NEMO Working Group M. Kumazawa
Internet-Draft Y. Watanabe
Expires: January 7, 2005 T. Matsumoto
S. Narayanan
Panasonic
July 9, 2004
Token based Duplicate Network Detection for split mobile network
(Token based DND)
draft-kumazawa-nemo-tbdnd-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
When multiple Mobile Routers share the same prefix, a Home Agent must
be able to verify whether the mobile routers are in the same Mobile
Network or not. Otherwise, the Home Agent may not be able to forward
a data packet to the correct recipient since it may not be connected
to the mobile router the home agent chooses to forward the packet.
This document describes a Token based Duplicate Network Detection
Kumazawa, et al. Expires January 7, 2005 [Page 1]
Internet-Draft Token based DND July 2004
mechanism that enables a home agent to detect whether the mobile
rotuers claiming the same prefix are in the same mobile network.
Kumazawa, et al. Expires January 7, 2005 [Page 2]
Internet-Draft Token based DND July 2004
1. Introduction
Today, Mobile Internet Access using third generation network and the
use of public Internet access services by Wireless LAN is gaining in
popularity. Various new access technologies will emerge in the near
future. This leads to the demand for ubiquitous networking, where
portable devices can be connected to the Internet anywhere, at any
time. To realize ubiquity, it is necessary to select from the
various access networks available the network most suitable for
mobile Internet access according to the user's location and
situation. However, it is difficult to add various wireless
interfaces to all portable devices for reasons of cost and size.
Wireless PAN (W-PAN) is one of possible solutions enabling ubiquity.
In W-PAN portable devices with short distance wireless interfaces are
connected and some of them have additional access interfaces and
provide connectivity to the Internet. Devices with such Internet
access interfaces need to provide session continuity of all nodes in
W-PAN even when they change points of attachement to the Internet.
The Nemo Basic Support [2] provides the mobility of an entire
network. It realizes session continuity to all nodes in the Mobile
Network by maintaing bi-directional tunnels between mobile routers
and a Home Agent. Devices with Internet access interfaces in W-PAN
act as Mobile Routers. Mobile networks with mulitple mobile routers
providing multiple points of attachments to the Internet are called
Multihomed Mobile Network[1][3]. Mobile Routers are required to
construct just one logical network even though the physical mobile
router providing connectivity to the Internet could vary based on
location. This means that multiple mobile router in the same mobile
network may have to claim the same prefix. This kind of
configuration is introduced as (N,*,1) in [1]. However, this
configuration has an issue. In the Nemo Basic Support protocol, a
Home Agent can't know whether Mobile Routers claiming the same prefix
are in the same Mobile Network or not. So, correct recipient may not
be connected to the Mobile Router the Home Agent chooses to forward
packets. This problem is called "split mobile network" and the
solution to detect split mobile network is called Duplicate Network
Detection (DND) and they have been discussed in NEMO working group
mailing list [5].
The solution described in this document requires sharing of a token
corresponding to a Mobile Network Prefix between Mobile Routers
within a network and a Home Agent. Since the token is updated
periodically, Mobile Routers which exist outside or move away can't
obtain it and share the prefix.
Kumazawa, et al. Expires January 7, 2005 [Page 3]
Internet-Draft Token based DND July 2004
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[6].
Owner
A Mobile Router which owns a Mobile Network prefix (ex.
manual-configured or obtained with DHCP)
Borrower
A Mobile Router which borrows a Mobile Network prefix from the
owner.
Token
It is a random number created, or updated by an owner or a Home
Agent. A token is set in a token option in a Binding Update
message when the owner creates or a Binding Acknowledgement
message when the Home Agent creates. A token is distributed with
a Mobile Network prefix from the owner to borrowers. A token is
used for Home Agent to confirm whether the borrowers are connected
to the owner or not.
Kumazawa, et al. Expires January 7, 2005 [Page 4]
Internet-Draft Token based DND July 2004
3. Overview
Figure 1 shows an example network for describing overview of the
operation.
+----+
| HA |
+--+-+
|
+-----------------------+ +------+
| Internet |-----+ CN |
+-----------------------+ +------+
| |
+-----+ +-----+
| MR1 | | MR2 |
+--+--+ +--+--+
| |
----------------------- 1::
| 100
+--+--+
| LFN |
+-----+
Figure 1: example network
A LFN is connected to a Mobile Network whose prefix is 1::, and the
Mobile Network is connected to the Internet via two mobile routers
MR1 and MR2. This example assumes that both mobile routers register
to the same Home Agent. Hence this document describes only (N,1,1)
[1] case. (N,N,1) [1] would need some inter Home Agent protocol, and
the Token based DND would work with such protocol. In this example,
MR1 acts as an owner of 1:: and MR2 as a borrower of 1::.
3.1 Registration as an Owner
MR1 sends a Binding Update message to the Home Agent when it attaches
to a new access router. MR1 sets a Prefix Delegated flag (D) to zero
to indicate that it is an owner of 1:: and puts a token option to
indicate that 1:: can be shared with other mobile routers having a
correct token in the message. The token may be generated by either
the owner (MR1) or the Home Agent. If MR1 generates a token, it is
set in the token option, or if MR1 requests the Home Agent to create
a token, MR1 sets the token to zero in the option.
When a Home Agent receives a Binding Update message, it searches its
binding cache and prefix table if any. If the Home Agent doesn't
find any other owner of the same prefix (1:: in this example) in the
Kumazawa, et al. Expires January 7, 2005 [Page 5]
Internet-Draft Token based DND July 2004
binding cache or prefix table, the Home Agent acknowledges the
Binding Update by sending a Binding Acknowledgement with status '0'
to MR1. When the token is set to zero in the Binding Update, Home
Agent generates a token and sets it in the token option in the
Binding Acknowledgement message. A token option is included in a
Binding Acknowledgement message regardless of the value in a
corresponding Binding Update, to indicate that the Home Agent
interprets a token option in the Binding Update and is aware of Token
based DND.
MR1 receives the Binding Acknowledgement message and confirm whether
it includes a token option or not. If the message doesn't include
token option, MR1 concludes that the Home Agent is not aware of Token
based DND, and operates without Token based DND. MR1 starts
advertising 1:: and a corresponding token with router advertisement
message in the Mobile Network when it receives a Binding
Acknowledgement message including a token option. The Router
Advertisement multicasted from MR1 includes a prefix option of 1::
and a token option.
LFN configures its address (1::100 in this example) in the first
reception of a router advertisement message with a prefix option and
begins communication with CN.
MR2(Borrower) MR1(Owner) HA
| | |
| |-----BU [1::, token,owner]---->|
| | |
| |<-----BA [status=0,token]------|
| | |
| |=====bi-directional tunnel=====|
|<--------RA[1::,token]---------| |
Figure 2: sequence: Registration as an Owner
Figure 2 shows the sequence MR1 registers as an owner. This section
assumes that MR1 (owner) generates and updates tokens.
If a Home Agent finds that another owner of 1:: already registers,
the Home Agent rejects the Binding Update from MR1 and sets status to
'141' (Invalid Prefix) in a corresponding Binding Acknowledgement
message.
3.2 Registration as a Borrower
When MR2 receives a Router Advertisement message with prefix option
including 1:: and a token option from MR1, MR2 sends a Binding Update
Kumazawa, et al. Expires January 7, 2005 [Page 6]
Internet-Draft Token based DND July 2004
message with a token option and a Mobile Network Prefix option
including 1:: and sets the Prefix delegated flag (D) to 1 to indicate
that it borrows 1:: to the Home Agent. MR2 sets the token received
from MR1 in the Binding Update to indicate that it borrows 1:: from
MR1.
When a Home Agent receives the Binding Update from MR2, it compares
the token of the MR2 and the token registered by MR1. If they are
the same, the Home Agent acknowledges the Binding Update and sends
Binding Acknowledgement with status '0' and a token option. If they
are different or the prefix in the Binding Update from MR2 is not
registered by any owner, the Home Agent rejects it and sets the
status 141 (Invalid Prefix) of Binding Acknowledgement.
There are now two mobile routers MR1 and MR2 which claim 1:: in the
Binding Cache in the Home agent, and the Home Agent chooses one based
on various policies (eg. load balancing) when forwarding packets for
LFN.
Now, while both MR1 and MR2 MUST advertise the prefix in their router
advertisment messages, MR2 MUST NOT include the token option in its
router advertisment messages. Only the owner of the prefix is
allowed to advertise the corresponding token.
3.3 Refreshment of Token
The token is updated periodically and exchanged between a Home Agent
and the owner. After MR1 receives a Binding Acknowledgement with a
token option and realizes that re-binding and update of the token has
finished successfuly, it includes the updated token in Router
Advertisement messages.
When MR2 finds the token updated, it sends a Binding Update message
with the new token to the Home Agent.
If MR2 moves away from the mobile network and Router Advertisement
messages from MR1 do not reach it, it can't follow token updates.
After a token is updated, Binding Update messages with old tokens are
rejected by a Home Agent. Since MR2 can't re-register to the Home
Agent to update its Binding, the entry of MR2 in the Home Agent will
expire. Figure 3 shows the sequence of the case MR2 moves away.
Kumazawa, et al. Expires January 7, 2005 [Page 7]
Internet-Draft Token based DND July 2004
MR2(Borrower) MR1(Owner) HA
| | |
moves away |--BU [1::,updated token,owner]-->|
| | |
| |<------BA [status=0,token]-------|
| | |
| unreachable | |
| <--RA[1::,updated token]--| |
| | |
|-------------------------------+--BU [1::,old token,borrower]--->|
| | |
|<------------------------------+-----BA [status=141]-------------|
| | |
| | The entry of MR2 expires
Figure 3: sequence: MR2 moves away
3.4 After Detection of Splitting
When MR2 moves away from MR1 and LFN remains connected to MR1, LFN
can keep communication with CN using the same address 1::100.
If LFN moves away with MR2 from MR1, LFN can't keep communication
using 1::100 since MR2 doesn't own 1:: yet.
When MR2 stops receiving router advertisements from MR1, it realizes
that the owner (MR1) of the prefix 1:: has either failed or moved
away. Upon realizing this, MR2 MUST stop including the prefix 1:: in
its router advertisment messages. Node still attached to MR2
(possibly including the LFN), will stop receiving RA messages that
include 1:: and hence their internal movement detection mechanisms
will reconfigure their addresses for communication. If all the nodes
that are using 1:: are attached to MR2, it makes sense to allow MR2
to take ownership of the prefix rather than re-configuring every node
in the network. Detecting such a situation and achieving the trasfer
of ownership is outside the scope of this document.
3.5 Registration Request from Token based DND-unaware Mobile Routers
A Binding Update without token option or Prefix Delegated Flag (D)
means that the Mobile Network prefix in the Binding Update must not
be shared with any mobile router. Hence Mobile Network Prefixes
owned by mobile routers unaware of Token based DND will not be
shared.
Kumazawa, et al. Expires January 7, 2005 [Page 8]
Internet-Draft Token based DND July 2004
4. Format
4.1 Binding Update
A new Prefix Delegated flag (D) is included in the Binding Update to
indicate that the Mobile Network Prefix is owned (zero) or borrowed
(one). The rest of the Binding Update format remains the same as
defined in [2].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Delegated Flag (D)
The Prefix Delegated Flag is set to indicate to the Home Agent
that Mobile Network prefix is owned or borrowerd. If the flag is
set to 0, the prefix is owned by a Mobile Router. If the flag is
set to 1, the prefix is borrowed from a Mobile Router(owner).
However, when Mobile Router Flag (R) is set to zero, the Home
Agent MUST ignore the D flag.
4.2 Token Option
A token option is included in the Binding Update and the Binding
Acknowledgement to share the token corresponding to the Mobile
Network prefix between an owner and a Home Agent. When the owner
requests the Home agent to generate or update the token, it sets zero
in the token field of the Binding Update. When the owner generates
or updates token by itself, the owner sets the value. A token option
is also included in router advertisements multicasted from an owner
to distribute the prefix and the token to borrowers within the Mobile
Network. A token option is also used to indicate that a Home Agent
is aware of Token based DND. If the Binding Acknowledgement from the
Home Agent doesn't include a token option while an owner or a
borrower includes a token option in the Binding Update, Token based
DND is not implemented in the Home Agent.
Kumazawa, et al. Expires January 7, 2005 [Page 9]
Internet-Draft Token based DND July 2004
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length in octests of the
option excluding the type and length fields. Set to 8.
token
2 bytes field contains token.
Kumazawa, et al. Expires January 7, 2005 [Page 10]
Internet-Draft Token based DND July 2004
5. Mobile Router Operation
A Mobile Router acts as either an owner or a borrower. Major
differences from Mobile Router's operation in [2] are the followings.
Binding Updates includes a D flag and a token option.
An owner multicasts Router Advertisement including a Mobile
Network Prefix and a token option.
5.1 Data Structure
An owner or a borrower also maintains Binding Update List, described
in Section 5.1 of NEMO Basic support specification[2]. This document
introduces a new token field and a Prefix Delegated Flag (D).
Prefix Delegated Flag (D) is set to zero (owner's case)
This indicates that a mobile router acts as an owner of the Mobile
Network prefix. The owner stores a token generated or updated by
itself or a Home Agent.
Prefix Delegated Flag (D) is set to one (borrower's case)
This indicates that a mobile router acts as a borrower of the
Mobile Network prefix. The borrower stores the token included in
router advertisements sent from the owner.
5.2 Owner Operation
5.2.1 Sending Binding Updates
An owner includes a token option in a Binding Update message if it
allows other mobile routers (borrowers) to share the Mobile Network
prefix. An owner doesn't include token option if it doesn't allow
share of the prefix.
An owner MUST maintain a token with a Home Agent using a token option
to share the prefix with borrowers. An owner can choose itself or
the Home Agent to generate and update the token. In the case an
owner generates or updates a token, the owner sets the value in the
option in a Binding Update. If the owner requests the Home Agent to
generate or update the token, the owner sets zero in the token field.
The owner can choose to generate/update the tokens or allow the home
agent to do the same. The periodicity of the updates (token change)
will be controlled by the owner or the home agent based on who is
generating/updating the token.
Kumazawa, et al. Expires January 7, 2005 [Page 11]
Internet-Draft Token based DND July 2004
An owner can operate in either Implicit or Explicit mode. In
implicit mode, the Mobile Router does not include a Mobile Network
Prefix Option in the Binding Update. In explicit mode, the Mobile
Router includes a Mobile Network Prefix Option in the Binding Update.
These modes are defined in [2].
5.2.2 Receiving Binding Acknowledgements
After the owner completes the Binding as a mobile router
successfully, it checks the token option in the Binding
Acknowledgement. If token option is not included in the Binding
Acknowledgement while the owner included a token option in the
correspoinding Binding Update, the owner assumes that the Home Agent
is not aware of Token based DND. In this case the owner acts as a
mobile router in [2] and doesn't include token option in Router
Advertisement messages.
If a token option is included in the Binding Acknowledgement, the
owner checks the value of token in the case the owner requests the
Home Agent to generate or update token by setting zero to the token
option in the corresponding Binding Update. If the value of the
token option in the Binding Acknowledgement is zero, which means that
an error is occurred in the Home Agent. In the case the owner MUST
NOT include token option in Router Advertisement messages. If the
value is not zero, the owner stores it in the Binding Update List.
When the owner succeeds in checking token option in the Binding
Acknowledgement, it starts multicasting Router Advertisement
including a token option. The owner MUST NOT include the token
option in the Router Advertisement before it confirms that the Home
Agent processes the token successfully.
5.2.3 Error processing
Error processing of an owner is the same as described in [2].
5.2.4 token update
A token SHOULD be updated frequently using the token option in
Binding Updates and Binding Acknowledgement. The owner need not
include token option in Binding Updates when it doesn't intend to
update a token. The owner MUST NOT include an updated token in
Router Advertisements before it confirms the token is processed
successfuly by the Home Agent.
5.2.5 Returning Home
When the owner returns home, it de-registers with the Home Agent.
After de-registration, the owner MUST NOT include token option in
Kumazawa, et al. Expires January 7, 2005 [Page 12]
Internet-Draft Token based DND July 2004
Router Advertisements since token can't be exchanged using Binding
messages between an owner and a Home Agent at home. This means that
a Mobile Network prefix can't be shared while an owner is connected
to home link.
5.3 Borrower Operation
5.3.1 Sending Binding Update
When a borrower receives a Router Advertisement including a prefix
option and a token option from an owner, the borrower sends a Binding
Update including token option with the same value and Prefix
Delegated Flag (D) set to one.
A borrower MUST NOT use implicit mode. A borrower can use only
explicit mode.
5.3.2 Receiving Binding Acknowledgement
When a borrower receives Binding Acknowledgement and realizes that
Home Agent sets up forwarding successfully, the borrower begins
Mobile Router operation. A borrower MUST NOT include token option in
Router Advertisement.
5.3.3 Receiving Router Advertisement
When a borrower finds a token in Router Advertisements updated, the
borrower MUST send a Binding Update including the updated token to
the Home Agent immediately.
When a borrower finds Router Advertisement from an owner stopped, the
borrower can assume that the owner failed or moved away. The
borrower MAY try to become a new owner of the Prefix. The mechanism
to change the ownership of a prefix is outside the scope of the
current document. This will involve invalidating the binding cache
entry of the old owner in the home agent, either by time expiry or a
de-registration by the owner.
When a borrower notices that an owner removes token option from
Router Advertisements, the borrower can assume that an owner
prohibits the share of its Prefix (ex. the owner returns home). In
this case the borrower may try to obtain a new prefix and become a
new owner of it or de-register with the Home Agent. Operations of
borrowers when an owner stops allowing the share of its Prefix are
outside the scope of this document.
Kumazawa, et al. Expires January 7, 2005 [Page 13]
Internet-Draft Token based DND July 2004
5.3.4 Error Processing
Since a borrower can use only explicit mode and Binding Updates sent
from the borrower are not rejected by the Home Agent using Prefix
Table, it interprets only error status '140' (Mobile Router Operation
not permitted) and '141' (Invalid Prefix). A borrower MUST discard
Binding Acknowledgements with status '142' or '143'.
Error status '141' is returned when a Mobile Network prefix is not
registered by an owner or when value of a token option is invalid.
These two cases are not differentiated with status value because of
security reason. When a borrower receives a Binding Acknowledgement
with status '141', it SHOULD wait until token is updated in Router
Advertisements from an owner.
Kumazawa, et al. Expires January 7, 2005 [Page 14]
Internet-Draft Token based DND July 2004
6. Home Agent operation
6.1 Data Structures
6.1.1 Binding Cache
The Binding Cache is a conceptual data structure described in detail
in [4] and [2]. This document introduces a new token field and a
Prefix Delegated Flag (D). A Home Agent stores tokens corresponding
to the Mobile Network Prefixes associated with owners. This
information is used when the Home Agent decides whether it
acknowledges requests for sharing the prefixes from borrowers or not.
The Home Agent also stores the status of Prefix Delegated Flag (D)
extracted from a Binding Update.
6.1.2 Prefix Table
Since borrowers can claim Mobile Network Prefixes that belongs to
owners using Token based DND. Prefix Table MUST NOT be used when
processing Binding Updates from borrowers.
6.2 Mobile Network Prefix Registration
The Home Agent performs the following checks of a Binding Update in
addition to checks in [2] in the case Mobile Router Flag (R) is set.
If Mobile Router Flag (R) of the Binding Update is not set, the Home
Agent MUST ignore the Prefix Delegation flag (D).
Prefix Delegation flag is set to zero in explicit mode
If the Home Agent has a binding cache entry with a Prefix
Delegation Flag (D) set to zero and the Mobile Network Prefix in
the Binding Update is the same as the existing entry, the Home
Agent rejects it and sends Binding Acknowledgement with status set
to 141. If the Home Agent verifies the prefix information with
the Prefix Table and the check fails, the Home Agent MUST reject
the Binding Update and send a Binding Acknowldegement with status
set to 142 (Not Authorized for Prefix).
Prefix Delegation flag is set to one in explicit mode
The Home Agent rejects the Binding Update and sends a Binding
Acknowledgement with status set to 141 in the following cases.
-The Binding Update doesn't include token option.
Kumazawa, et al. Expires January 7, 2005 [Page 15]
Internet-Draft Token based DND July 2004
-When the Binding Update includes a token option and the Home
Agent doesn't have any entry with Prefix Delegated Flat set to
zero, the same prefix, and the same token.
Prefix Delegation flag is set to zero in implicit mode
The Home Agent checks the Binding Update as described in [2].
Prefix Delegation flag is set to one in implicit mode
The Home Agent rejects the Binding Update and sends Binding
Acknowledgement with status set to 143.
When the Home Agent has a valid binding cache entry with a Prefix
Delegate Flag (D) set to one and rejects the corresponding Binding
Update because of an invalid token, the Home Agent SHOULD NOT delete
the existing entry with just one rejection. The Home Agent MAY use
the number of errors or the lifetime of the entry to decide whether
the Home Agent deletes the entry or not. This is because borrowers
may not be able to obatin an updated token as soon as the update
occurs.
If all checks are passed, the Home Agent creates a binding cache
entry for an owner or an borrower, or updates the binding cache entry
if it already exists. If the Binding Update from unregistered owner
without token option arrives, the Home Agent sets zero in the token
field of the binding cache entry. If the Binding Update from
registered owner without token option arrives, the Home Agent doesn't
update the token field of the entry.
If the token is set to zero in the Binding Update with Prefix
Delegated Flag (D) set to zero, the Home Agent generates or updates a
token if necessary.
After setting up Binding Cache Entry and forwarding, the Home Agent
sends the Binding Acknowledgement with status set to zero. If the
Binding Update from an owner or a borrower includes the token option,
the Home Agent includes a token option in the Binding
Acknowledgement. If the Binding Update doesn't include token option,
the Home Agent SHOULD NOT include token option in the Binding
Acknowledgement.
When the token is zero in the Binding Update sent from an owner, the
Home Agent sets the value generated by itself in the Binding
Acknowledgement.
Kumazawa, et al. Expires January 7, 2005 [Page 16]
Internet-Draft Token based DND July 2004
6.3 Forwarding Packets
When the Home Agent forwards a data packet destined for the mobile
network, the Home Agent selects one Mobile Router among an owner and
borrowers if any. This selection will be done based on various
policies. Selection of Mobile Router for data forwarding is outside
the scope of this document.
Kumazawa, et al. Expires January 7, 2005 [Page 17]
Internet-Draft Token based DND July 2004
7. Security Consideration
A token is used for a Home Agent to confirm reachability between an
owner and borrowers within a link. Hence, token sent from an owner
should be protected with security mechanisms like layer 2 encryption.
And exchange of token between an owner and a Home Agent should be
protected with IPsec.
8 References
[1] Ng, C. and J. Charbon, "Multi-Homing Issues in Bi-Directional
Tunneling", draft-ng-nemo-multihoming-issues-03 (work in
progress), February 2004.
[2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[3] Ernst, T., "Goals and Benefits of Multihoming",
draft-multihoming-generic-goals-and-benefits-00 (work in
progress), February 2004.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] IETF NEMO (NEtwork MObility) working group mailing list,
Archive: http://www.ietf.org/html.charters/nemo-charter.html.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Masayuki Kumazawa
Panasonic (Matsushita Electric Industrial Co., Ltd.)
4-5-15 Higashi-shinagawa
Shinagawa-ku, Tokyo
Japan
Phone: +81 3 5460 2729
EMail: kumazawa.masayuki@jp.panasonic.com
Kumazawa, et al. Expires January 7, 2005 [Page 18]
Internet-Draft Token based DND July 2004
Yasuhiko Watanabe
Panasonic (Matsushita Electric Industrial Co., Ltd.)
4-5-15 Higashi-shinagawa
Shinagawa-ku, Tokyo
Japan
Phone: +81 3 5460 2729
EMail: watanabe.yasuhiko@jp.panasonic.com
Taisuke Matsumoto
Panasonic (Matsushita Electric Industrial Co., Ltd.)
4-5-15 Higashi-shinagawa
Shinagawa-ku, Tokyo
Japan
Phone: +81 3 5460 2729
EMail: matsumoto.taisuke@jp.panasonic.com
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: 609 734 7599
EMail: sathya@research.panasonic.com
Kumazawa, et al. Expires January 7, 2005 [Page 19]
Internet-Draft Token based DND July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kumazawa, et al. Expires January 7, 2005 [Page 20]