< draft-thubert-nemo-reverse-routing-header-00.txt		draft-thubert-nemo-reverse-routing-header-01.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: December 18, 2002 Cisco Systems		Expires: April 11, 2003 Cisco Systems
	June 19, 2002		October 11, 2002
	IPv6 Reverse Routing Header and its application to Mobile Networks		IPv6 Reverse Routing Header and its application to Mobile Networks
	draft-thubert-nemo-reverse-routing-header-00		draft-thubert-nemo-reverse-routing-header-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 32 ¶
	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 December 18, 2002.		This Internet-Draft will expire on April 11, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	Already existing proposals enable Mobile Networks by extending Mobile		Already existing proposals enable Mobile Networks by extending Mobile
	IP to support Mobile Routers. In order to enable nested Mobile		IP to support Mobile Routers. In order to enable nested Mobile
	Networks, some involve the overhead of nested tunnels between the		Networks, some involve the overhead of nested tunnels between the
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . . 10		4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . . 10
	4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . . 12		4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . . 12
	4.3 Extension Header order . . . . . . . . . . . . . . . . . . . 14		4.3 Extension Header order . . . . . . . . . . . . . . . . . . . 14
	5. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 17		6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 17
	6.1 Modified Router Advertisement Message Format . . . . . . . . 17		6.1 Modified Router Advertisement Message Format . . . . . . . . 17
	6.2 New Tree Information Option Format . . . . . . . . . . . . . 18		6.2 New Tree Information Option Format . . . . . . . . . . . . . 18
	7. Binding Cache Management . . . . . . . . . . . . . . . . . . 20		7. Binding Cache Management . . . . . . . . . . . . . . . . . . 20
	7.1 Binding Updates . . . . . . . . . . . . . . . . . . . . . . 20		7.1 Binding Updates . . . . . . . . . . . . . . . . . . . . . . 20
	7.2 RRH Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 20		7.2 RRH Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 20
	8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 20		8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 21
	9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 22		9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 22
	9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . . 22		9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . . 23
	9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . . 23		9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . . 23
	9.3 Processing of RHH for Outbound Packets . . . . . . . . . . . 24		9.3 Processing of RHH for Outbound Packets . . . . . . . . . . . 24
	9.4 Processing of Tree Information Option . . . . . . . . . . . 24		9.4 Processing of Tree Information Option . . . . . . . . . . . 24
	9.5 Processing of the extended Routing Header Type 2 . . . . . . 25		9.5 Processing of the extended Routing Header Type 2 . . . . . . 25
	9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 26		9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 26
	10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 26		10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 26
	11. Security Considerations . . . . . . . . . . . . . . . . . . 27		11. Security Considerations . . . . . . . . . . . . . . . . . . 27
	11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . . 27		11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . . 27
	11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . . 28		11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . . 28
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	References . . . . . . . . . . . . . . . . . . . . . . . . . 29		References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
	A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 30		A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 30
	A.1 Prefix Scope Binding Updates . . . . . . . . . . . . . . . . 30		A.1 Prefix Scope Binding Updates . . . . . . . . . . . . . . . . 30
	A.2 Path Optimization with RRH . . . . . . . . . . . . . . . . . 31		A.2 Path Optimization with RRH . . . . . . . . . . . . . . . . . 31
	A.3 Packet Size Optimization . . . . . . . . . . . . . . . . . . 32		A.3 Packet Size Optimization . . . . . . . . . . . . . . . . . . 32
	A.3.1 Routing Header Type 3 (HAddr option replacement) . . . . . . 34		A.3.1 Routing Header Type 3 (HAddr option replacement) . . . . . . 34
	B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 35		B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 35
	B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . . 35		B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . . 35
	B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . . 36		B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . . 36
			C. Changes from Previous Version of the Draft . . . . . . . . . 37
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 38		Full Copyright Statement . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document assumes the reader is familiar with the Mobile Networks		This document assumes the reader is familiar with the Mobile Networks
	terminology defined in [2] and with Mobile IPv6 defined in [1].		terminology defined in [2] and with Mobile IPv6 defined in [1].
	Generally a NEMO may be either simple (a network with one mobile		Generally a Mobile Network may be either simple (a network with one
	router) or nested, single or multi-homed. This proposal starts from		mobile router) or nested, single or multi-homed. This proposal
	the assumption that nested NEMOs will be the norm, and so presents a		starts from the assumption that nested Mobile Networks will be the
	solution that avoids the tunnel within tunnel overhead of already		norm, and so presents a solution that avoids the tunnel within tunnel
	existing proposals.		overhead of already existing proposals.
	The solution is based on a single bi-directional tunnel between the		The solution is based on a single bi-directional tunnel between the
	first Mobile Router (MR) to forward a packet and its Home Agent (HA).		first Mobile Router (MR) to forward a packet and its Home Agent (HA).
	By using IPsec ESP on that tunnel, home equivalent privacy is		By using IPsec ESP on that tunnel, home equivalent privacy is
	obtained without further encapsulation.		obtained without further encapsulation.
	The solution uses a new Routing Header (RH), called the Reverse		The solution uses a new Routing Header (RH), called the Reverse
	Routing Header (RRH), to provide an optimized path for the single		Routing Header (RRH), to provide an optimized path for the single
	tunnel. RRH is a variant of IPv4 Loose Source and Record Route		tunnel. RRH is a variant of IPv4 Loose Source and Record Route
	(LSRR) [6] adapted for IPv6. RRH records the route out of the nested		(LSRR) [6] adapted for IPv6. RRH records the route out of the nested
	NEMO and can be trivially converted into a routing header for packets		Mobile Network and can be trivially converted into a routing header
	destined to the NEMO.		for packets destined to the Mobile Network.
	This version focuses on single-homed NEMOs. Hints for further		This version focuses on single-homed Mobile Networks. Hints for
	optimizations and multi-homing are given in the appendixes.		further optimizations and multi-homing are given in the appendixes.
	Local Fixed Node (LFN) and Correspondent Node (CN) operations are		Local Fixed Node (LFN) and Correspondent Node (CN) operations are
	left unchanged as in [1]. Specifically the CN can also be a LFN.		left unchanged as in [1]. Specifically the CN can also be a LFN.
	Section 3 proposes an example to illustrate the operation of the		Section 3 proposes an example to illustrate the operation of the
	proposed solution, leaving detailed specifications to the remaining		proposed solution, leaving detailed specifications to the remaining
	chapters. The reader may refer to Section 2.1 for the specific		chapters. The reader may refer to Section 2.1 for the specific
	terminology.		terminology.
	1.1 Extending existing solutions		1.1 Extending existing solutions
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 51 ¶
	This proposal extends [1] to support simple and nested Mobile		This proposal extends [1] to support simple and nested Mobile
	Networks.		Networks.
	This paper also builds on an other existing proposal, [3], which is		This paper also builds on an other existing proposal, [3], which is
	based on nested tunnels, in order to address the following problems,		based on nested tunnels, in order to address the following problems,
	introduced by that solution:		introduced by that solution:
	"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 Mobile Network, with increased
	resilience and more bandwidth usage.		latency, less resilience and more bandwidth usage.
	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 [5] cannot be		packets. The header compression suggested in [5] 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.
	2. Terminology and Assumptions		2. Terminology and Assumptions
	2.1 Terminology		2.1 Terminology
	Simple NEMO		Simple Mobile Network
	One or more IP subnets attached to a MR and mobile as a unit, with		One or more IP subnets attached to a MR and mobile as a unit, with
	respect to the rest of the Internet. A simple NEMO can be either		respect to the rest of the Internet. A simple Mobile Network can
	single or multi-homed.		be either single or multi-homed.
	The IP subnets may have any kind of topology and may contain fixed		The IP subnets may have any kind of topology and may contain fixed
	routers. All the access points of the NEMO (to which further MRs		routers. All the access points of the Mobile Network (to which
	may attach) are on the same layer 2 link of the MR.		further MRs may attach) are on the same layer 2 link of the MR.
	We like to represent a simple single-homed NEMO as an hanger,		We like to represent a simple single-homed Mobile Network as an
	because it has only one uplink hook and a bar to which multiple		hanger, because it has only one uplink hook and a bar to which
	hooks can be attached. Graphically we use the question mark "?"		multiple hooks can be attached. Graphically we use the question
	to show the uplink hook (interface) connected to the MR, and the		mark "?" to show the uplink hook (interface) connected to the MR,
	"=" sign to represent the bar:		and the "=" sign to represent the bar:
	?		?
	MR1		MR1
	|		|
	===============		===============
	Nested NEMO		Nested Mobile Network
	A group of simple NEMOs recursively attached together and		A group of simple Mobile Networks recursively attached together
	implementing nested Mobility as defined in [2].		and implementing nested Mobility as defined in [2].
	?		?
	MR1		MR1
	|		|
	====?===============?====		====?===============?====
	MR2 MR3		MR2 MR3
	| |		| |
	=========== ===?==========?===		=========== ===?==========?===
	MR4 MR5		MR4 MR5
	| |		| |
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	IPv6 Mobile Host		IPv6 Mobile Host
	A IPv6 Host, with support for MIPv6 MN, and the additional Nemo		A IPv6 Host, with support for MIPv6 MN, and the additional Nemo
	capability described in this draft.		capability described in this draft.
	Home prefix		Home prefix
	Network prefix, which identifies the home link within the Internet		Network prefix, which identifies the home link within the Internet
	topology.		topology.
	NEMO prefix		Mobile Network prefix
	Network prefix, common to all IP addresses in the NEMO when the MR		Network prefix, common to all IP addresses in the Mobile Network
	is attached to the home link. It may or may not be a subset of		when the MR is attached to the home link. It may or may not be a
	the Home subnet prefix.		subset of the Home subnet prefix.
	Inbound direction:		Inbound direction:
	direction from outside the NEMO to inside		direction from outside the Mobile Network to inside
	Outbound direction:		Outbound direction:
	direction from inside the NEMO to outside		direction from inside the Mobile Network to outside
	2.2 Assumptions		2.2 Assumptions
	We make the following assumptions:		We make the following assumptions:
	1. A MR has one Home Agent and one Home Address -> one primary CoA.		1. A MR has one Home Agent and one Home Address -> one primary CoA.
	2. A MR attaches to a single Access Router as default router.		2. A MR attaches to a single Attachment Router as default router.
	3. A MR may have more than one uplink interface.		3. A MR may have more than one uplink interface.
	4. An interface can be either wired or wireless. The text assumes		4. An interface can be either wired or wireless. The text assumes
	that interfaces are wireless for generality.		that interfaces are wireless for generality.
	5. Each simple NEMO may have more that one L2 Access Point, all of		5. Each simple Mobile Network may have more that one L2 Access
	them controlled by the same Access Router, which we assume to be		Point, all of them controlled by the same Attachment Router,
	the Mobile Router.		which we assume to be the Mobile Router.
	Since an MR has only one primary CoA, only one uplink interface can		Since an MR has only one primary CoA, only one uplink interface can
	be used at a given point of time. Since the MR attaches to a single		be used at a given point of time. Since the MR attaches to a single
	access router, if due care is applied to avoid loops, then the		attachment router, if due care is applied to avoid loops, then the
	resulting topology is a tree.		resulting topology is a tree.
	3. An Example		3. An Example
	The nested NEMO in the following figure has a tree topology,		The nested Mobile Network in the following figure has a tree
	according to the assumptions in Section 2.2. In the tree each node		topology, according to the assumptions in Section 2.2. In the tree
	is a simple NEMO, represented by its MR.		each node is a simple Mobile Network, represented by its MR.
	+---------------------+		+---------------------+
	| Internet |---CN		| Internet |---CN
	+---------------|-----+		+---------------|-----+
	/ Access Router		/ Access Router
	MR3_HA |		MR3_HA |
	======?======		======?======
	MR1		MR1
	|		|
	====?=============?==============?===		====?=============?==============?===
	MR5 MR2 MR6		MR5 MR2 MR6
	| | |		| | |
	=========== ===?========= =============		=========== ===?========= =============
	MR3		MR3
	|		|
	==|=========?== <-- NEMO3		==|=========?== <-- Mobile Network3
	LFN1 MR4		LFN1 MR4
	|		|
	=========		=========
	An example nested NEMO		An example nested Mobile Network
	This example focuses on a NEMO node at depth 3 (NEMO3) inside the		This example focuses on a Mobile Network node at depth 3 (Mobile
	tree, represented by its mobile router MR3. The path to the Top		Network3) inside the tree, represented by its mobile router MR3. The
	Level Mobile Router (TLMR) MR1 and then the Internet is		path to the Top Level Mobile Router (TLMR) MR1 and then the Internet
			is
	MR3 -> MR2 -> MR1 -> Internet		MR3 -> MR2 -> MR1 -> Internet
	Consider the case where a LFN belonging to NEMO3 sends a packet to a		Consider the case where a LFN belonging to Mobile Network3 sends a
	CN in the Internet, and the CN replies back.		packet to a CN in the Internet, and the CN replies back. With the
			tunnel within tunnel approach described by [3], we would have three
	With the tunnel within tunnel approach described by [3], we would		bi-directional nested tunnels:
	have three bi-directional nested tunnels:
	-----------.		-----------.
	--------/ /-----------.		--------/ /-----------.
	-------/ | | /-----------		-------/ | | /-----------
	CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN		CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN
	MR3_HA -------\ | | \----------- MR3		MR3_HA -------\ | | \----------- MR3
	MR2_HA --------\ \----------- MR2		MR2_HA --------\ \----------- MR2
	MR1_HA ----------- MR1		MR1_HA ----------- MR1
	Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this		Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this
	may lead to a very inefficient "pinball" routing.		may lead to a very inefficient "pinball" routing in the
			Infrastructure.
	On the other hand, with the RRH approach we would have only one bi-		On the other hand, with the RRH approach we would have only one bi-
	directional tunnel:		directional tunnel:
	--------------------------------- MR1 ---- MR2 ----		--------------------------------- MR1 ---- MR2 ---- MR3
	CN ------( - - - - - - - - - - - - - - - - (-------- LFN		CN ------( - - - - - - - - - - - - - - - - (-------- LFN
	MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3		MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3
	The first mobile router on the path, MR3, in addition to tunneling		The first mobile router on the path, MR3, in addition to tunneling
	the packet to its HA, adds a reverse routing header with N = 3 pre-		the packet to its HA, adds a reverse routing header with N = 3 pre-
	allocated slots. Choosing the right value for N is discussed in		allocated slots. Choosing the right value for N is discussed in
	Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address		Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address
	option. MR3 inserts its home address MR3_HAddr into slot 0.		option. MR3 inserts its home address MR3_HAddr into slot 0.
	The outer packet has source MR3's CareOf Address (CoA), MR3_CoA and		The outer packet has source MR3's CareOf Address (CoA), MR3_CoA and
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 17 ¶
	the RRH is MR2_CoA | MR3_CoA | MR3_HAddr:		the RRH is MR2_CoA | MR3_CoA | MR3_HAddr:
	<-------------- outer IPv6 header -------------------->		<-------------- outer IPv6 header -------------------->
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |		|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
	|MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET		|MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET
	| | |: :| 4 | | | | |		| | |: :| 4 | | | | |
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	In a colloquial way we may say that while the packet travels from MR3		In a colloquial way we may say that while the packet travels from MR3
	to MR3_HA, the NEMO tunnel end point "telescopes" from MR3 to MR2 to		to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3
	MR1.		to MR2 to MR1.
	When the home agent MR3_HA receives the packet it notices that it		When the home agent MR3_HA receives the packet it notices that it
	contains a RRH and it looks at the bottom entry, MR3_HAddr. This		contains a RRH and it looks at the bottom entry, MR3_HAddr. This
	entry is used as if it were a MIPv6 Home Address destination option,		entry is used as if it were a MIPv6 Home Address destination option,
	i.e. as an index into the Binding Cache. When decapsulating the		i.e. as an index into the Binding Cache. When decapsulating the
	inner packet the home agent performs the checks described in Section		inner packet the home agent performs the checks described in Section
	8, and if successful it forwards the inner packet to CN.		8, and if successful it forwards the inner packet to CN.
	MR3_HA stores two items in the Bind Cache Entry associated with MR3:		MR3_HA stores two items in the Bind Cache Entry associated with MR3:
	the address entries from RRH, to be used to build the RH, and the		the address entries from RRH, to be used to build the RH, and the
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 9 ¶
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	|oSRC |oDST |: :|oRH | | | | |		|oSRC |oDST |: :|oRH | | | | |
	|MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET		|MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET
	| | |: :| 2 | | | | |		| | |: :| 2 | | | | |
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	The packet is routed with plain IP routing up to the first		The packet is routed with plain IP routing up to the first
	destination MR1_CoA.		destination MR1_CoA.
	The RH of the outer packet is type 2 as in [1], but has additional		The RH of the outer packet is type 2 as in [1], but has additional
	semantics inherited from type 0: it contains the path information to		semantics inherited from type 0: it contains the path information to
	traverse the nested NEMO from the TLMR to the tunnel endpoint MR.		traverse the nested Mobile Network from the TLMR to the tunnel
	Each intermediate destination forwards the packet to the following		endpoint MR. Each intermediate destination forwards the packet to
	destination in the routing header. The security aspects of this are		the following destination in the routing header. The security
	treated in Section 11.2.		aspects of this are treated in Section 11.2.
	MR1, which is the initial destination in the IP header, looks at the		MR1, which is the initial destination in the IP header, looks at the
	RH and processes it according to Section 9, updating the RH and the		RH and processes it according to Section 9, updating the RH and the
	destination and sending it to MR2_CoA. MR2 does the same and so on		destination and sending it to MR2_CoA. MR2 does the same and so on
	until the packet reaches the tunnel endpoint, MR3.		until the packet reaches the tunnel endpoint, MR3.
	When the packet reaches MR3, the source address in the IP header is		When the packet reaches MR3, the source address in the IP header is
	MR3_HA, the destination is MR3_CoA and in the RH there is one segment		MR3_HA, the destination is MR3_CoA and in the RH there is one segment
	left, MR3_HAddr. As a consequence the packet belongs to the MR3_HA -		left, MR3_HAddr. As a consequence the packet belongs to the MR3_HA -
	- MR3 tunnel. MR3 decapsulates the inner packet, applying the rules		- MR3 tunnel. MR3 decapsulates the inner packet, applying the rules
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 21 ¶
	8-bit unsigned integer. Number of slots used. Initially set to 1		8-bit unsigned integer. Number of slots used. Initially set to 1
	by the MR when only the Home Address is there. Incremented by the		by the MR when only the Home Address is there. Incremented by the
	MRs on the way as they add the packets source addresses to the		MRs on the way as they add the packets source addresses to the
	RRH.		RRH.
	Sequence Number		Sequence Number
	32-bit unsigned integer. The Sequence Number starts at 0, and is		32-bit unsigned integer. The Sequence Number starts at 0, and is
	incremented by the source upon each individual packet. Using the		incremented by the source upon each individual packet. Using the
	lollipop algorithm, the high order byte is never reset to zero but		Radia Perlman's lollipop algorithm, values between 0 and 255 are
	passes from 255 to 1.		'negative', left to indicate a reboot or the loss of HA
			connectivity, and are skipped when wrapping and upon positive
	The sequence number is used to check the freshness of the RRH;		Binding Ack. The sequence number is used to check the freshness
	anti-replay protection is left to IPsec AH.		of the RRH; anti-replay protection is left to IPsec AH.
	Slot[n-1..0]		Slot[n-1..0]
	Vector of 128-bit addresses, numbered n-1 to 0.		Vector of 128-bit addresses, numbered n-1 to 0.
	When applied to the NEMO problem, the RRH can be used to update the		When applied to the Nemo problem, the RRH can be used to update the
	HA on the actual location of the MR. Only MRs forwarding packets on		HA on the actual location of the MR. Only MRs forwarding packets on
	an egress interface while not at home update it on the fly.		an egress interface while not at home update it on the fly.
	A RRH is inserted by the first MR on the Nemo outbound path, as part		A RRH is inserted by the first MR on the Mobile Network outbound
	of the reverse tunnel encapsulation; it is removed by the associated		path, as part of the reverse tunnel encapsulation; it is removed by
	HA when the tunneled packet is decapsulated. The RRH contains n pre-		the associated HA when the tunneled packet is decapsulated. The RRH
	allocated address slots, to be filled by each MR in the path.		contains n pre-allocated address slots, to be filled by each MR in
			the path.
	4.3 Extension Header order		4.3 Extension Header order
	The RH type 2 is to be placed as any RH as described in [10] section		The RH type 2 is to be placed as any RH as described in [10] section
	4.1. If a RH type 0 is present in the packet, then the RH type 2 is		4.1. If a RH type 0 is present in the packet, then the RH type 2 is
	placed immediately after the RH type 0, and the RH type 0 MUST be		placed immediately after the RH type 0, and the RH type 0 MUST be
	consumed before the RH type 2.		consumed before the RH type 2.
	RH type 3 and 4 are mutually exclusive. They are to be placed right		RH type 3 and 4 are mutually exclusive. They are to be placed right
	after the Hop-by-Hop Options header if any, or else right after the		after the Hop-by-Hop Options header if any, or else right after the
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 32 ¶
	Encapsulating Security Payload header (note 2)		Encapsulating Security Payload header (note 2)
	Destination Options header (note 3)		Destination Options header (note 3)
	upper-layer header		upper-layer header
	5. ICMP		5. ICMP
	The RRH could have fewer slots than the number of MRs in the path		The RRH could have fewer slots than the number of MRs in the path
	because either the nested NEMO topology is changing too quickly or		because either the nested Mobile Network topology is changing too
	the MR that inserted the RRH could have a wrong representation of the		quickly or the MR that inserted the RRH could have a wrong
	topology.		representation of the topology.
	To solve this problem a new ICMP message is introduced, "RRH		To solve this problem a new ICMP message is introduced, "RRH
	Warning", type 64. Note that this ICMP message creates a new class		Warning", type 64. Note that this ICMP message creates a new class
	of warning messages besides the error messages and the control		of warning messages besides the error messages and the control
	messages of ICMP.		messages of ICMP.
	This message allows a MR on the path to propose a larger number of		This message allows a MR on the path to propose a larger number of
	slots to the MR that creates the RRH. The Proposed Size MUST be		slots to the MR that creates the RRH. The Proposed Size MUST be
	larger than the current size and MUST NOT be larger than 8.		larger than the current size and MUST NOT be larger than 8.
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶
	6. Modifications to IPv6 Neighbor Discovery		6. Modifications to IPv6 Neighbor Discovery
	6.1 Modified Router Advertisement Message Format		6.1 Modified Router Advertisement Message Format
	Mobile IPv6 [1] modifies the format of the Router Advertisement		Mobile IPv6 [1] modifies the format of the Router Advertisement
	message [11] by the addition of a single flag bit (H) to indicate		message [11] by the addition of a single flag bit (H) to indicate
	that the router sending the Advertisement message is serving as a		that the router sending the Advertisement message is serving as a
	home agent on this link.		home agent on this link.
	This draft adds another single flag bit (R) to indicate that the		This draft adds another single flag bit (N) to indicate that the
	router sending the advertisement message is a MR. This means that		router sending the advertisement message is a MR. This means that
	the link on which the message is sent is a NEMO, which may or may not		the link on which the message is sent is a Mobile Network, which may
	be at home.		or may not be at home.
	The Router Advertisement message has the following format:		The Router Advertisement message has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |		| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 49 ¶		skipping to change at page 16, line 49 ¶
	The Home Agent (H) bit is set in a Router Advertisement to		The Home Agent (H) bit is set in a Router Advertisement to
	indicate that the router sending this Router Advertisement is also		indicate that the router sending this Router Advertisement is also
	functioning as a Mobile IP home agent on this link.		functioning as a Mobile IP home agent on this link.
	NEMO Capable (N)		NEMO Capable (N)
	The NEMO Capable (N) bit is set in a Router Advertisement to		The NEMO Capable (N) bit is set in a Router Advertisement to
	indicate that the router sending this Router Advertisement is also		indicate that the router sending this Router Advertisement is also
	functioning as a Mobile Router on this link, so that the link is a		functioning as a Mobile Router on this link, so that the link is a
	NEMO, possibly away from home.		Mobile Network, possibly away from home.
	Reserved
	Reduced from a 6-bit field to a 4-bit field to account for the
	addition of the Home Agent (H) and the Nemo Capable (N) bits.
	6.2 New Tree Information Option Format		6.2 New Tree Information Option Format
	This draft defines a new Tree Information option, used in Router		This draft defines a new Tree Information Option, used in Router
	Advertisement messages.		Advertisement messages. Fields set by the TLMR are propagated
			transparently by the MRs.
	The Tree Information option has the following format:		The Tree Information option has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length = 5 | Preference | TreeDepth |		| Type | Length = 5 | Tree_Prefer. | TreeDepth |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|F|H| Reserved | DelayTime |		|F|H| Reserved | Bandwidth | DelayTime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MRPreference | BootTimeRandom |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PathCRC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Tree TLMR Identifier +		+ Tree TLMR Identifier +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Tree Group +		+ Tree Group +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	Set to 7.		8-bit unsigned integer set to 7 by the TLMR.
	Length		Length
	8-bit unsigned integer. The length of the option (including the		8-bit unsigned integer set to 6 by the TLMR. The length of the
	type and length fields) in units of 8 octets. The value of this		option (including the type and length fields) in units of 8
	field MUST be 5.		octets.
	Preference
	8-bit signed integer. The preference of a tree as configured on		Tree_Preference
	its TLMR. Range from 0 = lowest to 255 = maximum.		8-bit unsigned integer set by the TLMR to its configured
			preference. Range from 0 = lowest to 255 = maximum.
	TreeDepth		TreeDepth
	8-bit signed integer. Set to 0 by the TLMR and incremented by 1		8-bit unsigned integer set to 0 by the TLMR and incremented by 1
	by each MR down the tree.		by each MR down the tree.
	Fixed (F)		Fixed (F)
	1-bit flag. Set to indicate that the TLMR is either attached to a		1-bit flag. Set by the TLMR to indicate that it is either
	fixed network or at home. This field is set by the TLMR and left		attached to a fixed network or at home.
	unchanged by the other MRs.
	Home (H)		Home (H)
	1-bit flag. Set to indicate that the TLMR is also functioning as		1-bit flag. Set by the TLMR to indicate that it is also
	a HA, for re-homing purposes. Set by the TLMR and left unchanged		functioning as a HA, for re-homing purposes.
	by the other MRs.
	Reserved		Reserved
	14-bit reserved field. Initialized to zero for transmission;		6-bit unsigned integer, set to 0 by the TLMR.
	ignored on reception.
			Bandwidth
			8-bit unsigned integer set by the TLMR and decremented by MRs with
			lower egress bandwidth. This is a power of 2 so that the
			available egress bandwidth in bps is between 2^Bandwidth and
			2^(Bandwidth+1). 0 means 'unspecified' and can not be modified
			down the tree.
	DelayTime		DelayTime
	Tree-wide time constant in milliseconds, set by the TLMR and left		16-bit unsigned integer set by the TLMR. Tree time constant in
	unchanged by other MRs.		milliseconds.
			MRPreference
			8-bit signed integer. Set by each MR to its configured
			preference. Range from 0 = lowest to 255 = maximum.
			BootTimeRandom
			24-bit unsigned integer set by each MR to a random value that the
			MR generates at boot time.
			PathCRC
			Updated by each MR. This is the result of a CRC-32 computation on
			a bit string obtained by appending the received value and the MR
			CareOf Address. TLMRs use a 'previous value' of zeroes to
			initially set the pathCRC.
	Tree TLMR Identifier		Tree TLMR Identifier
	Set by the TLMR and left unchanged by other MRs. Identifier of		IPv6 global address, set by the TLMR. Identifier of the tree.
	the tree. It is a unique IPv6 address.
	Tree Group		Tree Group
	Group Identifier. Set by the TLMR and left unchanged by other		IPv6 global address, set by the TLMR. Identifier of the tree
	MRs. A MR may use the Tree Group in its tree selection algorithm.		group. A MR may use the Tree Group in its tree selection
			algorithm.
	The TLMR MUST include this option in its Router Advertisements.		The TLMR MUST include this option in its Router Advertisements.
	A MR receiving this option from its Access Router MUST update the		A MR receiving this option from its Attachment Router MUST update the
	TreeDepth field and MUST forward it on its ingress interface(s), as		TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST
	described in Section 9.4.		propagate it on its ingress interface(s), as described in Section
			9.4.
	The alignment requirement of the Tree Information Option is 8n.		The alignment requirement of the Tree Information Option is 8n.
	7. Binding Cache Management		7. Binding Cache Management
	7.1 Binding Updates		7.1 Binding Updates
	Binding Updates are still used as described in MIPv6 [1] for Home		Binding Updates are still used as described in MIPv6 [1] for Home
	Registration and de-registration, but only when the MR registers for		Registration and de-registration, but only when the MR registers for
	the first time with its HA.		the first time with its HA.
	Since the BU doesn't contain the full NEMO path to the MR, it cannot		Since the BU doesn't contain the full NEMO path to the MR, it cannot
	be used in this design of nested NEMOs.		be used in this design of nested Mobile Networks.
	7.2 RRH Heartbeat		7.2 RRH Heartbeat
	Subsequent updates (or just refreshes) to the CoA binding are		Subsequent updates (or just refreshes) to the CoA binding are
	obtained as one of the results of processing the RRH by the HA.		obtained as one of the results of processing the RRH by the HA.
	When the MR becomes aware of a topology change in the tree (for		When the MR becomes aware of a topology change in the tree (for
	examples it changes point of attachment, it obtains a new CoA, it		examples it changes point of attachment, it obtains a new CoA, it
	receives a Tree Information message) or in the absence of traffic		receives a Tree Information message) or in the absence of traffic
	(detected by a timeout) to the HA, it must send an RRH Heartbeat (IP		(detected by a timeout) to the HA, it must send an RRH Heartbeat (IP
	skipping to change at page 20, line 16 ¶		skipping to change at page 20, line 40 ¶
	presence of a Routing Header of type 3 or 4. Both contain as least		presence of a Routing Header of type 3 or 4. Both contain as least
	the entry for the home address of the MN in slot 0; this replaces the		the entry for the home address of the MN in slot 0; this replaces the
	MIP Home Address Option and allows the HA to determine the actual		MIP Home Address Option and allows the HA to determine the actual
	source of the packet, to access the corresponding security		source of the packet, to access the corresponding security
	association.		association.
	As explained in Section 11.2, the HA MUST verify the authenticity of		As explained in Section 11.2, the HA MUST verify the authenticity of
	the packet using IPSEC AH and drop packets that were not issued by		the packet using IPSEC AH and drop packets that were not issued by
	the proper Mobile Node. An RRH is considered only if the packet is		the proper Mobile Node. An RRH is considered only if the packet is
	authenticated and if its sequence number is higher than the one saved		authenticated and if its sequence number is higher than the one saved
	in the BCE. Also, an RRH is considered only if an initial Bind		in the BCE.
	Update exchange has been successfully completed between the Mobile
	Node and its Home Agent for Home Registration. If the RRH is valid,		Also, an RRH is considered only if an initial Bind Update exchange
	then the Bind Cache Entry is revalidated for a lifetime as configured		has been successfully completed between the Mobile Node and its Home
	from the initial Bind Update.		Agent for Home Registration. If the RRH is valid, then the Bind
			Cache Entry is revalidated for a lifetime as configured from the
			initial Bind Update.
	The BCE abstract data is updated as follows:		The BCE abstract data is updated as follows:
	The first hop for the return path is the last hop on the path of		The first hop for the return path is the last hop on the path of
	the incoming packet, that is between the HA and the Top Level		the incoming packet, that is between the HA and the Top Level
	Mobile Router (TLMR) of the Mobile Network. The HA saves the IP		Mobile Router (TLMR) of the Mobile Network. The HA saves the IP
	address of the TLMR from the source field in the IP header.		address of the TLMR from the source field in the IP header.
	The rest of the path to the MN is found in the RRH.		The rest of the path to the MN is found in the RRH.
	skipping to change at page 25, line 4 ¶		skipping to change at page 25, line 4 ¶
	decrement Segments Left by 1;		decrement Segments Left by 1;
	compute i, the index of the next address to be visited in		compute i, the index of the next address to be visited in
	the address vector, by subtracting Segments Left from n		the address vector, by subtracting Segments Left from n
	if Address [i] or the IPv6 Destination Address is multicast {		if Address [i] or the IPv6 Destination Address is multicast {
	discard the packet		discard the packet
	}		}
	else {		else {
	/* new security check */		/* new security check */
	if Address [i] doesn't belong to one of the NEMO prefixes {		if Address [i] doesn't belong to one of the Mobile Network prefixes {
	discard the packet		discard the packet
	return		return
	}		}
	/* new check: keep MIPv6 behavior: prevent packets from being		/* new check: keep MIPv6 behavior: prevent packets from being
	* forwarded outside the node.		* forwarded outside the node.
	*/		*/
	if Segments Left equals 0 and Address[i] isn't the node's own		if Segments Left equals 0 and Address[i] isn't the node's own
	home address {		home address {
	discard the packet		discard the packet
	skipping to change at page 25, line 42 ¶		skipping to change at page 25, line 42 ¶
	}		}
	9.6 Decapsulation		9.6 Decapsulation
	A MR when decapsulating a packet from its HA must perform the		A MR when decapsulating a packet from its HA must perform the
	following checks		following checks
	1. Destination address		1. Destination address
	The destination address of the inner packet must belong to one of		The destination address of the inner packet must belong to one of
	the NEMO prefixes.		the Mobile Network prefixes.
	10. Mobile Host Operation		10. Mobile Host Operation
	When it is at Home, a Mobile Host issues packets with source set to		When it is at Home, a Mobile Host issues packets with source set to
	its home address and with destination set to its CN, in a plain IPv6		its home address and with destination set to its CN, in a plain IPv6
	format.		format.
	When a MH is not at home but is attached to a foreign link in the		When a MH is not at home but is attached to a foreign link in the
	Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to		Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to
	manage its mobility.		manage its mobility.
	skipping to change at page 26, line 31 ¶		skipping to change at page 26, line 31 ¶
	the CN.		the CN.
	11. Security Considerations		11. Security Considerations
	This section is not complete; further work is needed to analyse and		This section is not complete; further work is needed to analyse and
	solve the security problems of record and source route.		solve the security problems of record and source route.
	Compared to MIPv6, the main security problem seems to be the fact		Compared to MIPv6, the main security problem seems to be the fact
	that the RRH can be modified in transit by an in-axis attacker. It		that the RRH can be modified in transit by an in-axis attacker. It
	has to be noted that an in-axis attacker (for example any MR in the		has to be noted that an in-axis attacker (for example any MR in the
	NEMO) can perform more effective attacks than modifying the RRH.		Mobile Network) can perform more effective attacks than modifying the
			RRH.
	Selecting the tree to attach to is a security critical operation		Selecting the tree to attach to is a security critical operation
	outside of the scope of this draft.		outside of the scope of this draft.
	11.1 IPsec Processing		11.1 IPsec Processing
	The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to		The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to
	provide different security services to the tunnel between a MR and		provide different security services to the tunnel between a MR and
	its HA. ESP tunnel mode SHOULD be used to provide confidentiality		its HA. ESP tunnel mode SHOULD be used to provide confidentiality
	and authentication to the inner packet. AH tunnel mode MUST be used		and authentication to the inner packet. AH tunnel mode MUST be used
	skipping to change at page 27, line 36 ¶		skipping to change at page 27, line 37 ¶
	AH authenticates the MR Home Address identity and the RRH sequence		AH authenticates the MR Home Address identity and the RRH sequence
	number. The RRH sequence number is to be used to check the freshness		number. The RRH sequence number is to be used to check the freshness
	of the RRH; anti-replay protection can be obtained if the receiver		of the RRH; anti-replay protection can be obtained if the receiver
	enables the anti-replay service of AH [8].		enables the anti-replay service of AH [8].
	As a consequence, the only kind of successful attack seems to require		As a consequence, the only kind of successful attack seems to require
	to be able to modify the packet in flight.		to be able to modify the packet in flight.
	If one of the RRH entry is faked either to an address outside the		If one of the RRH entry is faked either to an address outside the
	tree or to an address that doesn't match the tree topology (not		tree or to an address that doesn't match the tree topology (not
	belonging to one of the NEMO prefixes at that level) then the reply		belonging to one of the Mobile Network prefixes at that level) then
	packet containing a RH type 2 built out of the previous RRH will be		the reply packet containing a RH type 2 built out of the previous RRH
	dropped by the first MR that processes that entry, as described in		will be dropped by the first MR that processes that entry, as
	Section 9.		described in Section 9.
	It is still an issue how to validate that the source of the outer		It is still an issue how to validate that the source of the outer
	packet is the actual TLMR as opposed to a forged IP address put by an		packet is the actual TLMR as opposed to a forged IP address put by an
	on-axis attacker outside the NEMO.		on-axis attacker outside the Mobile Network.
	12. Acknowledgements		12. Acknowledgements
	The authors wish to thank Steve Deering, Fred Baker, Thomas Fossati,		The authors wish to thank David Auerbach, Fred Baker, Dana Blair,
	Dave Auerbach, Kent Leung, Francois Le Faucheur, Dana Blair, Dan		Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,
	Shell, Dave Forster and Massimo Lucchina for their constructive		Kent Leung, Massimo Lucchina, Dan Shell and Patrick Wetterwald -last
	comments on the ideas that sustain this document.		but not least :)-.
	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-17 (work in progress), May		IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July
	2002.		2002.
	[2] Ernst, T., "Network Mobility Support Terminology", draft-ernst-		[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	monet-terminology-00 (work in progress), February 2002.		draft-ernst-monet-terminology-01 (work in progress), July 2002.
	[3] Kniveton, T., "Mobile Router Support with Mobile IP", draft-		[3] Kniveton, T., "Mobile Router Support with Mobile IP", draft-
	kniveton-mobrtr-01 (work in progress), March 2002.		kniveton-mobrtr-02 (work in progress), July 2002.
	[4] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A.		[4] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A.
	Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix		Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix
	Scope Binding Updates)", draft-ernst-mobileip-v6-network-03		Scope Binding Updates)", draft-ernst-mobileip-v6-network-03
	(work in progress), March 2002.		(work in progress), March 2002.
	[5] Deering, S. and B. Zill, "Redundant Address Deletion when		[5] 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.
	skipping to change at page 29, line 30 ¶		skipping to change at page 29, line 30 ¶
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	EMail: mmolteni@cisco.com		EMail: mmolteni@cisco.com
	Appendix A. Optimizations		Appendix A. Optimizations
	A.1 Prefix Scope Binding Updates		A.1 Prefix Scope Binding Updates
	[4] suggests modifications to MIPv6 to enable support for LFNs in		[4] suggests modifications to MIPv6 to enable support for LFNs in
	non-nested NEMOs, leaving for later investigation more complex		non-nested Mobile Networks, leaving for later investigation more
	scenarios like MNs behind the MR or nested NEMOs.		complex scenarios like MNs behind the MR or nested Mobile Networks.
	The solution described there has bi-directional route optimization as		The solution described there has bi-directional route optimization as
	in MIPv6: the CN to MR direction uses the RH type 2, while the MR to		in MIPv6: the CN to MR direction uses the RH type 2, while the MR to
	CN direction uses the home address destination option. Route		CN direction uses the home address destination option. Route
	optimization is obtained by introducing a new kind of binding update,		optimization is obtained by introducing a new kind of binding update,
	the Prefix Scope BU (PSBU) and by modifying the CN and MR operations		the Prefix Scope BU (PSBU) and by modifying the CN and MR operations
	in order to exploit it.		in order to exploit it.
	The MR has to keep track of all the pending communications between		The MR has to keep track of all the pending communications between
	hosts in his NEMO and their CNs, in order to send to the CNs a PSBU		hosts in his Mobile Network and their CNs, in order to send to the
	each time the MR changes its point of attachment.		CNs a PSBU each time the MR changes its point of attachment.
	If we extend [4] in such a way that each MR in a nested NEMO sends a		If we extend [4] in such a way that each MR in a nested Mobile
	full set of PSBUs each time it changes its point of attachment, then		Network sends a full set of PSBUs each time it changes its point of
	each CN by receiving all the PSBUs and processing them can infer a		attachment, then each CN by receiving all the PSBUs and processing
	partial topology of the nested NEMO, sufficient to build a multi-hop		them can infer a partial topology of the nested Mobile Network,
	routing header for packets sent to nodes inside the nested NEMO.		sufficient to build a multi-hop routing header for packets sent to
			nodes inside the nested Mobile Network.
	However, this extension seems to come at a too high price:		However, this extension seems to come at a too high price:
	1. PSBU storm		1. PSBU storm
	when one MR changes its point of attachment, it needs to send a		when one MR changes its point of attachment, it needs to send a
	PSBU to all the CNs of each node behind him. When the NEMO is		PSBU to all the CNs of each node behind him. When the Mobile
	nested, the number of nodes and relative CNs can be huge. In		Network is nested, the number of nodes and relative CNs can be
	order to send the PSBUs, the MR has to keep track of all the		huge. In order to send the PSBUs, the MR has to keep track of
	traffic it forwards to maintain his list of CNs.		all the traffic it forwards to maintain his list of CNs.
	2. CN operation		2. CN operation
	The computation burden of the CN becomes heavy, because it has to		The computation burden of the CN becomes heavy, because it has to
	analyze each PSBU in a recursive fashion in order to deduct		analyze each PSBU in a recursive fashion in order to deduct
	nested NEMO topology required to build a multi hop routing		nested Mobile Network topology required to build a multi hop
	header.		routing header.
	3. Missing PSBU		3. Missing PSBU
	If a CN doesn't receive the full set of PSBU sent by the MR, it		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		will not be able to infer the full path to a node inside the
	nested NEMO. The RH will be incomplete and the packet may or may		nested Mobile Network. The RH will be incomplete and the packet
	not be delivered. If PSBU are sent asynchronously by each MR,		may or may not be delivered. If PSBU are sent asynchronously by
	then, when the relative position of MRs and/or the TLMR point of		each MR, then, when the relative position of MRs and/or the TLMR
	attachment change rapidly, the image of Mobile Network that the		point of attachment change rapidly, the image of Mobile Network
	CN maintains is highly unstable.		that the CN maintains is highly unstable.
	A conclusion is that the path information must be somehow aggregated		A conclusion is that the path information must be somehow aggregated
	to provide the CN with consistent snapshots of the full path across		to provide the CN with consistent snapshots of the full path across
	the Mobile Network. If this is achieved by a series of stacked Home		the Mobile Network. If this is achieved by a series of stacked Home
	Address Options, then the problem turns into a format war and about		Address Options, then the problem turns into a format war and about
	the opportunity to insert headers in a packet as opposed to		the opportunity to insert headers in a packet as opposed to
	tunneling. Either way is a route record, which is why defining a		tunneling. Either way is a route record, which is why defining a
	real V6 version of LSRR is relevant in the first place.		real V6 version of LSRR is relevant in the first place.
	A.2 Path Optimization with RRH		A.2 Path Optimization with RRH
	The body of the draft presents RRH as a header that circulates in the		The body of the draft presents RRH as a header that circulates in the
	reverse tunnel exclusively. The RRH format by itself has no such		reverse tunnel exclusively. The RRH format by itself has no such
	limitation. This section illustrates a potential optimization for		limitation. This section illustrates a potential optimization for
	end-to-end traffic between a Mobile Network Node and its		end-to-end traffic between a Mobile Network Node and its
	Correspondent Node.		Correspondent Node.
	The MNN determines that it is part of a Nemo by screening the Tree		The MNN determines that it is part of a Mobile Network by screening
	Information option in the RA messages from its Access Router. In		the Tree Information option in the RA messages from its Attachment
	particular, the MNN knows the TreeDepth as advertised by the AR. An		Router. In particular, the MNN knows the TreeDepth as advertised by
	initial test phase could be derived from MIPv6 to decide whether		the AR. An initial test phase could be derived from MIPv6 to decide
	optimization with a given CN is possible.		whether optimization with a given CN is possible.
	When an MNN performs end-to-end optimization with a CN, the MNN		When an MNN performs end-to-end optimization with a CN, the MNN
	inserts an empty RRH inside its packets, as opposed to tunneling them		inserts an empty RRH inside its packets, as opposed to tunneling them
	home, which is the default behavior of a Mobile Host as described in		home, which is the default behavior of a Mobile Host as described in
	Section 10. The number of slots in the RRH is initially the AR		Section 10. The number of slots in the RRH is initially the AR
	treeDepth plus 1, but all slots are clear as opposed to the MR		treeDepth plus 1, but all slots are clear as opposed to the MR
	process as described in Section 9. The source address in the header		process as described in Section 9. The source address in the header
	is the MNN address, and the destination is the CN.		is the MNN address, and the destination is the CN.
	The AR of the MNN is by definition an MR. Since an RRH is already		The AR of the MNN is by definition an MR. Since an RRH is already
	skipping to change at page 34, line 38 ¶		skipping to change at page 34, line 38 ¶
	===?== ==?===		===?== ==?===
	MR1 MR2		MR1 MR2
	| |		| |
	==?=====?=======?====== situation B		==?=====?=======?====== situation B
	MR3 MR4 MR5		MR3 MR4 MR5
	| | |		| | |
	=== === ===		=== === ===
	Going from A to B, MR5 may now choose between MR1 and MR2 for its		Going from A to B, MR5 may now choose between MR1 and MR2 for its
	Access (default) Router. In terms of Tree Information, MR5, as well		Attachment (default) Router. In terms of Tree Information, MR5, as
	as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once MR5		well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once
	selects its AR, MR2, say, MR5 belongs to the associated tree and		MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and
	whether MR1 can be reached or not makes no difference.		whether MR1 can be reached or not makes no difference.
	As long as each MR has a single default router for all its outbound		As long as each MR has a single default router for all its outbound
	traffic, 2 different logical trees can be mapped over the physical		traffic, 2 different logical trees can be mapped over the physical
	configurations in both situations, and once the trees are		configurations in both situations, and once the trees are
	established, both cases are equivalent for the processing of RRH.		established, both cases are equivalent for the processing of RRH.
	Note that MR5 MUST use a CareOf based on a prefix owned by its AR as		Note that MR5 MUST use a CareOf based on a prefix owned by its AR as
	source of the reverse tunnel, even if other prefixes are present on		source of the reverse tunnel, even if other prefixes are present on
	the Nemo, to ensure that a RH type 2 can be securely routed back.		the Mobile Network, to ensure that a RH type 2 can be securely routed
			back.
	B.2 Multihomed Mobile Router		B.2 Multihomed Mobile Router
	Consider the difference between situation B and C in this diagram:		Consider the difference between situation B and C in this diagram:
	===?== ==?===		===?== ==?===
	MR1 MR2		MR1 MR2
	| |		| |
	==?=====?=======?====== situation B		==?=====?=======?====== situation B
	MR3 MR4 MR5		MR3 MR4 MR5
	skipping to change at page 35, line 34 ¶		skipping to change at page 35, line 35 ¶
	==?=====?=======?====== situation C		==?=====?=======?====== situation C
	MR3 MR4 MR5		MR3 MR4 MR5
	| | |		| | |
	=== === ===		=== === ===
	In situation C, MR2's egress interface and its properties are		In situation C, MR2's egress interface and its properties are
	migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home		migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home
	Agents, and 2 active interfaces.		Agents, and 2 active interfaces.
	If MR1 uses both CareOf addresses at a given point of time, and if		If MR1 uses both CareOf addresses at a given point of time, and if
	they belong to different prefixes to be used via different access		they belong to different prefixes to be used via different attachment
	routers, then MR1 actually belongs to 2 trees. It must perform some		routers, then MR1 actually belongs to 2 trees. It must perform some
	routing logic to decide whether to forward packets on either egress		routing logic to decide whether to forward packets on either egress
	interface. Also, it MUST advertise both tree information sets in its		interface. Also, it MUST advertise both tree information sets in its
	RA messages.		RA messages.
	The difference between situations C and B is that when an attached		The difference between situations C and B is that when an attached
	router (MR5, say) selects a tree and forwards egress packets via MR1,		router (MR5, say) selects a tree and forwards egress packets via MR1,
	it can not be sure that MR1 will actually forward the packets over		it can not be sure that MR1 will actually forward the packets over
	that tree. If MR5 has selected a given tree for a specific reason,		that tree. If MR5 has selected a given tree for a specific reason,
	then a new source route header is needed to enforce that path on MR1.		then a new source route header is needed to enforce that path on MR1.
	The other way around, MR5 may leave the decision up to MR1. If MR1		The other way around, MR5 may leave the decision up to MR1. If MR1
	uses the same access router for a given flow or at least a given		uses the same attachment router for a given flow or at least a given
	destination, then the destination receives consistent RRHs.		destination, then the destination receives consistent RRHs.
	Otherwise, the BCE cache will flap, but as both paths are valid, the		Otherwise, the BCE cache will flap, but as both paths are valid, the
	traffic still makes it through.		traffic still makes it through.
	The RRH seems compatible with the various cases of multi-homing		The RRH seems compatible with the various cases of multi-homing
	exposed here, though in some cases, some additional work is needed.		exposed here, though in some cases, some additional work is needed.
			Appendix C. Changes from Previous Version of the Draft
			This appendix briefly lists some of the major changes in this draft
			relative to the previous version of this same draft, draft-thubert-
			nemo-reverse-routing-header-00.txt:
			Added new Tree Information Option fields:
			A 8 bits Bandwidth indication that provides an idea of the
			egress bandwidth.
			A CRC-32 that changes with the egress path out of the tree.
			a 32 bits unsigned integer, built by each MR out of a high
			order configured preference and 24 bits random constant. This
			can help as a tie break in Attachment Router selection.
			Reduced the 'negative' part of the lollipop space to 0..255
			Fixed acknowledgements (sorry Patrick :)
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). 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
End of changes. 76 change blocks.
	166 lines changed or deleted		218 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/