home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1621.txt < prev    next >
Text File  |  1996-05-07  |  131KB  |  1,259 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         P. Francis Request for Comments: 1621                                           NTT Category: Informational                                         May 1994 
  8.  
  9.                         Pip Near-term Architecture 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo provides information for the Internet community.  This memo    does not specify an Internet standard of any kind.  Distribution of    this memo is unlimited. 
  14.  
  15. Preamble 
  16.  
  17.    During 1992 and 1993, the Pip internet protocol, developed at    Belclore, was one of the candidate replacments for IP.  In mid 1993,    Pip was merged with another candidate, the Simple Internet Protocol    (SIP), creating SIPP (SIP Plus).  While the major aspects of Pip--    particularly its distinction of identifier from address, and its use    of the source route mechanism to achieve rich routing capabilities--    were preserved, many of the ideas in Pip were not.  The purpose of    this RFC and the companion RFC "Pip Header Processing" are to record    the ideas (good and bad) of Pip. 
  18.  
  19.    This document references a number of Pip draft memos that were in    various stages of completion.  The basic ideas of those memos are    presented in this document, though many details are lost.  The very    interested reader can obtain those internet drafts by requesting them    directly from me at <francis@cactus.ntt.jp>. 
  20.  
  21.    The remainder of this document is taken verbatim from the Pip draft    memo of the same title that existed when the Pip project ended.  As    such, any text that indicates that Pip is an intended replacement for    IP should be ignored. 
  22.  
  23. Abstract 
  24.  
  25.    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. 
  26.  
  27.  
  28.  
  29.  
  30.  
  31. Francis                                                         [Page 1] 
  32.  RFC 1621               Pip Near-term Architecture               May 1994 
  33.  
  34.  Table of Contents 
  35.  
  36.    1. Pip Architecture Overview ...................................    4    1.1 Pip Architecture Characteristics ...........................    4    1.2 Components of the Pip Architecture .........................    5 
  37.  
  38.    2. A Simple Example ............................................    6 
  39.  
  40.    3. Pip Overview ................................................    7 
  41.  
  42.    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 
  43.  
  44.    5. Pip IDs .....................................................   17 
  45.  
  46.    6. Use of DNS ..................................................   18    6.1 Information Held by DNS ....................................   19    6.2 Authoritative Queries in DNS ...............................   20 
  47.  
  48.    7. Type-of-Service (TOS) (or lack thereof) .....................   21 
  49.  
  50.    8. Routing on (Hierarchical) Pip Addresses .....................   22    8.1 Exiting a Private Domain ...................................   23    8.2 Intra-domain Networking ....................................   24 
  51.  
  52.    9. Pip Header Server ...........................................   25    9.1 Forming Pip Headers ........................................   25    9.2 Pip Header Protocol (PHP) ..................................   27    9.3 Application Interface ......................................   27 
  53.  
  54.    10. Routing Algorithms in Pip ..................................   28    10.1 Routing Information Filtering .............................   29 
  55.  
  56.    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 
  57.  
  58.  
  59.  
  60.  Francis                                                         [Page 2] 
  61.  RFC 1621               Pip Near-term Architecture               May 1994 
  62.  
  63.     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 
  64.  
  65.    13. Pip Control Message Protocol (PCMP) ........................   40 
  66.  
  67.    14. Host Mobility ..............................................   42    14.1 PCMP Mobile Host message ..................................   43    14.2 Spoofing Pip IDs ..........................................   44 
  68.  
  69.    15. Public Data Network (PDN) Address Discovery ................   44    15.1 Notes on Carrying PDN Addresses in NSAPs ..................   46 
  70.  
  71.    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 
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101. Francis                                                         [Page 3] 
  102.  RFC 1621               Pip Near-term Architecture               May 1994 
  103.  
  104.  Introduction 
  105.  
  106.    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). 
  107.  
  108.    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. 
  109.  
  110. 1.  Pip Architecture Overview 
  111.  
  112.    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). 
  113.  
  114.    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.) 
  115.  
  116. 2.  Pip Architecture Characteristics 
  117.  
  118.    The proposed architecture for near-term Pip has the following    characteristics: 
  119.  
  120.    1.  Provider-rooted hierarchical addresses. 
  121.  
  122.    2.  Automatic domain-wide address prefix assignment. 
  123.  
  124.    3.  Automatic host address and ID assignment. 
  125.  
  126.  
  127.  
  128.  Francis                                                         [Page 4] 
  129.  RFC 1621               Pip Near-term Architecture               May 1994 
  130.  
  131.     4.  Exit provider selection. 
  132.  
  133.    5.  Multiple defaults routing (default routing, but to multiple exit        points). 
  134.  
  135.    6.  Equivalent of IP Class D style addressing for multicast. 
  136.  
  137.    7.  CBT style multicast. 
  138.  
  139.    8.  "Anycast" addressing (route to one of a group, usually the        nearest). 
  140.  
  141.    9.  Providers support forwarding on policy routes (but initially will        not provide the support for sources to calculate policy routes). 
  142.  
  143.    10.  Mobile hosts. 
  144.  
  145.    11.  Support for routing across large Public Data Networks (PDN). 
  146.  
  147.    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. 
  148.  
  149.    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). 
  150.  
  151.    14.  Mechanisms for evolving Pip beyond the near-term architecture. 
  152.  
  153. 1.2 Components of the Pip Architecture 
  154.  
  155.    The Pip Architecture consists of the following five systems: 
  156.  
  157.    1.  Host (source and sink of Pip packets) 
  158.  
  159.    2.  Router (forwards Pip packets) 
  160.  
  161.    3.  DNS 
  162.  
  163.    4.  Pip/IP Translator 
  164.  
  165.    5.  Pip Header Server (formats Pip headers) 
  166.  
  167.    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. 
  168.  
  169.  
  170.  
  171.  Francis                                                         [Page 5] 
  172.  RFC 1621               Pip Near-term Architecture               May 1994 
  173.  
  174.     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. 
  175.  
  176. 2.  A Simple Example 
  177.  
  178.    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.) 
  179.  
  180.    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. 
  181.  
  182.    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 
  183.  
  184.  
  185.  
  186. Francis                                                         [Page 6] 
  187.  RFC 1621               Pip Near-term Architecture               May 1994 
  188.  
  189.     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). 
  190.  
  191. 3.  Pip Overview 
  192.  
  193.    Here, a brief overview of the Pip protocol is given.  The reader is    encouraged to read [2] for a complete description. 
  194.  
  195.    The Pip header is divided into three parts: 
  196.  
  197.       Initial Part       Transit Part       Options Part 
  198.  
  199.    The Initial Part contains the following fields: 
  200.  
  201.       Version Number       Options Offset, OP Contents, Options Present (OP)       Packet SubID       Protocol       Dest ID       Source ID       Payload Length       Host Version       Payload Offset       Hop Count 
  202.  
  203.    All of the fields in the Initial Part are of fixed length.  The    Initial Part is 8 32-bit words in length. 
  204.  
  205.    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. 
  206.  
  207.    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 
  208.  
  209.  
  210.  
  211. Francis                                                         [Page 7] 
  212.  RFC 1621               Pip Near-term Architecture               May 1994 
  213.  
  214.     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. 
  215.  
  216.    The Transit Part contains the following fields: 
  217.  
  218.       Transit Part Offset       HD Contents       Handling Directive (HD)       Active FTIF       RC Contents       Routing Context (RC)       FTIF Chain (FTIF = Forwarding Table Index Field) 
  219.  
  220.    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. 
  221.  
  222.    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). 
  223.  
  224.    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. 
  225.  
  226.    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. 
  227.  
  228.    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. 
  229.  
  230.  
  231.  
  232. Francis                                                         [Page 8] 
  233.  RFC 1621               Pip Near-term Architecture               May 1994 
  234.  
  235.     This allows the definition of the Routing Context to evolve over    time. 
  236.  
  237.    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. 
  238.  
  239. 4.  Pip Addressing 
  240.  
  241.    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. 
  242.  
  243.    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). 
  244.  
  245.    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: 
  246.  
  247.       Value      Address Family       -----      --------------        00        Hierarchical Unicast Pip Address        01        Class D Style Multicast Address        10        CBT Style Multicast Address        11        Anycast Pip Address 
  248.  
  249.    The remaining bits are defined differently for different address    families, and are defined in the following sections. 
  250.  
  251. 4.1  Hierarchical Pip Addressing 
  252.  
  253.    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. 
  254.  
  255.  
  256.  
  257.  Francis                                                         [Page 9] 
  258.  RFC 1621               Pip Near-term Architecture               May 1994 
  259.  
  260.     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. 
  261.  
  262.    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. 
  263.  
  264.    The RC for (hierarchical) Pip Addresses is defined as: 
  265.  
  266.       bits       meaning       ----       -------       0,1        Pip Address (= 00)       2,3        level       4,5        metalevel       6          exit routing type 
  267.  
  268.    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). 
  269.  
  270.    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. 
  271.  
  272.  
  273.  
  274.  
  275.  
  276. Francis                                                        [Page 10] 
  277.  RFC 1621               Pip Near-term Architecture               May 1994 
  278.  
  279.     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. 
  280.  
  281.    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. 
  282.  
  283.    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). 
  284.  
  285.    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].) 
  286.  
  287.    Thus, the basic form of a Pip address is: 
  288.  
  289.          providerPart,subscriberPart 
  290.  
  291.    where both the providerPart and subscriberPart can have multiple    layers of hierarchy internally. 
  292.  
  293.    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: 
  294.  
  295.          providerPart1,subscriberPart          providerPart2,subscriberPart          providerPart3,subscriberPart 
  296.  
  297.    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). 
  298.  
  299.  
  300.  
  301.  Francis                                                        [Page 11] 
  302.  RFC 1621               Pip Near-term Architecture               May 1994 
  303.  
  304.     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. 
  305.  
  306.    Top-level Pip numbers can be assigned to subscriber networks as well    as to providers. 
  307.  
  308.          privatePart,subscriberPart 
  309.  
  310.    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. 
  311.  
  312.    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. 
  313.  
  314.          longDistanceProvider.localAccessProvider.subscriber              (top-level)          (top-level)     (next level) 
  315.  
  316.    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. 
  317.  
  318.    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. 
  319.  
  320. 4.1.1  Assignment of (Hierarchical) Pip Addresses 
  321.  
  322.    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.) 
  323.  
  324.  
  325.  
  326. Francis                                                        [Page 12] 
  327.  RFC 1621               Pip Near-term Architecture               May 1994 
  328.  
  329.     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. 
  330.  
  331.    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. 
  332.  
  333.    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. 
  334.  
  335.    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 
  336.  
  337.  
  338.  
  339. Francis                                                        [Page 13] 
  340.  RFC 1621               Pip Near-term Architecture               May 1994 
  341.  
  342.     level of routing, thus mitigating the scaling problem at that level. 
  343.  
  344.    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. 
  345.  
  346. 4.1.2  Host Addressing 
  347.  
  348.    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. 
  349.  
  350.    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. 
  351.  
  352.    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.) 
  353.  
  354.    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. 
  355.  
  356.    (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 
  357.  
  358.  
  359.  
  360. Francis                                                        [Page 14] 
  361.  RFC 1621               Pip Near-term Architecture               May 1994 
  362.  
  363.     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.) 
  364.  
  365.    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. 
  366.  
  367. 4.2  CBT Style Multicast Addresses 
  368.  
  369.    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: 
  370.  
  371.        bits       meaning       ----       -------       0,1        CBT Multicast (= 10)       2,3        level       4,5        metalevel       6          exit routing type       7          on-tree bit       8,9        scoping 
  372.  
  373.     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. 
  374.  
  375.    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. 
  376.  
  377.    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. 
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  Francis                                                        [Page 15] 
  384.  RFC 1621               Pip Near-term Architecture               May 1994 
  385.  
  386.     Once the packet reaches the multicast tree, it switches to multicast    routing by changing the on-tree bit to 1 and using the Dest ID group    address for forwarding.  During this phase, bits 2-6 are ignored. 
  387.  
  388. 4.3  Class D Style Multicast Addresses 
  389.  
  390.    When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01,    the FTIF and Dest ID indicate Class D style multicast.  The remainder    of the RC is defined as: 
  391.  
  392.        bits       meaning       ----       -------       0,1        Class D Style Multicast (= 01)       2-5        Scoping 
  393.  
  394.     By "class D" style multicast, we mean multicast using the algorithms    developed for use with Class D addresses in IP (class D addresses are    not used per se).  This style of routing uses both source and    destination information to route the packet (source host address and    destination multicast group). 
  395.  
  396.    For Pip, the FTIF Chain holds the source Pip Address, in order of    most significant hierarchy level first.  The reason for putting the    source Pip Address rather than the Source ID in the FTIF Chain is    that use of the source Pip Address allows the multicast routing to    take advantage of the hierarchical source address, as is being done    with IP.  The Dest ID field holds the multicast group.  The Routing    Context indicates Class-D style multicast.  All routers must first    look at the FTIF Chain and Dest ID field to route the packet on the    tree. 
  397.  
  398.    Bits 2 through 5 of the RC are the scoping bits. 
  399.  
  400. 4.4  Anycast Addressing 
  401.  
  402.    When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11,    the FTIF and Dest ID indicate Anycast addressing.  The remainder of    the RC is defined as: 
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414. Francis                                                        [Page 16] 
  415.  RFC 1621               Pip Near-term Architecture               May 1994 
  416.  
  417.        bits       meaning       ----       -------       0,1        Anycast Address (= 11)       2,3        level       4,5        metalevel       6          exit routing type       7          anycast active       8,9        scoping 
  418.  
  419.     With anycast routing, the packet is unicast, but to the nearest of a    group of destinations.  This type of routing is used by Pip for    autoconfiguration.  Other applications, such as discovery protocols,    may also use anycast routing. 
  420.  
  421.    Like CBT, Pip anycast has two phases of operation, in this case the    unicast phase and the anycast phase.  The unicast phase is for the    purpose of getting the packet into a certain vicinity.  The anycast    phase is to forward the packet to the nearest of a group of    destinations in that vicinity. 
  422.  
  423.    Thus, the RC has both unicast and anycast information in it.  During    the unicast phase, the anycast active bit is set to 0, and the packet    is forwarded according to the rules of Pip Addressing.  The scoping    bits are ignored. 
  424.  
  425.    The switch from the unicast phase to the anycast phase is triggered    by the presence of an FTIF of value 1 in the FTIF Chain.  When this    FTIF is reached, the anycast active bit is set to 1, the scoping bits    take effect, and bits 2 through 6 are ignored.  When in the anycast    phase, forwarding is based on the Dest ID field. 
  426.  
  427. 5.  Pip IDs 
  428.  
  429.    The Pip ID is 64-bits in length [4]. 
  430.  
  431.    The basic role of the Pip ID is to identify the source and    destination host of a Pip Packet.  (The other role of the Pip ID is    for allowing a router to find the destination host on the destination    subnetwork.) 
  432.  
  433.    This having been said, it is possible for the Pip ID to ultimately    identify something in addition to the host.  For instance, the Pip ID    could identify a user or a process.  For this to work, however, the    Pip ID has to be bound to the host, so that as far as the Pip layer    is concerned, the ID is that of the host.  Any additional use of the    Pip ID is outside the scope of this Pip architecture. 
  434.  
  435.  
  436.  
  437.  Francis                                                        [Page 17] 
  438.  RFC 1621               Pip Near-term Architecture               May 1994 
  439.  
  440.     The Pip ID is treated as flat.  When a host receives a Pip packet, it    compares the destination Pip ID in the Pip header with its' own.  If    there is a complete match, then the packet has reached the correct    destination, and is sent to the higher layer protocol.  If there is    not a complete match, then the packet is discarded, and a PCMP    Invalid Address packet is returned to the originator of the packet    [7]. 
  441.  
  442.    It is something of an open issue as to whether or not Pip IDs should    contain significant organizational hierarchy information.  Such    information could be used for inverse DNS lookups and allowing a Pip    packet to be associated with an organization.  (Note that the use of    the Pip ID alone for this purpose can be easily spoofed.  By cross    checking the Pip ID with the Pip Address prefix, spoofing is harder-    -as hard as it is with IP--but still easy.  Section 14.2 discusses    methods for making spoofing harder still, without requiring    encryption.) 
  443.  
  444.    However, relying on organizational information in the Pip header    generally complicates ID assignment.  This complication has several    ramifications.  It makes host autoconfiguration of hosts harder,    because hosts then have to obtain an assignment from some database    somewhere (versus creating one locally from an IEEE 802 address, for    instance).  It means that a host has to get a new assignment if it    changes organizations.  It is not clear what the ramifications of    this might be in the case of a mobile host moving through different    organizations. 
  445.  
  446.    Because of these difficulties, the use of flat Pip IDs is currently    favored. 
  447.  
  448.    Blocks of Pip ID numbers have been reserved for existing numbering    spaces, such as IP, IEEE 802, and E.164.  Pip ID numbers have been    assigned for such special purposes such as "any host", "any router",    "all hosts on a subnetwork", "all routers on a subnetwork", and so    on.  Finally, 32-bit blocks of Pip ID numbers have been reserved for    each country, according to ISO 3166 country code assignments. 
  449.  
  450. 6.  Use of DNS 
  451.  
  452.    The Pip near-term architecture uses DNS in roughly the same style    that it is currently used.  In particular, the Pip architecture    maintains the two fundamental DNS characteristics of 1) information    stored in DNS does not change often, and 2) the information returned    by DNS is independent of who requested it. 
  453.  
  454.    While the fundamental use of DNS remains roughly the same, Pip's use    of DNS differs from IP's use by degrees.  First, Pip relies on DNS to 
  455.  
  456.  
  457.  
  458. Francis                                                        [Page 18] 
  459.  RFC 1621               Pip Near-term Architecture               May 1994 
  460.  
  461.     hold more types of information than IP [1].  Second, Pip Addresses in    DNS are expected to change more often than IP addresses, due to    reassignment of Pip Address prefixes (the providerPart).  To still    allow aggressive caching of DNS records in the face of more quickly    changing addressing, Pip has a mechanism of indicating to hosts when    an address is no longer assigned.  This triggers an authoritative    query, which overrides DNS caches.  The mechanism consists of PCMP    Packet Not Delivered messages that indicate explicitly that the Pip    Address is invalid. 
  462.  
  463.    In what follows, we first discuss the information contained in DNS,    and then discuss authoritative queries. 
  464.  
  465. 6.1  Information Held by DNS 
  466.  
  467.    The information contained in DNS for the Pip architecture is: 
  468.  
  469.    1.  The Pip ID. 
  470.  
  471.    2.  Multiple Pip Addresses 
  472.  
  473.    3.  The destination's mobile host address servers. 
  474.  
  475.    4.  The Public Data Network (PDN) addresses through which the        destination can be reached. 
  476.  
  477.    5.  The Pip/IP Translators through which the destination (if the        destination is IP-only) can be reached. 
  478.  
  479.    6.  Information about the providers represented by the destination's        Pip addresses.  This information includes provider name, the type        of provider network (such as SMDS, ATM, or SIP), and access        restrictions on the provider's network. 
  480.  
  481.    The Pip ID and Addresses are the basic units of information required    for carriage of a Pip packet. 
  482.  
  483.    The mobile host address server tells where to send queries for the    current address of a mobile Pip host. Note that usually the current    address of the mobile host is conveyed by the mobile host itself,    thus a mobile host server query is not usually required. 
  484.  
  485.    The PDN address is used by the entry router of a PDN to learn the PDN    address of the next hop router.  The entry router obtains the PDN    address via an option in the Pip packet.  If there are multiple PDNs    associated with a given Pip Address, then there can be multiple PDN    addresses carried in the option.  Note that the option is not sent on    every packet, and that only the PDN entry router need examine the 
  486.  
  487.  
  488.  
  489. Francis                                                        [Page 19] 
  490.  RFC 1621               Pip Near-term Architecture               May 1994 
  491.  
  492.     option. 
  493.  
  494.    The Pip/IP translator information is used to know how to translate an    IP address into a Pip Address so that the packet can be carried    across the Pip infrastructure.  If the originating host is IP, then    the first IP/Pip translator reached by the IP packet must query DNS    for this information. 
  495.  
  496.    The information about the destination's providers is used to help the    "source" (either the source host or a Pip Header Server near the    source host) format an appropriate Pip header with regards to    choosing a Pip Address [14].  The choice of one of multiple Pip    Addresses is essentially a policy routing choice. 
  497.  
  498.    More detailed descriptions of the use of the information carried in    DNS is contained in the relevant sections. 
  499.  
  500. 6.2 Authoritative Queries in DNS 
  501.  
  502.    In general, Pip treats addresses as more dynamic entities than does    IP.  One example of this is how Pip Address prefixes change when a    subscriber network attaches to a new provider.  Pip also carries more    information in DNS, any of which can change for various reasons.    Thus, the information in DNS is more dynamic with Pip than with IP. 
  503.  
  504.    Because of the increased reliance on DNS, there is a danger of    increasing the load on DNS.  This would be particularly true if the    means of increasing DNS' dynamicity is by shortening the cache    holding time by decreasing the DNS Time-to-Live (TTL).  To counteract    this trend, Pip provides explicit network layer (Pip layer) feedback    on the correctness of address information.  This allows Pip hosts to    selectively over-ride cached DNS information by making an    authoritative query.  Through this mechanism, we actually hope to    increase the cache holding time of DNS, thus improving DNS' scaling    characteristics overall. 
  505.  
  506.    The network layer feedback is in the form of a type of PCMP Packet    Not Delivered (PDN) message that indicates that the address used is    known to be out-of-date.  Routers can be configured with this    information, or it can be provided through the routing algorithm    (when an address is decommissioned, the routing algorithm can    indicate that this is the reason that it has become unreachable, as    opposed to becoming "temporarily" unreachable through equipment    failure). 
  507.  
  508.    Pip hosts consider destination addresses to be in one of four states: 
  509.  
  510.  
  511.  
  512.  
  513.  
  514. Francis                                                        [Page 20] 
  515.  RFC 1621               Pip Near-term Architecture               May 1994 
  516.  
  517.     1.  Unknown, but assumed to be valid. 
  518.  
  519.    2.  Reachable (and therefore valid). 
  520.  
  521.    3.  Unreachable and known to be invalid. 
  522.  
  523.    4.  Unreachable, but weakly assumed to be valid. 
  524.  
  525.    The first state exists before a host has attempted communication with    another host.  In this state, the host queries DNS as normal (that    is, does not make an authoritative query). 
  526.  
  527.    The second state is reached when a host has successfully communicated    with another host.  Once a host has reached this state, it can stay    in it for an arbitrarily long time, including after the DNS TTL has    expired.  When in this state, there is no need to query DNS. 
  528.  
  529.    A host enters the third state after a failed attempt at communicating    with another host where the PCMP PND message indicates explicitly    that the address is known to be invalid.  In this case, the host    makes an authoritative query to DNS whether or not the TTL has    expired.  It is this case that allows lengthy caching of DNS    information while still allowing addresses to be reassigned    frequently. 
  530.  
  531.    A host enters the fourth state after a failed attempt at    communicating with another host, but where the address is not    explicitly known to be invalid.  In this state, the host weakly    assumes that the address of the destination is still valid, and so    can requery DNS with a normal (non-authoritative) query. 
  532.  
  533. 7.  Type-of-Service (TOS) (or lack thereof) 
  534.  
  535.    One year ago it probably would have been adequate to define a handful    (4 or 5) of priority levels to drive a simple priority FIFO queue.    With the advent of real-time services over the Internet, however,    this is no longer sufficient.  Real-time traffic cannot be handled on    the same footing as non-real-time.  In particular, real-time traffic    must be subject to access control so that excess real-time traffic    does not swamp a link (to the detriment of other real-time and non-    real-time traffic alike). 
  536.  
  537.    Given that a consensus solution to real- and non-real-time traffic    management in the internet does not exist, this version of the Pip    near-term architecture does not specify any classes of service (and    related queueing mechanisms).  It is expected that Pip will define    classes of service (primarily for use in the Handling Directive) as    solutions become available. 
  538.  
  539.  
  540.  
  541. Francis                                                        [Page 21] 
  542.  RFC 1621               Pip Near-term Architecture               May 1994 
  543.  
  544.  8.  Routing on (Hierarchical) Pip Addresses 
  545.  
  546.    Pip forwarding in a single router is done based on one or a small    number of FTIFs.  What this means with respect to hierarchical Pip    Addresses is that a Pip router is able to forward a packet based on    examining only part of the Pip Address--often a single level. 
  547.  
  548.    One advantage to encoding each level of the Pip Address separately is    that it makes handling of addresses, for instance address assignment    or managing multiple addresses, easier.  Another advantage is address    lookup speed--the entire address does not have to be examined to    forward a packet (as is necessary, for instance, with traditional    hierarchical address encoding).  The cost of this, however, is    additional complexity in keeping track of the active hierarchical    level in the Pip header. 
  549.  
  550.    Since Pip Addresses allow reuse of numbers at each level of the    hierarchy, it is necessary for a Pip router to know which level of    the hierarchy it is acting at when it retrieves an FTIF.  This is    done in part with a hierarchy level indicator in the Routing Context    (RC) field.  RC level is numbered from the top of the hierarchy down.    Therefore, the top of the hierarchy is RC level = 0, the next level    down is RC level = 1, and so on. 
  551.  
  552.    The RC level alone, however, is not adequate to keep track of the    appropriate level in all cases.  This is because different parts of    the hierarchy may have different numbers of levels, and elements of    the hierarchy (such as a domain or an area) may exist in multiple    parts of the hierarchy.  Thus, a hierarchy element can be, say, level    3 under one of its parents and level 2 under another. 
  553.  
  554.    To resolve this ambiguity, the topological hierarchy is superimposed    with another set of levels--metalevels [11].  A metalevel boundary    exists wherever a hierarchy element has multiple parents with    different numbers of levels, or may with reasonable probability have    multiple parents with different numbers of levels in the future. 
  555.  
  556.    Thus, a metalevel boundary exists between a subscriber network and    its provider.  (Note that in general the metalevel represents a    significant administrative boundary between two levels of the    topological hierarchy.  It is because of this administrative boundary    that the child is likely to have multiple parents.) Lower metalevels    may exist, but usually will not. 
  557.  
  558.    The RC, then, contains a level and a metalevel indicator.  The level    indicates the number of levels from the top of the next higher    metalevel.  The top of the global hierarchy is metalevel 0, level 0.    The next level down (for instance, the level that provides a level of 
  559.  
  560.  
  561.  
  562. Francis                                                        [Page 22] 
  563.  RFC 1621               Pip Near-term Architecture               May 1994 
  564.  
  565.     hierarchy within a provider) is metalevel 0, level 1.  The first    level of hierarchy under a provider is metalevel 1, level 0, and so    on. 
  566.  
  567.    To determine the RC level and RC metalevel in a transmitted Pip    packet, a host (or Pip Header Server) must know where the metalevels    are in its own Pip Addresses. 
  568.  
  569.    The host compares its source Pip Address with the destination Pip    Address.  The highest Pip Address component that is different between    the two addresses determines the level and metalevel.  (No levels    higher than this level need be encoded in the Routing Directive.) 
  570.  
  571.    Neighbor routers are configured to know if there is a level or    metalevel boundary between them, so that they can modify the RC level    and RC metalevel in a transmitted packet appropriately. 
  572.  
  573. 8.1  Exiting a Private Domain 
  574.  
  575.    The near-term Pip Architecture provides two methods of exit routing,    that is, routing inter-domain Pip packets from a source host to a    network service provider of a private domain [12,15].  In the first    method, called transit-driven exit routing, the source host leaves    the choice of provider to the routers.  In the second method, called    host-driven exit routing, the source host explicitly chooses the    provider.  In either method, it is possible to prevent internal    routers from having to carry external routing information.  The exit    routing bit of the RC indicates which type of exit routing is in    effect. 
  576.  
  577.    With host-driven exit routing, it is possible for the host to choose    a provider through which the destination cannot be reached.  In this    case, the host receives the appropriate PCMP Packet Not Delivered    message, and may either fallback on transit-driven exit routing or    choose a different provider. 
  578.  
  579.    When using transit-driven exit routing, there are two modes of    operation.  The first, called destination-oriented, is used when the    routers internal to a domain have external routing information, and    the host has only one provider prefix.  The second, called provider-    oriented, is used when the routers internal to a domain do not have    any external routing information or when the host has multiple    provider prefixes.  (With IP, this case is called default routing.    In the case of IP, however, default routing does not allow an    intelligent choice of multiple exit points.) 
  580.  
  581.    With provider-oriented exit routing, the host arbitrarily chooses a    source Pip Address (and therefore, a provider).  (Note that if the 
  582.  
  583.  
  584.  
  585. Francis                                                        [Page 23] 
  586.  RFC 1621               Pip Near-term Architecture               May 1994 
  587.  
  588.     Pip Header Server is tracking inter-domain routing, then it chooses    the appropriate provider.) If the host chooses the wrong provider,    then the border router will redirect the host to the correct provider    with a PCMP Provider Redirect message. 
  589.  
  590. 8.2  Intra-domain Networking 
  591.  
  592.    With intra-domain networking (where both source and destination are    in the private network), there are two scenarios of concern.  In the    first, the destination address shares a providerPart with the source    address, and so the destination is known to be intra-domain even    before a packet is sent.  In the second, the destination address does    not share a providerPart with the source address, and so the source    host doesn't know that the destination is reachable intra-domain.    Note that the first case is the most common, because the private    top-level number assignment acts as the common prefix even though it    isn't advertised globally (see section 4.1). 
  593.  
  594.    In the first case, the Pip Addresses in the Routing Directive need    not contain the providerPart.  Rather, it contains only the address    part below the metalevel boundary.  (A Pip Address in an FTIF Chain    always starts at a metalevel boundary). 
  595.  
  596.    For instance, if the source Pip Address is 1.2.3,4.5.6 and the    destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be    included for the destination address in the Routing Directive.  (The    comma "," in the address indicates the metalevel boundary between    providerPart and subscriberPart.) The metalevel and level are set    accordingly. 
  597.  
  598.    In the second case, it is desirable to use the Pip Header Server to    determine if the destination is intra-domain or inter-domain.  The    Pip Header Server can do this by monitoring intra-domain routing.    (This is done by having the Pip Header Server run the intra-domain    routing algorithm, but not advertise any destinations.) Thus, the Pip    Header Server can determine if the providerPart can be eliminated    from the address, as described in the last paragraph, or cannot and    must conform to the rules of exit routing as described in the    previous section. 
  599.  
  600.    If the Pip Header Server does not monitor intra-domain routing,    however, then the following actions occur.  In the case of host-    driven exit routing, the packet will be routed to the stated    provider, and an external path will be used to reach an internal    destination.  (The moral here is to not use host-driven exit routing    unless the Pip Header Server is privy to routing information, both    internal and external.) 
  601.  
  602.  
  603.  
  604.  Francis                                                        [Page 24] 
  605.  RFC 1621               Pip Near-term Architecture               May 1994 
  606.  
  607.     In the case of transit-driven exit routing, the packet sent by the    host will eventually reach a router that knows that the destination    is intra-domain.  This router will forward the packet towards the    destination, and at the same time send a PCMP Reformat Transit Part    message to the host.  This message tells the host how much of the Pip    Address is needed to route the packet. 
  608.  
  609. 9.  Pip Header Server 
  610.  
  611.    Two new components of the Pip Architecture are the Pip/IP Translator    and the Pip Header Server.  The Pip/IP Translator is only used for    transition from IP to Pip, and otherwise would not be necessary.  The    Pip Header Server, however, is a new architectural component. 
  612.  
  613.    The purpose of the Pip Header Server is to form a Pip Header.  It is    useful to form the Pip header in a separate box because 1) in the    future (as policy routing matures, for instance), significant amounts    of information may be needed to form the Pip header--too much    information to distribute to all hosts, and 2) it won't be possible    to evolve all hosts at the same time, so the existence of a separate    box that can spoon-feed Pip headers to old hosts is necessary.  (It    is impossible to guarantee that no modification of Pip hosts is    necessary for any potential evolution, but being able to form the    header in a server, and hand it to an outdated host, is a large step    in the right direction.) 
  614.  
  615.    (Note that policy routing architectures commonly if not universally    require the use of some kind of "route server" for calculating policy    routes.  The Pip Header Server is, among other things, just this    server.  Thus, the Pip Header Server does not so much result from the    fact that Pip itself is more complex than IP or other "IPv7"    proposals.  Rather, the Pip Header Server reflects the fact that the    Pip Architecture has more functionality than ROAD architectures    supported by the simpler proposals.) 
  616.  
  617.    We note that for the near-term architecture hosts themselves will    by-and-large have the capability of forming Pip headers.  The    exception to this will be the case where the Pip Header Server wishes    to monitor inter-domain routing to enhance provider selection.  Thus,    the Pip Header Server role will be largely limited to evolution (see    section 16). 
  618.  
  619. 9.1  Forming Pip Headers 
  620.  
  621.    Forming a Pip header is more complex than forming an IP header    because there are many more choices to make.  At a minimum, one of    multiple Pip Addresses (both source and destination) must be chosen    [14].  In the near future, it will also be necessary to choose a TOS. 
  622.  
  623.  
  624.  
  625. Francis                                                        [Page 25] 
  626.  RFC 1621               Pip Near-term Architecture               May 1994 
  627.  
  628.     After DNS information about the destination has been received, the    the following information is available to the Pip header formation    function. 
  629.  
  630.    1.  From DNS: The destination's providers (either directly connected        or nearby enough to justify making a policy decision about), and        the names, types, and access restrictions of those providers. 
  631.  
  632.    2.  From the source host: The application type (and thus, the desired        service), and the user access restriction classes. 
  633.  
  634.    3.  From local configuration: The source's providers, and the names,        types, and access restrictions of those providers. 
  635.  
  636.    4.  Optionally from inter-domain routing: The routes chosen by        inter-domain to all top level providers.  (Note that inter-domain        routing in the Pip near-term architecture is path-vector.        Because of this, the Pip Header Server does not obtain enough        information from inter-domain routing to form a policy route.        When the technology to do this matures, it can be installed into        Pip Header Servers.) 
  637.  
  638.        The inter-domain routing information is optional.  If it is used,        then probably a Pip Header Server is necessary, to limit this        information to a small number of systems. 
  639.  
  640.    There may also be arbitrary policy information available to the Pip    header formation function.  This architecture does not specify any    such information. 
  641.  
  642.    The Pip header formation function then goes through a process of    forming an ordered list of source/destination Pip Addresses to use.    The ordering is based on knowledge of the application service    requirements, the service provided by the source providers, guesses    or learned information about the service provided by the destination    providers or by source/destination provider pairs, and the cost of    using source providers to reach destination providers.  It is assumed    that the sophistication of forming the ordered list will grow as    experienced is gained with internet commercialization and real-time    services. 
  643.  
  644.    The Pip Header formation function then returns the ordered pairs of    source and destination addresses to the source host in the PHP    response message, along with an indication of what kind of exit    routing to use with each pair.  Any additional information, such as    PDN Address, is also returned.  With this information, the source    host can now establish communications and properly respond to PCMP    messages.  Based on information received from PCMP messages, 
  645.  
  646.  
  647.  
  648. Francis                                                        [Page 26] 
  649.  RFC 1621               Pip Near-term Architecture               May 1994 
  650.  
  651.     particularly PCMP Packet Not Delivered messages but also Mobile Host    messages, the host is able to choose appropriately from the ordered    list. 
  652.  
  653.    Note that if Pip evolves to the point where the Transit Part of the    Pip header is no longer compatible with the current Transit Part, and    the querying host has not been updated to understand the new Transit    Part, then the PHP response message contains a bit map of the Transit    Part.  The host puts this bit map into the Transit Part of the    transmitted Pip header even though it does not understand the    semantics of the Transit Part.  The Host Version field indicates to    the Pip Header Server what kinds of transit parts the host can    understand. 
  654.  
  655. 9.2  Pip Header Protocol (PHP) 
  656.  
  657.    The Pip Header Protocol (PHP) is a simple query/response protocol    used to exchange information between the Pip host and the Pip Header    Server [6].  In the query, the Pip host includes (among other things)    the domain name of the destination it wishes to send Pip packets to.    (Thus, the PHP query serves as a substitute for the DNS query.) 
  658.  
  659.    The PHP query also contains 1) User Access Restriction Classes, 2)    Application Types, and 3) host version.  The host version tells the    Pip Header Server what features are installed in the host.  Thus, the    Pip Header Server is able to determine if the host can format its own    Pip header based on DNS information, or whether the Pip Header Server    needs to do it on behalf of the host.  In the future, the PHP query    will also contain desired TOS (possibly in lieu of Application Type).    (Note that this information could come from the application.  Thus,    the application interface to PHP (the equivalent of gethostbyname())    must pass this information.) 
  660.  
  661. 9.3  Application Interface 
  662.  
  663.    In order for a Pip host to generate the information required in the    PHP query, there must be a way for the application to convey the    information to the PHP software.  The host architecture for doing    this is as follows. 
  664.  
  665.    A local "Pip Header Client" (the source host analog to the Pip Header    Server) is called by the application (instead of the current    gethostbyname()).  The application provides the Pip Header Client    with either the destination host domain name or the destination host    Pip ID, and other pertinent information such as user access    restriction class and TOS.  The Pip Header Client, if it doesn't have    the information cached locally, queries the Pip Header Server and    receives an answer.  (Remember that the Pip Header Server can be co- 
  666.  
  667.  
  668.  
  669. Francis                                                        [Page 27] 
  670.  RFC 1621               Pip Near-term Architecture               May 1994 
  671.  
  672.     resident with the host.) 
  673.  
  674.    Once the Pip Header Client has determined what the Pip header(s) are,    it assigns a local handle to the headers, returns the handle to the    application, and configures the Pip packet processing engine with the    handle and related Pip Headers.  The application then issues packets    to the Pip layer (via intervening layers such as transport) using the    local handle. 
  675.  
  676. 10.  Routing Algorithms in Pip 
  677.  
  678.    This section discusses the routing algorithm for use with    (hierarchical) Pip Addresses. 
  679.  
  680.    The architecture for operating routing algorithms in Pip reflects the    clean partitioning of routing contexts in the Pip header.  Thus,    routing in the Pip architecture is nicely modularized. 
  681.  
  682.    Within the Hierarchical Pip Address, there are multiple hierarchical    levels.  Wherever two routers connect, or two levels interface    (either in a single router or between routers), two decisions must be    made:  1) what information should be exchanged (that is, what of one    side's routing table should be propagated to the other side), and 2)    what routing algorithm should be used to exchange the information?    The first decision is discussed in section 10.1 below (Routing    Information Filtering).  The latter decision is discussed here. 
  683.  
  684.    Conceptually, and to a large extent in practice, the routing    algorithms at each level are cleanly partitioned.  This partition is    much like the partition between "egp" and "igp" level routing in IP,    but with Pip it exists at each level of the hierarchy. 
  685.  
  686.    At the top-level of the Pip Address hierarchy, a path-vector routing    algorithm is used.  Path-vector is more appropriate at the top level    than link-state because path-vector does not require agreement    between top-level entities (providers) on metrics in order to be    loop-free.  (Agreement between the providers is likely to result in    better paths, but the Pip Architecture does not assume such    agreement.) 
  687.  
  688.    The top-level path-vector routing algorithm is based on IDRP, but    enhanced to handle Pip addresses and Pip idiosyncrasies such as the    Routing Context.  At any level below the top level, it is a local    decision as to what routing algorithm technology to run.  However,    the path-vector routing algorithm is generalized so that it can run    at multiple levels of the Pip Address hierarchy.  Thus, a lower level    domain can choose to take advantage of the path-vector algorithm, or    run another, such as a link-state algorithm.  The modified version of 
  689.  
  690.  
  691.  
  692. Francis                                                        [Page 28] 
  693.  RFC 1621               Pip Near-term Architecture               May 1994 
  694.  
  695.     IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced    "milpiv"). 
  696.  
  697.    Normally, information is exchanged between two separate routing    algorithms by virtue of the two algorithms co-existing in the same    router.  For instance, a border router is likely to participate in an    exchange of routing information with provider routers, and still run    the routing algorithm of the internal routers.  If the two algorithms    are different routing technologies (for instance, link-state versus    distance-vector) then internal conversion translates information from    one routing algorithm to the form of the other. 
  698.  
  699.    In some cases, however, two routing algorithms that exchange    information will exist in different routers, and will have to    exchange information over a link.  If these two algorithms are    different technologies, then they need a common means of exchanging    routing information.  While strictly speaking this is a local matter,    MLPV can also serve as the interface between two disparate routing    algorithms.  Thus, all routers should be able to run MLPV, if for no    other reason than to exchange information with other, perhaps    proprietary, routing protocols. 
  700.  
  701.    MLPV is designed to be extendible with regards to the type of routes    that it calculates.  It uses the Pip Object parameter identification    number space to identify what type of route is being advertised and    calculated [9].  Thus, to add new types of routes (for instance, new    types of service), it is only necessary to configure the routers to    accept the new route type, define metrics for that type, and criteria    for preferring one route of that type over another. 
  702.  
  703. 10.1  Routing Information Filtering 
  704.  
  705.    Of course, the main point behind having hierarchical routing is so    that information from one part of the hierarchy can be reduced when    passed to another.  In general, reduction (in the form of    aggregation) takes place when passing information from the bottom of    the hierarchy up.  However, Pip uses tunneling and exit routing to,    if desired, allow information from the top to be reduced when it goes    down. 
  706.  
  707.    When two routers become neighbors, they can determine what    hierarchical levels they have in common by comparing Pip Addresses.    For instance, if two neighbor routers have Pip Addresses 1.2.3,4 and    1.2.8,9.14 respectively, then they share levels 0 and 1, and are    different at levels below that.  (0 is the highest level, 1 is the    next highest, and so on.) As a general rule, these two routers    exchange level 0, level 1, and level 2 routing information, but not    level 3 or lower routing information.  In other words, both routers 
  708.  
  709.  
  710.  
  711. Francis                                                        [Page 29] 
  712.  RFC 1621               Pip Near-term Architecture               May 1994 
  713.  
  714.     know how to route to all things at the top level (level 0), how to    route to all level 1 things with "1" as the level 0 prefix, and how    to route to all level 2 things with "1.2" as the level 1 prefix. 
  715.  
  716.    In the absence of other instructions, two routers will by default    exchange information about all levels from the top down to the first    level at which they have differing Pip Addresses.  In practice,    however, this default exchange is as likely to be followed as not.    For instance, assume that 1.2.3,4 is a provider router, and    1.2.8,9.14 is a subscriber router.  (Note that 1.2.8 is the prefix    given the subscriber by the provider, thus the metalevel boundary    indicated by the comma.) Assume also that the subscriber network is    using destination-oriented transit-driven exit routing (see section    8.1).  Finally, assume that router 1.2.8,9.14 is the subscriber's    only entry point into provider 1 (other routers provide entry points    to other providers). 
  717.  
  718.    In this case, 1.2.8,9.14 does not need to know about level 2 or level    1 areas in the provider (that is, it does not need to know about    1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on).  Thus, 1.2.8,9.14    should be configured to inform 1.2.3,4 that it does not need level 1    or 2 information. 
  719.  
  720.    As another example, assume still that 1.2.3,4 is a provider and    1.2.8,9.14 is a subscriber.  However, assume now that the subscriber    network is using host-driven exit routing.  In this case, the    subscriber does not even need to know about level 0 information,    because all exit routing is directed to the provider of choice, and    having level 0 information therefore does not influence that choice. 
  721.  
  722. 11.  Transition 
  723.  
  724.    The transition scheme for Pip has two major components, 1)    translation, and 2) encapsulation.  Translation is required to map    the Pip Address into the IP address and vice versa.  Encapsulation is    used for one Pip router (or host) to exchange packets with another    Pip router (or host) by tunneling through intermediate IP routers. 
  725.  
  726.    The Pip transition scheme is basically a set of techniques that    allows existing IP "stuff" and Pip to coexist, but within the    limitations of IP address depletion (though not within the    limitations of IP scaling problems).  By this I mean that an IP-only    host can only exchange packets with other hosts in a domain where IP    numbers are unique.  Initially this domain includes all IP hosts, but    eventually will include only hosts within a private domain.  The IP    "stuff" that can exist includes 1) whole IP domains, 2) individual IP    hosts, 3) IP-oriented TCPs, and 4) IP-oriented applications. 
  727.  
  728.  
  729.  
  730.  Francis                                                        [Page 30] 
  731.  RFC 1621               Pip Near-term Architecture               May 1994 
  732.  
  733.  11.1  Justification for Pip Transition Scheme 
  734.  
  735.    Note that all transition to a bigger address require translation.  It    cannot be avoided.  The major choices one must make when deciding on    a translation scheme are: 
  736.  
  737.    1.  Will we require a contiguous infrastructure consisting of the new        protocol, or will we allow tunneling through whatever remains of        the existing IP infrastructure at any point in time? 
  738.  
  739.    2.  Will we allow global connectivity between IP machines after IP        addresses are no longer globally unique, or not?  (In other words,        will we use a NAT scheme or not? [15]) 
  740.  
  741.    Concerning question number 1; while it is desirable to move as    quickly as possible to a contiguous Pip (or SIP or whatever)    infrastructure, especially for purposes of improved scaling, it is    fantasy to think that the whole infrastructure will cut over to Pip    quickly.  Furthermore, during the testing stages of Pip, it is highly    desirable to be able to install Pip in any box anywhere, and by    tunneling through IP, create a virtual Pip internet.  Thus, it seems    that the only reasonable answer to question number 1 is to allow    tunneling. 
  742.  
  743.    Concerning question number 2; it is highly desirable to avoid using a    NAT scheme.  A NAT (Network Address Translation) scheme is one    whereby any two IP hosts can communicate, even though IP addresses    are not globally unique.  This is done by dynamically mapping non-    unique IP addresses into unique ones in order to cross the    infrastructure.  NAT schemes have the problems of increased    complexity to maintain the mappings, and of translating IP addresses    that reside within application data structures (such as the PORT    command in FTP). 
  744.  
  745.    This having been said, it is conceivable that the new protocol will    not be far enough along when IP addresses are no longer unique, and    therefore a NAT scheme becomes necessary.  It is possible to employ a    NAT scheme at any time in the future without making it part of the    intended transition scheme now.  Thus, we can plan for a NATless    transition now without preventing the potential use of NAT if it    becomes necessary. 
  746.  
  747. 11.2  Architecture for Pip Transition Scheme 
  748.  
  749.    The architecture for Pip Transition is that of a Pip infrastructure    surrounded by IP-only "systems".  The IP-only "systems" surrounding    Pip can be whole IP domains, individual IP hosts, an old TCP in an    otherwise Pip host, or an old application running on top of a Pip- 
  750.  
  751.  
  752.  
  753. Francis                                                        [Page 31] 
  754.  RFC 1621               Pip Near-term Architecture               May 1994 
  755.  
  756.     smart TCP. 
  757.  
  758.    The Pip infrastructure will initially get its internal connectivity    by tunneling through IP.  Thus, any Pip box can be installed    anywhere, and become part of the Pip infrastructure by configuration    over a "virtual" IP.  Of course, it is desirable that Pip boxes be    directly connected to other Pip boxes, but very early on this is the    exception rather than the rule. 
  759.  
  760.    Two neighbor Pip systems tunneling through IP simply view IP as a    "link layer" protocol, and encapsulate Pip over IP just as they would    encapsulate Pip over any other link layer protocol.  In particular,    the hop-count field of Pip is not copied into the Time-to-Live field    of IP.  There is no automatic configuration of neighbor Pip systems    over IP.  Manual configuration (and careful "virtual topology"    engineering) is required.  Note that ICMP messages from a IP router    in a tunnel is not translated into a PCMP message and sent on.  ICMP    messages are sinked at the translating router at the head of the    tunnel.  The information learned from such ICMP messages, however,    may be used to determine unreachability of the other end of the    tunnel, and may there result in PCMP message on later packets. 
  761.  
  762.    In the remainder of this section, we do not distinguish between a    virtual Pip infrastructure on IP, and a pure Pip infrastructure. 
  763.  
  764.    Given the model of a Pip infrastructure surrounded by IP, there are 5    possible packet paths: 
  765.  
  766.    1.  IP - IP 
  767.  
  768.    2.  IP - Pip - IP 
  769.  
  770.    3.  IP - Pip 
  771.  
  772.    4.  Pip - IP 
  773.  
  774.    5.  Pip - Pip 
  775.  
  776.    The first three paths involve packets that originate at IP-only    hosts.  In order for an IP host to talk to any other host (IP or    not), the other host must be addressable within the context of the IP    host's 32-bit IP address.  Initially, this "IP-unique" domain will    include all IP hosts.  When IP addresses become no longer unique, the    IP-unique domain will include a subset of all hosts.  At a minimum,    this subset will include those hosts in the IP-host's private domain.    However, it makes sense also to arrange for the set of all "public"    hosts, basically anonymous ftp servers and mail gateways, to be in    this subset.  In other words, a portion of IP address space should be 
  777.  
  778.  
  779.  
  780. Francis                                                        [Page 32] 
  781.  RFC 1621               Pip Near-term Architecture               May 1994 
  782.  
  783.     set aside to remain globally unique, even though other parts of the    address space are being reused. 
  784.  
  785. 11.3  Translation between Pip and IP packets 
  786.  
  787.    Paths 2 and 4 involve translation from Pip to IP.  This translation    is straightforward, as all the information needed to create the IP    addresses is in the Pip header.  In particular, Pip IDs have an    encoding that allows them to contain an IP address (again, one that    is unique within an IP-unique domain).  Whenever a packet path    involves an IP host on either end, both hosts must have IP addresses.    Thus, translating from Pip to IP is just a matter of extracting the    IP addresses from the Pip IDs and forming an IP header. 
  788.  
  789.    Translating from an IP header to a Pip header is more difficult,    because the 32-bit IP address must be "translated" into a 64-bit Pip    ID and a Pip Address.  There is no algorithm for making this    translation.  A table mapping IP addresses (or, rather, network    numbers) to Pip IDs and Pip Addresses is required.  Since such a    table must potentially map every IP address, we choose to use dynamic    discovery and caching to maintain the table.  We choose also to use    DNS as the means of discovering the mappings. 
  790.  
  791.    Thus, DNS contains records that map IP address to Pip ID and Pip    Address.  In the case where the host represented by the DNS record is    a Pip host (packet path 3), the Pip ID and Pip Address are those of    the host.  In the case where the host represented by the DNS record    is an IP-only host (packet paths 2 and 4), the Pip Address is that of    the Pip/IP translating gateway that is used to reach the IP host.    Thus, an IP-only domain must at least be able to return Pip    information in its DNS records (or, the parent DNS domain must be    able to do it on behalf of the child). 
  792.  
  793.    With paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating    gateway (IP to Pip) makes the DNS query.  It stores the IP packet    while waiting for the answer.  The query is an inverse address (in-    addr) using the destination IP address.  The translating gateway can    cache the record for an arbitrarily long period, because if the    mapping ever becomes invalid, a PCMP Invalid Address message flushes    the cache entry. 
  794.  
  795.    In the case of path 4 (Pip-IP), however, the Pip Address of the    translating gateway is returned directly to the source host--    piggybacked on the DNS record that is normally returned.  Thus this    scheme incurs only a small incremental cost over the normal DNS    query. 
  796.  
  797.  
  798.  
  799.  
  800.  
  801. Francis                                                        [Page 33] 
  802.  RFC 1621               Pip Near-term Architecture               May 1994 
  803.  
  804.  11.4  Translating between PCMP and ICMP 
  805.  
  806.    The only ICMP/PCMP messages that are translated are the Destination    Unreachable, Echo, and PTMU Exceeded messages.  The portion of the    offending IP/Pip header that is attached to the ICMP/PCMP message is    not translated. 
  807.  
  808. 11.5  Translating between IP and Pip Routing Information 
  809.  
  810.    It is not necessary to pass IP routing information into the Pip    infrastructure.  The mapping of IP address to Pip Address in DNS    allows Pip to find the appropriate gateway to IP in the context of    Pip addresses only. 
  811.  
  812.    It is impossible to pass Pip routing information into IP routers,    since IP routers cannot understand Pip addresses.  IP domains must    therefore use default routing to reach IP/Pip translators. 
  813.  
  814. 11.6  Old TCP and Application Binaries in Pip Hosts 
  815.  
  816.    A Pip host can be expected to have an old TCP above it for a long    time to come, and a new (Pip-smart) TCP can be expected to have old    application binaries running over it for a long time to come.  Thus,    we must have some way of insuring that the TCP checksum is correctly    calculated in the event that one or both ends is running Pip, and one    or both ends has an old TCP binary.  In addition, we must arrange to    allow applications to interface with TCP using a 32-bit "address"    only, even though those 32 bits get locally translated into Pip    Addresses and IDs. 
  817.  
  818.    As stated above, in all cases where a Pip host is talking to an IP-    only host, the Pip host has a 32-bit IP address. This address is    embedded in the Pip ID such that it can be identified as an IP    address from inspection of the Pip ID alone. 
  819.  
  820.    The TCP pseudo-header is calculated using the Payload Length and    Protocol fields, and some or all of the Source and Dest Pip IDs.  In    the case where both Source and Dest Pip IDs are IP-based, only the    32-bit IP address is included in the pseudo-header checksum    calculation.  Otherwise, the full 64 bits are used.  (Note that using    the full Payload Length and Protocol fields does not fail when old    TCP binaries are being used, because the values for those fields must    be within the 16-bit and 8-bit limits for TCP to correctly operate.) 
  821.  
  822.    The reason for only using 32 bits of the Pip ID in the case of both    ends using an IP address is that an old TCP will use only 32 bits of    some number to form the pseudo-header.  If the entire 64 bits of the    Pip ID were used, then there would be cases where no 32-bit number 
  823.  
  824.  
  825.  
  826. Francis                                                        [Page 34] 
  827.  RFC 1621               Pip Near-term Architecture               May 1994 
  828.  
  829.     could be used to insure that the correct checksum is calculated in    all cases. 
  830.  
  831.    Note that in the case of an old TCP on top of Pip, "Pip" (actually, a    Pip daemon) must create a 32-bit number that can both be used to 1)    allow the Pip layer to correctly associate a packet from the TCP    layer with the right Pip header, and 2) cause the TCP layer to    calculate the right checksum.  (This number is created when the    application initiates a DNS query.  A Pip daemon intervenes in this    request, calculates a 32 bit number that the application/TCP can use,    and informs the Pip layer of the mapping between this 32 bit number    and the full Pip header.) 
  832.  
  833.    When the destination host is an IP only host, then this 32-bit number    is nothing more than the IP address.  When the destination host is a    Pip host, then this 32-bit number is some number generated by Pip to    "fool" the old TCP into generating the right checksum.  This 32-bit    number can normally be the same as the lower 32 bits of the Pip ID.    However, it is possible that two or more active TCP connections is    established to different hosts whose Pip IDs have the same lower 32    bits.  In this case, the Pip layer must generate a different 32-bit    number for each connection, but in such a way that the sum of the two    16-bit components of the 32-bit numbers are the same as the sum of    the two 16-bit components of the lower 32 bits of the Pip IDs. 
  834.  
  835.    In the case where an old Application wants to open a socket using an    IP address handed to it (by the user or hard-coded), and not using a    domain name, then it must be assumed that this IP address is valid    within the IP-unique domain.  To form a Pip ID out of this 32-bit    number, the host appends the high-order 24 bits of its own Pip ID,    plus the IP-address-identifier-byte value, to the 32-bit IP address. 
  836.  
  837. 11.7  Translating between Pip Capable and non-Pip Capable DNS Servers 
  838.  
  839.    In addition to transitioning "Pip-layer" packets, it is necessary to    transition DNS from non-Pip capable to Pip capable.  During    transition there will be name servers in DNS that only understand IP    queries and those that understand both Pip and IP queries.  This    means there must be a mechanism for Pip resolvers to detect whether a    name server is Pip capable, and vice versa.  Also, a name server, if    it provides recursive service, must be able to translate Pip requests    to IP requests.  (Pip-capable means a name server understands Pip and    existing IP queries.  It does not necessarily mean the name server    uses the Pip protocol to communicate.) 
  840.  
  841.    New resource records have been defined to hold Pip identifiers and    addresses, and other information [1].  These resource records must be    queried using a new opcode in the DNS query packet header.  Existing 
  842.  
  843.  
  844.  
  845. Francis                                                        [Page 35] 
  846.  RFC 1621               Pip Near-term Architecture               May 1994 
  847.  
  848.     resource records can be queried using both the old and new header    formats.  Name servers that are not Pip-capable will respond with a    format error to queries with the new opcode.  Thus, a resolver can    determine dynamically whether a name server is Pip-capable, by    sending it a Pip query and noting the response.  This only need be    done once, when querying a server for the "first" time, and the    outcome can be cached along with the name server's address. 
  849.  
  850.    Using a new opcode for making Pip queries also helps name servers    determine whether a resolver is Pip-capable (it is not always not    obvious from the type of query made since many queries are common to    to IP and Pip).  Determining whether a resolver is Pip-capable is    necessary when responding with address information that is not    explicitly requested by the query.  An important example of this is    when a name server makes a referral to another name server in a    response: if the request comes from a Pip resolver, name server    addresses will be returned as Pip identifier/address resource    records, otherwise the addresses will be returned as IP A resource    records. 
  851.  
  852.    Those servers that are Pip-capable and provide recursive service must    translate Pip requests to IP requests when querying an IP name    server.  For most queries, this will just mean modifying the opcode    value in the query header to reflect an IP query, rather than a Pip    query.  (Most queries are identical in IP and Pip.) Other queries,    notably the query for Pip identifier/address information, must be    translated into its IP counterpart, namely, an IP A query.  On    receipt of an answer from an IP name server, a Pip name server must    translate the query header and question section back to its original,    and format the answer appropriately.  Again, for most queries, this    will be a trivial operation, but responses containing IP addresses,    either as a result of an explicit query or as additional information,    must be formatted to appear as a valid Pip response. 
  853.  
  854.    Pip-capable name servers that provide recursive name service should    also translate IP address requests into Pip identifier/address    requests when querying a Pip-capable name server.  (A host's IP    address can be deduced from the host's Pip identifier.) This enables    a Pip-capable name server to cache all relevant addressing    information about a Pip host in the first address query concerning    the host.  Caching partial information is undesirable since the name    server, using the current DNS caching strategy, would return only the    cached information on a future Pip request, and IP, rather than Pip,    would be used to communicate with the destination host. 
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862. Francis                                                        [Page 36] 
  863.  RFC 1621               Pip Near-term Architecture               May 1994 
  864.  
  865.  12.  Pip Address and ID Auto-configuration 
  866.  
  867.    One goal of Pip is to make networks as easy to administer as    possible, especially with regards to hosts.  Certain aspects of the    Pip architecture make administration easier.  For instance, the ID    field provides a network layer "anchor" around which address changes    can be administered. 
  868.  
  869.    This section discusses three aspects of autoconfiguration; 1)    domain-wide Pip Address prefix assignment, 2) host Pip Address    assignment, and 3) host Pip ID assignment. 
  870.  
  871. 12.1  Pip Address Prefix Administration 
  872.  
  873.    A central premise behind the use of provider-rooted hierarchical    addresses is that domain-wide address prefix assignment and re-    assignment is straight-forward.  This section describes that process. 
  874.  
  875.    Pip Address prefix administration limits required manual prefix    configuration to DNS and border routers.  This is the minimum    required manual configuration possible, because both border routers    and DNS must be configured with prefix information for other reasons.    DNS must be configured with prefix information so that it can reply    to address queries.  DNS files are structured so that the prefix is    administered in only one place (that is, every host record does not    have to be changed to create a new prefix).  Border routers must be    configured with prefix information in order to advertise exit routes    internally. 
  876.  
  877.    Note in particular that no internal (non-border) routers or hosts    need ever be manually configured with any externally derived    addressing information.  All internal routers that are expected to    fall under a common provider-prefix must, however, be configured with    a "group ID" taken from the Pip ID space.  (This group ID is not a    multicast ID per se.  Rather, it is an identifier that allows prefix    updates to be targetted to a specific set of routers.) 
  878.  
  879.    Each border router is configured with the following information. 
  880.  
  881.    1.  The type of exit routing for the domain.  This tells the border        router whether or not it needs to advertise external routes        internally. 
  882.  
  883.    2.  The address prefix of the providers that the border is directly        connected to.  This prefix information includes any metalevel        boundaries above the subscriber/provider metalevel boundary        (called simply the subscriber metalevel). 
  884.  
  885.  
  886.  
  887.  Francis                                                        [Page 37] 
  888.  RFC 1621               Pip Near-term Architecture               May 1994 
  889.  
  890.     3.  Other information about the provider (provider name, type, user        access restriction classes). 
  891.  
  892.    4.  A list of common-provider-prefix group IDs that should receive the        auto-configuration information. (The default is that only systems        that share a group ID with the border router will receive the        information.) 
  893.  
  894.    This information is injected into the intra-domain routing algorithm.    It is automatically spread to all routers indicated by the group ID    list.  This way, the default behavior is for the information to be    automatically constrained to the border router's "area". 
  895.  
  896.    When a non-border router receives this information, it 1) records the    route to the providers in its forwarding table, and 2) advertises the    information to hosts in the router discovery protocol [8].  Thus    hosts learn not only their complete address, but also information on    how to do exit routing and on how to choose source addresses. 
  897.  
  898. 12.2  Host Autoconfiguration 
  899.  
  900.    There are three phases of host autoconfiguration: 
  901.  
  902.    1.  The host locally creates a flat unique Pip ID (probably globally        unique but at least unique on the attached subnet). 
  903.  
  904.    2.  The host learns its Pip Addresses. 
  905.  
  906.    3.  The host optionally obtains a hierarchical, organizationally        meaningful Pip ID and a domain name from a Pip ID/domain name        assignment service.  This service updates DNS. 
  907.  
  908.    Item three is optional.  If Pip ID and domain name assignment    services are not installed, then the host must obtain its domain name    and, if necessary, Pip ID, from static configuration.  Each of the    three phases are described below. 
  909.  
  910. 12.2.1  Host Initial Pip ID Creation 
  911.  
  912.    When a host boots, it can form an ID based only on local information.    If the host has an IEEE 802 number, either from an IEEE 802 interface    or from an internal identifier, then it can create a globally unique    Pip ID from the IEEE 802 Pip ID type [4].  Otherwise, the host can    create an ID from the IEEE 802 space using its subnet (link layer)    address.  This latter ID is only guaranteed to be locally unique. 
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  Francis                                                        [Page 38] 
  919.  RFC 1621               Pip Near-term Architecture               May 1994 
  920.  
  921.  12.2.2  Host Pip Address Assignment 
  922.  
  923.    Unless a host does not wish to use ID-tailed Pip Addresses (see    section 4.1.2), host Pip Address assignment is trivial.  (The near-    term Pip Architecture doesn't specify a means for a host to obtain a    non-ID-tailed Pip Address.) When a host attaches to a subnet, it    learns the Pip Address of the attached routers through router    discovery. 
  924.  
  925.    The host simply adopts these Pip Addresses as its own.  The Pip    Address gets a packet to the host's subnet, and the host's Pip ID is    used to route across the subnet.  When the routers advertise new    addresses (for instance, because of a new provider), the host adopts    the new addresses. 
  926.  
  927. 12.2.3  Pip ID and Domain Name Assignment 
  928.  
  929.    Once the host has obtained its Pip Addresses and an at-least-    locally-unique Pip ID, it can exchange packets with an ID/Domain Name    (ID/DN) assignment service.  If the host locally created a globally    unique Pip ID (using an IEEE 802 number), and the organization it    belongs to does not use organizationally structured Pip IDs (which    should normally be the case) then it only needs to obtain a domain    name.  The ID/DN assignment service is reachable at a well-known    anycast address [4].  Thus, the host is able to start exchanging    packets with the ID/DN assignment service without any additional    configuration. 
  930.  
  931.    If there is no ID/DN assignment service available, then the host must    obtain it's organizational ID or DNS name in a non-automatic way.  If    the ID/DN assignment service is down, the host must temporarily    suffice with just a Pip ID and Address.  The host can periodically    try to reach the ID/DN assignment service. 
  932.  
  933.    The ID/DN assignment service must coordinate with DNS.  When the    ID/DN assignment service creates a new ID or domain name to assign to    a new host, it must know which IDs and domain names are available for    assignment.  It must also update DNS with the new information. 
  934.  
  935.    The design of this service is left for further study. 
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947. Francis                                                        [Page 39] 
  948.  RFC 1621               Pip Near-term Architecture               May 1994 
  949.  
  950.  13.  Pip Control Message Protocol (PCMP) 
  951.  
  952.    The Pip analog to ICMP is PCMP [7].  The near-term Pip architecture    defines the following PCMP messages: 
  953.  
  954.    1.  Local Redirect 
  955.  
  956.    2.  Packet Not Delivered 
  957.  
  958.    3.  Echo 
  959.  
  960.    4.  Parameter Problem 
  961.  
  962.    5.  Router Discovery 
  963.  
  964.    6.  PMTU Exceeded 
  965.  
  966.    7.  Provider Redirect 
  967.  
  968.    8.  Reformat Transit Part 
  969.  
  970.    9.  Unknown Parameter 
  971.  
  972.    10. Host Mobility 
  973.  
  974.    11. Exit PDN Address 
  975.  
  976.    The Local Redirect, Echo, and Parameter Problem PCMP messages operate    almost identically to their ICMP counterparts. 
  977.  
  978.    The Packet Not Delivered PCMP message serves the role of ICMP's    Destination Unreachable.  The Packet Not Delivered, has two major    differences.  First, it is more general in that it indicates the    hierarchy level of unreachability (rather than explicit host, subnet,    network unreachability as with IP).  Second, it indicates when an    address is known to be invalid, thus allowing for more intelligent    use of DNS (see section 6.2). 
  979.  
  980.    The Router Discovery PCMP message operates as ICMP's, with the    exception that a host derives its Pip Address from it. 
  981.  
  982.    The PMTU Exceeded message operates as ICMP's, with the exception that    the Pip header size of the offending Packet is also given.  This    allows the source host transport to determine how much smaller the    packet PMTU should be from the advertised subnet PMTU.  Note that if    an occasional option, such as the PDN Address option, needs to be    attached to one of many packets, and that this option makes the    packet larger than the PMTU, then it is not necessary to modify the 
  983.  
  984.  
  985.  
  986. Francis                                                        [Page 40] 
  987.  RFC 1621               Pip Near-term Architecture               May 1994 
  988.  
  989.     MTU coming from transport.  Instead, that packet can be fragmented by    the host's Pip forwarding engine.  (Pip specifies    fragmentation/reassembly for hosts but not for routers.  The    fragmentation information is in a Pip Option.) 
  990.  
  991.    The Provider Redirect, Invalid Address, Reformat Transit Part,    Unknown Parameter, Host Mobility, and Exit PDN Address PCMP messages    are new. 
  992.  
  993.    The Provider Redirect PCMP message is used to inform the source host    of a preferable exit provider to use when provider-rooted, transit-    driven exit routing is used (see section 8.1). 
  994.  
  995.    The Invalid Address PCMP message is used to inform the source host    that none of the IDs of the destination host match that of the Pip    packet.  The purpose of this message is to allow for authoritative    DNS requests (see section 6.2). 
  996.  
  997.    The Reformat Transit Part PCMP message has both near-term Pip    architecture functions and evolution functions.  Near-term, the    Reformat Transit Part PCMP message is used to indicate to the source    whether it has too few or too many layers of address in the Routing    Directive (see section 8.2).  Long-term, the Reformat Transit Part    PCMP message is able to arbitrarily modify the transit part    transmitted by the host, as encoded by a bit string. 
  998.  
  999.    The Unknown Parameter PCMP message is used to inform the source host    that the router does not understand a parameter in either the    Handling Directive, the Routing Context, or the Transit Options.  The    purpose of this message is to assist evolution (see section 16.1). 
  1000.  
  1001.    The Host Mobility PCMP message is sent by a host to inform another    host (for instance, the host's Mobile Address Server) that it has a    new address (see section 14).  The main use of this packet is for    host mobility, though it can be used to manage any address changes,    such as because of a new prefix assignment. 
  1002.  
  1003.    The Exit PDN Address PCMP message is used to manage the function    whereby the source host informs the PDN entry router of the PDN    Address of the exit PDN system (see section 15). 
  1004.  
  1005.    When a router needs to send a PCMP message, it sends it to the source    Pip Address.  If the Pip header is in a tunnel, then the PCMP message    is sent to the router that is the source of the tunnel.  Depending on    the situation, this may result in another PCMP message from the    source of the tunnel to the true source (for instance, if the source    of the tunnel finds that the dest of the tunnel can't be reached, it    may send a Packet Not Delivered to the source host). 
  1006.  
  1007.  
  1008.  
  1009. Francis                                                        [Page 41] 
  1010.  RFC 1621               Pip Near-term Architecture               May 1994 
  1011.  
  1012.  14.  Host Mobility 
  1013.  
  1014.    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. 
  1015.  
  1016.    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.) 
  1017.  
  1018.    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. 
  1019.  
  1020.    Pip uses the Mobile Host Server and the PCMP Host Mobility message to    manage host mobility; 
  1021.  
  1022.    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.) 
  1023.  
  1024.    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 
  1025.  
  1026.  
  1027.  
  1028. Francis                                                        [Page 42] 
  1029.  RFC 1621               Pip Near-term Architecture               May 1994 
  1030.  
  1031.     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.) 
  1032.  
  1033.    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.) 
  1034.  
  1035.    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. 
  1036.  
  1037.    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. 
  1038.  
  1039. 14.1  PCMP Mobile Host message 
  1040.  
  1041.    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. 
  1042.  
  1043.    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). 
  1044.  
  1045.    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. 
  1046.  
  1047.    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. 
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055. Francis                                                        [Page 43] 
  1056.  RFC 1621               Pip Near-term Architecture               May 1994 
  1057.  
  1058.  14.2  Spoofing Pip IDs 
  1059.  
  1060.    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. 
  1061.  
  1062.    After a host makes a DNS query, it knows: 
  1063.  
  1064.    1.  The destination host's Pip ID, 
  1065.  
  1066.    2.  The destination host's permanent Pip Addresses, and 
  1067.  
  1068.    3.  The destination host's Mobile Host Server's Pip ID and Addresses. 
  1069.  
  1070.    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. 
  1071.  
  1072.    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. 
  1073.  
  1074.    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. 
  1075.  
  1076. 15.  Public Data Network (PDN) Address Discovery 
  1077.  
  1078.    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). 
  1079.  
  1080.    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 
  1081.  
  1082.  
  1083.  
  1084. Francis                                                        [Page 44] 
  1085.  RFC 1621               Pip Near-term Architecture               May 1994 
  1086.  
  1087.     convey the exit PDN Address to the PDN entry router in a Pip option. 
  1088.  
  1089.    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. 
  1090.  
  1091.    (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.) 
  1092.  
  1093.    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. 
  1094.  
  1095.    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. 
  1096.  
  1097.    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. 
  1098.  
  1099.    Finally, the entry PDN router delivers the Pip packet (perhaps by    setting up a connection) to the PDN Address indicated. 
  1100.  
  1101.    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. 
  1102.  
  1103.  
  1104.  
  1105. Francis                                                        [Page 45] 
  1106.  RFC 1621               Pip Near-term Architecture               May 1994 
  1107.  
  1108.     When the source host receives the PCMP Exit PDN Address query    message, it transmits the PDN Addresses to the entry PDN router. 
  1109.  
  1110. 15.1  Notes on Carrying PDN Addresses in NSAPs 
  1111.  
  1112.    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. 
  1113.  
  1114.    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". 
  1115.  
  1116.    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. 
  1117.  
  1118.    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. 
  1119.  
  1120. 16.  Evolution with Pip 
  1121.  
  1122.    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. 
  1123.  
  1124.    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 
  1125.  
  1126.  
  1127.  
  1128. Francis                                                        [Page 46] 
  1129.  RFC 1621               Pip Near-term Architecture               May 1994 
  1130.  
  1131.     or even a majority of systems install it.  None-the-less, it is    necessary to be able to install it piece-wise. 
  1132.  
  1133.    The Pip protocol itself supports evolution through the following    mechanisms [2]: 
  1134.  
  1135.    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.) 
  1136.  
  1137.        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. 
  1138.  
  1139.    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. 
  1140.  
  1141.        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. 
  1142.  
  1143.        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. 
  1144.  
  1145.        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. 
  1146.  
  1147.        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 
  1148.  
  1149.  
  1150.  
  1151. Francis                                                        [Page 47] 
  1152.  RFC 1621               Pip Near-term Architecture               May 1994 
  1153.  
  1154.         modified, using the PCMP Reformat Transit Part message. 
  1155.  
  1156.    3.  Separation of handling from routing.  This allows one aspect to        evolve independently of the other. 
  1157.  
  1158.    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). 
  1159.  
  1160.    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. 
  1161.  
  1162.     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. 
  1163.  
  1164.    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. 
  1165.  
  1166.    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.) 
  1167.  
  1168.     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. 
  1169.  
  1170.    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. 
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Francis                                                        [Page 48] 
  1177.  RFC 1621               Pip Near-term Architecture               May 1994 
  1178.  
  1179.     Note that none of these evolution features of Pip significantly slow    down Pip header processing (as compared to other internet protocols). 
  1180.  
  1181. 16.1 Handling Directive (HD) and Routing Context (RC) Evolution 
  1182.  
  1183.    Because the HD and RC are central to handling and routing of a Pip    packet, the evolution of these aspects deserves more discussion. 
  1184.  
  1185.    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). 
  1186.  
  1187.    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.) 
  1188.  
  1189.    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. 
  1190.  
  1191.    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]. 
  1192.  
  1193.    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). 
  1194.  
  1195.    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 
  1196.  
  1197.  
  1198.  
  1199. Francis                                                        [Page 49] 
  1200.  RFC 1621               Pip Near-term Architecture               May 1994 
  1201.  
  1202.     new parameter set by appropriate configuration of routers. 
  1203.  
  1204.    In the case of a new HD parameter set, however, new software is    necessary--to execute the new handling. 
  1205.  
  1206.    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: 
  1207.  
  1208.    1.  Ignore the unknown parameter, 
  1209.  
  1210.    2.  Set unknown parameter to all 0's, 
  1211.  
  1212.    3.  Set unknown parameter to all 1's, 
  1213.  
  1214.    4.  Silently discard packet, 
  1215.  
  1216.    5.  Discard packet with PCMP Parameter Unknown. 
  1217.  
  1218.    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 
  1219.  
  1220.    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. 
  1221.  
  1222.    The same 5 default actions used for the HD and RC also apply to the    Options. 
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  Francis                                                        [Page 50] 
  1235.  RFC 1621               Pip Near-term Architecture               May 1994 
  1236.  
  1237.  References 
  1238.  
  1239.    [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. 
  1240.  
  1241. Notes on the References: 
  1242.  
  1243.    As of the publication of this RFC, a version of [12], titled    "Comparison of Geographic and Provider-rooted Internet Addressing,"    was submitted to ISOC INET 94 in Prague.  Reference [13] was    published at ACM SIGCOMM 93 in San Francisco under the title "An    Architecture for Scalable Inter-Domain Multicast Routing". 
  1244.  
  1245. Security Considerations 
  1246.  
  1247.    Security issues are not discussed in this memo. 
  1248.  
  1249. Author's Address: 
  1250.  
  1251.    Paul Francis    NTT Software Lab    3-9-11 Midori-cho Musashino-shi    Tokyo 180 Japan 
  1252.  
  1253.    Phone: +81-422-59-3843    Fax +81-422-59-3765    EMail: francis@cactus.ntt.jp 
  1254.  
  1255.  
  1256.  
  1257.  Francis                                                        [Page 51] 
  1258.  
  1259.