RFC 2002
IP Mobility Support
4. Routing Considerations This section describes how mobile nodes, home agents, and (possibly) foreign agents cooperate to route datagrams to/from mobile nodes that are connected to a foreign network. The mobile node informs its home agent of its current location using the registration procedure described in Section 3. See the protocol overview in Section 1.7 for the relative locations of the mobile node's home address with respect to its home agent, and the mobile node itself with respect to any foreign agent with which it might attempt to register.
4.1. Encapsulation Types Home agents and foreign agents MUST support tunneling datagrams using IP in IP encapsulation [14]. Any mobile node that uses a co-located care-of address MUST support receiving datagrams tunneled using IP in IP encapsulation. Minimal encapsulation [15] and GRE encapsulation [8] are alternate encapsulation methods which MAY optionally be supported by mobility agents and mobile nodes. The use of these alternative forms of encapsulation, when requested by the mobile node, is otherwise at the discretion of the home agent. 4.2. Unicast Datagram Routing 4.2.1. Mobile Node Considerations When connected to its home network, a mobile node operates without the support of mobility services. That is, it operates in the same way as any other (fixed) host or router. The method by which a mobile node selects a default router when connected to its home network, or when away from home and using a co-located care-of address, is outside the scope of this document. ICMP Router Advertisement [4] is one such method. When registered on a foreign network, the mobile node chooses a default router by the following rules: - If the mobile node is registered using a foreign agent care-of address, then the mobile node MUST choose its default router from among the Router Addresses advertised in the ICMP Router Advertisement portion of that Agent Advertisement message. The mobile node MAY also consider the IP source address of the Agent Advertisement as another possible choice for the IP address of a default router, along with the (possibly empty) list of Router Addresses from the ICMP Router Advertisement portion of the message. In such cases, the IP source address MUST be considered to be the worst choice (lowest preference) for a default router. - If the mobile node is registered directly with its home agent using a co-located care-of address, then the mobile node SHOULD choose its default router from among those advertised in any ICMP Router Advertisement message that it receives for which its externally obtained care-of address and the Router Address match under the network prefix. If the mobile node's externally obtained care-of address matches the IP source address of the Agent Advertisement under the network prefix, the mobile node MAY also consider that IP source address as another possible choice for the IP address of a default router, along with the (possibly empty) list of Router Addresses from the ICMP Router
Advertisement portion of the message. If so, the IP source
address MUST be considered to be the worst choice (lowest
preference) for a default router. The network prefix MAY
be obtained from the Prefix-Lengths Extension in the Router
Advertisement, if present. The prefix MAY also be obtained
through other mechanisms beyond the scope of this document.
Beyond these rules, the actual selection of the default router is
made by the selection method specified for ICMP Router Discovery [4],
among the Router Addresses specified above. In any case, a mobile
node registered via a foreign agent MAY choose its foreign agent as a
default router.
Note that Van Jacobson header compression [10] will not function
properly unless all TCP IP datagrams to and from the mobile node
pass, respectively, through the same first and last-hop router. The
mobile node, therefore, MUST select its foreign agent as its default
router if it performs Van Jacobson header compression with its
foreign agent.
4.2.2. Foreign Agent Considerations
Upon receipt of an encapsulated datagram sent to its advertised
care-of address, a foreign agent MUST compare the inner destination
address to those entries in its visitor list. When the destination
does not match the address of any mobile node currently in the
visitor list, the foreign agent MUST NOT forward the datagram without
modifications to the original IP header, because otherwise a routing
loop is likely to result. The datagram SHOULD be silently discarded.
ICMP Destination Unreachable MUST NOT be sent when a foreign agent is
unable to forward an incoming tunneled datagram. Otherwise, the
foreign agent forwards the decapsulated datagram to the mobile node.
The foreign agent MUST NOT advertise to other routers in its routing
domain, nor to any other mobile node, the presence of a mobile router
(Section 4.5).
The foreign agent MUST route datagrams it receives from registered
mobile nodes. At a minimum, this means that the foreign agent must
verify the IP Header Checksum, decrement the IP Time To Live,
recompute the IP Header Checksum, and forward such datagrams to a
default router. In addition, the foreign agent SHOULD send an
appropriate ICMP Redirect message to the mobile node.
4.2.3. Home Agent Considerations The home agent MUST be able to intercept any datagrams on the home network addressed to the mobile node while the mobile node is registered away from home. Proxy and gratuitous ARP MAY be used in enabling this interception, as specified in Section 4.6. The home agent must examine the IP Destination Address of all arriving datagrams to see if it is equal to the home address of any of its mobile nodes registered away from home. If so, the home agent tunnels the datagram to the mobile node's currently registered care- of address or addresses. If the home agent supports the optional capability of multiple simultaneous mobility bindings, it tunnels a copy to each care-of address in the mobile node's mobility binding list. If the mobile node has no current mobility bindings, the home agent MUST NOT attempt to intercept datagrams destined for the mobile node, and thus will not in general receive such datagrams. However, if the home agent is also a router handling common IP traffic, it is possible that it will receive such datagrams for forwarding onto the home network. In this case, the home agent MUST assume the mobile node is at home and simply forward the datagram directly onto the home network. See Section 4.1 regarding methods of encapsulation that may be used for tunneling. Nodes implementing tunneling SHOULD also implement the "tunnel soft state" mechanism [14], which allows ICMP error messages returned from the tunnel to correctly be reflected back to the original senders of the tunneled datagrams. Home agents SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node for the purpose of maintaining location privacy, as described in Section 5.5. If the Lifetime for a given mobility binding expires before the home agent has received another valid Registration Request for that mobile node, then that binding is deleted from the mobility binding list. The home agent MUST NOT send any Registration Reply message simply because the mobile node's binding has expired. The entry in the visitor list of the mobile node's current foreign agent will expire naturally, probably at the same time as the binding expired at the home agent. When a mobility binding's lifetime expires, the home agent MUST delete the binding, but it MUST retain any other (non- expired) simultaneous mobility bindings that it holds for the mobile node. When a home agent receives a datagram, intercepted for one of its mobile nodes registered away from home, the home agent MUST examine the datagram to check if it is already encapsulated. If so, special
rules apply in the forwarding of that datagram to the mobile node:
- If the inner (encapsulated) Destination Address is the same
as the outer Destination Address (the mobile node), then the
home agent MUST also examine the outer Source Address of the
encapsulated datagram (the source address of the tunnel). If
this outer Source Address is the same as the mobile node's
current care-of address, the home agent MUST silently discard
that datagram in order to prevent a likely routing loop. If,
instead, the outer Source Address is NOT the same as the mobile
node's current care-of address, then the home agent SHOULD
forward the datagram to the mobile node. In order to forward
the datagram in this case, the home agent MAY simply alter the
outer Destination Address to the care-of address, rather than
re-encapsulating the datagram.
- Otherwise (the inner Destination Address is NOT the same as the
outer Destination Address), the home agent SHOULD encapsulate
the datagram again (recursive encapsulation), with the new outer
Destination Address set equal to the mobile node's care-of
address. That is, the home agent forwards the entire datagram
to the mobile node in the same way as any other datagram
(encapsulated already or not).
4.3. Broadcast Datagrams
When a home agent receives a broadcast datagram, it MUST NOT forward
the datagram to any mobile nodes in its mobility binding list other
than those that have requested forwarding of broadcast datagrams. A
mobile node MAY request forwarding of broadcast datagrams by setting
the 'B' bit in its Registration Request message (Section 3.3). For
each such registered mobile node, the home agent SHOULD forward
received broadcast datagrams to the mobile node, although it is a
matter of configuration at the home agent as to which specific
categories of broadcast datagrams will be forwarded to such mobile
nodes.
If the 'D' bit was set in the mobile node's Registration Request
message, indicating that the mobile node is using a co-located care-
of address, the home agent simply tunnels appropriate broadcast IP
datagrams to the mobile node's care-of address. Otherwise (the 'D'
bit was NOT set), the home agent first encapsulates the broadcast
datagram in a unicast datagram addressed to the mobile node's home
address, and then tunnels this encapsulated datagram to the foreign
agent. This extra level of encapsulation is required so that the
foreign agent can determine which mobile node should receive the
datagram after it is decapsulated. When received by the foreign
agent, the unicast encapsulated datagram is detunneled and delivered
to the mobile node in the same way as any other datagram. In either case, the mobile node must decapsulate the datagram it receives in order to recover the original broadcast datagram. 4.4. Multicast Datagram Routing As mentioned previously, a mobile node that is connected to its home network functions in the same way as any other (fixed) host or router. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. This section therefore describes the behavior of a mobile node that is visiting a foreign network. In order receive multicasts, a mobile node MUST join the multicast group in one of two ways. First, a mobile node MAY join the group via a (local) multicast router on the visited subnet. This option assumes that there is a multicast router present on the visited subnet. If the mobile node is using a co-located care-of address, it SHOULD use this address as the source IP address of its IGMP [5] messages. Otherwise, it MUST use its home address. Alternatively, a mobile node which wishes to receive multicasts MAY join groups via a bi-directional tunnel to its home agent, assuming that its home agent is a multicast router. The mobile node tunnels IGMP messages to its home agent and the home agent forwards multicast datagrams down the tunnel to the mobile node. The rules for multicast datagram delivery to mobile nodes in this case are identical to those for broadcast datagrams (Section 4.3). Namely, if the mobile node is using a co-located care-of address (the 'D' bit was set in the mobile node's Registration Request), then the home agent SHOULD tunnel the datagram to this care-of address; otherwise, the home agent MUST first encapsulate the datagram in a unicast datagram addressed to the mobile node's home address and then MUST tunnel the resulting datagram (recursive tunneling) to the mobile node's care-of address. A mobile node that wishes to send datagrams to a multicast group also has two options: (1) send directly on the visited network; or (2) send via a tunnel to its home agent. Because multicast routing in general depends upon the IP source address, a mobile node which sends multicast datagrams directly on the visited network MUST use a co- located care-of address as the IP source address. Similarly, a mobile node which tunnels a multicast datagram to its home agent MUST use its home address as the IP source address of both the (inner) multicast datagram and the (outer) encapsulating datagram. This second option assumes that the home agent is a multicast router.
4.5. Mobile Routers A mobile node can be a router, which is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". A mobile router MAY act as a foreign agent and provide a foreign agent care-of address to mobile nodes connected to the mobile network. Typical routing to a mobile node via a mobile router in this case is illustrated by the following example: a) A laptop computer is disconnected from its home network and later attached to a network port in the seat back of an aircraft. The laptop computer uses Mobile IP to register on this foreign network, using a foreign agent care-of address discovered through an Agent Advertisement from the aircraft's foreign agent. b) The aircraft network is itself mobile. Suppose the node serving as the foreign agent on the aircraft also serves as the default router that connects the aircraft network to the rest of the Internet. When the aircraft is at home, this router is attached to some fixed network at the airline's headquarters, which is the router's home network. While the aircraft is in flight, this router registers from time to time over its radio link with a series of foreign agents below it on the ground. This router's home agent is a node on the fixed network at the airline's headquarters. c) Some correspondent node sends a datagram to the laptop computer, addressing the datagram to the laptop's home address. This datagram is initially routed to the laptop's home network. d) The laptop's home agent intercepts the datagram on the home network and tunnels it to the laptop's care-of address, which in this example is an address of the node serving as router and foreign agent on the aircraft. Normal IP routing will route the datagram to the fixed network at the airline's headquarters.
e) The aircraft router and foreign agent's home agent there
intercepts the datagram and tunnels it to its current care-of
address, which in this example is some foreign agent on the
ground below the aircraft. The original datagram from the
correspondent node has now been encapsulated twice: once
by the laptop's home agent and again by the aircraft's home
agent.
f) The foreign agent on the ground decapsulates the datagram,
yielding a datagram still encapsulated by the laptop's home
agent, with a destination address of the laptop's care-of
address. The ground foreign agent sends the resulting
datagram over its radio link to the aircraft.
g) The foreign agent on the aircraft decapsulates the datagram,
yielding the original datagram from the correspondent node,
with a destination address of the laptop's home address.
The aircraft foreign agent delivers the datagram over the
aircraft network to the laptop's link-layer address.
This example illustrated the case in which a mobile node is attached
to a mobile network. That is, the mobile node is mobile with respect
to the network, which itself is also mobile (here with respect to the
ground). If, instead, the node is fixed with respect to the mobile
network (the mobile network is the fixed node's home network), then
either of two methods may be used to cause datagrams from
correspondent nodes to be routed to the fixed node.
A home agent MAY be configured to have a permanent registration for
the fixed node, that indicates the mobile router's address as the
fixed host's care-of address. The mobile router's home agent will
usually be used for this purpose. The home agent is then responsible
for advertising connectivity using normal routing protocols to the
fixed node. Any datagrams sent to the fixed node will thus use
recursive tunneling as described above.
Alternatively, the mobile router MAY advertise connectivity to the
entire mobile network using normal IP routing protocols through a
bi-directional tunnel to its own home agent. This method avoids the
need for recursive tunneling of datagrams.
4.6. ARP, Proxy ARP, and Gratuitous ARP
The use of ARP [16] requires special rules for correct operation when
wireless or mobile nodes are involved. The requirements specified in
this section apply to all home networks in which ARP is used for
address resolution.
In addition to the normal use of ARP for resolving a target node's
link-layer address from its IP address, this document distinguishes
two special uses of ARP:
- A Proxy ARP [18] is an ARP Reply sent by one node on behalf
of another node which is either unable or unwilling to answer
its own ARP Requests. The sender of a Proxy ARP reverses the
Sender and Target Protocol Address fields as described in [16],
but supplies some configured link-layer address (generally, its
own) in the Sender Hardware Address field. The node receiving
the Reply will then associate this link-layer address with the
IP address of the original target node, causing it to transmit
future datagrams for this target node to the node with that
link-layer address.
- A Gratuitous ARP [23] is an ARP packet sent by a node in order to
spontaneously cause other nodes to update an entry in their ARP
cache. A gratuitous ARP MAY use either an ARP Request or an ARP
Reply packet. In either case, the ARP Sender Protocol Address
and ARP Target Protocol Address are both set to the IP address
of the cache entry to be updated, and the ARP Sender Hardware
Address is set to the link-layer address to which this cache
entry should be updated. When using an ARP Reply packet, the
Target Hardware Address is also set to the link-layer address to
which this cache entry should be updated (this field is not used
in an ARP Request packet).
In either case, for a gratuitous ARP, the ARP packet MUST be
transmitted as a local broadcast packet on the local link. As
specified in [16], any node receiving any ARP packet (Request or
Reply) MUST update its local ARP cache with the Sender Protocol
and Hardware Addresses in the ARP packet, if the receiving node
has an entry for that IP address already in its ARP cache. This
requirement in the ARP protocol applies even for ARP Request
packets, and for ARP Reply packets that do not match any ARP
Request transmitted by the receiving node [16].
While a mobile node is registered on a foreign network, its home
agent uses proxy ARP [18] to reply to ARP Requests it receives that
seek the mobile node's link-layer address. When receiving an ARP
Request, the home agent MUST examine the target IP address of the
Request, and if this IP address matches the home address of any
mobile node for which it has a registered mobility binding, the home
agent MUST transmit an ARP Reply on behalf of the mobile node. After
exchanging the sender and target addresses in the packet [18], the
home agent MUST set the sender link-layer address in the packet to
the link-layer address of its own interface over which the Reply will
be sent.
When a mobile node leaves its home network and registers a binding on a foreign network, its home agent uses gratuitous ARP to update the ARP caches of nodes on the home network. This causes such nodes to associate the link-layer address of the home agent with the mobile node's home (IP) address. When registering a binding for a mobile node for which the home agent previously had no binding (the mobile node was assumed to be at home), the home agent MUST transmit a gratuitous ARP on behalf of the mobile node. This gratuitous ARP packet MUST be transmitted as a broadcast packet on the link on which the mobile node's home address is located. Since broadcasts on the local link (such as Ethernet) are typically not guaranteed to be reliable, the gratuitous ARP packet SHOULD be retransmitted a small number of times to increase its reliability. When a mobile node returns to its home network, the mobile node and its home agent use gratuitous ARP to cause all nodes on the mobile node's home network to update their ARP caches to once again associate the mobile node's own link-layer address with the mobile node's home (IP) address. Before transmitting the (de)Registration Request message to its home agent, the mobile node MUST transmit this gratuitous ARP on its home network as a local broadcast on this link. The gratuitous ARP packet SHOULD be retransmitted a small number of times to increase its reliability, but these retransmissions SHOULD proceed in parallel with the transmission and processing of its (de)Registration Request. When the mobile node's home agent receives and accepts this (de)Registration Request, the home agent MUST also transmit a gratuitous ARP on the mobile node's home network. This gratuitous ARP also is used to associate the mobile node's home address with the mobile node's own link-layer address. A gratuitous ARP is transmitted by both the mobile node and its home agent, since in the case of wireless network interfaces, the area within transmission range of the mobile node will likely differ from that within range of its its home agent. Th ARP packet from the home agent MUST be transmitted as a local broadcast on the mobile node's home link, and SHOULD be retransmitted a small number of times to increase its reliability; these retransmissions, however, SHOULD proceed in parallel with the transmission and processing of its (de)Registration Reply. While the mobile node is away from home, it MUST NOT transmit any broadcast ARP Request or ARP Reply messages. Finally, while the mobile node is away from home, it MUST NOT reply to ARP Requests in which the target IP address is its own home address, unless the ARP Request is sent by a foreign agent with which the mobile node is attempting to register or a foreign agent with which the mobile node has an unexpired registration. In the latter case, the mobile
node MUST use a unicast ARP Reply to respond to the foreign agent.
Note that if the mobile node is using a co-located care-of address
and receives an ARP Request in which the target IP address is this
care-of address, then the mobile node SHOULD reply to this ARP
Request. Note also that, when transmitting a Registration Request on
a foreign network, a mobile node may discover the link-layer address
of a foreign agent by storing the address as it is received from the
Agent Advertisement from that foreign agent, but not by transmitting
a broadcast ARP Request message.
The specific order in which each of the above requirements for the
use of ARP, proxy ARP, and gratuitous ARP are applied, relative to
the transmission and processing of the mobile node's Registration
Request and Registration Reply messages when leaving home or
returning home, are important to the correct operation of the
protocol.
To summarize the above requirements, when a mobile node leaves its
home network, the following steps, in this order, MUST be performed:
- The mobile node decides to register away from home, perhaps
because it has received an Agent Advertisement from a foreign
agent and has not recently received one from its home agent.
- Before transmitting the Registration Request, the mobile node
disables its own future processing of any ARP Requests it
may subsequently receive requesting the link-layer address
corresponding to its home address, except insofar as necessary to
communicate with foreign agents on visited networks.
- The mobile node transmits its Registration Request.
- When the mobile node's home agent receives and accepts the
Registration Request, it performs a gratuitous ARP on behalf
of the mobile node, and begins using proxy ARP to reply to ARP
Requests that it receives requesting the mobile node's link-layer
address. If, instead, the home agent rejects the Registration
Request, no ARP processing (gratuitous nor proxy) is performed by
the home agent.
When a mobile node later returns to its home network, the following
steps, in this order, MUST be performed:
- The mobile node decides to register at home, perhaps because it
has received an Agent Advertisement from its home agent.
- Before transmitting the Registration Request, the mobile node
re-enables its own future processing of any ARP Requests it may
subsequently receive requesting its link-layer address.
- The mobile node performs a gratuitous ARP for itself.
- The mobile node transmits its Registration Request.
- When the mobile node's home agent receives and accepts the
Registration Request, it stops using proxy ARP to reply to
ARP Requests that it receives requesting the mobile node's
link-layer address, and then performs a gratuitous ARP on behalf
of the mobile node. If, instead, the home agent rejects the
Registration Request, no ARP processing (gratuitous nor proxy) is
performed by the home agent.
5. Security Considerations
The mobile computing environment is potentially very different from
the ordinary computing environment. In many cases, mobile computers
will be connected to the network via wireless links. Such links are
particularly vulnerable to passive eavesdropping, active replay
attacks, and other active attacks.
5.1. Message Authentication Codes
Home agents and mobile nodes MUST be able to perform authentication.
The default algorithm is keyed MD5 [21], with a key size of 128 bits.
The default mode of operation is to both precede and follow the data
to be hashed, by the 128-bit key; that is, MD5 is to be used in
"prefix+suffix" mode. The foreign agent MUST also support
authentication using keyed MD5 and key sizes of 128 bits or greater,
with manual key distribution. More authentication algorithms,
algorithm modes, key distribution methods, and key sizes MAY also be
supported.
5.2. Areas of Security Concern in this Protocol
The registration protocol described in this document will result in a
mobile node's traffic being tunneled to its care-of address. This
tunneling feature could be a significant vulnerability if the
registration were not authenticated. Such remote redirection, for
instance as performed by the mobile registration protocol, is widely
understood to be a security problem in the current Internet if not
authenticated [2]. Moreover, the Address Resolution Protocol (ARP)
is not authenticated, and can potentially be used to steal another
host's traffic. The use of "Gratuitous ARP" (Section 4.6) brings
with it all of the risks associated with the use of ARP.
5.3. Key Management This specification requires a strong authentication mechanism (keyed MD5) which precludes many potential attacks based on the Mobile IP registration protocol. However, because key distribution is difficult in the absence of a network key management protocol, messages with the foreign agent are not all required to be authenticated. In a commercial environment it might be important to authenticate all messages between the foreign agent and the home agent, so that billing is possible, and service providers do not provide service to users that are not legitimate customers of that service provider. 5.4. Picking Good Random Numbers The strength of any authentication mechanism depends on several factors, including the innate strength of the authentication algorithm, the secrecy of the key used, the strength of the key used, and the quality of the particular implementation. This specification requires implementation of keyed MD5 for authentication, but does not preclude the use of other authentication algorithms and modes. For keyed MD5 authentication to be useful, the 128-bit key must be both secret (that is, known only to authorized parties) and pseudo-random. If nonces are used in connection with replay protection, they must also be selected carefully. Eastlake, et al. [7] provides more information on generating pseudo-random numbers. 5.5. Privacy Users who have sensitive data that they do not wish others to see should use mechanisms outside the scope of this document (such as encryption) to provide appropriate protection. Users concerned about traffic analysis should consider appropriate use of link encryption. If absolute location privacy is desired, the mobile node can create a tunnel to its home agent. Then, datagrams destined for correspondent nodes will appear to emanate from the home network, and it may be more difficult to pinpoint the location of the mobile node. Such mechanisms are all beyond the scope of this document.
5.6. Replay Protection for Registration Requests The Identification field is used to let the home agent verify that a registration message has been freshly generated by the mobile node, not replayed by an attacker from some previous registration. Two methods are described in this section: timestamps (mandatory) and "nonces" (optional). All mobile nodes and home agents MUST implement timestamp-based replay protection. These nodes MAY also implement nonce-based replay protection (but see Appendix A.2 for a patent that may apply to nonce-based replay protection). The style of replay protection in effect between a mobile node and its home agent is part of the mobile security association. A mobile node and its home agent MUST agree on which method of replay protection will be used. The interpretation of the Identification field depends on the method of replay protection as described in the subsequent subsections. Whatever method is used, the low-order 32 bits of the Identification MUST be copied unchanged from the Registration Request to the Reply. The foreign agent uses those bits (and the mobile node's home address) to match Registration Requests with corresponding replies. The mobile node MUST verify that the low-order 32 bits of any Registration Reply are identical to the bits it sent in the Registration Request. The Identification in a new Registration Request MUST NOT be the same as in an immediately preceding Request, and SHOULD NOT repeat while the same security context is being used between the mobile node and the home agent. Retransmission as in Section 3.6.3 is allowed. 5.6.1. Replay Protection using Timestamps The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Obviously the two nodes must have adequately synchronized time-of-day clocks. As with any messages, time synchronization messages may be protected against tampering by an authentication mechanism determined by the security context between the two nodes. If timestamps are used, the mobile node MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol [13]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits which are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit Identification
used in a Registration Request from the mobile node MUST be greater than that used in any previous Registration Request, as the home agent uses this field also as a sequence number. Without such a sequence number, it would be possible for a delayed duplicate of an earlier Registration Request to arrive at the home agent (within the clock synchronization required by the home agent), and thus be applied out of order, mistakenly altering the mobile node's current registered care-of address. Upon receipt of a Registration Request with a valid Mobile-Home Authentication Extension, the home agent MUST check the Identification field for validity. In order to be valid, the timestamp contained in the Identification field MUST be close enough to the home agent's time of day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting mobile node. Time tolerances and resynchronization details are specific to a particular mobility security association. If the timestamp is valid, the home agent copies the entire Identification field into the Registration Reply it returns the Reply to the mobile node. If the timestamp is not valid, the home agent copies only the low-order 32 bits into the Registration Reply, and supplies the high-order 32 bits from its own time of day. In this latter case, the home agent MUST reject the registration by returning Code 133 (identification mismatch) in the Registration Reply. As described in Section 3.6.2.1, the mobile node MUST verify that the low-order 32 bits of the Identification in the Registration Reply are identical to those in the rejected registration attempt, before using the high-order bits for clock resynchronization. 5.6.2. Replay Protection using Nonces Implementors of this optional mechanism should examine Appendix A.2 for a patent that may be applicable to nonce-based replay protection. The basic principle of nonce replay protection is that node A includes a new random number in every message to node B, and checks that node B returns that same number in its next message to node A. Both messages use an authentication code to protect against alteration by an attacker. At the same time node B can send its own nonces in all messages to node A (to be echoed by node A), so that it too can verify that it is receiving fresh messages. The home agent may be expected to have resources for computing pseudo-random numbers useful as nonces [7]. It inserts a new nonce as the high-order 32 bits of the identification field of every Registration Reply. The home agent copies the low-order 32 bits of
the Identification from the Registration Request message into the low-order 32 bits of the Identification in the Registration Reply. When the mobile node receives an authenticated Registration Reply from the home agent, it saves the high-order 32 bits of the identification for use as the high-order 32 bits of its next Registration Request. The mobile node is responsible for generating the low-order 32 bits of the Identification in each Registration Request. Ideally it should generate its own random nonces. However it may use any expedient method, including duplication of the random value sent by the home agent. The method chosen is of concern only to the mobile node, because it is the node that checks for valid values in the Registration Reply. The high-order and low-order 32 bits of the identification chosen SHOULD both differ from their previous values. The home agent uses a new high-order value and the mobile node uses a new low-order value for each registration message. The foreign agent uses the low-order value (and the mobile host's home address) to correctly match registration replies with pending Requests (Section 3.7.1). If a registration message is rejected because of an invalid nonce, the Reply always provides the mobile node with a new nonce to be used in the next registration. Thus the nonce protocol is self- synchronizing.
6. Acknowledgments Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp and John Ioannidis (JI) (Columbia), for forming the working group, chairing it, and putting so much effort into its early development. Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li for their contributions to the group while performing the duties of chairperson, as well as for their many useful comments. Thanks to the active members of the Mobile IP Working Group, particularly those who contributed text, including (in alphabetical order) - Ran Atkinson (Naval Research Lab), - Dave Johnson (Carnegie Mellon University), - Frank Kastenholz (FTP Software), - Anders Klemets (KTH), - Chip Maguire (KTH), - Andrew Myles (Macquarie University), - Al Quirt (Bell Northern Research), - Yakov Rekhter (IBM), and - Fumio Teraoka (Sony). Thanks to Charlie Kunzinger and to Bill Simpson, the editors who produced the first drafts for of this document, reflecting the discussions of the Working Group. Much of the new text of this memo is due to Jim Solomon and Dave Johnson. Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank Kastenholz (FTP Software) for their generous support in hosting interim Working Group meetings.
A. Patent Issues As of the time of publication, the IETF had been made aware of two patents that may be relevant to implementors of the protocol described in this technical specification. A.1. IBM Patent #5,159,592 Charles Perkins, editor of this memo, is sole inventor of U.S. Patent No. 5,159,592, assigned to IBM. In a letter dated May 30, 1995, IBM brought this patent to the attention of the IETF, stating that this patent "relates to the Mobile IP." We understand that IBM did not intend to assert that any particular implementation of Mobile IP would or would not infringe the patent, but rather that IBM was meeting what it viewed as a duty to disclose information that could be relevant to the process of adopting a standard. Based on a review of the claims of the patent, IETF believes that a system of registering an address obtained from a foreign agent, as described in the document, would not necessarily infringe any of the claims of the patent; and that a system in which an address is obtained elsewhere and then registered can be implemented without necessarily infringing any claims of the patent. Accordingly, our view is that the proposed protocol can be implemented without necessarily infringing the Perkins Patent. Parties considering adopting this protocol must be aware that some specific implementations, or features added to otherwise non- infringing implementations, may raise an issue of infringement with respect to this patent or to some other patent. This statement is for the IETF's assistance in its standard-setting procedure, and should not be relied upon by any party as an opinion or guarantee that any implementation it might make or use would not be covered by the Perkins Patent and any other patents. In particular, IBM might disagree with the interpretation of this patent described herein. A.2. IBM Patent #5,148,479 This patent, also assigned to IBM, may be relevant to those who implement nonce-based replay protection as described in Section 5.6.2. Note that nonce-based replay protection is an optional feature of this specification. Timestamp-based replay protection, on the other hand, (Section 5.6.1) is a requirement of this specification.
B. Link-Layer Considerations The mobile node MAY use link-layer mechanisms to decide that its point of attachment has changed. Such indications include the Down/Testing/Up interface status [11], and changes in cell or administration. The mechanisms will be specific to the particular link-layer technology, and are outside the scope of this document. The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol Control Protocol (IPCP) [12], negotiates the use of IP addresses. The mobile node SHOULD first attempt to specify its home address, so that if the mobile node is attaching to its home network, the unrouted link will function correctly. When the home address is not accepted by the peer, but a transient IP address is dynamically assigned to the mobile node, and the mobile node is capable of supporting a co-located care-of address, the mobile node MAY register that address as a co-located care-of address. When the peer specifies its own IP address, that address MUST NOT be assumed to be a foreign agent care-of address or the IP address of a home agent. C. TCP Considerations C.1. TCP Timers Most hosts and routers which implement TCP/IP do not permit easy configuration of the TCP timer values. When high-delay (e.g., SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are in use, the default TCP timer values in many systems may cause retransmissions or timeouts, even when the link and network are actually operating properly with greater than usual delays because of the medium in use. This can cause an inability to create or maintain TCP connections over such links, and can also cause unneeded retransmissions which consume already scarce bandwidth. Vendors are encouraged to make TCP timers more configurable. Vendors of systems designed for the mobile computing markets should pick default timer values more suited to low-bandwidth, high-delay links. Users of mobile nodes should be sensitive to the possibility of timer-related difficulties. C.2. TCP Congestion Management Mobile nodes often use media which are more likely to introduce errors, effectively causing more packets to be dropped. This introduces a conflict with the mechanisms for congestion management found in modern versions of TCP [9]. Now, when a packet is dropped, the correspondent node's TCP implementation is likely to react as if there were a source of network congestion, and initiate the slow-
start mechanisms [9] designed for controlling that problem. However, those mechanisms are inappropriate for overcoming errors introduced by the links themselves, and have the effect of magnifying the discontinuity introduced by the dropped packet. This problem has been analyzed by Caceres, et al. [3]; there is no easy solution available, and certainly no solution likely to be installed soon on all correspondent nodes. While this problem is beyond the scope of this document, it does illustrate that providing performance transparency to mobile nodes involves understanding mechanisms outside the network layer. It also indicates the need to avoid designs which systematically drop packets; such designs might otherwise be considered favorably when making engineering tradeoffs. D. Example Scenarios This section shows example Registration Requests for several common scenarios. D.1. Registering with a Foreign Agent Care-of Address The mobile node receives an Agent Advertisement from a foreign agent and wishes to register with that agent using the advertised foreign agent care-of address. The mobile node wishes only IP-in-IP encapsulation, does not want broadcasts, and does not want simultaneous mobility bindings: IP fields: Source Address = mobile node's home address Destination Address = copied from the IP source address of the Agent Advertisement Time to Live = 1 UDP fields: Source Port = <any> Destination Port = 434 Registration Request fields: Type = 1 S=0,B=0,D=0,M=0,G=0 Lifetime = the Registration Lifetime copied from the Mobility Agent Advertisement Extension of the Router Advertisement message Home Address = the mobile node's home address Home Agent = IP address of mobile node's home agent Care-of Address = the Care-of Address copied from the Mobility Agent Advertisement Extension of the Router Advertisement message Identification = Network Time Protocol timestamp or Nonce Extensions: The Mobile-Home Authentication Extension
D.2. Registering with a Co-Located Care-of Address The mobile node enters a foreign network that contains no foreign agents. The mobile node obtains an address from a DHCP server [6] for use as a co-located care-of address. The mobile node supports all forms of encapsulation (IP-in-IP, minimal encapsulation, and GRE), desires a copy of broadcast datagrams on the home network, and does not want simultaneous mobility bindings: IP fields: Source Address = care-of address obtained from DHCP server Destination Address = IP address of home agent Time to Live = 64 UDP fields: Source Port = <any> Destination Port = 434 Registration Request fields: Type = 1 S=0,B=1,D=1,M=1,G=1 Lifetime = 1800 (seconds) Home Address = the mobile node's home address Home Agent = IP address of mobile node's home agent Care-of Address = care-of address obtained from DHCP server Identification = Network Time Protocol timestamp or Nonce Extensions: The Mobile-Home Authentication Extension
D.3. Deregistration The mobile node returns home and wishes to deregister all care-of addresses with its home agent. IP fields: Source Address = mobile node's home address Destination Address = IP address of home agent Time to Live = 1 UDP fields: Source Port = <any> Destination Port = 434 Registration Request fields: Type = 1 S=0,B=0,D=0,M=0,G=0 Lifetime = 0 Home Address = the mobile node's home address Home Agent = IP address of mobile node's home agent Care-of Address = the mobile node's home address Identification = Network Time Protocol timestamp or Nonce Extensions: The Mobile-Home Authentication Extension E. Applicability of Prefix Lengths Extension Caution is indicated with the use of the Prefix Lengths Extension over wireless links, due to the irregular coverage areas provided by wireless transmitters. As a result, it is possible that two foreign agents advertising the same prefix might indeed provide different connectivity to prospective mobile nodes. The Prefix-Lengths Extension SHOULD NOT be included in the advertisements sent by agents in such a configuration.
Foreign agents using different wireless interfaces would have to cooperate using special protocols to provide identical coverage in space, and thus be able to claim to have wireless interfaces situated on the same subnetwork. In the case of wired interfaces, a mobile node disconnecting and subsequently connecting to a new point of attachment, may well send in a new Registration Request no matter whether the new advertisement is on the same medium as the last recorded advertisement. And, finally, in areas with dense populations of foreign agents it would seem unwise to require the propagation via routing protocols of the subnet prefixes associated with each individual wireless foreign agent; such a strategy could lead to quick depletion of available space for routing tables, unwarranted increases in the time required for processing routing updates, and longer decision times for route selection if routes (which are almost always unnecessary) are stored for wireless "subnets". References [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989. [3] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on Selected Areas in Communications, 13(5):850--857, June 1995. [4] Deering, S., Editor, "ICMP Router Discovery Messages", RFC 1256, September 1991. [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993. [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994. [8] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [9] Van Jacobson. Congestion Avoidance and Control. In Proceedings of the SIGCOMM '88 Symposium: Communications Architectures & Protocols, pages 314--329, August 1988.
[10] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [11] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994. [12] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [13] Mills, D., "Network Time Protocol (Version 3): Specification, Implementation and Analysis", RFC 1305, March 1992. [14] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [16] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [18] Postel, J., "Multi-LAN Address Resolution", RFC 925, October 1984. [19] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981. [20] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [21] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [22] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, Reading, Massachusetts, 1994.
Editor's Address Questions about this memo can also be directed to the editor: Charles Perkins Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-6205 EMail: perk@watson.ibm.com The working group can be contacted via the current chair: Jim Solomon Motorola, Inc. 1301 E. Algonquin Rd. Schaumburg, IL 60196 Work: +1-847-576-2753 EMail: solomon@comm.mot.com