idnits 2.17.1 draft-liu-v6ops-ula-usage-analysis-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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4071 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6204' is mentioned on line 232, but not defined ** Obsolete undefined reference: RFC 6204 (Obsoleted by RFC 7084) == Missing Reference: 'RFC6052' is mentioned on line 312, but not defined == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft S. Jiang 3 Intended status: Best Current Practice Huawei Technologies 4 Expires: August 28, 2013 C. Byrne 5 T-Mobile USA 6 February 25, 2013 8 Guidance of Using Unique Local Addresses 9 draft-liu-v6ops-ula-usage-analysis-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 28, 2013. 28 Copyright Notice 30 Copyright (c) 2013 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents carefully, 37 as they describe your rights and restrictions with respect to this 38 document. 40 Abstract 42 This document provides guidance of how to use ULA. It analyzes ULA 43 usage scenarios and recommends use cases where ULA address may be 44 beneficially used. 46 Table of Contents 48 1. Introduction ................................................. 2 49 2. ULA usage analysis ........................................... 3 50 2.1. The features of ULA ..................................... 3 51 2.1.1. Self-assigned ...................................... 3 52 2.1.2. Globally unique .................................... 3 53 2.1.3. Independent address space .......................... 3 54 2.1.4. Well known prefix .................................. 4 55 2.1.5. Stable or Temporary Prefix ......................... 4 56 2.2. Enumeration of ULA use scenarios ........................ 4 57 2.2.1. Isolated network ................................... 4 58 2.2.2. Connected network .................................. 5 59 2.2.2.1. ULA-only Deployment ........................... 5 60 2.2.2.2. ULA along with GUA ............................ 6 61 3. Recommended ULA Use Cases .................................... 6 62 3.1. Used in Isolated Networks ............................... 6 63 3.2. ULA along with GUA ...................................... 6 64 3.3. Special Use Cases ....................................... 7 65 3.3.1. Special routing .................................... 7 66 3.3.2. Used as NAT64 prefix ............................... 7 67 3.3.3. Used as identifier ................................. 8 68 4. Security Considerations ...................................... 8 69 5. IANA Considerations .......................................... 8 70 6. Conclusions .................................................. 9 71 7. References ................................................... 9 72 7.1. Normative References .................................... 9 73 7.2. Informative References .................................. 9 74 8. Acknowledgments ............................................. 10 76 1. Introduction 78 Unique Local Addresses (ULAs) are defined in [RFC4193] as provider- 79 independent prefixes that can be used on isolated networks, internal 80 networks, and VPNs. Although ULAs may be treated like global scope by 81 applications, normally they are not used on the publicly routable 82 internet. 84 However, the ULAs haven't been widely used since IPv6 hasn't been 85 widely deployed yet. 87 The use of ULA addresses in various types of networks has been confused 88 for network operators. Some network operators believe ULAs are not 89 useful at all while other network operators run their entire networks on 90 ULA address space. This document attempts to clarify the advantages and 91 disadvantages of ULAs and how they can be most appropriately used. 93 2. ULA usage analysis 95 2.1. The features of ULA 97 2.1.1. Self-assigned 99 ULA is self-assigned, this feature allows automatic address 100 allocation, which is beneficial for some lightweight systems and can 101 leverage minimal human management. 103 2.1.2. Globally unique 105 ULA is intended to be globally unique to avoid collision. Since the 106 hosts assigned with ULA may occasionally be merged into one network, 107 this uniqueness is necessary. The prefix uniqueness is based on 108 randomization of 40 bits and is considered random enough to ensure a 109 high degree of uniqueness (refer to [RFC4193] section 3.2.3 for 110 details)and make merging of networks simple and without the need to 111 renumbering overlapping IP address space. Overlapping is cited as a 112 deficiency with how [RFC1918] addresses were deployed, and ULA was 113 designed to overcome this deficiency. 115 Notice that, as described in [RFC4864], in practice, applications may 116 treat ULAs like global-scope addresses, but address selection 117 algorithms may need to distinguish between ULAs and ordinary GUA 118 (Global-scope Unicast Address) to ensure bidirectional communications. 120 2.1.3. Independent address space 122 ULA provides an internal address independence capability in IPv6 that 123 is similar to how [RFC1918] is commonly used. ULA allows 124 administrators to configure the internal network of each platform the 125 same way it is configured in IPv4. But the ability to merge two ULA 126 networks without renumbering (because of the uniqueness) is a big 127 advantage over [RFC1918]. 129 On the other hand, many organizations have security policies and 130 architectures based around the local-only routing of [RFC1918] addresses 131 and those policies may directly map to ULA. ULA can be used for 132 internal communications without having any permanent or only 133 intermittent Internet connectivity. And it needs no registration so 134 that it can support on-demand usage and does not carry any RIR 135 documentation burden or disclosures. 137 2.1.4. Well known prefix 139 The prefixes of ULAs are well known and they are easy to be 140 identified and easy to be filtered. 142 This feature may be convenient to management of security policies and 143 troubleshooting. For example, the administrators can decide what 144 parameters have to be assembled or transmitted globally, by a 145 separate function, through an appropriate gateway/firewall, to the 146 Internet or to the telecom network. 148 2.1.5. Stable or Temporary Prefix 150 A ULA prefix can be generated once, at installation time or "factory 151 reset", and then never change unless the network manager wants to 152 change. Alternatively, it could be regenerated regularly, if desired 153 for some reason. 155 2.2. Enumeration of ULA use scenarios 157 In this section, we try to cover plausible possible ULA use case. 158 Some of them might have been discussed in other documents and are 159 briefly reviewed in this document as well as other potential valid 160 usage is discussed. 162 2.2.1. Isolated network 164 IP is used ubiquitously. Some networks like RS-485, or other type of 165 industrial control bus, or even non-networked digital interface like 166 MIL-STD-1397 began to use IP protocol. In such kind of networks, the 167 system might lack the ability/requirement of connecting to the 168 Internet. 170 Besides, some networks are explicitly designed to not connect to the 171 internet. These networks may include machine-to-machine, sensor networks, 172 or other types of SCADA networks which may include very large numbers of 173 addresses and explicitly prohibited from connect to the global internet 174 (electricity meters...). 176 ULA is a straightforward way to assign the IP addresses in these 177 kinds of networks with minimal administrative cost or burden. 179 2.2.2. Connected network 181 2.2.2.1. ULA-only Deployment 183 In some situations, hosts/interfaces are assigned with ULA-only, but 184 the networks need to communicate with the outside. For example, just 185 like many implementations of private IPv4 address space [RFC1918]. One 186 important reason of using private address space is the lack of IPv4 187 addresses, but this it is not an issue any more in IPv6. Another reason 188 is regarding with security, private address space is designed by some 189 administrators as one layer of a multilayer security. Such design is 190 also applicable in IPv6 with using ULAs. 192 But we should eliminate the misunderstanding that ULA is designed to 193 be the IPv6 version of [RFC1918] deployment model. If you chose non- 194 globally routable address space for some reasons, ULA is a nature 195 selection, but we need to know ULA itself is not designed for this 196 intention. 198 ULA-only in connected network may include the following two models. 200 o Using Network Prefix Translation 202 Network Prefix Translation (NPTv6) [RFC6296] is an experimental 203 specification that provides a stateless one to one mapping between 204 internal addresses and external addresses. 206 In some very constrained situations(for example, in the sensors), the 207 network needs ULA as the on-demand and stable addressing which 208 doesn't need much code to support address assignment mechanisms like 209 DHCP or ND. And the network also needs to connect to the outside, 210 then there can be a gateway to be the NAT which may not be so 211 sensitive to the constrained resource. This behavior could refer 212 NPTv6 [RFC6296]. 214 o Using application-layer proxies 216 The proxies terminate the network-layer connectivity of the hosts and 217 delegate the outgoing/incoming connections. 219 There may be some scenarios that need this kind of deployment for 220 some special purpose (strict application access control, content 221 monitoring, e.g.). 223 2.2.2.2. ULA along with GUA 225 There are two classes of network probably to use ULA with GUA 226 addresses: 228 o Home network. Home networks are normally assigned with one or more 229 globally routed PA prefixes to connect to the uplink of some an 230 ISP. And besides, they may need internal routed networking even 231 when the ISP link is down. Then ULA is a proper tool to fit the 232 requirement. And in [RFC6204], it requires the CPE to support ULA. 234 o Enterprise network. An enterprise network is usually a managed 235 network with one or more PA prefixes or with a PI prefix, all of 236 which are globally routed. The ULA could be used for internal 237 connectivity redundancy and better internal connectivity or 238 isolation of certain functions like OAM of servers. 240 3. Recommended ULA Use Cases 242 3.1. Used in Isolated Networks 244 As analyzed in section 2.2.1, ULA is very suitable for isolated 245 networks. Especially when you have subnets in the isolated networks, 246 ULA is almost the only choice. 248 3.2. ULA along with GUA 250 For either home networks or enterprise networks, the main purpose of 251 using ULA along with GUA is to provide a logically local routing 252 plane separated from the globally routing plane. The benefit is to 253 ensure stable and specific local communication regardless of the ISP 254 uplink failure. This benefit is especially meaningful for the home 255 network or private OAM function in an enterprise. 257 In some special cases such as renumbering, enterprise administrators 258 may want to avoid the need to renumber their internal-only, private 259 nodes when they have to renumber the PA addresses of the whole 260 network because of changing ISPs, ISPs restructure their address 261 allocations, or whatever reasons. In these situations, ULA is an 262 effective tool for the internal-only nodes. 264 Besides the internal-only nodes, the public nodes can also benefit 265 from ULA for renumbering. When renumbering, as RFC4192 suggested, it 266 has a period to keep using the old prefix(es) before the new 267 prefix(es) is(are) stable. In the process of adding new prefix(es) 268 and deprecating old prefix(es), it is not easy to keep the local 269 communication immune of global routing plane change. If we use ULA 270 for the local communication, the separated local routing plane can 271 isolate the affecting by global routing change. 273 But for the separated local routing plane, there always be some 274 argument that in practice the ULA+PA makes terrible operational 275 complexity. But it is not a ULA-specific problem; the multiple- 276 addresses-per-interface is an important feature of IPv6 protocol. 277 Running multiple prefixes in IPv6 might be very common, and we need 278 to adapt this new operational model than that in IPv4. 280 Another issue is mentioned in [RFC5220], there is a possibility that 281 the longest matching rule will not be able to choose the correct 282 address between ULAs and global unicast addresses for correct intra- 283 site and extra-site communication. In [RFC6724] , it claimed that a 284 site-specific policy entry can be used to cause ULAs within a site to 285 be preferred over global addresses. 287 3.3. Special Use Cases 289 3.3.1. Special routing 291 If you have a special routing scenario, of which 292 [draft-baker-v6ops-b2b-private-routing] is an example, for various 293 reasons you might want to have routing that you control and is 294 separate from other routing. In the b2b case, even though two 295 companies each have at least one ISP, they might choose to also use 296 direct connectivity that only connects stated machines, such as a 297 silicon foundry with client engineers that use it. A ULA provides a 298 simple way to obtain such a prefix that would be used in accordance 299 with an agreement between the parties. 301 3.3.2. Used as NAT64 prefix 303 Since the NAT64 pref64 is just a group of local fake addresses for 304 the DNS64 to point traffic to a NAT64, the pref64 is a very good use 305 of ULA. It ensures that only local systems can use the translation 306 resources of the NAT64 system since the ULA is not globally routable 307 and helps clearly identify traffic that is locally contained and 308 destine to a NAT64. Using ULA for Pref64 is deployed and it is an 309 operational model. 311 But there's an issue should be noticed. The NAT64 standard [RFC6146) 312 mentioned the pref64 should align with [RFC6052], in which the IPv4- 313 Embedded IPv6 Address format was specified. If we pick a /48 for 314 NAT64, it happened to be a standard 48/ part of ULA (7bit ULA famous 315 prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA is not 316 violated to be filled with part of the 32bit IPv4 address. This is 317 important, because the 40bit assures the uniqueness of ULA, if the 318 prefix is shorter than /48, the 40bit would be violated, and this may 319 cause conformance issue. But it is considered that the most common 320 use case will be a /96 PREF64, or even /64 will be used. So it seems 321 this issue is not common in current practice. 323 It is most common that ULA Pref64 will be deployed on a single internal 324 network, where the clients and the NAT64 share a common internal network. 325 ULA will not be effective as Pref64 when the access network must use an 326 Internet transit to receive the translation service of a NAT64 since the 327 ULA will not route across the internet. 329 3.3.3. Used as identifier 331 Since ULA could be self-generated and easily grabbed from the 332 standard IPv6 stack, it is very suitable to be used as identifiers by 333 the up layer applications. And since ULA is not intended to be 334 globally routed, it is not harmful to the routing system. 336 Such kind of benefit has been utilized in real implementations. For 337 example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to 338 assign a topology-independent identifier to each client host 339 according to the following considerations: 341 o TCP connections between two end hosts wish to survive in network 342 changes. 344 o Sometimes one needs a constant identifier to be associated with a 345 key so that the Security Association can survive the location 346 changes. 348 It should be noticed again that in theory ULA has the possibility of 349 collision. However, the probability is desirable small enough and 350 could be ignored by most of the cases when used as identifiers. 352 4. Security Considerations 354 Security considerations regarding ULAs, in general, please refer to 355 the ULA specification [RFC4193]. 357 5. IANA Considerations 359 None. 361 6. Conclusions 363 ULA is a useful tool, it have been successfully deployed in a diverse 364 set of circumstances including large private machine-to-machine type 365 networks, enterprise networks with private systems, and within 366 service providers to limit Internet communication with non-public 367 services such as caching DNS servers and NAT64 translation resources. 369 We should eliminate the misunderstanding that ULA is just an IPv6 370 version of [RFC1918]. The features of ULA could be beneficial for 371 various use cases. 373 7. References 375 7.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", RFC 2119, BCP14, March 1997. 380 [RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast 381 Addresses", RFC 4193, October 2005. 383 7.2. Informative References 385 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 386 E. Lear, "Address Allocation for Private Internets",BCP 5, 387 RFC 1918, February 1996. 389 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 390 E. Klein, "Local Network Protection for IPv6", RFC 4864, 391 May 2007. 393 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 394 "Problem Statement for Default Address Selection in 395 Multi-Prefix Environments: Operational Issues of RFC 3484 396 Default Rules", RFC 5220, July 2008. 398 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 399 "Understanding Apple's Back to My Mac (BTMM) Service", RFC 400 6281, June 2011. 402 [RFC6296] Wasserman, M., and F. Baker, "IPv6-to-IPv6 Network Prefix 403 Translation", RFC 6296, June 2011. 405 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and Tim Chown, 406 "Default Address Selection for Internet Protocol version 6 407 (IPv6)", RFC 6724, September, 2012. 409 [draft-baker-v6ops-b2b-private-routing] 410 F. Baker, "Business to Business Private Routing", Expired 412 8. Acknowledgments 414 Many valuable comments were received in the mail list, especially 415 from Fred Baker, Brian Carpenter, Anders Brandt and Wesley George. 417 This document was prepared using 2-Word-v2.0.template.dot. 419 Authors' Addresses 421 Bing Liu 422 Huawei Technologies Co., Ltd 423 Huawei Q14 Building, No.156 Beiqing Rd., 424 Zhong-Guan-Cun Environmental Protection Park, Beijing 425 P.R. China 427 EMail: leo.liubing@huawei.com 429 Sheng Jiang 430 Huawei Technologies Co., Ltd 431 Huawei Q14 Building, No.156 Beiqing Rd., 432 Zhong-Guan-Cun Environmental Protection Park, Beijing 433 P.R. China 435 EMail: jiangsheng@huawei.com 437 Cameron Byrne 438 T-Mobile USA 439 Bellevue, Washington 98006 440 USA 442 Email: cameron.byrne@t-mobile.com