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

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

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   According to the current Mobile IPv6 specification, a mobile node may
   have several care-of addresses, but only one, termed the primary
   care-of address, can be registered with its home agent and the
   correspondent nodes.  However, for matters of cost, bandwidth, delay,
   etc, it is useful for the mobile node to get Internet access through
   multiple access media simultaneously, in which case multiple active
   IPv6 care-of addresses would be assigned to the mobile node.  We thus
   propose Mobile IPv6 extensions designed to register multiple care-of
   addresses bound to a single Home Address instead of the sole primary
   care-of address.  For doing so, a new identification number must be
   carried in each binding for the receiver to distinguish between the
   bindings corresponding to the same Home Address.  Those extensions
   are targeted to NEMO (Network Mobility) Basic Support as well as to
   Mobile IPv6.

Table of Contents

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

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

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

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

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

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

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

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

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

   9. 32
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 30

   10. 33

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31

   11. 34

   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   12. 35

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     12.1. 35
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     12.2. 35
     13.2. Informative References . . . . . . . . . . . . . . . . . . 33 36

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

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

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

1.  Introduction

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

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

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

   In this document, we thus propose a new identification number called
   Binding Unique Identification (BID) number for each binding cache entry to
   accommodate multiple bindings registration.  The mobile node notifies
   the BID to both its Home Agent and correspondent nodes by means of a
   Binding Update.  Correspondent nodes and the home agent record the
   BID into their binding cache.  The Home Address thus identifies a
   mobile node itself whereas the BID identifies each binding registered
   by a mobile node.  By using the BID, multiple bindings can then be
   distinguished.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

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

   Binding 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 conceptually
      assigned to MUST be unique for a
      binding in to a way it cannot be duplicated with
      another BID.  The zero value specific care-of address for a given home address and
      care-of address pair.  The zero value and a negative value MUST
      NOT be used.  Each BID is generated and managed by a mobile node.
      After being generated by the mobile node, the BID is stored in the
      Binding Update List and is sent by the mobile node by means
      of a sub-option of a in the Binding
      Update.  A mobile node MAY change the value of a BID at any time
      according to its administrative policy, for instance to protect
      its privacy.  An implementation must carefully assign the BID so
      as to keep using the same BID for the same binding even when the
      status of the binding is changed.  More details can be found in
      Section 5.1.

   Binding Unique Identifier sub-option Mobility Option

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

   Bulk Registration

      A mobile node can register multiple bindings at once by sending a
      single binding update.  The mobile node does not necessarily put
      all the available care-of addresses in the binding update, but
      several care-of addresses.  A mobile node can also replace all the
      bindings available at the home agent with the new bindings by
      using the bulk registration.  The bulk registration is supported
      only for home registration and deregistration de-registration as explained in
      Section 5.5.  A mobile node MUST NOT perform bulk registration
      with correspondent nodes.

3.  Protocol Overview

   A new identification number (BID) is introduced to distinguish
   multiple bindings pertaining to the same Home Address.  Once a mobile
   node gets several IPv6 global addresses on one or more of its
   interfaces, it can register these addresses with its home agent.  If
   the mobile node wants to register multiple bindings, it MUST generate
   a BID for each care-of address and record the BID into the binding
   update list.  A mobile node can manage manipulate each binding independently owing to
   by using a BID.  The mobile node then registers its care-of addresses
   by sending a Binding Update with a Binding Unique Identifier sub-option. mobility
   option.  The BID MUST be included in the Binding Unique Identifier sub-option. mobility
   option.  After receiving such Binding Update and Binding Unique Identifier sub-
   mobility option, the home agent MUST copy the BID from the Binding Unique
   Identifier sub-option mobility option to the corresponding field in the binding
   cache entry.  Even if there is already an entry for the mobile node's
   home address, the home agent MUST register a new binding entry for
   the BID stored in the Binding Unique Identifier sub-option. mobility option.  The mobile
   node registers multiple care-of addresses either independently in
   individual Binding Updates or multiple at once in a single Binding
   Update.

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

   If the mobile node decides to act as a regular mobile node compliant
   with [RFC-3775] , it just sends a Binding Update without any Binding
   Unique
   Identifier sub-options (i.e. normal Binding Update). mobility options.  The receiver of the Binding Update
   deletes all the bindings registering with a BID and registers only a
   single binding for the mobile node.  Note that the mobile node can
   continue to use using BID even if only a single binding is active at some
   time.

   The BID is used as a search key for a corresponding entry in the
   binding cache in addition to the Home Address.

   When a home agent and a correspondent node check the binding cache
   database for the mobile node, they search a corresponding binding
   entry with the pair of Home Address and BID of the desired binding.
   If necessary, a mobile node can use policy and filter information to
   look up the best binding per sessions, flow, packets, but this is out
   of scope in this document
   and is currently discussed in Monami6 WG. document.  If there is no desired binding, it
   searches the binding cache database with the Home Address as
   specified in Mobile IPv6.  The first matched binding entry may be
   found, although this is implementation dependent.

   A

   The mobile node carefully operates the returning home.  The Home Agent
   needs may return to defend a mobile node's home address by the proxy NDP home link through one its
   interfaces.  There are three options possible for
   packet interception, while the mobile node defends
   when its home address
   by regular NDP to send and receive packets at returns home.

   1.  The mobile node uses only the interface attached with which it attaches to
       the home link.  Two nodes, Home Agent and Mobile Node, compete ND
   state.  This will causes address duplication problem at the end.  If
   the proxy neighbor advertisement for the Home Address is stopped,
   packets  It de-registers all bindings related to all
       care-of addresses.  The interfaces which are always routed still attached to
       the interface visited link are not used.

   2.  The mobile node uses only the interfaces still attached to the home
       visited link.
   On the other hand, packets are never routed to the interface attached
   to the home link when the proxy is active.

   When a mobile node wants to return home with  The interface attached to
   the home link, it MUST de-register all the bindings by sending a
   Binding Update with lifetime set to zero as described in [RFC-3775]
   and [RFC-3963].  The mobile node does not put any Binding Unique
   Identifier sub-option in this Binding Update.  The receiver deletes
   all the bindings from its binding cache database.  On which the other hand,
   a mobile node does not want to return home and keeps the interfaces
   attached attaches
       to the foreign links active, when one of its interfaces is
   attached to its home link. link is not used.

   3.  The mobile node disables may simultaneously use both the interface
       attached to the home link and keeps using the rest of interfaces still attached to foreign links.  In this case, the mobile node sends a de-
   registration Binding Update including the BID for
       the interface
   attached to visited links.

   Section 5.6 describes the returning home link.  The receiver of procedures in more detail.

4.  Mobile IPv6 Extensions

   This section summarizes the de-registration changes to Mobile IPv6 necessary to
   manage multiple bindings bound to a same Home Address.

4.1.  Binding Cache Structure and Binding Update deletes only the relative binding entry from List

   The BID is required in the binding cache database. and binding update list
   structure.

4.2.  Message Format Changes

4.2.1.  Binding Identifier Mobility Option

   The home agent does not stop proxying
   neighbor advertisement as long as there are still bindings for the
   other interfaces.  It is important to understand that this scenario Binding Identifier mobility option is not the most efficient because all included in the traffic from and to the
   mobile node is going through the bi-directional tunnel, whereas the
   mobile node is now accessible at one hop from its home agent.

   In the above two cases, a mobile node cannot use interfaces attached
   to both home and foreign links simultaneously.  If the proxy NDP is
   disabled, the main problem can be solved.  In the Multiple Care-of
   Address Registration, the elimination of Proxy NDP enables that
   Mobile Node and Home Agent maintain multiple bindings for the
   interfaces attached to the home link and the foreign links.  The
   mobile node sends the binding update with H flag set for the
   interface attached to the home link.  The detail operation can be
   found in Section 5.5.

4.  Mobile IPv6 Extensions

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

4.1.  Binding Cache Structure and Binding Update List

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

4.2.  Message Format Changes

4.2.1.  Binding Unique Identifier sub-option

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

                      1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Binding Unique ID (BID)        |     Status    |C|O|H|Reserved    |C|O|H|D|Resrvd |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       +
       :                 IPv4 or IPv6 care-of address (CoA)                      +            :
       +                                                               +
       +---------------------------------------------------------------+

                       Figure 1: BID Sub-Option Mobility Option

   Type

      Type value for Binding Unique Identifier is TBD

   Length

      8-bit unsigned integer.  Length value of the option, in octets,
      excluding the Type and Length fields.  MUST be set to 4 when C the
      'C' flag is unset.  Otherwise, the Length value MUST be set to 20.
      either 8 or 20 depending on the 'D' (DSMIPv6) flag.

   Binding Unique ID (BID)
      The BID which is assigned to the binding carried in the Binding
      Update with this sub-option. mobility option.  BID is 16-bit unsigned integer.
      A value of zero is reserved.

   Status

      When the Binding Unique Identifier sub-option mobility option is included in a
      Binding Acknowledgment, this field overwrites the status field
      correspondent to each binding in the Binding Acknowledgment.  If
      this field is zero, the receiver MUST use the registration status
      stored in the Binding Acknowledgment message.  This Status field
      can be used to carry error information for a Care-of Test message.
      The status is 8-bit unsigned integer.  The possible status codes
      are the same as the status codes of Binding Acknowledgment.

   Care-of address (C) flag

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

   Overwrite (O) flag

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

   Simultaneous Home and Foreign Binding (H) flag

      This flag indicates that the mobile node registers multiple
      bindings to the home agent while is attached to the home link.
      This flag is valid only for a binding update for sent to the home
      agent.

   Reserved

      5 bits Reserved field.  Reserved field must be

   DSMIPv6 (D) flag

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

   Reserved

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

   Care-of Address

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

4.3.  New Status Values for Binding Acknowledgment

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

   MCOA INCOMPLIANT (TBD) NOTCOMPLETE (TBD < 128)

      In bulk registration, not all the binding identifier mobility
      option are successfully registered.  Some of them are rejected.
      The error status value of the failed mobility option is
      individually stored in the status field of the binding identifier
      mobility option.

   MCOA RETURNHOME WO/NDP (TBD < 128)

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

   MCOA MALFORMED (TBD more than 128)

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

   MCOA BID CONFLICT (TBD)

      It indicates that (TBD more than 128)

      The home agent cannot cache both a regular binding (i.e. without the BID set) is
      already registered for the home address, and is conflicting with a
      received Binding Update which BID is set.
      extended binding simultaneously.  It returns this status value
      when the received binding conflicts with the existing binding
      cache entry(ies).

   MCOA PROHIBITED(TBD) PROHIBITED(TBD more than 128)

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

   MCOA BULK REGISTRATION NOT SUPPORTED (TBD) (TBD more than 128)

      The bulk binding registration is not supported.

   MCOA FLAG CONFLICTS (TBD)

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

5.  Mobile Node Operation

5.1.  Management of Care-of Addresses and Binding Unique Identifier

   There are two cases when a mobile node has several Care-of Addresses: Addresses.
   Note that a mixture of the two cases are possible.

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

   2.  A mobile node uses a single physical network interface, but
       multiple prefixes are announced on the link the interface is
       attached to.  Several global addresses are configured on this
       interface for each of the announced prefixes.

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

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

5.2.  Return Routability: Sending CoTI and Receiving CoT

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

   If the Mobile Node manages bindings with BID, it MUST include a
   Binding Unique Identifier sub-option mobility option in a Care-of Test Init message.
   It MUST NOT set the any flags in the sub-option. mobility option.  The receiver
   (i.e. correspondent node) will calculate a care-of Keygen token as
   specified in [RFC-3775] and reply a Care-of Test message and the
   Binding Unique Identifier sub-option mobility option as described in Section 6.2.  When
   the mobile node receives the Care-of Test message, the Care-of Test
   message is verified as same as in [RFC-3775].  If a Binding
   Unique
   Identifier sub-option mobility option is not presented in CoT in reply to the
   CoTI containing the Binding Unique Identifier sub-option, mobility option, the
   correspondent node does not support the Multiple Care-of Address
   registration.  Thus, the mobile node MUST NOT use a Binding Unique
   Identifier sub-option mobility option in the future Binding Update.  The Mobile
   Node MAY skip resending re-sending regular CoTI message and keep the received
   care-of Keygen token for the regular Binding Update, because the
   correspondent node just ignores and skip the Binding Unique Identifier sub-option
   mobility option and calculates the care-of Keygen token as [RFC-3775]
   specified.

5.3.  Binding Registration

   When a mobile node sends a Binding Update, it MUST decide whether it
   registers multiple care-of addresses or not.  However, how this
   decision is taken is out-of scope in this document.  If a mobile node
   decides not to register multiple care-of addresses, it completely
   follows the RFC3775 specification.

   For the multiple Care-of Addresses registration, the mobile node MUST
   include a Binding Unique Identifier sub-option(s) mobility option(s) in the Mobility
   Option field of a Binding Update as shown in Figure 2.  The BID is
   copied from a corresponding Binding Update List entry to the BID
   field of the Binding Unique Identifier sub-option. mobility option.  When ESP is used
   for binding update, the care-of address MUST be stored in the Care-of
   Address field by setting C flag as a substitute for the alternate
   care-of address option.  The alternate care-of address option MUST be
   omitted.  Additionally for binding registration to a correspondent
   node, the mobile node MUST have both active home and care-of Keygen
   tokens for Kbm (see Section 5.2.5 of [RFC-3775]).  The care-of Keygen
   tokens MUST be maintained for each care-of address that the mobile
   node wants to register to the correspondent node, as described in
   Section 5.2.  After computing an Authenticator value for the Binding
   Authorization sub-option, mobility option, it sends a Binding Update which
   contains a Binding Unique Identifier sub-option. mobility option.  The Binding Update is
   protected by a Binding Authorization Data sub-option mobility option placed
   after the Binding Unique Identifier sub-option. mobility option.

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

             Figure 2: Binding Update for Binding Registration

5.4.  Binding Bulk Registration

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

   A mobile node sets the C flag in a Binding Unique Identifier sub- mobility option
   and stores includes the particular care-of address in the Binding
   Unique Identifier sub-option.
   mobility option.  The mobile node stores multiple sets of a Binding Unique
   Identifier sub-option mobility option in a Binding Update as shown in Figure 3.  When multiple Binding Unique Identifier sub-
   options are presented in a Binding Update, the flag field of all the
   sub-options MUST have the same value.  For example, if C flag is set,
   the same flag MUST be set to all the sub-options.  Otherwise, the
   mobile node will receive errors [MCOA FLAG CONFLICTS] by a Binding
   Acknowledgment.
   In the bulk registration, all the other binding information such as
   Lifetime, Sequence Number, binding Flags are shared among the bulked
   Care-of Addresses.  The alternate care-of address option MUST be
   omitted when ESP is used to protect a binding update.

   In the bulk registration, the Sequence Number field of a Binding
   Update SHOULD be carefully configured.  This is because all the bulk-
   registered bindings uses the same Sequence Number specified in the
   Binding Update.  If each binding uses different sequence number, a
   mobile node MUST use the largest sequence number from the binding
   update list used for the bulk registration.  If it cannot select a
   sequence number for all the bindings due to sequence number out of
   window, it MUST NOT use the bulk registration for the binding which
   sequence number is out of window and uses a separate Binding Update
   for the binding.

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Unique Identifier sub-options mobility options
                            (C flag is set, O flag is optional,
                             BID and CoA are stored)

          Figure 3: Binding Update for Binding Bulk Registration

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

5.5.  Binding De-Registration and Returning Home

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

   If a mobile node wants to delete a particular binding(s) from its
   home agent and correspondent nodes (e.g. from foreign link), the
   mobile node simply sets zero lifetime for the sending binding update.
   The Binding Update MUST contain a relative an appropriate Binding Unique Identifier
   Sub-option(s).
   mobility option(s).  The receiver will remove only the care-of
   address(es) that matches to the specified BID.  For the bulk de-registration, de-
   registration, the care-of addresses field of each sub-option mobility option
   SHOULD be omitted, because the receiver will remove all the care-of
   addresses which matches matching the specified BID.

   When a

5.6.  Returning Home

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

   As shown in Figure 7 in Appendix A, a mobile node de-registers all
   the binding from the home agent, while it MAY still keep the bindings
   link through one of the other interface active attached to foreign links only at interfaces on the
   Correspondent Nodes.  By doing this, mobile node.  When the
   mobile node still receives
   packets from the Correspondent Node at wants to return home, it should be configured with what
   interface it needs to use.  The mobile node may use only the
   interface with which it is attached to a
   foreign link thanks the home link, only the
   interfaces still attached to route optimization.  If the correspondent
   nodes does not visited link or use route optimization, both interfaces
   attached to the home link and visited link simultaneously.  The
   following describes each option in more detail.

5.6.1.  Using only Interface attached to the Home Link

   The mobile node receives such returns home and de-registers all the bindings as
   shown in Figure 9.  How to de-register all the bindings is the same
   as binding de-registration from foreign link described in
   Section 5.5.  All the packets at routed by the home agent are only
   forwarded to the interface attached to the home link.

   In Figure 8, a mobile node does not want to return home link, even if one
   of there
   are other active interfaces is attached to the home visited link.  The  While the
   mobile node MUST
   disable de-registers all the bindings from the home agent, it may
   continue registering bindings for interface attached to visited link
   to the home link.  Otherwise, address
   duplication will correspondent node as shown in Figure 9.  These bindings at
   correspondent node MUST be observed because the home agent still defend the
   Home Address by the proxy neighbor advertisement and the created before a mobile node
   also enables the same Home Address on returns home.

5.6.2.  Using only Interface attached to the Visited Link

   The mobile node returns home link.  After disabling and shutdown the interface attached to
   the home link, the mobile node MUST delete
   the link as shown in Figure 10.  The binding for of the disabled home
   attached interface MUST be deleted by sending a de-registration
   binding update.  The de-registration binding update is sent from one of active interfaces interface attached to the foreign
   links.  As a result,  This scenario is not the
   mobile node no longer receives packets at the interface attached to most efficient because all the home link.  All packets are routed to other interfaces attached
   traffic from and to a foreign link.

   Alternatively, the Mobile Node may choose to activate both mobile node is going through the
   interfaces attached to bi-
   directional tunnel, whereas the mobile node is now accessible at one
   hop from its home link and the foreign link, agent.

5.6.3.  Simultaneous Home and
   communicates with all of the interfaces. Visited Link Operation

   The Mobile Node notifies
   the Home Agent mobile node returns home and continues using all the H flag which means the Mobile Node is interfaces
   attached to the both foreign and home link. links as shown in Figure 11.  The Mobile Node may notify the care-of
   address of the interface(s) attached to
   mobile node indicates this by setting the foreign link(s) 'H' flag in the
   same message using bulk registration.  The Home Agent then no longer
   uses Proxy Neighbor Advertisement to intercept packets and BID
   mobility option.  There are additional requirements on the Mobile
   Node can utilize both of interfaces attached to Returning
   Home procedures for possible ND conflicts at the home link and described
   below.

   In [RFC3775], the
   foreign link simultaneously.  The Home Agent can intercept home agent intercepts packets by
   IP routing, but not by meant for the mobile
   node using proxy Neighbor Discovery.  The detailed
   operation of no NDP operation can be found in [ID-NONDP]. while the mobile node is away from the home
   link.  When the Mobile Node mobile node returns home, it de-registers a binding for the
   interface.  While the bindings for home agent deletes the interfaces attached to
   binding cache and stop the
   foreign link are still active.  Intercepting packets, proxy NDP for the Home Agent home address so that a
   mobile node can decide whether it tunnels to configure its home address on the foreign interface or routes attached
   to the home interface of the Mobile Node.  To do so, link.  In this specification, a mobile node may return
   home while it keeps several interfaces attached to the Home Agent must
   know that foreign links
   and continues using them.  Therefore, even though both the Mobile Node is back mobile
   node and the home agent need to intercept packets, the ND states of
   the home link.  However, address can conflict between the home agent and the mobile
   node.  For instance, if the
   binding is deleted, there is no way proxy ND for the Home Agent to know that
   the Mobile Node Address is at the home, too.  The Home Agent SHOULD
   invalidate stopped
   by the binding for home agent, packets are always routed to the interface
   attached to the home link and MAY NOT delete it.  It can alternatively mark that are never routed to the Mobile
   Node interface
   attached to the foreign link.  It is at required to avoid this ND
   conflicts in the case of the simultaneous home link, too.  As an example, and foreign
   attachment.

   In this specification, the Home Agent inserts home agent MUST intercept all the Home Address of packets
   meant for the Mobile Node in mobile node and decide whether to send the Care-of Address field of traffic
   directly to the Mobile Node.  The binding is named "Home Binding" in this
   documentation. home address on the link or tunnel to the care-of
   address.  The Home Agent MAY manage this home binding as same
   as agent would make this decision based on the other binding entry in terms type
   of lifetime validation, etc.  The
   Mobile Node MAY send multiple binding de- registration packets and flows.  How to keep make this
   home binding active.  Alternatively, the Home Agent can use infinity
   lifetime decision is out of scope in
   this document.  The delicate part would be to create a neighbor cache
   entry for the lifetime of mobile node so that the home binding.  When the Mobile Node
   leaves the Home Link, it agent can update deliver the
   packets on-link.  The home binding agent would need to know the normal
   binding.  Before that, Layer-2
   address of the Home Agent believes interface with which the Mobile Node mobile node is at attached to
   the home and may route packets for the Mobile Node link.  In order to create the Home Link.

5.6.  Receiving Binding Acknowledgment

   The verification of a Binding Acknowledgment is neighbor cache entry for the same as Mobile
   IPv6 (section 11.7.3 of [RFC-3775]).
   mobile node, following operations are required.

   The operation for sending a
   Binding Acknowledgment is described in Section 6.3.

   If a mobile node includes a Binding Unique Identifier sub-option in a
   Binding Update with A flag set, a Binding Acknowledgment MUST carry sends a
   Binding Unique Identifier sub-option in de-registration binding update to the Mobility Options field.
   If no such sub-option is appeared in home
   agent from the Binding Acknowledgment
   replied interface attached to the home link.  In the Binding Update
   Update, the BID mobility option must be stored for the multiple care-of address
   registration, this indicates that BID assigned
   to the originator node of this Binding
   Acknowledgment might not recognize interface.  The H flag MUST be set in the Binding Unique Identifier sub- BID mobility option.  The
   When the H flag is appears, the home agent learns and remembers that
   the mobile node SHOULD stop registering multiple care-of
   addresses by wants to continue using a Binding Unique Identifier sub-option. interfaces attached to both
   foreign and home links.  If a Binding Unique Identifier sub-option H flag is present in unset, the received
   Binding Acknowledgment, home agent deletes
   either all the mobile node checks bindings or the registration
   status for binding corresponding to the Care-of address(es).  The status value MUST be
   retrieved as follows.  If BID.

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

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

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

   When the home agent is the only router at the home link, it can
   intercept all the packets by IP routing without proxy NDP.  It stops
   proxy ND for the requested home address and replies the [Binding
   Update Accepted] value to the mobile node.  The neighbor cache entry
   for the mobile node uses is created by the value in regular NDP operation (i.e.
   NS/NA exchange).  On the
   Status field of other hand, if the Binding Acknowledgment.  Otherwise, home agent is not the
   only router, it uses MUST continue defending the home address by proxy NDP
   to capture all the mobile node's traffic.  The home agent, then,
   returns [MCOA RETURNHOME WO/NDP] value in the Status field of the Binding Unique Identifier sub- BID
   mobility option.

   If  The home agent also learns the status code is greater than or equal to 128, mobile node's
   layer-2 address (i.e.  MAC address) during this binding de-
   registration.  It keeps the learned layer-2 address as the neighbor
   cache entry for the mobile node
   starts relevant operations according to so that it can construct the error code.  Otherwise, layer-2
   header for the originator (home agent or correspondent node) successfully
   registered packets meant for the binding information mobile node and BID for forwards them
   directly to the mobile node.

   o  If node's interface attached to the Status value is [MCOA PROHIBITED], home link.

   According to [RFC3775], the mobile node MUST
      give up registering multiple bindings to NOT assign the peer sending home
   address to the
      Binding Acknowledgment.  It MUST return interface attached to the regular Mobile IPv6
      [RFC-3775] home link and MUST NOT
   attempt NDP operations for the peer node.

   o  If home address before the Status value is [MCOA BULK REGISTRATION completion of
   binding de-registration.  It MUST NOT SUPPORT], send and reply to Neighbor
   Solicitation for the home address.  The home address MUST be
   tentative address at this moment until it receives Binding
   Acknowledgment with success status value.

   When the mobile node SHOULD stop using bulk registration to the peer
      sending receives the Binding Acknowledgment.

   o  If [MCOA FLAG CONFLICTS] is specified, binding acknowledgment and BID
   mobility option, it indicates that assigns home address at the
      different flag values are used in Binding Unique Identifier sub-
      options in a Binding Update.  If interface attached to
   the C flag is set, all sub-
      options MUST have C flag.  It is same for O flag.  How home link according to handle
      other error the status codes is specified in [RFC-3775].

   o field of the BID.  If [MCOA BID CONFLICT] the value
   is specified, [Binding Update Accepted], the binding mobile node can start defending the
   home address using NDP.  The home agent can create neighbor cache
   entry specified
      by for the Binding Unique Identifier sub-option is already registered mobile node by NS and NA exchange as a regular binding.  In such case, normal IPv6
   operation.

   If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT
   defends its home address at the home link by NDP.  When the mobile
   node SHOULD stop
      sending Binding Updates with BID, or SHOULD use O flag for sends packets from the
      peer interface attached to reset all the registered bindings. home link, it
   MUST learn the layer2 address (i.e.  MAC address) of the next hop
   (i.e. default router, it can be home agent) during the binding de-
   registration and construct the packet including layer 2 header with
   the learned home agent's layer-2 address.

5.7.  Receiving Binding Refresh Request Acknowledgment

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

   If a mobile node receives a Binding Refresh Request with includes a Binding
   Unique Identifier sub-option, this mobility option in a
   Binding Refresh Request requests Update with A flag set, a
   new binding indicated by the BID.  The mobile node SHOULD update only
   the respective binding.  The mobile node Binding Acknowledgment MUST put carry a
   Binding Unique Identifier sub-option into the Binding Update sent to refresh mobility option in the
   entry. Mobility Options field.  If
   no Binding Unique Identifier sub-option such mobility option is present included in a Binding
   Refresh Request, the mobile node sends a Binding Update according Acknowledgment
   replied to
   its Binding Update List.  On the other hand, if the mobile node does
   not have any Binding Update List entry for the requesting node, the
   mobile node needs to register either a single binding or multiple
   bindings depending on its binding management policy.

5.8.  Sending Packets to Home Agent

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

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

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

   Beside care-of address
   registration, this indicates that the additional size originator node of packets, no difference is observed
   between these two.  The routing path is always the same and no
   redundant path such as dog-leg route occurs.  However, in this
   document, Binding
   Acknowledgment might not recognize the Binding Identifier mobility
   option.  The mobile node is capable of using SHOULD stop registering multiple care-of
   addresses for outgoing packets.  This by using a Binding Identifier mobility option.

   If a Binding Identifier mobility option is problem present in home agent side
   because they must verify the Care-of address for all the packets received from
   Binding Acknowledgment, the mobile node (i.e. ingress filtering).  When it uses checks the Home Address option, registration
   status for the home agent MAY check Care-of address(es).  The status value MUST be
   retrieved as follows.  If the care-of address status value in the packet with the registering binding entries.  This causes
   additional overhead to the home agent.  Therefore, Binding Identifier
   mobility option is zero, the mobile node
   SHOULD use uses the bi-directional tunnel even if it registers a
   binding(s) to value in the home agent.

5.9.  Bootstrapping

   When a mobile node bootstraps and registers multiple bindings at Status
   field of the
   first time, Binding Acknowledgment.  Otherwise, it SHOULD set O flag uses the value in
   the Status field of the Binding Unique Identifier
   sub-option. mobility option.

   If old bindings still exists at the Home Agent, the
   mobile node has no way status code is greater than or equal to know which bindings are remained as a
   garbage.  This scenario happens when a 128, the mobile node reboots without
   correct deregistration.  If O flag is used, all the bindings are
   replaced
   starts relevant operations according to the new binding(s).  Thus, error code.  Otherwise,
   the garbage bindings are
   surely replaced by new bindings originator (home agent or correspondent node) successfully
   registered with the first Binding
   Update.  If binding information and BID for the mobile node receives node.

   o  If the Binding Acknowledgment with Status value is [MCOA PROHIBITED], the status code set to 135 [Sequence number out of window], it mobile node MUST
   retry sending a Binding Update with
      give up registering multiple bindings to the last accepted sequence number
   which is notified by peer sending the
      Binding Acknowledgment.

   For Correspondent nodes,  It MUST return to the regular Mobile IPv6
      [RFC-3775] for the peer node.

   o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
      mobile node cannot use the O flag
   because of no SHOULD stop using bulk registration support.  Thus, if necessary, it MUST
   sends a regular binding first to overwrite the remaining bindings at peer
      sending the correspondent node.  Then, Binding Acknowledgment.

   o  If [MCOA MALFORMED] is specified, it can re-register indicates that the set of bindings binding
      identifier mobility option is formatted wrongly.  For example, if
      the C flag is set, all mobility options MUST have C flag.  It is
      same for O flag.  How to handle other error status codes is
      specified in [RFC-3775].

   o  If [MCOA BID CONFLICT] is specified, the binding entry specified
      by using Multiple Care-of Address Registration.

6.  Home Agent and Correspondent Node Operation

6.1.  Searching Binding Cache with the Binding Unique Identifier

   If either a correspondent node or a home agent has multiple bindings
   for mobility option is already registered as
      a regular binding.  In such case, the mobile node in their binding cache database, it can use any of
   the bindings to communicate SHOULD stop
      sending Binding Updates with BID, or SHOULD use O flag for the mobile node.  How
      peer to select the
   most suitable binding from reset all the binding cache database registered bindings.

5.8.  Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is out the same as in
   Mobile IPv6 (section 11.7.4 of scope [RFC-3775]).  The operation of sending
   a Binding Refresh Request is described in this document.

   Whenever section Section 6.4.

   If a correspondent mobile node searches receives a binding cache for Binding Refresh Request with a home
   address, it SHOULD uses both the Home Address and the BID as the
   search key if it knows Binding
   Identifier mobility option, this Binding Refresh Request requests a
   new binding indicated by the corresponding BID.  In  The mobile node SHOULD update only
   the example below,
   if a correspondent node searches the binding with the Home Address
   and BID2, it gets binding2 for this respective binding.  The mobile node.

             binding1 [a:b:c:d::EUI,  care-of address1,  BID1]
             binding2 [a:b:c:d::EUI,  care-of address2,  BID2]
             binding3 [a:b:c:d::EUI,  care-of address3,  BID3]

                   Figure 4: Searching the Binding Cache

   A correspondent node basically learns the BID when it receives MUST put a Binding Unique
   Identifier sub-option.  At mobility option into the time, Binding Update sent to refresh
   the correspondent entry.

   If no Binding Identifier mobility option is present in a Binding
   Refresh Request, the mobile node MUST look up sends a Binding Update according to
   its binding cache database with the Home Address
   and the BID retrieved from the Binding Update.  If Update List.  On the correspondent other hand, if the mobile node does
   not know the BID, it searches have any Binding Update List entry for the requesting node, the
   mobile node needs to register either a single binding with only or multiple
   bindings depending on its binding management policy.

5.9.  Sending Packets to Home Agent

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

   1.  Using Home Address as performed in Mobile IPv6.  In such case, Option. (required additional 24 bytes)

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

   Beside the first
   matched binding additional size of packets, no difference is found.  But which binding entry observed
   between these two.  The routing path is returned for always the normal search depends on implementations.  If same and no
   redundant path such as dog-leg route occurs.  However, in this
   document, the correspondent mobile node does not desire to use is capable of using multiple bindings care-of
   addresses for a mobile node, it
   can simply ignore outgoing packets.  This is problem in home agent side
   because they must verify the BID.

6.2.  Receiving CoTI and Sending CoT

   When a correspondent Care-of address for all the packets
   received from the mobile node receives a CoTI message which contains a
   Binding Unique Identifier sub-option, it MUST process (i.e. ingress filtering).  When it uses
   the Home Address option, the home agent MAY check the care-of address
   in the packet with
   following steps.

   First of all, the CoTI message is verified according registering binding entries.  This causes
   additional overhead to [RFC-3775].
   The Binding Unique Identifier sub-option MUST be, then, processed as
   follows:

   o  If a correspondent the home agent.  Therefore, the mobile node does not understand a Binding Unique
      Identifier sub-option,
   SHOULD use the bi-directional tunnel even if it just ignores and skip this option.  The
      calculation of a care-of Keygen token will thus be done without a
      BID value.  The correspondent node returns registers a CoT message without
   binding(s) to the home agent.

5.10.  Bootstrapping

   When a
      Binding Unique Identifier sub-option.  The mobile node can thus
      know whether bootstraps and registers multiple bindings at the correspondent can process
   first time, it SHOULD set O flag in the Binding Unique Identifier sub-option or not, by checking if such option is
      present in mobility
   option.  If old bindings still exists at the CoT message.

   o Home Agent, the mobile
   node has no way to know which bindings are still remained at the home
   agent.  This scenario happens when a mobile node reboots without
   correct de-registration.  If either or both C and O flag is set in used, all the sub-option, bindings are
   replaced to the
      Correspondent Node SHOULD NOT calculate a care-of Keygen token and
      MUST include a Binding Unique Identifier sub-option which status
      value set to [MCOA INCOMPLIANT] in new binding(s).  Thus, the returned Care-of Test
      message.

   o  Otherwise, garbage bindings are
   surely replaced by new bindings registered with the correspondent first Binding
   Update.  If the mobile node MUST include a receives the Binding Unique
      Identifier sub-option which Acknowledgment with
   the status value MUST be code set to zero in
      the returning 135 [Sequence number out of window], it MUST
   retry sending a CoT message.

   o  All the Binding Unique Identifier sub-options SHOULD be copied
      from Update with the received one except for last accepted sequence number
   which is notified by the Status Field for CoT.  The
      Care-of address field of each Binding Unique Identifier sub-
      option, however, can be omitted, because Acknowledgment.

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

6.3.  Processing Multiple Care-of Address Registration.

6.  Home Agent and Correspondent Node Operation

6.1.  Searching Binding Update Cache with Binding Identifier

   If either a Binding Update does not contain correspondent node or a Binding Unique Identifier sub-
   option, its processing is same as in [RFC-3775].  But if the receiver
   already home agent has multiple bindings
   for the home address, it MUST replace
   all the existing bindings by the received binding.  As a result, the
   receiver mobile node MUST have only a in their binding for cache database, it can use any of
   the bindings to communicate with the mobile node.  If  How to select the
   Binding Update is for de-registration,
   most suitable binding from the receiver MUST delete all
   existing bindings from its Binding Cache.

   If binding cache database is out of scope
   in this document.

   Whenever a Binding Update contains correspondent node searches a Binding Unique Identifier sub-
   option(s), binding cache for a home
   address, it is validated according to section 9.5.1 of [RFC-3775]
   and the following step.

   o  If SHOULD uses both the home registration flag is set in Home Address and the Binding Update, BID as the
      home agent MUST carefully operate DAD for
   search key if it knows the received Home
      Address.  If corresponding BID.  In the home agent has already had example below,
   if a binding(s) for correspondent node searches the
      Mobile Node, it MUST avoid running DAD check when binding with the Home Address
   and BID2, it receives gets binding2 for this mobile node.

             binding1 [a:b:c:d::EUI,  care-of address1,  BID1]
             binding2 [a:b:c:d::EUI,  care-of address2,  BID2]
             binding3 [a:b:c:d::EUI,  care-of address3,  BID3]

                   Figure 4: Searching the Binding Update.

   The receiver Cache

   A correspondent node MUST process basically learns the BID when it receives a
   Binding Unique Identifier sub-
   option(s) in mobility option.  At the time, the following steps.  When a correspondent
   node sends a
   Binding Acknowledgment, the status value is always stored in the
   Status field of MUST look up its binding cache database with the Binding Acknowledgment Home Address
   and keep the Status field
   of Binding Unique Identifier sub-option to zero.  For BID retrieved from the Home Agent, Binding Update.  If the status value can be stored in correspondent
   node does not know the Status field of either BID, it searches for a
   Binding Acknowledgment or binding with only a Binding Unique Identifier sub-option.  If
   Home Address as performed in Mobile IPv6.  In such case, the status value first
   matched binding is specific found.  But which binding entry is returned for
   the normal search depends on implementations.  If the correspondent
   node does not desire to one of use multiple bindings in for a mobile node, it
   can simply ignore the bulk
   registration, BID.

6.2.  Receiving CoTI and Sending CoT

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

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

   o  If a correspondent node does not understand a Binding Identifier
      mobility option, it just ignores and skip this option.  The
      calculation of a care-of Keygen token will thus be stored in done without a
      BID value.  The correspondent node returns a CoT message without a
      Binding Identifier mobility option.  The mobile node can thus know
      whether the Status field in correspondent can process the corresponding Binding Unique Identifier sub-option.

   o  The length value
      mobility option or not, by checking if such option is examined.  The length value MUST be present in
      the CoT message.

   o  If either 4 or 20 depending on both C flag.  If the length and O flag is incorrect, set in the
      receiver MUST rejects mobility option, the Binding Update
      Correspondent Node SHOULD NOT calculate a care-of Keygen token and returns the
      MUST include a Binding Identifier mobility option which status
      value set to [MCOA INCOMPLIANT].

   o  When C flag is specified, the care-of address MUST be given MALFORMED] in the
      Binding Unique Identifier sub-option. returned Care-of Test
      message.

   o  Otherwise, the receiver correspondent node MUST reject the include a Binding Unique
      Identifier sub-option and returns
      the mobility option which status value MUST be set to [MCOA INCOMPLIANT]. zero
      in the returning a CoT message.

   o  When multiple binding Unique Identifier sub-options are presented,
      the receiver MUST support the bulk registration.  Only a home
      agent can accept the bulk registration.  Otherwise, it MUST reject
      the Binding Update and returns the status value set to [MCOA BULK
      REGISTRATION NOT SUPPORT] in  All the Binding Acknowledgment.

   o  When multiple binding Unique Identifier sub-options are presented, mobility options SHOULD be copied from
      the flags received one except for the Status Field for CoT.  The Care-of
      address field of all the each Binding Unique Identifier sub-option
      stored in the same Binding Update MUST mobility option, however,
      can be equal.  Otherwise, the
      receiver MUST reject omitted, because the mobile node can match a corresponding
      binding update list by using BID.

6.3.  Processing Binding Update and returns the status
      value set to [MCOA FLAG CONFLICTS] in the Binding Acknowledgment.

   o

   If the Lifetime field of the a Binding Update does not contain a Binding Identifier mobility
   option, its processing is zero, same as in [RFC-3775].  But if the receiver
      node deletes
   already has multiple bindings for the binding entry which BID is same as BID sent home address, it MUST replace
   all the existing bindings by the Binding Unique Identifier sub-option.  If received binding.  As a result, the
   receiver node
      does not MUST have appropriate only a binding which BID is matched with for the mobile node.  If the
      Binding Update, it MUST reject this de-registration
   Binding Update is for the binding cache.  If de-registration, the receiver is MUST delete all
   existing bindings from its Binding Cache.

   If a Home Agent, Binding Update contains a Binding Identifier mobility option(s),
   it SHOULD
      also return the status value set is validated according to [not Home Agent for this
      mobile node, 133]. section 9.5.1 of [RFC-3775] and the
   following step.

   o  If O the home registration flag is set in the deregistering Binding Update, the receiver
      can ignore this flag
      home agent MUST carefully operate Duplicate Address Detection
      (DAD) for deregistration.  If the H flag is set, received Home Address.  If the home agent stores has
      already had a Home Address in binding(s) for the Care-of Address field
      of Mobile Node, it MUST avoid
      running DAD check when it receives the binding cache entry. Binding Update.

   The home agent no longer performs
      proxy NDP for this mobile receiver node until this entry is deleted.

   o  If MUST process the Lifetime field is not zero, Binding Identifier mobility
   option(s) in the receiver following steps.  When a correspondent node registers sends a
      binding with
   Binding Acknowledgment, the specified BID as a mobile node's binding.  The
      Care-of address is picked from status value MUST be always stored in the
   Status field of the Binding Update packet as
      follows:

      *  If C flag is set in Acknowledgment and keep the Status field
   of Binding Unique Identifier sub-option, mobility option to zero.

   For the care-of address must Home Agent, the status value can be taken from stored in the care-of address Status
   field in each of either a Binding Acknowledgment or a Binding Unique Identifier sub-option.

      *
   mobility option.  If C flag the status value is not set specific to one of bindings
   in the Binding Unique Identifier sub-
         option, bulk registration, the care-of address must status value MUST be taken from stored in the Source
         Address
   Status field of in the IPv6 header.

      *  If C flag is not corresponding Binding Identifier mobility option.
   In this case, [MCOA NOTCOMPLETE] MUST be set and an alternate care-of address is
         present, to the care-of address is taken from Status field of
   the Alternate
         Care-of address sub-option.

   o  Once Binding Acknowledgment so that the care-of address(es) has been retrieved from receiver can examine the
   Status field of each Binding
      Update, it starts registering binding(s).

      *  Only if O flag Identifier mobility option for further
   operations.

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

   o  When C flag is specified, the care-of address MUST be given in the sub-option,
      Binding Identifier mobility option.  Otherwise, the home agent first
         removes all receiver MUST
      reject the existing bindings Binding Identifier mobility option and registers returns the received
         bindings.

      *  If
      status value set to [MCOA MALFORMED].  The operation of D flag is
      described in Section 8

   o  When multiple binding Identifier mobility options are presented,
      the receiver has MUST support the bulk registration.  Only a regular binding which does not have BID
         for home
      agent can accept the mobile node, bulk registration.  Otherwise, it de-registers MUST reject
      the regular binding Binding Update and
         registers a new binding including BID according returns the status value set to [MCOA BULK
      REGISTRATION NOT SUPPORT] in the Binding
         Update.  In this case, the receiver MUST return [MCOA BID
         CONFLICT].

      * Acknowledgment.

   o  If the Lifetime field of the Binding Update is zero, the receiver
      node has already registered deletes the binding entry which BID is matched with requesting BID, then it MUST update the
         binding with same as BID sent by
      the Binding Update and returns [0 Binding Update
         accepted].

      * Identifier mobility option.  If the receiver node does
      not have a appropriate binding entry which BID is matched with the requesting BID, Binding
      Update, it registers a new binding for
         the BID and returns [0 MUST reject this de-registration Binding Update accepted].

   If all for the above operations are successfully finished,
      binding cache.  If the Binding
   Acknowledgment containing receiver is a Home Agent, it SHOULD also
      return the Binding Unique Identifier sub-options
   MUST be replied status value set to the [not Home Agent for this mobile node if A
      node, 133].

   o  If O flag is set in the de-registering Binding
   Acknowledgment.  Whenever a Binding Acknowledgment Update, the
      receiver can ignore this flag for de-registration.  If the H flag
      is returned, all set, the Binding Unique Identifier sub-options stored home agent stores a Home Address in the Binding
   Update MUST be copied to the Binding Acknowledgment.  The Care-of
   address
      Address field of each Binding Unique Identifier sub-option, however,
   can be omitted, because the binding cache entry.  The home agent no
      longer performs proxy NDP for this mobile node can match a corresponding
   binding update list by using BID.

6.4.  Sending Binding Refresh Request

   When a until this entry is
      deleted.

   o  If the Lifetime field is not zero, the receiver node sends a Binding Refresh Request for registers a particular
      binding
   registering with BID, the node SHOULD contain specified BID as a mobile node's binding.  The
      Care-of address is picked from the Binding Unique
   Identifier sub-option Update packet as
      follows:

      *  If C flag is set in the Binding Refresh Request.

6.5.  Receiving Packets from Mobile Node

   When a node receives packets with a Home Address destination option Identifier mobility option, the
         care-of address must be taken from a mobile node, it MUST check that the care-of address appeared field in
         each Binding Identifier mobility option.

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

      *  If C flag is not set and an alternate care-of
   addresses in address is
         present, the binding cache entry.  If no binding care-of address is found, taken from the
   packets MUST be silently discarded and MUST send a Binding Error Alternate
         Care-of address mobility 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 mobility option, the home agent
         first removes all the existing bindings and registers the
         received bindings.

      *  If the receiver has a regular binding which does not have BID
         for the mobile node, it de-registers the regular binding and
         registers a new binding including BID according to the Binding
         Update.  In this case, the receiver MUST return [MCOA BID
         CONFLICT].

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

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

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

6.4.  Sending Binding Refresh Request

   When a node sends a Binding Refresh Request for a particular binding
   registering with BID, the node SHOULD contain a Binding Identifier
   mobility option in the Binding Refresh Request.

6.5.  Receiving Packets from Mobile Node

   When a node receives packets with a Home Address destination option
   from a mobile node, it MUST check that the care-of address appeared
   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 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 [RFC-4886].  Issues regarding mobile
   routers with multiple interfaces and other multihoming configurations
   are documented in [RFC-4980].

   Since the binding management mechanisms are the same for a mobile
   host operating Mobile IPv6 and for a mobile router operating NEMO
   Basic Support (RFC 3963), our extensions can also be used to deal
   with multiple care-of addresses registration sent from a multihomed
   mobile router.  Figure 5 shows an example format of a Binding Update
   used by a mobile router.

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

                       Figure 5: NEMO Binding Update

8.  DSMIPv6 Applicability

   Dual Stack Mobile IPv6 (DSMIPv6) extends Mobile IPv6 to register an
   IPv4 care-of address instead of the IPv6 care-of address when the
   mobile node is attached to an IPv4-only access network.  It also
   allows the mobile node to acquire an IPv4 home address in addition to
   an IPv6 home address for use with IPv4-only correspondent nodes.
   This section describes how multiple care-of address registration
   works with IPv4 care-of and home addresses.

8.1.  IPv4 Care-of Address Registration

   In DSMIPv6, the binding update and acknowledgment exchange is used to
   detect NAT.  Thus, when a mobile node registers its IPv4 care-of
   address bound to IPv6 home address, it MUST first attempt to send a
   Binding Update with Binding Identifier mobility option independently.
   The bulk registration MUST NOT be used for the first binding update
   of the IPv4 care-of address.  The Binding Update MUST be sent to the
   IPv4 home agent address by using UDP and IPv4 headers as shown in
   Figure 6.  It is similar to [DSMIP] except for using BID mobility
   option instead of IPv4 care-of address option.

              IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                UDP Header
                  IPv6 header (src=V6HoA, dst=HAADDR)
                       ESP Header
                       Mobility header
                           -BU
                          Mobility Options
                            - Binding Identifier (IPv4 CoA)

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

   When the home agent detects NAT for the received binding update, it
   MUST send the NAT detection option in the Binding Acknowledgment.
   Whenever the NAT detection option is found, the mobile node MUST NOT
   use the bulk registration for the IPv4 care-of address.  Otherwise,
   it can send the IPv4 care-of address with other care-of addresses in
   the bulk registration mode.  How to handle NAT is same as [DSMIP].

   If NAT is not detected, the mobile node can update the IPv4 care-of
   address by using BULK registration.  The mobile node can register the
   IPv4 care-of address with other care-of addresses.  Figure 7 shows
   the binding update format when the mobile node sends a Binding Update
   from one of its IPv6 care-of addresses.  If the mobile node sends a
   BU from IPv4 care-of address, it MUST follows the Figure 6 and store
   more BID mobility options in the mobility options field.  Note that
   IPv4 Care-of Address must be registered by non bulk Binding
   registration, whenever it is changed.  NAT detection MUST be carried
   out for every new IPv4 addresses.

              IPv6 header (src=V6CoA, dst=HAADDR)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -BU
                       Mobility Options
                          - Binding Identifier (IPv6/v4 CoA)
                          - Binding Identifier (IPv6/v4 CoA)
                          - ...

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

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

   If the home agent rejects the IPv4 care-of address, it MUST store the
   error code value in the Status field of the BID mobility option.  The
   home agent MUST send the binding acknowledgment and all the received
   BID mobility options to the mobile node.  In this case, the IPv4
   address acknowledgment option MUST NOT be included in the Binding
   Acknowledgment.  All the error codes for IPv4 care-of address
   registration MUST NOT be done for
   a Binding Update.

7.  Network Mobility Applicability

   Support stored in the Status field of multihomed mobile routers the BID mobility
   option.  The IPv4 address acknowledgment option is advocated in used only when a
   mobile node requests IPv4 home address management.

8.2.  IPv4 HoA Management

   When the NEMO working
   group (see R12 "The solution MUST function for multihomed MR and
   multihomed mobile networks" node obtains an IPv4 home address, it MUST store the
   IPv4 Home Address option in [RFC-4886].  Issues regarding the Binding Update.  If the home agent
   accepts the binding update, the mobile
   routers with node can also register
   multiple interfaces and other multihoming configurations
   are documented in [RFC-4980].

   Since care-of addresses for the binding management mechanisms are IPv4 home address in addition to
   the IPv6 home address.  The same set of care-of addresses will be
   registered for a mobile
   host operating Mobile both IPv6 and for a IPv4 home addresses.  The mobile router operating NEMO
   Basic Support (RFC 3963), our extensions can also be used to deal
   with multiple node
   cannot binding different set of care-of addresses registration sent from to each home
   address.

   The home agent MUST returns a multihomed
   mobile router.  Figure 5 shows binding acknowledgment and IPv4 address
   acknowledgment option to the example format of a Binding Update
   used by mobile node only when a mobile router.

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

                       Figure 5: NEMO Binding Update

8. node
   requests IPv4 home address mobility management.  In this case, this
   option MUST be presented before any BID options.  The status field of
   the IPv4 address acknowledgment option contains only the error code
   regarding IPv4 home address management.  The error value of the IPv4
   care-of address registration MUST be stored in the BID mobility
   option.

9.  IPsec and IKEv2 interaction

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

   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.

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

   For each home address the mobile node sets up security associations
   with the home agent, the mobile node must pick one care-of address
   and use that as the source address for all IKEv2 messages exchanged
   to create and maintain the IPsec security associations associated
   with the home address.  The resultant IKEv2 security association is
   created based on this care-of address.

   If the mobile node needs to change the care-of address, it just sends
   a Binding Update with the care-of address it wants to use, with the
   corresponding Binding Unique Identifier sub-option, mobility option, and with the 'K'
   bit set.  This will force the home agent to update the IKEv2 security
   association to use the new care-of address.  If the 'K' bit is not
   supported on the mobile node or the home agent, the mobile node MUST
   re-establish the IKEv2 security association with the new care-of
   address.  This will also result in new IPsec security associations
   being setup for the home address.

8.2.

9.2.  Transport Mode IPsec protected messages

   For Mobile IPv6 signaling message protected using IPsec in transport
   mode, the use of a particular care-of address among multiple care-of
   addresses does not matter for IPsec processing.

   For Mobile Prefix Discovery messages, [RFC-3775] requires the home
   agent to verify that the mobile node is using the care-of address
   that is in the binding cache entry that corresponds to the mobile
   node's home address.  If a different address is used as the source
   address, the message is silently dropped by the home agent.  This
   document requires the home agent implementation to process the
   message as long as the source address is is one of the care-of
   addresses in the binding cache entry for the mobile node.

8.3.

9.3.  Tunnel Mode IPsec protected messages

   The use of IPsec in tunnel mode with multiple care-of address
   introduces a few issues that require changes to how the mobile node
   and the home agent send and receive tunneled traffic.  The route
   optimization mechanism described in [RFC-3775] mandates the use of
   IPsec protection in tunnel mode for the HoTi and HoT messages.  The
   mobile node and the home agent may also choose to protect all may also choose to protect all reverse
   tunneled payload traffic with IPsec in tunnel mode.  The following
   sections address multiple care-of address support for these two types
   of messages.

9.3.1.  Tunneled HoTi and HoT messages

   The mobile node MAY use the same care-of address for all HoTi
   messages sent reverse tunneled through the home agent.  The mobile
   node may use the same care-of address irrespective of which
   correspondent node the HoTi message is being sent.  RFC 3775 requires
   the home agent to verify that the mobile node is using the care-of
   address that is in the binding cache entry, when it receives a
   reverse tunneled HoTi message.  If a different address is used as the
   source address, the message is silently dropped by the home agent.
   This document requires the home agent implementation to decapsulate
   and forward the HoTi message as long as the source address is one of
   the care-of addresses in the binding cache entry for the mobile node.

   When the home agent tunnels a HoT message to the mobile node, the
   care-of address used in the outer IPv6 header is not relevant to the
   HoT message.  So regular IPsec tunnel encapsulation with the care-of
   address known to the IPsec implementation on the home agent is
   sufficient.

9.3.2.  Tunneled Payload Traffic

   When the mobile sends and receives multiple traffic flows protected
   by IPsec to different care-of addresses, the use of the correct
   care-of address for each flow becomes important.  Support for this
   requires the following two considerations on the home agent.

   o  When the home agent receives a reverse tunneled payload traffic with message
      protected by 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 mode, it must check that the same care-of
      address for all HoTi
   messages sent reverse tunneled through the home agent.  The mobile
   node may use is one of the same care-of address irrespective of which
   correspondent node addresses in the HoTi message is being sent. binding cache
      entry.  According to RFC 3775 requires 4306, the IPsec implementation on the
      home agent to verify that does not check the mobile node is using source address on the outer IPv6
      header.  Therefore the care-of address that is used in the binding cache entry, when it receives a reverse
      tunneled HoTi message.  If a traffic can be different from the care-of address is used as
      the source address, address in the message IKEv2 exchange.  However, the Mobile
      IPv6 stack on the home agent MUST verify that the source address
      is silently dropped one of the care-of addresses registered by the mobile node
      before decapsulating and forwarding the payload traffic towards
      the correspondent node.

   o  For tunneled IPsec traffic from the home agent. agent to the mobile node,
      The IPsec implementation on the home agent may not be aware of
      which care-of address to use when performing IPsec tunnel
      encapsulation.  The Mobile IP stack on the home agent must specify
      the tunnel end point for the IPsec tunnel.  This document may require tight
      integration between the IPsec and Mobile IP implementations on the
      home agent.

10.  Security Considerations

   As shown in Section 9, the Multiple Care-of Addresses Registration
   requires IPsec protection for all the home agent implementation to decapsulate signaling between a mobile node
   and forward the HoTi message as long as the source address its home agent.

   With simultaneous binding support, it is one possible for a malicious
   mobile node to successfully bind a number of
   the victims' addresses as
   valid care-of addresses in the binding cache entry for the mobile node.

   When node with its home agent.
   Once these addresses have been bound, the malicious mobile node can
   perform a re-direction attack by instructing the home agent tunnels (e.g.
   setting filtering rules to direct a HoT message large file transfer) to tunnel
   packets to the mobile node, the
   care-of address used victims' addresses.  Such risk is highlighted in the outer IPv6 header [ID-
   MIP6ANALYSIS] and is not relevant to the
   HoT message.  So regular IPsec tunnel encapsulation with possible because the care-of
   address known to addresses specified
   by the IPsec implementation on mobile node in the binding update messages are not verified by
   home agent is
   sufficient.

8.3.2.  Tunneled Payload Traffic

   When (since Mobile IPv6 assumes an existing trust relationship
   between the mobile sends node and receives its home agent).

   Although such risk exists in Mobile IPv6, the risk level is escalated
   when simultaneous multiple traffic flows protected
   by IPsec to different care-of addresses, address bindings are performed.
   One fundamental difference is the use degree of risk involved is much
   greater in the correct simultaneous binding support case.  For a single
   care-of address for each flow becomes important.  Support for this
   requires the following two considerations on the home agent.

   o  When the binding, a mobile node can only have a single care-of
   address binding per home agent receives address at a reverse tunneled payload message
      protected by IPsec in tunnel mode, it must check that the given time.  However, for
   simultaneous multiple care-of address bindings, a mobile node can
   have more than one care-of address binding per home address at a
   given time.  This implies that a mobile node using simultaneous
   binding support can effectively bind more than a single victim's
   address.  Another fundamental difference is one the form of risk
   involved.  In the single care-of addresses in the address binding cache
      entry.  According to RFC 4306, the IPsec implementation on case, once the re-
   direction attack is initiated, a malicious mobile node would be
   unable to use its home agent does not check the source address on for communications (such as to receive
   control packets pertaining to the outer IPv6
      header.  Therefore file transfer).  However, in the
   simultaneous binding support case, a malicious mobile node could bind
   a valid care-of address used in the reverse
      tunneled traffic can be different from the addition to multiple victims addresses.
   This valid care-of address could then be used as
      the source address in the IKEv2 exchange.  However, the Mobile
      IPv6 stack on the home agent MUST verify that the source address
      is one of the care-of addresses registered by the malicious mobile
   node
      before decapsulating and forwarding the payload traffic towards
      the correspondent node.

   o  For tunneled IPsec traffic from the home agent to the mobile node,
      The IPsec implementation on the set up flow filtering rules at its home agent, thereby
   controlling and/or launching new re-direction attacks.

   Thus, in view of such risk, it is advisable for a home agent may not be aware to
   employ some form of
      which care-of address to use when performing IPsec tunnel
      encapsulation.  The Mobile IP stack on the home agent must specify
      the tunnel end point for the IPsec tunnel.  This may require tight
      integration between the IPsec and Mobile IP implementations on the
      home agent.

9.  Security Considerations

   As shown in Section 8, the Multiple Care-of Addresses Registration
   requires IPsec protected all verification mechanism before
   using the signaling between care-of addresses as a valid routing path to a mobile node and
   its home agent.

10. node.
   Some solutions to advert such problems are described in Appendix.

11.  IANA Considerations

   The following Extension Types MUST be assigned by IANA:

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

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

      *  MCOA NOTCOMPLETE (TBD)

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

      *  MCOA INCOMPLIANT MALFORMED (TBD)

      *  MCOA BID CONFLICT (TBD)

      *  MCOA PROHIBITED(TBD)

      *  MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

      *  MCOA FLAG CONFLICTS (TBD)

11.

12.  Acknowledgments

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

12.

13.  References

12.1.

13.1.  Normative References

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

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

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

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

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

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

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

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

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

12.2.

13.2.  Informative References

   [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
   K. Kuladinithi, "Motivations and Scenarios for Using Multiple
   Interfaces and Global Addresses",
   draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
   [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
   Multihoming in Network Mobility Support", RFC 4980, October 2007.

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

   [RFC-3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
   RFC 3972, March 2005.

   [RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
   Optimization for Mobile IPv6", RFC 4866, May 2007.

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

Appendix A.  Example Configurations

   In this section, we describe typical scenarios when a mobile node has
   multiple network interfaces and acquires multiple Care-of Addresses
   bound to a Home Address.  The Home Address of the mobile node (MN in
   figures) is a:b:c:d::EUI.  MN has 3 different interfaces and possibly
   acquires care-of addresses 1-3 (CoA1, CoA2, CoA3).  The MN assigns
   BID1, BID2 and BID3 to each care-of address.

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

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

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

   Figure 6 8 depicts the scenario where all interfaces of the mobile node
   are attached to foreign links.  After binding registrations, the home
   agent (HA) and the Correspondent Node (CN) have the binding entries
   listed in their binding cache database.  The mobile node can utilize
   all the interfaces.

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

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

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

   Figure 7 9 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 7. 9.  After de-registration, the ND state of the
   home address is managed by the MN.  MN can communicate with the HA
   through only the interface attached to the home link.  On the other
   hand, the mobile node can communicate with CN from the other
   interfaces attached to foreign links (i.e. route optimization).  Even when
   if MN is attached to the home link, it can still send Binding Updates
   for other active care-of addresses (CoA2 and CoA3). CoA3) to CNs.  If CN has
   bindings, packets are routed to each Care-of Addresses directly.  Any
   packet arrived at HA are routed to the primary interface. interface attached to the home
   link.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +----+-----+          +--+-+
        CoA2|           |                   |   Home Link
         +--+--+        |             --+---+------
         |  MN +========+               |
         +--+--+ CoA1                   |
            |                           |
            +---------------------------+
             (Disable interface)

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

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

   Figure 8 10 depicts the scenario where MN disables the interface
   attached to the home link and communicates with the interfaces
   attached to foreign links.  HA continues managing the ND state of the
   home address by Proxy neighbor advertisement.  The HA and the CN have
   the binding entries listed in their binding cache database.  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.

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

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

     Binding Cache Database:
        home agent's binding (Proxy neighbor advertisement is inactive)
              none
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
              binding [a:b:c:d::EUI  care-of address3  BID3]

   Figure 9: Several 11: Utilize Interfaces Attached to both Home Link and Returning Home Foreign Links

   Figure 9 11 depicts the scenario where multiple interfaces of MN are attached to
   both the home and foreign links.  There are two possible topologies
   whether the HA is single router at the home link. link or not.  The
   operation of ND is different in two topologies.  The HA and CN have
   the binding entries listed in Figure 9 11 in their binding cache database.
   database regardless of topologies.  The MN can not
   use HA also knows that the interface MN has
   attached to a foreign link unless a CN has a
   binding for the interface. home link.  All packets which arrive at the HA traffic from the Internet are
   intercepted by the HA and routed to one of either the MN's interfaces interface attached to
   the home link.

   Figure 10 depicts link or the scenario where interfaces of MN are attached to the foreign links.  One of foreign link  How
   to make the decision is managed by out of scope in this document.

   There are two different treatments of the home agent.
   The HA and CN have ND state of the binding entries listed in Figure 10 in their
   binding cache database.  The home agent advertises a prefix which is
   other than
   address.

   o  MN defends the home prefix.  The mobile node will generate a care-of address from the prefix and registers it to by regular ND (topology-a)

   o  HA defends the home agent.  Even if address by Proxy ND (topology-b)

   The first case is required that the mobile node attaches HA is the single exit router to a foreign link,
   the link Internet and is managed by
   its home agent.  It will tunnel the capable of intercepting packets to without relying
   on proxy ND.  The MN can manage the ND of the home agent, but address on the
   home agent is one-hop neighbor.  The cost of tunnel is
   negligible.  If link.  In the mobile node wants to utilize second case, the HA is not only an
   interface attached to router at the home but also interfaces attached to foreign
   link, it can use this foreign
   link and cannot intercept all the packets meant for the MN by IP
   routing.  The HA needs to run Proxy ND to intercept all the packets
   at the home link.  Since the MN cannot operate the ND of its home
   addrss at the home agent to return a one
   hop foreign link on behalf link, HA cannot resolve the layer-2 address of a the
   MN at the home link.  This is different from
   the general returning home, but this enable  The HA MUST learn and record the capability layer-2
   address (MAC address) of using
   interfaces the MN's interface attached to both the home and foreign link without any
   modifications
   to Mobile IPv6 and NEMO basic support.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +----+-----+          ++-+-+
        CoA2|           |                 | |   Home Link
         +--+--+        |             ----|-+------
         | forward packets.  The packets forwarding is achieved without ND
   cache.  The MN +========+                 |
         +--+--+ CoA1                ---+-+------
       CoA3 |                           |  Foreign Link
            +---------------------------+

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

   Figure 10: Emulating to Utilize Interfaces Attached also required to both Home learn and
                               Foreign Links record the layer-2
   address of the HA's interface to send packets from the home link.

Appendix B.  Changes From Previous Versions

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

   o  Change the handling of  Binding Unique Identifier is renamed to Bidning Identifier

   o  New Status field.  All Code [MCOA NOTCOMPLETE], the home agent uses this
      status value is
      defined for BA code in the Binding Acknowledgement when not all the
      bindings are accepted in the bulk registration.

   o  Alternate CoA option is omitted, but using C flag  [MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED]

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

   o  Adding examples of BU  Support DSMIPv6

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

   o  Editorial updates, thanks George Tsirtsis for detailed comments!

Authors' Addresses

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

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/

   Thierry Ernst
   INRIA
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153
   France

   Phone: +33-1-39-63-59-30
   Fax:   +33-1-39-63-54-91
   Email: thierry.ernst@inria.fr
   URI:   http://www.nautilus6.org/~thierry
   Kenichi Nagami
   INTEC NetCore Inc.
   1-3-3, Shin-suna
   Koto-ku, Tokyo  135-0075
   Japan

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

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

   Email: vijay.devarapalli@azairenet.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

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

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

Intellectual Property

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

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

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

Acknowledgment

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