One document matched: draft-wakikawa-mobileip-multiplecoa-00.txt
Mobile IP Working Group Ryuji Wakikawa
INTERNET DRAFT Keisuke Uehara
18 Feb 2003 Thierry Ernst
Keio University/WIDE project
Multiple Care-of Address Registration on Mobile IPv6
draft-wakikawa-mobileip-multiplecoa-00.txt
Status of This Memo
This document is a submission to the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Motivation 2
3. Protocol Overview 3
R. Wakikawa et.al. Expires 18 Aug 2003 [Page i]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
4. Multiple Network Interface vs Multiple Care-of Address 4
5. Terminology 5
6. Mobile IPv6 Extension 6
6.1. Binding Cache Structure and Management . . . . . . . . . 6
6.2. Binding Update Structure and Management . . . . . . . . . 7
6.3. Messages Format Changes . . . . . . . . . . . . . . . . . 7
6.3.1. CoA InFormation sub-option . . . . . . . . . . . 7
6.3.2. Binding Update . . . . . . . . . . . . . . . . . 8
6.3.3. Binding Ack . . . . . . . . . . . . . . . . . . . 8
7. Return Routability Procedure 9
8. Mobile Node Operation 11
8.1. Management of care-of addresses . . . . . . . . . . . . . 11
8.2. Management of Multiple Care-of addresses on the interface 11
8.3. Sending Binding Update . . . . . . . . . . . . . . . . . 11
8.4. Receiving Binding Ack with CoAINFO sub-option . . . . . . 12
8.5. Receiving Binding Refresh Request with CoAINFO sub-option 13
8.6. Receiving Binding Error . . . . . . . . . . . . . . . . . 13
8.7. De-registration of one of care-of addresses . . . . . . . 14
8.8. Movement Detection . . . . . . . . . . . . . . . . . . . 14
9. Correspondent Node Operation 14
9.1. Selection of care-of address for outgoing packets . . . . 14
9.2. How to search the binding cache . . . . . . . . . . . . . 14
9.3. Receiving Binding Update . . . . . . . . . . . . . . . . 15
9.4. Sending Binding Ack . . . . . . . . . . . . . . . . . . . 15
9.5. Sending Binding Refresh Request . . . . . . . . . . . . . 16
9.6. Sending Binding Error . . . . . . . . . . . . . . . . . . 16
10. Security Consideration 16
Acknowledgments 16
References 16
Authors' Addresses 18
1. Introduction
This document describes how to manage and register multiple care-of
addresses which are assigned to either single or multiple network
interfaces with a single home address on Mobile IPv6. Associating
multiple care-of addresses with a home address enable durable
Internet connectivity [7] [1] [8]. For example, when a Mobile
Node (MN) loses its Internet connectivity at one of the interface,
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 1]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
it can use the second interface as a backup interface and still keep
connectivity to the network. In addition, the MN can send each
communication flow to a distinct network interface. This provides
efficient network bandwidth consumption. A user can select the most
suitable network interface per application.
IPv6 [2] conceptually allows a node to have several addresses on an
interface. Mobile IPv6 [3] has mechanisms to manage multiple home
addresses based on home agent's managed prefixes such as mobile
prefix solicitation, mobile prefix advertisement. But, according
to section 11.5.3 of [3], current Mobile IPv6 does not allow a MN
to register multiple care-of addresses as a binding. If a MN sends
Binding Update (BU) for each care-of addresses , Correspondent
Nodes (CNs) always overwrites the existing binding to the received
binding update. It is impossible for a MN to register multiple
care-of addresses in CN's binding cache.
Consequently, it lacks scheme to associate multiple care-of addresses
with a home address in binding cache. This document proposes
extension of binding cache management, new sub-options for binding
update to accommodate multiple care-of addresses.
2. Motivation
A MN moves across several networks (i.e. ISPs, hotspots, etc) in the
mobile world. Permanent Internet connectivity is required by some
applications. For example, if an automobile is running on a freeway
and receives voice or video streaming data via the Internet, it is
better never to shutdown the Internet connectivity.
Unfortunately, there is no network interface assuring global scale
connectivity. Therefore, the MN should use various type of network
interfaces to obtain wide areas network connectivity [6]. In
addition, users can select the most appropriate network interface
depending on the visiting network environment, since wireless
networks is mutable and less reliable than wired networks and each
network interface has different cost performance, bandwidth, access
range, and reliability. A user can also selects the most appropriate
interface per communication. For example, TCP communication should
be transmitted over wireless interface, but UDP communication should
be sent over wired interface not to disturb TCP connections.
Multiple care-of address registration to CNs is an efficient approach
to meet above requirements. CNs can re-select a binding of MN to
recover communication when one of MN's CoA becomes invalid. To put
binding selection policy to each binding, MN can use a binding for
specified communication type. If MN does not have enough bandwidth
for communications, it can utilize both of binding to gain network
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 2]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
bandwidth. Furthermore, MN may bicast packets through every network
interfaces for some flow.
Other approach is MMI [4]. MMI also proposed the use of multiple
network interfaces on Mobile IPv6. MMI basically focuses on
redirecting a flow from an interface to another depending on the
movement of the MN.
The advantage of using single home address compared to multiple home
addresses assigned to each network interface is that applications do
not need to be aware of the difference in home addresses. Of course,
a MN can assign multiple home addresses per network interfaces,
but applications should be aware of the active home address for
communication. At the TCP [5] layer, TCP holds the home address as
a source address of the communication for connection managements.
Thus, applications must reboot to reset the connection information
when the the MN changes the active network interface (i.e. change
the home address).
3. Protocol Overview
When a MN acquires multiple care-of addresses for a home address,
it SHOULD notify all of them to CN. Even if a CoA goes invalid, CN
still have another registered CoA for the MN. Thus, CN can switch
to an active CoA as soon as it detects CoA's invalidation. CN can
detect CoA's invalidation by packets loss or ICMP error messages
such as ICMP_UNREACHABLE. If the MN does not have enough bandwidth
for outgoing packets, the MN can utilize multiple network interfaces
simultaneously, and divide flow to each network interface.
This draft proposes a new identification number for each interface.
Once a MN gets several CoAs on difference interfaces, it MUST select
a primary CoA from active CoAs as well as the section 11.5.3 of [3].
After the selection, the interface which has the primary CoA becomes
the primary interface on the MN.
The MN registers only its primary CoA to its Home Agent (HA) as
the home registration. After the home registration, the MN MAY
send BU to CNs through Return Routability (RR) procedure. The MN
starts to send HoTI and CoTI for the primary CoA. If the MN has
another non-primary CoA, it also sends CoTI for the non-primary CoA
which can be assigned to any interfaces. This CoTI is sent with the
non-primary CoA set to the source address field of the IPv6 header.
The MN has to contain the identification number and the priority of
the interface which is assigned the target CoA in each CoTI message.
These values are securely notified to CNs by RR operations. After
getting HoT and CoT for either primary CoA or non-primary CoA, the MN
sends BU with the identification and the priority value for the CoA
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 3]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
which is authenticated by CoT. To register both CoAs to CNs, the MN
MUST sends BUs for each CoA.
When a CN receives a BU with the identification and the priority
value, it checks binding cache for the home address and the
identification. If both are matched, the CN updates the binding with
the new CoA (stored in the BU). Otherwise, it creates new binding for
the home address and the identification even if it has already had
a binding for the same home address, because the identification is
different.
Whenever the MN moves and changes the CoA for a given interface, it
MUST send BU with the identification value of the changed interface.
MN can always update the particular CoA with the identification of
the interface. When the MN returns home, it MUST de-register all the
bindings by BU which lifetime set to zero regardless of availability
of another care-of addresses. When MN detects that the primary
interface is attached to the home link, it indicates MN's returning
home.
4. Multiple Network Interface vs Multiple Care-of Address
There are two cases when a MN has several care-of addresses.
- MN uses several physical network interfaces to acquire a care-of
address.
- MN uses single physical network interface, but it acquires
several addresses from the attached network. Since IPv6 allows
to have several addresses on single network interface, it is
possible to get several global address with a network interface
at the attached network.
The difference between above two cases is a number of physical
network interfaces. This draft basically handles the several network
interfaces. To accommodate the second situation, this document
treats single interface as MN pseudoly having multiple network
interfaces. (i.e. if MN has multiple care-of addresses at the
single interface, Mobile IPv6 treats each care-of address is assigned
to each pseudo interface.) For example, MN obtained care-of address1
and care-of address2 at interface-A, MN treats this like: care-of
address1 is assigned to interface-A and care-of address2 is assigned
to pseudo-interface-B. If care-of address1 is deleted due to the
expiration of router lifetime, MN removes the pseudo interface-B. The
more protocol operation is described in the section 8.2.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 4]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
5. Terminology
Most of terms used in this draft are defined in [3].
InterFace IDentification number (IFID)
The identification number which is used to distinguish
each interface on MN. IFID is assigned to each interface,
and generated randomly not to duplicate each other. If an
interface has multiple care-of addresses, then MN can assign
IFID to a pseudo interface. MN has to assign different IFID
for each destination node. This is for security policy. If MN
uses same IFID to all destination nodes, it will always reveal
all interface information to all nodes. MN sometime hides some
of interface from specific destination nodes.
InterFace PRIority (IFPRI)
The priority value can be used to select a care-of address
on CN. The care-of address which has the highest priority is
the primary care-of address. Lower value indicates higher
priority. Zero indicates primary interface. If an interface
has multiple care-of addresses, then MN can assign IFPRI to
each care-of address.
Primary InterFace (P-IF)
The interface which is assigned a primary care-of address.
Once the primary interface goes invalid due to movements,
MN MUST reselect primary interface from set of interfaces
installed in MN.
Non-Primary InterFace(NP-IF)
The interface which is NOT assigned the primary care-of
address.
Primary care-of address (P-CoA)
The primary care-of address is defined as ``the care-of address
registered with the MN's home agent is called its ``primary''
care-of address'' in [3].
In this draft, the definition is extended as follows. The
care-of address which is primary associated with a home address
and is assigned to a P-IF. MN MUST have PCoA all the time.
Once PCoA goes invalid, MN MUST reselect PCoA from the multiple
care-of addresses that a MN may have at any given time.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 5]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
Non-Primary care-of address (NP-CoA)
The care-of address which is NOT selected as primary (i.e.
``non-primary'' CoA).
Care-of Address Information sub-option (CoAINFO)
The CoA information sub-option is used to notify IFID and IFPRI
with BU.
Multiple Care-of Addresses Flag (M flag)
A flag which indicated a CoAINFO sub-option is included in the
BU's mobility option field.
6. Mobile IPv6 Extension
Mobile IPv6 should be able to manage multiple care-of addresses. The
changes are described in this section.
6.1. Binding Cache Structure and Management
This document requires to have additional items for the binding cache
structure, which are
- IFID
The IFID of the registered care-of address. The IFID is notified
by BU sent by MN. The IFID is protected by return routability
procedure described in section 7.
- IFPRI
The IFPRI of the registered care-of address. The priority is
notified by BU. Whenever a BU is received, the priority value
MUST be overwritten to newest one. The IFPRI is also protected
by return routability procedure described in section 7.
If a node gets a BU with a CoAINFO defined at 6.3.1, it searches
Binding Cache entries with the set of the home address and the IFID.
If both does match with the registered binding, the node MUST update
the CoA and the IFID into the matched binding. Otherwise, the node
MUST register a new binding for the CoA and the IFID, even if there
are already the other binding for the MN's home address.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 6]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
6.2. Binding Update Structure and Management
This document requires to have additional items for binding update
structure, which are
- IFID
The IFID of the care-of address MUST be recorded in the binding
update list.
- IFPRI
The priority of the care-of address MUST be recorded in the
binding update list.
If MN has multiple care-of addresses at a time, it SHOULD assign a
IFID and a IFPRI to each care-of address. The IFID and the IFPRI
should be recorded in the binding update list. MN SHOULD update
the value of the IFID periodically not to be discovered by a third
person. The value of IFPRI can be changed at any time.
6.3. Messages Format Changes
6.3.1. CoA InFormation sub-option
The CoAINFO sub-option can be included in Binding Update, Binding
Ack, Binding Refresh Request, Binding Error if needed.
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 = TBD | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CoA ID | IFPRI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Type
Type value for CoAINFO will be assigned later.
Length
The value MUST be always 2.
IFID
The IFID of the care-of address which is notified by this
BU with CoAINFO.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 7]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
IFPRI
The IFPRI of the care-of address which is notified by this
BU with CoAINFO.
Reserved
16 bit Reserved field. Reserved field must be set with all
0.
6.3.2. Binding Update
If MN wants to register several CoAs which would be bound to a
home address, MN MUST set 'M' flag and include the CoA information
sub-option. The sub-option is constructed according to the binding
update list.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple Care-of Addresses Flag (M)
This flag is used for multiple care-of address registration.
Reserved
Reserved field is reduced to 11 bits.
6.3.3. Binding Ack
The message format of Binding Ack is not changed, but operations
listed below are added in this draft.
The receiver who gets binding update with 'M' flag MUST reply BA if
'A' flag is set or BU is for home registration. The receiver MUST
also reply BA with correspondent error number if it finds some error
during processing BU and its sub-option described in section 6.3.2.
If a BU has 'M' flag and a CoAINFO sub-option, a CN MUST reply
BA containing the CoAINFO sub-option. To include the CoAINFO
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 8]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
sub-option, the sender (i.e. MN) can process the BA for the target
CoA specified by the CoAINFO sub-option.
This document defines new number for 'M' flag handling.
1 Successful registration of NP-CoA
7. Return Routability Procedure
The CoTI and CoT messages transaction must be modified to secure the
CoAINFO sub-option. Therefore, this draft describes only CoTI and
CoT, because both HoTI and HoT are not modified at all. Processing
of HoTI and HoT can be found at [3].
Mobile node Home agent Correspondent node
| |
| 1b. |
| Care-of Test Init(CoTI) |
| Src = care-of address |
| Dst = correspondent |
| Parameters: |
| - care-of init cookie |
| - care-of address ID |
| - care-of address Priority |
|---------------------------------------------------->|
| |
| 2b. |
| Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - care-of init cookie |
| - care-of keygen token |
| - care-of nonce index |
|<----------------------------------------------------|
| |
1b. Care-of Test Init
The MN sends a Care-of Test Init message to the correspondent
node to acquire the care-of keygen token. The contents of this
message can be summarized as follows:
Src = care-of address
Dst = correspondent
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 9]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
Parameters:
+ care-of init cookie
+ care-of address ID (IFID)
+ care-of address Priority (IFPRI)
The second message conveys the MN's care-of address to the
correspondent node. The MN also sends along a care-of init
cookie that the correspondent node must return later. The
Care-of Test Init message is sent directly to the correspondent
node.
2b. Care-of Test
This message is sent in response to a Care-of Test Init message.
The contents of the message are:
Src = correspondent
Dst = care-of address
Parameters:
+ care-of init cookie
+ care-of keygen token
+ care-of nonce index
The correspondent node also sends a challenge to the MN's care-of
address. When the correspondent node receives the Care-of Test
Init message, it generates a care-of keygen token as follows:
care-of keygen token = First (64, MAC (Kcn, (care-of address
| IFID | IFPRI | nonce)))
The keygen token is formed from the first 64 bits of the MAC
result, and sent directly to the MN at its care-of address. The
care-of init cookie from the from Care-of Test Init message is
returned to ensure that the message comes from a node on the
route to the correspondent node.
The care-of nonce index is provided to identify the nonce used
for the care-of keygen token. The home and care-of nonce indices
are often the same in the Home and Care-of Test messages.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 10]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
8. Mobile Node Operation
8.1. Management of care-of addresses
A MN assigns IFPRI to each interface according to user's policy or
administrative policy. If the MN has only single interface, it
assigns ``zero value'' to the interface as P-IF.
A MN also assigns IFID to each interface. The value should be
randomly generated and assigned to each interface. If the MN has
single interface, assignment of IFID to the interface is not needed
until it has multiple interfaces.
A MN MUST handle P-CoA normally as described in base Mobile IPv6
[3]. For example, ``home registration to HA'' and ``returning home''
is proceeded without any changes to Mobile IPv6 (i.e. same as the
section 11.7.1 and the section 11.5.4 of [3]). P-CoA MUST be the
care-of address on P-IF all the time.
A MN MUST manage multiple NP-CoA per NP-IF. Whenever the MN detects
the change of a NP-CoA by the prefix comparison between the NP-CoA
and received router advertisements sent by routers, it MUST start
appropriate operations such as updating the binding, de-registering
the binding, etc.
8.2. Management of Multiple Care-of addresses on the interface
If MN obtains several care-of address on an interface, MN has to
select an address as the P-CoA from the set of addresses. If MN
wants to register several care-of address on the same interface,
MN has to assign the ID to each of care-of address temporarily and
register the address by BU with CoAINFO sub-option. Once the address
is deleted from the interface, MN MUST de-register the address by
sending BU with lifetime zero and correspond CoAINFO sub-option. The
ID assigned to a CoA is available until the CoA is active. Whenever,
the CoA changed, the MN MUST de-register the older CoA and the older
ID and MUST assign a new ID for the new CoA.
8.3. Sending Binding Update
When a MN sends a BU to its home agent (i.e. home registration), the
MN should choose the P-CoA for home registration. The MN SHOULD NOT
register multiple CoAs to the HA with CoAINFO sub-options. The MN
SHOULD operate the home registration as Mobile IPv6 described in [3].
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 11]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
When the MN sends a BU to CNs, it MUST decide whether it registers
multiple CoAs to the CN or not. However, this decision is out-of
scope in this document.
- General Mobile IPv6
If the MN decides not to register multiple CoAs to the CN, it
just starts RR and sends BU using the home-registered P-CoA
according to [3].
- RR procedure for P-CoA
On the other hand, if the MN need to register multiple CoAs
to the CN, the MN first attempts to process registration of
its P-CoA to the CN. The MN sends HoTI, and CoTI with CoAINFO
sub-option. In the CoAINFO sub-option, the MN puts a randomly
generated IFID and a IFPRI set to zero (to indicate primary).
These values MUST be recorded into the binding update list. An
IFID and an IFPRI for each interface MAY be configured beforehand
by users.
- Registration of P-CoA to a CN
Once the MN receives HoT and CoT from the CN, it prepares
for the BU. The BU must be constructed with 'M' flag and
contain a CoAINFO sub-option. The detail of BU is described in
section 6.3.2. The value of CoAINFO sub-option is copied from
the binding update list. Finally, the MN sends the BU to the
CN. The MN MUST wait a BA from the CN to confirm successfully
registration as described in section 8.4
- Registration of NP-CoAs to the CN
After registration of the P-CoA, the MN start processes of NP-CoA
registration. It sends CoTI with a CoAINFO sub-option and MAY
send HoTI as well. Since the MN has already received HoT from
the CN, sending HoTI CAN be skipped. When the value of the
CoAINFO sub-option for CoT is set, these values MUST be recorded
to the binding update list. After receiving CoT, it makes BU
including CoAINFO sub-option and 'M' flag. The value of CoAINFO
sub-option is copied from the binding update list. The MN MUST
wait a BA from the CN as described in section 8.4. The MN repeat
this operations for all possible care-of addresses.
8.4. Receiving Binding Ack with CoAINFO sub-option
Verification of Binding Ack is same as Mobile IPv6 (section 11.7.3
of [3]). The operation except for the text below is described in
the [3]. The operation of sending BA is described in 9.4.
If MN sends BU with a CoAINFO sub-option, BA MUST contain the CoAINFO
sub-option. If BA does not have the CoAINFO sub-option, the CN might
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 12]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
not recognize CoAINFO sub-option. The MN SHOULD stop registering
multiple care-of addresses by CoAINFO sub-option.
If BA has the CoAINFO sub-option and the success status value (i.e.
1), it indicates successful registration of the care-of address which
IFID is in the CoAINFO sub-option.
If the BA's status code is zero (indicating successfully registration
in Mobile IPv6 [3]) regardless of CoAINFO sub-option availability in
BA, the MN MAY stop attempting multiple binding registration to the
CN. The successful status code is ``1'' on this document, therefore
the CN may not registered multiple care-of addresses respectively.
(i.e. CN overwrites the existing binding to the received BU)
If the status field does not indicate success registration (i.e.
more than 128), it SHOULD stop registering the care-of address which
IFID is in the CoAINFO sub-option.
8.5. Receiving Binding Refresh Request with CoAINFO sub-option
Verification of Binding Refresh Request is same as Mobile IPv6
(section 11.7.4 of [3]). Operation except for text below is
described in the [3]. The operation of Sending Binding Refresh
Request (BRR) is described in the section 9.5.
If CN receives a BRR with a CoAINFO sub-option, this BRR indicates
BRR for the interface of IFID stored in the CoAINFO sub-option. The
MN MAY send BU for the care-of address which is assigned to the
interface.
If BRR does not contain a CoAINFO sub-option and if the MN has
the binding update list for the requesting node, the MN sends BU
according to the binding update list. On the other had, if the MN
does not have any binding update list for the requesting node, the MN
sends BU according to the section 8.3.
8.6. Receiving Binding Error
When a MN receives BE with a CoAINFO sub-option, the BE is for the
interface which IFID is stored in the CoAINFO sub-option. Further
operations except for the text below are same as [3]. The operation
of sending BE is described in the section 9.6.
If the message Status field is 2 (unrecognized MH Type value)
regardless of CoAINFO sub-option availability, the MN should stop
sending CoAINFO sub-option to the CN. Instead, the MN should register
only P-CoA to the CN.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 13]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
8.7. De-registration of one of care-of addresses
When a MN need to de-register one of care-of address, it sends a BU
with a CoAINFO sub-option to the CN. The BU MUST contain the lifetime
specified as zero and specify a Care-of address that matches the
home address for the binding. The CoAINFO sub-option MUST contain
IFID and IFPRI of the target interface. Otherwise, the CN can not
determine which binding should be deleted for this de-registration if
there are multiple bindings for the home address.
If a MN decided to delete all the binding from the CN, it sends
normal de-registration BU to the CN (i.e. exclusion of the CoAINFO
sub-option from the above operation). see the section 9.3 for
details.
8.8. Movement Detection
If the new visiting network is not the home link, the MN just updates
the CoA (either P-CoA or NP-CoA). If one of the interface changes the
attached network and gets a different CoA regardless of primary or
not, MN must register the new CoA to CNs with a CoAINFO sub-option.
Whenever the P-IF is attached to the home link, the MN sends BU for
de-registration to the HA and CNs. If the NP-IF is attached to the
home link, MN de-register NP-CoAs attached to the information of
NP-IF to CNs, but it SHOULD NOT de-register the binding for the P-CoA
to the HA and CNs.
9. Correspondent Node Operation
9.1. Selection of care-of address for outgoing packets
If the CN registers multiple care-of addressed for a home address
in its binding cache, it can use any of the binding for outgoing
communication to the registering MN.
The selection of the best CoA is out of scope in the present
document. However, the CN MAY decide to choose the best binding by
the comparison of each registered priority value.
9.2. How to search the binding cache
Whenever the CN searches the binding cache for the home address, it
SHOULD uses both the home address and an IFID as a key of search if
it knows IFID. The CN basically knows an IFID when it receives an
CoAINFO sub-option. At the time, the CN MUST look up the binding
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 14]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
cache with the home address and the IFID retrieved from the CoAINFO
sub-option.
If the CN does not know the IFID, the CN search the binding with only
the home address as well as base Mobile IPv6. The CN can ignore the
knowing IFID, if it does not desire to use.
9.3. Receiving Binding Update
If the received a BU does not contain a CoAINFO sub-option or does
not have 'M' flag set, the processing of the BU is same as [3]. But
if the CN has already registered multiple care-of addresses for the
home address, the CN MUST overwrite the binding for the home address
with the received BU. After receiving the BU which does not contain
a CoAINFO sub-option, the CN MUST have only a binding for the home
address.
The CN MUST validate the BU and the CoAINFO sub-option according
to the section 9.5.1 of [3]. If the received a BU contain a
CoAINFO sub-option or has 'M' flag set, the receiving node MUST
operate additional validation for the BU and the CoAINFO sub-option
additionally.
If the BU has 'M' flag at the flag field, it MUST contain a CoAINFO
sub-option. If it does not contains a CoAINFO sub-option, the CN
MUST silently drop the BU. If the CoAINFO sub-option is present, the
CN MUST register the IFID and the IFPRI to the MN's binding.
If the CN has already registered the binding for the home address and
IFID, then it MUST update the care-of address of the binding and the
IFPRI.
9.4. Sending Binding Ack
After processing the BU described in 9.3, the CN MUST reply BA either
when the 'A' bit is set to the BU or when the CN find an error during
processing BU described in [3].
If the BU does not contain a CoAINFO sub-option, the CN MUST reply BA
according to the section 9.5.4 of [3]. Otherwise, the CN MUST follow
the procedure below.
If the CN successfully registered the care-of address which
identified in CoAINFO sub-option, it returns BA with status set to
'1' (Successfully registration of NP-CoA) and the CoAINFO sub-option
copied from the BU.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 15]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
If the CN encountered an error during processing BU, it must returns
BA with appropriate error number described in [3]. The CN MAY attach
the CoAINFO sub-option to notify the dropped interface to the MN.
9.5. Sending Binding Refresh Request
When a CN notices that the registered binding will expire soon, it
SHOULD send BRR. If the registered binding has IFPRI and IFID, the CN
SHOULD contain CoAINFO sub-option in BRR. Then, the CN can receive BU
with CoAINFO sub-option and update only the target binding. If the
registered binding does not have IFPRI and IFID, then the CN sends
normal BRR.
9.6. Sending Binding Error
When a CN receives BU with an CoAINFO sub-option, it verifies the BU
according to the [3]. If the CN does not understand either the 'M'
flag or CoAINFO sub-option, it MUST return BE to the sender MN with
the status specified to '1'(Unrecognized MH Type value).
If the CN receives data packets with the home address destination
option, it MUST verify the IPv6 source address field. If the source
address is not registered in the CN's binding cache, the CN MUST
return BE to the sender MN with the status set to zero (Unknown
binding for Home Address destination option). Then, the MN MAY send
BU (with a CoAINFO sub-option) to register the new binding.
10. Security Consideration
The information of a CoAINFO can be protected by RR procedure. MN
contains the CoAINFO in CoTI. CN calculates a CoA keygen token based
on the MN's care-of address, the information of the CoAINFO (IFID and
IFPRI), and the CN's nonce. CN sends the CoA keygen token by CoT.
MN uses the CoA keygen token to calculate the authentication data
and puts the data to the authentication data sub-option. CN always
verify the information of the CoAINFO by comparison of authentication
data sub-option.
Acknowledgments
The authors would like to thank Susumu Koshiba, Koshiro Mitsuya,
Masafumi Watari and InternetCAR group at KEIO University for their
comments.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 16]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
References
[1] M. Baker, X. Zhao, S. Cheshire, and J. Stone. Supporting
mobility in mosquitonet. In Proceedings of the 1996 USENIX
Conference, Jan. 1996.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[3] D. Johnson, C. Perkins, and J. Arkko. Mobility
support in IPv6 (work in progress). Internet Draft,
(draft-ietf-mobileip-ipv6-20.txt), Internet Engineering Task
Force, January 2003.
[4] N. Montavont, T. Noel, and M. Kassi-Lahlou. MIPv6 for Multiple
Interfaces. Internet Draft (draft-montavont-mobileip-mmi-01.txt),
Internet Engineering Task Force, July 2002.
[5] J. Postel. Transmission Control Protocol. Request for Comments
(Standard) 793, Internet Engineering Task Force, September 1981.
[6] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay
networks. Mobile Networks and Applications, 3(4):335--350, 1998.
[7] R. Wakikawa, K. Uehara, and J. Murai. Multiple Network
Interfaces Support by Policy-Based Routing on Mobile IPv6. In
The 2002 International Conference on Wireless Networks, ICWN2002,
Jul. 2002.
[8] X. Zhao, C. Castelluccia, and M. Baker. Flexible network support
for mobility. In The Second Annual International Conference on
Mobile Computing and Networking, Nov. 1998.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 17]
Internet Draft Multiple Care-of Address Registration 18 Feb 2003
Authors' Addresses
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252 JAPAN
Phone: +81-466-49-1394 Thierry Ernst
EMail: ryuji@sfc.wide.ad.jp Keio University and WIDE
Fax: +81-466-49-1395 5322 Endo Fujisawa Kanagawa
252 JAPAN
Keisuke Uehara Phone: +81-466-49-1394
Keio University and WIDE EMail: ernst@sfc.wide.ad.jp
5322 Endo Fujisawa Kanagawa Fax: +81-466-49-1395
252 JAPAN
Phone: +81-466-49-1394
EMail: kei@wide.ad.jp
Fax: +81-466-49-1395
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 04:01:36 |