Dow,
Fortunately, Bill Fenner thought things through when drafting
RFC 4727 (Experimental Values in Headers):
"3.6. IPv6 Routing Header Routing Type
This document assigns two values for the Routing Type field in the
IPv6 Routing Header, 253 and 254."
So, people wanting to work on a new RH type can develop
use cases and run experiments using these values, without
further IETF action. These values are fine in a 'consenting
adults' situation if unmodified nodes implement the RFC 2460
rules correctly.
Brian
On 2007-08-31 09:32, Dow Street wrote:
On Aug 30, 2007, at 1:31 PM, Brian E Carpenter wrote:
Incidentally, RFC 2460 is clear that unknown headers should cause the
packet to be dropped, so the transition strategy is tricky in any case.
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.
Yes, but this would only be the node addressed by the IPv6 header -
or do I read this wrongly?
Correct ... and actually I quoted the wrong text for the case of an
unknown RH number, but the result is the same - only the next-hop
router listed in the RH itself needs to understand that new RH number.
But that does create a 'consenting adults' situation; if you construct
an RHx you must know that every router listed in it understands RHx,
otherwise the packet will be dropped. That is quite a restriction on
deployment scenarios beyond experimental or local use.
Brian
Maybe this isn't a huge problem. For source routing to be particularly
useful, the sender probably wants / needs to know something about the
topology. At a minimum, the sender would presumably need to know the
addresses of the way-points to use in the source route. Whatever
mechanism / process is used to determine these way-points could probably
verify RHx support (at those addresses) with just a little more work.
R,
Dow
So the core of the network is not affected either
way (unless explicit filtering is implemented somewhere), and only
routers of end networks that wish to participate in, say, a future RH4
routing would need to upgrade the software.
-is
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
