3.7.3.2. Forwarding Replies to the Mobile Node
A Registration Reply which satisfies the validity checks of Section
3.8.2.1 is relayed to the mobile node. The foreign agent MUST also
update its visitor list entry for the mobile node to reflect the
results of the Registration Request, as indicated by the Code field
in the Reply. If the Code indicates that the mobile node has
accepted the registration and the Lifetime field is nonzero, the
foreign agent MUST set the Lifetime in the visitor list entry to the
value specified in the Lifetime field of the Registration Reply. If,
instead, the Code indicates that the Lifetime field is zero, the
foreign agent MUST delete its visitor list entry for the mobile node.
Finally, if the Code indicates that the registration was denied by
the home agent, the foreign agent MUST delete its pending
registration list entry, but not its visitor list entry, for the
mobile node.
The foreign agent MUST NOT modify any of the fields beginning with
the fixed portion of the Registration Reply up through and including
the Mobile-Home Authentication Extension. Otherwise, an
authentication failure is very likely to occur at the mobile node.
In addition, the foreign agent SHOULD perform the following
additional procedures:
- It MUST process and remove any Extensions following the
Mobile-Home Authentication Extension,
- It MAY append its own non-authentication Extensions of relevance
to the mobile node, if applicable, and
- It MUST append the Mobile-Foreign Authentication Extension, if
the foreign agent shares a mobility security association with the
mobile node.
Specific fields within the IP header and the UDP header of the
relayed Registration Reply are set according to the same rules
specified in Section 3.7.2.3.
After forwarding a valid Registration Reply to the mobile node, the
foreign agent MUST update its visitor list entry for this
registration as follows. If the Registration Reply indicates that
the registration was accepted by the home agent, the foreign agent
resets its timer of the lifetime of the registration to the Lifetime
granted in the Registration Reply; unlike the mobile node's timing of
the registration lifetime as described in Section 3.6.2.2, the
foreign agent considers this lifetime to begin when it forwards the
Registration Reply message, ensuring that the foreign agent will not
expire the registration before the mobile node does. On the other
hand, if the Registration Reply indicates that the registration was
rejected by the home agent, the foreign agent deletes its visitor
list entry for this attempted registration.
3.8. Home Agent Considerations
Home agents play a reactive role in the registration process. The
home agent receives Registration Requests from the mobile node
(perhaps relayed by a foreign agent), updates its record of the
mobility bindings for this mobile node, and issues a suitable
Registration Reply in response to each.
A home agent MUST NOT transmit a Registration Reply except when
replying to a Registration Request received from a mobile node. In
particular, the home agent MUST NOT generate a Registration Reply to
indicate that the Lifetime has expired.
3.8.1. Configuration and Registration Tables
Each home agent MUST be configured with an IP address and with the
prefix size for the home network. The home agent MUST be configured
with the home address and mobility security association of each
authorized mobile node that it is serving as a home agent. When the
home agent accepts a valid Registration Request from a mobile node
that it serves as a home agent, the home agent MUST create or modify
the entry for this mobile node in its mobility binding list
containing:
- the mobile node's care-of address
- the Identification field from the Registration Reply
- the remaining Lifetime of the registration
The home agent MAY also maintain mobility security associations with
various foreign agents. When receiving a Registration Request from a
foreign agent, if the home agent shares a mobility security
association with the foreign agent, the home agent MUST check the
Authenticator in the required Foreign-Home Authentication Extension
in the message, based on this mobility security association.
Similarly, when sending a Registration Reply to a foreign agent, if
the home agent shares a mobility security association with the
foreign agent, the home agent MUST include a Foreign-Home
Authentication Extension in the message, based on this mobility
security association.
3.8.2. Receiving Registration Requests
If the home agent accepts an incoming Registration Request, it MUST
update its record of the the mobile node's mobility binding(s) and
SHOULD send a Registration Reply with a suitable Code. Otherwise
(the home agent denies the Request), it SHOULD send a Registration
Reply with an appropriate Code specifying the reason the Request was
denied. The following sections describe this behavior in more
detail.
3.8.2.1. Validity Checks
Registration Requests with an invalid, non-zero UDP checksum MUST be
silently discarded by the home agent.
The authentication in the Registration Request MUST be checked. This
involves the following operations:
a) The home agent MUST check for the presence of a valid
Mobile-Home Authentication Extension, and perform the
indicated authentication. Exactly one Mobile-Home
Authentication Extension MUST be present in the Registration
Request, and the home agent MUST check the Authenticator
value in the Extension. If no Mobile-Home Authentication
Extension is found, or if more than one Mobile-Home
Authentication Extension is found, or if the Authenticator
is invalid, the home agent MUST reject the mobile node's
registration and SHOULD send a Registration Reply to the
mobile node with Code 131. The home agent MUST then discard
the Request and SHOULD log the error as a security exception.
b) The home agent MUST check that the registration
Identification field is correct using the context selected by
the SPI within the Mobile-Home Authentication Extension. See
Section 5.6 for a description of how this is performed. If
incorrect, the home agent MUST reject the Request and SHOULD
send a Registration Reply to the mobile node with Code 133,
including an Identification field computed in accordance with
the rules specified in Section 5.6. The home agent MUST do
no further processing with such a Request, though it SHOULD
log the error as a security exception.
c) If the home agent shares a mobility security association with
the foreign agent, the home agent MUST check for the presence
of a valid Foreign-Home Authentication Extension. Exactly
one Foreign-Home Authentication Extension MUST be present in
the Registration Request in this case, and the home agent
MUST check the Authenticator value in the Extension. If no
Foreign-Home Authentication Extension is found, or if more
than one Foreign-Home Authentication Extension is found, or
if the Authenticator is invalid, the home agent MUST reject
the mobile node's registration and SHOULD send a Registration
Reply to the mobile node with Code 132. The home agent
MUST then discard the Request and SHOULD log the error as a
security exception.
In addition to checking the authentication in the Registration
Request, home agents MUST deny Registration Requests that are sent to
the subnet-directed broadcast address of the home network (as opposed
to being unicast to the home agent). The home agent MUST discard the
Request and SHOULD returning a Registration Reply with a Code of 136.
In this case, the Registration Reply will contain the home agent's
unicast address, so that the mobile node can re-issue the
Registration Request with the correct home agent address.
3.8.2.2. Accepting a Valid Request
If the Registration Request satisfies the validity checks in Section
3.8.2.1, and the home agent is able to accommodate the Request, the
home agent MUST update its mobility binding list for the requesting
mobile node and MUST return a Registration Reply to the mobile node.
In this case, the Reply Code will be either 0 if the home agent
supports simultaneous mobility bindings, or 1 if it does not. See
Section 3.8.3 for details on building the Registration Reply message.
The home agent updates its record of the mobile node's mobility
bindings as follows, based on the fields in the Registration Request:
- If the Lifetime is zero and the Care-of Address equals the mobile
node's home address, the home agent deletes all of the entries in
the mobility binding list for the requesting mobile node. This
is how a mobile node requests that its home agent cease providing
mobility services.
- If the Lifetime is zero and the Care-of Address does not equal
the mobile node's home address, the home agent deletes only the
entry containing the specified Care-of Address from the mobility
binding list for the requesting mobile node. Any other active
entries containing other care-of addresses will remain active.
- If the Lifetime is nonzero, the home agent adds an entry
containing the requested Care-of Address to the mobility binding
list for the mobile node. If the 'S' bit is set and the home
agent supports simultaneous mobility bindings, the previous
mobility binding entries are retained. Otherwise, the home agent
removes all previous entries in the mobility binding list for the
mobile node.
In all cases, the home agent MUST send a Registration Reply to the
source of the Registration Request, which might indeed be a different
foreign agent than that whose care-of address is being
(de)registered. If the home agent shares a mobility security
association with the foreign agent whose care-of address is being
deregistered, and that foreign agent is different from the one which
relayed the Registration Request, the home agent MAY additionally
send a Registration Reply to the foreign agent whose care-of address
is being deregistered. The home agent MUST NOT send such a Reply if
it does not share a mobility security association with the foreign
agent. If no Reply is sent, the foreign agent's visitor list will
expire naturally when the original Lifetime expires.
The home agent MUST NOT increase the Lifetime above that specified by
the mobile node in the Registration Request. However, it is not an
error for the mobile node to request a Lifetime longer than the home
agent is willing to accept. In this case, the home agent simply
reduces the Lifetime to a permissible value and returns this value in
the Registration Reply. The Lifetime value in the Registration Reply
informs the mobile node of the granted lifetime of the registration,
indicating when it SHOULD re-register in order to maintain continued
service. After the expiration of this registration lifetime, the
home agent MUST delete its entry for this registration in its
mobility binding list.
If the Registration Request duplicates an accepted current
Registration Request, the new Lifetime MUST NOT extend beyond the
Lifetime originally granted. A Registration Request is a duplicate
if the home address, care-of address, and Identification fields all
equal those of an accepted current registration.
In addition, if the home network implements ARP [16], and the
Registration Request asks the home agent to create a mobility binding
for a mobile node which previously had no binding (the mobile node
was previously assumed to be at home), then the home agent MUST
follow the procedures described in Section 4.6 with regard to ARP,
proxy ARP, and gratuitous ARP. If the mobile node already had a
previous mobility binding, the home agent MUST continue to follow the
rules for proxy ARP described in Section 4.6.
3.8.2.3. Denying an Invalid Request
If the Registration Reply does not satisfy all of the validity checks
in Section 3.8.2.1, or the home agent is unable to accommodate the
Request, the home agent SHOULD return a Registration Reply to the
mobile node with a Code that indicates the reason for the error. If
a foreign agent was involved in relaying the Request, this allows the
foreign agent to delete its pending visitor list entry. Also, this
informs the mobile node of the reason for the error such that it may
attempt to fix the error and issue another Request.
This section lists a number of reasons the home agent might reject a
Request, and provides the Code value it should use in each instance.
See Section 3.8.3 for additional details on building the Registration
Reply message.
Many reasons for rejecting a registration are administrative in
nature. For example, a home agent can limit the number of
simultaneous registrations for a mobile node, by rejecting any
registrations that would cause its limit to be exceeded, and
returning a Registration Reply with error code 135. Similarly, a
home agent may refuse to grant service to mobile nodes which have
entered unauthorized service areas by returning a Registration Reply
with a Code of 129.
If the Reserved field is nonzero, it MUST deny the Request with a
Code of 134.
3.8.3. Sending Registration Replies
If the home agent accepts a Registration Request, it then MUST update
its record of the mobile node's mobility binding(s) and SHOULD send a
Registration Reply with a suitable Code. Otherwise (the home agent
has denied the Request), it SHOULD send a Registration Reply with an
appropriate Code specifying the reason the Request was denied. The
following sections provide additional detail for the values the home
agent MUST supply in the fields of Registration Reply messages.
3.8.3.1. IP/UDP Fields
This section provides the specific rules by which mobile nodes pick
values for the IP and UDP header fields of a Registration Reply.
IP Source Address
Copied from the IP Destination Address of Registration
Request, unless a multicast or broadcast address was
used. If the IP Destination Address of the Registration
Request was a broadcast or multicast address, the IP
Source Address of the Registration Reply MUST be set to
the home agent's (unicast) IP address.
IP Destination Address
Copied from the IP Source Address of the Registration
Request.
UDP Source Port
Copied from the UDP Destination Port of the Registration
Request.
UDP Destination Port
Copied from the UDP Source Port of the Registration
Request.
When sending a Registration Reply in response to a Registration
Request that requested deregistration of the mobile node (the
Lifetime is zero and the Care-of Address equals the mobile node's
home address) and in which the IP Source Address was also set to the
mobile node's home address (this is the normal method used by a
mobile node to deregister when it returns to its home network), the
IP Destination Address in the Registration Reply will be set to the
mobile node's home address, as copied from the IP Source Address of
the Request.
In this case, when transmitting the Registration Reply, the home
agent MUST transmit the Reply directly onto the home network as if
the mobile node were at home, bypassing any mobility binding list
entry that may still exist at the home agent for the destination
mobile node. In particular, for a mobile node returning home after
being registered with a care-of address, if the mobile node's new
Registration Request is not accepted by the home agent, the mobility
binding list entry for the mobile node will still indicate that
datagrams addressed to the mobile node should be tunneled to the
mobile node's registered care-of address; when sending the
Registration Reply indicating the rejection of this Request, this
existing binding list entry MUST be ignored, and the home agent MUST
transmit this Reply as if the mobile node were at home.
3.8.3.2. Registration Reply Fields
This section provides specific rules by which home agents pick values
for the fields within the fixed portion of a Registration Reply. The
Code field of the Registration Reply is chosen in accordance with the
rules specified in the previous sections. When replying to an
accepted registration, a home agent SHOULD respond with Code 1 if it
does not support simultaneous registrations.
The Lifetime field MUST be copied from the corresponding field in the
Registration Request, unless the requested value is greater than the
maximum length of time the home agent is willing to provide the
requested service. In such a case, the Lifetime MUST be set to the
length of time that service will actually be provided by the home
agent. This reduced Lifetime SHOULD be the maximum Lifetime allowed
by the home agent (for this mobile node and care-of address).
The Home Address field MUST be copied from the corresponding field in
the Registration Request.
If the Home Agent field in the Registration Request contains a
unicast address of this home agent, then that field MUST be copied
into the Home Agent field of the Registration Reply. Otherwise, the
home agent MUST set the Home Agent field in the Registration Reply to
its unicast address. In this latter case, the home agent MUST reject
the registration with a suitable code (e.g., Code 136) to prevent the
mobile node from possibly being simultaneously registered with two or
more home agents.
3.8.3.3. Extensions
This section describes the ordering of any required and any optional
Mobile IP Extensions that a home agent appends to a Registration
Reply. The following ordering MUST be followed:
a) The IP header, followed by the UDP header, followed by the
fixed-length portion of the Registration Reply,
b) If present, any non-authentication Extensions used by the
mobile node (which may or may not also be used by the foreign
agent),
c) The Mobile-Home Authentication Extension,
d) If present, any non-authentication Extensions used only by
the foreign agent, and
e) The Foreign-Home Authentication Extension, if present.
Note that items (a) and (c) MUST appear in every Registration Reply
sent by the home agent. Items (b), (d), and (e) are optional.
However, item (e) MUST be included when the home agent and the
foreign agent share a mobility security association.
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