idnits 2.17.1 draft-ietf-pier-renum-ovrvw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10175 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERN' on line 285 ** Downref: Normative reference to an Informational RFC: RFC 1814 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1775 (ref. '2') == Outdated reference: A later version (-04) exists of draft-hubbard-registry-guidelines-01 ** Downref: Normative reference to an Historic draft: draft-hubbard-registry-guidelines (ref. '3') ** Obsolete normative reference: RFC 1631 (ref. '4') (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1519 (ref. '6') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1883 (ref. '7') (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '9') Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIER Working Group P. Ferguson 2 Internet Draft cisco Systems, Inc. 3 June 1996 4 Expires in six months 6 Network Renumbering Overview: 7 Why would I want it and what is it anyway? 8 draft-ietf-pier-renum-ovrvw-00.txt 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The PIER [Procedures for Internet/Enterprise Renumbering] working 32 group is compiling a series of documents to assist and instruct 33 organizations in their efforts to renumber. However, it is becoming 34 apparent that, with the increasing number of new Internet Service 35 Providers (ISP's) and organizations getting connected to the 36 Internet for the first time, the concept of network renumbering 37 needs to be further defined. This document attempts to clearly 38 define the concept of network renumbering and discuss some of the 39 more pertinent reasons why an organization would have a need to do 40 so. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 45 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3 47 4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3 48 5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 6. Security Considerations . . . . . . . . . . . . . . . . . . 5 50 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 6 51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 54 1. Introduction 56 The popularity of connecting to the global Internet over the course 57 of the past several years has spawned new problems; what most people 58 casually refer to as ``growing pains'' can be attributed to more 59 basic problems in understanding the requirements for Internet 60 connectivity. However, the reasons why organizations may need to 61 renumber their networks can greatly vary. We'll discuss these issues 62 in some amount of detail below. It is not within the intended scope 63 of this document to discuss renumbering methodologies, techniques, or 64 tools. 66 2. Background 68 The ability for any network or interconnected devices, such as 69 desktop PCs or workstations, to obtain connectivity to any potential 70 destination in the global Internet is reliant upon the possession of 71 unique IP host addresses [1]. A duplicate host address that is 72 being used elsewhere in the Internet could best be described as 73 problematic, since the presence of duplicate addresses would cause 74 one of the destinations to be unreachable from some origins in the 75 Internet. It should be noted, however, that globally unique IP 76 addresses are not always necessary, and is dependent on the 77 connectivity requirements [2]. 79 However, the recent popularity in obtaining Internet connectivity 80 has made these types of connectivity dependencies unpredictable, 81 and conventional wisdom in the Internet community dictates that 82 the various address allocation registries, such as the interNIC, 83 as well as the ISP's, become more prudent in their address 84 allocation strategies. In that vein, the interNIC has defined 85 address allocation policies [3] wherein the majority of address 86 allocations for end-user networks are accommodated by their 87 upstream ISP, except in cases where dual- or multihoming and 88 very large blocks of addresses are required. With this allocation 89 policy becoming standard current practice, it presents unique 90 problems regarding the portability of addresses from one provider 91 to another. 93 Also, in many instances, organizations who have never connected to 94 the Internet, yet have been using arbitrary blocks of addresses since 95 their construction, have different and unique challenges. 97 3. Network Renumbering Defined 99 In the simplest of definitions, the exercise of renumbering a 100 network consists of changing the IP host addresses, and perhaps 101 the network mask, of each device within the network that has an 102 address associated with it. This activity may or may not consist 103 of all networks within a particular domain, such as FOO.EDU, or 104 networks which comprise an entire autonomous system. 106 Devices which may need to be renumbered, for example, are networked 107 PC's, workstations, printers, file servers, terminal servers, and 108 routers. While this is not an all-inclusive list, the PIER working 109 group is making efforts to compile documentation to identify these 110 devices in a more detailed fashion. 112 Network renumbering need not be sudden activity, either; in most 113 instances, an organization's upstream service provider(s) will 114 allow a grace period where both the ``old'' addresses and the ``new'' 115 addresses may be used in parallel. 117 4. Reasons for Renumbering 119 The following sections discuss particular reasons which may 120 precipitate network renumbering, and are not presented in any 121 particular order of precedence. 123 A. Initial connectivity and usage of non-unique addresses 125 As recently as two years ago, many organizations had no intention 126 of connecting to the Internet, and constructed their corporate or 127 organizational network(s) using unregistered, non-unique network 128 addresses. Obviously, as most problems evolve, these same 129 organizations determined that Internet connectivity had become 130 a valuable asset, and subsequently discovered that they could no 131 longer use the same unregistered, non-unique network addresses 132 that were previously deployed throughout their organization. 133 Thus, the labor of renumbering to valid network addresses is 134 now upon them, as they move to connect to the global Internet. 136 While obtaining valid, unique addresses are certainly required 137 to obtain full Internet connectivity in most circumstances, the 138 number of unique addresses required can be significantly reduced 139 by the implementation of Network Address Translation (NAT) devices 140 [4] and the use of private address space, as specified in [5]. 141 NAT reduces not only the number of required unique addresses, but 142 also localizes the changes required by renumbering. 144 It should also be noted that NAT technology may not always be 145 a viable option, depending upon scale of addressing, performance 146 or topological constraints. 148 B. Change in organizational structure or network topology 150 As companies grow, through mergers, acquisitions and reorganizations, 151 the need may arise for realignment and modification of the various 152 organizational network architectures. The connectivity of disparate 153 corporate networks present unique challenges in the realm of 154 renumbering, since one or more individual networks may have to be 155 blended into a much larger architecture consisting a different IP 156 address prefix altogether. Also, when a site or company makes major 157 changes in it's internal network topology, for whatever reason, 158 partial or complete renumbering may be necessary even if the network 159 prefix does not change. 161 C. Change of Internet Service Provider 163 As mentioned previously in Section 2, it is increasingly becoming 164 current practice for organizations to have their IP addresses 165 allocated by their upstream ISP. Also, with the advent of Classless 166 Inter Domain Routing (CIDR) [6], and the considerable growth in the 167 size of the global Internet table, Internet Service Providers 168 are becoming more and more reluctant to allow customers to continue 169 using addresses which were allocated by the ISP, when the customer 170 terminates service and moves to another ISP. The prevailing 171 reason is that the ISP was previously issued a CIDR block of 172 contiguous address space, which can be announced to the remainder of 173 the Internet community as a single prefix. (A prefix is what is 174 referred to in classless terms as a contiguous block of IP 175 addresses.) If a non-customer advertises a specific component 176 of the CIDR block, then this adds an additional routing entry to 177 the global Internet routing table. This is what is commonly 178 referred to as ``punching holes'' in a CIDR block. Consequently, 179 there are usually no routing anomalies in doing this since a specific 180 prefix is always preferred over an aggregate route. However, if 181 this practice were to happen on a large scale, the growth of the 182 global routing table would become much larger, and perhaps too 183 large for current backbone routers to accommodate in an acceptable 184 fashion with regards to performance of recalculating routing 185 information and sheer size of the routing table itself. For obvious 186 reasons, this practice is highly discouraged by ISP's with CIDR 187 blocks, and some ISP's are making this a contractual issue, so that 188 customers understand that addresses allocated by the ISP are non- 189 portable. 191 It is noteworthy to mention that the likelihood of being forced to 192 renumber in this situation is inversely proportional to the size of 193 the customer's address space. For example, an organization with a 194 /16 allocation may be allowed to consider the address space 195 ``portable'', while an organization with multiple non-contiguous 196 /24 allocations may not. While the scenarios may be vastly different 197 in scope, it becomes an issue to be decided at the discretion of the 198 initial allocating entity, and the ISP's involved; the major deciding 199 factor being whether or not the change will fragment an existing CIDR 200 block and whether it will significantly contribute to the overall 201 growth of the global Internet routing tables. 203 It should also be noted that (contrary to opinions sometimes voiced) 204 this form of renumbering is a technically necessary consequence of 205 changing ISP's, rather than a commercial or political mandate. 207 D. Returning segregate prefixes for an aggregate 209 It is not unusual for organizational networks to grow sporadically, 210 obtaining an address prefix here and there, in a non-contiguous 211 fashion. Depending on the number of prefixes that an organization 212 acquires over time, it may become increasingly unmanageable or demand 213 higher levels of maintenance and administration when individual 214 prefixes are acquired in this way. In many instances, an 215 organization can return their current, non-contiguous prefix 216 allocations for a contiguous block of address space of equal or 217 greater size, which can be accommodated with CIDR. Also, many 218 organizations have begun to deploy classless interior routing 219 protocols within their domains that make use of route summarization 220 and other optimized routing features, effectively reducing the total 221 number of routes being propagated within their internal network(s), 222 and making it much easier to administer and maintain. This is also 223 a highly encouraged method to help in reducing the size of the global 224 routing table. 226 E. Transitioning to IP version 6 228 Of course, when IPv6 [7] deployment is set in motion, and as 229 methodologies are developed to transition to IPv6, renumbering will 230 also be necessary, but perhaps not immediately mandatory. To aid 231 in the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6 232 stacks on network hosts should also become available. It is also 233 envisioned that Network Address Translation (NAT) devices will be 234 developed to assist in the IPv4 to IPv6 transition, or perhaps 235 supplant the need to renumber the majority of interior networks 236 altogether, but that is beyond the scope of this document. At the 237 very least, DNS hosts will need to be reconfigured to resolve new 238 host names and addresses, and routers will need to be reconfigured 239 to advertize new prefixes. 241 IPv6 address allocation will be managed by the Internet Assigned 242 Numbers Authority (IANA) as set forth in [8]. 244 F. Legacy address allocation 246 There are also several instances where organizations were originally 247 allocated very large amounts of address space, such as traditional 248 ``Class A'' or ``Class B'' allocations, while the actual address 249 requirements are much less than the total amount of address space 250 originally allocated. In many cases, these organizations could 251 suffice with a smaller CIDR allocation, and utilize the allocated 252 address space in a more efficient manner. As allocation requirements 253 become more stringent, mechanisms to review how these organizations 254 are utilizing their address space could, quite possibly, result in 255 a request to return the original allocation to a particular registry 256 and renumber with a more appropriately sized address block. 258 5. Summary 260 As indicated by the Internet Architecture Board (IAB) in [9], 261 the task of renumbering networks is becoming more widespread 262 and commonplace. Although there are numerous reasons why an 263 organization would desire, or be required to renumber, there are 264 equally as many reasons why address allocation should be done with 265 great care and forethought at the onset, in order to minimize the 266 impact that renumbering would have on the organization. Even 267 with the most forethought and vision, however, an organization 268 cannot foresee the possibility for renumbering. The best advice, 269 in this case, is to be prepared, and get ready for renumbering. 271 6. Security Considerations 273 Although no obvious security issues are discussed in this 274 document, it stands to reason that renumbering certain devices 275 can defeat security systems designed and based on static IP host 276 addresses. Care should be exercised by the renumbering entity 277 to ensure that all security systems deployed with the network(s) 278 which may need to be renumbered be given special consideration 279 and significant forethought to provide continued functionality 280 and adequate security. 282 7. Acknowledgments 284 Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.], 285 Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for 286 their contributions and editorial critique. 288 8. References 290 [1] RFC-1814, ``Unique Addresses are Good''; E. Gerich; IAB; June 1995 292 [2] RFC-1775, ``To Be `On' the Internet''; D. Crocker, March 1995 294 [3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES'', 295 K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg; 296 draft-hubbard-registry-guidelines-01.txt 298 [4] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang, 299 P. Francis; May 1994 301 [5] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter, 302 R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 304 [6] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address 305 Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu, 306 K. Varadhan; October 1993 308 [7] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification''; 309 S. Deering, R. Hinden; December 1995 311 [8] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG; 312 December 1995 314 [9] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter; 315 IAB; February 1996 317 9. Author's Address 319 Paul Ferguson 320 cisco Systems, Inc. 321 1875 Campus Commons Road 322 Suite 210 323 Reston, VA 22091 325 Phone: (703) 716-9538 326 Fax: (703) 716-9599 327 EMail: pferguso@cisco.com