Internet DRAFT - draft-dommety-mobileip-lma-ipv6
draft-dommety-mobileip-lma-ipv6
INTERNET DRAFT Gopal Dommety, Cisco Systems
Category: Standards Track Madhavi W. Subbarao, Cisco
Systems
Title: draft-dommety-mobileip-lma-ipv6-03.txt Kent Leung, Cisco Systems
Raj Patil, Nokia
July 2001
Expires December 2001
Local Mobility Agents in IPv6
draft-dommety-mobileip-lma-ipv6-03.txt
Status of this Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@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 working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Mobile IPv6 is better integrated into IPv6, thereby obviating the need
for Foreign Agents (FA) in IPv6 [5]. In IPv6 most, if not all, of the
functions of the Mobile IPv4 FA [1] are assumed by other parts of the
Mobile IPv6 architecture. Specifically, all routers send Router
Advertisements and the Mobile Node (MN) does its own detunneling and
Routing Header processing.
This draft proposes the concept of Local Mobility Agents (LMA) in
Mobile IPv6 Architecture. The main advantage is that LMAs facilitate
fast handoffs and provide an inter-network mechanism between IPv6 and
IPv4 networks. Other advantages include aiding in Authentication in
Local Domain, satisfying the need of commercial operators to have a
central/controlling element for mobile users/stations in their
networks through access control, and localizing signalling. LMA is an
optional entity.
1. Introduction
Mobile IPv6 is better integrated into IPv6, thereby obviating the
need for FA in IPv6 [5]. In IPv6 most, if not all, of the
functions of the Mobile IPv4 FA [1] are assumed by other parts of the
Mobile IPv6 architecture. Specifically, all routers send Router
Advertisements and the MN does its own detunneling and Routing Header
processing.
This draft proposes the concept of Local Mobility Agents (LMA) in
Mobile IPv6 Architecture. LMAs are analogous to FAs in Mobile IPv4.
The main advantage is that LMAs facilitate fast handoffs and provide
an inter-network mechanism between IPv6 and IPv4 networks. Other
advantages include Authentication in Local Domain and satisfying the
need of commercial operators to have a central/controlling element
for mobile users/stations in their networks. LMA is an optional entity.
In wide area deployment, the handoff latencies in current Mobile IP
could be high. In a mobile environment, it is important to limit
the delay experienced in communication as a MN moves from one access
point/base station to another. The introduction of LMA into the
Mobile IPv6 Architecture enables fast handoffs. Moreover, the evolution
of the Internet to IPv6 will be gradual. LMAs provide the capability of
establishing either a IPv6 tunnel between the Home Agent (HA) and LMA, or
an IPv4 tunnel to support legacy systems.
1.1 Problem Description
Mobility agents similar to FA in Mobile IPv4 do not exist in Mobile
IPv6. Although there is no need for such agents for the operation of
Mobile IP in IPv6, the introduction of LMAs into the Mobile IPv6
Architecture has several advantages:
A) Fast Handoff: As a MN moves from one subnet to another, the break
in communication perceived by the user must be low. This is
especially important for real-time data services and voice
applications. Having a LMA provides advantages for the following
reasons:
1. It provides the option of using a LMA Care of Address
(CoA). This eliminates at least one round trip time if using DHCPv6
[6] or Autoconfiguration with Duplicate Address Detection (DAD) [11]
to obtain the COA. (It may be possible to perform Stateless
Autoconfiguration without DAD.)
2. It introduces the possibility of managing handoffs locally
by performing quick rerouting. Examples of such mechanisms are Local
Anchoring [14], Regionalized Tunnels [3], and Proactive Handoffs[12].
By using LMA, a MN can send a Binding Update BU to a HA or
Corresponding Node (CN) through encapsulation via the LMA. Thus, the
waiting time incurred by the MN in transmitting sequential bindings is
eliminated. LMAs can be used to create a hierarchy either dynamically
or statically.
NOTE: Fast Handoff in the case where the Link Layer permits
wireless access to more than one access point can be done with
simultaneous bindings. By using hierarchies, LMAs can still reduce
signalling back to the HA, thereby speeding up a handoff.
B) Inter-network mechanism between IPv6 and IPv4: LMAs provide the
option of establishing either an IPv6 tunnel or IPv4 tunnel between
the HA and LMA, depending on the network. This enables the operation
of Mobile IPv6 over the existing Internet, which is predominently IPv4
and will most likely evolve gradually to IPv6.
C) Authentication in the Local Domain. The Mobile has to authenticate
to the Foreign Domain. LMA's aiding in Authentication in Local Domain
and satisfying the need of commercial operators to have a
central/controlling element for mobile users/stations in their
networks through access control.
D) Useful in Creating Static or Dynamic Hierarchies.
2. Solution
2.1 Network Model
The network model being considered is illustrated in Figure 1.
+----------------------------------+ +----------------+
| Visited | | |
| Network | | |
| | | |
| +------+ +-------+ | IPv6 or IPv4 | +------+ |
| | | | | | tunnel to HA | | | |
| | MN |-------------| LMA |-------------------------|HA/CN | |
| | | | |-------------------------| | |
| +------+ +-------+ | | +------+ |
| | | |
| | +----------------+
| +-------+ |
| | LMA | |
| | | |
| | | |
| +-------+ |
+----------------------------------+
Figure 1: Network Model
The above figure shows a new element LMA in the IPv6 mobility
architecture. There are two types of LMAs possible depending on the
palcement of the LMA relative to the mobile.
1. LMA that has Link Layer connectivity to the MN (similar
to FA in Mobile IPv4).
2. LMAs that do not have Link Layer connectivity to the MN
at that instant of time (similar to Anchor FA[14] or GFA[3]).
There are processing differences between the LMA that has Link Layer
connectivity to the MN and the LMA that does not. Using the LMA
framework, static or dynamic hierarchies can be created, and various
handoff schemes can be realized.
The scenarios described below illustrate the working of IPv6 in the
presence of LMAs. The details are provided in
Sections 2.2 and 3.
Option 1: Scnario with out a LMA (Basic Operation of Mobile IPv6):
+----------------------------------+ +----------------+
| Visited | | |
| Network | | |
| | | |
| +------+ | | +------+ |
| | | | | | | |
| | MN |-----------------------------------------------|HA/CN | |
| | | | | | | |
| +------+ | | +------+ |
| | | |
| | +----------------+
+----------------------------------+
Fig 2: Basic Operation of Mobile IPv6 without LMA
In this option, the IP packets destined to the mobiles are routed as
follows:
1. If the CN has a biniding cache for the mobile, source routes the
packets to the MN
2. If the CN does not have a biniding cache, the packets are routed
to the HA and the HA tunnels the packets to MN.
Option 2: Scenario with LMA that has link layer connectivity with the
MN (henceforth this type of LMA is referred to as LC-LMA).
+----------------------------------+ +----------------+
| Visited | | |
| Network | | |
| | | |
| +------+ +-------+ | | +------+ |
| | | | | | | | | |
| | MN |*************| LMA |-------------------------|HA/CN | |
| | | | |-------------------------| | |
| +------+ +-------+ | | +------+ |
| | | |
| | +----------------+
+----------------------------------+
Fig 3: Operation with Link Connected LMA (****** denotes Link Layer
connectivity).
In this configuration, LMA advertises the LMA CoA, which is used by
the MN in its encapsulated Binding Updates (BU) (see Section 2.2.2).
(1) HA tunnels packets for MN to LMA and LMA detunnels and
forwards packets to MN, or
(2) CN source routes the packets to MN via LMA.
LMA can also optionally advertise an IPv4 option if it can support an
IPv4 tunnel. If IPv4 option is present in BU, HA determines whether to
establish IPv6 or IPv4 tunnel to the LC-LMA (depending on HA
capabilities).
Option 3: Scenario with a LC-LMA and an LMA with out direct link layer
connectivity to the mobile.
+----------------------------------+ +----------------+
| Visited | | |
| Network | | |
| | | |
| +------+ +-------+ +-----+ | | +------+ |
| | | | | | | | | | | |
| | MN |****|LC-LMA |---|LMA 1| -----------------------|HA/CN | |
| | | | |---| | -----------------------| | |
| +------+ +-------+ +-----+ | | +------+ |
| | | |
| | +----------------+
+----------------------------------+
Fig 4: Operation with Link Connected LMA and another LMA (hierarchy)
In this scenario, a hierarchy is either a statically or
dynamically established using Local Mobility Agents (Section 4).
LC-LMA maintains visitor mapping of MN home address with LC-LMA CoA.
LMA 1 maintains visitor mapping of MN home address with LMA 1 and
LC-LMA CoA.
(1) When packets for MN arrive at LMA 1 (via either
tunneling from HA or source routed from CN), it verifies that the MN
is visiting on its network, and then tunnels the packets to LC-LMA
CoA.
(2) LC-LMA detunnels and forwards packets to MN.
Depending of the capabilities of the various Agents, whenever
tunelling is performed, IPv6 or IPv4 tunnel is established between
entities.
Option 4: Scenario with LMA that does not have link layer connectivity
with the MN.
+----------------------------------+ +----------------+
| Visited | | |
| Network | | |
| | | |
| +------+ +-------+ | | +------+ |
| | | | | | | | | |
| | MN |-------------| LMA |-------------------------|HA/CN | |
| | |-------------| |-------------------------| | |
| +------+ +-------+ | | +------+ |
| | | |
| | +----------------+
+----------------------------------+
Fig 4: Operation with LMA that is not Link Connected
In this sceanrio, the Mobile is assumed to know the LMA. Possible
methods by which the mobile learns of the LMA are:
A. All routers on the link advertise the LMA CoA
which they learn from LMA advertisements. The MN uses the LMA CoA in
its encapsulated Binding Updates (see Section 2.2.2).
B. An LMA discovery procedure is followed
C. The Mobile has knowledge of the LMA. For example, when performing
anchoring the mobile knows the previous LC-LMA.
Once the appropriate tunnels/binding caches are established. The routing of
packets is as follows:
(1) HA tunnels packets for MN to LMA and LMA Tunnels packets to
Co-located CoA of the MN, or
(2) CN source routes the packets to MN via LMA, and LMA Tunnels
packets to Co-located CoA of the MN.
In both cases, LMA tunnels packets to MN.
2.2 Enhancements
In order to facilitate the above described scenarios, the following
enhancements are proposed:
The neighbor discovery phase is proposed to be enhanced to send the
LMA CoA in the Router Advertisement message.
An enhancement is proposed where a MN can either send a Binding Update
to the HA/CN in a one-phase or two-phase approach. In the one-phase
approach, bindings at the LMA and HA/CN can be updated in a single
transmission by the MN, where the MN sends an encaspulated Binding
Update to the LMA, which is then detunneled and relayed to the HA/CN.
In the two-phase approach, a Binding Update is first sent to the LMA
and once the Binding Update is acknowledged by the LMA, the MN sends a
Binding Update to HA/CN. Two-Phase Binding Update is similar to the
procedure described in [4] and may incur higher latency than the
one-phase approach.
2.2.1 Neighbour Discovery Extension
The LMAs send Router Advertisements with the following new option.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime |C|L| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ LMA CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| More LMA Care of Addresses |
+ +
Fields:
Type Message type. To be assigned.
Length 8-bit unsigned integer. The length in bytes
of the option (including the type and length fields).
Sequence Number
The count of Agent Advertisement messages sent
since the agent was initialized (Similar to
Sequence Number in Mobile IPv4).
Binding Lifetime
Longest lifetime (in seconds) that the LMA is willing
to accept in any Binding Update.
C Bit if not set indicates that the first LMA CoA is
that of LC-LMA, i.e., the mobile can use this CoA
with out acquiring its own CoA.
L Bit indicating whether the LMA can support a
IPv4 tunnel. Bit when set indicates the support to
terminate a IPv4 tunnel.
TBW (To be Worked on) Multiple LMAs on the link.
2.2.2 Binding Update and Binding Update Acknowledgement Usage
In order to create a hierarchy, encapsulated binding updates are sent
as shown in the figure below.
A Binding Update has the format specified in [5] with the addition of a new
bit following the 'Duplicate Address Detection' (D) bit:
L Bit indicating that the MN is requesting a IPv4
tunnel. In order for the MN to set this bit, an LMA
advertisement with the L bit set must have been heard.
A new header extension (TBD) will be used in the Binding Update
Acknowledgement to indicate the preference of the HA. Note: That most
of the time the MN is aware of the HA's capabilities and will request
the appropriate tunnel type.
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
| w/ BU DH | |
+----------------------------------//-----+
<BU between MN and HA/CN with IPv6 headers>
|
v
<Tunnel IPv6 Headers> < Original Packet >
<with BU DH>
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet with Binding Update |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Binding Update with original Binding Update Encapsulated >
BU: Binding Update
DH: Destination Header
Using this tunneling mechanisim a static/dynamic hierarchy can be
created as required [3][14]. (See Section 4.)
Since IP Authentication Headers (AH) are used for authentication in
Mobile IPv6, the Binding Update between the MN and HA/CN is
encapsulated within a Binding Update sent to the LMA. The inner
Binding Update, i.e., BU between MN and HA/CN, contains all of the
necessary extensions [5], including IPv6 headers. It is necessary
to encapsulate the Binding Update between the MN and HA/CN so that
proper authentication will pass at the HA/CN. Note that the LMA cannot
simply create a Binding Update on behalf of the MN since authentication at the
HA/CN would fail.
If a MN is communicating with multiple hosts, only the first
Binding Update needs to be transmitted in this manner. This establishes
the visitor binding at the LMA. The remaining Binding Updates can be
transmitted
directly to the CNs with the LMA CoA as the CoA in the Binding Update.
3 Processing Considerations
3.1 Mobile Node
The MN behaves as a regular Mobile IPv6 node using a CoA. The
variation is that the MN uses a LMA CoA instead of a co-located CoA
and sends its Binding Updates to the HA/CN via a LMA. Note that if
the MN should desire, it may use a co-located CoA and register via the
LMA. In this case, the LMA simply forwards packets destined for the
MN to the co-located CoA. (Although using a LMA CoA reduces latency,
this draft allows for using co-located CoA and sending Binding Update via
LMA. Mobile can also send a Binding Update directly with its
co-located CoA.)
The MN learns of the LMA CoA and IPv4 tunnel options provided by the LMA
either by listening to Router Advertisements or performing Router
Solicitation as specified in [5].
The MN sends a Binding Update to the HA/CN via the LMA as follows.
The MN creates a Binding Update to the HA/CN with CoA set to the LMA CoA,
IPv6 Destination Address set to HA/CN address, and IPv6 Source Address
set to MN home address. The MN will include the necessary extensions
so that the HA/CN can properly authenticate the Binding Update when it
is relayed by the LMA. The MN encapsulates this Binding Update within
another Binding Update destined to the LMA. If the LMA advertises an
IPv4 option, the MN sets the 'L' bit in both Binding Updates if it
desires an IPv4 tunnel.
For hierarchical network configurations (e.g., Option 3 in Section 2.1),
further encapsulation is done as described in Section 4.
The MN receives packets via the LMA with an IPv6 Routing Header set to LMA
CoA and IPv6 Destination Address set to MN address. (If a CN does not
have a binding cache entry, the packet is routed via the MN's home
network and the the IPv6 Destination Address will be the MN's home
address.)
3.2 Local Mobility Agent
3.2.1 LMA with Link Layer connectivity
Signaling Flow:
MN Advertisement LMA HA/CN
|<--------------------- | |
| Binding Update | |
|---------------------->| Binding Update |
| |---------------------->|
| | |
| | |
| | Binding Ack |
| Binding Ack |<----------------------|
|<----------------------| |
The LMA will send periodic Router Advertisements as defined in Section 2.2.1
to facilitate neighbor discovery. If the LMA receives a Router Solication
message, it will respond by sending a LMA Router Advertisement.
As described in Section 2.2.2, the Binding Update to the HA/CN is encapsulated
within a Binding Update sent to the LMA. When the LMA receives a Binding
Update
from a MN, it checks that the
proper authentication is present. If the Binding Update is valid, the LMA
strips off the tunnel headers and forwards the internal Binding Update
packet to the HA/CN. It enters the Binding Update Request in its Pending
Binding Update table.
The Binding Update Acknowledgements are encapsulated: inner Binding
Acknowledgement
has Destination Address = MN home address and Source Address = HA/CN
address. Outer
Binding Acknowledgement has Destination Address = LMA CoA and
Source Address = HA/CN address.
When the MN receives the Binding Update Acknowledgement for the encapsulated
Binding Update, i.e., between MN and HA/CN, the MN can assume that the
Binding Update
to the LMA was also received. (Since the encapsulated Binding Update could
not
have been received by the HA/CN unless the outer Binding Update was received
by the LMA.)
When a LMA receives a packet for the MN, it relays the packet after
adjusting the Routing Header extension and sends it to the MN much
like a FA in Mobile IPv4 Architecture.
3.2.2 LMA with out link Layer connectivity
When LMA receives packets, it tunnels these packets to the registered CoA
in the Binding Update (the registered CoA could be LC-LMA CoA or
co-located CoA). It additionally authenticates the Binding Updates and
sends tunneled Binding Updates/Acknowledgements. This operation is
similar to the operation of a HA in IPv6 (The other alternative is to
change the Routing Header and the Destination Header. One needs to take
caution that the order of headers for IPSec is preserved before
delivering the packet to the MN in this case ).
3.3 Home Agent
Th Home Agent is much like a regular IPv6 HA, except that the HA may choose
between establishing an IPv6 or IPv4 tunnel depending on the request from
the MN
and the HA capabilities. If the 'L' bit is set in the received Binding
Update and
the HA can support an IPv4 tunnel, the HA may set up an IPv4 tunnel between
the
HA and CoA.
3.4 Correspondent Node
The Correspondent node behaves much like a regular IPv6 node. If the CN
receives
a Binding Update with the 'L' bit set and does not understand this option,
the CN simply
ignores the bit and processes the Binding Update as usual, i.e., assumes
the BU is a
regular IPv6 BU and the bit is not set.
4. Creating a Hierarchy using LMAs
With LMAs, either a static hierarchy or dynamic hierarchy (Section
2.1, Option 3, Fig. 4) can be formed using encapsulated Binding
Updates.
4.1 Dynamic Hierarchy
A dynamic hierarchy can be formed using various approaches. Th main idea
is that the
MN remembers the LMA CoA and IPv4 options of the last LMA to which it was
attached. When
the MN determines that it has moved to the domain of another LMA, the MN
registers back
with the 'previous' LMA, creating a dynamic set of tunnels. The tunnel
between the HA and
'previous' LMA is still maintained, and a new tunnel is established between
the 'new' LMA and
'previous' LMA. The LMA sends LMA advertisements as described in Section
2.2.1, with
the inclusion of any necessary extensions for building the dynamic
hierarchy. Similarly,
the MN sends encapsulated Binding Updates in the same manner as described
for Static Hierarchy (Section 4.1), with the inclusion of any necessary
extensions.
The details of the scheme will depend on the specific dynamic
hierarchy scheme being employed.
As an example using Local Anchoring [14], the mobile as it moves to
the new subnet, performs a Binding update through the new LC-LMA to
the old LC-LMA (Anchor LMA) and packets get forwarded through the old
LC-LMA to the new LC-LMA the LMAs will include the necessary
extensions in the LMA advertisements to announce the anchoring
capability. The MN maintains an anchor LMA within a zoned region
(domain), and as it moves within the domain, it registers back with
the anchor LMA. It includes the necessary anchor extensions in its
Binding Updates to the 'new' LMA and anchor LMA, i.e., BU (ii) and
(iii) from Section 4.1. As the MN moves from one zoned region to
another, the existing dynamic hierarchy can be dismantled and a new
dynamic hierarchy can be established.
4.2 Static Hierarchy
In a static hierarchy, the LMA 1 announces its capabilities in its LMA
advertisements. The LC-LMA advertises both LC-LMA CoA and LMA 1 CoA.
Thus, the MN learns of the static hierarchy structure via the LC-LMA
advertisements.
When the MN first enters a foreign domain, the MN sends encapsulated
Binding Updates as follows:
(i) Inner Most Binding Update: LMA 1 CoA to HA/CN.
(ii) Outer-1 Binding Update: LC-LMA CoA to LMA 1
(iii) Outer Most Binding Update: LC-LMA CoA to LC-LMA
As the MN moves from an LC-LMA to a 'new' LC-LMA still within the domain of
LMA 1,
it need only register back with the 'new' LC-LMA. Thus, the signaling all
the way
back to the HA/CN is reduced (the implicit and valid assumption is that the
'previous' LC-LMA and 'new' LC-LMA are in closer proximity).
5. How Existing Handoff Proposals for IPv4 apply to IPv6
To Be Discussed Later
6. How Local Authentication can be performed in IPv6
To Be Discussed Later
7. Synergies and differences between MAP [4] and this draft
The approach described herein does not require the MN to obtain a
co-located CoA (using either DHCP or Autoconfiguration). The MN registers
back with the HA using the LMA CoA, and can use the LMA to create either
a static or dynamic hierarchy. Hence, the latency involved with the MN
acquiring a co-located CoA is avoided. Moreover, by using hiearchies,
the signaling all the way back to the HA each time is avoided.
Since the Binding Update is forwarded to the HA/CN directly by the LMA,
the delay in the MN waiting for a Binding Acknowledgement from the LMA and then
registering back with the HA/CN using the LMA CoA is also avoided.
The reduction in latency will aid in the efficiency of fast handoffs.
6. Security Considerations
Security associations as specified in [5] are used to protect all the
binding update and reply mesages.
7. IANA Considerations
8. Acknowledgments
The authors would like to thank Steve Deering for his suggestions
and helpful discussion.
9. References
[1] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
[2] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[3] E. Gustafsson, et. al. Mobile IP Regional Tunnel Management.
draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
[4] H. Soliman and K. El Malki, Hierarchical Mobile IPv6 and Fast
Handoffs. draft-soliman-mobileip-hmipv6-00.txt, June 2000.
[5] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-10.txt, February 2000.
[6] Jim Bound and Charles Perkins. Dynamic Host Configuration
Protocol for IPv6 (DHCPv6), February 1999. Work in progress.
[7] Alex Conta and Stephen Deering. Generic packet tunneling in
IPv6 specification. RFC 2473, December 1998.
[8] Alex Conta and Stephen Deering. Internet Control Message
Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6)
specification. RFC 2463, December 1998.
[9] Stephen E. Deering and Robert M. Hinden. Internet Protocol
version 6 (IPv6) specification. RFC 2460, December 1998.
[10] Thomas Narten, Erik Nordmark, and William Allen Simpson.
Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December
1998.
[11] Susan Thomson and Thomas Narten. IPv6 stateless address
autoconfiguration. RFC 2462, December 1998.
[12] J. Kempf, P. Calhoun, and C. Pairla, Foreign Agent Assisted Hand-off,
draft-calhoun-mobileip-proactive-fa-01.txt, June 2002
[13] N. Asokhan et. al, AAA for IPv6 Network Access,
draft-perkins-aaav6-00.txt, March 2000.
[14] G. Dommety and T. Ye, "Local and Indirect Registration for
Anchoring Handoffs",
draft-dommety-mobileip-anchor-handoff-01.txt(work in
progress), July 2000.
Dommety [Page 4]
Internet Draft
Authors Information
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: gdommety@cisco.com
Madhavi W. Subbarao
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
e-mail: msubbara@cisco.com
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: kleung@cisco.com
Raj Patil
Nokia
Appendix:
Three options of sending Binding Updates via the LMA.
1. Sequential Bindings (Similar to MAP[4])
MN Advertisement LMA HA/CN
|<--------------------- | |
| Binding Update | |
|---------------------->| |
| Binding Ack | |
|<----------------------| Binding Update |
|---------------------------------------------->|
| Binding Ack |
|<----------------------------------------------|
The drawback in this case is the latency incurred by sequential transmissions.
2. LMA Relays Bindings to HA/CN
MN Advertisement LMA HA/CN
|<--------------------- | |
| Binding Update | |
|---------------------->| Binding Update |
| |---------------------->|
| | |
| | |
| | Binding Ack |
| Binding Ack |<----------------------|
|<----------------------| |
In this case MN sends a Binding Update to LMA, and LMA sends a
Binding Update to HA/CN on behalf of MN. If the Binding Update is
required to be acknowledged, LMA waits for the Binding Update Ack
from the HA/CN and once it receives the Ack, it sends an Ack for the
original Binding Update from the MN. The problem in this case,
however, is that the HA/CN will not be able to authenticate the Binding
Update sent by the LMA on behalf of the MN.
3. Encapsulated Bindings
MN Advertisement LMA HA/CN
|<--------------------- | |
| Binding Update | |
|---------------------->| Binding Update |
| |---------------------->|
| | |
| | |
| | Binding Ack |
| Binding Ack |<----------------------|
|<----------------------| |
In this case MN sends a Binding Update to LMA with the Binding Update for
HA/CN encapsulated. Once the LMA authenticates the MN, the LMA relays the
inner Binding Update to HA/CN. The HA/CN sends a Binding Ack back to the MN
encapsulated within a Binding Ack to the LMA.
