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

Versions: 00 01 02 03 04 05

Mobile IP Working Group                                   Ryuji Wakikawa
INTERNET DRAFT                                            Keisuke Uehara
24 June 2003                                               Thierry Ernst
                                            Keio University/WIDE project

          Multiple Care-of Address Registration on Mobile IPv6
               draft-wakikawa-mobileip-multiplecoa-01.txt


 Status of This Memo

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

 Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

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


 Abstract

   This draft proposes extensions of Mobile IPv6 in order to register
   multiple care-of addresses to a home agent and correspondent nodes.
   This draft also targets Network Mobility (NEMO). According to the
   current specification of Mobile IPv6, a mobile node can register only
   one of care-of addresses as its primary care-of address even if the
   mobile node has multiple active care-of address.  However, it is
   useful to get Internet access through multiple access media (i.e.
   care-of addresses) simultaneously in terms of bandwidth, delay,
   and etc.  Our extensions are thus designed to register multiple
   care-of addresses bound to a single home address to a home agent and
   correspondent nodes.  For doing so, we propose a new identification
   number for each interface of a mobile node.  The mobile node


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 1]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   registers a care-of address with the identification number so that
   the receiver can distinguish the binding.

                                  Contents


Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       3

 2. Multiple Network Interface vs Multiple Care-of Address             5

 3. Terminology                                                        5

 4. Protocol Overview                                                  6

 5. Mobile IPv6 Extension                                              7
     5.1. Binding Cache Structure and Management  . . . . . . . . .    8
     5.2. Binding Update Structure and Management . . . . . . . . .    8
     5.3. Messages Format Changes . . . . . . . . . . . . . . . . .    9
           5.3.1. CoA InFormation sub-option  . . . . . . . . . . .    9
           5.3.2. Binding Update  . . . . . . . . . . . . . . . . .    9
           5.3.3. Binding Acknowledgment  . . . . . . . . . . . . .   10

 6. Return Routability Procedure                                      10

 7. Mobile Node Operation                                             12
     7.1. Management of care-of addresses . . . . . . . . . . . . .   12
     7.2. Management of Multiple Care-of addresses on the interface   13
     7.3. Sending Binding Update  . . . . . . . . . . . . . . . . .   13
     7.4. Receiving Binding Acknowledgment with CoAINFO sub-option    14
     7.5. Receiving Binding Refresh Request with CoAINFO sub-option   15
     7.6. Receiving Binding Error . . . . . . . . . . . . . . . . .   15
     7.7. De-registration of one of care-of addresses . . . . . . .   15
     7.8. Movement Detection  . . . . . . . . . . . . . . . . . . .   16

 8. Correspondent Node Operation                                      16
     8.1. Selection of care-of address for outgoing packets . . . .   16
     8.2. How to search the binding cache . . . . . . . . . . . . .   16
     8.3. Receiving Binding Update  . . . . . . . . . . . . . . . .   16
     8.4. Sending Binding Acknowledgment  . . . . . . . . . . . . .   17
     8.5. Sending Binding Refresh Request . . . . . . . . . . . . .   17
     8.6. Sending Binding Error . . . . . . . . . . . . . . . . . .   18

 9. Network Mobility Applicability                                    18

10. Security Consideration                                            18


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 2]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


11. Changes from the version 00                                       19

Acknowledgments                                                       19

References                                                            19

Authors' Addresses                                                    20


 1. Introduction

   Permanent Internet connectivity is required by some applications
   while a mobile node (MN) 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 network.

   Unfortunately, there is no network interface assuring global scale
   connectivity.  Therefore, the MN should use various type of network
   interfaces to obtain wide areas network connectivity [8].  In
   addition, users should select the most appropriate network interface
   depending on the visiting network environment, since wireless
   networks is mutable and less reliable than wired networks and
   each network interface has different cost, performance, bandwidth,
   access range, and reliability.  A user should also select the most
   appropriate interface per communication.  For example, TCP [7]
   communication should be transmitted over wireless interface, but UDP
   communication should be sent over wired interface not to disturb TCP
   connections.

   Associating multiple care-of addresses to a home address would
   enable durable Internet connectivity [9] [1] [10].  For example,
   when a MN loses its Internet connectivity at one of the interface,
   it can use the second interface as a backup interface and still
   keeps connectivity to the network.  In addition, the MN 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 (CNs) can also re-select a binding of MN to
   recover communication when one of MN's CoA becomes invalid.  To put
   binding selection policy to each binding, MN can use a binding for
   specified communication type.  If MN does not have enough bandwidth
   for communications, it can utilize both of bindings to gain network
   bandwidth.  Furthermore, MN may bicast packets through every network
   interfaces for some flow.

   IPv6 [2] conceptually allows a node to have several addresses
   on an interface.  On the other hand, according to section 11.5.3
   of [6], current Mobile IPv6 [6] does not allow a MN to register


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 3]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   multiple care-of addresses bound to a single home address.  If a MN
   sends Binding Update (BU) for each care-of addresses , CNs always
   overwrites the existing binding to the received binding update.  It
   is impossible for a MN to register multiple care-of addresses in CN's
   binding cache.

   Mobile IPv6 [6] has mechanisms to manage multiple ``home addresses''
   based on home agent's managed prefixes such as mobile prefix
   solicitation, mobile prefix advertisement.  The advantage of using
   single home address compared to multiple home addresses assigned to
   each network interface is that applications do not need to be aware
   of the difference in home addresses.  Of course, a MN can assign
   multiple home addresses per network interfaces, but applications
   should be aware of the active home address for communication.  At
   the TCP layer, TCP holds the home address as a source address of the
   communication for connection managements.  Thus, applications must
   reboot to reset the connection information when the the MN changes
   the active network interface (i.e.  change the home address).

   In this document, we thus propose a new identification number called
   IFID and a priority value (IFPRI) for each interface to accommodate
   multiple care-of addresses.  We also propose extension of binding
   cache management to store IFID, new sub-options for binding update
   to carry IFID. MN assigns an IFID and an IFPRI to either a single
   or multiple network interfaces bound to a single home address in
   Mobile IPv6.  MN notifies the IFID and the IFPRI to both HA and CN
   by BU. CN and HA record the IFID and the IFPRI into their binding
   cache database.  Therefore, CNs and HA distinguish multiple care-of
   addresses by using the IFID. A home address identifies a mobile node
   itself and the IFID identifies each network interfaces installed in
   a mobile node.  A user of a mobile node may be able to bind some
   policies to the IFID. The policy is used to divide flow to multiple
   network interfaces by flow type, port number, or destination address,
   etc.  How to distribute or configure policy is currently out of scope
   in this draft.

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


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 4]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


 2. Multiple Network Interface vs Multiple Care-of Address

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

    -  MN uses several physical network interfaces to acquire a care-of
       address.

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

   The difference between above two cases is a number of physical
   network interfaces.  This draft basically handles the several network
   interfaces.  To accommodate the second situation, this document
   treats single interface as MN pseudoly having multiple network
   interfaces.  (i.e.  if MN has multiple care-of addresses at the
   single interface, Mobile IPv6 treats each care-of address is assigned
   to each pseudo interface.)  For example, MN obtained care-of address1
   and care-of address2 at interface-A, MN treats this like:  care-of
   address1 is assigned to interface-A and care-of address2 is assigned
   to pseudo-interface-B. If care-of address1 is deleted due to the
   expiration of router lifetime, MN removes the pseudo interface-B. The
   more protocol operation is described in the section 7.2.


 3. Terminology

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

      InterFace IDentification number (IFID)

         The identification number which is used to distinguish
         each interface on MN. IFID is assigned to each interface,
         and generated randomly not to duplicate each other.  If an
         interface has multiple care-of addresses, then MN can assign
         IFID to a pseudo interface.  MN has to assign different IFID
         for each destination node.  This is for security policy.  If MN
         uses same IFID to all destination nodes, it will always reveal
         all interface information to all nodes.  MN sometime hides some
         of interface from specific destination nodes.

      InterFace PRIority (IFPRI)

         The priority value can be used to select a care-of address
         on CN. The care-of address which has the highest priority is
         the primary care-of address.  Lower value indicates higher
         priority.  Zero indicates primary interface.  If an interface


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 5]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


         has multiple care-of addresses, then MN can assign IFPRI to
         each care-of address.

      Primary InterFace (P-IF)

         The interface which is assigned a primary care-of address.
         Once the primary interface goes invalid due to movements,
         MN MUST reselect primary interface from set of interfaces
         installed in MN.

      Non-Primary InterFace(NP-IF)

         The interface which is NOT assigned the primary care-of
         address.

      Primary care-of address (P-CoA)

         The primary care-of address is defined as ``the care-of address
         registered with the MN's home agent is called its ``primary''
         care-of address'' in [6].

         In this draft, the definition is extended as follows.  The
         care-of address which is primary associated with a home address
         and is assigned to a P-IF. MN MUST have PCoA all the time.
         Once PCoA goes invalid, MN MUST reselect PCoA from the multiple
         care-of addresses that a MN may have at any given time.

      Non-Primary care-of address (NP-CoA)

         The care-of address which is NOT selected as primary (i.e.
         ``non-primary'' CoA).

      Care-of Address Information sub-option (CoAINFO)

         The CoA information sub-option is used to notify IFID and IFPRI
         with BU.

      Multiple Care-of Addresses Flag (M flag)

         A flag which indicated a CoAINFO sub-option is included in the
         BU's mobility option field.


 4. Protocol Overview

   We propose a new identification number (IFID) for each interface.
   Once a MN gets several CoAs on distinct interfaces, it MUST select a
   primary CoA from active CoAs as specified in Section 11.5.3 of  [6].


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 6]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   After the selection, the interface which has the primary CoA becomes
   the primary interface on the MN.

   When a MN acquires multiple care-of addresses for a home address, it
   SHOULD notify all of them to CN. Even when a CoA goes invalid, CN
   still have another registered CoA for the MN. Thus, CN can switch
   to an active CoA as soon as it detects CoA's invalidation.  CN can
   detect CoA's invalidation by packets loss or ICMP error messages
   such as ICMP_UNREACHABLE. If the MN does not have enough bandwidth
   for outgoing packets, the MN can utilize multiple network interfaces
   simultaneously, and divide flow to each network interface.

   The MN registers only its primary CoA to its Home Agent (HA) as the
   home registration.  After the home registration, the MN MAY send BU
   to CNs through Return Routability (RR) procedure.  The MN starts
   to send HoTI and CoTI for the primary CoA. If the MN has another
   non-primary CoA, it also sends CoTI for the non-primary CoA which can
   be assigned to any interface.  This CoTI is sent with the non-primary
   CoA set to the source address field of the IPv6 header.  The MN MUST
   add CoAINFO sub-option containing IFID and IFPRI of the interface
   which is assigned to the target CoA in each CoTI message.  These
   values are securely notified to CNs by RR operations.  After getting
   HoT and CoT for either primary CoA or non-primary CoA, the MN sends
   BU with IFID and IFPRI for the CoA which is authenticated by CoT. To
   register both CoAs to CNs, the MN MUST sends BUs for each CoA.

   When a CN receives a BU with a CoAINFO sub-option containing an IFID
   and an IFPRI, it checks binding cache for the home address and the
   IFID stored in the CoAINFO sub-option.  If both are matched, the CN
   updates the binding with the new CoA (stored in the BU). Otherwise,
   it creates new binding for the home address and the IFID even if it
   has already had a binding for the same home address, because the
   recorded IFID is different from the requesting IFID.

   Whenever the MN moves and changes the CoA for a given interface, it
   MUST send BU with the IFID of the changed interface.  MN can always
   update the particular CoA with the IFID. When the MN returns home, it
   MUST de-register all the bindings by BU which lifetime set to zero
   regardless of availability of another care-of addresses.  When MN
   detects that the primary interface is attached to the home link, it
   indicates MN's returning home.


 5. Mobile IPv6 Extension

   Mobile IPv6 should be able to manage multiple care-of addresses.  The
   changes are described in this section.


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 7]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


 5.1. Binding Cache Structure and Management

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

    -  IFID
       The IFID of the registered care-of address.  The IFID is notified
       by BU sent by MN. The IFID is protected by return routability
       procedure described in section 6.

    -  IFPRI
       The IFPRI of the registered care-of address.  The priority is
       notified by BU. Whenever a BU is received, the priority value
       MUST be overwritten to newest one.  The IFPRI is also protected
       by return routability procedure described in section 6.

   If a node gets a BU with a CoAINFO defined at 5.3.1, it searches
   Binding Cache entries with the set of the home address and the IFID.
   If both does match with the registered binding, the node MUST update
   the CoA and the IFID into the matched binding.  Otherwise, the node
   MUST register a new binding for the CoA and the IFID, even if there
   are already the other binding for the MN's home address.


 5.2. Binding Update Structure and Management

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


    -  IFID
       The IFID of the care-of address MUST be recorded in the binding
       update list.

    -  IFPRI
       The priority of the care-of address MUST be recorded in the
       binding update list.

   If MN has multiple care-of addresses at a time, it SHOULD assign a
   IFID and a IFPRI to each care-of address.  The IFID and the IFPRI
   should be recorded in the binding update list.  MN SHOULD update
   the value of the IFID periodically not to be discovered by a third
   person.  The value of IFPRI can be changed at any time.


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 8]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


 5.3. Messages Format Changes

 5.3.1. CoA InFormation sub-option

   The CoAINFO sub-option can be included in Binding Update, Binding
   Acknowledgment, Binding Refresh Request, Binding Error if needed.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |   Type = TBD  |   Length = 2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     IF ID     |     IFPRI     |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+

      Type
             Type value for CoAINFO will be assigned later.

      Length
             The value MUST be always 2.

      IFID
             The IFID of the care-of address which is notified by this
             BU with CoAINFO.

      IFPRI
             The IFPRI of the care-of address which is notified by this
             BU with CoAINFO.

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


 5.3.2. Binding Update

   If MN wants to register several CoAs which would be bound to a
   home address, MN MUST set 'M' flag and include the CoA information
   sub-option.  The sub-option is constructed according to the binding
   update list.


R. Wakikawa et.al.              Expires 24 Dec 2003             [Page 9]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


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

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

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

      Reserved
           Reserved field is reduced to 11 bits.


 5.3.3. Binding Acknowledgment

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

   The receiver who gets binding update with 'M' flag MUST reply BA if
   'A' flag is set or BU is for home registration.  The receiver MUST
   also reply BA with correspondent error number if it finds some error
   during processing BU and its sub-option described in section 5.3.2.

   If a BU has 'M' flag and a CoAINFO sub-option, a CN MUST reply
   BA containing the CoAINFO sub-option.  To include the CoAINFO
   sub-option, the sender (i.e.  MN) can process the BA for the target
   CoA specified by the CoAINFO sub-option.

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

     1 Successful registration of NP-CoA


 6. Return Routability Procedure

   The CoTI and CoT messages transaction must be modified to secure the
   CoAINFO sub-option.  Therefore, this draft describes only CoTI and
   CoT, because both HoTI and HoT are not modified at all.  Processing
   of HoTI and HoT can be found at [6].


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 10]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


     Mobile node                 Home agent           Correspondent node
          |                                                     |
          |  1b.                                                |
          |  Care-of Test Init(CoTI)                            |
          |  Src = care-of address                              |
          |  Dst = correspondent                                |
          |  Parameters:                                        |
          |     - care-of init cookie                           |
          |     - care-of address ID                            |
          |     - care-of address Priority                      |
          |---------------------------------------------------->|
          |                                                     |
          |                             2b.                     |
          |                             Care-of Test(CoT)       |
          |                             Src = correspondent,    |
          |                             Dst = care-of address   |
          |                             Parameters:             |
          |                              - care-of init cookie  |
          |                              - care-of keygen token |
          |                              - care-of nonce index  |
          |<----------------------------------------------------|
          |                                                     |


   1b. Care-of Test Init
       The MN sends a Care-of Test Init message to the correspondent
       node to acquire the care-of keygen token.  The contents of this
       message can be summarized as follows:

           Src = care-of address

           Dst = correspondent

           Parameters:

            +  care-of init cookie

            +  care-of address ID (IFID)

            +  care-of address Priority (IFPRI)

       The second message conveys the MN's care-of address to the
       correspondent node.  The MN also sends along a care-of init
       cookie that the correspondent node must return later.  The
       Care-of Test Init message is sent directly to the correspondent
       node.


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 11]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   2b. Care-of Test
       This message is sent in response to a Care-of Test Init message.
       The contents of the message are:

           Src = correspondent

           Dst = care-of address

           Parameters:

            +  care-of init cookie

            +  care-of keygen token

            +  care-of nonce index

       The correspondent node also sends a challenge to the MN's care-of
       address.  When the correspondent node receives the Care-of Test
       Init message, it generates a care-of keygen token as follows:


           care-of keygen token = First (64, MAC (Kcn, (care-of address
           | IFID | IFPRI | nonce)))

       The keygen token is formed from the first 64 bits of the MAC
       result, and sent directly to the MN at its care-of address.  The
       care-of init cookie from the from Care-of Test Init message is
       returned to ensure that the message comes from a node on the
       route to the correspondent node.

       The care-of nonce index is provided to identify the nonce used
       for the care-of keygen token.  The home and care-of nonce indices
       are often the same in the Home and Care-of Test messages.


 7. Mobile Node Operation

 7.1. Management of care-of addresses

   A MN assigns IFPRI to each interface according to user's policy or
   administrative policy.  If the MN has only single interface, it
   assigns ``zero value'' to the interface as P-IF.

   A MN also assigns IFID to each interface.  The value should be
   randomly generated and assigned to each interface.  If the MN has
   single interface, assignment of IFID to the interface is not needed
   until it has multiple interfaces.


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 12]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   A MN MUST handle P-CoA normally as described in base Mobile IPv6
   [6].  For example, ``home registration to HA'' and ``returning home''
   is proceeded without any changes to Mobile IPv6 (i.e.  same as the
   section 11.7.1 and the section 11.5.4 of [6]).  P-CoA MUST be the
   care-of address on P-IF all the time.

   A MN MUST manage multiple NP-CoA per NP-IF. Whenever the MN detects
   the change of a NP-CoA by the prefix comparison between the NP-CoA
   and received router advertisements sent by routers, it MUST start
   appropriate operations such as updating the binding, de-registering
   the binding, etc.


 7.2. Management of Multiple Care-of addresses on the interface

   If MN obtains several care-of address on an interface, MN has to
   select an address as the P-CoA from the set of addresses.  If MN
   wants to register several care-of address on the same interface,
   MN has to assign the ID to each of care-of address temporarily and
   register the address by BU with CoAINFO sub-option.  Once the address
   is deleted from the interface, MN MUST de-register the address by
   sending BU with lifetime zero and correspond CoAINFO sub-option.  The
   ID assigned to a CoA is available until the CoA is active.  Whenever,
   the CoA changed, the MN MUST de-register the older CoA and the older
   ID and MUST assign a new ID for the new CoA.


 7.3. Sending Binding Update

   When a MN sends a BU to its home agent (i.e.  home registration), the
   MN should choose the P-CoA for home registration.  The MN SHOULD NOT
   register multiple CoAs to the HA with CoAINFO sub-options.  The MN
   SHOULD operate the home registration as Mobile IPv6 described in [6].

   When the MN sends a BU to CNs, it MUST decide whether it registers
   multiple CoAs to the CN or not.  However, this decision is out-of
   scope in this document.

    -  General Mobile IPv6
       If the MN decides not to register multiple CoAs to the CN, it
       just starts RR and sends BU using the home-registered P-CoA
       according to  [6].

    -  RR procedure for P-CoA
       On the other hand, if the MN need to register multiple CoAs
       to the CN, the MN first attempts to process registration of
       its P-CoA to the CN. The MN sends HoTI, and CoTI with CoAINFO
       sub-option.  In the CoAINFO sub-option, the MN puts a randomly
       generated IFID and a IFPRI set to zero (to indicate primary).


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 13]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


       These values MUST be recorded into the binding update list.  An
       IFID and an IFPRI for each interface MAY be configured beforehand
       by users.

    -  Registration of P-CoA to a CN
       Once the MN receives HoT and CoT from the CN, it prepares
       for the BU. The BU must be constructed with 'M' flag and
       contain a CoAINFO sub-option.  The detail of BU is described in
       section 5.3.2.  The value of CoAINFO sub-option is copied from
       the binding update list.  Finally, the MN sends the BU to the
       CN. The MN MUST wait a BA from the CN to confirm successfully
       registration as described in section 7.4

    -  Registration of NP-CoAs to the CN
       After registration of the P-CoA, the MN start processes of NP-CoA
       registration.  It sends CoTI with a CoAINFO sub-option and MAY
       send HoTI as well.  Since the MN has already received HoT from
       the CN, sending HoTI CAN be skipped.  When the value of the
       CoAINFO sub-option for CoT is set, these values MUST be recorded
       to the binding update list.  After receiving CoT, it makes BU
       including CoAINFO sub-option and 'M' flag.  The value of CoAINFO
       sub-option is copied from the binding update list.  The MN MUST
       wait a BA from the CN as described in section 7.4.  The MN repeat
       this operations for all possible care-of addresses.


 7.4. Receiving Binding Acknowledgment with CoAINFO sub-option

   Verification of Binding Acknowledgment is same as Mobile IPv6
   (section 11.7.3 of [6]).  The operation except for the text below
   is described in the [6].  The operation of sending BA is described
   in 8.4.

   If MN sends BU with a CoAINFO sub-option, BA MUST contain the CoAINFO
   sub-option.  If BA does not have the CoAINFO sub-option, the CN might
   not recognize CoAINFO sub-option.  The MN SHOULD stop registering
   multiple care-of addresses by CoAINFO sub-option.

   If BA has the CoAINFO sub-option and the success status value (i.e.
   1), it indicates successful registration of the care-of address which
   IFID is in the CoAINFO sub-option.

   If the BA's status code is zero (indicating successfully registration
   in Mobile IPv6 [6]) regardless of CoAINFO sub-option availability in
   BA, the MN MAY stop attempting multiple binding registration to the
   CN. The successful status code is ``1'' on this document, therefore
   the CN may not registered multiple care-of addresses respectively.
   (i.e.  CN overwrites the existing binding to the received BU)


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 14]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   If the status field does not indicate success registration (i.e.
   more than 128), it SHOULD stop registering the care-of address which
   IFID is in the CoAINFO sub-option.


 7.5. Receiving Binding Refresh Request with CoAINFO sub-option

   Verification of Binding Refresh Request is same as Mobile IPv6
   (section 11.7.4 of [6]).  Operation except for text below is
   described in the [6].  The operation of Sending Binding Refresh
   Request (BRR) is described in the section 8.5.

   If CN receives a BRR with a CoAINFO sub-option, this BRR indicates
   BRR for the interface of IFID stored in the CoAINFO sub-option.  The
   MN MAY send BU for the care-of address which is assigned to the
   interface.

   If BRR does not contain a CoAINFO sub-option and if the MN has
   the binding update list for the requesting node, the MN sends BU
   according to the binding update list.  On the other had, if the MN
   does not have any binding update list for the requesting node, the MN
   sends BU according to the section 7.3.


 7.6. Receiving Binding Error

   When a MN receives BE with a CoAINFO sub-option, the BE is for the
   interface which IFID is stored in the CoAINFO sub-option.  Further
   operations except for the text below are same as  [6].  The operation
   of sending BE is described in the section 8.6.

   If the message Status field is 2 (unrecognized MH Type value)
   regardless of CoAINFO sub-option availability, the MN should stop
   sending CoAINFO sub-option to the CN. Instead, the MN should register
   only P-CoA to the CN.


 7.7. De-registration of one of care-of addresses

   When a MN need to de-register one of care-of address, it sends a BU
   with a CoAINFO sub-option to the CN. The BU MUST contain the lifetime
   specified as zero and specify a Care-of address that matches the
   home address for the binding.  The CoAINFO sub-option MUST contain
   IFID and IFPRI of the target interface.  Otherwise, the CN can not
   determine which binding should be deleted for this de-registration if
   there are multiple bindings for the home address.

   If a MN decided to delete all the binding from the CN, it sends
   normal de-registration BU to the CN (i.e.  exclusion of the CoAINFO


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 15]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   sub-option from the above operation).  see the section 8.3 for
   details.


 7.8. Movement Detection

   If the new visiting network is not the home link, the MN just updates
   the CoA (either P-CoA or NP-CoA). If one of the interface changes the
   attached network and gets a different CoA regardless of primary or
   not, MN must register the new CoA to CNs with a CoAINFO sub-option.

   Whenever the P-IF is attached to the home link, the MN sends BU for
   de-registration to the HA and CNs.  If the NP-IF is attached to the
   home link, MN de-register NP-CoAs attached to the information of
   NP-IF to CNs, but it SHOULD NOT de-register the binding for the P-CoA
   to the HA and CNs.


 8. Correspondent Node Operation

 8.1. Selection of care-of address for outgoing packets

   If the CN registers multiple care-of addressed for a home address
   in its binding cache, it can use any of the binding for outgoing
   communication to the registering MN.

   The selection of the best CoA is out of scope in the present
   document.  However, the CN MAY decide to choose the best binding by
   the comparison of each registered priority value.


 8.2. How to search the binding cache

   Whenever the CN searches the binding cache for the home address, it
   SHOULD uses both the home address and an IFID as a key of search if
   it knows IFID. The CN basically knows an IFID when it receives an
   CoAINFO sub-option.  At the time, the CN MUST look up the binding
   cache with the home address and the IFID retrieved from the CoAINFO
   sub-option.

   If the CN does not know the IFID, the CN search the binding with only
   the home address as well as base Mobile IPv6.  The CN can ignore the
   knowing IFID, if it does not desire to use.


 8.3. Receiving Binding Update

   If the received a BU does not contain a CoAINFO sub-option or does
   not have 'M' flag set, the processing of the BU is same as [6].  But


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 16]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   if the CN has already registered multiple care-of addresses for the
   home address, the CN MUST overwrite the binding for the home address
   with the received BU. After receiving the BU which does not contain
   a CoAINFO sub-option, the CN MUST have only a binding for the home
   address.

   The CN MUST validate the BU and the CoAINFO sub-option according
   to the section 9.5.1 of [6].  If the received a BU contain a
   CoAINFO sub-option or has 'M' flag set, the receiving node MUST
   operate additional validation for the BU and the CoAINFO sub-option
   additionally.

   If the BU has 'M' flag at the flag field, it MUST contain a CoAINFO
   sub-option.  If it does not contains a CoAINFO sub-option, the CN
   MUST silently drop the BU. If the CoAINFO sub-option is present, the
   CN MUST register the IFID and the IFPRI to the MN's binding.

   If the CN has already registered the binding for the home address and
   IFID, then it MUST update the care-of address of the binding and the
   IFPRI.


 8.4. Sending Binding Acknowledgment

   After processing the BU described in 8.3, the CN MUST reply BA either
   when the 'A' bit is set to the BU or when the CN find an error during
   processing BU described in [6].

   If the BU does not contain a CoAINFO sub-option, the CN MUST reply BA
   according to the section 9.5.4 of [6].  Otherwise, the CN MUST follow
   the procedure below.

   If the CN successfully registered the care-of address which
   identified in CoAINFO sub-option, it returns BA with status set to
   '1' (Successfully registration of NP-CoA) and the CoAINFO sub-option
   copied from the BU.

   If the CN encountered an error during processing BU, it must returns
   BA with appropriate error number described in [6].  The CN MAY attach
   the CoAINFO sub-option to notify the dropped interface to the MN.


 8.5. Sending Binding Refresh Request

   When a CN notices that the registered binding will expire soon, it
   SHOULD send BRR. If the registered binding has IFPRI and IFID, the CN
   SHOULD contain CoAINFO sub-option in BRR. Then, the CN can receive BU
   with CoAINFO sub-option and update only the target binding.  If the


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 17]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


   registered binding does not have IFPRI and IFID, then the CN sends
   normal BRR.


 8.6. Sending Binding Error

   When a CN receives BU with an CoAINFO sub-option, it verifies the BU
   according to the [6].  If the CN does not understand either the 'M'
   flag or CoAINFO sub-option, it MUST return BE to the sender MN with
   the status specified to '1'(Unrecognized MH Type value).

   If the CN receives data packets with the home address destination
   option, it MUST verify the IPv6 source address field.  If the source
   address is not registered in the CN's binding cache, the CN MUST
   return BE to the sender MN with the status set to zero (Unknown
   binding for Home Address destination option).  Then, the MN MAY send
   BU (with a CoAINFO sub-option) to register the new binding.


 9. Network Mobility Applicability

   This draft can be applied to the basic network mobility support
   protocol [3] proposed in the NEMO working group.  Multihoming is
   required as R12 (The solution MUST function for multihomed MR and
   multihomed mobile networks...)  in [4].  Since binding managements
   are same as Mobile IPv6, both a mobile router and a home agent
   can support this draft to deal with multiple care-of addresses
   registration in terms of a multihomed mobile router.


 10. Security Consideration

   The information of a CoAINFO can be protected by RR procedure.  MN
   adds the CoAINFO in CoTI. CN calculates a CoA keygen token based on
   the MN's care-of address, the information of the CoAINFO (IFID and
   IFPRI), and the CN's nonce.  CN sends the CoA keygen token by CoT.
   MN uses the CoA keygen token to calculate the authentication data
   and puts the data to the authentication data sub-option.  CN always
   verify the information of the CoAINFO by comparison of authentication
   data sub-option.


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 18]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


 11. Changes from the version 00

    -  Corrected composition and grammatical errors.

    -  Update the packet format of Binding Update due to R-bit proposed
       by NEMO basic support.

    -  Clarify to support a NEMO Mobile Router, too.


 Acknowledgments

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


 References

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

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

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

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

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

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

    [7] J. Postel.  Transmission Control Protocol.  Request for Comments
        (Standard) 793, Internet Engineering Task Force, September 1981.


R. Wakikawa et.al.             Expires 24 Dec 2003             [Page 19]


Internet Draft     Multiple Care-of Address Registration    24 June 2003


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

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

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


 Authors' Addresses


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


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


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