idnits 2.17.1 draft-ietf-pip-architecture-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-04-26) 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 == 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 a Security Considerations 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (June 1993) is 11273 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: '5' is defined on line 2353, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2364, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pip Working Group Paul Francis 3 (formerly Paul Tsuchiya) 4 INTERNET-DRAFT Bellcore 5 June 1993 7 Pip Near-term Architecture 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts). 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 Abstract 28 Pip is an internet protocol intended as the replacement for IP 29 version 4. Pip is a general purpose internet protocol, designed to 30 evolve to all forseeable internet protocol requirements. This 31 specification describes the routing and addressing architecture for 32 near-term Pip deployment. We say near-term only because Pip is 33 designed with evolution in mind, so other architectures are expected 34 in the future. This document, however, makes no reference to such 35 future architectures. 37 Changes from the last version 39 This version contains the following changes: 41 1. Numerous typos and minor corrections. 43 2. Addition of "anycast" addressing. 45 3. Updated Pip header description. 47 4. Update of Pip Address types (add top-level assignments to 48 private networks). 50 5. Allow for multiple Exit PDN Addresses in a single packet (for 51 multiple PDNs). 53 6. Change to the way source information is carried in Class D style 54 multicast (Pip Address instead of Pip ID). 56 7. Scoping is added to the two multicast descriptions. 58 8. The RC for the near term Pip architecture (RC Contents = 1) is 59 defined. 61 9. The exit routing procedure has been modified. 63 10. The host autoconfiguration is updated to include automatic ID 64 and domain name assignment. 66 11. Transition of DNS (Pip-smart DNS interacting with old DNS sys- 67 tems) has been added. 69 Table of Contents 71 1 Pip Architecture Overview ....................................... 5 72 1.1 Pip Architecture Characteristics .............................. 5 73 1.2 Components of the Pip Architecture ............................ 6 75 2 A Simple Example ................................................ 7 77 3 Pip Overview .................................................... 8 79 4 Pip Addressing .................................................. 10 80 4.1 Hierarchical Pip Addressing ................................... 11 81 4.1.1 Assignment of (Hierarchical) Pip Addresses .................. 14 82 4.1.2 Host Addressing ............................................. 16 83 4.2 CBT Style Multicast Addresses ................................. 17 84 4.3 Class D Style Multicast Addresses ............................. 18 85 4.4 Anycast Addressing ............................................ 19 87 5 Pip IDs ......................................................... 19 89 6 Use of DNS ...................................................... 21 90 6.1 Information Held by DNS ....................................... 21 91 6.2 Authoritative Queries in DNS .................................. 22 93 7 Type-of-Service (TOS) (or lack thereof) ......................... 24 95 8 Routing on (Hierarchical) Pip Addresses ......................... 24 96 8.1 Exiting a Private Domain ...................................... 26 97 8.2 Intra-domain Networking ....................................... 26 99 9 Pip Header Server ............................................... 28 100 9.1 Forming Pip Headers ........................................... 28 101 9.2 Pip Header Protocol (PHP) ..................................... 30 102 9.3 Application Interface ......................................... 30 104 10 Routing Algorithms in Pip ...................................... 31 105 10.1 Routing Information Filtering ................................ 33 107 11 Transition ..................................................... 34 108 11.1 Justification for Pip Transition Scheme ...................... 34 109 11.2 Architecture for Pip Transition Scheme ....................... 35 110 11.3 Translation between Pip and IP packets ....................... 36 111 11.4 Translating between PCMP and ICMP ............................ 37 112 11.5 Translating between IP and Pip Routing Information ........... 38 113 11.6 Old TCP and Application Binaries in Pip Hosts ................ 38 114 11.7 Translating between Pip Capable and non-Pip Capable DNS 115 Servers ........................................................... 39 117 12 Pip Address and ID Auto-configuration .......................... 41 118 12.1 Pip Address Prefix Administration ............................ 41 119 12.2 Host Autoconfiguration ....................................... 42 120 12.2.1 Host Initial Pip ID Creation ............................... 43 121 12.2.2 Host Pip Address Assignment ................................ 43 122 12.2.3 Pip ID and Domain Name Assignment .......................... 43 124 13 Pip Control Message Protocol (PCMP) ............................ 44 126 14 Host Mobility .................................................. 46 127 14.1 PCMP Mobile Host message ..................................... 48 128 14.2 Spoofing Pip IDs ............................................. 48 130 15 Public Data Network (PDN) Address Discovery .................... 49 131 15.1 Notes on Carrying PDN Addresses in NSAPs ..................... 50 133 16 Evolution with Pip ............................................. 51 134 16.1 Handling Directive (HD) and Routing Context (RC) Evolution 135 16.1.1 Options Evolution .......................................... 55 136 Introduction 138 Pip is an internet protocol intended as the replacement for IP ver- 139 sion 4. Pip is a general purpose internet protocol, designed to han- 140 dle all forseeable internet protocol requirements. This specifica- 141 tion describes the routing and addressing architecture for near-term 142 Pip deployment. We say near-term only because Pip is designed with 143 evolution in mind, so other architectures are expected in the future. 144 This document, however, makes no reference to such future architec- 145 tures (except in that it discusses Pip evolution in general). 147 This document gives an overall picture of how Pip operates. It is 148 provided primarily as a framework within which to understand the 149 total set of documents that comprise Pip. 151 1. Pip Architecture Overview 153 The Pip near-term architecture is an incremental step from IP. Like 154 IP, near-term Pip is datagram. Pip runs under TCP and UDP. DNS is 155 used in the same fashion it is now used to distribute name to Pip 156 Address (and ID) mappings. Routing in the near-term Pip architecture 157 is hop-by-hop, though it is possible for a host to create a domain- 158 level source route (for policy reasons). 160 Pip Addresses have more hierarchy than IP, thus improving scaling on 161 one hand, but introducing additional addressing complexities, such as 162 multiple addresses, on the other. Pip, however, uses hierarchical 163 addresses to advantage by making them provider-based, and using them 164 to make policy routing (in this case, provider selection) choices. 165 Pip also provides mechanisms for automatically assigning provider 166 prefixes to hosts and routers in domains. This is the main differ- 167 ence between the Pip near-term architecture and the IP architecture. 168 (Note that in the remainder of this paper, unless otherwise stated, 169 the phrase "Pip architecture" refers to the near-term Pip architec- 170 ture described herein.) 172 1.1. Pip Architecture Characteristics 174 The proposed architecture for near-term Pip has the following charac- 175 teristics: 177 1. Provider-rooted hierarchical addresses. 179 2. Automatic domain-wide address prefix assignment. 181 3. Automatic host address and ID assignment. 183 4. Exit provider selection. 185 5. Multiple defaults routing (default routing, but to multiple exit 186 points). 188 6. Equivalent of IP Class D style addressing for multicast. 190 7. CBT style multicast. 192 8. "Anycast" addressing (route to one of a group, usually the 193 nearest). 195 9. Providers support forwarding on policy routes (but initially 196 will not provide the support for sources to calculate policy 197 routes). 199 10. Mobile hosts. 201 11. Support for routing across large Public Data Networks (PDN). 203 12. Inter-operation with IP hosts (but, only within an IP-address 204 domain where IP addresses are unique). In particular, an IP 205 address can be explicitly carried in a Pip header. 207 13. Operation with existing transport and application binaries 208 (though if the application contains IP context, like FTP, it may 209 only work within a domain where IP addresses are unique). 211 14. Mechanisms for evolving Pip beyond the near-term architecture. 213 1.2. Components of the Pip Architecture 215 The Pip Architecture consists of the following five systems: 217 1. Host (source and sink of Pip packets) 218 2. Router (forwards Pip packets) 220 3. DNS 222 4. Pip/IP Translator 224 5. Pip Header Server (formats Pip headers) 226 The first three systems exist in the IP architecture, and require no 227 explanation here. The fourth system, the Pip/IP Translator, is 228 required solely for the purpose of inter-operating with current IP 229 systems. All Pip routers are also Pip/IP translators. 231 The fifth system, the Pip Header Server, is new. Its function is to 232 format Pip headers on behalf of the source host (though initially 233 hosts will be able to do this themselves). This use of the Pip 234 Header Server will increase as policy routing becomes more sophisti- 235 cated (moves beyond near-term Pip Architecture capabilities). 237 To handle future evolution, a Pip Header Server can be used to 238 "spoon-feed" Pip headers to old hosts that have not been updated to 239 understand new uses of Pip. This way, the probability that the 240 internet can evolve without changing all hosts is increased. 242 2. A Simple Example 244 A typical Pip "exchange" is as follows: An application initiates an 245 exchange with another host as identified by a domain name. A request 246 for one or more Pip Headers, containing the domain name of the desti- 247 nation host, goes to the Pip Header Server. The Pip Header Server 248 generates a DNS request, and receive back a Pip ID, multiple Pip 249 Addresses, and possibly other information such as a mobile host 250 server or a PDN address. Given this information, plus information 251 about the source host (its Pip Addresses, for instance), plus option- 252 ally policy information, plus optionally topology information, the 253 Pip Header Server formats an ordered list of valid Pip headers and 254 give these to the host. (Note that if the Pip Header Server is co- 255 resident with the host, as will be common initially, the host 256 behavior is similar to that of an IP host in that a DNS request comes 257 from the host, and the host forms a Pip header based on the answer 258 from DNS.) 260 The source host then begins to transmit Pip packets to the 261 destination host. If the destination host is an IP host, then the 262 Pip packet is translated into an IP packet along the way. Assuming 263 that the destination host is a Pip host, however, the destination 264 host uses the destination Pip ID alone to determine if the packet is 265 destined for it. The destination host generates a return Pip header 266 based either on information in the received Pip header, or the desti- 267 nation host uses the Pip ID of the source host to query the Pip 268 Header Server/DNS itself. The latter case involves more overhead, 269 but allows a more informed decision about how to return packets to 270 the originating host. 272 If either host is mobile, and moves to a new location, thus getting a 273 new Pip Address, it informs the other host of its new address 274 directly. Since host identification is based on the Pip ID and not 275 the Pip Address, this doesn't cause transport level to fail. If both 276 hosts are mobile and receive new Pip Addresses at the same time (and 277 thus cannot exchange packets at all), then they can query each 278 other's respective mobile host servers (learned from DNS). Note that 279 keeping track of host mobility is completely confined to hosts. 280 Routers never get involved in tracking mobile hosts (though naturally 281 they are involved in host discovery and automatic host address 282 assignment). 284 3. Pip Overview 286 Here, a brief overview of the Pip protocol is given. The reader is 287 encouraged to read [2] for a complete description. 289 The Pip header is divided into three parts: 291 Initial Part 292 Transit Part 293 Options Part 295 The Initial Part contains the following fields: 297 Version Number 298 Options Offset, OP Contents, Options Present (OP) 299 Packet SubID 300 Protocol 301 Dest ID 302 Source ID 303 Payload Length 304 Host Version 305 Payload Offset 306 Hop Count 308 All of the fields in the Initial Part are of fixed length. The Ini- 309 tial Part is 8 32-bit words in length. 311 The Version Number places Pip as a subsequent version of IP. The 312 Options Offset, OP Contents, and Options Present (OP) fields tell how 313 to process the options. The Options Offset tells where the options 314 are The OP tells which of up to 8 options are in the options part, so 315 that the Pip system can efficiently ignore options that don't pertain 316 to it. The OP Contents is like a version number for the OP field. 317 It allows for different sets of the (up to 8) options. 319 The Packet SubID is used to relate a received PCMP message to a pre- 320 viously sent Pip packet. This is necessary because, since routers in 321 Pip can tag packets, the packet returned to a host in a PCMP message 322 may not be the same as the packet sent. The Payload Length and Pro- 323 tocol take the place of IP's Total Length and Protocol fields respec- 324 tively. The Dest ID identifies the destination host, and is not used 325 for routing, except for where the final router on a LAN uses ARP to 326 find the physical address of the host identified by the dest ID. The 327 Source ID identifies the source of the packet. The Host Version 328 tells what control algorithms the host has implemented, so that 329 routers can respond to hosts appropriately. This is an evolution 330 mechanism. The Hop Count is similar to IP's Time-to-Live. 332 The Transit Part contains the following fields: 334 Transit Part Offset 335 HD Contents 336 Handling Directive (HD) 337 Active FTIF 338 RC Contents 339 Routing Context (RC) 340 FTIF Chain (FTIF = Forwarding Table Index Field) 342 Except for the FTIF Chain, which can have a variable number of 16-bit 343 FTIF fields, the fields in the Transit Part are of fixed length, and 344 are three 32-bit words in length. 346 The Transit Part Offset gives the length of the Transit Part. This 347 is used to determine the location of the subsequent Transit Part (in 348 the case of Transit Part encapsulation). 350 The Handling Directive (HD) is a set of subfields, each of which 351 indicates a specific handling action that must be executed on the 352 packet. Handling directives have no influence on routing. The HD 353 Contents field indicates what subfields are in the Handling Direc- 354 tive. This allows the definition of the set of handling directives 355 to evolve over time. Example handling directives are queueing prior- 356 ity, congestion experienced bit, drop priority, and so on. 358 The remaining fields comprise the Routing Directive. This is where 359 the routing decision gets made. The basic algorithm is that the 360 router uses the Routing Context to choose one of multiple forwarding 361 tables. The Active FTIF indicates which of the FTIFs to retrieve, 362 which is then used as an index into the forwarding table, which 363 either instructs the router to look at the next FTIF, or returns the 364 forwarding information. 366 Examples of Routing Context uses are; to distinguish address families 367 (multicast vs. unicast), to indicate which level of the hierarchy a 368 packet is being routed at, and to indicate a Type of Service. In the 369 near-term architecture, the FTIF Chain is used to carry source and 370 destination hierarchical unicast addresses, policy route fragments, 371 multicast addresses (all-of-group), and anycast (one-of-group) 372 addresses. Like the OP Contents and HD Contents fields, the RC Con- 373 tents field indicates what subfields are in the Routing Context. 374 This allows the definition of the Routing Context to evolve over 375 time. 377 The Options Part contains the options. The options are preceded by 378 an array of 8 fields that gives the offset of each of up to 8 379 options. Thus, a particular option can be found without a serial 380 search of the list of options. 382 4. Pip Addressing 384 Addressing is the core of any internet architecture. Pip Addresses 385 are carried in the Routing Directive (RD) of the Pip header (except 386 for the Pip ID, which in certain circumstances functions as part of 387 the Pip Address). Pip Addresses are used only for routing packets. 388 They do not identify the source and destination of a Pip packet. The 389 Pip ID does this. Here we describe and justify the Pip Addressing 390 types. 392 There are four Pip Address types [11]. The hierarchical Pip Address 393 (referred to simply as the Pip Address) is used for scalable unicast 394 and for the unicast part of a CBT-style multicast and anycast. The 395 multicast part of a CBT-style multicast is the second Pip address 396 type. The third Pip address type is class-D style multicast. The 397 fourth type of Pip address is the so-called "anycast" address. This 398 address causes the packet to be forwarded to one of a class of desti- 399 nations (such as, to the nearest DNS server). 401 Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is, 402 for the near-term Pip architecture) indicate which of four address 403 families the FTIFs and Dest ID apply to. The values are: 405 Value Address Family 406 ----- -------------- 407 00 Hierarchical Unicast Pip Address 408 01 Class D Style Multicast Address 409 10 CBT Style Multicast Address 410 11 Anycast Pip Address 412 The remaining bits are defined differently for different address fam- 413 ilies, and are defined in the following sections. 415 4.1. Hierarchical Pip Addressing 417 The primary purpose of a hierarchical address is to allow better 418 scaling of routing information, though Pip also uses the "path" 419 information latent in hierarchical addresses for making provider 420 selection (policy routing) decisions. 422 The Pip Header encodes addresses as a series of separate numbers, one 423 number for each level of hierarchy. This can be contrasted to tradi- 424 tional packet encodings of addresses, which places the entire address 425 into one field. Because of Pip's encoding, it is not necessary to 426 specify a format for a Pip Address as it is with traditional 427 addresses (for instance, the SIP address is formatted such that the 428 first so-many bits are the country/metro code, the next so-many bits 429 are the site/subscriber, and so on). Pip's encoding also eliminates 430 the "cornering in" effect of running out of space in one part of the 431 hierarchy even though there is plenty of room in another. No "field 432 sizing" decisions need be made at all with Pip Addresses. This makes 433 address assignment easier and more flexible than with traditional 434 addresses. 436 Pip Addresses are carried in DNS as a series of numbers, usually with 437 each number representing a layer of the hierarchy [1], but optionally 438 with the initial number(s) representing a "route fragment" (the tail 439 end of a policy route--a source route whose elements are providers). 440 The route fragments would be used, for instance, when the destination 441 network's directly attached (local access) provider is only giving 442 access to other (long distance) providers, but the important 443 provider-selection policy decision has to do the long distance pro- 444 viders. 446 The RC for (hierarchical) Pip Addresses is defined as: 448 bits meaning 449 ---- ------- 450 0,1 Pip Address (= 00) 451 2,3 level 452 4,5 metalevel 453 6 exit routing type 455 The level and metalevel subfields are used to indicate what level of 456 the hierarchy the packet is currently at (see section 8). The exit 457 routing type subfield is used to indicate whether host-driven (hosts 458 decide exit provider) or router-driven (routers decide exit provider) 459 exit routing is in effect (see section 8.1). 461 Each FTIF in the FTIF Chain is 16 bits in length. The low-order part 462 of each FTIF in a (hierarchical unicast) Pip Address indicates the 463 relationship of the FTIF with the next FTIF. The three relators are 464 Vertical, Horizontal, and Extension. The Vertical and Horizontal 465 relators indicate if the subsequent FTIF is hierarchically above or 466 below (Vertical) or hierarchically unrelated (Horizontal). The 467 Extension relator is used to encode FTIF values longer than 16 bits. 469 FTIF values 0 - 31 are reserved for special purposes. That is, they 470 cannot be assigned to normal hierarchical elements. FTIF value 1 is 471 defined as a flag to indicate a switch from the unicast phase of 472 packet forwarding to the anycast phase of packet forwarding. 474 Note that Pip Addresses do not need to be seen by protocol layers 475 above Pip (though layers above Pip can provide a Pip Address if 476 desired). Transport and above use the Pip ID to identify the source 477 and destination of a Pip packet. The Pip layer is able to map the 478 Pip IDs (and other information received from the layer above, such as 479 QOS) into Pip Addresses. 481 The Pip ID can serve as the lowest level of a Pip Address. While 482 this "bends the principal" of separating Pip Addressing from Pip 483 Identification, it greatly simplifies dynamic host address assign- 484 ment. The Pip ID also serves as a multicast ID. Unless otherwise 485 stated, the term "Pip Address" refers to just the part in the Routing 486 Directive (that is, excludes the Pip ID). 488 Pip Addresses are provider-rooted (as opposed to geographical). That 489 is, the top-level of a Pip Address indicates a network service pro- 490 vider (even when the service provided is not Pip). (A justification 491 of using provider-rooted rather than geographical addresses is given 492 in [12].) 494 Thus, the basic form of a Pip address is: 496 providerPart,subscriberPart 498 where both the providerPart and subscriberPart can have multiple 499 layers of hierarchy internally. 501 A subscriber may be attached to multiple providers. In this case, a 502 host can end up with multiple Pip Addresses by virtue of having mul- 503 tiple providerParts: 505 providerPart1,subscriberPart 506 providerPart2,subscriberPart 507 providerPart3,subscriberPart 509 This applies to the case where the subscriber network spans many dif- 510 ferent provider areas, for instance, a global corporate network. In 511 this case, some hosts in the global corporate network will have cer- 512 tain providerParts, and other hosts will have others. The subscri- 513 berPart should be assigned such that routing can successfully take 514 place without a providerPart in the destination Pip Address of the 515 Pip Routing Directive (see section 8.2). 517 Note that, while there are three providerParts shown, there is only 518 one subscriberPart. Internal subscriber numbering should be indepen- 519 dent of the providerPart. Indeed, with the Pip architecture, it is 520 possible to address internal packets without including any of the 521 providerPart of the address. 523 Top-level Pip numbers can be assigned to subscriber networks as well 524 as to providers. 526 privatePart,subscriberPart 528 In this case, however, the top-level number (privatePart) would not 529 be advertised globally. The purpose of such an assignment is to give 530 a private network "ownership" of a globally unique Pip Address space. 531 Note that the privatePart is assigned as an extended FTIF (that is, 532 from numbers greater than 2^15). Because the privatePart is not 533 advertised globally, and because internal packets do not need the 534 prefix (above the subscriberPart), the privatePart actually never 535 appears in a Pip packet header. 537 Pip Addresses can be prepended with a route fragment. That is, one 538 or more Pip numbers that are all at the top of the hierarchy. 540 longDistanceProvider.localAccessProvider.subscriber 541 (top-level) (top-level) (next level) 543 This is useful, for instance, when the subscriber's directly attached 544 provider is a "local access" provider, and is not advertised glo- 545 bally. In this case, the "long distance" provider is prepended to 546 the address even though the local access provider number is enough to 547 provide global uniqueness. 549 Note that no coordination is required between the long distance and 550 local access providers to form this address. The subscriber with a 551 prefix assigned to it by the local access provider can autonomously 552 form and use this address. It is only necessary that the long dis- 553 tance provider know how to route to the local access provider. 555 4.1.1. Assignment of (Hierarchical) Pip Addresses 557 Administratively, Pip Addresses are assigned as follows [3]. There 558 is a root Pip Address assignment authority. Likely choices for this 559 are IANA or ISOC. The root authority assigns top-level Pip Address 560 numbers. (A "Pip Address number" is the number at a single level of 561 the Pip Address hierarchy. A Pip Address prefix is a series of con- 562 tiguous Pip Address numbers, starting at the top level but not 563 including the entire Pip Address. Thus, the top-level prefix is the 564 same thing as the top-level number.) 566 Though by-and-large, and most importantly, top-level assignments are 567 made to providers, each country is given an assignment, each existing 568 address space (such as E.164, X.121, IP, etc.) is given an 569 assignment, and private networks can be given assignments. Thus, 570 existing addresses can be grandfathered in. Even if the top-level 571 Pip address number is an administrative rather than topological 572 assignment, the routing algorithm still advertises providers at the 573 top (provider) level of routing. That is, routing will advertise 574 enough levels of hierarchy that providers know how to route to each 575 other. 577 There must be some means of validating top-level number requests from 578 providers (basically, those numbers less than 2^15). That is, top- 579 level assignments must be made only to true providers. While design- 580 ing the best way to do this is outside the scope of this document, it 581 seems off hand that a reasonable approach is to charge for the top- 582 level prefixes. The charge should be enough to discourage non- 583 serious requests for prefixes, but not so much that it becomes an 584 inhibitor to entry in the market. The charge might include a yearly 585 "rent", and top-level prefixes could be reclaimed when they are no 586 longer used by the provider. Any profit made from this activity 587 could be used to support the overall role of number assignment. 588 Since roughly 32,000 top-level assignments can be made before having 589 to increase the FTIF size in the Pip header from 16 bits to 32 bits, 590 it is envisioned that top-level prefixes will not be viewed as a 591 scarce resource. 593 After a provider obtains a top-level prefix, it becomes an assignment 594 authority with respect to that particular prefix. The provider has 595 complete control over assignments at the next level down (the level 596 below the top-level). The provider may either assign top-level minus 597 one prefixes to subscribers, or preferably use that level to provide 598 hierarchy within the provider's network (for instance, in the case 599 where the provider has so many subscribers that keeping routing 600 information on all of them creates a scaling problem). It is 601 envisioned that the subscriber will have complete control over number 602 assignments made at levels below that of the prefix assigned it by 603 the provider. 605 Assigning top level prefixes directly to providers leaves the number 606 of top-level assignments open-ended, resulting in the possibility of 607 scaling problems at the top level. While it is expected that the 608 number of providers will remain relatively small (say less than 10000 609 globally), this can't be guaranteed. If there are more providers 610 than top-level routing can handle, it is likely that many of these 611 providers will be "local access" providers--providers whose role is 612 to give a subscriber access to multiple "long-distance" providers. 613 In this case, the local access providers need not appear at the top 614 level of routing, thus mitigating the scaling problem at that level. 616 In the worst case, if there are too many top-level "long-distance" 617 providers for top-level routing to handle, a layer of hierarchy above 618 the top-level can be created. This layer should probably conform to 619 some policy criteria (as opposed to a geographical criteria). For 620 instance, backbones with similar access restrictions or type-of- 621 service can be hierarchically clustered. Clustering according to 622 policy criteria rather than geographical allows the choice of address 623 to remain an effective policy routing mechanism. Of course, adding a 624 layer of hierarchy to the top requires that all systems, over time, 625 obtain a new providerPart prefix. Since Pip has automatic prefix 626 assignment, and since DNS hides addresses from users, this is not a 627 debilitating problem. 629 4.1.2. Host Addressing 631 Hosts can have multiple Pip Addresses. Since Pip Addresses are topo- 632 logically significant, a host has multiple Pip Addresses because it 633 exists in multiple places topologically. For instance, a host can 634 have multiple Pip addresses because it can be reached via multiple 635 providers, or because it has multiple physical interfaces. The 636 address used to reach the host influences the path to the host. 638 Locally, Pip Addressing is similar to IP Addressing. That is, Pip 639 prefixes are assigned to subnetworks (where the term subnetwork here 640 is meant in the OSI sense. That is, it denotes a network operating 641 at a lower layer than the Pip layer, for instance, a LAN). Thus, it 642 is not necessary to advertise individual hosts in routing updates-- 643 routers only need to advertise and store routes to subnetworks. 645 Unlike IP, however, a single subnetwork can have multiple prefixes. 646 (Strictly speaking, in IP a single subnetwork can have multiple pre- 647 fixes, but a host may not be able to recognize that it can reach 648 another host on the same subnetwork but with a different prefix 649 without going through a router.) 651 There are two styles of local Pip Addressing--one where the Pip 652 Address denotes the host, and another where the Pip Address denotes 653 only the destination subnetwork. The latter style is called ID- 654 tailed Pip Addressing. With ID-tailed Pip Addresses, the Pip ID is 655 used by the last router to forward the packet to the host. It is 656 expected that ID-tailed Pip Addressing is the most common, because it 657 greatly eases address administration. 659 (Note that the Pip Routing Directive can be used to route a Pip 660 packet internal to a host. For instance, the RD can be used to 661 direct a packet to a device in a host, or even a certain memory loca- 662 tion. The use of the RD for this purpose is not part of this near- 663 term Pip architecture. We note, however, that this use of the RD 664 could be locally done without effecting any other Pip systems.) 666 When a router receives a Pip packet and determines that the packet is 667 destined for a host on one of its' attached subnetworks (by examining 668 the appropriate FTIF), it then examines the destination Pip ID (which 669 is in a fixed position) and forwards based on that. If it does not 670 know the subnetwork address of the host, then it ARPs, using the Pip 671 ID as the "address" in the ARP query. 673 4.2. CBT Style Multicast Addresses 675 When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10, 676 the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast. 677 The remainder of the bits are defined as follows: 679 bits meaning 680 ---- ------- 681 0,1 CBT Multicast (= 10) 682 2,3 level 683 4,5 metalevel 684 6 exit routing type 685 7 on-tree bit 686 8,9 scoping 688 With CBT (Core-based Tree) multicast, there is a single multicast 689 tree connecting the members (recipients) of the multicast group (as 690 opposed to Class-D style multicast, where there is a tree per 691 source). The tree emanates from a single "core" router. To transmit 692 to the group, a packet is routed to the core using unicast routing. 693 Once the packet reaches a router on the tree, it is multicast using a 694 group ID. 696 Thus, the FTIF Chain for CBT multicast contains the (Unicast) 697 Hierarchical Pip Address of the core router. The Dest ID field con- 698 tains the group ID. 700 A Pip CBT packet, then, has two phases of forwarding, a unicast phase 701 and a multicast phase. The "on-tree" bit of the RC indicates which 702 phase the packet is in. While in the unicast phase, the on-tree bit 703 is set to 0, and the packet is forwarded similarly to Pip Addresses. 704 During this phase, the scoping bits are ignored. 706 Once the packet reaches the multicast tree, it switches to multicast 707 routing by changing the on-tree bit to 1 and using the Dest ID group 708 address for forwarding. During this phase, bits 2-6 are ignored. 710 4.3. Class D Style Multicast Addresses 712 When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01, 713 the FTIF and Dest ID indicate Class D style multicast. The remainder 714 of the RC is defined as: 716 bits meaning 717 ---- ------- 718 0,1 Class D Style Multicast (= 01) 719 2-5 Scoping 721 By "class D" style multicast, we mean multicast using the algorithms 722 developed for use with Class D addresses in IP (class D addresses are 723 not used per se). This style of routing uses both source and desti- 724 nation information to route the packet (source host address and des- 725 tination multicast group). 727 For Pip, the FTIF Chain holds the source Pip Address, in order of 728 most significant hierarchy level first. The reason for putting the 729 source Pip Address rather than the Source ID in the FTIF Chain is 730 that use of the source Pip Address allows the multicast routing to 731 take advantage of the hierarchical source address, as is being done 732 with IP. The Dest ID field holds the multicast group. The Routing 733 Context indicates Class-D style multicast. All routers must first 734 look at the FTIF Chain and Dest ID field to route the packet on the 735 tree. 737 Bits 2 through 5 of the RC are the scoping bits. 739 4.4. Anycast Addressing 741 When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11, 742 the FTIF and Dest ID indicate Anycast addressing. The remainder of 743 the RC is defined as: 745 bits meaning 746 ---- ------- 747 0,1 Anycast Address (= 11) 748 2,3 level 749 4,5 metalevel 750 6 exit routing type 751 7 anycast active 752 8,9 scoping 754 With anycast routing, the packet is unicast, but to the nearest of a 755 group of destinations. This type of routing is used by Pip for auto- 756 configuration. Other applications, such as discovery protocols, may 757 also use anycast routing. 759 Like CBT, Pip anycast has two phases of operation, in this case the 760 unicast phase and the anycast phase. The unicast phase is for the 761 purpose of getting the packet into a certain vicinity. The anycast 762 phase is to forward the packet to the nearest of a group of destina- 763 tions in that vicinity. 765 Thus, the RC has both unicast and anycast information in it. During 766 the unicast phase, the anycast active bit is set to 0, and the packet 767 is forwarded according to the rules of Pip Addressing. The scoping 768 bits are ignored. 770 The switch from the unicast phase to the anycast phase is triggered 771 by the presence of an FTIF of value 1 in the FTIF Chain. When this 772 FTIF is reached, the anycast active bit is set to 1, the scoping bits 773 take effect, and bits 2 through 6 are ignored. When in the anycast 774 phase, forwarding is based on the Dest ID field..sp 2 776 5. Pip IDs 778 The Pip ID is 64-bits in length [4]. 780 The basic role of the Pip ID is to identify the source and destina- 781 tion host of a Pip Packet. (The other role of the Pip ID is for 782 allowing a router to find the destination host on the destination 783 subnetwork.) 784 This having been said, it is possible for the Pip ID to ultimately 785 identify something in addition to the host. For instance, the Pip ID 786 could identify a user or a process. For this to work, however, the 787 Pip ID has to be bound to the host, so that as far as the Pip layer 788 is concerned, the ID is that of the host. Any additional use of the 789 Pip ID is outside the scope of this Pip architecture. 791 The Pip ID is treated as flat. When a host receives a Pip packet, it 792 compares the destination Pip ID in the Pip header with its' own. If 793 there is a complete match, then the packet has reached the correct 794 destination, and is sent to the higher layer protocol. If there is 795 not a complete match, then the packet is discarded, and a PCMP 796 Invalid Address packet is returned to the originator of the packet 797 [7]. 799 It is something of an open issue as to whether or not Pip IDs should 800 contain significant organizational hierarchy information. Such 801 information could be used for inverse DNS lookups and allowing a Pip 802 packet to be associated with an organization. (Note that the use of 803 the Pip ID alone for this purpose can be easily spoofed. By cross 804 checking the Pip ID with the Pip Address prefix, spoofing is harder- 805 -as hard as it is with IP--but still easy. Section 14.2 discusses 806 methods for making spoofing harder still, without requiring encryp- 807 tion.) 809 However, relying on organizational information in the Pip header gen- 810 erally complicates ID assignment. This complication has several ram- 811 ifications. It makes host autoconfiguration of hosts harder, because 812 hosts then have to obtain an assignment from some database somewhere 813 (versus creating one locally from an IEEE 802 address, for instance). 814 It means that a host has to get a new assignment if it changes organ- 815 izations. It is not clear what the ramifications of this might be in 816 the case of a mobile host moving through different organizations. 818 Because of these difficulties, the use of flat Pip IDs is currently 819 favored. 821 Blocks of Pip ID numbers have been reserved for existing numbering 822 spaces, such as IP, IEEE 802, and E.164. Pip ID numbers have been 823 assigned for such special purposes such as "any host", "any router", 824 "all hosts on a subnetwork", "all routers on a subnetwork", and so 825 on. Finally, 32-bit blocks of Pip ID numbers have been reserved for 826 each country, according to ISO 3166 country code assignments. 828 6. Use of DNS 830 The Pip near-term architecture uses DNS in roughly the same style 831 that it is currently used. In particular, the Pip architecture main- 832 tains the two fundamental DNS characteristics of 1) information 833 stored in DNS does not change often, and 2) the information returned 834 by DNS is independent of who requested it. 836 While the fundamental use of DNS remains roughly the same, Pip's use 837 of DNS differs from IP's use by degrees. First, Pip relies on DNS to 838 hold more types of information than IP [1]. Second, Pip Addresses in 839 DNS are expected to change more often than IP addresses, due to reas- 840 signment of Pip Address prefixes (the providerPart). To still allow 841 aggressive caching of DNS records in the face of more quickly chang- 842 ing addressing, Pip has a mechanism of indicating to hosts when an 843 address is no longer assigned. This triggers an authoritative query, 844 which overrides DNS caches. The mechanism consists of PCMP Packet 845 Not Delivered messages that indicate explicitly that the Pip Address 846 is invalid. 848 In what follows, we first discuss the information contained in DNS, 849 and then discuss authoritative queries. 851 6.1. Information Held by DNS 853 The information contained in DNS for the Pip architecture is: 855 1. The Pip ID. 857 2. Multiple Pip Addresses 859 3. The destination's mobile host address servers. 861 4. The Public Data Network (PDN) addresses through which the desti- 862 nation can be reached. 864 5. The Pip/IP Translators through which the destination (if the 865 destination is IP-only) can be reached. 867 6. Information about the providers represented by the destination's 868 Pip addresses. This information includes provider name, the 869 type of provider network (such as SMDS, ATM, or SIP), and access 870 restrictions on the provider's network. 872 The Pip ID and Addresses are the basic units of information required 873 for carriage of a Pip packet. 875 The mobile host address server tells where to send queries for the 876 current address of a mobile Pip host. Note that usually the current 877 address of the mobile host is conveyed by the mobile host itself, 878 thus a mobile host server query is not usually required. 880 The PDN address is used by the entry router of a PDN to learn the PDN 881 address of the next hop router. The entry router obtains the PDN 882 address via an option in the Pip packet. If there are multiple PDNs 883 associated with a given Pip Address, then there can be multiple PDN 884 addresses carried in the option. Note that the option is not sent on 885 every packet, and that only the PDN entry router need examine the 886 option. 888 The Pip/IP translator information is used to know how to translate an 889 IP address into a Pip Address so that the packet can be carried 890 across the Pip infrastructure. If the originating host is IP, then 891 the first IP/Pip translator reached by the IP packet must query DNS 892 for this information. 894 The information about the destination's providers is used to help the 895 "source" (either the source host or a Pip Header Server near the 896 source host) format an appropriate Pip header with regards to choos- 897 ing a Pip Address [14]. The choice of one of multiple Pip Addresses 898 is essentially a policy routing choice. 900 More detailed descriptions of the use of the information carried in 901 DNS is contained in the relevant sections. 903 6.2. Authoritative Queries in DNS 905 In general, Pip treats addresses as more dynamic entities than does 906 IP. One example of this is how Pip Address prefixes change when a 907 subscriber network attaches to a new provider. Pip also carries more 908 information in DNS, any of which can change for various reasons. 909 Thus, the information in DNS is more dynamic with Pip than with IP. 911 Because of the increased reliance on DNS, there is a danger of 912 increasing the load on DNS. This would be particularly true if the 913 means of increasing DNS' dynamicity is by shortening the cache hold- 914 ing time by decreasing the DNS Time-to-Live (TTL). To counteract 915 this trend, Pip provides explicit network layer (Pip layer) feedback 916 on the correctness of address information. This allows Pip hosts to 917 selectively over-ride cached DNS information by making an authorita- 918 tive query. Through this mechanism, we actually hope to increase the 919 cache holding time of DNS, thus improving DNS' scaling characteris- 920 tics overall. 922 The network layer feedback is in the form of a type of PCMP Packet 923 Not Delivered (PDN) message that indicates that the address used is 924 known to be out-of-date. Routers can be configured with this infor- 925 mation, or it can be provided through the routing algorithm (when an 926 address is decommissioned, the routing algorithm can indicate that 927 this is the reason that it has become unreachable, as opposed to 928 becoming "temporarily" unreachable through equipment failure). 930 Pip hosts consider destination addresses to be in one of four states: 932 1. Unknown, but assumed to be valid. 934 2. Reachable (and therefore valid). 936 3. Unreachable and known to be invalid. 938 4. Unreachable, but weakly assumed to be valid. 940 The first state exists before a host has attempted communication with 941 another host. In this state, the host queries DNS as normal (that 942 is, does not make an authoritative query). 944 The second state is reached when a host has successfully communicated 945 with another host. Once a host has reached this state, it can stay 946 in it for an arbitrarily long time, including after the DNS TTL has 947 expired. When in this state, there is no need to query DNS. 949 A host enters the third state after a failed attempt at communicating 950 with another host where the PCMP PND message indicates explicitly 951 that the address is known to be invalid. In this case, the host 952 makes an authoritative query to DNS whether or not the TTL has 953 expired. It is this case that allows lengthy caching of DNS informa- 954 tion while still allowing addresses to be reassigned frequently. 956 A host enters the fourth state after a failed attempt at communicat- 957 ing with another host, but where the address is not explicitly known 958 to be invalid. In this state, the host weakly assumes that the 959 address of the destination is still valid, and so can requery DNS 960 with a normal (non-authoritative) query. 962 7. Type-of-Service (TOS) (or lack thereof) 964 One year ago it probably would have been adequate to define a handful 965 (4 or 5) of priority levels to drive a simple priority FIFO queue. 966 With the advent of real-time services over the Internet, however, 967 this is no longer sufficient. Real-time traffic cannot be handled on 968 the same footing as non-real-time. In particular, real-time traffic 969 must be subject to access control so that excess real-time traffic 970 does not swamp a link (to the detriment of other real-time and non- 971 real-time traffic alike). 973 Given that a consensus solution to real- and non-real-time traffic 974 management in the internet does not exist, this version of the Pip 975 near-term architecture does not specify any classes of service (and 976 related queueing mechanisms). It is expected that Pip will define 977 classes of service (primarily for use in the Handling Directive) as 978 solutions become available. 980 8. Routing on (Hierarchical) Pip Addresses 982 Pip forwarding in a single router is done based on one or a small 983 number of FTIFs. What this means with respect to hierarchical Pip 984 Addresses is that a Pip router is able to forward a packet based on 985 examining only part of the Pip Address--often a single level. 987 One advantage to encoding each level of the Pip Address separately is 988 that it makes handling of addresses, for instance address assignment 989 or managing multiple addresses, easier. Another advantage is address 990 lookup speed--the entire address does not have to be examined to for- 991 ward a packet (as is necessary, for instance, with traditional 992 hierarchical address encoding). The cost of this, however, is addi- 993 tional complexity in keeping track of the active hierarchical level 994 in the Pip header. 996 Since Pip Addresses allow reuse of numbers at each level of the 997 hierarchy, it is necessary for a Pip router to know which level of 998 the hierarchy it is acting at when it retrieves an FTIF. This is 999 done in part with a hierarchy level indicator in the Routing Context 1000 (RC) field. RC level is numbered from the top of the hierarchy down. 1002 Therefore, the top of the hierarchy is RC level = 0, the next level 1003 down is RC level = 1, and so on. 1005 The RC level alone, however, is not adequate to keep track of the 1006 appropriate level in all cases. This is because different parts of 1007 the hierarchy may have different numbers of levels, and elements of 1008 the hierarchy (such as a domain or an area) may exist in multiple 1009 parts of the hierarchy. Thus, a hierarchy element can be, say, level 1010 3 under one of its parents and level 2 under another. 1012 To resolve this ambiguity, the topological hierarchy is superimposed 1013 with another set of levels--metalevels [11]. A metalevel boundary 1014 exists wherever a hierarchy element has multiple parents with dif- 1015 ferent numbers of levels, or may with reasonable probability have 1016 multiple parents with different numbers of levels in the future. 1018 Thus, a metalevel boundary exists between a subscriber network and 1019 its provider. (Note that in general the metalevel represents a sig- 1020 nificant administrative boundary between two levels of the topologi- 1021 cal hierarchy. It is because of this administrative boundary that 1022 the child is likely to have multiple parents.) Lower metalevels may 1023 exist, but usually will not. 1025 The RC, then, contains a level and a metalevel indicator. The level 1026 indicates the number of levels from the top of the next higher 1027 metalevel. The top of the global hierarchy is metalevel 0, level 0. 1028 The next level down (for instance, the level that provides a level of 1029 hierarchy within a provider) is metalevel 0, level 1. The first 1030 level of hierarchy under a provider is metalevel 1, level 0, and so 1031 on. 1033 To determine the RC level and RC metalevel in a transmitted Pip 1034 packet, a host (or Pip Header Server) must know where the metalevels 1035 are in its own Pip Addresses. 1037 The host compares its source Pip Address with the destination Pip 1038 Address. The highest Pip Address component that is different between 1039 the two addresses determines the level and metalevel. (No levels 1040 higher than this level need be encoded in the Routing Directive.) 1042 Neighbor routers are configured to know if there is a level or 1043 metalevel boundary between them, so that they can modify the RC level 1044 and RC metalevel in a transmitted packet appropriately. 1046 8.1. Exiting a Private Domain 1048 The near-term Pip Architecture provides two methods of exit routing, 1049 that is, routing inter-domain Pip packets from a source host to a 1050 network service provider of a private domain [12,15]. In the first 1051 method, called transit-driven exit routing, the source host leaves 1052 the choice of provider to the routers. In the second method, called 1053 host-driven exit routing, the source host explicitly chooses the pro- 1054 vider. In either method, it is possible to prevent internal routers 1055 from having to carry external routing information. The exit routing 1056 bit of the RC indicates which type of exit routing is in effect. 1058 With host-driven exit routing, it is possible for the host to choose 1059 a provider through which the destination cannot be reached. In this 1060 case, the host receives the appropriate PCMP Packet Not Delivered 1061 message, and may either fallback on transit-driven exit routing or 1062 choose a different provider. 1064 When using transit-driven exit routing, there are two modes of opera- 1065 tion. The first, called destination-oriented, is used when the 1066 routers internal to a domain have external routing information, and 1067 the host has only one provider prefix. The second, called provider- 1068 oriented, is used when the routers internal to a domain do not have 1069 any external routing information or when the host has multiple pro- 1070 vider prefixes. (With IP, this case is called default routing. In 1071 the case of IP, however, default routing does not allow an intelli- 1072 gent choice of multiple exit points.) 1074 With provider-oriented exit routing, the host arbitrarily chooses a 1075 source Pip Address (and therefore, a provider). (Note that if the 1076 Pip Header Server is tracking inter-domain routing, then it chooses 1077 the appropriate provider.) If the host chooses the wrong provider, 1078 then the border router will redirect the host to the correct provider 1079 with a PCMP Provider Redirect message. 1081 8.2. Intra-domain Networking 1083 With intra-domain networking (where both source and destination are 1084 in the private network), there are two scenarios of concern. In the 1085 first, the destination address shares a providerPart with the source 1086 address, and so the destination is known to be intra-domain even 1087 before a packet is sent. In the second, the destination address does 1088 not share a providerPart with the source address, and so the source 1089 host doesn't know that the destination is reachable intra-domain. 1090 Note that the first case is the most common, because the private 1091 top-level number assignment acts as the common prefix even though it 1092 isn't advertised globally (see section 4.1). 1094 In the first case, the Pip Addresses in the Routing Directive need 1095 not contain the providerPart. Rather, it contains only the address 1096 part below the metalevel boundary. (A Pip Address in an FTIF Chain 1097 always starts at a metalevel boundary). 1099 For instance, if the source Pip Address is 1.2.3,4.5.6 and the desti- 1100 nation Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be included 1101 for the destination address in the Routing Directive. (The comma "," 1102 in the address indicates the metalevel boundary between providerPart 1103 and subscriberPart.) The metalevel and level are set accordingly. 1105 In the second case, it is desirable to use the Pip Header Server to 1106 determine if the destination is intra-domain or inter-domain. The 1107 Pip Header Server can do this by monitoring intra-domain routing. 1108 (This is done by having the Pip Header Server run the intra-domain 1109 routing algorithm, but not advertise any destinations.) Thus, the Pip 1110 Header Server can determine if the providerPart can be eliminated 1111 from the address, as described in the last paragraph, or cannot and 1112 must conform to the rules of exit routing as described in the previ- 1113 ous section. 1115 If the Pip Header Server does not monitor intra-domain routing, how- 1116 ever, then the following actions occur. In the case of host-driven 1117 exit routing, the packet will be routed to the stated provider, and 1118 an external path will be used to reach an internal destination. (The 1119 moral here is to not use host-driven exit routing unless the Pip 1120 Header Server is privy to routing information, both internal and 1121 external.) 1123 In the case of transit-driven exit routing, the packet sent by the 1124 host will eventually reach a router that knows that the destination 1125 is intra-domain. This router will forward the packet towards the 1126 destination, and at the same time send a PCMP Reformat Transit Part 1127 message to the host. This message tells the host how much of the Pip 1128 Address is needed to route the packet. 1130 9. Pip Header Server 1132 Two new components of the Pip Architecture are the Pip/IP Translator 1133 and the Pip Header Server. The Pip/IP Translator is only used for 1134 transition from IP to Pip, and otherwise would not be necessary. The 1135 Pip Header Server, however, is a new architectural component. 1137 The purpose of the Pip Header Server is to form a Pip Header. It is 1138 useful to form the Pip header in a separate box because 1) in the 1139 future (as policy routing matures, for instance), significant amounts 1140 of information may be needed to form the Pip header--too much infor- 1141 mation to distribute to all hosts, and 2) it won't be possible to 1142 evolve all hosts at the same time, so the existence of a separate box 1143 that can spoon-feed Pip headers to old hosts is necessary. (It is 1144 impossible to guarantee that no modification of Pip hosts is neces- 1145 sary for any potential evolution, but being able to form the header 1146 in a server, and hand it to an outdated host, is a large step in the 1147 right direction.) 1149 (Note that policy routing architectures commonly if not universally 1150 require the use of some kind of "route server" for calculating policy 1151 routes. The Pip Header Server is, among other things, just this 1152 server. Thus, the Pip Header Server does not so much result from the 1153 fact that Pip itself is more complex than IP or other "IPv7" propo- 1154 sals. Rather, the Pip Header Server reflects the fact that the Pip 1155 Architecture has more functionality than ROAD architectures supported 1156 by the simpler proposals.) 1158 We note that for the near-term architecture hosts themselves will 1159 by-and-large have the capability of forming Pip headers. The excep- 1160 tion to this will be the case where the Pip Header Server wishes to 1161 monitor inter-domain routing to enhance provider selection. Thus, 1162 the Pip Header Server role will be largely limited to evolution (see 1163 section 16). 1165 9.1. Forming Pip Headers 1167 Forming a Pip header is more complex than forming an IP header 1168 because there are many more choices to make. At a minimum, one of 1169 multiple Pip Addresses (both source and destination) must be chosen 1170 [14]. In the near future, it will also be necessary to choose a TOS. 1172 After DNS information about the destination has been received, the 1173 the following information is available to the Pip header formation 1174 function. 1176 1. From DNS: The destination's providers (either directly connected 1177 or nearby enough to justify making a policy decision about), and 1178 the names, types, and access restrictions of those providers. 1180 2. From the source host: The application type (and thus, the 1181 desired service), and the user access restriction classes. 1183 3. From local configuration: The source's providers, and the names, 1184 types, and access restrictions of those providers. 1186 4. Optionally from inter-domain routing: The routes chosen by 1187 inter-domain to all top level providers. (Note that inter- 1188 domain routing in the Pip near-term architecture is path-vector. 1189 Because of this, the Pip Header Server does not obtain enough 1190 information from inter-domain routing to form a policy route. 1191 When the technology to do this matures, it can be installed into 1192 Pip Header Servers.) 1194 The inter-domain routing information is optional. If it is 1195 used, then probably a Pip Header Server is necessary, to limit 1196 this information to a small number of systems. 1198 There may also be arbitrary policy information available to the Pip 1199 header formation function. This architecture does not specify any 1200 such information. 1202 The Pip header formation function then goes through a process of 1203 forming an ordered list of source/destination Pip Addresses to use. 1204 The ordering is based on knowledge of the application service 1205 requirements, the service provided by the source providers, guesses 1206 or learned information about the service provided by the destination 1207 providers or by source/destination provider pairs, and the cost of 1208 using source providers to reach destination providers. It is assumed 1209 that the sophistication of forming the ordered list will grow as 1210 experienced is gained with internet commercialization and real-time 1211 services. 1213 The Pip Header formation function then returns the ordered pairs of 1214 source and destination addresses to the source host in the PHP 1215 response message, along with an indication of what kind of exit rout- 1216 ing to use with each pair. Any additional information, such as PDN 1217 Address, is also returned. With this information, the source host 1218 can now establish communications and properly respond to PCMP mes- 1219 sages. Based on information received from PCMP messages, particu- 1220 larly PCMP Packet Not Delivered messages but also Mobile Host mes- 1221 sages, the host is able to choose appropriately from the ordered 1222 list. 1224 Note that if Pip evolves to the point where the Transit Part of the 1225 Pip header is no longer compatible with the current Transit Part, and 1226 the querying host has not been updated to understand the new Transit 1227 Part, then the PHP response message contains a bit map of the Transit 1228 Part. The host puts this bit map into the Transit Part of the 1229 transmitted Pip header even though it does not understand the seman- 1230 tics of the Transit Part. The Host Version field indicates to the 1231 Pip Header Server what kinds of transit parts the host can under- 1232 stand. 1234 9.2. Pip Header Protocol (PHP) 1236 The Pip Header Protocol (PHP) is a simple query/response protocol 1237 used to exchange information between the Pip host and the Pip Header 1238 Server [6]. In the query, the Pip host includes (among other things) 1239 the domain name of the destination it wishes to send Pip packets to. 1240 (Thus, the PHP query serves as a substitute for the DNS query.) 1242 The PHP query also contains 1) User Access Restriction Classes, 2) 1243 Application Types, and 3) host version. The host version tells the 1244 Pip Header Server what features are installed in the host. Thus, the 1245 Pip Header Server is able to determine if the host can format its own 1246 Pip header based on DNS information, or whether the Pip Header Server 1247 needs to do it on behalf of the host. In the future, the PHP query 1248 will also contain desired TOS (possibly in lieu of Application Type). 1249 (Note that this information could come from the application. Thus, 1250 the application interface to PHP (the equivalent of gethostbyname()) 1251 must pass this information.) 1253 9.3. Application Interface 1255 In order for a Pip host to generate the information required in the 1256 PHP query, there must be a way for the application to convey the 1257 information to the PHP software. The host architecture for doing 1258 this is as follows. 1260 A local "Pip Header Client" (the source host analog to the Pip Header 1261 Server) is called by the application (instead of the current gethost- 1262 byname()). The application provides the Pip Header Client with 1263 either the destination host domain name or the destination host Pip 1264 ID, and other pertinent information such as user access restriction 1265 class and TOS. The Pip Header Client, if it doesn't have the infor- 1266 mation cached locally, queries the Pip Header Server and receives an 1267 answer. (Remember that the Pip Header Server can be co-resident with 1268 the host.) 1270 Once the Pip Header Client has determined what the Pip header(s) are, 1271 it assigns a local handle to the headers, returns the handle to the 1272 application, and configures the Pip packet processing engine with the 1273 handle and related Pip Headers. The application then issues packets 1274 to the Pip layer (via intervening layers such as transport) using the 1275 local handle. 1277 10. Routing Algorithms in Pip 1279 This section discusses the routing algorithm for use with (hierarchi- 1280 cal) Pip Addresses. 1282 The architecture for operating routing algorithms in Pip reflects the 1283 clean partitioning of routing contexts in the Pip header. Thus, 1284 routing in the Pip architecture is nicely modularized. 1286 Within the Hierarchical Pip Address, there are multiple hierarchical 1287 levels. Wherever two routers connect, or two levels interface 1288 (either in a single router or between routers), two decisions must be 1289 made: 1) what information should be exchanged (that is, what of one 1290 side's routing table should be propagated to the other side), and 2) 1291 what routing algorithm should be used to exchange the information? 1292 The first decision is discussed in section 10.1 below (Routing Infor- 1293 mation Filtering). The latter decision is discussed here. 1295 Conceptually, and to a large extent in practice, the routing algo- 1296 rithms at each level are cleanly partitioned. This partition is much 1297 like the partition between "egp" and "igp" level routing in IP, but 1298 with Pip it exists at each level of the hierarchy. 1300 At the top-level of the Pip Address hierarchy, a path-vector routing 1301 algorithm is used. Path-vector is more appropriate at the top level 1302 than link-state because path-vector does not require agreement 1303 between top-level entities (providers) on metrics in order to be 1304 loop-free. (Agreement between the providers is likely to result in 1305 better paths, but the Pip Architecture does not assume such agree- 1306 ment.) 1308 The top-level path-vector routing algorithm is based on IDRP, but 1309 enhanced to handle Pip addresses and Pip idiosyncrasies such as the 1310 Routing Context. At any level below the top level, it is a local 1311 decision as to what routing algorithm technology to run. However, 1312 the path-vector routing algorithm is generalized so that it can run 1313 at multiple levels of the Pip Address hierarchy. Thus, a lower level 1314 domain can choose to take advantage of the path-vector algorithm, or 1315 run another, such as a link-state algorithm. The modified version of 1316 IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced 1317 "milpiv"). 1319 Normally, information is exchanged between two separate routing algo- 1320 rithms by virtue of the two algorithms co-existing in the same 1321 router. For instance, a border router is likely to participate in an 1322 exchange of routing information with provider routers, and still run 1323 the routing algorithm of the internal routers. If the two algorithms 1324 are different routing technologies (for instance, link-state versus 1325 distance-vector) then internal conversion translates information from 1326 one routing algorithm to the form of the other. 1328 In some cases, however, two routing algorithms that exchange informa- 1329 tion will exist in different routers, and will have to exchange 1330 information over a link. If these two algorithms are different tech- 1331 nologies, then they need a common means of exchanging routing infor- 1332 mation. While strictly speaking this is a local matter, MLPV can 1333 also serve as the interface between two disparate routing algorithms. 1334 Thus, all routers should be able to run MLPV, if for no other reason 1335 than to exchange information with other, perhaps proprietary, routing 1336 protocols. 1338 MLPV is designed to be extendible with regards to the type of routes 1339 that it calculates. It uses the Pip Object parameter identification 1340 number space to identify what type of route is being advertised and 1341 calculated [9]. Thus, to add new types of routes (for instance, new 1342 types of service), it is only necessary to configure the routers to 1343 accept the new route type, define metrics for that type, and criteria 1344 for preferring one route of that type over another. 1346 10.1. Routing Information Filtering 1348 Of course, the main point behind having hierarchical routing is so 1349 that information from one part of the hierarchy can be reduced when 1350 passed to another. In general, reduction (in the form of aggrega- 1351 tion) takes place when passing information from the bottom of the 1352 hierarchy up. However, Pip uses tunneling and exit routing to, if 1353 desired, allow information from the top to be reduced when it goes 1354 down. 1356 When two routers become neighbors, they can determine what hierarchi- 1357 cal levels they have in common by comparing Pip Addresses. For 1358 instance, if two neighbor routers have Pip Addresses 1.2.3,4 and 1359 1.2.8,9.14 respectively, then they share levels 0 and 1, and are dif- 1360 ferent at levels below that. (0 is the highest level, 1 is the next 1361 highest, and so on.) As a general rule, these two routers exchange 1362 level 0, level 1, and level 2 routing information, but not level 3 or 1363 lower routing information. In other words, both routers know how to 1364 route to all things at the top level (level 0), how to route to all 1365 level 1 things with "1" as the level 0 prefix, and how to route to 1366 all level 2 things with "1.2" as the level 1 prefix. 1368 In the absence of other instructions, two routers will by default 1369 exchange information about all levels from the top down to the first 1370 level at which they have differing Pip Addresses. In practice, how- 1371 ever, this default exchange is as likely to be followed as not. For 1372 instance, assume that 1.2.3,4 is a provider router, and 1.2.8,9.14 is 1373 a subscriber router. (Note that 1.2.8 is the prefix given the sub- 1374 scriber by the provider, thus the metalevel boundary indicated by the 1375 comma.) Assume also that the subscriber network is using 1376 destination-oriented transit-driven exit routing (see section 8.1). 1377 Finally, assume that router 1.2.8,9.14 is the subscriber's only entry 1378 point into provider 1 (other routers provide entry points to other 1379 providers). 1381 In this case, 1.2.8,9.14 does not need to know about level 2 or level 1382 1 areas in the provider (that is, it does not need to know about 1383 1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on). Thus, 1.2.8,9.14 1384 should be configured to inform 1.2.3,4 that it does not need level 1 1385 or 2 information. 1387 As another example, assume still that 1.2.3,4 is a provider and 1388 1.2.8,9.14 is a subscriber. However, assume now that the subscriber 1389 network is using host-driven exit routing. In this case, the sub- 1390 scriber does not even need to know about level 0 information, because 1391 all exit routing is directed to the provider of choice, and having 1392 level 0 information therefore does not influence that choice. 1394 11. Transition 1396 The transition scheme for Pip has two major components, 1) transla- 1397 tion, and 2) encapsulation. Translation is required to map the Pip 1398 Address into the IP address and vice versa. Encapsulation is used 1399 for one Pip router (or host) to exchange packets with another Pip 1400 router (or host) by tunneling through intermediate IP routers. 1402 The Pip transition scheme is basically a set of techniques that 1403 allows existing IP "stuff" and Pip to coexist, but within the limita- 1404 tions of IP address depletion (though not within the limitations of 1405 IP scaling problems). By this I mean that an IP-only host can only 1406 exchange packets with other hosts in a domain where IP numbers are 1407 unique. Initially this domain includes all IP hosts, but eventually 1408 will include only hosts within a private domain. The IP "stuff" that 1409 can exist includes 1) whole IP domains, 2) individual IP hosts, 3) 1410 IP-oriented TCPs, and 4) IP-oriented applications. 1412 11.1. Justification for Pip Transition Scheme 1414 Note that all transition to a bigger address require translation. It 1415 cannot be avoided. The major choices one must make when deciding on 1416 a translation scheme are: 1418 1. Will we require a contiguous infrastructure consisting of the 1419 new protocol, or will we allow tunneling through whatever 1420 remains of the existing IP infrastructure at any point in time? 1422 2. Will we allow global connectivity between IP machines after IP 1423 addresses are no longer globally unique, or not? (In other 1424 words, will we use a NAT scheme or not? [15]) 1426 Concerning question number 1; while it is desirable to move as 1427 quickly as possible to a contiguous Pip (or SIP or whatever) infras- 1428 tructure, especially for purposes of improved scaling, it is fantasy 1429 to think that the whole infrastructure will cut over to Pip quickly. 1430 Furthermore, during the testing stages of Pip, it is highly desirable 1431 to be able to install Pip in any box anywhere, and by tunneling 1432 through IP, create a virtual Pip internet. Thus, it seems that the 1433 only reasonable answer to question number 1 is to allow tunneling. 1435 Concerning question number 2; it is highly desirable to avoid using a 1436 NAT scheme. A NAT (Network Address Translation) scheme is one 1437 whereby any two IP hosts can communicate, even though IP addresses 1438 are not globally unique. This is done by dynamically mapping non- 1439 unique IP addresses into unique ones in order to cross the infras- 1440 tructure. NAT schemes have the problems of increased complexity to 1441 maintain the mappings, and of translating IP addresses that reside 1442 within application data structures (such as the PORT command in FTP). 1444 This having been said, it is conceivable that the new protocol will 1445 not be far enough along when IP addresses are no longer unique, and 1446 therefore a NAT scheme becomes necessary. It is possible to employ a 1447 NAT scheme at any time in the future without making it part of the 1448 intended transition scheme now. Thus, we can plan for a NATless 1449 transition now without preventing the potential use of NAT if it 1450 becomes necessary. 1452 11.2. Architecture for Pip Transition Scheme 1454 The architecture for Pip Transition is that of a Pip infrastructure 1455 surrounded by IP-only "systems". The IP-only "systems" surrounding 1456 Pip can be whole IP domains, individual IP hosts, an old TCP in an 1457 otherwise Pip host, or an old application running on top of a Pip- 1458 smart TCP. 1460 The Pip infrastructure will initially get its internal connectivity 1461 by tunneling through IP. Thus, any Pip box can be installed any- 1462 where, and become part of the Pip infrastructure by configuration 1463 over a "virtual" IP. Of course, it is desirable that Pip boxes be 1464 directly connected to other Pip boxes, but very early on this is the 1465 exception rather than the rule. 1467 Two neighbor Pip systems tunneling through IP simply view IP as a 1468 "link layer" protocol, and encapsulate Pip over IP just as they would 1469 encapsulate Pip over any other link layer protocol. In particular, 1470 the hop-count field of Pip is not copied into the Time-to-Live field 1471 of IP. There is no automatic configuration of neighbor Pip systems 1472 over IP. Manual configuration (and careful "virtual topology" 1473 engineering) is required. Note that ICMP messages from a IP router 1474 in a tunnel is not translated into a PCMP message and sent on. ICMP 1475 messages are sinked at the translating router at the head of the tun- 1476 nel. The information learned from such ICMP messages, however, may 1477 be used to determine unreachability of the other end of the tunnel, 1478 and may there result in PCMP message on later packets. 1480 In the remainder of this section, we do not distinguish between a 1481 virtual Pip infrastructure on IP, and a pure Pip infrastructure. 1483 Given the model of a Pip infrastructure surrounded by IP, there are 5 1484 possible packet paths: 1486 1. IP - IP 1488 2. IP - Pip - IP 1490 3. IP - Pip 1492 4. Pip - IP 1494 5. Pip - Pip 1496 The first three paths involve packets that originate at IP-only 1497 hosts. In order for an IP host to talk to any other host (IP or 1498 not), the other host must be addressable within the context of the IP 1499 host's 32-bit IP address. Initially, this "IP-unique" domain will 1500 include all IP hosts. When IP addresses become no longer unique, the 1501 IP-unique domain will include a subset of all hosts. At a minimum, 1502 this subset will include those hosts in the IP-host's private domain. 1503 However, it makes sense also to arrange for the set of all "public" 1504 hosts, basically anonymous ftp servers and mail gateways, to be in 1505 this subset. In other words, a portion of IP address space should be 1506 set aside to remain globally unique, even though other parts of the 1507 address space are being reused. 1509 11.3. Translation between Pip and IP packets 1511 Paths 2 and 4 involve translation from Pip to IP. This translation 1512 is straightforward, as all the information needed to create the IP 1513 addresses is in the Pip header. In particular, Pip IDs have an 1514 encoding that allows them to contain an IP address (again, one that 1515 is unique within an IP-unique domain). Whenever a packet path 1516 involves an IP host on either end, both hosts must have IP addresses. 1517 Thus, translating from Pip to IP is just a matter of extracting the 1518 IP addresses from the Pip IDs and forming an IP header. 1520 Translating from an IP header to a Pip header is more difficult, 1521 because the 32-bit IP address must be "translated" into a 64-bit Pip 1522 ID and a Pip Address. There is no algorithm for making this transla- 1523 tion. A table mapping IP addresses (or, rather, network numbers) to 1524 Pip IDs and Pip Addresses is required. Since such a table must 1525 potentially map every IP address, we choose to use dynamic discovery 1526 and caching to maintain the table. We choose also to use DNS as the 1527 means of discovering the mappings. 1529 Thus, DNS contains records that map IP address to Pip ID and Pip 1530 Address. In the case where the host represented by the DNS record is 1531 a Pip host (packet path 3), the Pip ID and Pip Address are those of 1532 the host. In the case where the host represented by the DNS record 1533 is an IP-only host (packet paths 2 and 4), the Pip Address is that of 1534 the Pip/IP translating gateway that is used to reach the IP host. 1535 Thus, an IP-only domain must at least be able to return Pip informa- 1536 tion in its DNS records (or, the parent DNS domain must be able to do 1537 it on behalf of the child). 1539 With paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating 1540 gateway (IP to Pip) makes the DNS query. It stores the IP packet 1541 while waiting for the answer. The query is an inverse address (in- 1542 addr) using the destination IP address. The translating gateway can 1543 cache the record for an arbitrarily long period, because if the map- 1544 ping ever becomes invalid, a PCMP Invalid Address message flushes the 1545 cache entry. 1547 In the case of path 4 (Pip-IP), however, the Pip Address of the 1548 translating gateway is returned directly to the source host-- 1549 piggybacked on the DNS record that is normally returned. Thus this 1550 scheme incurs only a small incremental cost over the normal DNS 1551 query. 1553 11.4. Translating between PCMP and ICMP 1555 The only ICMP/PCMP messages that are translated are the Destination 1556 Unreachable, Echo, and PTMU Exceeded messages. The portion of the 1557 offending IP/Pip header that is attached to the ICMP/PCMP message is 1558 not translated. 1560 11.5. Translating between IP and Pip Routing Information 1562 It is not necessary to pass IP routing information into the Pip 1563 infrastructure. The mapping of IP address to Pip Address in DNS 1564 allows Pip to find the appropriate gateway to IP in the context of 1565 Pip addresses only. 1567 It is impossible to pass Pip routing information into IP routers, 1568 since IP routers cannot understand Pip addresses. IP domains must 1569 therefore use default routing to reach IP/Pip translators. 1571 11.6. Old TCP and Application Binaries in Pip Hosts 1573 A Pip host can be expected to have an old TCP above it for a long 1574 time to come, and a new (Pip-smart) TCP can be expected to have old 1575 application binaries running over it for a long time to come. Thus, 1576 we must have some way of insuring that the TCP checksum is correctly 1577 calculated in the event that one or both ends is running Pip, and one 1578 or both ends has an old TCP binary. In addition, we must arrange to 1579 allow applications to interface with TCP using a 32-bit "address" 1580 only, even though those 32 bits get locally translated into Pip 1581 Addresses and IDs. 1583 As stated above, in all cases where a Pip host is talking to an IP- 1584 only host, the Pip host has a 32-bit IP address. This address is 1585 embedded in the Pip ID such that it can be identified as an IP 1586 address from inspection of the Pip ID alone. 1588 The TCP pseudo-header is calculated using the Payload Length and Pro- 1589 tocol fields, and some or all of the Source and Dest Pip IDs. In the 1590 case where both Source and Dest Pip IDs are IP-based, only the 32-bit 1591 IP address is included in the pseudo-header checksum calculation. 1592 Otherwise, the full 64 bits are used. (Note that using the full Pay- 1593 load Length and Protocol fields does not fail when old TCP binaries 1594 are being used, because the values for those fields must be within 1595 the 16-bit and 8-bit limits for TCP to correctly operate.) 1597 The reason for only using 32 bits of the Pip ID in the case of both 1598 ends using an IP address is that an old TCP will use only 32 bits of 1599 some number to form the pseudo-header. If the entire 64 bits of the 1600 Pip ID were used, then there would be cases where no 32-bit number 1601 could be used to insure that the correct checksum is calculated in 1602 all cases. 1604 Note that in the case of an old TCP on top of Pip, "Pip" (actually, a 1605 Pip daemon) must create a 32-bit number that can both be used to 1) 1606 allow the Pip layer to correctly associate a packet from the TCP 1607 layer with the right Pip header, and 2) cause the TCP layer to calcu- 1608 late the right checksum. (This number is created when the applica- 1609 tion initiates a DNS query. A Pip daemon intervenes in this request, 1610 calculates a 32 bit number that the application/TCP can use, and 1611 informs the Pip layer of the mapping between this 32 bit number and 1612 the full Pip header.) 1614 When the destination host is an IP only host, then this 32-bit number 1615 is nothing more than the IP address. When the destination host is a 1616 Pip host, then this 32-bit number is some number generated by Pip to 1617 "fool" the old TCP into generating the right checksum. This 32-bit 1618 number can normally be the same as the lower 32 bits of the Pip ID. 1619 However, it is possible that two or more active TCP connections is 1620 established to different hosts whose Pip IDs have the same lower 32 1621 bits. In this case, the Pip layer must generate a different 32-bit 1622 number for each connection, but in such a way that the sum of the two 1623 16-bit components of the 32-bit numbers are the same as the sum of 1624 the two 16-bit components of the lower 32 bits of the Pip IDs. 1626 In the case where an old Application wants to open a socket using an 1627 IP address handed to it (by the user or hard-coded), and not using a 1628 domain name, then it must be assumed that this IP address is valid 1629 within the IP-unique domain. To form a Pip ID out of this 32-bit 1630 number, the host appends the high-order 24 bits of its own Pip ID, 1631 plus the IP-address-identifier-byte value, to the 32-bit IP address. 1633 11.7. Translating between Pip Capable and non-Pip Capable DNS Servers 1635 In addition to transitioning "Pip-layer" packets, it is necessary to 1636 transition DNS from non-Pip capable to Pip capable. During transi- 1637 tion there will be name servers in DNS that only understand IP 1638 queries and those that understand both Pip and IP queries. This 1639 means there must be a mechanism for Pip resolvers to detect whether a 1640 name server is Pip capable, and vice versa. Also, a name server, if 1641 it provides recursive service, must be able to translate Pip requests 1642 to IP requests. (Pip-capable means a name server understands Pip and 1643 existing IP queries. It does not necessarily mean the name server 1644 uses the Pip protocol to communicate.) 1646 New resource records have been defined to hold Pip identifiers and 1647 addresses, and other information [1]. These resource records must be 1648 queried using a new opcode in the DNS query packet header. Existing 1649 resource records can be queried using both the old and new header 1650 formats. Name servers that are not Pip-capable will respond with a 1651 format error to queries with the new opcode. Thus, a resolver can 1652 determine dynamically whether a name server is Pip-capable, by send- 1653 ing it a Pip query and noting the response. This only need be done 1654 once, when querying a server for the "first" time, and the outcome 1655 can be cached along with the name server's address. 1657 Using a new opcode for making Pip queries also helps name servers 1658 determine whether a resolver is Pip-capable (it is not always not 1659 obvious from the type of query made since many queries are common to 1660 to IP and Pip). Determining whether a resolver is Pip-capable is 1661 necessary when responding with address information that is not expli- 1662 citly requested by the query. An important example of this is when a 1663 name server makes a referral to another name server in a response: if 1664 the request comes from a Pip resolver, name server addresses will be 1665 returned as Pip identifier/address resource records, otherwise the 1666 addresses will be returned as IP A resource records. 1668 Those servers that are Pip-capable and provide recursive service must 1669 translate Pip requests to IP requests when querying an IP name 1670 server. For most queries, this will just mean modifying the opcode 1671 value in the query header to reflect an IP query, rather than a Pip 1672 query. (Most queries are identical in IP and Pip.) Other queries, 1673 notably the query for Pip identifier/address information, must be 1674 translated into its IP counterpart, namely, an IP A query. On 1675 receipt of an answer from an IP name server, a Pip name server must 1676 translate the query header and question section back to its original, 1677 and format the answer appropriately. Again, for most queries, this 1678 will be a trivial operation, but responses containing IP addresses, 1679 either as a result of an explicit query or as additional information, 1680 must be formatted to appear as a valid Pip response. 1682 Pip-capable name servers that provide recursive name service should 1683 also translate IP address requests into Pip identifier/address 1684 requests when querying a Pip-capable name server. (A host's IP 1685 address can be deduced from the host's Pip identifier.) This enables 1686 a Pip-capable name server to cache all relevant addressing informa- 1687 tion about a Pip host in the first address query concerning the host. 1688 Caching partial information is undesirable since the name server, 1689 using the current DNS caching strategy, would return only the cached 1690 information on a future Pip request, and IP, rather than Pip, would 1691 be used to communicate with the destination host. 1693 12. Pip Address and ID Auto-configuration 1695 One goal of Pip is to make networks as easy to administer as possi- 1696 ble, especially with regards to hosts. Certain aspects of the Pip 1697 architecture make administration easier. For instance, the ID field 1698 provides a network layer "anchor" around which address changes can be 1699 administered. 1701 This section discusses three aspects of autoconfiguration; 1) 1702 domain-wide Pip Address prefix assignment, 2) host Pip Address 1703 assignment, and 3) host Pip ID assignment. 1705 12.1. Pip Address Prefix Administration 1707 A central premise behind the use of provider-rooted hierarchical 1708 addresses is that domain-wide address prefix assignment and re- 1709 assignment is straight-forward. This section describes that process. 1711 Pip Address prefix administration limits required manual prefix con- 1712 figuration to DNS and border routers. This is the minimum required 1713 manual configuration possible, because both border routers and DNS 1714 must be configured with prefix information for other reasons. DNS 1715 must be configured with prefix information so that it can reply to 1716 address queries. DNS files are structured so that the prefix is 1717 administered in only one place (that is, every host record does not 1718 have to be changed to create a new prefix). Border routers must be 1719 configured with prefix information in order to advertise exit routes 1720 internally. 1722 Note in particular that no internal (non-border) routers or hosts 1723 need ever be manually configured with any externally derived address- 1724 ing information. All internal routers that are expected to fall 1725 under a common provider-prefix must, however, be configured with a 1726 "group ID" taken from the Pip ID space. (This group ID is not a mul- 1727 ticast ID per se. Rather, it is an identifier that allows prefix 1728 updates to be targetted to a specific set of routers.) 1730 Each border router is configured with the following information. 1732 1. The type of exit routing for the domain. This tells the border 1733 router whether or not it needs to advertise external routes 1734 internally. 1736 2. The address prefix of the providers that the border is directly 1737 connected to. This prefix information includes any metalevel 1738 boundaries above the subscriber/provider metalevel boundary 1739 (called simply the subscriber metalevel). 1741 3. Other information about the provider (provider name, type, user 1742 access restriction classes). 1744 4. A list of common-provider-prefix group IDs that should receive 1745 the auto-configuration information. (The default is that only 1746 systems that share a group ID with the border router will 1747 receive the information.) 1749 This information is injected into the intra-domain routing algorithm. 1750 It is automatically spread to all routers indicated by the group ID 1751 list. This way, the default behavior is for the information to be 1752 automatically constrained to the border router's "area". 1754 When a non-border router receives this information, it 1) records the 1755 route to the providers in its forwarding table, and 2) advertises the 1756 information to hosts in the router discovery protocol [8]. Thus 1757 hosts learn not only their complete address, but also information on 1758 how to do exit routing and on how to choose source addresses. 1760 12.2. Host Autoconfiguration 1762 There are three phases of host autoconfiguration: 1764 1. The host locally creates a flat unique Pip ID (probably globally 1765 unique but at least unique on the attached subnet). 1767 2. The host learns its Pip Addresses. 1769 3. The host optionally obtains a hierarchical, organizationally 1770 meaningful Pip ID and a domain name from a Pip ID/domain name 1771 assignment service. This service updates DNS. 1773 Item three is optional. If Pip ID and domain name assignment ser- 1774 vices are not installed, then the host must obtain its domain name 1775 and, if necessary, Pip ID, from static configuration. Each of the 1776 three phases are described below. 1778 12.2.1. Host Initial Pip ID Creation 1780 When a host boots, it can form an ID based only on local information. 1781 If the host has an IEEE 802 number, either from an IEEE 802 interface 1782 or from an internal identifier, then it can create a globally unique 1783 Pip ID from the IEEE 802 Pip ID type [4]. Otherwise, the host can 1784 create an ID from the IEEE 802 space using its subnet (link layer) 1785 address. This latter ID is only guaranteed to be locally unique. 1787 12.2.2. Host Pip Address Assignment 1789 Unless a host does not wish to use ID-tailed Pip Addresses (see sec- 1790 tion 4.1.2), host Pip Address assignment is trivial. (The near-term 1791 Pip Architecture doesn't specify a means for a host to obtain a non- 1792 ID-tailed Pip Address.) When a host attaches to a subnet, it learns 1793 the Pip Address of the attached routers through router discovery. 1795 The host simply adopts these Pip Addresses as its own. The Pip 1796 Address gets a packet to the host's subnet, and the host's Pip ID is 1797 used to route across the subnet. When the routers advertise new 1798 addresses (for instance, because of a new provider), the host adopts 1799 the new addresses. 1801 12.2.3. Pip ID and Domain Name Assignment 1803 Once the host has obtained its Pip Addresses and an at-least- 1804 locally-unique Pip ID, it can exchange packets with an ID/Domain Name 1805 (ID/DN) assignment service. If the host locally created a globally 1806 unique Pip ID (using an IEEE 802 number), and the organization it 1807 belongs to does not use organizationally structured Pip IDs (which 1808 should normally be the case) then it only needs to obtain a domain 1809 name. The ID/DN assignment service is reachable at a well-known any- 1810 cast address [4]. Thus, the host is able to start exchanging packets 1811 with the ID/DN assignment service without any additional configura- 1812 tion. 1814 If there is no ID/DN assignment service available, then the host must 1815 obtain it's organizational ID or DNS name in a non-automatic way. If 1816 the ID/DN assignment service is down, the host must temporarily suf- 1817 fice with just a Pip ID and Address. The host can periodically try 1818 to reach the ID/DN assignment service. 1820 The ID/DN assignment service must coordinate with DNS. When the 1821 ID/DN assignment service creates a new ID or domain name to assign to 1822 a new host, it must know which IDs and domain names are available for 1823 assignment. It must also update DNS with the new information. 1825 The design of this service is left for further study. 1827 13. Pip Control Message Protocol (PCMP) 1829 The Pip analog to ICMP is PCMP [7]. The near-term Pip architecture 1830 defines the following PCMP messages: 1832 1. Local Redirect 1834 2. Packet Not Delivered 1836 3. Echo 1838 4. Parameter Problem 1840 5. Router Discovery 1842 6. PMTU Exceeded 1844 7. Provider Redirect 1846 8. Reformat Transit Part 1848 9. Unknown Parameter 1850 10. Host Mobility 1852 11. Exit PDN Address 1854 The Local Redirect, Echo, and Parameter Problem PCMP messages operate 1855 almost identically to their ICMP counterparts. 1857 The Packet Not Delivered PCMP message serves the role of ICMP's Des- 1858 tination Unreachable. The Packet Not Delivered, has two major 1859 differences. First, it is more general in that it indicates the 1860 hierarchy level of unreachability (rather than explicit host, subnet, 1861 network unreachability as with IP). Second, it indicates when an 1862 address is known to be invalid, thus allowing for more intelligent 1863 use of DNS (see section 6.2). 1865 The Router Discovery PCMP message operates as ICMP's, with the excep- 1866 tion that a host derives its Pip Address from it. 1868 The PMTU Exceeded message operates as ICMP's, with the exception that 1869 the Pip header size of the offending Packet is also given. This 1870 allows the source host transport to determine how much smaller the 1871 packet PMTU should be from the advertised subnet PMTU. Note that if 1872 an occasional option, such as the PDN Address option, needs to be 1873 attached to one of many packets, and that this option makes the 1874 packet larger than the PMTU, then it is not necessary to modify the 1875 MTU coming from transport. Instead, that packet can be fragmented by 1876 the host's Pip forwarding engine. (Pip specifies 1877 fragmentation/reassembly for hosts but not for routers. The fragmen- 1878 tation information is in a Pip Option.) 1880 The Provider Redirect, Invalid Address, Reformat Transit Part, Unk- 1881 nown Parameter, Host Mobility, and Exit PDN Address PCMP messages are 1882 new. 1884 The Provider Redirect PCMP message is used to inform the source host 1885 of a preferable exit provider to use when provider-rooted, transit- 1886 driven exit routing is used (see section 8.1). 1888 The Invalid Address PCMP message is used to inform the source host 1889 that none of the IDs of the destination host match that of the Pip 1890 packet. The purpose of this message is to allow for authoritative 1891 DNS requests (see section 6.2). 1893 The Reformat Transit Part PCMP message has both near-term Pip archi- 1894 tecture functions and evolution functions. Near-term, the Reformat 1895 Transit Part PCMP message is used to indicate to the source whether 1896 it has too few or too many layers of address in the Routing Directive 1897 (see section 8.2). Long-term, the Reformat Transit Part PCMP message 1898 is able to arbitrarily modify the transit part transmitted by the 1899 host, as encoded by a bit string. 1901 The Unknown Parameter PCMP message is used to inform the source host 1902 that the router does not understand a parameter in either the Han- 1903 dling Directive, the Routing Context, or the Transit Options. The 1904 purpose of this message is to assist evolution (see section 16.1). 1906 The Host Mobility PCMP message is sent by a host to inform another 1907 host (for instance, the host's Mobile Address Server) that it has a 1908 new address (see section 14). The main use of this packet is for 1909 host mobility, though it can be used to manage any address changes, 1910 such as because of a new prefix assignment. 1912 The Exit PDN Address PCMP message is used to manage the function 1913 whereby the source host informs the PDN entry router of the PDN 1914 Address of the exit PDN system (see section 15). 1916 When a router needs to send a PCMP message, it sends it to the source 1917 Pip Address. If the Pip header is in a tunnel, then the PCMP message 1918 is sent to the router that is the source of the tunnel. Depending on 1919 the situation, this may result in another PCMP message from the 1920 source of the tunnel to the true source (for instance, if the source 1921 of the tunnel finds that the dest of the tunnel can't be reached, it 1922 may send a Packet Not Delivered to the source host). 1924 14. Host Mobility 1926 Depending on how security conscience a host is, and what security 1927 mechanisms a host has available, mobility can come from Pip "for 1928 free". If a host is willing to accept a packet by just looking at 1929 source and destination Pip ID, and if the host simply records the 1930 source Pip Address on any packet it receives as the appropriate 1931 return address to the source Pip ID, then mobility comes automati- 1932 cally. 1934 That is, when a mobile host gets a new Pip Address, it simply puts 1935 that address into the next packet it sends. When the other host 1936 receives it, it records the new Pip Address, and starts sending 1937 return packets to that address. The security aspect of this is that 1938 this type of operation leads to an easy way to spoof the (internet 1939 level) identity of a host. That is, absent any other security 1940 mechanisms, any host can write any Pip ID into a packet. (Cross- 1941 checking a source Pip ID against the source Pip Address at least 1942 makes spoofing of this sort as hard as with IP. This is discussed 1943 below.) 1945 The above simple host mobility mechanism does not work in the case 1946 where source and destination hosts obtain new Pip Addresses at the 1947 same time and the old Pip addresses no longer work, because neither 1948 is able to send its new address information directly to the other. 1949 Furthermore, if a host wishes to be more secure about authenticating 1950 the source Pip ID of a packet, then the above mechanism also is not 1951 satisfactory. In what follows, the complete host mobility mechanism 1952 is described. 1954 Pip uses the Mobile Host Server and the PCMP Host Mobility message to 1955 manage host mobility; 1957 The Mobile Host Server is a non-mobile host (or router acting as a 1958 host) that keeps track of the active address of a mobile host. The 1959 Pip ID and Address of the Mobile Host Server is configured into the 1960 mobile host, and in DNS. When a host X obtains information from DNS 1961 about a host Y, the Pip ID and Address of host Y's Mobile Host Server 1962 is among the information. (Also among the information is host Y's 1963 "permanent" address, if host Y has one. If host Y is so mobile that 1964 it doesn't have a permanent address, then no permanent address is 1965 returned by DNS. In particular, note that DNS is not intended to 1966 keep track of a mobile host's active address.) 1968 Given the destination host's (Y) permanent ID and Address, and the 1969 Mobile Host Server's permanent IDs and Addresses, the source host (X) 1970 proceedes as follows. X tries to establish communications with Y 1971 using one of the permanent addresses. If this fails (or if at any 1972 time X cannot contact Y), X sends a PCMP Mobile Host message to the 1973 Mobile Host Server requesting the active address for Y. (Note that X 1974 can determine that it cannot contact Y from receipt of a PCMP Desti- 1975 nation Unreachable or a PCMP Invalid Address message.) 1977 The Mobile Host Server responds to X with the active Pip Addresses of 1978 Y. (Of course, Y must inform its Mobile Host Server(s) of its active 1979 Pip Addresses when it knows them. This also is done using the PCMP 1980 Mobile Host message. Y also informs any hosts that it is actively 1981 communicating with, using either a regular Pip packet or with a PCMP 1982 Mobile Host message. Thus, usually X does not need to contact the 1983 Mobile Host Server to track Y's active address.) 1985 If the address that X already tried is among those returned by Y, 1986 then the source host has the option of either 1) continuing to try 1987 the same Pip Address, 2) trying another of Y's Pip Addresses, 3) 1988 waiting and querying the Mobile Host Server again, or 4) giving up. 1990 If the Mobile Host Server indicates that Y has new active Pip 1991 Addresses, then X chooses among these in the same manner that it 1992 chooses among multiple permanent Pip Addresses, and tries to contact 1993 Y. 1995 14.1. PCMP Mobile Host message 1997 There are two types of PCMP Mobile Host messages, the query and the 1998 response. The query consists of the Pip ID of the host for which 1999 active Pip Address information is being requested. 2001 The response consists of a Pip ID, a sequence number, a set of Pip 2002 Addresses, and a signature field. The set of Pip Addresses includes 2003 all currently usable addresses of the host indicated by the Pip ID. 2004 Thus, the PCMP Mobile Host message can be used both to indicate a 2005 newly obtained address, and to indicate that a previous address is no 2006 longer active (by that addresses' absence in the set). 2008 The sequence number indicates which is the most recent information. 2009 It is needed to deal with the case where an older PCMP Mobile Host 2010 response is received after a newer one. 2012 The signature field is a value that derives from encrypting the 2013 sequence number and the set of Pip Addresses. For now, the encryp- 2014 tion algorithms used, how to obtain keys, and so on are for further 2015 study. 2017 14.2. Spoofing Pip IDs 2019 This section discusses host mechanisms for decreasing the probability 2020 of Pip ID spoofing. The mechanisms provided in this version of the 2021 near-term Pip architecture are no more secure than DNS itself. It is 2022 hoped that mechanisms and the corresponding infrastructure needed for 2023 better internetwork layer security can be installed with whatever new 2024 IP protocol is chosen. 2026 After a host makes a DNS query, it knows: 2028 1. The destination host's Pip ID, 2030 2. The destination host's permanent Pip Addresses, and 2032 3. The destination host's Mobile Host Server's Pip ID and 2033 Addresses. 2035 Note that the DNS query can be a normal one (based on domain name) or 2036 an inverse query (based on Pip ID or Pip Address, though the latter 2037 is more likely to succeed, since the Pip ID may be flat and therefore 2038 not suitable for an inverse lookup). The inverse query is done when 2039 the host did not initiate the packet exchange, and therefore doesn't 2040 know the domain name of the remote (initiating) host. 2042 If the destination host is not mobile, then the source host can check 2043 the source Pip Address, compare it with those received from DNS, and 2044 reject the packet if it does not match. This gives spoof protection 2045 equal to that of IP. 2047 If the destination host is mobile and obtains new Pip Addresses, then 2048 the source host can check the validity of the new Pip Address by 2049 sending a PCMP Mobile Host query to the Mobile Host Server learned 2050 from DNS. The set of Pip Addresses learned from the Mobile Address 2051 Server is then used for subsequent validation. 2053 15. Public Data Network (PDN) Address Discovery 2055 One of the problems with running Pip (or any internet protocol) over 2056 a PDN is that of the PDN entry Pip System discovering the PDN Address 2057 of the appropriate PDN exit Pip System. This problem is solved using 2058 ARP in small, broadcast LANs because the broadcast mechanism is rela- 2059 tively cheap. This solution is not available in the PDN case, where 2060 the number of attached systems is very large, and where broadcast is 2061 not available (or is not cheap if it is). 2063 For the case where the domain of the destination host is attached to 2064 a PDN, the problem is nicely solved by distributing the domain's exit 2065 PDN Address information in DNS, and then having the source host con- 2066 vey the exit PDN Address to the PDN entry router in a Pip option. 2068 The DNS of the destination host's domain contains the PDN Addresses 2069 for the domain. When DNS returns a record for the destination host, 2070 the record associates zero or more PDN Addresses with each Pip 2071 Address. There can be more than one PDN address associated with a 2072 given PDN, and there can be more than on PDN associated with a given 2073 Pip Address. This latter case occurs when more than one hierarchical 2074 component of the Pip Address each represents a separate PDN. It is 2075 expected that in almost all cases, there will be only one (or none) 2076 PDN associated with any Pip address. 2078 (Note that, while the returned DNS record associates the PDN 2079 Addresses with a single Pip Address, in general the PDN Address will 2080 apply to a set of Pip Addresses--those for all hosts in the domain. 2082 The DNS files are structured to reflect this grouping in the same way 2083 that a single Pip Address prefix in DNS applies to many hosts. There- 2084 fore, every individual host entry in the DNS files does not need to 2085 have separate PDN Addresses typed in with it. This simplifies confi- 2086 guration of DNS.) 2088 When the source host sends the first packet to a given destination 2089 host, it attaches the PDN Addresses, one per PDN, to the packet in an 2090 option. (Note that, because of the way that options are processed in 2091 Pip packets, no router other than the entry PDN router need look at 2092 the option.) When the entry router receives this packet, it deter- 2093 mines that it is the entry router based on the result of the FTIF 2094 Chain lookup. 2096 It retrieves the PDN Address from the option, and caches it locally. 2097 The cache entry can later by retrieved using either the destination 2098 Pip ID or the destination Pip Address as the cache index. 2100 The entry router sends the source host a PCMP Exit PDN Address mes- 2101 sage indicating that it has cached the information. If there are 2102 multiple exit PDN Addresses, then the source host can at this time 2103 inform the entry PDN router of all the PDN addresses. The entry PDN 2104 router can either choose from these to setup a connection, or cache 2105 them to recover from the case where the existing connection breaks. 2107 Finally, the entry PDN router delivers the Pip packet (perhaps by 2108 setting up a connection) to the PDN Address indicated. 2110 When a PDN entry router receives a Pip packet for which it doesn't 2111 know the exit PDN address (and has no other means of determining it, 2112 such as shortcut routing), it sends a PCMP Exit PDN Address query 2113 message to the originating host. This can happen if, for instance, 2114 routing changes and directs the packets to a new PDN entry router. 2115 When the source host receives the PCMP Exit PDN Address query mes- 2116 sage, it transmits the PDN Addresses to the entry PDN router. 2118 15.1. Notes on Carrying PDN Addresses in NSAPs 2120 The Pip use of PDN Address carriage in the option or PCMP Exit PDN 2121 Address message solves two significant problems associated with the 2122 analogous use of PDN Address-based NSAPs. 2124 First, there is no existing agreement (standards or otherwise) that 2125 the existence of of a PDN Address in an NSAP address implies that the 2126 identified host is reachable behind the PDN Address. Thus, upon 2127 receiving such an NSAP, the entry PDN router does not know for sure, 2128 without explicit configuration information, whether or not the PDN 2129 Address can be used at the lower layer. Solution of this problem 2130 requires standards body agreement, perhaps be setting aside addi- 2131 tional AFIs to mean "PDN Address with topological significance". 2133 The second, and more serious, problem is that a PDN Address in an 2134 NSAP does not necessarily scale well. This is best illustrated with 2135 the E.164 address. E.164 addresses can be used in many different 2136 network technologies--telephone network, BISDN, SMDS, Frame Relay, 2137 and other ATM. When a router receives a packet with an E.164-based 2138 NSAP, the E.164 address is in the most significant part of the NSAP 2139 address (that is, contains the highest level routing information). 2140 Thus, without a potentially significant amount of routing table 2141 information, the router does not know which network to send the 2142 packet to. Thus, unless E.164 addresses are assigned out in blocks 2143 according to provider network, it won't scale well. 2145 A related problem is that of how an entry PDN router knows that the 2146 PDN address is meant for the PDN it is attached to or some other PDN. 2147 With Pip, there is a one-to-one relationship between Pip Address pre- 2148 fix and PDN, so it is always known. With NSAPs, it is not clear 2149 without the potentially large routing tables discussed in the previ- 2150 ous paragraph. 2152 16. Evolution with Pip 2154 The fact that we call this architecture "near-term" implies that we 2155 expect it to evolve to other architectures. Thus it is important 2156 that we have a plan to evolve to these architectures. The Pip near- 2157 term architecture includes explicit mechanisms to support evolution. 2159 The key to evolution is being able to evolve any system at any time 2160 without destroying old functionality. Depending on what the new 2161 functionality is, it may be immediately useful to any system that 2162 installs it, or it may not become useful until a significant number 2163 or even a majority of systems install it. None-the-less, it is 2164 necessary to be able to install it piece-wise. 2166 The Pip protocol itself supports evolution through the following 2167 mechanisms [2]: 2169 1. Tunneling. This allows more up-to-date routers to tunnel through 2170 less up-to-date routers, thus allowing for incremental router 2171 evolution. (Of course, by virtue of encapsulation, tunneling is 2172 always an evolution option, and indeed tunneling through IP is 2173 used in the Pip transition. However, Pip's tunneling encoding 2174 is efficient because it doesn't duplicate header information.) 2176 The only use for Pip tunneling in the Pip near-term architecture 2177 is to route packets through the internal routers of a transit 2178 domain when the internal routers have no external routing infor- 2179 mation. It is assumed that enhancements to the Pip Architecture 2180 that require tunneling will have their own means of indicating 2181 when forming a tunnel is necessary. 2183 2. Host independence from routing information. Since a host can 2184 receive packets without understanding the routing content of the 2185 packet, routers can evolve without necessarily requiring hosts 2186 to evolve at the same pace. 2188 In order to allow hosts to send Pip packets without understand- 2189 ing the contents of the routing information (in the Transit 2190 Part), the Pip Header Server is able to "spoon-feed" the host 2191 the Pip header. 2193 If the Pip Header Server determines that the host is able to 2194 form its own Pip header (as will usually be the case with the 2195 near-term Pip architecture), the Pip Header is essentially a 2196 null function. It accepts a query from the host, passes it on 2197 to DNS, and returns the DNS information to the host. 2199 If the Pip Header Server determines that the host is not able to 2200 form its own Pip header, then the Pip Header Server forms one on 2201 behalf of the host. In one mode of operation, the Pip Header 2202 Server gives the host the values of some or all Transit Part 2203 fields, and the host constructs the Transit Part. This allows 2204 for evolution within the framework of the current Transit Part. 2205 In another mode, the Pip Header Server gives the host the Tran- 2206 sit Part as a simple bit field. This allows for evolution out- 2207 side the framework of the current Transit Part. 2209 In addition to the Pip Header Server being able to spoon-feed 2210 the host a Transit Part, routers are also able to spoon-feed 2211 hosts a Transit Part, in case the original Transit Part needs to 2212 be modified, using the PCMP Reformat Transit Part message. 2214 3. Separation of handling from routing. This allows one aspect to 2215 evolve independently of the other. 2217 4. Flexible Handling Directive, Routing Context, and Options defin- 2218 ition. This allows new handling, routing, and option types to 2219 be added and defunct ones to be removed over time (see section 2220 16.1 below). 2222 5. Fast and general options processing. Options processing in Pip 2223 is fast, both because not every router need look at every 2224 option, and because once a router decides it needs to look at an 2225 option, it can find it quickly (does not require a serial 2226 search). Thus the oft-heard argument that a new option can't be 2227 used because it will slow down processing in all routers goes 2228 away. 2230 Pip Options can be thought of as an extension of the Handling 2231 Directive (HD). The HD is used when the handling type is com- 2232 mon, and can be encoded in a small space. The option is used 2233 otherwise. It is possible that a future option will influence 2234 routing, and thus the Option will be an extension of the RD as 2235 well. The RD, however, is rich enough that this is unlikely. 2237 6. Generalized Routing Directive. Because the Routing Directive is 2238 so general, it is more likely that we can evolve routing and 2239 addressing semantics without having to redefine the Pip header 2240 or the forwarding machinery. 2242 7. Host version number. This number tells what Pip functions a 2243 host has, such as which PCMP messages it can handle, so that 2244 routers can respond appropriately to a Pip packet received from 2245 a remote host. This supports the capability for routers to 2246 evolve ahead of hosts. (All Pip hosts will at least be able to 2247 handle all Pip near-term architecture functions.) 2249 The Host version number is also used by the Pip Header Server to 2250 determine the extent to which the Pip Header Server needs to 2251 format a header on behalf of the host. 2253 8. Generalized Route Types. The IDRP/MLPV routing algorithm is 2254 generic with regards to the types of routes it can calculate. 2255 Thus, adding new route types is a matter of configuring routers 2256 to accept the new route type, defining metrics for the new route 2257 type, and defining criteria for selecting one route of the new 2258 type over another. 2260 Note that none of these evolution features of Pip significantly slow 2261 down Pip header processing (as compared to other internet protocols). 2263 16.1. Handling Directive (HD) and Routing Context (RC) Evolution 2265 Because the HD and RC are central to handling and routing of a Pip 2266 packet, the evolution of these aspects deserves more discussion. 2268 Both the HD and the RC fields contain multiple parameters. (In the 2269 case of the RC, the router treats the RC field as a single number, 2270 that is, ignores the fact that the RC is composed of multiple parame- 2271 ters. This allows for fast forwarding of Pip packets.) These HD and 2272 RC multiple parameters may be arranged in any fashion (can be any 2273 length, subject to the length of the HD and RC fields themselves, and 2274 can fall on arbitrary bit boundaries). 2276 Associated with the HD and RC are "Contents" fields that indicate 2277 what parameters are in the HD and RC fields, and where they are. 2278 (The Contents fields are basically version numbers, except that a 2279 higher "version" number is not considered to supersede a lower one. 2280 Typical types of parameters are address family, TOS value, queueing 2281 priority, and so on.) 2283 The Contents field is a single number, the value of which indicates 2284 the parameter set. The mapping of Contents field value to parameter 2285 set is configured manually. 2287 The procedure for establishing new HD or RC parameter sets (or, eras- 2288 ing old ones) is as follows. Some organization defines the new 2289 parameter set. This may involve defining a new parameter. If it 2290 does, then the new parameter is described as a Pip Object. A Pip 2291 Object is nothing more than a number space used to unambiguously 2292 identify a new parameter type, and a character string that describes 2293 it [9]. 2295 Thus, the new parameter set is described as a list of Pip Objects, 2296 and the bit locations in the HD/RC that each Pip Object occupies. 2297 The organization that defines the parameter set submits it for an 2298 official Contents field value. (It would be submitted to the stan- 2299 dards body that has authority over Pip, currently the IAB.) If the 2300 new parameter set is approved, it is given a Contents value, and that 2301 value is published in a well known place (an RFC). 2303 Of course, network administrators are free to install or not install 2304 the new parameter set in their hosts and routers. In the case of a 2305 new RC parameter set, installation of the new parameter set does not 2306 necessarily require any new software, because any Pip routing proto- 2307 col, such as IDRP/MLPV, is able to find routes according to the new 2308 parameter set by appropriate configuration of routers. 2310 In the case of a new HD parameter set, however, new software is 2311 necessary--to execute the new handling. 2313 For new HD and RC parameters sets, systems that do not understand the 2314 new parameter set can still be configured to execute one of several 2315 default actions on the new parameter. These default action allow for 2316 some control over how new functions are introduced into Pip systems. 2317 The default actions are: 2319 1. Ignore the unknown parameter, 2321 2. Set unknown parameter to all 0's, 2323 3. Set unknown parameter to all 1's, 2325 4. Silently discard packet, 2327 5. Discard packet with PCMP Parameter Unknown. 2329 Action 1 is used when it doesn't much matter if previous systems on a 2330 path have acted on the parameter or not. Actions 2 and 3 are used 2331 when systems should know whether a previous system has not understood 2332 the parameter. Actions 4 and 5 are used when something bad happens 2333 if not all systems understand the new parameter. 2335 16.1.1. Options Evolution 2337 The evolution of Options is very similar to that of the HD and RC. 2338 Associated with the Options is an Options Present field that indi- 2339 cates in a single word which of up to 8 options are present in the 2340 Options Part. There is a Contents field associated with the Options 2341 Present field that indicates which subset of all possible options the 2342 Options Present field refers to. Contents field values are assigned 2343 in the same way as for the HD and RC Contents fields. 2345 The same 5 default actions used for the HD and RC also apply to the 2346 Options. 2348 References 2349 [1] Thomson, Francis, "Use of DNS with Pip", Internet-Draft 2350 [2] Francis, "Pip Header Processing", Internet-Draft 2351 [3] Pip Address Assignment Spec (to be completed) 2352 [4] Francis, "Pip Identifiers", Internet Draft 2353 [5] Pip Assigned Numbers (to be completed) 2354 [6] Pip Header Protocol (to be completed) 2355 [7] Francis, Govindan, "PCMP: Pip Control Message Protocol", 2356 Internet-Draft 2357 [8] Pip Router Discovery Protocol (to be completed) 2358 [9] Pip Objects Spec (Internet Draft) 2359 [10] Rajagopolan, Francis "The Multi-Level Path Vector Routing 2360 Scheme", Internet-Draft 2361 [11] Francis, "Pip Address Conventions", Internet-Draft 2362 [12] Francis "On the Assignment of Provider Rooted Addresses", 2363 Internet-Draft 2364 [13] Ballardie, Francis, Crowcroft, "Core Based Trees (CBT), An 2365 Architecture for Scalable Inter-Domain Multicast Routing", 2366 Internet-draft. 2367 [14] Franics, "Pip Host Operation", Internet-Draft 2368 [15] Kjeld Borch Egevang, Paul Francis, "The IP Network Address 2369 Translator (NAT)", Internet Draft, May 1993