PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc1918.txt =

page 4 of 6



   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=

1|2|3| < PREV = PAGE 4 = NEXT > |5|6

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0103781 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)