draft-ietf-nemo-requirements-03.txt   draft-ietf-nemo-requirements-04.txt 
NEMO Working Group T. Ernst NEMO Working Group T. Ernst
Internet-Draft WIDE at Keio University Internet-Draft WIDE at Keio University
Expires: April 25, 2005 October 25, 2004 Expires: August 25, 2005 February 21, 2005
Network Mobility Support Goals and Requirements Network Mobility Support Goals and Requirements
draft-ietf-nemo-requirements-03 draft-ietf-nemo-requirements-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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. This Internet-Draft will expire on August 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
Network mobility arises when a router connecting an entire network to Network mobility arises when a router connecting a network to the
the Internet dynamically changes its point of attachment to the Internet dynamically changes its point of attachment to the Internet
Internet therefrom causing the reachability of the entire network to thereby causing the reachability of the said network to be changed in
be changed in the topology. Such kind of network is referred to as a relation to the fixed Internet topology. Such kind of network is
mobile network. Without appropriate mechanisms, sessions established referred to as a mobile network. With appropriate mechanisms,
between nodes in the mobile network and the global Internet cannot be sessions established between nodes in the mobile network and the
maintained while the mobile router changes its point of attachment. global Internet can be maintained after the mobile router changes its
The required support mechanisms will be provided in two phases. The point of attachment. This document outlines the goals expected from
first phase, referred to as NEMO Basic Support is to provide session network mobility support and defines the requirements that must be
continuity while the necessary optimizations mechanims referred to as met by the NEMO Basic Support solution.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Working Group Objectives and Methodology . . . . . . . 4 2. NEMO Working Group Objectives and Methodology . . . . . . . 4
3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 5 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 5
3.1 Migration Transparency . . . . . . . . . . . . . . . . . . 5 3.1 Migration Transparency . . . . . . . . . . . . . . . . . . 5
3.2 Performance Transparency and Seamless Mobility . . . . . . 5 3.2 Performance Transparency and Seamless Mobility . . . . . . 5
skipping to change at page 2, line 31 skipping to change at page 2, line 29
3.5 Arbitrary Configurations . . . . . . . . . . . . . . . . . 6 3.5 Arbitrary Configurations . . . . . . . . . . . . . . . . . 6
3.6 Local Mobility and Global Mobility . . . . . . . . . . . . 7 3.6 Local Mobility and Global Mobility . . . . . . . . . . . . 7
3.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 3.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
3.8 Backward Compatibility . . . . . . . . . . . . . . . . . . 7 3.8 Backward Compatibility . . . . . . . . . . . . . . . . . . 7
3.9 Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8 3.9 Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8
3.10 Location Privacy . . . . . . . . . . . . . . . . . . . . 8 3.10 Location Privacy . . . . . . . . . . . . . . . . . . . . 8
3.11 IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . 8 3.11 IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . 8
4. NEMO Basic Support One-Liner Requirements . . . . . . . . . 8 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . 8
5. Changes Between Versions . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 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
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 A. Change Log From Earlier Versions . . . . . . . . . . . . . . 12
A.1 Changes between version -03 and -04 . . . . . . . . . . . 12
A.2 Changes between version -02 and -03 . . . . . . . . . . . 12
A.3 Changes Between Version -01 and -02 . . . . . . . . . . . 12
A.4 Changes Between Version -00 and -01 . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14
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 a network is referred to as a mobile network
network and includes one or more mobile routers (MRs) which connect and includes one or more mobile routers (MRs) which connect it to the
it to the global Internet. Nodes behind the MR(s) (MNNs) are both global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs)
fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal and mobile (VMNs or LMNs). In most cases, the internal structure of
structure of the mobile network will in effect be relatively stable the mobile network will be relatively stable (no dynamic change of
(no dynamic change of the topology), but this is not a general the topology), but this is not always true.
assumption.
Cases of mobile networks include for instance: Cases of mobile networks include, for instance:
o 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.
o 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 increasingly 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 ([9], [8]).
o access networks deployed in public transportation (buses, trains, o Access networks deployed in public transportation (buses, trains,
taxis, aircrafts): they provide Internet access to IP devices taxis, aircrafts): they provide Internet access to IP devices
carried by passengers (laptop, camera, mobile phone: host mobility carried by passengers: laptop, camera, mobile phone: host mobility
within network mobility or PANs: network mobility within network within network mobility or PANs: network mobility within network
mobility, i.e. nested mobility). mobility, i.e. nested mobility (see [4] for the definition of
nested mobility).
o ad-hoc networks connected to the Internet via a MR: for instance o Ad-hoc networks connected to the Internet via an MR: for instance
students in a train that both need to set up an ad-hoc network students in a train that need both to set up an ad-hoc network
among themselves and to get Internet connectivity through the MR among themselves, and 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 do 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 in MNNs losing Internet access and breaking ongoing sessions
sessions entertained between arbitrary correspondent node (CNs) in between arbitrary correspondent node (CNs) in the global Internet and
the global Internet and those MNNs located within the mobile network. those MNNs located within the mobile network. In addition, the
In addition, the communication path between MNNs and arbitrary communication path between MNNs and correspondent nodes becomes
correspondent nodes (CN) becomes sub-optimal, whereas multiple levels sub-optimal, and multiple levels of mobility will cause extremely
of mobility will cause extremely sub-optimal routing. sub-optimal routing.
The mechanisms required for handling such mobility issues are
currently lacking within the IETF standards. Traditional work
conducted on mobility support (particularly in the Mobile IP working
group) is to provide continuous Internet connectivity and optimal
routing to mobile hosts only (host mobility support) and are unable
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.
Mobility-related terms used in this document are defined in [3] Mobility-related terms used in this document are defined in [3],
whereas terms pertaining to network mobility specifically are defined whereas terms specifically pertaining to network mobility are defined
in [4]. This document is structured as follows: Section 2 defines in [4]. This document is structured as follows: in Section 2 we
the rough objectives and methodology of the NEMO working group and we define the rough objectives and methodology of the NEMO working group
emphasize the stepwise approach the working group has decided to to handle network mobility issues and we emphasize the stepwise
follow. A number of desirable design goals are listed in Section 3. approach the working group has decided to follow. A number of
Those design goals serve as guidelines to edict the requirements desirable design goals are listed in Section 3. Those design goals
listed in Section 4 for basic network mobility support [2]. then serve as guidelines to define the requirements listed in
Section 4 for basic network mobility support [2].
2. NEMO Working Group Objectives and Methodology 2. NEMO Working Group Objectives and Methodology
The mechanisms required for handling network mobility issues were
lacking within the IETF standards when the NEMO working group was set
up at the IETF. At that time, work conducted on mobility support
(particularly in the Mobile IP working group) was to provide
continuous Internet connectivity and optimal routing to mobile hosts
only (host mobility support). Such mechanisms speficied in Mobile
IPv6 [1] are unable to support network mobility. The NEMO working
group has therefore been set up to deal with issues specific to
network mobility.
The primary objective 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. router seving the mobile network changes its point of attachment.
Secondary goals of the work is to investigate the effects of network The secondary goals of the work is to investigate the effects of
mobility on various aspects of internet communication such as routing network mobility on various aspects of internet communication such as
protocol changes, implications of realtime traffic and fast routing protocol changes, implications of real-time traffic and fast
handovers, optimizations. These should all support the primary goal handovers, and optimizations. This should 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 security solutions if they are appropriate. Although a well-designed
may include security inherent in other protocols, mobile networks solution may include security inherent in other protocols, mobile
also introduce new challenges. networks also introduce new challenges.
For doing so, the NEMO working group has decided to take a stepwise To complete these tasks, the NEMO working group has decided to take a
approach by standardizing a basic solution to preserve session stepwise approach. The steps in this approach include standardizing
continuity (NEMO Basic Support), and at the same time study the a basic solution to preserve session continuity (NEMO Basic Support),
possible approaches and issues with providing more optimal routing and studying the possible approaches and issues with providing more
with potentially nested mobile networks (NEMO Extended Support). optimal routing with potentially nested mobile networks (NEMO
However, the working group is not chartered to actually standardize a Extended Support). However, the working group is not chartered to
solution to such route optimization at this point in time. actually standardize a solution for extgended support at this point
in time. If deemed necessary, the working group will be rechartered
based on the conclusions of the discussions.
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;
the network's movement needs to be completely transparent to the thus, the network's movement needs to be completely transparent to
nodes inside the mobile network. This assumption will be made to the nodes inside the mobile network. This assumption accommodates
accommodate nodes inside the network that are not generally aware of 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, now defined in [2] following
Agent, and use bidirectional tunneling between the MR and HA to the requirements stated in Section 4 of the present document, is for
preserve session continuity while the MR moves. The MR will acquire each MR to have a Home Agent, and use bi-directional tunneling
a Care-of-address from its attachment point much like what is done between the MR and HA to preserve session continuity while the MR
for mobile nodes (MN) using Mobile IP. This approach allows nested moves. The MR will acquire a care-of address at its attachment point
mobile networks, since each MR will appear to its attachment point as much like what is done for mobile nodes (MN), using Mobile IP. This
a single node. approach allows nested mobile networks, since each MR will appear to
its attachment point as a single node.
3. NEMO Support 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 intend to achieve. Those design goals serve to define the issues and
understand the requirements defined for forthcoming solutions. to impose a list of requirements for forthcoming solutions. Actual
Actual requirements for NEMO Basic Support are in the next section, requirements for NEMO Basic Support are in Section 4; NEMO Extended
whereas NEMO Extended Support has not yet been considered. Support is not yet considered at the time of this writing.
3.1 Migration Transparency 3.1 Migration Transparency
A permanent connectivity to the Internet has to be provided to all Permanent connectivity to the Internet has to be provided to all
MNNs while continuous sessions are expected to be maintained as the MNNs, since continuous sessions are expected to be maintained as the
mobile router changes its point of attachment. For doing so, MNNs mobile router changes its point of attachment. For maintaining those
are expected to be reachable via their permanent IP addresses. sessions, MNNs are expected to be reachable via their permanent IP
addresses.
3.2 Performance Transparency and Seamless Mobility 3.2 Performance Transparency and Seamless Mobility
NEMO support is expected to be provided with limited signaling NEMO support is expected to be provided with limited signaling
overhead and to minimize the impact of handover over applications, in overhead and to minimize the impact of handovers on applications, in
terms of packet loss or delay. However, although variable delays of terms of packet loss or delay. However, although variable delays of
transmission and losses between MNNs and their respective CNs could transmission and losses between MNNs and their respective CNs could
be perceived as the network is displaced, it would not be considered be perceived as the network is displaced, it would not be considered
a lack of performance transparency. a lack of performance transparency.
3.3 Network Mobility Support Transparency 3.3 Network Mobility Support Transparency
MNNs behind the MR(s) don't change their own physical point of MNNs behind the MR(s) do not change their own physical point of
attachment as a result of the mobile network's displacement in the attachment as a result of the mobile network's displacement in the
Internet topology. Consequently, NEMO support is expected to be Internet topology. Consequently, NEMO support is expected to be
performed by the sole MR(s) and specific support functions on any performed only be the MR(s). Specific support functions on any other
other node than the MR(s) would better be avoided. node than the MR(s) would better be avoided.
3.4 Operational Transparency 3.4 Operational Transparency
NEMO support is to be implemented at the IP layer level. It is NEMO support is to be implemented at the level of IP layer. It is
expected to be transparent to upper layers so that any upper layer 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 protocol can run unchanged on top of an IP layer extended with NEMO
support. support.
3.5 Arbitrary Configurations 3.5 Arbitrary Configurations
The formation of a mobile network can exist in various levels of The formation of a mobile network can occur in various levels of
complexity. In the simplest case, a mobile network contains just a complexity. In the simplest case, a mobile network contains just a
mobile router and a host. In the most complicated case, a mobile mobile router and a host. In the most complicated case, a mobile
network is multihomed and is itself a multi-level aggregation of network is multihomed and is itself a multi-level aggregation of
mobile networks with collectively thousands of mobile routers and mobile networks with collectively thousands of mobile routers and
hosts. While the list of potential configurations of mobile networks hosts. While the list of potential configurations of mobile networks
cannot be limited, at least the following configurations are cannot be limited, at least the following ones are desirable:
desirable:
o mobile networks of any size, ranging from a sole subnet with a few 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 IP devices to a collection of subnets with a large number of IP
devices, devices.
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 foreign mobile nodes that attach to the mobile network, o Foreign mobile nodes that attach to the mobile network.
o multihomed mobile network either when a single MR has multiple o Multihomed mobile network: either when a single MR has multiple
attachments to the internet, or when the mobile network is attachments to the internet, or when the mobile network is
attached to the Internet by means of multiple MRs (see definition attached to the Internet by means of multiple MRs (see definition
in [4] and the analys in [5]), in [4] and the analysis in [5]).
o nested mobile networks (mobile networks attaching to other mobile o Nested mobile networks (mobile networks attaching to other mobile
networks (see definition in [4]). Although the complexity networks (see definition in [4]). Although the complexity
requirements of those nested networks is not clear, it is requirements of those nested networks is not clear, it is
desirable to support arbitrary levels of recursive networks, and desirable to support arbitrary levels of recursive networks. The
only in the case where this is impractical and protocol concerns solution should only impose restrictions on nesting (e.g. path
preclude this support should the solution impose restrictions on MTU) when this is impractical and protocol concerns preclude such
nesting (e.g. path MTU), support.
o distinct mobility frequencies (see mobility factor in [3]) o Distinct mobility frequencies (see mobility factor in [3]).
o distinct access medium. o Distinct access media.
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 the forwarded between two endpoints outside of the network, so that the
network itself simply serves as a transitional conduit for packet network itself simply serves as a transitional conduit for packet
forwarding. A stub network (leaf network), on the other hand, does forwarding. A stub network (leaf network), on the other hand, does
not serve as a data forwarding path. Data on a stub network is 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. either sent by or addressed to a node located within that network.
3.6 Local Mobility and Global Mobility 3.6 Local Mobility and Global Mobility
Mobile networks and mobile nodes owned by administratively different Mobile networks and mobile nodes owned by different administrative
entities are expected to be displaced within a domain boundary or entities are expected to be displaced within a domain boundary or
between domain boundaries. Multihoming, vertical and horizontal between domain boundaries. Multihoming, vertical and horizontal
handoffs, and access control mechanisms are desirable to achieve this handoffs, and access control mechanisms are desirable to achieve this
goal. Such mobility type is not expected to be limited for any goal. Such mobility is not expected to be limited for any
consideration other than administrative and security policies. consideration other than administrative and security policies.
3.7 Scalability 3.7 Scalability
NEMO support signaling and processing is expected to scale to a NEMO support signaling and processing is expected to scale to a
potentially large number of mobile networks irrespective of their potentially large number of mobile networks irrespective of their
configuration, mobility frequency, size and number of CNs. configuration, mobility frequency, size and number of CNs.
3.8 Backward Compatibility 3.8 Backward Compatibility
NEMO support will have to co-exist with existing IPv6 standards NEMO support will have to co-exist with established IPv6 standards
without interfering with them. Standards defined in other IETF and not interfer with them. Standards defined in other IETF working
working groups have to be reused as much as possible and extended groups have to be reused as much as possible and extended only if
only if deemed necessary. For instance, the following mechanisms deemed necessary. For instance, the following mechanisms defined by
defined by other working groups are expected to function without other working groups are expected to function without modidication:
modidications:
o Address allocation and configuration mechanisms o Address allocation and configuration mechanisms.
o Host mobility support: mobile nodes and correspondent nodes, o Host mobility support: mobile nodes and correspondent nodes,
either located within or outside the mobile network are expected either located within or outside the mobile network, are expected
to keep operating protocols defined by the Mobile IP working to continue operating protocols defined by the Mobile IP working
group. This include mechanisms for host mobility support (Mobile group. This include mechanisms for host mobility support (Mobile
IPv6) and seamless mobility (FMIPv6). IPv6) and seamless mobility (FMIPv6).
o Multicast support entertained by MNNs are expected to be o Multicast support intended for MNNs is expected to be maintained
maintained while the mobile router changes its point of while the mobile router changes its point of attachment.
attachment.
o Access control protocols and mechanisms used by visiting mobile o Access control protocols and mechanisms used by visiting mobile
hosts and routers to be authenticated and authorized to gain hosts and routers to be authenticated and authorized, gaining
access to the Internet via the mobile network infrastructure access to the Internet via the mobile network infrastructure
(MRs). (MRs).
o Security protocols and mechanisms o Security protocols and mechanisms.
o Mechanisms performed by routers deployed both in the visited o Mechanisms performed by routers deployed in both the visited
networks and in mobile networks (routing protocols, Neighbor networks and in mobile networks (routing protocols, Neighbor
Discovery, ICMP, Router Renumbering, ...). Discovery, ICMP, Router Renumbering).
3.9 Secure Signaling 3.9 Secure Signaling
NEMO support will have to comply with usual IETF security policies NEMO support will have to comply with the usual IETF security
and recommendations and is expected to have its specific security policies and recommendations and is expected to have its specific
issues fully addressed. In practice, all NEMO support control security issues fully addressed. In practice, all NEMO support
messages transmitted in the network will have to ensure an acceptable control messages transmitted in the network will have to be protected
level of security to prevent intruders to usurp identities and forge with an acceptable level of security to prevent intruders to usurp
data. Specifically, the following issues have to be considered: 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 to o Authorization, to make sure the sender is granted permission to
perform the operation as indicated in the control message. 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.
3.10 Location Privacy 3.10 Location Privacy
Means to hide the actual location of MNNS to third parties other than Location privacy means to hide the actual location of MNNS to third
the HA are desired. In which extend this has to be enforced is not parties other than the HA are desired. It is not clear to which
clear since it is always possible to determine the topological extend this has to be enforced, since it is always possible to
location by analysing IPv6 headers. It would thus require some kind determine the topological location by analysing IPv6 headers. It
of encryption of the IPv6 header to prevent third parties to monitor would thus require some kind of encryption of the IPv6 header to
IPv6 addresses between the MR and the HA. On the other hand, it is prevent third parties from monitoring IPv6 addresses between the MR
at the very least desirable to provide means for MNNs to hide their and the HA. On the other hand, it is at the very least desirable to
real topological location to their CNs. provide a means for MNNs to hide their real topological location to
their CNs.
3.11 IPv4 and NAT Traversal 3.11 IPv4 and NAT Traversal
IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, 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 so it is desirable to ensure mechanisms developed for NEMO will be
able to traverse such clouds. able to traverse such clouds.
4. NEMO Basic Support One-Liner Requirements 4. NEMO Basic Support One-Liner Requirements
The NEMO WG is to specify a unified and unique "Network Mobility The NEMO WG is to specify a unified and unique "Network Mobility
Basic Support" solution, hereafter referred to as "the solution". Basic Support" solution, hereafter referred to as "the solution".
This solution is to allow all nodes in the mobile network to be This solution is to allow all nodes in the mobile network to be
reachable via permanent IP addresses, as well as maintain ongoing reachable via permanent IP addresses, as well as maintain ongoing
sessions as the MR changes its point of attachment to the Internet sessions as the MR changes its point of attachment to the Internet
topology. This is to be done by maintaining a bidirectional tunnel topology. This is to be done by maintaining a bi-directional tunnel
between a MR and its Home Agent. between an MR and its Home Agent.
For doing so, the NEMO Working Group has decided to investigate The NEMO Working Group, after some investigation of alternatives, has
reusing the existing Mobile IPv6 [1] mechanisms for the tunnel decided to reuse the existing Mobile IPv6 [1] mechanisms for tunnel
management, or extend it if deemed necessary. management, or extend it if deemed necessary.
The list of requirements below have been placed on the NEMO Basic The list of requirements below has been imposed on the NEMO Basic
Support solution. They have been mostly met by the resulting Support solution. The requirements have mostly been met by the
specification which can now be found in [2]. resulting specification which can now be found in [2].
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 a R02: The solution MUST set up a bi-directional tunnel between a
Mobile Router and its Home Agent (MRHA tunnel) Mobile Router and its Home Agent (MRHA tunnel)
R03: All traffic exchanged between a MNN and a CN in the global R03: All traffic exchanged between an MNN and a CN in the global
Internet MUST transit through the bidirectional MRHA tunnel. Internet MUST transit through the bi-directional MRHA 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 handover of and multicast) between MNNs and arbitrary CNs after IP handover of
(one of) the MR. (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 R07: The solution MUST support fixed nodes, mobile hosts and
mobile routers in the mobile network. mobile 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 ensure backward compatibility with other R09: The solution MUST ensure backward compatibility with other
standards defined by the IETF. This include particularly: standards defined by the IETF. In particular, this includes:
R09:1: The solution MUST not prevent the proper operation of R09:1: The solution MUST not prevent the proper operation of
Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs
to operate either the CN, HA, or MN operations defined in [1]) to operate either the CN, HA, or MN operations defined in [1])
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 of same way (whatever the number of subnets, MNNs, nested levels of
MRs, egress interfaces, ...) MRs, egress interfaces)
R11: The solution MUST support at least 2 levels of nested mobile R11: The solution MUST support at least 2 levels of nested mobile
networks, while, in principle, arbitrary levels of recursive networks, while, in principle, arbitrary levels of recursive
mobile networks SHOULD be supported. mobile networks SHOULD be supported.
R12: The solution MUST function for multihomed MR and multihomed R12: The solution MUST function for multihomed MRs and multihomed
mobile networks as defined in [4]. mobile networks as defined in [4].
R13: NEMO Support signaling over the bidirectional MUST be R13: NEMO Support signaling over the bi-directional MUST be
minimized minimized
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 MAY be encrypted R14.4: The signaling messages MAY be encrypted.
R15: The solution MUST ensure transparent continuation of routing R15: The solution MUST ensure transparent continuation of routing
and management operations over the bi-directional tunnel (this and management operations over the bi-directional tunnel (this
includes e.g. unicast and multicast routing protocols, router includes e.g. unicast and multicast routing protocols, router
renumbering, DHCPv6, etc) renumbering, DHCPv6)
R16: The solution MUST not impact on the routing fabric neither on R16: When one egress interface fails, the solution MAY preserve
the Internet addressing architecture. [ACCORDING TO IETF56 sessions established through another egress interface.
minutes, SHOULD BE REMOVED]
R18: The solution MAY preserve sessions established through 5. Acknowledgments
another egress interface when one fails
5. Changes Between Versions 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 at the time (Erik Nordmark and Thomas
Narten) who greatly 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: T.J. 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 mailing lists (formely known as MONET). Thierry
Ernst wishes to personally acknowledge his 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).
5.1 Changes between version -02 and -03 6. References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Internet-Draft draft-ietf-nemo-terminology-03, February 2005.
[5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in
Network Mobility Support",
Internet-Draft draft-ietf-nemo-multihoming-issues-02, February
2005.
[6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network
Models", Internet-Draft draft-ietf-nemo-home-network-models-01,
October 2004.
[7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
IETF RFC 2460, December 1998.
[8] Ernst, T. and K. Uehara, "Connecting Automobiles to the
Internet", Proceedings 3rd International Workshop on ITS
Telecommunications (ITST), November 2002.
[9] "CALM - Medium and Long Range, High Speed, Air Interfaces
parameters and protocols for broadcast, point to point, vehicle
to vehicle, and vehicle to point communication in the ITS sector
- Networking Protocol - Complementary Element", ISO Drat ISO/WD
21210, February 2005.
Author's Address
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
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Appendix A. Change Log From Earlier Versions
The discussions behind the changes in the lattest versions of this
documents are reflected in the "issue" web page:
http://www.sfc.wide.ad.jp/~ernst/nemo/
A.1 Changes between version -03 and -04
- Issue B1: English brush up
- Issue B2: Added a reference to [9] and [8] when speaking about
usages.
- Issue B3: The following paragraph from section 1 was partly
removed; the remaining part was moved to section 2 and rephrased:
"The mechanisms required for handling such mobility issues are
currently lacking within the IETF standards. Traditional work
conducted on mobility support (particularly in the Mobile IP working
group) is to provide continuous Internet connectivity and optimal
routing to mobile hosts only (host mobility support) and are unable
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."
- Issue B4: Effectively removed former requirements about "impact on
the routing fabric".
A.2 Changes between version -02 and -03
- Mostly cosmetic changes - Mostly cosmetic changes
- Merged section Terminology into Introduction - Merged section Terminology into Introduction
- Cross-references with other NEMO WG docs - Cross-references with other NEMO WG docs
- Changed the introducion of section Section 4 and added reference to - Changed the introducion of section Section 4 and added reference to
NEMO Basic Support's resulting specification. NEMO Basic Support's resulting specification.
5.2 Changes Between Version -01 and -02 A.3 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)
5.3 Changes Between Version -00 and -01 A.4 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 Global - section 4: changed "Administration" paragraph to "Local and Global
Mobility". Text enhanced. Mobility". Text enhanced.
- section 5: R02: replace "between MR and MR's HA" with "a MR and its - section 5: R02: replace "between MR and MR's HA" with "an MR and
HA" R11: specified at least 2 levels R12: replaced "support" with its HA" R11: specified at least 2 levels R12: replaced "support" with
"function" and add "multihomed MR" R13.x renumbered to R12.x since "function" and add "multihomed MR" R13.x renumbered to R12.x since
part of R12 (editing mistake) R13 and R18: new requirements proposed part of R12 (editing mistake) R13 and R18: new requirements proposed
by editor and minor changes in the formulation of other Requirements by editor and minor changes in the formulation of other Requirements
6. 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).
7 References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-02 (work in progress), October 2004.
[5] Ng, C-W., Paik, E-K. and T. Ernst, "Analysis of Multihoming in
Network Mobility Support", draft-ietf-nemo-multihoming-issues-01
(work in progress), October 2004.
[6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network
Models", draft-ietf-nemo-home-network-models-01 (work in
progress), October 2004.
[7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",
IETF RFC 2460, December 1998.
Author's Address
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
Phone: +81-44-580-1600
Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 41 skipping to change at page 14, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/