< draft-thubert-nemo-reverse-routing-header-05.txt		draft-thubert-nemo-reverse-routing-header-06.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: November 30, 2004 Cisco Systems		Expires: April 1, 2007 Cisco Systems
	June 2004		September 28, 2006
	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-05		draft-thubert-nemo-reverse-routing-header-06
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 30, 2004.		This Internet-Draft will expire on April 1, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	NEMO basic support enables Mobile Networks by extending Mobile IP to		NEMO basic support enables Mobile Networks by extending Mobile IP to
	Mobile Routers. In the case of nested Mobile Networks, this involves		Mobile Routers. In the case of nested Mobile Networks, this involves
	the overhead of nested tunnels between the Mobile Routers and their		the overhead of nested tunnels between the Mobile Routers and their
	Home Agents, and causes a number of security issues.		Home Agents, and causes a number of security issues.
	This proposal alleviates those problems as well as other minor ones,		This proposal alleviates those problems as well as other minor ones,
	by using a source routing within the mobile nested structure,		by using a source routing within the mobile nested structure,
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3		1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5		2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5
	2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6		2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
	3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 11		4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 11
	4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11		4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11
	4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13		4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13
	4.3 Extension Header order . . . . . . . . . . . . . . . . . . 15		4.3 Extension Header order . . . . . . . . . . . . . . . . . . 16
	5. Optimum number of slots in RRH . . . . . . . . . . . . . . . 17		5. Optimum number of slots in RRH . . . . . . . . . . . . . . . 18
	6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 19		6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 20
	6.1 Modified Router Advertisement Message Format . . . . . . . 19		6.1 Modified Router Advertisement Message Format . . . . . . . 20
	7. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . 20		7. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1 DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 20		7.1 DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.2 Binding Updates . . . . . . . . . . . . . . . . . . . . . 20		7.2 Binding Updates . . . . . . . . . . . . . . . . . . . . . 21
	8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 21		8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 22
	9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 23		9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 24
	9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 23		9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 24
	9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 24		9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 25
	9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 24		9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 25
	9.4 Processing of the extended Routing Header Type 2 . . . . . 25		9.4 Processing of the extended Routing Header Type 2 . . . . . 26
	9.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 27		9.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 28
	10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 27		10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 28
	11. Security Considerations . . . . . . . . . . . . . . . . . . 28		11. Security Considerations . . . . . . . . . . . . . . . . . . 29
	11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . 28		11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . 29
	11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . 28		11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . 29
	11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . 28		11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . 29
	11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . 30		11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . 31
	12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 31		12. IANA considerations . . . . . . . . . . . . . . . . . . . . 32
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		13. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 32
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 34		15.1 informative reference . . . . . . . . . . . . . . . . . 33
	A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 34		15.2 normative reference . . . . . . . . . . . . . . . . . . 33
	A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
			A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 35
			A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 35
			A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 36
	A.2.1 Routing Header Type 3 (Home Address option		A.2.1 Routing Header Type 3 (Home Address option
	replacement) . . . . . . . . . . . . . . . . . . . . . 36		replacement) . . . . . . . . . . . . . . . . . . . . . 37
	B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 38		B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 39
	B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 38		B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 39
	B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 39		B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 41
	C. Changes from Previous Version of the Draft . . . . . . . . . 40		C. Changes from Previous Version of the Draft . . . . . . . . . 42
	Intellectual Property and Copyright Statements . . . . . . . 42		Intellectual Property and Copyright Statements . . . . . . . 44
	1. Introduction		1. Introduction
	This document assumes that the reader is familiar with the Mobile		This document assumes that the reader is familiar with the Mobile
	Networks terminology defined in [9] and [11], with Mobile IPv6		Networks terminology defined in [17] and [4], with Mobile IPv6
	defined in [10], and with the NEMO basic support defined in [12].		defined in [18], and with the NEMO basic support defined in [19].
	Generally a Mobile Network may be either solid (a network with one		Generally a Mobile Network may be either solid (a network with one
	mobile router) or nested, single or multi-homed. This proposal		mobile router) or nested, single or multi-homed. This proposal
	starts from the assumption that nested Mobile Networks will be the		starts from the assumption that nested Mobile Networks will be the
	norm, and so presents a solution that avoids the tunnel within tunnel		norm, and so presents a solution that avoids the tunnel within tunnel
	overhead of already existing proposals.		overhead of already existing proposals.
	The solution is based on a single, telescopic tunnel between the		The solution is based on a single, telescopic 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 introduces a new Routing Header (RH), called the Reverse		The solution introduces a new Routing Header (RH), called the Reverse
	Routing Header (RRH), to perform source routing within the mobile		Routing Header (RRH), to perform source routing within the mobile
	structure. RRH is a variant of IPv4 Loose Source and Record Route		structure. RRH is a variant of IPv4 Loose Source and Record Route
	(LSRR) [1] adapted for IPv6. RRH records the route out of the nested		(LSRR) [9] adapted for IPv6. RRH records the route out of the nested
	Mobile Network and can be trivially converted into a routing header		Mobile Network and can be trivially converted into a routing header
	for packets destined to the Mobile Network.		for packets destined to the Mobile Network.
	This version focuses on single-homed Mobile Networks. Hints for		This version focuses on single-homed Mobile Networks. Hints for
	further 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 from Mobile IPv6 [10]. Specifically the CN can also		left unchanged from Mobile IPv6 [18]. Specifically the CN can also
	be a LFN.		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 Recursive complexity		1.1 Recursive complexity
	A number of drafts and publications suggest -or can be extended to- a		A number of drafts and publications suggest -or can be extended to- a
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	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. This can be achieved by an IPv6 form of loose		the Mobile Network. This can be achieved by an IPv6 form of loose
	source / record route header, that we introduce here as a Reverse		source / record route header, that we introduce here as a Reverse
	Routing Header		Routing Header
	2. Terminology and Assumptions		2. Terminology and Assumptions
	2.1 Terminology		2.1 Terminology
	This document assumes that the reader is familiar with Mobile IPv6 as		This document assumes that the reader is familiar with Mobile IPv6 as
	defined in [10] and with the concept of Mobile Router defined in the		defined in [18] and with the concept of Mobile Router defined in the
	NEMO terminology document [11]. In particular, the "Nested Mobility		NEMO terminology document [4]. In particular, the "Nested Mobility
	Terms" introduced in the NEMO terminology are repeatedly used in this		Terms" introduced in the NEMO terminology are repeatedly used in this
	document.		document.
	Solid Mobile Network:		Solid 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 Solid Mobile Network can		respect to the rest of the Internet. A Solid Mobile Network can
	be either singly or multi-homed. A Solid Mobile Network may be		be either singly or multi-homed. A Solid Mobile Network may be
	composed of more then one link and may interconnect several		composed of more then one link and may interconnect several
	routers, but all routers in the Solid Mobile Network are fixed		routers, but all routers in the Solid Mobile Network are fixed
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 39 ¶
	An example nested Mobile Network		An example nested Mobile Network
	This example focuses on a Mobile Network node at depth 3 (Mobile		This example focuses on a Mobile Network node at depth 3 (Mobile
	Network3) inside the tree, represented by its mobile router MR3. The		Network3) inside the tree, represented by its mobile router MR3. The
	path to the Top Level Mobile Router (TLMR) MR1 and then the Internet		path to the Top Level Mobile Router (TLMR) MR1 and then the Internet
	is		is
	MR3 -> MR2 -> MR1 -> Internet		MR3 -> MR2 -> MR1 -> Internet
	Consider the case where a LFN belonging to Mobile Network3 sends a		Consider the case where a LFN belonging to Mobile Network3 sends a
	packet to a CN in the Internet, and the CN replies back. With the		packet to a CN in the Internet, and the CN replies back. With the
	tunnel within tunnel approach described by [12], we would have three		tunnel within tunnel approach described by [19], we would have three
	bi-directional nested tunnels:		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 in the		may lead to a very inefficient "pinball" routing in the
	Infrastructure.		Infrastructure.
	On the other hand, with the RRH approach we would have only one		On the other hand, with the RRH approach we would have only one bi-
	bi-directional tunnel:		directional tunnel:
	--------------------------------- MR1 ---- MR2 ---- MR3		--------------------------- 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		the packet to its HA, adds a reverse routing header with N = 3 pre-
	pre-allocated slots. Choosing the right value for N is discussed in		allocated slots. Choosing the right value for N is discussed in
	Section 5. The bottom slot is equivalent to the MIPv6 Home Address		Section 5. The bottom slot is equivalent to the MIPv6 Home Address
	option. MR3 inserts its home address MR3_HoA into slot 0.		option. MR3 inserts its home address MR3_HoA into slot 0.
	The outer packet has source MR3's Care of Address, MR3_CoA, and		The outer packet has source MR3's Care of Address, MR3_CoA, and
	destination MR3's Home Agent, MR3_HA:		destination MR3's Home Agent, MR3_HA:
	<-------------- outer IPv6 header -------------------->		<-------------- outer IPv6 header -------------------->
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |		|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
	|MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET		|MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	<-------------- outer IPv6 header -------------------->		<-------------- outer IPv6 header -------------------->
	+-------+-------++ -- ++----+-------+-------+---------+ +-------		+-------+-------++ -- ++----+-------+-------+---------+ +-------
	|oSRC |oDST |: :|oRH | | | | |		|oSRC |oDST |: :|oRH | | | | |
	|MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET		|MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |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 MIPv6 [10], but has		The RH of the outer packet is type 2 as in MIPv6 [18], but has
	additional semantics inherited from type 0: it contains the path		additional semantics inherited from type 0: it contains the path
	information to traverse the nested Mobile Network from the TLMR to		information to traverse the nested Mobile Network from the TLMR to
	the tunnel endpoint MR3. Each intermediate destination forwards the		the tunnel endpoint MR3. Each intermediate destination forwards the
	packet to the following destination in the routing header. The		packet to the following destination in the routing header. The
	security aspects of this are treated in Section 11.2.		security 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.
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	This draft modifies the MIPv6 Routing Header type 2 and introduces		This draft modifies the MIPv6 Routing Header type 2 and introduces
	two new Routing Headers, type 3 and 4. Type 3, which is an		two new Routing Headers, type 3 and 4. Type 3, which is an
	optimization of type 4 will be discussed in Appendix A.2.1. The		optimization of type 4 will be discussed in Appendix A.2.1. The
	draft presents their operation in the context of Mobile Routers		draft presents their operation in the context of Mobile Routers
	although the formats are not tied to Mobile IP and could be used in		although the formats are not tied to Mobile IP and could be used in
	other situations.		other situations.
	4.1 Routing Header Type 2 (MIPv6 RH with extended semantics)		4.1 Routing Header Type 2 (MIPv6 RH with extended semantics)
	Mobile IPv6 uses a Routing header to carry the Home Address for		Mobile IPv6 uses a Routing header to carry the Home Address for
	packets sent from a Correspondent Node to a Mobile Node. In [10],		packets sent from a Correspondent Node to a Mobile Node. In [18],
	this Routing header (Type 2) is restricted to carry only one IPv6		this Routing header (Type 2) is restricted to carry only one IPv6
	address. The format proposed here extends the Routing Header type 2		address. The format proposed here extends the Routing Header type 2
	to be multi-hop.		to be multi-hop.
	The processing of the multi-hop RH type 2 inherits from the RH type 0		The processing of the multi-hop RH type 2 inherits from the RH type 0
	described in IPv6 [5]. Specifically: the restriction on multicast		described in IPv6 [13]. Specifically: the restriction on multicast
	addresses is the same; a RH type 2 is not examined or processed until		addresses is the same; a RH type 2 is not examined or processed until
	it reaches the node identified in the Destination Address field of		it reaches the node identified in the Destination Address field of
	the IPv6 header; in that node, the RH type 0 algorithm applies, with		the IPv6 header; in that node, the RH type 0 algorithm applies, with
	added security checks.		added security checks.
	The construction of the multi-hop RH type 2 by the HA is described in		The construction of the multi-hop RH type 2 by the HA is described in
	Section 8; the processing by the MRs is described in Section 9.4; and		Section 8; the processing by the MRs is described in Section 9.4; and
	the security aspects are treated in Section 11.2.		the security aspects are treated in Section 11.2.
	The destination node of a packet containing a RH type 2 can be a MR		The destination node of a packet containing a RH type 2 can be a MR
	or some other kind of node. If it is a MR it will perform the		or some other kind of node. If it is a MR it will perform the
	algorithm described in Section 9.4, otherwise it will operate as		algorithm described in Section 9.4, otherwise it will operate as
	prescribed by IPv6 [5] when the routing type is unrecognized.		prescribed by IPv6 [13] when the routing type is unrecognized.
	The multi-hop Routing Header type 2, as extended by this draft, has		The multi-hop Routing Header type 2, as extended by this draft, has
	the following format:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type=2| Segments Left |		| Next Header | Hdr Ext Len | Routing Type=2| Segments Left |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 48 ¶
	+ Address[n] +		+ Address[n] +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header		Next Header
	8-bit selector. Identifies the type of header immediately		8-bit selector. Identifies the type of header immediately
	following the Routing header. Uses the same values as the IPv4		following the Routing header. Uses the same values as the IPv4
	Protocol field [8].		Protocol field [16].
	Hdr Ext Len		Hdr Ext Len
	8-bit unsigned integer. Length of the Routing header in 8-octet		8-bit unsigned integer. Length of the Routing header in 8-octet
	units, not including the first 8 octets. For the Type 2 Routing		units, not including the first 8 octets. For the Type 2 Routing
	header, Hdr Ext Len is equal to two times the number of addresses		header, Hdr Ext Len is equal to two times the number of addresses
	in the header.		in the header.
	Routing Type		Routing Type
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 34 ¶
	32-bit reserved field. Initialized to zero for transmission;		32-bit reserved field. Initialized to zero for transmission;
	ignored on reception.		ignored on reception.
	Address[1..n]		Address[1..n]
	Vector of 128-bit addresses, numbered 1 to n.		Vector of 128-bit addresses, numbered 1 to n.
	4.2 Routing Header Type 4 (The Reverse Routing Header)		4.2 Routing Header Type 4 (The Reverse Routing Header)
	The Routing Header type 4, or Reverse Routing Header (RRH), is a		The Routing Header type 4, or Reverse Routing Header (RRH), is a
	variant of IPv4 loose source and record route (LSRR) [1] adapted for		variant of IPv4 loose source and record route (LSRR) [9] adapted for
	IPv6.		IPv6.
	Addresses are added from bottom to top (0 to n-1 in the picture).		Addresses are added from bottom to top (0 to n-1 in the picture).
	The RRH is designed to help the destination build an RH for the		The RRH is designed to help the destination build an RH for the
	return path.		return path.
	When a RRH is present in a packet, the rule for upper-layer checksum		When a RRH is present in a packet, the rule for upper-layer checksum
	computing is that the source address used in the pseudo-header is		computing is that the source address used in the pseudo-header is
	that of the original source, located in the slot 0 of the RRH, unless		that of the original source, located in the slot 0 of the RRH, unless
	the RRH slot 0 is empty, in which case the source in the IP header of		the RRH slot 0 is empty, in which case the source in the IP header of
	skipping to change at page 14, line 46 ¶		skipping to change at page 15, line 46 ¶
	+ Slot[0] (Home address) +		+ Slot[0] (Home address) +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header		Next Header
	8-bit selector. Identifies the type of header immediately		8-bit selector. Identifies the type of header immediately
	following the Routing header. Uses the same values as the IPv4		following the Routing header. Uses the same values as the IPv4
	Protocol field [8].		Protocol field [16].
	Hdr Ext Len		Hdr Ext Len
	8-bit unsigned integer. Length of the Routing header in 8-octet		8-bit unsigned integer. Length of the Routing header in 8-octet
	units, not including the first 8 octets. For the Type 4 Routing		units, not including the first 8 octets. For the Type 4 Routing
	header, Hdr Ext Len is equal to two times the number of addresses		header, Hdr Ext Len is equal to two times the number of addresses
	in the header.		in the header.
	Routing Type		Routing Type
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 24 ¶
	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
	Radia Perlman's lollipop algorithm, values between 0 and 255 are		Radia Perlman's lollipop algorithm, values between 0 and 255 are
	'negative', left to indicate a reboot or the loss of HA		'negative', left to indicate a reboot or the loss of HA
	connectivity, and are skipped when wrapping and upon positive		connectivity, and are skipped when wrapping and upon positive
	Binding Ack. The sequence number is used to check the freshness		Binding Ack. The sequence number is used to check the freshness of
	of the RRH; anti-replay protection is left to IPsec AH.		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 Mobile Network outbound		A RRH is inserted by the first MR on the Mobile Network outbound
	path, as part of the reverse tunnel encapsulation; it is removed by		path, as part of the reverse tunnel encapsulation; it is removed by
	the associated HA when the tunneled packet is decapsulated.		the associated HA when the tunneled packet is decapsulated.
	4.3 Extension Header order		4.3 Extension Header order
	The RH type 2 is to be placed as any RH as described in [5] section		The RH type 2 is to be placed as any RH as described in [13] 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
	IPv6 header.		IPv6 header.
	As a result, the order prescribed in section 4.1 of RFC 2460 becomes:		As a result, the order prescribed in section 4.1 of RFC 2460 becomes:
	skipping to change at page 17, line 8 ¶		skipping to change at page 18, line 8 ¶
	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. Optimum number of slots in RRH		5. Optimum number of slots in RRH
	If its current Attachment Router conforms to Tree Discovery as		If its current Attachment Router conforms to Tree Discovery as
	specified in [13], a MR knows its current tree depth from the Tree		specified in [7], a MR knows its current tree depth from the Tree
	Information Option (RA-TIO). The maximum number of slots needed in		Information Option (RA-TIO). The maximum number of slots needed in
	the RRH is the same value as the MR's own tree depth (that is the		the RRH is the same value as the MR's own tree depth (that is the
	TreeDepth as received from the AR incremented by one).		TreeDepth as received from the AR incremented by one).
	When sending a Binding Update, a MR always reinitializes the number		When sending a Binding Update, a MR always reinitializes the number
	of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree		of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree
	depth, if the latter is known from a reliable hint such as RA-TIO.		depth, if the latter is known from a reliable hint such as RA-TIO.
	The message may have a number of unused (NULL) slots, when it is		The message may have a number of unused (NULL) slots, when it is
	received by the Home Agent. The HA crops out the extra entries in		received by the Home Agent. The HA crops out the extra entries in
	order to send a RH of type 2 back with its response. The RH type 2		order to send a RH of type 2 back with its response. The RH type 2
	skipping to change at page 18, line 34 ¶		skipping to change at page 19, line 34 ¶
	Code 0: RRH too small		Code 0: RRH too small
	The originating MR requires the source to set the RRH size to a		The originating MR requires the source to set the RRH size to a
	larger value. The packet that triggered the ICMP will still be		larger value. The packet that triggered the ICMP will still be
	forwarded by the MR, but the path cannot be totally optimized (see		forwarded by the MR, but the path cannot be totally optimized (see
	Section 9.3).		Section 9.3).
	Checksum		Checksum
	The ICMP checksum [7].		The ICMP checksum [15].
	Current Size		Current Size
	RRH size of the invoking packet, as a reference.		RRH size of the invoking packet, as a reference.
	Proposed Size		Proposed Size
	The new value, expressed as a number of IPv6 addresses that can		The new value, expressed as a number of IPv6 addresses that can
	fit in the RRH.		fit in the RRH.
	Reserved		Reserved
	16-bit reserved field. Initialized to zero for transmission;		16-bit reserved field. Initialized to zero for transmission;
	ignored on reception.		ignored on reception.
	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 [10] modifies the format of the Router Advertisement		Mobile IPv6 [18] modifies the format of the Router Advertisement
	message [6] by the addition of a single flag bit (H) to indicate that		message [14] by the addition of a single flag bit (H) to indicate
	the router sending the Advertisement message is serving as a home		that the router sending the Advertisement message is serving as a
	agent on this link.		home agent on this link.
	This draft adds another single flag bit (N) 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 Mobile Network, which may		the link on which the message is sent is a Mobile Network, which may
	or may not 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
	skipping to change at page 19, line 36 ¶		skipping to change at page 20, line 36 ¶
	| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |		| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |		| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |		| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options ...		| Options ...
	+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-
	This format represents the following changes over that originally		This format represents the following changes over that originally
	specified for Neighbor Discovery [6]:		specified for Neighbor Discovery [14]:
	Home Agent (H)		Home Agent (H)
	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
	Mobile Network, possibly away from home.		Mobile Network, possibly away from home.
	7. MIPv6 flows		7. MIPv6 flows
	7.1 DHAAD		7.1 DHAAD
	Conforming MIPv6 [10], a MR normally does not identify itself in its		Conforming MIPv6 [18], a MR normally does not identify itself in its
	DHAAD messages, using a Home Address option. For the same reason, a		DHAAD messages, using a Home Address option. For the same reason, a
	RRH with a Home address in slot 0 is not required here, either. Yet,		RRH with a Home address in slot 0 is not required here, either. Yet,
	this specification allows a MR to send its DHAAD messages with a NULL		this specification allows a MR to send its DHAAD messages with a NULL
	RRH, as opposed to no RRH at all.		RRH, as opposed to no RRH at all.
	This is generally useful if the attachment router is not bound yet,		This is generally useful if the attachment router is not bound yet,
	for whatever reason, and more specifically in the case of the Mobile		for whatever reason, and more specifically in the case of the Mobile
	Home Network as described in [14]. In the latter case, an HA is		Home Network as described in [3]. In the latter case, an HA is
	mobile and may happen to be located under one of its MRs (within its		mobile and may happen to be located under one of its MRs (within its
	subtree), which is a dead lock for the NEMO basic support..		subtree), which is a dead lock for the NEMO basic support..
	Since MRs may forward packets with an RRH even if themselves are not		Since MRs may forward packets with an RRH even if themselves are not
	bound yet, the packets from nested MRs can be forwarded and the		bound yet, the packets from nested MRs can be forwarded and the
	responses are source routed back, allowing the nested MRs to bind.		responses are source routed back, allowing the nested MRs to bind.
	In particular, if a nested MR is also a mobile Home Agent, it becomes		In particular, if a nested MR is also a mobile Home Agent, it becomes
	reachable from its own MRs, which breaks the deadlock.		reachable from its own MRs, which breaks the deadlock.
	Also, this alleviates the need for the attachment router to forward		Also, this alleviates the need for the attachment router to forward
	DHAAD messages across its own MRHA tunnel.		DHAAD messages across its own MRHA tunnel.
	HAs MUST respond by reversing the RRH into a RH2 if a RRH is present		HAs MUST respond by reversing the RRH into a RH2 if a RRH is present
	and not NULL. A NULL RRH is ignored.		and not NULL. A NULL RRH is ignored.
	7.2 Binding Updates		7.2 Binding Updates
	A MIPv6 or NEMO Binding Update provides more information than just		A MIPv6 or NEMO Binding Update provides more information than just
	the path in the nested cloud so they are still used as described in		the path in the nested cloud so they are still used as described in
	MIPv6 [10] for Home Registration and de-registration. The only		MIPv6 [18] for Home Registration and de-registration. The only
	difference when using a RRH is that the Home Address Destination		difference when using a RRH is that the Home Address Destination
	Option and the alternate CareOf MIP option MUST be omitted.		Option and the alternate CareOf MIP option MUST be omitted.
	The Binding Update flow is also used to update the optimum size of		The Binding Update flow is also used to update the optimum size of
	the RRH, as described in Section 5.		the RRH, as described in Section 5.
	The HA MUST save the RRH in its binding cache, either in the original		The HA MUST save the RRH in its binding cache, either in the original
	form or in the form of an RH type 2, ready to be added to the tunnel		form or in the form of an RH type 2, ready to be added to the tunnel
	header of the MRHA packets. The RRH format is very close to that of		header of the MRHA packets. The RRH format is very close to that of
	the RH type 2, designed to minimize the process of the transmutation.		the RH type 2, designed to minimize the process of the transmutation.
	8. Home Agent Operation		8. Home Agent Operation
	This section inherits from chapter 10 of MIPv6 [10], which is kept		This section inherits from chapter 10 of MIPv6 [18], which is kept
	unmodified except for parts 10.5 and 10.6 which are extended. This		unmodified except for parts 10.5 and 10.6 which are extended. This
	draft mostly adds the opportunity for a MN to update the Binding		draft mostly adds the opportunity for a MN to update the Binding
	Cache of its Home Agent using RRH, though it does not change the fact		Cache of its Home Agent using RRH, though it does not change the fact
	that MNs still need to select a home agent, register and deregister		that MNs still need to select a home agent, register and deregister
	to it, using the MIP Bind Update.		to it, using the MIP Bind Update.
	This draft extends [10] section 10.6 as follows:		This draft extends [18] section 10.6 as follows:
	o The entry point of the tunnel is now checked against the TLMR as		o The entry point of the tunnel is now checked against the TLMR as
	opposed to the primary CoA.		opposed to the primary CoA.
	o The Binding Cache can be updated based on RRH with proper AH		o The Binding Cache can be updated based on RRH with proper AH
	authentication.		authentication.
	As further explained in Section 7.2, this specification modifies MIP		As further explained in Section 7.2, this specification modifies MIP
	so that the HA can rely on the RH type 4 (RRH) to update its Bind		so that the HA can rely on the RH type 4 (RRH) to update its Bind
	Cache Entry (BCE), when the Mobile Node moves. The conceptual		Cache Entry (BCE), when the Mobile Node moves. The conceptual
	skipping to change at page 22, line 14 ¶		skipping to change at page 23, line 14 ¶
	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.
	The sequence counter semantics is changed as described in Section		The sequence counter semantics is changed as described in
	4.2		Section 4.2
	This draft extends [10] section 10.5 as follows:		This draft extends [18] section 10.5 as follows:
	A Home Agent advertises the prefixes of its registered Mobile		A Home Agent advertises the prefixes of its registered Mobile
	Routers, during the registration period, on the local Interior		Routers, during the registration period, on the local Interior
	Gateway Protocol (IGP).		Gateway Protocol (IGP).
	The Routing Header type 2 is extended to be multi-hop.		The Routing Header type 2 is extended to be multi-hop.
	The Home Agent is extended to support routes to prefixes that are		The Home Agent is extended to support routes to prefixes that are
	owned by Mobile Routers. This can be configured statically, or can		owned by Mobile Routers. This can be configured statically, or can
	be exchanged using a routing protocol as in [12], which is out of the		be exchanged using a routing protocol as in [19], which is out of the
	scope of this document. As a consequence of this process, the Home		scope of this document. As a consequence of this process, the Home
	Agent which is selected by a Mobile Router advertises reachability of		Agent which is selected by a Mobile Router advertises reachability of
	the MR prefixes for the duration of the registration over the local		the MR prefixes for the duration of the registration over the local
	IGP.		IGP.
	When a HA gets a packet for which the destination is a node behind a		When a HA gets a packet for which the destination is a node behind a
	Mobile Router, it places the packet in the tunnel to the associated		Mobile Router, it places the packet in the tunnel to the associated
	MR. This ends up with a packet which destination address in the IP		MR. This ends up with a packet which destination address in the IP
	Header is the TLMR, and with a Routing Header of type 2 for the rest		Header is the TLMR, and with a Routing Header of type 2 for the rest
	of the way to the Mobile Router, which may be multi-hop.		of the way to the Mobile Router, which may be multi-hop.
	To build the RH type 2 from the RRH, the HA sets the type to 2, and		To build the RH type 2 from the RRH, the HA sets the type to 2, and
	clears the bits 32-63 (byte 4 to 7).		clears the bits 32-63 (byte 4 to 7).
	9. Mobile Router Operation		9. Mobile Router Operation
	This section inherits from chapter 11 of [10], which is extended to		This section inherits from chapter 11 of [18], which is extended to
	support Mobile Networks and Mobile Routers as a specific case of		support Mobile Networks and Mobile Routers as a specific case of
	Mobile Node.		Mobile Node.
	This draft extends section 11.2.1 of MIPv6 [10] as follows:		This draft extends section 11.2.1 of MIPv6 [18] as follows:
	o When not at home, an MR uses a reverse tunnel with its HA for all		o When not at home, an MR uses a reverse tunnel with its HA for all
	the traffic that is sourced in its mobile network(s); traffic		the traffic that is sourced in its mobile network(s); traffic
	originated further down a nested network is not tunneled twice but		originated further down a nested network is not tunneled twice but
	for exception cases.		for exception cases.
	o The full path to and within the Mobile Network is piggy-backed		o The full path to and within the Mobile Network is piggy-backed
	with the traffic on a per-packet basis to cope with rapid		with the traffic on a per-packet basis to cope with rapid
	movement. This makes the packet construction different from		movement. This makes the packet construction different from
	MIPv6.		MIPv6.
	The MR when not at home sets up a bi-directional tunnel with its HA.		The MR when not at home sets up a bi-directional tunnel with its HA.
	The reverse direction MR -> HA is needed to assure transparent		The reverse direction MR -> HA is needed to assure transparent
	topological correctness to LFNs, as in [12]. But, as opposed to the		topological correctness to LFNs, as in [19]. But, as opposed to the
	NEMO Basic Support, nested tunnels are generally avoided.		NEMO Basic Support, nested tunnels are generally avoided.
	9.1 Processing of ICMP "RRH too small"		9.1 Processing of ICMP "RRH too small"
	The New ICMP message "RRH too Small" is presented in Section 5. This		The New ICMP message "RRH too Small" is presented in Section 5. This
	message is addressed to the MR which performs the tunnel		message is addressed to the MR which performs the tunnel
	encapsulation and generates the RRH.		encapsulation and generates the RRH.
	Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate		Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate
	it to the originating LFN or inner tunnel source, but MUST process it		it to the originating LFN or inner tunnel source, but MUST process it
	skipping to change at page 25, line 5 ¶		skipping to change at page 26, line 5 ¶
	9.3 Processing of RHH for Outbound Packets		9.3 Processing of RHH for Outbound Packets
	The forwarding of a packet with a non saturated RRH consists in fact		The forwarding of a packet with a non saturated RRH consists in fact
	in passing the hot potato to the attachment router, which does not		in passing the hot potato to the attachment router, which does not
	require the MRHA tunnel to be up.		require the MRHA tunnel to be up.
	So, it happens as soon as a MR has selected its attachment router and		So, it happens as soon as a MR has selected its attachment router and
	before the binding flow has actually taken place. Also, this process		before the binding flow has actually taken place. Also, this process
	is much safer since the packet is not forwarded home.		is much safer since the packet is not forwarded home.
	if no RRH in outer header /* First Mobile Router specific */		if no RRH in outer header /* First Mobile Router specific */
	or RRH present but saturated { /* Need a nested encapsulation */		or RRH present but saturated { /* Need a nested encapsulation */
	if RRH is saturated {		if RRH is saturated {
	do ICMP back (RRH too small)		do ICMP back (RRH too small)
	}		}
	/* put packet in sliding reverse tunnel if bound */		/* put packet in sliding reverse tunnel if bound */
	if reverse tunnel is established {		if reverse tunnel is established {
	insert new IP header plus RRH		insert new IP header plus RRH
	set source address to the MR Home Address		set source address to the MR Home Address
	set destination address to the MR Home Agent Address		set destination address to the MR Home Agent Address
	skipping to change at page 26, line 38 ¶		skipping to change at page 27, line 38 ¶
	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 Mobile Network prefixes {		if Address [i] doesn't belong to one of the MNP {
	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 is 0 and Address[i] isn't the node's own
	home address {		home address {
	discard the packet		discard the packet
	return		return
	}		}
	swap the IPv6 Destination Address and Address[i]		swap the IPv6 Destination Address and Address[i]
	if the IPv6 Hop Limit is less than or equal to 1 {		if the IPv6 Hop Limit is less than or equal to 1 {
	send an ICMP Time Exceeded -- Hop Limit Exceeded in		send an ICMP Time Exceeded -- Hop Limit Exceeded in
	Transit message to the Source Address and discard the		Transit message to the Source Address and discard the
	packet		packet
	}		}
	skipping to change at page 28, line 21 ¶		skipping to change at page 29, line 21 ¶
	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 attacker on the path.		that the RRH can be modified in transit by an attacker on the path.
	It has to be noted that such an attacker (for example any MR in the		It has to be noted that such an attacker (for example any MR in the
	Mobile Network) can perform more effective attacks than modifying the		Mobile Network) can perform more effective attacks than modifying the
	RRH.		RRH.
	11.1 IPsec Processing		11.1 IPsec Processing
	The IPsec [2] AH [3] and ESP [4] can be used in tunnel mode to		The IPsec [10] AH [11] and ESP [12] 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
	to provide authentication of the outer IP header fields, especially		to provide authentication of the outer IP header fields, especially
	the Routing Headers.		the Routing Headers.
	11.1.1 Routing Header type 2		11.1.1 Routing Header type 2
	Due to the possible usage of Doors [15] to enable IPv4 traversal, the		Due to the possible usage of Doors [8] to enable IPv4 traversal, the
	Routing Header type 2 cannot be treated as type 0 for the purpose of		Routing Header type 2 cannot be treated as type 0 for the purpose of
	IPsec processing (i.e. it cannot be included in its intirety in the		IPsec processing (i.e. it cannot be included in its intirety in the
	Integrity Check Value (ICV) computation, because NAT/PAT may mangle		Integrity Check Value (ICV) computation, because NAT/PAT may mangle
	one of the MR care-of-addresses along the HA-MR path.		one of the MR care-of-addresses along the HA-MR path.
	The sender (the HA) will put the slot 0 entry (the MR Home Address)		The sender (the HA) will put the slot 0 entry (the MR Home Address)
	of the RH as destination of the outer packet, will zero out		of the RH as destination of the outer packet, will zero out
	completely the Routing Header and will perform the ICV computation.		completely the Routing Header and will perform the ICV computation.
	The receiver (the MR) will put the slot 0 entry as destination of the		The receiver (the MR) will put the slot 0 entry as destination of the
	outer packet, will zero out the Routing Header and will perform the		outer packet, will zero out the Routing Header and will perform the
	ICV validation.		ICV validation.
	skipping to change at page 30, line 11 ¶		skipping to change at page 31, line 11 ¶
	Address) in the source address and will zero out all the slots and		Address) in the source address and will zero out all the slots and
	the Segment Used field of the RRH, and then will perform the ICV		the Segment Used field of the RRH, and then will perform the ICV
	verification.		verification.
	11.2 New Threats		11.2 New Threats
	The RH type 4 is used to construct a MIPv6 RH type 2 with additional		The RH type 4 is used to construct a MIPv6 RH type 2 with additional
	semantics, as described in Section 4.1. Since RH type 2 becomes a		semantics, as described in Section 4.1. Since RH type 2 becomes a
	multi hop option like RH type 0, care must be applied to avoid the		multi hop option like RH type 0, care must be applied to avoid the
	spoofing attack that can be performed with the IPv4 source route		spoofing attack that can be performed with the IPv4 source route
	option. This is why IPv6 [5] takes special care in responding to		option. This is why IPv6 [13] takes special care in responding to
	packets carrying Routing Headers.		packets carrying Routing Headers.
	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 [3].		enables the anti-replay service of AH [11].
	In particular, if IPSec is being used, the content is protected and		In particular, if IPSec is being used, the content is protected and
	can not be read or modified, so there is no point in redirecting the		can not be read or modified, so there is no point in redirecting the
	traffic just to screen it.		traffic just to screen it.
	Say a MR in a nested structure modifies the RRH in order to bomb a		Say a MR in a nested structure modifies the RRH in order to bomb a
	target outside of the tree. If that MR forwards the packet with		target outside of the tree. If that MR forwards the packet with
	itself as source address, the MR above it will make sure that the		itself as source address, the MR above it will make sure that the
	response packets come back to the attacker first, since that source		response packets come back to the attacker first, since that source
	is prepended to the RRH. If it forges the source address, then the		is prepended to the RRH. If it forges the source address, then the
	skipping to change at page 30, line 49 ¶		skipping to change at page 31, line 49 ¶
	Say a MR in a nested structure modifies the RH 2 in order to attack a		Say a MR in a nested structure modifies the RH 2 in order to attack a
	target outside of the tree. The RH type 2 forwarding rules make sure		target outside of the tree. The RH type 2 forwarding rules make sure
	that the packet can only go down a tree. So unless the attacker is		that the packet can only go down a tree. So unless the attacker is
	TLMR, the packet will not be forwarded. In any case, the attacker		TLMR, the packet will not be forwarded. In any case, the attacker
	will be bombed first.		will be bombed first.
	Say that an attacker on the path of the MRHA tunnel modifies the RRH		Say that an attacker on the path of the MRHA tunnel modifies the RRH
	in order to black out the MR. The result could actually be		in order to black out the MR. The result could actually be
	accomplished by changing any bit in the packet since the IPSec		accomplished by changing any bit in the packet since the IPSec
	signature would fail, or scrambling the radio waves in the case of		signature would fail, or scrambling the radio waves in the case of
	wireless.		wireless.
	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. Note that the MR should not		outside of the scope of this draft. Note that the MR should not
	select a path based on trust but rather on measured service. If a		select a path based on trust but rather on measured service. If a
	better bandwidth is obtained via an untrusted access using IPSec,		better bandwidth is obtained via an untrusted access using IPSec,
	isn't it better than a good willing low bandwidth trusted access?		isn't it better than a good willing low bandwidth trusted access?
	12. Protocol Constants		12. IANA considerations
			This document requires IANA to define 2 new IPv6 Routing Header
			types.
			13. Protocol Constants
	DEF_RRH_SLOTS: 7		DEF_RRH_SLOTS: 7
	MAX_RRH_SLOTS: 10		MAX_RRH_SLOTS: 10
	13. Acknowledgements		14. Acknowledgements
	The authors wish to thank David Auerbach, Fred Baker, Dana Blair,		The authors wish to thank David Auerbach, Fred Baker, Dana Blair,
	Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,		Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur,
	Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick		Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick
	Wetterwald -last but not least :)-.		Wetterwald -last but not least :)-.
	14 References		15. References
	[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September		15.1 informative reference
	1981.
	[2] Kent, S. and R. Atkinson, "Security Architecture for the		[1] Devarapalli, V., "Local HA to HA protocol",
			draft-devarapalli-mip6-nemo-local-haha-01 (work in progress),
			March 2006.
			[2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
			Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
			progress), May 2006.
			[3] Thubert, P., "NEMO Home Network models",
			draft-ietf-nemo-home-network-models-06 (work in progress),
			February 2006.
			[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
			draft-ietf-nemo-terminology-05 (work in progress), March 2006.
			[5] Ernst, T., "Network Mobility Support Goals and Requirements",
			draft-ietf-nemo-requirements-05 (work in progress),
			October 2005.
			[6] Ng, C., "Analysis of Multihoming in Network Mobility Support",
			draft-ietf-nemo-multihoming-issues-06 (work in progress),
			June 2006.
			[7] Thubert, P., "Nested Nemo Tree Discovery",
			draft-thubert-tree-discovery-03 (work in progress), April 2006.
			[8] Thubert, P., Molteni, M., and P. Wetterwald, "IPv4 traversal for
			MIPv6 based Mobile Routers",
			draft-thubert-nemo-ipv4-traversal-01 (work in progress),
			May 2003.
			15.2 normative reference
			[9] Postel, J., "Internet Protocol", STD 5, RFC 791,
			September 1981.
			[10] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,		[11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
	November 1998.		November 1998.
	[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload		[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
	(ESP)", RFC 2406, November 1998.		(ESP)", RFC 2406, November 1998.
	[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery		[14] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[7] Conta, A. and S. Deering, "Internet Control Message Protocol		[15] Conta, A. and S. Deering, "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
	[8] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an		[16] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
	On-line Database", RFC 3232, January 2002.		line Database", RFC 3232, January 2002.
	[9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC		[17] Manner, J. and M. Kojo, "Mobility Related Terminology",
	3753, June 2004.		RFC 3753, June 2004.
	[10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[18] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[11] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[19] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	draft-ietf-nemo-terminology-01 (work in progress), February		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	2004.		January 2005.
	[12] Devarapalli, V., "Network Mobility (NEMO) Basic Support
	Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
	June 2004.
	[13] Thubert, P. and N. Montavont, "Nested Nemo Tree Discovery",
	draft-thubert-tree-discovery-00 (work in progress), May 2004.
	[14] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home
	Network models", draft-ietf-nemo-home-network-models-00 (work
	in progress), April 2004.
	[15] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for
	MIPv6 based Mobile Routers",
	draft-thubert-nemo-ipv4-traversal-01 (work in progress), May
	2003.
	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
	EMail: pthubert@cisco.com		Email: pthubert@cisco.com
	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
	Appendix A. Optimizations		Appendix A. Optimizations
	A.1 Path Optimization with RRH		A.1 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.
	skipping to change at page 36, line 8 ¶		skipping to change at page 37, line 8 ¶
	o Since the path information is not available, the correspondent		o Since the path information is not available, the correspondent
	MUST NOT update its BCE based on the RH type 3. The CN (or HA)		MUST NOT update its BCE based on the RH type 3. The CN (or HA)
	identifies the source from the entry in slot 0 and may reconstruct		identifies the source from the entry in slot 0 and may reconstruct
	the initial packet using the CareOf in slot 1 as source for AH		the initial packet using the CareOf in slot 1 as source for AH
	purposes.		purposes.
	/* MR processing on outbound packet with RH type 3 support */		/* MR processing on outbound packet with RH type 3 support */
	{		{
	if no RH type 3 or 4 in outer header /* First Mobile Router specific */		if no RH type 3 or 4 in outer header /* Case of first MR */
	or RH type 4 present but saturated { /* Need a nested encapsulation */		or RH type 4 present but saturated { /* Causing nested encap */
	if RRH is saturated {		if RRH is saturated {
	do ICMP back (RRH too small)		do ICMP back (RRH too small)
	}		}
	/* put packet in sliding reverse tunnel */		/* put packet in sliding reverse tunnel */
	insert new IP header plus RRH		insert new IP header plus RRH
	set source address to the MR Home Address		set source address to the MR Home Address
	set destination address to the MR Home Agent Address		set destination address to the MR Home Agent Address
	add an RRH with all slots zeroed out		add an RRH with all slots zeroed out
	skipping to change at page 37, line 27 ¶		skipping to change at page 38, line 27 ¶
	+ Home Address +		+ Home Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header		Next Header
	8-bit selector. Identifies the type of header immediately		8-bit selector. Identifies the type of header immediately
	following the Routing header. Uses the same values as the IPv4		following the Routing header. Uses the same values as the IPv4
	Protocol field [8].		Protocol field [16].
	Hdr Ext Len		Hdr Ext Len
	8-bit unsigned integer. Length of the Routing header in 8-octet		8-bit unsigned integer. Length of the Routing header in 8-octet
	units, not including the first 8 octets. For the Type 3 Routing		units, not including the first 8 octets. For the Type 3 Routing
	header, Hdr Ext Len is always 2.		header, Hdr Ext Len is always 2.
	Routing Type		Routing Type
	8-bit unsigned integer. Set to 3.		8-bit unsigned integer. Set to 3.
	skipping to change at page 38, line 27 ¶		skipping to change at page 39, line 31 ¶
	=== === ===		=== === ===
	===?== ==?===		===?== ==?===
	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
	Attachment (default) Router. In terms of Tree Information, MR5, as		Attachment (default) Router. In terms of Tree Information, MR5, as
	well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once		well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once
	MR5 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.
	skipping to change at page 39, line 25 ¶		skipping to change at page 41, line 25 ¶
	=== === ===		=== === ===
	==? ?==		==? ?==
	MR1		MR1
	|		|
	==?=====?=======?====== 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 attachment		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.
	skipping to change at page 40, line 34 ¶		skipping to change at page 42, line 34 ¶
	NEMO but that RRH replaces both Home address Option and Alternate		NEMO but that RRH replaces both Home address Option and Alternate
	CareOf option.		CareOf option.
	From -02 to -03		From -02 to -03
	Reworded the security part to remove an ambiguity that let the		Reworded the security part to remove an ambiguity that let the
	reader think that RRH is unsafe.		reader think that RRH is unsafe.
	From -01 to -02		From -01 to -02
	Made optional the usage of ICMP warning "RRH too small" (Section		Made optional the usage of ICMP warning "RRH too small"
	5).		(Section 5).
	Changed the IPsec processing for Routing Header type 2 (Section		Changed the IPsec processing for Routing Header type 2
	11.1).		(Section 11.1).
	From -00 to -01		From -00 to -01
	Added new Tree Information Option fields:		Added new Tree Information Option fields:
	A 8 bits Bandwidth indication that provides an idea of the		A 8 bits Bandwidth indication that provides an idea of the
	egress bandwidth.		egress bandwidth.
	A CRC-32 that changes with the egress path out of the tree.		A CRC-32 that changes with the egress path out of the tree.
	skipping to change at page 42, line 41 ¶		skipping to change at page 44, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 75 change blocks.
	149 lines changed or deleted		176 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/