Date: Mon, 23 Oct 2000 14:24:53 +0100 From: "Gallagher, Mick" <mick.gallagher@roke.co.uk> To: 'JINMEI Tatuya / ????' <jinmei@isl.rdc.toshiba.co.jp> Cc: freebsd-net@FreeBSD.ORG Subject: RE: GIF IPv6 tunnelling support Message-ID: <76C92FBBFB58D411AE760090271ED41866E027@RSYS002A>
next in thread | raw e-mail | index | archive | help
Hi Tatuya, Thanks for your reply. 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?) 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?) 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? Many thanks for your help. Best regards, Mick ---- mick.gallagher@roke.co.uk > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: 22 October 2000 15:13 > To: Gallagher, Mick > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: GIF IPv6 tunnelling support > > > >>>>> 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?76C92FBBFB58D411AE760090271ED41866E027>