RFCs in HTML Format

RFC 1621

                       Pip Near-term Architecture

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   evolve to all forseeable internet protocol requirements.  This
   specification describes the routing and addressing architecture for
   near-term Pip deployment.  We say near-term only because Pip is
   designed with evolution in mind, so other architectures are expected
   in the future.  This document, however, makes no reference to such
   future architectures.

Francis                                                         [Page 1]

RFC 1621 Pip Near-term Architecture May 1994 Table of Contents 1. Pip Architecture Overview ................................... 4 1.1 Pip Architecture Characteristics ........................... 4 1.2 Components of the Pip Architecture ......................... 5 2. A Simple Example ............................................ 6 3. Pip Overview ................................................ 7 4. Pip Addressing .............................................. 9 4.1 Hierarchical Pip Addressing ................................ 9 4.1.1 Assignment of (Hierarchical) Pip Addresses ............... 12 4.1.2 Host Addressing .......................................... 14 4.2 CBT Style Multicast Addresses .............................. 15 4.3 Class D Style Multicast Addresses .......................... 16 4.4 Anycast Addressing ......................................... 16 5. Pip IDs ..................................................... 17 6. Use of DNS .................................................. 18 6.1 Information Held by DNS .................................... 19 6.2 Authoritative Queries in DNS ............................... 20 7. Type-of-Service (TOS) (or lack thereof) ..................... 21 8. Routing on (Hierarchical) Pip Addresses ..................... 22 8.1 Exiting a Private Domain ................................... 23 8.2 Intra-domain Networking .................................... 24 9. Pip Header Server ........................................... 25 9.1 Forming Pip Headers ........................................ 25 9.2 Pip Header Protocol (PHP) .................................. 27 9.3 Application Interface ...................................... 27 10. Routing Algorithms in Pip .................................. 28 10.1 Routing Information Filtering ............................. 29 11. Transition ................................................. 30 11.1 Justification for Pip Transition Scheme ................... 31 11.2 Architecture for Pip Transition Scheme .................... 31 11.3 Translation between Pip and IP packets .................... 33 11.4 Translating between PCMP and ICMP ......................... 34 11.5 Translating between IP and Pip Routing Information ........ 34 11.6 Old TCP and Application Binaries in Pip Hosts ............. 34 11.7 Translating between Pip Capable and non-Pip Capable DNS Servers ................................................... 35 Francis [Page 2]
RFC 1621 Pip Near-term Architecture May 1994 12. Pip Address and ID Auto-configuration ...................... 37 12.1 Pip Address Prefix Administration ......................... 37 12.2 Host Autoconfiguration .................................... 38 12.2.1 Host Initial Pip ID Creation ............................ 38 12.2.2 Host Pip Address Assignment ............................. 39 12.2.3 Pip ID and Domain Name Assignment ....................... 39 13. Pip Control Message Protocol (PCMP) ........................ 40 14. Host Mobility .............................................. 42 14.1 PCMP Mobile Host message .................................. 43 14.2 Spoofing Pip IDs .......................................... 44 15. Public Data Network (PDN) Address Discovery ................ 44 15.1 Notes on Carrying PDN Addresses in NSAPs .................. 46 16. Evolution with Pip ......................................... 46 16.1 Handling Directive (HD) and Routing Context (RC) Evolution. 49 16.1.1 Options Evolution ....................................... 50 References ..................................................... 51 Security Considerations ........................................ 51 Author's Address ............................................... 51 Francis [Page 3]
RFC 1621 Pip Near-term Architecture May 1994 Introduction Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures (except in that it discusses Pip evolution in general). This document gives an overall picture of how Pip operates. It is provided primarily as a framework within which to understand the total set of documents that comprise Pip. 1. Pip Architecture Overview The Pip near-term architecture is an incremental step from IP. Like IP, near-term Pip is datagram. Pip runs under TCP and UDP. DNS is used in the same fashion it is now used to distribute name to Pip Address (and ID) mappings. Routing in the near-term Pip architecture is hop-by-hop, though it is possible for a host to create a domain- level source route (for policy reasons). Pip Addresses have more hierarchy than IP, thus improving scaling on one hand, but introducing additional addressing complexities, such as multiple addresses, on the other. Pip, however, uses hierarchical addresses to advantage by making them provider-based, and using them to make policy routing (in this case, provider selection) choices. Pip also provides mechanisms for automatically assigning provider prefixes to hosts and routers in domains. This is the main difference between the Pip near-term architecture and the IP architecture. (Note that in the remainder of this paper, unless otherwise stated, the phrase "Pip architecture" refers to the near- term Pip architecture described herein.) 2. Pip Architecture Characteristics The proposed architecture for near-term Pip has the following characteristics: 1. Provider-rooted hierarchical addresses. 2. Automatic domain-wide address prefix assignment. 3. Automatic host address and ID assignment. Francis [Page 4]
RFC 1621 Pip Near-term Architecture May 1994 4. Exit provider selection. 5. Multiple defaults routing (default routing, but to multiple exit points). 6. Equivalent of IP Class D style addressing for multicast. 7. CBT style multicast. 8. "Anycast" addressing (route to one of a group, usually the nearest). 9. Providers support forwarding on policy routes (but initially will not provide the support for sources to calculate policy routes). 10. Mobile hosts. 11. Support for routing across large Public Data Networks (PDN). 12. Inter-operation with IP hosts (but, only within an IP-address domain where IP addresses are unique). In particular, an IP address can be explicitly carried in a Pip header. 13. Operation with existing transport and application binaries (though if the application contains IP context, like FTP, it may only work within a domain where IP addresses are unique). 14. Mechanisms for evolving Pip beyond the near-term architecture. 1.2 Components of the Pip Architecture The Pip Architecture consists of the following five systems: 1. Host (source and sink of Pip packets) 2. Router (forwards Pip packets) 3. DNS 4. Pip/IP Translator 5. Pip Header Server (formats Pip headers) The first three systems exist in the IP architecture, and require no explanation here. The fourth system, the Pip/IP Translator, is required solely for the purpose of inter-operating with current IP systems. All Pip routers are also Pip/IP translators. Francis [Page 5]
RFC 1621 Pip Near-term Architecture May 1994 The fifth system, the Pip Header Server, is new. Its function is to format Pip headers on behalf of the source host (though initially hosts will be able to do this themselves). This use of the Pip Header Server will increase as policy routing becomes more sophisticated (moves beyond near-term Pip Architecture capabilities). To handle future evolution, a Pip Header Server can be used to "spoon-feed" Pip headers to old hosts that have not been updated to understand new uses of Pip. This way, the probability that the internet can evolve without changing all hosts is increased. 2. A Simple Example A typical Pip "exchange" is as follows: An application initiates an exchange with another host as identified by a domain name. A request for one or more Pip Headers, containing the domain name of the destination host, goes to the Pip Header Server. The Pip Header Server generates a DNS request, and receive back a Pip ID, multiple Pip Addresses, and possibly other information such as a mobile host server or a PDN address. Given this information, plus information about the source host (its Pip Addresses, for instance), plus optionally policy information, plus optionally topology information, the Pip Header Server formats an ordered list of valid Pip headers and give these to the host. (Note that if the Pip Header Server is co-resident with the host, as will be common initially, the host behavior is similar to that of an IP host in that a DNS request comes from the host, and the host forms a Pip header based on the answer from DNS.) The source host then begins to transmit Pip packets to the destination host. If the destination host is an IP host, then the Pip packet is translated into an IP packet along the way. Assuming that the destination host is a Pip host, however, the destination host uses the destination Pip ID alone to determine if the packet is destined for it. The destination host generates a return Pip header based either on information in the received Pip header, or the destination host uses the Pip ID of the source host to query the Pip Header Server/DNS itself. The latter case involves more overhead, but allows a more informed decision about how to return packets to the originating host. If either host is mobile, and moves to a new location, thus getting a new Pip Address, it informs the other host of its new address directly. Since host identification is based on the Pip ID and not the Pip Address, this doesn't cause transport level to fail. If both hosts are mobile and receive new Pip Addresses at the same time (and thus cannot exchange packets at all), then they can query each other's respective mobile host servers (learned from DNS). Note that Francis [Page 6]
RFC 1621 Pip Near-term Architecture May 1994 keeping track of host mobility is completely confined to hosts. Routers never get involved in tracking mobile hosts (though naturally they are involved in host discovery and automatic host address assignment). 3. Pip Overview Here, a brief overview of the Pip protocol is given. The reader is encouraged to read [2] for a complete description. The Pip header is divided into three parts: Initial Part Transit Part Options Part The Initial Part contains the following fields: Version Number Options Offset, OP Contents, Options Present (OP) Packet SubID Protocol Dest ID Source ID Payload Length Host Version Payload Offset Hop Count All of the fields in the Initial Part are of fixed length. The Initial Part is 8 32-bit words in length. The Version Number places Pip as a subsequent version of IP. The Options Offset, OP Contents, and Options Present (OP) fields tell how to process the options. The Options Offset tells where the options are The OP tells which of up to 8 options are in the options part, so that the Pip system can efficiently ignore options that don't pertain to it. The OP Contents is like a version number for the OP field. It allows for different sets of the (up to 8) options. The Packet SubID is used to relate a received PCMP message to a previously sent Pip packet. This is necessary because, since routers in Pip can tag packets, the packet returned to a host in a PCMP message may not be the same as the packet sent. The Payload Length and Protocol take the place of IP's Total Length and Protocol fields respectively. The Dest ID identifies the destination host, and is not used for routing, except for where the final router on a LAN uses ARP to find the physical address of the host identified by the dest Francis [Page 7]
RFC 1621 Pip Near-term Architecture May 1994 ID. The Source ID identifies the source of the packet. The Host Version tells what control algorithms the host has implemented, so that routers can respond to hosts appropriately. This is an evolution mechanism. The Hop Count is similar to IP's Time-to-Live. The Transit Part contains the following fields: Transit Part Offset HD Contents Handling Directive (HD) Active FTIF RC Contents Routing Context (RC) FTIF Chain (FTIF = Forwarding Table Index Field) Except for the FTIF Chain, which can have a variable number of 16-bit FTIF fields, the fields in the Transit Part are of fixed length, and are three 32-bit words in length. The Transit Part Offset gives the length of the Transit Part. This is used to determine the location of the subsequent Transit Part (in the case of Transit Part encapsulation). The Handling Directive (HD) is a set of subfields, each of which indicates a specific handling action that must be executed on the packet. Handling directives have no influence on routing. The HD Contents field indicates what subfields are in the Handling Directive. This allows the definition of the set of handling directives to evolve over time. Example handling directives are queueing priority, congestion experienced bit, drop priority, and so on. The remaining fields comprise the Routing Directive. This is where the routing decision gets made. The basic algorithm is that the router uses the Routing Context to choose one of multiple forwarding tables. The Active FTIF indicates which of the FTIFs to retrieve, which is then used as an index into the forwarding table, which either instructs the router to look at the next FTIF, or returns the forwarding information. Examples of Routing Context uses are; to distinguish address families (multicast vs. unicast), to indicate which level of the hierarchy a packet is being routed at, and to indicate a Type of Service. In the near-term architecture, the FTIF Chain is used to carry source and destination hierarchical unicast addresses, policy route fragments, multicast addresses (all-of-group), and anycast (one-of-group) addresses. Like the OP Contents and HD Contents fields, the RC Contents field indicates what subfields are in the Routing Context. Francis [Page 8]
RFC 1621 Pip Near-term Architecture May 1994 This allows the definition of the Routing Context to evolve over time. The Options Part contains the options. The options are preceded by an array of 8 fields that gives the offset of each of up to 8 options. Thus, a particular option can be found without a serial search of the list of options. 4. Pip Addressing Addressing is the core of any internet architecture. Pip Addresses are carried in the Routing Directive (RD) of the Pip header (except for the Pip ID, which in certain circumstances functions as part of the Pip Address). Pip Addresses are used only for routing packets. They do not identify the source and destination of a Pip packet. The Pip ID does this. Here we describe and justify the Pip Addressing types. There are four Pip Address types [11]. The hierarchical Pip Address (referred to simply as the Pip Address) is used for scalable unicast and for the unicast part of a CBT-style multicast and anycast. The multicast part of a CBT-style multicast is the second Pip address type. The third Pip address type is class-D style multicast. The fourth type of Pip address is the so-called "anycast" address. This address causes the packet to be forwarded to one of a class of destinations (such as, to the nearest DNS server). Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is, for the near-term Pip architecture) indicate which of four address families the FTIFs and Dest ID apply to. The values are: Value Address Family ----- -------------- 00 Hierarchical Unicast Pip Address 01 Class D Style Multicast Address 10 CBT Style Multicast Address 11 Anycast Pip Address The remaining bits are defined differently for different address families, and are defined in the following sections. 4.1 Hierarchical Pip Addressing The primary purpose of a hierarchical address is to allow better scaling of routing information, though Pip also uses the "path" information latent in hierarchical addresses for making provider selection (policy routing) decisions. Francis [Page 9]
RFC 1621 Pip Near-term Architecture May 1994 The Pip Header encodes addresses as a series of separate numbers, one number for each level of hierarchy. This can be contrasted to traditional packet encodings of addresses, which places the entire address into one field. Because of Pip's encoding, it is not necessary to specify a format for a Pip Address as it is with traditional addresses (for instance, the SIP address is formatted such that the first so-many bits are the country/metro code, the next so-many bits are the site/subscriber, and so on). Pip's encoding also eliminates the "cornering in" effect of running out of space in one part of the hierarchy even though there is plenty of room in another. No "field sizing" decisions need be made at all with Pip Addresses. This makes address assignment easier and more flexible than with traditional addresses. Pip Addresses are carried in DNS as a series of numbers, usually with each number representing a layer of the hierarchy [1], but optionally with the initial number(s) representing a "route fragment" (the tail end of a policy route--a source route whose elements are providers). The route fragments would be used, for instance, when the destination network's directly attached (local access) provider is only giving access to other (long distance) providers, but the important provider-selection policy decision has to do the long distance providers. The RC for (hierarchical) Pip Addresses is defined as: bits meaning ---- ------- 0,1 Pip Address (= 00) 2,3 level 4,5 metalevel 6 exit routing type The level and metalevel subfields are used to indicate what level of the hierarchy the packet is currently at (see section 8). The exit routing type subfield is used to indicate whether host-driven (hosts decide exit provider) or router-driven (routers decide exit provider) exit routing is in effect (see section 8.1). Each FTIF in the FTIF Chain is 16 bits in length. The low-order part of each FTIF in a (hierarchical unicast) Pip Address indicates the relationship of the FTIF with the next FTIF. The three relators are Vertical, Horizontal, and Extension. The Vertical and Horizontal relators indicate if the subsequent FTIF is hierarchically above or below (Vertical) or hierarchically unrelated (Horizontal). The Extension relator is used to encode FTIF values longer than 16 bits. Francis [Page 10]
RFC 1621 Pip Near-term Architecture May 1994 FTIF values 0 - 31 are reserved for special purposes. That is, they cannot be assigned to normal hierarchical elements. FTIF value 1 is defined as a flag to indicate a switch from the unicast phase of packet forwarding to the anycast phase of packet forwarding. Note that Pip Addresses do not need to be seen by protocol layers above Pip (though layers above Pip can provide a Pip Address if desired). Transport and above use the Pip ID to identify the source and destination of a Pip packet. The Pip layer is able to map the Pip IDs (and other information received from the layer above, such as QOS) into Pip Addresses. The Pip ID can serve as the lowest level of a Pip Address. While this "bends the principal" of separating Pip Addressing from Pip Identification, it greatly simplifies dynamic host address assignment. The Pip ID also serves as a multicast ID. Unless otherwise stated, the term "Pip Address" refers to just the part in the Routing Directive (that is, excludes the Pip ID). Pip Addresses are provider-rooted (as opposed to geographical). That is, the top-level of a Pip Address indicates a network service provider (even when the service provided is not Pip). (A justification of using provider-rooted rather than geographical addresses is given in [12].) Thus, the basic form of a Pip address is: providerPart,subscriberPart where both the providerPart and subscriberPart can have multiple layers of hierarchy internally. A subscriber may be attached to multiple providers. In this case, a host can end up with multiple Pip Addresses by virtue of having multiple providerParts: providerPart1,subscriberPart providerPart2,subscriberPart providerPart3,subscriberPart This applies to the case where the subscriber network spans many different provider areas, for instance, a global corporate network. In this case, some hosts in the global corporate network will have certain providerParts, and other hosts will have others. The subscriberPart should be assigned such that routing can successfully take place without a providerPart in the destination Pip Address of the Pip Routing Directive (see section 8.2). Francis [Page 11]
RFC 1621 Pip Near-term Architecture May 1994 Note that, while there are three providerParts shown, there is only one subscriberPart. Internal subscriber numbering should be independent of the providerPart. Indeed, with the Pip architecture, it is possible to address internal packets without including any of the providerPart of the address. Top-level Pip numbers can be assigned to subscriber networks as well as to providers. privatePart,subscriberPart In this case, however, the top-level number (privatePart) would not be advertised globally. The purpose of such an assignment is to give a private network "ownership" of a globally unique Pip Address space. Note that the privatePart is assigned as an extended FTIF (that is, from numbers greater than 2^15). Because the privatePart is not advertised globally, and because internal packets do not need the prefix (above the subscriberPart), the privatePart actually never appears in a Pip packet header. Pip Addresses can be prepended with a route fragment. That is, one or more Pip numbers that are all at the top of the hierarchy. longDistanceProvider.localAccessProvider.subscriber (top-level) (top-level) (next level) This is useful, for instance, when the subscriber's directly attached provider is a "local access" provider, and is not advertised globally. In this case, the "long distance" provider is prepended to the address even though the local access provider number is enough to provide global uniqueness. Note that no coordination is required between the long distance and local access providers to form this address. The subscriber with a prefix assigned to it by the local access provider can autonomously form and use this address. It is only necessary that the long distance provider know how to route to the local access provider. 4.1.1 Assignment of (Hierarchical) Pip Addresses Administratively, Pip Addresses are assigned as follows [3]. There is a root Pip Address assignment authority. Likely choices for this are IANA or ISOC. The root authority assigns top-level Pip Address numbers. (A "Pip Address number" is the number at a single level of the Pip Address hierarchy. A Pip Address prefix is a series of contiguous Pip Address numbers, starting at the top level but not including the entire Pip Address. Thus, the top-level prefix is the same thing as the top-level number.) Francis [Page 12]
RFC 1621 Pip Near-term Architecture May 1994 Though by-and-large, and most importantly, top-level assignments are made to providers, each country is given an assignment, each existing address space (such as E.164, X.121, IP, etc.) is given an assignment, and private networks can be given assignments. Thus, existing addresses can be grandfathered in. Even if the top-level Pip address number is an administrative rather than topological assignment, the routing algorithm still advertises providers at the top (provider) level of routing. That is, routing will advertise enough levels of hierarchy that providers know how to route to each other. There must be some means of validating top-level number requests from providers (basically, those numbers less than 2^15). That is, top- level assignments must be made only to true providers. While designing the best way to do this is outside the scope of this document, it seems off hand that a reasonable approach is to charge for the top-level prefixes. The charge should be enough to discourage non-serious requests for prefixes, but not so much that it becomes an inhibitor to entry in the market. The charge might include a yearly "rent", and top-level prefixes could be reclaimed when they are no longer used by the provider. Any profit made from this activity could be used to support the overall role of number assignment. Since roughly 32,000 top-level assignments can be made before having to increase the FTIF size in the Pip header from 16 bits to 32 bits, it is envisioned that top-level prefixes will not be viewed as a scarce resource. After a provider obtains a top-level prefix, it becomes an assignment authority with respect to that particular prefix. The provider has complete control over assignments at the next level down (the level below the top-level). The provider may either assign top-level minus one prefixes to subscribers, or preferably use that level to provide hierarchy within the provider's network (for instance, in the case where the provider has so many subscribers that keeping routing information on all of them creates a scaling problem). It is envisioned that the subscriber will have complete control over number assignments made at levels below that of the prefix assigned it by the provider. Assigning top level prefixes directly to providers leaves the number of top-level assignments open-ended, resulting in the possibility of scaling problems at the top level. While it is expected that the number of providers will remain relatively small (say less than 10000 globally), this can't be guaranteed. If there are more providers than top-level routing can handle, it is likely that many of these providers will be "local access" providers--providers whose role is to give a subscriber access to multiple "long-distance" providers. In this case, the local access providers need not appear at the top Francis [Page 13]
RFC 1621 Pip Near-term Architecture May 1994 level of routing, thus mitigating the scaling problem at that level. In the worst case, if there are too many top-level "long-distance" providers for top-level routing to handle, a layer of hierarchy above the top-level can be created. This layer should probably conform to some policy criteria (as opposed to a geographical criteria). For instance, backbones with similar access restrictions or type-of- service can be hierarchically clustered. Clustering according to policy criteria rather than geographical allows the choice of address to remain an effective policy routing mechanism. Of course, adding a layer of hierarchy to the top requires that all systems, over time, obtain a new providerPart prefix. Since Pip has automatic prefix assignment, and since DNS hides addresses from users, this is not a debilitating problem. 4.1.2 Host Addressing Hosts can have multiple Pip Addresses. Since Pip Addresses are topologically significant, a host has multiple Pip Addresses because it exists in multiple places topologically. For instance, a host can have multiple Pip addresses because it can be reached via multiple providers, or because it has multiple physical interfaces. The address used to reach the host influences the path to the host. Locally, Pip Addressing is similar to IP Addressing. That is, Pip prefixes are assigned to subnetworks (where the term subnetwork here is meant in the OSI sense. That is, it denotes a network operating at a lower layer than the Pip layer, for instance, a LAN). Thus, it is not necessary to advertise individual hosts in routing updates-- routers only need to advertise and store routes to subnetworks. Unlike IP, however, a single subnetwork can have multiple prefixes. (Strictly speaking, in IP a single subnetwork can have multiple prefixes, but a host may not be able to recognize that it can reach another host on the same subnetwork but with a different prefix without going through a router.) There are two styles of local Pip Addressing--one where the Pip Address denotes the host, and another where the Pip Address denotes only the destination subnetwork. The latter style is called ID- tailed Pip Addressing. With ID-tailed Pip Addresses, the Pip ID is used by the last router to forward the packet to the host. It is expected that ID-tailed Pip Addressing is the most common, because it greatly eases address administration. (Note that the Pip Routing Directive can be used to route a Pip packet internal to a host. For instance, the RD can be used to direct a packet to a device in a host, or even a certain memory Francis [Page 14]
RFC 1621 Pip Near-term Architecture May 1994 location. The use of the RD for this purpose is not part of this near-term Pip architecture. We note, however, that this use of the RD could be locally done without effecting any other Pip systems.) When a router receives a Pip packet and determines that the packet is destined for a host on one of its' attached subnetworks (by examining the appropriate FTIF), it then examines the destination Pip ID (which is in a fixed position) and forwards based on that. If it does not know the subnetwork address of the host, then it ARPs, using the Pip ID as the "address" in the ARP query. 4.2 CBT Style Multicast Addresses When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10, the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast. The remainder of the bits are defined as follows: bits meaning ---- ------- 0,1 CBT Multicast (= 10) 2,3 level 4,5 metalevel 6 exit routing type 7 on-tree bit 8,9 scoping With CBT (Core-based Tree) multicast, there is a single multicast tree connecting the members (recipients) of the multicast group (as opposed to Class-D style multicast, where there is a tree per source). The tree emanates from a single "core" router. To transmit to the group, a packet is routed to the core using unicast routing. Once the packet reaches a router on the tree, it is multicast using a group ID. Thus, the FTIF Chain for CBT multicast contains the (Unicast) Hierarchical Pip Address of the core router. The Dest ID field contains the group ID. A Pip CBT packet, then, has two phases of forwarding, a unicast phase and a multicast phase. The "on-tree" bit of the RC indicates which phase the packet is in. While in the unicast phase, the on-tree bit is set to 0, and the packet is forwarded similarly to Pip Addresses. During this phase, the scoping bits are ignored. Francis [Page 15]
RFC 1621 Pip Near-term Architecture May 1994
RFC 1621 Pip Near-term Architecture May 1994 14. Host Mobility Depending on how security conscience a host is, and what security mechanisms a host has available, mobility can come from Pip "for free". If a host is willing to accept a packet by just looking at source and destination Pip ID, and if the host simply records the source Pip Address on any packet it receives as the appropriate return address to the source Pip ID, then mobility comes automatically. That is, when a mobile host gets a new Pip Address, it simply puts that address into the next packet it sends. When the other host receives it, it records the new Pip Address, and starts sending return packets to that address. The security aspect of this is that this type of operation leads to an easy way to spoof the (internet level) identity of a host. That is, absent any other security mechanisms, any host can write any Pip ID into a packet. (Cross- checking a source Pip ID against the source Pip Address at least makes spoofing of this sort as hard as with IP. This is discussed below.) The above simple host mobility mechanism does not work in the case where source and destination hosts obtain new Pip Addresses at the same time and the old Pip addresses no longer work, because neither is able to send its new address information directly to the other. Furthermore, if a host wishes to be more secure about authenticating the source Pip ID of a packet, then the above mechanism also is not satisfactory. In what follows, the complete host mobility mechanism is described. Pip uses the Mobile Host Server and the PCMP Host Mobility message to manage host mobility; The Mobile Host Server is a non-mobile host (or router acting as a host) that keeps track of the active address of a mobile host. The Pip ID and Address of the Mobile Host Server is configured into the mobile host, and in DNS. When a host X obtains information from DNS about a host Y, the Pip ID and Address of host Y's Mobile Host Server is among the information. (Also among the information is host Y's "permanent" address, if host Y has one. If host Y is so mobile that it doesn't have a permanent address, then no permanent address is returned by DNS. In particular, note that DNS is not intended to keep track of a mobile host's active address.) Given the destination host's (Y) permanent ID and Address, and the Mobile Host Server's permanent IDs and Addresses, the source host (X) proceedes as follows. X tries to establish communications with Y using one of the permanent addresses. If this fails (or if at any Francis [Page 42]
RFC 1621 Pip Near-term Architecture May 1994 time X cannot contact Y), X sends a PCMP Mobile Host message to the Mobile Host Server requesting the active address for Y. (Note that X can determine that it cannot contact Y from receipt of a PCMP Destination Unreachable or a PCMP Invalid Address message.) The Mobile Host Server responds to X with the active Pip Addresses of Y. (Of course, Y must inform its Mobile Host Server(s) of its active Pip Addresses when it knows them. This also is done using the PCMP Mobile Host message. Y also informs any hosts that it is actively communicating with, using either a regular Pip packet or with a PCMP Mobile Host message. Thus, usually X does not need to contact the Mobile Host Server to track Y's active address.) If the address that X already tried is among those returned by Y, then the source host has the option of either 1) continuing to try the same Pip Address, 2) trying another of Y's Pip Addresses, 3) waiting and querying the Mobile Host Server again, or 4) giving up. If the Mobile Host Server indicates that Y has new active Pip Addresses, then X chooses among these in the same manner that it chooses among multiple permanent Pip Addresses, and tries to contact Y. 14.1 PCMP Mobile Host message There are two types of PCMP Mobile Host messages, the query and the response. The query consists of the Pip ID of the host for which active Pip Address information is being requested. The response consists of a Pip ID, a sequence number, a set of Pip Addresses, and a signature field. The set of Pip Addresses includes all currently usable addresses of the host indicated by the Pip ID. Thus, the PCMP Mobile Host message can be used both to indicate a newly obtained address, and to indicate that a previous address is no longer active (by that addresses' absence in the set). The sequence number indicates which is the most recent information. It is needed to deal with the case where an older PCMP Mobile Host response is received after a newer one. The signature field is a value that derives from encrypting the sequence number and the set of Pip Addresses. For now, the encryption algorithms used, how to obtain keys, and so on are for further study. Francis [Page 43]
RFC 1621 Pip Near-term Architecture May 1994 14.2 Spoofing Pip IDs This section discusses host mechanisms for decreasing the probability of Pip ID spoofing. The mechanisms provided in this version of the near-term Pip architecture are no more secure than DNS itself. It is hoped that mechanisms and the corresponding infrastructure needed for better internetwork layer security can be installed with whatever new IP protocol is chosen. After a host makes a DNS query, it knows: 1. The destination host's Pip ID, 2. The destination host's permanent Pip Addresses, and 3. The destination host's Mobile Host Server's Pip ID and Addresses. Note that the DNS query can be a normal one (based on domain name) or an inverse query (based on Pip ID or Pip Address, though the latter is more likely to succeed, since the Pip ID may be flat and therefore not suitable for an inverse lookup). The inverse query is done when the host did not initiate the packet exchange, and therefore doesn't know the domain name of the remote (initiating) host. If the destination host is not mobile, then the source host can check the source Pip Address, compare it with those received from DNS, and reject the packet if it does not match. This gives spoof protection equal to that of IP. If the destination host is mobile and obtains new Pip Addresses, then the source host can check the validity of the new Pip Address by sending a PCMP Mobile Host query to the Mobile Host Server learned from DNS. The set of Pip Addresses learned from the Mobile Address Server is then used for subsequent validation. 15. Public Data Network (PDN) Address Discovery One of the problems with running Pip (or any internet protocol) over a PDN is that of the PDN entry Pip System discovering the PDN Address of the appropriate PDN exit Pip System. This problem is solved using ARP in small, broadcast LANs because the broadcast mechanism is relatively cheap. This solution is not available in the PDN case, where the number of attached systems is very large, and where broadcast is not available (or is not cheap if it is). For the case where the domain of the destination host is attached to a PDN, the problem is nicely solved by distributing the domain's exit PDN Address information in DNS, and then having the source host Francis [Page 44]
RFC 1621 Pip Near-term Architecture May 1994 convey the exit PDN Address to the PDN entry router in a Pip option. The DNS of the destination host's domain contains the PDN Addresses for the domain. When DNS returns a record for the destination host, the record associates zero or more PDN Addresses with each Pip Address. There can be more than one PDN address associated with a given PDN, and there can be more than on PDN associated with a given Pip Address. This latter case occurs when more than one hierarchical component of the Pip Address each represents a separate PDN. It is expected that in almost all cases, there will be only one (or none) PDN associated with any Pip address. (Note that, while the returned DNS record associates the PDN Addresses with a single Pip Address, in general the PDN Address will apply to a set of Pip Addresses--those for all hosts in the domain. The DNS files are structured to reflect this grouping in the same way that a single Pip Address prefix in DNS applies to many hosts. Therefore, every individual host entry in the DNS files does not need to have separate PDN Addresses typed in with it. This simplifies configuration of DNS.) When the source host sends the first packet to a given destination host, it attaches the PDN Addresses, one per PDN, to the packet in an option. (Note that, because of the way that options are processed in Pip packets, no router other than the entry PDN router need look at the option.) When the entry router receives this packet, it determines that it is the entry router based on the result of the FTIF Chain lookup. It retrieves the PDN Address from the option, and caches it locally. The cache entry can later by retrieved using either the destination Pip ID or the destination Pip Address as the cache index. The entry router sends the source host a PCMP Exit PDN Address message indicating that it has cached the information. If there are multiple exit PDN Addresses, then the source host can at this time inform the entry PDN router of all the PDN addresses. The entry PDN router can either choose from these to setup a connection, or cache them to recover from the case where the existing connection breaks. Finally, the entry PDN router delivers the Pip packet (perhaps by setting up a connection) to the PDN Address indicated. When a PDN entry router receives a Pip packet for which it doesn't know the exit PDN address (and has no other means of determining it, such as shortcut routing), it sends a PCMP Exit PDN Address query message to the originating host. This can happen if, for instance, routing changes and directs the packets to a new PDN entry router. Francis [Page 45]
RFC 1621 Pip Near-term Architecture May 1994 When the source host receives the PCMP Exit PDN Address query message, it transmits the PDN Addresses to the entry PDN router. 15.1 Notes on Carrying PDN Addresses in NSAPs The Pip use of PDN Address carriage in the option or PCP Exit PDN Address message solves two significant problems associated with the analogous use of PDN Address-based NSAPs. First, there is no existing agreement (standards or otherwise) that the existence of of a PDN Address in an NSAP address implies that the identified host is reachable behind the PDN Address. Thus, upon receiving such an NSAP, the entry PDN router does not know for sure, without explicit configuration information, whether or not the PDN Address can be used at the lower layer. Solution of this problem requires standards body agreement, perhaps be setting aside additional AFIs to mean "PDN Address with topological significance". The second, and more serious, problem is that a PDN Address in an NSAP does not necessarily scale well. This is best illustrated with the E.164 address. E.164 addresses can be used in many different network technologies--telephone network, BISDN, SMDS, Frame Relay, and other ATM. When a router receives a packet with an E.164-based NSAP, the E.164 address is in the most significant part of the NSAP address (that is, contains the highest level routing information). Thus, without a potentially significant amount of routing table information, the router does not know which network to send the packet to. Thus, unless E.164 addresses are assigned out in blocks according to provider network, it won't scale well. A related problem is that of how an entry PDN router knows that the PDN address is meant for the PDN it is attached to or some other PDN. With Pip, there is a one-to-one relationship between Pip Address prefix and PDN, so it is always known. With NSAPs, it is not clear without the potentially large routing tables discussed in the previous paragraph. 16. Evolution with Pip The fact that we call this architecture "near-term" implies that we expect it to evolve to other architectures. Thus it is important that we have a plan to evolve to these architectures. The Pip near- term architecture includes explicit mechanisms to support evolution. The key to evolution is being able to evolve any system at any time without destroying old functionality. Depending on what the new functionality is, it may be immediately useful to any system that installs it, or it may not become useful until a significant number Francis [Page 46]
RFC 1621 Pip Near-term Architecture May 1994 or even a majority of systems install it. None-the-less, it is necessary to be able to install it piece-wise. The Pip protocol itself supports evolution through the following mechanisms [2]: 1. Tunneling. This allows more up-to-date routers to tunnel less up-to-date routers, thus allowing for incremental router evolution. (Of course, by virtue of encapsulation, tunneling is always an evolution option, and indeed tunneling through IP is used in the Pip transition. However, Pip's tunneling encoding is efficient because it doesn't duplicate header information.) The only use for Pip tunneling in the Pip near-term architecture is to route packets through the internal routers of a transit domain when the internal routers have no external routing information. It is assumed that enhancements to the Pip Architecture that require tunneling will have their own means of indicating when forming a tunnel is necessary. 2. Host independence from routing information. Since a host can receive packets without understanding the routing content of the packet, routers can evolve without necessarily requiring hosts to evolve at the same pace. In order to allow hosts to send Pip packets without understanding the contents of the routing information (in the Transit Part), the Pip Header Server is able to "spoon-feed" the host the Pip header. If the Pip Header Server determines that the host is able to form its own Pip header (as will usually be the case with the near-term Pip architecture), the Pip Header is essentially a null function. It accepts a query from the host, passes it on to DNS, and returns the DNS information to the host. If the Pip Header Server determines that the host is not able to form its own Pip header, then the Pip Header Server forms one on behalf of the host. In one mode of operation, the Pip Header Server gives the host the values of some or all Transit Part fields, and the host constructs the Transit Part. This allows for evolution within the framework of the current Transit Part. In another mode, the Pip Header Server gives the host the Transit Part as a simple bit field. This allows for evolution outside the framework of the current Transit Part. In addition to the Pip Header Server being able to spoon-feed the host a Transit Part, routers are also able to spoon-feed hosts a Transit Part, in case the original Transit Part needs to be Francis [Page 47]
RFC 1621 Pip Near-term Architecture May 1994 modified, using the PCMP Reformat Transit Part message. 3. Separation of handling from routing. This allows one aspect to evolve independently of the other. 4. Flexible Handling Directive, Routing Context, and Options definition. This allows new handling, routing, and option types to be added and defunct ones to be removed over time (see section 16.1 below). 5. Fast and general options processing. Options processing in Pip is fast, both because not every router need look at every option, and because once a router decides it needs to look at an option, it can find it quickly (does not require a serial search). Thus the oft-heard argument that a new option can't be used because it will slow down processing in all routers goes away. Pip Options can be thought of as an extension of the Handling Directive (HD). The HD is used when the handling type is common, and can be encoded in a small space. The option is used otherwise. It is possible that a future option will influence routing, and thus the Option will be an extension of the RD as well. The RD, however, is rich enough that this is unlikely. 6. Generalized Routing Directive. Because the Routing Directive is so general, it is more likely that we can evolve routing and addressing semantics without having to redefine the Pip header or the forwarding machinery. 7. Host version number. This number tells what Pip functions a host has, such as which PCMP messages it can handle, so that routers can respond appropriately to a Pip packet received from a remote host. This supports the capability for routers to evolve ahead of hosts. (All Pip hosts will at least be able to handle all Pip near-term architecture functions.) The Host version number is also used by the Pip Header Server to determine the extent to which the Pip Header Server needs to format a header on behalf of the host. 8. Generalized Route Types. The IDRP/MLPV routing algorithm is generic with regards to the types of routes it can calculate. Thus, adding new route types is a matter of configuring routers to accept the new route type, defining metrics for the new route type, and defining criteria for selecting one route of the new type over another. Francis [Page 48]
RFC 1621 Pip Near-term Architecture May 1994 Note that none of these evolution features of Pip significantly slow down Pip header processing (as compared to other internet protocols). 16.1 Handling Directive (HD) and Routing Context (RC) Evolution Because the HD and RC are central to handling and routing of a Pip packet, the evolution of these aspects deserves more discussion. Both the HD and the RC fields contain multiple parameters. (In the case of the RC, the router treats the RC field as a single number, that is, ignores the fact that the RC is composed of multiple parameters. This allows for fast forwarding of Pip packets.) These HD and RC multiple parameters may be arranged in any fashion (can be any length, subject to the length of the HD and RC fields themselves, and can fall on arbitrary bit boundaries). Associated with the HD and RC are "Contents" fields that indicate what parameters are in the HD and RC fields, and where they are. (The Contents fields are basically version numbers, except that a higher "version" number is not considered to supersede a lower one. Typical types of parameters are address family, TOS value, queueing priority, and so on.) The Contents field is a single number, the value of which indicates the parameter set. The mapping of Contents field value to parameter set is configured manually. The procedure for establishing new HD or RC parameter sets (or, erasing old ones) is as follows. Some organization defines the new parameter set. This may involve defining a new parameter. If it does, then the new parameter is described as a Pip Object. A Pip Object is nothing more than a number space used to unambiguously identify a new parameter type, and a character string that describes it [9]. Thus, the new parameter set is described as a list of Pip Objects, and the bit locations in the HD/RC that each Pip Object occupies. The organization that defines the parameter set submits it for an official Contents field value. (It would be submitted to the standards body that has authority over Pip, currently the IAB.) If the new parameter set is approved, it is given a Contents value, and that value is published in a well known place (an RFC). Of course, network administrators are free to install or not install the new parameter set in their hosts and routers. In the case of a new RC parameter set, installation of the new parameter set does not necessarily require any new software, because any Pip routing protocol, such as IDRP/MLPV, is able to find routes according to the Francis [Page 49]
RFC 1621 Pip Near-term Architecture May 1994 new parameter set by appropriate configuration of routers. In the case of a new HD parameter set, however, new software is necessary--to execute the new handling. For new HD and RC parameters sets, systems that do not understand the new parameter set can still be configured to execute one of several default actions on the new parameter. These default action allow for some control over how new functions are introduced into Pip systems. The default actions are: 1. Ignore the unknown parameter, 2. Set unknown parameter to all 0's, 3. Set unknown parameter to all 1's, 4. Silently discard packet, 5. Discard packet with PCMP Parameter Unknown. Action 1 is used when it doesn't much matter if previous systems on a path have acted on the parameter or not. Actions 2 and 3 are used when systems should know whether a previous system has not understood the parameter. Actions 4 and 5 are used when something bad happens if not all systems understand the new parameter. 16.1.1 Options Evolution The evolution of Options is very similar to that of the HD and RC. Associated with the Options is an Options Present field that indicates in a single word which of up to 8 options are present in the Options Part. There is a Contents field associated with the Options Present field that indicates which subset of all possible options the Options Present field refers to. Contents field values are assigned in the same way as for the HD and RC Contents fields. The same 5 default actions used for the HD and RC also apply to the Options. Francis [Page 50]
RFC 1621 Pip Near-term Architecture May 1994 References [1] Thomson, F., "Use of DNS with Pip", Work in Progress. [2] Francis, P., "Pip Header Processing", Work in Progress. [3] Pip Address Assignment Specification, Work in Progress. [4] Francis, P., "Pip Identifiers", Work in Progress. [5] Pip Assigned Numbers, Work in Progress. [6] Pip Header Protocol, Work in Progress. [7] Francis, G., "PCMP: Pip Control Message Protocol", Work in Progress. [8] Pip Router Discovery Protocol, Work in Progress. [9] Pip Objects Specification, Work in Progress. [10] Rajagopolan, and P. Francis, "The Multi-Level Path Vector Routing Scheme", Work in Progress. [11] Francis, P., "Pip Address Conventions", Work in Progress. [12] Francis, P., "On the Assignment of Provider Rooted Addresses", Work in Progress. [13] Ballardie, Francis, P., and J. Crowcroft, "Core Based Trees (CBT), An Architecture for Scalable Inter-Domain Multicast Routing", Work in Progress. [14] Franics, P., "Pip Host Operation", Work in Progress. [15] Egevang, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, Cray Communications, NTT, May 1994.

Back to RFC index





Register domain name and transfer | Cheap webhosting service | Domain name registration