Mobile IP Working Group Eva Gustafsson
INTERNET DRAFT Ericsson
22 November 2003 Annika Jonsson
Ericsson
Charles E. Perkins
Nokia Research Center
Mobile IPv4 Regional Registration
draft-ietf-mobileip-reg-tunnel-08.txt
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Using Mobile IP, a mobile node registers with its home agent each
time it changes care-of address. If the distance between the
visited network and the home network of the mobile node is large, the
signaling delay for these registrations may be long. This document
describes a new kind of `regional' registrations, i.e. registrations
local to the visited domain. The regional signaling is performed via
a new network entity called a Gateway Foreign Agent and introduces
a layer of hierarchy in the visited domain. Regional registrations
reduce the number of signaling messages to the home network, and
reduce the signaling delay when a mobile node moves from one foreign
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page i]
Internet Draft Regional Registration 22 November 2003
agent to another within the same visited domain. This document is an
optional extension to the Mobile IPv4 protocol.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page ii]
Internet Draft Regional Registration 22 November 2003
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 3
3. Description of the Protocol 4
3.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
3.3. Advertising Foreign Agent and GFA . . . . . . . . . . . . 7
3.4. Backwards compatibility with RFC3344 . . . . . . . . . . 8
4. Home Registration 8
4.1. Mobile Node Considerations . . . . . . . . . . . . . . . 8
4.2. Foreign Agent Considerations . . . . . . . . . . . . . . 10
4.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 10
4.4. Home Agent Considerations . . . . . . . . . . . . . . . . 12
5. Regional Registration 13
5.1. Mobile Node Considerations . . . . . . . . . . . . . . . 14
5.2. Foreign Agent Considerations . . . . . . . . . . . . . . 15
5.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 15
6. Generalized NAI Extension 15
7. Router Discovery Extensions 17
7.1. Regional Registration Flag . . . . . . . . . . . . . . . 17
7.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 17
8. Regional Extensions to Mobile IPv4 Registration Messages 18
8.1. GFA IP Address Extension . . . . . . . . . . . . . . . . 18
8.2. Hierarchical Foreign Agent Extension . . . . . . . . . . 19
8.3. Replay Protection Style . . . . . . . . . . . . . . . . . 19
8.4. New Code Values for Registration Reply . . . . . . . . . 21
9. Regional Registration Message Formats 22
9.1. Regional Registration Request . . . . . . . . . . . . . . 22
9.2. Regional Registration Reply . . . . . . . . . . . . . . . 24
9.3. New Regional Registration Reply Code Values . . . . . . . 24
10. Authentication Extensions 25
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page iii]
Internet Draft Regional Registration 22 November 2003
11. IANA considerations 26
12. Security Considerations 26
13. Acknowledgements 27
A. Changes from Previous Versions 29
A.1. Updates from version 06 . . . . . . . . . . . . . . . . . 29
A.2. Updates from version 05 . . . . . . . . . . . . . . . . . 30
A.3. List of updates made for previous revisions . . . . . . . 30
A.4. Updates from version 02 . . . . . . . . . . . . . . . . . 31
B. Hierarchical Foreign Agents 32
B.1. Registration with Home Agent . . . . . . . . . . . . . . 32
B.2. Handling Binding Updates . . . . . . . . . . . . . . . . 35
B.3. Regional Registration . . . . . . . . . . . . . . . . . . 36
B.4. Regional Registrations and Smooth Handover . . . . . . . 38
B.5. Co-located care of address . . . . . . . . . . . . . . . 38
B.6. Data Traffic . . . . . . . . . . . . . . . . . . . . . . 38
B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 39
C. Authentication, Authorization and Accounting AAA Interactions 39
D. Anchoring at a GFA/RFA/FA 40
Addresses 41
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 1]
Internet Draft Regional Registration 22 November 2003
1. Introduction
This document is an optional extension to the Mobile IPv4 protocol,
and proposes a means for mobile nodes to register locally within a
visited domain. By registering locally, the number of signaling
messages to the home network are kept to a minimum, and the signaling
delay is reduced.
In Mobile IP, as specified in RFC 3344 [9], a mobile node registers
with its home agent each time it changes care-of address. If the
distance between the visited network and the home network of the
mobile node is large, the signaling delay for these registrations
may be long. We propose a solution for performing registrations
locally in the visited domain: regional registrations. The
regional registration design introduces new Mobile IPv4 messages
- Regional Registrations, new Mobile IPv4 extensions to convey
information between the mobile node, foreign agent and home agent,
and a new network entity: the Gateway Foreign Agent (GFA). Regional
registrations reduce the number of signaling messages to the home
network, and reduce the signaling delay when a mobile node moves from
one foreign agent to another within the same visited domain. This
will both decrease the load on the home network, and speed up the
process of handover within the visited domain.
When a mobile node first arrives at a visited domain, it performs a
_home_registration -- that is, a registration with its home agent.
At this registration, we assume that the home network generates
a registration key (e.g. using [11]) for the mobile node. This
registration key is distributed to the mobile node and to the visited
domain, and can be used for authentication of regional registrations.
During a home registration, the home agent registers the care-of
address of the mobile node. When the visited domain supports
regional tunnel management, the care-of address that is registered
at the home agent is the publicly routable address of a Gateway
Foreign Agent (GFA). This care-of address will not change when the
mobile node changes foreign agent under the same GFA. When changing
GFA, a mobile node MUST perform a home registration; when changing
foreign agent under the same GFA, the mobile node MAY instead perform
a regional registration within the visited domain. The proposed
regional registration protocol supports one level of foreign agent
hierarchy beneath the GFA, but the protocol may be utilized to
support several levels of hierarchy, as discussed in Appendix B.
Foreign agents that support regional registrations are also required
to support registrations according to Mobile IPv4 [9]. If there is
a foreign agent address announced in the Agent Advertisement, the
mobile node may register that foreign agent care-of address with its
home agent [9]. Similarly, if the mobile node chooses not to employ
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 2]
Internet Draft Regional Registration 22 November 2003
regional registrations, it may register a co-located care-of address
directly with its home agent, according to [9].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
This document uses the following terms:
Critical type
A type value for an extension in the range 0-127, which
indicates that the extension MUST either be known to the
recipient, or that the message containing the extension
MUST be rejected. In other words, an extension with a
critical type value is non-skippable.
Domain A collection of networks sharing a common network
administration.
Foreign Agent (FA)
As defined in [9].
Gateway Foreign Agent (GFA)
A Foreign Agent which has a publicly routable IP address.
A GFA may, for instance, be placed in or near a firewall.
Home Agent (HA)
As defined in [9].
Home domain
The domain where the home network and home agent are
located.
Home network
As defined in [9].
Home Registration
A registration, processed by the home agent and the GFA,
using the specification in [9] possibly with additional
extensions defined in this document.
Local Care-of Address
A Care-of Address which is either assigned to a mobile
node, or to a foreign agent offering local connectivity
to a mobile node. A registration message from the mobile
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 3]
Internet Draft Regional Registration 22 November 2003
node is subsequently sent to a GFA (or another RFA, see
Appendix B) via the local care-of address.
Mobile Node (MN)
As defined in [9].
Mobility Agent (MA)
As defined in [9].
Network Access Identifier(NAI)
Some features of this protocol specification rely on use
of the Network Access Identifier (NAI) [3].
Regional Foreign Agent (RFA)
A Foreign Agent which may be the target of a request for
regional registration.
Regional Registration
A mobile node performs registration locally at the
visited domain, by sending a Regional Registration
Request to a GFA, and receiving a Regional Registration
Reply in return.
Registration Key
A key used by mobile nodes and mobility agents to secure
certain signals and control messages specified by Mobile
IP.
Visited domain
The domain where the visited network, the current foreign
agent and the GFA are located.
Visited network
As defined in [9].
3. Description of the Protocol
This section provides an overview of the regional registration
protocol.
3.1. General Assumptions
Our general model of operation is illustrated in figure 1, showing a
visited domain with foreign agent and GFA, and a home network with a
home agent.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 4]
Internet Draft Regional Registration 22 November 2003
+---------------------------+ +----------------+
| Visited Domain | | Home |
| | +---------+ | Network |
| | | | | |
| +------+ +-------+ | | Public | | +------+ |
| | FA |------| GFA |-------------------------| HA | |
| +--+---+ +-------+ | | Network | | +------+ |
| | | | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+
Figure 1: Visited domain with a GFA, and a home network with HA.
For mobile nodes that cannot process a NAI, or with mobility agents
that are not configured to advertise their NAI, regional registration
is still useful, but the lack of certain features may result in less
than optimal results.
3.1.1. Visited Domain
We assume two hierarchy levels of foreign agents in the visited
domain. At the top level of the hierarchy, there is at least one
GFA, which is a foreign agent with additional features. A GFA
must have a publicly routable address. Beneath a GFA, there are
one or more regional foreign agents (RFAs). We assume that there
exist established security associations between a GFA and the
RFAs beneath it. Multiple hierarchy levels of foreign agents are
discussed in Appendix B. When designing a domain supporting regional
registrations, the RFAs and GFA must be compatible. That is, they
should support the same encapsulation types, compression mechanisms
etc.
When a mobile node changes care-of address under the same GFA, it MAY
perform a regional registration. If the mobile node changes GFA,
within a visited domain or between visited domains, it MUST perform a
home registration.
3.1.2. Authentication
With the regional registration protocol, a GFA address is registered
at the home agent as the care-of address of the mobile node. If a
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 5]
Internet Draft Regional Registration 22 November 2003
Mobile-Foreign Authentication extension is present in a Registration
Request message directed to the home agent, the GFA will perform
the authentication. Similarly, if a Foreign-Home Authentication
extension is present in a Registration Request message, the
authentication is performed between the GFA and the home agent.
Regional Registration messages also have to be protected with
authentication extensions in the same way as registrations with the
home agent. This means that the mobile node and the GFA MUST have
received the keys needed to construct the authentication extensions
before any Regional Registration is performed. When the regional
registration protocol is employed, the GFA is the agent within
the visited domain which receives the registration keys. This is
because the GFA address is the registered care-of address of the
mobile node at its home network. The distributed registration
keys are subsequently used to enable proper authentication for
regional registrations (see sections 9.1 and 9.2). How the keys
are distributed is outside the scope of this draft. One example is
that the keys are distributed as part of the registration at the
home network, for example according to [4, 11]. Another example is
pre-configured keys.
3.2. Protocol Overview
When a mobile node first arrives at a visited domain, it performs a
registration with its home network. At this registration, the home
agent registers the care-of address of the mobile node. In case the
visited domain supports regional registrations, the care-of address
that is registered at the home agent is the address of a GFA. The GFA
keeps a visitor list of all the mobile nodes currently registered
with it.
Since the care-of address registered at the home agent is the GFA
address, it will not change when the mobile node changes foreign
agent under the same GFA. Thus, the home agent does not need to be
informed of any further mobile node movements within the visited
domain.
Figure 2 illustrates the signaling message flow for registration
with the home network. After the registration at the home agent,
the home agent records the GFA address as the care-of address of the
mobile node. If the GFA address was dynamically assigned to the
mobile node, the Registration Reply has an extension indicating the
IP address of the GFA to the mobile node.
Figure 3 illustrates the signaling message flow for regional
registration. Even though the mobile node's local care-of address
changes, the home agent continues to record the GFA address as the
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 6]
Internet Draft Regional Registration 22 November 2003
MN FA1 GFA HA
| | | |
| Registration Request | | |
|---------------------->| Reg. Request w/ext. | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply |
| | Reg. Reply w/ext. |<---------------|
| Registration Reply |<----------------------| |
|<----------------------| | |
| | | |
Figure 2: Registration at the GFA and the home agent.
MN FA2 GFA HA
| | | |
| Regional Reg. Req. | | |
|---------------------->| Regional Reg. Req. w/ext. | |
| |----------------------------->| |
| | Regional Reg. Reply w/ext. | |
| Regional Reg. Reply |<-----------------------------| |
|<----------------------| | |
| | | |
Figure 3: Regional registration at the GFA.
care-of address of the mobile node. We introduce two new message
types for regional registrations: Regional Registration Request and
Regional Registration Reply.
3.3. Advertising Foreign Agent and GFA
A foreign agent typically announces its presence via an Agent
Advertisement message [9]. If the domain to which a foreign agent
belongs supports regional registrations, the following changes are
applied to the Agent Advertisement message.
The `I' flag (see Section 7) MUST be set to indicate that the domain
supports regional tunnel management. If the `I' flag is set, there
MUST be at least one care-of address in the Agent Advertisement
message, but that address MAY be set to the ``all ones'' address. If
the `I' flag is set, and there is only one care-of address (which is
not all ones), it is the address of the FA. If the `I' flag is set,
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 7]
Internet Draft Regional Registration 22 November 2003
and there are multiple care-of addresses, the first care-of address
is the local FA, and the last care-of address is the GFA. The FA-NAI
(see section 7.2) SHOULD also be present to enable the mobile node
to decide whether or not it is in its home domain. The decision is
based on whether the realm part of the advertised FA-NAI matches the
mobile node's realm.
3.4. Backwards compatibility with RFC3344
A domain that supports Regional Registrations SHOULD also be
backwards compatible. If the Foreign Agent does not advertise an
``all ones'' care-of address, it MUST support registrations according
to Mobile IPv4 as defined in RFC3344 [9]. This allows mobile nodes
that doesn't support Regional Registrations to register via this
Foreign Agent using standard Mobile IPv4. If the Foreign agent
advertises both its own care-of address and a GFA care-of address,
a mobile node that supports Regional Registrations but has a Home
Agent that doesn't, will still be able to make use of Regional
Registrations through that GFA care-of address. A Foreign Agent that
advertises an ``all ones'' care-of address will not be backwards
compatible with RFC3344. In that case, and in other cases when the
mobile node requests that a GFA address is dynamically assigned to
it by setting the care-of address in a Registration Request to zero,
the mobile node and its Home Agent MUST support the GFA IP address
extension.
4. Home Registration
This section gives a detailed description of home registration,
i.e., registration with the home agent (on the home network). Home
registration is performed when a mobile node first arrives at a
visited domain, when it requests a new home agent, or when it changes
GFA. Home registration is also performed to renew bindings which
would otherwise expire.
4.1. Mobile Node Considerations
Upon receipt of an Agent Advertisement message with the `I' flag set
and a FA-NAI extension, the mobile node compares the domain part
of the foreign agent NAI with the domain part of its own NAI, to
determine whether it is in its home domain or in a visited domain.
If the NAIs do not match, the mobile node MUST assume it is in a
foreign domain. Otherwise, if the mobile node determines that it is
in its home domain, it acts as defined in [9].
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 8]
Internet Draft Regional Registration 22 November 2003
If the mobile node determines that it is in a visited domain, it
SHOULD either use the advertised GFA address in the care-of address
field in the Registration Request message, or set this field to
zero to request to be assigned a GFA. If the mobile node sets the
care-of address to zero, the mobile node and its home agent MUST
support the GFA IP address extension (see section 8.1). In that
case, the mobile node MUST check to make sure that it receives a GFA
IP address extension in the Registration Reply. If the Foreign Agent
only advertises an ``all ones'' care-of address, it only supports
dynamically assigned GFA care-of address, and the mobile node MUST
set the care-of address in the Registration Request to zero.
A mobile node with a co-located care-of address might also want
to use Regional Registrations. It then finds out the address of
a GFA, either from Agent Advertisements sent by a Foreign Agent,
or by some means not described in this draft. The mobile node MAY
then generate a Registration Request message, with the GFA address
in the care-of address field, and send it directly to the GFA (not
via a foreign agent). In this case, the mobile node MUST add a
Hierarchical Foreign Agent extension 8.2, including its co-located
care-of address, to the Registration Request before sending it.
The Hierarchical Foreign Agent extension MUST be protected by an
authentication extension. If the mobile node has established a
mobility security association with the GFA, the Hierarchical Foreign
Agent extension SHOULD be placed after the MN-HA authentication
extension and before the MN-FA authentication extension. Otherwise
the Hierarchical Foreign Agent extension MUST be placed before the
MN-HA authentication extension.
If the mobile node receives an Agent Advertisement with the `R' bit
set it, even if it has a co-located care-of address, still formulates
the same Registration Request message with extensions, but it sends
the message to the advertising foreign agent instead of to the GFA.
If the home registration is about to expire, the mobile node performs
a new home registration using the same GFA care-of address to refresh
the binding [9]. If the mobile node has just moved to a new Foreign
Agent and not yet sent a Regional Registration Request when the home
registration is due to expire, the mobile node sends only a home
Registration Request, as this will update both the GFA and the HA.
This Registration Request MUST be constructed as if it was the first
registration in this domain. For example, if the new Foreign Agent
only advertises an `all ones' care-of address, the mobile node MUST
set the care-of address in the Registration Request to zero, to avoid
problems if this new Foregin Agent doesn't support the same GFA as
the mobile node had before.
If the Registration Replay includes a Replay Protection Style
extension, the value in the Initial Identification field is the value
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 9]
Internet Draft Regional Registration 22 November 2003
to be used for replay protection in the next Regional Registration
Request (see section 5.1).
4.2. Foreign Agent Considerations
When the foreign agent receives a Registration Request message
from a mobile node, it extracts the care-of address field in the
Registration Request message, to find the GFA to which the message
shall be relayed. All Foreign Agents that advertise the `I' flag
MUST also be able to handle Registration Requests with a zero care-of
address. If the care-of address field is set to zero, the foreign
agent assigns a GFA to the mobile node. A Foreign Agent can either
have a default GFA that it assigns to all mobile nodes or it can
assign a GFA by some means not described in this specification.
If the Foreign Agent receives a Registration request where the
care-of address is set to ``all ones''(which could happen if a mobile
node that doesn't support Regional Registrations copied an ``all
ones'' care-of address from an Agent Advertisement), it must reply
with the Code field set to ``poorly formed Request'' [9].
If the Registration Request has the `T' bit set, the mobile node is
requesting Reverse Tunneling [8]. In this case, the foreign agent
has to tunnel packets from the mobile node to the GFA for further
handling.
If the care-of address in the Registration Request is the address of
the foreign agent, the foreign agent relays the message directly to
the home agent, as described in [9]. For each pending or current
home registration, the foreign agent maintains a visitor list entry
as described in [9]. If reverse tunneling is being used, the visitor
list MUST, in addition to the fields required in [9], contain the
address of the GFA.
Otherwise, if the care-of address in the Registration Request
is the address of a GFA (or zero), the foreign agent adds a
Hierarchical Foreign Agent extension, including its own address,
to the Registration Request message, and relays it to the GFA. The
Hierarchical Foreign Agent extension MUST be appended at the end
of all previous extensions that were included in the Registration
Request message when the foreign agent received it, and it SHOULD be
protected by an FA-FA Authentication extension (see section 10).
4.3. GFA Considerations
For each pending or current home registration, the GFA maintains a
visitor list entry as described in [9]. This visitor list entry is
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 10]
Internet Draft Regional Registration 22 November 2003
also updated for the regional registrations performed by the mobile
node. In addition to the fields required in [9], the list entry MUST
contain:
- the current care-of address of the mobile node (i.e., the foreign
agent or co-located address) in the Hierarchical Foreign Agent
extension
- the remaining Lifetime of the regional registration
- the style of replay protection in use for the regional
registration
- the Identification value for the regional registration.
The default replay protection style for Regional Registrations is
timestamp-based replay protection, as defined in Mobile IPv4 [9].
If the timestamp sent by the mobile node in the Registration
Request is not close enough to the GFA's time of day clock, the GFA
adds a Replay Protection Style extension (see section 8.3) to the
Registration Reply, with the GFAs time of day in the Identification
field to synchronize the mobile node with the GFA for the Regional
Registrations. If nonce based reply protection is used, the GFA adds
a Replay Protection Style extension to the Registration Reply, where
the high-order 32 bits in the Identification fields is the nonce
that should be used by the mobile node in the following Regional
Registration.
If the Registration Request message contains a Replay Protection
extension (see section 8.3) requesting a style of replay protection
not supported by the GFA, the GFA MUST reject the Registration
Request and send a Registration Reply with the value in the Code
field set to REPLAY_PROT_UNAVAIL (see section 8.4).
If the care-of address field of the Registration Request is set
to zero, the GFA assigns a GFA care-of address for this Mobile
Node, and adds a GFA IP Address extension with this address of
to the Registration Request message. The GFA MUST NOT insert
the GFA address directly in the care-of address field in the
Registration Request message, since that would cause the Mobile-Home
authentication to fail.
The GFA IP Address extension has to be protected so that it can't
be changed by a malicious node when the Registration Request is
forwarded to the HA. If the HA and the GFA have a mobility security
association, the GFA IP Address extension MUST be protected by the
HA-FA authentication extension. Otherwise the Registration Request
MUST be sent to the HA in a secure way, for example via a secure AAA
protocol (see e.g. [4, 11]).
If the Hierarchical Foreign Agent extension comes after the
MN-FA authentication extension, the GFA MUST remove it from the
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 11]
Internet Draft Regional Registration 22 November 2003
Registration Request message. The GFA then sends the request to the
home agent. Upon receipt of the Registration Reply message, the GFA
consults its pending registration record to find the care-of address
within its domain that is currently used by the mobile node, and
sends the Registration Reply to that care-of address.
If the Replay extension (see section 8.3) is present in a home
registration, and follows the MN-HA authentication extension, the GFA
SHOULD remove the Replay extension after performing any necessary
processing, before sending the home registration to the home agent.
If the GFA receives a Registration Request from a mobile node that it
already has a mobility binding for, this is an update of a binding
that is about to expire. If the address in the Hierarchical Foreign
Agent extension is the same as the current care-of address in the
visitor list for the mobile node, the entries in the visitor list
concerning regional registrations are not changed, except to update
the lifetime. If the address in the Hierarchical Foreign Agent
extension is a new address, the values for the regional registration
are updated.
If the Registration request has the 'T' bit set, the GFA has to
decapsulate the packets from the foreign agent and re-encapsulate
them for further delivery back to the home agent. These actions are
required because the home agent has to receive such packets from the
expected care-of address (i.e., that of the GFA) instead of the local
care-of address (that of the FA).
4.4. Home Agent Considerations
A Registration Request that does not contain a GFA IP Address
extension is processed by the home agent as described in [9]. If
the home agent receives a Registration Request with this extension,
and the home agent does not support the extension, the home
agent must return a Registration Reply with the Code value set to
ZERO_COA_NOT_SUPP 8.4 . If a home agent receives a Registration
Request message with the care-of address set to zero, and a GFA
IP Address extension, it MUST register the IP address of the GFA
as the care-of address of the mobile node in its mobility binding
list. If the Registration Request is accepted, the home agent MUST
include the GFA IP Address extension in the Registration Reply,
before the Mobile-Home Authentication extension. If a home agent
receives a Registration Request message with the care-of address set
to zero, but no GFA IP Address extension, it MUST deny the request
by sending a Registration Reply message with the Code field set to
ZERO_CAREOF_ADDRESS (see section 8.4). Otherwise, the home agent
then generates a Registration Reply message, including the GFA IP
Address extension, and sends it back to the GFA.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 12]
Internet Draft Regional Registration 22 November 2003
5. Regional Registration
This section describes in detail regional registration. Once the
home agent has registered the GFA address as the care-of address of
the mobile node, the mobile node may perform regional registrations.
When performing regional registrations, the mobile node may either
register a foreign agent care-of address or a co-located address with
the GFA (or, another RFA -- see Appendix B). In the following, we
assume that a home registration has already occurred, as described in
section 4, and that the GFA has a mobility security association with
the mobile node.
Suppose the mobile node moves from one foreign agent to another
foreign agent within the same visited domain. It will then receive
an Agent Advertisement from the new foreign agent. Suppose further
that the Agent Advertisement indicates that the visited domain
supports regional registrations, and that either the advertised GFA
address is the same as the one the mobile node has registered as its
care-of address during its last home registration, or the realm part
of the newly advertised FA-NAI matches the FA-NAI advertised by the
mobile node's previous foreign agent. Then, the mobile node can
perform a regional registration with this foreign agent and GFA. The
mobile node issues a Regional Registration Request message to the GFA
via the new foreign agent. The request is authenticated using the
registration key that was distributed to the GFA and to the mobile
node from the home network and the message is authenticated by the
MN-GFA Authentication Extension. The care-of address should be set
to the address of the local foreign agent, or else zero if the local
foreign agent is not advertising its own care-of address.
If the Regional Registration Request does not contain its care-of
address, the foreign agent adds a Hierarchical Foreign Agent
extension to the message and relays it to the GFA. Based on the
information in the Hierarchical Foreign Agent extension, the GFA
updates the mobile node's current point of attachment in its visitor
list. The GFA then issues a Regional Registration Reply to the
mobile node via the foreign agent.
If the advertised GFA is not the same as the one the mobile node has
registered as its care-of address, and if the mobile node is still
within the same domain as it was when it registered that care-of
address, the mobile node MAY try to perform a regional registration
with its registered GFA. If the foreign agent cannot support
regional registration to a GFA, other than advertised, the foreign
agent denies the regional registration with code UNKNOWN_GFA (see
section 9.3). In this case the MN has to do a new home registration
via the new GFA.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 13]
Internet Draft Regional Registration 22 November 2003
It is essential for the mobile node to distinguish regional
registrations from home registrations, since in the former case the
nonces are not synchronized with its home agent. Furthermore, a
home registration MUST be directed to the home network before the
lifetime of the GFA's regional care-of address expires. Since the
mobile node can use a zero Care-of Address either to request a GFA
(in a home registration) or to signify the use of an unspecified
(perhaps privately addressed) RFA (in a regional registration),
it is necessary to distinguish regional registrations from home
registration. Thus, we introduce new message types for the Regional
Registration messages.
5.1. Mobile Node Considerations
For each pending or current home registration, the mobile node
maintains the information described in [9]. The information is also
updated for the regional registrations performed by the mobile node.
In addition to the information described in [9], the mobile node MUST
maintain the following information, if present:
- the GFA address
- the style of replay protection in use for the regional
registration
- the Identification value for the regional registration.
The replay protection for registrations and regional registrations
is performed as described in [9]. Since the mobile node performs
regional registrations at the GFA in parallel with registrations at
its home network, the mobile node MUST be able to keep one replay
protection mechanism and sequence for the GFA, and a separate
mechanism and sequence for the home agent.
For regional registrations, replay protection may also be provided at
the foreign agent by the challenge-response mechanism, as described
in [5]. In this case, the mobile node inserts the 64 bit response
value (timestamp or nonce, according to Mobile IPv4 [9]) in the
Identification field in the Regional Registration Request. Thus,
the GFA SHOULD expect such an Identification field. When a mobile
node, which has already registered a GFA care-of address with its
home agent, changes foreign agent within the same domain and receives
an Agent Advertisement which advertises another GFA address, it MAY
still generate a Regional Registration Request message destined to
its old GFA.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 14]
Internet Draft Regional Registration 22 November 2003
5.2. Foreign Agent Considerations
When the foreign agent receives a Regional Registration Request
message from a mobile node, addressed to a GFA, it processes the
message generally according to the rules of processing a Registration
Request message addressed to a home agent (see section 4.2). The
only difference is that the GFA IP address field replaces the home
agent address field. If that address belongs to a known GFA, the
foreign agent forwards the request to the indicated GFA. Otherwise,
the foreign agent MUST generate a Regional Registration Reply with
error code UNKNOWN_GFA.
For each pending or current registration, the foreign agent maintains
a visitor list entry as described in [9]. If reverse tunneling is
being used, the visitor list MUST contain the address of the GFA, in
addition to the fields required in [9]. This is required so that the
foreign agent can tunnel datagrams, sent by the mobile node, to the
GFA. The GFA then decapsulates the datagrams, re-encapsulates them
and sends them to the home agent.
5.3. GFA Considerations
If the GFA accepts a request for regional registration, it MUST set
the lifetime to be no greater than the remaining lifetime of the
mobile node's registration with its home agent, and put this lifetime
into the corresponding Regional Registration Reply. The GFA MUST NOT
accept a request for a regional registration if the lifetime of the
mobile node's registration with its home agent has expired. In that
case the GFA sends a Regional Registration Reply with the value in
the Code field set to NO_HOME_REG.
If the GFA receives a tunneled packet from a foreign agent in its
domain, then after decapsulation the GFA looks to see whether it has
an entry in its visitor list for the source IP address of the inner
IP header after decapsulation. If so, then it checks the visitor
list to see whether reverse tunneling has been requested; if it was
requested, the GFA re-encapsulates the packet with its own address
as the source IP address, and the address of the home agent as the
destination IP address.
6. Generalized NAI Extension
The revised specification for "IP Mobility Support for IPv4" [9]
defines a new extension header format, that is intended to extend
the Mobile IP extension address space. The use of a Network Access
Identifier (NAI) [1] for mobile nodes is specified for Mobile IPv4
in [3]. The Generalized NAI (GNAI) extension, defined in this
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 15]
Internet Draft Regional Registration 22 November 2003
section, uses the new extension header format to extend this idea,
enabling NAIs to be used for identifying IPv4 mobility agents (i.e.,
the Foreign Agent or the Home agent) or other possible network
elements that may be involved with the processing of Registration
Requests. For Regional Registration, only a single sub-type is
defined; it is used to carry a Foreign Agent's NAI (see section 7.2).
The GNAI extension, illustrated in figure 4, may be carried by
Registration Request and Reply messages.
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 | Sub-Type | NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Generalized NAI (GNAI) Extension
Type (Type to be assigned by IANA) (skippable)
Length 8-bit unsigned integer. Length of the extension,
in octets, excluding the extension Type and
the extension Length fields, but including the
Sub-Type field and the variable length NAI field.
Sub-Type 8-bit unsigned integer identifying the specific
sub-type of the GNAI extension, and thus be
implication the type of the entity which is to be
identified by using the NAI.
NAI A string containing the Network Access Identifier
NAI in the format prescribed in [1].
When a mobile node or home agent adds a GNAI extension to a
registration message, the extension MUST appear prior to any
authentication extensions.
When the Foreign Agent adds an GNAI extension to a registration
message, the extension MUST appear prior to any authentication
extensions added by the FA.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 16]
Internet Draft Regional Registration 22 November 2003
7. Router Discovery Extensions
This section specifies a new flag within the Mobile IP Agent
Advertisement, and an optional extension to the ICMP Router Discovery
Protocol [6].
7.1. Regional Registration Flag
The only change to the Mobility Agent Advertisement Extension
defined in [9] is a flag indicating that the domain, to which the
foreign agent generating the Agent Advertisement belongs, supports
regional registrations. The flag is inserted after the flags defined
in [9], [8] and [10].
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T|S|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The flag is defined as follows:
I Regional registration. This domain supports Regional
Registration as specified in this document.
7.2. Foreign Agent NAI Extension
The FA-NAI extension is defined as a subtype 4 of the Generalized NAI
Extension (GNAIE) (see section 6).
The foreign agent SHOULD include its NAI in the Agent Advertisement
message. If present, the Foreign Agent NAI (FA-NAI) extension
MUST appear in the Agent Advertisement message after any of the
advertisement extensions defined in [9].
By comparing the domain part of the foreign agent NAI with the domain
part of its own NAI, the mobile node can determine whether it is in
its home domain or in a visited domain, and whether it has changed
domain since it last registered.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 17]
Internet Draft Regional Registration 22 November 2003
8. Regional Extensions to Mobile IPv4 Registration Messages
In this section we specify new Mobile IP registration extensions for
the purpose of managing regional registrations.
8.1. GFA IP Address Extension
If the mobile node requests a dynamically assigned GFA, the GFA
adds a GFA IP Address extension to the Registration Request before
relaying it to the HA. The mobile node indicates that it wants a GFA
to be assigned by sending a Registration Request message with the
care-of address field set to zero. The GFA IP Address extension MUST
appear in the Registration Request message before the Foreign-Home
Authentication extension, if present.
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 | GFA IP Address ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The GFA IP Address extension
If a home agent receives a Registration Request message with the
care-of address set to zero, and a GFA IP Address extension, it MUST
register the IP address of the GFA as the care-of address of the
mobile node. When generating a Registration Reply message, the home
agent MUST include the GFA IP Address extension from the Registration
Request in the Registration Reply message. The GFA IP Address
extension MUST appear in the Registration Reply message before the
Mobile-Home Authentication extension.
The GFA IP Address extension, illustrated in figure 5 is defined as
follows:
Type TBD (GFA IP Address)
Length 4
GFA IP Address The GFA IP Address field contains the Gateway
Foreign Agent's publicly routable address.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 18]
Internet Draft Regional Registration 22 November 2003
8.2. Hierarchical Foreign Agent Extension
The Hierarchical Foreign Agent extension may be present in a
Registration Request or Regional Registration Request message. When
this extension is added to a Registration Request by a foreign
agent, the receiving mobility agent sets up a pending registration
record for the mobile node, using the IP address in the Hierarchical
Foreign Agent extension as the care-of address for the mobile
node. Furthermore, in this case, the extension MUST be appended
at the end of all previous extensions that had been included in
the registration message as received by the foreign agent. The
Hierarchical Foreign Agent extension SHOULD be protected by an FA-FA
Authentication extension. When the receiving foreign agent receives
the registration message, it MUST remove the Hierarchical Foreign
Agent extension added by the sending foreign agent.
The Hierarchical Foreign Agent extension is defined as follows:
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 | FA IP Address ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FA IP Address .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Hierarchical Foreign Agent Extension
Type TBD (Hierarchical Foreign Agent)
Length 4
FA IP Address The IP Address of the foreign agent relaying
the Registration Request.
8.3. Replay Protection Style
When a mobile node uses Mobile IP to register a care-of address
with its home agent, the style of replay protection used for the
registration messages is assumed to be known by way of a Mobility
Security Association that is required to exist between the mobile
node and the home agent receiving the request. No such pre-existing
security association between the mobile node and the GFA is likely
to be available. By default, the mobile node SHOULD treat replay
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 19]
Internet Draft Regional Registration 22 November 2003
protection for Regional Registration messages exactly as specified in
Mobile IPv4 [9] for timestamp-based replay protection.
If the mobile node requires nonce-based replay protection, also
as specified in Mobile IPv4, it MAY append a Replay Protection
extension to a home registration message. Since home registrations
are forwarded to the home agent by way of the GFA, the GFA will be
able to establish the selected replay protection (see section 4.3).
The GFA also uses this extension by adding a Replay Protection
Style extension to a Registration Reply to synchronize the replay
protection for Regional registrations (see section 4.3).
The format of this extension is shown in figure 7.
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 | Replay Protection Style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Initial Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Replay Protection Extension
Type TBD (Replay Protection Style)
Length 2
Replay Protection Style
An integer specifying the style of replay protection
desired by the mobile node.
Initial Identification
The timestamp or nonce to be used for initial
synchronization for the replay mechanism.
Admissible values for the Replay Protection Style are as follows:
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 20]
Internet Draft Regional Registration 22 November 2003
Value Replay Protection Style
----- -----------------------
0 timestamp [9]
1 nonce [9]
The Replay Protection Style extension MUST be protected by an
authentication extension. If the mobile node has an established
mobility security association with the GFA, the Replay Protection
Style extension SHOULD be placed after the MN-HA authentication
extension and before the MN-FA authentication extension. Otherwise
the Replay Protection Style extension MUST be placed before the MN-HA
authentication extension.
Replay protection MAY also be provided through a challenge-response
mechanism, at the foreign agent issuing the Agent Advertisement, as
described in [5].
8.4. New Code Values for Registration Reply
The values to use within the Code field of the Registration Reply are
defined in [9]. In addition, the following values are defined:
Registration denied by the FA:
Error Name Value Section of Document
---------------------- ----- -------------------
SMOOTH_HO_REQUIRED TBD B.4
Registration denied by the GFA:
Error Name Value Section of Document
---------------------- ----- -------------------
REPLAY_PROT_UNAVAIL TBD 8.3
GFA_ID_MISMATCH TBD 4.3
Registration denied by the HA:
Error Name Value Section of Document
---------------------- ----- -------------------
ZERO_CAREOF_ADDRESS TBD 4.4
ZERO_COA_NOT_SUPP TBD 4.4
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 21]
Internet Draft Regional Registration 22 November 2003
9. Regional Registration Message Formats
This section specifies two new registration message types: Regional
Registration Request and Regional Registration Reply. These messages
are used by the mobile node instead of the existing Registration
Request and Registration Reply, in order to make registration work
faster, and also to reduce network load for Mobile IP registration,
as described in section 5.
Regional registration messages are protected by requiring
authentication extensions, in the same way as the existing Mobile IP
registration messages are protected. The following rules apply to
authentication extensions:
- The Mobile-GFA Authentication extension [9] MUST be included in
all regional registration messages.
- The Mobile-Foreign Authentication extension [9] MAY be included
in regional registration messages.
- The Foreign-Home Authentication extension [9] MUST NOT be
included in any regional registration message.
9.1. Regional Registration Request
The Regional Registration Request, illustrated below, is used by a
mobile node to register with its current GFA.
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|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 22]
Internet Draft Regional Registration 22 November 2003
The Regional Registration Request message is defined as the
Registration Request message in [9], but with the following changes:
Type TBD (Regional Registration Request)
GFA IP Address
The IP address of the Gateway Foreign Agent. (Replaces
Home Agent field in Registration Request message
in [9].)
Care-of Address
Care-of address of local foreign agent; MAY be set to
all ones.
Extensions
For the Regional Registration Request, the Hierarchical Foreign Agent
Extension is also an allowable extension in addition to those which
are allowable for the Registration Request message.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 23]
Internet Draft Regional Registration 22 November 2003
9.2. Regional Registration Reply
The Regional Registration Reply message, illustrated below, delivers
the indication of regional registration acceptance or denial to a
mobile node. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regional FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
This message is defined as the Registration Reply message in [9], but
with the following changes:
Type TBD (Regional Registration Reply)
Regional FA IP Address
The IP address of the Gateway Foreign Agent. (Replaces
Home Agent field specified in Mobile IPv4 [9]).
Extensions
The Regional FA IP Address is the address of the regional foreign
agent generating the Regional Registration Reply message. For the
two-level hierarchy specified here, it is the address of the GFA. For
more levels of hierarchy, it may be the address of an intermediate
RFA.
9.3. New Regional Registration Reply Code Values
For a Regional Registration Reply, the following additional Code
values are defined in addition to those specified in Mobile IPv4 [9].
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 24]
Internet Draft Regional Registration 22 November 2003
Registration denied by the FA:
Error Name Value Section of Document
---------------------- ----- -------------------
UNKNOWN_GFA TBD 5.2
GFA_UNREACHABLE TBD
GFA_HOST_UNREACHABLE TBD
GFA_PORT_UNREACHABLE TBD
SMOOTH_HO_REQUIRED TBD B.4
Registration denied by the GFA:
Error Name Value Section of Document
---------------------- ----- -------------------
NO_HOME_REG TBD 5.3
The four first Code values are returned to the mobile node in
response to ICMP errors that may be received by the foreign agent.
10. Authentication Extensions
In this section, two new subtypes for the Generalized Authentication
Extension [5] are specified. First, the FA-FA Authentication
extension is used by regional foreign agents to secure the
Hierarchical Foreign Agent (HFA) extension to the Registration
Request and Regional Registration Request messages. A new
authentication extension is necessary because the HFA extension
is typically added after the Mobile-Home (or some other
authorization-enabling [9] (e.g. MN-AAA [3], see section C)
authentication extension.
The MN-GFA authentication extension is used whenever the mobile node
has a co-located address. Furthermore, the MN-GFA extension is used
to provide authentication for a Regional Registration Request.
The subtype values for these new subtypes are as follows:
Subtype Name Value
---------------------- ------
FA-FA authentication TBD
MN-GFA authentication TBD
The default algorithm for computation of the authenticator is the
same as for the MN-AAA Authentication subtype defined in [5].
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 25]
Internet Draft Regional Registration 22 November 2003
11. IANA considerations
This document defines:
- The Generalized NAI extension, specified in section 6. The type
number for this new extension is to be assigned from the number
space for Mobile IPv4 skippable extensions (128-255).
- A Sub-Type for the GNAI extension is specified in section 7.2,
which needs to have a value assigned from the space of GNAI
subtypes.
- Three new extensions to Mobile IP Registration messages: GFA IP
Address, Hierarchical Foreign Agent, and Replay Protection Style
(see section 8.1, 8.2 and 8.3). The Type values for the GFA IP
Address extension must be within the range 0 through 127, while
the other two must be within the range 128 through 255.
- New Code values for Registration Reply messages (see
section 8.4).
- Two new subtypes for the Generalized Authentication
Extension [5]; see section 10
- Two new message types for Mobile IP: Regional Registration
Request and Regional Registration Reply (see section 9.1
and 9.2).
- Code values for Regional Registration Reply messages (see section
9.3)
12. Security Considerations
This document proposes a method for a mobile node to register locally
in a visited domain. The authentication extensions to be used are
those defined either in [9], [10], or [4]. Key distribution is to be
performed, for instance, according to [4], or [11].
If the Hierarchical Foreign Agent (HFA) extension is appended to a
Registration Request message, that extension is to be followed by
an FA-FA Authentication Extension (see section 10) to prevent any
modification to the data. Likewise, if the GFA IP Address extension
is added to such a message, it is to be followed by an authentication
extension.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 26]
Internet Draft Regional Registration 22 November 2003
13. Acknowledgements
This document is a logical successor to documents written with Pat
Calhoun and Gabriel Montenegro; thanks to them and their many efforts
to help explore this problem space. Many thanks also to Jari Malinen
at the Nokia Research Center for his commentary on a rough version of
this document, and providing motivation for section B.4.
The text in section 6 was taken directly from a previous Internet
Draft [7] written by Mohamed M. Khalil, Emad Qaddoura, Haseeb
Akhtar of Nortel Networks, along with Pat R. Calhoun of Black Storm
Networks.
References
[1] B. Aboba and M. Beadles. The Network Access Identifier.
Request for Comments (Proposed Standard) 2486, Internet
Engineering Task Force, January 1999.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier
Extension for IPv4. Request for Comments (Proposed Standard)
2794, Internet Engineering Task Force, January 2000.
[4] P. Calhoun and C. Perkins. DIAMETER Mobile IP Extensions (work
in progress). Internet Draft, Internet Engineering Task Force.
draft-ietf-aaa-diameter-mobileip-06.txt, June 2001.
[5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension. Request for Comments (Proposed
Standard) 3012, Internet Engineering Task Force, December 2000.
[6] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[7] Mohamed Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R.
Calhoun. Generalized NAI Extension (GNAIE) (work in progress).
draft-ietf-mobileip-gnaie-00.txt, September 2001.
[8] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised.
Request for Comments (Proposed Standard) 3024, Internet
Engineering Task Force, January 2001.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 27]
Internet Draft Regional Registration 22 November 2003
[9] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 3344, Internet Engineering Task Force,
August 2002.
[10] C. Perkins and D. Johnson. Route Optimization in Mobile IP
(work in progress). Internet Draft, Internet Engineering Task
Force.
draft-ietf-mobileip-optim-11.txt, September 2001.
[11] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys
for Mobile IP (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-ietf-mobileip-aaa-key-10.txt, October 2002.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 28]
Internet Draft Regional Registration 22 November 2003
A. Changes from Previous Versions
The following updates and changes were made in this version of the
Mobile IP Regional Registration draft, compared to earlier versions.
A.1. Updates from version 06
Updated the Abstract and Introduction.
Updated section 3.1.2
Backwards compatibility. Changed the Agent
Advertisement, so that if only one address is
advertised, it is the FA address, and not the GFA
address, and instead of advertising a zero care-of
address for dynamic allocation of GFA address, it is
an `all ones' address. Added section 3.4.
Added the Code `ZERO_COA_NOT_SUPP' for Registration
Replies.
Let the GFA add the GFA IP Address extension to a
Registration Request, instead of the FA, i.e. moved
text from section 4.2 to section 4.3 and updated
section 8.1.
Clarified how home registrations that are about
to expire should be handled in section 4.1 and
section 4.3.
Clarified how authentication extensions should be
used in section 4.1 and section 8.3.
Changed the Reply Code HOME_REG_EXPIRED to
NO_HOME_REG, since when the registration has expired,
the binding is removed, and the GFA doesn't know if a
binding for this mobile node has ever existed.
Clarified that the GFA IP address extension must be
protected when the Registration Request is sent to
the HA in section 4.3.
Added a way for the GFA to synchronize the replay
protection with the mobile node for Regional
registrations in sections 4.3, 8.3, and 8.4.
Clarified the use of Binding Updates for multiple
hierarchies in section B.2 and B.3.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 29]
Internet Draft Regional Registration 22 November 2003
Upgraded citations for RFC 2002 to instead refer to
RFC 3344.
A.2. Updates from version 05
Specified the GNAI extension (see section 6, as was
previously done in [7]. Changed IANA considerations
and section 7.2 as needed.
Upgraded citations for RFC 2002 to instead refer to
RFC 3220.
A.3. List of updates made for previous revisions
Added `v4' to the title, changed all code values,
message types and extensions to `TBD', and added an
`IANA Considerations' section.
Section 3.3 Clarified that the care-of address can be zero.
Section 4.2 Added that any Foreign Agent that supports regional
registrations must be able to assign a GFA to
a mobile node if the care-of address in the
Registration Request is zero.
Section 5.2 Clarified that in regional registrations the GFA
address field replaces the HA address field.
Section 5.3 Added a new error code: HOME_REG_EXPIRED that the
GFA use when denying a regional registration because
the home registration lifetime has expired.
Section 7.1 Clarified the placement of the 'I' flag.
Section 10 Added reference to a default algorithm for the
authentication extensions.
Section B.5 Added a section to allow a mobile node with a
co-located care of address to use multi-level
hierarchies.
Section B.4 Interactions with delivery of Binding Update messages
to RFAs along the previous routing path have been
suggested in order to prevent various race conditions
that have been observed in practice.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 30]
Internet Draft Regional Registration 22 November 2003
A.4. Updates from version 02
The following updates and changes were made in this version of the
Mobile IP Regional Registration draft, compared to the earlier
version (version 02).
Section 4.3 The contents of the visitor list entry at the
GFA have been clarified. A GFA keeps a visitor
list entry for each pending or current home
registration. The entry is also updated for the
regional registrations performed by the mobile
node.
Section 8.4 A new code value for the Registration Reply has
been defined: MISSING_GFA_ADDRESS. This section
has also been re-structured for clarification.
Section 5.1 Specific message types for regional
registrations messages (Regional Registration
Request and Regional Registration Reply) were
defined. The reason for defining specific
message types for the regional registration
messages, instead of using the Registration
Request and Reply as defined in [9] are the
following:
- a mobile node must be able to distinguish
between regional registrations and home
registrations, because when it uses
regional registration, the nonces are not
synchronized with its home agent;
- a mobile node can use a zero care-of
address either to request a GFA (in a home
registration) or to signify the use of an
unspecified regional foreign agent (in a
regional registration).
For regional registrations, the
challenge-response mechanism may be used
to provide replay protection. In this case, the
mobile node inserts the 64 bit response value
in the Identification field in the Regional
Registration Request.
Section 7.2 The FA-NAI extension is defined as a subtype TBD
of the Generalized NAI Extension (GNAIE).
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 31]
Internet Draft Regional Registration 22 November 2003
Section 9 This entire section is added to the draft, and
it describes the Regional Registration Request
and Regional Registration Reply messages.
Appendix B The contents of the visitor list entry at the
RFA and GFA have been clarified. An RFA/GFA
keeps a visitor list entry for each pending or
current home registration. The entry is also
updated for the regional registrations performed
by the mobile node.
Appendix D This appendix has been added to the draft. It
clarifies how a mobile node can register a
care-of address with its home agent; a GFA, RFA
or FA care-of address, and then maintain this
care-of address when it moves in the visited
domain.
B. Hierarchical Foreign Agents
The main body of this specification assumes two hierarchy levels of
foreign agents in the visited domain. At the top level, there is one
or several GFAs, and on the lower level, there is a number of foreign
agents. The structure can be extended to include multiple hierarchy
levels of foreign agents beneath the GFA level (Figure 8). Such
multiple hierarchy levels are discussed in this appendix.
We assume that security associations have been established among
a GFA and all the foreign agents beneath it in the hierarchy. As
before, we assume that when a mobile node performs registration at
its home network, registration keys are generated and distributed to
the mobile node and to the GFA. The GFA may then in turn distribute
the registration keys to the foreign agents beneath it in the
hierarchy, using methods not specified in this document. We also
assume that all foreign agents and the mobile node support smooth
handover as specified in [10], with some modifications as explained
below.
B.1. Registration with Home Agent
As described in this specification, a foreign agent announces itself
and a GFA in the Agent Advertisement in the first and last address
in the care-of address field in the Mobility Agent Advertisement
extension [9]. If there is a hierarchy of foreign agents between
the GFA and the announcing foreign agent, the foreign agent MUST
support smooth handover (specifically, the Previous Foreign Agent
Notification extension) as described in [10]. The foreign agent MAY
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 32]
Internet Draft Regional Registration 22 November 2003
+--------+
| |
| GFA |
| |
+--------+
/ | \
... ... ...
|
+--------+
| |
| RFA3 |
| |
+--------+
/ \
+--------+ +--------+
| | | |
| FA2 | | FA1 |
| | | |
+--------+ +--------+
| |
| +--------+
... | |
| MN |
| |
+--------+
Figure 8: Domain with a GFA and multiple hierarchies of FAs, enabled
for regional registrations.
also include the addresses of the foreign agents in the hierarchy in
order between its own address (first) and the GFA address (last):
- Address of announcing foreign agent
- Address of the next higher-level Regional Foreign Agent (RFA)
- ...
- Address of GFA
If a foreign agent advertises the entire hierarchy between itself and
the GFA, the Registration Request messages MUST be delivered to each
RFA address in turn within that hierarchy.
When newly arriving at a visited domain, the mobile node sends
a Registration Request, with the care-of address set to the GFA
address announced in the Agent Advertisement. The mobile node may
also request a GFA to be assigned, as described earlier in this
specification. The registration Request MUST include the Previous
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 33]
Internet Draft Regional Registration 22 November 2003
Foreign Agent Notification Extension defined in [10]. The Binding
Update that results is processed as described in Section B.2.
When the foreign agent closest to the mobile node receives the
Registration Request, processing is as described in Section 4.2.
It adds a Hierarchical Foreign Agent extension to the Registration
Request, including its own address, and relays the Registration
Request to the next RFA in the hierarchy toward the GFA. It also
constructs a Binding Update and sends it to the previous foreign
agent, as defined in [10].
The next RFA receives the Registration Request. For each pending
or current registration, an RFA maintains a visitor list entry. In
addition to the list entry contents (described in [9]), the list
entry for regional registrations MUST contain:
- the address of the next lower-level RFA, or FA, in the hierarchy
- the remaining Lifetime of the regional registration
- the style of replay protection in use for the regional
registration
- the Identification value for the regional registration.
The RFA removes the Hierarchical Foreign Agent extension that the
last FA or RFA added, and adds a new Hierarchical Foreign Agent
extension with its own address. This procedure is repeated at each
RFA, or FA, in the hierarchy under the GFA.
When the GFA receives the Registration Request, it removes the
Hierarchical Foreign Agent extension and caches information about
the next lower-level RFA in the hierarchy. It then relays the
Registration Request to the home agent, possibly via AAA servers.
For each pending or current home registration, the GFA maintains
a visitor list entry as described in [9]. The list entry is also
updated for regional registrations reaching the GFA. In addition to
the list entry contents required in [9], the list entry MUST contain:
- the address of the next lower-level RFA in the hierarchy
- the remaining Lifetime of the regional registration
- the style of replay protection in use for the regional
registration
- the Identification value for the regional registration.
If there is only one level of hierarchy beneath the GFA, the address
of the next lower-level RFA is the current care-of address of the
mobile node, as stated in Section 4.3.
The home agent, as described before, processes the Registration
Request, stores the GFA address as the current care-of address of
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 34]
Internet Draft Regional Registration 22 November 2003
the mobile node, generates a Registration Reply, and sends it to the
GFA. The home agent also distributes a registration key to the mobile
node, perhaps with the assistance of the GFA, for instance by way of
other AAA functions [11]. When the GFA receives the Registration
Reply, it checks its pending Registration Request record to see which
next lower-level RFA to send the Registration Reply message to.
It SHOULD then add, for instance, a new FA-FA Key Reply extension
to the Registration Reply message, before relaying it to the next
foreign agent. The new FA-FA Agent Key Reply extension contains the
registration key, encrypted with a secret shared between the GFA and
the next lower-level RFA in the hierarchy. Similar procedures are to
be used with [11].
The next lower-level RFA receives the Registration Reply and checks
its pending Registration Request record to see which lower-level
foreign agent should next receive the Registration Reply. It
extracts, decrypts and caches the registration key, and relays the
Registration Reply to the next foreign agent. This procedure is
repeated in every foreign agent in the hierarchy, until the message
reaches the foreign agent closest to the mobile node.
When the lowest-level foreign agent receives the Registration Reply,
it checks its cached information, as described in [9], and relays the
Registration Reply to the mobile node.
B.2. Handling Binding Updates
Meanwhile, when the previous foreign agent receives the Binding
Update, it will process it according to [10], except that instead
of sending back a Binding Acknowledge message, it sends the Binding
Update to the next RFA in the hierarchy towards the GFA. This is
done to make sure that all RFAs in the path to the previous FA are
notified that the mobile node has moved. The previous foreign agent
must be sure that the next RFA received the Binding Update, therefore
the RFA MUST send a Binding Acknowledge message back to the foreign
agent that it got the Binding Update from. Note that this is the
same Binding Acknowledge message than the one defined in [10], but
this one is addressed to the IP address of the Foreign Agent that
sent the Binding Update instead of to the mobile node.
The RFA that received the Binding Update sends the Binding
Acknowledge message back to the lower-layer Foreign Agent, and relays
the Binding Update to the next RFA in the hierarchy towards the GFA.
The RFA will also update the binding cache for the mobile node so
that it will expire according to the lifetime in the Binding Update,
but the binding cache entry will still point to the same lower-level
foreign agent.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 35]
Internet Draft Regional Registration 22 November 2003
The crossover FA is the foreign agent lowest in the hierarchy which
is part of both the old and the new path to the mobile node. When
the Binding Update reaches the crossover FA, which might be an RFA or
the GFA, it will, in addition to sending a Binding Acknowledge back
to the sending RFA, also send a Binding Acknowledge to the mobile
node. This Binding Acknowledge message is the one defined in [10]
and it is addressed to the mobile node and sent down the hierarchy
via the old path and the previous Foreign Agent, who tunnels it to
the new Foreign Agent.
The crossover FA will receive both a Registration Request and a
Binding Update for the mobile node. When the crossover FA receives
the Registration Request, it continues to send traffic via the
old path until it receives a valid Registration Reply with a Code
indicating success. Then it starts sending traffic via the new
route.
In the unlikely event that the crossover FA receives the Binding
Update before it receives the Registration Request, it doesn't know
that it is the crossover FA yet, and therefore relays the Binding
Update to the next Foreign Agent. When the crossover FA later
receives the Registration Request, it will know that it is the
crossover FA, and will send a Binding Acknowledge message to the
mobile node (via the old route). It also forwards the Registration
Request up to the next FA. The foreign agents above the crossover FA
in the hierarchy that already got the Binding Update will see that
the Registration Request does not supply any new care-of address
information (the care-of address is the same as the address in
the Binding Update) and will therefor ignore the previous Binding
Update and update the mobility binding according to the Registration
Request.
B.3. Regional Registration
A Regional Registration Request is forwarded to the GFA by way of
one or more intermediate regional foreign agents. When the Regional
Registration Request message arrives at the first foreign agent, the
foreign agent checks its visitor list to see if this mobile node
is already registered with it. If it is not, the foreign agent
checks which next higher-level RFA to relay the Regional Registration
Request to. It adds a Hierarchical Foreign Agent extension to the
Regional Registration Request, including its address, and relays the
message to the next RFA in the hierarchy toward the GFA.
The next RFA checks its visitor list to see if the mobile node is
already registered with it. If it is not, the RFA removes the
Hierarchical Foreign Agent extension and adds a new one, with its own
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 36]
Internet Draft Regional Registration 22 November 2003
address, and relays the message to the next higher-level RFA in the
hierarchy toward the GFA.
This process is repeated in each RFA in the hierarchy, until an RFA
recognizes the mobile node as already registered. This RFA may be
the GFA, or any RFA beneath it in the hierarchy. If the mobile node
is already registered with this RFA, the RFA generates a Regional
Registration Reply and sends it to the next lower-level RFA in the
hierarchy. The lifetime field in the Regional Registration Reply is
set to the remaining lifetime that was earlier agreed upon between
the mobile node and the GFA. If the lifetime of the GFA registration
has expired, the Regional Registration Request is relayed all the way
to the GFA.
The Previous Foreign Agent Notification Extension, Binding Updates
and Binding Acknowledge messages are used for Regional Registrations
in the same way as for Home Registrations. That means that if the
crossover FA receives the Binding Update before it receives the
Registration Request, it forwards the Registration Request to the
higher level FA, so that that FA updates its visitor list according
to the Registration Request, and ignores the Binding Update. That FA
also forwards the Registration Request to any FA or GFA that it has
sent the corresponding Binding Update to.
If the hierarchy between the advertising foreign agent and the GFA is
announced in the Agent Advertisement, the mobile node may generate
a Regional Registration Request not destined to the GFA, but to the
closest RFA with which it can register.
Replay protection can be provided at the announcing foreign agent,
through the challenge-response mechanism described in [5]. If the
GFA, and the RFAs in the hierarchy, trust the announcing foreign
agent to perform the replay protection, timestamps or nonces between
the mobile node and the GFA, or between the mobile node and each
RFA, are not needed. If the challenge-response mechanism is used
for replay protection, the mobile node inserts the 64 bit response
value in the Identification field in the Regional Registration
Request message. If a mobile node includes a Hierarchical Foreign
Agent extension in its Registration Request message, it MAY insert
the extension before the MN-HA or MN-FA authentication extension.
In this case, the Hierarchical Foreign Agent extension MUST NOT be
removed by the GFA or any other RFA prior to the generation of the
Registration Reply message.
If more than one Hierarchical Foreign Agent extension is inserted
by the mobile node into the registration message, the order of the
extensions MUST be maintained through the hierarchy. When sending a
Regional Registration Reply, the GFA MUST ensure that the order of
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 37]
Internet Draft Regional Registration 22 November 2003
the Hierarchical Foreign Agent extensions is reversed from the order
found in the Regional Registration Request.
B.4. Regional Registrations and Smooth Handover
Multiple hierarchy levels of foreign agents requires the use of
smooth handover from [10], as discussed in Appendix B. This is
not needed in a two level hierarchy. But a mobile node might not
know how many levels of hierarchy a network has, so if the foreign
agents in one network support both Regional Registrations and
Smooth Handover a mobile node MAY try to use Regional Registrations
without Smooth Handover. If the network requires the use of Smooth
Handover (because it has more than two levels of hierarchy, or
for other reasons) the Foreign Agent MUST deny the request by
sending back a Registration Reply message with the Code field set to
SMOOTH_HO_REQUIRED.
The Foreign Agent NAI extension (see section 7.2) is also used during
Smooth Handover. If Smooth Handovers are used, and the foreign
agent does not advertise its own address in the Agent Advertisement
message, the FA-NAI will be used to identify the Previous Foreign
agent instead. This will be done by adding an FA-NAI extension
(defined in section 6) to the Registration Request (together with the
Previous Foreign Agent Notification extension) and in the Binding
Update and setting the care-of address to zero.
B.5. Co-located care of address
If a mobile node uses a co-located care-of address, it MAY use
Regional Registrations directly to the GFA (see section 4.1 and
section 5). It MAY also use the same method to make use of multiple
levels of Foreign Agents, if it can find out about the hierarchy,
either from Mobility Agent Advertisements, or in some other way
outside the scope of this specification.
B.6. Data Traffic
When a correspondent node sends traffic to the mobile node, the
traffic arrives at the home agent, and the home agent tunnels the
traffic to the GFA. The GFA or RFA at each level of the hierarchy has
a visitor list for the mobile node, showing the address of the next
lower-level RFA or FA in the hierarchy. Thus, a datagram arriving at
the top level of the hierarchy, that is, the GFA, will be re-routed
to the next lower-level RFA in the hierarchy. This re-routing occurs
at each level of the hierarchy, until the datagram reaches the last
point which is either the mobile node itself (in case of a co-located
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 38]
Internet Draft Regional Registration 22 November 2003
care-of address) or a foreign agent that can deliver the datagram to
the mobile node with no further special Mobile IP handling.
In case of decapsulation and re-encapsulation, it should be noted
that the actual decapsulation need not occur at each step of the
hierarchy. Instead, the foreign agent at that level can merely
change the source and destination IP addresses of the encapsulating
IP header.
Traffic from the mobile node is sent as described in [9] or [8].
According to the Route Optimization specification [10], Binding
Updates send to the correspondent node from the Home Agent
will contain the address of the GFA, since this is the only
care-of address known to the Home Agent. Therefore, Binding Updates
from the mobile node sent to the correspondent node SHOULD also have
the care-of address belonging to the GFA. This also has the advantage
of reducing the number of Binding Update messages that have to be
sent to the correspondent node, at a modest increase in routing path
length. Furthermore, the local network domain may be configured to
admit such traffic into the local domain only if packets are tunneled
directly to the GFA.
B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension
If a GFA uses the Registration Reply to distribute an MN-FA key to
the other RFAs in its domain, a new subtype for the Generalized MN-FA
Key Reply Extension [11] is required.
The subtype value is as follows:
Subtype Name Value
-------------- ------------
GFA-RFA Key Reply 5
The subtype data for the GFA-RFA Key Reply subtype is a 4 byte SPI,
followed by the registration key encoded according to the recipe
indicated by the SPI.
C. Authentication, Authorization and Accounting AAA Interactions
When the mobile node has to obtain authorization by way of
Authentication, Authorization and Accounting (AAA) infrastructure
services, the control flow implicit in the main body of this
specification is likely to be modified. Typically, the mobile node
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 39]
Internet Draft Regional Registration 22 November 2003
will supply credentials for authorization by AAA as part of its
registration messages. The GFA will parse the credentials supplied
by the mobile and forward the appropriate authorization request to a
local AAA server (see [5, 4]).
Concretely, this means that:
- The GFA MAY include the Mobile IP Registration Request data
inside an authorization request, directed to a local AAA server.
- The GFA MAY receive the Mobile IP Registration Reply data
from a message granting authorization, received from the AAA
infrastructure.
D. Anchoring at a GFA/RFA/FA
As described earlier in this draft, once a mobile node has registered
the address of a GFA as its care-of address with its home agent, it
MAY perform regional registrations when changing foreign agent under
the same GFA. When detecting that is has changed foreign agent, and
if the new foreign agent advertises the `I' flag, the mobile node MAY
address a Regional Registration Request message to its registered
GFA, even if the address of that particular GFA is not advertised by
the new foreign agent. The foreign agent MAY then relay the request
to the GFA in question, or deny the request with error code 'unknown
GFA'.
Similarly, a mobile node MAY address a Regional Registration Request
message to any Regional Foreign Agent or foreign agent that it has
registered as the current care-of address with its home agent.
Assume that a mobile node has registered the address of an RFA or
foreign agent as its care-of address with its home agent. When
detecting that it changes foreign agent, and if the new foreign agent
advertises the `I' flag, the mobile node MAY address a Regional
Registration Request to that RFA/FA. The new foreign agent MAY then
relay the request to the RFA/FA in question, or deny the request
with error code 'unknown GFA'. If the Regional Registration Request
reaches the RFA/FA, and if the RFA/FA also has the capability to
act as a GFA, it MAY accept the request and generate a Regional
Registration Reply to the mobile node. This scenario assumes that
keys have been distributed to the RFA/FA and to the mobile node prior
to the regional registration, so that the Regional Registration
Request message can be authenticated with the MN-GFA Authentication
extension.
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 40]
Internet Draft Regional Registration 22 November 2003
Addresses
Questions about this memo can be directed to:
Eva Gustafsson Annika Jonsson
Ericsson Research Ericsson Research
Torshamnsgatan 23 Torshamnsgatan 23
SE-164 80 Stockholm SE-164 80 Stockholm
SWEDEN SWEDEN
Phone: +46 8 7641270 Phone: +46 8 4047242
EMail: eva.gustafsson@ericsson.com EMail: annika.jonsson@ericsson.com
Fax: +46 8 4047020 Fax: +46 8 4047020
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charles.perkins@nokia.com
Fax: +1 650 625-2502
Gustafsson, Jonsson, Perkins Expires 22 May 2004 [Page 41]
