< draft-ng-nemo-access-router-option-00.txt		draft-ng-nemo-access-router-option-01.txt >
	Network Working Group C. W. Ng		NEMO Working Group C. Ng
	Internet-Draft Panasonic Singapore Labs		Internet-Draft Panasonic Singapore Labs
	Expires: April 2003 T. Tanaka		Expires: January 10, 2005 J. Hirano
	Matsushita Communications Ind		Panasonic
			July 12, 2004
	October 2002
	Securing Nested Tunnels Optimization with Access Router Option		Securing Nested Tunnels Optimization with Access Router Option
	draft-ng-nemo-access-router-option-00.txt		draft-ng-nemo-access-router-option-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026 [1].		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			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 that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as
	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 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.
	Abstract		This Internet-Draft will expire on January 10, 2005.
	Through the establishment of bi-directional tunnels between a mobile		Copyright Notice
	router and home agent, global connectivity can be extended to nodes
	within a network in motion. However, the multiple levels of bi-
	directional tunnels in nested mobile networks lead to undesirable
	effects. This memo proposes using a new mobility header option
	called the Access Router Option to allow a mobile router to inform
	its home agent the home-address of the access router it is currently
	attached to. From there, this memo lays out a mechanism that allows
	mobile routers to securely achieve nested tunnels optimization.
	Conventions used in this document		Copyright (C) The Internet Society (2004). All Rights Reserved.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		Abstract
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [2].		Network Mobility (NEMO) Basic Support provides global connectivity to
			mobile network through the establishment of bi-directional tunnels
			between a mobile router and home agent. However, this sub-optimal
			routing, especially when nesting of mobile networks or Mobile IPv6
			(MIPv6) host occurs within a mobile network. This memo proposes
			using a new mobility header option called the Access Router Option to
			allow a mobile node (host/router) to inform its home agent (HA) or
			corespondent node (CN) the home-address (HoA) of the access router it
			is currently attached to. From there, this memo lays out a mechanism
			that allows mobile nodes to securely achieve nested tunnels
			optimization, and even full route optimization.
	Table of Contents		Table of Contents
	1. Introduction...................................................4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terms Used................................................5		1.1 Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Assumptions...............................................5		1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Organization..............................................6		1.3 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Overview of Operation..........................................6		2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
	2.1. Router Advertisement......................................7		2.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 7
	2.2. Binding Update from MR1 to HA1............................7		2.2 Binding Update from MR1 to HA1 . . . . . . . . . . . . . . 7
	2.3. Binding Update from MR2 to HA1............................7		2.3 Binding Update from MR2 to HA1 . . . . . . . . . . . . . . 8
	2.4. Forwarding Packets from HA1 to MR1........................8		2.4 Forwarding Packets from HA1 to MR1 . . . . . . . . . . . . 8
	2.5. Forwarding Packets from MR1 to HA1........................8		2.5 Forwarding Packets from MR1 to HA1 . . . . . . . . . . . . 9
	3. Changes to Existing Protocols..................................9		2.6 Scenario with a Local Fixed Router . . . . . . . . . . . . 9
	3.1. Modifications to Mobile IPv6..............................9		2.7 Route Optimization with Mobile Network Hosts . . . . . . . 10
	3.1.1. Addition of Access Router Option.....................9		3. Changes to Existing Protocols . . . . . . . . . . . . . . . . 12
	3.1.2. Extending Type 2 Routing Header.....................10		3.1 Modifications to NEMO Basic Support / Mobile IPv6 . . . . 12
	3.1.3. Extending Binding Acknowledgement Message...........12		3.1.1 Addition of Access Router Option . . . . . . . . . . . 12
	3.1.4. Modification to Conceptual Data Structures..........12		3.1.2 Extending Type 2 Router Header . . . . . . . . . . . . 13
	3.2. Modifications to IPv6 Neighborhood Discovery.............12		3.1.3 Modification to Conceptual Data Structures . . . . . . 14
	3.2.1. Extension to Router Advertisement...................12		3.2 Modifications to IPv6 Neighbor Discovery . . . . . . . . . 15
	3.2.2. Addition of a New Option in Router Advertisement....13		3.2.1 Addition of New Option in Router Advertisement . . . . 15
	3.3. Extending the Router Alert Option........................14		3.3 Modifications to ICMPv6 . . . . . . . . . . . . . . . . . 16
	4. Operation of NEMO-enabledMobile Router........................15		3.3.1 New Router Global Address ICMP Message . . . . . . . . 16
	4.1. Operation when Mobile Router is at Home..................15		3.4 Extending the Router Alert Option . . . . . . . . . . . . 18
	4.1.1. Sending Router Advertisement........................15		4. Operation of ARO-Enabled Mobile Routers . . . . . . . . . . . 20
	4.1.2. Processing Outbound Packets.........................15		4.1 Operation When Mobile Router is At Home . . . . . . . . . 20
	4.1.3. Processing Inbound Packets..........................16		4.1.1 Sending Router Advertisement . . . . . . . . . . . . . 20
	4.2. Operation when Mobile Router is Away.....................16		4.1.2 Processing Outbound Packets . . . . . . . . . . . . . 20
	4.2.1. Sending Router Advertisement........................16		4.1.3 Processing Inbound Packets . . . . . . . . . . . . . . 20
	4.2.2. Receiving Router Advertisement......................16		4.2 Operation When Mobile Router is Away . . . . . . . . . . . 21
	4.2.3. Sending Binding Updates.............................17		4.2.1 Sending Router Advertisement . . . . . . . . . . . . . 21
	4.2.4. Processing Outbound Packets.........................17		4.2.2 Receiving Router Advertisement . . . . . . . . . . . . 21
	4.2.5. Processing Inbound Packets..........................18		4.2.3 Sending Binding Updates . . . . . . . . . . . . . . . 21
	4.3. IPSec Processing.........................................19		4.2.4 Processing Outbound Packets . . . . . . . . . . . . . 22
	4.3.1. IPSec Processing on Inbound Packets.................19		4.2.5 Processing Inbound Packets . . . . . . . . . . . . . . 23
	4.3.2. IPSec Processing on Outbound Packets................19		4.3 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 24
	5. Operation of NEMO-enabled Home Agent..........................20		4.3.1 IPSec Processing on Inbound Packets . . . . . . . . . 24
	5.1. Sending Router Advertisement.............................20		4.3.2 IPSec Processing on Outbound Packets . . . . . . . . . 24
	5.2. Receiving Binding Updates................................20		5. Operation of ARO-Enabled Home Agents . . . . . . . . . . . . . 25
	5.3. Receiving Tunneled Packets from Away Nodes...............20		5.1 Receiving Binding Updates . . . . . . . . . . . . . . . . 25
	5.4. Tunneling Packets to Away Nodes..........................21		5.2 Receiving Tunneled Packets from Away Nodes . . . . . . . . 25
	5.5. IPSec Processing.........................................23		5.3 Tunneling Packets to Away Nodes . . . . . . . . . . . . . 26
	5.5.1. IPSec Processing on Inbound Packets.................23		5.4 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 28
	5.5.2. IPSec Processing on Outbound Packets................23		5.4.1 IPSec Processing on Inbound Packets . . . . . . . . . 28
	6. Considerations in the Use of Mutable Router Alert Option......24		5.4.2 IPSec Processing on Outbound Packets . . . . . . . . . 28
	6.1. Router Alert Option......................................24		6. Operation of ARO-Enabled Mobile Network Nodes . . . . . . . . 29
	6.2. Example where an Immutable RAO is Used...................24		6.1 Nested Tunnel Optimization with Home Agent . . . . . . . . 29
	6.3. The Need for Mutable RAO.................................26		6.2 Receiving Router Advertisement . . . . . . . . . . . . . . 29
	6.4. Sub-Optimality of NEMO-NFwd RAO..........................26		6.3 Sending Binding Updates . . . . . . . . . . . . . . . . . 29
	6.5. Alternatives to the Mutable Router Alert Option..........27		6.4 Sending Data Packets . . . . . . . . . . . . . . . . . . . 30
	6.5.1. IPv6 Flow Label.....................................27		6.5 Processing Inbound Packets . . . . . . . . . . . . . . . . 30
	6.5.2. New Routing Header Type.............................27		6.6 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 31
	7. Changing Source Address by Intermediate Routers...............28		6.6.1 IPSec Processing on Inbound Packets . . . . . . . . . 31
	7.1. Justifications...........................................28		6.6.2 IPSec Processing on Outbound Packets . . . . . . . . . 31
	7.2. Alternatives.............................................28		7. Operation of ARO-Enabled Correspondent Node . . . . . . . . . 32
	8. Security Considerations.......................................28		7.1 Receiving Binding Updates . . . . . . . . . . . . . . . . 32
	8.1. Addition of Access Router Option.........................28		7.2 Receiving Route Optimized Packets from Mobile Nodes . . . 32
	8.2. Router Global Address Option.............................30		7.3 Sending Route Optimized Packets to Mobile Nodes . . . . . 32
	8.3. Accepting Tunnel with a Source Address not Directly Bound to		7.4 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 33
	the Home Address..............................................30		7.4.1 IPSec Processing on Inbound Packets . . . . . . . . . 33
	8.4. Use of Extended Routing Header Type 2....................31		7.4.2 IPSec Processing on Outbound Packets . . . . . . . . . 33
	8.5. Mutable Router Alert Option..............................32		8. Design Considerations . . . . . . . . . . . . . . . . . . . . 34
	8.6. IPSec Processing.........................................33		8.1 Considerations in the Use of Mutable Router Alert
	8.6.1. Processing of Extended Routing Header Type 2........33		Option . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	8.6.2. Processing of Home Address Destination Option.......33		8.1.1 Overview of Router Alert Option . . . . . . . . . . . 34
	8.6.3. Processing of Mutable Router Alert Option...........34		8.1.2 Example where an Immutable RAO is Used . . . . . . . . 34
	Acknowledgements.................................................34		8.1.3 The Need for Mutable RAO . . . . . . . . . . . . . . . 36
	References.......................................................34		8.1.4 Alternatives to the Mutable Router Alert Option . . . 36
	Author's Addresses...............................................36		8.2 Change of Source Address . . . . . . . . . . . . . . . . . 37
	Appendices.......................................................36		8.2.1 Justifications . . . . . . . . . . . . . . . . . . . . 37
	A. Route Optimization............................................36		8.2.2 Alternatives . . . . . . . . . . . . . . . . . . . . . 38
	B. Other NEMO Solution Proposals.................................37		9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	B.1. IPv6 Reverse Routing Header..............................37		9.1 Addition of Access Router Option . . . . . . . . . . . . . 39
	B.2. Prefix Scope Binding Update (PSBU).......................38		9.2 Router Global Address Option . . . . . . . . . . . . . . . 40
	B.3. Hierarchical Mobile IPv6 (HMIPv6)........................39		9.3 Accepting Tunnel with a Source Address not Directly
	C. Examples......................................................39		Bound to the Home Address . . . . . . . . . . . . . . . . 40
	C.1. Abbreviations............................................39		9.4 Use of Extended Routing Header Type 2 . . . . . . . . . . 41
	C.2. MR1 attaches to MR2......................................40		9.5 Mutable Router Alert Option . . . . . . . . . . . . . . . 42
	C.2.1. MR1 establishes binding to HA1.........................40		9.6 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 43
	C.2.2. LFN1 sends packet to CN1...............................42		9.6.1 Processing of Extended Routing Header Type 2 . . . . . 43
	C.2.3. CN1 sends packet to LFN1...............................44		9.6.2 Processing of Home Address Destination Option . . . . 43
	C.2.4. MR2 establishes binding to HA1.........................46		9.6.3 Processing of Mutable Router Alert Option . . . . . . 43
	C.2.5. LFN1 sends packet to CN1...............................46		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	C.2.6. CN1 sends packet to LFN1...............................47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
	C.3. MR2 moves to new location................................48		A. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 46
	C.3.1. MR2 sends binding update to HA1........................49		Intellectual Property and Copyright Statements . . . . . . . . 47
	Additional References............................................49
	1. Introduction		1. Introduction
	The problem of Network Mobility Support (NEMO) is identified in		This memo describes a proposed solution for provisioning route
	various previous works [3,4,5,6]. In essence, the problem of network		optimization in Network Mobility (NEMO). This solution is built on
	in motion is to provide continuous Internet connectivity to nodes in		top of Mobile IPv6 (MIPv6) [1] and NEMO Basic Support [2][3]. The
	a network that moves as a whole. Nodes within the network that moves		general problem of route optimization in NEMO is analyzed and
	may not be aware of the network changing its point of attachment to		summarized in [4].
	the Internet. This differs from the traditional problem of mobility
	support as addressed by Mobile IPv4 [7] in Internet Protocol version
	4 (IPv4) [8] and Mobile IPv6 [9] in Internet Protocol version 6
	(IPv6) [10].
	This memo describes a proposed solution of NEMO that is based on		The proposed solution described in this memo aims to solve the
	extension of Mobile IPv6 and bi-directional tunneling between the		following route optimizations problems:
	mobile router controlling the mobile network and its home agent
	[11][12]. As described in the NEMO charter, a mobile router, when it
	is in a foreign domain, will set up a bi-directional tunnel with its
	home agent. Here, the home agent will intercept packets destined for
	the subnet controlled by the mobile router and tunnel the packet to
	the mobile router's care-of-address, based on a previous Binding
	Update (possibly Prefix-Scoped Binding Update [12]) sent by the
	mobile router. In addition, the mobile router will encapsulate
	outbound packets to its home agent through the bi-directional tunnel
	for delivery.
	This memo addresses the basic NEMO solution with some route		o Nested Tunnel Optimization
	optimization. It proposes various modifications to some aspects of
	Mobile IPv6 so that problems of bi-directional tunneling that arose
	when other mobile hosts or networks attached themselves to a mobile
	network (thus forming what is called the Nested Mobile Networks) are
	solved. More specifically, the solution described in this document
	attempts to solve the problem of Nested Tunnels Optimization as
	described in [13]. In [14], Thubert et. al. proposed the use of a
	Reverse Type 2 Routing Header to solve the problem of Nested Tunnels
	Optimization. In essence, the proposal requires the first mobile
	router to attach a reverse routing header to the tunnel packet.
	Subsequent mobile routers along the egress path of the packet would
	not further encapsulate the packet. Instead, they will move the
	source address of the incoming packet to the next available entry of
	the reverse routing header, and put their own care-of-address in the
	source address field. In this way, the home agent receiving this
	packet can construct the chain of access routers the mobile router is
	attached to. From there, a packet addressed to the mobile router (or
	to any nodes attached to the ingress interface of the mobile router)
	can be sent with an extended Type 2 Routing Header.
	Security issues is one major problem of the reverse routing header		This optimization problem is to eliminate the nesting of tunnels
	solution, as admitted by Thubert et. al. in their proposal. It is		for a nested mobile network. The proposed solution requires
	the main objective of this memo to propose a relatively secure		changes to the mobile router (MR) and home agent (HA)
	solution to the nested tunnel optimization problem. The solution		implementation so that no matter how many level of nesting a
	proposed here defines a new option in mobility headers specified in		mobile network has, there is only one tunnel between the innermost
	[9]. This new option, called the Access Router Option, is used by		MR and its HA.
	the sender (i.e. the mobile router) to inform the recipient (e.g.
	home agent) the global address of the access router the sender is
	attached to. From the information provided in the Access Router
	Option, the recipient can then construct the chain of access routers
	the sender is attached to. This can be used to construct the
	extended Type 2 Routing Header.
	1.1. Terms Used		o Nested Tunnel Optimization for MIPv6
			This optimization problem is to eliminate the nesting of tunnels
			for a MIPv6 host in a mobile network. The proposed solution
			requires changes to the MR, MIPv6 host, and HA (for both the MR
			and MIPv6 host) implementation so that for a visiting mobile host
			in a mobile network, the only tunnel necessary is the one between
			the MIPv6 host and its HA, without additional encapsulation at the
			MR.
			o MIPv6 over NEMO Optimization
			This optimization problem is to allow the MIPv6 route optimization
			to work between a MIPv6 host in a mobile network (i.e. visiting
			mobile host) and its correspondent node (CN). The proposed
			solution requires changes to the MR, MIPv6 host, and CN
			implementation so that a visiting mobile host in a mobile network
			can perform route optimization with a CN, without any tunneling
			back to the home agents of either the MIPv6 host or MR.
			Various different proposals have been submitted to the NEMO Working
			Group to solve different aspects of the route optimization problem of
			network mobility. Readers are encouraged to look at
			<http://www.mobilenetworks.org/nemo/> for a complete list of Internet
			Drafts that have been published.
			1.1 Terms Used
	It is assumed that readers are familiar with the NEMO terminology		It is assumed that readers are familiar with the NEMO terminology
	described in [15], and the terms described in [13]. In addition, a		described in [5] and those defined in [4]. In addition, [4] also
	detailed description of the problem of nested tunnels optimization is		presents a detailed description of the problem of route optimization
	given in Section 2 of [13]. It will not be duplicated in this memo.		in NEMO.
	Apart from the terms described in [15] and [13], we further define		Apart from the terms described in [5] and [4], we further define the
	the following terminology:		following terminology:
	Access Router (AR)		Access Router (AR)
	Any router that is the point of attachment to the Internet of		Any router that is the point of attachment to the Internet of one
	one or more visiting mobile node (VMN). We use the phrase		or more visiting mobile node (VMN). We use the phrase "access
	"access router of node X" to loosely refer to the router a		router of node X" to loosely refer to the router a node X attaches
	node X attaches to. An access router can be a mobile router		to. An access router can be a MR.
	(MR).
	Proposed NEMO Solution, NEMO-enabled		ARO-Solution, ARO-enabled
	To aid our illustration, we refer to the solution proposed in		To aid our illustration, we refer to the solution proposed in this
	this memo as the "Proposed NEMO Solution". Any network nodes		memo as the "ARO-Solution". Any network nodes that implements the
	that implements the "Proposed NEMO Solution" is referred to as		"ARO-Solution" is referred to as a "ARO-enabled" node.
	a "NEMO-enabled" node.
	1.2. Assumptions		1.2 Organization
	This memo makes the following assumptions:		In this memo, we first begin in Section 2 by giving a general
			overview of the proposed ARO Solution in operation. This is followed
			by a detailed description of the modifications to existing protocols
			in Section 3. Following which, the operation of each entity: mobile
			router, home agent, mobile network node, and correspondent node that
			support the ARO Solution are detailed respectively from Section 4
			through Section 7. In Section 8, we list some of the design
			considerations when formulating the ARO Solution. Finally, security
			considerations in discussed in Section 9.
	(1) A mobile router has only one active egress interface, and thus		1.3 Change Log
	only one home-address and primary care-of-address at any point
	in time.
	(2) All mobile routers in a NEMO are assumed to be NEMO-enabled.		o Changes from version -00 to -01
	Local Fixed Routers (LFR) are assumed to be not NEMO-enabled.
	(3) All home agents of mobile routers are assumed to be NEMO-enabled.		* Extended solution to be able to optimized over local fixed
			router with inclusion of NEMO-BU RAO
	The first assumption precludes multi-homed mobile networks. We are		* Inclusion of NEMO-BU RAO and a new ICMPv6 message
	currently analyzing the proposed solution to understand its
	applicability to multi-homed NEMO.
	1.3. Organization		* Extended solution for optimization between MR and CN
	In the remaining portions of this memo, we will first describe an		* Extended solution for optimization between VMN and CN/HA
	overview of the operation in Section 2. Following which, Section 3
	will list the modifications to existing protocols this memo proposes
	in detail. The operations of mobile routers and home agents are
	described separately in Sections 4 and 5. Section 6 discusses some
	design considerations leading to the proposal of a mutable router
	alert option, and Section 7 argues the case of allowing intermediate
	routers to change the source address of a packet. Finally, Section 8
	presents the security considerations.
	Three appendices are attached at the end of this document. Appendix		* Included operations of CN and VMN
	A discusses the possibility of extending the proposal described in
	this memo to achieve full router optimization. Appendix B compares
	the proposal described in this memo to other proposed solutions for
	NEMO. Appendix C describes an example to illustrate how the solution
	proposed in this memo works.
	2. Overview of Operation		2. Overview of Operation
	This section gives an overview of the operation of the proposed		This section gives an overview of the operation of the proposed
	solution. We use the scenario illustrated in Figure 1 below as an		solution. We use the scenario illustrated in Figure 1 below as an
	example to describe the operation of the proposed solution.		example to describe the operation of the ARO-solution.
	HA1		HA1
	|		|
	+---------|---------+		+---------|---------+
	| |		| |
	LFN1---MR1---MR2---- Internet ----CN1		LFN1---MR1---MR2---- Internet ----CN1
	| |		| |
	+---------|---------+		+---------|---------+
	|		|
	HA2		HA2
	Figure 1: Example Scenario		Figure 1: Example Scenario
	In Figure 1, LFN1 is a local fixed node attached to the ingress		In Figure 1, LFN1 is a local fixed node attached to the ingress
	interface of the visiting mobile router (VMR) MR1. MR1 is itself		interface of the visiting mobile router (VMR) MR1. MR1 is itself
	attached to the ingress interface of another mobile router, MR2. HA1		attached to the ingress interface of another mobile router, MR2. HA1
	is the home agent of MR1, and HA2 is the home agent of MR2. LFN1 is		is the home agent of MR1, and HA2 is the home agent of MR2. LFN1 is
	communicating with a correspondent node CN1.		communicating with a correspondent node CN1.
	2.1. Router Advertisement		2.1 Router Advertisement
	When MR1 first obtains a Router Advertisement (RA) from MR2, it		When MR1 first obtains a Router Advertisement (RA) from MR2, it
	checks if MR2 supports the Proposed NEMO Solution. This is		checks if MR2 supports the ARO-Solution. This is determined by an
	determined by a bit flag in the RA message. In the RA message, NEMO-		additional option (known as Router Global Address Option, or RGAO)
	enabled routers should include an option to advertise their home-		that advertises the home-address (HoA) of MR2.
	address as well.
	2.2. Binding Update from MR1 to HA1		2.2 Binding Update from MR1 to HA1
	After MR1 obtains a care-of-address (CoA), it sends Binding Update		After MR1 obtains a care-of-address (CoA), it sends Binding Update
	(BU) to its home agent, HA1. The BU message contains an important		(BU) to its home agent, HA1. The BU message, beside having the
			prefix informations as detailed in [2], also contains an important
	extension, known as the "Access Router Option" (ARO). This ARO		extension, known as the "Access Router Option" (ARO). This ARO
	specifies the global address of MR2, thus informing HA1 the access		specifies the global address of MR2, thus informing HA1 the access
	router MR1 is currently attached to. In this case, since MR2 is		router MR1 is currently attached to. In this case, since MR2 is
	itself a mobile router, the global address is the home-address (HoA)		itself a mobile router, the global address is the HoA of MR2.
	of MR2.
	HA1 records this together with the binding update entry in its		HA1 records this together with the binding update in the
	binding cache. When returning the Binding Acknowledgement (BA), HA1		corresponding binding cache entry (BCE). When returning the Binding
	can then made use of the extended Type 2 Routing Header (RH2) to		Acknowledgment (BA), HA1 can then made use of the extended Type 2
	forward the BA message to MR1 via the HoA of MR2. Here, the RH2 as		Routing Header (RH2) to forward the BA message to MR1 via the HoA of
	defined by Mobile IPv6 specification [9] is extended so that it can		MR2. Here, the RH2 as defined by Mobile IPv6 specification [1] is
	store more than one address.		extended so that it can store more than one address. In addition,
			HA1 should insert the same ARO in BA message to indicate that the BU
			with ARO is accepted.
	Since the BA message is addressed to the HoA of MR2, the BA message		Since the BA message is addressed to the HoA of MR2, the BA message
	will be intercepted by HA2. Here, we assume that the binding cache		will be intercepted by HA2. Here, we assume that the BCE of HA2
	entry of HA2 contains a binding of the current CoA and HoA of MR2.		contains a binding of the current CoA and HoA of MR2. Thus, HA2 will
	Thus, HA2 will tunnel the packet to the CoA of MR2. When MR2		tunnel the packet to the CoA of MR2. When MR2 receives and
	receives and decapsulates the BA message, it notices that there is an		decapsulates the BA message, it notices that there is an extended
	extended RH2. It proceeds to swap the destination address with the		RH2. It proceeds to swap the destination address with the
	appropriate entry in the RH2 (which should be the CoA of MR1), and		appropriate entry in the RH2 (which should be the CoA of MR1), and
	forward it to MR1. MR1 receives the packet, verifies that it is the		forward it to MR1. MR1 receives the packet, verifies that it is the
	final destination of the packet, and consumes the BA message.		final destination of the packet, and consumes the BA message.
	2.3. Binding Update from MR2 to HA1		2.3 Binding Update from MR2 to HA1
	From the processing of the extended RH2 as described previously, MR2		From the processing of the extended RH2 as described previously, MR2
	can deduce the following two facts:		can deduce the following two facts:
	(1) the sender (i.e. HA1) does not have a binding cache entry of		1. the sender (i.e. HA1) does not have a BCE of MR2's current CoA,
	MR2's current CoA, since the received packet is encapsulated in		since the received packet is encapsulated in a tunnel from HA2,
	a tunnel from HA2, and		and
	(2) HA1 is NEMO-enabled, since an extended RH2 is used.		2. HA1 is ARO-enabled, since an extended RH2 is used.
	Having established these, MR2 may then send a BU to HA1. In this		Having established these, MR2 may then send a BU to HA1. In this
	case, HA1 is treated as a correspondent node from the perspective of		case, HA1 is treated as a correspondent node from the perspective of
	MR2. Thus, the Return Routability (RR) Test specified in [9] must be		MR2. Thus, the Return Routability (RR) procedure specified in [1]
	carried out before sending the BU message. Once the binding update		must be carried out before sending the BU message. Note also that
	is successful, MR2 should add the host address of HA1 to a locally		since HA1 is treated as a correspondent node, MR2 should not insert
	maintained Binding Update List. This list contains a list of hosts		any prefix information (i.e. Mobile Network Prefix Option [2]) in
	that have an active binding cache entry of MR2's current CoA.		the BU message. Once the binding update is successful, MR2 should
			add the host address of HA1 to a locally maintained Binding Update
			List. This list contains a list of hosts that have an active binding
			cache entry of MR2's current CoA.
	Note that if the access router (fixed or mobile) of MR2 is NEMO-		Note that if the access router (fixed or mobile) of MR2 is ARO-
	enabled, MR2 should add an ARO in the BU it sent to HA1 to inform HA1		enabled, MR2 should add an ARO in the BU it sent to HA1 to inform HA1
	the global address of the access router MR2 is currently attached to.		the global address of the access router MR2 is currently attached to.
	To simply our description, we assume that this is not the case.		To simply our description, we assume that this is not the case.
	2.4. Forwarding Packets from HA1 to MR1		2.4 Forwarding Packets from HA1 to MR1
	After receiving the BU message from MR2, the bi-directional tunnel		After receiving the BU message from MR2, the bi-directional tunnel
	between HA1 and MR1 need not go through the tunnel between HA2 and		between HA1 and MR1 need not go through the tunnel between HA2 and
	MR2. Instead, tunnel packets from HA1 to MR1 can be sent directly to		MR2. Instead, tunnel packets from HA1 to MR1 can be sent directly to
	the CoA of MR2 with an attached extended RH2.		the CoA of MR2 with an attached extended RH2.
	As an illustration, suppose CN1 now sends a packet to LFN1. The		As an illustration, suppose CN1 now sends a packet to LFN1. The
	packet will be intercepted by HA1. HA1 checks its routing table and		packet will be intercepted by HA1. HA1 checks its routing table and
	notices that the packet should be forwarded to MR1. However, a check		notices that the packet should be forwarded to MR1. However, a check
	of its binding cache reveals that MR1 is away. Hence, HA1 needs to		of its binding cache reveals that MR1 is away. Hence, HA1 needs to
	tunnel the packet to the current CoA of MR1. Furthermore, HA1 knows		tunnel the packet to the current CoA of MR1. Furthermore, HA1 knows
	that MR1 is currently attached to MR2, and HA1 has a binding cache		that MR1 is currently attached to MR2, and HA1 has a BCE of MR2.
	entry of MR2. Thus, the tunnel should be configured, with an		Thus, the tunnel should be configured, with an extended RH2, such
	extended RH2, such that it reaches CoA of MR1 via CoA MR2. In this		that it reaches CoA of MR1 via CoA MR2. In this case, the
	case, the destination address of the outer packet is set to the CoA		destination address of the outer packet is set to the CoA of MR2, and
	of MR2, and the entries in the RH2 are the CoA and HoA of MR1, in		the entries in the RH2 are the CoA and HoA of MR1, in that order.
	that order. When MR2 receives such a packet, it updates the RH2		When MR2 receives such a packet, it updates the RH2 (i.e. swap the
	(i.e. swap the destination address with the next entry in the RH2),		destination address with the next entry in the RH2), and forward the
	and forward the packet to the new destination (i.e. CoA of MR1). MR1		packet to the new destination (i.e. CoA of MR1). MR1 upon receiving
	upon receiving the packet will verify that it is the final		the packet will verify that it is the final destination of the outer
	destination of the outer packet, and decapsulates the packet. The		packet, and decapsulates the packet. The inner packet is addressed
	inner packet is addressed to LFN1, a valid address in the subnet of		to LFN1, a valid address in the subnet of MR1. Hence, MR1 forwards
	MR1. Hence, MR1 forwards the packet to its appropriate ingress		the packet to its appropriate ingress interface.
	interface.
	2.5. Forwarding Packets from MR1 to HA1		2.5 Forwarding Packets from MR1 to HA1
	When LFN1 sends a packet to CN1, MR1 will encapsulate the packet to		When LFN1 sends a packet to CN1, MR1 will encapsulate the packet to
	be sent through the reverse tunnel with its home agent HA1. The		be sent through the reverse tunnel with its home agent HA1. The
	external packet is appended with a mutable Router Alert Option (RAO)		outer packet is appended with a mutable Router Alert Option (RAO)
	[16], in addition to the Home Address destination Option (HAO). This		[6], in addition to the Home Address destination Option (HAO). This
	RAO requests upstream routers that support the Proposed NEMO Solution		RAO requests upstream routers that are ARO-enabled to forward packet
	to forward packet directly to the destination. When MR2 receives		directly to the destination. When MR2 receives this packet and
	this packet and noticed the RAO, it checks if it has a binding update		noticed the RAO, it checks if it has a binding update with the
	with the specified destination (from its Binding Update List). If		specified destination (from its Binding Update List). If so, it
	so, it changes the source address to its CoA and sends the packet to		changes the source address to its CoA and sends the packet to the
	the destination. Else, the packet is tunneled to HA2, i.e. normal		destination. Else, the packet is tunneled to HA2, i.e. normal
	reverse tunneling between MR2 and HA2. For the latter case, MR2		reverse tunneling between MR2 and HA2. For the latter case, MR2
	might want to send a BU message to the destination (i.e. HA1) so that		might want to send a BU message to the destination (i.e. HA1) so
	subsequent packets can be forwarded directly to the destination		that subsequent packets can be forwarded directly to the destination
	(without going through an additional level of encapsulation).		(without going through an additional level of encapsulation).
	When HA1 receives an encapsulated packet, it verifies that the outer		When HA1 receives an encapsulated packet, it verifies that the outer
	packet originated from authentic source. This is done by checking		packet originated from authentic source. This is done by checking
	that the originator (that is specified by the HAO) has a binding		that the originator (that is specified by the HAO) has a BCE that
	entry that indicates the mobile router identified by the source		indicates the mobile router identified by the source address is a
	address is a valid access router of the originator. HA1 then		valid access router of the originator. HA1 then overwrites the
	overwrites the source address with the HoA specified in HAO and		source address with the HoA specified in HAO and processes it as per
	processes it as per Mobile IPv6 specifications [9].		MIPv6 specifications [1].
	A detail example showing the sequence of message exchange can be		Section 4 describes in greater detail the operation of an ARO-enabled
	found in Appendix C.		mobile router, and Section 5 describes the operation of an
			ARO-enabled home agent.
			2.6 Scenario with a Local Fixed Router
			The ARO-Solution is designed such that it will work even across a non
			ARO-enabled router, such as in the case where there is a local fixed
			router in between two ARO-enabled MR. Figure 2 show the scenario
			with a non ARO-enabled router LFR1 in between MR1 and MR2. Again,
			HA1 and HA2 are the home-agents of MR1 and MR2 respectively. LFR1
			simply route packets between its ingress and egress interfaces, and
			does not do any reverse tunneling.
			HA1
			|
			+---------|---------+
			| |
			LFN1---MR1---LFR1---MR2---- Internet ----CN1
			| |
			+---------|---------+
			|
			HA2
			Figure 2: Example Scenario with a LFR
			The problem here is that although MR2 advertises its HoA in the RA
			messages it broadcast, LFR1 being non ARO-enabled will ignore such
			information. Also, MR1 will not see any RGAO in the RA messages
			broadcasted by LFR1. Thus MR1 will not add in any RAO in the tunnel
			packet to HA1, and hence MR2 will not attempt to send BU to HA1.
			This will result in all packets sent between LFN1 and CN1 to go
			through two levels of encapsulation.
			To overcome this problem, when an ARO-enabled mobile router (eg MR1)
			does not detect its access router to be ARO-enabled, it should try to
			determine if there is any ARO-enabled router in its upstream. This
			is done by adding a new RAO in the initial BU message it sent to its
			HA. Any upstream ARO-enabled router (eg MR2) will detect this RAO,
			and respond to MR1 with an ICMP message conveying its global address.
			This way, MR1 can immediately send a new BU with the global address
			of the MR2 in the ARO. This imply that for the purpose of route
			optimization, MR1 treats MR2 as its access router.
			2.7 Route Optimization with Mobile Network Hosts
			The same mechanism can be extended to be used between a MIPv6 mobile
			host and its home agent or correspondent node (CN). Here, the MIPv6
			host needs to extract the RGAO from the RA messages it receives from
			its access router, and insert the ARO in the BU messages it sent to
			its HA or CN. After a successful binding, data packets sent from the
			mobile host can be prepend with a RAO to request upstream routers to
			attempt to route packets directly to the destination. The RAO can be
			inserted when tunneling a packet back to its HA, or inserted when the
			packet is sent directly to the CN using MIPv6 route optimization
			mechanism. In this way, a visiting mobile host (VMH) can perform
			route optimization over NEMO.
			When attempting to use ARO-Solution for full route optimization with
			a CN, the mobile host must first determine if the CN is ARO-enabled.
			One possible way of such capability detection is to send a BU with
			the ARO, and check if the BA returned contains the same ARO. An
			ARO-enabled CN would return a BA with the same ARO found in a BU
			message.
			Section 6 describes in greater detail the operation of an ARO-enabled
			mobile node, and Section 7 describes the operation of an ARO-enabled
			correspondent node.
	3. Changes to Existing Protocols		3. Changes to Existing Protocols
	3.1. Modifications to Mobile IPv6		3.1 Modifications to NEMO Basic Support / Mobile IPv6
	3.1.1. Addition of Access Router Option		3.1.1 Addition of Access Router Option
	The Access Router Option (ARO) is a new option for Mobility Header		The Access Router Option (ARO) is a new option for Mobility Header
	defined in Mobile IPv6. Its format is shown below.		defined in Mobile IPv6 and NEMO Basic Support. Its format is shown
			below.
	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 = TBA | Length = 16 |		| Type = TBA | Length = 16 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Access Router Address +		+ Access Router Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Figure 3: Access Router Option
	8-bit identifier of the Mobility Header option type. The value		Type
	that identifies an Access Router Option is yet to be assigned.
	Length		8-bit identifier of the Mobility Header option type. The value
			that identifies an Access Router Option is yet to be assigned.
	8-bit unsigned integer that specifies the length of the		Length
	mobility option in octets, excluding Type and Length fields.
	Always 16 for the Access Router Option.
	Access Router Address		8-bit unsigned integer that specifies the length of the mobility
			option in octets, excluding Type and Length fields. Always 16 for
			the Access Router Option.
	Global address of the access router that the sender is		Access Router Address
	currently attached to.
	The Access Router Option is only valid in a Binding Update message.		Global address of the access router that the sender is currently
	The purpose of this option is to inform the recipient that the sender		attached to.
	is currently attached to the specified access router. Using this
			The Access Router Option is only valid in a BU and BA message. The
			purpose of this option is to inform the recipient that the sender is
			currently attached to the specified access router. Using this
	information, recipient can route packets to the sender via the access		information, recipient can route packets to the sender via the access
	router by making use of extended Type 2 Routing Header. Section 8.1		router by making use of extended Type 2 Routing Header. Section 9.1
	addresses some security considerations on the use of the Access		addresses some security considerations on the use of the Access
	Router Option.		Router Option.
	3.1.2. Extending Type 2 Routing Header		3.1.2 Extending Type 2 Router Header
	The Type 2 Routing Header (RH2) is now extended such that it can		The Type 2 Routing Header (RH2) is now extended such that it can
	contain more than one entry. This extension makes it more similar to		contain more than one entry. This extension makes it more similar to
	the type 0 routing header. The format of the modified Type 2 Routing		the type 0 routing header. The format of the modified Type 2 Routing
	Header is shown below.		Header is shown below.
	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 |
	skipping to change at page 11, line 4 ¶		skipping to change at page 13, line 42 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Address [n] +		+ Address [n] +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header
	8-bit selector. Identifies the type of header immediately		Figure 4: Extended Type 2 Routing Header
	following the Routing Header. Uses the same value as the IPv6
	Next Header field [10].
	Hdr Ext Len		Next Header
	8-bit unsigned integer. Length of the routing header in 8-		8-bit selector. Identifies the type of header immediately
	octet units, not including the first 8 octets. This value is		following the Routing Header. Uses the same value as the IPv6
	always equal to twice the number of addresses in the Address		Next Header field [7].
	vector.
	Routing Type		Hdr Ext Len
	8-bit unsigned integer that contains the value 2.		8-bit unsigned integer. Length of the routing header in 8- octet
			units, not including the first 8 octets. This value is always
			equal to twice the number of addresses in the Address vector.
	Segments Left		Routing Type
	8-bit unsigned integer. Number of route segments remaining;		8-bit unsigned integer that contains the value 2.
	i.e. number of explicitly listed intermediate nodes still to be
	visited before reaching its final destination.
	Address[1..n]		Segments Left
	Vector of 128-bit addresses, numbered 1 to n.		8-bit unsigned integer. Number of route segments remaining; i.e.
			number of explicitly listed intermediate nodes still to be visited
			before reaching its final destination.
			Address[1..n]
			Vector of 128-bit addresses, numbered 1 to n.
	This routing header is used by the sender to direct the packet to the		This routing header is used by the sender to direct the packet to the
	mobile node via a sequence of routers. The addresses of the sequence		mobile node via a sequence of routers. The addresses of the sequence
	of routers are placed in the order of visit to the Address[1..n]		of routers are placed in the order of visit to the Address[1..n]
	vector. The last address, Address[n], must be the HoA of the		vector. The last address, Address[n], must be the HoA of the
	intended recipient. Note also that Hdr Ext Len field must always		intended recipient. Note also that Hdr Ext Len field must always
	contain an even number.		contain an even number.
	Each mobile router that receives a packet with the Type 2 Routing		Each MR that receives a packet with the Type 2 Routing Header and the
	Header and the destination field equals to its address must checked		destination field equals to its address must checked if Segments Left
	if Segments Left field is equal to 1. If yes, the last address in		field is equal to 1. If yes, the last address in the Address[]
	the Address[] vector must be its HoA. Else the packet is discarded.		vector must be its HoA. Else the packet is discarded. If
	If Segments-Left is non-zero, it decrements the Segment-Left field,		Segments-Left is non-zero, it decrements the Segment-Left field, and
	and swaps the destination field with the next address in the		swaps the destination field with the next address in the Address[]
	Address[] vector. To work out which address to swap, the mobile		vector. To work out which address to swap, the MR can divide the Hdr
	router can divide the Hdr Ext Len field by 2 (which gives the number		Ext Len field by 2 (which gives the number of entries in Address[]
	of entries in Address[] vector), and subtract Segment Left from it.		vector), and subtract Segment Left from it.
	The extended Type 2 Routing Header is a mutable but predictable IPv6		The extended Type 2 Routing Header is a mutable but predictable IPv6
	header. Thus IP Security (IPSec) [17] protocols such as		header. Thus IP Security (IPSec) [8] protocols such as
	Authentication Header (AH) [18] and Encapsulating Security Payload		Authentication Header (AH) [9] and Encapsulating Security Payload
	(ESP) [19] can be used with the routing header. Security		(ESP) [10] can be used with the routing header. Security
	considerations on the extension of Type 2 Routing Header are		considerations on the extension of Type 2 Routing Header are
	presented in Section 8.4.		presented in Section 9.4.
	3.1.3. Extending Binding Acknowledgement Message
	The Status field of the Binding Acknowledgement (BA) message is
	extended to include an addition status code of value to be assigned.
	The assigned value (hereafter referred to as ARO-OK) must be less
	than 128 and non-zero, to indicate that the Binding Update and Access
	Router Option is accepted. All nodes that support the Proposed NEMO
	Solution must use this new success Status code if the corresponding
	Binding Update message contains an Access Router Option. All nodes
	that do not understand the Access Router Option should continue to
	use the 0 Status code. Recipient of the Binding Acknowledgement can
	then determine from the Status code if the Access Router Option is
	accepted.
	3.1.4. Modification to Conceptual Data Structures
	In Mobile IPv6 [9], the Binding Cache data structure is defined to
	contain entries of home-address to care-of-address bindings. This
	Proposed NEMO Solution extends the each Binding Cache entry to
	contain an additional field known as the Access Router Address. This
	field is used to store the global address of the access router
	specified in the Access Router Option in a Binding Update message.
	When updating the Binding Cache entry, the Access Router Address
	field is overwritten with the address specified in the Access Router
	Option. If the Access Router Option is absent, the Access Router
	Address field should be marked to be invalid.
	3.2. Modifications to IPv6 Neighborhood Discovery		3.1.3 Modification to Conceptual Data Structures
	3.2.1. Extension to Router Advertisement		In Mobile IPv6 [1], the Binding Cache data structure is defined to
			contain entries of HoA to CoA bindings. NEMO Basic Support [2]
			suggested the extension of each BCE to contain information on
			prefixes injected by mobile routers. This ARO-Solution further
			extends each BCE to contain an additional field known as the Access
			Router Address. This field is used to store the global address of
			the access router specified in the Access Router Option in a Binding
			Update message.
	A single bit flag is added to the Router Advertisement specified in		When updating the BCE, the Access Router Address field is overwritten
	IPv6 Neighbor Discovery [20] so that a sender can advertise to the		with the address specified in the Access Router Option. If the
	recipients it is a router capable of supporting the Proposed NEMO		Access Router Option is absent, the Access Router Address field
	Solution. Here an N bit is introduced, thus reducing the reserved		should be marked to be invalid.
	bits to 4. When N=0, the router sending this advertisement is not
	NEMO capable, and when N=1, the router sending this advertisement is
	NEMO capable.
	0 1 2 3		3.2 Modifications to IPv6 Neighbor Discovery
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options ...
	+-+-+-+-+-+-+-+-+-+-+-+-
	3.2.2. Addition of a New Option in Router Advertisement		3.2.1 Addition of New Option in Router Advertisement
	A new option, Router Global Address Option (RGAO) is defined here.		A new option, Router Global Address Option (RGAO) is defined here.
	This new option can only appear in a Router Advertisement message,		This new option can only appear in a Router Advertisement message,
	its format is defined below.		its format is defined below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 13, line 41 ¶		skipping to change at page 15, line 40 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Router Global Address +		+ Router Global Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Figure 5: Router Global Address Option
	8-bit identifier to identify the type of the option. The value		Type
	used to identify the Router Global Address Option is yet to be
	assigned.
	Length		8-bit identifier to identify the type of the option. The value
			used to identify the Router Global Address Option is yet to be
			assigned.
	8-bit unsigned integer that gives the length of the option in		Length
	8-octet units. Always equals to 3 for the Router Home Address
	Option.
	Router Global Address		8-bit unsigned integer that gives the length of the option in
			8-octet units. Always equals to 3 for the Router Global Address
			Option.
	128-bit address. Contains the global address of the egress		Router Global Address
	interface of the sender. Should the sender be a mobile router,
	this global address is the home-address of the sender.		128-bit address. Contains the global address of the egress
			interface of the sender. Should the sender be a mobile router,
			this global address is the home-address of the sender.
	This option allows the sender to advertise its egress interface		This option allows the sender to advertise its egress interface
	global address to nodes attached to its ingress interface(s). This		global address to nodes attached to its ingress interface(s). This
	allows mobile nodes to include an Access Router Option when sending		allows mobile nodes to include an Access Router Option when sending
	Binding Updates. In addition, it is speculated that the global		BU. Inclusion of this option in a RA message would imply the sender
	address of the sender may prove to be useful for fast handover		is ARO-enabled.
	operations.
	Security considerations for the Router Global Address Option are		Security considerations for the Router Global Address Option are
	listed in Section 8.2. According to Section 4.2 of RFC2461[20],		listed in Section 9.2. According to Section 4.2 of IPv6 Neighbor
	receivers that do not understand this new option MUST silently ignore		Discovery [11], receivers that do not understand this new option MUST
	the option and continue processing the Router Advertisement message.		silently ignore the option and continue processing the Router
			Advertisement message.
	3.3. Extending the Router Alert Option		3.3 Modifications to ICMPv6
	The router alert option [16] has the following format:		3.3.1 New Router Global Address ICMP Message
			A new ICMP message to convey the global address of a mobile router is
			needed in the ARO-Solution. This message, called the Router Global
			Address Message, has a format as defined below.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Code | CheckSum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Router Global Address +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 6: Router Global Address ICMP Message
			Type
			8-bit identifier to identify the type of the ICMP Message. The
			value used to identify the Router Global Address Message is yet to
			be assigned.
			Code
			8-bit unsigned integer that gives the finer granularity on message
			type differentiation. Set to 0 for the Router Global Address
			Message.
			CheckSum
			8-bit ICMP Checksum (see [12]
			Router Global Address
			128-bit address. Contains the global address of the egress
			interface of the sender. Should the sender be a mobile router,
			this global address is the home-address of the sender.
			This message is sent when a ARO-enabled router intercepts a packet
			from its ingress interface containing a NEMO-BU RAO. This occurs
			when a nested MR does not know its access router's global address,
			and is attempting to learn its access router's global address. The
			ARO-enabled router intercepting such a packet would send the Router
			Global Address ICMP message to the source, revealing its global
			address (or home-address if the ARO-enabled router is also a mobile
			router).
			3.4 Extending the Router Alert Option
			The router alert option [6] 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |		|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 7: Router Alert Option
	The first three bits of the first byte are zero and the value 5 in		The first three bits of the first byte are zero and the value 5 in
	the remaining five bits is the Hop-by-Hop Option Type number. By		the remaining five bits is the Hop-by-Hop Option Type number. By
	zeroing all three, this specification requires that nodes not		zeroing all three, this specification requires that nodes not
	recognizing this option type should skip over this option and		recognizing this option type should skip over this option and
	continue processing the header, and that the option must not change		continue processing the header, and that the option must not change
	en route.		en route.
	In this memo, we require the value field to be mutable en-route.		In this memo, we require the value field to be mutable en-route.
	Specifically, the mobile router that is not attached to a NEMO-		Specifically, the router that is not attached to a ARO- enabled
	enabled access router will change the value code. Thus, this memo		access router will change the value code. Thus, this memo propose a
	propose a mutable Router Alert Option, of the following format:		mutable Router Alert Option, of 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 1|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |		|0 0 1|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 8: Mutable Router Alert Option
	The first two bits of the first byte are zero, the third bit is 1 and		The first two bits of the first byte are zero, the third bit is 1 and
	the value 5 in the remaining five bits. Thus the Hop-by-Hop Option		the value 5 in the remaining five bits. Thus the Hop-by-Hop Option
	Type number is 0x25 (hexidecimal). By zeroing the first two bits,		Type number is 0x25 (hexadecimal). By zeroing the first two bits,
	this memo requires that nodes not recognizing this option type should		this memo requires that nodes not recognizing this option type should
	skip over this option and continue processing the header.		skip over this option and continue processing the header.
	The Value code in the mutable Router Alert Option is extended to		The Value code in the mutable Router Alert Option is extended to
	contain two extra values to be assigned. For purpose of description,		contain three extra values to be assigned. For purpose of
	we call these two values the NEMO-Forward and NEMO-No-Forward.		description, we call these values the NEMO-Forward, NEMO-No-Forward,
	Hereafter, mutable Router Alert Option with Value code equal to NEMO-		and NEMO-BU. Hereafter, mutable Router Alert Option with Value code
	Forward will be known as a NEMO-Forward Router Alert Option, or		equal to NEMO- Forward will be known as a NEMO-Forward Router Alert
	simply, NEMO-Fwd RAO, and mutable Router Alert Option with Value code		Option, or simply, NEMO-Fwd RAO; mutable Router Alert Option with
	equal to NEMO-No-Forward will be known as a NEMO-No-Forward Router		Value code equal to NEMO-No-Forward will be known as a
	Alert Option, or simply, NEMO-NFwd RAO.		NEMO-No-Forward Router Alert Option, or simply, NEMO-NoFwd RAO; and
			mutable Router Alert Option with Value code equal to NEMO-BU will be
			known as a NEMO-BU Router Alert Option, or simply, NEMO-BU RAO.
	Intermediate routers that support the Proposed NEMO Solution should		Intermediate routers that support the ARO-Solution should recognize
	recognize the NEMO-Fwd RAO and attempt to forward the packet directly		the NEMO-Fwd RAO and attempt to forward the packet directly to the
	to the destination without using a reverse tunnel. If necessary, the		destination without using a reverse tunnel. If necessary, the router
	router can change the source address of the packet to the current		can change the source address of the packet to the current CoA of the
	care-of-address of the router in order to pass through ingress		router in order to pass through ingress filters of subsequent
	filters of subsequent routers/gateways.		routers/gateways.
	Intermediate routers that support the Proposed NEMO Solution should		Intermediate routers that support the ARO-Solution should recognize
	recognize the NEMO-No-Fwd RAO, and behave as if the RAO is not		the NEMO-NoFwd RAO, and behave as if the RAO is not present.
	present. Specifically, the router MUST NOT change the source address		Specifically, the router MUST NOT change the source address of the
	of the packet.		packet.
	Section 6 discusses some of the design considerations that lead to		Intermediate routers that support the ARO-Solution should recognize
			the NEMO-BU RAO, and realize that the sender (indicated by the source
			address), is attempting to discover the global address of its access
			router. The ARO-enabled intermediate router should then change the
			NEMO-BU RAO to a NEMO-NoFwd RAO before forwarding the packet. In
			addition, it should send a Router Global Address ICMP message (see
			Section 3.3.1) to the source of the packet containing the NEMO-BU
			RAO. This allows the source to learn the HoA of the MR.
			Section 8.1 discusses some of the design considerations that lead to
	the use of a mutable Router Alert Option.		the use of a mutable Router Alert Option.
	4. Operation of NEMO-enabledMobile Router		4. Operation of ARO-Enabled Mobile Routers
	4.1. Operation when Mobile Router is at Home		4.1 Operation When Mobile Router is At Home
	This section describes the operation of a mobile router when it is		This section describes the operation of a MR when it is attached to
	attached to its home link.		its home link.
	4.1.1. Sending Router Advertisement		4.1.1 Sending Router Advertisement
	When the mobile router sends Router Advertisement, the mobile router		When the MR sends RA message, it should advertise its HoA by adding a
	should set N-flag to 1, indicating to recipients it is a NEMO-enabled		RGAO in the RA message. This also indicates to the recipients that
	router. In addition, the mobile router should advertise its home-		the MR is ARO-enabled.
	address by adding a Router Global Address Option in the Router
	Advertisement message.
	4.1.2. Processing Outbound Packets		4.1.2 Processing Outbound Packets
	When the mobile router intercepts an outbound packet from its ingress		When the MR intercepts an outbound packet from its ingress interface,
	interface, it first checks if the packet contains a NEMO-Fwd RAO.		it first checks if the packet contains a NEMO-Fwd RAO or a NEMO-BU
	Packets that do not contain a NEMO-Fwd RAO, or packets that contain a		RAO. Packets that do not contain a NEMO-Fwd RAO, or packets that
	NEMO-NFwd RAO are simply forwarded to its egress interface. For		contain a NEMO-NoFwd RAO are simply forwarded to its egress
	packet that contains a NEMO-Fwd RAO, since the mobile router is at		interface. For packet that contains a NEMO-Fwd RAO, since the MR is
	home, it changes the NEMO-Fwd RAO to a NEMO-NFwd RAO and forwards the		at home, it changes the NEMO-Fwd RAO to a NEMO-NoFwd RAO and forwards
	packet to its egress interface.		the packet to its egress interface.
	4.1.3. Processing Inbound Packets		If the packet contains a NEMO-BU RAO, it implies that the originator
			of that packet is an ARO-enabled node trying to learn if there is an
			ARO-enabled access router in its upstream. The MR should send to
			this originator a Router Global Address ICMP message (see Section
			3.3.1). In addition, the MR should change the NEMO-BU RAO to a
			NEMO-NoFwd RAO, and forward the packet to its egress interface.
	When the mobile router is at home, it functions like a normal router.		4.1.3 Processing Inbound Packets
	Thus it will consume any packet that is addressed to its home-
	address, forward any packet with a destination address that is a
	valid address in one of its ingress interface (e.g. the destination
	address must contain the same network prefix as one of the ingress
	interface), and discard any packet with an invalid destination
	address.
	When the packet is addressed to the mobile router's home-address, the		When the MR is at home, it functions like a normal router. Thus it
	packet may contain an extended RH2. The Segments Left field of RH2		will consume any packet that is addressed to its HoA, forward any
	is checked. If Segments Left field is 0, the packet is consumed. If		packet with a destination address that is a valid address in one of
	Segments Left field is non-zero, it is checked to be smaller or equal		its ingress interface (e.g. the destination address must contain the
	to the number of addresses in the Type 2 Routing Header (which can be		same network prefix as one of the ingress interface), and discard any
	calculated by dividing the Ext Hdr Len field by two). If Segments		packet with an invalid destination address.
	Left field is bigger, the packet is discarded, and an ICMP error may
	be returned to the sender. Else, the Segments Left field is		When the packet is addressed to the MR's HoA, the packet may contain
	decremented by one and the destination address is swapped with the		an extended RH2. The Segments Left field of RH2 is checked. If
	next entry in the Address[] vector of the RH2.		Segments Left field is 0, the packet is consumed. If Segments Left
			field is non-zero, it is checked to be smaller or equal to the number
			of addresses in the Type 2 Routing Header (which can be calculated by
			dividing the Ext Hdr Len field by two). If Segments Left field is
			bigger, the packet is discarded, and an ICMP error may be returned to
			the sender. Else, the Segments Left field is decremented by one and
			the destination address is swapped with the next entry in the
			Address[] vector of the RH2.
	The new destination address is then checked if it is a valid address		The new destination address is then checked if it is a valid address
	in one of the ingress interfaces of the mobile router. If yes, the		in one of the ingress interfaces of the MR. If yes, the packet is
	packet is forwarded to the new destination. Else, the packet is		forwarded to the new destination. Else, the packet is silently
	silently discarded.		discarded.
	4.2. Operation when Mobile Router is Away		4.2 Operation When Mobile Router is Away
	This section describes the operation of a mobile router when it is		This section describes the operation of a MR when it is away from its
	away from its home link.		home link.
	4.2.1. Sending Router Advertisement		4.2.1 Sending Router Advertisement
	The mobile router would continue to send Router Advertisement when it		The MR would continue to send RA messages to its ingress interface(s)
	is away. It should behave as specified in Section 4.1.1. There is		when it is away. It should behave as specified in Section 4.1.1.
	no difference in the Router Advertisement message whether the mobile		There is no difference in the RA message whether the MR is at home or
	router is at home or away.		away.
	4.2.2. Receiving Router Advertisement		4.2.2 Receiving Router Advertisement
	The mobile router should solicit router advertisement from its access		The MR should solicit RA from its access router whenever it changes
	router whenever it changes its point of attachment to the Internet.		its point of attachment to the Internet. When the MR receives the
	When the mobile router receives the Router Advertisement, it should		RA, it should check if the access router has included the RGAO in the
	check if the access router has set the N-flag to 1. If the N-flag is		RA message. If an RGAO is present, the access router is ARO-enabled.
	set to 1, the access router is NEMO-enabled. If the flag is set to		If no RGAO is present, the access router is not ARO-enabled.
	0, the access router is not NEMO-enabled.
	4.2.3. Sending Binding Updates		4.2.3 Sending Binding Updates
	When the mobile router sends Binding Updates to other hosts, either		When the MR sends BU to other hosts, either its own HA or other
	its own home agent or other correspondent nodes, it should add an		correspondent nodes, it should add an ARO to the BU messages if its
	Access Router Option to the Binding Updates if its access router is		access router is ARO-enabled. The ARO should contain the global
	NEMO-enabled. Otherwise, if its access router is not NEMO-enabled,		address of the access router it learned from the RGAO in the RA
	the mobile router will not include the Access Router Option in the		message. Otherwise, if its access router is not ARO-enabled, the MR
	Binding Update messages.		will not include the ARO in the BU messages.
	When sending Binding Updates with the Access Router Option,		When sending BU with the ARO, especially to nodes that the MR does
	especially to hosts that it does not know to be NEMO-enabled, the		not know to be ARO-enabled, the MR should request for a BA so that it
	mobile router should request for a Binding Acknowledgement so that it		can determine if the recipient supports the ARO-Solution by checking
	can determine if the host supports the Proposed NEMO Solution by		if the ARO is present in the BA message. If the ARO is present, the
	inspecting the Status code. If the Status code is 0, the host is not		node is ARO-enabled.
	NEMO-enabled.
	4.2.4. Processing Outbound Packets		If the access router is not ARO-enabled, a MR may attempt to discover
			if there are any ARO-enabled routers upstream by prepending a NEMO-BU
			RAO to the BU message it sends out. If there exist an ARO-enabled
			router upstream, the ARO-enabled router will send an ICMP message
			containing the global address (eg HoA) of the ARO-enabled router.
			For this case, the MR can send another BU message with an ARO
			containing this global address.
	* Packet does not have a NEMO-Fwd RAO		If no response is received after a short timeout period, the MR
			should concede that there is no ARO-enabled router upstream.
	When the mobile router intercepts a packet from one of its ingress		4.2.4 Processing Outbound Packets
	interfaces, the mobile router first checks if there is a NEMO-Fwd RAO
	attached to the packet. When the NEMO-Fwd RAO is absent (or a NEMO-
	NFwd RAO is present), the mobile router has to route this packet
	through its own home agent. The packet is encapsulated in an
	external packet addressed to the home agent of the mobile router.
	If the mobile router's access router is not NEMO-enabled, the outer
	packet is sent to the mobile router's home agent. The external
	packet has the normal mobility characteristics, i.e. the source field
	contains the care-of-address of the mobile router, the destination
	field contains the address of the home agent of the mobile router,
	and a Home Address destination Option should specify the home-address
	of the mobile router.
	If the mobile router's access router is NEMO-enabled, reverse		When the MR received a packet from its ingress interface for outbound
	tunneling is still necessary. However, in this case, the mobile		forwarding, the behavior of the MR will be different depending on
	router will add a NEMO-Fwd RAO to the outer packet. The external		whether the outbound packet contains a RAO or not.
	packet is then marked with source address set to the care-of-address
	of the mobile router, destination address set to the address of the
	mobile router's home agent, and attached with a Home Address
	destination Option containing the home-address of the mobile router.
	* Packet has a NEMO-Fwd RAO		1. Packet does not have any RAO
	On the other hand, when the mobile router received a packet with a		When the MR intercepts a packet from one of its ingress
	NEMO-Fwd RAO from one of its ingress interfaces, the mobile router		interfaces, it first checks if there is a NEMO-Fwd RAO or NEMO-BU
	will then attempt to forward the packet directly to the destination.		RAO attached to the packet. When the NEMO-Fwd RAO is absent (or
	To do so, the mobile router has to check if it has a binding update		a NEMO- NoFwd RAO is present), the MR has to route this packet
	with the specified destination (by checking its Binding Update List).		through its own HA. The packet is encapsulated in an outer
	If it does not have an active binding update with the specified		packet addressed to the HA of the mobile router. If the MR's
	destination, the mobile router will have to tunnel the received		access router is not ARO-enabled, the outer packet is sent to the
	packet to its home agent using reverse tunneling. In this case, the		MR's home agent. The outer packet has the normal mobility
	NEMO-Fwd RAO is changed to a NEMO-NFwd RAO, and the packet is		characteristics, i.e. the source field contains the CoA of the
	processed as though it does not contain a NEMO-Fwd RAO (as described		MR and the destination field contains the address of the HA of
	in previous paragraph).		the MR.
	The presence of a NEMO-Fwd RAO should suggest to the mobile router		If the MR's access router is ARO-enabled, reverse tunneling is
	that it could perform a Return Routability Test and Binding Update		still necessary. However, in this case, the mobile router will
	with the specified destination, so that subsequent packets from the		add a NEMO-Fwd RAO to the outer packet. The outer packet is then
	same source to the same destination need not go through the bi-		marked with source address set to the CoA of the MR, destination
	directional tunnel.		address set to the address of the MR's HA. and attached with a
			Home Address destination Option containing the HoA of the MR.
	If the mobile router does have an active binding update with the		2. Packet has a NEMO-NoFwd RAO
	specified destination, the source address of the packet is changed to
	the care-of-address of the mobile router. In addition, if the access
	router of the mobile router is not NEMO-enabled, the NEMO-Fwd RAO is
	changed to a NEMO-NFwd RAO. The packet is then forwarded through the
	egress interface of the mobile router.
	4.2.5. Processing Inbound Packets		Processing of an outbound packet with a NEMO-NoFwd RAO is
			identical to that when the packet contains no RAO.
	When the mobile router received a packet from its access router the		3. Packet has a NEMO-Fwd RAO
	packet must contain a destination field equal the care-of-address of
	the mobile router, and a type 2 routing header. If these conditions
	are not satisfied, the packet is silently discarded. In addition,
	since the packet is addressed to the care-of-address of the mobile
	router, the packet must be sent from a host that has a binding entry
	of the mobile router. If security measures warrant it, the mobile
	router may want to verify the sender is indeed a host in the mobile
	router's Binding Update List, and discard the packet if it isn't.
	The Segments Left field of RH2 is also checked. If Segments Left		On the other hand, when the MR received a packet with a NEMO-Fwd
			RAO from one of its ingress interfaces, the MR will then attempt
			to forward the packet directly to the destination. To do so, the
			MR has to check if it has a binding update with the specified
			destination (by checking its Binding Update List). If it does
			not have an active binding update with the specified destination,
			the MR will have to tunnel the received packet to its HA using
			reverse tunneling. In this case, the NEMO-Fwd RAO is changed to
			a NEMO-NoFwd RAO, and the packet is processed as though it does
			not contain a NEMO-Fwd RAO (as described previously).
			The presence of a NEMO-Fwd RAO should suggest to the MR that it
			could perform a Return Routability Procedure and BU with the
			specified destination, so that subsequent packets from the same
			source to the same destination need not go through the bi-
			directional tunnel.
			If the MR does have an active binding update with the specified
			destination, the source address of the packet is changed to the
			CoA of the MR. In addition, if the access router of the MR is
			not ARO-enabled, the NEMO-Fwd RAO is changed to a NEMO-NoFwd RAO.
			The packet is then forwarded through the egress interface of the
			MR.
			4. Packet has a NEMO-BU RAO
			When the MR intercepts a packet from one of its ingress
			interfaces with a NEMO-BU RAO, it implies that the originator of
			that packet is an ARO-enabled node trying to learn if there is an
			ARO-enabled access router in its upstream. The MR should send to
			this originator a Router Global Address ICMP message (see Section
			3.3.1). In addition, the MR should change the NEMO-BU RAO to a
			NEMO-NoFwd RAO, and process the packet as though it does not
			contain a NEMO-BU RAO (as described previously).
			4.2.5 Processing Inbound Packets
			When the MR received a packet from its egress interface, the MR
			checks if the packet is addressed to itself. Packets not addressed
			to its CoA or HoA are discarded. When the packet is addressed to its
			CoA, the MR checks for the presence of type 2 routing header (RH2).
			Packets without the RH2 are processed as per specified in [2]. If
			the packet contains a RH2 and is addressed to its CoA, the packet
			must be sent from a host that has a BCE of the MR. If security
			measures warrant it, the MR may want to verify the sender is indeed a
			node in the MR's Binding Update List, and discard the packet if it
			isn't.
			The Segments Left field of RH2 is then checked. If Segments Left
	field is 0, the packet is discarded. If Segments Left field is non-		field is 0, the packet is discarded. If Segments Left field is non-
	zero, it is checked to be smaller or equal to the number of addresses		zero, it is checked to be smaller or equal to the number of addresses
	in the Type 2 Routing Header (which can be calculated by dividing the		in the RH2 (which can be calculated by dividing the Ext Hdr Len field
	Ext Hdr Len field by two). If Segments Left field is bigger, the		by two). If Segments Left field is bigger, the packet is discarded,
	packet is discarded, and an ICMP error may be returned to the sender.		and an ICMP error may be returned to the sender. Else, the Segments
	Else, the Segments Left field is decremented by one and the		Left field is decremented by one and the destination address is
	destination address is swapped with the next entry in the Address[]		swapped with the next entry in the Address[] vector of the RH2.
	vector of the RH2.
	If the new destination address is the home-address of the mobile		If the new destination address is the HoA of the MR, the Segments
	router, the Segments Left field is checked if it is 0 (after		Left field is checked if it is 0 (after decrementing). If so, the
	decrementing). If so, the packet is consumed by the mobile router.		packet is consumed by the MR. Otherwise, the packet is silently
	Otherwise, the packet is silently discarded.		discarded.
	Alternatively, the new destination address may be an address in one		Alternatively, the new destination address may be an address in one
	of the mobile router's ingress interfaces. If yes, the packet is		of the MR's ingress interfaces. If yes, the packet is forwarded to
	forwarded to the new destination. Else, if the new destination		the new destination. Else, if the new destination field of the
	field of the packet is neither the home-address nor a valid address		packet is neither the HoA nor a valid address in one of the MR's
	in one of the mobile router's ingress interfaces, the packet is		ingress interfaces, the packet is silently discarded.
	silently discarded.
	When a packet is consumed by the mobile router, the payload may be an		When a packet is consumed by the MR, the payload may be an
	encapsulated packet. In this case, sender of the outer packet must		encapsulated packet. In this case, sender of the outer packet must
	be the home agent of the mobile router. Processing of the inner		be the HA of the MR, or a node in MR's Binding Update List.
	packet is the same as that described in Section 4.1.3, i.e. as though		Processing of the inner packet is the same as though the mobile
	the mobile router is at home.		router is at home.
	4.3. IPSec Processing
	It is strongly recommended that the mobile router uses IPSec		4.3 IPSec Processing
	protocols such as AH[18] or ESP[19] to secure the reverse tunnel with
	its home agent. This section highlights changes to the IPSec
	processing for inbound and outbound packets.
	4.3.1. IPSec Processing on Inbound Packets		It is recommended that the MR uses IPSec protocols such as AH [9] or
			ESP [10] to secure the reverse tunnel with its HA [13]. This section
			highlights changes to the IPSec processing for inbound and outbound
			packets.
	Inbound packets may contain a type 2 routing header with an AH/ESP.		4.3.1 IPSec Processing on Inbound Packets
	The routing header should be processed before AH. If the mobile
	router is the final destination, the packet is passed to the IPSec
	module for AH/ESP processing. Since the home agent will generate the
	AH/ESP in a such a way that it is consistent with the state of the
	packet headers when the receiver received the packet (see Section
	5.5.2), no additional processing needs to be done before the AH/ESP
	processing.
	4.3.2. IPSec Processing on Outbound Packets		Inbound packets may contain a RH2 with an AH/ESP. The RH2 should be
			processed before AH. If the MR is the final destination, the packet
			is passed to the IPSec module for AH/ESP processing. Since the HA or
			CN will generate the AH/ESP in a such a way that it is consistent
			with the state of the packet headers when the receiver received the
			packet (see Section 5.4.2), no additional processing needs to be done
			before the AH/ESP processing.
	For outbound packets, the new option added to the packets by the		4.3.2 IPSec Processing on Outbound Packets
	Proposed NEMO Solution is the NEMO-Forward and NEMO-No-Forward Router
	Alert Options. Originator of a packet will only insert the NEMO-Fwd
	RAO to a newly-created packet. The NEMO-Fwd RAO will be changed to a
	NEMO-NFwd RAO by subsequent router, since all NEMO-enabled mobile
	routers will change the NEMO-Fwd RAO in a outgoing packet to a NEMO-
	NFwd RAO when
	(1) the mobile router is attached to an access router that is not		For outbound packets, the new options added to the packets by the
	NEMO-enabled; or		ARO-Solution are the NEMO-Fwd, NEMO-BU and NEMO-NoFwd Router Alert
			Options. For simplicity, it is best that all IPSec implementations
			ignore these options and treat their values as all zero when
			processing.
	(2) the mobile router encapsulate the outgoing packet into a tunnel		5. Operation of ARO-Enabled Home Agents
	packet.
	Thus the NEMO-Fwd RAO is a mutable but predictable option, where the		5.1 Receiving Binding Updates
	receiver always received the NEMO-Fwd RAO as a NEMO-NFwd RAO. Thus
	when generating AH authentication data, the sender should use a NEMO-
	NFwd RAO for AH processing.
	Also, when generating the AH authentication data, the originator		When a HA receives a BU message, it needs to check for the necessary
	should use its home-address as the IPv6 source address in the IPv6		security measures as specified in Mobile IPv6 specifications [1] or
	header, and place its care-of-address in the Home Address field of		NEMO Basic Support [2]. The only change this ARO Solution requires
	the Home Address destination option, as required by [9].		is for the HA to add a field to its Binding Cache: access router's
			address. Every valid BU is checked for the Access Router Option
			field. If one is absent, the corresponding BCE will have the access
			router field invalidated. If one is present, the corresponding BCE
			will have the access router field updated.
	5. Operation of NEMO-enabled Home Agent		In addition, when returning a BA for a BU that contains an Access
			Router Option, the ARO-Solution requires that the HA return a the BA
			with the same Access Router Option if the binding is successful.
			Note also that the HA MUST accept BU with Access Router Option
			regardless of whether the Home Registration bit is set.
	5.1. Sending Router Advertisement		5.2 Receiving Tunneled Packets from Away Nodes
	When the home agent sends Router Advertisement, the home agent should		When the HA received a packet that contains an encapsulated packet,
	set the H-flag to 1 and set the N-flag to 1, indicating to recipients		it may choose to perform certain security checks. The obvious check
	it is functioning as a NEMO-enabled Mobile IP home agent.		is to ensure that the source address is either a valid CoA of the HoA
			in its binding cache, or the source address is a valid CoA or HoA of
			an access router that is in the upstream of the mobile node with the
			specified HoA in the Home Address Destination option. Section 9.3
			discusses the security considerations on accepting tunnels with a
			source address that is not directly bound to the HoA specified in the
			Home Address destination option.
	5.2. Receiving Binding Updates		To establish this, the HA can use the pseudo algorithm depicted in
			Figure 9. The algorithm returns TRUE if the source address in a
			valid address, and FALSE otherwise. When the algorithm returns TRUE,
			the source address is a valid address, and the packet is decapsulated
			and processed as normal. Should the algorithm evaluates to FALSE,
			the packet is discarded.
	When a home agent receives a Binding Update message, it needs to		set start-address = HoA in HAO
	check for the necessary security measures as specified in Mobile IPv6		while (TRUE) do
	specifications [9]. The only change this Proposed NEMO Solution		{
	requires is for the home agent to add a field to its Binding Cache:		find an entry in Binding Cache with HoA field == start-address
	access router's home-address. Every valid Binding Update is checked		if (no BCE is found)
	for the Access Router Option field. If one is absent, the		{
	corresponding entry in the Binding Cache will have the access router		return (FALSE)
	field invalidated. If one is present, the corresponding entry in the		}
	Binding Cache will have the access router field updated.		if (CoA field in the BCE
			== source-address of outer packet)
			{
			return (TRUE)
			}
			if (the BCE does not contain a valid access
			router address)
			{
			return (FALSE)
			}
			if (access router address field in the BCE
			== source-address of outer packet)
			{
			return (TRUE)
			}
			set start-address = access router address field in the BCE
			}
	In addition, when returning a Binding Acknowledgement for a Binding		Figure 9: Algorithm to check source address is valid
	Update that contains an Access Router Option, the Proposed NEMO
	Solution requires that the home agent return a Status code that is to
	be assigned (referred to as ARO-OK) to indicate that the Access
	Router Option is accepted.
	Note also that the home-agent MUST accept Binding Updates with ARO		5.3 Tunneling Packets to Away Nodes
	with or without the Home Registration bit set.
	5.3. Receiving Tunneled Packets from Away Nodes		When the HA intercepted a packet addressed to a node in its home
			domain, it checks the next hop to forward the packet from its routing
			table. This sub-section describes the operation of the HA when the
			next hop is away, i.e. the next hop is a mobile node, and the mobile
			node is away from home.
	When the home agent received a packet that contains an encapsulated		In this case, the HA will forward the packet to the mobile node at
	packet, it may choose to perform certain security checks. The		the CoA of the mobile node. This is done by encapsulating the
	obvious check is to ensure that the source address is either a valid		intercepted packet into a new packet. According to standard MIPv6
	care-of-address of the home-address in its binding cache, or the		specification [1], the packet will have the source address set to the
	source address is a valid care-of-address/home-address of an access		address of the HA, destination set to the CoA of the mobile router,
	router that is in the upstream of the mobile node with the specified		and a RH2 with only one address entry equals to the HoA of the mobile
	home-address. Section 7.3 discusses the security considerations on		node.
	accepting tunnels with a source address that is not directly bound to
	the home-address specified in the Home Address destination option.
	To establish this, the home agent can use the pseudo algorithm		This ARO-Solution extends the RH2 to include addresses of access
	depicted in Figure 2. The algorithm returns TRUE if the source		routers, and the pseudo algorithm depicted in Figure 10 can be used
	address in a valid address, and FALSE otherwise. When the algorithm		to construct such a routing header. In Figure 10, src-address and
	returns TRUE, the source address is a valid address, and the packet		dst-address are the abbreviations for the source address and
	is decapsulated and processed as normal. Should the algorithm		destination address fields of the outer packet respectively.
	evaluates to FALSE, the packet is discarded.
	set start-address = HoA in HAO		initialize an empty stack
	while (TRUE) do		set src-address = address of home agent
	{		set dst-address = HoA of mobile node
	find an entry in Binding Cache with HoA field = start-address		set Finished = FALSE
	if (no Binding Cache entry is found)		while (not Finished)
	{		{
	return (FALSE)		find BCE with HoA field = dst-address
	}		if (no BCE is found)
	if (CoA field in the Binding Cache entry
	== source-address of outer packet)
	{		{
	return (TRUE)		Finished = TRUE
	}		}
	if (the Binding Cache entry does not contain a valid access		else
	router address)
	{		{
	return (FALSE)		if (dst-address == HoA of mobile node)
			{
			push dst-address to stack
			}
			set dst-address = CoA field of the found BCE
			if (the found BCE contains a valid access router address)
			{
			push dst-address to stack
			set dst-address = access router address field of BCE found
			}
			else
			{
			Finished = TRUE
			}
	}		}
	if (access router address field in the Binding Cache entry		}
	== source-address of outer packet)		if (stack is not empty)
			{
			prepare a type 2 routing header
			set Hdr Ext Len field of RH2 = (size of stack) x 2
			set Segments Left field of RH2 = size of stack
			for n=1 to (Segments Left field of RH2)
	{		{
	return (TRUE)		pop top of stack to Address[n] of RH2
	}		}
	set start-address = access router address field in the		}
	Binding Cache entry
	}
	Figure 2: Algorithm to check source address is valid		Figure 10: Algorithm to construct extended RH2
	5.4. Tunneling Packets to Away Nodes		The outer packet is then sent to the destination. If secure tunnel
			is used, the IPSec protocol used must be able to recognize that the
			RH2 is a mutable but predictable header, such that the two end-points
			use the same routing header and IPv6 destination field for IPSec
			processing. Particularly, the sender should calculate the IPSec
			parameters using values in the IPv6 headers that the receiver will
			receive.
	When the home agent intercepted a packet addressed to a node in its		5.4 IPSec Processing
	home domain, it checks the next router to forward the packet from its
	routing table. This sub-section describes the operation of the home
	agent when the next router is away, i.e. the next router is a mobile
	router, and the mobile router is away from home.
	In this case, the home agent will forward the packet to the mobile		It is recommended that the HA uses IPSec protocols such as AH [9] or
	router at the care-of-address of the mobile router. This is done by		ESP [10] to protect the tunnel with a mobile node [13]. This section
	encapsulating the intercepted packet into a new packet. According to		highlights changes to the IPSec processing for inbound and outbound
	standard Mobile IPv6 specification [9], the packet will have the		packets.
	source address set to the address of the home agent, destination set
	to the care-of-address of the mobile router, and a Type 2 Routing
	Header with only one address entry equals to the home-address of the
	mobile router.
	This Proposed NEMO Solution extends the Type 2 Routing Header to		5.4.1 IPSec Processing on Inbound Packets
	include addresses of access routers, and the pseudo algorithm
	depicted in Figure 3 can be used to construct such a routing header.
	In Figure 3, src-address and dst-address are the abbreviations for
	the source address and destination address fields of the outer packet
	respectively.
	empty a stack		Packets that are inbound may have their source address modified en-
	set src-address = address of home agent		route by access routers. Thus, all home-agents SHOULD use the
	set dst-address = HoA of mobile router		algorithm shown in Figure 9 to establish the authenticity of the
	set Finished = FALSE		source address. Once the source address is verified, the source
	while (not Finished)		address field will be replaced by the HoA specified in the Home
	{		Address Destination option, and the Home Address field of the Home
	find entry in Binding Cache with HoA field = dst-address		Address Destination option MUST be replaced with the CoA of the
	if (no Binding Cache entry is found)		sender. In MIPv6, this CoA can be obtained from the source address
	{		field in the packet. However, the ARO-Solution allows intermediate
	Finished = TRUE		mobile routers to modify the source address field. Thus, the home
	}		agent MUST obtain the CoA from its BCE.
	else
	{
	if (dst-address == HoA of mobile router)
	{
	push dst-address to stack
	}
	set dst-address = CoA field of the found Binding Cache entry
	if (the found Binding Cache entry contains a valid access
	router address)
	{
	push dst-address to stack
	set dst-address = access router address field of found
	Binding Cache Entry
	}
	else
	{
	Finished = TRUE
	}
	}
	}
	if (stack is not empty)
	{
	prepare a type 2 routing header
	set Hdr Ext Len field of RH2 = (size of stack) x 2
	set Segments Left field of RH2 = size of stack
	for n=1 to (Segments Left field of RH2)
	{
	pop top of stack to Address[n] of RH2
	}
	}
	Figure 3: Algorithm to construct extended RH2		The above processing MUST be carried out before AH processing.
	The outer packet is then sent to the destination. If secure tunnel		5.4.2 IPSec Processing on Outbound Packets
	is used, the IPSec protocol used must be able to recognize that the
	Type 2 Routing Header is a mutable but predictable header, such that
	the two end-points use the same routing header and IPv6 destination
	field for IPSec processing. Particularly, the sender should
	calculate the IPSec parameters using values in the IPv6 headers that
	the receiver will receive.
	5.5. IPSec Processing		Outbound packets may contain an extended RH2. The extended RH2 is a
			mutable but predictable header. According to the usual norm of
			generating AH authentication data, the HA must order the contents of
			the RH2 as it will appear at the final destination when generating
			the AH authentication data.
	It is strongly recommended that the home agent uses IPSec protocols		6. Operation of ARO-Enabled Mobile Network Nodes
	such as AH[18] or ESP[19] to secure the reverse tunnel with a mobile
	router. This section highlights changes to the IPSec processing for
	inbound and outbound packets.
	5.5.1. IPSec Processing on Inbound Packets		The operation of an ARO-enabled MNN is very similar to that of a MR.
			When the MNN is at home, there is no additional operation
			requirements imposed by the ARO Solution (i.e. the ARO-enabled MNN
			operation is similar to a normal MNN when it is at home). This
			section described the operation of MNN when it is away (i.e. it is a
			VMN).
			6.1 Nested Tunnel Optimization with Home Agent
			In this case, the MNN is VMN using MIPv6 bi-direction tunneling with
			its HA. If it is ARO-enabled, and its HA is also ARO-enabled, then
			the number of nested tunnel can be reduced to one.
			The MNN basically follows the same procedure as an ARO-enabled MR.
			It needs to detect the RGAO in the RA messages broadcasted by its
			access router to determine if its access router is ARO-enabled. When
			sending BU message to its HA, the MNN will insert an ARO to the BU
			message containing the home-address of its access router.
			After the binding is successful, the MNN can then attached a NEMO-Fwd
			RAO in the tunnel packets sent to its HA. Note that when doing so,
			the MNN needs to attach a Home Address Destination Option in the
			tunnel packet.
			6.2 Receiving Router Advertisement
			The MNN should solicit RA from its access router whenever it changes
			its point of attachment to the Internet. When the MNN receives the
			RA, it should check if the access router has included the RGAO in the
			RA message. If an RGAO is present, the access router is ARO-enabled.
			If no RGAO is present, the access router is not ARO-enabled.
			6.3 Sending Binding Updates
			When the MNN sends BU to other hosts, either its own HA or other
			correspondent nodes, it should add an ARO to the BU messages if its
			access router is ARO-enabled. The ARO should contain the global
			address of the access router it learned from the RGAO in the RA
			message. Otherwise, if its access router is not ARO-enabled, the MNN
			will not include the ARO in the BU messages.
			When sending BU with the ARO, especially to nodes that the MNN does
			not know to be ARO-enabled, the MNN should request for a BA so that
			it can determine if the recipient supports the ARO-Solution by
			checking if the ARO is present in the BA message. If the ARO is
			present, the node is ARO-enabled.
			If the access router is not ARO-enabled, a MNN may attempt to
			discover if there are any ARO-enabled routers upstream by prepending
			a NEMO-BU RAO to the BU message it sends out. If there exist an
			ARO-enabled router upstream, the ARO-enabled router will send an ICMP
			message containing the global address of the ARO-enabled router. For
			this case, the MNN can send another BU message with an ARO containing
			this global address.
			If no response is received after a short timeout period, the MNN
			should concede that there is no ARO-enabled router upstream.
			6.4 Sending Data Packets
			When the MNN is tunneling data packets to its HA, the MNN can add a
			NEMO-Fwd RAO to the tunnel packet (i.e. outer packet) if (1) its HA
			is ARO-enabled, and (2) its access router is ARO-enabled. Otherwise,
			the MNN should use the normal MIPv6 bi-directional tunneling to
			forward the data packet to its HA. When adding the NEMO-Fwd RAO, the
			MNN should also include a Home Address Destination Option in the
			tunnel packet.
			When the MNN knows (by other means) that the CN it is communicating
			with is ARO-enabled, the MNN can choose to employ full route
			optimization with the CN. This is done by adding a NEMO-Fwd RAO to
			the data packet. Note that the MNN should also include a Home
			Address Destination Option in the data packet.
			6.5 Processing Inbound Packets
			When the MNN received a packet from its egress interface, the MNN
			checks if the packet is addressed to itself. Packets not addressed
			to its CoA or HoA are discarded. When the packet is addressed to its
			CoA, the MNN checks for the presence of type 2 routing header (RH2).
			Packets without the RH2 are processed as per specified in [2]. If
			the packet contains a RH2 and is addressed to its CoA, the packet
			must be sent from a host that has a BCE of the MNN. If security
			measures warrant it, the MR may want to verify the sender is indeed a
			node in the MR's Binding Update List, and discard the packet if it
			isn't.
			The Segments Left field of RH2 is then checked. If Segments Left
			field is 0, the packet is discarded. If Segments Left field is non-
			zero, it is checked to be smaller or equal to the number of addresses
			in the RH2 (which can be calculated by dividing the Ext Hdr Len field
			by two). If Segments Left field is bigger, the packet is discarded,
			and an ICMP error may be returned to the sender. Else, the Segments
			Left field is decremented by one and the destination address is
			swapped with the next entry in the Address[] vector of the RH2.
			Being a host, the MNN must be the final destination of the packet.
			Thus, if the new destination address is not the HoA of MNN, or the
			Segments Left field is non-zero after decrementing, the packet is
			silently discarded. Else if the new destination address is the HoA
			of MNN, and the Segments Left field is zero after decrementing the
			packet is consumed.
			When a packet is consumed by the MNN, the payload may be an
			encapsulated packet. In this case, sender of the outer packet must
			be the HA of the MNN. Processing of the inner packet is the same as
			though the MNN is at home.
			6.6 IPSec Processing
			6.6.1 IPSec Processing on Inbound Packets
			Inbound packets may contain a RH2 with an AH/ESP. The routing header
			should be processed before AH. If the MNN is the final destination,
			the packet is passed to the IPSec module for AH/ESP processing.
			Since the HA or CN will generate the AH/ESP in a such a way that it
			is consistent with the state of the packet headers when the receiver
			received the packet (see Section 5.4.2), no additional processing
			needs to be done before the AH/ESP processing.
			6.6.2 IPSec Processing on Outbound Packets
			For outbound packets, the new options added to the packets by the
			ARO-Solution are the NEMO-Fwd, NEMO-BU and NEMO-NoFwd Router Alert
			Options. For simplicity, it is best that all IPSec implementations
			ignore these options and treat their values as all zero when
			processing.
			7. Operation of ARO-Enabled Correspondent Node
			7.1 Receiving Binding Updates
			When a CN receives a BU message, it needs to check for the necessary
			security measures as specified in Mobile IPv6 specifications [1] or
			NEMO Basic Support [2]. The only change this ARO Solution requires
			is for the CN to add a field to its Binding Cache: access router's
			address. Every valid BU is checked for the Access Router Option
			field. If one is absent, the corresponding BCE will have the access
			router field invalidated. If one is present, the corresponding BCE
			will have the access router field updated.
			In addition, when returning a BA for a BU that contains an Access
			Router Option, the ARO-Solution requires that the CN returns a the BA
			with the same Access Router Option if the binding is successful.
			Note that a BU sent to the CN MUST be preceded with a return
			routability procedure. Section 9.1 discusses possibility of
			extending the return routability procedure to protect the Access
			Router Option.
			7.2 Receiving Route Optimized Packets from Mobile Nodes
			When the CN received a packet that contains a Home Address
			Destination Option, it will have to perform certain security checks
			to ensure that the source address is either a valid CoA of the HoA in
			its binding cache, or the source address is a valid CoA or HoA of an
			access router that is in the upstream of the mobile node with the
			specified HoA in the Home Address Destination option. Section 9.3
			discusses the security considerations on accepting tunnels with a
			source address that is not directly bound to the HoA specified in the
			Home Address destination option.
			To establish this, the CN can use the pseudo algorithm depicted in
			Figure 9 shown in Section 5.2. The algorithm returns TRUE if the
			source address in a valid address, and FALSE otherwise. When the
			algorithm returns TRUE, the source address is a valid address, and
			the source address is replaced with the HoA contained in the Home
			Address Destination Option and processed as normal. Should the
			algorithm evaluates to FALSE, the packet is silently discarded.
			7.3 Sending Route Optimized Packets to Mobile Nodes
			When the CN sends a packet, it should check if the destination
			address is in its BCE. If the destination is not in the BCE, then
			the packet is sent as per normal IPv6 operation. If the destination
			is in its BCE, normal MIPv6 will require that the source address be
			set to the address of the CN, destination set to the CoA of the MR,
			and a RH2 with only one address entry equals to the HoA of the mobile
			node.
			This ARO-Solution extends the RH2 to include addresses of access
			routers, and the pseudo algorithm depicted in Figure 10 shown in
			Section 5.3 can be used to construct such a routing header. In
			Figure 10, src-address and dst-address are the abbreviations for the
			source address and destination address fields of the outer packet
			respectively.
			If IPSec protocol is used to protect the packet, the IPSec protocol
			used must be able to recognize that the RH2 is a mutable but
			predictable header, such that the two end-points use the same routing
			header and IPv6 destination field for IPSec processing.
			Particularly, the sender should calculate the IPSec parameters using
			values in the IPv6 headers that the receiver will receive.
			7.4 IPSec Processing
			7.4.1 IPSec Processing on Inbound Packets
	Packets that are inbound may have their source address modified en-		Packets that are inbound may have their source address modified en-
	route by access routers. Thus, all home agents MUST use the		route by access routers. Thus, all ARO-enabled correspondent nodes
	algorithm shown in Figure 2 to establish the authenticity of the		SHOULD use the algorithm depicted in Figure 9 shown in Section 5.2 to
	source address. Once the source address is verified, the source		establish the authenticity of the source address. Once the source
	address field will be replaced by the home-address specified in the		address is verified, the source address field will be replaced by the
	Home Address destination option, and the Home Address field of the		HoA specified in the Home Address Destination option, and the Home
	Home Address destination option MUST be replaced with the care-of-		Address field of the Home Address Destination option MUST be replaced
	address of the sender. In Mobile IPv6, this care-of-address can be		with the CoA of the sender. In MIPv6, this CoA can be obtained from
	obtained from the source address field in the packet. However, this		the source address field in the packet. However, the ARO-Solution
	Proposed NEMO Solution allows intermediate mobile routers to modify		allows intermediate mobile routers to modify the source address
	the source address field. Thus, the home agent MUST obtain the care-		field. Thus, the CN MUST obtain the CoA from its BCE.
	of-address from its Binding cache.
	The above processing MUST be carried out before AH processing.		The above processing MUST be carried out before AH processing.
	5.5.2. IPSec Processing on Outbound Packets		7.4.2 IPSec Processing on Outbound Packets
	Outbound packets may contain an extended RH2. The extended RH2 is a		Outbound packets may contain an extended RH2. The extended RH2 is a
	mutable but predictable header. According to the usual norm of		mutable but predictable header. According to the usual norm of
	generating AH authentication data, the home agent must order the		generating AH authentication data, the CN must order the contents of
	contents of the RH2 as it will appear at the final destination when		the RH2 as it will appear at the final destination when generating
	generating the AH authentication data.		the AH authentication data.
	6. Considerations in the Use of Mutable Router Alert Option		8. Design Considerations
	This section described the design considerations leading to the use		This section describes the rational behind some design decision made
	of a mutable Router Alter Option.		in the formulation of the ARO Solution. Some justifications are
			given, and in some cases, alternative approaches are discussed.
	6.1. Router Alert Option		8.1 Considerations in the Use of Mutable Router Alert Option
	The proposed solution described in this memo is designed so that it		8.1.1 Overview of Router Alert Option
	will work in a nested NEMO where some mobile routers are NEMO-enabled
	and some are not. Thus, some form of indications on a packet is
	necessary to inform upstream mobile routers to attempt to use the
	Proposed NEMO Solution. Since the indication is meant for
	intermediate routers, a hop-by-hop option is needed.
	The Router Alert Option [16] lends itself readily for use. By		The ARO Solution described in this memo is designed so that it will
	assigning a value in RAO, a NEMO-enabled mobile router can request		work in a nested NEMO where some mobile routers are ARO-enabled and
	its access router to attempt to forward the packet directly to the		some are not. Thus, some form of indications on a packet is
			necessary to inform upstream mobile routers to attempt to use the ARO
			Solution. Since the indication is meant for intermediate routers, a
			hop-by-hop option is needed.
			The Router Alert Option [6] lends itself readily for use. By
			assigning a value in RAO, a ARO-enabled mobile router can request its
			access router to attempt to forward the packet directly to the
	destination without using reverse tunnel. However, further analysis		destination without using reverse tunnel. However, further analysis
	reveals that there is a need for a mobile router that is not attached		reveals that there is a need for a mobile router that is not attached
	to a NEMO-enabled access router to disable this behavior.		to a ARO-enabled access router to disable this behavior.
	6.2. Example where an Immutable RAO is Used		8.1.2 Example where an Immutable RAO is Used
	To understand why a mobile router that is not attached to a NEMO-		To understand why a MR that is not attached to a ARO- enabled access
	enabled access router should disable the NEMO-Fwd RAO, consider the		router should disable the NEMO-Fwd RAO, consider the following
	following scenario, where MR1, MR2, and MR4 are NEMO-enabled mobile		scenario, where MR1, MR2, and MR4 are ARO-enabled mobile routers,
	routers, LFR3 is a non-NEMO-enabled local fixed router attached to		LFR3 is a non-ARO-enabled local fixed router attached to MR4, and HA1
	MR4, and HA1 is the home agent of MR1.		is the home agent of MR1.
	MR1---MR2---LFR3---MR4---[Internet]---HA1		MR1---MR2---LFR3---MR4---[Internet]---HA1
	Suppose both MR1 and MR2 have performed binding updates successfully		Suppose both MR1 and MR2 have performed binding updates successfully
	with HA1, thus the state of the Binding Cache of HA1 will be:		with HA1, thus the state of the Binding Cache of HA1 will be:
	Home-Address Care-of-Address Access Router		Home-Address Care-of-Address Access Router
	------------ --------------- -------------		------------ --------------- -------------
	MR1.HoA MR1.CoA MR2.HoA		MR1.HoA MR1.CoA MR2.HoA
	MR2.HoA MR2.CoA <invalid>		MR2.HoA MR2.CoA <invalid>
	When MR1 encapsulates a packet to be tunneled to HA1, MR1 adds a		When MR1 encapsulates a packet to be tunneled to HA1, MR1 adds a
	NEMO-Fwd RAO in the outer packet (since MR2, the access router of		NEMO-Fwd RAO in the outer packet (since MR2, the access router of
	MR1, is NEMO-enabled). Thus the packet from MR1 to MR2 will contains		MR1, is ARO-enabled). Thus the packet from MR1 to MR2 will contains
	the following contents:		the following contents:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)		IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt		Hop-by-Hop Opt
	RAO (NEMO-Fwd)		RAO (NEMO-Fwd)
	Dest Opt		Dest Opt
	HAO (MR1.HoA)		HAO (MR1.HoA)
	Since MR2 has already performed a binding update with HA1, it changes		Since MR2 has already performed a binding update with HA1, it changes
	the source address and forwards the packet to LFR3. LFR3 is a fixed		the source address and forwards the packet to LFR3. LFR3 is a fixed
	router, thus it simply forwards the packet to MR4. At MR4, the		router, thus it simply forwards the packet to MR4. At MR4, the
	packet contents is then:		packet contents is then:
	IPv6 Hdr (src=MR2.CoA, dst=HA1)		IPv6 Hdr (src=MR2.CoA, dst=HA1)
	Hop-by-Hop Opt		Hop-by-Hop Opt
	RAO (NEMO-Fwd)		RAO (NEMO-Fwd)
	Dest Opt		Dest Opt
	HAO (MR1.HoA)		HAO (MR1.HoA)
	When MR4 intercepts this packet, the presence of the NEMO-Fwd RAO		When MR4 intercepts this packet, the presence of the NEMO-Fwd RAO
	will cause MR4 to start a binding update with HA1, and tunnels the		will cause MR4 to start a binding update with HA1, and tunnels the
	packet to its home agent. From the home agent of MR4, the packet is		packet to its home agent. From the home agent of MR4, the packet is
	forwarded to HA1.		forwarded to HA1.
	Suppose now HA1 accepts the binding update with MR4, and its Binding		Suppose now HA1 accepts the binding update with MR4, and its Binding
	Cache is thus as follows:		Cache is thus as follows:
	Home-Address Care-of-Address Access Router		Home-Address Care-of-Address Access Router
	------------ --------------- -------------		------------ --------------- -------------
	MR1.HoA MR1.CoA MR2.HoA		MR1.HoA MR1.CoA MR2.HoA
	MR2.HoA MR2.CoA <invalid>		MR2.HoA MR2.CoA <invalid>
	MR4.HoA MR4.HoA <invalid>		MR4.HoA MR4.HoA <invalid>
	Now, when MR1 sends a tunnel packet to HA1 again, the packet will		Now, when MR1 sends a tunnel packet to HA1 again, the packet will
	arrive at MR4 with the following contents:		arrive at MR4 with the following contents:
	IPv6 Hdr (src=MR2.CoA, dst=HA1)		IPv6 Hdr (src=MR2.CoA, dst=HA1)
	Hop-by-Hop Opt		Hop-by-Hop Opt
	RAO (NEMO-Fwd)		RAO (NEMO-Fwd)
	Dest Opt		Dest Opt
	HAO (MR1.HoA)		HAO (MR1.HoA)
	This time, MR4 checks that HA1 is on its Binding Update List, thus it		This time, MR4 checks that HA1 is on its Binding Update List, thus it
	will change the source address of the packet to its care-of-address		will change the source address of the packet to its CoA and forward
	and forward the packet to HA1 through the Internet. When HA1		the packet to HA1 through the Internet. When HA1 receives the
	receives the packet, the contents will be:		packet, the contents will be:
	IPv6 Hdr (src=MR4.CoA, dst=HA1)		IPv6 Hdr (src=MR4.CoA, dst=HA1)
	Hop-by-Hop Opt		Hop-by-Hop Opt
	RAO (NEMO-Fwd)		RAO (NEMO-Fwd)
	Dest Opt
	HAO (MR1.HoA)
	Because the Access Router field of the Binding Cache entry for MR2 is		Dest Opt
	marked invalid, the algorithm for checking the validity of the source		HAO (MR1.HoA)
	address as shown in Figure 2 of Section 5.3 will fail. Thus the
	packet will be discarded at HA1.
	6.3. The Need for Mutable RAO		Because the Access Router field of the BCE for MR2 is marked invalid,
			the algorithm for checking the validity of the source address as
			shown in Figure 9 of Section 5.2 will fail. Thus the packet will be
			discarded at HA1.
			8.1.3 The Need for Mutable RAO
	The example in the previous section shows that the presence of a		The example in the previous section shows that the presence of a
	local fixed router (LFR) that is not NEMO-enabled may cause an		local fixed router (LFR) that is not ARO-enabled may cause an
	unintentional denial-of-service to mobile routers that are attached		unintentional denial-of-service to mobile routers that are attached
	to the LFR.		to the LFR.
	To avoid this problem, MR4 must somehow realize that it should ignore		To avoid this problem, MR4 must somehow realize that it should ignore
	the NEMO-Fwd RAO in a packet forwarded by MR2. One method is to		the NEMO-Fwd RAO in a packet forwarded by MR2. One method is to
	check that the source address is a valid source address in the		check that the source address is a valid source address in the
	ingress interface of MR4. However, MR2 might obtain a care-of-		ingress interface of MR4. However, MR2 might obtain a CoA that
	address that contains a prefix that is valid in the ingress interface		contains a prefix that is valid in the ingress interface of MR4.
	of MR4. Thus checking source address does not completely eliminate		Thus checking source address does not completely eliminate the
	the problem.		problem.
	If MR2 can somehow invalidate the NEMO-Fwd RAO, the problem can be		If MR2 can somehow invalidate the NEMO-Fwd RAO, the problem can be
	eliminated. But the Router Alert Option as defined in [16] is an		eliminated. But the Router Alert Option as defined in [6] is an
	immutable hop-by-hop option, so what is needed here is a mutable		immutable hop-by-hop option, so what is needed here is a mutable
	router alert option.		router alert option.
	6.4. Sub-Optimality of NEMO-NFwd RAO		8.1.4 Alternatives to the Mutable Router Alert Option
	It must be noted that using NEMO-NFwd RAO is sub-optimal. We
	illustrate this by considering the same scenario. The tunnel packet
	is forwarded from MR1 to MR2 with the following contents:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-Fwd)
	Dest Opt
	HAO (MR1.HoA)
	MR2 will change the source address to its care-of-address. In
	addition, since the access router of MR2 (i.e. LFN3) is not NEMO-
	enabled, MR2 invalidates the NEMO-Fwd RAO. Hence the contents of the
	packet that eventually read MR4 will be
	IPv6 Hdr (src=MR2.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-NFwd)
	Dest Opt
	HAO (MR1.HoA)
	Because the NEMO-Fwd RAO is changed to a NEMO-NFwd RAO, MR4 will not
	attempt to forward the packet directly to HA1. Instead, the packet
	is encapsulated in an outer tunnel to the home agent of MR4. Thus,
	the nested tunnel optimization problem is not solved optimally.
	To solve this problem optimally, a mechanism must be defined to allow
	MR4 to notify MR2 its home-address, so that MR2 can specify the home-
	address of MR4 in the Access Router Option of a Binding Update
	message sent to the home agent of MR2. It remains unclear how to
	provide such a mechanism without introducing additional security
	threats.
	6.5. Alternatives to the Mutable Router Alert Option
	There are other alternatives to the mutable Router Alert Option.		There are other alternatives to the mutable Router Alert Option.
	These include using the Flow label in IPv6 header, and defining a new		These include using the Flow label in IPv6 header, and defining a new
	routing header type. These are briefly described below.		routing header type. These are briefly described below.
	6.5.1. IPv6 Flow Label		o IPv6 Flow Label
	It is possible to use the IPv6 Flow label to achieve the same effects		It is possible to use the IPv6 Flow label to achieve the same
	as the mutable Router Alert Option. A specific, universal Flow label		effects as the mutable Router Alert Option. A specific, universal
	can be reserved to indicate to NEMO-enabled routers that they should		Flow label can be reserved to indicate to NEMO-enabled routers
	try to forward the packets directly to their destination (instead of		that they should try to forward the packets directly to their
	using a reverse tunnel with home agents).		destination (instead of using a reverse tunnel with home agents).
	This approach eliminates the need of defining a new hop-by-hop header		This approach eliminates the need of defining a new hop-by-hop
	option. However, this means that a specific flow label has to be		header option. However, this means that a specific flow label has
	reserved, which may be in contention with currently deployed IPv6		to be reserved, which may be in contention with currently deployed
	nodes. In addition, this will mean that NEMO-enabled mobile routers		IPv6 nodes. In addition, this will mean that NEMO-enabled mobile
	are unable to use Flow label for other purposes.		routers are unable to use Flow label for other purposes.
	6.5.2. New Routing Header Type		o New Routing Header Type
	A new routing header type can be defined to store the address of the		A new routing header type can be defined to store the address of
	final destination. When such a routing header is used, the		the final destination. When such a routing header is used, the
	originator will place the address of the final destination in the		originator will place the address of the final destination in the
	routing header, and place the home-address of the access router of		routing header, and place the home-address of the access router of
	the originator in the destination (when the access router is NEMO-		the originator in the destination (when the access router is NEMO-
	enabled). When a NEMO-enabled mobile router that is not attached to		enabled). When a NEMO-enabled mobile router that is not attached
	a NEMO-enabled access router receives a packet with this type of		to a NEMO-enabled access router receives a packet with this type
	routing header, it will overwrite the destination address of the		of routing header, it will overwrite the destination address of
	packet with the final destination specified in the routing header,		the packet with the final destination specified in the routing
	and decrement the Segments Left field. When a NEMO-enabled mobile		header, and decrement the Segments Left field. When a
	router that is attached to a NEMO-enabled access router receives a		NEMO-enabled mobile router that is attached to a NEMO-enabled
	packet with this type of routing header, it will overwrite the		access router receives a packet with this type of routing header,
	destination address of this packet with the home-address of its		it will overwrite the destination address of this packet with the
	access router and the leave the contents of the routing header		home-address of its access router and the leave the contents of
	untouched.		the routing header untouched.
	There remain issues that are unclear when this new type of routing		There remain issues that are unclear when this new type of routing
	header is used with other routing headers. Also, the security		header is used with other routing headers. Also, the security
	implication of defining a new type of routing header is yet to be		implication of defining a new type of routing header is yet to be
	explored.		explored.
	7. Changing Source Address by Intermediate Routers		o Discarding Immutable RAO
			Another possibility is to use the normal immutable RAO and instead
			allow routers en-route to simply discard the RAO (instead of
			changing it to a NEMO-NoFwd RAO). This will work exactly the
			same, and is both applicable to NEMO-Fwd and NEMO-BU RAO. It will
			in fact reduce processing delay when the RAO is only option in the
			hop-by-hop header. Since this will cause the hop-by-hop header to
			be removed, and en-route router need not process the hop-by-hop
			header and only to find that it contains a NEMO-NoFwd RAO which
			requires no processing.
			8.2 Change of Source Address
	This memo proposed to allow intermediate routers to change the source		This memo proposed to allow intermediate routers to change the source
	address of a packet en-route. It is expected that this will cause		address of a packet en-route. It is expected that this will cause
	some disturbances, as it is generally not allowed for routers to		some disturbances, as it is generally not allowed for routers to
	change the source address. We hope to justify our design decision in		change the source address. We hope to justify our design decision in
	this section, and discuss some alternatives.		this section, and discuss some alternatives.
	7.1. Justifications		8.2.1 Justifications
	The main factor in consideration to changing the source address en-		The main factor in consideration to changing the source address en-
	route is to overcome ingress filtering. In order for a packet to be		route is to overcome ingress filtering. In order for a packet to be
	able to pass through an ingress filter, the source address must be		able to pass through an ingress filter, the source address must be
	topologically compatible with where the packet is originated. Thus,		topologically compatible with where the packet is originated. Thus,
	to overcome ingress filtering, the source address must somehow be		to overcome ingress filtering, the source address must somehow be
	changed. We view the change of source address as somewhat akin to		changed. We view the change of source address as somewhat akin to
	the use of a care-of-address as the packet source address in Mobile		the use of a CoA as the packet source address in MIPv6.
	IPv6.
	For the case of Mobile IPv6, mobile nodes use the care-of-address to		For the case of MIPv6, mobile nodes use the CoA to overcome ingress
	overcome ingress filtering, and use the Binding Update mechanism and		filtering, and use the BU mechanism and Home Address Destination
	Home Address destination Option to allow receivers to establish a		Option to allow receivers to establish a relationship between the
	relationship between the source address (i.e. care-of-address) and		source address (i.e. CoA) and the HoA. In the ARO Solution,
	the home-address. In this proposal, receivers can use the algorithm		receivers can use the algorithm depicted in Figure 9 of Section 5.2
	depicted in Figure 2 of Section 5.3 to establish a similar		to establish a similar relationship between the source address (in
	relationship between the source address (in this case, the care-of-		this case, the CoA/HoA of an upstream access router) and the HoA.
	address of an upstream access router) and the home-address.
	7.2. Alternatives		8.2.2 Alternatives
	There are alternatives to changing source address for the purpose of		There are alternatives to changing source address for the purpose of
	overcoming ingress filters. One method is to use packet		overcoming ingress filters. One method is to use packet
	encapsulation to achieve the same effect as changing of source		encapsulation to achieve the same effect as changing of source
	address (since the outer packet has a different source address).		address (since the outer packet has a different source address).
	Currently, evaluating such a scheme is in progress.		Currently, evaluating such a scheme is in progress.
	8. Security Considerations		9. Security Considerations
	This proposal introduces several modifications to existing protocols.		This proposal introduces several modifications to existing protocols.
	In this section, we will discuss additional security issues that		In this section, we will discuss additional security issues that
	arise due to these modifications.		arise due to these modifications.
	8.1. Addition of Access Router Option		9.1 Addition of Access Router Option
	Access Router Option is introduced so that a recipient can establish		Access Router Option is introduced so that a recipient can establish
	a credible link between the global address of the access router		a credible link between the global address of the access router
	specified, and the home-address of the mobile router that sends the		specified, and the HoA of the mobile node that sends the Access
	Access Router Option.		Router Option.
	When a mobile router sends Binding Update to its home agent, current		When a mobile node sends BU to its HA, current MIPv6 draft specifies
	Mobile IPv6 draft specifies that the Binding Update should be secured		that the BU should be secured (either by ESP or AH). For this case,
	(either by ESP or AH). For this case, the introduction of Access		the introduction of Access Router Option does not introduce new
	Router Option does not introduce new security threats.		security threats.
	When sending Binding Updates to correspondent node, the mobile router		When sending BU to CN, the mobile node inserts the Access Router
	inserts the Access Router Option only when sending the actual Binding		Option only when sending the actual BU message. The BU message is
	Update message. The Binding Update message is protected using a key		protected using a key generated after obtaining the Care-of-Test
	generated after obtaining the Care-of-Test and Home-Test messages, so		(CoT) and Home-Test (HoT) messages, so the Access Router Option
	the Access Router Option should be relatively secure. However, there		should be relatively secure. However, there exist the slight
	exist the slight possibility of an attacker snooping on both the		possibility of an attacker snooping on both the CoT and HoT messages,
	Care-of-Test and Home-Test messages, thus allowing the attacker to		thus allowing the attacker to generate the key independently. The
	generate the key independently. The attacker can then proceed to		attacker can then proceed to change the values in the Access Router
	change the values in the Access Router Option and change the		Option and change the Authenticator value of the BU message using the
	Authenticator value of the Binding Update message using the generated		generated key, thus leading the correspondent node to believe that
	key, thus leading the correspondent node to believe that the mobile		the mobile node is attached to another access router.
	router is attached to another access router.
	To overcome this, it is suggested that the mobile router to insert		To overcome this, the mobile node may insert the Access Router Option
	the Access Router Option when sending the Care-of-Test Init Message.		when sending the CoT Init Message. The ARO-enabled CN, should then
	The NEMO-enabled corresponding node, should then generate the care-of		generate the care-of cookie using
	cookie using
	Care-of cookie = First64(MAC_Kcn(CoA | access router address |		Care-of cookie = First64(MAC_Kcn(CoA | access router address |
	nonce))		nonce))
	instead of using only the care-of-address and nonce. In this way,		instead of using only the CoA and nonce. In this way, the global
	the global address of the access router in the Access Router Option		address of the access router in the Access Router Option is protected
	is protected the same way the care-of-address is protected.		the same way the CoA is protected.
	Note that if the correspondent node does not recognize the Access		Note that if the CN does not recognize the Access Router Option, it
	Router Option, it will not use the access router address to generate		will not use the access router address to generate the
	the care-of-cookie. However, we do not require the mobile router to		care-of-cookie. However, we do not require the mobile node to change
	change the way the Authenticator value is generated, i.e. the value		the way the Authenticator value is generated, i.e. the value is
	is generated using the method as specified in Mobile IPv6 [9]:		generated using the method as specified in MIPv6 [1]:
	Kbu = Hash(home cookie | care-of cookie)		Kbu = Hash(home cookie | care-of cookie)
	Authenticator = MAC_Kbu(CoA | CN address | BU)		Authenticator = MAC_Kbu(CoA | CN address | BU)
	So, the Binding Update will be verified to be authentic by the		So, the BU will be verified to be authentic by the CN regardless of
	correspondent node regardless of how the care-of cookie is generated,		how the care-of cookie is generated, provided the generation of
	provided the generation of care-of cookie is consistent. The mobile		care-of cookie is consistent. The mobile node must still request for
	router must still request for Binding Acknowledgement so that the		BA so that it if the CN has accepted the Access Router Option.
	mobile router knows if the correspondent node has accepted the Access
	Router Option.
	8.2. Router Global Address Option		9.2 Router Global Address Option
	The introduction of global address of the access router in the		The introduction of global address of the access router in the BU
	Binding Update message is the crux of the Proposed NEMO Solution,		message is the crux of the ARO Solution, since this is the link which
	since this is the link which allows home agents and correspondent		allows HA and CN to set up the RH2 and to accept packets from
	nodes to set up the Type 2 Routing Header and to accept packets from
	otherwise unknown sources. From previous discussion, the global		otherwise unknown sources. From previous discussion, the global
	address of the access router is fairly secure since		address of the access router is fairly secure since
	(1) Binding Update sent by an away node to its home agent that		o BU sent by an away node to its home agent that contains the access
	contains the access router's global address is secure, and		router's global address is secure, and
	(2) Binding Updates sent to corresponding nodes are reasonably		o BU sent to CN are reasonably protected using the Return
	protected using the Return Routablility Test.		Routability Procedure.
	The weakest link is now the method in which the mobile router learns		The weakest link is now the method in which the mobile node learns
	the global address of the access router it attaches to. The method		the global address of the access router it attaches to. The method
	proposed in this memo is to use the Router Advertisement. Two		proposed in this memo is to use the Router Advertisement. Two
	possible security threats are identified here:		possible security threats are identified here:
	(1) a malicious access router advertising false global address in		1. a malicious access router advertising false global address in the
	Router Advertisement, and		RA messages it broadcasts, and
	(2) an attacker replays a Router Advertisement message from a		2. an attacker replays a RA message from a legitimate access router,
	legitimate access router, but changes the global address		but changes the global address contained in the Router Global
	contained in the Router Global Address Option to a false entry.		Address Option to a false entry.
	The severity of the two threats is yet to be fully analyzed. We do		The severity of the two threats is yet to be fully analyzed. We do
	provide our initial analysis here to invite further discussion. For		provide our initial analysis here to invite further discussion. For
	the first case, advertising a false global address is believed to be		the first case, advertising a false global address is believed to be
	one of least harm a malicious access router could do. There are		one of least harm a malicious access router could do. There are
	other far more potent threats faced by the mobile router when it		other far more potent threats faced by the mobile router when it
	attaches itself to a malicious access router. For the second case		attaches itself to a malicious access router. For the second case
	where an attacker replays a modified Router Advertisement, we		where an attacker replays a modified RA, we believed that the threat
	believed that the threat existed in IPv6 Neighbor Discovery [20]. In		existed in IPv6 Neighbor Discovery [11]. In [11], security issues
	[20], security issues pertaining to Router Advertisement are		pertaining to RA are discussed. This discussion should be able to
	discussed. This discussion should be able to shed some light on how		shed some light on how to advert such an attack.
	to advert such an attack.
	8.3. Accepting Tunnel with a Source Address not Directly Bound to the		9.3 Accepting Tunnel with a Source Address not Directly Bound to the
	Home Address		Home Address
	Mobile IPv6 forbids home agent from accepting tunnels with a source		MIPv6 forbids home agent from accepting tunnels with a source address
	address that is not bound to the home-address specified in a Home		that is not bound to the HoA specified in a Home Address Option.
	Address Option. This proposal relaxed this security measure. The		This proposal relaxed this security measure. The home agent should
	home agent should now admit tunnels from a source address that is		now admit tunnels from a source address that is "indirectly" bound
	"indirectly" bound (through the linkage of access router field in the		(through the linkage of access router field in the binding cache) to
	binding cache) to the home-address specified in the Home Address		the home-address specified in the Home Address Option. The algorithm
	Option. The algorithm presented in Figure 2 of Section 5.3 can be		presented in Figure 9 of Section 5.2 can be used to verify if the
	used to verify if the source address is "indirectly" bound to the		source address is "indirectly" bound to the HoA specified in the Home
	home-address specified in the Home Address Option.		Address Option.
	As considered above in Section 6.1, the Access Router Option is		As considered above in Section 8.2, the Access Router Option is
	secured by the fact that a Binding Update to the home agent is always		secured by the fact that a BU to the HA is always secure. In
	secure. In addition, the Access Router Option is fairly secured with		addition, the Access Router Option is fairly secured with the Return
	the Return Routability Tests. Thus the relaxation of the security		Routability Procedure. Thus the relaxation of the security measure
	measure of source address verification of a tunnel does not		of source address verification of a tunnel does not significantly
	significantly increase the home agent's vulnerability to attacks. It		increase the HA's vulnerability to attacks. It is also recommended
	is also recommended that the tunnel between the mobile node and the		that the tunnel between the mobile node and the home agent to be
	home agent to be secured by ESP or AH. In addition, we also		secured by ESP or AH. In addition, we also recommend that all
	recommend that all implementations to allow the support of this		implementations to allow the support of this ARO Solution to be
	Proposed NEMO Solution to be administratively disabled or enabled.		administratively disabled or enabled. The default should be enabled.
	The default should be enabled.
	8.4. Use of Extended Routing Header Type 2		9.4 Use of Extended Routing Header Type 2
	The extension of the Type 2 Routing Header exposes this solution to		The extension of the RH2 exposes this solution to additional security
	additional security threats in that attackers can change the entries		threats in that attackers can change the entries in the RH2 to be
	in the routing header to be routed to another entity. However, we		routed to another entity. However, we note that this extension is
	note that this extension is designed so that the extended Type 2		designed so that the extended RH2 is now very similar to the Type 0
	Routing Header is now very similar to the Type 0 Routing Header.		Routing Header. Thus, the security threats faced by RH2 is not a new
	Thus, the security threats faced by Type 2 Routing Header is not a		threat introduced by this solution itself. In any case, the harm an
	new threat introduced by this solution itself. In any case, the		attacker can do by changing the entries in the routing header is
	harm an attacker can do by changing the entries in the routing header		limited to:
	is limited to:
	(1) causing the packet to be routed to another entity for snooping		o causing the packet to be routed to another entity for snooping
	into the contents of the payloads;		into the contents of the payloads;
	(2) denial-of-service attack causing the packet to be discarded by		o denial-of-service attack causing the packet to be discarded by
	intermediate routers; and		intermediate routers; and
	(3) using the Type 2 Routing Header to reflect packets off a mobile		o using the RH2 to reflect packets off a mobile network.
	network.
	In the first two cases, given that the attacker has the ability to		In the first two cases, given that the attacker has the ability to
	change the contents in the routing header, it can perform the same		change the contents in the routing header, it can perform the same
	attack even if a Type 2 Routing Header is not used.		attack even if a RH2 is not used. For the threat where attacker
			construct a RH2 to reflect packets off a mobile network, we recommend
			that all routers supporting the RH2 to perform the following security
			measures:
	For the threat where attacker construct a Type 2 Routing Header to		o When the mobile node receives a packet with the destination field
	reflect packets off a mobile network, we recommend that all routers		set to its HoA or CoA, it should check for the existence of a RH2.
	supporting the Type 2 Routing Header to perform the following
	security measures:
	- When the mobile router receives a packet with the destination		Any packet that is sent to the mobile node's CoA without a RH2
	field set to its home-address or care-of-address, it should		should be discarded.
	check for the existence of a Type 2 Routing Header. Any packet
	that is sent to the mobile router's care-of-address without a
	Type 2 Routing Header should be discarded.
	- If the Segment Left field has a value of 1, the last address in		o If the Segment Left field has a value of 1, the last address in
	the routing header must contain the home-address of the mobile		the routing header must contain the HoA of the mobile node.
	router.
	- If the Segment Left field has a value greater than 1, the new		o If the Segment Left field has a value greater than 1, the new
	destination address must contain a valid address in one of its		destination address must contain a valid address in one of the
	ingress links.		mobile router's ingress links. If the mobile node is a mobile
			host, the packet should be discarded.
	Effectively, the above security checks ensure the mobile router will		Effectively, the above security checks ensure the mobile node will
	discard any packets it received with a Type 2 Routing Header that		discard any packets it received with a RH2 that requires it to
	requires the router to forward the packet through an egress link.		forward the packet through an egress link. This should reduce, if
	This should reduce, if not eliminate, the possibility of using the		not eliminate, the possibility of using the extended RH2 for
	extended Type 2 Routing Header for reflection attacks.		reflection attacks.
	In addition, it must be noted that the extended Type 2 Routing Header		In addition, it must be noted that the extended RH2 is mutable but
	is mutable but predictable. Thus, it can be protected using AH.		predictable. Thus, it can be protected using AH.
	8.5. Mutable Router Alert Option		9.5 Mutable Router Alert Option
	The mutable Router Alert Option is used in this memo to request/stop		The mutable Router Alert Option is used in this memo to request/stop
	subsequent routers to attempt to forward the packet directly to its		subsequent routers to attempt to forward the packet directly to its
	destination. Possible security threats identified are:		destination. Possible security threats identified are:
	- Adding a NEMO-Fwd RAO to a packet		The attacker can add a NEMO-Fwd RAO to a packet. This will cause
			subsequent mobile routers to perform BU with the destination.
	The attacker can add a NEMO-Fwd RAO to a packet. This will		When BU is successful, subsequent mobile routers will forward the
	cause subsequent mobile routers to perform binding update with		packets directly to the destination, causing the packet to be
	the destination. When binding update is successful, subsequent		discarded (due to failure of algorithm in Figure 9).
	mobile routers will forward the packets directly to the
	destination, causing the packet to be discarded (due to failure
	of algorithm in Figure 2).
	- Adding a NEMO-NFwd RAO to a packet
	The attacker can add a NEMO-NFwd RAO to a packet. This has no
	effect (other than causing AH to fail), since the default
	behavior of processing a packet with NEMO-NFwd RAO at a mobile
	router is the same as the default behavior of processing a
	packet without any RAO.
	- Changing a NEMO-Fwd RAO to NEMO-NFwd RAO		The attacker can add a NEMO-NoFwd RAO to a packet. This has no
			effect, since the default behavior of processing a packet with
			NEMO-NoFwd RAO at a mobile router is the same as the default
			behavior of processing a packet without any RAO.
	The attacker can change the value of the NEMO-Fwd RAO to a NEMO-		The attacker can change the value of the NEMO-Fwd RAO to a NEMO-
	NFwd RAO. The effect of this form of attack is to cause the		NoFwd RAO. The effect of this form of attack is to cause the
	packet to be delivered sub-optimally (i.e. nested tunnels).		packet to be delivered sub-optimally (i.e. nested tunnels).
	- Changing a NEMO-NFwd RAO to NEMO-Fwd RAO
	The attacker can change the value of the NEMO-NFwd RAO to a		The attacker can change the value of the NEMO-NoFwd RAO to a
	NEMO-Fwd RAO. The effect of this form of attack is to cause		NEMO-Fwd RAO. The effect of this form of attack is to cause
	subsequent mobile routers to perform binding update with the		subsequent mobile routers to perform BU with the destination.
	destination. When binding update is successful, subsequent		When BU is successful, subsequent mobile routers will forward the
	mobile routers will forward the packets directly to the		packets directly to the destination, causing the packet to be
	destination, causing the packet to be discarded (due to failure		discarded (due to failure of algorithm in Figure 9).
	of algorithm in Figure 2).
	All the security threats described above require the attacker to be		All the security threats described above require the attacker to be
	on the path of the packet route. In addition, the most severe effect		on the path of the packet route. In addition, the most severe effect
	the attacker can achieve is causing packets to be discarded at the		the attacker can achieve is causing packets to be discarded at the
	receiver. Since the attacker must be on the path of the packet		receiver. Since the attacker must be on the path of the packet
	route, the attacker can achieve the same effect by simply discarding		route, the attacker can achieve the same effect by simply discarding
	the intercepted packet. Thus, the use of mutable router alert option		the intercepted packet. Thus, the use of mutable router alert option
	described in this memo does not introduce any new security threats.		described in this memo does not introduce any new security threats.
	8.6. IPSec Processing
	It is strongly recommended that the mobile router uses IPSec		9.6 IPSec Processing
	protocols such as AH[18] or ESP[19] to secure the reverse tunnel with
	its home agent. This Proposed NEMO Solution introduces modifications
	to existing protocols that may interfere with IPSec Processing. This
	section will highlight the possible interference.
	8.6.1. Processing of Extended Routing Header Type 2		9.6.1 Processing of Extended Routing Header Type 2
	As covered in Section 5.5.2, the extended RH2 is a mutable but		As covered in Section 5.4.2, the extended RH2 is a mutable but
	predictable header, thus the sender must ordered the fields in the		predictable header, thus the sender must ordered the fields in the
	RH2 (and the destination address of the IPv6 header) as they will		RH2 (and the destination address of the IPv6 header) as they will
	appear at the final destination when generating the AH authentication		appear at the final destination when generating the AH authentication
	header.		header.
	8.6.2. Processing of Home Address Destination Option		9.6.2 Processing of Home Address Destination Option
	As specified in Mobile IPv6 [9], the originator should use its home-		As specified in MIPv6, the originator should use its HoA as the IPv6
	address as the IPv6 source address in the IPv6 header, and place its		source address in the IPv6 header, and place its CoA in the Home
	care-of-address in the Home Address field of the Home Address		Address field of the Home Address destination option, when generating
	destination option, when generating the AH authentication data.		the AH authentication data.
	The Proposed NEMO Solution allows mobile routers to modify the source		The ARO Solution allows mobile routers to modify the source address
	address of the IPv6 Header, thus when the source address field may no		of the IPv6 Header, thus when the source address field may no longer
	longer contain the care-of-address of the sender at the final		contain the CoA of the sender at the final destination.
	destination.
	All home agents MUST use the algorithm shown in Figure 2 of Section		All home agents MUST use the algorithm shown in Figure 9 of Section
	5.3 to establish the authenticity of the source address. Once the		5.2 to establish the authenticity of the source address. Once the
	source address is verified, the source address field will be replaced		source address is verified, the source address field will be replaced
	by the home-address specified in the Home Address destination option,		by the HoA specified in the Home Address destination option, and the
	and the Home Address field of the Home Address destination option		Home Address field of the Home Address destination option will be
	will be replaced with the care-of-address of the sender. This care-		replaced with the CoA of the sender. This CoA is obtained from the
	of-address is obtained from the receiver's Binding cache.		receiver's BCE.
	The above processing MUST be carried out before AH processing.		The above processing MUST be carried out before AH processing.
	8.6.3. Processing of Mutable Router Alert Option		9.6.3 Processing of Mutable Router Alert Option
	As described in Section 4.3.2, when the sender of a packet inserts a		As described in Section 4.3.2, when the sender of a packet inserts a
	NEMO-Fwd RAO to the packet, the receiver always received the RAO		NEMO-Fwd RAO or NEMO-BU RAO to the packet, the receiver always
	modified to NEMO-NFwd. Thus the mutable NEMO-Fwd RAO is predictable.		received the RAO modified to NEMO-NoFwd. Thus the mutable NEMO-Fwd
	When AH is used, the originator should use the NEMO-NFwd RAO to		RAO is predictable. It is thus possible for the originator to use
	generate the AH authentication data.		NEMO-NoFwd RAO to generate the AH authentication data. However, it
			is recommended that the RAO simply be left out of any IPSec
	Acknowledgements		processing.
	The authors would like to extend sincere gratitude to Thierry Ernst
	and Keisuke Uehara of the WIDE Project for their invaluable comments
	and suggestions to the initial draft of this memo.
	References
	[1] Bradner, S., "The Internet Standards Process -- Revision 3",
	BCP 9, RFC 2026, October 1996.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997
	[3] Soliman, H., and Pettersson, M., "Mobile Networks (MONET)
	Problem Statement and Scope", Internet Draft, draft-soliman-
	monet-statement-00.txt, Feb 2002, Work In Progress.
	[4] Ernst, T., and Lach, H., "Network Mobility Support
	Requirements", Internet Draft, draft-ernst-nemo-requirements-
	00.txt, Oct 2002, Work In Progress.
	[5] Lach, H. et. al., "Mobile Networks Scenarios, Scope and
	Requirements", Internet Draft, draft-lach-monet-requirements-
	00.txt, Feb 2002, Work In Progress.
	[6] Kniventon, T. J., and Yegin, A. E., "Problem Scope and
	Requirements for Mobile Networks Working Group", Internet
	Draft, draft-kniventon-monet-requiremetns-00.txt, Feb 2002,
	Work In Progress.
	[7] Perkins, C. E. et. al., "IP Mobility Support", IETF RCF 2002,		10 References
	Oct 1996.
	[8] DARPA, "Internet Protocol", IETF RFC 791, Sep 1981.		[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
			IPv6", RFC 3775, June 2004.
	[9] Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility		[2] Devarapalli, V., "Network Mobility (NEMO) Basic Support
	Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-		Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
	18.txt, Work In Progress, June 2002.		June 2004.
	[10] Deering, S., and Hinden, R., "Internet Protocol, Version 6		[3] Ernst, T., "Network Mobility Support Goals and Requirements",
	(IPv6) Specification", IETF RFC 2460, Dec 1998.		draft-ietf-nemo-requirements-02 (work in progress), February
			2004.
	[11] Kniveton, T., "Mobile Router Support with Mobile IP", Internet		[4] Thubert, P., Molteni, M. and C. Ng, "Taxonomy of Route
	Draft: draft-kniveton-mobrtr-01.txt, Work In Progress, Mar		Optimization models in the Nemo Context",
	2002.		draft-thubert-nemo-ro-taxonomy-02 (work in progress), February
			2004.
	[12] Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and		[5] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	Olivereau, A., "Mobile Networks Support in Mobile IPv6 (Prefix		draft-ietf-nemo-terminology-01 (work in progress), February
	Scope Binding Updates)", Internet Draft: draft-ernst-mobileip-		2004.
	v6-network-03.txt, Mar 2002.
	[13] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization		[6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC
	Models in the NEMO Context", Internet Draft: draft-thubert-		2711, October 1999.
	nemo-ro-taxonomy-00.txt, Work In Progress, Oct 2002.
	[14] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and		[7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Its Application to Mobile Networks", Internet Draft: draft-		Specification", RFC 2460, December 1998.
	thubert-nemo-reverse-routing-header-01.txt, Work In Progress,
	Oct 2002.
	[15] Ernst, T., and Lach, H., "Network Mobility Support		[8] Kent, S. and R. Atkinson, "Security Architecture for the
	Terminology", Internet Draft, draft-ernst-nemo-terminology-		Internet Protocol", RFC 2401, November 1998.
	00.txt, Oct 2002, Work In Progress.
	[16] Partridge, C., and Jackson, A., "IPv6 Router Alert Option",		[9] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
	IETF RFC 2711, Oct 1999.		November 1998.
	[17] Kent, S., and Atkinson, R., "Security Architecture for the		[10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
	Internet Protocol", IETF RFC 2401, Nov 1998.		(ESP)", RFC 2406, November 1998.
	[18] Kent, S., and Atkinson, R., "IP Authentication Header", IETF		[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
	RFC 2402, Nov 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[19] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload		[12] Conta, A. and S. Deering, "Internet Control Message Protocol
	(ESP)", IETF RFC 2406, Nov 1998.		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
			Specification", RFC 2463, December 1998.
	[20] Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery		[13] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
	for IPv6", IETF RFC 2461, Dec 1998.		Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
			Agents", RFC 3776, June 2004.
	Author's Addresses		Authors' Addresses
	Chan-Wah Ng		Chan-Wah Ng
	Panasonic Singapore Laboratories Pte Ltd		Panasonic Singapore Laboratories Pte Ltd
	Blk 1022 Tai Seng Ave #04-3530		Blk 1022 Tai Seng Ave #06-3530
	Tai Seng Industrial Estate		Tai Seng Industrial Estate
	Singapore 534415		Singapore 534415
	Phone: (+65) 6554 5420		SG
	Email: cwng@psl.com.sg
	Takeshi Tanaka
	Wireless Solution Laboratories
	Matsushita Communication Industrial Co Ltd
	5-3, Hikarinooka, Yokoshuka-shi, Kanagawa
	239-0847, Japan
	Phone: +81-468-40-5494
	Email: Takeshi.Tanaka@yrp.mci.mei.co.jp
	Appendices
	A. Route Optimization
	It is possible to extend the proposed solution described in this memo
	to perform route optimization for NEMO-enabled mobile network hosts.
	For an NEMO-enabled mobile network host, when it detects that its
	access router is NEMO-enabled (from the Router Advertisement), it
	sends Binding Update with Access Router Option to its home agent.
	From here, it will use reverse tunneling with its home agent to send
	packets to corresponding nodes. The mobile network nodes will also
	insert the NEMO-Fwd RAO into tunnel packet so as to achieve nested
	tunnel optimization.
	In order to achieve full route optimization, corresponding nodes are
	required to be NEMO-enabled. Specifically, they should be able to
	recognize the Access Router Option in a Binding Update message and
	set the appropriate Status code in a Binding Advertisement, be able
	to construct an extended Type 2 Routing Header using the algorithm
	specified in Figure 3 of Section 5.4, and be able to verify the
	source address of a received packet using the algorithm specified in
	Figure 2 of Section 5.3.
	B. Other NEMO Solution Proposals
	B.1. IPv6 Reverse Routing Header
	B.1.1. Overview of the Reversed Routing Header Solution
	The current proposal uses the notion of access router to allow home
	agents to construct routing header so that pinball effect of nested
	tunnels can be avoided in a nested NEMO. A very similar proposal is
	the use of Reverse Type 2 Routing Header proposed by Thubert et. al.
	[14], where a reverse routing header is attached to the tunnel packet
	sent by the lowest level mobile router. Subsequent upstream mobile
	routers would not further encapsulate the packet. Instead, they will
	move the source address of the incoming packet to the next available
	entry of the reverse routing header, and put their own care-of-
	address in the source address field. In this way, the home agent
	receiving this packet can construct the chain of access routers the
	mobile router is attached to. From there, a packet addressed to the
	mobile router (or to the NEMO controlled by the mobile router) can be
	sent with an extended Type 2 Routing Header similar to the mechanism
	proposed here.
	B.1.2. Comparison
	In comparison, the proposal by Thubert et. al. is more efficient. It
	does not require each mobile router on the path to perform binding
	updates with the home agent of the lowest-level mobile router, as
	this proposal do. Any change in the nested NEMO topology is
	immediately reflected in the reversed routing header. Whereas, for
	the solution proposed in this memo, changes in nested NEMO topology
	will have to be propagated slowly via binding updates sent by mobile
	routers at each nested level.
	However, the simplicity of the Reversed Routing Header solution is
	also its greatest disadvantage: it is extremely difficult to
	establish the credibility of the reverse routing header received by
	the home agent. Because of the lack of binding updates from the
	upper layer mobile routers, the home agent has no way of knowing if
	the reverse routing header is tampered with en-route. On the hand,
	the solution proposed in this memo uses Mobile IPv6 binding mechanism
	to establish the chain of routers an away node is attached to. Thus
	it does not introduce any additional security threats that are not
	already present in Mobile IPv6.
	Furthermore, the Reverse Routing Header solution requires home agents
	(and correspondent nodes, if route optimization is used) to maintain
	a list of reverse routing headers for each mobile router. This is
	more expensive (computationally and storage capacity wise) to
	maintain than a binding cache, since reverse routing header can vary
	in size. On the other hand, the solution proposed in this memo
	merely requires an additional column in the binding cache to record
	the access routers' addresses. However, admittedly, the current
	solution does increase the processing load of home agents and
	correspondent nodes by requiring them to construct a routing header
	from the binding cache.
	B.1.3. Possible Merging of Solutions
	As the Reverse Routing Header and the proposal described in this memo
	attempts to solve similar problems (i.e. nested tunnel optimization),
	it is possible to merge the two solutions. Both extend the routing
	header type 2 to contain more than one address. For the packet path
	from a mobile router to its home agent, [14] uses the reverse routing
	header to forward the packet and overcome ingress filtering, while
	the current proposal uses a Router Alert Option to request direct
	forwarding, and allow the upper level mobile routers to change the
	source address of the packet.
	A possible merged solution can have the following characteristics:
	(1) mobile routers use the Access Router Option to inform home
	agents the access routers they are currently attached to;
	(2) home agents use the Access Router Option to update their Binding
	Cache, where each entry in the Binding Cache contains an extra
	field to store the home-address of access router;
	(3) mobile routers attach the reverse routing header on tunnel
	packets for upper level routers to append their care-of-
	addresses; and
	(4) home agents use the extra field in the Binding Cache to check
	the legitimacy of the reverse routing header in a received
	tunnel packet.
	The above discussion outlines a possible approach to merge the two
	proposals. Further analysis is needed to establish the feasibility
	of such an approach.
	B.2. Prefix Scope Binding Update (PSBU)
	Other proposed solution includes Prefix Scope Binding Update proposed
	by Ernst et. al. [12]. The main idea in this work is to specify the
	prefix length in the Binding Update, so that correspondent nodes, as
	well as home agent, realize that any address falling into the home-
	prefix is bound to that care-of-address. The current proposal works
	well with such a Prefix Scope Binding Update, and can coexist or be
	merged as one solution.
	B.3. Hierarchical Mobile IPv6 (HMIPv6)
	One other candidate is Hierarchical Mobile IPv6 proposal (HMIPv6)
	[21]. Till date, it is unclear how HMIPv6 can be adopted as the NEMO
	solution.
	C. Examples
	This Section describes several examples to illustrate how the
	proposed solution works. These examples are based on the scenario
	described in Figure C.1 below. Here, LFN1 is a local fixed node
	attached to MR1. MR1 and MR2 are NEMO-enabled mobile routers, and
	HA1 and HA2 are the home agents of MR1 and MR2 respectively. LFN1 is
	communicating with a corresponding node CN1.
	HA1
	|
	+---------|---------+
	| |
	LFN1---MR1---MR2---- Internet ----CN1
	| |
	+---------|---------+
	|
	HA2
	C.1. Abbreviations
	In the following illustrations, the following abbreviations are used:
	ARO: Access Router Option
	BU: Binding Update
	BA: Binding Acknowledgement
	HAO: Home Address Destination Option
	RH2: extended Type 2 Routing Header
	C.2. MR1 attaches to MR2
	In this section, the messages exchange is described after MR1
	attaches to MR2.
	C.2.1. MR1 establishes binding to HA1
	(1) MR1 Receives RA from MR2
	When MR1 attaches to MR2, MR1 receives Router Advertisement with N
	bit set, Router Home Address Option = MR2.HoA from MR2. MR1 knows
	it is attached to a NEMO-enabled router.
	(2) MR1 sends BU to HA1
	BU sent from MR1 to HA1 looks like this:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Mobility Hdr
	BU (A bit=1)
	ARO (MR2.HoA)
	(3) MR2 encapsulates the BU
	When the BU reaches MR2, it will be further encapsulated into a
	tunnel between MR2 and HA2. The encapsulated packet from MR2 to
	HA2 will look like this:
	IPv6 Hdr (src=MR2.CoA, dst=HA2)
	Dst Opt
	HAO (MR2.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Mobility Hdr
	BU (A bit=1)
	ARO (MR2.HoA)
	Mobility Hdr
	BU (A bit=1)
	ARO (MR2.HoA)
	(4) HA2 processes the tunnel packet
	When HA2 receives the tunnel packet, it first processes AH/ESP
	with the address in HAO. Then HA1 checks if it has an entry for
	MR1.HoA as Home Address. Next HA1 decapsulates the packet, and
	forward the inner packet to HA1.
	(5) HA1 processes the BU
	HA1 first processes AH/ESP with the address in HAO, checking if it
	has an entry for MR1.HoA as Home Address. Next HA1 notices it has
	Access Router field and creates/updates binding entry for MR2 with
	Access Router field set. After this, the Binding Cache of HA1 has
	the following entry:
	Home Address Care-of Address Access Router
	------------ --------------- -------------
	MR1.HoA MR1.CoA MR2.HoA
	(6) HA1 sends BA to MR1
	BA sent from HA1 to MR1 looks like this:
	IPv6 Hdr (src=HA1, dst=MR2.HoA)
	RH2 ( Segments Left=2,
	Address[1]=MR1.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Mobility Hdr
	BA (status=ARO-OK)
	(7) HA2 receives the BA
	HA2 intercepts the packet from HA1 to MR2 and encapsulates it.
	Using the algorithm given in Figure 3 of Section 5.4, HA2
	constructs a RH2 and attaches it to the outer packet. Packet sent
	from HA2 looks like this:
	IPv6 Hdr (src=HA2, dst=MR2.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.HoA)
	AH/ESP hdr
	Encapsulated IPv6 Hdr (src=HA1, dst=MR2.HoA)
	RH2 ( Segments Left=2,
	Address[1]=MR1.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Mobility Hdr
	BA (status=ARO-OK)
	(8) MR2 receives BA
	MR2 receives the packet and processes the RH2. MR2 notices that
	the Segments Left field is 1 and verifies that the last address in
	RH2 is its own home-address. It decapsulates the packet and
	process the inner packet.
	The inner packet has destination field equals to the home-address
	of MR2. So MR2 processes the inner packet, and updates the RH2 of
	the inner packet. It verifies that the new destination is a valid
	address in its ingress interface, and sends it off.
	BA sent from MR2 to MR1 looks like this:
	IPv6 Hdr (src=HA1, dst=MR1.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.HoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Mobility Hdr
	BA (status=ARO-OK)
	(9) MR1 receives BA
	MR1 receives the packet and processes the RH2. Since Segments
	Left=1, it verifies that the last address in RH2 is its own home-
	address. After MR1 processes RH2, the packet looks like this:
	IPv6 Hdr (src=HA1, dst=MR1.HoA)
	RH2 ( Segments Left=0,
	Address[1]=MR2.HoA,
	Address[2]=MR1.CoA )
	AH/ESP Hdr
	Mobility Hdr
	BA (status=ARO-OK)
	Since MR1 has a SA with HA1, MR1 processes AH/ESP. After that,
	MR1 knows that the BU it sent previously was accepted by HA1.
	C.2.2. LFN1 sends packet to CN1
	(1) LFN1 sends packet to CN1
	Packet sent from LFN1 to CN1 looks like this:
	IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(2) MR1 receives packet from LFN1
	MR1 notices the packet does not have NEMO-Fwd RAO in it, thus MR1
	encapsulate it. Since access router of MR1 is NEMO-enabled, MR1
	adds NEMO-Fwd RAO to the outer packet.
	Packet sent from MR1 to MR2 looks like this:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-Fwd)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(3) MR2 receives packet from MR1
	MR2 notices the packet has NEMO-Fwd RAO in it, but MR2 does not
	have binding to the destination (=HA1), thus MR2 encapsulates the
	packet and tunnels to HA2. Since access router of MR2 is not
	NEMO-enabled, MR2 does not add NEMO-Fwd RAO to outer packet.
	Packet sent from MR2 to HA2 looks like this:
	IPv6 Hdr (src=MR2.CoA, dst=HA2)
	Dst Opt
	HAO (MR2.CoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-Fwd)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(4) HA2 receives packet from MR2
	HA2 receives the packet and verify that the source address is
	valid using the algorithm described in Figure 2 of Section 5.3.
	The packet is decapsulated and the inner packet is forwarded to
	HA1.
	The packet from HA2 to HA1 looks like this:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-Fwd)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(5) HA1 receives packet from HA2
	HA1 receives the packet and verify that the source address is
	valid using the algorithm described in Figure 2 of Section 5.3.
	The packet is decapsulated and the inner packet is forwarded to
	CN1.
	C.2.3. CN1 sends packet to LFN1
	(1) CN1 sends packet to LFN1
	Packet sent from CN1 to LFN1 looks like this:
	IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(2) HA1 receives packet from CN1
	Since address of LFN1 belongs to MR1, the packet is routed to HA1.
	HA1 notices MR1 is away from home, thus HA1 encapsulates the
	packet and constructs an extended RH2.
	Packet sent from HA1 looks like this:
	IPv6 Hdr (src=HA1, dst=MR2.HoA)
	RH2 ( Segments Left=2,
	Address[1]=MR1.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(3) HA2 receives packet from HA1
	Since the packet is addressed to MR2.HoA, it is routed to HA2.
	HA2 notices MR2 is away from home, thus HA2 encapsulates the
	packet and forwards to MR2.
	Packet sent from HA2 looks like this:
	IPv6 Hdr (src=HA2, dst=MR2.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=HA1, dst=MR2.HoA)
	RH2 ( Segments Left=2,
	Address[1]=MR1.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(4) MR2 receives packet from HA2
	MR2 receives the packet and processes the RH2. MR2 notices that
	the Segments Left field is 1 and verifies that the last address in
	RH2 is its own home-address. It decapsulates the packet and
	process the inner packet.
	The inner packet has destination field equals to the home-address
	of MR2. So MR2 processes the inner packet, and updates the RH2 of
	the inner packet. It verifies that the new destination is a valid
	address in its ingress interface, and sends it off.
	Packet sent from MR2 to MR1 looks like this:
	IPv6 Hdr (src=HA2, dst=MR1.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.HoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(5) MR1 receives packet from MR2
	MR1 receives the packet and processes the RH2. MR1 notices that
	the Segments Left field is 1 and verifies that the last address in
	RH2 is its own home-address. It decapsulates the packet and sends
	the inner packet to LFN1.
	C.2.4. MR2 establishes binding to HA1
	Since MR2 notices there is a request to directly forward packet to
	HA1, MR2 starts to establish binding with HA1.
	(1) MR2 performs Return Routability test to HA1
	(2) MR2 sends BU to HA1
	BU sent from MR1 to HA1 looks like this:
	IPv6 Hdr (src=MR2.CoA, dst=HA1)
	Dst Opt
	HAO (MR2.HoA)
	Mobility Hdr
	BU (A bit=1, Binding Auth data option)
	(3) HA1 processes the BU
	Next HA1 checks Binding Auth data. Then HA1 creates/updates
	binding entry for MR2.
	Binding Cache of HA1 has following entries:
	Home Address Care-of Address Access Router
	------------ --------------- -------------
	MR1.HoA MR1.CoA MR2.HoA
	MR2.HoA MR2.CoA <invalid>
	(4) HA1 sends BA to MR2
	BA sent from HA1 to MR2 looks like this.
	IPv6 Hdr (src=HA1, dst=MR2.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.HoA )
	AH/ESP Hdr
	Mobility Hdr
	BA(status=0)
	C.2.5. LFN1 sends packet to CN1
	(1) LFN1 sends packet to CN1
	Packet sent from LFN1 to CN1 looks like this:
	IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(2) MR1 receives packet from LFN1
	MR1 notices the packet does not have NEMO-Fwd RAO in it, MR1
	encapsulates it and adds NEMO-Fwd RAO to outer packet. Packet
	sent from MR1 to MR2 looks like this:
	IPv6 Hdr (src=MR1.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-Fwd)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(3) MR2 receives packet from MR1
	MR2 notices the packet has NEMO-Fwd RAO in it, and MR2 has binding
	to the destination (=HA1), thus MR2 changes the source address to
	MR2.CoA and sends the packet directly to HA1. Since access router
	of MR2 is not NEMO-enabled, MR2 changes NEMO-Fwd to NEMO-NFwd RAO.
	Packet sent from MR2 to HA1 looks like this:
	IPv6 Hdr (src=MR2.CoA, dst=HA1)
	Hop-by-Hop Opt
	RAO (NEMO-NFwd)
	Dst Opt
	HAO (MR1.HoA)
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
	Data
	(4) HA1 receives packet from MR2
	HA1 receives the packet and verify that the source address is
	valid using the algorithm described in Figure 2 of Section 5.3.
	The packet is decapsulated and the inner packet is forwarded to
	CN1.
	C.2.6. CN1 sends packet to LFN1
	(1) CN1 sends packet to LFN1
	Packet sent from LFN1 to CN1 looks like this:
	IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(2) HA1 receives packet from CN1
	HA1 intercepts the packet from CN1 to LFN1 and encapsulates it.
	Using the algorithm given in Figure 3 of Section 5.4, HA1
	constructs a RH2 and attaches it to the outer packet.
	Packet sent from HA1 to MR1 looks like this:
	IPv6 Hdr (src=HA1, dst=MR2.CoA)
	RH2 ( Segments Left=2,
	Address[1]=MR1.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(3) MR2 receives packet from HA1
	MR2 receives the packet and processes the RH2. The Segments Left
	field is decremented, and the destination address in the IPv6
	header is swapped with the next address in RH2. MR2 checks that
	the new destination address is a valid address in its ingress
	interface, and sends the packet out.
	Packet sent from MR2 to MR1 looks like this:
	IPv6 Hdr (src=HA1, dst=MR1.CoA)
	RH2 ( Segments Left=1,
	Address[1]=MR2.CoA,
	Address[2]=MR1.HoA )
	AH/ESP Hdr
	Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
	Data
	(4) MR1 receives packet from MR2
	MR1 receives the packet and processes the RH2. MR1 notices that
	the Segments Left field is 1 and verifies that the last address in
	RH2 is its own home-address. The inner packet is decapsulated and
	sent to LFN1.
	C.3. MR2 moves to new location
	In this section, the messages exchange is described after MR2 moves		Phone: +65 65505420
	to a new location. This section will demonstrate that a change in		EMail: cwng@psl.com.sg
	attachment of the upper level mobile router is transparent to nested
	nodes. Note that the binding update between MR2 and HA2 is not shown.
	C.3.1. MR2 sends binding update to HA1		Jun Hirano
			Matsushita Electric Industrial Co., Ltd. (Panasonic)
			5-3 Hikarino-oka
			Yokosuka, Kanagawa 239-0847
			JP
	After MR2 obtains a new care-of-address, it sends a new binding		Phone: +81 46 840 5123
	update to HA1 since HA1 is on the Binding Update List of MR2.		EMail: hirano.jun@jp.panasonic.com
	(1) MR2 performs Return Routability test to HA1		Appendix A. Acknowledgement
	(2) MR2 sends BU to HA1		The authors would like to express our sincere gratitude to Takeshi
			Tanaka for his contribution to the initial version of this draft. In
			addition, appreciation is also extended to Thierry Ernst, Pascal
			Thubert, and various people in the NEMO WG who have given us valuable
			comments.
	BU sent from MR2 to HA1 looks like this:		Intellectual Property Statement
	IPv6 Hdr (src=MR2.CoA, dst=HA1)		The IETF takes no position regarding the validity or scope of any
	Dst Opt		Intellectual Property Rights or other rights that might be claimed to
	HAO (MR2.HoA)		pertain to the implementation or use of the technology described in
	Mobility Hdr		this document or the extent to which any license under such rights
	BU (Binding Auth data option)		might or might not be available; nor does it represent that it has
			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.
	(3) HA1 processes the BU		Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Next HA1 checks Binding Auth data. Then HA1 updates binding entry		The IETF invites any interested party to bring to its attention any
	for MR2.		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.
	Binding Cache of HA1 has following entries:		Disclaimer of Validity
	Home Address Care-of Address Access Router		This document and the information contained herein are provided on an
	------------ --------------- -------------		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	MR1.HoA MR1.CoA MR2.HoA		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	MR2.HoA MR2.nCoA <invalid>		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING 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.
	It should be noted that the state of the Binding Cache is very		Copyright Statement
	similar to the state at Section C.2.4. Thus packets sent from
	LFN1 and CN1 to each other will go through only one level of
	encapsulation, as illustrated in Sections C.2.5 and C.2.6.
	This serves to demonstrate a change in attachment of the upper		Copyright (C) The Internet Society (2004). This document is subject
	level mobile router is transparent to nested nodes.		to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
	Additional References		Acknowledgment
	[21] Soliman, H., Castelluccia, C., El-Malki, K., and Bellier, L.,		Funding for the RFC Editor function is currently provided by the
	"Hierarchical MIPv6 Mobility Management (HMIPv6)", Internet		Internet Society.
	Draft: draft-ietf-mobileip-hmipv6-07-txt, Work In Progress, Oct
	2002.
End of changes. 292 change blocks.
	1749 lines changed or deleted		1412 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/