idnits 2.17.1 draft-ietf-6renum-enterprise-05.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 (December 21, 2012) is 4143 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational Huawei Technologies Co., Ltd 4 Expires: June 23, 2013 B. Carpenter 5 University of Auckland 6 December 21, 2012 8 IPv6 Enterprise Network Renumbering Scenarios, 9 Considerations and Methods 10 draft-ietf-6renum-enterprise-05.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute working 19 documents as Internet-Drafts. The list of current Internet-Drafts is 20 at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on June 23, 2013. 29 Copyright Notice 31 Copyright (c) 2012 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Abstract 46 This document analyzes events that cause renumbering and describes 47 the current renumbering methods. These are described in three 48 categories: those applicable during network design, those applicable 49 during preparation for renumbering, and those applicable during the 50 renumbering operation. 52 Table of Contents 54 1. Introduction ................................................. 3 55 2. Enterprise Network Illustration for Renumbering .............. 3 56 3. Enterprise Network Renumbering Scenario Categories ........... 5 57 3.1. Renumbering Caused by External Network Factors .......... 5 58 3.2. Renumbering caused by Internal Network Factors .......... 6 59 4. Network Renumbering Considerations and Current Methods ....... 6 60 4.1. Considerations and Current Methods during Network Design. 6 61 4.2. Considerations and Current Methods for the Preparation of 62 Renumbering ................................................. 10 63 4.3. Considerations and Current Methods during Renumbering 64 Operation ................................................... 11 65 5. Security Considerations ..................................... 13 66 6. IANA Considerations ......................................... 14 67 7. Acknowledgements ............................................ 14 68 8. References .................................................. 14 69 8.1. Normative References ................................... 14 70 8.2. Informative References ................................. 15 71 Author's Addresses ............................................. 17 73 1. Introduction 75 Site renumbering is difficult. Network managers frequently attempt to 76 avoid future renumbering by numbering their network resources from 77 Provider Independent (PI) address space. However, widespread use of 78 PI would aggravate BGP4 scaling problems [RFC4116] and, depending on 79 Regional Internet Registry (RIR) policies, PI space is not always 80 available for enterprises of all sizes. Therefore, it is desirable to 81 develop mechanisms that simplify IPv6 renumbering for enterprises. 83 This document is an analysis of IPv6 site renumbering for enterprise 84 networks. It undertakes scenario descriptions, including 85 documentation of current capabilities and existing practices. The 86 reader is assumed to be familiar with [RFC4192] and [RFC5887]. 87 Proposals for new technology and methods are out of scope. 89 Since IPv4 and IPv6 are logically separate from the perspective of 90 renumbering, regardless of overlapping of the IPv4/IPv6 networks or 91 devices, this document focuses on IPv6 only, leaving IPv4 out of 92 scope. Dual-stack network or IPv4/IPv6 transition scenarios are out 93 of scope, too. 95 This document focuses on enterprise network renumbering; however, 96 most of the analysis is also applicable to ISP network renumbering. 97 Renumbering in home networks is out of scope, but it can also benefit 98 from the analysis in this document. 100 The concept of an enterprise network and a typical network 101 illustration are introduced first. Then, current renumbering methods 102 are introduced according to the following categories: those 103 applicable during network design, those applicable during preparation 104 for renumbering, and those applicable during the renumbering 105 operation. 107 2. Enterprise Network Illustration for Renumbering 109 An Enterprise Network as defined in [RFC4057] is a network that has 110 multiple internal links, one or more router connections to one or 111 more Providers, and is actively managed by a network operations 112 entity. 114 Figure 1 provides a sample enterprise network architecture for a 115 simple case. Those entities mainly affected by renumbering are 116 illustrated: 118 * Gateway: Border router, firewall, web cache, etc. 120 * Application server (for internal or external users) 122 * DNS and DHCP servers 124 * Routers 126 * Hosts (desktops etc.) 128 Address reconfiguration is fulfilled either by the Dynamic Host 129 configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for 130 IPv6 (ND) protocols. During a renumbering event, the Domain Name 131 Service (DNS) records need to be synchronized while routing tables, 132 Access Control Lists (ACLs) and IP filtering tables in various 133 devices also need to be updated. It is taken for granted that 134 applications will work entirely on the basis of DNS names, but any 135 direct dependencies on IP addresses in application layer entities 136 must also be updated. 138 The issue of static addresses is described in a dedicated draft 139 [I-D.ietf-6renum-static-problem]. 141 Uplink 1 Uplink 2 142 | | 143 +---+---+ +---+---+ 144 +---- |Gateway| --------- |Gateway| -----+ 145 | +-------+ +-------+ | 146 | Enterprise Network | 147 | +------+ +------+ +------+ | 148 | | APP | |DHCPv6| | DNS | | 149 | |Server| |Server| |Server| | 150 | +---+--+ +---+--+ +--+---+ | 151 | | | | | 152 | ---+--+---------+------+---+- | 153 | | | | 154 | +--+---+ +---+--+ | 155 | |Router| |Router| | 156 | +--+---+ +---+--+ | 157 | | | | 158 | -+---+----+-------+---+--+- | 159 | | | | | | 160 | +-+--+ +--+-+ +--+-+ +-+--+ | 161 | |Host| |Host| |Host| |Host| | 162 | +----+ +----+ +----+ +----+ | 163 +----------------------------------------+ 164 Figure 1 Enterprise network illustration 166 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 167 stack in which a logical IPv6 plane is independent from IPv4. As 168 mentioned above, IPv4/IPv6 co-existence scenarios are out of scope. 170 This document focuses on routable unicast addresses; link-local, 171 multicast and anycast addresses are also out of scope. 173 3. Enterprise Network Renumbering Scenario Categories 175 In this section, we divide enterprise network renumbering scenarios 176 into two categories defined by external and internal network factors, 177 which require renumbering for different reasons. 179 3.1. Renumbering Caused by External Network Factors 181 The following ISP uplink-related events can cause renumbering: 183 o The enterprise network switches to a new ISP. When this occurs, 184 the enterprise stop numbering its resources from the prefix 185 allocated by the old ISP and renumbers its resources from the 186 prefix allocated by the new ISP. 188 When the enterprise switches ISPs, a "flag day" renumbering event 189 [RFC4192] may be averted if, during a transitional period, the 190 enterprise network may number its resources from either prefix. 191 One way to facilitate such a transitional period is for the 192 enterprise to contract for service from both ISPs during the 193 transition. 195 o The renumbering event can be initiated by receiving new prefixes 196 from the same uplink. This might happen if the enterprise network 197 is switched to a different location within the network topology of 198 the same ISP due to various considerations, such as commercial, 199 performance or services reasons, etc. Alternatively, the ISP 200 itself might be renumbered due to topology changes or migration to 201 a different or additional prefix. These ISP renumbering events 202 would initiate enterprise network renumbering events, of course. 204 o The enterprise network adds new uplink(s) for multihoming purposes. 205 This might not be a typical renumbering case because the original 206 addresses will not be changed. However, initial numbering may be 207 considered as a special renumbering event. The enterprise network 208 removes uplink(s) or old prefixes. 210 3.2. Renumbering caused by Internal Network Factors 212 o As companies split, merge, grow, relocate or reorganize, the 213 enterprise network architectures might need to be re-built. This 214 will trigger partial or total internal renumbering. 216 o The enterprise network might proactively adopt a new address 217 scheme, for example by switching to a new transition mechanism or 218 stage of a transition plan. 220 o The enterprise network might reorganize its topology or subnets. 222 4. Network Renumbering Considerations and Current Methods 224 In order to carry out renumbering in an enterprise network, 225 systematic planning and administrative preparation are needed. 226 Careful planning and preparation could make the renumbering process 227 smoother. 229 This section describes current solutions or strategies for enterprise 230 renumbering, chosen among existing mechanisms. There are known gaps 231 analyzed by [I-D.ietf-6renum-gap-analysis] and 232 [I-D.ietf-6renum-static-problem]. If these gaps are filled in the 233 future, enterprise renumbering can be processed more automatically, 234 with fewer issues. 236 4.1. Considerations and Current Methods during Network Design 238 This section describes the consideration or issues relevant to 239 renumbering that a network architect should carefully plan when 240 building or designing a new network. 242 - Prefix Delegation 244 In a large or a multi-site enterprise network, the prefix should 245 be carefully managed, particularly during renumbering events. 246 Prefix information needs to be delegated from router to router. 247 The DHCPv6 Prefix Delegation options [RFC3633] and [RFC6603] 248 provide a mechanism for automated delegation of IPv6 prefixes. 249 Normally, DHCPv6 Prefix Delegation (PD) options are used between 250 the internal enterprise routers, for example, a router receives 251 prefix(es) from its upstream router (a border gateway or edge 252 router etc.) through DHCPv6 PD options and then advertises it 253 (them) to the local hosts through Router Advertisement (RA) 254 messages. 256 - Usage of FQDN 257 In general, Fully-Qualified Domain Names (FQDNs) are recommended 258 to be used to configure network connectivity, such as tunnels, 259 servers etc. The capability to use FQDNs as endpoint names has 260 been standardized in several RFCs, for example for IPsec 261 [RFC5996], although many system/network administrators do not 262 realize that it is there and works well as a way to avoid manual 263 modification during renumbering. 265 Note that using FQDN would rely on DNS systems. For a link local 266 network that does not have a DNS system, multicast DNS 267 [I-D.cheshire-dnsext-multicastdns] could be utilized. For some 268 specific circumstances, using FQDN might not be chosen if adding 269 DNS service in the node/network would cause undesired complexity 270 or issues. 272 Service discovery protocols such as Service Location Protocol 273 [RFC2608], multicast DNS with SRV records and DNS Service 274 Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce 275 the number of places that IP addresses need to be configured. But 276 it should be noted that these protocols are normally used link- 277 local only. 279 Network designers generally have little control over the design of 280 application software. However, it is important to avoid any 281 software that has built-in dependency on IP addresses instead of 282 FQDNs [I-D.ietf-6renum-static-problem]. 284 - Usage of ULA 286 Unique Local Addresses (ULAs) are defined in [RFC4193] as 287 provider-independent prefixes. Since there is a 40 bits pseudo 288 random field in the ULA prefix, there is no practical risk of 289 collision (please refer to section 3.2.3 in [RFC4193] for more 290 detail). For enterprise networks, using ULA simultaneously with 291 Provider Aggregated (PA) addresses can provide a logically local 292 routing plane separated from the global routing plane. The benefit 293 is to ensure stable and specific local communication regardless of 294 any ISP uplink failure. This benefit is especially meaningful for 295 renumbering. It mainly includes three use cases described below. 297 During the transition period, it is desirable to isolate local 298 communication changes in the global routing plane. If we use 299 ULA for the local communication, this isolation is achieved. 301 Enterprise administrators might want to avoid the need to 302 renumber their internal-only, private nodes when they have to 303 renumber the PA addresses of the whole network because of 304 changing ISPs, ISPs restructuring their address allocation, or 305 any other reasons. In these situations, ULA is an effective 306 tool for the internal-only nodes. 308 ULA can be a way of avoiding renumbering from having an impact 309 on multicast. In most deployments multicast is only used 310 internally (intra-domain), and the addresses used for 311 multicast sources and Rendezvous-Points need not be reachable 312 nor routable externally. Hence one may at least internally 313 make use of ULA for multicast specific infrastructure. 315 - Address Types 317 This document focuses on the dynamically-configured global unicast 318 addresses in enterprise networks. They are the targets of 319 renumbering events. 321 Manually-configured addresses are not scalable in medium to large 322 sites, hence should be avoided for both network elements and 323 application servers [I-D.ietf-6renum-static-problem]. 325 - Address configuration models 327 In IPv6 networks, there are two auto-configuration models for 328 address assignment after each host obtains a link-local address: 329 Stateless Address Auto-Configuration (SLAAC, [RFC4862]) by 330 Neighbor Discovery (ND, [RFC4861]) and stateful address 331 configuration by Dynamic Host Configuration Protocol for IPv6 332 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 may also support 333 the host-generated address model by assigning a prefix through 334 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 336 SLAAC is considered to support easy renumbering by broadcasting a 337 Router Advertisement message with a new prefix. DHCPv6 can also 338 trigger the renumbering process by sending unicast RECONFIGURE 339 messages, though it might cause a large number of interactions 340 between hosts and the DHCPv6 server. 342 This document has no preference between the SLAAC and DHCPv6 343 address configuration models. It is the network architects' job to 344 decide which configuration model is employed. But it should be 345 noticed that using DHCPv6 and SLAAC together within one network, 346 especially in one subnet, might cause operational issues. For 347 example, some hosts use DHCPv6 as the default configuration model 348 while some use ND. Then the hosts' address configuration model 349 depends on the policies of operating systems and cannot be 350 controlled by the network. Section 5.1 of 352 [I-D.ietf-6renum-gap-analysis] discusses more details on this 353 topic. So, in general, this document recommends using DHCPv6 or 354 SLAAC independently in different subnets. 356 However, since DHCPv6 is also used to configure many other network 357 parameters, there are ND and DHCPv6 co-existence scenarios. 358 Combinations of address configuration models might coexist within 359 a single enterprise network. [I-D.ietf-savi-mix] provides 360 recommendations to avoid collisions and to review collision 361 handling in such scenarios. 363 - DNS 365 Although the A6 DNS record model [RFC2874] was designed for easier 366 renumbering, it left many unsolved technical issues [RFC3364]. 367 Therefore, it has been moved to historic status [RFC6563] and 368 should not be used. 370 Often, a small site depends on its ISP's DNS system rather than 371 maintaining its own. When renumbering, this requires 372 administrative coordination between the site and its ISP. 374 It is recommended that the site have an automatic and systematic 375 procedure for updating/synchronizing its DNS records, including 376 both forward and reverse mapping. In order to simplify the 377 operational procedure, the network architect should combine the 378 forward and reverse DNS updates in a single procedure. A manual 379 on-demand updating model does not scale, and increases the chance 380 of errors. Either a database-driven mechanism, or Secure Dynamic 381 DNS Update [RFC3007], or both, could be used. 383 Dynamic DNS update can be provided by the DHCPv6 client or by the 384 server on behalf of individual hosts. [RFC4704] defined a DHCPv6 385 option to be used by DHCPv6 clients and servers to exchange 386 information about the client's FQDN and about who has the 387 responsibility for updating the DNS with the associated AAAA and 388 PTR (Pointer Record) RRs (Resource Records). For example, if a 389 client wants the server to update the FQDN-address mapping in the 390 DNS server, it can include the Client FQDN option with proper 391 settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and 392 REBIND message originated by the client. When DHCPv6 server gets 393 this option, it can use Secure Dynamic DNS update on behalf of the 394 client. This document suggests use of this FQDN option. However, 395 since it is a DHCPv6 option, only the DHCP-managed hosts can make 396 use of it. In SLAAC mode, hosts need either to use Secure Dynamic 397 DNS Update directly, or to register addresses on a registration 398 server. This could in fact be a DHCPv6 server (as described in 400 [I-D.ietf-dhc-addr-registration]); then the server would update 401 corresponding DNS records. 403 - Security 405 Any automatic renumbering scheme has a potential exposure to 406 hijacking. A malicious entity in the network could forge prefixes 407 to renumber the hosts, so proper network security mechanisms are 408 needed. Further details are in the Security Considerations below. 410 - Miscellaneous 412 A site or network should also avoid embedding addresses from other 413 sites or networks in its own configuration data. Instead, the 414 Fully-Qualified Domain Names should be used. Thus, connections can 415 be restored after renumbering events at other sites. This also 416 applies to host-based connectivity. 418 4.2. Considerations and Current Methods for the Preparation of 419 Renumbering 421 In ND, it is not possible to reduce a prefix's lifetime to below two 422 hours. So, renumbering should not be an unplanned sudden event. This 423 issue could only be avoided by early planning and preparation. 425 This section describes several recommendations for the preparation of 426 enterprise renumbering event. By adopting these recommendations, a 427 site could be renumbered more easily. However, these recommendations 428 might increase the daily traffic, server load, or burden of network 429 operation. Therefore, only those networks that are expected to be 430 renumbered soon or very frequently should adopt these 431 recommendations, with balanced consideration between daily cost and 432 renumbering cost. 434 - Reduce the address preferred time or valid time or both. 436 Long-lifetime addresses might cause issues for renumbering events. 437 Particularly, some offline hosts might reconnect using these 438 addresses after renumbering events. Shorter preferred lifetimes 439 with relatively long valid lifetimes may allow short transition 440 periods for renumbering events and avoid frequent address 441 renewals. 443 - Reduce the DNS record TTL on the local DNS server. 445 The DNS AAAA resource record TTL on the local DNS server should be 446 manipulated to ensure that stale addresses are not cached. 448 Recent research [BA2011] [JSBM2002] indicates that it is both 449 practical and reasonable for A, AAAA, and PTR records that belong 450 to leaf nodes of the DNS (i.e. not including the DNS root or DNS 451 top-level domains) to be configured with very short DNS TTL 452 values, not only during renumbering events, but also for longer- 453 term operation. 455 - Reduce the DNS configuration lifetime on the hosts. 457 Since the DNS server could be renumbered as well, the DNS 458 configuration lifetime on the hosts should also be reduced if 459 renumbering events are expected. In ND, the DNS configuration can 460 be done through reducing the lifetime value in RDNSS option 461 [RFC6106]. In DHCPv6, the DNS configuration option specified in 462 [RFC3646] doesn't provide a lifetime attribute, but we can reduce 463 the DHCPv6 client lease time to achieve similar effect. 465 - Identify long-living sessions 467 Any applications which maintain very long transport connections 468 (hours or days) should be identified in advance, if possible. Such 469 applications will need special handling during renumbering, so it 470 is important to know that they exist. 472 4.3. Considerations and Current Methods during Renumbering Operation 474 Renumbering events are not instantaneous events. Normally, there is a 475 transition period, in which both the old prefix and the new prefix 476 are used in the site. Better network design and management, better 477 pre-preparation and longer transition period are helpful to reduce 478 the issues during renumbering operation. 480 - Within/without a flag day 482 As is described in [RFC4192], "a 'flag day' is a procedure in 483 which the network, or a part of it, is changed during a planned 484 outage, or suddenly, causing an outage while the network 485 recovers." 487 If renumbering event is processed within a flag day, the network 488 service/connectivity will be unavailable for a period until the 489 renumbering event is completed. It is efficient and provides 490 convenience for network operation and management. But network 491 outage is usually unacceptable for end users and enterprises. A 492 renumbering procedure without a flag day provides smooth address 493 switching, but much more operational complexity and difficulty is 494 introduced. 496 - Transition period 498 If renumbering transition period is longer than all address 499 lifetimes, after which the address leases expire, each host will 500 automatically pick up its new IP address. In this case, it would 501 be the DHCPv6 server or Router Advertisement itself that 502 automatically accomplishes client renumbering. 504 Address deprecation should be associated with the deprecation of 505 associated DNS records. The DNS records should be deprecated as 506 early as possible, before the addresses themselves. 508 - Network initiative enforced renumbering 510 If the network has to enforce renumbering before address leases 511 expire, the network should initiate DHCPv6 RECONFIGURE messages. 512 For some operating systems such as Windows 7, if the hosts receive 513 RA messages with ManagedFlag=0, they'll release the DHCPv6 514 addresses and do SLAAC according to the prefix information in the 515 RA messages, so this could be another enforcement method for some 516 specific scenarios. 518 - Impact to branch/main sites 520 Renumbering in main/branch site might cause impact on branch/main 521 site communication. The routes, ingress filtering of site's 522 gateways, and DNS might need to be updated. This needs careful 523 planning and organizing. 525 - DNS record update and DNS configuration on hosts 527 DNS records on the local DNS server should be updated if hosts are 528 renumbered. If the site depends on ISP's DNS system, it should 529 report the new host's DNS records to its ISP. During the 530 transition period, both old and new DNS records are valid. If the 531 TTLs of DNS records are shorter than the transition period, an 532 administrative operation might not be necessary. 534 DNS configuration on hosts should be updated if local recursive 535 DNS servers are renumbered. During the transition period, both old 536 and new DNS server addresses might co-exist on the hosts. If the 537 lifetime of DNS configuration is shorter than the transition 538 period, name resolving failure may be reduced to minimum. 540 - Tunnel concentrator renumbering 541 A tunnel concentrator itself might be renumbered. This change 542 should be reconfigured in relevant hosts or routers, unless the 543 configuration of tunnel concentrator was based on FQDN. 545 For IPSec, IKEv2 [RFC5996] defines the ID_FQDN Identification 546 Type, which could be used to identify an IPsec VPN concentrator 547 associated with a site's domain name. For current practice, the 548 community needs to change its bad habit of using IPsec in an 549 address-oriented way, and renumbering is one of the main reasons 550 for that. 552 - Connectivity session survivability 554 During the renumbering operations, connectivity sessions in IP 555 layer would break if the old address is deprecated before the 556 session ends. However, the upper layer sessions can survive by 557 using session survivability technologies, such as SHIM6 [RFC5533]. 558 As mentioned above, some long-living applications may need to be 559 handled specially. 561 - Verification of success 563 The renumbering operation should end with a thorough check that 564 all network elements and hosts are using only the new prefixes and 565 that network management and monitoring systems themselves are 566 still operating correctly. A database clean-up may also be needed. 568 5. Security Considerations 570 Any automatic renumbering scheme has a potential exposure to 571 hijacking by an insider attack. For attacks on ND, Secure Neighbor 572 Discovery (SEND) [RFC3971] is a possible solution, but it is complex 573 and there is almost no real deployment at the time of writing. 574 Compared to the non-trivial deployment of SEND, RA Guard [RFC6105] is 575 a lightweight alternative, which focuses on preventing rogue router 576 advertisements in a network. However, it was also not widely deployed 577 at the time when this memo was published. 579 For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 580 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages 581 [RFC3315] could be utilized. But these security mechanisms also have 582 not been verified by widespread deployment at the time of writing. 584 A site that is listed by IP address in a black list can escape that 585 list by renumbering itself. However, the new prefix might be back on 586 a black list rather soon, if the root cause for being added to such a 587 list is not corrected. In practice, the cost of renumbering will be 588 typically much larger than the cost of getting off the black list. 590 Dynamic DNS update might bring risk of DoS attack to the DNS server. 591 So along with the update authentication, session filtering/limitation 592 might also be needed. 594 The "make-before-break" approach of [RFC4192] requires the routers 595 keep advertising the old prefixes for some time. But if the ISP 596 changes the prefixes very frequently, the co-existence of old and new 597 prefixes might cause potential risk to the enterprise routing system, 598 since the old address relevant route path might already invalid and 599 the routing system just doesn't know it. However, normally enterprise 600 scenarios don't involve the extreme situation. 602 6. IANA Considerations 604 This draft does not request any IANA action. 606 7. Acknowledgements 608 This work is inspired by RFC5887, so thank for RFC 5887 authors, 609 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 610 in by documents from Tim Chown and Fred Baker. The authors also want 611 to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald 612 Bonica, other 6renum members, and several reviewers for valuable 613 comments. 615 8. References 617 8.1. Normative References 619 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 620 Location Protocol, Version 2", RFC 2608, June 1999. 622 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 623 Update", RFC 3007, November 2000. 625 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 626 M. Carney, "Dynamic Host Configuration Protocol for IPv6 627 (DHCPv6)", RFC 3315, July 2003. 629 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 630 Host Configuration Protocol (DHCP) version 6", RFC 3633, 631 December 2003. 633 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 634 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 635 December 2003. 637 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 638 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 640 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", 641 RFC 4057, June 2005. 643 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 644 Addresses", RFC 4193, October 2005. 646 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 647 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 648 RFC 4706, October 2006. 650 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 651 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 652 September 2007. 654 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 655 Address Autoconfiguration", RFC 4862, September 2007. 657 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 658 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 659 September 2010. 661 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 662 "IPv6 Router Advertisement Option for DNS Configuration", 663 RFC 6106, November 2011. 665 8.2. Informative References 667 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 668 IPv6 Address Aggregation and Renumbering", RFC 2874, July 669 2000. 671 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 672 for Internet Protocol version 6 (IPv6)", RFC 3364, August 673 2002. 675 [RFC4116] J. Abley, K. Lindqvist, E. Davies, B. Black, and V. Gill, 676 "IPv4 Multihoming Practices and Limitations", RFC 4116, 677 July 2005. 679 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 680 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 681 September 2005. 683 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 684 Shim Protocol for IPv6", RFC 5533, June 2009. 686 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 687 Still Needs Work", RFC 5887, May 2010. 689 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 690 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 691 February 2011. 693 [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 694 Historic Status", RFC 6563, May 2012. 696 [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 697 Exclude Option for DHCPv6-based Prefix Delegation", RFC 698 6603, May 2012. 700 [I-D.ietf-dhc-secure-dhcpv6] 701 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 702 in progress, March 2012. 704 [I-D.ietf-dhc-host-gen-id] 705 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 706 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 707 August, 2012. 709 [I-D.ietf-savi-mix] 710 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 711 for Mixed Address Assignment Methods Scenario", working in 712 progress, April 2012. 714 [I-D.ietf-dhc-addr-registration] 715 Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration 716 Solution Using DHCPv6", working in progress, May 2012. 718 [I-D.ietf-6renum-gap-analysis] 719 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 720 Analysis", working in progress, August 2012. 722 [I-D.ietf-6renum-static-problem] 723 Carpenter, B. and S. Jiang., "Problem Statement for 724 Renumbering IPv6 Hosts with Static Addresses", working in 725 progress, August 2012. 727 [I-D.cheshire-dnsext-dns-sd] 728 Cheshire, S. and M. Krochmal, "DNS-Based Service 729 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 730 progress), December 2011. 732 [I-D.cheshire-dnsext-multicastdns] 733 Cheshire, S. and M. Krochmal, "Multicast DNS", draft- 734 cheshire-dnsext-multicastdns-15 (work in progress), 735 December 2011. 737 [BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. 738 14th IEEE Global Internet Symposium (GI2011), Shanghai, 739 China. 15 April 2011. 741 [JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS 742 Performance and the Effectiveness of Caching", IEEE/ACM 743 Transactions on Networking, 10(5):589-603, 2002. 745 Author's Addresses 747 Sheng Jiang 748 Huawei Technologies Co., Ltd 749 Q14, Huawei Campus 750 No.156 Beiqing Rd. 751 Hai-Dian District, Beijing 100095 752 P.R. China 754 EMail: jiangsheng@huawei.com 756 Bing Liu 757 Huawei Technologies Co., Ltd 758 Q14, Huawei Campus 759 No.156 Beiqing Rd. 760 Hai-Dian District, Beijing 100095 761 P.R. China 763 EMail: leo.liubing@huawei.com 765 Brian Carpenter 766 Department of Computer Science 767 University of Auckland 768 PB 92019 769 Auckland, 1142 770 New Zealand 772 EMail: brian.e.carpenter@gmail.com