Talk:IPv4 address exhaustion

Hierarchy

I removed the references to hierarchy because hierarchy has only a second-order relationship to address exhaustion, and I don't want to confuse readers. The real issue with address exhaustion is that because of the use of bit masks, allocation blocks have to be in sizes that are powers of two, and this leads to "breakage", where the back portion of the block is unused. I have focussed the article on this.

CIDR was introduced to solve three separate problems:

• the rapid consumption of class-B addresses (/16's)
• the eventual exhaustion of the entire address space
• the growth in routing tables

Hierarchy attacks the third, by making sure that X.a, X.b ... X.n are all colocated, so that in distant parts of the network, they can be covered with a single routing table entry for X. Note that you can have "efficient" allocation (i.e. in power-2 blocks) without having hierachy (i.e. routing table size control); you can allocate successive /24's to places which are far apart, so you will never be able to condense their routing table entries.

The particular mechanism we picked (CIDR) does allow hierarchy, as well as allocation of blocks in any size (not just /8, /16 and /24), but it's easy to get mixed up between the two (which this article used to).

The connection between hierarchy and address allocation is second-order because hierarchy means it doesn't make sense to allocate a growing institution a series of small, unconnected blocks as it grows, and this is not maximally efficient in terms of address space consumption. E.g. it's slightly more efficient in space terms to give a growing entity, over time, 3 unrelated /24's than a single /22, but we wouldn't do that because it would produce more routing table entries.

This is a simple gloss on an issue that is very complex, hope it is useful. Noel 12:59, 13 Sep 2004 (UTC)

POV on this article

It may be correct to say that IPv4+NAT is an untenable long-term solution, but it is not undisputed. If I went through the article and {{fact}}-tagged every sentence that needed a cite and referred to a disputed point, the article would be more blue than grey.

How should this article accommodate the perspective that IPv4 will function for the foreseeable future, with permanent addresses become scarcer but simultaneously less vital to the day-to-day use model of the Internet?

--- tqbf 22:07, 13 November 2007 (UTC)

This is exactly the question I have, reading this article as a non-expert curious about the need for such a cumbersome and costly IPv6. How much longer do we really have, assuming people use NAT sensibly. As a rough (probably naive) estimate, we get an extra 16 bits of addressing using NAT. Even if the number of addresses doubles every 10 years, that's many decades of future growth. The article needs to address this question in a way that non-experts can understand.

I started using NAT several years ago, and haven't run into any "connectivity" problems discussed in this article. From my POV, it is actually better that every one of my devices not have a permanent address on the Internet. I also have an occasional need to work with raw IP addresses, and a 32-bit address is certainly easier to read and write than 128.

Dave (talk) 17:21, 2 June 2012 (UTC)

The article is a bit long, so to get a comprehensive view one need to read the whole article. I would also suggest reading on NAT traversal as it give some insight on the problems with nat. One reason ipv4 + nat is a bad idea is performance. The more scares ipv4 become, the more fragmented the ip space becomes. A fragmented address space results in slower response times and more expensive equipments for ISP's. With layered NAT, nat traversal becomes more tricky and most current "tricks" wont work. This mean that most software that want to do Peer to peer communication need to go through a middle proxy, meaning more costs in bandwidth, performance, and so on. You can see this with Skype to take one example. Last, consumers are today not expected to handle raw IP addressing. DHCP and remote administrations is the current standard for this. If one do need to work with raw IP addressing, one is assumed to be able to handle 128 addresses. Given that IPv6 has some tricks of eliminating zeros in addresses, ipv6 addresses are sometimes smaller to type (less characters) than a ipv4 address. Belorn (talk) 10:46, 3 June 2012 (UTC)

"(...) depletion has been anticipated since the late 1980s, when the Internet started to experience dramatic growth." Hardly. There was no "dramatic" growth of the Internet in the 1980s. This happened in the late 1990s. Gentleman wiki (talk) 13:21, 19 July 2018 (UTC)

Please see Global Internet usage where it shows that the number of hosts started to increase geometrically in the mid-80s. Raw numbers can be seen at http://users.cs.cf.ac.uk/Dave.Marshall/Internet/node18.html and other locations. Walter Görlitz (talk) 21:47, 19 July 2018 (UTC)

Yes, I am aware of that but using growth in percent when the initial number of hosts is very small is simply misleading. Going from 500 to 2000 hosts may be a 300% increase but one cannot call this "dramatic". Take the analogy of one earning a meager $3.00 per hour and receiving a salary increase to $5.00 per hour -- it may be impressive in % but it's still a very low salary by most standards. — Preceding unsigned comment added by Gentleman wiki (talk • contribs) 14:41, 20 July 2018 (UTC)

Your argument was that "there was no 'dramatic' growth of the Internet in the 1980s" and then you state that "yes, I am aware of that" growth in the 80s yet you continue to argue it didn't happen using incorrect statistics. In your example, the salary would go from $3/hr to $9/hr. The Internet started growing at a rate of 200–300% starting in 1985. The highest growth rate was 1988 through the early 2000s, at least when measured by ISPs. Walter Görlitz (talk) 15:09, 20 July 2018 (UTC)

There seems to be agreement here that there was a large percentage growth starting in the 1980s. The numbers were small then so there was no immediate threat of exhaustion. But if you extrapolated those numbers out exponentially, a reasonable thing to do, one could anticipate exhaustion within decades. ~Kvng (talk) 13:25, 23 July 2018 (UTC)

Removed from IP address

I have removed the following from IP address § IP versions as this level of detail was not necessary there. I beleive this material is already covered in this article but some of the detail and refs may be useful for improving this article. ~Kvng (talk) 19:25, 5 March 2018 (UTC)

IANA's primary IPv4 address pool was exhausted on 3 February 2011, when the last five blocks were allocated to the five RIRs. APNIC was the first RIR to exhaust its regional pool on 15 April 2011, except for a small amount of address space reserved for the transition to IPv6, intended to be allocated in a restricted process. Individual ISPs still had unassigned pools of IP addresses, and could recycle addresses no longer needed by their subscribers.

References

Data network example

Walter Görlitz made this change. I reverted because "data network" is a broad term (it redirects to Computer network). An example is presented here. I think it is best to be specific in examples. I don't see this change as an improvement. Walter Görlitz has reverted my revert so presumably feels strongly about it. Let's try to resolve this. ~Kvng (talk) 15:50, 25 August 2018 (UTC)

If the link offends you, remove it. I don't see using a term that no longer has relevance as being beneficial to readers either. Walter Görlitz (talk) 15:56, 25 August 2018 (UTC)

@Walter Görlitz: What link do you suspect offends me? Data network? How is cellular or 4G not relevant in the context of an example? These are specific non-obsolete network technologies. ~Kvng (talk) 02:16, 27 August 2018 (UTC)

This article is on my watchlist, no need to ping me.

I see your point. We should link to Computer network#Cellular standards. It's much more clear than what the anon changed it to. Walter Görlitz (talk) 02:21, 27 August 2018 (UTC)

It is not exactly clear what you're proposing but I've taken a crack at it anyway. I created a Cellular data network redirect to Computer network#Cellular standards and used it in the disputed sentence. I also changed "wireless LAN" to "WiFi" to eliminate ambiguity - cellular data network is also arguably a wireless LAN. ~Kvng (talk) 14:37, 29 August 2018 (UTC)

That works for me. Walter Görlitz (talk) 15:00, 29 August 2018 (UTC)