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

From: Bob Hinden <[email-masked]>
Date: Sat, 29 Jan 2022 15:43:02 -0800

Hi,

We submitted the first working group draft of <draft-ietf-6man-hbh-processing-00>.   The changes from the previous individual draft are:

   *  6MAN Working Group Draft
   *  Reworked text to talk about processing HBH options at full
      forwarding rates, instead of "fast path"
   *  Revised Section 6 "New Hop-by-Hop Options" to allow variable sized
      HBH options, remove specific length requirements, and other
      clarifications.
   *  Editorial changes.

Please review.  Links below.

We are working on creating a github based issue tracker to capture issues on this draft.   Once we have that set up we will announce the details.

Bob & Gorry

—————

A new version of I-D, draft-ietf-6man-hbh-processing-00.txt
has been successfully submitted by Robert M. Hinden and posted to the
IETF repository.

Name:		draft-ietf-6man-hbh-processing
Revision:	00
Title:		IPv6 Hop-by-Hop Options Processing Procedures
Document date:	2022-01-29
Group:		6man
Pages:		13
URL:            https://www.ietf.org/archive/id/draft-ietf-6man-hbh-processing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/
Html:           https://www.ietf.org/archive/id/draft-ietf-6man-hbh-processing-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-hbh-processing

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.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Jan 2022 00:01:28 -0300

Hi, Bob & Gorry,

I may have missed some recent discussion of this I-D (my apologies for
that, if that's the case). Here are my comments:

Section 3, page 3:
>    *  Forwarding Plane: IPv6 hosts exchange user data through the
>       forwarding plane.  User data is processed by its recipient (i.e.,
>       an IPv6 host).  User data can traverse intermediate nodes (i.e.,
>       routers) between its source and its destination.  These
>       intermediate nodes process metadata contained in packet headers.
>       However, they do not process information contained in packet
>       payloads.

This misses the discussion in RFC9098: quite often forwarding nodes do
need to process IPv6 payloads.

Section 3, page 3:
>    *  Fast Path: A path through a router that is optimized for
>       forwarding packets without processing their payloads.  The Fast
>       Path may be supported by Application Specific Integrated Circuits
>       (ASICS), Network Processor (NP), or other special purpose
>       hardware.  This is the usual processing path within a router taken
>       by the forwarding plane.

Other might correct me, but... I don;t think the definition of "fast
path" should be conditioned with what the fast path is being optimized
for. -- it could very well be  optimized to process IPv6 header chain
(including ports) as long as the header chain is shorted than X bytes
(for some definition of X, which could e.g. be 64, 128, 256, 512, etc...)

* Section 4, page 5:
>    Unfortunately, this did not improve the processing of Hop-by-Hop
>    options and did not significantly improve deployment and use in the
>    Internet.  Essentially, it only documented how they were being used
>    in the Internet at the time RFC8200 was published.

Has enough time elapsed  to be able to tell if the RFC8200 made a
difference or not?

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

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

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.

* Section 5.2:
>    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 (as described
>    in the next paragraph).

Wouldn't this mean that the previous requirement was really a "SHOULD" then?

* Section 8, page 11:
>    The authors believe that these changes significantly reduces the
>    security issues relating to IPv6 Hop-by-Hop options and will enable
>    them to be used safely in the Internet.

One of the main security problems associated with IPv6 EHs is that too
many implementations seem fail to gracefully handle malformed/malicious
EHs. See:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipv6+extension+header

So, if asked to process EHs, just for a possible future use case, it;s
no surprise that may operators will argue "No, thanks".

Thanks,
Fernando

On 29/1/22 20:43, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
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: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Jan 2022 17:03:36 +1300

One small comment:

> Has enough time elapsed  to be able to tell if the RFC8200 made a

Probably the reference date should be the publication of RFC7045,
which said it first (in 2013). But neither of those RFCs expected
to change the status quo.

     Brian

> “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: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 17:12:05 +0000

Hi Bob,

Thanks for the update. 

*Reworked text to talk about processing HBH options at full forwarding rates, instead of "fast path"

I feel the above change is vague and the meaning of "at full forwarding rate" is not very clear. In many platforms (e.g., CPU and NP), adding more processing always means lowering the throughput. We often accept it because we think the device can still sustain the normal traffic load in the average case.

I think we can admit an HBH option if it can be processed on "fast path" with moderate cost which can be justified by the benefits it brings. Somehow the criterion seems subjective and depends on many factors.

Best,
Haoyu

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Saturday, January 29, 2022 3:43 PM
To: IPv6 List <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; Bob Hinden <[email-masked]>
Subject: <draft-ietf-6man-hbh-processing-00>

Hi,

Bob & Gorry

-----

A new version of I-D, draft-ietf-6man-hbh-processing-00.txt
has been successfully submitted by Robert M. Hinden and posted to the IETF repository.

Name:		draft-ietf-6man-hbh-processing
Revision:	00
Title:		IPv6 Hop-by-Hop Options Processing Procedures
Document date:	2022-01-29
Group:		6man
Pages:		13
URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C0b4cfe2c69654a99df0d08d9e38127c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790966164495284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XyTN9ltSeab5rlvjr6XjX48%2BXWA%2BWpnCPSK%2FGdAydAQ%3D&amp;reserved=0
Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-hbh-processing%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C0b4cfe2c69654a99df0d08d9e38127c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790966164495284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xzHN%2FtFer45Enxh3rtYJuAXr84Y%2F8rcoj51Jz8bgXGM%3D&amp;reserved=0
Html:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.html&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C0b4cfe2c69654a99df0d08d9e38127c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790966164495284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=jQ6ucOFMjXbS6gKU2EgKK54D9bLsdZF2BkopWgMJvDo%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-hbh-processing&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C0b4cfe2c69654a99df0d08d9e38127c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637790966164495284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gg8YsbbG8jwZwIK3qPmq6JDYZ7QoEn8j7er1PtCxRUE%3D&amp;reserved=0

Abstract:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Feb 2022 07:58:47 +1300

I read "full forwarding rate" to mean "at line speed". That is precise - is it what the authors intended?

Regards
    Brian Carpenter

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Jan 2022 19:37:58 +0000

"at line speed" is also vague. Typically the line speed can only be achieved under certain assumption of the packet size. The minimum possible packet size is 40Bytes, barely any hardware can sustain the line speed forwarding for it at the terabit throughput. The more processing one adds to the packets, the larger packet size needs to be assumed to claim the "line speed" forwarding. 

Regards,
Haoyu

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, January 31, 2022 10:59 AM
To: Haoyu Song <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>
Subject: Re: <draft-ietf-6man-hbh-processing-00>

Regards
    Brian Carpenter

On 01-Feb-22 06:12, Haoyu Song wrote:
> URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C5c120f334b004b6b845108d9e4ebb900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792523357280754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DxHxrk3Yc9zaQ5QXMdCgPEaPSJS2JzrOvvdYyqU32%2Fg%3D&amp;reserved=0
> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-hbh-processing%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C5c120f334b004b6b845108d9e4ebb900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792523357280754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=AAf61TOdtFyVZl5gjHD6KBaOzhP1F3COZMsr4a67sJI%3D&amp;reserved=0
> Html:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.html&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C5c120f334b004b6b845108d9e4ebb900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792523357280754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=f2YZZ%2By7cvJwAgz4SxVDB7Bd5w%2FN0rTRuRBdPBeuBDo%3D&amp;reserved=0
> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-hbh-processing&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C5c120f334b004b6b845108d9e4ebb900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792523357280754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2GRadFQkQTXegK%2F5A7c2N1zouofMbx8aqQo2eiOtOUs%3D&amp;reserved=0
> 
> 
> Abstract:
> Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C5c120f334b004b6b845108d9e4ebb900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792523357280754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5S376Msnr4eCHT2O5is4h%2Fx09OeG78GoBXJsGbFLges%3D&amp;reserved=0

---

From: Tom Herbert <[email-masked]>
Date: Mon, 31 Jan 2022 12:34:50 -0800

> is a bad practice.. Many in the operational world would actually argue
Fernando,

By operational world, I think you mean network operations as opposed
to all host side operations. 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?

> probably focus more on the overall IPv6 header chain length, than in the

draft-ietf-6man-eh-limits-00.txt discusses that and sets a limit for
IP header chain length.

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

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Feb 2022 14:33:46 +1300

> "at line speed" is also vague. Typically the line speed can only be achieved under certain assumption of the packet size. The minimum possible packet size is 40Bytes, barely any hardware can sustai…

I agree that vendors can cheat in their marketing claims, but the *definition* of "at line speed" can be independent of the packet size distribution. Since the packet/fragment size is bounded by the minimum packet size and by the link MTU, we can write a precise definition of "at line speed". (That says nothing about the dwell time of a packet within the router.)

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.

    Brian

---

From: Haoyu Song <[email-masked]>
Date: Tue, 1 Feb 2022 03:17:20 +0000

Hi Brian,

I'm not sure I understand your definition of "line speed".  Could you please elaborate on it a little bit more?

Regards,
Haoyu

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, January 31, 2022 5:34 PM
To: Haoyu Song <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>
Subject: Re: <draft-ietf-6man-hbh-processing-00>

    Brian

>> URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C02afdd0ae11f48dbd46a08d9e522e760%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792760367852090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Mq99aEwyyL3y1uIjDCF%2FsyDDdzop%2F5baOUkGjnaZe7s%3D&amp;reserved=0
>> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-hbh-processing%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C02afdd0ae11f48dbd46a08d9e522e760%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792760367852090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nstSHAkwOmq58EANIEcUqAJ24SegCRKww0lf1s4mcnQ%3D&amp;reserved=0
>> Html:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-6man-hbh-processing-00.html&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C02afdd0ae11f48dbd46a08d9e522e760%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792760367852090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=N7uREYlt1b1cwV%2BK6bRyV4S4OOvPHrmKdAOM8tuFJjc%3D&amp;reserved=0
>> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-hbh-processing&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C02afdd0ae11f48dbd46a08d9e522e760%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792760367852090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7HHSsAPQ8s265VKQxdBZqmbwp5uG0kqANr05co7DEEo%3D&amp;reserved=0
>>
>>
>> Abstract:
>> Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C02afdd0ae11f48dbd46a08d9e522e760%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637792760367852090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=KR%2FHgEY9LxSVQpHEJswUhwOUHQcSa6OozsUHUyQOlBI%3D&amp;reserved=0

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Feb 2022 16:22:19 +1300

That will take more than a few moments. I'd rather first see some feedback from Gorry and Bob about whether they want to go in that direction.

Regards
    Brian Carpenter