Network Working Group                                         Y. Rekhter
Request for Comments: 1918                                 Cisco Systems
Obsoletes: 1627, 1597                                       B. Moskowitz
BCP: 5                                                    Chrysler Corp.
Category: Best Current Practice                            D. Karrenberg
                                                               RIPE NCC
                                                         G. J. de Groot
                                                               RIPE NCC
                                                                E. Lear
                                                 Silicon Graphics, Inc.
                                                          February 1996


               Address Allocation for Private Internets

Status of this Memo

  This document specifies an Internet Best Current Practices for the
  Internet Community, and requests discussion and suggestions for
  improvements.  Distribution of this memo is unlimited.

1. Introduction

  For the purposes of this document, 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.

  This document describes address allocation for private internets. The
  allocation permits full network layer connectivity among all hosts
  inside an enterprise as well as among all public hosts of different
  enterprises. The cost of using private internet address space is the
  potentially costly effort to renumber hosts and networks between
  public and private.

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 Internet has grown beyond anyone's expectations. Sustained
  exponential growth continues to introduce new challenges.  One
  challenge is a concern within the community that globally unique
  address space will be exhausted. A separate and far more pressing
  concern is that the amount of routing overhead will grow beyond the



Rekhter, et al           Best Current Practice                  [Page 1]

RFC 1918        Address Allocation for Private Internets   February 1996


  capabilities of Internet Service Providers. Efforts are in progress
  within the community to find long term solutions to both of these
  problems. Meanwhile it is necessary to revisit address allocation
  procedures, and their impact on the Internet routing system.

  To contain growth of routing overhead, an Internet Provider obtains a
  block of address space from an address registry, and then assigns to
  its customers addresses from within that block based on each customer
  requirement. The result of this process is that routes to many
  customers will be aggregated together, and will appear to other
  providers as a single route [RFC1518], [RFC1519].  In order for route
  aggregation to be effective, Internet providers encourage customers
  joining their network to use the provider's block, and thus renumber
  their computers. Such encouragement may become a requirement in the
  future.

  With the current size of the Internet and its growth rate it is no
  longer realistic to assume that by virtue of acquiring globally
  unique IP addresses out of an Internet registry an organization that
  acquires such addresses would have Internet-wide IP connectivity once
  the organization gets connected to the Internet. To the contrary, it
  is quite likely that when the organization would connect to the
  Internet to achieve Internet-wide IP connectivity the organization
  would need to change IP addresses (renumber) all of its public hosts
  (hosts that require Internet-wide IP connectivity), regardless of
  whether the addresses used by the organization initially were
  globally unique or not.

  It has been typical to assign globally unique addresses to all hosts
  that use TCP/IP. In order to extend the life of the IPv4 address
  space, address registries are requiring more justification than ever
  before, making it harder for organizations to acquire additional
  address space [RFC1466].

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

     Category 1: hosts that do not require access to hosts in other
                 enterprises or the Internet at large; hosts within
                 this category may use IP addresses that are
                 unambiguous within an enterprise, but may be
                 ambiguous between enterprises.

     Category 2: hosts that need access to a limited set of outside
                 services (e.g., E-mail, FTP, netnews, remote login)
                 which can be handled by mediating gateways (e.g.,
                 application layer gateways). For many hosts in this
                 category an unrestricted external access (provided



Rekhter, et al           Best Current Practice                  [Page 2]

RFC 1918        Address Allocation for Private Internets   February 1996


                 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.

     Category 3: hosts that need network layer access outside the
                 enterprise (provided via IP connectivity); hosts in
                 the last category require IP addresses that are
                 globally unambiguous.

  We will refer to the hosts in the first and second categories as
  "private".  We will refer to the hosts in the third category as
  "public".

  Many applications require connectivity only within one enterprise and
  do not need external (outside the enterprise) 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 organizations 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 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
          gateways are visible from the Internet. In this case, the
          internal network can use non-unique IP network numbers.

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






Rekhter, et al           Best Current Practice                  [Page 3]

RFC 1918        Address Allocation for Private Internets   February 1996


3. Private Address Space

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

    10.0.0.0        -   10.255.255.255  (10/8 prefix)
    172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
    192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

  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 (in
  pre-CIDR notation) 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 256 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, or the set of enterprises which
  choose to cooperate over this space so they may communicate with each
  other in their own private internet.

  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 and thus could be
  classified as private. Such hosts 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 host outside of the enterprise. While not
  having external (outside of the enterprise) IP connectivity private
  hosts can still have access to external services via mediating
  gateways (e.g., application layer gateways).

  All other hosts will be 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 public hosts outside the enterprise.
  Public hosts do not have connectivity to private hosts of other
  enterprises.





Rekhter, et al           Best Current Practice                  [Page 4]

RFC 1918        Address Allocation for Private Internets   February 1996


  Moving a host from private to public or vice versa involves a change
  of IP address, changes to the appropriate DNS entries, and changes to
  configuration files on other hosts that reference the host by 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 been 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. If such an enterprise
  would later connects to the Internet, this could potentially create
  very serious problems, as IP routing cannot provide correct
  operations in presence of ambiguous addressing. Although in principle
  Internet Service Providers should guard against such mistakes through
  the use of route filters, this does not always happen in practice.
  Using private address space provides a safe choice for such
  enterprises, avoiding clashes once outside connectivity is needed.





Rekhter, et al           Best Current Practice                  [Page 5]

RFC 1918        Address Allocation for Private Internets   February 1996


  A major drawback to the use of private address space is that it may
  actually reduce an enterprise's flexibility to access the Internet.
  Once one commits to using a private address, one is committing to
  renumber part or all of an enterprise, should one decide to provide
  IP connectivity between that part (or all of the enterprise) and the
  Internet.  Usually the cost of renumbering can be measured by
  counting the number of hosts that have to transition from private to
  public. As was discussed earlier, however, even if a network uses
  globally unique addresses, it may still have to renumber in order to
  acquire Internet-wide IP connectivity.

  Another drawback to the use of private address space is that it may
  require renumbering when merging several private internets into a
  single private internet. If we review the examples we list in Section
  2, we note that companies tend to merge. If such companies prior to
  the merge maintained their uncoordinated internets using private
  address space, then if after the merge these private internets would
  be combined into a single private internet, some addresses within the
  combined private internet may not be unique. As a result, hosts with
  these addresses would need to be renumbered.

  The cost of renumbering may well be mitigated by development and
  deployment of tools that facilitate renumbering (e.g.  Dynamic Host
  Configuration Protocol (DHCP)). When deciding whether to use private
  addresses, we recommend to inquire computer and software vendors
  about availability of such tools.  A separate IETF effort (PIER
  Working Group) is pursuing full documentation of the requirements and
  procedures for renumbering.

5. Operational Considerations

  One possible 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 does not need to be fixed permanently. If a group of one
  or more hosts requires to change their status (from private to public
  or vice versa) later, this can be accomplished by renumbering only
  the hosts involved, and changing physical connectivity, if needed. In
  locations where such changes can be foreseen (machine rooms, etc.),
  it is advisable to configure separate physical media for public and
  private subnets to facilitate such changes.  In order to avoid major
  network disruptions, it is advisable to group hosts with similar
  connectivity needs on their own subnets.






Rekhter, et al           Best Current Practice                  [Page 6]

RFC 1918        Address Allocation for Private Internets   February 1996


  If a suitable subnetting scheme can be designed and is supported by
  the equipment concerned, it is advisable to use the 24-bit block
  (class A network) of private address space and make an addressing
  plan with a good growth path. If subnetting is a problem, the 16-bit
  block (class C networks), or the 20-bit block (class B networks) of
  private address space can be used.

  One might be tempted to have both public and private addresses on the
  same physical medium. While this is possible, there are pitfalls to
  such a design (note that the pitfalls have nothing to do with the use
  of private addresses, but are due to the presence of multiple IP
  subnets on a common Data Link subnetwork).  We advise caution when
  proceeding in this area.

  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.

  It is possible for two sites, who both coordinate their private
  address space, to communicate with each other over a public network.
  To do so they must use some method of encapsulation at their borders
  to a public network, thus keeping their private addresses private.

  If two (or more) organizations follow the address allocation
  specified in this document and then later wish to establish IP
  connectivity with each other, then there is a risk that address
  uniqueness would be violated.  To minimize the risk it is strongly
  recommended that an organization using private IP addresses choose
  randomly from the reserved pool of private addresses, when allocating
  sub-blocks for its internal allocation.

  If an enterprise uses the private address space, or a mix of private
  and public address spaces, then DNS clients outside of the enterprise
  should not see addresses in the private address space used by the
  enterprise, since these addresses would be ambiguous.  One way to
  ensure this is to run two authority servers for each DNS zone
  containing both publically and privately addressed hosts.  One server
  would be visible from the public address space and would contain only
  the subset of the enterprise's addresses which were reachable using
  public addresses.  The other server would be reachable only from the
  private network and would contain the full set of data, including the
  private addresses and whatever public addresses are reachable the
  private network.  In order to ensure consistency, both servers should
  be configured from the same data of which the publically visible zone



Rekhter, et al           Best Current Practice                  [Page 7]

RFC 1918        Address Allocation for Private Internets   February 1996


  only contains a filtered version. There is certain degree of
  additional complexity associated with providing these capabilities.

6. Security Considerations

  Security issues are not addressed in this memo.

7. 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. However, use of private addressing requires that an
  organization renumber part or all of its enterprise network, as its
  connectivity requirements change over time.

8. Acknowledgments

  We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-
  Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN
  Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne
  Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks),
  Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute),
  Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush
  (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg
  Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence),
  Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet
  Software Consortium) for their review and constructive comments.

9. References

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

  [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
      Allocation with CIDR", RFC 1518, September 1993.

  [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
      Inter-Domain Routing (CIDR): an Address Assignment and
      Aggregation Strategy", RFC 1519, September 1993.








Rekhter, et al           Best Current Practice                  [Page 8]

RFC 1918        Address Allocation for Private Internets   February 1996


10. Authors' Addresses

  Yakov Rekhter
  Cisco systems
  170 West Tasman Drive
  San Jose, CA, USA
  Phone: +1 914 528 0090
  Fax: +1 408 526-4952
  EMail: [email protected]


  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: [email protected]


  Daniel Karrenberg
  RIPE Network Coordination Centre
  Kruislaan 409
  1098 SJ Amsterdam, the Netherlands
  Phone: +31 20 592 5065
  Fax: +31 20 592 5090
  EMail: [email protected]


  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: [email protected]


  Eliot Lear
  Mail Stop 15-730
  Silicon Graphics, Inc.
  2011 N. Shoreline Blvd.
  Mountain View, CA 94043-1389
  Phone: +1 415 960 1980
  Fax:   +1 415 961 9584
  EMail: [email protected]




Rekhter, et al           Best Current Practice                  [Page 9]

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.