idnits 2.17.1 draft-ietf-v6ops-ula-usage-considerations-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 : ---------------------------------------------------------------------------- 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 (February 6, 2016) is 3000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-dhcpv6-slaac-problem-06 -- 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 (~~), 2 warnings (==), 3 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: August 9, 2016 February 6, 2016 7 Considerations For Using Unique Local Addresses 8 draft-ietf-v6ops-ula-usage-considerations-00 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 August 9, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3 54 3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3 55 3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3 56 3.3. Provider Independent Address Space . . . . . . . . . . . 3 57 3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 58 3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4 59 4. Analysis and Operational Considerations for Scenarios Using 60 ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Connected Networks . . . . . . . . . . . . . . . . . . . 5 63 4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 5 64 4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7 65 4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9 66 5. General Considerations For Using ULAs . . . . . . . . . . . . 10 67 5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10 68 5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10 69 6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 11 70 6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11 71 6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11 72 6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11 73 6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11 74 6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11 75 6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 10.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 Unique Local Addresses (ULA) is defined in [RFC4193], and it is an 87 alternative to site-local address (deprecated in [RFC3879]). But the 88 two kind of addresses are not the same. ULAs are defined as a global 89 scope address space. However, they are not intended to be used 90 globally on the public Internet; in contrast, they are mostly used 91 locally, for example, in isolated networks, internal networks, or 92 VPNs. 94 Global scope yet local usage, this special feature has confused 95 network operators more or less. This document aims to introduce the 96 usage of ULAs in various scenarios, provide some operational 97 considerations, and clarify the advantages and disadvantages of the 98 usage in each scenario. Thus, the administrators could choose to use 99 ULAs in a certain way that considered benificial for them. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119] when they appear in ALL CAPS. When these words are not in 107 ALL CAPS (such as "should" or "Should"), they have their usual 108 English meanings, and are not to be interpreted as [RFC2119] key 109 words. 111 3. Analysis of ULA Features 113 3.1. Automatically Generated 115 ULA prefixes can be automatically generated using the algorithms 116 described in [RFC4193]. This feature allows automatic prefix 117 allocation. Thus one can get a network working immediately without 118 applying for prefix(es) from an RIR/LIR (Regional Internet Registry/ 119 Local Internet Registry). 121 3.2. Globally Unique 123 ULAs are intended to have an extremely low probability of collision. 124 The randomization of 40 bits in a ULA prefix is considered sufficient 125 enough to ensure a high degree of uniqueness (refer to [RFC4193] 126 Section 3.2.3 for details) and simplifies merging of networks by 127 avoiding the need to renumber overlapping IP address space. Such 128 overlapping was a major drawback to the deployment of private 129 [RFC1918] addresses in IPv4. 131 Note that, as described in [RFC4864], applications may treat ULAs in 132 practice like global-scope addresses, but address selection 133 algorithms may need to distinguish between ULAs and Global-scope 134 Unicast Addresses (GUAs) to ensure bidirectional communications. As 135 a further note, the default address selection policy table in 136 [RFC6724]) responds to this requirement. 138 3.3. Provider Independent Address Space 140 ULAs can be used for internal communications even without Internet 141 connectivity. They need no registration, so they can support on- 142 demand usage and do not carry any RIR/LIR burden of documentation or 143 fees. 145 3.4. Well Known Prefix 147 The prefixes of ULAs are well known thus they are easily identified 148 and filtered. 150 This feature is convenient for management of security policies and 151 troubleshooting. For example, network administrators can segregate 152 packets containing data which must stay in the internal network by 153 assigning ULAs to internal servers. Externally-destined data can be 154 sent to the Internet or telecommunication network by a separate 155 function, through an appropriate gateway/firewall. 157 3.5. Stable or Temporary Prefix 159 A ULA prefix can be generated once, at installation time or factory 160 reset, and then possibly never be changed. Alternatively, it can be 161 regenerated regularly, depending on deployment requirements. 163 4. Analysis and Operational Considerations for Scenarios Using ULAs 165 4.1. Isolated Networks 167 IP is used ubiquitously. Some networks like industrial control bus 168 (e.g. [RS-485], [SCADA], or even non-networked digital interfaces 169 like [MIL-STD-1397] have begun to use IP. In these kinds of 170 networks, the system may lack the ability to communicate with the 171 public networks. 173 As another example, there may be some networks in which the equipment 174 has the technical capability to connect to the Internet, but is 175 prohibited by administration or just temporarily not connected. 176 These networks may include separate financial networks, lab networks. 177 machine-to-machine (e.g. vehicle networks), sensor networks, or even 178 normal LANs, and can include very large numbers of addresses. 180 Serious disadvantages and impact on applications due to the use of 181 ambiguous address space have been well documented in [RFC1918]. 182 However, ULA is a straightforward way to assign the IP addresses in 183 the kinds of networks just described, with minimal administrative 184 cost or burden. Also, ULAs fit in multiple subnet scenarios, in 185 which each subnet has its own ULA prefix. For example, when 186 assigning vehicles with ULAs, it is then possible to separate in- 187 vehicle embedded networks into different subnets depending on real- 188 time situation. 190 However, each isolated network has the possibility to be connected in 191 the future. Administrators need to consider the following before 192 deciding whether to use ULAs: 194 o If the network eventually connects to another isolated or private 195 network, the potential for address collision arises. However, if 196 the ULAs were generated in the standard way, this will not be a 197 big problem. 199 o If the network eventually connects to the global Internet, then 200 the operator will need to add a new global prefix and ensure that 201 the address selection policy is properly set up on all interfaces. 203 Operational considerations: 205 o Prefix generation: randomly generated according to the algorithms 206 defined in [RFC4193] or manually assigned. Normally, automatic 207 generation of the prefixes is recommended, following [RFC4193]. 208 If there are some specific reasons that call for manual 209 assignment, administrators have to plan the prefixes carefully to 210 avoid collision. 212 o Prefix announcement: in some cases, networks might need to 213 announce prefixes to each other. For example, in vehicle networks 214 with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) 215 communication, prior knowledge of the respective prefixes is 216 unlikely. Hence, a prefix announcement mechanism is needed to 217 enable inter-vehicle communications based on IP. As one 218 possibility, such announcements could rely on extensions to the 219 Router Advertisement message of the Neighbor Discovery Protocol 220 (e.g., [I-D.petrescu-autoconf-ra-based-routing] and 221 [I-D.jhlee-mext-mnpp]). 223 4.2. Connected Networks 225 4.2.1. ULA-Only Deployment 227 In some situations, nodes in one network are assigned ULAs but not 228 Global Unicast Addresses (GUAs), but the nodes also need to 229 communicate with the outside network. There could be two approaches: 231 o Using Network Prefix Translation (NPTv6) 233 NPTv6[RFC6296] is an experimental specification that provides a 234 stateless one-to-one mapping between internal addresses and 235 external addresses. Translating ULA prefixes into GUA prefixes 236 is an use case of this specification. 238 NPTv6 works differently from traditional stateful NAT/NAPT 239 (which is discouraged in [RFC5902]). So it does not create 240 several of the problems known to exsit with other kinds of NATs 241 as discussed in [RFC2993] and [RFC3027]. However, NPTv6 242 Translation does create difficulties for some kinds of 243 applications. (Please refer to Section 5 of [RFC6296] for 244 detailed analysis.) 246 o Using Application-Layer Proxies 248 In this approach, the proxies terminate the network-layer 249 connectivity of the hosts and associate separate internal and 250 external connections. 252 In some environments (e.g., information security sensitive 253 enterprises or government departments), central control is 254 exercised by allowing the endpoints to connect to the Internet 255 only through a proxy. With IPv4, using private address space 256 with proxies is an effective and common practice for this 257 purpose, and it is natural to pick ULA as its counterpart in 258 IPv6. 260 o Controversies of ULA-only Deployment 262 The comunity has strong controversies of ULA-only deployment in 263 connected networks. 265 The main reason of those who are in favor of using ULAs this 266 way is that it could get provider independent addresses or get 267 connected from the isolated stage without applying to any RIRs/ 268 LIRs. This might be a essential benefit for the vast number of 269 small organizations, for saving time and address fee. 271 For those who are strongly against this usage, the main reason 272 is to avoid breaking the end-to-end transparence. Because 273 people have suffered from the NAT/Proxy middle boxes so much in 274 the IPv4 ear, there is no reason to continue the suffering when 275 IPv6 is available. 277 So, according to the controversy, this document does not 278 consider ULA+NPTv6/Proxy as a first choice for normal cases. 279 Rather, this document considers ULA+PA (Provider Aggregated) as 280 a better approach to connect to the global network when ULAs 281 are expected to be retained. The use of ULA+PA is discussed in 282 detail in Section 4.2.2 below. 284 Operational considerations: 286 o Firewall deployment: [RFC6296] points out that an NPTv6 translator 287 does not have the same security properties as a traditional NAT44, 288 and hence needs be supplemented with a firewall if security at the 289 boundary is an issue. The operator has to decide where to locate 290 the firewall. 292 - If the firewall is located outside the NPTv6 translator, then 293 filtering is based on the translated GUA prefixes, and when the 294 internal ULA prefixes are renumbered, the filtering rules do 295 not need to be changed. However, when the GUA prefixes of the 296 NPTv6 are renumbered, the filtering rules need to be updated 297 accordingly.). 299 - If the firewall is located inside the NPTv6 translator, the 300 filtering is then based on the ULA prefixes, and the rules need 301 to be updated correspondingly. There is no need to update when 302 the NPTv6 GUA prefixes are renumbered. 304 4.2.2. ULAs along with PA Addresses 306 Two classes of network might need to use ULA with PA (Provider 307 Aggregated) addresses: 309 o Home network. Home networks are normally assigned with one or 310 more globally routed PA prefixes to connect to the uplink of an 311 ISP. In addition, they may need internal routed networking even 312 when the ISP link is down. Then ULA is a proper tool to fit the 313 requirement. [RFC7084] requires the CPE to support ULA. Note: 314 ULAs provide more benefit for multiple-segment home networks; for 315 home networks containing only one segment, link-local addresses 316 are better alternatives. 318 o Enterprise network. An enterprise network is usually a managed 319 network with one or more PA prefixes or with a PI prefix, all of 320 which are globally routed. The ULA can be used to improve 321 internal connectivity and make it more resilient, or to isolate 322 certain functions like OAM for servers. 324 Benefits of Using ULAs in this scenario: 326 o Separated local communication plane: for either home networks or 327 enterprise networks, the main purpose of using ULAs along with PA 328 addresses is to provide a logically local routing plane separated 329 from the global routing plane. The benefit is to ensure stable 330 and specific local communication regardless of the ISP uplink 331 failure. This benefit is especially meaningful for the home 332 network or for private OAM function in an enterprise. 334 o Renumbering: in some special cases such as renumbering, enterprise 335 administrators may want to avoid the need to renumber their 336 internal-only, private nodes when they have to renumber the PA 337 addresses of the rest of the network because they are changing 338 ISPs, because the ISP has restructured its address allocations, or 339 for some other reason. In these situations, ULA is an effective 340 tool for addressing internal-only nodes. Even public nodes can 341 benefit from ULA for renumbering, on their internal interfaces. 342 When renumbering, as [RFC4192] suggests, old prefixes continue to 343 be valid until the new prefix(es) is(are) stable. In the process 344 of adding new prefix(es) and deprecating old prefix(es), it is not 345 easy to keep local communication disentangled from global routing 346 plane change. If we use ULAs for local communication, the 347 separated local routing plane can isolate the effects of global 348 routing change. 350 Drawbacks: 352 o Operational Complexity: there are some arguments that in practice 353 the use of ULA+PA creates additional operational complexity. This 354 is not a ULA-specific problem; the multiple-addresses-per- 355 interface is an important feature of IPv6 protocol. Nevertheless, 356 running multiple prefixes needs more operational consideration 357 than running a single one. 359 Operational considerations: 361 o Default Routing: connectivity may be broken if ULAs are used as 362 default route. When using RIO (Route Information Option) in 363 [RFC4191], specific routes can be added without a default route, 364 thus avoiding bad user experience due to timeouts on ICMPv6 365 redirects. This behavior was well documented in [RFC7084] as rule 366 ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default 367 router with a Router Lifetime greater than zero whenever all of 368 its configured and delegated prefixes are ULA prefixes." and along 369 with rule L-3 "An IPv6 CE router MUST advertise itself as a router 370 for the delegated prefix(es) (and ULA prefix if configured to 371 provide ULA addressing) using the "Route Information Option" 372 specified in Section 2.3 of [RFC4191]. This advertisement is 373 independent of having or not having IPv6 connectivity on the WAN 374 interface.". However, it needs to be noticed that current OSes 375 don't all support [RFC4191]. 377 o SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled 378 in one network simultaneously; the administrators need to 379 carefully plan how to assign ULA and PA prefixes in accordance 380 with the two mechanisms. The administrators need to know the 381 current issue of the SLAAC/DHCPv6 interaction (please refer to 382 [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details). 384 o Address selection: As mentioned in [RFC5220], there is a 385 possibility that the longest matching rule will not be able to 386 choose the correct address between ULAs and global unicast 387 addresses for correct intra-site and extra-site communication. 388 [RFC6724] claims that a site-specific policy entry can be used to 389 cause ULAs within a site to be preferred over global addresses. 391 o DNS relevant: if administrators choose not to do reverse DNS 392 delegation inside of their local control of ULA prefixes, a 393 significant amount of information about the ULA population may 394 leak to the outside world. Because reverse queries will be made 395 and naturally routed to the global reverse tree, so external 396 parties will be exposed to the existence of a population of ULA 397 addresses. [ULA-IN-WILD] provides more detailed situations on 398 this issue. Administrators may need a split DNS to separate the 399 queries from internal and external for ULA entries and GUA 400 entries. 402 4.3. IPv4 Co-existence Considerations 404 Generally, this document does not consider IPv4 to be in scope. But 405 regarding ULA, there is a special case needs to be recognized, which 406 is described in Section 3.2.2 of [RFC5220]. When an enterprise has 407 IPv4 Internet connectivity but does not yet have IPv6 Internet 408 connectivity, and the enterprise wants to provide site-local IPv6 409 connectivity, a ULA is the best choice for site-local IPv6 410 connectivity. Each employee host will have both an IPv4 global or 411 private address and a ULA. Here, when this host tries to connect to 412 an outside node that has registered both A and AAAA records in the 413 DNS, the host will choose AAAA as the destination address and the ULA 414 for the source address according to the IPv6 preference of the 415 default policy table defined in the old address selection standard 416 [RFC3484]. This will clearly result in a connection failure. The 417 new address selection standard [RFC6724] has corrected this behavior 418 by preferring IPv4 than ULAs in the default policy table. However, 419 there are still lots of hosts using the old standard [RFC3484], thus 420 this could be an issue in real networks. 422 Happy Eyeballs [RFC6555] solves this connection failure problem, but 423 unwanted timeouts will obviously lower the user experience. One 424 possible approach to eliminating the timeouts is to deprecate the 425 IPv6 default route and simply configure a scoped route on hosts (in 426 the context of this document, only configure the ULA prefix routes). 427 Another alternative is to configure IPv4 preference on the hosts, and 428 not include DNS A records but only AAAA records for the internal 429 nodes in the internal DNS server. Then outside nodes have both A and 430 AAAA records and can be connected through IPv4 as default and 431 internal nodes can always connect through IPv6. But since IPv6 432 preference is default, changing the default in all nodes is not 433 suitable at scale. 435 5. General Considerations For Using ULAs 437 5.1. Do Not Treat ULA Equal to RFC1918 439 ULA and [RFC1918] are similar in some aspects. The most obvious one 440 is as described in Section 3.1.3 that ULA provides an internal 441 address independence capability in IPv6 that is similar to how 442 [RFC1918] is commonly used. ULA allows administrators to configure 443 the internal network of each platform the same way it is configured 444 in IPv4. Many organizations have security policies and architectures 445 based around the local-only routing of [RFC1918] addresses and those 446 policies may directly map to ULA [RFC4864]. 448 But this does not mean that ULA is equal to an IPv6 version of 449 [RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for 450 global connectivity. But it is not necessary to combine ULAs with 451 any kind of NAT. Operators can use ULA for local communications 452 along with global addresses for global communications (see 453 Section 4.2.2). This is a big advantage brought by default support 454 of multiple-addresses-per-interface feature in IPv6. (People may 455 still have a requirement for NAT with ULA, this is discussed in 456 Section 4.2.1. But people also need to keep in mind that ULA is not 457 intentionally designed for this kind of use case.) 459 Another important difference is the ability to merge two ULA networks 460 without renumbering (because of the uniqueness), which is a big 461 advantage over [RFC1918]. 463 5.2. Using ULAs in a Limited Scope 465 A ULA is by definition a prefix that is never advertised outside a 466 given domain, and is used within that domain by agreement of those 467 networked by the domain. 469 So when using ULAs in a network, the administrators need to clearly 470 set the scope of the ULAs and configure ACLs on relevant border 471 routers to block them out of the scope. And if internal DNS is 472 enabled, the administrators might also need to use internal-only DNS 473 names for ULAs and might need to split the DNS so that the internal 474 DNS server includes records that are not presented in the external 475 DNS server. 477 6. ULA Usages Considered Helpful 479 6.1. Used in Isolated Networks 481 As analyzed in Section 4.1, ULA is very suitable for isolated 482 networks. Especially when there are subnets in the isolated network, 483 ULA is a reasonable choice. 485 6.2. ULA along with PA 487 As described in Section 4.2.2, using ULAs along with PA addresses to 488 provide a logically separated local plane can benefit OAM functions 489 and renumbering. 491 6.3. Some Specific Use Cases 493 Along with the general scenarios, this section provides some specific 494 use cases that could benefit from using ULA. 496 6.3.1. Special Routing 498 For various reasons the administrators may want to have private 499 routing be controlled and separated from other routing. For example, 500 in the business-to-business case described in 501 [I-D.baker-v6ops-b2b-private-routing], two companies might want to 502 use direct connectivity that only connects stated machines, such as a 503 silicon foundry with client engineers that use it. A ULA provides a 504 simple way to assign prefixes that would be used in accordance with 505 an agreement between the parties. 507 6.3.2. Used as NAT64 Prefix 509 The NAT64 PREF64 is just a group of local fake addresses for the 510 DNS64 to point traffic to a NAT64. Using a ULA prefix as the PREF64 511 easily ensures that only local systems can use the translation 512 resources of the NAT64 system since the ULA is not intended to be 513 globally routable. The ULA helps clearly identify traffic that is 514 locally contained and destined to a NAT64. Using ULA for PREF64 is 515 deployed and it is an operational model. 517 But there is an issue needs to be noted. The NAT64 standard 518 [RFC6146] specifies that the PREF64 should align with [RFC6052], in 519 which the IPv4-Embedded IPv6 Address format was specified. If we 520 pick a /48 for NAT64, it happens to be a standard 48/ part of ULA 521 (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID). Then the 522 40bit of ULA is not violated by being filled with part of the 32bit 523 IPv4 address. This is important, because the 40bit assures the 524 uniqueness of ULA. If the prefix is shorter than /48, the 40bit 525 would be violated, and this could cause conformance issues. But it 526 is considered that the most common use case will be a /96 PREF64, or 527 even /64 will be used. So it seems this issue is not common in 528 current practice. 530 It is most common that ULA PREF64 will be deployed on a single 531 internal network, where the clients and the NAT64 share a common 532 internal network. ULA will not be effective as PREF64 when the 533 access network must use an Internet transit to receive the 534 translation service of a NAT64 since the ULA will not route across 535 the Internet. 537 According to the default address selection table specified in 538 [RFC6724], the host would always prefer IPv4 over ULA. This could be 539 a problem in NAT64-CGN scenario as analyzed in Section 8 of 540 [RFC7269]. So administrators need to add additional site-specific 541 address selection rules to the default table to steer traffic flows 542 going through NAT64-CGN. However, updating the default policy tables 543 in all hosts involves significant management cost. This may be 544 possible in an enterprise (using a group policy object, or other 545 configuration mechanisms), but it is not suitable at scale for home 546 networks. 548 6.3.3. Used as Identifier 550 ULAs could be self-generated and easily grabbed from the standard 551 IPv6 stack. And ULAs don't need to be changed as the GUA prefixes 552 do. So they are very suitable to be used as identifiers by the up 553 layer applications. And since ULA is not intended to be globally 554 routed, it is not harmful to the routing system. 556 Such kind of benefit has been utilized in real implementations. For 557 example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to 558 assign a topology-independent identifier to each client host 559 according to the following considerations: 561 o TCP connections between two end hosts wish to survive in network 562 changes. 564 o Sometimes one needs a constant identifier to be associated with a 565 key so that the Security Association can survive the location 566 changes. 568 It needs to be noticed again that in theory ULA has the possibility 569 of collision. However, the probability is desirably small enough and 570 can be ignored in most cases when ULAs are used as identifiers. 572 7. Security Considerations 574 Security considerations regarding ULAs, in general, please refer to 575 the ULA specification [RFC4193]. Also refer to [RFC4864], which 576 shows how ULAs help with local network protection. 578 As mentioned in Section 4.2.2, when using NPTv6, the administrators 579 need to know where the firewall is located to set proper filtering 580 rules. 582 Also as mentioned in Section 4.2.2, if administrators choose not to 583 do reverse DNS delegation inside their local control of ULA prefixes, 584 a significant amount of information about the ULA population may leak 585 to the outside world. 587 8. IANA Considerations 589 This memo has no actions for IANA. 591 9. Acknowledgements 593 Many valuable comments were received in the IETF v6ops WG mail list, 594 especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee 595 Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim 596 Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, 597 Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, 598 Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, 599 Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali 600 and Wesley George. 602 Some test of using ULA in the lab was done by our research partner 603 BNRC-BUPT (Broad Network Research Centre in Beijing University of 604 Posts and Telecommunications). Thanks for the work of Prof. 605 Xiangyang Gong and student Dengjia Xu. 607 Tom Taylor did a language review and revision throught the whole 608 document. The authors appreciate a lot for his help. 610 This document was produced using the xml2rfc tool [RFC2629] 611 (initially prepared using 2-Word-v2.0.template.dot.). 613 10. References 615 10.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 623 DOI 10.17487/RFC2629, June 1999, 624 . 626 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 627 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 628 . 630 10.2. Informative References 632 [I-D.baker-v6ops-b2b-private-routing] 633 Baker, F., "Business to Business Private Routing", draft- 634 baker-v6ops-b2b-private-routing-00 (work in progress), 635 July 2007. 637 [I-D.ietf-v6ops-dhcpv6-slaac-problem] 638 Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, 639 "DHCPv6/SLAAC Interaction Problems on Address and DNS 640 Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-06 641 (work in progress), February 2016. 643 [I-D.jhlee-mext-mnpp] 644 Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix 645 Provisioning", draft-jhlee-mext-mnpp-00 (work in 646 progress), October 2009. 648 [I-D.petrescu-autoconf-ra-based-routing] 649 Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali, 650 "Router Advertisements for Routing between Moving 651 Networks", draft-petrescu-autoconf-ra-based-routing-05 652 (work in progress), July 2014. 654 [MIL-STD-1397] 655 "Military Standard, Input/Output Interfaces, Standard 656 Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989". 658 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 659 and E. Lear, "Address Allocation for Private Internets", 660 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 661 . 663 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 664 DOI 10.17487/RFC2993, November 2000, 665 . 667 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 668 with the IP Network Address Translator", RFC 3027, 669 DOI 10.17487/RFC3027, January 2001, 670 . 672 [RFC3484] Draves, R., "Default Address Selection for Internet 673 Protocol version 6 (IPv6)", RFC 3484, 674 DOI 10.17487/RFC3484, February 2003, 675 . 677 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 678 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 679 2004, . 681 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 682 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 683 November 2005, . 685 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 686 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 687 DOI 10.17487/RFC4192, September 2005, 688 . 690 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 691 E. Klein, "Local Network Protection for IPv6", RFC 4864, 692 DOI 10.17487/RFC4864, May 2007, 693 . 695 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 696 "Problem Statement for Default Address Selection in Multi- 697 Prefix Environments: Operational Issues of RFC 3484 698 Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008, 699 . 701 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 702 IPv6 Network Address Translation", RFC 5902, 703 DOI 10.17487/RFC5902, July 2010, 704 . 706 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 707 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 708 DOI 10.17487/RFC6052, October 2010, 709 . 711 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 712 NAT64: Network Address and Protocol Translation from IPv6 713 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 714 April 2011, . 716 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 717 "Understanding Apple's Back to My Mac (BTMM) Service", 718 RFC 6281, DOI 10.17487/RFC6281, June 2011, 719 . 721 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 722 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 723 . 725 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 726 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 727 2012, . 729 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 730 "Default Address Selection for Internet Protocol Version 6 731 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 732 . 734 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 735 Requirements for IPv6 Customer Edge Routers", RFC 7084, 736 DOI 10.17487/RFC7084, November 2013, 737 . 739 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 740 Deployment Options and Experience", RFC 7269, 741 DOI 10.17487/RFC7269, June 2014, 742 . 744 [RS-485] "Electronic Industries Association (1983). Electrical 745 Characteristics of Generators and Receivers for Use in 746 Balanced Multipoint Systems. EIA Standard RS-485.". 748 [SCADA] "Boyer, Stuart A. (2010). SCADA Supervisory Control and 749 Data Acquisition. USA: ISA - International Society of 750 Automation.". 752 [ULA-IN-WILD] 753 "G. Michaelson, "conference.apnic.net/data/36/apnic- 754 36-ula_1377495768.pdf"". 756 Authors' Addresses 758 Bing Liu 759 Huawei Technologies 760 Q14, Huawei Campus, No.156 Beiqing Road 761 Hai-Dian District, Beijing, 100095 762 P.R. China 764 Email: leo.liubing@huawei.com 766 Sheng Jiang 767 Huawei Technologies 768 Q14, Huawei Campus, No.156 Beiqing Road 769 Hai-Dian District, Beijing, 100095 770 P.R. China 772 Email: jiangsheng@huawei.com