Fred Baker wrote:
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.
Right, so for end hosts, any new extension header would have to be
supported. Firewalls, IDSes, routers with ACLs etc. would probably also
need to be upgraded. Say a firewall might be configured to only allow
certain UDP and TCP traffic through. If it finds an unknown extension
header, it might believe it's an unknown protocol that shouldn't get
through. Even if the payload really is UDP/TCP that should get through.
Trying to assume that an unknown protocol number is an extension header
and then to look what's beyond it would be a very bad idea.
It might have been useful to remove the ambiguity by having a predefined
protocol number range for potential new extension headers. Then current
equipment/software could be made to support future unknown headers.
Anyway, I'm hoping that any new stuff can be options within the
currently defined extension headers...
Stig
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
