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