Monami6 Working Group                                        R. Wakikawa
Internet-Draft                                           Keio University
Expires: April 4, 2007
Intended status: Standards Track                                T. Ernst
                                                  Keio University / WIDE
Expires: September 6, 2007                                         INRIA
                                                               K. Nagami
                                                           INTEC NetCore
                                                          V. Devarapalli
                                                         Azaire Networks
                                                           March 5, 2007

                Multiple Care-of Addresses Registration
                 draft-ietf-monami6-multiplecoa-01.txt
                 draft-ietf-monami6-multiplecoa-02.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 April 4, September 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   According to the current Mobile IPv6 specification, a mobile node may
   have several Care-of Addresses, care-of addresses, but only one, termed the primary
   Care-of Address,
   care-of address, can be registered with its Home Agent home agent and the
   Correspondent Nodes.
   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 care-of addresses would be assigned to the mobile node.  We thus
   propose Mobile IPv6 extensions designed to register multiple Care-of
   Addresses care-of
   addresses bound to a single Home Address instead of the sole primary
   Care-of Address.
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  7  6

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

   4.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 11 10
     4.1.  Binding Cache Structure and Management . . . . . . . . . . 11
     4.2. Binding Update List Structure and Management .  . . . . . . 11
     4.3. 10
     4.2.  Message Format Changes . . . . . . . . . . . . . . . . . . 11
       4.3.1. 10
       4.2.1.  Binding Unique Identifier sub-option . . . . . . . . . 11
       4.3.2.  Binding Update . . . . . . . . . . . . . . . . . . . . 13
       4.3.3. 10
       4.2.2.  Binding Acknowledgment . . . . . . . . . . . . . . . . 13

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

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

   7.  Network Mobility Applicability . . . . . . . . . . . . . . . . 24 26

   8.  IPsec and IKE IKEv2 interaction  . . . . . . . . . . . . . . . . . 27
     8.1.  Use of Care-of Address in the IKEv2 exchange . 25

   9.  Conclusion . . . . . . 27
     8.2.  Transport Mode IPsec protected messages  . . . . . . . . . 28
     8.3.  Tunnel Mode IPsec protected messages . . . . . . . . . . . 26

   10. Acknowledgments 28
       8.3.1.  Tunneled HoTi and HoT messages . . . . . . . . . . . . 28
       8.3.2.  Tunneled Payload Traffic . . . . . . . . . . . 27

   11. References . . . . 29

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   10. IANA Considerations  . . . 27
     11.1. Normative References . . . . . . . . . . . . . . . . . . 31

   11. Acknowledgments  . 27
     11.2. Informative References . . . . . . . . . . . . . . . . . . 27

   Appendix A.  Example Configurations . . . . 32

   12. References . . . . . . . . . . . 28

   Appendix B.  Changes From Previous Versions . . . . . . . . . . . 34

   Authors' Addresses . . . . 32
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     12.2. Informative References . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36

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

   Appendix A.  Example Configurations  . . . . . . . . . . . . . . . 33

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

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

1.  Introduction

   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 connectivity.  Assumed 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. [10].

   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 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 node is more
   advantageous than assigning multiple Home Addresses because
   applications do not need to be aware of the multiplicity of Home
   Addresses.  Of course,  If multiple home addresses are available, applications should be
   aware of
   must reset the connection information when the mobile node changes
   its active network interface (i.e. change the Home Address Address).

   According 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 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
   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  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] [11] 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.  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 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 correspondent nodes by means of a
   Binding Update.
   Correspondent correspondent nodes and the Home Agent 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.  There are solutions available in Monami6 WG, for example
   [11].

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 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 by sending a single
      binding update.  Several  The mobile node does not necessarily put all the
      available care-of addresses in the binding update, but several
      care-of addresses which can be stored in a Binding Update.  The
      bulk registration is supported only for home
      registration. registration and
      deregistration as explained in Section 5.5.  Note that a mobile
      node should not try to perform bulk registration with Correspondent Nodes.
      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 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 interfaces,
   it can register these addresses with its Home Agent home agent (home
   registration).  If the mobile node wants to register multiple
   bindings to its Home Agent, home agent, it MUST generate a BID for each Care-of
   Address care-of
   address and record it into the binding update list.  The mobile node
   then registers its Care-of Addresses 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 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 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 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 care-of
   addresses either independently (in individual BUs) or multiple at
   once (in a single BU).

   If the mobile node wishes to register its binding with a
   Correspondent Node,
   correspondent node, it MUST start must operate return routability operations
   before sending a Binding Update. operations.
   The mobile node MUST sends CoTI for
   each manage a Care-of Addresses Keygen Token per care-of
   address.  If it is necessary (ex.  Care-of Keygen token is expired),
   the mobile node exchanges CoTI and MUST receive CoT for each Care-of
   Addresses.  The the releative care-of
   addresses.  When the mobile node also uses registers several care-of addresses
   to a correspondent node, it uses the same BID as the one generated
   for the home
   registration to register them as individual 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 sub-option as well
   as the other sub-options specified in RFC 3775.  Since
   return routability cannot be verified with multiple care-of addresses
   in a binding update,  For simplicity, the
   bulk registration is not supported with
   Correspondent Nodes for correspondent nodes in this
   document.

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 a home agent and
   a correspondent node check 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 necessary, a mobile node registers a binding with priority
   value, the priority can be a key use
   policy and filter information to select a binding.  The capability
   of searching look up the desired best binding enables load-sharing and QoS with
   flow separation.  However, per
   sessions, flow, packets, but this selection and flow separation are
   outside the scope is out of scope in this document. 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.

   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 has changed, the mobile node sends
   a Binding Update with the new Care-of Address care-of address and the corresponding
   BID.  The receiver of the Binding Update updates the binding which
   BID fits matches 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, act as 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
   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
   node and, if necessary, deletes all the
   rest of bindings are deleted.

3.3.  Returning Home

   When the mobile node 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 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 implementers.

   The first situation is when a mobile node wants to return home with
   interface attached to the home link.  In this case, the mobile node
   MUST de-register all the bindings by sending a Binding Update with
   lifetime set to zero.  The mobile node MAY NOT put any Binding Unique
   Identifier sub-option in this packet.  Then, the receiver deletes all
   the bindings from its binding cache database.  A home agent MUST stop
   proxy neighbor advertisement for the home address of the mobile node.

   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 relative binding entry from the binding cache
   database.  The Home Agent 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.

   In the above two cases, a mobile node cannot use interfaces attached
   to both home and foreign links simultaneously.  If this is what a
   mobile node wants, a home agent can set up another link other than
   home link and uses the link for the mobile node to return virtually
   to home network.  Even though packets from and to the mobile node are
   routed via the home agent, the hop count is kept in one.  The
   overhead should be negligible since it is only for an additional IPv6
   header and processing tunnel (encapsulation and decapsulation) per
   packets.  The detail can be found in Figure 7

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 Binding Update List

   The following additional items are required in the binding cache
   structure, i.e.:

   BID of the Binding Cache Entry

      The and
   binding update list structure.

   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

      A value of a Binding
      Unique Identifier sub-option.

4.2.  Binding Update List Structure and Management

   The following additional items are required for zero indicates No Priority.  A value of 255 indicates
      that the binding update
   structure, i.e.:

   BID

      The corresponding to this BID MUST be generated whenever the is a default of this
      mobile node registers
      multiple bindings for its Home Address.

   Priority

      MUST node.  The detail can be set if the priority field of a Binding Unique Identifier found in Figure 1.  This
      information is valid.

4.3. used by [12].

4.2.  Message Format Changes

4.3.1.

4.2.1.  Binding Unique Identifier sub-option

   If needed, the

   The Binding Unique Identifier sub-option is included in the Binding
   Update, Binding Acknowledgment, Binding Refresh Request,
   or Binding Error messages. 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)   |Priority/Status|C|R|   |Priority/Status|C|O|  Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       +                    Care-of Address (CoA)                    care-of address (CoA)                      +
       +                                                               +
       +---------------------------------------------------------------+

                         Figure 1: BID Sub-Option
   Type

      Type value for Binding Unique Identifier will be assigned later.

   Length

      Length value is MUST be 4 when the C flag is unset.  Length value is 20
      when  On the other hand if
      C flag is set. 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.

   Priority/Status

      When the Binding Unique Identifier sub-option is included in a
      Binding Update, this field indicates the priority field 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.  The higher value has higher priority.
      Values of zero and 255 are reserved for specific special meaning.

      A value of zero indicates No Priority.  A value of 255 indicates
      that the binding corresponding to this BID is a default of this
      mobile node.  This default binding is used by the flow binding
      scheme [11]. [12].  If the receiver cannot recognize 255, it MUST ignore
      this field.

      When the Binding Unique Identifier sub-option is included in a
      Binding Acknowledgment, this field indicates the status
      correspondent to each binding in a bulk registration mode. binding.  The mobile node can know knows the
      registration status of each binding.  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 SUBOPTION (0)

         The registration of the correspond binding is successfully
         operated.

      INCOMPLIANT BID SUBOPTION

      MCOA REASON UNSPECIFIED (128)
         Registration failed because of unknown errors

      MCOA INCOMPLIANT (129)

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

   Care-of Address

      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.

      MCOA BULK REGISTRATION PROHIBITED (131)

         The C flag can be set only if a Binding Unique Identifier sub-
         option is presented only in a Binding Update or a Binding
         Acknowledgment.

   care-of address (C) flag

      When this flag is set, a mobile node can store a Care-of Address
      correspondent
      corresponding to the BID in the Binding Unique Identifier sub-option. sub-
      option.  This flag must be used whenever a mobile node sends
      multiple bindings in a single Binding Update, i.e. bulk
      registration.

   Removable (R)

   Overwrite (O) flag

      When this flag is set, a mobile node request requests a Home Agent home agent to
      remove
      replace all the binding correspondent bindings to BID, even if the binding
      update is not for de-registration. entries stored in a Binding
      Update.  This flag is valid only when
      bulk registration is used (C flag is set). for Home Registration and
      Deregistration.

   Reserved

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

4.3.2.  Binding Update

   No modification

   Care-of Address

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

4.3.3.

4.2.2.  Binding Acknowledgment

   The message format of Binding Acknowledgment is does not changed, change, but
   operations listed below are added in this draft.

   A receiver who gets a Binding Update with

   If a Binding Unique Identifier
   option MUST reply with sub-option is included in a Binding Acknowledgment if
   Update with the A flag is also
   set.  The set, a receiver MUST also send reply 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
   Acknowledgment.  The receiver node MUST reply with a Binding Acknowledgment
   containing include the same Binding
   Unique Identifier sub-option(s). 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 fields: the Status field of multiple care-of address registration: one
   in a Binding
   Acknowledgment and another in the Status field of a Binding Unique Identifier
   sub-option.  The first  In this specification, the Status field of a Binding
   Acknowledgment indicates the general registration status and of a "Binding
   Update".  The status value in the latter field gives detail registration information Binding Acknowledgment is for
   each binding.  The latter field all
   Binding Unique Identifier sub-options stored in the Binding
   Acknowledgment.  For example, if the status value is often used to indicate 134 in the
   status
   information for multiple bindings field of the Binding Acknowledgment, all the care-of addresses
   stored in a single 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 update
   (i.e. bulk registration). relative to the sub-option.
   Whether each Care-of address has been successfully registered
   successfully or not is given in the Status field of each Binding
   Unique Identifier sub-option.

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

   MCOA CONFLICT(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.

   BULK REGISTRATION FAIL (145) PROHIBITED(TBD)

      It implies that the bulk binding multiple care-of address registration is failed.  The
      correspondent status which is defined in RFC3775 is stored in each
      Binding Unique Identifier sub-option.  The status value is TBD.
      administratively prohibited.

   MCOA BULK REGISTRATION NOT SUPPORT (146)

      It implies that the SUPPORTED (TBD)

      The bulk binding registration is not supported.

   MCOA FLAG CONFLICTS (TBD)

      The mobile node can process the Binding Acknowledgment for the
   particular Care-of Address identified by flags of the BID set sub-options presented in the a Binding
   Unique Identifier sub-option. Update
      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 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. care-of addresses.  How to assign an identification number
   is up to implementers.

   A mobile node assigns a BID to each Care-of Address care-of address when it wants to
   simultaneously
   register them simultaneously with its Home Address. Address .  The value
   should be generated from a value comprised between 1 to 65535.  Zero
   and negative value values MUST NOT be taken as a BID.  If a mobile node has
   only one Care-of Address, care-of address, the assignment of a BID is not needed until
   it has multiple Care-of Addresses care-of addresses to register with.

5.2.  Binding Registration  Return Routability: Sending CoTI and Receiving CoT

   When a mobile node sends wants to register bindings to a Binding Update, Correspondent
   Node, it MUST decide whether it
   registers multiple Care-of Addresses or not.  However, this decision
   is out-of scope in this document.  If send a mobile node decides not to
   register multiple Care-of Addresses, it completely follows standard
   RFC 3775 specification. CoTI per care-of address, while the HoTI and HoT
   can be exchanged only once for a Home Address.  If the mobile node needs to register multiple Care-of Addresses, Mobile Node
   manages bindings with BID, it MUST use BIDs to identify a Care-of Address.  The mobile node puts include a Binding Unique
   Identifier sub-option into in a Care-of Test Init message.  It MUST NOT
   set the Option field of C and O flag in the
   Binding Update. sub-option.

   The BID is copied from receiver (i.e. correspondent node) will calculate a Binding Update List to care-of
   keygen token with the received BID and reply a Care-of Test message
   which contains a Binding Unique Identifier sub-option.  No flag 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 should be set for independent binding
   registration.

   If in the mobile node registers bindings to a Correspondent Node, it
   MUST sends multiple CoTIs for multiple Care-of Addresses.  After
   getting CoTs, it sends Binding Updates with Test MUST be
   processed as follows:

   o  If a Binding Unique Identifier sub-option for all Care-of Addresses.  In any case, the
   mobile node MUST set the A flag is not presented in Binding Updates and MUST wait for
   a Binding Acknowledgment CoT
      in reply to confirm the registration was successful
   as described in section Section 5.7.

5.3. CoTI containing the Binding Bulk Registration

   This bulk registration is an optimization for registering multiple
   Care-of Addresses only to a Home Agent by using Unique Identifier sub-
      option, a single Binding
   Update, although the current Mobile IPv6 specification correspondent node does not allow
   to send multiple bindings by means of a single Binding Update.  In
   this case, a support the Multiple Care-of
      Address registration.  Thus, the mobile node sets the C flag into MUST NOT use a
      Binding Unique Identifier sub-option and stores the particular Care-of Address in the Binding Unique Identifier sub-option. Update.  It
      MUST send a regular Binding Update (i.e. no BID) to the
      correspondent node [2].  The mobile Mobile Node MAY skip resending
      regular CoTI message and use the received care-of keygen token for
      the regular Binding Update, because the correspondent node can store
   multiple sets of a Unique just
      ignores and skip the Binding Unique Identifier sub-option in a Binding
   Update.  All and
      calculates the other binding information such care-of keygen token as Lifetime, Sequence
   Number, binding Flags are shared among [2] specified.

   o  If the bulk Care-of Addresses.
   Whether status field of a mobile node registers multiple Care-of Addresses separately
   or not Binding Unique Identifier sub-option is up
      set to implementations.

   If one of Care-of Address should be removed while [MCOA BULK REGISTRATION PROHIBITED], the other Care-of
   Address must care-of keygen
      token MUST NOT be updated, used for a mobile node can set the R flag in Binding Update.  It MUST re-send a
      Care-of Test Init message again with a corrected Binding Unique
      Identifier sub-option correspondent to the removed
   Care-of Address.  When the R (i.e.  C flag is set, the binding will MUST be removed
   from the binding cache of unset).

   o  If the Home Agent.  Other bindings for which R
   flag status field is unset will be registered or updated accordingly.

5.4.  Binding De-Registration

   When a mobile node decides set to delete all bindings for its home
   address, less than 128, it sends a regular de-registration Binding
      Update (i.e.
   exclusion through Return Routability procedure.

   The computation of MAC is the same as the one in [2] except for
   calculation of a care-of keygen token.  The calculation of a care-of
   keygen token is modified as follows.  BID is used to generate the
   care-of keygen token.

   care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
   nonce | BID | 1)))

5.3.  Binding Unique Identifier sub-option).  See
   Section 6.2 for details.

   If Registration

   When a mobile node wants to delete sends a particular binding from its Home
   Agent and Correspondent Nodes (e.g. from foreign link), Binding Update, it MUST send
   a Binding Update with lifetime decide whether it
   registers multiple care-of addresses or not.  However, this decision
   is set out-of scope in this document.  If a mobile node decides not to zero.
   register multiple care-of addresses, it completely follows the
   standard RFC 3775 specification.

   If only single a mobile node needs to register multiple Care-of Address is removed by Addresses, it
   MUST use BID to identify a Binding Update, the care-of address.  The mobile node
   simply sets zero lifetime in includes
   a Binding Update and contains the single
   correspondent Unique Binding Identifier Sub-option (C flag must be
   unset).  The receiver will remove only sub-option in the Care-of Address which Mobility Option field
   of a Binding Update.  The BID is
   retrieved copied from a corresponding Binding
   Update List entry to the Source Address BID field of the IPv6 header.  On the
   other hand, if Binding Unique Identifier
   sub-option.  If the mobile node wants to remove multiple Care-of
   Addresses at once, it stores multiple Unique Binding Identifier sub-
   options which C flag is set replace existing registered
   bindings on the home agent to the binding entry(s) in a the Binding Update.
   Update, it can set O flag.

   If a mobile node registers bindings to a correspondent node, it MUST
   have both active home and care-of keygen tokens for Kbm (see Section
   5.2.5 of [2].  The Care-of
   Addresses stored care-of keygen tokens MUST be maintained for each
   care-of address that the mobile node wants to register to the
   correspondent node, as described in Section 5.2.  After computing an
   Authenticator value, 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 Binding Unique Identifier sub-options will
   all be removed. sub-option.

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 wants node, for instance, does not want to remove send a binding while it registers the
   other valid bindings, lot
   of control messages through an interface which bandwidth is scarce,
   it can use R 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 mobile node sets the C flag in a Binding Unique
   Identifier 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 detailed operation mobile node
   can be found store multiple sets of a Binding Unique Identifier sub-option in
   Section 5.3.

5.5.  Returning Home

   When
   a Binding Update.  If the mobile node returns home, it MUST de-register all wants to replace existing
   registered bindings
   with the Home Agent.

   Although on the mobile node MUST delete home agent with the bindings with Correspondent
   Nodes as well, in the node sent
   Binding Update, it can still keep set O flag.  Section 6.3 describes this
   registration procedure in detail.  In the binding of bulk registration, all the
   other
   interface active attached to foreign links at the Correspondent
   Nodes.  In binding information such case, as Lifetime, Sequence Number, binding
   Flags are shared among the bulked Care-of Addresses.  Whether a
   mobile node still receives packets at the
   other interface attached registers multiple Care-of Addresses separately or in
   bulk is up to implementations.

   In the bulk registration, the Sequence Number field of a Binding
   Update SHOULD be carefully configured.  If each binding uses
   different sequence number, a foreign link thanks to route
   optimization.  The mobile node also receives packets at MUST use the interface
   attached to largest
   sequence number from the home link when Correspondent Nodes does not use route
   optimization.

   Note that when binding update list used for the mobile node does not want bulk
   registration.  If it cannot select a sequence number for all the
   bindings due to return home even if
   one sequence number out of interfaces is attached to the home link, the mobile node window, it MUST
   disable NOT use the interface.  Otherwise, address duplication will be
   observed because
   bulk registration for the Home Agent still defend binding which sequence number is out of
   window and uses a separate Binding Update for the Home Address by binding.

   When multiple Binding Unique Identifier sub-options are presented,
   the
   proxy neighbor advertisement and flag field of all the mobile node also enables sub-options MUST have the same Home Address on the home link.  After disabling value.  For
   example, if C flag is set, the interface
   attached same flag MUST be set to all the home link, the sub-
   options.

5.5.  Binding De-Registration

   When a mobile node MUST decides to delete all the binding bindings for the interface by sending its home
   address, it sends a regular de-registration binding update.  The
   de-registration binding update must be sent from one of active
   interfaces attached to foreign links.  As Binding Update.  A
   Binding Unique Identifier sub-option is not required.  See
   Section 6.3 for details.

   If 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 wants to delete a particular binding from its home
   agent and correspondent nodes (e.g. from foreign link.

5.6.  Using Alternate Care-of Address

   A link), the mobile
   node can use an alternate Care-of Address in the following
   situations.

   o  One Care-of Address becomes invalid (e.g because simply sets zero lifetime or uses the link where it
      is attached to is no longer available) and MUST be deleted.  In
      such case, home address as the mobile node can not send source
   address in a Binding Update.  The Binding Update from MUST contain a
   relative Binding Unique Identifier Sub-option (C flag MUST NOT be
   set).  The receiver will remove only the
      Care-of Address because care-of address that matches
   the interface's link is lost.  The specified BID.

   On the other hand, when a mobile node needs decides to return home (ie only
   uses its interface attached to the home link), it MUST de-register
   all the remote binding of registered bindings.  To do so, the Care-of
      Address through one of its active Care-of Addresses.

   o  A mobile node has stores
   multiple interfaces, but it wants to send Binding Updates for all Care-of Addresses from Unique Identifier sub-options in a specific
      interface Binding Update
   which has wider bandwidth depending on interface's
      characteristics.  A mobile node does not want lifetime is set to send a lot of
      control messages through an interface zero or which bandwidth source address is scarce.

   In these cases, set to the
   Home Address.  C flag MUST be specified in all the mobile node sends a Binding Update with both
   Alternate Care-of Address sub-option and Binding Unique
   Identifier
   sub-option.

5.7.  Receiving Binding Acknowledgment sub-options.  The verification care-of addresses field of a Binding Acknowledgment is each sub-
   option MAY be omitted, because the same as in Mobile
   IPv6 (section 11.7.3 of RFC 3775).  The operation for sending receiver will remove all the
   care-of addresses which matches the specified BID.

   O flag is always ignored if a Binding Acknowledgment Update is described in Section 6.3.

   If for binding de-
   registration

5.6.  Returning Home

   When a mobile node sends a Binding Update with a Binding Unique
   Identifier sub-option, a Binding Acknowledgment returns home, it MUST have a Binding
   Unique Identifier sub-option in the Mobility options field.  If there
   is no such sub-option, de-register all bindings
   with the originator node of this Binding
   Acknowledgment might not recognize home agent.

   Although 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 delete the Home Agent, bindings with
   Correspondent Nodes as well, the mobile node MAY try still keep the binding of
   the other interface active attached to discover a
   new Home Agent supporting foreign links only at the multiple Care-of Address registration
   or give up with
   Correspondent Nodes.  In such case, the multiple Care-of Address registration.

   If a Binding Unique Identifier sub-option is present, mobile node still receives
   packets at the other interface attached to a foreign link thanks to
   route optimization.  The mobile node
   checks also receives packets at the Status field of
   interface attached to the Binding Acknowledgment.  If the status
   code indicates successful registration (below 128), the originator
   successfully registered the binding information and BID for home link when correspondent nodes does not
   use route optimization.

   Note that when the mobile node.

   If the status code is node does not zero and Binding Unique Identifier sub-
   option want to return home even if
   one of interfaces is in attached to the Binding Acknowledgment, home link, the mobile node proceeds
   with relevant operations according to the status code.

   If MUST
   disable the status code is 144, interface.  Otherwise, address duplication will be
   observed because the mobile node has already registered a
   regular binding before sending a Binding Update with a Binding Unique
   Identifier sub-option.  In such case, home agent still defend the mobile node SHOULD stop
   sending Binding Updates without BID or SHOULD stop sending Binding
   Updates with BID.

   If Home Address by the status code is 145,
   proxy neighbor advertisement and the mobile node should check also enables the status
   field of Binding Unique Identifier sub-option for
   same Home Address on the detail
   information. home link.  After correcting errors, disabling the interface
   attached to the home link, the mobile node can re-
   register only MUST delete the failed binding in separate registration or bulk
   registration mode.

5.8.  Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is
   for the same as in
   Mobile IPv6 (section 11.7.4 of RFC 3775).  The operation of interface by sending a
   Binding Refresh Request is described in section Section 6.4.

   If 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 a Binding Refresh Request with a Binding
   Unique Identifier sub-option, this Binding Refresh Request requests a
   binding indicated by packets at the BID.  The mobile node SHOULD update only interface attached to the
   respective binding.  The home
   link.  All packets are routed to other interfaces attached to a
   foreign link.

5.7.  Using Alternate care-of address

   A mobile node MUST put a Binding Unique
   Identifier sub-option into a Binding Update.

   If no Binding Unique Identifier sub-option is present can use an alternate care-of address in a Binding
   Refresh Request, following
   situation.  One care-of address becomes invalid (e.g because the mobile node sends a Binding Update according link
   where it is attached to
   its Binding Update List for the requesting node.  On the other hand,
   if is no longer available) and MUST be deleted.
   In such case, the mobile node does can not have any send a Binding Update List entry for from the requesting node,
   care-of address because the interface's link is lost.  The mobile
   node needs to register either a
   single de-register the remote binding or multiple bindings depending on of the care-of address
   through one of its binding
   management policy.

5.9.  Receiving Binding Error

   When a active care-of addresses.

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

   If C flag is for set in a binding indicated by 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 the each Binding Unique
   Identifier sub-option.  Further operations
   except for sub-option to modify corresponding binding cache entries.
   Any address can be specified in the text below are identical 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 is the same as in Mobile
   IPv6 (section 11.7.3 of RFC 3775. 3775).  The operation for sending BE a
   Binding Acknowledgment is described in the section Section 6.5.

   When 6.3.

   If a mobile node receives includes 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 Unique Identifier sub-option in Mobile IPv6.

6.  Home Agent and Correspondent Node Operation

6.1.  Searching a
   Binding Cache Update with A flag set, a Binding Acknowledgment MUST have a
   Binding Unique Identifier sub-option in the Mobility Options field.
   If either a Correspondent Node or a Home Agent has multiple bindings
   for a mobile node no such sub-option appears in their binding cache database, it can use any of the bindings Binding Acknowledgment replied
   to communicate with the mobile node.  How to select Binding Update for the
   most suitable binding from multiple care-of address registration,
   this means that the binding cache database is out originator node 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 Binding Acknowledgment
   might not recognize the corresponding BID. 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 priority originator is
   available for a binding cache entry,
   the priority can be used as
   additional key to search a binding.  In home agent, the example below, if mobile node MAY try to discover a
   Correspondent Node searches new home agent
   supporting the binding multiple care-of address registration or give up 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 multiple care-of address registration.

   If a Binding Unique Identifier sub-option.  At sub-option is present in the time, received
   Binding Acknowledgment, the Correspondent
   Node MUST look up its binding cache database with mobile node checks the Home Address
   and Status field of
   the BID retrieved from Binding Update. Acknowledgment.  If the Correspondent Node
   does not know status code indicates successful
   registration (less than 128), the BID, it searches for a binding with only a Home
   Address as performed in Mobile IPv6.  In such case, originator successfully registered
   the first matched
   binding is found.  But which binding entry is returned information and BID for the normal
   search depends on implementations. mobile node.

   If the Correspondent Node does
   not desire status code of the Binding Acknowledgment is greater than or
   equal to use multiple bindings for a 128, the mobile node, it can simply
   ignore node proceeds with relevant operations
   according to the status code of the BID.

6.2.  Receiving Binding Update

   If a Binding Update does not have a Acknowledgment.  The
   status value of the stored Binding Unique Identifier, Identifier sub-option may
   be used to decide further operation.

   o  If the
   processing Status value of the regular Binding Update Acknowledgment is [MCOA
      PROHIBITED], the same as in RFC 3775.
   But if the receiver already has mobile node MUST give up registering multiple
      bindings for to the Home
   Address, it MUST overwrite all existing bindings for the mobile node
   with the received binding.  As a result, peer sending the receiver node Binding Acknowledgment.  It MUST have
   only a binding
      return to the regular Mobile IPv6 [2] for the mobile peer node.

   o  If the Binding Update Status value is for de-
   registration, the receiver MUST delete all existing bindings for [MCOA BULK REGISTRATION NOT SUPPORT], the
      mobile node.

   On the other hand, if a Binding Update contains a Binding Unique
   Identifier sub-option(s), a receiver node MUST perform additional
   validations as follows:

   o  A receiver node MUST validate SHOULD stop using bulk registration to the peer
      sending the Binding Update according to
      section 9.5.1 of RFC 3775. Acknowledgment.

   o  If a Binding Unique Identifier sub-option(s) [MCOA FLAG CONFLICTS] is present, the
      receiver node MUST process specified in the sub-option.

   o  If Binding
      Acknowledgment, it indicates that the C different flag is unset values are
      used in a Binding Unique Identifier sub-
      option(s), the length field MUST be 4.  Otherwise, sub-options in a Binding Update.
      If the receiver C flag is set, all sub-options MUST return the have C flag.  It is
      same for O flag.  How to handle other error code 128 status codes is
      specified in the [2].

   The mobile node also learn detailed registration status from the
   Status field of the Binding
      Unique Identifier sub-option and send a Binding Acknowledgment
      with status code set to 145 with the each Binding Unique Identifier sub-option.  When  If the length field
   value is more greater than 4, the receiver
      MAY process this sub-option by ignoring or equal to 128, the rest of field beyond mobile node proceeds with
   relevant operations according to the 4 octets (i.e. after Reserved field). status value.

   o  If [MCOA BID CONFLICT] is specified, the binding entry specified
      by the Binding Unique Identifier sub-option is with already registered
      as a regular binding.  In such case, the C mobile node SHOULD stop
      sending Binding Updates with BID, or SHOULD use O flag set
      and no care-of address is present in for the sub-option, the receiver
      node MUST set 128 in the Status field of
      peer sending the Binding Unique
      Identifier sub-option and send Acknowledgment.

5.9.  Receiving Binding Refresh Request

   The verification of a Binding Acknowledgment with
      status code set to 145 with Refresh Request is the same as in
   Mobile IPv6 (section 11.7.4 of RFC 3775).  The operation of sending a
   Binding Unique Identifier sub-
      option. Refresh Request is described in section Section 6.4.

   If either a Correspondent Node or a Home Agent not
      supporting bulk registration mobile node receives the a Binding Unique
      Identifier sub-option Refresh Request with C flag set, it MUST return the error
      code 146 in a Binding Acknowledgment.

   o  If the Lifetime field is not zero, the receiver node registers
   Unique Identifier sub-option, this Binding Refresh Request requests a
   binding that includes indicated by the BID as a BID.  The mobile node's binding.

      *  If the C flag is set in node SHOULD update only the
   respective binding.  The mobile node MUST put a Binding Unique
   Identifier sub-
         option, the Care-of Address must be taken from sub-option into the Care-of
         Address in Binding Update sent to refresh the
   entry.

   If no Binding Unique Identifier sub-option.

      *  If the C flag sub-option is not set present in the a Binding Unique Identifier sub-
         option, the Care-of Address must be taken from the Source
         Address field of the IPv6 header.

      *  If
   Refresh Request, the C flag is not set and an alternate care-of address is
         present, mobile node sends a Binding Update according to
   its Binding Update List for the care-of address is taken from requesting node.  On the Alternate
         Care-of Address sub-option.

      *  If other hand,
   if the receiver mobile node does not have any binding Binding Update List entry for
   the mobile requesting node,
         it registers a binding which includes BID field.

      *  If the receiver has mobile node needs to register either a regular
   single binding which does not have BID
         for the mobile node, it de-registers the regular or multiple bindings depending on its binding and
         registers
   management policy.

5.10.  Sending Packets to Home Agent

   When a new binding including BID according 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 Binding
         Update.  In this case, additional size of packets, no difference is observed
   between these two.  The routing path is always the receiver MUST send Binding
         Acknowledgment with status code set to 144.

      *  If same and no
   redundant path such as dog-leg route or triangular route occurs.

   However, in this document, the receiver mobile node has already registered the binding which
         BID is matched with requesting BID, then it MUST update capable of using
   multiple care-of addresses for outgoing packets.  This is problem in
   home agent side because they must verify the
         binding with Care-of address for all
   the Binding Update.  Meanwhile, if packets received from the receiver
         does not have a binding entry which BID is matched with mobile node.  Therefore, the
         requesting BID, mobile
   node SHOULD use the bi-directional tunnel even if it registers a new binding for
   binding(s) to the BID.

      *  If home agent.  When it uses the receiver node found R flag in a Binding Unique
         Identifier sub-option, Home Address option,
   the C flag must be set.  Otherwise, it
         replies with 128 home agent MAY reject the packets because the Care-of address in a Binding Unique Identifier sub-option
   the packet and
         set 145 the first found Care-of Address in a Binding Acknowledgment.  The receiver node must
         remove the binding correspondent to Cache
   of the Binding Unique
         Identifier sub-option for which R flag is set.

   o  If Lifetime field is zero, home agent are different.  The mobile node then receive
   Binding Error for the receiver packet drop.

5.11.  Bootstrapping

   When a mobile node deletes bootstraps and registers multiple bindings at the
      registering binding entry which BID is same as BID sent by
   first time, it SHOULD set O flag in the Binding Unique Identifier
   sub-option.  If when old bindings still exists at the receiver Home Agent and
   Correspondent Nodes, the mobile node does
      not have appropriate binding has no way to verify which BID is matched with the Binding
      Update, it MUST reject this de-registration Binding Update.  If
      the receiver is
   bindings are left as a Home Agent, it SHOULD also return garbage in those nodes.  This scenario happens
   when a Binding
      Acknowledgment to the mobile node, in which the Status field node reboots without correct deregistration.  If O flag
   is
      set used, all the bindings are replaced to 133 (not the new binding(s).  Thus,
   the garbage bindings are surely removed by the first Binding Update.
   XXX SEQ

6.  Home Agent for this mobile node).

6.3.  Sending Binding Acknowledgment

   If a and Correspondent Node Operation

6.1.  Searching Binding Update does not contain a Cache with Binding Unique Identifier sub-
   option, the receiver,

   If either a Correspondent Node correspondent node or a Home Agent,
   MUST reply with home agent has multiple bindings
   for a Binding Acknowledgment according to section 9.5.4 mobile node in their binding cache database, it can use any of RFC 3775.  Otherwise, whenever
   the Binding Unique Identifier sub-
   option is present, bindings to communicate with the receiver MUST follow mobile node.  How to select the additional procedure
   below.  The receiver MUST reply with a Binding Acknowledgment whether
   most suitable binding from the A flag binding cache database is set or not out of scope
   in the Binding Update.

   If the receiver successfully registers this document.

   Whenever a correspondent node searches a binding cache for the BID stored
   in a Binding Unique Identifier sub-option, home
   address, it returns 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
   Acknowledgment with Status field set to successful value (0 binding cache entry, the priority can be used as
   additional key to 128) search a binding.  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: Searching the Binding Cache

   A correspondent node basically learns the BID when it receives a
   Binding Unique Identifier sub-option copied 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 received Binding Update.  If the receiver deletes an existing binding which correspondent
   node does not have a BID and registers a new binding for know the BID, it MUST
   return searches for a Binding Acknowledgment binding with Status field set to 144.  On only a
   Home Address as performed in Mobile IPv6.  In such case, the
   other hand, if first
   matched binding is found.  But which binding entry is returned for
   the node encounters an error during normal search depends on implementations.  If the processing of correspondent
   node does not desire to use multiple bindings for a Binding Update, mobile node, it must return
   can simply ignore the BID.

6.2.  Receiving CoTI and Sending CoT

   When a Binding Acknowledgment with an
   appropriate error number as described in RFC 3775.  The correspondent node SHOULD
   put receives a Care-of Test Init message which
   contains a Binding Unique Identifier sub-option if the BID is available
   for sub-option, it MUST process it
   with following steps.

   First of all, the Care-of Test Init message is verified according to
   [2].  The Binding Acknowledgment.

6.4.  Sending Binding Refresh Request

   When either Unique Identifier sub-option MUST be processed as
   follows:

   o  If a Correspondent Node or Home Agent notices that correspondent node does not understand a
   registered binding Binding Unique
      Identifier sub-option, it will ignore and skip this option.  The
      calculation of a care-of keygen token will thus be expired soon, done without a
      BID value.  After regular processing of HoTI message according to
      [2], it MAY send will return a Care-of Test message without use of a
      Binding
   Refresh Request. Unique Identifier sub-option.  The mobile node can thus
      know whether its correspondent can process or not the Binding
      Unique Identifier sub-option by checking if such option is present
      in the Care-of Test message.

   o  If C flag is set in the registered binding has BID, sub-option, the Correspondent Node SHOULD contain
      NOT calculate a care-of keygen token and MUST include a Binding
      Unique Identifier sub-
   option sub-option which status value set to [MCOA BULK
      REGISTRATION PROHIBITED] in the returned Care-of Test message.
      All the fields of the Care-of Test message MUST be set to zero.
      All the Binding Refresh Request.  Then, 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 receive
      ignore this flag and can process it as described in the next
      bullet.

   o  Otherwise, the correspondent node MUST include a Binding Update with Unique
      Identifier sub-option which status value MUST be set to [MCOA
      ACCEPTING BID] in the returning a Care-of Test message.  The
      Binding Unique Identifier sub-
   option and can update only sub-option SHOULD be copied from the particular binding.  If
      received one except for the registered
   binding does not have BID, then Status Field and the Care-of address
      Field.

   The calculation of a care-of keygen token is modified as follows.
   The BID is used to generate the care-of keygen token.

   care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address |
   nonce | BID | 1)))

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.  But if the receiver
   already has multiple bindings for the Home Address, it MUST replace
   all 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 a Binding Update contains a Binding Unique
   Identifier sub-option(s), the Binding Update is also validated
   according to section 9.5.1 of [2] and the following step.

   o  If the home 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 when it receives the Binding Update.

   If a Binding Unique Identifier sub-option(s) is present, the receiver
   node MUST process the 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 the Binding
      Acknowledgment MUST be set to [REASON UNSPECIFIED, 128].

   o  When C flag is set, the receiver MUST support 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].

   o  When either C or O flag is set, 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 the Binding Acknowledgment MUST be set to
      [MCOA FLAG CONFLICTS].

   o  When C flag is specified, the care-of address MUST be given in the
      Binding Unique Identifier sub-option.  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 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 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.  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 [not Home Agent for this mobile node, 133].  If O
      flag is set in the deregistering Binding Update, the receiver can
      ignore this flag for deregistration.

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

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

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

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

   Issues regarding mobile routers with multiple interfaces and other
   multihoming configurations are documented in [11].

   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.

8.  IPsec and IKEv2 interaction

   Mobile IPv6 [2] and the NEMO protocol [3] require the use of IPsec to
   protect signaling messages like Binding Updates, Binding
   Acknowledgments and return routability messages.  IPsec may also be
   used protect all reverse tunneled data traffic.  The Mobile IPv6-
   IKEv2 specification [9] specifies how IKEv2 can be used to setup the
   required IPsec security associations.  The following assumptions were
   made in RFC 3775, RFC 3963 and the MIP6-IKEv2 specification with
   respect to the use of IKEv2 and IPsec.

   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 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 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 Correspondent Node sends a
   Binding Refresh Request without HoTi message is being sent.  RFC 3775 requires
   the sub-option.

6.5.  Sending Binding Error

   When a Correspondent Node sends a Binding Error with Status field set home agent to 2 (Unrecognized MH Type value), it MAY put a Binding Unique
   Identifier sub-option into Mobility Options field if BID verify that the mobile node is using the care-of
   address that is available in a received the binding message.

   When a Correspondent Node cache entry, when it receives data packets with a home
   reverse tunneled HoTi message.  If a different address
   destination option, it verifies is used as the IPv6
   source address field.  If 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 not registered one of
   the care-of addresses in the Correspondent Node's binding cache, cache entry for the Correspondent Node MUST return mobile node.

   When the home agent tunnels a Binding Error HoT message to the mobile node, the
   care-of address used in the outer IPv6 header is not relevant to the sender
   HoT message.  So regular IPsec tunnel encapsulation with the status set care-of
   address known to zero (Unknown binding for Home
   Address destination option).  The Correspondent Node MUST NOT put a
   Binding Unique Identifier sub-option, because there the IPsec implementation on the home agent is no binding
   cache entry for
   sufficient.

8.3.2.  Tunneled Payload Traffic

   When the source address.

7.  Network Mobility Applicability

   Support of multihomed mobile routers is advocated in sends and receives multiple traffic flows protected
   by IPsec to different care-of addresses, the NEMO working
   group (see R12 "The solution MUST function use of the correct
   care-of address for multihomed MR and
   multihomed mobile networks" 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 [7]

   Issues regarding mobile routers with multiple interfaces and other
   multihoming configurations are documented tunnel mode, it must check that the care-of
      address is one of the care-of addresses in [10].

   Since the binding management mechanisms are cache
      entry.  According to RFC 4306, the same for a mobile
   host operating Mobile IPsec implementation on the
      home agent does not check the source address on the outer IPv6 and for a mobile router operating NEMO
   Basic Support (RFC 3963), our extensions
      header.  Therefore the care-of address used in the reverse
      tunneled traffic can also be used to deal
   with multiple Care-of Addresses registration sent different from a multihomed
   mobile router.

8.  IPsec and IKE interaction

   TBA

9.  Conclusion

   In this document, we propose a solution to achieve multihomed mobile
   node on the care-of address used as
      the source address in the IKEv2 exchange.  However, the Mobile
      IPv6 and Network Mobility.  A binding unique
   identifier stack on the home agent MUST verify that the source address
      is introduced to register multiple one of the care-of addresses to a
   Home Agent registered by the mobile node
      before decapsulating and a Correspondent Node.  Those care-of addresses are
   bound forwarding the payload traffic towards
      the correspondent node.

   o  For tunneled IPsec traffic from the home agent to the same mobile node,
      The IPsec implementation on the home address.  A few modifications agent may not be aware of
      which care-of address to use when performing IPsec tunnel
      encapsulation.  The Mobile IPv6 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 NEMO are required to support multiple care-of address
   registration. Mobile IP implementations on the
      home agent.

9.  Security Considerations

   TBD

10.  IANA Considerations

   TBD

11.  Acknowledgments

   The authors would like to thank Masafumi Aramoto (Sharp Corporation),
   Julien Charbon, Tero Kauppinen (Ericsson), 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, and WIDE project for their contributions.

11.

12.  References

11.1.

12.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
         draft-ietf-monami6-mipv6-analysis-02 (work in progress),
         February 2006. 2007.

   [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
         draft-ietf-nemo-terminology-06 (work in progress),
        February
         November 2006.

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

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

   [9]   Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
         IKEv2 and the revised IPsec Architecture",
         draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
        October 2005.

11.2.
         December 2006.

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

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

   [10]

   [11]  Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming
         in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-05
         draft-ietf-nemo-multihoming-issues-06 (work in progress),
         February
         June 2006.

   [11]

   [12]  Soliman, H., "Flow Bindings in Mobile IPv6",
         draft-soliman-monami6-flow-binding-02 (work in progress),
         September 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 care-of addresses
   1-3 (CoA1, CoA2, CoA3).  The MN assigns BID1, BID2 and BID3 to each
   Care-of Addresses.
   care-of address.

   Figure 3 depicts the scenario where all interfaces of the mobile node
   are attached to foreign links.  After binding registrations, the Home
   Agent 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 +========+   |
         +--+--+ CoA1       |
        CoA3|               |
            +---------------+

     Binding Cache Database:
        Home Agent's
        home agent's binding (Proxy neighbor advertisement is active)
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
              binding [a:b:c:d::EUI  Care-of Address3  care-of address3  BID3]
        Correspondent Node's
        correspondent node's binding
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
              binding [a:b:c:d::EUI  Care-of Address3  care-of address3  BID3]

         Figure 3: Multiple Interfaces Attached to a Foreign Link

   Figure 4 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.  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 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 +========+   |           |
         +--+--+        |   |           |
        CoA3|           +---|-----------+
            +---------------+

     Binding Cache Database:
        Home Agent's
        home agent's binding (Proxy neighbor advertisement is inactive)
              none
        Correspondent Node's
        correspondent node's binding
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
              binding [a:b:c:d::EUI  Care-of Address3  care-of address3  BID3]

    Figure 4: One of Interface Attached to Home Link and Returing Returning Home

   Figure 5 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 +========+               |
         +--+--+ CoA1                   |
            |                           |
            +---------------------------+
             (Disable interface)

     Binding Cache Database:
        Home Agent's
        home agent's binding (Proxy neighbor advertisement is active)
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
        Correspondent Node's
        correspondent node's binding
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]

    Figure 5: One of Interface Attached to Home Link and Not Returing Returning
                                   Home

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

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +----------+          +--+-+
        CoA2|                               |   Home Link
         +--+--+                 --+----+---+------
         |  MN +===================+    |
         +--+--+                        |
            |                           |
            +---------------------------+

     Binding Cache Database:
        Home Agent's
        home agent's binding (Proxy neighbor advertisement is inactive)
              none
        Correspondent Node's
        correspondent node's binding
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]

   Figure 6: Several Interfaces Attached to Home Link and Returning Home

   Figure 7 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 7 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 home. 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
            +---------------------------+
             (Disable interface)

     Binding Cache Database:
        Home Agent's
        home agent's binding (Proxy neighbor advertisement is active)
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
              binding [a:b:c:d::EUI  Care-of Address3  care-of address3  BID3]
        Correspondent Node's
        correspondent node's binding
              binding [a:b:c:d::EUI  Care-of Address1  care-of address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  care-of address2  BID2]
              binding [a:b:c:d::EUI  Care-of Address3  care-of address3  BID3]

    Figure 7: Emulating to Utilize Interfaces Attached to both Home and
                               Foreign Links

Appendix B.  Changes From Previous Versions

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

   o  Adding a default value for the BID priority field.  This default
      value is used by the flow binding scheme [11]. draft-ietf-monami6-multiplecoa-01.txt

   o  Updating the text of BID definition.  The older text was unclear
      whether a BID is assigned to a binding or a interface.  It is now
      clearly defined that BID is assigned assigned to each binding.

   o  Removing R flag according to complexity.

   o  Introducing O (Overwrite) flag.  This flag is useful when a MN
      sends all the active CoAs to HA or CN all at once.  It also useful
      when a MN reboots and sends a first BU to HA and CN. see
      Section 5.11 in detail.

   o  Removing the Binding Error texts, since there is no way to know
      BID when BE is sent by CN.

   o  Clearing up the Status code of Binding Unique Identifier sub-
      option and Binding Acknowledgment.  Renewing the texts in
      Section 6.3.

   o  Adding new section "Sending Packets to HA" and "Receiving Packets
      from MN".

   o  adding how to handle correspondent nodes which do not support MCoA
      extension in Section 5.2.

   o  Return routability is now extended to each binding. carry and use BID to
      generate Authenticator.  Section 6.2 and Section 5.2 are added.

   o  Adding a new section: IPsec and IKEv2 interaction.

   o  Shortening Introduction.  We also remove several useless texts in
      this doc.

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
   INRIA
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153
   France

   Phone: +81-44-580-1600 +33-1-39-63-59-30
   Fax:   +81-44-580-1437   +33-1-39-63-54-91
   Email: ernst@sfc.wide.ad.jp thierry.ernst@inria.fr
   URI:   http://www.sfc.wide.ad.jp/~ernst/   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 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. IETF
   Administrative Support Activity (IASA).