Subject: Re: <draft-ietf-6man-hbh-processing-00>

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Feb 2022 12:10:16 -0300

Hi, Brian,

On 31/1/22 22:33, Brian E Carpenter wrote:
[...]
>
> I also suspect that devices handling terabit lines will not be the ones
> attempting to look at HBH options. This really hasn't changed since
> RFC7045 and probably not since RFC1812; leading edge routers only do
> routing.

Agreed. But, as specified in this document, they seem to be required to.

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Feb 2022 12:22:02 -0300

Hi, Tom,

On 31/1/22 17:34, Tom Herbert wrote:
[...]
>> * Section 4, page 6:
>>>     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", and
>>>     that "The share of traffic containing more than one EH however, is
>>>     very small.  For the design of hardware able to handle the dynamic
>>>     nature of EHs, we therefore recommend to support at least one EH".
>>
>> This paragraph missed RFC7872, which is a product of the IETF.
>>
>> Aside, not sure what [Hendriks] stating that dropping packets with EHs
>> is a bad practice.. Many in the operational world would actually argue
>> quite the opposite.
> Fernando,
>
> By operational world, I think you mean network operations as opposed
> to all host side operations.

Network + cloud. -- folks normally have a fair share of technical
aspects/issues to deal with to add support for something that for the
most part is currently not needed, and regularly brings problems.

> If a host is trying to legitimately use
> extension headers and the network drops them, then the network is
> simply being detrimental to host communications. Also, even if it is
> true that many network operators believe that it is good practice to
> drop packets with EH, has anyone ever brought that to IETF in the form
> of a BCP with a clear rationale or a proposal to obsolete extension
> headers in the protocol?

 From the point of view of anyone doing operations, your problem is
solved as soon as you've addressed that in your own network and systems.

>> * Section 5.2:
>>
>> I believe this draft is missing a very important point that is one of
>> the key take-aways from RFC9098: The overall IPv6 extension header
>> chain. -- this is a crucial aspect.
>>
>> In order to comply with this requirement:
>>
>>      Nodes that implement a differentiation between a Fast Path and a Slow
>>      Path MUST process all (with one exception noted below) Hop-by-Hop
>>      options in the Fast Path.
>>
>> routers should be prepared to process IPv6 header chains of arbitrary
>> lengths in the fast path. And that;s simply unfeasible for many router
>> architectures that have the concept of slow/fast path.
>>
>> So, IMHO, if this document really means to make a difference, it should
>> probably focus more on the overall IPv6 header chain length, than in the
>> number of HBH options.
>>
>
> draft-ietf-6man-eh-limits-00.txt discusses that and sets a limit for
> IP header chain length.

That's a good thing -- I'll take a read.

FWIW, when we were doing RFC7112, at some point we tried to limit it to
1280 bytes, and the idea didn't fly. -- that's why RFC7112 (and now
RFC8200) limit it to the local MTU, essentially.

>> The measurements in RFC7872 seem to also agree that the longer the IPv6
>> header chain, the higher the probability that the packet will get dropped.
>>
> I don't see how RFC7872 shows that. The data shows the drop rates that
> only allow comparisons between different types of extension headers,
> to make a correlation between length of IP header chain and drops we
> need data for the same extension header type with different sizes.

Oops, you're right! FWIW, I did do such measurements at the time
(they're just not in RFC7872, because that would have screwed up the
tables). And it boils down to this: as you increase the EH-chain length,
so does the drop rate.

I'll try to re-run the experiment again, and also set up a web page such
that it's run regularly and folks can see changes (if any).

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Feb 2022 08:42:00 +1300

> Agreed. But, as specified in this document, they seem to be required to.

But of course, they won't, if the laws of physics determine otherwise.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Feb 2022 17:15:08 -0300

Hi, Brian,

> But of course, they won't, if the laws of physics determine otherwise.

What I'm trying to say is: are we working/planning to mandate a behavior
that we're already well aware of that is not possible to comply with? :-)

Thanks,