Talk:IPv4 address exhaustion

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the IPv4 address exhaustion article.
Article policies
This is a controversial topic that may be under dispute. Please read this page and discuss substantial changes here before making them.
Make sure to supply full citations when adding information and consider tagging or removing uncited/unciteable information.

Contents

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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. [1]. 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.

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

[edit] 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)

[edit] 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)

[edit] 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: [2]
  • These articles also touch on the restriction in MS Windows, but not enough in and of themselves [3] [4]
  • Issues in OpenSolaris: [5]
  • Lack of Class E support in Cisco routers: [6]
  • Lack of Class E support in Intel switch: [7]
  • This draft also support the claim of poor support (with no further explanation that I can find). [8]
  • 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)

[edit] 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)

[edit] 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)


[edit] 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)

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.

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

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)

[edit] 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)