Date: Sun, 22 Oct 2000 23:12:51 +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: <y7vsnpphsm4.wl@condor.isl.rdc.toshiba.co.jp> In-Reply-To: In your message of "Thu, 19 Oct 2000 14:50:09 %2B0100" <76C92FBBFB58D411AE760090271ED41866E01A@RSYS002A> References: <76C92FBBFB58D411AE760090271ED41866E01A@RSYS002A>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Thu, 19 Oct 2000 14:50:09 +0100, >>>>> "Gallagher, Mick" <mick.gallagher@roke.co.uk> said: > The GIF man page suggests that the GIF tunnelling behaviour is based on RFC1933, which outlines transition mechanisms for IPv6 (basically v6 in v4 tunnelling). > So far as v6-in-v6 and v4-in-v6 tunnelling is concerned, does GIF implement RFC2473 (Generic Packet Tunnelling in IPv6)? RFC2473 contains many things, and some of them (e.g. Tunnel Encapsulation Limit option) are not implemented in the GIF stuff. Which part did you particularly mean? > Also, does the GIF driver perform packet encapsulation itself, or does it pass inner packets through the stack for encapsulation in the outer packet? > (I'm wondering about v6 extension headers in the outer packet). The gif output routine(s) basically encapsulates the whole outer packet by itself. But it does not attach any IPv6 extension headers. 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?y7vsnpphsm4.wl>