RFC 1597 INFORMATIONAL IP ADDRESSING · ENTERPRISE NETWORKS

Private Addresses: Address Allocation for Private Internets

Using non-unique IP addresses inside enterprises to conserve address space

On rfc-editor.org ↗
PUBLISHED
March 1994
AUTHORS
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot
STREAM
Legacy
OBSOLETED BY
RFC 1918 — Private Address Space
24-BIT BLOCK
10.0.0.0 to 10.255.255.255 (16 million addresses)
20-BIT BLOCK
172.16.0.0 to 172.31.255.255 (1 million addresses)
16-BIT BLOCK
192.168.0.0 to 192.168.255.255 (65,536 addresses)
KEY CONSTRAINT
Routing info about private networks must not be forwarded to the Internet
DOI
10.17487/RFC1597

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                        Y. Rekhter
Request for Comments: 1597       T.J. Watson Research Center, IBM Corp.
Category: Informational                                    B. Moskowitz
                                                         Chrysler Corp.
                                                          D. Karrenberg
                                                               RIPE NCC
                                                            G. de Groot
                                                               RIPE NCC
                                                             March 1994


                Address Allocation for Private Internets

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1. Introduction

   This RFC describes methods to preserve IP address space by not
   allocating globally unique IP addresses to hosts private to an
   enterprise while still permitting full network layer connectivity
   between all hosts inside an enterprise as well as between all public
   hosts of different enterprises. The authors hope, that using these
   methods, significant savings can be made on allocating IP address
   space.

   For the purposes of this memo, an enterprise is an entity
   autonomously operating a network using TCP/IP and in particular
   determining the addressing plan and address assignments within that
   network.

2. Motivation

   With the proliferation of TCP/IP technology worldwide, including
   outside the Internet itself, an increasing number of non-connected
   enterprises use this technology and its addressing capabilities for
   sole intra-enterprise communications, without any intention to ever
   directly connect to other enterprises or the Internet itself.

   The current practice is to assign globally unique addresses to all
   hosts that use TCP/IP.  There is a growing concern that the finite IP
   address space might become exhausted.  Therefore, the guidelines for
   assigning IP address space have been tightened in recent years [1].
   These rules are often more conservative than enterprises would like,
   in order to implement and operate their networks.

   Hosts within enterprises that use IP can be partitioned into three
   categories:

      - hosts that do not require access to hosts in other enterprises
        or the Internet at large;

      - hosts that need access to a limited set of outside services
        (e.g., E-mail, FTP, netnews, remote login) which can be handled
        by application layer gateways;

      - hosts that need network layer access outside the enterprise
        (provided via IP connectivity);

      - hosts within the first category may use IP addresses that are
        unambiguous within an enterprise, but may be ambiguous between
        enterprises.

   For many hosts in the second category an unrestricted external access
   (provided via IP connectivity) may be unnecessary and even
   undesirable for privacy/security reasons.  Just like hosts within the
   first category, such hosts may use IP addresses that are unambiguous
   within an enterprise, but may be ambiguous between enterprises.

   Only hosts in the last category require IP addresses that are
   globally unambiguous.

   Many applications require connectivity only within one enterprise and
   do not even need external connectivity for the majority of internal
   hosts.  In larger enterprises it is often easy to identify a
   substantial number of hosts using TCP/IP that do not need network
   layer connectivity outside the enterprise.

   Some examples, where external connectivity might not be required,
   are:

      - A large airport which has its arrival/departure displays
        individually addressable via TCP/IP. It is very unlikely that
        these displays need to be directly accessible from other
         networks.

      - Large organisations like banks and retail chains are switching
        to TCP/IP for their internal communication.  Large numbers of
        local workstations like cash registers, money machines, and
        equipment at clerical positions rarely need to have such
        connectivity.

      - For security reasons, many enterprises use application layer
        gateways (e.g., firewalls) to connect their internal network to
        the Internet.  The internal network usually does not have direct
        access to the Internet, thus only one or more firewall hosts are
        visible from the Internet.  In this case, the internal network
        can use non-unique IP numbers.

      - If two enterprises communicate over their own private link,
        usually only a very limited set of hosts is mutually reachable
        from the other enterprise over this link. Only those hosts need
        globally unique IP numbers.

      - Interfaces of routers on an internal network usually do not
        need to be directly accessible from outside the enterprise.

3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private networks:

        10.0.0.0        -   10.255.255.255
        172.16.0.0      -   172.31.255.255
        192.168.0.0     -   192.168.255.255

   We will refer to the first block as "24-bit block", the second as
   "20-bit block, and to the third as "16-bit" block.  Note that the
   first block is nothing but a single class A network number, while the
   second block is a set of 16 contiguous class B network numbers, and
   third block is a set of 255 contiguous class C network numbers.

   An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry.  The address space can thus be
   used by many enterprises.  Addresses within this private address
   space will only be unique within the enterprise.

   As before, any enterprise that needs globally unique address space is
   required to obtain such addresses from an Internet registry.  An
   enterprise that requests IP addresses for its external connectivity
   will never be assigned addresses from the blocks defined above.

   In order to use private address space, an enterprise needs to
   determine which hosts do not need to have network layer connectivity
   outside the enterprise in the foreseeable future.  Such hosts will be
   called private hosts, and will use the private address space defined
   above.  Private hosts can communicate with all other hosts inside the
   enterprise, both public and private.  However, they cannot have IP
   connectivity to any external host.  While not having external network
   layer connectivity private hosts can still have access to external
   services via application layer relays.

   All other hosts will be called public and will use globally unique
   address space assigned by an Internet Registry.  Public hosts can
   communicate with other hosts inside the enterprise both public and
   private and can have IP connectivity to external public hosts.
   Public hosts do not have connectivity to private hosts of other
   enterprises.

   Moving a host from private to public or vice versa involves a change
   of IP address.

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links.  Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks.  If such a router
   receives such information the rejection shall not be treated as a
   routing protocol error.

   Indirect references to such addresses should be contained within the
   enterprise.  Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses.  In particular, Internet service providers should take
   measures to prevent such leakage.

4. Advantages and Disadvantages of Using Private Address Space

   The obvious advantage of using private address space for the Internet
   at large is to conserve the globally unique address space by not
   using it where global uniqueness is not required.

   Enterprises themselves also enjoy a number of benefits from their
   usage of private address space: They gain a lot of flexibility in
   network design by having more address space at their disposal than
   they could obtain from the globally unique pool.  This enables
   operationally and administratively convenient addressing schemes as
   well as easier growth paths.

   For a variety of reasons the Internet has already encountered
   situations where an enterprise that has not between connected to the
   Internet had used IP address space for its hosts without getting this
   space assigned from the IANA.  In some cases this address space had
   been already assigned to other enterprises.  When such an enterprise
   later connects to the Internet, it could potentially create very
   serious problems, as IP routing cannot provide correct operations in
   presence of ambiguous addressing.  Using private address space
   provides a safe choice for such enterprises, avoiding clashes once
   outside connectivity is needed.

   One could argue that the potential need for renumbering represents a
   significant drawback of using the addresses out of the block
   allocated for private internets.  However, we need to observe that
   the need is only "potential", since many hosts may never move into
   the third category, and an enterprise may never decide to
   interconnect (at IP level) with another enterprise.

   But even if renumbering has to happen, we have to observe that with
   Classless Inter-Domain Routing (CIDR) an enterprise that is connected
   to the Internet may be encouraged to renumber its public hosts, as it
   changes its Network Service Providers.  Thus renumbering is likely to
   happen more often in the future, regardless of whether an enterprise
   does or does not use the addresses out of the block allocated for
   private networks.  Tools to facilitate renumbering (e.g., DHCP) would
   certainly make it less of a concern.

   Also observe that the clear division of public and private hosts and
   the resulting need to renumber makes uncontrolled outside
   connectivity more difficult, so to some extend the need to renumber
   could be viewed as an advantage.

5. Operational Considerations

   A recommended strategy is to design the private part of the network
   first and use private address space for all internal links.  Then
   plan public subnets at the locations needed and design the external
   connectivity.

   This design is not fixed permanently.  If a number of hosts require
   to change status later this can be accomplished by renumbering only
   the hosts involved and installing another physical subnet if
   required.

   If a suitable subnetting scheme can be designed and is supported by
   the equipment concerned, it is advisable to use the 24-bit block of
   private address space and make an addressing plan with a good growth
   path.  If subnetting is a problem, the 16-bit class C block, which
   consists of 255 contiguous class C network numbers, can be used.

   Using multiple IP (sub)nets on the same physical medium has many
   pitfalls. We recommend to avoid it unless the operational problems
   are well understood and it is proven that all equipment supports this
   properly.

   Moving a single host between private and public status will involve a
   change of address and in most cases physical connectivity.  In
   locations where such changes can be foreseen (machine rooms etc.)  it
   may be advisable to configure separate physical media for public and
   private subnets to facilitate such changes.

   Changing the status of all hosts on a whole (sub)network can be done
   easily and without disruption for the enterprise network as a whole.
   Consequently it is advisable to group hosts whose connectivity needs
   might undergo similar changes in the future on their own subnets.

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage.  An enterprise should also filter any
   private networks from inbound routing information in order to protect
   itself from ambiguous routing situations which can occur if routes to
   the private address space point outside the enterprise.

   Groups of organisations which foresee a big need for mutual
   communication can consider forming an enterprise by designing a
   common addressing plan supported by the necessary organisational
   arrangements like a registry.

   If two sites of the same enterprise need to be connected using an
   external service provider, they can consider using an IP tunnel to
   prevent packet leaks form the private network.

   A possible approach to avoid leaking of DNS RRs is to run two
   nameservers, one external server authoritative for all globally
   unique IP addresses of the enterprise and one internal nameserver
   authoritative for all IP addresses of the enterprise, both public and
   private.  In order to ensure consistency both these servers should be
   configured from the same data of which the external nameserver only
   receives a filtered version.

   The resolvers on all internal hosts, both public and private, query
   only the internal nameserver.  The external server resolves queries
   from resolvers outside the enterprise and is linked into the global
   DNS.  The internal server forwards all queries for information
   outside the enterprise to the external nameserver, so all internal
   hosts can access the global DNS.  This ensures that information about
   private hosts does not reach resolvers and nameservers outside the
   enterprise.

6. References

   [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC
       1466, Merit Network, Inc., May 1993.

7. Security Considerations

   While using private address space can improve security, it is not a
   substitute for dedicated security measures.

8. Conclusion

   With the described scheme many large enterprises will need only a
   relatively small block of addresses from the globally unique IP
   address space.  The Internet at large benefits through conservation
   of globally unique address space which will effectively lengthen the
   lifetime of the IP address space. The enterprises benefit from the
   increased flexibility provided by a relatively large private address
   space.

9. Acknowledgments

   We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS),
   Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran
   (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord
   (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza
   Turchanyi (RIPE NCC) for their review and constructive comments.

10. Authors' Addresses

   Yakov Rekhter
   T.J. Watson Research Center, IBM Corp.
   P.O. Box 218
   Yorktown Heights, NY, 10598

   Phone: +1 914 945 3896
   Fax: +1 914 945 2141
   EMail: yakov@watson.ibm.com


   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015

   Phone: +1 810 758 8212
   Fax: +1 810 758 8173
   EMail: 3858921@mcimail.com


   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands

   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: Daniel.Karrenberg@ripe.net


   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands

   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: GeertJan.deGroot@ripe.net

AI ELI5

On this page
PROBLEMThe finite supply of globally unique IPv4 addresses would be exhausted quickly if every computer in every enterprise needed a unique address, even those that never connect to the Internet.
MECHANISMThis document reserves three ranges of IP addresses for private use within enterprises: 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 192.168.0.0-192.168.255.255. These addresses are not routable on the public Internet.
WHY IT MATTEREDIt was replaced by RFC 1918, which codifies the same practice, but enabled enterprises to save vast amounts of global address space.

§1The Address Shortage Problem

The Internet originally allocated IP addresses assuming every computer would eventually need a globally unique address to connect to the public Internet. But many devices inside companies never need external connectivity: they are internal workstations, cash registers, parking lot displays, or equipment behind firewalls.

The RFC identifies three types of hosts: those that never need external connectivity, those that need limited external access (through application-layer gateways like email or FTP), and those that need full Internet connectivity. Only the third category truly requires globally unique addresses. By allowing the first two categories to use non-unique, locally meaningful addresses, enterprises could dramatically reduce their consumption of the global address pool.

Not every computer inside a bank needs to be reachable from the Internet. Many computers just talk to other computers inside the bank. If they all used fake addresses that only work internally, we'd save real addresses for computers that need them.

§2The Private Address Blocks

IANA reserved three blocks of IP addresses for private use: the 24-bit block (10.0.0.0 to 10.255.255.255), which is a single Class A network with 16 million addresses; the 20-bit block (172.16.0.0 to 172.31.255.255), which is 16 contiguous Class B networks with about 1 million addresses; and the 16-bit block (192.168.0.0 to 192.168.255.255), which is 256 contiguous Class C networks with about 65,000 addresses.

These addresses are non-unique globally: many enterprises can use the same private addresses simultaneously. An enterprise using private addresses does not need IANA approval. However, enterprises still need globally unique addresses for any hosts that require external connectivity. The key constraint is that routers on the Internet boundary should filter out routing information about private networks, preventing private addresses from leaking into the global routing system.

Three ranges of addresses are reserved for private use. 10.0.0.0 is huge, 172.16.0.0 is medium, and 192.168.0.0 is smaller. Any company can use any of these without asking permission.

§3Deploying Private Addresses

Enterprises should design their network by first mapping out all internal connectivity needs and using private addresses everywhere internally, then adding public addresses at the edge where external connectivity is needed. This preserves the largest contiguous blocks of private space for future growth.

When a host must change from private to public status (or vice versa), its address must change, which requires renumbering. The RFC recommends designing subnets so that hosts likely to undergo such changes in the future are grouped together, minimizing disruption. Routers at the enterprise boundary should be configured with filters to prevent private addresses and routing information about private networks from escaping. Many enterprises use Network Address Translation (NAT) to translate between private internal addresses and a few public external addresses, though NAT is not explicitly discussed in the RFC.

Design the inside of the company first using private addresses. At the edge, translate to real addresses. If a computer needs to become external later, it needs a new address.

§4Benefits and Tradeoffs

The primary benefit is conservation of globally unique address space, which directly extends the lifetime of the IPv4 address pool. Enterprises also gain flexibility: they have much more address space to work with, allowing for cleaner address plans and easier network growth. The RFC notes that for enterprises that have used addresses before connecting to the Internet, private addresses provide a safe way to avoid collisions with addresses already assigned to other organizations.

The main drawback is that moving a host between private and public status requires renumbering, which is inconvenient. However, the RFC argues this is not as severe as it may seem: many hosts may never move, and tools like DHCP (mentioned as an emerging technology) can automate renumbering. Moreover, the RFC notes that even hosts with globally unique addresses may need renumbering as enterprises change Internet service providers, so the renumbering concern is not unique to private addressing.

The benefit is saving millions of addresses. The downside is if a computer needs to become public later, it must change addresses. But many computers never need to change.

§5Operational Best Practices

The RFC recommends several operational practices. Routers connecting enterprises to external networks should use packet and routing filters at both ends to prevent leakage of private addresses. Enterprises should filter inbound routing information about private networks to avoid being confused by ambiguous routing. Two-nameserver DNS configurations are recommended: one external server for public addresses (linked into global DNS) and one internal server for all addresses (both public and private), preventing information about private hosts from leaking beyond the enterprise.

For enterprises using external connectivity, the RFC suggests using IP tunnels between sites to prevent private addresses from leaking when connections cross external networks. The clear separation of public and private addresses, while requiring renumbering when status changes, also makes uncontrolled external connectivity more difficult, providing a security benefit.

Set up walls around your private network so private addresses don't escape to the Internet. Run two separate DNS servers so outsiders only see public addresses.

§6References