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)", RFC1631, 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