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
nested 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 nested tunneling of datagrams.
4.6. ARP, Proxy ARP, and Gratuitous ARP
The use of ARP [36] 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 [39] 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 [36],
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 [45] 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 [36], 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 [36].
While a mobile node is registered on a foreign network, its home
agent uses proxy ARP [39] 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 [39], 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 home agent. The 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 unicast 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. In the gratuitous ARP, the ARP Sender Hardware
Address is set to the link-layer address of the home agent.
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. In this
gratuitous ARP, the ARP Sender Hardware Address is set to the
link-layer address of the mobile node.
- 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. In this gratuitous ARP, the ARP Sender
Hardware Address is set to the link-layer address of the mobile
node. If, instead, the home agent rejects the Registration
Request, the home agent MUST NOT make any change to the way it
performs ARP processing (gratuitous nor proxy) for the mobile
node. In this latter case, the home agent should operate as if
the mobile node has not returned home, and continue to perform
proxy ARP on behalf of the mobile node.
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 HMAC-MD5 [23], with a key size of 128 bits.
The foreign agent MUST also support authentication using HMAC-MD5 and
key sizes of 128 bits or greater, with manual key distribution. Keys
with arbitrary binary values MUST be supported.
The "prefix+suffix" use of MD5 to protect data and a shared secret is
considered vulnerable to attack by the cryptographic community.
Where backward compatibility with existing Mobile IP implementations
that use this mode is needed, new implementations SHOULD include
keyed MD5 [41] as one of the additional authentication algorithms for
use when producing and verifying the authentication data that is
supplied with Mobile IP registration messages, for instance in the
extensions specified in sections 3.5.2, 3.5.3, and 3.5.4.
More authentication algorithms, algorithm modes, key distribution
methods, and key sizes MAY also be supported for all of these
extensions.
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. [14] 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. Ingress Filtering
Many routers implement security policies such as "ingress filtering"
[15] that do not allow forwarding of packets that have a Source
Address which appears topologically incorrect. In environments where
this is a problem, mobile nodes may use reverse tunneling [27] with
the foreign agent supplied care-of address as the Source Address.
Reverse tunneled packets will be able to pass normally through such
routers, while ingress filtering rules will still be able to locate
the true topological source of the packet in the same way as packets
from non-mobile nodes.
5.7. 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).
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.7.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. Unless specified differently in the
security association between the nodes, a default value of 7 seconds
MAY be used to limit the time difference. This value SHOULD be
greater than 3 seconds. 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 [26]. 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 an authorization-enabling
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.7.2. Replay Protection using Nonces
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 [14]. 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. IANA Considerations
Mobile IP specifies several new number spaces for values to be used
in various message fields. These number spaces include the
following:
- Mobile IP message types sent to UDP port 434, as defined in
section 1.8.
- types of extensions to Registration Request and Registration
Reply messages (see sections 3.3 and 3.4, and also consult [27,
29, 6, 7, 12])
- values for the Code in the Registration Reply message (see
section 3.4, and also consult [27, 29, 6, 7, 12])
- Mobile IP defines so-called Agent Solicitation and Agent
Advertisement messages. These messages are in fact Router
Discovery messages [10] augmented with mobile-IP specific
extensions. Thus, they do not define a new name space, but do
define additional Router Discovery extensions as described
below in Section 6.2. Also see Section 2.1 and consult [7,
12].
There are additional Mobile IP numbering spaces specified in [7].
Information about assignment of mobile-ip numbers derived from
specifications external to this document is given by IANA at
http://www.iana.org/numbers.html. From that URL, follow the
hyperlinks to [M] within the "Directory of General Assigned Numbers",
and subsequently to the specific section for "Mobile IP Numbers".
6.1. Mobile IP Message Types
Mobile IP messages are defined to be those that are sent to a message
recipient at port 434 (UDP or TCP). The number space for Mobile IP
messages is specified in Section 1.8. Approval of new extension
numbers is subject to Expert Review, and a specification is required
[30]. The currently standardized message types have the following
numbers, and are specified in the indicated sections.
Type Name Section
---- -------------------------------------------- ---------
1 Registration Request 3.3
3 Registration Reply 3.4
6.2. Extensions to RFC1256 Router Advertisement
RFC1256 defines two ICMP message types, Router Advertisement and
Router Solicitation. Mobile IP defines a number space for extensions
to Router Advertisement, which could be used by protocols other than
Mobile IP. The extension types currently standardized for use with
Mobile IP have the following numbers.
Type Name Reference
---- -------------------------------------------- ---------
0 One-byte Padding 2.1.3
16 Mobility Agent Advertisement 2.1.1
19 Prefix-Lengths 2.1.2
Approval of new extension numbers for use with Mobile IP is subject
to Expert Review, and a specification is required [30].
6.3. Extensions to Mobile IP Registration Messages
The Mobile IP messages, specified within this document, and listed in
sections 1.8 and 6.1, may have extensions. Mobile IP message
extensions all share the same number space, even if they are to be
applied to different Mobile IP messages. The number space for Mobile
IP message extensions is specified within this document. Approval of
new extension numbers is subject to Expert Review, and a
specification is required [30].
Type Name Reference
---- -------------------------------------------- ---------
0 One-byte Padding
32 Mobile-Home Authentication 3.5.2
33 Mobile-Foreign Authentication 3.5.3
34 Foreign-Home Authentication 3.5.4
6.4. Code Values for Mobile IP Registration Reply Messages
The Mobile IP Registration Reply message, specified in section 3.4,
has a Code field. The number space for the Code field values is also
specified in Section 3.4. The Code number space is structured
according to whether the registration was successful, or whether the
foreign agent denied the registration request, or lastly whether the
home agent denied the registration request, as follows:
0-8 Success Codes
9-63 No allocation guidelines currently exist
64-127 Error Codes from the Foreign Agent
128-192 Error Codes from the Home Agent
193-255 No allocation guidelines currently exist
Approval of new Code values requires Expert Review [30].
7. Acknowledgments
Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp
and John Ioannidis (JI) (Columbia University), for forming the
working group, chairing it, and putting so much effort into its early
development. Columbia's early Mobile IP work can be found in [18,
19, 17].
Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon,
Erik Nordmark, Basavaraj Patil, and Phil Roberts 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),
- Samita Chakrabarti (Sun Microsystems)
- Ken Imboden (Candlestick Networks, Inc.)
- Dave Johnson (Carnegie Mellon University),
- Frank Kastenholz (FTP Software),
- Anders Klemets (KTH),
- Chip Maguire (KTH),
- Alison Mankin (ISI)
- Andrew Myles (Macquarie University),
- Thomas Narten (IBM)
- Al Quirt (Bell Northern Research),
- Yakov Rekhter (IBM), and
- Fumio Teraoka (Sony).
- Alper Yegin (NTT DoCoMo)
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 in the later
revisions preceding RFC2002 is due to Jim Solomon and Dave Johnson.
Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank
Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for
their generous support in hosting interim Working Group meetings.
Sections 1.10 and 1.11, which specify new extension formats to be
used with aggregatable extension types, were included from a
specification document (entitled "Mobile IP Extensions
Rationalization (MIER)", which was written by
- Mohamed M.Khalil, Nortel Networks
- Raja Narayanan, nVisible Networks
- Haseeb Akhtar, Nortel Networks
- Emad Qaddoura, Nortel Networks
Thanks to these authors, and also for the additional work on
MIER, which was contributed by Basavaraj Patil, Pat Calhoun, Neil
Justusson, N. Asokan, and Jouni Malinen.
A. Patent Issues
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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 [24], 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) [42] and its Internet Protocol
Control Protocol (IPCP) [25], 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.
PPP extensions for Mobile IP have been specified in RFC2290 [44].
Please consult that document for additional details for how to handle
care-of address assignment from PPP in a more efficient manner.
C. TCP Considerations
C.1. TCP Timers
When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency
Radio) links are in use, some TCP stacks may have insufficiently
adaptive (non-standard) retransmission timeouts. There may be
spurious retransmission timeouts, even when the link and network
are actually operating properly, but just with a high delay 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 follow the algorithms in RFC2988 [31] when
implementing TCP retransmission timers. Vendors of systems designed
for low-bandwidth, high-delay links should consult RFCs 2757 and
2488 [28, 1]. Designers of applications targeted to operate on
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 [21]. 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 [21] 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. [5]. TCP approaches to the problem
of handling errors that might interfere with congestion management
are discussed in documents from the [pilc] working group [3, 9].
While such approaches are beyond the scope of this document,
they illustrate that providing performance transparency to mobile
nodes involves understanding mechanisms outside the network layer.
Problems introduced by higher media error rates also indicate 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:
An authorization-enabling extension (e.g., 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 [13]
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:
An authorization-enabling extension (e.g., 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".
F. Interoperability Considerations
This document specifies revisions to RFC2002 that are intended to
improve interoperability by resolving ambiguities contained in the
earlier text. Implementations that perform authentication according
to the new more precisely specified algorithm would be interoperable
with earlier implementations that did what was originally expected
for producing authentication data. That was a major source of non-
interoperability before.
However, this specification does have new features that, if used,
would cause interoperability problems with older implementations.
All features specified in RFC2002 will work with the new
implementations, except for V-J compression [20]. The following list
details some of the possible areas of compatibility problems that may
be experienced by nodes conforming to this revised specification,
when attempting to interoperate with nodes obeying RFC2002.
- A client that expects some of the newly mandatory features
(like reverse tunneling) from a foreign agent would still be
interoperable as long as it pays attention to the `T' bit.
- Mobile nodes that use the NAI extension to identify themselves
would not work with old mobility agents.
- Mobile nodes that use a zero home address and expect to receive
their home address in the Registration Reply would not work
with old mobility agents.
- Mobile nodes that attempt to authenticate themselves without
using the Mobile-Home authentication extension will be unable
to successful register with their home agent.
In all of these cases, a robust and well-configured mobile node is
very likely to be able to recover if it takes reasonable actions upon
receipt of a Registration Reply with an error code indicating the
cause for rejection. For instance, if a mobile node sends a
registration request that is rejected because it contains the wrong
kind of authentication extension, then the mobile node could retry
the registration with a mobile-home authentication extension, since
the foreign agent and/or home agent in this case will not be
configured to demand the alternative authentication data.
G. Changes since RFC2002
This section details differences between the original Mobile IP base
specification (RFC2002 and ff.) that have been made as part of this
revised protocol specification for Mobile IP.
G.1. Major Changes
- Specification for Destination IP address of Registration Reply
transmitted from Foreign Agent, to avoid any possible
transmission to IP address 0.0.0.0.
- Specification of two new formats for Mobile IP extensions,
according to the ideas contained in MIER.
- Specification that the SPI of the MN-HA authentication
extension is to be used as part of the data over which the
authentication algorithm must be computed.
- Eliminated Van-Jacobson Compression feature
- Specification that foreign agents MAY send advertisements at a
rate faster than once per second, but chosen so that the
advertisements do not burden the capacity of the local link.
For simplicity, the foreign agent now MAY send advertisements
at an interval less than 1/3 the advertised ICMP Lifetime.
- Specification that foreign agents SHOULD support reverse
tunneling, and home agents MUST support decapsulation of
reverse tunnels.
- Changed the preconfiguration requirements in section 3.6 for
the mobile node to reflect the capability, specified in RFC
2794 [6], for the mobile node to identify itself by using its
NAI, and then getting a home address from the Registration
Reply.
- Changed section 3.7.3.1 so that a foreign agent is not required
to discard Registration Replies that have a Home Address field
that does not match any pending Registration Request.
- Allowed registrations to be authenticated by use of a security
association between the mobile node and a suitable
authentication entity acceptable to the home agent. Defined
"Authorization-enabling Extension" to be an authentication
extension that makes a registration message acceptable to the
recipient. This is needed according to specification in [6].
- Mandated that HMAC-MD5 be used instead of the "prefix+suffix"
mode of MD5 as originally mandated in RFC2002.
- Specified that the mobile node SHOULD take the first care-of
address in a list offered by a foreign agent, and MAY try each
subsequent advertised address in turn if the attempted
registrations are rejected by the foreign agent
- Clarification that a mobility agent SHOULD only put its own
addresses into the initial (i.e., not mobility-related) list of
routers in the mobility advertisement. RFC2002 suggests that
a mobility agent might advertise other default routers.
- Specification that a mobile node MUST ignore reserved bits in
Agent Advertisements, as opposed to discarding such
advertisements. In this way, new bits can be defined later,
without affecting the ability for mobile nodes to use the
advertisements even when the newly defined bits are not
understood. Furthermore, foreign agents can set the `R' bit to
make sure that new bits are handled by themselves instead of
some legacy mobility agent.
- Specification that the foreign agent checks to make sure that
the indicated home agent address does not belong to any of its
network interfaces before relaying a Registration Request. If
the check fails, and the foreign agent is not the mobile node's
home agent, then the foreign agent rejects the request with
code 136 (unknown home agent address).
- Specification that, while they are away from the home network,
mobile nodes MUST NOT broadcast ARP packets to find the MAC
address of another Internet node. Thus, the (possibly empty)
list of Router Addresses from the ICMP Router Advertisement
portion of the message is not useful for selecting a default
router, unless the mobile node has some means not involving
broadcast ARP and not specified within this document for
obtaining the MAC address of one of the routers in the list.
Similarly, in the absence of unspecified mechanisms for
obtaining MAC addresses on foreign networks, the mobile node
MUST ignore redirects to other routers on foreign networks.
- Specification that a foreign agent MUST NOT use broadcast ARP
for a mobile node's MAC address on a foreign network. It may
obtain the MAC address by copying the information from an Agent
Solicitation or a Registration Request transmitted from a
mobile node.
- Specification that a foreign agent's ARP cache for the mobile
node's IP address MUST NOT be allowed to expire before the
mobile node's visitor list entry expires, unless the foreign
agent has some way other than broadcast ARP to refresh its MAC
address associated to the mobile node's IP address.
- At the end of section 4.6, clarified that a home agent MUST NOT
make any changes to the way it performs proxy ARP after it
rejects an invalid deregistration request.
- In section 4.2.3, specification that multihomed home agents
MUST use the the address sent to the mobile node in the home
agent field of the registration reply as the source address in
the outer IP header of the encapsulated datagram.
- Inserted 'T' bit into its proper place in the Registration
Request message format (section 3.3).
G.2. Minor Changes
- Allowed registration replies to be processed by the mobile
node, even in the absence of any Mobile-Home Authentication
extension, when containing rejection code by the foreign agent.
- Specification that the foreign agent MAY configure a maximum
number of pending registrations that it is willing to maintain
(typically 5). Additional registrations SHOULD then be
rejected by the foreign agent with code 66. The foreign agent
MAY delete any pending Registration Request after the request
has been pending for more than 7 seconds; in this case, the
foreign agent SHOULD reject the Request with code 78
(registration timeout).
- Relaxation of the requirement that, when a mobile node has
joined a multicast group at the router on the foreign network,
the mobile node MUST use its home address as the source IP
address for multicast packets,
- Clarification that a mobility agent MAY use different settings
for each of the 'R', 'H', and 'F' bits on different network
interfaces.
- Replacement of the terminology "recursive tunneling" by the
terminology "nested tunneling".
- Specification that the mobile node MAY use the IP source
address of an agent advertisement as its default router
address.
- Clarification that keys with arbitrary binary values MUST be
supported as part of mobility security associations.
- Specification that the default value may be chosen as 7
seconds, for allowable time skews between a home agent and
mobile node using timestamps for replay protection. Further
specification that this value SHOULD be greater than 3 seconds.
- Specification that Registration Requests with the 'D' bit set
to 0, and specifying a care-of address not offered by the
foreign agent, MUST be rejected with code 77 (invalid care-of
address).
- Clarification that the foreign agent SHOULD consider its own
maximum value when handling the Lifetime field of the