[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5648

Monami6 Working Group                                        R. Wakikawa
Internet-Draft                                           Keio University
Expires: April 4, 2007                                          T. Ernst
                                                  Keio University / WIDE
                                                               K. Nagami
                                                           INTEC NetCore
                                                                Oct 2006


                Multiple Care-of Addresses Registration
                 draft-ietf-monami6-multiplecoa-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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



Wakikawa, et al.          Expires April 4, 2007                 [Page 1]

Internet-Draft                    MCoA                          Oct 2006


   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.










































Wakikawa, et al.          Expires April 4, 2007                 [Page 2]

Internet-Draft                    MCoA                          Oct 2006


Table of Contents

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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7

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

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

   5.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Management of Care-of Addresses and Binding Unique
           Identifier . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2.  Binding Registration . . . . . . . . . . . . . . . . . . . 15
     5.3.  Binding Bulk Registration  . . . . . . . . . . . . . . . . 16
     5.4.  Binding De-Registration  . . . . . . . . . . . . . . . . . 16
     5.5.  Returning Home . . . . . . . . . . . . . . . . . . . . . . 17
     5.6.  Using Alternate Care-of Address  . . . . . . . . . . . . . 17
     5.7.  Receiving Binding Acknowledgment . . . . . . . . . . . . . 18
     5.8.  Receiving Binding Refresh Request  . . . . . . . . . . . . 18
     5.9.  Receiving Binding Error  . . . . . . . . . . . . . . . . . 19

   6.  Home Agent and Correspondent Node Operation  . . . . . . . . . 20
     6.1.  Searching Binding Cache with Binding Unique Identifier . . 20
     6.2.  Receiving Binding Update . . . . . . . . . . . . . . . . . 20
     6.3.  Sending Binding Acknowledgment . . . . . . . . . . . . . . 22
     6.4.  Sending Binding Refresh Request  . . . . . . . . . . . . . 23
     6.5.  Sending Binding Error  . . . . . . . . . . . . . . . . . . 23

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

   8.  IPsec and IKE interaction  . . . . . . . . . . . . . . . . . . 25

   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26

   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27



Wakikawa, et al.          Expires April 4, 2007                 [Page 3]

Internet-Draft                    MCoA                          Oct 2006


     11.2. Informative References . . . . . . . . . . . . . . . . . . 27

   Appendix A.  Example Configurations  . . . . . . . . . . . . . . . 28

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

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36











































Wakikawa, et al.          Expires April 4, 2007                 [Page 4]

Internet-Draft                    MCoA                          Oct 2006


1.  Introduction

   Permanent Internet connectivity is required by some applications
   while a mobile node moves across several access networks (i.e.  ISPs,
   hotspots, etc).  Unfortunately, there is no network interfaces
   assuring global scale connectivity.  Therefore, a mobile node should
   use various type of network interfaces to obtain durable and wide
   area network connectivity [8].  For example, it is desirable to
   maintain the Internet connectivity while an automobile running on a
   freeway receives voice or video streaming data from different access
   networks.  Such scenarios and motivations for multiple points of
   attachment, and benefits for doing it are discussed at large in [9].

   Once multiple interfaces are available to a mobile node, a backup
   interface can be used to recover from the loss of Internet
   connectivity on the other interface, therefrom maintaining Internet
   connectivity of wide spread and reach.  In addition, each
   communication flow could be sent to a distinct network interface,
   providing efficient network bandwidth consumption.  It becomes
   possible for users to select the most appropriate network interface
   depending on a visiting network environment, since wireless networks
   are mutable and less reliable than wired networks and since each
   network interface has different cost, performance, bandwidth, access
   range, and reliability.  Users should also be able to select the most
   appropriate interface per communication type.  For example, TCP
   traffic should be transmitted over the wireless interface, whereas
   UDP traffic should be transmitted over the wired interface to avoid
   disturbing TCP connections.

   IPv6 [1] conceptually allows a node to have several addresses on a
   given interface.  Consequently, Mobile IPv6 [2] has mechanisms to
   manage multiple ``Home Addresses'' based on Home Agent's 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
   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, 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



Wakikawa, et al.          Expires April 4, 2007                 [Page 5]

Internet-Draft                    MCoA                          Oct 2006


   cache with the one contained in the latest received binding update.
   It is thus impossible for a mobile node to register multiple Care-of
   Addresses in the Correspondent Node's binding cache.  Moreover, since
   NEMO Basic Support [3] is based on Mobile IPv6, the same issues
   applies to a mobile node acting as mobile router.

   Multihoming issues pertaining to mobile nodes operating Mobile IPv6
   and mobile routers operating NEMO Basic Support are respectively
   discussed [4] and [10] in Monami6 and NEMO Working Group.

   In this document, we thus propose a new identification number called
   Binding Unique Identification (BID) number for each binding cache
   entry to accommodate multiple bindings registration.  We also propose
   extension of binding cache management to store the BID and a new sub-
   option for binding update to carry the BID.  The BID is assigned to
   either the interfaces or Care-of Addresses 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.  There are solutions available in Monami6 WG, for example
   [11].






















Wakikawa, et al.          Expires April 4, 2007                 [Page 6]

Internet-Draft                    MCoA                          Oct 2006


2.  Terminology

   Terms used in this draft are defined in [2], [5] and [6].  In
   addition or in replacement of these, the following terms are defined
   or redefined:

   Binding Unique Identification number (BID)

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

      The BID is conceptually assigned to a binding.  An implementation
      must carefully assign the BID so as to keep using the same BID for
      the same binding even when the status of the binding is changed.
      More details can be found in Section 5.1.

   Binding Unique Identifier sub-option

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

   Bulk Registration

      A mobile node can register multiple bindings by sending a binding
      update.  Several care-of addresses can be stored in a Binding
      Update.  The bulk registration is supported only for home
      registration.  Note that a mobile node should not try to perform
      bulk registration with Correspondent Nodes.














Wakikawa, et al.          Expires April 4, 2007                 [Page 7]

Internet-Draft                    MCoA                          Oct 2006


3.  Protocol Overview

   We propose a new identification number (BID) to distinguish multiple
   bindings pertaining to the same Home Address.  The procedures for the
   mobile node to register multiple bindings are described in the
   paragraphs below.

3.1.  Multiple Care-of Addresses Registration

   Once a mobile node gets several IPv6 global addresses on interfaces,
   it can register these addresses with its Home Agent (home
   registration).  If the mobile node wants to register multiple
   bindings to its Home Agent, it MUST generate a BID for each Care-of
   Address and record it into the binding update list.  The mobile node
   then registers its Care-of Addresses by sending a Binding Update with
   a Binding Unique Identifier sub-option.  The BID MUST be put in the
   Binding Unique Identifier sub-option.  After receiving the Binding
   Update, the Home Agent 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.  Even if
   there is already an entry for the mobile node, the Home Agent MUST
   register a new binding entry for the BID stored in the Binding Unique
   Identifier sub-option.  The mobile node registers multiple Care-of
   Addresses either independently (in individual BUs) or multiple at
   once (in a single BU).

   If the mobile node wishes to register its binding with a
   Correspondent Node, it MUST start 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 uses a BID generated for the home
   registration 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 RFC 3775.  Since
   return routability cannot be verified with multiple care-of addresses
   in a binding update, bulk registration is not supported with
   Correspondent Nodes in this document.

3.2.  Multiple Bindings Management

   The BID is used as a search key for a corresponding entry in the
   binding cache in addition to the Home Address.  When the Home Agent
   checks the binding cache database for the mobile node, it searches a
   corresponding binding entry with the Home Address and BID of the
   desired binding.




Wakikawa, et al.          Expires April 4, 2007                 [Page 8]

Internet-Draft                    MCoA                          Oct 2006


   The desired binding can be selected with policy and filter
   information.  If a mobile node registers a binding with priority
   value, the priority can be a key to select a binding.  The capability
   of searching the desired binding enables load-sharing and QoS with
   flow separation.  However, this selection and flow separation are
   outside the scope of this document.

   If there is no desired binding, it searches the binding cache
   database with the Home Address as specified in Mobile IPv6.  The
   first matched binding entry may be found, although this is
   implementation dependent.

   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 single binding, it just
   sends a Binding Update without a Binding Unique Identifier sub-option
   (i.e. normal Binding Update).  The receiver of the Binding Update
   registers only a single binding for the mobile node.  If the receiver
   has multiple bindings, one binding is registered without BID and 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 the
   proxy neighbor advertisement.  It is impossible to utilize all the
   interfaces when one interface is attached to the home link and the
   others are attached to foreign links.  If the proxy Neighbor
   Advertisement for the Home Address is stopped, packets are always
   routed to the interface attached to the home link.  If proxy is not
   stopped, packets are never routed to the interface attached to the
   home link.  The decision whether a mobile node returns home or not is
   up to implementers.

   The first situation is when a mobile node wants to return home with
   interface attached to the home link.  In this case, the mobile node



Wakikawa, et al.          Expires April 4, 2007                 [Page 9]

Internet-Draft                    MCoA                          Oct 2006


   MUST de-register all the bindings by sending a Binding Update with
   lifetime set to zero.  The mobile node MAY NOT put any Binding Unique
   Identifier sub-option in this packet.  Then, the receiver deletes all
   the bindings from its binding cache database.

   The second situation is when a mobile node does not want to return
   home, though one of its interfaces is attached to its home link.  The
   mobile node disables the interface attached to the home link and
   keeps using the rest of interfaces attached to foreign links.  In
   this case, the mobile node sends a de-registration Binding Update for
   the interface attached to the home link with the Binding Unique
   Identifier sub-option.  The receiver of the de-registration Binding
   Update deletes only the correspondent binding entry from the binding
   cache database.  The Home Agent does not stop proxying neighbor
   advertisement as long as there are still bindings for the other
   interfaces.

   In the above two cases, a mobile node cannot use interfaces attached
   to both home and foreign links simultaneously.  If this is what a
   mobile node wants, a home agent can set up another link other than
   home link and uses the link for the mobile node to return virtually
   to home network.  The detail can be found in Figure 7





























Wakikawa, et al.          Expires April 4, 2007                [Page 10]

Internet-Draft                    MCoA                          Oct 2006


4.  Mobile IPv6 Extensions

   In this section are described the changes to Mobile IPv6 necessary to
   manage multiple bindings bound to a same Home Address.

4.1.  Binding Cache Structure and Management

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

   BID of the Binding Cache Entry

      The BID is notified by the mobile node by means of a Binding
      Unique Identifier sub-option.  The value MUST be zero if the
      Binding Unique identifier does not appear in a Binding Update.

   Priority of the Binding Cache Entry

      The priority is notified by the mobile node by means of a Binding
      Unique Identifier sub-option.

4.2.  Binding Update List Structure and Management

   The following additional items are required for the binding update
   structure, i.e.:

   BID

      The BID MUST be generated whenever the mobile node registers
      multiple bindings for its Home Address.

   Priority

      MUST be set if the priority field of a Binding Unique Identifier
      is valid.

4.3.  Message Format Changes

4.3.1.  Binding Unique Identifier sub-option

   If needed, the Binding Unique Identifier sub-option is included in
   the Binding Update, Binding Acknowledgment, Binding Refresh Request,
   or Binding Error messages.








Wakikawa, et al.          Expires April 4, 2007                [Page 11]

Internet-Draft                    MCoA                          Oct 2006


                      1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Binding Unique ID (BID)   |Priority/Status|C|R| Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       +                                                               +
       +                    Care-of Address (CoA)                      +
       +                                                               +
       +---------------------------------------------------------------+


   Figure 1: BID Sub-Option

   Type

      Type value for Binding Unique Identifier will be assigned later.

   Length

      Length value is 4 when the C flag is unset.  Length value is 20
      when the C flag is set.

   Binding Unique ID (BID)

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

   Priority/Status

      When the Binding Unique Identifier sub-option is included in a
      Binding Update, this field indicates the priority field assigned
      to each binding.  The receiver can utilize this priority to
      determine which binding is used to deliver packets.  The priority
      is 8-bit unsigned integer.  The higher value has higher priority.
      Values of zero and 255 are reserved for specific meaning.

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







Wakikawa, et al.          Expires April 4, 2007                [Page 12]

Internet-Draft                    MCoA                          Oct 2006


      When the Binding Unique Identifier sub-option is included in a
      Binding Acknowledgment, this field indicates the status
      correspondent to each binding in a bulk registration mode.  The
      mobile node can know the registration status of each binding.  The
      status is 8-bit unsigned integer.  The possible status codes are
      listed below.  If the status field is below 128, it indicates that
      the binding registration was successful.



      ACCEPTING BID SUBOPTION (0)

         The registration of the correspond binding is successfully
         operated.

      INCOMPLIANT BID SUBOPTION (128)

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

   Care-of Address (C) flag

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

   Removable (R) flag

      When this flag is set, a mobile node request a Home Agent to
      remove the binding correspondent to BID, even if the binding
      update is not for de-registration.  This flag is valid only when
      bulk registration is used (C flag is set).

   Reserved

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

4.3.2.  Binding Update

   No modification to Binding Update.  A mobile node stores a Binding
   Unique Identifier option in the Mobility Options field of a Binding
   Update.

4.3.3.  Binding Acknowledgment

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



Wakikawa, et al.          Expires April 4, 2007                [Page 13]

Internet-Draft                    MCoA                          Oct 2006


   A receiver who gets a Binding Update with a Binding Unique Identifier
   option MUST reply with a Binding Acknowledgment if the A flag is also
   set.  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 Section 4.3.

   If a Binding Update has 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(s).  There
   are two status fields of multiple care-of address registration: one
   in Binding Acknowledgment and another in Binding Unique Identifier
   sub-option.  The first field indicates the general registration
   status and the latter field gives detail registration information for
   each binding.  The latter field is often used to indicate status
   information for multiple bindings stored in a single binding update
   (i.e. bulk registration).  New status values for the status field in
   Binding Acknowledgment are defined for handling the multiple Care-of
   Addresses registration:

   MCOA CONFLICT(144)

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

   BULK REGISTRATION FAIL (145)

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

   BULK REGISTRATION NOT SUPPORT (146)

      It implies that the bulk binding registration is not supported.

   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.













Wakikawa, et al.          Expires April 4, 2007                [Page 14]

Internet-Draft                    MCoA                          Oct 2006


5.  Mobile Node Operation

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

   There are two cases when a mobile node has several Care-of Addresses:

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

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

   The difference between the above two cases is only a number of
   physical network interfaces and therefore does not matter in this
   document.  The Identification number is used to identify a binding.
   To implement this, a mobile node MAY assign an identification number
   for each Care-of Addresses.  How to assign an identification number
   is up to implementers.

   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 MUST 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.  Binding Registration

   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
   RFC 3775 specification.

   If the mobile node needs to register multiple Care-of Addresses, it
   MUST use BIDs to identify a Care-of Address.  The mobile node puts a
   Binding Unique Identifier sub-option into the Option field of the
   Binding Update.  The BID is copied from a Binding Update List to the
   Binding Unique Identifier sub-option.  No flag in the Binding Unique
   Identifier sub-option should be set for independent binding
   registration.

   If the mobile node registers bindings to a Correspondent Node, it
   MUST sends multiple CoTIs for multiple Care-of Addresses.  After
   getting CoTs, it sends Binding Updates with a Binding Unique
   Identifier sub-option for all Care-of Addresses.  In any case, the



Wakikawa, et al.          Expires April 4, 2007                [Page 15]

Internet-Draft                    MCoA                          Oct 2006


   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 Section 5.7.

5.3.  Binding Bulk Registration

   This bulk registration is an optimization for registering multiple
   Care-of Addresses only to a Home Agent by using a single Binding
   Update, although the current Mobile IPv6 specification does not allow
   to send multiple bindings by means of a single Binding Update.  In
   this case, a mobile node sets the C flag into a Binding Unique
   Identifier sub-option and stores the particular Care-of Address in
   the Binding Unique Identifier sub-option.  The mobile node can store
   multiple sets of a Unique Binding Identifier sub-option in a Binding
   Update.  All the other binding information such as Lifetime, Sequence
   Number, binding Flags are shared among the bulk Care-of Addresses.
   Whether a mobile node registers multiple Care-of Addresses separately
   or not is up to implementations.

   If one of Care-of Address should be removed while the other Care-of
   Address must be updated, a mobile node can set the R flag in a
   Binding Unique Identifier sub-option correspondent to the removed
   Care-of Address.  When the R flag is set, the binding will be removed
   from the binding cache of the Home Agent.  Other bindings for which R
   flag is unset will be registered or updated accordingly.

5.4.  Binding 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.
   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 (e.g. from foreign link), it MUST send
   a Binding Update with lifetime is set to zero.  If only single
   Care-of Address is removed by a Binding Update, the mobile node
   simply sets zero lifetime in a Binding Update and contains the single
   correspondent Unique Binding Identifier Sub-option (C flag must be
   unset).  The receiver will remove only the Care-of Address which is
   retrieved from the Source Address field of the IPv6 header.  On the
   other hand, if the mobile node wants to remove multiple Care-of
   Addresses at once, it stores multiple Unique Binding Identifier sub-
   options which C flag is set in a Binding Update.  The Care-of
   Addresses stored in the Binding Unique Identifier sub-options will
   all be removed.

   If a mobile node wants to remove a binding while it registers the



Wakikawa, et al.          Expires April 4, 2007                [Page 16]

Internet-Draft                    MCoA                          Oct 2006


   other valid bindings, it can use R flag in a Binding Unique
   Identifier sub-option.  The detailed operation can be found in
   Section 5.3.

5.5.  Returning Home

   When a mobile node returns home, it MUST de-register all bindings
   with the Home Agent.

   Although the mobile node MUST delete the bindings with Correspondent
   Nodes as well, the node can still keep the binding of the other
   interface active attached to foreign links at the Correspondent
   Nodes.  In such case, the mobile node still receives packets at the
   other interface attached to a foreign link thanks to route
   optimization.  The mobile node also receives packets at the interface
   attached to the home link when Correspondent Nodes does not use route
   optimization.

   Note that when the mobile node does not want to return home even if
   one of interfaces is attached to the home link, the mobile node MUST
   disable the interface.  Otherwise, address duplication will be
   observed because the Home Agent still defend the Home Address by the
   proxy neighbor advertisement and the mobile node also enables the
   same Home Address on the home link.  After disabling the interface
   attached to the home link, the mobile node MUST delete the binding
   for the interface by sending a de-registration binding update.  The
   de-registration binding update must be sent from one of active
   interfaces attached to foreign links.  As a result, the mobile node
   no longer receives packets at the interface attached to the home
   link.  All packets are routed to other interfaces attached to a
   foreign link.

5.6.  Using Alternate Care-of Address

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

   o  One Care-of Address becomes invalid (e.g because the link where it
      is attached to is no longer available) and MUST be deleted.  In
      such case, the mobile node can not send 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.

   o  A mobile node has multiple interfaces, but it wants to send
      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



Wakikawa, et al.          Expires April 4, 2007                [Page 17]

Internet-Draft                    MCoA                          Oct 2006


      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.

5.7.  Receiving Binding Acknowledgment

   The verification of a Binding Acknowledgment is the same as in Mobile
   IPv6 (section 11.7.3 of RFC 3775).  The operation for sending a
   Binding Acknowledgment is described in Section 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
   Addresses by using a Binding Unique Identifier sub-option.  If the
   originator is the Home Agent, the mobile node MAY try to discover a
   new Home Agent supporting the multiple Care-of Address registration
   or give up with 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
   successfully registered the binding information and BID for the
   mobile node.

   If the status code is not zero and Binding Unique Identifier sub-
   option is in the Binding Acknowledgment, the mobile node proceeds
   with 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 or SHOULD stop sending Binding
   Updates with BID.

   If the status code is 145, the mobile node should check the status
   field of Binding Unique Identifier sub-option for the detail
   information.  After correcting errors, the mobile node can re-
   register only the failed binding in separate registration or bulk
   registration mode.

5.8.  Receiving Binding Refresh Request

   The verification of a Binding Refresh Request is the same as in



Wakikawa, et al.          Expires April 4, 2007                [Page 18]

Internet-Draft                    MCoA                          Oct 2006


   Mobile IPv6 (section 11.7.4 of RFC 3775).  The operation of sending a
   Binding Refresh Request is described in section Section 6.4.

   If a mobile node receives a 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.9.  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 RFC 3775.  The
   operation for sending BE is described in the section 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 performed in Mobile IPv6.






















Wakikawa, et al.          Expires April 4, 2007                [Page 19]

Internet-Draft                    MCoA                          Oct 2006


6.  Home Agent and Correspondent Node Operation

6.1.  Searching Binding Cache with Binding Unique Identifier

   If either a Correspondent Node or a Home Agent has multiple bindings
   for a mobile node in their 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.  If the priority is
   available for a binding cache entry, the priority can be used as
   additional key to search a binding.  In the example below, if a
   Correspondent Node searches the binding with the Home Address and
   BID2, it gets binding2 for this mobile node.



             binding1 [a:b:c:d::EUI,  Care-of Address1,  BID1]
             binding2 [a:b:c:d::EUI,  Care-of Address2,  BID2]
             binding3 [a:b:c:d::EUI,  Care-of Address3,  BID3]



   Figure 2: Searching the Binding Cache

   A Correspondent Node basically learns the BID when it receives a
   Binding Unique Identifier sub-option.  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 for 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 does not have a Binding Unique Identifier, the
   processing of the regular Binding Update is the same as in RFC 3775.
   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 for de-
   registration, the receiver MUST delete all existing bindings for the



Wakikawa, et al.          Expires April 4, 2007                [Page 20]

Internet-Draft                    MCoA                          Oct 2006


   mobile node.

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

   o  A receiver node MUST validate the Binding Update according to
      section 9.5.1 of RFC 3775.

   o  If a Binding Unique Identifier sub-option(s) is present, the
      receiver node MUST process the sub-option.

   o  If the C flag is unset in a Binding Unique Identifier sub-
      option(s), the length field MUST be 4.  Otherwise, the receiver
      MUST return the error code 128 in the status field of the Binding
      Unique Identifier sub-option and send a Binding Acknowledgment
      with status code set to 145 with the Binding Unique Identifier
      sub-option.  When the length field is more than 4, the receiver
      MAY process this sub-option by ignoring the rest of field beyond
      the 4 octets (i.e. after Reserved field).

   o  If the Binding Unique Identifier sub-option is with the C flag set
      and no care-of address is present in the sub-option, the receiver
      node MUST set 128 in the Status field of the Binding Unique
      Identifier sub-option and send a Binding Acknowledgment with
      status code set to 145 with the Binding Unique Identifier sub-
      option.  If either a Correspondent Node or a Home Agent not
      supporting bulk registration receives the Binding Unique
      Identifier sub-option with C flag set, it MUST return the error
      code 146 in a Binding Acknowledgment.

   o  If the Lifetime field is not zero, the receiver node registers a
      binding that includes the BID as a mobile node's binding.

      *  If the C flag is set in the Binding Unique Identifier sub-
         option, the Care-of Address must be taken from the Care-of
         Address in the Binding Unique Identifier sub-option.

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

      *  If the C flag is not set and an alternate care-of address is
         present, the care-of address is taken from the Alternate
         Care-of Address sub-option.

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



Wakikawa, et al.          Expires April 4, 2007                [Page 21]

Internet-Draft                    MCoA                          Oct 2006


      *  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 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 the receiver node found R flag in a Binding Unique
         Identifier sub-option, the C flag must be set.  Otherwise, it
         replies with 128 in a Binding Unique Identifier sub-option and
         set 145 in a Binding Acknowledgment.  The receiver node must
         remove the binding correspondent to the Binding Unique
         Identifier sub-option for which R flag is set.

   o  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
      Acknowledgment to the mobile node, in which the Status field is
      set to 133 (not Home Agent for this mobile node).

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 RFC 3775.  Otherwise, whenever the Binding Unique Identifier 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 an 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 RFC 3775.  The node SHOULD



Wakikawa, et al.          Expires April 4, 2007                [Page 22]

Internet-Draft                    MCoA                          Oct 2006


   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 MAY send a Binding
   Refresh Request.  If the registered binding has BID, the
   Correspondent Node SHOULD contain a Binding Unique Identifier sub-
   option in the Binding Refresh Request.  Then, the Correspondent Node
   can receive a Binding Update with a Binding Unique Identifier sub-
   option and can update only the particular binding.  If the registered
   binding does not have BID, then the Correspondent Node sends a
   Binding Refresh Request without the sub-option.

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

   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 MUST NOT put a
   Binding Unique Identifier sub-option, because there is no binding
   cache entry for the source address.





















Wakikawa, et al.          Expires April 4, 2007                [Page 23]

Internet-Draft                    MCoA                          Oct 2006


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

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

   Since the binding management mechanisms are the same for a mobile
   host operating Mobile IPv6 and for a mobile router operating NEMO
   Basic Support (RFC 3963), our extensions can also be used to deal
   with multiple Care-of Addresses registration sent from a multihomed
   mobile router.





































Wakikawa, et al.          Expires April 4, 2007                [Page 24]

Internet-Draft                    MCoA                          Oct 2006


8.  IPsec and IKE interaction

   TBA
















































Wakikawa, et al.          Expires April 4, 2007                [Page 25]

Internet-Draft                    MCoA                          Oct 2006


9.  Conclusion

   In this document, we propose a solution to achieve multihomed mobile
   node on Mobile IPv6 and Network Mobility.  A binding unique
   identifier is introduced to register multiple care-of addresses to a
   Home Agent and a Correspondent Node.  Those care-of addresses are
   bound to the same home address.  A few modifications to Mobile IPv6
   and NEMO are required to support multiple care-of address
   registration.










































Wakikawa, et al.          Expires April 4, 2007                [Page 26]

Internet-Draft                    MCoA                          Oct 2006


10.  Acknowledgments

   The authors would like to thank Masafumi Aramoto (Sharp Corporation),
   Julien Charbon, Tero Kauppinen (Ericsson), Susumu Koshiba, Martti
   Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen
   (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U),
   Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U),
   Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab.
   at KEIO University, and WIDE project for their contributions.


11.  References

11.1.  Normative References

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

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

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

   [4]  Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
        Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
        draft-ietf-monami6-mipv6-analysis-00 (work in progress),
        February 2006.

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

   [6]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
        draft-ietf-nemo-terminology-05 (work in progress),
        February 2006.

   [7]  Ernst, T., "Network Mobility Support Goals and Requirements",
        draft-ietf-nemo-requirements-05 (work in progress),
        October 2005.

11.2.  Informative References

   [8]   Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
         Networks", Journal Mobile Networks and Applications, vol. 3,
         number 4, pages 335-350, 1998.

   [9]   Ernst, T., "Motivations and Scenarios for Using Multiple



Wakikawa, et al.          Expires April 4, 2007                [Page 27]

Internet-Draft                    MCoA                          Oct 2006


         Interfaces and Global Addresses",
         draft-ietf-monami6-multihoming-motivation-scenario-00 (work in
         progress), February 2006.

   [10]  Ng, C., "Analysis of Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-05 (work in progress),
         February 2006.

   [11]  Soliman, H., "Flow Bindings in Mobile IPv6",
         draft-soliman-monami6-flow-binding-02 (work in progress),
         September 2006.


Appendix A.  Example Configurations

   In this section, we describe typical scenarios when a mobile node has
   multiple network interfaces and acquires multiple Care-of Addresses
   bound to a Home Address.

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

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






















Wakikawa, et al.          Expires April 4, 2007                [Page 28]

Internet-Draft                    MCoA                          Oct 2006


                    +----+
                    | 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 3: Multiple Interfaces Attached to a Foreign Link

   Figure 4 depicts the scenario where MN returns home with one of its
   interfaces.  After the successful de-registration of the binding to
   HA, HA and CN have the binding entries listed in their binding cache
   database of Figure 4.  MN can communicate with the HA through only
   the interface attached to the home link.  On the other hand, the
   mobile node can communicate with CN from the other interfaces
   attached to foreign links (i.e. route optimization).  Even when MN is
   attached to the home link, it can still send Binding Updates for
   other active Care-of Addresses (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.












Wakikawa, et al.          Expires April 4, 2007                [Page 29]

Internet-Draft                    MCoA                          Oct 2006


                    +----+
                    | 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 4: One of Interface Attached to Home Link and Returing Home

   Figure 5 depicts the scenario where MN disables the interface
   attached to the home link and communicates with the interfaces
   attached to foreign links.  The HA and the CN have the binding
   entries listed in their binding cache database.  MN disable the
   interface attached to the home link, because the HA still defends the
   home address of the MN by proxy neighbor advertisements.  All packets
   routed to the home link are intercepted by the HA and tunneled to the
   other interfaces attached to the foreign link according to the
   binding entries.

















Wakikawa, et al.          Expires April 4, 2007                [Page 30]

Internet-Draft                    MCoA                          Oct 2006


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

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


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

   Figure 6 depicts the scenario where multiple interfaces of MN are
   attached to the home link.  The HA and CN have the binding entries
   listed in Figure 6 in their binding cache database.  The MN can not
   use the interface attached to a foreign link unless a CN has a
   binding for the interface.  All packets which arrive at the HA are
   routed to one of the MN's interfaces attached to the home link.


















Wakikawa, et al.          Expires April 4, 2007                [Page 31]

Internet-Draft                    MCoA                          Oct 2006


                    +----+
                    | 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 6: Several Interfaces Attached to Home Link and Returning Home

   Figure 7 depicts the scenario where interfaces of MN are attached to
   the foreign links.  One of foreign link is managed by the home agent.
   The HA and CN have the binding entries listed in Figure 7 in their
   binding cache database.  The home agent advertises a prefix which is
   other than home prefix.  The mobile node will generate a care-of
   address from the prefix and registers it to the home agent.  Even if
   the mobile node attaches to a foreign link, the link is managed by
   its home agent.  It will tunnel the packets to the home agent, but
   the home agent is one-hop neighbor.  The cost of tunnel is
   negligible.  If the mobile node wants to utilize not only an
   interface attached to home but also interfaces attached to foreign
   link, it can use this foreign link of the home agent to return home.
   This is different from the general returning home, but this enable
   the capability of using interfaces attached to both home and foreign
   link without any modifications to Mobile IPv6 and NEMO basic support.













Wakikawa, et al.          Expires April 4, 2007                [Page 32]

Internet-Draft                    MCoA                          Oct 2006


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

     Binding Cache Database:
        Home Agent's binding (Proxy neighbor advertisement is active)
              binding [a:b:c:d::EUI  Care-of Address1  BID1]
              binding [a:b:c:d::EUI  Care-of Address2  BID2]
              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 7: Emulating to Utilize Interfaces Attached to both Home and
   Foreign Links























Wakikawa, et al.          Expires April 4, 2007                [Page 33]

Internet-Draft                    MCoA                          Oct 2006


Appendix B.  Changes From Previous Versions

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

   o  Adding a default value for the BID priority field.  This default
      value is used by the flow binding scheme [11].

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









































Wakikawa, et al.          Expires April 4, 2007                [Page 34]

Internet-Draft                    MCoA                          Oct 2006


Authors' Addresses

   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

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


   Thierry Ernst
   Keio University / WIDE
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan

   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   Email: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/


   Kenichi Nagami
   INTEC NetCore Inc.
   1-3-3, Shin-suna
   Koto-ku, Tokyo  135-0075
   Japan

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














Wakikawa, et al.          Expires April 4, 2007                [Page 35]

Internet-Draft                    MCoA                          Oct 2006


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Wakikawa, et al.          Expires April 4, 2007                [Page 36]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/