draft-ietf-monami6-multiplecoa-09.txt   draft-ietf-monami6-multiplecoa-10.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC/Keio Univ. Internet-Draft Toyota ITC/Keio Univ.
Intended status: Standards Track V. Devarapalli (Ed.) Intended status: Standards Track V. Devarapalli (Ed.)
Expires: March 1, 2009 Wichorus Expires: May 8, 2009 Wichorus
T. Ernst T. Ernst
INRIA INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
August 28, 2008 November 4, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-09.txt draft-ietf-monami6-multiplecoa-10.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 March 1, 2009. This Internet-Draft will expire on May 8, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, called the primary have several care-of addresses, but only one, called the primary
care-of address, that can be registered with its home agent and the care-of address, that can be registered with its home agent and the
skipping to change at page 3, line 7 skipping to change at page 2, line 21
etc, it is useful for the mobile node to get Internet access through etc, it is useful for the mobile node to get Internet access through
multiple accesses simultaneously, in which case the mobile node would multiple accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses. This be configured with multiple active IPv6 care-of addresses. This
document proposes extensions to the Mobile IPv6 protocol to register document proposes extensions to the Mobile IPv6 protocol to register
and use multiple care-of addresses. The extensions proposed in this and use multiple care-of addresses. The extensions proposed in this
document can be used by Mobile Routers using the NEMO (Network document can be used by Mobile Routers using the NEMO (Network
Mobility) Basic Support protocol as well. Mobility) Basic Support protocol as well.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 12 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11
4.1. Binding Cache Structure and Binding Update List . . . . . 12 4.1. Binding Cache Structure and Binding Update List . . . . . 11
4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 12 4.2. Binding Identifier Mobility Option . . . . . . . . . . . . 11
4.3. New Status Values for Binding Acknowledgement . . . . . . 14 4.3. New Status Values for Binding Acknowledgement . . . . . . 13
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 16 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15
5.1. Management of Care-of Address(es) and Binding 5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 16 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 16 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 15
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 17 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 16
5.4. Bulk Registration . . . . . . . . . . . . . . . . . . . . 17 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 17
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 18 5.5. Returning Home: Using Single Interface . . . . . . . . . . 17
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 18 5.5.1. Using only Interface attached to the Home Link . . . . 17
5.6.1. Using only Interface attached to the Home Link . . . . 19 5.5.2. Using only Interface attached to the Visited Link . . 17
5.6.2. Using only Interface attached to the Visited Link . . 19 5.6. Returning Home: Simultaneous Home and Visited Link
5.6.3. Simultaneous Home and Visited Link Operation . . . . . 19 Operation . . . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24 5.6.1. Problems of Simultaneous Home and Foreign
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25 Attachments . . . . . . . . . . . . . . . . . . . . . 18
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 25 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 18
5.6.3. Sending Deregistration Binding Update . . . . . . . . 20
5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 20
5.6.5. Sending Packets from the Home Link . . . . . . . . . . 22
5.6.6. Leaving from the Home Link . . . . . . . . . . . . . . 22
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 23
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 24
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 24
6. Home Agent and Correspondent Node Operation . . . . . . . . . 27 6. Home Agent and Correspondent Node Operation . . . . . . . . . 25
6.1. Searching Binding Cache with Binding Identifier . . . . . 27 6.1. Searching Binding Cache with Binding Identifier . . . . . 25
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 27 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 25
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 28 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 28
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 30 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 28
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 30
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 29
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 30
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 30
8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 34 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 31
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 35 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 32
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 35 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 32
9.2. Transport Mode IPsec protected messages . . . . . . . . . 36 9.2. Transport Mode IPsec protected messages . . . . . . . . . 33
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 36 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 33
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 36 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 33
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 37 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41
1. Introduction 1. Introduction
A mobile node may use various types of network interfaces to obtain A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. This is increasingly durable and wide area network connectivity. This is increasingly
become true with mobile nodes having multiple interfaces such as become true with mobile nodes having multiple interfaces such as
802.2, 802.11, 802.16, cellular radios, etc.. The motivations for 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for
and benefits of using multiple points of attachment are discussed in and benefits of using multiple points of attachment are discussed in
[ID-MOTIVATION]. When a mobile node with multiple interfaces uses [ID-MOTIVATION]. When a mobile node with multiple interfaces uses
Mobile IPv6 [RFC-3775] for mobility management, it cannot use its Mobile IPv6 [RFC-3775] for mobility management, it cannot use its
skipping to change at page 6, line 20 skipping to change at page 5, line 20
Terms used in this draft are defined in [RFC-3775], [RFC-3753] and Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
[RFC-4885]. In addition or in replacement of these, the following [RFC-4885]. In addition or in replacement of these, the following
terms are defined or redefined: terms are defined or redefined:
Binding Identification number (BID) Binding Identification number (BID)
The BID is an identification number used to distinguish multiple The BID is an identification number used to distinguish multiple
bindings registered by the mobile node. Assignment of distinct bindings registered by the mobile node. Assignment of distinct
BIDs allows a mobile node to register multiple binding cache BIDs allows a mobile node to register multiple binding cache
entries for a given home address. The BID MUST be unique for a entries for a given home address. The BIDs assigned to a same
binding to a specific care-of address for a given home address and home address MUST NOT be duplicated at a time. Zero and negative
care-of address pair. Zero and negative values MUST NOT be used. values MUST NOT be used. Each BID is generated and managed by a
Each BID is generated and managed by a mobile node. The BID is mobile node. The BID is stored in the Binding Update List and is
stored in the Binding Update List and is sent by the mobile node sent by the mobile node in the Binding Update. A mobile node MAY
in the Binding Update. A mobile node MAY change the value of a change the value of a BID at any time according to its
BID at any time according to its administrative policy, for administrative policy, for instance to protect its privacy. An
instance to protect its privacy. An implementation must carefully implementation must carefully assign the BID so as to keep using
assign the BID so as to keep using the same BID for the same the same BID for the same binding even when the status of the
binding even when the status of the binding is changed. More binding is changed. More details can be found in Section 5.1.
details can be found in Section 5.1.
Binding Identifier Mobility Option Binding Identifier Mobility Option
The Binding Identifier mobility option is used to carry the BID The Binding Identifier mobility option is used to carry the BID
information. information.
Bulk Registration Bulk Registration
A mobile node can register multiple bindings at once by sending a A mobile node can register multiple bindings at once by sending a
single Binding Update. A mobile node can also replace some or all single Binding Update. A mobile node can also replace some or all
the bindings available at the home agent with the new bindings by the bindings available at the home agent with the new bindings by
using the bulk registration. Bulk registration is supported only using the bulk registration. Bulk registration is supported only
for home registration (i.e. with the home agent) as explained in for home registration (i.e. with the home agent) as explained in
Section 5.4. A mobile node MUST NOT perform bulk registration Section 5.3. A mobile node MUST NOT perform bulk registration
mechanism described in this specification with a correspondent mechanism described in this specification with a correspondent
node. node.
3. Protocol Overview 3. Protocol Overview
A new extension called the Binding identification number (BID) is A new extension called the Binding identification number (BID) is
introduced to distinguish between multiple bindings pertaining to the introduced to distinguish between multiple bindings pertaining to the
same home address. If a mobile node configures several IPv6 global same home address. If a mobile node configures several IPv6 global
addresses on one or more of its interfaces, it can register these addresses on one or more of its interfaces, it can register these
addresses with its home agent as care-of addresses. If the mobile addresses with its home agent as care-of addresses. If the mobile
skipping to change at page 7, line 30 skipping to change at page 6, line 30
mobility option to the corresponding field in the binding cache mobility option to the corresponding field in the binding cache
entry. If there is an existing binding cache entry for the mobile entry. If there is an existing binding cache entry for the mobile
node, and if the BID in the Binding Update does not match the one node, and if the BID in the Binding Update does not match the one
with the existing entry, the home agent MUST create a new binding with the existing entry, the home agent MUST create a new binding
cache entry for the new care-of address and BID. The mobile node can cache entry for the new care-of address and BID. The mobile node can
register multiple care-of addresses either independently in register multiple care-of addresses either independently in
individual Binding Updates or multiple at once in a single Binding individual Binding Updates or multiple at once in a single Binding
Update. Update.
If the mobile host wishes to register its binding with a If the mobile host wishes to register its binding with a
correspondent node, it must perform return routability operations. correspondent node, it must perform return routability operations as
This includes managing a Care-of Keygen token per care-of address and described in [RFC-3775]. This includes managing a Care-of Keygen
exchanging CoTi and CoT message with the correspondent node for each token per care-of address and exchanging CoTi and CoT message with
care-of address. The mobile node MAY use the same BID that it used the correspondent node for each care-of address. The mobile node MAY
with the home agent for a particular care-of address. For protocol use the same BID that it used with the home agent for a particular
simplicity, bulk registration to correspondent nodes is not supported care-of address. For protocol simplicity, bulk registration to
in this document. This is because the Return Routability mechanism correspondent nodes is not supported in this document. This is
introduced in [RFC-3775] cannot be easily extended to verify multiple because the Return Routability mechanism introduced in [RFC-3775]
care-of addresses stored in a single Binding Update. cannot be easily extended to verify multiple care-of addresses stored
in a single Binding Update.
Figure 1 illustrates the configuration where the mobile node obtains Figure 1 illustrates the configuration where the mobile node obtains
multiple care-of addresses at foreign links. The mobile node can multiple care-of addresses at foreign links. The mobile node can
utilize all the care-of addresses. In Figure 1, the home address of utilize all the care-of addresses. In Figure 1, the home address of
the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
different interfaces and possibly acquires care-of addresses 1-3 different interfaces and possibly acquires care-of addresses 1-3
(CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to
each care-of address. each care-of address.
+----+ +----+
skipping to change at page 9, line 4 skipping to change at page 8, line 4
data packets. For the protocol signaling such as a binding update, data packets. For the protocol signaling such as a binding update,
BID should be always carried by a BID sub-option in a protocol BID should be always carried by a BID sub-option in a protocol
signaling. Therefore, a correspondent binding cache that matches the signaling. Therefore, a correspondent binding cache that matches the
specified BID MUST be found from the binding cache database. On the specified BID MUST be found from the binding cache database. On the
other hand, for the data packets, no BID information is carried in a other hand, for the data packets, no BID information is carried in a
packet. The binding cache lookup may involve policy or flow filters packet. The binding cache lookup may involve policy or flow filters
to retrieve a correspondent BID per packet in cases where some policy to retrieve a correspondent BID per packet in cases where some policy
or flow filters are used to direct a certain packet or flow to a or flow filters are used to direct a certain packet or flow to a
particular care-of address. However, the binding cache lookup using particular care-of address. However, the binding cache lookup using
policy or flow filters is out of scope for this document. If no such policy or flow filters is out of scope for this document. If no such
mechanism is available and no BID is found for a packet, a node can mechanism is available and no BID is found for a packet, a node
lookup based on only the home address. It uses the first matched SHOULD use the binding which was last verified by receiving data
binding or a binding in a round robin fashion. This is packets or signaling from the mobile node. In case the binding cache
implementation dependent and configurable on a node. In case the lookup for data packets, using the combination of home address and
binding cache lookup for data packets, using the combination of home BID, does not return a valid binding cache entry, the home agent
address and BID, does not return a valid binding cache entry, the SHOULD perform the lookup based on only the home address as described
home agent MAY perform another lookup based on only the home address. in [RFC-3775].
The mobile node may return to the home link through one of its The mobile node may return to the home link through one of its
interfaces. There are two options possible for the mobile node when interfaces. There are two options possible for the mobile node when
its returns home. Section 5.6 describes the returning home its returns home. Section 5.6 and Section 5.5.1 describe the
procedures in more detail. returning home procedures in more detail.
1. The mobile node uses only the interface with which it attaches to 1. The mobile node uses only the interface with which it attaches to
the home link. This is illustrated in Figure 2. It de-registers the home link. This is illustrated in Figure 2. It de-registers
all bindings with the home agent related to all care-of all bindings with the home agent related to all care-of
addresses. The interfaces still attached to the visited link(s) addresses. The interfaces still attached to the visited link(s)
are no longer going to be receiving any encapsulated traffic from are no longer going to be receiving any encapsulated traffic from
the home agent. On the other hand, the mobile node can continue the home agent. On the other hand, the mobile node can continue
communicating with the correspondent node from the other communicating with the correspondent node from the other
interfaces attached to foreign links by using route optimization. interfaces attached to foreign links by using route optimization.
Even if the mobile node is attached to the home link, it can Even if the mobile node is attached to the home link, it can
skipping to change at page 10, line 12 skipping to change at page 9, line 12
binding [2001:db8::EUI care-of address1 BID1] binding [2001:db8::EUI care-of address1 BID1]
binding [2001:db8::EUI care-of address2 BID2] binding [2001:db8::EUI care-of address2 BID2]
Figure 2: Using only Interface Attached to Home Link Figure 2: Using only Interface Attached to Home Link
2. The mobile node may simultaneously use both the interface 2. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to attached to the home link and the interfaces still attached to
the visited link(s) as shown in Figure 3. There are two possible the visited link(s) as shown in Figure 3. There are two possible
topologies depending on whether the home agent is only router on topologies depending on whether the home agent is only router on
the home link or not. The operation of Neighbor Discovery [RFC- the home link or not. The operation of Neighbor Discovery [RFC-
4861] is different in the two topologies. More details can be 4861] is different in the two topologies. More details can be
found in Section 5.6.3. The home agent and the correspondent found in Section 5.6. The home agent and the correspondent node
node have the binding entries listed in Figure 3 in their binding have the binding entries listed in Figure 3 in their binding
cache database in both topologies. The home agent also knows cache database in both topologies. The home agent also knows
that the mobile node is attached to the home link. All the that the mobile node is attached to the home link. All the
traffic from the Internet is intercepted by the home agent first traffic from the Internet is intercepted by the home agent first
and routed to either the interface attached to the home link or and routed to either the interface attached to the home link or
the one of the foreign links. How the home agent decides to the one of the foreign links. How the home agent decides to
route a particular flow to the interface attached to the home route a particular flow to the interface attached to the home
link or foreign link is out of scope in this document. link or foreign link is out of scope in this document.
Topology-a) Topology-a)
+----+ +----+
skipping to change at page 12, line 15 skipping to change at page 11, line 15
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
This section summarizes the extensions to Mobile IPv6 necessary for This section summarizes the extensions to Mobile IPv6 necessary for
manage multiple bindings. manage multiple bindings.
4.1. Binding Cache Structure and Binding Update List 4.1. Binding Cache Structure and Binding Update List
The BID is required to be stored in the binding cache and binding The BID is required to be stored in the binding cache and binding
update list structure. update list structure.
The sequence number value SHOULD be shared among all the binding The sequence number value MUST be shared among all the binding update
update list entries related to binding updates sent to a particular list entries related to binding updates sent to a particular home
home agent or correspondent node. Whenever a mobile node sends agent or correspondent node. Whenever a mobile node sends either
either individual or bulk binding update, the sequence number is individual or bulk binding update, the sequence number is
incremented. On the other hand, if a mobile node manages an incremented. When a home agent receives an individual BU, it should
individual sequence value per binding update list, a mobile node update the sequence number for all the bindings for a particular
SHOULD carefully select the sequence number value for the bulk mobile node with the sequence number in the received BU.
binding update. This is because all the bulk-registered bindings use
the same Sequence Number specified in the Binding Update. If each
binding uses different sequence number, a mobile node MUST use the
largest sequence number from the Binding Update list entries used for
the bulk registration. If the mobile node cannot select a sequence
number for all the bindings due to sequence number out of window, it
MUST NOT use the bulk registration for the binding whose sequence
number is out of window. A separate Binding Update should be sent
for the binding.
4.2. Binding Identifier Mobility Option 4.2. Binding Identifier Mobility Option
The Binding Identifier mobility option is included in the Binding The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
Test Init and Care-of Test message. The Binding Identifier Mobility Test Init and Care-of Test message. The Binding Identifier Mobility
Option has an alignment requirement of 2n if the Care-of Address Option has an alignment requirement of 2n if the Care-of Address
field is not present. Otherwise, it has the alignment requirement of field is not present. Otherwise, it has the alignment requirement of
8n + 2. 8n + 2.
skipping to change at page 13, line 32 skipping to change at page 12, line 26
The BID which is assigned to the binding indicated by the care-of The BID which is assigned to the binding indicated by the care-of
address in the Binding Update or the BID mobility option. The BID address in the Binding Update or the BID mobility option. The BID
is a 16-bit unsigned integer. The value of zero is reserved and is a 16-bit unsigned integer. The value of zero is reserved and
MUST NOT be used. MUST NOT be used.
Status Status
The Status field is an 8-bit unsigned integer. When the Binding The Status field is an 8-bit unsigned integer. When the Binding
Identifier mobility option is included in a Binding Identifier mobility option is included in a Binding
Acknowledgement, this field overwrites the status field in the Acknowledgement, this field overwrites the status field in the
Binding Acknowledgement. If this field is set to zero, the Binding Acknowledgement only for this BID. If this field is set
receiver ignores this field and uses the registration status to zero, the receiver ignores this field and uses the registration
stored in the Binding Acknowledgement message. The receiver MUST status stored in the Binding Acknowledgement message. The
ignore this field if the Binding Identifier mobility option is not receiver MUST ignore this field if the Binding Identifier mobility
carried within either the Binding Acknowledgement or the Care-of option is not carried within either the Binding Acknowledgement or
Test messages. The possible status codes are the same as the the Care-of Test messages. The possible status codes are the same
status codes of Binding Acknowledgement. This Status field is as the status codes of Binding Acknowledgement. This Status field
also used to carry error information related to the care-of is also used to carry error information related to the care-of
address test in the Care-of Test message. address test in the Care-of Test message.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, all the binding cache entries for a mobile When this flag is set, all the binding cache entries for a mobile
node are replaced by new entries registering with this binding node are replaced by new entries registering with this binding
update message. update message. This flag is only used when BID Mobility Option
is carried with Binding Update.
Simultaneous Home and Foreign Binding (H) flag Simultaneous Home and Foreign Binding (H) flag
This flag indicates that the mobile node registers multiple This flag indicates that the mobile node registers multiple
bindings to the home agent while is attached to the home link. bindings to the home agent while is attached to the home link.
This flag is valid only for a Binding Update sent to the home This flag is valid only for a Binding Update sent to the home
agent. agent.
Reserved Reserved
5 bits Reserved field. The value MUST be initialized to zero by 5 bits Reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver. the sender, and MUST be ignored by the receiver.
skipping to change at page 14, line 20 skipping to change at page 13, line 16
5 bits Reserved field. The value MUST be initialized to zero by 5 bits Reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver. the sender, and MUST be ignored by the receiver.
Care-of Address Care-of Address
If a Binding Identifier mobility option is included in a Binding If a Binding Identifier mobility option is included in a Binding
Update, either IPv4 or IPv6 care-of address for the corresponding Update, either IPv4 or IPv6 care-of address for the corresponding
BID can be stored in this field. If no address is specified in BID can be stored in this field. If no address is specified in
this field, the length of this field MUST be zero (i.e. not this field, the length of this field MUST be zero (i.e. not
appeared in the option). If the option is included in any other appeared in the option). If no address is specified in this
messages than a Binding Update, the length of this field MUST be field, a care-of address is taken from the source address of the
also zero. IPv6 header. If the option is included in any other messages than
a Binding Update, the length of this field MUST be also zero.
4.3. New Status Values for Binding Acknowledgement 4.3. New Status Values for Binding Acknowledgement
New status values for the status field in a Binding Acknowledgement New status values for the status field in a Binding Acknowledgement
are defined for handling the multiple Care-of Addresses registration: are defined for handling the multiple Care-of Addresses registration:
MCOA NOTCOMPLETE (TBD less than 128) MCOA NOTCOMPLETE (TBD less than 128)
In bulk registration, not all the binding identifier mobility In bulk registration, not all the binding identifier mobility
option are successfully registered. Some of them are rejected. option are successfully registered. Some of them are rejected.
skipping to change at page 15, line 14 skipping to change at page 14, line 10
The home agent cannot cache both a regular binding and a BID The home agent cannot cache both a regular binding and a BID
extended binding simultaneously. It returns this status value extended binding simultaneously. It returns this status value
when the received binding conflicts with the existing binding when the received binding conflicts with the existing binding
cache entry(ies). cache entry(ies).
MCOA PROHIBITED(TBD more than 128) MCOA PROHIBITED(TBD more than 128)
It implies the multiple care-of address registration is It implies the multiple care-of address registration is
administratively prohibited. administratively prohibited.
MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) MCOA BULK REGISTRATION PROHIBITED(TBD more than 128)
Bulk binding registration is not supported. Note that the bulk Bulk binding registration is not either permitted or supported.
registration is optional procedure and might not be available on a Note that the bulk registration is optional procedure and might
home agent. not be available on a home agent.
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128)
Simultaneous home and foreign attachment is neither supported nor
permitted.
5. Mobile Node Operation 5. Mobile Node Operation
5.1. Management of Care-of Address(es) and Binding Identifier(s) 5.1. Management of Care-of Address(es) and Binding Identifier(s)
There are two cases when a mobile node might acquire several care-of There are two cases when a mobile node might acquire several care-of
addresses. Note that a mixture of the two cases is also possible. addresses. A mixture of the two cases is also possible. Note that a
mobile node can use BID regardless of the number of interfaces and
care-of addresses. Whether a mobile node uses BID or not is
determined by a local configuration.
1. A mobile node may be using several physical network interfaces 1. A mobile node may be using several physical network interfaces
and acquires a care-of address on each of its interfaces. and acquires a care-of address on each of its interfaces.
2. A mobile node uses a single physical network interface, but 2. A mobile node uses a single physical network interface, but
receives advertisements for multiple prefixes on the link the receives advertisements for multiple prefixes on the link the
interface is attached to. This will result in the mobile node interface is attached to. This will result in the mobile node
configuring several global addresses on the interface from each configuring several global addresses on the interface from each
of the announced prefixes. of the announced prefixes.
skipping to change at page 16, line 35 skipping to change at page 15, line 38
A mobile node assigns a BID to each care-of address when it wants to A mobile node assigns a BID to each care-of address when it wants to
register them simultaneously with its home address. The BID MUST be register them simultaneously with its home address. The BID MUST be
unique for a given home address and care-of address pair. The value unique for a given home address and care-of address pair. The value
should be an integer between 1 and 65535. Zero value MUST NOT be should be an integer between 1 and 65535. Zero value MUST NOT be
used as BIDs. If a mobile node has only one care-of address, the used as BIDs. If a mobile node has only one care-of address, the
assignment of a BID is not needed until it has multiple care-of assignment of a BID is not needed until it has multiple care-of
addresses to register with, at which time all of the care-of addresses to register with, at which time all of the care-of
addresses MUST be mapped to BIDs. addresses MUST be mapped to BIDs.
5.2. Return Routability: Sending CoTI and Receiving CoT 5.2. Binding Registration
When a mobile node wants to register multiple care-of address with a
correspondent node, it MUST have the valid Care-of Keygen token per
care-of address. The mobile node needs only one Home Keygen token
for its home address.
The mobile node MUST include a Binding Identifier mobility option in
the Care-of Test Init message. It MUST NOT set any flags in the
mobility option. The receiver (i.e. correspondent node) will
calculate a care-of Keygen token as specified in [RFC-3775] and reply
with a Care-of Test message, with the Binding Identifier mobility
option as described in Section 6.2. When the mobile node receives
the Care-of Test message, the message is verified as in [RFC-3775].
If a Binding Identifier mobility option is not present in the CoT
message in reply to the CoTI message that included a Binding
Identifier mobility option, the mobile node must assume that the
correspondent node does not support Multiple Care-of Address
registration. Thus, the mobile node MUST NOT use a Binding
Identifier mobility option in any future Binding Updates to that
correspondent node. The mobile node MAY skip re-sending regular CoTI
message and keep the received care-of Keygen token for the regular
Binding Update.
5.3. Binding Registration
For the multiple Care-of Addresses registration, the mobile node MUST For the multiple Care-of Addresses registration, the mobile node MUST
include a Binding Identifier mobility option(s) in the Binding Update include a Binding Identifier mobility option(s) in the Binding Update
as shown in Figure 5. The BID is copied from a corresponding Binding as shown in Figure 5. The BID is copied from a corresponding Binding
Update List entry to the BID field of the Binding Identifier mobility Update List entry to the BID field of the Binding Identifier mobility
option. When IPsec ESP is used for protecting the Binding Update, option. When IPsec ESP is used for protecting the Binding Update,
the care-of address can be carried in the Care-of Address field of the care-of address can be carried in the Care-of Address field of
the Binding Identifier mobility option. If this is done, the the Binding Identifier mobility option. If this is done, the
alternate care-of address option MUST NOT be included in the Binding alternate care-of address option MUST NOT be included in the Binding
Update. For binding registration to a correspondent node, the mobile Update. For binding registration to a correspondent node, the mobile
skipping to change at page 17, line 42 skipping to change at page 16, line 22
Mobility header Mobility header
Binding Update Binding Update
Mobility Options Mobility Options
Binding Identifier mobility option Binding Identifier mobility option
Binding Authorization mobility option+ Binding Authorization mobility option+
(*) if necessary, for home registration (*) if necessary, for home registration
(+) if necessary, for route optimization (+) if necessary, for route optimization
Figure 5: Binding Update for Binding Registration Figure 5: Binding Update for Binding Registration
5.4. Bulk Registration If the mobile node wants to replace existing registered bindings on
the home agent with the single binding in the sent Binding Update, it
sets the 'O' flag. Section 6.2 describes this registration procedure
in detail.
5.3. Bulk Registration
Bulk registration is an optimization for binding multiple care-of Bulk registration is an optimization for binding multiple care-of
addresses to a home address using a single Binding Update. This is addresses to a home address using a single Binding Update. This is
very useful if the mobile node, for instance, does not want to send a very useful if the mobile node, for instance, does not want to send a
lot of signaling messages through an interface where the bandwidth is lot of signaling messages through an interface where the bandwidth is
scarce. This document specifies bulk registration only for the scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk mobile node's home registration. A mobile node performing bulk
registration with a correspondent node is out of scope. registration with a correspondent node is out of scope.
To use bulk registration, the mobile node includes a Binding To use bulk registration, the mobile node includes a Binding
skipping to change at page 18, line 20 skipping to change at page 17, line 4
Binding Update are common across all care-of addresses. The Binding Update are common across all care-of addresses. The
alternate care-of address option MUST NOT be used. alternate care-of address option MUST NOT be used.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header ESP Header
Mobility header Mobility header
Binding Update Binding Update
Mobility Options Mobility Options
Binding Identifier mobility options (CoA) Binding Identifier mobility options (CoA)
Figure 6: Binding Update for Bulk Registration Figure 6: Binding Update for Bulk Registration
If the mobile node wants to replace existing registered bindings on If the mobile node wants to replace existing registered bindings on
the home agent with the bindings in the sent Binding Update, it sets the home agent with the multiple bindings in the sent Binding Update,
the 'O' flag. Section 6.3 describes this registration procedure in it sets the 'O' flag.
detail.
5.5. Binding De-Registration 5.4. Binding De-Registration
When a mobile node decides to delete all the bindings for its home When a mobile node decides to delete all the bindings for its home
address, it sends a regular de-registration Binding Update with address, it sends a regular de-registration Binding Update with
lifetime set to zero as defined in [RFC-3775]. The Binding lifetime set to zero as defined in [RFC-3775]. The Binding
Identifier mobility option is not required. Identifier mobility option is not required.
If a mobile node wants to delete a particular binding(s) from its If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes, the mobile node sends a Binding home agent and correspondent nodes, the mobile node sends a Binding
Update with lifetime set to zero and includes a Binding Identifier Update with lifetime set to zero and includes a Binding Identifier
mobility option(s) with the BID(s) it wants to de-register. The mobility option(s) with the BID(s) it wants to de-register. The
receiver will remove only the care-of address(es) that match(es) the receiver will remove only the care-of address(es) that match(es) the
specified BID(s). The care-of addresses field in each mobility specified BID(s). The care-of addresses field in each mobility
option SHOULD be omitted by the sender (i.e. the field does not option SHOULD be omitted by the sender (i.e. the field does not
appear in the option) and MUST be ignored by the receiver. This is appear in the option) and MUST be ignored by the receiver. This is
because the receiver will remove the binding that matches the because the receiver will remove the binding that matches the
specified BID. specified BID.
5.6. Returning Home 5.5. Returning Home: Using Single Interface
The mobile node may return to the home link, by attaching to the home The mobile node may return to the home link, by attaching to the home
link through one of its interfaces. When the mobile node wants to link through one of its interfaces. When the mobile node wants to
return home, it should be configured with information on what return home, it should be configured with information on what
interface it needs to use. The mobile node may use only the interface it needs to use.
interface with which it is attached to the home link, only the
interfaces still attached to the visited link(s) or use both
interfaces attached to the home link and visited link(s)
simultaneously. The following describes each option in more detail.
5.6.1. Using only Interface attached to the Home Link 5.5.1. Using only Interface attached to the Home Link
The mobile node returns home and de-registers all the bindings as The mobile node returns home and de-registers all the bindings as
shown in Figure 2 and as defined in [RFC-3775]. De-registering all shown in Figure 2 and as defined in [RFC-3775]. De-registering all
the bindings is the same as binding de-registration from foreign link the bindings is the same as binding de-registration from foreign link
described in Section 5.5. After the de-registration step, all the described in Section 5.4. After the de-registration step, all the
packets routed by the home agent are only forwarded to the interface packets routed by the home agent are only forwarded to the interface
attached to the home link, even if there are other active interfaces attached to the home link, even if there are other active interfaces
attached to the visited link(s). While the mobile node de-registers attached to the visited link(s). While the mobile node de-registers
all the bindings from the home agent, it may continue registering all the bindings from the home agent, it may continue registering
bindings for interface(s) attached to visited link(s) to the bindings for interface(s) attached to visited link(s) to the
correspondent node as shown in Figure 2. correspondent node as shown in Figure 2.
5.6.2. Using only Interface attached to the Visited Link 5.5.2. Using only Interface attached to the Visited Link
The mobile node returns home in physically and shuts down the The mobile node returns home in physically and shuts down the
interface attached to the home link. As a result, a mobile node does interface attached to the home link. As a result, a mobile node does
not return home even though it attaches to the home link by one of not return home even though it attaches to the home link by one of
interfaces. Following procedures should be taken by the mobile node. interfaces. Following procedures should be taken by the mobile node.
Before shutting down the interface, any binding for the care-of Before shutting down the interface, any binding for the care-of
address previously associated with the interface should be deleted. address previously associated with the interface should be deleted.
To delete the binding cache entry, the mobile node SHOULD send a de- To delete the binding cache entry, the mobile node SHOULD send a de-
registration Binding Update with the lifetime set to zero and include registration Binding Update with the lifetime set to zero and include
the corresponding BID information. If the mobile node does not send the corresponding BID information. If the mobile node does not send
a de-registration Binding Update, the binding for the care-of address a de-registration Binding Update, the binding for the care-of address
previously assigned to the interface remains at the home agent until previously assigned to the interface remains at the home agent until
its lifetime expires. its lifetime expires.
In this scenario, despite the fact that the mobile node is connected In this scenario, despite the fact that the mobile node is connected
to its home link, all of its traffic is sent and received via the to its home link, all of its traffic is sent and received via the
home agent and its foreign links. home agent and its foreign links.
5.6.3. Simultaneous Home and Visited Link Operation 5.6. Returning Home: Simultaneous Home and Visited Link Operation
[Problems of Simultaneous Home and Foreign Attachments] 5.6.1. Problems of Simultaneous Home and Foreign Attachments
The mobile node returns home and continues using all the interfaces The mobile node returns home and continues using all the interfaces
attached to both foreign and home links as shown in Figure 3. The attached to both foreign and home links as shown in Figure 3. The
mobile node indicates this by setting the 'H' flag in the BID mobile node indicates this by setting the 'H' flag in the BID
mobility option as defined below. There are additional requirements mobility option as defined below. There are additional requirements
on the Returning Home procedures for possible Neighbor Discovery on the Returning Home procedures for possible Neighbor Discovery
states conflicts at the home link. states conflicts at the home link.
In [RFC-3775], the home agent intercepts packets meant for the mobile In [RFC-3775], the home agent intercepts packets meant for the mobile
node using the Proxy Neighbor Discovery [RFC-4861] while the mobile node using the Proxy Neighbor Discovery [RFC-4861] while the mobile
skipping to change at page 20, line 23 skipping to change at page 18, line 48
attached to the foreign links. In this case, a possible conflict attached to the foreign links. In this case, a possible conflict
arises when the both the home agent and the mobile node try to defend arises when the both the home agent and the mobile node try to defend
the home address. If the home agent stops proxying for the home the home address. If the home agent stops proxying for the home
address, the packets are always routed to the interface attached to address, the packets are always routed to the interface attached to
the home link and are never routed to the interfaces attached to the the home link and are never routed to the interfaces attached to the
visited links. It is required to avoid the conflict between the home visited links. It is required to avoid the conflict between the home
agent and the mobile node, while still allowing the simultaneous use agent and the mobile node, while still allowing the simultaneous use
of home and foreign links. The following describes the mechanism for of home and foreign links. The following describes the mechanism for
achieving this. achieving this.
[Overview and Approach] 5.6.2. Overview and Approach
In this specification, the home agent MUST intercept all the packets In this specification, the home agent MUST intercept all the packets
meant for the mobile node and decide whether to send the traffic meant for the mobile node and decide whether to send the traffic
directly to the home address on the link or tunnel to the care-of directly to the home address on the link or tunnel to the care-of
address. The home agent intercepts all the packets even when the address. The home agent intercepts all the packets even when the
mobile node is attached to the home link through one of its mobile node is attached to the home link through one of its
interfaces. The home agent would make this decision based on the interfaces. The home agent would make this decision based on the
type of flow. How to make this decision is out of scope in this type of flow. How to make this decision is out of scope in this
document. document.
skipping to change at page 20, line 45 skipping to change at page 19, line 22
Home Agent is the only router at the home link or not. The Home Agent is the only router at the home link or not. The
difference is on who defends the home address by (Proxy) Neighbor difference is on who defends the home address by (Proxy) Neighbor
Discovery on the home link. Discovery on the home link.
1. Mobile node defends the home address by the regular Neighbor 1. Mobile node defends the home address by the regular Neighbor
Discovery Protocol (illustrated as topology-a in Figure 3). The Discovery Protocol (illustrated as topology-a in Figure 3). The
home agent is the only router on the home link. Therefore the home agent is the only router on the home link. Therefore the
home agent is capable of intercepting packets without relying on home agent is capable of intercepting packets without relying on
the proxy Neighbor Discovery protocol and the mobile node can the proxy Neighbor Discovery protocol and the mobile node can
manage the Neighbor Cache entry of the home address on the home manage the Neighbor Cache entry of the home address on the home
link as a regular IPv6 node. link as a regular IPv6 node. However, there is one
limitation of this scenario. If a correspondent node is located
at the home link, the home agent may not intercept the packets
destined to the mobile node. These packets are routed only via
the home link, but this is most optimized path for the mobile
node to communicate with nodes on the home link.
2. If there are other routers on the home link apart from the home 2. If there are other routers on the home link apart from the home
agent, then it cannot be guaranteed that all packets meant for agent, then it cannot be guaranteed that all packets meant for
the mobile node are routed to the home agent. In this case, the the mobile node are routed to the home agent. In this case, the
mobile node MUST NOT operate Neighbor Discovery protocol for the mobile node MUST NOT operate Neighbor Discovery protocol for the
home address on the home link. This allows the home agent to home address on the home link. This allows the home agent to
keep using proxy neighbor discovery and thus it keeps receiving keep using proxy neighbor discovery and thus it keeps receiving
all the packets sent to the mobile node's home address. If the all the packets sent to the mobile node's home address. If the
home agent, according to its local policy, needs to deliver home agent, according to its local policy, needs to deliver
packets to the mobile node over the home link, an issue arises packets to the mobile node over the home link, an issue arises
skipping to change at page 21, line 22 skipping to change at page 20, line 5
mobile node would also know the link-layer address of the default mobile node would also know the link-layer address of the default
router address to send packets from the home link without router address to send packets from the home link without
Neighbor Discovery. The link-layer address is used to transmit Neighbor Discovery. The link-layer address is used to transmit
packets from and to the mobile node on the home link. The packets from and to the mobile node on the home link. The
packets are transmitted without the Neighbor Discovery protocol packets are transmitted without the Neighbor Discovery protocol
by constructing the link-layer header manually. This operation by constructing the link-layer header manually. This operation
is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a
deregistration binding update to the home agent's link-layer deregistration binding update to the home agent's link-layer
address in returning home operation. address in returning home operation.
[Sending Deregistration Binding Update] 5.6.3. Sending Deregistration Binding Update
o As soon as a mobile node returns home, it sends a de-registration o As soon as a mobile node returns home, it sends a de-registration
Binding Update to the home agent from the interface attached to Binding Update to the home agent from the interface attached to
the home link. the home link.
o The mobile node MUST include the BID mobility option specifying o The mobile node MUST include the BID mobility option specifying
the BID the mobile node had previously associated with the the BID the mobile node had previously associated with the
interface attached to the home link. The 'H' flag MUST be set in interface attached to the home link. The 'H' flag MUST be set in
the BID mobility option. None of the care-of address MUST be sent the BID mobility option. For the binding deregistration, a mobile
in the Care-of Address field of the BID mobility option. When the node SHOULD NOT store a care-of address in the Care-of Address
'H' flag is set, the home agent recognizes that the mobile node field of the BID mobility option. The receive, the home agent,
wants to continue using interfaces attached to both home and can match the removed binding with BID value in the BID mobility
visited links. Note that H flag MUST be set for all the binding option. If the mobile node has to remove multiple bindings
updates sent from the mobile node (ex. Binding Update for the simultaneously, it contains multiple BID mobility options with O
interface(s) attached to the foreign link(s)). flag set. When the 'H' flag is set, the home agent recognizes
that the mobile node wants to continue using interfaces attached
to both home and visited links. Note that H flag MUST be set for
all the binding updates sent from the mobile node (ex. Binding
Update for the interface(s) attached to the foreign link(s)). If
the home agent does not allow this scenario, it MUST send a
Binding Acknowledgement with the status code [MCOA SIMULTANEOUS
HOME AND FOREIGN PROHIBITED] set.
o The mobile node SHOULD include the Link-layer Address (LLA) Option o The mobile node SHOULD include the Link-layer Address (LLA) Option
[RFC-5268] to notify the mobile node's link-layer address to the [RFC-5268] to notify the mobile node's link-layer address to the
home agent, too. The option code of the Link-layer Address (LLA) home agent, too. The option code of the Link-layer Address (LLA)
option MUST be set to '2' (Link-layer Address of the mobile node). option MUST be set to '2' (Link-layer Address of the mobile node).
This link-layer address is required for the home agent to send the This link-layer address is required for the home agent to send the
Binding Acknowledgement and to forward the mobile node's packet. Binding Acknowledgement and to forward the mobile node's packet.
o According to [RFC-3775], the mobile node MUST start responding to o According to [RFC-3775], the mobile node MUST start responding to
Neighbor Solicitation for its home address right after it sends Neighbor Solicitation for its home address right after it sends
the deregistration Binding Update to the home agent. However, in the deregistration Binding Update to the home agent. However, in
this specification, the mobile node MUST NOT respond to Neighbor this specification, the mobile node MUST NOT respond to Neighbor
Solicitation before receiving a Binding Acknowledgement, since the Solicitation before receiving a Binding Acknowledgement, since the
home agent may continue proxying for the home address. If the home agent may continue proxying for the home address. If the
mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
in the received Binding Acknowledgment, it MUST NOT respond to in the received Binding Acknowledgment, it MUST NOT respond to
Neighbor Solicitation even after the Binding Acknowledgement. Neighbor Solicitation even after the Binding Acknowledgement.
[Sending Binding Acknowledgement] 5.6.4. Sending Binding Acknowledgement
o When the home agent sends the Binding Acknowledgement after o When the home agent sends the Binding Acknowledgement after
successfully processing the binding de-registration, it MUST set successfully processing the binding de-registration, it MUST set
the status value to either 0 [Binding Update Accepted] or to [MCOA the status value to either 0 [Binding Update Accepted] or to [MCOA
RETURNHOME WO/NDP (TBD)] in the Status field of the Binding RETURNHOME WO/NDP (TBD)] in the Status field of the Binding
Acknowledgment depending on home agent configuration at the home Acknowledgment depending on home agent configuration at the home
link. The new values are: link. The new values are:
* Binding Update Accepted (0): NDP is permitted for the home * Binding Update Accepted (0): NDP is permitted for the home
address at the home link. This is regular returning home address at the home link. This is regular returning home
skipping to change at page 23, line 21 skipping to change at page 22, line 6
o If BID option is not included in the Binding Acknowledgement, the o If BID option is not included in the Binding Acknowledgement, the
home agent might not recognize the simultaneous home and foreign home agent might not recognize the simultaneous home and foreign
attachment. The home agent might have processed the de- attachment. The home agent might have processed the de-
registration Binding Update as a regular de-registration as registration Binding Update as a regular de-registration as
described in [RFC-3775] and deletes all the registered binding described in [RFC-3775] and deletes all the registered binding
cache entries for the mobile node. Thus, the mobile node SHOULD cache entries for the mobile node. Thus, the mobile node SHOULD
stop using the interface attached to foreign link and use only the stop using the interface attached to foreign link and use only the
interface attached to the home link. interface attached to the home link.
[Sending Packets from the Home Link] 5.6.5. Sending Packets from the Home Link
o When the mobile node receives the Binding Acknowledgement with the o When the mobile node receives the Binding Acknowledgement with the
status value 'Binding Update Accepted' and the BID option, it can status value 'Binding Update Accepted' and the BID option, it can
configure its home address to the interface attached to the home configure its home address to the interface attached to the home
link and start operating Neighbor Discovery for the home address link and start operating Neighbor Discovery for the home address
on the home link. Packets can be transmitted from and to the on the home link. Packets can be transmitted from and to the
mobile node as if the mobile node is a regular IPv6 node. mobile node as if the mobile node is a regular IPv6 node.
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
the Binding Acknowledgement, it MUST NOT operate Neighbor the Binding Acknowledgement, it MUST NOT operate Neighbor
skipping to change at page 23, line 49 skipping to change at page 22, line 34
constructing the packet including link-layer header with the constructing the packet including link-layer header with the
learned link-layer address of the default router. The home agent learned link-layer address of the default router. The home agent
also forwards the packet to the mobile node on the home link by also forwards the packet to the mobile node on the home link by
using the mobile node's link-layer address. The link-layer using the mobile node's link-layer address. The link-layer
address SHOULD be cached when the home agent received the address SHOULD be cached when the home agent received the
deregistration Binding Update message. Note that the default deregistration Binding Update message. Note that the default
router MUST NOT cache the mobile node's link-layer address as a router MUST NOT cache the mobile node's link-layer address as a
neighbor cache when it forwards the packet from the mobile node to neighbor cache when it forwards the packet from the mobile node to
the home agent. the home agent.
[Leaving from the Home Link] 5.6.6. Leaving from the Home Link
o When the mobile node detaches from the home link, it SHOULD o When the mobile node detaches from the home link, it SHOULD
immediately send a binding update for one of active care-of immediately send a binding update for one of active care-of
address with H flag unset. When the 'H' flag of BID option is address with H flag unset. When the 'H' flag of BID option is
unset in any Binding Update, the home agent stop forwarding the unset in any Binding Update, the home agent stop forwarding the
mobile node's packet to the home link. mobile node's packet to the home link.
o On the other hand, if the mobile node does not have any active 5.6.6.1. Changing Behavior during the attachment to the home link
care-of address to send a Binding Update and leaves the home link
(i.e. the mobile node is completely disconnected), the home agent
continues forwarding packets to the mobile node until the
expiration of all the binding cache entries for the home address.
Once all the bindings are expired, the mobile node is assumed to
be disconnected completely from networks.
[Changing Behavior during the attachment to the home link]
If a mobile node decides to return home completely without any active If a mobile node decides to return home completely without any active
foreign link attachment, it simply sends a deregistration binding foreign link attachment, it simply sends a deregistration binding
update as described in Section 5.6.1. Once the home agent receives update as described in Section 5.5.1. Once the home agent receives
such de-registration binding update, the home agent clears all the such de-registration binding update, the home agent clears all the
binding and states for the mobile node. binding and states for the mobile node.
If a mobile node decides to stop using the interface attached to the If a mobile node decides to stop using the interface attached to the
home link, it simply sends a binding update from the one of active home link, it simply sends a binding update from the one of active
care-of address. In the Binding Update, the mobile node should care-of address. In the Binding Update, the mobile node should
include the BID option for the care-of address and unset the H flag include the BID option for the care-of address and unset the H flag
of BID option. The home agent clears the states of the mobile node of BID option. The home agent clears the states of the mobile node
for the interface attached to the home link and stop forwarding the for the interface attached to the home link and stop forwarding the
packets to the mobile node on the home link. packets to the mobile node on the home link.
5.7. Receiving Binding Acknowledgement 5.7. Receiving Binding Acknowledgement
The verification of a Binding Acknowledgement is the same as Mobile The verification of a Binding Acknowledgement is the same as Mobile
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
Binding Acknowledgement is described in Section 6.3. Binding Acknowledgement is described in Section 6.2.
If a mobile node includes a Binding Identifier mobility option in a If a mobile node includes a Binding Identifier mobility option in a
Binding Update with the 'A' flag set, a Binding Acknowledgement MUST Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
carry a Binding Identifier mobility option. If no such mobility carry a Binding Identifier mobility option. According to [RFC-3775],
option is included in the Binding Acknowledgement in response to a the receiver of the Binding Update ignores unknown mobility options
Binding Update for multiple care-of address registration, this and process the Binding Update without the unknown mobility option.
indicates that the originating node of the Binding Acknowledgement Therefore, if no such mobility option is included in the Binding
does not support processing the Binding Identifier mobility option. Acknowledgement in response to a Binding Update for multiple care-of
The mobile node MUST then stop multiple care-of address registration address registration, this indicates that the originating node of the
with that node. Binding Acknowledgement does not support processing the Binding
Identifier mobility option regardless of status value. In such case,
the receiver of the Binding Update may create a regular binding. The
mobile node then stop multiple care-of address registration with that
node. If it is home registration, the mobile node MAY attempt to
discover another home agent supporting BID mobility option for the
home registration.
If a Binding Identifier mobility option is present in the received If a Binding Identifier mobility option is present in the received
Binding Acknowledgement, the mobile node checks the status field in Binding Acknowledgement, the mobile node checks the status field in
the option. If the status value in the Binding Identifier mobility the option. If the status value in the Binding Identifier mobility
option is zero, the mobile node uses the value in the Status field of option is zero, the mobile node uses the value in the Status field of
the Binding Acknowledgement. Otherwise, it uses the value in the the Binding Acknowledgement. Otherwise, it uses the value in the
Status field of the Binding Identifier mobility option. Status field of the Binding Identifier mobility option.
If the status code is greater than or equal to 128, the mobile node If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise, starts relevant operations according to the error code. Otherwise,
skipping to change at page 25, line 37 skipping to change at page 24, line 18
o If [MCOA BID CONFLICT] is specified, the binding entry specified o If [MCOA BID CONFLICT] is specified, the binding entry specified
by the Binding Identifier mobility option is already registered as by the Binding Identifier mobility option is already registered as
a regular binding. In such case, the mobile node SHOULD stop a regular binding. In such case, the mobile node SHOULD stop
sending Binding Updates with BID, or SHOULD use the 'O' flag to sending Binding Updates with BID, or SHOULD use the 'O' flag to
reset all the registered bindings. reset all the registered bindings.
5.8. Receiving Binding Refresh Request 5.8. Receiving Binding Refresh Request
The verification of a Binding Refresh Request is the same as in The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of sending
a Binding Refresh Request is described in section Section 6.4. a Binding Refresh Request is described in section Section 6.3.
If a mobile node receives a Binding Refresh Request with a Binding If a mobile node receives a Binding Refresh Request with a Binding
Identifier mobility option, it indicates that the node sending the Identifier mobility option, it indicates that the node sending the
Binding Refresh Request message is requesting the mobile node to send Binding Refresh Request message is requesting the mobile node to send
a new Binding Update for the BID. The mobile node SHOULD then send a a new Binding Update for the BID. The mobile node SHOULD then send a
Binding Update only for the respective binding. The mobile node MUST Binding Update at least for the respective binding. The mobile node
include a Binding Identifier mobility option in the Binding Update. MUST include a Binding Identifier mobility option in the Binding
Update.
5.9. Bootstrapping 5.9. Bootstrapping
When a mobile node bootstraps and registers multiple bindings for the When a mobile node bootstraps and registers multiple bindings for the
first time, it MUST set the 'O' flag in the Binding Identifier first time, it MUST set the 'O' flag in the Binding Identifier
mobility option. If old bindings still exists at the home agent, the mobility option. If old bindings still exists at the home agent, the
mobile node has no knowledge of which bindings still exist at the mobile node has no knowledge of which bindings still exist at the
home agent. This scenario happens when a mobile node reboots and home agent. This scenario happens when a mobile node reboots and
looses state regarding the registrations. If the 'O' flag is set, looses state regarding the registrations. If the 'O' flag is set,
all the bindings are replaced by the new binding(s). If the mobile all the bindings are replaced by the new binding(s). If the mobile
node receives the Binding Acknowledgement with the status code set to node receives the Binding Acknowledgement with the status code set to
135 [Sequence number out of window], it MUST retry sending a Binding 135 [Sequence number out of window], it MUST follow the operations
Update with the last accepted sequence number indicated in the described in [RFC-3775].
Binding Acknowledgement.
The 'O' flag can also be used in individual Binding Updates sent to The 'O' flag can also be used in individual Binding Updates sent to
the correspondent nodes to override any existing binding cache the correspondent nodes to override any existing binding cache
entries at the correspondent node. entries at the correspondent node.
6. Home Agent and Correspondent Node Operation 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Identifier 6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
skipping to change at page 27, line 37 skipping to change at page 25, line 37
Figure 7: Searching the Binding Cache Figure 7: Searching the Binding Cache
The node learns the BID when it receives a Binding Identifier The node learns the BID when it receives a Binding Identifier
mobility option. At that time, the node MUST look up its binding mobility option. At that time, the node MUST look up its binding
cache database with the home address and the BID retrieved from the cache database with the home address and the BID retrieved from the
Binding Update. If the node does not know the BID, it searches for a Binding Update. If the node does not know the BID, it searches for a
binding with only the home address. In such a case, the first binding with only the home address. In such a case, the first
matched binding is found. If the node does not desire to use matched binding is found. If the node does not desire to use
multiple bindings for a mobile node, it can simply ignore the BID. multiple bindings for a mobile node, it can simply ignore the BID.
6.2. Receiving CoTI and Sending CoT 6.2. Processing Binding Update
When a correspondent node receives a CoTI message which contains a
Binding Identifier mobility option, it processes it as follows.
First, the CoTI message is verified as specified in [RFC-3775]. The
Binding Identifier mobility option is processed as follows:
o If a correspondent node does not understand a Binding Identifier
mobility option, it just ignores and skips processing the option.
The calculation of a care-of Keygen token will thus be done
without a BID value. The correspondent node returns a CoT message
without a Binding Identifier mobility option. The mobile node
knows whether the correspondent supports processing the Binding
Identifier mobility option, by checking if the option is present
in the CoT message.
o If either the 'C' or the 'O' flag is set in the Binding Identifier
mobility option, the correspondent Node SHOULD NOT calculate a
care-of Keygen token, but MUST include a Binding Identifier
mobility option with status value set to [MCOA MALFORMED] in the
Care-of Test message.
o Otherwise, the correspondent node MUST include a Binding
Identifier mobility option with status value set to zero (success)
in the Care-of Test message.
o The Care-of address field of each Binding Identifier mobility
option, can be omitted, because the mobile node can identify the
corresponding Binding Update list entry using the BID.
6.3. Processing Binding Update
If a Binding Update does not contain a Binding Identifier mobility If a Binding Update does not contain a Binding Identifier mobility
option, its processing is same as in [RFC-3775]. If the receiver option, its processing is same as in [RFC-3775]. If the receiver
already has multiple bindings for the home address, it MUST replace already has multiple bindings for the home address, it MUST replace
all the existing bindings by the received binding. As a result, the all the existing bindings by the received binding. As a result, the
receiver node MUST have only one binding cache entry for the mobile receiver node MUST have only one binding cache entry for the mobile
node. If the Binding Update is for de-registration, the receiver node. If the Binding Update is for de-registration, the receiver
MUST delete all existing bindings from its Binding Cache. MUST delete all existing bindings from its Binding Cache.
If the Binding Update contains a Binding Identifier mobility If the Binding Update contains a Binding Identifier mobility
skipping to change at page 28, line 48 skipping to change at page 26, line 19
o When the Length value is either 12 or 20, the care-of address MUST o When the Length value is either 12 or 20, the care-of address MUST
be present in the Binding Identifier mobility option. If the be present in the Binding Identifier mobility option. If the
valid care-of address is not present, the receiver MUST reject the valid care-of address is not present, the receiver MUST reject the
Binding Identifier mobility option and returns the status value Binding Identifier mobility option and returns the status value
set to [MCOA MALFORMED]. set to [MCOA MALFORMED].
o When multiple Binding Identifier mobility options are present in o When multiple Binding Identifier mobility options are present in
the Binding Update, it is treated as bulk registration. If the the Binding Update, it is treated as bulk registration. If the
receiving node is a correspondent node, it MUST reject the Binding receiving node is a correspondent node, it MUST reject the Binding
Update and returns the status value in the binding acknowledgement Update and returns the status value in the binding Acknowledgement
set to [MCOA BULK REGISTRATION NOT SUPPORT] set to [MCOA BULK REGISTRATION NOT SUPPORT]
o If the Lifetime field in the Binding Update is set to zero, the o If the Lifetime field in the Binding Update is set to zero, the
receiving node deletes the binding entry that corresponds to the receiving node deletes the binding entry that corresponds to the
BID in the Binding Identifier mobility option. If the receiving BID in the Binding Identifier mobility option. If the receiving
node does not have an appropriate binding for the BID, it MUST node does not have an appropriate binding for the BID, it MUST
reject the Binding Update and send a Binding Acknowledgement with reject the Binding Update and send a Binding Acknowledgement with
status set to 133 [not home agent for this mobile node]. status set to 133 [not home agent for this mobile node].
o If the 'O' flag is set in the de-registering Binding Update, it is o If the 'O' flag is set in the de-registering Binding Update, it is
skipping to change at page 29, line 39 skipping to change at page 27, line 10
field of the IPv6 header. field of the IPv6 header.
* If the Length value of the Binding Identifier mobility option * If the Length value of the Binding Identifier mobility option
is 4 and an alternate care-of address is present, the care-of is 4 and an alternate care-of address is present, the care-of
address is copied from the Alternate Care-of address mobility address is copied from the Alternate Care-of address mobility
option. option.
o Once the care-of address(es) have been retrieved from the Binding o Once the care-of address(es) have been retrieved from the Binding
Update, the receiving nodes creates new binding(s). Update, the receiving nodes creates new binding(s).
* If only the 'O' flag is set in the Binding Identifier mobility * If 'O' flag is not set in all the Binding Identifier options,
the home agent MUST return the status value [MCOA MALFORMED] by
Binding Acknowledgement.
* If the 'O' flag is set in the Binding Identifier mobility
option, the home agent removes all the existing bindings and option, the home agent removes all the existing bindings and
registers the received bindings. registers the received bindings.
* If the receiver has a regular binding which does not have BID * If the receiver has a regular binding which does not have BID
for the mobile node, it must not process the binding update. for the mobile node, it must not process the binding update.
The receiver should sent a binding acknowledgement with status The receiver should sent a binding acknowledgement with status
set to [MCOA BID CONFLICT]. set to [MCOA BID CONFLICT].
* If the receiver already has a binding with the same BID but * If the receiver already has a binding with the same BID but
different care-of address, it MUST update the binding and different care-of address, it MUST update the binding and
skipping to change at page 30, line 36 skipping to change at page 28, line 11
or a Binding Identifier mobility option. If the status value is or a Binding Identifier mobility option. If the status value is
specific to one of bindings in the bulk registration, the status specific to one of bindings in the bulk registration, the status
value MUST be stored in the Status field in the corresponding Binding value MUST be stored in the Status field in the corresponding Binding
Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be
set to the Status field of the Binding Acknowledgement so that the set to the Status field of the Binding Acknowledgement so that the
receiver can examine the Status field of each Binding Identifier receiver can examine the Status field of each Binding Identifier
mobility option for further operations. Otherwise, the status field mobility option for further operations. Otherwise, the status field
of the Binding Identifier mobility option MUST be set to zero and the of the Binding Identifier mobility option MUST be set to zero and the
home agent status field of the Binding Acknowledgement is used. home agent status field of the Binding Acknowledgement is used.
6.4. Sending Binding Refresh Request 6.3. Sending Binding Refresh Request
When a node (home agent or correspondent node) sends a Binding When a node (home agent or correspondent node) sends a Binding
Refresh Request for a particular binding created with the BID, the Refresh Request for a particular binding created with the BID, the
node SHOULD include the Binding Identifier mobility option in the node SHOULD include the Binding Identifier mobility option in the
Binding Refresh Request. The node MAY include multiple Binding Binding Refresh Request. The node MAY include multiple Binding
Identifier mobility options if there are multiple bindings that need Identifier mobility options if there are multiple bindings that need
to be refreshed. to be refreshed.
6.5. Receiving Packets from Mobile Node 6.4. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address that from a mobile node, it MUST check that the care-of address that
appears in the source address field of the IPv6 header MUST be equal appears in the source address field of the IPv6 header MUST be equal
to one of the care-of addresses in the binding cache entry. If no to one of the care-of addresses in the binding cache entry. If no
binding is found, the packets MUST be discarded. The node MUST also binding is found, the packets MUST be discarded. The node MUST also
send a Binding Error message as specified in [RFC-3775]. This send a Binding Error message as specified in [RFC-3775]. This
verification MUST NOT be done for a Binding Update. verification MUST NOT be done for a Binding Update.
7. Network Mobility Applicability 7. Network Mobility Applicability
skipping to change at page 36, line 14 skipping to change at page 33, 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.
9.2. Transport Mode IPsec protected messages 9.2. Transport Mode IPsec protected messages
For Mobile IPv6 signaling message protected using IPsec in transport For Mobile IPv6 signaling message protected using IPsec in transport
mode, the use of a particular care-of address among multiple care-of mode, the use of a particular care-of address among multiple care-of
addresses does not matter for IPsec processing. addresses does not matter for IPsec processing.
For Mobile Prefix Discovery messages, [RFC-3775] requires the home The home agent processes Mobile Prefix Discovery messages with the
agent to verify that the mobile node is using the care-of address same rules of data packets described in Section 6.4.
that is in the binding cache entry that corresponds to the mobile
node's home address. If a different address is used as the source
address, the message is silently dropped by the home agent. This
document requires the home agent implementation to process the
message as long as the source address is one of the care-of addresses
in the binding cache entry for the mobile node.
9.3. Tunnel Mode IPsec protected messages 9.3. Tunnel Mode IPsec protected messages
The use of IPsec in tunnel mode with multiple care-of address The use of IPsec in tunnel mode with multiple care-of address
introduces a few issues that require changes to how the mobile node introduces a few issues that require changes to how the mobile node
and the home agent send and receive tunneled traffic. The route and the home agent send and receive tunneled traffic. The route
optimization mechanism described in [RFC-3775] mandates the use of optimization mechanism described in [RFC-3775] mandates the use of
IPsec protection in tunnel mode for the HoTi and HoT messages. The IPsec protection in tunnel mode for the HoTi and HoT messages. The
mobile node and the home agent may also choose to protect all reverse mobile node and the home agent may also choose to protect all reverse
tunneled payload traffic with IPsec in tunnel mode. The following tunneled payload traffic with IPsec in tunnel mode. The following
skipping to change at page 38, line 12 skipping to change at page 35, line 12
integration between the IPsec and Mobile IP implementations on the integration between the IPsec and Mobile IP implementations on the
home agent. home agent.
10. Security Considerations 10. Security Considerations
The security considerations for securing the Binding Update and The security considerations for securing the Binding Update and
binding acknowledgement messages with multiple care-of address are binding acknowledgement messages with multiple care-of address are
very similar to the security considerations for securing the Binding very similar to the security considerations for securing the Binding
Update and binding acknowledgement. Please see [RFC-3775] for more Update and binding acknowledgement. Please see [RFC-3775] for more
information. The Binding Update and binding acknowledgement messages information. The Binding Update and binding acknowledgement messages
with multiple care-of addresses MUST be protected using IPsec as show with multiple care-of addresses are securely exchanged as described
in Section 9. Additional security considerations are described in [RFC-3775], [RFC-4877] and Section 9. Additional security
below. considerations are described below.
With simultaneous binding support, it is possible for a malicious With simultaneous binding support, it is possible for a malicious
mobile node to successfully bind a number of victims' addresses as mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home agent. valid care-of addresses for the mobile node with its home agent.
Once these addresses have been bound, the malicious mobile node can Once these addresses have been bound, the malicious mobile node can
perform a re-direction attack by instructing the home agent (e.g. perform a re-direction attack by instructing the home agent (e.g.
setting filtering rules to direct a large file transfer) to tunnel setting filtering rules to direct a large file transfer) to tunnel
packets to the victims' addresses. Such risk is highlighted in [ID- packets to the victims' addresses. Such risk is highlighted in [ID-
MIP6ANALYSIS]. These attacks are possible because the care-of MIP6ANALYSIS]. These attacks are possible because the care-of
addresses sent by the mobile node in the Binding Update messages are addresses sent by the mobile node in the Binding Update messages are
skipping to change at page 39, line 5 skipping to change at page 36, line 5
file transfer). However, in the simultaneous binding support case, a file transfer). However, in the simultaneous binding support case, a
malicious mobile node could bind a valid care-of address in addition malicious mobile node could bind a valid care-of address in addition
to multiple victims addresses. This valid care-of address could then to multiple victims addresses. This valid care-of address could then
be used by the malicious mobile node to set up flow filtering rules be used by the malicious mobile node to set up flow filtering rules
at its home agent, thereby controlling and/or launching new re- at its home agent, thereby controlling and/or launching new re-
direction attacks. direction attacks.
Thus, in view of such risks, it is advisable for a home agent to Thus, in view of such risks, it is advisable for a home agent to
employ some form of care-of address verification mechanism before employ some form of care-of address verification mechanism before
using the care-of addresses as a valid routing path to a mobile node. using the care-of addresses as a valid routing path to a mobile node.
Solutions related to this are described in [ID-COAVERIFY]. These mechanisms are out-of scope for this document. The home agent
can also choose to reject bulk registration by using [MCOA BULK
REGISTRATION PROHIBITED] in a Binding Acknowledgement.
11. IANA Considerations 11. IANA Considerations
The following Extension Types MUST be assigned by IANA: The following Extension Types MUST be assigned by IANA:
o Binding Identifier mobility option type: This must be assigned o Binding Identifier mobility option type: This must be assigned
from the same space as mobility option in [RFC-3775]. from the same space as mobility option in [RFC-3775].
o New Successful Status of Binding Acknowledgement: This status code o New Successful Status of Binding Acknowledgement: This status code
must be assigned from the same space as binding acknowledgement must be assigned from the same space as binding acknowledgement
skipping to change at page 40, line 30 skipping to change at page 37, line 30
o New Unsuccessful Status of Binding Acknowledgement: These status o New Unsuccessful Status of Binding Acknowledgement: These status
codes must also be assigned from the same space as binding codes must also be assigned from the same space as binding
acknowledgement status codes in [RFC-3775]. acknowledgement status codes in [RFC-3775].
* MCOA MALFORMED (TBD) * MCOA MALFORMED (TBD)
* MCOA BID CONFLICT (TBD) * MCOA BID CONFLICT (TBD)
* MCOA PROHIBITED(TBD) * MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD) * MCOA BULK REGISTRATION PROHIBITED (TBD)
* MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD)
12. Acknowledgements 12. Acknowledgements
The authors would like to special thank George Tsirtsis for thorough The authors would like to special thank George Tsirtsis for thorough
review and suggestions. The authors would also like to thank review and suggestions. The authors would also like to thank
Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin
Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas
Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to
Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
Uehara, Masafumi Watari and Jun Murai for earlier work on this Uehara, Masafumi Watari and Jun Murai for earlier work on this
skipping to change at page 42, line 15 skipping to change at page 39, line 15
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 (work in
progress), July 2008. progress), July 2008.
[ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-02 (work in progress), July 2008.
[RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June
2008. 2008.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku 6-6-20 Akasaka, Minato-ku
Tokyo 107-0052 Tokyo 107-0052
Japan Japan
 End of changes. 68 change blocks. 
245 lines changed or deleted 207 lines changed or added

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