>>>>> On Mon, 19 Apr 2004 15:28:39 -0400,
>>>>> Lori Napoli <[EMAIL PROTECTED]> said:
> I have a question about Routing Headers (type 0), more specifically what
> happens when we receive an ICMPv6 msg where the offending packet contained
> a routing header. From RFC 3542, a routing header can contain 127 IPv6
> next hop addresses.
I first would like to note that the RFC3542 specification is not the
essential part of this discussion. RFC3542 simply allows the maximum
number based on the protocol specification, and this is rather a
protocol issue.
> Therefore, if a packet specified the maximum number
> of entries in a routing header, the routing header alone would exceed 1280
> bytes. Now, if an intermediate node needed to drop this packet and
> generate an ICMPv6 msg, the ICMPv6 msg can only contain as much of the
> offending packet as will fit within minimum MTU (1280 bytes). Therefore
> it is possible for the offending packet within the ICMPv6 msg to not
> contain the entire routing header. This ICMPv6 msg will be sent to the
> original source of the packet, but the source address of the ICMPv6 msg
> will not be the original destination address of the packet since the
> destination address in the IPv6 header changes when there is a routing
> header. So, how does the originating node correlate this ICMPv6 packet
> with the correct socket? Since we can't rely on the entire routing header
> being present in the offending packet, we can't even rebuild what the
> original destination would have been.
I think your concern is valid, but this is mostly not specific to
routing headers. If we want to deliver an ICMPv6 error to a
particular socket(s), the inner packet of the error message should
contain the upper layer header such as a TCP header. However, we
cannot always guarantee this due to the existence of intermediate
extension headers. And, this does not only apply to routing headers,
but also to all other kinds of extension headers.
But I don't think this issue requires an update on the spec. After
all, ICMPv6 error messages basically only work in a best-effort
manner.
The only problematic case, as far as I can see, would be ICMPv6 too
big messages for path MTU discovery. In this case, however, we can
still update the MTU information gradually; we first update the MTU
information to the intermediate destination stored in the destination
address field of the inner IPv6 packet. Then succeeding packets will
go farther. And, eventually, we can at least reach at the
intermediate destination without seeing an ICMPv6 too big error. Then
the IPv6 destination address will be updated to the next intermediate
destination (which might be the final one), and we can still reach
there by the similar steps.
> My second question is that for IPv6, the Type 0 Routing header can contain
> 127 addresses. This routing header is considered non-fragmentable. If
> your interface is Ethernet with a standard 1492 MTU, this packet cannot be
> sent on that interface since the routing header alone would exceed 1492.
> It seems inconsistent to me to allow such a large non-fragmentable header.
This is also true, but this is not specific to routing headers
either. And, again, I don't see this is a bug of protocol
specification to be fixed. First, this would still work for links
with a larger link MTU. Secondly, at least IMO, it is not unfair to
say it's the sender's responsibility to keep the unfragmentable part
not exceeding the path MTU (if not, the sender can detect the error,
at least theoretically).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
