Live data from Hacker News

A brief history of IPv4 address space exhaustion

blogs.igalia.com

51–60 of 89 posts

Re: A brief history of IPv4 address space exhaustion

#51

I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html EDIT: Dan has many excellent points, but I'd like to quote my favorite: The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space. Indeed, what were they thinking! It's certainly an undeniable fact that IPv6 ad…

> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

I respect djb and his contributions to cryptography, but he is off base here. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space.

Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.

IPv6 has lots of flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, etc.) that only looked good in the 90s, that definitely made ipv6 adoption a lot more painful than it needed to be, and ended up as difference for just difference's sake; but the one thing that was unambiguously done right with v6 was a completely clear separation of address spaces from IPv4.

Re: A brief history of IPv4 address space exhaustion

#52
post #45
post #38

Earlier quoted context omitted.

> One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other? Via a NAT router that talks v4 on one side and v6 on the other.

A NAT router is not enough. Suppose the v4 side wants to initiate the communication; to which address would it send the initial packet? Remember, the "v4 side" has no concept of extended addresses at all, for it every address must be 32 bits and nothing more. And it also doesn't solve the "v4 router in the middle of the path" problem.

v4 systems can only talk to other v4 systems.

If there's a system that has only v4, it can tunnel v6 packets out to a tunnel gateway that will unwrap and forward them.

There are other protocol-specific tricks, like v4 DNS records that resolve to a HTTP reverse proxy, which forwards based on hostname and path to the real v6 server, while the v6 DNS records point directly to the v6 server.

Re: A brief history of IPv4 address space exhaustion

#53
post #37

IPv4 is like any commodity. Now that it's not easily to get from ARIN, a market has sprung up around buying and selling it. It's still relatively easy to get IPv4 blocks for a buck or two per IP through auction houses.

Although whatever block you get has to be big enough to convince people to route to it. Too small and it won't matter. No ISP wants to carry the load for millions of tiny IPv4 blocks.

Re: A brief history of IPv4 address space exhaustion

#54
post #52
post #45

Earlier quoted context omitted.

A NAT router is not enough. Suppose the v4 side wants to initiate the communication; to which address would it send the initial packet? Remember, the "v4 side" has no concept of extended addresses at all, for it every address must be 32 bits and nothing more. And it also doesn't solve the "v4 router in the middle of the path" problem.

v4 systems can only talk to other v4 systems. If there's a system that has only v4, it can tunnel v6 packets out to a tunnel gateway that will unwrap and forward them. There are other protocol-specific tricks, like v4 DNS records that resolve to a HTTP reverse proxy, which forwards based on hostname and path to the real v6 server, while the v6 DNS records point directly to the v6 server.

> v4 systems can only talk to other v4 systems.

That depends on what you mean. A v4 packet can only be delivered unaltered to a v4 stack. But one can build a proxy server that tunnels TCP and UDP from a v4 network to a v6 network, so data can be passed from a v4 system to a v6 system without any software changes at either end.

Re: A brief history of IPv4 address space exhaustion

#55
post #45
post #38

Earlier quoted context omitted.

> One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other? Via a NAT router that talks v4 on one side and v6 on the other.

A NAT router is not enough. Suppose the v4 side wants to initiate the communication; to which address would it send the initial packet? Remember, the "v4 side" has no concept of extended addresses at all, for it every address must be 32 bits and nothing more. And it also doesn't solve the "v4 router in the middle of the path" problem.

> A NAT router is not enough. Suppose the v4 side wants to initiate the communication.

The router would also need to act as a DNS server and translate v6 responses into dynamically assigned v4 addresses. Routers routinely do this sort of thing today for captive portals.

Re: A brief history of IPv4 address space exhaustion

#56
When I was at UCLA, I learned this new architecture called NDN https://named-data.net/. It does not rely on addressable device or host. It give addresses to content. Not sure how industry think of this new idea. I watched several talks about NDN. They all have great stories and believe it's the future.

Re: A brief history of IPv4 address space exhaustion

#57
post #50
post #40

Earlier quoted context omitted.

I don't think it really matters what percent of clients are IPv6-capable. Nobody is incentivized to actually deploy servers to IPv6 while there exist zero IPv6-only clients.

The main benefit of IPv6 is that it allows all endpoints to have a real IPv6 address, including the ones that don't have a real IPv4 address. It serves its purpose if it allows end user devices to directly communicate with each other even if cloud servers with real IPv4 addresses continue to use IPv4 until the end of time.

Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made?

And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.

Re: A brief history of IPv4 address space exhaustion

#58
post #19
post #9

Unfortunately my perception is that IPv6 deployment is stalled (due to inaction by ISPs). In my company we have recently dismantled some of our IPv6 infrastructure because it became apparent that ubiquitous v6 connectivity was not coming any time soon (e.g. we have locations served by Charter/Spectrum, and they have no IPv6 and no plan to deploy it). We've instead deployed a private IPv4 overlay network between our s…

It's not, alas, a flip-a-switch upgrade, given how many CPEs and other equipment have shoddy or non-existent IPv6 support. Forward-thinking network operators (like Verizon Wireless or Comcast or T-Mobile USA) have taken advantage of the LTE and DOCSIS 3 transitions (which inherently involve installing and provisioning new hardware on a massive scale) to properly provision and deploy IPv6 to their customers. There's p…

The CPE problem is a bit of an elephant in the room. Just from my own experience, setting up IPv6 on my Comcast connection took quite a bit of fumbling around before I managed to hit on the right settings - and my router's GUI hardly even acknowledges the existence of IPv6 at all.

On the upside, I have a /60 to play with...

Re: A brief history of IPv4 address space exhaustion

#59
post #9

Unfortunately my perception is that IPv6 deployment is stalled (due to inaction by ISPs). In my company we have recently dismantled some of our IPv6 infrastructure because it became apparent that ubiquitous v6 connectivity was not coming any time soon (e.g. we have locations served by Charter/Spectrum, and they have no IPv6 and no plan to deploy it). We've instead deployed a private IPv4 overlay network between our s…

Charter/Spectrum is actively rolling out IPv6 to customers now: http://www.spectrum.net/support/internet/ipv6-faq/

Re: A brief history of IPv4 address space exhaustion

#60

I've only worked at one company that had full IPv6 support. Even on my current 1GbE fibre setup with a small startup, they still don't have IPv6 rolled out to residents yet. :( I feel like one big hurdle is IPv6 usability. You can write down and easily remember IPv4 addresses. IPv6 netmasks can get really confusing. They make sense if you expand out every block, but in reality, IPv6 requires a lot of tooling to chop…

I think this is the key point. It's too hard to understand, and adds a lot of what I would consider extraneous and over-engineered guff. People will naturally resist it when what they have, works.

The only thing that needed fixing was the address space (imo, as far as I can see), but if I need to turn it on, I now have to worry about weird routing, special addresses (IPv4 has some, but IPv6 seems to have taken it to a new level), understanding hexadecimal addresses, translation layers etc. What a mess, just extend the address space.

Post reply on HN