draft-ietf-monami6-multiplecoa-13.txt   draft-ietf-monami6-multiplecoa-14.txt 
MEXT Working Group R. Wakikawa (Ed.) MEXT Working Group R. Wakikawa (Ed.)
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track V. Devarapalli Intended status: Standards Track V. Devarapalli
Expires: October 22, 2009 Wichorus Expires: November 28, 2009 Wichorus
G. Tsirtsis G. Tsirtsis
Qualcomm Qualcomm
T. Ernst T. Ernst
INRIA INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
April 20, 2009 May 27, 2009
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-13.txt draft-ietf-monami6-multiplecoa-14.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 October 22, 2009. This Internet-Draft will expire on November 28, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 39 skipping to change at page 3, line 39
4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13
4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14
4.4. New Status Values for Binding Acknowledgement . . . . . . 15 4.4. New Status Values for Binding Acknowledgement . . . . . . 15
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18
5.1. Management of Care-of Address(es) and Binding 5.1. Management of Care-of Address(es) and Binding
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18 Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18
5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19
5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20
5.5. Returning Home: Using Single Interface . . . . . . . . . . 20 5.5. Returning Home with complete binding de-registration:
Using Single Interface . . . . . . . . . . . . . . . . . . 20
5.5.1. Using only Interface attached to the Home Link . . . . 21 5.5.1. Using only Interface attached to the Home Link . . . . 21
5.5.2. Using only Interface attached to the Visited Link . . 21 5.5.2. Using only Interface attached to the Visited Link . . 21
5.6. Returning Home: Simultaneous Home and Visited Link 5.6. Returning Home: Simultaneous Home and Visited Link
Operation . . . . . . . . . . . . . . . . . . . . . . . . 21 Operation . . . . . . . . . . . . . . . . . . . . . . . . 21
5.6.1. Problems of Simultaneous Home and Foreign 5.6.1. Problems of Simultaneous Home and Foreign
Attachments . . . . . . . . . . . . . . . . . . . . . 21 Attachments . . . . . . . . . . . . . . . . . . . . . 21
5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22
5.6.3. Home Binding Support . . . . . . . . . . . . . . . . . 23 5.6.3. Home Binding Support . . . . . . . . . . . . . . . . . 23
5.6.4. Sending Packets from the Home Link . . . . . . . . . . 23 5.6.4. Sending Packets from the Home Link . . . . . . . . . . 23
5.6.5. Leaving from the Home Link . . . . . . . . . . . . . . 24 5.6.5. Leaving from the Home Link . . . . . . . . . . . . . . 24
5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 24
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 25
5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 26
6. Home Agent and Correspondent Node Operation . . . . . . . . . 27 6. Home Agent and Correspondent Node Operation . . . . . . . . . 27
6.1. Searching Binding Cache with Binding Identifier . . . . . 27 6.1. Searching Binding Cache with Binding Identifier . . . . . 27
6.2. Processing Binding Update . . . . . . . . . . . . . . . . 27 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 27
6.3. Sending Binding Acknowledgement for home link 6.3. Sending Binding Acknowledgement for home link
registration . . . . . . . . . . . . . . . . . . . . . . . 29 registration . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 31 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 31
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 31 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 31
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 32
8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 33
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 33
8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 34
9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 36 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 36
skipping to change at page 8, line 34 skipping to change at page 8, line 34
correspondent node's binding correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2] binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3] binding [2001:db8::EUI BID3 care-of address3]
Figure 1: Multiple Care-of Address Registration Figure 1: Multiple Care-of Address Registration
If the mobile node decides to act as a regular mobile node compliant If the mobile node decides to act as a regular mobile node compliant
with [RFC-3775], it sends a Binding Update without any Binding with [RFC-3775], it sends a Binding Update without any Binding
Identifier mobility options. The receiver of the Binding Update Identifier mobility options. The receiver of the Binding Update
deletes all the bindings registering with a BID and registers only a deletes all the bindings registered with a BID and registers only a
single binding for the mobile node. Note that the mobile node can single binding for the mobile node. Note that the mobile node can
continue using the BID even if it has only a single binding that is continue using the BID even if it has only a single binding that is
active. active.
Binding cache lookup is done based on the home address and BID Binding cache lookup is done based on the home address and BID
information if a BID is available. This is different from RFC 3775, information if a BID is available. This is different from RFC 3775,
where only the home address is used for binding cache lookup. where only the home address is used for binding cache lookup.
Binding cache lookup is operated for either protocol signaling and Binding cache lookup is operated for either protocol signaling and
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
skipping to change at page 9, line 22 skipping to change at page 9, line 22
In any case, to avoid problems with upper layer protocols and TCP in In any case, to avoid problems with upper layer protocols and TCP in
particular, a single packet flow as identified by the 5-tuple SHOULD particular, a single packet flow as identified by the 5-tuple SHOULD
only be sent to a single care-of address at a time. only be sent to a single care-of address at a time.
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 and Section 5.5.1 describe the its returns home. Section 5.6 and Section 5.5.1 describe the
returning home 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 and takes back full ownership of its HoA on the
all bindings with the home agent related to all care-of home link. This is illustrated in Figure 2. It de-registers all
addresses. The interfaces still attached to the visited link(s) bindings with the home agent related to all care-of addresses.
are no longer going to be receiving any encapsulated traffic from The interfaces still attached to the visited link(s) are no
the home agent. On the other hand, the mobile node can continue longer going to be receiving any encapsulated traffic from the
communicating with the correspondent node from the other home agent. On the other hand, the mobile node can continue
communicating with the correspondent nodes from the other
interfaces attached to foreign links by using route optimization. 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
still send Binding Updates for other active care-of addresses still send Binding Updates for other active care-of addresses
(CoA1 and CoA2) to correspondent nodes. Since the correspondent (CoA1 and CoA2) to correspondent nodes. Since the correspondent
node has bindings, packets are routed to each Care-of Addresses node has bindings, packets are routed from and to each Care-of
directly. Addresses directly.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
+------+ Internet |----------+ HA | +------+ Internet |----------+ HA |
| +----+-----+ +--+-+ | +----+-----+ +--+-+
CoA2| | | Home Link CoA2| | | Home Link
+--+--+ | --+---+------ +--+--+ | --+---+------
skipping to change at page 14, line 51 skipping to change at page 14, line 51
address is not carried by this option, the length value MUST be address is not carried by this option, the length value MUST be
set to 4. If the IPv4 care-of address is stored in the care-of set to 4. If the IPv4 care-of address is stored in the care-of
address field, the length MUST be 8. Otherwise, the Length value address field, the length MUST be 8. Otherwise, the Length value
MUST be set to 20 for IPv6 care-of address. MUST be set to 20 for IPv6 care-of address.
Binding ID (BID) Binding ID (BID)
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 Binding Identifier mobility address in the Binding Update or the Binding Identifier mobility
option. The BID is a 16-bit unsigned integer. The value of zero option. The BID is a 16-bit unsigned integer. The value of zero
is reserved and MUST NOT be used. is reserved and SHOULD 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 only for this BID. If this field is set Binding Acknowledgement only for this BID. If this field is set
to zero, the receiver ignores this field and uses the registration to zero, the receiver ignores this field and uses the registration
status stored in the Binding Acknowledgement message. The status stored in the Binding Acknowledgement message. The
receiver MUST ignore this field if the Binding Identifier mobility receiver MUST ignore this field if the Binding Identifier mobility
option is not carried within either the Binding Acknowledgement or option is not carried within either the Binding Acknowledgement or
the Care-of Test messages. The possible status codes are the same the Care-of Test messages. The possible status codes are the same
as the status codes of Binding Acknowledgement. This Status field as the status codes of Binding Acknowledgement. This Status field
is 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.
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 it 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
7 bits Reserved field. The value MUST be initialized to zero by 7 bits Reserved field. The value MUST be initialized to zero by
the sender, and SHOULD be ignored by the receiver. the sender, and SHOULD be ignored by the receiver.
Care-of Address Care-of Address
skipping to change at page 16, line 28 skipping to change at page 16, line 28
Registration failed because Binding Identifier mobility option was Registration failed because Binding Identifier mobility option was
not formatted correctly. This value is used in the following not formatted correctly. This value is used in the following
cases. cases.
* when the wrong length value is specified (neither 4, 8 nor 20) * when the wrong length value is specified (neither 4, 8 nor 20)
in the length field of the Binding Identifier mobility option. in the length field of the Binding Identifier mobility option.
* when a unicast routable address is not specified in the care-of * when a unicast routable address is not specified in the care-of
address field of the Binding Identifier mobility option. address field of the Binding Identifier mobility option.
* when a care-of address is not appeared in the care-of address * when a care-of address does not appear in the care-of address
field of the Binding Identifier mobility option stored in an field of the Binding Identifier mobility option stored in an
IPsec ESP protected Binding Update. IPsec ESP protected Binding Update.
MCOA NON-MCOA BINDING EXISTS (TBD more than 128) MCOA NON-MCOA BINDING EXISTS (TBD more than 128)
It indicates that a bootstrapping multiple care-of address It indicates that a bootstrapping multiple care-of address
registration was performed without the 'O' flag set. registration was performed without the 'O' flag set.
MCOA UNKOWN COA(TBD more than 128) MCOA UNKOWN COA(TBD more than 128)
skipping to change at page 18, line 38 skipping to change at page 18, 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. The value is an integer between 1 unique for a given home address. The value is an integer between 1
and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node
has only one care-of address, the assignment of a BID is not needed has only one care-of address, the assignment of a BID is not needed
until it has multiple care-of addresses to register with, at which until it has multiple care-of addresses to register with, at which
time all of the care-of addresses MUST be mapped to BIDs. time all of the care-of addresses MUST be mapped to BIDs.
When a mobile node registers a given BID for the first time it MUST When a mobile node registers a given BID for the first time it MUST
include the care of address field in the Binding Identifier mobility include the care-of address field in the Binding Identifier mobility
option. For any subsequent registrations that either re-register or option. For any subsequent registrations that either re-register or
de-register the same BID, the MN SHOULD NOT include the care of de-register the same BID, the MN need not include the care-of address
address field in the Binding Identifier mobility option. field in the Binding Identifier mobility option.
5.2. Binding Registration 5.2. 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 6. as shown in Figure 6.
When IPsec ESP is used for protecting the Binding Update, a care-of When IPsec ESP is used for protecting the Binding Update, a care-of
address MUST be carried in an alternate care-of address mobility address MUST be carried in an alternate care-of address mobility
option as described in [RFC-4877]. However, in this specification, option as described in [RFC-4877]. However, in this specification,
skipping to change at page 20, line 46 skipping to change at page 20, line 46
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). Since de-registration attempts to remove a BID specified BID(s). Since de-registration attempts to remove a BID
that already exists, the care-of addresses field in each binding that already exists, the care-of addresses field in each binding
identifier option can be omitted by the sender as defined in identifier option can be omitted by the sender as defined in
Section 5.1. Section 5.1.
5.5. Returning Home: Using Single Interface 5.5. Returning Home with complete binding de-registration: 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. interface it needs to use.
5.5.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 it has
shown in Figure 2 and as defined in [RFC-3775]. After the de- with the home agent as shown in Figure 2 and as defined in [RFC-
registration step, all the packets routed by the home agent are only 3775]. After the de-registration step, all the packets routed by the
forwarded to the interface attached to the home link, even if there home agent are only forwarded to the interface attached to the home
are other active interfaces attached to the visited link(s). While link, even if there are other active interfaces attached to the
the mobile node de-registers all the bindings from the home agent, it visited link(s). While the mobile node de-registers all the bindings
may continue registering bindings for interface(s) attached to from the home agent, it may continue registering bindings for
visited link(s) to the correspondent node as shown in Figure 2. interface(s) attached to visited link(s) to the correspondent node as
shown in Figure 2.
5.5.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 physically but shuts down the interface The mobile node returns home physically but shuts down the interface
attached to the home link. As a result, a mobile node does not 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 return home even though it attaches to the home link by one of
interfaces. Before shutting down the interface, any binding for the interfaces. Before shutting down the interface, any binding for the
care-of address previously associated with the interface should be care-of address previously associated with the interface should be
deleted as defined in . deleted as defined in Section 5.4.
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. Returning Home: Simultaneous Home and Visited Link Operation 5.6. Returning Home: Simultaneous Home and Visited Link Operation
5.6.1. 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. attached to both foreign and home links as shown in Figure 3.
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 Proxy Neighbor Discovery [RFC-4861] while the mobile node node using Proxy Neighbor Discovery [RFC-4861] while the mobile node
is away from the home link. When the mobile node returns home, the is away from the home link. When the mobile node returns home, the
home agent deletes the binding cache and stops proxying for the home home agent deletes the binding cache and stops proxying for the home
address so that a mobile node can configure its home address on the address so that a mobile node can configure its home address on the
interface attached to the home link. In this specification, a mobile interface attached to the home link. In this specification, a mobile
node may return home, configure the home address on the interface node may return home, configure the home address on the interface
attached to the home link, but still use the interfaces attached to attached to the home link, but still use the interfaces attached to
the foreign links. In this case, a possible conflict arises when the the foreign links. In this case, a possible conflict arises when
both the home agent and the mobile node try to defend the home both the home agent and the mobile node try to defend the home
address. If the home agent stops proxying for the home address, the address. If the home agent stops proxying for the home address, the
packets are always routed to the interface attached to the home link packets are always routed to the interface attached to the home link
and are never routed to the interfaces attached to the visited links. and are never routed to the interfaces attached to the visited links.
It is required to avoid the conflict between the home agent and the It is required to avoid the conflict between the home agent and the
mobile node, while still allowing the simultaneous use of home and mobile node, while still allowing the simultaneous use of home and
foreign links. The following describes the mechanism for achieving foreign links. The following describes the mechanism for achieving
this. this.
5.6.2. Overview and Approach 5.6.2. Overview and Approach
skipping to change at page 23, line 11 skipping to change at page 23, line 14
operation is similar to Mobile IPv6 [RFC-3775] when a mobile node operation is similar to Mobile IPv6 [RFC-3775] when a mobile node
sends a deregistration binding update to the home agent's link- sends a deregistration binding update to the home agent's link-
layer address in the operation for returning home. layer address in the operation for returning home.
5.6.3. Home Binding Support 5.6.3. Home Binding Support
When the home binding is used, the mobile node MUST send a When the home binding is used, the mobile node MUST send a
registering binding update with a Binding Identifier mobility option registering binding update with a Binding Identifier mobility option
whith H flag set. The lifetime MUST be set to a non-zero lifetime of whith H flag set. The lifetime MUST be set to a non-zero lifetime of
the home binding, and the care-of address MUST be set to the home the home binding, and the care-of address MUST be set to the home
address. address. The mobile node registers only one home binding at the time
even if it attaches to the home link by multiple interfaces.
The mobile node SHOULD include the Mobility Header Link-layer Address The mobile node SHOULD include the Mobility Header Link-layer Address
Option [RFC-5268] to notify the mobile node's link-layer address to Option [RFC-5268] to notify the mobile node's link-layer address to
the home agent, too. The option code of the Mobility Header Link- the home agent, too. The option code of the Mobility Header Link-
layer Address option MUST be set to '2' (Link-layer Address of the layer Address option MUST be set to '2' (Link-layer Address of the
mobile node). This link-layer address is required for the home agent mobile node). This link-layer address is required for the home agent
to send the Binding Acknowledgement and to forward the mobile node's to send the Binding Acknowledgement and to forward the mobile node's
packet. packet.
According to [RFC-3775], the mobile node MUST start responding to According to [RFC-3775], the mobile node MUST start responding to
skipping to change at page 25, line 16 skipping to change at page 25, line 22
If the status code is greater than or equal to 128, the mobile node If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise, starts relevant operations according to the error code. Otherwise,
the mobile node assumes that the originator (home agent or the mobile node assumes that the originator (home agent or
correspondent node) successfully registered the binding information correspondent node) successfully registered the binding information
and BID for the mobile node. and BID for the mobile node.
o If the Status value is [MCOA PROHIBITED], the mobile node MUST o If the Status value is [MCOA PROHIBITED], the mobile node MUST
stop registering multiple bindings with the node that sent the stop registering multiple bindings with the node that sent the
Binding Acknowledgement. Binding Acknowledgement.
o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the o If the Status value is [MCOA BULK REGISTRATION PROHIBITED], the
mobile node needs to stop using bulk registrations with the node mobile node needs to stop using bulk registrations with the node
that sent the Binding Acknowledgement. It should assume that none that sent the Binding Acknowledgement. It should assume that none
of the attempted registrations were successful. of the attempted registrations were successful.
o If [MCOA MALFORMED] is specified, it indicates that the binding o If [MCOA MALFORMED] is specified, it indicates that the binding
identifier mobility option is formatted wrongly presumably due to identifier mobility option is formatted wrongly presumably due to
a programming error or major packet corruption. . a programming error or major packet corruption.
o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that
there is non-MCoA binding entry in the receiver. The mobile node there is non-MCoA binding entry in the receiver. The mobile node
MUST set 'O' flag so that all the registered bindings are replced MUST set 'O' flag so that all the registered bindings are replaced
by an MCoA registration as described in Section 5.9. by an MCoA registration as described in Section 5.9.
o If [MCOA UNKNOWN COA] is specified, it means that the mobile node o If [MCOA UNKNOWN COA] is specified, it means that the mobile node
sent a binding identifier mobility option without a care-off sent a binding identifier mobility option without a care-of
address field but the receiver could not find an entry for the BID address field but the receiver could not find an entry for the BID
indicated. If the mobile node is trying to deregister a BID, it indicated. If the mobile node is trying to deregister a BID, it
NEED NOT do anything further. If the mobile node is trying to need not do anything further. If the mobile node is trying to
refresh a binding it SHOULD send a binding identifier mobility refresh a binding it SHOULD send a binding identifier mobility
option including the care-of address field. option including the care-of address field.
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 6.4. a Binding Refresh Request is described in Section 6.4.
If a mobile node receives a Binding Refresh Request with a Binding If a mobile node receives a Binding Refresh Request with a Binding
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 at least for the respective binding, as described in Binding Update at least for the respective binding, as described in
Section 5.2 and Section 5.3. Section 5.2 and Section 5.3.
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 Update message. first time, it MUST set the 'O' flag in the Binding Update message.
If old bindings still exists at the home agent, the mobile node has If old bindings still exist at the home agent, the mobile node has no
no knowledge of which bindings still exist at the home agent. This knowledge of which bindings still exist at the home agent. This
scenario happens when a mobile node reboots and loses state regarding scenario happens when a mobile node reboots and loses state regarding
the registrations. If the 'O' flag is set, all the bindings are the registrations. If the 'O' flag is set, all the bindings are
replaced by the new binding(s). replaced by the new binding(s).
6. Home Agent and Correspondent Node Operation 6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Identifier 6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
skipping to change at page 28, line 18 skipping to change at page 28, line 18
be present in the Binding Identifier mobility option. If the be present in the Binding Identifier mobility option. If the
unicast routable address [RFC-3775] is not present in the care-of unicast routable address [RFC-3775] is not present in the care-of
address field, the receiver MUST reject the Binding Identifier address field, the receiver MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA mobility option and returns the status value set to [MCOA
MALFORMED]. 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 PROHIBITED].
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
ignored. If the 'H' flag is set, the home agent stores a home ignored. If the 'H' flag is set, the home agent stores a home
address in the Care-of Address field of the binding cache entry. address in the Care-of Address field of the binding cache entry.
The home agent MUST follow the descriptions described in The home agent MUST follow the descriptions described in
Section 5.6. Section 5.6.
o If the Lifetime field is not set to zero, the receiving node o If the Lifetime field is not set to zero, the receiving node
registers a binding with the specified BID as a mobile node's registers a binding with the specified BID as a mobile node's
binding. The Care-of address is obtained from the Binding Update binding. The Care-of address is obtained from the Binding Update
packet as follows: packet as follows:
* If the Length value of the Binding Identifier mobility option * If the Length value of the Binding Identifier mobility option
is 20, the care-of address is copied the IPv6 address from the is 20, the care-of address is the IPv6 address copied from the
care-of address field in the Binding Identifier mobility care-of address field in the Binding Identifier mobility
option. option.
* When the Length value is 8, the address MUST be the IPv4 valid * When the Length value is 8, the address MUST be the IPv4 valid
address. How to obtain an IPv4 care-of address is described in address. How to obtain an IPv4 care-of address is described in
Section 8. Section 8.
* When the Length value is 4 and If the Binding Identifier is
present in the Binding Cache, the receiving node MUST update
the associated binding entry. Otherwise, the receiving node
MUST reject that Binding Identifier mobility option and send a
Binding Acknowledgement with the status for that Binding
Identifier mobility option set to [MCOA UNKNOWN].
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 the 'O' flag is set in the Binding Update, the home agent * If the 'O' flag is set in the Binding Update, the receiving
removes all the existing bindings and registers the received node removes all the existing bindings and registers the
binding(s). received binding(s).
* If the 'O' flag is unset in the Binding Update and the receiver * If the 'O' flag is unset in the Binding Update and the receiver
has a regular binding which does not have BID for the mobile has a regular binding which does not have BID for the mobile
node, it must not process the Binding Update. The receiver node, it must not process the Binding Update. The receiver
should sent a Binding Acknowledgement with status set to [MCOA should sent a Binding Acknowledgement with status set to [MCOA
NON-MCOA BINDING EXISTS]. NON-MCOA BINDING EXISTS].
* 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
respond with a Binding Acknowledgement with status set to 0 respond with a Binding Acknowledgement with status set to 0
[Binding Update accepted]. [Binding Update accepted].
* If the receiver does not have a binding entry for the BID, it * If the receiver does not have a binding entry for the BID, it
registers a new binding for the BID and responds with a Binding registers a new binding for the BID and responds with a Binding
Acknowledgement with status set to 0 [Binding Update accepted]. Acknowledgement with status set to 0 [Binding Update accepted].
If all the above operations are successfully completed, a Binding If all the above operations are successfully completed and 'A' flag
Acknowledgement containing the Binding Identifier mobility options is set in the Binding Update, a Binding Acknowledgement containing
MUST be sent to the mobile node. Whenever a Binding Acknowledgement the Binding Identifier mobility options MUST be sent to the mobile
is sent, all the Binding Identifier mobility options stored in the node. Whenever a Binding Acknowledgement is sent, all the Binding
Binding Update MUST be copied to the Binding Acknowledgement except Identifier mobility options stored in the Binding Update MUST be
the status field. The Care-of address field in each Binding copied to the Binding Acknowledgement except the status field. The
Identifier mobility option, however, MAY be omitted, because the Care-of address field in each Binding Identifier mobility option,
mobile node can match a corresponding binding update list entry using however, MAY be omitted, because the mobile node can match a
the BID. corresponding binding update list entry using the BID.
When a correspondent node sends a Binding Acknowledgement, the status When a correspondent node sends a Binding Acknowledgement, the status
value MUST be always stored in the Status field of the Binding value MUST be always stored in the Status field of the Binding
Acknowledgement and the Status field of Binding Identifier mobility Acknowledgement and the Status field of Binding Identifier mobility
option MUST be always set to zero. option MUST be always set to zero.
When the home agent sends a Binding Acknowledgement, the status value When the home agent sends a Binding Acknowledgement, the status value
can be stored in the Status field of either a Binding Acknowledgement can be stored in the Status field of either a Binding Acknowledgement
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
skipping to change at page 31, line 27 skipping to change at page 31, line 35
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.5. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address 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 is equal to
to one of the care-of addresses in the binding cache entry. If no 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
The binding management mechanisms are the same for a mobile host that The binding management mechanisms are the same for a mobile host that
uses Mobile IPv6 and for a mobile router that is using the NEMO Basic uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
Support protocol [RFC-3963]. Therefore the extensions described in Support protocol [RFC-3963]. Therefore the extensions described in
this document can also be used to support a mobile router with this document can also be used to support a mobile router with
skipping to change at page 33, line 19 skipping to change at page 33, line 19
when the mobile node is attached to an IPv4-only access network. It when the mobile node is attached to an IPv4-only access network. It
also allows the mobile node to acquire an IPv4 home address in also allows the mobile node to acquire an IPv4 home address in
addition to an IPv6 home address for use with IPv4-only correspondent addition to an IPv6 home address for use with IPv4-only correspondent
nodes. This section describes how the multiple care-of address nodes. This section describes how the multiple care-of address
registration works with IPv4 care-of and home addresses. registration works with IPv4 care-of and home addresses.
8.1. IPv4 Care-of Address Registration 8.1. IPv4 Care-of Address Registration
The mobile node can use the extensions described in the document to The mobile node can use the extensions described in the document to
register multiple care-of addresses, even if some of the care-of register multiple care-of addresses, even if some of the care-of
addresses are IPv4 address. addresses are IPv4 addresses.
Bulk registration MUST NOT be used for the initial binding Bulk registration MUST NOT be used for the initial binding
registration from an IPv4 care-of address. This is because, the registration from an IPv4 care-of address. This is because, the
Binding Update and Binding Acknowledgement exchange is used to detect Binding Update and Binding Acknowledgement exchange is used to detect
NAT on the path between the mobile node and the home agent. So the NAT on the path between the mobile node and the home agent. So the
mobile node needs to check for a NAT between each IPv4 care-of mobile node needs to check for a NAT between each IPv4 care-of
address and the home agent. address and the home agent.
The Binding Update MUST be sent to the IPv4 home agent address by The Binding Update MUST be sent to the IPv4 home agent address by
using UDP and IPv4 headers as shown in Figure 9. It is similar to using UDP and IPv4 headers as shown in Figure 9. It is similar to
skipping to change at page 38, line 19 skipping to change at page 38, line 19
care-of address for each flow becomes important. Support for this care-of address for each flow becomes important. Support for this
requires the following two considerations on the home agent. requires the following two considerations on the home agent.
o When the home agent receives a reverse tunneled payload message o When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, the source address used in the protected by IPsec in tunnel mode, the source address used in the
outer IPv6 header is irrelevant to IPsec, since the tunnel mode outer IPv6 header is irrelevant to IPsec, since the tunnel mode
security association is based on the addresses in the inner IPv6 security association is based on the addresses in the inner IPv6
header. Therefore, the same IPsec security association can be header. Therefore, the same IPsec security association can be
used for payload traffic tunneled from any of the care-of used for payload traffic tunneled from any of the care-of
addresses. Note that the care-of address used in the reverse addresses. Note that the care-of address used in the reverse
tunneld traffic can be different from the care-of address used as tunneled traffic can be different from the care-of address used as
the source address in the IKEv2 exchange. However, this does not the source address in the IKEv2 exchange. However, this does not
cause an issue due to the above mentioned reason. cause an issue due to the above mentioned reason.
o For tunneled IPsec traffic from the home agent to the mobile node, o For tunneled IPsec traffic from the home agent to the mobile node,
the IPsec implementation on the home agent will not be aware of the IPsec implementation on the home agent will not be aware of
which care-of address to use when performing IPsec tunnel which care-of address to use when performing IPsec tunnel
encapsulation. The Mobile IP stack on the home agent, based on encapsulation. The Mobile IP stack on the home agent, based on
the binding cache entries created by the mobile node, knows which the binding cache entries created by the mobile node, knows which
care-of address the packet belonging to a particular flow needs to care-of address the packet belonging to a particular flow needs to
be tunneled to. The destination address for the outer IP header be tunneled to. The destination address for the outer IP header
skipping to change at page 42, line 35 skipping to change at page 42, line 35
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 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-07 (work in and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in
progress), December 2008. progress), December 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.
13.2. Informative References 13.2. Informative References
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
 End of changes. 34 change blocks. 
61 lines changed or deleted 70 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/