From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2071.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2071.txt (limited to 'doc/rfc/rfc2071.txt') diff --git a/doc/rfc/rfc2071.txt b/doc/rfc/rfc2071.txt new file mode 100644 index 0000000..989e9dd --- /dev/null +++ b/doc/rfc/rfc2071.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group P. Ferguson +Request for Comments: 2071 cisco Systems, Inc. +Category: Informational H. Berkowitz + PSC International + January 1997 + + Network Renumbering Overview: + Why would I want it and what is it anyway? + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The PIER [Procedures for Internet/Enterprise Renumbering] working + group is compiling a series of documents to assist and instruct + organizations in their efforts to renumber. However, it is becoming + apparent that, with the increasing number of new Internet Service + Providers (ISP's) and organizations getting connected to the Internet + for the first time, the concept of network renumbering needs to be + further defined. This document attempts to clearly define the + concept of network renumbering and discuss some of the more pertinent + reasons why an organization would have a need to do so. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3 + 4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3 + 5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + +Ferguson & Berkowitz Informational [Page 1] + +RFC 2071 Network Renumbering Overview January 1997 + + +1. Introduction + + The popularity of connecting to the global Internet over the course + of the past several years has spawned new problems; what most people + casually refer to as "growing pains" can be attributed to more basic + problems in understanding the requirements for Internet connectivity. + However, the reasons why organizations may need to renumber their + networks can greatly vary. We'll discuss these issues in some amount + of detail below. It is not within the intended scope of this + document to discuss renumbering methodologies, techniques, or tools. + +2. Background + + The ability for any network or interconnected devices, such as + desktop PCs or workstations, to obtain connectivity to any potential + destination in the global Internet is reliant upon the possession of + unique IP host addresses [1]. A duplicate host address that is being + used elsewhere in the Internet could best be described as + problematic, since the presence of duplicate addresses would cause + one of the destinations to be unreachable from some origins in the + Internet. It should be noted, however, that globally unique IP + addresses are not always necessary, and is dependent on the + connectivity requirements [2]. + + However, the recent popularity in obtaining Internet connectivity has + made these types of connectivity dependencies unpredictable, and + conventional wisdom in the Internet community dictates that the + various address allocation registries, such as the InterNIC, as well + as the ISP's, become more prudent in their address allocation + strategies. In that vein, the InterNIC has defined address + allocation policies [3] wherein the majority of address allocations + for end-user networks are accommodated by their upstream ISP, except + in cases where dual- or multihoming and very large blocks of + addresses are required. With this allocation policy becoming + standard current practice, it presents unique problems regarding the + portability of addresses from one provider to another. + + As a practical matter, end users cannot assume they "own" address + allocations, if their intention is to be to have full connectivity to + the global Internet. Rather, end users will "borrow" part of the + address space of an upstream provider's allocation. The larger + provider block from which their space is suballocated will have been + assigned in a manner consistent with global Internet routing. + + Not having "permanent" addresses does not mean users will not have + unique identifiers. Such identifiers are typically Domain Name System + (DNS) [4] names for endpoints such as servers and workstations. + Mechanisms such as the Dynamic Host Configuration Protocol (DHCP) [5] + + + +Ferguson & Berkowitz Informational [Page 2] + +RFC 2071 Network Renumbering Overview January 1997 + + + can help automate the assignment and maintenance of host names, as + well as the 'borrowed' addresses required for routing-level + connectivity. + + The PIER Working Group is developing procedures and guidelines for + detailed renumbering of specific technologies, such as routers [6]. + PIER WG documents are intended to suggest methods both for making + existing networks prepared for convenient renumbering, as well as for + operational transition to new addressing schemes. + + Also, in many instances, organizations who have never connected to + the Internet, yet have been using arbitrary blocks of addresses since + their construction, have different and unique challenges. + +3. Network Renumbering Defined + + In the simplest of definitions, the exercise of renumbering a network + consists of changing the IP host addresses, and perhaps the network + mask, of each device within the network that has an address + associated with it. This activity may or may not consist of all + networks within a particular domain, such as FOO.EDU, or networks + which comprise an entire autonomous system. + + Devices which may need to be renumbered, for example, are networked + PC's, workstations, printers, file servers, terminal servers, and + routers. Renumbering a network may involve changing host parameters + and configuration files which contain IP addresses, such as + configuration files which contain addresses of DNS and other servers, + addresses contained in SNMP [7] management stations, and addresses + configured in access control lists. While this is not an all- + inclusive list, the PIER working group is making efforts to compile + documentation to identify these devices in a more detailed fashion. + + Network renumbering need not be sudden activity, either; in most + instances, an organization's upstream service provider(s) will allow + a grace period where both the "old" addresses and the "new" addresses + may be used in parallel. + +4. Reasons for Renumbering + + The following sections discuss particular reasons which may + precipitate network renumbering, and are not presented in any + particular order of precedence. They are grouped into reasons that + primarily reflect decisions made in the past, operational + requirements of the present, or plans for the future. + + + + + + +Ferguson & Berkowitz Informational [Page 3] + +RFC 2071 Network Renumbering Overview January 1997 + + + Some of these requirements reflect evolution in the organization's + mission, such as a need to communicate with business partners, or to + work efficiently in a global Internet. Other requirements reflect + changes in network technologies. + +4.1 Past + + Many organizations implemented IP-based networks not for connectivity + to the Internet, but simply to make use of effective data + communications mechanisms. These organizations subsequently found + valid reasons to connect to other organizations or the Internet in + general, but found the address structures they chose incompatible + with overall Internet practice. + + Other organizations connected early to the Internet, but did so at a + time when address space was not scarce. Yet other organizations + still have no requirement to connect to the Internet, but have legacy + addressing structures that do not scale to adequate size. + +4.1.1 Initial addressing using non-unique addresses + + As recently as two years ago, many organizations had no intention of + connecting to the Internet, and constructed their corporate or + organizational network(s) using unregistered, non-unique network + addresses. Obviously, as most problems evolve, these same + organizations determined that Internet connectivity had become a + valuable asset, and subsequently discovered that they could no longer + use the same unregistered, non-unique network addresses that were + previously deployed throughout their organization. Thus, the labor + of renumbering to valid network addresses is now upon them, as they + move to connect to the global Internet. + + While obtaining valid, unique addresses is certainly required to + obtain full Internet connectivity in most circumstances, the number + of unique addresses required can be significantly reduced by the + implementation of Network Address Translation (NAT) devices [8] and + the use of private address space, as specified in [9]. NAT reduces + not only the number of required unique addresses, but also localizes + the changes required by renumbering. + + It should also be noted that NAT technology may not always be a + viable option, depending upon scale of addressing, performance or + topological constraints. + + + + + + + + +Ferguson & Berkowitz Informational [Page 4] + +RFC 2071 Network Renumbering Overview January 1997 + + +4.1.2 Legacy address allocation + + There are also several instances where organizations were originally + allocated very large amounts of address space, such as traditional + "Class A" or "Class B" allocations, while the actual address + requirements are much less than the total amount of address space + originally allocated. In many cases, these organizations could + suffice with a smaller CIDR allocation, and utilize the allocated + address space in a more efficient manner. As allocation requirements + become more stringent, mechanisms to review how these organizations + are utilizing their address space could, quite possibly, result in a + request to return the original allocation to a particular registry + and renumber with a more appropriately sized address block. + +4.1.3 Limitations of Bridged Internetworks + + Bridging has a long and distinguished history in legacy networks. As + networks grow, however, traditional bridged networks reach + performance- and stability-related limits, including (but not limited + to) broadcast storms. + + Early routers did not have the speed to handle the needs of some + large networks. Some organizations were literally not able to move + to routers until router forwarding performance improved to be + comparable to bridges. Now that routers are of comparable or + superior speed, and offer more robust features, replacing bridged + networks becomes reasonable. + + IP addresses assigned to pure bridged networks tend not to be + subnetted, yet subnetting is a basic approach for router networks. + Introducing subnetting is a practical necessity in moving from + bridging to routing. + + Special cases of bridging are realized in workgroup switching + systems, discussed below. + +4.1.4 Limitations of Legacy Routing Systems + + Other performance problems might come from routing mechanisms that + advertise excessive numbers of routing updates (e.g., RIP, IGRP). + Likewise, appropriate replacement protocols (e.g., OSPF, EIGRP, S-IS) + will work best with a structured addressing system that encourages + aggregation. + + + + + + + + +Ferguson & Berkowitz Informational [Page 5] + +RFC 2071 Network Renumbering Overview January 1997 + + +4.1.5 Limitations of System Administration Methodologies + + There can be operational limits to growth based on the difficulty of + adds, moves and changes. As enterprise networks grow, it may be + necessary to delegate portions of address assignment and maintenance. + If address space has been assigned randomly or inefficiently, it may + be difficult to delegate portions of the address space. + + It is not unusual for organizational networks to grow sporadically, + obtaining an address prefix here and there, in a non-contiguous + fashion. Depending on the number of prefixes that an organization + acquires over time, it may become increasingly unmanageable or demand + higher levels of maintenance and administration when individual + prefixes are acquired in this way. + + Reasonable IP address management may in general simplify continuing + system administration; a good numbering plan is also a good + renumbering plan. Renumbering may force a discipline into system + administration that will reduce long-term support costs. + + It has been observed "...there is no way to renumber a network + without an inventory of the hosts (absent DHCP). On a large network + that needs a database, plus tools and staff to maintain the + database."[10] It can be argued that a detailed inventory of router + configurations is even more essential. + +4.2 Present + + Organizations now face needs to connect to the global Internet, or at + a minimum to other organizations through bilateral private links. + + Certain new transmission technologies have tended to redefine the + basic notion of an IP subnet. An IP numbering plan needs to work + with these new ideas. Legacy bridged networks and leading-edge + workgroup switched networks may very well need changes in the + subnetting structure. Renumbering needs may also develop due to the + characteristics of new WAN technologies, especially nonbroadcast + multi-access (NBMA) services such as Frame-Relay and Asynchronous + Transfer Mode (ATM). + + Increased use of telecommuting by mobile workers, and in small and + home offices, need on-demand WAN connectivity, using modems or ISDN. + Effective use of demand media often requires changes in numbering and + routing. + + + + + + + +Ferguson & Berkowitz Informational [Page 6] + +RFC 2071 Network Renumbering Overview January 1997 + + +4.2.1 Change in organizational structure or network topology + + As companies grow, through mergers, acquisitions and reorganizations, + the need may arise for realignment and modification of the various + organizational network architectures. The connectivity of disparate + corporate networks present unique challenges in the realm of + renumbering, since one or more individual networks may have to be + blended into a much larger architecture consisting a different IP + address prefix altogether. + +4.2.2 Inter-Enterprise Connectivity + + Even if they do not connect to the general Internet, enterprises may + interconnect to other organizations which have independent numbering + systems. Such connectivity can be as simple as bilateral dedicated + circuits. If both enterprises use unregistered or private address + space, they run the risk of using duplicate addresses. + + In such cases, one or both organizations may need to renumber into + different parts of the private address space, or obtain unique + registered addresses. + +4.2.3 Change of Internet Service Provider + + As mentioned previously in Section 2, it is increasingly becoming + current practice for organizations to have their IP addresses + allocated by their upstream ISP. Also, with the advent of Classless + Inter Domain Routing (CIDR) [11], and the considerable growth in the + size of the global Internet table, Internet Service Providers are + becoming more and more reluctant to allow customers to continue using + addresses which were allocated by the ISP, when the customer + terminates service and moves to another ISP. The prevailing reason + is that the ISP was previously issued a CIDR block of contiguous + address space, which can be announced to the remainder of the + Internet community as a single prefix. (A prefix is what is referred + to in classless terms as a contiguous block of IP addresses.) If a + non-customer advertises a specific component of the CIDR block, then + this adds an additional routing entry to the global Internet routing + table. This is what is commonly referred to as "punching holes" in a + CIDR block. Consequently, there are usually no routing anomalies in + doing this since a specific prefix is always preferred over an + aggregate route. However, if this practice were to happen on a large + scale, the growth of the global routing table would become much + larger, and perhaps too large for current backbone routers to + accommodate in an acceptable fashion with regards to performance of + recalculating routing information and sheer size of the routing table + itself. For obvious reasons, this practice is highly discouraged by + ISP's with CIDR blocks, and some ISP's are making this a contractual + + + +Ferguson & Berkowitz Informational [Page 7] + +RFC 2071 Network Renumbering Overview January 1997 + + + issue, so that customers understand that addresses allocated by the + ISP are non-portable. + + It is noteworthy to mention that the likelihood of being forced to + renumber in this situation is inversely proportional to the size of + the customer's address space. For example, an organization with a + /16 allocation may be allowed to consider the address space + "portable", while an organization with multiple non-contiguous /24 + allocations may not. While the scenarios may be vastly different in + scope, it becomes an issue to be decided at the discretion of the + initial allocating entity, and the ISP's involved; the major deciding + factor being whether or not the change will fragment an existing CIDR + block and whether it will significantly contribute to the overall + growth of the global Internet routing tables. + + It should also be noted that (contrary to opinions sometimes voiced) + this form of renumbering is a technically necessary consequence of + changing ISP's, rather than a commercial or political mandate. + +4.2.3 Internet Global Routing + + Even large organizations, now connected to the Internet with + "portable" address space, may find their address allocation too + small. Current registry guidelines require that address space usage + be justified by an engineering plan. Older networks may not have + efficiently utilized existing address space, and may need to make + their existing structures more efficient before new address + allocations can be made. + +4.2.4 Internal Use of LAN Switching + + Introducing workgroup switches may introduce subtle renumbering + needs. Fundamentally, workgroup switches are specialized, high- + performance bridges, which make their main forwarding decisions based + on Layer 2 (MAC) address information. Even so, they rarely are + independent of Layer 3 (IP) address structure. Pure Layer 2 + switching has a "flat" address space that will need to be renumbered + into a hierarchical, subnetted space consistent with routing. + + Introducing single switches or stacks of switches may not have + significant impact on addressing, as long as it is understood that + each system of switches is a single broadcast domain. Each broadcast + domain should map to a single IP subnetwork. + + Virtual LANs (VLANs) further extend the complexity of the role of + workgroup switches. It is generally true that moving an end station + from one switch port to another within the same VLAN will not cause + major changes in addressing. Many overview presentations of this + + + +Ferguson & Berkowitz Informational [Page 8] + +RFC 2071 Network Renumbering Overview January 1997 + + + technology do not make it clear that moving the same end station + between different VLANs will move the end station into another IP + subnet, requiring a significant address change. + + Switches are commonly managed by SNMP applications. These network + management applications communicate with managed devices using IP. + Even if the switch does not do IP forwarding, it will itself need IP + addresses if it is to be managed. Also, if the clients and servers in + the workgroup are managed by SNMP, they will also require IP + addresses. The workgroup, therefore, will need to appear as one or + more IP subnetworks. + + Increasingly, internetworking products are not purely Layer 2 or + Layer 3 devices. A workgroup switch product often includes a routing + function, so the numbering plan must support both flat Layer 2 and + hierarchical Layer 3 addressing. + +4.2.4 Internal Use of NBMA Cloud Services + + "Cloud" services such as frame relay often are more economical than + traditional services. At first glance, when converting existing + enterprise networks to NBMA, it might appear that the existing subnet + structure should be preserved, but this is often not the case. + + Many organizations often began by treating the "cloud" as a single + subnet, but experience has shown it is often better to treat the + individual virtual circuits as separate subnets, which appear as + traditional point-to-point circuits. When the individual point-to- + point VCs become separate subnets, efficient address utilization + requires the use of long prefixes (i.e., 30 bit) for these subnets. + In practice, obtaining 30 bit prefixes means the logical network + should support variable length subnet masks (VLSM). VLSMs are the + primary method in which an assigned prefix can be subnetted + efficiently for different media types. This is accomplished by + establishing one or more prefix lengths for LAN media with more than + two hosts, and subdividing one or more of these shorter prefixes into + longer /30 prefixes that minimize address loss. + + There are alternative ways to configure routing over NBMA, using + special mechanisms to exploit or simulate point-to-multipoint VCs. + These often have a significant performance impact, and may be less + reliable because a single routing point of failure is created. + Motivations for such alternatives tend to include: + + + + + + + + +Ferguson & Berkowitz Informational [Page 9] + +RFC 2071 Network Renumbering Overview January 1997 + + + 1. A desire not to use VLSM. This is often founded in fear + rather than technology. + + 2. Router implementation issues that limit the number of subnets + or interfaces a given router can support. + + 3. An inherently point-to-multipoint application (e.g., remote + hosts to a data center). In such cases, some of the + limitations are due to the dynamic routing protocol in use. + In such "hub-and-spoke" implementations, static routing can + be preferable from a performance and flexibility standpoint, + since it does not produce routing protocol chatter and is + unaffected by split horizon constraints (namely, the inability + to build an adjacency with a peer within the same IP + subnetwork). + +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: (703) 716-9538 + Fax: (703) 716-9599 + EMail: pferguso@cisco.com + + + Howard C. Berkowitz + PSC International + 1600 Spring Hill Road + Vienna, VA 22182 + + Phone (703) 998-5819 + Fax: (703) 998-5058 + EMail: hcb@clark.net + + + + + + + + + + + + + + + + + + + + + + + + +Ferguson & Berkowitz Informational [Page 14] + -- cgit v1.2.3