MIP6 Working Group                                        Ryuji Wakikawa
INTERNET DRAFT                                            Keisuke Uehara
Category:  Individual                                      Thierry Ernst
Expire:20 Dec 2005                                       Keio Univ./WIDE
                                                          Kenichi Nagami
                                                           INTEC Netcore
                                                             20 Jun 2005

                 Multiple Care-of Addresses Registration
               draft-wakikawa-mobileip-multiplecoa-04.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 mailing list.

   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 December 20, 2005.


   Copyright Notice

   Copyright (C) The Internet Society (2005).


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 1]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   Abstract

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

                                  Contents


Status of This Memo                                                    1

Copyright Notice                                                       1

Abstract                                                               2

 1. Introduction                                                       4

 2. Terminology                                                        6

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

 4. Mobile IPv6 Extensions                                            10
     4.1. Binding Cache Structure and Management  . . . . . . . . .   10
     4.2. Binding Update Structure and Management . . . . . . . . .   10
     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  . . . . . . . . . . . . .   12
     4.4. Dynamic Home Agent Address Discovery  . . . . . . . . . .   13
           4.4.1. DHAAD Request . . . . . . . . . . . . . . . . . .   13
           4.4.2. DHAAD Reply . . . . . . . . . . . . . . . . . . .   13
           4.4.3. Home Agent Information Option . . . . . . . . . .   14

 5. Mobile Node Operation                                             15


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 2]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


     5.1. Management of care-of addresses and Binding Unique
         Identifier . . . . . . . . . . . . . . . . . . . . . . . .   15
     5.2. Sending Binding Update  . . . . . . . . . . . . . . . . .   15
     5.3. De-registration . . . . . . . . . . . . . . . . . . . . .   16
     5.4. Using Alternate Care-of Address . . . . . . . . . . . . .   17
     5.5. Receiving Binding Acknowledgment  . . . . . . . . . . . .   17
     5.6. Receiving Binding Refresh Request . . . . . . . . . . . .   18
     5.7. Receiving Binding Error . . . . . . . . . . . . . . . . .   18

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

 7. Network Mobility Applicability                                    22

Appendices                                                            23

 A. A Scenario:  Access both Carrier Packet Network and the Internet  23

 B. Example Configurations                                            24

 C. Changes                                                           27

References                                                            28

Authors' Addresses                                                    29


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 3]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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.  Such motivations for multiple points of attachment, and
   benefits for doing it are discussed at large in [4].  The problem
   statement of multihomed mobile node is summarized in  [7].

   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 [9].  In
   addition, users should select the most appropriate network interface
   depending on a visiting network environment, since wireless networks
   are mutable and less reliable than wired networks and since each
   network interface has different cost, performance, bandwidth, access
   range, and reliability.  Users should also be able to select the
   most appropriate interface per communication type.  For example, TCP
   traffic should be transmitted over the wireless interface, whereas
   UDP traffic should be transmitted over the wired interface to avoid
   disturbing TCP connections.

   Associating multiple care-of addresses to a single home address would
   allow durable Internet connectivity.  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 [1] conceptually allows a node to have several addresses on a
   given interface.  Consequently, Mobile IPv6 [5] has mechanisms to
   manage multiple ``home addresses'' based on home agent's managed
   prefixes such as mobile prefix solicitation and mobile prefix
   advertisement.  But assigning a single home address to a 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


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 4]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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 communication for connection management.  Applications must be
   restarted to reset the connection information when the mobile node
   changes its active network interface (i.e.  change the home address).

   However, according to section 11.5.3 of the Mobile IPv6 specification
   [5], 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 care-of address recorded in the binding cache
   with the one contained in the latest received binding update.  It
   is thus impossible for a mobile node to register multiple care-of
   addresses in the correspondent node's binding cache.

   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 Binding Update.
   Correspondent nodes and the home agent record the BID into their
   binding cache.  The home address thus identifies a mobile node itself
   whereas the BID identifies each binding registered by a mobile node.
   By using the BID, multiple bindings can then be distinguished.

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


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 5]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   2. Terminology

   Terms used in this draft are defined in [5] and  [6].  We define or
   redefine the following ones:

      Binding Unique Identification number (BID)

         The BID is an identification number used to distinguish
         multiple bindings registered by the mobile node.  Assignment of
         distinct BID allows a mobile node to register multiple binding
         cache entries for a given home address.  The BID is generated
         to register multiple bindings in the binding cache for a given
         addess in a way it cannot be duplicated with another BID.
         The zero value and a negative value MUST NOT be used.  After
         being generated by the mobile node, the BID is stored in the
         Binding Update List and is sent by the mobile node by means of
         a sub-option of a Binding Update.  A mobile node MAY change
         the value of a BID at any time according to its administrative
         policy, for instance to protect its privacy.

         The BID can be assigned to either a care-of address or an
         interface depending on implementation choices 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 [5], 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 document,
         the term is refined as ``the care-of address which is primarily
         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 care-of-address from the set of
         other care-of addresses that it may also own at that time.

      Primary Interface

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


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 6]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


      Binding Unique Identifier sub-option

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

      Multiple Care-of Addresses Flag (B 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 Dec 2005             [Page 7]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   3. Protocol Overview

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


   3.1. Multiple Care-of Addresses Registration

   Once a mobile node gets several IPv6 global addresses on distinct
   interfaces, it MUST select a primary care-of address from the active
   addresses as specified in Section 11.5.3  [5].  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 with a Binding
   Unique Identifier sub-option.  The B 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 Binding
   Update to the corresponding field in the binding entry.

   After this home registration, the mobile node SHOULD 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 for 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 independently.

   If the mobile node wish to register its binding with 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 a BID for each care-of addresses to
   register them as individual bindings.  The registration step
   is the same as for the home registration except for calculating
   authenticator by using Binding Unique Identifier sub-option as well
   as the other sub-options specified in [5].


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 8]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   3.2. Multiple Bindings Management

   The BID is used as a search key for a corresponding entry in the
   binding cache in addition to the home address.  When the home agent
   checks the binding cache database for the mobile node, it searches
   a corresponding binding entry with the home address and BID of the
   desired binding.  The desired binding can be selected with policy
   and filter information.  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 it searches the binding cache with
   the home address as it would for Mobile IPv6

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

   When one of the care-of addresses is changed, the mobile node sends
   a Binding Update with the new care-of address and the corresponding
   BID. The receiver of the Binding Update updates the binding which
   BID fits the BID contained in the received Binding Unique Identifier
   sub-option.  The mobile node can manage each binding independently
   owing to BID.

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


   3.3. Returning Home

   When the mobile node returns home, there are two situations, since
   the home agent defends the mobile node's home address by using
   proxy neighbor advertisement.  It is impossible to utilize all the
   interfaces when one interface is attached to the home link and the
   others are attached to foreign 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.


R. Wakikawa et.al.              Expires 20 Dec 2005             [Page 9]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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
   de-registration 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 the 'P' flag in the Binding Unique Identifier
   sub-option to indicates stop proxying for the mobile node to the home
   agent.  The 'P' flag is valid only when the destination of a Binding
   Update is a home agent.

   The second situation is when a 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
   de-registration Binding Update with the Binding Unique Identifier
   sub-option.  The mobile node stores the BID of the binding and MUST
   NOT set the 'P' flag in the sub-option regardless of home agent or
   not.  Therefore, the receiver of the de-registration 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

   In this section are described the changes to allow Mobile IPv6 to
   manage multiple bindings bound to a same home address.


   4.1. Binding Cache Structure and Management

   Additional items are required in the binding cache structure, which
   are:

    -  BID of the binding cache entry.  The BID is notified by the
       mobile node by means of a Binding Update sub-option.  The value
       MUST be zero if the Binding Update does not contain a BID.


   4.2. Binding Update Structure and Management

   Additional items are required for the binding update structure, which
   are:


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 10]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


    -  BID: MUST be generated whenever the mobile node registers
       multiple bindings for its home address.

    -  Primary flag:  MUST be set if the care-of address is primary.


   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 = 4  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Binding Unique ID (BID)   |P|       Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+

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

      Length
             The value MUST be always 4.

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

      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


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 11]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


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


   4.3.2. Binding Update

   The 'B' flag MUST be set and a Binding Unique Identifier sub-option
   MUST be included if the mobile node wants to bind multiple care-of
   address to a given home address.

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

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

      Reserved
           Reserved field is reduced to 9 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 the 'B' flag set MUST reply
   with a Binding Acknowledgment if the 'A' flag is also set or in
   case of a home registration.  The receiver MUST also send a Binding
   Acknowledgment with corresponding error codes if it finds an error
   while processing the Binding Update and its sub-option described in
   section 4.3.2.

   If a Binding Update has the 'B' flag set and a Binding Unique
   Identifier sub-option is present, the receiver node MUST reply with 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 the BID set in the
   Binding Unique Identifier sub-option.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 12]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   A new number is defined for handling the 'B' flag:

    -  TBD (144)
       It implies conflicting a regular binding and a binding that has
       BID in binding cache.  The regular binding indicates the binding
       that does not have BID field.  The status value is TBD.


   4.4. Dynamic Home Agent Address Discovery

   The Dynamic Home Agent Address Discovery (DHAAD) defined in
   RFC3775 [5] is extended so that Mobile Nodes or Mobile Routers only
   register multiple care-of addresses with Home Agents that support
   multiple care-of addresses registration.

   However, we do not provide a solution for Mobile Nodes that would
   like to register multiple care-of addresses only with Correspondant
   Nodes that support multiple care-of addresses registration.


   4.4.1. DHAAD Request

   A new 'B' flag is introduced in the DHAAD Request message in order
   to discover Home Agents supporting the multiple care-of address
   registration.

    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      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Identifier           |R|B|        Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Multiple Care-of Addresses Flag (B)
           This flag is set when the mobile node wants to discover Home
           Agents that support multiple care-of addresses registration.


   4.4.2. DHAAD Reply

   A new 'B' flag is introduced in the DHAAD Reply message.  When a Home
   Agent receives a DHAAD Request message with the Multiple Care-of
   Addresses support Flag set, it MUST reply with a list of Home Agents
   supporting the multiple care-of addresses registration.  The 'B' flag
   MUST be set in the DHAAD Reply.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 13]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


    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      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |R|B|         Reserved          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                      Home Agent Addresses                     .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Multiple Care-of Addresses Flag (B)
           This flag is set when the Home Agents listed in this message
           support the multiple care-of addresses registration.


   4.4.3. Home Agent Information Option

   A new 'B' flag is introduced in the Home Agent Information Option.
   The home agent SHOULD set the flag if it supports multiple care-of
   addresses registration.

    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      |    Length     |R|B|       Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Home Agent Preference     |      Home Agent Lifetime      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Multiple Care-of Addresses Flag (B)
           This flag is set when the Home Agent supports multiple
           care-of addresses registration.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 14]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   5. Mobile Node Operation

   5.1. Management of care-of addresses and Binding Unique Identifier

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

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

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

   The difference between the above two cases is only a number of
   physical network interfaces and therefore does not matter.  The
   Identification number is used to distinguish multiple bindings so
   that the mobile node assigns an identification number for each
   care-of addresses.  How to assign an identification number is up to
   implementors.

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


   5.2. Sending Binding Update

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

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

   On the other hand, if the mobile node needs to register multiple
   care-of addresses, it MUST use BIDs all the time.  The mobile node
   sets B flag in a Binding Update and puts a Binding Unique Identifier
   sub-option into the Option field of the Binding Update.  The BID is


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 15]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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 the 'B' flag set
   and a Binding Unique Identifier sub-option for all care-of addresses,
   one by one.  In any case, the mobile node MUST set the 'A' flag in
   Binding Updates and MUST wait for a Binding Acknowledgment to confirm
   the registration was successful as described in section 5.5.

   Note that 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 means of a single Binding Update.


   5.3. De-registration

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

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

   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 after the mobile node
   returns home, it MUST set the 'P' flag in a Binding Unique Identifier
   sub-option.  Otherwise, the 'P' flag MUST NOT be set.  If the 'P'
   flag is set, the home agent stop proxy neighbor advertisement for the
   mobile node.  The 'P' flag is ignored if the receiver is not the home
   agent.

   When the mobile node's primary interface gets attached to the home
   link (see Figure 3 and Figure 5 in Appendix B), the Mobile Node MUST
   start de-registration processing to its home agent as indicated in
   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 at correspondent nodes
   as well, the node can still keep the binding of the non-primary
   interface active at the correspondent nodes.  In such case, the
   mobile node still receives packets at a non-primary interface
   attached to a foreign link thanks to 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 the mobile node's non-primary interface
   gets attached back to the home link (see Figure 4 in Appendix B),


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 16]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   the mobile node 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 is eager to receive packets at the non-primary interface
   at the home link, it MUST re-select the interface as the primary one.


   5.4. Using Alternate Care-of Address

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

    -  One care-of address becomes invalid (e.g because the link where
       it is attached is no longer available) and MUST be deleted.
       In such case, the mobile node can not sends a Binding Update
       from the care-of address because the interface's link is lost.
       The mobile node needs to de-register the remote binding of the
       care-of address through one of its active care-of addresses.

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

   In these cases, the mobile node sends a Binding Update with both
   Alternate Care-of Address sub-option and Binding Unique Identifier
   sub-option.  The processing of Alternate Care-of Address sub-option
   is described in the 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.


   5.5. Receiving Binding Acknowledgment

   The verification of a Binding Acknowledgment is the same as in Mobile
   IPv6 (section 11.7.3 of [5]).  The operation for 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 the 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


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 17]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   addresses by using a Binding Unique Identifier sub-option.  If the
   originator is the Home Agent, the mobile node MAY perform DHAAD to
   discover a new Home Agent supporting the multiple care-of address
   registration.

   If a Binding Unique Identifier sub-option is present, the mobile
   node checks the Status field of the Binding Acknowledgment.  If
   the status code indicates successful registration (below 128), 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
   relevant operations according to the status code.

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


   5.6. Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is the same as in
   Mobile IPv6 (section 11.7.4 of [5]).  The operation of sending a
   Binding Refresh Request is described in 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 the 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 is present in a Binding
   Refresh Request, the 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 List entry
   for the requesting node, the mobile node needs to register either
   a single binding or multiple bindings depending on its binding
   management policy.


   5.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 the
   BID in the Binding Unique Identifier sub-option.  Further operations
   except for the text below are identical as in [5].  The operation for
   sending BE is described in the section 6.5.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 18]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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 performed in 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 to
   communicate with the mobile node.  How to select the most suitable
   binding from the binding cache database is out of scope in this
   document.

   Whenever a correspondent node searches a binding cache for a home
   address, it SHOULD uses both the home address and the BID as the
   search key if it knows the corresponding BID. Below is an example of
   multiple bindings for a home address in the 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 the BID when it receives a
   Binding Unique Identifier sub-option.  At the time, the correspondent
   node MUST look up its binding cache database with the home address
   and the BID retrieved from Binding Update.  If the correspondent
   node does not know the BID, it searches a binding with only a home
   address as performed in Mobile IPv6.  In such case, the first matched
   binding is found.  But which binding entry is returned for the normal
   search depends on implementations.  If the correspondent node does
   not desire to use multiple bindings for a mobile node, it can simply
   ignore the BID.


   6.2. Receiving Binding Update

   If a Binding Update has neither 'B' flag set nor a Binding Unique
   Identifier, the processing of the regular Binding Update is the same
   as in [5].  But if the receiver already has multiple bindings for the
   home address, it MUST overwrite all existing bindings for the mobile
   node with the received binding.  As a result, the receiver node MUST
   have only a binding for the mobile node.  If the Binding Update is


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 19]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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 the 'B' flag is set, a receiver node MUST
   operate additional validations as follows:

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

    -  If the Binding Update has the 'B' flag set at the 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 the
       'B' 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 that includes the BID as a mobile node's binding.

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

        *  If the receiver has a regular binding which does not have
           BID for the mobile node, it de-registers the regular binding
           and registers a new binding including BID according to the
           Binding Update.  In this case, the receiver MUST send Binding
           Acknowledgment with status code set to 144.

        *  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
           for the BID.

    -  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 MUST reject this de-registration Binding
       Update.  If the receiver is a Home Agent, it SHOULD also return a
       Binding Acknowledgement to the mobile node, in which the Status
       field is set to 133 (not home agent for this mobile node).


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 20]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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, the receiver, either a correspondent node or a home
   agent, MUST reply with a Binding Acknowledgment according to section
   9.5.4 of [5].  Otherwise, whenever the BID sub-option is present, the
   receiver MUST follow the additional procedure below.  The receiver
   MUST reply with a Binding Acknowledgment whether the 'A' flag is set
   or not in the Binding Update.

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


   6.4. Sending Binding Refresh Request

   When either a correspondent node or Home Agent 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.


   6.5. Sending Binding Error

   When a correspondent node sends a Binding Error with Status field
   set to 2 (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.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 21]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   When a correspondent node receives data packets with a home address
   destination option, it verifies the IPv6 source address field.  If
   the source address is not registered in the correspondent node's
   binding cache, the correspondent node MUST return a 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 [3]).

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

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

   A mobile router MUST NOT use the 'P' flag when its home agent does
   not use proxy neighbor advertisement to intercept packets destined
   to the mobile router.  This situation occurrs when the home link
   is configured as a virtual home link as detailed in extended home
   address described in [10].


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 22]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   A. A Scenario:  Access both Carrier Packet Network and the Internet

   This scheme can be applied to many scenarios such as described
   in [4].  Additionally, there is a specific scenario where this scheme
   is specially required.

   A carrier often provides an independent networks from the Internet.
   For example, a Japanese carrier, NTT, provides a Flet's network
   for ADSL and FTTH users.  The Flet's network is isolated from the
   Internet and is independent from the ISP, but can be accessed only
   from the NTT's ADSL and the FTTH physical lines.

   Similar services are well expected to mobile wireless services.  When
   a mobile node has a W-CDMA and a 802.11b interfaces with the network
   topology described in Figure 1, application servers limit connection
   only from the W-CDMA celluler network.

   In such case, even if a mobile node is armed with Mobile IPv6, the
   application servers will reject the connection from 802.11b.  If the
   mobile node intelligently selects the W-CDMA for the application
   servers, the mobile node can use 802.11b for other traffic.  The
   mobile node simply uses this scheme.


                              +-------------------------+
                              |   +-------------+       |
                              |   |appl. servers|       |
                              |   +------+------+       |
                 +----+       |          |              |
                 | CN |       |   service networks      |
                 +--+-+       |   ----------------      |
                    |         |          |              |
                +---+------+  |       +--+-+            |
         +------+ Internet |--+---+---+ HA +--+         |
  802.11b|      +----------+  |   |   +----+  |         |
     CoA2|                    |   |        Home Link    |
      +--+--+                 |   +        ---+------   |
      |  MN +=============Access Servers                |
      +-----+ CoA1            |                         |
            W-CDMA            +-------------------------+
                                  W-CDMA Packet Network


         Figure 1: Service operated by a combination of a Packet
                        Network and the Internet.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 23]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   B. Example Configurations

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

   The home address of the mobile node (MN in figures) is a:b:c:d::EUI.
   MN has 3 different interfaces and possibly acquires care-of addresses
   1-3 (CoA1, CoA2, CoA3).  The MN assigns BID1, BID2 and BID3 to each
   care-of addresses.

   Figure 2 depicts the scenario where all interfaces of the mobile node
   are attached to foreign links.  After binding registrations, the home
   agent (HA) and the correspondent node (CN) have the binding entries
   listed in Figure 2 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 2: Multiple Interfaces are attached to Foreign Link


   Figure 3 depicts the scenario where the primary interface of MN is
   attached to the home link.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 24]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


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


                 +----+
                 | CN |
                 +--+-+
                    |
                +---+------+          +----+
         +------+ Internet |----------+ HA |
         |      +--------+-+          +--+-+
     CoA2|               |               |   Home Link
      +--+--+            |         --+---+------
      |  MN +========+   |           |
      +--+--+        |   |           |
     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 3: Primary Interface is attached to Home Link


   Figure 4 depicts the scenario where a non-primary interface of a MN
   is attached to the home link.

   The HA and the CN have the binding entries listed in Figure 4 in
   their binding cache database.  MN can not utilize the non-primary
   interface attached to the home link, because the HA still defends the
   home address of the MN by proxy neighbor advertisements.  All packets
   routed to the home link are intercepted by the HA and tunneled to
   the other interfaces attached to the foreign link according to the
   binding entries.

   Figure 5 depicts the scenario where primary and a non-primary
   interface of MN are attached to the home link.  The HA and the CN


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 25]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


                 +----+
                 | 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 4: One of Non-Primary Interfaces is attached to Home Link


   have the binding entries listed in Figure 5 in their binding cache
   database.  The MN can not use the non-primary interface attached to a
   foreign link unless a CN has a binding for the non-primary interface.
   All packets which arrive at the HA are routed to one of interfaces
   attached to the MN. The HA decides an interface anyway, for example,
   by using policy and filters.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 26]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


                 +----+
                 | 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 5: Primary and Non-Primary Interfaces are
                          attached to Home Link


   C. Changes

    -  Updating packet formats.  M flag is re-named to B flag as
       suggested by  [11].

    -  Adding extended operations for DHAAD packets in terms of finding
       Home Agent supporting multiple CoAs registration.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 27]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   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 Jun Murai Lab.  at KEIO
   University, and WIDE project for their contributions.

   The authors acknowledge Romain Kuntz from Keio University and WIDE
   for providing the texts of the DHAAD operation and reviewing this
   draft.


   References

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

    [2] V. Devaraplli, R. Wakikawa, A. Petrescu, and P. Thubert.
        Network Mobility (NEMO) Basic Support Protocol.  Request for
        Comments (Standards Track) 3963, Internet Engineering Task
        Force, January 2005.

    [3] T. Ernst.  Network Mobility Support Goals and Requirements (work
        in progress).  Internet Draft (draft-ietf-nemo-requirements-04),
        Internet Engineering Task Force, February 2005.

    [4] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng,
        K. Kuladinithi, and T. Noel.  Goals and Benefits of Multihoming
        (work in progress, draft-ernst-generic-goals-and-benefits-01).
        Internet Draft, Internet Engineering Task Force, February 2005.

    [5] D. Johnson, C. Perkins, and J. Arkko.  Mobility support in
        IPv6.  Request for Comments (Standards Track) 3775, Internet
        Engineering Task Force, June 2004.

    [6] J. Manner and M. Kojo.  Mobility Related Terminology.  Request
        for Comments (Informational) 3753, Internet Engineering Task
        Force, June 2004.

    [7] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, and C. Ng.
        Problem Statement for multihomed Mobile Nodes (work in progress,
        draft-montavont-mobileip-multihoming-pb-statement-03.txt).
        Internet Draft, Internet Engineering Task Force, January 2005.

    [8] C. Ng, E. Paik, and T. Ernst.  Analysis of Multihoming
        in Network Mobility Support (work in progress,
        draft-ietf-nemo-multihoming-issues-xx.txt).  Internet
        Draft, Internet Engineering Task Force, July 2004.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 28]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


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

   [10] P. Thubert, R. Wakikawa, and V. Devarapalli.  NEMO Home
        Network models (work in progress).  Internet Draft
        (draft-ietf-nemo-home-network-models-03.txt), Internet
        Engineering Task Force, March 2005.

   [11] P. Valitalo.  Multihoming of (1,1,*) configured
        networks in Network Mobility Support (work in progress,
        draft-valitalo-nemo-multihoming-00.txt).  Internet Draft,
        Internet Engineering Task Force, March 2005.


   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 Dec 2005             [Page 29]


Internet Draft    Multiple Care-of Addresses Registration    20 Jun 2005


   Intellectual Property Statement

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

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

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


   Disclaimer of Validity

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


   Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


R. Wakikawa et.al.             Expires 20 Dec 2005             [Page 30]