Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Obsoleted by:1918 INFORMATIONAL
Network Working Group                                        Y. RekhterRequest 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 1994Address Allocation for Private InternetsStatus 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.Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 1]

RFC 1597        Address Allocation for Private Internets      March 1994   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.Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 2]

RFC 1597        Address Allocation for Private Internets      March 1994      - 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 networkRekhter, Moskowitz, Karrenberg & de Groot                       [Page 3]

RFC 1597        Address Allocation for Private Internets      March 1994   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 veryRekhter, Moskowitz, Karrenberg & de Groot                       [Page 4]

RFC 1597        Address Allocation for Private Internets      March 1994   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.Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 5]

RFC 1597        Address Allocation for Private Internets      March 1994   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.Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 6]

RFC 1597        Address Allocation for Private Internets      March 19946. References   [1] Gerich, E., "Guidelines for Management of IP Address Space",RFC1466, 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.Rekhter, Moskowitz, Karrenberg & de Groot                       [Page 7]

RFC 1597        Address Allocation for Private Internets      March 199410. 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.netRekhter, Moskowitz, Karrenberg & de Groot                       [Page 8]

[8]ページ先頭

©2009-2025 Movatter.jp