idnits 2.17.1 draft-jiang-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 (July 01, 2011) is 4683 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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-secure-dhcpv6 - is the name correct? -- No information found for draft-liu-6renum-gap-analysis - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 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: Best Current Practice Huawei Technologies Co., Ltd 4 Expires: January 03, 2012 B. Carpenter 5 University of Auckland 6 July 01, 2011 8 IPv6 Enterprise Network Renumbering Scenarios and Guidelines 9 draft-jiang-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 January 03, 2012. 28 Copyright Notice 30 Copyright (c) 2011 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 the enterprise renumbering events and gives 46 the recommendations among the existing renumbering mechanisms. 47 According to the different stages of renumbering events, 48 considerations and best current recommendations are described in 49 three categories: during network design, for preparation of 50 renumbering, and during renumbering operation. A gap inventory is 51 listed at the 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........... 4 59 3.2. Renumbering caused by Internal Network Factors........... 5 60 4. Network Renumbering Considerations and Best Current 61 Recommendations ................................................. 5 62 4.1. Considerations and Recommendations during Network Design. 6 63 4.2. Considerations and Recommendations for the Preparation of 64 Renumbering .................................................. 8 65 4.3. Considerations and Recommendations during Renumbering 66 Operation .................................................... 9 67 5. Gap Inventory ............................................... 11 68 6. Security Considerations ..................................... 12 69 7. IANA Considerations ......................................... 12 70 8. Acknowledgements ............................................ 12 71 9. Change Log [RFC Editor please remove] ....................... 12 72 10. References ................................................. 13 73 10.1. Normative References .................................. 13 74 10.2. Informative References ................................ 14 75 Author's Addresses ............................................. 15 77 1. Introduction 79 IPv6 site renumbering is considered difficult. Network managers would 80 turn to Provider Independent (PI) addressing for IPv6 to attempt to 81 minimize the need for future renumbering. However, widespread use of 82 PI may create very serious BGP4 scaling problems. It is thus 83 desirable to develop tools and practices that may make renumbering a 84 simpler process to reduce demand for IPv6 PI space. 86 This document undertakes scenario descriptions, including 87 documentation of current capability inventories and existing BCPs, 88 for enterprise networks. It takes the analysis conclusions from 89 [RFC5887] and other relevant documents as the primary input. 91 This document focuses on IPv6 only, by leaving IPv4 out of scope. 92 Dual-stack network or IPv4/IPv6 transition scenarios are out of scope, 93 too. 95 According to the different stages of renumbering events, 96 considerations and best current recommendations are described in 97 three categories: during network design, for preparation of 98 renumbering, and during renumbering operation. A gap inventory is 99 listed at the end of this document. 101 2. Enterprise Network Illustration for Renumbering 103 The enterprise network architecture is illustrated as the figure 104 below. From the renumbering perspective of view, these entities 105 relevant to renumbering are highlighted. 107 Address reconfiguration is fulfilled either by DHCPv6 or ND 108 protocols. Static address assignment is not considered in this 109 version. During the renumbering event, the DNS records need to be 110 synchronized while routing tables, ACLs and IP filtering tables in 111 various gateways also need to be updated, too. 113 Uplink 1 Uplink 2 114 | | 115 +---+---+ +---+---+ 116 +---- |Gateway| --------- |Gateway| -----+ 117 | +-------+ +-------+ | 118 | Enterprise Network | 119 | +------+ +------+ +------+ | 120 | | APP | | DHCP | | DNS | | 121 | |Server| |Server| +Server+ | 122 | +---+--+ +---+--+ +--+---+ | 123 | | | | | 124 | ---+--+---------+------+---+- | 125 | | | | 126 | +--+---+ +---+--+ | 127 | |Router| |Router| | 128 | +--+---+ +---+--+ | 129 | | | | 130 | -+---+----+-------+---+--+- | 131 | | | | | | 132 | +-+--+ +--+-+ +--+-+ +-+--+ | 133 | |Host| |Host| |Host| |Host| | 134 | +----+ +----+ +----+ +----+ | 135 +----------------------------------------+ 136 Figure 1 Enterprise network illustration 138 It is assumed that IPv6 enterprise networks are IPv6-only, or dual- 139 stack in which a logical IPv6 plane is independent from IPv4. The 140 complicated IPv4/IPv6 co-existing scenarios are out of scope. 142 This document focuses on the unicast addresses; site-local, link- 143 local, multicast and anycast addresses are out of scope. 145 3. Enterprise Network Renumbering Scenario Categories 147 In this section, we category enterprise network renumbering scenarios 148 mainly according to different reasons. Some of renumbering reasons 149 described in [RFC2071] has out of date, or not suitable in IPv6, or 150 not suitable for enterprise networks. 152 3.1. Renumbering caused by External Network Factors 154 The most influential external network factor is the uplink ISP. 156 o The enterprise network switches to a new ISP. Of course, the 157 prefixes received from different ISPs are different. This is the 158 most common scenario. 160 Whether there is an overlap time between the old and new ISPs 161 would also influence the possibility whether the enterprise can 162 fulfill renumbering without a flag day [RFC4192]. 164 o The renumbering event may be initiated by receiving new prefixes 165 from the same uplink. The typical scenario is that the DHCP server 166 in ISP delegates a new prefix to the enterprise network. Or the 167 enterprise network may be switched to a different location within 168 the network topology of the same ISP due to various 169 considerations, such as commercial, performance or services 170 reasons, etc. The ISP itself may also be renumbered due to 171 topology change or migration to a different or additional prefix. 172 These ISP renumbering events would initiate enterprise network 173 renumbering events, of course. 175 o The enterprise network adds new uplink(s) for multihoming 176 purpose. This may not a typical renumbering because the original 177 addresses will not be changed. However, initial numbering may be 178 considered as a special renumbering event. If the administrators 179 only want part of the network to have multiple prefixes, the 180 renumbering process should be carefully managed. 182 3.2. Renumbering caused by Internal Network Factors 184 o As companies split, merge, grow, or reorganize, the enterprise 185 network architectures may need to be re-built. This will trigger 186 the internal renumbering. 188 4. Network Renumbering Considerations and Best Current Recommendations 190 In order to carry out renumbering in an enterprise network, 191 systematic planning and administrative preparation are needed. 192 Carefully planning and preparation could make the renumbering process 193 smoother. 195 This section tries to give the recommended solutions or strategies 196 for the enterprise renumbering among the existing mechanisms. There 197 are a few gaps analyzed by [I-D.liu-6renum-gap-analysis]. If they are 198 filled in the future, the enterprise renumbering may be processed 199 more automatically, with fewer issues. 201 4.1. Considerations and Recommendations during Network Design 203 This section describes the renumbering relevant considerations or 204 issues that a network architect should carefully plan when he builds 205 or designs a new network. 207 - Prefix Delegation 209 In a large or a multi-site enterprise network, the prefix should 210 be carefully managed, particularly during renumbering events. 211 Prefix information needs to be delegated from router to router. 212 The DHCPv6 Prefix Delegation options [RFC3633] provide a mechanism 213 for automated delegation of IPv6 prefixes. DHCPv6 PD options may 214 also be used between the enterprise routers and their upstream 215 ISPs. 217 - Usage of FQDN 219 It is recommended that Fully-Qualified Domain Names (FQDNs) should 220 be used to configure network connectivity, such as tunnels. The 221 capability to use FQDNs as endpoint names has been standardized in 222 several RFCs, such as [RFC5996], although many system/network 223 administrators do not realize that it is there and works well as a 224 way to avoid manual modification during renumbering. 226 Service Location Protocol [RFC2608] and multicast DNS with SRV 227 records for service discovery can reduce the number of places that 228 IP addresses need to be configured. 230 - Address Types 232 This document focuses on the dynamic-configured global unicast 233 addresses in enterprise networks. They are the targets of 234 renumbering events. 236 Manual-configured addresses are not scalable in medium to large 237 sites, hence be out of scope. However, some hosts such as servers 238 may need static addresses. Manual-configured addresses/hosts 239 should be avoided as much as possible. 241 [Open Question to WG] What we can do regarding to manual 242 configured hosts and static addresses, which do need to be 243 changed? 245 Unique Local Address (ULA, [RFC4193]) may be used on local routers 246 or servers, which only intends for local communications, usually 247 inside of enterprise networks. Normally, they do NOT need to be 248 changed during the renumbering event. 250 [Open Question to WG] Is anyone actually using ULAs? 252 - Address configuration models 254 In IPv6 networks, there are two auto-configuration models for 255 address assignment: the Stateless Address Auto-Configuration 256 (SLAAC) by Neighbor Discovery (ND, [RFC4861, RFC4862]) and the 257 stateful address configuration by Dynamic Host Configuration 258 Protocol for IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 259 can also support host-generate address model by assigning prefix 260 through DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. 262 ND is considered easier to renumber by broadcasting a Router 263 Advertisement message with a new prefix. DHCPv6 can also trigger 264 the renumbering process by sending unicast RECONFIGURE messages 265 though it may cause a large number of interactions between hosts 266 and DHCPv6 server. 268 In principle, a network should choose only one address 269 configuration model and employs either ND or DHCPv6. This document 270 has no preference between ND and DHCPv6 address configuration 271 models. 273 However, since DHCPv6 is also used to configure many other network 274 parameters, there are ND and DHCPv6 co-existing scenarios. The 275 current protocols do not effectively prevent that both SLAAC and 276 DHCPv6 address assignment are used in the same network (see M bit 277 analysis in section 5.1.1 [RFC5887]). It is network architects' 278 job to make sure only one configuration model is employed. Even in 279 a large network that contains several subnet works, it is 280 recommended not to mix the two address configuration models though 281 isolately using them in different subnet works may reduce the risk 282 partly. 284 - DNS 286 It is recommended that the site have an automatic and systematic 287 procedure for updating/synchronising its DNS records, including 288 both forward and reverse mapping [RFC2874]. Manually on-demand 289 updating model is considered as a harmful problem creator in 290 renumbering event. 292 A6 DNS record model is recommended over AAAA record model for 293 renumbering purpose [RFC2874, RFC3364]. 295 In order to simplify the operation procedure, the network 296 architect should combine the forward and reverse DNS updates in a 297 single procedure. 299 If a small site depends on its ISP's DNS system rather than 300 maintains its own one. When renumbering, it requires 301 administrative coordination between the site and its ISP. 302 Alternatively, the DNS synchronizing may be completed through the 303 Secure Dynamic DNS Update. 305 - Security 307 Any automatic renumbering scheme has a potential exposure to 308 hijacking at the moment that a new address is announced. Proper 309 network security mechanisms should be employed. Secure Neighbor 310 Discovery (SEND, [RFC3971]), which does not widely deployed, is 311 recommended to replace ND. Alternatively, certain lightweight 312 renumbering specific security mechanism may be developed in the 313 future. DHCPv6 build-in secure mechanisms, like Secure DHCPv6 314 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 315 [RFC3315] are recommended. 317 - Miscellaneous 319 A site or network should also avoid to embed addresses from other 320 sites or networks in its own configuration data. Instead, the 321 Fully-Qualified Domain Names should be used. Thusness, these 322 connectivities can survive after renumbering events. This also 323 applies to host-based connectivities. 325 4.2. Considerations and Recommendations for the Preparation of 326 Renumbering 328 It is not possible to reduce a prefix's lifetime to below two hours. 329 So, renumbering should not be an unplanned sudden event. This issue 330 could only be avoided by early planning and preparation. 332 This session describes several recommendations for the preparation of 333 enterprise renumbering event. By adopting these recommendations, a 334 site could be renumbered easier. However, these recommendations are 335 not cost free. They might increase the daily burden of network 336 operation. Therefore, only these networks that are expected to be 337 renumbered soon or very frequently should adopt these recommendations 338 with the balance consideration between daily cost and renumbering 339 cost. 341 - Reduce the address preferred time or valid time or both. 343 Long-lifetime addresses may cause issues for renumbering events. 344 Particularly, some offline hosts may reconnect back using these 345 addresses after renumbering events. Shorter preferred lifetime 346 with relevant long valid lifetime may get short transition period 347 for renumbering event and avoid address renew too frequent. 349 - Reduce the DNS record TTL. 351 The DNS record TTL on the local DNS server should be manipulated 352 to ensure that stale addresses are not cached. 354 - Reduce the DNS configuration lifetime on the hosts. 356 Since the DNS server could be renumbered as well, the DNS 357 configuration lifetime on the hosts should also be reduced if 358 renumbering events are expected. The DNS configuration can be done 359 through either ND [RFC6106] or DHCPv6 [RFC3646]. However, DHCPv6 360 DNS option does not include associated lifetime. It should be 361 updated. 363 4.3. Considerations and Recommendations during Renumbering Operation 365 Renumbering events are not instantaneous events. Normally, there is a 366 transition period, in which both the old prefix and the new prefix 367 are used in the site. Better network design and management, better 368 pre-preparation and longer transition period are helpful to reduce 369 the issues during renumbering operation. 371 - Within/without a flag day 373 As is described in [RFC4192], "a 'flag day' is a procedure in 374 which the network, or a part of it, is changed during a planned 375 outage, or suddenly, causing an outage while the network 376 recovers." 378 If renumbering event is processed within a flag day, the network 379 service/connectivity will be outage for a period till the 380 renumbering event is completed. It is efficient and provides 381 convenient for network operation and management. But network 382 outage is usually unacceptable for end users and the enterprises. 383 Renumbering procedure without a flag day provides smooth addresses 384 switching, but much more operational complexity and difficulty is 385 introduced. 387 - Transition period 388 If renumbering transition period is longer than all addresses 389 lifetime, after which the addresses lease expire, each host will 390 automatically pick up its new IP address. In this case, it would 391 be the DHCP server or Router Advertisement itself that 392 automatically accomplishes client renumbering. 394 - Network initiative enforced renumbering 396 If the network has to enforce renumbering before addresses lease 397 expire, the network should initiate enforcement messages, either 398 in Router Advertisement messages or DHCPv6 RECONFIGURE messages. 400 - Impact to branch/main sites 402 Renumbering in main/branch site may cause impact on branch/main 403 site communication. The routes, ingress filtering of site's 404 gateways, and DNS may need to be updated. This needs carefully 405 planning and organizing. 407 - DNS record update and DNS configuration on hosts 409 DNS records should be updated if hosts are renumbered. If the site 410 depends on ISP's DNS system, it should report the new host's DNS 411 records to its ISP. During the transition period, both old and new 412 DNS records are valid. If the TTL of DNS records is shorter than 413 the transition period, administrative operation may not be 414 necessary. 416 DNS configuration on hosts should be updated if local recursive 417 DNS servers are renumbered. During the transition period, both old 418 and new DNS addresses may co-exist on the hosts. If the lifetime 419 of DNS configuration is shorter than the transition period, name 420 resolving failure may not be reduced to minimum. A notification 421 mechanism may be needed to indicate the hosts that a renumbering 422 event of local recursive DNS happens or is going to take place. 424 - Router awareness 426 In a site with multiple border routers, all border routers should 427 be aware of partial renumbering in order to correctly handle 428 inbound packets. Internal forwarding tables need to be updated. 430 - Border filtering 432 In a multihomed site, an egress router to ISP A could normally 433 filter packets with source addresses from other ISPs. The egress 434 router connecting to ISP A should be notified if the egress router 435 connecting to ISP B initiates a renumbering event in order to 436 properly act filter function. 438 - Tunnel concentrator renumbering 440 Tunnel concentrator itself might be renumbered. This change should 441 be reconfigured to relevant hosts or router, unless the 442 configuration of tunnel concentrator was based on FQDN. 444 5. Gap Inventory 446 This section lists a few issues that still remain unsolvable. Some of 447 them may be inherently unsolvable. 449 - Manual or script-driven procedures will break the completely 450 automatic host renumbering. 452 - Some environments like embedded systems might not use DHCP or 453 SLAAC and even configuration scripts might not be an option. 454 This creates special problems that no general-purpose solution 455 is likely to address. 457 - TCP and UDP flows can't survive at renumbering event at either 458 end. 460 - Some address configuration data might be widely dispersed and 461 much harder to find, even will inevitably be found only after 462 the renumbering event. 464 - The embedding of IPv6 unicast addresses into multicast 465 addresses and the embedded-RP (Rendezvous Point) [RFC3956] will 466 cause issues when renumbering. 468 - Changing the unicast source address of a multicast sender might 469 also be an issue for receivers. 471 - When a renumbering event takes place, entries in the state 472 table of tunnel concentrator that happen to contain the 473 affected addresses will become invalid and will eventually time 474 out. However, this can be considered as harmless though it 475 takes sources on these devices for a while. 477 - A site that is listed in a black list can escape that list by 478 renumbering itself. The site itself of course will not 479 initiatively to report its renumbering and the black list may 480 not be able to monitor or discover the renumbering event. 482 - Multihomed site, using SLAAC for one address prefix and DHCPv6 483 for another, would clearly create a risk of inconsistent host 484 behaviour and operational confusion. 486 - The impact of portion renumbering may need to be analyzed 487 further. 489 Some of these issues can be considered as harmless or have minimum 490 impacts. 492 6. Security Considerations 494 A site that is listed in a black list can escape that list by 495 renumbering itself. 497 Any automatic renumbering scheme has a potential exposure to 498 hijacking at the moment that a new address is announced. Proper 499 network security mechanisms should be employed. SEND is recommended 500 to replace ND. Alternatively, certain lightweight renumbering 501 specific security mechanism may be developed in the future. DHCPv6 502 build-in secure mechanisms, like Secure DHCPv6 503 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages 504 [RFC3315] are recommended. 506 The security updates will need to be made in two stages (immediately 507 before and immediately after the event). 509 [Editor note: this section needs further work.] 511 7. IANA Considerations 513 This draft does not request any IANA action. 515 8. Acknowledgements 517 This work is illumined by RFC5887, so thank for RFC 5887 authors, 518 Randall Atkinson and Hannu Flinck. Useful ideas were also illumined 519 by documents from Tim Chown and Fred Baker. The authors also want to 520 thank Wesley George, Olivier Bonaventure and other 6renum members for 521 valuable comments. 523 9. Change Log [RFC Editor please remove] 525 draft-jiang-6renum-enterprise-00, original version, 2011-07-01 527 10. References 529 10.1. Normative References 531 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service 532 Location Protocol, Version 2", RFC 2608, June 1999. 534 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 535 M. Carney, "Dynamic Host Configuration Protocol for IPv6 536 (DHCPv6)", RFC 3315, July 2003. 538 [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic 539 Host Configuration Protocol (DHCP) version 6", RFC 3633, 540 December 2003. 542 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host 543 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 544 December 2003. 546 [RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous 547 Point (RP) Address in an IPv6 Multicast Address", RFC 3956, 548 November 2004 550 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander 551 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 553 [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast 554 Addresses", RFC 4193, October 2005. 556 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 557 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 558 September 2007. 560 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 561 Address Autoconfiguration", RFC 4862, September 2007. 563 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet 564 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 565 September 2010. 567 [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli 568 "IPv6 Router Advertisement Option for DNS Configuration", 569 RFC 6106, November 2011. 571 10.2. Informative References 573 [RFC2071] Ferguson, P., and H. Berkowitz., "Network Renumbering 574 Overview: Why would I want it and what is it anyway?", RFC 575 2071, January 1997. 577 [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support 578 IPv6 Address Aggregation and Renumbering", RFC 2874, July 579 2000. 581 [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support 582 for Internet Protocol version 6 (IPv6)", RFC 3364, August 583 2002. 585 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 586 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 587 September 2005. 589 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 590 Still Needs Work", RFC 5887, May 2010. 592 [I-D.ietf-dhc-secure-dhcpv6] 593 Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working 594 in progress. 596 [I-D.ietf-dhc-host-gen-id] 597 S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in 598 DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), 599 April, 2011. 601 [I-D.liu-6renum-gap-analysis] 602 Liu, B., and S. Jiang, "IPv6 Site Renumbering Gap Analysis", 603 working in progress. 605 Author's Addresses 607 Sheng Jiang 608 Huawei Technologies Co., Ltd 609 Huawei Building, No.3 Xinxi Rd., 610 Shang-Di Information Industry Base, Hai-Dian District, Beijing 611 P.R. China 612 EMail: jiangsheng@huawei.com 614 Bing Liu 615 Huawei Technologies Co., Ltd 616 Huawei Building, No.3 Xinxi Rd., 617 Shang-Di Information Industry Base, Hai-Dian District, Beijing 618 P.R. China 619 EMail: leo.liubing@huawei.com 621 Brian Carpenter 622 Department of Computer Science 623 University of Auckland 624 PB 92019 625 Auckland, 1142 626 New Zealand 627 EMail: brian.e.carpenter@gmail.com