idnits 2.17.1 draft-ietf-ipngwg-unicast-aggr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Abstract section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 49, but not defined == Missing Reference: 'EUI-64' is mentioned on line 299, but not defined == Unused Reference: 'ALLOC' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'AUTO' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'EUI64' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 434, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. 'ALLOC') -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' ** Obsolete normative reference: RFC 1826 (ref. 'AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1971 (ref. 'AUTO') (Obsoleted by RFC 2462) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETHER' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'FDDI' ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1466 (ref. 'RFC2050') (Obsoleted by RFC 2050) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 March 13, 1998 M. O'Dell, UUNET 3 S. Deering, Cisco 5 An IPv6 Aggregatable Global Unicast Address Format 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the internet- 23 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 This internet draft expires on September 13, 1998. 29 1.0 Introduction 31 This document defines an IPv6 aggregatable global unicast address 32 format for use in the Internet. The address format defined in this 33 document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6 34 Addressing Architecture'' [ARCH]. It is designed to facilitate 35 scalable Internet routing. 37 This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast 38 Address Format''. RFC 2073 will become historic. The Aggregatable 39 Global Unicast Address Format is an improvement over RFC 2073 in a 40 number of areas. The major changes include removal of the registry 41 bits because they are not needed for route aggregation, support of 42 EUI-64 based interface identifiers, support of provider and exchange 43 based aggregation, separation of public and site topology, and new 44 aggregation based terminology. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [RFC 2119]. 50 2.0 Overview of the IPv6 Address 52 IPv6 addresses are 128-bit identifiers for interfaces and sets of 53 interfaces. There are three types of addresses: Unicast, Anycast, 54 and Multicast. This document defines a specific type of Unicast 55 address. 57 In this document, fields in addresses are given specific names, for 58 example "subnet". When this name is used with the term "ID" (for 59 "identifier") after the name (e.g., "subnet ID"), it refers to the 60 contents of the named field. When it is used with the term "prefix" 61 (e.g. "subnet prefix") it refers to all of the addressing bits to 62 the left of and including this field. 64 IPv6 unicast addresses are designed assuming that the Internet 65 routing system makes forwarding decisions based on a "longest prefix 66 match" algorithm on arbitrary bit boundaries and does not have any 67 knowledge of the internal structure of IPv6 addresses. The structure 68 in IPv6 addresses is for assignment and allocation. The only 69 exception to this is the distinction made between unicast and 70 multicast addresses. 72 The specific type of an IPv6 address is indicated by the leading bits 73 in the address. The variable-length field comprising these leading 74 bits is called the Format Prefix (FP). 76 This document defines an address format for the 001 (binary) Format 77 Prefix for Aggregatable Global Unicast addresses. The same address 78 format could be used for other Format Prefixes, as long as these 79 Format Prefixes also identify IPv6 unicast addresses. Only the "001" 80 Format Prefix is defined here. 82 3.0 IPv6 Aggregatable Global Unicast Address Format 84 This document defines an address format for the IPv6 aggregatable 85 global unicast address assignment. The authors believe that this 86 address format will be widely used for IPv6 nodes connected to the 87 Internet. This address format is designed to support both the 88 current provider-based aggregation and a new type of exchange-based 89 aggregation. The combination will allow efficient routing 90 aggregation for sites that connect directly to providers and for 91 sites that connect to exchanges. Sites will have the choice to 92 connect to either type of aggregation entity. 94 While this address format is designed to support exchange-based 95 aggregation (in addition to current provider-based aggregation) it is 96 not dependent on exchanges for it's overall route aggregation 97 properties. It will provide efficient route aggregation with only 98 provider-based aggregation. 100 Aggregatable addresses are organized into a three level hierarchy: 102 - Public Topology 103 - Site Topology 104 - Interface Identifier 106 Public topology is the collection of providers and exchanges who 107 provide public Internet transit services. Site topology is local to 108 a specific site or organization which does not provide public transit 109 service to nodes outside of the site. Interface identifiers identify 110 interfaces on links. 112 ______________ ______________ 113 --+/ \+--------------+/ \+---------- 114 ( P1 ) +----+ ( P3 ) +----+ 115 +\______________/ | |----+\______________/+--| |-- 116 | +--| X1 | +| X2 | 117 | ______________ / | |-+ ______________ / | |-- 118 +/ \+ +-+--+ \ / \+ +----+ 119 ( P2 ) / \ +( P4 ) 120 --+\______________/ / \ \______________/ 121 | / \ | | 122 | / | | | 123 | / | | | 124 _|_ _/_ _|_ _|_ _|_ 125 / \ / \ / \ / \ / \ 126 ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C ) 127 \___/ \___/ \___/ \___/ \___/ 128 | / \ 129 _|_ _/_ \ ___ 130 / \ / \ +-/ \ 131 ( S.D ) ( S.E ) ( S.F ) 132 \___/ \___/ \___/ 134 As shown in the figure above, the aggregatable address format is 135 designed to support long-haul providers (shown as P1, P2, P3, and 136 P4), exchanges (shown as X1 and X2), multiple levels of providers 137 (shown at P5 and P6), and subscribers (shown as S.x) Exchanges 138 (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses. 139 Organizations who connect to these exchanges will also subscribe 140 (directly, indirectly via the exchange, etc.) for long-haul service 141 from one or more long-haul providers. Doing so, they will achieve 142 addressing independence from long-haul transit providers. They will 143 be able to change long-haul providers without having to renumber 144 their organization. They can also be multihomed via the exchange to 145 more than one long-haul provider without having to have address 146 prefixes from each long-haul provider. Note that the mechanisms used 147 for this type of provider selection and portability are not discussed 148 in the document. 150 3.1 Aggregatable Global Unicast Address Structure 152 The aggregatable global unicast address format is as follows: 154 | 3| 13 | 8 | 24 | 16 | 64 bits | 155 +--+-----+---+--------+--------+--------------------------------+ 156 |FP| TLA |RES| NLA | SLA | Interface ID | 157 | | ID | | ID | ID | | 158 +--+-----+---+--------+--------+--------------------------------+ 160 <--Public Topology---> Site 161 <--------> 162 Topology 163 <------Interface Identifier-----> 165 Where 167 FP Format Prefix (001) 168 TLA ID Top-Level Aggregation Identifier 169 RES Reserved for future use 170 NLA ID Next-Level Aggregation Identifier 171 SLA ID Site-Level Aggregation Identifier 172 INTERFACE ID Interface Identifier 174 The following sections specify each part of the IPv6 Aggregatable 175 Global Unicast address format. 177 3.2 Top-Level Aggregation ID 179 Top-Level Aggregation Identifiers (TLA ID) are the top level in the 180 routing hierarchy. Default-free routers must have a routing table 181 entry for every active TLA ID and will probably have additional 182 entries providing routing information for the TLA ID in which they 183 are located. They may have additional entries in order to optimize 184 routing for their specific topology, but the routing topology at all 185 levels must be designed to minimize the number of additional entries 186 fed into the default free routing tables. 188 This addressing format supports 8,192 (2^13) TLA ID's. Additional 189 TLA ID's may be added by either growing the TLA field to the right 190 into the reserved field or by using this format for additional format 191 prefixes. 193 The issues relating to TLA ID assignment are beyond the scope of this 194 document. They will be described in a document under preparation. 196 3.3 Reserved 198 The Reserved field is reserved for future use and must be set to 199 zero. 201 The Reserved field allows for future growth of the TLA and NLA fields 202 as appropriate. See section 4.0 for a discussion. 204 3.4 Next-Level Aggregation Identifier 206 Next-Level Aggregation Identifier's are used by organizations 207 assigned a TLA ID to create an addressing hierarchy and to identify 208 sites. The organization can assign the top part of the NLA ID in a 209 manner to create an addressing hierarchy appropriate to its network. 210 It can use the remainder of the bits in the field to identify sites 211 it wishes to serve. This is shown as follows: 213 | n | 24-n bits | 16 | 64 bits | 214 +-----+--------------------+--------+-----------------+ 215 |NLA1 | Site ID | SLA ID | Interface ID | 216 +-----+--------------------+--------+-----------------+ 218 Each organization assigned a TLA ID receives 24 bits of NLA ID space. 219 This NLA ID space allows each organization to provide service to 220 approximately as many organizations as the current IPv4 Internet can 221 support total networks. 223 Organizations assigned TLA ID's may also support NLA ID's in their 224 own Site ID space. This allows the organization assigned a TLA ID to 225 provide service to organizations providing public transit service and 226 to organizations who do not provide public transit service. These 227 organizations receiving an NLA ID may also choose to use their Site 228 ID space to support other NLA ID's. This is shown as follows: 230 | n | 24-n bits | 16 | 64 bits | 231 +-----+--------------------+--------+-----------------+ 232 |NLA1 | Site ID | SLA ID | Interface ID | 233 +-----+--------------------+--------+-----------------+ 235 | m | 24-n-m | 16 | 64 bits | 236 +-----+--------------+--------+-----------------+ 237 |NLA2 | Site ID | SLA ID | Interface ID | 238 +-----+--------------+--------+-----------------+ 240 | o |24-n-m-o| 16 | 64 bits | 241 +-----+--------+--------+-----------------+ 242 |NLA3 | Site ID| SLA ID | Interface ID | 243 +-----+--------+--------+-----------------+ 245 The design of the bit layout of the NLA ID space for a specific TLA 246 ID is left to the organization responsible for that TLA ID. Likewise 247 the design of the bit layout of the next level NLA ID is the 248 responsibility of the previous level NLA ID. It is recommended that 249 organizations assigning NLA address space use "slow start" allocation 250 procedures similar to [RFC2050]. 252 The design of an NLA ID allocation plan is a tradeoff between routing 253 aggregation efficiency and flexibility. Creating hierarchies allows 254 for greater amount of aggregation and results in smaller routing 255 tables. Flat NLA ID assignment provides for easier allocation and 256 attachment flexibility, but results in larger routing tables. 258 3.5 Site-Level Aggregation Identifier 260 The SLA ID field is used by an individual organization to create its 261 own local addressing hierarchy and to identify subnets. This is 262 analogous to subnets in IPv4 except that each organization has a much 263 greater number of subnets. The 16 bit SLA ID field support 65,535 264 individual subnets. 266 Organizations may choose to either route their SLA ID "flat" (e.g., 267 not create any logical relationship between the SLA identifiers that 268 results in larger routing tables), or to create a two or more level 269 hierarchy (that results in smaller routing tables) in the SLA ID 270 field. The latter is shown as follows: 272 | n | 16-n | 64 bits | 273 +-----+------------+-------------------------------------+ 274 |SLA1 | Subnet | Interface ID | 275 +-----+------------+-------------------------------------+ 277 | m |16-n-m | 64 bits | 278 +----+-------+-------------------------------------+ 279 |SLA2|Subnet | Interface ID | 280 +----+-------+-------------------------------------+ 282 The approach chosen for structuring an SLA ID field is the 283 responsibility of the individual organization. 285 The number of subnets supported in this address format should be 286 sufficient for all but the largest of organizations. Organizations 287 which need additional subnets can arrange with the organization they 288 are obtaining Internet service from to obtain additional site 289 identifiers and use this to create additional subnets. 291 3.6 Interface ID 293 Interface identifiers are used to identify interfaces on a link. 294 They are required to be unique on that link. They may also be unique 295 over a broader scope. In many cases an interfaces identifier will be 296 the same or be based on the interface's link-layer address. 297 Interface IDs used in the aggregatable global unicast address format 298 are required to be 64 bits long and to be constructed in IEEE EUI-64 299 format [EUI-64]. These identifiers may have global scope when a 300 global token (e.g., IEEE 48bit MAC) is available or may have local 301 scope where a global token is not available (e.g., serial links, 302 tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE 303 EUI-64 terminology) in the EUI-64 identifier must be set correctly, 304 as defined in [ARCH], to indicate global or local scope. 306 The procedures for creating EUI-64 based Interface Identifiers is 307 defined in [ARCH]. The details on forming interface identifiers is 308 defined in the appropriate "IPv6 over " specification such as 309 "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 311 4.0 Technical Motivation 313 The design choices for the size of the fields in the aggregatable 314 address format were based on the need to meet a number of technical 315 requirements. These are described in the following paragraphs. 317 The size of the Top-Level Aggregation Identifier is 13 bits. This 318 allows for 8,192 TLA ID's. This size was chosen to insure that the 319 default-free routing table in top level routers in the Internet is 320 kept within the limits, with a reasonable margin, of the current 321 routing technology. The margin is important because default-free 322 routers will also carry a significant number of longer (i.e., more- 323 specific) prefixes for optimizing paths internal to a TLA and between 324 TLAs. 326 The important issue is not only the size of the default-free routing 327 table, but the complexity of the topology that determines the number 328 of copies of the default-free routes that a router must examine while 329 computing a forwarding table. Current practice with IPv4 it is 330 common to see a prefix announced fifteen times via different paths. 331 The complexity of Internet topology is very likely to increase in the 332 future. It is important that IPv6 default-free routing support 333 additional complexity as well as a considerably larger internet. 335 It should be noted for comparison that the current IPv4 default-free 336 routing table is approximately 47,000 prefixes. While this shows 337 that it is possible to support more routes than 8,192 it is matter of 338 debate if the number of prefixes supported today in IPv4 is already 339 too high for current routing technology. There are serious issues of 340 route stability as well as cases of providers not supporting all top 341 level prefixes. The technical requirement was to pick a TLA ID size 342 that was below, with a reasonable margin, what was being done with 343 IPv4. 345 The choice of 13 bits for the TLA field was an engineering 346 compromise. Fewer bits would have been too small by not supporting 347 enough top level organizations. More bits would have exceeded what 348 can be reasonably accommodated, with a reasonable margin, with 349 current routing technology in order to deal with the issues described 350 in the previous paragraphs. 352 If in the future, routing technology improves to support a larger 353 number of top level routes in the default-free routing tables there 354 are two choices on how to increase the number TLA identifiers. The 355 first is to expand the TLA ID field into the reserved field. This 356 would increase the number of TLA ID's to approximately 2 million. 357 The second approach is to allocate another format prefix (FP) for use 358 with this address format. Either or a combination of these 359 approaches allows the number of TLA ID's to increase significantly. 361 The size of the Reserved field is 8 bits. This size was chosen to 362 allow significant growth of either the TLA ID and/or the NLA ID 363 fields. 365 The size of the Next-Level Aggregation Identifier field is 24 bits. 367 This allows for approximately sixteen million NLA ID's if used in a 368 flat manner. Used hierarchically it allows for a complexity roughly 369 equivalent to the IPv4 address space (assuming an average network 370 size of 254 interfaces). If in the future additional room for 371 complexity is needed in the NLA ID, this may be accommodated by 372 extending the NLA ID into the Reserved field. 374 The size of the Site-Level Aggregation Identifier field is 16 bits. 375 This supports 65,535 individual subnets per site. The design goal 376 for the size of this field was to be sufficient for all but the 377 largest of organizations. Organizations which need additional 378 subnets can arrange with the organization they are obtaining Internet 379 service from to obtain additional site identifiers and use this to 380 create additional subnets. 382 The Site-Level Aggregation Identifier field was given a fixed size in 383 order to force the length of all prefixes identifying a particular 384 site to be the same length (i.e., 48 bits). This facilitates 385 movement of sites in the topology (e.g., changing service providers 386 and multi-homing to multiple service providers). 388 The Interface ID Interface Identifier field is 64 bits. This size 389 was chosen to meet the requirement specified in [ARCH] to support 390 EUI-64 based Interface Identifiers. 392 5.0 Acknowledgments 394 The authors would like to express our thanks to Thomas Narten, Bob 395 Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, 396 Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg 397 for their review and constructive comments. 399 6.0 References 401 [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", 402 RFC1881, December 1995. 404 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 405 Internet Draft, , 406 July 1997. 408 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 409 1995. 411 [AUTO] Thompson, S., T. Narten., "IPv6 Stateless Address 412 Autoconfiguration", RFC1971, August 1996. 414 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 415 Networks", Internet Draft, , March 1997. 418 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 419 Registration Authority", 420 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 421 March 1997. 423 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 424 Networks", Internet Draft, , March 1997. 427 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 428 (IPv6) Specification", RFC1883, December 1995. 430 [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. 431 Postel, "Internet Registry IP Allocation Guidelines", 432 RFC1466, BCP12, November 1996. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", RFC2119, BCP14, March 1997. 437 7.0 Security Considerations 439 IPv6 addressing documents do not have any direct impact on Internet 440 infrastructure security. Authentication of IPv6 packets is defined 441 in [AUTH]. 443 8.0 Authors' Addresses 445 Robert M. Hinden phone: 1 408 990-2004 446 Nokia . email: hinden@iprg.nokia.com 447 232 Java Drive 448 Sunnyvale, CA 94089 449 USA 451 Mike O'Dell phone: 1 703 206-5890 452 UUNET Technologies, Inc. email: mo@uunet.uu.net 453 3060 Williams Drive 454 Fairfax, VA 22030 455 USA 457 Stephen E. Deering phone: 1 408 527-8213 458 Cisco Systems, Inc. email: deering@cisco.com 459 170 West Tasman Drive 460 San Jose, CA 95134-1706 461 USA