Subject: Re: Adoption call on HBH drafts

From: "喻海生" <[email-masked]>
Date: Tue, 14 Dec 2021 15:15:41 +0800

Dear Ron,

&nbsp; &nbsp; &nbsp; &nbsp; For Part 2, my opinion is as follows：
&nbsp; &nbsp; &nbsp; &nbsp; One of the most important advantages of IPv6 compared to IPv4 is that IPv6 has good programmability and can use extension headers flexibly. Among them, the HBH extension header is the most outstanding representative, because other extension headers are only processed in the source node and the destination node. HBH extension header is the only extension header that can be processed at the intermediate node.&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; In the past, due to the low overall utilization rate of IPv6 networks, there were few innovations based on IPv6 networks. In recent years, with the development of IPv6, innovations based on IPv6 extension headers have also increased substantially. HBH is the representative of the IPv6 extension header. Due to historical reasons, the HBH extension header has been abandoned for fear of becoming a carrier of DOS attacks. At present, it has come to the era of innovation and reproduction of brilliance for the use of HBH extension headers and IPv6.

Haisheng Yu(Johnson)
BIIGroup&nbsp;

[email-masked]

On&nbsp;12/14/2021 05:56，Ron Bonica<rbonica=[email-masked]&gt;&nbsp;wrote：

Brian,

Your case has two parts:

1) HBH is a great success as it is today
2) the fact that it doesn't work across the open Internet is unimportant

Although 1) may be true, it does not imply 2).

Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]&gt; On Behalf Of Brian E Carpenter
Sent: Monday, December 13, 2021 2:36 PM
To:&nbsp;[email-masked]
Subject: Re: Adoption call on HBH drafts

[External Email. Be cautious of content]

So, there's a case for saying that HBH is a great success as it is today, and the fact that it doesn't work across the open Internet is unimportant. (We under-estimated this in RFC8799, for example completely missing RFC6553.)

Regards
Brian

On 13-Dec-21 23:29, Pascal Thubert (pthubert) wrote:
See also RFC 6553 (used by millions of deployed nodes in IoT networks)&nbsp;
and&nbsp;
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
t-pthubert-detnet-ipv6-hbh__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz
3MrkdNBKegkJwJJdIYFGRq-UCUCd3fjJP_Fsw$ ,
which allows ot signal DetNet at L3, the alternate being above UDP.

Keep safe;

Pascal

-----Original Message-----
From: ipv6 <[email-masked]&gt; On Behalf Of&nbsp;[email-masked]
Sent: lundi 13 décembre 2021 10:30
To: Gyan Mishra <[email-masked]&gt;
Cc: 6man WG <[email-masked]&gt;; 6man Chairs <[email-masked]&gt;
Subject: Re: Adoption call on HBH drafts

There are successful uses of the HBH header within limited domains,&nbsp;
and considering all the work that already went in on HBH for RFC8200.
Is there anything more the IETF can or should do?

Gyan&gt; Can you point to documentation or drafts &nbsp;of &nbsp;limited&nbsp;
domains
HBH usage? &nbsp;I was not aware of any that exist.

I was thinking of:

IOAM in:&nbsp;
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
tf-ippm-ioam-ipv6-__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz3MrkdNB
KegkJwJJdIYFGRq-UCUCd3fsgkKY1M$
options/06/
AltMark:&nbsp;
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
tf-6man-ipv6-alt-mark/__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz3Mr
kdNBKegkJwJJdIYFGRq-UCUCd3fhPmGauV$

Cheers,
Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests:&nbsp;
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz3MrkdNBKegkJwJJdIYFGRq-UCU
Cd3fkRDXrFC$
--------------------------------------------------------------------

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 14 Dec 2021 07:58:52 -0800

On Mon, Dec 13, 2021 at 11:23 PM 喻海生 <[email-masked]> wrote:

> Dear Ron,
>
>         For Part 2, my opinion is as follows：
>         One of the most important advantages of IPv6 compared to IPv4 is
> that IPv6 has good programmability and can use extension headers flexibly.
> Among them, the HBH extension header is the most outstanding
> representative, because other extension headers are only processed in the
> source node and the destination node. HBH extension header is the only
> extension header that can be processed at the intermediate node.
>         In the past, due to the low overall utilization rate of IPv6
> networks, there were few innovations based on IPv6 networks. In recent
> years, with the development of IPv6, innovations based on IPv6 extension
> headers have also increased substantially. HBH is the representative of the
> IPv6 extension header. Due to historical reasons, the HBH extension header
> has been abandoned for fear of becoming a carrier of DOS attacks. At
> present, it has come to the era of innovation and reproduction of
> brilliance for the use of HBH extension headers and IPv6.
>

Well said. IMO, Hop-by-Hop extension header is *the* extensible mechanism
in IPv6 that allows the host to signal the network and vice versa. The need
for such signaling is known and the suggested alternatives to HbH options
are overloading flow label, embedding information in IPv6 addresses,
putting networking layer information in transport layer like the spin bit
in QUIC-- all of those are hacks that at best address a few short term
point problems and only increase ossification of the Internet. I fear that
if we abandon HbH options, even outside of limited domains, then we are
conceding that the Internet is no longer a platform for innovation and
evolution at least at the networking layer.

Tom

>
> Haisheng Yu(Johnson)
> BIIGroup
> [email-masked]
>
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=Haisheng+Yu%28Johnson%29&uid=yhsyhs8983%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%22%2C%22yhsyhs8983%40163.com%22%2C%22%22%2C%22%22%2C%22%22%5D>
>
> On 12/14/2021 05:56，Ron Bonica<rbonica=[email-masked]>
> <rbonica=[email-masked]> wrote：
>
> Brian,
>
> Your case has two parts:
>
> From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
> To: [email-masked]
> So, there's a case for saying that HBH is a great success as it is today,
> and the fact that it doesn't work across the open Internet is unimportant.
> (We under-estimated this in RFC8799, for example completely missing
> RFC6553.)
>
> Regards
> Brian
>
> See also RFC 6553 (used by millions of deployed nodes in IoT networks)
> and
> From: ipv6 <[email-masked]> On Behalf Of [email-masked]
> To: Gyan Mishra <[email-masked]>
> Cc: 6man WG <[email-masked]>; 6man Chairs <[email-masked]>
> There are successful uses of the HBH header within limited domains,
> Gyan> Can you point to documentation or drafts  of  limited
> domains
>
> HBH usage?  I was not aware of any that exist.
>
> I was thinking of:
>
> IOAM in:
> AltMark:
> Administrative Requests:
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz3MrkdNBKegkJwJJdIYFGRq-UCUCd3fkRDXrFC$

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Dec 2021 16:26:09 +0000

+1

To illustrate this: we are facing situations (DetNet is one of them) where the temptation is to place all the relevant info above UDP.
If DetNet is L3 then it should be signaled at L3 and its basic operation should not depend on ULP information.

Keep safe,

Pascal

From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: mardi 14 décembre 2021 16:59
To: 喻海生 <[email-masked]>
Cc: rbonica=40juniper.net <rbonica=[email-masked]>; ipv6 <[email-masked]>
Subject: Re: Adoption call on HBH drafts

On Mon, Dec 13, 2021 at 11:23 PM 喻海生 <[email-masked]<mailto:[email-masked]>> wrote:
Dear Ron,

        For Part 2, my opinion is as follows：
        One of the most important advantages of IPv6 compared to IPv4 is that IPv6 has good programmability and can use extension headers flexibly. Among them, the HBH extension header is the most outstanding representative, because other extension headers are only processed in the source node and the destination node. HBH extension header is the only extension header that can be processed at the intermediate node.
        In the past, due to the low overall utilization rate of IPv6 networks, there were few innovations based on IPv6 networks. In recent years, with the development of IPv6, innovations based on IPv6 extension headers have also increased substantially. HBH is the representative of the IPv6 extension header. Due to historical reasons, the HBH extension header has been abandoned for fear of becoming a carrier of DOS attacks. At present, it has come to the era of innovation and reproduction of brilliance for the use of HBH extension headers and IPv6.

Well said. IMO, Hop-by-Hop extension header is *the* extensible mechanism in IPv6 that allows the host to signal the network and vice versa. The need for such signaling is known and the suggested alternatives to HbH options are overloading flow label, embedding information in IPv6 addresses, putting networking layer information in transport layer like the spin bit in QUIC-- all of those are hacks that at best address a few short term point problems and only increase ossification of the Internet. I fear that if we abandon HbH options, even outside of limited domains, then we are conceding that the Internet is no longer a platform for innovation and evolution at least at the networking layer.

Tom

[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
Haisheng Yu(Johnson)
BIIGroup
[email-masked]<mailto:[email-masked]>

On 12/14/2021 05:56，Ron Bonica<rbonica=[email-masked]><mailto:rbonica=[email-masked]> wrote：
Brian,

Your case has two parts:

Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian E Carpenter
Sent: Monday, December 13, 2021 2:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Adoption call on HBH drafts

Regards
Brian

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draf>

Keep safe;

Pascal
-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: lundi 13 décembre 2021 10:30
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: 6man WG <[email-masked]<mailto:[email-masked]>>; 6man Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption call on HBH drafts

I was thinking of:

IOAM in:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ie>
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ie>

Cheers,
Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests:
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
__;!!NEt6yMaO-gk!Q3FfaSQWPEEHbnJhRfS1iq77sTz3MrkdNBKegkJwJJdIYFGRq-UCU
Cd3fkRDXrFC$
--------------------------------------------------------------------

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

---

From: Haisheng Yu(Johnson) <[email-masked]>
Date: Thu, 16 Dec 2021 16:24:35 +0800

Dear Pascal,

My opinion is similar. If DetNet is positioned at L3, the information needed in the DetNet network transmission process should be obtained at L3 and can be sensed by intermediate network nodes. L4 technologies like QUIC reduce the delay and reduce the coefficient before RTT, while some technologies of L3 should aim to reduce the RTT itself.

Haisheng Yu(Johnson)

[email-masked]

签名由
网易邮箱大师
定制

On 12/15/2021 00:27，Pascal Thubert (pthubert)<[email-masked]> wrote：

+1

Keep safe,

Pascal

From: ipv6 <[email-masked]>
On Behalf Of Tom Herbert

To:
喻海生 <[email-masked]>

On Mon, Dec 13, 2021 at 11:23 PM
喻海生 <[email-masked]> wrote:

Dear Ron,

One of the most important advantages of IPv6 compared to IPv4
is that IPv6 has good programmability and can use extension headers flexibly. Among them, the HBH extension header is the most outstanding representative, because other extension headers are only processed in the source node and the destination node. HBH extension
header is the only extension header that can be processed at the intermediate node.

In the past, due to the low overall utilization rate of IPv6
networks, there were few innovations based on IPv6 networks. In recent years, with the development of IPv6, innovations based on IPv6 extension headers have also increased substantially. HBH is the representative of the IPv6 extension header. Due to historical
reasons, the HBH extension header has been abandoned for fear of becoming a carrier of DOS attacks. At present, it has come to the era of innovation and reproduction of brilliance for the use of HBH extension headers and IPv6.

Well said. IMO, Hop-by-Hop extension header is *the* extensible mechanism in IPv6 that allows the host to signal the network and vice versa. The need for such signaling is known
and the suggested alternatives to HbH options are overloading flow label, embedding information in IPv6 addresses, putting networking layer information in transport layer like the spin bit in QUIC-- all of those are hacks that at best address a few short term
point problems and only increase ossification of the Internet. I fear that if we abandon HbH options, even outside of limited domains, then we are conceding that the Internet is no longer a platform for innovation and evolution at least at the networking layer.

Tom

Haisheng Yu(Johnson)

BIIGroup

[email-masked]

On 12/14/2021 05:56，Ron
Bonica<rbonica=[email-masked]> wrote：

Brian,

Your case has two parts:

Ron

-----Original Message-----

To: [email-masked]

Regards

Brian

and

Keep safe;

Pascal

-----Original Message-----

domains

I was thinking of:

IOAM in:

options/06/

AltMark:

Cheers,

Ole

[email-masked]

Administrative Requests:

Cd3fkRDXrFC$

[email-masked]

Administrative Requests:

[email-masked]

Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

[email-masked]

Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Dec 2021 22:55:54 -0500

Ron & Tom

+1

> evolution at least at the networking layer.

Gyan> Very good points indeed related to HBH extensibility and how
important it is for operators regarding the viability of HBH for
innovations on the public internet.

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*