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

From: Ron Bonica <[email-masked]>
Date: Thu, 9 Sep 2021 17:10:50 +0000

Folks,

This message initiates a call for adoption for draft-peng-v6ops-hbh (https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/).

Please post comments by September 24, 2021.

                                                                   Fred and Ron

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2021 09:08:31 +1200

I'm afraid I don't understand at all what this draft proposes. To be explicit:

>  8. Migration Strategies 

Migration from what to what?

> 1. The source of the HBH options header encapsulation.The information to be carried in the HBH options header needs to be first categorized and encapsulated into either control options or forwarding options, and then encapsulated in different packets.
...
> The edge nodes should check whether the packet contains an HBH header with control or forwarding option. 
What different packets? How are control and forwarding options distinguished? Is this proposal suggesting two kinds of HBH option? If so it belongs in 6man. If not, I have no idea what it actually suggests. 

Regards
   Brian

On 10-Sep-21 05:10, Ron Bonica wrote:
> Folks,
> 
>  
> 
> This message initiates a call for adoption for draft-peng-v6ops-hbh (https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/ <https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/>).
> 
>  
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Sep 2021 17:15:24 -0400

On Thu, Sep 9, 2021 at 1:11 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
>
>
> This message initiates a call for adoption for draft-peng-v6ops-hbh (
> https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/).
>

<no hats>
I've read this document, and I think that it provides useful background and
level-setting information. I don't think that there is a huge amount of
brand new information (other than Sec 7, 8), but the background on how
devices actually operate, summaries, references, background (Sec 1, 2, 4,
5, 6) make it worthwhile.
Even if it never becomes an RFC, I personally think it is worth adoption -
it clearly needs work (Sec 7 may be overly prescriptive, and Sec 8 seems
unclear/unfinished and possibly reaching into 6man space), but even just
having a document which collects and summarizes existing information, and
gives everyone to the same place to stand is useful.

W

>                                                                    Fred
> and Ron

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Huzhibo <[email-masked]>
Date: Fri, 10 Sep 2021 07:13:43 +0000

Reasonable HBH processing is very useful in various scenarios such as Alternate-Marking (draft-ietf-6man-ipv6-alt-mark-09) and PMTU (draft-ietf-6man-mtu-option-08).
Therefore, I support WG adoption of this document.

Thank you!

Zhibo Hu
From: v6ops [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Friday, September 10, 2021 1:11 AM
To: [email-masked]
Subject: [v6ops] Call for adoption: draft-peng-v6ops-hbh

Folks,

                                                                   Fred and Ron

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 10 Sep 2021 07:43:41 +0000

Hi WG,

I support the adoption of the document.

Thanks
Jingrong

Folks,

                                                                   Fred and Ron

---

From: Stefano Previdi <[email-masked]>
Date: Fri, 10 Sep 2021 11:07:38 +0200

Hi,

As mentioned by the authors, the draft still require some work but I also agree that it’s useful to have a document reporting the current HBH deployment and behavior as well as the requirements for a better HBH solution.

I therefore support the adoption of this draft.

Thanks.
s.

> On Sep 9, 2021, at 7:10 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>

---

From: [email-masked]
Date: Fri, 10 Sep 2021 11:10:27 +0200

We have:
draft-ietf-6man-hbh-header-handling-03
IPv6 Hop-by-Hop Options Extension Header

That in combination with RFC7045 led up to the relaxed rules for processing of HBH in RFC8200.

There's also:
draft-hinden-6man-hbh-processing-01
IPv6 Hop-by-Hop Options Processing Procedures

And then this draft which draft-peng-v6ops-hbh seems to be still referring to as it's hinting at "control plane" and "data plane" HBH options.
draft-li-6man-hbh-fwd-hdr-01
Hop-by-Hop Forwarding Options Header

What I struggle with for draft-peng-v6ops-hbh is figuring out what it says that hasn't already been said before.

O.

> On 9 Sep 2021, at 19:10, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 10 Sep 2021 10:19:01 +0000

Hi Warren,

Thank you for your support!

I agree that some text in Section 8 needs to be revised especially those seem to be related to the solutions since this draft only focuses on requirements.

We could further work on the requirements listed in Section 7 altogether, which was the intention.

Thank you!

Best regards,
Shuping

From: v6ops [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Friday, September 10, 2021 5:15 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Call for adoption: draft-peng-v6ops-hbh

On Thu, Sep 9, 2021 at 1:11 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

<no hats>
I've read this document, and I think that it provides useful background and level-setting information. I don't think that there is a huge amount of brand new information (other than Sec 7, 8), but the background on how devices actually operate, summaries, references, background (Sec 1, 2, 4, 5, 6) make it worthwhile.
Even if it never becomes an RFC, I personally think it is worth adoption - it clearly needs work (Sec 7 may be overly prescriptive, and Sec 8 seems unclear/unfinished and possibly reaching into 6man space), but even just having a document which collects and summarizes existing information, and gives everyone to the same place to stand is useful.

W

                                                                   Fred and Ron

Juniper Business Use Only
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 10 Sep 2021 10:41:57 +0000

I support the adoption.

The document is an useful informational draft to describe the current status and issues of IPv6 HBH processing from different aspects or angles, so it can be taken as a good base for discussing how to solve the IPv6 HBH processing issues further.

To my understanding, this draft focuses on the requirements only not solutions.

Section 8 seems to provide some migration strategies that aim to provide a guidance for deploying the HBH options header that satisfies the requirements stated in section 7.

Btw, may be better to add more info to the title of each section?  Will help the readers to understand the draft better.

Thanks,
Cheng

________________________________

Email: [email-masked]<mailto:[email-masked]>
发件人：Ron Bonica <rbonica=[email-masked]>
收件人：v6ops <[email-masked]>
时 间：2021-09-10 01:11:41
主 题：[v6ops] Call for adoption: draft-peng-v6ops-hbh

Folks,

                                                                   Fred and Ron

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Sep 2021 09:12:32 -0400

On Fri, Sep 10, 2021 at 5:10 AM <[email-masked]> wrote:

> And then this draft which draft-peng-v6ops-hbh seems to be still referring
> to as it's hinting at "control plane" and "data plane" HBH options.

Not a whole heck of a lot -- but it does (IMO) collect and collate a bunch
of existing information in one place. It seems to me that, in many of the
HbH discussions, we have people with very different views of what the
elephant looks like, and having a level-setting document is useful. This
document also has a bunch of "how a modern router works" information (for
some version of 'modern' and 'router') - much of this isn't really
explained on other documents (at least, not easily findable); it might have
been presented in things like the TDD session on "Modern Router
Architectures", but that's not really the same thing. So, in some ways I'm
viewing this as a 'hitch-hikers guide' or 'problem statement and
requirements' type document.

Not trying to sway your view, just explaining my position,
W

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Sep 2021 09:33:40 -0400

I support WG adoption.

There have been many documents written describing issues related to HBH
processing in the past.  This drafts focus is on the culmination of all
drafts of the past that had attempted to define this real world problem
related to HBH header processing, and now finally a draft that can pave the
way for any and all HBH processing solutions to facilitate breaking the
endless cycle that has transformed HBH into a DDOS vector.

Now more so than ever, we have many and growing use cases for developers to
leverage the use of a line rate HBH forwarding plane processing tool in the
developers toolbox, that can finally come to fruition, from IOAM, PMTUD,
Alt Mark telemetry to future work across all IETF WGs from transport to
routing area, to TEAS, PCE, SFC, BIER and beyond.

Sky’s the limit on what we all at the IETF can dream up for HBH line rate
processing tools.

This draft will now help bring the WG together on 6MAN to help focus on
coming up with the best possible solutions for the foreseeable future of
HBH line rate processing tools so that operators around the globe can
finally reap the tremendous benefits.

Kind Regards

Gyan

On Fri, Sep 10, 2021 at 6:42 AM Chengli (Cheng Li) <[email-masked]> wrote:

> I support the adoption.
>
> The document is an useful informational draft to describe the current
> status and issues of IPv6 HBH processing from different aspects or angles,
> so it can be taken as a good base for discussing how to solve the IPv6 HBH
> processing issues further.
>
> Section 8 seems to provide some migration strategies that aim to provide a
> guidance for deploying the HBH options header that satisfies the
> requirements stated in section 7.
>
> Btw, may be better to add more info to the title of each section?  Will
> help the readers to understand the draft better.
>
> Thanks,
> Cheng
>
>
> ------------------------------
>
> Email: [email-masked]
> *发件人：*Ron Bonica <rbonica=[email-masked]>
> *收件人：*v6ops <[email-masked]>
> *时 间：*2021-09-10 01:11:41
> *主 题：*[v6ops] Call for adoption: draft-peng-v6ops-hbh
>
> Folks,
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Sep 2021 16:00:16 -0700

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.

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.

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Sep 2021 16:49:32 -0700

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

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

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Sep 2021 22:30:04 -0400

Hi Bob

Many thanks for your comments and feedback on this draft.

Responses in-line

Kind Regards

Gyan
On Fri, Sep 10, 2021 at 7:01 PM Bob Hinden <[email-masked]> 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:
>
> 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.
>

    Gyan> Agreed

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

    Gyan> Yes, we can work together on improving the situation with HBH.

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

   Gyan> Thank you for the suggestion and we will update,

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

    Gyan> As we wanted to cover all hardware architectures we will add
software based platforms. Thanks for mentioning.

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

     Gyan>  Understand.  We will clean up the verbiage.

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

Gyan> Good point.  We will reword and remove mention of DDOS vector.

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

    Gyan> Good point as well.

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

    Gyan>  We will work on revamping this section.  Do you have any
requirements that you would like to add to an HBH solution?

> It talks about characterizing options into either control options or
> forward options.   We only have HBH Options, not two types.
>
> 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.

    Gyan> We have discussed cleaning up this section or removing and now
based on feedback we are leaning towards removing.

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Sat, 11 Sep 2021 04:00:56 +0000

Dear Brian, 

Our main purpose of this work, as we presented in the IETF meetings, is to ultimately 
1. Break the endless cycle that resulted in HBH to become a DOS vector.
2. Enable the HBH options header to be utilized in a safe/secure way without impacting the management plane.
3. Ease the deployments of the new HBH based network services in a multi-vendor/operator’s scenario that can now be deployed without operational impact.

This document acts as a requirement document and not a solution document so the purpose is to describe the current state and what needs to be fixed.

As you pointed out, we agree that the purpose is not very clear now, we will extend the introduction section that currently has a small paragraph on the purpose of this draft, and add more information to make it more clear. It will also be reflected in the abstract. 

Thank you for your comments to help us to improve the draft.

Best regards, 
Shuping 

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Friday, September 10, 2021 5:09 AM
> To: Ron Bonica <rbonica=[email-masked]>; [email-masked]
> > 1. The source of the HBH options header encapsulation.The information to
> be carried in the HBH options header needs to be first categorized and
> encapsulated into either control options or forwarding options, and then
> encapsulated in different packets.
> ...
> What different packets? How are control and forwarding options
> distinguished? Is this proposal suggesting two kinds of HBH option? If so it
> belongs in 6man. If not, I have no idea what it actually suggests.
> 
> Regards
>    Brian
> 
> > This message initiates a call for adoption for draft-peng-v6ops-hbh
> (https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/
> <https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/>).
> >
> >
> >

---

From: Chongfeng Xie <[email-masked]>
Date: Sat, 11 Sep 2021 17:39:25 +0800

Hi，folks，
As a co-author，I support the adoption of this draft. I think the HBH option header can be considered as a valuable container for carrying the information facilitating the introduction of new services or meeting other demands.

Best regards
Chongfeng

> 2021年9月10日 上午1:10，Ron Bonica <rbonica=[email-masked]> 写道：
> 
> Folks,
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Sep 2021 09:38:17 +1200

Hi Shuping,

Thanks. I think that Gorry Fairhurst's comments express exactly what I want to say. I support adoption, subject to those comments.

Regards
   Brian

On 11-Sep-21 16:00, Pengshuping (Peng Shuping) wrote:
> As you pointed out, we agree that the purpose is not very clear now, we 
will extend the introduction section that currently has a small paragraph 
on the purpose of this draft, and add more information to make it more clear. It will also be reflected in the abstract.

---

From: Bob Hinden <[email-masked]>
Date: Sun, 12 Sep 2021 09:14:37 -0700

Gyan,

Thanks, a few points below.

Bob

> On Sep 10, 2021, at 7:30 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Hi Bob
> 

……..

> Gyan> Good point.  We will reword and remove mention of DDOS vector.

We clearly want to reduce the possibility of the HBH option header to be used as a DDOS vector, but the way this was written it would be impossible to meet.    It’s still good to mention DDOS, but it needs better scoping.

>     Gyan>  We will work on revamping this section.  Do you have any requirements that you would like to add to an HBH solution?

Perhaps take a look at  draft-hinden-6man-hbh-processing-01 and draft-herbert-6man-eh-limits.  These are written with solutions in mind, but they do infer requirements.

>     Gyan> We have discussed cleaning up this section or removing and now based on feedback we are leaning towards removing.

I would support that.

---

From: Lizhenbin <[email-masked]>
Date: Mon, 13 Sep 2021 06:50:16 +0000

Hi All,
I support the adoption of the draft as the co-author.

Best Regards,
Zhenbin (Robin)

Folks,

                                                                   Fred and Ron

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 13 Sep 2021 10:35:36 +0000

Dear Brian, 

Many thanks for your support and those comments. 

I will reply to Gorry separately. 

Thank you! 

Best regards, 
Shuping 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, September 12, 2021 5:38 AM
To: Pengshuping (Peng Shuping) <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] Call for adoption: draft-peng-v6ops-hbh

Hi Shuping,

Regards
   Brian

On 11-Sep-21 16:00, Pengshuping (Peng Shuping) wrote:
> Dear Brian,
> 
> Our main purpose of this work, as we presented in the IETF meetings, 
> is
to ultimately 
> As you pointed out, we agree that the purpose is not very clear now, 
will extend the introduction section that currently has a small paragraph on the purpose of this draft, and add more information to make it more clear. It will also be reflected in the abstract. 
>>> 1. The source of the HBH options header encapsulation.The 
>>> information
to
>> be carried in the HBH options header needs to be first categorized 
>> and encapsulated into either control options or forwarding options, 
>> and then encapsulated in different packets.
>> ...
>>> The edge nodes should check whether the packet contains an HBH 
>>> header
>> with control or forwarding option.
>> distinguished? Is this proposal suggesting two kinds of HBH option? 
>> If
so it

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 15 Sep 2021 20:09:42 -0400

Hi Bob

Responses in-line

Many Thanks

Gyan

On Sun, Sep 12, 2021 at 12:14 PM Bob Hinden <[email-masked]> wrote:

> We clearly want to reduce the possibility of the HBH option header to be
> used as a DDOS vector, but the way this was written it would be impossible
> to meet.    It’s still good to mention DDOS, but it needs better scoping.
>

    Gyan> Thanks for the clarification.  Rewrite - HBH options usage should
not result in an DDOS attack vector as a result of control plane processing
of packets that should be processed in the forwarding plane.

> Perhaps take a look at  draft-hinden-6man-hbh-processing-01 and
> draft-herbert-6man-eh-limits.  These are written with solutions in mind,
> but they do infer requirements.

Gyan> Will do.  Thank you

> based on feedback we are leaning towards removing.

   Gyan> Thank you

*Gyan Mishra*

*M 301 502-1347*

---

From: Ron Bonica <[email-masked]>
Date: Mon, 27 Sep 2021 01:38:14 +0000

Folks,

This message ends the call for adoption with consensus to adopt.

Authors,

Please address the comments received during the call for adoption and resubmit the draft as draft-ietf-v6ops-hbh-00. When you submit the draft, please indicate that it replaces draft-peng-v6ops-hbh.

                                                                                                            Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Thursday, September 9, 2021 1:11 PM
To: [email-masked]
Subject: Call for adoption: draft-peng-v6ops-hbh

Folks,

                                                                   Fred and Ron