MEXT Working Group                                     R. Wakikawa (Ed.)
Internet-Draft                                           Keio University                                     Toyota ITC/Keio Univ.
Intended status: Standards Track                                T. Ernst
Expires: August 27, November 1, 2008                                          INRIA
                                                               K. Nagami
                                                           INTEC NetCore
                                                    V. Devarapalli (Ed.)
                                                         Azaire Networks
                                                       February 24,
                                                                Wichorus
                                                          April 30, 2008

                Multiple Care-of Addresses Registration
                 draft-ietf-monami6-multiplecoa-06.txt
                 draft-ietf-monami6-multiplecoa-07.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 August 27, November 1, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   According to the current Mobile IPv6 specification, a mobile node may
   have several care-of addresses, but only one, called the primary
   care-of address, that can be registered with its home agent and the
   correspondent nodes.  However, for matters of cost, bandwidth, delay,
   etc, it is useful for the mobile node to get Internet access through
   multiple accesses simultaneously, in which case the mobile node would
   be configured with multiple active IPv6 care-of addresses.  This
   document proposes extensions to the Mobile IPv6 protocol to register
   and use multiple care-of addresses.  The extensions proposed in this
   document can be used by Mobile Routers using the NEMO (Network
   Mobility) Basic Support protocol as well.

Table of Contents

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

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

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

   4.  Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . .  9 12
     4.1.  Binding Cache Structure and Binding Update List  . . . . .  9 12
     4.2.  Binding Identifier Mobility Option . . . . . . . . . . . .  9 12
     4.3.  New Status Values for Binding Acknowledgement  . . . . . . 11 14

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

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

   7.  Network Mobility Applicability . . . . . . . . . . . . . . . . 25 32

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

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

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33 40

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 41

   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 41
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 41
     13.2. Informative References . . . . . . . . . . . . . . . . . . 34

   Appendix A.  Example Configurations  . . . . . . . . . . . . . . . 36 41

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

1.  Introduction

   A mobile node may use various types of network interfaces to obtain
   durable and wide area network connectivity.  This is increasingly
   become true with mobile nodes having multiple interfaces such as
   802.2, 802.11, 802.16, cellular radios, etc..  The motivations for
   and benefits of using multiple points of attachment are discussed in
   [ID-MOTIVATION].  When a mobile node with multiple interfaces uses
   Mobile IPv6 [RFC-3775] for mobility management, it cannot use its
   multiple interfaces to send and receive packets while taking
   advantage of session continuity provided by Mobile IPv6.  This is
   because Mobile IPv6 allows the mobile node to only bind one care-of
   address at a time with its home address.

   This document proposes extensions to Mobile IPv6 to allow a mobile
   node to register multiple care-of addresses for a home address and
   create multiple binding cache entries.  A new Binding Identification
   (BID) number is created for each binding the mobile node wants to
   create and sent in the binding update.  The home agent that receives
   this Binding Update creates separate binding for each BID.  The BID
   information is stored in the corresponding binding cache entry.  The
   BID information can now be used to identify individual bindings.  The
   same extensions can also be used in Binding Updates sent to the
   correspondent nodes.

2.  Terminology

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

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

   Binding Identification number (BID)

      The BID is an identification number used to distinguish multiple
      bindings registered by the mobile node.  Assignment of distinct
      BIDs allows a mobile node to register multiple binding cache
      entries for a given home address.  The BID MUST be unique for a
      binding to a specific care-of address for a given home address and
      care-of address pair.  Zero and negative values MUST NOT be used.
      Each BID is generated and managed by a mobile node.  The BID is
      stored in the Binding Update List and is sent by the mobile node
      in the Binding Update.  A mobile node MAY change the value of a
      BID at any time according to its administrative policy, for
      instance to protect its privacy.  An implementation must carefully
      assign the BID so as to keep using the same BID for the same
      binding even when the status of the binding is changed.  More
      details can be found in Section 5.1.

   Binding Identifier Mobility Option

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

   Bulk Registration

      A mobile node can register multiple bindings at once by sending a
      single Binding Update.  A mobile node can also replace some or all
      the bindings available at the home agent with the new bindings by
      using the bulk registration.  Bulk registration is supported only
      for home registration (i.e. with the home agent agent) as explained in
      Section 5.5. 5.4.  A mobile node MUST NOT perform bulk registration
      with a correspondent node.

3.  Protocol Overview

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

   If the mobile host wishes to register its binding with a
   correspondent node, it must perform return routability operations.
   This includes managing a Care-of Keygen token per care-of address and
   exchanging CoTi and CoT message with the correspondent node for each
   care-of address.  The mobile node MAY use the same BID that it used
   with the home agent for a particular care-of address.  For protocol
   simplicity, bulk registration to correspondent nodes is not supported
   in this document.  This is because the Return Routability mechanism
   introduced in [RFC-3775] cannot be easily extended to verify multiple
   care-of addresses stored in a single Binding Update.

   Figure 1 illustrates the configuration where the mobile node obtains
   multiple care-of addresses at foreign links.  The mobile node can
   utilize all the care-of address.  In Figure 1, the home address of
   the mobile node (MN) is a:b:c:d::EUI.  The mobile node has 3
   different interfaces and possibly acquires care-of addresses 1-3
   (CoA1, CoA2, CoA3).  The mobile node 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 1: Multiple Care-of Address Registration

   If the mobile node decides to act as a regular mobile node compliant
   with [RFC-3775], it sends a Binding Update without any Binding
   Identifier mobility options.  The receiver of the Binding Update
   deletes all the bindings registering with a BID and registers only a
   single binding for the mobile node.  Note that the mobile node can
   continue using the BID even if it has only a single binding that is
   active.

   Binding cache lookup is done based on the home address and BID
   information.  This is different from RFC 3775, where only the home
   address is used for binding cache lookup.  The binding cache lookup
   may also involve policy or flow filters in cases where some policy or
   flow filters are used to direct certain packets or flows to a
   particular care-of address.  The binding cache lookup using policy or
   flow filters is out of scope for this document.  In case the binding
   cache lookup, using the combination of home address and BID, does not
   return a valid binding cache entry, the home agent MAY perform
   another lookup based on only the home address.  This is
   implementation dependent and configurable on the home agent.

   The mobile node may return to the home link through one of its
   interfaces.  There are three options possible for the mobile node
   when its returns home.  Section 5.6 describes the returning home
   procedures in more detail.

   1.  The mobile node uses only the interface with which it attaches to
       the home link.  This is illustrated in Figure 2.  It de-registers
       all bindings with the home agent related to all care-of
       addresses.  The interfaces still attached to the visited link(s)
       are no longer going to be receiving any encapsulated traffic from
       the home agent.

   2.  The  On the other hand, the mobile node uses only can continue
       communicating with the correspondent node from the other
       interfaces attached to foreign links by using route optimization.
       Even if the mobile node is attached to the home link, it can
       still send Binding Updates for other active care-of addresses
       (CoA1 and CoA2) to correspondent nodes.  Since the correspondent
       node has bindings, packets are routed to each Care-of Addresses
       directly.

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

     Binding Cache Database:
        home agent's binding
              none
        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 2: Using only Interface Attached to Home Link

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

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

     Binding Cache Database:
        home agent's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]

          Figure 3: Using only interface attached to the visited link

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

   Section 5.6 describes link(s) as shown in Figure 4.  There are two possible
       topologies depending on whether the returning home procedures agent is only router on
       the home link or not.  The operation of Neighbor Discovery [RFC-
       2461] is different in more detail.

4.  Mobile IPv6 Extensions

   This section summarizes the extensions two topologies.  The home agent and the
       correspondent node have the binding entries listed in Figure 4 in
       their binding cache database in both topologies.  The home agent
       also knows that the mobile node has attached to the home link.
       All the traffic from the Internet is intercepted by the home
       agent first and routed to either the interface attached to the
       home link or the one of the foreign links.  How the home agent
       decides to route a particular flow to the interface attached to
       the home link or foreign link is out of scope in this document.

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

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

     Binding Cache Database:
        home agent's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]

            Figure 4: Simultaneous Home and Visited Link Operation

4.  Mobile IPv6 Extensions

   This section summarizes the extensions to Mobile IPv6 necessary for
   manage multiple bindings.

4.1.  Binding Cache Structure and Binding Update List

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

4.2.  Binding Identifier Mobility Option

   The Binding Identifier mobility option is included in sequence number value SHOULD be shared among all the Binding
   Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
   Test Init and Care-of Test message.

                      1                   2                   3 binding
   update list entries related to binding updates sent to a particular
   home agent or correspondent node.  Whenever a mobile node sends
   either individual or bulk binding update, the sequence number is
   incremented.  On the other hand, if a mobile node manages an
   individual sequence value per binding update list, a mobile node
   SHOULD carefully select the sequence number value for the bulk
   binding update.  This is because all the bulk-registered bindings use
   the same Sequence Number specified in the Binding Update.  If each
   binding uses different sequence number, a mobile node MUST use the
   largest sequence number from the Binding Update list entries used for
   the bulk registration.  If the mobile node cannot select a sequence
   number for all the bindings due to sequence number out of window, it
   MUST NOT use the bulk registration for the binding whose sequence
   number is out of window.  A separate Binding Update should be sent
   for the binding.

4.2.  Binding Identifier Mobility Option

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

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

                       Figure 1: 5: BID Mobility Option
   Type

      Type value for Binding Identifier is TBD

   Length

      8-bit unsigned integer.  Length of the option, in octets,
      excluding the Type and Length fields.  It MUST be set to 4 when either 4,
      12, or 20 depending on the
      'C' flag care-of address field.  When the
      care-of address is unset. not carried by this option, the length value
      MUST be set to 4.  If the IPv4 care-of address is stored in the
      care-of address field, the length MUST be 12.  Otherwise, the
      Length value MUST be set to
      either 8 or 20 depending on the 'D' (DSMIPv6) flag. for IPv6 care-of address.

   Binding ID (BID)

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

   Status

      When the Binding Identifier mobility option is included in a
      Binding Acknowledgement, this field overwrites the status field in
      the Binding Acknowledgement.  If this field is zero, the receiver
      MUST use the registration status stored in the Binding
      Acknowledgement message.  This Status field is also used to carry
      error information related to the care-of address test in the
      Care-of Test message.  The status is 8-bit unsigned integer.  The
      possible status codes are the same as the status codes of Binding
      Acknowledgement.

   Care-of address (C) flag

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

   Overwrite (O)

   Overwrite (O) flag

      When this flag is set, a mobile node requests the recipient to
      replace all the bindings to binding entries stored in a Binding
      Update.

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

   DSMIPv6 (D) flag

      This flag indicates that the care-of address is an IPv4 address.
      When this flag is set, the care-of address field MUST contain an
      IPv4 address.

   Reserved

      5 bits Reserved field.  The reserved field MUST be zero.

   Care-of Address

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

4.3.  New Status Values for Binding Acknowledgement

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

   MCOA NOTCOMPLETE (TBD < 128)

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

   MCOA RETURNHOME WO/NDP (TBD < 128)

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

   MCOA MALFORMED (TBD more than 128)

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

   MCOA BID CONFLICT (TBD more than 128)

      The home agent cannot cache both a regular binding and a BID
      extended binding simultaneously.  It returns this status value
      when the received binding conflicts with the existing binding
      cache entry(ies).

   MCOA PROHIBITED(TBD more than 128)
      It implies the multiple care-of address registration is
      administratively prohibited.

   MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128)

      Bulk binding registration is not supported.

5.  Mobile Node Operation

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

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

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

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

   The difference between the above two cases is only in the number of
   physical network interfaces and therefore irrelevant in this
   document.  What is of significance is the fact that the mobile node
   has several addresses it can use as care-of addresses.

   A mobile node assigns a BID to each care-of address when it wants to
   register them simultaneously with its home address.  The BID MUST be
   unique for a given home address and care-of address pair.  The value
   should be an integer between 1 and 65535.  Zero and negative values
   MUST NOT be used as BIDs.  If a mobile node has only one care-of
   address, the assignment of a BID is not needed until it has multiple
   care-of addresses to register with, at which time all of the care-of
   addresses MUST be mapped to BIDs.

5.2.  Return Routability: Sending CoTI and Receiving CoT

   When a mobile node wants to register multiple care-of address with a
   correspondent node, it MUST have the valid Care-of Keygen token per
   care-of address.  The mobile node needs only one Home Keygen token
   for its home address.

   The mobile node MUST include a Binding Identifier mobility option in
   the Care-of Test Init message.  It MUST NOT set any flags in the
   mobility option.  The receiver (i.e. correspondent node) will
   calculate a care-of Keygen token as specified in [RFC-3775] and reply
   with a Care-of Test message, with the Binding Identifier mobility
   option as described in Section 6.2.  When the mobile node receives
   the Care-of Test message, the message is verified as in [RFC-3775].
   If a Binding Identifier mobility option is not present in the CoT
   message in reply to the CoTI message that included a Binding
   Identifier mobility option, the mobile node must assume that the
   correspondent node does not support Multiple Care-of Address
   registration.  Thus, the mobile node MUST NOT use a Binding
   Identifier mobility option in any future Binding Updates to that
   correspondent node.  The mobile node MAY skip re-sending regular CoTI
   message and keep the received care-of Keygen token for the regular
   Binding Update.

5.3.  Binding Registration

   For the multiple Care-of Addresses registration, the mobile node MUST
   include a Binding Identifier mobility option(s) in the Binding Update
   as shown in Figure 2. 6.  The BID is copied from a corresponding Binding
   Update List entry to the BID field of the Binding Identifier mobility
   option.  When IPsec ESP is used for protecting the Binding Update,
   the care-of address can be carried in the Care-of Address field of
   the Binding Identifier mobility option.  If this is done, the
   alternate care-of address option MUST NOT be included in the Binding
   Update.  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]) before sending the Binding Update.
   The care-of Keygen tokens MUST be maintained for each care-of address
   that the mobile node wants to register to the correspondent node.
   The Binding Update to the correspondent node is protected by the
   Binding Authorization Data mobility option that is placed after the
   Binding Identifier mobility option.

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

             Figure 2: 6: Binding Update for Binding Registration

5.4.  Bulk Registration

   Bulk registration is an optimization for binding multiple care-of
   addresses to a home address using a single Binding Update.  This is
   very useful if the mobile node, for instance, does not want to send a
   lot of signaling messages through an interface where the bandwidth is
   scarce.  This document specifies bulk registration only for the
   mobile node's home registration.  A mobile node performing bulk
   registration with a correspondent node is out of scope.

   To use bulk registration, the mobile node includes a Binding
   Identifier Mobility option for each BID and Care-of address pair it
   wants to register in the same Binding Update message.  This is shown
   in Figure 3. 7.  The rest of the fields and options in the Binding
   Update such as Lifetime, Sequence Number, and the flags in the
   Binding Update are common across all care-of addresses.  The
   alternate care-of address option MUST NOT be used.

   In the bulk registration, the Sequence Number field of a

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header
                    Mobility header
                        -Binding Update
                       Mobility Options
                          - Binding Identifier mobility options (CoA)

              Figure 7: Binding Update SHOULD be carefully configured.  This is because all for Bulk Registration

   If the bulk- mobile node wants to replace existing registered bindings use on
   the same Sequence Number specified home agent with the bindings 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 entries used for the bulk registration.  If the mobile
   node cannot select a sequence number for all the bindings due to
   sequence number out of window, it MUST NOT use the bulk registration
   for the binding whose sequence number is out of window.  A separate
   Binding Update should be sent for the binding.

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

              Figure 3: Binding Update for Bulk Registration

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

5.5.  Binding De-Registration

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

   If a mobile node wants to delete a particular binding(s) from its
   home agent and correspondent nodes, the mobile node sends a Binding
   Update with lifetime set to zero and includes a Binding Identifier
   mobility option(s) with the BID(s) it wants to de-register.  The
   receiver will remove only the care-of address(es) that match(es) the
   specified BID(s).  The care-of addresses field in each mobility
   option SHOULD be omitted by the sender and MUST be ignored by the
   receiver.  This is because the receiver will remove the binding that
   matches the specified BID.

5.6.  Returning Home

   The mobile node may return to the home link, by attaching to the home
   link through one of its interfaces.  When the mobile node wants to
   return home, it should be configured with information on what
   interface it needs to use.  The mobile node may use only the
   interface with which it is attached to the home link, only the
   interfaces still attached to the visited link link(s) or use both
   interfaces attached to the home link and visited link link(s)
   simultaneously.  The following describes each option in more detail.

5.6.1.  Using only Interface attached to the Home Link

   The mobile node returns home and de-registers all the bindings as
   shown in Figure 8 2 and as defined in [RFC-3775].  De-registering all
   the bindings is the same as binding de-registration from foreign link
   described in Section 5.5.  After the de-registration step, all the
   packets routed by the home agent are only forwarded to the interface
   attached to the home link, even if there are other active interfaces
   attached to the visited link. link(s).  While the mobile node de-registers
   all the bindings from the home agent, it may continue registering
   bindings for interface interface(s) attached to visited link link(s) to the
   correspondent node as shown in Figure 8. 2.

5.6.2.  Using only Interface attached to the Visited Link

   The mobile node returns home and shuts down the interface attached to
   the home link as shown in Figure 9. 3.  Before shutting down the
   interface, any binding for the care-of address previously associated
   with the interface should be deleted.  To delete the binding cache
   entry, the mobile node SHOULD send a de-registration Binding Update
   with the lifetime set to zero and include the corresponding BID
   information.  If the mobile node does not send a de-registration
   Binding Update, the binding for the care-of address previously
   assigned to the interface remains at the home agent.  This binding is
   deleted only when it agent until its
   lifetime expires.

   In order to avoid this, this scenario, despite the fact that the mobile node SHOULD send a de-registration binding update for the interface
   attached is connected
   to the its home link.

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

5.6.3.  Simultaneous Home and Visited Link Operation

   In this case, the

   [Problems of Simultaneous Home and Foreign Attachments]

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

   In [RFC-3775], the home agent intercepts packets meant for the mobile
   node using proxy the Proxy Neighbor Discovery [RFC-2461] while the mobile
   node is away from the home link.  When the mobile node returns home,
   the home agent deletes the binding cache and stops proxying for the
   home address so that a mobile node can configure its home address on
   the interface attached to the home link.  In this specification, a
   mobile node may return home, configure the home address on the
   interface attached to the home link, but still use the interfaces
   attached to the foreign links.  In this case, a possible conflict
   arises when the both the home agent and the mobile node try to defend
   the home address.  If the home agent stops proxying for the home
   address, the packets are always routed to the interface attached to
   the home link and are never routed to the interfaces attached to the
   visited links.  It is required to avoid the conflict between the home
   agent and the mobile node, while still allowing the simultaneous use
   of home and foreign links.  The following describes the mechanism for
   achieving this.

   [Overview and Approach]

   In this specification, the home agent MUST intercept all the packets
   meant for the mobile node and decide whether to send the traffic
   directly to the home address on the link or tunnel to the care-of
   address.  The home agent intercepts all the packets even when the
   mobile node is attached to the home link through one of its
   interfaces.  The home agent would make this decision based on the
   type of packets and flows. flow.  How to make this decision is out of scope in this
   document.  The critical part would be to create a neighbor
   cache entry for

   Two scenarios are illustrated in Figure 4, depending on whether the mobile node so that
   Home Agent is the only router at the home agent can deliver
   the packets on-link. link or not.  The home agent would need to know
   difference is on who defends the Layer-2 home address of the interface with which by (Proxy) Neighbor
   Discovery on the mobile home link.

   1.  Mobile node defends the home address by the regular Neighbor
       Discovery Protocol (illustrated as topology-a in Figure 4).  The
       home agent is attached to the only router on the home link.  In order to create  Therefore the neighbor cache entry for
       home agent is capable of intercepting packets without relying on
       the proxy Neighbor Discovery protocol and the
   mobile node, following operations are required.

   The mobile node sends a de-registration Binding Update to the home
   agent from can
       manage the interface attached to Neighbor Cache entry of the home link.  In address on the Binding
   Update, home
       link as a regular IPv6 node.

   2.  If there are other routers on the BID mobility option must include home link apart from the BID home
       agent, then it cannot be guaranteed that all packets meant for
       the mobile node
   had previously associated with the interface attached are routed to the home
   link.  The 'H' flag MUST be set in agent.  In this case, the BID mobility option.  The 'C'
   flag
       mobile node MUST NOT be set and operate Neighbor Discovery protocol for the care-of
       home address field MUST NOT be
   included.  When on the 'H' flag is set, home link.  This allows the home agent recognizes that
   the mobile node wants to continue
       keep using interfaces attached to both
   home proxy neighbor discovery and visited links.  If thus it keeps receiving
       all the 'H' flag is unset, packets sent to the mobile node's home agent
   deletes either all the bindings or address.  If the binding corresponding
       home agent, according to its local policy, needs to deliver
       packets to the
   BID included in mobile node over the Binding Identifier mobility option.

   When home link, an issue arises
       with respect to how the home agent sends discovers the mobile node's
       link local address.  This specification uses Link-layer Address
       (LLA) Option defined in [RFC-4068bis] in order to carry the
       mobile node's link-layer address in the Binding Acknowledgement, it MUST set Update.
       Likewise, the status value mobile node would also know the link-layer address
       of the default router address to either 0 [Binding Update Accepted] or send packets from the home link
       without Neighbor Discovery.  The link-layer address is used to
       transmit packets from and to
   [MCOARETURNHOME WO/NDP (TBD)] in the BID mobility option depending mobile node on
   home agent configuration at the home link.
       The new values are:

   o  Binding Update Accepted (0): NDP is permitted for packets are transmitted without the home address
      at Neighbor Discovery
       protocol by constructing the home link. link-layer header manually.  This is regular returning home
       operation of
      [RFC-3775]

   o  MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for similar to Mobile IPv6 [RFC-3775] when a mobile node
       sends a deregistration binding update to the home agent's link-
       layer address at the in returning home link

   When operation.

   [Sending Deregistration Binding Update]

   o  As soon as a mobile node returns home, it sends a de-registration
      Binding Update to the home agent is from the only router at interface attached to
      the home link, it can
   intercept all link.

   o  The mobile node MUST include the packets by normal IP routing without using proxying
   for BID mobility option specifying
      the home address.  It stops proxy ND for BID the requested home
   address and responds mobile node had previously associated with the [Binding Update Accepted] status value
      interface attached to the mobile node. home link.  The neighbor cache entry for 'H' flag MUST be set in
      the mobile node is
   created by BID mobility option.  Any address MUST NOT be set in the regular exchange of Neighbor Solicitation and Neighbor
   Advertisement.  If
      Care-of Address field in the home agent BID mobility option.  When the 'H'
      flag is not set, the only router on home agent recognizes that the mobile node wants
      to continue using interfaces attached to both home
   link, it and visited
      links.  Note that H flag MUST continue defending be set for all the home address by proxy neighbor
   discovery in order to intercept binding updates
      sent from the mobile node's traffic.  The home
   agent, then, returns [MCOA RETURNHOME WO/NDP] value in node (ex.  Binding Update for the Status
   field of
      interface(s) attached to the BID mobility option. foreign link(s)).

   o  The home agent also learns mobile node SHOULD include the Link-layer Address (LLA) Option
      [RFC-4068bis] to notify the mobile node's layer-2 link-layer address (i.e., MAC address) during this binding
   de-registration.  It stores to
      the learnt layer-2 address in a neighbor
   cache entry for home agent, too.  The option code of the mobile node so that it can construct Link-layer Address
      (LLA) option MUST be set to '2' (Link-layer Address of the layer-2
   header mobile
      node).  This link-layer address is required for the packets meant for home agent to
      send the mobile node Binding Acknowledgement and forwards them
   directly to forward the mobile node's interface attached to the home link.
      packet.

   o  According to [RFC-3775], the mobile node MUST NOT assign the start responding to
      Neighbor Solicitation for its home address to right after it sends
      the interface attached deregistration Binding Update to the home link and MUST NOT
   attempt NDP operations for the home address before agent.  However, in
      this specification, the completion of
   binding de-registration.  It mobile node MUST NOT send and reply respond to Neighbor
      Solicitation before receiving a Binding Acknowledgement, since the
      home agent may continue proxying for the home address.  The home address MUST be
   tentative address at this moment until it receives Binding
   Acknowledgement with success status value.

   When  If the
      mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value
      in the received Binding Acknowledgement and BID
   mobility option, Acknowledgment, it assigns home address to the interface attached MUST NOT respond to
      Neighbor Solicitation even after the Binding Acknowledgement.

   [Sending Binding Acknowledgement]

   o  When the home link according to agent sends the status field of Binding Acknowledgement after
      successfully processing the BID.  If binding de-registration, it MUST set
      the status value
   is to either 0 [Binding Update Accepted], Accepted] or to [MCOA
      RETURNHOME WO/NDP (TBD)] in the mobile node can start defending Status field of the Binding
      Acknowledgment depending on home address using regular Neighbor Discovery.

   If agent configuration at the mobile node receives home
      link.  The new values are:

      *  Binding Update Accepted (0): NDP is permitted for the [MCOA RETURNHOME WO/NDP], it MUST NOT
   defend its home
         address on at the home link.  When  This is regular returning home
         operation of [RFC-3775]

      *  MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the mobile node sends
   packets from home
         address at the interface attached home link

      If the binding update is rejected, the appropriate error value
      MUST be set to the status field.  In this case, the home agent
      operation is same as [RFC-3775].

   o  If the home agent is the only router at the home link, it MUST learn stops
      proxy Neighbor Discover for the layer 2 requested home address (i.e., MAC address) of and
      responds with the next hop (i.e. default
   router, it can be home agent) during [Binding Update Accepted] status value to the binding de- registration and
   construct
      mobile node.  Since the packet including layer 2 header with mobile node will not reply to Neighbor
      Solicitation for the learnt layer-2 home address of before receiving the default router or Binding
      Acknowledgement, the home agent.

5.7.  Receiving Binding Acknowledgement

   The verification of a agent SHOULD use the link-layer address
      carried by the Link Layer Address option [RFC-4068bis] in the
      received Binding Acknowledgement is Update.  After the same as Mobile
   IPv6 (section 11.7.3 completion of [RFC-3775]).  The operation for sending a
   Binding Acknowledgement is described in Section 6.3.

   If a mobile node includes a Binding Identifier mobility option in a
   Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
   carry a Binding Identifier mobility option.  If no such mobility
   option is included in the Binding Acknowledgement in response to a
   Binding Update for multiple care-of address registration, this
   indicates that binding
      deregistration, the originating mobile node of starts regular Neighbor Discovery
      operations for the Binding Acknowledgement
   does not support processing home address on the Binding Identifier mobility option. home link.  The mobile node MUST then stop multiple care-of neighbor
      cache entry for the home address registration
   with that node.

   If a Binding Identifier mobility option is present in the received
   Binding Acknowledgement, the mobile node checks the status field in created by the option.  If regular
      exchange of Neighbor Solicitation and Neighbor Advertisement.

   o  On the status value in other hand, if the Binding Identifier mobility
   option home agent is zero, the mobile node uses the value in not the Status field of only router on the Binding Acknowledgement.  Otherwise,
      home link, it uses the returns [MCOA RETURNHOME WO/NDP] value in the Status
      field of the Binding Identifier BID mobility option.

   If the status code is greater than or equal to 128,  The home agent learns the
      mobile node
   starts relevant operations according to node's link-layer address by receiving the error code.  Otherwise, link-layer
      address option carried by the Binding Update.  It stores the link-
      layer address as a neighbor cache entry for the mobile node assumes so
      that it can send the originator (home agent or
   correspondent node) successfully registered the binding information
   and BID for packets to the mobile node. node's link-layer
      address.

   o  If  Note that the Status value is [MCOA PROHIBITED], the mobile node MUST
      stop registering multiple bindings to the node that sent the
      Binding Acknowledgement.

   o  If the Status value use of proxy Neighbor Discovery is [MCOA BULK REGISTRATION NOT SUPPORT], easier way to
      intercept the mobile node SHOULD stop using bulk registrations with the node
      that sent the Binding Acknowledgement.

   o  If [MCOA MALFORMED] nodes' packets instead of IP routing in some
      deployment scenarios.  Therefore, even if a home agent is specified, it indicates that the binding
      identifier mobility option only
      router, it is formatted wrongly. an implementation and operational choice whether the
      home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
      WO/NDP].

   o  If [MCOA BID CONFLICT] option is specified, not included in the binding entry specified
      by Binding Acknowledgement, the
      home agent might not recognize the simultaneous home and foreign
      attachment.  The home agent might have processed the de-
      registration Binding Identifier mobility option is already registered Update as a regular binding.  In such case, de-registration as
      described in [RFC-3775] and deletes all the registered binding
      cache entries for the mobile node.  Thus, the mobile node SHOULD
      stop
      sending Binding Updates with BID, or SHOULD using the interface attached to foreign link and use only the 'O' flag
      interface attached to
      reset all the registered bindings.

5.8.  Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is home link.

   [Sending Packets from the Home Link]

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

   If a mobile node receives a the Binding Refresh Request Acknowledgement with a Binding
   Identifier mobility the
      status value 'Binding Update Accepted' and the BID option, it indicates that can
      configure its home address to the node sending interface attached to the
   Binding Refresh Request message is requesting home
      link and start operating Neighbor Discovery for the home address
      on the home link.  Packets can be transmitted from and to the
      mobile node to send
   a new Binding Update for as if the BID.  The mobile node SHOULD then send is a regular IPv6 node.

   o  If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
      the Binding Update only Acknowledgement, it MUST NOT operate Neighbor
      Discovery for the respective binding.  The home address.  When the mobile node sends
      packets from the interface attached to the home link, it MUST
   include
      learn the link-layer address of the next hop (i.e. default router
      of the mobile node).  A mobile node learns the default router's
      link-layer address from a Binding Identifier mobility Source Link-Layer Address option in
      Router Advertisements.  The mobile node sends packets directly to
      the Binding Update.

   If no Binding Identifier mobility option default router's link-layer address.  This is present in a done by
      constructing the packet including link-layer header with the
      learned link-layer address of the default router.  The home agent
      also forwards the packet to the mobile node on the home link by
      using the mobile node's link-layer address.  The link-layer
      address SHOULD be cached when the home agent received the
      deregistration Binding
   Refresh Request, Update message.

   [Leaving from the Home Link]

   o  When the mobile node sends detaches from the home link, it SHOULD
      immediately send a binding update for one of active care-of
      address with H flag unset.  When the 'H' flag of BID option is
      unset in any Binding Update according Update, the home agent stop forwarding the
      mobile node's packet to
   its Binding Update List. the home link.

   o  On the other hand, if the mobile node does not have any active
      care-of address to send a Binding Update List entry for and leaves the requesting node, home link
      (i.e. the mobile node needs is completely disconnected), the home agent
      continues forwarding packets to register either a single binding or multiple
   bindings depending on its binding management policy.

5.9.  Bootstrapping

   When a the mobile node bootstraps and registers multiple bindings for the
   first time, it MUST set until the 'O' flag in
      expiration of all the Binding Identifier
   mobility option.  If old bindings still exists at binding cache entries for the home agent, address.
      Once all the
   mobile node has no knowledge of which bindings still exist at are expired, the
   home agent.  This scenario happens when a mobile node reboots and
   looses state regarding the registrations.  If the 'O' flag is set,
   all assumed to
      be disconnected completely from networks.

   [Changing Behavior during the bindings are replaced by attachment to the new binding(s). home link]

   If the a mobile node receives the Binding Acknowledgement with the status code set decides to
   135 [Sequence number out of window], return home completely without any active
   foreign link attachment, it MUST retry sending simply sends a Binding
   Update with the last accepted sequence number indicated deregistration binding
   update as described in Section 5.6.1.  Once the
   Binding Acknowledgement.

   The 'O' flag can also be used in individual Binding Updates sent to home agent receives
   such de-registration binding update, the home agent clears all the correspondent nodes to override any existing
   binding cache
   entries at and states for the correspondent mobile node.

6.  Home Agent and Correspondent Node Operation

6.1.  Searching Binding Cache with Binding Identifier

   If either a correspondent mobile node or a decides to stop using the interface attached to the
   home agent has multiple bindings
   for link, it simply sends a mobile node in their binding cache database, it can use any update from the one of active
   care-of address.  In the bindings to communicate with Binding Update, the mobile node.  This section
   explains how to retrieve node should
   include the desired binding BID option for the binding
   management.  This document does not provide any mechnaism to select
   the suitable binding for forwarding data packets.

   A correspondent node SHOULD use both the home care-of address and unset the H flag
   of BID as option.  The home agent clears the search key states of the binding cache if it knows the corresponding BID
   (ex. when processing signaling messages).  In the example below, if a
   correspondent mobile node searches
   for the binding with interface attached to the home address link and
   BID2, it gets binding2 for this mobile node.

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

                   Figure 4: Searching the Binding Cache

   A correspondent node learns stop forwarding the BID when it receives a Binding
   Identifier mobility option.  At that time,
   packets to the correspondent mobile node
   MUST look up its binding cache database with on the home address and the
   BID retrieved from the link.

5.7.  Receiving Binding Update.  If the correspondent node
   does not know the BID, it searches for Acknowledgement

   The verification of a binding with only Binding Acknowledgement is the home
   address.  In such same as Mobile
   IPv6 (section 11.7.3 of [RFC-3775]).  The operation for sending a case, the first matched binding
   Binding Acknowledgement is found. described in Section 6.3.

   If the
   correspondent node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID.

6.2.  Receiving CoTI and Sending CoT

   When a correspondent node receives a CoTI message which contains includes a Binding Identifier mobility option, it processes it as follows.

   First, the CoTI message is verified as specified option in [RFC-3775].  The a
   Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
   carry a Binding Identifier mobility option.  If no such mobility
   option is processed as follows:

   o  If included in the Binding Acknowledgement in response to a correspondent
   Binding Update for multiple care-of address registration, this
   indicates that the originating node of the Binding Acknowledgement
   does not understand a Binding Identifier
      mobility option, it just ignores and skips support processing the option.
      The calculation of a care-of Keygen token will thus be done
      without a BID value.  The correspondent node returns a CoT message
      without a Binding Identifier mobility option.
   The mobile node
      knows whether the correspondent supports processing the MUST then stop multiple care-of address registration
   with that node.

   If a Binding Identifier mobility option, by checking if the option is present in the CoT message.

   o  If either received
   Binding Acknowledgement, the 'C' or mobile node checks the 'O' flag is set status field in
   the Binding Identifier
      mobility option, option.  If the correspondent Node SHOULD NOT calculate a
      care-of Keygen token, but MUST include a Binding Identifier
      mobility option with status value set to [MCOA MALFORMED] in the
      Care-of Test message.

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

   o  The Care-of address Status field of each
   the Binding Identifier mobility
      option, can be omitted, because Acknowledgement.  Otherwise, it uses the mobile node can identify value in the
      corresponding Binding Update list entry using
   Status field of the BID.

6.3.  Processing Binding Update

   If a Binding Update does not contain a Binding Identifier mobility
   option, its processing is same as in [RFC-3775]. option.

   If the receiver
   already has multiple bindings for the home address, it MUST replace
   all status code is greater than or equal to 128, the existing bindings by mobile node
   starts relevant operations according to the received binding.  As a result, error code.  Otherwise,
   the
   receiver mobile node MUST have only one assumes that the originator (home agent or
   correspondent node) successfully registered the binding cache entry information
   and BID for the mobile node.

   o  If the Binding Update Status value is for de-registration, [MCOA PROHIBITED], the receiver mobile node MUST delete all existing
      stop registering multiple bindings from its Binding Cache.

   If the Binding Update contains a Binding Identifier mobility
   option(s), it is first validated according to section 9.5.1 of [RFC-
   3775].  Then the receiver processes node that sent the
      Binding Identifier mobility
   option(s) as described in the following steps. Acknowledgement.

   o  The length value is examined.  The length value MUST be either 4,
      8, or 20 depending on the 'C' and 'D' flags.  If the length Status value is
      incorrect, [MCOA BULK REGISTRATION NOT SUPPORT], the receiver MUST reject
      mobile node SHOULD stop using bulk registrations with the Binding Update and returns node
      that sent the status value set to [MCOA MALFORMED]. Binding Acknowledgement.

   o  When the 'C' flag  If [MCOA MALFORMED] is set, the care-of address MUST be present in specified, it indicates that the Binding Identifier binding
      identifier mobility option. option is formatted wrongly.

   o  If the care-of address [MCOA BID CONFLICT] is
      not present, specified, the receiver MUST reject binding entry specified
      by the Binding Identifier mobility option and returns is already registered as
      a regular binding.  In such case, the status value set mobile node SHOULD stop
      sending Binding Updates with BID, or SHOULD use the 'O' flag to [MCOA
      MALFORMED].
      reset all the registered bindings.

5.8.  Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is the same as in
   Mobile IPv6 (section 11.7.4 of [RFC-3775]).  The operation of 'D' flag sending
   a Binding Refresh Request is described in section Section 8

   o  When multiple Binding Identifier mobility options are present in
      the Binding Update, it is treated as bulk registration. 6.4.

   If the
      receiving a mobile node is receives a correspondent node, it MUST reject the Binding
      Update and returns the status value in the binding acknowledgement
      set to [MCOA BULK REGISTRATION NOT SUPPORT]

   o  If Refresh Request with a Binding
   Identifier mobility option, it indicates that the Lifetime field in node sending the
   Binding Update Refresh Request message is set to zero, requesting the
      receiving mobile node deletes the binding entry that corresponds to send
   a new Binding Update for the
      BID in BID.  The mobile node SHOULD then send a
   Binding Update only for the respective binding.  The mobile node MUST
   include a Binding Identifier mobility option.  If option in the receiving Binding Update.

5.9.  Bootstrapping

   When a mobile node does not have an appropriate binding bootstraps and registers multiple bindings for the BID,
   first time, it MUST
      reject the Binding Update and send a Binding Acknowledgement with
      status set to 133 [not home agent for this mobile node].

   o  If the 'O' flag is set in the de-registering Binding Update, it is
      ignored. Identifier
   mobility option.  If old bindings still exists at the 'H' flag is set, the home agent stores a home
      address in agent, the Care-of Address field
   mobile node has no knowledge of which bindings still exist at the binding cache entry.
      The
   home agent also stops performing proxy ND for the agent.  This scenario happens when a mobile
      node's home address.

   o node reboots and
   looses state regarding the registrations.  If the Lifetime field 'O' flag is not set to zero, set,
   all the receiving bindings are replaced by the new binding(s).  If the mobile
   node
      registers a binding receives the Binding Acknowledgement with the specified BID as a mobile node's
      binding.  The Care-of address is obtained from the Binding Update
      packet as follows:

      *  If the 'C' flag is status code set in the to
   135 [Sequence number out of window], it MUST retry sending a Binding Identifier mobility
         option, the care-of address is copied from
   Update with the care-of address
         field last accepted sequence number indicated in the
   Binding Identifier mobility option.

      *  If the 'C' Acknowledgement.

   The 'O' flag is not set can also be used in the individual Binding Identifier mobility
         option, the care-of address is copied from the source address
         field of Updates sent to
   the IPv6 header.

      *  If correspondent nodes to override any existing binding cache
   entries at the 'C' flag is not set correspondent node.

6.  Home Agent and an alternate care-of address is
         present, the care-of address is copied from the Alternate
         Care-of address mobility option.

   o  Once the care-of address(es) have been retrieved from the Correspondent Node Operation

6.1.  Searching Binding
      Update, the receiving nodes creates new binding(s).

      *  If only the 'O' flag is set in the Cache with Binding Identifier mobility
         option, the

   If either a correspondent node or a home agent removes all the existing bindings and
         registers the received bindings.

      *  If the receiver has a regular binding which does not have BID multiple bindings
   for the a mobile node, node in their binding cache database, it must not process can use any of
   the binding update.
         The receiver should sent a binding acknowledgement bindings to communicate with status
         set the mobile node.  This section
   explains how to [MCOA BID CONFLICT].

      *  If retrieve the receiver already has a desired binding with the same BID but
         different care-of address, it MUST update for the binding and
         respond with a Binding Acknowledgement with status set to 0
         [Binding Update accepted].

      *  If the receiver
   management.  This document does not have a provide any mechanism to select
   the suitable binding entry for forwarding data packets.

   A correspondent node SHOULD use both the home address and the BID as
   the search key of the BID, it
         registers a new binding for cache if it knows the corresponding BID and responds with a Binding
         Acknowledgement with status set to 0 [Binding Update accepted].

   If all
   (ex. when processing signaling messages).  In the above operations are successfully completed, example below, if a Binding
   Acknowledgement containing
   correspondent node searches the Binding Identifier mobility options
   MUST be sent to binding with the home address and
   BID2, it gets binding2 for this mobile node.  Whenever a

             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 8: Searching the Binding Acknowledgement
   is sent, all Cache

   A correspondent node learns the BID when it receives a Binding
   Identifier mobility options stored in option.  At that time, the
   Binding Update correspondent node
   MUST be copied to the Binding Acknowledgement except look up its binding cache database with the status field.  The Care-of home address field in each and the
   BID retrieved from the Binding
   Identifier mobility option, however, can be omitted, because Update.  If the
   mobile correspondent node can match
   does not know the BID, it searches for a corresponding binding update list entry using with only the BID.

   When home
   address.  In such a case, the first matched binding is found.  If the
   correspondent node sends does not desire to use multiple bindings for a Binding Acknowledgement,
   mobile node, it can simply ignore the status
   value MUST be always stored in the Status field of the Binding
   Acknowledgement BID.

6.2.  Receiving CoTI and the Status field of Sending CoT

   When a correspondent node receives a CoTI message which contains a
   Binding Identifier mobility
   option set to zero.  For the home agent, option, it processes it as follows.

   First, the status value can be
   stored CoTI message is verified as specified in [RFC-3775].  The
   Binding Identifier mobility option is processed as follows:

   o  If a correspondent node does not understand a Binding Identifier
      mobility option, it just ignores and skips processing the Status field option.
      The calculation of either a Binding Acknowledgement or care-of Keygen token will thus be done
      without a BID value.  The correspondent node returns a CoT message
      without a Binding Identifier mobility option.  If  The mobile node
      knows whether the status value correspondent supports processing the Binding
      Identifier mobility option, by checking if the option is specific
   to one of bindings present
      in the bulk registration, CoT message.

   o  If either the status value MUST be
   stored in 'C' or the Status field 'O' flag is set in the corresponding Binding Identifier
      mobility option.  In this case, [MCOA NOTCOMPLETE] MUST be set to the
   Status field of the Binding Acknowledgement so that the receiver can
   examine option, the Status field of each correspondent Node SHOULD NOT calculate a
      care-of Keygen token, but MUST include a Binding Identifier
      mobility option
   for further operations.

6.4.  Sending Binding Refresh Request

   When a node (home agent or correspondent node) sends a Binding
   Refresh Request for a particular binding created with status value set to [MCOA MALFORMED] in the BID,
      Care-of Test message.

   o  Otherwise, the correspondent node SHOULD MUST include the a Binding
      Identifier mobility option in the
   Binding Refresh Request.  If the mobile node had used bulk
   registration, the sender SHOULD include all with status value set to zero (success)
      in the Care-of Test message.

   o  The Care-of address field of each Binding Identifier mobility options.  If
      option, can be omitted, because the mobile node had not used bulk registration, can identify the sender includes
      corresponding Binding Update list entry using the BID.

6.3.  Processing Binding Update

   If a Binding Update does not contain a Binding Identifier mobility options only for
   those
   option, its processing is same as in [RFC-3775].  If the receiver
   already has multiple bindings that need to be refreshed.

6.5.  Receiving Packets from Mobile Node

   When a node receives packets with a Home Address destination option
   from a mobile node, for the home address, it MUST check that replace
   all the care-of address that
   appears in existing bindings by the source address field of received binding.  As a result, the IPv6 header
   receiver node MUST be equal
   to have only one of the care-of addresses in the binding cache entry. entry for the mobile
   node.  If no
   binding is found, the packets MUST be silently discarded.  The node
   MUST also send a Binding Error message as specified in [RFC-3775].
   This verification MUST NOT be done Update is for a de-registration, the receiver
   MUST delete all existing bindings from its Binding Update.

7.  Network Mobility Applicability

   The binding management mechanisms are Cache.

   If the same for a mobile host that
   uses Mobile IPv6 and for Binding Update contains a mobile router that Binding Identifier mobility
   option(s), it is using first validated according to section 9.5.1 of [RFC-
   3775].  Then the NEMO Basic
   Support protocol [RFC-3963].  Therefore receiver processes the extensions Binding Identifier mobility
   option(s) as described in
   this document can also the following steps.

   o  The length value is examined.  The length value MUST be used to support a mobile router with
   multiple care-of addresses.

8.  DSMIPv6 Applicability

   Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 either 4,
      8, or 20 depending on the Care-of Address field.  If the length is
      incorrect, the receiver MUST reject the Binding Update and returns
      the status value set to
   register an IPv4 [MCOA MALFORMED].

   o  When the Length value is either 12 or 20, the care-of address instead of MUST
      be present in the Binding Identifier mobility option.  If the IPv6
      care-of address
   when the mobile node is attached to an IPv4-only access network.  It
   also allows not present, the mobile node receiver MUST reject the
      Binding Identifier mobility option and returns the status value
      set to acquire [MCOA MALFORMED].  If the Length value is 12, an IPv4 home valid
      address in
   addition to MUST be present.  Otherwise, 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

   The mobile node can use the extensions described MUST be
      stored in the document to
   register Binding Identifier mobility option.

   o  When multiple care-of addresses, even if some of the care-of
   addresses Binding Identifier mobility options are IPv4 address.

   Bulk registration MUST NOT be used for present in
      the initial binding from an
   IPv4 care-of address.  This Binding Update, it is because, treated as bulk registration.  If the
      receiving node is a correspondent node, it MUST reject the Binding
      Update and returns the status value in the binding acknowledgement exchange is used
      set to detect NAT on the path
   between [MCOA BULK REGISTRATION NOT SUPPORT]
   o  If the mobile node and Lifetime field in the home agent.  So Binding Update is set to zero, the mobile
      receiving node needs deletes the binding entry that corresponds to check the
      BID in the Binding Identifier mobility option.  If the receiving
      node does not have an appropriate binding for a NAT between each IPv4 care-of address and the home
   agent.

   The BID, it MUST
      reject the Binding Update MUST be sent and send a Binding Acknowledgement with
      status set to the IPv4 133 [not home agent address by
   using UDP and IPv4 headers as shown for this mobile node].

   o  If the 'O' flag is set in Figure 5.  It the de-registering Binding Update, it is similar to
   [ID-DSMIPv6] except that
      ignored.  If the IPv4 care-of 'H' flag is set, the home agent stores a home
      address option MUST NOT be
   used when in the BID mobility option is used.

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

         Figure 5: Initial Binding Update for IPv4 Care-of Address field of the binding cache entry.
      The home agent also stops performing proxy ND for the mobile
      node's home address.

   o  If a NAT the Lifetime field is not detected, set to zero, the mobile receiving node can update
      registers a binding with the IPv4 care-of
   address by using bulk registration.  The specified BID as a mobile node can register the
   IPv4 care-of node's
      binding.  The Care-of address along with other IPv4 and IPv6 care-of
   addresses.  Figure 6 shows is obtained from the Binding Update format when
      packet as follows:

      *  If the mobile
   node sends a Binding Update from one Length value of its IPv6 care-of addresses.
   If the mobile node sends a BU from IPv4 care-of address, it MUST
   follow the format described in Figure 5.  Note that the IPv4 Care-of
   Address must be registered by non bulk Binding registration, whenever
   it is changed.

              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 6: Binding Bulk Registration for IPv4 mobility option
         is 20, the care-of address

   If is copied the home agent rejects IPv6 address from the IPv4
         care-of address, it MUST store the
   error code value in the Status address field of in the BID Binding Identifier mobility
         option.

8.2.  IPv4 HoA Management  When the mobile node wants to configure an IPv4 home address in
   addition to Length value is 12, the IPv6 home address, it can request for one using address MUST be the
         IPv4 Home Address option valid address.  Detail information can be found in the Binding Update.
         Section 8.

      *  If the home agent
   accepts Length value of the Binding Update, Identifier mobility option
         is 4, the mobile node can now register multiple care-of addresses for address is copied from the IPv4 home source address in addition to
         field of the IPv6
   home address.  The same set header.

      *  If the Length value of care-of addresses will be registered
   for both IPv6 the Binding Identifier mobility option
         is 4 and IPv4 home addresses.  The mobile node cannot bind
   different set of an alternate care-of addresses to each home address.

   According to [ID-DSMIPv6], the home agent includes address is present, the IPv4 care-of
         address
   acknowledgement option in is copied from the Binding Acknowledgement only if Alternate Care-of address mobility
         option.

   o  Once the
   mobile node had requested for an IPv4 home address in care-of address(es) have been retrieved from the
   corresponding Binding Update.  The IPv4 address acknowledgement
   option MUST be present before any BID option.  The status field of
      Update, the IPv4 address acknowledgement option contains receiving nodes creates new binding(s).

      *  If only the error code
   corresponding to the IPv4 home address management.  The error values
   related to the IPv4 care-of address registration MUST be stored 'O' flag is set in the BID Binding Identifier mobility option.

9.  IPsec and IKEv2 interaction

   Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require
         option, the
   use of IPsec to protect signaling messages like Binding Updates,
   Binding Acknowledgements and return routability messages.  IPsec may
   also be used protect home agent removes all 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 [RFC-4877] with
   respect to the use of IKEv2 existing bindings and IPsec.

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

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

   o  When received bindings.

      *  If the home agent receives receiver has a packet from regular binding which does not have BID
         for the mobile node, it must not process the
      source address is verified against the care-of address in the
      corresponding binding cache entry. update.
         The receiver should sent a binding acknowledgement with status
         set to [MCOA BID CONFLICT].

      *  If the packet is receiver already has a reverse
      tunneled packet from the mobile node, binding with the care-of address check is
      done against the source address on same BID but
         different care-of address, it MUST update the outer IPv6 header.  The
      reverse tunnel packet could either be binding and
         respond with a tunneled HoTi message or
      tunneled data traffic to the correspondent node.

   o  The mobile node runs IKEv2 (or IKEv1) Binding Acknowledgement with status set to 0
         [Binding Update accepted].

      *  If the home agent using receiver does not have a binding entry for the care-of address.  The IKE SA is based on BID, it
         registers a new binding for the care-of address
      of BID and responds with a Binding
         Acknowledgement with status set to 0 [Binding Update accepted].

   If all the mobile node.

   The above assumptions may not be valid when multiple care-of
   addresses operations are used by successfully completed, a Binding
   Acknowledgement containing the Binding Identifier mobility options
   MUST be sent to the mobile node.  In  Whenever a Binding Acknowledgement
   is sent, all the following sections, Binding Identifier mobility options stored in the main issues with
   Binding Update MUST be copied to the use of multiple care-of address with IPsec
   are addressed.

9.1.  Use of Binding Acknowledgement except
   the status field.  The Care-of Address address field in the IKEv2 exchange

   For each home address Binding
   Identifier mobility option, however, can be omitted, because the
   mobile node sets up security associations
   with the home agent, can match a corresponding binding update list entry using
   the mobile BID.

   When a correspondent node must pick one care-of address
   and use that as sends a Binding Acknowledgement, the source address for all IKEv2 messages exchanged
   to create and maintain status
   value MUST be always stored in the IPsec security associations associated
   with Status field of the home address.  The resultant IKEv2 security association is
   created based on this care-of address.

   If Binding
   Acknowledgement and the mobile node needs Status field of Binding Identifier mobility
   option set to change zero.  For the care-of address, it just sends home agent, the status value can be
   stored in the Status field of either a Binding Update with Acknowledgement or a
   Binding Identifier mobility option.  If the care-of address it wants status value is specific
   to use, with one of bindings in the bulk registration, the status value MUST be
   stored in the Status field in the corresponding Binding Identifier
   mobility option, and with option.  In this case, [MCOA NOTCOMPLETE] MUST be set to the 'K'
   bit set.  This will force
   Status field of the home Binding Acknowledgement so that the receiver can
   examine the Status field of each Binding Identifier mobility option
   for further operations.

6.4.  Sending Binding Refresh Request

   When a node (home agent to update or correspondent node) sends a Binding
   Refresh Request for a particular binding created with the IKEv2 security
   association to use BID, the new care-of address.  If
   node SHOULD include the 'K' bit is not
   supported on Binding Identifier mobility option in the
   Binding Refresh Request.  If the mobile node or had used bulk
   registration, the home agent, sender SHOULD include all the Binding Identifier
   mobility options.  If the mobile node MUST
   re-establish had not used bulk registration,
   the IKEv2 security association with sender includes the new care-of
   address.  This will also result in new IPsec security associations
   being setup Binding Identifier mobility options only for the home address.

9.2.  Transport Mode IPsec protected messages

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

   For Mobile Prefix Discovery messages, [RFC-3775] requires the home
   agent to verify
   those bindings that the mobile need to be refreshed.

6.5.  Receiving Packets from Mobile Node

   When a node is using receives packets with a Home Address destination option
   from a mobile node, it MUST check that the care-of address that is
   appears 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 address field of the home agent implementation IPv6 header MUST be equal
   to process the
   message as long as the source address is one of the care-of addresses in the binding cache entry for entry.  If no
   binding is found, the mobile node.

9.3.  Tunnel Mode IPsec protected messages packets MUST be silently discarded.  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
   MUST also send and receive tunneled traffic.  The route
   optimization mechanism described in [RFC-3775] mandates the use of
   IPsec protection a Binding Error message as specified in tunnel mode [RFC-3775].
   This verification MUST NOT be done for the HoTi and HoT messages. a Binding Update.

7.  Network Mobility Applicability

   The binding management mechanisms are the same for a mobile node host that
   uses Mobile IPv6 and for a mobile router that is using the home agent may NEMO Basic
   Support protocol [RFC-3963].  Therefore the extensions described in
   this document can also choose be used to protect all reverse
   tunneled payload traffic support a mobile router with IPsec in tunnel mode.  The following
   sections address
   multiple care-of addresses.

8.  DSMIPv6 Applicability

   Dual Stack Mobile IPv6 (DSMIPv6) [ID-DSMIPv6] extends Mobile IPv6 to
   register an IPv4 care-of address support for these two types instead of messages.

9.3.1.  Tunneled HoTi and HoT messages

   The mobile node MAY use the same IPv6 care-of address for all HoTi
   messages sent reverse tunneled through
   when the home agent.  The mobile node may use is attached to an IPv4-only access network.  It
   also allows the same care-of mobile node to acquire an IPv4 home address irrespective of which 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

   The mobile node can use the HoTi message is being sent.  RFC 3775 requires extensions described in the home agent document to verify that
   register multiple care-of addresses, even if some of the mobile node is using care-of
   addresses are IPv4 address.

   Bulk registration MUST NOT be used for the initial binding from an
   IPv4 care-of
   address that address.  This is in because, the Binding Update and
   binding cache entry, when it receives a
   reverse tunneled HoTi message.  If a different address acknowledgement exchange is used as to detect NAT on the
   source address, path
   between the message is silently dropped by mobile node and the home agent.
   This document requires  So the home agent implementation mobile node needs
   to decapsulate check for a NAT between each IPv4 care-of address and forward the HoTi message as long as home
   agent.

   The Binding Update MUST be sent to the source IPv4 home agent address is one of
   the care-of addresses by
   using UDP and IPv4 headers as shown in the binding cache entry for the mobile node.

   When the home agent tunnels a HoT message Figure 9.  It is similar to
   [ID-DSMIPv6] except that the mobile node, the IPv4 care-of address option MUST NOT be
   used in when the outer BID mobility option is used.

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

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

   If a NAT is not relevant to detected, the
   HoT message.  So regular IPsec tunnel encapsulation with mobile node can update the IPv4 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 using bulk registration.  The mobile node can register the correct
   IPv4 care-of address for each flow becomes important.  Support for this
   requires the following two considerations on along with other IPv4 and IPv6 care-of
   addresses.  Figure 10 shows the home agent.

   o  When Binding Update format when the home agent receives mobile
   node sends a reverse tunneled payload message
      protected by IPsec in tunnel mode, it must check that the care-of
      address is Binding Update from one of the care-of addresses in the binding cache
      entry.  According to RFC 4306, the IPsec implementation on the
      home agent does not check the source address on the outer its IPv6
      header.  Therefore the care-of address used in addresses.
   If the reverse
      tunneled traffic can be different mobile node sends a Binding Update from the IPv4 care-of address used as
      the source address in address,
   it MUST follow the IKEv2 exchange.  However, format described in Figure 9.  Note that the Mobile IPv4
   Care-of Address must be registered by non bulk Binding registration,
   whenever it is changed.

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

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

   If the home agent rejects the IPv4 care-of address, it MUST verify that store the source address
      is one
   error code value in the Status field of the care-of addresses registered by BID mobility option.

8.2.  IPv4 HoA Management

   When the mobile node
      before decapsulating and forwarding the payload traffic towards
      the correspondent node.

   o  For tunneled IPsec traffic from the home agent wants to the mobile node,
      The IPsec implementation on the configure an IPv4 home agent may not be aware of
      which care-of address in
   addition to use when performing IPsec tunnel
      encapsulation.  The Mobile IP stack on the IPv6 home agent must specify
      the tunnel end point address, it can request for one using the IPsec tunnel.  This may require tight
      integration between
   IPv4 Home Address option in the IPsec and Mobile IP implementations on Binding Update.  If the home agent.

10.  Security Considerations

   The security considerations for securing agent
   accepts the Binding Update and
   binding acknowledgement messages with Update, the mobile node can now register multiple
   care-of addresses for the IPv4 home address are
   very similar in addition to the security considerations for securing the Binding
   Update and binding acknowledgement.  Please see [RFC-3775] for more
   information. IPv6
   home address.  The Binding Update and binding acknowledgement messages
   with multiple same set of care-of addresses MUST will be protected using IPsec as show
   in Section 9.  Additional security considerations are described
   below.

   With simultaneous binding support, it is possible registered
   for a malicious both IPv6 and IPv4 home addresses.  The mobile node to successfully cannot bind a number
   different set of victims' addresses as
   valid care-of addresses for the mobile node with its to each home agent.
   Once these addresses have been bound, the malicious mobile node can
   perform a re-direction attack by instructing address.

   According to [ID-DSMIPv6], the home agent (e.g.
   setting filtering rules to direct a large file transfer) to tunnel
   packets to the victims' addresses.  Such risk is highlighted in [ID-
   MIP6ANALYSIS].  These attacks are possible because the care-of
   addresses sent by includes the mobile node IPv4 address
   acknowledgement option in the Binding Update messages are
   not verified by home agent, i.e., the home agent does not check Acknowledgement only if the
   mobile node is at had requested for an IPv4 home address in the care-of
   corresponding Binding Update.  The IPv4 address it is claiming to be. acknowledgement
   option MUST be present before any BID option.  The
   security model for Mobile IPv6 assumes that there is a trust
   relationship between status field of
   the mobile node and its home agent.  Any
   malicious attack by IPv4 address acknowledgement option contains only the mobile node is traceable by error code
   corresponding to the IPv4 home agent.
   This acts as a deterrent for the mobile node address management.  The error values
   related to launch such attacks.

   Although such risk exists in Mobile IPv6, the risk level is escalated
   when simultaneous multiple IPv4 care-of address bindings are performed.
   In registration MUST be stored in
   the BID mobility option.

9.  IPsec and IKEv2 interaction

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

   o  There is only have a single one primary care-of address
   binding per home address at a given time.  However, for simultaneous
   multiple care-of address bindings, a mobile node can have more than
   one node.

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

   o  When the home address at a given time.  This
   implies that agent receives a packet from the mobile node using simultaneous binding support can
   effectively bind more than a single victim's address.  Another
   difference is node, the degree of risk involved.  In
      source address is verified against the single care-of address in the
      corresponding binding case, once cache entry.  If the re-direction attack packet is initiated, a
   malicious mobile node would be unable to use its home address for
   communications (such as to receive control packets pertaining to the
   file transfer).  However, in reverse
      tunneled packet from the simultaneous binding support case, a
   malicious mobile node could bind a valid node, the care-of address in addition
   to multiple victims addresses.  This valid care-of check is
      done against the source address on the outer IPv6 header.  The
      reverse tunnel packet could then either be used by the malicious mobile node to set up flow filtering rules
   at its home agent, thereby controlling and/or launching new re-
   direction attacks.

   Thus, in view of such risks, it is advisable for a tunneled HoTi message or
      tunneled data traffic to the correspondent node.

   o  The mobile node runs IKEv2 (or IKEv1) with the home agent to
   employ some form of using
      the care-of address.  The IKE SA is based on the care-of address verification mechanism before
   using
      of the mobile node.

   The above assumptions may not be valid when multiple care-of
   addresses as a valid routing path to a are used by the mobile node.
   Solutions related to this  In the following sections,
   the main issues with the use of multiple care-of address with IPsec
   are described addressed.

9.1.  Use of Care-of Address in [ID-COAVERIFY].

11.  IANA Considerations 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 following Extension Types MUST be assigned by IANA:

   o resultant IKEv2 security association is
   created based on this care-of address.

   If the mobile node needs to change the care-of address, it just sends
   a Binding Update with the care-of address it wants to use, with the
   corresponding Binding Identifier mobility option type: This must be assigned
      from option, and with the same space as mobility option in [RFC-3775].

   o  New Successful Status of Binding Acknowledgement: 'K'
   bit set.  This status code
      must be assigned from will force the same space as binding acknowledgement
      status codes in [RFC-3775].

      *  MCOA NOTCOMPLETE (TBD)

   o  New Unsuccessful Status of Binding Acknowledgement: These status
      codes must 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 be assigned from result in new IPsec security associations
   being setup for the same space as binding
      acknowledgement status codes home address.

9.2.  Transport Mode IPsec protected messages

   For Mobile IPv6 signaling message protected using IPsec in [RFC-3775].

      *  MCOA MALFORMED (TBD)

      *  MCOA BID CONFLICT (TBD)

      *  MCOA PROHIBITED(TBD)

      *  MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

12.  Acknowledgements

   The authors would like 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 thank Masafumi Aramoto, George Tsirtsis,
   Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Susumu
   Koshiba, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Hiroki
   Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada, Keisuke
   Uehara, Masafumi Watari verify that the mobile node is using the care-of address
   that is in alphabetical order, and the Jun Murai
   Laboratory at binding cache entry that corresponds to the KEIO University.

13.  References

13.1.  Normative References

   [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 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 one of the care-of addresses
   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.

   [RFC-2119] Bradner, S., "Key words the binding cache entry for the mobile node.

9.3.  Tunnel Mode IPsec protected messages

   The use of IPsec in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation tunnel mode with
   IKEv2 and multiple care-of address
   introduces a few issues that require changes to how the revised IPsec Architecture", RFC 4877, April 2007.

13.2.  Informative References

   [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
   K. Kuladinithi, "Motivations and Scenarios for Using Multiple
   Interfaces mobile node
   and Global Addresses",
   draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
   [RFC-4980] Ng, C., Paik, Ernst, the home agent send and C. Bagnulo, "Analysis of
   Multihoming receive tunneled traffic.  The route
   optimization mechanism described in Network Mobility Support", RFC 4980, October 2007.

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

   [RFC-3753] Manner, J. tunnel mode for the HoTi and M. Kojo, "Mobility Related Terminology",
   RFC 3753, June 2004.

   [RFC-4885] Ernst, T. HoT messages.  The
   mobile node and H. Lach, "Network Mobility Support
   Terminology", RFC 4885, July 2007.

   [ID-DSMIPv6] Soliman, H., "Mobile IPv6 the home agent may also choose to protect all reverse
   tunneled payload traffic with IPsec in tunnel mode.  The following
   sections address multiple care-of address support for dual stack Hosts these two types
   of messages.

9.3.1.  Tunneled HoTi and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work 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
   progress), November 2007.

   [ID-COAVERIFY] Lim, B., C. NG 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 K. Aso, "Verification forward the HoTi message as long as the source address is one of Care-of
   Addresses in Multiple Bindings Registration",
   draft-lim-mext-multiple-coa-verify-01 (work
   the care-of addresses in progress), February
   2008.

Appendix A.  Example Configurations

   In this section, we describe typical scenarios when the binding cache entry for the mobile node.

   When the home agent tunnels a HoT message to the mobile node has
   multiple network interfaces 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 acquires receives multiple Care-of Addresses
   bound traffic flows protected
   by IPsec to a 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 address.  The agent.

   o  When the home agent receives a reverse tunneled payload message
      protected by IPsec in tunnel mode, it must check that the care-of
      address is one of the 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 in the binding cache
      entry.  According to each care-of address.

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

     Binding Cache Database: RFC 4306, the IPsec implementation on the
      home agent's binding (Proxy neighbor advertisement is active)
              binding [a:b:c:d::EUI agent does not check the source address on the outer IPv6
      header.  Therefore the care-of address1  BID1]
              binding [a:b:c:d::EUI address used in the reverse
      tunneled traffic can be different from the care-of address2  BID2]
              binding [a:b:c:d::EUI address used as
      the source address in the IKEv2 exchange.  However, the Mobile
      IPv6 stack on the home agent MUST verify that the source address
      is one of the care-of address3  BID3] addresses registered by the mobile node
      before decapsulating and forwarding the payload traffic towards
      the 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 7: Multiple Interfaces Attached node.

   o  For tunneled IPsec traffic from the home agent to a Foreign Link

   Figure 7 depicts the scenario where all interfaces mobile node,
      The IPsec implementation on the home agent may not be aware of the mobile node
   are attached
      which care-of address to foreign links.  After binding registrations, use when performing IPsec tunnel
      encapsulation.  The Mobile IP stack on the home agent (HA) and must specify
      the correspondent node (CN) have tunnel end point for the binding entries
   listed in their binding cache database. IPsec tunnel.  This may require tight
      integration between the IPsec and Mobile IP implementations on the
      home agent.

10.  Security Considerations

   The mobile node can utilize
   all security considerations for securing the interfaces.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+          +----+
            +------+ Internet |----------+ HA |
            |      +--------+-+          +--+-+
        CoA2|               |               |   Home Link
         +--+--+            |         --+---+------
         |  MN +========+   |           |
         +--+--+        |   |           |
        CoA3|           +---|-----------+
            +---------------+ Binding Cache Database:
        home agent's binding
              none
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address2  BID2] Update and
   binding [a:b:c:d::EUI acknowledgement messages with multiple care-of address3  BID3]

    Figure 8: One of Interface Attached address are
   very similar to Home Link and Returning Home

   Figure 8 depicts the scenario where MN returns home with one of its
   interfaces.  After the successful de-registration of security considerations for securing the Binding
   Update and binding to
   HA, HA acknowledgement.  Please see [RFC-3775] for more
   information.  The Binding Update and CN have the binding entries listed acknowledgement messages
   with multiple care-of addresses MUST be protected using IPsec as show
   in their Section 9.  Additional security considerations are described
   below.

   With simultaneous binding cache
   database of Figure 8.  After de-registration, the ND state of the
   home address support, it is managed by the MN.  MN can communicate with the HA
   through only the interface attached possible for a malicious
   mobile node to successfully bind a number of victims' addresses as
   valid care-of addresses for the mobile node with its home link.  On the other
   hand, agent.
   Once these addresses have been bound, the malicious mobile node can communicate with CN from the other
   interfaces attached to foreign links (i.e. route optimization).  Even
   if MN is attached to
   perform a re-direction attack by instructing the home link, it can still send Binding Updates
   for other active care-of addresses (CoA2 and CoA3) agent (e.g.
   setting filtering rules to CNs.  If CN has
   bindings, packets are routed direct a large file transfer) to each Care-of Addresses directly.  Any
   packet arrived at HA are routed tunnel
   packets to the interface attached to victims' addresses.  Such risk is highlighted in [ID-
   MIP6ANALYSIS].  These attacks are possible because the home
   link.

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

     Binding Cache Database:
        home agent's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI  care-of address2  BID2]
        correspondent node's binding
              binding [a:b:c:d::EUI  care-of address1  BID1]
              binding [a:b:c:d::EUI care-of address2  BID2]

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

   Figure 9 depicts the scenario where MN disables
   addresses sent by the interface
   attached to mobile node in the Binding Update messages are
   not verified by home link and communicates with the interfaces
   attached to foreign links.  HA continues managing the ND state of agent, i.e., the home address by Proxy neighbor advertisement.  The HA and agent does not check if
   the CN have mobile node is at the binding entries listed in their binding cache database.  All
   packets routed care-of address it is claiming to be.  The
   security model for Mobile IPv6 assumes that there is a trust
   relationship between the mobile node and its home link are intercepted agent.  Any
   malicious attack by the HA and
   tunneled to mobile node is traceable by the other interfaces attached to home agent.
   This acts as a deterrent for the foreign link
   according mobile node to launch such attacks.

   Although such risk exists in Mobile IPv6, the risk level is escalated
   when simultaneous multiple care-of address bindings are performed.
   In Mobile IPv6, a mobile node can only have a single care-of address
   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: per home agent's binding
              binding [a:b:c:d::EUI address at a given time.  However, for simultaneous
   multiple care-of address1  BID1]
              binding [a:b:c:d::EUI address bindings, a mobile node can have more than
   one care-of address2  BID2]
        correspondent node's address binding per home address at a given time.  This
   implies that a mobile node using simultaneous binding [a:b:c:d::EUI support can
   effectively bind more than a single victim's address.  Another
   difference is the degree of risk involved.  In the single care-of address1  BID1]
   address binding [a:b:c:d::EUI  care-of address2  BID2] case, once the re-direction attack is initiated, a
   malicious mobile node would be unable to use its home address for
   communications (such as to receive control packets pertaining to the
   file transfer).  However, in the simultaneous binding [a:b:c:d::EUI support case, a
   malicious mobile node could bind a valid care-of address3  BID3]

   Figure 10: Utilize Interfaces Attached address in addition
   to both Home and Foreign Links

   Figure 10 depicts multiple victims addresses.  This valid care-of address could then
   be used by the scenario where interfaces malicious mobile node to set up flow filtering rules
   at its home agent, thereby controlling and/or launching new re-
   direction attacks.

   Thus, in view of MN are attached such risks, it is advisable for a home agent to
   both
   employ some form of care-of address verification mechanism before
   using the home and foreign links.  There care-of addresses as a valid routing path to a mobile node.
   Solutions related to this are two possible topologies
   whether described in [ID-COAVERIFY].

11.  IANA Considerations

   The following Extension Types MUST be assigned by IANA:

   o  Binding Identifier mobility option type: This must be assigned
      from the HA is single router at same space as mobility option in [RFC-3775].

   o  New Successful Status of Binding Acknowledgement: This status code
      must be assigned from the home link or not.  The
   operation same space as binding acknowledgement
      status codes in [RFC-3775].

      *  MCOA NOTCOMPLETE (TBD)

      *  MCOA RETURNHOME WO/NDP (TBD)

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

      *  MCOA MALFORMED (TBD)

      *  MCOA BID CONFLICT (TBD)

      *  MCOA PROHIBITED(TBD)

      *  MCOA BULK REGISTRATION NOT SUPPORTED (TBD)

12.  Acknowledgements

   The HA authors would like to special thank George Tsirtsis for thorough
   review and CN have
   the binding entries listed in Figure 10 in their binding cache
   database regardless of topologies. suggestions.  The HA authors would also knows that the MN has
   attached like to the home link.  All the traffic from the Internet are
   intercepted by the HA thank
   Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin
   Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas
   Montavont for their discussions and routed to either the interface attached to
   the home link or the interfaces attached to the foreign links.  How inputs.  Thanks to make the decision is out of scope in Susumu
   Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
   Uehara, Masafumi Watari and Jun Murai for earlier work on this document.

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

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

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

   The first case is required that the HA is the single exit router
   subject.

13.  References

13.1.  Normative References

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

   [RFC-2461] Narten, T., Nordmark, E., and is capable of intercepting packets without relying
   on proxy ND.  The MN can manage the ND W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [RFC-2464] Crawford, M., "Transmission of the home address on the
   home link.  In the second case, the HA is not only router at the home
   link IPv6 Packets over Ethernet
   Networks", RFC 2464, 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.

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

13.2.  Informative References

   [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
   K. Kuladinithi, "Motivations and Scenarios for 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
   address at the home link, HA cannot resolve the layer-2 address 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
   the MN at the home link.  The HA MUST learn
   Multihoming in Network Mobility Support", RFC 4980, October 2007.

   [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and record the layer-2
   address (MAC address)
   K. Kuladinithi, "Analysis of the MN's interface attached to the home link
   to forward packets.  The packets forwarding is achieved without ND
   cache.  The MN is also required to learn Multihoming in Mobile IPv6",
   draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
   2007.

   [RFC-3753] Manner, J. and record the layer-2
   address M. Kojo, "Mobility Related Terminology",
   RFC 3753, June 2004.

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

   [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts
   and Routers (DSMIPv6)", draft-ietf-mext-v4traversal-01 (work in
   progress), February 2008.

   [ID-COAVERIFY] Lim, B., C. NG and K. Aso, "Verification of the HA's interface to send packets from the home link. Care-of
   Addresses in Multiple Bindings Registration",
   draft-lim-mext-multiple-coa-verify-01 (work in progress), February
   2008.

   [RFC-4068bis] R. Koodli, "Mobile IPv6 Fast Handovers",
   draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt (work in progress), April
   2008.

Authors' Addresses

   Ryuji Wakikawa (Editor)
   Faculty of Environment and Information Studies,
   Toyota ITC / Keio University
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-466-49-1100 +81-3-5561-8276
   Fax:   +81-466-49-1395   +81-3-5561-8292
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/ ryuji@jp.toyota-itc.com

   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,
   Wichorus
   3590 North First St
   San Jose, CA  95054  95134
   USA

   Email: vijay.devarapalli@azairenet.com vijay@wichorus.com

Full Copyright Statement

   Copyright (C) The IETF Trust (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).