Monami6 Working Group R. Wakikawa
Internet-Draft Keio University
Expires: August 5, 2006 T. Ernst
Keio University / WIDE
K. Nagami
INTEC NetCore
February 2006
Multiple Care-of Addresses Registration
draft-wakikawa-mobileip-multiplecoa-05
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 August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
Wakikawa, et al. Expires August 5, 2006 [Page 1]
Internet-Draft MCoA February 2006
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.
Wakikawa, et al. Expires August 5, 2006 [Page 2]
Internet-Draft MCoA February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Multiple Care-of Addresses Registration . . . . . . . . . 8
3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 8
3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 9
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11
4.1. Binding Cache Structure and Management . . . . . . . . . . 11
4.2. Binding Update Structure and Management . . . . . . . . . 11
4.3. Message Format Changes . . . . . . . . . . . . . . . . . . 11
4.3.1. Binding Unique Identifier sub-option . . . . . . . . . 11
4.3.2. Binding Update . . . . . . . . . . . . . . . . . . . . 12
4.3.3. Binding Acknowledgment . . . . . . . . . . . . . . . . 13
5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14
5.1. Management of Care-of Addresses and Binding Unique
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Sending Binding Update . . . . . . . . . . . . . . . . . . 14
5.3. Sending De-Registration Binding Update . . . . . . . . . . 15
5.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Using Alternate Care-of Address . . . . . . . . . . . . . 16
5.6. Receiving Binding Acknowledgment . . . . . . . . . . . . . 16
5.7. Receiving Binding Refresh Request . . . . . . . . . . . . 17
5.8. Receiving Binding Error . . . . . . . . . . . . . . . . . 18
6. Home Agent and Correspondent Node Operation . . . . . . . . . 19
6.1. Searching Binding Cache with Binding Unique Identifier . . 19
6.2. Receiving Binding Update . . . . . . . . . . . . . . . . . 19
6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . . 21
6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 21
6.5. Sending Binding Error . . . . . . . . . . . . . . . . . . 21
7. Network Mobility Applicability . . . . . . . . . . . . . . . . 23
8. IPsec and IKE interaction . . . . . . . . . . . . . . . . . . 24
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Wakikawa, et al. Expires August 5, 2006 [Page 3]
Internet-Draft MCoA February 2006
Appendix A. Example Configurations . . . . . . . . . . . . . . . 27
Appendix B. Dynamic Home Agent Address Discovery . . . . . . . . 31
B.1. DHAAD Request . . . . . . . . . . . . . . . . . . . . . . 31
B.2. DHAAD Reply . . . . . . . . . . . . . . . . . . . . . . . 32
B.3. Home Agent Information Option . . . . . . . . . . . . . . 33
Appendix C. Change Log From Previous Versions . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Wakikawa, et al. Expires August 5, 2006 [Page 4]
Internet-Draft MCoA February 2006
1. Introduction
Permanent Internet connectivity is required by some applications
while a mobile node moves across several access networks (i.e. ISPs,
hotspots, etc). Unfortunately, there is no network interfaces
assuring global scale connectivity. Therefore, a mobile node should
use various type of network interfaces to obtain durable and wide
area network connectivity [8]. For example, it is desirable to
maintain the Internet connectivity while an automobile running on a
freeway receives voice or video streaming data from different access
networks. Such scenarios and motivations for multiple points of
attachment, and benefits for doing it are discussed at large in [9].
Once multiple interfaces are available to a mobile node, a backup
interface can be used to recover from the loss of Internet
connectivity on the other interface, therefrom maintaining Internet
connectivity of wide spread and reach. In addition, each
communication flow could be sent to a distinct network interface,
providing efficient network bandwidth consumption. It becomes
possible for users to select the most appropriate network interface
depending on a visiting network environment, since wireless networks
are mutable and less reliable than wired networks and since each
network interface has different cost, performance, bandwidth, access
range, and reliability. Users should also be able to select the most
appropriate interface per communication type. For example, TCP
traffic should be transmitted over the wireless interface, whereas
UDP traffic should be transmitted over the wired interface to avoid
disturbing TCP connections.
IPv6 [1] conceptually allows a node to have several addresses on a
given interface. Consequently, Mobile IPv6 [2] 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 given
network interface is more advantageous than assigning multiple Home
Addresses because applications do not need to be aware of the
multiplicity of Home Addresses. Of course, applications should be
aware of the active Home Address to be used for communicating. At
the TCP layer, TCP holds the Home Address as a source address of the
communication for connection management. Applications must be
restarted to reset the connection information when the mobile node
changes its active network interface (i.e. change the Home Address).
However, according to section 11.5.3 of the Mobile IPv6
specification, a mobile node is not allowed to register multiple
Care-of Addresses bound to a single Home Address. If a mobile node
sends Binding Updates for each Care-of Address, correspondent nodes
would always overwrite the Care-of Address recorded in the binding
Wakikawa, et al. Expires August 5, 2006 [Page 5]
Internet-Draft MCoA February 2006
cache with the one contained in the latest received binding update.
It is thus impossible for a mobile node to register multiple Care-of
Addresses in the correspondent node's binding cache. Moreover, since
NEMO Basic Support [3] is based on Mobile IPv6, the same issues
applies to a mobile node acting as mobile router.
Multihoming issues pertaining to mobile nodes operating Mobile IPv6
and mobile routers operating NEMO Basic Support are respectively
discussed [4] and [10].
In this document, we thus propose a new identification number called
Binding Unique Identification number (BID) for each binding cache
entry to accommodate multiple bindings registration. We also propose
extension of binding cache management to store the BID and a new sub-
option for binding update to carry the BID. The BID is assigned to
either the interfaces or Care-of Addresses bound to a single home
address of a mobile node. 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.
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.
Wakikawa, et al. Expires August 5, 2006 [Page 6]
Internet-Draft MCoA February 2006
2. Terminology
Terms used in this draft are defined in [2], [5] and [6]. In
addition or in replacement of these, the following terms are defined
or redefined:
Binding Unique Identification number (BID)
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 is generated to
register multiple bindings in the binding cache for a given
address in a way it cannot be duplicated with another BID. The
zero value and a negative value MUST NOT be used. After being
generated by the mobile node, the BID is stored in the Binding
Update List and is sent by the mobile node by means of a sub-
option of a 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.
The BID can be assigned to either a Care-of Address or an
interface depending on implementation choices 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 Unique Identifier sub-option
The Binding Unique Identifier sub-option is used to carry the BID.
Wakikawa, et al. Expires August 5, 2006 [Page 7]
Internet-Draft MCoA February 2006
3. Protocol Overview
We propose a new identification number (BID) to distinguish multiple
bindings pertaining to the same Home Address. The procedures for the
mobile node to register multiple bindings are described in the
paragraphs below.
3.1. Multiple Care-of Addresses Registration
Once a mobile node gets several IPv6 global addresses on distinct
interfaces, it MUST register these addresses with its home agent
(home registration). If the mobile node wants to register multiple
bindings to its home agent, it MUST generate a BID for each Care-of
Address and record it into the binding update list entry. The mobile
node then registers its Care-of Addresses by sending a Binding Update
with a Binding Unique Identifier sub-option. The BID MUST be put in
the Binding Unique Identifier sub-option. After receiving the
Binding Update, the home agent verifies the request and records the
binding in its binding cache. If the newly defined sub-option is
present in the Binding Update, the home agent MUST copy the BID from
the Binding Update to the corresponding field in the binding entry.
Even if there is already an entry for the mobile node, the home agent
MUST register a new binding entry for the BID stored in the Binding
Unique Identifier sub-option. The mobile node registers multiple
Care-of Addresses either independently (in individual BUs) or all at
once (in a single BU).
If the mobile node wishes to register its binding with a
correspondent node, it MUST start return routability operations
before sending a Binding Update. The mobile node MUST sends CoTI for
each Care-of Addresses and MUST receive CoT for each Care-of
Addresses. The mobile node also uses a BID generated for the home
registration to register them as individual bindings. The
registration step is the same as for the home registration except for
calculating authenticator by using Binding Unique Identifier sub-
option as well as the other sub-options specified in RFC 3775.
3.2. Multiple Bindings Management
The BID is used as a search key for a corresponding entry in the
binding cache in addition to the Home Address. When the home agent
checks the binding cache database for the mobile node, it searches a
corresponding binding entry with the Home Address and BID of the
desired binding.
The desired binding can be selected with policy and filter
information. If a mobile node registers a binding with priority
value, the priority can be a key to select a binding. The capability
Wakikawa, et al. Expires August 5, 2006 [Page 8]
Internet-Draft MCoA February 2006
of searching the desired binding enables load-sharing and QoS with
flow separation. However, this selection and flow separation are 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.
If a node has multiple bindings and its packets meant for the mobile
node are not delivered correctly, the node can change the binding
entry for the mobile node so as to recover the connection
immediately. The node can detect a binding invalidation by packets
loss or ICMP error messages such as ICMP_UNREACHABLE. This provides
redundancy for Mobile IPv6.
When one of the care-of addresses is changed, the mobile node sends a
Binding Update with the new Care-of Address and the corresponding
BID. The receiver of the Binding Update updates the binding which
BID fits the BID contained in the received Binding Unique Identifier
sub-option. The mobile node can manage each binding independently
owing to BID.
If the mobile node decides to register only single binding, it just
sends a Binding Update without a Binding Unique Identifier sub-option
(i.e. normal Binding Update). The receiver of the Binding Update
registers only a single binding for the mobile node. If the receiver
has multiple bindings, one binding is registered without BID and the
rest of bindings are deleted.
3.3. Returning Home
When the mobile node returns home, there are two situations, since
the home agent defends the mobile node's Home Address by using the
proxy neighbor advertisement. It is impossible to utilize all the
interfaces when one interface is attached to the home link and the
others are attached to foreign links. If the proxy Neighbor
Advertisement for the Home Address is stopped, packets are always
routed to the interface attached to the home link. If proxy is not
stopped, packets are never routed to the interface attached to the
home link. The decision whether a mobile node returns home or not is
up to implementors.
The first situation is when a mobile node wants to return home with
the home attached interface. In this case, the mobile node MUST de-
register all the bindings by sending a Binding Update which lifetime
set to zero. The mobile node MAY NOT put any Binding Unique
Identifier sub-option in this packet. Then, the receiver deletes all
Wakikawa, et al. Expires August 5, 2006 [Page 9]
Internet-Draft MCoA February 2006
the bindings from its binding cache database.
The second situation is when a mobile node does not want to return
home, though one of its interfaces is attached to its home link. The
mobile node 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 interface attached to the home link with the Binding Unique
Identifier sub-option. The receiver of the de-registration Binding
Update deletes only the correspondent binding entry from the binding
cache database. The home agent does not stop proxying neighbor
advertisement unless there are still bindings for the other
interfaces.
Wakikawa, et al. Expires August 5, 2006 [Page 10]
Internet-Draft MCoA February 2006
4. Mobile IPv6 Extensions
In this section are described the changes to Mobile IPv6 necessary to
manage multiple bindings bound to a same Home Address.
4.1. Binding Cache Structure and Management
The following additional items are required in the binding cache
structure, i.e.:
BID of the Binding Cache Entry
The BID is notified by the mobile node by means of a Binding
Unique Identifier sub-option. The value MUST be zero if the
Binding Unique identifier does not appear in a Binding Update.
Priority of the Binding Cache Entry
The priority is notified by the mobile node by means of a Binding
Unique Identifier sub-option.
4.2. Binding Update Structure and Management
The following additional items are required for the binding update
structure, i.e.:
BID
The BID MUST be generated whenever the mobile node registers
multiple bindings for its Home Address.
Priority
MUST be set if the priority field of a Binding Unique Identifier
is valid.
4.3. Message Format Changes
4.3.1. Binding Unique Identifier sub-option
If needed, the Binding Unique Identifier sub-option is included in
the Binding Update, Binding Acknowledgment, Binding Refresh Request,
or Binding Error messages.
Wakikawa, et al. Expires August 5, 2006 [Page 11]
Internet-Draft MCoA February 2006
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 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) | Priority |B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Figure 1: BID Sub-Option
Type
Type value for Binding Unique Identifier will be assigned later.
Binding Unique ID (BID)
The BID which is assigned to the binding carried in the Binding
Update with this sub-option. BID is 16-bit unsigned integer. A
value of zero is reserved.
Priority
The priority is assigned to each binding. The receiver can
utilize this priority to determine which binding is used to
deliver packets. The priority is 8-bit unsigned integer. A value
of zero indicates No Priority. The higher value has higher
priority.
Bulk Registration (B) flag
When this flag is set, a mobile node can piggyback several Care-of
Addresses into a binding update. The mobile node must use a
Care-of Address stored in an alternate Care-of Address sub-option
followed by the Binding Unique Identifier sub-option.
Reserved
15 bits Reserved field. Reserved field must be set with all 0.
4.3.2. Binding Update
No modification to Binding Update. A mobile node stores a Binding
Unique Identifier option in the Mobility Options field of a Binding
Update.
Wakikawa, et al. Expires August 5, 2006 [Page 12]
Internet-Draft MCoA February 2006
4.3.3. Binding Acknowledgment
The message format of Binding Acknowledgment is not changed, but
operations listed below are added in this draft.
A receiver who gets a Binding Update with a binding unique identifier
option MUST reply with a Binding Acknowledgment if the 'A' flag is
also set or in case of a home registration. The receiver MUST also
send a Binding Acknowledgment with corresponding error codes if it
finds an error while processing the Binding Update and its sub-option
described in section Section 4.3.
If a Binding Update has a Binding Unique Identifier sub-option is
present, the receiver node MUST reply with a Binding Acknowledgment
containing the same Binding Unique Identifier sub-option. The mobile
node can process the Binding Acknowledgment for the particular
Care-of Address identified by the BID set in the Binding Unique
Identifier sub-option.
A new number is defined for handling the multiple Care-of Addresses
registration:
TBD (144)
It implies conflicting a regular binding and a binding that has
BID in binding cache. The regular binding indicates the binding
that does not have BID field. The status value is TBD.
TBD (145)
It implies that the bulk binding registration is failed. The
status value is TBD.
Wakikawa, et al. Expires August 5, 2006 [Page 13]
Internet-Draft MCoA February 2006
5. Mobile Node Operation
5.1. Management of Care-of Addresses and Binding Unique Identifier
There are two cases when a mobile node has several Care-of Addresses:
1. A mobile node uses 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
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.
The difference between the above two cases is only a number of
physical network interfaces and therefore does not matter. The
Identification number is used to distinguish multiple bindings so
that the mobile node assigns an identification number for each
Care-of Addresses. How to assign an identification number is up to
implementors.
A mobile node assigns a BID to each Care-of Address when it wants to
simultaneously register with its Home Address. The value should be
generated from a value comprised between 1 to 65535. Zero and
negative value can not be taken 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.
5.2. Sending Binding Update
When a mobile node sends a Binding Update, it MUST decide whether it
registers multiple Care-of Addresses or not. However, this decision
is out-of scope in this document. If a mobile node decides not to
register multiple Care-of Addresses, it completely follows standard
RFC 3775 specification.
On the other hand, if the mobile node needs to register multiple
Care-of Addresses, it MUST use BIDs to identify a Care-of Address.
The mobile node puts a Binding Unique Identifier sub-option into the
Option field of the Binding Update. The BID is copied from a Binding
Update List to the Binding Unique Identifier sub-option. If the
mobile node registers bindings to a correspondent node, it MUST sends
multiple CoTI for multiple Care-of Addresses. After getting CoTs, it
sends Binding Updates with a Binding Unique Identifier sub-option for
all Care-of Addresses. In any case, the mobile node MUST set the 'A'
flag in Binding Updates and MUST wait for a Binding Acknowledgment to
confirm the registration was successful as described in section
Section 5.6.
Wakikawa, et al. Expires August 5, 2006 [Page 14]
Internet-Draft MCoA February 2006
Note that there is an optimization for registering multiple Care-of
Addresses by using a single Binding Update, although the current
Mobile IPv6 specification does not allow to send multiple bindings by
means of a single Binding Update. In this case, a mobile node sets
the B flag into a Binding Unique Identifier sub-option and stores the
particular Care-of Address in an alternate Care-of Address sub-option
followed by the Binding Unique Identifier sub-option. The mobile
node can store multiple sets of a Unique Binding Identifier sub-
option and an Alternate Care-of Address sub-option in a Binding
Update. All the other binding information such as Lifetime, Sequence
Number, binding Flags are shared among the bulk Care-of Addresses.
Whether a mobile node registers multiple Care-of Addresses
respectively or not is up to implementations.
5.3. Sending De-Registration Binding Update
When a mobile node decides to delete all bindings for its home
address, it sends a regular de-registration Binding Update (i.e.
exclusion of a Binding Unique Identifier sub-option). See
Section 6.2 for details.
If a mobile node wants to delete a particular binding from its home
agent and correspondent nodes (ex. from foreign link), it MUST sends
a Binding Update which lifetime is set to zero. If only single
Care-of Address is removed by a Binding Update, the mobile node
simply set zero lifetime in a Binding Update and contains the single
correspondent Unique Binding Identifier Sub-option (B flag must be
unset). The receiver will remove only the Care-of Address which is
retrieved from the Source Address field of the IPv6 header. On the
other hand, if the mobile node wants to remove multiple Care-of
Addresses at once, it stores multiple Unique Binding Identifier sub-
options and Alternate Care-of Address sub-options in a Binding
Update. The Care-of Addresses stored in the Alternate Care-of
Address sub-options will be all removed.
5.4. Returning Home
When a mobile node returns home, it MUST de-registers all the binding
from the Home Agent.
Although the mobile node MUST deletes the binding at correspondent
nodes as well, the node can still keep the binding of the other
interface active attached to foreign links at the correspondent
nodes. In such case, the mobile node still receives packets at the
other interface attached to a foreign link thanks to route
optimization. The mobile node also receives packets at the interface
attached to the home link when correspondent nodes does not use route
optimization.
Wakikawa, et al. Expires August 5, 2006 [Page 15]
Internet-Draft MCoA February 2006
Note that when the 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. 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 interface by sending de-registration binding update. The de-
registration binding update must be 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.
5.5. Using Alternate Care-of Address
A mobile node can use an alternate Care-of Address in the following
situations.
o One Care-of Address becomes invalid (e.g because the link where it
is attached is no longer available) and MUST be deleted. In such
case, the mobile node can not sends a Binding Update from the
Care-of Address because the interface's link is lost. The mobile
node needs to de-register the remote binding of the Care-of
Address through one of its active Care-of Addresses.
o A mobile node has multiple interfaces, but it wants to sends
Binding Updates for all Care-of Addresses from a specific
interface which has wider bandwidth depending on interface's
characteristics. A mobile node does not want to send a lot of
control messages through an interface which bandwidth is scarce.
o A mobile node wants to register multiple Care-of Addresses in bulk
mode. The mobile node can store multiple Care-of Addresses with
correspondent BID into a Binding Update message.
In these cases, the mobile node sends a Binding Update with both
Alternate Care-of Address sub-option and Binding Unique Identifier
sub-option. If the B flag is unset in a Binding Unique Identifier
sub-option, the BID in a Binding Unique Identifier sub-option is
assigned for the Care-of Address in the Alternate Care-of Address
sub-option. If the B flag is set, the BID in a Binding Unique
Identifier sub-option is assigned for the Care-of Address in the
followed Alternate Care-of Address sub-option.
5.6. Receiving Binding Acknowledgment
The verification of a Binding Acknowledgment is the same as in Mobile
Wakikawa, et al. Expires August 5, 2006 [Page 16]
Internet-Draft MCoA February 2006
IPv6 (section 11.7.3 of RFC 3775). The operation for sending a
Binding Acknowledgment is described in Section 6.3.
If a mobile node sends a Binding Update with a Binding Unique
Identifier sub-option, a Binding Acknowledgment MUST have a Binding
Unique Identifier sub-option in the Mobility options field. If there
is no such sub-option, the originator node of this Binding
Acknowledgment might not recognize the Binding Unique Identifier sub-
option. The mobile node SHOULD stop registering multiple Care-of
Addresses by using a Binding Unique Identifier sub-option. If the
originator is the Home Agent, the mobile node MAY perform DHAAD to
discover a new Home Agent supporting the multiple Care-of Address
registration or give up the multiple Care-of Address registration.
If a Binding Unique Identifier sub-option is present, the mobile node
checks the Status field of the Binding Acknowledgment. If the status
code indicates successful registration (below 128), the originator
registers a binding information and BID for the mobile node
successfully.
If the status code is not zero regardless of Binding Unique
Identifier sub-option availability in Binding Acknowledgment, the
mobile node proceeds an relevant operations according to the status
code.
If the status code is 144, the mobile node has already registered a
regular binding before sending a Binding Update with a Binding Unique
Identifier sub-option. In such case, the mobile node SHOULD stop
sending Binding Updates without BID.
If the status code is 145, the mobile node should re-registers
multiple Care-of Addresses respectively. (i.e. not using the bulk
registration).
5.7. 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
Unique Identifier sub-option, this Binding Refresh Request requests a
binding indicated by the BID. The mobile node SHOULD update only the
respective binding. The mobile node MUST put a Binding Unique
Identifier sub-option into a Binding Update.
If no Binding Unique Identifier sub-option is present in a Binding
Refresh Request, the mobile node sends a Binding Update according to
Wakikawa, et al. Expires August 5, 2006 [Page 17]
Internet-Draft MCoA February 2006
its Binding Update List for the requesting node. 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.8. Receiving Binding Error
When a mobile node receives a Binding Error with a Binding Unique
Identifier sub-option, the message is for a binding indicated by the
BID in the Binding Unique Identifier sub-option. Further operations
except for the text below are identical as in RFC 3775. The
operation for sending BE is described in the section Section 6.5.
When a mobile node receives a Binding Error with Status field set to
2 (unrecognized MH Type value) , it MAY stop trying to register
multiple Care-of Addresses and registers only primary Care-of Address
as performed in Mobile IPv6.
Wakikawa, et al. Expires August 5, 2006 [Page 18]
Internet-Draft MCoA February 2006
6. Home Agent and Correspondent Node Operation
6.1. Searching Binding Cache with Binding Unique Identifier
If either a correspondent node or a home agent has multiple bindings
for a mobile node in its 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.
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. If the priority is
available for a binding cache entry, the priority can be used as
additional key to search a binding. In the below example, if a
correspondent node searches the binding with the 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 2: Searching the Binding Cache
A correspondent node basically learns the BID when it receives a
Binding Unique Identifier sub-option. At the time, the correspondent
node MUST look up its binding cache database with the Home Address
and the BID retrieved from Binding Update. If the correspondent node
does not know the BID, it searches 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.
6.2. Receiving Binding Update
If a Binding Update does not have a Binding Unique Identifier, the
processing of the regular Binding Update is the same as in RFC 3775.
But if the receiver already has multiple bindings for the Home
Address, it MUST overwrite all existing bindings for the mobile node
with 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 for the
Wakikawa, et al. Expires August 5, 2006 [Page 19]
Internet-Draft MCoA February 2006
mobile node.
On the other hand, if a Binding Update contains a Binding Unique
Identifier sub-option, a receiver node MUST operate additional
validations as follows:
o A receiver node MUST validate the Binding Update according to
section 9.5.1 of RFC 3775.
o If the Binding Unique Identifier sub-option is present, the
receiver node MUST process the Binding Update.
o If the Binding Unique Identifier sub-option has B flag set and no
alternate Care-of Address sub-option can be found, the receiver
node MUST send a binding acknowledgment with status code set to
145.
o If the Lifetime field is not zero, the receiver node registers a
binding that includes the BID as a mobile node's binding.
* If the B flag is set in the Binding Unique Identifier sub-
option, the Care-of Address must be taken from the followed
Alternate Care-of Address sub-option.
* If the B flag is not set in the Binding Unique Identifier sub-
option, the Care-of Address must be taken from the Source
Address field of the IPv6 header.
* If the receiver does not have any binding for the mobile node,
it registers a binding which includes BID field.
* 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 send Binding
Acknowledgment with status code set to 144.
* If the receiver node has already registered the binding which
BID is matched with requesting BID , then it MUST update the
binding up-to-date with the Binding Update. Meanwhile, 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.
o If Lifetime field is zero, the receiver node deletes the
registering binding entry which BID is same as BID sent by the
Binding Unique Identifier sub-option. If the receiver node does
not have appropriate binding which BID is matched with the Binding
Wakikawa, et al. Expires August 5, 2006 [Page 20]
Internet-Draft MCoA February 2006
Update, it MUST reject this de-registration Binding Update. If
the receiver is a Home Agent, it SHOULD also return a Binding
Acknowledgment to the mobile node, in which the Status field is
set to 133 (not home agent for this mobile node).
6.3. Sending Binding Acknowledgment
If a Binding Update does not contain a Binding Unique Identifier sub-
option, the receiver, either a correspondent node or a home agent,
MUST reply with a Binding Acknowledgment according to section 9.5.4
of RFC 3775. Otherwise, whenever the BID sub-option is present, the
receiver MUST follow the additional procedure below. The receiver
MUST reply with a Binding Acknowledgment whether the 'A' flag is set
or not in the Binding Update.
If the receiver successfully registers a binding for the BID stored
in a Binding Unique Identifier sub-option, it returns a Binding
Acknowledgment with Status field set to successful value (0 to 128)
and a Binding Unique Identifier sub-option copied from the received
Binding Update. If the receiver deletes the existing binding which
does not have a BID and registers a new binding for the BID, it MUST
return a Binding Acknowledgment with Status field set to '144'. On
the other hand, if the node encounters an error during the processing
of a Binding Update, it must return a Binding Acknowledgment with an
appropriate error number as described in RFC 3775. The node SHOULD
put a Binding Unique Identifier sub-option if the BID is available
for the Binding Acknowledgment.
6.4. Sending Binding Refresh Request
When either a correspondent node or Home Agent notices that a
registered binding will be expired soon, it SHOULD send a Binding
Refresh Request. If the registered binding has BID, the
correspondent node SHOULD contain a Binding Unique Identifier sub-
option in the Binding Refresh Request. Then, the correspondent node
can receive a Binding Update with a Binding Unique Identifier sub-
option and can update only the particular binding. If the registered
binding does not have BID, then the correspondent node sends a
Binding Refresh Request without the sub-option.
6.5. Sending Binding Error
When a correspondent node sends a Binding Error with Status field set
to 2 (Unrecognized MH Type value), it MAY put a Binding Unique
Identifier sub-option into Mobility Options field if BID is available
in a received binding message.
When a correspondent node receives data packets with a home address
Wakikawa, et al. Expires August 5, 2006 [Page 21]
Internet-Draft MCoA February 2006
destination option, it verifies the IPv6 source address field. If
the source address is not registered in the correspondent node's
binding cache, the correspondent node MUST return a Binding Error to
the sender with the status set to zero (Unknown binding for Home
Address destination option). The correspondent node can not put a
Binding Unique Identifier sub-option, because there is no binding
cache entry for the source address.
Wakikawa, et al. Expires August 5, 2006 [Page 22]
Internet-Draft MCoA February 2006
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 [7]
Issues regarding mobile routers with multiple interfaces and other
multihoming configurations are documented in [10].
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.
Wakikawa, et al. Expires August 5, 2006 [Page 23]
Internet-Draft MCoA February 2006
8. IPsec and IKE interaction
TBA
Wakikawa, et al. Expires August 5, 2006 [Page 24]
Internet-Draft MCoA February 2006
9. Conclusion
In this document, we propose a solution to achieve multihomed mobile
node on Mobile IPv6 and Network Mobility. A binding unique
identifier is introduced to register multiple care-of addresses to a
home agent and a correspondent node. Those care-of addresses are
bound to the same home address. A few modifications to Mobile IPv6
and NEMO are required to support multiple care-of address
registration.
Wakikawa, et al. Expires August 5, 2006 [Page 25]
Internet-Draft MCoA February 2006
10. Acknowledgments
The authors would like to thank Masafumi Aramoto (Sharp Corporation),
Julien Charbon, Susumu Koshiba, Romain Kuntz (Keio-U), 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, and
WIDE project for their contributions.
11. References
11.1. Normative References
[1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
IETF RFC 2460, December 1998.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-00 (work in progress),
February 2006.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress),
February 2006.
[7] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-05 (work in progress),
October 2005.
11.2. Informative References
[8] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
Networks", Journal Mobile Networks and Applications, vol. 3,
number 4, pages 335-350, 1998.
[9] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses",
Wakikawa, et al. Expires August 5, 2006 [Page 26]
Internet-Draft MCoA February 2006
draft-ietf-monami6-multihoming-motivations-scenarios-00 (work
in progress), February 2006.
[10] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-05 (work in progress),
February 2006.
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.
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 Addresses.
Figure 3 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.
Wakikawa, et al. Expires August 5, 2006 [Page 27]
Internet-Draft MCoA February 2006
+----+
| 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 3: Multiple Interfaces Attached to a Foreign Link
Figure 4 depicts the scenario where MN returns home by 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 4. 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 when MN is
attached to the home link, it can still send Binding Updates for
other active Care-of Addresses (CoA2 and CoA3). If CN has bindings,
packets are routed to each Care-of Addresses directly. Any packet
arrived at HA are routed to the primary interface.
Wakikawa, et al. Expires August 5, 2006 [Page 28]
Internet-Draft MCoA February 2006
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +--------+-+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ | |
+--+--+ | | |
CoA3| +---|-----------+
+---------------+
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]
binding [a:b:c:d::EUI Care-of Address3 BID3]
Figure 4: One of Interface Attached to Home Link and Returing Home
Figure 5 depicts the scenario where a MN disable the interface
attached to the home link and communicates with the interfaces
attached to foreign links. The HA and the CN have the binding
entries listed in their binding cache database. MN disable the
interface attached to the home link, because the HA still defends the
home address of the MN by proxy neighbor advertisements. 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.
Wakikawa, et al. Expires August 5, 2006 [Page 29]
Internet-Draft MCoA February 2006
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +========+ |
+--+--+ CoA1 |
| |
+---------------------------+
(Disable interface)
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]
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 5: One of Interface Attached to Home Link and Not Returing
Home
Figure 6 depicts the scenario where multiple interfaces of MN are
attached to the home link. The HA and the CN have the binding
entries listed in Figure 6 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.
Wakikawa, et al. Expires August 5, 2006 [Page 30]
Internet-Draft MCoA February 2006
+----+
| 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]
Figure 6: Several Interfaces Attached to Home Link and Returning Home
Appendix B. Dynamic Home Agent Address Discovery
The Dynamic Home Agent Address Discovery (DHAAD) defined in RFC 3775
is extended so that Mobile Nodes or Mobile Routers only register
multiple Care-of Addresses with Home Agents that support multiple
Care-of Addresses registration. This is optional operations.
However, we do not provide a solution for Mobile Nodes that would
like to register multiple Care-of Addresses only with Correspondent
Nodes that support multiple Care-of Addresses registration.
B.1. DHAAD Request
A new 'B' flag is introduced in the DHAAD Request message in order to
discover Home Agents supporting the multiple Care-of Address
registration.
Wakikawa, et al. Expires August 5, 2006 [Page 31]
Internet-Draft MCoA February 2006
0 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHAAD Request
Multiple Care-of Addresses (B) Flag
This flag is set when the mobile node wants to discover Home
Agents that support multiple Care-of Addresses registration.
B.2. DHAAD Reply
A new 'B' flag is introduced in the DHAAD Reply message. When a Home
Agent receives a DHAAD Request message with the Multiple Care-of
Addresses support Flag set, it MUST reply with a list of Home Agents
supporting the multiple Care-of Addresses registration. The 'B' flag
MUST be set in the DHAAD Reply.
0 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DHAAD Reply
Wakikawa, et al. Expires August 5, 2006 [Page 32]
Internet-Draft MCoA February 2006
Mobile Router (R) Flag
This flag is used by NEMO Basic Support [3]
Multiple Care-of Addresses (B) Flag
This flag is set when the Home Agents listed in this message
supports multiple Care-of Addresses registration.
B.3. Home Agent Information Option
A new 'B' flag is introduced in the Home Agent Information Option.
The home agent SHOULD set the flag if it supports multiple Care-of
Addresses registration.
0 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 | Length |R|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Home Agent Information Option
Mobile Router (R) Flag
This flag is used by NEMO Basic Support [3]
Multiple Care-of Addresses (B) Flag
This flag is set when the Home Agents listed in this message
supports multiple Care-of Addresses registration.
Wakikawa, et al. Expires August 5, 2006 [Page 33]
Internet-Draft MCoA February 2006
Appendix C. Change Log From Previous Versions
Changes from draft-wakikawa-mobileip-multiplecoa-04.txt
o Updating packet formats. B flag in Binding Update is removed.
o Updating packet formats. B flag in Unique Binding Identifier sub-
option is introduced for bulk registration.
o Bulk Registration is now supported.
o The distinction of primary and non-primary is obsoleted.
o IPsec and IKE interaction will be added shortly.
o The priority is introduced instead of primary and non-primary.
This priority is from comment by Monami6 WG. The specification
may not be completed, but if the document become WG, we will
complete the spec.
o The DHAAD extension is optional extension. (moved to Appendix)
Wakikawa, et al. Expires August 5, 2006 [Page 34]
Internet-Draft MCoA February 2006
Authors' Addresses
Ryuji Wakikawa
Keio University
Department of Environmental Information, 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
Keio University / WIDE
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
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
Wakikawa, et al. Expires August 5, 2006 [Page 35]
Internet-Draft MCoA February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wakikawa, et al. Expires August 5, 2006 [Page 36]