This is the
talk page for discussing improvements to the
IPv4 address exhaustion article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1,
2Auto-archiving period: 365 days
![]() |
![]() | A news item involving IPv4 address exhaustion was featured on Wikipedia's Main Page in the In the news section on 2 February 2011. | ![]() |
![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
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:
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)
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)
"(...) depletion has been anticipated since the late 1980s, when the Internet started to experience dramatic growth." Hardly. There was no "dramatic" growth of the Internet in the 1980s. This happened in the late 1990s. Gentleman wiki ( talk) 13:21, 19 July 2018 (UTC)
I have removed the following from IP address § IP versions as this level of detail was not necessary there. I beleive this material is already covered in this article but some of the detail and refs may be useful for improving this article. ~ Kvng ( talk) 19:25, 5 March 2018 (UTC)
IANA's primary IPv4 address pool was exhausted on 3 February 2011, when the last five blocks were allocated to the five RIRs. [1] [2] APNIC was the first RIR to exhaust its regional pool on 15 April 2011, except for a small amount of address space reserved for the transition to IPv6, intended to be allocated in a restricted process. [3] Individual ISPs still had unassigned pools of IP addresses, and could recycle addresses no longer needed by their subscribers.
References
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
Walter Görlitz made this change. I reverted because "data network" is a broad term (it redirects to Computer network). An example is presented here. I think it is best to be specific in examples. I don't see this change as an improvement. Walter Görlitz has reverted my revert so presumably feels strongly about it. Let's try to resolve this. ~ Kvng ( talk) 15:50, 25 August 2018 (UTC)
This is the
talk page for discussing improvements to the
IPv4 address exhaustion article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1,
2Auto-archiving period: 365 days
![]() |
![]() | A news item involving IPv4 address exhaustion was featured on Wikipedia's Main Page in the In the news section on 2 February 2011. | ![]() |
![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||
|
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:
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)
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)
"(...) depletion has been anticipated since the late 1980s, when the Internet started to experience dramatic growth." Hardly. There was no "dramatic" growth of the Internet in the 1980s. This happened in the late 1990s. Gentleman wiki ( talk) 13:21, 19 July 2018 (UTC)
I have removed the following from IP address § IP versions as this level of detail was not necessary there. I beleive this material is already covered in this article but some of the detail and refs may be useful for improving this article. ~ Kvng ( talk) 19:25, 5 March 2018 (UTC)
IANA's primary IPv4 address pool was exhausted on 3 February 2011, when the last five blocks were allocated to the five RIRs. [1] [2] APNIC was the first RIR to exhaust its regional pool on 15 April 2011, except for a small amount of address space reserved for the transition to IPv6, intended to be allocated in a restricted process. [3] Individual ISPs still had unassigned pools of IP addresses, and could recycle addresses no longer needed by their subscribers.
References
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
{{
cite web}}
: Unknown parameter |deadurl=
ignored (|url-status=
suggested) (
help)
Walter Görlitz made this change. I reverted because "data network" is a broad term (it redirects to Computer network). An example is presented here. I think it is best to be specific in examples. I don't see this change as an improvement. Walter Görlitz has reverted my revert so presumably feels strongly about it. Let's try to resolve this. ~ Kvng ( talk) 15:50, 25 August 2018 (UTC)