draft-ietf-monami6-multiplecoa-03.txt   draft-ietf-monami6-multiplecoa-04.txt 
Monami6 Working Group R. Wakikawa 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: January 10, 2008 INRIA Expires: May 22, 2008 INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli V. Devarapalli
Azaire Networks Azaire Networks
July 9, 2007 November 19, 2007
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-03.txt draft-ietf-monami6-multiplecoa-04.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 January 10, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, termed the primary have several care-of addresses, but only one, termed the primary
care-of address, can be registered with its home agent and the care-of address, can be registered with its home agent and the
skipping to change at page 3, line 12 skipping to change at page 3, line 12
are targeted to NEMO (Network Mobility) Basic Support as well as to are targeted to NEMO (Network Mobility) Basic Support as well as to
Mobile IPv6. Mobile IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7
3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7
3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10
4.1. Binding Cache Structure and Binding Update List . . . . . 10 4.1. Binding Cache Structure and Binding Update List . . . . . 10
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10
4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10
4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 12 4.3. New Status Values for Binding Acknowledgment . . . . . . . 12
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13
5.1. Management of Care-of Addresses and Binding Unique 5.1. Management of Care-of Addresses and Binding Unique
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14
5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.5. Binding De-Registration and Returning Home . . . . . . . . 16
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 17
5.7. Using Alternate care-of address . . . . . . . . . . . . . 18 5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 18
5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 19 5.8. Sending Packets to Home Agent . . . . . . . . . . . . . . 19
5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 20 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 19
5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20
5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21
6. Home Agent and Correspondent Node Operation . . . . . . . . . 22 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21
6.1. Searching Binding Cache with Binding Unique Identifier . . 22 6.1. Searching Binding Cache with Binding Unique Identifier . . 21
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 26 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 24
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26
8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 28 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27
8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 28 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27
8.2. Transport Mode IPsec protected messages . . . . . . . . . 29 8.2. Transport Mode IPsec protected messages . . . . . . . . . 28
8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 29 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28
8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 29 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28
8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 30 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Configurations . . . . . . . . . . . . . . . 34 Appendix A. Example Configurations . . . . . . . . . . . . . . . 34
Appendix B. Changes From Previous Versions . . . . . . . . . . . 38 Appendix B. Changes From Previous Versions . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 41
1. Introduction 1. Introduction
A mobile node should use various type of network interfaces to obtain A mobile node should use various type of network interfaces to obtain
durable and wide area network connectivity. Assumed scenarios and durable and wide area network connectivity. The assumed scenarios
motivations for multiple points of attachment, and benefits for doing and motivations for multiple points of attachment, and benefits for
it are discussed at large in [10]. doing it are discussed at large in [ID-MOTIVATION].
IPv6 [1] conceptually allows a node to have several addresses on a IPv6 [RFC-2460] conceptually allows a node to have several addresses
given interface. Consequently, Mobile IPv6 [2] has mechanisms to on a given interface. Consequently, Mobile IPv6 [RFC-3775] has
manage multiple ``Home Addresses'' based on home agent's managed mechanisms to manage multiple ``Home Addresses'' based on home
prefixes such as mobile prefix solicitation and mobile prefix agent's managed prefixes such as mobile prefix solicitation and
advertisement. But assigning a single Home Address to a node is more mobile prefix advertisement. But assigning a single Home Address to
advantageous than assigning multiple Home Addresses because a node is more advantageous than assigning multiple Home Addresses
applications do not need to be aware of the multiplicity of Home because applications do not need to be aware of the multiplicity of
Addresses. If multiple home addresses are available, applications Home Addresses. If multiple home addresses are available,
must reset the connection information when the mobile node changes applications must reset the connection information when the mobile
its active network interface (i.e. change the Home Address). node changes its active network interface (i.e. change the Home
Address).
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 [3] is based on Mobile IPv6, the Address. Since NEMO Basic Support [RFC-3963] is based on Mobile
same issues applies to a mobile node acting as mobile router. IPv6, the same issues apply to a mobile node acting as a mobile
Multihoming issues pertaining to mobile nodes operating Mobile IPv6 router. Multihoming issues pertaining to mobile nodes operating
and mobile routers operating NEMO Basic Support are respectively Mobile IPv6 and mobile routers operating NEMO Basic Support are
discussed [4] and [11] in Monami6 and NEMO Working Group. respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6
and NEMO Working Group.
In this document, we thus propose a new identification number called In this document, we thus propose a new identification number called
Binding Unique Identification (BID) number for each binding cache Binding Unique Identification (BID) number for each binding cache
entry to accommodate multiple bindings registration. The BID is entry to accommodate multiple bindings registration. The mobile node
assigned to either the interfaces or care-of addresses bound to a notifies the BID to both its Home Agent and correspondent nodes by
single home address of a mobile node. The mobile node notifies the means of a Binding Update. Correspondent nodes and the home agent
BID to both its Home Agent and correspondent nodes by means of a record the BID into their binding cache. The Home Address thus
Binding Update. correspondent nodes and the home agent record the BID identifies a mobile node itself whereas the BID identifies each
into their binding cache. The Home Address thus identifies a mobile binding registered by a mobile node. By using the BID, multiple
node itself whereas the BID identifies each binding registered by a bindings can then be distinguished.
mobile node. By using the BID, multiple bindings can then be
distinguished.
2. Terminology 2. Terminology
Terms used in this draft are defined in [2], [5] and [6]. In The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
addition or in replacement of these, the following terms are defined "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
or redefined: document are to be interpreted as described in [RFC-2119].
Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
[RFC-4885]. In addition or in replacement of these, the following
terms are defined or redefined:
Binding Unique Identification number (BID) Binding Unique Identification number (BID)
The BID is an identification number used to distinguish multiple The BID is an identification number used to distinguish multiple
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 generated to entries for a given Home Address. The BID is conceptually
register multiple bindings in the binding cache for a given assigned to a binding in a way it cannot be duplicated with
address in a way it cannot be duplicated with another BID. The another BID. The zero value and a negative value MUST NOT be
zero value and a negative value MUST NOT be used. After being used. After being generated by the mobile node, the BID is stored
generated by the mobile node, the BID is stored in the Binding in the Binding Update List and is sent by the mobile node by means
Update List and is sent by the mobile node by means of a sub- of a sub-option of a Binding Update. A mobile node MAY change the
option of a Binding Update. A mobile node MAY change the value of value of a BID at any time according to its administrative policy,
a BID at any time according to its administrative policy, for for instance to protect its privacy. An implementation must
instance to protect its privacy. carefully assign the BID so as to keep using the same BID for the
same binding even when the status of the binding is changed. More
The BID is conceptually assigned to a binding. An implementation details can be found in Section 5.1.
must carefully assign the BID so as to keep using the same BID for
the same binding even when the status of the binding is changed.
More details can be found in Section 5.1.
Binding Unique Identifier sub-option Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is used to carry the BID. The Binding Unique Identifier sub-option is used to carry the BID.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings by sending a single A mobile node can register multiple bindings at once by sending a
binding update. The mobile node does not necessarily put all the single binding update. The mobile node does not necessarily put
available care-of addresses in the binding update, but several all the available care-of addresses in the binding update, but
care-of addresses which can be stored in a Binding Update. The several care-of addresses. A mobile node can also replace all the
bulk registration is supported only for home registration and bindings available at the home agent with the new bindings by
deregistration as explained in Section 5.5. Note that a mobile using the bulk registration. The bulk registration is supported
node should not try to perform bulk registration with only for home registration and deregistration as explained in
correspondent nodes. Section 5.5. A mobile node MUST NOT perform bulk registration
with correspondent nodes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [7].
3. Protocol Overview 3. Protocol Overview
We propose a new identification number (BID) to distinguish multiple A new identification number (BID) is introduced to distinguish
bindings pertaining to the same Home Address. The procedures for the multiple bindings pertaining to the same Home Address. Once a mobile
mobile node to register multiple bindings are described in the node gets several IPv6 global addresses on interfaces, it can
paragraphs below. register these addresses with its home agent. If the mobile node
wants to register multiple bindings, it MUST generate a BID for each
3.1. Multiple Care-of Addresses Registration care-of address and record the BID into the binding update list. A
mobile node can manage each binding independently owing to BID. The
Once a mobile node gets several IPv6 global addresses on interfaces, mobile node then registers its care-of addresses by sending a Binding
it can register these addresses with its home agent (home Update with a Binding Unique Identifier sub-option. The BID MUST be
registration). If the mobile node wants to register multiple included in the Binding Unique Identifier sub-option. After
bindings to its home agent, it MUST generate a BID for each care-of receiving such Binding Update and Binding Unique Identifier sub-
address and record it into the binding update list. The mobile node option, the home agent MUST copy the BID from the Binding Unique
then registers its care-of addresses by sending a Binding Update with Identifier sub-option to the corresponding field in the binding cache
a Binding Unique Identifier sub-option. The BID MUST be put in the entry. Even if there is already an entry for the mobile node's home
Binding Unique Identifier sub-option. After receiving the Binding address, the home agent MUST register a new binding entry for the BID
Update, the home agent verifies the request and records the binding stored in the Binding Unique Identifier sub-option. The mobile node
in its binding cache. If the newly defined sub-option is present in registers multiple care-of addresses either independently in
the Binding Update, the home agent MUST copy the BID from the Binding individual Binding Updates or multiple at once in a single Binding
Update to the corresponding field in the binding entry. Even if Update.
there is already an entry for the mobile node, the home agent MUST
register a new binding entry for the BID stored in the Binding Unique
Identifier sub-option. The mobile node registers multiple care-of
addresses either independently (in individual BUs) or multiple at
once (in a single BU).
If the mobile node 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 operate return routability operations.
The mobile node 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. If it is necessary (ex. Care-of Keygen token is expired),
the mobile node exchanges CoTI and CoT for the releative care-of the mobile host exchanges CoTI and CoT for the relative care-of
addresses. When the mobile node registers several care-of addresses addresses. When the mobile host registers several care-of addresses
to a correspondent node, it uses the same BID as the one generated to a correspondent node, it uses the same BID as the one generated
for the home registration's bindings. The binding registration step for the home registration's bindings. The binding registration step
is the same as for the home registration except for calculating is the same as for the home registration except for calculating
authenticator by using Binding Unique Identifier sub-option as well authenticator by using Binding Unique Identifier sub-option as well
as the other sub-options specified in RFC 3775. For simplicity, the as the other sub-options specified in [RFC-3775]. For simplicity,
bulk registration is not supported for correspondent nodes in this the bulk registration is not supported for correspondent nodes in
document. this document.
3.2. Multiple Bindings Management 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
Unique Identifier sub-options (i.e. normal Binding Update). The
receiver of the Binding Update deletes all the bindings registering
with a BID and registers only a single binding for the mobile node.
Note that the mobile node can continue to use BID even if only a
single binding is active at some time.
The BID is used as a search key for a corresponding entry in the The BID is used as a search key for a corresponding entry in the
binding cache in addition to the Home Address. When a home agent and binding cache in addition to the Home Address. When a home agent and
a correspondent node check the binding cache database for the mobile a correspondent node check the binding cache database for the mobile
node, it searches a corresponding binding entry with the Home Address node, they search a corresponding binding entry with the Home Address
and BID of the desired binding. If necessary, a mobile node can use and BID of the desired binding. If necessary, a mobile node can use
policy and filter information to look up the best binding per policy and filter information to look up the best binding per
sessions, flow, packets, but this is out of scope in this document sessions, flow, packets, but this is out of scope in this document
and is currently discussed in Monami6 WG. and is currently discussed in Monami6 WG. If there is no desired
binding, it searches the binding cache database with the Home Address
If there is no desired binding, it searches the binding cache as specified in Mobile IPv6. The first matched binding entry may be
database with the Home Address as specified in Mobile IPv6. The found, although this is implementation dependent.
first matched binding entry may be found, although this is
implementation dependent.
When one of the care-of addresses has changed, the mobile node sends
a Binding Update with the new care-of address and the corresponding
BID. The receiver of the Binding Update updates the binding which
BID matches the BID contained in the received Binding Unique
Identifier sub-option. The mobile node can manage each binding
independently owing to BID.
If the mobile node decides to act as a regular mobile node compliant
with [2] , it just sends a Binding Update without a Binding Unique
Identifier sub-option (i.e. normal Binding Update). The receiver of
the Binding Update registers only a single binding for the mobile
node and, if necessary, deletes all the bindings registering with a
BID. Note that the mobile node can continue to use BID even if only
a single binding is active at some time.
3.3. Returning Home
When the mobile node returns home, there are two situations, since
the home agent defends the mobile node's Home Address by using the
proxy neighbor advertisement. It is impossible to utilize all the
interfaces when one interface is attached to the home link and the
others are attached to foreign links. If the proxy Neighbor
Advertisement for the Home Address is stopped, packets are always
routed to the interface attached to the home link. If proxy is not
stopped, packets are never routed to the interface attached to the
home link. The decision whether a mobile node returns home or not is
up to implementers.
The first situation is when a mobile node wants to return home with
interface attached to the home link. In this case, the mobile node
MUST de-register all the bindings by sending a Binding Update with
lifetime set to zero. The mobile node MAY NOT put any Binding Unique
Identifier sub-option in this packet. Then, the receiver deletes all
the bindings from its binding cache database. A home agent MUST stop
proxy neighbor advertisement for the home address of the mobile node.
The second situation is when a mobile node does not want to return
home, though 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 for
the interface attached to the home link with the Binding Unique
Identifier sub-option. 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 HA.
In the above two cases, a mobile node cannot use interfaces attached A mobile node carefully operates the returning home. The Home Agent
to both home and foreign links simultaneously. This restriction is
related to the Proxy NDP operation on a Home Agent. The Home Agent
needs to defend a mobile node's home address by the proxy NDP for needs to defend a mobile node's home address by the proxy NDP for
packet interception, while the mobile node defends its home address packet interception, while the mobile node defends its home address
by regular NDP to send and receive packets at the interface attached 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 to the home link. Two nodes, Home Agent and Mobile Node, compete ND
state. This will causes address duplication problem at the end. state. This will causes address duplication problem at the end. If
This document recommends not to use the Proxy NDP for this scenario. the proxy neighbor advertisement for the Home Address is stopped,
When one of the Mobile Node's interface is attached to the home link packets are always routed to the interface attached to the home link.
and the other is attached to the foreign link and it decides to On the other hand, packets are never routed to the interface attached
utilize both interfaces, it notifies the Home Agent using the H flag to the home link when the proxy is active.
which means the Mobile Node is attached to the home link. If the
proxy NDP is disabled, the main problem can be solved. In the When a mobile node wants to return home with interface attached to
Multiple Care-of Address Registration case, the elimination of Proxy the home link, it MUST de-register all the bindings by sending a
NDP enable that Mobile Node and Home Agent maintain multiple Binding Update with lifetime set to zero as described in [RFC-3775]
bindings, one of the Mobile Node's interface is attached to the home and [RFC-3963]. The mobile node does not put any Binding Unique
link and the other is attached to the foreign link. 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
to both home and foreign links simultaneously. If the proxy NDP is
disabled, the main problem can be solved. In the Multiple Care-of
Address Registration, the elimination of Proxy NDP enables that
Mobile Node and Home Agent maintain multiple bindings for the
interfaces attached to the home link and the foreign links. The
mobile node sends the binding update with H flag set for the
interface attached to the home link. The detail operation can be
found in Section 5.5.
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
In this section are described 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 following additional items are required in the binding cache and The BID is required in the binding cache and binding update list
binding update list structure. structure.
BID
The value MUST be zero if the Binding Unique identifier does not
appear in a Binding Update.
4.2. Message Format Changes 4.2. Message Format Changes
4.2.1. Binding Unique Identifier sub-option 4.2.1. Binding Unique Identifier sub-option
The Binding Unique Identifier sub-option is included in the Binding The Binding Unique Identifier sub-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
skipping to change at page 10, line 44 skipping to change at page 10, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
+ care-of address (CoA) + + care-of address (CoA) +
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: BID Sub-Option Figure 1: BID Sub-Option
Type Type
Type value for Binding Unique Identifier will be assigned later. Type value for Binding Unique Identifier is TBD
Length Length
Length value MUST be 4 when C flag is unset. On the other hand if
C flag is set, Length value MUST be set to 20. Length value MUST be 4 when C flag is unset. Otherwise, the
Length value MUST be set to 20.
Binding Unique ID (BID) Binding Unique ID (BID)
The BID which is assigned to the binding carried in the Binding The BID which is assigned to the binding carried in the Binding
Update with this sub-option. BID is 16-bit unsigned integer. A Update with this sub-option. BID is 16-bit unsigned integer. A
value of zero is reserved. value of zero is reserved.
Status Status
When the Binding Unique Identifier sub-option is included in a When the Binding Unique Identifier sub-option is included in a
Binding Acknowledgment, this field indicates the status Binding Acknowledgment, this field overwrites the status field
correspondent to each binding. The mobile node knows the correspondent to each binding in the Binding Acknowledgment. If
registration status of each binding. The status is 8-bit unsigned this field is zero, the receiver MUST use the registration status
integer. The possible status codes are listed below. If the stored in the Binding Acknowledgment message. This Status field
status field is below 128, it indicates that the binding can be used to carry error information for a Care-of Test message.
registration was successful. The status is 8-bit unsigned integer. The possible status codes
are the same as the status codes of Binding Acknowledgment.
MCOA ACCEPTING BID (0)
The registration of the correspond binding is successfully
operated.
MCOA REASON UNSPECIFIED (128)
Registration failed because of unknown errors
MCOA INCOMPLIANT (129)
Registration failed because Binding Unique Identifier sub-
option is not compliant.
MCOA BID CONFLICT (130)
It indicates that a regular binding (ie without the BID set) is
already registered for the home address, and is conflicting
with a received Binding Update which BID was set.
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 Unique Identifier sub-
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 bindings in a single Binding Update, i.e. bulk
registration. registration or MUST be used as a substitute for an alternate
care-of address option. This flag is valid only for binding
update for the home agent.
Overwrite (O) flag 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 for Home Registration and Update. This flag is valid only for binding update for the home
Deregistration. agent.
Home Binding (H) flag Home Binding (H) flag
This flag indicates that the mobile node is attached to the home This flag indicates that the mobile node is attached to the home
link. This flag is valid for Home Registration, Deregistration link. This flag is valid only for binding update for the home
and bulk registration. agent.
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
Only when C flag is set, only a single Care-of Address matched to When C flag is set, a Care-of Address matched to the BID is
the BID is stored. This field is valid only if a Binding Unique stored. This field is valid only if a Binding Unique Identifier
Identifier sub-option is stored in Binding Update message. sub-option is stored in Binding Update message. Otherwise, this
Otherwise, this field can be omitted. The receiver SHOULD ignore field can be omitted. The receiver SHOULD ignore this field if
this field if the sub-option is presented in other than Binding the sub-option is presented in other than Binding Update.
Update.
4.2.2. Binding Acknowledgment 4.3. New Status Values for Binding Acknowledgment
The message format of Binding Acknowledgment does not change, but New status values for the status field in a Binding Acknowledgment
operations listed below are added in this draft. are defined for handling the multiple Care-of Addresses registration:
If a Binding Unique Identifier sub-option is included in a Binding MCOA INCOMPLIANT (TBD)
Update with the A flag set, a receiver MUST reply a Binding
Acknowledgment. The receiver node MUST include the same Binding
Unique Identifier sub-option(s) in the Binding Acknowledgment. The
receiver MUST specify relative status in the Status field of the
Binding Acknowledgment.
There are two status fields: the Status field of a Binding Registration failed because Binding Unique Identifier sub-option
Acknowledgment and the Status field of a Binding Unique Identifier is not compliant.
sub-option. In this specification, the Status field of a Binding
Acknowledgment indicates the registration status of a "Binding
Update". The status value in the Binding Acknowledgment is for all
Binding Unique Identifier sub-options stored in the Binding
Acknowledgment. For example, if the status value is 134 in the
status field of the Binding Acknowledgment, all the care-of addresses
stored in the Binding Unique Identifier sub-options are rejected
because the duplicate address detection has failed on the home agent.
The status field of the Binding Unique Identifier sub-option only MCOA BID CONFLICT (TBD)
informs the receiver about the binding relative to the sub-option.
Whether each Care-of address has been successfully registered
successfully or not is given in the Status field of each Binding
Unique Identifier sub-option.
New status values for the status field of a Binding Acknowledgment It indicates that a regular binding (i.e. without the BID set) is
are defined for handling the multiple Care-of Addresses registration: already registered for the home address, and is conflicting with a
received Binding Update which BID is set.
MCOA PROHIBITED(TBD) MCOA PROHIBITED(TBD)
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)
The bulk binding registration is not supported. The bulk binding registration is not supported.
MCOA FLAG CONFLICTS (TBD) MCOA FLAG CONFLICTS (TBD)
The flags of the sub-options presented in a Binding Update The flags of the sub-options presented in a Binding Unique
conflicts. 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 Unique Identifier
There are two cases when a mobile node has several Care-of Addresses: There are two cases when a mobile node has several Care-of Addresses:
1. A mobile node uses several physical network interfaces and 1. A mobile node uses several physical network interfaces and
acquires a care-of address on each of its interfaces. acquires a care-of address on each of its interfaces.
skipping to change at page 14, line 36 skipping to change at page 13, line 36
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 value
should be generated from a value comprised between 1 to 65535. Zero should be generated from a value comprised between 1 to 65535. Zero
and negative values MUST NOT be taken as a BID. If a mobile node has and negative values MUST NOT be taken as a BID. If a mobile node has
only one care-of address, the assignment of a BID is not needed until only one care-of address, the assignment of a BID is not needed until
it has multiple care-of addresses to register with. 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 send a CoTI per care-of address, while the HoTI and HoT Node, it MUST have the valid care-of Keygen token per care-of
can be exchanged only once for a Home Address. If the Mobile Node address, while the HoTI and HoT can be exchanged only once for a Home
manages bindings with BID, it MUST include a Binding Unique Address.
Identifier sub-option in a Care-of Test Init message. It MUST NOT
set the C and O flag in the sub-option.
The receiver (i.e. correspondent node) will calculate a care-of
keygen token as specified in [2] and reply a Care-of Test message
which contains a Binding Unique Identifier sub-option as described in
Section 6.2. When the mobile node receives the Care-of Test message,
the Care-of Test message is verified as same as in [2] and the
Binding Unique Identifier sub-option in the Care-of Test MUST be
processed as follows:
o If a Binding Unique Identifier sub-option is not presented in CoT
in reply to the CoTI containing the Binding Unique Identifier sub-
option, a correspondent node does not support the Multiple Care-of
Address registration. Thus, the mobile node MUST NOT use a
Binding Unique Identifier sub-option in the Binding Update. It
MUST send a regular Binding Update (i.e. no BID) to the
correspondent node [2]. The Mobile Node MAY skip resending
regular CoTI message and use the received care-of keygen token for
the regular Binding Update, because the correspondent node just
ignores and skip the Binding Unique Identifier sub-option and
calculates the care-of keygen token as [2] specified.
o If the status field of a Binding Unique Identifier sub-option is
set to [MCOA INCOMPLIANT], the received care-of keygen token MUST
NOT be used for sending a Binding Update. It MUST re-send a
Care-of Test Init message again with a corrected Binding Unique
Identifier sub-option which C flag MUST be unset.
o If the status field is set to less than 128, it sends a Binding If the Mobile Node manages bindings with BID, it MUST include a
Update through Return Routability procedure. Binding Unique Identifier sub-option in a Care-of Test Init message.
It MUST NOT set the any flags in the sub-option. The receiver (i.e.
correspondent node) will calculate a care-of Keygen token as
specified in [RFC-3775] and reply a Care-of Test message and the
Binding Unique Identifier sub-option as described in Section 6.2.
When the mobile node receives the Care-of Test message, the Care-of
Test message is verified as same as in [RFC-3775]. If a Binding
Unique Identifier sub-option is not presented in CoT in reply to the
CoTI containing the Binding Unique Identifier sub-option, the
correspondent node does not support the Multiple Care-of Address
registration. Thus, the mobile node MUST NOT use a Binding Unique
Identifier sub-option in the future Binding Update. The Mobile Node
MAY skip resending regular CoTI message and keep the received care-of
Keygen token for the regular Binding Update, because the
correspondent node just ignores and skip the Binding Unique
Identifier sub-option and calculates the care-of Keygen token as
[RFC-3775] specified.
5.3. Binding Registration 5.3. Binding Registration
When a mobile node sends a Binding Update, it MUST decide whether it When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple care-of addresses or not. However, this decision registers multiple care-of addresses or not. However, this decision
is out-of scope in this document. If a mobile node decides not to is out-of scope in this document. If a mobile node decides not to
register multiple care-of addresses, it completely follows the register multiple care-of addresses, it completely follows the
standard RFC 3775 specification. RFC3775 specification.
If a mobile node needs to register multiple Care-of Addresses, it
MUST use BID to identify a care-of address. The mobile node includes
a Binding Unique Identifier sub-option in the Mobility Option field
of a Binding Update. The BID is copied from a corresponding Binding
Update List entry to the BID field of the Binding Unique Identifier
sub-option. If the mobile node wants to replace existing registered
bindings on the home agent to the binding entry(s) in the Binding
Update, it can set O flag.
If a mobile node registers bindings to a correspondent node, it MUST For the multiple Care-of Addresses registration, the mobile node MUST
have both active home and care-of keygen tokens for Kbm (see Section include a Binding Unique Identifier sub-option(s) in the Mobility
5.2.5 of [2]. The care-of keygen tokens MUST be maintained for each Option field of a Binding Update as shown in Figure 2. The BID is
care-of address that the mobile node wants to register to the copied from a corresponding Binding Update List entry to the BID
correspondent node, as described in Section 5.2. After computing an field of the Binding Unique Identifier sub-option. When ESP is used
Authenticator value, it sends a Binding Update which contains a 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
care-of address option. The alternate care-of address option MUST be
omitted. Additionally for binding registration to a correspondent
node, the mobile node MUST have both active home and care-of Keygen
tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen
tokens MUST be maintained for each care-of address that the mobile
node wants to register to the correspondent node, as described in
Section 5.2. After computing an Authenticator value for the Binding
Authorization sub-option, it sends a Binding Update which contains a
Binding Unique Identifier sub-option. The Binding Update is Binding Unique Identifier sub-option. The Binding Update is
protected by a Binding Authorization Data sub-option placed after the protected by a Binding Authorization Data sub-option placed after the
Binding Unique Identifier sub-option. The Mobile Node MUST NOT set Binding Unique Identifier sub-option.
the C flag in the Binding Unique Identifier sub-option.
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header (for home registration)
Mobility header
-BU
Mobility Options
- Binding Unique Identifier sub-option
- Binding Authorization sub-option
(for Route Optimization)
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 from a containing multiple or all the valid care-of addresses.
specific interface which has wider bandwidth.
In this case, a mobile node sets the C flag in a Binding Unique
Identifier sub-option and stores the particular care-of address in
the Binding Unique Identifier sub-option. When the C flag is set,
the length field of the suboption MUST be set to 20. The mobile node
can store multiple sets of a Binding Unique Identifier sub-option in
a Binding Update. If the mobile node wants to replace existing
registered bindings on the home agent with the bindings in the sent
Binding Update, it can set O flag. Section 6.3 describes this
registration procedure in detail. In the bulk registration, all the
other binding information such as Lifetime, Sequence Number, binding
Flags are shared among the bulked Care-of Addresses. Whether a
mobile node registers multiple Care-of Addresses separately or in
bulk is up to implementations.
In the bulk registration, the Sequence Number field of a Binding A mobile node sets the C flag in a Binding Unique Identifier sub-
Update SHOULD be carefully configured. If each binding uses option and stores the particular care-of address in the Binding
Unique Identifier sub-option. The mobile node stores multiple sets
of a Binding Unique Identifier sub-option in a Binding Update as
shown in Figure 3. When multiple Binding Unique Identifier sub-
options are presented in a Binding Update, the flag field of all the
sub-options MUST have the same value. For example, if C flag is set,
the same flag MUST be set to all the sub-options. Otherwise, the
mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding
Acknowledgment. In the bulk registration, all the other binding
information such as Lifetime, Sequence Number, binding Flags are
shared among the bulked Care-of Addresses. The alternate care-of
address option MUST be omitted when ESP is used to protect a binding
update. In the bulk registration, the Sequence Number field of a
Binding Update SHOULD be carefully configured. If each binding uses
different sequence number, a mobile node MUST use the largest different sequence number, a mobile node MUST use the largest
sequence number from the binding update list used for the bulk sequence number from the binding update list used for the bulk
registration. If it cannot select a sequence number for all the registration. If it cannot select a sequence number for all the
bindings due to sequence number out of window, it MUST NOT use the bindings due to sequence number out of window, it MUST NOT use the
bulk registration for the binding which sequence number is out of bulk registration for the binding which sequence number is out of
window and uses a separate Binding Update for the binding. window and uses a separate Binding Update for the binding.
When multiple Binding Unique Identifier sub-options are presented, IPv6 header (src=CoA, dst=HA)
the flag field of all the sub-options MUST have the same value. For IPv6 Home Address Option
example, if C flag is set, the same flag MUST be set to all the sub- ESP Header
options. Mobility header
-BU
5.5. Binding De-Registration Mobility Options
- Binding Unique Identifier sub-options
(C flag is set, O flag is optional,
BID and CoA are stored)
When a mobile node decides to delete all the bindings for its home Figure 3: Binding Update for Binding Bulk Registration
address, it sends a regular de-registration Binding Update. A
Binding Unique Identifier sub-option is not required. See
Section 6.3 for details.
If a mobile node wants to delete a particular binding from its home If the mobile node wants to replace existing registered bindings on
agent and correspondent nodes (e.g. from foreign link), the mobile the home agent with the bindings in the sent Binding Update, it can
node simply sets zero lifetime or uses the home address as the source set O flag. Section 6.3 describes this registration procedure in
address in a Binding Update. The Binding Update MUST contain a detail.
relative Binding Unique Identifier Sub-option (C flag MUST NOT be
set). The receiver will remove only the care-of address that matches
the specified BID.
On the other hand, when a mobile node decides to return home (ie only 5.5. Binding De-Registration and Returning Home
uses its interface attached to the home link), it MUST de-register
all the registered bindings. To do so, the mobile node stores
multiple Binding Unique Identifier sub-options in a Binding Update
which lifetime is set to zero or which source address is set to the
Home Address. C flag MUST be specified in all the Binding Unique
Identifier sub-options. The care-of addresses field of each sub-
option MAY be omitted, because the receiver will remove all the
care-of addresses which matches the specified BID.
O flag is always ignored if a Binding Update is for binding de- When a mobile node decides to delete all the bindings for its home
registration address at a visiting network, it simply sends a regular de-
registration Binding Update which lifetime is set to zero. A Binding
Unique Identifier sub-option is not required.
5.6. Returning Home If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes (e.g. from foreign link), the
mobile node simply sets zero lifetime for the sending binding update.
The Binding Update MUST contain a relative Binding Unique Identifier
Sub-option(s). The receiver will remove only the care-of address(es)
that matches to the specified BID. For the bulk de-registration, the
care-of addresses field of each sub-option SHOULD be omitted, because
the receiver will remove all the care-of addresses which matches the
specified BID.
When a mobile node returns home, it MUST de-register all bindings When a mobile node returns home, it SHOULD de-register all bindings
with the home agent. 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.
Although the mobile node SHOULD delete the bindings with As shown in Figure 7 in Appendix A, a mobile node de-registers all
Correspondent Nodes as well, the node MAY still keep the binding of the binding from the home agent, while it MAY still keep the bindings
the other interface active attached to foreign links only at the of the other interface active attached to foreign links only at the
Correspondent Nodes. In such case, the mobile node still receives Correspondent Nodes. By doing this, the mobile node still receives
packets at the other interface attached to a foreign link thanks to packets from the Correspondent Node at the interface attached to a
route optimization. The mobile node also receives packets at the foreign link thanks to route optimization. If the correspondent
interface attached to the home link when correspondent nodes does not nodes does not use route optimization, the mobile node receives such
use route optimization. packets at the interface attached to the home link.
Note that when the mobile node does not want to return home even if In Figure 8, a mobile node does not want to return home even if one
one of interfaces is attached to the home link, the mobile node MUST of interfaces is attached to the home link. The mobile node MUST
disable the interface. Otherwise, address duplication will be disable the interface attached to the home link. Otherwise, address
observed because the home agent still defend the Home Address by the duplication will be observed because the home agent still defend the
proxy neighbor advertisement and the mobile node also enables the Home Address by the proxy neighbor advertisement and the mobile node
same Home Address on the home link. After disabling the interface also enables the same Home Address on the home link. After disabling
attached to the home link, the mobile node MUST delete the binding the interface attached to the home link, the mobile node MUST delete
for the interface by sending a de-registration binding update. The the binding for the disabled interface by sending a de-registration
de-registration binding update must be sent from one of active binding update. The de-registration binding update is sent from one
interfaces attached to foreign links. As a result, the mobile node of active interfaces attached to foreign links. As a result, the
no longer receives packets at the interface attached to the home mobile node no longer receives packets at the interface attached to
link. All packets are routed to other interfaces attached to a the home link. All packets are routed to other interfaces attached
foreign link. to a foreign link.
Alternatively, the Mobile Node may choose to activate both the Alternatively, the Mobile Node may choose to activate both the
interfaces attached to the home link and the foreign link, and interfaces attached to the home link and the foreign link, and
communicates with all of the interfaces. The Mobile Node notifies communicates with all of the interfaces. The Mobile Node notifies
the Home Agent using the H flag which means the Mobile Node is the Home Agent using the H flag which means the Mobile Node is
attached to the home link. The Mobile Node may notify the care-of attached to the home link. The Mobile Node may notify the care-of
address of the interface(s) attached to the foreign link(s) in the address of the interface(s) attached to the foreign link(s) in the
same message using bulk registration. The Home Agent then no longer same message using bulk registration. The Home Agent then no longer
uses Proxy Neighbor Advertisement to intercept packets and the Mobile uses Proxy Neighbor Advertisement to intercept packets and the Mobile
Node can utilize both of interfaces attached to the home link and the Node can utilize both of interfaces attached to the home link and the
foreign link simultaneously. The Home Agent can intercept packets by foreign link simultaneously. The Home Agent can intercept packets by
IP routing, but not by proxy Neighbor Discovery. 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 When the Mobile Node returns home, it de-registers a binding for the
interface. While the bindings for the interfaces attached to the interface. While the bindings for the interfaces attached to the
foreign link are still active. Intercepting packets, the Home Agent foreign link are still active. Intercepting packets, the Home Agent
can decide whether it tunnels to the foreign interface or routes to 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 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 know that the Mobile Node is back to the home link. However, if the
binding is deleted according to [2], there is no way for the Home binding is deleted, there is no way for the Home Agent to know that
Agent to know that the Mobile Node is at the home, too. The Home the Mobile Node is at the home, too. The Home Agent SHOULD
Agent SHOULD invalidate the binding for the interface attached to the invalidate the binding for the interface attached to the home link
home link and MAY NOT delete it. It can alternatively mark that the and MAY NOT delete it. It can alternatively mark that the Mobile
Mobile Node is at the home link, too. As an example, the Home Agent Node is at the home link, too. As an example, the Home Agent inserts
inserts the Home Address of the Mobile Node in the Care-of Address the Home Address of the Mobile Node in the Care-of Address field of
field of the Mobile Node. The binding is named "Home Binding" in the Mobile Node. The binding is named "Home Binding" in this
this doc. The Home Agent MAY manage this home binding as same as the documentation. The Home Agent MAY manage this home binding as same
other binding entry in terms of lifetime validation, etc. The Mobile as the other binding entry in terms of lifetime validation, etc. The
Node MAY send multiple binding de- registration to keep this home Mobile Node MAY send multiple binding de- registration to keep this
binding active. Alternatively, the Home Agent can use infinity home binding active. Alternatively, the Home Agent can use infinity
lifetime for the lifetime of the home binding. When the Mobile Node 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 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 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. the home and may route packets for the Mobile Node to the Home Link.
5.7. Using Alternate care-of address 5.6. Receiving Binding Acknowledgment
A mobile node can use an alternate care-of address in a following
situation. One care-of address becomes invalid (e.g because the link
where it is attached to is no longer available) and MUST be deleted.
In such case, the mobile node can not send a Binding Update from the
care-of address because the interface's link is lost. The mobile
node needs to de-register the remote binding of the care-of address
through one of its active care-of addresses.
In this case, the mobile node include both Alternate Care-of Address
sub-option and Binding Unique Identifier sub-option in a Binding
Update. An Alternate care-of address sub-option can be presented
only once in a Binding Update after a Binding Unique Identifier sub-
option. The care-of address stored in an Alternate Care-of address
sub-option is replaced the address in the source address field as
same as [2] specified.
If C flag is set in a Binding Unique Identifier sub-option, an
Alternate Care-of Address sub-option SHOULD NOT be used. A receiver
uses the care-of addresses and BID stored in each Binding Unique
Identifier sub-option to modify corresponding binding cache entries.
Any address can be specified in the Source address field of the IPv6
header of the Binding Update even without an Alternate Care-of
Address sub-option.
5.8. Receiving Binding Acknowledgment
The verification of a Binding Acknowledgment is the same as in Mobile The verification of a Binding Acknowledgment is the same as 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 Unique Identifier sub-option in a
Binding Update with A flag set, a Binding Acknowledgment MUST have a Binding Update with A flag set, a Binding Acknowledgment MUST carry a
Binding Unique Identifier sub-option in the Mobility Options field. Binding Unique Identifier sub-option in the Mobility Options field.
If no such sub-option appears in the Binding Acknowledgment replied If no such sub-option is appeared in the Binding Acknowledgment
to the Binding Update for the multiple care-of address registration, replied to the Binding Update for the multiple care-of address
this means that the originator node of this Binding Acknowledgment registration, this indicates that the originator node of this Binding
might not recognize the Binding Unique Identifier sub-option. The Acknowledgment might not recognize the Binding Unique Identifier sub-
mobile node SHOULD stop registering multiple care-of addresses by option. The mobile node SHOULD stop registering multiple care-of
using a Binding Unique Identifier sub-option. If the originator is addresses by using a Binding Unique Identifier sub-option.
the home agent, the mobile node MAY try to discover a new home agent
supporting the multiple care-of address registration or give up with
the multiple care-of address registration.
If a Binding Unique Identifier sub-option is present in the received If a Binding Unique Identifier sub-option is present in the received
Binding Acknowledgment, the mobile node checks the Status field of Binding Acknowledgment, the mobile node checks the registration
the Binding Acknowledgment. If the status code indicates successful status for the Care-of address(es). The status value MUST be
registration (less than 128), the originator successfully registered retrieved as follows. If the status value in the Binding Unique
the binding information and BID for the mobile node. Identifier sub-option is zero, the mobile node uses the value in the
Status field of the Binding Acknowledgment. Otherwise, it uses the
value in the Status field of the Binding Unique Identifier sub-
option.
If the status code of the Binding Acknowledgment is greater than or If the status code is greater than or equal to 128, the mobile node
equal to 128, the mobile node proceeds with relevant operations starts relevant operations according to the error code. Otherwise,
according to the status code of the Binding Acknowledgment. The the originator (home agent or correspondent node) successfully
status value of the stored Binding Unique Identifier sub-option may registered the binding information and BID for the mobile node.
be used to decide further operation.
o If the Status value of the Binding Acknowledgment is [MCOA o If the Status value is [MCOA PROHIBITED], the mobile node MUST
PROHIBITED], the mobile node MUST give up registering multiple give up registering multiple bindings to the peer sending the
bindings to the peer sending the Binding Acknowledgment. It MUST Binding Acknowledgment. It MUST return to the regular Mobile IPv6
return to the regular Mobile IPv6 [2] 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 in the Binding o If [MCOA FLAG CONFLICTS] is specified, it indicates that the
Acknowledgment, it indicates that the different flag values are different flag values are used in Binding Unique Identifier sub-
used in Binding Unique Identifier sub-options in a Binding Update. options in a Binding Update. If the C flag is set, all sub-
If the C flag is set, all sub-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 [2].
The mobile node also learn detailed registration status from the
Status field of each Binding Unique Identifier sub-option. If the
value is greater than or equal to 128, the mobile node proceeds with
relevant operations according to the status value.
o If [MCOA BID CONFLICT] is specified, the binding entry specified o If [MCOA BID CONFLICT] is specified, the binding entry specified
by the Binding Unique Identifier sub-option is already registered by the Binding Unique Identifier sub-option is already registered
as a regular binding. In such case, the mobile node SHOULD stop as 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 sending the Binding Acknowledgment. peer to reset all the registered bindings.
5.9. Receiving Binding Refresh Request 5.7. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of RFC 3775). The operation of sending a Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending
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 Unique Identifier sub-option, this Binding Refresh Request requests a
binding indicated by the BID. The mobile node SHOULD update only the new binding indicated by the BID. The mobile node SHOULD update only
respective binding. The mobile node MUST put a Binding Unique the respective binding. The mobile node MUST put a Binding Unique
Identifier sub-option into the Binding Update sent to refresh the Identifier sub-option into the Binding Update sent to refresh the
entry. entry.
If no Binding Unique Identifier sub-option is present in a Binding If no Binding Unique Identifier sub-option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according to Refresh Request, the mobile node sends a Binding Update according to
its Binding Update List for the requesting node. On the other hand, its Binding Update List. On the other hand, if the mobile node does
if the mobile node does not have any Binding Update List entry for not have any Binding Update List entry for the requesting node, the
the requesting node, the mobile node needs to register either a mobile node needs to register either a single binding or multiple
single binding or multiple bindings depending on its binding bindings depending on its binding management policy.
management policy.
5.10. Sending Packets to Home Agent 5.8. 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
redundant path such as dog-leg route or triangular route occurs. redundant path such as dog-leg route occurs. However, in this
document, the mobile node is capable of using multiple care-of
However, in this document, the mobile node is capable of using addresses for outgoing packets. This is problem in home agent side
multiple care-of addresses for outgoing packets. This is problem in because they must verify the Care-of address for all the packets
home agent side because they must verify the Care-of address for all received from the mobile node (i.e. ingress filtering). When it uses
the packets received from the mobile node. Therefore, the mobile the Home Address option, the home agent MAY check the care-of address
node SHOULD use the bi-directional tunnel even if it registers a in the packet with the registering binding entries. This causes
binding(s) to the home agent. When it uses the Home Address option, additional overhead to the home agent. Therefore, the mobile node
the home agent MAY reject the packets because the Care-of address in SHOULD use the bi-directional tunnel even if it registers a
the packet and the first found Care-of Address in the binding Cache binding(s) to the home agent.
of the home agent are different. The mobile node then receive
Binding Error for the packet drop.
5.11. Bootstrapping 5.9. 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 Unique Identifier
sub-option. when old bindings still exists at the Home Agent and sub-option. If old bindings still exists at the Home Agent, the
Correspondent Nodes, the mobile node has no way to verify which mobile node has no way to know which bindings are remained as a
bindings are left as a garbage in those nodes. This scenario happens garbage. This scenario happens when a mobile node reboots without
when a mobile node reboots without correct deregistration. If O flag correct deregistration. If O flag is used, all the bindings are
is used, all the bindings are replaced to the new binding(s). Thus, replaced to the new binding(s). Thus, the garbage bindings are
the garbage bindings are surely removed by the first Binding Update. surely replaced by new bindings registered with the first Binding
XXX SEQ Update. If the mobile node receives the Binding Acknowledgment with
the status code set to 135 [Sequence number out of window], it MUST
retry sending a Binding Update with the last accepted sequence number
which is notified by the Binding Acknowledgment.
For Correspondent nodes, the mobile node cannot use the O flag
because of no bulk registration support. Thus, if necessary, it MUST
sends a regular binding first to overwrite the remaining bindings at
the correspondent node. Then, it can re-register the set of bindings
by using Multiple Care-of Address Registration.
6. Home Agent and Correspondent Node Operation 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Unique Identifier 6.1. Searching Binding Cache with Binding Unique Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. How to select the the bindings to communicate with the mobile node. How to select the
most suitable binding from the binding cache database is out of scope most suitable binding from the binding cache database is out of scope
in this document. in this document.
skipping to change at page 22, line 25 skipping to change at page 21, line 25
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 2: 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 Unique Identifier sub-option. At the time, the correspondent
node MUST look up its binding cache database with the Home Address node MUST look up its binding cache database with the Home Address
and the BID retrieved from 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 Care-of Test Init message which When a correspondent node receives a CoTI message which contains a
contains a Binding Unique Identifier sub-option, it MUST process it Binding Unique Identifier sub-option, it MUST process it with
with following steps. following steps.
First of all, the Care-of Test Init message is verified according to First of all, the CoTI message is verified according to [RFC-3775].
[2]. The Binding Unique Identifier sub-option MUST be processed as The Binding Unique Identifier sub-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 Unique
Identifier sub-option, it will ignore and skip this option. The Identifier sub-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. After regular processing of HoTI message according to BID value. The correspondent node returns a CoT message without a
[2], it will return a Care-of Test message without use of a
Binding Unique Identifier sub-option. The mobile node can thus Binding Unique Identifier sub-option. The mobile node can thus
know whether its correspondent can process or not the Binding know whether the correspondent can process the Binding Unique
Unique Identifier sub-option by checking if such option is present Identifier sub-option or not, by checking if such option is
in the Care-of Test message. present in the CoT message.
o If C flag is set in the sub-option, the Correspondent Node SHOULD
NOT calculate a care-of keygen token and MUST include a Binding
Unique Identifier sub-option which status value set to [MCOA
INCOMPLIANT] in the returned Care-of Test message. All the fields
of the Care-of Test message MUST be set to zero. All the Binding
Unique Identifier sub-options SHOULD be copied from the received
one except for the Status Field and the Care-of Address field.
o If O flag is set in the sub-option, the Correspondent Node can o If either or both C and O flag is set in the sub-option, the
ignore this flag and can process it as described in the next Correspondent Node SHOULD NOT calculate a care-of Keygen token and
bullet. MUST include a Binding Unique Identifier sub-option which status
value set to [MCOA INCOMPLIANT] in the returned Care-of Test
message.
o Otherwise, the correspondent node MUST include a Binding Unique o Otherwise, the correspondent node MUST include a Binding Unique
Identifier sub-option which status value MUST be set to [MCOA Identifier sub-option which status value MUST be set to zero in
ACCEPTING BID] in the returning a Care-of Test message. The the returning a CoT message.
Binding Unique Identifier sub-option SHOULD be copied from the
received one except for the Status Field and the Care-of address o All the Binding Unique Identifier sub-options SHOULD be copied
Field. from the received one except for the Status Field for CoT. The
Care-of address field of each Binding Unique Identifier sub-
option, however, can be omitted, because the mobile node can match
a corresponding binding update list by using BID.
6.3. Processing Binding Update 6.3. Processing Binding Update
If a Binding Update does not contain a Binding Unique Identifier sub- If a Binding Update does not contain a Binding Unique Identifier sub-
option, its processing is same as in RFC 3775. But if the receiver 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 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.
On the other hand, if a Binding Update contains a Binding Unique If a Binding Update contains a Binding Unique Identifier sub-
Identifier sub-option(s), the Binding Update is also validated option(s), it is validated according to section 9.5.1 of [RFC-3775]
according to section 9.5.1 of [2] and the following step. and the following step.
o If the home flag is set in the Binding Update, the home agent MUST o If the home registration flag is set in the Binding Update, the
carefully operate DAD for the received Home Address. If the home home agent MUST carefully operate DAD for the received Home
agent has already had a binding(s) for the Mobile Node, it MUST Address. If the home agent has already had a binding(s) for the
avoid running DAD when it receives the Binding Update. Mobile Node, it MUST avoid running DAD check when it receives the
Binding Update.
If a Binding Unique Identifier sub-option(s) is present, the receiver The receiver node MUST process the Binding Unique Identifier sub-
node MUST process the sub-option. option(s) in the following steps. When a correspondent node sends a
Binding Acknowledgment, the status value is always stored in the
Status field of the Binding Acknowledgment and keep the Status field
of Binding Unique Identifier sub-option to zero. For the Home Agent,
the status value can be stored in the Status field of either a
Binding Acknowledgment or a Binding Unique Identifier sub-option. If
the status value is specific to one of bindings in the bulk
registration, the status value MUST be stored in the Status field in
the corresponding Binding Unique Identifier sub-option.
o The length value is examined. The length value MUST be either 4 o The length value is examined. The length value MUST be either 4
or 20 depending on C flag. If the length is incorrect, the or 20 depending on C flag. If the length is incorrect, the
receiver MUST rejects the Binding Update and returns all the receiver MUST rejects the Binding Update and returns the status
received Binding Unique Identifier sub-option which status value value set to [MCOA INCOMPLIANT].
is set to [MCOA INCOMPLIANT]. The status field of the Binding
Acknowledgment MUST be set to [REASON UNSPECIFIED, 128].
o When C flag is set, the receiver MUST support the bulk
registration. Otherwise, it MUST reject the Binding Update and
returns all the received Binding Unique Identifier sub-option
which status value is set to [MCOA REASON UNSPECIFIED]. The
status field of the Binding Acknowledgment MUST be set to [MCOA
BULK REGISTRATION NOT SUPPORTED].
o When either C or O flag is set, 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 all the received Binding Unique Identifier sub-
option which status value is set to [MCOA REASON UNSPECIFIED].
The status field of the Binding Acknowledgment MUST be set to
[MCOA FLAG CONFLICTS].
o When C flag is specified, the care-of address MUST be given in the o When C flag is specified, the care-of address MUST be given in the
Binding Unique Identifier sub-option. Otherwise, the receiver Binding Unique Identifier sub-option. Otherwise, the receiver
MUST reject the Binding Update and returns all the received MUST reject the Binding Unique Identifier sub-option and returns
Binding Unique Identifier sub-option which status value is set to the status value set to [MCOA INCOMPLIANT].
[MCOA INCOMPLIANT]. The status field of the Binding
Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. o When multiple binding Unique Identifier sub-options are presented,
the receiver MUST support the bulk registration. Only a home
agent can accept the bulk registration. Otherwise, it MUST reject
the Binding Update and returns the status value set to [MCOA BULK
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 Unique Identifier sub-option. If the receiver node
does not have appropriate binding which BID is matched with the does not have appropriate binding which BID is matched with the
Binding Update, it MUST reject this de-registration Binding Binding Update, it MUST reject this de-registration Binding Update
Update. If the receiver is a Home Agent, it SHOULD also return a for the binding cache. If the receiver is a Home Agent, it SHOULD
Binding Acknowledgment to the mobile node, in which the Status also return the status value set to [not Home Agent for this
field is set to [not Home Agent for this mobile node, 133]. If O mobile node, 133].
flag is set in the deregistering Binding Update, the receiver can
ignore this flag for deregistration. If the H flag is set, the o If O flag is set in the deregistering Binding Update, the receiver
home agent stores a Home Address in the Care-of Address field of can ignore this flag for deregistration. If the H flag is set,
the binding cache entry. The home agent no longer performs proxy the home agent stores a Home Address in the Care-of Address field
NDP for this mobile node until this entry is deleted. of the binding cache entry. The home agent no longer performs
proxy NDP for this mobile node until this entry is deleted.
o If the Lifetime field is not zero, the receiver node registers a 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 Unique Identifier sub-option,
the care-of address must be taken from the care-of address the care-of address must be taken from the care-of address
field in each Binding Unique Identifier sub-option. field in each Binding Unique Identifier sub-option.
skipping to change at page 25, line 29 skipping to change at page 24, line 23
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 sub-option, the home agent first
removes all the existing bindings and registers the received removes all the existing bindings and registers the received
bindings. 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 specify [MCOA BID Update. In this case, the receiver MUST return [MCOA BID
CONFLICT] to the Binding Unique Identifier sub-option which is CONFLICT].
replied to the Mobile Node. The Status field of the replying
Binding Acknowledgment MUST be set to [Binding Update ACCEPTED,
0].
* If the receiver node has already registered the binding which * If the receiver node has already registered the binding which
BID is matched with requesting BID, then it MUST update the BID is matched with requesting BID, then it MUST update the
binding with the Binding Update. binding with the Binding Update and returns [0 Binding Update
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. 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 Unique Identifier sub-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 Unique Identifier sub-options stored in the Binding
Update MUST be copied to the Binding Acknowledgment. The Care-of Update MUST be copied to the Binding Acknowledgment. The Care-of
address field of each Binding Unique Identifier sub-option, however, address field of each Binding Unique Identifier sub-option, however,
can be omitted, because the mobile node can match a corresponding can be omitted, because the mobile node can match a corresponding
binding update list by using BID. binding update list by using BID.
6.4. Sending Binding Refresh Request 6.4. Sending Binding Refresh Request
When either a correspondent node or home agent notices that a When a node sends a Binding Refresh Request for a particular binding
registered binding will be expired soon, it MAY send a Binding registering with BID, the node SHOULD contain a Binding Unique
Refresh Request. If the registered binding has BID, the Identifier sub-option in the Binding Refresh Request.
correspondent node SHOULD contain a Binding Unique Identifier sub-
option in the Binding Refresh Request. Then, the Correspondent Node
can receive a Binding Update with a Binding Unique Identifier sub-
option and can update only the particular binding. If the registered
binding does not have BID, then the correspondent node sends a
Binding Refresh Request without the sub-option.
6.5. Receiving Packets from Mobile Node 6.5. Receiving Packets from Mobile Node
When a correspondent node receives packets with a Home Address When a node receives packets with a Home Address destination option
destination option from a mobile node, it MUST check that the care-of from a mobile node, it MUST check that the care-of address appeared
address appeared in the Source Address field MUST be equal to one of in the Source Address field MUST be equal to one of the care-of
the care-of addresses in the binding cache entry. If no binding is addresses in the binding cache entry. If no binding is found, the
found, the packets MUST be silently discarded and MUST send a Binding packets MUST be silently discarded and MUST send a Binding Error
Error message according to RFC3775. This verification MUST NOT be message according to RFC3775. This verification MUST NOT be done for
done for a Binding Update. a Binding Update.
7. Network Mobility Applicability 7. Network Mobility Applicability
Support of multihomed mobile routers is advocated in the NEMO working Support of multihomed mobile routers is advocated in the NEMO working
group (see R12 "The solution MUST function for multihomed MR and group (see R12 "The solution MUST function for multihomed MR and
multihomed mobile networks" in [8]. multihomed mobile networks" in [RFC-4886]. Issues regarding mobile
routers with multiple interfaces and other multihoming configurations
Issues regarding mobile routers with multiple interfaces and other are documented in [RFC-4980].
multihoming configurations are documented in [11].
Since the binding management mechanisms are the same for a mobile Since the binding management mechanisms are the same for a mobile
host operating Mobile IPv6 and for a mobile router operating NEMO host operating Mobile IPv6 and for a mobile router operating NEMO
Basic Support (RFC 3963), our extensions can also be used to deal Basic Support (RFC 3963), our extensions can also be used to deal
with multiple care-of addresses registration sent from a multihomed with multiple care-of addresses registration sent from a multihomed
mobile router. mobile router. Figure 5 shows the example format of a Binding Update
used by a mobile router.
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Unique Identifier sub-option
- Mobile Network Prefix sub-option
Figure 5: NEMO Binding Update
8. IPsec and IKEv2 interaction 8. IPsec and IKEv2 interaction
Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
protect signaling messages like Binding Updates, Binding use of IPsec to protect signaling messages like Binding Updates,
Acknowledgments and return routability messages. IPsec may also be Binding Acknowledgments and return routability messages. IPsec may
used protect all reverse tunneled data traffic. The Mobile IPv6- also be used protect all reverse tunneled data traffic. The Mobile
IKEv2 specification [9] specifies how IKEv2 can be used to setup the IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used
required IPsec security associations. The following assumptions were to setup the required IPsec security associations. The following
made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2
respect to the use of IKEv2 and IPsec. specification with respect to the use of IKEv2 and IPsec.
o There is only one primary care-of address per mobile node. o There is only one primary care-of address per mobile node.
o The primary care-of address is stored in the IPsec database for o The primary care-of address is stored in the IPsec database for
tunnel encapsulation and decapsulation. tunnel encapsulation and decapsulation.
o When the home agent receives a packet from the mobile node, the o When the home agent receives a packet from the mobile node, the
source address is verified against the care-of address in the source address is verified against the care-of address in the
corresponding binding cache entry. If the packet is a reverse corresponding binding cache entry. If the packet is a reverse
tunneled packet from the mobile node, the care-of address check is tunneled packet from the mobile node, the care-of address check is
skipping to change at page 29, line 14 skipping to change at page 28, line 14
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 8.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 8.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 8.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
skipping to change at page 31, line 8 skipping to change at page 30, line 8
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 9. Security Considerations
As shown in Section 8, the Multiple Care-of Addresses Registration As shown in Section 8, the Multiple Care-of Addresses Registration
requires IPsec protected all the signalings between a mobile node and requires IPsec protected all the signaling between a mobile node and
its home agent. its home agent.
10. IANA Considerations 10. IANA Considerations
The following Extension Types MUST be assigned by IANA: The following Extension Types MUST be assigned by IANA:
1. Binding Unique Identifier sub-option type o Binding Unique Identifier sub-option type
2. New Status of Binding Acknowledgement o New Status of Binding Acknowledgment
* MCOA INCOMPLIANT (TBD)
* MCOA BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD)
* MCOA FLAG CONFLICTS (TBD)
11. Acknowledgments 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), Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson),
Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen Benjamin Koh (Panasonic), Susumu Koshiba, Martti Kuparinen
(Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki
Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji
Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D)
in alphabetical order, the Jun Murai Lab. at KEIO University. in alphabetical order, the Jun Murai Lab. at KEIO University.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] 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.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
Kuladinithi, "Analysis of Multihoming in Mobile IPv6", K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-02 (work in progress), draft-ietf-monami6-mipv6-analysis-02 (work in progress), February
February 2007. 2007.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 3753, June 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-nemo-terminology-06 (work in progress), RFC 3753, June 2004.
November 2006.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Levels", BCP 14, RFC 2119, March 1997. Terminology", RFC 4885, July 2007.
[8] Ernst, T., "Network Mobility Support Goals and Requirements", [RFC-4886] Ernst, T., "Network Mobility Support Goals and
draft-ietf-nemo-requirements-06 (work in progress), Requirements", RFC 4886, July 2007.
November 2006.
[9] 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", IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
December 2006.
12.2. Informative References 12.2. Informative References
[10] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
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-01 (work in draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), October 2006. [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007.
[11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming [ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of
in Network Mobility Support", Proxy NDP from Home Agent Operations",
draft-ietf-nemo-multihoming-issues-06 (work in progress), draft-wakikawa-mip6-no-ndp-02.txt (work in progress), November 2007.
June 2006.
Appendix A. Example Configurations Appendix A. Example Configurations
In this section, we describe typical scenarios when a mobile node has In this section, we describe typical scenarios when a mobile node has
multiple network interfaces and acquires multiple Care-of Addresses multiple network interfaces and acquires multiple Care-of Addresses
bound to a Home Address. 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 35, line 4 skipping to change at page 34, line 37
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 3: Multiple Interfaces Attached to a Foreign Link
Figure 3 depicts the scenario where all interfaces of the mobile node Figure 6: Multiple Interfaces Attached to a Foreign Link
Figure 6 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 |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
skipping to change at page 35, line 33 skipping to change at page 35, line 26
CoA3| +---|-----------+ CoA3| +---|-----------+
+---------------+ +---------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3] binding [a:b:c:d::EUI care-of address3 BID3]
Figure 4: One of Interface Attached to Home Link and Returning Home Figure 7: One of Interface Attached to Home Link and Returning Home
Figure 4 depicts the scenario where MN returns home with one of its Figure 7 depicts the scenario where MN returns home with one of its
interfaces. After the successful de-registration of the binding to interfaces. After the successful de-registration of the binding to
HA, HA and CN have the binding entries listed in their binding cache HA, HA and CN have the binding entries listed in their binding cache
database of Figure 4. MN can communicate with the HA through only database of Figure 7. MN can communicate with the HA through only
the interface attached to the home link. On the other hand, the the interface attached to the home link. On the other hand, the
mobile node can communicate with CN from the other interfaces mobile node can communicate with CN from the other interfaces
attached to foreign links (i.e. route optimization). Even when MN is attached to foreign links (i.e. route optimization). Even when MN is
attached to the home link, it can still send Binding Updates for attached to the home link, it can still send Binding Updates for
other active care-of addresses (CoA2 and CoA3). If CN has bindings, other active care-of addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface. arrived at HA are routed to the primary interface.
+----+ +----+
| CN | | CN |
skipping to change at page 36, line 28 skipping to change at page 36, line 28
(Disable interface) (Disable interface)
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active) home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 5: One of Interface Attached to Home Link and Not Returning Figure 8: One of Interface Attached to Home Link and Not Returning
Home Home
Figure 5 depicts the scenario where MN disables the interface Figure 8 depicts the scenario where MN disables the interface
attached to the home link and communicates with the interfaces attached to the home link and communicates with the interfaces
attached to foreign links. The HA and the CN have the binding attached to foreign links. The HA and the CN have the binding
entries listed in their binding cache database. MN disable the entries listed in their binding cache database. MN disable the
interface attached to the home link, because the HA still defends the interface attached to the home link, because the HA still defends the
home address of the MN by proxy neighbor advertisements. All packets home address of the MN by proxy neighbor advertisements. All packets
routed to the home link are intercepted by the HA and tunneled to the routed to the home link are intercepted by the HA and tunneled to the
other interfaces attached to the foreign link according to the other interfaces attached to the foreign link according to the
binding entries. binding entries.
+----+ +----+
skipping to change at page 37, line 25 skipping to change at page 37, line 25
+--+--+ | +--+--+ |
| | | |
+---------------------------+ +---------------------------+
Binding Cache Database: Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive) home agent's binding (Proxy neighbor advertisement is inactive)
none none
correspondent node's binding correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address2 BID2]
Figure 6: Several Interfaces Attached to Home Link and Returning Home Figure 9: Several Interfaces Attached to Home Link and Returning Home
Figure 6 depicts the scenario where multiple interfaces of MN are Figure 9 depicts the scenario where multiple interfaces of MN are
attached to the home link. The HA and CN have the binding entries attached to the home link. The HA and CN have the binding entries
listed in Figure 6 in their binding cache database. The MN can not listed in Figure 9 in their binding cache database. The MN can not
use the interface attached to a foreign link unless a CN has a use the interface attached to a foreign link unless a CN has a
binding for the interface. All packets which arrive at the HA are binding for the interface. All packets which arrive at the HA are
routed to one of the MN's interfaces attached to the home link. routed to one of the MN's interfaces attached to the home link.
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 |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ ++-+-+
CoA2| | | | Home Link
+--+--+ | ----|-+------
| MN +========+ |
+--+--+ CoA1 ---+-+------
CoA3 | | Foreign Link
+---------------------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
Figure 10: Emulating to Utilize Interfaces Attached to both Home and
Foreign Links
Appendix B. Changes From Previous Versions Appendix B. Changes From Previous Versions
Changes from draft-ietf-monami6-multiplecoa-02.txt Changes from draft-ietf-monami6-multiplecoa-03.txt
o Add Security Considerations o Change the handling of Status field. All the status value is
defined for BA
o Add IANA Considerations o Alternate CoA option is omitted, but using C flag is recommended.
o Add H flag for BID option and Modify Returning Home. o Adding examples of BU
o Many editorial updates
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa (Editor)
Keio University Faculty of Environment and Information Studies, Keio University
Department of Environmental Information, Keio University.
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100 Phone: +81-466-49-1100
Fax: +81-466-49-1395 Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/ URI: http://www.wakikawa.org/
Thierry Ernst Thierry Ernst
 End of changes. 142 change blocks. 
670 lines changed or deleted 627 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/