RFC 2002
IP Mobility Support
3. Registration Mobile IP registration provides a flexible mechanism for mobile nodes to communicate their current reachability information to their home agent. It is the method by which mobile nodes: - request forwarding services when visiting a foreign network, - inform their home agent of their current care-of address, - renew a registration which is due to expire, and/or - deregister when they return home. Registration messages exchange information between a mobile node, (optionally) a foreign agent, and the home agent. Registration creates or modifies a mobility binding at the home agent, associating the mobile node's home address with its care-of address for the specified Lifetime.
Several other (optional) capabilities are available through the
registration procedure, which enable a mobile node to:
- maintain multiple simultaneous registrations, so that a copy of
each datagram will be tunneled to each active care-of address
- deregister specific care-of addresses while retaining other
mobility bindings, and
- discover the address of a home agent if the mobile node is not
configured with this information.
3.1. Registration Overview
Mobile IP defines two different registration procedures, one via a
foreign agent that relays the registration to the mobile node's home
agent, and one directly with the mobile node's home agent. The
following rules determine which of these two registration procedures
to use in any particular circumstance:
- If a mobile node is registering a foreign agent care-of address,
the mobile node MUST register via that foreign agent.
- If a mobile node is using a co-located care-of address, and
receives an Agent Advertisement from a foreign agent on the
link on which it is using this care-of address, the mobile node
SHOULD register via that foreign agent (or via another foreign
agent on this link) if the 'R' bit is set in the received Agent
Advertisement message.
- If a mobile node is otherwise using a co-located care-of address,
the mobile node MUST register directly with its home agent.
- If a mobile node has returned to its home network and is
(de)registering with its home agent, the mobile node MUST
register directly with its home agent.
Both registration procedures involve the exchange of Registration
Request and Registration Reply messages (Sections 3.3 and 3.4). When
registering via a foreign agent, the registration procedure requires
the following four messages:
a) The mobile node sends a Registration Request to the
prospective foreign agent to begin the registration process.
b) The foreign agent processes the Registration Request and then
relays it to the home agent.
c) The home agent sends a Registration Reply to the foreign
agent to grant or deny the Request.
d) The foreign agent processes the Registration Reply and then
relays it to the mobile node to inform it of the disposition
of its Request.
When the mobile node instead registers directly with its home agent,
the registration procedure requires only the following two messages:
a) The mobile node sends a Registration Request to the home
agent.
b) The home agent sends a Registration Reply to the mobile
node, granting or denying the Request.
The registration messages defined in Sections 3.3 and 3.4 use the
User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be
included in the header, and MUST be checked by the recipient.
3.2. Authentication
Each mobile node, foreign agent, and home agent MUST be able to
support a mobility security association for mobile entities, indexed
by their SPI and IP address. In the case of the mobile node, this
must be its Home Address. See Section 5.1 for requirements for
support of authentication algorithms. Registration messages between
a mobile node and its home agent MUST be authenticated with the
Mobile-Home Authentication Extension (Section 3.5.2). This Extension
immediately follows all non-authentication Extensions, except those
foreign agent-specific Extensions which may be added to the message
after the mobile node computes the authentication.
3.3. Registration Request
A mobile node registers with its home agent using a Registration
Request message so that its home agent can create or modify a
mobility binding for that mobile node (e.g., with a new lifetime).
The Request may be relayed to the home agent by the foreign agent
through which the mobile node is registering, or it may be sent
directly to the home agent in the case in which the mobile node is
registering a co-located care-of address.
IP fields:
Source Address Typically the interface address from which the
message is sent.
Destination Address Typically that of the foreign agent or the
home agent.
See Sections 3.6.1.1 and 3.7.2.2 for details.
UDP fields:
Source Port variable
Destination Port 434
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|V|rsv| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
S Simultaneous bindings. If the 'S' bit is set, the mobile
node is requesting that the home agent retain its prior
mobility bindings, as described in Section 3.6.1.2.
B Broadcast datagrams. If the 'B' bit is set, the mobile
node requests that the home agent tunnel to it any
broadcast datagrams that it receives on the home network,
as described in Section 4.3.
D Decapsulation by mobile node. If the 'D' bit is set, the
mobile node will itself decapsulate datagrams which are
sent to the care-of address. That is, the mobile node is
using a co-located care-of address.
M Minimal encapsulation. If the 'M' bit is set, the
mobile node requests that its home agent use minimal
encapsulation [15] for datagrams tunneled to the mobile
node.
G GRE encapsulation. If the 'G' bit is set, the
mobile node requests that its home agent use GRE
encapsulation [8] for datagrams tunneled to the mobile
node.
V The mobile node requests that its mobility agent use Van
Jacobson header compression [10] over its link with the
mobile node.
rsv Reserved bits; sent as zero
Lifetime
The number of seconds remaining before the registration
is considered expired. A value of zero indicates a
request for deregistration. A value of 0xffff indicates
infinity.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
Care-of Address
The IP address for the end of the tunnel.
Identification
A 64-bit number, constructed by the mobile node, used for
matching Registration Requests with Registration Replies,
and for protecting against replay attacks of registration
messages. See Sections 5.4 and 5.6.
Extensions
The fixed portion of the Registration Request is followed
by one or more of the Extensions listed in Section 3.5.
The Mobile-Home Authentication Extension MUST be included
in all Registration Requests. See Sections 3.6.1.3
and 3.7.2.2 for information on the relative order in
which different extensions, when present, MUST be placed
in a Registration Request message.
3.4. Registration Reply A mobility agent returns a Registration Reply message to a mobile node which has sent a Registration Request (Section 3.3) message. If the mobile node is requesting service from a foreign agent, that foreign agent will receive the Reply from the home agent and subsequently relay it to the mobile node. The Reply message contains the necessary codes to inform the mobile node about the status of its Request, along with the lifetime granted by the home agent, which MAY be smaller than the original Request. The foreign agent MUST NOT increase the Lifetime selected by the mobile node in the Registration Request, since the Lifetime is covered by the Mobile-Home Authentication Extension, which cannot be correctly (re)computed by the foreign agent. The home agent MUST NOT increase the Lifetime selected by the mobile node in the Registration Request, since doing so could increase it beyond the maximum Registration Lifetime allowed by the foreign agent. If the Lifetime received in the Registration Reply is greater than that in the Registration Request, the Lifetime in the Request MUST be used. When the Lifetime received in the Registration Reply is less than that in the Registration Request, the Lifetime in the Reply MUST be used. IP fields: Source Address Typically copied from the destination address of the Registration Request to which the agent is replying. See Sections 3.7.2.3 and 3.8.3.1 for complete details. Destination Address Copied from the source address of the Registration Request to which the agent is replying UDP fields: Source Port <variable> Destination Port Copied from the source port of the corresponding Registration Request (Section 3.7.1).
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 3 (Registration Reply)
Code A value indicating the result of the Registration
Request. See below for a list of currently defined Code
values.
Lifetime
If the Code field indicates that the registration was
accepted, the Lifetime field is set to the number of
seconds remaining before the registration is considered
expired. A value of zero indicates that the mobile node
has been deregistered. A value of 0xffff indicates
infinity. If the Code field indicates that the
registration was denied, the contents of the Lifetime
field are unspecified and MUST be ignored on reception.
Home Address
The IP address of the mobile node.
Home Agent
The IP address of the mobile node's home agent.
Identification
A 64-bit number used for matching Registration Requests
with Registration Replies, and for protecting against
replay attacks of registration messages. The value is
based on the Identification field from the Registration
Request message from the mobile node, and on the style of
replay protection used in the security context between
the mobile node and its home agent (defined by the
mobility security association between them, and SPI
value in the Mobile-Home Authentication Extension). See
Sections 5.4 and 5.6.
Extensions
The fixed portion of the Registration Reply is followed
by one or more of the Extensions listed in Section 3.5.
The Mobile-Home Authentication Extension MUST be included
in all Registration Replies returned by the home agent.
See Sections 3.7.2.2 and 3.8.3.3 for rules on placement
of extensions to Reply messages.
The following values are defined for use within the Code field.
Registration successful:
0 registration accepted
1 registration accepted, but simultaneous mobility
bindings unsupported
Registration denied by the foreign agent:
64 reason unspecified
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 home agent failed authentication
69 requested Lifetime too long
70 poorly formed Request
71 poorly formed Reply
72 requested encapsulation unavailable
73 requested Van Jacobson compression unavailable
80 home network unreachable (ICMP error received)
81 home agent host unreachable (ICMP error received)
82 home agent port unreachable (ICMP error received)
88 home agent unreachable (other ICMP error received)
Registration denied by the home agent:
128 reason unspecified
129 administratively prohibited
130 insufficient resources
131 mobile node failed authentication
132 foreign agent failed authentication
133 registration Identification mismatch
134 poorly formed Request
135 too many simultaneous mobility bindings
136 unknown home agent address
Up-to-date values of the Code field are specified in the most recent
"Assigned Numbers" [20].
3.5. Registration Extensions
3.5.1. Computing Authentication Extension Values
The Authenticator value computed for each authentication Extension
MUST protect the following fields from the registration message:
- the UDP payload (that is, the Registration Request or
Registration Reply data),
- all prior Extensions in their entirety, and
- the Type and Length of this Extension.
The default authentication algorithm uses keyed-MD5 [21] in
"prefix+suffix" mode to compute a 128-bit "message digest" of the
registration message. The default authenticator is a 128-bit value
computed as the MD5 checksum over the the following stream of bytes:
- the shared secret defined by the mobility security association
between the nodes and by SPI value specified in the
authentication Extension, followed by
- the protected fields from the registration message, in the order
specified above, followed by
- the shared secret again.
Note that the Authenticator field itself and the UDP header are NOT
included in the computation of the default Authenticator value. See
Section 5.1 for information about support requirements for message
authentication codes, which are to be used with the various
authentication Extensions.
The Security Parameter Index (SPI) within any of the authentication
Extensions defines the security context which is used to compute the
Authenticator value and which MUST be used by the receiver to check
that value. In particular, the SPI selects the authentication
algorithm and mode (Section 5.1) and secret (a shared key, or
appropriate public/private key pair) used in computing the
Authenticator. In order to ensure interoperability between different
implementations of the Mobile IP protocol, an implementation MUST be
able to associate any SPI value with any authentication algorithm and
mode which it implements. In addition, all implementations of Mobile
IP MUST implement the default authentication algorithm (keyed-MD5)
and mode ("prefix+suffix") defined above.
3.5.2. Mobile-Home Authentication Extension
Exactly one Mobile-Home Authentication Extension MUST be present in
all Registration Requests and Registration Replies, and is intended
to eliminate problems [2] which result from the uncontrolled
propagation of remote redirects in the Internet. The location of the
extension marks the end of the authenticated data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
Authenticator (variable length) (See Section 3.5.1.)
3.5.3. Mobile-Foreign Authentication Extension
This Extension MAY be included in Registration Requests and Replies
in cases in which a mobility security association exists between the
mobile node and the foreign agent. See Section 5.1 for information
about support requirements for message authentication codes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 33
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
Authenticator (variable length) (See Section 3.5.1.)
3.5.4. Foreign-Home Authentication Extension
This Extension MAY be included in Registration Requests and Replies
in cases in which a mobility security association exists between the
foreign agent and the home agent. See Section 5.1 for information
about support requirements for message authentication codes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34
Length 4 plus the number of bytes in the Authenticator.
SPI Security Parameter Index (4 bytes). An opaque
identifier (see Section 1.6).
Authenticator (variable length) (See Section 3.5.1.)
3.6. Mobile Node Considerations
A mobile node MUST be configured with its home address, a netmask,
and a mobility security association for each home agent. In
addition, a mobile node MAY be configured with the IP address of one
or more of its home agents; otherwise, the mobile node MAY discover a
home agent using the procedures described in Section 3.6.1.2.
For each pending registration, the mobile node maintains the
following information:
- the link-layer address of the foreign agent to which the
Registration Request was sent, if applicable,
- the IP destination address of the Registration Request,
- the care-of address used in the registration,
- the Identification value sent in the registration,
- the originally requested Lifetime, and
- the remaining Lifetime of the pending registration.
A mobile node SHOULD initiate a registration whenever it detects a
change in its network connectivity. See Section 2.4.2 for methods by
which mobile nodes MAY make such a determination. When it is away
from home, the mobile node's Registration Request allows its home
agent to create or modify a mobility binding for it. When it is at
home, the mobile node's (de)Registration Request allows its home
agent to delete any previous mobility binding(s) for it. A mobile
node operates without the support of mobility functions when it is at
home.
There are other conditions under which the mobile node SHOULD
(re)register with its foreign agent, such as when the mobile node
detects that the foreign agent has rebooted (as specified in Section
2.4.4) and when the current registration's Lifetime is near
expiration.
In the absence of link-layer indications of changes in point of
attachment, Agent Advertisements from new agents SHOULD NOT cause a
mobile node to attempt a new registration, if its current
registration has not expired and it is still also receiving Agent
Advertisements from the foreign agent with which it is currently
registered. In the absence of link-layer indications, a mobile node
MUST NOT attempt to register more often than once per second.
A mobile node MAY register with a different agent when transport-
layer protocols indicate excessive retransmissions. A mobile node
MUST NOT consider reception of an ICMP Redirect from a foreign agent
that is currently providing service to it as reason to register with
a new foreign agent. Within these constraints, the mobile node MAY
register again at any time.
Appendix D shows some examples of how the fields in registration
messages would be set up in some typical registration scenarios.
3.6.1. Sending Registration Requests The following sections specify details for the values the mobile node MUST supply in the fields of Registration Request messages. 3.6.1.1. IP Fields This section provides the specific rules by which mobile nodes pick values for the IP header fields of a Registration Request. IP Source Address: - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - In all other circumstances, the IP source address MUST be the mobile node's home address. IP Destination Address: - When the mobile node has discovered the agent with which it is registering, through some means (e.g., link-layer) that does not provide the IP address of the agent (the IP address of the agent is unknown to the mobile node), then the "All Mobility Agents" multicast address (224.0.0.11) MUST be used. In this case, the mobile node MUST use the agent's link-layer unicast address in order to deliver the datagram to the correct agent. - When registering with a foreign agent, the address of the agent as learned from the IP source address of the corresponding Agent Advertisement MUST be used. In addition, when transmitting this Registration Request message, the mobile node MUST use a link-layer destination address copied from the link-layer source address of the Agent Advertisement message in which it learned this foreign agent's IP address. - When the mobile node is registering directly with its home agent and knows the (unicast) IP address of its home agent, the destination address MUST be set to this address.
- If the mobile node is registering directly with its home
agent, but does not know the IP address of its home agent,
the mobile node may use dynamic home agent address resolution
to automatically determine the IP address of its home agent
(Section 3.6.1.2). In this case, the IP destination address is
set to the subnet-directed broadcast address of the mobile node's
home network. This address MUST NOT be used as the destination
IP address if the mobile node is registering via a foreign agent,
although it MAY be used as the Home Agent address in the body of
the Registration Request when registering via a foreign agent.
IP Time to Live:
- The IP TTL field MUST be set to 1 if the IP destination address
is set to the "All Mobility Agents" multicast address as
described above. Otherwise a suitable value should be chosen in
accordance with standard IP practice [19].
3.6.1.2. Registration Request Fields
This section provides specific rules by which mobile nodes pick
values for the fields within the fixed portion of a Registration
Request.
A mobile node MAY set the 'S' bit in order to request that the home
agent maintain prior mobility binding(s). Otherwise, the home agent
deletes any previous binding(s) and replaces them with the new
binding specified in the Registration Request. Multiple simultaneous
mobility bindings are likely to be useful when a mobile node using at
least one wireless network interface moves within wireless
transmission range of more than one foreign agent. IP explicitly
allows duplication of datagrams. When the home agent allows
simultaneous bindings, it will tunnel a separate copy of each
arriving datagram to each care-of address, and the mobile node will
receive multiple copies of datagrams destined to it.
The mobile node SHOULD set the 'D' bit if it is registering with a
co-located care-of address. Otherwise, the 'D' bit MUST NOT be set.
A mobile node MAY set the 'B' bit to request its home agent to
forward to it, a copy of broadcast datagrams received by its home
agent from the home network. The method used by the home agent to
forward broadcast datagrams depends on the type of care-of address
registered by the mobile node, as determined by the 'D' bit in the
mobile node's Registration Request:
- If the 'D' bit is set, then the mobile node has indicated that it
will decapsulate any datagrams tunneled to this care-of address
itself (the mobile node is using a co-located care-of address).
In this case, to forward such a received broadcast datagram to
the mobile node, the home agent MUST tunnel it to this care-of
address. The mobile node de-tunnels the received datagram in the
same way as any other datagram tunneled directly to it.
- If the 'D' bit is NOT set, then the mobile node has indicated
that it is using a foreign agent care-of address, and that the
foreign agent will thus decapsulate arriving datagrams before
forwarding them to the mobile node. In this case, to forward
such a received broadcast datagram to the mobile node, the home
agent MUST first encapsulate the broadcast datagram in a unicast
datagram addressed to the mobile node's home address, and then
MUST tunnel this resulting datagram to the mobile node's care-of
address.
When decapsulated by the foreign agent, the inner datagram will
thus be a unicast IP datagram addressed to the mobile node,
identifying to the foreign agent the intended destination of the
encapsulated broadcast datagram, and will be delivered to the
mobile node in the same way as any tunneled datagram arriving for
the mobile node. The foreign agent MUST NOT decapsulate the
encapsulated broadcast datagram and MUST NOT use a local network
broadcast to transmit it to the mobile node. The mobile node thus
MUST decapsulate the encapsulated broadcast datagram itself, and
thus MUST NOT set the 'B' bit in its Registration Request in this
case unless it is capable of decapsulating datagrams.
The mobile node MAY request alternative forms of encapsulation by
setting the 'M' bit and/or the 'G' bit, but only if the mobile node
is decapsulating its own datagrams (the mobile node is using a co-
located care-of address) or if its foreign agent has indicated
support for these forms of encapsulation by setting the corresponding
bits in the Mobility Agent Advertisement Extension of an Agent
Advertisement received by the mobile node. Otherwise, the mobile
node MUST NOT set these bits.
The Lifetime field is chosen as follows:
- If the mobile node is registering with a foreign agent, the
Lifetime SHOULD NOT exceed the value in the Registration Lifetime
field of the Agent Advertisement message received from the
foreign agent. When the method by which the care-of address is
learned does not include a Lifetime, the default ICMP Router
Advertisement Lifetime (1800 seconds) MAY be used.
- The mobile node MAY ask a home agent to delete a particular
mobility binding, by sending a Registration Request with the
care-of address for this binding, with the Lifetime field set to
zero (Section 3.8.2).
- Similarly, a Lifetime of zero is used when the mobile node
deregisters all care-of addresses, such as upon returning home.
The Home Agent field MUST be set to the address of the mobile node's
home agent, if the mobile node knows this address. Otherwise, the
mobile node MAY use dynamic home agent address resolution to learn
the address of its home agent. In this case, the mobile node MUST
set the Home Agent field to the subnet-directed broadcast address of
the mobile node's home network. Each home agent receiving such a
Registration Request with a broadcast destination address MUST reject
the mobile node's registration and SHOULD return a rejection
Registration Reply indicating its unicast IP address for use by the
mobile node in a future registration attempt.
The Care-of Address field MUST be set to the value of the particular
care-of address that the mobile node wishes to (de)register. In the
special case in which a mobile node wishes to deregister all care-of
addresses, it MUST set this field to its home address.
The mobile node chooses the Identification field in accordance with
the style of replay protection it uses with its home agent. This is
part of the mobility security association the mobile node shares with
its home agent. See Section 5.6 for the method by which the mobile
node computes the Identification field.
3.6.1.3. Extensions
This section describes the ordering of any mandatory and any optional
Extensions that a mobile node appends to a Registration Request.
This following ordering MUST be followed:
a) The IP header, followed by the UDP header, followed by the
fixed-length portion of the Registration Request, followed by
b) If present, any non-authentication Extensions expected to be
used by the home agent (which may or may not also be used by
the foreign agent), followed by
c) The Mobile-Home Authentication Extension, followed by
d) If present, any non-authentication Extensions used only by
the foreign agent, followed by
e) The Mobile-Foreign Authentication Extension, if present.
Note that items (a) and (c) MUST appear in every Registration Request
sent by the mobile node. Items (b), (d), and (e) are optional.
However, item (e) MUST be included when the mobile node and the
foreign agent share a mobility security association.
3.6.2. Receiving Registration Replies
Registration Replies will be received by the mobile node in response
to its Registration Requests. Registration Replies generally fall
into three categories:
- the registration was accepted,
- the registration was denied by the foreign agent, or
- the registration was denied by the home agent.
The remainder of this section describes the Registration Reply
handling by a mobile node in each of these three categories.
3.6.2.1. Validity Checks
Registration Replies with an invalid, non-zero UDP checksum MUST be
silently discarded.
In addition, the low-order 32 bits of the Identification field in the
Registration Reply MUST be compared to the low-order 32 bits of the
Identification field in the most recent Registration Request sent to
the replying agent. If they do not match, the Reply MUST be silently
discarded.
Also, the authentication in the Registration Reply MUST be checked.
That is, the mobile node MUST check for the presence of a valid
authentication Extension, acting in accordance with the Code field in
the Reply. The rules are as follows:
a) If the mobile node and the foreign agent share a
mobility security association, exactly one Mobile-Foreign
Authentication Extension MUST be present in the Registration
Reply, and the mobile node MUST check the Authenticator
value in the Extension. If no Mobile-Foreign Authentication
Extension is found, or if more than one Mobile-Foreign
Authentication Extension is found, or if the Authenticator is
invalid, the mobile node MUST silently discard the Reply and
SHOULD log the event as a security exception.
b) If the Code field indicates that service is denied by
the home agent, or if the Code field indicates that the
registration was accepted by the home agent, exactly one
Mobile-Home Authentication Extension MUST be present in
the Registration Reply, and the mobile node 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 mobile node MUST silently
discard the Reply and SHOULD log the event as a security
exception.
If the Code field indicates an authentication failure, either at the
foreign agent or the home agent, then it is quite possible that any
authenticators in the Registration Reply will also be in error. This
could happen, for example, if the shared secret between the mobile
node and home agent was erroneously configured. The mobile node
SHOULD log such errors as security exceptions.
3.6.2.2. Registration Request Accepted
If the Code field indicates that the request has been accepted, the
mobile node SHOULD configure its routing table appropriately for its
current point of attachment (Section 4.2.1).
If the mobile node is returning to its home network and that network
is one which implements ARP, the mobile node MUST follow the
procedures described in Section 4.6 with regard to ARP, proxy ARP,
and gratuitous ARP.
If the mobile node has registered on a foreign network, it SHOULD
re-register before the expiration of the Lifetime of its
registration. As described in Section 3.6, for each pending
Registration Request, the mobile node MUST maintain the remaining
lifetime of this pending registration, as well as the original
Lifetime from the Registration Request. When the mobile node
receives a valid Registration Reply, the mobile node MUST decrease
its view of the remaining lifetime of the registration by the amount
by which the home agent decreased the originally requested Lifetime.
This procedure is equivalent to the mobile node starting a timer for
the granted Lifetime at the time it sent the Registration Request,
even though the granted Lifetime is not known to the mobile node
until the Registration Reply is received. Since the Registration
Request is certainly sent before the home agent begins timing the
registration Lifetime (also based on the granted Lifetime), this
procedure ensures that the mobile node will re-register before the
home agent expires and deletes the registration, in spite of possibly
non-negligible transmission delays for the original Registration
Request and Reply that started the timing of the Lifetime at the mobile node and its home agent. 3.6.2.3. Registration Request Denied If the Code field indicates that service is being denied, the mobile node SHOULD log the error. In certain cases the mobile node may be able to "repair" the error. These include: Code 69: (Denied by foreign agent, Lifetime too long) In this case, the Lifetime field in the Registration Reply will contain the maximum Lifetime value which that foreign agent is willing to accept in any Registration Request. The mobile node MAY attempt to register with this same agent, using a Lifetime in the Registration Request that MUST be less than or equal to the value specified in the Reply. Code 133: (Denied by home agent, Identification mismatch) In this case, the Identification field in the Registration Reply will contain a value that allows the mobile node to synchronize with the home agent, based upon the style of replay protection in effect (Section 5.6). The mobile node MUST adjust the parameters it uses to compute the Identification field based upon the information in the Registration Reply, before issuing any future Registration Requests. Code 136: (Denied by home agent, Unknown home agent address) This code is returned by a home agent when the mobile node is performing dynamic home agent address resolution as described in Sections 3.6.1.1 and 3.6.1.2. In this case, the Home Agent field within the Reply will contain the unicast IP address of the home agent returning the Reply. The mobile node MAY then attempt to register with this home agent in future Registration Requests. In addition, the mobile node SHOULD adjust the parameters it uses to compute the Identification field based upon the corresponding field in the Registration Reply, before issuing any future Registration Requests. 3.6.3. Registration Retransmission When no Registration Reply has been received within a reasonable time, another Registration Request MAY be transmitted. When timestamps are used, a new registration Identification is chosen for each retransmission; thus it counts as a new registration. When nonces are used, the unanswered Request is retransmitted unchanged;
thus the retransmission does not count as a new registration (Section 5.6). In this way a retransmission will not require the home agent to resynchronize with the mobile node by issuing another nonce in the case in which the original Registration Request (rather than its Registration Reply) was lost by the network. The maximum time until a new Registration Request is sent SHOULD be no greater than the requested Lifetime of the Registration Request. The minimum value SHOULD be large enough to account for the size of the messages, twice the round trip time for transmission to the home agent, and at least an additional 100 milliseconds to allow for processing the messages before responding. The round trip time for transmission to the home agent will be at least as large as the time required to transmit the messages at the link speed of the mobile node's current point of attachment. Some circuits add another 200 milliseconds of satellite delay in the total round trip time to the home agent. The minimum time between Registration Requests MUST NOT be less than 1 second. Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that is less than the maximum as specified above. 3.7. Foreign Agent Considerations The foreign agent plays a mostly passive role in Mobile IP registration. It relays Registration Requests between mobile nodes and home agents, and, when it provides the care-of address, decapsulates datagrams for delivery to the mobile node. It SHOULD also send periodic Agent Advertisement messages to advertise its presence as described in Section 2.3, if not detectable by link-layer means. A foreign agent MUST NOT transmit a Registration Request except when relaying a Registration Request received from a mobile node, to the mobile node's home agent. A foreign agent MUST NOT transmit a Registration Reply except when relaying a Registration Reply received from a mobile node's home agent, or when replying to a Registration Request received from a mobile node in the case in which the foreign agent is denying service to the mobile node. In particular, a foreign agent MUST NOT generate a Registration Request or Reply because a mobile node's registration Lifetime has expired. A foreign agent also MUST NOT originate a Registration Request message that asks for deregistration of a mobile node; however, it MUST relay valid (de)Registration Requests originated by a mobile node.
3.7.1. Configuration and Registration Tables Each foreign agent MUST be configured with a care-of address. In addition, for each pending or current registration, the foreign agent MUST maintain a visitor list entry containing the following information obtained from the mobile node's Registration Request: - the link-layer source address of the mobile node - the IP Source Address (the mobile node's Home Address) - the IP Destination Address (as specified in 3.6.2.3) - the UDP Source Port - the Home Agent address - the Identification field - the requested registration Lifetime, and - the remaining Lifetime of the pending or current registration. As with any node on the Internet, a foreign agent MAY also share mobility security associations with any other nodes. When relaying a Registration Request from a mobile node to its home agent, if the foreign agent shares a mobility security association with the home agent, it MUST add a Foreign-Home Authentication Extension to the Request and MUST check the required Foreign-Home Authentication Extension in the Registration Reply from the home agent (Sections 3.3 and 3.4). Similarly, when receiving a Registration Request from a mobile node, if the foreign agent shares a mobility security association with the mobile node, it MUST check the required Mobile- Foreign Authentication Extension in the Request and MUST add a Mobile-Foreign Authentication Extension to the Registration Reply to the mobile node. 3.7.2. Receiving Registration Requests If the foreign agent accepts a Registration Request from a mobile node, it then MUST relay the Request to the indicated home agent. Otherwise, if the foreign agent denies the Request, it MUST send a Registration Reply to the mobile node with an appropriate denial Code, except in cases where the foreign agent would be required to send out more than one such denial per second to the same mobile node. The following sections describe this behavior in more detail. If a foreign agent receives a Registration Request from a mobile node in its visitor list, the existing visitor list entry for the mobile node SHOULD NOT be deleted or modified until the foreign agent receives a valid Registration Reply from the home agent with a Code indicating success. The foreign agent MUST record the new pending
Request separately from the existing visitor list entry for the mobile node. If the Registration Request requests deregistration, the existing visitor list entry for the mobile node SHOULD NOT be deleted until the foreign agent has received a successful Registration Reply. If the Registration Reply indicates that the Request (for registration or deregistration) was denied by the home agent, the existing visitor list entry for the mobile node MUST NOT be modified as a result of receiving the Registration Reply. 3.7.2.1. Validity Checks Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded. Also, the authentication in the Registration Request MUST be checked. If the foreign agent and the mobile node share a mobility security association, exactly one Mobile-Foreign Authentication Extension MUST be present in the Registration Request, and the foreign agent MUST check the Authenticator value in the Extension. If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST silently discard the Request and SHOULD log the event as a security exception. The foreign agent also SHOULD send a Registration Reply to the mobile node with Code 67. 3.7.2.2. Forwarding a Valid Request to the Home Agent If the foreign agent accepts the mobile node's Registration Request, it MUST relay the Request to the mobile node's home agent as specified in the Home Agent field of the Registration Request. The foreign agent MUST NOT modify any of the fields beginning with the fixed portion of the Registration Request up through and including the Mobile-Home Authentication Extension. Otherwise, an authentication failure is very likely to occur at the home agent. In addition, the foreign agent proceeds as follows: - It MUST process and remove any Extensions following the Mobile-Home Authentication Extension, - It MAY append any of its own non-authentication Extensions of relevance to the home agent, if applicable, and - It MUST append the Foreign-Home Authentication Extension, if the foreign agent shares a mobility security association with the home agent.
Specific fields within the IP header and the UDP header of the
relayed Registration Request MUST be set as follows:
IP Source Address
The foreign agent's address on the interface from which
the message will be sent.
IP Destination Address
Copied from the Home Agent field within the Registration
Request.
UDP Source Port
<variable>
UDP Destination Port
434
After forwarding a valid Registration Request to the home agent, the
foreign agent MUST begin timing the remaining lifetime of the pending
registration based on the Lifetime in the Registration Request. If
this lifetime expires before receiving a valid Registration Reply,
the foreign agent MUST delete its visitor list entry for this pending
registration.
3.7.2.3. Denying Invalid Requests
If the foreign agent denies the mobile node's Registration Request
for any reason, it SHOULD send the mobile node a Registration Reply
with a suitable denial Code. In such a case, the Home Address, Home
Agent, and Identification fields within the Registration Reply are
copied from the corresponding fields of the Registration Request.
If the Reserved field is nonzero, the foreign agent MUST deny the
Request and SHOULD return a Registration Reply with status code 70 to
the mobile node. If the Request is being denied because the
requested Lifetime is too long, the foreign agent sets the Lifetime
in the Reply to the maximum Lifetime value it is willing to accept in
any Registration Request, and sets the Code field to 69. Otherwise,
the Lifetime SHOULD be copied from the Lifetime field in the Request.
Specific fields within the IP header and the UDP header of the
Registration Reply MUST be set as follows:
IP Source Address
Copied from the IP Destination Address of Registration
Request, unless the "All Agents Multicast" address was
used. In this case, the foreign agent's address (on the
interface from which the message will be sent) MUST be
used.
IP Destination Address
Copied from the IP Source Address of the Registration
Request.
UDP Source Port
434
UDP Destination Port
Copied from the UDP Source Port of the Registration
Request.
3.7.3. Receiving Registration Replies
The foreign agent updates its visitor list when it receives a valid
Registration Reply from a home agent. It then relays the
Registration Reply to the mobile node. The following sections
describe this behavior in more detail.
If upon relaying a Registration Request to a home agent, the foreign
agent receives an ICMP error message instead of a Registration Reply,
then the foreign agent SHOULD send to the mobile node a Registration
Reply with an appropriate "Home Agent Unreachable" failure Code
(within the range 80-95, inclusive). See Section 3.7.2.3 for details
on building the Registration Reply.
3.7.3.1. Validity Checks
Registration Replies with an invalid, non-zero UDP checksum MUST be
silently discarded.
When a foreign agent receives a Registration Reply message, it MUST
search its visitor list for a pending Registration Request with the
same mobile node home address as indicated in the Reply. If no
pending Request is found, the foreign agent MUST silently discard the
Reply. The foreign agent MUST also silently discard the Reply if the
low-order 32 bits of the Identification field in the Reply do not
match those in the Request.
Also, the authentication in the Registration Reply MUST be checked.
If the foreign agent and the home agent share a mobility security
association, exactly one Foreign-Home Authentication Extension MUST
be present in the Registration Reply, and the foreign 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 foreign agent MUST silently discard the Reply and SHOULD
log the event as a security exception. The foreign agent also MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 68. 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.
(page 55 continued on part 3)
