idnits 2.17.1 draft-ietf-6renum-enterprise-01.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 (July 16, 2012) is 4299 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 216, but not defined == Missing Reference: 'Bing' is mentioned on line 510, but not defined == Unused Reference: 'RFC3956' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC4864' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-pd-exclude' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-addr-registration' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'I-D.carpenter-6renum-static-problem' is defined on line 693, 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-dhc-addr-registration - is the name correct? -- 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 (~~), 8 warnings (==), 4 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: January 14, 2013 B. Carpenter 5 University of Auckland 6 July 16, 2012 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-ietf-6renum-enterprise-01.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 January 14, 2013. 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. 52 Table of Contents 54 1. Introduction ................................................. 3 55 2. Enterprise Network Illustration for Renumbering .............. 3 56 3. Enterprise Network Renumbering Scenario Categories ........... 4 57 3.1. Renumbering caused by External Network Factors........... 5 58 3.2. Renumbering caused by Internal Network Factors........... 5 59 4. Network Renumbering Considerations and Best Current Practices. 5 60 4.1. Considerations and Best Current Practices during Network 61 Design ....................................................... 6 62 4.2. Considerations and Best Current Practices for the Preparation 63 of Renumbering ............................................... 9 64 4.3. Considerations and Best Current Practices during Renumbering 65 Operation ................................................... 10 66 5. Security Considerations ..................................... 12 67 6. IANA Considerations ......................................... 13 68 7. Acknowledgements ............................................ 13 69 8. Change Log [RFC Editor please remove] ....................... 13 70 9. References .................................................. 13 71 9.1. Normative References ................................... 13 72 9.2. Informative References ................................. 14 73 Author's Addresses ............................................. 16 75 1. Introduction 77 IPv6 site renumbering is considered difficult. Network managers 78 currently prefer to use Provider Independent (PI) addressing for IPv6 79 to attempt to minimize the need for future renumbering. However, 80 widespread use of PI may create very serious BGP4 scaling problems 81 and PI space is not always available for enterprise according to the 82 RIR (Regional Internet Registry) policies. It is thus desirable to 83 develop tools and practices that may make renumbering a simpler 84 process to reduce demand for IPv6 PI space. In any case, renumbering 85 may be necessary for other reasons. 87 This document undertakes scenario descriptions, including 88 documentation of current capabilities and existing BCPs, for 89 enterprise networks. It takes [RFC5887] and other relevant documents 90 as the primary input. 92 The IPv4 and IPv6 are logically separated from the perspective of 93 renumbering, regardless of overlapping of the IPv4/IPv6 networks or 94 devices. This document focuses on IPv6 only, by leaving IPv4 out of 95 scope. Dual-stack network or IPv4/IPv6 transition scenarios are out 96 of scope, too. 98 This document focuses on enterprise network renumbering, though most 99 of the analysis is also applicable to ISP network renumbering. 100 Renumbering in home networks is considered out of scope, though it 101 may also benefit from the analysis in this document. 103 The concept of enterprise network and a typical network illustration 104 are introduced first. Then, according to the different stages of 105 renumbering events, considerations and best current practices are 106 described in three categories: during network design, for preparation 107 of renumbering, and during renumbering operation. A gap inventory is 108 listed at the end of this document. 110 2. Enterprise Network Illustration for Renumbering 112 An Enterprise Network as defined in [RFC4057] is: a network that has 113 multiple internal links, one or more router connections to one or 114 more Providers, and is actively managed by a network operations 115 entity. 117 The enterprise network architecture is illustrated in the figure 118 below. Those entities relevant to renumbering are highlighted. 120 Address reconfiguration is fulfilled either by DHCPv6 or ND 121 protocols. During the renumbering event, the DNS records need to be 122 synchronized while routing tables, ACLs and IP filtering tables in 123 various gateways also need to be updated, too. 125 Static address issue is described in a dedicated draft [I- 126 D.carpenter-6renum-static-problem]. (Editor's note: some major 127 conclusions would be included in this document if we can get 128 consensus on the discussion of the static address problem.) 130 Uplink 1 Uplink 2 131 | | 132 +---+---+ +---+---+ 133 +---- |Gateway| --------- |Gateway| -----+ 134 | +-------+ +-------+ | 135 | Enterprise Network | 136 | +------+ +------+ +------+ | 137 | | APP | |DHCPv6| | DNS | | 138 | |Server| |Server| +Server+ | 139 | +---+--+ +---+--+ +--+---+ | 140 | | | | | 141 | ---+--+---------+------+---+- | 142 | | | | 143 | +--+---+ +---+--+ | 144 | |Router| |Router| | 145 | +--+---+ +---+--+ | 146 | | | | 147 | -+---+----+-------+---+--+- | 148 | | | | | | 149 | +-+--+ +--+-+ +--+-+ +-+--+ | 150 | |Host| |Host| |Host| |Host| | 151 | +----+ +----+ +----+ +----+ | 152 +----------------------------------------+ 153 Figure 1 Enterprise network illustration 155 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 156 stack in which a logical IPv6 plane is independent from IPv4. The 157 complicated IPv4/IPv6 co-existence scenarios are out of scope. 159 This document focuses on the unicast addresses; site-local, link- 160 local, multicast and anycast addresses are out of scope. 162 3. Enterprise Network Renumbering Scenario Categories 164 In this section, we divide enterprise network renumbering scenarios 165 into two categories defined by external and internal network factors, 166 which require renumbering for different reasons. 168 3.1. Renumbering caused by External Network Factors 170 The most influential external network factor is the uplink ISP. 172 o The enterprise network switches to a new ISP. Of course, the 173 prefixes received from different ISPs are different. This is the 174 most common scenario. 176 Whether there is an overlap time between the old and new ISPs 177 would also influence the possibility whether the enterprise can 178 fulfill renumbering without a flag day [RFC4192]. 180 o The renumbering event may be initiated by receiving new prefixes 181 from the same uplink. This might happen if the enterprise network 182 is switched to a different location within the network topology of 183 the same ISP due to various considerations, such as commercial, 184 performance or services reasons, etc. Alternatively, the ISP 185 itself might be renumbered due to topology changes or migration to 186 a different or additional prefix. These ISP renumbering events 187 would initiate enterprise network renumbering events, of course. 189 o The enterprise network adds new uplink(s) for multihoming 190 purposes. This may not a typical renumbering because the original 191 addresses will not be changed. However, initial numbering may be 192 considered as a special renumbering event. The enterprise network 193 removes uplink(s) or old prefixes. 195 3.2. Renumbering caused by Internal Network Factors 197 o As companies split, merge, grow, relocate or reorganize, the 198 enterprise network architectures may need to be re-built. This 199 will trigger the internal renumbering. 201 o The enterprise network may proactively adopt a new address scheme, 202 for example by switching to a new transition mechanism or stage of 203 a transition plan. 205 o The enterprise network may reorganize its topology or subnets. 207 4. Network Renumbering Considerations and Best Current Practices 209 In order to carry out renumbering in an enterprise network, 210 systematic planning and administrative preparation are needed. 211 Carefully planning and preparation could make the renumbering process 212 smoother. 214 This section tries to give the recommended solutions or strategies 215 for the enterprise renumbering, chosen among existing mechanisms. 216 There are known gaps analyzed by [I-D.liu-6renum-gap-analysis]. If 217 these gaps are filled in the future, the enterprise renumbering may 218 be processed more automatically, with fewer issues. 220 4.1. Considerations and Best Current Practices during Network Design 222 This section describes the consideration or issues relevant to 223 renumbering that a network architect should carefully plan when 224 building or designing a new network. 226 - Prefix Delegation 228 In a large or a multi-site enterprise network, the prefix should 229 be carefully managed, particularly during renumbering events. 230 Prefix information needs to be delegated from router to router. 231 The DHCPv6 Prefix Delegation options [RFC3633] [I-D.ietf-dhc-pd- 232 exclude] provide a mechanism for automated delegation of IPv6 233 prefixes. Normally, DHCPv6 PD options are used between the 234 internal enterprise routers. 236 - Usage of FQDN 238 In general, Fully-Qualified Domain Names (FQDNs) are recommended 239 to be used to configure network connectivity, such as tunnels, 240 whenever possible. The capability to use FQDNs as endpoint names 241 has been standardized in several RFCs, such as [RFC5996], although 242 many system/network administrators do not realize that it is there 243 and works well as a way to avoid manual modification during 244 renumbering. 246 Service Location Protocol [RFC2608] and multicast DNS with SRV 247 records for service discovery can reduce the number of places that 248 IP addresses need to be configured. But it should be noted that 249 multicast DNS is link-local only. 251 - Usage of ULA 253 Unique Local Addresses (ULAs) are defined in [RFC4193] as 254 provider-independent prefixes, and they are globally unique to 255 avoid collision. For enterprise networks, using ULA along with PA 256 can provide a logically local routing plane separated from the 257 globally routing plane. The benefit is to ensure stable and 258 specific local communication regardless of the ISP uplink failure. 259 This benefit is especially meaningful for renumbering. It mainly 260 includes three use cases as the following. 262 When renumbering, as RFC4192 suggested, it has a period to keep 263 using the old prefix(es) before the new prefix(es) is(are) stable. 264 In the process of adding new prefix(es) and deprecating old 265 prefix(es), it is not easy to keep the local communication immune 266 of global routing plane change. If we use ULA for the local 267 communication, the separated local routing plane can isolate the 268 affecting by global routing change. 270 Enterprise administrators may want to avoid the need to renumber 271 their internal-only, private nodes when they have to renumber the 272 PA addresses of the whole network because of changing ISPs, ISPs 273 restructure their address allocations, or any other reasons. In 274 these situations, ULA is an effective tool for the internal-only 275 nodes. 277 For multicast, ULA may be a way of avoiding renumbering from 278 having an impact on multicast. In most deployments multicast is 279 only used internally (intra-domain), and the addresses used for 280 multicast sources and Rendezvous-Points need not be reachable nor 281 routable externally. Hence one may at least internally make use of 282 ULA for multicast specific infrastructure. 284 - Address Types 286 This document focuses on the dynamically-configured global unicast 287 addresses in enterprise networks. They are the targets of 288 renumbering events. 290 Manual-configured addresses are not scalable in medium to large 291 sites, hence are out of scope. Manual-configured addresses/hosts 292 should be avoided as much as possible. 294 - Address configuration models 296 In IPv6 networks, there are two auto-configuration models for 297 address assignment: Stateless Address Auto-Configuration (SLAAC) 298 by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful 299 address configuration by Dynamic Host Configuration Protocol for 300 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 301 support host-generated address model by assigning a prefix through 302 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 304 ND is considered easier to renumber by broadcasting a Router 305 Advertisement message with a new prefix. DHCPv6 can also trigger 306 the renumbering process by sending unicast RECONFIGURE messages, 307 though it may cause a large number of interactions between hosts 308 and DHCPv6 server. 310 This document has no preference between ND and DHCPv6 address 311 configuration models. It is network architects' job to decide 312 which configuration model is employed. But it should be noticed 313 that using DHCPv6 and ND together within one network, especially 314 in one subnet, may cause operational issues. For example, some 315 hosts use DHCPv6 as the default configuration model while some use 316 ND. Then the hosts' address configuration model depends on the 317 policies of operating systems and cannot be controlled by the 318 network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses 319 more details on this topic. So, in general, this document 320 recommends using DHCPv6/SLAAC independently in different subnets. 322 However, since DHCPv6 is also used to configure many other network 323 parameters, there are ND and DHCPv6 co-existence scenarios. 324 Combinations of address configuration models may coexist within a 325 single enterprise network. [I-D.ietf-savi-mix] provides 326 recommendations to avoid collisions and to review collision 327 handling in such scenarios. 329 - DNS 331 It is recommended that the site have an automatic and systematic 332 procedure for updating/synchronising its DNS records, including 333 both forward and reverse mapping [RFC2874]. A manual on-demand 334 updating model does not scale, and increases the chance of errors. 336 Although the A6 DNS record model [RFC2874] was designed for easier 337 renumbering, it has a lot of unsolved technical issues [RFC3364]. 338 Therefore, it has been moved to experimental status [RFC3363], and 339 will move to historic status by [RFC6563] (Moving A6 to Historic 340 Status). So A6 is not recommended. 342 In order to simplify the operation procedure, the network 343 architect should combine the forward and reverse DNS updates in a 344 single procedure. 346 Often, a small site depends on its ISP's DNS system rather than 347 maintaining its own. When renumbering, this requires 348 administrative coordination between the site and its ISP. 350 The DNS synchronization may be completed through the Secure DNS 351 Dynamic Update [RFC3007]. Dynamic DNS update can be provided by 352 the DHCPv6 client or by the server on behalf of individual hosts. 353 [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and 354 servers to exchange information about the client's FQDN and about 355 who has the responsibility for updating the DNS with the 356 associated AAAA and PTR RRs. For example, if a client wants the 357 server to update the FQDN-address mapping in the DNS server, it 358 can include the Client FQDN option with proper settings in the 359 SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message 360 originated by the client. When DHCPv6 server gets this option, it 361 can use the dynamic DNS update on behalf of the client. In this 362 document, we promote to support this FQDN option. But since it's a 363 DHCPv6 option, it implies that only the DHCP-managed networks are 364 suitable for this operation. In SLAAC mode, sometimes hosts also 365 need to register addresses on a registration server, which could 366 in fact be a DHCPv6 server (as described in [I-D.ietf-dhc-addr- 367 registration]); then the server would update corresponding DNS 368 records. 370 - Security 372 Any automatic renumbering scheme has a potential exposure to 373 hijacking. Malicious entity in the network can forge prefixes to 374 renumber the hosts. So proper network security mechanisms are 375 needed. 377 For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible 378 solution, but it is complex and there's almost no real deployment 379 so far. Comparing the non-trivial deployment of SEND, RA guard 380 [RFC6105] is a light-weight alternative, however, it also hasn't 381 been widely deployed since it hasn't been published for long. 383 For DHCPv6, there are built-in secure mechanisms (like Secure 384 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 385 messages [RFC3315] could be utilized. But these security 386 mechanisms also haven't been verified by wide real deployment. 388 - Miscellaneous 390 A site or network should also avoid embedding addresses from other 391 sites or networks in its own configuration data. Instead, the 392 Fully-Qualified Domain Names should be used. Thus, these 393 connections can survive after renumbering events at other sites. 394 This also applies to host-based connectivities. 396 4.2. Considerations and Best Current Practices for the Preparation of 397 Renumbering 399 In ND, it is not possible to reduce a prefix's lifetime to below two 400 hours. So, renumbering should not be an unplanned sudden event. This 401 issue could only be avoided by early planning and preparation. 403 This section describes several recommendations for the preparation of 404 enterprise renumbering event. By adopting these recommendations, a 405 site could be renumbered more easily. However, these recommendations 406 are not cost free. They might increase the daily burden of network 407 operation. Therefore, only those networks that are expected to be 408 renumbered soon or very frequently should adopt these recommendations, 409 with balanced consideration between daily cost and renumbering cost. 411 - Reduce the address preferred time or valid time or both. 413 Long-lifetime addresses may cause issues for renumbering events. 414 Particularly, some offline hosts may reconnect using these 415 addresses after renumbering events. Shorter preferred lifetimes 416 with relatively long valid lifetimes may allow short transition 417 periods for renumbering events and avoid frequent address 418 renewals. 420 - Reduce the DNS record TTL on the local DNS server. 422 The DNS AAAA resource record TTL on the local DNS server should be 423 manipulated to ensure that stale addresses are not cached. 425 - Reduce the DNS configuration lifetime on the hosts. 427 Since the DNS server could be renumbered as well, the DNS 428 configuration lifetime on the hosts should also be reduced if 429 renumbering events are expected. The DNS configuration can be done 430 through either ND [RFC6106] or DHCPv6 [RFC3646]. 432 - Identify long-living sessions 434 Any applications which maintain very long transport connections 435 (hours or days) should be identified in advance, if possible. Such 436 applications will need special handling during renumbering, so it 437 is important to know that they exist. 439 4.3. Considerations and Best Current Practices during Renumbering 440 Operation 442 Renumbering events are not instantaneous events. Normally, there is a 443 transition period, in which both the old prefix and the new prefix 444 are used in the site. Better network design and management, better 445 pre-preparation and longer transition period are helpful to reduce 446 the issues during renumbering operation. 448 - Within/without a flag day 449 As is described in [RFC4192], "a 'flag day' is a procedure in 450 which the network, or a part of it, is changed during a planned 451 outage, or suddenly, causing an outage while the network 452 recovers." 454 If renumbering event is processed within a flag day, the network 455 service/connectivity will be unavailable for a period until the 456 renumbering event is completed. It is efficient and provides 457 convenience for network operation and management. But network 458 outage is usually unacceptable for end users and enterprises. A 459 renumbering procedure without a flag day provides smooth address 460 switching, but much more operational complexity and difficulty is 461 introduced. 463 - Transition period 465 If renumbering transition period is longer than all address 466 lifetimes, after which the address leases expire, each host will 467 automatically pick up its new IP address. In this case, it would 468 be the DHCPv6 server or Router Advertisement itself that 469 automatically accomplishes client renumbering. 471 Address deprecation should be associated with the deprecation of 472 associated DNS records. The DNS records should be deprecated as 473 early as possible, before the addresses themselves. 475 - Network initiative enforced renumbering 477 If the network has to enforce renumbering before address leases 478 expire, the network should initiate DHCPv6 RECONFIGURE messages. 479 For some operating systems such as Windows 7, if the hosts receive 480 RA messages with ManagedFlag=0, they'll release the DHCPv6 481 addresses and do SLAAC according to the prefix information in the 482 RA messages, so this could be another enforcement method for some 483 specific scenarios. 485 - Impact to branch/main sites 487 Renumbering in main/branch site may cause impact on branch/main 488 site communication. The routes, ingress filtering of site's 489 gateways, and DNS may need to be updated. This needs careful 490 planning and organizing. 492 - DNS record update and DNS configuration on hosts 494 DNS records on the local DNS server should be updated if hosts are 495 renumbered. If the site depends on ISP's DNS system, it should 496 report the new host's DNS records to its ISP. During the 497 transition period, both old and new DNS records are valid. If the 498 TTLs of DNS records are shorter than the transition period, an 499 administrative operation may not be necessary. 501 DNS configuration on hosts should be updated if local recursive 502 DNS servers are renumbered. During the transition period, both old 503 and new DNS server addresses may co-exist on the hosts. If the 504 lifetime of DNS configuration is shorter than the transition 505 period, name resolving failure may be reduced to minimum. A 506 notification mechanism may be needed to indicate to the hosts that 507 a renumbering event of local recursive DNS happens or is going to 508 take place. 510 [Bing] Gap 7.1 512 - Tunnel concentrator renumbering 514 A tunnel concentrator itself might be renumbered. This change 515 should be reconfigured in relevant hosts or routers, unless the 516 configuration of tunnel concentrator was based on FQDN. 518 - Connectivity session survivability 520 During the renumbering operations, connectivity sessions in IP 521 layer would break if the old address is deprecated before the 522 session ends. However, the upper layer sessions may survive by 523 using session survivability technologies, such as SHIM6 [RFC5533]. 524 As mentioned above, some long-living applications may need to be 525 handled specially. 527 5. Security Considerations 529 As noted, a site that is listed by IP address in a black list can 530 escape that list by renumbering itself. 532 Any automatic renumbering scheme has a potential exposure to 533 hijacking. Proper network security mechanisms are needed. Although 534 there are existing security mechanisms such as SEND, RA guard, secure 535 DHCPv6 etc., they haven't been widely deployed and haven't been 536 verified whether they are suitable for ensuring security while not 537 bringing too much operational complexity and cost. 539 Dynamic DNS update may bring risk of DoS attack to the DNS server. So 540 along with the update authentication, session filtering/limitation 541 may also be needed. 543 The "make-before-break" approach of [RFC4192] requires the routers 544 keep advertising the old prefixes for some time. But if the ISP 545 changes the prefixes very frequently, the co-existence of old and new 546 prefixes may cause potential risk to the enterprise routing system. 547 However, enterprise scenarios may not involve the extreme situation; 548 this issue needs to be identified in the future. 550 The security configuration updates will need to be made in two stages 551 (immediately before and immediately after the event). 553 6. IANA Considerations 555 This draft does not request any IANA action. 557 7. Acknowledgements 559 This work is illuminated by RFC5887, so thank for RFC 5887 authors, 560 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 561 in by documents from Tim Chown and Fred Baker. The authors also want 562 to thank Wesley George, Olivier Bonaventure and other 6renum members 563 for valuable comments. 565 8. Change Log [RFC Editor please remove] 567 draft-jiang-6renum-enterprise-00, original version, 2011-07-01 569 draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail 570 list discussions, 2011-10-09 572 draft-jiang-6renum-enterprise-02, Update according to IETF82 573 discussions, 2011-12-06 575 draft-ietf-6renum-enterprise-00, Update according to mail list 576 discussions, 2012-02-06 578 9. References 580 9.1. Normative References 582 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 583 Location Protocol, Version 2", RFC 2608, June 1999. 585 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 586 Update", RFC 3007, November 2000. 588 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 589 M. Carney, "Dynamic Host Configuration Protocol for IPv6 590 (DHCPv6)", RFC 3315, July 2003. 592 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 593 Host Configuration Protocol (DHCP) version 6", RFC 3633, 594 December 2003. 596 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 597 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 598 December 2003. 600 [RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous 601 Point (RP) Address in an IPv6 Multicast Address", RFC 3956, 602 November 2004 604 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 605 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 607 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 608 Addresses", RFC 4193, October 2005. 610 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 611 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 612 RFC 4706, October 2006. 614 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 615 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 616 September 2007. 618 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 619 Address Autoconfiguration", RFC 4862, September 2007. 621 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 622 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 623 September 2010. 625 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 626 "IPv6 Router Advertisement Option for DNS Configuration", 627 RFC 6106, November 2011. 629 9.2. Informative References 631 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 632 IPv6 Address Aggregation and Renumbering", RFC 2874, July 633 2000. 635 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 636 "Representing Internet Protocol version 6 (IPv6) Addresses 637 in the Domain Name System (DNS)", RFC 3363, August 2002. 639 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 640 for Internet Protocol version 6 (IPv6)", RFC 3364, August 641 2002. 643 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 644 4057, June 2005. 646 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 647 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 648 September 2005. 650 [RFC4864] Van de Velde, G., T. Hain, R. Droms, B. Carpenter, E. Klein, 651 Local Network Protection for IPv6", RFC 4864, May 2007. 653 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 654 Shim Protocol for IPv6", RFC 5533, June 2009. 656 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 657 Still Needs Work", RFC 5887, May 2010. 659 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 660 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 661 February 2011. 663 [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 664 Historic Status", RFC 6563, May 2012. 666 [I-D.ietf-dhc-secure-dhcpv6] 667 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 668 in progress. 670 [I-D.ietf-dhc-host-gen-id] 671 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 672 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 673 April, 2011. 675 [I-D.ietf-savi-mix] 676 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 677 for Mixed Address Assignment Methods Scenario", working in 678 progress. 680 [I-D.ietf-dhc-pd-exclude] 681 J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 682 Exclude Option for DHCPv6-based Prefix Delegation", working 683 in progress. 685 [I-D.ietf-dhc-addr-registration] 686 Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration 687 Solution Using DHCPv6", working in progress. 689 [I-D.ietf-6renum-gap-analysis] 690 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 691 Analysis", working in progress. 693 [I-D.carpenter-6renum-static-problem] 694 Carpenter, B. and S. Jiang., "Problem Statement for 695 Renumbering IPv6 Hosts with Static Addresses", working in 696 progress. 698 Author's Addresses 700 Sheng Jiang 701 Huawei Technologies Co., Ltd 702 Huawei Q14 Building, No.156 Beiqing Rd., 703 Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District 704 EMail: jiangsheng@huawei.com 706 Bing Liu 707 Huawei Technologies Co., Ltd 708 Huawei Q14 Building, No.156 Beiqing Rd., 709 Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District 710 EMail: leo.liubing@huawei.com 712 Brian Carpenter 713 D