Subject: FW: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 2 Jul 2020 16:06:34 +0000

Hi Folks, 

We have just uploaded a new draft aiming to analyze and tackle the issues faced by the Hop-by-Hop Options Header, which has been sparsely used without any form of large scale deployment. 

However, as IPv6 is being rapidly and widely deployed worldwide, more and more new services that requires hop-by-hop forwarding process behavior are emerging, and also the already defined over ten HBH Options are going to be used widely in practice.

We look forward to hearing your feedback and comments, and try to release the benefits that could be provided by HBH Options header altogether. 

Best regards, 
Shuping

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 2, 2020 11:31 PM
To: Lizhenbin <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>
Subject: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has been successfully submitted by Shuping Peng and posted to the IETF repository.

Name:		draft-li-6man-hbh-fwd-hdr
Revision:	00
Title:		Hop-by-Hop Forwarding Options Header
Document date:	2020-07-03
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-li-6man-hbh-fwd-hdr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/
Htmlized:       https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-6man-hbh-fwd-hdr

Abstract:
   RFC8200 specifies the HBH header that is assumed to be processed by
   each hop in the delivery path of the packet.  However, RFC8200 also
   expects that nodes processing the HBH header have been explicitly
   configured to do so.  Therefore, it cannot be assumed that a HBH
   header present in the packet is processed.  It all depends on the
   configuration of each node across the path.  Moreover, in most of
   networks today, the processing of the HBH header is done in the
   control plane (slow processing path) which incurs several limitations
   among which resources consumption and security risk.

   For these reasons, over time, the Hop-by-Hop Options header has been
   sparsely used without any form of large scale deployment.  Also, most
   of already defined HBH options are forwarding options which contain
   forwarding plane information that needs not to be sent to the control
   plane.

   This document proposes a new Hop-by-Hop Forwarding Options Header in
   order to carry Hop-by-Hop options that are solely intended to and
   processed by the forwarding plane.  This new HBH header is confined
   in and dedicated to the forwarding plane while the current HBH header
   can still be used for control plane options.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bob Hinden <[email-masked]>
Date: Mon, 6 Jul 2020 10:24:44 -0700

Shuping,

A few comments on your draft (without co-chair hat on).

This is in direct violation of RFC8200, that is:

  4.8.  Defining New Extension Headers and Options

   Note: New extension headers that require hop-by-hop behavior must not
   be defined because, as specified in Section 4 of this document, the
   only extension header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

Further, I don’t see how defining a new option header with hop-by-hop behavior in anyway can resolve the operational issues with the current hop-by-hop header.   Forwarding planes can be configured to process the current hop-by-hop header just fine, like you propose with this new option.   A new one isn’t useful.

I don’t see any justification for this draft.   IMHO, handling of hop-by-hop options is an implementation issue in routers, and configuration of these routers by operators.   If there is a hop-by-hop option that provides enough benefit, I suspect that there will be incentive to use it in the operational internet.   That is the real reason why hop-by-hop options haven’t been used.  The expense/benefit ratio isn’t very good.

Stay well!

Bob

> On Jul 2, 2020, at 9:06 AM, Pengshuping (Peng Shuping) <[email-masked]> wrote:
> 
> Hi Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Jul 2020 10:55:36 -0700

> I don’t see any justification for this draft.   IMHO, handling of hop-by-hop options is an implementation issue in routers, and configuration of these routers by operators.   If there is a hop-by-h…

Bob,

We also can promote their use if we reduce the expense part of the
ratio. This is why the RFC8200 provision allowing intermediate nodes
to ignore HBH options and the allowances for nodes to limit the number
of options they process in RFC8504 are relevant to "fixing" HBH. The
nodes can first ignore Hop-by-Hop Options which is far better then
dropping at least. If a node does process them, they can apply
practical limits on how many options or how many bytes of headers they
process. The net effect is that either an intermediate node processes
Hop-by-Hop options or ignores them, and if a node processes then
they're processed in the fast path (history has shown if you want to
kill a network layer protocol feature used in the data path or make it
a candidate to be exploited by DOS attack ensure that it goes through
the "slow path" implementation ;-) ). This is another reason why this
draft is problematic, it tries to codify the fast path and slow path
of HBH options-- IMO it's better to eliminate the concept of HBH "slow
path" processing altogether.

Tom

Tom

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 7 Jul 2020 09:36:19 +0000

Hi Bob,

Thank you very much for your comments. Please find mine inline below. 

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 
Sent: Tuesday, July 7, 2020 1:25 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Shuping,

[Shuping] Yes, we are aware of this statement. Just we still believe that this proposal probably provides a more reasonable way to go forward to resolve the current issues and at the same time compatible with existing deployments in the network. 
The current HBH option header defined in RFC8200 carries both forwarding options and control options which carry information for the forwarding plane and the control plane, respectively. Currently there is no effective way to differentiate them. 
To have a HBH Forwarding Options Header that only carries the forwarding options is a more natural and compatible way to solve this issue. The current HBH Options Header can still be used for carrying the HBH control options that contain information only used for the control plane.

[Shuping] There are two problems here. 
First, there are some devices in the network that once they are configured to send the packets carrying HBH to the control plane their configuration is embedded in the implementation of the node and cannot be reconfigured as forwarding those packets on the forwarding plane. 
Second, the two types of options, i.e. forwarding options and control options, are both currently carried in the same HBH Options Header. If the carried option is a forwarding option, it would be just fine that the device is configured to process this HBH header on the forwarding plane. If the control option is carried, then the forwarding plane will be used to make the classification and then send the option to the control plane of this device. Please find the description in the draft below. 
“
   If all the HBH Options are forced to be processed first in the
   forwarding plane and then classified according to the HBH Option
   Type, it requires the consumption of the forwarding plane resources
   to make such processing selection, which will impact the forwarding
   efficiency.  Moreover, there are some existing nodes that are
   configured to assign the packets containing a Hop-by-Hop Options
   header to the control plane of the nodes cannot be reconfigured.
”

[Shuping] IMHO, just because it is left to implementation and configuration and there is no clear specification, different vendors and operators have various implementations and configurations, which makes the handling of the HBH along the path unpredictable. You never know for certain whether the packet carrying the HBH Options Header has been processed, dropped, or skipped, and whether it has been processed by the control plane or the forwarding plane. If such packets are dropped by some of the nodes along the path, it makes the network services relying on the HBH information impossible. Even worse, if every packet carrying the HBH options header is sent to the control plane it will cause inconsistent packet drop due to rate limitation, this will impact the normal IP forwarding which is not acceptable. That is also why some operators simply block the packets carrying HBH options header passing through their networks.

Stay well!

Bob

Thank you!

Best regards, 
Shuping

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 7 Jul 2020 09:44:37 +0000

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, July 7, 2020 1:56 AM
To: Bob Hinden <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Bob,

We also can promote their use if we reduce the expense part of the ratio. This is why the RFC8200 provision allowing intermediate nodes to ignore HBH options and the allowances for nodes to limit the number of options they process in RFC8504 are relevant to "fixing" HBH. The nodes can first ignore Hop-by-Hop Options which is far better then dropping at least. If a node does process them, they can apply practical limits on how many options or how many bytes of headers they process. The net effect is that either an intermediate node processes Hop-by-Hop options or ignores them, and if a node processes then they're processed in the fast path (history has shown if you want to kill a network layer protocol feature used in the data path or make it a candidate to be exploited by DOS attack ensure that it goes through the "slow path" implementation ;-) ). This is another reason why this draft is problematic, it tries to codify the fast path and slow path of HBH options-- IMO it's better to eliminate the concept of HBH "slow path" processing altogether.

Hi Tom,

Yes, we agree that for the HBH options that are supposed to be processed on the forwarding plane, the HBH “slow path” processing should be eliminated. However, currently both forwarding options and control options are carried in the same HBH option header defined in RFC8200, and there is no effective way to differentiate them. This can be resolved with the proposed HBH forwarding options header that only carries the forwarding options and is processed on the forwarding plane. 

Best regards,
Shuping

Tom

> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: [email-masked]
Date: Tue, 7 Jul 2020 14:02:17 +0200

> Yes, we agree that for the HBH options that are supposed to be processed on the forwarding plane, the HBH “slow path” processing should be eliminated. However, currently both forwarding options and…

Can you give an example of a "control plane" option and a "forwarding plane" option?

Cheers,
Ole

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 8 Jul 2020 01:44:09 +0000

Hi Ole, 

The HBH forward options contain information that is useful to a router's forwarding plane, e.g. the Jumbo Payload Option [RFC2675]. While the HBH Control Options contain information that is useful to a router's control plane, e.g. the Router Alert Option [RFC2711]. 
https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00#page-5

Please also find the Appendix in this draft in which we tried to list the currently defined HBH Options and classify them into HBH Forwarding and HBH Control Options. We can see that among all the defined HBH Options the HBH Forwarding Options are in the majority. 
https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00#page-8

Best regards, 
Shuping 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 7, 2020 8:02 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Jul 2020 19:27:35 -0700

> https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00#page-8

So that's a grand total of two HBH control options, neither of which
really have seen much deployment. Do you foresee more control options
being defined in the near future? Btw, pad options should be in some
sort of class of their own.

Tom

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 8 Jul 2020 03:14:54 +0000

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, July 8, 2020 10:28 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

> https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00#page-8

So that's a grand total of two HBH control options, neither of which really have seen much deployment. Do you foresee more control options being defined in the near future? Btw, pad options should be in some sort of class of their own.

Hi Tom,

We see some forwarding options being defined and foresee more emerging.

Yes, pad options can be used in either the forwarding plane or the control plane. 

Thank you!

Best regards,
Shuping

Tom

---

From: [email-masked]
Date: Wed, 8 Jul 2020 10:17:29 +0200

Shuping,

> https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00#page-8

Thanks, missed that.

The Jumbo payload option was designed for interconnect of supercomputers. That option is not generally applicable. E.g. routers would have to have buffers > 64K.

We already have infrastructure for indicating to routers on the path that they need to take a closer look at the packet with the general HBH option.

Would it make more sense to have this discussion when we have an actual use of the HBH functionality to discuss?

Best regards,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 Jul 2020 07:37:47 -0700

> We see some forwarding options being defined and foresee more emerging.
Peng,

Yes, but my question was about more control options. If all the HBH
options are going to be forwarding options anyway then it seems like
the effect of the draft is more to replace to Hop-by-Hop extension
headers with some new equivalent. That might be the intent, and I
suppose the logic is that if we start over from scratch then maybe the
"mistakes" in the design of Hop-by-Hop options can be rectified, but
as Bob said a new header would be prohibited by RFC8200.

Additionally, the implicit assumption in the draft in referencing
RFC7872 is that a new extension header would be dropped less often by
intermediate nodes; I'm don't see much basis for that. RFC7872 shows
that Destination Options and Fragment Headers are also dropped at
significant rates, where HBH is dropped more than FH which is dropped
more than DO. We can postulate a possible reason FH is dropped more
than DO is that nodes doing filtering can't parse beyond the fragment
header therefore drop packets for security. Devices wouldn't be able
to parse beyond a new extension header either, and the fact it's an
unknown protocol increases likelihood of drops with a security
justification. I'd guess that we should expect packets with new EH to
have drop rates at least that of FH maybe higher.

Tom

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 9 Jul 2020 00:53:09 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 8, 2020 4:17 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Shuping,

Thanks, missed that.

Hi Ole,

What would be an actual use of the HBH functionality in your mind? Thank you!

Best regards, 
Shuping 

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Jul 2020 14:20:42 +1200

Let's look at the options that the draft classifies as "Control Plane":

>>> HBH Control Options:
>>> 
>>>    o  Router Alert Option [RFC2711]
>>> 
>>>    o  Quickstart Option [RFC4782]

Router Alert instructs every router that it has something to do. In a sense you can argue that is a pointless option, because the very existence of a HbH options header tells every router that it needs to examine the entire header chain. In any case, my understanding has always been that high performance routers have always treated this as a signal to send the packet to the "slow" path, so I don't quite understand the advantage of treating it differently. 

Quickstart is an Experimental RFC from 13 years ago. The RFC unfortunately doesn't appear to state the time limit for the experiment or how we would evaluate the experiment, but it does say:

"As a result of these concerns,
and as a result of the difficulties and seeming absence of motivation
for routers, such as core routers to deploy Quick-Start, Quick-Start
is being proposed as a mechanism that could be of use in controlled
environments, and not as a mechanism that would be intended or
appropriate for ubiquitous deployment in the global Internet."

So to honest I don't think that Quickstart matters at all.

Looking at the list of "Forwarding Plane" options, I see that it includes the RPL option. RFC6553 says:

"The RPL Option provides a mechanism to include routing information
with each datagram that a router forwards.  When receiving datagrams
that include routing information, RPL routers process the routing
information to help maintain the routing topology."

I can't see how that is an action in the forwarding plane; it seems to describe a control plane action since it is updating the topology maps.

On balance it seems to me that almost any conceivable HbH option, which by definition is intended for consumption by routers, is a control plane action, i.e. it distracts the router from its elementary job of looking for the longest match for the destination address in its forwarding table.

(The Jumbo payload option is not really an exception to this, since as well as doing the longest match, the router must check that the outbound link supports the required MTU. Anyway, since the packet size by definition exceeds 65,575 bytes, nobody will really care about some overhead. Also, like most of the defined HbH options, it's a limited-domain option.)

Regards
    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Jul 2020 07:06:46 +0200

> Let's look at the options that the draft classifies as "Control Plane":
...
> >>>    o  Router Alert Option [RFC2711]
...
> In any case, my understanding has always been that high performance routers have always treated this as a signal to send the packet to the "slow" path, so I don't quite understand the advantage of treating it differently. 

Bingo. And i am happy to repeat one of my deeply help persuasions,
that the functionality of RFC2711 can only be achieved in deployments
if we would at least replace it with a functional equivalent new options
 type number RFC amended with something like:

  IPv6 nodes supporting this "new router alert option" MUST process
  packets with this option and a specific "Value" at the same speed as 
  packets without this option and "Value", unless the "Value" functionality
  for this router is explicitly configured/enabled on the router. Any
  such functionality MUST not be enabled automatically.

  (value is the router alert field indicating the protocol, for those
   to lazy to look up rfc2711)

Aka: Both PGM and RSVP failed to be deployable in controlled network
that deeply desired to have them deployed for core business functions
because router implementations across multiple vendors where punting
packets with router alert whether or not they had this protocol enabled,
so it was explicitly those routers along the path that DID NOT have PGM or
RSVP supported or enabled that where killed by those router alert packets
punting. And given the absence of very strict and clear rquirements in the
RFC as to how to process such packets in rfc2711, you can hardly blame the
implementors (ok. i do, but then my expectations about implementations
 are probably too high).

I am mentioning this as food for thought that bad RFC and resulting bad
implementations can burn a perfectly good idea and that the only
way out may be to redo it. I am persuaded this is the case with router alert.

If i where to find enough passion to propose this and it would get
through the resistance of status-quo-maintenance, i would also make
sure to immediatly have a YANG model to go along with the spec as an
RFC so that there is full diagnostics and common configurability of this
behavior, because the absence of this has also driven operators mad in
the past and simply lead to filtering of all packets with router alert.

I also more broadly think it would be good if we had a better model,
definition and common agreement of what the heck "the forwarding plane" is.
I dont think we (IETF) have that yet. That makes it difficult for
attempts like the one this draft seems to be to come up with useful
distinctions.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 9 Jul 2020 08:29:46 +0000

Hi Tom,

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, July 8, 2020 10:38 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; Bob Hinden <[email-masked]>; [email-masked]
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Peng,

Yes, but my question was about more control options. If all the HBH options are going to be forwarding options anyway then it seems like the effect of the draft is more to replace to Hop-by-Hop extension headers with some new equivalent. That might be the intent, and I suppose the logic is that if we start over from scratch then maybe the "mistakes" in the design of Hop-by-Hop options can be rectified, but as Bob said a new header would be prohibited by RFC8200.

[Shuping] We only focus on the forwarding options in this draft. For the control options, they can still be carried in the HBH header as defined in RFC8200.

Additionally, the implicit assumption in the draft in referencing
RFC7872 is that a new extension header would be dropped less often by intermediate nodes; I'm don't see much basis for that. RFC7872 shows that Destination Options and Fragment Headers are also dropped at significant rates, where HBH is dropped more than FH which is dropped more than DO. We can postulate a possible reason FH is dropped more than DO is that nodes doing filtering can't parse beyond the fragment header therefore drop packets for security. Devices wouldn't be able to parse beyond a new extension header either, and the fact it's an unknown protocol increases likelihood of drops with a security justification. I'd guess that we should expect packets with new EH to have drop rates at least that of FH maybe higher.

[Shuping] We don’t have this " implicit assumption" in the draft. If it has made you such confusion, would you like to suggest how to revise? Thank you! 

Tom

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 9 Jul 2020 09:11:25 +0000

Hi Brian, 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, July 9, 2020 10:21 AM
To: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Cc: [email-masked]; Bob Hinden <[email-masked]>
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

[Shuping] Our focus is on the forwarding options. We don’t want to treat the control options differently, which can still be carried within the current HBH Options Header (Next header = 0) and follow the specification in RFC8200 and common configuration in the fields as it is now, i.e. being sent to the "slow" path. This also aligns with what is required by the control options. 

"As a result of these concerns,
and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet."

"The RPL Option provides a mechanism to include routing information with each datagram that a router forwards.  When receiving datagrams that include routing information, RPL routers process the routing information to help maintain the routing topology."

[Shuping] Same from RFC6553: "The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. " This option is carried in the data plane datagram. So if we send many such datagram to the "slow" path, it will form a DOS attack to the control plane. Due to the rate limitation caused, it will cause inconsistent packet drop which actually impact the normal IP forwarding. The network service is disturbed. 

[Shuping] For the classification of the list of the HBH options in the Appendix and other missing HBH options, we are open for comments and suggestions. Thank you!

Best regards,
Shuping

Regards
    Brian

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 9 Jul 2020 09:30:31 +0000

Hi Toerless, 

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Thursday, July 9, 2020 1:07 PM
To: Brian E Carpenter <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]; [email-masked]; Bob Hinden <[email-masked]>
Subject: Re: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

...
...
> In any case, my understanding has always been that high performance routers have always treated this as a signal to send the packet to the "slow" path, so I don't quite understand the advantage of…

Bingo. And i am happy to repeat one of my deeply help persuasions, that the functionality of RFC2711 can only be achieved in deployments if we would at least replace it with a functional equivalent new options  type number RFC amended with something like:

Aka: Both PGM and RSVP failed to be deployable in controlled network that deeply desired to have them deployed for core business functions because router implementations across multiple vendors where punting packets with router alert whether or not they had this protocol enabled, so it was explicitly those routers along the path that DID NOT have PGM or RSVP supported or enabled that where killed by those router alert packets punting. And given the absence of very strict and clear rquirements in the RFC as to how to process such packets in rfc2711, you can hardly blame the implementors (ok. i do, but then my expectations about implementations  are probably too high).

I am mentioning this as food for thought that bad RFC and resulting bad implementations can burn a perfectly good idea and that the only way out may be to redo it. I am persuaded this is the case with router alert.

If i where to find enough passion to propose this and it would get through the resistance of status-quo-maintenance, i would also make sure to immediatly have a YANG model to go along with the spec as an RFC so that there is full diagnostics and common configurability of this behavior, because the absence of this has also driven operators mad in the past and simply lead to filtering of all packets with router alert.

I also more broadly think it would be good if we had a better model, definition and common agreement of what the heck "the forwarding plane" is.
I dont think we (IETF) have that yet. That makes it difficult for attempts like the one this draft seems to be to come up with useful distinctions.

[Shuping] Many modern routers maintain a separation between forwarding plane and control plane. The forwarding plane of a modern router is what we are referring to here. But thank you for pointing this out. I am also planning to add in the Terminology section the definitions on "forwarding plane" and "control plane", "forwarding options" and "control options". I checked through IETF documents and there are some definitions in different contexts. It would be good to have them in this draft. If there is any suggestion on those terminologies, please let us know. Thank you! 

Best regards, 
Shuping

Cheers
    Toerless

> (The Jumbo payload option is not really an exception to this, since as 
> well as doing the longest match, the router must check that the 
> outbound link supports the required MTU. Anyway, since the packet size 
> by definition exceeds 65,575 bytes, nobody will really care about some 
> overhead. Also, like most of the defined HbH options, it's a 
> limited-domain option.)
> 
> Regards
>     Brian
> 
> 
> 
> 
> 

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Jul 2020 11:39:28 +0200

> [Shuping] Many modern routers maintain a separation between forwarding plane and control plane. The forwarding plane of a modern router is what we are referring to here. But thank you for pointing…

Would be interesting to see how you think "forwarding plane" is distinguished
from "data plane".

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 9 Jul 2020 10:06:35 +0000

> Sent: Thursday, July 9, 2020 5:39 PM
> Cc: Brian E Carpenter <[email-masked]>;
> [email-masked]; [email-masked]; Bob Hinden
> <[email-masked]>
> > I dont think we (IETF) have that yet. That makes it difficult for attempts like
> the one this draft seems to be to come up with useful distinctions.
> >
> > [Shuping] Many modern routers maintain a separation between forwarding
> plane and control plane. The forwarding plane of a modern router is what
> we are referring to here. But thank you for pointing this out. I am also
> planning to add in the Terminology section the definitions on "forwarding
> plane" and "control plane", "forwarding options" and "control options". I
> checked through IETF documents and there are some definitions in different
> contexts. It would be good to have them in this draft. If there is any
> suggestion on those terminologies, please let us know. Thank you!
> 
> Would be interesting to see how you think "forwarding plane" is
> distinguished from "data plane".

We only used "forwarding plane" not "data plane" in this draft. In the context of this draft, from the perspective of the separation of the control plane and forwarding plane of a modern router, they could be taken as the same.

> 
> Cheers
>     Toerless
> 
> > Best regards,
> > Shuping
> >
> >
> > Cheers
> >     Toerless
> >
> > >
> > > Quickstart is an Experimental RFC from 13 years ago. The RFC
> unfortunately doesn't appear to state the time limit for the experiment or
> how we would evaluate the experiment, but it does say:
> > >
> > > and as a result of the difficulties and seeming absence of
> > > motivation for routers, such as core routers to deploy Quick-Start,
> > > Quick-Start is being proposed as a mechanism that could be of use in
> > > controlled environments, and not as a mechanism that would be
> > > intended or appropriate for ubiquitous deployment in the global
> Internet."
> > >
> > > I can't see how that is an action in the forwarding plane; it seems to
> describe a control plane action since it is updating the topology maps.
> > >
> > > On balance it seems to me that almost any conceivable HbH option,
> which by definition is intended for consumption by routers, is a control plane
> action, i.e. it distracts the router from its elementary job of looking for the
> longest match for the destination address in its forwarding table.
> > >
> > > (The Jumbo payload option is not really an exception to this, since
> > > as well as doing the longest match, the router must check that the
> > > outbound link supports the required MTU. Anyway, since the packet
> > > size by definition exceeds 65,575 bytes, nobody will really care
> > > about some overhead. Also, like most of the defined HbH options,
> > > it's a limited-domain option.)
> > >
> > > Regards
> > >     Brian
> > >
> > >
> > >
> > >
> > >

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Jul 2020 12:31:56 +0200

> We only used "forwarding plane" not "data plane" in this draft. In the context of this draft, from the perspective of the separation of the control plane and forwarding plane of a modern router, th…

How about inband signaling such as

https://tools.ietf.org/internet-drafts/draft-martinsen-mmusic-malice-00.txt
https://tools.ietf.org/html/draft-han-tsvwg-ip-transport-qos-03

Older experiments would punt to CPU, newer PoC would process this in the FPE ASIC.

Is this control plane if its punted and forwarding plane if its run in the FPE ?
Do you think there should be a distinction between data plane and forwarding plane 
in terminology ?

I don't think we have an agreed upon definition of what forwarding plane means.
Most likely it has been used as a stand-in for data plane, but that typically
comes from times when there was no signalling processed by FPE.

To me, forwarding plane is anything running in an FPE. 

Just saying.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Jul 2020 10:20:47 -0700

Shuping,

In that case, I really don't understand what problem this is trying to
solve. There's only two control options identified, neither of which
seem to have been deployed, but there are several forwarding options
identified. If there is merit in splitting out these to use two
different EH types, wouldn't it make more sense to move the ones in
the less common class to the new EH and keep all the forwarding
options to use Hop-by-Hop options to avoid thrashing so many protocol
specifications and implementations?

Tom

---

From: Ron Bonica <[email-masked]>
Date: Thu, 9 Jul 2020 18:08:28 +0000

Peng,

Do you really mean to make a distinction between the "fast path" and the "slow path"?

If is possible to process a forwarding plane option on the slow path. Likewise, it is possible to process a control plane option on the fast path.

                                                                                              Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, July 9, 2020 6:07 AM
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]; Bob Hinden <[email-masked]>
Subject: RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

[External Email. Be cautious of content]

> [email-masked]; [email-masked]; Bob Hinden <[email-masked]>
> > attempts like
> plane and control plane. The forwarding plane of a modern router is 
> what we are referring to here. But thank you for pointing this out. I 
> am also planning to add in the Terminology section the definitions on 
> "forwarding plane" and "control plane", "forwarding options" and 
> "control options". I checked through IETF documents and there are some 
> definitions in different contexts. It would be good to have them in 
> this draft. If there is any suggestion on those terminologies, please let us know. Thank you!
>

> unfortunately doesn't appear to state the time limit for the 
> experiment or how we would evaluate the experiment, but it does say:
> > >
> > > motivation for routers, such as core routers to deploy 
> > > Quick-Start, Quick-Start is being proposed as a mechanism that 
> > > could be of use in controlled environments, and not as a mechanism 
> > > that would be intended or appropriate for ubiquitous deployment in 
> > > the global
> Internet."
> > >
> > > Looking at the list of "Forwarding Plane" options, I see that it 
> > > includes
> the RPL option. RFC6553 says:
> > >
> > > "The RPL Option provides a mechanism to include routing 
> > > information with each datagram that a router forwards.  When 
> > > receiving datagrams that include routing information, RPL routers 
> > > process the routing information to help maintain the routing topology."
> > >
> which by definition is intended for consumption by routers, is a 
> control plane action, i.e. it distracts the router from its elementary 
> job of looking for the longest match for the destination address in its forwarding table.
> > >
> > > (The Jumbo payload option is not really an exception to this, 
> > > since as well as doing the longest match, the router must check 
> > > that the outbound link supports the required MTU. Anyway, since 
> > > the packet size by definition exceeds 65,575 bytes, nobody will 
> > > really care about some overhead. Also, like most of the defined 
> > > HbH options, it's a limited-domain option.)
> > >
> > > Regards
> > >     Brian
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [email-masked] 
> > > Administrative
> > > Requests: 
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > ipv6__;!!NEt6yMaO-gk!X7fjTemEu7P-sAil8xNdRgMAizJFIVeDksw4lQszRIxlo
> > > oRS-NgOJWtauFqu7InN$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X7fjTemEu7P-sAil8xNdRgMAizJFIVeDksw4lQszRIxlooRS-NgOJWtauFqu7InN$
--------------------------------------------------------------------

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Jul 2020 08:41:29 +0000

Hi Tom, 

> Sent: Friday, July 10, 2020 1:21 AM
> > > > The HBH forward options contain information that is useful to a
> router's forwarding plane, e.g. the Jumbo Payload Option [RFC2675]. While
> the HBH Control Options contain information that is useful to a router's
> control plane, e.g. the Router Alert Option [RFC2711].
> > > > Please also find the Appendix in this draft in which we tried to list the
> currently defined HBH Options and classify them into HBH Forwarding and
> HBH Control Options. We can see that among all the defined HBH Options
> the HBH Forwarding Options are in the majority.
> being defined in the near future? Btw, pad options should be in some sort of
> class of their own.
> > >
> > > Hi Tom,
> > >
> options are going to be forwarding options anyway then it seems like the
> effect of the draft is more to replace to Hop-by-Hop extension headers with
> some new equivalent. That might be the intent, and I suppose the logic is
> that if we start over from scratch then maybe the "mistakes" in the design of
> Hop-by-Hop options can be rectified, but as Bob said a new header would be
> prohibited by RFC8200.
> >
> > [Shuping] We only focus on the forwarding options in this draft. For the
> control options, they can still be carried in the HBH header as defined in
> RFC8200.
> >
> intermediate nodes; I'm don't see much basis for that. RFC7872 shows that
> Destination Options and Fragment Headers are also dropped at significant
> rates, where HBH is dropped more than FH which is dropped more than DO.
> We can postulate a possible reason FH is dropped more than DO is that
> nodes doing filtering can't parse beyond the fragment header therefore drop
> packets for security. Devices wouldn't be able to parse beyond a new
> extension header either, and the fact it's an unknown protocol increases
> likelihood of drops with a security justification. I'd guess that we should
> expect packets with new EH to have drop rates at least that of FH maybe
> higher.
> >
> > [Shuping] We don’t have this " implicit assumption" in the draft. If it has
> made you such confusion, would you like to suggest how to revise? Thank
> you!
> >
> 
> Shuping,
> 
> In that case, I really don't understand what problem this is trying to solve.
> There's only two control options identified, neither of which seem to have
> been deployed, but there are several forwarding options identified. If there
> is merit in splitting out these to use two different EH types, wouldn't it make
> more sense to move the ones in the less common class to the new EH and
> keep all the forwarding options to use Hop-by-Hop options to avoid
> thrashing so many protocol specifications and implementations?

The problem we are trying to solve is that there are some options that are supposed to be kept on the forwarding plane but sent to the control plane which causes DOS attack to the control plane and inconsistent packet drop disturbing the normal IP forwarding. 

The proposed new header is used to encapsulate these forwarding options. Once the devices see the new next header value TBD in the IPv6 header indicating this new HBH header, they won't drop the packets or send them to the control plane but keep them on the forwarding plane. For the legacy devices, they will skip the header so the normal IP forwarding are not disturbed. 

This proposal is not thrashing any protocol specifications and implementations except minor changes to RFC8200. The sender decides which HBH options header to use when doing encapsulation. Once the packet carrying the HBH options header is sent out, the device will decide how to handle it based on the next header value in the IPv6 header. If it is 0, then the device will perform the exact same way as it is now. If it is the value TBD, then the device will keep the packet in the forwarding plane instead of sending it to the control plane unnecessarily or even wrongly.

Best regards, 
Shuping 

> > > > > Yes, we agree that for the HBH options that are supposed to be
> processed on the forwarding plane, the HBH “slow path” processing should
> be eliminated. However, currently both forwarding options and control
> options are carried in the same HBH option header defined in RFC8200, and
> there is no effective way to differentiate them. This can be resolved with the
> proposed HBH forwarding options header that only carries the forwarding
> options and is processed on the forwarding plane.
> > > >

---

From: [email-masked]
Date: Fri, 10 Jul 2020 11:39:51 +0200

Shuping,

> This proposal is not thrashing any protocol specifications and implementations except minor changes to RFC8200. The sender decides which HBH options header to use when doing encapsulation. Once the…

Why would it ever do that?
If the router is configured to process e.g. the Path MTU record option, it will process that in the fast path, or if it is not it will ignore it. If it receives a e.g. router alert, it will punt that to software following the processing rules of any other packet to the control plane. Why is that any different to any other exception packet, if it's ND or BGP...

Cheers,
Ole

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Jul 2020 10:13:33 +0000

Hi Toreless, 

> Sent: Thursday, July 9, 2020 6:32 PM
> > We only used "forwarding plane" not "data plane" in this draft. In the
> context of this draft, from the perspective of the separation of the control
> plane and forwarding plane of a modern router, they could be taken as the
> same.
> 
> Do you think there should be a distinction between data plane and
> forwarding plane in terminology ?
> 

In the context of this draft, we take the forwarding plane of a router as the fast path, while the control plane as the slow path.

For the fast path and slow path, we refer to the terminology defined in RFC6398. 

   o  Fast path: Hardware or Application-Specific Integrated Circuit
      (ASIC) processing path for packets.  This is the nominal
      processing path within a router for IP datagrams.

   o  Slow path: Software processing path for packets.  This is a sub-
      nominal processing path for packets that require special
      processing or differ from assumptions made in fast-path
      heuristics.

It seems that these terminologies caused some misunderstanding. We need to put some text in the draft to clarify. It will be great if we could also get some help.

Best regards, 
Shuping

> > > > > could be of use in controlled environments, and not as a
> > > > > mechanism that would be intended or appropriate for ubiquitous
> > > > > deployment in the global
> > > Internet."
> > > > >
> > > > > receiving datagrams that include routing information, RPL
> > > > > routers process the routing information to help maintain the routing
> topology."
> > > > >
> > > control plane action, i.e. it distracts the router from its
> > > elementary job of looking for the longest match for the destination
> address in its forwarding table.
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ---- IETF IPv6 working group mailing list [email-masked]
> > > > > Administrative

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Jul 2020 10:13:49 +0000

Hi Ron,

> From: Ron Bonica [mailto:[email-masked]]
> Sent: Friday, July 10, 2020 2:08 AM
> To: Pengshuping (Peng Shuping) <[email-masked]>; Toerless
> Eckert <[email-masked]>

We aim to let the option get the handling that is appropriate to it, that is, to be processed on either the "fast path" or "slow path".

> 
> If is possible to process a forwarding plane option on the slow path. Likewise,

Yes, but this actually causes the problem which we are trying to solve here. The forwarding option carrying in the data packets is supposed to be kept in the fast path but if sent to the slow path, it will cause DOS attack.

> it is possible to process a control plane option on the fast path.

This is ok. But the information carried in a control option is supposed to be consumed by the control plane, so even if it is processed in the fast path, it will still be sent to the control plane eventually. 

Best Regards,
Shuping

> > definition and common agreement of what the heck "the forwarding
> plane"
> > is.
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;
> !!NEt6yMaO-gk!X7fjTemEu7P-sAil8xNdRgMAizJFIVeDksw4lQszRIxlooRS-NgO
> JWtauFqu7InN$

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Jul 2020 10:33:18 +0000

Hi Ole, 

> Sent: Friday, July 10, 2020 5:40 PM
> > This proposal is not thrashing any protocol specifications and
> implementations except minor changes to RFC8200. The sender decides
> which HBH options header to use when doing encapsulation. Once the
> packet carrying the HBH options header is sent out, the device will decide
> how to handle it based on the next header value in the IPv6 header. If it is 0,
> then the device will perform the exact same way as it is now. If it is the value
> TBD, then the device will keep the packet in the forwarding plane instead of
> sending it to the control plane unnecessarily or even wrongly.
> 
> If the router is configured to process e.g. the Path MTU record option, it will
> process that in the fast path, or if it is not it will ignore it. If it receives a e.g.
> router alert, it will punt that to software following the processing rules of
> any other packet to the control plane. Why is that any different to any other
> exception packet, if it's ND or BGP...

What you have described is that everything is based on configuration. However, there are some devices cannot be reconfigured once the configuration is embedded in the devices, and the default configuration is to send to the slow path which causes troubles.

Even if it can be configured, it did not say how to process, either on the fast path or slow path? On default every packet carrying the HBH is sent to the slow path.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jul 2020 14:59:06 +0000

Peng,

While your solution may require refinement, I think that you have latched on to a problem that needs to be solved. HBH Options, as they were originally conceived in RFC 1883, are very useful.

When IPv6 was first implemented on high-speed routers (circa 2000), HBH options were not yet well-understood and ASICs were not so capable as they are today. So, early IPv6 implementation dispatched all packet that contain HBH options to their slow path. In these implementations, a large flow of IPv6 packets could congest the slow path, causing other critical functions that are executed on the slow path to fail. These critical functions include routing and network management.

To mitigate this DoS vulnerability, many operators deployed Access Control Lists (ACLs) that discard all packets containing HBH Options. This introduced a circular problem:

- An implementation problem caused HBH to become a DoS vector
- Because HBH was a DoS vector, network operators deployed ACLs that discard packets containing HBH
- Because network operators deployed ACLs that discard packets containing HBH, network designers stopped defining new HBH Options
- Because network designers stopped defining new HBH Options, the community was not motivated to fix the implementation problem that cause HBH to become a DoS vector

If we can fix the implementation problem that caused HBH to become a DoS vector, we can break this cycle and start using HBH Options.

Let's continue to work on a solution.

                                                         Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, July 2, 2020 12:07 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Hi Folks,

Best regards,
Shuping

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 2, 2020 11:31 PM
To: Lizhenbin <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>
Subject: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Name:           draft-li-6man-hbh-fwd-hdr
Revision:       00
Title:          Hop-by-Hop Forwarding Options Header
Document date:  2020-07-03
Group:          Individual Submission
Pages:          10
URL:            https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$
Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$
Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgPvsH43l$
Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li-6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$

Abstract:

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgEBbFhyl$
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 08:01:51 -0700

Shuping,

That may be true for some implementations or maybe your
implementation, but it's not true for all implementations, and nowhere
in RFC8200 or any other RFC will you find this a requirement or even
normative definitions of "slow path" and "fast path". In particular, a
host networking stack doesn't do this, options are just processed in
the data path. But note that if  someone starts sending a new
extension header to a host then we MUST update the host stack  lest we
can't  correctly parse the packet. So this proposal is asking us to
modify all  host implementations to solve a perceived problem for some
routers.

If  routers are being DOSed by receiving certain HBH options, IMO that
is an implementation issue in the routers and not a protocol problem
that needs to be fixed in IETF!

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Jul 2020 15:31:49 +0000

Hi Ron, 

Thank you for explaining the history and the cause factors behind this very clearly. 

It is great that you are willing to tackle this problem together! :)

Best regards, 
Shuping 

> Sent: Friday, July 10, 2020 10:59 PM
> To: Pengshuping (Peng Shuping) <[email-masked]>;
> [email-masked]
> While your solution may require refinement, I think that you have latched on
> to a problem that needs to be solved. HBH Options, as they were originally
> conceived in RFC 1883, are very useful.
> 
> When IPv6 was first implemented on high-speed routers (circa 2000), HBH
> options were not yet well-understood and ASICs were not so capable as they
> are today. So, early IPv6 implementation dispatched all packet that contain
> HBH options to their slow path. In these implementations, a large flow of
> IPv6 packets could congest the slow path, causing other critical functions
> that are executed on the slow path to fail. These critical functions include
> routing and network management.
> 
> To mitigate this DoS vulnerability, many operators deployed Access Control
> Lists (ACLs) that discard all packets containing HBH Options. This introduced
> a circular problem:
> 
> - Because network operators deployed ACLs that discard packets containing
> HBH, network designers stopped defining new HBH Options
> - Because network designers stopped defining new HBH Options, the
> community was not motivated to fix the implementation problem that cause
> HBH to become a DoS vector
> 
> If we can fix the implementation problem that caused HBH to become a DoS
> vector, we can break this cycle and start using HBH Options.
> 
> We have just uploaded a new draft aiming to analyze and tackle the issues
> faced by the Hop-by-Hop Options Header, which has been sparsely used
> without any form of large scale deployment.
> 
> However, as IPv6 is being rapidly and widely deployed worldwide, more and
> more new services that requires hop-by-hop forwarding process behavior
> are emerging, and also the already defined over ten HBH Options are going
> to be used widely in practice.
> 
> We look forward to hearing your feedback and comments, and try to release
> the benefits that could be provided by HBH Options header altogether.
> 
> Best regards,
> Shuping
> 
> A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has been successfully
> submitted by Shuping Peng and posted to the IETF repository.
> 
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6
> man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00d
> bzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man-
> hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S
> 4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$
> Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-f
> wd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4C
> G2fZYHGYeOXYwVmtNTFnzgPvsH43l$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li-
> 6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuC
> mO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$
> 
> 
> Abstract:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> !!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOX
> YwVmtNTFnzgEBbFhyl$

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Jul 2020 08:58:58 -0700

> On Jul 10, 2020, at 2:39 AM, [email-masked] wrote:
> 
> Shuping,
> 
> If the router is configured to process e.g. the Path MTU record option, it will process that in the fast path, or if it is not it will ignore it. If it receives a e.g. router alert, it will punt that to software following the processing rules of any other packet to the control plane. Why is that any different to any other exception packet, if it's ND or BGP…

I agree.

I note the issues with HBH opions is an implementation problem, not a protocol problem.   Defining new hbh options does not fix the underlying issues with HBH options, I think it might actually make it worse.   The current HBH design (always first option header, indicated by 0, etc.) is quite good.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 10:13:25 -0700

> If we can fix the implementation problem that caused HBH to become a DoS vector, we can break this cycle and start using HBH Options.
Ron,

I think there were "protocol problems" in the original design of HBH.
The requirement that _all_ routers in the path process Hop-by-Hop
options was in retrospect too austere, and the possibility that an
attacker could stuff a packet with hundreds of bogus options, only
limited by MTU, was, again in retrospect, a pretty obvious DOS vector.
I believe these problems have been addressed in RFC8200 and RFC8504.
We certainly welcome the feedback from router vendors whether these
mitigations are sufficient to make HBH options deployable.

Tom