Parsing IPv6 extension headers containing unknown extensions

Question

I'm writing a very simple net filter, and getting to where I want to parse IPv6 headers to match things like ICMPv6 types, TCP/UDP port numbers, etc.

So I'm reading about the IPv6 packet format in depth, and I'm kind of like... well... I sort of had to read it over and over again to make sure I was actually reading it right. It looks to me that you have to start with the 40-byte fixed header and look at its next header field. Then you have to look at the next header's next header field, and so on, like a linked list, until you reach the end. If there's payload, it will follow.

The problem is that there is no length field either in the fixed header or the extension headers. You have to have a table of extension header types and their sizes so that you can chase this linked list to the end.

This strikes me as a strange, possibly even hare-brained design. What if I encounter an unrecognized extension header type? What do I do? I don't know its length. I guess I have to throw the packet out and block it, since in a net filter allowing the packet through would allow an attacker to evade the net filter by including a bogus header type. But that means that if the protocol is ever extended, every single piece of IPv6 header parsing software ever written must be simultaneously updated if the new extension is to be used.

So how can I parse IPv6 headers if I don't know the extensions they're using? How can I skip a header for an unknown extension, since I don't know its length?

Solution 1

If you run into something you cannot parse, you have to make your decision or perform your action based on what you've parsed already.

The design is that way because in IPv6, each extension header "wraps" the rest of the packet. If you see the routing header, then some header you've never heard of, then the payload, then you cannot parse the payload. The meaning of the payload depends in principle on the header you don't know how to interpret.

Routers can route such packets, because all they need is the routing header. Deep packet inspection gadgets and suchlike need to know a lot, but then that's their fate anyway.

Edited to add: This design means that middleboxes can only change what they know. If a middlebox sees a header it doesn't know, then it has only two options: Reject or pass on. In IPv4 it could also remove the unknown extension and pass on the rest. IMO this property makes the design more rather than less extensible.

Solution 2

What if I encounter an unrecognized extension header type?

From RFC 2460:

If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header.

Solution 3

It is (in the real world) impossible to add a new extension header to IPv6.

Incorrect, because:

1. Only the destination host is allowed to reject based on unrecognized extensions headers (with that one exception mentioned in the question you linked)

2. If your new extension header is in some way optional (it had better be), you will receive an ICMP error about that and can try again without it.

Solution 4

The update RFC 6564 covers this case. It lays out exactly the scenario you describe and puts forth a format for any new extension headers (if any are ever defined) which middleboxes such as yours will be able to work with, at least some of the time.

Keep in mind that it isn't intended to extend IPv6 by creating new extension headers, but by adding new Destination Options. It should be trivial, or at least much easier, for you to deal with unknown destination options.

View more solutions

Comments

[AdamIerymenko]

Based on this question it looks like I'm not stupid and yes I am reading this right: it is (in the real world) impossible to add a new extension header to IPv6. stackoverflow.com/questions/9847923/…

[AdamIerymenko]

And yes, it also does seem that computing header length requires a linked list traversal: stackoverflow.com/questions/14762193/… Don't get me wrong. IPv6 is awesome and much needed. But this still seems bone-headed.

[Alan B]

I think, given the amount of time it has taken and the combined intellects involved, that there is probably a fairly good reason.

[Anders E. Andersen]

The spec (linked in the top comment) says routers are not supposed to look at the headers, so shouldn't care what headers you add. Only the destination node is supposed to look at the headers.

[ytti]

IPv6 header is this silly. EH can be used to hide L4 headers (by putting them further in the packet than router can inspect) causing firewall by-pass. There is on-going work like draft-ietf-6man-ext-transmit-01 to remedy current situation, but I don't expect very dramatic improvements to be accepted.

[pzkpfw]

Just a note: "hair-brained" is a fairly confusing spelling, and "hare-brained" should be preferred (source: tfd)

[Alan B]

Insofar as there's only one correct spelling, which is 'hare-brained'.

[AdamIerymenko]

Good. I thought I was losing my mind. So yes, it really is a completely un-extensible design... at least without in-band signaling and other hacks. That's excusable in an application protocol where you control both ends and only have to account for new versions of your app, but not in something designed to last for... hundreds of years?

[AdamIerymenko]

Saw your edit, seems pretty definitive. The problem is that yes this does make the protocol un-extensible, since intelligent routers and filters cannot pass packets with unrecognized extension headers for security reasons. Wow.

[jman]

Having the ability to ignore unknown headers would lead to much more complicated issues. (What if an intermediate proxy modified TCP headers without knowledge of an encapsulating ESP header?) Simplicity beats "extensible" in this case!

[AdamIerymenko]

Yeah, I see what you mean. I'll take that. But still... 2^128 addresses means we'll never need IPv7, so we better not need to add a new header field any time in the next 10,000 years or so. Of course if there's interplanetary colonization I suppose you could take the opportunity to insert a new header for use only on Mars.

[jman]

We may not need a new IP header, but surely we'll have new extension headers (en.wikipedia.org/wiki/IPv6_packet#Extension_headers) much more often!

[bezmax]

@Adamlerymenko But still... 2^128 addresses means we'll never need IPv7, 640K is more memory than anyone will ever need. I believe it will go the same way. People will use IP's for home electronics, watches, smartphones, etc. Then people will start using several IP addresses on one PC for some reasons (virtual machines and stuff, or just convenience), and little by little no IPs remain again.

[Tyler McHenry]

@Max IPv6 has quite literally enough addresses to assign one to every single atom on Earth. There's no number of Internet-connected toasters that will deplete this space.

[glglgl]

@Max Do you know how much 2^128 is? If you have a /64 at home, you can address 2^64, about 1.8 quintillions of devices (if I am not completely wrong). Evenly, there can be 1.8 quintillions of /64 nets all over the world. I merely cannot imagine we'll ever will need more.

[cincodenada]

@Max I won't say we'll absolutely never need IPv7, but with IPv6 we have enough address space to give each cubic millimeter in Earth's atmosphere (130,000km up) a unique address...100,000 times over. So I mean, once we start colonizing other galaxies we might have something to worry about, but until then we should be pretty good.

[ytti]

@Max It's possible that by really silly policies we can project exhaustion of IPv6 addresses. If that would happen, it would be very simple to fix the policies to be less silly (There is no inherent dependency to SLAAC, nor inherent technical need for SLAAC LAN to be 64b or large at all, just allocate urnd address and DAD until free found). IPv6 has problems, exhaustion of addresses is not one of them.

[Dexter]

And you're certain that that ICMP packet will make it through the NAT to the actual sender?

[bezmax]

@cincodenada Nothing is ever in abundance. If something is - it becomes abused, then everyone gets used to it and no policies help. Take that memory example, who would've guessed that we would load virtual machines into memory of other machines, using lists everywhere even that arrays would suffice, etc etc. If people from 1980 saw our code - they would think we are wasting resources like crazy. I believe same will happen with IPv6. For example, applications could start reserving whole IP addresses or even ranges of them, new ways of communication would arise, and so on.

[Janus Troelsen]

@Dexter ipv6 will kill NAT ... hopefully

[Bill Lynch]

@Dexter: Those ICMP packets need to arrive for a number of reasons. For example, if the MTU of the pipe has shrunk (perhaps packet encapsulation has happened because of PPPoE or a VPN), and the packet being sent is too large, an ICMP packet will be returned saying that the packet is too large.

[ytti]

Of course policies help, if you don't qualify for new RIR allocation due to your incorrect allocation of addresses, that is the end of your address wastage. If we completely fsck-up current global Internet block, we have lot more completely unassigned blocks we can start fresh with better policies. Pulling the 640k argument is rather poor argument, when argument was made people already were using more than 640k in some environments and compelling arguments were easy to make. Rather than doing the 640k argument, present compelling argument how we could run out of IPv6 addresses.

[Dexter]

@JanusTroelsen not everyone shares your hopes.

[Tobu]

Some context is missing: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.