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

[Suresh Krishnan <[e-mail]>]

Hi Mirja/Bob,


On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden <[e-mail]> wrote:
> Hi,
>
>> On Apr 16, 2017, at 4:57 AM, [e-mail] wrote:
>>
>> Brian, Mirja,
>>
>>>>> 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.
>>>
>>> I think I will leave that for the document editor. A large part of RFC7045 is about this issue but Bob can probably see best how to integrate it here.
>>
>> I think what is in the document already is representing the working group consensus.
>> The issues of new / unknown extension headers, and how to distinguish these from new transport protocols have been discussed from many angles. The two main reasons for the strong recommendation against new extension headers are:
>> - most uses are already accommodated with the 3 existing containers options (routing. hbh and destination)
>> - sharing the same number space with IP protocols, makes it hard for intermediate devices depending on parsing the header chain to find transport information if new headers were introduced.
>>
>> There is already an opening / provision in the text for new extension headers. The text only asks for these considerations to be made, before proposing new ones.
>
> I agree.
>
> I also note that the text in this section was derived from RFC6564, which updated RFC2460.  Specifically from Section 3 of RFC6564:
>
>    Mindful of the need for compatibility with existing IPv6 deployments,
>    new IPv6 extension headers MUST NOT be created or specified, unless
>    no existing IPv6 extension header can be used by specifying a new
>    option for that existing IPv6 extension header.

Yes. This text was arrived at after a lot of discussion in the 6man WG
during the development of the draft that became RFC6564.

>
> New extension headers are allowed (just not recommended) and the next paragraph in the Section specifies a format that should be used for new Extension headers.  I think there is a lot of flexibility going forward.

Yep. I think the above warning is issued because a node processing an
unknown extension header will simply drop it, and this makes
incremental deployability of these new extension headers difficult
over the Internet.

Thanks
Suresh