Hi David. > > Incidentally, RFC 2460 is clear that unknown headers should cause the > > packet to be dropped, so the transition strategy is tricky in any > > case.
> Water under the bridge and all that, but I'm curious: what was the > rationale for this? It would seem to imply it is impossible to do > incremental deployment of new headers, and thus essentially freezes > routing header development for the lifetime of IPv6. The way routing headers work in IPv6, the next destination in the routing header gets placed into the destination field of the base IPv6 packet. Thus, the packet itself (because of the routing header) is addressed to the router in question. If that router doesn't understand how to process it (i.e., presumably to place the next address into the destination field -- after doing whatever other processing is appropriate), there isn't much it can do other than drop it. Same as any other node receiving a packet addressed to it that it doesn't know how to handle. The benefit of this design (compared with IPv4) is that intermediate routers do no need to inspect packets containing routing headers, unless the router is the actual destination. In IPv4, every router has to look at the option, including routers that don't do anything as a result of looking at the routing option... Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
