One document matched: draft-ietf-monami6-multiplecoa-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!--
=====
=====
-->
<rfc category="std" ipr="full3978" docName="draft-ietf-monami6-multiplecoa-05.txt">
<!------------------------------------------------>
<!-- Front Section -->
<!------------------------------------------------>
<front>
<title abbrev="MCoA">
Multiple Care-of Addresses Registration
</title>
<!-- AUTHORS -->
<?rfc include="../authors/author-wakikawa.xml" ?>
<?rfc include="../authors/author-ernst.xml" ?>
<?rfc include="../authors/author-nagami.xml" ?>
<?rfc include="../authors/author-devarapalli.xml" ?>
<!-- ADD ENTRY ???: -->
<date month="January" year="2008" />
<area>Internet</area><workgroup>Monami6 Working Group</workgroup>
<abstract>
<t>
According to the current Mobile IPv6 specification, a mobile node
may have several care-of addresses, but only one, termed the primary
care-of address, can be registered with its home agent and the
correspondent nodes. However, for matters of cost, bandwidth, delay,
etc, it is useful for the mobile node to get Internet access through
multiple access media simultaneously, in which case multiple active
IPv6 care-of addresses would be assigned to the mobile node. We
thus propose Mobile IPv6 extensions designed to register multiple
care-of addresses bound to a single Home Address instead of the sole
primary care-of address. For doing so, a new identification number
must be carried in each binding for the receiver to distinguish
between the bindings corresponding to the same Home Address. Those
extensions are targeted to NEMO (Network Mobility) Basic Support as
well as to Mobile IPv6.
</t>
</abstract>
</front>
<middle>
<!------------------------------------------------>
<!-- SECTION 1: INTRODUCTION -->
<!------------------------------------------------>
<section anchor="sec:intro" title="Introduction">
<t>
<!--Permanent Internet connectivity is required by some
applications while a mobile node moves across several access
networks (i.e. ISPs, hotspots, etc). -->
A mobile node may use various types of network interfaces to
obtain durable and wide area network connectivity. The assumed
scenarios and motivations for multiple points of attachment, and
benefits for doing it are discussed at large in
[ID-MOTIVATION].
</t>
<t> IPv6 [RFC-2460] conceptually allows a node to
have several addresses on a given interface. Consequently, Mobile
IPv6 [RFC-3775] has mechanisms to manage multiple
``Home Addresses'' based on home agent's managed prefixes such as
mobile prefix solicitation and mobile prefix advertisement. But
assigning a single Home Address to a node is more advantageous
than assigning multiple Home Addresses because applications do not
need to be aware of the multiplicity of Home Addresses. If
multiple home addresses are available, applications must reset the
connection information when the mobile node changes its active
network interface (i.e. change the Home Address).
</t><t> According to the Mobile IPv6 specification, a mobile node is
not allowed to register multiple care-of addresses bound to a
single Home Address. Since NEMO Basic Support
[RFC-3963] is based on Mobile IPv6, the same issues
apply to a mobile node acting as a mobile router. Multihoming
issues pertaining to mobile nodes operating Mobile IPv6 and mobile
routers operating NEMO Basic Support are respectively
discussed [ID-MIP6ANALYSIS]
and [RFC-4980] in
Monami6 and NEMO Working Group.
</t>
<t> In this document, we thus propose a new identification number
called Binding Identification (BID) number for each binding
cache entry to accommodate multiple bindings registration. The
mobile node notifies the BID to both its Home Agent and
correspondent nodes by means of a Binding Update. Correspondent
nodes and the home agent record the BID into their binding
cache. The Home Address thus identifies a mobile node itself
whereas the BID identifies each binding registered by a mobile
node. By using the BID, multiple bindings can then be
distinguished.
</t>
<!-- A user of a mobile node may be able to bind some policies to
a BID. The policy is used to divide flows to multiple network
interfaces by flow type, port number, or destination address,
etc. How to distribute or configure policies is not within the scope
of this document. There are solutions available in Monami6 WG, for
example <xref target="I-D.soliman-monami6-flow-binding"/>. The goal
of this document is to setup multiple tunnels per care-of address
between mobile node and home agent.
-->
</section> <!-- Intro -->
<!------------------------------------------------>
<!-- SECTION: TERMINOLOGY -->
<!------------------------------------------------>
<section anchor="sec:terminology" title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC-2119].
</t>
<t>
Terms used in this draft are defined
in [RFC-3775], [RFC-3753]
and [RFC-4885]. In addition or in
replacement of these, the following terms are defined or
redefined:
</t>
<t>
<list style="hanging">
<t hangText="Binding Identification number (BID)"/>
<t>
The BID is an identification number used to distinguish
multiple bindings registered by the mobile node. Assignment of
distinct BID allows a mobile node to register multiple binding
cache entries for a given Home Address. The BID MUST be
unique for a binding to a specific care-of address for a given
home address and care-of address pair. The zero value and a
negative value MUST NOT be used. Each BID is generated and
managed by a mobile node. After being generated by the mobile
node, the BID is stored in the Binding Update List and is sent
by the mobile node in the Binding Update. A mobile node MAY
change the value of a BID at any time according to its
administrative policy, for instance to protect its privacy.
An implementation must carefully assign the BID so as to keep
using the same BID for the same binding even when the status
of the binding is changed. More details can be found in
<xref target="sec:assign"/>.
</t>
<!-- The BID is conceptually assigned to a binding in a way it
cannot be duplicated with another BID.-->
<t hangText="Binding Identifier Mobility Option"/>
<t>
The Binding Identifier mobility option is used to carry the BID.
</t>
<t hangText="Bulk Registration"/>
<t> A mobile node can register multiple bindings at once by
sending a single binding update. The mobile node does not
necessarily put all the available care-of addresses in the
binding update, but several care-of addresses. A mobile node
can also replace all the bindings available at the home agent
with the new bindings by using the bulk registration. The
bulk registration is supported only for home registration and
de-registration as explained in
<xref target="sec:deregister"/>. A mobile node MUST NOT
perform bulk registration with correspondent nodes.
</t>
</list>
</t>
</section> <!-- Terminology -->
<!------------------------------------------------>
<!-- SECTION: PROTOCOL OVERVIEW -->
<!------------------------------------------------>
<section anchor="sec:overview" title="Protocol Overview">
<t>
A new identification number (BID) is introduced to distinguish
multiple bindings pertaining to the same Home Address. Once a
mobile node gets several IPv6 global addresses on one or more of
its interfaces, it can register these addresses with its home
agent. If the mobile node wants to register multiple bindings, it
MUST generate a BID for each care-of address and record the BID
into the binding update list. A mobile node can manipulate each
binding independently by using a BID. The mobile node then
registers its care-of addresses by sending a Binding Update with a
Binding Identifier mobility option. The BID MUST be included in the
Binding Identifier mobility option. After receiving such Binding Update
and Binding Identifier mobility option, the home agent MUST copy the
BID from the Binding Identifier mobility option to the corresponding
field in the binding cache entry. Even if there is already an
entry for the mobile node's home address, the home agent MUST
register a new binding entry for the BID stored in the Binding
Identifier mobility option. The mobile node registers multiple care-of
addresses either independently in individual Binding Updates or
multiple at once in a single Binding Update.
</t>
<t>
If the mobile host wishes to register its binding with a
correspondent node, it must perform return routability
operations. The mobile host MUST manage a Care-of Keygen Token per
care-of address. The mobile host exchanges CoTI and CoT for the
corresponding care-of addresses if necessary. When the mobile host
registers several care-of addresses to a correspondent node, it
uses the same BID as the one generated for the home registration's
bindings. The binding registration step is the same as for the
home registration except for calculating authenticator. For
protocol simplicity, the bulk registration is not supported for
correspondent nodes in this document. Return Routability
introduced in [RFC-3775] cannot be easily extended to verify
multiple care-of addresses stored in a single Binding Update.
</t>
<t>
If the mobile node decides to act as a regular mobile node
compliant with [RFC-3775] , it just sends a Binding Update without
any Binding Identifier mobility options. The receiver of the Binding
Update deletes all the bindings registering with a BID and
registers only a single binding for the mobile node. Note that the
mobile node can continue using BID even if only a single binding
is active at some time.
</t>
<t>
When a home agent and a correspondent node check the binding
cache database for the mobile node, they search a corresponding
binding entry with the pair of Home Address and BID of the desired
binding. If necessary, a mobile node can use policy and filter
information to look up the best binding per sessions, flow,
packets, but this is out of scope in this document. If there is no
desired binding, it searches the binding cache database with the
Home Address as specified in Mobile IPv6. The first matched
binding entry may be found, although this is implementation
dependent.
</t>
<t>The mobile node may return to the home link through one its
interfaces. There are three options possible for the mobile node
when its returns home.</t>
<list style="numbers">
<t>The mobile node uses only the interface with which it attaches
to the home link. It de-registers all bindings related to all
care-of addresses. The interfaces which are still attached to
the visited link are not used.</t>
<t>The mobile node uses only the interfaces still attached to the
visited link. The interface with which the mobile node attaches
to the home link is not used.</t>
<t>The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to
the visited links.</t>
</list>
<t> <xref target="sec:returnhome"/> describes the returning home
procedures in more detail.</t>
<!-- <t>When a mobile node wants to return home with interface attached
to the home link, it SHOULD de-register all the bindings by
sending a Binding Update with lifetime set to zero as described in
[RFC-3775] and [RFC-3963]. The mobile node SHOULD NOT include any
Binding Identifier mobility option in this Binding Update. The
receiver deletes all the registered bindings for the home address
from its binding cache database. All the packets are only routed
to the interface attached to the home link. Even if there are
other active interfaces attached to the foreign link, the mobile
node cannot utilize them due to the returning home operation.
</t>
<t>On the other hand, if a mobile node keeps the interfaces attached
to the foreign links active, it disables the interface attached to
the home link and keeps using the rest of interfaces attached to
foreign links. In this case, the mobile node sends a
de-registration Binding Update for the care-of address of the
interface attached to the home link if necessary. All the packets
are routed to one of interfaces attached to the foreign link and
are never routed to the interface attached to the home link. The
mobile node SHOULD disable the interface at the home link. This
scenario is not the most efficient because all the traffic from
and to the mobile node is going through the bi-directional tunnel,
whereas the mobile node is now accessible at one hop from its home
agent.
</t>
<t>A mobile node may want to use all the interfaces, both attached
to the home link and visited links. In this case, there are
additional requirements on the Returning Home procedures.
In [RFC3775], the home agent intercepts packets meant for
the mobile node by proxy NDP while the mobile node is away from
the home link. When the mobile node returns home, the home agent
deletes the binding cache and stop the proxy NDP for the home
address so that a mobile node can configure its home address on
the interface attached to the home link. In this specification, a
mobile node may return home while it keeps several interfaces
attached to the foreign links and continues using them. Therefore,
even though both the mobile node and the home agent need to
intercept packets, the ND states of the home address can be
conflict between the home agent and the mobile node. For
instance, if the proxy ND for the Home Address is stopped by the
home agent, packets are always routed to the interface attached to
the home link and are never routed to the interface attached to
the foreign link. The mobile node sends the binding update with H
flag set for the interface attached to the home link. The detail
operation can be found in <xref target="sec:deregister"/>.-->
<!-- The Home
Agent needs to defend a mobile node's home address by the proxy
NDP for packet interception, while the mobile node defends its
home address by regular NDP to send and receive packets at the
interface attached to the home link.
Two nodes, Home Agent and
Mobile Node, compete ND state. This will causes address
duplication problem at the end. If the proxy neighbor
advertisement for the Home Address is stopped, packets are always
routed to the interface attached to the home link. On the other
hand, packets are never routed to the interface attached to the
home link when the proxy is active.-->
<!-- <t>In the above two cases, a mobile node cannot use interfaces
attached to both home and foreign links simultaneously. If the
proxy NDP is disabled, the main problem can be solved. In the
Multiple Care-of Address Registration, the elimination of Proxy
NDP enables that Mobile Node and Home Agent maintain multiple
bindings for the interfaces attached to the home link and the
foreign links. The mobile node sends the binding update with H
flag set for the interface attached to the home link. The detail
operation can be found in <xref target="sec:deregister"/>.
</t>-->
</section> <!-- Protocol Overview -->
<!------------------------------------------------>
<!-- SECTION: MIP6 EXTENSIONS -->
<!------------------------------------------------>
<section anchor="sec:extensions" title="Mobile IPv6 Extensions">
<t>
This section summarizes the changes to Mobile IPv6 necessary
to manage multiple bindings bound to a same Home Address.
</t>
<!--====================================================-->
<section title="Binding Cache Structure and Binding Update List">
<t>
The BID is required in the binding cache and binding update list
structure. <!--The value MUST be zero if the Binding
identifier does not appear in a Binding Update.-->
</t>
</section><!-- BU Structure & Management -->
<!--====================================================-->
<section anchor="sec:format" title="Message Format Changes">
<section title="Binding Identifier Mobility Option">
<t>
The Binding Identifier mobility option is included in the
Binding Update, Binding Acknowledgment, Binding Refresh
Request, and Care-of Test Init and Care-of Test message.
</t>
<figure anchor="fig:bid_so" title="BID Mobility Option">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |C|O|H|D|Resrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
</artwork>
</figure>
<list style="hanging">
<t hangText="Type"></t>
<t>Type value for Binding Identifier is TBD</t>
<t hangText="Length"></t>
<t> 8-bit unsigned integer. Length of the option, in octets,
excluding the Type and Length fields. MUST be set to 4 when
the 'C' flag is unset. Otherwise, the Length value MUST be
set to either 8 or 20 depending on the 'D' (DSMIPv6) flag.
</t>
<t hangText="Binding ID (BID)"></t>
<t> The BID which is assigned to the binding carried in the
Binding Update with this mobility option. BID is 16-bit unsigned
integer. A value of zero is reserved.
</t>
<t hangText="Status"></t>
<t> When the Binding Identifier mobility option is included
in a Binding Acknowledgment, this field overwrites the
status field correspondent to each binding in the Binding
Acknowledgment. If this field is zero, the receiver MUST use
the registration status stored in the Binding Acknowledgment
message. This Status field can be used to carry error
information for a Care-of Test message. The status is 8-bit
unsigned integer. The possible status codes are the same as
the status codes of Binding Acknowledgment.
</t>
<t hangText="Care-of address (C) flag"></t>
<t> When this flag is set, a mobile node can store a Care-of
Address corresponding to the BID in the Binding Identifier
mobility option. This flag MUST be used whenever a mobile node
sends multiple care-of addresses in a single Binding Update,
i.e. bulk registration. It MUST be also used for the
independent binding registration as a substitute for an
alternate care-of address option. This flag is valid only
for binding update sent to the home agent.
</t>
<t hangText="Overwrite (O) flag"></t>
<t> When this flag is set, a mobile node requests a home agent
to replace all the bindings to binding entries stored in a
Binding Update. This flag is valid only for binding update
sent to the home agent.
</t>
<t hangText="Simultaneous Home and Foreign Binding (H) flag"></t>
<t> This flag indicates that the mobile node registers multiple
bindings to the home agent while is attached to the home
link. This flag is valid only for a binding update sent to the
home agent.
</t>
<t hangText="DSMIPv6 (D) flag"></t>
<t> This flag indicates that the care-of address field MUST be
set to IPv4 care-of address. If this flag is set, the
Care-of Address field MUST be used.
</t>
<t hangText="Reserved"></t>
<t>5 bits Reserved field. Reserved field MUST be set with all
0.</t>
<t hangText="Care-of Address"></t>
<t>This field has the variable length depending on the
specified flags. When C flag is set and D flag is unset, an
IPv6 Care-of Address matched to the BID is stored in this
field. If both C and D flags are set, an IPv4 Care-of
Address is stored. This field MUST NOT be used if a Binding
Identifier mobility option is included in any other messages
than a Binding Update message. The receiver SHOULD ignore
this field if the mobility option is not presented in
Binding Update message. </t>
</list>
</section>
</section>
<section title="New Status Values for Binding Acknowledgment">
<t>
New status values for the status field in a Binding
Acknowledgment are defined for handling the multiple Care-of
Addresses registration:
<list style="hanging">
<t hangText="MCOA NOTCOMPLETE (TBD < 128)"/>
<t>In bulk registration, not all the binding identifier
mobility option are successfully registered. Some of them are
rejected. The error status value of the failed mobility option is
individually stored in the status field of the binding
identifier mobility option.</t>
<t hangText="MCOA RETURNHOME WO/NDP (TBD < 128)"/>
<t>When a mobile node returns home, it MUST NOT use NDP for
the home address on the home link. The detail can be found
in <xref target="sec:returnhome"/></t>
<t hangText="MCOA MALFORMED (TBD more than 128)"/>
<t>Registration failed because Binding Identifier
mobility option is not formed correctly.</t>
<t hangText="MCOA BID CONFLICT (TBD more than 128)"/>
<t> The home agent cannot cache both a regular binding and a
BID extended binding simultaneously. It returns this status
value when the received binding conflicts with the
existing binding cache entry(ies).</t>
<t hangText="MCOA PROHIBITED(TBD more than 128)"/>
<t> It implies the multiple care-of address registration is
administratively prohibited. </t>
<t hangText="MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)"/>
<t> The bulk binding registration is not supported.</t>
<!-- <t hangText="MCOA FLAG CONFLICTS (TBD)"/>
<t> The flags of the mobility options presented in a Binding
Identifier mobility options conflicts. </t>-->
</list>
</t>
</section><!-- BA-->
</section><!-- MIP6 Extensions-->
<!-------------------------------------------------------->
<!-- SECTION: MN OPERATION -->
<!-------------------------------------------------------->
<section title="Mobile Node Operation" anchor="sec:op-mn">
<!--====================================================-->
<section anchor="sec:assign" title="Management of Care-of Addresses and Binding Identifier">
<t>
There are two cases when a mobile node has several Care-of
Addresses. Note that a mixture of the two cases are possible.
</t>
<list style="numbers">
<t>
A mobile node uses several physical network interfaces and
acquires a care-of address on each of its interfaces.
</t>
<t>
A mobile node uses a single physical network interface, but
multiple prefixes are announced on the link the interface is
attached to. Several global addresses are configured on this
interface for each of the announced prefixes.
</t>
</list>
<t>
The difference between the above two cases is only a number of
physical network interfaces and therefore does not matter in
this document. The Identification number is used to identify a
binding. To implement this, a mobile node MAY assign an
identification number for each care-of addresses. How to assign
an identification number is implementation specific, but the
following rules MUST be followed.
</t>
<t>
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 unique for a binding to a specific care-of address
for a given home address and care-of address pair. The value
should be generated from a value comprised between 1 to
65535. Zero and negative values MUST NOT be used as a BID. If a
mobile node has only one care-of address, the assignment of a
BID is not needed until it has multiple care-of addresses to
register with.
</t>
</section>
<section anchor="sendCoT" title="Return Routability: Sending CoTI and Receiving CoT">
<t>When a mobile node wants to register bindings to a
Correspondent Node, it MUST have the valid care-of Keygen token
per care-of address, while the HoTI and HoT can be exchanged
only once for a Home Address.</t>
<t>If the Mobile Node manages bindings with BID, it MUST include a
Binding Identifier mobility option in a Care-of Test Init
message. It MUST NOT set the any flags in the mobility option. The
receiver (i.e. correspondent node) will calculate a care-of
Keygen token as specified in [RFC-3775] and reply
a Care-of Test message and the Binding Identifier
mobility option as described in <xref target="sec:recvCoTI"/>. When
the mobile node receives the Care-of Test message, the Care-of
Test message is verified as same as in
[RFC-3775]. If a Binding Identifier
mobility option is not presented in CoT in reply to the CoTI
containing the Binding Identifier mobility option, the
correspondent node does not support the Multiple Care-of Address
registration. Thus, the mobile node MUST NOT use a Binding
Identifier mobility option in the future Binding Update. The
Mobile Node MAY skip re-sending regular CoTI message and keep the
received care-of Keygen token for the regular Binding Update,
because the correspondent node just ignores and skip the Binding
Identifier mobility option and calculates the care-of Keygen
token as [RFC-3775] specified.</t>
<!-- <t>If the status field of a Binding Identifier mobility option
is set to [MCOA MALFORMED], the received care-of keygen
token MUST NOT be used for sending a Binding Update. It MUST
re-send a Care-of Test Init message again with a corrected
Binding Identifier mobility option which C flag MUST be
unset.</t>
<t>If the status field is set to less than 128, it sends a
Binding Update through Return Routability procedure.</t>
</list>-->
<!-- <t>The computation of MAC is the same as the one in
[RFC-3775] except for calculation of a care-of
keygen token. The calculation of a care-of keygen token is
modified as follows. BID is used to generate the care-of keygen
token. </t>
<t>care-of keygen token :=
First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | BID | 1)))</t>-->
</section>
<!--====================================================-->
<section anchor="sendBU" title="Binding Registration">
<t>
When a mobile node sends a Binding Update, it MUST decide
whether it registers multiple care-of addresses or not. However,
how this decision is taken is out-of scope in this document. If
a mobile node decides not to register multiple care-of
addresses, it completely follows the RFC3775 specification.
</t>
<t> For the multiple Care-of Addresses registration, the mobile
node MUST include a Binding Identifier mobility option(s) in
the Mobility Option field of a Binding Update as shown in
<xref target="fig:bu-mcoa"/>. The BID is copied from a
corresponding Binding Update List entry to the BID field of the
Binding Identifier mobility option. When ESP is used for
binding update, the care-of address MUST be stored in the
Care-of Address field by setting C flag as a substitute for the
alternate care-of address option. The alternate care-of address
option MUST be omitted. Additionally for binding registration to
a correspondent node, the mobile node MUST have both active home
and care-of Keygen tokens for Kbm (see Section 5.2.5 of
[RFC-3775]). The care-of Keygen tokens MUST be
maintained for each care-of address that the mobile node wants
to register to the correspondent node, as described in
<xref target="sendCoT"/>. After computing an Authenticator value
for the Binding Authorization mobility option, it sends a Binding
Update which contains a Binding Identifier
mobility option. The Binding Update is protected by a Binding
Authorization Data mobility option placed after the Binding
Identifier mobility option.
</t>
<figure anchor="fig:bu-mcoa" title="Binding Update for Binding Registration">
<artwork>
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header (for home registration)
Mobility header
-BU
Mobility Options
- Binding Identifier mobility option
- Binding Authorization mobility option
(for Route Optimization)
</artwork>
</figure>
<!-- <t>The Mobile Node MUST NOT set any flags in the Binding
Identifier mobility option for the binding individual registration.</t>-->
</section>
<section anchor="sec:bulk_reg" title="Binding Bulk Registration">
<t> The bulk registration is an optimization for registering
multiple care-of addresses only to a home agent by using a
single Binding Update. If a mobile node, for instance, does not
want to send a lot of control messages through an interface
which bandwidth is scarce, it can use this bulk registration and
send a Binding Update containing multiple or all the valid
care-of addresses.
</t>
<t>A mobile node sets the C flag in a Binding Identifier
mobility option and includes the particular care-of address in the
Binding Identifier mobility option. The mobile node stores
multiple sets of a Binding Identifier mobility option in a
Binding Update as shown in <xref target="fig:bu-bulk"/>.
<!-- When multiple Binding Identifier mobility options are presented in a
Binding Update, the flag field of all the mobility options MUST have
the same value.
For example, if C flag is set, the same
flag MUST be set to all the mobility options. Otherwise, the mobile
node will receive errors [MCOA MALFORMED] by a Binding
Acknowledgment. -->
In the bulk registration, all the other binding
information such as Lifetime, Sequence Number, binding Flags are
shared among the bulked Care-of Addresses. The alternate care-of
address option MUST be omitted when ESP is used to protect a
binding update. </t>
<t>In the bulk registration, the Sequence Number field of a
Binding Update SHOULD be carefully configured. This is because
all the bulk-registered bindings uses the same Sequence Number
specified in the Binding Update. If each binding uses different
sequence number, a mobile node MUST use the largest sequence
number from the binding update list used for the bulk
registration. If it cannot select a sequence number for all the
bindings due to sequence number out of window, it MUST NOT use
the bulk registration for the binding which sequence number is
out of window and uses a separate Binding Update for the
binding. </t>
<figure anchor="fig:bu-bulk" title="Binding Update for Binding Bulk Registration">
<artwork>
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier mobility options
(C flag is set, O flag is optional,
BID and CoA are stored)
</artwork>
</figure>
<t>If the mobile node wants to replace existing registered
bindings on the home agent with the bindings in the sent Binding
Update, it can set O flag. <xref target="sec:recv_bu"/>
describes this registration procedure in detail. </t>
</section>
<!--====================================================-->
<section anchor="sec:deregister" title="Binding De-Registration">
<t> When a mobile node decides to delete all the bindings for its
home address at a visiting network, it simply sends a regular
de-registration Binding Update which lifetime is set to zero. A
Binding Identifier mobility option is not required. </t>
<t>If a mobile node wants to delete a particular binding(s) from
its home agent and correspondent nodes (e.g. from foreign link),
the mobile node simply sets zero lifetime for the sending
binding update. The Binding Update MUST contain an appropriate
Binding Identifier mobility option(s). The receiver will
remove only the care-of address(es) that matches to the
specified BID. For the bulk de-registration, the care-of
addresses field of each mobility option SHOULD be omitted, because
the receiver will remove all the care-of addresses matching
the specified BID.
</t>
</section>
<section anchor="sec:returnhome" title="Returning Home">
<t>The mobile node may return to the home link, by attaching to the
home link through one of the interfaces on the mobile node. When
the mobile node wants to return home, it should be configured with
what interface it needs to use. The mobile node may use only the
interface with which it is attached to the home link, only the
interfaces still attached to the visited link or use both
interfaces attached to the home link and visited link
simultaneously. The following describes each option in more
detail.</t>
<section title="Using only Interface attached to the Home Link">
<t>The mobile node returns home and de-registers all the bindings
as shown in <xref target="fig:ex-2"/>. How to de-register all
the bindings is the same as binding de-registration from foreign
link described in <xref target="sec:deregister"/>. All the
packets routed by the home agent are only forwarded to the
interface attached to the home link, even if there are other
active interfaces attached to the visited link. While the
mobile node de-registers all the bindings from the home agent,
it may continue registering bindings for interface attached to
visited link to the correspondent node as shown in
<xref target="fig:ex-2"/>. These bindings at correspondent node
MUST be created before a mobile node returns home.</t>
</section>
<section title="Using only Interface attached to the Visited Link">
<t>The mobile node returns home and shutdown the interface
attached to the home link as shown in <xref target="fig:ex-3"/>.
The binding of the home attached interface MUST be deleted by
sending a de-registration binding update from one of active
interface attached to the foreign links. This scenario is not the
most efficient because all the traffic from and to the mobile node
is going through the bi-directional tunnel, whereas the mobile
node is now accessible at one hop from its home agent.</t>
</section>
<section title="Simultaneous Home and Visited Link Operation">
<t>The mobile node returns home and continues using all the
interfaces attached to both foreign and home links as shown in
<xref target="fig:ex-5"/>. The mobile node indicates this by
setting the 'H' flag in the BID mobility option. There are
additional requirements on the Returning Home procedures for
possible ND conflicts at the home link described below.</t>
<t>In [RFC3775], the home agent intercepts packets meant for the
mobile node using proxy NDP while the mobile node is away from
the home link. When the mobile node returns home, the home agent
deletes the binding cache and stop the proxy NDP for the home
address so that a mobile node can configure its home address on
the interface attached to the home link. In this specification,
a mobile node may return home while it keeps several interfaces
attached to the foreign links and continues using them.
Therefore, even though both the mobile node and the home agent
need to intercept packets, the ND states of the home address can
conflict between the home agent and the mobile node. For
instance, if the proxy ND for the Home Address is stopped by the
home agent, packets are always routed to the interface attached
to the home link and are never routed to the interface attached
to the foreign link. It is required to avoid this ND conflicts
in the case of the simultaneous home and foreign attachment.</t>
<t>In this specification, the home agent MUST intercept all the
packets meant for the mobile node and decide whether to send the
traffic directly to the home address on the link or tunnel to
the care-of address. The home agent would make this decision
based on the type of packets and flows. How to make this
decision is out of scope in this document. The delicate part
would be to create a neighbor cache entry for the mobile node so
that the home agent can deliver the packets on-link. The home
agent would need to know the Layer-2 address of the interface
with which the mobile node is attached to the home link. In
order to create the neighbor cache entry for the mobile node,
following operations are required.</t>
<t>The mobile node sends a de-registration binding update to the
home agent from the interface attached to the home link. In the
Binding Update, the BID mobility option must be stored for the
BID assigned to the interface. The H flag MUST be set in the
BID mobility option. When the H flag is appears, the home agent
learns and remembers that the mobile node wants to continue
using interfaces attached to both foreign and home links. If H
flag is unset, the home agent deletes either all the bindings or
the binding corresponding to the BID.</t>
<t>When the home agent sends the Binding Acknowledgment, it MUST
store one of two status values such as [Binding Update Accepted
(0)] [MCOA RETURNHOME WO/NDP (TBD)] in the BID mobility option
depending on home agent configuration at the home link. The new
values are:</t>
<list style="symbols">
<t>Binding Update Accepted (0): NDP is permitted for the home
address at the home link. This is regular returning home
operation of [RFC3775]</t>
<t>MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link</t>
</list>
<t>When the home agent is the only router at the home link, it can
intercept all the packets by IP routing without proxy NDP. It
stops proxy ND for the requested home address and replies the
[Binding Update Accepted] value to the mobile node. The
neighbor cache entry for the mobile node is created by the
regular NDP operation (i.e. NS/NA exchange). On the other
hand, if the home agent is not the only router, it MUST continue
defending the home address by proxy NDP to capture all the
mobile node's traffic. The home agent, then, returns [MCOA
RETURNHOME WO/NDP] value in the Status field of the BID mobility
option. The home agent also learns the mobile node's layer-2
address (i.e. MAC address) during this binding de-registration.
It keeps the learned layer-2 address as the neighbor cache entry
for the mobile node so that it can construct the layer-2 header
for the packets meant for the mobile node and forwards them
directly to the mobile node's interface attached to the home
link.</t>
<t>According to [RFC3775], the mobile node MUST NOT assign the
home address to the interface attached to the home link and MUST
NOT attempt NDP operations for the home address before the
completion of binding de-registration. It MUST NOT send and
reply to Neighbor Solicitation for the home address. The home
address MUST be tentative address at this moment until it
receives Binding Acknowledgment with success status value.</t>
<t>When the mobile node receives the binding acknowledgment and
BID mobility option, it assigns home address at the interface
attached to the home link according to the status field of the
BID. If the value is [Binding Update Accepted], the mobile node
can start defending the home address using NDP. The home agent
can create neighbor cache entry for the mobile node by NS and NA
exchange as normal IPv6 operation.</t>
<t>If the home agent receives the [MCOA RETURNHOME WO/NDP], it
MUST NOT defends its home address at the home link by NDP. When
the mobile node sends packets from the interface attached to the
home link, it MUST learn the layer2 address (i.e. MAC address)
of the next hop (i.e. default router, it can be home agent)
during the binding de- registration and construct the packet
including layer 2 header with the learned home agent's layer-2
address.</t>
</section>
<!-- <t>When a mobile node wants to return home with interface attached
to the home link, it SHOULD de-register all the bindings by
sending a Binding Update with lifetime set to zero as described in
[RFC-3775] and [RFC-3963].
</t>
<list style="numbers">
<t>A mobile node returns home and de-registers all the bindings
as shown in <xref target="fig:ex-2"/>. How to de-register all
the bindings is the same as binding de-registration from
foreign link described in <xref target="sec:deregister"/>.
All the packets routed by the home agent are only reached to
the interface attached to the home link due to binding
de-registration, even if there are other active interfaces
attached to the foreign link. While the mobile node
de-registers all the bindings from the home agent, it continue
registering bindings for interface attached to foreign link to
the correspondent node as shown in
<xref target="fig:ex-2"/>. These bindings at correspondent
node MUST be created before a mobile node returns home.</t>
<t>A mobile node returns home and shutdown the interface
attached to the home link as shown in
<xref target="fig:ex-3"/>. The binding of the home attached
interface MUST be deleted by sending a de-registration binding
update from one of active interface attached to the foreign
links. This scenario is not the most efficient because all the
traffic from and to the mobile node is going through the
bi-directional tunnel, whereas the mobile node is now
accessible at one hop from its home agent. </t>
<t>A mobile node returns home and continues using all the
interfaces attached to both foreign and home links as shown in
<xref target="fig:ex-5"/>. There are additional requirements
on the Returning Home procedures for possible ND conflicts at
the home link described below.
</t>
</list>
<t>In [RFC3775], the home agent intercepts packets meant for the
mobile node by proxy NDP while the mobile node is away from the
home link. When the mobile node returns home, the home agent
deletes the binding cache and stop the proxy NDP for the home
address so that a mobile node can configure its home address on
the interface attached to the home link. In this specification,
a mobile node may return home while it keeps several interfaces
attached to the foreign links and continues using
them. Therefore, even though both the mobile node and the home
agent need to intercept packets, the ND states of the home
address can be conflict between the home agent and the mobile
node. For instance, if the proxy ND for the Home Address is
stopped by the home agent, packets are always routed to the
interface attached to the home link and are never routed to the
interface attached to the foreign link. It is required to avoid
this ND conflicts in the case of the simultaneous home and
foreign attachment (i.e. third operation). </t>
<t>In this specification, the home agent MUST intercept all the
packets meant for the mobile node and would decide whether to
send the traffic directly to the home address on the link or
tunnel to the care-of address that the mobile node has
registered at the home agent. The home agent would make this
decision based on the type of packets and flows. How to make
this decision is out of scope in this document. The delicate
part would be to create a neighbor cache entry for the mobile
node so that the home agent can deliver the packet on-link. The
home agent would need to know the Layer-2 address of the
interface with which the mobile node is attached to the home
link. In order to create the neighbor cache entry for the
mobile node, following operations are required.</t>
<t>The mobile node sends a de-registration binding update to the
home agent from the interface attached to the home link. In the
Binding Update, the BID mobility option must be stored for the
BID assigned to the interface. The H flag MUST be set in the BID
mobility option. When the H flag is appeared, the home agent
learns and remembers that the mobile node continue using
interfaces attached to both foreign and home links. If H flag
is unset, the home agent deletes either all the bindings or the
binding corresponding to the BID (i.e. scenario 1 or 2).</t>
<t>When the home agent sends the Binding Acknowledgment, it MUST
store one of two status values such as [Binding Update Accepted
(0)] [MCOA RETURNHOME WO/NDP (TBD)] in the BID mobility option
depending on home agent configuration at the home link. The new
values are:
<list style="symbols">
<t>Binding Update Accepted (0): NDP is permitted for the home
address at the home link. This is regular returning home
operation of [RFC3775]</t>
<t>MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the
home address at the home link</t>
</list>
</t>
<t>When the home agent is the only router at the home link, it can
intercept all the packets by IP routing without proxy NDP. It
stops proxy ND for the requested home address and replies the
[Binding Update Accepted] value to the mobile node. The neighbor
cache entry for the mobile node is created by the regular NDP
operation (i.e. NS/NA exchange). On the other hand, if the home
agent is not solo router, it MUST continue defending the home
address by proxy NDP to capture all the mobile node's
traffic. The home agent, then, returns [MCOA RETURNHOME WO/NDP]
value in the Status field of the BID mobility option. The home agent
also requires to learn the mobile node's layer-2 address
(i.e. MAC address) during this binding de-registration. It
keeps the learned layer-2 address as the neighbor cache entry
for the mobile node so that it can construct the Ethernet header
for the packets meant for the mobile node and forwards them
directly to the mobile node's interface attached to the home
link.</t>
<t>According to [RFC3775], the mobile node MUST NOT assign the
home address to the interface attached to the home link and MUST
NOT attempt NDP operations for the home address before the
completion of binding de-registration. It MUST NOT send and
reply to Neighbor Solicitation for the home address. The home
address MUST be tentative address at this moment until it
receives Binding Acknowledgment with success status value.</t>
<t>When it receives the binding acknowledgment and BID mobility
option, it assigns home address at the interface attached to the
home link according to the status field of the BID. If the value
is [Binding Update Accepted], it can start defending home
address by NDP as a regular IPv6 operation and makes the home
address as a valid IPv6 address. The home agent can create
neighbor cache entry for the mobile node by NS and NA exchange
as the regular IPv6.</t>
<t>If the home agent receives the [MCOA RETURNHOME WO/NDP], it
MUST NOT defends its home address at the home link by NDP. When
the mobile node sends packets from the interface attached to the
home link, it MUST learn the layer2 address (i.e. MAC address)
of the next hop (i.e. default router, it can be home agent)
during the binding de-registration and construct the packet
including Ethernet header with the learned home agent's layer-2
address.</t>-->
<!-- <t>
When a mobile node returns home, it SHOULD de-register all
bindings with the home agent by sending a regular
de-registration binding update to flush all the registered
bindings. However, there are several scenarios for returning
home described in <xref target="ap:scenario"/>
(<xref target="fig:ex-2"/>, <xref target="fig:ex-3"/>,
<xref target="fig:ex-4"/>). We have discussed this feature in
Monami6 working group now. This part might be updated in the
next revision.
</t>
<t>
As shown in <xref target="fig:ex-2"/> in
<xref target="ap:scenario"/>, a mobile node de-registers all the
binding from the home agent, while it MAY still keep the
bindings of the other interface active attached to foreign links
only at the Correspondent Nodes. By doing this, the mobile node
still receives packets from the Correspondent Node at the
interface attached to a foreign link thanks to route
optimization. If the correspondent nodes does not use route
optimization, the mobile node receives such packets at the
interface attached to the home link.
</t>
<t>In <xref target="fig:ex-3"/>, a mobile node does not want to
return home even if one of interfaces is attached to the home
link. The mobile node MUST disable the interface attached to the
home link. Otherwise, address duplication will be observed
because the home agent still defend the Home Address by the
proxy neighbor advertisement and the mobile node also enables
the same Home Address on the home link. After disabling the
interface attached to the home link, the mobile node MUST delete
the binding for the disabled interface by sending a
de-registration binding update. The de-registration binding
update is sent from one of active interfaces attached to foreign
links. As a result, the mobile node no longer receives packets
at the interface attached to the home link. All packets are
routed to other interfaces attached to a foreign link.
</t>
<t>Alternatively, the Mobile Node may choose to activate both the
interfaces attached to the home link and the foreign link, and
communicates with all of the interfaces. The Mobile Node
notifies the Home Agent using the H flag which means the Mobile
Node is attached to the home link. The Mobile Node may notify
the care-of address of the interface(s) attached to the foreign
link(s) in the same message using bulk registration. The Home
Agent then no longer uses Proxy Neighbor Advertisement to
intercept packets and the Mobile Node can utilize both of
interfaces attached to the home link and the foreign link
simultaneously. The Home Agent can intercept packets by IP
routing, but not by proxy Neighbor Discovery. The detailed
operation of no NDP operation can be found in [ID-NONDP].</t>
<t>When the Mobile Node returns home, it de-registers a binding
for the interface. While the bindings for the interfaces
attached to the foreign link are still active. Intercepting
packets, the Home Agent can decide whether it tunnels to the
foreign interface or routes to the home interface of the Mobile
Node. To do so, the Home Agent must know that the Mobile Node
is back to the home link. However, if the binding is deleted,
there is no way for the Home Agent to know that the Mobile Node
is at the home, too. The Home Agent SHOULD invalidate the
binding for the interface attached to the home link and MAY NOT
delete it. It can alternatively mark that the Mobile Node is at
the home link, too. As an example, the Home Agent inserts the
Home Address of the Mobile Node in the Care-of Address field of
the Mobile Node. The binding is named "Home Binding" in this
documentation. The Home Agent MAY manage this home binding as
same as the other binding entry in terms of lifetime validation,
etc. The Mobile Node MAY send multiple binding de- registration
to keep this home binding active. Alternatively, the Home Agent
can use infinity lifetime for the lifetime of the home binding.
When the Mobile Node leaves the Home Link, it can update the
home binding to the normal binding. Before that, the Home Agent
believes the Mobile Node is at the home and may route packets
for the Mobile Node to the Home Link.</t>-->
</section>
<!--====================================================-->
<section anchor="sec:recv_ba" title="Receiving Binding Acknowledgment">
<t>
The verification of a Binding Acknowledgment is the same as
Mobile IPv6 (section 11.7.3 of [RFC-3775]). The operation for
sending a Binding Acknowledgment is described in
<xref target="sec:recv_bu"/>.
</t>
<t>If a mobile node includes a Binding Identifier
mobility option in a Binding Update with A flag set, a Binding
Acknowledgment MUST carry a Binding Identifier mobility option
in the Mobility Options field. If no such mobility option is included
in the Binding Acknowledgment replied to the Binding Update for
the multiple care-of address registration, this indicates that
the originator node of this Binding Acknowledgment might not
recognize the Binding Identifier mobility option. The mobile
node SHOULD stop registering multiple care-of addresses by using
a Binding Identifier mobility option.
</t>
<t> If a Binding Identifier mobility option is present in the
received Binding Acknowledgment, the mobile node checks the
registration status for the Care-of address(es). The status
value MUST be retrieved as follows. If the status value in the
Binding Identifier mobility option is zero, the mobile node
uses the value in the Status field of the Binding
Acknowledgment. Otherwise, it uses the value in the Status field
of the Binding Identifier mobility option. </t>
<t>If the status code is greater than or equal to 128, the mobile
node starts relevant operations according to the error
code. Otherwise, the originator (home agent or correspondent
node) successfully registered the binding information and BID
for the mobile node.
</t>
<list style="symbols">
<t> If the Status value is [MCOA PROHIBITED], the mobile node
MUST give up registering multiple bindings to the peer sending
the Binding Acknowledgment. It MUST return to the regular
Mobile IPv6 [RFC-3775] for the peer node. </t>
<t>If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT],
the mobile node SHOULD stop using bulk registration to the
peer sending the Binding Acknowledgment. </t>
<t>If [MCOA MALFORMED] is specified, it indicates that the
binding identifier mobility option is formatted wrongly. For
example, if the C flag is
set, all mobility options MUST have C flag. It is same for O
flag. How to handle other error status codes is specified in
[RFC-3775].</t>
<t>If [MCOA BID CONFLICT] is specified, the binding entry
specified by the Binding Identifier mobility option is
already registered as a regular binding. In such case, the
mobile node SHOULD stop sending Binding Updates with BID, or
SHOULD use O flag for the peer to reset all the registered
bindings.</t>
</list>
</section>
<!--====================================================-->
<section title="Receiving Binding Refresh Request">
<t>
The verification of a Binding Refresh Request is the same as in
Mobile IPv6 (section 11.7.4 of [RFC-3775]). The operation of
sending a Binding Refresh Request is described in section
<xref target="sec:sending_brr"/>.
</t>
<t>
If a mobile node receives a Binding Refresh Request with a
Binding Identifier mobility option, this Binding Refresh
Request requests a new binding indicated by the BID. The mobile node
SHOULD update only the respective binding. The mobile node MUST
put a Binding Identifier mobility option into the Binding
Update sent to refresh the entry.
</t>
<t>
If no Binding Identifier mobility option is present in a
Binding Refresh Request, the mobile node sends a Binding Update
according to its Binding Update List. On the other hand, if the
mobile node does not have any Binding Update List entry for the
requesting node, the mobile node needs to register either a
single binding or multiple bindings depending on its binding
management policy.
</t>
</section>
<!--====================================================-->
<section title="Sending Packets to Home Agent">
<t>When a multihomed mobile node sends packets to its home agent,
there are conceptually two ways to construct packets.</t>
<list style="numbers">
<t>Using Home Address Option. (required additional 24 bytes)</t>
<t>Using IPv6-IPv6 tunnel. (required additional 40 bytes)</t>
</list>
<t>Beside the additional size of packets, no difference is
observed between these two. The routing path is always the same
and no redundant path such as dog-leg route occurs. However, in
this document, the mobile node is capable of using multiple
care-of addresses for outgoing packets. This is problem in home
agent side because they must verify the Care-of address for all
the packets received from the mobile node (i.e. ingress
filtering). When it uses the Home Address option, the home
agent MAY check the care-of address in the packet with the
registering binding entries. This causes additional overhead to
the home agent. Therefore, the mobile node SHOULD use the
bi-directional tunnel even if it registers a binding(s) to the
home agent.
</t>
</section>
<section anchor="bootstrapping" title="Bootstrapping">
<t>When a mobile node bootstraps and registers multiple bindings
at the first time, it SHOULD set O flag in the Binding
Identifier mobility option. If old bindings still exists at the Home
Agent, the mobile node has no way to know which bindings are still
remained at the home agent.
This scenario happens when a mobile node
reboots without correct de-registration. If O flag is used, all
the bindings are replaced to the new binding(s). Thus, the
garbage bindings are surely replaced by new bindings registered
with the first Binding Update. If the mobile node receives the
Binding Acknowledgment with the status code set to 135 [Sequence
number out of window], it MUST retry sending a Binding Update
with the last accepted sequence number which is notified by the
Binding Acknowledgment.
</t>
<t>For Correspondent nodes, the mobile node cannot use the O flag
because of no bulk registration support. Thus, if necessary, it
MUST sends a regular binding first to overwrite the remaining
bindings at the correspondent node. Then, it can re-register the
set of bindings by using Multiple Care-of Address Registration.</t>
</section>
</section> <!-- MN Operation -->
<!-------------------------------------------------------->
<!-- SECTION: CN & HA OPERATION -->
<!-------------------------------------------------------->
<section title="Home Agent and Correspondent Node Operation">
<!--====================================================-->
<section title="Searching Binding Cache with Binding Identifier">
<t>
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 the bindings to communicate with the mobile node.
How to select the most suitable binding from the binding cache
database is out of scope in this document.
</t>
<t>
Whenever a correspondent node searches a binding cache for a
home address, it SHOULD uses both the Home Address and the BID
as the search key if it knows the corresponding BID. In the
example below, if a correspondent node searches the binding with
the Home Address and BID2, it gets binding2 for this mobile
node.
</t>
<figure anchor="fig:bs-search" title="Searching the Binding Cache">
<artwork>
binding1 [a:b:c:d::EUI, care-of address1, BID1]
binding2 [a:b:c:d::EUI, care-of address2, BID2]
binding3 [a:b:c:d::EUI, care-of address3, BID3]
</artwork>
</figure>
<t>
A correspondent node basically learns the BID when it receives a
Binding Identifier mobility option. At the time, the
correspondent node MUST look up its binding cache database with
the Home Address and the BID retrieved from the Binding Update. If the
correspondent node does not know the BID, it searches for a binding
with only a Home Address as performed in Mobile IPv6. In such
case, the first matched binding is found. But which binding entry
is returned for the normal search depends on implementations. If
the correspondent node does not desire to use multiple bindings
for a mobile node, it can simply ignore the BID.
</t>
</section>
<section anchor="sec:recvCoTI" title="Receiving CoTI and Sending CoT">
<t>When a correspondent node receives a CoTI message
which contains a Binding Identifier mobility option, it MUST
process it with following steps.</t>
<t>First of all, the CoTI message is verified according to
[RFC-3775]. The Binding Identifier
mobility option MUST be, then, processed as follows:</t>
<list style="symbols">
<t>If a correspondent node does not understand a Binding
Identifier mobility option, it just ignores and skip this
option. The calculation of a care-of Keygen token will thus be
done without a BID value. The correspondent node returns a CoT
message without a Binding Identifier mobility option. The
mobile node can thus know whether the correspondent can
process the Binding Identifier mobility option or not, by
checking if such option is present in the CoT message.</t>
<t>If either or both C and O flag is set in the mobility option, the
Correspondent Node SHOULD NOT calculate a care-of Keygen token
and MUST include a Binding Identifier mobility option which
status value set to [MCOA MALFORMED] in the returned Care-of
Test message. </t>
<t>Otherwise, the correspondent node MUST include a Binding
Identifier mobility option which status value MUST be set to
zero in the returning a CoT message.</t>
<t>All the Binding Identifier mobility options SHOULD be
copied from the received one except for the Status Field for
CoT. The Care-of address field of each Binding
Identifier mobility option, however, can be omitted, because the
mobile node can match a corresponding binding update list by
using BID.</t>
</list>
</section>
<!--====================================================-->
<section anchor="sec:recv_bu" title="Processing Binding Update">
<t>
If a Binding Update does not contain a Binding Identifier
mobility option, its processing is same as in [RFC-3775]. But if the
receiver already has multiple bindings for the home address, it
MUST replace all the existing bindings by the received
binding. As a result, the receiver node MUST have only a binding
for the mobile node. If the Binding Update is for
de-registration, the receiver MUST delete all existing bindings
from its Binding Cache.
</t>
<t>
If a Binding Update contains a Binding Identifier
mobility option(s), it is validated according to section 9.5.1
of [RFC-3775] and the following step.</t>
<list style="symbols">
<t>If the home registration flag is set in the Binding Update,
the home agent MUST carefully operate Duplicate Address
Detection (DAD) for the received Home Address. If the home
agent has already had a binding(s) for the Mobile Node, it
MUST avoid running DAD check when it receives the Binding
Update.
</t>
</list>
<t> The receiver node MUST process the Binding Identifier
mobility option(s) in the following steps. When a correspondent
node sends a Binding Acknowledgment, the status value MUST be
always stored in the Status field of the Binding
Acknowledgment and keep the Status field of Binding
Identifier mobility option to zero.</t>
<t> For the Home Agent, the status value can be stored in the
Status field of either a Binding Acknowledgment or a Binding
Identifier mobility option. If the status value is specific to one
of bindings in the bulk registration, the status value MUST
be stored in the Status field in the corresponding Binding
Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST
be set to the Status field of the Binding Acknowledgment so
that the receiver can examine the Status field of each
Binding Identifier mobility option for further operations.
</t>
<list style="symbols">
<t>
The length value is examined. The length value MUST be either
4, 8, or 20 depending on C and D flag. If the length is
incorrect, the receiver MUST rejects the Binding Update and
returns the status value set to [MCOA MALFORMED].
</t>
<t>When C flag is specified, the care-of address MUST be given in
the Binding Identifier mobility option. Otherwise, the receiver
MUST reject the Binding Identifier mobility option and returns
the status value set to [MCOA MALFORMED]. The operation of D
flag is described in <xref target="dsmip"/></t>
<t>When multiple binding Identifier mobility options are
presented, the receiver MUST support the bulk
registration. Only a home agent can accept the bulk
registration. Otherwise, it MUST reject the Binding Update and
returns the status value set to [MCOA BULK REGISTRATION NOT
SUPPORT] in the Binding Acknowledgment. </t>
<!-- <t>When multiple binding Identifier mobility options are
presented, the flags field of all the Binding Identifier
mobility option stored in the same Binding Update MUST be
equal. Otherwise, the receiver MUST reject the Binding Update
and returns the status value set to [MCOA MALFORMED] in
the Binding Acknowledgment.</t>-->
<t>If the Lifetime field of the Binding Update is zero, the
receiver node deletes the binding entry which BID is same as
BID sent by the Binding Identifier mobility option. If the
receiver node does not have appropriate binding which BID is
matched with the Binding Update, it MUST reject this
de-registration Binding Update for the binding cache. If the
receiver is a Home Agent, it SHOULD also return the status
value set to [not Home Agent for this mobile node, 133]. </t>
<t>If O flag is set in the de-registering Binding Update, the
receiver can ignore this flag for de-registration. If the H
flag is set, the home agent stores a Home Address in the
Care-of Address field of the binding cache entry. The home
agent no longer performs proxy NDP for this mobile node until
this entry is deleted.
</t>
<t>
If the Lifetime field is not zero, the receiver node registers
a binding with the specified BID as a mobile node's binding. The
Care-of address is picked from the Binding Update packet as
follows:</t>
<list style="symbols">
<t>
If C flag is set in the Binding Identifier
mobility option, the care-of address must be taken from the
care-of address field in each Binding Identifier
mobility option.
</t>
<t>
If C flag is not set in the Binding Identifier
mobility option, the care-of address must be taken from the Source
Address field of the IPv6 header.
</t>
<t>
If C flag is not set and an alternate care-of
address is present, the care-of address is taken from the
Alternate Care-of address mobility option.
</t>
</list>
<t>Once the care-of address(es) has been retrieved from the Binding
Update, it starts registering binding(s). </t>
<list style="symbols">
<t>
Only if O flag is set in the mobility option, the home agent
first removes all the existing bindings and registers the
received bindings.
</t>
<t>If the receiver has a regular binding which does not have
BID for the mobile node, it de-registers the regular binding
and registers a new binding including BID according to the
Binding Update. In this case, the receiver MUST return [MCOA
BID CONFLICT].
</t>
<t> If the receiver node has already registered the binding
which BID is matched with requesting BID, then it MUST
update the binding with the Binding Update and returns [0
Binding Update accepted].
</t>
<t>
If the receiver does not have a binding entry which BID is
matched with the requesting BID, it registers a new binding
for the BID and returns [0 Binding Update accepted].
</t>
</list>
</list>
<t>If all the above operations are successfully finished, the
Binding Acknowledgment containing the Binding Identifier
mobility options MUST be replied to the mobile node if A flag is set
in the Binding Acknowledgment. Whenever a Binding Acknowledgment
is returned, all the Binding Identifier mobility options
stored in the Binding Update MUST be copied to the Binding
Acknowledgment. The Care-of address field of each Binding
Identifier mobility option, however, can be omitted, because the
mobile node can match a corresponding binding update list by
using BID. </t>
</section>
<!--====================================================-->
<section anchor="sec:sending_brr" title="Sending Binding Refresh Request">
<t>
When a node sends a Binding Refresh Request for a particular
binding registering with BID, the node SHOULD contain a Binding
Identifier mobility option in the Binding Refresh Request.
</t>
</section>
<!--====================================================-->
<section anchor="sec:receve_pkt" title="Receiving Packets from Mobile Node">
<t>When a node receives packets with a Home Address
destination option from a mobile node, it MUST check that the
care-of address appeared in the Source Address field MUST be
equal to one of the care-of addresses in the binding cache
entry. If no binding is found, the packets MUST be silently
discarded and MUST send a Binding Error message according to
RFC3775. This verification MUST NOT be done for a Binding
Update.</t>
</section>
</section><!-- HA & CN Operation -->
<!-------------------------------------------------------->
<!-- SECTION: NEMO APPLICABILITY -->
<!-------------------------------------------------------->
<section title="Network Mobility Applicability">
<t>
Support of multihomed mobile routers is advocated in the NEMO
working group (see R12 "The solution MUST function for multihomed
MR and multihomed mobile networks" in
[RFC-4886].
Issues regarding mobile routers with multiple interfaces and other
multihoming configurations are documented in [RFC-4980].
</t><t> Since the binding management mechanisms are the same for a
mobile host operating Mobile IPv6 and for a mobile router operating
NEMO Basic Support (RFC 3963), our extensions can also be used to
deal with multiple care-of addresses registration sent from a
multihomed mobile router. <xref target="fig:bu-nemo"/> shows an
example format of a Binding Update used by a mobile router.
</t>
<figure anchor="fig:bu-nemo" title="NEMO Binding Update">
<artwork>
IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier
- Mobile Network Prefix
</artwork>
</figure>
</section> <!-- NEMO-->
<section anchor="dsmip" title="DSMIPv6 Applicability">
<t>Dual Stack Mobile IPv6 (DSMIPv6) extends Mobile IPv6 to register
an IPv4 care-of address instead of the IPv6 care-of address when
the mobile node is attached to an IPv4-only access network. It
also allows the mobile node to acquire an IPv4 home address in
addition to an IPv6 home address for use with IPv4-only
correspondent nodes. This section describes how multiple care-of
address registration works with IPv4 care-of and home
addresses.</t>
<section anchor="dsmip:registration" title="IPv4 Care-of Address Registration">
<t>In DSMIPv6, the binding update and acknowledgment exchange is
used to detect NAT. Thus, when a mobile node registers its IPv4
care-of address bound to IPv6 home address, it MUST first attempt to send
a Binding Update with Binding Identifier mobility option
independently. The bulk registration MUST NOT be used for the
first binding update of the IPv4 care-of address. The Binding
Update MUST be sent to the IPv4 home agent address by using UDP
and IPv4 headers as shown in <xref target="fig:bu-dsmip"/>. It
is similar to [DSMIP] except for using BID mobility option instead of
IPv4 care-of address option.</t>
<figure anchor="fig:bu-dsmip" title="Initial Binding Update for IPv4 Care-of Address">
<artwork>
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier (IPv4 CoA)
</artwork>
</figure>
<t>When the home agent detects NAT for the received binding
update, it MUST send the NAT detection option in the Binding
Acknowledgment. Whenever the NAT detection option is found, the
mobile node MUST NOT use the bulk registration for the IPv4
care-of address. Otherwise, it can send the IPv4 care-of address
with other care-of addresses in the bulk registration mode. How
to handle NAT is same as [DSMIP].</t>
<t>If NAT is not detected, the mobile node can update the IPv4
care-of address by using BULK registration. The mobile node can
register the IPv4 care-of address with other care-of addresses.
<xref target="fig:bulkbu-dsmip"/> shows the binding update
format when the mobile node sends a Binding Update from one of
its IPv6 care-of addresses. If the mobile node sends a BU from
IPv4 care-of address, it MUST follows the
<xref target="fig:bu-dsmip"/> and store more BID mobility options in
the mobility options field. Note that IPv4 Care-of Address must
be registered by non bulk Binding registration, whenever it is
changed. NAT detection MUST be carried out for every new IPv4
addresses.</t>
<figure anchor="fig:bulkbu-dsmip" title="Binding Bulk Registration for IPv4 care-of address ">
<artwork>
IPv6 header (src=V6CoA, dst=HAADDR)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...
</artwork>
</figure>
<t>If the IPv4 care-of address is successfully registered, the
mobile node sets up a relevant tunnel to the home agent according
to [DSMIP].</t>
<t>If the home agent rejects the IPv4 care-of address, it MUST
store the error code value in the Status field of the BID
mobility option. The home agent MUST send the binding acknowledgment
and all the received BID mobility options to the mobile node. In this
case, the IPv4 address acknowledgment option MUST NOT be
included in the Binding Acknowledgment. All the error codes for
IPv4 care-of address registration MUST be stored in the Status
field of the BID mobility option. The IPv4 address acknowledgment
option is used only when a mobile node requests IPv4 home
address management.</t>
</section>
<section anchor="dsmip:v4hoa" title="IPv4 HoA Management">
<t>When the mobile node obtains an IPv4 home address, it MUST
store the IPv4 Home Address option in the Binding Update. If
the home agent accepts the binding update, the mobile node can
also register multiple care-of addresses for the IPv4 home
address in addition to the IPv6 home address. The same set of
care-of addresses will be registered for both IPv6 and IPv4 home
addresses. The mobile node cannot binding different set of
care-of addresses to each home address.</t>
<t>The home agent MUST returns a binding acknowledgment and IPv4
address acknowledgment option to the mobile node only when a
mobile node requests IPv4 home address mobility management. In
this case, this option MUST be presented before any BID
options. The status field of the IPv4 address acknowledgment
option contains only the error code regarding IPv4 home address
management. The error value of the IPv4 care-of address
registration MUST be stored in the BID mobility option.</t>
</section>
</section>
<!-------------------------------------------------------->
<!-- SECTION: IPsec-->
<!-------------------------------------------------------->
<section anchor="security" title="IPsec and IKEv2 interaction">
<t>
Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
use of IPsec to protect signaling messages like Binding Updates,
Binding Acknowledgments and return routability messages. IPsec may
also be used protect all reverse tunneled data traffic. The Mobile
IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used
to setup the required IPsec security associations. The following
assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2
specification with respect to the use of IKEv2 and IPsec.
</t>
<t>
<list style="symbols">
<t>There is only one primary care-of address per mobile node.
</t>
<t>The primary care-of address is stored in the IPsec database for
tunnel encapsulation and decapsulation.
</t>
<t>When the home agent receives a packet from the mobile node, the
source address is verified against the care-of address in the
corresponding binding cache entry. If the packet is a reverse
tunneled packet from the mobile node, the care-of address check
is done against the source address on the outer IPv6 header.
The reverse tunnel packet could either be a tunneled HoTi
message or tunneled data traffic to the correspondent node.
</t>
<t>The mobile node runs IKEv2 (or IKEv1) with the home agent
using the care-of address. The IKE SA is based on the care-of
address of the mobile node.
</t>
</list></t>
<t>
The above assumptions may not be valid when multiple care-of
addresses are used by the mobile node. In the following sections,
the main issues with the use of multiple care-of address with
IPsec are addressed.
</t>
<section title="Use of Care-of Address in the IKEv2 exchange">
<t>For each home address the mobile node sets up security
associations with the home agent, the mobile node must pick one
care-of address and use that as the source address for all IKEv2
messages exchanged to create and maintain the IPsec security
associations associated with the home address. The resultant IKEv2
security association is created based on this care-of address.
</t>
<t>If the mobile node needs to change the care-of address, it just
sends a Binding Update with the care-of address it wants to use,
with the corresponding Binding Identifier mobility option, and
with the 'K' bit set. This will force the home agent to update the
IKEv2 security association to use the new care-of address. If the
'K' bit is not supported on the mobile node or the home agent, the
mobile node MUST re-establish the IKEv2 security association with
the new care-of address. This will also result in new IPsec
security associations being setup for the home address.
</t>
</section>
<section title="Transport Mode IPsec protected messages">
<t>
For Mobile IPv6 signaling message protected using IPsec in
transport mode, the use of a particular care-of address among
multiple care-of addresses does not matter for IPsec processing.
</t>
<t>
For Mobile Prefix Discovery messages, [RFC-3775] requires the home
agent to verify that the mobile node is using the care-of address
that is in the binding cache entry that corresponds to the mobile
node's home address. If a different address is used as the source
address, the message is silently dropped by the home agent. This
document requires the home agent implementation to process the
message as long as the source address is is one of the care-of
addresses in the binding cache entry for the mobile node.
</t>
</section>
<section title="Tunnel Mode IPsec protected messages">
<t>
The use of IPsec in tunnel mode with multiple care-of address
introduces a few issues that require changes to how the mobile
node and the home agent send and receive tunneled traffic. The
route optimization mechanism described in [RFC-3775] mandates the
use of IPsec protection in tunnel mode for the HoTi and HoT
messages. The mobile node and the home agent may also choose to
protect all reverse tunneled payload traffic with IPsec in tunnel
mode. The following sections address multiple care-of address
support for these two types of messages.
</t>
<section title="Tunneled HoTi and HoT messages">
<t> The mobile node MAY use the same care-of address for all HoTi
messages sent reverse tunneled through the home agent. The
mobile node may use the same care-of address irrespective of
which correspondent node the HoTi message is being sent. RFC
3775 requires the home agent to verify that the mobile node is
using the care-of address that is in the binding cache entry,
when it receives a reverse tunneled HoTi message. If a different
address is used as the source address, the message is silently
dropped by the home agent. This document requires the home agent
implementation to decapsulate and forward the HoTi message as
long as the source address is one of the care-of addresses in
the binding cache entry for the mobile node.
</t>
<t>
When the home agent tunnels a HoT message to the mobile node, the
care-of address used in the outer IPv6 header is not relevant to
the HoT message. So regular IPsec tunnel encapsulation with the
care-of address known to the IPsec implementation on the home
agent is sufficient.
</t>
</section>
<section title="Tunneled Payload Traffic">
<t>
When the mobile sends and receives multiple traffic flows
protected by IPsec to different care-of addresses, the use of the
correct care-of address for each flow becomes important. Support
for this requires the following two considerations on the home
agent.
</t>
<t>
<list style="symbols">
<t>When the home agent receives a reverse tunneled payload message
protected by IPsec in tunnel mode, it must check that the
care-of address is one of the care-of addresses in the binding
cache entry. According to RFC 4306, the IPsec implementation
on the home agent does not check the source address on the
outer IPv6 header. Therefore the care-of address used in the
reverse tunneled traffic can be different from the care-of
address used as the source address in the IKEv2 exchange.
However, the Mobile IPv6 stack on the home agent MUST verify
that the source address is one of the care-of addresses
registered by the mobile node before decapsulating and forwarding
the payload traffic towards the correspondent node.
</t>
<t> For tunneled IPsec traffic from the home agent to the mobile
node, The IPsec implementation on the home agent may not be
aware of which care-of address to use when performing IPsec
tunnel encapsulation. The Mobile IP stack on the home agent
must specify the tunnel end point for the IPsec tunnel. This may
require tight integration between the IPsec and Mobile IP
implementations on the home agent.
</t>
</list></t>
</section>
</section>
</section> <!-- NEMO-->
<!-------------------------------------------------------->
<!-- SECTION: SECURITY CONSIDERATIONS -->
<!-------------------------------------------------------->
<section title="Security Considerations">
<t> As shown in <xref target="security"/>, the Multiple Care-of
Addresses Registration requires IPsec protection for all the signaling
between a mobile node and its home agent.
</t>
<t>With simultaneous binding support, it is possible for a malicious
mobile node to successfully bind a number of victims' addresses as
valid care-of addresses for the mobile node with its home
agent. Once these addresses have been bound, the malicious mobile
node can perform a re-direction attack by instructing the home
agent (e.g. setting filtering rules to direct a large file
transfer) to tunnel packets to the victims' addresses. Such risk
is highlighted in [ID-MIP6ANALYSIS] and is possible because the
care-of addresses specified by the mobile node in the binding
update messages are not verified by home agent (since Mobile IPv6
assumes an existing trust relationship between the mobile node and
its home agent).</t>
<t>Although such risk exists in Mobile IPv6, the risk level is
escalated when simultaneous multiple care-of address bindings are
performed. One fundamental difference is the degree of risk
involved is much greater in the simultaneous binding support
case. For a single care-of address binding, a mobile node can only
have a single care-of address binding per home address at a given
time. However, for simultaneous multiple care-of address bindings,
a mobile node can have more than one care-of address binding per
home address at a given time. This implies that a mobile node
using simultaneous binding support can effectively bind more than
a single victim's address. Another fundamental difference is the
form of risk involved. In the single care-of address binding case,
once the re-direction attack is initiated, a malicious mobile node
would be unable to use its home address for communications (such
as to receive control packets pertaining to the file
transfer). However, in the simultaneous binding support case, a
malicious mobile node could bind a valid care-of address in
addition to multiple victims addresses. This valid care-of address
could then be used by the malicious mobile node to set up flow
filtering rules at its home agent, thereby controlling and/or
launching new re-direction attacks.</t>
<t>Thus, in view of such risk, it is advisable for a home agent to
employ some form of care-of address verification mechanism before
using the care-of addresses as a valid routing path to a mobile
node. Some solutions to advert such problems are described in
Appendix.</t>
</section> <!-- security -->
<!-------------------------------------------------------->
<!-- SECTION: IANA CONSIDERATIONS -->
<!-------------------------------------------------------->
<section title="IANA Considerations">
<t>The following Extension Types MUST be assigned by IANA:
</t>
<list style="symbols">
<t>Binding Identifier mobility option type:This must be assigned
from the same space as mobility option in [RFC3775].</t>
<t>New Successful Status of Binding Acknowledgment:This
status code must be assigned from the same space as binding
acknowledgement status codes in [RFC3775].</t>
<list style="symbols">
<t>MCOA NOTCOMPLETE (TBD)</t>
</list>
<t>New Unsuccessful Status of Binding Acknowledgment: These
status codes must also be assigned from the same space as
binding acknowledgement status codes in [RFC3775].</t>
<list>
<t>MCOA MALFORMED (TBD)</t>
<t>MCOA BID CONFLICT (TBD)</t>
<t>MCOA PROHIBITED(TBD)</t>
<t>MCOA BULK REGISTRATION NOT SUPPORTED (TBD)</t>
</list>
</list>
</section> <!-- IANA -->
<!-------------------------------------------------------->
<!-- SECTION: ACKNOWLEDGMENTS -->
<!-------------------------------------------------------->
<section title="Acknowledgments">
<t>
The authors would like to thank Masafumi Aramoto (Sharp
Corporation), George Tsirtsis (Qualcomm), Keigo Aso (Panasonic),
Julien Charbon, Tero Kauppinen (Ericsson), Benjamin Lim (Panasonic),
Susumu Koshiba, Martti Kuparinen (Ericsson), Romain Kuntz (Keio-U),
Heikki Mahkonen (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro
Mitsuya (Keio-U), Nicolas Montavont, Koji Okada (Keio-U), Keisuke
Uehara (Keio-U), Masafumi Watari (KDDI R&D) in alphabetical order,
the Jun Murai Lab. at KEIO University.
</t>
<!--<t>
The authors acknowledge Romain Kuntz (Keio-U) for providing the texts of the DHAAD operation and reviewing this draft.
</t> -->
</section> <!-- Acknowledgments -->
<?rfc compact="yes" ?>
</middle>
<!-------------------------------------------------------->
<!-- Back Section -->
<!-------------------------------------------------------->
<!-------------------------------------------------------->
<!-- REFERENCES -->
<!-------------------------------------------------------->
<section title="References">
<vspace blankLines="1" />
<section title="Normative References">
<t>
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998.
</t><t>
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
</t><t>
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
</t><t>
[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-04 (work in progress),
Novemver 2007.
</t><t>
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
</t><t>
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
</t><t>
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
RFC 4885, July 2007.
</t><t>
[RFC-4886] Ernst, T., "Network Mobility Support Goals and Requirements",
RFC 4886, July 2007.
</t><t>
[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture",
RFC 4877, April 2007.
</t>
</section>
<!-------------------------------------------------------------------------->
<!-- SECTION 8.2: Informative References -->
<!-------------------------------------------------------------------------->
<section title="Informative References">
<t>
[ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
Kuladinithi, "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
progress), July 2007
</t><t>
[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming
in Network Mobility Support",
RFC 4980, October 2007.
</t><t>
<!--[ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of Proxy NDP from Home Agent Operations", draft-wakikawa-mip6-no-ndp-02.txt (work in progress), November 2007.
</t><t>-->
[RFC-3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
</t><t>
[RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization
for Mobile IPv6", RFC 4866, May 2007.
</t><t>
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
<!--</t><t>
[ID-RRCOOKIE] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6
using a State Cookie", draft-dupont-mipv6-rrcookie-04 (work in progress),
January 2007.-->
</t>
</section>
</section>
<vspace blankLines="1" />
<back>
<vspace blankLines="100"/> <!-- Force New Page -->
<!-------------------------------------------------------->
<!-- APPENDIX -->
<!-------------------------------------------------------->
<section anchor="ap:scenario" title="Example Configurations">
<t>
In this section, we describe typical scenarios when a mobile node
has multiple network interfaces and acquires multiple Care-of
Addresses bound to a Home Address. The Home Address of the mobile
node (MN in figures) is a:b:c:d::EUI. MN has 3 different interfaces
and possibly acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The
MN assigns BID1, BID2 and BID3 to each care-of address.</t>
<figure anchor="fig:ex-1" title="Multiple Interfaces Attached to a Foreign Link">
<artwork>
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
</artwork>
</figure>
<t> <xref target="fig:ex-1"/> depicts the scenario where all
interfaces of the mobile node are attached to foreign links. After
binding registrations, the home agent (HA) and the Correspondent
Node (CN) have the binding entries listed in their binding cache
database. The mobile node can utilize all the interfaces.
</t>
<figure anchor="fig:ex-2" title="One of Interface Attached to Home Link and Returning Home">
<artwork>
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +--------+-+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ | |
+--+--+ | | |
CoA3| +---|-----------+
+---------------+
Binding Cache Database:
home agent's binding
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
</artwork>
</figure>
<t> <xref target="fig:ex-2"/> depicts the scenario where MN returns
home with one of its interfaces. After the successful
de-registration of the binding to HA, HA and CN have the binding
entries listed in their binding cache database of
<xref target="fig:ex-2"/>. After de-registration, the ND state of
the home address is managed by the MN. MN can communicate with the
HA through only the interface attached to the home link. On the
other hand, the mobile node can communicate with CN from the other
interfaces attached to foreign links (i.e. route optimization). Even
if MN is attached to the home link, it can still send Binding
Updates for other active care-of addresses (CoA2 and CoA3) to
CNs. If CN has bindings, packets are routed to each Care-of
Addresses directly. Any packet arrived at HA are routed to the
interface attached to the home link.
</t>
<figure anchor="fig:ex-3" title="One of Interface Attached to Home Link and Not Returning Home">
<artwork>
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
(Disable interface)
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
</artwork>
</figure>
<t>
<xref target="fig:ex-3"/> depicts the scenario where MN disables the
interface attached to the home link and communicates with the
interfaces attached to foreign links. HA continues managing the ND
state of the home address by Proxy neighbor advertisement. The HA
and the CN have the binding entries listed in their binding cache
database. All packets routed to the home link are intercepted by
the HA and tunneled to the other interfaces attached to the foreign
link according to the binding entries.
</t>
<!--<figure anchor="fig:ex-4" title="Several Interfaces Attached to Home Link and Returning Home">
<artwork>
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----------+ +--+-+
CoA2| | Home Link
+--+--+ --+----+---+------
| MN +===================+ |
+--+--+ |
| |
+---------------------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is inactive)
none
correspondent node's binding
binding [a:b:c:d::EUI care-of address2 BID2]
</artwork>
</figure>
<t>
<xref target="fig:ex-4"/> depicts the scenario where multiple
interfaces of MN are attached to the home link. The HA and CN
have the binding entries listed in <xref target="fig:ex-4"/>
in their binding cache database. The MN can not use the interface
attached to a foreign link unless a CN has a binding for the
interface. All packets which arrive at the HA are routed to one of
the MN's interfaces attached to the home link.
</t>-->
<figure anchor="fig:ex-5" title="Utilize Interfaces Attached to both Home and Foreign Links">
<artwork>
<![CDATA[
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
correspondent node's binding
binding [a:b:c:d::EUI care-of address1 BID1]
binding [a:b:c:d::EUI care-of address2 BID2]
binding [a:b:c:d::EUI care-of address3 BID3]
]]>
</artwork>
</figure>
<t> <xref target="fig:ex-5"/> depicts the scenario where interfaces
of MN are attached to both the home and foreign links. There are
two possible topologies whether the HA is single router at the home
link or not. The operation of ND is different in two topologies.
The HA and CN have the binding entries listed in
<xref target="fig:ex-5"/> in their binding cache database
regardless of topologies. The HA also knows that the MN has
attached to the home link. All the traffic from the Internet are
intercepted by the HA and routed to either the interface attached
to the home link or the interfaces attached to the foreign
links. How to make the decision is out of scope in this
document. </t>
<t>There are two different treatments of the ND state of the home address.
<list style="symbols">
<t>MN defends the home address by regular ND (topology-a)</t>
<t>HA defends the home address by Proxy ND (topology-b)</t>
</list>
The first case is required that the HA is the single exit router to
the Internet and is capable of intercepting packets without relying
on proxy ND. The MN can manage the ND of the home address on the
home link. In the second case, the HA is not only router at the
home link and cannot intercept all the packets meant for the MN by
IP routing. The HA needs to run Proxy ND to intercept all the
packets at the home link. Since the MN cannot operate the ND of its
home addrss at the home link, HA cannot resolve the layer-2 address
of the MN at the home link. The HA MUST learn and record the
layer-2 address (MAC address) of the MN's interface attached to the
home link to forward packets. The packets forwarding is achieved
without ND cache. The MN is also required to learn and record the
layer-2 address of the HA's interface to send packets from the home
link.
</t>
</section><!-- Examples -->
<!-------------------------------------------------------->
<!-- Change Log -->
<!-------------------------------------------------------->
<vspace blankLines="100"/> <!-- Force New Page -->
<section anchor="sec:log" title="Changes From Previous Versions">
<t>
Changes from draft-ietf-monami6-multiplecoa-04.txt
</t>
<t><list style="symbols">
<t>Binding Unique Identifier is renamed to Bidning Identifier</t>
<t>New Status Code [MCOA NOTCOMPLETE], the home agent uses this
status code in the Binding Acknowledgement when not all the
bindings are accepted in the bulk registration. </t>
<t>[MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED]</t>
<t>Add care-of address verification issue in the Security
Consideration, the text is proposed by Benjamin Lim.</t>
<t>Support DSMIPv6</t>
<t>Support simultaneous foreign and home location. (Section 5.5)</t>
<t>Editorial updates, thanks George Tsirtsis for detailed comments!</t>
</list></t>
</section> <!-- Change Log -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:34:57 |