idnits 2.17.1 draft-ietf-ngtrans-6bone-ptla-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 305 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([6BONE-TLA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 10, 2000) is 8807 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) == Unused Reference: 'HARDEN' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 276, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2546 (ref. 'HARDEN') (Obsoleted by RFC 2772) ** Obsolete normative reference: RFC 2471 (ref. '6BONE-TLA') (Obsoleted by RFC 3701) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Bob Fink, ESnet 2 March 10, 2000 4 6BONE pTLA and pNLA Formats (pTLA) 6 8 Abstract 10 This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, 11 allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-Level Aggregation 12 Identifiers(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months and 24 may be updated, replaced, or obsoleted by other documents at any time. It 25 is inappropriate to use Internet-Drafts as reference material or to cite 26 them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet Draft expires September 10, 2000. 36 Acknowledgements 38 The address formats here are contributions of various early participants 39 of the 6bone testbed project, and of the IPng and NGtrans IETF working 40 groups. 42 Contents 44 Status of this Memo.......................................... 46 1. Introduction............................................. 48 2. 6BONE pTLA/pNLA Format................................... 50 3. Security Considerations.................................. 52 4. Change Log............................................... 54 REFERENCES................................................... 56 AUTHOR'S ADDRESS............................................. 58 1. Introduction 60 This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, 61 allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-Level Aggregation 62 Identifiers (pTLA) and pseudo Next-Level Aggregation Identifiers (pNLA). 64 The guiding specifications for IPv6 addressing relating to the 6bone 65 prefix, and the pTLA and pNLA formats, are "IP Version 6 Addressing 66 Architecture" [ADDRARCH], and "An IPv6 Aggregatable Global Unicast 67 Address Format" [AGGR]. 69 The purpose of creating pseudo TLA and NLA formats for the 6bone is to 70 provide a prototype of the actual TLA and NLA formats as they might be 71 used in production IPv6 networks. To do this economically, using only a 72 minimum of real production IPv6 address space, a single TLA, 3FFE::/16, 73 was reserved by the IANA (Internet Assigned Numbers Authority) for 74 testing on the 6bone. Thus it was necessary to define a pretend-to-be, 75 or pseudo, TLA and NLA structure to use under the 3FFE::/16 prefix. 77 Given the 48-bit length of the IPv6 Aggregatable Global Unicast Address 78 external routing prefix (that contains the TLA and NLA identifiers), there 79 is enough room to extend the TLA ID to contain a pTLA and shorten the 80 NLA ID to become a pNLA. This document specifies this. 82 In early 1999, it was decided to change the 6bone's pTLA format to allow 83 greater expansion of the testbed network, thus accommodating more than the 84 original 256 pTLA-s. Thus there are now two 6bone pTLA and pNLA formats. 85 This document specifies this. 87 2. 6BONE pTLA and pNLA Formats 89 2.1 Original 8-bit pTLA and 24-bit pNLA Format 91 The original pTLA and pNLA format was intended to accommodate 256 pTLA-s, 92 i.e., backbone networks carrying IPv6 transit traffic. 94 The original TLA and NLA ID-s as specified in [AGGR] are as follows: 96 | 3 | 13 | 32 | 16 | 64 bits | 97 +---+-----+---------------------+--------+-----------------+ 98 |001| TLA | NLA ID | SLA ID | Interface ID | 99 +---+-----+---------------------+--------+-----------------+ 101 The TLA value 1FFE was assigned to the 6bone, which when viewed with the 102 3-bit format preffix in prefix notation form is 3FFE::/16. 104 The first 8-bits of the NLA ID space are assigned as the pTLA that 105 defines the top level of aggegation (backbone) for the 6bone. This 106 provides for 256 6bone backbone networks, or pTLA-s, and leaves a 24-bit 107 pNLA ID for each pTLA to assign as needed. 109 | 16 | 8 | 24 | 16 | 64 bits | 110 +-+---------+-----+-------------+--------+-----------------+ 111 | 0x3FFE |pTLA | pNLA | SLA ID | Interface ID | 112 +-+---------+-----+-------------+--------+-----------------+ 114 In prefix notation form the pTLA is 3FFE:nn00::/24, where nn is the pTLA 115 assignment. 117 The remaining NLA ID space can be used by each pTLA for their downward 118 aggregated delegation: 120 | n | 24-n bits | 16 | 64 bits | 121 +-----+--------------------+--------+-----------------+ 122 |pNLA1| Site | SLA ID | Interface ID | 123 +-----+--------------------+--------+-----------------+ 125 | m | 24-n-m | 16 | 64 bits | 126 +-----+--------------+--------+-----------------+ 127 |pNLA2| Site | SLA ID | Interface ID | 128 +-----+--------------+--------+-----------------+ 130 | o |24-n-m-o| 16 | 64 bits | 131 +-----+--------+--------+-----------------+ 132 |pNLA3| Site | SLA ID | Interface ID | 133 +-----+--------+--------+-----------------+ 135 The pNLA delegation works in the same manner as specified in [AGGR]. 136 pTLA's are required to assume registry duties for the pNLA's below them, 137 pNLA1's for those below them, etc. 139 2.2 New 12-bit pTLA and 20-bit pNLA Format 141 After if became clear that the 6bone would become a useful testbed for 142 transition, in addition to its early role asa testbed for specifications 143 and implementations, the 6bone community decided to expand the size of the 144 pTLA ID. 146 Several important decisions regarding this expansion of the pTLA field are: 148 1. to leave the currently allocated 8-bit pTLA-s in use until the space was 149 needed, thus relying on a range value check to indicate the new pTLA format, 151 2. to use a modulo 4-bit sized pTLA ID to make reverse path entry into the 152 DNS easier, 154 3. given 2. above, to keep the pTLA ID size as small as possible to not 155 restrict pNLA ID size. 157 Therefore, the first 12-bits of the NLA ID space are assigned as the pTLA 158 that defines the top level of aggegation (backbone) for the 6bone. This 159 would eventually provide for 4096 6bone backbone networks, or pTLA-s, and 160 leaves a 20-bit pNLA ID for each pTLA to assign as needed. 162 | 16 | 12 | 20 | 16 | 64 bits | 163 +-+---------+-------+-----------+--------+-----------------+ 164 | 0x3FFE | pTLA | pNLA | SLA ID | Interface ID | 165 +-+---------+-------+-----------+--------+-----------------+ 167 In prefix notation form the pTLA is 3FFE:nnn0::/28, where nnn is the pTLA 168 assignment. However, as the existing 8-bit pTLA's are being left in use 169 for the present, the nnn value starts at 0x800 for now, thus yielding only 170 2048 pTLA's in this new format. 172 The remaining NLA ID space can be used by each pTLA for their downward 173 aggregated delegation: 175 | n | 20-n bits | 16 | 64 bits | 176 +-----+--------------------+--------+-----------------+ 177 |pNLA1| Site | SLA ID | Interface ID | 178 +-----+--------------------+--------+-----------------+ 180 | m | 20-n-m | 16 | 64 bits | 181 +-----+--------------+--------+-----------------+ 182 |pNLA2| Site | SLA ID | Interface ID | 183 +-----+--------------+--------+-----------------+ 185 | o |20-n-m-o| 16 | 64 bits | 186 +-----+--------+--------+-----------------+ 187 |pNLA3| Site | SLA ID | Interface ID | 188 +-----+--------+--------+-----------------+ 190 As with the original pTLA format, the pNLA delegation works in the same 191 manner as specified in [AGGR]. pTLA's are required to assume registry 192 duties for the pNLA's below them, pNLA1's for those below them, etc. 194 2.3 Example Format For pNLA's 196 An example usage of the pNLA space is given to demonstrate what is 197 reasonable and possible. It should not be assumed that this implies the 198 pNLA space must be used this way. As the new pTLA and pNLA format is now 199 the default, the example here assumes the 20-bit pNLA format. 201 The following example provides for up to 255 intermediate transit ISP's 202 (called pNLA1 below). The pNLA1 value of zero is meant to indicate that 203 there is no intermediate transit ISP between the backbone pTLA network 204 and the end user site. 206 |<-----20-bit pNLA ID----->| 207 | | 208 | 8 | 12 bits | 16 | 64 bits | 209 +-----+--------------------+--------+-----------------+ 210 |pNLA1| Site ID | SLA ID | Interface ID | 211 +-----+--------------------+--------+-----------------+ 213 Intermediate transit networks (pNLA1's) would assign uniques Site ID's for 214 eachend user site served. 216 As an example of this, assuming a backbone pTLA of 0x800, no intermediate 217 transit ISP (thus a pNLA1 of 0x00) and a sequential site ID (with start at 218 the right edge numbering) of 0x0001, the routing prefix for the first site 219 would look like: 221 3FFE:8000:0001/48 222 6bone _|||| |||| ||||___site 223 |||| | 224 b/b site____|||| | 225 | | 226 transit________|_| 228 Another example of this usage, assuming the same backbone pTLA1 of 0x800 and 229 an intermediate transit ISP under it (numbering from the left edge) with an 230 NLA1 of 0x80, and a sequential site ID of 0x0001, the routing prefix for the 231 first site connected would look like: 233 3FFE:0180:0001/48 234 6bone _|||| |||| ||||___site 235 |||| 236 b/b site____|||| 237 || 238 transit_______|| 240 Note 1: the two sites numbered 0x001 in the above examples are really two 241 different sites as their pNLA1 authority above them is different (i.e., in 242 the first case no transit exists thus the site is directly connected to 243 the pTLA backbone ISP, and in the second case the site is directly 244 connected to intermediate transit ISP 0x80). 246 Note 2: there would be nothing to prevent an pNLA1 transit site from 247 further allocating pNLA's below, but that becomes the policy of the pTLA 248 and pNLA's above them to work out. 250 Note 3: The 6bone registry, which is a RIPE-style database for documenting 251 IPv6 sites connected to the 6bone, has an "inet6num" object to allow 252 documentation of all IPv6 addresses allocated. 254 3. Security Considerations 256 IPv6 addressing documents do not have any direct impact on Internet infra- 257 structure security. 259 4. Change Log 261 Changes since version -00 of the draft: 263 none yet, still on -00 265 REFERENCES 267 [ADDRARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 268 RFC 2373, July 1998. 270 [AGGR] R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable Global 271 Unicast Address Format", RFC 2374, July 1998. 273 [HARDEN] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", 274 RFC xxxx, December 1999. Replaces RFC 2546. 276 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 277 Requirement Levels", RFC 2119, March 1997. 279 [6BONE-TLA] R. Hinden, R. Fink, J. Postel, "IPv6 Testing Address 280 Allocation", RFC 2471, December 1998. 282 AUTHOR'S ADDRESS 284 Bob Fink, ESnet 285 Lawrence Berkeley National Lab 286 MS 50A-3111 287 1 Cyclotron Road 288 Berkeley, CA 94720 289 USA 291 phone: +1 510 486 5692 292 fax: +1 510 486 4790 293 email: fink@es.net 295 -end