Internet DRAFT - draft-huang-nemo-mn-ro
draft-huang-nemo-mn-ro
Network Working Group Andy(Zhigang). Huang
Internet-Draft Huawei Technologies
Expires: April 14, 2007 October 11, 2006
Route Optimization for Mobile Nodes in Mobile Network
draft-huang-nemo-mn-ro-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a mechanism for enabling mobile nodes in IPv6
mobile network to perform route optimization. The route optimization
is possible because mobile router provides a care-of address for
mobile nodes in mobile network which we call Virtual Care-of Address
(VCoA). The VCoA uses the network prefix of the access network.
Mobile nodes register VCoA as its own care-of address with home agent
and correspondent nodes. With little modification to mobile nodes
and correspondent nodes, mobile router deals with the packets
forwarding between them.
Huang Expires April 14, 2007 [Page 1]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Brief Description of Solution . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Messages between VMN and MR . . . . . . . . . . . . . . . 6
4.1.1. Route Optimization Request Message . . . . . . . . . . 6
4.1.2. Route Optimization Acknowledgement Message . . . . . . 7
4.1.3. Binding Refresh Request Message . . . . . . . . . . . 7
4.2. CoTI and CoT Message Format Changes . . . . . . . . . . . 7
5. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 8
5.2. Generating VCoA . . . . . . . . . . . . . . . . . . . . . 8
5.3. Registration Process . . . . . . . . . . . . . . . . . . . 9
5.4. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 10
5.4.1. Data Packet . . . . . . . . . . . . . . . . . . . . . 10
5.4.2. Registration Packet . . . . . . . . . . . . . . . . . 11
5.5. Route Optimization Process . . . . . . . . . . . . . . . . 11
5.6. Impact on Return Routability Process . . . . . . . . . . . 12
5.7. Moving out of Mobile Network . . . . . . . . . . . . . . . 13
5.8. MR Handover . . . . . . . . . . . . . . . . . . . . . . . 13
6. Home Agent and Correspondent Node Operation . . . . . . . . . 14
7. About Nested Mobile Network . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Huang Expires April 14, 2007 [Page 2]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
1. Introduction
Mobile IPv6[RFC3775] allows a mobile node to perform route
optimization with its correspondent node in order to avoid tunneling
with its home agent, however, the "optimized" route is no longer
optimized when the mobile node is attached to a mobile network. The
route between mobile node and correspondent node has to pass through
the bi-directional tunnel between mobile router and its home agent.
The problem is well defined in section 2.4 of 'Network Mobility Route
Optimization Problem
Statement'[draft-ietf-nemo-ro-problem-statement-03].
NEMO Basic Support Protocol[RFC3963] is to preserve session
continuity using the bi-directional tunnel between MR and its HA.
The purpose of this document is to enable MNs behind the MR to
perform Mobile IPv6 Route Optimization. This can reduce the overhead
on MR because MR considers the packets of Local Fixed Nodes in the
bidirectional tunnel between MR and HA.
This document provides a mechanism to enable MN to get and register a
topologically correct care-of address (VCoA) with its HA and CN. By
use of VCoA, MN can get route optimization.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses the terminology and abbreviation conformed to
'Mobility Related Terminology' [RFC3753] and 'Network Mobility
Support Terminology'[draft-ietf-nemo-terminology-04] on the
assumption that the reader is familiar with Mobile IPv6 and NEMO
terminology. In addition, following terms are used:
Virtual Care-of Address (VCoA)
It is one of the addresses that mobile router generates on the egress
interface. Mobile router reserves it for all VMNs which are attached
to mobile network. VMN will regard VCoA as its own care-of address
to register with HA and CN.
Route Optimization Cache
Mobile router stores the binding relationships between VMN's HoA and
VMN_CoA in the Route Optimization Cache. It is mainly used to
forward the packets between mobile nodes and correspondent nodes.
Huang Expires April 14, 2007 [Page 3]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
Route Optimization Request (RO Request)
VMN need send Route Optimization Request message to mobile router to
get VCoA to register with its HA and CN, the message format is same
as Binding Update message defined in RFC3775.
Route Optimization Acknowledgement (RO Ack)
Mobile router sends Route Optimization Acknowledgement message to VMN
to confirm the Route Optimization Request message.
Binding Refresh Request
Mobile router sends Binding Refresh Request message to request VMN to
update its Route Optimization information. Also it can be used to
inform VMN of a new VCoA when handover has taken place on MR.
3. Brief Description of Solution
The case that mobile network node and correspondent node are located
in the same mobile network is not discussed in this document. And
the communications between two mobile network nodes within a nested
mobile network is also out of the scope. This case is depicted in
section 3.2 of 'Network Mobility Route Optimization Solution Space
Analysis' [draft-ietf-nemo-ro-space-analysis-03].
Huang Expires April 14, 2007 [Page 4]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
+--------+ +--------+
| MR_HA | | VMN_HA |
+---+----+ +---+----+
| |
+-----+---------------+---+ +--------+
| Internet |----| CN |
+------------+------------+ +--------+
|
+---+---+
| AR |
+---+---+
| MR_CoA/VCoA
+---+---+
| MR |
+---+---+
|
---------+-------+-----------+-------
| VMN_CoA |
+----+---+ +----+---+
| VMN | | LFN |
+--------+ +--------+
Figure 1 Visited mobile node in mobile network
The scenario discussed in this document is illustrated in Figure 1.
To realize more available route optimization, VMN need get a
topologically correct CoA and register this CoA with HA and CN. When
MR is attached to AR on the foreign link, MR gets its CoA (MR_CoA)
through IPv6 stateless address autoconfiguration[RFC2461] [RFC2462]
or Dynamic Host Configuration Protocol [RFC3315]. VMN MAY register
MR_CoA with its HA and CN to perform route optimization. Then CN can
send the packets to MN using MR_CoA as Destination Address in IPv6
header so that the packets will be routed to MR directly, not passing
through the bi-directional tunnel between MR and its HA.
Since MR_CoA has been registered with its HA by mobile router and
used as the bi-directional tunnel endpoint, to make mobile router can
easily differentiate between the packets from CN directly and the
packets through the bi-directional tunnel between MR and its HA
(mobile router has to process these two kinds of packets in a
different way), it's better that MR can get another address for VMNs
which want to perform real route optimization. Let us call this
address VCoA (Virtual Care-of Address). How MR gets VCoA is detailed
in section 5.2.
When VMN moves to mobile network, first it will generate the care-of
address (let's call it VMN_CoA) and register it with its HA. And it
will register VMN_CoA with CN on the condition that CN supports route
Huang Expires April 14, 2007 [Page 5]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
optimization defined in RFC3775. However, it is not the most
available route optimization because the packets between VMN and CN
have to go through bi-directional tunnel between MR and its HA. If
VMN wants to perform a more available route optimization, it need
register a topologically correct care-of address with its HA and CN.
Here, VCoA is a good choice.
After VMN realize that it has moved into mobile network, how VMN get
to know is out of the scope, it sends a request with VMN_CoA and
VMN's HoA to MR to get the VCoA, and then registers VCoA with HA and
CN through 'multiple care-of addresses registration'
[draft-ietf-monami6-multiplecoa-00] after mobile router responses
with VCoA. Mobile router will store the binding relationships
between VMN's HoA and VMN_CoA in the Route Optimization Cache and
forward the packets from CN to VMN according to the binding
relationships.
The data packets from CN to VMN will be routed to MR because VCoA
actually belongs to MR though VMN registers VCoA with its HA and CN.
MR can easily and clearly know that the packets are destined for VMNs
according to Destination Address (VCoA) in the IPv6 header. Then
mobile router will extract HoA from type 2 routing header and look up
the corresponding binding relationship in the Route Optimization
Cache to get VMN_CoA, and finally encapsulate these packets to
corresponding VMN. The data packets from VMN to CN are encapsulated
by VMN, after mobile router receives the packets, it will de-
encapsulate the packets and send the inner packet to CN directly.
4. Message Formats
This paragraph introduces some messages which are necessary for the
solution. These messages can reuse the message format defined in
RFC3775.
4.1. Messages between VMN and MR
4.1.1. Route Optimization Request Message
The Route Optimization Request message is used by mobile nodes in
mobile network to request VCoA from mobile router, at the same time
mobile nodes register binding relationship between care-of address
and home address. The message has the same format as Binding Update
defined in RFC3775. Just like RFC3775, Home Address option in
Destination Option extension header MUST be included in the message
to provide MR of VMN's HoA.
Huang Expires April 14, 2007 [Page 6]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
4.1.2. Route Optimization Acknowledgement Message
The Route Optimization Acknowledgement message is used by mobile
router to response mobile nodes in mobile network with VCoA. It has
the same format as Binding Acknowledgement message defined in
RFC3775. Alternate Care-of Address option which carries VCoA MUST be
included in the Mobility options.
4.1.3. Binding Refresh Request Message
The Binding Refresh Request message is used by mobile router to
request a VMN to update its binding information. Also it is also
used to inform VMN of new VCoA when handover has taken place on MR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile router binding (M)
The Mobile router binding (M) bit is set by mobile router to indicate
that the message is from MR.
Handover of mobile route (H)
The Handover of mobile route (H) bit is set by mobile router to
indicate that handover has taken place on MR. When H bit is set, M
bit MUST be set. Alternate Care-of Address option which can be used
to carry new VCoA MUST be included in the Mobility options.
4.2. CoTI and CoT Message Format Changes
HoTI/HoT and CoTI/CoT messages are same as RFC3775. However, Home
Address option in Destination Option extension header SHOULD be added
to CoTI message and type 2 routing header SHOULD be added to CoT
messages. The reason is described in detail in Section 5.6.
5. Solution Details
Huang Expires April 14, 2007 [Page 7]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
5.1. Conceptual Data Structures
Mobile router SHOULD maintain a Route Optimization Cache for each VMN
in mobile network which has applied for route optimization. Route
Optimization Cache has two functions: when mobile router forwards the
packets from CN, it will look up the Route Optimization Cache to
encapsulate the packets to VMN; on the other hand, when mobile router
has a handover from one access network to another, it will inform
VMNs which are still in Route Optimization Cache of the new VCoA.
Route Optimization Cache is similar to Binding Cache defined in
RFC3775. Each Route Optimization Cache entry conceptually contains
the following fields:
The home address of VMN: this field is used as the key for searching
the Route Optimization Cache when mobile router forwarding packets to
VMN.
The care-of address of VMN: this field is used as destination address
of a packet forwarded by mobile router to VMN.
A lifetime value: indicating the remaining lifetime for this Route
Optimization Cache entry. The lifetime value is initialized from the
Lifetime field in the Route Optimization Request message that created
or last modified this Route Optimization Cache entry.
The maximum value of the Sequence Number field is same as RFC3775.
5.2. Generating VCoA
MR can get VCoA through stateless address autoconfiguration or
stateful address autoconfiguration. In the stateless address
autoconfiguration, mobile router combines the prefix in the RA from
access router and link interface identifier to generate IPv6 address.
On the MR egress interface, generally there is only one link
interface identifier which has been used to generate MR_CoA. Here,
we need another link interface identifier to generate VCoA. This
link interface identifier MAY come from other interfaces of mobile
router or be created in other ways. In the DHCPv6 method, mobile
router can request two addresses on the egress interface from DHCP
server at the same time. Mobile router will select one of them as
MR_CoA and the other as VCoA by itself. Of course, as RFC2462 points
out, mobile router can generate these two addresses through stateless
address autoconfiguration and stateful address autoconfiguration at
the same time.
Huang Expires April 14, 2007 [Page 8]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
5.3. Registration Process
The whole registration process is elaborated as follows.
When MR leaves home network and attaches to foreign link, MR
generates two addresses (MR_CoA and VCoA) on the egress interface.
MR_CoA is used to register with its HA by MR according to RFC3963.
VCoA is reserved for VMNs which hope to initiate more available route
optimization.
When VMN moves into mobile network, VMN first generates VMN_CoA and
registers it with HA and CN according to RFC3775. Return routability
process will be initiated by VMN before registering VMN_CoA with CN.
To initiate more available route optimization between VMN and CN, VMN
MUST get VCoA to register with HA and CN. VMN first sends the Route
Optimization Request message to MR, asking for permission from MR.
It's possible that MR could not provide all VMNs with the route
optimization function due to limited resource. MR MUST ensure the
basic service before it decides to support route optimization request
from VMN. However, the criterion whether MR will allow the route
optimization for VMN or not is out of the scope.
If MR allows VMN to optimize the traffic path, MR will send Route
Optimization Acknowledgement message to confirm the request and
inform VMN of VCoA. At the same time MR need establish the binding
relationship between VMN's HoA and VMN_CoA and store it in the Route
Optimization Cache. To prevent malicious VMN from attacking other
VMNs by spoofing MR into establishing wrong binding relationship, MR
MUST ensure that HoA and VMN_CoA really belong to VMN. More details
can be found in section 5.5.
After getting VCoA from MR, VMN regards it as its own another care-of
address and considers itself a multi-homing node because it has two
care-of addresses (VMN_CoA and VCoA). VMN generates a BID for each
care-of address and records it into the binding update list, then
registers them by sending a Binding Update with a Binding Unique
Identifier sub-option according to 'Multiple Care-of Addresses
Registration'. This makes HA and CN to support multiple bindings
bound to a single home address. The priority of Binding Cache Entry
which is used to select a binding is notified by the VMN by means of
a Binding Unique Identifier sub-option. VCoA SHOULD have higher
priority than VMN_CoA so that VCoA can be selected in preference to
VMN_CoA and the packets between CN and VMN will not pass through the
bi-directional tunnel between MR and its HA.
Huang Expires April 14, 2007 [Page 9]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
5.4. Packet Forwarding
Provided that the same VCoA is shared as preference choice by all
VMNs in mobile network, all packets from CN or HA to VMNs will
normally sent to MR. MR need distribute these packets to real
destination according to HoA in type 2 routing header. However, HoA
is not the real location but an permanent identifier of VMN. It is
VMN_CoA that can be used to directly route the packet to VMN in the
mobile network, especially when there is intermeidary router between
mobile router and VMN. MR need foward the packets according to the
binding relationships in the Route Optimization Cache.
5.4.1. Data Packet
After successful registration VCoA with higher priority with CN, the
Binding Cache Entry of VCoA and VMN's HoA will be choosed by CN and
the packets between CN and VMN will route along CN-AR-MR-VMN path.
The data packet format from CN to VMN is compatible with RFC3775.
The Source Address in the packet's IPv6 header is set to CN address
and the Destination Address in the packet's IPv6 header is set to
VCoA. Type 2 routing header containing HoA of VMN is included in the
original packet. When MR receives the packets it will extract HoA
from type 2 routing header and look up the corresponding binding
relationship to get VMN_CoA. If the corresponding binding
relationship does not exist, MR will discard the packets sliently.
If the corresponding binding relationship exists, MR will encapsulate
the packets and send them to VMN. The Source Address in the outer
IPv6 header is set to MR address and the Destination Address in the
packet's outer IPv6 header is set to VMN_CoA. The packet format sent
from MR is illustrated as follows.
IPv6 header (source = MR address,
destination = VMN_CoA)
IPv6 header (source = CN address,
destination = VCoA)
Routing header (type 2)
VMN's HoA
Any protocol
Accordingly, the packets from VMN to CN will be encapsulated by VMN.
The inner packet format is compatible with RFC3775 so that CN can
recognize it without any difficulty. The Source Address in the inner
IPv6 header is set to VCoA and the Destination Address in the inner
IPv6 header is set to CN address. Home Address option containing HoA
is included in the inner packet. The outer IPv6 header is used to
route the packet to MR. The Source Address in the outer IPv6 header
is set to VMN_CoA and the Destination Address in the outer IPv6
Huang Expires April 14, 2007 [Page 10]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
header is set to MR address. When MR receives the packets it will
the de-capsulate the packets and send inner IPv6 packets to CN. The
packet format sent from VMN is illustrated as follows.
IPv6 header (source = VMN_CoA,
destination = MR address)
IPv6 header (source = VCoA,
destination = CN address)
Destination Options header
Home Address option (VMN's HoA)
Any protocol
Data packets between HA and VMN are protected by ESP tunnel mode
according to [RFC3776], so it's impossible for MR to get HoA from
inner packet IPv6 header because the inner packet is encrypted.
However, in route optimization mode, data packets between HA and VMN
is unnecessary.
5.4.2. Registration Packet
Registration packets between VMN and HA or CN include Binding Update
message, Binding Acknowledgement message, Binding Error message and
Binding Update Refresh message. HoTI/HoT and CoTI/CoT message
exchanges will be separately discussed in the following section 5.6.
Registration packets between CN and VMN are similar to the data
packets between them. HoA contained in type 2 routing header and
Home Address option in Destination Option extension header is used as
identifier of VMN from the perspective of upper layer protocol.
Registration packets between HA and VMN are protected by ESP
transport mode according to RFC3776, especially, type 2 routing
header and Destination Option extension header appear before ESP
according to [RFC4303]. That is, HoA in these headers will not be
encrypted by ESP, MR can verify and forward the registration packets
as it deals with data traffic between CN and VMN.
5.5. Route Optimization Process
Before VMN initiates route optimization request to register HoA and
VMN_CoA with MR, the same return routability process as RFC3775
SHOULD be used to provide the security. To prevent malicious VMN
from attacking other VMNs by tricking MR into establishing the wrong
binding relationship, MR MUST be able to ensure that HoA and VMN_CoA
really belongs to VMN which sends the Route Optimization Request.
Referring to RFC3775, it seems as if MR acts as CN's role which VMN
means to register with. Figure 2 depicts the message exchange
process. VMN first sends HoTI and CoTI messages to MR and receives
Huang Expires April 14, 2007 [Page 11]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
HoT and CoT messages from MR respectively. VMN gets the home keygen
token from HoT message and the care-of keygen token from CoT message.
Based on these two tokens VMN will compute binding management key Kbm
which is used to generate the Binding Authorization Data mobility
option in Route Optimization Request message.
VMN VMN's HA MR
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
Figure 2 Return routability process between VMN and MR
Route Optimization Request/Acknowledgement messages are similar to
Binding Update/ Acknowledgement defined in RFC3775. The message
exchange is illustrated in figure 3. VMN sends Route Optimization
Request message to MR, MR MUST re-generate the home keygen token and
the care-of keygen token from the information contained in the
packet. It then generates the binding management key Kbm and uses it
to verify the authenticator field in the Route Optimization Request.
Then MR sends Route Optimization Acknowledgement message to confirm
the request and inform VMN of VCoA.
VMN MR
| |
| Route Optimization Request |
|----------------------------->|
| |
| Route Optimization Acknowledg|ement
|<-----------------------------|
| |
Figure 3 Route Optimization Request/Acknowledgement
5.6. Impact on Return Routability Process
According to RFC3775, return routability process has to be performed
by VMN to register CoA with CN. As described in section 5.3, after
Huang Expires April 14, 2007 [Page 12]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
VMN moves into mobile network, it will first register VMN_CoA with CN
to realize route optimization if CN can also support Route
Optimization mode. During the step, VMN has to perform HoTI/HoT and
CoTI/CoT message exchanges to get the home keygen token and the
care-of keygen token. When VMN means to register the second CoA
(VCoA) with CN, HoTI/HoT message exchange is unnecessary because the
home keygen token is the same. CoTI/CoT message exchange is
necessary to get the care-of keygen token.
There is some difficulty for mobile router to deal with CoT message
because home address does not appear in CoTI/CoT messages. It
results in that MR can not forward CoT messages to corresponding VMNs
so that VMN will fail to perform CoTI/CoT message exchange. To solve
the problem, it hopes that the same Home Address option in
Destination Option extension header and type 2 routing header can be
added to the CoTI and CoT messages.
5.7. Moving out of Mobile Network
When VMN moves out of mobile network and attaches to a new foreign
network, it will generate a new care-of address and register it with
HA and CN. According to 'multiple Care-of Addresses registration'
[draft-ietf-monami6-multiplecoa-00], VMN sends a regular Binding
Update which does not contain Binding Unique Identifier, CN or HA
MUST overwrite all existing bindings for the mobile node with the
received binding.
If VMN returns home, it MUST de-register all the bindings by sending
a Binding Update with lifetime set to zero. The mobile node MAY NOT
put any Binding Unique Identifier sub-option in this packet. Then,
the receiver deletes all the bindings from its Binding Cache.
5.8. MR Handover
When mobile router moves to another foreign link or returns home, it
first generates the new MR_CoA and VCoA and deals with registration
or de-registration with its HA according to RFC3963. Then it sends
Binding Update Refresh message with M flag and H flag set to 1 to
VMNs which still remain in the Route Optimization Cache. The new
VCoA MUST be included in Alternate Care-of Address option. If the
number of VMN is very large, MR SHOULD send Binding Update Refresh
with a little time interval to prevent registration storms between
VMN and CN.
After VMN receives the Binding Update Refresh message with M flag and
H flag set to 1, VMN gets the new VCoA from Alternate Care-of Address
option and updates the corresponding Binding Update List entry,
replacing the care-of address field with new VCoA. Then it registers
Huang Expires April 14, 2007 [Page 13]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
the new VCoA with HA and CN by sending Binding Update with a Binding
Unique Identifier sub-option. The BID is copied from a Binding
Update List to the Binding Unique Identifier sub-option.
It's possible that VMN could not register new VCoA with CN in time.
If CN detect the old VCoA binding invalidation by packets loss or
ICMP error messages such as ICMP_UNREACHABLE, it can change the
binding entry of VMN_CoA for the VMN so as to recover the connection
immediately. This mechanism is described in 'multiple Care-of
Addresses registration' [draft-ietf-monami6-multiplecoa-00].
6. Home Agent and Correspondent Node Operation
Home agent and correspondent node operation conforms to RFC3775 and
'multiple Care-of Addresses registration'. The only difference is
that CN SHOULD send CoT with HoA in type 2 routing Header as a
response to CoTI. HoA can be extracted from Home Address option of
Destination Option extension header in CoTI message.
7. About Nested Mobile Network
Nested NEMO is out of scope of this solution. Note, the solution can
work with nested NEMO but the actual routing within the NESTED NEMO
is out of scope for now and is a problem of itself.
8. IANA Considerations
TBD.
9. Security Considerations
Return routability process is described in the section 5.5 to ensure
that the correct binding relationship between VMN_CoA and HoA is
created in mobile router.
Regarding IPSec used to protect packets, some discussion has been
described in the section 5.4. Currently, ESP header in tunnel mode
is only used to protect the data packets between HA and VMN.
However, it's possible to use ESP tunnel mode to protect the packets
between CN and MN. If so, MR will not be able to get HoA from the
packets to distribute the packets to each VMN. How to deal with it?
Huang Expires April 14, 2007 [Page 14]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
10. Acknowledgments
The authors would like to thank Carl Williams, Liyun Ou, Xia Qin for
their comments.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbour
Discovery for IP version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[draft-ietf-monami6-multiplecoa-00]
Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration",
draft-ietf-monami6-multiplecoa-00 (work in progress),
June 2006.
[draft-ietf-nemo-terminology-04]
Ernst, T. and H. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-04 (work in
progress), October 2005.
Huang Expires April 14, 2007 [Page 15]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
11.2. Informative References
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[draft-ietf-nemo-ro-problem-statement-03]
Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network
Mobility Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-03(work in
progress), September 2006.
[draft-ietf-nemo-ro-space-analysis-03]
Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis",
draft-ietf-nemo-ro-space-analysis-03 (work in progress),
September 2006.
Huang Expires April 14, 2007 [Page 16]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
Author's Address
Zhigang Huang
Huawei Technologies
No.91 BaiXia Rd.
Nanjing, Jiangsu 210001
China
Phone: +86-25-84565415
Email: hpanda@huawei.com
Huang Expires April 14, 2007 [Page 17]
Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Huang Expires April 14, 2007 [Page 18]
