idnits 2.17.1 draft-ietf-tuba-address-00.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. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2 Overview of OSI NSAPs' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 126 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 544: '...s. The value in source address MUST be...' RFC 2119 keyword, line 558: '...ing loop: Router SHOULD NOT be aware o...' RFC 2119 keyword, line 572: '...ers, and other TUBA systems MUST allow...' RFC 2119 keyword, line 576: '... Systems MAY also allow configur...' RFC 2119 keyword, line 580: '... proposal it MUST be possible to o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1992) is 11487 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) -- Missing reference section? '1' on line 620 looks like a reference -- Missing reference section? '2' on line 622 looks like a reference -- Missing reference section? '3' on line 625 looks like a reference -- Missing reference section? '4' on line 627 looks like a reference -- Missing reference section? '5' on line 629 looks like a reference -- Missing reference section? '6' on line 631 looks like a reference -- Missing reference section? '7' on line 634 looks like a reference -- Missing reference section? '8' on line 637 looks like a reference -- Missing reference section? '9' on line 639 looks like a reference -- Missing reference section? '10' on line 641 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ross Callon 3 DEC 4 October 1992 6 Addressing and End Point Identification, 7 For Use with TUBA 9 Status of the Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet Drafts. 16 Internet Drafts are working 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 19 Internet Drafts as reference material or to cite them other than 20 as a ''working draft'' or ''work in progress''. 22 Distribution of this memo is unlimited. 24 Abstract 26 Addressing is critically tied into routing and scaling in very 27 large Internets. This draft paper discusses how NSAP addresses 28 can be used to allow scaling in a huge Internet, and to allow the 29 flexibility necessary to deal with multiple different dimensions 30 of Internet growth. 32 This document is a personal contribution of the author as an 33 input to the IETF TUBA working group. 35 1 Summary 37 The Internet is approaching a situation in which the current IP 38 address space is no longer adequate for global addressing and 39 routing. There is an urgent need to develop and deploy an approach 40 to addressing and routing which solves these problems and allows 41 scaling to several orders of magnitude larger than the existing 42 Internet [1]. A companion paper [2] describes a simple proposal 43 which provides a long-term solution to Internet addressing, 44 routing, and scaling based on gradual migration from the current 45 Internet Suite (which is based on Internet applications, running 46 over TCP or UDP, running over IP) to an updated suite (based on 47 the same Internet applications, running over TCP or UDP, running 48 over CLNP [2]). This approach is known as "TUBA" (TCP & UDP with 49 Bigger Addresses). 51 This paper describes a proposal for how addressing and end point 52 identification may be done with TUBA. This allows the ability to 53 scale, as well as the flexibility to deal with multiple different 54 dimensions of Internet growth. For example, the Internet may grow 55 by creation of more backbones and regional networks along the 56 current Internet model, by use of IP and/or CLNP service by large 57 public carriers, and/or by provision of Internet services to a 58 very large number of homes and/or small businesses over telephone 59 networks or similar services. 61 The main motivation of TUBA is to allow the Internet to scale to 62 a size many orders of magnitude larger than the current Internet. 63 In fact, it is important to be able to scale to as large an Internet 64 as we can conceive may exist (for example, there may someday be a 65 network and hundreds of hosts in every home in the world -- any 66 proposed solution to Internet routing, addressing, and scaling 67 should be capable of easily scaling to this size). The addressing 68 proposal described in this paper makes use of the general scaling 69 concepts described in NSAP Guidelines [reference], with 70 flexibility for other address techniques also built in. 72 Annex B provides a very rough description of how this proposal 73 allows scaling beyond the largest anticipated size of the 74 worldwide Internet. 76 2 Overview of OSI NSAPs 78 80 - very flexible (some would say too flexible); binary string of 81 variable length up to 20 byte maximum length; 83 - NSAP is split into "Part which conforms to international 84 standards" (IDP) and "rest" (DSP) 86 - AFIs; first byte is AFI, indicates format for the part which 87 conforms to international standards. A variety of AFIs are 88 defined (more could easily be defined if anyone could think of a 89 use for a new format). 91 OSI standards allows for binary and decimal addresses. However, 92 the decimal encodings are obsolete/useless and can be ignored. In 93 practice, only binary representations make sense (and associated 94 external representations, such as writing addresses in 95 hexadecimal with or without separators for human readibility). 96 Old version of standard places variable length restrictions based 97 on AFI. However, this is based on obsolete requirement that 98 addresses be capable of being represented in 40 decimal digits. 99 Given that the decimal representation is obsolete, these length 100 restrictions can be ignored, and have been removed from current 101 versions of the standard. Thus only length restriction is that 102 address has maximum size of 20 bytes (regardless of AFI). 104 It is important to clarify what hosts can assume about addresses, 105 what routers can assume, and how addresses are actually to be 106 used. (see section xxx below). Addresses will need to have a lot 107 of structure, but most of the structure will be used to allow 108 address summarization (along boundaries which need to be 109 configured) and administration. Thus most of structure is not 110 visible to hosts and router implementations. 112 There are multiple NSAP formats in use. However, routers need to 113 think of NSAP addresses as a string of bits (or a string of 114 nibbles -- half bytes), where forwarding is based on prefixes. 115 Thus, routers don't know anything about any of the various 116 formats, except perhaps for the configuration code, and knowledge 117 of the size of the ID. Similarly, I would expect aggregation to 118 require substantial manual configuration, such as manually 119 configured summary addresses (surely a router is not going to 120 *automatically* determine that it should aggregate, based on 121 knowledge of the gosips). Thus, adding another format does not 122 impact the router, except perhaps by causing more entries to get 123 added to (or deleted from) the forwarding table. 125 3 Technical Considerations / Constraints 127 3.1 End Point Identification 129 An address performs two functions: It identifies the system, and 130 it specifies the location where the system is. The identification 131 of source and destination systems may, for example, be used to 132 demultiplex various network communications. The location of a 133 system may be used as one input to the routing function (to 134 determine how to get a packet delivered to the system). 136 There are some situations in which it is preferable to perform 137 these two functions independently: For example, if a system 138 moves, then the identification of the system may stay the same, 139 while the location of the system may change. Similarly, if the 140 location of the system is specified hierarchically based on 141 network topology (or based on the geographic location of a 142 private network's attachment to a public service), then a change 143 in network topology (or a change in where the public connection 144 is made) may result in a change in the specification of the 145 location of the system, even though the identity remains 146 constant. 148 Traditionally (for example, in the 32-bit IP address space) the 149 functions of identification and location are intermingled, so 150 that it is difficult or impossible to change one without changing 151 the other. The current Internet protocol suite generally does not 152 take advantage of the possibility of separating these two 153 functions (ie, enhanced features of the Internet suite, such as 154 mobile host support, had to be developed without consideration of 155 the possibility of separating location and identification 156 information). For this reason it is difficult to accurately 157 predict precisely how valueable this separation will turn out to 158 be. However, specification of the location and the identity of a 159 host system are architecturally separate functions, and therefore 160 it is felt that separation of these functions will turn out to be 161 valuable. 163 3.2 NSAP Address Standard and Address Structure 165 TUBA makes use of NSAP addresses which correspond to ISO 166 standards. This includes the requirements of the NSAP address 167 standard [reference], and routing protocols [reference ES-IS and 168 IS-IS]. However, in order to allow the host identification to be 169 separated from the location, the requirement (from IS-IS) that 170 the ID be unique within the area is strengthened, to require that 171 the ID must be globally unique. In order to emphasize that the ID 172 globally identifies the end-point (ie, the conceptual virtual 173 host which is the recipient of a CLNP packet), the globally 174 unique ID will be referred to as the End-point IDentifier (EID). 176 Also note that (in accordance with IS-IS) the last byte of the 177 NSAP address is refered to as the Selector (SEL) and is used to 178 demultiplex users of the CLNP service within a host. This 179 therefore provides the same function as the Protocol field in the 180 IP header. For TUBA, we will use values corresponding to the 181 assigned Protocol values from assigned numbers for the Selector. 182 This results in an address structure as follows: 184 Tuba +-------------------+--------------------+----------+ 185 Terms | Location | End-Point Id (EID) | Protocol | 186 +-------------------+--------------------+----------+ 187 variable length 6 bytes 1 byte 189 <------------Network Entity Title--------> 190 OSI <----Area Address---><--------ID---------><---SEL---> 191 Terms <--IDP--><--HO-DSP--> 193 Figure 1 - Basic Structure of TUBA Addresses 195 The basic structure of TUBA addresses, and the correspondance 196 between TUBA addresses and OSI addresses, is illustrated in 197 figure 1. TUBA splits the addresses into Location, EIDs, and 198 Protocol. Here the location identifies where a system is. The EID 199 identifies the system. Finally the Protocol specifies what user 200 protocol is operating above CLNP (i.e., specifies the protocol 201 whose packets are included in the CLNP Data field). 203 The OSI term "Network Entity Title" (NET) refers to the entire 204 address, except for the Protocol field. The NET therefore 205 performs the same function as a 32-bit IP address (except longer 206 with more flexibility). The NET is therefore the entity which is 207 returned by DNS name-to-address lookups (in much the same manner 208 than IP DNS lookups return a 32-bit IP address). 210 IS-IS uses the low order 7 bytes of the address as the identifier 211 and selector. The rest of the address (all of the address except 212 for the last 7 bytes) is known as the "area address", and 213 specifies which area the system is in. Once the destination area 214 is reached, IS-IS then routes directly to the destination host. 215 The IS-IS term "area address" is therefore analoguous to the TUBA 216 term "location", and specifies where the system is. 218 [NOTE: TUBA requires use of CLNP and ES-IS. Other CLNP-related 219 network layer protocols such as IS-IS are assumed to be used, but 220 are not actually required. If, hypothetically, we were to define 221 a new intra-domain protocol then the TUBA format will remain 222 constant in the sense that the low-order 7 bytes will specify EID 223 and Protocol, and the remaining high-order part of the address 224 would specify the location. However, in this hypothetical case 225 the location might not necessarily correspond to area (for 226 example, if a new protocol routed to subnets, then the "location" 227 field from the TUBA addresses may correspond to "subnet address" 228 from a new routing protocol specification). This allows a 229 graceful transition from IS-IS to a future intra-domain routing 230 protocol, in the hypothetical case that this was required at some 231 point in the future]. 233 NSAP addresses used with TUBA must be valid OSI NSAP addresses. 234 This implies that the first byte of the Location must be an AFI 235 (authority and format identifier), which specifies the format of 236 the remainder of the IDP (ie, for the high-order part of the 237 location). Depending upon the value of the AFI, the location part 238 of the address may vary from a minimum of one byte (containing 239 only an AFI) to a maximum of 13 bytes. Thus the overall TUBA 240 address may vary from a minimum of 8 bytes (which would contain 241 only an AFI, EID, and Protocol field), to a maximum of 20 bytes. 243 The TCP connection is identified by the EID and Protocol (as well 244 as information carried in the transport level header). Thus the 245 location part of the address is not required for unique 246 identification of the host. However, a complete valid address is 247 required in all packets. Thus, packet forwarding is based on the 248 entire NSAP address, and in general is not based on solely the 249 location nor on solely the EID. [Note: For normal operation with 250 IS-IS and IDRP, the packet is forwarded based on location until 251 the packet arrives at the destination area, and then forwarded 252 based on EID to the destination host]. 254 Future documentation will specify how a host (if it knows a 255 priori the EID portion of its address) can autoconfigure the 256 location part of the address. The same mechanism is also useful 257 for updating the addresses assigned to a particular area or 258 routing domain, by allowing auto-re-configuration of the location 259 part of the address. This is important to allow addresses to be 260 changed when necessary (in the current Internet architecture 261 changing addresses is just too hard). Note, these mechanisms will 262 be based on the address autoconfiguration work done for CLNP, 263 with additional TUBA-specific features (for example, to deal with 264 mobile hosts, to allow TCP connections to remain in operation 265 undisturbed through address changes, etc), The TUBA-specific 266 mechanisms are straightforward, but have not yet been written 267 down in detail due to time constraints. 269 It is necessary to be able to map from EID to name. This is 270 analoguous to the mapping from 32-bit IP address to name in the 271 current Internet architecture. EIDs therefore must be 272 administered in a manner which facilitates this mapping. In 273 addition, EID assignments must be global, and must conform to 274 Internet requirements (TBD). Initial proposal is described in 275 Annex A. 277 3.3 Addressing and Scaling 279 The primary motivation for TUBA is to allow scaling of the 280 Internet architecture to a truely enormous worldwide ubiquitous 281 Internet. This requires that addresses used with TUBA be assigned 282 in a manner which facilitates scaling. 284 288 The current IP addressing scheme assigns one or more "network 289 numbers" to each customer. There are two immediate problems with 290 this approach: 292 a)The Internet is running out of some types of addresses 293 (particularly, class B network numbers). 295 b)Internet routing tables (and routing protocols) require a 296 separate entry for every customer (ie, for each network 297 number). As the internet grows, this implies that the growth 298 in routing tables and routing protocol information grows at 299 least linearly with the number of customers. 301 The first of these problems is largely a matter of ensuring that 302 the address space (including any hierarchical subdivision of the 303 address space) is large enough so that you don't run out of addresses 304 to assign. This implies that one needs to be very careful when 305 subdividing and address space, but does not appear to be a 306 significant problem for the NSAP address space due to the large 307 number of addresses available. 309 The second of these problems require much more care. There are 310 several proposals for how to deal with growth of addressing 311 information: 313 a)Massive Resources 315 This approach attempts to deal directly with one or more 316 separate routes for each Internet customer. In the future this 317 potentially will require massive routing tables, massive CPU 318 and memory in routers, and some (unspecified) management tools 319 to make management of the associated information feasible. 321 b)Provider Based Addresses 323 This approach makes use of addresses for customer networks 324 which are based on prefixes assigned by provider. Thus, any 325 one particular public service provider would obtain a large 326 block of the address space based on a single prefix from a 327 national or international address authority. Each provider 328 would then allocate a part of this address space (based on a 329 longer prefix) to each customer. This is the approach 330 recommended by RFC 1347. 332 c)Provider-Subnet Addresses 334 This approach is not intended for general use by all networks, 335 but rather is intended to deal with one important special 336 case. In particular, in some situations it is necessary to 337 deal with very large numbers of individual systems or small 338 sites connected via telephone networks, public data networks, 339 ISDN, or other public service. For example, such situations 340 may occur in retail sales and home applications. In general, 341 telephone networks, public data networks, and similar networks 342 have their own globally significant address space. In these 343 cases, it will be necessary to map from the global internet 344 address space to the subnet address space used by the 345 provider. This is facilitated with TUBA by allowing such 346 "provider-subnet" addresses to be embedded as part of the 347 "location" field in the TUBA NSAP address. 349 Provider-subnet addresses are considered important enough that 350 they are discussed separately in section 3.4 below. 352 d)Geographic Addresses 354 This approach assigns addresses to customer networks based on 355 the geographic area of their attachment to a public service 356 provider. This approach requires considerable cooperation 357 between public service providers. In particular, it requires 358 that a metro-area be fully connected, (i.e., either once a 359 packet is delivered to any point in a metro area, it can reach 360 any other point in the same metro without leaving the metro, 361 or special mechanisms such as encapsulation are used to allow 362 the packet to be delivered between different providers in the 363 same metro area via intermediate networks). 365 The topology constraint associated with geographic addressing is 366 just a specific case of the general requirement/assumption of any 367 hierarchical routing scheme: that each region, sub-region, 368 sub-sub-region, etc. be fully connected. There is an analogous 369 case with provider-based addressing: A provider's facilities must 370 be fully connected if they are to be identified by a single 371 prefix. 373 (Note, this is not an absolute requirement -- you can use tricks 374 like tunneling to link together the pieces of a partitioned 375 region. IS-IS can do that to heal partitioned Level 1 Areas, and 376 the various mobile IP schemes do something similar to allow 377 members of a subnet to roam to arbitrary places in the graph.) 379 Provider-based addressing and geographic addressing are not 380 necessarily mutually exclusive. Suppose that some providers rely 381 on provider-based addresses (implying that customers of this 382 provider are required to take addresses from that provider's 383 space), and other providers make use of geographic addressing. In 384 this case, those providers which use geographic addressing are 385 required to cooperate and exchange traffic between them, but will 386 have the offsetting advantage that they can advertise "open" 387 addressing (ie, addressing which does not lock the customer into 388 a single provider). 390 TUBA does not require any particular solution to the hierarchical 391 routing issue. Any combination of Provider based addressing, 392 Geographic addressing, and Provider-Subnet addressing is permitted 393 with TUBA. 395 399 3.4 Provider-Subnet Addressing to Homes and Small Sites 401 Imagine a situation in which the financial services department of 402 XYZ corporation has placed point-of-sale terminals in 100,000 403 small retail stores (we might presume that the stores are 404 independently-owned, and that XYZ corporation has contracted to 405 provide a service to the stores). Alternatively, imagine a 406 situation in which XYZ entertainment corporation has placed 407 entertainment devices in 100,000 homes. 409 In either cases, let's suppose that access from the central 410 offices of XYZ corporation to the 100,000 individual sites is 411 done over the public telephone network, and that the applications 412 running from XYZ to the sites is done using Internet applications 413 running over TUBA. In this case, it will be necessary to assign 414 NSAP addresses to each of the individual sites, and to facilitate 415 routing between XYZ corporation and the individual sites. 417 With the existing IP architecture, this problem is very hard to 418 solve. It becomes necessary to map from the 32-bit IP address 419 space to the "subnet point of attachment (SNPA) addresses" (ie, 420 phone numbers) used in each customer site. With IP, this requires 421 a very large mapping table, which is either difficult or 422 impossible to manage. 424 With TUBA, this problem is solved by embedding the SNPA address 425 in the location part of the NSAP address. This is facilitated by 426 defining a separate AFI for each commonly used type of SNPA 427 address. For example, in the telephone case the NSAP/TUBA address 428 would be as follows: 430 432 In this case the AFI is 1 byte long, the telephone number is 433 variable length (padded to a constant length of xx bytes, 434 corresponding to the maximum length of worldwide telephone 435 numbers), the EID is 6 bytes long, and the protocol is 1 byte 436 long. 438 Note that with this approach, rather than requiring a mapping 439 table with 100,000 entries, only a single entry is needed in 440 routing tables. This entry would route packets destined to the 441 appropriate type of address to one or more routers with 442 interfaces on the public telephone network. The routers attached 443 to the telephone network would then be able to obtain the correct 444 subnet address (ie, telephone number) by extracting it from the 445 NSAP address. If a finer grained control was required (for 446 example, routing traffic separately based on country, or based on 447 area code), then this would be easy to do by using prefixes 448 applied to the telephone number. This is facilitated since the 449 telephone number space is globally meaningful, and is assigned in 450 a manner which corresponds to the global topology of the 451 telephone network. 453 A similar approach can be used for public networks using other 454 common address formats. AFI values have been assigned for telex 455 numbers, telephone numbers, X.121 addresses, and E.164 addresses 456 (used by ISDN and some other public networks). 458 3.5 Compatibility with Current CLNP deployment 460 TUBA is based on the use of CLNP as a scalable network layer for 461 use with existing Internet applications. However, it must be 462 realized that CLNP will also be used for other purposes. For 463 example, some OSI applications have been deployed which make use 464 of the services provided by CLNP. Similarly, some proprietary 465 applications have also been deployed which make use of CLNP. 467 It is therefore desireable (although not absolutely necessary) to 468 allow a common address format be used for TUBA, and for other 469 uses of CLNP. The use of a common address format will simplify 470 network configuration, management, and operation. 472 The identifiers used with TUBA must be compatible with the 473 identifiers used with other CLNP applications, in the sense that 474 the same ID cannot be assigned for one host for use with TUBA and 475 to another host in the same area for use with OSI applications. 477 Use of common identifiers is also somewhat useful but is not as 478 important. For example, if TUBA makes use of one format for 479 identifiers, and OSI applications make use of a different format, 480 then multi-protocol hosts will have to have two different 481 identifiers assigned to them. However, the requirement that 482 the identifiers used with TUBA must be capable of being used as 483 the index for a DNS identifier-to-name lookup constrains the form 484 of identifier used with TUBA. 486 Generally, current CLNP applications (including OSI and 487 proprietary applications) make use of two common methods for 488 assigning IDs: Some systems use IEEE 48-bit globally administered 489 unicast IDs, Some use manual configuration of IDs. The latter are 490 not a problem (locally administered IDs for use with OSI 491 applications can be chosen for compatibility with TUBA). However, 492 given that some systems are already using IEEE IDs, we have two 493 choices: (i) Use globally administered unicast IEEE IDs; or (ii) 494 Avoid the 25% of the 48 bit ID space which happens to correspond 495 to the IEEE globally administered unicast IDs. 497 Given our desire to make ID to name lookups easy, we propose to 498 use the latter approach: All IDs assigned for use with TUBA will 499 use a prefix which avoids collision with the IEEE globally 500 administered space. 502 The current practice in assignment of NSAP addresses is somewhat 503 more complex (ie, different formats are being used in different 504 situations, and some customer networks are uncertain as to which 505 NSAP format would be the best to use). However there is a strong 506 trend towards use of NSAP addresses which are chosen to allow 507 scaling. In particular, the current trend is towards use of 508 provider-based addresses assigned more-or-less in conformance 509 with RFC 1237. Also, existing NSAP allocations make use of a 510 variety of address lengths, but use a consistent 6 byte ID. The 511 current practice is therefore compatible with TUBA addressing 512 requirements specified in this document. 514 516 4 Proposed Address Solution 518 4.1 What Hosts can Assume about Addresses 520 - The NSAP address is split into Location (variable length), 521 EID (6 bytes), Protocol (1 byte) 523 - Location should be treated as flat variable length binary 524 string (in fact will have structure, but structure is not 525 visible to host) 527 - EID is six byte globally unique identifier. TUBA host can 528 assume that this will always be globally unique, and will 529 identify the other system. DNS will be able to look up name 530 based on EID. However, host cannot make any assumptions about 531 the internal contents of the ID. 533 - A single host can have multiple values for the location part 534 of the address. It is possible that some future specifications 535 might allow what constitutes a correct location part of the 536 address for any one host to vary over time. 538 - Logically a host only has one correct value for the EID. Thus, 539 if a real physical host has multiple EIDs assigned to it, it 540 is treated as if it were multiple logical hosts. If the EID 541 changes, then logically you have a different host. 543 - Protocol field uses same values as IP. Host uses value in 544 destination address. The value in source address MUST be 545 ignored. 547 4.2 What Routers can Assume about TUBA Addresses 549 - The NSAP address is split into Location (variable length), EID 550 (6 bytes), Protocol (1 byte) 552 - Routing is in accordance with other standards 554 - For initial use, using existing CLNP-associated routing 555 protocols such as ES-IS, IS-IS and IDRP 556 - These use prefixes on location part, on "nibble" boundaries, 557 plus ID in destination area 558 - For forwarding loop: Router SHOULD NOT be aware of internal 559 structure of location part of address, except for matching 560 prefixes to location part of address 562 - Note: During transition period EID will contain IP address. 563 This could potentially be used for router-visible transition 564 methods such as packet translation details outside of the 565 scope of this document. 567 - Router ignores Protocol (as required by IS-IS and IDRP) 569 - 570 4.3 Configuration of NSAP Addresses 572 Hosts, routers, name servers, and other TUBA systems MUST allow 573 configuration of NSAPs as a simple hexadecimal string without 574 consideration of internal structure. 576 Systems MAY also allow configuration in other ways (e.g., systems 577 may allow the option of checking to see if a valid AFI is 578 provided, and/or allow the IDP to be entered in a format which is 579 AFI dependent). However, in order to conform with the TUBA 580 proposal it MUST be possible to override this and enter NSAPs as 581 simple hexadecimal strings. 583 NSAPs may be input as simple hexadecimal strings. Different 584 sub-fields in the NSAP may be separated by dots, but the dots are 585 optionally included only for ease of writing down the NSAP, and 586 do not have semantic meaning (i.e., the dots are ignored by 587 address parsers). The user can put them wherever he/she wants in 588 a configuration file (and they can be inserted in any position on 589 output). For example the following NSAP Addresses are all 590 equivalent: 592 47000580FFEC00000000000010000080F1005100 594 47.0005.80FF.EC00.0000.0000.0010.0000.80F1.0051.00 596 47.0005.80.FFEC00.0000.0000.0010.000080F10051.00 598 The latter grouping uses the location of dots to group bytes 599 according to administrative fields. In either case, the placement 600 of the dots has no significance other than readability. 602 4.4 What Address Solution Will be Used 604 606 Currently multiple things in use, will converge over time 608 Depends upon situation, can use combination of provider based, 609 geographic, or provider-subnet address based. 611 For geographic base, use different DFI, split rest differently 613 For subnet-provider-address-based, use X.121 (or...) format 615 5 References 617 620 [1] Overview of ROAD problem (ROAD report or IESG report) 622 [2] RFC 1347, "TCU and UDP with Bigger Addresses (TUBA), a 623 Proposal for... 625 [3] RFC 1348, and/or its replacement 627 [4] NSAP Guidelines 629 [5] Dave Piscitello's TUBA CLNP Profile 631 [6] "Protocol for Providing the Connectionless-Mode Network 632 Service", ISO 8473, 1988. 634 [7] "Supernetting: An Address Assignment and Aggregation 635 Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, Mar 1992. 637 [8] IP Address Guidelines paper 639 [9] Steve Deering's Geographic paper 641 [10] "Extending the IP Internet Through Address Reuse", Paul 642 Tsuchiya, December 1991. 644 6 Security Considerations 646 Security issues are not discussed in this memo. 648 7 Author's Address 650 Ross Callon 651 Digital Equipment Corporation 652 550 King Street, LKG 1-2/A19 653 Littleton, MA 01460-1289 655 Phone: 508-486-5009 657 Email: Callon@bigfut.lkg.dec.com 659 Annex A A Draft Proposal for EID Assignments 661 A.1 Constraints 663 665 A.2 Proposal 667 For initial use: 669 - Fixed 16-bit prefix prepended to IP address 671 - Prefix chosen to not collide with IDs selected from IEEE 672 globally administered space 674 For future use: 676 - Administered by IANA 678 - Details for further study 680 Annex B A Rough Analysis of NSAP Scaling 682 We know that the Internet will grow a lot, but we don't know how 683 the Internet will grow. In particular, we don't know what the 684 topology will look like. For example, if the Internet reaches 685 every home in North America and Europe, how will this public 686 Internet service be provided? Will there be one large public 687 service provider per country, or many smaller providers? If there 688 are many public service providers in each country, how will the 689 providers interconnect? How many providers will there be 690 worldwide and how large will they be? Will the bulk of systems 691 connected to the Internet use "public service provider specific" 692 addresses such as X.121, E.164, or telephone numbers? 694 This uncertainty about the manner in which the Internet topology 695 will grow leads to a resulting difficulty in determining what 696 future Internet addressing should look like, and in accurately 697 predicting how any particular addressing plan will scale. 698 Fortunately, the NSAP address scheme used with TUBA provides a 699 great deal of flexibility in how addresses are structured. Also, 700 as discussed in section 4, TUBA-capable hosts are required to 701 make no assumption about the substructure of the location field 702 of the NSAP addresses, and routers similarly should make only 703 very limited assumptions about the location field. This implies 704 that the substructure can be changed (or different structures for 705 the location field used in different parts of the Internet) 706 without effecting existing equipment. 708 Given this flexibility in NSAP address structure and uncertainly 709 in network topology design, it is difficult to accurately predict 710 precisely how addresses will scale. However, we can give rough 711 "back of the envelope" calculations for several different 712 scenarios. 714 B.1 Scaling of Provider-Based Addressing 716 It is proposed that provider based addresses basically look like: 718 720 * NOTE: By "country", we really mean country or geographic area. 721 For example, multi-country continental networks (such as a 722 European wide backbone) would specify continent in this field, 723 rather than country. 725 ** NOTE: The "substructure" field is needed because eventually we 726 will either end up with too many providers in order to route on a 727 flat provider space (in one country), or, more likely, end up 728 with too many customers of a single provider in a single country. 729 For example, given more than 10,000,000 companies in the USA, and 730 roughly 100,000,000 homes in the USA, it is likely that 731 eventually there will be one or more providers in the USA which 732 have enough customers to require hierarchical routing between 733 customers of the same provider. This "substructure" field is 734 referred to as "reserved" in the US GOSIP and ANSI address 735 spaces, since initially (so long as the number of providers 736 within a country, and the number of customers of any one provider 737 is small), the "substructure" field does not need to be used. 739 Note that the some of these subfields in the Provider-based 740 addressing will actually be further subdivided into several 741 sub-sub-fields. For example, the country will be specified using 742 the combination of an AFI (authority and format identifier -- the 743 first byte of the NSAP giving the format of the next field) and 744 DCC (data country code) or ICD (international code designator). 745 Some NSAP format provide a single byte after the country to 746 indicate the type of the rest of the address (for example, this 747 byte will specify whether the address is provider-based or 748 geographic-based). 750 For example, with US GOSIP based addressing, the approximate 751 mapping is as follows: 753 My Term GOSIP Field 754 (for rough analysis) term size 756 Country AFI and ICD 3 bytes 758 (not mentioned) DFI 1 byte 760 Provider AA 3 bytes 762 substructure reserved 2 bytes 764 customer RD 2 bytes 766 area area 2 bytes 768 EID ID 6 bytes 770 (not mentioned) Protocol/SEL 1 byte 772 Note that the DFI (DSP Format Identifier) in the GOSIP space can 773 be used to identify different address formats, such as the 774 provider based format (as illustrated above) versus a geographic 775 format. The selector/Protocol field is provided by the GOSIP 776 format (and required for TUBA addressing), but is not considered 777 for purposed of analysis of scaling because the Protocol/Selector 779 Internet Draft Addressing and EID for Use with TUBA Oct 1992 781 field is only used for demultiplexing within a host, and is 782 therefore not useful for scaling to a large number of hosts. 784 Initially, we can probably treat the country and provider as a 785 flat field which specifies the provider. Assuming that dynamic 786 routing in a flat address space allows for roughly up to 10,000 787 entries at one level (noting that the phone system seems to 788 manage with this size, and that the Internet also is managing 789 routing in a flat space with several thousand network numbers). 790 Our guess is that this may be sufficient indefinitely (there may 791 never be more than 10,000 providers). If this guess is wrong and 792 the number of providers gets large enough that it is not possible 793 to route amongst providers on a flat basis, then we will need to 794 route hierarchically amongst providers. 796 However, provider identifiers are in fact being handed out 797 geographically, based on country (or at least continent, in the 798 case of multinational nets). Thus, if we needed to, we could 799 first route on country, then on provider, without changing the 800 current address assignments. In practice, if the number of public 801 service providers worldwide gets to be substantially larger than 802 roughly 10,000, then most likely there will be some "major" 803 providers, which will continue to be advertised globally in 804 routing advertisement and tables, as well as some "minor" 805 providers, which can be routed on a per-country basis (i.e., 806 routes to the minor providers will only be maintained within 807 their country of operation). 809 The RD field allows up to about 10,000 customers per provider 810 (again, routed on a flat basis; if fact, more than 10,000 entries 811 are possible, but we are assuming that 10,000 is a reasonable 812 "order of magnitude" estimate of the comfortable maximum size of 813 a routing table). 815 Let's suppose that we end up with something like 100 providers in 816 the US (it might be larger, but this number is a sort of "today's 817 guess"). Given that there are millions of companies in the US 818 (most very small), it would appear inevitable that if we assign 819 value for "customer" to each company (even small ones), then we 820 are eventually going to get more than 10,000 customers for a 821 single provider. Thus there is the substruture field sitting 822 there waiting in just the right spot to allow a single provider 823 to hierarchically subdivide the addresses under it. 825 The Area, and EID fields are used for routing within a company / 826 campus. For a large company we might have a few hundred areas. If 827 we needed to, we could have a few thousand (the routing 828 algorithms could handle this, but it is dubious that there will 829 be many companies large enough to need it). Each area could have 830 up to a few thousand end systems. 832 A rough upper bound of the size that can be handled by this 833 scheme can be obtained by multipling together the maximum size at 834 each level. Without using the substructure (reserved) field, and 835 assuming that we would prefer to use flat routing of providers 836 worldwide, we get 10,000 providers (worldwide) with 10,000 837 customers each with 100 areas per customer with 1000 hosts per 838 area. This implies about 10**8 customers with about 10**13 hosts. 839 If we ignore homes, then this is about the anticipated maximum 840 size of the Internet. However, note that we will probably never 841 actually be able to reach the "upper bound" size, since it is 842 nearly impossible to completely fill in every level of a 843 hierarchical address without having some parts of the address 844 space become exhausted (ie, we will probably end up having to use 845 the reserved field). 847 If some companies have more than 100 areas that is fine (we could 848 easily go much larger). If we end up with more than 10,000 849 providers then again this is fine, since there is the option of 850 routing by country/continent first, or of subdividing the 851 providers within a country by using the "sustructure" field. If 852 we end up with fewer providers and more customers per provider, 853 then we will need to use the reserved field to allow hierarchical 854 subdivision of the customers of a provider, this would 855 potentially allow several million customers of each provider, 856 each customer able to have well over 100,000 hosts (again, each 857 customer could have up to several thousand areas and several 858 thousand hosts per area). 860 We can similarly put together an upper bound with use of the 861 reserved field. We might assume that we are unlikely to get more 862 than 10,000 major providers worldwide. Thus, although the NSAP 863 address scheme allows for more than this number, it is not likely 864 to actually be used (except perhaps for a number of smaller 865 providers). If we assume 10,000 providers worldwide, with 866 10,000,000 customers (router hierarchically within each provider 867 using the "substructure" field, and noteing that the NSAP 868 structure could actually handle more than this -- we just don't 869 expect any one provider to require more than this), then we come 870 up with a rough upper bound of 10**11 customers, each with up to 871 several thousand areas, and several thousand hosts per area. Note 872 however that this bound is much larger than the number of 873 potential sites which exist which could want to attach to the 874 Internet, unless we consider individual homes. 876 B.2 Provider/Geographic Based Addresses to Individual Homes 878 Routing to individual homes is also well handled. Given that each 879 home is located in a small geographic location, each provider 880 would probably arrange its provider network geographically, use 881 the RD field (or perhaps the reserved field) geographically, and 882 then assign a single area to each house in a geographic area 883 (assuming that we have no more than a few thousand hosts within a 884 single house). This would allow 10,000 geographic areas per 885 provider (using the RD field) and 10,000 houses per geographic 886 area (using the area field), or a maximum of about 100,000,000 887 houses per provider. If there is a single provider serving a 888 country which has more than 100,000 houses (perhaps the Chinese 889 monopoly PTT), then they will to use the reserved field and 890 arrange the Chinese PTT itself in a hierarchical way, allowing 891 10,000 top-level things (using the Reverved field), 10,000 next 892 level things (using the RD field), and 10,000 houses per thing 893 (using area field). Thus the Chinese PTT, if it really needed to, 894 could hand out 10**12 addresses to 10**12 houses within China, 895 with each house having a thousand computers in it. 897 Note, in this example, it is possible that the Chinese PTT might 898 not choose to route CLNP directly, but rather might offer simple 899 telephone service or ISDN service to each home. In this case, 900 provider-subnet addresses would be used, as was discussed earlier 901 in section 3.4. 903 B.3 Scaling of Geographic Addressing 905 907 B.4 Summary 909 It is hard to anticipate exactly how much fan-out will exist at 910 each level of the hierarchy because we still don't know exactly 911 what providers will exist and how many customers each will have. 912 However, the NSAP address space with the ANSI/GOSIP address 913 structure allows plenty of room and flexibility and scales well 914 beyond the current size of the world.