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

Hi authors,

Could you please explain the relationship between this doc and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers, in which the processing policy for the packets with HBH EH is DROP or IGNORE? If the processing policy is really needed to be revised, can we update the WG draft https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering accordingly?

Best Regards,
Zhenqiang Li 

li_zhenqiang@hotmail.com

From: Tom Herbert
Date: 2021-06-03 23:17
To: Bob Hinden
CC: Gorry Fairhurst; IPv6 List
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Hello, a few comments on the draft:

>From the draft: "Unfortunately, this did not improve the processing of
Hop-by-Hop options and did not significantly improve deployment and
use in the Internet."

Is there data that supports this statement? Since RFC8200 was
published, have router implementations been changed to ignore HBH
options instead of dropping packets containing them? The primary
problem with supporting HBH Options in the Internet isn't that we need
all nodes in the path to process them, it's that we need all nodes in
the Internet to at least forward packets containing them and not
blindly drop the packets.

"This document updates [RFC8200] that a node MUST process the first
Option in the Hop-by-Hop Header in the Fast Path"

It think this should be "This document updates [RFC8200] that a node
MUST process the first Option in the Hop-by-Hop Header in the Fast
Path if a node is configured to process Hop-by-Hop Options"

"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"

I suspect that the share of traffic containing any EH is very small
:-). There's an obvious tradeoff here in limiting an extensibility
mechanism to elicit feasible implementation versus not restricting the
mechanism so much that it inhibits innovation. So we need to define
and recommend some number of options N that satisfies both these
objectives. Emerging programmable devices, such as those based on P4
or PANDA, are more capable and flexible than ASIC based
implementations, so N=1 might not be the best choice looking forward
since it is overly restrictive. Note also that section 5.3 of RFC8504
sets N=8 for end host processing of HBH and Dest Options (I suggest
RFC8504 should be referenced by the draft).

"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."

This is a change to RFC8200 that would make a lot of implementations
retroactively non-conformant. I don't think it's practical. I would
suggest updating to RFC8200 with these requirements instead.

- If an intermediate node processes an option it does not recognize
and the top two bits of the Option Type field of the option are
non-zero, then the node MUST stop option processing and SHOULD NOT
drop the packet and SHOULD NOT send an ICMP Parameter Problem.
- A final destination node MUST process all the Hop-by-Hop Options, or
drop the packet if the number of options exceeds the configured limit
per RFC8504. This includes processing per the top two bits of Option
Type when an option is unrecognized as specified in RFC8200.
- New Hop-by-Hop Options SHOULD be defined with 00 as the top two bits
of the Option Type (that is new option should be defined to be ignored
if they are unrecognized by a node).

Tom

On Wed, Jun 2, 2021 at 11:32 AM Bob Hinden <bob.hinden@gmail.com> wrote:
>
> Hi,
>
> We posted a new version of draft-hinden-6man-hbh-processing.    The changes include:
>
>    *  Expanded terminology section to include Forwarding Plane and
>       Control Plane.
>    *  Changed draft that only one HBH Option MUST be processed and
>       additional HBH Options MAY be processed based on local
>       configuration.
>    *  Clarified that all HBH options (with one exception) must be
>       processed on the Fast Path.
>    *  Kept the Router Alert options as the single exception for Slow
>       Path processing.
>    *  Rewrote and expanded section on New Hop-by-Hop Options.
>    *  Removed requirement for HBH Option size and alignment.
>    *  Removed sections evaluating currently defined HBH Options.
>    *  Added content to the Security Considerations section.
>    *  Added people to the acknowledgements section.
>    *  Numerous editorial changes
>
> We think this resolves most of the issues raised on the list and at the pervious IETF meeting.
>
> Please review and comment on the list.
>
> Bob & Gorry
>
> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
> Date: June 2, 2021 at 11:27:07 AM PDT
> To: "Robert M. Hinden" <bob.hinden@gmail.com>, "Godred Fairhurst" <gorry@erg.abdn.ac.uk>, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>, "Robert Hinden" <bob.hinden@gmail.com>
>
>
> A new version of I-D, draft-hinden-6man-hbh-processing-01.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>
> Name: draft-hinden-6man-hbh-processing
> Revision: 01
> Title: IPv6 Hop-by-Hop Options Processing Procedures
> Document date: 2021-06-02
> Group: Individual Submission
> Pages: 13
> URL:            https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> Html:           https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01
>
> Abstract:
>   This document specifies procedures for how IPv6 Hop-by-Hop options
>   are processed.  It modifies the procedures specified in the IPv6
>   Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-
>   Hop options practical with the goal of making IPv6 Hop-by-Hop options
>   useful to deploy and use in the Internet.  When published, this
>   document updates RFC8200.
>
>
>
>
> The IETF Secretariat
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------