On Oct 19, 2006, at 3:53 AM, Su Thunder wrote:
I don't think your comment is a problem. Whether a block of memory
is payload or an extension header is determined by the Next Header
value of the immediately preceding header, not whether the
extension header is known or unknown. A node should pass an unknown
extension header to the next header immediately following it, why
it regards something unknown as something else?
yes, but there is some ambiguity there. One can use the value in the
next header field to indicate an interior header, or one can use it
to pass out to another protocol such as TCP.
So you are a machine that doesn't know the meaning of the number
(let's say) 254. Is it an interior header, in which case it is of a
certain size and you can continue processing to determine that maybe
there is an end to end header after it, or is it a new transport
protocol? How do you know?
And actually, as I read the spec, that's not what it is supposed to do.
If, as a result of processing a header, a node is required to
proceed
to the next header but the Next Header value in the current
header is
unrecognized by the node, it should discard the packet and send an
ICMP Parameter Problem message to the source of the packet, with an
ICMP Code value of 1 ("unrecognized Next Header type encountered")
and the ICMP Pointer field containing the offset of the unrecognized
value within the original packet. The same action should be
taken if
a node encounters a Next Header value of zero in any header other
than an IPv6 header.
When it comes to a number it doesn't know how to interpret, it is
supposed to drop the datagram and report to the sender.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
