In RFC 2460 it states "IPv6 nodes must accept and attempt to process
extension headers in any order and occuring any number of times in the same
packet, except for the Hop-by-Hop Options header which is restricted to
appear immediately after an IPv6 IP Header." Below are some discussions
my colleagues and I have had on the Routing Type 0 extension header. Any
insight you can shed would be appreciated.
Duplicate Constraint
There are two conceivable cases that could produce multiple routing headers
in one packet. First, the originating node inserted two of these headers
because the desired route had more than 255 hops, the maximum number of
hops that can be specified in a single header. However, the IPv6 Hop Limit
field is an 8-bit field specifying a maximum hop limit of 255. Inserting
two routing headers covering more than 255 hops would prevent the packet
from ever reaching its destination because the IPv6 hop limit would be
exhausted. It should be noted that an extension header alone covering 255
hops would be nearly 4k bytes. Not only would specifying more than 255
hops prevent the packet from reaching it's destination, it would waste
internet resources processing these huge headers. Allowing the packet
originator to insert two routing headers covering less than 255 hops
combined, though unnecessary and inefficient, seems ok initially. However,
this case is indistinguishable from the second case which should not be
allowed. Comments?
The second case that could cause multiple Type 0 Routing headers to appear
in one packet is if an intermediate node inserted one. This would force
the packet to visit more nodes than the packet originator intended and may
prevent the packet from reaching the destination intended by the
originator. If the intermediate node inserted a new routing header before
the original routing header (closer to the IPv6 header), it would arrive at
a different destination (D2) when the new routing header is exhausted. If
the new destination (D2) has a route to the next segment specified in the
original routing header, the packet will be forwarded and may or may not
eventually reach the final destination intended by the packet originator.
The real problem occurs if an intermediate node inserts a new routing
header after the original routing header (farther from the IPv6 header).
When the original routing header is exhausted, the packet has reached the
final destination intended by the packet originator. However, since
another unexhausted routing header is present after the original, it would
be processed and cause the packet to be forwarded elsewhere. If the final
destination of the new routing header is the same as the original routing
header, the packet may arrive back at the intended final destination but it
will have unnecessarily traveled at least two more hops. Otherwise, the
packet will fail to reach the final destination intended by the packet
originator. This last case should clearly not be allowed and is
indistinguishable from the first case described. Therefore, should either
of these cases should be allowed?
Ordering Constraints
Does it makse sense for a routing header to follow a Fragment header? RFC
2460 says, "...unlike IPv4, fragmentation in IPv6 is performed only by
source nodes, not by routers along a packet's delivery path." It also
states "extension headers must be processed strictly in the order they
appear in the packet". This statement does not explicitly forbid
reassembly from occuring at an intermediate node which is what would occur
if a routing header followed a Fragment header**. However, a problem
occurs if an intermediate node reassembles a packet and the MTU for the
next hop is smaller than the size of the reassembled packet. In this case,
the intermediate node should discard the packet and send a "Packet Too Big"
message back to the source. This would cause a loop that would prevent the
packet from ever reaching it's final destination. On the other hand, if
the intermediate node did fragment the reassembled packet and forward it,
the packet might reach it's final destination but this would violate the
RFC statement that fragmentation only occurs at source nodes.
>From RFC 2402 (IP Authentication Header) "If required, reassembly is
performed prior to AH processing. If a packet offered to AH for processing
appears to be an IP fragment the receiver MUST discard the packet" RFC
2406 has exactly the same wording applied to ESP headers. If we adhere to
the rules in RFC 2460 that extension headers must be processed in the order
received, then an implementation cannot accept an ESP or AH header before a
Fragment header. This packet will be discarded per the rules in RFCs 2402
and 2406, right?
** A routing header followed by a Fragment header is the only way
reassembly could occur at an intermediate node. Reassembly by definition
is to take place at the final destination.
Thanks
Lori Napoli
z/OS Communications Server Development - TCP/IP Stack
919-254-6146 T/L 8-444-6146
E-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
