View source for Problems of address exhaustion and collision with Internet Protocol

{{subpages}}
{{TOC|right}}
''This is some very preliminary material that is apt to change titles and split into other articles before the ideas stabilize, as it deals with very dynamic real-world problems. Be careful in linking to it, because the article is apt to reorganize. Feel free to discuss on the talk page.

Unfortunately, the sandbox doesn't work for some of these discussions, which will involve a lot of stubby definitions, use of R-templates, changing redirects and disambiguation, etc. I wish I knew a better way, but I believe some of this information, even if changing, is of definite utility even in rough form.''

There are a set of '''Problems of address exhaustion and collision with Internet Protocol'''. The problems are not restricted to IPv4 and not IPv6; the problems are not restricted to the IPv4 private address space<ref name=RFC1918>{{citation
 | id = RFC1918 
 | title = Address Allocation for Private Internets
 | author =Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear
 | date = February 1996
 | url = http://www.ietf.org/rfc/rfc1918.txt}} alone. 

Some real-world examples may serve to show the general nature of the problems. It was intended to have a private address space so enterprises could number their IP hosts, which never connected to the public Internet, without having to go out for unique address space. This involved both administrative workload and draining a very limited resource, globally routable IP address space. 

Some organizations, such as the U.S. military, that had been involved early in the assignment of IP addresses, had large blocks of unique addresses that never were visible on the Internet. This made it enormously easier to avoid renumbering when, for example, a particular electronic warfare function moved from the Navy to the entire Department of Defense.  In the general business sector, this option did not exist for enterprises that had used the RFC 1918 space for what they believed to be internal use only, but had a merger or acquisition with another enterprise that used the same private address space, or divested an organization that created a "hole" in either private or assigned public address space.

In the [[Internet Protocol version 6]] work, there is a block called "site local" (SLA), whose purpose is roughly equivalent to the RFC 1918 block. With experience, SLA use is being deprecated, and organizations are encouraged to get unique addresses from the immensely larger pool of IPv6 addresses. With unique addresses, the problem of collisions in mergers tend not to happen.

A related problem is that some very large organizations, such as cable television/internet access providers, have literally run out of space in the IPv4 private address space, a problem that was inconceivable not so many years ago.

Until the world widely transitions to IPv6 and unique address space, however, a variety of tools are needed to solve some of these issues, at least for the interim.  There are a variety of such tools; the challenge is fitting the right tool to the specific problem to be solved. ''For now, see a mailing list response that discussed, very informally, some of the issues and possibilities''.
==Tools==
===Address space not routable on the public Internet, IPv4 and IPv6===
===Network Address Translation===
===Tunneling===
===VPNs with Route Distinguishers===
===Internal backbones of backbones===
===Deliberately isolated routing domains===

==Refererences==