Re: [v6ops] Call for adoption: draft-peng-v6ops-hbh

On Fri, Sep 10, 2021 at 4:00 PM Bob Hinden <bob.hinden@gmail.com> wrote:
>
> Hi,
>
> If there is enough interest in v6ops, I generally support the V6OPS w.g. taking this on as a w.g. document.   I am a co-author of a few relevant documents in 6MAN, these are:
>
> draft-ietf-6man-mtu-option
> draft-hinden-6man-hbh-processing
>
> The second represents a proposed solution to the issues with IPv6 Hop-by-Hop options.  At the high level, I think there is general agreement that the goals of draft-peng-v6ops-hbh and draft-hinden-6man-hbh-processing are aligned.   If adopted they could reference each other.   Another relevant document presented in 6MAN is draft-herbert-6man-eh-limits.   I think this is also aligned.

Yes, the need for extension headers is alluded to in the draft "IPv6
Extended Header limitations that need to be addressed to make HBH
processing more efficient and viable in the forwarding plane". It
might make sense to reference draft-herbert-6man-eh-limits (for
instance it addresses the 2,048 bytes in a single EH problem).

>
> While the problems with IPv6 Hop-by-Hop options are generally well known and described in IETF documents, for example <draft-ietf-v6ops-ipv6-ehs-packet-drops>, RFC9099 and RFC7872, I don’t see any harm in doing another, if it helps us to improve the situation with IPv6 Hop-by-Hop headers.  If we want to fix this, we need to work together.
>
> I do see a number of serious issues with draft-peng-v6ops-hbh-06, even though it is much better than the earlier versions that should be fixed if adopted.  These include:
>
> 1) The current title is "Processing of the Hop-by-Hop Options Header”.   This makes it sound a lot like how routers should process IPv6 HBH headers and options, not like a description of the operational issues.   I think will cause confusion with draft-hinden-6man-hbh-processing that is titled "IPv6 Hop-by-Hop Options Processing Procedures”.   I think draft-peng-v6ops-hbh should change it’s title avoid this confusion.  Something like “Operational Issues with Processing Hop-bb-Hop Options Headers” (or something similar) would be better.
>
> 2) Section 2. "Modern Router Architecture”
>
> This appears to be a good description of some “modern” router architectures, but I suspect there are other architectures that are different.   For example, there are still a lot (perhaps the majority of routers) of software based routers without hardware assist and differentiated control and forwarding planes.  This section needs work if it intends to describe all router architecture handling of Hop-by-Hop option headers.
>
> 3) Section 3.  Specification of RFC 8200
>
> This section summarizes text from RFC8200.   In general it is better to quote other RFCs instead of trying to summarize them.   Summarizing tends to loose subtle differences.
>
> 4) Section 7 Requirements
>
> This section needs a lot of work, or should be removed.   For example, looking at the the first requirement:
>
>    *  The HBH options header MUST NOT become a possible DDoS Vector.
>
> This has several serious issues.   The first is that any protocol mechanism can be used a a DDOS attack vector under the right circumstances.   With a MUST NOT this requirement is impossible to meet.   The use of upper case RFC8174 key words turns this into a protocol specification, I don’t think that would be in scope for V6OPS.
>
> The next requirement:
>
>    *  HBH options SHOULD be designed so that they don't reduce the
>       probability of packet delivery.  For example, an intermediate node
>       may discard a packet because it contains more HBH options than the
>       node can process.
>
> How can you design an HBH option that knows how many options an intermediate node (we usually call these routers) can process?   Again, it’s a requirement that can’t be met.
>
> I have similar comments on the other requirements, but won’t list them here.  As I said, this section either needs a lot of work, or should be removed.
>
> 5) Section 8.  Migration Strategies
>
> This section also has serious issues.   These include:
>
> It talks about characterizing options into either control options or forward options.   We only have HBH Options, not two types.
>
I believe this is describing that a router might choose to process
some HBH options in the forwarding fast path, and some in a software
slow path. IMO, from a host stack perspective, any HBH options being
sent should be processed in the fast path or not processed at all--
taking the slow path for some packets creates performance variances
and OOO packets.

> It says nodes are updated to the proposed behavior introduced in the pervious section, but the previous section says requirements.
>
> It says edge nodes (we usually call these hosts in IPv6) should check whether the packet contains an HBH header with control or forwarding options.   This isn’t a good description of how hosts actually work, nor are there control or forward options.
>
> This section may be a remanent of an earlier version of this draft that was proposing different types of HBH options, but can’t really tell.   Might be best to remove this section.
>
> Bob
>
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops