LWN: Comments on "The trouble with IPv6 extension headers"

The trouble with IPv6 extension headers

jch — Thu, 16 Jan 2020 01:59:51 +0000

Path MTU discovery (PMTUD), as described in RFC 8201, doesn't use extension headers. The draft linked from the article is just a personal draft, not an IETF working group document.

The trouble with IPv6 extension headers

dan_a — Thu, 09 Jan 2020 11:26:56 +0000

There is also a draft explaining the potential problems with them: https://tools.ietf.org/html/draft-smith-6man-in-flight-eh...

The trouble with IPv6 extension headers

shef — Thu, 09 Jan 2020 05:10:12 +0000

Back in Dec/Nov there was a huge mail thread in ietf ipv6/spring mail list about exactly the same issue. Cisco proposes to add SRH (ipv6 segment routing header) on transit nodes and there are plenty of IETF participants who disagree with that proposal. I think we should wait for standards track RFC which will at least guarantee rough consensus on the issue.

The trouble with IPv6 extension headers

hmh — Wed, 08 Jan 2020 11:37:51 +0000

Hmm, as far as we know, right now packets with EHs don't live long on the Internet. Refer to RFC7872.

Due to this, adding EHs to 3rd party packets going through a transit[1] network seems akin to sabotaging that packet flow to me, unless you also remove the added EHs before handing the packets over to the next AS (autonomous system)/ISP. So, this is something to use inside your own networks, where you (supposedly) know nothing will drop that packet just because you added the EH (in which case, IME, you will have headaches for the next decade with other people within your network pushing for buying (or outright buying and deploying) incompatible crap and breaking network paths that used to work).

I.e. exactly like IPv4 options.

If anything, this kind of "feature" should be in DPDK and other zero-copy userspace data planes, or on the hardware flow offload devices. The only reason to have it in-kernel would be to use it on very-low-performance (virtualized overlay ?) networks, as far as I know... or to direct the kernel to mangle packets being locally originated by applications you cannot "fix", before delivering them to the network.

[1] In the Internet sense. A transit network/provider/Autonomous System is an Autonomous System that is willing to forward packets from a client Autonomous System to its other client Autonomous Systems *and* to its own upstream transit networks.