Subject: Re: Tunnel Encapsulation Limit Option in rfc2473

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 01 Aug 2000 13:21:56 +0900

>>>>> On Fri, 28 Jul 2000 11:09:51 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> What Vlad is pointing out is that we now must put code into the general
> fragmentation path which not only needs to know about existance of dest-
> ination option headers but needs to know about and search for specific
> options in the destination options header based on whether the next header
> value of the last header in the datagram is IPPROTO_IPV6.  Either that or
> we need to have special purpose fragmentation code that only deals with
> tunnel ingress processing.

> Both these alternatives are bad in my opinion.  The first is a performance
> hit, the second is code bloat.  It is doable but suboptimal.

> Continuing to insist that you haven't changed the fragmentation rules is
> not an accurate assessment of the situation once one considers the details
> of actual implementation.

(although we've never tried to implement the tunnel encapsulation
option in the KAME statck) I completely agree with Tim and Vlad; the
proposed rule for the new option contradicts with general rules
described in RFC2460, and the advantage of the new rule is not worth
modifying existing implementations (IMHO).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Tue, 1 Aug 2000 09:33:38 -0700

> modifying existing implementations (IMHO).

I'll agree with this also. This is a non-trivial & ugly change to the
fragmentation rules in RFC 2460.

It may be too late, but how about this idea - have two code points for the
Destination Options, one that indicates fragmentable Destination Options
(typically used after routing/fragment header) and one that indicates
non-fragmentable Destination Options (typically used before routing/fragment
header, or when there is a tunnel encapsulation option).

Rich

---

From: Sowmini Varadhan <[email-masked]>
Date: Mon, 7 Aug 2000 13:11:55 -0400 (EDT)

tim> > > Continuing to insist that you haven't changed the 
tim> > fragmentation rules is
tim> > > not an accurate assessment of the situation once one 
tim> > considers the details
tim> > > of actual implementation.

jinmei> > (although we've never tried to implement the tunnel encapsulation
jinmei> > option in the KAME statck) I completely agree with Tim and Vlad; the
jinmei> > proposed rule for the new option contradicts with general rules
jinmei> > described in RFC2460, and the advantage of the new rule is not worth
jinmei> > modifying existing implementations (IMHO).

richdr> I'll agree with this also. This is a non-trivial & ugly change to the
richdr> fragmentation rules in RFC 2460.
richdr> 
richdr> It may be too late, but how about this idea - have two code points for the
richdr> Destination Options, one that indicates fragmentable Destination Options
richdr> (typically used after routing/fragment header) and one that indicates
richdr> non-fragmentable Destination Options (typically used before routing/fragment
richdr> header, or when there is a tunnel encapsulation option).

Instead of hacking up destination options, wouldn't it be cleaner to 
adopt Vlad's idea of a new tunnel-specific extension header that is 
unfragmentable, and is to be parsed by tunnel entry points only?

--Sowmini