INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-proactive-fa-02.txt Tom Hiller
Date: September 2000 Lucent Technologies
James Kempf
Sun Microsystems, Inc.
Peter J. McCann
Lucent Technologies
Chandana Pairla
University of Illinois
Ajoy Singh
Sebastian Thalanany
Motorola
Foreign Agent Assisted Hand-off
Status of this Memo
This document is an individual contribution for consideration by the
Mobile IP Working Group of the Internet Engineering Task Force.
Comments should be submitted to the mobile-
ip@standards.nortelnetworks.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Calhoun et al. expires February 2001 [Page 1]
INTERNET DRAFT September 2000
Copyright (C) The Internet Society 2000. All Rights Reserved.
Abstract
The Mobile IP protocol allows a Mobile Node to continue using the
same home address even after changing its point of attachment to the
Internet. This provides transparency to most existing applications
that assume a fixed address and a fixed point of attachment.
However, new applications, such as voice-over-IP, have additional
real-time requirements such that a change in the point of attachment
will cause a noticeable degradation of service unless additional
steps are taken to reduce the latency of a handoff event.
This specification proposes extensions to the Mobile IP protocol that
may be used by Foreign Agents to set up a Mobile Node's visitor
entry, and forward its packets, prior to receiving a formal
Registration Request from the Mobile Node. This enables a very rapid
establishment of service at the new point of attachment so that the
effect of the handoff on real-time applications is minimized.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Terminology
1.3 Fast handoffs
2.0 Registration Latency
2.1 Gateway Foreign Agents
2.2 Anchor Foreign Agent
3.0 Movement Detection
3.1 Ping-Pong effect
4.0 Reverse Tunneling Support
5.0 Security Relationships
6.0 Power Consumption
7.0 Operation
7.1 Foreign Agent Considerations
7.2 Gateway/Anchor Foreign Agent Considerations
8.0 Binding Update extensions
9.0 Link Layer Address NAI
9.1 CDMA 2000 Link Layer Address Extension
9.2 Ethernet Link Layer Address Extension
10.0 Error Values
11.0 IANA Considerations
12.0 Security Considerations
13.0 References
14.0 Acknowledgements
15.0 Authors' Addresses
Calhoun et al. expires February 2001 [Page 2]
INTERNET DRAFT September 2000
16.0 Full Copyright Statement
Calhoun et al. expires February 2001 [Page 3]
INTERNET DRAFT September 2000
1.0 Introduction
This specification proposes extensions to the Mobile IP protocol that
may be used by Foreign Agents to set up a Mobile Node's visitor
entry, and forward its packets, prior to receiving a formal
Registration Request from the Mobile Node. This enables a very rapid
establishment of service at the new point of attachment so that the
effect of the handoff on real-time applications is minimized. The
proposed extensions make a few minimal assumptions about support
available from the link layer. These assumptions are fairly broad and
abstract. Although they address the kinds of link layer support
available in existing radio link layers, the assumptions are not
based on any specific radio link protocol.
The extensions handle both intra-domain and inter-domain handoff.
While intra-domain handoff MAY make use of pre-configured security
associations between Mobility Agents, inter-domain handoffs MAY make
use of the AAA infrastructure. In the case of inter-technology
handoff, active involvement by the mobile is necessary to switch from
one network interface to another; however, the delivery of the agent
advertisements, indicating the availability of a mobility agent on a
new network interface, is still controlled by network assisted
handoff.
In summary, this draft covers a hand-off scenario not addressed by
RFC 2002: that of a pro-active, network-controlled, anchor-chained
hand-off.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [4].
1.2 Terminology
This document frequently uses the following terms:
AAA
Authentication, accounting and authorization.
Anchor Foreign Agent (AFA)
A foreign agent with publicly routable IP address that acts as
an anchor point when a mobile moves to a new foreign agent.
Upon successful global registration (registration with home
agent) of a mobile node, the anchor foreign agent supports
Calhoun et al. expires February 2001 [Page 4]
INTERNET DRAFT September 2000
local registration when the mobile node changes its point of
attachment to some other neighboring foreign agents.
cdma2000
This is a wide-band radio transmission technology standard,
that uses CDMA(code division multiple access) technology, to
meet the demands of a third-generation wireless communication
system.
Connection ID
A number used to differentiate different link layer connections
originated from the same device.
Dormant mode
Certain wireless technologies support dormancy, which allows
the mobile to go into power saving mode. This typically occurs
when the mobile has been idle for some time, but could be
initiated by the network.
Foreign Agent IP Address Derivation
The derivation of the IP address of a source foreign agent or a
target foreign agent based on the receipt of a link layer
trigger at the target foreign agent or the source foreign agent
respectively.
Gateway Foreign Agent(GFA)
A foreign agent with publicly routable IP address that acts as
a concentration point for other foreign agents within an
administrative domain. Upon successful global registration
(registration with Home agent) of a mobile node, the GFA
supports local registration when the mobile node changes its
point of Attachment to some other foreign agent of the same
administrative Domain.
Home Domain
The domain where the home network [1] and home agent [1] are
located.
International Mobile Subscriber information (IMSI)
A number used for identifying a mobile subscriber station.
Link layer
A link layer specifies a protocol used by communicating nodes
to exchange information over a physical link. A mobile node
attaches itself to a mobile access network, before it can be
served by a foreign agent. A mobile node's link layer address
is the media access control(MAC) address of the mobile node's
network interface.
Calhoun et al. expires February 2001 [Page 5]
INTERNET DRAFT September 2000
Mobility Agent
A foreign agent or a home agent. The foreign agent types
include an anchor foreign agent and a gateway foreign agent.
Mobility Advertisement
An advertisement message constructed by attaching a special
extension to a router advertisement message.
Movement Detection
A detection of a movement in the link layer attachement of the
mobile node to a mobile access network.
Ping-Pong Handoff
The rapid oscillation of a mobile node among coverage area of
two or more foreign agents.
Proactive Foreign agent
A foreign agent that initiates mobile/IP registration on behalf
of a mobile node due to reception of some link layer trigger
event.
Source Trigger
A signal received by the source foreign agent mobile/IP stack,
via the link layer, when the mobile node departs from the
serving area of the source foreign agent.
Target Trigger
A signal received by the target foreign agent mobile/IP stack,
via the link layer, when the mobile node arrives at the serving
area of the target foreign agent.
Trigger
The link layer signal used by wireless link layer to inform
inter foreign agent handoff event to Mobile/IP stack.
Visited Domain
An administrative domain, visited by a Mobile IP client, and
containing the AAA infrastructure needed to carry out the
necessary operations enabling Mobile IP registrations. From
the point of view of the foreign agent, the foreign domain is
the local domain.
1.2 Fast handoffs
MNs connect to FAs via direct, link-layer connections. Because an FA
is directly connected to the link-layer, it may obtain link-layer
information such as power measurements that might indicate the
Calhoun et al. expires February 2001 [Page 6]
INTERNET DRAFT September 2000
necessity of a hand-off to a new FA. The FA can also gain assurance
of the MN's identity through link-layer authentication, and can
authenticate the stream of traffic coming from the MN, including any
power measurements or other indications used for hand-off.
In this document, we will assume that the link-layer events are
signaled to the Foreign Agent as "triggers". The acquisition of a
"trigger" to signal that a hand-off is necessary may be more
difficult when the technologies differ. We assume that any such
triggers will be sufficient to derive the IP addresses of the Foreign
Agents that will receive or send the hand-off. If such a trigger is
not available or if the MN decides on its own that a hand-off is to
take place, then one of the FAs can often still derive the identity
(IP address) of the other from link-layer messages.
In order for the Mobile IP protocol to provide fast hand-off, the
following problems must be addressed:
1. Reducing the latency involved in the registration process.
Although optimization of the Registration process is not
typically considered a Hand-Off problem, this proposal assumes
that such a mechanism is in place.
2. Reducing the latency involved in the Mobile Node's movement
detection process.
3. "Bi-casting" the Mobile Node's traffic to two (or more) points
of attachment, ensuring that the mobile's traffic is delivered
as soon as the link layer hand-off is completed.
4. Support for Reverse Tunneling, which MAY be required for
private addresses.
5. The Security Relationships between the mobility entities for
inter-domain hand-offs.
6. Does not increase mobile power consumption
2.0 Registration Latency
The Mobile IP protocol [1] requires that a Mobile Node registers with
a Foreign Agent, and subsequently its Home Agent, in order to have
its packets delivered to its current point of attachment. The Mobile
IP Regional Registration [6] specification proposes optimized
registration approaches using two different methods:
1. Gateway Foreign Agents (GFA), which are mobility agents that
act as concentration points for Foreign Agents within an
Administrative Domain.
2. Anchor Foreign Agents (AFA), where a previously used Foreign
Agent becomes an anchor point when a mobile moves to a new
Foreign Agent.
Calhoun et al. expires February 2001 [Page 7]
INTERNET DRAFT September 2000
Both GFAs and AFAs allow a Mobile Node's registration message to be
processed by a Mobility Agent in the local domain, eliminating the
need to contact the Home Agent, which MAY be topologically distant.
2.1 Gateway Foreign Agents
The Mobile IP Regional Registration specification introduces the
Gateway Foreign Agent (GFA), as a mobility agent that two Foreign
Agents providing service to a Mobile Node have in common. Figure 1
provides an example of a Mobile's initial registration, through the
GFA. Given this is the first registration message, the message MUST
be forwarded to the Home Agent. All packets destined for the mobile
will be delivered to the GFA, which in turn will forward the packets
to the Foreign Agent servicing the Mobile Node.
Reg Req +-----+ Reg Req
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ Reg Req +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
Figure 1 - Initial Registrations through GFA
In the event that the mobile moves to a new Foreign Agent that is
serviced by a GFA that is common with oFA, the Mobile Node MAY issue
a Regional Registration Request (see Figure 2). The Regional
Registration message does not need to be forwarded to the Home Agent,
since the mobile's traffic can still be delivered to the same GFA.
This optimized approach effectively reduces the latency involved in
the registration process.
Calhoun et al. expires February 2001 [Page 8]
INTERNET DRAFT September 2000
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
Regional Reg +-----+ Regional Reg
Figure 2 - Regional Registration through GFA
2.2 Anchor Foreign Agent
The Mobile IP Regional Registration specification introduces what
this document will call the Anchor Foreign Agent, which is similar to
[7]. The Anchor Foreign Agent operates very similarly to the GFA,
with the exception that the mobile's old Foreign Agent acts as an
anchor point for the Mobile Node.
In order to minimize the latency involved in the registration
process, the Mobile Node MAY issues a Regional Registration message,
setting the old Foreign Agent as the GFA, as shown in Figure 3. Once
completed, the Mobile Node MAY issue an additional RFC 2002 compliant
Registration Messages to eliminate the routing leg through the anchor
Foreign Agent.
+-----+ +----+
| oFA | | HA |
+-----+ +----+
^
+----+ |
| MN | | Regional
+----+ | Reg
| |
| +-----+
+------------>| nFA |
Regional Reg +-----+
Figure 3 - Regional Registrations through an AFA
3.0 Movement Detection
The Mobile IP protocol [1] and the Regional Registration extension
[6] require Mobile Nodes to listen for, or solicit, advertisements in
order to detect that a movement to a new IP subnet has occurred. This
Calhoun et al. expires February 2001 [Page 9]
INTERNET DRAFT September 2000
movement detection mechanism introduces significant latency into the
hand-off process, which causes service degradation, especially for
real-time services. Service is further impacted given the additional
latency introduced through the registration process that follows the
movement detection, since the mobile's traffic can only be delivered
once all of the registration has completed.
There have been many solutions proposed to solve this problem,
including increasing the advertisement frequency. In networks where
radio spectrum is expensive or bandwidth is limited, the additional
signaling required for increasing advertisement frequency is a
serious issue impacting deployability.
+-----+
| GFA |
+-----+
^ |
2b. Regional Reg | | 3b. Regional Reply
| |
| v
+-----+ 1. Binding Update +-----+
| | -----------------> | |
| oFA | 2a. Regional Reg | nFA |
| | <----------------- | |
+-----+ 3a. Regional Reply +-----+
----------------->
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 4 - "source trigger" hand-off using either AFA or GFA
In this document, we propose that the Foreign Agent take a pro-active
approach and issue the Regional Registration message on behalf of the
Mobile Node (acting as a surrogate of sorts). When a Foreign Agent is
aware that a hand-off is occurring at the link-layer, a trigger is
sent to the Mobile IP protocol stack. This trigger could occur either
at old Foreign agent (see Figure 4), or at the new Foreign agent(see
Figure 5). The source trigger can be obtained at the old FA once the
link layer detects that the MN is departing from the old FA coverage
area. The target trigger can be obtained at the new FA once the link
layer detects that the MN is arriving at the new FA coverage area.
Both the source and target trigger may be available before the actual
completion of the link layer handoff.
Calhoun et al. expires February 2001 [Page 10]
INTERNET DRAFT September 2000
+-----+
| GFA |
+-----+
^ |
3b. Regional Reg | | 4b. Regional Reply
| |
1. Binding Request | v
+-----+ <---------------- +-----+
| | 2. Binding Update | |
| oFA | -----------------> | nFA |
| | 3a. Regional Reg | |
+-----+ <----------------- +-----+
4a. Regional Reply
----------------->
+-----+ Movement +-----+
| MN | - - - - - - - - -> | MN |
+-----+ +-----+
Figure 5 - "target trigger" hand-off using either AFA or GFA
Figures 4 & 5 provide an example of network initiated hand-off using
both an Anchor Foreign Agent and a Gateway Foreign Agent. The
messages whose numbers end with 'a' (e.g. 3a) are used with Anchor
Foreign Agents, while the messages with a 'b' are used with Gateway
Foreign Agents. The fact that both the AFA and the GFA are present in
Figures 4 & 5 are purely for illustrative purposes, as a network
would only use one method for a given mobile.
In Figure 4, oFA obtains link-layer information, such as power
measurements, that indicates the necessity of a hand-off to nFA. This
causes a trigger on oFA, which results in the transmission of a
Binding Update to nFA.
In Figure 5, if a GFA is being used, the nFA must issue a Binding
Request to oFA when it receives a trigger that indicates that a
link-layer handoff has occured. This is needed in order to determine
the GFA's address, if one was used. Upon receipt of a Binding
Request, oFA MUST reply with a Binding Update.
In both cases, the receipt of a Binding Update causes a Regional
Registration Request to be sent from nFA to either oFA (which acts as
the anchor FA) or the GFA. The associated Regional Registration Reply
contains the information required by nFA to establish its local
visitor entry.
In the event that the GFA information was provided by the link-layer,
the Binding Request and Update messages do not need to be exchanged
in the "target trigger" case. If this mechanism is used, the need for
Calhoun et al. expires February 2001 [Page 11]
INTERNET DRAFT September 2000
GRE and Reverse Tunneling would also have to be contained within the
link-layer messages. The need for modifying the link-layer messages
to carry such information is out of the scope of this specification.
The end result is that the new Foreign Agent already has a visitor
entry for the Mobile Node prior to the RFC 2002 Registration
procedure. The Mobile Node's packets may be delivered as soon as it
enters nFA's service area, and establishes the necessary air
interface channel.
3.1 Ping-Pong effect
Some link-layers are subject to rapid motion of MNs between two FAs.
For example, even though link-layer power measurements may indicate
that a hand-off is necessary, the mobile may fail to attach to the
new point of attachment, and return almost immediately to its old
point of attachment. This event is known as a "ping-pong" effect.
Data +-----+ Data
+-------------| oFA |<-------------+
| +-----+ |
v |
+----+ +-----+ Data +----+
| MN | | GFA |<--------| HA |
+----+ +-----+ +----+
^ |
| +-----+ |
+-------------| nFA |<-------------+
Data +-----+ Data
Figure 6 - Bi-Casting using a Gateway Foreign Agent
In such situations, it does not benefit the Mobile to issue a
registration in the new service area, and then move back to its old
point of attachment. To avoid problems with ping ponging, this
proposal makes use of the 'S' bit (Simultaneous Binding) in the
Regional Registration message, allowing the user's traffic to be
"Bi-Casted" to two or more Foreign Agents (see Figures 6 & 7).
Calhoun et al. expires February 2001 [Page 12]
INTERNET DRAFT September 2000
Data +-----+ Data +----+
+-------------| oFA |<--------------------------| HA |
| +-----+ +----+
v |
+----+ |
| MN | | Data
+----+ |
^ v
| +-----+
+-------------| nFA |
Data +-----+
Figure 7 - Bi-Casting using an Anchor Foreign Agent
When simultaneous bindings are in effect, and a ping-pong event
occurs, the mobile's service is guaranteed not to experience any
additional latency beyond that imposed by the link-layer handoff. It
is also possible for Foreign Agents to issue Regional Registrations
with the 'S' bit enabled in order to provide for a smooth hand-off
between service areas.
4.0 Reverse Tunneling Support
In the event the Mobile Node requested Reverse Tunneling [12]
support, by setting the 'T' bit in its Registration Request, the
Binding Update (see Section 8.0) from either oFA or the GFA includes
the 'T' bit enabled to inform nFA to establish a bi-directional
tunnel for the visitor entry.
5.0 Security Relationships
The Mobile IP Regional Registration specification [6] requires that
the communicating Mobility Agents exchange authenticated messages.
This imposes a requirement for Mobility Agents to share a pre-
established security association. This assumption is valid for
intra-domain mobility (mobility within an Administrative Domain).
However, such a requirement introduces a scaling problem when the
Mobility Agents are owned by separate Administrative Domains (ADs).
Given that the existing AAA infrastructure is used to establish
dynamic security associations between Foreign and Home Agents in
different ADs, the same infrastructure could be used to establish the
required security association for the purposes of inter-domain hand-
offs (see Figure 8).
Calhoun et al. expires February 2001 [Page 13]
INTERNET DRAFT September 2000
+-----+ +-----+
| AAA |-------------->| AAA |
+-----+ +-----+
^ |
| |
| AAA |
| Hand-Off |
| Req |
| v
+-----+ +-----+
| oFA | | nFA |
+-----+ +-----+
+-----+ Movement +-----+
| MN | - - - - - - > | MN |
+-----+ +-----+
Figure 8 - Inter-FA communication using AAA
Note that it is possible for geographically neighboring Foreign
Agents owned by different Administrative Domains to have a pre-
established security association, which would reduce the latency
introduced by the AAA infrastructure traversal. Given that such
geographically neighboring FAs MAY be small in number, such an
approach MAY be reasonable.
6.0 Power Consumption
An additional benefit that derives from this proposal is the
potential for tracking mobile nodes while in dormant mode, if the
radio link supports it, allowing significant power saving without
adding additional complexity to the network layer protocol in the
wired network. One of the primary innovations proposed here, namely
to allow the Foreign Agents to set up visitor entries prior to the
Mobile Node's registration, is also useful for power saving. Certain
radio link layers allow the mobile node to enter dormant mode when
idle. Allowing the network to control the handoff ensures that the
mobiles do not have to be removed out of dormant mode in order to
establish a Mobile IP handoff.
Limiting power consumption is a requirement for certain wireless
Standards Defining Organizations (SDOs), and a Mobile IP fast handoff
proposal MUST satisfy this requirement.
7.0 Operation
A Foreign Agent can receive two different types of triggers informing
Calhoun et al. expires February 2001 [Page 14]
INTERNET DRAFT September 2000
it of a handoff (The event that causes the trigger may be derived via
link layer messaging assistance from the network or from the mobile):
- a "source trigger" is when the old FA is informed of an
upcoming link-layer handoff,
- a "target trigger" occurs at the new FA when it is informed
that a link layer handoff is in progress.
It is also possible that a particular kind of link layer technology
can support both source and target triggers.
The method by which such triggers occur are link-layer specific, and
are outside the scope of this document.
When the new Foreign Agent receives a "target trigger" event
notification, it SHOULD issue a Binding Request [5] message to the
old Foreign Agent. This is necessary in order to determine whether a
GFA was used.
When the old Foreign Agent receives a "source trigger" event
notification, or a Binding Request, it MUST issue a Binding Update
[5] message to the new Foreign Agent. The Binding Update contains the
Mobile Node's home address, any security association information [8],
as well as the identity of either the Gateway Foreign Agent (GFA) or
the Anchor Foreign Agent (AFA). The Mobile's link-layer address MUST
also be provided within the Binding Update (see Section 9).
The new Foreign Agent MUST issue a Regional Registration Request
message to either the AFA, or the GFA, upon receipt of a Binding
Update message. The Regional registration message MUST include the
mobile's link-layer address, as specified in Section 9. The Regional
Registration message MAY have the 'S' bit enabled, depending upon
local policy (see Section 3.1). The Regional Registration's lifetime
field specifies the proposed GFA or AFA's visitor entry duration.
Should the GFA or AFA not receive a new Regional Registration
message, or a Registration Request message from the Mobile Node prior
to the expiration of the lifetine, it SHOULD expire the visitor entry
tied to the new Foreign Agent.
The Regional Registration Reply message from the AFA or GFA MUST
include the Mobile Node's Home Address, Home Agent Address, any
security associations used with those nodes, visitor entry lifetime,
and the flags that were agreed upon at registration time.
Once the Mobile Node establishes a link layer channel with the new
Foreign Agent, its traffic will be immediately delivered along with a
Mobility Advertisement message [1]. Upon receipt of the Advertisement
message, the Mobile Node MUST issue a Registration Message to update
Calhoun et al. expires February 2001 [Page 15]
INTERNET DRAFT September 2000
its Home Agent's binding table.
Note that the Foreign Agent MAY delay sending the Mobility
Advertisement message, especially to reduce noticeable service
disruption during a ping-pong effect. However, when doing so, it MAY
need to re-issue a new Regional Registration message to either the
AFA or GFA, to extend the visitor entry's lifetime. This procedure
MAY also be used in wireless technologies that support dormant
mobiles, in order to eliminate the need for the mobile to wake up and
perform a Mobile IP registration. In the case of a dormant mobile, or
a mobile outside of the local service area, incoming data destined
for the Mobile Node MAY require the Foreign Agent to cause a
transmission of a link-layer page message.
Given that a Mobile Node's packets will be delivered prior to
registration, a Mobile Node is free to discard all packets received
from Foreign Agents with which it hasn't registered.
If GFAs are used, and a Foreign Agent determines that a Mobile Node
is no longer in its service area, it SHOULD issue a Regional
Registration message with the lifetime set to zero (0), which will
remove the current visitor entry on the GFA. Foreign Agents MAY
decide to not issue this message immediately when a link-layer
trigger is received, in order to support smooth service during a
ping-pong event.
If AFAs are used, a Foreign Agent MUST issue a Regional Registration
message with a zero lifetime to the AFA once a successful
Registration Reply is received from the Mobile Node's Home Agent.
This will effectively change the Mobile Node's anchor point to the
new Foreign Agent.
7.1 Foreign Agent Considerations
Upon receipt of a "target trigger" event, the Foreign Agent MAY issue
a Binding Request [5] message to the Foreign Agent to whom the mobile
is being handed off.
Upon receipt of either a Binding Request or a "source trigger" event,
the Foreign Agent MUST issue a Binding Update message [5] to the
Foreign Agent to which the mobile is being handed off. The Binding
Update's Mobile Node Home Address field MUST be set to the recipient
of the message, while the Care-Of address field MUST be set to the
local address. The Binding Update message MUST include a Link Layer
Address NAI extension (Section 9). If the Foreign Agent made use of a
GFA for the mobile, the GFA IP Address Extension [6] MUST be present.
Calhoun et al. expires February 2001 [Page 16]
INTERNET DRAFT September 2000
Upon receipt of a Binding Update, the Foreign Agent MUST issue a
Regional Registration Request to either the GFA (if the GFA IP
Address Extension was present in the Binding Update), or the sender
of the Binding Update. The Regional Registration Request's Care-Of
address field MUST be set to the local Foreign Agent's address, while
the GFA IP Address MUST be set to the address of the recipient of the
request. The Link-Layer Address NAI (Section 9) extension MUST be
present. The request's lifetime field is set to an administratively
configured value, that is used to inform the recipient of the
expected lifetime for the visitor entry.
The above procedures require Foreign Agents to resolve the handoff
peer's link layer address to an IP address, and this particular
process is outside the scope of this document.
The GFA or AFA MUST reply with a Regional Registration Reply, which
MUST include the Link Layer Address NAI extension (Section 9), as
well as the Mobile Node's home and Home Agent addresses, the
remaining tunnel lifetime, as well as any flags that were set in the
Mobile Node's registration request message. If the code field
indicates a successful registration, the local Foreign Agent MUST
create a visitor entry for the Mobile Node.
In the event that a Foreign Agent handling a particular Mobile Node's
visitor entry is soon to expire, and the Mobile Node has not yet
issued a Registration Request, the FA has the option to transmit a
new Regional Registration message to either the GFA or AFA. Whether
the FA transmits a new Regional Registration is a policy decision up
to the network administrator.
A Foreign Agent MAY receive packets for a Mobile Node to which it
does not have a direct link layer connection. At this point, the
Foreign Agent MAY:
1. Drop all packets for the Mobile Node
2. Buffer packets for the Mobile Node
3. Attempt to establish a link-layer connection with the mobile
4. Issue a Regional Registration Request with a zero lifetime
When a Foreign Agent determines that it is no longer servicing a
Mobile Node, it SHOULD issue a Regional Registration Request message
with the lifetime field set to zero (0). This will cause the
associated visitor entry on the AFA or GFA to be expired.
If a Regional Registration Reply message is received with the code
field set to DO_NOT_SERVICE_MN (Section 10), the Foreign Agent SHOULD
NOT provide service to the Mobile Node. The Foreign Agent MAY enforce
this by closing the Link-Layer connection (if possible), not issuing
any Mobility Advertisements to the Mobile Node (assuming a point-to-
Calhoun et al. expires February 2001 [Page 17]
INTERNET DRAFT September 2000
point Link Layer), or simply denying all Registration Requests with
the error code set to 65 (Administratively Prohibited) [1].
7.2 Gateway/Anchor Foreign Agent Considerations
Upon receipt of a Regional Registration Request, a GFA or AFA MUST
create a visitor entry indicating the Mobile Node's current point of
attachment. In the event that a visitor entry already exists, the GFA
or AFA SHOULD be able to create multiple visitor entries for the same
Mobile Nodes with different Care-Of addresses. If the 'S' bit was
enabled in the Regional Registration Request, the GFA MUST be able to
forward the mobile's packets to all Foreign Agents in the visitor
entries.
When constructing the Regional Registration Reply, the AFA or GFA
SHOULD include the FA-FA authentication extension [6], and set the
lifetime field to the lesser of:
1. number of seconds before the Mobile Node's Registration with
its Home Agent will expire.
2. The lifetime of the locally created Visitor Entry.
In the event that the Regional Registration Request's lifetime field
was set to zero (0), the GFA or AFA MUST remove the visitor entry
associated with the Care-Of address in the message.
Should the GFA or AFA decide that the Foreign Agent is not to
provide service to the Mobile Node, it MUST issue a Regional
Registration Reply message, with the code field set to
DO_NOT_SERVICE_MN (see Section 10).
8.0 Binding Update extensions
This specification has identified a need for Reverse Tunneling to be
communicated in the Binding Update from oFA to nFA (see Figures 4 &
5).
Calhoun et al. expires February 2001 [Page 18]
INTERNET DRAFT September 2000
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 |A|I|M|G|T| Rsvd| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The only change to the Binding Update [5] is the additional 'T'
bit:
T nFA must establish a reverse tunnel for the visitor
entry
9.0 Generalized Link Layer Address Extension
This section defines the Generalized Link Layer Address (LLA)
Extension, used by any that needs to communicate Link Layer
Addresses. The format of the extension follows MIER [13], and each
sub-type of link-layer address defines its own sub-structure. This
draft defines two sub-types, the cdma2000 IMSI and the Ethernet
Address. Future RFCs should allocate their own sub-type and define
their own address formats.
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 | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
The length of the Link Layer Address + the one octet Sub-Type field
Calhoun et al. expires February 2001 [Page 19]
INTERNET DRAFT September 2000
Sub-Type
This field contains the Link Layer sub-type identifier
LLA
Contains the Link Layer Address
In this document, two subtypes are defined:
1 cdma2000 International Mobile Station Identity [14]
2 Ethernet 48 bit MAC address [15]
9.1 cdma2000 Link Layer Address Extension
The cdma2000 Link Layer Address Extension contains the International
Mobile Station Identity, as defined in [14].
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 | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
The length of the IMSI field + the one octet Sub-Type field
Sub-Type
1
IMSI
Contains the IMSI, in the form:
<IMSI>:<Connection Id>
Where the <IMSI> is an ASCII-based representation of the
International Mobile Station Identifier, most significant digit
first, ":" is ASCII 0x3a, and the Connection ID is the ASCII
representation of a small, decimal number used for
distinguishing different link-layer connections from the same
Calhoun et al. expires February 2001 [Page 20]
INTERNET DRAFT September 2000
device.
9.2 Ethernet Link Layer Address Extension
The Ethernet Link Layer Address Extension contains the 48 bit
Ethernet MAC Address, as defined in [15].
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 | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
7 (includes the Sub-Type field)
Sub-Type
2
MAC
Contains the 48 bit Ethernet MAC Address.
10.0 Error Values
The following table contains the name of Code [9] to be returned in a
Registration Reply, the value for the Code, and the section in which
the error is first mentioned in this specification.
Error Name Value Section of Document
---------------------- ----- -------------------
DO_NOT_SERVICE_MN TBD 7.1
11.0 IANA Considerations
The number for the Generalized Link Layer Address Extension is taken
from the numbering space defined for Mobile IP registration
extensions defined in RFC 2002 [1]. These MUST NOT conflict with any
numbers used in RFC 2002[1], RFC 2344 [12], RFC 2356 [16], Mobile IP
Calhoun et al. expires February 2001 [Page 21]
INTERNET DRAFT September 2000
Challenge/Response Extension [17], Mobile IP Network Access
Identifier Extensions Draft[18]. The Code values specified for
errors, listed in section 10, MUST NOT conflict with any other code
values listed in RFC 2002[1], RFC 2344 [12], RFC 2356 [16], Mobile IP
Challenge/Response Extensions[7], or Mobile IP Network Access
Identifier Extensions Draft [18].
The new 'T' flag in the Binding Update message MUST NOT conflict with
any other flags defined in the message in [5].
12.0 Security Considerations
Similar to [6] and [7], this specification assumes that the local
Foreign Agent, and the GFA (or AFA) inherently trust each other. This
MAY be achieved through the use of a long lived security association.
This specification introduces a new change to Mobile IP, which is the
ability for a Mobile Node to receive packets from a Foreign Agent to
which it has not yet registered. In the event that the Mobile Node
does not wish to receive packets from unknown Foreign Agents, it MAY
drop them.
Although this document does not specify how Foreign Agents can
identify, or track, Mobile Nodes, it is assumed that the wireless
link layer be sufficiently secure in order to correctly identify a
Mobile Node. Wireless networks that do not provide such features will
be subjected to impersonation attacks, where malicious nodes could
cause the Foreign Agents to believe that a Mobile Node has moved to
other service areas.
13.0 References
[1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October
1996.
[2] T. Hiller et al. "Cdma2000 Wireless Data Requirements for AAA".
draft-hiller-cdma2000-AAA-00.txt (work in progress). October
1999.
[3] U. Black. "2nd Generation Wireless Networks". Prentice-Hall.
New York. 1999.
[4] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels". BCP 14. RFC 2119. March 1997.
Calhoun et al. expires February 2001 [Page 22]
INTERNET DRAFT September 2000
[5] C. Perkins and D. Johnson. "Route Optimization in Mobile IP".
draft-ietf-mobileip-optim-08.txt (work in progress). February
1999.
[6] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional
Registration", draft-ietf-mobileip-reg-tunnel-02.txt (work in
progress), March 2000.
[7] G. Dommety. "Local and Indirect Registration for Anchoring Hand-
offs", draft-dommety-mobileip-anchor-handoff-00.txt (work in
progress), March 2000.
[8] P. Calhoun, H. Akhtar, E. Qaddoura, N. Asokan, "Foreign Agent
Keys Encoded as Opaque Tokens for use in Hand-off Process",
draft-calhoun-mobileip-fa-tokens-00.txt (work in progress),
March 2000.
[9] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing
Encapsulation (GRE). Request for Comments (Informational) 1701,
Internet Engineering Task Force, October 1994.
[10] C. Perkins. Minimal Encapsulation within IP. Request for Com-
ments (Proposed Standard) 2004, Internet Engineering Task Force,
October 1996.
[11] Mohamed M.Khalil, Emad Qaddoura, Haseeb Akhtar, Pat R. Calhoun,
"Generalized NAI Extension (GNAIE)", draft-ietf-mobileip-gnaie-
00.txt (work in progress), February 2000.
[12] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[13] Khalil, and et. al. Mobile IP Extensions Rationalization (MIER)
draft-ietf-mobileip-mier-00.txt, Dec 1999.
[14] TIA/EIA/IS-95-B
[15] D. Plummer, "An Ethernet Address Resolution Protocol - or - Con-
verting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, Symbolics,
Inc., November 1982.
[16] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[17] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
Extension", RFC 2794, March 2000.
Calhoun et al. expires February 2001 [Page 23]
INTERNET DRAFT September 2000
[18] C. Perkins, P. Calhoun. Mobile IP Challenge/Response Exten-
sions. draft-ietf-mobileip-challenge-13.txt, June 2000.
14.0 Acknowledgements
The authors would like to thank Charles Perkins for his valuable
feedback.
15.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
E-mail: pcalhoun@eng.sun.com
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 979 7673
FAX: +1 630 979 7673
E-Mail: tom.hiller@lucent.com
James Kempf
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 5890
Fax: +1 650 786 6445
E-mail: james.kempf@eng.sun.com
Calhoun et al. expires February 2001 [Page 24]
INTERNET DRAFT September 2000
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 713 9359
FAX: +1 630 713 4982
E-Mail: mccap@lucent.com
Chandana Pairla
University of Illinois - Urbana Champaign
3315, DCL,
1304, W. Springfield Ave.,
Urbana, IL 61801
USA
Phone: +1 217 244 7117
E-mail: pairla@uiuc.edu
Sebastian Thalanany
Motorola
1475 West Shure Drive
Arlington Heights, IL - 60004
USA
Phone: +1 847 435 9296
E-mail: sthalan1@email.mot.com
Ajoy Singh
Motorola
1501 West Shure Drive
Arlington Heights, IL รด 60004
USA
Phone: +1 847 632 6941
E-mail: asingh1@email.mot.com
16.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
Calhoun et al. expires February 2001 [Page 25]
INTERNET DRAFT September 2000
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS 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."
Calhoun et al. expires February 2001 [Page 26]