summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1597.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1597.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1597.txt')
-rw-r--r--doc/rfc/rfc1597.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1597.txt b/doc/rfc/rfc1597.txt
new file mode 100644
index 0000000..a9d747c
--- /dev/null
+++ b/doc/rfc/rfc1597.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+
+
+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 network
+
+
+
+Rekhter, 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 very
+
+
+
+Rekhter, 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 1994
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot [Page 7]
+
+RFC 1597 Address Allocation for Private Internets March 1994
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Rekhter, Moskowitz, Karrenberg & de Groot [Page 8]
+