idnits 2.17.1 draft-ietf-ipngwg-unicast-aggr-01.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-03-28) 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 44, but not defined == Missing Reference: 'EUI-64' is mentioned on line 324, but not defined == Unused Reference: 'AUTO' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'EUI64' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 377, 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 1971 (ref. 'AUTO') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 1338 (ref. 'CIDR') (Obsoleted by RFC 1519) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETHER' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'EXCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'FDDI' ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Ipsilon Networks 3 June 12, 1997 M. O'Dell, UUNET 4 S. Deering, Cisco 6 An IPv6 Aggregatable Global Unicast Address Format 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 Please check the 1id-abstracts.txt listing contained in the internet- 24 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 25 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 26 current status of any Internet Draft. 28 This internet draft expires on December 13, 1997. 30 1.0 Introduction 32 This document defines an IPv6 aggregatable global unicast address 33 format for use in the Internet. The address format defined in this 34 document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 35 Addressing Architecture" [ARCH]. It is designed to facilitate 36 scalable Internet routing. 38 This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast 39 Address Format". RFC 2073 will become historic. 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [RFC 2119]. 45 2.0 Overview of the IPv6 Address 47 IPv6 addresses are 128-bit identifiers for interfaces and sets of 48 interfaces. There are three types of addresses: Unicast, Anycast, 49 and Multicast. This document defines a specific type of Unicast 50 address. 52 In this document, fields in addresses are given specific names, for 53 example "subnet". When this name is used with the term "ID" (for 54 "identifier") after the name (e.g., "subnet ID"), it refers to the 55 contents of the named field. When it is used with the term "prefix" 56 (e.g. "subnet prefix") it refers to all of the addressing bits to 57 the left of and including this field. 59 IPv6 unicast addresses are designed assuming that the internet 60 routing system makes forwarding decisions based on a "longest prefix 61 match" algorithm on arbitrary bit boundaries and does not have any 62 knowledge of the internal structure of IPv6 addresses. The structure 63 in IPv6 addresses is for assignment and allocation. The only 64 exception to this is the distinction made between unicast and 65 multicast addresses. 67 The specific type of an IPv6 address is indicated by the leading bits 68 in the address. The variable-length field comprising these leading 69 bits is called the Format Prefix (FP). 71 This document defines an address format for the 001 (binary) Format 72 Prefix for Aggregatable Global Unicast addresses. The same address 73 format could be used for other Format Prefixes, as long as these 74 Format Prefixes also identify IPv6 unicast addresses. Only the "001" 75 Format Prefix is defined here. 77 3.0 IPv6 Aggregatable Global Unicast Address Format 79 This document defines an address format for the IPv6 aggregatable 80 global unicast address assignment. The authors believe that this 81 address format will be widely used for IPv6 nodes connected to the 82 Internet. This address format is designed to support both the 83 current provider-based aggregation and a new type of exchange-based 84 aggregation. The combination will allow efficient routing 85 aggregation for both sites that connect directly to providers and 86 sites that connect to exchanges. Sites will have the choice to 87 connect to either type of aggregation entity. 89 Aggregatable addresses are organized into a three level hierarchy: 91 - Public Topology 92 - Site Topology 93 - Interface Identifier 95 Public topology is the collection of providers and exchanges who 96 provide public Internet transit services. Site topology is local to 97 a specific site or organization which does not provide public transit 98 service to nodes outside of the site. Interface identifiers identify 99 interfaces on links. 101 ______________ ______________ 102 --+/ \+--------------+/ \+---------- 103 ( P1 ) +----+ ( P3 ) +----+ 104 +\______________/ | |----+\______________/+--| |-- 105 | +--| X1 | +| X2 | 106 | ______________ / | |-+ ______________ / | |-- 107 +/ \+ +-+--+ \ / \+ +----+ 108 ( P2 ) / \ +( P4 ) 109 --+\______________/ / \ \______________/ 110 | / \ | | 111 | / | | | 112 | / | | | 113 _|_ _/_ _|_ _|_ _|_ 114 / \ / \ / \ / \ / \ 115 ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.D ) 116 \___/ \___/ \___/ \___/ \___/ 117 | / \ 118 _|_ _/_ \ ___ 119 / \ / \ +-/ \ 120 ( S.E ) ( S.F ) ( S.G ) 121 \___/ \___/ \___/ 123 As shown in the figure above, the aggregatable address format is 124 designed to support long-haul providers (shown as P1, P2, P3, and 125 P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of 126 providers (shown at P5 and P6), and subscribers (shown as S.x) 127 Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 128 addresses. Organizations who connect to these exchanges will also 129 subscribe (directly, indirectly via the exchange, etc.) for long- 130 haul service from one or more long-haul providers. Doing so, they 131 will achieve addressing independence from long-haul transit 132 providers. They will be able to change long-haul providers without 133 having to renumber their organization. They can also be multihomed 134 via the exchange to more than one long-haul provider without having 135 to have address prefixes from each long-haul provider. Note that the 136 mechanisms used for this type of provider selection and portability 137 are not discussed in the document. 139 3.1 Aggregatable Global Unicast Address Structure 141 The aggregatable global unicast address format is as follows: 143 | 3 | 13 | 32 | 16 | 64 bits | 144 +---+-----+-----------+--------+--------------------------------+ 145 |FP | TLA | NLA* | SLA* | Interface ID | 146 +---+-----+-----------+--------+--------------------------------+ 148 <--Public Topology---> Site 149 <--------> 150 Topology 151 <------Interface Identifier-----> 153 Where 155 FP Format Prefix (001) 156 TLA Top-Level Aggregator 157 NLA* Next-Level Aggregator(s) 158 SLA* Site-Level Aggregator(s) 159 INTERFACE ID Interface Identifier 161 The following sections specify each part of the IPv6 Aggregatable 162 Global Unicast address format. 164 3.2 Top-Level Aggregator 166 Top-Level Aggregators (TLA) are the top level in the routing 167 hierarchy. Default-free routers must have a routing table entry for 168 every active TLA. They may have additional entries, but the routing 169 topology at all levels must be designed to minimize the number of 170 additional entries fed into the default free routing tables. 172 This addressing format supports 8,192 (2^^13) TLA's. Additional TLA 173 may be added by using this format for additional format prefixes. 174 The addition of another FP will add another 8,192 TLA's. 176 3.2.1 Assignment of TLAs 178 TLAs are assigned to organizations providing public transit topology. 179 They are specifically not assigned to organizations only providing 180 leaf or private transit topology. TLA assignment does not imply 181 ownership. It does imply stewardship over valuable Internet 182 property. 184 The IAB and IESG have authorized the Internet Assigned Numbers 185 Authority (IANA) as the appropriate entity to have the responsibility 186 for the management of the IPv6 address space as defined in [ALLOC]. 188 The IANA will assign small blocks of TLAs to IPv6 registries. The 189 registries will assign the TLAs to organizations meeting the 190 requirements for TLAs. When the registries have assigned all of 191 their TLAs they can request that the IANA give them another block. 192 The blocks do not have to be contiguous. The IANA may also assign 193 TLAs to organizations directly. 195 Organizations assigned TLAs are required to meet the following 196 requirements: 198 - Must have a plan to offer public native IPv6 service within 6 199 months from assignment. Plan must include plan for NLA 200 allocation. 202 - Plan or track record providing public internet transit service on 203 fair, reasonable, and non-discriminatory terms, to other 204 providers. TLAs must not be assigned to organizations that are 205 only providing leaf service even if multihomed. 207 - Must provide registry services on fair, reasonable, and non- 208 discriminatory terms, for the NLA address space it is responsible 209 for under its TLA. This must include both sites and next level 210 providers. 212 - Must provide transit routing and forwarding to all assigned TLAs 213 on fair, reasonable, and non-discriminatory terms. Organizations 214 are not allowed to filter out any specific TLA's (except 215 temporarily for diagnostic purposes or emergency repair purposed). 217 - Periodically (interval set by registry) provide to registry 218 utilization statistics of the TLA it has custody of. The 219 organization must also show evidence of carrying TLA routing and 220 transit traffic. This can be in the form of traffic statistics, 221 traceroutes, routing table dumps, or similar means. 223 Organizations which are given custody of a TLA and fail to continue 224 to meet these may have the TLA custody revoked. 226 3.3 Next-Level Aggregator(s) 228 Next-Level Aggregator(s) are used by TLA's to create an addressing 229 hierarchy and to identify sites. The TLA can assign the top part of 230 the NLA in a manner to create an addressing hierarchy appropriate to 231 its network. It can use the remainder of the bits in the field to 232 identify sites it wishes to serve. This is shown as follows: 234 | n | 32-n bits | 16 | 64 bits | 235 +-----+--------------------+--------+-----------------+ 236 |NLA1 | Site | SLA* | Interface ID | 237 +-----+--------------------+--------+-----------------+ 239 Each TLA receives 32 bits of NLA* space. This NLA* space allows each 240 TLA to provide service to about as many organizations as the current 241 IPv4 internet can support total nodes. 243 The TLAs may also support NLAs in their own Site ID space. This 244 allows the TLAs to provide service to organizations providing public 245 transit service and organizations who do not. The organizations 246 providing public transit service become NLA's themselves. These NLAs 247 may also choose to use their Site ID space to support other NLAs. 248 This is shown as follows: 250 | n | 32-n bits | 16 | 64 bits | 251 +-----+--------------------+--------+-----------------+ 252 |NLA1 | Site | SLA* | Interface ID | 253 +-----+--------------------+--------+-----------------+ 255 | m | 32-n-m | 16 | 64 bits | 256 +-----+--------------+--------+-----------------+ 257 |NLA2 | Site | SLA* | Interface ID | 258 +-----+--------------+--------+-----------------+ 260 | o |32-n-m-o| 16 | 64 bits | 261 +-----+--------+--------+-----------------+ 262 |NLA3 | Site | SLA* | Interface ID | 263 +-----+--------+--------+-----------------+ 265 The NLA delegation works in the same manner as CIDR delegation in 266 IPv4 [CIDR]. TLAs are required to assume registry duties for the 267 NLAs. Each level of NLA is required to assume registry duties for 268 the next level NLA. 270 The design of the bit layout of the NLA space for a specific TLA is 271 left to the organization responsible for that TLA. Likewise the 272 design of the bit layout of the next level NLA is the responsibility 273 of the previous level NLA. It is recommended that organizations 274 assigning NLA address space use "slow start" allocation procedures as 275 is currently done with IPV4 CIDR blocks. 277 The design of an NLA allocation plan is a tradeoff between routing 278 aggregation efficiency and flexibility. Creating hierarchies allows 279 for greater amount of aggregation and results in smaller routing 280 tables. Flat NLA assignment provides for easier allocation and 281 attachment flexibility but results in larger routing tables. 283 3.4 Site-Level Aggregator(s) 285 The SLA* field is used by an individual organization to create its 286 own local addressing hierarchy and to identify subnets. This is 287 analogous to subnets in IPv4 except that each organization has a much 288 greater number of subnets. The 16 bit SLA* field support 65,535 289 individual subnets. 291 Organizations may choose to either route their SLA* "flat" (e.g., not 292 create any logical relationship between the SLA identifiers which 293 results in larger routing tables), or to create a two or more level 294 hierarchy (which results in smaller routing tables) in the SLA* 295 field. The latter is shown as follows: 297 | n | 16-n | 64 bits | 298 +-----+------------+-------------------------------------+ 299 |SLA1 | Subnet | Interface ID | 300 +-----+------------+-------------------------------------+ 302 | m |16-n-m | 64 bits | 303 +----+-------+-------------------------------------+ 304 |SLA2|Subnet | Interface ID | 305 +----+-------+-------------------------------------+ 307 The approach chosen for how to the structure of an SLA* field is the 308 responsibility of the individual organization. 310 The number of subnets supported should be sufficient for all but the 311 largest of organizations. Organizations which need additional 312 subnets can arrange with the organization they are obtaining internet 313 service from to obtain additional site identifiers and use this to 314 create additional subnets. 316 3.5 Interface ID 318 Interface identifiers are used to identify interfaces on a link. 319 They are required to be unique on that link. They may also be unique 320 over a broader scope. In many cases an interface's identifier will 321 be the same as that interface's link-layer address. Interface IDs 322 used in the aggregatable global unicast address format are required 323 to be 64 bits long and to be constructed in IEEE EUI-64 format 324 [EUI-64]. These identifiers may have global scope when a global 325 token (e.g., IEEE 48bit MAC) is available or may have local scope 326 where a global token is not available (e.g., serial links, tunnel 327 end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64 328 terminology) in the EUI-64 identifier must be set correctly, as 329 defined in [ARCH], to indicate global or local scope. 331 The procedures for creating EUI-64 based Interface Identifiers is 332 defined in [ARCH]. The details on forming interface identifiers is 333 defined in the appropriate "IPv6 over " specification such as 334 "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 336 4.0 Acknowledgments 338 The authors would like to express our thanks to Thomas Narten, Bob 339 Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, 340 Scott Bradner, Brian Carpenter, and John Stewart. for their review 341 and constructive comments. 343 5.0 References 345 [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", 346 RFC1881, December 1995. 348 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 349 Internet Draft, , May 350 1997. 352 [AUTO] Thompson, S., Narten T., "IPv6 Stateless Address 353 Autoconfiguration", RFC1971, August 1996. 355 [CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an 356 Address Assignment and Aggregation Strategy", RFC1338. 358 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 359 Networks", Internet Draft, , March 1997. 362 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 363 Registration Authority", 364 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 365 March 1997. 367 [EXCH] Hinden, R., Huitema, C. "Internet Exchanges", document 368 under preparation. 370 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 371 Networks", Internet Draft, , March 1997. 374 [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, 375 Version 6 (IPv6) Specification", RFC1883, December 1995. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", RFC2119, BCP14, March 1997. 380 6.0 Security Considerations 382 Documents of this type do not directly impact the security of the 383 Internet infrastructure or its applications. 385 7.0 Authors' Addresses 387 Robert M. Hinden phone: 1 408 990-2004 388 Ipsilon Networks, Inc. email: hinden@ipsilon.com 389 232 Java Drive 390 Sunnyvale, CA 94089 391 USA 393 Mike O'Dell phone: 1 703 206-5890 394 UUNET Technologies, Inc. email: mo@uunet.uu.net 395 3060 Williams Drive 396 Fairfax, VA 22030 397 USA 399 Stephen E. Deering phone: 1 408 527-8213 400 Cisco Systems, Inc. email: deering@cisco.com 401 170 West Tasman Drive 402 San Jose, CA 95134-1706 403 USA