< draft-ietf-nemo-requirements-00.txt   draft-ietf-nemo-requirements-01.txt >
NEMO Working Group Thierry Ernst, Editor NEMO Working Group Thierry Ernst, Editor
Internet-Draft INRIA and WIDE Internet-Draft WIDE and INRIA
February, 2003 May, 2003
"Network Mobility Support Requirements" "Network Mobility Support Goals and Requirements"
<draft-ietf-nemo-requirements-00.txt> <draft-ietf-nemo-requirements-01.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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.
Abstract Abstract
Network mobility arises when an entire network changes its point of Network mobility arises when a router connecting an entire network to
attachment to the Internet and thus its reachability in the topology. the Internet dynamically changes its point of attachment to the
The mobile network is viewed as a unit and is connected to the global Internet therefrom causing the reachability of the entire network to
Internet by one or more mobile routers. In contrast with host be changed in the topology. Such kind of network is referred to as a
mobility support which aims at providing continuous Internet mobile network. Without appropriate mechanisms, sessions established
connectivity to mobile hosts only, network mobility support is to between nodes in the mobile network and the global Internet cannot be
provide continuous Internet sessions not only to the mobile router maintained while the mobile router changes its point of attachment.
connecting the mobile network to the global Internet, but also to The required support mechanisms will be provided in two phases. The
nodes behind the mobile router. The purpose of this document is to first phase, referred to as NEMO Basic Support is to provide session
list the requirements that must be met by network mobility support continuity while the necessary optimizations mechanims referred to as
solutions in IPv6. NEMO Extended Support might be provided later. This document outlines
the goals expected from network mobility support and defines the
requirements that must be met by NEMO Basic Support solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04
3. Network Mobility Goals and Methodology . . . . . . . . . . . 04 3. NEMO Working Group Goals and Methodology . . . . . . . . . . 04
4. General Purpose Guidelines for the Solutions . . . . . . . . 05 4. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 05
5. One-liner Requirements for Basic NEMO Support. . . . . . . . 09 5. NEMO Basic Support One-liner Requirements . . . . . . . . . 09
6. Changes From Previous Version . . . . . . . . . . . . . . . 11
A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11
B. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 B. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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 (keeping the same address on the mobile network at all times), fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal
and mobile (entering and leaving the mobile network as they roam with structure of the mobile network will in effect be relatively stable
respect to it). In most cases, the internal structure of the mobile (no dynamic change of the topology), but this is not a general
network will in effect be relatively stable (no dynamic change of the assumption.
topology), but this is not a general 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 - 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.
skipping to change at page 3, line 44 skipping to change at page 3, line 43
trains, taxis, aircrafts): they provide Internet access to IP trains, taxis, aircrafts): they provide Internet access to IP
devices carried by passengers (laptop, camera, mobile phone: host devices carried by passengers (laptop, camera, mobile phone: host
mobility within network mobility or PANs: network mobility within mobility within network mobility or PANs: network mobility within
network mobility, i.e. nested mobility). network mobility, i.e. nested mobility).
- ad-hoc networks connected to the Internet via a MR: for instance - 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.
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 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 which results in lack of location with respect to the global Internet. If network mobility is
Internet access and broken sessions if no supporting mechanisms are not explicitly supported by some mechanisms, the mobility of the MR
deployed. In addition, communication between a MNN and an arbitrary results into MNNs losing Internet access and breaking ongoing
Correspondent Node (CN) may result in extremely suboptimal paths, sessions entertained between arbitrary correspondent node (CNs) in
particularly when mobile networks are nested or when the CN is itself the global Internet and those MNNs located within the mobile network.
mobile. In addition, the communication path between MNNs and arbitrary
correspondent nodes (CN) becomes sub-optimal, whereas multiple levels
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. The NEMO working group currently lacking within the IETF standards. Traditional work
has therefore been set up to deal with those. The purpose of this conducted on mobility support (particularly in the Mobile IP working
document is thus to detail the methodology that will be followed by group) is to provide continuous Internet connectivity and optimal
the NEMO working group and to list requirements for network mobility routing to mobile hosts only (host mobility support) and are unable
support. to support network mobility. The NEMO working group has therefore
been set up to deal with issues specific to network mobility. The
purpose of this document is thus to detail the methodology that will
be followed by the NEMO working group, its goals, and to define
requirements for network mobility support.
This document is structured as follows: first, section 2 introduces This document is structured as follows: in section 3, we define the
the terminology for network mobility. In section 3, we define the goals and methodology of the NEMO working group and we emphasize the
goals and methodology of the working group and we emphasize the
stepwise approach the working group has decided to follow. A number 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 of desirable design goals are listed in section 4. Those design goals
edict the requirements for basic network mobility support. serve as guidelines to edict the requirements for basic network
mobility support.
2. Terminology 2. Terminology
Terms used in this document are taken from [MIPv6] and [MOBILITY- Mobility-related terms used in this document are defined in
TERMS]. Additional terms pertaining to network mobility specifically [MOBILITY-TERMS] whereas terms pertaining to network mobility
are defined in [NEMO-TERMS]. 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 3. NEMO Working Group Goals and Methodology
The primary goal of the NEMO work is to specify a solution which The primary goal 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 (basic network mobility support), and at the same time continuity (NEMO Basic Support), and at the same time study the
study the possible approaches and issues with providing more optimal possible approaches and issues with providing more optimal routing
routing with potentially nested mobile networks (extended network with potentially nested mobile networks (NEMO Extended Support).
mobility support). However, the working group is not chartered to However, the working group is not chartered to actually standardize a
actually standardize a solution to such route optimization at this solution to such route optimization at this point in time.
point in time.
For basic NEMO 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 [7] and Mobile IPv6 [6] protocols, which have already Mobile IPv4 and Mobile IPv6 protocols, which have already solved the
solved the issue of host mobility support. Since challenges to issue of host mobility support. Since challenges to enabling mobile
enabling mobile networks are vastly reduced by this work, basic networks are vastly reduced by this work, basic network mobility
network mobility support will adopt the methods for host mobility support will adopt the methods for host mobility support used in
support used in Mobile IP, and extend them in the simplest way Mobile IP, and extend them in the simplest way possible to achieve
possible to achieve its goals. The basic support solution is for each its goals. The basic support solution is for each MR to have a Home
MR to have a Home Agent, and use bidirectional tunneling between the Agent, and use bidirectional tunneling between the MR and HA to
MR and HA to preserve session continuity while the MR moves. The MR preserve session continuity while the MR moves. The MR will acquire a
will acquire a Care-of-address from its attachment point much like Care-of-address from its attachment point much like what is done for
what is done for mobile nodes (MN) using Mobile IP. This approach mobile nodes (MN) using Mobile IP. This approach allows nested mobile
allows nested mobile networks, since each MR will appear to its networks, since each MR will appear to its attachment point as a
attachment point as a single node. single node.
4. General Purpose Guidelines for the Solutions 4. NEMO Suppport Design Goals
This section lists a number of guidelines which are used to edict the This section details the fundamental design goals the solutions will
requirements that MUST or SHOULD be met by forthcoming network tend to achieve. Those design goals will serve to edict and
mobility support solutions, for both basic NEMO support and extended understand the requirements defined for forthcoming solutions. Actual
NEMO support. requirements for NEMO Basic Support are in the next section, whereas
NEMO Extended Support has not yet been considered.
- Migration Transparency: a permanent connectivity to the Internet - Migration Transparency: a permanent connectivity to the Internet
MUST be provided to all MNNs while continuous sessions MUST be has to be provided to all MNNs while continuous sessions are
maintained as the mobile router changes its point of attachment. expected to be maintained as the mobile router changes its point
For doing so, MNNs will be reachable via their permanent IP of attachment. For doing so, MNNs are expected to be reachable via
addresses. their permanent IP addresses.
- Performance Transparency (Seamless Mobility): NEMO support - Performance Transparency and Seamless Mobility: NEMO support is
SHOULD provide limited signaling overhead and ideally SHOULD expected to be provided with limited signaling overhead and to
minimize the impact of handover on applications, in terms of minimize the impact of handover over applications, in terms of
packet loss or delay. Variable delays of transmission and losses packet loss or delay. However, although variable delays of
between MNNs and their respective CNs as the network is moving are transmission and losses between MNNs and their respective CNs
not considered lack of performance transparency. 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) - Network Mobility Support Transparency: MNNs behind the MR(s)
don't change their own point of attachment as a result of the don't change their own physical point of attachment as a result of
mobile network's displacement in the Internet topology. the mobile network's displacement in the Internet topology.
Consequently, NEMO support is better performed by the sole MR(s) Consequently, NEMO support is expected to be performed by the sole
and specific support functions on any other nodes than the MR(s) MR(s) and specific support functions on any other node than the
SHOULD be avoided. MR(s) would better be avoided.
- Operational Transparency: NEMO support MUST be implemented at - Operational Transparency: NEMO support is to be implemented at
the IP layer level. It MUST be transparent to any upper layer so the IP layer level. It is expected to be transparent to upper
that any upper layer protocol can run unchanged on top of an IP layers so that any upper layer protocol can run unchanged on top
layer extended with NEMO support. of an IP layer extended with NEMO support.
- Arbitrary Configurations: The formation of a mobile network can - Arbitrary Configurations: The formation of a mobile network can
exist in various levels of complexity. In the simplest case, a exist in various levels of complexity. In the simplest case, a
mobile network contains just a mobile router and a host. In the mobile network contains just a mobile router and a host. In the
most complicated case, a mobile network is multi-homed and is most complicated case, a mobile network is multi-homed and is
itself a multi-level aggregation of mobile networks with itself a multi-level aggregation of mobile networks with
collectively thousands of mobile routers and hosts. While the list collectively thousands of mobile routers and hosts. While the list
of potential configurations of mobile networks cannot be limited, of potential configurations of mobile networks cannot be limited,
at least the following configurations are desirable: at least the following configurations are desirable:
o mobile networks of any size, ranging from a sole subnet with o mobile networks of any size, ranging from a sole subnet with
a few IP devices to a collection of subnets with a large a few IP devices to a collection of subnets with a large
number of IP devices, 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 o nodes that change their point of attachment within the mobile
network. network,
o nested mobile networks (see definition in [NEMO-TERMS]. o foreign mobile nodes that attach to the mobile network,
o mobile networks displaced within a domain boundary (local o multi-homed mobile network either when a single MR has
mobility) or between domain boundaries (global mobility). 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 distinct mobility frequencies. o nested mobile networks (mobile networks attaching to other
mobile networks, see definition in [NEMO-TERMS]. Although the
complexity requirements of those nested networks is not
clear, it is 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),
o distinct mobility frequencies,
o distinct access medium. o distinct access medium.
In order to keep complexity minimal, transit networks are excluded In order to keep complexity minimal, transit networks are excluded
from this list. A transit network is one in which data would be from this list. A transit network is one in which data would be
forwarded between two endpoints outside of the network, so that forwarded between two endpoints outside of the network, so that
the network itself simply serves as a transitional conduit for the network itself simply serves as a transitional conduit for
packet forwarding. A stub network (leaf network), on the other packet forwarding. A stub network (leaf network), on the other
hand, does not serve as a data forwarding path. Data on a stub 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 network is either sent by or addressed to a node located within
that network. that network.
- Administration: the solution MUST not prevent mobile networks - Local Mobility and Global Mobility: mobile networks and mobile
and mobile nodes owned by administratively different entities to nodes owned by administratively different entities are expected to
attach to any part of the Internet topology for any other be displaced within a domain boundary or between domain
considerations than administrative and security policies (both boundaries. Multihoming, vertical and horizontal handoffs, and
global mobility and local-mobility are desirable). 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 MUST scale to - Scalability: NEMO support signaling and processing is expected
a potentially large number of mobile networks irrespective of to scale to a potentially large number of mobile networks
their configuration, mobility frequency, and number of CNs. irrespective of their configuration, mobility frequency, size and
number of CNs.
- Backward Compatibility: NEMO support MUST be able to co-exist - Backward Compatibility: NEMO support will have to co-exist with
and not interfere with existing IPv6 standards. The solution MUST existing IPv6 standards without interfering with them. Standards
reuse standards defined in other IETF working groups and MAY only defined in other IETF working groups have to be reused as much as
extend them if deemed necessary. For instance, the following possible and extended only if deemed necessary. For instance, the
mechanisms defined by other working groups MUST still function: following mechanisms defined by other working groups are expected
to function without modidications:
o Address allocation and configuration mechanism. o Address allocation and configuration mechanisms
o Host mobility support: the solution MUST not prevent mobile o Host mobility support: mobile nodes and correspondent nodes,
nodes and correspondent nodes, either located within or either located within or outside the mobile network are
outside the mobile network, to keep operating protocols expected to keep operating protocols defined by the Mobile IP
defined by the Mobile IP working group. working group. This include mechanisms for host mobility
support (Mobile IPv6) and seamless mobility (FMIPv6).
o Multicast support: the solution MUST maintain ongoing o Multicast support entertained by MNNs are expected to be
multicast sessions of MNNs as the mobile router changes its maintained while the mobile router changes its point of
point of attachment. Group membership is currently gathered attachment.
by MLD.
o Access control protocols and mechanisms: NEMO support MUST o Access control protocols and mechanisms used by visiting
not disallow protocols and mechanisms used by visiting mobile mobile hosts and routers to be authenticated and authorized
hosts and routers to be authenticated and authorized to gain to gain access to the Internet via the mobile network
access to the Internet via the mobile network infrastructure infrastructure (MRs).
(MRs).
o Security protocols and mechanisms o Security protocols and mechanisms
o Routing protocols and mechanisms: routers deployed in mobile o Mechanisms performed by routers deployed both in the visited
networks may be routers like the others and therefrom are networks and in mobile networks (routing protocols, Neighbor
expected to run in some situations a number of protocols such Discovery, ICMP, Router Renumbering, ...).
as a routing protocol, Neighbor Discovery, ICMP, Router
Renumbering and others. NEMO support MUST thus not prevent
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 - Secure Signaling: NEMO support will have to comply with usual
policies and recommendations and MUST have its specific security IETF security policies and recommendations and is expected to have
issues fully addressed. In practice, all NEMO support control its specific security issues fully addressed. In practice, all
messages transmitted in the network MUST ensure an acceptable NEMO support control messages transmitted in the network will have
level of security to prevent intruders to usurp identities. to ensure an acceptable level of security to prevent intruders to
Specifically, the following issues have to be addressed: usurp identities and forge data. Specifically, the following
issues have to be considered:
o Authentication of the sender to prevent identity usurpation. o Authentication of the sender to prevent identity usurpation.
o Authorization, to make sure the sender is granted permission o Authorization, to make sure the sender is granted permission
to perform the operation as indicated in the control message. to perform the operation as indicated in the control message.
o Confidentiality of the data contained 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 - Location Privacy: means to hide the actual location of MNNS to
to third parties other than the HA if desired. third parties other than 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.
5. One-liner Requirements for Basic NEMO Support - IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co-
exist with IPv6 for a long time, so it is desirable to ensure
mechanisms developped for NEMO will be able to traverse such
clouds.
5. NEMO Basic Support One-liner Requirements
The NEMO WG will specify a unified and unique solution for "Basic The NEMO WG will specify a unified and unique solution for "Basic
Network Mobility Support". The solution will allow all nodes in the Network Mobility Support". The solution will allow all nodes in the
mobile network to be reachable via permanent IP addresses, as well as mobile network to be reachable via permanent IP addresses, as well as
maintain ongoing sessions as the MR changes its point of attachment maintain ongoing sessions as the MR changes its point of attachment
to the Internet topology. This will be done by maintaining a to the Internet topology. This will be done by maintaining a
bidirectional tunnel between the MR and its Home Agent. The Working bidirectional tunnel between a MR and its Home Agent. The Working
Group will investigate reusing the existing Mobile IPv6 mechanisms Group will investigate reusing the existing Mobile IPv6 mechanisms
for the tunnel management, or extend it if deemed necessary. for the tunnel management, or extend it if deemed necessary.
The following requirements are placed on the Basic NEMO support The following requirements are placed on the NEMO Basic Support
solution, hereafter referred to as "the solution": solution, hereafter referred to as "the solution":
R01: The solution MUST be implemented at the IP layer level. R01: The solution MUST be implemented at the IP layer level.
R02: The solution MUST set up a bi-directional tunnel between R02: The solution MUST set up a bi-directional tunnel between a
MR and MR's Home Agent. MR and its Home Agent.
R03: All traffic exchanged between a MNN and a CN in the global R03: All traffic exchanged between a MNN and a CN in the global
Internet MUST transit through the bidirectional tunnel. Internet MUST transit through the bidirectional tunnel.
R04: MNNs MUST be reachable at a permanent IP address and name. R04: MNNs MUST be reachable at a permanent IP address and name.
R05: The solution MUST maintain continuous sessions (both unicast R05: The solution MUST maintain continuous sessions (both unicast
and multicast) between MNNs and arbitrary CNs after IP and multicast) between MNNs and arbitrary CNs after IP
handover of (one of) the MR. handover of (one of) the MR.
R06: The solution MUST not require modifications to any node other R06: The solution MUST not require modifications to any node other
than MRs and HAs. than MRs and HAs.
R07: The solution MUST support fixed nodes, mobile hosts and mobile R07: The solution MUST support fixed nodes, mobile hosts and mobile
routers in the mobile network. routers in the mobile network.
R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
network link as either a home link or a foreign link. network link as either a home link or a foreign link.
R09: The solution MUST not prevent the proper operation of Mobile R09: The solution MUST not prevent the proper operation of Mobile
IPv6 (i.e. the solution MUST support MIPv6-enabled MNNs and IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to operate
MUST also allow MNNs to receive and process Binding Updates either the CN, HA, or MN operations defined in [MIPv6])
from arbitrary Mobile Nodes.) [SHOULD BE MOVED UNDER R17]
R10: The solution MUST treat all the potential configurations the R10: The solution MUST treat all the potential configurations the
same way (whatever the number of subnets, MNNs, nested levels same way (whatever the number of subnets, MNNs, nested levels
of MRs, egress interfaces, ...) of MRs, egress interfaces, ...)
R11: The solution MUST support mobile networks attaching to other R11: The solution MUST support at least 2 levels of nested mobile
mobile networks (nested mobile networks). Although it is not networks, while, in principle, arbitrary levels of recursive
fully clear how many layers of topology MUST be supported, or mobile networks SHOULD be supported.
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. R12: The solution MUST function for multihomed MR and multihomed
More precisely: mobile networks as defined in [NEMO-TERMS]). Particularly:
R13.1: The solution MUST support mobile networks with R12.1: The solution MUST function for multi-MR mobile networks
multiple MRs,
R13.2: The solution MUST support MR with multiple interfaces, R12.2: The solution MUST function for multi-egress
interfaces
R13.3: The solution must support MR with multiple global R12.3: The solution MUST function for MR with multiple global
addresses on an egress interface. addresses on an egress interface.
[I PROPOSE TO REMOVE R12.1, 2 and 3 BECAUSE THIS IS
CONTAINED IN THE DEFINITION IN [NEMO-TERMS]].
R13: NEMO Support signaling over the bidirectional MUST be minimized
[NEW REQUIREMENT PROPOSED BY EDITOR]
R14: Signaling messages between the HA and the MR MUST be secured: R14: Signaling messages between the HA and the MR MUST be secured:
R14.1: The receiver MUST be able to authenticate the sender R14.1: The receiver MUST be able to authenticate the sender
R14.2: The function performed by the sender MUST be authorized R14.2: The function performed by the sender MUST be authorized
for the content carried for the content carried
R14.3: Anti-replay MUST be provided R14.3: Anti-replay MUST be provided
R14.4: The signaling messages SHOULD be encrypted R14.4: The signaling messages SHOULD be encrypted [ACCORDING TO
DISCUSSION AT IETF56, SHALL BE REMOVED or SOFTENED TO
"MAY" (?)]
R15: The solution MUST ensure transparent continuation of routing and R15: The solution MUST ensure transparent continuation of routing and
management operations over the bi-directional tunnel when the MR management operations over the bi-directional tunnel when the MR
is away from home. (this includes e.g. routing protocols, router is away from home. (this includes e.g. routing protocols, router
renumbering, DHCPv6, etc) renumbering, DHCPv6, etc)
R16: The solution MUST not impact on the routing fabric neither on R16: The solution MUST not impact on the routing fabric neither on
the Internet addressing architecture the Internet addressing architecture. [ACCORDING TO IETF56
minutes, SHOULD BE REMOVED]
R17: The solution MUST ensure backward compatibility with other R17: The solution MUST ensure backward compatibility with other
standards defined by the IETF. standards defined by the IETF [SPECIFIC PROTOCOLS SHOULD BE
EXPLICITLY LISTED: MLD, ... etc. PLEASE CONTRIBUTE THE NAMES OF
PROTOCOLS TO BE INCLUDED ON THE MAILING LIST. MAYBE MIPV6 COULD
BE INCLUDED HERE INSTEAD OF R09.] Particularly:
R18: The solution SHOULD preserve sessions established through
another egress interface when one fails [PROPOSED BY EDITOR OF
THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE
MAILING LIST]
6. Changes since last version
- title of documents: included the word "goals"
- entire document: some rewording
- section 4: changed title of section to "NEMO Design Goals".
- section 4: removed "MUST" and "MAY"
- section 4: more text about location privacy
- section 4: changed "Administration" paragraph to "Local and
Global 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
A. Acknowledgments A. 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
skipping to change at page 11, line 27 skipping to change at page 12, line 11
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 B. References
[IPv6-NODE] John Loughney [IPv6-NODE] John Loughney
"IPv6 Node Requirements" "IPv6 Node Requirements"
draft-ietf-ipv6-node-requirements-01.txt draft-ietf-ipv6-node-requirements.txt
July 2002, Work in progress. Work in progress.
[MIPv6] David B. Johnson and C. Perkins. [MobileIPv4] Charles Perkins
"IP Mobility Support"
RFC 2002, IETF, October 1996.
[MobileIPv6] David B. Johnson and C. Perkins.
"Mobility Support in IPv6" "Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-20.txt, draft-ietf-mobileip-ipv6.txt,
January 2002. Work in progress. Work in progress.
[MOBILITY-TERMS] J. Manner [MOBILITY-TERMS] J. Manner
"Mobility Related Terminology "Mobility Related Terminology
<draft-ietf-seamoby-mobility-terminology-00.txt> <draft-ietf-seamoby-mobility-terminology.txt>
August 2002. Work in progress Work in progress.
[NEMO-TERMS] Thierry Ernst and Hong-Yon Lach [NEMO-TERMS] Thierry Ernst and Hong-Yon Lach
"Terminology for Network Mobility Support", "Terminology for Network Mobility Support",
draft-ernst-nemo-terminology.txt. draft-ietf-nemo-terminology.txt
Work in progress. Work in progress.
[RFC1122] R. Braden (editor). [RFC1122] R. Braden (editor).
"Requirements for Internet Hosts - Communication "Requirements for Internet Hosts - Communication
Layers". IETF RFC 1122, October 1989. Layers". IETF RFC 1122, October 1989.
[RFC2119] S. Bradner [RFC2119] S. Bradner
"Key words for use in RFCs to Indicate Requirement "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, IETF, March 1997. Levels", BCP 14, RFC 2119, IETF, March 1997.
 End of changes. 59 change blocks. 
188 lines changed or deleted 246 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/