Vlad,
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.
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.
Your comments are a valuable contribution in improving the
specifications, which is a permanent goal
with documents on standards track is a permanent goal. I noted the
request/suggestion for an explicit statement on the placing of a tunnel
encapsulation limit at tunnel packet fragmentation. This seems
particularly useful for host developers implementing fragmentation.
Thanks,
Alex
Vladislav Yasevich wrote:
>
> Alex
>
> This exception to Destination Option Header processing changes the
> fragmentation rules and makes Destination Option Header processing
> inconsistent.
>
> 1. Destination Option Header processing inconsistency:
> - You specify that Destination Option Header with Encapsulation Limit
> option must be processed by all inner tunnel entry points. However, these
> entry points are not the destinations specified in the destination field of
> the Tunnel Encapsulation Header (IPv6 header). Now RFC 2460, section 4
> clearly states:
>
> "With one exception, extension headers are not examined or processed
> by any node along a packet's delivery path, until the packet reaches
> the node (or each of the set of nodes, in the case of multicast)
> identified in the Destination Address field of the IPv6 header.
> ...
> The exception referred to in the preceding paragraph is the Hop-by-
> Hop Options header, which carries information that must be examined
> and processed by every node along a packet's delivery path, including
> the source and destination nodes."
>
> 2. Change to the fragmentation rule:
> - You state in the draft that every tunnel entry point must examine and
> process Tunnel Encapsulation Limit option if one is present. However
> you never state the amendment to the fragmentation rule, that Destination
> Option Header carrying the Tunnel Encapsulation Limit option must be
> placed in every fragment. If this amendment is not required, then there
> is no way to enforce the requirement the draft places on the tunnel entry
> points. The reason is, that if fragmentation happens according to rfc 2460,
> then the Destination Option Header, regardless of the options it carries,
> will be placed in the fragmentable part and since the inner tunnel entry
> point is not the destination, there will be no way for it to check the
> option.
>
> With the requirement that your draft places on fragmentation rules, the
> architecture suddenly needs to concern itself not just with the Extension
> Headers, but with the options that they carry.
>
> -vlad
>
> Alex Conta wrote:
> >
> > Vlad,
> >
> > In RFC 2473, page 14:
> >
> > "Tunnel Incapsulation Limit options are of interest only to tunnel
> > entry points. A tunnel entry-point node is required to execute
> > the
> > following procedure for every packet entering a tunnel at that
> > node:...."
> >
> > ".....(Note that this requirement is an
> > exception to the general IPv6 rule that a Destination
> > Options extension header need only be examined by a
> > packet's destination node. An alternative and "cleaner"
> > approach would have been to use a Hop-by-Hop extension
> > header for this purpose, but that would have imposed an
> > undesirable extra processing burden, and possible
> > consequent extra delay, at every IPv6 node along the path
> > of a tunnel.)"
> >
> > Please note the "exception".
> >
> > Further, or once more:
> >
> > The "tunnel encapsulation limit", along with the forwarding/routing and
> > hop limit information, is part of the "control" information stored by a
> > tunnel entry-point in the tunnel headers. This information
> > is used/processed by the nodes in the tunnel, downstream from the tunnel
> > entry-point, to appropriately forward the tunnel packets towards the
> > tunnel exit point.
> >
> > The forwarding/routing information and hop limit in the IPv6 main header
> > is processed by each and every node. The forwarding/routing information
> > in a routing header is processed by the nodes which are part of the
> > source route. The tunnel encapsulation limit is processed by entry-point
> > nodes in inner nested tunnels, and ignored by other nodes.
> >
> > Ideally, a tunnel entry-point would specify each tunnel entry point in
> > inner nested tunnels in a
> > tunnel routing header. This is however impractical, as a tunnel entry
> > point MAY not know all the downstream entry-points to inner nested
> > tunnels. Nevertheless, all entry-points in inner nested tunnels, which
> > in extremus can be all nodes in a tunnel, MUST have access to the tunnel
> > encapsulation limit, to avoid the effect of infinite encapsulation. The
> > tunnel encapsulation limit carried by the tunnel headers of a packet
> > MUST be put in the tunnel headers of every fragment of that packet, when
> > the packet gets fragmented.
> >
> > To conclude, in the context of RFC2473 explained above, the statement in
> > RFC 2460
> >
> > " The Unfragmentable Part consists of the IPv6 header plus any
> > extension headers that must be processed by nodes en route to
> > the
> > destination"....
> >
> > applies fully. Its explanation:
> >
> > "that is, all headers up to and including the Routing
> > header if present, else the Hop-by-Hop Options header if
> > present,
> > else no extension headers."
> >
> > if it is to be interpreted strictly ad literam, is excepted.
> >
> > Alex
> >
>
> --
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> Vladislav Yasevich Tel: (603) 884-1079
> Compaq Computer Corp. Fax: (435) 514-6884
> 110 Spit Brook Rd ZK03-3/T07
> Nashua, NH 03062
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
