Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Brian,

thanks for splitting the discussion up into it’s three piece. However, i’m answering this one first because there is some relation to the other one on HBH. Further see below.

> Am 14.04.2017 um 04:28 schrieb Brian E Carpenter <[e-mail]>:
> 
> And one more comment for today:
> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
> 
> ...
>>> As it says in Section 4.8:
>>> 
>>>  Defining new IPv6 extension headers is not recommended.  There has to
>>>  be a very clear justification why any new extension header is needed
>>>  before it is standardized.  Instead of defining new Extension
>>>  Headers, it is recommended that the Destination Options header is
>>>  used to carry optional information that must be examined only by a
>>>  packet's destination node(s), because they provide better handling
>>>  and backward compatibility.
>>> 
>> Yes, this text is the text I have problem with. I think I would suggest to drop the first part and only have this part:
>> 
>> "It is recommended to rather use the Destination Options header 
>> to carry optional information that must be examined only by a
>> packet's destination node(s), instead of defining new Extension
>> Headers, because they provide better handling
>> and backward compatibility."
> 
> "Defining new IPv6 extension headers is not recommended" is a rather
> mild statement. There were certainly some in the WG who wanted
> a MUST NOT here. It's an operational and security concern: existing
> middleboxes, especially firewalls, are allergic to extension headers
> that they don't understand. This is unfortunate, since the design model
> was that the forwarding path should be transparent to all headers, which
> meant that new headers could be deployed between consenting adults
> without any infrastructure issues. But this simply doesn't work in
> the real world - that's the main reason we wrote RFC7045. I think it's
> worth quoting this:
> 
>   This combination of circumstances creates a "Catch-22" situation
>   [Heller] for the deployment of any newly standardised extension
>   header except for local use.  It cannot be widely deployed because
>   existing middleboxes will drop it on many paths through the Internet.
>   However, most middleboxes will not be updated to allow the new header
>   to pass until it has been proved safe and useful on the open
>   Internet, which is impossible until the middleboxes have been
>   updated.
> 
> So, defining new IPv6 extension headers is not recommended, because
> they probably won't work across the Internet. But it isn't a MUST NOT,
> because if there was a compelling operational case, we could do it and
> the middleboxes would follow.

First of all yes, giving further explanation/background is definitely a good thing to do, and maybe also provide a reference to rfc7045 if appropriate.

I think I agree that I would not like to make a normative statement here, given that the circumstances are not due to the protocol design itself but because of the current deployment situation we have (which in theory could change in future).

However, instead of making a clear recommendation to not every define a new extension header, I think I would prefer if the text was phrased in the a way that would make the risk clear, give a clear recommendation to rather use destination options if suitable, and then say nothing else.

Maybe you can work on some new text and then have a quick (?) check with the wg which text is preferred. If there is clear consensus for one way by the wg I will not further block this.

However, please see my next mail.

Mirja

P.S.: My understanding from the text above is that the new extension header will be dropped but not the whole packets. Is that right? Because in this case there are still ways for experimentation.


> 
> RFC 7045 was intended to nudge middlebox developers in the right
> direction, and similarly draft-ietf-opsec-ipv6-eh-filtering. But it's
> an uphill battle.
> 
>     Brian
>