NEMO Working Group                                           M. Kumazawa
Internet-Draft                                               Y. Watanabe
Expires: January 7, 2005                                    T. Matsumoto
                                                            S. Narayanan
                                                               Panasonic
                                                            July 9, 2004


    Token based Duplicate Network Detection for split mobile network
                           (Token based DND)
                    draft-kumazawa-nemo-tbdnd-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 7, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   When multiple Mobile Routers share the same prefix, a Home Agent must
   be able to verify whether the mobile routers are in the same Mobile
   Network or not.  Otherwise, the Home Agent may not be able to forward
   a data packet to the correct recipient since it may not be connected
   to the mobile router the home agent chooses to forward the packet.
   This document describes a Token based Duplicate Network Detection



Kumazawa, et al.        Expires January 7, 2005                 [Page 1]


Internet-Draft              Token based DND                    July 2004


   mechanism that enables a home agent to detect whether the mobile
   rotuers claiming the same prefix are in the same mobile network.

















































Kumazawa, et al.        Expires January 7, 2005                 [Page 2]


Internet-Draft              Token based DND                    July 2004


1.  Introduction

   Today, Mobile Internet Access using third generation network and the
   use of public Internet access services by Wireless LAN is gaining in
   popularity.  Various new access technologies will emerge in the near
   future.  This leads to the demand for ubiquitous networking, where
   portable devices can be connected to the Internet anywhere, at any
   time.  To realize ubiquity, it is necessary to select from the
   various access networks available the network most suitable for
   mobile Internet access according to the user's location and
   situation.  However, it is difficult to add various wireless
   interfaces to all portable devices for reasons of cost and size.

   Wireless PAN (W-PAN) is one of possible solutions enabling ubiquity.
   In W-PAN portable devices with short distance wireless interfaces are
   connected and some of them have additional access interfaces and
   provide connectivity to the Internet.  Devices with such Internet
   access interfaces need to provide session continuity of all nodes in
   W-PAN even when they change points of attachement to the Internet.

   The Nemo Basic Support [2] provides the mobility of an entire
   network.  It realizes session continuity to all nodes in the Mobile
   Network by maintaing bi-directional tunnels between mobile routers
   and a Home Agent.  Devices with Internet access interfaces in W-PAN
   act as Mobile Routers.  Mobile networks with mulitple mobile routers
   providing multiple points of attachments to the Internet are called
   Multihomed Mobile Network[1][3].  Mobile Routers are required to
   construct just one logical network even though the physical mobile
   router providing connectivity to the Internet could vary based on
   location.  This means that multiple mobile router in the same mobile
   network may have to claim the same prefix.  This kind of
   configuration is introduced as (N,*,1) in [1].  However, this
   configuration has an issue.  In the Nemo Basic Support protocol, a
   Home Agent can't know whether Mobile Routers claiming the same prefix
   are in the same Mobile Network or not.  So, correct recipient may not
   be connected to the Mobile Router the Home Agent chooses to forward
   packets.  This problem is called "split mobile network" and the
   solution to detect split mobile network is called Duplicate Network
   Detection (DND) and they have been discussed in NEMO working group
   mailing list [5].

   The solution described in this document requires sharing of a token
   corresponding to a Mobile Network Prefix between Mobile Routers
   within a network and a Home Agent.  Since the token is updated
   periodically, Mobile Routers which exist outside or move away can't
   obtain it and share the prefix.





Kumazawa, et al.        Expires January 7, 2005                 [Page 3]


Internet-Draft              Token based DND                    July 2004


2.  Terminology

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

   Owner
      A Mobile Router which owns a Mobile Network prefix (ex.
      manual-configured or obtained with DHCP)

   Borrower
      A Mobile Router which borrows a Mobile Network prefix from the
      owner.

   Token
      It is a random number created, or updated by an owner or a Home
      Agent.  A token is set in a token option in a Binding Update
      message when the owner creates or a Binding Acknowledgement
      message when the Home Agent creates.  A token is distributed with
      a Mobile Network prefix from the owner to borrowers.  A token is
      used for Home Agent to confirm whether the borrowers are connected
      to the owner or not.





























Kumazawa, et al.        Expires January 7, 2005                 [Page 4]


Internet-Draft              Token based DND                    July 2004


3.  Overview

   Figure 1 shows an example network for describing  overview of the
   operation.


                +----+
                | HA |
                +--+-+
                   |
                +-----------------------+     +------+
                |        Internet       |-----+  CN  |
                +-----------------------+     +------+
                    |               |
                 +-----+         +-----+
                 | MR1 |         | MR2 |
                 +--+--+         +--+--+
                    |               |
                 ----------------------- 1::
                             | 100
                          +--+--+
                          | LFN |
                          +-----+

                       Figure 1: example network

   A LFN is connected to a Mobile Network whose prefix is 1::, and the
   Mobile Network is connected to the Internet via two mobile routers
   MR1 and MR2.  This example assumes that both mobile routers register
   to the same Home Agent.  Hence this document describes only (N,1,1)
   [1] case.  (N,N,1) [1] would need some inter Home Agent protocol, and
   the Token based DND would work with such protocol.  In this example,
   MR1 acts as an owner of 1:: and MR2 as a borrower of 1::.

3.1  Registration as an Owner

   MR1 sends a Binding Update message to the Home Agent when it attaches
   to a new access router.  MR1 sets a Prefix Delegated flag (D) to zero
   to indicate that it is an owner of 1:: and puts a token option to
   indicate that 1:: can be shared with other mobile routers having a
   correct token in the message.  The token may be generated by either
   the owner (MR1) or the Home Agent.  If MR1 generates a token, it is
   set in the token option, or if MR1 requests the Home Agent to create
   a token, MR1 sets the token to zero in the option.

   When a Home Agent receives a Binding Update message, it searches its
   binding cache and prefix table if any.  If the Home Agent doesn't
   find any other owner of the same prefix (1:: in this example) in the



Kumazawa, et al.        Expires January 7, 2005                 [Page 5]


Internet-Draft              Token based DND                    July 2004


   binding cache or prefix table, the Home Agent acknowledges the
   Binding Update by sending a Binding Acknowledgement with status '0'
   to MR1.  When the token is set to zero in the Binding Update, Home
   Agent generates a token and sets it in the token option in the
   Binding Acknowledgement message.  A token option is included in a
   Binding Acknowledgement message regardless of the value in a
   corresponding Binding Update, to indicate that the Home Agent
   interprets a token option in the Binding Update and is aware of Token
   based DND.

   MR1 receives the Binding Acknowledgement message and confirm whether
   it includes a token option or not.  If the message doesn't include
   token option, MR1 concludes that the Home Agent is not aware of Token
   based DND, and operates without Token based DND.  MR1 starts
   advertising 1:: and a corresponding token with router advertisement
   message in the Mobile Network when it receives a Binding
   Acknowledgement message including a token option.  The Router
   Advertisement multicasted from MR1 includes a prefix option of 1::
   and a token option.

   LFN configures its address (1::100 in this example) in the first
   reception of a router advertisement message with a prefix option and
   begins communication with CN.


   MR2(Borrower)                   MR1(Owner)                       HA
    |                               |                               |
    |                               |-----BU [1::, token,owner]---->|
    |                               |                               |
    |                               |<-----BA [status=0,token]------|
    |                               |                               |
    |                               |=====bi-directional tunnel=====|
    |<--------RA[1::,token]---------|                               |

              Figure 2: sequence: Registration as an Owner

   Figure 2 shows the sequence MR1 registers as an owner.  This section
   assumes that MR1 (owner) generates and updates tokens.

   If a Home Agent finds that another owner of 1:: already registers,
   the Home Agent rejects the Binding Update from MR1 and sets status to
   '141' (Invalid Prefix) in a corresponding Binding Acknowledgement
   message.

3.2  Registration as a Borrower

   When MR2 receives a Router Advertisement message with prefix option
   including 1:: and a token option from MR1, MR2 sends a Binding Update



Kumazawa, et al.        Expires January 7, 2005                 [Page 6]


Internet-Draft              Token based DND                    July 2004


   message with a token option and a Mobile Network Prefix option
   including 1:: and sets the Prefix delegated flag (D) to 1 to indicate
   that it borrows 1:: to the Home Agent.  MR2 sets the token received
   from MR1 in the Binding Update to indicate that it borrows 1:: from
   MR1.

   When a Home Agent receives the Binding Update from MR2, it compares
   the token of the MR2 and the token registered by MR1.  If they are
   the same, the Home Agent acknowledges the Binding Update and sends
   Binding Acknowledgement with status '0' and a token option.  If they
   are different or the prefix in the Binding Update from MR2 is not
   registered by any owner, the Home Agent rejects it and sets the
   status 141 (Invalid Prefix) of Binding Acknowledgement.

   There are now two mobile routers MR1 and MR2 which claim 1:: in the
   Binding Cache in the Home agent, and the Home Agent chooses one based
   on various policies (eg.  load balancing) when forwarding packets for
   LFN.

   Now, while both MR1 and MR2 MUST advertise the prefix in their router
   advertisment messages, MR2 MUST NOT include the token option in its
   router advertisment messages.  Only the owner of the prefix is
   allowed to advertise the corresponding token.

3.3  Refreshment of Token

   The token is updated periodically and exchanged between a Home Agent
   and the owner.  After MR1 receives a Binding Acknowledgement with a
   token option and realizes that re-binding and update of the token has
   finished successfuly, it includes the updated token in Router
   Advertisement messages.

   When MR2 finds the token updated, it sends a Binding Update message
   with the new token to the Home Agent.

   If MR2 moves away from the mobile network and Router Advertisement
   messages from MR1 do not reach it, it can't follow token updates.
   After a token is updated, Binding Update messages with old tokens are
   rejected by a Home Agent.  Since MR2 can't re-register to the Home
   Agent to update its Binding, the entry of MR2 in the Home Agent will
   expire.  Figure 3 shows the sequence of the case MR2 moves away.










Kumazawa, et al.        Expires January 7, 2005                 [Page 7]


Internet-Draft              Token based DND                    July 2004


   MR2(Borrower)                   MR1(Owner)                        HA
    |                               |                                 |
    moves away                      |--BU [1::,updated token,owner]-->|
    |                               |                                 |
    |                               |<------BA [status=0,token]-------|
    |                               |                                 |
    |   unreachable                 |                                 |
    |     <--RA[1::,updated token]--|                                 |
    |                               |                                 |
    |-------------------------------+--BU [1::,old token,borrower]--->|
    |                               |                                 |
    |<------------------------------+-----BA [status=141]-------------|
    |                               |                                 |
    |                               |           The entry of MR2 expires

                   Figure 3: sequence: MR2 moves away


3.4  After Detection of Splitting

   When MR2 moves away from MR1 and LFN remains connected to MR1, LFN
   can keep communication with CN using the same address 1::100.

   If LFN moves away with MR2 from MR1, LFN can't keep communication
   using 1::100 since MR2 doesn't own 1:: yet.

   When MR2 stops receiving router advertisements from MR1, it realizes
   that the owner (MR1) of the prefix 1:: has either failed or moved
   away.  Upon realizing this, MR2 MUST stop including the prefix 1:: in
   its router advertisment messages.  Node still attached to MR2
   (possibly including the LFN), will stop receiving RA messages that
   include 1:: and hence their internal movement detection mechanisms
   will reconfigure their addresses for communication.  If all the nodes
   that are using 1:: are attached to MR2, it makes sense to allow MR2
   to take ownership of the prefix rather than re-configuring every node
   in the network.  Detecting such a situation and achieving the trasfer
   of ownership is outside the scope of this document.

3.5  Registration Request from Token based DND-unaware Mobile Routers

   A Binding Update without token option or Prefix Delegated Flag (D)
   means that the Mobile Network prefix in the Binding Update must not
   be shared with any mobile router.  Hence Mobile Network Prefixes
   owned by mobile routers unaware of Token based DND will not be
   shared.






Kumazawa, et al.        Expires January 7, 2005                 [Page 8]


Internet-Draft              Token based DND                    July 2004


4.  Format

4.1  Binding Update

   A new Prefix Delegated flag (D) is included in the Binding Update to
   indicate that the Mobile Network Prefix is owned (zero) or borrowed
   (one).  The rest of the Binding Update format remains the same as
   defined in [2].

           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
                                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                          |          Sequence #           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |A|H|L|K|M|R|D|    Reserved     |           Lifetime            |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          .                                                               .
          .                        Mobility options                       .
          .                                                               .
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Prefix Delegated Flag (D)
      The Prefix Delegated Flag is set to indicate to the Home Agent
      that Mobile Network prefix is owned or borrowerd.  If the flag is
      set to 0, the prefix is owned by a Mobile Router.  If the flag is
      set to 1, the prefix is borrowed  from a Mobile Router(owner).
      However, when Mobile Router Flag (R) is set to zero, the Home
      Agent MUST ignore the D flag.

4.2  Token Option

   A token option is included in the Binding Update and the Binding
   Acknowledgement to share the token corresponding to the Mobile
   Network prefix between an owner and a Home Agent.  When the owner
   requests the Home agent to generate or update the token, it sets zero
   in the token field of the Binding Update.  When the owner generates
   or updates token by itself, the owner sets the value.  A token option
   is also included in router advertisements multicasted from an owner
   to distribute the prefix and the token to borrowers within the Mobile
   Network.  A token option is also used to indicate that a Home Agent
   is aware of Token based DND.  If the Binding Acknowledgement from the
   Home Agent doesn't include a token option while an owner or a
   borrower includes a token option in the Binding Update, Token based
   DND is not implemented in the Home Agent.





Kumazawa, et al.        Expires January 7, 2005                 [Page 9]


Internet-Draft              Token based DND                    July 2004


           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   Length      |            Reserved           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                          Token                                |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      TBA

   Length
      8 bit unsigned integer indicating the length in octests of the
      option excluding the type and length fields.  Set to 8.

   token
      2 bytes field contains token.


































Kumazawa, et al.        Expires January 7, 2005                [Page 10]


Internet-Draft              Token based DND                    July 2004


5.  Mobile Router Operation

   A Mobile Router acts as either an owner or a borrower.  Major
   differences from Mobile Router's operation in [2] are the followings.

      Binding Updates includes a D flag and a token option.

      An owner multicasts Router Advertisement including a Mobile
      Network Prefix and a token option.

5.1  Data Structure

   An owner or a borrower also maintains Binding Update List, described
   in Section 5.1 of NEMO Basic support specification[2].  This document
   introduces a new token field and a Prefix Delegated Flag (D).

   Prefix Delegated Flag (D) is set to zero (owner's case)

      This indicates that a mobile router acts as an owner of the Mobile
      Network prefix.  The owner stores a token generated or updated by
      itself or a Home Agent.

   Prefix Delegated Flag (D) is set to one (borrower's case)

      This indicates that a mobile router acts as a borrower of the
      Mobile Network prefix.  The borrower stores the token included in
      router advertisements sent from the owner.

5.2  Owner Operation

5.2.1  Sending Binding Updates

   An owner includes a token option in a Binding Update message if it
   allows other mobile routers (borrowers) to share the Mobile Network
   prefix.  An owner doesn't include token option if it doesn't allow
   share of the prefix.

   An owner MUST maintain a token with a Home Agent using a token option
   to share the prefix with borrowers.  An owner can choose itself or
   the Home Agent to generate and update the token.  In the case an
   owner generates or updates a token, the owner sets the value in the
   option in a Binding Update.  If the owner requests the Home Agent to
   generate or update the token, the owner sets zero in the token field.
   The owner can choose to generate/update the tokens or allow the home
   agent to do the same.  The periodicity of the updates (token change)
   will be controlled by the owner or the home agent based on who is
   generating/updating the token.




Kumazawa, et al.        Expires January 7, 2005                [Page 11]


Internet-Draft              Token based DND                    July 2004


   An owner can operate in either Implicit or Explicit mode.  In
   implicit mode, the Mobile Router does not include a Mobile Network
   Prefix Option in the Binding Update.  In explicit mode, the Mobile
   Router includes a Mobile Network Prefix Option in the Binding Update.
   These modes are defined in [2].

5.2.2  Receiving Binding Acknowledgements

   After the owner completes the Binding as a mobile router
   successfully, it checks the token option in the Binding
   Acknowledgement.  If token option is not included in the Binding
   Acknowledgement while the owner included a token option in the
   correspoinding Binding Update, the owner assumes that the Home Agent
   is not aware of Token based DND.  In this case the owner acts as a
   mobile router in [2] and doesn't include token option in Router
   Advertisement messages.

   If a token option is included in the Binding Acknowledgement, the
   owner checks the value of token in the case the owner requests the
   Home Agent to generate or update token by setting zero to the token
   option in the corresponding Binding Update.  If the value of the
   token option in the Binding Acknowledgement is zero, which means that
   an error is occurred in the Home Agent.  In the case the owner MUST
   NOT include token option in Router Advertisement messages.  If the
   value is not zero, the owner stores it in the Binding Update List.
   When the owner succeeds in checking token option in the Binding
   Acknowledgement, it starts multicasting Router Advertisement
   including a token option.  The owner MUST NOT include the token
   option in the Router Advertisement before it confirms that the Home
   Agent processes the token successfully.

5.2.3  Error processing

   Error processing of an owner is the same as described in [2].

5.2.4  token update

   A token SHOULD be updated frequently using the token option in
   Binding Updates and Binding Acknowledgement.  The owner need not
   include token option in Binding Updates when it doesn't intend to
   update a token.  The owner MUST NOT include an updated token in
   Router Advertisements before it confirms the token is processed
   successfuly by the Home Agent.

5.2.5  Returning Home

   When the owner returns home, it de-registers with the Home Agent.
   After de-registration, the owner MUST NOT include token option in



Kumazawa, et al.        Expires January 7, 2005                [Page 12]


Internet-Draft              Token based DND                    July 2004


   Router Advertisements since token can't be exchanged using Binding
   messages between an owner and a Home Agent at home.  This means that
   a Mobile Network prefix can't be shared while an owner is connected
   to home link.

5.3  Borrower Operation

5.3.1  Sending Binding Update

   When a borrower receives a Router Advertisement including a prefix
   option and a token option from an owner, the borrower sends a Binding
   Update including token option with the same value and Prefix
   Delegated Flag (D) set to one.

   A borrower MUST NOT use implicit mode.  A borrower can use only
   explicit mode.

5.3.2  Receiving Binding Acknowledgement

   When a borrower receives Binding Acknowledgement and realizes that
   Home Agent sets up forwarding successfully, the borrower begins
   Mobile Router operation.  A borrower MUST NOT include token option in
   Router Advertisement.

5.3.3  Receiving Router Advertisement

   When a borrower finds a token in Router Advertisements updated, the
   borrower MUST send a Binding Update including the updated token to
   the Home Agent immediately.

   When a borrower finds Router Advertisement from an owner stopped, the
   borrower can assume that the owner failed or moved away.  The
   borrower MAY try to become a new owner of the Prefix.  The mechanism
   to change the ownership of a prefix is outside the scope of the
   current document.  This will involve invalidating the binding cache
   entry of the old owner in the home agent, either by time expiry or a
   de-registration by the owner.

   When a borrower notices that an owner removes token option from
   Router Advertisements, the borrower can assume that an owner
   prohibits the share of its Prefix (ex.  the owner returns home).  In
   this case the borrower may try to obtain a new prefix and become a
   new owner of it or de-register with the Home Agent.  Operations of
   borrowers when an owner stops allowing the share of its Prefix are
   outside the scope of this document.






Kumazawa, et al.        Expires January 7, 2005                [Page 13]


Internet-Draft              Token based DND                    July 2004


5.3.4  Error Processing

   Since a borrower can use only explicit mode and Binding Updates sent
   from the borrower are not rejected by the Home Agent using Prefix
   Table, it interprets only error status '140' (Mobile Router Operation
   not permitted) and '141' (Invalid Prefix).  A borrower MUST discard
   Binding Acknowledgements with status '142' or '143'.

   Error status '141' is returned when a Mobile Network prefix is not
   registered by an owner or when value of a token option is invalid.
   These two cases are not differentiated with status value because of
   security reason.  When a borrower receives a Binding Acknowledgement
   with status '141', it SHOULD wait until token is updated in Router
   Advertisements from an owner.





































Kumazawa, et al.        Expires January 7, 2005                [Page 14]


Internet-Draft              Token based DND                    July 2004


6.  Home Agent operation

6.1  Data Structures

6.1.1  Binding Cache

   The Binding Cache is a conceptual data structure described in detail
   in [4] and [2].  This document introduces a new token field and a
   Prefix Delegated Flag (D).  A Home Agent stores tokens corresponding
   to the Mobile Network Prefixes associated with owners.  This
   information is used when the Home Agent decides whether it
   acknowledges requests for sharing the prefixes from borrowers or not.
   The Home Agent also stores the status of Prefix Delegated Flag (D)
   extracted from a Binding Update.

6.1.2  Prefix Table

   Since borrowers can claim Mobile Network Prefixes that belongs to
   owners using Token based DND.  Prefix Table MUST NOT be used when
   processing Binding Updates from borrowers.

6.2  Mobile Network Prefix Registration

   The Home Agent performs the following checks of a Binding Update in
   addition to checks in [2] in the case Mobile Router Flag (R) is set.
   If Mobile Router Flag (R) of the Binding Update is not set, the Home
   Agent MUST ignore the Prefix Delegation flag (D).

   Prefix Delegation flag is set to zero in explicit mode

      If the Home Agent has a binding cache entry with a Prefix
      Delegation Flag (D) set to zero and the Mobile Network Prefix in
      the Binding Update is the same as the existing entry, the Home
      Agent rejects it and sends Binding Acknowledgement with status set
      to 141.  If the Home Agent verifies the prefix information with
      the Prefix Table and the check fails, the Home Agent MUST reject
      the Binding Update and send a Binding Acknowldegement with status
      set to 142 (Not Authorized for Prefix).

   Prefix Delegation flag is set to one in explicit mode

      The Home Agent rejects the Binding Update and sends a Binding
      Acknowledgement with status set to 141 in the following cases.


         -The Binding Update doesn't include token option.





Kumazawa, et al.        Expires January 7, 2005                [Page 15]


Internet-Draft              Token based DND                    July 2004


         -When the Binding Update includes a token option and the Home
         Agent doesn't have any entry with Prefix Delegated Flat set to
         zero, the same prefix, and the same token.

   Prefix Delegation flag is set to zero in implicit mode

      The Home Agent checks the Binding Update as described in [2].

   Prefix Delegation flag is set to one in implicit mode

      The Home Agent rejects the Binding Update and sends Binding
      Acknowledgement with status set to 143.

   When the Home Agent has a valid binding cache entry with a Prefix
   Delegate Flag (D) set to one and rejects the corresponding Binding
   Update because of an invalid token, the Home Agent SHOULD NOT delete
   the existing entry with just one rejection.  The Home Agent MAY use
   the number of errors or the lifetime of the entry to decide whether
   the Home Agent deletes the entry or not.  This is because borrowers
   may not be able to obatin an updated token as soon as the update
   occurs.

   If all checks are passed, the Home Agent creates a binding cache
   entry for an owner or an borrower, or updates the binding cache entry
   if it already exists.  If the Binding Update from unregistered owner
   without token option arrives, the Home Agent sets zero in the token
   field of the binding cache entry.  If the Binding Update from
   registered owner without token option arrives, the Home Agent doesn't
   update the token field of the entry.

   If the token is set to zero in the Binding Update with Prefix
   Delegated Flag (D) set to zero, the Home Agent generates or updates a
   token if necessary.

   After setting up Binding Cache Entry and forwarding, the Home Agent
   sends the Binding Acknowledgement with status set to zero.  If the
   Binding Update from an owner or a borrower includes the token option,
   the Home Agent includes a token option in the Binding
   Acknowledgement.  If the Binding Update doesn't include token option,
   the Home Agent SHOULD NOT include token option in the Binding
   Acknowledgement.

   When the token is zero in the Binding Update sent from an owner, the
   Home Agent sets the value generated by itself in the Binding
   Acknowledgement.






Kumazawa, et al.        Expires January 7, 2005                [Page 16]


Internet-Draft              Token based DND                    July 2004


6.3  Forwarding Packets

   When the Home Agent forwards a data packet destined for the mobile
   network, the Home Agent selects one Mobile Router among an owner and
   borrowers if any.  This selection will be done based on various
   policies.  Selection of Mobile Router for data forwarding is outside
   the scope of this document.












































Kumazawa, et al.        Expires January 7, 2005                [Page 17]


Internet-Draft              Token based DND                    July 2004


7.  Security Consideration

   A token is used for a Home Agent to confirm reachability between an
   owner and borrowers within a link.  Hence, token sent from an owner
   should be protected with security mechanisms like layer 2 encryption.
   And exchange of token between an owner and a Home Agent should be
   protected with IPsec.

8  References

   [1]  Ng, C. and J. Charbon, "Multi-Homing Issues in Bi-Directional
        Tunneling", draft-ng-nemo-multihoming-issues-03 (work in
        progress), February 2004.

   [2]  Devarapalli, V., "Network Mobility (NEMO) Basic Support
        Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
        June 2004.

   [3]  Ernst, T., "Goals and Benefits of Multihoming",
        draft-multihoming-generic-goals-and-benefits-00 (work in
        progress), February 2004.

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

   [5]  IETF NEMO (NEtwork MObility) working group mailing list,
        Archive: http://www.ietf.org/html.charters/nemo-charter.html.

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


Authors' Addresses

   Masayuki Kumazawa
   Panasonic (Matsushita Electric Industrial Co., Ltd.)
   4-5-15 Higashi-shinagawa
   Shinagawa-ku, Tokyo
   Japan

   Phone: +81 3 5460 2729
   EMail: kumazawa.masayuki@jp.panasonic.com









Kumazawa, et al.        Expires January 7, 2005                [Page 18]


Internet-Draft              Token based DND                    July 2004


   Yasuhiko Watanabe
   Panasonic (Matsushita Electric Industrial Co., Ltd.)
   4-5-15 Higashi-shinagawa
   Shinagawa-ku, Tokyo
   Japan

   Phone: +81 3 5460 2729
   EMail: watanabe.yasuhiko@jp.panasonic.com


   Taisuke Matsumoto
   Panasonic (Matsushita Electric Industrial Co., Ltd.)
   4-5-15 Higashi-shinagawa
   Shinagawa-ku, Tokyo
   Japan

   Phone: +81 3 5460 2729
   EMail: matsumoto.taisuke@jp.panasonic.com


   Sathya Narayanan
   Panasonic Digital Networking Lab
   Two Research Way, 3rd Floor
   Princeton, NJ  08536
   USA

   Phone: 609 734 7599
   EMail: sathya@research.panasonic.com























Kumazawa, et al.        Expires January 7, 2005                [Page 19]


Internet-Draft              Token based DND                    July 2004


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 (2004).  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.




Kumazawa, et al.        Expires January 7, 2005                [Page 20]