Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

[Joe Touch <[e-mail]>]

On 3/28/2016 4:44 PM, Fred Baker (fred) wrote:
> 
>> On Mar 28, 2016, at 4:30 PM, Joe Touch <[e-mail]> wrote:
>>
>>
>>
>> On 3/28/2016 3:21 PM, Brian E Carpenter wrote:
>>> On 29/03/2016 10:36, Fred Baker (fred) wrote:
>>>>
>>>> On Mar 28, 2016, at 2:29 PM, [e-mail] wrote:
>>>>> Note, however, that the idea of an offset to "jump" to the transport
>>>>> header makes no sense. There's no rule that HBH header lengths never
>>>>> change in transit, which means you just end up with another field that
>>>>> might be inconsistent with the actual header.
>>>>
>>>> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94.
>>>
>>> In any case, that issue is foreseen in
>>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6
>>
>> Simple counterexample - quickstart (RFC4782).
>>
>> Intermediate routers are allowed to indicate they do not support the
>> option by *deleting* it.
> 
> There's deleting and deleting. One could move any succeeding options
> forward 8 bytes (not six, as the document says), shorten the HBH header
> by 8 bytes, remove the HBH option entirely if it is now empty perhaps,
> and move everything else forward by 8+ bytes as well. Or, one could
> overwrite the quickstart option with an 8 byte PAD option. Guess which
> one I would do...

There are many ways that COULD work, but unfortunately there are as many
that won't.

The trouble happens when (not if) this jump option is part of a header
that is modified by an endpoint that knows the old option and not this
jump one. There's no rule that requires that HBH headers be modified in
a way that won't affect offsets, and unless the offset is
mandatory-to-support for intermediate devices, the situation gets worse
as new options are added.

Joe