idnits 2.17.1 draft-jiang-ipv6-site-renum-guideline-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2011) is 4829 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2072' is mentioned on line 374, but not defined == Unused Reference: 'RFC3736' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC4076' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC4192' is defined on line 529, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft B. Liu 3 Intended status: Best Current Practice Huawei Technologies Co., Ltd 4 Expires: August 5, 2011 January 26, 2011 6 IPv6 Site Renumbering Guidelines and Further Works 7 draft-jiang-ipv6-site-renum-guideline-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on August 5, 2011. 26 Copyright Notice 28 Copyright (c) 2011 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 This document analyzes the existing issues for IPv6 site renumbering. 44 It also analyzes the possible directions to solve these issues and 45 gives recommendations. This document only takes the perspective of 46 network and network protocols. Renumbering in IPv4 networks, in the 47 dual-stack network or in the IPv4/IPv6 transition networks are out of 48 scope. 50 This document only takes the perspective of network and network 51 protocols. According to the different stages, these issues are 52 described in three categories: considerations during network design, 53 considerations for routine network management, and considerations 54 during renumbering operation. Recommended solutions or strategies are 55 also described. Issues that still remain unsolvable are listed as the 56 fourth category. 58 Although we list a few non-network issues in this document, we 59 consider them as issues that ISPs or network providers cannot affect. 60 So, these issues are considered to be unsolvable and not explore 61 further in these document, though they may be solved by OS 62 implementations or application implementations. 64 We summary the requests that need to extend current protocols as 65 further works at the end of this document. 67 Table of Contents 69 1. Introduction ................................................. 3 70 2. Network Renumbering Considerations and Solutions/Strategies... 3 71 2.1. Considerations/issues during network design ............. 4 72 2.2. Considerations/issues for the routine network management. 5 73 2.3. Considerations/issues during renumbering operation....... 6 74 2.4. Issues that still remain unsolvable ..................... 8 75 2.5. Issues that need further analysis ....................... 9 76 3. Non-network issues ........................................... 9 77 4. Requests to extend current protocol ......................... 10 78 5. Security Considerations ..................................... 11 79 6. IANA Considerations ......................................... 11 80 7. Acknowledgements ............................................ 11 81 8. Change Log [RFC Editor please remove] ....................... 11 82 9. References .................................................. 11 83 9.1. Normative References ................................... 11 84 9.2. Informative References ................................. 12 85 Author's Addresses ............................................. 13 87 1. Introduction 89 [RFC5887] has reviewed the existing mechanisms for site renumbering 90 for both IPv4 and IPv6, and identified operational issues with those 91 mechanisms. However, the discussion and analysis were too wide. It 92 exposure many issues, but not give enough analysis on whether these 93 issues are solvable and how. Even the document itself indicates more 94 fractionized and detailed analysis is needed. On another side, the 95 mechanisms analyzed in the document are still not in used. 97 This document focuses on IPv6 network renumbering only, by leaving 98 IPv4 out of scope. Renumbering in IPv4 networks, in the dual-stack 99 network or in the IPv4/IPv6 transition networks are out of scope. 100 This is also consistent preference from IETF renumber mail list by 101 the time of writing up. 103 This document is mainly concerned with issues affecting medium to 104 large sites, which is taken as the conclusion from [RFC5887]. It 105 takes the analysis conclusions from [RFC5887] and other relevant 106 documents as the primary input. 108 This document only takes the perspective of network and network 109 protocols. According to the different stages, these issues are 110 described in three categories: considerations during network design, 111 considerations for routine network management, and considerations 112 during renumbering operation. Recommended solutions or strategies are 113 also described. Issues that still remain unsolvable are listed as the 114 fourth category. 116 Issues that need further analysis are temporarily listed for now. 117 They should all be relocated into abovementioned four categories. 119 Although we list a few non-network issues in this document, we 120 consider them as issues that ISPs or network providers cannot affect. 121 So, these issues are considered to be unsolvable and not explore 122 further in these document, though they may be solved by OS 123 implementations or application implementations. 125 At the end of this document, we summary the requests that need to 126 extend current protocols. 128 2. Network Renumbering Considerations and Solutions/Strategies 130 The purpose of this section is not to describe the renumbering 131 operation or event completely or entirely, but to expose the existing 132 issues and give the recommended solutions or strategies. 134 2.1. Considerations/issues during network design 136 This section describes the renumbering relevant considerations or 137 issues that a network architect should carefully plan when he builds 138 or designs a new network. 140 - Address configuration models 142 In IPv6 networks, there are two auto-configuration models for 143 address assignment: the Stateless Address Auto-Configuration 144 (SLAAC) by Neighbor Discovery (ND, [RFC4861, RFC4862]) and the 145 stateful address configuration by Dynamic Host Configuration 146 Protocol for IPv6 (DHCPv6, [RFC3315]). (Manual address 147 configuration is not scalable in medium to large sites, hence be 148 out of scope.) 150 SLAAC is considered easier to renumbering by broadcasting a Router 151 Advertisement message with a new prefix. DHCPv6 can also trigger 152 the renumbering process by sending unicast RECONFIGURE messages 153 though it may cause large number of interactions between hosts and 154 DHCPv6 server. However, DHCPv6 reconfiguration "doesn't appear to 155 be widely used for bulk renumbering purposes" [RFC5887]. 157 In principle, a network should choice only one address 158 configuration model and employs either ND or DHCPv6. However, 159 since DHCPv6 is also used to configure many other network 160 parameters, there are ND and DHCPv6 co-existing scenarios. The 161 current protocols do not effectively prevent that both SLAAC and 162 DHCPv6 address assignment are used in the same network (see M bit 163 analysis in section 5.1.1 [RFC5887]. It is network architects' job 164 to make sure only one configuration model is employed. Even in a 165 large network that contains several subnet works, it is 166 recommended not to mixture the two address configuration models 167 though isolately using them in different subnet works may reduce 168 the risk partly. 170 On another side, new protocol extension may help to diagnose the 171 fault situation. This diagnose function could be particularly 172 useful in the scenario where a multihomed network uses SLAAC for 173 one address prefix and DHCPv6 for another. 175 - DNS 177 It is recommended that the site have an automatic and systematic 178 procedure for updating/synchronising its DNS records, including 179 both forward and reverse mapping. Manually on-demand updating 180 model is considered as a harmful problem creator in renumbering 181 event. 183 In order to simplify the operation procedure, the network 184 architect should combine the forward and reverse DNS updates in a 185 single procedure. 187 If a small site depends on its ISP's DNS system rather than 188 maintains its own one. When renumbering, it requires 189 administrative coordination between the site and its ISP. 190 Alternatively, the DNS synchronizing may be completed through the 191 Secure Dynamic DNS Update. 193 - Security 195 Any automatic renumbering scheme has a potential exposure to 196 hijacking at the moment that a new address is announced. Proper 197 network security mechanisms should be employed. Secure Neighbour 198 Discovery (SEND, [RFC3971]), which does not widely deployed, is 199 recommended to replace ND. Alternatively, certain lightweight 200 renumbering specific security mechanism may be developed in the 201 future. DHCPv6 build-in secure mechanisms, like Secure DHCPv6 202 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 203 [RFC3315] are recommended. 205 - Miscellaneous 207 Addresses should not be used to configure network connectivity, 208 such as tunnels. A site or network should also avoid to embed 209 addresses from other sites or networks in its own configuration 210 data. Instead, the Fully-Qualified Domain Names should be used. 211 Thusness, these connectivities can survive after renumbering 212 events. This also applies to host-based connectivities. 214 Service Location Protocol and multicast DNS with SRV records for 215 service discovery can reduce the number of places that IP 216 addresses need to be configured. 218 2.2. Considerations/issues for the routine network management 220 This session describes several recommendations for the routine 221 network management. To adopt these recommendations, a site could be 222 renumbered easier. However, these recommendations are not cost free. 223 They are possible to increase the daily burden of networks. 224 Therefore, only these networks that are expected to be renumbered 225 soon or very frequent should adopt these recommendations with the 226 balance consideration between daily cost and renumbering cost. 228 - Reduce the address preferred time or valid time or both. 230 Long-lifetime addresses may cause issues for renumbering events. 231 Particularly, some offline hosts may reconnect back using these 232 addresses after renumbering events. Shorter preferred lifetime 233 with relevant long valid lifetime may get short transition period 234 for renumbering event and avoid address renew too frequent. 236 - Reduce the DNS record TTL. 238 The DNS record TTL on the local DNS server should be manipulated 239 to ensure that stale addresses are not cached. 241 - Reduce the DNS configuration lifetime on the hosts. 243 Since the DNS server could be renumbered as well, the DNS 244 configuration lifetime on the hosts should also be reduced if 245 renumbering events are expected. The DNS configuration can be done 246 through either ND [RFC6106] or DHCPv6 [RFC3646]. However, DHCPv6 247 DNS option does not include associated lifetime. It should be 248 updated. 250 - Reduce the NAT mapping session keepalive time. 252 Idle NAT mapping session may be keep alive for a long period if 253 the external network addresses space is plenteous and the internal 254 network address architecture is stable. However, renumbering 255 events mean to restructure the internal network address 256 architecture fully or partly. Reducing the NAT mapping session 257 keepalive time may help to tear down the idle TCP connectivities. 258 This will reduce the TCP surviving issue during the renumbering 259 event. 261 2.3. Considerations/issues during renumbering operation 263 Renumbering events are not instantaneous events. Normally, there is a 264 transition period, in which both the old prefix and the new prefix 265 are used in the site. Better network design and management, better 266 pre-preparation and longer transition period are helpful to reduce 267 the issues during renumbering operation. 269 - Transition period 271 If renumbering transition period is longer than all addresses 272 life, after which the addresses lease expire, each host will 273 automatically pick up its new IP address. In this case, it would 274 be the DHCP server or Router Advertisement itself that 275 automatically accomplishes client renumbering. 277 - Network initiative enforced renumbering 279 If the network has to enforce renumbering before addresses lease 280 expire, the network should initiate enforcement messages, either 281 in Router Advertisement messages or DHCPv6 RECONFIGURE messages. 283 - DNS record update and DNS configuration on hosts 285 DNS records should be updated if hosts are renumbered. If the site 286 depends on ISP's DNS system, it should report the new host's DNS 287 records to its ISP. During the transition period, both old and new 288 DNS records are valid. If the TTL of DNS records is shorter than 289 the transition period, administrative operation may not be 290 necessary. 292 DNS configuration on hosts should be updated if local recursive 293 DNS servers are renumbered. During the transition period, both old 294 and new DNS addresses may co-exist on the hosts. If the lifetime 295 of DNS configuration is shorter than the transition period, name 296 resolving failure may not be reduced to minimum. A notification 297 mechanism may be needed to indicate the hosts that a renumbering 298 event of local re DNS happen or is going to take place recursive. 300 - Router awareness 302 In a site with multiple border routers, portion renumbering should 303 be aware by all border routers in order to correctly handle 304 inbound packets. Internal forwarding tables need to be updated. 306 - Border filtering 308 In a multihomed site, an egress router to ISP A could normally 309 filter packets with source addresses from other ISPs. The egress 310 router connecting to ISP A should be notified if the egress router 311 connecting to ISP B initiates a renumbering event in order to 312 properly act filter function. 314 - NAT or tunnel concentrator renumbering 316 NAT or tunnel concentrator itself might be renumbered. This change 317 should be reconfigured to relevant hosts or router. 319 2.4. Issues that still remain unsolvable 321 This section lists a few issues that still remain unsolvable. Some of 322 them may be inherently unsolvable. 324 - It is not possible to reduce a prefix's lifetime to below two 325 hours. So, renumbering should not be an unplanned sudden event. 326 This issue could only be avoided by early planning. 328 - Manual or script-driven procedures will break the completely 329 automatic host renumbering. 331 - Some environments like embedded systems might not use DHCP or 332 SLAAC and even configuration scripts might not be an option. 333 This creates special problems that no general-purpose solution 334 is likely to address. 336 - TCP and UDP flows can't survive at renumbering event at either 337 end. 339 - Some address configuration data might be widely dispersed and 340 much harder to find, even will inevitably be found only after 341 the renumbering event. 343 - The embedding of IPv6 unicast addresses into multicast 344 addresses and the embedded-RP (Rendezvous Point) will cause 345 issues when renumbering. 347 - Changing the unicast source address of a multicast sender might 348 also be an issue for receivers. 350 - When a renumbering event takes place, entries in the state 351 table of NAT or tunnel concentrator that happen to contain the 352 affected addresses will become invalid and will eventually time 353 out. However, this can be considered as harmless though it 354 takes sources on these devices for a while. 356 - A site that is listed in a black list can escape that list by 357 renumbering itself. The site itself of course will not 358 initiatively to report its renumbering and the black list may 359 not be able to monitor or discover the renumbering event. 361 Some of these issues can be considered as harmless or have minimum 362 impacts. 364 2.5. Issues that need further analysis 366 This section lists a few issues that still need further analysis. 367 Some of them may be addressed in later version of this document and 368 relocated into other sections. Some of them may be worthy separated 369 document. (Editor note: if all issues addressed, this section should 370 be removed.) 372 - "Some routers cache IP addresses in some situations. So 373 routers might need to be restarted as a result of site 374 renumbering" [RFC2072]. It seems this caused by individual 375 implementation and only happen on the old type of routers. 376 (Author note: to be removed, if confirmed) 378 - Multihomed site, using SLAAC for one address prefix and DHCPv6 379 for another, would clearly create a risk of inconsistent host 380 behaviour and operational confusion. 382 - It seems so far the renumbering studies only focusing on the 383 individual network using a single prefix. In a large network, a 384 short prefix may be used. The prefix is assigned to be longer 385 and prefixes and delegated to several sub-networks. To make the 386 scenario even more complicated, it may be some sub-networks 387 employ SLAAS while some others are managed by DHCPv6. How to 388 coordinate among these sub-networks to be renumbered together 389 may be worth of analyzing. 391 - The impact of portion renumbering may need to be analyzed 392 further. 394 3. Non-network issues 396 Although we focus on network side, in this section, we also list a 397 few non-network issues. They are out of network providers/operators 398 reach. Therefore, from network perspective, these issues are 399 considered to be unsolvable though they may be solved by OS 400 implementations or application/service implementations. It is out of 401 scope to explore these issues further. 403 - Any implementation is at risk from renumbering if it does not 404 check that an address is valid each time it opens a new 405 communications session 407 - Socket API encourages applications to be aware of and to store 408 IP address. And the API relative functions do not return an 409 address lifetime so that applications have no way to know the 410 address is no longer valid. 412 - "DNS Pining": limits acceptance of server IP address changes 413 for JavaScript security considerations and it may directly 414 damage the ability of applications to deal with renumbering. 416 - Server applications might need to be restarted when the host 417 they contain is renumbered. In an IPv6 multi-addressed host, 418 server applications need to be able to listen on more than one 419 address simultaneously. Name-based APIs or implementations are 420 recommended. 422 - When a nameserver is renumbered, the host may not be aware or 423 notified immediately; or even the host is notified, but it 424 still considers the old nameserver is available. The host will 425 at some point find it unavailable. This will cause name 426 resolving failure though these failure may be recoverable. 428 - Renumbering may cause issues for ACLs or group login services. 430 4. Requests to extend current protocol 432 As mentioned in section 2, the following request to extend the 433 current protocols. 435 - A diagnose function to detect and report the confliction of 436 SLAAC and DHCPv6 address assignment. 438 - The current protocol needs to be extended if it does not 439 support to combine the forward and reverse DNS updates in a 440 single procedure. (Author note: it seems possible. If so, 441 remove this item.) 443 - DHCPv6 should be extended to indicate hosts the associated DNS 444 lifetimes when making DNS configuration. 446 - A lightweight renumbering specific security mechanism may be 447 developed if SEND is too weight to be widely deployed. 449 - If the issues of coordination among these sub-networks to be 450 renumbered together are confirmed, new interaction may need to 451 be defined to achieve the cooperation. 453 - A notification mechanism may be needed to indicate the hosts 454 that a renumbering event of local recursive DNS happen or is 455 going to take place recursive. 457 - NAT or tunnel concentrator configuration procedure may need to 458 be extended to be able to notify the host the renumbering of 459 NAT or tunnel concentrator. 461 5. Security Considerations 463 A site that is listed in a black list can escape that list by 464 renumbering itself. 466 Any automatic renumbering scheme has a potential exposure to 467 hijacking at the moment that a new address is announced. Proper 468 network security mechanisms should be employed. SEND is recommended 469 to replace ND. Alternatively, certain lightweight renumbering 470 specific security mechanism may be developed in the future. DHCPv6 471 build-in secure mechanisms, like Secure DHCPv6 472 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 473 [RFC3315] are recommended. 475 The security updates will need to be made in two stages (immediately 476 before and immediately after the event). 478 [Editor note: this section needs further work.] 480 6. IANA Considerations 482 This draft does not request any IANA action. 484 7. Acknowledgements 486 This work is illumined by RFC5887, so thank for RFC 5887 authors, 487 Brian Carpeter, Randall Atkinson and Hannu Flinck. Useful ideas were 488 also illumined by documents from Tim Chown and Fred Bark. 490 8. Change Log [RFC Editor please remove] 492 draft-jiang-ipv6-site-renumbering-ps-00, original version, 2011-01-28 494 9. References 496 9.1. Normative References 498 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 499 M. Carney, "Dynamic Host Configuration Protocol for IPv6 500 (DHCPv6)", RFC 3315, July 2003. 502 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 503 Configuration Protocol for IPv6 (DHCPv6) ", RFC3646, 504 December 2003. 506 [RFC3736] R. Droms, "Stateless Dynamic Host Configuration Protocol 507 (DHCP) Service for IPv6", RFC 3736, April 2004. 509 [RFC3971] J. Arkko, Ed., J. Kempf, B. Zill, and P. Nikander "SEcure 510 Neighbor Discovery (SEND)", RFC 3971, March 2005 512 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 513 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 514 September 2007. 516 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 517 Address Autoconfiguration", RFC 4862, September 2007. 519 [RFC6106] J. Jeong, Ed., S. Park, L. Beloeil, and S. Madanapalli 520 "IPv6 Router Advertisement Option for DNS Configuration", 521 RFC 6106, November 2011. 523 9.2. Informative References 525 [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering 526 Requirements for Stateless Dynamic Host Configuration 527 Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005. 529 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 530 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 531 September 2005. 533 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 534 Still Needs Work", RFC 5887, May 2010. 536 [I-D.ietf-dhc-secure-dhcpv6] 537 Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working 538 in progress. 540 Author's Addresses 542 Sheng Jiang 543 Huawei Technologies Co., Ltd 544 Huawei Building, No.3 Xinxi Rd., 545 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 546 P.R. China 547 Email: shengjiang@huawei.com 549 Bing Liu 550 Huawei Technologies Co., Ltd 551 Huawei Building, No.3 Xinxi Rd., 552 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 553 P.R. China 554 Email: leo.liubing@huawei.com