One document matched: draft-wakikawa-mobileip-multiplecoa-03.txt
Differences from draft-wakikawa-mobileip-multiplecoa-02.txt
MIP6 Working Group Ryuji Wakikawa
INTERNET DRAFT Keisuke Uehara
Category: Individual Thierry Ernst
19 Jun 2004 Keio Univ./WIDE
Kenichi Nagami
INTEC Netcore
Multiple Care-of Addresses Registration
draft-wakikawa-mobileip-multiplecoa-03.txt
Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
This document is a submission to the MIP6 Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mip6@ietf.org (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
According to the current Mobile IPv6 specification, a mobile node
may have several care-of addresses, but only one, termed the primary
care-of address, can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through
multiple access media (i.e. interfaces) simultaneously, in which
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 1]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
case multiple active IPv6 care-of addresses would be assigned to
the mobile node. We thus propose Mobile IPv6 extensions designed
to register multiple care-of addresses bound to a single home
address instead of the sole primary care-of address. For doing so,
a new identification number must be carried in each binding for the
receiver to distinguish between the bindings corresponding to the
same home address. Those extensions are targeted to NEMO (Network
Mobility) Basic Support as well as to Mobile IPv6.
Contents
Status of This Memo 1
Abstract 1
1. Introduction 4
2. Terminology 6
3. Protocol Overview 8
3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8
3.2. Multiple Bindings Management . . . . . . . . . . . . . . 9
3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . 9
4. Mobile IPv6 Extensions 10
4.1. Binding Cache Structure and Management . . . . . . . . . 10
4.2. Binding Update Structure and Management . . . . . . . . . 10
4.3. Messages Format Changes . . . . . . . . . . . . . . . . . 11
4.3.1. Binding Unique Identifier sub-option . . . . . . 11
4.3.2. Binding Update . . . . . . . . . . . . . . . . . 12
4.3.3. Binding Acknowledgment . . . . . . . . . . . . . 12
5. Mobile Node Operation 13
5.1. Management of care-of addresses . . . . . . . . . . . . . 13
5.2. Sending Binding Update . . . . . . . . . . . . . . . . . 13
5.3. De-registration . . . . . . . . . . . . . . . . . . . . . 14
5.4. Using Alternate Care-of Address . . . . . . . . . . . . . 15
5.5. Receiving Binding Acknowledgment . . . . . . . . . . . . 16
5.6. Receiving Binding Refresh Request . . . . . . . . . . . . 16
5.7. Receiving Binding Error . . . . . . . . . . . . . . . . . 17
6. Home Agent and Correspondent Node Operation 17
6.1. Searching Binding Cache with Binding Unique Identification
Number . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 18
6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 19
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 19
6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 20
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 2]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
7. Network Mobility Applicability 20
Appendices 21
A. Example Configurations 21
Example Configurations 21
Acknowledgments 24
References 24
Authors' Addresses 26
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 3]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
1. Introduction
Permanent Internet connectivity is required by some applications
while a mobile node moves across several access networks (i.e.
ISPs, hotspots, etc). For example, it is desirable to maintain
the Internet connectivity while an automobile running on a freeway
receives voice or video streaming data from different access
networks. Such motivations for multiple points of attachment, and
benefits for doing it are discussed at large in [5].
Unfortunately, there is no network interfaces assuring global scale
connectivity. Therefore, a mobile node should use various type of
network interfaces to obtain wide area network connectivity [8]. In
addition, users should select the most appropriate network interface
depending on a visiting network environment, since wireless networks
are mutable and less reliable than wired networks and since each
network interface has different cost, performance, bandwidth, access
range, and reliability. Users should also be able to select the
most appropriate interface per communication type. For example, TCP
traffic should be transmitted over the wireless interface, whereas
UDP traffic should be transmitted over wired the interface to avoid
disturbing TCP connections.
Associating multiple care-of addresses to a single home address would
allow durable Internet connectivity [10] [1] [11]. For example,
when a mobile node loses its Internet connectivity at one of its
interface, the second interface can be used as a backup interface
therefrom maintaining Internet connectivity. In addition, the
mobile node 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.
Correspondent nodes can also re-select a binding of the mobile node
to recover communication when one of mobile node's bindings becomes
invalid. To enable a binding selection policy, a mobile node can
use the particular binding for specified communication type. If a
mobile node does not have enough bandwidth for communications, it
can utilize both bindings to gain network bandwidth. Furthermore,
a mobile node may bicast packets of a particular flow through all
available network interfaces.
IPv6 [2] conceptually allows a node to have several addresses on a
given interface. Consequently, Mobile IPv6 [6] has mechanisms to
manage multiple ``home addresses'' based on home agent's managed
prefixes such as mobile prefix solicitation and mobile prefix
advertisement. But assigning a single home address to a given
network interface is more advantageous than assigning multiple
home addresses because applications do not need to be aware of the
multiplicity of home addresses. Of course, applications should be
aware of the active home address to be used for communicating. At
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 4]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
the TCP layer, TCP holds the home address as a source address of the
communication for connection management. Thus, applications must be
restarted to reset the connection information when the mobile node
changes its active network interface (i.e. change the home address).
However, according to section 11.5.3 of the Mobile IPv6 specification
[6], a mobile node is not allowed to register multiple care-of
addresses bound to a single home address. If a mobile node sends
Binding Updates for each care-of address, correspondent nodes would
always overwrite the care-of address recorded in the binding cache
with the one contained in the latest received binding update. It
is thus impossible for a mobile node to register multiple care-of
addresses in the correspondent node's binding cache.
In this document, we thus propose a new identification number called
Binding Unique Identification number (BID) for each binding cache
entry to accommodate multiple bindings registration. We also propose
extension of binding cache management to store the BID and a new
sub-option for binding update to carry the BID. The BID is assigned
to either the interfaces or care-of addresses bound to a single home
address of a mobile node. The mobile node notifies the BID to both
its home agent and correspondent nodes by means of a Binding Update.
Correspondent nodes and the home agent record the BID into their
binding cache. The home address thus identifies a mobile node itself
whereas the BID identifies each binding registered by a mobile node.
By using the BID, multiple bindings can then be distinguished.
A user of a mobile node may be able to bind some policies to a BID.
The policy is used to divide flows to multiple network interfaces
by flow type, port number, or destination address, etc. How to
distribute or configure policies is not within the scope of this
document.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 5]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
2. Terminology
Terms used in this draft are defined in [6] and [7]. We define or
redefine the following ones:
Binding Unique Identification number (BID)
The BID is an identification number used to distinguish
multiple bindings registered by the mobile node. Assignment of
distinct BID allows a mobile node to register multiple binding
cache entries for a given home address. The BID is generated
in a way it cannot be duplicated with another BID. The zero
value and a negative value MUST NOT be used. After being
generated, the BID is stored in the Binding Update List and is
sent by the mobile node by means of a sub-option of a Binding
Update. A mobile node MAY change the value of a BID at any
time according to its administrative policy, for instance to
protect its privacy.
The BID can be assigned to either a care-of address or an
interface depending on implementations so as to keep using
the same BID for the same binding even when the status of the
binding is changed. More details can be found in Section 5.1.
Primary care-of address
In [6], the primary care-of address is defined as ``the care-of
address registered with the mobile node's home agent is called
its ``primary'' care-of address''. In this present document,
the term is refined as ``the care-of address which is primarily
associated with a home address''.
A mobile node MUST have a primary care-of address all the time.
Once the primary care-of address becomes invalid, the mobile
node MUST reselect a primary care-of-address from the multiple
care-of addresses that a mobile node may have at any given
time.
Primary Interface
The interface on which the primary care-of address is assigned.
Once the primary interface becomes invalid due to movements,
the mobile node MUST re-select a primary interface from the set
of interfaces installed in the mobile node.
Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is used to carry the
BID.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 6]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
Multiple Care-of Addresses Flag (M flag)
This flag indicates that a Binding Unique Identifier sub-option
is included in the Binding Update Mobility Option field.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 7]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
3. Protocol Overview
We propose a new identification number to distinguish multiple
bindings pertaining to the same home address. The procedures for
the mobile node to register multiple bindings are described in the
paragraphs below.
3.1. Multiple Care-of Addresses Registration
Once a mobile node gets several IPv6 global addresses on distinct
interfaces, it MUST select a primary care-of address from the active
addresses as specified in Section 11.5.3 [6]. After the selection,
the interface which has the primary care-of address becomes the
primary interface for the mobile node.
After selecting the primary care-of address, the mobile node MUST
register it with its home agent (home registration). If the mobile
node wants to register multiple bindings to its home agent, it MUST
generate a BID for the primary care-of address and record it into
the binding update list entry. The mobile node then registers its
primary care-of address by sending a Binding Update with a Binding
Unique Identifier sub-option. The M flag MUST be set in the Flag
field of the Binding Update and the BID MUST be put in the Binding
Unique Identifier sub-option. After receiving the Binding Update,
the home agent verifies the request and records the binding in its
binding cache. If the newly defined sub-option is present in the
Binding Update, the home agent MUST copy the BID from the Binding
Update to the corresponding field in the binding entry.
After this home registration, the mobile node can register the rest
of care-of addresses to its Home Agent. Even if there is already
an entry for the mobile node, the home agent MUST registers a new
binding entry for the BID stored in the Binding Unique Identifier
sub-option. The registration process is the same as for the
registration of the primary care-of address. The mobile node MUST
register multiple care-of addresses respectively.
If the mobile node wish to register its binding with a correspondent
node, it MUST starts return routability operations before sending a
Binding Update. The mobile node MUST sends CoTI for each care-of
addresses and MUST receive CoT for each care-of addresses. The
mobile node also generates a BID for each care-of addresses to
register them as individual bindings . The registration step
is the same as for the home registration except for calculating
authenticator with Binding Unique Identifier sub-option as well as
the other sub-options specified in [6].
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 8]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
3.2. Multiple Bindings Management
The BID is also used as a search key of the binding cache database as
well as a home address. When the home agent checks the binding cache
database for the mobile node, it searches a corresponding binding
entry with the home address and BID of the desired binding. The
desired binding can be selected with policy and filter information.
The capability of searching the desired binding enables load-sharing
and QoS with flow separation. But this selection and flow separation
are out of scope in this draft. If there is no desired binding,
it search the binding cache database with the home address as well
as Mobile IPv6. The first matched binding entry may be found, but
which binding entry is returned for the normal search depends on
implementations.
If a node has multiple bindings and its packets meant for the
mobile node are not delivered correctly, the node can change the
binding entry for the mobile node so as to recover the connection
immediately. The node can detect a binding invalidation by packets
loss or ICMP error messages such as ICMP_UNREACHABLE. This provides
redundancy for Mobile IPv6.
When one of the care-of addresses is changed, the mobile node sends
a Binding Update with the new care-of address and the corresponding
BID. The receiver of the Binding Update updates the binding which
BID fits the BID contained in the received Binding Unique Identifier
sub-option. The mobile node can manage each binding independently
owing to BID.
Once the mobile node decides to register only one binding, it just
sends a Binding Update without M flag and a Binding Unique Identifier
sub-option (i.e. normal Binding Update). The receiver of the
Binding Update registers only single binding for the mobile node.
If the receiver has multiple bindings, one bindings is registered
without BID and the rest of bindings are deleted.
3.3. Returning Home
When the mobile node returns home, there are two situations. It is
because the home agent defends the mobile node's home address by
using proxy neighbor advertisement. It is impossible to utilize
all the interfaces when one interface is attached to home and the
others are attached to foreign link. If proxy Neighbor Advertisement
for the home address is stopped, packets are always routed to the
interface attached to the home link. If proxy is not stopped,
packets are never routed to the interface attached to the home link.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 9]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
The first situation is when the primary interface is attached to the
home link. In this case, the mobile node MUST de-register all the
bindings by sending a Binding Update which lifetime set to zero. The
mobile node MAY NOT put any Binding Unique Identifier sub-options
in this packet. Then, the receiver deletes all the bindings from
its binding cache database. On the other hand, if the mobile node
wants to delete binding entries respectively, it sends multiple
de-registration Binding Updates for all BID (that is all registered
care-of addresses). In those Binding Updates, the mobile node MUST
store a Binding Unique Identifier sub-option. Only when the care-of
address is the primary one and the destination is the home agent, the
mobile node also set the 'P' flag in the Binding Unique Identifier
sub-option to indicates stop proxying for the mobile node to the home
agent. The 'P' flag is valid only when the destination of a Binding
Update is a home agent.
The second situation is when a non-primary interface is attached to
the home link. The primary care-of address takes precedence over
the rest of addresses. The mobile node stops using the interface
attached to the home link and keeps using the rest of interfaces
attached to foreign links. In this case, the mobile node sends
de-registration Binding Update with the Binding Unique Identifier
sub-option. The mobile node stores the BID of the binding and MUST
NOT set the 'P' flag in the sub-option regardless of home agent or
not. Therefore, the receiver of the de-registration Binding Update
deletes only the binding entry from the binding cache database. The
home agent does not stop proxying neighbor advertisement.
4. Mobile IPv6 Extensions
In this section are described the changes to allow Mobile IPv6 to
manage multiple bindings bound to a same home address.
4.1. Binding Cache Structure and Management
Additional items are required in the binding cache structure, which
are:
- BID of the binding cache entry. The BID is notified by the
mobile node by means of a Binding Update sub-option. The value
MUST be zero if the Binding Update does not contain a BID.
4.2. Binding Update Structure and Management
Additional items are required for the binding update structure, which
are:
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 10]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
- BID: MUST be generated whenever the mobile node decides to
register multiple bindings for its home address.
- Primary flag: MUST be set if the care-of address is primary.
4.3. Messages Format Changes
4.3.1. Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is included in Binding
Update, Binding Acknowledgment, 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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) | P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Type
Type value for Binding Unique Identifier will be assigned
later.
Length
The value MUST be always 4.
Binding Unique ID (BID)
The BID which is assigned to the binding carried in
the Binding Update with this sub-option. BID is 16-bit
unsigned integer. A value of zero is reserved.
Flag
Stop Proxy Neighbor Advertisement (P) Flag
When this flag is set, the home agent MUST stop
proxy neighbor advertisement for a mobile node.
This flag is checked only when a Binding Update
is for de-registration and the destination of a
Binding Update is mobile node's home agent (i.e.
home de-registration). Otherwise, this flag MUST be
ignored.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 11]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
Reserved
15 bit Reserved field. Reserved field must be set with all
0.
4.3.2. Binding Update
If a mobile node wants to register several care-of addresses which
would be bound to a home address, mobile node MUST set 'M' flag and
include a Binding Unique Identifier sub-option.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|R|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R)
This flag is proposed by the NEMO working group [3].
Multiple Care-of Addresses Flag (M)
This flag is used for multiple care-of addresses
registration.
Reserved
Reserved field is reduced to 11 bits.
4.3.3. Binding Acknowledgment
The message format of Binding Acknowledgment is not changed, but
operations listed below are added in this draft.
A receiver who gets a Binding Update with the 'M' flag set MUST reply
with a Binding Acknowledgment if the 'A' flag is also set or in
case of a home registration. The receiver MUST also send a Binding
Acknowledgment with corresponding error codes if it finds an error
while processing the Binding Update and its sub-option described in
section 4.3.2.
If a Binding Update has the 'M' flag set and a Binding Unique
Identifier sub-option is present, the receiver node MUST reply with a
Binding Acknowledgment containing the same Binding Unique Identifier
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 12]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
sub-option. The mobile node can process the Binding Acknowledgment
for the particular care-of address identified by the BID set in the
Binding Unique Identifier sub-option.
A new number is defined for handling the 'M' flag:
140 Conflicting a regular binding and a binding that has BID in
binding cache. The regular binding indicates the binding that
does not have BID field. The number is TBD.
5. Mobile Node Operation
5.1. Management of care-of addresses
There are two cases when a mobile node has several care-of addresses:
- A mobile node uses several physical network interfaces to acquire
a care-of address.
- A mobile node uses a 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 the above two cases is only a number of
physical network interfaces and therefore does not matter. The
Identification number is used to distinguish multiple bindings so
that the mobile node assigns an identification number for each
care-of addresses. How to assign an identification number is up to
implementors.
A mobile node assigns a BID to each care-of address when it wants
to simultaneously register with its home address. The value should
be generated from a value comprised between 1 to 65535. Zero and
negative value can not be taken as a BID. If a mobile node has only
one care-of address, the assignment of a BID is not needed until it
has multiple care-of addresses to register with.
5.2. Sending Binding Update
When a mobile node sends a Binding Update to its home agent (i.e.
home registration) and the Binding Update is aimed to de-register
the binding, the mobile node MUST check whether the care-of address
contained in the Binding Update is primary or not. If the care-of
address is primary one, it MUST set the 'P' flag in the Binding
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 13]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
Unique Identifier sub-option. More description about the 'P' flag
can be found in Section 5.3.
When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple care-of addresses or not. However, this decision
is out-of scope in this document. If a mobile node decides not to
register multiple care-of addresses, it completely follows standard
Mobile IPv6 [6].
On the other hand, if mobile node needs to register multiple care-of
addresses, the mobile node MUST use BIDs for all care-of addresses
all the time. The mobile node sets M flag in a Binding Update and
puts a Binding Unique Identifier sub-option into the Option field of
the Binding Update. The BID is copied from a Binding Update List
to the Binding Unique Identifier sub-option. If the mobile node
registers bindings to a correspondent node, it MUST sends multiple
CoTI for multiple care-of addresses. After getting CoTs, it sends
Binding Updates with the 'M' flag set and a Binding Unique Identifier
sub-option for all care-of addresses, one by one. In any case,
the mobile node MUST set the 'A' flag in Binding Updates and MUST
wait for a Binding Acknowledgment to confirm the registration was
successful as described in section 5.5.
Note that there is no optimization such as registering multiple
care-of addresses by using a single Binding Update, because the
current Mobile IPv6 specification does not allow to send multiple
bindings by means of a single Binding Update.
5.3. De-registration
When a mobile node decides to delete all bindings for its home
address, it sends a regular de-registration Binding Update (i.e.
unset of 'M' flag and exclusion of a Binding Unique Identifier
sub-option). See Section 6.2 for details.
If a mobile node wants to delete a particular binding from its home
agent and correspondent nodes, it follows the operations below.
When a mobile node is attached to its home link by one of its network
interfaces, it MUST de-register an appropriate binding. If a binding
of a primary care-of address becomes invalid in terms of the mobile
node's returning home, it MUST set the 'P' flag in a Binding Unique
Identifier sub-option. Otherwise, the 'P' flag MUST NOT be set. If
the 'P' flag is set, the home agent stop proxy neighbor advertisement
for the mobile node. If the receiver is not the Home Agent but a
Correspondent Node, it ignores the 'P' flag.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 14]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
When the mobile node's primary interface gets attached to the home
link by its primary (see Figure 2 and Figure 4 in Appendix A), the
Mobile Node MUST start de-registration processing to its home agent
as indicated in Mobile IPv6. The home agent deletes all bindings
for the mobile node and stops intercepting packets meant for the
mobile node. Although the mobile node MUST deletes the binding at
correspondent nodes as well, the node can still keep the binding of
the non-primary interface active at the correspondent nodes. In
such case, the mobile node still receives packets at a non-primary
interface attached to a foreign link thanks to route optimization.
The mobile node also receives packets at the primary interface
attached to the home link when correspondent nodes does not use route
optimization.
On the other hand, when the mobile node's non-primary interface gets
attached back to the home link (see Figure 3 in Appendix A), the
MN MUST delete only the particular binding from its home agent and
correspondent nodes. The home agent does not delete all bindings
and does not stop proxy neighbor advertisement for the mobile
node. Therefore, the mobile node no longer receives packets at the
non-primary interface attached to the home link. All packets are
routed to other interfaces attached to a foreign link. If the mobile
node is eager to receive packets at the non-primary interface at the
home link, it MUST re-select the interface as the primary one.
5.4. Using Alternate Care-of Address
A mobile node can use an alternate care-of address in the following
situations.
- One care-of address becomes invalid (.e.g because the link where
it is attached is no longer available) and MUST be deleted.
In such case, the mobile node can not sends a Binding Update
from the care-of address because the interface's link is lost.
The mobile node needs to de-register the remote binding of the
care-of address through one of its active care-of addresses.
- A mobile node has multiple interfaces, but it wants to sends
Binding Updates for all care-of addresses from a specific
interface which has wider bandwidth depending on interface's
characteristics. A mobile node does not want to send a lot of
control messages through an interface which bandwidth is scarce.
In these cases, the mobile node sends a Binding Update with both
Alternate Care-of Address sub-option and Binding Unique Identifier
sub-option. The processing of Alternate Care-of Address sub-option
is described in the Mobile IPv6 specification. If there is an
Alternate Care-of Address sub-option, the BID in a Binding Unique
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 15]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
Identifier sub-option is assigned for the care-of address in the
Alternate Care-of Address sub-option.
5.5. Receiving Binding Acknowledgment
The verification of a Binding Acknowledgment is the same as in Mobile
IPv6 (section 11.7.3 of [6]). The operation for sending a Binding
Acknowledgment is described in 6.3.
If a mobile node sends a Binding Update with a Binding Unique
Identifier sub-option, a Binding Acknowledgment MUST have a
Binding Unique Identifier sub-option in Mobility options field. If
there is no such sub-option, the originator node of this Binding
Acknowledgment might not recognize the Binding Unique Identifier
sub-option. The mobile node SHOULD stop registering multiple care-of
addresses by using a Binding Unique Identifier sub-option.
If a Binding Unique Identifier sub-option is present, the mobile node
checks the Status field of the Binding Acknowledgment. If the status
code indicates successful registration (1), the originator registers
a binding information and BID for the mobile node successfully.
If the status code is not zero regardless of Binding Unique
Identifier sub-option availability in BA, the mobile node proceeds an
appropriate operations according to the status code.
If the status code is 140, the mobile node has already registered a
regular binding before sending a Binding Update with a Binding Unique
Identifier sub-option. In such case, the mobile node SHOULD stop
sending Binding Updates without BID.
5.6. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of [6]). The operation of sending a
Binding Refresh Request is described in section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding
Unique Identifier sub-option, this Binding Refresh Request requests
a binding indicated by the BID. The mobile node SHOULD update only
the respective binding. The mobile node MUST put a Binding Unique
Identifier sub-option into a Binding Update.
If no Binding Unique Identifier sub-option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according
to its Binding Update List for the requesting node. On the other
hand, if the mobile node does not have any Binding Update List entry
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 16]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
for the requesting node, the mobile node needs to register either
a single binding or multiple bindings depending on its binding
management policy.
5.7. Receiving Binding Error
When a mobile node receives a Binding Error with a Binding Unique
Identifier sub-option, the message is for a binding indicated by the
BID in the Binding Unique Identifier sub-option. Further operations
except for the text below are identical as in [6]. The operation for
sending BE is described in the section 6.5.
When a mobile node receives a Binding Error with Status field set
to 2 (unrecognized MH Type value) , it MAY stop trying to register
multiple care-of addresses and registers only primary care-of address
as performed in Mobile IPv6.
6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Unique Identification
Number
If a correspondent node has multiple bindings for a mobile node
in its binding cache database, it can use any of the bindings to
communicate with the mobile node. How to select the most suitable
binding from the binding cache database is out of scope in this
document.
Whenever a correspondent node searches a binding cache for a home
address, it SHOULD uses both the home address and the BID as the
search key if it knows the corresponding BID. Below is an example of
multiple bindings for a home address in the binding cache database.
If a correspondent node searches the binding with the home address
and BID2, it gets binding2 for this mobile node.
binding1 [a:b:c:d::EUI care-of address1 BID1]
binding2 [a:b:c:d::EUI care-of address2 BID2]
binding3 [a:b:c:d::EUI care-of address3 BID3]
A correspondent node basically learns the BID when it receives a
Binding Unique Identifier sub-option. At the time, the correspondent
node MUST look up its binding cache database with the home address
and the BID retrieved from Binding Update. If the correspondent node
does not know the BID, it searches a binding with only a home address
as performed in Mobile IPv6. In such case, the first matched binding
MAY be found. But which binding entry is returned for the normal
search depends on implementations. If the correspondent node does
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 17]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
not desire to use multiple bindings for a mobile node, it can simply
ignore the BID.
6.2. Receiving Binding Update
If a Binding Update has neither 'M' flag set nor a Binding Unique
Identifier, the processing of the regular Binding Update is the same
as in [6]. But if the receiver already has multiple bindings for the
home address, it MUST overwrite existing bindings for the mobile node
with the received binding. As the result, the receiver node MUST
have only a binding for the mobile node. If the Binding Update is
for de-registration, the receiver MUST delete all existing bindings
for the mobile node.
On the other hand, if a Binding Update contains a Binding Unique
Identifier sub-option or the 'M' flag is set, a receiver node MUST
operate additional validations as follows:
- A receiver node MUST validate the Binding Update according to
section 9.5.1 of [6].
- If the Binding Update has the 'M' flag set at the Flag field, a
Binding Unique Identifier sub-option MUST be present in Mobility
options field of the Binding Update.
- If there is no Binding Unique Identifier sub-option with the
'M' flag set, the receiver node MUST silently drop the Binding
Update.
- If the Binding Unique Identifier sub-option is present, the
receiver node MUST process the Binding Update.
- If the Lifetime field is not zero, the receiver node registers a
binding that includes the BID as a mobile node's binding.
* If the receiver does not have any binding for the mobile
node, it registers a binding which includes BID field.
* If the receiver has a regular binding which does not have
BID for the mobile node, it de-registers the regular binding
and registers a new binding including BID according to the
Binding Update. In this case, the receiver MUST send Binding
Acknowledgment with status code set to 140.
* If the receiver node has already registered the binding which
BID is matched with requesting BID , then it MUST update
the binding up-to-date with the Binding Update. Meanwhile,
if the receiver does not have a binding entry which BID is
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 18]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
matched with the requesting BID, it registers a new binding
for the BID.
- If Lifetime field is zero, the receiver node deletes the
registering binding entry which BID is same as BID sent by the
Binding Unique Identifier sub-option. If the receiver node
does not have appropriate binding which BID is matched with the
Binding Update, it ignores the Binding Update.
Note if the mobile node sends multiple Binding Updates with a
different BID but for same care-of address (i.e. same home address,
same care-of address, and different BID) , the receiver SHOULD
register both bindings into its binding cache.
6.3. Sending Binding Acknowledgment
If a Binding Update does not contain a Binding Unique Identifier
sub-option, the receiver, either a correspondent node or a home
agent, MUST reply with a Binding Acknowledgment according to section
9.5.4 of [6]. Otherwise, whenever the BID sub-option, the receiver
MUST follow the additional procedure below. The receiver MUST reply
with a Binding Acknowledgment whether the 'A' flag is set or not in
Binding Update.
If the receiver successfully registers a binding for the BID stored
in a Binding Unique Identifier sub-option, it returns a Binding
Acknowledgment with Status field set to '0' (Successful registration)
and a Binding Unique Identifier sub-option copied from the received
Binding Update. If the receiver deletes the existing binding which
does not have a BID and registers a new binding for the BID, it MUST
return a Binding Acknowledgment with Status field set to '140'. On
the other hand, if the node encounters an error during the processing
of a Binding Update, it must return a Binding Acknowledgment with an
appropriate error number as described in [6]. The node SHOULD put a
Binding Unique Identifier sub-option if the BID is available for the
Binding Acknowledgment.
6.4. Sending Binding Refresh Request
When either a correspondent node or Home Agent notices that
a registered binding will be expired soon, it SHOULD send a
Binding Refresh Request. If the registered binding has BID, the
correspondent node SHOULD contain a Binding Unique Identifier
sub-option in the Binding Refresh Request. Then, the correspondent
node can receive a Binding Update with a Binding Unique Identifier
sub-option and can update only the particular binding. If the
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 19]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
registered binding does not have BID, then the correspondent node
sends a Binding Refresh Request without the sub-option.
6.5. Sending Binding Error
When a correspondent node sends a Binding Error with Status field
set to 1 (Unrecognized MH Type value), it MAY put a Binding Unique
Identifier sub-option into Mobility Options field if BID is available
in a received binding message.
When a correspondent node receives data packets with a home address
destination option, it verifies the IPv6 source address field. If
the source address is not registered in the correspondent node's
binding cache, the correspondent node MUST return a Binding Error
to the sender with the status set to zero (Unknown binding for Home
Address destination option). The correspondent node can not put a
Binding Unique Identifier sub-option, because there is no binding
cache entry for the source address.
7. Network Mobility Applicability
Support of multihomed mobile routers is advocated in the NEMO working
group (see R12 ``The solution MUST function for multihomed MR and
multihomed mobile networks'' in [4]).
Since the binding management mechanisms are the same for a mobile
host operating Mobile IPv6 and for a mobile router operating NEMO
Basic Support [3], our extensions can also be used to deal with
multiple care-of addresses registration sent from a multihomed mobile
router.
A mobile router MUST NOT use the 'P' flag when its home agent does
not use proxy neighbor advertisement to intercept packets destined to
the mobile router. This situation is occurred when the home link is
configured as a virtual home link in terms of extended home address
described in [9].
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 20]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
A. Example Configurations
In this section, we describes typical scenarios when a mobile
node has multiple network interfaces and acquires multiple care-of
addresses bound to a home address.
The home address of the mobile node (MN in figures) is a:b:c:d::EUI.
MN has 3 different interfaces and possibly acquires care-of addresses
1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each
care-of addresses.
Figure 1 depicts the scenario where all interfaces of the mobile node
are attached to foreign links. After binding registrations, the home
agent (HA) and the correspondent node (CN) have the binding entries
listed in Figure 1 in their binding cache database. The mobile node
can utilize all the interfaces.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Correspondent Node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 1: Multiple Interfaces are attached to Foreign Link
Figure 2 depicts the scenario where the primary interface of MN is
attached to the home link.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 21]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
After bindings registration, HA and CN have the binding entries
listed in Figure 2 in their binding cache database. MN can
communicate with the HA through only the primary interface attached
to the home link. On the other hand, the mobile node can communicate
with CN by using route optimization. Even when MN is attached to the
home link, it can still send Binding Updates for other active care-of
addresses (CoA2 and CoA3). If CN has bindings, packets are routed
to each care-of addresses directly. Any packets arrived at HA are
routed to the primary interface.
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +--------+-+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ | |
+--+--+ | | |
CoA3| +---|-----------+
+---------------+
Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is inactive)
none
Correspondent Node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 2: Primary Interface is attached to Home Link
Figure 3 depicts the scenario where a non-primary interface of a MN
is attached to the home link.
The HA and the CN have the binding entries listed in Figure 3 in
their binding cache database. MN can not utilize the non-primary
interface attached to the home link, because the HA still defends the
home address of the MN by proxy neighbor advertisements. All packets
routed to the home link are intercepted by the HA and tunneled to
the other interfaces attached to the foreign link according to the
binding entries.
Figure 4 depicts the scenario where primary and a non-primary
interface of MN are attached to the home link. The HA and the CN
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 22]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Correspondent Node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 3: One of Non-Primary Interfaces is attached to Home Link
have the binding entries listed in Figure 4 in their binding cache
database. The MN can not use the non-primary interface attached to a
foreign link unless a CN has a binding for the non-primary interface.
All packets which arrive at the HA are routed to one of interfaces
attached to the MN. The HA decides an interface anyway, for example,
by using policy and filters.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 23]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----------+ +--+-+
CoA2| | Home Link
+--+--+ --+----+---+------
| MN +===================+ |
+--+--+ |
| |
+---------------------------+
Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is inactive)
none
Correspondent Node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 4: Primary and Non-Primary Interfaces are
attached to Home Link
Acknowledgments
The authors would like to thank Julien Charbon, Susumu Koshiba,
Hiroki Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada,
Masafumi Watari (in alphabetical order), the nacm group at KEIO
University, and WIDE project for their contributions.
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] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo
Basic Support Protocol (work in progress). Internet Draft
(draft-ietf-nemo-basic-support-02), Internet Engineering Task
Force, December 2003.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 24]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
[4] T. Ernst. Nemo Mobility Support Goals and Requirements (work in
progress). Internet Draft (draft-ietf-nemo-requirements-01),
Internet Engineering Task Force, May 2003.
[5] Thierry Ernst, Nicolas Montavont, and Ryuji Wakikawa.
Goals and Benefits of Multihoming. Internet Draft
draft-multihoming-generic-goals-and-benefits-01, Internet
Engineering Task Force, April 2004. Work in progress.
[6] David B. Johnson, C. Perkins, and Jari Arkko. Mobility Support
in IPv6. Request For Comments 3775, Internet Engineering Task
Force, June 2004.
[7] J. Manner and M. Kojo. Mobility Related Terminology. Request
For Comments RFC3753, Internet Engineering Task Force, June
2004.
[8] M. Stemm and R. H. Katz. Vertical handoffs in wireless overlay
networks. Mobile Networks and Applications, 3(4):335--350,
1998.
[9] P. Thubert, R. Wakikawa, and V. Devarapalli. NEMO Home
Network models (work in progress). Internet Draft
(draft-ietf-nemo-home-network-models-00.txt), Internet
Engineering Task Force, May 2003.
[10] 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.
[11] 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 19 Dec 2004 [Page 25]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
Authors' Addresses
Ryuji Wakikawa Thierry Ernst
Keio University and WIDE Keio University and WIDE
5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa
252 JAPAN 252 JAPAN
Phone: +81-466-49-1394 Phone: +81-466-49-1394
EMail: ryuji@sfc.wide.ad.jp EMail: ernst@sfc.wide.ad.jp
Fax: +81-466-49-1395 Fax: +81-466-49-1395
Keisuke Uehara Kenichi Nagami
Keio University and WIDE INTEC NetCore
5322 Endo Fujisawa Kanagawa 1-3-3 Shinsuna Koto-ku Tokyo
252 JAPAN 135-0075 JAPAN
Phone: +81-466-49-1394 Phone: +81-3-5665-5069
EMail: kei@wide.ad.jp EMail: nagami@inetcore.com
Fax: +81-466-49-1395 FAX : +81-3-5665-5094
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 26]
Internet Draft Multiple Care-of Addresses Registration 19 Jun 2004
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 IETF's procedures with respect to rights in IETF 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 (2004). 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.''
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
R. Wakikawa et.al. Expires 19 Dec 2004 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-22 06:54:05 |