Brian E Carpenter <[email protected]> wrote: > On 2012-05-23 08:47, Ole Tr??an wrote: >> Brian E Carpenter <[email protected]> wrote: >> >>> I agree with that, but we seem to have a small problem. >>> >>> RFC 2460 says that unrecognized extension headers should >>> lead to a discard and an ICMP Parameter Problem message, >>> and RFC 6434 confirms this - but without adding the extension >>> headers defined since RFC 2460. Thus the Internet is partially >>> opaque to MIPv6, SHIM6 and HIP, depending on which vendors >>> happen to allow for them.
(This, of course, is wrong: we really-should fix it.) RFC 6564 "updates" RFC 2460, but this is easily missed, especially since it has no text to contradict the "should discard" message of RFC 2460. But the mere existence of possible extension headers unknown at the time a particular IPv6 node's software was written implies that sometime some node will encounter a newly-defined header; and an always-discard rule is unduly limiting. (IMHO, of course; but anyone disagreeing is WRONG!) >> RFC2460: >> With one exception, extension headers are not examined or processed >> by any node along a packet's delivery path, until the packet reaches >> the node (or each of the set of nodes, in the case of multicast) >> identified in the Destination Address field of the IPv6 header. That has always been clear to me: "Don't look; don't tell!" > I wish it was true. There are definitely boxes that are opaque to > unrecognized headers. You are correct that the text in 2460 about > discard is not supposed to apply to forwarding nodes, which are only > supposed to examine the hop-by-hop options header, but this seems to > have been misunderstood by some implementors. Alas, "Don't look" is also unworkable: we should recognize the reality. There _will_ be middleboxes that look; many of them will discard: this is damage to route-around if we can. Nothing we write in RFCs will stop middleboxes from discarding stuff. But such behavior is not helpful; and it's very sad that RFC 2460 seems to endorse it. We should have a clear path for extending the list of extension headers (and especially for finding more middle-ground between _every_ hop must process and _no_ hop should process before the destination). Perhaps all the examples we can think of right now beg for "Experimental" status; but the time will come when we reach consensus some such animal should be standardized. -- John Leslie <[email protected]> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
