Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt

[Fernando Gont <[e-mail]>]

On 05/05/2014 09:11 PM, Brian E Carpenter wrote:
>>
>> That being said, if Brian is correct in his assertion that we should 
>> expect typical filtering middleboxes to agressively apply a "default 
>> deny" policy to unknown extension headers, 

Well, policy is policy. Why I'd expect such policy to be widespread,
we're essentially ruling out the other possibility.


>> then I'd have to agree 
>> with his conclusion that UEH (or a reserved range of next header 
>> values) would fail to achieve its intended purpose, which is to get 
>> them to skip over unknown extention headers.  On the other hand, I 
>> have gotten the impression from much of the discussion here and on 
>> v6ops that the usual aim of filtering middeboxes is to inspect 
>> transport headers, not specifically extension headers, and apply a 
>> "default deny" policy to transport protocols.

Exactly. That's the comment that I made in my previous response ot Brian.


>>> 2. Given that argument, I think this draft should consider a 4th 
>>> possible solution: Do Nothing. I think it's a valid option.
>>
>> If "do nothing" means make no changes to the normative 
>> specifications in 7045 and 6564, then yes, that is a valid option.
>>
>> That being said, there has in the past been an impression that RFC 
>> 6564 guaranteed that it would be possible to skip over unknown 
>> extension headers -- see, e.g., the changes in the above-referenced 
>> DHCPv6-Shield draft in going from -01 to -02.
>>
>> In order to clear up thus confusion, it would probably be useful to 
>> at least publish advice to implementors of middleboxes that any 
>> unrecognized Next Header value SHOULD be treated as if it indicates 
>> the presence of an unknown upper-layer header, because it is unsafe 
>> to treat it as if it were a new extension header with the TLV format 
>> defined by RFC 6564.  

Agreed.

> 
> Right, because even if they use the complete IANA list of extension
> headers, as specified in RFC 7045, it might be out of date.
> 
>> It would also be good to remind them that they 
>> MUST provide a configuration option to allow packets containing such 
>> values, as specified in RFC 7045, noting that a side-effect of 
>> allowing all unrecognized extension headers is that unrecognized 
>> transport protocols will be allowed also.
> 
> Yes. Whatever we decide about this draft and UEH, I think an
> implementation guide is sorely needed.

Yes. That's kind f the stuff we had in mind as part of elaborating on
Section 5.3 -- should that option be the "winner".

We will expand and resubmit.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492