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