idnits 2.17.1 draft-liu-ula-guide-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 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 18, 2013) is 4078 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 218, but not defined ** Obsolete undefined reference: RFC 6204 (Obsoleted by RFC 7084) == Missing Reference: 'RFC6052' is mentioned on line 299, but not defined == Unused Reference: 'RFC2119' is defined on line 364, 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 21, 2013 C. Byrne 5 T-Mobile USA 6 February 18, 2013 8 Guidance of Using Unique Local Addresses 9 draft-liu-ula-guide-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 21, 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 .................................. 3 55 2.2. Enumeration of ULA use scenarios ........................ 4 56 2.2.1. Isolated network ................................... 4 57 2.2.2. Connected network .................................. 4 58 2.2.2.1. ULA-only Deployment ........................... 4 59 2.2.2.2. ULA along with GUA ............................ 5 60 3. Recommended ULA Use Cases .................................... 5 61 3.1. Used in Isolated Networks ............................... 5 62 3.2. ULA along with GUA ...................................... 6 63 3.3. Special Use Cases ....................................... 6 64 3.3.1. Special routing .................................... 6 65 3.3.2. Used as NAT64 prefix ............................... 7 66 3.3.3. Used as identifier ................................. 7 67 4. Security Considerations ...................................... 8 68 5. IANA Considerations .......................................... 8 69 6. Conclusions .................................................. 8 70 7. References ................................................... 8 71 7.1. Normative References .................................... 8 72 7.2. Informative References .................................. 8 73 8. Acknowledgments .............................................. 9 75 1. Introduction 77 Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193] as 78 provider-independent prefixes that can be used on isolated networks, 79 internal networks, and VPNs. Although ULAs may be treated like global 80 scope by applications, normally they are not used on the publicly 81 routable internet. 83 However, the ULAs haven't been widely used since IPv6 hasn't been 84 widely deployed yet. 86 The use of ULA addresses in various types of networks has been confused 87 for network operators. Some network operators believe ULAs are not 88 useful at all while other network operators run their entire networks on 89 ULA address space. This document attempts to clarify the advantages and 90 disadvantages of ULAs and how they can be most appropriately used. 92 2. ULA usage analysis 94 2.1. The features of ULA 96 2.1.1. Self-assigned 98 ULA is self-assigned, this feature allows automatic address 99 allocation, which is beneficial for some lightweight systems and can 100 leverage minimal human management. 102 2.1.2. Globally unique 104 ULA is intended to be globally unique to avoid collision. Since the 105 hosts assigned with ULA may occasionally be merged into one network, 106 this uniqueness is necessary. The prefix uniqueness is based on 107 randomization of 40 bits and is considered random enough to ensure a 108 high degree of uniqueness and make merging of networks simple and 109 without the need to renumbering overlapping IP address space. 110 Overlapping is cited as a deficiency with how [RFC1918] addresses were 111 deployed, and ULA was designed to overcome this deficiency. 113 Notice that, as described in [RFC4864], in practice, applications may 114 treat ULAs like global-scope addresses, but address selection 115 algorithms may need to distinguish between ULAs and ordinary GUA 116 (Global-scope Unicast Address) to ensure bidirectional communications. 118 2.1.3. Independent address space 120 ULA provides an internal address independence capability in IPv6 that 121 is similar to how [RFC1918] is commonly used. ULA allows 122 administrators to configure the internal network of each platform the 123 same way it is configured in IPv4. Many organizations have security 124 policies and architectures based around the local-only routing of 125 RFC1918 addresses and those policies may directly map to ULA. ULA can 126 be used for internal communications without having any permanent or 127 only intermittent Internet connectivity. And it needs no registration 128 so that it can support on-demand usage and does not carry any RIR 129 documentation burden or disclosures. 131 2.1.4. Well known prefix 133 The prefixes of ULAs are well known and they are easy to be 134 identified and easy to be filtered. 136 This feature may be convenient to management of security policies and 137 troubleshooting. For example, the administrators can decide what 138 parameters have to be assembled or transmitted globally, by a 139 separate function, through an appropriate gateway/firewall, to the 140 Internet or to the telecom network. 142 2.2. Enumeration of ULA use scenarios 144 In this section, we try to cover plausible possible ULA use case. 145 Some of them might have been discussed in other documents and are 146 briefly reviewed in this document as well as other potential valid 147 usage is discussed. 149 2.2.1. Isolated network 151 IP is used ubiquitously. Some networks like RS-485, or other type of 152 industrial control bus, or even non-networked digital interface like 153 MIL-STD-1397 began to use IP protocol. In such kind of networks, the 154 system might lack the ability/requirement of connecting to the 155 Internet. 157 Besides, some networks are explicitly designed to not connect to the 158 internet. These networks may include machine-to-machine, sensor networks, 159 or other types of SCADA networks which may include very large numbers of 160 addresses and explicitly prohibited from connect to the global internet 161 (electricity meters...). 163 ULA is a straightforward way to assign the IP addresses in these 164 kinds of networks with minimal administrative cost or burden. 166 2.2.2. Connected network 168 2.2.2.1. ULA-only Deployment 170 In some situations, hosts/interfaces are assigned with ULA-only, but 171 the networks need to communicate with the outside. For example, just 172 like many implementations of private IPv4 address space [RFC1918]. One 173 important reason of using private address space is the lack of IPv4 174 addresses, but this it is not an issue any more in IPv6. Another reason 175 is regarding with security, private address space is designed by some 176 administrators as one layer of a multilayer security. Such design is 177 also applicable in IPv6 with using ULAs. 179 But we should eliminate the misunderstanding that ULA is designed to 180 be the IPv6 version of [RFC1918] deployment model. If you chose non- 181 globally routable address space for some reasons, ULA is a nature 182 selection, but we need to know ULA itself is not designed for this 183 intention. 185 ULA-only in connected network may include the following two models. 187 o Using NAT 189 With some a kind of NAT which provides a simple one to one mapping 190 for a subset of the internal addresses could fit the requirement. 192 In some very constrained situations(for example, in the sensors), the 193 network needs ULA as the on-demand and stable addressing which 194 doesn't need much code to support address assignment mechanisms like 195 DHCP or ND. And the network also needs to connect to the outside, 196 then there can be a gateway to be the NAT which may not be so 197 sensitive to the constrained resource. This behavior could refer 198 NPTv6 [RFC6296]. 200 o Using application-layer proxies 202 The proxies terminate the network-layer connectivity of the hosts and 203 delegate the outgoing/incoming connections. 205 There may be some scenarios that need this kind of deployment for 206 some special purpose (strict application access control, content 207 monitoring, e.g.). 209 2.2.2.2. ULA along with GUA 211 There are two classes of network probably to use ULA with GUA 212 addresses: 214 o Home network. Home networks are normally assigned with PA 215 addresses to connect to the uplink of some an ISP. And besides, 216 they may need internal routed networking even when the ISP link is 217 down. Then ULA is a proper tool to fit the requirement. And in 218 [RFC6204], it requires the CPE to support ULA. 220 o Enterprise network. An enterprise network is usually a managed 221 network with a fixed PA space. The ULA could be used for internal 222 connectivity redundancy and better internal connectivity or 223 isolation of certain functions like OAM of servers. 225 3. Recommended ULA Use Cases 227 3.1. Used in Isolated Networks 229 As analyzed in section 2.2.1, ULA is very suitable for isolated 230 networks. Especially when you have subnets in the isolated networks, 231 ULA is almost the only choice. 233 (Some specific description to be filled.) 235 3.2. ULA along with GUA 237 For either home networks or enterprise networks, the main purpose of 238 using ULA along with GUA is to provide a logically local routing 239 plane separated from the globally routing plane. The benefit is to 240 ensure stable and specific local communication regardless of the ISP 241 uplink failure. This benefit is especially meaningful for the home 242 network or private OAM function in an enterprise. 244 In some special cases such as renumbering, enterprise administrators 245 may want to avoid the need to renumber their internal-only, private 246 nodes when they have to renumber the PA addresses of the whole 247 network because of changing ISPs, ISPs restructure their address 248 allocations, or whatever reasons. In these situations, ULA is an 249 effective tool for the internal-only nodes. 251 Besides the internal-only nodes, the public nodes can also benefit 252 from ULA for renumbering. When renumbering, as RFC4192 suggested, it 253 has a period to keep using the old prefix(es) before the new 254 prefix(es) is(are) stable. In the process of adding new prefix(es) 255 and deprecating old prefix(es), it is not easy to keep the local 256 communication immune of global routing plane change. If we use ULA 257 for the local communication, the separated local routing plane can 258 isolate the affecting by global routing change. 260 But for the separated local routing plane, there always be some 261 argument that in practice the ULA+PA makes terrible operational 262 complexity. But it is not a ULA-specific problem; the multiple- 263 addresses-per-interface is an important feature of IPv6 protocol. 264 Running multiple prefixes in IPv6 might be very common, and we need 265 to adapt this new operational model than that in IPv4. 267 Another issue is mentioned in [RFC5220], there is a possibility that 268 the longest matching rule will not be able to choose the correct 269 address between ULAs and global unicast addresses for correct intra- 270 site and extra-site communication. In [draft-ietf-6man-rfc3484bis] , 271 it claimed that a site-specific policy entry can be used to cause 272 ULAs within a site to be preferred over global addresses. 274 3.3. Special Use Cases 276 3.3.1. Special routing 278 If you have a special routing scenario, of which 279 [draft-baker-v6ops-b2b-private-routing] is an example, for various 280 reasons you might want to have routing that you control and is 281 separate from other routing. In the b2b case, even though two 282 companies each have at least one ISP, they might choose to also use 283 direct connectivity that only connects stated machines, such as a 284 silicon foundry with client engineers that use it. A ULA provides a 285 simple way to obtain such a prefix that would be used in accordance 286 with an agreement between the parties. 288 3.3.2. Used as NAT64 prefix 290 Since the NAT64 pref64 is just a group of local fake addresses for 291 the DNS64 to point traffic to a NAT64, the pref64 is a very good use 292 of ULA. It ensures that only local systems can use the translation 293 resources of the NAT64 system since the ULA is not globally routable 294 and helps clearly identify traffic that is locally contained and 295 destine to a NAT64. Using ULA for Pref64 is deployed and it is an 296 operational model. 298 But there's an issue should be noticed. The NAT64 standard [RFC6146) 299 mentioned the pref64 should align with [RFC6052], in which the IPv4- 300 Embedded IPv6 Address format was specified. If we pick a /48 for 301 NAT64, it happened to be a standard 48/ part of ULA (7bit ULA famous 302 prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA is not 303 violated to be filled with part of the 32bit IPv4 address. This is 304 important, because the 40bit assures the uniqueness of ULA, if the 305 prefix is shorter than /48, the 40bit would be violated, and this may 306 cause conformance issue. But it is considered that the most common 307 use case will be a /96 PREF64, or even /64 will be used. So it seems 308 this issue is not common in current practice. 310 It is most common that ULA Pref64 will be deployed on a single internal 311 network, where the clients and the NAT64 share a common internal network. 312 ULA will not be effective as Pref64 when the access network must use an 313 Internet transit to receive the translation service of a NAT64 since the 314 ULA will not route across the internet. 316 3.3.3. Used as identifier 318 Since ULA could be self-generated and easily grabbed from the 319 standard IPv6 stack, it is very suitable to be used as identifiers by 320 the up layer applications. And since ULA is not intended to be 321 globally routed, it is not harmful to the routing system. 323 Such kind of benefit has been utilized in real implementations. For 324 example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to 325 assign a topology-independent identifier to each client host 326 according to the following considerations: 328 o TCP connections between two end hosts wish to survive in network 329 changes. 331 o Sometimes one needs a constant identifier to be associated with a 332 key so that the Security Association can survive the location 333 changes. 335 It should be noticed again that in theory ULA has the possibility of 336 collision. However, the probability is desirable small enough and 337 could be ignored by most of the cases when used as identifiers. 339 4. Security Considerations 341 Security considerations regarding ULAs, in general, please refer to 342 the ULA specification [RFC4193]. 344 5. IANA Considerations 346 None. 348 6. Conclusions 350 ULA is a useful tool, it have been successfully deployed in a diverse 351 set of circumstances including large private machine-to-machine type 352 networks, enterprise networks with private systems, and within 353 service providers to limit Internet communication with non-public 354 services such as caching DNS servers and NAT64 translation resources. 356 We should eliminate the misunderstanding that ULA is just an IPv6 357 version of [RFC1918]. The features of ULA could be beneficial for 358 various use cases. 360 7. References 362 7.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", RFC 2119, BCP14, March 1997. 367 [RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast 368 Addresses", RFC 4193, October 2005. 370 7.2. Informative References 372 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 373 E. Lear, "Address Allocation for Private Internets",BCP 5, 374 RFC 1918, February 1996. 376 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 377 E. Klein, "Local Network Protection for IPv6", RFC 4864, 378 May 2007. 380 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 381 "Problem Statement for Default Address Selection in 382 Multi-Prefix Environments: Operational Issues of RFC 3484 383 Default Rules", RFC 5220, July 2008. 385 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 386 "Understanding Apple's Back to My Mac (BTMM) Service", RFC 387 6281, June 2011. 389 [RFC6296] Wasserman, M., and F. Baker, "IPv6-to-IPv6 Network Prefix 390 Translation", RFC 6296, June 2011. 392 [draft-ietf-6man-rfc3484bis] 393 Thaler, D., Draves, R., Matsumoto, A., and Tim Chown, 394 "Default Address Selection for Internet Protocol version 6 395 (IPv6)", Working in progress. 397 [draft-baker-v6ops-b2b-private-routing] 398 F. Baker, "Business to Business Private Routing", Expired 400 8. Acknowledgments 402 Many valuable comments were received in the mail list, especially 403 from Fred Baker, Brian Carpenter, Anders Brandt and Wesley George. 405 This document was prepared using 2-Word-v2.0.template.dot. 407 Authors' Addresses 409 Bing Liu 410 Huawei Technologies Co., Ltd 411 Huawei Q14 Building, No.156 Beiqing Rd., 412 Zhong-Guan-Cun Environmental Protection Park, Beijing 413 P.R. China 415 EMail: leo.liubing@huawei.com 417 Sheng Jiang 418 Huawei Technologies Co., Ltd 419 Huawei Q14 Building, No.156 Beiqing Rd., 420 Zhong-Guan-Cun Environmental Protection Park, Beijing 421 P.R. China 423 EMail: jiangsheng@huawei.com 425 Cameron Byrne 426 T-Mobile USA 427 Bellevue, Washington 98006 428 USA 430 Email: cameron.byrne@t-mobile.com