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]