NEMO Working Group                                           M. Kumazawa
Internet-Draft                                               Y. Watanabe
Expires: April 12, 2005                                     T. Matsumoto
                                                            S. Narayanan
                                                               Panasonic
                                                        October 12, 2004


    Token based Duplicate Network Detection for split mobile network
                           (Token based DND)
                    draft-kumazawa-nemo-tbdnd-01.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 April 12, 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 share the same Mobile
   Network or not.  Otherwise, the Home Agent may not be able to forward
   a data packet to a correct recipient since the recipient may not be
   connected to the mobile router the Home Agent chooses to forward the
   packet.  This document describes a Token based Duplicate Network



Kumazawa, et al.         Expires April 12, 2005                 [Page 1]


Internet-Draft              Token based DND                 October 2004


   Detection mechanism that enables a Home Agent to detect whether
   multiple Mobile Rotuers claiming the same prefix are in the same
   Mobile Network.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Registration as an Owner . . . . . . . . . . . . . . . . .  6
     3.2   Registration as a Borrower . . . . . . . . . . . . . . . .  7
     3.3   Refreshment of Token . . . . . . . . . . . . . . . . . . .  8
     3.4   Registration Request from Token based DND-unaware
           Mobile Routers . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Mobile Network Prefix Option . . . . . . . . . . . . . . . 10
     4.2   Token Option . . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.1   Binding Acknowledgement  . . . . . . . . . . . . . . . 11
   5.  Mobile Router Operation  . . . . . . . . . . . . . . . . . . . 12
     5.1   Data Structure . . . . . . . . . . . . . . . . . . . . . . 12
     5.2   Sending Binding Updates  . . . . . . . . . . . . . . . . . 12
     5.3   Receiving Binding Acknowledgements . . . . . . . . . . . . 13
     5.4   Error Processing . . . . . . . . . . . . . . . . . . . . . 13
     5.5   Token Update . . . . . . . . . . . . . . . . . . . . . . . 14
     5.6   Returning Home . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Home Agent operation . . . . . . . . . . . . . . . . . . . . . 15
     6.1   Data Structures  . . . . . . . . . . . . . . . . . . . . . 15
       6.1.1   Binding Cache  . . . . . . . . . . . . . . . . . . . . 15
       6.1.2   Prefix Table . . . . . . . . . . . . . . . . . . . . . 15
     6.2   Mobile Network Prefix Registration . . . . . . . . . . . . 15
     6.3   Forwarding Packets . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Consideration . . . . . . . . . . . . . . . . . . . . 17
     7.1   Protection of Tokens . . . . . . . . . . . . . . . . . . . 17
     7.2   how to generate Tokens . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   A.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20













Kumazawa, et al.         Expires April 12, 2005                 [Page 2]


Internet-Draft              Token based DND                 October 2004


1.  Introduction

   Today, Mobile Internet Access using various kinds of wireless access
   technologies is gaining in popularity.  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 the network most suitable for mobile Internet access from
   the various access networks available according to the user's
   location and preference.  However, it is difficult to add various
   wireless access interfaces to all portable devices for reasons of
   cost and size.

   Wireless PAN (W-PAN) is one possible solutions enabling ubiquity.  A
   W-PAN consists of a collection of portable devices with short
   distance wireless interfaces and some of them have additional access
   interfaces providing 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 attachment 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 maintaining bi-directional tunnels between Mobile Routers
   and their Home Agents.  Devices with Internet access interfaces in a
   W-PAN act as Mobile Routers.  Mobile Network with multiple Mobile
   Routers providing multiple points of attachments to the Internet is
   one of Multihomed Mobile Networks [1][3].

   It is necessary to consider the issues relevant to the support of
   Mobile Network Prefixes by multiple Mobile Routers in a single Mobile
   Network.  If each Mobile Router supports different prefixes, nodes in
   the Mobile Network must change its source address when they send
   packets via a different Mobile Router, which makes it difficult to
   maintain continous sessions.  And a Home Agent needs to forward a
   data packet meant for a node to just one Mobile Router which supports
   the prefix of the node.  Hence, to provide advantages of multihoming,
   it is important to allow multiple Mobile Routers in the same mobile
   network to support the same prefix.  However, 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.  If
   Mobile Routers claiming the same prefix are in different places,
   packets forwarded from the Home Agent to one of the Mobile Routers
   might not reach correct recipient since it might be behind another
   Mobile Router.  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 the NEMO working
   group mailing list [7].




Kumazawa, et al.         Expires April 12, 2005                 [Page 3]


Internet-Draft              Token based DND                 October 2004


   Some solutions have already been proposed in the mailing list.  In
   the proposed solutions, a Home Agent confirms connectivity between
   the Mobile Routers claiming the same prefix before it acknowledges a
   new binding update.  These solutions have the following problems:

   o  If the bi-directional tunnel between the first Mobile Router and
      the Home Agent is unavailable temporarily, the DND test can't be
      done.

   o  Confirmation of connectivity before acknowledgement leads to some
      delay.

   This document describes a new DND solution using Tokens (Token based
   DND).  The Token based DND can do DND tests without above problems.
   Since the Token based DND is compatible with NEMO Basic Support,
   Token-based-DND-aware Mobile Routers and Home Agent can coexist with
   existing Mobile Routers and Home Agents.


































Kumazawa, et al.         Expires April 12, 2005                 [Page 4]


Internet-Draft              Token based DND                 October 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].

   This document assumes that the reader is familiar with Mobile IPv6 as
   defined in [5] and with the concept of Mobile Router defined in the
   NEMO terminology document [4].

   Owner
      When a Mobile Router owns Mobile Network prefixes (ex.
      manual-configured or obtains with DHCP), the Mobile Router is
      defined as an Owner of the Prefixes.

   Borrower
      When a Mobile Router supports a Mobile Network prefix from the
      Owner of the Prefix, the Mobile Router is defined as an Borrower
      of the Prefix.

   Token
      It is a number associated with a Mobile Network Prefix.  It is
      generated and updated by the Owner of the Prefix.  A Token is set
      in a Token option following the Mobile Network Prefix Option in a
      Binding Update and registered with its Home Agent.  A Token is
      also distributed with the Mobile Network Prefix from the Owner to
      other Mobile Routers (Borrowers) using Router Advertisements.  A
      Token is used for the Home Agent to confirm whether the Borrowers
      are connected to the Owner or not.  The way to generate Token is
      discussed in Section 7.2.  One of the simplest ways is just
      generating a random number.  All zero means 'NULL' and that the
      Owner doesn't allow its own Prefix to be shared.



















Kumazawa, et al.         Expires April 12, 2005                 [Page 5]


Internet-Draft              Token based DND                 October 2004


3.  Overview

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


                +----+
                | HA |
                +--+-+
                   |
                +-----------------------+     +------+
                |        Internet       |-----+  CN  |
                +-----------------------+     +------+
                    |               |
                 +-----+         +-----+
                 | MR1 |         | MR2 |
                 +--+--+         +--+--+
                    |P1::            |P2::
                 ---------------------------
                      | P1::a          | P2::b
                   +--+--+          +--+--+
                   | LFNa|          | LFNb|
                   +-----+          +-----+

                       Figure 1: example network

   MR1 and MR2 establish bi-directional tunnels with their Home Agent.
   Mobile Network Prefixes MR1 and MR2 register are P1 and P2
   respectively.  LFNa and LFNb configures its address with P1::a and
   P2::b.  MR1, MR2, and LFNa,LFNb are connected via a link.  This
   configuration can be expressed as (2,1,2) based on the notation in
   [1].  This Mobile Network consists of two logical independent network
   P1::/64 and P2::/64.  MR1 can neither forward LFNb's packets nor MR2
   can do LFNb's ones currently.

3.1  Registration as an Owner

   As MR1 is the Owner of prefix P1, MR1 generates and updates a Token
   corresponding to P1.  MR1 sends a Binding Update including a Mobile
   Network Prefix Option of P1 to the Home Agent when it attaches to a
   new access router.  And MR1 sets a Prefix Delegated flag (D) to 0 in
   the Mobile Network Prefix option to indicate that it is the Owner of
   P1 and MUST put a Token option next to that in the Binding Update.

   If the Home Agent receives and processes the message successfully,
   the Home Agent stores the token and acknowledges it by sending MR1 a
   Binding Acknowledgement indicating that the prefix and the Token is
   processed successfully.



Kumazawa, et al.         Expires April 12, 2005                 [Page 6]


Internet-Draft              Token based DND                 October 2004


   After MR1 receives the Binding Acknowledgement, MR1 starts
   advertising P1 and the Token using Router Advertisements in the
   Mobile Network.

   After MR2 registers P2 and the corresponding Token, it advertises
   them in the same way as MR1.


   MR1(owner of P1)                   MR2(owner of P2)                    HA
    |                                  |                                  |
    |-----BU [P1, token, owner]--------|--------------------------------->|
    |                                  |                                  |
    |<---------------------------------|---------BA [status=OK]-----------|
    |                                  |                                  |
    |--------RA[P1, token]------------>|                                  |
    |                                  |                                  |
    |                                  |-----BU [P2, token, owner]------->|
    |                                  |                                  |
    |                                  |<--------BA [status=OK]-----------|
    |                                  |                                  |
    |<--------RA[P2, token]------------|                                  |

              Figure 2: sequence: Registration as an Owner

   Figure 2 shows the sequence where MR1 and MR2 register their own
   prefixes as Owners.

3.2  Registration as a Borrower

   When MR2 receives a Router Advertisement with prefix option including
   P1 and the corresponding Token from MR1, MR2 configures P1 as a
   prefix which it supports in addition to P2.

   To indicate support of P1 and P2 to the Home Agent, MR2 sends a
   Binding Update with two Mobile Network Prefix Options followed by
   corresponding Token options respectively.  The token options for each
   of the prefix MUST follow the network prefix option as the ordering
   is used to match a particular prefix to a particular token.

   Figure 3 shows options in the Binding Update sent from MR2 to the
   Home Agent.  First MNP option includes P2 with the Prefix Delegated
   Flag (D) set to 0 and the next MNP option includes P1 with the flag
   set to '1'.








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


Internet-Draft              Token based DND                 October 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      |0|  Reserved   | Prefix Length |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          .                   Mobile Network Prefix(P2)                   .
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   Length      |            Reserved           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |              Token for P2 (generated by MR2)                  |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   Length      |1|  Reserved   | Prefix Length |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          .                   Mobile Network Prefix(P1)                   .
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   Length      |            Reserved           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |              Token for P1 (generated by MR1)                  |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: Mobility Options of the Binding Update sent from MR2

   When the Home Agent receives the Binding Update from MR2, it updates
   the entry of P2 and examines the Token option following the prefix
   option of P1.  When it equals to the Token registered by MR1, the
   Home Agent acknowledges the Binding Update by sending a Binding
   Acknowledgement.  MR2 becomes the Owner of P2 and the Borrower of P1
   after the registration finishes successfully.  MR1 registers as the
   Owner of P1 and the Borrower of P2 as well.  Hence data packets meant
   for P1 and P2 can be forwarded via either MR1 or MR2.

3.3  Refreshment of Token

   A Token is updated periodically and registered with a Home Agent by
   the Owner of the prefix.  After the Owner finishes registration
   successfully, they include the updated Tokens in Router
   Advertisements.

   When the Borrower finds the Token updated, it sends a Binding Update
   with the updated Token to the Home Agent.  If the Borrower moves away
   from the Mobile Network and Router Advertisements from the Owner do
   not reach it, it can't obtain the updated Token.  After the Token is
   updated, Binding Updates with old Tokens are rejected by the Home
   Agent.  Hence, a Borrower which moves away from the mobile network



Kumazawa, et al.         Expires April 12, 2005                 [Page 8]


Internet-Draft              Token based DND                 October 2004


   can't keep sharing the prefix.

3.4  Registration Request from Token based DND-unaware Mobile Routers

   A Binding Update without Token option means that the prefix 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 April 12, 2005                 [Page 9]


Internet-Draft              Token based DND                 October 2004


4.  Format

4.1  Mobile Network Prefix Option

   A new Prefix Delegated flag (D) is included in a Mobile Network
   Prefix Option to indicate that the prefix is owned (0) or borrowed(1)
   by a Mobile Router sending the Binding Update.  The rest of the
   Mobile Network Prefix Option 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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   Length      |D|  Reserved   | Prefix Length |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          +                                                               +
          |                                                               |
          +                   Mobile Network Prefix                       +
          |                                                               |
          +                                                               +
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Prefix Delegated Flag (D)
      The Prefix Delegated Flag is used to indicate to its Home Agent
      that the Mobile Network Prefix is owned or borrowed.  If the flag
      is set to 0, the prefix is owned by the Mobile Router.  If the
      flag is set to 1, the prefix is borrowed from another Mobile
      Router(Owner).

4.2  Token Option

   Token options are included in a Binding Update.  A Token option
   corresponds to a Mobile Network Prefix Option placed ahead it.

   Token options are also included in Router Advertisements distributed
   from an Owner to Borrowers.  In a Router Advertisement, a Token
   option is placed next to a Prefix Option including the Mobile Network
   Prefix.

           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                                |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Kumazawa, et al.         Expires April 12, 2005                [Page 10]


Internet-Draft              Token based DND                 October 2004


   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.


4.2.1  Binding Acknowledgement

   The Binding Acknowledgement format used in this document is the same
   as defined in [2].  This document introduces the following new
   Binding Acknowledgement status values.

      2 (TBA)   DND test and set up are completed successfully

































Kumazawa, et al.         Expires April 12, 2005                [Page 11]


Internet-Draft              Token based DND                 October 2004


5.  Mobile Router Operation

   A Mobile Router is defined as either Owner or Borrower for each
   Mobile Network Prefix it supports.  An Owner and Borrowers share
   Mobile Network Prefixes using Token.

5.1  Data Structure

   A Mobile Router maintains a 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).  The
   followings are relationships between Token and Prefix Delegated Flag
   (D).

   Prefix Delegated Flag (D) is set to 0 ( the Prefix is owned by the
   Mobile Router)

      *  Token is generated or updated by the Owner.  'NULL' in Token
         field means that the Prefix is not shared.

   Prefix Delegated Flag (D) is set to 1 (the Prefix is borrowed from an
   Owner)

      *  Token is extracted from Router Advertisements sent from the
         Owner.

5.2  Sending Binding Updates

   A Mobile Router sends a Binding Update including Mobile Network
   Prefix Options described in Section 5.2 of [2].  The difference from
   [2] is that a Mobile Router sets a Prefix Delegated Flag (D) of each
   Mobile Network Prefix Option and adds Token Options if necessary.  A
   Mobile Router MUST send a Binding Update in Explicit mode when it
   uses any Token option.  A Mobile Router includes options and sets
   flag of the options in the Binding Update as follows.  When the
   Mobile Router includes Token Options in a Binding Update, it MUST put
   each Token Option next to the corresponding Mobile Network Prefix
   option.

   Owner

      The Mobile Router sets the Prefix Delegated Flag (D) to 0 in a
      Mobile Network Prefix Option and MUST put a Token Option next to
      it when the Mobile Router allows the Prefix to be shared.  The
      Mobile Router doesn't put a Token Option when it doesn't allow
      sharing the Prefix.





Kumazawa, et al.         Expires April 12, 2005                [Page 12]


Internet-Draft              Token based DND                 October 2004



   Borrower

      A Mobile Router sets the Prefix Delegated Flag (D) to 1 in a
      Mobile Network Prefix Option and puts a Token Option next to it.
      Mobile Network Prefix Option MUST be followed by the corresponding
      Token Option when its Prefix Delegated Flag is set to '1'.

5.3  Receiving Binding Acknowledgements

   If the status field of Binding Acknowledgement is '2' to indicate
   that the Home Agent processed prefixes and Tokens successfully, the
   Mobile Router assumes that the Home Agent set up forwarding for all
   the Prefixes including borrowed ones.  The Mobile Router can then
   start using bi-directional tunnels for the Prefixes.  If the status
   is set to '0', the Mobile Router assumes that the Home Agent isn't
   aware of the Token based DND and acts as described in [2].  In this
   case the Mobile Router SHOULD re-send the Binding Update including
   only its own Prefixes without Token Options.

   After the Binding finishes successfully, the Mobile Router then
   starts sending Router Advertisement including Prefixes which it owns
   and corresponding Tokens if any.  The Mobile Router MUST NOT
   advertise Prefixes nor Tokens of which it is not the Owner but the
   Borrower.  The Mobile Router SHOULD NOT include a Token option which
   is set to NULL in Router Advertisement messages.

   When the Mobile Router receives a Router Advertisement including a
   new Prefix and a corresponding Token from the Owner of the Prefix, it
   MAY become the Borrower of the Prefix by sending a Binding Update
   along with the token option.

5.4  Error Processing

   This document doesn't introduce any new Binding Acknowledgement
   status value for errors.  Since the Token based DND operates only in
   Explicit mode, the Mobile Router interprets the Binding
   Acknowledgement status values as described in Section 5.4.2 of [2].

   A Mobile Network Prefix with Prefix Delegated Flag set to '1' will be
   rejected in two cases.  One is when the Token is different from that
   registered by the Owner and the other is when no Owner registers the
   Prefix.  The Binding Acknowledgement is returned with status '141' in
   both of the cases.  In these cases, the Mobile Router SHOULD wait
   until an updated Token is distributed from the Owner or send a
   Binding Update without the Mobile Network Prefix borrowed from the
   Owner.




Kumazawa, et al.         Expires April 12, 2005                [Page 13]


Internet-Draft              Token based DND                 October 2004


5.5  Token Update

   An Owner MUST update Tokens periodically.  When a Borrower moves away
   from the mobile network, the Tokens held by the Borrower would be
   obsolete and enable the Home Agent to find the movement of the
   Borrower.  The Owner MUST advertise the updated Tokens using Router
   Advertisement as soon as it finishes the registration of the Tokens.
   The Owner MUST NOT advertise the updated Tokens until it receives the
   Binding Acknowledgement message indicating that the Home Agent
   finishes the registration successfully.  The Owner need not include
   Token options in the Binding Update when it doesn't intend to update
   them.  The Owner sets 'NULL' to the Token in the Binding Update when
   it intends to stop the sharing of the prefix by other Mobile Routers
   (Borrowers).  The Borrower MUST send a Binding Update including the
   update Tokens as soon as it finds the Tokens updated in Router
   Advertisement.

5.6  Returning Home

   When a Mobile Router returns home, it de-registers with its Home
   Agent.  After de-registration, the Mobile Router MUST NOT include any
   Token option corresponding to its own Prefixes in Router
   Advertisements since Tokens can't be registered with the Home Agent
   at home.  This means that Mobile Network Prefixes can't be shared
   while the Owner of the Prefixes is connected to home link.  The
   Borrower MUST send a Binding Update not including the Prefixes as
   soon as it finds the corresponding Token options removed from Router
   Advertisement from the Owner.























Kumazawa, et al.         Expires April 12, 2005                [Page 14]


Internet-Draft              Token based DND                 October 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 [5] and [2].  This document introduces a new Token field and a
   Prefix Delegated Flag (D).  A Home Agent stores a Token corresponding
   to a Mobile Network Prefix when the Prefix Delegated Flag is set to
   '0' in the Mobile Network Prefix Option.

6.1.2  Prefix Table

   Prefix Delegated Flag (D) might need to be introduced in a Prefix
   Table Entry since the Home Agent SHOLUD be able to prevent the
   following cases:

   o  As an Owner, a Mobile Router claims Mobile Network Prefixes owned
      by another Mobile Router (Owner).

   o  A Mobile Router borrows Mobile Network Prefixes not allowed from
      the Owner of them.

6.2  Mobile Network Prefix Registration

   A Home Agent performs the following check of all of the Mobile
   Network Prefix Options and Token Options in the Binding Update in
   addition to checks in [2] in the case Mobile Router Flag (R) is set.

   o  If there is any Token option which isn't placed next to a Mobile
      Network Prefix Option, it MUST reject the Binding Update and send
      a Binding Acknowledgement with status set to 143 (Forwarding Setup
      failed).

   When the Prefix Delegated Flag (D) is set to '0', it performs the
   following checks.

   o  If there is already a binding cache entry or Prefix Table entry
      which has the same Prefix owned by another Mobile Router (Prefix
      Delegated Flag (D) is set to '0'), the Home Agent MUST reject the
      Binding Update and send a Binding Acknowledgement with status set
      to 142 (Not Authorized for Prefix).

   When the Prefix Delegated Flag (D) is set to '1', it performs the
   following checks.





Kumazawa, et al.         Expires April 12, 2005                [Page 15]


Internet-Draft              Token based DND                 October 2004


   o  The Home Agent MUST reject the Binding Update and send a Binding
      Acknowledgement with status set to 141 (Invalid Prefix) in the
      following cases:

      *  The Mobile Network Prefix Option isn't followed by a Token
         Option.
      *  NULL (all zero) is set in a Token Option.
      *  The Mobile Network Prefix is not registered by any Owners.
      *  The Token is different from that registered by an Owner in the
         Binding Cache Entry.

   When the Home Agent has a valid binding cache entry with a Prefix
   Delegate Flag (D) set '1', it SHOULD NOT delete the entry with just
   one error of a Token.  This is because a Borrower may not be able to
   obtain an updated Token as soon as the update occurs necessarily.
   However, the Home Agent might need to delete the entry if the number
   of errors exceeds threshold before it expires.

   If all checks are passed, the Home Agent creates a binding cache
   entry for Mobile Router's Home Address, or updates the binding cache
   entry if it already exists.  When it has a valid binding cache entry
   with a Prefix Delegated Flag (D) set to '0' and it receives the
   Binding Update including the Mobile Network Prefix Option without a
   Token Option, the Home Agent doesn't update the Token.  When it
   creates a binding cache entry with Prefix Delegated Flag (D) set to
   '0' by receiving a Binding Update including a Mobile Network Prefix
   Option without a Token Option, it sets NULL in the Token field of the
   entry.

   After setting up Mobile Network Prefixes and corresponding Tokens and
   forwarding, the Home Agent sends a Binding Acknowledgement with
   status set to '2' to indicate that the setup finishes successfully.
   If all of the tokens set up with the Binding Update are configured to
   'NULL' and no Token option is included in the Binding Update, it MUST
   send the Binding Acknowledgement with status '0'.

6.3  Forwarding Packets

   When the Home Agent forwards a data packet destined for a Mobile
   Network Prefix, the Home Agent selects one Mobile Router among an
   Owner and Borrowers of the Prefix.  This selection will be done based
   on various policies.  The selection of Mobile Router is outside the
   scope of this document.








Kumazawa, et al.         Expires April 12, 2005                [Page 16]


Internet-Draft              Token based DND                 October 2004


7.  Security Consideration

7.1  Protection of Tokens

   Tokens MUST NOT be obtained except by a Home Agent and nodes
   including Mobile Routers within a Mobile Network.  Token Option in
   Binding Updates from a Mobile Router to the Home Agent would be
   protected with IPsec.  Router Advertisements including Token Option
   MUST be prevented from being snooped by nodes outside the Mobile
   Network using some security mechanism such as layer 2 encryption.

7.2  how to generate Tokens

   A Token is used for a Home Agent to confirm reachability between an
   Owner and Borrowers via just one link.  The following is not goal of
   using Tokens:

   o  To indicate to the Home Agent that a Mobile Router claiming a
      Mobile Network Prefix is a true Owner of the Prefix.

   Hence it is enough to generate a random number as a Token and a Token
   need not be associated with any information.

8  References

   [1]  Ernst, T., "Analysis of Multihoming in Network Mobility
        Support", draft-ietf-nemo-multihoming-issues-00 (work in
        progress), July 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-ernst-generic-goals-and-benefits-00 (work in progress),
        July 2004.

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

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

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

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


Kumazawa, et al.         Expires April 12, 2005                [Page 17]


Internet-Draft              Token based DND                 October 2004


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


   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 April 12, 2005                [Page 18]


Internet-Draft              Token based DND                 October 2004


Appendix A.  Change Log

   From -00 to -01

   o  Added (n,*,n) case to (n,*,1) case.

   o  Moved Prefix Delegated Flag from Binding Update to Mobile Network
      Prefix Option

   o  Only Owner can generate tokens while a Home Agent could also do in
      -00.








































Kumazawa, et al.         Expires April 12, 2005                [Page 19]


Internet-Draft              Token based DND                 October 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 April 12, 2005                [Page 20]