idnits 2.17.1 draft-ietf-6renum-enterprise-03.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 5 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 == Line 80 has weird spacing: '...roblems and P...' == Line 564 has weird spacing: '... system since...' -- The document date (October 15, 2012) is 4210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3956' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC4864' is defined on line 655, 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) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft B. Liu 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: April 14, 2013 B. Carpenter 5 University of Auckland 6 October 15, 2012 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-ietf-6renum-enterprise-03.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 April 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........... 4 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 .............................................. 10 64 4.3. Considerations and Best Current Practices during Renumbering 65 Operation ................................................... 11 66 5. Security Considerations ..................................... 13 67 6. IANA Considerations ......................................... 13 68 7. Acknowledgements ............................................ 13 69 8. References .................................................. 13 70 8.1. Normative References ................................... 13 71 8.2. Informative References ................................. 15 72 Author's Addresses ............................................. 17 74 1. Introduction 76 IPv6 site renumbering is considered difficult. Network managers might 77 prefer to use Provider Independent (PI) addressing for IPv6 to 78 attempt to minimize the need for future renumbering. However, 79 widespread use of PI might create very serious BGP4 scaling 80 problems and PI space is not always available for enterprises 81 according to the RIR (Regional Internet Registry) policies. It is 82 thus desirable to develop mechanisms and practice guidelines that 83 could make renumbering a simpler process to reduce demand for IPv6 PI 84 spaces. 86 This document undertakes scenario descriptions, including 87 documentation of current capabilities and existing BCPs, for 88 enterprise networks. It takes [RFC5887] and other relevant documents 89 as the primary input. 91 Since the IPv4 and IPv6 are logically separated from the perspective 92 of renumbering, regardless of overlapping of the IPv4/IPv6 networks 93 or devices, this document focuses on IPv6 only, by leaving IPv4 out 94 of scope. Dual-stack network or IPv4/IPv6 transition scenarios are 95 out of scope, too. 97 This document focuses on enterprise network renumbering, however, 98 most of the analysis is also applicable to ISP network renumbering. 99 Renumbering in home networks is considered out of scope, but it can 100 also benefit from the analysis in this document. 102 The concept of enterprise network and a typical network illustration 103 are introduced first. Then, according to the different stages of 104 renumbering events, considerations and best current practices are 105 described in three categories: during network design, for preparation 106 of renumbering, and during 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 The enterprise network architecture is illustrated in the figure 116 below. Those entities relevant to renumbering are highlighted. 118 Address reconfiguration is fulfilled either by DHCPv6 or ND 119 protocols. During the renumbering event, the DNS records need to be 120 synchronized while routing tables, ACLs and IP filtering tables in 121 various devices also need to be updated, too. 123 Static address issue is described in a dedicated draft 124 [I-D.ietf-6renum-static-problem]. 126 Uplink 1 Uplink 2 127 | | 128 +---+---+ +---+---+ 129 +---- |Gateway| --------- |Gateway| -----+ 130 | +-------+ +-------+ | 131 | Enterprise Network | 132 | +------+ +------+ +------+ | 133 | | APP | |DHCPv6| | DNS | | 134 | |Server| |Server| +Server+ | 135 | +---+--+ +---+--+ +--+---+ | 136 | | | | | 137 | ---+--+---------+------+---+- | 138 | | | | 139 | +--+---+ +---+--+ | 140 | |Router| |Router| | 141 | +--+---+ +---+--+ | 142 | | | | 143 | -+---+----+-------+---+--+- | 144 | | | | | | 145 | +-+--+ +--+-+ +--+-+ +-+--+ | 146 | |Host| |Host| |Host| |Host| | 147 | +----+ +----+ +----+ +----+ | 148 +----------------------------------------+ 149 Figure 1 Enterprise network illustration 151 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 152 stack in which a logical IPv6 plane is independent from IPv4. The 153 complicated IPv4/IPv6 co-existence scenarios are out of scope. 155 This document focuses on the unicast addresses; site-local, link- 156 local, multicast and anycast addresses are out of scope. 158 3. Enterprise Network Renumbering Scenario Categories 160 In this section, we divide enterprise network renumbering scenarios 161 into two categories defined by external and internal network factors, 162 which require renumbering for different reasons. 164 3.1. Renumbering Caused by External Network Factors 166 The most influential external network factor is the uplink ISP. 168 o The enterprise network switches to a new ISP. Of course, the 169 prefixes received from different ISPs are different. This is the 170 most common scenario. 172 Whether there is an overlap time between the old and new ISPs 173 would also influence the possibility whether the enterprise can 174 fulfill renumbering without a flag day [RFC4192]. 176 o The renumbering event can be initiated by receiving new prefixes 177 from the same uplink. This might happen if the enterprise network 178 is switched to a different location within the network topology of 179 the same ISP due to various considerations, such as commercial, 180 performance or services reasons, etc. Alternatively, the ISP 181 itself might be renumbered due to topology changes or migration to 182 a different or additional prefix. These ISP renumbering events 183 would initiate enterprise network renumbering events, of course. 185 o The enterprise network adds new uplink(s) for multihoming purposes. 186 This might not be a typical renumbering case because the original 187 addresses will not be changed. However, initial numbering may be 188 considered as a special renumbering event. The enterprise network 189 removes uplink(s) or old prefixes. 191 3.2. Renumbering caused by Internal Network Factors 193 o As companies split, merge, grow, relocate or reorganize, the 194 enterprise network architectures might need to be re-built. This 195 will trigger the internal renumbering. 197 o The enterprise network might proactively adopt a new address 198 scheme, for example by switching to a new transition mechanism or 199 stage of a transition plan. 201 o The enterprise network might reorganize its topology or subnets. 203 4. Network Renumbering Considerations and Best Current Practices 205 In order to carry out renumbering in an enterprise network, 206 systematic planning and administrative preparation are needed. 207 Carefully planning and preparation could make the renumbering process 208 smoother. 210 This section recommends some solutions or strategies for the 211 enterprise renumbering, chosen among existing mechanisms. There are 212 known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps 213 are filled in the future, the enterprise renumbering can be processed 214 more automatically, with fewer issues. 216 4.1. Considerations and Best Current Practices during Network Design 218 This section describes the consideration or issues relevant to 219 renumbering that a network architect should carefully plan when 220 building or designing a new network. 222 - Prefix Delegation 224 In a large or a multi-site enterprise network, the prefix should 225 be carefully managed, particularly during renumbering events. 226 Prefix information needs to be delegated from router to router. 227 The DHCPv6 Prefix Delegation options [RFC3633] and 228 [RFC6603] provide a mechanism for automated delegation of IPv6 229 prefixes. Normally, DHCPv6 PD options are used between the 230 internal enterprise routers, for example, a router receives 231 prefix(es) from its upstream router (might be a border gateway or 232 edge router .etc) through DHCPv6 PD options and then advertise it 233 (them) to the local hosts through RA messages. 235 - Usage of FQDN 237 In general, Fully-Qualified Domain Names (FQDNs) are recommended 238 to be used to configure network connectivity, such as tunnels, 239 whenever possible. The capability to use FQDNs as endpoint names 240 has been standardized in several RFCs, such as [RFC5996], although 241 many system/network administrators do not realize that it is there 242 and works well as a way to avoid manual modification during 243 renumbering. 245 Service Location Protocol [RFC2608], multicast DNS 246 [I-D.cheshire-dnsext-multicastdns] with SRV records, and DNS 247 Service Discovery [I-D.cheshire-dnsext-dns-sd] for service 248 discovery can reduce the number of places that IP addresses need 249 to be configured. But it should be noted that multicast DNS is 250 link-local only. 252 - Usage of ULA 254 Unique Local Addresses (ULAs) are defined in [RFC4193] as 255 provider-independent prefixes, and they are globally unique to 256 avoid collision. For enterprise networks, using ULA along with PA 257 can provide a logically local routing plane separated from the 258 globally routing plane. The benefit is to ensure stable and 259 specific local communication regardless of the ISP uplink failure. 260 This benefit is especially meaningful for renumbering. It mainly 261 includes three use cases as the following. 263 When renumbering, as RFC4192 suggested, it has a period to keep 264 using the old prefix(es) before the new prefix(es) is(are) stable. 265 In the process of adding new prefix(es) and deprecating old 266 prefix(es), it is not easy to keep the local communication immune 267 of global routing plane change. If we use ULA for the local 268 communication, the separated local routing plane can isolate the 269 affecting by global routing change. 271 Enterprise administrators might want to avoid the need to renumber 272 their internal-only, private nodes when they have to renumber the 273 PA addresses of the whole network because of changing ISPs, ISPs 274 restructuring their address allocation, or any other reasons. In 275 these situations, ULA is an effective tool for the internal-only 276 nodes. 278 For multicast, ULA can be a way of avoiding renumbering from 279 having an impact on multicast. In most deployments multicast is 280 only used internally (intra-domain), and the addresses used for 281 multicast sources and Rendezvous-Points need not be reachable nor 282 routable externally. Hence one may at least internally make use of 283 ULA for multicast specific infrastructure. 285 - Address Types 287 This document focuses on the dynamically-configured global unicast 288 addresses in enterprise networks. They are the targets of 289 renumbering events. 291 Manual-configured addresses are not scalable in medium to large 292 sites, hence are out of scope. Manually-configured addresses/hosts 293 should be avoided as much as possible. 295 - Address configuration models 297 In IPv6 networks, there are two auto-configuration models for 298 address assignment: Stateless Address Auto-Configuration (SLAAC, 299 [RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful 300 address configuration by Dynamic Host Configuration Protocol for 301 IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also 302 support host-generated address model by assigning a prefix through 303 DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 305 ND is considered easier to renumber by broadcasting a Router 306 Advertisement message with a new prefix. DHCPv6 can also trigger 307 the renumbering process by sending unicast RECONFIGURE messages, 308 though it might cause a large number of interactions between hosts 309 and DHCPv6 server. 311 This document has no preference between ND and DHCPv6 address 312 configuration models. It is network architects' job to decide 313 which configuration model is employed. But it should be noticed 314 that using DHCPv6 and ND together within one network, especially 315 in one subnet, might cause operational issues. For example, some 316 hosts use DHCPv6 as the default configuration model while some use 317 ND. Then the hosts' address configuration model depends on the 318 policies of operating systems and cannot be controlled by the 319 network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses 320 more details on this topic. So, in general, this document 321 recommends using DHCPv6/SLAAC independently in different subnets. 323 However, since DHCPv6 is also used to configure many other network 324 parameters, there are ND and DHCPv6 co-existence scenarios. 325 Combinations of address configuration models might coexist within 326 a single enterprise network. [I-D.ietf-savi-mix] provides 327 recommendations to avoid collisions and to review collision 328 handling in such scenarios. 330 - DNS 332 It is recommended that the site have an automatic and systematic 333 procedure for updating/synchronizing its DNS records, including 334 both forward and reverse mapping [RFC2874]. A manual on-demand 335 updating model does not scale, and increases the chance of errors. 337 Although the A6 DNS record model [RFC2874] was designed for easier 338 renumbering, it has a lot of unsolved technical issues [RFC3364]. 339 Therefore, it has been moved to experimental status [RFC3363], and 340 will move to historic status by [RFC6563] (Moving A6 to Historic 341 Status). So A6 is not recommended. 343 In order to simplify the operation procedure, the network 344 architect should combine the forward and reverse DNS updates in a 345 single procedure. 347 Often, a small site depends on its ISP's DNS system rather than 348 maintaining its own. When renumbering, this requires 349 administrative coordination between the site and its ISP. 351 The DNS synchronization can be completed through the Secure DNS 352 Dynamic Update [RFC3007]. Dynamic DNS update can be provided by 353 the DHCPv6 client or by the server on behalf of individual hosts. 354 [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and 355 servers to exchange information about the client's FQDN and about 356 who has the responsibility for updating the DNS with the 357 associated AAAA and PTR (Pointer Record) RRs (Resource Records). 359 For example, if a client wants the server to update the FQDN- 360 address mapping in the DNS server, it can include the Client FQDN 361 option with proper settings in the SOLICIT with Rapid Commit, 362 REQUEST, RENEW, and REBIND message originated by the client. When 363 DHCPv6 server gets this option, it can use the dynamic DNS update 364 on behalf of the client. In this document, we promote to support 365 this FQDN option. But since it's a DHCPv6 option, it implies that 366 only the DHCP-managed networks are suitable for this operation. In 367 SLAAC mode, sometimes hosts also need to register addresses on a 368 registration server, which could in fact be a DHCPv6 server (as 369 described in 370 [I-D.ietf-dhc-addr-registration]); then the server would update 371 corresponding DNS records. 373 - Security 375 Any automatic renumbering scheme has a potential exposure to 376 hijacking. Malicious entity in the network can forge prefixes to 377 renumber the hosts. So proper network security mechanisms are 378 needed. 380 For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible 381 solution, but it is complex and there's almost no real deployment 382 so far. Comparing the non-trivial deployment of SEND, RA guard 383 [RFC6105] is a light-weight alternative, which focuses on rogue 384 router advertisements proof in a L2 network. However, it also 385 hasn't been widely deployed since it hasn't been published for 386 long. 388 For DHCPv6, there are built-in secure mechanisms (like Secure 389 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 390 messages [RFC3315] could be utilized. But these security 391 mechanisms also haven't been verified by wide real deployment. 393 - Miscellaneous 395 A site or network should also avoid embedding addresses from other 396 sites or networks in its own configuration data. Instead, the 397 Fully-Qualified Domain Names should be used. Thus, these 398 connections can survive after renumbering events at other sites. 399 This also applies to host-based connectivities. 401 4.2. Considerations and Best Current Practices for the Preparation of 402 Renumbering 404 In ND, it is not possible to reduce a prefix's lifetime to below two 405 hours. So, renumbering should not be an unplanned sudden event. This 406 issue could only be avoided by early planning and preparation. 408 This section describes several recommendations for the preparation of 409 enterprise renumbering event. By adopting these recommendations, a 410 site could be renumbered more easily. However, these recommendations 411 might increase the daily traffic, server load, or burden of network 412 operation. Therefore, only those networks that are expected to be 413 renumbered soon or very frequently should adopt these recommendations, 414 with balanced consideration between daily cost and renumbering cost. 416 - Reduce the address preferred time or valid time or both. 418 Long-lifetime addresses might cause issues for renumbering events. 419 Particularly, some offline hosts might reconnect using these 420 addresses after renumbering events. Shorter preferred lifetimes 421 with relatively long valid lifetimes may allow short transition 422 periods for renumbering events and avoid frequent address renewals. 424 - Reduce the DNS record TTL on the local DNS server. 426 The DNS AAAA resource record TTL on the local DNS server should be 427 manipulated to ensure that stale addresses are not cached. 429 Recent research [BA2011] [JSBM2002] indicates that it is both 430 practical and reasonable for A, AAAA, and PTR records that belong 431 to leaf nodes of the DNS (i.e. not including the DNS root or DNS 432 top-level domains) to be configured with very short DNS TTL values, 433 not only during renumbering events, but also for longer-term 434 operation. 436 - Reduce the DNS configuration lifetime on the hosts. 438 Since the DNS server could be renumbered as well, the DNS 439 configuration lifetime on the hosts should also be reduced if 440 renumbering events are expected. In ND, The DNS configuration can 441 be done through reducing the lifetime value in RDNSS option 442 [RFC6106]. In DHCPv6, the DNS configuration option specified in 443 [RFC3646] doesn't provide lifetime attribute, but we can reduce 444 the DHCPv6 client lease time to achieve similar effect. 446 - Identify long-living sessions 447 Any applications which maintain very long transport connections 448 (hours or days) should be identified in advance, if possible. Such 449 applications will need special handling during renumbering, so it 450 is important to know that they exist. 452 4.3. Considerations and Best Current Practices during Renumbering 453 Operation 455 Renumbering events are not instantaneous events. Normally, there is a 456 transition period, in which both the old prefix and the new prefix 457 are used in the site. Better network design and management, better 458 pre-preparation and longer transition period are helpful to reduce 459 the issues during renumbering operation. 461 - Within/without a flag day 463 As is described in [RFC4192], "a 'flag day' is a procedure in 464 which the network, or a part of it, is changed during a planned 465 outage, or suddenly, causing an outage while the network 466 recovers." 468 If renumbering event is processed within a flag day, the network 469 service/connectivity will be unavailable for a period until the 470 renumbering event is completed. It is efficient and provides 471 convenience for network operation and management. But network 472 outage is usually unacceptable for end users and enterprises. A 473 renumbering procedure without a flag day provides smooth address 474 switching, but much more operational complexity and difficulty is 475 introduced. 477 - Transition period 479 If renumbering transition period is longer than all address 480 lifetimes, after which the address leases expire, each host will 481 automatically pick up its new IP address. In this case, it would 482 be the DHCPv6 server or Router Advertisement itself that 483 automatically accomplishes client renumbering. 485 Address deprecation should be associated with the deprecation of 486 associated DNS records. The DNS records should be deprecated as 487 early as possible, before the addresses themselves. 489 - Network initiative enforced renumbering 491 If the network has to enforce renumbering before address leases 492 expire, the network should initiate DHCPv6 RECONFIGURE messages. 493 For some operating systems such as Windows 7, if the hosts receive 494 RA messages with ManagedFlag=0, they'll release the DHCPv6 495 addresses and do SLAAC according to the prefix information in the 496 RA messages, so this could be another enforcement method for some 497 specific scenarios. 499 - Impact to branch/main sites 501 Renumbering in main/branch site might cause impact on branch/main 502 site communication. The routes, ingress filtering of site's 503 gateways, and DNS might need to be updated. This needs careful 504 planning and organizing. 506 - DNS record update and DNS configuration on hosts 508 DNS records on the local DNS server should be updated if hosts are 509 renumbered. If the site depends on ISP's DNS system, it should 510 report the new host's DNS records to its ISP. During the 511 transition period, both old and new DNS records are valid. If the 512 TTLs of DNS records are shorter than the transition period, an 513 administrative operation might not be necessary. 515 DNS configuration on hosts should be updated if local recursive 516 DNS servers are renumbered. During the transition period, both old 517 and new DNS server addresses might co-exist on the hosts. If the 518 lifetime of DNS configuration is shorter than the transition 519 period, name resolving failure may be reduced to minimum. 521 - Tunnel concentrator renumbering 523 A tunnel concentrator itself might be renumbered. This change 524 should be reconfigured in relevant hosts or routers, unless the 525 configuration of tunnel concentrator was based on FQDN. 527 For IPSec, [RFC2230] defines the KX (Key eXchange) record, which 528 could be used to help locate the domain-name for an IPsec VPN 529 concentrator associated with a site's domain name. For current 530 practice, the community needs to change its bad habit of using 531 IPsec in an address-oriented way, and renumbering is one of the 532 main reasons for that. 534 - Connectivity session survivability 536 During the renumbering operations, connectivity sessions in IP 537 layer would break if the old address is deprecated before the 538 session ends. However, the upper layer sessions can survive by 539 using session survivability technologies, such as SHIM6 [RFC5533]. 541 As mentioned above, some long-living applications may need to be 542 handled specially. 544 5. Security Considerations 546 As noted, a site that is listed by IP address in a black list can 547 escape that list by renumbering itself. 549 Any automatic renumbering scheme has a potential exposure to 550 hijacking. Proper network security mechanisms are needed. Although 551 there are some existing security mechanisms such as SEND, RA guard, 552 secure DHCPv6 etc., they haven't been widely deployed and haven't 553 been verified whether they are not bringing too much operational 554 complexity and cost. 556 Dynamic DNS update might bring risk of DoS attack to the DNS server. 557 So along with the update authentication, session filtering/limitation 558 might also be needed. 560 The "make-before-break" approach of [RFC4192] requires the routers 561 keep advertising the old prefixes for some time. But if the ISP 562 changes the prefixes very frequently, the co-existence of old and new 563 prefixes might cause potential risk to the enterprise routing 564 system since the old address relevant route path might already 565 invalid and the routing system just doesn't know it. However, 566 normally enterprise scenarios don't involve the extreme situation. 568 6. IANA Considerations 570 This draft does not request any IANA action. 572 7. Acknowledgements 574 This work is illuminated by RFC5887, so thank for RFC 5887 authors, 575 Randall Atkinson and Hannu Flinck. Useful ideas were also presented 576 in by documents from Tim Chown and Fred Baker. The authors also want 577 to thank Wesley George, Olivier Bonaventure and other 6renum members 578 for valuable comments. 580 8. References 582 8.1. Normative References 584 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 585 Location Protocol, Version 2", RFC 2608, June 1999. 587 [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic 588 Update", RFC 3007, November 2000. 590 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 591 M. Carney, "Dynamic Host Configuration Protocol for IPv6 592 (DHCPv6)", RFC 3315, July 2003. 594 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 595 Host Configuration Protocol (DHCP) version 6", RFC 3633, 596 December 2003. 598 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 599 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 600 December 2003. 602 [RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous 603 Point (RP) Address in an IPv6 Multicast Address", RFC 3956, 604 November 2004 606 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 607 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 609 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 610 Addresses", RFC 4193, October 2005. 612 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 613 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", 614 RFC 4706, October 2006. 616 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 617 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 618 September 2007. 620 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 621 Address Autoconfiguration", RFC 4862, September 2007. 623 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 624 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 625 September 2010. 627 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 628 "IPv6 Router Advertisement Option for DNS Configuration", 629 RFC 6106, November 2011. 631 8.2. Informative References 633 [RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS", 634 RFC 2230, November 1997. 636 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 637 IPv6 Address Aggregation and Renumbering", RFC 2874, July 638 2000. 640 [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, 641 "Representing Internet Protocol version 6 (IPv6) Addresses 642 in the Domain Name System (DNS)", RFC 3363, August 2002. 644 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 645 for Internet Protocol version 6 (IPv6)", RFC 3364, August 646 2002. 648 [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 649 4057, June 2005. 651 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 652 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 653 September 2005. 655 [RFC4864] Van de Velde, G., T. Hain, R. Droms, B. Carpenter, E. Klein, 656 Local Network Protection for IPv6", RFC 4864, May 2007. 658 [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming 659 Shim Protocol for IPv6", RFC 5533, June 2009. 661 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 662 Still Needs Work", RFC 5887, May 2010. 664 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 665 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 666 February 2011. 668 [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to 669 Historic Status", RFC 6563, May 2012. 671 [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix 672 Exclude Option for DHCPv6-based Prefix Delegation", RFC 673 6603, May 2012. 675 [I-D.ietf-dhc-secure-dhcpv6] 676 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 677 in progress, March 2012. 679 [I-D.ietf-dhc-host-gen-id] 680 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 681 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 682 August, 2012. 684 [I-D.ietf-savi-mix] 685 Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI 686 for Mixed Address Assignment Methods Scenario", working in 687 progress, April 2012. 689 [I-D.ietf-dhc-addr-registration] 690 Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration 691 Solution Using DHCPv6", working in progress, May 2012. 693 [I-D.ietf-6renum-gap-analysis] 694 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 695 Analysis", working in progress, August 2012. 697 [I-D.ietf-6renum-static-problem] 698 Carpenter, B. and S. Jiang., "Problem Statement for 699 Renumbering IPv6 Hosts with Static Addresses", working in 700 progress, August 2012. 702 [I-D.cheshire-dnsext-dns-sd] 703 Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", 704 draft-cheshire-dnsext-dns-sd-11 (work in progress), 705 December 2011. 707 [I-D.cheshire-dnsext-multicastdns] 708 Cheshire, S. and M. Krochmal, "Multicast DNS", draft- 709 cheshire-dnsext-multicastdns-15 (work in progress), 710 December 2011. 712 [BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc. 713 14th IEEE Global Internet Symposium (GI2011), Shanghai, 714 China. 15 April 2011. 716 [JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS 717 Performance and the Effectiveness of Caching", IEEE/ACM 718 Transactions on Networking, 10(5):589-603, 2002. 720 Author's Addresses 722 Sheng Jiang 723 Huawei Technologies Co., Ltd 724 Q14, Huawei Campus 725 No.156 Beiqing Rd. 726 Hai-Dian District, Beijing 100095 727 P.R. China 729 EMail: jiangsheng@huawei.com 731 Bing Liu 732 Huawei Technologies Co., Ltd 733 Q14, Huawei Campus 734 No.156 Beiqing Rd. 735 Hai-Dian District, Beijing 100095 736 P.R. China 738 EMail: leo.liubing@huawei.com 740 Brian Carpenter 741 Department of Computer Science 742 University of Auckland 743 PB 92019 744 Auckland, 1142 745 New Zealand 747 EMail: brian.e.carpenter@gmail.com