[IPv6]Re: Fwd: New Version Notification for draft-herbert-deprecate-eh-00.txt

[Tom Herbert <[e-mail]>]

On Tue, Dec 30, 2025 at 2:58 PM Brian E Carpenter
<[e-mail]> wrote:
>
> On 31-Dec-25 10:54, Mark Smith wrote:
> > If IPv6 EHs are such a big problem, why haven't IPv4 options been removed decades ago?
>
> I think because everybody knows that the Internet is opaque to them, so it's never been worth anybody's time to write an RFC. The difference with IPv6 is that they have long been touted as an IPv6 advantage, so people keep trying to use them for new things.
>
> >
> > It's starting to sound a bit chicken little to me.
>
> Well, as Tom has been pointing out, the concern about DoS is real enough, which is why common operational practice is to filter them. And the Internet was already stated to be opaque to IPv4 options when I first started attending IETF meetings, even though DoS was not much of an active threat then. So the sky isn't falling, because operators have already mitigated the risk, both for IPv4 (since 1990s) and IPv6.

Brian,

Also, there is a lot more code to support extension headers than IPv4
options, and that code is deployed across billions of devices.
Maintaining code for a protocol that is unused is not free. And if
code isn't being used and maintained and potential issues aren't being
addressed then the code is nothing more than a liability and it needs
to be removed. It really does come down to "use it or lose it".

Tom

>
>     Brian
>
> >
> > On Wed, 31 Dec 2025, 06:49 Brian E Carpenter, <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Sebastian,
> >
> >      > It seems sad, that we are on the path of making that impossible.
> >
> >     Indeed. However, there is a difference between:
> >
> >     (a) Changing the IETF Standard to remove EH from the protocol (except for a few exceptions such as ESP).
> >
> >     (b) Issuing an operational Best Current Practice strongly recommending filtering EH (except for a few exceptions) at network boundaries.
> >
> >     (b) would leave space for future changes that (a) would exclude.
> >
> >     Regards/Ngā mihi
> >          Brian Carpenter
> >
> >     On 31-Dec-25 08:26, Sebastian Moeller wrote:
> >      > Hi Tom,
> >      >
> >      > so I agree that this might be the wisest thing to do.
> >      > I am a bit sad though, because I have this pet usage for which an EH might actually be a decent solution:
> >      > Late 2023 there was a draft (Congestion Signaling (CSIG) draft-ravi-ippm-csig-00) that offered a way forward for better congestion/capacity signalling beyond drops and 1bit ECN marking.
> >      > It was an IMHO undeservedly shunned draft that showed ways to bring capacity signalling into the not so new-anymore millenium. To recap, the core of the idea was that all hops along a path (which might be a single switch in the original design or multiple routers) aggregate information about their capacity along a path, e.g. the minimum relative available capacity, and the endpoint can extract relevant capacity changes along the path from that and hence can react to looming capacity shortfalls instead of simply slow.staring itself into transient over-load.
> >      >
> >      > Somewhat unfortunately It had picked L2 as the home for the information, making it purposefully unsuitable for internet usage#. IMHO the same principle of information collection works just as well over the internet, except we replace L2 headers and L2 switches with L3 headers and L3-routers... So I am searching for an L3 header with preferably predictable position that can be modified potentially by all nodes along a path and that can also be read by the endpoint. My limited understanding of EHs told me that either a Hop-by-Hop option (which can be modified by all hops along a path) or an unencrypted destination option (that will be read be the endpoint) are candidates here (and for the DO one would need to accept on path modification*).
> >      > It seems sad, that we are on the path of making that impossible.
> >      >
> >      > Regards
> >      >       Sebastian
> >      >
> >      >
> >      > #) IMHO not the most sensible approach for a draft for the _internet_ engineering task force....
> >      > *) I am fine with that, I could not care less about theoretical taxonomy of different EH types
> >      >
> >      >
> >      >> On 26. Dec 2025, at 23:16, Tom Herbert <tom=[e-mail] <mailto:[e-mail]>> wrote:
> >      >>
> >      >> Happy Holidays 6man!
> >      >>
> >      >> I've posted a new draft on deprecating extension headers on the
> >      >> Internet. Comment are appreciated!
> >      >>
> >      >> Thanks,
> >      >> Tom
> >      >>
> >      >> ---------- Forwarded message ---------
> >      >> From: <[e-mail] <mailto:[e-mail]>>
> >      >> Date: Fri, Dec 26, 2025 at 2:14 PM
> >      >> Subject: New Version Notification for draft-herbert-deprecate-eh-00.txt
> >      >> To: Tom Herbert <[e-mail] <mailto:[e-mail]>>
> >      >>
> >      >>
> >      >> A new version of Internet-Draft draft-herbert-deprecate-eh-00.txt has been
> >      >> successfully submitted by Tom Herbert and posted to the
> >      >> IETF repository.
> >      >>
> >      >> Name:     draft-herbert-deprecate-eh
> >      >> Revision: 00
> >      >> Title:    Deprecating IPv6 Extension Headers on the Internet
> >      >> Date:     2025-12-26
> >      >> Group:    Individual Submission
> >      >> Pages:    10
> >      >> URL: https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-00.txt <https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-00.txt>
> >      >> Status: https://datatracker.ietf.org/doc/draft-herbert-deprecate-eh/ <https://datatracker.ietf.org/doc/draft-herbert-deprecate-eh/>
> >      >> HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-deprecate-eh <https://datatracker.ietf.org/doc/html/draft-herbert-deprecate-eh>
> >      >>
> >      >>
> >      >> Abstract:
> >      >>
> >      >>    This document describes the deprecation of IPv6 extension headers on
> >      >>    the Internet with the exception of Encapsulating Security Payload.
> >      >>    Deprecation is motivated by three factors: 1) the data shows high
> >      >>    discard rates for packets with extension headers sent over the
> >      >>    Internet, 2) extension headers can be used for Denial of Service
> >      >>    attack and are replete with other security vulnerabilities, 3) the
> >      >>    high loss rates are a disincentive to develop new extension headers
> >      >>    or options that might be useful or fix known problems.  This document
> >      >>    recommends that extension headers, other than Encapsulating Security
> >      >>    Payload, be relegated to use only in limited domains and that packets
> >      >>    with extension headers should be discarded at boundary routers of
> >      >>    limited domains.
> >      >>
> >      >>
> >      >>
> >      >> The IETF Secretariat
> >      >>
> >      >> --------------------------------------------------------------------
> >      >> IETF IPv6 working group mailing list
> >      >> [e-mail] <mailto:[e-mail]>
> >      >> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>
> >      >> --------------------------------------------------------------------
> >      >
> >      > --------------------------------------------------------------------
> >      > IETF IPv6 working group mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>
> >      > --------------------------------------------------------------------
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/ <https://mailman3.ietf.org/mailman3/lists/[e-mail]/>
> >     --------------------------------------------------------------------
> >