< draft-ietf-nemo-requirements-04.txt		draft-ietf-nemo-requirements-05.txt >
	NEMO Working Group T. Ernst		NEMO Working Group T. Ernst
	Internet-Draft WIDE at Keio University		Internet-Draft Keio University / WIDE
	Expires: August 25, 2005 February 21, 2005		Expires: April 27, 2006 October 24, 2005
	Network Mobility Support Goals and Requirements		Network Mobility Support Goals and Requirements
	draft-ietf-nemo-requirements-04		draft-ietf-nemo-requirements-05
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		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-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 25, 2005.		This Internet-Draft will expire on April 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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 . . . . . . . . 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
	3.3 Network Mobility Support Transparency . . . . . . . . . . 5		3.3. Network Mobility Support Transparency . . . . . . . . . . 6
	3.4 Operational Transparency . . . . . . . . . . . . . . . . . 6		3.4. Operational Transparency . . . . . . . . . . . . . . . . . 6
	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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	A. Change Log From Earlier Versions . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.1 Changes between version -03 and -04 . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	A.2 Changes between version -02 and -03 . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 11
	A.3 Changes Between Version -01 and -02 . . . . . . . . . . . 12
	A.4 Changes Between Version -00 and -01 . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . 14		Appendix A. Change Log From Earlier Versions . . . . . . . . . . 13
			A.1. Changes between version -04 and -05 . . . . . . . . . . . 13
			A.2. Changes between version -03 and -04 . . . . . . . . . . . 13
			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
			Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Network mobility support is concerned with managing the mobility of		Network mobility support (see [1] for the related terminology) is
	an entire network, viewed as a single unit, which changes its point		concerned with managing the mobility of an entire network, viewed as
	of attachment to the Internet and thus its reachability in the		a single unit, which changes its point of attachment to the Internet
	Internet topology. Such a network is referred to as a mobile network		and thus its reachability in the Internet topology. Such a network
	and includes one or more mobile routers (MRs) which connect it to the		is referred to as a mobile network and includes one or more mobile
	global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs)		routers (MRs) which connect it to the global Internet. Nodes behind
	and mobile (VMNs or LMNs). In most cases, the internal structure of		the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In
	the mobile network will be relatively stable (no dynamic change of		most cases, the internal structure of the mobile network will be
	the topology), but this is not always true.		relatively stable (no dynamic change of the topology), but this is
			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 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 ([9], [8]).		(Intelligent Transportation Systems) applications ([4], [5]).
	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 [4] 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
	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 node (CNs) in the global Internet and
	those MNNs located within the mobile network. In addition, the		those MNNs located within the mobile network. In addition, the
	communication path between MNNs and correspondent nodes becomes		communication path between MNNs and correspondent nodes becomes sub-
	sub-optimal, and multiple levels of mobility will cause extremely		optimal, and multiple levels of mobility will cause extremely sub-
	sub-optimal routing.		optimal routing.
	Mobility-related terms used in this document are defined in [3],		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 [4]. 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 4 for basic network mobility support [2].		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. At that time, work conducted on mobility support
	(particularly in the Mobile IP working group) was to provide		(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 [1] are unable to support network mobility. The NEMO working		IPv6 [6] 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)
	and studying the possible approaches and issues with providing more		(see [3]), and studying the possible approaches and issues with
	optimal routing with potentially nested mobile networks (NEMO		providing more optimal routing with potentially nested mobile
	Extended Support). However, the working group is not chartered to		networks (NEMO Extended Support) (see [7]). However, the working
	actually standardize a solution for extgended support at this point		group is not chartered to actually standardize a solution for
	in time. If deemed necessary, the working group will be rechartered		extgended support at this point in time. If deemed necessary, the
	based on the conclusions of the discussions.		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;		the nodes behind the MR will be aware of the network's mobility;
	thus, the network's movement needs to be completely transparent to		thus, the network's movement needs to be completely transparent to
	the nodes inside the mobile network. This assumption accommodates		the nodes inside the mobile network. This assumption accommodates
	nodes inside the network that are not generally aware of mobility.		nodes inside 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 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, now defined in [2] following		its goals. The basic support solution, now defined in [3] following
	the requirements stated in Section 4 of the present document, is for		the requirements stated in Section 4 of the present document, is for
	each MR to have a Home Agent, and use bi-directional tunneling		each MR to have a Home Agent, and use bi-directional tunneling
	between the MR and HA to preserve session continuity while the MR		between the MR and HA to preserve session continuity while the MR
	moves. The MR will acquire a care-of address at its attachment point		moves. The MR will acquire a care-of address at its attachment point
	much like what is done for mobile nodes (MN), using Mobile IP. This		much like what is done for mobile nodes (MN), using Mobile IP. This
	approach allows nested mobile networks, since each MR will appear to		approach allows nested mobile networks, since each MR will appear to
	its attachment point as a single node.		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
	Permanent connectivity to the Internet has to be provided to all		Permanent connectivity to the Internet has to be provided to all
	MNNs, since 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 maintaining those		mobile router changes its point of attachment. For maintaining those
	sessions, MNNs are expected to be reachable via their permanent IP		sessions, MNNs are expected to be reachable via their permanent IP
	addresses.		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 handovers on 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) 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 be 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
	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
	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 ones are desirable:		cannot be limited, at least the following ones are 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
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 42 ¶
	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 analysis in [5]).		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 [4]). Although the complexity		networks (see definition in [1]). 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. 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 [3]).		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
	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 different administrative		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 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 interfer 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 modidication:
	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,
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 13 ¶
	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 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 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 to usurp
	identities and forge data. Specifically, the following issues have		identities and forge data. Specifically, the following issues have
	to be considered:		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 to hide the actual location of MNNS 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 analysing 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 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 bi-directional tunnel		topology. This is to be done by maintaining a bi-directional tunnel
	between an MR and its Home Agent.		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 [1] mechanisms for tunnel		decided to reuse the existing Mobile IPv6 [6] mechanisms for tunnel
	management, or extend it if deemed necessary.		management, or extend it if deemed necessary.
	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 [2].		resulting specification which can now be found in [3].
	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 42 ¶		skipping to change at page 9, line 46 ¶
	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. 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		Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to
	to operate either the CN, HA, or MN operations defined in [1])		operate either the CN, HA, or MN operations defined in [6])
	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 [4].		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 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)		renumbering, 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. Acknowledgments		5. Security Considerations
			As this document only provides a discussion about design goals and
			describes neither a protocol nor an implementation or a procedure,
			there are no security considerations associated with it.
			6. IANA Considerations
			This document requires no IANA actions.
			7. 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 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),		contributed to the present document: T.J. Kniveton (Nokia), Alexandru
	Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola),		Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert
	Pascal Thubert (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson		(Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and
	(Ericsson) and all the others people who have expressed their		all the others people who have expressed their opinions on the NEMO
	opinions on the NEMO mailing lists (formely known as MONET). Thierry		mailing lists (formely known as MONET). Thierry Ernst wishes to
	Ernst wishes to personally acknowledge his previous employers, INRIA,		personally acknowledge his previous employers, INRIA, and Motorola
	and Motorola for their support and direction in bringing this topic		for their support and direction in bringing this topic up to the IETF
	up to the IETF -- particularly Claude Castelluccia (INRIA) and		-- particularly Claude Castelluccia (INRIA) and Hong-Yon Lach
	Hong-Yon Lach (Motorola).		(Motorola).
	6. References		8. References
	[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		8.1. Normative References
	IPv6", RFC 3775, June 2004.
	[2] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert,		[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		draft-ietf-nemo-terminology-04 (work in progress), October 2005.
	January 2005.
	[3] 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.
	[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	Internet-Draft draft-ietf-nemo-terminology-03, February 2005.		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
			January 2005.
	[5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in		8.2. Informative References
	Network Mobility Support",
	Internet-Draft draft-ietf-nemo-multihoming-issues-02, February
	2005.
	[6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network		[4] "CALM - Medium and Long Range, High Speed, Air Interfaces
	Models", Internet-Draft draft-ietf-nemo-home-network-models-01,		parameters and protocols for broadcast, point to point, vehicle
	October 2004.		to vehicle, and vehicle to point communication in the ITS
			sector - Networking Protocol - Complementary Element", ISO
			Draft ISO/WD 21210, February 2005.
	[7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)",		[5] Ernst, T. and K. Uehara, "Connecting Automobiles to the
	IETF RFC 2460, December 1998.		Internet", Proceedings 3rd International Workshop on ITS
			Telecommunications (ITST), November 2002.
	[8] Ernst, T. and K. Uehara, "Connecting Automobiles to the		[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	Internet", Proceedings 3rd International Workshop on ITS		IPv6", RFC 3775, June 2004.
	Telecommunications (ITST), November 2002.
	[9] "CALM - Medium and Long Range, High Speed, Air Interfaces		[7] Ng, C., "Network Mobility Route Optimization Problem
	parameters and protocols for broadcast, point to point, vehicle		Statement", draft-ietf-nemo-ro-problem-statement-01 (work in
	to vehicle, and vehicle to point communication in the ITS sector		progress), October 2005.
	- Networking Protocol - Complementary Element", ISO Drat ISO/WD
	21210, February 2005.
	Author's Address		[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.
	Thierry Ernst		[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
	WIDE at Keio University		Network Models", draft-ietf-nemo-home-network-models-05 (work
	Jun Murai Lab., Keio University.		in progress), June 2005.
	K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
	Kawasaki, Kanagawa 212-0054
	Japan
	Phone: +81-44-580-1600		[10] Deering, S. and R. Hinden, "Internet Protocol Version 6
	Fax: +81-44-580-1437		(IPv6)", IETF RFC 2460, December 1998.
	Email: ernst@sfc.wide.ad.jp
	URI: http://www.sfc.wide.ad.jp/~ernst/
	Appendix A. Change Log From Earlier Versions		Appendix A. Change Log From Earlier Versions
	The discussions behind the changes in the lattest versions of this		The discussions behind the changes in the lattest versions of this
	documents are reflected in the "issue" web page:		documents are reflected in the "issue" web page:
	http://www.sfc.wide.ad.jp/~ernst/nemo/		http://www.sfc.wide.ad.jp/~ernst/nemo/
	A.1 Changes between version -03 and -04		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 B1: English brush up
	- Issue B2: Added a reference to [9] and [8] when speaking about		- Issue B2: Added a reference to [4] and [5] when speaking about
	usages.		usages.
	- Issue B3: The following paragraph from section 1 was partly		- Issue B3: The following paragraph from section 1 was partly
	removed; the remaining part was moved to section 2 and rephrased:		removed; the remaining part was moved to section 2 and rephrased:
	"The mechanisms required for handling such mobility issues are		"The mechanisms required for handling such mobility issues are
	currently lacking within the IETF standards. Traditional work		currently lacking within the IETF standards. Traditional work
	conducted on mobility support (particularly in the Mobile IP working		conducted on mobility support (particularly in the Mobile IP working
	group) is to provide continuous Internet connectivity and optimal		group) is to provide continuous Internet connectivity and optimal
	routing to mobile hosts only (host mobility support) and are unable		routing to mobile hosts only (host mobility support) and are unable
	to support network mobility. The NEMO working group has therefore		to support network mobility. The NEMO working group has therefore
	been set up to deal with issues specific to network mobility. The		been set up to deal with issues specific to network mobility. The
	purpose of this document is thus to detail the methodology that will		purpose of this document is thus to detail the methodology that will
	be followed by the NEMO working group, its goals, and to define		be followed by the NEMO working group, its goals, and to define
	requirements for network mobility support."		requirements for network mobility support."
	- Issue B4: Effectively removed former requirements about "impact on		- Issue B4: Effectively removed former requirements about "impact on
	the routing fabric".		the routing fabric".
	A.2 Changes between version -02 and -03		A.3. 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.
	A.3 Changes Between Version -01 and -02		A.4. 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)
	A.4 Changes Between Version -00 and -01		A.5. 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 "an MR and		- section 5: R02: replace "between MR and MR's HA" with "an MR and
	its 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
			Author's Address
			Thierry Ernst
			Keio University / WIDE
			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.
End of changes. 67 change blocks.
	136 lines changed or deleted		168 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/