draft-ietf-monami6-multiplecoa-04.txt   draft-ietf-monami6-multiplecoa-05.txt 
Monami6 Working Group R. Wakikawa (Editor) Monami6 Working Group R. Wakikawa (Editor)
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track T. Ernst Intended status: Standards Track T. Ernst
Expires: May 22, 2008 INRIA Expires: July 31, 2008 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli V. Devarapalli
Azaire Networks Azaire Networks
November 19, 2007 January 28, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-04.txt draft-ietf-monami6-multiplecoa-05.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 May 22, 2008. This Internet-Draft will expire on July 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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, termed the primary
care-of address, can be registered with its home agent and the care-of address, can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay, correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through etc, it is useful for the mobile node to get Internet access through
multiple access media simultaneously, in which case multiple active multiple access media simultaneously, in which case multiple active
IPv6 care-of addresses would be assigned to the mobile node. We thus IPv6 care-of addresses would be assigned to the mobile node. We thus
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Mobile IPv6. 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 . . . . . . . . . . . . . . . . . . . . 10 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9
4.1. Binding Cache Structure and Binding Update List . . . . . 10 4.1. Binding Cache Structure and Binding Update List . . . . . 9
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 9
4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 4.2.1. Binding Identifier Mobility Option . . . . . . . . . . 9
4.3. New Status Values for Binding Acknowledgment . . . . . . . 12 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 Unique 5.1. Management of Care-of Addresses and Binding Identifier . . 13
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 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. Binding Bulk Registration . . . . . . . . . . . . . . . . 15
5.5. Binding De-Registration and Returning Home . . . . . . . . 16 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16
5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 17 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16
5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 18 5.6.1. Using only Interface attached to the Home Link . . . . 16
5.8. Sending Packets to Home Agent . . . . . . . . . . . . . . 19 5.6.2. Using only Interface attached to the Visited Link . . 16
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 19 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17
5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 19
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20
5.9. Sending Packets to Home Agent . . . . . . . . . . . . . . 20
5.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21
6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 6. Home Agent and Correspondent Node Operation . . . . . . . . . 22
6.1. Searching Binding Cache with Binding Unique Identifier . . 21 6.1. Searching Binding Cache with Binding Identifier . . . . . 22
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27
8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 28
8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 28
8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 29
8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28
8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28
8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 30
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 30
9.2. Transport Mode IPsec protected messages . . . . . . . . . 31
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
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Configurations . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 Appendix A. Example Configurations . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Changes From Previous Versions . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
A mobile node should use various type of network interfaces to obtain A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. The assumed scenarios durable and wide area network connectivity. The assumed scenarios
and motivations for multiple points of attachment, and benefits for and motivations for multiple points of attachment, and benefits for
doing it are discussed at large in [ID-MOTIVATION]. doing it are discussed at large in [ID-MOTIVATION].
IPv6 [RFC-2460] conceptually allows a node to have several addresses IPv6 [RFC-2460] conceptually allows a node to have several addresses
on a given interface. Consequently, Mobile IPv6 [RFC-3775] has on a given interface. Consequently, Mobile IPv6 [RFC-3775] has
mechanisms to manage multiple ``Home Addresses'' based on home mechanisms to manage multiple ``Home Addresses'' based on home
agent's managed prefixes such as mobile prefix solicitation and agent's managed prefixes such as mobile prefix solicitation and
mobile prefix advertisement. But assigning a single Home Address to mobile prefix advertisement. But assigning a single Home Address to
a node is more advantageous than assigning multiple Home Addresses a node is more advantageous than assigning multiple Home Addresses
skipping to change at page 5, line 34 skipping to change at page 5, line 34
According to the Mobile IPv6 specification, a mobile node is not According to the Mobile IPv6 specification, a mobile node is not
allowed to register multiple care-of addresses bound to a single Home allowed to register multiple care-of addresses bound to a single Home
Address. Since NEMO Basic Support [RFC-3963] is based on Mobile Address. Since NEMO Basic Support [RFC-3963] is based on Mobile
IPv6, the same issues apply to a mobile node acting as a mobile IPv6, the same issues apply to a mobile node acting as a mobile
router. Multihoming issues pertaining to mobile nodes operating router. Multihoming issues pertaining to mobile nodes operating
Mobile IPv6 and mobile routers operating NEMO Basic Support are Mobile IPv6 and mobile routers operating NEMO Basic Support are
respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6 respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6
and NEMO Working Group. and NEMO Working Group.
In this document, we thus propose a new identification number called In this document, we thus propose a new identification number called
Binding Unique Identification (BID) number for each binding cache Binding Identification (BID) number for each binding cache entry to
entry to accommodate multiple bindings registration. The mobile node accommodate multiple bindings registration. The mobile node notifies
notifies the BID to both its Home Agent and correspondent nodes by the BID to both its Home Agent and correspondent nodes by means of a
means of a Binding Update. Correspondent nodes and the home agent Binding Update. Correspondent nodes and the home agent record the
record the BID into their binding cache. The Home Address thus BID into their binding cache. The Home Address thus identifies a
identifies a mobile node itself whereas the BID identifies each mobile node itself whereas the BID identifies each binding registered
binding registered by a mobile node. By using the BID, multiple by a mobile node. By using the BID, multiple bindings can then be
bindings can then be distinguished. distinguished.
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 Unique 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 BID allows a mobile node to register multiple binding cache
entries for a given Home Address. The BID is conceptually entries for a given Home Address. The BID MUST be unique for a
assigned to a binding in a way it cannot be duplicated with binding to a specific care-of address for a given home address and
another BID. The zero value and a negative value MUST NOT be care-of address pair. The zero value and a negative value MUST
used. After being generated by the mobile node, the BID is stored NOT be used. Each BID is generated and managed by a mobile node.
in the Binding Update List and is sent by the mobile node by means After being generated by the mobile node, the BID is stored in the
of a sub-option of a Binding Update. A mobile node MAY change the Binding Update List and is sent by the mobile node in the Binding
value of a BID at any time according to its administrative policy, Update. A mobile node MAY change the value of a BID at any time
for instance to protect its privacy. An implementation must according to its administrative policy, for instance to protect
carefully assign the BID so as to keep using the same BID for the its privacy. An implementation must carefully assign the BID so
same binding even when the status of the binding is changed. More as to keep using the same BID for the same binding even when the
details can be found in Section 5.1. status of the binding is changed. More details can be found in
Section 5.1.
Binding Unique Identifier sub-option Binding Identifier Mobility Option
The Binding Unique Identifier sub-option is used to carry the BID. The Binding Identifier mobility option is used to carry the BID.
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. The mobile node does not necessarily put
all the available care-of addresses in the binding update, but all the available care-of addresses in the binding update, but
several care-of addresses. A mobile node can also replace all the several care-of addresses. A mobile node can also replace all the
bindings available at the home agent with the new bindings by bindings available at the home agent with the new bindings by
using the bulk registration. The bulk registration is supported using the bulk registration. The bulk registration is supported
only for home registration and deregistration as explained in only for home registration and de-registration as explained in
Section 5.5. A mobile node MUST NOT perform bulk registration Section 5.5. A mobile node MUST NOT perform bulk registration
with correspondent nodes. with correspondent nodes.
3. Protocol Overview 3. Protocol Overview
A new identification number (BID) is introduced to distinguish A new identification number (BID) is introduced to distinguish
multiple bindings pertaining to the same Home Address. Once a mobile multiple bindings pertaining to the same Home Address. Once a mobile
node gets several IPv6 global addresses on interfaces, it can node gets several IPv6 global addresses on one or more of its
register these addresses with its home agent. If the mobile node interfaces, it can register these addresses with its home agent. If
wants to register multiple bindings, it MUST generate a BID for each the mobile node wants to register multiple bindings, it MUST generate
care-of address and record the BID into the binding update list. A a BID for each care-of address and record the BID into the binding
mobile node can manage each binding independently owing to BID. The update list. A mobile node can manipulate each binding independently
mobile node then registers its care-of addresses by sending a Binding by using a BID. The mobile node then registers its care-of addresses
Update with a Binding Unique Identifier sub-option. The BID MUST be by sending a Binding Update with a Binding Identifier mobility
included in the Binding Unique Identifier sub-option. After option. The BID MUST be included in the Binding Identifier mobility
receiving such Binding Update and Binding Unique Identifier sub- option. After receiving such Binding Update and Binding Identifier
option, the home agent MUST copy the BID from the Binding Unique mobility option, the home agent MUST copy the BID from the Binding
Identifier sub-option to the corresponding field in the binding cache Identifier mobility option to the corresponding field in the binding
entry. Even if there is already an entry for the mobile node's home cache entry. Even if there is already an entry for the mobile node's
address, the home agent MUST register a new binding entry for the BID home address, the home agent MUST register a new binding entry for
stored in the Binding Unique Identifier sub-option. The mobile node the BID stored in the Binding Identifier mobility option. The mobile
registers multiple care-of addresses either independently in node registers 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 operate return routability operations. correspondent node, it must perform return routability operations.
The mobile host MUST manage a Care-of Keygen Token per care-of The mobile host MUST manage a Care-of Keygen Token per care-of
address. If it is necessary (ex. Care-of Keygen token is expired), address. The mobile host exchanges CoTI and CoT for the
the mobile host exchanges CoTI and CoT for the relative care-of corresponding care-of addresses if necessary. When the mobile host
addresses. When the mobile host registers several care-of addresses registers several care-of addresses to a correspondent node, it uses
to a correspondent node, it uses the same BID as the one generated the same BID as the one generated for the home registration's
for the home registration's bindings. The binding registration step bindings. The binding registration step is the same as for the home
is the same as for the home registration except for calculating registration except for calculating authenticator. For protocol
authenticator by using Binding Unique Identifier sub-option as well simplicity, the bulk registration is not supported for correspondent
as the other sub-options specified in [RFC-3775]. For simplicity, nodes in this document. Return Routability introduced in [RFC-3775]
the bulk registration is not supported for correspondent nodes in cannot be easily extended to verify multiple care-of addresses stored
this document. 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 just sends a Binding Update without any Binding
Unique Identifier sub-options (i.e. normal Binding Update). The Identifier mobility options. The receiver of the Binding Update
receiver of the Binding Update deletes all the bindings registering deletes all the bindings registering with a BID and registers only a
with a BID and registers only a single binding for the mobile node. single binding for the mobile node. Note that the mobile node can
Note that the mobile node can continue to use BID even if only a continue using BID even if only a single binding is active at some
single binding is active at some time. time.
The BID is used as a search key for a corresponding entry in the When a home agent and a correspondent node check the binding cache
binding cache in addition to the Home Address. When a home agent and database for the mobile node, they search a corresponding binding
a correspondent node check the binding cache database for the mobile entry with the pair of Home Address and BID of the desired binding.
node, they search a corresponding binding entry with the Home Address If necessary, a mobile node can use policy and filter information to
and BID of the desired binding. If necessary, a mobile node can use look up the best binding per sessions, flow, packets, but this is out
policy and filter information to look up the best binding per of scope in this document. If there is no desired binding, it
sessions, flow, packets, but this is out of scope in this document searches the binding cache database with the Home Address as
and is currently discussed in Monami6 WG. If there is no desired specified in Mobile IPv6. The first matched binding entry may be
binding, it searches the binding cache database with the Home Address
as specified in Mobile IPv6. The first matched binding entry may be
found, although this is implementation dependent. found, although this is implementation dependent.
A mobile node carefully operates the returning home. The Home Agent The mobile node may return to the home link through one its
needs to defend a mobile node's home address by the proxy NDP for interfaces. There are three options possible for the mobile node
packet interception, while the mobile node defends its home address when its returns home.
by regular NDP to send and receive packets at the interface attached
to the home link. Two nodes, Home Agent and Mobile Node, compete ND
state. This will causes address duplication problem at the end. If
the proxy neighbor advertisement for the Home Address is stopped,
packets are always routed to the interface attached to the home link.
On the other hand, packets are never routed to the interface attached
to the home link when the proxy is active.
When a mobile node wants to return home with interface attached to 1. The mobile node uses only the interface with which it attaches to
the home link, it MUST de-register all the bindings by sending a the home link. It de-registers all bindings related to all
Binding Update with lifetime set to zero as described in [RFC-3775] care-of addresses. The interfaces which are still attached to
and [RFC-3963]. The mobile node does not put any Binding Unique the visited link are not used.
Identifier sub-option in this Binding Update. The receiver deletes
all the bindings from its binding cache database. On the other hand,
a mobile node does not want to return home and keeps the interfaces
attached to the foreign links active, when one of its interfaces is
attached to its home link. The mobile node disables the interface
attached to the home link and keeps using the rest of interfaces
attached to foreign links. In this case, the mobile node sends a de-
registration Binding Update including the BID for the interface
attached to the home link. The receiver of the de-registration
Binding Update deletes only the relative binding entry from the
binding cache database. The home agent does not stop proxying
neighbor advertisement as long as there are still bindings for the
other interfaces. It is important to understand that this scenario
is not the most efficient because all the traffic from and to the
mobile node is going through the bi-directional tunnel, whereas the
mobile node is now accessible at one hop from its home agent.
In the above two cases, a mobile node cannot use interfaces attached 2. The mobile node uses only the interfaces still attached to the
to both home and foreign links simultaneously. If the proxy NDP is visited link. The interface with which the mobile node attaches
disabled, the main problem can be solved. In the Multiple Care-of to the home link is not used.
Address Registration, the elimination of Proxy NDP enables that
Mobile Node and Home Agent maintain multiple bindings for the 3. The mobile node may simultaneously use both the interface
interfaces attached to the home link and the foreign links. The attached to the home link and the interfaces still attached to
mobile node sends the binding update with H flag set for the the visited links.
interface attached to the home link. The detail operation can be
found in Section 5.5. 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 changes to Mobile IPv6 necessary to
manage multiple bindings bound to a same Home Address. manage multiple bindings bound to a same Home Address.
4.1. Binding Cache Structure and 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 in the binding cache and binding update list
structure. structure.
4.2. Message Format Changes 4.2. Message Format Changes
4.2.1. Binding Unique Identifier sub-option 4.2.1. Binding Identifier Mobility Option
The Binding Unique Identifier sub-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 Acknowledgment, 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 Unique ID (BID) | Status |C|O|H|Reserved | | Binding ID (BID) | Status |C|O|H|D|Resrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
+ care-of address (CoA) + : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Sub-Option Figure 1: BID Mobility Option
Type Type
Type value for Binding Unique Identifier is TBD Type value for Binding Identifier is TBD
Length Length
Length value MUST be 4 when C flag is unset. Otherwise, the 8-bit unsigned integer. Length of the option, in octets,
Length value MUST be set to 20. excluding the Type and Length fields. MUST be set to 4 when the
'C' flag is unset. Otherwise, the Length value MUST be set to
Binding Unique ID (BID) either 8 or 20 depending on the 'D' (DSMIPv6) flag.
Binding ID (BID)
The BID which is assigned to the binding carried in the Binding The BID which is assigned to the binding carried in the Binding
Update with this sub-option. BID is 16-bit unsigned integer. A Update with this mobility option. BID is 16-bit unsigned integer.
value of zero is reserved. A value of zero is reserved.
Status Status
When the Binding Unique Identifier sub-option is included in a When the Binding Identifier mobility option is included in a
Binding Acknowledgment, this field overwrites the status field Binding Acknowledgment, this field overwrites the status field
correspondent to each binding in the Binding Acknowledgment. If correspondent to each binding in the Binding Acknowledgment. If
this field is zero, the receiver MUST use the registration status this field is zero, the receiver MUST use the registration status
stored in the Binding Acknowledgment message. This Status field stored in the Binding Acknowledgment message. This Status field
can be used to carry error information for a Care-of Test message. can be used to carry error information for a Care-of Test message.
The status is 8-bit unsigned integer. The possible status codes The status is 8-bit unsigned integer. The possible status codes
are the same as the status codes of Binding Acknowledgment. are the same as the status codes of Binding Acknowledgment.
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, a mobile node can store a Care-of Address
corresponding to the BID in the Binding Unique Identifier sub- corresponding to the BID in the Binding Identifier mobility
option. This flag must be used whenever a mobile node sends option. This flag MUST be used whenever a mobile node sends
multiple bindings in a single Binding Update, i.e. bulk multiple care-of addresses in a single Binding Update, i.e. bulk
registration or MUST be used as a substitute for an alternate registration. It MUST be also used for the independent binding
care-of address option. This flag is valid only for binding registration as a substitute for an alternate care-of address
update for the home agent. option. This flag is valid only for binding 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 a home agent 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 for the home Update. This flag is valid only for binding update sent to the
agent. home agent.
Home Binding (H) flag Simultaneous Home and Foreign Binding (H) flag
This flag indicates that the mobile node is attached to the home This flag indicates that the mobile node registers multiple
link. This flag is valid only for binding update for the home 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
agent. agent.
DSMIPv6 (D) flag
This flag indicates that the care-of address field MUST be set to
IPv4 care-of address. If this flag is set, the Care-of Address
field MUST be used.
Reserved Reserved
5 bits Reserved field. Reserved field must be set with all 0. 5 bits Reserved field. Reserved field MUST be set with all 0.
Care-of Address Care-of Address
When C flag is set, a Care-of Address matched to the BID is This field has the variable length depending on the specified
stored. This field is valid only if a Binding Unique Identifier flags. When C flag is set and D flag is unset, an IPv6 Care-of
sub-option is stored in Binding Update message. Otherwise, this Address matched to the BID is stored in this field. If both C and
field can be omitted. The receiver SHOULD ignore this field if D flags are set, an IPv4 Care-of Address is stored. This field
the sub-option is presented in other than Binding Update. MUST NOT be used if a Binding Identifier mobility option is
included in any other messages than a Binding Update message. The
receiver SHOULD ignore this field if the mobility option is not
presented in Binding Update message.
4.3. New Status Values for Binding Acknowledgment 4.3. New Status Values for Binding Acknowledgment
New status values for the status field in a Binding Acknowledgment New status values for the status field in a Binding Acknowledgment
are defined for handling the multiple Care-of Addresses registration: are defined for handling the multiple Care-of Addresses registration:
MCOA INCOMPLIANT (TBD) MCOA NOTCOMPLETE (TBD < 128)
Registration failed because Binding Unique Identifier sub-option In bulk registration, not all the binding identifier mobility
is not compliant. option are successfully registered. Some of them are rejected.
The error status value of the failed mobility option is
individually stored in the status field of the binding identifier
mobility option.
MCOA BID CONFLICT (TBD) MCOA RETURNHOME WO/NDP (TBD < 128)
It indicates that a regular binding (i.e. without the BID set) is When a mobile node returns home, it MUST NOT use NDP for the home
already registered for the home address, and is conflicting with a address on the home link. The detail can be found in Section 5.6
received Binding Update which BID is set.
MCOA PROHIBITED(TBD) MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option is
not formed correctly.
MCOA BID CONFLICT (TBD more than 128)
The home agent cannot cache both a regular binding and a BID
extended binding simultaneously. It returns this status value
when the received binding conflicts with the existing binding
cache entry(ies).
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) MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)
The bulk binding registration is not supported. The bulk binding registration is not supported.
MCOA FLAG CONFLICTS (TBD)
The flags of the sub-options presented in a Binding Unique
Identifier sub-options conflicts.
5. Mobile Node Operation 5. Mobile Node Operation
5.1. Management of Care-of Addresses and Binding Unique Identifier 5.1. Management of Care-of Addresses and Binding Identifier
There are two cases when a mobile node has several Care-of Addresses: There are two cases when a mobile node has several Care-of Addresses.
Note that a mixture of the two cases are possible.
1. A mobile node uses several physical network interfaces and 1. A mobile node uses several physical network interfaces and
acquires a care-of address on each of its interfaces. acquires a care-of address on each of its interfaces.
2. A mobile node uses a single physical network interface, but 2. A mobile node uses a single physical network interface, but
multiple prefixes are announced on the link the interface is multiple prefixes are announced on the link the interface is
attached to. Several global addresses are configured on this attached to. Several global addresses are configured on this
interface for each of the announced prefixes. interface for each of the announced prefixes.
The difference between the above two cases is only a number of The difference between the above two cases is only a number of
physical network interfaces and therefore does not matter in this physical network interfaces and therefore does not matter in this
document. The Identification number is used to identify a binding. document. The Identification number is used to identify a binding.
To implement this, a mobile node MAY assign an identification number To implement this, a mobile node MAY assign an identification number
for each care-of addresses. How to assign an identification number for each care-of addresses. How to assign an identification number
is up to implementers. is 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 value register them simultaneously with its Home Address. The BID MUST be
should be generated from a value comprised between 1 to 65535. Zero unique for a binding to a specific care-of address for a given home
and negative values MUST NOT be taken as a BID. If a mobile node has address and care-of address pair. The value should be generated from
only one care-of address, the assignment of a BID is not needed until a value comprised between 1 to 65535. Zero and negative values MUST
it has multiple care-of addresses to register with. NOT be used as a BID. If a mobile node has only one care-of address,
the assignment of a BID is not needed until it has multiple care-of
addresses to register with.
5.2. 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 bindings to a Correspondent
Node, it MUST have the valid care-of Keygen token per care-of Node, it MUST have the valid care-of Keygen token per care-of
address, while the HoTI and HoT can be exchanged only once for a Home address, while the HoTI and HoT can be exchanged only once for a Home
Address. Address.
If the Mobile Node manages bindings with BID, it MUST include a If the Mobile Node manages bindings with BID, it MUST include a
Binding Unique Identifier sub-option in a Care-of Test Init message. Binding Identifier mobility option in a Care-of Test Init message.
It MUST NOT set the any flags in the sub-option. The receiver (i.e. It MUST NOT set the any flags in the mobility option. The receiver
correspondent node) will calculate a care-of Keygen token as (i.e. correspondent node) will calculate a care-of Keygen token as
specified in [RFC-3775] and reply a Care-of Test message and the specified in [RFC-3775] and reply a Care-of Test message and the
Binding Unique Identifier sub-option as described in Section 6.2. Binding Identifier mobility option as described in Section 6.2. When
When the mobile node receives the Care-of Test message, the Care-of the mobile node receives the Care-of Test message, the Care-of Test
Test message is verified as same as in [RFC-3775]. If a Binding message is verified as same as in [RFC-3775]. If a Binding
Unique Identifier sub-option is not presented in CoT in reply to the Identifier mobility option is not presented in CoT in reply to the
CoTI containing the Binding Unique Identifier sub-option, the CoTI containing the Binding Identifier mobility option, the
correspondent node does not support the Multiple Care-of Address correspondent node does not support the Multiple Care-of Address
registration. Thus, the mobile node MUST NOT use a Binding Unique registration. Thus, the mobile node MUST NOT use a Binding
Identifier sub-option in the future Binding Update. The Mobile Node Identifier mobility option in the future Binding Update. The Mobile
MAY skip resending regular CoTI message and keep the received care-of Node MAY skip re-sending regular CoTI message and keep the received
Keygen token for the regular Binding Update, because the care-of Keygen token for the regular Binding Update, because the
correspondent node just ignores and skip the Binding Unique correspondent node just ignores and skip the Binding Identifier
Identifier sub-option and calculates the care-of Keygen token as mobility option and calculates the care-of Keygen token as [RFC-3775]
[RFC-3775] specified. specified.
5.3. Binding Registration 5.3. Binding Registration
When a mobile node sends a Binding Update, it MUST decide whether it When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple care-of addresses or not. However, this decision registers multiple care-of addresses or not. However, how this
is out-of scope in this document. If a mobile node decides not to decision is taken is out-of scope in this document. If a mobile node
register multiple care-of addresses, it completely follows the decides not to register multiple care-of addresses, it completely
RFC3775 specification. 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 Unique Identifier sub-option(s) in the Mobility include a Binding Identifier mobility option(s) in the Mobility
Option field of a Binding Update as shown in Figure 2. The BID is Option field of a Binding Update as shown in Figure 2. The BID is
copied from a corresponding Binding Update List entry to the BID copied from a corresponding Binding Update List entry to the BID
field of the Binding Unique Identifier sub-option. When ESP is used field of the Binding Identifier mobility option. When ESP is used
for binding update, the care-of address MUST be stored in the Care-of for binding update, the care-of address MUST be stored in the Care-of
Address field by setting C flag as a substitute for the alternate Address field by setting C flag as a substitute for the alternate
care-of address option. The alternate care-of address option MUST be care-of address option. The alternate care-of address option MUST be
omitted. Additionally for binding registration to a correspondent omitted. Additionally for binding registration to a correspondent
node, the mobile node MUST have both active home and care-of Keygen node, the mobile node MUST have both active home and care-of Keygen
tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen
tokens MUST be maintained for each care-of address that the mobile tokens MUST be maintained for each care-of address that the mobile
node wants to register to the correspondent node, as described in node wants to register to the correspondent node, as described in
Section 5.2. After computing an Authenticator value for the Binding Section 5.2. After computing an Authenticator value for the Binding
Authorization sub-option, it sends a Binding Update which contains a Authorization mobility option, it sends a Binding Update which
Binding Unique Identifier sub-option. The Binding Update is contains a Binding Identifier mobility option. The Binding Update is
protected by a Binding Authorization Data sub-option placed after the protected by a Binding Authorization Data mobility option placed
Binding Unique Identifier sub-option. 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 Unique Identifier sub-option - Binding Identifier mobility option
- Binding Authorization sub-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. Binding Bulk Registration
The bulk registration is an optimization for registering multiple The bulk registration is an optimization for registering multiple
care-of addresses only to a home agent by using a single Binding care-of addresses only to a home agent by using a single Binding
Update. If a mobile node, for instance, does not want to send a lot Update. If a mobile node, for instance, does not want to send a lot
of control messages through an interface which bandwidth is scarce, of control messages through an interface which bandwidth is scarce,
it can use this bulk registration and send a Binding Update it can use this bulk registration and send a Binding Update
containing multiple or all the valid care-of addresses. containing multiple or all the valid care-of addresses.
A mobile node sets the C flag in a Binding Unique Identifier sub- A mobile node sets the C flag in a Binding Identifier mobility option
option and stores the particular care-of address in the Binding and includes the particular care-of address in the Binding Identifier
Unique Identifier sub-option. The mobile node stores multiple sets mobility option. The mobile node stores multiple sets of a Binding
of a Binding Unique Identifier sub-option in a Binding Update as Identifier mobility option in a Binding Update as shown in Figure 3.
shown in Figure 3. When multiple Binding Unique Identifier sub- In the bulk registration, all the other binding information such as
options are presented in a Binding Update, the flag field of all the Lifetime, Sequence Number, binding Flags are shared among the bulked
sub-options MUST have the same value. For example, if C flag is set, Care-of Addresses. The alternate care-of address option MUST be
the same flag MUST be set to all the sub-options. Otherwise, the omitted when ESP is used to protect a binding update.
mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding
Acknowledgment. In the bulk registration, all the other binding In the bulk registration, the Sequence Number field of a Binding
information such as Lifetime, Sequence Number, binding Flags are Update SHOULD be carefully configured. This is because all the bulk-
shared among the bulked Care-of Addresses. The alternate care-of registered bindings uses the same Sequence Number specified in the
address option MUST be omitted when ESP is used to protect a binding Binding Update. If each binding uses different sequence number, a
update. In the bulk registration, the Sequence Number field of a mobile node MUST use the largest sequence number from the binding
Binding Update SHOULD be carefully configured. If each binding uses update list used for the bulk registration. If it cannot select a
different sequence number, a mobile node MUST use the largest sequence number for all the bindings due to sequence number out of
sequence number from the binding update list used for the bulk window, it MUST NOT use the bulk registration for the binding which
registration. If it cannot select a sequence number for all the sequence number is out of window and uses a separate Binding Update
bindings due to sequence number out of window, it MUST NOT use the for the binding.
bulk registration for the binding which sequence number is out of
window and uses a separate Binding Update for the binding.
IPv6 header (src=CoA, dst=HA) 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 Unique Identifier sub-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 Binding 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 can
set O flag. Section 6.3 describes this registration procedure in set O flag. Section 6.3 describes this registration procedure in
detail. detail.
5.5. Binding De-Registration and Returning Home 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 at a visiting network, it simply sends a regular de-
registration Binding Update which lifetime is set to zero. A Binding registration Binding Update which lifetime is set to zero. A Binding
Unique Identifier sub-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 (e.g. from foreign link), the
mobile node simply sets zero lifetime for the sending binding update. mobile node simply sets zero lifetime for the sending binding update.
The Binding Update MUST contain a relative Binding Unique Identifier The Binding Update MUST contain an appropriate Binding Identifier
Sub-option(s). The receiver will remove only the care-of address(es) mobility option(s). The receiver will remove only the care-of
that matches to the specified BID. For the bulk de-registration, the address(es) that matches to the specified BID. For the bulk de-
care-of addresses field of each sub-option SHOULD be omitted, because registration, the care-of addresses field of each mobility option
the receiver will remove all the care-of addresses which matches the SHOULD be omitted, because the receiver will remove all the care-of
specified BID. addresses matching the specified BID.
When a mobile node returns home, it SHOULD de-register all bindings 5.6. Returning Home
with the home agent by sending a regular de-registration binding
update to flush all the registered bindings. However, there are
several scenarios for returning home described in Appendix A
(Figure 7, Figure 8, Figure 9). We have discussed this feature in
Monami6 working group now. This part might be updated in the next
revision.
As shown in Figure 7 in Appendix A, a mobile node de-registers all The mobile node may return to the home link, by attaching to the home
the binding from the home agent, while it MAY still keep the bindings link through one of the interfaces on the mobile node. When the
of the other interface active attached to foreign links only at the mobile node wants to return home, it should be configured with what
Correspondent Nodes. By doing this, the mobile node still receives interface it needs to use. The mobile node may use only the
packets from the Correspondent Node at the interface attached to a interface with which it is attached to the home link, only the
foreign link thanks to route optimization. If the correspondent interfaces still attached to the visited link or use both interfaces
nodes does not use route optimization, the mobile node receives such attached to the home link and visited link simultaneously. The
packets at the interface attached to the home link. following describes each option in more detail.
In Figure 8, a mobile node does not want to return home even if one 5.6.1. Using only Interface attached to the Home Link
of interfaces is attached to the home link. The mobile node MUST
disable the interface attached to the home link. Otherwise, address
duplication will be observed because the home agent still defend the
Home Address by the proxy neighbor advertisement and the mobile node
also enables the same Home Address on the home link. After disabling
the interface attached to the home link, the mobile node MUST delete
the binding for the disabled interface by sending a de-registration
binding update. The de-registration binding update is sent from one
of active interfaces attached to foreign links. As a result, the
mobile node no longer receives packets at the interface attached to
the home link. All packets are routed to other interfaces attached
to a foreign link.
Alternatively, the Mobile Node may choose to activate both the The mobile node returns home and de-registers all the bindings as
interfaces attached to the home link and the foreign link, and shown in Figure 9. How to de-register all the bindings is the same
communicates with all of the interfaces. The Mobile Node notifies as binding de-registration from foreign link described in
the Home Agent using the H flag which means the Mobile Node is Section 5.5. All the packets routed by the home agent are only
attached to the home link. The Mobile Node may notify the care-of forwarded to the interface attached to the home link, even if there
address of the interface(s) attached to the foreign link(s) in the are other active interfaces attached to the visited link. While the
same message using bulk registration. The Home Agent then no longer mobile node de-registers all the bindings from the home agent, it may
uses Proxy Neighbor Advertisement to intercept packets and the Mobile continue registering bindings for interface attached to visited link
Node can utilize both of interfaces attached to the home link and the to the correspondent node as shown in Figure 9. These bindings at
foreign link simultaneously. The Home Agent can intercept packets by correspondent node MUST be created before a mobile node returns home.
IP routing, but not by proxy Neighbor Discovery. The detailed
operation of no NDP operation can be found in [ID-NONDP].
When the Mobile Node returns home, it de-registers a binding for the 5.6.2. Using only Interface attached to the Visited Link
interface. While the bindings for the interfaces attached to the
foreign link are still active. Intercepting packets, the Home Agent
can decide whether it tunnels to the foreign interface or routes to
the home interface of the Mobile Node. To do so, the Home Agent must
know that the Mobile Node is back to the home link. However, if the
binding is deleted, there is no way for the Home Agent to know that
the Mobile Node is at the home, too. The Home Agent SHOULD
invalidate the binding for the interface attached to the home link
and MAY NOT delete it. It can alternatively mark that the Mobile
Node is at the home link, too. As an example, the Home Agent inserts
the Home Address of the Mobile Node in the Care-of Address field of
the Mobile Node. The binding is named "Home Binding" in this
documentation. The Home Agent MAY manage this home binding as same
as the other binding entry in terms of lifetime validation, etc. The
Mobile Node MAY send multiple binding de- registration to keep this
home binding active. Alternatively, the Home Agent can use infinity
lifetime for the lifetime of the home binding. When the Mobile Node
leaves the Home Link, it can update the home binding to the normal
binding. Before that, the Home Agent believes the Mobile Node is at
the home and may route packets for the Mobile Node to the Home Link.
5.6. Receiving Binding Acknowledgment The mobile node returns home and shutdown the interface attached to
the home link as shown in Figure 10. The binding of the home
attached interface MUST be deleted by sending a de-registration
binding update from one of active interface attached to the foreign
links. This scenario is not the most efficient because all the
traffic from and to the mobile node is going through the bi-
directional tunnel, whereas the mobile node is now accessible at one
hop from its home agent.
5.6.3. Simultaneous Home and Visited Link Operation
The mobile node returns home and continues using all the interfaces
attached to both foreign and home links as shown in Figure 11. The
mobile node indicates this by setting the 'H' flag in the BID
mobility option. There are additional requirements on the Returning
Home procedures for possible ND conflicts at the home link described
below.
In [RFC3775], the home agent intercepts packets meant for the mobile
node using proxy NDP while the mobile node is away from the home
link. When the mobile node returns home, the home agent deletes the
binding cache and stop the proxy NDP for the home address so that a
mobile node can configure its home address on the interface attached
to the home link. In this specification, a mobile node may return
home while it keeps several interfaces attached to the foreign links
and continues using them. Therefore, even though both the mobile
node and the home agent need to intercept packets, the ND states of
the home address can conflict between the home agent and the mobile
node. For instance, if the proxy ND for the Home Address is stopped
by the home agent, packets are always routed to the interface
attached to the home link and are never routed to the interface
attached to the foreign link. It is required to avoid this ND
conflicts in the case of the simultaneous home and foreign
attachment.
In this specification, the home agent MUST intercept all the packets
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
address. The home agent would make this decision based on the type
of packets and flows. How to make this decision is out of scope in
this document. The delicate 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
the home link. In order to create the neighbor cache entry for the
mobile node, following operations are required.
The mobile node sends a de-registration binding update to the home
agent from the interface attached to the home link. In the Binding
Update, the BID mobility option must be stored for the BID assigned
to the interface. The H flag MUST be set in the BID mobility option.
When the H flag is appears, the home agent learns and remembers that
the mobile node wants to continue using interfaces attached to both
foreign and home links. If H flag is unset, the home agent deletes
either all the bindings or the binding corresponding to the BID.
When the home agent sends the Binding Acknowledgment, it MUST store
one of two status values such as [Binding Update Accepted (0)] [MCOA
RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home
agent configuration at the home link. The new values are:
o Binding Update Accepted (0): NDP is permitted for the home address
at the home link. This is regular returning home operation of
[RFC3775]
o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link
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
proxy ND for the requested home address and replies the [Binding
Update Accepted] value to the mobile node. The neighbor cache entry
for the mobile node is created by the regular NDP operation (i.e.
NS/NA exchange). On the other hand, if the home agent is not the
only router, it MUST continue defending the home address by proxy NDP
to capture all the mobile node's traffic. The home agent, then,
returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID
mobility option. The home agent also learns the mobile node's
layer-2 address (i.e. MAC address) during this binding de-
registration. It keeps the learned layer-2 address as the neighbor
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
directly to the mobile node's interface attached to the home link.
According to [RFC3775], the mobile node MUST NOT assign the home
address to the interface attached to the home link and MUST NOT
attempt NDP operations for the home address before the completion of
binding de-registration. It MUST NOT send and reply to Neighbor
Solicitation for the home address. The home address MUST be
tentative address at this moment until it receives Binding
Acknowledgment with success status value.
When the mobile node receives the binding acknowledgment and BID
mobility option, it assigns home address at the interface attached to
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
home address using NDP. The home agent can create neighbor cache
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
defends its home address at the home link by NDP. When the mobile
node sends packets from the interface attached to the home link, it
MUST learn the layer2 address (i.e. MAC address) of the next hop
(i.e. default router, it can be home agent) during the binding de-
registration and construct the packet including layer 2 header with
the learned home agent's layer-2 address.
5.7. Receiving Binding Acknowledgment
The verification of a Binding Acknowledgment is the same as Mobile The verification of a Binding Acknowledgment 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 Acknowledgment is described in Section 6.3.
If a mobile node includes a Binding Unique Identifier sub-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 A flag set, a Binding Acknowledgment MUST carry a
Binding Unique Identifier sub-option in the Mobility Options field. Binding Identifier mobility option in the Mobility Options field. If
If no such sub-option is appeared in the Binding Acknowledgment no such mobility option is included in the Binding Acknowledgment
replied to the Binding Update for the multiple care-of address replied to the Binding Update for the multiple care-of address
registration, this indicates that the originator node of this Binding registration, this indicates that the originator node of this Binding
Acknowledgment might not recognize the Binding Unique Identifier sub- Acknowledgment might not recognize the Binding Identifier mobility
option. The mobile node SHOULD stop registering multiple care-of option. The mobile node SHOULD stop registering multiple care-of
addresses by using a Binding Unique Identifier sub-option. addresses by using a Binding Identifier mobility option.
If a Binding Unique Identifier sub-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 Acknowledgment, the mobile node checks the registration
status for the Care-of address(es). The status value MUST be status for the Care-of address(es). The status value MUST be
retrieved as follows. If the status value in the Binding Unique retrieved as follows. If the status value in the Binding Identifier
Identifier sub-option is zero, the mobile node uses the value in the mobility option is zero, the mobile node uses the value in the Status
Status field of the Binding Acknowledgment. Otherwise, it uses the field of the Binding Acknowledgment. Otherwise, it uses the value in
value in the Status field of the Binding Unique Identifier sub- the Status field of the Binding Identifier mobility option.
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 originator (home agent or correspondent node) successfully
registered the binding information and BID for the mobile node. 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 give up registering multiple bindings to the peer sending the
Binding Acknowledgment. It MUST return to the regular Mobile IPv6 Binding Acknowledgment. It MUST return to the regular Mobile IPv6
[RFC-3775] for the peer node. [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 registration to the peer
sending the Binding Acknowledgment. sending the Binding Acknowledgment.
o If [MCOA FLAG CONFLICTS] is specified, it indicates that the o If [MCOA MALFORMED] is specified, it indicates that the binding
different flag values are used in Binding Unique Identifier sub- identifier mobility option is formatted wrongly. For example, if
options in a Binding Update. If the C flag is set, all sub- the C flag is set, all mobility options MUST have C flag. It is
options MUST have C flag. It is same for O flag. How to handle same for O flag. How to handle other error status codes is
other error status codes is specified in [RFC-3775]. 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 Unique Identifier sub-option is already registered by the Binding Identifier mobility option is already registered as
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 O flag for the
peer to reset all the registered bindings. peer to reset all the registered bindings.
5.7. 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
Unique Identifier sub-option, this Binding Refresh Request requests a Identifier mobility option, this Binding Refresh Request requests a
new binding indicated by the BID. The mobile node SHOULD update only new binding indicated by the BID. The mobile node SHOULD update only
the respective binding. The mobile node MUST put a Binding Unique the respective binding. The mobile node MUST put a Binding
Identifier sub-option into the Binding Update sent to refresh the Identifier mobility option into the Binding Update sent to refresh
entry. the entry.
If no Binding Unique Identifier sub-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.8. Sending Packets to Home Agent 5.9. Sending Packets to Home Agent
When a multihomed mobile node sends packets to its home agent, there When a multihomed mobile node sends packets to its home agent, there
are conceptually two ways to construct packets. are conceptually two ways to construct packets.
1. Using Home Address Option. (required additional 24 bytes) 1. Using Home Address Option. (required additional 24 bytes)
2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes)
Beside the additional size of packets, no difference is observed Beside the additional size of packets, no difference is observed
between these two. The routing path is always the same and no between these two. The routing path is always the same and no
skipping to change at page 19, line 36 skipping to change at page 21, line 7
document, the mobile node is capable of using multiple care-of document, the mobile node is capable of using multiple care-of
addresses for outgoing packets. This is problem in home agent side addresses for outgoing packets. This is problem in home agent side
because they must verify the Care-of address for all the packets because they must verify the Care-of address for all the packets
received from the mobile node (i.e. ingress filtering). When it uses 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 the Home Address option, the home agent MAY check the care-of address
in the packet with the registering binding entries. This causes in the packet with the registering binding entries. This causes
additional overhead to the home agent. Therefore, the mobile node additional overhead to the home agent. Therefore, the mobile node
SHOULD use the bi-directional tunnel even if it registers a SHOULD use the bi-directional tunnel even if it registers a
binding(s) to the home agent. binding(s) to the home agent.
5.9. Bootstrapping 5.10. Bootstrapping
When a mobile node bootstraps and registers multiple bindings at the When a mobile node bootstraps and registers multiple bindings at the
first time, it SHOULD set O flag in the Binding Unique Identifier first time, it SHOULD set O flag in the Binding Identifier mobility
sub-option. If old bindings still exists at the Home Agent, the option. If old bindings still exists at the Home Agent, the mobile
mobile node has no way to know which bindings are remained as a node has no way to know which bindings are still remained at the home
garbage. This scenario happens when a mobile node reboots without agent. This scenario happens when a mobile node reboots without
correct deregistration. If O flag is used, all the bindings are correct de-registration. If O flag is used, all the bindings are
replaced to the new binding(s). Thus, the garbage bindings are replaced to the new binding(s). Thus, the garbage bindings are
surely replaced by new bindings registered with the first Binding surely replaced by new bindings registered with the first Binding
Update. If the mobile node receives the Binding Acknowledgment with Update. If the mobile node receives the Binding Acknowledgment with
the status code set to 135 [Sequence number out of window], it MUST the status code set to 135 [Sequence number out of window], it MUST
retry sending a Binding Update with the last accepted sequence number retry sending a Binding Update with the last accepted sequence number
which is notified by the Binding Acknowledgment. which is notified by the Binding Acknowledgment.
For Correspondent nodes, the mobile node cannot use the O flag For Correspondent nodes, the mobile node cannot use the O flag
because of no bulk registration support. Thus, if necessary, it MUST because of no bulk registration support. Thus, if necessary, it MUST
sends a regular binding first to overwrite the remaining bindings at sends a regular binding first to overwrite the remaining bindings at
the correspondent node. Then, it can re-register the set of bindings the correspondent node. Then, it can re-register the set of bindings
by using Multiple Care-of Address Registration. 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 Unique 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. How to select the
most suitable binding from the binding cache database is out of scope most suitable binding from the binding cache database is out of scope
in this document. in this document.
Whenever a correspondent node searches a binding cache for a home Whenever a correspondent node searches a binding cache for a home
address, it SHOULD uses both the Home Address and the BID as the address, it SHOULD uses both the Home Address and the BID as the
search key if it knows the corresponding BID. In the example below, search key if it knows the corresponding BID. In the example below,
if a correspondent node searches the binding with the Home Address if a correspondent node searches the binding with the Home Address
and BID2, it gets binding2 for this mobile node. and 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 basically learns the BID when it receives a
Binding Unique Identifier sub-option. At the time, the correspondent Binding Identifier mobility option. At the time, the correspondent
node MUST look up its binding cache database with the Home Address node MUST look up its binding cache database with the Home Address
and the BID retrieved from the Binding Update. If the correspondent and the BID retrieved from the Binding Update. If the correspondent
node does not know the BID, it searches for a binding with only a node does not know the BID, it searches for a binding with only a
Home Address as performed in Mobile IPv6. In such case, the first Home Address as performed in Mobile IPv6. In such case, the first
matched binding is found. But which binding entry is returned for matched binding is found. But which binding entry is returned for
the normal search depends on implementations. If the correspondent the normal search depends on implementations. If the correspondent
node does not desire to use multiple bindings for a mobile node, it node does not desire to use multiple bindings for a mobile node, it
can simply ignore the BID. 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 Unique Identifier sub-option, it MUST process it with Binding Identifier mobility option, it MUST process it with following
following steps. steps.
First of all, the CoTI message is verified according to [RFC-3775]. First of all, the CoTI message is verified according to [RFC-3775].
The Binding Unique Identifier sub-option MUST be, then, processed as The Binding Identifier mobility option MUST be, then, processed as
follows: follows:
o If a correspondent node does not understand a Binding Unique o If a correspondent node does not understand a Binding Identifier
Identifier sub-option, it just ignores and skip this option. The mobility option, it just ignores and skip this option. The
calculation of a care-of Keygen token will thus be done without a calculation of a care-of Keygen token will thus be done without a
BID value. The correspondent node returns a CoT message without a BID value. The correspondent node returns a CoT message without a
Binding Unique Identifier sub-option. The mobile node can thus Binding Identifier mobility option. The mobile node can thus know
know whether the correspondent can process the Binding Unique whether the correspondent can process the Binding Identifier
Identifier sub-option or not, by checking if such option is mobility option or not, by checking if such option is present in
present in the CoT message. the CoT message.
o If either or both C and O flag is set in the sub-option, the o If either or both C and O flag is set in the mobility option, the
Correspondent Node SHOULD NOT calculate a care-of Keygen token and Correspondent Node SHOULD NOT calculate a care-of Keygen token and
MUST include a Binding Unique Identifier sub-option which status MUST include a Binding Identifier mobility option which status
value set to [MCOA INCOMPLIANT] in the returned Care-of Test value set to [MCOA MALFORMED] in the returned Care-of Test
message. message.
o Otherwise, the correspondent node MUST include a Binding Unique o Otherwise, the correspondent node MUST include a Binding
Identifier sub-option which status value MUST be set to zero in Identifier mobility option which status value MUST be set to zero
the returning a CoT message. in the returning a CoT message.
o All the Binding Unique Identifier sub-options SHOULD be copied o All the Binding Identifier mobility options SHOULD be copied from
from the received one except for the Status Field for CoT. The the received one except for the Status Field for CoT. The Care-of
Care-of address field of each Binding Unique Identifier sub- address field of each Binding Identifier mobility option, however,
option, however, can be omitted, because the mobile node can match can be omitted, because the mobile node can match a corresponding
a corresponding binding update list by using BID. 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 Unique Identifier sub- 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]. But 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 a binding for the mobile node. If the
Binding Update is for de-registration, the receiver MUST delete all Binding Update is for de-registration, the receiver MUST delete all
existing bindings from its Binding Cache. existing bindings from its Binding Cache.
If a Binding Update contains a Binding Unique Identifier sub- If a Binding Update contains a Binding Identifier mobility option(s),
option(s), it is validated according to section 9.5.1 of [RFC-3775] it is validated according to section 9.5.1 of [RFC-3775] and the
and the following step. following step.
o If the home registration flag is set in the Binding Update, the o If the home registration flag is set in the Binding Update, the
home agent MUST carefully operate DAD for the received Home home agent MUST carefully operate Duplicate Address Detection
Address. If the home agent has already had a binding(s) for the (DAD) for the received Home Address. If the home agent has
Mobile Node, it MUST avoid running DAD check when it receives the already had a binding(s) for the Mobile Node, it MUST avoid
Binding Update. running DAD check when it receives the Binding Update.
The receiver node MUST process the Binding Unique Identifier sub- The receiver node MUST process the Binding Identifier mobility
option(s) in the following steps. When a correspondent node sends a option(s) in the following steps. When a correspondent node sends a
Binding Acknowledgment, the status value is always stored in the Binding Acknowledgment, the status value MUST be always stored in the
Status field of the Binding Acknowledgment and keep the Status field Status field of the Binding Acknowledgment and keep the Status field
of Binding Unique Identifier sub-option to zero. For the Home Agent, of Binding Identifier mobility option to zero.
the status value can be stored in the Status field of either a
Binding Acknowledgment or a Binding Unique Identifier sub-option. If
the status value is specific to one of bindings in the bulk
registration, the status value MUST be stored in the Status field in
the corresponding Binding Unique Identifier sub-option.
o The length value is examined. The length value MUST be either 4 For the Home Agent, the status value can be stored in the Status
or 20 depending on C flag. If the length is incorrect, the field of either a Binding Acknowledgment or a Binding Identifier
receiver MUST rejects the Binding Update and returns the status mobility option. If the status value is specific to one of bindings
value set to [MCOA INCOMPLIANT]. 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 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,
8, or 20 depending on C and D flag. If the length is incorrect,
the receiver MUST rejects the Binding Update and returns the
status value set to [MCOA MALFORMED].
o When C flag is specified, the care-of address MUST be given in the o When C flag is specified, the care-of address MUST be given in the
Binding Unique Identifier sub-option. Otherwise, the receiver Binding Identifier mobility option. Otherwise, the receiver MUST
MUST reject the Binding Unique Identifier sub-option and returns reject the Binding Identifier mobility option and returns the
the status value set to [MCOA INCOMPLIANT]. status value set to [MCOA MALFORMED]. The operation of D flag is
described in Section 8
o When multiple binding Unique Identifier sub-options are presented, o When multiple binding Identifier mobility options are presented,
the receiver MUST support the bulk registration. Only a home the receiver MUST support the bulk registration. Only a home
agent can accept the bulk registration. Otherwise, it MUST reject agent can accept the bulk registration. Otherwise, it MUST reject
the Binding Update and returns the status value set to [MCOA BULK the Binding Update and returns the status value set to [MCOA BULK
REGISTRATION NOT SUPPORT] in the Binding Acknowledgment. REGISTRATION NOT SUPPORT] in the Binding Acknowledgment.
o When multiple binding Unique Identifier sub-options are presented,
the flags field of all the Binding Unique Identifier sub-option
stored in the same Binding Update MUST be equal. Otherwise, the
receiver MUST reject the Binding Update and returns the status
value set to [MCOA FLAG CONFLICTS] in the Binding Acknowledgment.
o If the Lifetime field of the Binding Update is zero, the receiver o If the Lifetime field of the Binding Update is zero, the receiver
node deletes the binding entry which BID is same as BID sent by node deletes the binding entry which BID is same as BID sent by
the Binding Unique Identifier sub-option. If the receiver node the Binding Identifier mobility option. If the receiver node does
does not have appropriate binding which BID is matched with the not have appropriate binding which BID is matched with the Binding
Binding Update, it MUST reject this de-registration Binding Update Update, it MUST reject this de-registration Binding Update for the
for the binding cache. If the receiver is a Home Agent, it SHOULD binding cache. If the receiver is a Home Agent, it SHOULD also
also return the status value set to [not Home Agent for this return the status value set to [not Home Agent for this mobile
mobile node, 133]. node, 133].
o If O flag is set in the deregistering Binding Update, the receiver o If O flag is set in the de-registering Binding Update, the
can ignore this flag for deregistration. If the H flag is set, receiver can ignore this flag for de-registration. If the H flag
the home agent stores a Home Address in the Care-of Address field is set, the home agent stores a Home Address in the Care-of
of the binding cache entry. The home agent no longer performs Address field of the binding cache entry. The home agent no
proxy NDP for this mobile node until this entry is deleted. longer performs proxy NDP for this mobile node until this entry is
deleted.
o If the Lifetime field is not zero, the receiver node registers a o If the Lifetime field is not zero, the receiver node registers a
binding with the specified BID as a mobile node's binding. The binding with the specified BID as a mobile node's binding. The
Care-of address is picked from the Binding Update packet as Care-of address is picked from the Binding Update packet as
follows: follows:
* If C flag is set in the Binding Unique Identifier sub-option, * If C flag is set in the Binding Identifier mobility option, the
the care-of address must be taken from the care-of address care-of address must be taken from the care-of address field in
field in each Binding Unique Identifier sub-option. each Binding Identifier mobility option.
* If C flag is not set in the Binding Unique Identifier sub- * If C flag is not set in the Binding Identifier mobility option,
option, the care-of address must be taken from the Source the care-of address must be taken from the Source Address field
Address field of the IPv6 header. of the IPv6 header.
* If C flag is not set and an alternate care-of address is * If C flag is not set and an alternate care-of address is
present, the care-of address is taken from the Alternate present, the care-of address is taken from the Alternate
Care-of address sub-option. Care-of address mobility option.
o Once the care-of address(es) has been retrieved from the Binding o Once the care-of address(es) has been retrieved from the Binding
Update, it starts registering binding(s). Update, it starts registering binding(s).
* Only if O flag is set in the sub-option, the home agent first * Only if O flag is set in the mobility option, the home agent
removes all the existing bindings and registers the received first removes all the existing bindings and registers the
bindings. received bindings.
* If the receiver has a regular binding which does not have BID * If the receiver has a regular binding which does not have BID
for the mobile node, it de-registers the regular binding and for the mobile node, it de-registers the regular binding and
registers a new binding including BID according to the Binding registers a new binding including BID according to the Binding
Update. In this case, the receiver MUST return [MCOA BID Update. In this case, the receiver MUST return [MCOA BID
CONFLICT]. CONFLICT].
* If the receiver node has already registered the binding which * If the receiver node has already registered the binding which
BID is matched with requesting BID, then it MUST update the BID is matched with requesting BID, then it MUST update the
binding with the Binding Update and returns [0 Binding Update binding with the Binding Update and returns [0 Binding Update
accepted]. accepted].
* If the receiver does not have a binding entry which BID is * If the receiver does not have a binding entry which BID is
matched with the requesting BID, it registers a new binding for matched with the requesting BID, it registers a new binding for
the BID and returns [0 Binding Update accepted]. the BID and returns [0 Binding Update accepted].
If all the above operations are successfully finished, the Binding If all the above operations are successfully finished, the Binding
Acknowledgment containing the Binding Unique Identifier sub-options Acknowledgment containing the Binding Identifier mobility options
MUST be replied to the mobile node if A flag is set in the Binding MUST be replied to the mobile node if A flag is set in the Binding
Acknowledgment. Whenever a Binding Acknowledgment is returned, all Acknowledgment. Whenever a Binding Acknowledgment is returned, all
the Binding Unique Identifier sub-options stored in the Binding the Binding Identifier mobility options stored in the Binding Update
Update MUST be copied to the Binding Acknowledgment. The Care-of MUST be copied to the Binding Acknowledgment. The Care-of address
address field of each Binding Unique Identifier sub-option, however, field of each Binding Identifier mobility option, however, can be
can be omitted, because the mobile node can match a corresponding omitted, because the mobile node can match a corresponding binding
binding update list by using BID. update list by using BID.
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 sends a Binding Refresh Request for a particular binding
registering with BID, the node SHOULD contain a Binding Unique registering with BID, the node SHOULD contain a Binding Identifier
Identifier sub-option in the Binding Refresh Request. mobility option in the Binding Refresh Request.
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 appeared
in the Source Address field MUST be equal to one of the care-of in the Source Address field MUST be equal to one of the care-of
addresses in the binding cache entry. If no binding is found, the addresses in the binding cache entry. If no binding is found, the
packets MUST be silently discarded and MUST send a Binding Error packets MUST be silently discarded and MUST send a Binding Error
message according to RFC3775. This verification MUST NOT be done for message according to RFC3775. This verification MUST NOT be done for
a Binding Update. a Binding Update.
skipping to change at page 26, line 17 skipping to change at page 27, line 17
Support of multihomed mobile routers is advocated in the NEMO working Support of multihomed mobile routers is advocated in the NEMO working
group (see R12 "The solution MUST function for multihomed MR and group (see R12 "The solution MUST function for multihomed MR and
multihomed mobile networks" in [RFC-4886]. Issues regarding mobile multihomed mobile networks" in [RFC-4886]. Issues regarding mobile
routers with multiple interfaces and other multihoming configurations routers with multiple interfaces and other multihoming configurations
are documented in [RFC-4980]. are documented in [RFC-4980].
Since the binding management mechanisms are the same for a mobile Since the binding management mechanisms are the same for a mobile
host operating Mobile IPv6 and for a mobile router operating NEMO host operating Mobile IPv6 and for a mobile router operating NEMO
Basic Support (RFC 3963), our extensions can also be used to deal Basic Support (RFC 3963), our extensions can also be used to deal
with multiple care-of addresses registration sent from a multihomed with multiple care-of addresses registration sent from a multihomed
mobile router. Figure 5 shows the example format of a Binding Update mobile router. Figure 5 shows an example format of a Binding Update
used by a mobile router. used by a mobile router.
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 Unique Identifier sub-option - Binding Identifier
- Mobile Network Prefix sub-option - Mobile Network Prefix
Figure 5: NEMO Binding Update Figure 5: NEMO Binding Update
8. IPsec and IKEv2 interaction 8. DSMIPv6 Applicability
Dual Stack Mobile IPv6 (DSMIPv6) extends Mobile IPv6 to register an
IPv4 care-of address instead of the IPv6 care-of address when the
mobile node is attached to an IPv4-only access network. It also
allows the mobile node to acquire an IPv4 home address in addition to
an IPv6 home address for use with IPv4-only correspondent nodes.
This section describes how multiple care-of address registration
works with IPv4 care-of and home addresses.
8.1. IPv4 Care-of Address Registration
In DSMIPv6, the binding update and acknowledgment exchange is used to
detect NAT. Thus, when a mobile node registers its IPv4 care-of
address bound to IPv6 home address, it MUST first attempt to send a
Binding Update with Binding Identifier mobility option independently.
The bulk registration MUST NOT be used for the first binding update
of the IPv4 care-of address. The Binding Update MUST be sent to the
IPv4 home agent address by using UDP and IPv4 headers as shown in
Figure 6. It is similar to [DSMIP] except for using BID mobility
option instead of IPv4 care-of address option.
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier (IPv4 CoA)
Figure 6: 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
address by using BULK registration. The mobile node can register the
IPv4 care-of address with other care-of addresses. Figure 7 shows
the binding update format when the mobile node sends a Binding Update
from one of its IPv6 care-of addresses. If the mobile node sends a
BU from IPv4 care-of address, it MUST follows the Figure 6 and store
more BID mobility options in the mobility options field. Note that
IPv4 Care-of Address must be registered by non bulk Binding
registration, whenever it is changed. NAT detection MUST be carried
out for every new IPv4 addresses.
IPv6 header (src=V6CoA, dst=HAADDR)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...
Figure 7: 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
error code value in the Status field of the BID mobility option. The
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
When the mobile node obtains an IPv4 home address, it MUST store the
IPv4 Home Address option in the Binding Update. If the home agent
accepts the binding update, the mobile node can also register
multiple care-of addresses for the IPv4 home address in addition to
the IPv6 home address. The same set of care-of addresses will be
registered for both IPv6 and IPv4 home addresses. The mobile node
cannot binding different set of care-of addresses to each home
address.
The home agent MUST returns a binding acknowledgment and IPv4 address
acknowledgment option to the mobile node only when a mobile node
requests IPv4 home address mobility management. In this case, this
option MUST be presented before any BID options. The status field of
the IPv4 address acknowledgment option contains only the error code
regarding IPv4 home address management. The error value of the IPv4
care-of address registration MUST be stored in the BID mobility
option.
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 Acknowledgments and return routability messages. IPsec may
also be used protect all reverse tunneled data traffic. The Mobile also be used protect all reverse tunneled data traffic. The Mobile
IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used
to setup the required IPsec security associations. The following to 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 the MIP6-IKEv2
specification with respect to the use of IKEv2 and IPsec. specification with respect to the use of IKEv2 and IPsec.
skipping to change at page 27, line 38 skipping to change at page 30, line 38
o The mobile node runs IKEv2 (or IKEv1) with the home agent using o The mobile node runs IKEv2 (or IKEv1) with the home agent using
the care-of address. The IKE SA is based on the care-of address the care-of address. The IKE SA is based on the care-of address
of the mobile node. of the mobile node.
The above assumptions may not be valid when multiple care-of The above assumptions may not be valid when multiple care-of
addresses are used by the mobile node. In the following sections, addresses are used by the mobile node. In the following sections,
the main issues with the use of multiple care-of address with IPsec the main issues with the use of multiple care-of address with IPsec
are addressed. are addressed.
8.1. Use of Care-of Address in the IKEv2 exchange 9.1. Use of Care-of Address in the IKEv2 exchange
For each home address the mobile node sets up security associations For each home address the mobile node sets up security associations
with the home agent, the mobile node must pick one care-of address with the home agent, the mobile node must pick one care-of address
and use that as the source address for all IKEv2 messages exchanged and use that as the source address for all IKEv2 messages exchanged
to create and maintain the IPsec security associations associated to create and maintain the IPsec security associations associated
with the home address. The resultant IKEv2 security association is with the home address. The resultant IKEv2 security association is
created based on this care-of address. created based on this care-of address.
If the mobile node needs to change the care-of address, it just sends If the mobile node needs to change the care-of address, it just sends
a Binding Update with the care-of address it wants to use, with the a Binding Update with the care-of address it wants to use, with the
corresponding Binding Unique Identifier sub-option, and with the 'K' corresponding Binding Identifier mobility option, and with the 'K'
bit set. This will force the home agent to update the IKEv2 security bit set. This will force the home agent to update the IKEv2 security
association to use the new care-of address. If the 'K' bit is not association to use the new care-of address. If the 'K' bit is not
supported on the mobile node or the home agent, the mobile node MUST supported on the mobile node or the home agent, the mobile node MUST
re-establish the IKEv2 security association with the new care-of re-establish the IKEv2 security association with the new care-of
address. This will also result in new IPsec security associations address. This will also result in new IPsec security associations
being setup for the home address. being setup for the home address.
8.2. Transport Mode IPsec protected messages 9.2. Transport Mode IPsec protected messages
For Mobile IPv6 signaling message protected using IPsec in transport For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing. addresses does not matter for IPsec processing.
For Mobile Prefix Discovery messages, [RFC-3775] requires the home 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 is one of the care-of
addresses in the binding cache entry for the mobile node. addresses in the binding cache entry for the mobile node.
8.3. Tunnel Mode IPsec protected messages 9.3. Tunnel Mode IPsec protected messages
The use of IPsec in tunnel mode with multiple care-of address The use of IPsec in tunnel mode with multiple care-of 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
sections address multiple care-of address support for these two types sections address multiple care-of address support for these two types
of messages. of messages.
8.3.1. Tunneled HoTi and HoT messages 9.3.1. Tunneled HoTi and HoT messages
The mobile node MAY use the same care-of address for all HoTi The mobile node MAY use the same care-of address for all HoTi
messages sent reverse tunneled through the home agent. The mobile messages sent reverse tunneled through the home agent. The mobile
node may use the same care-of address irrespective of which node may use the same care-of address irrespective of which
correspondent node the HoTi message is being sent. RFC 3775 requires correspondent node the HoTi message is being sent. RFC 3775 requires
the home agent to verify that the mobile node is using the care-of the home agent to verify that the mobile node is using the care-of
address that is in the binding cache entry, when it receives a address that is in the binding cache entry, when it receives a
reverse tunneled HoTi message. If a different address is used as the reverse tunneled HoTi message. If a different address is used as the
source address, the message is silently dropped by the home agent. source address, the message is silently dropped by the home agent.
This document requires the home agent implementation to decapsulate This document requires the home agent implementation to decapsulate
and forward the HoTi message as long as the source address is one of and forward the HoTi message as long as the source address is one of
the care-of addresses in the binding cache entry for the mobile node. the care-of addresses in the binding cache entry for the mobile node.
When the home agent tunnels a HoT message to the mobile node, the When the home agent tunnels a HoT message to the mobile node, the
care-of address used in the outer IPv6 header is not relevant to the care-of address used in the outer IPv6 header is not relevant to the
HoT message. So regular IPsec tunnel encapsulation with the care-of HoT message. So regular IPsec tunnel encapsulation with the care-of
address known to the IPsec implementation on the home agent is address known to the IPsec implementation on the home agent is
sufficient. sufficient.
8.3.2. Tunneled Payload Traffic 9.3.2. Tunneled Payload Traffic
When the mobile sends and receives multiple traffic flows protected When the mobile sends and receives multiple traffic flows protected
by IPsec to different care-of addresses, the use of the correct by IPsec to different care-of addresses, the use of the correct
care-of address for each flow becomes important. Support for this care-of address for each flow becomes important. Support for this
requires the following two considerations on the home agent. requires the following two considerations on the home agent.
o When the home agent receives a reverse tunneled payload message o When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, it must check that the care-of protected by IPsec in tunnel mode, it must check that the care-of
address is one of the care-of addresses in the binding cache address is one of the care-of addresses in the binding cache
entry. According to RFC 4306, the IPsec implementation on the entry. According to RFC 4306, the IPsec implementation on the
skipping to change at page 30, line 5 skipping to change at page 33, line 5
the correspondent node. the correspondent node.
o For tunneled IPsec traffic from the home agent to the mobile node, o For tunneled IPsec traffic from the home agent to the mobile node,
The IPsec implementation on the home agent may not be aware of The IPsec implementation on the home agent 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.
9. Security Considerations 10. Security Considerations
As shown in Section 8, the Multiple Care-of Addresses Registration As shown in Section 9, the Multiple Care-of Addresses Registration
requires IPsec protected all the signaling between a mobile node and requires IPsec protection for all the signaling between a mobile node
its home agent. and its home agent.
10. IANA Considerations With simultaneous binding support, it is possible for a malicious
mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home agent.
Once these addresses have been bound, the malicious mobile node can
perform a re-direction attack by instructing the home agent (e.g.
setting filtering rules to direct a large file transfer) to tunnel
packets to the victims' addresses. Such risk is highlighted in [ID-
MIP6ANALYSIS] and is possible because the care-of addresses specified
by the mobile node in the binding update messages are not verified by
home agent (since Mobile IPv6 assumes an existing trust relationship
between the mobile node and its home agent).
Although such risk exists in Mobile IPv6, the risk level is escalated
when simultaneous multiple care-of address bindings are performed.
One fundamental difference is the degree of risk involved is much
greater in the simultaneous binding support case. For a single
care-of address binding, a mobile node can only have a single care-of
address binding per home address at a given time. However, for
simultaneous multiple care-of address bindings, a mobile node can
have more than one care-of address binding per home address at a
given time. This implies that a mobile node using simultaneous
binding support can effectively bind more than a single victim's
address. Another fundamental difference is the form of risk
involved. In the single care-of address binding case, once the re-
direction attack is initiated, a malicious mobile node would be
unable to use its home address for communications (such as to receive
control packets pertaining to the file transfer). However, in the
simultaneous binding support case, a malicious mobile node could bind
a valid care-of address in addition to multiple victims addresses.
This valid care-of address could then be used by the malicious mobile
node to set up flow filtering rules at its home agent, thereby
controlling and/or launching new re-direction attacks.
Thus, in view of such risk, it is advisable for a home agent to
employ some form of care-of address verification mechanism before
using the care-of addresses as a valid routing path to a mobile node.
Some solutions to advert such problems are described in Appendix.
11. IANA Considerations
The following Extension Types MUST be assigned by IANA: The following Extension Types MUST be assigned by IANA:
o Binding Unique Identifier sub-option type o Binding Identifier mobility option type:This must be assigned from
the same space as mobility option in [RFC3775].
o New Status of Binding Acknowledgment o New Successful Status of Binding Acknowledgment:This status code
must be assigned from the same space as binding acknowledgement
status codes in [RFC3775].
* MCOA INCOMPLIANT (TBD) * MCOA NOTCOMPLETE (TBD)
o New Unsuccessful Status of Binding Acknowledgment: These status
codes must also be assigned from the same space as binding
acknowledgement status codes in [RFC3775].
* 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)
* MCOA FLAG CONFLICTS (TBD) 12. Acknowledgments
11. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation), The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson), George Tsirtsis (Qualcomm), Keigo Aso (Panasonic), Julien Charbon,
Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen Tero Kauppinen (Ericsson), Benjamin Lim (Panasonic), Susumu Koshiba,
(Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki Martti Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen
Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U),
Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U),
in alphabetical order, the Jun Murai Lab. at KEIO University. Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab.
at KEIO University.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998. (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 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-02 (work in progress), February draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
2007. 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] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC-4886] Ernst, T., "Network Mobility Support Goals and [RFC-4886] Ernst, T., "Network Mobility Support Goals and
Requirements", RFC 4886, July 2007. 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.
12.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
[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.
[ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of [RFC-3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Proxy NDP from Home Agent Operations", RFC 3972, March 2005.
draft-wakikawa-mip6-no-ndp-02.txt (work in progress), November 2007.
[RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
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.
skipping to change at page 34, line 38 skipping to change at page 37, 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 6: Multiple Interfaces Attached to a Foreign Link Figure 8: Multiple Interfaces Attached to a Foreign Link
Figure 6 depicts the scenario where all interfaces of the mobile node Figure 8 depicts the scenario where all interfaces of the mobile node
are attached to foreign links. After binding registrations, the home are attached to foreign links. After binding registrations, the home
agent (HA) and the Correspondent Node (CN) have the binding entries agent (HA) and the Correspondent Node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize listed in their binding cache database. The mobile node can utilize
all the interfaces. all the interfaces.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +--------+-+ +--+-+ | +--------+-+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
| MN +========+ | | | MN +========+ | |
+--+--+ | | | +--+--+ | | |
CoA3| +---|-----------+ CoA3| +---|-----------+
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive) 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 7: One of Interface Attached to Home Link and Returning Home Figure 9: One of Interface Attached to Home Link and Returning Home
Figure 7 depicts the scenario where MN returns home with one of its Figure 9 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 7. MN can communicate with the HA through only database of Figure 9. After de-registration, the ND state of the
the interface attached to the home link. On the other hand, the home address is managed by the MN. MN can communicate with the HA
mobile node can communicate with CN from the other interfaces through only the interface attached to the home link. On the other
attached to foreign links (i.e. route optimization). Even when MN is hand, the mobile node can communicate with CN from the other
attached to the home link, it can still send Binding Updates for interfaces attached to foreign links (i.e. route optimization). Even
other active care-of addresses (CoA2 and CoA3). If CN has bindings, if MN is attached to the home link, it can still send Binding Updates
packets are routed to each Care-of Addresses directly. Any packet for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has
arrived at HA are routed to the primary interface. bindings, packets are routed to each Care-of Addresses directly. Any
packet arrived at HA are routed to the interface attached to the home
link.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ +--+-+ | +----+-----+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 | +--+--+ CoA1 |
| | | |
+---------------------------+ +---------------------------+
(Disable interface) (Disable interface)
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding
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 8: One of Interface Attached to Home Link and Not Returning Figure 10: One of Interface Attached to Home Link and Not Returning
Home Home
Figure 8 depicts the scenario where MN disables the interface Figure 10 depicts the scenario where MN disables the interface
attached to the home link and communicates with the interfaces attached to the home link and communicates with the interfaces
attached to foreign links. The HA and the CN have the binding attached to foreign links. HA continues managing the ND state of the
entries listed in their binding cache database. MN disable the home address by Proxy neighbor advertisement. The HA and the CN have
interface attached to the home link, because the HA still defends the the binding entries listed in their binding cache database. All
home address of the MN by proxy neighbor advertisements. All packets packets routed to the home link are intercepted by the HA and
routed to the home link are intercepted by the HA and tunneled to the tunneled to the other interfaces attached to the foreign link
other interfaces attached to the foreign link according to the according to the binding entries.
binding entries.
Topology-a)
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----------+ +--+-+ | +----+-----+ +--+-+
CoA2| | Home Link CoA2| | | Home Link
+--+--+ --+----+---+------ +--+--+ | --+---+------
| MN +===================+ | | MN +========+ |
+--+--+ | +--+--+ CoA1 |
| | CoA3 | |
+---------------------------+ +---------------------------+
Binding Cache Database: Topology-b)
home agent's binding (Proxy neighbor advertisement is inactive)
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
Figure 9: Several Interfaces Attached to Home Link and Returning Home
Figure 9 depicts the scenario where multiple interfaces of MN are
attached to the home link. The HA and CN have the binding entries
listed in Figure 9 in their binding cache database. The MN can not
use the interface attached to a foreign link unless a CN has a
binding for the interface. All packets which arrive at the HA are
routed to one of the MN's interfaces attached to the home link.
Figure 10 depicts the scenario where interfaces of MN are attached to
the foreign links. One of foreign link is managed by the home agent.
The HA and CN have the binding entries listed in Figure 10 in their
binding cache database. The home agent advertises a prefix which is
other than home prefix. The mobile node will generate a care-of
address from the prefix and registers it to the home agent. Even if
the mobile node attaches to a foreign link, the link is managed by
its home agent. It will tunnel the packets to the home agent, but
the home agent is one-hop neighbor. The cost of tunnel is
negligible. If the mobile node wants to utilize not only an
interface attached to home but also interfaces attached to foreign
link, it can use this foreign link of the home agent to return a one
hop foreign link on behalf of a home link. This is different from
the general returning home, but this enable the capability of using
interfaces attached to both home and foreign link without any
modifications to Mobile IPv6 and NEMO basic support.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ Router +----+
+------+ Internet |----------+ HA | +------+ Internet |-------R | HA |
| +----+-----+ ++-+-+ | +----+-----+ | +--+-+
CoA2| | | | Home Link CoA2| | | | Home Link
+--+--+ | ----|-+------ +--+--+ | --+-+-------+------
| MN +========+ | | MN +========+ |
+--+--+ CoA1 ---+-+------ +--+--+ CoA1 |
CoA3 | | Foreign Link CoA3 | |
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) 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]
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 10: Emulating to Utilize Interfaces Attached to both Home and Figure 11: Utilize Interfaces Attached to both Home and Foreign Links
Foreign Links
Figure 11 depicts the scenario where interfaces of MN are attached to
both the home and foreign links. There are two possible topologies
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
the binding entries listed in Figure 11 in their binding cache
database regardless of topologies. The HA also knows that the MN has
attached to the home link. All the traffic from the Internet are
intercepted by the HA and routed to either the interface attached to
the home link or the interfaces attached to the foreign links. How
to make the decision is out of scope in this document.
There are two different treatments of the ND state of the home
address.
o MN defends the home address by regular ND (topology-a)
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 Internet and is capable of intercepting packets without relying
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
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
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
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
to forward packets. The packets forwarding is achieved without ND
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.
Appendix B. Changes From Previous Versions Appendix B. Changes From Previous Versions
Changes from draft-ietf-monami6-multiplecoa-03.txt Changes from draft-ietf-monami6-multiplecoa-04.txt
o Change the handling of Status field. All the status value is o Binding Unique Identifier is renamed to Bidning Identifier
defined for BA
o Alternate CoA option is omitted, but using C flag is recommended. 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 Adding examples of BU o [MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED]
o Many editorial updates 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
skipping to change at page 41, line 7 skipping to change at page 44, line 7
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Azaire Networks
3121 Jay Street 3121 Jay Street
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: vijay.devarapalli@azairenet.com Email: vijay.devarapalli@azairenet.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 170 change blocks. 
539 lines changed or deleted 769 lines changed or added

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