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

[Tom Herbert <[e-mail]>]

On Mon, Dec 29, 2025 at 1:31 PM Bonica, Ron
<ronald.bonica=[e-mail]> wrote:
>
> Inline.......RB>
>
>
> ________________________________
> From: Tom Herbert <tom=[e-mail]>
> Sent: Monday, December 29, 2025 3:33 PM
> To: Bonica, Ron <[e-mail]>
> Cc: 6MAN <[e-mail]>
> Subject: Re: [IPv6]Fwd: New Version Notification for draft-herbert-deprecate-eh-00.txt
>
> On Mon, Dec 29, 2025 at 10:42 AM Bonica, Ron
> <ronald.bonica=[e-mail]> wrote:
> >
> > Tom,
> >
> > You can extend the definition of "limited domain" to include every network that deploys ACLs at its edge. But you cannot mandate or even recommend that all networks maintain the same set of ACLs at their edge.
>
> Hi Ron,
>
> Why not? SRV6 already requires SR packets to be filtered as a MUST.
> That's because it's bad to leak SR packets into the Internet, and very
> bad to accept them from untrusted sources. The same logic seems to
> apply to other extension headers, at least HBH.
>
> RB> Because every network has unique security requirements. For example, assume that my network processes the IPv6 Minimum Path MTU Hop-by-Hop Option [RFC 9268] on the forwarding plane. Therefore, it poses no threat to my network. Moreover, it offers benefit to my customers. Why should I filter it?
>

HI Ron,

Is it a benefit to your users or only a potential benefit? AFAIK there
is no host implementation of RFC9268 that would consume the data, if
that's true then Minimum Path MTU Hop-by-Hop Option is only beneficial
on paper.

>
> >
> > Each network has unique filtering requirements. A transit network may filter destination options in packets that are bound for its own infrastructure. But it has no business filtering destination options in packets that are bound for its customers.
>
> Except that transit networks commonly drop Destination Options that
> are bound for their customers, so they've made it their business :-(.
>
>
> RB> This is a bug, not a feature.

A bug in the implementation or the protocol? I will argue that
defining Hop-by-Hop and Destination options that allow an attacker to
stuff 700 unknown options in a single MTU size packet which has no
purpose other than DoS attack is a protocol bug :-)

>
> >
> > This filtering, although well-meaning, is not helpful to the customer who may rely on the filtered destination option.
>
> But no customers rely on Destination Options.
>
> RB> Can you stand by that statement? If you look at the IANA registry, many Destination Options are defined. What makes you so sure that none of them are in use? Do you have any empirical evidence? Maybe a survey of network operators?

Yes, we do have evidence. Destination Options are of interest to hosts
and not network operators, so if any one is to be polled it is host
developers and operating systems developers. Here's the scorecard:

1) Linux kernel only supports one Destination Option which is the
mobility option. It's possible other OSes support others, but even if
they do there's very little interoperability (just amongst
themselves).
2) Previously on the 6man list, someone pointed out that Android OS
summarily drops all packets with extension headers (i.e. if they're
not needed, why waste battery processing them?).
3)  In the discussion on UDP Options (which are essentially a
reformation of Destination Options) the QUIC advocates argued that for
a requirement that UDP options must not be used with QUIC as they
would undermine the security position of QUIC that all end-to-end
information is encrypted-- I suspect they would advocate the same
requirement that Destination Options should not be used with QUIC for
the same reasons.
4) The high drop rates of Destination Options on the Internet
discourage serious applications developers from using them. Why should
we, i.e. application developers, use a protocol feature that is very
likely to be dropped and IETF has no plan to address the drops?

>
> The unreliability, lack
> of security, and fact that there's no defined Destination options that
> are useful ensure that.
>
> RB> Can you support the statement that there are no defined Destination Options that are useful? In order to do this, you would have to do a survey of  RFCs that define Destination options and explain why each Destination Option is useless. Do you really want to take on this task.

As I mentioned wrt PMTU HBH option there's "potentially useful" and
then there's "useful". Considering that the most deployed OS running
on billions of hosts only supports one legacy Destination Options, I
think it's safe to say that there are no Destination options that are
remotely close to being widely useful after 25+ years of IPv6.
Personally, I am skeptical that there's even _any_ Destination options
being productively used at all in real deployment, but obviously that
is something I cannot prove.

>
> I am especially concerned with the lack of
> security in Destination since that seems like an egregious security
> hole that can always be avoided by just setting the data inside the
> encryption envelope of a transport protocol.
>
> RB> I don't understand this statement. The Destination Option is encapsulated in the ESP.

That's only true if ESP is in use. If there's no ESP then Destinations
Options can be sent in plain text. Note that the draft makes an
allowance for ESP and Destination Options after ESP.

Tom



>
>
> Tom
>
> >
> >
> >                                                                      Ron
> >
> >
> >
> > ________________________________
> > From: Tom Herbert <tom=[e-mail]>
> > Sent: Monday, December 29, 2025 10:14 AM
> > To: Bonica, Ron <[e-mail]>
> > Cc: 6MAN <[e-mail]>
> > Subject: Re: [IPv6]Fwd: New Version Notification for draft-herbert-deprecate-eh-00.txt
> >
> > On Mon, Dec 29, 2025 at 6:58 AM Bonica, Ron
> > <ronald.bonica=[e-mail]> wrote:
> > >
> > > Tom,
> > >
> > > Please disregard my previous comments regarding this draft. On second reading, the draft has a much more significant problem.
> > >
> > > In the introduction, you say:
> > >
> > > "This document proposes that extension headers be deprecated on the Internet by discarding packets with extension headers at the boundaries of limited domains [RFC8799]."
> > >
> > > In Section 2, where all of the normative language appears, you define ACLs that SHOULD or MUST be deployed at limited domain boundaries.
> > >
> > > It seems to me that this draft does not deprecate extension headers on the Internet at all. The ACLs defined in Section 2 won't do anything to restrict extension headers sent across three provider networks that do not participate in limited domains.
> > >
> > > In reality, this draft defines a one-size-fits-all limited domain. Do you really want to do that?
> >
> > Ron,
> >
> > A provider network is a limited domain, It is potentially dangerous
> > for a provider network to accept packets with extension headers from
> > an untrusted party, i.e. anyone on the Internet. By necessity provider
> > networks need to establish ACLs at ingress points in their network to
> > at least filter packets with extension headers especially Hop-by-Hop
> > Options and Routing headers which can target the providers
> > infrastructure.
> >
> > >
> > > Two operators might need to deploy limited domains. However, one operator might want to filter one set of extension headers while another operator might want to filter a different set.
> > >
> > > At very least, you should change the title of the document and remove claims about deprecating extension headers on the Internet.
> >
> > But that;s the point. We want to eliminate the use of extension
> > headers on the open Internet, The mechanism to enforce that is to drop
> > packets with extension headers at boundary points.
> >
> > Tom
> >
> > >
> > >                                                                                                  Ron
> > >
> > >
> > >
> > > ________________________________
> > > From: Tom Herbert <tom=[e-mail]>
> > > Sent: Friday, December 26, 2025 5:16 PM
> > > To: 6MAN <[e-mail]>
> > > Subject: [IPv6]Fwd: New Version Notification for draft-herbert-deprecate-eh-00.txt
> > >
> > > 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://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-00.txt__;!!NpxR!iJ1sQxfMiPDQYMZn18vwro6QhGiB_k4p3EvJg7ODewoap9PfftZsk4cvvHTzhpIGg7mnU8PtaH0heh7EWXQLiuQQRp5zUmhp$
> > > Status:   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-herbert-deprecate-eh/__;!!NpxR!iJ1sQxfMiPDQYMZn18vwro6QhGiB_k4p3EvJg7ODewoap9PfftZsk4cvvHTzhpIGg7mnU8PtaH0heh7EWXQLiuQQRgm9B6Th$
> > > HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-herbert-deprecate-eh__;!!NpxR!iJ1sQxfMiPDQYMZn18vwro6QhGiB_k4p3EvJg7ODewoap9PfftZsk4cvvHTzhpIGg7mnU8PtaH0heh7EWXQLiuQQRpZo_F9M$
> > >
> > >
> > > 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://urldefense.com/v3/__https://mailman3.ietf.org/mailman3/lists/[e-mail]/__;!!NpxR!iJ1sQxfMiPDQYMZn18vwro6QhGiB_k4p3EvJg7ODewoap9PfftZsk4cvvHTzhpIGg7mnU8PtaH0heh7EWXQLiuQQRnxNN22L$
> > > --------------------------------------------------------------------