WDIFF

draft-ietf-mip4-reg-tunnel-00.txt --> draft-ietf-mip4-reg-tunnel-01.txt

MIP4 Working Group E. Gustafsson
Internet-Draft A. Jonsson
Expires: May 23, 2005 June 2, 2006 Ericsson
C. Perkins
Nokia Research Center
November 22, 2004 29, 2005

Mobile IPv4 Regional Registration
draft-ietf-mip4-reg-tunnel-00
draft-ietf-mip4-reg-tunnel-01

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667.

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she become becomes
aware will be disclosed, in accordance with
RFC 3668. Section 6 of BCP 79.

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.

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.

This Internet-Draft will expire on May 23, 2005. June 2, 2006.

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, "regional registrations", i.e. registrations

Gustafsson, et al. Expires May 23, 2005 [Page 1]

Internet-Draft Mobile IPv4 Regional Registration November 2004 local to the visited
domain. The regional signaling is registrations are performed via a new network
entity called a Gateway Foreign Agent (GFA) and introduces introduce a layer of
hierarchy in the visited domain. Regional registrations reduce the

Gustafsson, et al. Expires June 2, 2006 [Page 1]

Internet-Draft Mobile IPv4 Regional Registration November 2005

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 document is an optional
extension to the Mobile IPv4 protocol.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Regional Registrations . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 6
4. Description of the Protocol . . . . . . . . . . . . . . . . . 6
3.1 8
4.1. General Assumptions . . . . . . . . . . . . . . . . . . . 6
3.1.1 8
4.1.1. Visited Domain . . . . . . . . . . . . . . . . . . . . 7
3.1.2 9
4.1.2. Authentication . . . . . . . . . . . . . . . . . . . . 7
3.2 9
4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
3.3 10
4.3. Advertising Foreign Agent and GFA . . . . . . . . . . . . 9
3.4 11
4.4. Backwards compatibility with RFC3344 . RFC 3344 . . . . . . . . . . 10
4. 11
5. Home Registration . . . . . . . . . . . . . . . . . . . . . . 10
4.1 12
5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 10
4.2 12
5.2. Foreign Agent Considerations . . . . . . . . . . . . . . . 12
4.3 13
5.3. GFA Considerations . . . . . . . . . . . . . . . . . . . . 13
4.4 14
5.4. Home Agent Considerations . . . . . . . . . . . . . . . . 14
5. 15
6. Regional Registration . . . . . . . . . . . . . . . . . . . . 15
5.1
6.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 16
5.2
6.2. Foreign Agent Considerations . . . . . . . . . . . . . . . 17
5.3
6.3. GFA Considerations . . . . . . . . . . . . . . . . . . . . 17
6. Generalized NAI Extension
7. Dynamic GFA Assignment . . . . . . . . . . . . . . . . . . . . 18
7.
7.1. Mobile Node Considerations for Dynamic GFA Assignment . . 18
7.2. Foreign Agent Considerations for Dynamic GFA Assignment . 18
7.3. GFA Considerations for Dynamic GFA Assignment . . . . . . 19
7.4. Home Agent Considerations for Dynamic GFA Assignment . . . 19
7.5. Regional Registration . . . . . . . . . . . . . . . . . . 20
8. Router Discovery Extensions . . . . . . . . . . . . . . . . . 19
7.1 20
8.1. Regional Registration Flag . . . . . . . . . . . . . . . . 19
7.2 20
8.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 19
8. 21
9. Regional Extensions to Mobile IPv4 Registration Messages . . . 20
8.1 21
9.1. GFA IP Address Extension . . . . . . . . . . . . . . . . . 20
8.2 21
9.2. Hierarchical Foreign Agent Extension . . . . . . . . . . . 21
8.3 22
9.3. Replay Protection Style . . . . . . . . . . . . . . . . . 22
8.4 23
9.4. New Code Values for Registration Reply . . . . . . . . . . 23
9. 24
10. Regional Registration Message Formats . . . . . . . . . . . . 24
9.1 25
10.1. Regional Registration Request . . . . . . . . . . . . . . 24
9.2 25
10.2. Regional Registration Reply . . . . . . . . . . . . . . . 25
9.3 27
10.3. New Regional Registration Reply Code Values . . . . . . . 26
10. 28
11. Authentication Extensions . . . . . . . . . . . . . . . . . 27
11. . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . 28
12. . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 29
14.2 Informative References . . . . . . . . . . . . . . . . . . . 29 30

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 2]

Internet-Draft Mobile IPv4 Regional Registration November 2004

Authors' Addresses . . . . . . . 2005

14. Acknowledgements . . . . . . . . . . . . . . . 30
A. Hierarchical Foreign Agents . . . . . . . . 30
15. References . . . . . . . . . 30
1. Registration with Home Agent . . . . . . . . . . . . . . . . . 31
2. Handling Binding Updates . .
15.1. Normative References . . . . . . . . . . . . . . . . . 34
3. Regional Registration . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 35
4. Regional Registrations 31
Appendix A. Authentication, Authorization and Smooth Handover . . . . . . . . . . 36
5. Co-located care of address . . . . . . . . . . . . . . . . . . 37
6. Data Traffic . . . . . . . . Accounting
(AAA) Interactions . . . . . . . . . . . . . . . . . 37 31
Appendix B. Authentication, Authorization and Accounting (AAA)
Interactions . . Anchoring at a GFA . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . 38
C. Anchoring at a GFA/RFA/FA . . . . . . . . . . . . . . . . . . 38 33
Intellectual Property and Copyright Statements . . . . . . . . 40 . . 34

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 3]

Internet-Draft Mobile IPv4 Regional Registration November 2004 2005

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 [RFC3344], 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
minimize 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

Regional registrations introduce a
_home_registration new network node: the Gateway
Foreign Agent (GFA). The address of the GFA is advertised by the
foreign agents in a visited domain. When a mobile node first arrives
at this 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 [I-D.ietf-mip4-aaa-key]) 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 GFA as its care-of address that is registered at
the with its
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. agent. When changing GFA, a
mobile node MUST perform a home registration; when changing moving between different foreign
agent under agents within the
same GFA, visited domain, the mobile node MAY instead perform only needs to make a regional
registration within to the visited domain. GFA.

In its simplest form, regional registrations are performed
transparently to the home agent. Additionally, regional
registrations may also allow dynamic assignment of GFA. The solution
for dynamic GFA assignment requires support in the mobile node, the
foreign agent, the GFA and the home agent.

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 hierarchy. Multiple levels of
hierarchy is not discussed in Appendix A. this document.

Foreign agents that support regional registrations are also required
to support registrations according to Mobile IPv4 [RFC3344]. If
there is a foreign agent address announced in the Agent

The following section gives an overview of regional registrations.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 4]

Internet-Draft Mobile IPv4 Regional Registration November 2004

Advertisement, 2005

2. Overview of Regional Registrations

In standard Mobile IP, there are three entities of interest. The
Mobile Node (MN), the mobile node may register that foreign agent
care-of address with its home agent [RFC3344]. Similarly, if Foreign Agent (FA), and the
mobile node chooses not to employ regional registrations, Home Agent (HA).
The MN communicates with the HA, either through an FA, or directly
(if it may
register has a co-located care-of address directly with its home agent,
according to [RFC3344].

2. Terminology

In this document, address). With Regional
Registrations, a new entity is defined: the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", Gateway Foreign Agent
(GFA). The GFA sits between the MN/FA and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] HA, and indicate requirement
levels for compliant implementations.

This document uses to the following terms:

Critical type
A type value for an extension in HA, it
appears as if the range 0-127, which indicates MN's temporary care-of address is that of the extension MUST either be known to GFA.
When a MN moves within a site, it only need interact with the recipient, or GFA, so
that the message containing GFA knows at what temporary address the extension MUST be rejected. In other
words, an extension with a critical type value MN is non-skippable.

Domain
A collection currently
reachable.

Two types of networks sharing registration messages are used. Regular [RFC3344]
Registration Requests/Replies are still used for when the MN
exchanges Registration Requests/Replies with the HA, but these
messages get forwarded through a common network administration.

Foreign Agent (FA)
As defined in [RFC3344].

Gateway Foreign Agent (GFA)
A Foreign Agent which has GFA, and include new extensions.

In addition, a publicly routable IP address. new pair of registration messages, Regional
Registration Requests/Replies, are used between MNs/FAs/GFAs for
intra-site signaling. A MN uses these messages to communicate its
new addresses to the GFA
may, for instance, be placed in or near as it moves around within a firewall.

Home Agent (HA)
As defined in [RFC3344].

Home domain site.

There are two models of how the MN uses Regional Registrations. The domain where
FA can advertise a GFA to the home network and home agent are located.

Home network
As defined in [RFC3344].

Home Registration
A registration, processed by MN. Alternatively, the home agent and FA can indicate
that dynamic assignment of GFA is to be used. With dynamic GFA
assignment, the MN does not choose the GFA, using rather the
specification in [RFC3344] possibly with additional extensions
defined FA (or GFA)
does so after receiving a Registration Request from the MN. However,
in this document.

Gustafsson, et al. Expires May 23, 2005 [Page 5]

Internet-Draft Mobile IPv4 mode the HA must understand (and support) Regional Registration November 2004

Local Care-of Address
A Care-of Address which is either assigned to a mobile node, or to
a foreign agent offering local connectivity
Registrations in order for them to be used. This last form is not
transparent because the MN doesn't know in advance what GFA will be
used, and cannot include it in a mobile node. A
registration signed message from to the mobile node is subsequently sent HA.

When a MN moves to a GFA (or another RFA, see Appendix A) via new domain (determined by comparing its NAI with
the local care-of
address.

Mobile Node (MN)
As defined FA-NAI included in [RFC3344].

Mobility received Agent (MA)
As defined in [RFC3344].

Network Access Identifier(NAI)
Some features of this protocol specification rely on Advertisements), it can opt to
use of the
Network Access Identifier (NAI) [RFC2794]. Regional Foreign Agent (RFA) Registrations. A Foreign Agent which may be the target of a request site indicates support for regional
registration. Regional Registration
A mobile node performs registration locally at the visited domain,
Registrations by sending setting the I-bit of the Mobile IP Agent
Advertisement extension. In addition, such advertisements include 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
list of one or more care-of addresses. If there is only one care-of
address, this is the visited network, address of the current foreign agent
and FA itself. In addition, the GFA are located.

Visited network
As defined in [RFC3344].

3. Description of
advertisement may include the Protocol

This section provides an overview address of the regional registration
protocol.

3.1 General Assumptions

Our general model GFA. A care-of address
of operation all-ones indicates that dynamic assignment of GFA is illustrated in Figure 1, showing a
visited domain with foreign agent and GFA, and supported
(and required).

A MN requests initial Regional Registration by sending a home network with normal
Registration Request to the FA, but setting the care-of address to
that of the GFA (i.e., if it has selected it wishes to use this GFA)
or all-zeros (which signals a
home agent: dynamic GFA assignment request). The

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 6] 5]

Internet-Draft Mobile IPv4 Regional Registration November 2004

+---------------------------+ +----------------+
| Visited Domain | | Home |
| | +---------+ | Network |
| | | | | |
| +------+ +-------+ | | Public | | +------+ |
| | 2005

FA |------| GFA |-------------------------| HA | |
| +--+---+ +-------+ | | Network | | +------+ |
| | | | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+

Figure 1

For mobile nodes that cannot process adds a NAI, or with mobility agents
that are not configured to advertise their NAI, regional registration
is still useful, but Hierarchical FA (HFA) extension and relays 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 request to
the visited
domain. At appropriate GFA. The HFA extension contains a single field: the top level
IP address of the hierarchy, there is at least one
GFA, which is a foreign agent FA.

Note: the algorithm for MNs 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 co-located care-of addresses is
similar, except that there exist
established security associations between a GFA and is no FA, so the RFAs beneath
it. Multiple hierarchy levels of foreign agents are discussed MN behaves as the FA in
Appendix A. When designing a domain supporting regional
registrations,
terms of the RFAs and messages it sends.

A GFA must be compatible. That is, they
should support the same encapsulation types, compression mechanisms
etc.

When receives Registration Requests relayed from a mobile node changes FA. If the
care-of address under the same GFA, it MAY
perform a regional registration. If in the mobile node changes GFA,
within a visited domain or between visited domains, it MUST perform a
home registration.

3.1.2 Authentication

With received Registration Request is zero, the regional registration protocol, a GFA address
assigns one. A GFA IP Address extension is registered
at then added to the home agent as
Registration Request, and the care-of message is forwarded to the HA. The
GFA IP Address extension contains a single field: the IP address of
the mobile node. If a
Mobile-Foreign Authentication extension GFA. (A separate field is present in a needed for this because the
Registration Request message directed to between the home agent, the GFA will perform the
authentication. Similarly, if a Foreign-Home Authentication

Gustafsson, et al. Expires May 23, 2005 [Page 7]

Internet-Draft Mobile IPv4 Regional Registration November 2004

extension is present in a Registration Request message, the
authentication MN/HA is performed between the GFA signed and the home agent. To
summarise, the GFA takes the role of a foreign agent as regards to
security associations in the home registrations.

Regional Registration messages also have to cannot
be protected with
authentication extensions modified.)

HAs process received Registration Requests in the same way as registrations with the
home agent. This means that the mobile node and before,
except in the case of dynamic GFA MUST have
received the keys needed to construct assignment. In this case, the authentication extensions
before any Regional Registration is performed. As described above,
since HA
uses the GFA address is from the registered GFA IP Address extension as the MN's
current care-of address of address. In addition, the mobile
node at its home network, Registration Reply message
must include the GFA is the agent within the visited
domain which has to have IP Address extension.

The regular Registration Requests/Replies are protected as described
in [RFC3344], by use of the appropriate mobility security associations with association between the home agent
MN and the mobile node. The GFA's HA. For regional registrations, it is assumed that a
mobility security association
with the mobile node is then used to enable proper authentication for
regional registrations (see Section 5). How the keys are distributed is outside established between the scope of this draft. One example is that MN and GFA
during registration with the keys HA. Regional Registration Requests/
Replies are
distributed as part protected by use of this security association between the registration at
MN and the home network, for
example according to [I-D.ietf-aaa-diameter-mobileip],
[I-D.ietf-mip4-aaa-key]. Another example is pre-configured keys.

3.2 Protocol Overview

When GFA, e.g., by use of a mobile node first arrives at MN-GFA Authentication extension.

HFA extensions, added by a visited domain, it performs FA to a Registration Request or Regional
Registration Request, are protected by an FA-FA Authentication
extension. Security associations between FAs and GFAs within 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 are assumed to exist prior to regional registrations, the care-of address
that is registered at the home agent is the address of a GFA. The registrations.

Dynamic 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 assignment requires means for securely sending
Registration Requests from the GFA
address, it will not change when to the mobile node changes foreign
agent under HA, in order to protect the same GFA. Thus,
GFA IP Address extension.

3. Terminology

In this document, the home agent does not need key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be
informed of any further mobile node movements within the visited
domain.

Figure 2 illustrates interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations.

Gustafsson, et al. Expires June 2, 2006 [Page 6]

Internet-Draft Mobile IPv4 Regional Registration November 2005

This document uses the signaling message flow following terms:

Critical type
A type value for registration with an extension in the home network. After range 0-127, which indicates
that the registration at 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 [RFC3344].

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 [RFC3344].

Home domain
The domain where the home agent, network and home agent are located.

Home network
As defined in [RFC3344].

Home Registration
A registration, processed by the home agent records and the GFA address as GFA, using the
specification in [RFC3344] possibly with additional extensions
defined in this document.

Local Care-of Address
A care-of address of the mobile
node. If the GFA address was dynamically which is either assigned to the a mobile node, the Registration Reply has an extension indicating the IP
address of the GFA or to the
a foreign agent offering local connectivity to a mobile node. A
registration message from the mobile node is subsequently sent to
a GFA via the local care-of address.

Mobile Node (MN)
As defined in [RFC3344].

Mobility Agent (MA)
As defined in [RFC3344].

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 8] 7]

Internet-Draft Mobile IPv4 Regional Registration November 2004 2005

Network Access Identifier(NAI)
Some features of this protocol specification rely on use of the
Network Access Identifier (NAI) [RFC2794].

Regional Registration
A mobile node performs registration locally at the GFA and the home agent:

MN FA1 GFA HA
| | | |
| 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 [RFC3344].

4. Description of the Protocol

This section provides an overview of the regional registration
protocol.

4.1. General Assumptions

Our general model of operation is illustrated in Figure 1, showing a
visited domain with FA and GFA, and a home network with a HA:

+---------------------------+ +----------------+
| Visited Domain | |
|---------------------->| Reg. Request w/ext. | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply Home |
| | Reg. Reply w/ext. |<---------------| +---------+ | Registration Reply |<----------------------| Network |
|<----------------------|
| | | | | |

Figure 2

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
care-of address of the mobile node. We introduce two new message
types for regional registrations: Regional Registration Request and
Regional Registration Reply.

Regional registration at the GFA:

MN FA2 GFA HA
| +------+ +-------+ | | Public | | Regional Reg. Req. +------+ |
| |
|---------------------->| Regional Reg. Req. w/ext. FA |------| GFA |-------------------------| HA | |
| |----------------------------->| +--+---+ +-------+ | | Network | | Regional Reg. Reply w/ext. +------+ |
| | Regional Reg. Reply |<-----------------------------| |
|<----------------------| | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+

Figure 3

3.3 Advertising Foreign Agent and GFA

A foreign agent typically announces its presence via an Agent
Advertisement message [RFC3344]. If the domain to which a foreign
agent belongs supports regional registrations, the following changes
are applied to the Agent Advertisement message. 1

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 9] 8]

Internet-Draft Mobile IPv4 Regional Registration November 2004

The 'I' flag (see Section 7) MUST be set to indicate 2005

For MNs that the domain
supports cannot process a NAI, or with mobility agents that are
not configured to advertise their NAI, regional tunnel management. If the 'I' flag registration is set, there
MUST be at least one care-of address still
useful, but the lack of certain features may result in less than
optimal results.

4.1.1. Visited Domain

We assume two hierarchy levels of FAs in the Agent Advertisement
message, but that address MAY be set to visited domain. At the "all ones" address. If
top level of the 'I' flag is set, and hierarchy, there is only at least one care-of address (which is
not all ones), it is the address of the FA. If the 'I' flag GFA, which is set,
and a FA
with additional features. A GFA must have a publicly routable
address. Beneath a GFA, there are multiple care-of addresses, one or more FAs. We assume that
there exist established security associations between a GFA and the first care-of address
is
FAs beneath it. When designing a domain supporting regional
registrations, the local FA, FAs and GFAs in this domain must be compatible.
That is, they should support the last same encapsulation types,
compression mechanisms etc.

When a MN changes care-of address is under the GFA. The FA-NAI
(see Section 7.2) SHOULD also be present to enable same GFA, it MAY perform
a regional registration. If the mobile node to
decide whether MN changes GFA, within a visited
domain or not between visited domains, it is in its MUST perform a home domain. The decision
registration.

4.1.2. Authentication

With regional registrations, a GFA address is
based on whether registered at the realm part of HA as
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]. This allows mobile nodes
that don'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, of the MN. If a
mobile node that supports Regional Registrations but has Mobile-Foreign (MN-FA)
Authentication extension is present in a Home Agent
that doesn't, will still be able Registration Request message
directed to make use of Regional
Registrations through that the HA, the 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 perform the
mobile node requests that authentication.
Similarly, if a GFA address Foreign-Home (FA-HA) Authentication extension is dynamically assigned to it
by setting the care-of address
present in a Registration Request to zero, message, the
mobile node authentication is
performed between the GFA and its Home Agent MUST support the HA. To summarize, the GFA IP address
extension.

4. Home Registration

This section gives a detailed description takes
the role of a FA with regard to security associations in the home registration, i.e.,
registrations.

Regional registration messages also need to be protected with
authentication extensions in the home agent (on same way as registrations with the home network). Home
HA. This means that the MN and the GFA MUST have received the keys
needed to construct the authentication extensions before any regional
registration is performed when a mobile node first arrives at a
visited domain, when it requests a new performed. As described above, since the GFA address
is the registered care-of address of the MN at its home agent, or when it changes
GFA. Home registration network, the
GFA is also performed to renew bindings the agent within the visited domain which
would otherwise expire.

4.1 Mobile Node Considerations

Upon receipt of an Agent Advertisement message has to have the
appropriate security associations with the 'I' flag set HA and a FA-NAI extension, the mobile node compares MN. The GFA's
security association with the domain part of MN is then used to enable proper
authentication for regional registrations (see Section 6). How the foreign agent NAI with
keys are distributed is outside the domain part scope of its own NAI, to
determine whether it this draft. One example
is in its home domain or in a visited domain.
If to distribute the NAIs do not match, keys as part of the mobile node MUST assume it home registration, for
example according to [RFC4004], [RFC3957]. Another example is in a pre-
configured keys.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 10] 9]

Internet-Draft Mobile IPv4 Regional Registration November 2004

foreign domain. Otherwise, if the mobile node determines that it is
in its home domain, it acts as defined in [RFC3344].

If the mobile node determines that it is in 2005

4.2. Protocol Overview

When a MN first arrives at a visited domain, it
SHOULD either use performs a
registration with its home network. At this registration, the advertised GFA address in HA
registers the care-of address
field in of the Registration Request message, or set this field to zero
to request to be assigned a GFA. If MN. In case the mobile node sets visited domain
supports regional registrations, 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, is
registered at the mobile
node MUST check to make sure that it receives HA is the address of a GFA. The GFA IP address
extension in keeps a
visitor list of all the Registration Reply. If MNs currently registered with it.

Since the Foreign Agent only
advertises an "all ones" care-of address, it only supports
dynamically assigned address registered at the HA is the GFA care-of address, and it
will not change when the mobile node MUST
set MN changes FA under the care-of address in same GFA. Thus, the Registration Request to zero.

A mobile node with a co-located care-of address might also want
HA does not need to
use Regional Registrations. It then finds out the address be informed 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 further MN movements within the
visited domain.

Figure 2 illustrates the signaling message flow for home
registration. At home registration, the HA records the GFA address in
as the care-of address field, and send it directly to of the GFA (not via a foreign
agent). In this case, MN.

Registration at the mobile node MUST add a Hierarchical
Foreign Agent extension (see Section 8.2), including its co-located
care-of address, to GFA and the HA:

MN FA1 GFA HA
| | | |
| 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, even if it has a co-located care-of address, it still formulates
the same Registration | | |
|---------------------->| Reg. Request message with extensions, but it sends | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply |
| | Reg. Reply |<---------------|
| Registration Reply |<----------------------| |
|<----------------------| | |
| | | |

Figure 2

Figure 3 illustrates the signaling 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 flow for regional
registration. Even though the same GFA MN's local care-of address to refresh
the binding [RFC3344]. If the mobile node has just moved to a new
Foreign Agent and not yet sent a Regional Registration Request when changes,
the home registration is due HA continues to expire, the mobile node sends only a
home Registration Request, as this will update both record the GFA and the
HA. This Registration Request MUST be constructed address 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 of
the MN. We introduce two new message types for regional
registrations: Regional Registration Request to zero, to
avoid problems if this new Foregin Agent doesn't support the same GFA and Regional
Registration Reply.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 11] 10]

Internet-Draft Mobile IPv4 Regional Registration November 2004

as the mobile node had before.

If the 2005

Regional Registration Reply includes a Replay Protection Style
extension, the value in the Initial Identification field is the value
to be used for replay protection in at the next GFA:

4.2 Req. | |
| |----------------------------->| |
| | Regional Registration Reply | |
| Regional Reg. Reply |<-----------------------------| |
|<----------------------| | |
| | | |

Figure 3

4.3. Advertising Foreign Agent Considerations

When the foreign agent receives a Registration Request and GFA

A FA typically announces its presence via an Agent Advertisement
message from a
mobile node, it extracts the care-of address field in [RFC3344]. If the
Registration Request message, domain to find which a FA belongs supports
regional registrations, the GFA following changes apply to which the message
shall Agent
Advertisement.

The 'I' flag (see Section 8.1) MUST be relayed. All Foreign Agents set to indicate that advertise the
domain supports regional registrations. If the 'I' flag is set,
there MUST also be able to handle Registration Requests with a zero at least one care-of
address. address in the Agent
Advertisement. If the 'I' flag is set and there is only one care-of
address field (which is not all-ones), it is set to zero, the foreign
agent assigns a GFA to address of 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. FA. If the Foreign Agent receives a Registration request where the
care-of address
'I' flag 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" [RFC3344].

If the Registration Request has the 'T' bit set, and there are multiple care-of addresses, the mobile node first
care-of address is
requesting Reverse Tunneling [RFC3024]. In this case, the foreign
agent has to tunnel packets from the mobile node to the GFA for
further handling.

If local FA, and the last care-of address in the Registration Request is the address of
the foreign agent, the foreign agent relays
GFA.

The FA-NAI (see Section 8.2) SHOULD also be present in the message directly Agent
Advertisement to enable the home agent, as described in [RFC3344]. For each pending MN to decide whether or
current home registration, the foreign agent maintains a visitor list
entry as described in [RFC3344]. If reverse tunneling not it is being used,
the visitor list MUST, in addition to the fields required in
[RFC3344], contain its
home domain. The decision is based on whether the address realm part of the GFA.

Otherwise, if
advertised FA-NAI matches the MN's realm.

4.4. Backwards compatibility with RFC 3344

A domain that supports regional registrations SHOULD also be
backwards compatible.

If a FA only advertises an all-ones care-of address in the Registration Request is the
address of a (i.e. for dynamic
GFA (or zero), the foreign agent adds a Hierarchical
Foreign Agent extension, including its own address, to the
Registration Request message, and relays assignment), it to will not be backwards compatible with [RFC3344],
since the GFA. The
Hierarchical Foreign Agent extension MUST MNs and HAs will also be appended at required to support the end of
all previous regional
registration extensions that were included defined in this document.

In all other cases, the Registration
Request message when the foreign agent received it, and it SHOULD be
protected by an FA-FA Authentication extension (see Section 10). FA MUST support registrations according to

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 12] 11]

Internet-Draft Mobile IPv4 Regional Registration November 2004

4.3 GFA Considerations

For each pending or current home registration, the GFA maintains a
visitor list entry 2005

Mobile IPv4 as described defined in [RFC3344]. This visitor list
entry is also updated for the allows MNs that don't
support regional registrations performed by the
mobile node. In addition to register via this FA using standard
Mobile IPv4. If the fields required in [RFC3344], the
list entry MUST contain:

o the current FA advertises both its own care-of address and a
GFA care-of address, a MN that supports regional registrations but
has a HA that doesn't, will still be able to make use of regional
registrations through that GFA care-of address.

5. Home Registration

This section gives a detailed description of home registration, i.e.,
registration with the mobile node (i.e., HA (on the foreign
agent home network). Home registration is
performed when a MN first arrives at a visited domain, when it
requests a new HA, or co-located address) in the Hierarchical Foreign when it changes GFA. Home registration is also
performed to renew bindings which would otherwise expire.

5.1. Mobile Node Considerations

Upon receipt of an Agent
extension
o Advertisement message with the remaining Lifetime 'I' flag set
and a FA-NAI extension, the MN compares the domain part of the regional registration
o FA NAI
with the style domain part of replay protection its own NAI, to determine whether it is in use for
its home domain or in a visited domain. If the regional
registration
o NAIs do not match,
the Identification value for MN MUST assume it is in a foreign domain. Otherwise, if the regional registration.

The default replay protection style for Regional Registrations MN
determines that it is
timestamp-based replay protection, in its home domain, it acts as defined in Mobile IPv4
[RFC3344].

If the timestamp sent by MN determines that it is in a visited domain, it SHOULD insert
the mobile node advertised GFA address in the care-of address field in the
Registration Request is not close enough message.

A MN with a co-located care-of address might also want to use
regional registrations. It then finds out the GFA's time address of day
clock, the GFA adds a Replay Protection Style extension (see Section
8.3) to the GFA,
either from Agent Advertisements sent by a FA, or by some means not
described in this draft. The MN MAY then generate a Registration Reply,
Request message, with the GFAs time of day GFA address in the
Identification field care-of address field,
and send it directly to synchronize the mobile node with the GFA for
the Regional Registrations. If nonce based reply protection is used, (not via a FA). In this case, the GFA adds MN
MUST add a Replay Protection Style Hierarchical Foreign Agent (HFA) extension (see
Section 9.2), including its co-located care-of address, to the
Registration
Reply, where the high-order 32 bits in the Identification fields is
the nonce that should Request before sending it. The HFA extension MUST be used
protected by the mobile node in the following
Regional Registration. an authentication extension. If the Registration Request message contains a Replay Protection
extension (see Section 8.3) requesting MN has established
a style of replay protection
not supported by mobility security association with the GFA, the GFA HFA extension 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,
be placed before the GFA assigns a GFA care-of address for this Mobile Node, MN-FA Authentication extension, 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 SHOULD be
changed by a malicious node when the Registration Request is
forwarded to the HA. If
placed after the HA and Mobile-Home (MN-HA) Authentication extension.
Otherwise, if the GFA have a MN has no established mobility security
association, association
with the GFA IP Address GFA, the HFA extension MUST be protected by placed before the
HA-FA MN-HA
authentication extension. Otherwise

If the Registration Request MN receives an Agent Advertisement with the 'R' bit set, even

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 13] 12]

Internet-Draft Mobile IPv4 Regional Registration November 2004

MUST be sent to the HA in a secure way, for example via 2005

if it has a secure AAA
protocol (see e.g. [I-D.ietf-aaa-diameter-mobileip],
[I-D.ietf-mip4-aaa-key]).

If the Hierarchical Foreign Agent extension comes after the MN-FA
authentication extension, the GFA MUST remove co-located care-of address, it from still formulates the same
Registration Request message. The GFA then message with extensions, but it sends the request
message to the
home agent. Upon receipt advertising FA instead of to the Registration Reply message, GFA.

If the GFA
consults its pending home registration record is about to find expire, the MN performs a new
home registration using the same GFA care-of address
within its domain that is currently used by to refresh the mobile node, and
sends
binding [RFC3344]. If the Registration Reply MN has just moved to that care-of address.

If a new FA and not yet
sent a Regional Registration Request when the Replay extension (see Section 8.3) home registration is present in
due to expire, the MN sends only a home
registration, Registration Request, as this will
update both the GFA and follows the MN-HA authentication HA.

If the Registration Reply includes a Replay Protection Style
extension, the GFA
SHOULD remove value in the Replay extension after performing any necessary
processing, before sending Initial Identification field is the home registration value
to be used for replay protection in the home agent.

If next Regional Registration
Request (see Section 6.1).

5.2. Foreign Agent Considerations

When the GFA FA receives a Registration Request message from a mobile node that MN, it
already has a mobility binding for, this is an update of a binding
that is about to expire. If
extracts the care-of address in field to find the Hierarchical Foreign
Agent extension is GFA to which the same as
message shall be relayed. All FAs that advertise the current 'I' flag MUST
also be able to handle Registration Requests with an all-zeros
care-of address in the
visitor list (used for dynamic GFA assignment).

If the mobile node, the entries in FA receives a Registration Request where the visitor list
concerning regional registrations are not changed, except care-of address
is set to update "all-ones" (which could happen if a MN that doesn't support
Regional Registrations copied an "all-ones" care-of address from an
Agent Advertisement), it MUST reply with the lifetime. Code field set to
"poorly formed request" [RFC3344].

If the address in Registration Request has the Hierarchical Foreign Agent
extension 'T' bit set, the MN is a new address, the values for the regional registration
are updated.

If the Registration request has the 'T' bit set, requesting
Reverse Tunneling [RFC3024]. In this case, the GFA FA has to
decapsulate the tunnel
packets from the foreign agent and re-encapsulate
them for further delivery back MN to the home agent. These actions are
required because the home agent has to receive such packets from GFA for further handling.

If the
expected care-of address (i.e. that of in the GFA) instead of Registration Request is 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 FA, the home agent FA relays the message directly to the HA, as described in
[RFC3344].
If a home agent receives a Registration Request with this extension,
and the home agent does not allow the use of this extension, the For each pending or current home
agent must return a Registration Reply with registration, the Code value set to
ZERO_COA_NOT_SUPP (see Section 8.4). (If a Home Agent that does not
support Regional Registrations receives a Registration Request with FA
maintains a
GFA IP Address extension, the request will be process visitor list entry as described in
[RFC3344].) [RFC3344]. If a home agent receives a Registration Request message
with reverse
tunneling is being used, the care-of address set visitor list MUST, in addition to zero, and a GFA IP Address extension,
it MUST register the IP
fields required in [RFC3344], contain the address of the GFA as GFA.

Otherwise, if the care-of address of
the mobile node in its mobility binding list. If the Registration

Gustafsson, et al. Expires May 23, 2005 [Page 14]

Internet-Draft Mobile IPv4 Regional Registration November 2004 Request is accepted, the home agent MUST include the
address of a GFA IP Address
extension in (or all-zeros), the FA adds a Hierarchical Foreign
Agent (HFA) extension, including its own address, to the Registration Reply, before
Request, and relays it to the GFA. The HFA extension MUST be
appended at the end of all previous extensions that were included in
the Mobile-Home
Authentication extension. If a home agent receives a Registration Request message with when the care-of address set to zero, but no GFA IP
Address extension, FA received it, and it MUST deny the request SHOULD be
protected by sending a Registration
Reply message with the Code field set to ZERO_CAREOF_ADDRESS Foreign-Foreign (FA-FA) Authentication extension (see

Gustafsson, et al. Expires June 2, 2006 [Page 13]

Internet-Draft Mobile IPv4 Regional Registration November 2005

Section 8.4). Otherwise, the 11).

5.3. GFA Considerations

For each pending or current home agent then generates a
Registration Reply message, including registration, the GFA IP Address extension,
and sends it back to the GFA.

5. Regional Registration

This section describes maintains a
visitor list entry as described in detail [RFC3344]. This visitor list
entry is also updated for the regional registration. Once registrations performed by the
home agent has registered
MN. In addition to the GFA address as fields required in [RFC3344], the list entry
MUST contain:

o the current care-of address of the mobile node, the mobile node may perform regional registrations.
When performing regional registrations, MN (i.e., the mobile node may either
register a foreign agent care-of address FA or a co-located address with
address) received in the GFA (or, another RFA - see Appendix A). In HFA extension
o the following, we
assume that a home remaining Lifetime of the regional registration has already occurred, as described in
Section 4, and that
o the GFA has a mobility security association with style of replay protection in use for the mobile node (the MN-FA security association in the home
registrations).

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 regional
registration
o the Agent Advertisement indicates that Identification value for the visited domain
supports regional registrations, and that either the advertised GFA
address registration.

The default replay protection style for regional registrations is the same
timestamp-based replay protection, as defined in Mobile IPv4
[RFC3344]. If the one timestamp sent by the mobile node has registered as its
care-of address during its last home registration, or MN in the realm part Registration
Request is not close enough to the GFA's time of day clock, the newly advertised FA-NAI matches GFA
adds a Replay Protection Style extension (see Section 9.3) to the FA-NAI advertised by
Registration Reply, with the
mobile node's previous foreign agent. Then, GFA's time of day in the mobile node can
perform a regional registration with this foreign agent and GFA. The
mobile node issues a Regional Registration Request message Identification
field to synchronize the MN with the GFA
via for the new foreign agent. The request regional
registrations.

If nonce-based replay protection is authenticated using the
existing mobility security association between used, the GFA and the mobile
node (either using adds a Replay
Protection Style extension to the SA established during Registration Reply, where the home registration,
or using pre-configured keys) and high-
order 32 bits in the message Identification fields is authenticated by the
MN-GFA Authentication Extension (see Section 10). The care-of
address nonce that should
be set to the address of used by the local foreign agent, or
else zero if MN in the local foreign agent is not advertising its own
care-of address. following regional registration.

If the Regional Registration Request does contains a Replay Protection Style
extension (see Section 9.3) requesting a style of replay protection
not contain its care-of
address, supported by the foreign agent adds 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 9.4).

If the Hierarchical Foreign Agent (HFA) extension to comes after the message and relays
MN-FA Authentication extension, the GFA MUST remove it from the
Registration Request. The GFA then sends the Registration Request to
the GFA. Based on HA. Upon receipt of the
information Registration Reply, the GFA consults its
pending registration record to find the care-of address within its
domain that is currently used by the MN, and sends the Registration
Reply to that care-of address.

If the Replay Protection Style extension (see Section 9.3) is present
in a Registration Request, and follows the Hierarchical Foreign Agent MN-HA Authentication
extension, the GFA
updates SHOULD remove the mobile node's current point of attachment in its visitor Replay Protection Style

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 15] 14]

Internet-Draft Mobile IPv4 Regional Registration November 2004

list. The GFA then issues a Regional 2005

extension after performing any necessary processing, before sending
the Registration Reply Request to the
mobile node via the foreign agent. HA.

If the advertised GFA receives a Registration Request from a MN that it already
has a mobility binding for, this is not the same as the one an update of a binding that is
about to expire. If the mobile node has
registered as its care-of address, and if address in the mobile node Hierarchical Foreign Agent
(HFA) extension 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 current care-of address in the foreign agent cannot support
visitor list for the MN, the entries in the visitor list concerning
regional registration registrations are not changed, except to update the
lifetime. If the address in the HFA extension is a GFA, other than advertised, new address, the foreign
agent denies
values for the regional registration with code UNKNOWN_GFA (see
Section 9.3). In this case are updated.

If the MN Registration Request has to do a new home registration
via the new GFA.

It is essential for 'T' bit set, the mobile node GFA has to distinguish regional
registrations
decapsulate the packets from home registrations, since in the former case FA and re-encapsulate them for
further delivery back to the
nonces HA. These actions are not synchronized with its home agent. Furthermore, a home
registration MUST be directed required because
the HA has to receive such packets from the home network before expected care-of address
(i.e. that of the lifetime GFA) instead of the GFA's regional local 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 (that 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 FA).

5.4. Home Agent Considerations

For each pending or current home registration, the mobile node
maintains the information described in [RFC3344].

The information Registration Request is
also updated for the regional registrations performed processed by the mobile
node. In addition to the information HA as described in [RFC3344], the
mobile node MUST maintain
[RFC3344].

6. Regional Registration

This section describes regional registrations. Once the following information, if present:

o HA has
registered the GFA address
o as the style care-of address of replay protection in use for the regional
registration
o the Identification value for MN, the MN
may perform regional registration.

The replay protection for registrations and registrations. When performing regional registrations is
performed
registrations, the MN may either register a FA care-of address or a
co-located address with the GFA. In the following, we assume that a
home registration has already occurred, as described in [RFC3344]. Since the mobile node performs
regional registrations at Section 5,
and that the GFA in parallel has a mobility security association with registrations at
its home network, the mobile node MUST be able to keep MN.

Suppose the MN moves from one replay
protection mechanism and sequence for FA to another FA within the GFA, and a separate
mechanism and sequence for same
visited domain. It will then receive an Agent Advertisement from the home agent.

For
new FA. Suppose further that the Agent Advertisement indicates that
the visited domain supports regional registrations, replay protection may also be provided at and that either
the foreign agent by advertised GFA address is the challenge-response mechanism, same as described
in [RFC3012]. In this case, the mobile node inserts the 64 bit

Gustafsson, et al. Expires May 23, 2005 [Page 16]

Internet-Draft Mobile IPv4 Regional Registration November 2004

response value (timestamp or nonce, according to Mobile IPv4
[RFC3344]) in the Identification field in the Regional Registration
Request. Thus, one the GFA SHOULD expect such an Identification field.
When a mobile node, which MN has already
registered a GFA as its care-of address with during its last home agent, changes foreign agent within the same
domain registration,
or that the realm part of the newly advertised FA-NAI matches the FA-
NAI advertised by the MN's previous FA. Then, the MN can perform a
regional registration with this FA and receives an Agent Advertisement which advertises another
GFA address, it MAY still generate GFA. The MN issues a Regional
Registration Request
message destined to its old GFA.

5.2 Foreign Agent Considerations

When the foreign agent receives a GFA via the new FA. The request is
authenticated using the existing mobility security association
between the GFA and the MN (either using the security association
established during home registration, or using pre-configured keys)

Gustafsson, et al. Expires June 2, 2006 [Page 15]

Internet-Draft Mobile IPv4 Regional Registration Request
message from a mobile node, addressed to a GFA, it processes November 2005

and the message generally according to is authenticated by the rules of processing a Registration
Request message addressed to a home agent MN-GFA Authentication
extension (see Section 4.2). 11). The
only difference is that the GFA IP care-of address field replaces should be set to the home
agent
address field. of the local FA.

If that address belongs to the Regional Registration Request contains a known GFA, care-of address field
of all-zeros, the
foreign agent forwards FA adds a Hierarchical Foreign Agent (HFA)
extension to the request message and relays it to the indicated GFA. Otherwise, Based on the foreign agent MUST generate
information in the HFA extension, the GFA updates the MN's current
point of attachment in its visitor list. The GFA then issues a
Regional Registration Reply with
error code UNKNOWN_GFA.

For each pending or current registration, to the foreign agent maintains
a visitor list entry as described in [RFC3344]. MN via the FA.

If reverse tunneling the advertised GFA is being used, not the visitor list MUST contain same as the address of one the GFA,
in addition to MN has
registered as its care-of address, and if the fields required in [RFC3344]. This MN is required so
that still within the foreign agent can tunnel datagrams, sent by
same domain as it was when it registered that care-of address, the mobile node, MN
MAY try to the perform a regional registration with its registered 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 FA cannot support regional registration, it MUST set
the lifetime registration to be no greater a GFA, other than
advertised, the remaining lifetime of FA denies the
mobile node's registration Regional Registration Request with its home agent, and put code
UNKNOWN_GFA (see Section 10.3). In this lifetime
into case the MN has to do a new
home registration via the new GFA.

New message types are introduced for the corresponding Regional Registration
Request and Reply. The GFA MUST NOT
accept a request motivation for a regional registration if the lifetime of the
mobile node's registration with its home agent has expired. In that
case introducing new message types,
rather than using the GFA sends a Regional Registration Request and Reply with the value defined in
[RFC3344] is: (1) the Code field set MN must be able to NO_HOME_REG.

If the GFA receives a tunneled packet distinguish regional
registrations from a foreign agent home registrations, since in its
domain, then after decapsulation the former case the
timestamps/nonces are synchronized with its GFA looks to see whether it has
an entry and in the latter
with its visitor list for HA; (2) a home registration MUST be directed to the source IP address home
network before the lifetime of the inner
IP header after decapsulation. If so, then it checks GFA care-of address expires; and
(3) the visitor
list MN can use an all-zeros care-of address either to see whether reverse tunneling has been requested; if it was
requested, the request a
dynamically assigned GFA re-encapsulates (in a home registration) or to signify the packet with its own address as
use of an unspecified (perhaps privately addressed) FA (in a regional
registration).

6.1. Mobile Node Considerations

For each pending or current home registration, the source IP address, and MN maintains the
information described in [RFC3344]. The information is also updated
for the regional registrations performed by the MN. In addition to
the information described in [RFC3344], the MN MUST maintain the
following information, if present:

o the GFA address
o the style of replay protection in use for the regional
registration
o the Identification value for the regional registration.

The replay protection for home agent registrations and regional
registrations is performed as described in [RFC3344]. Since the
destination IP address. MN

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 17] 16]

Internet-Draft Mobile IPv4 Regional Registration November 2004

6. Generalized NAI Extension

The revised specification for "IP Mobility Support for IPv4"
[RFC3344] defines a new extension header format, that is intended to
extend 2005

performs regional registrations at the Mobile IP extension address space. The use of a Network
Access Identifier (NAI) [RFC2486] for mobile nodes is specified for
Mobile IPv4 in [RFC2794]. The Generalized NAI (GNAI) extension,
defined GFA in this section, uses parallel with home
registrations at the new extension header format to
extend this idea, enabling NAIs to HA, the MN MUST be used able to keep one replay
protection mechanism and sequence for identifying IPv4
mobility agents (i.e. the Foreign Agent or GFA, and a separate
mechanism and sequence for the Home agent) or other
possible network elements that may be involved with the processing of
Registration Requests. HA.

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 below, regional registrations, replay protection may also be carried by Registration
Request and Reply messages.

The Generalized NAI (GNAI) Extension:

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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
(Type to be assigned provided at
the FA by IANA) (skippable)

Length
8-bit unsigned integer. Length of the extension, challenge-response mechanism, as described 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
[RFC3012]. In this case, the type of MN inserts the entity
which is 64 bit response value
(timestamp or nonce, according to be identified by using the NAI.

NAI
A string containing the Network Access Identifier NAI Mobile IPv4 [RFC3344]) in the
format prescribed
Identification field in [RFC2486].

When a mobile node or home agent adds a GNAI extension to a
registration message, the extension MUST appear prior to any

Gustafsson, et al. Expires May 23, 2005 [Page 18]

Internet-Draft Mobile IPv4 Regional Registration November 2004

authentication extensions.

When Request. Thus, the
GFA SHOULD expect such an Identification field.

6.2. Foreign Agent adds an GNAI extension Considerations

When the FA receives a Regional Registration Request from a MN,
addressed to a registration
message, GFA, it generally processes the extension MUST appear prior message according to any authentication
extensions added by
the FA.

7. Router Discovery Extensions

This section specifies rules of processing a new flag within the Mobile IP Agent
Advertisement, and an optional extension to the ICMP Router Discovery
Protocol [RFC1256].

7.1 Regional Registration Flag Request addressed to a HA (see
Section 5.2). The only change to the Mobility Agent Advertisement Extension defined
in [RFC3344] difference is a flag indicating that the domain, GFA IP address field
replaces the HA address field. If that address belongs to which a known
GFA, the
foreign agent generating FA forwards the Agent Advertisement belongs, supports
regional registrations. The flag is inserted after request to the flags defined
in [RFC3344], [RFC3024] and [route-optim].

Regional registration flag:

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 indicated GFA. Otherwise,
the FA MUST generate a Regional Registration as specified in this document.

7.2 Foreign Agent NAI Extension

The FA-NAI extension is defined as a subtype 4 of Reply with error code
UNKNOWN_GFA.

For each pending or current registration, the Generalized NAI
Extension (GNAIE) (see Section 6).

The foreign agent SHOULD include its NAI FA maintains a visitor
list entry as described in the Agent Advertisement

Gustafsson, et al. Expires May 23, 2005 [Page 19]

Internet-Draft Mobile IPv4 Regional Registration November 2004

message. [RFC3344]. If present, reverse tunneling is being
used, the Foreign Agent NAI (FA-NAI) extension visitor list MUST
appear in contain the Agent Advertisement message after any address of the
advertisement extensions defined GFA, in
addition to the fields required in [RFC3344].

By comparing This is required so
that the domain part of FA can tunnel datagrams, sent by the foreign agent NAI with MN, to the domain
part of its own NAI, GFA. The
GFA then decapsulates the mobile node can determine whether it is in
its home domain or in a visited domain, datagrams, re-encapsulates them and whether it has changed
domain since it last registered.

8. Regional Extensions sends
them to Mobile IPv4 Registration Messages

In this section we specify new Mobile IP registration extensions for the purpose of managing regional registrations.

8.1 HA.

6.3. GFA IP Address Extension Considerations

If the mobile node requests a dynamically assigned GFA, the GFA adds accepts a GFA IP Address extension to the Regional Registration Request before
relaying Request, it to MUST set the HA. The mobile node indicates that it wants a GFA
lifetime of the registration to be assigned by sending a Registration Request message no greater than the remaining
lifetime of the MN's registration with its HA, and put this lifetime
into the
care-of address field set to zero. corresponding Regional Registration Reply. The GFA IP Address extension MUST
appear in the Registration Request message before the Foreign-Home
Authentication extension, if present.

If a home agent receives NOT
accept a Registration Request message with the
care-of address set to zero, and request for a GFA IP Address extension, it MUST
register regional registration if the IP address lifetime of the GFA as the care-of address of
MN's registration with its HA has expired. In that case the
mobile node. When generating GFA
sends a Regional Registration Reply message, the home
agent MUST include the GFA IP Address extension from with the Registration
Request value in the Registration Reply message. The Code field
set to NO_HOME_REG.

If the GFA IP Address
extension MUST appear receives a tunneled packet from a FA in its domain, then
after decapsulation the Registration Reply message before the
Mobile-Home Authentication extension.

The GFA looks to see whether it has an entry in
its visitor list for the source IP Address 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 | GFA address of the inner IP Address ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header
after decapsulation. If so, it checks the visitor list to see
whether reverse tunneling has been requested; if it was requested,
the GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ re-encapsulates the packet with its own address as the source

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 20] 17]

Internet-Draft Mobile IPv4 Regional Registration November 2004

Type
TBD (GFA IP Address)

Length
4

GFA IP Address
The GFA 2005

IP Address field contains address, and the Gateway Foreign Agent's
publicly routable address of the HA as the destination IP address.

8.2 Hierarchical Foreign Agent Extension

The Hierarchical Foreign Agent extension

7. Dynamic GFA Assignment

Regional registrations may be present in also allow dynamic assignment of a
Registration Request or Regional Registration Request message. When
this extension is added GFA to
a Registration Request by a foreign agent, MN. The visited network (i.e. the receiving mobility agent sets up a pending registration record FA) indicates support for the mobile node, using the IP
dynamic GFA assignment by advertising an all-ones care-of address in
the Hierarchical Foreign Agent extension as Advertisement. The MN then sets 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
Registration Request to all-zeros to request a dynamically assigned
GFA. Upon receiving foreign agent receives this Registration Request, the
registration message, FA relays it MUST remove to
the Hierarchical Foreign Agent
extension added by appropriate GFA, and 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 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
TBD (Hierarchical Foreign Agent)

Length
4

Gustafsson, et al. Expires May 23, 2005 [Page 21]

Internet-Draft Mobile IPv4 Regional Registration November 2004

FA IP Address
The GFA assigns its address to the MN by
means of a GFA IP Address of the foreign agent relaying extension added to the Registration
Request.

8.3 Replay Protection Style

When a mobile node uses Mobile

In order for dynamic GFA assignment to work, the MN, GFA and HA
respectively MUST support the GFA IP Address extension. Also, the FA
MUST be able to register a advertise an all-ones care-of address and handle a
Registration Request with
its home agent, the style of replay an all-zeros care-of address.

Note also that protection used for of the
registration messages is assumed GFA IP Address extension, added to be known by way
the Registration Request, requires either the use of a Mobility
Security Association that is required FA-HA
Authentication extension or other means to exist between secure the mobile
node and Registration
Request when forwarded from the home agent receiving GFA to the request. No such pre-existing
security association between HA.

7.1. Mobile Node Considerations for Dynamic GFA Assignment

If the mobile node 'I' flag in the Agent Advertisement sent out by the FA is set,
and the GFA care-of address (or the care-of address indicating the GFA)
is likely set to
be available. By default, the mobile node SHOULD treat replay
protection for Regional Registration messages exactly as specified in
Mobile IPv4 [RFC3344] all-ones, this indicates support for timestamp-based replay protection. dynamic GFA
assignment.

If the mobile node requires nonce-based replay protection, also as
specified in Mobile IPv4, MN determines that it MAY append a Replay Protection extension
to is in a home registration message. Since home registrations are
forwarded to visited domain, if it supports
dynamic GFA assignment, and if the home agent by way of advertised GFA address is all-
ones, the GFA, MN SHOULD set the GFA will be able
to establish care-of address field in the selected replay protection (see Section 4.3).

The Registration
Request to all-zeros to request to be assigned a GFA.

When requesting dynamic GFA also uses this extension by adding assignment, the MN MUST check to make
sure that it receives a Replay Protection Style GFA IP Address extension to in the Registration
Reply.

7.2. Foreign Agent Considerations for Dynamic GFA Assignment

If an FA supports dynamic GFA assignment, and receives a Registration Reply
Request with the care-of address field set to synchronize all-zeros, the replay
protection for Regional registrations (see Section 4.3).

The format of FA
assigns a GFA to the Replay Protection extension is:

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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
TBD (Replay Protection Style) MN. A FA can either have a default GFA that it
assigns to all MNs or it can assign a GFA by some means not described
in this specification.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 22] 18]

Internet-Draft Mobile IPv4 Regional Registration November 2004

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:

+-------+-------------------------+
| Value | Replay Protection Style |
+-------+-------------------------+
| 0 | timestamp [RFC3344] |
| 1 | nonce [RFC3344] |
+-------+-------------------------+

The Replay Protection Style extension MUST be protected by an
authentication extension. 2005

If the mobile node has an established
mobility security association a FA that does not support dynamic GFA assignment receives a
Registration Request 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 care-of address field set to all-zeros,
the foreign agent issuing FA will deny the Agent Advertisement, request as described in [RFC3012].

8.4 New Code Values for [RFC3344], i.e. by
sending a Registration Reply

The values to use within with the Code field of the Registration Reply are
defined in [RFC3344]. In addition, the following values are defined: set to "invalid
care-of address".

7.3. GFA Considerations for Dynamic GFA Assignment

If a GFA supports dynamic GFA assignment, and receives a Registration denied by
Request with the care-of address field set to all-zeros, the GFA
assigns its own IP address as care-of address for this MN, and adds a
a GFA IP Address extension with this address to the FA:

+--------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+--------------------+-------+---------------------+
| SMOOTH_HO_REQUIRED | TBD | Section 4 |
+--------------------+-------+---------------------+

Gustafsson, et al. Expires May 23, 2005 [Page 23]

Internet-Draft Mobile IPv4 Regional Registration November 2004 Registration denied by
Request. The GFA MUST NOT insert the GFA IP address directly in the
care-of address field in the GFA:

The GFA IP Address extension has to be protected so that it cannot be
changed by a malicious node when the HA:

+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| ZERO_CAREOF_ADDRESS | TBD | Section 4.4 |
| ZERO_COA_NOT_SUPP | TBD | Section 4.4 |
+---------------------+-------+---------------------+

9. Regional Registration Message Formats

This section specifies two new registration message types: Regional Registration Request is
forwarded to the HA. If the HA and Regional Registration Reply. These messages
are used the GFA have a mobility security
association, the GFA IP Address extension MUST be protected by the mobile node instead of
FA-HA authentication extension. Otherwise, the existing Registration Request and Registration Reply, in order
MUST be sent 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:

o The Mobile-GFA Authentication extension [RFC3344] MUST be included
in all regional registration messages.
o The Mobile-Foreign Authentication extension [RFC3344] MAY be
included in regional registration messages.
o The Foreign-Home Authentication extension [RFC3344] MUST NOT be
included HA in any regional registration message.

9.1 Regional Registration Request

The Regional Registration Request is used by a mobile node to
register with its current GFA.

Regional Registration Request:

Gustafsson, et al. Expires May 23, 2005 [Page 24]

Internet-Draft Mobile IPv4 Regional Registration November 2004

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 ...
+-+-+-+-+-+-+-+-

The Regional Registration Request message is defined as the
Registration Request message in [RFC3344], but with secure way, for example via a secure AAA
protocol (see e.g. [RFC4004], [RFC3957]).

If 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 [RFC3344].)

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.

9.2 Regional Registration Reply

The Regional Registration Reply message delivers the indication of
regional registration acceptance or denial to a mobile node.

In the Regional Registration Reply message, the UDP header is
followed by the Mobile IP fields shown below:

Gustafsson, et al. Expires May 23, 2005 [Page 25]

Internet-Draft Mobile IPv4 Regional Registration November 2004

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
[RFC3344], 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 [RFC3344]).

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
[RFC3344].

Gustafsson, et al. Expires May 23, 2005 [Page 26]

Internet-Draft Mobile IPv4 Regional Registration November 2004

Registration denied by the FA:

+-----------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+-----------------------+-------+---------------------+
| UNKNOWN_GFA | TBD | Section 5.2 |
| GFA_UNREACHABLE | TBD | |
| GFA_HOST_UNREACHABLE | TBD | |
| GFA_PORT_UNREACHABLE | TBD | |
| SMOOTH_HO_REQUIRED | TBD | Section 4 |
+-----------------------+-------+---------------------+

Registration denied by the GFA:

+--------------+-------+---------------------+
| Error Name | Value | Section of Document |
+--------------+-------+---------------------+
| NO_HOME_REG | TBD | Section 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 [RFC3012] 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 [RFC3344] (e.g. MN-AAA [RFC2794], see
Appendix B) 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 |
+------------------------+-------+

Gustafsson, et al. Expires May 23, 2005 [Page 27]

Internet-Draft Mobile IPv4 Regional Registration November 2004

The default algorithm for computation of the authenticator is the
same as for the MN-AAA Authentication subtype defined in [RFC3012].

11. 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 [RFC3344], [I-D.ietf-aaa-diameter-mobileip]
or [route-optim]. Key distribution is to be performed, for instance,
according to [I-D.ietf-aaa-diameter-mobileip] or
[I-D.ietf-mip4-aaa-key]. Or the keys can be pre-configured.

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.

12. IANA Considerations

This document defines:

o 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).
o 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.
o Three new extensions to Mobile IP Registration messages: GFA IP
Address, Hierarchical Foreign Agent, and Replay Protection Style
(see Section 8.1, Section 8.2 and Section 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.
o New Code values for Registration Reply messages (see Section 8.4).
o Two new subtypes for the Generalized Authentication Extension
[RFC3012]; see Section 10.
o Two new message types for Mobile IP: Regional Registration Request
and Regional Registration Reply (see Section 9.1 and Section 9.2).
o Code values for Regional Registration Reply messages (see Section
9.3).

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

Gustafsson, et al. Expires May 23, 2005 [Page 28]

Internet-Draft Mobile IPv4 Regional Registration November 2004

at the Nokia Research Center for his commentary on a rough version of
this document, and providing motivation for Section 4.

The text in Section 6 was taken directly from a previous Internet
Draft [I-D.ietf-mobileip-gnaie] written by Mohamed M. Khalil, Emad
Qaddoura, Haseeb Akhtar of Nortel Networks, along with Pat R.
Calhoun of Airespace Networks.

14. References

14.1 Normative References

[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.

[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.

[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4
Challenge/Response Extensions", RFC 3012, November 2000.

[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.

[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

14.2 Informative References

[I-D.ietf-aaa-diameter-mobileip]
Calhoun, P., Johansson, T., Perkins, C. and T. Hiller,
"Diameter Mobile IPv4 Application",
draft-ietf-aaa-diameter-mobileip-20 (work in progress),
August 2004.

[I-D.ietf-mobileip-gnaie]
Khalil, M., Qaddoura, E., Akhtar, H. and P. Calhoun,
"Generalized NAI (GNAIE) Extension for Mobile IPv4",
draft-ietf-mobileip-gnaie-05 (work in progress), October
2001.

[I-D.ietf-mip4-aaa-key]

Gustafsson, et al. Expires May 23, 2005 [Page 29]

Internet-Draft Mobile IPv4 Regional Registration November 2004

Perkins, C. and P. Calhoun, "AAA does not support dynamic GFA assignment, it will deny the
request by sending a Registration Keys Reply with the Code field set to
ZERO_COA_NOT_SUPP (see Section 9.4).

7.4. Home Agent Considerations for
Mobile IPv4", draft-ietf-mip4-aaa-key-06 (work in
progress), June 2004.

[route-optim]
Perkins, C. Dynamic GFA Assignment

If a HA receives a Registration Request with a GFA IP Address
extension, and D. Johnson, "Route Optimization in Mobile
IP", September 2001,
<http://www.watersprings.org/pub/id/draft-ietf-mobileip-op
tim-11.txt>.

Authors' Addresses

Eva Gustafsson
Ericsson
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden

EMail: eva.gustafsson@ericsson.com

Annika Jonsson
Ericsson
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden

EMail: annika.jonsson@ericsson.com

Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA

EMail: charles.perkins@nokia.com

Appendix A. Hierarchical Foreign Agents

The main body the HA does not allow the use of this specification assumes two hierarchy levels of
foreign agents in extension, the visited domain. At
HA MUST return a Registration Reply with the top level, there is one
or several GFAs, and on Code value set to
ZERO_COA_NOT_SUPP (see Section 9.4).

If a HA receives a Registration Request message with the lower level, there is care-of
address set to all-zeros, but no GFA IP Address extension, it MUST
deny the request by sending a number of foreign
agents. The structure can Registration Reply message with the
Code field set to ZERO_CAREOF_ADDRESS (see Section 9.4).

If a HA that does not support dynamic GFA assignment receives a
Registration Request with a GFA IP Address extension, the request
will be extended denied by the HA, as described in [RFC3344].

If a HA that supports dynamic GFA assignment receives a Registration
Request with the care-of address set to include multiple hierarchy
levels all-zeros and a GFA IP
Address extension, it MUST register the IP address of foreign agents beneath the GFA level (Figure 5). Such
multiple hierarchy levels are discussed as the
care-of address of the MN in this appendix. its mobility binding list. If the

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 30] 19]

Internet-Draft Mobile IPv4 Regional Registration November 2004

We assume that security associations have been established among a 2005

Registration Request is accepted, the HA MUST include the GFA IP
Address extension in the Registration Reply, before the MN-HA
Authentication extension.

7.5. Regional Registration

If the MN receives an Agent Advertisement with the care-of address
field indicating the GFA set to all-ones, and all if the foreign agents beneath MN determines
that it in is within the hierarchy. As
before, we assume that same visited domain as when a mobile node performs registration at it did its last
home network, registration keys are generated and distributed registration, it MAY send a Regional Registration Request to its
current GFA. Otherwise, it MUST send a Registration Request to its
HA as described in Section 7.1.

8. Router Discovery Extensions

This section specifies a new flag within the mobile node Mobile IP Agent
Advertisement, and an optional extension to the GFA. ICMP Router Discovery
Protocol [RFC1256].

8.1. Regional Registration Flag

The GFA may then only change to the Mobility Agent Advertisement Extension defined
in turn distribute [RFC3344] is a flag indicating that the domain, to which the FA
generating the Agent Advertisement belongs, supports regional
registrations. The flag is inserted after the flags defined in
[RFC3344] and [RFC3024].

Regional Registration flag:

The flag is defined as follows:

Type 16 (Mobility Agent Advertisement)

I Regional Registration. This domain supports regional

Gustafsson, et al. Expires June 2, 2006 [Page 20]

Internet-Draft Mobile IPv4 Regional Registration November 2005

registration keys to the foreign agents beneath it in the
hierarchy, using methods not as specified in this document. We also
assume that all foreign agents and the mobile node support smooth
handover as specified in [route-optim], with some modifications as
explained below.

1 Registration with Home

8.2. Foreign Agent

As described in this specification, a foreign agent announces itself
and NAI Extension

The FA-NAI extension is defined as a GFA subtype TBD of the NAI Carrying
Extension [RFC3846].

The FA SHOULD include its NAI in the Agent Advertisement in the first and last address in message. If
present, the care-of address field Foreign Agent NAI (FA-NAI) extension MUST appear in the Mobility
Agent Advertisement
extension message after any of the advertisement extensions
defined in [RFC3344]. If there

By comparing the domain part of the FA-NAI with the domain part of
its own NAI, the MN can determine whether it is in its home domain or
in a hierarchy visited domain, and whether it has changed domain since it last
registered.

9. Regional Extensions to Mobile IPv4 Registration Messages

In this section we specify new Mobile IP registration extensions for
the purpose of foreign agents
between managing regional registrations.

9.1. GFA IP Address Extension

The GFA IP Address extension is defined for the purpose of supporting
dynamic GFA and assignment. If the announcing foreign agent, MN requests a dynamically assigned
GFA, the GFA adds a GFA IP Address extension to the Registration
Request before relaying it to the HA. The MN indicates that it wants
a GFA to be assigned by sending a Registration Request with the foreign agent
care-of address field set to all-zeros. The GFA IP Address extension
MUST support smooth handover (specifically, the Previous Foreign
Agent Notification extension) as described appear in [route-optim]. The
foreign agent MAY also include the addresses of Registration Request before the foreign agents in FA-HA
Authentication extension, if present.

If a HA receives a Registration Request message with the hierarchy in order between its own care-of
address (first) set to all-zeros, and the a GFA
address (last):

o Address of announcing foreign agent
o IP Address of extension, it MUST
register the next higher-level Regional Foreign Agent (RFA)
o ...
o Address IP address of the GFA

If as the care-of address of the MN.
When generating a foreign agent advertises Registration Reply message, the entire hierarchy between itself and HA MUST include the GFA,
GFA IP Address extension from the Registration Request messages in the
Registration Reply message. The GFA IP Address extension MUST be delivered to each
RFA address appear
in turn within that hierarchy. the Registration Reply message before the MN-HA Authentication
extension.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 31] 21]

Internet-Draft Mobile IPv4 Regional Registration November 2004 2005

The figure below shows a domain with a GFA and multiple hierarchies
of FAs, enabled for regional registrations:

+--------+
| |
| GFA |
| |
+--------+
/ | \
... ... ...
|
+--------+
| |
| RFA3 |
| |
+--------+
/ \
+--------+ +--------+
| | | |
| FA2 | | FA1 |
| | | |
+--------+ +--------+
| |
| +--------+
... | |
| MN |
| |
+--------+

Figure IP Address Extension is defined as follows:

0 1 2 3
0 1 2 3 4 5

When newly arriving at a visited domain, the mobile node sends a
Registration Request, with the care-of address set to the 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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA address
announced in the Agent Advertisement. The mobile node may also
request a IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
TBD (GFA IP Address) (non-skippable)

Length
6

GFA to be assigned, as described earlier in this
specification. IP Address
The registration Request MUST include GFA IP Address field contains the Previous Gateway Foreign Agent's
(GFA) publicly routable address.

9.2. Hierarchical Foreign Agent Notification Extension defined in [route-optim].

The
Binding Update that results is processed as described Hierarchical Foreign Agent (HFA) extension may be present in Section 2. a
Registration Request or Regional Registration Request. When a FA
adds this extension to a Registration Request, the foreign receiving mobility
agent closest to sets up a pending registration record for the mobile node receives MN, using the
Registration Request, processing is as described IP
address in Section 4.2. It
adds a Hierarchical Foreign Agent the HFA extension to as the Registration
Request, including its own address, and relays care-of address for the Registration
Request to MN.
Furthermore, in this case, the next RFA extension MUST be appended at the end
of all previous extensions that had been included in the hierarchy toward registration
message as received by the GFA. It also
constructs a Binding Update and sends FA. The HFA extension SHOULD be protected
by an FA-FA Authentication extension. When the receiving FA receives
the registration message, it to MUST remove the previous foreign
agent, as HFA extension added by
the sending FA.

The Hierarchical Foreign Agent (HFA) Extension is defined in [route-optim]. 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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 32] 22]

Internet-Draft Mobile IPv4 Regional Registration November 2004 2005

Type
TBD (Hierarchical Foreign Agent)

Length
6

FA IP Address
The next RFA receives IP Address of the FA relaying the Registration Request. For each pending or
current registration, an RFA maintains

9.3. Replay Protection Style

When a visitor list entry. In
addition MN uses Mobile IPv4 to the list entry contents (described in [RFC3344]), the
list entry for regional registrations MUST contain:

o the register a care-of address of the next lower-level RFA, or FA, in the hierarchy
o the remaining Lifetime of the regional registration
o with its HA,
the style of replay protection in use used for the regional registration
o 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 [RFC3344]. The list entry messages is also
updated for regional registrations reaching the GFA. In addition
assumed to
the list entry contents required in [RFC3344], the list entry MUST
contain:

o the address of the next lower-level RFA in the hierarchy
o the remaining Lifetime of the regional registration
o the style be known by way of replay protection in use for the regional
registration
o a mobility security association that is
required to exist between the Identification value for MN and the regional registration.

If there is only one level of hierarchy beneath HA receiving the GFA, request.
No such pre-existing security association between the address
of MN and the next lower-level RFA GFA
is likely to be available. By default, the current care-of address of the
mobile node, MN SHOULD treat replay
protection for Regional Registration messages exactly as stated specified in Section 4.3.

The home agent, as described before, processes the Registration
Request, stores
Mobile IPv4 [RFC3344] for timestamp-based replay protection.

If the GFA address MN requires nonce-based replay protection, also as the current care-of address of the
mobile node, generates a Registration Reply, and sends specified
in Mobile IPv4, it MAY append a Replay Protection Style extension to the GFA.
The home agent also distributes
a registration key Registration Request. Since Registration Requests are forwarded to
the mobile
node, perhaps with the assistance of the GFA, for instance HA by way of
other AAA functions [I-D.ietf-mip4-aaa-key]. When the GFA receives GFA, the Registration Reply, it checks its pending Registration Request
record to see which next lower-level RFA GFA will be able to send establish the Registration
Reply message to. It SHOULD then add, for instance,
selected replay protection (see Section 5.3).

The GFA also uses this extension by adding a new FA-FA Key
Reply Replay Protection Style
extension to the a Registration Reply message, before relaying it to synchronize the next foreign agent. replay
protection for Regional Registrations (see Section 5.3).

The new FA-FA Agent Key Reply format of the Replay Protection Style extension is:

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 33] 23]

Internet-Draft Mobile IPv4 Regional Registration November 2004

contains the registration key, encrypted with a secret shared between
the GFA and 2005

Type
TBD (Replay Protection Style)

Length
2

Replay Protection Style
An integer specifying the next lower-level RFA in style of replay protection desired by
the hierarchy. Similar
procedures are MN.

Initial Identification
The timestamp or nonce to be used with [I-D.ietf-mip4-aaa-key].

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 for initial synchronization for
the lowest-level foreign agent receives replay mechanism.

Admissible values for the Registration Reply,
it checks its cached information, Replay Protection Style are as described in [RFC3344], and
relays the Registration Reply to the mobile node.

2 Handling Binding Updates

Meanwhile, when the previous foreign agent receives the Binding
Update, it will process it according to [route-optim], except that
instead of sending back a Binding Acknowledge message, it sends follows:

+-------+-------------------------+
| Value | Replay Protection Style |
+-------+-------------------------+
| 0 | timestamp [RFC3344] |
| 1 | nonce [RFC3344] |
+-------+-------------------------+

The Replay Protection Style extension MUST be protected by an
authentication extension. If the
Binding Update to MN has an established mobility
security association with the next RFA in GFA, the hierarchy towards Replay Protection Style
extension MUST be placed before the GFA.
This is done to make sure that all RFAs MN-FA Authentication extension in
the path to Registration Request, and SHOULD be placed after the previous
FA are notified that MN-HA
Authentication extension. Otherwise, the mobile node has moved. The previous foreign
agent must Replay Protection Style
extension MUST be sure that placed before the next RFA received MN-HA Authentication extension in
the Binding Update,
therefore Registration Request.

If the RFA MUST send GFA adds a Binding Acknowledge message back Replay Protection Style extension to the
foreign agent that a Registration
Reply, it got SHOULD be placed before the Binding Update from. Note that this is MN-FA Authentication extension.
The MN-FA Authentication extension should be based on security
associations between the same Binding Acknowledge message than MN and GFA established during home
registration.

Replay protection MAY also be provided through a challenge-response
mechanism, at the one defined FA issuing the Agent Advertisement, as described in
[route-optim], but this one is addressed
[RFC3012].

9.4. New Code Values for Registration Reply

The values to use within the IP address Code field of the
Foreign Agent that sent the Binding Update instead of to Registration Reply are
defined in [RFC3344]. In addition, the mobile
node.

The RFA that received following values are defined:

Gustafsson, et al. Expires June 2, 2006 [Page 24]

Internet-Draft Mobile IPv4 Regional Registration November 2005

Registration denied by the Binding Update sends GFA:

+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| REPLAY_PROT_UNAVAIL | TBD | Section 5.3 |
| ZERO_COA_NOT_SUPP | TBD | Section 7.3 |
+---------------------+-------+---------------------+

Registration denied by the Binding
Acknowledge HA (for dynamic GFA assignment):

+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| ZERO_CAREOF_ADDRESS | TBD | Section 7.4 |
| ZERO_COA_NOT_SUPP | TBD | Section 7.4 |
+---------------------+-------+---------------------+

10. Regional Registration Message Formats

This section specifies two new registration message back to the lower-layer Foreign Agent, types: Regional
Registration Request and relays Regional Registration Reply. These messages
are used by the Binding Update to MN instead of the next RFA existing Mobile IPv4 Registration
Request and Registration Reply, as described 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 Section 6.

Regional registration messages are protected by required
authentication extensions, in the Binding Update,
but same way as the binding cache entry will still point existing Mobile
IPv4 registration messages are protected. The following rules apply
to the same lower-level
foreign agent. authentication extensions:

o The crossover FA is the foreign agent lowest MN-GFA Authentication extension [RFC3344] MUST be included 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
all regional registration messages.
o The MN-FA Authentication extension [RFC3344] MAY be an RFA or
the GFA, it will, included 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
regional registration messages.
o The FA-HA Authentication extension [RFC3344] MUST NOT be included
in
[route-optim] and it any regional registration message.

10.1. Regional Registration Request

The Regional Registration Request is addressed used by a MN to the mobile node and sent down
the hierarchy via the old path and the previous Foreign Agent, who register with
its current GFA.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 34] 25]

Internet-Draft Mobile IPv4 Regional Registration November 2004

tunnels it to the new Foreign Agent. 2005

Regional Registration Request:

The crossover FA will receive both a Regional Registration Request and a
Binding Update for the mobile node. When the crossover FA receives
the Registration Request, it continues to send traffic via is defined as the old
path until it receives a valid Registration Reply
Request in [RFC3344], but 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 following changes:

Type
TBD (Regional 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 Request)

Lifetime
The number of seconds remaining before the Regional Registration Request, it will know that it
is the
crossover FA, and will send considered expired. A value of zero indicates a Binding Acknowledge message to the
mobile node (via the old route). It also forwards the Registration
Request up to request for
deregistration with the next FA. GFA. A value of 0xffff indicates
infinity.

GFA IP Address
The foreign agents above IP address of the crossover FA Gateway Foreign Agent (GFA). (Replaces Home
Agent field 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 message in the
Binding Update) and will therefor ignore the previous Binding Update
and update the mobility binding according [RFC3344].)

Care-of Address
Care-of address of local FA; MAY be set to all-ones.

Identification
A 64-bit number, constructed by the Registration
Request.

3 MN, used for matching Regional
Registration

A Requests with Regional Registration Request is forwarded to the GFA by way Replies, and for
protecting against replay attacks of one
or more intermediate regional foreign agents. When the registration
messages.

Gustafsson, et al. Expires June 2, 2006 [Page 26]

Internet-Draft Mobile IPv4 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 November 2005

Extensions
For the Regional Registration
Request to. It adds a Request, the Hierarchical Foreign
Agent (HFA) Extension is an allowable extension (in addition to
those which are allowable for the Registration Request).

10.2. Regional Registration Request, including its address, and relays the
message to the next RFA in the hierarchy toward the GFA. Reply

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
address, and relays Regional Registration Reply delivers the message indication of regional
registration acceptance or denial to a MN.

In the next higher-level RFA in the
hierarchy toward Regional Registration Reply, the GFA.

This process UDP header is repeated in each RFA in the hierarchy, until an RFA
recognizes followed by the mobile node as already registered.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-

This RFA may be
the GFA, or any RFA beneath it in the hierarchy. If the mobile node message is already registered with this RFA, the RFA generates a Regional
Registration Reply and sends it to defined as the next lower-level RFA Registration Reply message in
[RFC3344], but with the
hierarchy. The lifetime field in following changes:

Type
TBD (Regional Registration Reply)

Code
A value indicating the result of the Regional Registration Reply is
Request. See [RFC3344] for a list of currently defined Code
values.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 35] 27]

Internet-Draft Mobile IPv4 Regional Registration November 2004

set to the remaining lifetime that was earlier agreed upon between
the mobile node and the GFA. 2005

Lifetime
If the lifetime of Code field indicates that the GFA regional registration
has expired, was
accepted, the Regional Registration Request Lifetime field is relayed all the way set 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 number of seconds
remaining before it receives the
Registration Request, it forwards the Registration Request to the
higher level FA, so that regional registration is considered expired.
A value of zero indicates that FA updates its visitor list according
to the Registration Request, and ignores MN has been deregistered with
the Binding Update. That FA
also forwards GFA. A value of 0xffff indicates infinity. If the Registration Request to any FA or GFA Code field
indicates that it has
sent the corresponding Binding Update to.

If regional registration was denied, the hierarchy between contents
of the advertising foreign agent Lifetime field are unspecified and the MUST be ignored on
reception.

GFA is
announced in IP Address
The IP address of the Gateway Foreign Agent Advertisement, (GFA) generating the mobile node may generate a
Regional Registration Request not destined to the GFA, but to the
closest RFA Reply. (Replaces Home Agent field specified
in Mobile IPv4 [RFC3344]).

Identification
A 64-bit number used for matching Regional Registration Requests
with which it can register.

Replay protection can be provided at Regional Registration Replies, and for protecting against
replay attacks of regional registration messages. The value is
based on the announcing foreign agent,
through Identification field from the challenge-response mechanism described in [RFC3012]. If Regional Registration
Request message from the GFA, MN, and on the RFAs style of replay protection
used in the hierarchy, trust the announcing foreign
agent to perform the replay protection, timestamps or nonces security context between the mobile node MN and its GFA (defined
by the GFA, or mobility security association between them).

10.3. New Regional Registration Reply Code Values

For a Regional Registration Reply, the mobile node and each RFA, following additional Code
values are not needed. If the challenge-response mechanism is used for
replay protection, the mobile node inserts the 64 bit response value defined in the Identification field addition to those specified in Mobile IPv4
[RFC3344].

Registration denied by the FA:

+----------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+----------------------+-------+---------------------+
| UNKNOWN_GFA | TBD | Section 6.2 |
| GFA_UNREACHABLE | TBD | |
| GFA_HOST_UNREACHABLE | TBD | |
| GFA_PORT_UNREACHABLE | TBD | |
+----------------------+-------+---------------------+

Gustafsson, et al. Expires June 2, 2006 [Page 28]

Internet-Draft Mobile IPv4 Regional Registration Request
message. If a mobile node includes a Hierarchical Foreign Agent
extension in its November 2005

Registration Request message, it MAY insert the
extension before denied by the MN-HA or MN-FA authentication extension. In
this case, GFA:

+-------------+-------+---------------------+
| Error Name | Value | Section of Document |
+-------------+-------+---------------------+
| NO_HOME_REG | TBD | Section 6.3 |
+-------------+-------+---------------------+

The four first Code values are returned to the Hierarchical Foreign Agent extension MUST NOT MN in response to ICMP
errors that may be
removed received by the GFA or any other RFA prior to the generation of FA.

11. Authentication Extensions

In this section, two new subtypes for the
Registration Reply message.

If more than one Hierarchical Foreign Agent Generalized Authentication
Extension [RFC3012] are specified. First, the FA-FA Authentication
extension is inserted used by FAs to secure the mobile node into the registration message, the order of the
extensions MUST be maintained through HFA extension to the hierarchy. When sending a
Registration Request and Regional Registration Reply, Request messages. A
new authentication extension is necessary because the GFA MUST ensure that HFA extension
is typically added after the order of MN-HA Authentication extension or, e.g.,
the Hierarchical Foreign Agent extensions MN-AAA Authentication extension [RFC3012].

The MN-GFA Authentication extension is reversed from the order
found in used whenever the MN has a co-
located address. The MN-GFA Authentication extension is also used to
provide authentication for a Regional Registration Request.

4 Regional Registrations and Smooth Handover

Multiple hierarchy levels

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 foreign agents requires the use of
smooth handover from [route-optim], authenticator is the
same as discussed for the MN-AAA Authentication subtype defined in Appendix A. [RFC3012].

12. Security Considerations

This
is not needed in document proposes a two level hierarchy. But method for a mobile node might not
know how many levels of hierarchy MN to register locally in a network has, so if
visited domain. The authentication extensions to be used are those
defined in [RFC3344] [RFC3012]. Key distribution, assumed to take
place during home registration, is to be performed, for instance,
according to [RFC4004] or [RFC3957]. Alternatively, the foreign keys can be
pre-configured.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 36] 29]

Internet-Draft Mobile IPv4 Regional Registration November 2004

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) 2005

If the Hierarchical Foreign Agent MUST deny the request by sending back (HFA) extension is appended to a
Registration Reply message with the Code field set to
SMOOTH_HO_REQUIRED.

The Foreign Agent NAI Request, this 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 followed by adding an FA-NAI FA-FA
Authentication extension
(defined in (see Section 6) 11) to prevent any modification
to the Registration Request (together with the
Previous Foreign Agent Notification extension) and in the Binding
Update data. Security associations between FAs and setting the care-of address to zero.

5 Co-located care of address

If a mobile node uses GFAs within a co-located care-of address, it MAY use
Regional Registrations directly
domain are assumed to exist prior to regional registrations.

If the GFA (see Section 4.1 and
Section 5). It MAY also use the same method IP Address extension is added 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.

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 registration message,
it is to the GFA. The GFA or RFA at each level of the hierarchy
has be followed by a visitor list for the mobile node, showing the address authentication extension. In case of the
next lower-level RFA or FA in the hierarchy. Thus,
GFA IP Address extension being added to a datagram
arriving at Registration Request, it
should be protected by a FA-HA Authentication extension. If no
security association exists between the top level of GFA and the hierarchy, that is, HA, the GFA, will
Registration Request needs to be
re-routed protected by other means not defined
in this document. When a GFA IP Address extension is added to a
Registration Reply, it is protected by the next lower-level RFA Mobile-Home Authentication
extension as defined in the hierarchy. This
re-routing occurs at each level of the hierarchy, until the datagram
reaches the last point which [RFC3344].

Replay protection for regional registrations is either defined similarly to
[RFC3344], with the mobile node itself (in
case addition of a co-located care-of address) or Replay Protection Style extension.
If this extension is added to a foreign agent that can
deliver Registration Reply by a GFA, it needs
to be protected by a MN-FA Authenticaion extension.

13. IANA Considerations

This document defines:

o A subtype for the datagram NAI Carrying Extension [RFC3846]is specified in
Section 8.2, which needs to have a value assigned from the mobile node with no further special space
of NAI Carrying Extension subtypes.
o Three new extensions to Mobile IP handling.

In case of decapsulation Registration messages: GFA IP
Address, Hierarchical Foreign Agent, and re-encapsulation, it should Replay Protection Style
(see Section 9.1, Section 9.2 and Section 9.3). The Type values
for the GFA IP Address extension must be noted
that within the actual decapsulation need not occur at each step of range 0
through 127, while the
hierarchy. Instead, other two must be within the foreign agent at that level can merely
change range 128
through 255.
o New Code values for Registration Reply messages (see Section 9.4).
o Two new subtypes for the source Generalized Authentication Extension
[RFC3012]; see Section 11.
o Two new message types for Mobile IP: Regional Registration Request
and destination IP addresses of the encapsulating
IP header.

Traffic from the mobile node Regional Registration Reply (see Section 10.1 and
Section 10.2).
o Code values for Regional Registration Reply messages (see
Section 10.3).

14. Acknowledgements

This document is sent as described in [RFC3344] or a logical successor to documents written with Pat

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 37] 30]

Internet-Draft Mobile IPv4 Regional Registration November 2004

[RFC3024].

According 2005

Calhoun and Gabriel Montenegro; thanks to the Route Optimization specification [route-optim],
Binding Updates send them and their many efforts
to the correspondent node from the Home Agent
will contain the address of the GFA, since help explore 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 problem space. Many thanks also has the advantage of
reducing the number of Binding Update messages that have to be sent to the correspondent node, at Jari Malinen
for his commentary on a modest increase rough version of this document.

15. References

15.1. Normative References

[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.

[RFC2119] Bradner, S., "Key words for use 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 RFCs to the GFA. Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.

[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.

[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/
Response Extensions", RFC 3012, November 2000.

[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.

[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

[RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for
Carrying Network Access Identifiers", RFC 3846, June 2004.

15.2. Informative References

[RFC3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.

[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.

Appendix B. A. Authentication, Authorization and Accounting (AAA)
Interactions

When the mobile node has to obtain authorization by way of

Gustafsson, et al. Expires June 2, 2006 [Page 31]

Internet-Draft Mobile IPv4 Regional Registration November 2005

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
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 [RFC3012], [I-D.ietf-aaa-diameter-mobileip]). [RFC4004]).

Concretely, this means that:

o The GFA MAY include the Mobile IP Registration Request data inside
an authorization request, directed to a local AAA server.
o The GFA MAY receive the Mobile IP Registration Reply data from a
message granting authorization, received from the AAA
infrastructure.

Appendix C. B. Anchoring at a GFA/RFA/FA GFA

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

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 38] 32]

Internet-Draft Mobile IPv4 Regional Registration November 2004

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. 2005

Authors' Addresses

Eva Gustafsson
Ericsson
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden

Email: eva.gustafsson@ericsson.com

Annika Jonsson
Ericsson
Goetalandsvaegen 230
SE-125 82 Aelvsjoe
Sweden

Email: annika.jonsson@ericsson.com

Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA

Email: charles.perkins@nokia.com

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 39] 33]

Internet-Draft Mobile IPv4 Regional Registration November 2004 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Gustafsson, et al. Expires May 23, 2005 June 2, 2006 [Page 40] 34]

----