idnits 2.17.1 draft-ietf-6renum-enterprise-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2012) is 4460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.liu-6renum-gap-analysis' is mentioned on line 516, but not defined == Unused Reference: 'I-D.ietf-dhc-pd-exclude' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6renum-gap-analysis' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'I-D.carpenter-6renum-static-problem' is defined on line 712, but no explicit reference was found in the text ** 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) -- No information found for draft-ietf-6renum-gap-analysis - is the name correct? -- No information found for draft-carpenter-6renum-static-problem - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). 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: August 9, 2012 B. Carpenter 5 University of Auckland 6 February 6, 2012 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-ietf-6renum-enterprise-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 9, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document analyzes enterprise renumbering events and describes 46 the best current practice among the existing renumbering mechanisms. 47 According to the different stages of renumbering events, 48 considerations and best current practices are described in three 49 categories: during network design, for preparation of renumbering, 50 and during a renumbering operation. A gap inventory is listed at the 51 end of this document. 53 Table of Contents 55 1. Introduction ................................................. 3 56 2. Enterprise Network Illustration for Renumbering .............. 3 57 3. Enterprise Network Renumbering Scenario Categories ........... 4 58 3.1. Renumbering caused by External Network Factors........... 5 59 3.2. Renumbering caused by Internal Network Factors........... 5 60 4. Network Renumbering Considerations and Best Current Practise . 5 61 4.1. Considerations and Best Current Practice during Network 62 Design ...................................................... .6 63 4.2. Considerations and Best Current Practice for the Preparation 64 of Renumbering ............................................... 9 65 4.3. Considerations and Best Current Practice during Renumbering 66 Operation ................................................... 10 67 5. Gap Inventory ............................................... 12 68 6. Security Considerations ..................................... 13 69 7. IANA Considerations ......................................... 13 70 8. Acknowledgements ............................................ 13 71 9. Change Log [RFC Editor please remove] ....................... 14 72 10. References ................................................. 14 73 10.1. Normative References .................................. 14 74 10.2. Informative References ................................ 15 75 Author's Addresses ............................................. 17 77 1. Introduction 79 IPv6 site renumbering is considered difficult. Network managers 80 currently prefer to use Provider Independent (PI) addressing for IPv6 81 to attempt to minimize the need for future renumbering. However, 82 widespread use of PI may create very serious BGP4 scaling problems 83 and PI space is not always available for enterprise according to the 84 RIR (Regional Internet Registry) policies. It is thus desirable to 85 develop tools and practices that may make renumbering a simpler 86 process to reduce demand for IPv6 PI space. In any case, renumbering 87 may be necessary for other reasons. 89 This document undertakes scenario descriptions, including 90 documentation of current capabilities and existing BCPs, for 91 enterprise networks. It takes [RFC5887] and other relevant documents 92 as the primary input. 94 The IPv4 and IPv6 are logically separated from the perspective of 95 renumbering, regardless of overlapping of the IPv4/IPv6 networks or 96 devices. This document focuses on IPv6 only, by leaving IPv4 out of 97 scope. Dual-stack network or IPv4/IPv6 transition scenarios are out 98 of scope, too. 100 This document focuses on enterprise network renumbering, though most 101 of the analysis is also applicable to ISP network renumbering. 102 Renumbering in home networks is considered out of scope, though it 103 may also benefit from the analysis in this document. 105 The concept of enterprise network and a typical network illustration 106 are introduced first. Then, according to the different stages of 107 renumbering events, considerations and best current practices are 108 described in three categories: during network design, for preparation 109 of renumbering, and during renumbering operation. A gap inventory is 110 listed at the end of this document. 112 2. Enterprise Network Illustration for Renumbering 114 An Enterprise Network as defined in [RFC4057] is: a network that has 115 multiple internal links, one or more router connections to one or 116 more Providers, and is actively managed by a network operations 117 entity. 119 The enterprise network architecture is illustrated in the figure 120 below. Those entities relevant to renumbering are highlighted. 122 Address reconfiguration is fulfilled either by DHCPv6 or ND 123 protocols. During the renumbering event, the DNS records need to be 124 synchronized while routing tables, ACLs and IP filtering tables in 125 various gateways also need to be updated, too. 127 Static address issue is described in a dedicated draft [I- 128 D.carpenter-6renum-static-problem]. (Editor's note: some major 129 conclusions would be included in this document if we can get 130 consensus on the discussion of the static address problem.) 132 Uplink 1 Uplink 2 133 | | 134 +---+---+ +---+---+ 135 +---- |Gateway| --------- |Gateway| -----+ 136 | +-------+ +-------+ | 137 | Enterprise Network | 138 | +------+ +------+ +------+ | 139 | | APP | |DHCPv6| | DNS | | 140 | |Server| |Server| +Server+ | 141 | +---+--+ +---+--+ +--+---+ | 142 | | | | | 143 | ---+--+---------+------+---+- | 144 | | | | 145 | +--+---+ +---+--+ | 146 | |Router| |Router| | 147 | +--+---+ +---+--+ | 148 | | | | 149 | -+---+----+-------+---+--+- | 150 | | | | | | 151 | +-+--+ +--+-+ +--+-+ +-+--+ | 152 | |Host| |Host| |Host| |Host| | 153 | +----+ +----+ +----+ +----+ | 154 +----------------------------------------+ 155 Figure 1 Enterprise network illustration 157 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 158 stack in which a logical IPv6 plane is independent from IPv4. The 159 complicated IPv4/IPv6 co-existence scenarios are out of scope. 161 This document focuses on the unicast addresses; site-local, link- 162 local, multicast and anycast addresses are out of scope. 164 3. Enterprise Network Renumbering Scenario Categories 166 In this section, we divide enterprise network renumbering scenarios 167 into two categories defined by external and internal network factors, 168 which require renumbering for different reasons. 170 3.1. Renumbering caused by External Network Factors 172 The most influential external network factor is the uplink ISP. 174 o The enterprise network switches to a new ISP. Of course, the 175 prefixes received from different ISPs are different. This is the 176 most common scenario. 178 Whether there is an overlap time between the old and new ISPs 179 would also influence the possibility whether the enterprise can 180 fulfill renumbering without a flag day [RFC4192]. 182 o The renumbering event may be initiated by receiving new prefixes 183 from the same uplink. This might happen if the enterprise network 184 is switched to a different location within the network topology of 185 the same ISP due to various considerations, such as commercial, 186 performance or services reasons, etc. Alternatively, the ISP 187 itself might be renumbered due to topology changes or migration to 188 a different or additional prefix. These ISP renumbering events 189 would initiate enterprise network renumbering events, of course. 191 o The enterprise network adds new uplink(s) for multihoming 192 purposes. This may not a typical renumbering because the original 193 addresses will not be changed. However, initial numbering may be 194 considered as a special renumbering event. The enterprise network 195 removes uplink(s) or old prefixes. 197 3.2. Renumbering caused by Internal Network Factors 199 o As companies split, merge, grow, relocate or reorganize, the 200 enterprise network architectures may need to be re-built. This 201 will trigger the internal renumbering. 203 o The enterprise network may proactively adopt a new address scheme, 204 for example by switching to a new transition mechanism or stage of 205 a transition plan. 207 o The enterprise network may reorganize its topology or subnets. 209 4. Network Renumbering Considerations and Best Current Practices 211 In order to carry out renumbering in an enterprise network, 212 systematic planning and administrative preparation are needed. 213 Carefully planning and preparation could make the renumbering process 214 smoother. 216 This section tries to give the recommended solutions or strategies 217 for the enterprise renumbering, chosen among existing mechanisms. 218 There are known gaps analyzed by [I-D.liu-6renum-gap-analysis]. If 219 these gaps are filled in the future, the enterprise renumbering may 220 be processed more automatically, with fewer issues. 222 4.1. Considerations and Best Current Practices during Network Design 224 This section describes the consideration or issues relevant to 225 renumbering that a network architect should carefully plan when 226 building or designing a new network. 228 - Prefix Delegation 230 In a large or a multi-site enterprise network, the prefix should 231 be carefully managed, particularly during renumbering events. 232 Prefix information needs to be delegated from router to router. 233 The DHCPv6 Prefix Delegation options [RFC3633] [I-D.ietf-dhc-pd- 234 exclude] provide a mechanism for automated delegation of IPv6 235 prefixes. DHCPv6 PD options may also be used between the 236 enterprise routers and their upstream ISPs. 238 - Usage of FQDN 240 In general, Fully-Qualified Domain Names (FQDNs) are recommended 241 to be used to configure network connectivity, such as tunnels, 242 whenever possible. The capability to use FQDNs as endpoint names 243 has been standardized in several RFCs, such as [RFC5996], although 244 many system/network administrators do not realize that it is there 245 and works well as a way to avoid manual modification during 246 renumbering. 248 Service Location Protocol [RFC2608] and multicast DNS with SRV 249 records for service discovery can reduce the number of places that 250 IP addresses need to be configured. But it should be noted that 251 multicast DNS is link-local only. 253 - Address Types 255 This document focuses on the dynamically-configured global unicast 256 addresses in enterprise networks. They are the targets of 257 renumbering events. 259 Manual-configured addresses are not scalable in medium to large 260 sites, hence are out of scope. Manual-configured addresses/hosts 261 should be avoided as much as possible. 263 Unique Local Addresses (ULA, [RFC4193]) may be used for local 264 communications, usually inside of enterprise networks. They can be 265 sufficient for any host that is accessible only inside the 266 enterprise network and has no need for external communication 267 [RFC4864]. Normally, they do not need to be changed during a 268 global prefix renumbering event. However, they may need to be 269 renumbered in some rare scenarios, quite separate from the global 270 prefix renumbering. 272 - Address configuration models 274 In IPv6 networks, there are two auto-configuration models for 275 address assignment: Stateless Address Auto-Configuration (SLAAC) 276 by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful 277 address configuration by Dynamic Host Configuration Protocol for 278 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 279 support host-generated address model by assigning a prefix through 280 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 282 ND is considered easier to renumber by broadcasting a Router 283 Advertisement message with a new prefix. DHCPv6 can also trigger 284 the renumbering process by sending unicast RECONFIGURE messages, 285 though it may cause a large number of interactions between hosts 286 and DHCPv6 server. 288 This document has no preference between ND and DHCPv6 address 289 configuration models. It is network architects' job to decide 290 which configuration model is employed. But it should be noticed 291 that using DHCPv6 and ND together within one network, especially 292 in one subnet, may cause operational issues. For example, some 293 hosts use DHCPv6 as the default configuration model while some use 294 ND. Then the hosts' address configuration model depends on the 295 policies of operating systems and cannot be controlled by the 296 network. Section 5.1 of [I-D.liu-6renum-gap-analysis] discusses 297 more details on this topic. So, in general, this document 298 recommends using DHCPv6/SLAAC independently in different subnets. 300 However, since DHCPv6 is also used to configure many other network 301 parameters, there are ND and DHCPv6 co-existence scenarios. 302 Combinations of address configuration models may coexist within a 303 single enterprise network. [I-D.ietf-savi-mix] provides 304 recommendations to avoid collisions and to review collision 305 handling in such scenarios. 307 - DNS 308 It is recommended that the site have an automatic and systematic 309 procedure for updating/synchronising its DNS records, including 310 both forward and reverse mapping [RFC2874]. A manual on-demand 311 updating model does not scale, and increases the chance of errors. 313 Although the A6 DNS record model [RFC2874] was designed for easier 314 renumbering, it has a lot of unsolved technical issues [RFC3364]. 315 Therefore, it has been moved to experimental status [RFC3363], and 316 will move to historic status by [I-D.jiang-dnsext-a6-to-historic] 317 (It is currently in RFC Editor Queue already). So A6 is not 318 recommended. 320 In order to simplify the operation procedure, the network 321 architect should combine the forward and reverse DNS updates in a 322 single procedure. 324 Often, a small site depends on its ISP's DNS system rather than 325 maintaining its own. When renumbering, this requires 326 administrative coordination between the site and its ISP. 328 The DNS synchronization may be completed through the Secure DNS 329 Dynamic Update [RFC3007]. Normally, the dynamic DNS update is 330 achieved by DHCPv6 server on behalf of individual hosts. [RFC4704] 331 defined a DHCPv6 option to be used by DHCPv6 clients and servers 332 to exchange information about the client's FQDN and about who has 333 the responsibility for updating the DNS with the associated AAAA 334 and PTR RRs. For example, if a client wants the server to update 335 the FQDN-address mapping in the DNS server, it can include the 336 Client FQDN option with proper settings in the SOLICIT with Rapid 337 Commit, REQUEST, RENEW, and REBIND message originated by the 338 client. When DHCPv6 server gets this option, it can use the 339 dynamic DNS update on behalf of the client. In this document, we 340 promote to support this FQDN option. But since it's a DHCPv6 341 option, it implies that only the DHCP-managed networks are 342 suitable for this operation. In a model including SLAAC, host 343 addresses may be registered on an address registration server, 344 which could in fact be a DHCPv6 server; then the server would 345 update corresponding DNS records. 347 - Security 349 Any automatic renumbering scheme has a potential exposure to 350 hijacking. Malicious entity in the network can forge prefixes to 351 renumber the hosts. So proper network security mechanisms are 352 needed. 354 For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible 355 solution, but it is complex and there's almost no real deployment 356 so far. Comparing the non-trivial deployment of SEND, RA guard 357 [RFC6105] is a light-weight alternative, however, it also hasn't 358 been widely deployed since it hasn't been published for long. 360 For DHCPv6, there are built-in secure mechanisms (like Secure 361 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 362 messages [RFC3315] could be utilized. But these security 363 mechanisms also haven't been verified by wide real deployment. 365 - Miscellaneous 367 A site or network should also avoid embedding addresses from other 368 sites or networks in its own configuration data. Instead, the 369 Fully-Qualified Domain Names should be used. Thus, these 370 connections can survive after renumbering events at other sites. 371 This also applies to host-based connectivities. 373 4.2. Considerations and Best Current Practices for the Preparation of 374 Renumbering 376 In ND, it is not possible to reduce a prefix's lifetime to below two 377 hours. So, renumbering should not be an unplanned sudden event. This 378 issue could only be avoided by early planning and preparation. 380 This section describes several recommendations for the preparation of 381 enterprise renumbering event. By adopting these recommendations, a 382 site could be renumbered more easily. However, these recommendations 383 are not cost free. They might increase the daily burden of network 384 operation. Therefore, only those networks that are expected to be 385 renumbered soon or very frequently should adopt these recommendations, 386 with balanced consideration between daily cost and renumbering cost. 388 - Reduce the address preferred time or valid time or both. 390 Long-lifetime addresses may cause issues for renumbering events. 391 Particularly, some offline hosts may reconnect using these 392 addresses after renumbering events. Shorter preferred lifetimes 393 with relatively long valid lifetimes may allow short transition 394 periods for renumbering events and avoid frequent address 395 renewals. 397 - Reduce the DNS record TTL on the local DNS server. 399 The DNS AAAA resource record TTL on the local DNS server should be 400 manipulated to ensure that stale addresses are not cached. 402 - Reduce the DNS configuration lifetime on the hosts. 404 Since the DNS server could be renumbered as well, the DNS 405 configuration lifetime on the hosts should also be reduced if 406 renumbering events are expected. The DNS configuration can be done 407 through either ND [RFC6106] or DHCPv6 [RFC3646]. 409 - Identify long-living sessions 411 Any applications which maintain very long transport connections 412 (hours or days) should be identified in advance, if possible. Such 413 applications will need special handling during renumbering, so it 414 is important to know that they exist. 416 4.3. Considerations and Best Current Practices during Renumbering 417 Operation 419 Renumbering events are not instantaneous events. Normally, there is a 420 transition period, in which both the old prefix and the new prefix 421 are used in the site. Better network design and management, better 422 pre-preparation and longer transition period are helpful to reduce 423 the issues during renumbering operation. 425 - Within/without a flag day 427 As is described in [RFC4192], "a 'flag day' is a procedure in 428 which the network, or a part of it, is changed during a planned 429 outage, or suddenly, causing an outage while the network 430 recovers." 432 If renumbering event is processed within a flag day, the network 433 service/connectivity will be unavailable for a period until the 434 renumbering event is completed. It is efficient and provides 435 convenience for network operation and management. But network 436 outage is usually unacceptable for end users and enterprises. A 437 renumbering procedure without a flag day provides smooth address 438 switching, but much more operational complexity and difficulty is 439 introduced. 441 - Transition period 443 If renumbering transition period is longer than all address 444 lifetimes, after which the address leases expire, each host will 445 automatically pick up its new IP address. In this case, it would 446 be the DHCPv6 server or Router Advertisement itself that 447 automatically accomplishes client renumbering. 449 Address deprecation should be associated with the deprecation of 450 associated DNS records. The DNS records should be deprecated as 451 early as possible, before the addresses themselves. 453 - Network initiative enforced renumbering 455 If the network has to enforce renumbering before address leases 456 expire, the network should initiate enforcement messages, either 457 in Router Advertisement messages or DHCPv6 RECONFIGURE messages. 459 - Impact to branch/main sites 461 Renumbering in main/branch site may cause impact on branch/main 462 site communication. The routes, ingress filtering of site's 463 gateways, and DNS may need to be updated. This needs careful 464 planning and organizing. 466 - DNS record update and DNS configuration on hosts 468 DNS records on the local DNS server should be updated if hosts are 469 renumbered. If the site depends on ISP's DNS system, it should 470 report the new host's DNS records to its ISP. During the 471 transition period, both old and new DNS records are valid. If the 472 TTLs of DNS records are shorter than the transition period, an 473 administrative operation may not be necessary. 475 DNS configuration on hosts should be updated if local recursive 476 DNS servers are renumbered. During the transition period, both old 477 and new DNS server addresses may co-exist on the hosts. If the 478 lifetime of DNS configuration is shorter than the transition 479 period, name resolving failure may be reduced to minimum. A 480 notification mechanism may be needed to indicate to the hosts that 481 a renumbering event of local recursive DNS happens or is going to 482 take place. 484 - Router awareness 486 In a site with multiple border routers, all border routers should 487 be aware of partial renumbering in order to correctly handle 488 inbound packets. Internal forwarding tables need to be updated. 490 - Border filtering 492 In a multihomed site, an egress router to ISP A could normally 493 filter packets with source addresses from other ISPs. The egress 494 router connecting to ISP A should be notified if the egress router 495 connecting to ISP B initiates a renumbering event in order to 496 properly update its filter function. 498 - Tunnel concentrator renumbering 500 A tunnel concentrator itself might be renumbered. This change 501 should be reconfigured in relevant hosts or routers, unless the 502 configuration of tunnel concentrator was based on FQDN. 504 - Connectivity session survivability 506 During the renumbering operations, connectivity sessions in IP 507 layer would break if the old address is deprecated before the 508 session ends. However, the upper layer sessions may survive by 509 using session survivability technologies, such as SHIM6 [RFC5533]. 510 As mentioned above, some long-living applications may need to be 511 handled specially. 513 5. Gap Inventory 515 This section lists a few issues that still appear to remain 516 unsolvable (also see [I-D.liu-6renum-gap-analysis]). Some of them may 517 be inherently unsolvable. 519 - Some environments like embedded systems might not use DHCPv6 or 520 SLAAC and even configuration scripts might not be an option. 521 This creates special problems that no general-purpose solution 522 is likely to address. 524 - TCP and UDP flows can't survive a renumbering event at either 525 end. 527 - The embedding of IPv6 unicast addresses into multicast 528 addresses and the embedded-RP (Rendezvous Point) [RFC3956] will 529 cause issues when renumbering. 531 - Changing the unicast source address of a multicast sender might 532 also be an issue for receivers. 534 - When a renumbering event takes place, entries in the state 535 table of tunnel concentrator that happen to contain the old 536 addresses will become invalid and will eventually time out. 537 However, this can be considered as harmless though it takes 538 resources on these devices for a while. 540 - A site that is listed in an IP black list can escape that list 541 by renumbering itself. The site itself of course will not 542 report its renumbering and the black list may not be able to 543 monitor or discover the renumbering event. 545 - Multihomed sites, using SLAAC for one address prefix and DHCPv6 546 for another, would clearly create a risk of inconsistent host 547 behaviour and operational confusion. 549 6. Security Considerations 551 As noted, a site that is listed by IP address in a black list can 552 escape that list by renumbering itself. 554 Any automatic renumbering scheme has a potential exposure to 555 hijacking. Proper network security mechanisms are needed. Although 556 there are existing security mechanisms such as SEND, RA guard, secure 557 DHCPv6 etc., they haven't been widely deployed and haven't been 558 verified whether they are suitable for ensuring security while not 559 bringing too much operational complexity and cost. 561 Dynamic DNS update may bring risk of DoS attack to the DNS server. So 562 along with the update authentication, session filtering/limitation 563 may also be needed. 565 The "make-before-break" approach of [RFC4192] requires the routers 566 keep advertising the old prefixes for some time. But if the ISP 567 changes the prefixes very frequently, the co-existence of old and new 568 prefixes may cause potential risk to the enterprise routing system. 569 However, enterprise scenarios may not involve the extreme situation; 570 this issue needs to be identified in the future. 572 The security configuration updates will need to be made in two stages 573 (immediately before and immediately after the event). 575 7. IANA Considerations 577 This draft does not request any IANA action. 579 8. Acknowledgements 581 This work is illuminated by RFC 5887, so thank for RFC 5887 authors, 582 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 583 in by documents from Tim Chown and Fred Baker. The authors also want 584 to thank Wesley George, Olivier Bonaventure and other 6renum members 585 for valuable comments. 587 9. Change Log [RFC Editor please remove] 589 draft-jiang-6renum-enterprise-00, original version, 2011-07-01 591 draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail 592 list discussions, 2011-10-09 594 draft-jiang-6renum-enterprise-02, Update according to IETF82 595 discussions, 2011-12-06 597 draft-ietf-6renum-enterprise-00, Update according to mail list 598 discussions, 2012-02-06 600 10. References 602 10.1. Normative References 604 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 605 Location Protocol, Version 2", RFC 2608, June 1999. 607 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 608 Update", RFC 3007, November 2000. 610 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 611 M. Carney, "Dynamic Host Configuration Protocol for IPv6 612 (DHCPv6)", RFC 3315, July 2003. 614 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 615 Host Configuration Protocol (DHCP) version 6", RFC 3633, 616 December 2003. 618 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 619 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 620 December 2003. 622 [RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous 623 Point (RP) Address in an IPv6 Multicast Address", RFC 3956, 624 November 2004 626 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 627 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 629 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 630 Addresses", RFC 4193, October 2005. 632 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 633 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 634 RFC 4706, October 2006. 636 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 637 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 638 September 2007. 640 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 641 Address Autoconfiguration", RFC 4862, September 2007. 643 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 644 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 645 September 2010. 647 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 648 "IPv6 Router Advertisement Option for DNS Configuration", 649 RFC 6106, November 2011. 651 10.2. Informative References 653 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 654 IPv6 Address Aggregation and Renumbering", RFC 2874, July 655 2000. 657 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 658 "Representing Internet Protocol version 6 (IPv6) Addresses 659 in the Domain Name System (DNS)", RFC 3363, August 2002. 661 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 662 for Internet Protocol version 6 (IPv6)", RFC 3364, August 663 2002. 665 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 666 4057, June 2005. 668 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 669 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 670 September 2005. 672 [RFC4864] Van de Velde, G., T. Hain, R. Droms, B. Carpenter, E. Klein, 673 Local Network Protection for IPv6", RFC 4864, May 2007. 675 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 676 Shim Protocol for IPv6", RFC 5533, June 2009. 678 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 679 Still Needs Work", RFC 5887, May 2010. 681 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 682 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 683 February 2011. 685 [I-D.ietf-dhc-secure-dhcpv6] 686 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 687 in progress. 689 [I-D.ietf-dhc-host-gen-id] 690 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 691 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 692 April, 2011. 694 [I-D.ietf-savi-mix] 695 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 696 for Mixed Address Assignment Methods Scenario", working in 697 progress. 699 [I-D.ietf-dhc-pd-exclude] 700 J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 701 Exclude Option for DHCPv6-based Prefix Delegation", working 702 in progress. 704 [I-D.ietf-6renum-gap-analysis] 705 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 706 Analysis", working in progress. 708 [I-D.jiang-dnsext-a6-to-historic] 709 Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 710 Historic Status", working in progress. 712 [I-D.carpenter-6renum-static-problem] 713 Carpenter, B. and S. Jiang., "Problem Statement for 714 Renumbering IPv6 Hosts with Static Addresses", working in 715 progress. 717 Author's Addresses 719 Sheng Jiang 720 Huawei Technologies Co., Ltd 721 Huawei Q14 Building, No.156 Beiqing Rd., 722 Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District 723 EMail: jiangsheng@huawei.com 725 Bing Liu 726 Huawei Technologies Co., Ltd 727 Huawei Q14 Building, No.156 Beiqing Rd., 728 Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District 729 EMail: leo.liubing@huawei.com 731 Brian Carpenter 732 Department of Computer Science 733 University of Auckland 734 PB 92019 735 Auckland, 1142 736 New Zealand 737 EMail: brian.e.carpenter@gmail.com