Message-ID: <willemdebruijn.kernel.8e46b721f5ed@gmail.com>
Date: Thu, 29 Jan 2026 14:05:48 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Justin Iurman <justin.iurman@...il.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Tom Herbert <tom@...bertland.com>, 
 davem@...emloft.net, 
 kuba@...nel.org, 
 netdev@...r.kernel.org
Subject: Re: [PATCH net-next v5 6/7] ipv6: Enforce Extension Header ordering

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.

Looks suspicious. But does not introduce concrete new risks?

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

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

Powered by blists - more mailing lists