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

[Tom Herbert <[e-mail]>]

On Sun, Dec 28, 2025 at 1:06 PM Justin Iurman <[e-mail]> wrote:
>
> On 12/28/25 19:36, Tom Herbert wrote:
> > On Sun, Dec 28, 2025 at 4:20 AM Justin Iurman <[e-mail]> wrote:
> >>
> >> Hi Tom,
> >>
> >>   From the 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
> >>
> >> Points 1 and 2 are contradictory. If discard rates are high, then a DoS
> >> attack is theoretical/unpractical.
> >
> > Happy Holidays Justin.
>
> Tom,
>
> > There's no contradiction here. The high discard rates discourage
> > developers from developing and deploying extension headers on the
> > Internet. EH is still reachable to many destinations so an attack
> > would be effective to those destinations. At best the high drop rates
> > have mitigated attacks, not eliminated them. Of course, if we don't
> > address the vulnerabilities on the basis that the protocol isn't used
> > then that's poor engineering.
>
> I'm not saying it's not possible, just that it's unlikely considering
> the current situation. Which is also why I proposed to fix that part of
> RFC 8200 in eh-occurrences (and I believe you also did in eh-limits).
>
> Back to a question I had: why does it have to be all or nothing when
> talking about EHs? IMO, fixing that part in RFC 8200 + adapting limits
> of options in a Hbh or DO in rfc8504-bis would be a good short-term
> compromise.
>
> >>      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.
> >>
> >> As already discussed in other threads, I don't think it'd be reasonable
> >> to disable/deprecate/you-name-it the Destination Options Header on the
> >> public Internet and relegate it to limited domains only. I don't have a
> >> strong opinion for other EHs, but my intuition tells me it wouldn't be a
> >> good idea for the future. Just because there aren't any use cases at the
> >> moment doesn't mean you won't have them in a few years.
> >
> > How many years exactly until we'll be able to reliably use extension
> > headers on the Internet? What's your plan to address the issues and
> > convince developers it's finally okay for them to use in their
>
> As mentioned, I only see the DO as a good candidate here.
>
> > applications? For Destination Options, how will you convince a
> > developer that they should send end-to-end data in plain text over the
> > Internet without any Integrity checks instead of just putting the data
> > inside the encryption envelope of a transport protocol? Consider that
>
> First, because you may need that data in Layer-3 instead of Layer-4.
> Second, you can just use ESP+Dest to avoid filtering and hardware
> limitation, and have confidentiality+integrity. So, it is doable if you
> really want to at the moment.

Justin,

The draft would allow ESP with a Destination Options header. What the
draft deprecates is using plain text Destination Options on the
Internet (i.e. Destination Options not sent in ESP). If nothing else,
the lack of security precludes any serious use of plain text
Destination Options being sent over the Internet. Do you agree with
this? If you don't, please describe the use case for a Destination
Option that exposes end to end information to untrusted parties, and
allows those parties to change the data as they please or even insert
their own Destination Options header in packets without detection.

Tom

>
> > we have more than twenty-five years of history with IPv6 and IPv4
> > options going back even farther-- not a single Destination option has
> > ever been defined that would be even remotely considered useful, much
> > less needed, over the Internet. Given all this, I don't believe that
> > Destination Options will ever be productively used on the Internet--
> > the cost-value proposition just isn't there and never will be IMO.
>
> That's a pretty strong opinion, but unfortunately we don't have a
> crystal ball.
>
> Justin
>
> > Tom
> >
> >>
> >> Justin
> >>
> >> On 12/26/25 23:16, Tom Herbert 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]>
> >>> 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]>
> >>>
> >>>
> >>> 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
> >>> Status:   https://datatracker.ietf.org/doc/draft-herbert-deprecate-eh/
> >>> HTMLized: 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]
> >>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
> >>> --------------------------------------------------------------------
> >>
>