rfc2071.txt

RFC 的详细文档！

4.2.5  Expansion of Dialup Services

   Dialup services, especially public Internet access providers, are
   experiencing explosive growth. This success represents a particular
   drain on the available address space, especially with a commonly used
   practice of assigning unique addresses to each customer.

   In this case, individual users announce their address to the access
   server using PPP's IP control protocol (IPCP) [12]. The server may
   validate the proposed address against some type of user
   identification, or simply make the address active in a subnet to
   which the access server (or set of bridged access servers) belongs.

   The preferred technique is to allocate dynamic addresses to the user
   from a pool of addresses available to the access server.

4.2.6  Returning non-contiguous prefixes for an aggregate

   In many instances, an organization can return their current, non-
   contiguous prefix allocations for a contiguous block of address space
   of equal or greater size, which can be accommodated with CIDR.  Also,
   many organizations have begun to deploy classless interior routing
   protocols within their domains that make use of route summarization
   and other optimized routing features, effectively reducing the total
   number of routes being propagated within their internal network(s),
   and making it much easier to administer and maintain.

   Hierarchical routing protocols such as OSPF scale best when the
   address assignment of a given network reflects the topology, and the
   topology of the network can often be fluid. Given that the network is
   fluid, even the best planned address assignment scheme, given time,
   will diverge from the actual topology. While not required, some



Ferguson & Berkowitz         Informational                     [Page 10]

RFC 2071              Network Renumbering Overview          January 1997


   organization may choose to gain the benefit of both technical and
   administrative scalability of their IGP by periodically renumbering
   to have address assignments reflect the network topology. Patrick
   Henry once said "the tree of liberty must from time to time be
   watered with the blood of patriots." In the Internet, routing trees
   of the best-planned networks need from time to time be watered with
   at least the sweat of network administrators.  Improving aggregation
   is also highly encouraged to reduce the size of not only the global
   Internet routing table, but also the size and scalability of interior
   routing within the enterprise.

4.3  Future

   Emerging new protocols will most definitely affect addressing plans
   and numbering schemes.

4.3.1  Internal Use of Switched Virtual Circuit Services

   Services such as ATM virtual circuits, switched frame relay, etc.,
   present challenges not considered in the original IP design.  The
   basic IP decision in forwarding a packet is whether the destination
   is local or remote, in relation to the source host's subnet. Address
   resolution mechanisms are used to find the medium address of the
   destination in the case of local destinations, or to find the medium
   address of the router in the case of remote routers.

   In these new services, there are cases where it is far more effective
   to "cut-through" a new virtual circuit to the destination. If the
   destination is on a different subnet than the source, the cut-through
   typically is to the egress router that serves the destination subnet.
   The advantage of cut-through in such a case is that it avoids the
   latency of multiple router hops, and reduces load on "backbone"
   routers. The cut-through decision is usually made by an entry router
   that is aware of both the routed and switched environments.

   This entry router communicates with a address resolution server using
   the Next Hop Resolution Protocol (NHRP) [13]. This server maps the
   destination network address to either a next-hop router (where cut-
   through is not appropriate) or to an egress router reached over the
   switched service. Obviously, the data base in such a server may be
   affected by renumbering. Clients may have a hard-coded address of the
   server, which again may need to change.  While the NHRP protocol
   specifications are still evolving at the time of this writing,
   commercial implementations based on drafts of the protocol standard
   are in use.






Ferguson & Berkowitz         Informational                     [Page 11]

RFC 2071              Network Renumbering Overview          January 1997


4.3.2  Transitioning to IP version 6

   Of course, when IPv6 [14] deployment is set in motion, and as
   methodologies are developed to transition to IPv6, renumbering will
   also be necessary, but perhaps not immediately mandatory.  To aid in
   the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6 stacks
   on network hosts should also become available. It is also envisioned
   that Network Address Translation (NAT) devices will be developed to
   assist in the IPv4 to IPv6 transition, or perhaps supplant the need
   to renumber the majority of interior networks altogether, but that is
   beyond the scope of this document. At the very least, DNS hosts will
   need to be reconfigured to resolve new host names and addresses, and
   routers will need to be reconfigured to advertise new prefixes.

   IPv6 address allocation will be managed by the Internet Assigned
   Numbers Authority (IANA) as set forth in [15].

5. Summary

   As indicated by the Internet Architecture Board (IAB) in [16], the
   task of renumbering networks is becoming more widespread and
   commonplace.  Although there are numerous reasons why an organization
   would desire, or be required to renumber, there are equally as many
   reasons why address allocation should be done with great care and
   forethought at the onset, in order to minimize the impact that
   renumbering would have on the organization. Even with the most
   forethought and vision, however, an organization cannot foresee the
   possibility for renumbering. The best advice, in this case, is to be
   prepared, and get ready for renumbering.

6. Security Considerations

   Although no obvious security issues are discussed in this document,
   it stands to reason that renumbering certain devices can defeat
   security systems designed and based on static IP host addresses.
   Care should be exercised by the renumbering entity to ensure that all
   security systems deployed with the network(s) which may need to be
   renumbered be given special consideration and significant forethought
   to provide continued functionality and adequate security.

7. Acknowledgments

   Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.], Tony
   Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for their
   contributions and editorial critique.






Ferguson & Berkowitz         Informational                     [Page 12]

RFC 2071              Network Renumbering Overview          January 1997


8. References

 [1] Gerich, E., "Unique Addresses are Good", RFC 1814, IAB, July 1995.

 [2] Crocker, D., "To Be `On' the Internet", RFC 1775, March 1995.

 [3] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J.
     Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
     BCP 12, RFC 2050, November 1996.

 [4] Mockapetris, P., "Domain Names - Concepts and Facilities",
     and  "Domain Names - Implementation and Specification",
     STD 13, RFCs 1034, 1035, November 1987.

 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
     October 1993.

 [6] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
     January 1997.

 [7] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
     Network Management Protocol (SNMP)", STD 15, RFC 1157,
     May 1990.

 [8] Egevang,, K., and P. Francis, "The IP Network Address Translator
     (NAT)", RFC 1631, May 1994.

 [9] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J., and E.
     Lear, "Address Allocation for Private Internets", RFC 1918,
     February 1996.

 [10] Messages to PIER list on CERN renumbering; Brian Carpenter, CERN.
      Available in PIER WG mailing list archives.

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

 [12] McGregor, G., "The PPP Internet Protocol Control Protocol
      (IPCP)", RFC 1332, May 1992.

 [13] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next
      Hop Resolution Protocol (NHRP)", Work in Progress.

 [14] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
      Specification", RFC 1883, December 1995.





Ferguson & Berkowitz         Informational                     [Page 13]

RFC 2071              Network Renumbering Overview          January 1997


 [15] IAB and IESG, "IPv6 Address Allocation Management", RFC 1881,
      December 1995.

 [16] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900,
      February 1996.

9. Authors' Addresses

   Paul Ferguson
   cisco Systems, Inc.
   1875 Campus Commons Road
   Suite 210
   Reston, VA 22091

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Howard C. Berkowitz
   PSC International
   1600 Spring Hill Road
   Vienna, VA 22182

   Phone [phone]
   Fax:  [phone]
   EMail:  [e-mail]
























Ferguson & Berkowitz         Informational                     [Page 14]