idnits 2.17.00 (12 Aug 2021) /tmp/idnits29009/draft-ietf-v6ops-ula-usage-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 1888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2993' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC3027' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC5902' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 552, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) -- No information found for draft-petrescu-autoconf-ra-based-routing - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Informational Huawei Technologies 5 Expires: September 14, 2017 March 13, 2017 7 Considerations For Using Unique Local Addresses 8 draft-ietf-v6ops-ula-usage-considerations-02 10 Abstract 12 This document provides considerations for using IPv6 Unique Local 13 Addresses (ULAs). Based on an analysis of different ULA usage 14 scenarios, this document identifies use cases where ULA addresses are 15 helpful as well as potential problems caused by using them. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 14, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. General Considerations For Using ULAs . . . . . . . . . . . . 3 54 3.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 3 55 3.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 4 56 4. Analysis and Operational Considerations for Scenarios Using 57 ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. ULA-only in Isolated Networks . . . . . . . . . . . . . . 4 59 4.2. ULA+PA in Connected Networks . . . . . . . . . . . . . . 5 60 4.3. ULA-Only in Connected Networks . . . . . . . . . . . . . 7 61 4.4. Some Specific Use Cases . . . . . . . . . . . . . . . . . 8 62 4.4.1. Special Routing . . . . . . . . . . . . . . . . . . . 8 63 4.4.2. Used as Identifier . . . . . . . . . . . . . . . . . 8 64 4.5. IPv4 Co-existence Considerations . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Unique Local Addresses (ULA) is defined in [RFC4193], and it is an 76 alternative to site-local address (deprecated in [RFC3879]). ULAs 77 have the following features: 79 - Automatically Generated 81 ULA prefixes can be automatically generated using the algorithms 82 described in [RFC4193]. This feature allows automatic prefix 83 allocation. Thus one can get a network working immediately 84 without applying for prefix(es) from an RIR/LIR (Regional Internet 85 Registry/Local Internet Registry). 87 - Globally Unique 89 ULAs are defined as a global scope address space. However, they 90 are not intended to be used globally on the public Internet; in 91 contrast, they are mostly used locally, for example, in isolated 92 networks, internal networks, or VPNs. 94 ULAs are intended to have an extremely low probability of 95 collision. The randomization of 40 bits in a ULA prefix is 96 considered sufficient enough to ensure a high degree of uniqueness 97 (refer to [RFC4193] Section 3.2.3 for details) and simplifies 98 merging of networks by avoiding the need to renumber overlapping 99 IP address space. 101 - Provider Independent Address Space 103 ULAs can be used for internal communications even without Internet 104 connectivity. They need no registration, so they can support on- 105 demand usage and do not carry any RIR/LIR burden of documentation 106 or fees. 108 - Well Known Prefix 110 The prefixes of ULAs are well known thus they are easily 111 identified and filtered. 113 This document aims to introduce the usage of ULAs in various 114 scenarios, provide some operational considerations, and clarify the 115 advantages and disadvantages of the usage in each scenario. Thus, 116 the administrators could choose to use ULAs in a certain way that 117 considered benificial for them. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119] when they appear in ALL CAPS. When these words are not in 125 ALL CAPS (such as "should" or "Should"), they have their usual 126 English meanings, and are not to be interpreted as [RFC2119] key 127 words. 129 3. General Considerations For Using ULAs 131 3.1. Do Not Treat ULA Equal to RFC1918 133 ULA and [RFC1918] are similar in some aspects. The most obvious one 134 is as described in Section 3.1.3 that ULA provides an internal 135 address independence capability in IPv6 that is similar to how 136 [RFC1918] is commonly used. ULA allows administrators to configure 137 the internal network of each platform the same way it is configured 138 in IPv4. Many organizations have security policies and architectures 139 based around the local-only routing of [RFC1918] addresses and those 140 policies may directly map to ULA [RFC4864]. 142 But this does not mean that ULA is equal to an IPv6 version of 143 [RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for 144 global connectivity. But it is not necessary to combine ULAs with 145 any kind of NAT. Operators can use ULA for local communications 146 along with global addresses for global communications (see 147 Section 4.2). This is a big advantage brought by default support of 148 multiple-addresses-per-interface feature in IPv6. (People may still 149 have a requirement for NAT with ULA, this is discussed in 150 Section 4.3. But people also need to keep in mind that ULA is not 151 intentionally designed for this kind of use case.) 153 Another important difference is the ability to merge two ULA networks 154 without renumbering (because of the uniqueness), which is a big 155 advantage over [RFC1918]. 157 3.2. Using ULAs in a Limited Scope 159 A ULA is by definition a prefix that is never advertised outside a 160 given domain, and is used within that domain by agreement of those 161 networked by the domain. 163 So when using ULAs in a network, the administrators need to clearly 164 set the scope of the ULAs and configure ACLs on relevant border 165 routers to block them out of the scope. And if internal DNS is 166 enabled, the administrators might also need to use internal-only DNS 167 names for ULAs and might need to split the DNS so that the internal 168 DNS server includes records that are not presented in the external 169 DNS server. 171 4. Analysis and Operational Considerations for Scenarios Using ULAs 173 4.1. ULA-only in Isolated Networks 175 IP is used ubiquitously. Some networks like industrial control bus 176 (e.g. [RS-485], [SCADA], or even non-networked digital interfaces 177 like [MIL-STD-1397] have begun to use IP. In these kinds of 178 networks, the system may lack the ability to communicate with the 179 public networks. 181 As another example, there may be some networks in which the equipment 182 has the technical capability to connect to the Internet, but is 183 prohibited by administration. These networks may include data center 184 networks, separate financial networks, lab networks. machine-to- 185 machine (e.g. vehicle networks), sensor networks, or even normal 186 LANs, and can include very large numbers of addresses. 188 ULA is a straightforward way to assign the IP addresses in the kinds 189 of networks just described, with minimal administrative cost or 190 burden. Also, ULAs fit in multiple subnet scenarios, in which each 191 subnet has its own ULA prefix. For example, when assigning vehicles 192 with ULAs, it is then possible to separate in-vehicle embedded 193 networks into different subnets depending on real-time situation. 195 However, each isolated network has the possibility to be connected in 196 the future. Administrators need to consider the following before 197 deciding whether to use ULAs: 199 o If the network eventually connects to another isolated or private 200 network, the potential for address collision arises. However, if 201 the ULAs were generated in the standard way, this will not be a 202 big problem. 204 o If the network eventually connects to the global Internet, then 205 the operator will need to add a new global prefix and ensure that 206 the address selection policy is properly set up on all interfaces. 208 Operational considerations: 210 o Prefix generation: randomly generated according to the algorithms 211 defined in [RFC4193] or manually assigned. Normally, automatic 212 generation of the prefixes is recommended, following [RFC4193]. 213 If there are some specific reasons that call for manual 214 assignment, administrators have to plan the prefixes carefully to 215 avoid collision. 217 o Prefix announcement: in some cases, networks might need to 218 announce prefixes to each other. For example, in vehicle networks 219 with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) 220 communication, prior knowledge of the respective prefixes is 221 unlikely. Hence, a prefix announcement mechanism is needed to 222 enable inter-vehicle communications based on IP. As one 223 possibility, such announcements could rely on extensions to the 224 Router Advertisement message of the Neighbor Discovery Protocol 225 (e.g., [I-D.petrescu-autoconf-ra-based-routing] and 226 [I-D.jhlee-mext-mnpp]). 228 4.2. ULA+PA in Connected Networks 230 Two classes of network might need to use ULA with PA (Provider 231 Aggregated) addresses: 233 o Home network. Home networks are normally assigned with one or 234 more globally routed PA prefixes to connect to the uplink of an 235 ISP. In addition, they may need internal routed networking even 236 when the ISP link is down. Then ULA is a proper tool to fit the 237 requirement. [RFC7084] requires the CPE to support ULA. Note: 238 ULAs provide more benefit for multiple-segment home networks; for 239 home networks containing only one segment, link-local addresses 240 are better alternatives. 242 o Enterprise network. An enterprise network is usually a managed 243 network with one or more PA prefixes or with a PI prefix, all of 244 which are globally routed. The ULA can be used to improve 245 internal connectivity and make it more resilient, or to isolate 246 certain functions like OAM for servers. 248 Benefits of Using ULAs in this scenario: 250 o Separated local communication plane: for either home networks or 251 enterprise networks, the main purpose of using ULAs along with PA 252 addresses is to provide a logically local routing plane separated 253 from the global routing plane. The benefit is to ensure stable 254 and specific local communication regardless of the ISP uplink 255 failure. This benefit is especially meaningful for the home 256 network or for private OAM function in an enterprise. 258 o Renumbering: in some special cases such as renumbering, enterprise 259 administrators may want to avoid the need to renumber their 260 internal-only, private nodes when they have to renumber the PA 261 addresses of the rest of the network because they are changing 262 ISPs, because the ISP has restructured its address allocations, or 263 for some other reason. In these situations, ULA is an effective 264 tool for addressing internal-only nodes. Even public nodes can 265 benefit from ULA for renumbering, on their internal interfaces. 266 When renumbering, as [RFC4192] suggests, old prefixes continue to 267 be valid until the new prefix(es) is(are) stable. In the process 268 of adding new prefix(es) and deprecating old prefix(es), it is not 269 easy to keep local communication disentangled from global routing 270 plane change. If we use ULAs for local communication, the 271 separated local routing plane can isolate the effects of global 272 routing change. 274 Drawbacks: 276 o Operational Complexity: there are some arguments that in practice 277 the use of ULA+PA creates additional operational complexity. This 278 is not a ULA-specific problem; the multiple-addresses-per- 279 interface is an important feature of IPv6 protocol. Nevertheless, 280 running multiple prefixes needs more operational consideration 281 than running a single one. 283 Operational considerations: 285 o Default Routing: connectivity may be broken if ULAs are used as 286 default route. When using RIO (Route Information Option) in 288 [RFC4191], specific routes can be added without a default route, 289 thus avoiding bad user experience due to timeouts on ICMPv6 290 redirects. This behavior was well documented in [RFC7084] as rule 291 ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default 292 router with a Router Lifetime greater than zero whenever all of 293 its configured and delegated prefixes are ULA prefixes." and along 294 with rule L-3 "An IPv6 CE router MUST advertise itself as a router 295 for the delegated prefix(es) (and ULA prefix if configured to 296 provide ULA addressing) using the "Route Information Option" 297 specified in Section 2.3 of [RFC4191]. This advertisement is 298 independent of having or not having IPv6 connectivity on the WAN 299 interface.". However, it needs to be noticed that current OSes 300 don't all support [RFC4191]. 302 o SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled 303 in one network simultaneously; the administrators need to 304 carefully plan how to assign ULA and PA prefixes in accordance 305 with the two mechanisms. The administrators need to know the 306 current issue of the SLAAC/DHCPv6 interaction (please refer to 307 [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details). 309 o Address selection: As mentioned in [RFC5220], there is a 310 possibility that the longest matching rule will not be able to 311 choose the correct address between ULAs and global unicast 312 addresses for correct intra-site and extra-site communication. 313 [RFC6724] claims that a site-specific policy entry can be used to 314 cause ULAs within a site to be preferred over global addresses. 316 o DNS relevant: if administrators choose not to do reverse DNS 317 delegation inside of their local control of ULA prefixes, a 318 significant amount of information about the ULA population may 319 leak to the outside world. Because reverse queries will be made 320 and naturally routed to the global reverse tree, so external 321 parties will be exposed to the existence of a population of ULA 322 addresses. [ULA-IN-WILD] provides more detailed situations on 323 this issue. Administrators may need a split DNS to separate the 324 queries from internal and external for ULA entries and GUA 325 entries. 327 4.3. ULA-Only in Connected Networks 329 In theory, a site numbered with ULAs only can get connected via a 330 NPTv6[RFC6296] (which is an experimental specification that provides 331 a stateless one-to-one mapping between internal addresses and 332 external addresses) or application-layer proxy. This approach could 333 get provider independent addresses or get connected from the isolated 334 stage without applying to any RIRs/LIRs. This might make small 335 organizations saving time and address fee. 337 However, this approach breaks the end-to-end transparence. People 338 have suffered from the NAT/Proxy middle boxes so much in the IPv4 339 ear, there is no reason to continue the suffering when IPv6 is 340 available. This document does not consider ULA+NPTv6/Proxy as a good 341 choice for normal cases. Rather, this document considers ULA+PA 342 (Provider Aggregated) as a better approach to connect to the global 343 network when ULAs are expected to be retained. 345 4.4. Some Specific Use Cases 347 Along with the general scenarios, this section provides some specific 348 use cases that could benefit from using ULA. 350 4.4.1. Special Routing 352 For various reasons the administrators may want to have private 353 routing be controlled and separated from other routing. For example, 354 in the business-to-business case described in 355 [I-D.baker-v6ops-b2b-private-routing], two companies might want to 356 use direct connectivity that only connects stated machines, such as a 357 silicon foundry with client engineers that use it. A ULA provides a 358 simple way to assign prefixes that would be used in accordance with 359 an agreement between the parties. 361 4.4.2. Used as Identifier 363 ULAs could be self-generated and easily grabbed from the standard 364 IPv6 stack. And ULAs don't need to be changed as the GUA prefixes 365 do. So they are very suitable to be used as identifiers by the up 366 layer applications. And since ULA is not intended to be globally 367 routed, it is not harmful to the routing system. 369 Such kind of benefit has been utilized in real implementations. For 370 example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to 371 assign a topology-independent identifier to each client host 372 according to the following considerations: 374 o TCP connections between two end hosts wish to survive in network 375 changes. 377 o Sometimes one needs a constant identifier to be associated with a 378 key so that the Security Association can survive the location 379 changes. 381 It needs to be noticed again that in theory ULA has the possibility 382 of collision. However, the probability is desirably small enough and 383 can be ignored in most cases when ULAs are used as identifiers. 385 4.5. IPv4 Co-existence Considerations 387 Generally, this document does not consider IPv4 to be in scope. But 388 regarding ULA, there is a special case needs to be recognized, which 389 is described in Section 3.2.2 of [RFC5220]. When an enterprise has 390 IPv4 Internet connectivity but does not yet have IPv6 Internet 391 connectivity, and the enterprise wants to provide site-local IPv6 392 connectivity, a ULA is the best choice for site-local IPv6 393 connectivity. Each employee host will have both an IPv4 global or 394 private address and a ULA. Here, when this host tries to connect to 395 an outside node that has registered both A and AAAA records in the 396 DNS, the host will choose AAAA as the destination address and the ULA 397 for the source address according to the IPv6 preference of the 398 default policy table defined in the old address selection standard 399 [RFC3484]. This will clearly result in a connection failure. The 400 new address selection standard [RFC6724] has corrected this behavior 401 by preferring IPv4 than ULAs in the default policy table. However, 402 there are still lots of hosts using the old standard [RFC3484], thus 403 this could be an issue in real networks. 405 Happy Eyeballs [RFC6555] solves this connection failure problem, but 406 unwanted timeouts will obviously lower the user experience. One 407 possible approach to eliminating the timeouts is to deprecate the 408 IPv6 default route and simply configure a scoped route on hosts (in 409 the context of this document, only configure the ULA prefix routes). 410 Another alternative is to configure IPv4 preference on the hosts, and 411 not include DNS A records but only AAAA records for the internal 412 nodes in the internal DNS server. Then outside nodes have both A and 413 AAAA records and can be connected through IPv4 as default and 414 internal nodes can always connect through IPv6. But since IPv6 415 preference is default, changing the default in all nodes is not 416 suitable at scale. 418 5. Security Considerations 420 Security considerations regarding ULAs, in general, please refer to 421 the ULA specification [RFC4193]. Also refer to [RFC4864], which 422 shows how ULAs help with local network protection. 424 As mentioned in Section 4.2, when using NPTv6, the administrators 425 need to know where the firewall is located to set proper filtering 426 rules. 428 Also as mentioned in Section 4.2, if administrators choose not to do 429 reverse DNS delegation inside their local control of ULA prefixes, a 430 significant amount of information about the ULA population may leak 431 to the outside world. 433 6. IANA Considerations 435 This memo has no actions for IANA. 437 7. Acknowledgements 439 Many valuable comments were received in the IETF v6ops WG mail list, 440 especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee 441 Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim 442 Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, 443 Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, 444 Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, 445 Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali 446 and Wesley George. 448 Some test of using ULA in the lab was done by our research partner 449 BNRC-BUPT (Broad Network Research Centre in Beijing University of 450 Posts and Telecommunications). Thanks for the work of Prof. 451 Xiangyang Gong and student Dengjia Xu. 453 Tom Taylor did a language review and revision throught the whole 454 document. The authors appreciate a lot for his help. 456 This document was produced using the xml2rfc tool [RFC2629] 457 (initially prepared using 2-Word-v2.0.template.dot.). 459 8. References 461 8.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 469 DOI 10.17487/RFC2629, June 1999, 470 . 472 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 473 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 474 . 476 8.2. Informative References 478 [I-D.baker-v6ops-b2b-private-routing] 479 Baker, F., "Business to Business Private Routing", draft- 480 baker-v6ops-b2b-private-routing-00 (work in progress), 481 July 2007. 483 [I-D.ietf-v6ops-dhcpv6-slaac-problem] 484 Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, 485 "DHCPv6/SLAAC Interaction Problems on Address and DNS 486 Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-07 487 (work in progress), August 2016. 489 [I-D.jhlee-mext-mnpp] 490 Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix 491 Provisioning", draft-jhlee-mext-mnpp-00 (work in 492 progress), October 2009. 494 [I-D.petrescu-autoconf-ra-based-routing] 495 Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali, 496 "Router Advertisements for Routing between Moving 497 Networks", draft-petrescu-autoconf-ra-based-routing-05 498 (work in progress), July 2014. 500 [MIL-STD-1397] 501 "Military Standard, Input/Output Interfaces, Standard 502 Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989". 504 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 505 and E. Lear, "Address Allocation for Private Internets", 506 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 507 . 509 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 510 DOI 10.17487/RFC2993, November 2000, 511 . 513 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 514 with the IP Network Address Translator", RFC 3027, 515 DOI 10.17487/RFC3027, January 2001, 516 . 518 [RFC3484] Draves, R., "Default Address Selection for Internet 519 Protocol version 6 (IPv6)", RFC 3484, 520 DOI 10.17487/RFC3484, February 2003, 521 . 523 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 524 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 525 2004, . 527 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 528 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 529 November 2005, . 531 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 532 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 533 DOI 10.17487/RFC4192, September 2005, 534 . 536 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 537 E. Klein, "Local Network Protection for IPv6", RFC 4864, 538 DOI 10.17487/RFC4864, May 2007, 539 . 541 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 542 "Problem Statement for Default Address Selection in Multi- 543 Prefix Environments: Operational Issues of RFC 3484 544 Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008, 545 . 547 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 548 IPv6 Network Address Translation", RFC 5902, 549 DOI 10.17487/RFC5902, July 2010, 550 . 552 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 553 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 554 DOI 10.17487/RFC6052, October 2010, 555 . 557 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 558 "Understanding Apple's Back to My Mac (BTMM) Service", 559 RFC 6281, DOI 10.17487/RFC6281, June 2011, 560 . 562 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 563 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 564 . 566 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 567 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 568 2012, . 570 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 571 "Default Address Selection for Internet Protocol Version 6 572 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 573 . 575 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 576 Requirements for IPv6 Customer Edge Routers", RFC 7084, 577 DOI 10.17487/RFC7084, November 2013, 578 . 580 [RS-485] "Electronic Industries Association (1983). Electrical 581 Characteristics of Generators and Receivers for Use in 582 Balanced Multipoint Systems. EIA Standard RS-485.". 584 [SCADA] "Boyer, Stuart A. (2010). SCADA Supervisory Control and 585 Data Acquisition. USA: ISA - International Society of 586 Automation.". 588 [ULA-IN-WILD] 589 "G. Michaelson, "conference.apnic.net/data/36/apnic- 590 36-ula_1377495768.pdf"". 592 Authors' Addresses 594 Bing Liu 595 Huawei Technologies 596 Q14, Huawei Campus, No.156 Beiqing Road 597 Hai-Dian District, Beijing, 100095 598 P.R. China 600 Email: leo.liubing@huawei.com 602 Sheng Jiang 603 Huawei Technologies 604 Q14, Huawei Campus, No.156 Beiqing Road 605 Hai-Dian District, Beijing, 100095 606 P.R. China 608 Email: jiangsheng@huawei.com