MIP6 Working Group                                        Ryuji Wakikawa
INTERNET DRAFT                                            Keisuke Uehara
20 Sep 2003                                                Thierry Ernst
                                            Keio University/WIDE project
                                                          Kenichi Nagami
                                                           INTEC Netcore

                 Multiple Care-of Addresses Registration
               draft-wakikawa-mobileip-multiplecoa-02.txt


   Status of This Memo

   This document is a submission to the MIP6 Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the mip6@ietf.org (mobile-ip@sunroof.eng.sun.com) mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.


   Abstract

   According to the current Mobile IPv6 specification, a mobile node
   may have several care-of addresses, but only one, termed the primary
   care-of address, can be registered with its home agent and the
   correspondent nodes.  However, for matters of cost, bandwidth, delay,
   etc, it is useful for the mobile node to get Internet access through
   multiple access media (i.e.  interfaces) simultaneously, in which
   case multiple active IPv6 care-of addresses would be assigned to
   the mobile node.  We thus propose Mobile IPv6 extensions designed
   to register multiple care-of addresses bound to a single home
   address instead of the sole primary care-of address.  For doing so,
   a new identification number must be carried in each binding for the


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 1]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   receiver to distinguish between the bindings corresponding to the
   same home address.  Those extensions are targeted to Network Mobility
   (NEMO) as well as to Mobile IPv6.

                                  Contents


Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       4

 2. Terminology                                                        6

 3. Protocol Overview                                                  8

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

 5. Mobile Node Operation                                             13
     5.1. Management of care-of addresses . . . . . . . . . . . . .   13
     5.2. Sending Binding Update  . . . . . . . . . . . . . . . . .   14
     5.3. De-registration . . . . . . . . . . . . . . . . . . . . .   15
           5.3.1. De-registration to home agent . . . . . . . . . .   15
           5.3.2. De-registration to correspondent nodes  . . . . .   16
     5.4. Using Alternate Care-of Address . . . . . . . . . . . . .   16
     5.5. Receiving Binding Acknowledgment  . . . . . . . . . . . .   17
     5.6. Receiving Binding Refresh Request . . . . . . . . . . . .   17
     5.7. Receiving Binding Error . . . . . . . . . . . . . . . . .   18

 6. Home Agent and Correspondent Node Operation                       18
     6.1. Searching Binding Cache with Binding Unique Identification
         Number . . . . . . . . . . . . . . . . . . . . . . . . . .   18
     6.2. Receiving Binding Update  . . . . . . . . . . . . . . . .   19
     6.3. Sending Binding Acknowledgment  . . . . . . . . . . . . .   20
     6.4. Sending Binding Refresh Request . . . . . . . . . . . . .   20
     6.5. Sending Binding Error . . . . . . . . . . . . . . . . . .   21

 7. Network Mobility Applicability                                    21

Appendices                                                            22

 A. Example Configurations                                            22


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 2]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


Example Configurations                                                22

Acknowledgments                                                       25

References                                                            25

Authors' Addresses                                                    27


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 3]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   1. Introduction

   Permanent Internet connectivity is required by some applications
   while a mobile node moves across several access networks (i.e.
   ISPs, hotspots, etc).  For example, it is desirable to maintain
   the Internet connectivity while an automobile running on a freeway
   receives voice or video streaming data from different access
   networks.

   Unfortunately, there is no network interfaces assuring global scale
   connectivity.  Therefore, a mobile node should use various type of
   network interfaces to obtain wide area network connectivity [7].  In
   addition, users should select the most appropriate network interface
   depending on a visiting network environment, since wireless networks
   is mutable and less reliable than wired networks and each network
   interface has different cost, performance, bandwidth, access range,
   and reliability.  Users should also select the most appropriate
   interface per communication.  For example, TCP traffic should be
   transmitted over the wireless interface, whereas UDP traffic should
   be transmitted over wired the interface to avoid disturbing TCP
   connections.

   Associating multiple care-of addresses to a single home address
   would allow durable Internet connectivity [8] [1] [9].  For example,
   when a mobile node loses its Internet connectivity at one of its
   interface, the second interface can be used as a backup interface
   therefrom maintaining Internet connectivity.  In addition, the
   mobile node can send each communication flow to a distinct network
   interface.  This provides efficient network bandwidth consumption.  A
   user can select the most suitable network interface per application.
   Correspondent nodes can also re-select a binding of the mobile node
   to recover communication when one of mobile node's bindings becomes
   invalid.  To enable a binding selection policy, a mobile node can
   use the particular binding for specified communication type.  If a
   mobile node does not have enough bandwidth for communications, it
   can utilize both bindings to gain network bandwidth.  Furthermore,
   a mobile node may bicast packets of a particular flow through all
   available network interfaces.

   IPv6 [2] conceptually allows a node to have several addresses on a
   given interface.  Consequently, Mobile IPv6 [6] has mechanisms to
   manage multiple ``home addresses'' based on home agent's managed
   prefixes such as mobile prefix solicitation and mobile prefix
   advertisement.  However, assigning a single home address to a given
   network interface is more advantageous than assigning multiple
   home addresses because applications do not need to be aware of the
   multiplicity of home addresses.  Of course, applications should be
   aware of the active home address to be used for communicating.  At
   the TCP layer, TCP holds the home address as a source address of the


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 4]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   communication for connection managements.  Thus, applications must
   reboot to reset the connection information when the the mobile node
   changes its active network interface (i.e.  change the home address).

   However, according to section 11.5.3 of  the Mobile IPv6
   specification [6], a mobile node is not allowed to register multiple
   care-of addresses bound to a single home address.  If a mobile node
   sends Binding Updates for each care-of address, correspondent nodes
   would always overwrite the careof address recorded in the binding
   cache with the one contained in the latest received binding update.
   It is thus impossible for a mobile node to register multiple care-of
   addresses in the correspondent node's binding cache.

   In this document, we thus propose a new identification number called
   Binding Unique Identification number (BID) for each binding cache
   entry to accommodate multiple bindings registration.  We also propose
   extension of binding cache management to store the BID and a new
   sub-option for binding update to carry the BID. The BID is assigned
   to either the interfaces or care-of addresses bound to a single
   home address of a mobile node.  The mobile node notifies the BID
   to both its home agent and correspondent nodes by means of a BU.
   Correspondent nodes and the home agent record the BID into their
   binding cache.  The home address thus identifies a mobile node itself
   whereas the BID identifies each binding registered by a mobile node.
   By using the BID, multiple bindings can then be distinguished.

   A user of a mobile node may be able to bind some policies to a BID.
   The policy is used to divide flows to multiple network interfaces
   by flow type, port number, or destination address, etc.  How to
   distribute or configure policies is not within the scope of this
   draft.

   The extensions specified in this draft can also be applied to Network
   Mobility (NEMO) basic support [3].  Our extensions can indeed be
   applied to either a mobile host (Mobile IPv6) or a mobile router
   (MR, see  [5]).  Network Mobility Support must allow multihoming so
   as to provide robustness, better performance, etc described in [4].
   Multihoming include in particular the ability to switch from one
   egress interface to another.

   Thierry:  what you wrote in section above is almost exactly the same
   content as section 7 so section 7 is useless


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 5]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   2. Terminology

   Most terms used in this draft are defined in [6].

      Binding Unique Identification number (BID)

         The identification number is used to distinguish multiple
         bindings registered by mobile node.  Assignment of distinct BID
         allows a mobile node to register multiple binding cache entries
         for a given home address.  BID is generated not to duplicate
         each other.  The zero value and negative value MUST NOT be used
         as a value.  After generating BID, BID is stored in the Binding
         Update List and is sent by a mobile node as a sub-option of a
         Binding Update.

         BID is conceptually used to distinguish multiple bindings for
         single home address.  Therefore, a mobile node can assign
         BID to either care-of address or interface depending on
         implementations 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

      Primary care-of address

         In [6], the primary care-of address is defined as ``the care-of
         address registered with the mobile node's home agent is called
         its ``primary'' care-of address''.  In this present draft, the
         definition is refined as follows:  The care-of address which is
         primary associated with a home address.

         A mobile node MUST have a primary care-of address all the time.
         Once the primary care-of address becomes invalid, the mobile
         node MUST reselect a primary careof-address from the multiple
         care-of addresses that a mobile node may have at any given
         time.

      Primary Interface

         The interface on which the primary care-of address is assigned.
         Once the primary interface becomes invalid due to movements,
         the mobile node MUST re-select primary interface from set of
         interfaces installed in mobile node.

      Binding Unique Identifier sub-option

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


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 6]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


      Multiple Care-of Addresses Flag (M flag)

         This flag indicates that a Binding Unique Identifier sub-option
         is included in the Binding Update mobility option field.


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 7]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   3. Protocol Overview

   We propose a new identification number to distinguish multiple
   bindings pertaining to the same home address.  The following
   paragraphs described the procedures for the mobile node to register
   multiple bindings.

   Once a mobile node gets several IPv6 global addresses on distinct
   interfaces, it MUST select a primary care-of address from the active
   addresses as specified in Section 11.5.3  [6].  After the selection,
   the interface which has the primary care-of address becomes the
   primary interface for the mobile node.

   After selecting the primary care-of address, the mobile node MUST
   register it with its home agent (home registration).  If the mobile
   node wants to register multiple bindings to its home agent, it MUST
   generate a BID for the primary care-of address and record it into
   the binding update list entry.  The mobile node then registers its
   primary care-of address by sending a Binding Update containing a
   Binding Unique Identifier sub-option.  The M flag MUST be set in
   the Flag field of the Binding Update and the BID MUST be put in the
   Binding Unique Identifier sub-option.  After receiving the Binding
   Update, the home agent verifies the request and records the binding
   in its binding cache.  If the newly defined sub-option is present in
   the Binding Update, the home agent MUST copy the BID from the BU to
   the corresponding field in the binding entry.

   After this home registration, the mobile node can register the rest
   of care-of addresses to its Home Agent.  Even if there is already
   an entry for the mobile node, the home agent MUST registers a new
   binding entry with the BID stored in the Binding Unique Identifier
   sub-option.  The registration process is the same as for the
   registration of the primary care-of address.  The mobile node MUST
   register multiple care-of addresses respectively.

   There is no optimization such as registering multiple care-of
   addresses by using a single Binding Update, because the current
   Mobile IPv6 specification does not allow to send multiple bindings by
   single Binding Update.

   If the mobile node would register its binding to a correspondent
   node, it MUST starts return routability operations before sending a
   Binding Update.  The mobile node MUST sends CoTI for each care-of
   addresses and MUST receive CoT for each care-of addresses.  The
   mobile node also generates BID for each care-of addresses to register
   them as individual bindings .  The registration step is same as
   the home registration except for calculating authenticator with
   Binding Unique Identifier sub-option as well as the other sub-options
   specified in [6].


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 8]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   BID is also used as a search key of binding cache database as well as
   a home address.  When the home agent checks binding cache database
   for the mobile node, it searches a correspondent binding entry with
   the home address and BID of the desired binding.  The desired binding
   can be selected with policy and filter information.  The capability
   of searching the desired binding enables load-sharing and QoS with
   flow separation.  But this selection and flow separation are out of
   scope in this draft.  If there is no desired binding, it search the
   binding cache database with the home address as well as Mobile IPv6.
   The first matched binding entry may be found, but which binding entry
   is returned for the normal search depends on implementations.

   If a node has multiple bindings and its packets meant for the
   mobile node are not delivered correctly, the node can change the
   binding entry for the mobile node so as to recover the connection
   immediately.  The node can detect a binding invalidation by packets
   loss or ICMP error messages such as ICMP_UNREACHABLE. This provides
   redundancy for Mobile IPv6.

   When one of care-of addresses is changed, the mobile node sends a
   Binding Update with the new care-of address and the correspondent
   BID. The receiver of the Binding Update updates the particular
   binding entry that its BID is same as the BID in the received Binding
   Unique Identifier sub-option.  The mobile node can manage each
   binding independently owing to BID.

   Once the mobile node decides to register only one binding, it just
   sends a Binding Update without M flag and a Binding Unique Identifier
   sub-option (i.e.  normal Binding Update).  The receiver of the
   Binding Update registers only single binding for the mobile node.
   If the receiver has multiple bindings, one bindings is registered
   without BID and the rest of bindings are deleted.

   When the mobile node returns home, there are two situations.  It is
   because the home agent defends the mobile node's home address by
   using proxy neighbor advertisement.  It is impossible to utilize
   all the interfaces when one interface is attached to home and the
   others are attached to foreign link.  If proxy Neighbor Advertisement
   for the home address is stopped, packets are always routed to the
   interface attached to the home link.  If proxy is not stopped,
   packets are never routed to the interface attached to the home link.

   The first situation is when the primary interface is attached to the
   home link.  In this case, the mobile node MUST de-register all the
   bindings by sending a Binding Update which lifetime set to zero.  The
   mobile node MAY NOT put any Binding Unique Identifier sub-options
   in this packet.  Then, the receiver deletes all the bindings from
   its binding cache database.  On the other hand, if the mobile node
   wants to delete binding entries respectively, it sends multiple


R. Wakikawa et.al.              Expires 20 Mar 2003             [Page 9]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   deregistration Binding Updates for all BID (that is all registered
   care-of addresses).  In those Binding Updates, the mobile node MUST
   store a Binding Unique Identifier sub-option.  Only when the care-of
   address is the primary one and the destination is the home agent,
   the mobile node also set 'P' flag in the Binding Unique Identifier
   sub-option to indicates stop proxying for the mobile node to the home
   agent.  P flag is valid only when the destination of a Binding Update
   is a home agent.

   The second situation is when non primary interface is attached to
   the home link.  The primary care-of address takes precedence over
   the rest of addresses.  The mobile node stops using the interface
   attached to the home link and keeps using the rest of interfaces
   attached to foreign links.  In this case, the mobile node sends
   deregistration Binding Update with the Binding Unique Identifier
   sub-option.  The mobile node stores the BID of the binding and MUST
   NOT set P flag in the sub-option regardless of home agent or not.
   Therefore, the receiver of the deregistration Binding Update deletes
   only the binding entry from the binding cache database.  The home
   agent does not stop proxying neighbor advertisement.


   4. Mobile IPv6 Extensions

   Mobile IPv6 should be able to manage multiple bindings bound to a
   same home address.  The changes are described in this section.


   4.1. Binding Cache Structure and Management

   This document requires to have additional items for the binding cache
   structure, which are

    -  BID
       The BID of the binding cache entry.  The BID is notified by BU
       sub-option by mobile node.  If mobile node does not use BID, then
       the value of BID MUST be always zero.

   If a node gets a BU with a Binding Unique Identifier defined
   at 4.3.1, it searches Binding Cache entries with the set of the home
   address and the BID. If both does match with the registered binding,
   the node MUST update the care-of address and the BID into the matched
   binding.  Otherwise, the node MUST register a new binding for the
   care-of address and the BID, even if there are already the other
   binding for the mobile node's home address.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 10]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   4.2. Binding Update Structure and Management

   This document requires to have additional items for binding update
   structure, which are


    -  BID
       The BID MUST be generated whenever mobile node decides to
       register multiple bindings for its home address.

    -  Primary flag
       If the care-of address is primary one, this flag MUST be set.

   If a mobile node has multiple care-of addresses at a time, it SHOULD
   assign a BID to each care-of address.  BID should be recorded in
   a binding update list.  A mobile node MAY update the value of BID
   periodically not to be discovered by a third person.

   The information of the primary care of address is kept at the Primary
   Flag field and is known only by a mobile node.  A mobile node does
   not need to send the preference information (primary or not) to
   correspondent nodes and a home agent except for the case of mobile
   node's returning home.  When a mobile node returns home, it MUST
   tell whether primary or not because the operation of proxy neighbor
   advertisement is different between primary and non primary care-of
   address.


   4.3. Messages Format Changes

   4.3.1. Binding Unique Identifier sub-option

   The Binding Unique Identifier sub-option is included in Binding
   Update, Binding Acknowledgment, Binding Refresh Request, Binding
   Error if needed.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |   Type = TBD  |   Length = 2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Binding Unique ID (BID)   | P|      Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+

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


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 11]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


      Length
             The value MUST be always 2.

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

      Flag


                Stop Proxy Neighbor Advertisement (P) Flag

                   When this flag is set, the home agent MUST stop
                   proxy neighbor advertisement for a mobile node.
                   This flag is checked only when a Binding Update
                   is for de-registration and the destination of a
                   Binding Update is mobile node's home agent (i.e.
                   home de-registration).  Otherwise, this flag MUST be
                   ignored.

      Reserved
             15 bit Reserved field.  Reserved field must be set with all
             0.


   4.3.2. Binding Update

   If a mobile node wants to register several care-of addresses which
   would be bound to a home address, mobile node MUST set 'M' flag and
   include a Binding Unique Identifier sub-option.

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |          Sequence #           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|L|K|R|M|    Reserved       |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Flag (R)
           This flag is proposed by the NEMO working group [3].


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 12]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


      Multiple Care-of Addresses Flag (M)
           This flag is used for multiple care-of addresses
           registration.

      Reserved
           Reserved field is reduced to 11 bits.


   4.3.3. Binding Acknowledgment

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

   A receiver who gets a Binding Update with 'M' flag MUST reply a
   Binding Acknowledgment if it has 'A' flag or it is home registration.
   The receiver MUST also reply a Binding Acknowledgment with
   correspondent error number if it finds an error during processing the
   Binding Update and its sub-option described in section 4.3.2.

   If a Binding Update has 'M' flag and a Binding Unique Identifier
   sub-option is present, a receiver node MUST reply a Binding
   Acknowledgment containing the same Binding Unique Identifier
   sub-option.  The mobile node can process the Binding Acknowledgment
   for the particular care-of address identified by BID set in the
   Binding Unique Identifier sub-option.

   This document defines a new number for 'M' flag handling.

   140 Conflicting a normal binding without BID and a binding with BID
       in binding cache.  The number is TBD.


   5. Mobile Node Operation

   5.1. Management of care-of addresses

   There are two cases when a mobile node has several care-of addresses.

    -  A mobile node uses several physical network interfaces to acquire
       a care-of address.

    -  A mobile node uses single physical network interface, but it
       acquires several addresses from the attached network.  Since IPv6
       allows to have several addresses on single network interface,
       it is possible to get several global address with a network
       interface at the attached network.

   Although the difference between above two cases is a number of
   physical network interfaces, it does not matter in this draft.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 13]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   Identification number is used to distinguish multiple bindings so
   that mobile node assigns an identification number for each care-of
   addresses.  The decision how to assign an identification number is up
   to implementations.

   A mobile node assigns BID to each care-of address when it wants to
   simultaneously register with its home address.  The value should be
   generated from 1 to 65535.  Zero and negative value can not be take
   as BID. If a mobile node has only one care-of address, assignment of
   BID is not needed until it has multiple care-of addresses to register
   as a binding.

   When a mobile node moves to a new foreign link by one of its
   interfaces, the mobile node just updates the binding for the new
   care-of address.  The mobile node sends a Binding Update with a
   Binding Unique Identifier sub-option storing BID of the binding.

   When a mobile node moves to a home link by its primary interface, it
   MUST start de-registration processing to its home agent as well as
   Mobile IPv6.  The home agent deletes all bindings for the mobile node
   and stops intercepting packets meant for the mobile node.  Although
   the mobile node MUST deletes the binding from correspondent nodes
   as well, the node still can keep a binding of non-primary interface
   active at correspondent nodes.  In such case, the mobile node still
   receives packets at a non primary interface attached to a foreign
   link by using route optimization.  The mobile node also receives
   packets at the primary interface attached to the home link when
   correspondent nodes does not use route optimization.

   On the other hand, when a mobile node returns to the home link by a
   non-primary interface, it MUST delete only the particular binding
   from its home agent and correspondent nodes.  The home agent does not
   delete all bindings and does not stop proxy neighbor advertisement
   for the mobile node.  Therefore, the mobile node no longer receives
   packets at the non primary interface attached to the home link.
   All packets are routed to other interfaces attached to a foreign
   link.  If the mobile node eager to receive packets at the non primary
   interface at the home link, it MUST re-select the interface as
   primary.


   5.2. Sending Binding Update

   When a mobile node sends a Binding Update to its home agent (i.e.
   home registration) and the BU is aimed to de-register the binding,
   the mobile node MUST check whether the care-of address contained in
   the BU is primary or not.  If the care-of address is primary one, it
   MUST set P flag in the Binding Unique Identifier sub-option.  More
   description about P flag can be found in Section 5.3.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 14]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   When a mobile node sends a BU, it MUST decide whether it registers
   multiple care-of addresses or not.  However, this decision is out-of
   scope in this document.  If a mobile node decides not to register
   multiple care-of addresses, it completely follows general Mobile
   IPv6 [6].

   On the other hand, if a mobile node needs to register multiple
   care-of addresses, the mobile node MUST use BID for all care-of
   addresses all the time.  The mobile node sets M flag in a Binding
   Update and puts a Binding Unique Identifier sub-option into the
   Option field of the Binding Update.  BID is copied from a binding
   update list to the Binding Unique Identifier sub-option.  If the
   mobile node registers bindings to a correspondent node, it MUST
   sends multiple CoTI for multiple care-of addresses.  After getting
   CoTs, it sends Binding Updates with M flag and a Binding Unique
   Identifier sub-option for all care-of addresses one by one.  In any
   case, the mobile node MUST set A flag in Binding Updates and MUST
   wait a Binding Acknowledgment to confirm successfully registration as
   described in section 5.5.


   5.3. De-registration

   When a mobile node decides to delete all bindings for its home
   address, it sends a normal de-registration Binding Update (i.e.
   exclusion of a Binding Unique Identifier sub-option).  See
   Section 6.2 for details.

   If a mobile node wants to delete particular binding from its home
   agent and correspondent nodes, it follows below operations.


   5.3.1. De-registration to home agent

   When a mobile node is attached to its home link by one of its
   network interfaces, it MUST de-register an appropriate binding.  If a
   binding of a primary care-of address becomes invalid in terms of the
   mobile node's returning home, it MUST set P flag in a Binding Unique
   Identifier sub-option.  Otherwise, P flag MUST NOT be set.  If P flag
   is set, a home agent stop proxy neighbor advertisement for the mobile
   node.

   When the primary interface is attached to a home link, all
   packets are routed to the primary interface because proxy neighbor
   advertisement is disabled at the home agent.

   If a non primary interface is attached to the home link, the home
   agent keeps intercepting packets meant for the mobile node by proxy
   neighbor advertisement.  Therefore, any packets can not be routed


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 15]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   to the non-primary interfaces.  In NEMO case, a mobile router MUST
   NOT use P flag for the configuration of a virtual home link in terms
   of extended home address, because its home agent does not use proxy
   neighbor advertisement to intercept packets destined to the mobile
   router.


   5.3.2. De-registration to correspondent nodes

   When a mobile node needs to de-register one of care-of addresses, it
   sends a Binding Update with a Binding Unique Identifier sub-option.
   The Binding Update MUST have Lifetime field set to zero.  The Binding
   Unique Identifier sub-option MUST have BID of the target binding.
   Then, the mobile node can de-register one binding from multiple
   registering bindings.  If a receiver receives a Binding Update
   without BID, a receiver can not determine which binding should be
   deleted for this de-registration.  In such case, the receiver deletes
   all of bindings for the mobile node.


   5.4. Using Alternate Care-of Address

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

    -  One of care-of address becomes invalid due to the link of an
       interface is no longer available and MUST be deleted by sending
       Binding Update.  In such case, a mobile node can not sends a
       Binding Update from the care-of address because of interface's
       link is lost.  A mobile node needs to de-register remote binding
       of the care-of address from one of active care-of addresses.

    -  A mobile node has multiple interfaces, but it wants to sends
       Binding Updates for all care-of addresses from a specific
       interface which has wider bandwidth depending on interface's
       characteristics.  A mobile node does not want to send a lot of
       control messages through an interface which bandwidth is narrow.

   In these cases, a mobile node sends a Binding Update with both
   Alternate Care-of Address sub-option and Binding Unique Identifier
   sub-option.  Processing of Alternate Care-of Address sub-option is
   described in Mobile IPv6 specification.  If there is an Alternate
   Care-of Address sub-option, the BID in a Binding Unique Identifier
   sub-option is assigned for the care-of address in the Alternate
   Care-of Address sub-option.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 16]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   5.5. Receiving Binding Acknowledgment

   The verification of a Binding Acknowledgment is same as Mobile
   IPv6 (section 11.7.3 of [6]).  The operation of sending a Binding
   Acknowledgment is described in 6.3.

   If a mobile node sends a Binding Update with a Binding Unique
   Identifier sub-option, a Binding Acknowledgment MUST have a
   Binding Unique Identifier sub-option in Mobility options field.  If
   there is no such sub-option, the originator node of this Binding
   Acknowledgment might not recognize the Binding Unique Identifier
   sub-option.  The mobile node SHOULD stop registering multiple care-of
   addresses by using a Binding Unique Identifier sub-option.

   If a Binding Unique Identifier sub-option is present, the mobile node
   checks Status field of the Binding Acknowledgment.  If the status
   code indicates successful registration (1), the originator registers
   a binding information and BID for the mobile node successfully.

   If the status code is not zero regardless of Binding Unique
   Identifier sub-option availability in BA, the mobile node proceeds an
   appropriate operations according to the status code.

   If the status code is 140, the mobile node has already registered a
   binding without BID before sending a Binding Update with a Binding
   Unique Identifier sub-option.  In such case, a mobile node SHOULD
   stop sending Binding Updates without BID.


   5.6. Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is same as Mobile IPv6
   (section 11.7.4 of [6]).  The operation of sending a Binding Refresh
   Request is described in the section 6.4.

   If a mobile node receives a Binding Refresh Request with a Binding
   Unique Identifier sub-option, this Binding Refresh Request requests
   a binding indicated by BID. The mobile node SHOULD update only the
   respective binding.  The mobile node MUST put a Binding Unique
   Identifier sub-option into a Binding Update.

   If no Binding Unique Identifier sub-option presents in a Binding
   Refresh Request, a mobile node sends a Binding Update according to
   its binding update list for the requesting node.  On the other hand,
   if the mobile node does not have any binding update lists for the
   requesting node, the mobile node needs to register either single
   binding or multiple bindings depending on its binding management
   policy.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 17]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   5.7. Receiving Binding Error

   When a mobile node receives a Binding Error with a Binding Unique
   Identifier sub-option, the message is for a binding indicated by BID
   in the Binding Unique Identifier sub-option.  Further operations
   except for the text below are same as [6].  The operation of sending
   BE is described in the section 6.5.

   When a mobile node receives a Binding Error with Status field set
   to 2 (unrecognized MH Type value) , it MAY stop trying to register
   multiple care-of addresses and registers only primary care-of address
   as well as Mobile IPv6.


   6. Home Agent and Correspondent Node Operation

   6.1. Searching Binding Cache with Binding Unique Identification
        Number

   If a correspondent node has multiple bindings for a mobile node
   in its binding cache database, it can use any of the bindings for
   communications to the mobile node.  How to select the most suitable
   binding from the binding cache database is out of scope in this
   document.  Once a correspondent node decides one binding and gets
   BID for the desired binding mostly by using policy and filter
   information, it searches the desired binding with BID.

   Whenever a correspondent node searches a binding cache for a home
   address, it SHOULD uses both the home address and BID as a key of
   search if it knows BID of the desired binding.  Below is an example
   of multiple bindings for a home address in binding cache database.
   If a correspondent node searches the binding with the home address
   and BID2, it gets binding2 for this mobile node.

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

   A correspondent node basically learns BID when it receives an Binding
   Unique Identifier sub-option.  At the time, the correspondent node
   MUST look up its binding cache database with the home address and
   the BID retrieved from Binding Update.  If a correspondent node does
   not know BID, the correspondent node searches a binding with only a
   home address as well as base Mobile IPv6.  In such case, the first
   matched binding MAY be found.  But which binding entry is returned
   for the normal search depends on implementations.  If a correspondent
   node does not desire to use multiple bindings for a mobile node, the
   correspondent node can ignore knowing BID.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 18]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   6.2. Receiving Binding Update

   If a Binding Update does not contain a Binding Unique Identifier
   sub-option and it does not have 'M' flag set, the processing of the
   Binding Update is same as [6].  But if the receiver already has
   multiple bindings for the home address, it MUST overwrite existing
   bindings for the mobile node with the received binding.  After
   processing the Binding Update which does not contain a Binding Unique
   Identifier sub-option, the receiver node MUST have only a binding for
   the mobile node.  If the Binding Update is for de-registration, the
   receiver MUST delete all existing bindings for the mobile node.

   On the other hand, if a Binding Update contains a Binding Unique
   Identifier sub-option or 'M' flag set, a receiver node MUST operate
   additional validations as follows.

    -  A receiver node MUST validate the Binding Update according to the
       section 9.5.1 of [6].

    -  If the Binding Update has 'M' flag at Flag field, a Binding
       Unique Identifier sub-option MUST be present in Mobility options
       field of the Binding Update.

    -  If there is no Binding Unique Identifier sub-option with M flag
       set, the receiver node MUST silently drop the Binding Update.

    -  If the Binding Unique Identifier sub-option is present, the
       receiver node MUST process the Binding Update.

    -  If the Lifetime field is not zero, the receiver node registers a
       binding with BID as a mobile node's binding.

        *  If the receiver does not have any binding for the mobile
           node, it registers a binding with BID.

        *  If the receiver has a normal binding without BID for the
           mobile node, it de-registers the normal binding and registers
           a new binding with BID according to the Binding Update.  In
           this case, the receiver MUST send Binding Acknowledgment with
           status code set to 140.

        *  If the receiver node has already registered the binding which
           BID is matched with requesting BID , then it MUST update
           the binding up-to-date with the Binding Update.  Meanwhile,
           if the receiver does not have a binding entry which BID is
           matched with the requesting BID, it registers a new binding
           with the BID.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 19]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


    -  If Lifetime field is zero, the receiver node deletes the
       registering binding entry which BID is same as BID sent by the
       Binding Unique Identifier sub-option.  If the receiver node
       does not have appropriate binding which BID is matched with the
       Binding Update, it ignores the Binding Update.

   Note if the mobile node sends multiple Binding Updates with a
   different BID but for same care-of address (i.e.  same home address,
   same care-of address, and different BID) , the receiver SHOULD
   register both bindings into its binding cache.


   6.3. Sending Binding Acknowledgment

   If a Binding Update does not contain a Binding Unique Identifier
   sub-option, a node, either a correspondent node or a home agent, MUST
   reply Binding Acknowledgment according to the section 9.5.4 of [6].
   Otherwise, the node MUST follow the additional procedure below.
   Whenever a Binding Unique Identifier present, the node MUST reply a
   Binding Acknowledgment regardless of 'A' flag in Binding Update.

   If the node successfully registers a binding with BID stored
   in a Binding Unique Identifier sub-option, it returns a Binding
   Acknowledgment with Status field set to '0' (Successful registration)
   and a Binding Unique Identifier sub-option copied from the received
   Binding Update.  If the node deletes the existing binding which
   does not have BID and registers a new binding with BID, it MUST
   return a Binding Acknowledgment with Status field set to '140'.  On
   the other hand, if the node encounters an error during processing
   a Binding Update, it must returns a Binding Acknowledgment with
   appropriate error number described in [6].  The node SHOULD put a
   Binding Unique Identifier sub-option if BID is available for the
   Binding Acknowledgment.


   6.4. Sending Binding Refresh Request

   When a correspondent node notices that a registered binding will
   be expired soon, it SHOULD send a Binding Refresh Request.  If the
   registered binding has BID, the correspondent node SHOULD contain
   a Binding Unique Identifier sub-option in the Binding Refresh
   Request.  Then, the correspondent node can receive a Binding Update
   with a Binding Unique Identifier sub-option and can update only the
   particular binding.  If the registered binding does not have BID,
   then the correspondent node sends a Binding Refresh Request without
   the sub-option.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 20]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   6.5. Sending Binding Error

   When a correspondent node sends a Binding Error with Status field
   set to 1 (Unrecognized MH Type value), it MAY put a Binding Unique
   Identifier sub-option into Mobility Options field if BID is available
   in a received binding message.

   When a correspondent node receives data packets with a home address
   destination option, it verifies an IPv6 source address field.  If the
   source address is not registered in the correspondent node's binding
   cache, the correspondent node MUST return Binding Error to the
   sender with the status set to zero (Unknown binding for Home Address
   destination option).  The correspondent node can not put a Binding
   Unique Identifier sub-option, because there is no binding cache entry
   for the source address.


   7. Network Mobility Applicability

   Support of multihomed mobile routers is advocated in the NEMO working
   group (see R12 ``The solution MUST function for multihomed MR and
   multihomed mobile networks'' in [4]).

   Since the binding management mechanisms are the same for a mobile
   host operating Mobile IPv6 and for a mobile router operating NEMO
   Basic Support [3], our extensions can also be used to deal with
   multiple care-of addresses registration sent from a multihomed mobile
   router.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 21]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   A. Example Configurations

   In this section, we describes typical scenarios when a mobile
   node has multiple network interfaces and acquires multiple care-of
   addresses bound to a home address.

   A home address of a mobile node (MN in figures) is a:b:c:d::EUI
   address.  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 addresses.

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


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

  Binding Cache Database:
     Home Agent's 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 Interfaces are attached to Foreign Link


   Figure 2 depicts the scenario where the primary interface of the
   mobile node is attached to the home link.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 22]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   After bindings registration, the home agent and the correspondent
   node has listed binding entries of Figure 2 in their binding cache
   database.  The mobile node can communicate with the home agent
   through only the primary interface attached to the home link.  On the
   other hand, the mobile node can communicate with the correspondent
   node by using route optimization.  Even when the mobile node is
   attached to the home link, it can still send Binding Updates for
   other active care-of addresses (CoA2 and CoA3).  If the correspondent
   node has bindings, packets are routed to each care-of addresses
   directly.  Any packets arrived at the home agent are routed to the
   primary interface.


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

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


          Figure 2: Primary Interface is attached to Home Link


   Figure 3 depicts the scenario where a non primary interface of a
   mobile node is attached to the home link.

   The home agent and the correspondent node has listed binding entries
   of Figure 3 in their binding cache database.  The mobile node can
   not utilize the non primary interface attached to the home link,
   because the home agent still defends the home address of the mobile
   node by proxy neighbor advertisements.  All packets routed to the
   home link are intercepted by the home agent and tunneled to the other
   interfaces attached to the foreign link according to the binding
   entries.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 23]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


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

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


    Figure 3: One of Non Primary Interfaces is attached to Home Link


   Figure 4 depicts the scenario where primary and a non primary
   interface of a mobile node are attached to the home link.  The
   home agent and the correspondent node has listed binding entries
   of Figure 4 in their binding cache database.  The mobile node can
   not use the non primary interface attached to a foreign link unless
   a correspondent node has a binding for the non primary interface.
   All packets which arrive at the home agent are routed to one of
   interfaces attached to the mobile node.  The home agent decides an
   interface anyway, for example, by using policy and filters.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 24]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


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

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


            Figure 4: Primary and Non Primary Interfaces are
                          attached to Home Link


   Acknowledgments

   The authors would like to thank Julien Charbon, Susumu Koshiba,
   Hiroki Matutani, Koshiro Mitsuya, Nicolas Montavont, Koji Okada,
   Masafumi Watari (in alphabetical order), the nacm group at KEIO
   University, and WIDE project for their contributions.


   References

   [1] M. Baker, X. Zhao, S. Cheshire, and J. Stone.  Supporting
       mobility in mosquitonet.  In Proceedings of the 1996 USENIX
       Conference, Jan. 1996.

   [2] S. Deering and R. Hinden.  Internet Protocol, Version 6 (ipv6)
       Specification.  Request for Comments (Draft Standard) 2460,
       Internet Engineering Task Force, December 1998.

   [3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert.  Nemo
       Basic Support Protocol (work in progress).  Internet Draft
       (draft-ietf-nemo-basic-support-00), Internet Engineering Task
       Force, June 2003.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 25]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   [4] T. Ernst.  Nemo Mobility Support Goals and Requirements (work in
       progress).  Internet Draft (draft-ietf-nemo-requirements-01),
       Internet Engineering Task Force, May 2003.

   [5] T. Ernst and H. Lach.  Nemo Mobility Support Terminology (work
       in progress).  Internet Draft (draft-ietf-nemo-terminology-00),
       Internet Engineering Task Force, May 2003.

   [6] D. Johnson, C. Perkins, and J. Arkko.  Mobility
       support in IPv6 (work in progress).  Internet Draft,
       (draft-ietf-mobileip-ipv6-24.txt), Internet Engineering Task
       Force, June 2003.

   [7] M. Stemm and R. H. Katz.  Vertical handoffs in wireless overlay
       networks.  Mobile Networks and Applications, 3(4):335--350, 1998.

   [8] R. Wakikawa, K. Uehara, and J. Murai.  Multiple Network
       Interfaces Support by Policy-Based Routing on Mobile IPv6.  In
       The 2002 International Conference on Wireless Networks, ICWN2002,
       Jul. 2002.

   [9] X. Zhao, C. Castelluccia, and M. Baker.  Flexible network support
       for mobility.  In The Second Annual International Conference on
       Mobile Computing and Networking, Nov. 1998.


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 26]


Internet Draft    Multiple Care-of Addresses Registration    20 Sep 2003


   Authors' Addresses


        Ryuji Wakikawa               Thierry Ernst
        Keio University and WIDE     Keio University and WIDE
        5322 Endo Fujisawa Kanagawa  5322 Endo Fujisawa Kanagawa
        252 JAPAN                    252 JAPAN
        Phone:  +81-466-49-1394      Phone:  +81-466-49-1394
        EMail:  ryuji@sfc.wide.ad.jp EMail:  ernst@sfc.wide.ad.jp
        Fax:  +81-466-49-1395        Fax:  +81-466-49-1395

        Keisuke Uehara               Kenichi Nagami
        Keio University and WIDE     INTEC NetCore
        5322 Endo Fujisawa Kanagawa  1-3-3 Shinsuna Koto-ku Tokyo
        252 JAPAN                    135-0075 JAPAN
        Phone:  +81-466-49-1394      Phone:  +81-3-5665-5069
        EMail:  kei@wide.ad.jp       EMail:  nagami@inetcore.com
        Fax:  +81-466-49-1395        FAX : +81-3-5665-5094


R. Wakikawa et.al.             Expires 20 Mar 2003             [Page 27]