On 08/10/2013 05:53, C. M. Heard wrote:
> 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.)
Yes, and for a moment there you had me worried, but if the security
concern is that the unknown header may contain bad stuff and/or cause
a buffer overflow bug, then it really doesn't matter whether it is
an extension header or a payload header. In either case, if you let
the packet through, you are assuming that the destination host knows
what it's doing.
We might need a slight rewording to remove the implication that
253/254 can *only* be used as extension headers. Something like:
"Experimental" extension headers include those defined by any
Experimental RFC, and the values 253 and 254 defined by [RFC3692]
and [RFC4727] when used as experimental extension headers.
>> ---
>>
>> 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.
Disagree, for reason given in my previous message.
> 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]
>
We can ask IANA to fix bugs anytime, surely?
Brian
>
> Thanks and regards,
>
> Mike Heard
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
