Message-ID: <CALx6S37LRKzvGF8j93OECgDuVR9P4rz0DNMhM2JwaFziNq2vaQ@mail.gmail.com>
Date: Fri, 30 Jan 2026 09:06:43 -0800
From: Tom Herbert <tom@...bertland.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Justin Iurman <justin.iurman@...il.com>, davem@...emloft.net, kuba@...nel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering

On Thu, Jan 29, 2026 at 11:05 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Justin Iurman wrote:
> > On 1/29/26 06:18, Willem de Bruijn wrote:
> > > Tom Herbert wrote:
> > >> RFC8200 highly recommends that different Extension Headers be send in
> > >> a prescibed order and all Extension Header types occur at most once
> > >> in a packet with the exception of Destination Options that may
> > >> occur twice. This patch enforces the ordering be folowed in received
> > >> packets.
> > >>
> > >> The allowed order of Extension Headers is:
> > >>
> > >>      IPv6 header
> > >>      Hop-by-Hop Options header
> > >>      Destination Options before the Routing Header
> > >>      Routing header
> > >>      Fragment header
> > >>      Authentication header
> > >>      Encapsulating Security Payload header
> > >>      Destination Options header
> > >>      Upper-Layer header
> > >>
> > >> Each Extension Header may be present only once in a packet.
> > >>
> > >> net.ipv6.enforce_ext_hdr_order is a sysctl to enable or disable
> > >> enforcement of xtension Header order. If it is set to zero then
> > >
> > > [e]xtension. There are a few more typos in the various commit
> > > messages.
> > >
> > >> Extension Header order and number of occurences is not checked
> > >> in receive processeing (except for Hop-by-Hop Options that
> > >> must be the first Extension Header and can only occur once in
> > >> a packet.
> > >
> > > RFC 8200 also states
> > >
> > >     "IPv6 nodes must accept and attempt to process extension headers in
> > >     any order and occurring any number of times in the same packet,
> > >     except for the Hop-by-Hop Options header, which is restricted to
> > >     appear immediately after an IPv6 header only. Nonetheless, it is
> > >     strongly advised that sources of IPv6 packets adhere to the above
> > >     recommended order until and unless subsequent specifications revise
> > >     that recommendation."
> > >
> > > A case of be strict in what you send, liberal in what you accept.
> > >
> > > This new sysctl has a chance of breaking existing users.
> >
> > Willem,
> >
> > Note that RFC8200 does not use normative language, which is part of the
> > problem. It could theoretically break existing users, but I don't think
> > it will in reality. For that, you would need users to beginning with
> > (joke aside, I like EHs). Anyway, if the order is enforced at sending,
> > why would any receiver accept a different order? In this case, being
> > liberal in what we accept might be a security risk (see below).
> >
> > > The series as a whole is framed as a security improvement. Does
> > > enforcing order help with that?
> >
> > IMHO, any packet with EHs in a different order than the one specified in
> > RFC8200 looks suspicious. So, yes.
>

Hi Willem, thanks for your comments!

> Looks suspicious. But does not introduce concrete new risks?

Hard to say specifically. On the other hand, there's no known use
cases for alternatives for it and given all the other security perils
a strong default security posture wrt EH order seems prudent.

>
> The main risk I understand around IPv6 extension headers is the risk
> common to all untrusted network input: bugs in parsing code. Bugs can
> cause crashes, infinite loops, or worse subtle effects. This is why we
> introduced the BPF flow dissector, for instance.

I believe the main risk is Denial of Service attacks and security
vulnerabilities.

>
> I don't immediately see how different order of headers increases
> parsing risk. Nor, btw, that reducing max number of headers from 8 to
> 2 significantly mitigates a real risk.

It's a similar rationale to putting a limit on the number of options
in the first place. Going from 700 options allowed in a packet to at
most 8 allowed was a no brainer. But even 8 is too much considering
that the stack only supports three Hop-by-Hop options and two
Destination options. There's a common misnomer that only hardware has
trouble parsing TLVs, and somehow it's free in SW (I've been battling
that mindset!). For instance, a well constructed attack could force
one cache, maybe two cache misses per each option. So going from 8 to
2 as the default limit could materially mitigate the damage for a DoS
attack on options.

>
> No objections necessarily. But I don't fully understand the argument.

We selected the default value of eight in RFC8504 based on an
expectation that there might be new options defined and that the
Internet would be fixed to reliably support extension headers
including those with options. I do not believe either of those are
going to happen.

Hop-by-Hop Options are ostensibly the right way to do network to host
and host to network signaling.The only HBH options that might get any
substantial deployment are Router Alert option and IOAM. The Router
Alert option is being deprecated and IOAM is at best a "nice toi
have". The best use case of Hop-by-Hop options is congestion
signaling, unfortunately the die was cast when CSIG authors decided to
place the information in VLANs at L2 and cajole the information to be
routable through a switch. IMO, the miss on CSIG pretty much is the
nail in the coffin for Hop-by-Hop options to ever be widely deployed
(https://www.ietf.org/archive/id/draft-ravi-ippm-csig-01.txt).

Destination Options have proven even less useful than Hop-by-Hop
Options. The only Destination Option supported by the stack is the
Tunnel Encap Limit option and Home Address Options. The Tunnel Encap
Option was buried in the v6 tunnel code which is why it wasn't obvious
it was supported in the first version of the patch set.  I'll assume
this might be useful, so this patch set cleans up the code for it. I
don't believe there's any use of Home Address Option.

A major problem with DestOpts, HBH, Routing Header, and Fragment
header is that they have no inherent security. Their use presents a
security risk especially when sent over untrusted networks including
the Internet. Given that and that the high drop rates of extension
headers on the Internet, I am proposing that Extension header except
fo ESP being deprecated on the Internet
(https://www.ietf.org/archive/id/draft-herbert-deprecate-eh-01.txt).

IMO, IPv6 Extension Headers are a failed experiment in protocol
design. The vast majority of hosts do not care about them, and the
best use case for them is Denial of Service attack. So IMO the greater
good is to limit them as much as possible. If some private network
finds a use case for them they can also configure sysctls if they
don't like the default behavior.

Tom

Powered by blists - more mailing lists