ARIN Finally Runs Out of IPv4 Addresses | Hacker News Reader

ARIN Finally Runs Out of IPv4 Addresses

networkworld.com

167 pointsjgrahamc180 comments

If IP addresses are scarce, why does it not seem to cost me anything to get one? I've had a bunch of online servers that came with a static IP, and an ISP service that came with one, at various times. It seldom seemed to be explicitly priced, and when it was the price was not really something worth considering.

Static or dynamic, the cost to the ISP is basically the same (perhaps a bit more for static if it's harder for them to manage the allocation); therefore, it's already built in to the cost of the service.

Have you tried getting additional IP addresses? One ISP charges me 50 cents/month per address for my colo box, while Comcast Business charges around $2/month (IIRC).

>Have you tried getting additional IP addresses?

Yeah. The price doesn't suggest scarcity. I guess the thing with the routing tables makes sense. I wonder if there's a way to rationalize that without it getting too messy. IIRC ipv6 thought of this and split up its address space in a roughly geographical way.

The price doesn't yet suggest scarcity because most ISPs have not yet had to start buying IP addresses because going to e.g. ARIN has been an option, and so they've not been pricing in acquisition costs.

It will rise, in proportion to the pain people experience in reducing their usage and/or switching to IPv6.

Because address allocation is inefficient and it is impractical to address this inefficiency in IPv4.

ARIN is out but your ISP has extras. Why doesn't your ISP sell its extras, since a scarce resource should have monetary value?

Routing tables.

Selling individual IPs off piecemeal isn't practical because routers simply do not have enough RAM to handle the enormous routing tables that would resultantly be necessary in order for packets to find their destinations.

I have a hard time seeing how IPv6 solves this problem. If we allocate them all individually, we have a world-shattering routing table problem. If we allocate them in gargantuan blocks, we have the same problem we have now with IPv4 -- we can't reallocate because routing becomes an impossible task. What am I missing? We're certainly not going to get the allocation right by doing it all at the beginning.

> If we allocate them in gargantuan blocks, we have the same problem we have now with IPv4

The problem with IPv4 is that when ISP can't get more, so they have to put some unlucky users behind a NAT. The company I worked for got /21, but we had way more than 2K simultaneously connected users. And, well, we failed the timing to get another allocation, and (I had left since then) is even more unlikely they'll get one those days.

IPv6 solves that by making all the blocks giant. With IPv6, when ISP is allocated /48 and allocates /64 per client - comparing to IPv4, it's like everyone gets a mighty /16 block right from the start, so even a tiniest company can grow to 65K users. And if they grow more, there is no problem in getting another subnet, those are not scarce, too.

With IPv6 the smallest allocation an ISP gets is a /32 (and it's pretty easy to get more as the ISP starts to fully utilize that /32). And even a small business can get a /48 from an ISP with almost no questions asked. That means, starting out, a company can grow to 65K networks (each network with effectively unlimited number of nodes on it). And, just as you said, getting another /48 won't be a problem.

Ouch. Yes. Sorry, you're absolutely right, it's /32, not /48. Was sleepy writing that comment and got numbers messed up in my head :)

The logic still stands, it's just that problem's solved by just making everything giant.

There are 2^128 IPv6 addresses. The number of "gargantuan blocks" possible with that many addresses is quite large. The problem of routing the allocated blocks is solved incrementally as needed by network expansion. In the event we need to route more than we can now routers are upgraded or topologies are changed.

With both IPv4 and IPv6, you want to allocate addresses hierarchically: network providers get large blocks, and delegate subsets to their customers. The problem is that with IPv4, addresses are scarce enough that customers only get as many as they can justify now (or in the immediate future). When that allocation runs out, they need to get another non-contiguous block. And this problem reoccurs on every level of the hierarchy, so ISPs themselves end up with lots of different blocks. Even if you manage to get a large block to allow for your own future expansion, you're just increasing the pressure on your neighbors.

With IPv6, we have enough bits of address space that we can drastically over-provision each level of delegation -- by orders of magnitude, if necessary -- and still have plenty of room to spare. e.g. as a home customer, my ISP gives me a /56 with no questions asked, which means 256 subnets each with an effectively unlimited number of devices.

In theory, this means it should become very rare for a single physical or logical network to have non-contiguous addresses. Which in turn means that routing tables can use a single prefix to cover an entire provider, instead of having to know about all of the individual sub-allocations.

In your example, your ISP has allocated you well over half the bits in an address. It's true that this is only 1/2^56 of the total space, but you can't overprovision very many levels to that extent no matter how long the addresses are (using the same proportions, the level above "home customer" might have a /25, the level above "ISP" might have a /10, and you could probably have two more levels on top of that with /5 and /2, although I'm not sure there's a lot of value in having a /2 layer protecting the /5. But I don't do internet routing; what do I know?

There are some rival pressures here:

- IPv6 space is so abundant (and cheap to allocate) that you can have as much as you ask for. This obviously leads to massive overdemand, after which it's hard to reallocate while preserving the idea that everyone who owns space owns one contiguous block.

- You can counter that by restricting how much people can ask for. But at that point you're not using the full space; you're restricted to the amount that can be allocated, which is smaller.

- Not everyone will be on board with "I'm going to take as much space as I can get, just in case I end up needing a million times as much space as expected." But some of those less-demanding people really will end up with addressing needs in excess of what they anticipated. We could call this the Hofstadter's Law ("it always takes longer than you expect, even after accounting for Hofstadter's Law") of addressing.

We can't expect everyone to get things right the first time; we need a working reallocation system. If reallocation doesn't work, abundance alone isn't going to save us.

> In your example, your ISP has allocated you well over half the bits in an address.

Eh, think of IPv6 as allocating from a 64 bit subnet space. So they're only allocating 1/8 of the address space.

> using the same proportions, the level above "home customer" might have a /25, the level above "ISP" might have a /10

More like /40 and /28

And once you are in the million-customer range you don't really need prefixes any more, but that gives room for more layers of generous prefixing and still having most of the address space spare.

Basically: you can't give everyone as much as they might ever ask for, but you can give everyone 10x as much as they seem to need and still have a dozen bits to spare

I think you've pretty much got it, but what makes it work is that you're overprovisioned at each level. You don't have to set up an addressing scheme that's guaranteed to be able to satisfy every conceivable request as a contiguous range. The extra buffer means that if you run out at one level, you can get another allocation from the next level up without having to advertise it globally.

Right now, if you need more IPv4 addresses, you have to buy a /22 or so from someone else. Because the address space is so hotly-contested, that block could come from almost anywhere, which means every core router on the internet needs to remember where it lives on the actual topology.

With IPv6, maybe once in a while a customer comes along who needs more than a /56. No big deal; you just give them another (maybe non-contiguous, if you're unlucky) allocation from the ISP's block. The ISP needs to remember that both allocations belong to the same customer, and route packets accordingly. But everyone else can just route based on the ISP's all-encompassing prefix. That's what makes the system fundamentally more scalable.

Really good point about the ISP just reaching into it's /32 allocation. Also, If there is the slightest chance that you will ever need more than a /56, (I.E. you are anything other than a vanilla home business account) the ISP will almost always give you a /48 right out of the gate anyways, and so you have on the very first day 65,536 subnetworks to work with. After that, everything you say is also true, if the customer starts to run low on those 65,536 subnetworks, the ISP can simply reach into it's /32, and then hand out a second /48 in the rare scenario that someone is using more than 65,536 subnetworks that need to be globally routed.

>In your example, your ISP has allocated you well over half the bits in an address.

The reason for that is because as of IPv6, DHCP is is no longer the standard way of getting an address. With IPv6 autoconfig each device assigns its own /64 address (either based on MAC, or randomly generated), thus subnets smaller than /64 are simply not practical for most use cases.

Having a /56 means you get 256 distinct subnets to assign as you please, just like you did with 192.168.0.0/16

> What am I missing?

A few things.

There's only 4,294,967,296 addresses in IPv4, so if you hand out giant blocks, you run out quite fast, whereas with 340,282,366,920,938,463,463,374,607,431,768,211,456 you could hand out huge IPv4 /8 sized blocks from now until the heat death of the sun if you wanted to.

But there's more to it than that. Right now only 1/8th of the IPv6 address space is "assigned to the internet", so there's effectively 7/8ths being held in reserve for the foreseable future -- this is partially to accommodate realistic router memory limits in the near term. IPv6 also has a more efficient hierarchical routing scheme than CIDR (which was kind of bolted on to IPv4 after-the-fact), which helps keep router tables from consuming terabytes of RAM. And IPv6 is designed to be more easily renumberable when we do make mistakes with assignments, with a clear separation between subnet prefix all that requires is changing the routing prefix.

At the end of the day, with 340 trillion trillion trillion addresses, handing out too many isn't ever going to be a big worry in the foreseeable lifetime of...anything, really.

> At the end of the day, with 340 trillion trillion trillion addresses, handing out too many isn't ever going to be a big worry in the foreseeable lifetime of...anything, really.

Well, why can't I have them all?

You'll have to settle for a measly trillion of them

Certain DARPA-funded emerging technologies[1] will more than likely need just a wee bit more than "a measly trillion".

Before spending some time in a wireless sensor net research lab as an undergrad, I had a difficult time imagining the scale of an application that could justify such a massive network address space...probably because I was too focused on trying to visualize what it might look like without considering the possibility that it would be invisible to the human eye.

[1] http://www.eecs.berkeley.edu/~pister/SmartDust/SmartDustBAA9...

consider that there are something like 3.35 * 10^22 water molecules on earth

there are 3.4 * 10^38 addresses in the IPv6 space

we could individual address every water molecule on earth and still have an enormous amount of space left over

so even if DARPA is planning on replacing the oceans with dust (and somehow managing to not exhaust a number of critical resources in this drive to make a truly staggering volume of dust), it's still not an issue

My thought process isn't as terrestrially constrained...qualitatively science fiction by today's measure, to be frank.

I was thinking more along the lines of an architecture adopted today which survives many millennia into the future that accounts for exponential human population growth on a galactic scale, isn't limited by the natural resources of this planet, where increment() will be the only pragmatic address assignment operation, meaningful archaeologic insight might be attained by discovering a microscopic 128-bit invariant, and so on.

I mean, yes, IPv6 fails the improbable science-fiction wish-list test, for any number of reasons beyond address space

path MTU discovery algorithms aren't going to be efficient when packet transit times are measured in decades, for one thing

> There's only 4,294,967,296 addresses in IPv4

In an internet-usable sense, there's fewer than that, too. The entire 127.0.0.0/8 block is for localhost/loopback, for example.

https://en.wikipedia.org/wiki/IPv4#Special-use_addresses

Worse: 224.0.0.0/4 and 240.0.0.0/4 are reserved, have always been reserved, and cannot in any practical terms be allocated, as there's huge amounts of hardware and software in production that's hard-coded to treat them as invalid. That's 1/8 of the entire IPv4 address space that's completely unusable.

224.0.0.0/4 is IPv4 multicast space. It's not reserved and often in active use. [0]

If there's software that treats IP traffic to or from 240.0.0.0/4 as invalid, then it's defective. I mean, I get that the broken software is a concern, but -if we care about carving out more IPv4 space- it's not something that we should be overly worried about. :)

[0] Indeed, mDNS/Bonjour/Avahi uses 224.0.0.251 for service discovery.

Perhaps I should clarify: That range isn't general-purpose IP space. And while multicast is useful, there's probably ways to implement it without sacrificing 1/16 of the entire address space.

> ...while multicast is useful, there's probably ways to implement it without sacrificing 1/16 of the entire address space.

It's far too late for that now. :( Perhaps if IPv4 multicast were more widely used on The Internet the large carve-out would look more sensible to you.

> That range isn't general-purpose IP space.

Yeah, that's a true statement. Just remember that "reserved" has a particular meaning when it comes to IP address ranges. :)

> There's only 4,294,967,296 addresses in IPv4, so if you hand out giant blocks, you run out quite fast, whereas with 340,282,366,920,938,463,463,374,607,431,768,211,456 you could hand out huge IPv4 /8 sized blocks from now until the heat death of the sun if you wanted to.

Well, according to [1] the sun will stay white-hot effectively forever. But, given that it will continue in its current state for another 5 billion years, and that there are 2^96 IPv4-sized blocks in IPv6's address space, one could give out 2.5e21 IPv4-sized blocks every second from now until the end of the sun's lifespan.

So yeah, IPv6's address space is really, really, tremendously, amazingly, enormously big.

[1] http://astrosociety.org/edu/publications/tnl/39/sun2.html

This made me realize just how big a 128-bit key in cryptography really is.

Indeed! It's bonkers. My college security professor once described a 128-bit key to us by imagining that every electron estimated to be in the known universe (think on this concept for a moment) had it's own unique value.

For a 256-bit key, give each electron from above it's own universe, and assign values to all. That's the keyspace to be broken.

Bruce Schneier once did a little thought exercise where he demonstrated that, assuming one needed to shift one electron (the absolute minimal amount needed to conceive of a compute switching operation), the energy requirements needed to brute force the key would exhaust the energy potential of the solar system.

"These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space."

Interesting to ponder.

(Source: https://www.schneier.com/blog/archives/2009/09/the_doghouse_... )

I suppose the idiom is normally supposed to be "heat death of the universe", but yeah, either way, the IPv6 address space is just galactically, unfathomably huge

I was trying to explain this to my boss the other week and after a little wolfram alpha came up with it being a lot less than the number of atoms in the universe but a lot more than the number of stars.

Seemed close enough.

The fact that only 1/8th is assigned to "the Internet" right now is worrying. After all, we know how that worked out with the 240.0.0.0/4 range in IPv4 - it was reserved for future use, but was never able to be used because by the time it would have been useful, everything classed it as non-routable. It's a huge swath of addresses that just can't be used.

The only solution to that sort of thing is just to be bloody minded.

Make it known from the start that when the currently unallocated blocks are needed they will be used, and if that breaks things for people who have used them already that is their fault and their problem to fix.

To be clear, I don't mean that 240.0.0.0/4 isn't able to be globally routable because everybody's using it for their own private stuff. I mean that 240.0.0.0/4 isn't routable at all.

Even if everything and everyone fails to learn the lesson of 240.0.0.0, and ignores the standard, and hard-codes the assumption that 7/8's of IPv6 is unusable forevermore, 1/8 of 340 trillion trillion trillion is still unfathomably huge

> And IPv6 is designed to be more easily renumberable

Can you point me to some information about this? I apologize if this is an easy question I am interested in ipv6 but only know enough to be confused more often than not.

> At the end of the day, with 340 trillion trillion trillion addresses, handing out too many isn't ever going to be a big worry in the foreseeable lifetime of...anything, really.

Gates already made that mistake.

I know "this time is different", but if you start thinking of "internet of things", where literally every little thing in the world can be called (so needs its own name/number/ip/etc), then at some point we might run out of those numbers as well.

I'm not sure how much (2^128) / 7 000 000 000 is, but it seemed not alot of every human's property can have its own address.

Every human can have trillions of addresses and not use that up.

Then every "device" you have connected with every other person's device might need its own public address.

And all of sudden, 640 kilobytes is not enough.

> I'm not sure how much (2^128) / 7 000 000 000 is, but it seemed not alot of every human's property can have its own address.

Well, to put it into perspective, imagine that humans would colonize planets around all 400 billion stars in our galaxy (let's say that each star has 10 planets), with 7 billion people on each of them, and each person having 7 billion devices, each device could still have almost 2 million unique addresses available. The range by itself IS big enough for any foreseeable future. The problem may come from the fact that not all that range is available for use.

"At the end of the day, with 340 trillion trillion trillion addresses, handing out too many isn't ever going to be a big worry in the foreseeable lifetime of...anything, really."

This is untrue, and a big over exaggeration.

Consider that pretty much any business (even a mom-and-pop shop) is allocated a /48 if they ask for it. Assuming one thousand /48 are allocated every second (ie. one thousand "business" IPv6 users coming online per second, which might be absolutely plausible 100+ years from now --we made IPv6 to be future proof right?), then we would run out of allocatable blocks in the global unicast IPv6 space (2000::/3) in 1,115 years. And we would run out of allocatable blocks in the entire IPv6 space in 8,919 years. So, yeah, I get annoyed when people mention the "death of the sun" or the "lifetime of the universe" when talking about IPv6, when in fact we could start running into exhaustion issues in the next ~1000 years.

Note that I am being pedantic here. I think any technology that seems to scale "only" for our needs up to ~1000 years from now is good enough :)

By my calculations, you could assign 1000 /48 subnets per second for 4.8 trillion years before exhausting that space.

http://www.wolframalpha.com/input/?i=%282%5E125%29%2F%282%5E...

You made an error. 2^48 should be replaced with 2^(128-48): http://www.wolframalpha.com/input/?i=%282%5E125%29%2F%282%5E...

That seems.. correct. My bad!

The statement about IPv6 [internet] having 2^128 addresses is completely and utterly untrue, in the same way as it would be untrue to claim that IPv4 [internet] have 2^48 TCP ports.

What IPv6 have address-space-wise, is 2^64 subnets, out of which 2^61 is actually allocated to be routable over public internet.

Then comes granularity of /48 allocations (= 2^16 subnets) to end users and /32 allocations (= 2^32 subnets) to ISPs. That gives just 2^45 end users and 2^29 ISPs at best. In practice, if handing a user a /48 would become a common practice, all medium and large IPSs would start accumulating multiple /32s, then routing concerns would come back, and largest ISPs will start aggregating to /28s or /24s or whatnot.

That is still a whole lot of addresses (and IPv4 still looks laughably small in comparison), but actual, practical numbers are way, way lower then "340 undecillion" marketing figure being plastered all over the place.

From what I've read, most end users will get /56 blocks and larger organizations will be the ones to get a /48, so the potential end users is much higher than you've estimated.

Blanket policy of /48 per end user comes from a (now obsolete) RFC3177. All RIRs now have less generous recommendations - both RIPE [0] and ARIN [1] seem to operate in /56 granularity nowadays, which is a very sensible step forward of course.

[0] https://www.ripe.net/publications/docs/ripe-650

[1] https://www.arin.net/policy/nrpm.html#six7

Let's say we make a list of all IP allocations today. We could replace each of them with 16 million unlimited-size subnets worth of address space, and we'd still only be using .00004% of IPv6. And that's before we consolidate multiple blocks owned by the same user.

There are currently half a million active BGP entries. There's no reason to massively change that number.

To be specific here, RAM is not the problem. It's often on-chip memory/TCAM. RAM is abundant. The place where the hardware actually installs the routes (the data plane/FIB) is often constrained.

Good clarification

Seems it'd be nice to "defragment" the IP address allocations, but totally infeasible since everyone's IPs would change and all the DNS records would point to the wrong places.

/24 can easily be moved. And if I have 65000 /24s with varying utilization (like Apple,) and could turn that into money by coalescing and adding NAT, that would drive change.

Because IP addresses are NOT scarce. They are so plentiful and so cheap that a single residential user will get a /54 block containing 18 billion billion IPv6 addresses.

There is no catch. All you have to do is use IPv6 (which you are already using unless you have explicitly turned it off). Many people have IPv6 network traffic running on their networks without even realizing it because it is included by default with every operating system.

The article that was posted only refers to the old-fashioned simplistic IPv4 addresses and they are only still in use because too many graybeards want to stick with what they learned 30 years ago. Learning new technology is not that hard. Run with it.

Most consumer ISPs still do not support native IPv6 (at least here in Canada, pretty sure it's about the same in the US). OS support is one thing, but actually having network access is another.

Comcast, the largest isp in the US, already claims to have ipv6 support in all markets since 2014. AT&T the next largest also claims full support. I would guess the majority of US residential internet users have ipv6 support from their ISP but they are just not using it because they have old modems or routers that dont support ipv6

I can confirm that in San Francisco, I've had a DHCPv6-PD assigned allocation for far longer than a year. When Comcast claimed to throw the switch to enable IPv6 for all of their residential customers a while back, something wonky happened to my IPv6 service (and stayed happened for several days) that required me to reboot my cable modem (which then proceeded to download a new config file and reboot several times) in order to resolve it.

I actually think this is less true than it used to be; the problem now is mainly on the server side. A substantial fraction of US residential customers can get IPv6 access as long as their network equipment supports it. But aside from a few prominent names -- like Google, Wikipedia, and Facebook -- the vast majority of the internet is only accessible if you have a v4 address.

From the latest statistics I could find, about 7-8% of Google visitors are connecting via IPv6 [1], but only about 1% of the Alexa top 10,000 sites are v6-enabled. [2]

[1]: https://www.google.com/intl/en/ipv6/statistics.html

[2]: https://www.vyncke.org/ipv6status/allgreen.php

that 7-8% is also worldwide, in the US it is 21% now

at least here in Canada, pretty sure it's about the same in the US).

We're getting there. TWC is one of the largest ISP's in the US, IIRC, and they have said they have IPv6 support for about 90% of their residential network. Anecdotally, I started getting an IPv6 address from DHCP on my cable-modem connection about 2 months ago.

We're a long way from full IPv6 coverage, but now you finally start to get the sense that it's real, whereas in the past (even a year ago) it was easy to wonder if the ISPs and what-not were even really trying.

>90% of their residential network

I'd like to see where that number is coming from. I've been a TWC subscriber for 9 years, I currently subscribe to their fastest residential offering in my region as well as one of their commercial offerings in the same region.

Both modems are DOCSIS 3 and IPv6 capable, neither receive IPv6 addresses. I have an AICCU tunnel setup on my residential, though it only gets a fraction of the potential performance. (Rather annoyingly the tunnel's routing is also far from perfect: for e.g I can't reach Netflix via IPv6; but because the DNS resolves it doesn't attempt to downgrade to IPv4.)

Considering I'm only 2 hops from their Chicago POP I sincerely doubt they have anything approaching 90% IPv6 rollout.

I'd like to see where that number is coming from.

I don't know how they arrive at it, or how accurate it is, but here's what they claim:

http://www.timewarnercable.com/en/support/internet/topics/ip...

    Time Warner Cable was an inaugural participant in World IPv6 Launch.  
    TWC has rolled out IPv6 to over 90% of its residential network.

Both modems are DOCSIS 3 and IPv6 capable, neither receive IPv6 addresses.

FWIW, I have a relatively new Netgear router (as in, about a year old, maybe less) but even after TWC upgraded my cable modem to one of the newest ones, I still did not get an IPv6 address until I updated to the latest firmware on the Netgear router. Depending on what you have hanging off of your cable modem, I suppose there's a chance that you're not getting an IPv6 address because of some issue on that device, as opposed to TWC's network itself.

at least here in Canada

TekSavvy covers some of the bigger centers in Canada and has supported IPv6 for some time.

The price of an IP is usually included in the price of the service. Note that in some parts of Southeast Asia, you can pay for a cheaper "web access" which is not a full Internet connection with a public IP, but essentially puts you in a huge LAN behind a NAT.

Because while those IPs have been allocated it does not mean they're being currently used.

So, ARIN can't allocate any more to providers but many providers are not yet feeling the pinch yet so they're not passing the cost onto you.

Give it a time and you'll start seeing IPv4's coming at a premium and IPv6's being free.

edit

Also interesting, check out whose holding the /8's. [1] Some of them make sense like AT&T, but others don't...like MIT. Why's a university holding 224 ip addresses? Well, they just happen to be one of the first network holders. HP has 2 /8's which sounds pretty absurd (unless there's some reason I don't know that HP needs over 32 million ip addresses).

One of HP's allocations is from DEC I believe.

Yeah, it is. But that's a hell of a lot of real estate for a single vendor whose not even providing significant network services.

> Why's a university holding 224 ip addresses?

224? A /8 leaves 24 bits for the hosts. That's 16.7M addresses

Presumably that was supposed to be 2^24.

That would be correct.

It does cost you, it's just calculated into the price of the service.

Try looking at for example a service like LowEndSpirit[1], which offers NATed VPS services for 3 euro a year(!) - it would be literally impossible to offer this service with a dedicated IPv4 address, and indeed the dedicated IPv4 VPS services typically start at $12-$15 per year.

Most of that $12-$15 is IP costs.

[1] http://lowendspirit.com/index.html

EDIT: Oh yes, no Markdown. Right.

We just did an internal migration to some ipv6 for some of our internal code so we could communicate with sites that use ipv6...

Long story short, it was hard. Required custom lib recompilations, etc.

I don't have all the details but it was significantly harder than I originally thought.

https://www.arin.net/resources/request/ipv4_countdown.html Looks like 9 /24's remain

Considering there were once hundreds of millions kicking around and being handed out like candy, having about two thousand left is basically nothing.

It's like saying the grocery store isn't cleaned out, there's still a single jar of peanut butter left.

My current company has maybe 100 left to sell virtual server hosting with. Sometime in the next year this fact will reach management and we'll be going on a harvesting spree to reclaim them from elsewhere. All of which is ridiculous.

It's empty now.

It's worth noting that APNIC, LACNIC, and RIPE all ran out of IPv4 addresses years ago (2011, 2014, 2012, respectively). Although, by the definition of exhaustion those organizations used (roughly "someone requested a block that we couldn't fulfill), ARIN ran out seweral months ago.

What this announcement really amounts to is "we cannot give out anymore IPv4 addresses." ARIN lists just 9 /24 blocks. By contrast, RIPE bottomed out at about .8 of a /8--about 6000 times the current ARIN IPv4 address pool. RIPE, for example, hit its . By contrast, ARIN is at 9 /24s.

Require payment of $1 per year per public IP, and suddenly wastrels like the Apple class A will be available again...

How would you go about enforcing that. and enforcing that is still covering up the issue that we really do need to move to IPv6

Why would that be hard to enforce?

Modifying a contract usually requires the consent of both parties. If IANA/ARIN tried to claw those IPs back from Apple, and Apple sued to stop them, who do you think would win?

They could enforce renting (vs owning) going forward with all new assignments, but that will probably just encourage even more hoarding of existing space.

My understanding is that at least ARIN holds the position that IP allocations are not property that the recipients own.

Since Apple's allocation predates the existence of ARIN, is ARIN's position relevant?

More to the point, the IPs were assigned to Apple by some agreement more or less akin to a perpetual lease. Under what conditions can that lease be terminated? (Actually some of the earliest allocation were apparently because "Postel says so". But probably still close enough to a handshake deal to be valid.)

  > Actually some of the earliest allocation were 
  > apparently because "Postel says so"

Postel's other, lesser known, law?

> If IANA/ARIN tried to claw those IPs back from Apple, and Apple sued to stop them, who do you think would win?

IANA and ARIN, historically. You don't ever own your IPs, no more than you own your phone number.

That's doesn't appear true for legacy blocks. They are, effectively, owned. ARIN can't "claw back" legacy IPs which were assigned before ARIN ever existed.

I own legacy IPs. And I pay nothing, because I did not sign the ARIN registration agreement. If they could force me to pay by threatening to revoke my IPs, they would have done it already.

Nothing stops someone else from announcing those IP blocks. You would be hard pressed to prove ownership in court.

Yes, that's the solution. Whoever announces a block the loudest gets to use it.

You may also want to look into concepts such as water rights. Nothing stops you from draining all the water out of the Colorado river upstream. Except the things that do...

I don't have a dog in this fight, as I don't manage network edges, AS, etc anymore. I'm simply stating that if you fight against ARIN, you'll lose. You're free to try, I've got better things to do.

http://www.finnegan.com/resources/articles/articlesdetail.as...

Uhm, did you read your link? There's nothing in it about losing if you fight ARIN. It's pretty clear ARIN knows they'll lose, which is why they're badgering people into signing these legacy agreements. So they'll be brought under control. If ARIN had authority, they wouldn't be asking for companies to volunteer it to them.

Or we could decide that the internet is important to society and pass some laws that gives IP allocation some claws, at least in the US. But, because the US works like it does, that doesn't happen. Win some, lose some.

People already shit bricks when the government seizes .com domains. I can't wait to see what happens when they seize AS numbers too. "OMG, those imperialist bastards think they can regulate the internet!"

You misunderstood, I think. My organization name is in the ARIN registration database from the early days of the internet. Most ISPs require some proof of ownership to do the BGP announcement (address, name match, etc.) My /24 block is announced and routed to my home network, by the way.

To what end? Reclaiming allocations would only prolong the painful transition to IPv6 which has already been going on for too long. For the internet at large IPv4 exhaustion is a good thing because it moves IPv6 forwards. The quicker we can get rid of IPv4 the better.

This. Running dual stack networks is harder and more expensive to manage, secure and troubleshoot.

The faster we get to single stack ipv6 only, the better.

Single stack IPv6 is just not happening; there's just WAY TOO MUCH STUFF out there that only speaks IPv4.

We just need to wait for all that stuff to become obsolete.

Yeah, but you can have that only at the edges, using ipv4-to-ipv6 proxies to connect to the Internet.

Yep; this is what T-Mobile already does if you set your phone's APN to "IPv6 only".

Similarly, my cable modem (which is distinct from my router) only gets an IPv6 address from Comcast.

That's only a management interface tho, the modem will still happily forward ipv4.

what icebraining said: use a nat64+dns64 at the edge of your network and make all your endpoints ipv6 only.

If you're an ISP, you could probably put multiple nat64 boxes in the core so that all your customers benefit from it and can gradually switch ipv4 off (since they can transparently reach ipv4 endpoints through the nat64 gateway).

Then there are a few applications that don't handle ipv6 properly (i.e. skype), and Apple's decision of mandating ipv6 support is meant to fix just that.

Then there is 4XLAT, ds-lite and others which allow for a single stack ipv6 network and carry ipv4 on top of it to the endpoints which need it.

IANA was allocating at a rate of 2 /8s per month right before they ran out.

Recovering an /8 would take staggeringly more effort than it is worth in terms of how little it fills existing demand.

There is no scheme that will make IPv4 work in the long-term. The mathematics are very simple. You cannot fill demand for exponentially more than 4 billion numbers with a pool of only 4 billion numbers.

but do we need 4 billion numbers? I thought things like NAT make the global static IP utility less than needing every other person to have an IP address

I think a point here is that NAT isn't long term sustainable. We seem to be teetering on the point where NAT Traversal becomes almost impossible to reliably do and the concept of a single internet breaks down, one NAT black box network at a time. Already there are systems that really can only communicate via HTTP to the global internet and then only if they initiate the request. To some people that is a "feature" and the future of firewalls, but I don't want to live on an internet where you have maybe one reliable protocol and a pull-only view of that one protocol at that...

There's a difference between "pull" and "initiate." NAT traversal is getting better over time, not worse. (Says data from gaming platforms) You only /really/ need more than one IP if you want to expose more than 65000 different services from a single physical place. But, instead of solving this through economics and ingenuity (which we knew could, and had to be done 10 or even 20 years ago) we let device vendors and academics run the show into IPv6. Which doesn't solve the /real/ problem we're /actually/ having: devices change connectivity every 5 minutes and move continents in a few hours. IPv6 just doesn't have an answer.

> NAT traversal is getting better over time, not worse. (Says data from gaming platforms) You only /really/ need more than one IP if you want to expose more than 65000 different services from a single physical place

There's a big, huge, insurmountable difference between home NAT traversal, with port-forwarding, and Carrier-grade NAT traversal, where fuck you and your ports.

Yes, there's a difference between "pull" and "initiate", but it is academic to my point/hyperbole. Also, yes, UPnP Port Forwarding has made less of a mess in the case of most modern "home" NATs, and this does show up nicely in gaming platforms. UPnP Port Forwarding is a nice kludge. Have you seen how much code and effort is involved in kludges like UPnP Port Forwarding? The game platforms are getting better at it over time mostly because the good platforms can spend a lot of money building the necessary complex software.

But we're already leaving behind the case where a single NAT near the edge of the network graph (the "home") is sufficient and are starting to see larger deployments of "carrier-grade NAT". So far as I know there is no equivalent kludge to UPnP Port Forwarding that works reliably on that scale, and building such a kludge seems like a major question of what sort of internet topology we really want. For hyperbole's sake, "carrier-grade NAT" and other similar cases of NATs speaking to NATs that what we're talking about is ultimately a balkanization of the internet, breaking the internet back into sub-networks of various addressability.

Even with economic incentives, we'd still be running out of IPv4 addresses for all of the "physical places" in the world that have 65000 devices. More critically, with IPv4 we've already hit scaling problems with the size of routing tables for the physical places that connect to the internet, we can't easily do "per-IP routing" and there aren't economic incentives that will quickly change that.

Ultimately, I'm wondering if this is the confusion you are having: IP (v4 or v6) is about the physical routing to the places of the internet. IPv6 doesn't have answers to device connectivity or movement because that's not its job. Logical Device to Physical IP Address mapping is the job of internet layers like DNS and mDNS/Bonjour. NAT is a series of hacks designed to deal with the fact that IPv4 doesn't do as great of a job at physical routing as we would like, now that we have millions of devices connecting to it every day. IPv6 is an actual attempt to fix how the internet does physical routing. It does solve the real problem we are actually having: physical routing on the internet. It solves it much better than NATs wish they could solve it, regardless of the "device vendors and academics" that "ran the show".

> So far as I know there is no equivalent kludge to UPnP Port Forwarding that works reliably on that scale

There's only Port Control Protocol, but almost no sane ISP will ever enable it, because it can't really solve much and the security implications make people really uncomfortable.

The big problem with carrier grade NAT is when you stick N people behind 1 IP, they can only have at most 65,536/N ports each. If you're a big city in India, say, and N=1000, that's 65 ports per person.

Your ports-per-person is your ceiling on maximum simultaneous TCP sessions per person. 65 ports is barely enough for a few browser tabs to be open simultaneously, and god help you if you've got another layer of NAT at the household level (which you probably do) and you're splitting those 65 ports between 2 or 3 other people (which you probably are).

Consequently, browsing the internet is a fraught process in a lot of places with carrier grade NAT. You can absolutely forget about P2P or anything else complex and port-hungry.

Carrier grade NAT is a disaster for end users, unless you want to do little more than browse the web unreliably.

Multiplayer gaming, peer-to-peer anything really, is an unmitigated shitshow under heavy NAT.

You definitely do not want carrier grade NAT to become entrenched in North America, like it already is in Asia.

And at some point, even if we did want it, we'd run out of numbers for people who want to serve content, and at that point NAT isn't going to do anything for you, and the barrier for entry for new web businesses becomes sky high.

I think you mean /24?

Nope. They've been allocating at least several /24's per day even since getting down to their last /8.

Only two /24s a month? Demand hasn't been that low in ages.

Unfortunately that would prolong the life of IPv4.

Like it or not, we're going to be stuck with it for at least twenty years.

What's probably going to happen is a marketplace will open up and unused IP blocks will go to those willing to pay for them. Eventually the cost of deploying IPv6 will be less than the cost of IPv4 addresses.

That market already exists, although not centrally organized by the RIRs.

i am fairly certain RIRs do not allow this, though i know it was common practice for major hosting providers to buy up dinky/unprofitable companies which had larger legacy allocations purely for their address space.

Still is. Along with various other IP hoarding schemes. ColoCrossing is a notorious offender in this area, and has also been draining IPs from ARIN.

Apple would just pay the tab. So would Google. It wouldn't change anything.

If you're large enough to get allocations that huge, you're large enough to afford it.

Why is Apple a "wastrel" when it's building gigantic datacenters all over the place, yet MIT, who has an equal sized allocation for a university, is somehow fine?

It's not in Apple's interest to yield the block unless there's industry consensus and other companies and organizations with similar allocations are doing the same.

At $1 per IP, given that Apple has a /8, that'd be almost $17M. They could probably cut quite a bit of usage if they wanted to.

The real problem is that this doesn't make sense: we don't WANT IPv4 to persist. The sooner we all go to IPv6, the better.

Ideally, usage will gradually wane until only obsolete items even use IPv4, then a cutoff date will come from major ISPs and such cutting off IPv4 service and we'll finally pass the last hurdle.

At least, one might hope so.

$17M/year to avoid having to re-architect all the internal networking at a trillion-dollar company? Easier to just pay it, really.

They probably pay more than $17M a year on domain registrations. Just the cost of doing business.

"Like" Apple. All single company /8 are wasteful.

And the holders didn't get the /8 in modern times "because they are huge" they got them in ancient times because historical reasons.

The fact that we've treated those allocations as sacrosanct means that we're stupid political people, not engineers. (What else is new? :-)

Naww, make it $50, which is close to what we pay for domain registration renewal. Now watch everyone give up all those IPs they've been hording. Apple has 16m IPv4 addresses, that's $800m right there. They're not dropping nearly $1b annually to hoard IPv4.

At a rate of $1B per year, they'll be out of cash in... 300 years.

I don't think shareholders would be happy spending that kind of money on things they don't use and probably will never use now that v6 is on the table.

So a class A would cost $16M /year to hold? I think folks should just move to V6 in all its silliness and be done with it.

Why single out Apple?

The US Government owns:

  6.0.0.0/8
  7.0.0.0/8
  11.0.0.0/8
  21.0.0.0/8
  22.0.0.0/8
  26.0.0.0/8
  28.0.0.0/8
  29.0.0.0/8
  30.0.0.0/8
  33.0.0.0/8
  55.0.0.0/8
  56.0.0.0/8
  214.0.0.0/8
  215.0.0.0/8

HP also owns 2 /8's, 15.0.0.0/8 and 16.0.0.0/8

Because they are easy pickings? MIT, USGOV and HP deserve equal pressure, of course!

Aren't they allocating ipv6 IPs in a similar way though? the only difference is exponentially more addresses to a single company...

While it's sad that there are so many large and unused blocks (Apple, DoD, etc), whats worse is the disgraceful adoption of IPv6 by ISP's.

Despite all the hate that Comcast (deservedly) gets, they do bring IPv6 to my apartment. Good on them for being on the ball.

Not bad that! Here (UK) we have yet to see a major ISP embrace IPv6 properly.

> Despite all the hate that Comcast (deservedly) gets, they do bring IPv6 to my apartment. Good on them for being on the ball.

Which would be great if everyone was running IPv6 - however my experiences is that some IPv6->IPv4 tunnels break some protocols (like T-Mobile's IPv6->IPv4 tunnel - I have to use IPv4 because their tunnel appears to break SIP connections. I'm not sure if they did that on purpose for suspect reasons. And of course - they don't make this easy...).

No, SIP is a terrible protocol so things will often break unintentionally. A lot of NATs also try to "fixup" the breakage and make it worse.

> No, SIP is a terrible protocol so things will often break unintentionally.

I use Asterisk and I've never had random problems with SIP. All my problems have been due to network (such as firewalls or network disconnected) or client implementations. I've found this article which makes me laugh [1]:

> The solution is remarkably easy!

If it's so easy - why doesn't he create an RFC proposal for a SIP 2.0?

SIP isn't the only protocol that isn't flawless. FTP and VPN comes to mind.

But here is an article that states exactly what I said and experienced [2]:

> SIP works fine in either an IPv4-only or IPv6-only environment, but issues arise in a mixed environment.

[1] http://www.talkingpointz.com/why-sip-sucks

[2] http://www.networkcomputing.com/networking/can-sip-and-ipv6-...?

Yes, FTP has an atrociously bad design. The difference is that SIP wasn't made in the early 80s, so what's their excuse? VPNs typically do OK, except IPSec because the IETF didn't want to admit that NAT existed (though I believe they cleaned that up with an add-on and things are mostly fine now.) As an end-user, hopefully your implementors have solved most problems for ya. As an implementor, SIP is a curse. (HTTP, which SIP drew its nutty parsing rules from, recently ditched the entire format in preference of a binary format. Not related to the IP-embedding-galore that SIP added, but still interesting to note.)

SIP does not "work fine" in an IPv4 only environment, as any NAT user will attest to. It can, by ignoring the RFC and hoping that no middleware gets involved. (Middleware only gets involved because the RFC makes it a juicy target.)

> VPNs typically do OK

Assuming the network administrator has configured his router for VPN pass through [1].

> SIP does not "work fine" in an IPv4 only environment, as any NAT user will attest to.

Seems to work fine for me. The built in SIP client for Android works great in IPv4 both NAT and non-NAT. However, it seems to have some issues with IPv6 (not surprised due to the lack of feedback on the Android bug tracker...). Zoiper on the other hand will work through pretty much anything you throw at it.

I'm not saying SIP is perfect - but my experiences with SIP have been generally positive with Asterisk. Now I'm also in control of Asterisk and can tweak the configuration - I'm sure a lot of canned SIP systems are completely broken.

[1] http://www.tp-link.us/FAQ-558.html

> Which would be great if everyone was running IPv6...

1) The big players already are.

2) Residential availability of IPv6 will help make the business case for IPv6 activation for operators who have not yet been able to see the train barrelling down at them. (Something about eggs and chickens...)

3) ISTR that Comcast serves at least 20% of the US residential ISP market.

In the service provider industry, Comcast really have been the leaders in the deployment of IPv6. Most of their challenges are around crappy IPv6 implementations in customer equipment.

Doesn't matter one bit. Why do people trot out this hilariously wrong argument every time IPv4 comes up?

ARIN was burning 2 /8s per month before they ran out.

Let me repeat that: 2 /8s PER MONTH.

There is no clawback scheme that can make any amount of difference. At best we buy ourselves 1-2 years. In reality, taking back all the large unused blocks would buy us months.

Furthermore almost all of those large blocks were handed out before the RIRs existed and are owned so there is no legal mechanism to take them back even if it could make a difference.

One of the companies I worked for migrated from a public IP range to using the DoD 11.* address range for their internal network. That was always a fun subject when talking with the network guys.

IPv6 growth has slowed down to about 8% per month, as google counts. Where is the boundary between graceful adoption and disgraceful? 9%/month? 11? 50?

For the normal users out there. What are the implications? Is this simply IPs being reserved for servers on the internet?

One implication is that you may not get a real IPv4 address anymore. So your cable/DSL connection will be behind a Carrier grade NAT ( https://en.wikipedia.org/wiki/Carrier-grade_NAT ) which breaks applications and causes problems for your internet provider (technical complexity), for software developers (implementation of workarounds for CGNs) and for you, because you suffer the consequences.

Also, more expensive IP addresses raise the barrier to entry for new competitiors, so your internet connection may get more expensive.

The cost of entry argument is specious because everyone has the same variable cost.

The real cause of lack of competition is the cost of physical access.

Currently in the mobile space everyone is behind at least one double-NAT at least, and you can order business level access for your wireless data account and get an IPv4 address allocated to you. AT&T does this for a single $500 fee for example, Sprint as a monthly $3 fee. I imagine this will become common with ISPs - you'll need to upgrade to a gaming/business class in order to make use of port-forwarding etc and for everyone else, some programs will cease to work or not connect as quickly/easily.

And we can't switch to IPv6 ourselves? This this problem need to accelerate user switching (even if just the advanced users) or switching at the ISP level?

There are at least a million IPv4 not in use here:

https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...

Possibly 100+ million.

What the frack does Halliburton need with 16 million IP addresses?

On that note, US Department of Defense apparently does not just consume most of the US budget, it also consumes over 210 MILLION ip addresses.

There are also a quarter billion ip addresses in the E block, which is probably easier to reprogram all routers than get all consumer devices to support ipv6 properly.

The problem with this is that you will get X million "new" IP addresses. But in Y years you will have the same problems as we have now again, because the X million IPs are again consumed.

So it is much better to focus on the implementation of IPv6.

The E block is a lost cause: http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-...

> But in Y years you will have the same problems as we have now again,

Note that Y in this case is significantly less than 1.

I was a sysadmin for a division of Halliburton for over a decade (until this past January) and word came down the pipe that they were going to retire/give-back 134.132.x (owned by Landmark Graphics subsidiary) and work on moving off 10.x in the next few years.

Keep in mind that a lot of these allocations were made in the 80s and 90s when nobody worried about running out of IPv4 addresses; in addition I saw what we paid to ARIN every year just to "have" 10.x and it was an insane amount (I remember it being more than my yearly salary).

You paid for using 10.0.0.0/8? Am I reading this correctly?

Possibly meant 11/8 which has been abused as an extension of 10/8.

Typo; I meant 34.0.0.0/8.

Probably just a placeholder number used by someone who didn't think about what 10.x actually is.

Typo! 34.0.0.0/8. Sorry.

Typo; they have 34.0.0.0/8 and were discussing moving to 10.x internally last I remember.

To be fair, US DoD was the first organization to use TCP/IP. Perhaps these 210 million addresses are a legacy of ARPAnet.

I agree that they should probably be returned to IANA.

A lot of this is down to history. Way back when lots of these blocks were allocated, not only was IPV4 exhaustion a non-issue, but allocations were either in /16 or /8. So if 65 000 adresses (a /16) was too few, the next step up was 16 million.

There was a time when simply having a .net domain, which was free to register, entitled you to a free Class B /16 allocation.

If you were a company with any degree of credibility, it wasn't too hard to petition for a Class A allocation, /8. Apple and MIT managed.

Then CIDR (https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) came along and we had more than three sizes to offer, which really eased up on the crazy allocations.

All those /8 allocations created chaos in the routing tables. Now they're usually sub-allocations from larger blocks which makes the routing tables much more orderly. Anything in the 192.x.x.x range was once called "the swamp" since it was full of so many routes.

> What the frack does Halliburton need with 16 million IP addresses?

Who cares? If they gave them back to IANA tomorrow, IANA would be out again in 2 weeks, at the rate of demand they were seeing the last time they had any blocks to assign. It would probably last even less time, now.

Do the class A allocations suck in retrospect? Sure.

Is it worth flushing time, effort, and money on trying to recover them? Hell no.

Whatever amount of money it would cost Haliburton to restructure all of their internal networks and rewrite their applications to compactify their IPv4 usage would be far more efficiently spent if they simply used it to upgrade their infrastructure to IPv6.

Putting any money into IPv4 is just throwing good money after bad at this point.

Keep in mind when IPv4 was introduced the number of computers on the internet could be measured in the hundreds.

I really hope people don't shit on the original engineers. A 32-bit address space probably seemed stupidly, uselessly huge at that point in time.

I don't think anybody's out to shit on the original engineers.

That the decisions they made at the time made sense doesn't make them any less regrettable in retrospect.

Either way, it's a pointless argument anyways. There is no point to fixing those allocations because if you could snap your fingers and efficiently allocate IPv4 address today, we'd still be out and still have to switch to IPv6.

> That the decisions they made at the time made sense doesn't make them any less regrettable in retrospect.

They really couldn't have made any better decision at the time--TCP/IP dates to 1974!

Bits were expensive back then. Backbone links were 56K. The Intel 1103 1K DRAM was the biggest selling semiconductor in 1972 and had just replaced core memory.

The fact that they even allocated 32 bits (the wastrels!) was amazingly forward thinking.

> They really couldn't have made any better decision at the time

Is there some confusion about what the phrase "in retrospect" means?

Time is linear and we gain perspective as we move forward in it. Often times good, smart seeming decisions, or even the only possible decision that was possible at a given point, become regrettable when we view them with the added perspective of seeing how things ultimately played out.

This isn't a condemnation of anyone; it's a simple, obvious observation: knowing what we know now, some of the decisions we made then have had unfortunate, regrettable consequences, however necessary they were are the time. C'est la vie.

I think the point is that even with the ability to see the future, they would have still made the same choice, given technical limitations of the time. So there's nothing to regret and a retrospective view adds nothing.

> I think the point is that even with the ability to see the future, they would have still made the same choice, given technical limitations of the time. So there's nothing to regret

I disagree. We can regret the way something worked out even if we had no other choice to make. That's a pretty normal human thing to do.

But we could also regret that, eg) the technical limitations didn't drive them to choose an even smaller address space, one that would have lasted just long enough to get us to a point where we could move to maybe a 2^64 space in the 90s, instead of a space just big enough to become incredible hard to move out of, but not big enough that half the world isn't now living behind carrier grade NAT.

What the parent is saying is that had they implemented a scheme like IPv6 at the time, it would have been problematic for hardware reasons, so it wouldn't have made sense. He's right.

IPv6 is old now. It dates back from 1998. Engineers understood two decades ago that ipv4 would run out and it finally made sense to create something better.

> What the parent is saying is that had they implemented a scheme like IPv6 at the time, it would have been problematic for hardware reasons, so it wouldn't have made sense. He's right.

There is some spectacular failure of communication here.

What I am definitely not saying: they should have implemented IPv6 in 1978!

What you are apparently somehow reading: they should have implemented IPv6 in 1978!

Here's what I am saying: Some decisions made in 1978 have, with the perspective of time, had unfortunate, unforeseeable consequences.

This doesn't mean that IPv4 should have had a bloody 128 bit address space in 1978. Rather, it means that, with the perspective of time, we can see that some decisions made have really had dire consequences, and that what would have been counter-intuitive or less than optimal decisions at the time would have worked out better in the long run.

For instance, given the hardware limitations of the time, it would have worked out better in the long run if IPv4 had had a bit smaller address space. At 2^24, it would have lasted well into the early/mid-90s but needed to be replaced right around the huge growth spike, before anything got too entrenched, when there was ample opportunity to roll out a different addressing scheme.

2^32 has left us in an uncomfortable spot where it was big enough to have got us quite far and for us to have become incredibly dependent on it, but that means we also have really, really entrenched a lot of legacy hardware in everyone's homes and offices, and it's not big enough to allow have the world to not live behind carrier-grade NAT.

In a sense they did limit it. The "Class D" space has always been off-limits, so it's never been 2^32.

The usable range is 1.0.0.0 through 126.255.255.255 and 128.0.0.0 through 233.255.255.255. The rest is reserved for various reasons or used for other purposes. That nibbles about 10% of the address space away.

They could've imposed more limits this way, but that might've seemed too heavy handed and would just lead to severe hacks and work-arounds.

It's a Catch-22. Switching to an IPv6-like address space in the mid 1990s would've been easier, but if it caused a lot of turbulence, it would've slowed the adoption of the IP technology in the first place, meaning the conversion was less urgent.

No we would not. IPv4 with NAT can scale for a very, very long time. If we had been politically bold 20 years ago, or 10 years ago, we'd not have a problem for a long time to come. Instead, the cost of replacing software and devices for IPv6 is staggering and will depress other investment. And IPv6 doesn't even solve any other, modern networking proverbs any better than v4.

> IPv4 with NAT can scale for a very, very long time.

Sure it can. Just ask everyone in India and China sitting behind three levels of Carrier-Grade NAT how great that experience is.

And hey, working out a rotational schedule as to who gets to have the XBox Live ports to themselves on what night of the month is a great way to meet your neighbours.

And at that time, it was really hard to foresee how cheap and ubiquitous computers would be. Computers were still multi-user shared resources. A "personal computer" was still a dream.

Funnily enough, people have used DoD space internally, since large parts of it never where publicly announced. Until DoD gave some of it back... (granted, the people pulling such stunts probably still run it internally. And wonder why they can't reach some websites)

Yup happened to one company i worked for. We moved from a couple of public blocks to the DoD 11.* range internally. Then one day we could not access some Oracle hosted services as they where using the range.

Some people are encoding IP addresses inside smartcards and similar electronic devices. There are all sorts of schemes out there such as devices that user their hardcoded IP address to send packets and network gateways use routing rules to decide whether to forward or drop the traffic.

Fact is that if you want a GLOBALLY UNIQUE IP address, then IPv6 is the ONLY way to get one. It has been over 20 years since IPv4 addresses ceased to be globally unique.

> Fact is that if you want a GLOBALLY UNIQUE IP address, then IPv6 is the ONLY way to get one.

Pardon?

Just as any yahoo can choose to manually assign the IPv4 address assigned to my border router to a machine on his internal network, he can choose to do the same thing with its IPv6 address.

My border router has a globally unique IPv4 address and a globally unique IPv6 address, inasmuch as any IP address in globally-routable space can be globally unique.

Reply on news.ycombinator.com