< draft-ietf-nemo-requirements-05.txt   draft-ietf-nemo-requirements-06.txt >
NEMO Working Group T. Ernst NEMO Working Group T. Ernst
Internet-Draft Keio University / WIDE Internet-Draft INRIA
Expires: April 27, 2006 October 24, 2005 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-05 draft-ietf-nemo-requirements-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 27, 2006. This Internet-Draft will expire on May 12, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 kind 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Working Group Objectives and Methodology . . . . . . . . 4 2. NEMO Working Group Objectives and Methodology . . . . . . . . 5
3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . . 5
3.1. Migration Transparency . . . . . . . . . . . . . . . . . . 5
3.2. Performance Transparency and Seamless Mobility . . . . . . 5
3.3. Network Mobility Support Transparency . . . . . . . . . . 6
3.4. Operational Transparency . . . . . . . . . . . . . . . . . 6
3.5. Arbitrary Configurations . . . . . . . . . . . . . . . . . 6
3.6. Local Mobility and Global Mobility . . . . . . . . . . . . 7
3.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 7
3.9. Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8
3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 8
3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 8
4. NEMO Basic Support One-Liner Requirements . . . . . . . . . . 8 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . . 7
3.1. Migration Transparency . . . . . . . . . . . . . . . . . . 7
3.2. Performance Transparency and Seamless Mobility . . . . . . 7
3.3. Network Mobility Support Transparency . . . . . . . . . . 7
3.4. Operational Transparency . . . . . . . . . . . . . . . . . 7
3.5. Arbitrary Configurations . . . . . . . . . . . . . . . . . 7
3.6. Local Mobility and Global Mobility . . . . . . . . . . . . 8
3.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 9
3.9. Secure Signaling . . . . . . . . . . . . . . . . . . . . . 9
3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 10
3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log From Earlier Versions . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.1. Changes between version -04 and -05 . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
A.2. Changes between version -03 and -04 . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
A.3. Changes between version -02 and -03 . . . . . . . . . . . 13
A.4. Changes Between Version -01 and -02 . . . . . . . . . . . 14
A.5. Changes Between Version -00 and -01 . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 16 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, which 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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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 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 ([4], [5]). (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 mobility
within network mobility or PANs: network mobility within network within network mobility or PANs: network mobility within network
mobility, i.e. nested mobility (see [1] for the definition of mobility, i.e. nested mobility (see [1] for the definition of
nested mobility). 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 that need both to set up an ad-hoc network
skipping to change at page 4, line 20 skipping to change at page 5, line 9
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 4 for basic network mobility support [3]. Section 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 was set
up at the IETF. At that time, work conducted on mobility support up at the IETF in 2002. At that time, work conducted on mobility
(particularly in the Mobile IP working group) was to provide support (particularly in the Mobile IP working group) was to provide
continuous Internet connectivity and optimal routing to mobile hosts continuous Internet connectivity and optimal routing to mobile hosts
only (host mobility support). Such mechanisms speficied in Mobile only (host mobility support). Such mechanisms speficied in Mobile
IPv6 [6] are unable to support network mobility. The NEMO working IPv6 [5] are unable to support network mobility. The NEMO working
group has therefore been set up to deal with issues specific to group has therefore been set up to deal with issues specific to
network mobility. 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
router seving the mobile network changes its point of attachment. router seving the mobile network changes its point of attachment.
The secondary goals of the work is to investigate the effects of The secondary goals of the work is to investigate the effects of
network mobility on various aspects of internet communication such as network mobility on various aspects of internet communication such as
routing protocol changes, implications of real-time traffic and fast routing protocol changes, implications of real-time traffic and fast
handovers, and optimizations. This should 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
security solutions if they are appropriate. Although a well-designed security solutions if they are appropriate. Although a well-designed
solution may include security inherent in other protocols, mobile solution may include security inherent in other protocols, mobile
networks also introduce new challenges. networks also introduce 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 [7]). However, the working networks (NEMO Extended Support, see [6] and [7] for a discussion on
group is not chartered to actually standardize a solution for routing optimization issues and [8] multihoming issues). However,
extgended support at this point in time. If deemed necessary, the the working group is not chartered to actually standardize a solution
working group will be rechartered based on the conclusions of the for extgended support at this point in time. If deemed necessary,
the working group will be rechartered based on the conclusions of the
discussions. discussions.
For NEMO Basic Support, the working group will assume that none of For NEMO Basic Support, the working group assumes that none of the
the nodes behind the MR will be aware of the network's mobility; nodes behind the MR is aware of the network's mobility; thus, the
thus, the network's movement needs to be completely transparent to network's movement needs to be completely transparent to the nodes
the nodes inside the mobile network. This assumption accommodates inside the mobile network. This assumption accommodates nodes inside
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 will adopt the methods for host mobility support used in support has adopted the methods for host mobility support used in
Mobile IP, and extend them in the simplest way possible to achieve Mobile IP, and has extended them in the simplest way possible to
its goals. The basic support solution, now defined in [3] following achieve its goals. The basic support solution, now defined in [3]
the requirements stated in Section 4 of the present document, is for following the requirements stated in Section 4 of the present
each MR to have a Home Agent, and use bi-directional tunneling document, is for each MR to have a Home Agent, and use bi-directional
between the MR and HA to preserve session continuity while the MR tunneling between the MR and HA to preserve session continuity while
moves. The MR will acquire a care-of address at its attachment point the MR moves. The MR acquires a Care-of address (CoA) at its
much like what is done for mobile nodes (MN), using Mobile IP. This attachment point much like what is done for mobile hosts (MH), using
approach allows nested mobile networks, since each MR will appear to Mobile IP. This approach allows nested mobile networks, since each
its attachment point as a single node. 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 6, line 10 skipping to change at page 7, line 35
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 be the MR(s). Specific support functions on any other performed only by the MR(s). Specific support functions on any 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 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
skipping to change at page 8, line 50 skipping to change at page 11, line 7
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 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 For basic network mobility support, the NEMO WG is to specify a
Basic Support" solution, hereafter referred to as "the solution". unified and unique "Network Mobility (NEMO) Basic Support" solution,
This solution is to allow all nodes in the mobile network to be hereafter referred to as "the solution". This solution is to allow
reachable via permanent IP addresses, as well as maintain ongoing all nodes in the mobile network to be reachable via permanent IP
sessions as the MR changes its point of attachment to the Internet addresses, as well as maintain ongoing sessions as the MR changes its
topology. This is to be done by maintaining a bi-directional tunnel point of attachment to the Internet topology. This is to be done by
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 the existing Mobile IPv6 [6] mechanisms for tunnel decided to reuse and extend the existing Mobile IPv6 [5] mechanisms
management, or extend it if deemed necessary. 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]. resulting specification which can now be found in [3]. Associated
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.
skipping to change at page 9, line 47 skipping to change at page 11, line 52
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. In particular, this includes: 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 to Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to
operate either the CN, HA, or MN operations defined in [6]) operate either the CN, HA, or MN operations defined in [5])
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 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
skipping to change at page 11, line 12 skipping to change at page 15, line 19
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 ADs at the time (Erik Nordmark and Thomas
Narten) who greatly helped to set up the NEMO working group. We are Narten) who greatly helped to set up the NEMO working group. We are
also grateful to all the following people whose comments highly also grateful to all the following people whose comments highly
contributed to the present document: T.J. Kniveton (Nokia), Alexandru contributed to the present document: T.J. Kniveton (Nokia), Alexandru
Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert
(Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and
all the others people who have expressed their opinions on the NEMO all the others people who have expressed their opinions on the NEMO
mailing lists (formely known as MONET). Thierry Ernst wishes to mailing lists (formely known as MONET). Thierry Ernst wishes to
personally acknowledge his previous employers, INRIA, and Motorola personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for
for their support and direction in bringing this topic up to the IETF their support and direction in bringing this topic up to the IETF
-- particularly Claude Castelluccia (INRIA) and Hong-Yon Lach back in year 2001 -- particularly Claude Castelluccia (INRIA) and
(Motorola). Hong-Yon Lach (Motorola) -- and his past employer, Keio University,
Japan which supported most of the costs associated with the IETF
during the timelife of previous versions of this document.
8. References 8. References
8.1. Normative References 8.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-04 (work in progress), October 2005. draft-ietf-nemo-terminology-06 (work in progress),
November 2006.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 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 8.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 to vehicle, and vehicle to point communication in the ITS sector
sector - Networking Protocol - Complementary Element", ISO - Networking Protocol - Complementary Element", ISO Draft ISO/WD
Draft ISO/WD 21210, February 2005. 21210, February 2005.
[5] Ernst, T. and K. Uehara, "Connecting Automobiles to the
Internet", Proceedings 3rd International Workshop on ITS
Telecommunications (ITST), November 2002.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-01 (work in
progress), October 2005.
[8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-04 (work in progress),
October 2005.
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
Network Models", draft-ietf-nemo-home-network-models-05 (work
in progress), June 2005.
[10] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6)", IETF RFC 2460, December 1998.
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 -04 and -05
Added a reference to [7]
Split references into Normative and Informational
Cosmetics changes
A.2. Changes between version -03 and -04
- Issue B1: English brush up
- Issue B2: Added a reference to [4] and [5] 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.3. Changes between version -02 and -03
- Mostly cosmetic changes
- Merged section Terminology into Introduction
- Cross-references with other NEMO WG docs
- Changed the introducion of section Section 4 and added reference to
NEMO Basic Support's resulting specification.
A.4. Changes Between Version -01 and -02
- removed sub-items in R12 (sub-cases are contained into the
definition of multihoming)
- minor typos
- R15: Added "multicast"
- R14.4: SHOULD softened to MAY according to discussion at IETF56th
meeting.
- R17 moved to R09 and contains former R09 as a sub-case.
- R18: relaxed from "SHOULD" to may based on Vijay Devarapalli [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
comment (030718) IPv6", RFC 3775, June 2004.
A.5. Changes Between Version -00 and -01 [6] Ng, C., Pascal, P., Masafumi, M., and F. Fan, "Network Mobility
Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-03 (work in progress),
September 2006.
- title of documents: included the word "goals" [7] Ng, C., Fan, F., Masafumi, M., and P. Pascal, "Network Mobility
Route Optimization Solution Space Analysis",
draft-ietf-nemo-ro-space-analysis-03 (work in progress),
September 2006.
- entire document: some rewording [8] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in
Network Mobility Support", draft-ietf-nemo-multihoming-issues-06
(work in progress), June 2006.
- section 4: changed title of section to "NEMO Design Goals". [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
Network Models", draft-ietf-nemo-home-network-models-06 (work in
progress), February 2006.
- section 4: removed "MUST" and "MAY" Author's Address
- section 4: more text about location privacy Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay, 78153
France
- section 4: changed "Administration" paragraph to "Local and Global Phone: +33 1 39 63 59 30
Mobility". Text enhanced. Fax: +33 1 39 63 54 91
Email: thierry.ernst@inria.fr
URI: http://www-rocq.inria.fr/imara
- section 5: R02: replace "between MR and MR's HA" with "an MR and Full Copyright Statement
its HA" R11: specified at least 2 levels R12: replaced "support" with
"function" and add "multihomed MR" R13.x renumbered to R12.x since
part of R12 (editing mistake) R13 and R18: new requirements proposed
by editor and minor changes in the formulation of other Requirements
Author's Address Copyright (C) The Internet Society (2006).
Thierry Ernst This document is subject to the rights, licenses and restrictions
Keio University / WIDE contained in BCP 78, and except as set forth therein, the authors
Jun Murai Lab., Keio University. retain all their rights.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600 This document and the information contained herein are provided on an
Fax: +81-44-580-1437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Email: ernst@sfc.wide.ad.jp OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
URI: http://www.sfc.wide.ad.jp/~ernst/ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement 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
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 16, line 29 skipping to change at page 18, 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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
209 lines changed or deleted 121 lines changed or added

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