Tim,
1. There are some implementations that were written tunneling code
before the tunneling specs were published as Proposed Standard, and that
was independent of the authors, the WG, or the developers.
Once RFC 2473 was out, it was supposed to have among others, the role of
bringing implementations
to a common denominator in regards to tunneling. That put,
unfortunately, some additional burden on those developers that had early
tunneling implementations, in particular if those implementations
were incomplete, or deviated from the RFC 2473.
Whether one way of implementing correctly fragmenting tunnel packets
carrying the tunnel encapsulation limit is worse or better it is an
implementation issue.
One can look just for the presence of a destination header with tunnel
encapsulation limit, and mark the point past that header as delimiter of
the unfragmentable portion of the tunnel packet. The procedure for
looking for the tunnel encapsulation limit is to be implemented anyway
for the use of the inner tunnel entry-points forwarding engines.
An efficient and correct implementation of a fragmentation engine
according to RFC 2460, and RFC 2473, is to look for a logical delimiter
of the unfragmentable portion rather than use specific next header types
as delimiters. Routing, hop by hop, and tunnel header processing engines
would set or update such a logical delimiter, past the headers that they
generate or process. The delimiter can be a pointer or offset in the IP
packet.
2. Please note, that once the specs were published as PS, they reflect a
process, which includes a Last Call in the WG and a Last Call in IESG.
That qualifies as far as I know as a general consensus.
The important point though is that both the specs and implementations
can be improved. As part of improving the specs, the authors of RFC 2473
are going to revisit the messages exchanged on this topic. Next week is
a very good opportunity and we will take full advantage of it.
Meanwhile I subscribe to Tim's call for more opinions on this matter.
Thanks,
Alex
Tim Hartrick wrote:
>
> 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]
--------------------------------------------------------------------
