HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:10:31 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 07 Jun 1996 22:00:00 GMT ETag: "304baa-43d7-31b8a660" Accept-Ranges: bytes Content-Length: 17367 Connection: close Content-Type: text/plain PIER Working Group P. Ferguson Internet Draft cisco Systems, Inc. June 1996 Expires in six months Network Renumbering Overview: Why would I want it and what is it anyway? draft-ietf-pier-renum-ovrvw-00.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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. draft-ietf-pier-renum-ovrvw-00.txt [Page 1] INTERNET-DRAFT Network Renumbering Overview June 1996 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3 4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3 5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 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. Also, in many instances, organizations who have never connected to draft-ietf-pier-renum-ovrvw-00.txt [Page 2] INTERNET-DRAFT Network Renumbering Overview June 1996 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. 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. A. Initial connectivity and usage of 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 are 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 [4] and the use of private address space, as specified in [5]. 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. draft-ietf-pier-renum-ovrvw-00.txt [Page 3] INTERNET-DRAFT Network Renumbering Overview June 1996 B. 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. Also, when a site or company makes major changes in it's internal network topology, for whatever reason, partial or complete renumbering may be necessary even if the network prefix does not change. C. 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) [6], 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 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. draft-ietf-pier-renum-ovrvw-00.txt [Page 4] INTERNET-DRAFT Network Renumbering Overview June 1996 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. D. Returning segregate prefixes for an aggregate 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. 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. This is also a highly encouraged method to help in reducing the size of the global routing table. E. Transitioning to IP version 6 Of course, when IPv6 [7] 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 advertize new prefixes. IPv6 address allocation will be managed by the Internet Assigned Numbers Authority (IANA) as set forth in [8]. F. 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. draft-ietf-pier-renum-ovrvw-00.txt [Page 5] INTERNET-DRAFT Network Renumbering Overview June 1996 5. Summary As indicated by the Internet Architecture Board (IAB) in [9], 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. 8. References [1] RFC-1814, ``Unique Addresses are Good''; E. Gerich; IAB; June 1995 [2] RFC-1775, ``To Be `On' the Internet''; D. Crocker, March 1995 [3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES'', K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg; draft-hubbard-registry-guidelines-01.txt [4] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang, P. Francis; May 1994 [5] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 [6] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu, K. Varadhan; October 1993 [7] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification''; S. Deering, R. Hinden; December 1995 draft-ietf-pier-renum-ovrvw-00.txt [Page 6] INTERNET-DRAFT Network Renumbering Overview June 1996 [8] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG; December 1995 [9] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter; IAB; February 1996 9. Author's Address 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 draft-ietf-pier-renum-ovrvw-00.txt [Page 7]