Re: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

[Gorry Fairhurst <[e-mail]>]

A few comments...

On 10/06/2021 10:18, Fernando Gont wrote:
> Hi, Gorry,
>
>
> On Thu, 2021-06-10 at 09:04 +0100, Gorry Fairhurst wrote:
>> * Section 4, page 4:
>>>>    The changes meant that an implementation complied with the IPv6
>>>>    specification even if it did not process hop-by-hop options,
>>>> and
>>>> that
>>>>    it was expected that routers would add configuration
>>>> information to
>>>>    control which hop-by-hop options they would process.
>>> The way I interpret RFC8200 is that a router is configured whether
>>> it
>>> needs to process the HbH header in the first place, rather than
>>> whether
>>> to process specific options.
>>>
>> I see, I don't see RFC8200 as saying whether this has to be a global
>> "switch"
>>
>> to disable processing, or whether it allows configuration that can
>> result
>>
>> in disabling. This ID intends to update and clarify that aspect.
> Fair enough. From my pov, I might live with simply skupping the HbH,
> but wouldn't have my boxes parse its contents. -- i.e., either ignore
> the whole thing, or drop. :-)
>
Understood.
>>> * Section 4, page 5:
>>>
>>>>      There has been research that discussed the general problem
>>>> with
>>>>      dropping packets containing IPv6 extension headers, including
>>>> the
>>>>      Hop-by-Hop Options header.  For example [Hendriks] states
>>>> that
>>>>      "dropping all packets with Extension Headers, is a bad
>>>> practice"
>>> Given the number of vulnerabilities associated with the processing
>>> of
>>> IPv6 EHs, and that it's a feature that is largely unused, the
>>> converse
>>> is probably true.
>>>
>> I thought you'd say so. However, this is a proposal to simplify the
>> method
>>
>> and to enable them to be used. I don't agree that this is generally
>> unsupported
>>
> FWIW, my point is that a claim such as "dropping all packets with EHs
> is abad practice" is kind of flawed/bogus statement.  -- it kind of
> implicitly assumed that it's the result of an arbitrary decision. ..
> when in many cases it's actually the other wat around.
That's a point the WG will need to agree upon:-) ... It also depends on 
how the WG sees (future) use of HBH options.
>>> * Section 4, page 5:
>>>
>>> This discussion misses an important point/aspect: the lgnth of the
>>> IPv6
>>> header chain. e.g., asking nodes to support a single HbH option if
>>> such
>>> option is, say, 256 bytes, will still be unfeasible.
>>>
>> Are you saying the first option (HBH has to be first), is not within
>> the first 256 bytes? I don't understand.
>>
>>
>> What I mean is: one of the problematic aspects is the overall IPv6
>> header chain length. No matter the restriction on the number of HbH
>> instances or number of HbH options, if the overall IPv6 header chain
>> length is too long, you;ll be in trouble.
>>
>> THe definition of too long depends on the implementation, and can be
>> anything from 8 to, say, 512, in powers of 2.  -- see RFC7872 for hint
>> of the impact of the IPv6 header chain length on the drop rate.
>>> * Section 5.1, page 6:
>>>> [RFC8200] also requires
>>>>      that a Hop-by-Hop Options header can only appear once in a
>>>> packet.
>>> This doesn't seem accurate. RFC8200 states:
>>>
>>>     IPv6 nodes must accept and attempt to process extension headers
>>> in
>>>     any order and occurring any number of times in the same packet,
>>>     except for the Hop-by-Hop Options header, which is restricted to
>>>     appear immediately after an IPv6 header only.  Nonetheless, it
>>> is
>>>     strongly advised that sources of IPv6 packets adhere to the
>>> above
>>>     recommended order until and unless subsequent specifications
>>> revise
>>>     that recommendation.
>>>
>>> i.e., there's a recommendation to send only one HbH, but still
>>> required
>>> to process all received. (cursed by the robustness principle, if
>>> you
>>> wish :-) )
>>>
>> The proposed ID targets PS to change this.
> What I mean is that the I-D argues that RFC8200 states that there can
> only be one instance of HbH. However, it actually simply *recommends*
> to have a single instance, but requires that any number of HbH
> instances are accepted and processed (hence my reference to the
> robustness principle)
>
>
So, the core thing from my side is that the ID is motivating that ONE 
HBH option can be useful.

The message was intended to be that more HBH options might also be 
useful, but deisgns need to be careful ... because, in the near future,  
routers might not process later HBH options in the same packet.

> * Section 5.3, page 8:
>
>>>>         The Router Alert Option is a problem since it's function
>>>> is to
>>>> do
>>>>         what this specification is proposing to eliminate, that
>>>> is,
>>>>         process the packet in the Slow Path.  One approach would
>>>> be to
>>>>         deprecate it as it's usage appears to be limited and
>>>> packets
>>>>         containing Hop-by-Hop options are frequently dropped.
>>> Nore: This option is employed for MLD packets, which result from ND
>>> using multicast. In such scenarios (MLD is link-local) packets
>>> survive
>>> -- cause they don't need to be forwarded in the first place.
>>> Whether
>>> using RAO for MLD (or whether MLD itself) is a good idea, is a
>>> different question... ;-)
>> Sure, isn't a Router Alert also used hop-by-hop with MPLS, RSVP for
>> QoS,
>> and other methods?
> Yep. What I'm saying is that it is actually used. So.. how/why would
> you deprecate it?
>
I see, and I think I agree. - I'm aware there is as BCP (168), aka RFC 
6398, which makes recommendations in this space, and that might be a 
good basis for whatever is decided.
>>> * Section 8, page 10:
>>>
>>>>      *  Limited the default number of Hop-by-Hop options that that
>>>> can
>>>> be
>>>>         in a packet to a single Hop-by-Hop option.
>>> If you are pursuing that path, you should also limite the overall
>>> IPv6
>>> header chain length. That;s probably even more important than
>>> limiting
>>> the number of EHs or number of HbH options.
>>>
>> Why does that impact the ability to process a HBH-O in a router?
>
> It doesn't. It affects the ability of the router to obtain layer-4
> information from the packet. And when that happens, as per draft-ietf-
> v6ops-ipv6-ehs-packet-drops, packets get dropped. That leads to
> unreliability of HbHs, which affects their possible usage.

I see. That might be something that impacts some types of usage for sure 
when the HBH option causes inspection of the transport header.

I also agree: This also impacts traversal (i.e. can lead to drop) in 
devices that generally check EHs.

We should note these.

> Thanks!
>
> Regards,

Gorry