>>>>> On Fri, 28 Jul 2000 11:09:51 -0700 (PDT),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
