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