draft-ietf-nemo-requirements-06.txt   rfc4886.txt 
NEMO Working Group T. Ernst Network Working Group T. Ernst
Internet-Draft INRIA Request for Comments: 4886 INRIA
Intended status: Informational November 8, 2006
Expires: May 12, 2007
Network Mobility Support Goals and Requirements Network Mobility Support Goals and Requirements
draft-ietf-nemo-requirements-06
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 12, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Network mobility arises when a router connecting a network to the Network mobility arises when a router connecting a network to the
Internet dynamically changes its point of attachment to the Internet Internet dynamically changes its point of attachment to the Internet
thereby causing the reachability of the said network to be changed in thereby causing the reachability of the said network to be changed in
relation to the fixed Internet topology. Such kind of network is relation to the fixed Internet topology. Such a type of network is
referred to as a mobile network. With appropriate mechanisms, referred to as a mobile network. With appropriate mechanisms,
sessions established between nodes in the mobile network and the sessions established between nodes in the mobile network and the
global Internet can be maintained after the mobile router changes its global Internet can be maintained after the mobile router changes its
point of attachment. This document outlines the goals expected from point of attachment. This document outlines the goals expected from
network mobility support and defines the requirements that must be network mobility support and defines the requirements that must be
met by the NEMO Basic Support solution. met by the NEMO Basic Support solution.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. NEMO Working Group Objectives and Methodology ...................3
2. NEMO Working Group Objectives and Methodology . . . . . . . . 5 3. NEMO Support Design Goals .......................................5
3.1. Migration Transparency .....................................5
3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . . 7 3.2. Performance Transparency and Seamless Mobility .............5
3.1. Migration Transparency . . . . . . . . . . . . . . . . . . 7 3.3. Network Mobility Support Transparency ......................5
3.2. Performance Transparency and Seamless Mobility . . . . . . 7 3.4. Operational Transparency ...................................5
3.3. Network Mobility Support Transparency . . . . . . . . . . 7 3.5. Arbitrary Configurations ...................................5
3.4. Operational Transparency . . . . . . . . . . . . . . . . . 7 3.6. Local Mobility and Global Mobility .........................6
3.5. Arbitrary Configurations . . . . . . . . . . . . . . . . . 7 3.7. Scalability ................................................7
3.6. Local Mobility and Global Mobility . . . . . . . . . . . . 8 3.8. Backward Compatibility .....................................7
3.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 9 3.9. Secure Signaling ...........................................7
3.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 9 3.10. Location Privacy ..........................................8
3.9. Secure Signaling . . . . . . . . . . . . . . . . . . . . . 9 3.11. IPv4 and NAT Traversal ....................................8
3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 10 3.12. Minimal Impact on Internet Routing ........................8
3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 10 4. NEMO Basic Support One-Liner Requirements .......................8
5. Security Considerations ........................................10
4. NEMO Basic Support One-Liner Requirements . . . . . . . . . . 11 6. Acknowledgments ................................................11
7. References .....................................................11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References ......................................11
7.2. Informative References ....................................11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
Network mobility support (see [1] for the related terminology) is Network mobility support (see [1] for the related terminology) is
concerned with managing the mobility of an entire network, viewed as concerned with managing the mobility of an entire network, viewed as
a single unit, which changes its point of attachment to the Internet a single unit that changes its point of attachment to the Internet
and thus its reachability in the Internet topology. Such a network and thus its reachability in the Internet topology. Such a network
is referred to as a mobile network and includes one or more mobile is referred to as a mobile network and includes one or more mobile
routers (MRs) which connect it to the global Internet. Nodes behind routers (MRs), which connect it to the global Internet. Nodes behind
the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In
most cases, the internal structure of the mobile network will be most cases, the internal structure of the mobile network will be
relatively stable (no dynamic change of the topology), but this is relatively stable (no dynamic change of the topology), but this is
not always true. not always true.
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 increasingly embedded with a number of processing units for are increasingly equipped 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 ([4]). (Intelligent Transportation Systems) applications ([4]).
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
within network mobility or PANs: network mobility within network mobility within network mobility or PANs; network mobility within
mobility, i.e. nested mobility (see [1] for the definition of network mobility, i.e., nested mobility (see [1] for the
nested mobility). definition of nested mobility).
o Ad-hoc networks connected to the Internet via an MR: for instance o Ad-hoc networks connected to the Internet via an MR: for instance,
students in a train that need both to set up an ad-hoc network students in a train who need to both set up an ad-hoc network
among themselves, and 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 do 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 in MNNs losing Internet access and breaking ongoing sessions results in MNNs losing Internet access and breaking ongoing sessions
between arbitrary correspondent node (CNs) in the global Internet and between arbitrary correspondent nodes (CNs) in the global Internet
those MNNs located within the mobile network. In addition, the and those MNNs located within the mobile network. In addition, the
communication path between MNNs and correspondent nodes becomes sub- communication path between MNNs and correspondent nodes becomes sub-
optimal, and multiple levels of mobility will cause extremely sub- optimal, and multiple levels of mobility will cause extremely sub-
optimal routing. optimal routing.
Mobility-related terms used in this document are defined in [2], Mobility-related terms used in this document are defined in [2],
whereas terms specifically pertaining to network mobility are defined whereas terms specifically pertaining to network mobility are defined
in [1]. This document is structured as follows: in Section 2 we in [1]. This document is structured as follows: in Section 2, we
define the rough objectives and methodology of the NEMO working group define the rough objectives and methodology of the NEMO working group
to handle network mobility issues and we emphasize the stepwise to handle network mobility issues and we emphasize the stepwise
approach the working group has decided to follow. A number of approach the working group has decided to follow. A number of
desirable design goals are listed in Section 3. Those design goals desirable design goals are listed in Section 3. Those design goals
then serve as guidelines to define the requirements listed in then serve as guidelines to define the requirements listed in Section
Section 4 for basic network mobility support [3]. 4 for basic network mobility support [3].
2. NEMO Working Group Objectives and Methodology 2. NEMO Working Group Objectives and Methodology
The mechanisms required for handling network mobility issues were The mechanisms required for handling network mobility issues were
lacking within the IETF standards when the NEMO working group was set lacking within the IETF standards when the NEMO working group (WG)
up at the IETF in 2002. At that time, work conducted on mobility was set up at the IETF in 2002. At that time, work conducted on
support (particularly in the Mobile IP working group) was to provide mobility support (particularly in the Mobile IP working group) was to
continuous Internet connectivity and optimal routing to mobile hosts provide continuous Internet connectivity and optimal routing to
only (host mobility support). Such mechanisms speficied in Mobile mobile hosts only (host mobility support). Such mechanisms specified
IPv6 [5] are unable to support network mobility. The NEMO working in Mobile IPv6 [5] are unable to support network mobility. The NEMO
group has therefore been set up to deal with issues specific to working group has therefore been set up to deal with issues specific
network mobility. 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 that
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 while the mobile router serving
router seving the mobile network changes its point of attachment. the mobile network changes its point of attachment. The secondary
The secondary goals of the work is to investigate the effects of goal of the work is to investigate the effects of network mobility on
network mobility on various aspects of internet communication such as various aspects of Internet communication such as routing protocol
routing protocol changes, implications of real-time traffic and fast changes, implications of real-time traffic and fast handovers, and
handovers, and optimizations. This should support the primary goal optimizations. This should support the primary goal of reachability
of reachability for mobile network nodes. Security is an important for mobile network nodes. Security is an important consideration
consideration too, and efforts should be made to use existing too, and efforts should be made to use existing security solutions if
security solutions if they are appropriate. Although a well-designed they are appropriate. Although a well-designed solution may include
solution may include security inherent in other protocols, mobile security inherent in other protocols, mobile networks also introduce
networks also introduce new challenges. new challenges.
To complete these tasks, the NEMO working group has decided to take a To complete these tasks, the NEMO working group has decided to take a
stepwise approach. The steps in this approach include standardizing stepwise approach. The steps in this approach include standardizing
a basic solution to preserve session continuity (NEMO Basic Support, a basic solution to preserve session continuity (NEMO Basic Support,
see [3]), and studying the possible approaches and issues with see [3]) and studying the possible approaches and issues with
providing more optimal routing with potentially nested mobile providing more optimal routing with potentially nested mobile
networks (NEMO Extended Support, see [6] and [7] for a discussion on networks (NEMO Extended Support, see [6] and [7] for a discussion on
routing optimization issues and [8] multihoming issues). However, routing optimization issues and [8] for a discussion on multihoming
the working group is not chartered to actually standardize a solution issues). However, the working group is not chartered to actually
for extgended support at this point in time. If deemed necessary, standardize a solution for Extended Support at this point in time.
the working group will be rechartered based on the conclusions of the If deemed necessary, the working group will be rechartered based on
discussions. the conclusions of the discussions.
For NEMO Basic Support, the working group assumes that none of the For NEMO Basic Support, the working group assumes that none of the
nodes behind the MR is aware of the network's mobility; thus, the nodes behind the MR is aware of the network's mobility; thus, the
network's movement needs to be completely transparent to the nodes network's movement needs to be completely transparent to the nodes
inside the mobile network. This assumption accommodates nodes inside inside the mobile network. This assumption accommodates nodes inside
the network that are not generally aware of mobility. the network that are not generally aware of 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 has adopted the methods for host mobility support used in support has adopted the methods for host mobility support used in
Mobile IP, and has extended them in the simplest way possible to Mobile IP and has extended them in the simplest way possible to
achieve its goals. The basic support solution, now defined in [3] achieve its goals. The Basic Support solution, now defined in [3]
following the requirements stated in Section 4 of the present following the requirements stated in Section 4 of the present
document, is for each MR to have a Home Agent, and use bi-directional document, is for each MR to have a Home Agent (HA), and use bi-
tunneling between the MR and HA to preserve session continuity while directional tunneling between the MR and HA to preserve session
the MR moves. The MR acquires a Care-of address (CoA) at its continuity while the MR moves. The MR acquires a Care-of Address
attachment point much like what is done for mobile hosts (MH), using (CoA) at its attachment point much like what is done for mobile hosts
Mobile IP. This approach allows nested mobile networks, since each (MHs), using Mobile IP. This approach allows nested mobile networks,
MR will appear to its attachment point as a single node. 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
intend to achieve. Those design goals serve to define the issues and intend to achieve. Those design goals serve to define the issues and
to impose a list of requirements for forthcoming solutions. Actual to impose a list of requirements for forthcoming solutions. Actual
requirements for NEMO Basic Support are in Section 4; NEMO Extended requirements for NEMO Basic Support are in Section 4; NEMO Extended
Support is not yet considered at the time of this writing. Support is not yet considered at the time of this writing.
3.1. Migration Transparency 3.1. Migration Transparency
skipping to change at page 7, line 35 skipping to change at page 5, line 37
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) do not 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 only by the MR(s). Specific support functions on any other performed only by the MR(s). Specific support functions on any node
node than the MR(s) would better be avoided. other than the MR(s) would better be avoided.
3.4. Operational Transparency 3.4. Operational Transparency
NEMO support is to be implemented at the level of IP layer. 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 occur 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
skipping to change at page 8, line 22 skipping to change at page 6, line 25
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 [1] and the analysis in [8]). in [1] and the analysis in [8]).
o Nested mobile networks (mobile networks attaching to other mobile o Nested mobile networks (mobile networks attaching to other mobile
networks (see definition in [1]). Although the complexity networks (see definition in [1]). Although the complexity
requirements of those nested networks is not clear, it is requirements of these nested networks are not clear, it is
desirable to support arbitrary levels of recursive networks. The desirable to support arbitrary levels of recursive networks. The
solution should only impose restrictions on nesting (e.g. path solution should only impose restrictions on nesting (e.g., path
MTU) when this is impractical and protocol concerns preclude such MTU) when this is impractical and protocol concerns preclude such
support. support.
o Distinct mobility frequencies (see mobility factor in [2]). o Distinct mobility frequencies (see mobility factor in [2]).
o Distinct access media. 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
skipping to change at page 9, line 9 skipping to change at page 7, line 9
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 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 established IPv6 standards NEMO support will have to co-exist with established IPv6 standards
and not interfer with them. Standards defined in other IETF working and not interfere with them. Standards defined in other IETF working
groups have to be reused as much as possible and extended only if groups have to be reused as much as possible and extended only if
deemed necessary. For instance, the following mechanisms defined by deemed necessary. For instance, the following mechanisms defined by
other working groups are expected to function without modidication: other working groups are expected to function without modification:
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 continue 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 includes mechanisms for host mobility support (Mobile
IPv6) and seamless mobility (FMIPv6). IPv6) and seamless mobility (FMIPv6).
o Multicast support intended for MNNs is expected to be maintained o Multicast support intended for MNNs is expected to be maintained
while the mobile router changes its point of attachment. while the mobile router changes its point of 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, gaining 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 in both the visited o Mechanisms performed by routers deployed in both visited networks
networks and in mobile networks (routing protocols, Neighbor and mobile networks (routing protocols, Neighbor Discovery, ICMP,
Discovery, ICMP, Router Renumbering). Router Renumbering).
3.9. Secure Signaling 3.9. Secure Signaling
NEMO support will have to comply with the usual IETF security NEMO support will have to comply with the usual IETF security
policies and recommendations and is expected to have its specific policies and recommendations and is expected to have its specific
security issues fully addressed. In practice, all NEMO support security issues fully addressed. In practice, all NEMO support
control messages transmitted in the network will have to be protected control messages transmitted in the network will have to be protected
with an acceptable level of security to prevent intruders to usurp with an acceptable level of security to prevent intruders from
identities and forge data. Specifically, the following issues have usurping identities and forge data. Specifically, the following
to be considered: 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
Location privacy means to hide the actual location of MNNS to third Location privacy means hiding the actual location of MNN to third
parties other than the HA are desired. It is not clear to which parties other than the HA are desired. It is not clear to which
extend this has to be enforced, since it is always possible to extend this has to be enforced, since it is always possible to
determine the topological location by analysing IPv6 headers. It determine the topological location by analyzing IPv6 headers. It
would thus require some kind of encryption of the IPv6 header to would thus require some kind of encryption of the IPv6 header to
prevent third parties from monitoring IPv6 addresses between the MR prevent third parties from monitoring IPv6 addresses between the MR
and the HA. On the other hand, it is at the very least desirable to and the HA. On the other hand, it is at the very least desirable to
provide a means for MNNs to hide their real topological location to provide a means for MNNs to hide their real topological location to
their CNs. 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 developed for NEMO will be so it is desirable to ensure that mechanisms developed for NEMO will
able to traverse such clouds. be able to traverse such clouds.
3.12. Minimal Impact on Internet Routing
Any NEMO solution needs have minimal negative effect on the global
Internet routing system. The solution must therefore limit both the
amount of information that must be injected into Internet routing, as
well as the dynamic changes in the information that is injected into
the global routing system.
As one example of why this is necessary, consider the approach of
advertising each mobile network's connectivity into BGP and, for
every movement, withdrawing old routes and injecting new routes. If
there were tens of thousands of mobile networks each advertising and
withdrawing routes, for example, at the speed that an airplane can
move from one ground station to another, the potential effect on BGP
could be very unfortunate. In this example, the total amount of
routing information advertised into BGP may be acceptable, but the
dynamic instability of the information (i.e., the number of changes
over time) would be unacceptable.
4. NEMO Basic Support One-Liner Requirements 4. NEMO Basic Support One-Liner Requirements
For basic network mobility support, the NEMO WG is to specify a For basic network mobility support, the NEMO WG is to specify a
unified and unique "Network Mobility (NEMO) Basic Support" solution, unified and unique "Network Mobility (NEMO) Basic Support" solution,
hereafter referred to as "the solution". This solution is to allow hereafter referred to as "the solution". This solution is to allow
all nodes in the mobile network to be reachable via permanent IP all nodes in the mobile network to be reachable via permanent IP
addresses, as well as maintain ongoing sessions as the MR changes its 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 point of attachment to the Internet topology. This is to be done by
maintaining a bi-directional tunnel between an MR and its Home Agent. maintaining a bi-directional tunnel between an MR and its Home Agent.
The NEMO Working Group, after some investigation of alternatives, has The NEMO Working Group, after some investigation of alternatives, has
decided to reuse and extend the existing Mobile IPv6 [5] mechanisms decided to reuse and extend the existing Mobile IPv6 [5] mechanisms
for tunnel management. for tunnel management.
The list of requirements below has been imposed on the NEMO Basic The list of requirements below has been imposed on the NEMO Basic
Support solution. The requirements have mostly been met by the Support solution. The requirements have mostly been met by the
resulting specification which can now be found in [3]. Associated resulting specification, which can now be found in [3]. Associated
deployment issues are discussed in [9] deployment issues are discussed in [9].
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 an 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 bi-directional 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
and multicast) between MNNs and arbitrary CNs after IP handover of multicast) between MNNs and arbitrary CNs after IP handover of
(one of) the MR. (one of) the MRs.
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
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 ensure backward compatibility with other R09: The solution must ensure backward compatibility with other
standards defined by the IETF. In particular, this includes: standards defined by the IETF. In particular, this includes the
following:
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 to Mobile IPv6 (i.e., the solution must allow MIPv6-enabled
operate either the CN, HA, or MN operations defined in [5]) MNNs to operate either the CN, HA, or MN operations
R10: The solution MUST treat all the potential configurations the defined in [5]).
same way (whatever the number of subnets, MNNs, nested levels of
MRs, egress interfaces)
R11: The solution MUST support at least 2 levels of nested mobile R10: The solution must be agnostic to the internal configuration.
This means the solution will behave the same way if NEMO is
nested, comprises one or several subnets, or comprises MNNs that
are LFNs, VMNs, LFNs or a mixture of them.
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 MRs and multihomed R12: The solution must function for multihomed MRs and multihomed
mobile networks as defined in [1]. mobile networks as defined in [1].
R13: NEMO Support signaling over the bi-directional 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
and management operations over the bi-directional tunnel (this 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) renumbering, Dynamic Host Configuration Protocol (DHCPv6)).
R16: When one egress interface fails, the solution MAY preserve R16: When one egress interface fails, the solution may preserve
sessions established through another egress interface. sessions established through another egress interface.
5. Security Considerations R17: The solution should have a minimal impact on the global Internet
routing system.
As this document only provides a discussion about design goals and 5. Security Considerations
describes neither a protocol nor an implementation or a procedure,
there are no security considerations associated with it.
6. IANA Considerations Security considerations of the NEMO Basic Support solution are
addressed in [RFC3963].
This document requires no IANA actions. Section 3.9 of this document discusses the security goals for all
forms of existing and forthcoming NEMO solutions.
7. 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 at the time (Erik Nordmark and Thomas (Ericsson) and the IETF Area Directors (ADs) at the time (Erik
Narten) who greatly helped to set up the NEMO working group. We are Nordmark and Thomas Narten), who greatly helped to set up the NEMO
also grateful to all the following people whose comments highly working group. We are also grateful to all the following people
contributed to the present document: T.J. Kniveton (Nokia), Alexandru whose comments greatly contributed to the present document: T.J.
Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau
(Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and (Motorola), Pascal Thubert (Cisco), Hong-Yon Lach (Motorola), Mattias
all the others people who have expressed their opinions on the NEMO Petterson (Ericsson), and all the others who have expressed their
mailing lists (formely known as MONET). Thierry Ernst wishes to opinions on the NEMO mailing lists (formerly known as MONET).
personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for Thierry Ernst wishes to personally acknowledge INRIA Rhone-Alpes and
their support and direction in bringing this topic up to the IETF Motorola Labs Paris for their support and direction in bringing up
back in year 2001 -- particularly Claude Castelluccia (INRIA) and this topic to the IETF in 2001--particularly Claude Castelluccia
Hong-Yon Lach (Motorola) -- and his past employer, Keio University, (INRIA) and Hong-Yon Lach (Motorola)--and his past employer, Keio
Japan which supported most of the costs associated with the IETF University, Japan, which supported most of the costs associated with
during the timelife of previous versions of this document. the IETF during the timelife of previous versions of this document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress), RFC 4885, July 2007.
November 2006.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
RFC 3753, June 2004. 3753, June 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
8.2. Informative References 7.2. Informative References
[4] "CALM - Medium and Long Range, High Speed, Air Interfaces [4] "CALM - Medium and Long Range, High Speed, Air Interfaces
parameters and protocols for broadcast, point to point, vehicle parameters and protocols for broadcast, point to point, vehicle
to vehicle, and vehicle to point communication in the ITS sector to vehicle, and vehicle to point communication in the ITS sector
- Networking Protocol - Complementary Element", ISO Draft ISO/WD - Networking Protocol - Complementary Element", ISO Draft ISO/WD
21210, February 2005. 21210, February 2005.
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Ng, C., Pascal, P., Masafumi, M., and F. Fan, "Network Mobility [6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
Route Optimization Problem Statement", Route Optimization Problem Statement", RFC 4888, July 2007.
draft-ietf-nemo-ro-problem-statement-03 (work in progress),
September 2006.
[7] Ng, C., Fan, F., Masafumi, M., and P. Pascal, "Network Mobility [7] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
Route Optimization Solution Space Analysis", Route Optimization Solution Space Analysis", RFC 4889, July
draft-ietf-nemo-ro-space-analysis-03 (work in progress), 2007.
September 2006.
[8] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 Multihoming in Network Mobility Support", Work in Progress),
(work in progress), June 2006. February 2007.
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility
Network Models", draft-ietf-nemo-home-network-models-06 (work in (NEMO) Home Network Models", RFC 4887, July 2007.
progress), February 2006.
Author's Address Author's Address
Thierry Ernst Thierry Ernst
INRIA INRIA
INRIA Rocquencourt INRIA Rocquencourt
Domaine de Voluceau B.P. 105 Domaine de Voluceau B.P. 105
Le Chesnay, 78153 78 153 Le Chesnay Cedex
France France
Phone: +33 1 39 63 59 30 Phone: +33 1 39 63 59 30
Fax: +33 1 39 63 54 91 Fax: +33 1 39 63 54 91
Email: thierry.ernst@inria.fr EMail: thierry.ernst@inria.fr
URI: http://www-rocq.inria.fr/imara URI: http://www-rocq.inria.fr/imara
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
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
skipping to change at page 18, line 45 skipping to change at page 13, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 81 change blocks. 
221 lines changed or deleted 207 lines changed or added

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