On Mon, 7 Oct 2013, Adrian Farrel wrote: > Section 1.1 > > A couple of points about the following paragraph: > > In this document "standard" IPv6 extension headers are those > specified in detail by IETF standards actions. "Experimental" > extension headers are those defined by any Experimental RFC, and the > experimental extension header values 253 and 254 defined by [RFC3692] > and [RFC4727]. "Defined" extension headers are the "standard" > extension headers plus the "experimental" ones. ... > Are 253 and 254 intended solely for experimental extension headers? > Couldn't the experiment be an experimental payload protocol?
This is a good point. RFC 3692 calls these out as experimental values for the IP Protocol Field, so experiments could in principle use these values either for experimental upper layer protocols or for experimental IPv6 headers. Nodes that are not involved in the experiment (including middleboxes) would have no way of knowing the difference. This opens up a small can of worms, because Section 2.1 says that "[e]xperimental IPv6 extension headers SHOULD be treated in the same way as standard extension headers, including an individually configurable discard policy." The problem is that if a node not participating in an experiment encounters a next header value of 253 or 254 it won't know whether to treat what follows as an experimental extension header, conforming to the uniform TLV format specified in RFC 6564, or an experimental upper-layer protocol, where all bets are off with respect to format. If packets containing these values are to be passed by a middlebox not participating in an experiment, it seems that the middlebox would have to stop parsing when encountering these values, and pass or drop the packet depending on what it's supposed to do with unknown upper layer protocol protocol types. (As an aside, it occure to me that the same thing is true if a middlebox encounters a next header type that it does not recognize -- it won't know if it refers to an extension header or an upper layer protocol, and must treat it as the latter. Hence the requirement that "[f]orwarding nodes MUST be configurable to allow packets containing unrecognised extension headers" means, in practice, that a middlebox needs to have a switch to allow unknown upper layer protocols to pass through.) > --- > > I find myself in I-wouldn't-have-done-it-this-way land, so this is, of > course, just a Comment for you to chew on and accept or reject according > to how it strikes you... > > It seems to me unwise to create a new registry that duplicates > information held in another registry. By adding a column to the > "Assigned Internet Protocol Numbers" registry you are making it > completely clear which are the IPv6 Extension Headers. Rather than risk > having this registry out of step with your new "IPv6 Extension Header > Types registry", I would have had the existing, empty "IPv6 Next Header > Types" registry redirect users to the "Assigned Internet Protocol > Numbers" registry and mention the existence of the specific column that > identifies extension headers. I think this idea has a lot of merit. Putting that information in the Internet protocol numbers registry would also provide an opportunity to fix some things about extention header entryes that currently are not quite right, such as: 43 IPv6-Route Routing Header for IPv6 [Steve_Deering] 44 IPv6-Frag Fragment Header for IPv6 [Steve_Deering] Thanks and regards, Mike Heard -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
