Re: [Spud] updated draft PLUS charter, rev. 1 June

[Joe Touch <[e-mail]>]

On 6/22/2016 2:18 PM, Tom Herbert wrote:
> On Wed, Jun 22, 2016 at 2:05 PM, Joe Touch <[e-mail]> wrote:
>>
>> On 6/22/2016 1:45 PM, Tom Herbert wrote:
>>>>> - For a fragmented packet each fragment can contain hop-by-hop options
>>>>> but not each one contains transport headers.
>>>>> - Hop-by-hop options must be first extension header in the packet so a
>>>>> network device only needs to parse the IPv6 header and one type of EH.
>>>>> If a middlebox has to access the transport layer header and payload it
>>>>> would need to be able to parse over other types of extension headers
>>>>> (routing, DO, etc.)
>>>> Except that they tend to want to jump over only a small number of such
>>>> options; increasing that number increases the chance the packet is dropped.
>>>>
>>> Per RFC2460 those devices should not be jumping over any options at
>>> all, this is non standard behavior.
>> The two high-order bits of all options determine whether they can be
>> ignored - at which point, they can be "jumped over". E.g., 00 allows
>> "skip and continue processing".
>>
>> You haven't mentioned whether you want that behavior, but if you don't
>> then the option will die at the first non-supporting router.
>>
> Right, I would say that HBH options like this should be 00. 

If that's the case, you can't know when a router processes a datagram
but ignores this option.

(note - TTL/hopcount tricks won't work - you can't know the difference
between a single router that decrements the TTL/hop by 2 and a second
router that ignores this option)

> Note
> though that the wording in RFC2460bis now allows nodes in the path to
> ignore HBH. That means that only nodes that are interested in what is
> in the options, like devices that would support the proposed
> signaling, need to inspect them.

Ick. That behavior was already supported by the choice of the option
designer. Taking away the potential to create "must handle" options is a
bad thing.

Joe