draft-ietf-monami6-multiplecoa-07.txt   draft-ietf-monami6-multiplecoa-08.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 T. Ernst Intended status: Standards Track V. Devarapalli (Ed.)
Expires: November 1, 2008 INRIA Expires: December 1, 2008 Wichorus
T. Ernst
INRIA
K. Nagami K. Nagami
INTEC NetCore INTEC NetCore
V. Devarapalli (Ed.) May 30, 2008
Wichorus
April 30, 2008
Multiple Care-of Addresses Registration Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-07.txt draft-ietf-monami6-multiplecoa-08.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 November 1, 2008. This Internet-Draft will expire on December 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
According to the current Mobile IPv6 specification, a mobile node may According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, 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 5, line 17 skipping to change at page 5, line 17
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
multiple interfaces to send and receive packets while taking multiple interfaces to send and receive packets while taking
advantage of session continuity provided by Mobile IPv6. This is advantage of session continuity provided by Mobile IPv6. This is
because Mobile IPv6 allows the mobile node to only bind one care-of because Mobile IPv6 allows the mobile node to only bind one care-of
address at a time with its home address. address at a time with its home address. See [ID-MIP6ANALYSIS] on a
further analysis of using multiple interfaces and addresses with
Mobile IPv6.
This document proposes extensions to Mobile IPv6 to allow a mobile This document proposes extensions to Mobile IPv6 to allow a mobile
node to register multiple care-of addresses for a home address and node to register multiple care-of addresses for a home address and
create multiple binding cache entries. A new Binding Identification create multiple binding cache entries. A new Binding Identification
(BID) number is created for each binding the mobile node wants to (BID) number is created for each binding the mobile node wants to
create and sent in the binding update. The home agent that receives create and sent in the binding update. The home agent that receives
this Binding Update creates separate binding for each BID. The BID this Binding Update creates separate binding for each BID. The BID
information is stored in the corresponding binding cache entry. The information is stored in the corresponding binding cache entry. The
BID information can now be used to identify individual bindings. The BID information can now be used to identify individual bindings. The
same extensions can also be used in Binding Updates sent to the same extensions can also be used in Binding Updates sent to the
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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.4. A mobile node MUST NOT perform bulk registration
with a correspondent node. mechanism described in this specification with a correspondent
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
node wants to register multiple bindings, it MUST generate a BID for node wants to register multiple bindings, it MUST generate a BID for
each care-of address and store the BID in the binding update list. A each care-of address and store the BID in the binding update list. A
skipping to change at page 7, line 42 skipping to change at page 7, line 42
exchanging CoTi and CoT message with the correspondent node for each exchanging CoTi and CoT message with the correspondent node for each
care-of address. The mobile node MAY use the same BID that it used care-of address. The mobile node MAY use the same BID that it used
with the home agent for a particular care-of address. For protocol with the home agent for a particular care-of address. For protocol
simplicity, bulk registration to correspondent nodes is not supported simplicity, bulk registration to correspondent nodes is not supported
in this document. This is because the Return Routability mechanism in this document. This is because the Return Routability mechanism
introduced in [RFC-3775] cannot be easily extended to verify multiple introduced in [RFC-3775] cannot be easily extended to verify multiple
care-of addresses stored in a single Binding Update. 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 address. 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 a:b:c:d::EUI. The mobile node has 3 the mobile node (MN) is a:b:c:d::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.
+----+ +----+
| CN | | CN |
+--+-+ +--+-+
| |
+---+------+ +----+ +---+------+ +----+
skipping to change at page 12, line 36 skipping to change at page 12, line 36
the bulk registration. If the mobile node cannot select a sequence the bulk registration. If the mobile node cannot select a sequence
number for all the bindings due to sequence number out of window, it number for all the bindings due to sequence number out of window, it
MUST NOT use the bulk registration for the binding whose sequence MUST NOT use the bulk registration for the binding whose sequence
number is out of window. A separate Binding Update should be sent number is out of window. A separate Binding Update should be sent
for the binding. 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. Test Init and Care-of Test message. The Binding Identifier Mobility
Option has an alignment requirement of 2n if the Care-of Address
field is not presented. Otherwise, it has the alignment requirement
of 8n + 2.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |O|H| Reserved | | Binding ID (BID) | Status |O|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 care-of address (CoA) :
skipping to change at page 13, line 27 skipping to change at page 13, line 29
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 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
When the Binding Identifier mobility option is included in a The Status field is an 8-bit unsigned integer. When the Binding
Binding Acknowledgement, this field overwrites the status field in Identifier mobility option is included in a Binding
the Binding Acknowledgement. If this field is zero, the receiver Acknowledgement, this field overwrites the status field in the
MUST use the registration status stored in the Binding Binding Acknowledgement. If this field is set to zero, the
Acknowledgement message. This Status field is also used to carry receiver ignores this field and uses the registration status
error information related to the care-of address test in the stored in the Binding Acknowledgement message. The receiver MUST
Care-of Test message. The status is 8-bit unsigned integer. The ignore this field if the Binding Identifier mobility option is not
possible status codes are the same as the status codes of Binding carried within either the Binding Acknowledgement or the Care-of
Acknowledgement. Test messages. The possible status codes are the same as the
status codes of Binding Acknowledgement. This Status field is
also used to carry error information related to the care-of
address test in the Care-of Test message.
Overwrite (O) flag Overwrite (O) flag
When this flag is set, a mobile node requests the recipient to When this flag is set, a mobile node requests the recipient to
replace all the bindings to binding entries stored in a Binding replace all the bindings to binding entries stored in a Binding
Update. 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 reserved field MUST be zero. 5 bits Reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver.
Care-of Address Care-of Address
This field has the variable length depending on the specified If a Binding Identifier mobility option is included in a Binding
flags. 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. This field MUST NOT be used if a BID can be stored in this field. If no address is specified in
Binding Identifier mobility option is included in any other this field, the length of this field MUST be zero (i.e. not
message other than a Binding Update. appeared in the option). 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 < 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.
The error status value of the failed mobility option is The error status value of the failed mobility option is
individually stored in the status field of the binding identifier individually stored in the status field of the binding identifier
mobility option. mobility option.
MCOA RETURNHOME WO/NDP (TBD < 128) MCOA RETURNHOME WO/NDP (TBD less than 128)
When a mobile node returns home, it MUST NOT use NDP for the home When a mobile node returns home, it MUST NOT use NDP for the home
address on the home link. This is explained in more detail in address on the home link. This is explained in more detail in
Section 5.6 Section 5.6
MCOA MALFORMED (TBD more than 128) MCOA MALFORMED (TBD more than 128)
Registration failed because Binding Identifier mobility option was Registration failed because Binding Identifier mobility option was
not formatted correctly. not formatted correctly.
skipping to change at page 16, line 29 skipping to change at page 16, line 29
of the announced prefixes. of the announced prefixes.
The difference between the above two cases is only in the number of The difference between the above two cases is only in the number of
physical network interfaces and therefore irrelevant in this physical network interfaces and therefore irrelevant in this
document. What is of significance is the fact that the mobile node document. What is of significance is the fact that the mobile node
has several addresses it can use as care-of addresses. has several addresses it can use as care-of addresses.
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 and negative values should be an integer between 1 and 65535. Zero value MUST NOT be
MUST NOT be used as BIDs. If a mobile node has only one care-of used as BIDs. If a mobile node has only one care-of address, the
address, the assignment of a BID is not needed until it has multiple assignment of a BID is not needed until it has multiple care-of
care-of addresses to register with, at which time all of the care-of addresses to register with, 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. Return Routability: Sending CoTI and Receiving CoT
When a mobile node wants to register multiple care-of address with a 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 correspondent node, it MUST have the valid Care-of Keygen token per
care-of address. The mobile node needs only one Home Keygen token care-of address. The mobile node needs only one Home Keygen token
for its home address. for its home address.
The mobile node MUST include a Binding Identifier mobility option in The mobile node MUST include a Binding Identifier mobility option in
skipping to change at page 17, line 31 skipping to change at page 17, line 31
node MUST have both active Home and Care-of Keygen tokens for Kbm node MUST have both active Home and Care-of Keygen tokens for Kbm
(see Section 5.2.5 of [RFC-3775]) before sending the Binding Update. (see Section 5.2.5 of [RFC-3775]) before sending the Binding Update.
The care-of Keygen tokens MUST be maintained for each care-of address The care-of Keygen tokens MUST be maintained for each care-of address
that the mobile node wants to register to the correspondent node. that the mobile node wants to register to the correspondent node.
The Binding Update to the correspondent node is protected by the The Binding Update to the correspondent node is protected by the
Binding Authorization Data mobility option that is placed after the Binding Authorization Data mobility option that is placed after the
Binding Identifier mobility option. Binding Identifier mobility option.
IPv6 header (src=CoA, dst=HA) IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option IPv6 Home Address Option
ESP Header (for home registration) ESP Header*
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+
(for Route Optimization) (*) if necessary, for home registration
(+) if necessary, for route optimization
Figure 6: Binding Update for Binding Registration Figure 6: Binding Update for Binding Registration
5.4. Bulk Registration 5.4. 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
skipping to change at page 18, line 15 skipping to change at page 18, line 17
wants to register in the same Binding Update message. This is shown wants to register in the same Binding Update message. This is shown
in Figure 7. The rest of the fields and options in the Binding in Figure 7. The rest of the fields and options in the Binding
Update such as Lifetime, Sequence Number, and the flags in the Update such as Lifetime, Sequence Number, and the flags in the
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 7: Binding Update for Bulk Registration Figure 7: 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 bindings in the sent Binding Update, it sets
the 'O' flag. Section 6.3 describes this registration procedure in the 'O' flag. Section 6.3 describes this registration procedure in
detail. detail.
5.5. Binding De-Registration 5.5. Binding De-Registration
skipping to change at page 18, line 39 skipping to change at page 18, line 41
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 and MUST be ignored by the option SHOULD be omitted by the sender (i.e. the field does not
receiver. This is because the receiver will remove the binding that appear in the option) and MUST be ignored by the receiver. This is
matches the specified BID. because the receiver will remove the binding that matches the
specified BID.
5.6. Returning Home 5.6. Returning Home
The mobile node may return to the home link, by attaching to the home The mobile node may return to the home link, by attaching to the home
link through one of 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. The mobile node may use only the
interface with which it is attached to the home link, only the interface with which it is attached to the home link, only the
interfaces still attached to the visited link(s) or use both interfaces still attached to the visited link(s) or use both
interfaces attached to the home link and visited link(s) interfaces attached to the home link and visited link(s)
skipping to change at page 27, line 16 skipping to change at page 27, line 16
6.1. Searching Binding Cache with Binding Identifier 6.1. Searching Binding Cache with Binding Identifier
If either a correspondent node or a home agent has multiple bindings If either a correspondent node or a home agent has multiple bindings
for a mobile node in their binding cache database, it can use any of for a mobile node in their binding cache database, it can use any of
the bindings to communicate with the mobile node. This section the bindings to communicate with the mobile node. This section
explains how to retrieve the desired binding for the binding explains how to retrieve the desired binding for the binding
management. This document does not provide any mechanism to select management. This document does not provide any mechanism to select
the suitable binding for forwarding data packets. the suitable binding for forwarding data packets.
A correspondent node SHOULD use both the home address and the BID as A node which is either a correspondent node or a home agent SHOULD
the search key of the binding cache if it knows the corresponding BID use both the home address and the BID as the search key of the
(ex. when processing signaling messages). In the example below, if a binding cache if it knows the corresponding BID (ex. when processing
correspondent node searches the binding with the home address and signaling messages). In the example below, if a node searches the
BID2, it gets binding2 for this mobile node. binding with the home address and BID2, it gets binding2 for this
mobile node.
binding1 [a:b:c:d::EUI, care-of address1, BID1] binding1 [a:b:c:d::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, care-of address2, BID2] binding2 [a:b:c:d::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, care-of address3, BID3] binding3 [a:b:c:d::EUI, care-of address3, BID3]
Figure 8: Searching the Binding Cache Figure 8: Searching the Binding Cache
A correspondent node learns the BID when it receives a Binding The node learns the BID when it receives a Binding Identifier
Identifier mobility option. At that time, the correspondent node mobility option. At that time, the node MUST look up its binding
MUST look up its binding cache database with the home address and the cache database with the home address and the BID retrieved from the
BID retrieved from the Binding Update. If the correspondent node Binding Update. If the node does not know the BID, it searches for a
does not know the BID, it searches for a binding with only the home binding with only the home address. In such a case, the first
address. In such a case, the first matched binding is found. If the matched binding is found. If the node does not desire to use
correspondent node does not desire to use multiple bindings for a multiple bindings for a mobile node, it can simply ignore the BID.
mobile node, it can simply ignore the BID.
6.2. Receiving CoTI and Sending CoT 6.2. Receiving CoTI and Sending CoT
When a correspondent node receives a CoTI message which contains a When a correspondent node receives a CoTI message which contains a
Binding Identifier mobility option, it processes it as follows. Binding Identifier mobility option, it processes it as follows.
First, the CoTI message is verified as specified in [RFC-3775]. The First, the CoTI message is verified as specified in [RFC-3775]. The
Binding Identifier mobility option is processed as follows: Binding Identifier mobility option is processed as follows:
o If a correspondent node does not understand a Binding Identifier o If a correspondent node does not understand a Binding Identifier
skipping to change at page 28, line 41 skipping to change at page 28, line 41
3775]. Then the receiver processes the Binding Identifier mobility 3775]. Then the receiver processes the Binding Identifier mobility
option(s) as described in the following steps. option(s) as described in the following steps.
o The length value is examined. The length value MUST be either 4, o The length value is examined. The length value MUST be either 4,
8, or 20 depending on the Care-of Address field. If the length is 8, or 20 depending on the Care-of Address field. If the length is
incorrect, the receiver MUST reject the Binding Update and returns incorrect, the receiver MUST reject the Binding Update and returns
the status value set to [MCOA MALFORMED]. the status value set to [MCOA MALFORMED].
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
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]. If the Length value is 12, an IPv4 valid set to [MCOA MALFORMED].
address MUST be present. Otherwise, an IPv6 address MUST be
stored in the Binding Identifier mobility option.
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
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.
skipping to change at page 29, line 14 skipping to change at page 29, line 12
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 also stops performing proxy ND for the mobile The home agent MUST follow the descriptions described in
node's home address. 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 copied the IPv6 address from the
care-of address field in the Binding Identifier mobility care-of address field in the Binding Identifier mobility
option. When the Length value is 12, the address MUST be the option. When the Length value is 12, the address MUST be the
skipping to change at page 30, line 24 skipping to change at page 30, line 22
is sent, all the Binding Identifier mobility options stored in the is sent, all the Binding Identifier mobility options stored in the
Binding Update MUST be copied to the Binding Acknowledgement except Binding Update MUST be copied to the Binding Acknowledgement except
the status field. The Care-of address field in each Binding the status field. The Care-of address field in each Binding
Identifier mobility option, however, can be omitted, because the Identifier mobility option, however, can be omitted, because the
mobile node can match a corresponding binding update list entry using mobile node can match a corresponding binding update list entry using
the BID. 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 set to zero. For the home agent, the status value can be option MUST be always set to zero.
stored in the Status field of either a Binding Acknowledgement or a
Binding Identifier mobility option. If the status value is specific When the home agent sends a Binding Acknowledgement, the status value
to one of bindings in the bulk registration, the status value MUST be can be stored in the Status field of either a Binding Acknowledgement
stored in the Status field in the corresponding Binding Identifier or a Binding Identifier mobility option. If the status value is
mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the specific to one of bindings in the bulk registration, the status
Status field of the Binding Acknowledgement so that the receiver can value MUST be stored in the Status field in the corresponding Binding
examine the Status field of each Binding Identifier mobility option Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be
for further operations. set to the Status field of the Binding Acknowledgement so that the
receiver can examine the Status field of each Binding Identifier
mobility option for further operations. Otherwise, the status field
of the Binding Identifier mobility option MUST be set to zero and the
home agent status field of the Binding Acknowledgement is used.
6.4. Sending Binding Refresh Request 6.4. 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. If the mobile node had used bulk Binding Refresh Request. The node MAY include multiple Binding
registration, the sender SHOULD include all the Binding Identifier Identifier mobility options if there are multiple bindings that need
mobility options. If the mobile node had not used bulk registration, to be refreshed.
the sender includes the Binding Identifier mobility options only for
those bindings that need to be refreshed.
6.5. Receiving Packets from Mobile Node 6.5. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address 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 silently discarded. The node binding is found, the packets MUST be discarded. The node MUST also
MUST also send a Binding Error message as specified in [RFC-3775]. send a Binding Error message as specified in [RFC-3775]. This
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
multiple care-of addresses. multiple care-of addresses.
8. DSMIPv6 Applicability 8. DSMIPv6 Applicability
skipping to change at page 41, line 11 skipping to change at page 41, line 11
* MCOA PROHIBITED(TBD) * MCOA PROHIBITED(TBD)
* MCOA BULK REGISTRATION NOT SUPPORTED (TBD) * MCOA BULK REGISTRATION NOT SUPPORTED (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 for their discussions and inputs. Thanks to Susumu Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to
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
subject. subject.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 41, line 44 skipping to change at page 41, line 44
January 2005. January 2005.
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
13.2. Informative References 13.2. Informative References
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
K. Kuladinithi, "Motivations and Scenarios for Using Multiple K. Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in draft-ietf-monami6-multihoming-motivation-scenario-03 (work in
progress), May 2008.
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007. Multihoming in Network Mobility Support", RFC 4980, October 2007.
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008.
2007.
[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-v4traversal-01 (work in and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-03 (work in
progress), February 2008. progress), May 2008.
[ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration", Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-01 (work in progress), February draft-lim-mext-multiple-coa-verify-01 (work in progress), February
2008. 2008.
[RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers", [RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers",
draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April
2008. 2008.
skipping to change at page 43, line 17 skipping to change at page 43, line 17
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
Phone: +81-3-5561-8276 Phone: +81-3-5561-8276
Fax: +81-3-5561-8292 Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com Email: ryuji@jp.toyota-itc.com
Vijay Devarapalli
Wichorus
3590 North First St
San Jose, CA 95134
USA
Email: vijay@wichorus.com
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt INRIA Rocquencourt
Domaine de Voluceau B.P. 105 Domaine de Voluceau B.P. 105
Le Chesnay, 78153 Le Chesnay, 78153
France France
Phone: +33-1-39-63-59-30 Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91 Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr Email: thierry.ernst@inria.fr
skipping to change at page 43, line 39 skipping to change at page 44, line 5
Kenichi Nagami Kenichi Nagami
INTEC NetCore Inc. INTEC NetCore Inc.
1-3-3, Shin-suna 1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075 Koto-ku, Tokyo 135-0075
Japan Japan
Phone: +81-3-5565-5069 Phone: +81-3-5565-5069
Fax: +81-3-5565-5094 Fax: +81-3-5565-5094
Email: nagami@inetcore.com Email: nagami@inetcore.com
Vijay Devarapalli
Wichorus
3590 North First St
San Jose, CA 95134
USA
Email: vijay@wichorus.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 36 change blocks. 
94 lines changed or deleted 109 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/