This post strives to provide an overview where (and why) IPv6 is different from IPv4. The intended audience are folks with a solid understanding of IPv4 but not too much exposure to IPv6 so far (I hear such an audience still exists ;-), and the post is intentionally kept short (regular readers of this blog may imagine that I’d love to extensively rant on several of the below items. some of them would deserve full posts on their own). Also I won’t go into technical detail too much.
In a nutshell the post tries to summarize why, under the hood, IPv6 is quite different from IPv4, and what those differences are.
In order to understand certain elements of IPv6, it’s helpful to keep in mind that it was mainly developed in the mid-90s. It hence tried to solve some of the issues & challenges found in networking at the time, besides introducing general new ideas.
For the purpose of this post the following objectives are of interest:
- autonomy: hosts should be able to come up with the configuration of basic IP parameters on their own, without the need for human intervention/administration or the need for additional services (like DHCP).
- (restoration of the) end-to-end principle: hosts should be able to communicate with each other without ‘the network’ providing functions besides simple packet forwarding.
- optimization: come up with some changes that ‘make network communications more efficient and hence faster’ such as replacing broadcast by multicast, or simplifying the IP header.
And, yes, the one main reason why IPv6 gets deployed in many environments today, that is larger address space, played a role, too.
The Unpleasant Reality
In case you’ve already been working a bit with IPv6, and you have scratched your head while reading the above section, thinking sth along the lines: “wait a second, those ideas haven’t really worked out, they’ve only been implemented half-baked, or they have even added a lot of complexity and operational pain”, you’re fully right.
Several factors have contributed to the mess we have today, like:
- Dynamics within standard bodies based on (seemingly) voluntary work like the IETF, including the composition of working groups, their politics plus the associated way of finding compromises etc.
- Over-engineering in general, further fueled by certain incentives within those working groups
- Lack of ‘feedback from the field’: during the first 15 years or so after the initial specification not much deployment happened, so nobody told those well-intentioned and smart – seriously, no irony here: they are, but the ecosystem is complex in itself – engineers that what many networks needed was just more address space, and that all the other shiny enhancements and features primarily introduced complexity and operational efforts. And things got worse with every year that passed, with regard to protocol complexity, and with regard to the inability to make fundamental changes of the design.
I’m aware that some of these things and developments are hard to understand from a technical perspective or from a 2021 point-of-view, but protocol development doesn’t happen in a vacuum, and of course in hindsight it’s always 20/20.
Point is: from a deployment perspective, accept IPv6 as it is (the boat for significant changes has long sailed), and drive the right conclusions for your operational decisions.
Technical Elements & Changes
In this section I’ll list some of the main technical elements of IPv6 which are new for those coming from IPv4, and which play a huge role in both the way how an IPv6 stack works (by default) and how ‘an IPv6-enabled network’ behaves in general:
- Router advertisements (‘RAs’): these are packets sent out by routers to their adjacent networks which carry information that enables hosts to perform autoconfiguration (remember the above autonomy objective). Understanding these packets, and their operational implications is crucial for smooth operations of the vast majority of IPv6 networks. I might add here that, based on some of the factors of the 2nd section, RAs are super-complex packets themselves, so they are somewhat metaphorical for the state of IPv6 ;-).
- The link-local address (‘LLA’): in contrast to IPv4 where one and the same address is usually used both for communication within a subnet and with remote hosts, IPv6 strictly differentiates between local communication and non-local communication (the latter happening through a router/’the default gateway’). This differentiation includes a special address only used for local purposes. It uses the prefix fe80::/10.
- Multicast: the approach of ‘general broadcasting’ when communication with multiple or ‘unknown’ hosts in the local subnet is needed, was replaced by using multicast groups (their addresses start with ‘ff’) for these types of communication. Combined with new/additional interactions (like RAs), at least in the local network (the ‘local link’ in IPv6 terms) one will usually see a lot of multicast traffic with different addresses, and for different purposes. Evidently this has a number of operational implications (which, again, are outside the scope of this post).
To some lesser extent one could add IPv6 extension headers (EHs) to this list, but – luckily – there’s a fair chance that many of you joining the IPv6 world in 2021 won’t ever see them in operational practice (besides security filters dropping them), so no need to discuss them further here.
As one can see, quite a few architectural changes have happened between IPv4 and IPv6. Understanding them can help to make well-informed decisions during the deployment of IPv6.