Re: Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

["C. M. Heard" <[e-mail]>]

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