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.
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
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.
=4= |