rfc1918.txt

中、英文RFC文档大全打包下载完全版 .

   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 been 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. If such an enterprise
   would later connects to the Internet, this could potentially create
   very serious problems, as IP routing cannot provide correct
   operations in presence of ambiguous addressing. Although in principle
   Internet Service Providers should guard against such mistakes through
   the use of route filters, this does not always happen in practice.
   Using private address space provides a safe choice for such
   enterprises, avoiding clashes once outside connectivity is needed.





Rekhter, et al           Best Current Practice                  [Page 5]

RFC 1918        Address Allocation for Private Internets   February 1996


   A major drawback to the use of private address space is that it may
   actually reduce an enterprise's flexibility to access the Internet.
   Once one commits to using a private address, one is committing to
   renumber part or all of an enterprise, should one decide to provide
   IP connectivity between that part (or all of the enterprise) and the
   Internet.  Usually the cost of renumbering can be measured by
   counting the number of hosts that have to transition from private to
   public. As was discussed earlier, however, even if a network uses
   globally unique addresses, it may still have to renumber in order to
   acquire Internet-wide IP connectivity.

   Another drawback to the use of private address space is that it may
   require renumbering when merging several private internets into a
   single private internet. If we review the examples we list in Section
   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.






Rekhter, et al           Best Current Practice                  [Page 6]

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



Rekhter, et al           Best Current Practice                  [Page 7]

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.

6. Security Considerations

   Security issues are not addressed in this memo.

7. 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. However, use of private addressing requires that an
   organization renumber part or all of its enterprise network, as its
   connectivity requirements change over time.

8. Acknowledgments

   We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-
   Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN
   Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne
   Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks),
   Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute),
   Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush
   (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg
   Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence),
   Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet
   Software Consortium) for their review and constructive comments.

9. References

   [RFC1466] Gerich, E., "Guidelines for Management of IP Address
       Space", RFC 1466, Merit Network, Inc., May 1993.

   [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
       Allocation with CIDR", RFC 1518, September 1993.

   [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
       Inter-Domain Routing (CIDR): an Address Assignment and
       Aggregation Strategy", RFC 1519, September 1993.








Rekhter, et al           Best Current Practice                  [Page 8]

RFC 1918        Address Allocation for Private Internets   February 1996


10. Authors' Addresses

   Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA
   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015
   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Eliot Lear
   Mail Stop 15-730
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA 94043-1389
   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]




Rekhter, et al           Best Current Practice                  [Page 9]