< draft-ietf-nemo-requirements-02.txt   draft-ietf-nemo-requirements-03.txt >
NEMO Working Group T. Ernst
Internet-Draft WIDE at Keio University
Expires: April 25, 2005 October 25, 2004
NEMO Working Group Thierry Ernst, Editor Network Mobility Support Goals and Requirements
Internet-Draft WIDE and INRIA draft-ietf-nemo-requirements-03
February, 2004
"Network Mobility Support Goals and Requirements"
<draft-ietf-nemo-requirements-02.txt>
Status of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract Abstract
Network mobility arises when a router connecting an entire network to Network mobility arises when a router connecting an entire network to
the Internet dynamically changes its point of attachment to the the Internet dynamically changes its point of attachment to the
Internet therefrom causing the reachability of the entire network to Internet therefrom causing the reachability of the entire network to
be changed in the topology. Such kind of network is referred to as a be changed in the topology. Such kind of network is referred to as a
mobile network. Without appropriate mechanisms, sessions established mobile network. Without appropriate mechanisms, sessions established
between nodes in the mobile network and the global Internet cannot be between nodes in the mobile network and the global Internet cannot be
maintained while the mobile router changes its point of attachment. maintained while the mobile router changes its point of attachment.
The required support mechanisms will be provided in two phases. The The required support mechanisms will be provided in two phases. The
first phase, referred to as NEMO Basic Support is to provide session first phase, referred to as NEMO Basic Support is to provide session
continuity while the necessary optimizations mechanims referred to as continuity while the necessary optimizations mechanims referred to as
NEMO Extended Support might be provided later. This document outlines NEMO Extended Support might be provided later. This document
the goals expected from network mobility support and defines the outlines the goals expected from network mobility support and defines
requirements that must be met by NEMO Basic Support solutions. the requirements that must be met by NEMO Basic Support solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04
3. NEMO Working Group Goals and Methodology . . . . . . . . . . 04
4. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 05
5. NEMO Basic Support One-liner Requirements . . . . . . . . . 09 2. NEMO Working Group Objectives and Methodology . . . . . . . 4
6. Changes From Previous Version . . . . . . . . . . . . . . . 10 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 5
3.1 Migration Transparency . . . . . . . . . . . . . . . . . . 5
3.2 Performance Transparency and Seamless Mobility . . . . . . 5
3.3 Network Mobility Support Transparency . . . . . . . . . . 5
3.4 Operational Transparency . . . . . . . . . . . . . . . . . 6
3.5 Arbitrary Configurations . . . . . . . . . . . . . . . . . 6
3.6 Local Mobility and Global Mobility . . . . . . . . . . . . 7
3.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
3.8 Backward Compatibility . . . . . . . . . . . . . . . . . . 7
3.9 Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8
3.10 Location Privacy . . . . . . . . . . . . . . . . . . . . 8
3.11 IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . 8
A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . 8
B. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Changes Between Versions . . . . . . . . . . . . . . . . . . 10
5.1 Changes between version -02 and -03 . . . . . . . . . . . 10
5.2 Changes Between Version -01 and -02 . . . . . . . . . . . 10
5.3 Changes Between Version -00 and -01 . . . . . . . . . . . 11
C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Conventions used in this document Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Intellectual Property and Copyright Statements . . . . . . . 13
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
Network mobility support is concerned with managing the mobility of Network mobility support is concerned with managing the mobility of
an entire network, viewed as a single unit, which changes its point an entire network, viewed as a single unit, which changes its point
of attachment to the Internet and thus its reachability in the of attachment to the Internet and thus its reachability in the
Internet topology. Such kind of network is referred to as a mobile Internet topology. Such kind of network is referred to as a mobile
network and includes one or more mobile routers (MRs) which connect network and includes one or more mobile routers (MRs) which connect
it to the global Internet. Nodes behind the MR(s) (MNNs) are both it to the global Internet. Nodes behind the MR(s) (MNNs) are both
fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal
structure of the mobile network will in effect be relatively stable structure of the mobile network will in effect be relatively stable
(no dynamic change of the topology), but this is not a general (no dynamic change of the topology), but this is not a general
assumption. assumption.
Cases of mobile networks include for instance: Cases of mobile networks include for instance:
- networks attached to people (Personal Area Networks or PANs): a o networks attached to people (Personal Area Networks or PANs): a
cell-phone with one cellular interface and one Bluetooth interface cell-phone with one cellular interface and one Bluetooth interface
together with a Bluetooth-enabled PDA constitute a very simple together with a Bluetooth-enabled PDA constitute a very simple
instance of a mobile network. The cell-phone is the mobile router 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 while the PDA is used for web browsing or runs a personal web
server. server.
- networks of sensors and computers deployed in vehicles: vehicles o networks of sensors and computers deployed in vehicles: vehicles
are more and more embedded with a number of processing units for are more and more embedded with a number of processing units for
safety and ease of driving reasons, as advocated by ITS safety and ease of driving reasons, as advocated by ITS
(Intelligent Transportation Systems) applications. (Intelligent Transportation Systems) applications.
- access networks deployed in public transportation (buses, o access networks deployed in public transportation (buses, trains,
trains, taxis, aircrafts): they provide Internet access to IP taxis, aircrafts): they provide Internet access to IP devices
devices carried by passengers (laptop, camera, mobile phone: host carried by passengers (laptop, camera, mobile phone: host mobility
mobility within network mobility or PANs: network mobility within within network mobility or PANs: network mobility within network
network mobility, i.e. nested mobility). mobility, i.e. nested mobility).
- ad-hoc networks connected to the Internet via a MR: for instance o 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 students in a train that both need to set up an ad-hoc network
among themselves and to get Internet connectivity through the MR among themselves and to get Internet connectivity through the MR
connecting the train to the Internet. connecting the train to the Internet.
Mobility of networks does not cause MNNs to change their own physical Mobility of networks does not cause MNNs to change their own physical
point of attachment, however they happen to change their topological point of attachment, however they happen to change their topological
location with respect to the global Internet. If network mobility is location with respect to the global Internet. If network mobility is
not explicitly supported by some mechanisms, the mobility of the MR not explicitly supported by some mechanisms, the mobility of the MR
results into MNNs losing Internet access and breaking ongoing results into MNNs losing Internet access and breaking ongoing
sessions entertained between arbitrary correspondent node (CNs) in sessions entertained between arbitrary correspondent node (CNs) in
the global Internet and those MNNs located within the mobile network. the global Internet and those MNNs located within the mobile network.
In addition, the communication path between MNNs and arbitrary In addition, the communication path between MNNs and arbitrary
correspondent nodes (CN) becomes sub-optimal, whereas multiple levels correspondent nodes (CN) becomes sub-optimal, whereas multiple levels
of mobility will cause extremely sub-optimal routing. of mobility will cause extremely sub-optimal routing.
The mechanisms required for handling such mobility issues are The mechanisms required for handling such mobility issues are
currently lacking within the IETF standards. Traditional work currently lacking within the IETF standards. Traditional work
conducted on mobility support (particularly in the Mobile IP working conducted on mobility support (particularly in the Mobile IP working
group) is to provide continuous Internet connectivity and optimal group) is to provide continuous Internet connectivity and optimal
routing to mobile hosts only (host mobility support) and are unable routing to mobile hosts only (host mobility support) and are unable
to support network mobility. The NEMO working group has therefore to support network mobility. The NEMO working group has therefore
been set up to deal with issues specific to network mobility. The been set up to deal with issues specific to network mobility. The
purpose of this document is thus to detail the methodology that will purpose of this document is thus to detail the methodology that will
be followed by the NEMO working group, its goals, and to define be followed by the NEMO working group, its goals, and to define
requirements for network mobility support. requirements for network mobility support.
This document is structured as follows: in section 3, we define the Mobility-related terms used in this document are defined in [3]
goals and methodology of the NEMO working group and we emphasize the whereas terms pertaining to network mobility specifically are defined
stepwise approach the working group has decided to follow. A number in [4]. This document is structured as follows: Section 2 defines
of desirable design goals are listed in section 4. Those design goals the rough objectives and methodology of the NEMO working group and we
serve as guidelines to edict the requirements for basic network emphasize the stepwise approach the working group has decided to
mobility support. follow. A number of desirable design goals are listed in Section 3.
Those design goals serve as guidelines to edict the requirements
2. Terminology listed in Section 4 for basic network mobility support [2].
Mobility-related terms used in this document are defined in
[MOBILITY-TERMS] whereas terms pertaining to network mobility
specifically are defined in [NEMO-TERMS].
3. NEMO Working Group Goals and Methodology 2. NEMO Working Group Objectives and Methodology
The primary goal of the NEMO work is to specify a solution which The primary objective of the NEMO work is to specify a solution which
allows mobile network nodes (MNNs) to remain connected to the allows mobile network nodes (MNNs) to remain connected to the
Internet and continuously reachable at all times while the mobile Internet and continuously reachable at all times while the mobile
network they are attached to changes its point of attachment. network they are attached to changes its point of attachment.
Secondary goals of the work is to investigate the effects of network Secondary goals of the work is to investigate the effects of network
mobility on various aspects of internet communication such as routing mobility on various aspects of internet communication such as routing
protocol changes, implications of realtime traffic and fast protocol changes, implications of realtime traffic and fast
handovers, optimizations. These should all support the primary goal handovers, optimizations. These should all support the primary goal
of reachability for mobile network nodes. Security is an important of reachability for mobile network nodes. Security is an important
consideration too, and efforts should be made to use existing consideration too, and efforts should be made to use existing
solutions if they are appropriate. Although a well-designed solution solutions if they are appropriate. Although a well-designed solution
may include security inherent in other protocols, mobile networks may include security inherent in other protocols, mobile networks
also introduce new challenges. also introduce new challenges.
For doing so, the NEMO working group has decided to take a stepwise For doing so, the NEMO working group has decided to take a stepwise
approach by standardizing a basic solution to preserve session approach by standardizing a basic solution to preserve session
continuity (NEMO Basic Support), and at the same time study the continuity (NEMO Basic Support), and at the same time study the
possible approaches and issues with providing more optimal routing possible approaches and issues with providing more optimal routing
with potentially nested mobile networks (NEMO Extended Support). with potentially nested mobile networks (NEMO Extended Support).
However, the working group is not chartered to actually standardize a However, the working group is not chartered to actually standardize a
solution to such route optimization at this point in time. solution to such route optimization at this point in time.
For NEMO Basic Support, the working group will assume that none of For NEMO Basic Support, the working group will assume that none of
the nodes behind the MR will be aware of the network's mobility, thus 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 the network's movement needs to be completely transparent to the
nodes inside the mobile network. This assumption will be made to nodes inside the mobile network. This assumption will be made to
accommodate nodes inside the network that are not generally aware of accommodate nodes inside the network that are not generally aware of
mobility. mobility.
The efforts of the Mobile IP working group have resulted in the The efforts of the Mobile IP working group have resulted in the
Mobile IPv4 and Mobile IPv6 protocols, which have already solved the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the
issue of host mobility support. Since challenges to enabling mobile issue of host mobility support. Since challenges to enabling mobile
networks are vastly reduced by this work, basic network mobility networks are vastly reduced by this work, basic network mobility
support will adopt the methods for host mobility support used in support will adopt the methods for host mobility support used in
Mobile IP, and extend them in the simplest way possible to achieve 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 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 Agent, and use bidirectional tunneling between the MR and HA to
preserve session continuity while the MR moves. The MR will acquire a preserve session continuity while the MR moves. The MR will acquire
Care-of-address from its attachment point much like what is done for a Care-of-address from its attachment point much like what is done
mobile nodes (MN) using Mobile IP. This approach allows nested mobile for mobile nodes (MN) using Mobile IP. This approach allows nested
networks, since each MR will appear to its attachment point as a mobile networks, since each MR will appear to its attachment point as
single node. a single node.
4. NEMO Suppport Design Goals 3. NEMO Support Design Goals
This section details the fundamental design goals the solutions will This section details the fundamental design goals the solutions will
tend to achieve. Those design goals will serve to edict and tend to achieve. Those design goals will serve to edict and
understand the requirements defined for forthcoming solutions. Actual understand the requirements defined for forthcoming solutions.
requirements for NEMO Basic Support are in the next section, whereas Actual requirements for NEMO Basic Support are in the next section,
NEMO Extended Support has not yet been considered. whereas NEMO Extended Support has not yet been considered.
- Migration Transparency: a permanent connectivity to the Internet 3.1 Migration Transparency
has to be provided to all MNNs while continuous sessions are
expected to be maintained as the mobile router changes its point
of attachment. For doing so, MNNs are expected to be reachable via
their permanent IP addresses.
- Performance Transparency and Seamless Mobility: NEMO support is A permanent connectivity to the Internet has to be provided to all
expected to be provided with limited signaling overhead and to MNNs while continuous sessions are expected to be maintained as the
minimize the impact of handover over applications, in terms of mobile router changes its point of attachment. For doing so, MNNs
packet loss or delay. However, although variable delays of are expected to be reachable via their permanent IP addresses.
transmission and losses between MNNs and their respective CNs
could be perceived as the network is displaced, it would not be
considered a lack of performance transparency.
- Network Mobility Support Transparency: MNNs behind the MR(s) 3.2 Performance Transparency and Seamless Mobility
don't change their own physical point of attachment as a result of
the mobile network's displacement in the Internet topology.
Consequently, NEMO support is expected to be performed by the sole
MR(s) and specific support functions on any other node than the
MR(s) would better be avoided.
- Operational Transparency: NEMO support is to be implemented at NEMO support is expected to be provided with limited signaling
the IP layer level. It is expected to be transparent to upper overhead and to minimize the impact of handover over applications, in
layers so that any upper layer protocol can run unchanged on top terms of packet loss or delay. However, although variable delays of
of an IP layer extended with NEMO support. transmission and losses between MNNs and their respective CNs could
be perceived as the network is displaced, it would not be considered
a lack of performance transparency.
- Arbitrary Configurations: The formation of a mobile network can 3.3 Network Mobility Support Transparency
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 multihomed 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 MNNs behind the MR(s) don't change their own physical point of
a few IP devices to a collection of subnets with a large attachment as a result of the mobile network's displacement in the
number of IP devices, Internet topology. Consequently, NEMO support is expected to be
performed by the sole MR(s) and specific support functions on any
other node than the MR(s) would better be avoided.
o nodes that change their point of attachment within the mobile 3.4 Operational Transparency
network,
o foreign mobile nodes that attach to the mobile network, NEMO support is to be implemented at the IP layer level. It is
expected to be transparent to upper layers so that any upper layer
protocol can run unchanged on top of an IP layer extended with NEMO
support.
o multihomed mobile network either when a single MR has 3.5 Arbitrary Configurations
multiple attachments to the internet, or when the mobile
network is attached to the Internet by means of multiple
MRs (see definition in [NEMO-TERMS]),
o nested mobile networks (mobile networks attaching to other The formation of a mobile network can exist in various levels of
mobile networks, see definition in [NEMO-TERMS]. Although the complexity. In the simplest case, a mobile network contains just a
complexity requirements of those nested networks is not mobile router and a host. In the most complicated case, a mobile
clear, it is desirable to support arbitrary levels of network is multihomed and is itself a multi-level aggregation of
recursive networks, and only in the case where this is mobile networks with collectively thousands of mobile routers and
impractical and protocol concerns preclude this support hosts. While the list of potential configurations of mobile networks
should the solution impose restrictions on nesting cannot be limited, at least the following configurations are
(e.g. path MTU), desirable:
o distinct mobility frequencies (see mobility factor in o mobile networks of any size, ranging from a sole subnet with a few
[MOBILITY-TERMS]) IP devices to a collection of subnets with a large number of IP
devices,
o distinct access medium. o nodes that change their point of attachment within the mobile
network,
In order to keep complexity minimal, transit networks are excluded o foreign mobile nodes that attach to the mobile network,
from this list. A transit network is one in which data would be
forwarded between two endpoints outside of the network, so that
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.
- Local Mobility and Global Mobility: mobile networks and mobile o multihomed mobile network either when a single MR has multiple
nodes owned by administratively different entities are expected to attachments to the internet, or when the mobile network is
be displaced within a domain boundary or between domain attached to the Internet by means of multiple MRs (see definition
boundaries. Multihoming, vertical and horizontal handoffs, and in [4] and the analys in [5]),
access control mechanisms are desirable to achieve this goal. Such
mobility type is not expected to be limited for any consideration
other than administrative and security policies.
- Scalability: NEMO support signaling and processing is expected o nested mobile networks (mobile networks attaching to other mobile
to scale to a potentially large number of mobile networks networks (see definition in [4]). Although the complexity
irrespective of their configuration, mobility frequency, size and requirements of those nested networks is not clear, it is
number of CNs. desirable 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),
- Backward Compatibility: NEMO support will have to co-exist with o distinct mobility frequencies (see mobility factor in [3])
existing IPv6 standards without interfering with them. Standards
defined in other IETF working groups have to be reused as much as
possible and extended only if deemed necessary. For instance, the
following mechanisms defined by other working groups are expected
to function without modidications:
o Address allocation and configuration mechanisms o distinct access medium.
o Host mobility support: mobile nodes and correspondent nodes, In order to keep complexity minimal, transit networks are excluded
either located within or outside the mobile network are from this list. A transit network is one in which data would be
expected to keep operating protocols defined by the Mobile IP forwarded between two endpoints outside of the network, so that the
working group. This include mechanisms for host mobility network itself simply serves as a transitional conduit for packet
support (Mobile IPv6) and seamless mobility (FMIPv6). 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.
o Multicast support entertained by MNNs are expected to be 3.6 Local Mobility and Global Mobility
maintained while the mobile router changes its point of
attachment.
o Access control protocols and mechanisms used by visiting Mobile networks and mobile nodes owned by administratively different
mobile hosts and routers to be authenticated and authorized entities are expected to be displaced within a domain boundary or
to gain access to the Internet via the mobile network between domain boundaries. Multihoming, vertical and horizontal
infrastructure (MRs). handoffs, and access control mechanisms are desirable to achieve this
goal. Such mobility type is not expected to be limited for any
consideration other than administrative and security policies.
o Security protocols and mechanisms 3.7 Scalability
o Mechanisms performed by routers deployed both in the visited NEMO support signaling and processing is expected to scale to a
networks and in mobile networks (routing protocols, Neighbor potentially large number of mobile networks irrespective of their
Discovery, ICMP, Router Renumbering, ...). configuration, mobility frequency, size and number of CNs.
- Secure Signaling: NEMO support will have to comply with usual 3.8 Backward Compatibility
IETF security policies and recommendations and is expected to have
its specific security issues fully addressed. In practice, all
NEMO support control messages transmitted in the network will have
to ensure an acceptable level of security to prevent intruders to
usurp identities and forge data. Specifically, the following
issues have to be considered:
o Authentication of the sender to prevent identity usurpation. NEMO support will have to co-exist with existing IPv6 standards
without interfering with them. Standards defined in other IETF
working groups have to be reused as much as possible and extended
only if deemed necessary. For instance, the following mechanisms
defined by other working groups are expected to function without
modidications:
o Authorization, to make sure the sender is granted permission o Address allocation and configuration mechanisms
to perform the operation as indicated in the control message.
o Confidentiality of the data contained in the control message. o Host mobility support: mobile nodes and correspondent nodes,
either located within or outside the mobile network are expected
to keep operating protocols defined by the Mobile IP working
group. This include mechanisms for host mobility support (Mobile
IPv6) and seamless mobility (FMIPv6).
- Location Privacy: means to hide the actual location of MNNS to o Multicast support entertained by MNNs are expected to be
third parties other than the HA are desired. In which extend this maintained while the mobile router changes its point of
has to be enforced is not clear since it is always possible to attachment.
determine the topological location by analysing IPv6 headers. It
would thus require some kind of encryption of the IPv6 header to
prevent third parties to monitor IPv6 addresses between the MR and
the HA. On the other hand, it is at the very least desirable to
provide means for MNNs to hide their real topological location to
their CNs.
- IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co- o Access control protocols and mechanisms used by visiting mobile
exist with IPv6 for a long time, so it is desirable to ensure hosts and routers to be authenticated and authorized to gain
mechanisms developped for NEMO will be able to traverse such access to the Internet via the mobile network infrastructure
clouds. (MRs).
5. NEMO Basic Support One-liner Requirements o Security protocols and mechanisms
The NEMO WG will specify a unified and unique "Network Mobility Basic o Mechanisms performed by routers deployed both in the visited
Support" solution. The solution will allow all nodes in the mobile networks and in mobile networks (routing protocols, Neighbor
network to be reachable via permanent IP addresses, as well as Discovery, ICMP, Router Renumbering, ...).
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 a 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 NEMO Basic Support 3.9 Secure Signaling
solution, hereafter referred to as "the solution":
R01: The solution MUST be implemented at the IP layer level. NEMO support will have to comply with usual IETF security policies
and recommendations and is expected to have its specific security
issues fully addressed. In practice, all NEMO support control
messages transmitted in the network will have to ensure an acceptable
level of security to prevent intruders to usurp identities and forge
data. Specifically, the following issues have to be considered:
R02: The solution MUST set up a bi-directional tunnel between a o Authentication of the sender to prevent identity usurpation.
MR and its Home Agent.
R03: All traffic exchanged between a MNN and a CN in the global o Authorization, to make sure the sender is granted permission to
Internet MUST transit through the bidirectional tunnel. perform the operation as indicated in the control message.
R04: MNNs MUST be reachable at a permanent IP address and name. o Confidentiality of the data contained in the control message.
R05: The solution MUST maintain continuous sessions (both unicast 3.10 Location Privacy
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 Means to hide the actual location of MNNS to third parties other than
than MRs and HAs. the HA are desired. In which extend this has to be enforced is not
clear since it is always possible to determine the topological
location by analysing IPv6 headers. It would thus require some kind
of encryption of the IPv6 header to prevent third parties to monitor
IPv6 addresses between the MR and the HA. On the other hand, it is
at the very least desirable to provide means for MNNs to hide their
real topological location to their CNs.
R07: The solution MUST support fixed nodes, mobile hosts and mobile 3.11 IPv4 and NAT Traversal
routers in the mobile network.
R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time,
network link as either a home link or a foreign link. so it is desirable to ensure mechanisms developped for NEMO will be
able to traverse such clouds.
R09: The solution MUST ensure backward compatibility with other 4. NEMO Basic Support One-Liner Requirements
standards defined by the IETF. This include particularly:
R09:1: The solution MUST not prevent the proper operation of The NEMO WG is to specify a unified and unique "Network Mobility
Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled Basic Support" solution, hereafter referred to as "the solution".
MNNs to operate either the CN, HA, or MN operations This solution is to allow all nodes in the mobile network to be
defined in [MIPv6]) reachable via permanent IP addresses, as well as maintain ongoing
sessions as the MR changes its point of attachment to the Internet
topology. This is to be done by maintaining a bidirectional tunnel
between a MR and its Home Agent.
R10: The solution MUST treat all the potential configurations the For doing so, the NEMO Working Group has decided to investigate
same way (whatever the number of subnets, MNNs, nested levels reusing the existing Mobile IPv6 [1] mechanisms for the tunnel
of MRs, egress interfaces, ...) management, or extend it if deemed necessary.
R11: The solution MUST support at least 2 levels of nested mobile The list of requirements below have been placed on the NEMO Basic
networks, while, in principle, arbitrary levels of recursive Support solution. They have been mostly met by the resulting
mobile networks SHOULD be supported. specification which can now be found in [2].
R12: The solution MUST function for multihomed MR and multihomed R01: The solution MUST be implemented at the IP layer level.
mobile networks as defined in [NEMO-TERMS]).
R13: NEMO Support signaling over the bidirectional MUST be minimized R02: The solution MUST set up a bi-directional tunnel between a
Mobile Router and its Home Agent (MRHA tunnel)
R14: Signaling messages between the HA and the MR MUST be secured: R03: All traffic exchanged between a MNN and a CN in the global
Internet MUST transit through the bidirectional MRHA tunnel.
R14.1: The receiver MUST be able to authenticate the sender R04: MNNs MUST be reachable at a permanent IP address and name.
R14.2: The function performed by the sender MUST be authorized R05: The solution MUST maintain continuous sessions (both unicast
for the content carried and multicast) between MNNs and arbitrary CNs after IP handover of
(one of) the MR.
R14.3: Anti-replay MUST be provided R06: The solution MUST not require modifications to any node other
than MRs and HAs.
R14.4: The signaling messages MAY be encrypted R07: The solution MUST support fixed nodes, mobile hosts and
mobile routers in the mobile network.
R15: The solution MUST ensure transparent continuation of routing and R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
management operations over the bi-directional tunnel (this network link as either a home link or a foreign link.
includes e.g. unicast and multicast routing protocols, router
renumbering, DHCPv6, etc)
R16: The solution MUST not impact on the routing fabric neither on R09: The solution MUST ensure backward compatibility with other
the Internet addressing architecture. [ACCORDING TO IETF56 standards defined by the IETF. This include particularly:
minutes, SHOULD BE REMOVED]
R18: The solution MAY preserve sessions established through R09:1: The solution MUST not prevent the proper operation of
another egress interface when one fails Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs
to operate either the CN, HA, or MN operations defined in [1])
6. Changes Between Versions R10: The solution MUST treat all the potential configurations the
same way (whatever the number of subnets, MNNs, nested levels of
MRs, egress interfaces, ...)
6.1. Changes Between Version -01 and -02 R11: The solution MUST support at least 2 levels of nested mobile
networks, while, in principle, arbitrary levels of recursive
mobile networks SHOULD be supported.
R12: The solution MUST function for multihomed MR and multihomed
mobile networks as defined in [4].
R13: NEMO Support signaling over the bidirectional MUST be
minimized
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 MAY be encrypted
R15: The solution MUST ensure transparent continuation of routing
and management operations over the bi-directional tunnel (this
includes e.g. unicast and multicast routing protocols, router
renumbering, DHCPv6, etc)
R16: The solution MUST not impact on the routing fabric neither on
the Internet addressing architecture. [ACCORDING TO IETF56
minutes, SHOULD BE REMOVED]
R18: The solution MAY preserve sessions established through
another egress interface when one fails
5. Changes Between Versions
5.1 Changes between version -02 and -03
- Mostly cosmetic changes
- Merged section Terminology into Introduction
- Cross-references with other NEMO WG docs
- Changed the introducion of section Section 4 and added reference to
NEMO Basic Support's resulting specification.
5.2 Changes Between Version -01 and -02
- removed sub-items in R12 (sub-cases are contained into the - removed sub-items in R12 (sub-cases are contained into the
definition of multihoming) definition of multihoming)
- minor typos - minor typos
- R15: Added "multicast" - R15: Added "multicast"
- R14.4: SHOULD softened to MAY according to discussion at IETF56th - R14.4: SHOULD softened to MAY according to discussion at IETF56th
meeting. meeting.
- R17 moved to R09 and contains former R09 as a sub-case. - R17 moved to R09 and contains former R09 as a sub-case.
- R18: relaxed from "SHOULD" to may based on Vijay Devarapalli - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli
comment (030718) comment (030718)
6.2 Changes Between Version -00 and -01 5.3 Changes Between Version -00 and -01
- title of documents: included the word "goals" - title of documents: included the word "goals"
- entire document: some rewording - entire document: some rewording
- section 4: changed title of section to "NEMO Design Goals". - section 4: changed title of section to "NEMO Design Goals".
- section 4: removed "MUST" and "MAY" - section 4: removed "MUST" and "MAY"
- section 4: more text about location privacy - section 4: more text about location privacy
- section 4: changed "Administration" paragraph to "Local and - section 4: changed "Administration" paragraph to "Local and Global
Global Mobility". Text enhanced. Mobility". Text enhanced.
- section 5:
R02: replace "between MR and MR's HA" with "a MR and its HA"
R11: specified at least 2 levels
R12: replaced "support" with "function" and add "multihomed MR"
R13.x renumbered to R12.x since part of R12 (editing mistake)
R13 and R18: new requirements proposed by editor
and minor changes in the formulation of other Requirements - section 5: R02: replace "between MR and MR's HA" with "a MR and its
HA" R11: specified at least 2 levels R12: replaced "support" with
"function" and add "multihomed MR" R13.x renumbered to R12.x since
part of R12 (editing mistake) R13 and R18: new requirements proposed
by editor and minor changes in the formulation of other Requirements
A. Acknowledgments 6. Acknowledgments
The material presented in this document takes most of its text from The material presented in this document takes most of its text from
discussions and previous documents submitted to the NEMO working discussions and previous documents submitted to the NEMO working
group. This includes initial contributions from Motorola, INRIA, group. This includes initial contributions from Motorola, INRIA,
Ericsson and Nokia. We are particularly grateful to Hesham Soliman Ericsson and Nokia. We are particularly grateful to Hesham Soliman
(Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who (Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who
highly helped to set up the NEMO working group. We are also grateful highly helped to set up the NEMO working group. We are also grateful
to all the following people whose comments highly contributed to the to all the following people whose comments highly contributed to the
present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola), present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola),
Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon
Lach (Motorola), Mattias Petterson (Ericsson) and all the others Lach (Motorola), Mattias Petterson (Ericsson) and all the others
people who have expressed their opinions on the NEMO (formely MONET) people who have expressed their opinions on the NEMO (formely MONET)
mailing list. Thierry Ernst wish to personally grant support to its mailing list. Thierry Ernst wish to personally grant support to its
previous employers, INRIA, and Motorola for their support and previous employers, INRIA, and Motorola for their support and
direction in bringing this topic up to the IETF, particularly Claude direction in bringing this topic up to the IETF, particularly Claude
Castelluccia (INRIA) and Hong-Yon Lach (Motorola). Castelluccia (INRIA) and Hong-Yon Lach (Motorola).
B. References 7 References
[IPv6-NODE] John Loughney [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
"IPv6 Node Requirements" IPv6", RFC 3775, June 2004.
draft-ietf-ipv6-node-requirements.txt
Work in progress.
[MobileIPv4] Charles Perkins [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
"IP Mobility Support" Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
RFC 2002, IETF, October 1996. June 2004.
[MobileIPv6] David B. Johnson and C. Perkins. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
"Mobility Support in IPv6" 3753, June 2004.
draft-ietf-mobileip-ipv6.txt,
Work in progress.
[MOBILITY-TERMS] J. Manner [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
"Mobility Related Terminology draft-ietf-nemo-terminology-02 (work in progress), October 2004.
<draft-ietf-seamoby-mobility-terminology.txt>
Work in progress.
[NEMO-TERMS] Thierry Ernst and Hong-Yon Lach [5] Ng, C-W., Paik, E-K. and T. Ernst, "Analysis of Multihoming in
"Terminology for Network Mobility Support", Network Mobility Support", draft-ietf-nemo-multihoming-issues-01
draft-ietf-nemo-terminology.txt (work in progress), October 2004.
Work in progress.
[RFC1122] R. Braden (editor). [6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network
"Requirements for Internet Hosts - Communication Models", draft-ietf-nemo-home-network-models-01 (work in
Layers". IETF RFC 1122, October 1989. progress), October 2004.
[RFC2119] S. Bradner [7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
"Key words for use in RFCs to Indicate Requirement IETF RFC 2460, December 1998.
Levels", BCP 14, RFC 2119, IETF, March 1997.
[RFC2460] S. Deering and R. Hinden. Author's Address
"Internet Protocol Version 6 (IPv6) Specification"
IETF RFC 2460, December 1998.
C. Editors's Addresses Thierry Ernst
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Questions about this document can be directed to the NEMO working Phone: +81-44-580-1600
group chairs: Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Thierry Ernst, Intellectual Property Statement
Keio University.
K-square Town Campus
1488-8 Ogura, Saiwai-ku, Kawasaki
Kanagawa, 212-0054 Japan
Phone : +81-44-580-1600
Fax : +81-44-580-1437
Email : ernst@sfc.wide.ad.jp
T. J. Kniveton The IETF takes no position regarding the validity or scope of any
Communications Systems Lab Intellectual Property Rights or other rights that might be claimed to
Nokia Research Center pertain to the implementation or use of the technology described in
313 Fairchild Drive this document or the extent to which any license under such rights
Mountain View, California 94043, USA might or might not be available; nor does it represent that it has
Phone : +1 650 625-2025 made any independent effort to identify any such rights. Information
Fax : +1 650 625-2502 on the procedures with respect to rights in RFC documents can be
EMail : Timothy.Kniveton@Nokia.com found in BCP 78 and BCP 79.
D. Full Copyright Statement 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.
Copyright (C) The Internet Society (2002). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Disclaimer of Validity
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 This document and the information contained herein are provided on an
revoked by the Internet Society or its successors or assigns. "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.
This document and the information contained herein is provided on an Copyright Statement
"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 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. Internet Society.
 End of changes. 123 change blocks. 
349 lines changed or deleted 372 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/