idnits 2.17.1 draft-chown-v6ops-renumber-thinkabout-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2052. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2042. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 18, 2006) is 6430 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) ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-renumbering-procedure (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1916 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2071 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2072 (ref. '4') ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '10') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '13') (Obsoleted by RFC 4941) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '15') (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-15 -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '17') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '18') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-ipv6-ula-central-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '30') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '31') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3627 (ref. '33') (Obsoleted by RFC 6547) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-nap-03 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Chown 3 Internet-Draft M. Thompson 4 Expires: March 22, 2007 A. Ford 5 S. Venaas 6 University of Southampton, UK 7 September 18, 2006 9 Things to think about when Renumbering an IPv6 network 10 draft-chown-v6ops-renumber-thinkabout-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 22, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This memo presents a summary of scenarios, issues for consideration 44 and protocol features for IPv6 network renumbering, i.e. achieving 45 the transition from the use of an existing network prefix to a new 46 prefix in an IPv6 network. Its focus lies not in the procedure for 47 renumbering, but as a set of "things to think about" when undertaking 48 such a renumbering exercise. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Structure of Document . . . . . . . . . . . . . . . . . . 4 54 1.2. Past IPv4 Renumbering studies in the PIER WG . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Renumbering Event Triggers . . . . . . . . . . . . . . . . . . 5 57 3.1. Change of uplink prefix . . . . . . . . . . . . . . . . . 6 58 3.1.1. Migration to new provider . . . . . . . . . . . . . . 6 59 3.1.2. Dial on Demand . . . . . . . . . . . . . . . . . . . . 6 60 3.1.3. Provider migration and upstream renumbering . . . . . 7 61 3.1.4. IPv6 transition . . . . . . . . . . . . . . . . . . . 7 62 3.2. Change of internal topology . . . . . . . . . . . . . . . 8 63 3.3. Acquisition or merger . . . . . . . . . . . . . . . . . . 8 64 3.4. Network growth . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Network mobility . . . . . . . . . . . . . . . . . . . . . 8 66 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 9 67 4.1. Minimal disruption . . . . . . . . . . . . . . . . . . . . 9 68 4.2. Session survivability . . . . . . . . . . . . . . . . . . 9 69 4.2.1. Short-term session survivability . . . . . . . . . . . 10 70 4.2.2. Medium-term session survivability . . . . . . . . . . 10 71 4.2.3. Long-term session survivability . . . . . . . . . . . 10 72 4.2.4. "Sessions" in non-session based transports . . . . . . 11 73 5. IPv6 Protocol Features and their Effects on Renumbering . . . 11 74 5.1. Multi-addressing . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. Multi-homing techniques . . . . . . . . . . . . . . . . . 12 76 5.2.1. Relevance of multi-homing to renumbering . . . . . . . 12 77 5.2.2. Current situation with IPv6 multi-homing . . . . . . . 13 78 5.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.3.1. Visited site renumbers when mobile . . . . . . . . . . 14 80 5.3.2. Home site renumbers when mobile . . . . . . . . . . . 14 81 5.3.3. Home site renumbers when disconnected . . . . . . . . 14 82 5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.5. Unique Local Addressing . . . . . . . . . . . . . . . . . 16 84 5.5.1. ULAs, Multicast and Address Selection . . . . . . . . 17 85 5.5.2. ULAs with application-layer gateways . . . . . . . . . 18 86 5.6. Anycast addressing . . . . . . . . . . . . . . . . . . . . 18 87 6. Node Configuration Issues . . . . . . . . . . . . . . . . . . 19 88 6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 19 89 6.1.1. Router Advertisement Lifetimes . . . . . . . . . . . . 20 90 6.1.2. Stateless Configuration with DHCPv6 . . . . . . . . . 20 91 6.1.3. Tokenised Interface Identifiers . . . . . . . . . . . 20 92 6.2. Stateful Configuration with DHCPv6 . . . . . . . . . . . . 21 93 6.2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . 22 94 6.2.2. Source Address Selection Policy distribution . . . . . 22 95 6.3. Router Renumbering . . . . . . . . . . . . . . . . . . . . 22 96 7. Administrative Considerations for Renumbering . . . . . . . . 23 97 7.1. Router Advertisement Lifetimes . . . . . . . . . . . . . . 23 98 7.2. Border filtering . . . . . . . . . . . . . . . . . . . . . 24 99 7.3. Frequency of renumbering episodes . . . . . . . . . . . . 24 100 7.4. Delay-related Considerations . . . . . . . . . . . . . . . 25 101 7.4.1. With or without a flag day . . . . . . . . . . . . . . 25 102 7.4.2. Freshness of service data . . . . . . . . . . . . . . 25 103 7.4.3. Availability of old prefix . . . . . . . . . . . . . . 26 104 7.4.4. Duration of overlap . . . . . . . . . . . . . . . . . 27 105 7.5. Scalability issues . . . . . . . . . . . . . . . . . . . . 27 106 7.5.1. Packet filters, Firewalls and ACLs . . . . . . . . . . 28 107 7.5.2. Monitoring tools . . . . . . . . . . . . . . . . . . . 30 108 7.6. Considerations with a Dual-Stack Network . . . . . . . . . 30 109 7.7. Equipment administrative ownership . . . . . . . . . . . . 31 110 8. Impact of Topology Design on Renumbering . . . . . . . . . . . 31 111 8.1. Merging networks . . . . . . . . . . . . . . . . . . . . . 31 112 8.2. Fixed length subnets . . . . . . . . . . . . . . . . . . . 32 113 8.3. Use 112-bit prefixes for point-to-point links . . . . . . 32 114 8.4. Plan for growth where possible . . . . . . . . . . . . . . 33 115 8.5. IPv6 NAT Avoidance . . . . . . . . . . . . . . . . . . . . 33 116 9. Application and service-oriented Issues . . . . . . . . . . . 34 117 9.1. Shims and sockets . . . . . . . . . . . . . . . . . . . . 34 118 9.2. Explicitly named IP addresses . . . . . . . . . . . . . . 35 119 9.3. API dilemma . . . . . . . . . . . . . . . . . . . . . . . 36 120 9.4. Server Sockets . . . . . . . . . . . . . . . . . . . . . . 37 121 9.5. Sockets surviving invalidity . . . . . . . . . . . . . . . 37 122 9.6. DNS Authority . . . . . . . . . . . . . . . . . . . . . . 38 123 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 124 10.1. IETF Call to Arms . . . . . . . . . . . . . . . . . . . . 38 125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 127 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 129 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 130 14.2. Informative References . . . . . . . . . . . . . . . . . . 40 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 132 Intellectual Property and Copyright Statements . . . . . . . . . . 44 134 1. Introduction 136 This memo presents a summary of scenarios, issues for consideration 137 and protocol features for IPv6 network renumbering, i.e. achieving 138 the transition from the use of an existing network prefix to a new 139 prefix in an IPv6 network. This document does not relate the 140 procedures for IPv6 renumbering; for such a procedure the reader is 141 referred to [1]. The authors plan to use this document, together 142 with ongoing operational experience, to refine [1] where necessary, 143 to promote that guide from Informational to BCP. The focus is on 144 renumbering site networks, though many of the principles apply to 145 renumbering other (ISP) networks. 147 1.1. Structure of Document 149 This document is split into a number of sections that discuss various 150 aspects of network renumbering that should be considered when 151 undertaking such an event. This document begins with a discussion of 152 the various reasons behind renumbering events, and the requirements 153 to ensure the event goes smoothly. The following sections then 154 discuss a selection of factors that can both help and hinder the 155 renumbering procedure, and as such should be taken into account when 156 planning the event. Finally, this document summarises issues with 157 applications and services, and attempts to identify places where IP 158 addresses may be hard-coded and thus require reconfiguration during a 159 renumbering event. 161 1.2. Past IPv4 Renumbering studies in the PIER WG 163 A number of years ago (1996-1997), the Procedures for Internet/ 164 Enterprise Renumbering (PIER) WG spent time considering the issues 165 for IPv4 renumbering. The WG produced three RFC documents. In 166 RFC1916 [2], a "call to arms" for input on renumbering techniques was 167 made. RFC2071 [3] documents why IPv4 renumbering is required. 168 Interestingly, many, but not all, of the drivers have changed with 169 respect to IPv6. In RFC2072 [4], a Router Renumbering Guide, some 170 operational procedures are given, much as they are in Baker [1] for 171 IPv6. 173 Reflection on RFC2071 is interesting, witness the quote: "It is also 174 envisioned that Network Address Translation (NAT) devices will be 175 developed to assist in the IPv4 to IPv6 transition, or perhaps 176 supplant the need to renumber the majority of interior networks 177 altogether, but that is beyond the scope of this document." That 178 need however is still very strong, particularly given the lack of 179 Provider Independent (PI) address space in IPv6 (in IPv4, PI address 180 space exists mainly for historical, pre-CIDR reasons). 182 RFC2072 is more interesting in the context of this document. Some is 183 certainly relevant, though much is not, due to the inherent changes 184 in IPv6. For example, there is no CIDR and address aggregation is 185 given as mandate. Also, IPv6 subnets are in effect fixed length 186 (/64), so local administrators do not need to resize subnets to 187 maximise efficient use of address space as they do in IPv4. 189 One core message from RFC2072 that holds true today is that of 190 section 4 where the observation is made that renumbering networks 191 whilst remaining the same hierarchy of subnets (i.e. the cardinality 192 of the set of prefixes to renumber remains constant) is the 'easiest' 193 scenario to renumber; when each "old" prefix can be mapped to a 194 single "new" prefix. 196 A distinction of this work is that, where the PIER working group 197 consider the transition from IPv4 to IPv6 addressing as a renumbering 198 scenario, we strictly consider only the renumbering from IPv6 199 prefixes to other IPv6 prefixes and leave transition to well 200 documented techniques such as those from the PIER working group. 202 2. Terminology 204 The following terminology is used in this document (to be expanded in 205 future revisions): 207 o Site: An organisationally distinct network, ranging from SOHO 208 through to enterprise. 210 o Flag day: A planned service outage. 212 o Node: A device on the network that is being renumbered, or that is 213 involved in communication with the network being renumbered. 215 3. Renumbering Event Triggers 217 This section details typical actions that result in the need for a 218 renumbering event, and thus define the scenarios for renumbering. 220 In many instances, in particular those where no "flag day" is 221 involved, the process of renumbering will inevitably lead to a 222 scenario where hosts are multi-addressed or multi-homed as one phase 223 of the renumbering procedure. The relationship between renumbering 224 and multi-homing is discussed later in this document. 226 In other instances, e.g. a change in the IPv4 address offered by a 227 provider to a site using 6to4 [9], the change offers no overlap in 228 external connectivity or addressing, and thus there is no multi- 229 homing overlap. 231 Triggers may be provider-initiated or customer-initiated. 233 Triggers and scenarios for IPv4 renumbering are discussed in RFC2071, 234 but many of these are no longer relevant, and in IPv6 some new 235 triggers exist, e.g. those related to network mobility or IPv6 236 transition tools. 238 3.1. Change of uplink prefix 240 One of the most common causes for renumbering will be a change in the 241 site's upstream provider. As per RFC3177 [10], the typical 242 allocation for an IPv6 site is a /48 size prefix taken from the 243 globally aggregated address space of the site's provider. With IPv6, 244 sites are highly unlikely to be able to obtain provider independent 245 (PI) address space, as have in some cases been obtained in the past 246 with IPv4. Rather, sites use provider assigned (PA) addressing. As 247 a result, if a site changes provider, it must also change its IPv6 PA 248 prefix. 250 3.1.1. Migration to new provider 252 In the simplest case, the customer is triggering the renumbering by 253 choosing to change the site's upstream provider to a new ISP and thus 254 a new PA IPv6 prefix range. This may simply be in the form of 255 selecting a new commercial provider, although there are several other 256 possible scenarios, such as changing from a dial-up to a broadband 257 connection, or moving from a community wireless connection to a fixed 258 broadband connection. 260 A similar scenario exists when a customer migrates to a different 261 service from the same provider. For example, if a customer changes 262 from a dialup to a broadband connection, they will likely be 263 connecting to a different part of the provider's topology, and 264 therefore receive a different address allocation. 266 3.1.2. Dial on Demand 268 A site may connect intermittently to its upstream provider. In such 269 cases the prefix allocated by the provider may change with each 270 connection, as it often does in the case of single IPv4 address 271 allocations to SOHO customers today. Thus the site may receive a 272 prefix still in its provider PA range, but the prefix may vary with 273 each connection, causing a renumbering event. 275 Dynamically assigned IP addresses are common today with dial-up and 276 ISDN Internet connections, and to a lesser extent some broadband 277 products, particularly cable modems. Usually with dynamically 278 assigned IP addresses on broadband products, the address is only 279 likely to change when the customer reconnects, which could be very 280 infrequently. 282 This case can be mitigated by encouraging ISPs to offer static IPv6 283 prefixes to customers. Where /48 prefixes are provided, a large ISP 284 may be forced to require significantly more than the "default" /32 285 allocation from an RIR to an ISP to be able to service its present 286 and future customer base. With always-on more common in new 287 deployments, provider re-allocation should be less common; however 288 the practice of reallocating IPv4 addresses in SOHO broadband 289 networks is not uncommon in current broadband ISPs. 291 3.1.3. Provider migration and upstream renumbering 293 A site's upstream provider may need to renumber, due for example to a 294 change in its network topology or the need to migrate to a different 295 or additional prefix from its Regional Internet Registry (RIR). This 296 will in turn trigger the renumbering of the end site. 298 Such renumbering events would be expected to be rare, but it should 299 be noted that RIR-assigned IPv6 address space is not owned by an ISP. 301 3.1.4. IPv6 transition 303 During transition to IPv6, there are several scenarios where a site 304 may have to renumber. For example, if the site uses 6to4 for access 305 and its IPv4 address is dynamically assigned, an IPv6 renumbering 306 event will be triggered when the site's IPv4 address changes. 308 Another likely renumbering event would be the change of transition 309 mechanism, such as from 6to4 to a static IPv6-in-IPv4 tunnel, or from 310 any one of those mechanisms to a native IPv6 link. When changing 311 from 6to4 (2002::/16) addresses to native global aggregatable unicast 312 addresses, renumbering would be unavoidable. When migrating from a 313 tunnelled to a native connection, renumbering may not be necessary if 314 the same prefix can be routed natively, however this would be 315 provider-dependent. 317 In addition, there are likely to be many cases of network renumbering 318 occurring when the old 6bone prefix (3FFE::/16) is phased out as per 319 RFC3701 [11], and networks still using it will have to renumber. 321 Finally, there is at least one transition mechanism, ISATAP [12], 322 that uses specially crafted host EUI-64 format addresses. Should a 323 site migrate from ISATAP to use either conventional EUI-64 addressing 324 (via stateless address autoconfiguration or perhaps DHCPv6), then 325 renumbering would be required at least in the host part of addresses. 327 It is also worth noting that nodes that use IPv6 Privacy Extensions 328 [13] will in effect renumber the host part of their address on a 329 frequent basis, in the case of one popular implementation on a daily 330 basis if the node remains on-link on the same network. 332 3.2. Change of internal topology 334 A site may need to renumber all or part of its internal network due 335 to a change of topology, such as creating more or less specific 336 subnets, or acquiring a larger IPv6 address allocation. Motivations 337 for splitting a link into separate subnets may be to meet security 338 demands on a particular link (policy for link-based access control 339 rules), or for link load management by shuffling popular services to 340 more appropriate locations in the local topology. Link-merging may 341 be due to department restructuring within the hosting organisation, 342 for example. 344 3.3. Acquisition or merger 346 Two networks may need to merge to one due to the acquisition or 347 merger of two organisations or companies. Such a reorganisation may 348 require one or more parts of the new network to renumber to the 349 primary PA IPv6 prefix. 351 3.4. Network growth 353 A site that is allocated a /48 prefix may grow to a size where it 354 needs to use a larger prefix for internal networking. Sites in the 355 early stages of IPv6 deployment may only request a /48, even if they 356 are likely to outgrow such a prefix in time. In such a case site- 357 wide renumbering may be required to utilise the new prefix if 358 organisational restructuring also happens due to the growth. 360 3.5. Network mobility 362 This covers various cases of network mobility, where a static or 363 nomadic network may obtain different uplink connectivity over time, 364 and thus be assigned different IPv6 PA prefixes as the topology 365 changes. One example is the "traditional" NEMO network [14], another 366 may be a community wireless network where different sets of nodes 367 gain uplink connectivity - typically to the same provider - at 368 different times. 370 4. Renumbering Requirements 372 In this section we enumerate potential specific goals or requirements 373 for sites or users undergoing an IPv6 renumbering event. 375 4.1. Minimal disruption 377 The renumbering event should cause minimal disruption to the routine 378 operation of the network being renumbered, and the users of that 379 network. 381 Disruption is a difficult term to quantify in a generic way, but it 382 can be expressed by factors such as: 384 o Application sessions being terminated 386 o Security controls (e.g. ACLs) blocking access to legitimate 387 resources 389 o Unreachability of nodes or networks 391 o Name resolution, directory and configuration services providing 392 invalid (out-of-date) address data 394 o Limitation of network management visibility 396 These disruptive elements will be covered in situ as we discuss 397 protocol features and other renumbering considerations later in this 398 memo. 400 4.2. Session survivability 402 The concept of session survivability is catered for by [1] in that 403 new sessions adopt either old or new prefix based on the state of the 404 renumbering process, as discussed in Section 5.1. However, other 405 approaches to renumbering networks may be appropriate in certain 406 deployments, such as where "flag days" are unavoidable, such as where 407 two live prefixes are being "swapped". In these cases, further 408 consideration for existing sessions (their longevity, frequency, 409 independence across interactions, etc.) is required. 411 Some protocols are specifically geared to aid session survivability, 412 e.g. the Stream Control Transmission Protocol (SCTP) [15], and may 413 prove valuable in mission-critical renumbering scenarios, in 414 particular the extension that enables the dynamic addition and 415 removal of IP addresses from an SCTP endpoint association [16]. 417 Sessions may be administratively maintained, such as NFS mounts for 418 user filestore, or they may be user-driven, e.g. long-running ssh 419 sessions. 421 In general, it is important to consider how TCP and the applications 422 above it handle the connection failures that may result from a change 423 in address. 425 There are different classes of session duration, as described in the 426 following sections. 428 4.2.1. Short-term session survivability 430 A typical short-term session would involve a request-response 431 protocol, such as HTTP, where a new network connection is initiated 432 per transaction, or at worst for a small transaction set. In such 433 cases the migration to a new network prefix is transparent: the 434 client can use the new prefix in new transactions without 435 consequence. Some applications, however, may be skewed by such a 436 shift in connection source for the same entity 'user', for example 437 applications that use recent connection history as a cue to identity 438 (e.g. POP-before-SMTP as used by many dial-on-demand ISP customers 439 ), or for applications that care 440 about connection statistics (the same user web-browsing "session" may 441 be split into two where a renumbering event occurs in-between client 442 transactions). 444 4.2.2. Medium-term session survivability 446 A medium-term session is typified by an application or service that 447 may persist for perhaps a period of a few minutes up to a period of a 448 day or so. This might involve a TCP-based application that is left 449 running during a working day, such as an interactive shell (SSH) or a 450 large file download. 452 4.2.3. Long-term session survivability 454 Long term sessions may typically run for several days, if not weeks 455 or months. These might typically include TCP-based NFS mounts, or 456 long-running TCP applications. Sessions in this context may also 457 include those applications that, once started, do not re-resolve 458 names and so repeatedly open new connections or send new datagrams to 459 the same (as bound at time of initialisation) address throughout 460 their execution lifetime. Even if at API-level applications do 461 attempt to re-resolve the symbol to which they desire to connect, the 462 behaviour of the resolvers is unclear as to whether mappings are 463 refreshed from the naming service, and as such even if the 464 renumbering site does update its DNS (or NIS, LDAP database etc.), 465 the local result may indeed be cached without any indication passed 466 back up to the application as to how 'old' said binding information 467 is. 469 4.2.4. "Sessions" in non-session based transports 471 UDP transport protocols, such as UDP-based NFS mounts, maintain the 472 status of a 'session' by keeping state at one or both ends of the 473 communication, but without a persistent open socket connection at the 474 network layer. If, due to node renumbering, one endpoint changes 475 address then that state becomes invalid and the 'session' 476 interrupted. 478 Note that some stack implementations do not correctly flag an error 479 to applications that attempt to send packets with an invalidated 480 source address, see section Section 9.5 482 IP addresses are also seen carried in higher-layer protocols, e.g. 483 application sessions, such as with FTP. Any application that makes 484 use of layer-3 address data as a unique end-point identifying token 485 may be disrupted by the address of the node changing to which that 486 token relates. This may not be an issue in cases where the token is 487 treated as abstract (i.e. literally just a token), however where 488 locator semantics are inferred, subsequent attempts to 'resolve' the 489 token to an address endpoint for communication, for example, will 490 fail. 492 5. IPv6 Protocol Features and their Effects on Renumbering 494 IPv6 includes a number of notable features that can help or hinder - 495 and sometimes both - renumbering episodes. This section discusses 496 these features and their associated effects for consideration when 497 undertaking network renumbering, both in terms of how they can be 498 used to ease the process, as well as potential pitfalls that should 499 be considered. 501 5.1. Multi-addressing 503 As per RFC3513 [17], IPv6 hosts may be multi-addressed. This means 504 that multiple unicast addresses can be assigned and active on the 505 same interface. These addresses can have different reachabilities 506 ('scopes' such as link-local or global), different statuses including 507 'preferred' and 'deprecated', and may be ephemeral in nature (such as 508 care-of addresses when attached to a foreign network [18] or IPv6 509 Privacy addresses [13]). RFC3484 address selection semantics [5] 510 determine which of the "MxN" address pairs to use for communication 511 in the general case. 513 During a renumbering episode, the addition of an extra address for an 514 endpoint increases the number of possible source-destination address 515 pairs for communications between nodes to use. The address selection 516 mechanisms specified by RFC3484 are currently at varying stages of 517 implementation in operating systems. 519 RFC3484 also specifies policy hooks to allow administrative override 520 of the default address selection behaviour, for example to 521 specifically prefer a source prefix for use with a set of particular 522 destinations. It is thought that this policy-based address selection 523 may be of benefit in renumbering events, or used in the development 524 of bespoke renumbering tools. 526 Multi-addressing also creates various issues with border filtering, 527 discussed in detail in Section 7.2. 529 5.2. Multi-homing techniques 531 A multi-homed site is a site which has multiple upstream providers. 532 A site may be multi-homed for various reasons, however the most 533 common are to provide redundancy in case of failure, to increase 534 bandwidth, and to provide more varied, optimal routes for certain 535 destinations. 537 In renumbering, multi-homing will either be a temporary state, during 538 the transition, or be a permanent feature of the network 539 configuration, which may be being altered during the renumbering. 541 5.2.1. Relevance of multi-homing to renumbering 543 As discussed in section 2, and in particular section 2.5, of [1], 544 during the 'without a flag day' renumbering procedure there will be a 545 period where both the old and the new prefixes are stable and valid 546 for the network. During such a period, the network may be multi- 547 homed, and as such many of the issues relating to multi-homing in 548 IPv6 are also relevant, albeit in a small capacity, to the 549 renumbering procedure. A stable multi-homed situation must therefore 550 be a requirement for renumbering without a 'flag day'. 552 In such a situation, however, the multi-homed state will not be 553 permanent, and will only exist for the duration for which it is 554 required, i.e. for the period during the renumbering procedure when 555 both prefixes should be valid. 557 Renumbering can also occur, however, in a network that is already 558 multi-homed, for example with redundant links to multiple providers. 559 Such a site may wish to renumber for any of the situations given in 560 the earlier section, as well as renumbering because of changes in the 561 number of upstream providers. If at least one of the upstream links 562 remains unchanged during the renumbering, however, then these links 563 could be used exclusively for that period, alleviating some of the 564 issues with prefix changes. The stable link(s) could therefore be 565 the only prefixes advertised as valid for the 'stable state', with 566 the removal of the old prefix and introduction of the new prefix 567 being separate events. 569 Until the best practice for the multi-homing situation is defined, 570 however, its effect on renumbering is not a focus of this document. 572 5.2.2. Current situation with IPv6 multi-homing 574 Unlike IPv4 multi-homing, where PI address space is relatively easy 575 to obtain and thus a site can broadcast its own routing information, 576 most IPv6 addresses will be PA addresses and thus the site will have 577 no control over routing information. Multi-homing in IPv6 therefore 578 does not necessarily exist in the same way as in IPv4 and the 579 multi6 [38] working group was chartered to try to find a solution. 581 Most IPv6 multi-homing solutions fall into the categories of either 582 being host-centric, where it is the hosts that are multi-addressed, 583 and choose which addresses to use, or site-based, where it is the 584 site exit routers that decide which connections to use. The simplest 585 solutions are extensions of the current multi-addressing techniques, 586 but these suffer from the problem that, at some point, connections 587 using the old addresses will be broken. 589 The more advanced solutions [19], and in particular the solution 590 taken forward into the shim6 [39] working group, examine the 591 potential for splitting the 'identity' and 'location' features of IP, 592 currently both represented by the IP address, and connecting to a 593 host's identity, rather than its address, so that connections can 594 continue unhindered across renumbering events. Such solutions are, 595 however, very much in their infancy and as yet do not provide a 596 stable solution to this problem. 598 Support for the level of multi-homing required during a renumbering 599 exercise is, however, mostly provided by multi-addressing 600 (Section 5.1), since all that is primarily required is stable use of 601 either prefix for a given period. The core issue remains, however, 602 that at some point the connections using the old address will be 603 broken when the addresses are removed. The impact of this can be 604 limited as best as possible during the renumbering procedure. 606 5.3. Mobile IPv6 608 Mobile IPv6 (MIPv6) [18] specifies routing support to permit an IPv6 609 host to continue using its "permanent" home address as it moves 610 around the Internet. Mobile IPv6 supports transparency above the IP 611 layer, including maintenance of active TCP connections and UDP port 612 bindings. There are a number of issues to take into account when 613 renumbering episodes occur where Mobile IPv6 is deployed: 615 Renumbering a network which has mobile IPv6 active is a potentially 616 complex issue to think about. In particular, can changed router 617 advertisements correctly reach the mobile nodes, and can they be 618 correctly renumbered, like a node on the local network? In addition, 619 an even more complex issue is what happens when the home agent 620 renumbers? Is it possible for the mobile nodes to be informed and 621 correctly renumber and continue, or will the link be irretrievably 622 broken? 624 5.3.1. Visited site renumbers when mobile 626 When a node is mobile and attached to a foreign network it, like any 627 other node on the link, is subject to prefix renumbering at that 628 site. Detecting a new prefix through the receipt of router 629 advertisements, the mobile node can then re-bind with its home agent 630 informing it of its care-of address - just as if it had detached from 631 the foreign network and migrated elsewhere. Where the node receives 632 forewarning of the renumbering episode, the Mobility specification 633 suggests that the node explicitly solicits an update of the prefix 634 information on its home network 636 5.3.2. Home site renumbers when mobile 638 When mobile, a host can still be contacted at its original (home) 639 address. Should the home network renumber whilst the node is away 640 but active (i.e. having bound to the home agent and registered a live 641 care-of address), then it can be informed of the new global routing 642 prefix used at the home site through the Mobile Prefix Solicitation 643 and Mobile Prefix Advertisement ICMPv6 messages (sections 6.7 and 6.8 644 of RFC3775 [18] respectively). 646 5.3.3. Home site renumbers when disconnected 648 Finally, if a mobile node is detached (i.e. no binding with the home 649 agent exists with the node present on a foreign network) and the home 650 network renumbers, the recommended procedure - documented as an 651 appendix to the mobility specification and therefore not necessarily 652 proven - is to fall back to alternative methods of 'rediscovering' 653 its home network, using the DNS to find the new global routing prefix 654 for the home network and therefore the Home Agent's subnet anycast 655 address, 'guessing' at what the node's new home address would be on 656 the basis of a 64 bit prefix and 64 bit interface identifier, and 657 then attempting to perform registration to bind its new location. 659 5.4. Multicast 661 IPv6 supports an enriched model of multicast compared to IPv4 in that 662 there are well-defined scopes for multicast communication that are 663 readily expressed in the protocol's addressing architecture. 664 Multicast features much more prominently in the core specification, 665 for example it is the enabling technology for the Neighbour Discovery 666 protocol (a much more efficient approach to layer 2 address discovery 667 than compared to ARP with IPv4). 669 Where multicast is used to discover the availability of core services 670 (e.g. all DHCPv6 servers in a site will join FF05::1:3), the effect 671 of renumbering the unicast address of those services will mean that 672 the services are still readily discoverable without resorting to a 673 (bespoke or otherwise) service location protocol to continue to 674 function - particularly if (unicast) ULAs are not deployed locally as 675 per Section 5.5. 677 One issue related to IPv6 multicast and renumbering is the embedding 678 of unicast addresses into multicast addresses specified in RFC3306 679 [20] and the embedded-RP (Rendezvous Point) in RFC3956 [21]. 681 The former is purely a way of assigning addresses that helps with 682 multicast address assignment, avoiding different sites from using the 683 same multicast addresses. If a site's unicast prefix changes, then 684 one will also need to change the multicast addresses. By way of 685 example, a site renumbering away from prefix 2001:DB8:BEEF::/48" 686 might have globally-scoped multicast addresses in use under the 687 prefix "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old 688 addresses for a while, but this should be avoided since another site 689 may inherit the prefix and they may end up using the same multicast 690 addresses. 692 The issue with embedded-RP is that, by definition, the RP address is 693 embedded. So if the RP address changes, then the group addresses 694 must also be changed. This may happen not only when a site is 695 renumbered, but also if a site is restructured or the RP is moved 696 within the site. The embedded address is used by routers to 697 determine the RP address. Applications must use new group addresses 698 once the RP is not available on the old address. 700 Another interesting topic is multicast source renumbering. With 701 traditional multicast a source should be able to start streaming from 702 a new address, and nodes belonging to the multicast group will 703 immediately start receiving. There might be some application issues 704 though. If sources are identified by the source address only, then 705 this might appear as a new source to the receivers (as they would 706 where IPv6 Privacy addresses are used). Using RTP a receiver may 707 determine it's the same source. 709 With Source Specific Multicast (SSM), source renumbering is more 710 complicated since receivers must specify exactly which sources they 711 want to to receive from. This means that receivers must somehow be 712 told to join the new source addresses, and must be able to discover 713 those addresses. 715 5.5. Unique Local Addressing 717 Section 5 of [22] suggests that the use of Local IPv6 addresses in a 718 site results in making communication using these addresses 719 independent of renumbering a site's provider based global addresses. 720 It also points out that a renumbering episode is not triggered when 721 merging multiple sites that have deployed centrally assigned unique 722 local addresses[23] because the FC00::/7 ULA prefix assures global 723 uniqueness. The use of ULAs internally should ideally mitigate 724 against global address renumbering of nodes, particularly as intra- 725 site communication can continue unhindered by the change in global 726 address prefixes due to provider migration or re-assignment of prefix 727 from an upstream. 729 ULAs appear to lend themselves particularly well for long-lived 730 sessions (from the categorisation Section 4.2.3) whose nature is 731 intra-site, for example local filestore mounts over TCP-mounted NFS: 732 With clients using ULA source addresses to mount filestore using the 733 ULA of an NFS server, both client and server can have their global 734 routing prefix renumbered without consequence to ongoing local 735 connections. 737 When merging two sites that have both deployed FC00::/7 locally- 738 assigned ULA prefixes, the chance of collision is inherently small 739 given the pseudo-random global-ID determination algorithm of [22]. 740 Consideration of possible collisions may be prudent however unlikely 741 the occurrence may be. 743 With reference to section 2 of [1], the adoption of ULA to assist in 744 network renumbering can be considered a 'seasoning' of Baker's 745 renumbering procedure: where interaction between local nodes and 746 their services cannot suffer the inherent issues observed when 747 migrating to a new aggregatable global unicast prefix, the use of 748 FC00::/7 unique local addresses may offer an appropriately stable and 749 reliable solution. Whilst on the surface, the use of ULAs in 750 networks that also have global connectivity appears straightforward 751 and of immediate benefit as regards provider migration, they 752 currently suffer significant operational issues including address 753 selection, border filtering, name service provision and routing. 755 If addresses under a global routing prefix are deployed alongside 756 ULAs, then nodes will need to cater for being multi-addressed with 757 multiple addresses of the same (global) syntactic scope, e.g. follow 758 the principles laid out in RFC3484 [5]. The administrator should 759 ideally be able to set local policy such that nodes use ULAs for 760 intranet communications and global addresses for global Internet 761 communications. Note in particular that address selection policy 762 different from the defaults of RFC3484 are required for sites that 763 have deployed ULAs whilst making use of multicast in scopes greater 764 than link-scope (i.e. FFx3 and higher). 766 5.5.1. ULAs, Multicast and Address Selection 768 For ordinary unicast traffic, the address selection rules of RFC3484 769 will function correctly. Assuming no higher-precedence rules are 770 matched, a multi-addressed host will choose its source address 771 through finding the address with the longest matching prefix compared 772 with the destination address. This will pick global unicast 773 addresses (i.e. within 2000::/3) for communication with other such 774 addresses, and pick ULAs for other ULAs. This correct behaviour is 775 dependent on sites running two-face DNS, however, and therefore 776 ensuring remote sites do not know of non-routable ULAs. 778 The key problem with ULAs and source address selection occurs, 779 however, when sending to multicast addresses. When it falls to the 780 longest matching prefix tests, a ULA will always come out as 781 preferable to a global unicast address for matching a multicast 782 (FF00::/8) address. 784 This does not affect link-local multicast, however, as the preference 785 for the appropriate scope will choose the unicast link-local address 786 before looking at the longest prefix match (see Section 3.1 of 787 RFC3484). For scopes wider than link-local, however, the ULA will by 788 default always be chosen. 790 Local policy needs to be implemented such that, e.g., global-scope 791 multicast addresses have the same `label' as global aggregatable 792 unicast addresses in RFC3484 parlance. Additional rules could also 793 be added such that site- and organisational-scope multicast addresses 794 prefer ULAs as source addresses, again by defining an appropriate 795 label. 797 Whilst no standard policy distribution mechanism exists for 798 overriding default RFC3484 preference rules, [24] proposes the use of 799 a DHCPv6 option in sites where stateful configuration is available. 801 5.5.2. ULAs with application-layer gateways 803 The use of ULAs may not necessarily be accompanied by provider- 804 assigned (PA) addresses in connected networks. If addresses under a 805 PA global routing prefix are not used, application layer gateway 806 deployment will be required for ULA-only nodes internal to the 807 network to communicate with external nodes that are not part of the 808 same ULA topology. 810 Destination nodes that are addressed under FC00::/7 which are not 811 part of the same administrative domain from which the ULA allocation 812 of the local node is made, nor part of a predetermined routing 813 agreement between two organisations utilising different ULAs for 814 nodes within their own sites, would be filtered at the site border as 815 usual. 817 Typical deployments utilising this technique would include those 818 networks where an administrative policy decision has been made to 819 restrict those services available to the users, or where connectivity 820 is sufficeintly intermittent that as few nodes as possible are 821 exposed to the issues of ephemeral connectivity. 823 5.6. Anycast addressing 825 Syntactically indistinguishable from unicast addresses, 'anycast' 826 offers nodes a mean to route traffic toward the topologically nearest 827 instance of a service (as represented by an IP address), relying on 828 the routing infrastructure to deliver appropriately. RFC2526 [25] 829 defines a set of reserved subnet anycast addresses within the highest 830 128 values of the 64 bit IID space. Of that space, currently only 831 three are used, of which one is actively used and is for discovery of 832 Mobile IPv6 Home-Agents. At the current time there are no 'global' 833 well-known anycast addresses assigned by IANA. 835 In order to participate using anycast, nodes need to be configured as 836 routers (to comply with RFC3513 [17]) and exchange routing 837 information about the reachability of the specific anycast address. 838 This extra level of administration requirement is negligible in the 839 context of services as the services themselves would need 840 configuration anyway. 842 There have been proposals to define globally well-known anycast 843 addresses for core services, such as the DNS [26]. Anycast scales 844 with regard subnet-anycast in the sense that the global routing 845 prefix used to direct packets to an anycast node within a site is no 846 different from any other host, and therefore nothing 'special' in the 847 global routing architecture is required - only locally within the 848 site does the multi-node nature of anycast need to be considered. 850 However, for global well-known anycast addresses to be defined, host- 851 specific routes will need to be advertised and distributed throughout 852 the entire Internet. As acknowledged by section 2.6 of [17], this 853 presents a severe scaling limit and it is expected that support for 854 global anycast sets may be unavailable or very restricted. A good 855 discussion of best current practice for service provision using 856 anycast addressing can be found in [27]. 858 The use of well-known anycast addresses would assist the renumbering 859 exercise by removing the requirement to change the addresses in the 860 configuration of such services. The use of anycast DNS would 861 alleviate concerns with ensuring node reconfiguration, for example 862 when using Stateless DHCPv6 (Section 6.1.2). While anycasting 863 datagram-based services such as DNS pose little problems, anycast 864 does not maintain state, and so it would not be guaranteed that 865 sequential TCP packets were to go to the same host. As discussed in 866 [28], responses from TCP sessions begun to an anycast address should 867 be sent from the unicast address, and future communication should 868 continue with this address. While this means that communication will 869 continue with the same unicast address, that address is subject to 870 the standard address deprecation and validity. Note that anycasting 871 of this form can be an alternative to site or organisational scope 872 multicast service discovery as described in Section 5.4. 874 6. Node Configuration Issues 876 This section discusses how IPv6 node configuration protocols (both 877 stateless and stateful, including DHCPv6, as well as ICMP router 878 renumbering messages) can be used to facilitate a renumbering event, 879 plus any complications caused by these processes, to which 880 consideration should be given. 882 6.1. Stateless Address Autoconfiguration 884 Many IPv6 networks are likely to be configured using Stateless 885 Address AutoConfiguration [6] (SLAAC), and in order to work through 886 the multi-staged process as documented by Baker [1], the new prefix 887 is introduced via router advertisements, and then the old prefix is 888 deprecated, and finally removed. 890 Initially the router advertisements will contain only the prefix of 891 the old network, then for a time they will contain both the old and 892 the new, but with a shorter (zero) lifetime on the old prefix to 893 indicate that it is deprecated. Finally the router advertisements 894 will contain only the new prefix. 896 6.1.1. Router Advertisement Lifetimes 898 RFC2462 (IPv6 Stateless Autoconfiguration) [6] specifies the 899 technique for expiring assigned prefixes and then invalidating them, 900 such that a network has opportunity to gracefully withdraw a prefix 901 from service whilst not terminally disrupting on-going applications 902 that use addresses under it. Section 5.5.4 of RFC2462 in particular 903 details the procedure for deprecation and subsequent invalidation. 905 By mandating as a node requirement the ability to phase out addresses 906 assigned to an interface, network renumbering is readily facilitated: 907 subnet routers update the pre-existing prefix and mark them as 908 'deprecated' with a scheduled time for expiration and then advertise 909 (when appropriate) the new prefix that should be chosen for all 910 outgoing communications. 912 6.1.2. Stateless Configuration with DHCPv6 914 Sometimes, DHCPv6 will be used alongside SLAAC. SLAAC will provide 915 the address assignment, and DHCPv6 will provide additional host 916 configuration options, such as DNS servers. If any of the DHCPv6 917 options are directly related to the IPv6 addresses being renumbered, 918 then the configuration must be changed at the appropriate time during 919 the renumbering event, even though it itself does not handle the 920 address assignments. 922 Since the configuration is stateless, the DHCPv6 server will not know 923 which clients to contact to inform them to refresh. Clients of the 924 configuration protocol should poll the service to obtain potentially 925 updated ancillary data, such as suggested by [29]. It is proposed 926 that a new DHCPv6 service option is added to inform clients of an 927 upper bound for how long they should wait before re-requesting 928 service information. 930 6.1.3. Tokenised Interface Identifiers 932 IPv6 Stateless Address Auto-configuration (SLAAC) enables network 933 administrators to deploy devices in a network and have those devices 934 automatically generate global addresses without any administrative 935 intervention, and without the need for any stateful configuration 936 service such as DHCPv6. 938 However, certain services - such as HTTP, SMTP and IMAP - may better 939 benefit from having 'well known' identifiers that do not depend on 940 the physical hardware address of the server's network interface card, 941 e.g. ::53 for name servers. 943 Tokenised addresses offer a facility for administrators to specify 944 the bottom 64 bits of an IPv6 address for a node whilst allowing the 945 top 64 bits (the network prefix) to be automatically configured from 946 router advertisements. 948 Currently, only more recent versions of Sun Microsytems' Solaris 949 operating system features ioctl-configured support for tokenised 950 interface identifiers, although recent work at Southampton has 951 demonstrated that the configuration technique can be introduced 952 trivially through simple kernel extensions in Linux. 954 As regards renumbering, automatically configured tokenised addresses, 955 where the network prefix component is learnt through router 956 advertisements, ease the renumbering process where administrators 957 have elected to use well known interface identifiers. Rather than 958 having to manually reconfigure the nodes with the new addresses, the 959 nodes can rely on automatic configuration techniques to pick up the 960 new prefix. 962 6.2. Stateful Configuration with DHCPv6 964 As opposed to stateless autoconfiguration, IPv6 stateful or managed 965 configuration can be achieved through the deployment of DHCPv6. 966 Section 18.1.8 of [30] details how a node should respond to the 967 receipt of stateful configuration data from a DHCPv6 server where the 968 lifetime indicated has expired (is zero). Section 19.4.1 details how 969 clients should respond to being instructed by DHCPv6 servers to 970 reconfigure (potentially forceful renumbering). Section 22.6 details 971 how prefix validity time is conveyed (c.f. the equivalent data in 972 SLAAC's Router Advertisement). 974 In order to renumber such a network, the DHCPv6 server should send 975 reconfigure messages to inform the clients that the configuration has 976 changed, and the clients should re-request configuration details from 977 the DHCPv6 server. This, of course, relies on the clients correctly 978 responding to such messages. 980 Where DHCPv6 has been employed, careful consideration about the 981 configuration of the service is required such that administrators can 982 be confident that clients will re-contact the service to refresh 983 their configuration data. As alluded to in sections 22.4 and 22.5 of 984 [30], the configurable timers that offer servers the ability to 985 control when clients re-contacts the server about its configuration 986 can be set such that clients rarely (if ever) connect to validate 987 their configuration set. 989 The approach described in [29] allows the lifetime of other 990 configuration information supplied by DHCPv6 to be ramped down in 991 preparation for a planned renumbering event. 993 6.2.1. Prefix Delegation 995 Where stateless autoconfiguration enables hosts to request prefixes 996 from link-attached routers, prefix delegation enables routers to 997 request a prefix for advertising from superior routers, i.e. routers 998 closer to the top of the prefix hierarchy - typically topologically 999 closer, therefore, to the provider. Once the router has been 1000 delegated prefix(es), it can begin advertising it to the connected 1001 subnet (perhaps even multi-link) with indicators for hosts to use 1002 stateful (DHCPv6) or stateless address autoconfiguration as per 1003 RFC2461. 1005 There have been two principal approaches to prefix delegation 1006 proposed: HPD (Hierarchical Prefix Delegation for IPv6), which 1007 proposed the use of bespoke ICMPv6 messages for prefix delegation, 1008 and IPv6 Prefix Options for Dynamic Host Configuration Protocol [31], 1009 which defines a DHCPv6 option type. Of the two approaches, the 1010 DHCPv6-based approach has received wide support and is on the 1011 standards track. 1013 6.2.2. Source Address Selection Policy distribution 1015 It has been proposed that DHCPv6 could also be used to distribute 1016 source address selection policy to nodes [24]. The model proposes 1017 that consumer edge router receives policies (e.g. from multiple ISPs 1018 in the case of multi-homed networks) and re-distributes them to end 1019 nodes. The end nodes then put them into their local policy table, 1020 which leads to appropriate source address selection. Where the 1021 design goal was a distribution mechanism in light of multi-homed 1022 networks, the adoption of the technique for the multi-prefix states 1023 of [1] during renumbering appears appropriate. 1025 6.3. Router Renumbering 1027 RFC2894 [7] defines a mechanism for renumbering IPv6 routers 1028 throughout a network using a bespoke ICMP message type for 1029 manipulating the set of prefixes deployed throughout subnets. 1030 Through the use of prefix matching and a rudimentary algebra for bit- 1031 wise manipulation of prefix data bound to router interfaces, the 1032 mechanism enables administrators to affect every router within a 1033 scope from a single administration workstation. One drawback of 1034 RFC2894 is that it requires an enterprise-wide IPsec infrastructure 1035 to be deployed to secure the ICMP messages in order to be compliant. 1037 The approach utilises multicast communication to the all-routers 1038 address, FF05::2, scoped to the entire 'site' as determined by router 1039 filter policy to distribute configuration updates to all (compliant) 1040 routers. The mechanism also works with more specific addressing 1041 modalities, such as link-local multicast (FF02::2) to reach all 1042 routers on a specific link, or directed unicast to affect a specific 1043 router instance. When surveying current implementations very few 1044 IPv6 implementations bound their interfaces to the Site-wide All- 1045 Routers multicast address (FF05::2), and fewer still have 1046 implementations of RFC2894. 1048 Example use cases cited in RFC2894 are for deploying global routing 1049 prefixes across a hierarchical network where site-locals already 1050 exist (presumably updated now to Unique Local Addresses), and for 1051 renumbering from an existing prefix to another in a similar manner to 1052 that proposed by Baker (i.e. the deployment of a new prefix alongside 1053 the existing one, which is deprecated and subsequently expired and 1054 removed - using the same mechanism described). 1056 The specification was developed before the shift in recommendation 1057 away from the Top-, Next- at Site-Level Aggregation Identifier 1058 address allocation hierarchy of RFC3513, although the techniques 1059 documented for renumbering the global routing prefix and subnet ID 1060 components in the updated address allocation recommendations [17] are 1061 not affected by the architectural change. 1063 As with other prefix assignment techniques, it is the responsibility 1064 of the node to correctly deprecate and then expire the use of a 1065 previously assigned prefix as defined by the IPv6 Neighbour Discovery 1066 protocol, RFC2461 [8], section 4.6.2 describing the Prefix 1067 Information option in particular. 1069 7. Administrative Considerations for Renumbering 1071 This section is concerned with factors that affect the renumbering 1072 procedure, from a network administration viewpoint. In particular, 1073 this section discusses areas that a network administrator should 1074 consider before undertaking a renumbering event, to ensure that it 1075 proceeds smoothly. This includes considerations of event frequency, 1076 scalability, and those relating to delays in information propagation. 1078 7.1. Router Advertisement Lifetimes 1080 As discussed in Section 6.1.1, IPv6 Stateless Autoconfiguration 1081 allows the expiration of assigned prefixes. This process permits 1082 existing sessions to continue while preferring a new prefix. It 1083 should be noted, however, that there are some limitations in the 1084 specification that have an impact in renumbering. In particular, it 1085 is not possible to reduce a prefix's lifetime to below two hours if 1086 it has previously been available at a longer validity. This 1087 therefore emphasises the need to plan renumbering events in advance 1088 if at all possible, to reduce the lifetime as required, within these 1089 limitations. 1091 7.2. Border filtering 1093 Multi-addressing (Section 5.1) allows multiple globally reachable 1094 addresses to be assigned to node interfaces, but one administrative 1095 caveat that arises is that of site border filtering. Not only is it 1096 the norm for sites to filter at their border router traffic that is 1097 not destined to local subnets, but it is also increasingly common for 1098 sites to undertake egress filtering. This is often used to prevent 1099 administratively local addresses (such as the, now deprecated, site- 1100 local prefix) 'leaking' traffic, or for mis-configured hosts (e.g. 1101 visitors with manually configured stacks without Mobile IPv6) from 1102 sourcing traffic that cannot be routed back (cases of which may 1103 include deliberate IP spoofing or DDoS attempts). 1105 Providers often use ingress filtering so that the provider only 1106 accepts packets from customers that have source addresses inside the 1107 address space the provider has delegated to the customer. With 1108 multi-addressing, hosts in the site may send packets with source 1109 addresses from either provider's address space. If the providers do 1110 ingress filtering, a packet must then be forwarded out on the correct 1111 uplink, based on which source address the packet has. If the site 1112 has a common exit router for the two uplinks, that router will need 1113 to route the packets based on the source address. If the site has 1114 two different exit routers, the entire site backbone may need to 1115 route based on source addresses in order to forward the packets to 1116 the correct exit router. 1118 7.3. Frequency of renumbering episodes 1120 The many different renumbering scenarios, discussed in Section 3, can 1121 have vastly different frequencies of renumbering events. In the case 1122 of a provider offering only dynamically assigned IP addresses, it 1123 could be very frequent, for example as frequent as 'per-connection' 1124 for dial-on-demand services, or weekly for some broadband services. 1125 Such renumbering events usually only occur when a customer reconnects 1126 to such services or are explicitly cited in a subscription agreement 1127 and as such are often pre-determined. 1129 The renumbering of a site due to upstream renumbering is relevant to 1130 all connections from a small dial-up link to a large enterprise. It 1131 is of particular interest since the end user has no control over the 1132 timing or frequency of the renumbering events. It is expected, 1133 however, that such events are likely to be very infrequent. 1135 The other irregular renumbering events are those that occur due to 1136 end user migrating, either to a new provider, or to a new address 1137 allocation of their choosing. The timing of such an event is 1138 therefore often within the control of the end user (within reason), 1139 and are also likely to be one-off events, or at the very least, 1140 highly infrequent. 1142 7.4. Delay-related Considerations 1144 When considering a renumbering event, both the planning of, and 1145 responses to the event are affected by temporal factors. The amount 1146 of time available in which to undertake the operation can change the 1147 administrative actions required, and this section aims to discuss 1148 some of these issues. 1150 7.4.1. With or without a flag day 1152 A network may be renumbered with or without a flag day. In the 1153 context of this document we are focusing on without a flag day, 1154 although many of the issues will still apply when renumbering is 1155 effected with a flag day. 1157 Despite the similarities, because there is an outage of services when 1158 renumbering with a flag day, it is not necessary to ensure continuity 1159 of network connections, and almost all reconfiguration can be done 1160 during the outage, thus greatly simplifying the task of renumbering. 1162 7.4.2. Freshness of service data 1164 One of the largest issues when renumbering a network will be the 1165 effect on applications that are already running. In particular, 1166 applications that periodically contact a particular host may do an 1167 initial hostname lookup, and cache the result for use throughout the 1168 lifetime of the program. In such a situation, there is no way for 1169 the application to find out that the host in question has been 1170 renumbered, and it should stop using its already cached address. It 1171 is therefore recommended that applications should regularly request 1172 hostname lookups for the desired hosts, leaving the caching to the 1173 resolver. It is then up to the resolver to ensure that resource 1174 record TTLs are observed, and its cached response is updated as 1175 necessary. 1177 Despite this, there is still a serious issue in that there is no 1178 method of caching resolvers knowing when a renumbering event is going 1179 to take place. If a typical RR's TTL is one day, then that should be 1180 reduced not less than a day before the renumbering event, so that 1181 resolvers will more frequently check for changed records. This will 1182 work successfully for a pre-planned renumbering event, but problems 1183 of stale, cached records will exist if the renumbering event is 1184 unplanned (e.g. by receiving a new router advertisement from 1185 upstream). 1187 There are also cases where the use of a resolver is not practical, 1188 such as with packet filter rules. If a packet filter has been 1189 configured with explicit hostnames, these are translated to IP 1190 addresses for fast packet matching. The per-packet resolver function 1191 is highly undesirable from a pure performance perspective. Such a 1192 packet filter is likely to need to be reloaded for the DNS changes to 1193 be recognised. 1195 A similar problem exists when a nameserver is renumbered. If the 1196 operating system's resolver has cached the nameserver address, it 1197 will at some point find it unavailable. To mitigate this problem, it 1198 is suggested that at least one off-site nameserver is included in the 1199 configuration. In addition, well-known anycast addresses (see 1200 Section 5.6) could be used, so that the client's DNS configuration 1201 does not need to be changed at all during the renumbering event. 1203 The basic process of renumbering, involving the introduction of a new 1204 prefix and the deprecation and eventual removal of the old prefix, 1205 could be hypothetically handled by a special tool, with no manual 1206 intervention. Such a tool would have to become significantly more 1207 complex in order to handle all the cases where IP addresses are 1208 explicitly specified (a comprehensive list is given in Section 9.2). 1209 Other particularly notable cases that could be changed with a tool, 1210 were it to be developed, include DNS zone files and DHCPv6 1211 configuration. Deployment of such a tool, even if possible, would be 1212 made complex through the requirement to authenticate the updates to 1213 each instance of the deployed literals. 1215 7.4.3. Availability of old prefix 1217 The duration of the period where the old prefix remains available 1218 affects the length of time that can be allowed for the renumbering 1219 procedure, and the maximum time for which existing sessions could 1220 continue. If end users have control over the renumbering procedure 1221 (such as when changing provider), then they can continue providing 1222 the old prefix for as long as required, within reason (such as cost 1223 aspects). This heavily mitigates the issues of session 1224 survivability, and relaxes the speed at which hosts must be 1225 reconfigured. 1227 If the end users do not have such control, such as when the upstream 1228 provider forces the renumbering, the availability of the old prefix 1229 is determined entirely by the upstream provider's willingness to 1230 continue providing it, which is likely to be based on the 1231 technicalities of their own renumbering situation. The end user 1232 should therefore not rely on retaining the old prefix for a 1233 relatively long period of time. In addition, many situations, such 1234 as dial-on-demand with dynamic IP addresses, and nomadic networks, 1235 will lose their old prefix quickly, if not almost instantaneously. 1237 It would be possible to continue using the old prefix internally, 1238 even when the external connectivity for that prefix is no longer 1239 active, for example to keep access to core services such as DNS 1240 servers while the transition is taking place. This should, however, 1241 be considered bad practice in case of route leaking and application 1242 confusion, as well as preventing access to the addresses if they have 1243 been reassigned, and as such this should only be used as a last 1244 resort to ensure internal continuity of service, if the availability 1245 of the old prefix is too short to allow a full transition to take 1246 place. 1248 7.4.4. Duration of overlap 1250 A key operational decision when renumbering is enforced due to a 1251 change in connectivity provider is how long to sustain the overlap of 1252 two live prefixes. The trade-off to be made is the cost of 1253 maintaining two contracts with separate providers against the 1254 'smoothness' of the transition to the new prefix as regards local 1255 administration overheads, service migration, etc. Where larger 1256 corporations can likely suffer the increased financial costs, SMEs 1257 and SOHOs might consider as little as one month's overlap too 1258 expensive, and so Baker's State 5 (Stable use of either prefix) [1] 1259 is unattainable in such scenarios. 1261 In some cases, there may be technical reasons for the overlap to not 1262 be feasible, such as with xDSL provision where the new service is a 1263 drop-in replacement for the old and the two cannot co-exist (for 1264 example, because the provision of the service requires the whole 1265 circuit resource from exchange to customer). 1267 7.5. Scalability issues 1269 During the renumbering transition, there will be a time when two 1270 prefixes are valid for use. At this point, there will be a 1271 considerable amount of configuration that will have to be 1272 (temporarily) duplicated. In particular, routing entries on the 1273 hosts will be doubled, and there will, for a short period, be two 1274 forward DNS records for every hostname. Security is another key 1275 scalability issue. All access control lists, packet filters, etc, 1276 will need to be updated to cope with the multiple addresses that each 1277 host will have. This could have a noticeable impact on packet filter 1278 performance, especially if it lead to, for example, the doubling of 1279 several hundred firewall rules. 1281 The scalability issues created by the increase in configuration to 1282 cope with the temporary existence of multiple addresses per host adds 1283 a complexity in management, but how much so is up to the end-users 1284 themselves. A user may choose to do direct transitions of some 1285 services (such as web servers) from one IP address to another, 1286 without going through a stage where the service is available on all 1287 addresses. While that is not strictly providing a fully seamless 1288 transition, it could significantly reduce the management complexity, 1289 without a significant impact on service, especially if the DNS 1290 updates are rapid. 1292 It should also be noted that during a renumbering event, since the 1293 DNS resource record TTLs are significantly shorter, the primary DNS 1294 servers for the domains will receive significantly more queries, as 1295 resolvers should not cache the responses for so long, and will 1296 regularly check back with the master. The likelihood of this having 1297 any significant impact is, however, fairly minimal, at least in a 1298 typical small to medium site. 1300 Section 3.1 of Baker [1] is aptly titled "Find all the places", and 1301 serves as a gentle reminder to application developers that embedding 1302 addresses is bad at best. Where common UNIX tools such as "grep" 1303 allow administrators to crawl the file systems of servers for places 1304 where address information is hard-coded, the proliferation of 1305 technologies such as NetInfo and other directory- or hive-based 1306 configuration schemes makes the job of finding all the places that 1307 addresses are hard-coded intractable. 1309 Beyond the call to arms for application and services developers made 1310 by Baker et al. [1], and specific to the challenges of renumbering, 1311 the following security and policy-related services that initial 1312 research has flagged as particularly troublesome: 1314 7.5.1. Packet filters, Firewalls and ACLs 1316 Throughout the transition from the old address set to the new, all 1317 packet filters and firewalls will need to adapt to map policy to both 1318 prefixes (sets of addresses) - perhaps even selectively as the old 1319 addresses become deprecated. Whilst technologies such as Router 1320 Renumbering and Neighbour Discovery automate to a large extent the 1321 transition of router and node configurations, and dynamic DNS update 1322 for the re-mapping of resource records to reflect the new addresses 1323 [32], no such mechanism exists at present for mechanising the 1324 adaption of security policy. 1326 Particularly troublesome policies to administer include egress 1327 filtering, where packet filters discard outbound packets that have 1328 source addresses that should not exist within the site, and filtering 1329 inbound site-local addresses in cases where two organisations are 1330 renumbering as a step toward merging their networks together 1331 (although the use of site-local addressing is now deprecated). 1333 Where renumbering is due to a 'clean break' from previous 1334 connectivity provider, another consideration is for the ingress 1335 filtering performed by the provider. For instance, the new provider 1336 may refuse to receive into their routing topology those packets whose 1337 source address is under the old prefix, and likewise for the old 1338 provider and new prefix. Whilst it is not the business of the IETF 1339 to mandate business practice, it is likely that the provision of out- 1340 of-allocation prefix routing as part of a multi-homing service 1341 contract would be a chargeable service and not one that an enterprise 1342 trying to make a clean break away would likely be willing to pay just 1343 for the duration of transition to their new prefix. 1345 Beyond the immediate up-stream provider, there are other policy-based 1346 considerations to take into account when renumbering. Some 1347 rudimentary authenticated access mechanisms rely on access queries 1348 coming from a particular IP network, for example, and so those 1349 application service providers will need to update their access 1350 control lists. Likewise all the internal applications (possibly 1351 meant for 'internal' eyes only) will have to have their access 1352 controls updated to reflect the change. The use of symbolic access 1353 controls (i.e. DNS domain names) rather than embedded addresses may 1354 serve to mitigate much of the distributed administrative load here, 1355 at least if such symbols are re-resolved, especially during the mid- 1356 renumbering states where both sets of addresses are still live and 1357 valid. 1359 7.5.1.1. Policy rule replication where both prefixes valid 1361 One key caveat with policy application during a renumbering prefix 1362 concerns rules that are 'tied down' at both ends to (sets of) 1363 addresses under the prefix to be renumbered, i.e. those that detail 1364 specific nodes or subnets in both source and destination elements of 1365 the policy rule as opposed to source 'any' or destination 'any'. 1367 Examples of where this approach apply include specific holes punched 1368 through a packet filter between a DMZ and the internal network, e.g. 1369 for staged access to compute servers from off-site. 1371 A dilemma here is that the otherwise 'ideal practice' use of symbolic 1372 names to identify elements in the network may not be appropriate in 1373 policy rules. This is particularly the case where resolver libraries 1374 do not return all bound resource data for symbols (i.e. old and new 1375 AAAA records for www.example.com), or where policy applications do 1376 not iterate across all returned resource record data in resolvers 1377 that are well behaved. It also assumes that name service data is 1378 updated ahead of policy application, which is ill-advised given that 1379 the instant name servers start serving data regarding new, yet to be 1380 configured, addresses for nodes. 1382 7.5.2. Monitoring tools 1384 Network monitoring and supervisory utilities such as RMON probes, 1385 etc., are often deployed to monitor network status based on IP 1386 traffic. During a renumbering episode, the addresses for which the 1387 probes should monitoring and the addresses of logging services to 1388 which the probes report (e.g. in the case of remote SNMP logging) 1389 need to be tracked. 1391 "Helpdesk ops" service liveness monitoring software also poses a 1392 particular problem where liveness is determined, for example, by a 1393 null transaction (e.g. for POP3 mail server, authenticating and 1394 performing a NOOP) made against a named service instance, if the name 1395 is by IP then two instances of the liveness test will be required: 1396 one on the old address to cater for those remote parties that are not 1397 yet aware of the new address, and one test against the new. 1399 As part of the renumbering process, it may be advantageous to deploy 1400 flow analysis tools that can be scripted to alert administrators on 1401 observation of particular traffic patterns, e.g. flows to a service 1402 under a deprecated prefix during transitions where both old and new 1403 prefixes are live and routed to the site concurrently. This can 1404 highlight, for example, mis-cached DNS resource records, sources of 1405 manually configured service location data, etc. 1407 When relying on DNS labels for identifying nodes to administer, care 1408 must be taken to ensure that the complete set of nodes administered 1409 are caught. For instance, a set of application servers may share the 1410 same DNS label and rely on DNS round-robin for rudimentary load 1411 balancing (a modality at odds with the notion of maintaining resource 1412 records for both old and new prefixes during renumbering episodes). 1413 A network monitoring tool that was configured to monitor just that 1414 service that was resolved by address lookup might only capture one of 1415 that set of nodes. 1417 7.6. Considerations with a Dual-Stack Network 1419 There are several issues to consider when renumbering a dual-stacked 1420 network. In the simplest case, the IPv4 addresses will be remaining 1421 the same while the IPv6 addresses are renumbered. This could, for 1422 example, be due to an upstream renumbering, a change of IPv6 1423 transition method (such as a tunnel), or a topology change. In such 1424 a case, the IPv4 connectivity remains unchanged, and as such can be 1425 used as a fallback during the renumbering to assist with session 1426 continuity, DNS services, etc. 1428 The other case is when the IPv4 network is being renumbered along 1429 with the IPv6 network. Again this could be due to an upstream 1430 change, a network reconfiguration, or because the two are inter- 1431 linked - such as with the 6to4 transition mechanism. In this case, 1432 it is unlikely that the existence of IPv4 on the network can be used 1433 for any advantage, and instead many of the same issues are likely to 1434 be found when renumbering the IPv4 network as for the IPv6 network, 1435 except for the fact that more of the renumbering must be manually 1436 configured, for example by reconfiguring the stateful IPv4 DHCP 1437 configuration, or even manually configuring IPv4 addresses. 1439 A hybrid case is also possible, where IPv4 NAT is used on the 1440 internal network, but with globally routable IPv6 addresses. In this 1441 case, if both networks' external connectivity is being renumbered, 1442 the internal network will only see the effect of the IPv6 1443 renumbering, while keeping the IPv4 addresses the same. The 1444 renumbering procedure will still have an impact on the IPv4 1445 connectivity and its session survivability, however. It may also be 1446 possible that the site uses both global and ULA IPv6 prefixes, the 1447 ULA prefix being deployed to avoid impact to long-running IPv6 1448 sessions. 1450 7.7. Equipment administrative ownership 1452 The question of who owns and administers (also, who is authorised to 1453 administer) the site's access router is an issue in some renumbering 1454 situations. In the enterprise scenarios, the liaison between the end 1455 users and remote administrators is likely to be relatively easy; this 1456 is less likely to be the case for a SOHO scenario. This is not 1457 likely to be a major issue, however, since SOHO renumbering is likely 1458 to only be required if the remote administrators deem it necessary, 1459 or if the end user is sufficiently technically competent and decides 1460 to renumber their own network. 1462 8. Impact of Topology Design on Renumbering 1464 This section looks at considerations regarding network design, such 1465 as network merging, and design-time recommendations that can help 1466 avoid the need for a network renumbering event. 1468 8.1. Merging networks 1470 Renumbering of all or part of a network due to merging two or more 1471 smaller networks has many of the concerns already discussed, but it 1472 may not affect the whole network. For example, multiple disparate 1473 networks may be merged together as one entirely new subnet, and thus 1474 all hosts must be renumbered; but it is also possible that one of the 1475 networks in the merger retains its prefix, and the other network(s) 1476 merge with it. 1478 When the networks merge, the router advertises itself, and the new 1479 prefix if appropriate, to the new hosts, and Duplicate Address 1480 Detection (DAD, see Section 5.4 of [6]) must be applied by the new 1481 hosts to ensure they are not taking addresses already assigned to the 1482 existing hosts. It is implementation-dependent, however, as to 1483 whether the DAD algorithm will be re-run on link-local addresses if 1484 the network configuration is changed, so there is the possibility of 1485 an address conflict. However, as is noted in RFC2462, DAD is not 1486 completely reliable, and as such it cannot be assumed that initially 1487 after a network merge all link-local addresses will be unique. 1489 8.2. Fixed length subnets 1491 The IAB/IESG recommendations for IPv6 address allocations [10] 1492 details some of the motivations behind the change in the addressing 1493 architecture of IPv6 since its inception, and asserts the current 1494 state of a 64-bit 'network' part (the prefix) and a 64-bit 'host' 1495 part (the interface identifier). Fixing the lower 64 bits to be 1496 exclusive of routing topology significantly reduces the 1497 administrative load associated with renumbering and re-subnetting as 1498 experienced with IPv4 networks previously, for example, to get better 1499 address utilisation efficiency as networks evolve and provider 1500 address allocations changed. 1502 The recommendations also discuss what length of network prefix should 1503 be allocated to sites, typically provisioning for 16-bits of subnet 1504 space in which sites can build their topology. Having such a large 1505 address space for sites to divide up at their discretion alleviates 1506 many of the drivers for renumbering discussed during the PIER working 1507 group's lifetime [3]. 1509 8.3. Use 112-bit prefixes for point-to-point links 1511 It is recommended that point-to-point links, such as tunnel endpoints 1512 or router-router links, are allocated /112 subnets from a single /64 1513 within the site's allocation. This simplifies policy-based filtering 1514 and is less wasteful of address space than using /64s everywhere, 1515 improving the address utilisation ratio for the site that would in 1516 extreme cases lead to a larger prefix becoming required. 1518 The 112-bit prefix length is preferred to 127-bit on the advice of 1519 RFC3627[33], which suggests that such allocations can lead to end- 1520 point address starvation where one router elects to take both the 1521 zeroth address in the /127 as a subnet router anycast address and the 1522 first address for its endpoint, leaving no address for the remote end 1523 of the link. 1525 8.4. Plan for growth where possible 1527 When designing address topology - particularly in ISP and larger- 1528 scale Enterprise sites - it is recommended that network designers 1529 plan for growth of lower hierarchies under their provision (e.g. a 1530 /60 satellite site becoming big enough for a /56; a /48 customer 1531 getting sufficiently large as to warrant a shorter prefix). 1533 Techniques for such allocations include centre-most bitset growth as 1534 described in Section 3.3 of RFC3531 [17], which leave the bits nearer 1535 upstream and downstream bit-boundaries until much later in the 1536 allocation selection set, meaning that a boundary shift has minimal 1537 impact on existing deployed allocations. However the overheads and 1538 non-contiguous nature of successive allocations may not suit 1539 Enterprise sites, meaning that other allocation strategies are 1540 required, contextually sensitive to the demands of the site in which 1541 the prefixes are being deployed. 1543 In enterprise networks where satellite sites participate, it is 1544 recommended that single-subnet blocks are skipped in the allocation 1545 such that remote satellites can grow (double) without requiring those 1546 `nearby' in the address block to renumber. 1548 For example, the strategy taken in an enterprise with 56-bit prefixes 1549 allocated to satellites is to leave subsequent /56s for future 1550 expansion of each sub-tier to a /55. 1552 Note that strictly adopting RFC3531 may be insufficient in 1553 enterprises where, for example, there is a mix of subnet provision 1554 (e.g. for satellite sites) and end-user subnets. 1556 8.5. IPv6 NAT Avoidance 1558 RFC2072 stated: "Network address translation (NAT) is a valuable 1559 technique for renumbering, or even for avoiding the need to renumber 1560 significant parts of an enterprise." That is, by 'hiding' the subnet 1561 topology and making independent of any connectivity provider the 1562 addressing model used within a site, NATs enable renumbering of 1563 entire networks because the only device that is renumbered when 1564 global addressing changes is the outside edge of the NAT devices. 1566 However, NAT is strongly discouraged in IPv6, not least because it 1567 breaks end-to-end transparency (as described in [34]) and obscures 1568 identity - including the basis for permission, authorisation, 1569 verification and validation - and thus should not be considered as 1570 being available as a solution. A significant reason to deploy IPv6 1571 is to simplify network and application operation by (IPv4) NAT 1572 removal, for example to provide true end-to-end connectivity, to make 1573 simple the gateway between site and Internet, to encourage 1574 'considered' policy for secure access rather than rely on the 1575 (relatively) dangerous defence of 'hiding' behind a NAT. A more 1576 detailed discussion of the motivations for 'protecting' the network 1577 architecture from NATs can be found in [35]. 1579 9. Application and service-oriented Issues 1581 In this section we highlight issues and common approaches to software 1582 development that 'disrupt' protocol layering to the extent that 1583 applications become aware of renumbering episodes, even if 1584 catastrophic and without knowing how to recover without failing. 1586 NOTE: This section, like the discussion sections before it, will 1587 evolve as experience grows researching the various renumbering 1588 strategies in controlled experiments - particularly in light of 1589 Section 10.1. 1591 9.1. Shims and sockets 1593 As discussed in Section 7.5, Baker's draft calls for application 1594 developers to consider the effects of renumbering whilst applications 1595 are 'live', particularly as regards caching the results of symbol 1596 resolution. Where applications maintain open connections to services 1597 over a sustained period of time (as opposed to the ephemeral nature 1598 of protocol interactions such as with HTTP), any change in either 1599 end's addressing may intrude on the application's execution - 1600 particularly if the change is abrupt or the session longer than the 1601 expiry and withdrawal time of the old addresses. 1603 Various options may be available to minimise the risk of application 1604 disruption in this instance. A HIP-like 'shim' [36], as is being 1605 developed as a candidate solution to the general multi-homing 1606 problem, removes the tight coupling between a connection and a 1607 service's topological location: as the renumbering event takes place, 1608 the locator is updated to reflect the new address topology, and the 1609 application remains blissfully unaware - a form of layer 3.5 1610 mobility. 1612 Alternatively, should the old address space be available such that a 1613 single (or subnet of) Mobile IPv6 Home Agents be deployed in the 1614 routing path of the to-be-otherwise-interrupted connection, then the 1615 endpoint being renumbered could utilise layer 3 mobility once the old 1616 prefix is removed from its link, i.e. register with the Home Agent in 1617 the old prefix topology - presumably in the provider's network, 1618 formerly upstream from the site - and rely on Mobile IPv6 route 1619 optimisation to make good the additional overhead imposed by the 1620 reverse tunnelling to the new prefix. 1622 Applications that employ SCTP as opposed to TCP or UDP for 1623 communication avoid all of the issues highlighted in this sub-section 1624 due to the provision of dynamic endpoint reconfiguration in the 1625 protocol (see Section 4.2). 1627 9.2. Explicitly named IP addresses 1629 There are many places in the network where IP addresses are embedded 1630 as opposed to symbolic names, and finding them all to be updated 1631 during a renumbering episode is not a trivial task. This section 1632 details an evolving list of such places as surveyed as common. 1634 Addresses may be hard-coded in software configuration files or 1635 services, in software source-code itself (which is particularly 1636 cumbersome if no source is available, e.g. a bespoke utility built to 1637 order), in firmware (for example, an access-controlling hardware 1638 dongle), or even in hardware, e.g. fixed by DIP switches. 1640 A non-exhaustive list of instances of such addresses includes: 1642 o Provider based prefix(es) 1644 o Names resolved to IP addresses in firewall at startup time 1646 o IP addresses in remote firewalls allowing access to remote 1647 services 1649 o IP-based authentication in remote systems allowing access to 1650 online bibliographic resources 1652 o IP address of both tunnel end points for IPv6 in IPv4 tunnel 1654 o Hard-coded IP subnet configuration information 1656 o IP addresses for static route targets 1658 o Blocked SMTP server IP list (spam sources) 1660 o Web .htaccess and remote access controls 1661 o Apache .Listen. directive on given IP address 1663 o Configured multicast rendezvous point 1665 o TCP wrapper files 1667 o Samba configuration files 1669 o DNS resolv.conf on Unix 1671 o Any network traffic monitoring tool 1673 o NIS/ypbind via the hosts file 1675 o Some interface configurations 1677 o Unix portmap security masks 1679 o NIS security masks 1681 o PIM-SM Rendezvous Point address on multicast routers 1683 Some hard-coded IP address information will be held in remote 1684 locations, e.g. remote firewalls, DNS glue, etc. adding to the 1685 complexity of the search for all instances of the old prefix. Should 1686 symbols be used rather than addresses, administrative ownership of 1687 DNS - with due consideration for the TTL of resource records - and 1688 other naming services ease this particularly problematic issue of 1689 data ownership and validity. 1691 There are also cases when IP addresses are embedded into payload 1692 data, such as with UDP-based NFS mounts and FTP sessions. These 1693 cases were discussed in more detail in Section 4.2.4. 1695 9.3. API dilemma 1697 In light of Section 7.4.2, there is an open question as to whether we 1698 need an extension to the sockets API that would allow applications 1699 resolving addresses to be able to determine the freshness of the 1700 resolved data. A straw poll of networking applications demonstrated 1701 that common programming practise is to 'resolve once, bind many' 1702 during the lifetime of an application, caching the initial lookup 1703 result and assuming that it is still valid throughout. Whilst this 1704 is a perfectly valid approach for short-lived applications, where the 1705 chance of renumbering - site or the single node - increases with 1706 regards the longevity of the application, the likelihood of the 1707 resolved data being intrusively inaccurate also increases. 1709 Application programmers should therefore consider the possibility of 1710 network renumbering when writing socket software. The best behaviour 1711 is probably to freshly resolve for any socket binding, and let the 1712 resolver handle the caching, based on the DNS TTL. Only when there 1713 are a significant number of connections within a short timeframe 1714 should application-level caching be considered. 1716 9.4. Server Sockets 1718 Certain applications create a server socket and bind the socket so 1719 that they only receive connections or datagrams at one specific 1720 address. These services typically keep the socket bound to that 1721 address until they are shut-down or restarted. This means that if 1722 the host is configured with a new address, these applications would 1723 not respond to that address. 1725 If the applications were listening to the wildcard address, they 1726 would also accept connections and datagrams on new addresses as they 1727 become configured on a node. 1729 An example would be a webserver, which may in fact bind to multiple 1730 different IP addresses to serve content for different domains where 1731 the particular business case is for customers to be allocated their 1732 'own' IP address (e.g. for reverse DNS to reflect their branded 1733 domain name). 1735 A typical work-around would be to schedule a restart of all such 1736 services having first identified whether they can operate on both 1737 address prefixes (to satisfy the middle states of Baker [1]), or at 1738 least to schedule their migration to the new address configuration in 1739 light of the DNS name bindings (considering caches and TTL), and the 1740 nature of existing clients that may still be bound to the old service 1741 (consider graceful migration). 1743 One possible solution, not implemented in existing socket APIs, would 1744 be to allow servers to bind to just the lowest 64 bits of an address, 1745 allowing the network identifier to change without the server knowing. 1746 This is a purely hypothetical solution, however, and has numerous 1747 issues, not least regarding requirements of some server software to 1748 know its current globally routable IP address. 1750 9.5. Sockets surviving invalidity 1752 When an address expires (validity lifetime falls to zero), addresses 1753 are to be removed from interfaces, and the expired address is not to 1754 be used as a source address for further packets (see RFC2462 section 1755 5.5.4 and RFC2215 secion 10). 1757 However, it appears that for an established TCP session or for UDP 1758 where the application has bound to a specific address, many stack 1759 implementations keep using the same source address blindly putting 1760 packets onto the wire, even if the address is removed from the 1761 interface. 1763 It appears that these stack implementations make sure the address is 1764 valid when the TCP session is created or when an application binds to 1765 an address on a datagram socket, but once the socket is bound to that 1766 address there are no more checks. 1768 Whilst this is not a serious issue - certainly, no reply packets 1769 could be received as the interface will not listen for them, and it 1770 is likely that the prefix would no longer be routable at the next-hop 1771 router beyond the point of invalidation - it does mean that 1772 application data will be lost up until that point where the transport 1773 layer determines that the packets are not being received (e.g. TCP 1774 ACKs). 1776 9.6. DNS Authority 1778 It is often the case in enterprises that host web servers and 1779 application servers on behalf of collaborators and customers that DNS 1780 zones out of the administrative control of the host maintain resource 1781 records concerning addresses for nodes out of their control. 1783 The upshot here is that when the service host renumbers, they do not 1784 have sufficient authority to change the AAAA records, etc., that 1785 refer to newly renumbered addresses. 1787 It is recommended that remote DNSes maintain CNAME records to labels 1788 in a zone that is under the authoritative control of the enterprise 1789 whose addresses are referenced. 1791 10. Summary 1793 This memo has further motivated the issue of network renumbering, 1794 highlighted important requirements to ensure that episodes can pass 1795 smoothly with a minimum of disruption to users, and indicated a 1796 number of protocol features and technologies that assist network 1797 designers and operators in the smooth transition from one prefix to 1798 another, all in the context of [1]. 1800 10.1. IETF Call to Arms 1802 Validation surveys of address selection implementations per RFC3484, 1803 of address expiry per RFC2462 and RFC3315, and operational experience 1804 validating the Baker et al. procedure have been carried out and 1805 reported on in other fora (e.g. in D3.6.1 of the 6NET project). 1806 However, in the above considerations, a number of actions would be 1807 most helpful in advancing the understanding of the practical 1808 implications and robustness of IPv6 renumbering. These include: 1810 o Survey of the pervasiveness of address literals and steps to avoid 1811 their use 1813 o Validation of address selection at source and destination during 1814 various stages of Baker's renumbering procedure in implementations 1815 other than Cisco IOS, FreeBSD 5.9, Linux 2.6, Macintosh OS/X 10.4, 1816 Sun Solaris 8-10, Microsoft Windows XP SP2 1818 o Validation of RA lifetime expiry and confirmation of prefix 1819 removal and effects on existing sessions in other implementations 1821 o Validation of IPv6 Prefix Delegation by DHCP, and of IPv6 Router 1822 Renumbering 1824 o Better understanding of the commonalities and differences between 1825 renumbering and multi-homing 1827 o Anecdotal experience of IETF members that have undertaken an IPv6 1828 renumbering exercise, e.g. in the transition from 3FFE::/16 6Bone 1829 addresses to production GAU 1831 Given that this memo is dressed as a set of "things to think about", 1832 there is no conclusion other than a call for input from the IETF 1833 community. 1835 There may be a case to be made to reopen the PIER WG in the new 1836 context of IPv6, although that group has not been active since 1997. 1838 11. IANA Considerations 1840 This document makes no request of IANA. 1842 12. Security Considerations 1844 The security considerations as outlined in [1] still hold, with the 1845 following supporting comments... (tbd) 1847 13. Acknowledgements 1848 The authors gratefully acknowledge the many helpful discussions and 1849 suggestions of their colleagues from the 6NET consortium, 1850 particularly Fred Baker, Graca Carvalho, Ralph Droms, David Mills, 1851 Thorsten Kuefer, Eliot Lear, Christian Schild, Andre Stolze, Tina 1852 Strauf, Bernard Tuy, and Gunter Van de Velde. 1854 14. References 1856 14.1. Normative References 1858 [1] Baker, F., "Procedures for Renumbering an IPv6 Network without a 1859 Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in 1860 progress), March 2005. 1862 [2] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, 1863 "Enterprise Renumbering: Experience and Information 1864 Solicitation", RFC 1916, February 1996. 1866 [3] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: 1867 Why would I want it and what is it anyway?", RFC 2071, 1868 January 1997. 1870 [4] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 1871 January 1997. 1873 [5] Draves, R., "Default Address Selection for Internet Protocol 1874 version 6 (IPv6)", RFC 3484, February 2003. 1876 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 1877 Autoconfiguration", RFC 2462, December 1998. 1879 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, 1880 August 2000. 1882 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1883 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1885 14.2. Informative References 1887 [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1888 IPv4 Clouds", RFC 3056, February 2001. 1890 [10] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1891 Allocations to Sites", RFC 3177, September 2001. 1893 [11] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1894 Allocation) Phaseout", RFC 3701, March 2004. 1896 [12] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1897 Site Automatic Tunnel Addressing Protocol (ISATAP)", 1898 draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. 1900 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1901 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1903 [14] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1904 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 1906 [15] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1907 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1908 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1909 October 2000. 1911 [16] Stewart, R., "Stream Control Transmission Protocol (SCTP) 1912 Dynamic Address Reconfiguration", 1913 draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006. 1915 [17] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1916 Addressing Architecture", RFC 3513, April 2003. 1918 [18] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1919 IPv6", RFC 3775, June 2004. 1921 [19] Huston, G., "Architectural Approaches to Multi-Homing for 1922 IPv6", draft-ietf-multi6-architecture-04 (work in progress), 1923 February 2005. 1925 [20] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1926 Multicast Addresses", RFC 3306, August 2002. 1928 [21] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1929 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1930 November 2004. 1932 [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1933 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in 1934 progress), January 2005. 1936 [23] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local 1937 IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-01 (work 1938 in progress), February 2005. 1940 [24] Matsumoto, A., "Source Address Selection Policy Distribution 1941 for Multihoming", draft-arifumi-multi6-sas-policy-dist-00 (work 1942 in progress), October 2004. 1944 [25] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1945 Addresses", RFC 2526, March 1999. 1947 [26] Jeong, J., "IPv6 Host Configuration of DNS Server Information 1948 Approaches", draft-ietf-dnsop-ipv6-dns-configuration-06 (work 1949 in progress), May 2005. 1951 [27] Abley, J. and K. Lindqvist, "Operation of Anycast Services", 1952 draft-ietf-grow-anycast-04 (work in progress), July 2006. 1954 [28] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting 1955 Service", RFC 1546, November 1993. 1957 [29] Venaas, S. and T. Chown, "Information Refresh Time Option for 1958 DHCPv6", draft-ietf-dhc-lifetime-03 (work in progress), 1959 January 2005. 1961 [30] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1962 Carney, "Dynamic Host Configuration Protocol for IPv6 1963 (DHCPv6)", RFC 3315, July 2003. 1965 [31] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1966 Configuration Protocol (DHCP) version 6", RFC 3633, 1967 December 2003. 1969 [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1970 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1971 April 1997. 1973 [33] Savola, P., "Use of /127 Prefix Length Between Routers 1974 Considered Harmful", RFC 3627, September 2003. 1976 [34] Carpenter, B., "Internet Transparency", RFC 2775, 1977 February 2000. 1979 [35] Velde, G., "IPv6 Network Architecture Protection", 1980 draft-ietf-v6ops-nap-03 (work in progress), July 2006. 1982 [36] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1983 Architecture", draft-ietf-hip-arch-03 (work in progress), 1984 August 2005. 1986 URIs 1988 [38] 1990 [39] 1992 Authors' Addresses 1994 Tim J. Chown 1995 University of Southampton, UK 1996 Electronics and Computer Science 1997 University of Southampton 1998 Southampton SO17 1BJ 1999 UK 2001 Phone: +44 23 8059 5415 2002 Fax: +44 23 8059 2865 2003 Email: tjc@ecs.soton.ac.uk 2005 Mark K. Thompson 2006 University of Southampton, UK 2008 Email: mkt@ecs.soton.ac.uk 2010 Alan Ford 2011 University of Southampton, UK 2013 Email: ajf101@ecs.soton.ac.uk 2015 Stig Venaas 2016 University of Southampton, UK 2018 Email: sv@ecs.soton.ac.uk 2020 Intellectual Property Statement 2022 The IETF takes no position regarding the validity or scope of any 2023 Intellectual Property Rights or other rights that might be claimed to 2024 pertain to the implementation or use of the technology described in 2025 this document or the extent to which any license under such rights 2026 might or might not be available; nor does it represent that it has 2027 made any independent effort to identify any such rights. Information 2028 on the procedures with respect to rights in RFC documents can be 2029 found in BCP 78 and BCP 79. 2031 Copies of IPR disclosures made to the IETF Secretariat and any 2032 assurances of licenses to be made available, or the result of an 2033 attempt made to obtain a general license or permission for the use of 2034 such proprietary rights by implementers or users of this 2035 specification can be obtained from the IETF on-line IPR repository at 2036 http://www.ietf.org/ipr. 2038 The IETF invites any interested party to bring to its attention any 2039 copyrights, patents or patent applications, or other proprietary 2040 rights that may cover technology that may be required to implement 2041 this standard. Please address the information to the IETF at 2042 ietf-ipr@ietf.org. 2044 Disclaimer of Validity 2046 This document and the information contained herein are provided on an 2047 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2048 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2049 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2050 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2051 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2052 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2054 Copyright Statement 2056 Copyright (C) The Internet Society (2006). This document is subject 2057 to the rights, licenses and restrictions contained in BCP 78, and 2058 except as set forth therein, the authors retain all their rights. 2060 Acknowledgment 2062 Funding for the RFC Editor function is currently provided by the 2063 Internet Society.