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

Vasilenko Eduard <> Fri, 11 June 2021 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73D253A33CD for <>; Fri, 11 Jun 2021 04:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wotrpt64wxY3 for <>; Fri, 11 Jun 2021 04:13:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CF493A33C9 for <>; Fri, 11 Jun 2021 04:13:29 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4G1dJD2bLWz6L7GX for <>; Fri, 11 Jun 2021 19:03:56 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 13:13:20 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 11 Jun 2021 14:13:17 +0300
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Fri, 11 Jun 2021 14:13:17 +0300
From: Vasilenko Eduard <>
To: "" <>
Subject: RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Thread-Topic: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
Thread-Index: AQHXXn73aHmqKIlNK0iyWDK9rp6HY6sOE9yAgAAba4CAAHGugA==
Date: Fri, 11 Jun 2021 11:13:17 +0000
Message-ID: <>
References: <> <> <> <> <> , <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jun 2021 11:13:34 -0000

Hi all,
I was silent reading this discussion because it is pretty much a useless exercise.
95% of Telco traffic is the Best Effort (nobody pays a penny for additional services).
Additional headers processing has the cost:
- develop a new feature
- test a new feature
- implement a new feature
- support a new feature
And accept the responsibility for additional different risks (security, performance, interoperability).

Never-ever EH would work on the Internet till the Telco business model would change. Dump pipe does not need it.
It is true for half of the latest development in the IETF (especially for anything QoS-related).

Hence, fancy IPv6 functionality should be convenient only for closed domains.
It is primarily Enterprises where business case calculation for everything activated is not so strict.
Enterprises have much more traffic that is considered important for many reasons.

HbH in its current specification is perfectly fine for a closed domain.
If you would change it in any way that was discussed here - it would be still fine for a closed domain.
Of course, I could be wrong here because IPv6 popularity in the Enterprise is still close to 0%.
Hence, we do not know what Enterprise would need when they move to IPv6.
Unfortunately, such discussion is not popular here. It is primarily here about how to fix what is not possible to fix.

PS: it makes sense to drop testing "best effort pipe" for fancy services for not to disappoint ourselves.
-----Original Message-----
From: ipv6 [] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, June 11, 2021 9:59 AM
To: Fernando Gont <>
Subject: RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

Hello Fernando

How that that so different from the PMTUD problem? When the route changes, the end-to-end MTU may change too.


- there are places were you won't even try to guess; 6LoWPAN decided to use an MTU of 1280 and will not try PMTUD; for HbH, as Brian suggests, it might be that the Internet at large is the wrong place to try it.

- there are flows and use cases that can really benefit from it, so keeping the lowest common denominator in all circumstances seems utterly wasteful.

- the concept of domain that Brian mentioned is intuitively the thing we're after. But the domain scope is not always very clear. So exploration can help.

Note that adding a HbH OH in an existing PMTUD / MSS exploration does not require a change in the intermediate routers and middle boxes. We do not need an RFC for that, anyone can try it already. 

draft-ietf-6man-mtu-option seems to serve the purpose as a side effect, though clarifying that other options can be placed in the HbH OH to experiment whether those options are also supported along the path seems like a good idea, e.g., for options with the leftmost bit set to 1 (act = 0b1O or act = 0b11).    

Keep safe;


> -----Original Message-----
> From: Fernando Gont <>
> Sent: vendredi 11 juin 2021 7:21
> To: Pascal Thubert (pthubert) <>
> Cc:;; 
> Subject: Re: New Version Notification for 
> draft-hinden-6man-hbh-processing- 01.txt
> Hi, Pascal,
> On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> > This might need a solution be similar to the MTU problem; e.g., 
> > during PMTUD a node might add the HbH Options that it needs to check 
> > that the options make it through…
> Aside from a bunch of other evil details:
> WHat if, say, you employ this solution at, say, connection- 
> establishment time, find that EHs actually "work" towards your 
> destination, but them, sometime later, the path to your 
> destinationchanges, and you find out that EHs no longer work?
>      Abort the transaction/connections?
>      "Migrate" from EH-based mechansim to the fall back mechanism?
>      Anything else?
> What about the impact on e.g. RTT for connection-establishment? What 
> about the complexity of the mechanism? How many bugs/vulns before 
> every implementation gets it right?
> Truth #3 of comes to mind...
> Thanks!
> Regards,
> --
> Fernando Gont
> Director of Information Security
> EdgeUno, Inc.
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

IETF IPv6 working group mailing list
Administrative Requests: