[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
NEMO Working Group                                           M. Kumazawa
Internet-Draft                                               Y. Watanabe
Expires: January 12, 2006                                   T. Matsumoto
                                                            S. Narayanan
                                                               Panasonic
                                                           July 11, 2005


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Kumazawa, et al.        Expires January 12, 2006                [Page 1]


Internet-Draft               Token based DND                   July 2005


   packet.  This document describes a Token based Duplicate Network
   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.  Usage scenarios  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Wireless Personal Area Network (W-PAN) . . . . . . . . . .  6
     3.2   Automobile network . . . . . . . . . . . . . . . . . . . .  6
     3.3   Mobile Routers in a plane  . . . . . . . . . . . . . . . .  6
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Registration as an Owner . . . . . . . . . . . . . . . . .  8
     4.2   Registration as a Borrower . . . . . . . . . . . . . . . .  9
     4.3   Refreshment of Token . . . . . . . . . . . . . . . . . . . 10
     4.4   Registration Request from Token based DND-unaware
           Mobile Routers . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1   Mobile Network Prefix Option . . . . . . . . . . . . . . . 12
     5.2   Token Option . . . . . . . . . . . . . . . . . . . . . . . 12
       5.2.1   Binding Acknowledgement  . . . . . . . . . . . . . . . 13
   6.  Mobile Router Operation  . . . . . . . . . . . . . . . . . . . 14
     6.1   Data Structure . . . . . . . . . . . . . . . . . . . . . . 14
     6.2   Sending Binding Updates  . . . . . . . . . . . . . . . . . 14
     6.3   Receiving Binding Acknowledgements . . . . . . . . . . . . 15
     6.4   Error Processing . . . . . . . . . . . . . . . . . . . . . 16
     6.5   Token Update . . . . . . . . . . . . . . . . . . . . . . . 16
     6.6   Returning Home . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Home Agent operation . . . . . . . . . . . . . . . . . . . . . 17
     7.1   Data Structures  . . . . . . . . . . . . . . . . . . . . . 17
       7.1.1   Binding Cache  . . . . . . . . . . . . . . . . . . . . 17
       7.1.2   Prefix Table . . . . . . . . . . . . . . . . . . . . . 17
     7.2   Mobile Network Prefix Registration . . . . . . . . . . . . 17
     7.3   Forwarding Packets . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Consideration . . . . . . . . . . . . . . . . . . . . 19
     8.1   Protection of Tokens . . . . . . . . . . . . . . . . . . . 19
     8.2   how to generate Tokens . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   A.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 22








Kumazawa, et al.        Expires January 12, 2006                [Page 2]


Internet-Draft               Token based DND                   July 2005


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




Kumazawa, et al.        Expires January 12, 2006                [Page 3]


Internet-Draft               Token based DND                   July 2005


   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 January 12, 2006                [Page 4]


Internet-Draft               Token based DND                   July 2005


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

   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 8.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 January 12, 2006                [Page 5]


Internet-Draft               Token based DND                   July 2005


3.  Usage scenarios

3.1  Wireless Personal Area Network (W-PAN)

   Alice enjoys music downloaded via her cellular phone (working as a
   MR) with her silicon player.  These devices are connected via
   Bluetooth and they form a W-PAN .  She adds a PDA with 802.11b
   interface and Bluetooth into her W-PAN as a MR.  The silicon player
   doesn't have to change its source address in using the PDA since it
   is configured with the same MNP as her cellular phone.

   One day she leaves her PDA switched on at home.  It continues sending
   Binding Updates periodically and the Home Agent sends some packets
   destined for the player to it.

   When the DND operates, the HA will be aware that the PDA is away from
   the cellular phone, and will reject the BU from PDA.  Thereby, all
   packets will be correctly sent to the player via the phone.

   If she leaves the phone instead of the PDA, which is the owner of the
   MNP, the PDA can't keep using it and has to obtain another MNP.

3.2  Automobile network

   Bob goes for a drive with his friends.  All of their cellular phones
   work as MRs and so the NEMO has multiple cellular interfaces to
   enable broadband communication.

   When they enjoy video transferred via the MRs with a monitor in Bob's
   car, one of them gets down off the car.

   For the decreased bandwidth Bob sends the streaming server control
   messages to lower the quality of the video.  However, he can't
   complete the operation since replies from the server are sent to the
   cellular phone outside of the car.

   Without DND, the user must operate his cellular phone when she/he
   moves away from the NEMO.

3.3  Mobile Routers in a plane

   A plane is equipped with Multiple MRs for load balancing and
   increasing bandwidth.

   A MNP of each MR will be shared among other MRs and be revoked in the
   case it is relocated to another plane automatically using DND.

   The DND will help network administrators to keep the integrity



Kumazawa, et al.        Expires January 12, 2006                [Page 6]


Internet-Draft               Token based DND                   July 2005


   between the location of MRs and the MNP shared by them.


















































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


Internet-Draft               Token based DND                   July 2005


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

4.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 January 12, 2006                [Page 8]


Internet-Draft               Token based DND                   July 2005


   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[P1, token]------------|                                  |

               Figure 2: sequence: Registration as an Owner

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

4.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 January 12, 2006                [Page 9]


Internet-Draft               Token based DND                   July 2005


           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   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.

4.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 update 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 January 12, 2006               [Page 10]


Internet-Draft               Token based DND                   July 2005


   can't keep sharing the prefix.

4.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 January 12, 2006               [Page 11]


Internet-Draft               Token based DND                   July 2005


5.  Format

5.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).


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









Kumazawa, et al.        Expires January 12, 2006               [Page 12]


Internet-Draft               Token based DND                   July 2005


           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |   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.




5.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 January 12, 2006               [Page 13]


Internet-Draft               Token based DND                   July 2005


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

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


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






Kumazawa, et al.        Expires January 12, 2006               [Page 14]


Internet-Draft               Token based DND                   July 2005


   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.



   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 Delegate Flag is set to '1'.


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






Kumazawa, et al.        Expires January 12, 2006               [Page 15]


Internet-Draft               Token based DND                   July 2005


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

6.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 update 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.

6.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 January 12, 2006               [Page 16]


Internet-Draft               Token based DND                   July 2005


7.  Home Agent operation

7.1  Data Structures

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

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


7.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 January 12, 2006               [Page 17]


Internet-Draft               Token based DND                   July 2005


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

7.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 January 12, 2006               [Page 18]


Internet-Draft               Token based DND                   July 2005


8.  Security Consideration

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

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

9.  References

   [1]  Ernst, T., "Analysis of Multihoming in Network Mobility
        Support", draft-ietf-nemo-multihoming-issues-02 (work in
        progress), February 2005.

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

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

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

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

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





Kumazawa, et al.        Expires January 12, 2006               [Page 19]


Internet-Draft               Token based DND                   July 2005

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


   Yasuhiko Watanabe
   Panasonic (Matsushita Electric Industrial Co., Ltd.)


   Taisuke Matsumoto
   Panasonic (Matsushita Electric Industrial Co., Ltd.)


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


























Kumazawa, et al.        Expires January 12, 2006               [Page 20]


Internet-Draft               Token based DND                   July 2005


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.

   From -01 to -02

   o  Added usage scenarios (Section 3)




































Kumazawa, et al.        Expires January 12, 2006               [Page 21]


Internet-Draft               Token based DND                   July 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Kumazawa, et al.        Expires January 12, 2006               [Page 22]