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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
