> > 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).
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
