New Perspectives on the Active IPv4 Address Space | Hacker News Reader

New Perspectives on the Active IPv4 Address Space

arxiv.org

25 pointsjsnell13 comments

I wonder how much of this recent IPv4 address count stagnation OP is talking about, is in fact due to increasing prevalence of carrie-grade NAT as opposed to real IPv4 deployment slowdown.

I wonder how much IPv6 plays a role.

Once you go IPv6, you never go back. After dealing with the hell that is limited IPv4 address space, everything just seems so easy.

> Once you go IPv6, you never go back. After dealing with the hell that is limited IPv4 address space, everything just seems so easy.

When I first looked at IPv6, I found it odd that it used 128-bit addresses, when 64 bits would uniquely identify every device (and MAC addresses in practice were 48 bits, because almost nothing uses EUI-64).

Now I look at IPv6 and wish the address was large enough to hold a cryptographic hash.

The thing you quickly realize is that IPv6 isn't so much about a large number of 128 bit addresses, it's about a large number of 64 bit networks. Each network capable of handling essentially unlimited number of addresses.

So, when people talk about how many "Addresses" are available, they are barking up the wrong tree, they should talk about how many networks are available.

Ironically, I've seen tens of thousands of IPv6 networks deployed, and almost all of them are in RFC 4193 space, which is the equivalent of IPv4s RFC 1918 (10.x.x.x/8, 172.16.x.x/12, and 192.168.x.x/16).

But, unlike RFC 1918, where the space is constricted, and too many people use 10.1.x.x or 192.168.1.x, and end up in conflict, companies are pretty good about choosing a completely random ::/48 from FD::/8 - odds of a conflict are pretty minimal between two companies.

Yeah, everyone treats non-routable space as a security control. So expect to only see DMZs and edges of networks in the routable IPv6 space.

Non Routability has a really bad reputation, but enterprise/corporate IT people are fond of it.

The nice meet-in-the-middle approach is to use a RFC 4193 space + NAT-PT. Gives you close to best of both worlds - you get end-end connectivity, but full address portability with little effort when you change ISPs.

This is only true if you can get IPv6 connectivity to all your important locations. This turns out to be not so easy even in 2016. E.g. Charter Cable has no IPv6. AWS has no IPv6.

HE.net's free tunnel broker is pretty awesome. They'll even speak BGP to you for free if you have your own allocation, which is no longer that expensive.

Furthermore, simply using IPv6 internally - and you can route it over the internet via VPNs etc - is a huge win.

E.g. you can give each docker container a globally routable address. Globally might be 'within your network', or perhaps you have translators from global IP space to your own internally routable space at the edge of the network.

Don't you have all this with v4? Sure, but not as easily. With v6 you can route subnets and re-route sub-subnets. And you can do this all day long without running out of address space. Doing that in v4 is much harder.

AWS has supported IPv6 on the edge for several years. What they haven't supported is IPv6 internally. I sometimes wonder if it's because they are running a home-built IP stack on custom gear, and just haven't bothered to adding IPv6 yet.

The neither the newer VPC ELBs nor CloudFront support IPv6. Not even the Route53 DNS servers have an IPv6 address. With very few exceptions, there is no IPv6 support on AWS, internal or external.

Please, is it possible for someone to write a tl;dr for non english readers ?

Read the paragraph titled 9. CONCLUSION (on page 13 of the paper).

> Continued overall growth but lagging adoptionof IPv6 have brought a reimagined IPv4 upon us, one thatentails address sharing in both space and time.

Sums it up pretty good.

Reply on news.ycombinator.com