Talk:IPv4 address exhaustion/Archive 1

Archive 1

Archive 2

van Bejnum article

Please note the sentence:

There is of course no reason to assume that future IP address use will conform to patterns seen in earlier years, but we really have nothing else to base our projections upon.

By all means, use this as a source; it's a cool article. But cite it accurately.

This article also does not address the {{fact}} tag on "reclaiming addresses involves more effort than converting to IPv6". Merely stating that reclaiming addresses is hard is not the same as comparing it explicitly and with evidence to the IPv6 flag day.

--- tqbf 20:43, 14 November 2007 (UTC)

• I wasn't trying to say it addresses the fact tag (in fact, I find that tagged statement a bit ridiculous myself and am all for removing it), it more so addresses the previous dubious tag about software that would need to be modified/upgraded. In the interest of keeping this pov cleanup, etc as organized as possible, I'll take the discussion of that point to its own topic. AWeenieMan 22:40, 14 November 2007 (UTC)

other software that would need to be modified or upgraded

I've put together a list of potential sources for this statement. It might still be better to be more specific than saying "many operating systems, routers and other software," however.

• Issues in MS Windows: [1]
• These articles also touch on the restriction in MS Windows, but not enough in and of themselves [2] [3]
• Issues in OpenSolaris: [4]
• Lack of Class E support in Cisco routers: [5]
• Lack of Class E support in Intel switch: [6]
• This draft also support the claim of poor support (with no further explanation that I can find). [7]
• Note also that this Tony Hain article ("At a minimum, some quick tests show that Windows 95 through Windows 2003 Server systems consider that block to be a configuration error and refuse to accept it.") and the van Beijnum article ("However, many TCP/IP stacks, such as the one in Windows, do not accept addresses from class E space and will not even communicate with correspondents holding those addresses. It is probably too late now to change this behavior on the installed base before the address space would be needed.") both make similar claims about TCP/IP stacks not supporting Class E addresses.

Thoughts? Or perhaps you could expand upon your argument that there is support. AWeenieMan 22:40, 14 November 2007 (UTC)

Conceded: if any release of Windows since Windows 98 considers "class E" space to be a configuration error, the statement in the article is valid. It'd be great to get that fact in there. --- tqbf 23:47, 14 November 2007 (UTC)

I changed the class E paragraph significantly. Adding in the info about Windows, adding citations, etc. I could find no proposal that suggested reclaiming the class E space for use on the public Internet, only the one that suggested using it for private networks. Thus, I reworded the paragraph to reflect that proposal. If anyone can find an alternate proposal (in any legitimate capacity), we could include both. AWeenieMan 01:46, 15 November 2007 (UTC)

Anon edits to "exhaustion date"

What's with the random IP address editors shifting the month of the Cisco predicted exhaustion date? Is this vandalism? I can't tell.

--- tqbf 21:40, 16 December 2007 (UTC)

As per the information on the footnote on the wikipedia page and also as per the information on the page that this information is linked to, this information is updated daily via automated scripts. Also, this is Geoff Huston's estimates, not Cisco's. I suspose whoever is updating this info should also be updating the footnote "retrieved" date. Since this is all verifiable information from reliable sources, I can easily tell that this is not vandalism. Wrs1864 (talk) 14:04, 17 December 2007 (UTC)

Right on. I have no objection. Can you edit the text to make it clear that's what's happening? It confused me, and I'm, uh, pretty familiar with the subject matter. --- tqbf 14:37, 17 December 2007 (UTC)

IPv6 deployment status

I have added a splitsection tag, please make any discussions on the subject in Talk:IPv6#Split article to keep things from getting scattered. Wrs1864 (talk) 15:38, 21 May 2008 (UTC)

Markets in IP addresses

Could someone tell me how RFC2088 (IMAP4 non-synchronizing literals) relates to a secondary market for IP addresses? The current text seems to imply that it outlines the drawbacks of a secondary market. AWeenieMan 01:54, 15 November 2007 (UTC)

IP addresses are numbers, so there is no intrinsic value of an IP address. Trading in goods with no intrinsic value (e.g. paper money) instead of goods with extrinsic value (e.g. gold coins) can be risky and requires a stable market.

While this is true, a number of precedents have been set. In order to create a "legitimate" USB or Ethernet device, you must buy an address block (Ethernet) or Vendor ID (USB). These are quite expensive (for "just a number"). —Preceding unsigned comment added by 67.165.222.130 (talk) 22:38, 27 September 2008 (UTC)

Avoiding NAT doesn't generally require public addresses

In other cases, this is due to the need for services that don't interact well with NAT, requiring globally unique addresses for hosts which may not otherwise need global reachability.

If this is meant to refer to services listening for connections, this conclusion is premature. There's nothing about RFC1918 addresses that requires NAT to be done until one leaves the boundaries of your internal organizational routing, at which point you're in global routing territory and globally routable addresses are appropriate. As stated, I believe the sentence will create confusion more than it will convey understanding.

There is a much more specific and common case though. An organization might use public addresses for equipment that is only used internally, such as when it has multiple sites without (virtual or physical) private connectivity between them. In these cases, port mapping via NAT could be used to avoid consuming additional addresses, unless the service doesn't interact well with NAT. Without adding dedicated connectivity, routing the traffic over the global network is required to perform the task, but the addition of network tunnels can be used to allow privately addressed hosts to be reached via the internet by encapsulating the private traffic inside packets routed between already assigned public IPs, such as a firewall's public IP. 207.22.18.69 (talk) 19:22, 16 October 2009 (UTC) amyl

Terms defined - CGN and LSN - confirmation

CGN = "carrier-grade NAT" ? LSN = "large-scale NAT" ?

Are these guesses of mine correct? CecilWard (talk) 23:47, 9 July 2010 (UTC)

Judging from Carrier Grade NAT I would say yes. However, the acronyms are not helpful in this article and I removed them while rewording the section. Johnuniq (talk) 04:00, 10 July 2010 (UTC)

early discussions

Discussions in 1988 can be found at [8] (and archived at [9]) The thread starts with [10], and one of the first responses sums up the problem well. John Vandenberg ^(chat) 01:51, 27 August 2010 (UTC)

Merger

I am tempted to merge this we IP address, which isn't too long and explains the hierarchical system a bit. Is that OK? Pete/Pcb21 (talk) 10:40, 10 May 2004 (UTC)

I think it's a complex enough issue that I'd rather not put the two of them in one article. We've have complaints about Internet-related articles being too thick to wade through, so let's try and keep them simple. Noel 12:59, 13 Sep 2004 (UTC)

• Merge with IPv4 This topic is discussed in the IPv4 article, and much of it is redundant. We should either provide a link to this topic, and remove the topic from that page, Or close this page and merge all this information with that on the IPv4 page. Clifsportland (talk) 03:32, 20 May 2010 (UTC)

• Keep as is Apart from the fact that this section is already quite old, Clifsportland, the IPv4 and IP address articles only briefly discuss the issue, and both already include a link to this article. — DataWraith (talk) 09:21, 20 May 2010 (UTC)

• Keep as is This is a significant enough issue that deserves a seperate article. --Gamerk2 (talk) 13:19, 31 August 2010 (UTC)

Contradiction

A shortage of available IPv4 addresses... a portion of IPv4 addresses reserved for "unspecified future uses"... Am I the only one to see a contradiction here? Surely this could be resolved to kill two birds with one stone, so to speak? 85.76.152.179 20:04, 14 Feb 2005 (UTC)

As explained in the following sentence about these restrictions being hardcoded into devices, we would not be able to get away with redeploying these addresses as additional unicast addresses because a lot of devices out there assume that they can't be used at all. You can't blame those devices, since they could not predict how those addresses work. The "future use" addresses come right after the multicast addresses (which must be handled by devices quite differently than unicast addresses) so is a device to assume unicast or multicast semantics for the experimental addresses. Another kind of address, neither unicast nor multicast, might indeed have been created. --Celada 00:05, September 1, 2005 (UTC)

And indeed was created; see Anycast addresses in IPv6. It is conceivable that this concept was anticipated and prepared for but was later deemed impractical for use in IPv4 due to the address shortage. --77.241.96.242 (talk) 05:26, 5 January 2010 (UTC)

Too many systems do not accept the future use address space for general use. Feel free to use for your internal network, if you need something bigger than 10.0.0.0/8, but expect problems. —Preceding unsigned comment added by 212.123.183.166 (talk) 17:42, 1 September 2010 (UTC)

Markets

Concerning the section on markets. There may indeed be technical issues with implementing a free-market for IPv4 addresses. However, the section's comments on the short comings of a market from an economical stand point are nonsensical and should be removed.

First, value is the measure of how much people want something. To say that IP addresses have no intrinsic value is to say that people don't want them. Clearly this is demonstratably false. We wouldn't be running out of addresses if people didn't want them. Obviously, people DO want them so obviously they DO have value.

Second, we will never run out of addresses if they could be bought and sold on the market. It might be that the price of addresses could rise such that they are no longer affordable for low-value uses but this is a *good* thing. The market would guarantee that the addresses are being used for high-value uses (which means that people are getting high-value from them). —Preceding unsigned comment added by 198.5.223.122 (talk) 00:46, 12 November 2007 (UTC)

• I did some clean-up on the market section. In particular, since you apparently don't understand the definition of "intrinsic value", I added a wiki-link to that article. I love free markets, I wish they were used more. Sadly, a market for IPv4 addresses does not seem very practical. Wrs1864 13:42, 14 November 2007 (UTC)

• I have a concern about the market section: it is nine grafs of position statement on why IPv4 markets are infeasible. These positions may be valid, and they may even be correct, but they are not indisputably and verifiably so.

• I'm inclined to cut this section down substantially and balance it against cited sources arguing on behalf of IP address markets. Happy to discuss here first. --- tqbf 15:34, 14 November 2007 (UTC)

• Well, if you can find good, technical cites for why an IP market would work, I recommend adding them. I haven't seen any. Your flagging of such obviously correct things like problems with routing table growth as dubious, along with saying that Tony Hain's well researched study is dubious lead me to think that you just want to believe that a market could work and are willing to ignore the vast reams of technical discussion that says it can't. Yeah, many of these points should have better citations, but they aren't dubious. Go read nanog, or the iana mailing lists, or the IETF WG mailing lists. This is not a new subject and has lots of discussion from very smart people who would love to be able to create a market, if they could. Many of them have helped create other internet related markets before. Wrs1864 19:16, 14 November 2007 (UTC)

• Yeah, see, what you just did there was synthesize a rather important statement ("IPv4 address markets probably can't work") from "nanog, iana mailing lists, and the IETF WG mailing lists", as well as the prior history of address markets as they appear to you, without citing any specific sources that justify that synthesis. You very specifically cannot do that in Wikipedia articles. Hence my problem with the article. --- tqbf 20:06, 14 November 2007 (UTC)

• Here's an interesting article (albeit 10 years old) by Geoff Huston that partially addresses the intrinsic value of the IP Address and also touches upon the potential market, etc). Might be of some interest. AWeenieMan 20:14, 14 November 2007 (UTC)

One thing I had a strong reaction to was "it's just a number". It's not just a number. It's, among many other things, a reserved place inside of an unfiltered BGP4 announcement. You don't buy the number; you buy the right to have your netblock announced. Not the same thing at all. --- tqbf 20:24, 14 November 2007 (UTC)

• It is, by the way, absolutely not clear to me that the IETF and IANA/ARIN/the RIRs are indisputable authorities on this subject. Additionally, these organizations have a clear POV on the issue.

• Also, mailing list posts are not acceptable sources in Wikipedia.

• Finally, it's reasonable to ask me to make a case for the inline tags I added to the section:

• "extending the address exhaustion date back a year or two." --- presumes we can accurately quantify the impact of "defragmenting" the classful allocations, presumes we have accurately quantified the "time to exhaustion" without doing anything. This tag simply demands a cite for that fact, or an NPOV rewording.

• "other software that would need to be modified or upgraded." --- which software/hardware can't handle "class E" addresses? I'm a dev, feel free to look me up, and I don't believe this. Remember that the overwhelming majority of address pressure comes from Win32. Maybe you can tell me the WRT45G cares what netblock it lives in. Cite a source, reword, or lose the argument.

• "The effort to do this would likely be as great, if not greater, than switching to IPv6." --- Nonsense. [11]. The effort involved in switching to IPv6 is immense. Cite a source!

• "Tony Hain of Cisco Systems predicts the exhaustion date to be" --- The first thing I did to this sentence was to unbold the predicted date, which read as if the article endorsed it. Hain works on IPv6 and liases with the IETF for Cisco. An actual prediction of when address exhaustion will occur deserves its own section; it is as complicated and error-prone a prediction as can be made in this field. Give it a section! Do not attempt to state it as a bare fact.

• I added that Cisco is a network equipment manufactur, to state the possible bias. His original article predicted an exhaustion date around 2009. However, the prediction of Tony Hain now closely tracks with the prediction of Geoff Huston, which used to predict exhaustion in the 2020's, but grew rapidly earlier as time progressed. In May 2007 Geoff Huston modified his method of prediction to a method closer to Tony Haine's method (using a polynomial fit instead of an exponential fit, see Geoff's predictions). Then this brought the exhaustion date about 15 months earlier, to the beginning of 2010. Now, both Tony and Geoff's method give very similar dates in the 3rd quarter of 2010. We should be careful with disputing Tony Hain prediction, as it is one out of only two sources available, also because it is regulary being updated, and his methods seem to be valid and validated by Geoff's prediction.

• This only show that the same methodology applied to the same numbers produces the same resulting numbers. It doesn't address the assumptions built into the original numbers, nor the assumptions built into the methodology. My biggest concern is not that Tony Hain doesn't know how to do math; it's the assumption that IP addresses will continue to be used and allocated in exactly the same way for the foreseeable future. As someone who had to grab an ARIN /19 allocation to get my ISP through the Sprint prefix filters, and spent a month justifying SWIP changes, I can tell you right now that allocation patterns change.

• I am not saying that the Cisco study is right or wrong. I'm saying that no matter what it says, it is not a fact that IP addresses will be exhausted in 2010; it's a prediction. Wikipedia is not a crystal ball. Put the numbers in context and we're fine. --- tqbf 19:32, 16 November 2007 (UTC)

• The problem is not that Tony Hain, or Geoff Huston, for that matter, don't know math, he doesn't know how to do society, which is much harder! Nobody knows whether conservation efforts will balance with the pressure from a last chance rush, so assuming continuity in trends, which might already include some of these effects, can be regarded as reasonable. I have to agree that using 6th order polynomials as in Tony's original prediction is almost never a good idea when extrapolating, because of extraordinary sensitivity to the last datapoints. However, when such predictions are updated regularly, or tested on earlier sets of data, it becomes quickly obvious whether such predictions are erratic opportunistic. Now, just prolonging the current usage rate gives results only a few months different from the here discussed more elaborate predictions.

• We should report it for what it is: a study that suggests when, assuming predictable allocation, reclamation, and usage policies, we will run out of IPv4 addresses. Since this is a bit of a niche article right now, I think it's a great place to go into some depth (maybe 2-3 grafs) on how the study worked. I'm not here to contest the work; I'm here to make sure that there isn't a page in the WP that says "we will run out of addresses in 2010". Nobody knows that. --- tqbf 21:37, 16 November 2007 (UTC)

• The studies do not look at the prediction of allocation, reclamation and usage policies: They assume nothing changes. Moreover, the article clearly states they are predictions. All RIR's now endorse the statement that we are going to run out in 2010-2011. Appart from vetting for opportunistic allocation requests with more scrutiny, they are not significantly changing their allocation policies to extend the exhaustion date significantly, as they recognize that at the current allocation rate this would be quite fruitless, at most gaining months. They might make some "fairness"-policies though, such as not doling out the last three /8 to a RIR when others are almost out of stock too. (Even this is counter current official policies, since current policy is to always give about a year of supply.)

• While I strongly disagree with your assertion that RIR policies won't change as address scarcity worsens, I agree with the rest of this. But what's your point? I agree, there should be a section in this article on the exhaustion studies. I'm simply saying that the article can't give a predicted exhaustion date as a fact. --- tqbf 18:02, 17 November 2007 (UTC)

• "Ad-hoc trading in addresses would lead to fragmented patterns of allocation that would vastly expand the routing table" --- having implemented BGP4 once already, I agree that fragmentation is bad. Of course, the impact of IPv6 on routing tables could be far worse. Finally, the sentence presumes something about trading schemes (that they will be ad hoc and bound to fragment netblocks) that isn't supported with evidence.

• "IP blocks that are large enough to prevent fragmentation problems would reduce the number of potentially tradeable goods to a few million at most" --- no source cited. Presumptive. See the previous bullet.

• "IP addresses are just numbers" --- of course they are not, just like telephone numbers are not "just numbers."

• "Weasel words" --- "some say", "it is often suggested", "would take quite a bit of effort", "it is likely". Uh huh.

it's not a good thing that ip addresses cost something, IF we can make freely make more of them. Why would you want to make life more expensive? And why break so many applications with NAT. —Preceding unsigned comment added by 212.123.183.166 (talk) 17:46, 1 September 2010 (UTC)

--- tqbf 20:22, 14 November 2007 (UTC)

Contribution

The following was contributed to the Endgame section by 131.211.44.164. It may be useful information though there are no citations. If used, it must be better integrated into the article. --Kvng (talk) 13:23, 16 September 2010 (UTC)

Involuntary IPv6 only devices

Already many application work better under IPv6. Most end users are already not able to use multiple static IPv4 addresses at their current ISP. This hampers the adoption of many applications such as internet telephony.

First IANA will exhaust. About 8 months later APNIC will first exhaust. Enterprises and ISP's which require provider independent address space, LIR's, which are new will not be able to get IPv4 addresses from APNIC. Also LIR's which are accelerating their growth will deplete their own stock quickly. 6 months later, most growing LIR's will run out. Without spending money on transferring spare IPv4 space from other LIR's, they have no choice but to use IPv6 space.

Such systems, which could be clients or servers will be only reachable from an IPv4 system through gateway services. You probably do not have control over these gateway services, but they can have an impact on security, reliability, latency, and bandwidth.

2011-01-19 :: Welcome to IPv6

According to http://www.ipv4depletion.com/?page_id=326, we have just reached the IANA pool depletion date. I had loaded the page a few hours ago, and the count-down indicated a the said date would be on the 21st. I reloaded the page and now the counted says we have already reached the IANA pool depletion date. Welcome to the beginning of the IPv6 era! Not sure how/if to add this in the article. AugustinMa (talk) 11:46, 19 January 2011 (UTC)

There's no need, as the prediction is self-evidently wrong. IANA have still not not allocated the final IPv4 addresses to the RIRs. But they will, any day now (another prediction is around 15 days). Dtaylor1984 (talk) 21:12, 19 January 2011 (UTC)

Other sites contradict it, so don't add it to the article. — Preceding unsigned comment added by Jasper Deng (talk • contribs) 00:44, 20 January 2011 (UTC)

In recent years, APNIC always asked for two additional /8 blocks from IANA once their own pool fell to below two /8 blocks. This is also the assumption of IPv4Depletion.com's prediction. APNIC's pool fell to below two /8 blocks on 17 January 2011 (+- one day). Once they request two /8 blocks from IANA (and IANA grants this request as is expected), the IANA pool will be down to five /8 blocks. At this moment, the final allocation rule comes into action, and each RIR will receive one of these remaining /8 blocks. On top of this, a large number of much smaller blocks (from the "Various" "pool") will be distributed as well. In a nutshell, APNIC is expected to request the two /8 blocks any day now, which will then trigger the allocation of the remainder of IANA's pool. It is then expected that APNIC will have used up its pool (except for the last /8 block) at some point in the second half in 2011. It will not totally run out as the allocation rules will be much stricter for the last /8 block. The consequence will be the same though - ISPs will not be able to request significant amounts of IPv4 addresses anymore. --77.109.64.36 (talk) 09:46, 20 January 2011 (UTC)

Also influential potaroo, and associate gadgets and websites now, or will soon, show effective exhaustion as of January 15. According to some sources, a date has been set for an exhaustion event, with a secret date. According to other sources at IANA, Apnic has not made a request, which would be regularly processed. See [http:/www.ipv4depletion.com], blog and comments. —Preceding unsigned comment added by 81.204.252.128 (talk) 00:05, 22 January 2011 (UTC)

Huston prediction just changed to feb-2. Might be a fluke. Hold your horses. See discussion at comments in blog at www.ipv4depletion.com

Please forget about day by day noise and apply some common sense. This is a encyclopedia article and not a news blog. Kbrose (talk) 07:23, 24 January 2011 (UTC)

Reaction to Kbrose: Why can't we say that IANA, according to the two authorative references, under regular continuing policies, should have exhausted already in mid-Januari? Isn't that an important fact in an article about exhaustion?

Of course, one could still feel, or estimate, that this is still a situation which is similar to past overdue allocations. That could be one reason for not mentioning this. But it really doesn't matter when this allocation takes, as effectively APNIC has already starting eating up it's final allocations, whether it has them or not. My point is that for the time when ipv4 addresses won't be available in the field the formal time of the allocation event to APNIC is less relevant than mid-Januari, where the informal exhaustion took place. So in a sense, it's less focused on the formal exhaustion event, not more (as Kbrose reversals indicate). —Preceding unsigned comment added by 131.211.45.45 (talk) 11:16, 24 January 2011 (UTC)

>Huston prediction just changed to feb-2. Might be a fluke. Hold your >horses. See discussion at comments in blog at www.ipv4depletion.com > >::Please forget about day by day noise and apply some common sense. This >is a encyclopedia article and not a news blog. Kbrose > (talk) 07:23, 24 January 2011 (UTC) reaction: That's exactly what was indicated. "Might be a fluke". "Hold your horses". No need to change anything. What was in the article (informal exhaustion mid-January) probably did not change.

Note also that the Hurricane Electric IPv4 exhaustion counter also exhausts beginning Februari. But this counter seems completely opaque to it's inner working. —Preceding unsigned comment added by 131.211.45.45 (talk) 11:22, 24 January 2011 (UTC)

One source says iana exhaustion jan 31. —Preceding unsigned comment added by 82.169.251.18 (talk) 05:06, 27 January 2011 (UTC)

Since these sources can now be considered dated info, it shouldn't be included in the article at all.Jasper Deng (talk) 06:17, 27 January 2011 (UTC)

Of course it will not make sense to talk about predictions of IANA exhaustion if it has happened already. However, both Geoff Huston and Stephan Lagerholm also make a prediction for the first RIR to deplete their regional pool. This is actually a more important event, so I suggest to keep using these predictions. --77.109.64.36 (talk) 14:10, 27 January 2011 (UTC)

Image

I was actually having a bit of a tough time fathoming some of the content of this article, till I remembered an older xkcd comic whose graphical format was a big help in comprehension: http://www.xkcd.com/195/. I think that this would be an excellent image to use in the article (Randall Munroe releases them under CC-ANC 2.5, but has in the past re-released them under less restrictive licenses for Wikipedia), or send to the Graphic Lab for use as a basis for a more professional-looking (and updated) map. bahamut0013^words_deeds 17:57, 31 January 2011 (UTC)

Do other sources confirm it?Jasper Deng (talk) 20:39, 31 January 2011 (UTC)

the end-to-end routable IPv4 Internet will be officially obsolete

This phrase "once the first RIR has run out, the end-to-end routable IPv4 Internet will be officially obsolete" currently appears in the heading of the article. There is no basis for this statement. There is no official who determines when the IPv4 Internet will be obsolete. The end-to-end principle died long ago with the invention of network address translation, NAT.

The NAT article says specifically that it's a violation of the end-to-end routability rule.Jasper Deng (talk) 01:17, 4 February 2011 (UTC)

Yes, NAT does violate end-to-end routing, but that has nothing to do with IPv4 address exhaustion. One could argue that the end-to-end routable Internet was officially retired when NAT was created and used on the IPv4 internet. —Preceding unsigned comment added by 66.194.72.10 (talk) 01:20, 4 February 2011 (UTC)

It was properly sourced. Rewording is better than simple removal. — Preceding unsigned comment added by Jasper Deng (talk • contribs) 01:13, 4 February 2011 (UTC)

I know of no source for that statement. It is even marked citation needed. —Preceding unsigned comment added by 66.194.72.10 (talk) 01:25, 4 February 2011 (UTC)

I thought it already had a citation. Your edit removed a citation, that's why. Anyhow, official means ICANN in this case. I also suggest you sign your comments.Jasper Deng (talk) 03:38, 4 February 2011 (UTC)

81.204.252.128 (talk) 13:40, 5 February 2011 (UTC) We should point out the repurcussions of the exhaustion somehow. One aspect is that require end-to-end connectivity, and this is not solvable anymore by getting addresses from IANA, even when required. I know, NAT work, but only sometimes. For example, SIP protocols require application layer gateways, which are not be available on many NATTED networks (example, apple, and possibly ISP run ones).

APNIC - Expectations vs Projections

I fail to see the difference between these. Anyone making projections will have to enter their expectations into the formulas. Just look at the amount of tweaking possible at the Lagerholm site. --Cybjit (talk) 18:00, 5 February 2011 (UTC)

Agreed. Go ahead and fix it :). Thue | talk 21:35, 5 February 2011 (UTC)

Done --Cybjit (talk) 11:25, 6 February 2011 (UTC)

Out of date

The vast majority of this article is written as if the IANA exhaustion date is in the future. IANA has allocated all of its addresses to the RIRs already. The tense of many sentences needs to be updated to reflect this fact. --AdamRoach (talk) 19:25, 8 February 2011 (UTC)

Excellent. When will you start to make the change since you understand the problem so well? --Walter Görlitz (talk) 19:40, 8 February 2011 (UTC)

82.169.251.18 (talk) 19:52, 8 February 2011 (UTC) Not sure what he is talking about. Now the article has progressed to talk about RIR exhaustion, and possibly LIR exhaustion. There might be a few left out. Calling the entire article out of date because of a few old phrases is a bit extreme. I doubt we'll see him soon again.

It doesn't seem outdated to me. Unless AdamRoach can point out at least one specific way it is outdated, I am going to remove the tag. Thue | talk 20:49, 8 February 2011 (UTC)

This article is in need of a lot of copy editing. But I think the current tone is OK, the IANA exhaustion is IMHO mostly symbolic. Only shortly after the RIRs get exhausted will this affect real users. --Cybjit (talk) 20:57, 8 February 2011 (UTC)

Didn't have time to make the edits last time. It turns out that about half the time IANA was mentioned, it was in the context of future exhaustion, not past exhaustion. I think I've fixed them all. --AdamRoach (talk) 21:53, 10 February 2011 (UTC)

Point of View

Reading the section "ISP wide NAT" I am a bit concerned with the point of view apparent in the discussion. It seems to be heavily biased towards the ISP and less than neutral in terms of the "net neutrality" debate. I admit this is not my area, but particularly comments such as those regarding inserting banner ads, also seem dubious due to legal reasons. What you guys think?--Luke.mccrohon (talk) 16:08, 28 January 2008 (UTC)

-- I've added a few sentences about the legal problems involved by using the ISP wide NAT, esp. if used to do anything more than that, what is suggested in the first part of the article. This might work in the USA with funding of MPAA/RIAA, but with the tight data protection laws in the EU and Switzerland, this idea calls for trouble. Ovbwiki - 31 January 2008 21:00 UTC —Preceding unsigned comment added by Ovbwiki (talk • contribs) 21:06, 31 January 2008 (UTC)

The more than NAT stuff could probablly be trimmed as irrelevent. The main problem with ISP wide nat is if you want to know who to blame when an abuse/spam report comes in (and you probablly do even if you don't respond to the reports individually) you have to log every connection AND you have to hope that the person sending the abuse report logged the source port as well as the source IP. There is also the obvious issue of it preventing users accepting incoming connections though something like UPNP could help with that for things like P2P apps. Plugwash (talk) 00:30, 6 April 2008 (UTC)

UPNP can't work with ISP NAT because it allocates a very sparse resource (IP ports) to specific internal hosts at the behest of an untrusted request. UPNP only really works if there are just a couple of internal hosts and they can be trusted not to try to break anything even by accident. 90.204.215.252 (talk) 09:49, 3 January 2011 (UTC)

ISP-wide NAT is already implemented in Russia and some other countries of the former USSR. There are no ISPs left in Russia (except for some old dial-up providers) who assign public IP addresses to their users by default. And it does not create any problems to users or whatsoever. Those who want can always get a public address for additional $2-$5 per month.

I don't know where you've got this "information" from, but it's untrue. Right now (as of Feb, 2010) all major ISPs in Moscow and St. Petersburg offer broadband connections with (dynamically assigned) public IPv4 addresses. I myself used Comstar, MGTS and BeeLine (Corbina) recently and all of them assign public IPs.

ISP-wide NAT seems to be the only practical solution to resolve IPv4 address space problem at a minimum cost for end users.

This is biased. NAT isn't only the "minimum cost" but also the minimum convenience solution. End users behind NAT are limited to applications, services and protocols that can use NAT. Furthermore, if they have a home network but receive one non-public IP from their ISP, they're further limited to using double NAT. Finally, there's no guarantee that their ISP will even forward all TCP/UDP ports. Basically, NAT is a second rate service.

In the meantime, the issue of alleged urgency of IPv6 introduction is enthusiastically welcomed by corporations like Microsoft to push users to buy newer versions of their OS and newer hardware. Alexander0807 (talk) 22:20, 31 May 2008 (UTC)

XP support IPV6 just fine (though unfortunately if you want to set a manual address you have to use the command line). Plugwash (talk) 23:01, 28 June 2008 (UTC)

Despite it's problems thanks to the inaction of many parties we have reached the point where some form of ISP level NAT is the only reasonable option. Thinking that all services will be on IPv6 in the next year or so is just wishfull thinking. The only questions left for an ISP who can't get the IPs they need are.

1: which users are least likely to notice losing their public v4 IPs (I would expect most ISPs to start with their bottom tier subscribers)

2: whether to deploy IPV6 to customers in addition to a natted v4 service.

3: what variant of ISP level NAT to use (NAT64, NAT464, NAT444, DS-LITE etc)

-- Plugwash (talk) 15:49, 5 September 2011 (UTC)

markets in IP addresses

The markets in IP addresses section is full of BS and is basically uncited (there is one cite before the bulleted list that seems to be only tangetically related to markets in IP addresses and a few cites in the section about the MS aquistion).

"The creation of a market in IPv4 addresses would only delay the practical exhaustion of the IPv4 address space for a relatively short time, since the public Internet is still growing. This implies that absolute exhaustion of the IPv4 space would follow within at most a couple of years after the exhaustion of addresses for new allocations."

This completely ignores market economics. Right now the demand for IPv4 addresses is high because the things are practically free. As the price of IPv4 addresses goes up address users will re-evaluate what applications REALLY need a public v4 address and what applications could be acheived without one.

"The concept of legal "ownership" of IP addresses as property is explicitly denied by ARIN and RIPE NCC policy documents and by the ARIN Registration Services Agreement. It is not even clear in which country's legal system the lawsuits would be resolved."

IIRC both ripe and ARIN have adopted policies that will allow sale of IPs post exhaustion subject to anti-hoarding restrictions and APNIC allows sales openly.

"Trading in IP blocks that are large enough to prevent fragmentation problems would reduce the number of potentially tradeable units to a few million at most."

Trading would almost certainly be between ISPs and/or large companies (with small companies continuing to get IPs from their ISP just as they do today) so a "few million" tradable blocks isn't as bad as it seems.

"The cost of changing from one set of IP addresses to another is very high, reducing the market liquidity. Organizations that can potentially reorganize their usage of IP addresses to free them up so that they can be sold will demand a high price and, once bought, will not be resold without a large profit."

No doubt blocks won't be cheap but expensive is generally considered preferable to unavailable.

"The cost of renumbering an organization's IP address space each time is comparable to the cost of switching to IPv6 once"

If the organisation has any sense they will move appropriate systems to IPv6 and/or private IPv4 as part of the renumbering. I wouldn't expect any organisation to go through multiple large scale renumberings.

-- Plugwash (talk) 10:05, 9 September 2011 (UTC)

Concern about making this a news story rather than an encyclopedic article

The constant changing, without references, is starting to make this a news story and not an encyclopedic article. It certainly breaks WP:RECENT. Most notably, it's documenting the changing rate of loss and remaining blocks. It doesn't really matter when the blocks will run-out in Asia or elsewhere down to the hour. It is sufficient to know that they will run-out out soon. I would like to see the updates stop, particularly when they're updating a referenced item and the reference isn't changed at all.

Also, simple math is WP:OR. --Walter Görlitz (talk) 18:55, 11 March 2011 (UTC)

I concur with this view. I have been trying to combat this tendency for months, but people can't seem to think or rise beyond the micromanaging of daily factoids, that is not what is expected of an encyclopedia. Kbrose (talk) 19:05, 11 March 2011 (UTC)

We should have discussed this before deleting these sections. After all, this is an article on "IPv4 address exhaustion", and to my mind, the date at which it will happen, and the process how the last addresses are allocated are pretty much the most important aspects. These dates are published by reputable sources, and this article summarised them. So what if they change every day? If some of us change the numbers every few days, that should be fine! Furthermore, simple math may be OR, but Walter Gorlitz failed to link to the right section of the policy, which explicitly allows simple calculations: WP:CALC. And that is exactly what is being done: sum over a few numbers in the source and convert to a /8. I probably agree though that the previous "IPv6" section was too long for this topic and is sufficient now. In my view, we should revert to this revision: http://en.wikipedia.org/w/index.php?title=IPv4_address_exhaustion&oldid=418338713 Specific criticism can then be made based on this. --SmilingBoy (talk) 20:51, 11 March 2011 (UTC)

Nothing stopping a revert from happening. My concern is with the daily change of the numbers as if this were a sort of count-down clock. --Walter Görlitz (talk) 21:02, 11 March 2011 (UTC)

Moreover, the predicted date have been shifted by months, especially for APNIC, and especially in the last weeks. There is still about a factor of two in time until APNIC exhaustion between predictions.

Now the entire sections about exhaustion at specific RIR's are gone! Also is gone how many companies/LIR's will not be able to get IP addresses from RIR's at APNIC. Who cares if the numbers change everyday. Only people who look at the history, i.e. the editors, do. If a company wants to know about this stuff, they should be able to get accurate data to assess their opportunities and liabilities. Now it seems exhaustion has already happened, but it's not quite over, and there are years expected between exhaustion at different RIRs. 81.204.252.128 (talk) 21:55, 11 March 2011 (UTC)

Also the impact on IPv4 exhaustion before complete adoption of IPv6 on the pressure on IPv6 transition mechanisms is completely gone. It has been widely discussed that many untested stop-gaps need to implemented because of this. 81.204.252.128 (talk) 22:00, 11 March 2011 (UTC)

I'm going for reverts. It's ridiculous. I appreciate your contributions KBrose, but this is too much.81.204.252.128 (talk) 22:02, 11 March 2011 (UTC)

I guess it depends whether people want up to date complete information, or a classical encyclopedia ;-).81.204.252.128 (talk) 22:19, 11 March 2011 (UTC)

No it doesn't depend on whether people want up-to-date, complete information or a traditional encyclopedia. That's a false dichotomy and not the issue at all. What the issue is described at WP:RECENT so please read it and stop being flippant.

What needs to stop is the daily, and sometimes hourly, updates of the exhaustion. It is enough to state that IPs will run out soon without updating with the latest number. That's what external links are for. Let them be up-to-date and let us be informative. We also didn't have up-to-the-minute news on any other events so this should not be an exception. --Walter Görlitz (talk) 08:26, 12 March 2011 (UTC)

Stages of exhaustion also was completely ignored. APNIC for instance recognizes at least four stages of exhaustion. (Pre-iana, Post-Iana, Last /8, completely exhausted). 81.204.252.128 (talk) 22:21, 11 March 2011 (UTC)

In some sense, this can be regarded as a current event, with new information coming in all the time. APNIC could exhaust within weeks. —Preceding unsigned comment added by 81.204.252.128 (talk) 22:49, 11 March 2011 (UTC)

Who cares if APNIC exhausted in weeks. When it has you can write a paragraph, when and how APNIC did get exhausted. Until it has, it is sufficient to state that it is expected to happen in 2011, giving a reference to the source, where a reader surely will find more detail that is updated whenever. Kbrose (talk) 01:14, 13 March 2011 (UTC)

I would only indicate that a month wouldn't hurt, but a count-down is not required nor is updating the number of remaining blocks on a regular basis. See WP:RECENT Walter Görlitz (talk) 02:27, 13 March 2011 (UTC)

This day-by-day updating is simply inappropriate, some people simply don't get the purpose of WP. It's not an authoritative source of details, and no-one expects to find such detail in an encyclopedia. Details about transition technologies don't belong here either, they belong into the IPv6 articles, and we have a specific article for transition issues already. Kbrose (talk) 01:10, 13 March 2011 (UTC)

I don't see the problem with the article being up-to-date with regard to the number of IP-adresses left at APNIC. It is not as if every part of the article is updated daily, it is just one (very relevant) number. Your argument seem to be that the article can't actually contain useful updated info, for no apparent reason. And I object to the complete deletion of the section with status and policies of the individual RIRs. The RIR information will be relevant for years, and as such is not recentism. Thue | talk 15:00, 13 March 2011 (UTC)

The problem is not that the article can't be kept up-to-date, edits over the past month argue against that, it's that it shouldn't be kept up-to-date. --Walter Görlitz (talk) 16:04, 13 March 2011 (UTC)

It shouldn't be kept up to date because encyclopedia are not expected to be? Welcome to the new world!81.204.252.128 (talk) 22:18, 13 March 2011 (UTC)

That's not what was written. It doesn't need to be kept up-to-date because that's not the role of Wikipedia. Somewhere in the world, this information should be kept up-to-date, but the details on the exact moment when one region of the world will run-out of IPv4 address is WP:FANCRUFT and not of importance to the average reader of this subject on WIkipedia.

As for the new world, welcome to a place where someone without an account can edit material that is available for everyone else to read. --Walter Görlitz (talk) 23:12, 13 March 2011 (UTC)

I think an article like this should be able to mention a predicted date. But in previous comments Gorlitz is more focused on the frequency of changes, but this does not affect readers at all, only editors. I previously tried to not focus on dates resulting from stock and allocation rate, which changes much less every day, so will induce less day to day editing, but this was rejected as WP:CALC, before it got wiped out all together. —Preceding unsigned comment added by 81.204.252.128 (talk) 03:42, 14 March 2011 (UTC)

As stated before, it should mention a predicted date. It should not be updated regularly. It should also not continually update the remaining blocks. --Walter Görlitz (talk) 06:28, 14 March 2011 (UTC)

This type of edits is what I have been making reference to. --Walter Görlitz (talk) 12:07, 19 March 2011 (UTC)

As we get closer to exhaustion, we can be obviously get more specific as the predictions get more accurate. "Around" is vague anyway, but possibly does not convey the level of uncertainty sufficiently, with a rush going. ipv4depletion is currently re-evaluating his predictions as they seem out of line. Haine is not providing sufficient information, but has been quite steady (first end-april, now mid-april). —Preceding unsigned comment added by 81.204.252.128 (talk) 18:41, 22 March 2011 (UTC)

What's wrong with vagarity? Nothing. Since the "experts" don't know, why should we pretend to be certain. --Walter Görlitz (talk) 18:49, 22 March 2011 (UTC)

I know this a few months old, but you've hit upon a bet peeve of mine. WP:RECENT says absolutely nothing about constantly updating facts. This happens quite often when people just cite the policy. Redirects to policy are not substitutes for actually making an argument. At the very least, you should point out what portion of the policy is being violated and why it applies.

Similarly, WP:OR says nothing about "simple math" being forbidden. In fact, it goes out of its way to define synthesis as only being problematic if the conclusions are controversial, and to state that routine calculations are allowed. In this case, the editor alleged the policy said the exact opposite of what it actually says.

And, no, none of this has changed in the interim. Those using the policy or essay links added authority that was unwarranted to their arguments. Hence my request that all said links be explained. — trlkly 20:04, 27 September 2011 (UTC)

Sorry to have offended you, but WP:RECENT is 1) not a policy but an opinion. 2) speaks to the idea that you shouldn't be constantly updating things so you're basically wrong on two fronts. And while WP:OR may not speak directly to simple math being prohibited, it's how it's done that the issue. So rather than fall back on the letter of the law, look at the spirit behind it. --Walter Görlitz (talk) 20:10, 27 September 2011 (UTC)

Data on ARIN's /8 availability since IANA exhaustion?

This entry includes a nice graph from Geoff Huston showing /8 availability from each of the RIRs, with predictions of their exhaustion. Geoff's own page mentions that the fit for ARIN is wrong because it doesn't account for change in policy activated by IANA exhaustion, which is clearly visible in the graph. Anybody know where I can get the data on the number of /8s ARIN had available per day since IANA exhaustion, so I can attempt a more accurate fit? —Darxus (talk) 22:42, 1 March 2012 (UTC)

I think Hurricane Electric's website (he.net) has some data, but you'll have to plot it yourself, I believe.Jasper Deng (talk) 23:09, 1 March 2012 (UTC)

Perhaps just ask Geoff Huston, since he seems to have a source? Thue | talk 12:35, 2 March 2012 (UTC)

He probably uses the pages linked at http://bgp.potaroo.net/stats/nro/ and http://www.potaroo.net/tools/ipv4/index.html . Thue | talk 12:46, 2 March 2012 (UTC)

The data for Arin are the delegated Arin data. You can get it from Arin ( ftp://ftp.arin.net/pub/stats/arin/ ). You will need lots of sets and lots of assumptions to build a hypothetical model. The registries are not required to keep sets of old data but you can find enough if not all. The best description of the current Arin inventory, assumptions about its future , and policy, could not be made by anyone else other that Arin ( https://www.arin.net/resources/request/ipv4_depletion.html ). Following just that you could determine some depletion rate. Building Hypothetical Models is not a pure science and if you want to do something like that for one registry you still need to look at all of them. Arin and the other registries give the delegated data in the same format ( http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format ) with no copyrights. Some good views of these data ( updated weekly ) are on http://IPduh.com ( http://ipduh.com/macro/ip/exhaustion/ , http://ipduh.com/macro/ip/world/ , http://ipduh.com/macro/ip/countries/ ). Tenretnieht (talk)

how many ip4 address are left in real time data

It would be great to have a real time data of total ip4 address left for assigning.Can anyone do this? —Preceding unsigned comment added by 122.162.103.166 (talk) 11:03, 12 July 2008 (UTC)

With NAT and subnetting it's unlikely to be sure. - Team4Technologies (talk) 20:32, 21 December 2008 (UTC)

here is the site http://inetcore.com/project/ipv4ec/index_en.html

plz add the flash code if possible —Preceding unsigned comment added by 122.163.194.62 (talk) 17:16, 21 January 2009 (UTC)

This is updated weekly http://ipduh.com/macro/ip/exhaustion/ . It shows address counts and /8 counts. It's on the external links as well. I think that adding some piece of JavaScript or flash is a really bad idea. I would not mind a static graphic that it is updated often and it is hot linked to a server that does that and its author gave explicit permission for it. I will look into creating something like that if it does not exist already and more people agree that it would be a useful addition. Tenretnieht (talk) —Preceding undated comment added 13:01, 26 March 2012 (UTC).

Remainining IPv4

http://ipduh.com/macro/ip/exhaustion/ -- Which other EL shows the current Remaining IPv4 and links to all inventories? How it is not related to the article? Tenretnieht (talk) 20:14, 27 March 2012 (UTC)

In reverse order: WP:EL states "Some acceptable links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy.

" Some external links are welcome, but it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic."

This count-down clock is not "further research". There isn't a link to the count-down clock for the upcoming summer Olympics. Even if there were, that is an official site while this is speculation.

Now as for which other link, the one immediately above it: http://www.potaroo.net/tools/ipv4/ potaroo.net: IPv4 Address Report with countdown where the first section has information on "Remaining Addresses in RIR Pool". --Walter Görlitz (talk) 20:23, 27 March 2012 (UTC)

Count down clock? I think we are not talking about the same link.

The link above ( http://www.potaroo.net/tools/ipv4/ ) shows the RIR inventories in /8 and some projections - hypotheses about their exhaustion date and then explains the model used.

The link I am talking about ( http://ipduh.com/macro/ip/exhaustion/ ) shows the remaining IPv4 addresses and in total.

These are the actual current numbers not projections nor guesses.

Shows the actual remaining IPv4 addresses ( not only just the /8s which messes up precision therefore the data there can be used easier in calculations)

It shows world totals for delegated , assigned , allocated , remaining and links to the registry inventories.

Obviously contains information that the one above do not. And the one above contains information that this does not.

This link is very relevant. Actually I think that this link along with the one above it could replace all this article just fine.

I would just copy the contents of these two links to this article but they are not static so it would be useless. Tenretnieht (talk)

Bad faith edit in restoring this material.

Still does not meet WP:EL. Period. Please remove now.

Good that you didn't copy the contents since that's a copyright violation. It would also turn Wikipedia into a count-down clock itself. Please familiarize yourself with Wikipedia policy and guidelines. --Walter Görlitz (talk) 20:52, 27 March 2012 (UTC)

>Bad faith edit in restoring this material. < I thought that you got confused since you were talking about some count down clock.

>Still does not meet WP:EL. Period. Please remove now. < I just read WP:EL just now and I don't see anything against adding http://ipduh.com/macro/ip/exhaustion/ to this article.

>Good that you didn't copy the contents since that's a copyright violation. It would also turn Wikipedia into a count-down clock itself. < null.

>Please familiarize yourself with Wikipedia policy and guidelines. < I am not an expert on this department but I have read many of these guidelines. Please tell me exactly what this link violates. Be specific. I do not see anything against my last edit except maybe from the 'bad faith edit' thing, but then again I did add it back after I read your response about some count down clock. I thought that you confused this with another link.

Please take a look at the link I want to add ( http://ipduh.com/macro/ip/exhaustion/ )( and then ( http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format if you are not familiar with the terms used ), then compare the link with http://www.potaroo.net/tools/ipv4/ . Also a look at ( http://ipduh.com/macro/ip/world/ ) may help you understand. The link I want to add is the most relevant link to this article and takes the least amount of effort to be understood. Tenretnieht (talk)

Tenretnieht (talk) —Preceding undated comment added 21:23, 27 March 2012 (UTC).

Since you're not an expert on the subject of external links, I'll just take it to experts to discuss. Thanks. --Walter Görlitz (talk) 22:10, 27 March 2012 (UTC)

>Since you're not an expert on the subject of external links < Did it take you more than a read of WP:EL to become an expert on it or you think that you are smarter than me?

If it did take you more than a read to become and expert on WP:EL I don't even want to imagine what it would take you to be become a mathematician, a computer scientist ,and an IP and DNS expert. If you think that you are smarter than me then you most probably aren't and you are just an arrogant.

>I'll just take it to experts to discuss. Thanks. < No problem, maybe https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Computing/Task_forces/Networking too. Tenretnieht (talk) 22:43, 27 March 2012 (UTC)

I'm sorry. I didn't mean to offend you. You're not discussing the same issue as I am. I am saying that the link doesn't provide any encyclopedic information and so it is excluded by WP:EL. I'm certainly no expert, but I have seen a few more additions like this excluded for the reasons I've provided. I've taken it to people who are experts to discuss since I'm keenly aware that I could be wrong about this. --Walter Görlitz (talk) 22:57, 27 March 2012 (UTC)

Sorry. I totally missed your suggestion of who should discuss it. No I took it to Wikipedia:External links/Noticeboard as they understand ELs. It appears someone else thinks that the link isn't appropriate, but for a different reason. --Walter Görlitz (talk) 23:08, 27 March 2012 (UTC)

>I'm sorry.I didn't mean to offend you.< No problem , only the absence of logic offends me.

>You're not discussing the same issue as I am. < I thought I did address all your concerns and I did explain my view.

>I am saying that the link doesn't provide any encyclopedic information and so it is excluded by WP:EL. < I did read WP:EL two times. + I think that this link is the single most relevant external link to this article. It alone describes the issue in a nutshell.

>I've taken it to people who are experts to discuss since I'm keenly aware that I could be wrong about this. < OK, it sounds cool.

>Sorry. I totally missed your suggestion of who should discuss it. No I took it to Wikipedia:External links/Noticeboard as they understand ELs. It appears someone else thinks that the link isn't appropriate, but for a different reason. < OK, NO problem. I think that it should also be discussed at https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Computing/Task_forces/Networking too. But I will take it there next time I login. Tenretnieht (talk) 23:18, 27 March 2012 (UTC)

Not sure that Wikipedia:WikiProject Computing/Computer networking task force is the correct place to discuss external link issues. That appears to be the root of the problem: you think this is a networking issue when it's really an external links issue. External links must conform to the EL policy. Whether the material is reliable or otherwise worthwhile is immaterial. --Walter Görlitz (talk) 23:42, 27 March 2012 (UTC)

I do not see anything against it on WP:EL. Please Be specific. I already asked about it on Wikipedia:WikiProject Computing/Computer networking task force Tenretnieht (talk) 00:45, 28 March 2012 (UTC)

Pretty much, because of NOTHOWTO, it's not an addition to the article's content.Jasper Deng (talk) 23:55, 27 March 2012 (UTC)

>Pretty much, because of NOTHOWTO, it's not an addition to the article's content. < http://ipduh.com/macro/ip/exhaustion/ is not a How TO Tenretnieht (talk) 00:45, 28 March 2012 (UTC)

I added the reason, quite specifically, when I moved the discussion from my talk page. Since you missed it, I'll add it again:

"Some acceptable links include those that contain further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy.

"Some external links are welcome, but it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic."

There's no further research offered at the site. It's a tool that may or may not be reliable. Research in this instance would be a detailed explanation of what IPv4 address exhaustion is or how it will affect me or my Internet-connected devices. It's not quite a how-to, but it does not inform the reader of the subject, only on one minor aspect related to the subject.

There's already a link that does something similar immediately above, although it has not been updated, but we're not creating a comprehensive list related to the topic.

Finally, it doesn't appear to be from a recognizable expert on the topic. --Walter Görlitz (talk) 00:24, 28 March 2012 (UTC)

>Some acceptable links include those that contain further research that is accurate and on-topic, < True for http://ipduh.com/macro/ip/exhaustion/

>information that could not be added to the article for reasons such as copyright < It does not apply

>or amount of detail, < ?

>or other meaningful relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy.< None of these apply to http://ipduh.com/macro/ip/exhaustion/

>There's no further research offered at the site. < No True for http://ipduh.com/macro/ip/exhaustion/ in relation to IPv4 address exhaustion

>It's a tool that may or may not be reliable. < It is not a tool. It is reliable as reliable is addition. If not Please prove it.

>Research in this instance would be a detailed explanation of what IPv4 address exhaustion is or how it will affect me or my Internet-connected devices. < Exactly http://ipduh.com/macr/ip/exhaustion/ is IPv4 Exhaustion in a nutshell

>It's not quite a how-to< quite TRUE. It is not a how-to

> but it does not inform the reader of the subject < NOT TRUE http://ipduh.com/macro/ip/exhaustion/ is IPv4 Exhaustion in a nutshell.

>Finally, it doesn't appear to be from a recognizable expert on the topic. < Not recognizable to you that you are not qualified to judge. You said it yourself above. Tenretnieht (talk) 00:54, 28 March 2012 (UTC)

(Note: stop quoting others' comments, we know perfectly well what you're replying to and it just confuses others) Let me take down your argument piece by piece:

1. No - nothing more than what's in the article
2. No - we have other reasons
3. Data is useless without analysis of it
4. No - there's no reason why we should link one of hundreds of calculators
5. No - we already have data sites and graphs, this is not an extension of the article
6. No - it's not official. We need to know their data collection method; if you yourself did it it's sort of original research
7. No - a simple graph/data chart is not called "detailed".
8. No - the average joe makes no sense of that adata
9. No - we know experts when we see them, and we see no credentials on that website. I'm no expert but an editor who knows how to judge the reliability of a source.

In short, your link just doesn't belong.Jasper Deng (talk) 00:55, 28 March 2012 (UTC)

Where is the current delegation totals for IPv4 in the article . All this article is hypotheses about the sums that are described on http://ipduh.com/macro/ip/exhaustion/ currently.

What reasons? Be spesific

There are not the raw data. There is analysis -- Simple addition but lots of it

What calculator are you talking about. I think that you are confused with out CIDR Calculator Argument. This is a report

Show me these data somewhere

Yeah the RIR delegation data is not official and simple addition is original research. I should write my thesis on it --I would be done in 4 afternoons. Be serious.

This is not even an argument

THis is not an argument either

OK you are not an expert on IP, CS, and basic Math. You don't even understand these subjects. However you claim that you know who is an expert and that you can prove that something related to those subjects is wright or wrong.

It is really sad what is happening here. I cannot understand your motivations. I just see ignorance ,lack of logic, and denial. Tenretnieht (talk) 01:17, 28 March 2012 (UTC)

I took this debate to Wikipedia:WikiProject Computing/Computer networking task force and Walter Görlitz took it to Wikipedia:External links/Noticeboard. Tenretnieht (talk) 01:20, 28 March 2012 (UTC)

I'm not going to point out the data to you when all you need to do is look at the provided graphs. Your data is pretty raw, and while I'm no expert, I'm not disqualified and any editor like me will see that your argument is the one lacking logic and refusing to get the point.Jasper Deng (talk) 01:21, 28 March 2012 (UTC)

Sorry to say this Tenretnieht, but you're absolutely deluded about what WP:EL states in relation to this. Your site is not appropriate. I have tried to explain it to you but instead of trying to understand you just argue, and you do it incorrectly. I'm going to wait to see if EL noticeboard has anything to say about the link and otherwise ignore your ramblings. --Walter Görlitz (talk) 01:50, 28 March 2012 (UTC)

Just the fact that 3 of you are opposed adding this link vs just only one ( me ) is enough. Let 's take it off.

For the record, I still think that http://ipduh.com/macro/ip/exhaustion/ and http://www.potaroo.net/tools/ipv4/ are the most important pieces information on this article.

What do you think about the ratio discussion on the above section? Foo (talk) 13:40, 2 April 2012 (UTC)

Allocated IPv4 addresses per delegated IPv4 addresses per cent and Remaining IPv4 Addresses per Total IPv4 addresses per cent

Adding the following two statements: " Based on the RIR delegated data of 2012-03-25, the Allocated IPv4 addresses are the 72.23% of the total Assigned and Allocated addresses (ref http://ipduh.com/macro/ip/exhaustion/ or http://ipduh.com/macro/ip/world/ ). Theoretically, approximately 3 out of 4 delegated IPv4 addresses are not assigned to an Internet host." Tenretnieht (talk)

Continued from https://en.wikipedia.org/wiki/User_talk:Jasper_Deng#IPv4_address_exhaustion.23Reclamation_of_unused_IPv4_space Tenretnieht (talk)

First, explain how you are going to follow our definition of "allocated" and "assigned". Start a new section on the article talk page.Jasper Deng (talk) 02:01, 26 March 2012 (UTC)

I do not define allocated nor assigned. I do not redefine them either. Allocated and Assigned are not really defined in the article. Allocated is defined implicitly but i believe my statements follow that. Allocated and Assigned are terms used by IANA and the RIRs to describe delegations. We should give their definitions in the article and explain why a delegation described as assigned or as allocated may not really be as defined. I just state the ratio Allocated / (Allocated + Assigned) % and a simplification of it on the second statement. The second statement is what the data says but there is a good chance that it is not accurate. I think that this simple arithmetic does a huge difference on understanding the issue. I admit that "assigned to an Internet host" is debatable hence, I start the second statement with "Theoretically" Tenretnieht (talk)

Your statements don't follow that definition. You don't make a definition, but under the definition used by IANA/RIRs, your statement makes no sense, especially the way you wanted them to be used in the article.Jasper Deng (talk) 02:41, 26 March 2012 (UTC)

>You don't follow that definition < What definition? none of the terms is defined explicitly , >but under the definition used by IANA/RIRs it makes no sense < Could you please prove that? , >it makes no sense < This is not an argument , >especially the way you wanted them to be used in the article. < I just said that we should give their definitions as defined by IETF.

If I change the second statement to: "Approximately 3 out of 4 delegated IPv4 addresses are not assigned." Then both statements are 100% true for 2012-03-25.

Before answering Please take a look at http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format

Tenretnieht (talk)

The definition, if you look at List of assigned /8 IPv4 address blocks, is clearly that allocation means allotment of addresses, and assignment is just another form of allocation on the next level down. The link you supplied has no definition of it. Unfortunately, yep, Wikipedia discussions more often than not are arguments. The IETF's definition is the one I'm using here.Jasper Deng (talk) 03:16, 26 March 2012 (UTC)

It took me a while to see it too because the status allocated and assigned is defined in another way too. I am not talking for sub allocation here. Please take a look at http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format The status assigned - allocated is defined a bit differently on the delegated data " status Type of allocation from the set:

   {allocated, assigned}

This is the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies. " Tenretnieht (talk) —Preceding undated comment added 03:25, 26 March 2012 (UTC).

No, assignment implicitly means a sub-allocation; your link, once again, backs up my argument, not yours. It's not to the registry, but it's from registry, that I'm talking about sub-allocations.Jasper Deng (talk) 03:29, 26 March 2012 (UTC)

I quote 'Type of allocation from the set:{allocated, assigned} This is the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies.' Tenretnieht (talk) 03:40, 26 March 2012 (UTC)

Did you even read my comment? That is no definition of allocation/assign. What I mean is that the file-making registry's assignment is an allocation to another agency. It is not that agency's sub-allocation, but the file-making registry's.Jasper Deng (talk) 03:42, 26 March 2012 (UTC)

Yes I did read it i do not argue the direction ( it's pretty obvious ). Yeah Both allocations and assignments are towards third parties. I think you are trying to say that assigned means that is given to someone who can gave it to others ( this is the difference ). Tenretnieht (talk) —Preceding undated comment added 03:48, 26 March 2012 (UTC).

No, that's not what I was trying to say. I'm trying to say, that in the context of the reference you cited in edits to this page, an allocation is the RIR's pool of addresses, and its assignments are allocations to third parties. In this particular context, dealing with LIR WHOIS entries, the two are virtually synonymous.Jasper Deng (talk) 03:51, 26 March 2012 (UTC)

Well both allocations and assignments are towards third parties as well. Look at the data. It is clearly seen in this view of the data as well ( http://ipduh.com/macro/ip/countries/ ) Tenretnieht (talk)

In the second statement I meant allocated as ---An allocated address belongs to a pool from which it may be assigned but it hasn't yet been marked as in use. Pools are managed by various organizations like ISPs, Webhosting services, and Universities. ( just found that using google -- I am looking for a valid reliable source that says it that clearly but not luck so far ) Tenretnieht (talk)

Exactly my point.

What about giving the official definitions of delegated , allocated , assigned. Give the allocated and assignment definitions of http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format and then change the second statement to 'approximately 3 out of 4 delegated IPv4 addresses are not assigned'

This would be a sequence of relative definitions and useful facts. Tenretnieht (talk) —Preceding undated comment added 04:13, 26 March 2012 (UTC).

This would belong on the IP address allocation page. However, I cannot use your "3 out of 4" statistic because you are not talking about what you think you are.Jasper Deng (talk) 04:22, 26 March 2012 (UTC)

>"3 out of 4" statistic because you are not talking about what you think you are < I did not understand this argument. What do you mean? Tenretnieht (talk)

OK skip the definitions (one way) and take off the '3 out of 4 ...' statement --This was a point I wanted to make but the people who cannot figure it out could get the a wrong idea. Would you agree with giving the rir-statistics-exchange-format status definitions and then the first statement - the ratio? There is no talk on this article about the data. However all talk is based upon hypothetical models building upon these data. Tenretnieht (talk) —Preceding undated comment added 04:45, 26 March 2012 (UTC).

First you'll have to correct your vocabulary. I would say "Out of x number of addresses allocated to RIRs, y (z%) have been assigned by them to other organizations".Jasper Deng (talk) 04:53, 26 March 2012 (UTC)

Now you are contradicting your previous self Tenretnieht (talk)

This is not how assigned is defined in the rir-statistics-exchange-format :This is the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies. Tenretnieht (talk) 12:22, 26 March 2012 (UTC)

I am saying "giving the rir-statistics-exchange-format status definitions and then the first statement - the ratio " NO interpretations ,NO thoughts ,NO conclusions , NO disputes of what it should and what it should not mean, NO feelings" -- Just the raw facts -- Tenretnieht (talk)

Something like that: The status allocated xor assigned is defined as the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies. ( ref: http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format). Based on the RIR delegated data of 2012-03-25, the allocated IPv4 addresses are the 72.23% of the delegated (total Assigned and Allocated) addresses (ref http://ipduh.com/macro/ip/exhaustion/ or http://ipduh.com/macro/ip/world/ ).[ Take off( Approximately 3 out of 4 IPv4 addresses are not assigned) ]Tenretnieht (talk)

The above statements are 100% true and 100% relative. Tenretnieht Tenretnieht (talk)

Allocated / delegated % is not equivalent to Allocated versus delegated percent. I don't even know what 'Allocated versus delegated percent' means. The title of this section is 'allocated / delegated %' . Please do not change. ( / ~ over ) 'Allocated IPv4 Addresses Per Delegated IPv4 Addresses Per Cent' is OK too.Tenretnieht (talk)

"Delegated" is not relevant here; the section header should not have the / or % symbol. I'm not contradicting myself, and I'm not arguing with you any more over this when it's blatently obvious that your statements make absolutely no sense whatsoever.Jasper Deng (talk) 17:06, 26 March 2012 (UTC)

Delegated = Allocated + Assigned Tenretnieht (talk)

I made the title 'Allocated IPv4 addresses per delegated IPv4 addresses percent' . OK I am not going to use math symbols and write them in English. I replaced / with per and % with percent. This is a very simple ratio. Do you understand this ratio? Can you see how is related to this article? Please do not change the title even if you do not understand it. Every time this title was changed it was changed to something that it does not make sense or something that does not mean what I mean undermining my request which is simple. I want this simple ratio to be included in this article.Tenretnieht (talk)

>blatently obvious? < Could you please show me one error in the following statement?

On the RIR delegation statistics the status allocated xor assigned is defined as the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies. ( ref: http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format). Based on all the RIR delegated data of 2012-03-25, the allocated IPv4 addresses are the 72.23% of the delegated (total Assigned and Allocated) addresses and the remaining (available for allocation and assignment) IPv4 addresses are the 6.72% of the total IPv4 addresses. (ref http://ipduh.com/macro/ip/exhaustion/ or http://ipduh.com/macro/ip/world/ ). Tenretnieht (talk)

I am interested in finding these ratios for other dates as well , let's say around 1994 , around 2000 , around 2005 . I am trying to find such sources. Actually the IANA + RIR pool on this | graph looks promising for the second ratio. I just don't see yet, how he calculates the IANA + RIR ( just RIR now days) pool from the data he is using. Foo (talk) 13:54, 2 April 2012 (UTC)

Warehoused IPv4 Addresses

Seems probable that large portions of the IPv4 address space are warehoused in anticipation of selling them as a scarce resource. For example Prudential Insurance, a financial company, owns the class A block 48.0.0.0/8 (16 million addresses) but appears to make no use of it. No BGP advertisements of this space exist. The addresses could be used exclusively for an internal network, but why bother when the 10.0.0.0/8 block would serve just as well?

http://whois.arin.net/rest/nets;q=48.0.0.0?showDetails=true

http://www.cidr-report.org/cgi-bin/as-report?as=AS6253 — Preceding unsigned comment added by Binnacle (talk • contribs) 05:31, 4 March 2011 (UTC)

This seems to be pure speculation and thus does not belong here.Jasper Deng (talk) 00:43, 12 March 2011 (UTC)

"but why bother when the 10.0.0.0/8 block would serve just as well?"

Something a lot of people forget is that there are major downsides to using private addesses for large networks even if you don't plan to directly interconnect with the internet. Over time companies merge, launch collaborative projects etc which may require interconnection of networks that were built by different administrative structures. If the two networks use overlapping IP addresses then either one or both of them will have to be renumbered (which can be a massive amount of work) or horrible NAT hacks must be used. Plugwash (talk) 11:31, 18 December 2012 (UTC)

Virtualization

Does it really only save hardware resources? I'm thinking that virtualization is not only a consolidation, but an expansion tool.Jasper Deng (talk) 03:49, 25 March 2012 (UTC)

There is no documented statistics that it has contributed to depletion. Virtualization is a direct result of new efficiencies, easing the growth of the Internet, like all hardware or software improvements. If you cite this than you have to cite all technologies that have made it easier to put more info on the Internet. This is not a driver, it is a relatively recent development that just coincides with the depletion end game. It is inconceivable to think that the Internet would have grown slower without virtualization in the last few years. Kbrose (talk) 04:07, 25 March 2012 (UTC)

There are certainly virtualisation scenarios that increase IP consumption.

For example you run a load of different services (say web, irc, email and xmpp) on one machine without virtualisation then you would have to go out of your way to give them different IP addresses. If you run those same services in individual VMs then you would have to go out of your way to share an IP between them (you could though DNAT).

Another case is the movement of infrastructure from inside companies own machine rooms where it can private IPs to cloud hosting services which use public IPs.

How important this is overall I have no idea. My gut feeling is it's less significant than client connections and SSL web hosting. Plugwash (talk) 16:10, 18 December 2012 (UTC)

We are running out of nothing...

However, large blocks of IPv4 addresses are reserved for special uses and are unavailable for public allocation.

Well, this is quite a joke, telling us that we are running out of something that isn't used at all. However, the adresses are also bought and withhold by autorithies that want soon a IPv6 stamp on all our faces. Beyound that, let's not forget that in fact IPv4 has about 65000 * 2^32 adresses, since ports also belong to an IP adress (in fact it could be even an unlimited amount more, since there are no limitations on port numbers, just think about a NAT server with 2^64 of ports!). However this would protect our privacy (since we could easily hide behind ports), and that never was a goal neither of (D)ARPA or IANA, right? --178.197.228.77 (talk) 02:52, 14 January 2014 (UTC)

Actually, we are running out of IPV4 space. The field for port number is 16 bits (65535 possible values), and popular web pages can use many ports for just one page. For example, Google Maps uses a few hundred connections, each of which uses a port. At the time that APNIC IPV4 space was exhausted, APNIC was burning through about 20 /8s per year. At this rate, it will require about 60 /8s just to bring APNIC back to no deficit. Since some major device and OS manufacturers have declared the Class E space to be configuration errors, recovering any space from class E would require everyone using one or more of those to get a new version after the new version was developed and released. There were 85 Class A blocks that were ever assigned. Assuming that you could all of these back (and you would likely have to go to court in many cases - which would take years), You would still only have 15 left after satisfying APNIC right now. Then you get to take into account that RIPE (Europe) has also run out, and would need about 9 /8s just to make up the backlog. LACNIC only has a month or two left, and is burning through IPV4 addresses at a rate of 2 to 3 /8s per year, and ARIN has less than a year left and is burning through /8s at a similar rate, and you should come to the conclusion that we will have to do something different than status quo in the near term.§ — Preceding unsigned comment added by John McLeod VII (talk • contribs) 17:17, 9 June 2014 (UTC)

References

NAT as an IPv4 exhaustion solution

Removed assertion of opinion to the effect that NAT is a general purpose IPv4 exhaustion solution - it could be reinserted if made with appropriate citations for claim — Preceding unsigned comment added by TcomptonMA (talk • contribs) 14:23, 16 June 2014 (UTC)

"Deployment of IPv6 is the only standards-based solution to the IPv4 address shortage." is strong and incorrect. Since another solution (NAT) was previously in the article which solves the IPv4 address shortage issue (and of course NAT has its own drawbacks). I had qualified it to "Deployment of IPv6 is the only standards-based solution to the IPv4 address shortage that allows running routable servers on each network endpoint." which is still strong and more accurate. You have reverted it and referenced above. I am now changing to "Deployment of IPv6 is a standards-based solution to the IPv4 address shortage" which now makes the sentence correct by making it less strong. Full Decent (talk) 23:55, 22 June 2014 (UTC)

Feel free to be WP:BOLD and change it then. ISPs have large blocks of IPv4 addresses and assign two to businesses who only need one. Walter Görlitz (talk) 00:15, 23 June 2014 (UTC)

Good outcome - perhaps it would be even more precise to say "Deployment of IPv6 is the IETF-recommended standards-based solution to the IPv4 address shortage." (per RFC 1752) --TcomptonMA 14:53, 23 June 2014 (UTC) — Preceding unsigned comment added by TcomptonMA (talk • contribs)

Use of XKCD comic as illustration

This article should use the XKCD comic "Nanobots" as an illustration, as it demonstrates the problem of IP exhaustion. — Preceding unsigned comment added by 72.213.254.184 (talk) 18:10, 31 October 2016 (UTC)

Can't. It's copyrighted. Walter Görlitz (talk) 04:11, 1 November 2016 (UTC)

Actually, XKCD is licensed under Creative Commons CC-BY-NC 2.5, which is unsuitable for Wikipedia because noncommercial licenses are prohibited. Too bad, it was really close. Elizium23 (talk) 04:17, 1 November 2016 (UTC)

I stand corrected. I did not know that the copyrights were not compatible. Walter Görlitz (talk) 04:24, 1 November 2016 (UTC)

You could always just ask the XKCD creator for permission to release it under a Wikipedia-compatible license. Thue (talk) 13:08, 1 November 2016 (UTC)

The comic is funny but I don't think it particularly explainatory. ~Kvng (talk) 12:11, 4 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on IPv4 address exhaustion. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110706085135/http://www.apricot-apan.asia/__data/assets/pdf_file/0012/31314/2011-02-23-dualstack-geoff.pdf to http://www.apricot-apan.asia/__data/assets/pdf_file/0012/31314/2011-02-23-dualstack-geoff.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Y The help request has been answered. To reactivate, replace "helped" with your help request.

Cheers.—InternetArchiveBot (Report bug) 07:07, 31 December 2016 (UTC)