9.  Pip Header Server

   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.

   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.)

   (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.)

   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).

9.1  Forming Pip Headers

   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.

   After DNS information about the destination has been received, the
   the following information is available to the Pip header formation
   function.

   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.

   2.  From the source host: The application type (and thus, the desired
       service), and the user access restriction classes.

   3.  From local configuration: The source's providers, and the names,
       types, and access restrictions of those providers.

   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.)

       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.

   There may also be arbitrary policy information available to the Pip
   header formation function.  This architecture does not specify any
   such information.

   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.

   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,

   particularly PCMP Packet Not Delivered messages but also Mobile Host
   messages, the host is able to choose appropriately from the ordered
   list.

   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.

9.2  Pip Header Protocol (PHP)

   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.)

   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.)

9.3  Application Interface

   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.

   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-

   resident with the host.)

   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.

10.  Routing Algorithms in Pip

   This section discusses the routing algorithm for use with
   (hierarchical) Pip Addresses.

   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.

   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.

   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.

   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.)

   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

   IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced
   "milpiv").

   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.

   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.

   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.

10.1  Routing Information Filtering

   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.

   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

   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.

   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).

   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.

   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.

11.  Transition

   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.

   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.

11.1  Justification for Pip Transition Scheme

   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:

   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?

   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])

   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.

   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).

   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.

11.2  Architecture for Pip Transition Scheme

   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-

   smart TCP.

   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.

   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.

   In the remainder of this section, we do not distinguish between a
   virtual Pip infrastructure on IP, and a pure Pip infrastructure.

   Given the model of a Pip infrastructure surrounded by IP, there are 5
   possible packet paths:

   1.  IP - IP

   2.  IP - Pip - IP

   3.  IP - Pip

   4.  Pip - IP

   5.  Pip - Pip

   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

   set aside to remain globally unique, even though other parts of the
   address space are being reused.

11.3  Translation between Pip and IP packets

   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.

   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.

   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).

   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.

   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.

11.4  Translating between PCMP and ICMP

   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.

11.5  Translating between IP and Pip Routing Information

   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.

   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.

11.6  Old TCP and Application Binaries in Pip Hosts

   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.

   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.

   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.)

   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

   could be used to insure that the correct checksum is calculated in
   all cases.

   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.)

   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.

   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.

11.7  Translating between Pip Capable and non-Pip Capable DNS Servers

   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.)

   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

   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.

   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.

   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.

   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.

12.  Pip Address and ID Auto-configuration

   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.

   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.

12.1  Pip Address Prefix Administration

   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.

   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.

   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.)

   Each border router is configured with the following information.

   1.  The type of exit routing for the domain.  This tells the border
       router whether or not it needs to advertise external routes
       internally.

   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).

   3.  Other information about the provider (provider name, type, user
       access restriction classes).

   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.)

   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".

   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.

12.2  Host Autoconfiguration

   There are three phases of host autoconfiguration:

   1.  The host locally creates a flat unique Pip ID (probably globally
       unique but at least unique on the attached subnet).

   2.  The host learns its Pip Addresses.

   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.

   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.

12.2.1  Host Initial Pip ID Creation

   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.

12.2.2  Host Pip Address Assignment

   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.

   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.

12.2.3  Pip ID and Domain Name Assignment

   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.

   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.

   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.

   The design of this service is left for further study.

13.  Pip Control Message Protocol (PCMP)

   The Pip analog to ICMP is PCMP [7].  The near-term Pip architecture
   defines the following PCMP messages:

   1.  Local Redirect

   2.  Packet Not Delivered

   3.  Echo

   4.  Parameter Problem

   5.  Router Discovery

   6.  PMTU Exceeded

   7.  Provider Redirect

   8.  Reformat Transit Part

   9.  Unknown Parameter

   10. Host Mobility

   11. Exit PDN Address

   The Local Redirect, Echo, and Parameter Problem PCMP messages operate
   almost identically to their ICMP counterparts.

   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).

   The Router Discovery PCMP message operates as ICMP's, with the
   exception that a host derives its Pip Address from it.

   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

   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.)

   The Provider Redirect, Invalid Address, Reformat Transit Part,
   Unknown Parameter, Host Mobility, and Exit PDN Address PCMP messages
   are new.

   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).

   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).

   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.

   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).

   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.

   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).

   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).

14.  Host Mobility

   Depending on how security conscience a host is, and what security
   mechanisms a host has available, mobility can come from Pip "for
   free".  If a host is willing to accept a packet by just looking at
   source and destination Pip ID, and if the host simply records the
   source Pip Address on any packet it receives as the appropriate
   return address to the source Pip ID, then mobility comes
   automatically.

   That is, when a mobile host gets a new Pip Address, it simply puts
   that address into the next packet it sends.  When the other host
   receives it, it records the new Pip Address, and starts sending
   return packets to that address.  The security aspect of this is that
   this type of operation leads to an easy way to spoof the (internet
   level) identity of a host.  That is, absent any other security
   mechanisms, any host can write any Pip ID into a packet.  (Cross-
   checking a source Pip ID against the source Pip Address at least
   makes spoofing of this sort as hard as with IP. This is discussed
   below.)

   The above simple host mobility mechanism does not work in the case
   where source and destination hosts obtain new Pip Addresses at the
   same time and the old Pip addresses no longer work, because neither
   is able to send its new address information directly to the other.
   Furthermore, if a host wishes to be more secure about authenticating
   the source Pip ID of a packet, then the above mechanism also is not
   satisfactory.  In what follows, the complete host mobility mechanism
   is described.

   Pip uses the Mobile Host Server and the PCMP Host Mobility message to
   manage host mobility;

   The Mobile Host Server is a non-mobile host (or router acting as a
   host) that keeps track of the active address of a mobile host.  The
   Pip ID and Address of the Mobile Host Server is configured into the
   mobile host, and in DNS.  When a host X obtains information from DNS
   about a host Y, the Pip ID and Address of host Y's Mobile Host Server
   is among the information.  (Also among the information is host Y's
   "permanent" address, if host Y has one.  If host Y is so mobile that
   it doesn't have a permanent address, then no permanent address is
   returned by DNS.  In particular, note that DNS is not intended to
   keep track of a mobile host's active address.)

   Given the destination host's (Y) permanent ID and Address, and the
   Mobile Host Server's permanent IDs and Addresses, the source host (X)
   proceedes as follows.  X tries to establish communications with Y
   using one of the permanent addresses.  If this fails (or if at any

   time X cannot contact Y), X sends a PCMP Mobile Host message to the
   Mobile Host Server requesting the active address for Y.  (Note that X
   can determine that it cannot contact Y from receipt of a PCMP
   Destination Unreachable or a PCMP Invalid Address message.)

   The Mobile Host Server responds to X with the active Pip Addresses of
   Y.  (Of course, Y must inform its Mobile Host Server(s) of its active
   Pip Addresses when it knows them.  This also is done using the PCMP
   Mobile Host message.  Y also informs any hosts that it is actively
   communicating with, using either a regular Pip packet or with a PCMP
   Mobile Host message.  Thus, usually X does not need to contact the
   Mobile Host Server to track Y's active address.)

   If the address that X already tried is among those returned by Y,
   then the source host has the option of either 1) continuing to try
   the same Pip Address, 2) trying another of Y's Pip Addresses, 3)
   waiting and querying the Mobile Host Server again, or 4) giving up.

   If the Mobile Host Server indicates that Y has new active Pip
   Addresses, then X chooses among these in the same manner that it
   chooses among multiple permanent Pip Addresses, and tries to contact
   Y.

14.1  PCMP Mobile Host message

   There are two types of PCMP Mobile Host messages, the query and the
   response.  The query consists of the Pip ID of the host for which
   active Pip Address information is being requested.

   The response consists of a Pip ID, a sequence number, a set of Pip
   Addresses, and a signature field.  The set of Pip Addresses includes
   all currently usable addresses of the host indicated by the Pip ID.
   Thus, the PCMP Mobile Host message can be used both to indicate a
   newly obtained address, and to indicate that a previous address is no
   longer active (by that addresses' absence in the set).

   The sequence number indicates which is the most recent information.
   It is needed to deal with the case where an older PCMP Mobile Host
   response is received after a newer one.

   The signature field is a value that derives from encrypting the
   sequence number and the set of Pip Addresses.  For now, the
   encryption algorithms used, how to obtain keys, and so on are for
   further study.

14.2  Spoofing Pip IDs

   This section discusses host mechanisms for decreasing the probability
   of Pip ID spoofing.  The mechanisms provided in this version of the
   near-term Pip architecture are no more secure than DNS itself.  It is
   hoped that mechanisms and the corresponding infrastructure needed for
   better internetwork layer security can be installed with whatever new
   IP protocol is chosen.

   After a host makes a DNS query, it knows:

   1.  The destination host's Pip ID,

   2.  The destination host's permanent Pip Addresses, and

   3.  The destination host's Mobile Host Server's Pip ID and Addresses.

   Note that the DNS query can be a normal one (based on domain name) or
   an inverse query (based on Pip ID or Pip Address, though the latter
   is more likely to succeed, since the Pip ID may be flat and therefore
   not suitable for an inverse lookup).  The inverse query is done when
   the host did not initiate the packet exchange, and therefore doesn't
   know the domain name of the remote (initiating) host.

   If the destination host is not mobile, then the source host can check
   the source Pip Address, compare it with those received from DNS, and
   reject the packet if it does not match.  This gives spoof protection
   equal to that of IP.

   If the destination host is mobile and obtains new Pip Addresses, then
   the source host can check the validity of the new Pip Address by
   sending a PCMP Mobile Host query to the Mobile Host Server learned
   from DNS.  The set of Pip Addresses learned from the Mobile Address
   Server is then used for subsequent validation.

15.  Public Data Network (PDN) Address Discovery

   One of the problems with running Pip (or any internet protocol) over
   a PDN is that of the PDN entry Pip System discovering the PDN Address
   of the appropriate PDN exit Pip System.  This problem is solved using
   ARP in small, broadcast LANs because the broadcast mechanism is
   relatively cheap.  This solution is not available in the PDN case,
   where the number of attached systems is very large, and where
   broadcast is not available (or is not cheap if it is).

   For the case where the domain of the destination host is attached to
   a PDN, the problem is nicely solved by distributing the domain's exit
   PDN Address information in DNS, and then having the source host

   convey the exit PDN Address to the PDN entry router in a Pip option.

   The DNS of the destination host's domain contains the PDN Addresses
   for the domain.  When DNS returns a record for the destination host,
   the record associates zero or more PDN Addresses with each Pip
   Address.  There can be more than one PDN address associated with a
   given PDN, and there can be more than on PDN associated with a given
   Pip Address.  This latter case occurs when more than one hierarchical
   component of the Pip Address each represents a separate PDN.  It is
   expected that in almost all cases, there will be only one (or none)
   PDN associated with any Pip address.

   (Note that, while the returned DNS record associates the PDN
   Addresses with a single Pip Address, in general the PDN Address will
   apply to a set of Pip Addresses--those for all hosts in the domain.
   The DNS files are structured to reflect this grouping in the same way
   that a single Pip Address prefix in DNS applies to many hosts.
   Therefore, every individual host entry in the DNS files does not need
   to have separate PDN Addresses typed in with it.  This simplifies
   configuration of DNS.)

   When the source host sends the first packet to a given destination
   host, it attaches the PDN Addresses, one per PDN, to the packet in an
   option.  (Note that, because of the way that options are processed in
   Pip packets, no router other than the entry PDN router need look at
   the option.) When the entry router receives this packet, it
   determines that it is the entry router based on the result of the
   FTIF Chain lookup.

   It retrieves the PDN Address from the option, and caches it locally.
   The cache entry can later by retrieved using either the destination
   Pip ID or the destination Pip Address as the cache index.

   The entry router sends the source host a PCMP Exit PDN Address
   message indicating that it has cached the information.  If there are
   multiple exit PDN Addresses, then the source host can at this time
   inform the entry PDN router of all the PDN addresses.  The entry PDN
   router can either choose from these to setup a connection, or cache
   them to recover from the case where the existing connection breaks.

   Finally, the entry PDN router delivers the Pip packet (perhaps by
   setting up a connection) to the PDN Address indicated.

   When a PDN entry router receives a Pip packet for which it doesn't
   know the exit PDN address (and has no other means of determining it,
   such as shortcut routing), it sends a PCMP Exit PDN Address query
   message to the originating host.  This can happen if, for instance,
   routing changes and directs the packets to a new PDN entry router.

   When the source host receives the PCMP Exit PDN Address query
   message, it transmits the PDN Addresses to the entry PDN router.

15.1  Notes on Carrying PDN Addresses in NSAPs

   The Pip use of PDN Address carriage in the option or PCP Exit PDN
   Address message solves two significant problems associated with the
   analogous use of PDN Address-based NSAPs.

   First, there is no existing agreement (standards or otherwise) that
   the existence of of a PDN Address in an NSAP address implies that the
   identified host is reachable behind the PDN Address.  Thus, upon
   receiving such an NSAP, the entry PDN router does not know for sure,
   without explicit configuration information, whether or not the PDN
   Address can be used at the lower layer.  Solution of this problem
   requires standards body agreement, perhaps be setting aside
   additional AFIs to mean "PDN Address with topological significance".

   The second, and more serious, problem is that a PDN Address in an
   NSAP does not necessarily scale well.  This is best illustrated with
   the E.164 address.  E.164 addresses can be used in many different
   network technologies--telephone network, BISDN, SMDS, Frame Relay,
   and other ATM.  When a router receives a packet with an E.164-based
   NSAP, the E.164 address is in the most significant part of the NSAP
   address (that is, contains the highest level routing information).
   Thus, without a potentially significant amount of routing table
   information, the router does not know which network to send the
   packet to.  Thus, unless E.164 addresses are assigned out in blocks
   according to provider network, it won't scale well.

   A related problem is that of how an entry PDN router knows that the
   PDN address is meant for the PDN it is attached to or some other PDN.
   With Pip, there is a one-to-one relationship between Pip Address
   prefix and PDN, so it is always known.  With NSAPs, it is not clear
   without the potentially large routing tables discussed in the
   previous paragraph.

16.  Evolution with Pip

   The fact that we call this architecture "near-term" implies that we
   expect it to evolve to other architectures.  Thus it is important
   that we have a plan to evolve to these architectures.  The Pip near-
   term architecture includes explicit mechanisms to support evolution.

   The key to evolution is being able to evolve any system at any time
   without destroying old functionality.  Depending on what the new
   functionality is, it may be immediately useful to any system that
   installs it, or it may not become useful until a significant number

   or even a majority of systems install it.  None-the-less, it is
   necessary to be able to install it piece-wise.

   The Pip protocol itself supports evolution through the following
   mechanisms [2]:

   1.  Tunneling.  This allows more up-to-date routers to tunnel less
       up-to-date routers, thus allowing for incremental router
       evolution.  (Of course, by virtue of encapsulation, tunneling is
       always an evolution option, and indeed tunneling through IP is
       used in the Pip transition.  However, Pip's tunneling encoding is
       efficient because it doesn't duplicate header information.)

       The only use for Pip tunneling in the Pip near-term architecture
       is to route packets through the internal routers of a transit
       domain when the internal routers have no external routing
       information.  It is assumed that enhancements to the Pip
       Architecture that require tunneling will have their own means of
       indicating when forming a tunnel is necessary.

   2.  Host independence from routing information.  Since a host can
       receive packets without understanding the routing content of the
       packet, routers can evolve without necessarily requiring hosts to
       evolve at the same pace.

       In order to allow hosts to send Pip packets without understanding
       the contents of the routing information (in the Transit Part), the
       Pip Header Server is able to "spoon-feed" the host the Pip header.

       If the Pip Header Server determines that the host is able to form
       its own Pip header (as will usually be the case with the near-term
       Pip architecture), the Pip Header is essentially a null function.
       It accepts a query from the host, passes it on to DNS, and returns
       the DNS information to the host.

       If the Pip Header Server determines that the host is not able to
       form its own Pip header, then the Pip Header Server forms one on
       behalf of the host.  In one mode of operation, the Pip Header
       Server gives the host the values of some or all Transit Part
       fields, and the host constructs the Transit Part.  This allows for
       evolution within the framework of the current Transit Part.  In
       another mode, the Pip Header Server gives the host the Transit
       Part as a simple bit field.  This allows for evolution outside the
       framework of the current Transit Part.

       In addition to the Pip Header Server being able to spoon-feed the
       host a Transit Part, routers are also able to spoon-feed hosts a
       Transit Part, in case the original Transit Part needs to be

       modified, using the PCMP Reformat Transit Part message.

   3.  Separation of handling from routing.  This allows one aspect to
       evolve independently of the other.

   4.  Flexible Handling Directive, Routing Context, and Options
       definition.  This allows new handling, routing, and option types
       to be added and defunct ones to be removed over time (see section
       16.1 below).

   5.  Fast and general options processing.  Options processing in Pip is
       fast, both because not every router need look at every option, and
       because once a router decides it needs to look at an option, it
       can find it quickly (does not require a serial search).  Thus the
       oft-heard argument that a new option can't be used because it will
       slow down processing in all routers goes away.

    Pip Options can be thought of as an extension of the Handling
    Directive (HD).  The HD is used when the handling type is common,
    and can be encoded in a small space.  The option is used otherwise.
    It is possible that a future option will influence routing, and thus
    the Option will be an extension of the RD as well.  The RD, however,
    is rich enough that this is unlikely.

   6.  Generalized Routing Directive.  Because the Routing Directive is
       so general, it is more likely that we can evolve routing and
       addressing semantics without having to redefine the Pip header or
       the forwarding machinery.

   7.  Host version number.  This number tells what Pip functions a host
       has, such as which PCMP messages it can handle, so that routers
       can respond appropriately to a Pip packet received from a remote
       host.  This supports the capability for routers to evolve ahead of
       hosts.  (All Pip hosts will at least be able to handle all Pip
       near-term architecture functions.)

    The Host version number is also used by the Pip Header Server to
    determine the extent to which the Pip Header Server needs to format
    a header on behalf of the host.

   8.  Generalized Route Types.  The IDRP/MLPV routing algorithm is
       generic with regards to the types of routes it can calculate.
       Thus, adding new route types is a matter of configuring routers to
       accept the new route type, defining metrics for the new route
       type, and defining criteria for selecting one route of the new
       type over another.

   Note that none of these evolution features of Pip significantly slow
   down Pip header processing (as compared to other internet protocols).

16.1 Handling Directive (HD) and Routing Context (RC) Evolution

   Because the HD and RC are central to handling and routing of a Pip
   packet, the evolution of these aspects deserves more discussion.

   Both the HD and the RC fields contain multiple parameters.  (In the
   case of the RC, the router treats the RC field as a single number,
   that is, ignores the fact that the RC is composed of multiple
   parameters.  This allows for fast forwarding of Pip packets.) These
   HD and RC multiple parameters may be arranged in any fashion (can be
   any length, subject to the length of the HD and RC fields themselves,
   and can fall on arbitrary bit boundaries).

   Associated with the HD and RC are "Contents" fields that indicate
   what parameters are in the HD and RC fields, and where they are.
   (The Contents fields are basically version numbers, except that a
   higher "version" number is not considered to supersede a lower one.
   Typical types of parameters are address family, TOS value, queueing
   priority, and so on.)

   The Contents field is a single number, the value of which indicates
   the parameter set.  The mapping of Contents field value to parameter
   set is configured manually.

   The procedure for establishing new HD or RC parameter sets (or,
   erasing old ones) is as follows.  Some organization defines the new
   parameter set.  This may involve defining a new parameter.  If it
   does, then the new parameter is described as a Pip Object.  A Pip
   Object is nothing more than a number space used to unambiguously
   identify a new parameter type, and a character string that describes
   it [9].

   Thus, the new parameter set is described as a list of Pip Objects,
   and the bit locations in the HD/RC that each Pip Object occupies.
   The organization that defines the parameter set submits it for an
   official Contents field value.  (It would be submitted to the
   standards body that has authority over Pip, currently the IAB.) If
   the new parameter set is approved, it is given a Contents value, and
   that value is published in a well known place (an RFC).

   Of course, network administrators are free to install or not install
   the new parameter set in their hosts and routers.  In the case of a
   new RC parameter set, installation of the new parameter set does not
   necessarily require any new software, because any Pip routing
   protocol, such as IDRP/MLPV, is able to find routes according to the

   new parameter set by appropriate configuration of routers.

   In the case of a new HD parameter set, however, new software is
   necessary--to execute the new handling.

   For new HD and RC parameters sets, systems that do not understand the
   new parameter set can still be configured to execute one of several
   default actions on the new parameter.  These default action allow for
   some control over how new functions are introduced into Pip systems.
   The default actions are:

   1.  Ignore the unknown parameter,

   2.  Set unknown parameter to all 0's,

   3.  Set unknown parameter to all 1's,

   4.  Silently discard packet,

   5.  Discard packet with PCMP Parameter Unknown.

   Action 1 is used when it doesn't much matter if previous systems on a
   path have acted on the parameter or not.  Actions 2 and 3 are used
   when systems should know whether a previous system has not understood
   the parameter.  Actions 4 and 5 are used when something bad happens
   if not all systems understand the new parameter.

16.1.1  Options Evolution

   The evolution of Options is very similar to that of the HD and RC.
   Associated with the Options is an Options Present field that
   indicates in a single word which of up to 8 options are present in
   the Options Part.  There is a Contents field associated with the
   Options Present field that indicates which subset of all possible
   options the Options Present field refers to.  Contents field values
   are assigned in the same way as for the HD and RC Contents fields.

   The same 5 default actions used for the HD and RC also apply to the
   Options.

References

   [1]  Thomson, F., "Use of DNS with Pip", Work in Progress.
   [2]  Francis, P., "Pip Header Processing", Work in Progress.
   [3]  Pip Address Assignment Specification,  Work in Progress.
   [4]  Francis, P., "Pip Identifiers", Work in Progress.
   [5]  Pip Assigned Numbers, Work in Progress.
   [6]  Pip Header Protocol,  Work in Progress.
   [7]  Francis, G., "PCMP: Pip Control Message Protocol",
        Work in Progress.
   [8]  Pip Router Discovery Protocol, Work in Progress.
   [9]  Pip Objects Specification, Work in Progress.
   [10] Rajagopolan, and P. Francis, "The Multi-Level Path Vector
        Routing Scheme", Work in Progress.
   [11] Francis, P., "Pip Address Conventions", Work in Progress.
   [12] Francis, P., "On the Assignment of Provider Rooted Addresses",
        Work in Progress.
   [13] Ballardie, Francis, P., and J. Crowcroft, "Core Based Trees
        (CBT), An Architecture for Scalable Inter-Domain Multicast
        Routing", Work in Progress.
   [14] Franics, P., "Pip Host Operation", Work in Progress.
   [15] Egevang, K., and P. Francis, "The IP Network Address
        Translator (NAT)", RFC 1631, Cray Communications, NTT,
        May 1994.

Notes on the References:

   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".

Security Considerations

   Security issues are not discussed in this memo.

Author's Address:

   Paul Francis
   NTT Software Lab
   3-9-11 Midori-cho Musashino-shi
   Tokyo 180 Japan

   Phone: +81-422-59-3843
   Fax +81-422-59-3765
   EMail: francis@cactus.ntt.jp