Date: Tue, 24 Oct 2000 09:51:16 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: "Gallagher, Mick" <mick.gallagher@roke.co.uk> Cc: freebsd-net@FreeBSD.ORG Subject: RE: GIF IPv6 tunnelling support Message-ID: <y7vu2a3f4e3.wl@condor.isl.rdc.toshiba.co.jp> In-Reply-To: In your message of "Mon, 23 Oct 2000 14:24:53 %2B0100" <76C92FBBFB58D411AE760090271ED41866E027@RSYS002A> References: <76C92FBBFB58D411AE760090271ED41866E027@RSYS002A>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Mon, 23 Oct 2000 14:24:53 +0100, >>>>> "Gallagher, Mick" <mick.gallagher@roke.co.uk> said: > As I read it, RFC2473 covers 3 areas: > 1 - Definition of packet encapsulation (in terms of bytes on the wire) > 2 - The implied means of encapsulation (i.e. looping packets through the stack twice) > 3 - Additional extension headers, etc. > 1 is critical. Does the GIF driver and RFC2473 observe the same > method of packet encapsulation? (i.e. Is the inner v6 packet > embedded in the outer by inserting a v6 protocol value (41?) into > the 'next header' field of the outer packet?) Yes, I believe so. > 2 may be important, in that it may implies whether or not the stack > looks after extension header processing. If the GIF driver performs > packet encapsulation but does not handle extension headers, then I > guess this makes tunnel fragmentation impossible. Is this an issue? > (I suppose not, given that Path MTU discovery should prevent > this. Are there any other not-so-desirable implications of lack of > tunnel extension headers that you're aware of?) Actually, the gif output routine recursively calls IPv4 or IPv6 output routine where fragmentation is done if necessary. I'm not sure if path MTU discovery works well for the tunnel link, but it would be anther issue. > 3 I'm not so concerned with. I assume that if we tried to > interoperate GIF with an RFC2473 tunnelling entity, we shouldn't run > into problems since (i) The tunnel encapsulation is (hopefully) the > same, and the (ii) GIF driver will simply ignore Tunnel > Encapsulation Limit destination options. Does this sound reasonable? If your main concern is interoperability between a KAME (i.e. gif) box and another implementation that sends encapsulated packets with the Tunnel Encapsulation Limit option, you're right. The KAME box will simply ignore the (unknown) option, and the packet will be just forwarded. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vu2a3f4e3.wl>