📄 rfc1597.txt
字号:
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 19946. 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 199410. 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.netRekhter, Moskowitz, Karrenberg & de Groot [Page 8]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -