IETF RFC on the Standards Tracks that talks about the problem of chaining headers in IPv6. I’m getting a sense of deja-vu since this was also has issue with IPv4 and, ultimately, use of chained IPv4 headers died away.
If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and drop it. Unfortunately, it is an established fact that several widely used firewalls do not recognise some or all of the extension headers standardised since RFC 2460 was published. It has also been observed that certain firewall do not even handle all the extension headers standardised in RFC 2460, including the fragment header [FRAGDROP], causing fundamental problems of end-to-end connectivity. This applies in particular to firewalls that attempt to inspect packets at very high speed, since they cannot take the time to reassemble fragmented packets, especially when under a denial-of-service attack.
Other types of middleboxes, such as load balancers or packet classifiers, might also fail in the presence of extension headers that they do not recognise.
Intermediate network appliances like proxy servers, firewalls, VPN Concentrators do not like to hold large amounts packet state which is required when performing inspection. Consider a firewall that wants to perform stateful inspection on an IPv6 flow that has 200 packets in a chain and would need to buffer those packets before locating the FIN and establishing the session state.
This combination of circumstances creates a “Catch-22” situation [Heller] for the deployment of any newly standardised extension header except for local use. It cannot be widely deployed because existing middleboxes will drop it on many paths through the Internet. However, most middleboxes will not be updated to allow the new header to pass until it has been proved safe and useful on the open Internet, which is impossible until the middleboxes have been updated.
With the increasing use of encryption in protocols, I’m taking the view that middle boxes may not be the future of networking. And IPv6 chaining is another problem area. Do we need IPv6 chaining ?
This RFC indicates that
IANA has added an extra column titled “IPv6 Extension Header” to the “Assigned Internet Protocol Numbers” registry to clearly mark those values that are also IPv6 extension header types defined by an IETF Standards Action or IESG Approval (see list below). This also applies to IPv6 extension header types defined in the future.
By standardising the IPv6 Extension header in RFC6564
I’m not sure what to make of this change. in one sense, key components of IPv6 still seem to be in development. This uncertainty makes it easy for me to further avoid for IPv6 in my head. I did see an RFC a while back that talked about network interception of protocols for carriers (for caching and inspection) but I can’t find it to compare with this RFC. Anyone know about that one ?