draft-ietf-monami6-multiplecoa-01.txt   draft-ietf-monami6-multiplecoa-02.txt 
Monami6 Working Group R. Wakikawa Monami6 Working Group R. Wakikawa
Internet-Draft Keio University Internet-Draft Keio University
Expires: April 4, 2007 T. Ernst Intended status: Standards Track T. Ernst
Keio University / WIDE Expires: September 6, 2007 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli
Azaire Networks
March 5, 2007
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-01.txt draft-ietf-monami6-multiplecoa-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several Care-of Addresses, but only one, termed the primary have several care-of addresses, but only one, termed the primary
Care-of Address, can be registered with its Home Agent and the care-of address, can be registered with its home agent and the
Correspondent Nodes. However, for matters of cost, bandwidth, delay, correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through etc, it is useful for the mobile node to get Internet access through
multiple access media simultaneously, in which case multiple active multiple access media simultaneously, in which case multiple active
IPv6 Care-of Addresses would be assigned to the mobile node. We thus IPv6 care-of addresses would be assigned to the mobile node. We thus
propose Mobile IPv6 extensions designed to register multiple Care-of propose Mobile IPv6 extensions designed to register multiple care-of
Addresses bound to a single Home Address instead of the sole primary addresses bound to a single Home Address instead of the sole primary
Care-of Address. For doing so, a new identification number must be care-of address. For doing so, a new identification number must be
carried in each binding for the receiver to distinguish between the carried in each binding for the receiver to distinguish between the
bindings corresponding to the same Home Address. Those extensions bindings corresponding to the same Home Address. Those extensions
are targeted to NEMO (Network Mobility) Basic Support as well as to are targeted to NEMO (Network Mobility) Basic Support as well as to
Mobile IPv6. Mobile IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7
3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 8 3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7
3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10
4.1. Binding Cache Structure and Management . . . . . . . . . . 11 4.1. Binding Cache Structure and Binding Update List . . . . . 10
4.2. Binding Update List Structure and Management . . . . . . . 11 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10
4.3. Message Format Changes . . . . . . . . . . . . . . . . . . 11 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10
4.3.1. Binding Unique Identifier sub-option . . . . . . . . . 11 4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 13
4.3.2. Binding Update . . . . . . . . . . . . . . . . . . . . 13
4.3.3. Binding Acknowledgment . . . . . . . . . . . . . . . . 13
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14
5.1. Management of Care-of Addresses and Binding Unique 5.1. Management of Care-of Addresses and Binding Unique
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14
5.3. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15
5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16
5.5. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16
5.6. Using Alternate Care-of Address . . . . . . . . . . . . . 17 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 5.7. Using Alternate care-of address . . . . . . . . . . . . . 18
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 18 5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18
5.9. Receiving Binding Error . . . . . . . . . . . . . . . . . 19 5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 19
5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20
5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20
6. Home Agent and Correspondent Node Operation . . . . . . . . . 20 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21
6.1. Searching Binding Cache with Binding Unique Identifier . . 20 6.1. Searching Binding Cache with Binding Unique Identifier . . 21
6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 20 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21
6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 22 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 23 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25
6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 23 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 24 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26
8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 25 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27
8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27
8.2. Transport Mode IPsec protected messages . . . . . . . . . 28
8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28
8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28
8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Configurations . . . . . . . . . . . . . . . 28 Appendix A. Example Configurations . . . . . . . . . . . . . . . 33
Appendix B. Changes From Previous Versions . . . . . . . . . . . 34 Appendix B. Changes From Previous Versions . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 41
1. Introduction 1. Introduction
Permanent Internet connectivity is required by some applications A mobile node should use various type of network interfaces to obtain
while a mobile node moves across several access networks (i.e. ISPs, durable and wide area network connectivity. Assumed scenarios and
hotspots, etc). Unfortunately, there is no network interfaces motivations for multiple points of attachment, and benefits for doing
assuring global scale connectivity. Therefore, a mobile node should it are discussed at large in [10].
use various type of network interfaces to obtain durable and wide
area network connectivity [8]. 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 scenarios and motivations for multiple points of
attachment, and benefits for doing it are discussed at large in [9].
Once multiple interfaces are available to a mobile node, a backup
interface can be used to recover from the loss of Internet
connectivity on the other interface, therefrom maintaining Internet
connectivity of wide spread and reach. In addition, each
communication flow could be sent to a distinct network interface,
providing efficient network bandwidth consumption. It becomes
possible for users to 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 the wired interface to avoid
disturbing TCP connections.
IPv6 [1] conceptually allows a node to have several addresses on a IPv6 [1] conceptually allows a node to have several addresses on a
given interface. Consequently, Mobile IPv6 [2] has mechanisms to given interface. Consequently, Mobile IPv6 [2] has mechanisms to
manage multiple ``Home Addresses'' based on Home Agent's managed manage multiple ``Home Addresses'' based on home agent's managed
prefixes such as mobile prefix solicitation and mobile prefix prefixes such as mobile prefix solicitation and mobile prefix
advertisement. But assigning a single Home Address to a given advertisement. But assigning a single Home Address to a node is more
network interface is more advantageous than assigning multiple Home advantageous than assigning multiple Home Addresses because
Addresses because applications do not need to be aware of the applications do not need to be aware of the multiplicity of Home
multiplicity of Home Addresses. Of course, applications should be Addresses. If multiple home addresses are available, applications
aware of the active Home Address to be used for communicating. At must reset the connection information when the mobile node changes
the TCP layer, TCP holds the Home Address as a source address of the its active network interface (i.e. change the Home Address).
communication for connection management. 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, 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. Moreover, since
NEMO Basic Support [3] is based on Mobile IPv6, the same issues
applies to a mobile node acting as mobile router.
According to the Mobile IPv6 specification, a mobile node is not
allowed to register multiple care-of addresses bound to a single Home
Address. Since NEMO Basic Support [3] is based on Mobile IPv6, the
same issues applies to a mobile node acting as mobile router.
Multihoming issues pertaining to mobile nodes operating Mobile IPv6 Multihoming issues pertaining to mobile nodes operating Mobile IPv6
and mobile routers operating NEMO Basic Support are respectively and mobile routers operating NEMO Basic Support are respectively
discussed [4] and [10] in Monami6 and NEMO Working Group. discussed [4] and [11] in Monami6 and NEMO Working Group.
In this document, we thus propose a new identification number called In this document, we thus propose a new identification number called
Binding Unique Identification (BID) number for each binding cache Binding Unique Identification (BID) number for each binding cache
entry to accommodate multiple bindings registration. We also propose entry to accommodate multiple bindings registration. The BID is
extension of binding cache management to store the BID and a new sub- assigned to either the interfaces or care-of addresses bound to a
option for binding update to carry the BID. The BID is assigned to single home address of a mobile node. The mobile node notifies the
either the interfaces or Care-of Addresses bound to a single home BID to both its Home Agent and correspondent nodes by means of a
address of a mobile node. The mobile node notifies the BID to both Binding Update. correspondent nodes and the home agent record the BID
its Home Agent and Correspondent Nodes by means of a Binding Update. into their binding cache. The Home Address thus identifies a mobile
Correspondent nodes and the Home Agent record the BID into their node itself whereas the BID identifies each binding registered by a
binding cache. The Home Address thus identifies a mobile node itself mobile node. By using the BID, multiple bindings can then be
whereas the BID identifies each binding registered by a mobile node. distinguished.
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. There are solutions available in Monami6 WG, for example
[11].
2. Terminology 2. Terminology
Terms used in this draft are defined in [2], [5] and [6]. In Terms used in this draft are defined in [2], [5] and [6]. In
addition or in replacement of these, the following terms are defined addition or in replacement of these, the following terms are defined
or redefined: or redefined:
Binding Unique Identification number (BID) Binding Unique Identification number (BID)
The BID is an identification number used to distinguish multiple The BID is an identification number used to distinguish multiple
skipping to change at page 7, line 37 skipping to change at page 6, line 37
must carefully assign the BID so as to keep using the same BID for must carefully assign the BID so as to keep using the same BID for
the same binding even when the status of the binding is changed. the same binding even when the status of the binding is changed.
More details can be found in Section 5.1. More details can be found in Section 5.1.
Binding Unique Identifier sub-option Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is used to carry the BID. The Binding Unique Identifier sub-option is used to carry the BID.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings by sending a binding A mobile node can register multiple bindings by sending a single
update. Several care-of addresses can be stored in a Binding binding update. The mobile node does not necessarily put all the
Update. The bulk registration is supported only for home available care-of addresses in the binding update, but several
registration. Note that a mobile node should not try to perform care-of addresses which can be stored in a Binding Update. The
bulk registration with Correspondent Nodes. bulk registration is supported only for home registration and
deregistration as explained in Section 5.5. Note that a mobile
node should not try to perform bulk registration with
correspondent nodes.
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 [7].
3. Protocol Overview 3. Protocol Overview
We propose a new identification number (BID) to distinguish multiple We propose a new identification number (BID) to distinguish multiple
bindings pertaining to the same Home Address. The procedures for the bindings pertaining to the same Home Address. The procedures for the
mobile node to register multiple bindings are described in the mobile node to register multiple bindings are described in the
paragraphs below. paragraphs below.
3.1. Multiple Care-of Addresses Registration 3.1. Multiple Care-of Addresses Registration
Once a mobile node gets several IPv6 global addresses on interfaces, Once a mobile node gets several IPv6 global addresses on interfaces,
it can register these addresses with its Home Agent (home it can register these addresses with its home agent (home
registration). If the mobile node wants to register multiple registration). If the mobile node wants to register multiple
bindings to its Home Agent, it MUST generate a BID for each Care-of bindings to its home agent, it MUST generate a BID for each care-of
Address and record it into the binding update list. The mobile node address and record it into the binding update list. The mobile node
then registers its Care-of Addresses by sending a Binding Update with then registers its care-of addresses by sending a Binding Update with
a Binding Unique Identifier sub-option. The BID MUST be put in the a Binding Unique Identifier sub-option. The BID MUST be put in the
Binding Unique Identifier sub-option. After receiving the Binding Binding Unique Identifier sub-option. After receiving the Binding
Update, the Home Agent verifies the request and records 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 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 the Binding Update, the home agent MUST copy the BID from the Binding
Update to the corresponding field in the binding entry. Even if Update to the corresponding field in the binding entry. Even if
there is already an entry for the mobile node, the Home Agent MUST there is already an entry for the mobile node, the home agent MUST
register a new binding entry for the BID stored in the Binding Unique register a new binding entry for the BID stored in the Binding Unique
Identifier sub-option. The mobile node registers multiple Care-of Identifier sub-option. The mobile node registers multiple care-of
Addresses either independently (in individual BUs) or multiple at addresses either independently (in individual BUs) or multiple at
once (in a single BU). once (in a single BU).
If the mobile node wishes to register its binding with a If the mobile node wishes to register its binding with a
Correspondent Node, it MUST start return routability operations correspondent node, it must operate return routability operations.
before sending a Binding Update. The mobile node MUST sends CoTI for The mobile node MUST manage a Care-of Keygen Token per care-of
each Care-of Addresses and MUST receive CoT for each Care-of address. If it is necessary (ex. Care-of Keygen token is expired),
Addresses. The mobile node also uses a BID generated for the home the mobile node exchanges CoTI and CoT for the releative care-of
registration to register them as individual bindings. The addresses. When the mobile node registers several care-of addresses
registration step is the same as for the home registration except for to a correspondent node, it uses the same BID as the one generated
calculating authenticator by using Binding Unique Identifier sub- for the home registration's bindings. The binding registration step
option as well as the other sub-options specified in RFC 3775. Since is the same as for the home registration except for calculating
return routability cannot be verified with multiple care-of addresses authenticator by using Binding Unique Identifier sub-option as well
in a binding update, bulk registration is not supported with as the other sub-options specified in RFC 3775. For simplicity, the
Correspondent Nodes in this document. bulk registration is not supported for correspondent nodes in this
document.
3.2. Multiple Bindings Management 3.2. Multiple Bindings Management
The BID is used as a search key for a corresponding entry in the The BID is used as a search key for a corresponding entry in the
binding cache in addition to the Home Address. When the Home Agent binding cache in addition to the Home Address. When a home agent and
checks the binding cache database for the mobile node, it searches a a correspondent node check the binding cache database for the mobile
corresponding binding entry with the Home Address and BID of the node, it searches a corresponding binding entry with the Home Address
desired binding. and BID of the desired binding. If necessary, a mobile node can use
policy and filter information to look up the best binding per
The desired binding can be selected with policy and filter sessions, flow, packets, but this is out of scope in this document
information. If a mobile node registers a binding with priority and is currently discussed in Monami6 WG.
value, the priority can be a key to select a binding. The capability
of searching the desired binding enables load-sharing and QoS with
flow separation. However, this selection and flow separation are
outside the scope of this document.
If there is no desired binding, it searches the binding cache If there is no desired binding, it searches the binding cache
database with the Home Address as specified in Mobile IPv6. The database with the Home Address as specified in Mobile IPv6. The
first matched binding entry may be found, although this is first matched binding entry may be found, although this is
implementation dependent. implementation dependent.
If a node has multiple bindings and its packets meant for the mobile When one of the care-of addresses has changed, the mobile node sends
node are not delivered correctly, the node can change the binding a Binding Update with the new care-of address and the corresponding
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. The receiver of the Binding Update updates the binding which
BID fits the BID contained in the received Binding Unique Identifier BID matches the BID contained in the received Binding Unique
sub-option. The mobile node can manage each binding independently Identifier sub-option. The mobile node can manage each binding
owing to BID. independently owing to BID.
If the mobile node decides to register only single binding, it just If the mobile node decides to act as a regular mobile node compliant
sends a Binding Update without a Binding Unique Identifier sub-option with [2] , it just sends a Binding Update without a Binding Unique
(i.e. normal Binding Update). The receiver of the Binding Update Identifier sub-option (i.e. normal Binding Update). The receiver of
registers only a single binding for the mobile node. If the receiver the Binding Update registers only a single binding for the mobile
has multiple bindings, one binding is registered without BID and the node and, if necessary, deletes all the bindings registering with a
rest of bindings are deleted. BID. Note that the mobile node can continue to use BID even if only
a single binding is active at some time.
3.3. Returning Home 3.3. Returning Home
When the mobile node returns home, there are two situations, since When the mobile node returns home, there are two situations, since
the Home Agent defends the mobile node's Home Address by using the the home agent defends the mobile node's Home Address by using the
proxy neighbor advertisement. It is impossible to utilize all the proxy neighbor advertisement. It is impossible to utilize all the
interfaces when one interface is attached to the home link and the interfaces when one interface is attached to the home link and the
others are attached to foreign links. If the proxy Neighbor others are attached to foreign links. If the proxy Neighbor
Advertisement for the Home Address is stopped, packets are always Advertisement for the Home Address is stopped, packets are always
routed to the interface attached to the home link. If proxy is not routed to the interface attached to the home link. If proxy is not
stopped, packets are never routed to the interface attached to the stopped, packets are never routed to the interface attached to the
home link. The decision whether a mobile node returns home or not is home link. The decision whether a mobile node returns home or not is
up to implementers. up to implementers.
The first situation is when a mobile node wants to return home with The first situation is when a mobile node wants to return home with
interface attached to the home link. In this case, the mobile node interface attached to the home link. In this case, the mobile node
MUST de-register all the bindings by sending a Binding Update with 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 lifetime set to zero. The mobile node MAY NOT put any Binding Unique
Identifier sub-option in this packet. Then, the receiver deletes all Identifier sub-option in this packet. Then, the receiver deletes all
the bindings from its binding cache database. the bindings from its binding cache database. A home agent MUST stop
proxy neighbor advertisement for the home address of the mobile node.
The second situation is when a mobile node does not want to return The second situation is when a mobile node does not want to return
home, though one of its interfaces is attached to its home link. The home, though one of its interfaces is attached to its home link. The
mobile node disables the interface attached to the home link and mobile node disables the interface attached to the home link and
keeps using the rest of interfaces attached to foreign links. In keeps using the rest of interfaces attached to foreign links. In
this case, the mobile node sends a de-registration Binding Update for this case, the mobile node sends a de-registration Binding Update for
the interface attached to the home link with the Binding Unique the interface attached to the home link with the Binding Unique
Identifier sub-option. The receiver of the de-registration Binding Identifier sub-option. The receiver of the de-registration Binding
Update deletes only the correspondent binding entry from the binding Update deletes only the relative binding entry from the binding cache
cache database. The Home Agent does not stop proxying neighbor database. The home agent does not stop proxying neighbor
advertisement as long as there are still bindings for the other advertisement as long as there are still bindings for the other
interfaces. interfaces. It is important to understand that this scenario is not
the most efficient because all the traffic from and to the mobile
node is going through the bi-directional tunnel, whereas the mobile
node is now accessible at one hop from its HA.
In the above two cases, a mobile node cannot use interfaces attached In the above two cases, a mobile node cannot use interfaces attached
to both home and foreign links simultaneously. If this is what a to both home and foreign links simultaneously. If this is what a
mobile node wants, a home agent can set up another link other than mobile node wants, a home agent can set up another link other than
home link and uses the link for the mobile node to return virtually home link and uses the link for the mobile node to return virtually
to home network. The detail can be found in Figure 7 to home network. Even though packets from and to the mobile node are
routed via the home agent, the hop count is kept in one. The
overhead should be negligible since it is only for an additional IPv6
header and processing tunnel (encapsulation and decapsulation) per
packets. The detail can be found in Figure 7
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
In this section are described the changes to Mobile IPv6 necessary to In this section are described the changes to Mobile IPv6 necessary to
manage multiple bindings bound to a same Home Address. manage multiple bindings bound to a same Home Address.
4.1. Binding Cache Structure and Management 4.1. Binding Cache Structure and Binding Update List
The following additional items are required in the binding cache
structure, i.e.:
BID of the Binding Cache Entry
The BID is notified by the mobile node by means of a Binding
Unique Identifier sub-option. The value MUST be zero if the
Binding Unique identifier does not appear in a Binding Update.
Priority of the Binding Cache Entry
The priority is notified by the mobile node by means of a Binding
Unique Identifier sub-option.
4.2. Binding Update List Structure and Management
The following additional items are required for the binding update The following additional items are required in the binding cache and
structure, i.e.: binding update list structure.
BID BID
The BID MUST be generated whenever the mobile node registers The value MUST be zero if the Binding Unique identifier does not
multiple bindings for its Home Address. appear in a Binding Update.
Priority Priority of the Binding Cache Entry
MUST be set if the priority field of a Binding Unique Identifier A value of zero indicates No Priority. A value of 255 indicates
is valid. that the binding corresponding to this BID is a default of this
mobile node. The detail can be found in Figure 1. This
information is used by [12].
4.3. Message Format Changes 4.2. Message Format Changes
4.3.1. Binding Unique Identifier sub-option 4.2.1. Binding Unique Identifier sub-option
If needed, the Binding Unique Identifier sub-option is included in The Binding Unique Identifier sub-option is included in the Binding
the Binding Update, Binding Acknowledgment, Binding Refresh Request, Update, Binding Acknowledgment, Binding Refresh Request, and Care-of
or Binding Error messages. Test Init and Care-of Test message.
1 2 3 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 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 | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) |Priority/Status|C|R| Reserved | | Binding Unique ID (BID) |Priority/Status|C|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
+ Care-of Address (CoA) + + care-of address (CoA) +
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Sub-Option Figure 1: BID Sub-Option
Type Type
Type value for Binding Unique Identifier will be assigned later. Type value for Binding Unique Identifier will be assigned later.
Length Length
Length value is 4 when the C flag is unset. Length value is 20 Length value MUST be 4 when C flag is unset. On the other hand if
when the C flag is set. C flag is set, Length value MUST be set to 20.
Binding Unique ID (BID) Binding Unique ID (BID)
The BID which is assigned to the binding carried in the Binding The BID which is assigned to the binding carried in the Binding
Update with this sub-option. BID is 16-bit unsigned integer. A Update with this sub-option. BID is 16-bit unsigned integer. A
value of zero is reserved. value of zero is reserved.
Priority/Status Priority/Status
When the Binding Unique Identifier sub-option is included in a When the Binding Unique Identifier sub-option is included in a
Binding Update, this field indicates the priority field assigned Binding Update, this field indicates the priority field assigned
to each binding. The receiver can utilize this priority to to each binding. The receiver can utilize this priority to
determine which binding is used to deliver packets. The priority determine which binding is used to deliver packets. The priority
is 8-bit unsigned integer. The higher value has higher priority. is 8-bit unsigned integer. The higher value has higher priority.
Values of zero and 255 are reserved for specific meaning. Values of zero and 255 are reserved for special meaning.
A value of zero indicates No Priority. A value of 255 indicates A value of zero indicates No Priority. A value of 255 indicates
that the binding corresponding to this BID is a default of this that the binding corresponding to this BID is a default of this
mobile node. This default binding is used by the flow binding mobile node. This default binding is used by the flow binding
scheme [11]. If the receiver cannot recognize 255, it MUST ignore scheme [12]. If the receiver cannot recognize 255, it MUST ignore
this field. this field.
When the Binding Unique Identifier sub-option is included in a When the Binding Unique Identifier sub-option is included in a
Binding Acknowledgment, this field indicates the status Binding Acknowledgment, this field indicates the status
correspondent to each binding in a bulk registration mode. The correspondent to each binding. The mobile node knows the
mobile node can know the registration status of each binding. The registration status of each binding. The status is 8-bit unsigned
status is 8-bit unsigned integer. The possible status codes are integer. The possible status codes are listed below. If the
listed below. If the status field is below 128, it indicates that status field is below 128, it indicates that the binding
the binding registration was successful. registration was successful.
ACCEPTING BID SUBOPTION (0) MCOA ACCEPTING BID (0)
The registration of the correspond binding is successfully The registration of the correspond binding is successfully
operated. operated.
INCOMPLIANT BID SUBOPTION (128) MCOA REASON UNSPECIFIED (128)
Registration failed because of unknown errors
MCOA INCOMPLIANT (129)
Registration failed because Binding Unique Identifier sub- Registration failed because Binding Unique Identifier sub-
option is not compliant. option is not compliant.
Care-of Address (C) flag MCOA BID CONFLICT (130)
It indicates that a regular binding (ie without the BID set) is
already registered for the home address, and is conflicting
with a received Binding Update which BID was set.
MCOA BULK REGISTRATION PROHIBITED (131)
The C flag can be set only if a Binding Unique Identifier sub-
option is presented only in a Binding Update or a Binding
Acknowledgment.
care-of address (C) flag
When this flag is set, a mobile node can store a Care-of Address When this flag is set, a mobile node can store a Care-of Address
correspondent to BID in the Binding Unique Identifier sub-option. corresponding to the BID in the Binding Unique Identifier sub-
This flag must be used whenever a mobile node sends multiple option. This flag must be used whenever a mobile node sends
bindings in a single Binding Update, i.e. bulk registration. multiple bindings in a single Binding Update, i.e. bulk
registration.
Removable (R) flag Overwrite (O) flag
When this flag is set, a mobile node request a Home Agent to When this flag is set, a mobile node requests a home agent to
remove the binding correspondent to BID, even if the binding replace all the bindings to binding entries stored in a Binding
update is not for de-registration. This flag is valid only when Update. This flag is valid for Home Registration and
bulk registration is used (C flag is set). Deregistration.
Reserved Reserved
6 bits Reserved field. Reserved field must be set with all 0. 6 bits Reserved field. Reserved field must be set with all 0.
4.3.2. Binding Update Care-of Address
No modification to Binding Update. A mobile node stores a Binding Only when C flag is set, only a single Care-of Address matched to
Unique Identifier option in the Mobility Options field of a Binding the BID is stored. This field is valid only if a Binding Unique
Identifier sub-option is stored in Binding Update message.
Otherwise, this field can be omitted. The receiver SHOULD ignore
this field if the sub-option is presented in other than Binding
Update. Update.
4.3.3. Binding Acknowledgment 4.2.2. Binding Acknowledgment
The message format of Binding Acknowledgment is not changed, but The message format of Binding Acknowledgment does not change, but
operations listed below are added in this draft. operations listed below are added in this draft.
A receiver who gets a Binding Update with a Binding Unique Identifier If a Binding Unique Identifier sub-option is included in a Binding
option MUST reply with a Binding Acknowledgment if the A flag is also Update with the A flag set, a receiver MUST reply a Binding
set. The receiver MUST also send a Binding Acknowledgment with Acknowledgment. The receiver node MUST include the same Binding
corresponding error codes if it finds an error while processing the Unique Identifier sub-option(s) in the Binding Acknowledgment. The
Binding Update and its sub-option described in section Section 4.3. receiver MUST specify relative status in the Status field of the
Binding Acknowledgment.
If a Binding Update has a Binding Unique Identifier sub-option is There are two status fields: the Status field of a Binding
present, the receiver node MUST reply with a Binding Acknowledgment Acknowledgment and the Status field of a Binding Unique Identifier
containing the same Binding Unique Identifier sub-option(s). There sub-option. In this specification, the Status field of a Binding
are two status fields of multiple care-of address registration: one Acknowledgment indicates the registration status of a "Binding
in Binding Acknowledgment and another in Binding Unique Identifier Update". The status value in the Binding Acknowledgment is for all
sub-option. The first field indicates the general registration Binding Unique Identifier sub-options stored in the Binding
status and the latter field gives detail registration information for Acknowledgment. For example, if the status value is 134 in the
each binding. The latter field is often used to indicate status status field of the Binding Acknowledgment, all the care-of addresses
information for multiple bindings stored in a single binding update stored in the Binding Unique Identifier sub-options are rejected
(i.e. bulk registration). New status values for the status field in because the duplicate address detection has failed on the home agent.
Binding Acknowledgment are defined for handling the multiple Care-of The status field of the Binding Unique Identifier sub-option only
Addresses registration: informs the receiver about the binding relative to the sub-option.
Whether each Care-of address has been successfully registered
successfully or not is given in the Status field of each Binding
Unique Identifier sub-option.
MCOA CONFLICT(144) New status values for the status field of a Binding Acknowledgment
are defined for handling the multiple Care-of Addresses registration:
It implies conflicting a regular binding and a binding that has MCOA PROHIBITED(TBD)
BID in binding cache. The regular binding indicates the binding
that does not have BID field. The status value is TBD.
BULK REGISTRATION FAIL (145) It implies the multiple care-of address registration is
administratively prohibited.
It implies that the bulk binding registration is failed. The MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
correspondent status which is defined in RFC3775 is stored in each
Binding Unique Identifier sub-option. The status value is TBD.
BULK REGISTRATION NOT SUPPORT (146) The bulk binding registration is not supported.
It implies that the bulk binding registration is not supported. MCOA FLAG CONFLICTS (TBD)
The mobile node can process the Binding Acknowledgment for the The flags of the sub-options presented in a Binding Update
particular Care-of Address identified by the BID set in the Binding conflicts.
Unique Identifier sub-option.
5. Mobile Node Operation 5. Mobile Node Operation
5.1. Management of Care-of Addresses and Binding Unique Identifier 5.1. Management of Care-of Addresses and Binding Unique Identifier
There are two cases when a mobile node has several Care-of Addresses: There are two cases when a mobile node has several Care-of Addresses:
1. A mobile node uses several physical network interfaces and 1. A mobile node uses several physical network interfaces and
acquires a Care-of Address on each of its interfaces. acquires a care-of address on each of its interfaces.
2. A mobile node uses a single physical network interface, but 2. A mobile node uses a single physical network interface, but
multiple prefixes are announced on the link the interface is multiple prefixes are announced on the link the interface is
attached to. Several global addresses are configured on this attached to. Several global addresses are configured on this
interface for each of the announced prefixes. interface for each of the announced prefixes.
The difference between the above two cases is only a number of The difference between the above two cases is only a number of
physical network interfaces and therefore does not matter in this physical network interfaces and therefore does not matter in this
document. The Identification number is used to identify a binding. document. The Identification number is used to identify a binding.
To implement this, a mobile node MAY assign an identification number To implement this, a mobile node MAY assign an identification number
for each Care-of Addresses. How to assign an identification number for each care-of addresses. How to assign an identification number
is up to implementers. is up to implementers.
A mobile node assigns a BID to each Care-of Address when it wants to 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 register them simultaneously with its Home Address . The value
generated from a value comprised between 1 to 65535. Zero and should be generated from a value comprised between 1 to 65535. Zero
negative value MUST NOT be taken as a BID. If a mobile node has only and negative values MUST NOT be taken as a BID. If a mobile node has
one Care-of Address, the assignment of a BID is not needed until it only one care-of address, the assignment of a BID is not needed until
has multiple Care-of Addresses to register with. it has multiple care-of addresses to register with.
5.2. Binding Registration 5.2. Return Routability: Sending CoTI and Receiving CoT
When a mobile node wants to register bindings to a Correspondent
Node, it MUST send a CoTI per care-of address, while the HoTI and HoT
can be exchanged only once for a Home Address. If the Mobile Node
manages bindings with BID, it MUST include a Binding Unique
Identifier sub-option in a Care-of Test Init message. It MUST NOT
set the C and O flag in the sub-option.
The receiver (i.e. correspondent node) will calculate a care-of
keygen token with the received BID and reply a Care-of Test message
which contains a Binding Unique Identifier sub-option as described in
Section 6.2. When the mobile node receives the Care-of Test message,
the Care-of Test message is verified as same as in [2] and the
Binding Unique Identifier sub-option in the Care-of Test MUST be
processed as follows:
o If a Binding Unique Identifier sub-option is not presented in CoT
in reply to the CoTI containing the Binding Unique Identifier sub-
option, a correspondent node does not support the Multiple Care-of
Address registration. Thus, the mobile node MUST NOT use a
Binding Unique Identifier sub-option in the Binding Update. It
MUST send a regular Binding Update (i.e. no BID) to the
correspondent node [2]. The Mobile Node MAY skip resending
regular CoTI message and use the received care-of keygen token for
the regular Binding Update, because the correspondent node just
ignores and skip the Binding Unique Identifier sub-option and
calculates the care-of keygen token as [2] specified.
o If the status field of a Binding Unique Identifier sub-option is
set to [MCOA BULK REGISTRATION PROHIBITED], the care-of keygen
token MUST NOT be used for a Binding Update. It MUST re-send a
Care-of Test Init message again with a corrected Binding Unique
Identifier sub-option (i.e. C flag MUST be unset).
o If the status field is set to less than 128, it sends a Binding
Update through Return Routability procedure.
The computation of MAC is the same as the one in [2] except for
calculation of a care-of keygen token. The calculation of a care-of
keygen token is modified as follows. BID is used to generate the
care-of keygen token.
care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
nonce | BID | 1)))
5.3. Binding Registration
When a mobile node sends a Binding Update, it MUST decide whether it When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple Care-of Addresses or not. However, this decision registers multiple care-of addresses or not. However, this decision
is out-of scope in this document. If a mobile node decides not to is out-of scope in this document. If a mobile node decides not to
register multiple Care-of Addresses, it completely follows standard register multiple care-of addresses, it completely follows the
RFC 3775 specification. standard RFC 3775 specification.
If the mobile node needs to register multiple Care-of Addresses, it If a mobile node needs to register multiple Care-of Addresses, it
MUST use BIDs to identify a Care-of Address. The mobile node puts a MUST use BID to identify a care-of address. The mobile node includes
Binding Unique Identifier sub-option into the Option field of the a Binding Unique Identifier sub-option in the Mobility Option field
Binding Update. The BID is copied from a Binding Update List to the of a Binding Update. The BID is copied from a corresponding Binding
Binding Unique Identifier sub-option. No flag in the Binding Unique Update List entry to the BID field of the Binding Unique Identifier
Identifier sub-option should be set for independent binding sub-option. If the mobile node wants to replace existing registered
registration. bindings on the home agent to the binding entry(s) in the Binding
Update, it can set O flag.
If the mobile node registers bindings to a Correspondent Node, it If a mobile node registers bindings to a correspondent node, it MUST
MUST sends multiple CoTIs for multiple Care-of Addresses. After have both active home and care-of keygen tokens for Kbm (see Section
getting CoTs, it sends Binding Updates with a Binding Unique 5.2.5 of [2]. The care-of keygen tokens MUST be maintained for each
Identifier sub-option for all Care-of Addresses. In any case, the care-of address that the mobile node wants to register to the
mobile node MUST set the A flag in Binding Updates and MUST wait for correspondent node, as described in Section 5.2. After computing an
a Binding Acknowledgment to confirm the registration was successful Authenticator value, it sends a Binding Update which contains a
as described in section Section 5.7. Binding Unique Identifier sub-option. The Binding Update is
protected by a Binding Authorization Data sub-option placed after the
Binding Unique Identifier sub-option. The Mobile Node MUST NOT set
the C flag in the Binding Unique Identifier sub-option.
5.3. Binding Bulk Registration 5.4. Binding Bulk Registration
This bulk registration is an optimization for registering multiple The bulk registration is an optimization for registering multiple
Care-of Addresses only to a Home Agent by using a single Binding care-of addresses only to a home agent by using a single Binding
Update, although the current Mobile IPv6 specification does not allow Update. If a mobile node, for instance, does not want to send a lot
to send multiple bindings by means of a single Binding Update. In of control messages through an interface which bandwidth is scarce,
this case, a mobile node sets the C flag into a Binding Unique it can use this bulk registration and send a Binding Update
Identifier sub-option and stores the particular Care-of Address in containing multiple or all the valid care-of addresses from a
the Binding Unique Identifier sub-option. The mobile node can store specific interface which has wider bandwidth.
multiple sets of a Unique Binding Identifier sub-option in a Binding
Update. All the other binding information such as Lifetime, Sequence
Number, binding Flags are shared among the bulk Care-of Addresses.
Whether a mobile node registers multiple Care-of Addresses separately
or not is up to implementations.
If one of Care-of Address should be removed while the other Care-of In this case, a mobile node sets the C flag in a Binding Unique
Address must be updated, a mobile node can set the R flag in a Identifier sub-option and stores the particular care-of address in
Binding Unique Identifier sub-option correspondent to the removed the Binding Unique Identifier sub-option. When the C flag is set,
Care-of Address. When the R flag is set, the binding will be removed the length field of the suboption MUST be set to 20. The mobile node
from the binding cache of the Home Agent. Other bindings for which R can store multiple sets of a Binding Unique Identifier sub-option in
flag is unset will be registered or updated accordingly. a Binding Update. If the mobile node wants to replace existing
registered bindings on the home agent with the bindings in the sent
Binding Update, it can set O flag. Section 6.3 describes this
registration procedure in detail. In the bulk registration, all the
other binding information such as Lifetime, Sequence Number, binding
Flags are shared among the bulked Care-of Addresses. Whether a
mobile node registers multiple Care-of Addresses separately or in
bulk is up to implementations.
5.4. Binding De-Registration In the bulk registration, the Sequence Number field of a Binding
Update SHOULD be carefully configured. If each binding uses
different sequence number, a mobile node MUST use the largest
sequence number from the binding update list used for the bulk
registration. If it cannot select a sequence number for all the
bindings due to sequence number out of window, it MUST NOT use the
bulk registration for the binding which sequence number is out of
window and uses a separate Binding Update for the binding.
When a mobile node decides to delete all bindings for its home When multiple Binding Unique Identifier sub-options are presented,
address, it sends a regular de-registration Binding Update (i.e. the flag field of all the sub-options MUST have the same value. For
exclusion of a Binding Unique Identifier sub-option). See example, if C flag is set, the same flag MUST be set to all the sub-
Section 6.2 for details. options.
If a mobile node wants to delete a particular binding from its Home 5.5. Binding De-Registration
Agent and Correspondent Nodes (e.g. from foreign link), it MUST send
a Binding Update with lifetime is set to zero. If only single
Care-of Address is removed by a Binding Update, the mobile node
simply sets zero lifetime in a Binding Update and contains the single
correspondent Unique Binding Identifier Sub-option (C flag must be
unset). The receiver will remove only the Care-of Address which is
retrieved from the Source Address field of the IPv6 header. On the
other hand, if the mobile node wants to remove multiple Care-of
Addresses at once, it stores multiple Unique Binding Identifier sub-
options which C flag is set in a Binding Update. The Care-of
Addresses stored in the Binding Unique Identifier sub-options will
all be removed.
If a mobile node wants to remove a binding while it registers the When a mobile node decides to delete all the bindings for its home
other valid bindings, it can use R flag in a Binding Unique address, it sends a regular de-registration Binding Update. A
Identifier sub-option. The detailed operation can be found in Binding Unique Identifier sub-option is not required. See
Section 5.3. Section 6.3 for details.
5.5. Returning Home If a mobile node wants to delete a particular binding from its home
agent and correspondent nodes (e.g. from foreign link), the mobile
node simply sets zero lifetime or uses the home address as the source
address in a Binding Update. The Binding Update MUST contain a
relative Binding Unique Identifier Sub-option (C flag MUST NOT be
set). The receiver will remove only the care-of address that matches
the specified BID.
On the other hand, when a mobile node decides to return home (ie only
uses its interface attached to the home link), it MUST de-register
all the registered bindings. To do so, the mobile node stores
multiple Binding Unique Identifier sub-options in a Binding Update
which lifetime is set to zero or which source address is set to the
Home Address. C flag MUST be specified in all the Binding Unique
Identifier sub-options. The care-of addresses field of each sub-
option MAY be omitted, because the receiver will remove all the
care-of addresses which matches the specified BID.
O flag is always ignored if a Binding Update is for binding de-
registration
5.6. Returning Home
When a mobile node returns home, it MUST de-register all bindings When a mobile node returns home, it MUST de-register all bindings
with the Home Agent. with the home agent.
Although the mobile node MUST delete the bindings with Correspondent Although the mobile node SHOULD delete the bindings with
Nodes as well, the node can still keep the binding of the other Correspondent Nodes as well, the node MAY still keep the binding of
interface active attached to foreign links at the Correspondent the other interface active attached to foreign links only at the
Nodes. In such case, the mobile node still receives packets at the Correspondent Nodes. In such case, the mobile node still receives
other interface attached to a foreign link thanks to route packets at the other interface attached to a foreign link thanks to
optimization. The mobile node also receives packets at the interface route optimization. The mobile node also receives packets at the
attached to the home link when Correspondent Nodes does not use route interface attached to the home link when correspondent nodes does not
optimization. use route optimization.
Note that when the mobile node does not want to return home even if Note that when the mobile node does not want to return home even if
one of interfaces is attached to the home link, the mobile node MUST one of interfaces is attached to the home link, the mobile node MUST
disable the interface. Otherwise, address duplication will be disable the interface. Otherwise, address duplication will be
observed because the Home Agent still defend the Home Address by the observed because the home agent still defend the Home Address by the
proxy neighbor advertisement and the mobile node also enables the proxy neighbor advertisement and the mobile node also enables the
same Home Address on the home link. After disabling the interface same Home Address on the home link. After disabling the interface
attached to the home link, the mobile node MUST delete the binding attached to the home link, the mobile node MUST delete the binding
for the interface by sending a de-registration binding update. The for the interface by sending a de-registration binding update. The
de-registration binding update must be sent from one of active de-registration binding update must be sent from one of active
interfaces attached to foreign links. As a result, the mobile node interfaces attached to foreign links. As a result, the mobile node
no longer receives packets at the interface attached to the home no longer receives packets at the interface attached to the home
link. All packets are routed to other interfaces attached to a link. All packets are routed to other interfaces attached to a
foreign link. foreign link.
5.6. Using Alternate Care-of Address 5.7. Using Alternate care-of address
A mobile node can use an alternate Care-of Address in the following
situations.
o One Care-of Address becomes invalid (e.g because the link where it A mobile node can use an alternate care-of address in a following
is attached to is no longer available) and MUST be deleted. In situation. One care-of address becomes invalid (e.g because the link
such case, the mobile node can not send a Binding Update from the where it is attached to is no longer available) and MUST be deleted.
Care-of Address because the interface's link is lost. The mobile In such case, the mobile node can not send a Binding Update from the
node needs to de-register the remote binding of the Care-of care-of address because the interface's link is lost. The mobile
Address through one of its active Care-of Addresses. node needs to de-register the remote binding of the care-of address
through one of its active care-of addresses.
o A mobile node has multiple interfaces, but it wants to send In this case, the mobile node include both Alternate Care-of Address
Binding Updates for all Care-of Addresses from a specific sub-option and Binding Unique Identifier sub-option in a Binding
interface which has wider bandwidth depending on interface's Update. An Alternate care-of address sub-option can be presented
characteristics. A mobile node does not want to send a lot of only once in a Binding Update after a Binding Unique Identifier sub-
control messages through an interface which bandwidth is scarce. option. The care-of address stored in an Alternate Care-of address
sub-option is replaced the address in the source address field as
same as [2] specified.
In these cases, the mobile node sends a Binding Update with both If C flag is set in a Binding Unique Identifier sub-option, an
Alternate Care-of Address sub-option and Binding Unique Identifier Alternate Care-of Address sub-option SHOULD NOT be used. A receiver
sub-option. uses the care-of addresses and BID stored in each Binding Unique
Identifier sub-option to modify corresponding binding cache entries.
Any address can be specified in the Source address field of the IPv6
header of the Binding Update even without an Alternate Care-of
Address sub-option.
5.7. Receiving Binding Acknowledgment 5.8. Receiving Binding Acknowledgment
The verification of a Binding Acknowledgment is the same as in Mobile The verification of a Binding Acknowledgment is the same as in Mobile
IPv6 (section 11.7.3 of RFC 3775). The operation for sending a IPv6 (section 11.7.3 of RFC 3775). The operation for sending a
Binding Acknowledgment is described in Section 6.3. Binding Acknowledgment is described in Section 6.3.
If a mobile node sends a Binding Update with a Binding Unique If a mobile node includes a Binding Unique Identifier sub-option in a
Identifier sub-option, a Binding Acknowledgment MUST have a Binding Binding Update with A flag set, a Binding Acknowledgment MUST have a
Unique Identifier sub-option in the Mobility options field. If there Binding Unique Identifier sub-option in the Mobility Options field.
is no such sub-option, the originator node of this Binding If no such sub-option appears in the Binding Acknowledgment replied
Acknowledgment might not recognize the Binding Unique Identifier sub- to the Binding Update for the multiple care-of address registration,
option. The mobile node SHOULD stop registering multiple Care-of this means that the originator node of this Binding Acknowledgment
Addresses by using a Binding Unique Identifier sub-option. If the might not recognize the Binding Unique Identifier sub-option. The
originator is the Home Agent, the mobile node MAY try to discover a mobile node SHOULD stop registering multiple care-of addresses by
new Home Agent supporting the multiple Care-of Address registration using a Binding Unique Identifier sub-option. If the originator is
or give up with the multiple Care-of Address registration. the home agent, the mobile node MAY try to discover a new home agent
supporting the multiple care-of address registration or give up with
the multiple care-of address registration.
If a Binding Unique Identifier sub-option is present, the mobile node If a Binding Unique Identifier sub-option is present in the received
checks the Status field of the Binding Acknowledgment. If the status Binding Acknowledgment, the mobile node checks the Status field of
code indicates successful registration (below 128), the originator the Binding Acknowledgment. If the status code indicates successful
successfully registered the binding information and BID for the registration (less than 128), the originator successfully registered
mobile node. the binding information and BID for the mobile node.
If the status code is not zero and Binding Unique Identifier sub- If the status code of the Binding Acknowledgment is greater than or
option is in the Binding Acknowledgment, the mobile node proceeds equal to 128, the mobile node proceeds with relevant operations
with relevant operations according to the status code. according to the status code of the Binding Acknowledgment. The
status value of the stored Binding Unique Identifier sub-option may
be used to decide further operation.
If the status code is 144, the mobile node has already registered a o If the Status value of the Binding Acknowledgment is [MCOA
regular binding before sending a Binding Update with a Binding Unique PROHIBITED], the mobile node MUST give up registering multiple
Identifier sub-option. In such case, the mobile node SHOULD stop bindings to the peer sending the Binding Acknowledgment. It MUST
sending Binding Updates without BID or SHOULD stop sending Binding return to the regular Mobile IPv6 [2] for the peer node.
Updates with BID.
If the status code is 145, the mobile node should check the status o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
field of Binding Unique Identifier sub-option for the detail mobile node SHOULD stop using bulk registration to the peer
information. After correcting errors, the mobile node can re- sending the Binding Acknowledgment.
register only the failed binding in separate registration or bulk
registration mode.
5.8. Receiving Binding Refresh Request o If [MCOA FLAG CONFLICTS] is specified in the Binding
Acknowledgment, it indicates that the different flag values are
used in Binding Unique Identifier sub-options in a Binding Update.
If the C flag is set, all sub-options MUST have C flag. It is
same for O flag. How to handle other error status codes is
specified in [2].
The mobile node also learn detailed registration status from the
Status field of each Binding Unique Identifier sub-option. If the
value is greater than or equal to 128, the mobile node proceeds with
relevant operations according to the status value.
o If [MCOA BID CONFLICT] is specified, the binding entry specified
by the Binding Unique Identifier sub-option is already registered
as a regular binding. In such case, the mobile node SHOULD stop
sending Binding Updates with BID, or SHOULD use O flag for the
peer sending the Binding Acknowledgment.
5.9. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a
Binding Refresh Request is described in section Section 6.4. Binding Refresh Request is described in section Section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding If a mobile node receives a Binding Refresh Request with a Binding
Unique Identifier sub-option, this Binding Refresh Request requests a Unique Identifier sub-option, this Binding Refresh Request requests a
binding indicated by the BID. The mobile node SHOULD update only the binding indicated by the BID. The mobile node SHOULD update only the
respective binding. The mobile node MUST put a Binding Unique respective binding. The mobile node MUST put a Binding Unique
Identifier sub-option into a Binding Update. Identifier sub-option into the Binding Update sent to refresh the
entry.
If no Binding Unique Identifier sub-option is present in a Binding If no Binding Unique Identifier sub-option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according to Refresh Request, the mobile node sends a Binding Update according to
its Binding Update List for the requesting node. On the other hand, its Binding Update List for the requesting node. On the other hand,
if the mobile node does not have any Binding Update List entry for if the mobile node does not have any Binding Update List entry for
the requesting node, the mobile node needs to register either a the requesting node, the mobile node needs to register either a
single binding or multiple bindings depending on its binding single binding or multiple bindings depending on its binding
management policy. management policy.
5.9. Receiving Binding Error 5.10. Sending Packets to Home Agent
When a mobile node receives a Binding Error with a Binding Unique When a multihomed mobile node sends packets to its home agent, there
Identifier sub-option, the message is for a binding indicated by the are conceptually two ways to construct packets.
BID in the Binding Unique Identifier sub-option. Further operations
except for the text below are identical as in RFC 3775. The
operation for sending BE is described in the section Section 6.5.
When a mobile node receives a Binding Error with Status field set to 1. Using Home Address Option. (required additional 24 bytes)
2 (Unrecognized MH Type value), it MAY stop trying to register
multiple Care-of Addresses and registers only primary Care-of Address 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes)
as performed in Mobile IPv6.
Beside the additional size of packets, no difference is observed
between these two. The routing path is always the same and no
redundant path such as dog-leg route or triangular route occurs.
However, in this document, the mobile node is capable of using
multiple care-of addresses for outgoing packets. This is problem in
home agent side because they must verify the Care-of address for all
the packets received from the mobile node. Therefore, the mobile
node SHOULD use the bi-directional tunnel even if it registers a
binding(s) to the home agent. When it uses the Home Address option,
the home agent MAY reject the packets because the Care-of address in
the packet and the first found Care-of Address in the binding Cache
of the home agent are different. The mobile node then receive
Binding Error for the packet drop.
5.11. Bootstrapping
When a mobile node bootstraps and registers multiple bindings at the
first time, it SHOULD set O flag in the Binding Unique Identifier
sub-option. when old bindings still exists at the Home Agent and
Correspondent Nodes, the mobile node has no way to verify which
bindings are left as a garbage in those nodes. This scenario happens
when a mobile node reboots without correct deregistration. If O flag
is used, all the bindings are replaced to the new binding(s). Thus,
the garbage bindings are surely removed by the first Binding Update.
XXX SEQ
6. Home Agent and Correspondent Node Operation 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Unique Identifier 6.1. Searching Binding Cache with Binding Unique Identifier
If either a Correspondent Node or a Home Agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. How to select the the bindings to communicate with the mobile node. How to select the
most suitable binding from the binding cache database is out of scope most suitable binding from the binding cache database is out of scope
in this document. in this document.
Whenever a Correspondent Node searches a binding cache for a home Whenever a correspondent node searches a binding cache for a home
address, it SHOULD uses both the Home Address and the BID as the address, it SHOULD uses both the Home Address and the BID as the
search key if it knows the corresponding BID. If the priority is search key if it knows the corresponding BID. If the priority is
available for a binding cache entry, the priority can be used as available for a binding cache entry, the priority can be used as
additional key to search a binding. In the example below, if a additional key to search a binding. In the example below, if a
Correspondent Node searches the binding with the Home Address and correspondent node searches the binding with the Home Address and
BID2, it gets binding2 for this mobile node. BID2, it gets binding2 for this mobile node.
binding1 [a:b:c:d::EUI, Care-of Address1, BID1] binding1 [a:b:c:d::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, Care-of Address2, BID2] binding2 [a:b:c:d::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, Care-of Address3, BID3] binding3 [a:b:c:d::EUI, care-of address3, BID3]
Figure 2: Searching the Binding Cache Figure 2: Searching the Binding Cache
A Correspondent Node basically learns the BID when it receives a A correspondent node basically learns the BID when it receives a
Binding Unique Identifier sub-option. At the time, the Correspondent Binding Unique Identifier sub-option. At the time, the correspondent
Node MUST look up its binding cache database with the Home Address node MUST look up its binding cache database with the Home Address
and the BID retrieved from Binding Update. If the Correspondent Node and the BID retrieved from the Binding Update. If the correspondent
does not know the BID, it searches for a binding with only a Home node does not know the BID, it searches for a binding with only a
Address as performed in Mobile IPv6. In such case, the first matched Home Address as performed in Mobile IPv6. In such case, the first
binding is found. But which binding entry is returned for the normal matched binding is found. But which binding entry is returned for
search depends on implementations. If the Correspondent Node does the normal search depends on implementations. If the correspondent
not desire to use multiple bindings for a mobile node, it can simply node does not desire to use multiple bindings for a mobile node, it
ignore the BID. can simply ignore the BID.
6.2. Receiving Binding Update 6.2. Receiving CoTI and Sending CoT
If a Binding Update does not have a Binding Unique Identifier, the When a correspondent node receives a Care-of Test Init message which
processing of the regular Binding Update is the same as in RFC 3775. contains a Binding Unique Identifier sub-option, it MUST process it
But if the receiver already has multiple bindings for the Home with following steps.
Address, it MUST overwrite all existing bindings for the mobile node
with the received binding. As a result, the receiver node MUST have First of all, the Care-of Test Init message is verified according to
only a binding for the mobile node. If the Binding Update is for de- [2]. The Binding Unique Identifier sub-option MUST be processed as
registration, the receiver MUST delete all existing bindings for the follows:
mobile node.
o If a correspondent node does not understand a Binding Unique
Identifier sub-option, it will ignore and skip this option. The
calculation of a care-of keygen token will thus be done without a
BID value. After regular processing of HoTI message according to
[2], it will return a Care-of Test message without use of a
Binding Unique Identifier sub-option. The mobile node can thus
know whether its correspondent can process or not the Binding
Unique Identifier sub-option by checking if such option is present
in the Care-of Test message.
o If C flag is set in the sub-option, the Correspondent Node SHOULD
NOT calculate a care-of keygen token and MUST include a Binding
Unique Identifier sub-option which status value set to [MCOA BULK
REGISTRATION PROHIBITED] in the returned Care-of Test message.
All the fields of the Care-of Test message MUST be set to zero.
All the Binding Unique Identifier sub-options SHOULD be copied
from the received one except for the Status Field and the Care-of
Address field.
o If O flag is set in the sub-option, the Correspondent Node can
ignore this flag and can process it as described in the next
bullet.
o Otherwise, the correspondent node MUST include a Binding Unique
Identifier sub-option which status value MUST be set to [MCOA
ACCEPTING BID] in the returning a Care-of Test message. The
Binding Unique Identifier sub-option SHOULD be copied from the
received one except for the Status Field and the Care-of address
Field.
The calculation of a care-of keygen token is modified as follows.
The BID is used to generate the care-of keygen token.
care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
nonce | BID | 1)))
6.3. Processing Binding Update
If a Binding Update does not contain a Binding Unique Identifier sub-
option, its processing is same as in RFC 3775. But if the receiver
already has multiple bindings for the Home Address, it MUST replace
all existing bindings by the received binding. As a 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 from its Binding Cache.
On the other hand, if a Binding Update contains a Binding Unique On the other hand, if a Binding Update contains a Binding Unique
Identifier sub-option(s), a receiver node MUST perform additional Identifier sub-option(s), the Binding Update is also validated
validations as follows: according to section 9.5.1 of [2] and the following step.
o A receiver node MUST validate the Binding Update according to o If the home flag is set in the Binding Update, the home agent MUST
section 9.5.1 of RFC 3775. carefully operate DAD for the received Home Address. If the home
agent has already had a binding(s) for the Mobile Node, it MUST
avoid running DAD when it receives the Binding Update.
o If a Binding Unique Identifier sub-option(s) is present, the If a Binding Unique Identifier sub-option(s) is present, the receiver
receiver node MUST process the sub-option. node MUST process the sub-option.
o If the C flag is unset in a Binding Unique Identifier sub- o The length value is examined. The length value MUST be either 4
option(s), the length field MUST be 4. Otherwise, the receiver or 20 depending on C flag. If the length is incorrect, the
MUST return the error code 128 in the status field of the Binding receiver MUST rejects the Binding Update and returns all the
Unique Identifier sub-option and send a Binding Acknowledgment received Binding Unique Identifier sub-option which status value
with status code set to 145 with the Binding Unique Identifier is set to [MCOA INCOMPLIANT]. The status field of the Binding
sub-option. When the length field is more than 4, the receiver Acknowledgment MUST be set to [REASON UNSPECIFIED, 128].
MAY process this sub-option by ignoring the rest of field beyond
the 4 octets (i.e. after Reserved field).
o If the Binding Unique Identifier sub-option is with the C flag set o When C flag is set, the receiver MUST support the bulk
and no care-of address is present in the sub-option, the receiver registration. Otherwise, it MUST reject the Binding Update and
node MUST set 128 in the Status field of the Binding Unique returns all the received Binding Unique Identifier sub-option
Identifier sub-option and send a Binding Acknowledgment with which status value is set to [MCOA REASON UNSPECIFIED]. The
status code set to 145 with the Binding Unique Identifier sub- status field of the Binding Acknowledgment MUST be set to [MCOA
option. If either a Correspondent Node or a Home Agent not BULK REGISTRATION NOT SUPPORTED].
supporting bulk registration receives the Binding Unique
Identifier sub-option with C flag set, it MUST return the error o When either C or O flag is set, the flags field of all the Binding
code 146 in a Binding Acknowledgment. Unique Identifier sub-option stored in the same Binding Update
MUST be equal. Otherwise, the receiver MUST reject the Binding
Update and returns all the received Binding Unique Identifier sub-
option which status value is set to [MCOA REASON UNSPECIFIED].
The status field of the Binding Acknowledgment MUST be set to
[MCOA FLAG CONFLICTS].
o When C flag is specified, the care-of address MUST be given in the
Binding Unique Identifier sub-option. Otherwise, the receiver
MUST reject the Binding Update and returns all the received
Binding Unique Identifier sub-option which status value is set to
[MCOA INCOMPLIANT]. The status field of the Binding
Acknowledgment MUST be set to [REASON UNSPECIFIED, 128].
o If the Lifetime field of the Binding Update is zero, the receiver
node deletes the 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 MUST reject this de-registration Binding
Update. If the receiver is a Home Agent, it SHOULD also return a
Binding Acknowledgment to the mobile node, in which the Status
field is set to [not Home Agent for this mobile node, 133]. If O
flag is set in the deregistering Binding Update, the receiver can
ignore this flag for deregistration.
o If the Lifetime field is not zero, the receiver node registers a o If the Lifetime field is not zero, the receiver node registers a
binding that includes the BID as a mobile node's binding. binding with the specified BID as a mobile node's binding. The
Care-of address is picked from the Binding Update packet as
follows:
* If the C flag is set in the Binding Unique Identifier sub- * If C flag is set in the Binding Unique Identifier sub-option,
option, the Care-of Address must be taken from the Care-of the care-of address must be taken from the care-of address
Address in the Binding Unique Identifier sub-option. field in each Binding Unique Identifier sub-option.
* If the C flag is not set in the Binding Unique Identifier sub- * If C flag is not set in the Binding Unique Identifier sub-
option, the Care-of Address must be taken from the Source option, the care-of address must be taken from the Source
Address field of the IPv6 header. Address field of the IPv6 header.
* If the C flag is not set and an alternate care-of address is * If C flag is not set and an alternate care-of address is
present, the care-of address is taken from the Alternate present, the care-of address is taken from the Alternate
Care-of Address sub-option. Care-of address sub-option.
* If the receiver does not have any binding for the mobile node, o Once the care-of address(es) has been retrieved from the Binding
it registers a binding which includes BID field. Update, it starts registering binding(s).
* Only if O flag is set in the sub-option, the home agent first
removes all the existing bindings and registers the received
bindings.
* If the receiver has a regular binding which does not have BID * If the receiver has a regular binding which does not have BID
for the mobile node, it de-registers the regular binding and for the mobile node, it de-registers the regular binding and
registers a new binding including BID according to the Binding registers a new binding including BID according to the Binding
Update. In this case, the receiver MUST send Binding Update. In this case, the receiver MUST specify [MCOA BID
Acknowledgment with status code set to 144. CONFLICT] to the Binding Unique Identifier sub-option which is
replied to the Mobile Node. The Status field of the replying
Binding Acknowledgment MUST be set to [Binding Update ACCEPTED,
0].
* If the receiver node has already registered the binding which * If the receiver node has already registered the binding which
BID is matched with requesting BID, then it MUST update the BID is matched with requesting BID, then it MUST update the
binding with the Binding Update. Meanwhile, if the receiver binding with the Binding Update.
does not have a binding entry which BID is matched with the
requesting BID, it registers a new binding for the BID.
* If the receiver node found R flag in a Binding Unique
Identifier sub-option, the C flag must be set. Otherwise, it
replies with 128 in a Binding Unique Identifier sub-option and
set 145 in a Binding Acknowledgment. The receiver node must
remove the binding correspondent to the Binding Unique
Identifier sub-option for which R flag is set.
o 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 MUST reject this de-registration Binding Update. If
the receiver is a Home Agent, it SHOULD also return a Binding
Acknowledgment to the mobile node, in which the Status field is
set to 133 (not Home Agent for this mobile node).
6.3. Sending Binding Acknowledgment
If a Binding Update does not contain a Binding Unique Identifier sub- * If the receiver does not have a binding entry which BID is
option, the receiver, either a Correspondent Node or a Home Agent, matched with the requesting BID, it registers a new binding for
MUST reply with a Binding Acknowledgment according to section 9.5.4 the BID.
of RFC 3775. Otherwise, whenever the Binding Unique Identifier sub-
option is present, 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 the Binding Update.
If the receiver successfully registers a binding for the BID stored If all the above operations are successfully finished, the Binding
in a Binding Unique Identifier sub-option, it returns a Binding Acknowledgment containing the Binding Unique Identifier sub-options
Acknowledgment with Status field set to successful value (0 to 128) MUST be replied to the mobile node if A flag is set in the Binding
and a Binding Unique Identifier sub-option copied from the received Acknowledgment. Whenever a Binding Acknowledgment is returned, all
Binding Update. If the receiver deletes an existing binding which the Binding Unique Identifier sub-options stored in the Binding
does not have a BID and registers a new binding for the BID, it MUST Update MUST be copied to the Binding Acknowledgment. The Care-of
return a Binding Acknowledgment with Status field set to 144. On the address field of each Binding Unique Identifier sub-option, however,
other hand, if the node encounters an error during the processing of can be omitted, because the mobile node can match a corresponding
a Binding Update, it must return a Binding Acknowledgment with an binding update list by using BID.
appropriate error number as described in RFC 3775. 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 6.4. Sending Binding Refresh Request
When either a Correspondent Node or Home Agent notices that a When either a correspondent node or home agent notices that a
registered binding will be expired soon, it MAY send a Binding registered binding will be expired soon, it MAY send a Binding
Refresh Request. If the registered binding has BID, the Refresh Request. If the registered binding has BID, the
Correspondent Node SHOULD contain a Binding Unique Identifier sub- correspondent node SHOULD contain a Binding Unique Identifier sub-
option in the Binding Refresh Request. Then, the Correspondent Node option in the Binding Refresh Request. Then, the Correspondent Node
can receive a Binding Update with a Binding Unique Identifier sub- can receive a Binding Update with a Binding Unique Identifier sub-
option and can update only the particular binding. If the registered option and can update only the particular binding. If the registered
binding does not have BID, then the Correspondent Node sends a binding does not have BID, then the correspondent node sends a
Binding Refresh Request without the sub-option. Binding Refresh Request without the sub-option.
6.5. Sending Binding Error 6.5. Receiving Packets from Mobile Node
When a Correspondent Node sends a Binding Error with Status field set
to 2 (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 When a correspondent node receives packets with a Home Address
destination option, it verifies the IPv6 source address field. If destination option from a mobile node, it MUST check that the care-of
the source address is not registered in the Correspondent Node's address appeared in the Source Address field MUST be equal to one of
binding cache, the Correspondent Node MUST return a Binding Error to the care-of addresses in the binding cache entry. If no binding is
the sender with the status set to zero (Unknown binding for Home found, the packets MUST be silently discarded and MUST send a Binding
Address destination option). The Correspondent Node MUST NOT put a Error message according to RFC3775. This verification MUST NOT be
Binding Unique Identifier sub-option, because there is no binding done for a Binding Update.
cache entry for the source address.
7. Network Mobility Applicability 7. Network Mobility Applicability
Support of multihomed mobile routers is advocated in the NEMO working Support of multihomed mobile routers is advocated in the NEMO working
group (see R12 "The solution MUST function for multihomed MR and group (see R12 "The solution MUST function for multihomed MR and
multihomed mobile networks" in [7] multihomed mobile networks" in [8].
Issues regarding mobile routers with multiple interfaces and other Issues regarding mobile routers with multiple interfaces and other
multihoming configurations are documented in [10]. multihoming configurations are documented in [11].
Since the binding management mechanisms are the same for a mobile Since the binding management mechanisms are the same for a mobile
host operating Mobile IPv6 and for a mobile router operating NEMO host operating Mobile IPv6 and for a mobile router operating NEMO
Basic Support (RFC 3963), our extensions can also be used to deal Basic Support (RFC 3963), our extensions can also be used to deal
with multiple Care-of Addresses registration sent from a multihomed with multiple care-of addresses registration sent from a multihomed
mobile router. mobile router.
8. IPsec and IKE interaction 8. IPsec and IKEv2 interaction
TBA Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to
protect signaling messages like Binding Updates, Binding
Acknowledgments and return routability messages. IPsec may also be
used protect all reverse tunneled data traffic. The Mobile IPv6-
IKEv2 specification [9] specifies how IKEv2 can be used to setup the
required IPsec security associations. The following assumptions were
made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with
respect to the use of IKEv2 and IPsec.
9. Conclusion o There is only one primary care-of address per mobile node.
In this document, we propose a solution to achieve multihomed mobile o The primary care-of address is stored in the IPsec database for
node on Mobile IPv6 and Network Mobility. A binding unique tunnel encapsulation and decapsulation.
identifier is introduced to register multiple care-of addresses to a
Home Agent and a Correspondent Node. Those care-of addresses are
bound to the same home address. A few modifications to Mobile IPv6
and NEMO are required to support multiple care-of address
registration.
10. Acknowledgments o When the home agent receives a packet from the mobile node, the
source address is verified against the care-of address in the
corresponding binding cache entry. If the packet is a reverse
tunneled packet from the mobile node, the care-of address check is
done against the source address on the outer IPv6 header. The
reverse tunnel packet could either be a tunneled HoTi message or
tunneled data traffic to the correspondent node.
o The mobile node runs IKEv2 (or IKEv1) with the home agent using
the care-of address. The IKE SA is based on the care-of address
of the mobile node.
The above assumptions may not be valid when multiple care-of
addresses are used by the mobile node. In the following sections,
the main issues with the use of multiple care-of address with IPsec
are addressed.
8.1. Use of Care-of Address in the IKEv2 exchange
For each home address the mobile node sets up security associations
with the home agent, the mobile node must pick one care-of address
and use that as the source address for all IKEv2 messages exchanged
to create and maintain the IPsec security associations associated
with the home address. The resultant IKEv2 security association is
created based on this care-of address.
If the mobile node needs to change the care-of address, it just sends
a Binding Update with the care-of address it wants to use, with the
corresponding Binding Unique Identifier sub-option, and with the 'K'
bit set. This will force the home agent to update the IKEv2 security
association to use the new care-of address. If the 'K' bit is not
supported on the mobile node or the home agent, the mobile node MUST
re-establish the IKEv2 security association with the new care-of
address. This will also result in new IPsec security associations
being setup for the home address.
8.2. Transport Mode IPsec protected messages
For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing.
For Mobile Prefix Discovery messages, RFC 3775 requires the home
agent to verify that the mobile node is using the care-of address
that is in the binding cache entry that corresponds to the mobile
node's home address. If a different address is used as the source
address, the message is silently dropped by the home agent. This
document requires the home agent implementation to process the
message as long as the source address is is one of the care-of
addresses in the binding cache entry for the mobile node.
8.3. Tunnel Mode IPsec protected messages
The use of IPsec in tunnel mode with multiple care-of address
introduces a few issues that require changes to how the mobile node
and the home agent send and receive tunneled traffic. The route
optimization mechanism described in RFC 3775 mandates the use of
IPsec protection in tunnel mode for the HoTi and HoT messages. The
mobile node and the home agent may also choose to protect all reverse
tunneled payload traffic with IPsec in tunnel mode. The following
sections address multiple care-of address support for these two types
of messages.
8.3.1. Tunneled HoTi and HoT messages
The mobile node MAY use the same care-of address for all HoTi
messages sent reverse tunneled through the home agent. The mobile
node may use the same care-of address irrespective of which
correspondent node the HoTi message is being sent. RFC 3775 requires
the home agent to verify that the mobile node is using the care-of
address that is in the binding cache entry, when it receives a
reverse tunneled HoTi message. If a different address is used as the
source address, the message is silently dropped by the home agent.
This document requires the home agent implementation to decapsulate
and forward the HoTi message as long as the source address is one of
the care-of addresses in the binding cache entry for the mobile node.
When the home agent tunnels a HoT message to the mobile node, the
care-of address used in the outer IPv6 header is not relevant to the
HoT message. So regular IPsec tunnel encapsulation with the care-of
address known to the IPsec implementation on the home agent is
sufficient.
8.3.2. Tunneled Payload Traffic
When the mobile sends and receives multiple traffic flows protected
by IPsec to different care-of addresses, the use of the correct
care-of address for each flow becomes important. Support for this
requires the following two considerations on the home agent.
o When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, it must check that the care-of
address is one of the care-of addresses in the binding cache
entry. According to RFC 4306, the IPsec implementation on the
home agent does not check the source address on the outer IPv6
header. Therefore the care-of address used in the reverse
tunneled traffic can be different from the care-of address used as
the source address in the IKEv2 exchange. However, the Mobile
IPv6 stack on the home agent MUST verify that the source address
is one of the care-of addresses registered by the mobile node
before decapsulating and forwarding the payload traffic towards
the correspondent node.
o For tunneled IPsec traffic from the home agent to the mobile node,
The IPsec implementation on the home agent may not be aware of
which care-of address to use when performing IPsec tunnel
encapsulation. The Mobile IP stack on the home agent must specify
the tunnel end point for the IPsec tunnel. This may require tight
integration between the IPsec and Mobile IP implementations on the
home agent.
9. Security Considerations
TBD
10. IANA Considerations
TBD
11. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation), The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti
Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen
(Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U),
Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U),
Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab. Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab.
at KEIO University, and WIDE project for their contributions. at KEIO University, and WIDE project for their contributions.
11. References 12. References
11.1. Normative References 12.1. Normative References
[1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", [1] Deering, S. and R. Hinden, "Internet Protocol Version 6
IETF RFC 2460, December 1998. (IPv6)", IETF RFC 2460, December 1998.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-00 (work in progress), draft-ietf-monami6-mipv6-analysis-02 (work in progress),
February 2006. February 2007.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", [5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress), draft-ietf-nemo-terminology-06 (work in progress),
February 2006. November 2006.
[7] Ernst, T., "Network Mobility Support Goals and Requirements", [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
draft-ietf-nemo-requirements-05 (work in progress), Levels", BCP 14, RFC 2119, March 1997.
October 2005.
11.2. Informative References [8] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-06 (work in progress),
November 2006.
[8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay [9] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
Networks", Journal Mobile Networks and Applications, vol. 3, IKEv2 and the revised IPsec Architecture",
number 4, pages 335-350, 1998. draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
December 2006.
[9] Ernst, T., "Motivations and Scenarios for Using Multiple 12.2. Informative References
[10] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-00 (work in draft-ietf-monami6-multihoming-motivation-scenario-01 (work in
progress), February 2006. progress), October 2006.
[10] Ng, C., "Analysis of Multihoming in Network Mobility Support", [11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming
draft-ietf-nemo-multihoming-issues-05 (work in progress), in Network Mobility Support",
February 2006. draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006.
[11] Soliman, H., "Flow Bindings in Mobile IPv6", [12] Soliman, H., "Flow Bindings in Mobile IPv6",
draft-soliman-monami6-flow-binding-02 (work in progress), draft-soliman-monami6-flow-binding-02 (work in progress),
September 2006. September 2006.
Appendix A. Example Configurations Appendix A. Example Configurations
In this section, we describe typical scenarios when a mobile node has In this section, we describe typical scenarios when a mobile node has
multiple network interfaces and acquires multiple Care-of Addresses multiple network interfaces and acquires multiple Care-of Addresses
bound to a Home Address. bound to a Home Address.
The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. 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 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 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each
Care-of Addresses. care-of address.
Figure 3 depicts the scenario where all interfaces of the mobile node Figure 3 depicts the scenario where all interfaces of the mobile node
are attached to foreign links. After binding registrations, the Home are attached to foreign links. After binding registrations, the home
Agent (HA) and the Correspondent Node (CN) have the binding entries agent (HA) and the Correspondent Node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize listed in their binding cache database. The mobile node can utilize
all the interfaces. all the interfaces.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+---+-+ +--+-+ | +----+---+-+ +--+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | | ------+------ +--+--+ | | ------+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
CoA3| | CoA3| |
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is active) 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 address1 BID1]
binding [a:b:c:d::EUI Care-of Address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI Care-of Address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Correspondent Node's binding correspondent node's binding
binding [a:b:c:d::EUI Care-of Address1 BID1] 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 address2 BID2]
binding [a:b:c:d::EUI Care-of Address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 3: Multiple Interfaces Attached to a Foreign Link Figure 3: Multiple Interfaces Attached to a Foreign Link
Figure 4 depicts the scenario where MN returns home with one of its Figure 4 depicts the scenario where MN returns home with one of its
interfaces. After the successful de-registration of the binding to interfaces. After the successful de-registration of the binding to
HA, HA and CN have the binding entries listed in their binding cache HA, HA and CN have the binding entries listed in their binding cache
database of Figure 4. MN can communicate with the HA through only database of Figure 4. MN can communicate with the HA through only
the interface attached to the home link. On the other hand, the the interface attached to the home link. On the other hand, the
mobile node can communicate with CN from the other interfaces mobile node can communicate with CN from the other interfaces
attached to foreign links (i.e. route optimization). Even when MN is attached to foreign links (i.e. route optimization). Even when MN is
attached to the home link, it can still send Binding Updates for attached to the home link, it can still send Binding Updates for
other active Care-of Addresses (CoA2 and CoA3). If CN has bindings, other active care-of addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface. arrived at HA are routed to the primary interface.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +--------+-+ +--+-+ | +--------+-+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
| MN +========+ | | | MN +========+ | |
+--+--+ | | | +--+--+ | | |
CoA3| +---|-----------+ CoA3| +---|-----------+
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
Correspondent Node's binding correspondent node's binding
binding [a:b:c:d::EUI Care-of Address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI Care-of Address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 4: One of Interface Attached to Home Link and Returing Home Figure 4: One of Interface Attached to Home Link and Returning Home
Figure 5 depicts the scenario where MN disables the interface Figure 5 depicts the scenario where MN disables the interface
attached to the home link and communicates with the interfaces attached to the home link and communicates with the interfaces
attached to foreign links. The HA and the CN have the binding attached to foreign links. The HA and the CN have the binding
entries listed in their binding cache database. MN disable the entries listed in their binding cache database. MN disable the
interface attached to the home link, because the HA still defends the interface attached to the home link, because the HA still defends the
home address of the MN by proxy neighbor advertisements. All packets 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 routed to the home link are intercepted by the HA and tunneled to the
other interfaces attached to the foreign link according to the other interfaces attached to the foreign link according to the
binding entries. binding entries.
skipping to change at page 31, line 21 skipping to change at page 36, line 21
| +----+-----+ +--+-+ | +----+-----+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
| | | |
+---------------------------+ +---------------------------+
(Disable interface) (Disable interface)
Binding Cache Database: Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is active) 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 address1 BID1]
binding [a:b:c:d::EUI Care-of Address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Correspondent Node's binding correspondent node's binding
binding [a:b:c:d::EUI Care-of Address1 BID1] 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 address2 BID2]
Figure 5: One of Interface Attached to Home Link and Not Returing Figure 5: One of Interface Attached to Home Link and Not Returning
Home Home
Figure 6 depicts the scenario where multiple interfaces of MN are Figure 6 depicts the scenario where multiple interfaces of MN are
attached to the home link. The HA and CN have the binding entries attached to the home link. The HA and CN have the binding entries
listed in Figure 6 in their binding cache database. The MN can not listed in Figure 6 in their binding cache database. The MN can not
use the interface attached to a foreign link unless a CN has a use the interface attached to a foreign link unless a CN has a
binding for the interface. All packets which arrive at the HA are binding for the interface. All packets which arrive at the HA are
routed to one of the MN's interfaces attached to the home link. routed to one of the MN's interfaces attached to the home link.
+----+ +----+
skipping to change at page 32, line 20 skipping to change at page 37, line 20
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----------+ +--+-+ | +----------+ +--+-+
CoA2| | Home Link CoA2| | Home Link
+--+--+ --+----+---+------ +--+--+ --+----+---+------
| MN +===================+ | | MN +===================+ |
+--+--+ | +--+--+ |
| | | |
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
Correspondent Node's binding correspondent node's binding
binding [a:b:c:d::EUI Care-of Address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 6: Several Interfaces Attached to Home Link and Returning Home Figure 6: Several Interfaces Attached to Home Link and Returning Home
Figure 7 depicts the scenario where interfaces of MN are attached to Figure 7 depicts the scenario where interfaces of MN are attached to
the foreign links. One of foreign link is managed by the home agent. the foreign links. One of foreign link is managed by the home agent.
The HA and CN have the binding entries listed in Figure 7 in their The HA and CN have the binding entries listed in Figure 7 in their
binding cache database. The home agent advertises a prefix which is binding cache database. The home agent advertises a prefix which is
other than home prefix. The mobile node will generate a care-of other than home prefix. The mobile node will generate a care-of
address from the prefix and registers it to the home agent. Even if address from the prefix and registers it to the home agent. Even if
the mobile node attaches to a foreign link, the link is managed by the mobile node attaches to a foreign link, the link is managed by
its home agent. It will tunnel the packets to the home agent, but its home agent. It will tunnel the packets to the home agent, but
the home agent is one-hop neighbor. The cost of tunnel is the home agent is one-hop neighbor. The cost of tunnel is
negligible. If the mobile node wants to utilize not only an negligible. If the mobile node wants to utilize not only an
interface attached to home but also interfaces attached to foreign interface attached to home but also interfaces attached to foreign
link, it can use this foreign link of the home agent to return home. link, it can use this foreign link of the home agent to return a one
This is different from the general returning home, but this enable hop foreign link on behalf of a home link. This is different from
the capability of using interfaces attached to both home and foreign the general returning home, but this enable the capability of using
link without any modifications to Mobile IPv6 and NEMO basic support. interfaces attached to both home and foreign link without any
modifications to Mobile IPv6 and NEMO basic support.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ ++-+-+ | +----+-----+ ++-+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | ----|-+------ +--+--+ | ----|-+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 ---+-+------ +--+--+ CoA1 ---+-+------
CoA3 | | Foreign Link CoA3 | | Foreign Link
+---------------------------+ +---------------------------+
(Disable interface)
Binding Cache Database: Binding Cache Database:
Home Agent's binding (Proxy neighbor advertisement is active) 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 address1 BID1]
binding [a:b:c:d::EUI Care-of Address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI Care-of Address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Correspondent Node's binding correspondent node's binding
binding [a:b:c:d::EUI Care-of Address1 BID1] 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 address2 BID2]
binding [a:b:c:d::EUI Care-of Address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 7: Emulating to Utilize Interfaces Attached to both Home and Figure 7: Emulating to Utilize Interfaces Attached to both Home and
Foreign Links Foreign Links
Appendix B. Changes From Previous Versions Appendix B. Changes From Previous Versions
Changes from draft-ietf-monami6-multiplecoa-00.txt Changes from draft-ietf-monami6-multiplecoa-01.txt
o Adding a default value for the BID priority field. This default
value is used by the flow binding scheme [11].
o Updating the text of BID definition. The older text was unclear o Updating the text of BID definition. The older text was unclear
whether a BID is assigned to a binding or a interface. It is now whether a BID is assigned to a binding or a interface. It is now
clearly defined that BID is assigned to each binding. clearly defined that BID is assigned to each binding.
o Removing R flag according to complexity.
o Introducing O (Overwrite) flag. This flag is useful when a MN
sends all the active CoAs to HA or CN all at once. It also useful
when a MN reboots and sends a first BU to HA and CN. see
Section 5.11 in detail.
o Removing the Binding Error texts, since there is no way to know
BID when BE is sent by CN.
o Clearing up the Status code of Binding Unique Identifier sub-
option and Binding Acknowledgment. Renewing the texts in
Section 6.3.
o Adding new section "Sending Packets to HA" and "Receiving Packets
from MN".
o adding how to handle correspondent nodes which do not support MCoA
extension in Section 5.2.
o Return routability is now extended to carry and use BID to
generate Authenticator. Section 6.2 and Section 5.2 are added.
o Adding a new section: IPsec and IKEv2 interaction.
o Shortening Introduction. We also remove several useless texts in
this doc.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Keio University Keio University
Department of Environmental Information, Keio University. Department of Environmental Information, Keio University.
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100 Phone: +81-466-49-1100
Fax: +81-466-49-1395 Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/ URI: http://www.wakikawa.org/
Thierry Ernst Thierry Ernst
Keio University / WIDE INRIA
Jun Murai Lab., Keio University. INRIA Rocquencourt
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Domaine de Voluceau B.P. 105
Kawasaki, Kanagawa 212-0054 Le Chesnay, 78153
Japan France
Phone: +81-44-580-1600 Phone: +33-1-39-63-59-30
Fax: +81-44-580-1437 Fax: +33-1-39-63-54-91
Email: ernst@sfc.wide.ad.jp Email: thierry.ernst@inria.fr
URI: http://www.sfc.wide.ad.jp/~ernst/ URI: http://www.nautilus6.org/~thierry
Kenichi Nagami Kenichi Nagami
INTEC NetCore Inc. INTEC NetCore Inc.
1-3-3, Shin-suna 1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075 Koto-ku, Tokyo 135-0075
Japan Japan
Phone: +81-3-5565-5069 Phone: +81-3-5565-5069
Fax: +81-3-5565-5094 Fax: +81-3-5565-5094
Email: nagami@inetcore.com Email: nagami@inetcore.com
Intellectual Property Statement Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 36, line 29 skipping to change at page 41, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 181 change blocks. 
624 lines changed or deleted 924 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/