< draft-ietf-monami6-multiplecoa-05.txt   draft-ietf-monami6-multiplecoa-06.txt >
Monami6 Working Group R. Wakikawa (Editor) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Ernst Intended status: Standards Track T. Ernst
Expires: July 31, 2008 INRIA Expires: August 27, 2008 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli V. Devarapalli (Ed.)
Azaire Networks Azaire Networks
January 28, 2008 February 24, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-05.txt draft-ietf-monami6-multiplecoa-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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, that 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9
4.1. Binding Cache Structure and Binding Update List . . . . . 9 4.1. Binding Cache Structure and Binding Update List . . . . . 9
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 9 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 9
4.2.1. Binding Identifier Mobility Option . . . . . . . . . . 9 4.3. New Status Values for Binding Acknowledgement . . . . . . 11
4.3. New Status Values for Binding Acknowledgment . . . . . . . 11
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13
5.1. Management of Care-of Addresses and Binding Identifier . . 13 5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14
5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15 5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 14
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 15
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. Using only Interface attached to the Home Link . . . . 16 5.6.1. Using only Interface attached to the Home Link . . . . 16
5.6.2. Using only Interface attached to the Visited Link . . 16 5.6.2. Using only Interface attached to the Visited Link . . 16
5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17
5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 19 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 19
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20
5.9. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20
5.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21
6. Home Agent and Correspondent Node Operation . . . . . . . . . 22
6.1. Searching Binding Cache with Binding Identifier . . . . . 22
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21
6.1. Searching Binding Cache with Binding 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 . . . . . . . . . . . . 24
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 28 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 25
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 28
8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 29
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 30 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 26
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 30 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 26
9.2. Transport Mode IPsec protected messages . . . . . . . . . 31 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 27
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 31
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 31
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28
9.2. Transport Mode IPsec protected messages . . . . . . . . . 29
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Example Configurations . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix B. Changes From Previous Versions . . . . . . . . . . . 42 Appendix A. Example Configurations . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
A mobile node may use various types 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 is 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 [ID-MOTIVATION]. When a mobile node with multiple interfaces uses
on a given interface. Consequently, Mobile IPv6 [RFC-3775] has Mobile IPv6 [RFC-3775] 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 only bind one care-of
a node is more advantageous than assigning multiple Home Addresses address at a time with its home address.
because applications do not need to be aware of the multiplicity of
Home Addresses. If multiple home addresses are available,
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 Identification (BID) number for each binding cache entry to node to register multiple care-of addresses for a home address and
accommodate multiple bindings registration. The mobile node notifies create multiple binding cache entries. A new Binding Identification
the BID to both its Home Agent and correspondent nodes by means of a (BID) number is created for each binding the mobile node wants to
Binding Update. Correspondent nodes and the home agent record the create and sent in the binding update. The home agent that receives
BID into their binding cache. The Home Address thus identifies a this Binding Update creates separate binding for each BID. The BID
mobile node itself whereas the BID identifies each binding registered information is stored in the corresponding binding cache entry. The
by a mobile node. By using the BID, multiple bindings can then be BID information can now be used to identify individual bindings. The
distinguished. 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 [RFC-2119].
Terms used in this draft are defined in [RFC-3775], [RFC-3753] and Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
[RFC-4885]. In addition or in replacement of these, the following [RFC-4885]. In addition or in replacement of these, the following
terms are defined or redefined: terms are defined or redefined:
Binding Identification number (BID) 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 MUST be unique for a entries for a given home address. The BID MUST be unique for a
binding to a specific care-of address for a given home address and binding to a specific care-of address for a given home address and
care-of address pair. The zero value and a negative value MUST care-of address pair. Zero and negative values MUST NOT be used.
NOT be used. Each BID is generated and managed by a mobile node. Each BID is generated and managed by a mobile node. The BID is
After being generated by the mobile node, the BID is stored in the stored in the Binding Update List and is sent by the mobile node
Binding Update List and is sent by the mobile node in the Binding in the Binding Update. A mobile node MAY change the value of a
Update. A mobile node MAY change the value of a BID at any time BID at any time according to its administrative policy, for
according to its administrative policy, for instance to protect instance to protect its privacy. An implementation must carefully
its privacy. An implementation must carefully assign the BID so assign the BID so as to keep using the same BID for the same
as to keep using the same BID for the same binding even when the binding even when the status of the binding is changed. More
status of the binding is changed. More details can be found in details can be found in Section 5.1.
Section 5.1.
Binding Identifier Mobility Option Binding Identifier Mobility Option
The Binding Identifier mobility 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 the bindings available at the home agent with the new bindings by
several care-of addresses. A mobile node can also replace all the using the bulk registration. Bulk registration is supported only
bindings available at the home agent with the new bindings by with the home agent as explained in Section 5.5. A mobile node
using the bulk registration. The bulk registration is supported MUST NOT perform bulk registration with a correspondent node.
only for home registration and de-registration as explained in
Section 5.5. A mobile node MUST NOT perform bulk registration
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 one or more of its same home address. If a mobile node configures several IPv6 global
interfaces, it can register these addresses with its home agent. If addresses on one or more of its interfaces, it can register these
the mobile node wants to register multiple bindings, it MUST generate addresses with its home agent as care-of addresses. If the mobile
a BID for each care-of address and record the BID into the binding node wants to register multiple bindings, it MUST generate a BID for
update list. A mobile node can manipulate each binding independently each care-of address and store the BID in the binding update list. A
by using a BID. The mobile node then registers its care-of addresses mobile node can manipulate each binding independently by using the
by sending a Binding Update with a Binding Identifier mobility BIDs. The mobile node then registers its care-of addresses by
option. The BID MUST be included in the Binding Identifier mobility sending a Binding Update with a Binding Identifier mobility option.
option. After receiving such Binding Update and Binding Identifier The BID is included in the Binding Identifier mobility option. After
mobility option, the home agent MUST copy the BID from the Binding receiving the Binding Update with a Binding Identifier mobility
Identifier mobility option to the corresponding field in the binding option, the home agent MUST copy the BID from the Binding Identifier
cache entry. Even if there is already an entry for the mobile node's mobility option to the corresponding field in the binding cache
home address, the home agent MUST register a new binding entry for entry. If there is an existing binding cache entry for the mobile
the BID stored in the Binding Identifier mobility option. The mobile node, and if the BID in the Binding Update does not match the one
node registers multiple care-of addresses either independently in 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
register multiple care-of addresses either independently in
individual Binding Updates or multiple at once in a single Binding individual Binding Updates or multiple at once in a single Binding
Update. Update.
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 perform return routability operations. correspondent node, it must perform return routability operations.
The mobile host MUST manage a Care-of Keygen Token per care-of This includes managing a Care-of Keygen token per care-of address and
address. The mobile host exchanges CoTI and CoT for the exchanging CoTi and CoT message with the correspondent node for each
corresponding care-of addresses if necessary. When the mobile host care-of address. The mobile node MAY use the same BID that it used
registers several care-of addresses to a correspondent node, it uses with the home agent for a particular care-of address. For protocol
the same BID as the one generated for the home registration's simplicity, bulk registration to correspondent nodes is not supported
bindings. The binding registration step is the same as for the home in this document. This is because the Return Routability mechanism
registration except for calculating authenticator. For protocol introduced in [RFC-3775] cannot be easily extended to verify multiple
simplicity, the bulk registration is not supported for correspondent care-of addresses stored in a single Binding Update.
nodes in this document. Return Routability introduced in [RFC-3775]
cannot be easily extended to verify multiple care-of addresses stored
in a single Binding Update.
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 [RFC-3775], it sends a Binding Update without any Binding
Identifier mobility options. The receiver of the Binding Update Identifier mobility options. The receiver of the Binding Update
deletes all the bindings registering with a BID and registers only a deletes all the bindings registering with a BID and registers only a
single binding for the mobile node. Note that the mobile node can single binding for the mobile node. Note that the mobile node can
continue using BID even if only a single binding is active at some continue using the BID even if it has only a single binding that is
time. active.
When a home agent and a correspondent node check the binding cache Binding cache lookup is done based on the home address and BID
database for the mobile node, they search a corresponding binding information. This is different from RFC 3775, where only the home
entry with the pair of Home Address and BID of the desired binding. address is used for binding cache lookup. The binding cache lookup
If necessary, a mobile node can use policy and filter information to may also involve policy or flow filters in cases where some policy or
look up the best binding per sessions, flow, packets, but this is out flow filters are used to direct certain packets or flows to a
of scope in this document. If there is no desired binding, it particular care-of address. The binding cache lookup using policy or
searches the binding cache database with the Home Address as flow filters is out of scope for this document. In case the binding
specified in Mobile IPv6. The first matched binding entry may be cache lookup, using the combination of home address and BID, does not
found, although this is implementation dependent. return a valid binding cache entry, the home agent MAY perform
another lookup based on only the home address. This is
implementation dependent and configurable on the home agent.
The mobile node may return to the home link through one its The mobile node may return to the home link through one of its
interfaces. There are three options possible for the mobile node interfaces. There are three options possible for the mobile node
when its returns home. when its returns home.
1. The mobile node uses only the interface with which it attaches to 1. The mobile node uses only the interface with which it attaches to
the home link. It de-registers all bindings related to all the home link. It de-registers all bindings related to all
care-of addresses. The interfaces which are still attached to care-of addresses. The interfaces still attached to the visited
the visited link are not used. link(s) are no longer going to be receiving any encapsulated
traffic from the home agent.
2. The mobile node uses only the interfaces still attached to the 2. The mobile node uses only the interfaces still attached to the
visited link. The interface with which the mobile node attaches visited link(s). The interface with which the mobile node
to the home link is not used. attaches to the home link is not used.
3. The mobile node may simultaneously use both the interface 3. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to attached to the home link and the interfaces still attached to
the visited links. the visited link(s).
Section 5.6 describes the returning home procedures in more detail. Section 5.6 describes the returning home procedures in more detail.
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 necessary for
manage multiple bindings bound to a same Home Address. 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
4.2.1. Binding Identifier Mobility Option 4.2. Binding Identifier Mobility Option
The Binding Identifier mobility option is included in the Binding The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgment, Binding Refresh Request, and Care-of Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
Test Init and Care-of Test message. Test Init and Care-of Test message.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |C|O|H|D|Resrvd | | Binding ID (BID) | Status |C|O|H|D|Resrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
skipping to change at page 10, line 4 skipping to change at page 9, line 47
Type value for Binding Identifier is TBD Type value for Binding Identifier is TBD
Length Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Type and Length fields. MUST be set to 4 when the excluding the Type and Length fields. MUST be set to 4 when the
'C' flag is unset. Otherwise, the Length value MUST be set to 'C' flag is unset. Otherwise, the Length value MUST be set to
either 8 or 20 depending on the 'D' (DSMIPv6) flag. either 8 or 20 depending on the 'D' (DSMIPv6) flag.
Binding ID (BID) Binding ID (BID)
The BID which is assigned to the binding carried in the Binding
Update with this mobility option. BID is 16-bit unsigned integer. The BID which is assigned to the binding indicated by the care-of
A value of zero is reserved. address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and
MUST NOT be used.
Status Status
When the Binding Identifier mobility option is included in a When the Binding Identifier mobility option is included in a
Binding Acknowledgment, this field overwrites the status field Binding Acknowledgement, this field overwrites the status field in
correspondent to each binding in the Binding Acknowledgment. If the Binding Acknowledgement. If this field is zero, the receiver
this field is zero, the receiver MUST use the registration status MUST use the registration status stored in the Binding
stored in the Binding Acknowledgment message. This Status field Acknowledgement message. This Status field is also used to carry
can be used to carry error information for a Care-of Test message. error information related to the care-of address test in the
The status is 8-bit unsigned integer. The possible status codes Care-of Test message. The status is 8-bit unsigned integer. The
are the same as the status codes of Binding Acknowledgment. possible status codes are the same as the status codes of Binding
Acknowledgement.
Care-of address (C) flag Care-of address (C) flag
When this flag is set, a mobile node can store a Care-of Address When this flag is set, it indicates that a valid care-of address
corresponding to the BID in the Binding Identifier mobility is present in the care-of address field in the BID mobility
option. This flag MUST be used whenever a mobile node sends option. This flag MUST be set whenever the mobile node sends
multiple care-of addresses in a single Binding Update, i.e. bulk multiple care-of addresses in a single Binding Update, i.e., bulk
registration. It MUST be also used for the independent binding registration. It MAY also used as a substitute for alternate
registration as a substitute for an alternate care-of address care-of address option even for Binding Updates that are sent only
option. This flag is valid only for binding update sent to the for one care-of address. This flag is valid only for Binding
home agent. Update sent to the home agent.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, a mobile node requests a home agent to When this flag is set, a mobile node requests the recipient to
replace all the bindings to binding entries stored in a Binding replace all the bindings to binding entries stored in a Binding
Update. This flag is valid only for binding update sent to the Update.
home agent.
Simultaneous Home and Foreign Binding (H) flag Simultaneous Home and Foreign Binding (H) flag
This flag indicates that the mobile node registers multiple This flag indicates that the mobile node registers multiple
bindings to the home agent while is attached to the home link. bindings to the home agent while is attached to the home link.
This flag is valid only for a binding update sent to the home This flag is valid only for a Binding Update sent to the home
agent. agent.
DSMIPv6 (D) flag DSMIPv6 (D) flag
This flag indicates that the care-of address field MUST be set to This flag indicates that the care-of address is an IPv4 address.
IPv4 care-of address. If this flag is set, the Care-of Address When this flag is set, the care-of address field MUST contain an
field MUST be used. IPv4 address.
Reserved Reserved
5 bits Reserved field. Reserved field MUST be set with all 0. 5 bits Reserved field. The reserved field MUST be zero.
Care-of Address Care-of Address
This field has the variable length depending on the specified This field has the variable length depending on the specified
flags. When C flag is set and D flag is unset, an IPv6 Care-of flags. When the 'C' flag is set and the 'D' flag is not, an IPv6
Address matched to the BID is stored in this field. If both C and care-of address for the corresponding BID is stored in this field.
D flags are set, an IPv4 Care-of Address is stored. This field If both 'C' and 'D' flags are set, an IPv4 Care-of Address is
MUST NOT be used if a Binding Identifier mobility option is carried in this field. This field MUST NOT be used if a Binding
included in any other messages than a Binding Update message. The Identifier mobility option is included in any other message other
receiver SHOULD ignore this field if the mobility option is not than a Binding Update or if the 'C' flag is not set.
presented in Binding Update message.
4.3. New Status Values for Binding Acknowledgment 4.3. New Status Values for Binding Acknowledgement
New status values for the status field in a Binding Acknowledgment New status values for the status field in a Binding Acknowledgement
are defined for handling the multiple Care-of Addresses registration: are defined for handling the multiple Care-of Addresses registration:
MCOA NOTCOMPLETE (TBD < 128) MCOA NOTCOMPLETE (TBD < 128)
In bulk registration, not all the binding identifier mobility In bulk registration, not all the binding identifier mobility
option are successfully registered. Some of them are rejected. option are successfully registered. Some of them are rejected.
The error status value of the failed mobility option is The error status value of the failed mobility option is
individually stored in the status field of the binding identifier individually stored in the status field of the binding identifier
mobility option. mobility option.
MCOA RETURNHOME WO/NDP (TBD < 128) MCOA RETURNHOME WO/NDP (TBD < 128)
When a mobile node returns home, it MUST NOT use NDP for the home When a mobile node returns home, it MUST NOT use NDP for the home
address on the home link. The detail can be found in Section 5.6 address on the home link. This is explained in more detail in
Section 5.6
MCOA MALFORMED (TBD more than 128) MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option is Registration failed because Binding Identifier mobility option was
not formed correctly. not formatted correctly.
MCOA BID CONFLICT (TBD more than 128) MCOA BID CONFLICT (TBD more than 128)
The home agent cannot cache both a regular binding and a BID The home agent cannot cache both a regular binding and a BID
extended binding simultaneously. It returns this status value extended binding simultaneously. It returns this status value
when the received binding conflicts with the existing binding when the received binding conflicts with the existing binding
cache entry(ies). cache entry(ies).
MCOA PROHIBITED(TBD more than 128) MCOA PROHIBITED(TBD more than 128)
It implies the multiple care-of address registration is It implies the multiple care-of address registration is
administratively prohibited. administratively prohibited.
MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)
The bulk binding registration is not supported. Bulk binding registration is not supported.
5. Mobile Node Operation 5. Mobile Node Operation
5.1. Management of Care-of Addresses and Binding 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
Note that a mixture of the two cases are possible. addresses. Note that a mixture of the two cases is also possible.
1. A mobile node uses several physical network interfaces and 1. A mobile node may be using several physical network interfaces
acquires a care-of address on each of its interfaces. and 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 the
attached to. Several global addresses are configured on this interface is attached to. This will result in the mobile node
interface for each of the announced prefixes. 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 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 implementation specific, but the following rules MUST be followed.
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 BID MUST be register them simultaneously with its home address. The BID MUST be
unique for a binding to a specific care-of address for a given home unique for a given home address and care-of address pair. The value
address and care-of address pair. The value should be generated from should be an integer between 1 and 65535. Zero and negative values
a value comprised between 1 to 65535. Zero and negative values MUST MUST NOT be used as BIDs. If a mobile node has only one care-of
NOT be used as a BID. If a mobile node has only one care-of address, address, the assignment of a BID is not needed until it has multiple
the assignment of a BID is not needed until it has multiple care-of care-of addresses to register with, at which time all of the care-of
addresses to register with. addresses MUST be mapped to BIDs.
5.2. Return Routability: Sending CoTI and Receiving CoT 5.2. Return Routability: Sending CoTI and Receiving CoT
When a mobile node wants to register bindings to a Correspondent When a mobile node wants to register multiple care-of address with a
Node, it MUST have the valid care-of Keygen token per care-of correspondent node, it MUST have the valid Care-of Keygen token per
address, while the HoTI and HoT can be exchanged only once for a Home care-of address. The mobile node needs only one Home Keygen token
Address. for its home address.
If the Mobile Node manages bindings with BID, it MUST include a The mobile node MUST include a Binding Identifier mobility option in
Binding Identifier mobility option in a Care-of Test Init message. the Care-of Test Init message. It MUST NOT set any flags in the
It MUST NOT set the any flags in the mobility option. The receiver mobility option. The receiver (i.e. correspondent node) will
(i.e. correspondent node) will calculate a care-of Keygen token as calculate a care-of Keygen token as specified in [RFC-3775] and reply
specified in [RFC-3775] and reply a Care-of Test message and the with a Care-of Test message, with the Binding Identifier mobility
Binding Identifier mobility option as described in Section 6.2. When option as described in Section 6.2. When the mobile node receives
the mobile node receives the Care-of Test message, the Care-of Test the Care-of Test message, the message is verified as in [RFC-3775].
message is verified as same as in [RFC-3775]. If a Binding If a Binding Identifier mobility option is not present in the CoT
Identifier mobility option is not presented in CoT in reply to the message in reply to the CoTI message that included a Binding
CoTI containing the Binding Identifier mobility option, the Identifier mobility option, the mobile node must assume that the
correspondent node does not support the Multiple Care-of Address correspondent node does not support Multiple Care-of Address
registration. Thus, the mobile node MUST NOT use a Binding registration. Thus, the mobile node MUST NOT use a Binding
Identifier mobility option in the future Binding Update. The Mobile Identifier mobility option in any future Binding Updates to that
Node MAY skip re-sending regular CoTI message and keep the received correspondent node. The mobile node MAY skip re-sending regular CoTI
care-of Keygen token for the regular Binding Update, because the message and keep the received care-of Keygen token for the regular
correspondent node just ignores and skip the Binding Identifier Binding Update.
mobility option and calculates the care-of Keygen token as [RFC-3775]
specified.
5.3. Binding Registration 5.3. Binding Registration
When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple care-of addresses or not. However, how this
decision is taken is out-of scope in this document. If a mobile node
decides not to register multiple care-of addresses, it completely
follows the RFC3775 specification.
For the multiple Care-of Addresses registration, the mobile node MUST For the multiple Care-of Addresses registration, the mobile node MUST
include a Binding Identifier mobility option(s) in the Mobility include a Binding Identifier mobility option(s) in the Binding Update
Option field of a Binding Update as shown in Figure 2. The BID is as shown in Figure 2. The BID is copied from a corresponding Binding
copied from a corresponding Binding Update List entry to the BID Update List entry to the BID field of the Binding Identifier mobility
field of the Binding Identifier mobility option. When ESP is used option. When IPsec ESP is used for protecting the Binding Update,
for binding update, the care-of address MUST be stored in the Care-of the care-of address can be carried in the Care-of Address field of
Address field by setting C flag as a substitute for the alternate the Binding Identifier mobility option. If this is done, the
care-of address option. The alternate care-of address option MUST be alternate care-of address option MUST NOT be included in the Binding
omitted. Additionally for binding registration to a correspondent Update. For binding registration to a correspondent node, the mobile
node, the mobile node MUST have both active home and care-of Keygen node MUST have both active Home and Care-of Keygen tokens for Kbm
tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update.
tokens MUST be maintained for each care-of address that the mobile The care-of Keygen tokens MUST be maintained for each care-of address
node wants to register to the correspondent node, as described in that the mobile node wants to register to the correspondent node.
Section 5.2. After computing an Authenticator value for the Binding The Binding Update to the correspondent node is protected by the
Authorization mobility option, it sends a Binding Update which Binding Authorization Data mobility option that is placed after the
contains a Binding Identifier mobility option. The Binding Update is Binding Identifier mobility option.
protected by a Binding Authorization Data mobility option placed
after the Binding Identifier mobility option.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header (for home registration) ESP Header (for home registration)
Mobility header Mobility header
-BU -BU
Mobility Options Mobility Options
- Binding Identifier mobility option - Binding Identifier mobility option
- Binding Authorization mobility option - Binding Authorization mobility option
(for Route Optimization) (for Route Optimization)
Figure 2: Binding Update for Binding Registration Figure 2: Binding Update for Binding Registration
5.4. Binding Bulk Registration 5.4. Bulk Registration
The bulk registration is an optimization for registering multiple Bulk registration is an optimization for binding multiple care-of
care-of addresses only to a home agent by using a single Binding addresses to a home address using a single Binding Update. This is
Update. If a mobile node, for instance, does not want to send a lot very useful if the mobile node, for instance, does not want to send a
of control messages through an interface which bandwidth is scarce, lot of signaling messages through an interface where the bandwidth is
it can use this bulk registration and send a Binding Update scarce.
containing multiple or all the valid care-of addresses.
A mobile node sets the C flag in a Binding Identifier mobility option To use bulk registration, the mobile node includes a Binding
and includes the particular care-of address in the Binding Identifier Identifier Mobility option for each BID and Care-of address pair it
mobility option. The mobile node stores multiple sets of a Binding wants to register in the same Binding Update message. This is shown
Identifier mobility option in a Binding Update as shown in Figure 3. in Figure 3. The rest of the fields and options in the Binding
In the bulk registration, all the other binding information such as Update such as Lifetime, Sequence Number, the flags in the Binding
Lifetime, Sequence Number, binding Flags are shared among the bulked Update are common across all care-of addresses. The alternate
Care-of Addresses. The alternate care-of address option MUST be care-of address option MUST NOT be used.
omitted when ESP is used to protect a binding update.
In the bulk registration, the Sequence Number field of a Binding In the bulk registration, the Sequence Number field of a Binding
Update SHOULD be carefully configured. This is because all the bulk- Update SHOULD be carefully configured. This is because all the bulk-
registered bindings uses the same Sequence Number specified in the registered bindings use the same Sequence Number specified in the
Binding Update. If each binding uses different sequence number, a Binding Update. If each binding uses different sequence number, a
mobile node MUST use the largest sequence number from the binding mobile node MUST use the largest sequence number from the Binding
update list used for the bulk registration. If it cannot select a Update list entries used for the bulk registration. If the mobile
sequence number for all the bindings due to sequence number out of node cannot select a sequence number for all the bindings due to
window, it MUST NOT use the bulk registration for the binding which sequence number out of window, it MUST NOT use the bulk registration
sequence number is out of window and uses a separate Binding Update for the binding whose sequence number is out of window. A separate
for the binding. Binding Update should be sent for the binding.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
-BU -BU
Mobility Options Mobility Options
- Binding Identifier mobility options - Binding Identifier mobility options
(C flag is set, O flag is optional, (C flag is set, O flag is optional,
BID and CoA are stored) BID and CoA are stored)
Figure 3: Binding Update for Binding Bulk Registration Figure 3: Binding Update for Bulk Registration
If the mobile node wants to replace existing registered bindings on If the mobile node wants to replace existing registered bindings on
the home agent with the bindings in the sent Binding Update, it can the home agent with the bindings in the sent Binding Update, it sets
set O flag. Section 6.3 describes this registration procedure in the 'O' flag. Section 6.3 describes this registration procedure in
detail. detail.
5.5. Binding De-Registration 5.5. 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 [RFC-3775]. The Binding
Identifier mobility option is not required. Identifier mobility option is not required.
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 an appropriate Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The
mobility option(s). The receiver will remove only the care-of receiver will remove only the care-of address(es) that match(es) the
address(es) that matches to the specified BID. For the bulk de- specified BID(s). The care-of addresses field in each mobility
registration, the care-of addresses field of each mobility option option SHOULD be omitted by the sender and MUST be ignored by the
SHOULD be omitted, because the receiver will remove all the care-of receiver. This is because the receiver will remove the binding that
addresses matching the specified BID. matches the specified BID.
5.6. Returning Home 5.6. Returning Home
The mobile node may return to the home link, by attaching to the home The mobile node may return to the home link, by attaching to the home
link through one of the interfaces on the mobile node. When the link through one of its interfaces. When the mobile node wants to
mobile node wants to return home, it should be configured with what return home, it should be configured with information on what
interface it needs to use. The mobile node may use only the interface it needs to use. The mobile node may use only the
interface with which it is attached to the home link, only the interface with which it is attached to the home link, only the
interfaces still attached to the visited link or use both interfaces interfaces still attached to the visited link or use both interfaces
attached to the home link and visited link simultaneously. The attached to the home link and visited link simultaneously. The
following describes each option in more detail. following describes each option in more detail.
5.6.1. Using only Interface attached to the Home Link 5.6.1. Using only Interface attached to the Home Link
The mobile node returns home and de-registers all the bindings as The mobile node returns home and de-registers all the bindings as
shown in Figure 9. How to de-register all the bindings is the same shown in Figure 8 and as defined in [RFC-3775]. De-registering all
as binding de-registration from foreign link described in the bindings is the same as binding de-registration from foreign link
Section 5.5. All the packets routed by the home agent are only described in Section 5.5. After the de-registration step, all the
forwarded to the interface attached to the home link, even if there packets routed by the home agent are only forwarded to the interface
are other active interfaces attached to the visited link. While the attached to the home link, even if there are other active interfaces
mobile node de-registers all the bindings from the home agent, it may attached to the visited link. While the mobile node de-registers all
continue registering bindings for interface attached to visited link the bindings from the home agent, it may continue registering
to the correspondent node as shown in Figure 9. These bindings at bindings for interface attached to visited link to the correspondent
correspondent node MUST be created before a mobile node returns home. node as shown in Figure 8.
5.6.2. Using only Interface attached to the Visited Link 5.6.2. Using only Interface attached to the Visited Link
The mobile node returns home and shutdown the interface attached to The mobile node returns home and shuts down the interface attached to
the home link as shown in Figure 10. The binding of the home the home link as shown in Figure 9. Before shutting down the
attached interface MUST be deleted by sending a de-registration interface, any binding for the care-of address previously associated
binding update from one of active interface attached to the foreign with the interface should be deleted. To delete the binding cache
links. This scenario is not the most efficient because all the entry, the mobile node SHOULD send a de-registration Binding Update
traffic from and to the mobile node is going through the bi- with the lifetime set to zero and include the corresponding BID
directional tunnel, whereas the mobile node is now accessible at one information. If the mobile node does not send a de-registration
hop from its home agent. Binding Update, the binding for the care-of address previously
assigned to the interface remains at the home agent. This binding is
deleted only when it expires. In order to avoid this, the mobile
node SHOULD send a de-registration binding update for the interface
attached to the home link.
This scenario is not the most efficient because all the traffic to
and from the mobile node is going through the bi-directional tunnel,
whereas the mobile node is now accessible at one hop on the home link
from its home agent.
5.6.3. Simultaneous Home and Visited Link Operation 5.6.3. Simultaneous Home and Visited Link Operation
The mobile node returns home and continues using all the interfaces In this case, the mobile node returns home and continues using all
attached to both foreign and home links as shown in Figure 11. The the interfaces attached to both foreign and home links as shown in
mobile node indicates this by setting the 'H' flag in the BID Figure 10. The mobile node indicates this by setting the 'H' flag in
mobility option. There are additional requirements on the Returning the BID mobility option as defined below. There are additional
Home procedures for possible ND conflicts at the home link described requirements on the Returning Home procedures for possible ND
below. conflicts at the home link described below.
In [RFC3775], the home agent intercepts packets meant for the mobile In [RFC-3775], the home agent intercepts packets meant for the mobile
node using proxy NDP while the mobile node is away from the home node using proxy Neighbor Discovery while the mobile node is away
link. When the mobile node returns home, the home agent deletes the from the home link. When the mobile node returns home, the home
binding cache and stop the proxy NDP for the home address so that a agent deletes the binding cache and stops proxying for the home
mobile node can configure its home address on the interface attached address so that a mobile node can configure its home address on the
to the home link. In this specification, a mobile node may return interface attached to the home link. In this specification, a mobile
home while it keeps several interfaces attached to the foreign links node may return home, configure the home address on the interface
and continues using them. Therefore, even though both the mobile attached to the home link, but still use the interfaces attached to
node and the home agent need to intercept packets, the ND states of the foreign links. In this case, a possible conflict arises when the
the home address can conflict between the home agent and the mobile both the home agent and the mobile node try to defend the home
node. For instance, if the proxy ND for the Home Address is stopped address. If the home agent stops proxying for the home address, the
by the home agent, packets are always routed to the interface packets are always routed to the interface attached to the home link
attached to the home link and are never routed to the interface and are never routed to the interfaces attached to the visited links.
attached to the foreign link. It is required to avoid this ND It is required to avoid the conflict between the home agent and the
conflicts in the case of the simultaneous home and foreign mobile node, while still allowing the simultaneous use of home and
attachment. foreign links. The following describes the mechanism for achieving
this.
In this specification, the home agent MUST intercept all the packets In this specification, the home agent MUST intercept all the packets
meant for the mobile node and decide whether to send the traffic meant for the mobile node and decide whether to send the traffic
directly to the home address on the link or tunnel to the care-of directly to the home address on the link or tunnel to the care-of
address. The home agent would make this decision based on the type address. The home agent intercepts all the packets even when the
of packets and flows. How to make this decision is out of scope in mobile node is attached to the home link through one of its
this document. The delicate part would be to create a neighbor cache interfaces. The home agent would make this decision based on the
entry for the mobile node so that the home agent can deliver the type of packets and flows. How to make this decision is out of scope
packets on-link. The home agent would need to know the Layer-2 in this document. The critical part would be to create a neighbor
cache entry for the mobile node so that the home agent can deliver
the packets on-link. The home agent would need to know the Layer-2
address of the interface with which the mobile node is attached to address of the interface with which the mobile node is attached to
the home link. In order to create the neighbor cache entry for the the home link. In order to create the neighbor cache entry for the
mobile node, following operations are required. mobile node, following operations are required.
The mobile node sends a de-registration binding update to the home The mobile node sends a de-registration Binding Update to the home
agent from the interface attached to the home link. In the Binding agent from the interface attached to the home link. In the Binding
Update, the BID mobility option must be stored for the BID assigned Update, the BID mobility option must include the BID the mobile node
to the interface. The H flag MUST be set in the BID mobility option. had previously associated with the interface attached to the home
When the H flag is appears, the home agent learns and remembers that link. The 'H' flag MUST be set in the BID mobility option. The 'C'
flag MUST NOT be set and the care-of address field MUST NOT be
included. When the 'H' flag is set, the home agent recognizes that
the mobile node wants to continue using interfaces attached to both the mobile node wants to continue using interfaces attached to both
foreign and home links. If H flag is unset, the home agent deletes home and visited links. If the 'H' flag is unset, the home agent
either all the bindings or the binding corresponding to the BID. deletes either all the bindings or the binding corresponding to the
BID included in the Binding Identifier mobility option.
When the home agent sends the Binding Acknowledgment, it MUST store When the home agent sends the Binding Acknowledgement, it MUST set
one of two status values such as [Binding Update Accepted (0)] [MCOA the status value to either 0 [Binding Update Accepted] or to
RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home [MCOARETURNHOME WO/NDP (TBD)] in the BID mobility option depending on
agent configuration at the home link. The new values are: home agent configuration at the home link. The new values are:
o Binding Update Accepted (0): NDP is permitted for the home address o Binding Update Accepted (0): NDP is permitted for the home address
at the home link. This is regular returning home operation of at the home link. This is regular returning home operation of
[RFC3775] [RFC-3775]
o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link address at the home link
When the home agent is the only router at the home link, it can When the home agent is the only router at the home link, it can
intercept all the packets by IP routing without proxy NDP. It stops intercept all the packets by normal IP routing without using proxying
proxy ND for the requested home address and replies the [Binding for the home address. It stops proxy ND for the requested home
Update Accepted] value to the mobile node. The neighbor cache entry address and responds with the [Binding Update Accepted] status value
for the mobile node is created by the regular NDP operation (i.e. to the mobile node. The neighbor cache entry for the mobile node is
NS/NA exchange). On the other hand, if the home agent is not the created by the regular exchange of Neighbor Solicitation and Neighbor
only router, it MUST continue defending the home address by proxy NDP Advertisement. If the home agent is not the only router on the home
to capture all the mobile node's traffic. The home agent, then, link, it MUST continue defending the home address by proxy neighbor
returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID discovery in order to intercept the mobile node's traffic. The home
mobility option. The home agent also learns the mobile node's agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status
layer-2 address (i.e. MAC address) during this binding de- field of the BID mobility option. The home agent also learns the
registration. It keeps the learned layer-2 address as the neighbor mobile node's layer-2 address (i.e., MAC address) during this binding
de-registration. It stores the learnt layer-2 address in a neighbor
cache entry for the mobile node so that it can construct the layer-2 cache entry for the mobile node so that it can construct the layer-2
header for the packets meant for the mobile node and forwards them header for the packets meant for the mobile node and forwards them
directly to the mobile node's interface attached to the home link. directly to the mobile node's interface attached to the home link.
According to [RFC3775], the mobile node MUST NOT assign the home According to [RFC-3775], the mobile node MUST NOT assign the home
address to the interface attached to the home link and MUST NOT address to the interface attached to the home link and MUST NOT
attempt NDP operations for the home address before the completion of attempt NDP operations for the home address before the completion of
binding de-registration. It MUST NOT send and reply to Neighbor binding de-registration. It MUST NOT send and reply to Neighbor
Solicitation for the home address. The home address MUST be Solicitation for the home address. The home address MUST be
tentative address at this moment until it receives Binding tentative address at this moment until it receives Binding
Acknowledgment with success status value. Acknowledgement with success status value.
When the mobile node receives the binding acknowledgment and BID When the mobile node receives the Binding Acknowledgement and BID
mobility option, it assigns home address at the interface attached to mobility option, it assigns home address to the interface attached to
the home link according to the status field of the BID. If the value the home link according to the status field of the BID. If the value
is [Binding Update Accepted], the mobile node can start defending the is [Binding Update Accepted], the mobile node can start defending the
home address using NDP. The home agent can create neighbor cache home address using regular Neighbor Discovery.
entry for the mobile node by NS and NA exchange as normal IPv6
operation.
If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT If the mobile node receives the [MCOA RETURNHOME WO/NDP], it MUST NOT
defends its home address at the home link by NDP. When the mobile defend its home address on the home link. When the mobile node sends
node sends packets from the interface attached to the home link, it packets from the interface attached to the home link, it MUST learn
MUST learn the layer2 address (i.e. MAC address) of the next hop the layer 2 address (i.e., MAC address) of the next hop (i.e. default
(i.e. default router, it can be home agent) during the binding de- router, it can be home agent) during the binding de- registration and
registration and construct the packet including layer 2 header with construct the packet including layer 2 header with the learnt layer-2
the learned home agent's layer-2 address. address of the default router or the home agent.
5.7. Receiving Binding Acknowledgment 5.7. Receiving Binding Acknowledgement
The verification of a Binding Acknowledgment is the same as Mobile The verification of a Binding Acknowledgement is the same as Mobile
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
Binding Acknowledgment is described in Section 6.3. Binding Acknowledgement is described in Section 6.3.
If a mobile node includes a Binding Identifier mobility option in a If a mobile node includes a Binding Identifier mobility option in a
Binding Update with A flag set, a Binding Acknowledgment MUST carry a Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
Binding Identifier mobility option in the Mobility Options field. If carry a Binding Identifier mobility option. If no such mobility
no such mobility option is included in the Binding Acknowledgment option is included in the Binding Acknowledgement in response to a
replied to the Binding Update for the multiple care-of address Binding Update for multiple care-of address registration, this
registration, this indicates that the originator node of this Binding indicates that the originating node of the Binding Acknowledgement
Acknowledgment might not recognize the Binding Identifier mobility does not support processing the Binding Identifier mobility option.
option. The mobile node SHOULD stop registering multiple care-of The mobile node MUST then stop multiple care-of address registration
addresses by using a Binding Identifier mobility option. with that node.
If a Binding Identifier mobility option is present in the received If a Binding Identifier mobility option is present in the received
Binding Acknowledgment, the mobile node checks the registration Binding Acknowledgement, the mobile node checks the status field in
status for the Care-of address(es). The status value MUST be the option. If the status value in the Binding Identifier mobility
retrieved as follows. If the status value in the Binding Identifier option is zero, the mobile node uses the value in the Status field of
mobility option is zero, the mobile node uses the value in the Status the Binding Acknowledgement. Otherwise, it uses the value in the
field of the Binding Acknowledgment. Otherwise, it uses the value in Status field of the Binding Identifier mobility option.
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 to 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 NOT SUPPORT], the
mobile node SHOULD stop using bulk registration to the peer mobile node SHOULD stop using bulk registrations with the node
sending the Binding Acknowledgment. that sent the Binding Acknowledgement.
o If [MCOA MALFORMED] is specified, it indicates that the binding o If [MCOA MALFORMED] is specified, it indicates that the binding
identifier mobility option is formatted wrongly. For example, if identifier mobility option is formatted wrongly.
the C flag is set, all mobility 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 o If [MCOA BID CONFLICT] is specified, the binding entry specified
by the Binding Identifier mobility option is already registered as by the Binding Identifier mobility option is already registered as
a regular binding. In such case, the mobile node SHOULD stop a regular binding. In such case, the mobile node SHOULD stop
sending Binding Updates with BID, or SHOULD use O flag for the sending Binding Updates with BID, or SHOULD use the 'O' flag to
peer to reset all the registered bindings. reset all the registered bindings.
5.8. Receiving Binding Refresh Request 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 [RFC-3775]). The operation of sending
a Binding Refresh Request is described in section Section 6.4. a Binding Refresh Request is described in section Section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding If a mobile node receives a Binding Refresh Request with a Binding
Identifier mobility 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 the mobile node to send
the respective binding. The mobile node MUST put a Binding a new Binding Update for the BID. The mobile node SHOULD then send a
Identifier mobility option into the Binding Update sent to refresh Binding Update only for the respective binding. The mobile node MUST
the entry. include a Binding Identifier mobility option in the Binding Update.
If no Binding Identifier mobility option is present in a Binding If no Binding Identifier mobility option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according to Refresh Request, the mobile node sends a Binding Update according to
its Binding Update List. On the other hand, if the mobile node does 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 not have any Binding Update List entry for the requesting node, the
mobile node needs to register either a single binding or multiple mobile node needs to register either a single binding or multiple
bindings depending on its binding management policy. bindings depending on its binding management policy.
5.9. Sending Packets to Home Agent 5.9. Bootstrapping
When a multihomed mobile node sends packets to its home agent, there
are conceptually two ways to construct packets.
1. Using Home Address Option. (required additional 24 bytes)
2. Using IPv6-IPv6 tunnel. (required additional 40 bytes)
Beside the additional size of packets, no difference is observed
between these two. The routing path is always the same and no
redundant path such as dog-leg route 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.10. Bootstrapping
When a mobile node bootstraps and registers multiple bindings at the When a mobile node bootstraps and registers multiple bindings for the
first time, it SHOULD set O flag in the Binding Identifier mobility first time, it MUST set the 'O' flag in the Binding Identifier
option. If old bindings still exists at the Home Agent, the mobile mobility option. If old bindings still exists at the home agent, the
node has no way to know which bindings are still remained at the home mobile node has no knowledge of which bindings still exist at the
agent. This scenario happens when a mobile node reboots without home agent. This scenario happens when a mobile node reboots and
correct de-registration. If O flag is used, all the bindings are looses state regarding the registrations. If the 'O' flag is set,
replaced to the new binding(s). Thus, the garbage bindings are all the bindings are replaced by the new binding(s). If the mobile
surely replaced by new bindings registered with the first Binding node receives the Binding Acknowledgement with the status code set to
Update. If the mobile node receives the Binding Acknowledgment with 135 [Sequence number out of window], it MUST retry sending a Binding
the status code set to 135 [Sequence number out of window], it MUST Update with the last accepted sequence number indicated in the
retry sending a Binding Update with the last accepted sequence number Binding Acknowledgement.
which is notified by the Binding Acknowledgment.
For Correspondent nodes, the mobile node cannot use the O flag The 'O' flag can also be used in individual Binding Updates sent to
because of no bulk registration support. Thus, if necessary, it MUST the correspondent nodes to override any existing binding cache
sends a regular binding first to overwrite the remaining bindings at entries at the correspondent node.
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 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Identifier 6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. How to select the the bindings to communicate with the mobile node. This section
most suitable binding from the binding cache database is out of scope explains how to retrieve the desired binding for the binding
in this document. management. This document does not provide any mechnaism to select
the suitable binding for forwarding data packets.
Whenever a correspondent node searches a binding cache for a home A correspondent node SHOULD use both the home address and the BID as
address, it SHOULD uses both the Home Address and the BID as the the search key of the binding cache if it knows the corresponding BID
search key if it knows the corresponding BID. In the example below, (ex. when processing signaling messages). In the example below, if a
if a correspondent node searches the binding with the Home Address correspondent node searches the binding with the home address and
and BID2, it gets binding2 for this mobile node. BID2, it gets binding2 for this mobile node.
binding1 [a:b:c:d::EUI, care-of address1, BID1] binding1 [a:b:c:d::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, care-of address2, BID2] binding2 [a:b:c:d::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, care-of address3, BID3] binding3 [a:b:c:d::EUI, care-of address3, BID3]
Figure 4: Searching the Binding Cache Figure 4: Searching the Binding Cache
A correspondent node basically learns the BID when it receives a A correspondent node learns the BID when it receives a Binding
Binding Identifier mobility option. At the time, the correspondent Identifier mobility option. At that time, the correspondent node
node MUST look up its binding cache database with the Home Address MUST look up its binding cache database with the home address and the
and the BID retrieved from the Binding Update. If the correspondent BID retrieved from the Binding Update. If the correspondent node
node does not know the BID, it searches for a binding with only a does not know the BID, it searches for a binding with only the home
Home Address as performed in Mobile IPv6. In such case, the first address. In such a case, the first matched binding is found. If the
matched binding is found. But which binding entry is returned for correspondent node does not desire to use multiple bindings for a
the normal search depends on implementations. If the correspondent mobile node, it can simply ignore the BID.
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 6.2. Receiving CoTI and Sending CoT
When a correspondent node receives a CoTI message which contains a When a correspondent node receives a CoTI message which contains a
Binding Identifier mobility option, it MUST process it with following Binding Identifier mobility option, it processes it as follows.
steps.
First of all, the CoTI message is verified according to [RFC-3775]. First, the CoTI message is verified as specified in [RFC-3775]. The
The Binding Identifier mobility option MUST be, then, processed as Binding Identifier mobility option is processed as follows:
follows:
o If a correspondent node does not understand a Binding Identifier o If a correspondent node does not understand a Binding Identifier
mobility option, it just ignores and skip this option. The mobility option, it just ignores and skips processing the option.
calculation of a care-of Keygen token will thus be done without a The calculation of a care-of Keygen token will thus be done
BID value. The correspondent node returns a CoT message without a without a BID value. The correspondent node returns a CoT message
Binding Identifier mobility option. The mobile node can thus know without a Binding Identifier mobility option. The mobile node
whether the correspondent can process the Binding Identifier knows whether the correspondent supports processing the Binding
mobility option or not, by checking if such option is present in Identifier mobility option, by checking if the option is present
the CoT message. in the CoT message.
o If either or both C and O flag is set in the mobility option, the o If either the 'C' or the 'O' flag is set in the Binding Identifier
Correspondent Node SHOULD NOT calculate a care-of Keygen token and mobility option, the correspondent Node SHOULD NOT calculate a
MUST include a Binding Identifier mobility option which status care-of Keygen token, but MUST include a Binding Identifier
value set to [MCOA MALFORMED] in the returned Care-of Test mobility option with status value set to [MCOA MALFORMED] in the
message. Care-of Test message.
o Otherwise, the correspondent node MUST include a Binding o Otherwise, the correspondent node MUST include a Binding
Identifier mobility option which status value MUST be set to zero Identifier mobility option with status value set to zero (success)
in the returning a CoT message. in the Care-of Test message.
o All the Binding Identifier mobility options SHOULD be copied from o The Care-of address field of each Binding Identifier mobility
the received one except for the Status Field for CoT. The Care-of option, can be omitted, because the mobile node can identify the
address field of each Binding Identifier mobility option, however, corresponding Binding Update list entry using the BID.
can be omitted, because the mobile node can match a corresponding
binding update list by using BID.
6.3. Processing Binding Update 6.3. Processing Binding Update
If a Binding Update does not contain a Binding Identifier mobility If a Binding Update does not contain a Binding Identifier mobility
option, its processing is same as in [RFC-3775]. But if the receiver option, its processing is same as in [RFC-3775]. If the receiver
already has multiple bindings for the home address, it MUST replace already has multiple bindings for the home address, it MUST replace
all the existing bindings by the received binding. As a result, the 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 receiver node MUST have only one binding cache entry for the mobile
Binding Update is for de-registration, the receiver MUST delete all node. If the Binding Update is for de-registration, the receiver
existing bindings from its Binding Cache. MUST delete all existing bindings from its Binding Cache.
If a Binding Update contains a Binding Identifier mobility 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
home agent MUST carefully operate Duplicate Address Detection
(DAD) for the received Home Address. If the home agent has
already had a binding(s) for the Mobile Node, it MUST avoid
running DAD check when it receives the Binding Update.
The receiver node MUST process the Binding Identifier mobility
option(s) in the following steps. When a correspondent node sends a
Binding Acknowledgment, the status value MUST be always stored in the
Status field of the Binding Acknowledgment and keep the Status field
of Binding Identifier mobility option to zero.
For the Home Agent, the status value can be stored in the Status If the Binding Update contains a Binding Identifier mobility
field of either a Binding Acknowledgment or a Binding Identifier option(s), it is first validated according to section 9.5.1 of [RFC-
mobility option. If the status value is specific to one of bindings 3775]. Then the receiver processes the Binding Identifier mobility
in the bulk registration, the status value MUST be stored in the option(s) as described in the following steps.
Status field in the corresponding Binding Identifier mobility option.
In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of
the Binding Acknowledgment so that the receiver can examine the
Status field of each Binding Identifier mobility option for further
operations.
o The length value is examined. The length value MUST be either 4, o The length value is examined. The length value MUST be either 4,
8, or 20 depending on C and D flag. If the length is incorrect, 8, or 20 depending on the 'C' and 'D' flags. If the length is
the receiver MUST rejects the Binding Update and returns the incorrect, the receiver MUST reject the Binding Update and returns
status value set to [MCOA MALFORMED]. the status value set to [MCOA MALFORMED].
o When C flag is specified, the care-of address MUST be given in the o When the 'C' flag is set, the care-of address MUST be present in
Binding Identifier mobility option. Otherwise, the receiver MUST the Binding Identifier mobility option. If the care-of address is
reject the Binding Identifier mobility option and returns the not present, the receiver MUST reject the Binding Identifier
status value set to [MCOA MALFORMED]. The operation of D flag is mobility option and returns the status value set to [MCOA
described in Section 8 MALFORMED]. The operation of 'D' flag is described in Section 8
o When multiple binding Identifier mobility options are presented, o When multiple Binding Identifier mobility options are present in
the receiver MUST support the bulk registration. Only a home the Binding Update, it is treated as bulk registration. If the
agent can accept the bulk registration. Otherwise, it MUST reject receiving node is a correspondent node, it MUST reject the Binding
the Binding Update and returns the status value set to [MCOA BULK Update and returns the status value in the binding acknowledgement
REGISTRATION NOT SUPPORT] in the Binding Acknowledgment. set to [MCOA BULK REGISTRATION NOT SUPPORT]
o If the Lifetime field of the Binding Update is zero, the receiver o If the Lifetime field in the Binding Update is set to zero, the
node deletes the binding entry which BID is same as BID sent by receiving node deletes the binding entry that corresponds to the
the Binding Identifier mobility option. If the receiver node does BID in the Binding Identifier mobility option. If the receiving
not have appropriate binding which BID is matched with the Binding node does not have an appropriate binding for the BID, it MUST
Update, it MUST reject this de-registration Binding Update for the reject the Binding Update and send a Binding Acknowledgement with
binding cache. If the receiver is a Home Agent, it SHOULD also status set to 133 [not home agent for this mobile node].
return the status value set to [not Home Agent for this mobile
node, 133].
o If O flag is set in the de-registering Binding Update, the o If the 'O' flag is set in the de-registering Binding Update, it is
receiver can ignore this flag for de-registration. If the H flag ignored. If the 'H' flag is set, the home agent stores a home
is set, the home agent stores a Home Address in the Care-of address in the Care-of Address field of the binding cache entry.
Address field of the binding cache entry. The home agent no The home agent also stops performing proxy ND for the mobile
longer performs proxy NDP for this mobile node until this entry is node's home address.
deleted.
o If the Lifetime field is not zero, the receiver node registers a o If the Lifetime field is not set to zero, the receiving node
binding with the specified BID as a mobile node's binding. The registers a binding with the specified BID as a mobile node's
Care-of address is picked from the Binding Update packet as binding. The Care-of address is obtained from the Binding Update
follows: packet as follows:
* If C flag is set in the Binding Identifier mobility option, the * If the 'C' flag is set in the Binding Identifier mobility
care-of address must be taken from the care-of address field in option, the care-of address is copied from the care-of address
each Binding Identifier mobility option. field in the Binding Identifier mobility option.
* If C flag is not set in the Binding Identifier mobility option, * If the 'C' flag is not set in the Binding Identifier mobility
the care-of address must be taken from the Source Address field option, the care-of address is copied from the source address
of the IPv6 header. field of the IPv6 header.
* If C flag is not set and an alternate care-of address is * If the 'C' flag is not set and an alternate care-of address is
present, the care-of address is taken from the Alternate present, the care-of address is copied from the Alternate
Care-of address mobility option. Care-of address mobility option.
o Once the care-of address(es) has been retrieved from the Binding o Once the care-of address(es) have been retrieved from the Binding
Update, it starts registering binding(s). Update, the receiving nodes creates new binding(s).
* Only if O flag is set in the mobility option, the home agent * If only the 'O' flag is set in the Binding Identifier mobility
first removes all the existing bindings and registers the option, the home agent removes all the existing bindings and
received bindings. registers the received bindings.
* If the receiver has a regular binding which does not have BID * If the receiver has a regular binding which does not have BID
for the mobile node, it de-registers the regular binding and for the mobile node, it must not process the binding update.
registers a new binding including BID according to the Binding The receiver should sent a binding acknowledgement with status
Update. In this case, the receiver MUST return [MCOA BID set to [MCOA BID CONFLICT].
CONFLICT].
* If the receiver node has already registered the binding which * If the receiver already has a binding with the same BID but
BID is matched with requesting BID, then it MUST update the different care-of address, it MUST update the binding and
binding with the Binding Update and returns [0 Binding Update respond with a Binding Acknowledgement with status set to 0
accepted]. [Binding Update accepted].
* If the receiver does not have a binding entry which BID is * If the receiver does not have a binding entry for the BID, it
matched with the requesting BID, it registers a new binding for registers a new binding for the BID and responds with a Binding
the BID and returns [0 Binding Update accepted]. Acknowledgement with status set to 0 [Binding Update accepted].
If all the above operations are successfully finished, the Binding If all the above operations are successfully completed, a Binding
Acknowledgment containing the Binding Identifier mobility options Acknowledgement containing the Binding Identifier mobility options
MUST be replied to the mobile node if A flag is set in the Binding MUST be sent to the mobile node. Whenever a Binding Acknowledgement
Acknowledgment. Whenever a Binding Acknowledgment is returned, all is sent, all the Binding Identifier mobility options stored in the
the Binding Identifier mobility options stored in the Binding Update Binding Update MUST be copied to the Binding Acknowledgement except
MUST be copied to the Binding Acknowledgment. The Care-of address the status field. The Care-of address field in each Binding
field of each Binding Identifier mobility option, however, can be Identifier mobility option, however, can be omitted, because the
omitted, because the mobile node can match a corresponding binding mobile node can match a corresponding binding update list entry using
update list by using BID. the BID.
When a correspondent node sends a Binding Acknowledgement, the status
value MUST be always stored in the Status field of the Binding
Acknowledgement and the Status field of Binding Identifier mobility
option set to zero. For the home agent, the status value can be
stored in the Status field of either a Binding Acknowledgement or a
Binding Identifier mobility 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 Identifier
mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the
Status field of the Binding Acknowledgement so that the receiver can
examine the Status field of each Binding Identifier mobility option
for further operations.
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 Identifier Refresh Request for a particular binding created with the BID, the
mobility option in the Binding Refresh Request. node SHOULD include the Binding Identifier mobility option in the
Binding Refresh Request. If the mobile node had used bulk
registration, the sender SHOULD include all the Binding Identifier
mobility options. If the mobile node had not used bulk registration,
the sender includes the Binding Identifier mobility options only for
those 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 MUST be equal
addresses in the binding cache entry. If no binding is found, the to 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 silently discarded. The node
message according to RFC3775. This verification MUST NOT be done for MUST also send a Binding Error message as specified in [RFC-3775].
a Binding Update. This 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 [RFC-3963]. 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.
Since the binding management mechanisms are the same for a mobile
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 an example format of a Binding Update
used by a mobile router.
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier
- Mobile Network Prefix
Figure 5: NEMO Binding Update
8. DSMIPv6 Applicability 8. DSMIPv6 Applicability
Dual Stack Mobile IPv6 (DSMIPv6) extends Mobile IPv6 to register an Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
IPv4 care-of address instead of the IPv6 care-of address when the register an IPv4 care-of address instead of the IPv6 care-of address
mobile node is attached to an IPv4-only access network. It also when the mobile node is attached to an IPv4-only access network. It
allows the mobile node to acquire an IPv4 home address in addition to also allows the mobile node to acquire an IPv4 home address in
an IPv6 home address for use with IPv4-only correspondent nodes. addition to an IPv6 home address for use with IPv4-only correspondent
This section describes how multiple care-of address registration nodes. This section describes how multiple care-of address
works with IPv4 care-of and home addresses. registration works with IPv4 care-of and home addresses.
8.1. IPv4 Care-of Address Registration 8.1. IPv4 Care-of Address Registration
In DSMIPv6, the binding update and acknowledgment exchange is used to The mobile node can use the extensions described in the document to
detect NAT. Thus, when a mobile node registers its IPv4 care-of register multiple care-of addresses, even if some of the care-of
address bound to IPv6 home address, it MUST first attempt to send a addresses are IPv4 address.
Binding Update with Binding Identifier mobility option independently.
The bulk registration MUST NOT be used for the first binding update Bulk registration MUST NOT be used for the initial binding from an
of the IPv4 care-of address. The Binding Update MUST be sent to the IPv4 care-of address. This is because, the Binding Update and
IPv4 home agent address by using UDP and IPv4 headers as shown in binding acknowledgement exchange is used to detect NAT on the path
Figure 6. It is similar to [DSMIP] except for using BID mobility between the mobile node and the home agent. So the mobile node needs
option instead of IPv4 care-of address option. 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 5. It is similar to
[ID-DSMIPv6] 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) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header UDP Header
IPv6 header (src=V6HoA, dst=HAADDR) IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header ESP Header
Mobility header Mobility header
-BU -BU
Mobility Options Mobility Options
- Binding Identifier (IPv4 CoA) - Binding Identifier (IPv4 CoA)
Figure 6: Initial Binding Update for IPv4 Care-of Address Figure 5: Initial Binding Update for IPv4 Care-of Address
When the home agent detects NAT for the received binding update, it
MUST send the NAT detection option in the Binding Acknowledgment.
Whenever the NAT detection option is found, the mobile node MUST NOT
use the bulk registration for the IPv4 care-of address. Otherwise,
it can send the IPv4 care-of address with other care-of addresses in
the bulk registration mode. How to handle NAT is same as [DSMIP].
If NAT is not detected, the mobile node can update the IPv4 care-of 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 address by using bulk registration. The mobile node can register the
IPv4 care-of address with other care-of addresses. Figure 7 shows IPv4 care-of address along with other IPv4 and IPv6 care-of
the binding update format when the mobile node sends a Binding Update addresses. Figure 6 shows the Binding Update format when the mobile
from one of its IPv6 care-of addresses. If the mobile node sends a node sends a Binding Update from one of its IPv6 care-of addresses.
BU from IPv4 care-of address, it MUST follows the Figure 6 and store If the mobile node sends a BU from IPv4 care-of address, it MUST
more BID mobility options in the mobility options field. Note that follow the format described in Figure 5. Note that the IPv4 Care-of
IPv4 Care-of Address must be registered by non bulk Binding Address must be registered by non bulk Binding registration, whenever
registration, whenever it is changed. NAT detection MUST be carried it is changed.
out for every new IPv4 addresses.
IPv6 header (src=V6CoA, dst=HAADDR) IPv6 header (src=V6CoA, dst=HAADDR)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
-BU -BU
Mobility Options Mobility Options
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA)
- ... - ...
Figure 7: Binding Bulk Registration for IPv4 care-of address Figure 6: Binding Bulk Registration for IPv4 care-of address
If the IPv4 care-of address is successfully registered, the mobile
node sets up a relevant tunnel to the home agent according to
[DSMIP].
If the home agent rejects the IPv4 care-of address, it MUST store the If the home agent rejects the IPv4 care-of address, it MUST store the
error code value in the Status field of the BID mobility option. The error code value in the Status field of the BID mobility option.
home agent MUST send the binding acknowledgment and all the received
BID mobility options to the mobile node. In this case, the IPv4
address acknowledgment option MUST NOT be included in the Binding
Acknowledgment. All the error codes for IPv4 care-of address
registration MUST be stored in the Status field of the BID mobility
option. The IPv4 address acknowledgment option is used only when a
mobile node requests IPv4 home address management.
8.2. IPv4 HoA Management 8.2. IPv4 HoA Management
When the mobile node obtains an IPv4 home address, it MUST store the When the mobile node wants to configure an IPv4 home address in
addition to the IPv6 home address, it can request for one using the
IPv4 Home Address option in the Binding Update. If the home agent IPv4 Home Address option in the Binding Update. If the home agent
accepts the binding update, the mobile node can also register accepts the Binding Update, the mobile node can now register multiple
multiple care-of addresses for the IPv4 home address in addition to care-of addresses for the IPv4 home address in addition to the IPv6
the IPv6 home address. The same set of care-of addresses will be home address. The same set of care-of addresses will be registered
registered for both IPv6 and IPv4 home addresses. The mobile node for both IPv6 and IPv4 home addresses. The mobile node cannot bind
cannot binding different set of care-of addresses to each home different set of care-of addresses to each home address.
address.
The home agent MUST returns a binding acknowledgment and IPv4 address According to [ID-DSMIPv6], the home agent includes the IPv4 address
acknowledgment option to the mobile node only when a mobile node acknowledgement option in the Binding Acknowledgement only if the
requests IPv4 home address mobility management. In this case, this mobile node had requested for an IPv4 home address in the
option MUST be presented before any BID options. The status field of corresponding Binding Update. The IPv4 address acknowledgement
the IPv4 address acknowledgment option contains only the error code option MUST be present before any BID option. The status field of
regarding IPv4 home address management. The error value of the IPv4 the IPv4 address acknowledgement option contains only the error code
care-of address registration MUST be stored in the BID mobility corresponding to the IPv4 home address management. The error values
option. related to the IPv4 care-of address registration MUST be stored in
the BID mobility option.
9. IPsec and IKEv2 interaction 9. IPsec and IKEv2 interaction
Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
use of IPsec to protect signaling messages like Binding Updates, use of IPsec to protect signaling messages like Binding Updates,
Binding Acknowledgments and return routability messages. IPsec may Binding Acknowledgements and return routability messages. IPsec may
also be used protect all reverse tunneled data traffic. The Mobile also be used protect all tunneled data traffic. The Mobile IPv6-
IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to
to setup the required IPsec security associations. The following setup the required IPsec security associations. The following
assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with
specification with respect to the use of IKEv2 and IPsec. 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
skipping to change at page 31, line 20 skipping to change at page 29, line 20
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 For Mobile Prefix Discovery messages, [RFC-3775] requires the home
agent to verify that the mobile node is using the care-of address agent to verify that the mobile node is using the care-of address
that is in the binding cache entry that corresponds to the mobile 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 node's home address. If a different address is used as the source
address, the message is silently dropped by the home agent. This address, the message is silently dropped by the home agent. This
document requires the home agent implementation to process the document requires the home agent implementation to process the
message as long as the source address is is one of the care-of message as long as the source address is one of the care-of addresses
addresses in the binding cache entry for the mobile node. in the binding cache entry for the mobile node.
9.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 address
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 [RFC-3775] mandates the use of
IPsec protection in tunnel mode for the HoTi and HoT messages. The IPsec protection in tunnel mode for the HoTi and HoT messages. The
mobile node and the home agent may also choose to protect all reverse mobile node and the home agent may also choose to protect all reverse
tunneled payload traffic with IPsec in tunnel mode. The following tunneled payload traffic with IPsec in tunnel mode. The following
skipping to change at page 33, line 7 skipping to change at page 31, line 7
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 may 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 must specify
the tunnel end point for the IPsec tunnel. This may require tight the tunnel end point for the IPsec tunnel. This may require tight
integration between the IPsec and Mobile IP implementations on the integration between the IPsec and Mobile IP implementations on the
home agent. home agent.
10. Security Considerations 10. Security Considerations
As shown in Section 9, the Multiple Care-of Addresses Registration The security considerations for securing the Binding Update and
requires IPsec protection for all the signaling between a mobile node binding acknowledgement messages with multiple care-of address are
and its home agent. very similar to the security considerations for securing the Binding
Update and binding acknowledgement. Please see [RFC-3775] for more
information. The Binding Update and binding acknowledgement messages
with multiple care-of addresses MUST be protected using IPsec as show
in Section 9. Additional security considerations are described
below.
With simultaneous binding support, it is possible for a malicious With simultaneous binding support, it is possible for a malicious
mobile node to successfully bind a number of victims' addresses as mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home agent. valid care-of addresses for the mobile node with its home agent.
Once these addresses have been bound, the malicious mobile node can Once these addresses have been bound, the malicious mobile node can
perform a re-direction attack by instructing the home agent (e.g. perform a re-direction attack by instructing the home agent (e.g.
setting filtering rules to direct a large file transfer) to tunnel setting filtering rules to direct a large file transfer) to tunnel
packets to the victims' addresses. Such risk is highlighted in [ID- packets to the victims' addresses. Such risk is highlighted in [ID-
MIP6ANALYSIS] and is possible because the care-of addresses specified MIP6ANALYSIS]. These attacks are possible because the care-of
by the mobile node in the binding update messages are not verified by addresses sent by the mobile node in the Binding Update messages are
home agent (since Mobile IPv6 assumes an existing trust relationship not verified by home agent, i.e., the home agent does not check if
between the mobile node and its home agent). the mobile node is at the care-of address it is claiming 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.
Although such risk exists in Mobile IPv6, the risk level is escalated Although such risk exists in Mobile IPv6, the risk level is escalated
when simultaneous multiple care-of address bindings are performed. when simultaneous multiple care-of address bindings are performed.
One fundamental difference is the degree of risk involved is much In Mobile IPv6, a mobile node can only have a single care-of address
greater in the simultaneous binding support case. For a single binding per home address at a given time. However, for simultaneous
care-of address binding, a mobile node can only have a single care-of multiple care-of address bindings, a mobile node can have more than
address binding per home address at a given time. However, for one care-of address binding per home address at a given time. This
simultaneous multiple care-of address bindings, a mobile node can implies that a mobile node using simultaneous binding support can
have more than one care-of address binding per home address at a effectively bind more than a single victim's address. Another
given time. This implies that a mobile node using simultaneous difference is the degree of risk involved. In the single care-of
binding support can effectively bind more than a single victim's address binding case, once the re-direction attack is initiated, a
address. Another fundamental difference is the form of risk malicious mobile node would be unable to use its home address for
involved. In the single care-of address binding case, once the re- communications (such as to receive control packets pertaining to the
direction attack is initiated, a malicious mobile node would be file transfer). However, in the simultaneous binding support case, a
unable to use its home address for communications (such as to receive malicious mobile node could bind a valid care-of address in addition
control packets pertaining to the file transfer). However, in the to multiple victims addresses. This valid care-of address could then
simultaneous binding support case, a malicious mobile node could bind be used by the malicious mobile node to set up flow filtering rules
a valid care-of address in addition to multiple victims addresses. at its home agent, thereby controlling and/or launching new re-
This valid care-of address could then be used by the malicious mobile direction attacks.
node to set up flow filtering rules at its home agent, thereby
controlling and/or launching new re-direction attacks.
Thus, in view of such risk, it is advisable for a home agent to Thus, in view of such risks, it is advisable for a home agent to
employ some form of care-of address verification mechanism before employ some form of care-of address verification mechanism before
using the care-of addresses as a valid routing path to a mobile node. using the care-of addresses as a valid routing path to a mobile node.
Some solutions to advert such problems are described in Appendix. Solutions related to this are described in [ID-COAVERIFY].
11. IANA Considerations 11. IANA Considerations
The following Extension Types MUST be assigned by IANA: The following Extension Types MUST be assigned by IANA:
o Binding Identifier mobility option type:This must be assigned from o Binding Identifier mobility option type: This must be assigned
the same space as mobility option in [RFC3775]. from the same space as mobility option in [RFC-3775].
o New Successful Status of Binding Acknowledgment:This status code o New Successful Status of Binding Acknowledgement: This status code
must be assigned from the same space as binding acknowledgement must be assigned from the same space as binding acknowledgement
status codes in [RFC3775]. status codes in [RFC-3775].
* MCOA NOTCOMPLETE (TBD) * MCOA NOTCOMPLETE (TBD)
o New Unsuccessful Status of Binding Acknowledgment: These status o New Unsuccessful Status of Binding Acknowledgement: These status
codes must also be assigned from the same space as binding codes must also be assigned from the same space as binding
acknowledgement status codes in [RFC3775]. acknowledgement status codes in [RFC-3775].
* MCOA MALFORMED (TBD) * MCOA MALFORMED (TBD)
* MCOA BID CONFLICT (TBD) * MCOA BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD) * MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD) * MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
12. Acknowledgments 12. Acknowledgements
The authors would like to thank Masafumi Aramoto (Sharp Corporation), The authors would like to thank Masafumi Aramoto, George Tsirtsis,
George Tsirtsis (Qualcomm), Keigo Aso (Panasonic), Julien Charbon, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Susumu
Tero Kauppinen (Ericsson), Benjamin Lim (Panasonic), Susumu Koshiba, Koshiba, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Hiroki
Martti Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, Keisuke
(Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Uehara, Masafumi Watari in alphabetical order, and the Jun Murai
Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), Laboratory at the KEIO University.
Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab.
at KEIO University.
13. References 13. References
13.1. Normative References 13.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-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
2007.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[RFC-4886] Ernst, T., "Network Mobility Support Goals and
Requirements", RFC 4886, July 2007.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
13.2. Informative References 13.2. Informative References
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
K. Kuladinithi, "Motivations and Scenarios for Using Multiple K. Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), July 2007 progress), July 2007
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007. Multihoming in Network Mobility Support", RFC 4980, October 2007.
[RFC-3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
RFC 3972, March 2005. K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
2007.
[RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
Optimization for Mobile IPv6", RFC 4866, May 2007. RFC 3753, June 2004.
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
792, September 1981. Terminology", RFC 4885, July 2007.
[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in
progress), November 2007.
[ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-01 (work in progress), February
2008.
Appendix A. Example Configurations Appendix A. Example Configurations
In this section, we describe typical scenarios when a mobile node has In this section, we describe typical scenarios when a mobile node has
multiple network interfaces and acquires multiple Care-of Addresses multiple network interfaces and acquires multiple Care-of Addresses
bound to a Home Address. The Home Address of the mobile node (MN in 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 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 acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns
BID1, BID2 and BID3 to each care-of address. BID1, BID2 and BID3 to each care-of address.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
skipping to change at page 37, line 38 skipping to change at page 36, line 38
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 8: Multiple Interfaces Attached to a Foreign Link Figure 7: Multiple Interfaces Attached to a Foreign Link
Figure 8 depicts the scenario where all interfaces of the mobile node Figure 7 depicts the scenario where all interfaces of the mobile node
are attached to foreign links. After binding registrations, the home are attached to foreign links. After binding registrations, the home
agent (HA) and the Correspondent Node (CN) have the binding entries agent (HA) and the correspondent node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize listed in their binding cache database. The mobile node can utilize
all the interfaces. all the interfaces.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +--------+-+ +--+-+ | +--------+-+ +--+-+
skipping to change at page 38, line 26 skipping to change at page 37, line 26
CoA3| +---|-----------+ CoA3| +---|-----------+
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
home agent's binding home agent's binding
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 9: One of Interface Attached to Home Link and Returning Home Figure 8: One of Interface Attached to Home Link and Returning Home
Figure 9 depicts the scenario where MN returns home with one of its Figure 8 depicts the scenario where MN returns home with one of its
interfaces. After the successful de-registration of the binding to interfaces. After the successful de-registration of the binding to
HA, HA and CN have the binding entries listed in their binding cache HA, HA and CN have the binding entries listed in their binding cache
database of Figure 9. After de-registration, the ND state of the database of Figure 8. After de-registration, the ND state of the
home address is managed by the MN. MN can communicate with the HA home address is managed by the MN. MN can communicate with the HA
through only the interface attached to the home link. On the other through only the interface attached to the home link. On the other
hand, the mobile node can communicate with CN from the other hand, the mobile node can communicate with CN from the other
interfaces attached to foreign links (i.e. route optimization). Even interfaces attached to foreign links (i.e. route optimization). Even
if MN is attached to the home link, it can still send Binding Updates if MN is attached to the home link, it can still send Binding Updates
for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has
bindings, packets are routed to each Care-of Addresses directly. Any bindings, packets are routed to each Care-of Addresses directly. Any
packet arrived at HA are routed to the interface attached to the home packet arrived at HA are routed to the interface attached to the home
link. link.
skipping to change at page 39, line 28 skipping to change at page 38, line 28
(Disable interface) (Disable interface)
Binding Cache Database: Binding Cache Database:
home agent's binding home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 10: One of Interface Attached to Home Link and Not Returning Figure 9: One of Interface Attached to Home Link and Not Returning
Home Home
Figure 10 depicts the scenario where MN disables the interface Figure 9 depicts the scenario where MN disables the interface
attached to the home link and communicates with the interfaces attached to the home link and communicates with the interfaces
attached to foreign links. HA continues managing the ND state of the attached to foreign links. HA continues managing the ND state of the
home address by Proxy neighbor advertisement. The HA and the CN have home address by Proxy neighbor advertisement. The HA and the CN have
the binding entries listed in their binding cache database. All the binding entries listed in their binding cache database. All
packets routed to the home link are intercepted by the HA and packets routed to the home link are intercepted by the HA and
tunneled to the other interfaces attached to the foreign link tunneled to the other interfaces attached to the foreign link
according to the binding entries. according to the binding entries.
Topology-a) Topology-a)
+----+ +----+
skipping to change at page 40, line 44 skipping to change at page 39, line 44
Binding Cache Database: Binding Cache Database:
home agent's binding home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 11: Utilize Interfaces Attached to both Home and Foreign Links Figure 10: Utilize Interfaces Attached to both Home and Foreign Links
Figure 11 depicts the scenario where interfaces of MN are attached to Figure 10 depicts the scenario where interfaces of MN are attached to
both the home and foreign links. There are two possible topologies both the home and foreign links. There are two possible topologies
whether the HA is single router at the home link or not. The whether the HA is single router at the home link or not. The
operation of ND is different in two topologies. The HA and CN have operation of ND is different in two topologies. The HA and CN have
the binding entries listed in Figure 11 in their binding cache the binding entries listed in Figure 10 in their binding cache
database regardless of topologies. The HA also knows that the MN has database regardless of topologies. The HA also knows that the MN has
attached to the home link. All the traffic from the Internet are attached to the home link. All the traffic from the Internet are
intercepted by the HA and routed to either the interface attached to intercepted by the HA and routed to either the interface attached to
the home link or the interfaces attached to the foreign links. How the home link or the interfaces attached to the foreign links. How
to make the decision is out of scope in this document. to make the decision is out of scope in this document.
There are two different treatments of the ND state of the home There are two different treatments of the ND state of the home
address. address.
o MN defends the home address by regular ND (topology-a) o MN defends the home address by regular ND (topology-a)
o HA defends the home address by Proxy ND (topology-b) o HA defends the home address by Proxy ND (topology-b)
The first case is required that the HA is the single exit router to The first case is required that the HA is the single exit router to
the Internet and is capable of intercepting packets without relying the Internet and is capable of intercepting packets without relying
on proxy ND. The MN can manage the ND of the home address on the on proxy ND. The MN can manage the ND of the home address on the
home link. In the second case, the HA is not only router at the home home link. In the second case, the HA is not only router at the home
link and cannot intercept all the packets meant for the MN by IP link and cannot intercept all the packets meant for the MN by IP
routing. The HA needs to run Proxy ND to intercept all the packets routing. The HA needs to run Proxy ND to intercept all the packets
at the home link. Since the MN cannot operate the ND of its home at the home link. Since the MN cannot operate the ND of its home
addrss at the home link, HA cannot resolve the layer-2 address of the address at the home link, HA cannot resolve the layer-2 address of
MN at the home link. The HA MUST learn and record the layer-2 the MN at the home link. The HA MUST learn and record the layer-2
address (MAC address) of the MN's interface attached to the home link address (MAC address) of the MN's interface attached to the home link
to forward packets. The packets forwarding is achieved without ND to forward packets. The packets forwarding is achieved without ND
cache. The MN is also required to learn and record the layer-2 cache. The MN is also required to learn and record the layer-2
address of the HA's interface to send packets from the home link. address of the HA's interface to send packets from the home link.
Appendix B. Changes From Previous Versions
Changes from draft-ietf-monami6-multiplecoa-04.txt
o Binding Unique Identifier is renamed to Bidning Identifier
o New Status Code [MCOA NOTCOMPLETE], the home agent uses this
status code in the Binding Acknowledgement when not all the
bindings are accepted in the bulk registration.
o [MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED]
o Add care-of address verification issue in the Security
Consideration, the text is proposed by Benjamin Lim.
o Support DSMIPv6
o Support simultaneous foreign and home location. (Section 5.5)
o Editorial updates, thanks George Tsirtsis for detailed comments!
Authors' Addresses Authors' Addresses
Ryuji Wakikawa (Editor) Ryuji Wakikawa (Editor)
Faculty of Environment and Information Studies, Keio University Faculty of Environment and Information Studies, Keio University
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100 Phone: +81-466-49-1100
Fax: +81-466-49-1395 Fax: +81-466-49-1395
 End of changes. 180 change blocks. 
794 lines changed or deleted 682 lines changed or added

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