Subject: Tunnel Encapsulation Limit Option in rfc2473

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 25 Jul 2000 14:18:49 -0400

Hello

After discussing this with a colleague who is trying to implement this spec
I believe there may be a problem with defining Tunnel Encapsulation Limit Option
as a Destination Option. When the packet is fragmented, the destination option 
header can be placed in the fragment if no routing header is present in the
packet.

Now, if you have nested tunnels, entry point for each tunnel will be doing
fragmentation.  So, the first tunnel entry point will encapsulate the original
packet, add the destination option, and then fragment to path MTU, palcing
the destination option in one of the fragments.  For the inner tunnel
to correctly process the Tunnel Encapsulation Limit Option, the inner
tunnel entry points will have to reassemble the packet, but there is
no guarantee that it will have all the framents.

There are 3 solutions to this that I can see.
  1.  Each entry point will have to add a routing header.
	- this is not very clean.
  2.  Use Hop by Hop option.
  3.  Invent another tunnel specific extension header that will
      be placed in every fragment.

-vlad 
++++++++++++++++++++++++++++++++++++++++++++++++++++
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-masked]
--------------------------------------------------------------------

---

From: Alex Conta <[email-masked]>
Date: Tue, 25 Jul 2000 16:49:37 -0400

Thank you for your note Vlad.

The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two
pieces of text are perhaps more important than others:

RFC 2473
 "Tunnel Encapsulation 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:..."

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"....

So,  in implementing RFC 2473, particularly the "tunnel encapsulation limit", one
must take in consideration the fact that:

1.. the "tunnel encapsulation limit" is part of the tunnel headers - this affects
the PMTU calculation, and thus fragmentation.
2.. the information carried by the "tunnel encapsulation limit" may be, at an
extreme, significant to every node in the tunnel, if every node in the tunnel is a
tunnel entry point. Which means that it may be processed at that extreme, like a
"hop by hop" header.
3. the "tunnel encapsulation limit" is part of the "control" information carried by
the tunnel headers, addressed to
the downstream tunnel nodes, therefore it MUST be available to each and every
downstream node in the tunnel, at and for the processing of each and every tunnel
header and packet generated by the upstream tunnel entry point..

Regards,
Alex

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 25 Jul 2000 17:29:14 -0400

Alex

>       extension headers that must be processed by nodes en route to the

to continue the paragraph:
	"... destination, 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."

Also from RFC 2460:
} 	"4.1  Extension Header Order
} 
} 	   When more than one extension header is used in the same packet, it is
} 	   recommended that those headers appear in the following order:
} 
} 	           IPv6 header
}         	   Hop-by-Hop Options header
} 	           Destination Options header (note 1)
} 	           Routing header
} 	           Fragment header
} 	           Authentication header (note 2)
} 	           Encapsulating Security Payload header (note 2)
} 	           Destination Options header (note 3)
}         
} 	   note 1: for options to be processed by the first destination
}                    that appears in the IPv6 Destination Address field
}                    plus subsequent destinations listed in the Routing
}                    header.
}            ...
} 	   note 3: for options to be processed only by the final
}                    destination of the packet.
} 
} 	 ...
} 	 4.6  Destination Options Header
} 
} 	   The Destination Options header is used to carry optional information
} 	   that need be examined only by a packet's destination node(s)...."

Thus, my statement that if you only specify the Destination Option Header (with
tunnel encapsulation limit option and any other options), then they will go into
the Fragmentable Part on the packet as per 2460. They will only be in the 
Unfragmentable Part if you specify a Routing Header after the Destination
Options.

> header and packet generated by the upstream tunnel entry point..

The tunnel encapsulation header in addressed to the tunnel exit point, not the
inner tunnels' entry point. Thus, since the inner tunnels' entry point is not
the destination, then it will not examine the Destination Option header.  Also,
since the packet may be fragmented, it will not be able to examine the
Destination
Option Header as I described above.  For each tunnel entry point to examine the
Destination Option header, a Routing Header must be specified after the 
Destination Option Header that would list each tunnel entry point.

Otherwise, you create a special rule on how to process the Destination Option
Header
that conatins "tunnel encapsulation limit" option.

> Alex

-Vlad

--

---

From: Alex Conta <[email-masked]>
Date: Wed, 26 Jul 2000 12:53:52 -0400

Vlad,

	In RFC 2473, page 14:

	   "Tunnel Encapsulation 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

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 27 Jul 2000 12:59:23 -0400

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

---

From: Alex Conta <[email-masked]>
Date: Fri, 28 Jul 2000 11:24:42 -0400

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