Monami6 Working Group                               R. Wakikawa (Editor)
Internet-Draft                                           Keio University
Intended status: Standards Track                                T. Ernst
Expires: January 10, May 22, 2008                                              INRIA
                                                               K. Nagami
                                                           INTEC NetCore
                                                          V. Devarapalli
                                                         Azaire Networks
                                                            July 9,
                                                       November 19, 2007

                Multiple Care-of Addresses Registration
                 draft-ietf-monami6-multiplecoa-03.txt
                 draft-ietf-monami6-multiplecoa-04.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 January 10, May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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

Table of Contents

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

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

   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Multiple Care-of Addresses Registration  . . . . . . . . .  7
     3.2.  Multiple Bindings Management . . . . . . . . . . . . . . .  7
     3.3.  Returning Home . . . . . . . . . . . . . . . . . . . . . .  8

   4.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Binding Cache Structure and Binding Update List  . . . . . 10
     4.2.  Message Format Changes . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Binding Unique Identifier sub-option . . . . . . . . . 10
       4.2.2.
     4.3.  New Status Values for Binding Acknowledgment . . . . . . . . . . . . . . . . 12

   5.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 14 13
     5.1.  Management of Care-of Addresses and Binding Unique
           Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 13
     5.2.  Return Routability: Sending CoTI and Receiving CoT . . . . 14 13
     5.3.  Binding Registration . . . . . . . . . . . . . . . . . . . 15 14
     5.4.  Binding Bulk Registration  . . . . . . . . . . . . . . . . 16 15
     5.5.  Binding De-Registration  . . . . . . . . . . . . . . . . . 16
     5.6. and Returning Home . . . . . . . . . . . . . . . . . . . . . . 17
     5.7.  Using Alternate care-of address  . . . . . . . . . . . . . 18
     5.8. 16
     5.6.  Receiving Binding Acknowledgment . . . . . . . . . . . . . 19
     5.9. 17
     5.7.  Receiving Binding Refresh Request  . . . . . . . . . . . . 20
     5.10. 18
     5.8.  Sending Packets to Home Agent  . . . . . . . . . . . . . . 20
     5.11. 19
     5.9.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 21 19

   6.  Home Agent and Correspondent Node Operation  . . . . . . . . . 22 21
     6.1.  Searching Binding Cache with Binding Unique 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  . . . . . . . . . . . . . 26 24
     6.5.  Receiving Packets from Mobile Node . . . . . . . . . . . . 26 25

   7.  Network Mobility Applicability . . . . . . . . . . . . . . . . 27 26

   8.  IPsec and IKEv2 interaction  . . . . . . . . . . . . . . . . . 28 27
     8.1.  Use of Care-of Address in the IKEv2 exchange . . . . . . . 28 27
     8.2.  Transport Mode IPsec protected messages  . . . . . . . . . 29 28
     8.3.  Tunnel Mode IPsec protected messages . . . . . . . . . . . 29 28
       8.3.1.  Tunneled HoTi and HoT messages . . . . . . . . . . . . 29 28
       8.3.2.  Tunneled Payload Traffic . . . . . . . . . . . . . . . 30 29

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31 30

   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32 31

   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 33 32
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 32
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 32
     12.2. Informative References . . . . . . . . . . . . . . . . . . 34 33

   Appendix A.  Example Configurations  . . . . . . . . . . . . . . . 34

   Appendix B.  Changes From Previous Versions  . . . . . . . . . . . 38 39

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 39
   Intellectual Property and Copyright Statements . . . . . . . . . . 40 41

1.  Introduction

   A mobile node should use various type of network interfaces to obtain
   durable and wide area network connectivity.  Assumed  The assumed scenarios
   and motivations for multiple points of attachment, and benefits for
   doing it are discussed at large in [10]. [ID-MOTIVATION].

   IPv6 [1] [RFC-2460] conceptually allows a node to have several addresses
   on a given interface.  Consequently, Mobile IPv6 [2] [RFC-3775] has
   mechanisms to manage multiple ``Home Addresses'' based on home
   agent's managed prefixes such as mobile prefix solicitation and
   mobile prefix advertisement.  But assigning a single Home Address to
   a node is more advantageous than assigning multiple Home Addresses
   because applications do not need to be aware of the multiplicity of
   Home Addresses.  If multiple home addresses are available,
   applications must reset the connection information when the mobile
   node changes its active network interface (i.e. change the Home
   Address).

   According to the Mobile IPv6 specification, a mobile node is not
   allowed to register multiple care-of addresses bound to a single Home
   Address.  Since NEMO Basic Support [3] [RFC-3963] is based on Mobile
   IPv6, the same issues applies apply to a mobile node acting as a mobile
   router.  Multihoming issues pertaining to mobile nodes operating
   Mobile IPv6 and mobile routers operating NEMO Basic Support are
   respectively discussed [4] [ID-MIP6ANALYSIS] and [11] [RFC-4980] in Monami6
   and NEMO Working Group.

   In this document, we thus propose a new identification number called
   Binding Unique Identification (BID) number for each binding cache
   entry to accommodate multiple bindings registration.  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  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.

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 [2], [5] [RFC-3775], [RFC-3753] and [6].
   [RFC-4885].  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 conceptually
      assigned to
      register multiple bindings in the binding cache for a given
      address binding 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 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 is conceptually assigned to a binding.  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 Unique Identifier sub-option

      The Binding Unique Identifier sub-option is used to carry the BID.

   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 which addresses.  A mobile node can be stored in a Binding Update. also replace all the
      bindings available at the home agent with the new bindings by
      using the bulk registration.  The bulk registration is supported
      only for home registration and deregistration as explained in
      Section 5.5.  Note that a  A mobile node should not try to MUST NOT perform bulk registration
      with correspondent nodes.

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

3.  Protocol Overview

   We propose a

   A new identification number (BID) is introduced 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 interfaces, it can
   register these addresses with its home agent (home
   registration). agent.  If the mobile node
   wants to register multiple
   bindings to its home agent, bindings, it MUST generate a BID for each
   care-of address and record it the BID into the binding update list.  A
   mobile node can manage each binding independently owing to BID.  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
   included in the Binding Unique Identifier sub-option.  After
   receiving the such Binding
   Update, the home agent verifies the request Update and records the binding
   in its binding cache.  If the newly defined sub-option is present in
   the Binding Update, Unique Identifier sub-
   option, the home agent MUST copy the BID from the Binding
   Update Unique
   Identifier sub-option to the corresponding field in the binding cache
   entry.  Even if there is already an entry for the mobile node, node's home
   address, 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 in
   individual BUs) Binding Updates or multiple at once (in in a single BU). Binding
   Update.

   If the mobile node host wishes to register its binding with a
   correspondent node, it must operate return routability operations.
   The mobile node host MUST manage a Care-of Keygen Token per care-of
   address.  If it is necessary (ex.  Care-of Keygen token is expired),
   the mobile node host exchanges CoTI and CoT for the releative relative care-of
   addresses.  When the mobile node host registers several care-of addresses
   to a correspondent node, it uses the same BID as the one generated
   for the home registration's bindings.  The binding registration step
   is the same as for the home registration except for calculating
   authenticator by using Binding Unique Identifier sub-option as well
   as the other sub-options specified in RFC 3775. [RFC-3775].  For simplicity,
   the bulk registration is not supported for correspondent nodes in
   this document.

3.2.  Multiple Bindings Management

   If the mobile node decides to act as a regular mobile node compliant
   with [RFC-3775] , it just sends a Binding Update without any Binding
   Unique Identifier sub-options (i.e. normal Binding Update).  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 to use BID even if only a
   single binding is active at some time.

   The BID is used as a search key for a corresponding entry in the
   binding cache in addition to the Home Address.  When a home agent and
   a correspondent node check the binding cache database for the mobile
   node, it searches they search a corresponding binding entry with the Home Address
   and BID of the desired binding.  If necessary, a mobile node can use
   policy and filter information to look up the best binding per
   sessions, flow, packets, but this is out of scope in this document
   and is currently discussed in Monami6 WG.  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.

   When one of the care-of addresses has changed, the

   A 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 matches the BID contained in carefully operates the received Binding Unique
   Identifier sub-option. returning home.  The mobile node can manage each binding
   independently owing to BID.

   If the mobile node decides Home Agent
   needs to act as defend a regular mobile node compliant
   with [2] , it just sends a Binding Update without a Binding Unique
   Identifier sub-option (i.e. normal Binding Update).  The receiver of node's home address by the Binding Update registers only a single binding proxy NDP for
   packet interception, while the mobile node and, if necessary, deletes all the bindings registering with a
   BID.  Note that the mobile node can continue to use BID even if only
   a single binding is active at some time.

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 its home address
   by using the
   proxy neighbor advertisement.  It is impossible regular NDP to utilize all send and receive packets at the
   interfaces when one interface is attached
   to the home link link.  Two nodes, Home Agent and Mobile Node, compete ND
   state.  This will causes address duplication problem at the
   others are attached to foreign links. end.  If
   the proxy Neighbor
   Advertisement 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,
   On the other hand, 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 implementers.

   The first situation is link when the proxy is active.

   When a mobile node wants to return home with interface attached to
   the home link.  In this case, the mobile node link, it MUST de-register all the bindings by sending a
   Binding Update with lifetime set to zero.  The mobile node MAY NOT zero as described in [RFC-3775]
   and [RFC-3963].  The mobile node does not put any Binding Unique
   Identifier sub-option in this packet.  Then, the Binding Update.  The receiver deletes
   all the bindings from its binding cache database.  A home agent MUST stop
   proxy neighbor advertisement for the home address of  On the mobile node.

   The second situation is when other hand,
   a mobile node does not want to return
   home, though home and keeps the interfaces
   attached to the foreign links active, when 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 de-
   registration Binding Update including the BID for the interface
   attached to the home link with the Binding Unique
   Identifier sub-option. link.  The receiver of the de-registration
   Binding Update deletes only the relative binding entry from the
   binding cache database.  The home agent does not stop proxying
   neighbor advertisement as long as there are still bindings for the
   other interfaces.  It is important to understand that this scenario
   is not the most efficient because all the traffic from and to the
   mobile node is going through the bi-directional tunnel, whereas the
   mobile node is now accessible at one hop from its HA. home agent.

   In the above two cases, a mobile node cannot use interfaces attached
   to both home and foreign links simultaneously.  This restriction is
   related to the Proxy NDP operation on a Home Agent.  The Home Agent
   needs to defend a mobile node's home address by the proxy NDP for
   packet interception, while the mobile node defends its home address
   by regular NDP to send and receive packets at the interface attached
   to the home link.  Two nodes, Home Agent and Mobile Node, compete ND
   state.  This will causes address duplication problem at the end.
   This document recommends not to use the Proxy NDP for this scenario.
   When one of the Mobile Node's interface is attached to the home link
   and the other is attached to the foreign link and it decides to
   utilize both interfaces, it notifies the Home Agent using the H flag
   which means the Mobile Node is attached to the home link.  If the proxy NDP is
   disabled, the main problem can be solved.  In the Multiple Care-of
   Address Registration case, Registration, the elimination of Proxy NDP enable enables that
   Mobile Node and Home Agent maintain multiple
   bindings, one of bindings for the Mobile Node's interface is
   interfaces attached to the home link and the other is foreign links.  The
   mobile node sends the binding update with H flag set for the
   interface attached to the foreign home link.  The detail operation can be
   found in Section 5.5.

4.  Mobile IPv6 Extensions

   In this

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

4.1.  Binding Cache Structure and Binding Update List

   The following additional items are BID is required in the binding cache and binding update list
   structure.

   BID

      The value MUST be zero if the Binding Unique identifier does not
      appear in a Binding Update.

4.2.  Message Format Changes

4.2.1.  Binding Unique Identifier sub-option

   The Binding Unique Identifier sub-option is included in the Binding
   Update, Binding Acknowledgment, 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 Unique ID (BID)   |     Status    |C|O|H|Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       +                    care-of address (CoA)                      +
       +                                                               +
       +---------------------------------------------------------------+

                         Figure 1: BID Sub-Option

   Type

      Type value for Binding Unique Identifier will be assigned later. is TBD

   Length

      Length value MUST be 4 when C flag is unset.  On  Otherwise, the other hand if
      C flag is set,
      Length value MUST be set to 20.

   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.

   Status

      When the Binding Unique Identifier sub-option is included in a
      Binding Acknowledgment, this field indicates overwrites the status field
      correspondent to each binding.  The mobile node knows binding in the Binding Acknowledgment.  If
      this field is zero, the receiver MUST use the registration status of each binding.
      stored in the Binding Acknowledgment message.  This Status field
      can be used to carry error information for a Care-of Test message.
      The status is 8-bit unsigned integer.  The possible status codes
      are listed below.  If the
      status field is below 128, it indicates that the binding
      registration was successful.

      MCOA ACCEPTING BID (0)

         The registration of same as the correspond binding is successfully
         operated.

      MCOA REASON UNSPECIFIED (128)

         Registration failed because status codes of unknown errors

      MCOA INCOMPLIANT (129)

         Registration failed because Binding Unique Identifier sub-
         option is not compliant.

      MCOA BID CONFLICT (130)

         It indicates that a regular binding (ie without the BID set) is
         already registered for the home address, and is conflicting
         with a received Binding Update which BID was set.

   care-of Acknowledgment.

   Care-of address (C) flag

      When this flag is set, a mobile node can store a Care-of Address
      corresponding to the BID in the Binding Unique Identifier sub-
      option.  This flag must be used whenever a mobile node sends
      multiple bindings in a single Binding Update, i.e. bulk
      registration.
      registration or MUST be used as a substitute for an alternate
      care-of address option.  This flag is valid only for binding
      update for the home agent.

   Overwrite (O) flag

      When this flag is set, a mobile node requests a home agent to
      replace all the bindings to binding entries stored in a Binding
      Update.  This flag is valid only for Home Registration and
      Deregistration. binding update for the home
      agent.

   Home Binding (H) flag

      This flag indicates that the mobile node is attached to the home
      link.  This flag is valid only for Home Registration, Deregistration
      and bulk registration. binding update for the home
      agent.

   Reserved

      5 bits Reserved field.  Reserved field must be set with all 0.

   Care-of Address

      Only when

      When C flag is set, only a single Care-of Address matched to the BID is
      stored.  This field is valid only if a Binding Unique Identifier
      sub-option is stored in Binding Update message.  Otherwise, this
      field can be omitted.  The receiver SHOULD ignore this field if
      the sub-option is presented in other than Binding Update.

4.2.2.

4.3.  New Status Values for Binding Acknowledgment

   The message format of

   New status values for the status field in a Binding Acknowledgment does not change, but
   operations listed below
   are added in this draft.

   If a defined for handling the multiple Care-of Addresses registration:

   MCOA INCOMPLIANT (TBD)

      Registration failed because Binding Unique Identifier sub-option
      is included in not compliant.

   MCOA BID CONFLICT (TBD)

      It indicates that a Binding
   Update with regular binding (i.e. without the A flag set, a receiver MUST reply a Binding
   Acknowledgment.  The receiver node MUST include the same Binding
   Unique Identifier sub-option(s) in the Binding Acknowledgment.  The
   receiver MUST specify relative status in the Status field of the
   Binding Acknowledgment.

   There are two status fields: the Status field of a Binding
   Acknowledgment and the Status field of a Binding Unique Identifier
   sub-option.  In this specification, the Status field of a Binding
   Acknowledgment indicates the registration status of a "Binding
   Update".  The status value in the Binding Acknowledgment BID set) is
      already registered for all
   Binding Unique Identifier sub-options stored in the Binding
   Acknowledgment.  For example, if the status value is 134 in the
   status field of the Binding Acknowledgment, all the care-of addresses
   stored in the Binding Unique Identifier sub-options are rejected
   because the duplicate address detection has failed on the home agent.

   The status field of the Binding Unique Identifier sub-option only
   informs the receiver about the binding relative to the sub-option.
   Whether each Care-of address has been successfully registered
   successfully or not address, and is given in the Status field of each Binding
   Unique Identifier sub-option.

   New status values for the status field of conflicting with a
      received Binding Acknowledgment
   are defined for handling the multiple Care-of Addresses registration: Update which BID is set.

   MCOA PROHIBITED(TBD)

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

   MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

      The bulk binding registration is not supported.

   MCOA FLAG CONFLICTS (TBD)

      The flags of the sub-options presented in a Binding Update Unique
      Identifier sub-options conflicts.

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 in this
   document.  The Identification number is used to identify a binding.
   To implement this, a mobile node MAY assign an identification number
   for each care-of addresses.  How to assign an identification number
   is up to implementers.

   A mobile node assigns a BID to each care-of address when it wants to
   register them simultaneously with its Home Address .  The value
   should be generated from a value comprised between 1 to 65535.  Zero
   and negative values MUST 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.  Return Routability: Sending CoTI and Receiving CoT

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

   If the Mobile Node manages bindings with BID, it MUST include a
   Binding Unique Identifier sub-option in a Care-of Test Init message.
   It MUST NOT set the C and O flag any flags in the sub-option.  The receiver (i.e.
   correspondent node) will calculate a care-of
   keygen Keygen token as
   specified in [2] [RFC-3775] and reply a Care-of Test message
   which contains a and the
   Binding Unique Identifier sub-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 [2] and the
   Binding Unique Identifier sub-option in the Care-of Test MUST be
   processed as follows:

   o [RFC-3775].  If a Binding
   Unique Identifier sub-option is not presented in CoT in reply to the
   CoTI containing the Binding Unique Identifier sub-
      option, a sub-option, the
   correspondent node does not support the Multiple Care-of Address
   registration.  Thus, the mobile node MUST NOT use a Binding Unique
   Identifier sub-option in the future Binding Update.  It
      MUST send a regular Binding Update (i.e. no BID) to the
      correspondent node [2].  The Mobile Node
   MAY skip resending regular CoTI message and use keep the received care-of keygen
   Keygen token for the regular Binding Update, because the
   correspondent node just ignores and skip the Binding Unique
   Identifier sub-option and calculates the care-of keygen Keygen token as [2]
   [RFC-3775] specified.

   o  If the status field of a Binding Unique Identifier sub-option is
      set to [MCOA INCOMPLIANT], the received care-of keygen token MUST
      NOT be used for sending a Binding Update.  It MUST re-send a
      Care-of Test Init message again with a corrected Binding Unique
      Identifier sub-option which C flag MUST be unset.

   o  If the status field is set to less than 128, it sends a Binding
      Update through Return Routability procedure.

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, this decision
   is out-of scope in this document.  If a mobile node decides not to
   register multiple care-of addresses, it completely follows the
   standard RFC 3775
   RFC3775 specification.

   If a mobile node needs to register

   For the multiple Care-of Addresses, it
   MUST use BID to identify a care-of address.  The Addresses registration, the mobile node includes MUST
   include a Binding Unique Identifier sub-option sub-option(s) in the Mobility
   Option field of a Binding Update. Update as shown in Figure 2.  The BID is
   copied from a corresponding Binding Update List entry to the BID
   field of the Binding Unique Identifier sub-option.  If the mobile node wants to replace existing registered
   bindings on the home agent to the  When ESP is used
   for binding entry(s) update, the care-of address MUST be stored in the Binding
   Update, it can set O flag.

   If Care-of
   Address field by setting C flag as a mobile node registers bindings substitute for the alternate
   care-of address option.  The alternate care-of address option MUST be
   omitted.  Additionally for binding registration to a correspondent
   node, it the mobile node MUST have both active home and care-of keygen Keygen
   tokens for Kbm (see Section 5.2.5 of [2]. [RFC-3775]).  The care-of keygen 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, value for the Binding
   Authorization sub-option, it sends a Binding Update which contains a
   Binding Unique Identifier sub-option.  The Binding Update is
   protected by a Binding Authorization Data sub-option placed after the
   Binding Unique Identifier sub-option.  The Mobile Node MUST NOT set
   the C flag in the

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header  (for home registration)
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Unique Identifier sub-option. sub-option
                          - Binding Authorization sub-option
                            (for Route Optimization)

             Figure 2: Binding Update for Binding Registration

5.4.  Binding Bulk Registration

   The bulk registration is an optimization for registering multiple
   care-of addresses only to a home agent by using a single Binding
   Update.  If a mobile node, for instance, does not want to send a lot
   of control messages through an interface which bandwidth is scarce,
   it can use this bulk registration and send a Binding Update
   containing multiple or all the valid care-of addresses from a
   specific interface which has wider bandwidth.

   In this case, a addresses.

   A mobile node sets the C flag in a Binding Unique Identifier sub-option sub-
   option and stores the particular care-of address in the Binding
   Unique Identifier sub-option.  When the C flag is set,
   the length field of the suboption MUST be set to 20.  The mobile node
   can store stores multiple sets
   of a Binding Unique Identifier sub-option in a Binding Update.  If the mobile node wants to replace existing
   registered bindings on the home agent with the bindings Update as
   shown in the sent Figure 3.  When multiple Binding Unique Identifier sub-
   options are presented in a Binding Update, it can the flag field of all the
   sub-options MUST have the same value.  For example, if C flag is set,
   the same flag MUST be set O flag.  Section 6.3 describes this
   registration procedure in detail. to all the sub-options.  Otherwise, the
   mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding
   Acknowledgment.  In the bulk registration, all the other binding
   information such as Lifetime, Sequence Number, binding Flags are
   shared among the bulked Care-of Addresses.  Whether a
   mobile node registers multiple Care-of Addresses separately or in
   bulk  The alternate care-of
   address option MUST be omitted when ESP is up used to implementations. protect a binding
   update.  In the bulk registration, the Sequence Number field of a
   Binding Update SHOULD be carefully configured.  If each binding uses
   different sequence number, a mobile node MUST use the largest
   sequence number from the binding update list used for the bulk
   registration.  If it cannot select a sequence number for all the
   bindings due to sequence number out of window, it MUST NOT use the
   bulk registration for the binding which sequence number is out of
   window and uses a separate Binding Update for the binding.

   When multiple

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Unique Identifier sub-options are presented,
   the flag field of all the sub-options MUST have the same value.  For
   example, if C
                            (C flag is set, the same O flag MUST be set is optional,
                             BID and CoA are stored)

          Figure 3: Binding Update for Binding Bulk Registration

   If the mobile node wants to all replace existing registered bindings on
   the sub-
   options. home agent with the bindings in the sent Binding Update, it can
   set O flag.  Section 6.3 describes this registration procedure in
   detail.

5.5.  Binding De-Registration and Returning Home

   When a mobile node decides to delete all the bindings for its home
   address,
   address at a visiting network, it simply sends a regular de-registration de-
   registration Binding Update. Update which lifetime is set to zero.  A Binding
   Unique Identifier sub-option is not required.  See
   Section 6.3 for details.

   If a mobile node wants to delete a particular binding binding(s) from its
   home agent and correspondent nodes (e.g. from foreign link), the
   mobile node simply sets zero lifetime or uses the home address as for the source
   address in a Binding Update. sending binding update.
   The Binding Update MUST contain a relative Binding Unique Identifier Sub-option (C flag MUST NOT be
   set).
   Sub-option(s).  The receiver will remove only the care-of address address(es)
   that matches to the specified BID.

   On  For the other hand, when a mobile node decides to return home (ie only
   uses its interface attached to bulk de-registration, the home link), it MUST de-register
   all the registered bindings.  To do so, the mobile node stores
   multiple Binding Unique Identifier sub-options in a Binding Update
   which lifetime is set to zero or which source address is set to the
   Home Address.  C flag MUST be specified in all the Binding Unique
   Identifier sub-options.  The
   care-of addresses field of each sub-
   option MAY sub-option SHOULD be omitted, because
   the receiver will remove all the care-of addresses which matches the
   specified BID.

   O flag is always ignored if a Binding Update is for binding de-
   registration

5.6.  Returning Home

   When a mobile node returns home, it MUST SHOULD de-register all bindings
   with the home agent.

   Although agent by sending a regular de-registration binding
   update to flush all the registered bindings.  However, there are
   several scenarios for returning home described in Appendix A
   (Figure 7, Figure 8, Figure 9).  We have discussed this feature in
   Monami6 working group now.  This part might be updated in the next
   revision.

   As shown in Figure 7 in Appendix A, a mobile node SHOULD delete de-registers all
   the bindings with
   Correspondent Nodes as well, binding from the node home agent, while it MAY still keep the binding bindings
   of the other interface active attached to foreign links only at the
   Correspondent Nodes.  In such case,  By doing this, the mobile node still receives
   packets from the Correspondent Node at the other interface attached to a
   foreign link thanks to route optimization.  The  If the correspondent
   nodes does not use route optimization, the mobile node also receives such
   packets at the interface attached to the home link when correspondent nodes does not
   use route optimization.

   Note that when the link.

   In Figure 8, a mobile node does not want to return home even if one
   of interfaces is attached to the home link, the link.  The mobile node MUST
   disable the interface. interface attached to the home link.  Otherwise, address
   duplication will be observed because the home agent still defend the
   Home Address by the proxy neighbor advertisement and the mobile node
   also enables the same Home Address on the home link.  After disabling
   the interface attached to the home link, the mobile node MUST delete
   the binding for the disabled interface by sending a de-registration
   binding update.  The de-registration binding update must be is sent from one
   of active interfaces attached to foreign links.  As a result, the
   mobile node no longer receives packets at the interface attached to
   the home link.  All packets are routed to other interfaces attached
   to a foreign link.

   Alternatively, the Mobile Node may choose to activate both the
   interfaces attached to the home link and the foreign link, and
   communicates with all of the interfaces.  The Mobile Node notifies
   the Home Agent using the H flag which means the Mobile Node is
   attached to the home link.  The Mobile Node may notify the care-of
   address of the interface(s) attached to the foreign link(s) in the
   same message using bulk registration.  The Home Agent then no longer
   uses Proxy Neighbor Advertisement to intercept packets and the Mobile
   Node can utilize both of interfaces attached to the home link and the
   foreign link simultaneously.  The Home Agent can intercept packets by
   IP routing, but not by proxy Neighbor Discovery.  The detailed
   operation of no NDP operation can be found in [ID-NONDP].

   When the Mobile Node returns home, it de-registers a binding for the
   interface.  While the bindings for the interfaces attached to the
   foreign link are still active.  Intercepting packets, the Home Agent
   can decide whether it tunnels to the foreign interface or routes to
   the home interface of the Mobile Node.  To do so, the Home Agent must
   know that the Mobile Node is back to the home link.  However, if the
   binding is deleted according to [2], deleted, there is no way for the Home Agent to know that
   the Mobile Node is at the home, too.  The Home Agent SHOULD
   invalidate the binding for the interface attached to the home link
   and MAY NOT delete it.  It can alternatively mark that the Mobile
   Node is at the home link, too.  As an example, the Home Agent inserts
   the Home Address of the Mobile Node in the Care-of Address field of
   the Mobile Node.  The binding is named "Home Binding" in this doc.
   documentation.  The Home Agent MAY manage this home binding as same
   as the other binding entry in terms of lifetime validation, etc.  The
   Mobile Node MAY send multiple binding de- registration to keep this
   home binding active.  Alternatively, the Home Agent can use infinity
   lifetime for the lifetime of the home binding.  When the Mobile Node
   leaves the Home Link, it can update the home binding to the normal
   binding.  Before that, the Home Agent believes the Mobile Node is at
   the home and may route packets for the Mobile Node to the Home Link.

5.7.  Using Alternate care-of address

   A mobile node can use an alternate care-of address in

5.6.  Receiving Binding Acknowledgment

   The verification of a following
   situation.  One care-of address becomes invalid (e.g because the link
   where it is attached to is no longer available) and MUST be deleted.
   In such case, the mobile node can not send 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.

   In this case, the mobile node include both Alternate Care-of Address
   sub-option and Binding Unique Identifier sub-option in a Binding
   Update.  An Alternate care-of address sub-option can be presented
   only once in a Binding Update after a Binding Unique Identifier sub-
   option.  The care-of address stored in an Alternate Care-of address
   sub-option is replaced the address in the source address field as
   same as [2] specified.

   If C flag is set in a Binding Unique Identifier sub-option, an
   Alternate Care-of Address sub-option SHOULD NOT be used.  A receiver
   uses the care-of addresses and BID stored in each Binding Unique
   Identifier sub-option to modify corresponding binding cache entries.
   Any address can be specified in the Source address field of the IPv6
   header of the Binding Update even without an Alternate Care-of
   Address sub-option.

5.8.  Receiving Binding Acknowledgment

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

   If a mobile node includes a Binding Unique Identifier sub-option in a
   Binding Update with A flag set, a Binding Acknowledgment MUST have carry a
   Binding Unique Identifier sub-option in the Mobility Options field.
   If no such sub-option appears is appeared in the Binding Acknowledgment
   replied to the Binding Update for the multiple care-of address
   registration, this means indicates that the originator node of this Binding
   Acknowledgment might not recognize the Binding Unique Identifier sub-option. 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 try to discover a new home agent
   supporting the multiple care-of address registration or give up with
   the multiple care-of address registration.

   If a Binding Unique Identifier sub-option is present in the received
   Binding Acknowledgment, the mobile node checks the Status field of
   the Binding Acknowledgment.  If the status code indicates successful registration (less than 128), the originator successfully registered
   the binding information and BID
   status for the mobile node. Care-of address(es).  The status value MUST be
   retrieved as follows.  If the status code of value in the Binding Acknowledgment is Unique
   Identifier sub-option is zero, the mobile node uses the value in the
   Status field of the Binding Acknowledgment.  Otherwise, it uses the
   value in the Status field of the Binding Unique Identifier sub-
   option.

   If the status code is greater than or equal to 128, the mobile node proceeds with
   starts relevant operations according to the status code of error code.  Otherwise,
   the Binding Acknowledgment.  The
   status value of originator (home agent or correspondent node) successfully
   registered the stored Binding Unique Identifier sub-option may
   be used to decide further operation. binding information and BID for the mobile node.

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

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

   o  If [MCOA FLAG CONFLICTS] is specified in the Binding
      Acknowledgment, specified, it indicates that the
      different flag values are used in Binding Unique Identifier sub-options sub-
      options in a Binding Update.  If the C flag is set, all sub-options sub-
      options MUST have C flag.  It is same for O flag.  How to handle
      other error status codes is specified in [2].

   The mobile node also learn detailed registration status from the
   Status field of each Binding Unique Identifier sub-option.  If the
   value is greater than or equal to 128, the mobile node proceeds with
   relevant operations according to the status value. [RFC-3775].

   o  If [MCOA BID CONFLICT] is specified, the binding entry specified
      by the Binding Unique Identifier sub-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 sending to reset all the Binding Acknowledgment.

5.9. registered bindings.

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). [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
   new 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 the Binding Update sent to refresh the
   entry.

   If no Binding Unique Identifier sub-option is present in a Binding
   Refresh Request, the mobile node sends a Binding Update according to
   its Binding Update List for the requesting node. 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.10.

5.8.  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 or triangular 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.  Therefore, the mobile node SHOULD use the bi-directional tunnel even if it registers a
   binding(s) to the home agent. (i.e. ingress filtering).  When it uses
   the Home Address option, the home agent MAY reject the packets because check the Care-of care-of address
   in the packet and the first found Care-of Address in with the registering binding Cache
   of entries.  This causes
   additional overhead to the home agent are different.  The agent.  Therefore, the mobile node then receive
   Binding Error for
   SHOULD use the packet drop.

5.11. bi-directional tunnel even if it registers a
   binding(s) to the home agent.

5.9.  Bootstrapping

   When a mobile node bootstraps and registers multiple bindings at the
   first time, it SHOULD set O flag in the Binding Unique Identifier
   sub-option. when  If old bindings still exists at the Home Agent and
   Correspondent Nodes, Agent, the
   mobile node has no way to verify know which bindings are left remained as a garbage in those nodes.
   garbage.  This scenario happens when a mobile node reboots without
   correct deregistration.  If O flag is used, all the bindings are
   replaced to the new binding(s).  Thus, the garbage bindings are
   surely removed replaced by new bindings registered with the first Binding
   Update.
   XXX SEQ

6.  Home Agent and Correspondent Node Operation

6.1.  Searching  If the mobile node receives the Binding Cache Acknowledgment with Binding Unique
   the status code set to 135 [Sequence number out of window], it MUST
   retry sending a Binding Update with the last accepted sequence number
   which is notified by the Binding Acknowledgment.

   For Correspondent nodes, the mobile node cannot use the O flag
   because of no bulk registration support.  Thus, if necessary, it MUST
   sends a regular binding first to overwrite the remaining bindings at
   the correspondent node.  Then, it can re-register the set of bindings
   by using Multiple Care-of Address Registration.

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 their binding cache database, it can use any of
   the bindings to communicate with the mobile node.  How to select the
   most suitable binding from the binding cache database is out of scope
   in this document.

   Whenever a correspondent node searches a binding cache for a home
   address, it SHOULD uses both the Home Address and the BID as the
   search key if it knows the corresponding BID.  In the example below,
   if a correspondent node searches the binding with the Home Address
   and BID2, it gets binding2 for this mobile node.

             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: 4: 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 the Binding Update.  If the correspondent
   node does not know the BID, it searches for a binding with only a
   Home Address as performed in Mobile IPv6.  In such case, the first
   matched binding is found.  But which binding entry is returned for
   the normal search depends on implementations.  If the correspondent
   node does not desire to use multiple bindings for a mobile node, it
   can simply ignore the BID.

6.2.  Receiving CoTI and Sending CoT

   When a correspondent node receives a Care-of Test Init CoTI message which contains a
   Binding Unique Identifier sub-option, it MUST process it with
   following steps.

   First of all, the Care-of Test Init CoTI message is verified according to
   [2]. [RFC-3775].
   The Binding Unique Identifier sub-option MUST be be, then, processed as
   follows:

   o  If a correspondent node does not understand a Binding Unique
      Identifier sub-option, it will ignore just ignores and skip this option.  The
      calculation of a care-of keygen Keygen token will thus be done without a
      BID value.  After regular processing of HoTI message according to
      [2], it will return  The correspondent node returns a Care-of Test CoT message without use of a
      Binding Unique Identifier sub-option.  The mobile node can thus
      know whether its the correspondent can process or not the Binding Unique
      Identifier sub-option or not, by checking if such option is
      present in the Care-of Test CoT message.

   o  If either or both C and O flag is set in the sub-option, the
      Correspondent Node SHOULD NOT calculate a care-of keygen Keygen token and
      MUST include a Binding Unique Identifier sub-option which status
      value set to [MCOA INCOMPLIANT] in the returned Care-of Test
      message.  All the fields
      of the Care-of Test message MUST be set to zero.  All the Binding
      Unique Identifier sub-options SHOULD be copied from the received
      one except for the Status Field and the Care-of Address field.

   o  If O flag is set in the sub-option, the Correspondent Node can
      ignore this flag and can process it as described in the next
      bullet.

   o  Otherwise, the correspondent node MUST include a Binding Unique
      Identifier sub-option which status value MUST be set to [MCOA
      ACCEPTING BID] zero in
      the returning a Care-of Test CoT message.  The

   o  All the Binding Unique Identifier sub-option sub-options SHOULD be copied
      from the received one except for the Status Field and the for CoT.  The
      Care-of address
      Field. field of each Binding Unique Identifier sub-
      option, however, can be omitted, because the mobile node can match
      a corresponding binding update list by using BID.

6.3.  Processing Binding Update

   If a Binding Update does not contain a Binding Unique Identifier sub-
   option, its processing is same as in RFC 3775. [RFC-3775].  But if the receiver
   already has multiple bindings for the Home Address, home address, it MUST replace
   all the existing bindings by the received binding.  As a result, the
   receiver node MUST have only a binding for the mobile node.  If the
   Binding Update is for de-registration, the receiver MUST delete all
   existing bindings from its Binding Cache.

   On the other hand, if

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

   o  If the home registration flag is set in the Binding Update, the
      home agent MUST carefully operate 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.

   If a Binding

   The receiver node MUST process the Binding Unique Identifier sub-option(s) is present, sub-
   option(s) in the receiver following steps.  When a correspondent node sends a
   Binding Acknowledgment, the status value is always stored in the
   Status field of the Binding Acknowledgment and keep the Status field
   of Binding Unique Identifier sub-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 Unique Identifier sub-option.  If
   the status value is specific to one of bindings in the bulk
   registration, the status value MUST process be stored in the Status field in
   the corresponding Binding Unique Identifier sub-option.

   o  The length value is examined.  The length value MUST be either 4
      or 20 depending on C flag.  If the length is incorrect, the
      receiver MUST rejects the Binding Update and returns all the
      received Binding Unique Identifier sub-option which status
      value
      is set to [MCOA INCOMPLIANT].  The status field of

   o  When C flag is specified, the Binding
      Acknowledgment care-of address MUST be given in the
      Binding Unique Identifier sub-option.  Otherwise, the receiver
      MUST reject the Binding Unique Identifier sub-option and returns
      the status value set to [REASON UNSPECIFIED, 128]. [MCOA INCOMPLIANT].

   o  When C flag is set, multiple binding Unique Identifier sub-options are presented,
      the receiver MUST support the bulk registration.  Only a home
      agent can accept the bulk registration.  Otherwise, it MUST reject
      the Binding Update and returns all the received Binding Unique Identifier sub-option
      which status value is set to [MCOA REASON UNSPECIFIED].  The
      status field of the Binding Acknowledgment MUST be set to [MCOA BULK
      REGISTRATION NOT SUPPORTED]. SUPPORT] in the Binding Acknowledgment.

   o  When either C or O flag is set, multiple binding Unique Identifier sub-options are presented,
      the flags field of all the Binding Unique Identifier sub-option
      stored in the same Binding Update MUST be equal.  Otherwise, the
      receiver MUST reject the Binding Update and returns all the received Binding Unique Identifier sub-
      option which status
      value is set to [MCOA REASON UNSPECIFIED].
      The status field of FLAG CONFLICTS] in the Binding Acknowledgment MUST be set to
      [MCOA FLAG CONFLICTS]. Acknowledgment.

   o  When C flag is specified,  If the care-of address MUST be given in Lifetime field of the Binding Unique Identifier sub-option.  Otherwise, Update is zero, the receiver
      MUST reject the Binding Update and returns all the received
      Binding Unique Identifier sub-option which status value is set to
      [MCOA INCOMPLIANT].  The status field of the Binding
      Acknowledgment MUST be set to [REASON UNSPECIFIED, 128].

   o  If the Lifetime field of the Binding Update is zero, the receiver
      node deletes
      node deletes the 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 Update, it MUST reject this de-registration Binding
      Update. Update
      for the binding cache.  If the receiver is a Home Agent, it SHOULD
      also return a
      Binding Acknowledgment to the mobile node, in which the Status
      field is status value set to [not Home Agent for this
      mobile node, 133].

   o  If O flag is set in the deregistering Binding Update, the receiver
      can ignore this flag for deregistration.  If the H flag is set,
      the home agent stores a Home Address in the Care-of Address field
      of the binding cache entry.  The home agent no longer performs
      proxy NDP for this mobile node until this entry is deleted.

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

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

      *  If C 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 C flag is not set and an alternate care-of address is
         present, the care-of address is taken from the Alternate
         Care-of address sub-option.

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

      *  Only if O flag is set in the sub-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 the regular binding and
         registers a new binding including BID according to the Binding
         Update.  In this case, the receiver MUST specify return [MCOA BID
         CONFLICT] to the Binding Unique Identifier sub-option which is
         replied to the Mobile Node.  The Status field of the replying
         Binding Acknowledgment MUST be set to [Binding Update ACCEPTED,
         0].
         CONFLICT].

      *  If the receiver node has already registered the binding which
         BID is matched with requesting BID, then it MUST update the
         binding with the Binding Update. Update and returns [0 Binding Update
         accepted].

      *  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. BID and returns [0 Binding Update accepted].

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

6.4.  Sending Binding Refresh Request

   When either a correspondent node or home agent notices that a
   registered binding will be expired soon, it MAY send sends a Binding Refresh Request.  If the registered Request for a particular binding has
   registering with BID, the
   correspondent node SHOULD contain a Binding Unique
   Identifier sub-
   option 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.  Receiving Packets from Mobile Node

   When a correspondent node receives packets with a Home Address destination option
   from a mobile node, it MUST check that the care-of address appeared
   in the Source Address field MUST be equal to one of the care-of
   addresses in the binding cache entry.  If no binding is found, the
   packets MUST be silently discarded and MUST send a Binding Error
   message according to RFC3775.  This verification MUST NOT be done for
   a Binding Update.

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 [8]. [RFC-4886].  Issues regarding mobile
   routers with multiple interfaces and other multihoming configurations
   are documented in [11]. [RFC-4980].

   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.  Figure 5 shows the 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 Unique Identifier sub-option
                          - Mobile Network Prefix sub-option

                       Figure 5: NEMO Binding Update

8.  IPsec and IKEv2 interaction

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

8.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 Unique Identifier sub-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.

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

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

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

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

9.  Security Considerations

   As shown in Section 8, the Multiple Care-of Addresses Registration
   requires IPsec protected all the signalings signaling between a mobile node and
   its home agent.

10.  IANA Considerations

   The following Extension Types MUST be assigned by IANA:

   1.

   o  Binding Unique Identifier sub-option type

   2.

   o  New Status of Binding Acknowledgement Acknowledgment

      *  MCOA INCOMPLIANT (TBD)

      *  MCOA BID CONFLICT (TBD)

      *  MCOA PROHIBITED(TBD)

      *  MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

      *  MCOA FLAG CONFLICTS (TBD)

11.  Acknowledgments

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

12.  References

12.1.  Normative References

   [1]

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

   [2]

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

   [3]

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

   [4]

   [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
   K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
   draft-ietf-monami6-mipv6-analysis-02 (work in progress), February
   2007.

   [5]   Manner,

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

   [6]

   [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
   Terminology",
         draft-ietf-nemo-terminology-06 (work in progress),
         November 2006.

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

   [8] 4885, July 2007.

   [RFC-4886] Ernst, T., "Network Mobility Support Goals and
   Requirements",
         draft-ietf-nemo-requirements-06 (work in progress),
         November 2006.

   [9] RFC 4886, July 2007.

   [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
   IKEv2 and the revised IPsec Architecture",
         draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
         December 2006. RFC 4877, April 2007.

12.2.  Informative References

   [10]

   [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-01
   draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
         progress), October 2006.

   [11]
   [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
   Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-06 RFC 4980, October 2007.

   [ID-NONDP] Wakikawa, R, Aramoto, M., Thubert, P., "Elimination of
   Proxy NDP from Home Agent Operations",
   draft-wakikawa-mip6-no-ndp-02.txt (work in progress),
         June 2006. November 2007.

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 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 3: 6: Multiple Interfaces Attached to a Foreign Link

   Figure 3 6 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.

                    +----+
                    | 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: 7: One of Interface Attached to Home Link and Returning Home

   Figure 4 7 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 4. 7.  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.

                    +----+
                    | 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: 8: One of Interface Attached to Home Link and Not Returning
                                   Home

   Figure 5 8 depicts the scenario where MN disables 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.

                    +----+
                    | 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: 9: Several Interfaces Attached to Home Link and Returning Home

   Figure 6 9 depicts the scenario where multiple interfaces of MN are
   attached to the home link.  The HA and CN have the binding entries
   listed in Figure 6 9 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.

   Figure 10 depicts the scenario where interfaces of MN are attached to
   the foreign links.  One of foreign link is managed by the home agent.
   The HA and CN have the binding entries listed in Figure 10 in their
   binding cache database.  The home agent advertises a prefix which is
   other than home prefix.  The mobile node will generate a care-of
   address from the prefix and registers it to the home agent.  Even if
   the mobile node attaches to a foreign link, the link is managed by
   its home agent.  It will tunnel the packets to the home agent, but
   the home agent is one-hop neighbor.  The cost of tunnel is
   negligible.  If the mobile node wants to utilize not only an
   interface attached to home but also interfaces attached to foreign
   link, it can use this foreign link of the home agent to return a one
   hop foreign link on behalf of a home link.  This is different from
   the general returning home, but this enable the capability of using
   interfaces attached to both home and foreign link without any
   modifications to Mobile IPv6 and NEMO basic support.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +----+-----+          ++-+-+
        CoA2|           |                 | |   Home Link
         +--+--+        |             ----|-+------
         |  MN +========+                 |
         +--+--+ CoA1                ---+-+------
       CoA3 |                           |  Foreign Link
            +---------------------------+

     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 10: Emulating to Utilize Interfaces Attached to both Home and
                               Foreign Links

Appendix B.  Changes From Previous Versions

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

   o  Add Security Considerations

   o  Add IANA Considerations draft-ietf-monami6-multiplecoa-03.txt

   o  Add H flag  Change the handling of Status field.  All the status value is
      defined for BID BA

   o  Alternate CoA option and Modify Returning Home. is omitted, but using C flag is recommended.

   o  Adding examples of BU

   o  Many editorial updates

Authors' Addresses

   Ryuji Wakikawa
   Keio University
   Department (Editor)
   Faculty of Environmental Information, Environment and Information Studies, Keio University. 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

   Copyright (C) The IETF Trust (2007).

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