wdiff draft-ietf-monami6-multiplecoa-05.txt draft-ietf-monami6-multiplecoa-06.txt

Monami6
MEXT Working Group R. Wakikawa (Editor) (Ed.)
Internet-Draft Keio University
Intended status: Standards Track T. Ernst
Expires: July 31, August 27, 2008 INRIA
K. Nagami
INTEC NetCore
V. Devarapalli (Ed.)
Azaire Networks
January 28,
February 24, 2008

Multiple Care-of Addresses Registration
draft-ietf-monami6-multiplecoa-05.txt
draft-ietf-monami6-multiplecoa-06.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 31, August 27, 2008.

Abstract

According to the current Mobile IPv6 specification, a mobile node may
have several care-of addresses, but only one, termed called the primary
care-of address, that 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 accesses simultaneously, in which case the mobile node would
be configured with multiple active IPv6 care-of addresses would be assigned addresses. This
document proposes extensions to the mobile node. We thus
propose Mobile IPv6 extensions designed protocol to register
and use 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 addresses. The extensions proposed in each binding for the receiver to distinguish between the
bindings corresponding to this
document can be used by Mobile Routers using the same Home Address. Those extensions
are targeted to NEMO (Network
Mobility) Basic Support protocol as well as to
Mobile IPv6. well.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7

4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9
4.1. Binding Cache Structure and Binding Update List . . . . . 9
4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 9
4.2.1. Binding Identifier Mobility Option . . . . . . . . . . . . 9
4.3. New Status Values for Binding Acknowledgment . Acknowledgement . . . . . . 11

5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13
5.1. Management of Care-of Addresses Address(es) and Binding Identifier
Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13
5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14
5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15 . . . . 14
5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 15
5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. Using only Interface attached to the Home Link . . . . 16
5.6.2. Using only Interface attached to the Visited Link . . 16
5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17
5.7. Receiving Binding Acknowledgment . Acknowledgement . . . . . . . . . . . . 19
5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20
5.9. Sending Packets to Home Agent . . . . . . . . . . . . . . 20
5.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21 20

6. Home Agent and Correspondent Node Operation . . . . . . . . . 22 21
6.1. Searching Binding Cache with Binding Identifier . . . . . 22 21
6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22 21
6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23 22
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25 24
6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26 24

7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27 25

8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 28 26
8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 28 26
8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 29 27

9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 30 28
9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 30 28
9.2. Transport Mode IPsec protected messages . . . . . . . . . 31 29
9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 31 29
9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 31 29
9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 32 30

10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 31

11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 33

12. Acknowledgments Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 34

13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 36 34

Appendix A. Example Configurations . . . . . . . . . . . . . . . 37

Appendix B. Changes From Previous Versions . . . . . . . . . . . 42 36

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 40
Intellectual Property and Copyright Statements . . . . . . . . . . 44 42

1. Introduction

A mobile node may use various types of network interfaces to obtain
durable and wide area network connectivity. This is increasingly
become true with mobile nodes having multiple interfaces such as
802.2, 802.11, 802.16, cellular radios, etc.. The assumed scenarios
and motivations for
and benefits of using multiple points of attachment, and benefits for
doing it attachment are discussed at large in
[ID-MOTIVATION].

IPv6 [RFC-2460] conceptually allows When a mobile node to have several addresses
on a given interface. Consequently, with multiple interfaces uses
Mobile IPv6 [RFC-3775] has
mechanisms to manage for mobility management, it cannot use its
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 interfaces to
a node send and receive packets while taking
advantage of session continuity provided by Mobile IPv6. This 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 Mobile IPv6 allows the mobile node changes to only bind one care-of
address at a time with its active network interface (i.e. change the Home
Address).

According home address.

This document proposes extensions to the Mobile IPv6 specification, to allow 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 for 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 home address and NEMO Working Group.

In this document, we thus propose a
create multiple binding cache entries. A new identification number called Binding Identification
(BID) number is created for each binding cache entry to
accommodate multiple bindings registration. The the mobile node notifies
the BID wants to both its Home Agent and correspondent nodes by means of a
Binding Update. Correspondent nodes
create and sent in the binding update. The home agent record the
BID into their that receives
this Binding Update creates separate binding cache. for each BID. The Home Address thus identifies a
mobile node itself whereas the BID identifies each binding registered
by a mobile node. By using
information is stored in the BID, multiple bindings corresponding binding cache entry. The
BID information can then now be
distinguished. used to identify individual bindings. The
same extensions can also be used in Binding Updates sent to the
correspondent nodes.

2. Terminology

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].

Terms used in this draft are defined in [RFC-3775], [RFC-3753] and
[RFC-4885]. In addition or in replacement of these, the following
terms are defined or redefined:

Binding Identification number (BID)

The BID is an identification number used to distinguish multiple
bindings registered by the mobile node. Assignment of distinct
BID
BIDs allows a mobile node to register multiple binding cache
entries for a given Home Address. 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 Zero and a negative value values MUST NOT be used.
Each BID is generated and managed by a mobile node.
After being generated by the mobile node, the 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 Section 5.1.

Binding Identifier Mobility Option

The Binding Identifier mobility option is used to carry the BID. BID
information.

Bulk Registration

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. Binding Update. A mobile node can also replace some or all
the bindings available at the home agent with the new bindings by
using the bulk registration. The bulk Bulk registration is supported only for
with the home registration and de-registration agent as explained in Section 5.5. A mobile node
MUST NOT perform bulk registration with a correspondent nodes. node.

3. Protocol Overview

A new extension called the Binding identification number (BID) is
introduced to distinguish between multiple bindings pertaining to the
same Home Address. Once home address. If a mobile node gets configures several IPv6 global
addresses on one or more of its interfaces, it can register these
addresses with its home agent. agent as care-of addresses. If the mobile
node wants to register multiple bindings, it MUST generate a BID for
each care-of address and record store the BID into in the binding update list. A
mobile node can manipulate each binding independently by using a BID. the
BIDs. The mobile node then registers its care-of addresses by
sending a Binding Update with a Binding Identifier mobility option.
The BID MUST be is included in the Binding Identifier mobility option. After
receiving such the Binding Update and with a 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 If there is already an existing binding cache entry for the mobile node's
home address,
node, and if the BID in the Binding Update does not match the one
with the existing entry, the home agent MUST register create a new binding
cache entry for the BID stored in the Binding Identifier mobility option. new care-of address and BID. The mobile node registers can
register multiple care-of addresses either independently in
individual Binding Updates or multiple at once in a single Binding
Update.

If the mobile host wishes to register its binding with a
correspondent node, it must perform return routability operations.
The mobile host MUST manage
This includes managing a Care-of Keygen Token token per care-of
address. The mobile host exchanges CoTI address and
exchanging CoTi and CoT for the
corresponding care-of addresses if necessary. When message with the mobile host
registers several care-of addresses to a correspondent node, it uses
the same BID as the one generated node for the home registration's
bindings. each
care-of address. The binding registration step is mobile node MAY use the same as for BID that it used
with the home
registration except agent for calculating authenticator. a particular care-of address. For protocol
simplicity, the bulk registration to correspondent nodes is not supported for correspondent
nodes
in this document. This is because the Return Routability mechanism
introduced in [RFC-3775] cannot be easily extended to verify multiple
care-of addresses stored in a single Binding Update.

If the mobile node decides to act as a regular mobile node compliant
with [RFC-3775] , [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 the BID even if it has only a single binding that is active at some
time.

When a
active.

Binding cache lookup is done based on the home agent address and a correspondent node check BID
information. This is different from RFC 3775, where only the home
address is used for binding cache
database for the mobile node, they search a corresponding lookup. The binding
entry with the pair of Home Address and BID of the desired binding.
If necessary, a mobile node can use cache lookup
may also involve policy and filter information or flow filters in cases where some policy or
flow filters are used to
look up the best direct certain packets or flows to a
particular care-of address. The binding per sessions, flow, packets, but this cache lookup using policy or
flow filters is out of scope in for this document. If there is no desired binding, it
searches In case the binding
cache database with lookup, using the Home Address as
specified in Mobile IPv6. The first matched combination of home address and BID, does not
return a valid binding entry may be
found, although this cache entry, the home agent MAY perform
another lookup based on only the home address. This is
implementation dependent. dependent and configurable on the home agent.

The mobile node may return to the home link through one of its
interfaces. There are three options possible for the mobile node
when its returns home.

1. 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
link(s) are not used. no longer going to be receiving any encapsulated
traffic from the home agent.

2. The mobile node uses only the interfaces still attached to the
visited link. link(s). The interface with which the mobile node
attaches to the home link is not used.

3. The mobile node may simultaneously use both the interface
attached to the home link and the interfaces still attached to
the visited links. link(s).

Section 5.6 describes the returning home procedures in more detail.

4. Mobile IPv6 Extensions

This section summarizes the changes extensions to Mobile IPv6 necessary to for
manage multiple bindings bound to a same Home Address. bindings.

4.1. Binding Cache Structure and Binding Update List

The BID is required to be stored in the binding cache and binding
update list structure.

4.2. Message Format Changes

4.2.1. Binding Identifier Mobility Option

The Binding Identifier mobility option is included in the Binding
Update, Binding Acknowledgment, Acknowledgement, Binding Refresh Request, and Care-of
Test Init and Care-of Test message.

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) :
+ +
+---------------------------------------------------------------+

Figure 1: BID Mobility Option

Type

Type value for Binding Identifier is TBD

Length

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.

Binding ID (BID)

The BID which is assigned to the binding carried indicated by the care-of
address in the Binding Update with this or the BID mobility option. The BID
is a 16-bit unsigned integer.
A The value of zero is reserved. reserved and
MUST NOT be used.

Status

When the Binding Identifier mobility option is included in a
Binding Acknowledgment, Acknowledgement, this field overwrites the status field
correspondent to each binding in
the Binding Acknowledgment. Acknowledgement. If this field is zero, the receiver
MUST use the registration status stored in the Binding Acknowledgment
Acknowledgement message. This Status field
can be is also used to carry
error information for a related to the care-of address test in the
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.
Acknowledgement.

Care-of address (C) flag

When this flag is set, it indicates that a mobile node can store a Care-of Address
corresponding to valid care-of address
is present in the BID care-of address field in the Binding Identifier BID mobility
option. This flag MUST be used set whenever a the mobile node sends
multiple care-of addresses in a single Binding Update, i.e. i.e., bulk
registration. It MUST be MAY also used for the independent binding
registration as a substitute for an alternate
care-of address
option. option even for Binding Updates that are sent only
for one care-of address. This flag is valid only for binding update Binding
Update sent to the home agent.

Overwrite (O) flag

When this flag is set, a mobile node requests a home agent the recipient 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.

Simultaneous Home and Foreign Binding (H) flag

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 Binding Update sent to the home
agent.

DSMIPv6 (D) flag

This flag indicates that the care-of address field MUST be set to is an IPv4 care-of address. If
When this flag is set, the Care-of Address care-of address field MUST be used. contain an
IPv4 address.

Reserved

5 bits Reserved field. Reserved The reserved field MUST be set with all 0. zero.

Care-of Address

This field has the variable length depending on the specified
flags. When C the 'C' flag is set and D the 'D' flag is unset, not, an IPv6 Care-of
Address matched to
care-of address for the corresponding BID is stored in this field.
If both C 'C' and
D 'D' flags are set, an IPv4 Care-of Address is stored.
carried in this field. This field MUST NOT be used if a Binding
Identifier mobility option is included in any other messages message other
than a Binding Update message. The
receiver SHOULD ignore this field or if the mobility option 'C' flag is not
presented in Binding Update message. set.

4.3. New Status Values for Binding Acknowledgment Acknowledgement

New status values for the status field in a Binding Acknowledgment Acknowledgement
are defined for handling the multiple Care-of Addresses registration:

MCOA NOTCOMPLETE (TBD < 128)

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.

MCOA RETURNHOME WO/NDP (TBD < 128)

When a mobile node returns home, it MUST NOT use NDP for the home
address on the home link. The This is explained in more detail can be found in
Section 5.6

MCOA MALFORMED (TBD more than 128)

Registration failed because Binding Identifier mobility option is was
not formed formatted correctly.

MCOA BID CONFLICT (TBD more than 128)

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).

MCOA PROHIBITED(TBD more than 128)

It implies the multiple care-of address registration is
administratively prohibited.

MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)

The bulk

Bulk binding registration is not supported.

5. Mobile Node Operation

5.1. Management of Care-of Addresses Address(es) and Binding Identifier Identifier(s)

There are two cases when a mobile node has might acquire several Care-of Addresses. care-of
addresses. Note that a mixture of the two cases are is also possible.

1. A mobile node uses may be using several physical network interfaces
and acquires a care-of address on each of its interfaces.

2. A mobile node uses a single physical network interface, but
receives advertisements for multiple prefixes are announced on the link the
interface is attached to. Several This will result in the mobile node
configuring several global addresses are configured on this the interface for from each
of the announced prefixes.

The difference between the above two cases is only a in the number of
physical network interfaces and therefore does not matter irrelevant in this
document. The Identification number What is used to identify a binding.
To implement this, a of significance is the fact that the mobile node MAY assign an identification number
for each
has several addresses it can use as care-of addresses. How to assign an identification number
is implementation specific, but the following rules MUST be followed.

A mobile node assigns a BID to each care-of address when it wants to
register them simultaneously with its Home Address. 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 an integer between 1 to and 65535. Zero and negative values
MUST NOT be used as a BID. BIDs. If a mobile node has only one care-of
address, the assignment of a BID is not needed until it has multiple
care-of addresses to register with. with, at which time all of the care-of
addresses MUST be mapped to BIDs.

5.2. Return Routability: Sending CoTI and Receiving CoT

When a mobile node wants to register bindings to multiple care-of address with a Correspondent
Node,
correspondent node, it MUST have the valid care-of Care-of Keygen token per
care-of
address, while the HoTI and HoT can be exchanged address. The mobile node needs only once for a one Home
Address.

If the Mobile Node manages bindings with BID, it Keygen token
for its home address.

The mobile node MUST include a Binding Identifier mobility option in a
the 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
with a Care-of Test message and message, with the Binding Identifier mobility
option as described in Section 6.2. When the mobile node receives
the Care-of Test message, the Care-of Test message is verified as same as in [RFC-3775].
If a Binding Identifier mobility option is not presented present in the CoT
message in reply to the CoTI containing the message that included a Binding
Identifier mobility option, the mobile node must assume that 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 any future Binding Update. Updates to that
correspondent node. The Mobile
Node 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. Update.

5.3. Binding Registration

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.

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 Figure 2. The BID is copied from a corresponding Binding
Update List entry to the BID field of the Binding Identifier mobility
option. When IPsec ESP is used for binding update, protecting the Binding Update,
the care-of address MUST can be stored carried in the Care-of Address field by setting C flag as a substitute for of
the alternate
care-of address Binding Identifier mobility option. The If this is done, the
alternate care-of address option MUST NOT be
omitted. Additionally for included in the Binding
Update. For binding registration to a correspondent node, the mobile
node MUST have both active home Home and care-of Care-of Keygen tokens for Kbm
(see Section 5.2.5 of [RFC-3775]). [RFC-3775]) before sending the Binding Update.
The care-of Keygen tokens MUST be maintained for each care-of address
that the mobile node wants to register to the correspondent node, as described in
Section 5.2. After computing an Authenticator value for the Binding
Authorization mobility option, it sends a Binding Update which
contains a Binding Identifier mobility option. node.
The Binding Update to the correspondent node is protected by a the
Binding Authorization Data mobility option that is placed after the
Binding Identifier mobility option.

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)

Figure 2: Binding Update for Binding Registration

5.4. Binding Bulk Registration

The bulk

Bulk registration is an optimization for registering binding multiple care-of
addresses only to a home agent by address using a single Binding Update. If a This is
very useful if the mobile node, for instance, does not want to send a
lot of control signaling messages through an interface which where the bandwidth is scarce,
it can
scarce.

To use this bulk registration and send a Binding Update
containing multiple or all registration, the valid care-of addresses.

A mobile node sets the C flag in includes a Binding
Identifier mobility Mobility option for each BID and includes the particular care-of Care-of address pair it
wants to register in the Binding Identifier
mobility option. The mobile node stores multiple sets of a Binding
Identifier mobility option in a same Binding Update as message. This is shown
in Figure 3.
In The rest of the bulk registration, all fields and options in the other binding information Binding
Update such as Lifetime, Sequence Number, binding Flags are shared among the bulked
Care-of Addresses. flags in the Binding
Update are common across all care-of addresses. The alternate
care-of address option MUST NOT be
omitted when ESP is used to protect a binding update. used.

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 use the same Sequence Number specified in the
Binding Update. If each binding uses different sequence number, a
mobile node MUST use the largest sequence number from the binding
update Binding
Update list entries used for the bulk registration. If it the mobile
node cannot select a sequence number for all the bindings due to
sequence number out of window, it MUST NOT use the bulk registration
for the binding which whose sequence number is out of window and uses a window. A separate
Binding Update should be sent for the binding.

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)

Figure 3: Binding Update for Binding Bulk Registration

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 sets
the 'O' flag. Section 6.3 describes this registration procedure in
detail.

5.5. Binding De-Registration

When a mobile node decides to delete all the bindings for its home
address at a visiting network,
address, it simply sends a regular de-
registration de-registration Binding Update which with
lifetime is set to zero. A zero as defined in [RFC-3775]. The Binding
Identifier mobility option is not required.

If a mobile node wants to delete a particular binding(s) from its
home agent and correspondent nodes (e.g. from foreign link), nodes, the mobile node simply sets zero lifetime for the sending binding update.
The sends a Binding
Update MUST contain an appropriate with lifetime set to zero and includes a Binding Identifier
mobility option(s). option(s) with the BID(s) it wants to de-register. The
receiver will remove only the care-of address(es) that matches to match(es) the
specified BID. For the bulk de-
registration, the BID(s). The care-of addresses field of in each mobility
option SHOULD be omitted, omitted by the sender and MUST be ignored by the
receiver. This is because the receiver will remove all the care-of
addresses matching binding that
matches the specified BID.

5.6. Returning Home

The mobile node may return to the home link, by attaching to the home
link through one of the interfaces on the mobile node. its interfaces. When the mobile node wants to
return home, it should be configured with information on 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.

5.6.1. Using only Interface attached to the Home Link

The mobile node returns home and de-registers all the bindings as
shown in Figure 9. How to de-register 8 and as defined in [RFC-3775]. De-registering all
the bindings is the same as binding de-registration from foreign link
described in Section 5.5. All After the de-registration step, 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 Figure 9. These bindings at
correspondent node MUST be created before a mobile node returns home. 8.

5.6.2. Using only Interface attached to the Visited Link

The mobile node returns home and shutdown shuts down the interface attached to
the home link as shown in Figure 10. The 9. Before shutting down the
interface, any binding of for the care-of address previously associated
with the home
attached interface MUST should be deleted. To delete the binding cache
entry, the mobile node SHOULD send a de-registration Binding Update
with the lifetime set to zero and include the corresponding BID
information. If the mobile node does not send a de-registration
Binding Update, the binding for the care-of address previously
assigned to the interface remains at the home agent. This binding is
deleted by sending only when it expires. In order to avoid this, the mobile
node SHOULD send a de-registration binding update from one of active for the interface
attached to the foreign
links. home link.

This scenario is not the most efficient because all the traffic from and to
and from the mobile node is going through the bi-
directional bi-directional tunnel,
whereas the mobile node is now accessible at one hop on the home link
from its home agent.

5.6.3. Simultaneous Home and Visited Link Operation

The

In this case, the mobile node returns home and continues using all
the interfaces attached to both foreign and home links as shown in
Figure 11. 10. The mobile node indicates this by setting the 'H' flag in
the BID mobility option. option as defined below. There are additional
requirements on the Returning Home procedures for possible ND
conflicts at the home link described below.

In [RFC3775], [RFC-3775], the home agent intercepts packets meant for the mobile
node using proxy NDP Neighbor Discovery 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 stops proxying 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, configure the home while it keeps several address on the interface
attached to the home link, but still use the interfaces attached to
the foreign links
and continues using them. Therefore, even though both links. In this case, a possible conflict arises when the mobile
node and
both the home agent need to intercept packets, and the ND states of mobile node try to defend the home address can conflict between
address. If the home agent and the mobile
node. For instance, if the proxy ND stops proxying for the Home Address is stopped
by the home agent, address, the
packets are always routed to the interface attached to the home link
and are never routed to the interface interfaces attached to the foreign link. visited links.
It is required to avoid this ND
conflicts in the case of conflict between the home agent and the
mobile node, while still allowing the simultaneous use of home and
foreign
attachment. links. The following describes the mechanism for achieving
this.

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 intercepts all the packets even when the
mobile node is attached to the home link through one of its
interfaces. 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 critical 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.

The mobile node sends a de-registration binding update 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 include the BID assigned the mobile node
had previously associated with the interface attached to the interface. home
link. The H 'H' flag MUST be set in the BID mobility option. The 'C'
flag MUST NOT be set and the care-of address field MUST NOT be
included. When the H 'H' flag is appears, set, the home agent learns and remembers recognizes that
the mobile node wants to continue using interfaces attached to both
foreign and
home and visited links. If H the 'H' flag is unset, the home agent
deletes either all the bindings or the binding corresponding to the BID.
BID included in the Binding Identifier mobility option.

When the home agent sends the Binding Acknowledgment, Acknowledgement, it MUST store
one of two set
the status values such as value to either 0 [Binding Update Accepted (0)] [MCOA
RETURNHOME Accepted] or to
[MCOARETURNHOME WO/NDP (TBD)] in the BID mobility option depending on
home agent configuration at the home link. The new values are:

o Binding Update Accepted (0): NDP is permitted for the home address
at the home link. This is regular returning home operation of
[RFC3775]
[RFC-3775]

o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home
address at the home link

When the home agent is the only router at the home link, it can
intercept all the packets by normal IP routing without proxy NDP. using proxying
for the home address. It stops proxy ND for the requested home
address and replies responds with the [Binding Update Accepted] status 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 exchange of Neighbor Solicitation and Neighbor
Advertisement. If the home agent is not the only router, router on the home
link, it MUST continue defending the home address by proxy NDP neighbor
discovery in order to capture all intercept 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. (i.e., MAC address) during this binding de-
registration.
de-registration. It keeps stores the learned learnt layer-2 address as the in a 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.

According to [RFC3775], [RFC-3775], 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
Acknowledgement with success status value.

When the mobile node receives the binding acknowledgment Binding Acknowledgement and BID
mobility option, it assigns home address at to 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 regular Neighbor Discovery.

If the mobile node by NS and NA exchange as normal IPv6
operation.

If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT
defends
defend its home address at on the home link by NDP. link. When the mobile node sends
packets from the interface attached to the home link, it MUST learn
the layer2 layer 2 address (i.e. (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 learnt layer-2 address.
address of the default router or the home agent.

5.7. Receiving Binding Acknowledgment Acknowledgement

The verification of a Binding Acknowledgment Acknowledgement is the same as Mobile
IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a
Binding Acknowledgment Acknowledgement is described in Section 6.3.

If a mobile node includes a Binding Identifier mobility option in a
Binding Update with A the 'A' flag set, a Binding Acknowledgment Acknowledgement MUST
carry a Binding Identifier mobility option in the Mobility Options field. option. If no such mobility
option is included in the Binding Acknowledgment
replied Acknowledgement in response to the a
Binding Update for the multiple care-of address registration, this
indicates that the originator originating node of this the Binding
Acknowledgment might Acknowledgement
does not recognize support processing the Binding Identifier mobility option.
The mobile node SHOULD MUST then stop registering multiple care-of
addresses by using a Binding Identifier mobility option. address registration
with that node.

If a Binding Identifier mobility option is present in the received
Binding Acknowledgment, Acknowledgement, the mobile node checks the registration status for field in
the Care-of address(es). The status value MUST be
retrieved as follows. option. 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. Acknowledgement. Otherwise, it uses the value in the
Status field of the Binding Identifier mobility option.

If the status code is greater than or equal to 128, the mobile node
starts relevant operations according to the error code. Otherwise,
the mobile node assumes that the originator (home agent or
correspondent node) successfully registered the binding information
and BID for the mobile node.

o If the Status value is [MCOA PROHIBITED], the mobile node MUST
give up
stop registering multiple bindings to the peer sending node that sent the
Binding Acknowledgment. It MUST return to the regular Mobile IPv6
[RFC-3775] for the peer node. Acknowledgement.

o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
mobile node SHOULD stop using bulk registration to registrations with the peer
sending node
that sent the Binding Acknowledgment. Acknowledgement.

o 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].

o 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 'O' flag to
reset all the registered bindings.

5.8. Receiving Binding Refresh Request

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 Section 6.4.

If a mobile node receives a Binding Refresh Request with a Binding
Identifier mobility option, this it indicates that the node sending the
Binding Refresh Request requests message is requesting the mobile node to send
a new binding indicated by Binding Update for the BID. The mobile node SHOULD update then send a
Binding Update only for the respective binding. The mobile node MUST put
include a Binding Identifier mobility option into in the Binding Update sent to refresh
the entry. Update.

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.

5.9. Sending Packets to Home Agent

When a multihomed mobile node sends packets to its home agent, there
are conceptually two ways to construct packets.

1. Using Home Address Option. (required additional 24 bytes)

2. Using IPv6-IPv6 tunnel. (required additional 40 bytes)

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.

5.10. Bootstrapping

When a mobile node bootstraps and registers multiple bindings at for the
first time, it SHOULD MUST set O the 'O' flag in the Binding Identifier
mobility option. If old bindings still exists at the Home Agent, home agent, the
mobile node has no way to know knowledge of which bindings are still remained exist at the
home agent. This scenario happens when a mobile node reboots without
correct de-registration. and
looses state regarding the registrations. If O the 'O' flag is used, set,
all the bindings are replaced to by 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 Acknowledgement 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 indicated in the
Binding Acknowledgment.

For Correspondent nodes, the mobile node cannot use the O Acknowledgement.

The 'O' flag
because of no bulk registration support. Thus, if necessary, it MUST
sends a regular binding first can also be used in individual Binding Updates sent to overwrite
the remaining bindings correspondent nodes to override any existing binding cache
entries at the correspondent node. Then, it can re-register the set of bindings
by using Multiple Care-of Address Registration.

6. Home Agent and Correspondent Node Operation

6.1. Searching Binding Cache with Binding Identifier

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 This section
explains how to select retrieve the
most suitable desired binding from for the binding cache database is out of scope
in this document.

Whenever a correspondent node searches a
management. This document does not provide any mechnaism to select
the suitable binding cache for a home
address, it forwarding data packets.

A correspondent node SHOULD uses use both the Home Address home address and the BID as
the search key of the binding cache if it knows the corresponding BID. BID
(ex. when processing signaling messages). In the example below, if a
correspondent node searches the binding with the Home Address home address and
BID2, it gets binding2 for this mobile node.

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]

Figure 4: Searching the Binding Cache

A correspondent node basically learns the BID when it receives a Binding
Identifier mobility option. At the that time, the correspondent node
MUST look up its binding cache database with the Home Address 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. the home
address. In such a 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.

6.2. Receiving CoTI and Sending CoT

When a correspondent node receives a CoTI message which contains a
Binding Identifier mobility option, it MUST process processes it with following
steps.

First of all, as follows.

First, the CoTI message is verified according to as specified in [RFC-3775]. The
Binding Identifier mobility option MUST be, then, is processed as follows:

o If a correspondent node does not understand a Binding Identifier
mobility option, it just ignores and skip this skips processing the option.
The calculation of a care-of Keygen token will thus be done
without a BID value. The correspondent node returns a CoT message
without a Binding Identifier mobility option. The mobile node can thus know
knows whether the correspondent can process supports processing the Binding
Identifier mobility option or not, option, by checking if such the option is present
in the CoT message.

o If either the 'C' or both C and O the 'O' flag is set in the Binding Identifier
mobility option, the
Correspondent correspondent Node SHOULD NOT calculate a
care-of Keygen token and token, but MUST include a Binding Identifier
mobility option which with status value set to [MCOA MALFORMED] in the returned
Care-of Test message.

o Otherwise, the correspondent node MUST include a Binding
Identifier mobility option which with status value MUST be set to zero (success)
in the returning a CoT Care-of Test message.

o 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 identify the
corresponding
binding update Binding Update list by entry using the BID.

6.3. Processing Binding Update

If a Binding Update does not contain a Binding Identifier mobility
option, its processing is same as in [RFC-3775]. But if 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 one binding cache entry for the mobile
node. If the Binding Update is for de-registration, the receiver
MUST delete all existing bindings from its Binding Cache.

If a the Binding Update contains a Binding Identifier mobility
option(s), it is first validated according to section 9.5.1 of [RFC-3775] and the
following step.

o If the home registration flag is set in [RFC-
3775]. Then 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.

The receiver node MUST process processes the Binding Identifier mobility
option(s) as described 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.

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.

o The length value is examined. The length value MUST be either 4,
8, or 20 depending on C the 'C' and D flag. 'D' flags. If the length is
incorrect, the receiver MUST rejects reject the Binding Update and returns
the status value set to [MCOA MALFORMED].

o When C the 'C' flag is specified, set, the care-of address MUST be given present in
the Binding Identifier mobility option. Otherwise, If the care-of address is
not present, the receiver MUST reject the Binding Identifier
mobility option and returns the status value set to [MCOA
MALFORMED]. The operation of D 'D' flag is described in Section 8

o When multiple binding Binding Identifier mobility options are presented,
the receiver MUST support present in
the Binding Update, it is treated as bulk registration. Only a home
agent can accept If the bulk registration. Otherwise,
receiving node is a correspondent node, it MUST reject the Binding
Update and returns the status value in the binding acknowledgement
set to [MCOA BULK REGISTRATION NOT SUPPORT] in the Binding Acknowledgment.

o If the Lifetime field of in the Binding Update is set to zero, the receiver
receiving node deletes the binding entry which BID is same as that corresponds to the
BID sent by in the Binding Identifier mobility option. If the receiver receiving
node does not have an appropriate binding which BID is matched with for the Binding
Update, BID, it MUST
reject this de-registration the Binding Update for the
binding cache. If the receiver is and send a Home Agent, it SHOULD also
return the Binding Acknowledgement with
status value set to 133 [not Home Agent home agent for this mobile
node, 133]. node].

o If O the 'O' flag is set in the de-registering Binding Update, the
receiver can ignore this flag for de-registration. it is
ignored. If the H 'H' flag is set, the home agent stores a Home Address home
address in the Care-of Address field of the binding cache entry.
The home agent no
longer performs also stops performing proxy NDP ND for this the mobile node until this entry is
deleted.
node's home address.

o If the Lifetime field is not set to zero, the receiver receiving node
registers a binding with the specified BID as a mobile node's
binding. The Care-of address is picked obtained from the Binding Update
packet as follows:

* If C the 'C' flag is set in the Binding Identifier mobility
option, the care-of address must be taken is copied from the care-of address
field in
each the Binding Identifier mobility option.

* If C the 'C' flag is not set in the Binding Identifier mobility
option, the care-of address must be taken is copied from the Source Address source address
field of the IPv6 header.

* If C the 'C' flag is not set and an alternate care-of address is
present, the care-of address is taken copied from the Alternate
Care-of address mobility option.

o Once the care-of address(es) has have been retrieved from the Binding
Update, it starts registering the receiving nodes creates new binding(s).

* Only if O If only the 'O' flag is set in the Binding Identifier mobility
option, the home agent
first removes all the existing bindings and
registers the received bindings.

* If the receiver has a regular binding which does not have BID
for the mobile node, it de-registers must not process the regular binding and
registers update.
The receiver should sent a new binding including BID according acknowledgement with status
set to the Binding
Update. In this case, the receiver MUST return [MCOA BID CONFLICT].

* If the receiver node has already registered the has a binding which
BID is matched with requesting BID, then the same BID but
different care-of address, it MUST update the binding with the Binding Update and returns [0
respond with a Binding Acknowledgement with status set to 0
[Binding Update accepted].

* If the receiver does not have a binding entry which BID is
matched with for the requesting BID, it
registers a new binding for the BID and returns [0 responds with a Binding
Acknowledgement with status set to 0 [Binding Update accepted].

If all the above operations are successfully finished, the completed, a Binding
Acknowledgment
Acknowledgement containing the Binding Identifier mobility options
MUST be replied sent to the mobile node if A flag is set in the Binding
Acknowledgment. node. Whenever a Binding Acknowledgment Acknowledgement
is returned, sent, all the Binding Identifier mobility options stored in the
Binding Update MUST be copied to the Binding Acknowledgment. Acknowledgement except
the status field. The Care-of address field of in each Binding
Identifier mobility option, however, can be omitted, because the
mobile node can match a corresponding binding update list by entry using
the BID.

When a correspondent node sends a Binding Acknowledgement, the status
value MUST be always stored in the Status field of the Binding
Acknowledgement and the Status field of Binding Identifier mobility
option set to zero. For the home agent, the status value can be
stored in the Status field of either a Binding Acknowledgement 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 Acknowledgement so that the receiver can
examine the Status field of each Binding Identifier mobility option
for further operations.

6.4. Sending Binding Refresh Request

When a node (home agent or correspondent node) sends a Binding
Refresh Request for a particular binding
registering created with the BID, the
node SHOULD contain a include the Binding Identifier mobility option in the
Binding Refresh Request. If the mobile node had used bulk
registration, the sender SHOULD include all the Binding Identifier
mobility options. If the mobile node had not used bulk registration,
the sender includes the Binding Identifier mobility options only for
those bindings that need to be refreshed.

6.5. Receiving Packets from Mobile Node

When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address appeared that
appears in the Source Address source address field of the IPv6 header 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 discarded. The node
MUST also send a Binding Error message according to RFC3775. as specified in [RFC-3775].
This verification MUST NOT be done for a Binding Update.

7. Network Mobility Applicability

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].

Since the

The binding management mechanisms are the same for a mobile host operating that
uses Mobile IPv6 and for a mobile router operating that is using the NEMO Basic
Support (RFC 3963), our protocol [RFC-3963]. Therefore the extensions described in
this document can also be used to deal support a mobile router with
multiple care-of addresses registration sent from a multihomed
mobile router. Figure 5 shows an example format of a Binding Update
used by a mobile router.

IPv6 header (src=CoA, dst=HA)
IPv6 Home Address Option
ESP Header
Mobility header
-BU
Mobility Options
- Binding Identifier
- Mobile Network Prefix

Figure 5: NEMO Binding Update addresses.

8. DSMIPv6 Applicability

Dual Stack Mobile IPv6 (DSMIPv6) [ID-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.

8.1. IPv4 Care-of Address Registration

In DSMIPv6,

The mobile node can use the extensions described in the document to
register multiple care-of addresses, even if some of the care-of
addresses are IPv4 address.

Bulk registration MUST NOT be used for the initial binding update from an
IPv4 care-of address. This is because, the Binding Update and acknowledgment
binding acknowledgement exchange is used to detect NAT. Thus, when a NAT on the path
between the mobile node registers its IPv4 care-of
address bound to IPv6 and the home address, it MUST first attempt agent. So the mobile node needs
to send a
Binding Update with Binding Identifier mobility option independently.
The bulk registration MUST NOT be used check for the first binding update
of the a NAT between each IPv4 care-of address. address and the home
agent.

The Binding Update MUST be sent to the IPv4 home agent address by
using UDP and IPv4 headers as shown in Figure 6. 5. It is similar to [DSMIP]
[ID-DSMIPv6] except for using BID mobility
option instead of that the IPv4 care-of address option. option MUST NOT be
used when the BID mobility option is used.

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)

Figure 6: 5: Initial Binding Update for IPv4 Care-of Address

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].

If a NAT is not detected, the mobile node can update the IPv4 care-of
address by using BULK bulk registration. The mobile node can register the
IPv4 care-of address along with other IPv4 and IPv6 care-of
addresses. Figure 7 6 shows the binding update 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
follow the Figure 6 and store
more BID mobility options format described in the mobility options field. Figure 5. Note that the 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.

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)
- ...

Figure 7: 6: Binding Bulk Registration for IPv4 care-of address

If the IPv4 care-of address is successfully registered, the mobile
node sets up a relevant tunnel to the home agent according to
[DSMIP].

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.

8.2. IPv4 HoA Management

When the mobile node obtains wants to configure an IPv4 home address in
addition to the IPv6 home address, it MUST store can request for one using the
IPv4 Home Address option in the Binding Update. If the home agent
accepts the binding update, Binding Update, the mobile node can also now 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 bind
different set of care-of addresses to each home address.

The

According to [ID-DSMIPv6], the home agent MUST returns a binding acknowledgment and includes the IPv4 address
acknowledgment
acknowledgement option to in the mobile node Binding Acknowledgement only when a if the
mobile node
requests had requested for an IPv4 home address mobility management. In this case, this in the
corresponding Binding Update. The IPv4 address acknowledgement
option MUST be presented present before any BID options. option. The status field of
the IPv4 address acknowledgment acknowledgement option contains only the error code
regarding
corresponding to the IPv4 home address management. The error value of values
related to the IPv4 care-of address registration MUST be stored in
the BID mobility option.

9. IPsec and IKEv2 interaction

Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the
use of IPsec to protect signaling messages like Binding Updates,
Binding Acknowledgments Acknowledgements and return routability messages. IPsec may
also be used protect all reverse tunneled data traffic. The Mobile
IPv6-IKEv2 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 [RFC-4877] with
respect to the use of IKEv2 and IPsec.

o There is only one primary care-of address per mobile node.

o The primary care-of address is stored in the IPsec database for
tunnel encapsulation and decapsulation.

o 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.

o 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.

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.

9.1. Use of Care-of Address in the IKEv2 exchange

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.

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.

9.2. Transport Mode IPsec protected messages

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.

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.

9.3. Tunnel Mode IPsec protected messages

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.

9.3.1. Tunneled HoTi and HoT messages

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.

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.

9.3.2. Tunneled Payload Traffic

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.

o 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.

o 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.

10. Security Considerations

As shown in Section 9,

The security considerations for securing the Multiple Care-of Addresses Registration
requires IPsec protection Binding Update and
binding acknowledgement messages with multiple care-of address are
very similar to the security considerations for all securing the signaling between a mobile node Binding
Update and its home agent. binding acknowledgement. Please see [RFC-3775] for more
information. The Binding Update and binding acknowledgement messages
with multiple care-of addresses MUST be protected using IPsec as show
in Section 9. Additional security considerations are described
below.

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
MIP6ANALYSIS]. These attacks are possible because the care-of
addresses specified sent by the mobile node in the binding update Binding Update messages are
not verified by home agent, i.e., the home agent (since does not check if
the mobile node is at the care-of address it is claiming to be. The
security model for Mobile IPv6 assumes an existing that there is a trust
relationship between the mobile node and its home agent). agent. Any
malicious attack by the mobile node is traceable by the home agent.
This acts as a deterrent for the mobile node to launch such attacks.

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,
In Mobile IPv6, 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 degree of risk involved. In the single care-of
address binding case, once the re-
direction 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 re-
direction attacks.

Thus, in view of such risk, risks, 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
Solutions related to advert such problems this are described in Appendix. [ID-COAVERIFY].

11. IANA Considerations

The following Extension Types MUST be assigned by IANA:

o Binding Identifier mobility option type:This type: This must be assigned
from the same space as mobility option in [RFC3775]. [RFC-3775].

o New Successful Status of Binding Acknowledgment:This Acknowledgement: This status code
must be assigned from the same space as binding acknowledgement
status codes in [RFC3775]. [RFC-3775].

* MCOA NOTCOMPLETE (TBD)

o New Unsuccessful Status of Binding Acknowledgment: Acknowledgement: These status
codes must also be assigned from the same space as binding
acknowledgement status codes in [RFC3775]. [RFC-3775].

* MCOA MALFORMED (TBD)

* MCOA BID CONFLICT (TBD)

* MCOA PROHIBITED(TBD)

* MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

12. Acknowledgments Acknowledgements

The authors would like to thank Masafumi Aramoto (Sharp Corporation), Aramoto, George Tsirtsis (Qualcomm), Tsirtsis,
Keigo Aso (Panasonic), Aso, Julien Charbon, Tero Kauppinen (Ericsson), Kauppinen, Benjamin Lim (Panasonic), Lim, Susumu
Koshiba, Martti Kuparinen (Ericsson), Kuparinen, Romain Kuntz (Keio-U), Kuntz, Heikki Mahkonen
(Ericsson), Mahkonen, Hiroki Matutani (Tokyo-U),
Matutani, Koshiro Mitsuya (Keio-U), Mitsuya, Nicolas Montavont, Koji Okada (Keio-U), Okada, Keisuke Uehara (Keio-U),
Uehara, Masafumi Watari (KDDI R&D) in alphabetical order, and the Jun Murai Lab.
Laboratory at the KEIO University.

13. References

13.1. Normative References

[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998.

[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.

[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.

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.

[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.

[RFC-4886] Ernst, T., "Network Mobility Support Goals and
Requirements", RFC 4886, July 2007.

[RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.

13.2. Informative References

[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

[RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", RFC 4980, October 2007.

[RFC-3972] Aura,

[ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.

[RFC-4866] Arkko, J., Vogt, Ng, C., and W. Haddad, "Enhanced Route
Optimization for
K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", RFC 4866, May
draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
2007.

[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,

[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC
792, September 1981. 3753, June 2004.

[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.

[ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work in
progress), November 2007.

[ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of Care-of
Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-01 (work in progress), February
2008.

Appendix A. Example Configurations

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. home address. The Home Address 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.

+----+
| 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]

Figure 8: 7: Multiple Interfaces Attached to a Foreign Link

Figure 8 7 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 correspondent node (CN) have the binding entries
listed in their binding cache database. The mobile node can utilize
all the interfaces.

+----+
| 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]

Figure 9: 8: One of Interface Attached to Home Link and Returning Home

Figure 9 8 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 Figure 9. 8. 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.

+----+
| 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]

Figure 10: 9: One of Interface Attached to Home Link and Not Returning
Home

Figure 10 9 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.

Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+

Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +========+ |
+--+--+ CoA1 |
CoA3 | |
+---------------------------+

Figure 11: 10: Utilize Interfaces Attached to both Home and Foreign Links

Figure 11 10 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 Figure 11 10 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.

There are two different treatments of the ND state of the home
address.

o MN defends the home address by regular ND (topology-a)

o HA defends the home address by Proxy ND (topology-b)

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
address 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.

Appendix B. Changes From Previous Versions

Changes from draft-ietf-monami6-multiplecoa-04.txt

o Binding Unique Identifier is renamed to Bidning Identifier

o 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.

o [MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED]

o Add care-of address verification issue in the Security
Consideration, the text is proposed by Benjamin Lim.

o Support DSMIPv6

o Support simultaneous foreign and home location. (Section 5.5)

o Editorial updates, thanks George Tsirtsis for detailed comments!

Authors' Addresses

Ryuji Wakikawa (Editor)
Faculty of Environment and Information Studies, Keio University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan

Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France

Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
Email: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry

Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo 135-0075
Japan

Phone: +81-3-5565-5069
Fax: +81-3-5565-5094
Email: nagami@inetcore.com

Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA

Email: vijay.devarapalli@azairenet.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).