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

["Bonica, Ron" <[e-mail]>]

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?


>
> 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.

>
> 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?

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.

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.


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$
> > --------------------------------------------------------------------