< draft-thubert-nemo-reverse-routing-header-03.txt		draft-thubert-nemo-reverse-routing-header-04.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: April 12, 2004 Cisco Systems		Expires: ao“t 1, 2004 Cisco Systems
	October 13, 2003		February 2004
	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-03		draft-thubert-nemo-reverse-routing-header-04
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 12, 2004.		This Internet-Draft will expire on ao“t 1, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). 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
	Mobile Routers and their Home Agents.		Mobile Routers and their Home Agents.
	This proposal allows the building of a nested Mobile Network avoiding		This proposal allows the building of a nested Mobile Network avoiding
	the nested tunnel overhead. This is accomplished by using a new		the nested tunnel overhead. This is accomplished by using a new
	skipping to change at page 21, line 15 ¶		skipping to change at page 21, line 15 ¶
	TreePreference		TreePreference
	8-bit unsigned integer set by the TLMR to its configured		8-bit unsigned integer set by the TLMR to its configured
	preference. Range from 0 = lowest to 255 = highest.		preference. Range from 0 = lowest to 255 = highest.
	TreeDepth		TreeDepth
	8-bit unsigned 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)		Grounded (G)
	1-bit flag. Set by the TLMR to indicate that it is either attached		1-bit flag. Set by the TLMR to indicate that it is either attached
	to a fixed network or at home.		to a fixed network or at home.
	Home (H)		Home Agent (H)
	1-bit flag. Set by the TLMR to indicate that it is also		1-bit flag. Set by the TLMR to indicate that it is also
	functioning as a HA, for re-homing purposes.		functioning as a Home Agent, for re-homing purposes.
	Reserved		Reserved
	6-bit unsigned integer, set to 0 by the TLMR.		6-bit unsigned integer, set to 0 by the TLMR.
	Bandwidth		Bandwidth
	8-bit unsigned integer set by the TLMR and decremented by MRs with		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		lower egress bandwidth. This is a power of 2 so that the available
	egress bandwidth in bps is between 2^Bandwidth and		egress bandwidth in bps is between 2^Bandwidth and
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 9 ¶
	TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST		TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST
	propagate it on its ingress interface(s), as described in Section		propagate it on its ingress interface(s), as described in Section
	9.4.		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		A MIPv6 or NEmo Binding Update provides more information than just
	Registration and de-registration, but only when the MR registers for		the path in the nested cloud so they are still used as described in
	the first time with its HA.		MIPv6 [1] for Home Registration and de-registration. The only
			difference when using RRH is that the Home Address Destination Option
	Since the BU doesn't contain the full NEMO path to the MR, it cannot		and the alternate CareOf MIP option MUST be omitted.
	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		Intermediate updates (or just refreshes) between BUs are obtained as
	obtained as one of the results of processing the RRH by the HA.		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 Option in an RA message that indicates a		receives a Tree Information Option in an RA message that indicates a
	change in the attachment tree) or in the absence of traffic (detected		change in the attachment tree) or in the absence of traffic (detected
	by a timeout) to the HA, it must send an RRH Heartbeat (IP packet		by a timeout) to the HA, it must send an RRH Heartbeat, which is a
	with the RRH and empty payload).		binding update with a RRH.
	8. Home Agent Operation		8. Home Agent Operation
	This section inherits from chapter 10 of MIPv6 [1], which is kept		This section inherits from chapter 10 of MIPv6 [1], 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.
	skipping to change at page 34, line 14 ¶		skipping to change at page 34, line 14 ¶
	References		References
	[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
	2003.		2003.
	[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-00 (work in progress), May 2003.		draft-ietf-nemo-terminology-00 (work in progress), May 2003.
	[3] Kniveton, T., "Mobile Router Tunneling Protocol",		[3] kniveton, t., "Mobile Router Support with Mobile IP",
	draft-kniveton-mobrtr-03 (work in progress), November 2002.		draft-kniveton-mobrtr-02 (work in progress), July 2002.
	[4] Deering, S. and B. Zill, "Redundant Address Deletion when		[4] Deering, S. and B. Zill, "Redundant Address Deletion when
	Encapsulating IPv6 in IPv6",		Encapsulating IPv6 in IPv6",
	draft-deering-ipv6-encap-addr-deletion-00 (work in progress),		draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
	November 2001.		November 2001.
	[5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for		[5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for
	MIPv6 based Mobile Routers",		MIPv6 based Mobile Routers",
	draft-thubert-nemo-ipv4-traversal-01 (work in progress), May		draft-thubert-nemo-ipv4-traversal-01 (work in progress), May
	2003.		2003.
	skipping to change at page 42, line 7 ¶		skipping to change at page 42, line 7 ¶
	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 attachment 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.
	Appendix C. Changes from Previous Version of the Draft		Appendix C. Changes from Previous Version of the Draft
			From -03 to -04
			TI option: renamed the F (fixed) flag bit to G (grounded).
			Binding Update: Made clear that the BU flow conforms MIPv6 and
			Nemo but that RRH replaces both Home address Option and Alternate
			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" (Section
	5).		5).
	Changed the IPsec processing for Routing Header type 2 (Section		Changed the IPsec processing for Routing Header type 2 (Section
	11.1).		11.1).
	skipping to change at page 43, line 29 ¶		skipping to change at page 43, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 14 change blocks.
	22 lines changed or deleted		29 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/