Subject: Comments on draft-ietf-6man-hbh-processing-00

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Feb 2022 11:44:01 -0800

Hi, here's some comments on the draft:

Section 3: Very nice definitions of Slow Path and Fast Path

"Unfortunately, this [RFC8200] did not improve the processing of
Hop-by-Hop options and did not significantly improve deployment and
use in the Internet." Is there empirical data to support this
statement that the changes in RFC8200 did not help?

"Routers are commonly configured to drop transit packets containing
hop-by-hop options that would have be processed in the Slow Path." --
this is the behavior that the changes in RFC8200 intended to address.
The idea seems simple, if a router doesn't have the capacity to
process HBH options it should just ignore them. Other than the problem
that the router may need to skip over them, ignoring HBH options is
negligible processing cost and eliminates any potential of a DoS
attack. The benefit of ignoring instead of dropping is that other
devices in the path that may have more capabilities can process the
HBH options and provide value.

"Allowing multiple hop-by-hop options in a single packet makes it even
more expensive in router resources to process these packets." -- true,
but the leap from routers processing zero options in a packet to
processing one is much greater than the leap from one to N options. If
the intent is to limit use of HBH options to just one option per
packet, then that obviously curtails future innovation. This is why
draft-ietf-6man-hbh-processing recommends for those routers that
process HBH options to be able to process up to eight of them.

"If the node can not process an option at the full forwarding rate, it
MUST behave as if it does not recognize the Option Type"-- without a
normative definition of "full forwarding rate" it's difficult to see
how this could be a MUST requirement.

I like to suggest that all the non-00 types be changed to "MAY
discard" as well but "MUST stop processing HBH options" when a non-00
type is encountered (at the destination it is still a MUST). The
rationale is that RFC8200 already made discarding a packet with
unknown options a MAY (a router that ignores HBH options wouldn't drop
any packets with unknown options)

"* Straight forward to process.  That is, they should be designed to
keep the time to process low."-- yes, always good practice to make
protocols straightforward to process :-)

"* New Hop-by-Hop options should be designed to be the first option in
a Hop-by-Hop options header."-- I'm not sure what this means. Unless
there's some special requirements that only apply to the first option,
or an option is defined that explicitly requires another option to
precede it, aren't all HBH options already designed to be the first
option?

"*  The size of an option should not extend beyond what can be
reasonably expected to be executed at full forwarding rate"-- This is
pretty ambiguous. Both protocol developers and implementations need to
have a common understanding and expectation about what requirements
are for size of options, etc. This is what
draft-herbert-6man-eh-limits endeavours to establish, maybe a
reference to that here?

General question: RFC2460 specified that all routers must process HBH
options, RFC8200 relaxed that requirement to allow routers to ignore
HBH options. Is this draft changing that to be that routers MUST
process at least one option, or can they still ignore all HBH options?

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2022 09:10:41 +1300

Tom

On one point:
On 11-Feb-22 08:44, Tom Herbert wrote:

...

> process at least one option, or can they still ignore all HBH options?

It doesn't matter what we write, leading-edge line-speed routers will ignore
them. So IMHO this statement in the draft is unrealistic:

"This document updates [RFC8200] that a node MUST process the first Option in the Hop-by-Hop Header at full forwarding rate..."

and only a SHOULD is realistic.

I also object to this:

"A node configured not to process HBH options, MUST drop the packet if the top two bits of the Option Type field of the first HBH option is non-zero."

I can't see any vendor of really high speed routers implementing that as
a default behavior. Why would they even look beyond the Destination Address?
They wouldn't even have an option to process or not process HBH.

     Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Feb 2022 12:21:12 -0800

On Thu, Feb 10, 2022, 12:10 PM Brian E Carpenter <
[email-masked]> wrote:

> "This document updates [RFC8200] that a node MUST process the first Option
> in the Hop-by-Hop Header at full forwarding rate..."
>
> "A node configured not to process HBH options, MUST drop the packet if the
> top two bits of the Option Type field of the first HBH option is non-zero."
>

Oh, I missed that. That would indeed answer my question if this is draft
requiring routers to process one option. Agree, this is not a feasible
requirement and seems to be somewhat reverting what RFC8200 states.

Tom