Stockholm Syndrome and IPv6 Address Planning - Guest Blog

Stockholm Syndrome and IPv6 Address Planning - Guest Blog [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Don’t be held hostage by IPv4 design requirements in IPv6.  Find out how Tom Coffeen likens the conservation of address space for host assignment in IPv6 addressing plans to Stockholm syndrome.

Guest blog post by Tom Coffeen

Early in my career I was helping a customer provision a DS3 point-to-point link (remember those?). When it came time to configure the IP addresses (and this was before formal certification of IPv6 as a protocol so they were all IPv4 addresses back then), the customer blithely informed me he would be using a routable /16 for the link. Though I hadn’t much networking experience at the time, I was pretty confident that using two addresses out of an available 65,534 was inelegant and wasteful at best, and possibly deserving of some form of corporal punishment at worst.

Flash-forward a decade to the first set of point-to-point links I was preparing to configure on a production network using IPv6. By that time, I had many network designs under my belt and had come to appreciate and rely on the address conservation efficiency provided by VLSM in IPv4. Rather than inelegance and waste, any network interface could be configured with a tidy number of available addresses to accommodate both use and growth.

And if that meant prefix disaggregation, so be it. I could always potentially aggregate my subnets at a higher level in the hierarchy (and if I couldn’t, there was always the fact that a /24 was Internet-routable). I didn’t feel like I had the luxury of time to be concerned with the fact that the IPv4 global routing table was hundreds of thousands of entries and was growing rapidly, consuming ever more router memory and making traffic optimization ever more complicated and costly. As long as I wasn’t wasting IPv4 addresses.

But back to my point-to-point links and their IPv6 address configuration. Based on my experience with IPv4, I naturally assumed such a subnet in IPv6 would be a /127, the minimum number of addresses required for the application. But the first recommendation I came across for a point-to-point link suggested using a /64.

Unsatisfied with that recommendation, I kept digging and found discussions regarding the potential security issues around using a /64 on a point-to-point link (later encapsulated in RFC 6164). Eventually, some were advocating a /127 where supported, but then suggested setting aside an entire /64 for each configured /127. So no matter what, every point-to-point link was going to get a /64. That is, 18 billion billion addresses. Or approximately four billion IPv4 Internets.

IPv6-IPv4 size comparison 1IPv6-IPv4 size comparison 2

Of course, this is also the standard allocation for every LAN interface as well. Given that any given LAN segment can only support a few thousand hosts at most, the quintillion or so remaining addresses in a /64 suggest that conservation has never been a primary concern in the address plan architecture of IPv6. (More evidence of this intent comes from the fact that further subnetting a /64 breaks SLAAC).

Which brings us to Stockholm syndrome.

Stockholm syndrome is defined by Wikipedia as “a psychological phenomenon in which hostages express empathy and sympathy and have positive feelings toward their captors, sometimes to the point of defending them.” For nearly two decades, network architects and engineers have been “held hostage” by an inescapable design requirement when working with IPv4 addressing plans: namely, the conservation of address space for host assignment.

But in designing our IPv6 addressing plan, we have been set free from our former captor in the form of conservation for its own sake. No more subnetting merely to accommodate host counts. Rather, we can now assign groups of prefixes (preferably on hexadecimal nibble boundaries) to location or use types to accommodate operational efficiency. Unused bits within our allocation and plan can be numbered into to accommodate unplanned growth.

And keep in mind that only 15% of the space available in the 2128 addresses available in IPv6 has been set aside for allocation. As routing expert Jeff Doyle recently pointed out in arguing that IP as a communication protocol “is more likely to become obsolete before we run out of IPv6 addresses,” even if the human population reaches the high estimate of 16 billion by 2100, that’s still 2200 /48s per person.

Of course, it is still entirely possible to over- or under-design leading to unnecessary allocation of prefixes. The abundance of IPv6 shouldn’t eliminate the importance of address planning that is as reasonably simple, scalable, flexible, and efficient as we can make it given the requirements of our networks. But we should keep any self-perceived extravagance on our part in the proper (3.4E38) perspective. And let waste now be avoided not out of necessity but rather because it may deprive our address plan of its viability and longevity (to say nothing of its elegance).

Where IPv6 address planning is concerned, it will be tragedy (then farce) if, instead of roaming free across such a practically boundless space, we all keep trying to climb back into our 32-bit cells (like victims of Stockholm syndrome). Instead, paraphrasing a 20th century mathematician’s famous tribute: Let no one expel us from the Paradise that IPv6 has created!

Tom Coffeen headshotTom Coffeen

IPv6 Evangelist

Infoblox

Blog

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.