idnits 2.17.1 draft-ietf-ipngwg-unicast-aggr-02.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 44, but not defined == Missing Reference: 'EUI-64' is mentioned on line 286, but not defined == Unused Reference: 'ALLOC' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'AUTO' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'CIDR' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'EUI64' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 342, 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) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLAASN' Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Ipsilon Networks 3 July 16, 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 January 17, 1998. 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 sites that connect directly to providers and for 86 sites that connect to exchanges. Sites will have the choice to 87 connect to either type of aggregation entity. 89 While this address format is designed to support exchange-based 90 aggregation (in addition to current provider-based aggregation) it is 91 not dependent on exchanges for it's overall route aggregation 92 properties. It will provide efficient route aggregation with only 93 provider-based aggregation. 95 Aggregatable addresses are organized into a three level hierarchy: 97 - Public Topology 98 - Site Topology 99 - Interface Identifier 101 Public topology is the collection of providers and exchanges who 102 provide public Internet transit services. Site topology is local to 103 a specific site or organization which does not provide public transit 104 service to nodes outside of the site. Interface identifiers identify 105 interfaces on links. 107 ______________ ______________ 108 --+/ \+--------------+/ \+---------- 109 ( P1 ) +----+ ( P3 ) +----+ 110 +\______________/ | |----+\______________/+--| |-- 111 | +--| X1 | +| X2 | 112 | ______________ / | |-+ ______________ / | |-- 113 +/ \+ +-+--+ \ / \+ +----+ 114 ( P2 ) / \ +( P4 ) 115 --+\______________/ / \ \______________/ 116 | / \ | | 117 | / | | | 118 | / | | | 119 _|_ _/_ _|_ _|_ _|_ 120 / \ / \ / \ / \ / \ 121 ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C ) 122 \___/ \___/ \___/ \___/ \___/ 123 | / \ 124 _|_ _/_ \ ___ 125 / \ / \ +-/ \ 126 ( S.D ) ( S.E ) ( S.F ) 127 \___/ \___/ \___/ 129 As shown in the figure above, the aggregatable address format is 130 designed to support long-haul providers (shown as P1, P2, P3, and 131 P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of 132 providers (shown at P5 and P6), and subscribers (shown as S.x) 133 Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 134 addresses. Organizations who connect to these exchanges will also 135 subscribe (directly, indirectly via the exchange, etc.) for long-haul 136 service from one or more long-haul providers. Doing so, they will 137 achieve addressing independence from long-haul transit providers. 138 They will be able to change long-haul providers without having to 139 renumber their organization. They can also be multihomed via the 140 exchange to more than one long-haul provider without having to have 141 address prefixes from each long-haul provider. Note that the 142 mechanisms used for this type of provider selection and portability 143 are not discussed in the document. 145 3.1 Aggregatable Global Unicast Address Structure 147 The aggregatable global unicast address format is as follows: 149 | 3 | 13 | 32 | 16 | 64 bits | 150 +---+-----+-----------+--------+--------------------------------+ 151 |FP | TLA | NLA ID | SLA ID | Interface ID | 152 | | ID | | | | 153 +---+-----+-----------+--------+--------------------------------+ 155 <--Public Topology---> Site 156 <--------> 157 Topology 158 <------Interface Identifier-----> 160 Where 162 FP Format Prefix (001) 163 TLA ID Top-Level Aggregation Identifier 164 NLA ID Next-Level Aggregation Identifier 165 SLA ID Site-Level Aggregation Identifier 166 INTERFACE ID Interface Identifier 168 The following sections specify each part of the IPv6 Aggregatable 169 Global Unicast address format. 171 3.2 Top-Level Aggregation ID 173 Top-Level Aggregation Identifiers (TLA ID) are the top level in the 174 routing hierarchy. Default-free routers must have a routing table 175 entry for every active TLA ID and will probably have additional 176 entries providing routing information for the TLA ID in which they 177 are located. They may have additional entries in order to optimize 178 routing for their specific topology, but the routing topology at all 179 levels must be designed to minimize the number of additional entries 180 fed into the default free routing tables. 182 This addressing format supports 8,192 (2^13) TLA ID's. Additional 183 TLA ID's may be added by using this format for additional format 184 prefixes. The addition of another FP will add another 8,192 TLA 185 ID's. 187 The rules for TLA ID assignment are defined in [TLAASN]. 189 3.3 Next-Level Aggregation Identifier 191 Next-Level Aggregation Identifier's are used by organizations 192 assigned a TLA ID to create an addressing hierarchy and to identify 193 sites. The organization can assign the top part of the NLA ID in a 194 manner to create an addressing hierarchy appropriate to its network. 195 It can use the remainder of the bits in the field to identify sites 196 it wishes to serve. This is shown as follows: 198 | n | 32-n bits | 16 | 64 bits | 199 +-----+--------------------+--------+-----------------+ 200 |NLA1 | Site ID | SLA ID | Interface ID | 201 +-----+--------------------+--------+-----------------+ 203 Each organization assigned a TLA ID receives 32 bits of NLA ID space. 204 This NLA ID space allows each organization to provide service to 205 approximately as many organizations as the current IPv4 Internet can 206 support total nodes. 208 Organizations assigned TLA ID's may also support NLA ID's in their 209 own Site ID space. This allows the organization assigned a TLA ID to 210 provide service to organizations providing public transit service and 211 to organizations who do not provide public transit service. These 212 organizations receiving an NLA ID may also choose to use their Site 213 ID space to support other NLA ID's. This is shown as follows: 215 | n | 32-n bits | 16 | 64 bits | 216 +-----+--------------------+--------+-----------------+ 217 |NLA1 | Site ID | SLA ID | Interface ID | 218 +-----+--------------------+--------+-----------------+ 220 | m | 32-n-m | 16 | 64 bits | 221 +-----+--------------+--------+-----------------+ 222 |NLA2 | Site ID | SLA ID | Interface ID | 223 +-----+--------------+--------+-----------------+ 225 | o |32-n-m-o| 16 | 64 bits | 226 +-----+--------+--------+-----------------+ 227 |NLA3 | Site ID| SLA ID | Interface ID | 228 +-----+--------+--------+-----------------+ 230 The rules for NLA ID assignment are defined in [TLAASN]. 232 The design of the bit layout of the NLA ID space for a specific TLA 233 ID is left to the organization responsible for that TLA ID. Likewise 234 the design of the bit layout of the next level NLA ID is the 235 responsibility of the previous level NLA ID. It is recommended that 236 organizations assigning NLA address space use "slow start" allocation 237 procedures as is currently done with IPv4 CIDR blocks. 239 The design of an NLA ID allocation plan is a tradeoff between routing 240 aggregation efficiency and flexibility. Creating hierarchies allows 241 for greater amount of aggregation and results in smaller routing 242 tables. Flat NLA ID assignment provides for easier allocation and 243 attachment flexibility, but results in larger routing tables. 245 3.4 Site-Level Aggregation Identifier 247 The SLA ID field is used by an individual organization to create its 248 own local addressing hierarchy and to identify subnets. This is 249 analogous to subnets in IPv4 except that each organization has a much 250 greater number of subnets. The 16 bit SLA ID field support 65,535 251 individual subnets. 253 Organizations may choose to either route their SLA ID "flat" (e.g., 254 not create any logical relationship between the SLA identifiers that 255 results in larger routing tables), or to create a two or more level 256 hierarchy (that results in smaller routing tables) in the SLA ID 257 field. The latter is shown as follows: 259 | n | 16-n | 64 bits | 260 +-----+------------+-------------------------------------+ 261 |SLA1 | Subnet | Interface ID | 262 +-----+------------+-------------------------------------+ 264 | m |16-n-m | 64 bits | 265 +----+-------+-------------------------------------+ 266 |SLA2|Subnet | Interface ID | 267 +----+-------+-------------------------------------+ 269 The approach chosen for structuring an SLA ID field is the 270 responsibility of the individual organization. 272 The number of subnets supported in this address format should be 273 sufficient for all but the largest of organizations. Organizations 274 which need additional subnets can arrange with the organization they 275 are obtaining Internet service from to obtain additional site 276 identifiers and use this to create additional subnets. 278 3.5 Interface ID 280 Interface identifiers are used to identify interfaces on a link. 281 They are required to be unique on that link. They may also be unique 282 over a broader scope. In many cases an interface's identifier will 283 be the same or be based on the interface's link-layer address. 284 Interface IDs used in the aggregatable global unicast address format 285 are required to be 64 bits long and to be constructed in IEEE EUI-64 286 format [EUI-64]. These identifiers may have global scope when a 287 global token (e.g., IEEE 48bit MAC) is available or may have local 288 scope where a global token is not available (e.g., serial links, 289 tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE 290 EUI-64 terminology) in the EUI-64 identifier must be set correctly, 291 as defined in [ARCH], to indicate global or local scope. 293 The procedures for creating EUI-64 based Interface Identifiers is 294 defined in [ARCH]. The details on forming interface identifiers is 295 defined in the appropriate "IPv6 over " specification such as 296 "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 298 4.0 Acknowledgments 300 The authors would like to express our thanks to Thomas Narten, Bob 301 Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, 302 Scott Bradner, Brian Carpenter, and John Stewart for their review and 303 constructive comments. 305 5.0 References 307 [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", 308 RFC1881, December 1995. 310 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 311 Internet Draft, , 312 July 1997. 314 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 315 1995. 317 [AUTO] Thompson, S., Narten T., "IPv6 Stateless Address 318 Autoconfiguration", RFC1971, August 1996. 320 [CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an 321 Address Assignment and Aggregation Strategy", RFC1338. 323 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 324 Networks", Internet Draft, , March 1997. 327 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 328 Registration Authority", 329 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 330 March 1997. 332 [EXCH] Huitema, C., R. Hinden, "Internet Exchanges", document 333 under preparation. 335 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 336 Networks", Internet Draft, , March 1997. 339 [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, 340 Version 6 (IPv6) Specification", RFC1883, December 1995. 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", RFC2119, BCP14, March 1997. 345 [TLAASN] Hinden, R., "TLA and NLA Assignment Rules", Internet Draft, 346 , July 1997. 348 6.0 Security Considerations 350 IPv6 addressing documents do not have any direct impact on Internet 351 infrastructure security. Authentication of IPv6 packets is defined 352 in [AUTH]. 354 7.0 Authors' Addresses 356 Robert M. Hinden phone: 1 408 990-2004 357 Ipsilon Networks, Inc. email: hinden@ipsilon.com 358 232 Java Drive 359 Sunnyvale, CA 94089 360 USA 362 Mike O'Dell phone: 1 703 206-5890 363 UUNET Technologies, Inc. email: mo@uunet.uu.net 364 3060 Williams Drive 365 Fairfax, VA 22030 366 USA 368 Stephen E. Deering phone: 1 408 527-8213 369 Cisco Systems, Inc. email: deering@cisco.com 370 170 West Tasman Drive 371 San Jose, CA 95134-1706 372 USA