draft-ietf-monami6-multiplecoa-04.txt   rfc5648.txt 
Monami6 Working Group R. Wakikawa (Editor) Network Working Group R. Wakikawa, Ed.
Internet-Draft Keio University Request for Comments: 5648 Toyota ITC
Intended status: Standards Track T. Ernst Category: Standards Track V. Devarapalli
Expires: May 22, 2008 INRIA Wichorus
G. Tsirtsis
Qualcomm
T. Ernst
INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli October 2009
Azaire Networks
November 19, 2007
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008.
Copyright Notice
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, called 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 accesses simultaneously, in which case the mobile node would
IPv6 care-of addresses would be assigned to the mobile node. We thus be configured with multiple active IPv6 care-of addresses. This
propose Mobile IPv6 extensions designed to register multiple care-of document proposes extensions to the Mobile IPv6 protocol to register
addresses bound to a single Home Address instead of the sole primary and use multiple care-of addresses. The extensions proposed in this
care-of address. For doing so, a new identification number must be document can be used by mobile routers using the NEMO (Network
carried in each binding for the receiver to distinguish between the Mobility) Basic Support protocol as well.
bindings corresponding to the same Home Address. Those extensions
are targeted to NEMO (Network Mobility) Basic Support as well as to
Mobile IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 Status of This Memo
4.1. Binding Cache Structure and Binding Update List . . . . . 10
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10
4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10
4.3. New Status Values for Binding Acknowledgment . . . . . . . 12
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 This document specifies an Internet standards track protocol for the
5.1. Management of Care-of Addresses and Binding Unique Internet community, and requests discussion and suggestions for
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 13 improvements. Please refer to the current edition of the "Internet
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 Official Protocol Standards" (STD 1) for the standardization state
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 and status of this protocol. Distribution of this memo is unlimited.
5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15
5.5. Binding De-Registration and Returning Home . . . . . . . . 16
5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 17
5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 18
5.8. Sending Packets to Home Agent . . . . . . . . . . . . . . 19
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 19
6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 Copyright and License Notice
6.1. Searching Binding Cache with Binding Unique Identifier . . 21
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 This document is subject to BCP 78 and the IETF Trust's Legal
8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 Provisions Relating to IETF Documents
8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 (http://trustee.ietf.org/license-info) in effect on the date of
8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28 publication of this document. Please review these documents
8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28 carefully, as they describe your rights and restrictions with respect
8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29 to this document. Code Components extracted from this document must
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 RFC 5648 MCoA October 2009
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 Table of Contents
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Configurations . . . . . . . . . . . . . . . 34 1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................4
4. Mobile IPv6 Extensions .........................................10
4.1. Binding Cache Structure and Binding Update List ...........10
4.2. Binding Update Message ....................................10
4.3. Binding Identifier Mobility Option ........................11
4.4. New Status Values for Binding Acknowledgement .............13
5. Mobile Node Operation ..........................................14
5.1. Management of Care-of Address(es) and Binding
Identifier(s) .............................................14
5.2. Binding Registration ......................................15
5.3. Bulk Registration .........................................16
5.4. Binding De-Registration ...................................16
5.5. Returning Home with Complete Binding
De-Registration: Using a Single Interface .................17
5.5.1. Using Only the Interface Attached to the
Home Link ..........................................17
5.5.2. Using Only the Interface Attached to the
Visited Link .......................................17
5.6. Returning Home: Simultaneous Home and Visited Link
Operation .................................................18
5.6.1. Problems of Simultaneous Home and Foreign
Attachments ........................................18
5.6.2. Overview and Approach ..............................18
5.6.3. Home Binding Support ...............................19
5.6.4. Sending Packets from the Home Link .................20
5.6.5. Leaving from the Home Link .........................20
5.7. Receiving Binding Acknowledgement .........................21
5.8. Receiving Binding Refresh Request .........................22
5.9. Bootstrapping .............................................22
6. Home Agent and Correspondent Node Operation ....................22
6.1. Searching Binding Cache with Binding Identifier ...........22
6.2. Processing Binding Update .................................23
6.3. Sending a Binding Acknowledgement for Home Link
Registration ..............................................25
6.4. Sending Binding Refresh Request ...........................27
6.5. Receiving Packets from Mobile Node ........................27
7. Network Mobility Applicability .................................27
8. DSMIPv6 Applicability ..........................................27
8.1. IPv4 Care-of Address Registration .........................28
8.2. IPv4 Home Address Management ..............................29
Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 RFC 5648 MCoA October 2009
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 9. IPsec and IKEv2 Interaction ....................................30
Intellectual Property and Copyright Statements . . . . . . . . . . 41 9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
9.2. Transport Mode IPsec-Protected Messages ...................31
9.3. Tunnel Mode IPsec-Protected Messages ......................31
9.3.1. Tunneled Home Test Init and Home Test Messages .....31
9.3.2. Tunneled Payload Traffic ...........................32
10. Security Considerations .......................................33
11. IANA Considerations ...........................................34
12. Acknowledgements ..............................................35
13. References ....................................................35
13.1. Normative References .....................................35
13.2. Informative References ...................................35
1. Introduction 1. Introduction
A mobile node should use various type of network interfaces to obtain A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. The assumed scenarios durable and wide area network connectivity. This has increasingly
and motivations for multiple points of attachment, and benefits for become true with mobile nodes having multiple interfaces, such as
doing it are discussed at large in [ID-MOTIVATION]. 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and
benefits of using multiple points of attachment are discussed in
IPv6 [RFC-2460] conceptually allows a node to have several addresses [MOTIVATION]. When a mobile node with multiple interfaces uses
on a given interface. Consequently, Mobile IPv6 [RFC-3775] has Mobile IPv6 [RFC3775] for mobility management, it cannot use its
mechanisms to manage multiple ``Home Addresses'' based on home multiple interfaces to send and receive packets while taking
agent's managed prefixes such as mobile prefix solicitation and advantage of session continuity provided by Mobile IPv6. This is
mobile prefix advertisement. But assigning a single Home Address to because Mobile IPv6 allows the mobile node to bind only one care-of
a node is more advantageous than assigning multiple Home Addresses address at a time with its home address. See [MIP6ANALYSIS] for a
because applications do not need to be aware of the multiplicity of further analysis of using multiple interfaces and addresses with
Home Addresses. If multiple home addresses are available, Mobile IPv6.
applications must reset the connection information when the mobile
node changes its active network interface (i.e. change the Home
Address).
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 [RFC-3963] is based on Mobile
IPv6, the same issues apply to a mobile node acting as a mobile
router. Multihoming issues pertaining to mobile nodes operating
Mobile IPv6 and mobile routers operating NEMO Basic Support are
respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6
and NEMO Working Group.
In this document, we thus propose a new identification number called This document proposes extensions to Mobile IPv6 to allow a mobile
Binding Unique Identification (BID) number for each binding cache node to register multiple care-of addresses for a home address and
entry to accommodate multiple bindings registration. The mobile node create multiple binding cache entries. A new Binding Identification
notifies the BID to both its Home Agent and correspondent nodes by (BID) number is created for each binding the mobile node wants to
means of a Binding Update. Correspondent nodes and the home agent create and is sent in the Binding Update. The home agent that
record the BID into their binding cache. The Home Address thus receives this Binding Update creates a separate binding for each BID.
identifies a mobile node itself whereas the BID identifies each The BID information is stored in the corresponding binding cache
binding registered by a mobile node. By using the BID, multiple entry. The BID information can now be used to identify individual
bindings can then be distinguished. bindings. The same extensions can also be used in Binding Updates
sent to the correspondent nodes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC2119].
Terms used in this draft are defined in [RFC-3775], [RFC-3753] and RFC 5648 MCoA October 2009
[RFC-4885]. In addition or in replacement of these, the following
terms are defined or redefined:
Binding Unique Identification number (BID) Terms used in this document are defined in [RFC3775], [RFC3753], and
[RFC4885]. In addition to or as a replacement of these, the
following terms are defined or redefined:
Binding Identification Number (BID)
The BID is an identification number used to distinguish multiple The BID is an identification number used to distinguish multiple
bindings registered by the mobile node. Assignment of distinct bindings registered by the mobile node. Assignment of distinct
BID allows a mobile node to register multiple binding cache BIDs allows a mobile node to register multiple binding cache
entries for a given Home Address. The BID is conceptually entries for a given home address. BIDs assigned to the same home
assigned to a binding in a way it cannot be duplicated with address must not be duplicated at the same time. The value zero
another BID. The zero value and a negative value MUST NOT be is reserved for future extensions. Each BID is generated and
used. After being generated by the mobile node, the BID is stored managed by a mobile node. The BID is stored in the Binding Update
in the Binding Update List and is sent by the mobile node by means List and is sent by the mobile node in the Binding Update. A
of a sub-option of a Binding Update. A mobile node MAY change the mobile node may change the value of a BID at any time according to
value of a BID at any time according to its administrative policy, its administrative policy -- for instance, to protect its privacy.
for instance to protect its privacy. An implementation must An implementation must carefully assign the BID so as to keep
carefully assign the BID so as to keep using the same BID for the using the same BID for the same binding even when the status of
same binding even when the status of the binding is changed. More the binding is changed. More details can be found in Section 5.1.
details can be found in Section 5.1.
Binding Unique Identifier sub-option Binding Identifier Mobility Option
The Binding Unique Identifier sub-option is used to carry the BID. The Binding Identifier mobility option is used to carry the BID
information.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings at once by sending a A mobile node can register multiple bindings at once by sending a
single binding update. The mobile node does not necessarily put single Binding Update. A mobile node can also replace some or all
all the available care-of addresses in the binding update, but of the bindings available at the home agent with the new bindings
several care-of addresses. A mobile node can also replace all the by using the bulk registration. Bulk registration is supported
bindings available at the home agent with the new bindings by only for home registration (i.e., with the home agent) as
using the bulk registration. The bulk registration is supported explained in Section 5.3. A mobile node must not perform the bulk
only for home registration and deregistration as explained in registration mechanism described in this specification with a
Section 5.5. A mobile node MUST NOT perform bulk registration correspondent node.
with correspondent nodes.
3. Protocol Overview 3. Protocol Overview
A new identification number (BID) is introduced to distinguish A new extension called the Binding Identification number (BID) is
multiple bindings pertaining to the same Home Address. Once a mobile introduced to distinguish between multiple bindings pertaining to the
node gets several IPv6 global addresses on interfaces, it can same home address. If a mobile node configures several IPv6 global
register these addresses with its home agent. If the mobile node addresses on one or more of its interfaces, it can register these
wants to register multiple bindings, it MUST generate a BID for each addresses with its home agent as care-of addresses. If the mobile
care-of address and record the BID into the binding update list. A node wants to register multiple bindings, it MUST generate a BID for
mobile node can manage each binding independently owing to BID. The each care-of address and store the BID in the Binding Update List. A
mobile node then registers its care-of addresses by sending a Binding mobile node can manipulate each binding independently by using the
Update with a Binding Unique Identifier sub-option. The BID MUST be BIDs. The mobile node then registers its care-of addresses by
included in the Binding Unique Identifier sub-option. After sending a Binding Update with a Binding Identifier mobility option.
receiving such Binding Update and Binding Unique Identifier sub-
option, the home agent MUST copy the BID from the Binding Unique RFC 5648 MCoA October 2009
Identifier sub-option to the corresponding field in the binding cache
entry. Even if there is already an entry for the mobile node's home The BID is included in the Binding Identifier mobility option. After
address, the home agent MUST register a new binding entry for the BID receiving the Binding Update with a Binding Identifier mobility
stored in the Binding Unique Identifier sub-option. The mobile node option, the home agent MUST copy the BID from the Binding Identifier
registers multiple care-of addresses either independently in mobility option to the corresponding field in the binding cache
individual Binding Updates or multiple at once in a single Binding entry. If there is an existing binding cache entry for the mobile
Update. node, and if the BID in the Binding Update does not match the one
with the existing entry, the home agent MUST create a new binding
cache entry for the new care-of address and BID. The mobile node can
either register multiple care-of addresses at once in a single
Binding Update or independently in individual Binding Updates.
If the mobile host wishes to register its binding with a If the mobile host wishes to register its binding with a
correspondent node, it must operate return routability operations. correspondent node, it must perform return routability operations as
The mobile host MUST manage a Care-of Keygen Token per care-of described in [RFC3775]. This includes managing a Care-of Keygen
address. If it is necessary (ex. Care-of Keygen token is expired), token per care-of address and exchanging Care-of Test Init and Care-
the mobile host exchanges CoTI and CoT for the relative care-of of Test messages with the correspondent node for each care-of
addresses. When the mobile host registers several care-of addresses address. The mobile node MAY use the same BID that it used with the
to a correspondent node, it uses the same BID as the one generated home agent for a particular care-of address. For protocol
for the home registration's bindings. The binding registration step simplicity, bulk registration to correspondent nodes is not supported
is the same as for the home registration except for calculating in this document. This is because the return routability mechanism
authenticator by using Binding Unique Identifier sub-option as well introduced in [RFC3775] cannot be easily extended to verify multiple
as the other sub-options specified in [RFC-3775]. For simplicity, care-of addresses stored in a single Binding Update.
the bulk registration is not supported for correspondent nodes in
this document. Figure 1 illustrates the configuration where the mobile node obtains
multiple care-of addresses at foreign links. The mobile node can
utilize all the care-of addresses. In Figure 1, the home address of
the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
different interfaces and possibly acquires care-of addresses 1-3
(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2, and BID3 to
each care-of address.
RFC 5648 MCoA October 2009
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
Figure 1: Multiple Care-of Addresses Registration
If the mobile node decides to act as a regular mobile node compliant If the mobile node decides to act as a regular mobile node compliant
with [RFC-3775] , it just sends a Binding Update without any Binding with [RFC3775], it sends a Binding Update without any Binding
Unique Identifier sub-options (i.e. normal Binding Update). The Identifier mobility options. The receiver of the Binding Update
receiver of the Binding Update deletes all the bindings registering deletes all the bindings registered with a BID and registers only a
with a BID and registers only a single binding for the mobile node. single binding for the mobile node. Note that the mobile node can
Note that the mobile node can continue to use BID even if only a continue using the BID even if it has only a single binding that is
single binding is active at some time. active.
The BID is used as a search key for a corresponding entry in the Binding cache lookup is done based on the home address and BID
binding cache in addition to the Home Address. When a home agent and information if a BID is available. This is different from RFC 3775,
a correspondent node check the binding cache database for the mobile where only the home address is used for binding cache lookup.
node, they search a corresponding binding entry with the Home Address Binding cache lookup is operated for either protocol signaling or
and BID of the desired binding. If necessary, a mobile node can use data packets. For protocol signaling such as a Binding Update, BID
policy and filter information to look up the best binding per should be always carried by a BID sub-option in a protocol signaling.
sessions, flow, packets, but this is out of scope in this document Therefore, a correspondent binding cache that matches the specified
and is currently discussed in Monami6 WG. If there is no desired BID MUST be found from the binding cache database. On the other
binding, it searches the binding cache database with the Home Address hand, for the data packets, no BID information is carried in a
as specified in Mobile IPv6. The first matched binding entry may be packet. The binding cache lookup may involve policy or flow filters
found, although this is implementation dependent. to retrieve a correspondent BID per packet in cases where some policy
or flow filters are used to direct a certain packet or flow to a
particular care-of address. However, the binding cache lookup using
policy or flow filters is out of scope for this document. If no such
A mobile node carefully operates the returning home. The Home Agent RFC 5648 MCoA October 2009
needs to defend a mobile node's home address by the proxy NDP for
packet interception, while the mobile node defends its home address
by regular NDP to send and receive packets at the interface attached
to the home link. Two nodes, Home Agent and Mobile Node, compete ND
state. This will causes address duplication problem at the end. If
the proxy neighbor advertisement for the Home Address is stopped,
packets are always routed to the interface attached to the home link.
On the other hand, packets are never routed to the interface attached
to the home link when the proxy is active.
When a mobile node wants to return home with interface attached to mechanism is available and no BID is found for a packet, a node
the home link, it MUST de-register all the bindings by sending a SHOULD use the binding that was last verified by receiving data
Binding Update with lifetime set to zero as described in [RFC-3775] packets or signaling from the mobile node. In case the binding cache
and [RFC-3963]. The mobile node does not put any Binding Unique lookup for data packets, using the combination of home address and
Identifier sub-option in this Binding Update. The receiver deletes BID, does not return a valid binding cache entry, the home agent
all the bindings from its binding cache database. On the other hand, SHOULD perform the lookup based on only the home address as described
a mobile node does not want to return home and keeps the interfaces in [RFC3775].
attached to the foreign links active, when one of its interfaces is
attached to its home link. The mobile node disables the interface
attached to the home link and keeps using the rest of interfaces
attached to foreign links. In this case, the mobile node sends a de-
registration Binding Update including the BID for the interface
attached to the home link. The receiver of the de-registration
Binding Update deletes only the relative binding entry from the
binding cache database. The home agent does not stop proxying
neighbor advertisement as long as there are still bindings for the
other 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 home agent.
In the above two cases, a mobile node cannot use interfaces attached In any case, to avoid problems with upper-layer protocols and TCP in
to both home and foreign links simultaneously. If the proxy NDP is particular, a single packet flow as identified by the 5-tuple SHOULD
disabled, the main problem can be solved. In the Multiple Care-of only be sent to a single care-of address at a time.
Address Registration, the elimination of Proxy NDP enables that
Mobile Node and Home Agent maintain multiple bindings for the The mobile node may return to the home link through one of its
interfaces attached to the home link and the foreign links. The interfaces. There are two options possible for the mobile node when
mobile node sends the binding update with H flag set for the it returns home. Sections 5.5.1 and 5.6 describe the returning-home
interface attached to the home link. The detail operation can be procedures in more detail.
found in Section 5.5.
1. The mobile node uses only the interface with which it attaches to
the home link and takes back full ownership of its HoA (home
address) on the home link. This is illustrated in Figure 2. It
de-registers all bindings with the home agent related to all
care-of addresses. The interfaces still attached to the visited
link(s) are no longer going to be receiving any encapsulated
traffic from the home agent. On the other hand, the mobile node
can continue communicating with the correspondent nodes from the
other interfaces attached to foreign links by using route
optimization. Even if the mobile node is attached to the home
link, it can still send Binding Updates for other active care-of
addresses (CoA1 and CoA2) to correspondent nodes. Since the
correspondent node has bindings, packets are routed from and to
each care-of address directly.
RFC 5648 MCoA October 2009
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Figure 2: Using Only an Interface Attached to the Home Link
2. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to
the visited link(s) as shown in Figure 3. There are two possible
topologies, depending on whether or not the home agent is the
only router on the home link. The operation of Neighbor
Discovery [RFC4861] is different in the two topologies. More
details can be found in Section 5.6. The home agent and the
correspondent node have the binding entries listed in Figure 3 in
their binding cache database in both topologies. The home agent
also knows that the mobile node is attached to the home link.
All the traffic from the Internet is intercepted by the home
agent first and routed to either the interface attached to the
home link or to one of the foreign links. How the home agent
decides to route a particular flow to the interface attached to
the home link or foreign link is out of scope for this document.
RFC 5648 MCoA October 2009
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Figure 3: Simultaneous Home and Visited Link Operation
This specification keeps backwards compatibility with [RFC3775]. If
a receiver (either home agent or correspondent node) does not support
this specification, it does not understand the Binding Identifier
mobility option. The receiver skips the unknown mobility option
(i.e., the Binding Identifier mobility option) and processes the
Binding Update as defined in [RFC3775]. In order to keep backwards
compatibility with [RFC3775], when a mobile node sends a Binding
RFC 5648 MCoA October 2009
Update message with extensions described in this document, the
receiver needs to reflect the Binding Identifier mobility option in
the Binding Acknowledgement. If the mobile node finds no Binding
Identifier mobility options in the received Binding Acknowledgement,
it assumes the other end node does not support this specification.
In such case, the mobile node needs to fall back to the legacy
[RFC3775]-compliant mobile node. If it is the home registration, the
mobile node MAY try to discover another home agent that supports the
Binding Identifier mobility option for the home registration.
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
This section summarizes the changes to Mobile IPv6 necessary to This section summarizes the extensions to Mobile IPv6 that are
manage multiple bindings bound to a same Home Address. necessary to manage multiple bindings.
4.1. Binding Cache Structure and Binding Update List 4.1. Binding Cache Structure and Binding Update List
The BID is required in the binding cache and binding update list The BID is required to be stored in the binding cache and Binding
structure. Update List structure.
4.2. Message Format Changes The sequence number value MUST be shared among all the Binding Update
List entries related to Binding Updates sent to a particular home
agent or correspondent node. Whenever a mobile node sends either an
individual or a bulk Binding Update, the sequence number is
incremented. When a home agent receives an individual Binding
Update, it should update the sequence number for all the bindings for
a particular mobile node, with the sequence number in the received
Binding Update.
4.2.1. Binding Unique Identifier sub-option 4.2. Binding Update Message
The Binding Unique Identifier sub-option is included in the Binding This specification extends the Binding Update message with a new
Update, Binding Acknowledgment, Binding Refresh Request, and Care-of flag. The flag is shown and described below.
Test Init and Care-of Test message.
1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update Message
RFC 5648 MCoA October 2009
Overwrite (O) flag
When this flag is set, all the binding cache entries for a mobile
node are replaced by new entries registering with this Binding
Update message. This flag is only used when the BID mobility
option is carried with the Binding Update.
Reserved
6-bit Reserved field.
4.3. Binding Identifier Mobility Option
The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
Test Init and Care-of Test messages. The Binding Identifier mobility
option has an alignment requirement of 2n if the Care-of Address
field is not present. Otherwise, it has the alignment requirement of
8n + 2.
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) | Status |C|O|H|Reserved | | Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
+ care-of address (CoA) + : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Sub-Option Figure 5: BID Mobility Option
Type Type
Type value for Binding Unique Identifier is TBD Type value for Binding Identifier is 35.
Length Length
Length value MUST be 4 when C flag is unset. Otherwise, the 8-bit unsigned integer. Length of the option, in octets,
Length value MUST be set to 20. excluding the Type and Length fields. It MUST be set to either 4,
8, or 20 depending on the Care-of Address field. When the care-of
address is not carried by this option, the length value MUST be
set to 4. If the IPv4 care-of address is stored in the Care-of
Address field, the length MUST be 8. Otherwise, the length value
MUST be set to 20 for IPv6 care-of addresses.
Binding Unique ID (BID) RFC 5648 MCoA October 2009
The BID which is assigned to the binding carried in the Binding Binding ID (BID)
Update with this sub-option. BID is 16-bit unsigned integer. A
value of zero is reserved. The BID that is assigned to the binding indicated by the care-of
address in the Binding Update or the Binding Identifier mobility
option. The BID is a 16-bit unsigned integer. The value of zero
is reserved and SHOULD NOT be used.
Status Status
When the Binding Unique Identifier sub-option is included in a The Status field is an 8-bit unsigned integer. When the Binding
Binding Acknowledgment, this field overwrites the status field Identifier mobility option is included in a Binding
correspondent to each binding in the Binding Acknowledgment. If Acknowledgement, this field overwrites the Status field in the
this field is zero, the receiver MUST use the registration status Binding Acknowledgement only for this BID. If this field is set
stored in the Binding Acknowledgment message. This Status field to zero, the receiver ignores this field and uses the registration
can be used to carry error information for a Care-of Test message. status stored in the Binding Acknowledgement message. The
The status is 8-bit unsigned integer. The possible status codes receiver MUST ignore this field if the Binding Identifier mobility
are the same as the status codes of Binding Acknowledgment. option is not carried within either the Binding Acknowledgement or
the Care-of Test messages. The possible status codes are the same
as the status codes of the Binding Acknowledgement. This Status
field is also used to carry error information related to the
care-of address test in the Care-of Test message.
Care-of address (C) flag Simultaneous Home and Foreign Binding (H) flag
When this flag is set, a mobile node can store a Care-of Address This flag indicates that the mobile node registers multiple
corresponding to the BID in the Binding Unique Identifier sub- bindings to the home agent while it is attached to the home link.
option. This flag must be used whenever a mobile node sends This flag is valid only for a Binding Update sent to the home
multiple bindings in a single Binding Update, i.e. bulk agent.
registration or MUST be used as a substitute for an alternate
care-of address option. This flag is valid only for binding
update for the home agent.
Overwrite (O) flag Reserved
When this flag is set, a mobile node requests a home agent to 7-bit Reserved field. The value MUST be initialized to zero by
replace all the bindings to binding entries stored in a Binding the sender, and SHOULD be ignored by the receiver.
Update. This flag is valid only for binding update for the home
agent.
Home Binding (H) flag Care-of Address
This flag indicates that the mobile node is attached to the home If a Binding Identifier mobility option is included in a Binding
link. This flag is valid only for binding update for the home Update for the home registration, either IPv4 or IPv6 care-of
agent. addresses for the corresponding BID can be stored in this field.
For the binding registration to correspondent nodes (i.e., route
optimization), only IPv6 care-of addresses can be stored in this
field. If no address is specified in this field, the length of
this field MUST be zero (i.e., not appear in the option). If the
option is included in any messages other than a Binding Update,
the length of this field MUST also be zero.
Reserved RFC 5648 MCoA October 2009
5 bits Reserved field. Reserved field must be set with all 0. 4.4. New Status Values for Binding Acknowledgement
Care-of Address New status values for the Status field in a Binding Acknowledgement
are defined for handling the multiple care-of addresses registration:
When C flag is set, a Care-of Address matched to the BID is MCOA NOTCOMPLETE (4)
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.
4.3. New Status Values for Binding Acknowledgment In bulk registration, not all the Binding Identifier mobility
options were successfully registered. Some of them were rejected.
The error status value of the failed mobility option is
individually stored in the Status field of the Binding Identifier
mobility option.
New status values for the status field in a Binding Acknowledgment MCOA RETURNHOME WO/NDP (5)
are defined for handling the multiple Care-of Addresses registration:
MCOA INCOMPLIANT (TBD) When a mobile node returns home, it MUST NOT use the Neighbor
Discovery Protocol (NDP) for the home address on the home link.
This is explained in more detail in Section 5.6.
Registration failed because Binding Unique Identifier sub-option MCOA MALFORMED (164)
is not compliant.
MCOA BID CONFLICT (TBD) Registration failed because the Binding Identifier mobility option
was not formatted correctly. This value is used in the following
cases:
It indicates that a regular binding (i.e. without the BID set) is * when the wrong length value is specified (neither 4, 8, nor 20)
already registered for the home address, and is conflicting with a in the Length field of the Binding Identifier mobility option.
received Binding Update which BID is set.
MCOA PROHIBITED(TBD) * when a unicast routable address is not specified in the Care-of
Address field of the Binding Identifier mobility option.
It implies the multiple care-of address registration is * when a care-of address does not appear in the Care-of Address
field of the Binding Identifier mobility option stored in an
IPsec Encapsulating Security Payload (ESP)-protected Binding
Update.
MCOA NON-MCOA BINDING EXISTS (165)
Indicates that a bootstrapping multiple care-of addresses
registration was performed without the 'O' flag set.
MCOA UNKOWN COA (167)
Indicates that a Binding Identifier mobility option did not
include a Care-of Address field and that the receiver has no
record for the Binding ID indicated in the same option.
RFC 5648 MCoA October 2009
MCOA PROHIBITED (166)
Implies that the multiple care-of addresses registration is
administratively prohibited. administratively prohibited.
MCOA BULK REGISTRATION NOT SUPPORTED (TBD) MCOA BULK REGISTRATION PROHIBITED (168)
The bulk binding registration is not supported. Bulk binding registration is either not permitted or not
supported. Note that the bulk registration is an optional
procedure and might not be available on a home agent.
MCOA FLAG CONFLICTS (TBD) MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
The flags of the sub-options presented in a Binding Unique Simultaneous home and foreign attachment is neither supported nor
Identifier sub-options conflicts. permitted.
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 Address(es) and Binding Identifier(s)
There are two cases when a mobile node has several Care-of Addresses: There are two cases when a mobile node might acquire several care-of
addresses. A mixture of the two cases is also possible. Note that a
mobile node can use BID regardless of the number of interfaces and
care-of addresses. Whether or not a mobile node uses BID is
determined by a local configuration.
1. A mobile node uses several physical network interfaces and 1. A mobile node is using 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 receives advertisements for multiple prefixes on the link to
attached to. Several global addresses are configured on this which the interface is attached. This will result in the mobile
interface for each of the announced prefixes. node configuring several global addresses on the interface from
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 in the number of
physical network interfaces and therefore does not matter in this physical network interfaces and is therefore irrelevant in this
document. The Identification number is used to identify a binding. document. What is of significance is the fact that the mobile node
To implement this, a mobile node MAY assign an identification number has several addresses it can use as care-of addresses.
for each care-of addresses. How to assign an identification number
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
register them simultaneously with its Home Address . The value register them simultaneously with its home address. The BID MUST be
should be generated from a value comprised between 1 to 65535. Zero unique for a given home address. The value is an integer between 1
and negative values MUST NOT be taken as a BID. If a mobile node has and 65535. A zero value SHOULD NOT be used as a BID. If a mobile
only one care-of address, the assignment of a BID is not needed until node has only one care-of address, the assignment of a BID is not
it has multiple care-of addresses to register with. needed until it has multiple care-of addresses with which to
register, at which time all of the care-of addresses MUST be mapped
to BIDs.
5.2. Return Routability: Sending CoTI and Receiving CoT RFC 5648 MCoA October 2009
When a mobile node wants to register bindings to a Correspondent When a mobile node registers a given BID for the first time, it MUST
Node, it MUST have the valid care-of Keygen token per care-of include the Care-of Address field in the Binding Identifier mobility
address, while the HoTI and HoT can be exchanged only once for a Home option. For any subsequent registrations that either re-register or
Address. de-register the same BID, the MN need not include the Care-of Address
field in the Binding Identifier mobility option.
If the Mobile Node manages bindings with BID, it MUST include a 5.2. Binding Registration
Binding Unique Identifier sub-option in a Care-of Test Init message.
It MUST NOT set the any flags in the sub-option. The receiver (i.e.
correspondent node) will calculate a care-of Keygen token as
specified in [RFC-3775] and reply a Care-of Test message and the
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 [RFC-3775]. If a Binding
Unique Identifier sub-option is not presented in CoT in reply to the
CoTI containing the Binding Unique Identifier sub-option, the
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 future Binding Update. The Mobile Node
MAY skip resending regular CoTI message and keep 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
[RFC-3775] specified.
5.3. Binding Registration For the multiple care-of addresses registration, the mobile node MUST
include a Binding Identifier mobility option(s) in the Binding Update
as shown in Figure 6.
When a mobile node sends a Binding Update, it MUST decide whether it When IPsec ESP is used for protecting the Binding Update, a care-of
registers multiple care-of addresses or not. However, this decision address MUST be carried in an alternate Care-of Address mobility
is out-of scope in this document. If a mobile node decides not to option as described in [RFC4877]. However, in this specification,
register multiple care-of addresses, it completely follows the the care-of address MUST be carried in the Care-of Address field of
RFC3775 specification. the Binding Identifier mobility option. In order to save bits of the
Binding Update, the alternate Care-of Address option MUST NOT be
included.
For the multiple Care-of Addresses registration, the mobile node MUST For binding registration to a correspondent node, the mobile node
include a Binding Unique Identifier sub-option(s) in the Mobility MUST have both active Home and Care-of Keygen tokens for Kbm (binding
Option field of a Binding Update as shown in Figure 2. The BID is management key; see Section 5.2.5 of [RFC3775]) before sending the
copied from a corresponding Binding Update List entry to the BID Binding Update. The care-of Keygen tokens MUST be maintained for
field of the Binding Unique Identifier sub-option. When ESP is used each care-of address that the mobile node wants to register to the
for binding update, the care-of address MUST be stored in the Care-of correspondent node. The Binding Update to the correspondent node is
Address field by setting C flag as a substitute for the alternate protected by the Binding Authorization Data mobility option that is
care-of address option. The alternate care-of address option MUST be placed after the Binding Identifier mobility option.
omitted. Additionally for binding registration to a correspondent
node, the mobile node MUST have both active home and care-of Keygen
tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen
tokens MUST be maintained for each care-of address that the mobile
node wants to register to the correspondent node, as described in
Section 5.2. After computing an Authenticator value for the Binding
Authorization sub-option, it sends a Binding Update which contains a
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.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header (for home registration) ESP Header*
Mobility header Mobility header
-BU Binding Update
Mobility Options Mobility Options
- Binding Unique Identifier sub-option Binding Identifier mobility option
- Binding Authorization sub-option Binding Authorization mobility option+
(for Route Optimization) (*) if necessary, for home registration
(+) if necessary, for route optimization
Figure 2: Binding Update for Binding Registration Figure 6: Binding Update for Binding Registration
5.4. Binding Bulk Registration If the mobile node wants to replace existing registered bindings on
the home agent with the single binding in the sent Binding Update, it
sets the 'O' flag. If the 'O' flag is not set, then the binding will
be added to existing bindings in the home agent. The single binding
will be registered with the assigned BID. Section 6.2 describes this
registration procedure in detail.
The bulk registration is an optimization for registering multiple RFC 5648 MCoA October 2009
care-of addresses only to a home agent by using a single Binding
Update. If a mobile node, for instance, does not want to send a lot
of control messages through an interface which bandwidth is scarce,
it can use this bulk registration and send a Binding Update
containing multiple or all the valid care-of addresses.
A mobile node sets the C flag in a Binding Unique Identifier sub- 5.3. Bulk Registration
option and stores the particular care-of address in the Binding
Unique Identifier sub-option. The mobile node stores multiple sets
of a Binding Unique Identifier sub-option in a Binding Update as
shown in Figure 3. When multiple Binding Unique Identifier sub-
options are presented in a Binding Update, the flag field of all the
sub-options MUST have the same value. For example, if C flag is set,
the same flag MUST be set to all the sub-options. Otherwise, the
mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding
Acknowledgment. In the bulk registration, all the other binding
information such as Lifetime, Sequence Number, binding Flags are
shared among the bulked Care-of Addresses. The alternate care-of
address option MUST be omitted when ESP is used to protect a binding
update. 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.
IPv6 header (src=CoA, dst=HA) Bulk registration is an optimization for binding multiple care-of
IPv6 Home Address Option addresses to a home address using a single Binding Update. This is
ESP Header very useful if the mobile node, for instance, does not want to send a
Mobility header lot of signaling messages through an interface where the bandwidth is
-BU scarce. This document specifies bulk registration only for the
Mobility Options mobile node's home registration. A mobile node performing bulk
- Binding Unique Identifier sub-options registration with a correspondent node is out of scope.
(C flag is set, O flag is optional,
BID and CoA are stored)
Figure 3: Binding Update for Binding Bulk Registration To use bulk registration, the mobile node includes a Binding
Identifier mobility option for each BID it wants to register in the
same Binding Update message. As with single registrations (see
Section 5.1), the Care-of Address field is included for each BID
registered for the first time. This is shown in Figure 7. The rest
of the fields and options in the Binding Update (such as Lifetime,
Sequence Number, and the flags in the Binding Update) are common
across all care-of addresses.
If the mobile node wants to replace existing registered bindings on IPv6 header (src=Care-of Address, dst=Home Agent Address)
the home agent with the bindings in the sent Binding Update, it can IPv6 Home Address Option
set O flag. Section 6.3 describes this registration procedure in ESP Header
detail. Mobility header
Binding Update
Mobility Options
Binding Identifier1 (including Care-of Address)
Binding Identifier2 (including Care-of Address)
Binding Identifier3 (no Care-of Address)
Binding IdentifierN (no Care-of Address)
5.5. Binding De-Registration and Returning Home :
Figure 7: Binding Update for Bulk Registration
As with regular registrations, if the mobile node wants to replace
existing registered bindings on the home agent with the multiple
bindings in the sent Binding Update, it sets the 'O' flag in the
Binding Update; otherwise, the bindings are added to the existing
bindings in the home agent.
5.4. Binding De-Registration
When a mobile node decides to delete all the bindings for its home When a mobile node decides to delete all the bindings for its home
address at a visiting network, it simply sends a regular de- address, it sends a regular de-registration Binding Update with
registration Binding Update which lifetime is set to zero. A Binding lifetime set to zero as defined in [RFC3775]. The Binding Identifier
Unique Identifier sub-option is not required. mobility option is not required.
RFC 5648 MCoA October 2009
If a mobile node wants to delete a particular binding(s) from its If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes (e.g. from foreign link), the home agent and correspondent nodes, the mobile node sends a Binding
mobile node simply sets zero lifetime for the sending binding update. Update with lifetime set to zero and includes a Binding Identifier
The Binding Update MUST contain a relative Binding Unique Identifier mobility option(s) with the BID(s) it wants to de-register. The
Sub-option(s). The receiver will remove only the care-of address(es) receiver will remove only the care-of address(es) that match(es) the
that matches to the specified BID. For the bulk de-registration, the specified BID(s). Since de-registration attempts to remove a BID
care-of addresses field of each sub-option SHOULD be omitted, because that already exists, the Care-of Address field in each Binding
the receiver will remove all the care-of addresses which matches the Identifier option can be omitted by the sender as defined in Section
specified BID. 5.1.
When a mobile node returns home, it SHOULD de-register all bindings 5.5. Returning Home with Complete Binding De-Registration: Using a
with the home agent by sending a regular de-registration binding Single Interface
update to flush all the registered bindings. However, there are
several scenarios for returning home described in Appendix A
(Figure 7, Figure 8, Figure 9). We have discussed this feature in
Monami6 working group now. This part might be updated in the next
revision.
As shown in Figure 7 in Appendix A, a mobile node de-registers all The mobile node may return to the home link by attaching to the home
the binding from the home agent, while it MAY still keep the bindings link through one of its interfaces. When the mobile node wants to
of the other interface active attached to foreign links only at the return home, it should be configured with information on what
Correspondent Nodes. By doing this, the mobile node still receives interface it needs to use.
packets from the Correspondent Node at the interface attached to a
foreign link thanks to route optimization. If the correspondent
nodes does not use route optimization, the mobile node receives such
packets at the interface attached to the home link.
In Figure 8, a mobile node does not want to return home even if one 5.5.1. Using Only the Interface Attached to the Home Link
of interfaces is attached to the home link. The mobile node MUST
disable the interface attached to the home link. Otherwise, address
duplication will be observed because the home agent still defend the
Home Address by the proxy neighbor advertisement and the mobile node
also enables the same Home Address on the home link. After disabling
the interface attached to the home link, the mobile node MUST delete
the binding for the disabled interface by sending a de-registration
binding update. The de-registration binding update is sent from one
of active interfaces attached to foreign links. As a result, the
mobile node no longer receives packets at the interface attached to
the home link. All packets are routed to other interfaces attached
to a foreign link.
Alternatively, the Mobile Node may choose to activate both the The mobile node returns home and de-registers all the bindings it has
interfaces attached to the home link and the foreign link, and with the home agent, as shown in Figure 2 and as defined in
communicates with all of the interfaces. The Mobile Node notifies [RFC3775]. After the de-registration step, all the packets routed by
the Home Agent using the H flag which means the Mobile Node is the home agent are only forwarded to the interface attached to the
attached to the home link. The Mobile Node may notify the care-of home link, even if there are other active interfaces attached to the
address of the interface(s) attached to the foreign link(s) in the visited link(s). While the mobile node de-registers all the bindings
same message using bulk registration. The Home Agent then no longer from the home agent, it may continue registering, to the
uses Proxy Neighbor Advertisement to intercept packets and the Mobile correspondent node, bindings for interfaces attached to visited links
Node can utilize both of interfaces attached to the home link and the as shown in Figure 2.
foreign link simultaneously. The Home Agent can intercept packets by
IP routing, but not by proxy Neighbor Discovery. The detailed
operation of no NDP operation can be found in [ID-NONDP].
When the Mobile Node returns home, it de-registers a binding for the 5.5.2. Using Only the Interface Attached to the Visited Link
interface. While the bindings for the interfaces attached to the
foreign link are still active. Intercepting packets, the Home Agent
can decide whether it tunnels to the foreign interface or routes to
the home interface of the Mobile Node. To do so, the Home Agent must
know that the Mobile Node is back to the home link. However, if the
binding is deleted, there is no way for the Home Agent to know that
the Mobile Node is at the home, too. The Home Agent SHOULD
invalidate the binding for the interface attached to the home link
and MAY NOT delete it. It can alternatively mark that the Mobile
Node is at the home link, too. As an example, the Home Agent inserts
the Home Address of the Mobile Node in the Care-of Address field of
the Mobile Node. The binding is named "Home Binding" in this
documentation. The Home Agent MAY manage this home binding as same
as the other binding entry in terms of lifetime validation, etc. The
Mobile Node MAY send multiple binding de- registration to keep this
home binding active. Alternatively, the Home Agent can use infinity
lifetime for the lifetime of the home binding. When the Mobile Node
leaves the Home Link, it can update the home binding to the normal
binding. Before that, the Home Agent believes the Mobile Node is at
the home and may route packets for the Mobile Node to the Home Link.
5.6. Receiving Binding Acknowledgment The mobile node returns home physically but shuts down the interface
attached to the home link. As a result, a mobile node does not
return home even though it attaches to the home link by one of the
interfaces. Before shutting down the interface, any binding for the
care-of address previously associated with the interface should be
deleted as defined in Section 5.4.
The verification of a Binding Acknowledgment is the same as Mobile In this scenario, despite the fact that the mobile node is connected
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a to its home link, all of its traffic is sent and received via the
Binding Acknowledgment is described in Section 6.3. home agent and its foreign links.
If a mobile node includes a Binding Unique Identifier sub-option in a RFC 5648 MCoA October 2009
Binding Update with A flag set, a Binding Acknowledgment MUST carry a
Binding Unique Identifier sub-option in the Mobility Options field.
If no such sub-option is appeared in the Binding Acknowledgment
replied to the Binding Update for the multiple care-of address
registration, this indicates that the originator node of this Binding
Acknowledgment might not recognize the Binding Unique Identifier sub-
option. The mobile node SHOULD stop registering multiple care-of
addresses by using a Binding Unique Identifier sub-option.
If a Binding Unique Identifier sub-option is present in the received 5.6. Returning Home: Simultaneous Home and Visited Link Operation
Binding Acknowledgment, the mobile node checks the registration
status for the Care-of address(es). The status value MUST be 5.6.1. Problems of Simultaneous Home and Foreign Attachments
retrieved as follows. If the status value in the Binding Unique
Identifier sub-option is zero, the mobile node uses the value in the The mobile node returns home and continues using all the interfaces
Status field of the Binding Acknowledgment. Otherwise, it uses the attached to both foreign and home links as shown in Figure 3.
value in the Status field of the Binding Unique Identifier sub-
option. In [RFC3775], the home agent intercepts packets meant for the mobile
node using proxy Neighbor Discovery [RFC4861] while the mobile node
is away from the home link. When the mobile node returns home, the
home agent deletes the binding cache and stops proxying for the home
address so that a mobile node can configure its home address on the
interface attached to the home link. In this specification, a mobile
node may return home and configure the home address on the interface
attached to the home link, but still use the interfaces attached to
the foreign links. In this case, a possible conflict arises when
both the home agent and the mobile node try to defend the home
address. If the home agent stops proxying for the home address, the
packets are always routed to the interface attached to the home link
and are never routed to the interfaces attached to the visited links.
Deployments making use of multiple care-of addresses are required to
avoid configuration conflict between the home agent and the mobile
node, while still allowing the simultaneous use of home and foreign
links. The following describes the mechanism for achieving this.
5.6.2. Overview and Approach
The home agent MUST intercept all the packets meant for the mobile
node, whether or not the mobile node is attached to the home link,
and decide whether to send the traffic directly to the home address
on the link or tunnel to the care-of address.
Two scenarios are illustrated in Figure 3, depending on whether or
not the home agent is the only router at the home link. The
difference is on who defends the home address by (Proxy) Neighbor
Discovery on the home link.
1. Mobile node defends the home address by the regular Neighbor
Discovery protocol (illustrated as topology-a in Figure 3). The
home agent is the only router on the home link. Therefore, the
home agent is capable of intercepting packets without relying on
the proxy Neighbor Discovery protocol, and the mobile node can
manage the neighbor cache entry of the home address on the home
link as a regular IPv6 node. However, there is one limitation of
this scenario. If a correspondent node is located at the home
link, the home agent may not intercept the packets destined to
RFC 5648 MCoA October 2009
the mobile node. These packets are routed only via the home
link, but this is the most optimal path for the mobile node to
communicate with nodes on the home link.
2. If there are routers other than the home agent on the home link,
then it cannot be guaranteed that all packets meant for the
mobile node are routed to the home agent. In this case, the
mobile node MUST NOT operate the Neighbor Discovery protocol for
the home address on the home link. This allows the home agent to
keep using proxy Neighbor Discovery, and thus it keeps receiving
all the packets sent to the mobile node's home address. If the
home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises
with respect to how the home agent discovers the mobile node's
link local address. This specification uses the Mobility Header
Link-Layer Address option defined in [RFC5568] in order to carry
the mobile node's link-layer address in the Binding Update.
Likewise, the mobile node would also know the link-layer address
of the default router address to send packets from the home link
without Neighbor Discovery. The link-layer address is used to
transmit packets from and to the mobile node on the home link.
The packets are transmitted without the Neighbor Discovery
protocol by constructing the link-layer header manually. This
operation is similar to Mobile IPv6 [RFC3775] when a mobile node
sends a de-registration Binding Update to the home agent's link-
layer address in the operation for returning home.
5.6.3. Home Binding Support
When the home binding is used, the mobile node MUST send a
registering Binding Update with a Binding Identifier mobility option
with the 'H' flag set. The lifetime MUST be set to a non-zero
lifetime of the home binding, and the Care-of Address field MUST be
set to the home address. The mobile node registers only one home
binding at a time, even if it attaches to the home link by multiple
interfaces.
The mobile node SHOULD include the Mobility Header Link-Layer Address
option [RFC5568] to notify the mobile node's link-layer address to
the home agent, too. The option code of the Mobility Header Link-
Layer Address option MUST be set to '2' (link-layer address of the
mobile node). This link-layer address is required for the home agent
to send the Binding Acknowledgement and to forward the mobile node's
packet.
According to [RFC3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends the
de-registration Binding Update to the home agent. However, in this
RFC 5648 MCoA October 2009
specification, the mobile node MUST NOT respond to Neighbor
Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the mobile
node receives [MCOA RETURNHOME WO/NDP (5)] status value in the
received Binding Acknowledgment, it MUST NOT respond to Neighbor
Solicitation even after the Binding Acknowledgement.
The management of the home binding is the same as the binding
management described in this specification. The home binding can be
included in a bulk binding registration (Section 5.3). The MN SHOULD
refresh the lifetime of the home binding by sending appropriate
Binding Updates as with any other binding.
5.6.4. Sending Packets from the Home Link
o When the mobile node receives the Binding Acknowledgement with the
status value 'Binding Update Accepted' and the BID option, it can
configure its home address to the interface attached to the home
link and start operating Neighbor Discovery for the home address
on the home link. Packets can be transmitted from and to the
mobile node as if the mobile node were a regular IPv6 node.
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
the Binding Acknowledgement, it MUST NOT operate Neighbor
Discovery for the home address. When the mobile node sends
packets from the interface attached to the home link, it MUST
learn the link-layer address of the next hop (i.e., default router
of the mobile node). A mobile node learns the default router's
link-layer address from a Source Link-Layer Address option in
Router Advertisements. The mobile node sends packets directly to
the default router's link-layer address. This is done by
constructing the packet to include a link-layer header with the
learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent receives the
de-registration Binding Update message. Note that the default
router MUST NOT cache the mobile node's link-layer address in the
neighbor cache when it forwards the packet from the mobile node to
the home agent.
5.6.5. Leaving from the Home Link
When the mobile node detaches from the home link, it SHOULD
immediately send a Binding Update for one of the active care-of
addresses with the 'H' flag unset. When the 'H' flag of the BID
option is unset in any Binding Update, the home agent stops
forwarding the mobile node's packets to the home link.
RFC 5648 MCoA October 2009
5.7. Receiving Binding Acknowledgement
The verification of a Binding Acknowledgement is the same as Mobile
IPv6 (Section 11.7.3 of [RFC3775]). The operation for sending a
Binding Acknowledgement is described in Section 6.2.
If a mobile node includes a Binding Identifier mobility option in a
Binding Update with the 'A' flag set, a Binding Acknowledgement
SHOULD carry a Binding Identifier mobility option. According to
[RFC3775], the receiver of the Binding Update ignores unknown
mobility options and processes the Binding Update without the unknown
mobility option. Therefore, if no such mobility option is included
in the Binding Acknowledgement in response to a Binding Update for a
multiple care-of addresses registration, this indicates that the
originating node of the Binding Acknowledgement does not support
processing the Binding Identifier mobility option regardless of
status value. In such case, the receiver of the Binding Update may
create a regular binding. The mobile node then SHOULD no longer
attempt a multiple care-of addresses registration with that node. If
this occurs with home registration, the mobile node MAY attempt to
discover another home agent that supports the Binding Identifier
mobility option for the home registration.
If a Binding Identifier mobility option is present in the received
Binding Acknowledgement, the mobile node checks the Status field in
the option. If the status value in the Binding Identifier mobility
option is zero, the mobile node uses the value in the Status field of
the Binding Acknowledgement. Otherwise, it uses the value in the
Status field of the Binding Identifier mobility option.
If the status code is greater than or equal to 128, the mobile node If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise, starts relevant operations according to the error code. Otherwise,
the originator (home agent or correspondent node) successfully the mobile node assumes that the originator (home agent or
registered the binding information and BID for the mobile node. correspondent node) successfully registered the binding information
and BID for the mobile node.
o If the Status value is [MCOA PROHIBITED], the mobile node MUST o If the status value is [MCOA PROHIBITED], the mobile node MUST
give up registering multiple bindings to the peer sending the stop registering multiple bindings with the node that sent the
Binding Acknowledgment. It MUST return to the regular Mobile IPv6 Binding Acknowledgement.
[RFC-3775] for the peer node.
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the o If the status value is [MCOA BULK REGISTRATION PROHIBITED], the
mobile node SHOULD stop using bulk registration to the peer mobile node needs to stop using bulk registrations with the node
sending the Binding Acknowledgment. that sent the Binding Acknowledgement. It should assume that none
of the attempted registrations were successful.
o If [MCOA FLAG CONFLICTS] is specified, it indicates that the o If [MCOA MALFORMED] is specified, it indicates that the Binding
different flag values are used in Binding Unique Identifier sub- Identifier mobility option is formatted wrong, presumably due to a
options in a Binding Update. If the C flag is set, all sub- programming error or major packet corruption.
options MUST have C flag. It is same for O flag. How to handle
other error status codes is specified in [RFC-3775].
o If [MCOA BID CONFLICT] is specified, the binding entry specified RFC 5648 MCoA October 2009
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 to reset all the registered bindings.
5.7. Receiving Binding Refresh Request o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that
there is a non-MCoA binding entry in the receiver. The mobile
node MUST set 'O' flag so that all the registered bindings are
replaced by an MCoA registration as described in Section 5.9.
o If [MCOA UNKNOWN COA] is specified, it means that the mobile node
sent a Binding Identifier mobility option without a Care-of
Address field, but the receiver could not find an entry for the
BID indicated. If the mobile node is trying to de-register a BID,
it need not do anything further. If the mobile node is trying to
refresh a binding, it SHOULD send a Binding Identifier mobility
option including the Care-of Address field.
5.8. 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 Mobile IPv6 (Section 11.7.4 of [RFC3775]). The operation of sending
a Binding Refresh Request is described in section Section 6.4. a Binding Refresh Request is described in 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 Identifier mobility option, it indicates that the node sending the
new binding indicated by the BID. The mobile node SHOULD update only Binding Refresh Request message is requesting that the mobile node
the respective binding. The mobile node MUST put a Binding Unique send a new Binding Update for the BID. The mobile node SHOULD then
Identifier sub-option into the Binding Update sent to refresh the send a Binding Update at least for the respective binding, as
entry. described in Sections 5.2 and 5.3.
If no Binding Unique Identifier sub-option is present in a Binding 5.9. Bootstrapping
Refresh Request, the mobile node sends a Binding Update according to
its Binding Update List. On the other hand, if the mobile node does
not have any Binding Update List entry for the requesting node, the
mobile node needs to register either a single binding or multiple
bindings depending on its binding management policy.
5.8. Sending Packets to Home Agent When a mobile node bootstraps and registers multiple bindings for the
first time, it MUST set the 'O' flag in the Binding Update message.
If old bindings still exist at the home agent, the mobile node has no
knowledge of which bindings still exist at the home agent. This
scenario happens when a mobile node reboots and loses state regarding
the registrations. If the 'O' flag is set, all the bindings are
replaced by the new binding(s).
When a multihomed mobile node sends packets to its home agent, there 6. Home Agent and Correspondent Node Operation
are conceptually two ways to construct packets.
1. Using Home Address Option. (required additional 24 bytes) 6.1. Searching Binding Cache with Binding Identifier
2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) 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
the bindings to communicate with the mobile node. This section
explains how to retrieve the desired binding for the binding
management. This document does not provide any mechanism to select
the suitable binding for forwarding data packets.
Beside the additional size of packets, no difference is observed RFC 5648 MCoA October 2009
between these two. The routing path is always the same and no
redundant path such as dog-leg 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 (i.e. ingress filtering). When it uses
the Home Address option, the home agent MAY check the care-of address
in the packet with the registering binding entries. This causes
additional overhead to the home agent. Therefore, the mobile node
SHOULD use the bi-directional tunnel even if it registers a
binding(s) to the home agent.
5.9. Bootstrapping A node that is either a correspondent node or a home agent SHOULD use
both the home address and the BID as the search key of the binding
cache if it knows the corresponding BID (for example, when processing
signaling messages). In the example below, if a node searches the
binding with the home address and BID2, it gets binding2 for this
mobile node.
When a mobile node bootstraps and registers multiple bindings at the binding1 [2001:db8::EUI, care-of address1, BID1]
first time, it SHOULD set O flag in the Binding Unique Identifier binding2 [2001:db8::EUI, care-of address2, BID2]
sub-option. If old bindings still exists at the Home Agent, the binding3 [2001:db8::EUI, care-of address3, BID3]
mobile node has no way to know which bindings are remained as a
garbage. 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 replaced by new bindings registered with the first Binding
Update. If the mobile node receives the Binding Acknowledgment with
the status code set to 135 [Sequence number out of window], it MUST
retry sending a Binding Update with the last accepted sequence number
which is notified by the Binding Acknowledgment.
For Correspondent nodes, the mobile node cannot use the O flag Figure 8: Searching the Binding Cache
because of no bulk registration support. Thus, if necessary, it MUST
sends a regular binding first to overwrite the remaining bindings at
the correspondent node. Then, it can re-register the set of bindings
by using Multiple Care-of Address Registration.
6. Home Agent and Correspondent Node Operation The node learns the BID when it receives a Binding Identifier
mobility option. At that time, the node MUST look up its binding
cache database with the home address and the BID retrieved from the
Binding Update. If the node does not know the BID, it searches for a
binding with only the home address. In such a case, the first
matched binding is found. If the node does not desire to use
multiple bindings for a mobile node, it can simply ignore the BID.
6.1. Searching Binding Cache with Binding Unique Identifier 6.2. Processing Binding Update
If either a correspondent node or a home agent has multiple bindings If a Binding Update does not contain a Binding Identifier mobility
for a mobile node in their binding cache database, it can use any of option, its processing is the same as in [RFC3775]. If the receiver
the bindings to communicate with the mobile node. How to select the already has multiple bindings for the home address, it MUST replace
most suitable binding from the binding cache database is out of scope all the existing bindings with the received binding. If the
in this document. [RFC3775] Binding Update is for de-registration, the receiver MUST
delete all existing bindings from its binding cache.
Whenever a correspondent node searches a binding cache for a home If the Binding Update contains Binding Identifier mobility option(s),
address, it SHOULD uses both the Home Address and the BID as the it is first validated according to Section 9.5.1 of [RFC3775]. Then
search key if it knows the corresponding BID. In the example below, the receiver processes the Binding Identifier mobility option(s) as
if a correspondent node searches the binding with the Home Address described in the following steps.
and BID2, it gets binding2 for this mobile node.
binding1 [a:b:c:d::EUI, care-of address1, BID1] o The length value is examined. The length value MUST be either 4,
binding2 [a:b:c:d::EUI, care-of address2, BID2] 8, or 20 depending on the Care-of Address field. If the length is
binding3 [a:b:c:d::EUI, care-of address3, BID3] incorrect, the receiver MUST reject the Binding Update and return
the status value set to [MCOA MALFORMED].
Figure 4: Searching the Binding Cache o When the length value is either 8 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the
unicast routable address [RFC3775] is not present in the Care-of
Address field, the receiver MUST reject the Binding Identifier
mobility option and return the status value set to [MCOA
MALFORMED].
A correspondent node basically learns the BID when it receives a RFC 5648 MCoA October 2009
Binding Unique Identifier sub-option. At the time, the correspondent
node MUST look up its binding cache database with the Home Address
and the BID retrieved from the Binding Update. If the correspondent
node does not know the BID, it searches for a binding with only a
Home Address as performed in Mobile IPv6. In such case, the first
matched binding is found. But which binding entry is returned for
the normal search depends on implementations. If the correspondent
node does not desire to use multiple bindings for a mobile node, it
can simply ignore the BID.
6.2. Receiving CoTI and Sending CoT o When multiple Binding Identifier mobility options are present in
the Binding Update, it is treated as bulk registration. If the
receiving node is a correspondent node, it MUST reject the Binding
Update and return the status value set to [MCOA BULK REGISTRATION
PROHIBITED] in the binding Acknowledgement.
When a correspondent node receives a CoTI message which contains a o If the Lifetime field in the Binding Update is set to zero, the
Binding Unique Identifier sub-option, it MUST process it with receiving node deletes the binding entry that corresponds to the
following steps. BID in the Binding Identifier mobility option. If the receiving
node does not have an appropriate binding for the BID, it MUST
reject the Binding Update and send a Binding Acknowledgement with
status set to 133 [not home agent for this mobile node].
First of all, the CoTI message is verified according to [RFC-3775]. o If the 'O' flag is set in the de-registering Binding Update, it is
The Binding Unique Identifier sub-option MUST be, then, processed as ignored. If the 'H' flag is set, the home agent stores a home
follows: address in the Care-of Address field of the binding cache entry.
The home agent MUST follow the descriptions described in Section
5.6.
o If a correspondent node does not understand a Binding Unique o If the Lifetime field is not set to zero, the receiving node
Identifier sub-option, it just ignores and skip this option. The registers a binding with the specified BID as a mobile node's
calculation of a care-of Keygen token will thus be done without a binding. The care-of address is obtained from the Binding Update
BID value. The correspondent node returns a CoT message without a packet as follows:
Binding Unique Identifier sub-option. The mobile node can thus
know whether the correspondent can process the Binding Unique
Identifier sub-option or not, by checking if such option is
present in the CoT message.
o If either or both C and O flag is set in the sub-option, the * If the length value of the Binding Identifier mobility option
Correspondent Node SHOULD NOT calculate a care-of Keygen token and is 20, the care-of address is the IPv6 address copied from the
MUST include a Binding Unique Identifier sub-option which status Care-of Address field in the Binding Identifier mobility
value set to [MCOA INCOMPLIANT] in the returned Care-of Test option.
message.
o Otherwise, the correspondent node MUST include a Binding Unique * When the length value is 8, the address MUST be the IPv4 valid
Identifier sub-option which status value MUST be set to zero in address. How to obtain an IPv4 care-of address is described in
the returning a CoT message. Section 8.
o All the Binding Unique Identifier sub-options SHOULD be copied * When the length value is 4 and the Binding Identifier is
from the received one except for the Status Field for CoT. The present in the binding cache, the receiving node MUST update
Care-of address field of each Binding Unique Identifier sub- the associated binding entry. Otherwise, the receiving node
option, however, can be omitted, because the mobile node can match MUST reject that Binding Identifier mobility option and send a
a corresponding binding update list by using BID. Binding Acknowledgement with the status for that Binding
Identifier mobility option set to [MCOA UNKNOWN].
6.3. Processing Binding Update o Once the care-of address(es) have been retrieved from the Binding
Update, the receiving nodes create new binding(s).
If a Binding Update does not contain a Binding Unique Identifier sub- * If the 'O' flag is set in the Binding Update, the receiving
option, its processing is same as in [RFC-3775]. But if the receiver node removes all the existing bindings and registers the
already has multiple bindings for the home address, it MUST replace received binding(s).
all the 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.
If a Binding Update contains a Binding Unique Identifier sub- RFC 5648 MCoA October 2009
option(s), it is validated according to section 9.5.1 of [RFC-3775]
and the following step.
o If the home registration flag is set in the Binding Update, the * If the 'O' flag is unset in the Binding Update and the receiver
home agent MUST carefully operate DAD for the received Home has a regular binding that does not have a BID for the mobile
Address. If the home agent has already had a binding(s) for the node, it must not process the Binding Update. The receiver
Mobile Node, it MUST avoid running DAD check when it receives the should send a Binding Acknowledgement with status set to [MCOA
Binding Update. NON-MCOA BINDING EXISTS].
The receiver node MUST process the Binding Unique Identifier sub- * If the receiver already has a binding with the same BID but
option(s) in the following steps. When a correspondent node sends a different care-of address, it MUST update the binding and
Binding Acknowledgment, the status value is always stored in the respond with a Binding Acknowledgement with status set to 0
Status field of the Binding Acknowledgment and keep the Status field [Binding Update accepted].
of Binding Unique Identifier sub-option to zero. For the Home Agent,
the status value can be stored in the Status field of either a
Binding Acknowledgment or a Binding Unique Identifier sub-option. If
the status value is specific to one of bindings in the bulk
registration, the status value MUST be stored in the Status field in
the corresponding Binding Unique Identifier sub-option.
o The length value is examined. The length value MUST be either 4 * If the receiver does not have a binding entry for the BID, it
or 20 depending on C flag. If the length is incorrect, the registers a new binding for the BID and responds with a Binding
receiver MUST rejects the Binding Update and returns the status Acknowledgement with status set to 0 [Binding Update accepted].
value set to [MCOA INCOMPLIANT].
o When C flag is specified, the care-of address MUST be given in the If all the above operations are successfully completed and the 'A'
Binding Unique Identifier sub-option. Otherwise, the receiver flag is set in the Binding Update, a Binding Acknowledgement
MUST reject the Binding Unique Identifier sub-option and returns containing the Binding Identifier mobility options MUST be sent to
the status value set to [MCOA INCOMPLIANT]. the mobile node. Whenever a Binding Acknowledgement is sent, all the
Binding Identifier mobility options stored in the Binding Update MUST
be copied to the Binding Acknowledgement except the Status field.
The Care-of Address field in each Binding Identifier mobility option,
however, MAY be omitted, because the mobile node can match a
corresponding Binding Update List entry using the BID.
o When multiple binding Unique Identifier sub-options are presented, When a correspondent node sends a Binding Acknowledgement, the status
the receiver MUST support the bulk registration. Only a home value MUST always be stored in the Status field of the Binding
agent can accept the bulk registration. Otherwise, it MUST reject Acknowledgement and the Status field of the Binding Identifier
the Binding Update and returns the status value set to [MCOA BULK mobility option MUST always be set to zero.
REGISTRATION NOT SUPPORT] in the Binding Acknowledgment.
o When multiple binding Unique Identifier sub-options are presented, When the home agent sends a Binding Acknowledgement, the status value
the flags field of all the Binding Unique Identifier sub-option can be stored in the Status field of either a Binding Acknowledgement
stored in the same Binding Update MUST be equal. Otherwise, the or a Binding Identifier mobility option. If the status value is
receiver MUST reject the Binding Update and returns the status specific to one of the bindings in the bulk registration, the status
value set to [MCOA FLAG CONFLICTS] in the Binding Acknowledgment. value MUST be stored in the Status field in the corresponding Binding
Identifier mobility option. In this case, the Status field of the
Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that
the receiver can examine the Status field of each Binding Identifier
mobility option for further operations. Otherwise, the Status field
of the Binding Identifier mobility option MUST be set to zero and the
home agent Status field of the Binding Acknowledgement is used.
o If the Lifetime field of the Binding Update is zero, the receiver 6.3. Sending a Binding Acknowledgement for Home Link Registration
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
for the binding cache. If the receiver is a Home Agent, it SHOULD
also return the status value set to [not Home Agent for this
mobile node, 133].
o If O flag is set in the deregistering Binding Update, the receiver The operations described in this section are related to returning
can ignore this flag for deregistration. If the H flag is set, home with simultaneous use of home and foreign links.
the home agent stores a Home Address in the Care-of Address field
of the binding cache entry. The home agent no longer performs
proxy NDP for this mobile node until this entry is deleted.
o If the Lifetime field is not zero, the receiver node registers a RFC 5648 MCoA October 2009
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 C flag is set in the Binding Unique Identifier sub-option, o When the home agent sends the Binding Acknowledgement after
the care-of address must be taken from the care-of address successfully processing the home binding registration, it MUST set
field in each Binding Unique Identifier sub-option. the status value to either 0 [Binding Update Accepted] or [MCOA
RETURNHOME WO/NDP (5)] in the Status field of the Binding
Acknowledgment, depending on home agent configuration at the home
link. The new values are:
* If C flag is not set in the Binding Unique Identifier sub- * Binding Update Accepted (0): The Neighbor Discovery protocol is
option, the care-of address must be taken from the Source permitted for the home address at the home link. This is the
Address field of the IPv6 header. regular returning home operation of [RFC3775].
* If C flag is not set and an alternate care-of address is * MCOA RETURNHOME WO/NDP (5): The Neighbor Discovery protocol is
present, the care-of address is taken from the Alternate prohibited for the home address at the home link.
Care-of address sub-option.
o Once the care-of address(es) has been retrieved from the Binding The respective Binding Identifier mobility options need to be
Update, it starts registering binding(s). included in the Binding Acknowledgement.
* Only if O flag is set in the sub-option, the home agent first o If the Binding Update is rejected, the appropriate error value
removes all the existing bindings and registers the received MUST be set in the Status field. In this case, the home agent
bindings. operation is the same as in [RFC3775].
* If the receiver has a regular binding which does not have BID o Only if the home agent is the only router in the home link MAY it
for the mobile node, it de-registers the regular binding and turn off Neighbor Discovery for the requested home address and
registers a new binding including BID according to the Binding respond with the [Binding Update Accepted] status value to the
Update. In this case, the receiver MUST return [MCOA BID mobile node. Since the mobile node will not reply to Neighbor
CONFLICT]. Solicitation for the home address before receiving the Binding
Acknowledgement, the home agent SHOULD use the link-layer address
carried by the Mobility Header Link-Layer Address option [RFC5568]
in the received Binding Update. After the completion of the home
binding registration, the mobile node starts regular Neighbor
Discovery operations for the home address on the home link. The
neighbor cache entry for the home address is created by the
regular exchange of Neighbor Solicitation and Neighbor
Advertisement.
* If the receiver node has already registered the binding which o If the home agent is not the only router in the home link, the
BID is matched with requesting BID, then it MUST update the home agent returns [MCOA RETURNHOME WO/NDP] value in the Status
binding with the Binding Update and returns [0 Binding Update field of the Binding Identifier mobility option. The home agent
accepted]. learns the mobile node's link-layer address by receiving the
Mobility Header Link-Layer Address option carried by the Binding
Update. It stores the link-layer address as a neighbor cache
entry for the mobile node so that it can send the packets to the
mobile node's link-layer address.
* If the receiver does not have a binding entry which BID is o Note that the use of proxy Neighbor Discovery is an easier way to
matched with the requesting BID, it registers a new binding for intercept the mobile nodes' packets instead of IP routing in some
the BID and returns [0 Binding Update accepted]. deployment scenarios. Therefore, even if a home agent is the only
If all the above operations are successfully finished, the Binding RFC 5648 MCoA October 2009
Acknowledgment containing the Binding Unique Identifier sub-options
MUST be replied to the mobile node if A flag is set in the Binding router, it is an implementation and operational choice whether the
Acknowledgment. Whenever a Binding Acknowledgment is returned, all home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
the Binding Unique Identifier sub-options stored in the Binding WO/NDP].
Update MUST be copied to the Binding Acknowledgment. The Care-of
address field of each Binding Unique Identifier sub-option, however, o If the BID option is not included in the Binding Acknowledgement,
can be omitted, because the mobile node can match a corresponding the home agent might not recognize the home registration. The
binding update list by using BID. home agent might have processed the home registration Binding
Update as a regular de-registration, as described in [RFC3775],
and deleted all the registered binding cache entries for the
mobile node. Thus, the mobile node SHOULD stop using the
interface attached to the foreign link and use only the interface
attached to the home link.
6.4. Sending Binding Refresh Request 6.4. Sending Binding Refresh Request
When a node sends a Binding Refresh Request for a particular binding When a node (home agent or correspondent node) sends a Binding
registering with BID, the node SHOULD contain a Binding Unique Refresh Request for a particular binding created with the BID, the
Identifier sub-option in the Binding Refresh Request. node SHOULD include the Binding Identifier mobility option in the
Binding Refresh Request. The node MAY include multiple Binding
Identifier mobility options if there are multiple bindings that need
to be refreshed.
6.5. Receiving Packets from Mobile Node 6.5. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address appeared from a mobile node, it MUST check that the care-of address that
in the Source Address field MUST be equal to one of the care-of appears in the Source Address field of the IPv6 header is equal to
addresses in the binding cache entry. If no binding is found, the one of the care-of addresses in the binding cache entry. If no
packets MUST be silently discarded and MUST send a Binding Error binding is found, the packets MUST be discarded. The node MUST also
message according to RFC3775. This verification MUST NOT be done for send a Binding Error message as specified in [RFC3775]. This
a Binding Update. verification MUST NOT be done for a Binding Update.
7. Network Mobility Applicability 7. Network Mobility Applicability
Support of multihomed mobile routers is advocated in the NEMO working The binding management mechanisms are the same for a mobile host that
group (see R12 "The solution MUST function for multihomed MR and uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
multihomed mobile networks" in [RFC-4886]. Issues regarding mobile Support protocol [RFC3963]. Therefore, the extensions described in
routers with multiple interfaces and other multihoming configurations this document can also be used to support a mobile router with
are documented in [RFC-4980]. multiple care-of addresses. [RFC4980] contains an analysis of NEMO
multihoming.
Since the binding management mechanisms are the same for a mobile 8. DSMIPv6 Applicability
host operating Mobile IPv6 and for a mobile router operating NEMO
Basic Support (RFC 3963), our extensions can also be used to deal
with multiple care-of addresses registration sent from a multihomed
mobile router. Figure 5 shows the example format of a Binding Update
used by a mobile router.
IPv6 header (src=CoA, dst=HA) Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] extends Mobile IPv6 to
IPv6 Home Address Option register an IPv4 care-of address instead of the IPv6 care-of address
ESP Header when the mobile node is attached to an IPv4-only access network. It
Mobility header also allows the mobile node to acquire an IPv4 home address in
-BU
Mobility Options
- Binding Unique Identifier sub-option
- Mobile Network Prefix sub-option
Figure 5: NEMO Binding Update RFC 5648 MCoA October 2009
8. IPsec and IKEv2 interaction addition to an IPv6 home address for use with IPv4-only correspondent
nodes. This section describes how the multiple care-of addresses
registration works with IPv4 care-of and home addresses.
Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the 8.1. IPv4 Care-of Address Registration
use of IPsec to protect signaling messages like Binding Updates,
Binding Acknowledgments and return routability messages. IPsec may The mobile node can use the extensions described in the document to
also be used protect all reverse tunneled data traffic. The Mobile register multiple care-of addresses, even if some of the care-of
IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used addresses are IPv4 addresses.
to setup the required IPsec security associations. The following
assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 Bulk registration MUST NOT be used for the initial binding
specification with respect to the use of IKEv2 and IPsec. registration from an IPv4 care-of address. This is because the
Binding Update and Binding Acknowledgement exchange is used to detect
NAT on the path between the mobile node and the home agent. So the
mobile node needs to check for a NAT between each IPv4 care-of
address and the home agent.
The Binding Update MUST be sent to the IPv4 home agent address by
using UDP and IPv4 headers as shown in Figure 9. It is similar to
[RFC5555] except that the IPv4 care-of address option MUST NOT be
used when the BID mobility option is used.
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv4 CoA)
*V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [RFC5555]
Figure 9: Initial Binding Update for IPv4 Care-of Address
If a NAT is not detected, the mobile node can update the IPv4 care-of
address by using bulk registration. The mobile node can register the
IPv4 care-of address along with other IPv4 and IPv6 care-of
addresses. Figure 10 shows the Binding Update format when the mobile
node sends a Binding Update from one of its IPv6 care-of addresses.
If the mobile node sends a Binding Update from an IPv4 care-of
address, it MUST follow the format described in Figure 9. Note that
the IPv4 care-of address must be registered by a non-bulk binding
registration whenever it is changed.
As shown in Figure 9, the IPv4 care-of address will appear in the
Binding Identifier mobility option. The IPv4 Care-of Address
mobility option defined in [RFC5555] MUST always be omitted. The
receiver of the Binding Update message for an IPv4 care-of address
RFC 5648 MCoA October 2009
MUST treat the IPv4 address stored in the Binding Identifier mobility
option as the one in the IPv4 Care-of Address mobility option of
[RFC5555]. If the IPv4 address in the Binding Identifier mobility
option is different from one in the Source Address field in the IPv4
header of the Binding Update (i.e., V4ADDR in Figure 9), the source
address is used as an IPv4 care-of address. Otherwise, the IPv4
address in the Binding Identifier mobility option is used as an IPv4
care-of address.
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...
Figure 10: Binding Bulk Registration for an IPv4 Care-of Address
When the home agent returns a Binding Acknowledgement for the IPv4
care-of address registration, it SHOULD NOT use the IPv4 Address
Acknowledgement mobility option and SHOULD use only the Binding
Identifier mobility option. The registration status for the IPv4
care-of address is stored in the Status field of the Binding
Identifier mobility option. However, if the home agent needs to
store the status value specially defined for the IPv4 Address
Acknowledgement mobility option, it MUST store the status value in
the IPv4 Address Acknowledgement mobility option and MUST NOT store
it in the Binding Identifier mobility option. In such case, the home
agent MUST include both the IPv4 Address Acknowledgement mobility
option and the Binding Identifier mobility option.
8.2. IPv4 Home Address Management
When the mobile node wants to configure an IPv4 home address in
addition to the IPv6 home address, it can request one using the IPv4
Home Address option in the Binding Update. If the home agent accepts
the Binding Update, the mobile node can now register multiple care-of
addresses for the IPv4 home address in addition to the IPv6 home
address. The mobile node MUST always use the IPv4 Home Address
mobility option for any purposes of the IPv4 home address management.
The same set of care-of addresses will be registered for both IPv6
and IPv4 home addresses. The mobile node cannot bind a different set
of care-of addresses to each home address.
RFC 5648 MCoA October 2009
According to [RFC5555], the home agent includes the IPv4 Address
Acknowledgement option in the Binding Acknowledgement only if the
mobile node had requested an IPv4 home address in the corresponding
Binding Update. The IPv4 Address Acknowledgement option MUST be
present before any Binding Identifier mobility option. The Status
field of the IPv4 Address Acknowledgement option contains only the
error code defined in Section 3.2.1 of [RFC5555]. The home agent
MUST always include the IPv4 Address Acknowledgement mobility option
in the Binding Acknowledgement for the IPv4 home address
registration.
9. IPsec and IKEv2 Interaction
Mobile IPv6 [RFC3775] and the NEMO protocol [RFC3963] require the use
of IPsec to protect signaling messages, including Binding Updates,
Binding Acknowledgements, and return routability messages. IPsec may
also be used to protect all tunneled data traffic. The Mobile IPv6-
IKEv2 specification [RFC4877] specifies how IKEv2 can be used to set
up the required IPsec security associations. The following
assumptions were made in [RFC3775], [RFC3963], and [RFC4877] with
respect to the use of IKEv2 and IPsec.
o There is only one primary care-of address per mobile node. o There is only one primary care-of address per mobile node.
o The primary care-of address is stored in the IPsec database for o The primary care-of address is stored in the IPsec database for
tunnel encapsulation and decapsulation. tunnel encapsulation and decapsulation.
o When the home agent receives a packet from the mobile node, the o When the home agent receives a packet from the mobile node, the
source address is verified against the care-of address in the source address is verified against the care-of address in the
corresponding binding cache entry. If the packet is a reverse corresponding binding cache entry. If the packet is a reverse-
tunneled packet from the mobile node, the care-of address check is tunneled packet from the mobile node, the care-of address check is
done against the source address on the outer IPv6 header. The done against the source address on the outer IPv6 header. The
reverse tunnel packet could either be a tunneled HoTi message or reverse-tunneled packet could either be a tunneled Home Test Init
tunneled data traffic to the correspondent node. message or tunneled data traffic to the correspondent node.
o The mobile node runs IKEv2 (or IKEv1) with the home agent using 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 the care-of address. The IKE SA is based on the care-of address
of the mobile node. of the mobile node.
The above assumptions may not be valid when multiple care-of The above assumptions may not be valid when multiple care-of
addresses are used by the mobile node. In the following sections, addresses are used by the mobile node. In the following sections,
the main issues with the use of multiple care-of address with IPsec the main issues with the use of multiple care-of addresses with IPsec
are addressed. are addressed.
8.1. Use of Care-of Address in the IKEv2 exchange RFC 5648 MCoA October 2009
For each home address the mobile node sets up security associations 9.1. Use of Care-of Address in the IKEv2 Exchange
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 For each home address for which the mobile node sets up security
to create and maintain the IPsec security associations associated associations with the home agent, the mobile node must pick one
with the home address. The resultant IKEv2 security association is care-of address and use that as the source address for all IKEv2
created based on this care-of address. 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 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 a Binding Update with the care-of address it wants to use, with the
corresponding Binding Unique Identifier sub-option, and with the 'K' corresponding Binding Identifier mobility option, and with the 'K'
bit set. This will force the home agent to update the IKEv2 security 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 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 supported on the mobile node or the home agent, the mobile node MUST
re-establish the IKEv2 security association with the new care-of re-establish the IKEv2 security association with the new care-of
address. This will also result in new IPsec security associations address. This will also result in new IPsec security associations
being setup for the home address. being set up for the home address.
8.2. Transport Mode IPsec protected messages 9.2. Transport Mode IPsec-Protected Messages
For Mobile IPv6 signaling message protected using IPsec in transport For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing. addresses does not matter for IPsec processing.
For Mobile Prefix Discovery messages, [RFC-3775] requires the home The home agent processes Mobile Prefix Discovery messages with the
agent to verify that the mobile node is using the care-of address same rules of data packets described in Section 6.5.
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 9.3. Tunnel Mode IPsec-Protected Messages
The use of IPsec in tunnel mode with multiple care-of address The use of IPsec in tunnel mode with multiple care-of addresses
introduces a few issues that require changes to how the mobile node introduces a few issues that require changes to how the mobile node
and the home agent send and receive tunneled traffic. The route and the home agent send and receive tunneled traffic. The route
optimization mechanism described in [RFC-3775] mandates the use of optimization mechanism described in [RFC3775] mandates the use of
IPsec protection in tunnel mode for the HoTi and HoT messages. The IPsec protection in tunnel mode for the Home Test Init and Home Test
mobile node and the home agent may also choose to protect all reverse messages. The mobile node and the home agent may also choose to
tunneled payload traffic with IPsec in tunnel mode. The following protect all reverse-tunneled payload traffic with IPsec in tunnel
sections address multiple care-of address support for these two types mode. The following sections address multiple care-of address
of messages. support for these two types of messages.
8.3.1. Tunneled HoTi and HoT messages 9.3.1. Tunneled Home Test Init and Home Test Messages
The mobile node MAY use the same care-of address for all HoTi The mobile node MAY use the same care-of address for all Home Test
messages sent reverse tunneled through the home agent. The mobile Init messages sent reverse tunneled through the home agent. The
node may use the same care-of address irrespective of which mobile node may use the same care-of address irrespective of which
correspondent node the HoTi message is being sent. RFC 3775 requires correspondent node the Home Test Init message is being to. RFC 3775
the home agent to verify that the mobile node is using the care-of requires the home agent to verify that the mobile node is using the
address that is in the binding cache entry, when it receives a 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 RFC 5648 MCoA October 2009
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 reverse-tunneled Home Test Init 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 Home Test Init 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 mobile sends and receives multiple traffic flows protected When the home agent tunnels a Home Test message to the mobile node,
by IPsec to different care-of addresses, the use of the correct the care-of address used in the outer IPv6 header is not relevant to
care-of address for each flow becomes important. Support for this the Home Test message. So regular IPsec tunnel encapsulation with
requires the following two considerations on the home agent. the care-of address known to the IPsec implementation on the home
agent is sufficient.
o When the home agent receives a reverse tunneled payload message 9.3.2. Tunneled Payload Traffic
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 When the mobile node sends and receives multiple traffic flows
entry. According to RFC 4306, the IPsec implementation on the protected by IPsec to different care-of addresses, the use of the
home agent does not check the source address on the outer IPv6 correct care-of address for each flow becomes important. Support for
header. Therefore the care-of address used in the reverse 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, the source address used in the
outer IPv6 header is irrelevant to IPsec, since the tunnel mode
security association is based on the addresses in the inner IPv6
header. Therefore, the same IPsec security association can be
used for payload traffic tunneled from any of the care-of
addresses. Note that the care-of address used in the reverse-
tunneled traffic can be different from the care-of address used as tunneled traffic can be different from the care-of address used as
the source address in the IKEv2 exchange. However, the Mobile the source address in the IKEv2 exchange. However, this does not
IPv6 stack on the home agent MUST verify that the source address cause an issue due to the above-mentioned reason.
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, 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 the IPsec implementation on the home agent will not be aware of
which care-of address to use when performing IPsec tunnel which care-of address to use when performing IPsec tunnel
encapsulation. The Mobile IP stack on the home agent must specify encapsulation. The Mobile IP stack on the home agent, based on
the tunnel end point for the IPsec tunnel. This may require tight the binding cache entries created by the mobile node, knows to
integration between the IPsec and Mobile IP implementations on the which care-of address the packet belonging to a particular flow
home agent. needs to be tunneled. The destination address for the outer IP
header must either be conveyed dynamically per packet to the IPsec
9. Security Considerations stack when it performs the encapsulation or the Mobile IPv6 stack
must get access to the packet after IPsec processing is done and
As shown in Section 8, the Multiple Care-of Addresses Registration modify the destination address. The first option requires changes
requires IPsec protected all the signaling between a mobile node and to the IPsec implementation. In the second option, there is a
its home agent. need for special processing in the forwarding function to replace
the destination address on the outer header with the correct
10. IANA Considerations care-of address. The exact technique to achieve the above is
implementation specific.
The following Extension Types MUST be assigned by IANA:
o Binding Unique Identifier sub-option type
o New Status of Binding Acknowledgment
* MCOA INCOMPLIANT (TBD)
* MCOA BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
* MCOA FLAG CONFLICTS (TBD)
11. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson),
Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen
(Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki
Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji
Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D)
in alphabetical order, the Jun Murai Lab. at KEIO University.
12. References
12.1. Normative References
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998.
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support RFC 5648 MCoA October 2009
in IPv6", RFC 3775, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 10. Security Considerations
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and The security considerations for securing the Binding Update and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Binding Acknowledgement messages with multiple care-of addresses are
draft-ietf-monami6-mipv6-analysis-02 (work in progress), February very similar to the security considerations for securing the Binding
2007. Update and Binding Acknowledgement. Please see [RFC3775] for more
information. The Binding Update and Binding Acknowledgement messages
with multiple care-of addresses are securely exchanged as described
in [RFC3775], [RFC4877], and Section 9 of this document. Additional
security considerations are described below.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate With simultaneous binding support, it is possible for a malicious
Requirement Levels", BCP 14, RFC 2119, March 1997. mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home agent.
Once these addresses have been bound, the malicious mobile node can
perform a re-direction attack by instructing the home agent (e.g.,
setting filtering rules to direct a large file transfer) to tunnel
packets to the victims' addresses. Such risk is highlighted in
[MIP6ANALYSIS]. These attacks are possible because the care-of
addresses sent by the mobile node in the Binding Update messages are
not verified by the home agent, i.e., the home agent does not check
if the mobile node is at the care-of address at which it claims to
be. The security model for Mobile IPv6 assumes that there is a trust
relationship between the mobile node and its home agent. Any
malicious attack by the mobile node is traceable by the home agent.
This acts as a deterrent for the mobile node to launch such attacks.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", Although such a risk exists in Mobile IPv6, the risk level is
RFC 3753, June 2004. increased when simultaneous multiple care-of address bindings are
performed. In Mobile IPv6, a mobile node can only have a single
care-of address binding per home address at a given time. However,
for simultaneous multiple care-of address bindings, a mobile node can
have more than one care-of address binding per home address at a
given time. This implies that a mobile node using simultaneous
binding support can effectively bind more than a single victim's
address. Another difference is the degree of risk involved. In the
single care-of address binding case, once the re-direction attack is
initiated, a malicious mobile node would be unable to use its home
address for communications (such as to receive control packets
pertaining to the file transfer). However, in the simultaneous
binding support case, a malicious mobile node could bind a valid
care-of address in addition to multiple victims addresses. This
valid care-of address could then be used by the malicious mobile node
to set up flow filtering rules at its home agent, thereby controlling
and/or launching new re-direction attacks.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support RFC 5648 MCoA October 2009
Terminology", RFC 4885, July 2007.
[RFC-4886] Ernst, T., "Network Mobility Support Goals and Thus, in view of such risks, it is advisable for a home agent to
Requirements", RFC 4886, July 2007. employ some form of care-of address verification mechanism before
using the care-of addresses as a valid routing path to a mobile node.
These mechanisms are out of scope for this document.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with In the binding registration of Mobile IPv6, a care-of address is
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. always verified by its reachability by a home agent. This
reachability test may decrease the above risks. However, when bulk
registration is used, a home agent cannot verify reachability of
care-of addresses carried in a Binding Identifier mobility option.
Therefore, the home agent can choose to reject bulk registration by
using [MCOA BULK REGISTRATION PROHIBITED] in a Binding
Acknowledgement. Alternatively, when a mobile node first registers a
care-of address, it uses the individual Binding Updates for the first
appeared care-of address. During the initial binding registration, a
home agent can verify the address reachability for that given care-of
address. After that, the mobile node uses bulk registration to
refresh the care-of address.
12.2. Informative References 11. IANA Considerations
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and The following Extension Types have been assigned by IANA:
K. Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), July 2007
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of o Binding Identifier mobility option type: (35) has been assigned
Multihoming in Network Mobility Support", RFC 4980, October 2007. from the same space as the mobility option in [RFC3775].
[ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of o New Successful Status of Binding Acknowledgement: These status
Proxy NDP from Home Agent Operations", codes have been assigned from the same space as the Binding
draft-wakikawa-mip6-no-ndp-02.txt (work in progress), November 2007. Acknowledgement status codes in [RFC3775].
Appendix A. Example Configurations * MCOA NOTCOMPLETE (4)
In this section, we describe typical scenarios when a mobile node has * MCOA RETURNHOME WO/NDP (5)
multiple network interfaces and acquires multiple Care-of Addresses
bound to a Home Address. The Home Address of the mobile node (MN in
figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly
acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns
BID1, BID2 and BID3 to each care-of address.
+----+ o New Unsuccessful Status of Binding Acknowledgement: These status
| CN | codes have also been assigned from the same space as the Binding
+--+-+ Acknowledgement status codes in [RFC3775].
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database: * MCOA MALFORMED (164)
home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 6: Multiple Interfaces Attached to a Foreign Link * MCOA NON-MCOA BINDING EXISTS (165)
Figure 6 depicts the scenario where all interfaces of the mobile node * MCOA PROHIBITED (166)
are attached to foreign links. After binding registrations, the home
agent (HA) and the Correspondent Node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize
all the interfaces.
+----+ * MCOA UNKNOWN COA (167)
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +--------+-+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ | |
+--+--+ | | |
CoA3| +---|-----------+
+---------------+
Binding Cache Database: * MCOA BULK REGISTRATION PROHIBITED (168)
home agent's binding (Proxy neighbor advertisement is inactive)
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 7: One of Interface Attached to Home Link and Returning Home RFC 5648 MCoA October 2009
Figure 7 depicts the scenario where MN returns home with one of its * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
interfaces. After the successful de-registration of the binding to
HA, HA and CN have the binding entries listed in their binding cache
database of Figure 7. MN can communicate with the HA through only
the interface attached to the home link. On the other hand, the
mobile node can communicate with CN from the other interfaces
attached to foreign links (i.e. route optimization). Even when MN is
attached to the home link, it can still send Binding Updates for
other active care-of addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface.
+----+ 12. Acknowledgements
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
(Disable interface)
Binding Cache Database: Ryuji Wakikawa and Thierry Ernst are grateful to Keio University for
home agent's binding (Proxy neighbor advertisement is active) its initial support on this specification at the time when they were
binding [a:b:c:d::EUI care-of address1 BID1] working there. In addition, the authors would like to thank Masafumi
binding [a:b:c:d::EUI care-of address2 BID2] Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen,
correspondent node's binding Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, and
binding [a:b:c:d::EUI care-of address1 BID1] Chan-Wah Ng for their discussions and inputs. Thanks to Susumu
binding [a:b:c:d::EUI care-of address2 BID2] Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
Uehara, Masafumi Watari, and Jun Murai for earlier work on this
subject.
Figure 8: One of Interface Attached to Home Link and Not Returning 13. References
Home
Figure 8 depicts the scenario where MN disables the interface 13.1. Normative References
attached to the home link and communicates with the interfaces
attached to foreign links. The HA and the CN have the binding
entries listed in their binding cache database. MN disable the
interface attached to the home link, because the HA still defends the
home address of the MN by proxy neighbor advertisements. All packets
routed to the home link are intercepted by the HA and tunneled to the
other interfaces attached to the foreign link according to the
binding entries.
+----+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
| CN | Requirement Levels", BCP 14, RFC 2119, March 1997.
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----------+ +--+-+
CoA2| | Home Link
+--+--+ --+----+---+------
| MN +===================+ |
+--+--+ |
| |
+---------------------------+
Binding Cache Database: [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
home agent's binding (Proxy neighbor advertisement is inactive) "Neighbor Discovery for IP version 6 (IPv6)", RFC
none 4861, September 2007.
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 9: Several Interfaces Attached to Home Link and Returning Home [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
Figure 9 depicts the scenario where multiple interfaces of MN are [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
attached to the home link. The HA and CN have the binding entries with IKEv2 and the Revised IPsec Architecture", RFC
listed in Figure 9 in their binding cache database. The MN can not 4877, April 2007.
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
routed to one of the MN's interfaces attached to the home link.
Figure 10 depicts the scenario where interfaces of MN are attached to [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
the foreign links. One of foreign link is managed by the home agent. Thubert, "Network Mobility (NEMO) Basic Support
The HA and CN have the binding entries listed in Figure 10 in their Protocol", RFC 3963, January 2005.
binding cache database. The home agent advertises a prefix which is
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
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
the home agent is one-hop neighbor. The cost of tunnel is
negligible. If the mobile node wants to utilize not only an
interface attached to home but also interfaces attached to foreign
link, it can use this foreign link of the home agent to return a one
hop foreign link on behalf of a home link. This is different from
the general returning home, but this enable the capability of using
interfaces attached to both home and foreign link without any
modifications to Mobile IPv6 and NEMO basic support.
+----+ [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
| CN | Hosts and Routers", RFC 5555, June 2009.
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ ++-+-+
CoA2| | | | Home Link
+--+--+ | ----|-+------
| MN +========+ |
+--+--+ CoA1 ---+-+------
CoA3 | | Foreign Link
+---------------------------+
Binding Cache Database: [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC
home agent's binding (Proxy neighbor advertisement is active) 5568, July 2009.
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 10: Emulating to Utilize Interfaces Attached to both Home and 13.2. Informative References
Foreign Links
Appendix B. Changes From Previous Versions [MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using
Multiple Interfaces and Global Addresses", Work in
Progress, May 2008.
Changes from draft-ietf-monami6-multiplecoa-03.txt RFC 5648 MCoA October 2009
o Change the handling of Status field. All the status value is [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis
defined for BA of Multihoming in Network Mobility Support", RFC 4980,
October 2007.
o Alternate CoA option is omitted, but using C flag is recommended. [MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
Work in Progress, May 2008.
o Adding examples of BU [RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, June 2004.
o Many editorial updates [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa (Editor) Ryuji Wakikawa (Editor)
Faculty of Environment and Information Studies, Keio University TOYOTA InfoTechnology Center Co., Ltd.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan
Phone: +81-3-5565-5069 EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Fax: +81-3-5565-5094
Email: nagami@inetcore.com
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Wichorus
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 EMail: vijay@wichorus.com
"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 George Tsirtsis
Qualcomm
The IETF takes no position regarding the validity or scope of any EMail: Tsirtsis@gmail.com
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Thierry Ernst
assurances of licenses to be made available, or the result of an INRIA
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any EMail: thierry.ernst@inria.fr
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment Kenichi Nagami
INTEC NetCore Inc.
Funding for the RFC Editor function is provided by the IETF EMail: nagami@inetcore.com
Administrative Support Activity (IASA).
 End of changes. 232 change blocks. 
1160 lines changed or deleted 1419 lines changed or added

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