452 lines
17 KiB
Plaintext
452 lines
17 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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]
|
|||
|
|