idnits 2.17.1 draft-mrw-6man-ulac-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 6001 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft ThingMagic 4 Expires: May 22, 2008 November 19, 2007 6 An Analysis of Centrally Assigned Unique Local Addresses 7 draft-mrw-6man-ulac-analysis-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 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 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 22, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 There has been discussion within the IETF IPv6 community for some 41 time regarding whether or not to define Centrally Assigned Unique 42 Local Addresses (ULA-Cs). Although many arguments both for and 43 against the definition of ULA-Cs have been raised and repeated, our 44 discussions have not resulted in consensus about whether or not to 45 define this new address type. This document will summarize the 46 arguments for and against the allocation of ULA-Cs, in an attempt to 47 help the IETF IPv6 community reach a decision on this issue. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Benefits of ULA-Cs . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Greater Assurance of Uniqueness . . . . . . . . . . . . . . 4 54 2.2. Accountability . . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. The Costs of ULA-Cs . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Address Space Consumption . . . . . . . . . . . . . . . . . 5 58 3.2. New Registration Method . . . . . . . . . . . . . . . . . . 5 59 4. Other Concerns about ULA-Cs . . . . . . . . . . . . . . . . . . 5 60 4.1. Lack of Value . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Wrong Way to Influence Registry Policy . . . . . . . . . . 6 62 4.3. Architecturally Flawed . . . . . . . . . . . . . . . . . . 6 63 4.4. Use as Globally Routed Provider Independent Addresses . . . 7 64 4.5. Enabling IPv6 NAT . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . . . . 9 73 1. Introduction 75 Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193], 76 which defines a local assignment method to be used for half of the 77 ULA address space. RFC 4193 reserves the other half of the ULA space 78 for ULAs that are assigned using another assignment method, without 79 specifying what method would be used. 81 ULAs are largely targeted at fulfilling the need for local, Internet 82 Service Provider (ISP)-independent prefixes that can be used on 83 isolated networks, internal networks and VPNs. Enterprise 84 administrators do not want to use Provider Assigned addresses for 85 these purposes, because they want to avoid the need to renumber their 86 internal, private networks when they change ISPs, or when their ISPs 87 merge with other ISPs or restructure their address allocations. 89 Locally Assigned ULAs are generated within the local enterprise, 90 either by the network administrator or by a piece of networking 91 equipment, using a random number generator. These addresses are 92 probabilistically unique, in the sense that it is extremely unlikely 93 that there will be an overlap within any reasonably small number of 94 Centrally Assigned ULA prefixes. 96 Locally Assigned ULAs meet most of the local addressing needs that 97 have been expressed, and their probabilistic uniqueness represents a 98 significant advantage over the overlapping private address space 99 available in IPv4. However, there have been some arguments that we 100 should also define a centrally assigned set of ULAs (ULA-Cs), to meet 101 some needs that are not fully handled by the locally allocated ones. 103 The IETF IPv6 community (originally represented by the IPv6 WG, but 104 now represented by the IPv6 Maintenance (6man) WG) has not been able 105 to achieve consensus, over a period of several years, regarding 106 whether or not to define ULA-Cs to inhabit the other half of the ULA 107 address space. The document has been written in an attempt to 108 clearly document the different sides of this issue, in the hope that 109 we can achieve a consensus decision on how to proceed. 111 2. The Benefits of ULA-Cs 113 To understand the benefits of Centrally Assigned ULAs in a world that 114 already has Locally Assigned ULAs available, we need to discuss what 115 features Centrally Assigned ULAs will provide that are not already 116 covered by Locally Assigned ULAs. These benefits stem from the 117 differences between Locally Assigned and Centrally Assigned ULAs: the 118 greater certainty that ULA-Cs will be unique, the publicly 119 accountable nature of the registration, and the ability for ULA-Cs to 120 be registered in the reverse DNS. 122 2.1. Greater Assurance of Uniqueness 124 In some cases, local enterprise networks extend beyond the boundaries 125 of a single enterprise, connecting a set of trading partners, or 126 connecting a business and its customers, to a single private network. 127 Many of these inter-enterprise private networks exist today, and they 128 can be quite large in some cases. 130 In cases where ULA prefixes are used for these large, private, inter- 131 enterprise networks, it is important that the ULA prefix assigned to 132 the private network does not conflict with any of the prefixes used 133 internally by the participating enterprises, including the prefixes 134 used by those enterprises on other private inter-enterprise networks 135 with overlappign membership. To ensure that this requirement is met, 136 some network administrators would prefer to use prefixes, such as 137 ULA-Cs, that have a greater probability of uniqueness than Locally 138 Assigned ULAs. 140 2.2. Accountability 142 ULA-Cs are assigned by a central registry that keeps a record of the 143 assignment. This means that if a conflict does arise where two 144 enterprises are using the same Centrally Assigned ULA prefix, it is 145 possible for an enterprise administrator to prove that the prefix was 146 assigned to his/her company, and that his/her enterprise has the 147 right to use it. 149 The use of Centrally Assigned ULAs also has some advantages for 150 tracking the source of any local traffic that may leak into another 151 enterprise network or onto the Internet. Because the prefix has been 152 centrally assigned, it should be possible to check who owns the 153 prefix and contact the owner about the problem. 155 2.3. Reverse DNS 157 One of the major advantages of Centrally Assigned ULAs over Locally 158 Assigned ULAs is that it is possible for the Centrally Assigned ULA 159 prefixes to be populated in the global Reverse DNS. Since these 160 addresses may be routed across private networks between enterprises, 161 it isn't reasonable to assume that all of the nodes on a private 162 network will be configured to use a single DNS server that can run 163 "two-faced" DNS to reflect the internal addresses. In these cases, 164 it may be valuable to have these addresses populated in the global 165 Reverse DNS tree. This would be possible with ULA-Cs, because of 166 their centrally-assigned nature. 168 3. The Costs of ULA-Cs 170 This section attempts to summarize the costs associated with the 171 definition of ULA-Cs. Additional concerns regarding the definition 172 of ULA-Cs are covered in the following section. 174 3.1. Address Space Consumption 176 From an address space perspective, there is little or no cost to 177 defining ULA-Cs. RFC 4193 allocates the prefix FCOO::/7 to be used 178 for Unique Local Addresses. One half of that space (the prefix 179 FD00::/8) is allocated for Locally Assigned ULAs, while the other 180 half of the space (the prefix FC00::/8) is reserved for ULAs that use 181 another assignment method. The ULA-C draft proposes that remaining 182 half of that space (the FC00::/8 prefix) should be used for Centrally 183 Assigned ULAs. 185 3.2. New Registration Method 187 ULA-Cs would require an additional type of address registration, 188 which would involve some costs to the larger Internet community. 189 However, if there is any signficant demand for ULA-Cs, it is likely 190 that these costs could be recouped from the ULA-C registration fees. 192 4. Other Concerns about ULA-Cs 194 In addition to the costs associated with defining ULA-Cs, a number of 195 concerns have been raised regarding the value of ULA-C prefixes and 196 how they might be used or abused. This section attempts to summarize 197 those concerns. 199 4.1. Lack of Value 201 Although there are some benefits of ULA-Cs listed in Section 2, it 202 has been argued that the benefits of ULA-Cs are not sufficient to 203 warrant the corresponding complexity that will be added to the IPv6 204 standard or the effort of setting up a centralized registration 205 mechanism. The vast majority of the benefits that can be obtained 206 using ULA-Cs can also be obtained using Locally Assigned ULAs, which 207 are already defined and do not require any central registration 208 process. In most cases where enterprise administrators argue that 209 they need a higher likelihood of uniqueness, it is not actually the 210 case that their application will substantially benefit from the 211 different between probabilistic uniqueness and more deterministic 212 uniqueness. 214 4.2. Wrong Way to Influence Registry Policy 216 It has been argued that it is inappropriate and/or ineffective for 217 the IETF to attempt to influence address registration policies 218 through the publication of an RFC that creates a new address space 219 with defined registration policies. 221 There is no technical advantage, and there may be some architectural 222 disadvantages (see Section 4.3), to allocating a prefix for globally 223 unique addresses with specific registration policies. If the 224 Internet community believes that it is both useful and wise to freely 225 assign globally unique prefixes for local use, registry policies 226 could be updated to make such assignments from the regular IPv6 227 address space. There is no guarantee that any address prefixes that 228 are assigned by the registries will be routable on the global 229 Internet. Routing is achieved through separate agreements with ISPs. 230 So there is no reason to allocate a new block of IPv6 address space 231 to remove that non-existent guarantee. 233 Furthermore, there is no direct connection between the publication of 234 and RFC and the implementation of an address registration service. 235 So, while it might be useful for the IETF to publish an RFC 236 describing needs for a specific type of registration service, an RFC 237 describing ULA-Cs would not directly result in the availability of a 238 corresponding registration service. 240 So, publishing an RFC that assigns an address prefix for ULA-Cs is 241 not necessary for the allocation of globally unique local addresses, 242 nor will it be sufficient to ensure that the registration function 243 described in the document becomes available. 245 4.3. Architecturally Flawed 247 It has been argued that associating routing behavior with specific 248 address prefixes is architecturally unsound and has caused problems 249 in the past. For example, IETF statements that the IPv4 address 250 block 240/4 would not be globally routable lead to the implementation 251 of default routing filters that have complicated the allocation of 252 those addresses as part of the global IPv4 address space. However, 253 this argument only loosely applies to the definition of ULA-Cs. We 254 will not avoid the allocation of address prefixes with associated 255 routing behaviour by deciding not to define ULA-Cs, as the address 256 space that would be used for ULA-Cs has already been allocated in RFC 257 4193. 259 4.4. Use as Globally Routed Provider Independent Addresses 261 There is a widely-held view in the Internet operations community that 262 ULA-Cs will end-up being routed across the Internet and will, 263 effectively, result in the unlimited allocation of globally routed 264 Provider Independent (PI) addresses. Since these addresses would not 265 be allocated by ISPs in an aggregable fashion, it is expected that 266 they would result in separate per-enterprise routes in the global 267 routing table, as PI addresses from the IPv4 "swamp space" do today. 268 If ULA-Cs were widely used in this fashion, the global routing tables 269 for IPv6 could become large enough to compromise the stability of the 270 Internet. 272 4.5. Enabling IPv6 NAT 274 Some have argued that the definition of ULA-Cs will provide a 275 suitable set of addresses for use behind an IPv6-to-IPv6 NAT box, and 276 that we should not define these addresses to avoid that situation. 277 However, ULA-Cs provide no significant benefits to NAT installations 278 that cannot be achieved with Locally Assigned ULAs, so it is unlikely 279 that defining ULA-Cs will have much effect, in either direction, on 280 whether enterprises decide to use NAT for IPv6 networks. 282 5. Security Considerations 284 This document analyzes the tradeoffs involved in whether or not to 285 define a new IPv6 local address type called Centrally Allocated ULAs 286 (ULA-Cs). Security considerations regarding ULAs, in general, can be 287 found in RFC 4193 [RFC4193], and security considerations regarding 288 Centrally Assigned ULAs, in particular, can be found in the ULA-C 289 draft [I-D.ietf-ipv6-ula-central]. 291 6. Acknowledgements 293 This document was written using the xml2rfc tool described in RFC 294 2629 [RFC2629]. 296 7. References 298 7.1. Normative References 300 [I-D.ietf-ipv6-ula-central] 301 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 302 Addresses", draft-ietf-ipv6-ula-central-02 (work in 303 progress), June 2007. 305 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 306 Addresses", RFC 4193, October 2005. 308 7.2. Informative References 310 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 311 June 1999. 313 Author's Address 315 Margaret Wasserman 316 ThingMagic 317 One Broadway, 5th Floor 318 Cambridge, MA 02142 319 USA 321 Phone: +1 781 405-7464 322 Email: margaret@thingmagic.com 323 URI: http://www.thingmagic.com 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2007). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).