NEMO Working Group Thierry Ernst, Editor
Internet-Draft INRIA and WIDE
February, 2003
"Network Mobility Support Requirements"
<draft-ietf-nemo-requirements-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
Network mobility arises when an entire network changes its point of
attachment to the Internet and thus its reachability in the topology.
The mobile network is viewed as a unit and is connected to the global
Internet by one or more mobile routers. In contrast with host
mobility support which aims at providing continuous Internet
connectivity to mobile hosts only, network mobility support is to
provide continuous Internet sessions not only to the mobile router
connecting the mobile network to the global Internet, but also to
nodes behind the mobile router. The purpose of this document is to
list the requirements that must be met by network mobility support
solutions in IPv6.
Ernst et al. Expires August 2003 [Page 1]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04
3. Network Mobility Goals and Methodology . . . . . . . . . . . 04
4. General Purpose Guidelines for the Solutions . . . . . . . . 05
5. One-liner Requirements for Basic NEMO Support. . . . . . . . 09
A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11
B. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Ernst et al. Expires August 2003 [Page 2]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
1. Introduction
Network mobility support is concerned with managing the mobility of
an entire network, viewed as a single unit, which changes its point
of attachment to the Internet and thus its reachability in the
Internet topology. Such kind of network is referred to as a mobile
network and includes one or more mobile routers (MRs) which connect
it to the global Internet. Nodes behind the MR(s) (MNNs) are both
fixed (keeping the same address on the mobile network at all times),
and mobile (entering and leaving the mobile network as they roam with
respect to it). In most cases, the internal structure of the mobile
network will in effect be relatively stable (no dynamic change of the
topology), but this is not a general assumption.
Cases of mobile networks include for instance:
- networks attached to people (Personal Area Networks or PANs): a
cell-phone with one cellular interface and one Bluetooth interface
together with a Bluetooth-enabled PDA constitute a very simple
instance of a mobile network. The cell-phone is the mobile router
while the PDA is used for web browsing or runs a personal web
server.
- networks of sensors and computers deployed in vehicles: vehicles
are more and more embedded with a number of processing units for
safety and ease of driving reasons, as advocated by ITS
(Intelligent Transportation Systems) applications.
- access networks deployed in public transportation (buses,
trains, taxis, aircrafts): they provide Internet access to IP
devices carried by passengers (laptop, camera, mobile phone: host
mobility within network mobility or PANs: network mobility within
network mobility, i.e. nested mobility).
- ad-hoc networks connected to the Internet via a MR: for instance
students in a train that both need to set up an ad-hoc network
among themselves and to get Internet connectivity through the MR
connecting the train to the Internet.
Traditional work conducted so far on mobility support was to provide
continuous Internet connectivity to mobile hosts only (host mobility
support). In contrast with host mobility support, network mobility
support is to provide continuous Internet sessions not only to the
mobile router connecting the mobile network to the global Internet,
but also to nodes behind the mobile router.
Mobility of networks does not cause MNNs to change their own physical
point of attachment, however they happen to change their topological
Ernst et al. Expires August 2003 [Page 3]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
location with respect to the global Internet which results in lack of
Internet access and broken sessions if no supporting mechanisms are
deployed. In addition, communication between a MNN and an arbitrary
Correspondent Node (CN) may result in extremely suboptimal paths,
particularly when mobile networks are nested or when the CN is itself
mobile.
The mechanisms required for handling such mobility issues are
currently lacking within the IETF standards. The NEMO working group
has therefore been set up to deal with those. The purpose of this
document is thus to detail the methodology that will be followed by
the NEMO working group and to list requirements for network mobility
support.
This document is structured as follows: first, section 2 introduces
the terminology for network mobility. In section 3, we define the
goals and methodology of the working group and we emphasize the
stepwise approach the working group has decided to follow. A number
of guidelines are listed in section 4 and are used in section 5 to
edict the requirements for basic network mobility support.
2. Terminology
Terms used in this document are taken from [MIPv6] and [MOBILITY-
TERMS]. Additional terms pertaining to network mobility specifically
are defined in [NEMO-TERMS].
[NOTE FROM THE EDITOR: parts from draft [NEMO-TERMS] will probably be
moved to [MOBILITY-TERMS] whereas the remaining terms would then be
pasted in this present document. THIS IS TO BE DISCUSSED]
3. Network Mobility Goals and Methodology
The primary goal of the NEMO work is to specify a solution which
allows mobile network nodes (MNNs) to remain connected to the
Internet and continuously reachable at all times while the mobile
network they are attached to changes its point of attachment.
Secondary goals of the work is to investigate the effects of network
mobility on various aspects of internet communication such as routing
protocol changes, implications of realtime traffic and fast
handovers, optimizations. These should all support the primary goal
of reachability for mobile network nodes. Security is an important
consideration too, and efforts should be made to use existing
solutions if they are appropriate. Although a well-designed solution
may include security inherent in other protocols, mobile networks
also introduce new challenges.
Ernst et al. Expires August 2003 [Page 4]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
For doing so, the NEMO working group has decided to take a stepwise
approach by standardizing a basic solution to preserve session
continuity (basic network mobility support), and at the same time
study the possible approaches and issues with providing more optimal
routing with potentially nested mobile networks (extended network
mobility support). However, the working group is not chartered to
actually standardize a solution to such route optimization at this
point in time.
For basic NEMO support, the working group will assume that none of
the nodes behind the MR will be aware of the network's mobility, thus
the network's movement needs to be completely transparent to the
nodes inside the mobile network. This assumption will be made to
accommodate nodes inside the network that are not generally aware of
mobility.
The efforts of the Mobile IP working group have resulted in the
Mobile IPv4 [7] and Mobile IPv6 [6] protocols, which have already
solved the issue of host mobility support. Since challenges to
enabling mobile networks are vastly reduced by this work, basic
network mobility support will adopt the methods for host mobility
support used in Mobile IP, and extend them in the simplest way
possible to achieve its goals. The basic support solution is for each
MR to have a Home Agent, and use bidirectional tunneling between the
MR and HA to preserve session continuity while the MR moves. The MR
will acquire a Care-of-address from its attachment point much like
what is done for mobile nodes (MN) using Mobile IP. This approach
allows nested mobile networks, since each MR will appear to its
attachment point as a single node.
4. General Purpose Guidelines for the Solutions
This section lists a number of guidelines which are used to edict the
requirements that MUST or SHOULD be met by forthcoming network
mobility support solutions, for both basic NEMO support and extended
NEMO support.
- Migration Transparency: a permanent connectivity to the Internet
MUST be provided to all MNNs while continuous sessions MUST be
maintained as the mobile router changes its point of attachment.
For doing so, MNNs will be reachable via their permanent IP
addresses.
- Performance Transparency (Seamless Mobility): NEMO support
SHOULD provide limited signaling overhead and ideally SHOULD
minimize the impact of handover on applications, in terms of
packet loss or delay. Variable delays of transmission and losses
Ernst et al. Expires August 2003 [Page 5]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
between MNNs and their respective CNs as the network is moving are
not considered lack of performance transparency.
- Network Mobility Support Transparency: MNNs behind the MR(s)
don't change their own point of attachment as a result of the
mobile network's displacement in the Internet topology.
Consequently, NEMO support is better performed by the sole MR(s)
and specific support functions on any other nodes than the MR(s)
SHOULD be avoided.
- Operational Transparency: NEMO support MUST be implemented at
the IP layer level. It MUST be transparent to any upper layer so
that any upper layer protocol can run unchanged on top of an IP
layer extended with NEMO support.
- Arbitrary Configurations: The formation of a mobile network can
exist in various levels of complexity. In the simplest case, a
mobile network contains just a mobile router and a host. In the
most complicated case, a mobile network is multi-homed and is
itself a multi-level aggregation of mobile networks with
collectively thousands of mobile routers and hosts. While the list
of potential configurations of mobile networks cannot be limited,
at least the following configurations are desirable:
o mobile networks of any size, ranging from a sole subnet with
a few IP devices to a collection of subnets with a large
number of IP devices,
o multi-homed mobile network (see definition in [NEMO-TERMS].
o foreign mobile nodes that attach to the mobile network.
o nodes that change their point of attachment within the mobile
network.
o nested mobile networks (see definition in [NEMO-TERMS].
o mobile networks displaced within a domain boundary (local
mobility) or between domain boundaries (global mobility).
o distinct mobility frequencies.
o distinct access medium.
In order to keep complexity minimal, transit networks are excluded
from this list. A transit network is one in which data would be
forwarded between two endpoints outside of the network, so that
Ernst et al. Expires August 2003 [Page 6]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
the network itself simply serves as a transitional conduit for
packet forwarding. A stub network (leaf network), on the other
hand, does not serve as a data forwarding path. Data on a stub
network is either sent by or addressed to a node located within
that network.
- Administration: the solution MUST not prevent mobile networks
and mobile nodes owned by administratively different entities to
attach to any part of the Internet topology for any other
considerations than administrative and security policies (both
global mobility and local-mobility are desirable).
- Scalability: NEMO support signaling and processing MUST scale to
a potentially large number of mobile networks irrespective of
their configuration, mobility frequency, and number of CNs.
- Backward Compatibility: NEMO support MUST be able to co-exist
and not interfere with existing IPv6 standards. The solution MUST
reuse standards defined in other IETF working groups and MAY only
extend them if deemed necessary. For instance, the following
mechanisms defined by other working groups MUST still function:
o Address allocation and configuration mechanism.
o Host mobility support: the solution MUST not prevent mobile
nodes and correspondent nodes, either located within or
outside the mobile network, to keep operating protocols
defined by the Mobile IP working group.
o Multicast support: the solution MUST maintain ongoing
multicast sessions of MNNs as the mobile router changes its
point of attachment. Group membership is currently gathered
by MLD.
o Access control protocols and mechanisms: NEMO support MUST
not disallow protocols and mechanisms used by visiting mobile
hosts and routers to be authenticated and authorized to gain
access to the Internet via the mobile network infrastructure
(MRs).
o Security protocols and mechanisms
o Routing protocols and mechanisms: routers deployed in mobile
networks may be routers like the others and therefrom are
expected to run in some situations a number of protocols such
as a routing protocol, Neighbor Discovery, ICMP, Router
Renumbering and others. NEMO support MUST thus not prevent
Ernst et al. Expires August 2003 [Page 7]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
usual routing protocols and mechanisms to keep working within
the mobile network and to interact with the global Internet
(home network only in the case of basic NEMO support) when
necessary.
o Seamless Mobility: the solutions MUST be compatible with
FMIPv6
- Security: NEMO support MUST comply with usual IETF security
policies and recommendations and MUST have its specific security
issues fully addressed. In practice, all NEMO support control
messages transmitted in the network MUST ensure an acceptable
level of security to prevent intruders to usurp identities.
Specifically, the following issues have to be addressed:
o Authentication of the sender to prevent identity usurpation.
o Authorization, to make sure the sender is granted permission
to perform the operation as indicated in the control message.
o Confidentiality of the data contained in the control message.
o Location Privacy: means to hide the actual location of MNNS
to third parties other than the HA if desired.
Ernst et al. Expires August 2003 [Page 8]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
5. One-liner Requirements for Basic NEMO Support
The NEMO WG will specify a unified and unique solution for "Basic
Network Mobility Support". The solution will allow all nodes in the
mobile network to be reachable via permanent IP addresses, as well as
maintain ongoing sessions as the MR changes its point of attachment
to the Internet topology. This will be done by maintaining a
bidirectional tunnel between the MR and its Home Agent. The Working
Group will investigate reusing the existing Mobile IPv6 mechanisms
for the tunnel management, or extend it if deemed necessary.
The following requirements are placed on the Basic NEMO support
solution, hereafter referred to as "the solution":
R01: The solution MUST be implemented at the IP layer level.
R02: The solution MUST set up a bi-directional tunnel between
MR and MR's Home Agent.
R03: All traffic exchanged between a MNN and a CN in the global
Internet MUST transit through the bidirectional tunnel.
R04: MNNs MUST be reachable at a permanent IP address and name.
R05: The solution MUST maintain continuous sessions (both unicast
and multicast) between MNNs and arbitrary CNs after IP
handover of (one of) the MR.
R06: The solution MUST not require modifications to any node other
than MRs and HAs.
R07: The solution MUST support fixed nodes, mobile hosts and mobile
routers in the mobile network.
R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
network link as either a home link or a foreign link.
R09: The solution MUST not prevent the proper operation of Mobile
IPv6 (i.e. the solution MUST support MIPv6-enabled MNNs and
MUST also allow MNNs to receive and process Binding Updates
from arbitrary Mobile Nodes.)
R10: The solution MUST treat all the potential configurations the
same way (whatever the number of subnets, MNNs, nested levels
of MRs, egress interfaces, ...)
R11: The solution MUST support mobile networks attaching to other
mobile networks (nested mobile networks). Although it is not
Ernst et al. Expires August 2003 [Page 9]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
fully clear how many layers of topology MUST be supported, or
the complexity requirements of those nested networks, the goal
is to support arbitrary levels of recursive networks, and only
in the case where this is impractical and protocol concerns
preclude this support should the solution impose restrictions on
nesting (e.g. path MTU).
R12: The solution MUST function for multi-homed mobile networks.
More precisely:
R13.1: The solution MUST support mobile networks with
multiple MRs,
R13.2: The solution MUST support MR with multiple interfaces,
R13.3: The solution must support MR with multiple global
addresses on an egress interface.
R14: Signaling messages between the HA and the MR MUST be secured:
R14.1: The receiver MUST be able to authenticate the sender
R14.2: The function performed by the sender MUST be authorized
for the content carried
R14.3: Anti-replay MUST be provided
R14.4: The signaling messages SHOULD be encrypted
R15: The solution MUST ensure transparent continuation of routing and
management operations over the bi-directional tunnel when the MR
is away from home. (this includes e.g. routing protocols, router
renumbering, DHCPv6, etc)
R16: The solution MUST not impact on the routing fabric neither on
the Internet addressing architecture
R17: The solution MUST ensure backward compatibility with other
standards defined by the IETF.
Ernst et al. Expires August 2003 [Page 10]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
A. Acknowledgments
The material presented in this document takes most of its text from
discussions and previous documents submitted to the NEMO working
group. This includes initial contributions from Motorola, INRIA,
Ericsson and Nokia. We are particularly grateful to Hesham Soliman
(Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who
highly helped to set up the NEMO working group. We are also grateful
to all the following people whose comments highly contributed to the
present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola),
Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon
Lach (Motorola), Mattias Petterson (Ericsson) and all the others
people who have expressed their opinions on the NEMO (formely MONET)
mailing list. Thierry Ernst wish to personally grant support to its
previous employers, INRIA, and Motorola for their support and
direction in bringing this topic up to the IETF, particularly Claude
Castelluccia (INRIA) and Hong-Yon Lach (Motorola).
B. References
[IPv6-NODE] John Loughney
"IPv6 Node Requirements"
draft-ietf-ipv6-node-requirements-01.txt
July 2002, Work in progress.
[MIPv6] David B. Johnson and C. Perkins.
"Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-20.txt,
January 2002. Work in progress.
[MOBILITY-TERMS] J. Manner
"Mobility Related Terminology
<draft-ietf-seamoby-mobility-terminology-00.txt>
August 2002. Work in progress
[NEMO-TERMS] Thierry Ernst and Hong-Yon Lach
"Terminology for Network Mobility Support",
draft-ernst-nemo-terminology.txt.
Work in progress.
[RFC1122] R. Braden (editor).
"Requirements for Internet Hosts - Communication
Layers". IETF RFC 1122, October 1989.
[RFC2119] S. Bradner
"Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, IETF, March 1997.
Ernst et al. Expires August 2003 [Page 11]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
[RFC2460] S. Deering and R. Hinden.
"Internet Protocol Version 6 (IPv6) Specification"
IETF RFC 2460, December 1998.
C. Editors's Addresses
Questions about this document can be directed to the NEMO working
group chairs:
Thierry Ernst,
Keio University.
5322 Endo, Fujisawa-shi,
Kanagawa 252-8520, Japan.
Phone : +81-466-49-1100
Fax : +81-466-49-1395
Email : ernst@sfc.wide.ad.jp
T. J. Kniveton
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043, USA
Phone : +1 650 625-2025
Fax : +1 650 625-2502
EMail : Timothy.Kniveton@Nokia.com
D. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Ernst et al. Expires August 2003 [Page 12]
INTERNET-DRAFT Network Mobility Support Requirements February 2003
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Funding for the RFC editor function is currently provided by the
Internet Society.
Ernst et al. Expires August 2003 [Page 13]