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