< draft-wakikawa-nemo-orc-00.txt		draft-wakikawa-nemo-orc-01.txt >
	INTERNET DRAFT Ryuji Wakikawa		INTERNET DRAFT Ryuji Wakikawa
	10 July 2004 Masafumi Watari		Expires: 24 Apr 2005 Masafumi Watari
	Keio Univ./WIDE		Keio Univ./WIDE
			24 Oct 2004
	Optimized Route Cache Protocol (ORC)		Optimized Route Cache Protocol (ORC)
	draft-wakikawa-nemo-orc-00.txt		draft-wakikawa-nemo-orc-01.txt
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note		Task Force (IETF), its areas, and its working groups. Note
	that other groups may also distribute working documents as		that other groups may also distribute working documents as
	Internet-Drafts.		Internet-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		and may be updated, replaced, or obsoleted by other documents at
	any time. It is inappropriate to use Internet-Drafts as reference		any 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.
			Copyright Notice
			Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This draft proposes Optimized Route Cache Protocol (ORC) to provide		This draft proposes Optimized Route Cache Protocol (ORC) to provide
	route optimization for the NEMO Basic Support protocol. ORC provides		route optimization for the NEMO Basic Support protocol. ORC provides
	a dynamic route optimization mechanism, similar to route optimization		a dynamic route optimization mechanism, similar to route optimization
	in Mobile IPv6.		in Mobile IPv6.
	The ORC aims to manage binding information as if routing information		The ORC aims to manage binding information for when routing
	of each mobile network are located at special routers called		information of each mobile network are located at special routers
	``Correspondent Router''.		called ``Correspondent Router''.
	Contents		Contents
	Status of This Memo i		Status of This Memo i
	Abstract i		Abstract i
	1. Introduction 2
	2. ORC Concept 2		1. Introduction 3
	3. Terminology 3		2. ORC Concept 3
	4. ORC Overview 4		3. Terminology 4
	4.1. Correspondent Router Discovery . . . . . . . . . . . . . 4
	4.2. Binding Registration to Correspondent Router . . . . . . 4
	4.3. Forwarding between Mobile Router and Correspondent Router 5
	5. Extensions to Mobile IPv6 and the Basic NEMO protocol 5		4. ORC Overview 5
	5.1. Forwarding Table Data Structure . . . . . . . . . . . . . 5		4.1. Correspondent Router Discovery . . . . . . . . . . . . . 5
	5.2. Mobility Header Messages . . . . . . . . . . . . . . . . 6		4.2. Binding Registration to Correspondent Router . . . . . . 5
	5.2.1. Binding Update . . . . . . . . . . . . . . . . . 6		4.3. Forwarding between Mobile Router and Correspondent Router 6
	5.2.2. Binding Acknowledgment . . . . . . . . . . . . . 6
	5.2.3. Managed Prefix Lists sub-option . . . . . . . . . 6
	5.3. New ICMP Messages . . . . . . . . . . . . . . . . . . . . 7
	5.3.1. Correspondent Router Discovery Request . . . . . 7
	5.3.2. Correspondent Router Discovery Reply . . . . . . 8
	6. Protocol Operations 10		5. Extensions to Mobile IPv6 and the Basic NEMO protocol 6
	6.1. Correspondent Router Discovery . . . . . . . . . . . . . 10		5.1. Forwarding Table Data Structure . . . . . . . . . . . . . 6
	6.2. Binding Registration to Correspondent Router . . . . . . 11		5.2. Mobility Header Messages . . . . . . . . . . . . . . . . 7
	6.2.1. Sending Binding Update . . . . . . . . . . . . . 11		5.2.1. Binding Update . . . . . . . . . . . . . . . . . 7
	6.2.2. Return Routability . . . . . . . . . . . . . . . 11		5.2.2. Binding Acknowledgment . . . . . . . . . . . . . 7
	6.3. Intercepting Packets by Correspondent Router . . . . . . 12		5.2.3. Managed Prefix Lists sub-option . . . . . . . . . 7
	6.4. Routing to Mobile Network . . . . . . . . . . . . . . . . 13		5.3. New ICMP Messages . . . . . . . . . . . . . . . . . . . . 8
			5.3.1. Correspondent Router Discovery Request . . . . . 8
			5.3.2. Correspondent Router Discovery Reply . . . . . . 9
	7. Support for Nested Mobile Networks 13		6. Protocol Operations 11
			6.1. Correspondent Router Discovery . . . . . . . . . . . . . 11
			6.2. Binding Registration to Correspondent Router . . . . . . 12
			6.2.1. Sending Binding Update . . . . . . . . . . . . . 12
			6.2.2. Return Routability . . . . . . . . . . . . . . . 12
			6.3. Intercepting Packets by Correspondent Router . . . . . . 13
			6.4. Routing to Mobile Network . . . . . . . . . . . . . . . . 14
	8. Security Consideration 14		7. Security Consideration 14
	9. Acknowledgements 14		8. Acknowledgements 14
	References 14		References 14
	Authors' Addresses 15		Authors' Addresses 16
	Appendices 16
	A. Example Scenario 16		Appendices 17
	B. Correspondent Router Hierarchy 18		A. Example Scenario 17
	C. Route Optimization in Nested Mobile Network 20		B. Correspondent Router Hierarchy 19
			C. Modifications from the last version 21
	1. Introduction		1. Introduction
	The NEMO Basic Support protocol [4] is currently being standardized		The NEMO Basic Support protocol [4] is currently being standardized
	at the IETF NEMO working group. However, the NEMO Basic Support		at the IETF NEMO working group. However, the NEMO Basic Support
	protocol does not provide route optimization, but always use a		protocol does not provide route optimization, but always use a
	bi-directional tunnel established between a mobile router and		bi-directional tunnel established between a mobile router and
	its home agent. Optimized route cache protocol is designed as an		its home agent. Optimized route cache protocol is designed as an
	extension to the NEMO Basic Support protocol for providing certain		extension to the NEMO Basic Support protocol for providing certain
	route optimization. ORC was proposed earlier in the paper [8].		route optimization. ORC was proposed earlier in the paper [8].
	skipping to change at page 2, line 41 ¶		skipping to change at page 3, line 41 ¶
	correspondent routers that can be configured anywhere in the		correspondent routers that can be configured anywhere in the
	Internet to be an anchor router for the mobile network, providing		Internet to be an anchor router for the mobile network, providing
	certain level of route optimization. Practically, the correspondent		certain level of route optimization. Practically, the correspondent
	routers should be scattered near the transit AS to allow direct		routers should be scattered near the transit AS to allow direct
	forwarding to the mobile network before reaching the home agent.		forwarding to the mobile network before reaching the home agent.
	Because it is impossible to replace all routers on the Internet		Because it is impossible to replace all routers on the Internet
	with the correspondent routers support, it is effective to place a		with the correspondent routers support, it is effective to place a
	correspondent router at places where traffic is converged like the		correspondent router at places where traffic is converged like the
	Internet Exchange Point (IXP).		Internet Exchange Point (IXP).
	The optimized routing cache protocol is kind of a best effect routing		The optimized routing cache protocol provides optimal route path in
	protocol, where the path is only optimized where correspondent		best effort when correspondent routers exist. However, the level of
	routers exist. However, the level of optimization can be improved		optimization can be improved depending on where the correspondent
	depending on where the correspondent routers are placed, and the		routers are placed, and the path it takes. The correspondent routers
	path it takes. The correspondent routers can also be dynamically		can also be dynamically discovered if necessary, to provide certain
	discovered if necessary, to provide certain route optimization.		route optimization.
	Since the binding is processed and maintained only by the		Since the binding is processed and maintained only by the
	correspondent routers scattered over the Internet, mobile router		correspondent routers scattered over the Internet, mobile router
	does not need to handle bindings for each correspondent nodes. It		does not need to handle bindings for each correspondent nodes. It
	is clearly redundant operations if both the mobile router and the		is clearly redundant operations if both the mobile router and the
	remote network manage bindings for the same communicating network.		remote network manage bindings for the same communicating network.
	This also allows the end-nodes to communicate in the optimized route		This also allows the end-nodes to communicate in the optimized route
	without requiring any additional functions.		without requiring any additional functions.
	This concept can be applied to Mobile IPv6 as well. In Mobile IPv6,		This concept can be applied to Mobile IPv6 as well. In Mobile IPv6,
	skipping to change at page 3, line 46 ¶		skipping to change at page 4, line 46 ¶
	anycast identifier. The anycast identifier is to be defined by		anycast identifier. The anycast identifier is to be defined by
	IANA.		IANA.
	Managed Prefix		Managed Prefix
	Prefixes which are managed by each correspondent router.		Prefixes which are managed by each correspondent router.
	The Managed Prefix is often configured with administrative		The Managed Prefix is often configured with administrative
	policy. For example, if a correspondent router is placed for		policy. For example, if a correspondent router is placed for
	an administrative domain (let's say 2001:a:b::/32), the Managed		an administrative domain (let's say 2001:a:b::/32), the Managed
	Prefix for the correspondent router is the 2001:a:b::/32.		Prefix for the correspondent router is the 2001:a:b::/32.
	Mobile router can forward any packets meant for the managed		Mobile router can tunnel any packets meant for the managed
	prefixes to the correspondent router. The correspondent		prefixes to the correspondent router. The correspondent
	router has responsibility to route packets correctly to the		router has responsibility to route packets correctly to the
	destination which is in the managed prefixes.		destination which is in the managed prefixes.
	Proxy Route		Proxy Route
	A proxy Route is used to intercept packets by a correspondent		A proxy Route is used to intercept packets by a correspondent
	router at an administrative domain. A proxy route is to direct		router at an administrative domain. A proxy route is to direct
	a route of a mobile network prefix to a correspondent router.		a route of a mobile network prefix to a correspondent router.
	Proxy route contains a mobile network prefix of a correspondent		Proxy route contains a mobile network prefix of a correspondent
	skipping to change at page 5, line 9 ¶		skipping to change at page 6, line 9 ¶
	the correspondent router. The mobile router MUST set ORC flag 'O' in		the correspondent router. The mobile router MUST set ORC flag 'O' in
	the Binding Update and include the Mobile Network Prefix sub-options.		the Binding Update and include the Mobile Network Prefix sub-options.
	The Binding Update message is same as a Binding Update sent to a Home		The Binding Update message is same as a Binding Update sent to a Home
	Agent except for the flag field (i.e. 'O' flag set and 'H' flag		Agent except for the flag field (i.e. 'O' flag set and 'H' flag
	unset).		unset).
	After processing the Binding Update successfully, the correspondent		After processing the Binding Update successfully, the correspondent
	router MUST return a Binding Acknowledgment including the managed		router MUST return a Binding Acknowledgment including the managed
	prefix list. The managed prefix is used when the mobile router		prefix list. The managed prefix is used when the mobile router
	decides which packets are sent to which correspondent router. The		decides which packets are sent to which correspondent router. The
	Home Agent setup forwarding for all the mobile network prefixes		correspondent router setup forwarding for all the mobile network
	notified by the mobile router.		prefixes notified by the mobile router.
	After getting successful Binding Acknowledgment, the mobile router		After getting successful Binding Acknowledgment, the mobile router
	set up forwarding for all managed prefixes. If the mobile router		set up forwarding for all managed prefixes. If the mobile router
	gets error status code in the Binding Acknowledgment or cannot get		gets error status code in the Binding Acknowledgment or cannot get
	any Binding Acknowledgment, it SHOULD stop sending Binding Update to		any Binding Acknowledgment, it SHOULD stop sending Binding Update to
	the correspondent router and SHOULD mark the correspondent router as		the correspondent router and SHOULD mark the correspondent router as
	invalid.		invalid.
	There is alternative mechanism based on Return Routability to send		There is alternative mechanism based on Return Routability to send
	secured Binding Update. The detailed operation is introduced in		secured Binding Update. The detailed operation is introduced in
	skipping to change at page 6, line 9 ¶		skipping to change at page 7, line 9 ¶
	- Correspondent Router Address		- Correspondent Router Address
	- Managed Prefix Lists		- Managed Prefix Lists
	The list of Managed Prefix which is notified by the correspondent		The list of Managed Prefix which is notified by the correspondent
	router		router
	5.2. Mobility Header Messages		5.2. Mobility Header Messages
	5.2.1. Binding Update		5.2.1. Binding Update
			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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence # |		| Sequence # |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A|H|L|K|M|R|O| Reserved | Lifetime |		|A|H|L|K|M|R|O| Reserved | Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Mobility options .		. Mobility options .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ORC Flag (O)		ORC Flag (O)
	The flag is used to identify a Binding Update sent		The flag is used to identify a Binding Update sent
	for a correspondent router.		for a correspondent router.
	5.2.2. Binding Acknowledgment		5.2.2. Binding Acknowledgment
			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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Status |K|O| Reserved |		| Status |K|O| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence # | Lifetime |		| Sequence # | Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Mobility options .		. Mobility options .
	. .		. .
	| |		| |
	skipping to change at page 8, line 8 ¶		skipping to change at page 9, line 8 ¶
	5.3.1. Correspondent Router Discovery Request		5.3.1. Correspondent Router Discovery Request
	The Correspondent Router Discovery Request message is used by a		The Correspondent Router Discovery Request message is used by a
	mobile node to discover correspondent routers where correspondent		mobile node to discover correspondent routers where correspondent
	nodes are located. The message format is as follows.		nodes are located. The message format is as follows.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | Reserved |		| Identifier | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
	To be assigned by IANA		To be assigned by IANA
	Code		Code
	0		0
	skipping to change at page 9, line 8 ¶		skipping to change at page 10, line 8 ¶
	5.3.2. Correspondent Router Discovery Reply		5.3.2. Correspondent Router Discovery Reply
	The Correspondent Router Discovery Reply message is used by a		The Correspondent Router Discovery Reply message is used by a
	correspondent router to send lists of correspondent routers		correspondent router to send lists of correspondent routers
	configured at the network in reply to the Correspondent Router		configured at the network in reply to the Correspondent Router
	Discovery Request message. The message format is as follows.		Discovery Request message. The message format is as follows.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | Reserved |		| Identifier | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Preference | Prefix Length |		| Reserved | Preference | Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Correspondent Router Address +		+ Correspondent Router Address +
	| |		| |
	skipping to change at page 13, line 14 ¶		skipping to change at page 14, line 14 ¶
	6.4. Routing to Mobile Network		6.4. Routing to Mobile Network
	Whenever a correspondent router receives packets and query routing		Whenever a correspondent router receives packets and query routing
	table as general router operations, it also searches for binding		table as general router operations, it also searches for binding
	cache for a destination address in the IPv6 header just like any		cache for a destination address in the IPv6 header just like any
	home agent. The correspondent router should select the prefix		home agent. The correspondent router should select the prefix
	longest matched binding and route for the destination. When the		longest matched binding and route for the destination. When the
	correspondent router finds the prefix longest matched binding for the		correspondent router finds the prefix longest matched binding for the
	destination, it must search binding cache database recursively for		destination, it must search binding cache database recursively for
	the next hope address of the binding and must select the last matched		the next hop address of the binding and must select the last matched
	binding for the destination. This recursive operation is aimed to		binding for the destination. This recursive operation is aimed to
	support nested mobility.		support nested mobility.
	Once the correspondent router finds a binding instead of an IGP		Once the correspondent router finds a binding instead of an IGP
	route for outgoing packets, it tunnels the packets directly to the		route for outgoing packets, it tunnels the packets directly to the
	care-of address of the destination according to the registered		care-of address of the destination according to the registered
	binding. For the opposite direction, the mobile router may reverse		binding. For the opposite direction, the mobile router may reverse
	tunnel packets to the correspondent router at correspondent node's		tunnel packets to the correspondent router at correspondent node's
	IGP domain which is found with route of the correspondent router's		IGP domain which is found with route of the correspondent router's
	managed prefixes in mobile router's routing table. The correspondent		managed prefixes in mobile router's routing table. The correspondent
	router then decapsulates packets and route them to a correspondent		router then decapsulates packets and route them to a correspondent
	node. The mobile router does not insert the home address option as		node. The mobile router does not insert the home address option as
	Mobile IPv6, since falsification of mobile network node's packets		Mobile IPv6, since falsification of mobile network node's packets
	on intermediate nodes like the mobile router should be avoided		on intermediate nodes like the mobile router should be avoided
	for security considerations. The encapsulation of packets adds		for security considerations. The encapsulation of packets adds
	additional IPv6 header, and it does not change original packets.		additional IPv6 header, and it does not change original packets.
	7. Support for Nested Mobile Networks		7. Security Consideration
	The optimized route cache protocol allows route optimization in
	nested mobile networks. The route optimization in optimized route
	cache protocol allows bypassing of all HAs which are serving the
	mobile routers in the nested mobile network, and create a direct path
	from the mobile network node to the correspondent node.
	The concept of route optimization in optimized route cache protocol
	is to achieve optimized route between the correspondent router and
	the nested mobile network with only a single tunnel encapsulation,
	together with routing headers, if necssary. The routes for each
	mobile network in the nest are assumed to be exchanged among the
	each mobile routers. This can be done by using a kind of an ad-hoc
	routing protocol, or extending router advertisement messages, as
	described in Appendix C.
	The route optimization is fully controlled and triggered by the sub
	mobile routers for which it's carrying the mobile network, and is
	independent from the root mobile router. In other words, the root
	mobile routers does not need to maintain information of the mobile
	routers attached behind them, for example maintaining binding update
	lists and sending binding update messages on behalf of them.
	8. Security Consideration
	The optimized route cache protocol enables to manage routing		The optimized route cache protocol enables to manage routing
	information across AS boundaries. In other words, it is possible for		information across AS boundaries. In other words, it is possible for
	a mobile router to alter routing table of opposite routers. Wrong		a mobile router to alter routing table of opposite routers. Wrong
	binding registrations will cause opposite ASs to fall into confusion		binding registrations will cause opposite ASs to fall into confusion
	or to have black-hole of routing. The ORC employees Mobile IPv6		or to have black-hole of routing. The ORC employees Mobile IPv6
	security mechanism [5] for protecting binding updates which are the		security mechanism [5] for protecting binding updates which are the
	IPsec authentication header [1] and the return routability scheme.		IPsec authentication header [1] and the return routability scheme.
	Furthermore, recipient routers can apply their IGP domain or AS		Furthermore, recipient routers can apply their IGP domain or AS
	routing policies to handle each binding.		routing policies to handle each binding.
	9. Acknowledgements		8. Acknowledgements
	The authors would like to thank Keisuke Uehara, Susumu Koshiba, Jun		The authors would like to thank Keisuke Uehara, Susumu Koshiba, Jun
	Murai, and WIDE Project for their contributions.		Murai, and WIDE Project for their contributions.
	References		References
	[1] R. Atkinson. IP Authentication Header. Request for Comments		[1] R. Atkinson. IP Authentication Header. Request for Comments
	(Proposed Standard) 1826, Internet Engineering Task Force, August		(Proposed Standard) 1826, Internet Engineering Task Force, August
	1995.		1995.
	skipping to change at page 18, line 25 ¶		skipping to change at page 19, line 25 ¶
	router tunnels the packets to the mobile router.		router tunnels the packets to the mobile router.
	Figure 3 shows the case where the mobile router selects the		Figure 3 shows the case where the mobile router selects the
	correspondent router configured at the leaf network. The		correspondent router configured at the leaf network. The
	correspondent router advertises the proxy route for the mobile router		correspondent router advertises the proxy route for the mobile router
	to other routers in the same network domain. Otherwise, packets		to other routers in the same network domain. Otherwise, packets
	are silently routed to the Internet without interception of the		are silently routed to the Internet without interception of the
	correspondent router. Packets sent to the mobile router are routed		correspondent router. Packets sent to the mobile router are routed
	to one of routers according to the proxy route and then routed to the		to one of routers according to the proxy route and then routed to the
	Correspondent Node		Mobile Router
	+		+
	|		|
	+-----+-------------+		+-----+-------------+
	| Internet |		| Internet |
	+--+------------+---+		+--+------------+---+
	| |		| |
	+-----+--+ +--+-----+		+-----+--+ +--+-----+
	| CR +------+ Router | /32 network		| CR +------+ Router | /32 network
	+-BC--+--+ +--+--PR-+		+-BC--+--+ +--+--PR-+
	Binding Cache / " / " Proxy Route		Binding Cache / " / " Proxy Route
	skipping to change at page 19, line 25 ¶		skipping to change at page 20, line 25 ¶
	prohibits the correspondent router support.		prohibits the correspondent router support.
	Increasing the number of correspondent routers caring the mobile		Increasing the number of correspondent routers caring the mobile
	network is an important factor to optimize routes between a mobile		network is an important factor to optimize routes between a mobile
	node and correspondent nodes as much as possible. By contrast,		node and correspondent nodes as much as possible. By contrast,
	the optimized route cache protocol does not always force to have a		the optimized route cache protocol does not always force to have a
	number of correspondent routers. Binding registrations to all the		number of correspondent routers. Binding registrations to all the
	correspondent routers bring considerable overheads to a mobile router		correspondent routers bring considerable overheads to a mobile router
	and prevents scalability and quickness of movement processing.		and prevents scalability and quickness of movement processing.
	Correspondent Node		Mobile Router
	+		+
	|		|
	+-----+-------------+		+-----+-------------+
	| Internet |		| Internet |
	+--+------------+---+		+--+------------+---+
	| |		| |
	+-----+--+ +--+-----+		+-----+--+ +--+-----+
	| Router +------+ Router | /32 network		| Router +------+ Router | /32 network
	+-PR--+--+ +--+--PR-+		+-PR--+--+ +--+--PR-+
	Proxy Route / " / " Proxy Route		Proxy Route / " / " Proxy Route
	skipping to change at page 20, line 5 ¶		skipping to change at page 21, line 5 ¶
	+---+----+		+---+----+
	| CR | /64 network		| CR | /64 network
	+---+-BC-+		+---+-BC-+
	| Binding Cache		| Binding Cache
	+--+--+--+--+		+--+--+--+--+
	CN CN CN CN CN		CN CN CN CN CN
	Correspondent Nodes		Correspondent Nodes
	Figure 3: Registration to Lower Router		Figure 3: Registration to Lower Router
	C. Route Optimization in Nested Mobile Network		C. Modifications from the last version
	The optimized route cache protocol allows route optimization in
	nested mobile networks. The route optimization in optimized route
	cache protocol allows bypassing of all HAs which are serving the
	mobile routers in the nested mobile network, and create a direct path
	from the mobile network node to the correspondent node.
	In providing such optimized route, we introduce a new mechanism
	called, ``a reflective binding update'', which is sent by the
	correspondent router in reflect to a request for a route optimization
	sent by the sub mobile router. The reflective binding update is
	used to maintain bindings at the correspondent router for the nested
	mobile network.
	Figure 4 shows a simple case where the nested level is two, and the
	correspondent node is located behind the correspondent router. The
	route optimization is fully controlled and triggered by the sub-MR,
	and is independent from the root-MR. Therefore, the root-MR does
	not need to maintain information of the mobile routers attached
	behind them. The correspondent router in the figure can also be a
	mobile router with another mobile router behind it. Even if both
	communicating sides are nested mobile networks, the optimized route
	cache protocol can create an optimized route.
	+-----+ +-----+
	| HA1 | | HA2 | Home Agents
	+--+--+ +--+--+
	| |
	+--+-------------+--+
	| Internet |
	+-+---------------+-+
	| |
	+----+---+ +--+-----+
	root-MR | MR1 | | CR | Correspondent Router
	+-+------+ +------+-+
	| |
	+------+-+ +--+--+--+--+
	sub-MR | MR2 | CN CN CN CN CN
	+----+---+ Correspondent Nodes
	|
	+---+---+---+
	MNN MNN MNN MNN
	Mobile Network Nodes
	Figure 4: Route Optimization in Nested Mobile Networks
	The route optimization is first initialized by the sub-MR when
	receiving a forwarded packet from its home agent. If the sub-MR
	in the nested mobile network decides that route optimization is
	needed, it sends a correspondent router discovery request to the
	correspondent network if necessary, as described in section 4.1. The
	decision can be based on protocols, port numbers, or the amount of
	tunneled packets received from a specific source address.
	After receiving a valid correspondent router discovery reply, the		- remove nested mobile networks support
	sub-MR sends a binding update to the correspondent router, indicating
	a request for a route optimization in the nested mobile network.
	The indication is done with a corresponding flag in the binding
	update message, together with the care of address of the root-MR in
	the binding update message sub-option. The care of address of the
	root-MR is originally notified to the sub-MR by extending the router
	advertisement message sent from the root-MR.
	When the correspondent router receives the binding update message,		- fix a few typo and packet formats
	it returns a binding acknowledgment to the sending mobile router,
	and retrieves the care of address of the root-MR. The correspondent
	router then sends a binding update message to the root-MR for the
	network claimed by the correspondent router. This binding update
	messages is called, ``a reflective binding update''.
	After a successful creation of the bindings between the correspondent		Intellectual Property Statement
	router and the root-MR, packets meant for the mobile network under
	the sub-MR are directly tunneled to the sub-MR at the correspondent
	router, together with the routing header for the root-MR. Likewise,
	packets meant for the correspondent network are directly tunneled to
	the correspondent router with the routing header for the root-MR.
	The router advertisement message sent by the mobile routers should		The IETF takes no position regarding the validity or scope of any
	be extended to support route optimization. Precisely, the router		Intellectual Property Rights or other rights that might be claimed to
	advertisement should include the care of address of the mobile		pertain to the implementation or use of the technology described in
	router's egress interface. If incase the care of address of the		this document or the extent to which any license under such rights
	mobile router changes due to movements, the new care of address		might or might not be available; nor does it represent that it has
	should be advertised with the router advertisement message.		made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	When the sub-MR detects the change of the care of address in the		Copies of IPR disclosures made to the IETF Secretariat and any
	router advertisement message, it should then send a new binding		assurances of licenses to be made available, or the result of an
	update message to the correspondent router. Since invalid binding at		attempt made to obtain a general license or permission for the
	the correspondent router will only cause the packets to go via the		use of such proprietary rights by implementers or users of this
	home agent, it is not critical for operation.		specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Full Copyright Statement		The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided
	others, and derivative works that comment on or otherwise explain it		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	or assist in its implementation may be prepared, copied, published		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	and distributed, in whole or in part, without restriction of any		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	kind, provided that the above copyright notice and this paragraph		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	are included on all such copies and derivative works. However,		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	this document itself may not be modified in any way, such as by		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	removing the copyright notice or references to the Internet Society
	or other Internet organizations, except as needed for the purpose
	of developing Internet standards in which case the procedures
	for copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	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. 45 change blocks.
	191 lines changed or deleted		102 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/