Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

On 4/17/2017 3:09 PM, Joe Touch wrote:
> Hi, Tom,
>
>
> On 4/17/2017 3:00 PM, Tom Herbert wrote:
>> On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch <[e-mail]> wrote:
>>> ...
>>> I don't think we should be writing rules to indicate who should NOT be
>>> changing them, if we already have rules indicating the only parties that
>>> can. (granted, the requirement in 7 needs to be revised in 2119-speak).
>>>
>> Joe,
>>
>> You may want to look at IPv6 EH description for guidance. Even with
>> all the words about how extension headers can't be examined or
>> processed with the exception of HBH options, there still has been
>> considerable discussion on what intermediate devices can or can't do.

For the benefit of others on this list who might not have followed this
issue, FWIW, this discussion happened during the revision of RFC2460 on
the v6ops and main IETF list.

RFC 2460 said the following:

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path

The one exception was HBH headers.

Discussion centered around a few issues:
    - 2460 said "not examined or processed" - did that include inserting
or deleting new EHs, which might arguably require neither examining nor
processing?
    - what does "processing" mean? (does it include altering? does it
include making a header longer or shorter?)
    - would not adding new EHs ossify IPv6?

It took a while to converge on the following:
    - that text now explicitly excludes inserting or deleting EHs
    - there are still arguments about what "processing" means, but that
term was accepted, given the clarification of inserting/deleting as
distinct operations
    - it was clarified (at least on the mailing lists) that the HBH
itself is already extensible, so disabling new EHs that change en-route
wasn't ossifying

------
For IPv6, this might have been important because it already did specify
cases where some EHs were modified in transit while others were not.

That's not the case for transport options, which is why I believe it is
unnecessary to provide detail on what devices en-route shouldn't be doing.

Joe