< draft-thubert-nemo-ro-taxonomy-00.txt		draft-thubert-nemo-ro-taxonomy-01.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: April 11, 2003 Cisco Systems		Expires: December 2, 2003 Cisco Systems
	October 11, 2002		C. Ng
			Panasonic Singapore Labs
			June 3, 2003
	Taxonomy of Route Optimization models in the Nemo Context		Taxonomy of Route Optimization models in the Nemo Context
	draft-thubert-nemo-ro-taxonomy-00		draft-thubert-nemo-ro-taxonomy-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32 ¶		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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 11, 2003.		This Internet-Draft will expire on December 2, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	Nemo enables Mobile Networks by extending Mobile IP to support Mobile		Nemo enables Mobile Networks by extending Mobile IP to support Mobile
	Routers. This paper documents how the MIPv6 concept of Route		Routers. This paper documents how the MIPv6 concept of Route
	Optimization can to be adapted for Nemo to optimize:		Optimization can to be adapted for Nemo to optimize:
	1) the nested tunnels of the nested Nemo configuration		1. the nested tunnels of the nested Nemo configuration
	2) router-to-router within the infrastructure as opposed to end-to-		2. router-to-router in the infrastructure as opposed to end-to-end.
	end.
	and much more ... :)		and much more ... :)
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 3		2. Nested Mobile Network . . . . . . . . . . . . . . . . . . 3
	2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 3		2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . 3
	2.2 Route Optimization inside the Nested Mobile Network . . . . . 6		2.1.1 Pitfalls and threats . . . . . . . . . . . . . . . . . . . 7
	3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1.1.1 Securing the protocol . . . . . . . . . . . . . . . . . . 7
	4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . . . 6		2.1.1.2 Recursive complexity . . . . . . . . . . . . . . . . . . . 7
	5. Optimization within the infrastructure . . . . . . . . . . . . 7		2.2 Route Optimization inside the Nested Mobile Network . . . 8
	5.1 Route Optimization within a ISP network . . . . . . . . . . . 8		3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 8		4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . 9
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Optimization within the infrastructure . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		5.1 Route Optimization within a ISP network . . . . . . . . . 10
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11		5.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . 12
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 13
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13
			References . . . . . . . . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
			Full Copyright Statement . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document assumes the reader is familiar with Mobile IPv6 defined		This document assumes the reader is familiar with Mobile IPv6 defined
	in [1], with the concept of Mobile Router (MR) and with the Nemo		in [1], with the concept of Mobile Router (MR) and with the Nemo
	terminology defined in [2].		terminology defined in [2].
	From the discussions on the mailing list, it appears that the common		From the discussions on the mailing list, it appears that the common
	current understanding of the problem space of Route Optimization		current understanding of the problem space of Route Optimization
	(RO), in the Nemo context, is still limited.		(RO), in the Nemo context, is still limited.
	This paper attempts to clarify the state of the discussion and		This paper attempts to clarify the state of the discussion and
	propose a taxonomy of the various aspects of the problem.		propose a taxonomy of the various aspects of the problem. We will
			look at different possible types of route optimizations related to
			mobile network.
			Firstly, route optimizations involving nested mobile networks are
			explored. This involves minimizing the number of tunnels required
			when there is multiple levels of nesting.
			Secondly, the Mobile Router can initiate route optimization with
			corresponding nodes (CN) on behalf of the mobile network nodes (MNN).
			Thirdly, we consider the feasibility of having a visiting mobile node
			(VMN) performing MIPv6 RO over the NEMO base protocol.
			Lastly, we explore the prospect of performing RO over the routing
			infrastructure. This involve optimizing the route between two
			routers situated near to each end point.
	2. Nested Mobile Network		2. Nested Mobile Network
	2.1 Nested Tunnels Optimization		2.1 Nested Tunnels Optimization
	Let us illustrate the problem by an example. In this example, the		Let us illustrate the problem by an example. In this example, the
	nested Mobile Network has a tree topology. In the tree each node is		nested Mobile Network has a tree topology. In the tree each node is
	a basic Mobile Network, represented by its MR.		a basic Mobile Network, represented by its MR.
	+---------------------+		+---------------------+
	skipping to change at page 4, line 28 ¶		skipping to change at page 5, line 11 ¶
	MR1_HA ----------- MR1		MR1_HA ----------- MR1
	No Nested Tunnels Optimization		No Nested Tunnels Optimization
	Such a solution introduces the following problems:		Such a solution introduces the following problems:
	"Pinball" routing		"Pinball" routing
	Both inbound and outbound packets will flow via the HAs of all the		Both inbound and outbound packets will flow via the HAs of all the
	MRs on their path within the NEMO, with increased latency, less		MRs on their path within the NEMO, with increased latency, less
	resilience and more bandwidth usage.		resilience and more bandwidth usage. To illustrate this effect,
			the figure below shows the route taken by a packet sent from LFN
			to CN:
			+--> HAofMR1 ---------------------+
			| |
			+----------------- HAofMR2 <--+ |
			| |
			+---------------+ |
			| V
			HAofMR3 <------+ CN
			|
			|
			LFN --> MR1 --> MR2 --> MR3
			'Pinball' Routing
	Packet size		Packet size
	An extra IPv6 header is added per level of nesting to all the		An extra IPv6 header is added per level of nesting to all the
	packets. The header compression suggested in [4] cannot be		packets. The header compression suggested in [4] cannot be
	applied because both the source and destination (the intermediate		applied because both the source and destination (the intermediate
	MR and its HA), are different hop to hop.		MR and its HA), are different hop to hop.
	On the other hand, with a Nested Tunnel Optimization, we would have		On the other hand, with a Nested Tunnel Optimization, we would have
	at most one bi-directional tunnel outside the Mobile Network, that		at most one bi-directional tunnel outside the Mobile Network, that
	skipping to change at page 5, line 12 ¶		skipping to change at page 6, line 12 ¶
	or MR3, depending on the solution. In the case of a Mobile Node		or MR3, depending on the solution. In the case of a Mobile Node
	visiting Net3, that Mobile Node may also be the end-point.		visiting Net3, that Mobile Node may also be the end-point.
	The potential approaches for avoiding the nesting of tunnels include:		The potential approaches for avoiding the nesting of tunnels include:
	Mobile Aggregation		Mobile Aggregation
	This model applies to a category of problems were the Mobile		This model applies to a category of problems were the Mobile
	Networks share a same administration and consistently move		Networks share a same administration and consistently move
	together (e.g. a fleet at sea). In this model, there is a		together (e.g. a fleet at sea). In this model, there is a
	cascade of Home Agents. The main Home Agent is fixed in the		cascade of Home Agents.
	infrastructure, and advertises an aggregated view of all the
	Mobile Networks. This aggregation is actually divided over a		The main Home Agent is fixed in the infrastructure, and advertises
	number of Mobile Routers, the TLMRs. The TLMRs subdivide some of		an aggregated view of all the Mobile Networks. This aggregation
	their address space to the other Mobile Routers forming their		is actually divided over a number of Mobile Routers, the TLMRs.
	fleet, for which they are Home Agent. As Home Agents, the TLMRs		The TLMRs subdivide some of their address space to the other
	terminate MIP Tunnels from the inside of the Mobile Network. As		Mobile Routers forming their fleet, for which they are Home Agent.
	Mobile Router, they also terminate their home Tunnels. As
	routers, they forward packets between the 2 tunnels.		As Home Agents, the TLMRs terminate MIP Tunnels from the inside of
			the Mobile Network. As Mobile Router, they also terminate their
			home Tunnels. As routers, they forward packets between the 2
			tunnels.
	Surrogate		Surrogate
	The TLMR acts as a proxy in the MIP registration, in a fashion of		The TLMR acts as a proxy in the MIP registration, in a fashion of
	MIPv4 Foreign Agent or HMIP MAP (see [7]). For instance, the TLMR		MIPv4 Foreign Agent or HMIP MAP (see [8]). For instance, the TLMR
	maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and		maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and
	switches packets between the two.		switches packets between the two.
	Internal Routing and gateway		Internal Routing and gateway
	This item can be approached from a MANET standpoint. This was		This item can be approached from a MANET standpoint. This was
	already done for DSR (see [8]) and AODV (see [9] and [6]) From a		already done for DSR (see [9]) and AODV (see [10] and [7]) From a
	Nemo standpoint, a full MANET is not necessary since the goal is		Nemo standpoint, a full MANET is not necessary since the goal is
	to find a way to the infrastructure, as opposed to any-to-any		to find a way to the infrastructure, as opposed to any-to-any
	connectivity.		connectivity.
	RRH		RRH
	The Reverse Routing Header (RRH) approach avoids the multiple		The Reverse Routing Header (RRH) approach avoids the multiple
	encapsulation of the traffic but maintains the home tunnel of the		encapsulation of the traffic but maintains the home tunnel of the
	first MR on the egress path. It is described in details in [5].		first MR on the egress path. It is described in details in [5].
	The first MR on the way out (egress direction) encapsulates the		The first MR on the way out (egress direction) encapsulates the
	packet over its reverse tunnel, using a form of Record Route		packet over its reverse tunnel, using a form of Record Route
	header, the RRH.		header, the RRH.
	The next MRs simply swap their CoA and the source of the packet,		The next MRs simply swap their CoA and the source of the packet,
	saving the original source in the RRH. The HA transforms the RRH		saving the original source in the RRH. The HA transforms the RRH
	in a Routing Header to perform a Source Routing across the nested		in a Routing Header to perform a Source Routing across the nested
	Mobile Network, along the ingress path to the target MR.		Mobile Network, along the ingress path to the target MR.
			Access Router Option
			The Access Router Option (ARO) approach [6] is somewhat similar to
			the RRH in that only the home tunnel of the first MR in the egress
			path is maintained. This is done by having MR to send an ARO in
			Binding Update to inform its HA the address of its access router.
			Using this information, HA can build a Routing Header to source-
			route a packet to the target MR within in a nested mobile network.
			Details can be found in [6].
			2.1.1 Pitfalls and threats
			2.1.1.1 Securing the protocol
	These approaches are generally difficult to secure unless all the		These approaches are generally difficult to secure unless all the
	Mobile Routers and Visiting Mobile Node belong to a same		Mobile Routers and Visiting Mobile Node belong to a same
	administrative domain and share predefined Security Associations.		administrative domain and share predefined Security Associations.
			Even if an intermediate MR is 'trusted', this does not prove it is
			able to provide the necessary bandwidth, and may not provide a good
			service. Eventually, a MR that is capable of securing (IPSec) its
			traffic may select a Mobile Access Router based on quality of service
			heuristics as opposed as trust.
	The problem is global to the whole Mobile Network in the case of a		The problem is global to the whole Mobile Network in the case of a
	MANET-based solution. For an RRH-based solution, the threat comes		MANET-based solution. For an RRH-based solution, the threat comes
	from on-axis MRs in the nested Mobile Network but is mostly limited		from on-axis MRs in the nested Mobile Network but is mostly limited
	to denial of service. This is detailed in [5].		to denial of service. This is detailed in [5]. The approach taken
			is to limit the threat to Black Hole and Grey Hole by using IPSec.
			2.1.1.2 Recursive complexity
			A number of drafts and publications suggest -or can be extended to- a
			model where the Home Agent and any arbitrary Correspondent would
			actually get individual binding from the chain of nested Mobile
			Routers, and form a routing header appropriately.
			An intermediate MR would keep track of all the pending communications
			between hosts in its subtree of Mobile Networks and their CNs, and a
			binding message to each CN each time it changes its point of
			attachment.
			If this was done, then each CN, by receiving all the binding messages
			and processing them recursively, could infer a partial topology of
			the nested Mobile Network, sufficient to build a multi-hop routing
			header for packets sent to nodes inside the nested Mobile Network.
			However, this extension has a cost:
			1. Binding Update storm
			when one MR changes its point of attachment, it needs to send a
			BU to all the CNs of each node behind him. When the Mobile
			Network is nested, the number of nodes and relative CNs can be
			huge, leading to congestions and drops.
			2. Protocol Hacks
			Also, in order to send the BUs, the MR has to keep track of all
			the traffic it forwards to maintain his list of CNs. In case of
			IPSec tunneled traffic, that CN information may not be available.
			3. CN operation
			The computation burden of the CN becomes heavy, because it has to
			analyze each BU in a recursive fashion in order to infer nested
			Mobile Network topology required to build a multi hop routing
			header.
			4. Missing BU
			If a CN doesn't receive the full set of PSBU sent by the MR, it
			will not be able to infer the full path to a node inside the
			nested Mobile Network. The RH will be incomplete and the packet
			may or may not be delivered.
			5. Obsolete BU
			If the Binding messages are sent asynchronously by each MR, then,
			when the relative position of MRs and/or the TLMR point of
			attachment change rapidly, the image of Mobile Network that the
			CN maintains is highly unstable. If only one BU in the chain is
			obsolete due to the movement of an intermediate MR, the
			connectivity may be lost.
	2.2 Route Optimization inside the Nested Mobile Network		2.2 Route Optimization inside the Nested Mobile Network
	This is not part of the Nemo Charter. The expectation is that the		This is not part of the Nemo Charter.
	mobile routes installed by Nemo can cohabit with a MANET support that
	would perform the RO inside the Nested Mobile Network.		The expectation is that the mobile routes installed by Nemo can
			cohabit with a MANET support that would perform the RO inside the
			Nested Mobile Network. In other words, MIP redistributes its
			prefixes locally to a MANET and the MR-HA tunnel is bypassed.
	3. MR-to-CN		3. MR-to-CN
	This section covers the case where the Route Optimization is		This section covers the case where the Route Optimization is
	performed between the MR and the Correspondent Node.		performed between the MR and the Correspondent Node.
	A major issue is that the MIPv6 Reverse Routability test is broken,		A major issue is that the MIPv6 Reverse Routability test is broken,
	since it is meant to ensure that the CoA (the MR) an the Home Address		since it is meant to ensure that the CoA (the MR) an the Home Address
	(the Mobile Node) are collocated. With a Mobile Network, a LFN is		(the Mobile Node) are collocated. With a Mobile Network, a LFN is
	reachable via the Care-Of Address, but not at the Care-Of Address.		reachable via the Care-Of Address, but not at the Care-Of Address.
	skipping to change at page 6, line 47 ¶		skipping to change at page 9, line 35 ¶
	negotiation capability at this time.		negotiation capability at this time.
	4. MIPv6 Route Optimization over Nemo		4. MIPv6 Route Optimization over Nemo
	When a Mobile Node visits a Mobile Network, the best Route		When a Mobile Node visits a Mobile Network, the best Route
	Optimization is obtained if the path in the Infrastructure is the		Optimization is obtained if the path in the Infrastructure is the
	same as if the Mobile Network was attached at the attachment point of		same as if the Mobile Network was attached at the attachment point of
	the Mobile Router (i.e., there is not additional Tunneling that is		the Mobile Router (i.e., there is not additional Tunneling that is
	linked to Nemo).		linked to Nemo).
	An example of that is a Mobile Node with RRH capability. If the		A possible approach to this is to extend the solution for nested
	Mobile Node emits packets with a RRH (as if it where the first MR),		mobile network optimization to include VMN as well. In this case,
	then the MRs just add to the RRH but do not affect its path. The CN		the VMN is treated as though it is an MR. This type of solution will
	must respond with RH type 2 based on RRH and if so, the MIP optimized		most likely require some extensions for a MIPv6 VMN and CN.
	path can be used.
	5. Optimization within the infrastructure		5. Optimization within the infrastructure
	This section elaborates on cases where the Route Optimization is		This section elaborates on cases where the Route Optimization is
	performed within the Routing Infrastructure. In this model, both the		performed within the Routing Infrastructure. In this model, both the
	LFN behind the MR and the Correspondent can be MIP agnostic. The		LFN behind the MR and the Correspondent can be MIP agnostic. The
	drawback is the introduction of Mobile Routes in specific Routers,		drawback is the introduction of Mobile Routes in specific Routers,
	causing additional signaling and load to the Routing Fabric.		causing additional signaling and load to the Routing Fabric.
	The general idea is that there is a correspondent-side Router in the		The general idea is that there is a correspondent-side Router in the
	skipping to change at page 8, line 45 ¶		skipping to change at page 11, line 36 ¶
	| | |		| | |
	+-------------------+ ===========Mobile Network========		+-------------------+ ===========Mobile Network========
	Correspondent Router		Correspondent Router
	The MR locates the CR for a given Correspondent and establishes a		The MR locates the CR for a given Correspondent and establishes a
	Tunnel to the CR for that destination and its prefix(es). Then, the		Tunnel to the CR for that destination and its prefix(es). Then, the
	CR establishes the Tunnel back to the MR and the Mobile Routes to the		CR establishes the Tunnel back to the MR and the Mobile Routes to the
	MR's Mobile Networks via that Tunnel.		MR's Mobile Networks via that Tunnel.
	Clearly, some extended MIP signaling has to be defined is to get
	there in a secure fashion.
	A key point is that the CR must be on the interception path of the		A key point is that the CR must be on the interception path of the
	traffic from the Correspondent to the Mobile Networks in order to		traffic from the Correspondent to the Mobile Networks in order to
	reroute the traffic over the appropriate Tunnel. This can be		reroute the traffic over the appropriate Tunnel. This can be
	achieved in several fashions:		achieved in several fashions:
	Redistribution		Redistribution
	There's a limited Number of CRs that cover an Autonomous System.		There's a limited Number of CRs that cover an Autonomous System.
	They redistribute the Mobile Routes on the fly, or within rate and		They redistribute the Mobile Routes on the fly, or within rate and
	amount limits. Garbage Collection is done at appropriate time to		amount limits. Garbage Collection is done at appropriate time to
	skipping to change at page 9, line 25 ¶		skipping to change at page 12, line 12 ¶
	AS of the Correspondent (it's a border gateway). In this case,		AS of the Correspondent (it's a border gateway). In this case,
	redistribution is not needed.		redistribution is not needed.
	Core Routers		Core Routers
	The Core Routers for the network of the Correspondent are all CRs.		The Core Routers for the network of the Correspondent are all CRs.
	If the path from the correspondent to the Home Agent does not pass		If the path from the correspondent to the Home Agent does not pass
	via a CR, then it's not worth optimizing. If it is, then the CRs		via a CR, then it's not worth optimizing. If it is, then the CRs
	are on the way. Again, redistribution is not needed.		are on the way. Again, redistribution is not needed.
			5.3 Distributed Anchor Routers
			Taking the idea of a correspondent router a step further, it is
			possible to have a distributed set of anchor routers across the
			Internet. Outgoing packets sent from a mobile network will be
			tunneled to one of the nearest anchor router (instead of to the home
			agent of the mobile router). This M-Side (Mobile Network Side)
			anchor router will decapsulate the packet, inspect the destination,
			and tunnel the packet to another anchor router situated near the CN
			(C-Side Anchor Router). From there, the packet will be decapsulated
			and forwarded to the CN.
			Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent
			o # n #
			o # n # # :== Tunnel
			o # n # o :== Optimized
			o # n # n :== Non-Optimized
			o # n #
			C-Side ################## M-Side ###### n #
			Anchor oooooooooooooooooo Anchor oooo Mobile
			Router ################## Router #### Router
			|
			====Mobile Network=======
			Optimization in the Infrastructure
			The C-Side Anchor Router will be subjected to the same condition as
			listed in the previous sub-section if packets sent from the CN to the
			mobile network are to be route-optimized too. Otherwise, the
			solution will only partially optimize routing to a triangular routing
			(i.e. packet sent by CN will still go through the home agent of the
			mobile network).
			The anchor router share many similarities with the concept of
			Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)
			[8]. In fact, it can be combined with HMIPv6 whereby each M-Side
			anchor router is also an MAP, and the MR obtains a regional care-of-
			address from the MAP.
	6. Conclusion		6. Conclusion
	The Problem space of Route Optimization in the Nemo context is		The Problem space of Route Optimization in the Nemo context is
	multifold and can be split is several work areas. It will be		multifold and can be split is several work areas. It will be
	critical, though, that the solution to a given piece of the puzzle be		critical, though, that the solution to a given piece of the puzzle be
	compatible and integrate smoothly with the others.		compatible and integrate smoothly with the others.
	Hopefully, the solutions will build on MIPv6 ([1]), as recommended by		Hopefully, the solutions will build on MIPv6 ([1]), as recommended by
	the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a		the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a
	direction that makes it more and more difficult to provide a Nemo		direction that makes it more and more difficult to provide a Nemo
	skipping to change at page 10, line 14 ¶		skipping to change at page 14, line 8 ¶
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki		The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki
	Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji		Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji
	Wakikawa and Patrick Wetterwald for their various contributions.		Wakikawa and Patrick Wetterwald for their various contributions.
	References		References
	[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in		[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July		IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), March
	2002.		2003.
	[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[2] Lach, H. and T. Ernst, "Network Mobility Support Terminology",
	draft-ernst-monet-terminology-01 (work in progress), July 2002.		draft-ietf-nemo-terminology-00 (work in progress), May 2003.
	[3] Kniveton, T., "Mobile Router Support with Mobile IP", draft-		[3] Kniveton, T., "Mobile Router Tunneling Protocol", draft-
	kniveton-mobrtr-02 (work in progress), July 2002.		kniveton-mobrtr-03 (work in progress), November 2002.
	[4] Deering, S. and B. Zill, "Redundant Address Deletion when		[4] Deering, S. and B. Zill, "Redundant Address Deletion when
	Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-		Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-
	deletion-00 (work in progress), November 2001.		deletion-00 (work in progress), November 2001.
	[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and		[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
	its application to Mobile Networks", draft-thubert-nemo-		its application to Mobile Networks", draft-thubert-nemo-
	reverse-routing-header-00 (work in progress), June 2002.		reverse-routing-header-01 (work in progress), October 2002.
	[6] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc		[6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization
	Networks", draft-wakikawa-manet-globalv6-01 (work in progress),		with Access Router Option", draft-ng-nemo-access-router-option-
	July 2002.		00 (work in progress), November 2002.
	[7] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier,		[7] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc
	"Hierarchical MIPv6 mobility management (HMIPv6)", draft-ietf-		Networks", draft-wakikawa-manet-globalv6-02 (work in progress),
	mobileip-hmipv6-06 (work in progress), July 2002.		November 2002.
	[8] Johnson, D., Maltz, D., Hu, Y. and J. Jetcheva, "The Dynamic		[8] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier,
			"Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-
			ietf-mobileip-hmipv6-07 (work in progress), October 2002.
			[9] Johnson, D., Maltz, D., Broch, J. and J. Jetcheva, "The Dynamic
	Source Routing Protocol for Mobile Ad Hoc Networks", draft-		Source Routing Protocol for Mobile Ad Hoc Networks", draft-
	ietf-manet-dsr-07 (work in progress), February 2002.		ietf-manet-dsr-07 (work in progress), February 2002.
	[9] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance		[10] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance
	Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in		Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in
	progress), July 2002.		progress), February 2003.
	[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September
	1981.		1981.
	[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert		Pascal Thubert
	Cisco Systems Technology Center		Cisco Systems Technology Center
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue Roumanille		400, Avenue Roumanille
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	skipping to change at page 12, line 5 ¶		skipping to change at page 15, line 25 ¶
	Marco Molteni		Marco Molteni
	Cisco Systems Technology Center		Cisco Systems Technology Center
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue Roumanille		400, Avenue Roumanille
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	EMail: mmolteni@cisco.com		EMail: mmolteni@cisco.com
			Chan-Wah Ng
			Panasonic Singapore Laboratories Pte Ltd
			Blk 1022 Tai Seng Ave #06-3530
			Tai Seng Industrial Estate
			Singapore 534415
			SG
			EMail: cwng@psl.com.sg
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 31 change blocks.
	67 lines changed or deleted		233 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/