Alex,
>
> 1. There is NO CHANGE to the fragmentation rules stated by RFC 2460.
>
> RFC 2473 merely specifies packet size calculations and tunnel headers
> specifics, which apply
> to tunnel packets only. These complement/extend the rules of RFC 2460
> for tunnel packets.
>
Actually, there is a change because if someone has written general
code to fragment IPv6 datagrams based on the rules in 2460, that code
won't work properly if presented with a datagram of the form.
| IPv6 outer header | Dst option header with encap limit | IPv6 inner header |
That general code will place the fragment header in front of the
destination option header thus creating a datagram that does not have
the encap limit option available for the next tunnel ingress point.
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.
> 2. RFC 2473 states the trade off made in using a destination rather than
> a hop by hop
> option header to carry the tunnel encapsulation limit. It also explains
> the reasoning behind
> the trade off. Practically, inner tunnel entry points are mostly routers
> in a packet's path.
> They are infrequent enough to make both the hop by hop processing costs,
> and a third type of
> options header in the architecture harder to justify, than an exception
> in processing destination
> headers. In making the trade off, the authors, and the WG were in
> consensus that practical world considerations outweigh abstract
> perspectives.
>
> Note: the third type of options header would be processed only by some
> nodes in the path, as opposed to hop by hop, and destination.
>
Given the limited implementation experience at the time that consensus was
reached (read none) I dare say that it might be, and I mean might be not is,
time to revisit the consensus. Given that the document is only proposed
standard it should be possible to make modifications if necessary.
It would be nice to hear from others that are attempting to write code to
support this specification.
Just one man's opinion.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
