Internet DRAFT - draft-vriz-mipv6-hbhlmap
draft-vriz-mipv6-hbhlmap
Internet Engineering Task Force Vrizlynn L. L. Thing
INTERNET-DRAFT Henry C. J. Lee
Yi Xu
Laboratories for
Information Technology
21 June 2002
Hop-by-Hop Local Mobility Agents Probing
for Mobile IPv6
<draft-vriz-mipv6-hbhlmap-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents, valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document introduces an extension to Mobile IPv6 to provide
support for Localized Mobility Management. This proposed Hop-by-Hop
Local Mobility Agents Probing scheme specifies the Local Mobility
Agents Discovery, Selection and Failure Detection architecture and
procedures for deploying the localized mobility management, whereby
the Local Mobility Agents are distributed. It reduces the amount of
signalling to the home agent and correspondent nodes when mobile
node moves among the subnets of the visited domain.
Thing, Lee, Xu Expires 21 December 2002 [Page i]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 1
3. Overview of Hop-by-Hop Local Mobility Agents Probing 2
3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 2
3.2. New IPv6 Hop-by-Hop Option - LMA Probe . . . . . . . . . 3
3.2.1. LMA Probe Option . . . . . . . . . . . . . . . . 3
3.3. New ICMPv6 Messages . . . . . . . . . . . . . . . . . . . 4
3.3.1. LMA Probe Reply . . . . . . . . . . . . . . . . . 4
3.3.2. LMA Configuration . . . . . . . . . . . . . . . . 5
3.3.3. LMA Configuration Acknowledgement . . . . . . . . 6
3.3.4. LMA Alive Notification . . . . . . . . . . . . . 7
3.4. Modification to Mobile IPv6 Binding Update . . . . . . . 8
4. Local Mobility Agents Discovery 9
5. Local Mobility Agents Selection and Registration 12
6. MN's Movement within Visited Domain 13
7. Failure Detection 13
8. IANA Considerations 14
9. Security Considerations 14
9.1. Binding Updates to Home Agent . . . . . . . . . . . . . . 14
9.2. Binding Updates to Correspondent Nodes . . . . . . . . . 15
9.3. Placement of Global CoA in inner IPv6 packet by MN . . . 15
9.4. Proxy support for MN by LMA . . . . . . . . . . . . . . . 15
10. Acknowledgement 15
11. References 15
12. Authors' addresses 16
Thing, Lee, Xu Expires 21 December 2002 [Page ii]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
1. Introduction
In real-time applications, stringent requirements such as delay and
packet loss are imposed. In order to meet these requirements, Mobile
IPv6 [1] is facing technical challenges in terms of performance and
scalability.
In Mobile IPv6, every inter-domain binding update sent by the mobile
node (MN) to its home agent (HA) and correspondent nodes (CNs) to
inform of its movement to a new Access Router, introduces delay and
potential packet loss due to the large round-trip time (in the order
of 300 to 500 ms). In the case of high handoff rate, binding updates
(BUs) are soon rendered invalid and new ones have to be generated and
sent to the MN's HA and CNs, which results in a higher signalling
overhead.
This document specifies the concept of a Localized Mobility
Management (LMM) [2] scheme using Hop-by-Hop Local Mobility Agents
(LMAs) Probing. It is an extension to Mobile IPv6 to provide support
for regional registration with the LMA Discovery, Selection and
Failure Detection mechanisms. The main objective is to limit the
processing of registration for the MN's movement within the visited
domain locally so as to reduce the network traffic and delay caused
by the re-registrations with the HA and CNs. When the MN moves into
the visited domain, a LMA registers with HA on behalf of the MN. As
MN roams among networks of this domain, only LMA is updated of its
location, thus avoiding all the signalling traffic towards HA and
CNs. By its very nature, it also serves as a mechanism to hide MN's
location from observers outside this domain.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", AND "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. This
document also uses the terminology described in [1] and [2].
Gateway Local Mobility Agent (GLMA)
Domain gateway acting as a Local Mobility Agent
Domain Gateway External Interface (DGEI)
Any interface on Gateway Local Mobility Agents linked to other
external domains
Intermediate Local Mobility Agent
Any router, excluding the Gateway Local Mobility Agents, in a
domain, acting as Local Mobility Agent
Thing, Lee, Xu Expires 21 December 2002 [Page 1]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
Home Domain
Mobile Node's home network domain
Visited Domain
An administrative domain, other than the Home Domain, where Mobile
Node has moved to
Global Care-of Address (GCoA)
Global IP address of the Local Mobility Agent selected by Mobile
Node. This Care-of Address is used for registering with Mobile
Node's Home Agent.
Local Care-of Address (LCoA)
A new IP address acquired by Mobile Node when it connects to a
router in the Visited Domain. This Care-of Address is used for
registering with the selected Local Mobility Agent.
3. Overview of Hop-by-Hop Local Mobility Agents Probing
3.1. Basic Operation
The Hop-by-Hop LMAs Probing LMM scheme introduces an extension to
Mobile IPv6 to reduce the latency due to frequent handoffs between
access routers in the visited domain as lesser time will be used to
update a binding locally, than with a distant HA. In addition, BUs to
all CNs with an existing binding entry for MN would not have to be
re-generated, which would otherwise result in a relatively high
signalling overhead.
For domains, which implement this LMM scheme, domain gateways MUST be
configured to act as LMAs. This is to identify that the boundary of
the domain has been reached so that LMAs in other external domains
will not be mistaken as those in the visited domain. It will also
ensure that at least one LMA is discovered when MN performs probing
along the transmission path to its HA. Routers distributed within the
local mobility domain MAY be configured too for redundancy, which
could take the place of the Gateway LMAs in the case of node or link
failure.
When MN moves into the visited domain initially, it will acquire a
new Care-of Address (CoA) known here as the Local Care-of Address
(LCoA). It will then perform probing to search for all the LMAs along
the transmission path to its HA. The furthest LMA in this visited
domain will be selected as the LMA to be registered with. The
decision to select the furthest LMA is to prevent re-registrations
with HA and CNs when MN performs frequent handoffs within the visited
domain, resulting in a new LMA being selected.
Thing, Lee, Xu Expires 21 December 2002 [Page 2]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
After a LMA is selected, MN will register with it to bind its Home
Address with its Local Care-of Address (LCoA). Therefore, the LMA is
acting as the HA for MN in this visited domain and MUST have the HA
functionalities incorporated. After which, MN will use the global IP
address of this LMA as its Global Care-of Address (GCoA) to register
with its HA and CNs. From then on, packets intended for MN will be
sent to the registered LMA, which will tunnel them to MN's LCoA. In
this way, when MN moves to connect to another Access Router and
acquire a new LCoA (within the visited domain), only the registered
LMA needs to be informed.
The details of the extensions to Mobile IPv6 will be presented later
in this document.
It SHOULD be noted that this LMM scheme by Hop-by-Hop LMAs Probing is
simply an extension to the Mobile IPv6 protocol. When it is
implemented, MN will proceed with registration to the selected LMA,
and then to its HA and CNs if necessary (i.e. on initial movement to
visited domain or when re-registration is REQUIRED when LMA changes).
In the situation whereby this LMM scheme is not implemented, the
standard Mobile IPv6 procedures are carried out.
3.2. New IPv6 Hop-by-Hop Option
Hop-by-Hop LMAs Probing LMM defines a new IPv6 Hop-by-Hop option [4],
the LMA Probe option. This option is used to initiate the LMAs
Discovery process.
3.2.1. LMA Probe Option
This Hop-by-Hop LMA Probe option is used in an ICMPv6 [5] Echo
Request packet sent by MN to its HA, to probe for all LMAs along the
transmission path. This LMA Probe option has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Probe ID | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
32 = 0x20
Option Length
8-bit unsigned integer. Length of the option, in octets, excluding
the Option Type and Option Length fields. This field MUST be set
to 4.
Thing, Lee, Xu Expires 21 December 2002 [Page 3]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
LMA Probe ID
An identifier to aid in matching LMA Probe Replies to this LMA
Probe message.
Counter
Initialized to zero by sending node. Incremented by each LMA in
the visited domain along transmission path till set to
0xFFFF (Boundary Encountered Value) by the Domain Gateway External
Interfaces (DGEIs). It is used to locate Intermediate and Gateway
LMAs within local mobility domain.
3.3. New ICMPv6 Messages
Hop-by-Hop LMAs Probing LMM defines four new ICMPv6 [5] Messages,
namely, LMA Probe Reply, LMA Configuration, LMA Configuration
Acknowledgement and LMA Alive Notification. The first one to cater
for the LMAs Discovery, the other three to handle failure detection.
3.3.1. LMA Probe Reply
This ICMPv6 message is sent by LMAs, which are along the transmission
path from MN to its HA. Through this reply, all the en-route LMAs,
within the visited domain, are discovered. This LMA Probe Reply
message has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Probe ID | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ LMA IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
143 = 0x8F
Code
0
Thing, Lee, Xu Expires 21 December 2002 [Page 4]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
Checksum
The ICMP Checksum [5].
LMA Probe ID
The identifier from the invoking LMA Probe message.
Counter
The Counter value from the invoking LMA Probe message.
Valid Lifetime
The minimum value (in seconds) of the preferred and valid
lifetimes of the prefix assigned to the LMA's subnet. This value
indicates the validity of the LMA's address and consequently the
time for which the GCoA is valid.
LMA IP Address
The LMA's Global Routable Address.
3.3.2. LMA Configuration
This ICMPv6 message is sent by the LMA to MN after registration, to
notify the MN, of the registered LMA's configuration information
related to this LMM scheme. This LMA Configuration message has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Probe ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Alive Notification Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
143 = 0x8F
Code
1
Checksum
The ICMP Checksum [5].
Thing, Lee, Xu Expires 21 December 2002 [Page 5]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
LMA Probe ID
The identifier from the LMA Probe message.
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
LMA Alive Notification Interval
The interval, in seconds, which the registered LMA has to send LMA
Alive Notification messages to the MN to notify that it is still
"alive" and serving as a proxy for the MN.
3.3.3. LMA Configuration Acknowledgement
This ICMPv6 message is sent by MN to the LMA, to notify the LMA of
the receipt of the LMA Configuration message by MN. This LMA
Configuration Acknowledgement message has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Probe ID | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
143 = 0x8F
Code
2
Checksum
The ICMP Checksum [5].
LMA Probe ID
The identifier from the LMA Configuration message.
Status
8-bit unsigned integer indicating the disposition of the LMA
Configuration. The following Status values are currently
defined:
Thing, Lee, Xu Expires 21 December 2002 [Page 6]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
0
LMA Configuration message accepted and information in it stored
in receiving node
128
Incorrect LMA Probe ID
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
3.3.4. LMA Alive Notification
This ICMPv6 message is sent by the registered LMA to the MN for whom
it is serving as a proxy, at intervals of the LMA Alive Notification
Interval value (configured by the LMA Alive Notification
Configuration message). This message is used to inform MN that the
registered LMA is still "alive" and serving as a proxy for the MN.
The LMA Alive Notification message has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMA Probe ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ LMA IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
143 = 0x8F
Code
3
Checksum
The ICMP Checksum [5].
Thing, Lee, Xu Expires 21 December 2002 [Page 7]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
LMA Probe ID
The identifier from the LMA Probe message.
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Valid Lifetime
The minimum value (in seconds) of the preferred and valid
lifetimes of the prefix assigned to the LMA's subnet. This value
indicates the validity of the LMA's address and consequently the
time for which the GCoA is valid. The local binding will be
updated if there's a change from the registered value.
LMA IP Address
The registered LMA's Global Routable Address.
3.4. Modification to Mobile IPv6 Binding Update
Registration with HA or CN is indicated by the 'H' flag. To
differentiate registration with LMA, a new flag is added to the
Binding Update (BU) message in Mobile IPv6. This 'L' flag is used to
indicate LMA registration. When MN registers with an LMA, the 'L'
flag MUST be set. The modified Mobile IPv6 Binding Update has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thing, Lee, Xu Expires 21 December 2002 [Page 8]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
4. Local Mobility Agents Discovery
When MN moves into the visited domain, it will acquire a new Local
Care-of Address (LCoA). It will then proceed to send an ICMPv6 Echo
Request message to its HA. This message will include the LMA Probe
option. The LMA Probe ID is randomly generated and the Counter will
be set to zero by MN.
As this message is transmitted along the route from MN to HA, each
LMA, which received this message, will process the LMA Probe option.
The Counter value is incremented by the LMA and a LMA Probe Reply
message is generated and sent to the soliciting MN. Intermediate
nodes, which do not recognize this LMA Probe option will skip over it
and proceed to process other options. Therefore, configuration is
only REQUIRED on LMAs and MNs. Modification to HAs, CNs and other
nodes not supporting this LMM scheme is not REQUIRED.
When the LMA Probe Option arrives at a Domain Gateway External
Interface (DGEI), the Counter value in the LMA Probe Option will be
set to the Boundary Encountered Value of 0xFFFF by the LMA. This is
to indicate that a boundary is reached. After which, no LMAs SHOULD
reply to this probing if the Counter in the LMA Probe is found to
contain this Boundary Encountered Value. This is to ensure that LMAs
in other domains will not be discovered and mistaken as those in the
visited domain. The following describes four scenarios of LMAs
Discovery. In Figure 1, 2 and 3, DGEIs are indicated by the 'X'
signs.
Scenario 1:
LMM scheme implemented in the visited domain only
Thing, Lee, Xu Expires 21 December 2002 [Page 9]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
+------+
| HA |
+------+
|
+----------------+
| Internet |
+----------------+
|
+---+
|
+---X--+
| LMA1 |
+------+
|
+------+
| R1 |
+------+
|
+------+
| LMA2 |
+------+
|
+------+
| MN |
+------+
Figure 1: Hop-by-Hop LMA Probing LMM Scheme in
the Visited Domain
In Figure 1, as the LMA Probe Option is transmitted along the route
from MN to HA, intermediate nodes configured to serve as LMAs will
trigger the sending of a LMA Probe Reply message to MN. LMA2 will
send a LMA Probe Reply message to MN with a Counter value of 1, and
LMA1 will send a LMA Probe Reply message with a Counter value of 2.
At LMA1's DGEI, the Counter value is set to the Boundary Encountered
Value of 0xFFFF and no other LMA Probe Reply messages will be sent to
MN from that point onwards.
Scenario 2:
LMM Scheme implemented in the visited and external domains (e.g. Home
Domain)
Thing, Lee, Xu Expires 21 December 2002 [Page 10]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
+------+
| HA |
+------+
|
+--------+
| LMA(H) |
+---X----+
|
+------------+
| Internet |
+------------+
|
+--+
|
+---X--+
| LMA1 |
+------+
|
+------+
| LMA2 |
+------+
|
+------+
| MN |
+------+
Figure 2: Hop-by-Hop LMA Probing LMM Scheme in the Visited
and External Domains
In Figure 2, LMA2 will send a LMA Probe Reply message to MN with a
Counter value of 1, and LMA1 will send a LMA Probe Reply message with
a Counter value of 2. At LMA1's DGEI, the Counter value is set to the
Boundary Encountered Value of 0xFFFF. When LMA(H) receives the LMA
Probe Option at its DGEI and sees that the Counter value has already
been set to the Boundary Encountered Value, it will just skip over
this option. Therefore, LMA(H) (including LMAs beyond it) will not
send any LMA Probe Reply message to MN.
Scenario 3:
LMM Scheme not implemented in the visited domain but in the external
domains (e.g. Home Domain)
Thing, Lee, Xu Expires 21 December 2002 [Page 11]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
+------+
| HA |
+------+
|
+--------+
| LMA(H) |
+---X----+
|
+------------+
| Internet |
+------------+
|
+--+
|
+------+
| R1 |
+------+
|
+------+
| MN |
+------+
Figure 3: Hop-by-Hop LMA Probing LMM Scheme in the
External Domain but not the Visited Domain
In Figure 3, the LMA Probe Option will be skipped by intermediate
nodes, not acting as LMAs, and forwarded on to the next node on the
transmission route. It will then arrive at the DGEI of the LMA(H),
which will set the Counter value in the LMA Probe Option to the
Boundary Encountered Value. Therefore, LMA(H) (including LMAs beyond
it) will not send any LMA Probe Reply message to MN.
Scenario 4:
LMM Scheme not implemented in the visited and external domains
In the case that this LMM scheme is not implemented in any of the
domains that the ICMPv6 Echo Request message is sent to, no LMA Probe
Reply will be received by the MN.
5. Local Mobility Agents Selection and Registration
When HA receives the ICMPv6 Echo Request message, it will reply with
an ICMPv6 Echo Reply message. When MN receives the ICMPv6 Echo Reply
message, which correspond to the ICMPv6 Echo Request message (with
the LMA Probe option), from the HA, it would check for any LMA Probe
Reply messages. If no LMA Probe Reply messages are received, the LMM
scheme is not implemented in the visited domain and MN will proceed
to perform the standard Mobile IPv6 registrations. If there are LMA
Probe Reply messages, MN will check their Counter value to locate the
one with the highest value. This will be the Gateway LMA (GLMA), to
be selected for registration. The information of the other LMAs
Thing, Lee, Xu Expires 21 December 2002 [Page 12]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
received in the LMA Probe Reply messages, corresponding to the latest
LMA Probing, is stored in MN for redundancy purpose (will be
discussed further in Section 6: Failure Detection).
To register with the GLMA, MN will send a BU message to this GLMA
with the LCoA in the Source Address field, the 'L' flag set, the GCoA
lifetime in the Lifetime field, and the home address of MN in the
Home Address field. A tunnel [6] will then be set up between the GLMA
and MN, whereby GLMA will tunnel all packets destined to MN's home
address to its new LCoA.
After receiving a Binding Acknowledgement message from the GLMA, MN
will send a BU message to its HA. For the inner packet, it will have
the GCoA in the Source Address field, the HA's address in the
Destination Address field, and the home address of MN in the Home
Address field. For the outer packet, it will have the LCoA in the
Source Address field, and the GCoA in the Destination Address field.
At the GLMA, it will remove the outer packet and forward the inner
packet to the HA. Packets destined to MN's home address will be
intercepted by HA and tunnelled to the GLMA.
If MN has existing bindings with CNs (recorded in the Mobile IPv6
Binding Update List), BU messages to update the bindings will be sent
through this tunnel. In this case, the Destination Address field of
the inner packet will hold the CN's address.
It SHOULD be noted that the lifetime of the binding with
HA and CNs MUST NOT be larger than the MN's binding lifetime with the
GLMA.
6. MN's movement within Visited Domain
When MN moves to connect to a new Access Router within the Visited
Domain, it will obtain a new LCoA. The LMAs Discovery process is
therefore triggered. If the currently registered LMA is the same as
the one selected for registration, a new BU will be sent to this LMA
to update the registration to bind the GCoA to this new LCoA. The HA
and other CNs will not be informed as the GCoA still remains the
same.
If a different LMA is selected, the BU messages will be sent to this
LMA, HA, and CNs (if bindings exists in MN's Mobile IPv6 Binding
Update List) to update the new LCoA and GCoA. The registration
process is described in Section 5.
7. Failure Detection
After sending the Binding Acknowledgement message to MN, the GLMA
will send a LMA Configuration message to MN. This message includes
the LMA Alive Notification Interval, which specifies the intervals
Thing, Lee, Xu Expires 21 December 2002 [Page 13]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
that it will send LMA Alive Notification messages to MN. MN will keep
track of these messages. If one has not been received exceeding the
Maximum Notification Delay (typically three times the Alive
Notification Interval, in seconds), MN will deem that a node or link
failure of the GLMA has occurred.
When a failure is detected, the information of the other LMAs
received in the LMA Probe Reply messages, corresponding to the latest
LMA Probing, which is stored in MN for redundancy purpose will be
scanned. This scanning locates the LMA with the next highest Counter
value (after the previously registered LMA). The LMA registration
process is triggered to register with this LMA. In the case whereby
registration with this LMA could not be completed successfully (e.g.
link failure of the previously registered LMA involves this LMA), the
scanning process is repeated. If the scanning could not result in
locating a potential LMA, the LMA Discovery process will then be
triggered.
8. IANA Considerations
This document defines a new Hop-by-Hop option and four new IPv6 ICMP
messages. They MUST be assigned a protocol number. These new
protocols are described in Section 3.2 and 3.3, and include the
following:
Hop-by-Hop Option Type = 32 for LMA Probe Option
ICMPv6 Type 143 and
ICMPv6 Code = 0 for LMA Probe Reply
ICMPv6 Code = 1 for LMA Configuration Message
ICMPv6 Code = 2 for LMA Configuration Acknowledgement Message
ICMPv6 Code = 3 for LMA Alive Notification Message
These future values can be allocated using standards action [7].
9. Security Considerations
9.1. Binding Updates to Home Agent
BU messages from MN to HA will be protected by authentication. The
inner packet with GCoA in the Source Address field and HA's address
in the Destination Address field will be protected by including the
Authentication Header in IPSec. This authentication is based on the
Security Association between the MN and its HA.
Thing, Lee, Xu Expires 21 December 2002 [Page 14]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
9.2. Binding Updates to Correspondent Nodes
BU messages from MN to CNs are not protected by the IPSec
Authentication Header. However, the related security issues in this
case, is taken care of by the standard Mobile IPv6's Home Test and
Care-of Test.
9.3. Placement of Global CoA in inner IPv6 packet by MN
In the BU messages for HA and CNs, MN is required to place the GCoA
as the Source Address in the inner packet on behalf of the registered
LMA (as the source node to forward this packet). A malicious MN might
send BUs in which the Source Address in the inner packet is set to
the address of a victim node. If such BUs are accepted, packets are
forced to be sent to the victim nodes causing a denial of service
attack.
This could be prevented by implementing a GCoA <-> Home Address
binding cache on the registered LMA. When the registered LMA receives
a BU message for HA or CNs, it will check it's Mobile IPv6 Binding
Cache and GCoA <-> Home Address Binding Cache, that it does have a
binding between the GCoA, LCoA, and Home Address in the packet. It
will then remove the outer packet and forwards the packet on behalf
of the MN. If the checking shows that it does not have the GCoA,
LCoA, and Home Address binding, it will reject (the request to
forward) this packet.
9.4. Proxy support for MN by LMA
The LMA does not have a security association with MN in this case.
However, this design does not introduce additional security issues
existing in IPv6 standard routers.
10. Acknowledgements
The authors would like to thank Dr. Robert H. Deng (Laboratories for
Information Technology) for his valuable analysis and advice on the
security aspects in this document.
11. References
[1] David B. Johnson, Charles Perkins, and Jari Arkko. Mobility
Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-17.txt
(Work in Progress), Internet Engineering Task Force, May 2002.
[2] Carl Williams. Localized Mobility Management Requirements for
IPv6. Internet Draft draft-ietf-mobileip-lmm-requirements-01.txt
(Work in Progress), Internet Engineering Task Force, March 2002.
Thing, Lee, Xu Expires 21 December 2002 [Page 15]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[5] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. Request for Coments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. Request for Comments (Proposed Standard) 2473,
Internet Engineering Task Force, December 1998.
[7] T. Narten and H. Alvestrand. Guidelines for Writing an IANA
Considerations Section in RFCs. Request for Comments (Best
Current Practice) 2434, Internet Engineering Task Force, October
1998.
12. Authors' Addresses
Questions about this document can also be directed to the authors:
Vrizlynn L. L. Thing
Laboratories for Information Technology
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65 6874 6728
Fax: +65 6776 8109
Email: vriz@lit.a-star.edu.sg
Henry C. J. Lee
Laboratories for Information Technology
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65 6874 6668
Fax: +65 6776 8109
Email: hlee@lit.a-star.edu.sg
Thing, Lee, Xu Expires 21 December 2002 [Page 16]
INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002
Yi Xu
Laboratories for Information Technology
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65 6874 8457
Fax: +65 6776 8109
Email: yxu@lit.a-star.edu.sg
Thing, Lee, Xu Expires 21 December 2002 [Page 17]
