wdiff draft-ng-nemo-access-router-option-00.txt draft-ng-nemo-access-router-option-01.txt

Network
NEMO Working Group C. W. Ng
Internet-Draft Panasonic Singapore Labs
Expires: April 2003 T. Tanaka
Matsushita Communications Ind

October 2002 January 10, 2005 J. Hirano
Panasonic
July 12, 2004

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

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026 [1].
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

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
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 10, 2005.

Abstract

Through

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, global connectivity can be extended to nodes
within a network in motion. agent. However, the multiple levels this sub-optimal
routing, especially when nesting of bi-
directional tunnels in nested mobile networks lead to undesirable
effects. 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 router 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 routers nodes to securely achieve nested tunnels optimization.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
optimization, and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2]. even full route optimization.

Table of Contents

1. Introduction...................................................4
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terms Used................................................5
1.2. Assumptions...............................................5
1.3. Organization..............................................6 Used . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Change Log . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of Operation..........................................6
2.1. Operation . . . . . . . . . . . . . . . . . . . . 7
2.1 Router Advertisement......................................7
2.2. Advertisement . . . . . . . . . . . . . . . . . . . 7
2.2 Binding Update from MR1 to HA1............................7
2.3. HA1 . . . . . . . . . . . . . . 7
2.3 Binding Update from MR2 to HA1............................7
2.4. HA1 . . . . . . . . . . . . . . 8
2.4 Forwarding Packets from HA1 to MR1........................8
2.5. MR1 . . . . . . . . . . . . 8
2.5 Forwarding Packets from MR1 to HA1........................8 HA1 . . . . . . . . . . . . 9
2.6 Scenario with a Local Fixed Router . . . . . . . . . . . . 9
2.7 Route Optimization with Mobile Network Hosts . . . . . . . 10
3. Changes to Existing Protocols..................................9
3.1. Protocols . . . . . . . . . . . . . . . . 12
3.1 Modifications to NEMO Basic Support / Mobile IPv6..............................9
3.1.1. IPv6 . . . . 12
3.1.1 Addition of Access Router Option.....................9
3.1.2. Option . . . . . . . . . . . 12
3.1.2 Extending Type 2 Routing Header.....................10
3.1.3. Extending Binding Acknowledgement Message...........12
3.1.4. Router Header . . . . . . . . . . . . 13
3.1.3 Modification to Conceptual Data Structures..........12
3.2. Structures . . . . . . 14
3.2 Modifications to IPv6 Neighborhood Discovery.............12
3.2.1. Extension to Router Advertisement...................12
3.2.2. Neighbor Discovery . . . . . . . . . 15
3.2.1 Addition of a New Option in Router Advertisement....13
3.3. Advertisement . . . . 15
3.3 Modifications to ICMPv6 . . . . . . . . . . . . . . . . . 16
3.3.1 New Router Global Address ICMP Message . . . . . . . . 16
3.4 Extending the Router Alert Option........................14 Option . . . . . . . . . . . . 18
4. Operation of NEMO-enabledMobile Router........................15
4.1. ARO-Enabled Mobile Routers . . . . . . . . . . . 20
4.1 Operation when When Mobile Router is at Home..................15
4.1.1. At Home . . . . . . . . . 20
4.1.1 Sending Router Advertisement........................15
4.1.2. Advertisement . . . . . . . . . . . . . 20
4.1.2 Processing Outbound Packets.........................15
4.1.3. Packets . . . . . . . . . . . . . 20
4.1.3 Processing Inbound Packets..........................16
4.2. Packets . . . . . . . . . . . . . . 20
4.2 Operation when When Mobile Router is Away.....................16
4.2.1. Away . . . . . . . . . . . 21
4.2.1 Sending Router Advertisement........................16
4.2.2. Advertisement . . . . . . . . . . . . . 21
4.2.2 Receiving Router Advertisement......................16
4.2.3. Advertisement . . . . . . . . . . . . 21
4.2.3 Sending Binding Updates.............................17
4.2.4. Updates . . . . . . . . . . . . . . . 21
4.2.4 Processing Outbound Packets.........................17
4.2.5. Packets . . . . . . . . . . . . . 22
4.2.5 Processing Inbound Packets..........................18
4.3. Packets . . . . . . . . . . . . . . 23
4.3 IPSec Processing.........................................19
4.3.1. Processing . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 IPSec Processing on Inbound Packets.................19
4.3.2. Packets . . . . . . . . . 24
4.3.2 IPSec Processing on Outbound Packets................19 Packets . . . . . . . . . 24
5. Operation of NEMO-enabled ARO-Enabled Home Agent..........................20
5.1. Sending Router Advertisement.............................20
5.2. Agents . . . . . . . . . . . . . 25
5.1 Receiving Binding Updates................................20
5.3. Updates . . . . . . . . . . . . . . . . 25
5.2 Receiving Tunneled Packets from Away Nodes...............20
5.4. Nodes . . . . . . . . 25
5.3 Tunneling Packets to Away Nodes..........................21
5.5. Nodes . . . . . . . . . . . . . 26
5.4 IPSec Processing.........................................23
5.5.1. Processing . . . . . . . . . . . . . . . . . . . . . 28
5.4.1 IPSec Processing on Inbound Packets.................23
5.5.2. Packets . . . . . . . . . 28
5.4.2 IPSec Processing on Outbound Packets................23 Packets . . . . . . . . . 28
6. Operation of ARO-Enabled Mobile Network Nodes . . . . . . . . 29
6.1 Nested Tunnel Optimization with Home Agent . . . . . . . . 29
6.2 Receiving Router Advertisement . . . . . . . . . . . . . . 29
6.3 Sending Binding Updates . . . . . . . . . . . . . . . . . 29
6.4 Sending Data Packets . . . . . . . . . . . . . . . . . . . 30
6.5 Processing Inbound Packets . . . . . . . . . . . . . . . . 30
6.6 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 31
6.6.1 IPSec Processing on Inbound Packets . . . . . . . . . 31
6.6.2 IPSec Processing on Outbound Packets . . . . . . . . . 31
7. Operation of ARO-Enabled Correspondent Node . . . . . . . . . 32
7.1 Receiving Binding Updates . . . . . . . . . . . . . . . . 32
7.2 Receiving Route Optimized Packets from Mobile Nodes . . . 32
7.3 Sending Route Optimized Packets to Mobile Nodes . . . . . 32
7.4 IPSec Processing . . . . . . . . . . . . . . . . . . . . . 33
7.4.1 IPSec Processing on Inbound Packets . . . . . . . . . 33
7.4.2 IPSec Processing on Outbound Packets . . . . . . . . . 33
8. Design Considerations . . . . . . . . . . . . . . . . . . . . 34
8.1 Considerations in the Use of Mutable Router Alert Option......24
6.1.
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1.1 Overview of Router Alert Option......................................24
6.2. Option . . . . . . . . . . . 34
8.1.2 Example where an Immutable RAO is Used...................24
6.3. Used . . . . . . . . 34
8.1.3 The Need for Mutable RAO.................................26
6.4. Sub-Optimality of NEMO-NFwd RAO..........................26
6.5. RAO . . . . . . . . . . . . . . . 36
8.1.4 Alternatives to the Mutable Router Alert Option..........27
6.5.1. IPv6 Flow Label.....................................27
6.5.2. New Routing Header Type.............................27
7. Changing Option . . . 36
8.2 Change of Source Address by Intermediate Routers...............28
7.1. Justifications...........................................28
7.2. Alternatives.............................................28
8. . . . . . . . . . . . . . . . . . 37
8.2.1 Justifications . . . . . . . . . . . . . . . . . . . . 37
8.2.2 Alternatives . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations.......................................28
8.1. Considerations . . . . . . . . . . . . . . . . . . . 39
9.1 Addition of Access Router Option.........................28
8.2. Option . . . . . . . . . . . . . 39
9.2 Router Global Address Option.............................30
8.3. Option . . . . . . . . . . . . . . . 40
9.3 Accepting Tunnel with a Source Address not Directly
Bound to the Home Address..............................................30
8.4. Address . . . . . . . . . . . . . . . . 40
9.4 Use of Extended Routing Header Type 2....................31
8.5. 2 . . . . . . . . . . 41
9.5 Mutable Router Alert Option..............................32
8.6. Option . . . . . . . . . . . . . . . 42
9.6 IPSec Processing.........................................33
8.6.1. Processing . . . . . . . . . . . . . . . . . . . . . 43
9.6.1 Processing of Extended Routing Header Type 2........33
8.6.2. 2 . . . . . 43
9.6.2 Processing of Home Address Destination Option.......33
8.6.3. Option . . . . 43
9.6.3 Processing of Mutable Router Alert Option...........34
Acknowledgements.................................................34
References.......................................................34
Author's Addresses...............................................36
Appendices.......................................................36 Option . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
A. Route Optimization............................................36
B. Other NEMO Solution Proposals.................................37
B.1. IPv6 Reverse Routing Header..............................37
B.2. Prefix Scope Binding Update (PSBU).......................38
B.3. Hierarchical Mobile IPv6 (HMIPv6)........................39
C. Examples......................................................39
C.1. Abbreviations............................................39
C.2. MR1 attaches to MR2......................................40
C.2.1. MR1 establishes binding to HA1.........................40
C.2.2. LFN1 sends packet to CN1...............................42
C.2.3. CN1 sends packet to LFN1...............................44
C.2.4. MR2 establishes binding to HA1.........................46
C.2.5. LFN1 sends packet to CN1...............................46
C.2.6. CN1 sends packet to LFN1...............................47
C.3. MR2 moves to new location................................48
C.3.1. MR2 sends binding update to HA1........................49
Additional References............................................49 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . 47

1. Introduction

The problem of Network Mobility Support (NEMO) is identified in
various previous works [3,4,5,6]. In essence, the problem of network
in motion is to provide continuous Internet connectivity to nodes in
a network that moves as a whole. Nodes within the network that moves
may not be aware of the network changing its point of attachment to
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 for provisioning route
optimization in Network Mobility (NEMO). This solution is based built on
extension
top of Mobile IPv6 (MIPv6) [1] and bi-directional tunneling between the
mobile router controlling the mobile network and its home agent
[11][12]. As described NEMO Basic Support [2][3]. The
general problem of route optimization 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 analyzed and tunnel
summarized in [4].

The proposed solution described in this memo aims to solve the packet
following route optimizations problems:

o Nested Tunnel Optimization

This optimization problem is to eliminate the mobile router's care-of-address, based on nesting of tunnels
for a previous Binding
Update (possibly Prefix-Scoped Binding Update [12]) sent by the nested mobile router. In addition, network. The proposed solution requires
changes to the mobile router will encapsulate
outbound packets to its (MR) and home agent through the bi-directional tunnel
for delivery.

This memo addresses the basic NEMO solution with some route
optimization. It proposes various modifications to some aspects of
Mobile IPv6 (HA)
implementation so that problems no matter how many level of bi-directional tunneling that arose
when other mobile hosts or networks attached themselves to nesting a
mobile network (thus forming what has, there is called only one tunnel between the innermost
MR and its HA.

o Nested Mobile Networks) are
solved. More specifically, the solution described in this document
attempts Tunnel Optimization for MIPv6

This optimization problem is to solve eliminate the problem nesting of Nested Tunnels Optimization as
described tunnels
for a MIPv6 host in [13]. In [14], Thubert et. al. proposed the use of a
Reverse Type 2 Routing Header mobile network. The proposed solution
requires changes to solve the problem of Nested Tunnels
Optimization. In essence, the proposal requires MR, MIPv6 host, and HA (for both the first MR
and MIPv6 host) implementation so that for a visiting mobile
router to attach host
in 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 network, the incoming packet to only tunnel necessary is the next available entry of one between
the reverse routing header, MIPv6 host 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 its HA, without additional encapsulation at the mobile router
MR.

o MIPv6 over NEMO Optimization

This optimization problem is
attached to. From there, a packet addressed to allow the mobile router (or
to any nodes attached MIPv6 route optimization
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
solution, as admitted by Thubert et. al. work between a MIPv6 host in their proposal. It is
the main objective of this memo to propose a relatively secure mobile network (i.e. visiting
mobile host) and its correspondent node (CN). The proposed
solution requires changes to the nested tunnel optimization problem. The solution
proposed here defines MR, MIPv6 host, and CN
implementation so that a new option in mobility headers specified visiting mobile host in
[9]. This new option, called the Access Router Option, is used by
the sender (i.e. the a mobile router) network
can perform route optimization with a CN, without any tunneling
back to inform the recipient (e.g. home agent) the global address agents of either the access router the sender is
attached to. From the information provided in the Access Router
Option, the recipient can then construct MIPv6 host or MR.

Various different proposals have been submitted to the chain NEMO Working
Group to solve different aspects of access routers the sender is attached to. This can be used route optimization problem of
network mobility. Readers are encouraged to construct the
extended Type 2 Routing Header.

1.1. 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
described in [15], [5] and the terms described those defined in [13]. [4]. In addition, [4] also
presents a detailed description of the problem of nested tunnels route optimization is
given in Section 2 of [13]. It will not be duplicated
in this memo. NEMO.

Apart from the terms described in [15] [5] and [13], [4], we further define the
following terminology:

Access Router (AR)

Any router that is the point of attachment to the Internet of one
or more visiting mobile node (VMN). We use the phrase "access
router of node X" to loosely refer to the router a node X attaches
to. An access router can be a mobile router
(MR).

Proposed NEMO Solution, NEMO-enabled MR.

ARO-Solution, ARO-enabled

To aid our illustration, we refer to the solution proposed in this
memo as the "Proposed NEMO Solution". "ARO-Solution". Any network nodes that implements the "Proposed NEMO Solution"
"ARO-Solution" is referred to as a "NEMO-enabled" "ARO-enabled" node.

1.2. Assumptions

This memo makes the following assumptions:

(1) A mobile router has only one active egress interface, and thus
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.
Local Fixed Routers (LFR) are assumed to be not NEMO-enabled.

(3) All home agents of mobile routers are assumed to be NEMO-enabled.

The first assumption precludes multi-homed mobile networks. We are
currently analyzing the proposed solution to understand its
applicability to multi-homed NEMO.

1.3.

1.2 Organization

In the remaining portions of this memo, we will first describe an begin in Section 2 by giving a general
overview of the operation proposed ARO Solution in Section 2. Following which, Section 3
will list operation. This is followed
by a detailed description of the modifications to existing protocols this memo proposes
in detail. The operations Section 3. Following which, the operation of each entity: mobile routers and
router, home agents agent, mobile network node, and correspondent node that
support the ARO Solution are
described separately in Sections detailed respectively from Section 4 and 5.
through Section 6 discusses 7. In Section 8, we list 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 design
considerations when formulating the source address of a packet. ARO Solution. Finally, Section 8
presents the security considerations.

Three appendices are attached at the end of this document. Appendix
A discusses the possibility of extending the proposal described
considerations in
this memo to achieve full router optimization. Appendix B compares
the proposal described discussed in this memo Section 9.

1.3 Change Log

o Changes from version -00 to other proposed solutions for
NEMO. Appendix C describes an example -01

* Extended solution to illustrate how the be able to optimized over local fixed
router with inclusion of NEMO-BU RAO

* Inclusion of NEMO-BU RAO and a new ICMPv6 message

* Extended solution
proposed in this memo works. for optimization between MR and CN

* Extended solution for optimization between VMN and CN/HA

* Included operations of CN and VMN

2. Overview of Operation

This section gives an overview of the operation of the proposed
solution. We use the scenario illustrated in Figure 1 below as an
example to describe the operation of the proposed solution. ARO-solution.

HA1
|
+---------|---------+
| |
LFN1---MR1---MR2---- Internet ----CN1
| |
+---------|---------+
|
HA2

Figure 1: Example Scenario

In Figure 1, LFN1 is a local fixed node attached to the ingress
interface of the visiting mobile router (VMR) MR1. MR1 is itself
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
communicating with a correspondent node CN1.

2.1.

2.1 Router Advertisement

When MR1 first obtains a Router Advertisement (RA) from MR2, it
checks if MR2 supports the Proposed NEMO Solution. ARO-Solution. This is determined by a bit flag in the RA message. In the RA message, NEMO-
enabled routers should include an
additional option to advertise their home-
address (known as well.

2.2. Router Global Address Option, or RGAO)
that advertises the home-address (HoA) of MR2.

2.2 Binding Update from MR1 to HA1

After MR1 obtains a care-of-address (CoA), it sends Binding Update
(BU) to its home agent, HA1. The BU message message, beside having the
prefix informations as detailed in [2], also contains an important
extension, known as the "Access Router Option" (ARO). This ARO
specifies the global address of MR2, thus informing HA1 the access
router MR1 is currently attached to. In this case, since MR2 is
itself a mobile router, the global address is the home-address (HoA) HoA of MR2.

HA1 records this together with the binding update entry in its the
corresponding binding cache. cache entry (BCE). When returning the Binding Acknowledgement
Acknowledgment (BA), HA1 can then made use of the extended Type 2
Routing Header (RH2) to forward the BA message to MR1 via the HoA of
MR2. Here, the RH2 as defined by Mobile IPv6 specification [9] [1] is
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
will be intercepted by HA2. Here, we assume that the binding cache
entry BCE of HA2
contains a binding of the current CoA and HoA of MR2. Thus, HA2 will
tunnel the packet to the CoA of MR2. When MR2 receives and
decapsulates the BA message, it notices that there is an extended
RH2. It proceeds to swap the destination address with the
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
final destination of the packet, and consumes the BA message.

2.3.

2.3 Binding Update from MR2 to HA1

From the processing of the extended RH2 as described previously, MR2
can deduce the following two facts:

(1)

1. the sender (i.e. HA1) does not have a binding cache entry BCE of MR2's current CoA,
since the received packet is encapsulated in a tunnel from HA2,
and

(2)

2. HA1 is NEMO-enabled, ARO-enabled, since an extended RH2 is used.

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
MR2. Thus, the Return Routability (RR) Test procedure specified in [9] [1]
must be carried out before sending the BU message. Note also that
since HA1 is treated as a correspondent node, MR2 should not insert
any prefix information (i.e. Mobile Network Prefix Option [2]) in
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- ARO-
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.
To simply our description, we assume that this is not the case.

2.4.

2.4 Forwarding Packets from HA1 to MR1

After receiving the BU message from MR2, the bi-directional tunnel
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
the CoA of MR2 with an attached extended RH2.

As an illustration, suppose CN1 now sends a packet to LFN1. The
packet will be intercepted by HA1. HA1 checks its routing table and
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
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
entry BCE of MR2.
Thus, the tunnel should be configured, with an extended RH2, such
that it reaches CoA of MR1 via CoA MR2. In this case, the
destination address of the outer packet is set to the CoA of MR2, and
the entries in the RH2 are the CoA and HoA of MR1, in that order.
When MR2 receives such a packet, it updates the RH2 (i.e. swap the
destination address with the next entry in the RH2), and forward the
packet to the new destination (i.e. CoA of MR1). MR1 upon receiving
the packet will verify that it is the final destination of the outer
packet, and decapsulates the packet. The inner packet is addressed
to LFN1, a valid address in the subnet of MR1. Hence, MR1 forwards
the packet to its appropriate ingress interface.

2.5.

2.5 Forwarding Packets from MR1 to HA1

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
external
outer packet is appended with a mutable Router Alert Option (RAO)
[16],
[6], in addition to the Home Address destination Option (HAO). This
RAO requests upstream routers that support the Proposed NEMO Solution are ARO-enabled to forward packet
directly to the destination. When MR2 receives this packet and
noticed the RAO, it checks if it has a binding update with the
specified destination (from its Binding Update List). If so, it
changes the source address to its CoA and sends the packet to the
destination. Else, the packet is tunneled to HA2, i.e. normal
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 subsequent packets can be forwarded directly to the destination
(without going through an additional level of encapsulation).

When HA1 receives an encapsulated packet, it verifies that the outer
packet originated from authentic source. This is done by checking
that the originator (that is specified by the HAO) has a binding
entry BCE that
indicates the mobile router identified by the source address is a
valid access router of the originator. HA1 then overwrites the
source address with the HoA specified in HAO and processes it as per Mobile IPv6
MIPv6 specifications [9].

A [1].

Section 4 describes in greater detail example showing the sequence operation of an ARO-enabled
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 exchange 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 Appendix C. 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.1.

3.1 Modifications to NEMO Basic Support / Mobile IPv6

3.1.1.

3.1.1 Addition of Access Router Option

The Access Router Option (ARO) is a new option for Mobility Header
defined in Mobile IPv6. IPv6 and NEMO Basic Support. Its format is shown
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 = TBA | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Access Router Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Access Router Option

Type

8-bit identifier of the Mobility Header option type. The value
that identifies an Access Router Option is yet to be assigned.

Length

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.

Access Router Address

Global address of the access router that the sender is currently
attached to.

The Access Router Option is only valid in a Binding Update 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
router by making use of extended Type 2 Routing Header. Section 8.1 9.1
addresses some security considerations on the use of the Access
Router Option.

3.1.2.

3.1.2 Extending Type 2 Routing Router Header

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
the type 0 routing header. The format of the modified Type 2 Routing
Header is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=2| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address [1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. . . . .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address [n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Extended Type 2 Routing Header

Next Header

8-bit selector. Identifies the type of header immediately
following the Routing Header. Uses the same value as the IPv6
Next Header field [10]. [7].

Hdr Ext Len

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.

Routing Type

8-bit unsigned integer that contains the value 2.

Segments Left

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
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]
vector. The last address, Address[n], must be the HoA of the
intended recipient. Note also that Hdr Ext Len field must always
contain an even number.

Each mobile router MR that receives a packet with the Type 2 Routing Header and the
destination field equals to its address must checked if Segments Left
field is equal to 1. If yes, the last address in the Address[]
vector must be its HoA. Else the packet is discarded. If
Segments-Left is non-zero, it decrements the Segment-Left field, and
swaps the destination field with the next address in the Address[]
vector. To work out which address to swap, the mobile
router MR can divide the Hdr
Ext Len field by 2 (which gives the number of entries in Address[]
vector), and subtract Segment Left from it.

The extended Type 2 Routing Header is a mutable but predictable IPv6
header. Thus IP Security (IPSec) [17] [8] protocols such as
Authentication Header (AH) [18] [9] and Encapsulating Security Payload
(ESP) [19] [10] can be used with the routing header. Security
considerations on the extension of Type 2 Routing Header are
presented in Section 8.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. 9.4.

3.1.3 Modification to Conceptual Data Structures

In Mobile IPv6 [9], [1], the Binding Cache data structure is defined to
contain entries of home-address HoA to care-of-address CoA bindings. This
Proposed NEMO Solution extends Basic Support [2]
suggested the extension of each Binding Cache entry 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.

When updating the Binding Cache entry, BCE, 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.

3.2 Modifications to IPv6 Neighborhood Discovery

3.2.1. Extension to Router Advertisement

A single bit flag is added to the Router Advertisement specified in
IPv6 Neighbor Discovery [20] so that a sender can advertise to the
recipients it is a router capable of supporting the Proposed NEMO
Solution. Here an N bit is introduced, thus reducing the reserved
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
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.

3.2.1 Addition of a New Option in Router Advertisement

A new option, Router Global Address Option (RGAO) is defined here.
This new option can only appear in a Router Advertisement message,
its format is 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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router Global Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Router Global Address Option

Type

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.

Length

8-bit unsigned integer that gives the length of the option in
8-octet units. Always equals to 3 for the Router Home Global Address
Option.

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 option allows the sender to advertise its egress interface
global address to nodes attached to its ingress interface(s). This
allows mobile nodes to include an Access Router Option when sending
Binding Updates. In addition, it is speculated that the global
address
BU. Inclusion of this option in a RA message would imply the sender may prove to be useful for fast handover
operations.
is ARO-enabled.

Security considerations for the Router Global Address Option are
listed in Section 8.2. 9.2. According to Section 4.2 of RFC2461[20], IPv6 Neighbor
Discovery [11], receivers that do not understand this new option MUST
silently ignore the option and continue processing the Router
Advertisement message.

3.3.

3.3 Modifications to ICMPv6

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 [16] [6] has the following format:

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 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 remaining five bits is the Hop-by-Hop Option Type number. By
zeroing all three, this specification requires that nodes not
recognizing this option type should skip over this option and
continue processing the header, and that the option must not change
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- ARO- enabled
access router will change the value code. Thus, this memo propose a
mutable Router Alert Option, of the following format:

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 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 value 5 in the remaining five bits. Thus the Hop-by-Hop Option
Type number is 0x25 (hexidecimal). (hexadecimal). By zeroing the first two bits,
this memo requires that nodes not recognizing this option type should
skip over this option and continue processing the header.

The Value code in the mutable Router Alert Option is extended to
contain two three extra values to be assigned. For purpose of
description, we call these two values the NEMO-Forward NEMO-Forward, NEMO-No-Forward,
and NEMO-No-Forward. NEMO-BU. Hereafter, mutable Router Alert Option with Value code
equal to NEMO- Forward will be known as a NEMO-Forward Router Alert
Option, or simply, NEMO-Fwd RAO, and RAO; mutable Router Alert Option with
Value code equal to NEMO-No-Forward will be known as a
NEMO-No-Forward Router Alert Option, or simply, NEMO-NFwd 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 ARO-Solution should recognize
the NEMO-Fwd RAO and attempt to forward the packet directly to the
destination without using a reverse tunnel. If necessary, the router
can change the source address of the packet to the current
care-of-address CoA of the
router in order to pass through ingress filters of subsequent
routers/gateways.

Intermediate routers that support the Proposed NEMO Solution ARO-Solution should recognize
the NEMO-No-Fwd NEMO-NoFwd RAO, and behave as if the RAO is not present.
Specifically, the router MUST NOT change the source address of the
packet.

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 6 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.

4. Operation of NEMO-enabledMobile Router

4.1. ARO-Enabled Mobile Routers

4.1 Operation when When Mobile Router is at At Home

This section describes the operation of a mobile router MR when it is attached to
its home link.

4.1.1.

4.1.1 Sending Router Advertisement

When the mobile router MR sends Router Advertisement, the mobile router
should set N-flag to 1, indicating to recipients RA message, it is a NEMO-enabled
router. In addition, the mobile router should advertise its home-
address HoA by adding a Router Global Address Option
RGAO in the Router
Advertisement RA message.

4.1.2. This also indicates to the recipients that
the MR is ARO-enabled.

4.1.2 Processing Outbound Packets

When the mobile router MR intercepts an outbound packet from its ingress interface,
it first checks if the packet contains a NEMO-Fwd RAO or a NEMO-BU
RAO. Packets that do not contain a NEMO-Fwd RAO, or packets that
contain a
NEMO-NFwd NEMO-NoFwd RAO are simply forwarded to its egress
interface. For packet that contains a NEMO-Fwd RAO, since the mobile router MR is
at home, it changes the NEMO-Fwd RAO to a NEMO-NFwd NEMO-NoFwd RAO and forwards
the packet to its egress interface.

4.1.3.

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.

4.1.3 Processing Inbound Packets

When the mobile router MR is at home, it functions like a normal router. Thus it
will consume any packet that is addressed to its home-
address, HoA, 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, MR's HoA, the packet may contain
an extended RH2. The Segments Left field of RH2 is checked. If
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
in one of the ingress interfaces of the mobile router. MR. If yes, the packet is
forwarded to the new destination. Else, the packet is silently
discarded.

4.2.

4.2 Operation when When Mobile Router is Away

This section describes the operation of a mobile router MR when it is away from its
home link.

4.2.1.

4.2.1 Sending Router Advertisement

The mobile router MR would continue to send Router Advertisement RA messages to its ingress interface(s)
when it is away. It should behave as specified in Section 4.1.1.
There is no difference in the Router Advertisement RA message whether the mobile
router MR is at home or
away.

4.2.2.

4.2.2 Receiving Router Advertisement

The mobile router MR should solicit router advertisement RA from its access router whenever it changes
its point of attachment to the Internet. When the mobile router MR receives the Router Advertisement,
RA, it should check if the access router has set included the N-flag to 1. If RGAO in the N-flag
RA message. If an RGAO is
set to 1, present, the access router is NEMO-enabled. ARO-enabled.
If the flag no RGAO is set to
0, present, the access router is not NEMO-enabled.

4.2.3. ARO-enabled.

4.2.3 Sending Binding Updates

When the mobile router MR sends Binding Updates BU to other hosts, either its own home agent HA or other
correspondent nodes, it should add an
Access Router Option ARO to the Binding Updates BU messages if its
access router is
NEMO-enabled. 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 NEMO-enabled, ARO-enabled, the mobile router MR
will not include the Access Router Option ARO in the
Binding Update BU messages.

When sending Binding Updates BU with the Access Router Option, ARO, especially to hosts nodes that it the MR does
not know to be NEMO-enabled, ARO-enabled, the
mobile router MR should request for a Binding Acknowledgement BA so that it
can determine if the host recipient supports the Proposed NEMO Solution ARO-Solution by
inspecting checking
if the Status code. ARO is present in the BA message. If the Status code ARO is 0, present, the host
node is ARO-enabled.

If the access router is not
NEMO-enabled.

4.2.4. 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.

If no response is received after a short timeout period, the MR
should concede that there is no ARO-enabled router upstream.

4.2.4 Processing Outbound Packets

When the MR received a packet from its ingress interface for outbound
forwarding, the behavior of the MR will be different depending on
whether the outbound packet contains a RAO or not.

1. Packet does not have a NEMO-Fwd any RAO

When the mobile router MR intercepts a packet from one of its ingress
interfaces, the mobile router it first checks if there is a NEMO-Fwd RAO or NEMO-BU
RAO attached to the packet. When the NEMO-Fwd RAO is absent (or
a NEMO-
NFwd NoFwd RAO is present), the mobile router MR has to route this packet
through its own home agent. HA. The packet is encapsulated in an
external outer
packet addressed to the home agent HA of the mobile router. If the mobile router's MR's
access router is not NEMO-enabled, ARO-enabled, the outer packet is sent to the mobile router's
MR's home agent. The external outer packet has the normal mobility
characteristics, i.e. the source field contains the care-of-address CoA of the mobile router,
MR and 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 HA of
the mobile router. MR.

If the mobile router's MR's access router is NEMO-enabled, ARO-enabled, reverse tunneling is
still necessary. However, in this case, the mobile router will
add a NEMO-Fwd RAO to the outer packet. The external outer packet is then
marked with source address set to the care-of-address CoA of the mobile router, MR, destination
address set to the address of the
mobile router's home agent, MR's HA. and attached with a
Home Address destination Option containing the home-address HoA of the mobile router.

* MR.

2. Packet has a NEMO-NoFwd RAO

Processing of an outbound packet with a NEMO-NoFwd RAO is
identical to that when the packet contains no RAO.

3. Packet has a NEMO-Fwd RAO

On the other hand, when the mobile router MR received a packet with a NEMO-Fwd
RAO from one of its ingress interfaces, the mobile router MR will then attempt
to forward the packet directly to the destination. To do so, the mobile router
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 mobile router MR will have to tunnel the received packet to its home agent HA using
reverse tunneling. In this case, the NEMO-Fwd RAO is changed to
a NEMO-NFwd NEMO-NoFwd RAO, and the packet is processed as though it does
not contain a NEMO-Fwd RAO (as described
in previous paragraph). previously).

The presence of a NEMO-Fwd RAO should suggest to the mobile router MR that it
could perform a Return Routability Test Procedure and Binding Update 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 mobile router MR does have an active binding update with the specified
destination, the source address of the packet is changed to the care-of-address
CoA of the mobile router. MR. In addition, if the access router of the mobile router MR is
not NEMO-enabled, ARO-enabled, the NEMO-Fwd RAO is changed to a NEMO-NFwd NEMO-NoFwd RAO.
The packet is then forwarded through the egress interface of the mobile router.

4.2.5. Processing Inbound Packets
MR.

4. Packet has a NEMO-BU RAO

When the mobile router received 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 must as though it does not
contain a destination field equal the care-of-address of NEMO-BU RAO (as described previously).

4.2.5 Processing Inbound Packets

When the mobile router, and MR received a type 2 routing header. If these conditions
are not satisfied, packet from its egress interface, the MR
checks if the packet is silently addressed to itself. Packets not addressed
to its CoA or HoA are discarded. In addition,
since When the packet is addressed to its
CoA, the care-of-address MR checks for the presence of type 2 routing header (RH2).
Packets without the mobile
router, 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 binding entry BCE of the mobile router. MR. If security
measures warrant it, the mobile
router MR may want to verify the sender is indeed a host
node in the mobile
router's MR's Binding Update List, and discard the packet if it
isn't.

The Segments Left field of RH2 is also 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 Type 2 Routing Header 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.

If the new destination address is the home-address HoA of the mobile
router, MR, the Segments
Left field is checked if it is 0 (after decrementing). If so, the
packet is consumed by the mobile router. MR. Otherwise, the packet is silently
discarded.

Alternatively, the new destination address may be an address in one
of the mobile router's MR's ingress interfaces. If yes, the packet is forwarded to
the new destination. Else, if the new destination field of the
packet is neither the home-address HoA nor a valid address in one of the mobile router's MR's
ingress interfaces, the packet is silently discarded.

When a packet is consumed by the mobile router, MR, the payload may be an
encapsulated packet. In this case, sender of the outer packet must
be the home agent HA of the mobile router. MR, or a node in MR's Binding Update List.
Processing of the inner packet is the same as that described in Section 4.1.3, i.e. as though the mobile
router is at home.

4.3.

4.3 IPSec Processing

It is strongly recommended that the mobile router MR uses IPSec protocols such as AH[18] AH [9] or ESP[19]
ESP [10] to secure the reverse tunnel with its home agent. HA [13]. This section
highlights changes to the IPSec processing for inbound and outbound
packets.

4.3.1.

4.3.1 IPSec Processing on Inbound Packets

Inbound packets may contain a type 2 routing header RH2 with an AH/ESP. The routing header RH2 should be
processed before AH. If the mobile
router MR is the final destination, the packet
is passed to the IPSec module for AH/ESP processing. Since the home agent 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.5.2), 5.4.2), no additional processing needs to be done
before the AH/ESP processing.

4.3.2.

4.3.2 IPSec Processing on Outbound Packets

For outbound packets, the new option options added to the packets by the
Proposed NEMO Solution is
ARO-Solution are the NEMO-Forward NEMO-Fwd, NEMO-BU and NEMO-No-Forward NEMO-NoFwd 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 For simplicity, it is attached to an access router best that is not
NEMO-enabled; or

(2) the mobile router encapsulate the outgoing packet into a tunnel
packet.

Thus the NEMO-Fwd RAO is a mutable but predictable option, where the
receiver always received the NEMO-Fwd RAO all IPSec implementations
ignore these options and treat their values as a NEMO-NFwd RAO. Thus all zero 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
should use its home-address as the IPv6 source address in the IPv6
header, and place its care-of-address in the Home Address field of
the Home Address destination option, as required by [9].

5. Operation of NEMO-enabled ARO-Enabled Home Agent

5.1. Sending Router Advertisement

When the home agent sends Router Advertisement, the home agent should
set the H-flag to 1 and set the N-flag to 1, indicating to recipients
it is functioning as a NEMO-enabled Mobile IP home agent.

5.2. Agents

5.1 Receiving Binding Updates

When a home agent HA receives a Binding Update BU message, it needs to check for the necessary
security measures as specified in Mobile IPv6 specifications [9]. [1] or
NEMO Basic Support [2]. The only change this Proposed NEMO ARO Solution requires
is for the home agent HA to add a field to its Binding Cache: access router's home-address.
address. Every valid Binding Update BU is checked for the Access Router Option
field. If one is absent, the corresponding entry in the Binding Cache BCE will have the access
router field invalidated. If one is present, the corresponding entry in the
Binding Cache BCE
will have the access router field updated.

In addition, when returning a Binding Acknowledgement BA for a Binding
Update BU that contains an Access
Router Option, the Proposed NEMO
Solution ARO-Solution requires that the home agent HA return a Status code that is to
be assigned (referred to as ARO-OK) to indicate that the BA
with the same Access Router Option if the binding is accepted. successful.
Note also that the home-agent HA MUST accept Binding Updates with ARO BU with or without Access Router Option
regardless of whether the Home Registration bit is set.

5.3.

5.2 Receiving Tunneled Packets from Away Nodes

When the home agent HA received a packet that contains an encapsulated packet,
it may choose to perform certain security checks. The obvious check
is to ensure that the source address is either a valid
care-of-address CoA of the home-address HoA
in its binding cache, or the source address is a valid care-of-address/home-address CoA or HoA of
an access router that is in the upstream of the mobile node with the
specified
home-address. HoA in the Home Address Destination option. Section 7.3 9.3
discusses the security considerations on accepting tunnels with a
source address that is not directly bound to the home-address HoA specified in the
Home Address destination option.

To establish this, the home agent HA can use the pseudo algorithm depicted in
Figure 2. 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.

set start-address = HoA in HAO
while (TRUE) do
{
find an entry in Binding Cache with HoA field = == start-address
if (no Binding Cache entry BCE is found)
{
return (FALSE)
}
if (CoA field in the Binding Cache entry BCE
== source-address of outer packet)
{
return (TRUE)
}
if (the Binding Cache entry BCE does not contain a valid access
router address)
{
return (FALSE)
}
if (access router address field in the Binding Cache entry BCE
== source-address of outer packet)
{
return (TRUE)
}
set start-address = access router address field in the
Binding Cache entry BCE
}

Figure 2: 9: Algorithm to check source address is valid

5.4.

5.3 Tunneling Packets to Away Nodes

When the home agent HA intercepted a packet addressed to a node in its home
domain, it checks the next router hop to forward the packet from its routing
table. This sub-section describes the operation of the home
agent HA when the
next router hop is away, i.e. the next router hop is a mobile
router, node, and the mobile router
node is away from home.

In this case, the home agent HA will forward the packet to the mobile
router node at
the care-of-address CoA of the mobile router. node. This is done by encapsulating the
intercepted packet into a new packet. According to standard Mobile IPv6 MIPv6
specification [9], [1], the packet will have the source address set to the
address of the home agent, HA, destination set to the care-of-address CoA of the mobile router,
and a Type 2 Routing
Header RH2 with only one address entry equals to the home-address HoA of the mobile router.
node.

This Proposed NEMO Solution ARO-Solution extends the Type 2 Routing Header RH2 to include addresses of access
routers, and the pseudo algorithm depicted in Figure 3 10 can be used
to construct such a routing header. In Figure 3, 10, src-address and
dst-address are the abbreviations for the source address and
destination address fields of the outer packet respectively.

initialize an empty a stack
set src-address = address of home agent
set dst-address = HoA of mobile router node
set Finished = FALSE
while (not Finished)
{
find entry in Binding Cache BCE with HoA field = dst-address
if (no Binding Cache entry BCE is found)
{
Finished = TRUE
}
else
{
if (dst-address == HoA of mobile router) node)
{
push dst-address to stack
}
set dst-address = CoA field of the found Binding Cache entry BCE
if (the found Binding Cache entry BCE contains a valid access router address)
{
push dst-address to stack
set dst-address = access router address field of BCE 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: 10: Algorithm to construct extended RH2

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
Type 2 Routing Header
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.

5.5.

5.4 IPSec Processing

It is strongly recommended that the home agent HA uses IPSec protocols such as AH[18] AH [9] or ESP[19]
ESP [10] to secure protect the reverse tunnel with a mobile
router. node [13]. This section
highlights changes to the IPSec processing for inbound and outbound
packets.

5.5.1.

5.4.1 IPSec Processing on Inbound Packets

Packets that are inbound may have their source address modified en-
route by access routers. Thus, all home agents MUST home-agents SHOULD use the
algorithm shown in Figure 2 9 to establish the authenticity of the
source address. Once the source address is verified, the source
address field will be replaced by the home-address HoA specified in the Home
Address destination Destination option, and the Home Address field of the Home
Address destination Destination option MUST be replaced with the care-of-
address CoA of the
sender. In Mobile IPv6, MIPv6, this care-of-address CoA can be obtained from the source address
field in the packet. However, this
Proposed NEMO Solution the ARO-Solution allows intermediate
mobile routers to modify the source address field. Thus, the home
agent MUST obtain the care-
of-address CoA from its Binding cache. BCE.

The above processing MUST be carried out before AH processing.

5.5.2.

5.4.2 IPSec Processing on Outbound Packets

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 home agent HA must order the contents of
the RH2 as it will appear at the final destination when generating
the AH authentication data.

6. Considerations Operation of ARO-Enabled Mobile Network Nodes

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 Use 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 Mutable 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 Alert 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 section described is done by adding a NEMO-Fwd RAO to
the design 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 leading 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-
route by access routers. Thus, all ARO-enabled correspondent nodes
SHOULD use the algorithm depicted in Figure 9 shown in Section 5.2 to
establish the authenticity of the source address. Once the source
address is verified, the source address field will be replaced by the
HoA specified in the Home Address Destination option, and the Home
Address field of the Home Address Destination option MUST be replaced
with the CoA of the sender. In MIPv6, this CoA can be obtained from
the source address field in the packet. However, the ARO-Solution
allows intermediate mobile routers to modify the source address
field. Thus, the CN MUST obtain the CoA from its BCE.

The above processing MUST be carried out before AH processing.

7.4.2 IPSec Processing on Outbound Packets

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 CN must order the contents of
the RH2 as it will appear at the final destination when generating
the AH authentication data.

8. Design Considerations

This section describes the rational behind some design decision made
in the formulation of the ARO Solution. Some justifications are
given, and in some cases, alternative approaches are discussed.

8.1 Considerations in the Use of Mutable Router Alter Option.

6.1. Alert Option

8.1.1 Overview of Router Alert Option

The proposed solution ARO Solution described in this memo is designed so that it will
work in a nested NEMO where some mobile routers are NEMO-enabled ARO-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 ARO
Solution. Since the indication is meant for intermediate routers, a
hop-by-hop option is needed.

The Router Alert Option [16] [6] lends itself readily for use. By
assigning a value in RAO, a NEMO-enabled 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
reveals that there is a need for a mobile router that is not attached
to a NEMO-enabled ARO-enabled access router to disable this behavior.

6.2.

8.1.2 Example where an Immutable RAO is Used

To understand why a mobile router MR that is not attached to a NEMO- ARO- enabled access
router should disable the NEMO-Fwd RAO, consider the following
scenario, where MR1, MR2, and MR4 are NEMO-enabled ARO-enabled mobile routers,
LFR3 is a non-NEMO-enabled non-ARO-enabled local fixed router attached to MR4, and HA1
is the home agent of MR1.

MR1---MR2---LFR3---MR4---[Internet]---HA1

Suppose both MR1 and MR2 have performed binding updates successfully
with HA1, thus the state of the Binding Cache of HA1 will be:

Home-Address Care-of-Address Access Router
------------ --------------- -------------
MR1.HoA MR1.CoA MR2.HoA
MR2.HoA MR2.CoA <invalid>

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
MR1, is NEMO-enabled). ARO-enabled). Thus the packet from MR1 to MR2 will contains
the following contents:

IPv6 Hdr (src=MR1.CoA, dst=HA1)
Hop-by-Hop Opt
RAO (NEMO-Fwd)
Dest Opt
HAO (MR1.HoA)

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
router, thus it simply forwards the packet to MR4. At MR4, the
packet contents is then:

IPv6 Hdr (src=MR2.CoA, dst=HA1)
Hop-by-Hop Opt
RAO (NEMO-Fwd)
Dest Opt
HAO (MR1.HoA)

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
packet to its home agent. From the home agent of MR4, the packet is
forwarded to HA1.

Suppose now HA1 accepts the binding update with MR4, and its Binding
Cache is thus as follows:

Home-Address Care-of-Address Access Router
------------ --------------- -------------
MR1.HoA MR1.CoA MR2.HoA
MR2.HoA MR2.CoA <invalid>
MR4.HoA MR4.HoA <invalid>

Now, when MR1 sends a tunnel packet to HA1 again, the packet will
arrive at MR4 with the following contents:

IPv6 Hdr (src=MR2.CoA, dst=HA1)
Hop-by-Hop Opt
RAO (NEMO-Fwd)
Dest Opt
HAO (MR1.HoA)

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 CoA and forward
the packet to HA1 through the Internet. When HA1 receives the
packet, the contents will be:

IPv6 Hdr (src=MR4.CoA, dst=HA1)
Hop-by-Hop Opt
RAO (NEMO-Fwd)

Dest Opt
HAO (MR1.HoA)

Because the Access Router field of the Binding Cache entry BCE for MR2 is marked invalid,
the algorithm for checking the validity of the source address as
shown in Figure 2 9 of Section 5.3 5.2 will fail. Thus the packet will be
discarded at HA1.

6.3.

8.1.3 The Need for Mutable RAO

The example in the previous section shows that the presence of a
local fixed router (LFR) that is not NEMO-enabled ARO-enabled may cause an
unintentional denial-of-service to mobile routers that are attached
to the LFR.

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
check that the source address is a valid source address in the
ingress interface of MR4. However, MR2 might obtain a care-of-
address CoA that
contains a prefix that is valid in the ingress interface of MR4.
Thus checking source address does not completely eliminate the
problem.

If MR2 can somehow invalidate the NEMO-Fwd RAO, the problem can be
eliminated. But the Router Alert Option as defined in [16] [6] is an
immutable hop-by-hop option, so what is needed here is a mutable
router alert option.

6.4. Sub-Optimality of NEMO-NFwd RAO

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.

8.1.4 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
routing header type. These are briefly described below.

6.5.1.

o IPv6 Flow Label

It is possible to use the IPv6 Flow label to achieve the same
effects as the mutable Router Alert Option. A specific, universal
Flow label can be reserved to indicate to NEMO-enabled routers
that they should try to forward the packets directly to their
destination (instead of using a reverse tunnel with home agents).

This approach eliminates the need of defining a new hop-by-hop
header option. However, this means that a specific flow label has
to be reserved, which may be in contention with currently deployed
IPv6 nodes. In addition, this will mean that NEMO-enabled mobile
routers are unable to use Flow label for other purposes.

6.5.2.

o New Routing Header Type

A new routing header type can be defined to store the address of
the final destination. When such a routing header is used, the
originator will place the address of the final destination in the
routing header, and place the home-address of the access router of
the originator in the destination (when the access router is NEMO-
enabled). When a NEMO-enabled mobile router that is not attached
to a NEMO-enabled access router receives a packet with this type
of routing header, it will overwrite the destination address of
the packet with the final destination specified in the routing
header, and decrement the Segments Left field. When a
NEMO-enabled mobile router that is attached to a NEMO-enabled
access router receives a packet with this type of routing header,
it will overwrite the destination address of this packet with the
home-address of its access router and the leave the contents of
the routing header untouched.

There remain issues that are unclear when this new type of routing
header is used with other routing headers. Also, the security
implication of defining a new type of routing header is yet to be
explored.

7. Changing

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 by Intermediate Routers

This memo proposed to allow intermediate routers to change the source
address of a packet en-route. It is expected that this will cause
some disturbances, as it is generally not allowed for routers to
change the source address. We hope to justify our design decision in
this section, and discuss some alternatives.

7.1.

8.2.1 Justifications

The main factor in consideration to changing the source address en-
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
topologically compatible with where the packet is originated. Thus,
to overcome ingress filtering, the source address must somehow be
changed. We view the change of source address as somewhat akin to
the use of a care-of-address CoA as the packet source address in Mobile
IPv6. MIPv6.

For the case of Mobile IPv6, MIPv6, mobile nodes use the care-of-address CoA to overcome ingress
filtering, and use the Binding Update BU mechanism and Home Address destination Destination
Option to allow receivers to establish a relationship between the
source address (i.e. care-of-address) CoA) and the home-address. HoA. In this proposal, the ARO Solution,
receivers can use the algorithm depicted in Figure 2 9 of Section 5.3 5.2
to establish a similar relationship between the source address (in
this case, the care-of-
address CoA/HoA of an upstream access router) and the home-address.

7.2. HoA.

8.2.2 Alternatives

There are alternatives to changing source address for the purpose of
overcoming ingress filters. One method is to use packet
encapsulation to achieve the same effect as changing of source
address (since the outer packet has a different source address).
Currently, evaluating such a scheme is in progress.

9. Security Considerations

This proposal introduces several modifications to existing protocols.
In this section, we will discuss additional security issues that
arise due to these modifications.

8.1.

9.1 Addition of Access Router Option

Access Router Option is introduced so that a recipient can establish
a credible link between the global address of the access router
specified, and the home-address HoA of the mobile router node that sends the Access
Router Option.

When a mobile router node sends Binding Update BU to its home agent, HA, current
Mobile IPv6 MIPv6 draft specifies
that the Binding Update BU should be secured (either by ESP or AH). For this case,
the introduction of Access Router Option does not introduce new
security threats.

When sending Binding Updates BU to correspondent node, CN, the mobile router node inserts the Access Router
Option only when sending the actual Binding
Update BU message. The Binding Update BU message is
protected using a key generated after obtaining the Care-of-Test
(CoT) and Home-Test (HoT) messages, so the Access Router Option
should be relatively secure. However, there exist the slight
possibility of an attacker snooping on both the
Care-of-Test CoT and Home-Test HoT messages,
thus allowing the attacker to generate the key independently. The
attacker can then proceed to change the values in the Access Router
Option and change the Authenticator value of the Binding Update BU message using the
generated key, thus leading the correspondent node to believe that
the mobile
router node is attached to another access router.

To overcome this, it is suggested that the mobile router to node may insert the Access Router Option
when sending the Care-of-Test CoT Init Message. The NEMO-enabled corresponding node, ARO-enabled CN, should then
generate the care-of cookie using

Care-of cookie = First64(MAC_Kcn(CoA | access router address |
nonce))

instead of using only the care-of-address CoA and nonce. In this way, the global
address of the access router in the Access Router Option is protected
the same way the care-of-address CoA is protected.

Note that if the correspondent node CN does not recognize the Access Router Option, it
will not use the access router address to generate the
care-of-cookie. However, we do not require the mobile router node to change
the way the Authenticator value is generated, i.e. the value is
generated using the method as specified in Mobile IPv6 [9]: MIPv6 [1]:

Kbu = Hash(home cookie | care-of cookie)
Authenticator = MAC_Kbu(CoA | CN address | BU)

So, the Binding Update BU will be verified to be authentic by the
correspondent node CN regardless of
how the care-of cookie is generated, provided the generation of
care-of cookie is consistent. The mobile
router node must still request for Binding Acknowledgement
BA so that the
mobile router knows it if the correspondent node CN has accepted the Access Router Option.

8.2.

9.2 Router Global Address Option

The introduction of global address of the access router in the
Binding Update BU
message is the crux of the Proposed NEMO ARO Solution, since this is the link which
allows home agents HA and correspondent
nodes CN to set up the Type 2 Routing Header RH2 and to accept packets from
otherwise unknown sources. From previous discussion, the global
address of the access router is fairly secure since

(1) Binding Update

o BU sent by an away node to its home agent that contains the access
router's global address is secure, and

(2) Binding Updates

o BU sent to corresponding nodes CN are reasonably protected using the Return Routablility Test.
Routability Procedure.

The weakest link is now the method in which the mobile router node learns
the global address of the access router it attaches to. The method
proposed in this memo is to use the Router Advertisement. Two
possible security threats are identified here:

(1)

1. a malicious access router advertising false global address in
Router Advertisement, the
RA messages it broadcasts, and

(2)

2. an attacker replays a Router Advertisement RA message from a legitimate access router,
but changes the global address contained in the Router Global
Address Option to a false entry.

The severity of the two threats is yet to be fully analyzed. We do
provide our initial analysis here to invite further discussion. For
the first case, advertising a false global address is believed to be
one of least harm a malicious access router could do. There are
other far more potent threats faced by the mobile router when it
attaches itself to a malicious access router. For the second case
where an attacker replays a modified Router Advertisement, RA, we believed that the threat
existed in IPv6 Neighbor Discovery [20]. [11]. In
[20], [11], security issues
pertaining to Router Advertisement RA are discussed. This discussion should be able to
shed some light on how to advert such an attack.

8.3.

9.3 Accepting Tunnel with a Source Address not Directly Bound to the
Home Address

Mobile IPv6

MIPv6 forbids home agent from accepting tunnels with a source address
that is not bound to the home-address HoA specified in a Home Address Option.
This proposal relaxed this security measure. The home agent should
now admit tunnels from a source address that is "indirectly" bound
(through the linkage of access router field in the binding cache) to
the home-address specified in the Home Address Option. The algorithm
presented in Figure 2 9 of Section 5.3 5.2 can be used to verify if the
source address is "indirectly" bound to the
home-address HoA specified in the Home
Address Option.

As considered above in Section 6.1, 8.2, the Access Router Option is
secured by the fact that a Binding Update BU to the home agent HA is always secure. In
addition, the Access Router Option is fairly secured with the Return
Routability Tests. Procedure. Thus the relaxation of the security measure
of source address verification of a tunnel does not significantly
increase the home agent's HA's vulnerability to attacks. It is also recommended
that the tunnel between the mobile node and the home agent to be
secured by ESP or AH. In addition, we also recommend that all
implementations to allow the support of this
Proposed NEMO ARO Solution to be
administratively disabled or enabled. The default should be enabled.

8.4.

9.4 Use of Extended Routing Header Type 2

The extension of the Type 2 Routing Header RH2 exposes this solution to additional security
threats in that attackers can change the entries in the routing header RH2 to be
routed to another entity. However, we note that this extension is
designed so that the extended Type 2
Routing Header RH2 is now very similar to the Type 0
Routing Header. Thus, the security threats faced by Type 2 Routing Header RH2 is not a new
threat introduced by this solution itself. In any case, the harm an
attacker can do by changing the entries in the routing header is
limited to:

(1)

o causing the packet to be routed to another entity for snooping
into the contents of the payloads;

(2)

o denial-of-service attack causing the packet to be discarded by
intermediate routers; and

(3)

o using the Type 2 Routing Header RH2 to reflect packets off a mobile network.

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
attack even if a Type 2 Routing Header RH2 is not used. For the threat where attacker
construct a Type 2 Routing Header RH2 to reflect packets off a mobile network, we recommend
that all routers supporting the Type 2 Routing Header RH2 to perform the following security
measures:

o When the mobile router node receives a packet with the destination field
set to its home-address HoA or care-of-address, CoA, it should check for the existence of a Type 2 Routing Header. RH2.

Any packet that is sent to the mobile router's care-of-address node's CoA without a
Type 2 Routing Header RH2
should be discarded.

o If the Segment Left field has a value of 1, the last address in
the routing header must contain the home-address HoA of the mobile
router.

- node.

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 the
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 node will
discard any packets it received with a Type 2 Routing Header RH2 that requires the router it to
forward the packet through an egress link. This should reduce, if
not eliminate, the possibility of using the extended Type 2 Routing Header RH2 for
reflection attacks.

In addition, it must be noted that the extended Type 2 Routing Header RH2 is mutable but
predictable. Thus, it can be protected using AH.

8.5.

9.5 Mutable Router Alert Option

The mutable Router Alert Option is used in this memo to request/stop
subsequent routers to attempt to forward the packet directly to its
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 binding update BU with the destination.
When binding update BU is successful, subsequent 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 9).

The attacker can add a NEMO-NFwd NEMO-NoFwd RAO to a packet. This has no
effect (other than causing AH to fail),
effect, since the default behavior of processing a packet with NEMO-NFwd
NEMO-NoFwd 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 change the value of the NEMO-Fwd RAO to a NEMO-
NFwd
NoFwd RAO. The effect of this form of attack is to cause the
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 NEMO-NoFwd RAO to a
NEMO-Fwd RAO. The effect of this form of attack is to cause
subsequent mobile routers to perform binding update BU with the destination.
When binding update BU is successful, subsequent mobile routers will forward the
packets directly to the destination, causing the packet to be
discarded (due to failure of algorithm in Figure 2). 9).

All the security threats described above require the attacker to be
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
receiver. Since the attacker must be on the path of the packet
route, the attacker can achieve the same effect by simply discarding
the intercepted packet. Thus, the use of mutable router alert option
described in this memo does not introduce any new security threats.
8.6.

9.6 IPSec Processing

It is strongly recommended that the mobile router uses IPSec
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.

9.6.1 Processing of Extended Routing Header Type 2

As covered in Section 5.5.2, 5.4.2, the extended RH2 is a mutable but
predictable header, thus the sender must ordered the fields in the
RH2 (and the destination address of the IPv6 header) as they will
appear at the final destination when generating the AH authentication
header.

8.6.2.

9.6.2 Processing of Home Address Destination Option

As specified in Mobile IPv6 [9], MIPv6, the originator should use its home-
address HoA as the IPv6
source address in the IPv6 header, and place its
care-of-address CoA in the Home
Address field of the Home Address destination option, when generating
the AH authentication data.

The Proposed NEMO ARO Solution allows mobile routers to modify the source address
of the IPv6 Header, thus when the source address field may no longer
contain the care-of-address CoA of the sender at the final destination.

All home agents MUST use the algorithm shown in Figure 2 9 of Section
5.3
5.2 to establish the authenticity of the source address. Once the
source address is verified, the source address field will be replaced
by the home-address HoA specified in the Home Address destination option, and the
Home Address field of the Home Address destination option will be
replaced with the care-of-address CoA of the sender. This care-
of-address CoA is obtained from the
receiver's Binding cache. BCE.

The above processing MUST be carried out before AH processing.

8.6.3.

9.6.3 Processing of Mutable Router Alert Option

As described in Section 4.3.2, when the sender of a packet inserts a
NEMO-Fwd RAO or NEMO-BU RAO to the packet, the receiver always
received the RAO modified to NEMO-NFwd. NEMO-NoFwd. Thus the mutable NEMO-Fwd
RAO is predictable.
When AH It is used, thus possible for the originator should to use the NEMO-NFwd
NEMO-NoFwd RAO to generate the AH authentication data.

Acknowledgements

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 However, it
is recommended that the initial draft RAO simply be left out of this memo. any IPSec
processing.

10 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,
Oct 1996.

[8] DARPA, "Internet Protocol", IETF RFC 791, Sep 1981.

[9] Johnson, D. B., D., Perkins, C. E., and J. Arkko, J., "Mobility Support in
IPv6", Internet Draft: draft-ietf-mobileip-ipv6-
18.txt, Work In Progress, June 2002.

[10] Deering, S., and Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", IETF RFC 2460, Dec 1998.

[11] Kniveton, T., "Mobile Router 3775, June 2004.

[2] Devarapalli, V., "Network Mobility (NEMO) Basic Support with Mobile IP", Internet
Draft: draft-kniveton-mobrtr-01.txt, Work In Progress, Mar
2002.

[12]
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.

[3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and
Olivereau, A., "Mobile Networks "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02 (work in Mobile IPv6 (Prefix
Scope Binding Updates)", Internet Draft: draft-ernst-mobileip-
v6-network-03.txt, Mar 2002.

[13] progress), February
2004.

[4] Thubert, P., and Molteni, M., M. and C. Ng, "Taxonomy of Route
Optimization
Models models in the NEMO Nemo Context", Internet Draft: draft-thubert-
nemo-ro-taxonomy-00.txt, Work In Progress, Oct 2002.

[14] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and
Its Application to Mobile Networks", Internet Draft: draft-
thubert-nemo-reverse-routing-header-01.txt, Work In Progress,
Oct 2002.

[15]
draft-thubert-nemo-ro-taxonomy-02 (work in progress), February
2004.

[5] Ernst, T., T. and H. Lach, H., "Network Mobility Support Terminology", Internet Draft, draft-ernst-nemo-terminology-
00.txt, Oct 2002, Work In Progress.

[16]
draft-ietf-nemo-terminology-01 (work in progress), February
2004.

[6] Partridge, C., C. and A. Jackson, A., "IPv6 Router Alert Option",
IETF RFC
2711, Oct October 1999.

[17]

[7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.

[8] Kent, S., S. and R. Atkinson, R., "Security Architecture for the
Internet Protocol", IETF RFC 2401, Nov November 1998.

[18]

[9] Kent, S., S. and R. Atkinson, R., "IP Authentication Header", IETF RFC 2402, Nov
November 1998.

[19]

[10] Kent, S., S. and R. Atkinson, R., "IP Encapsulating Security Payload
(ESP)", IETF RFC 2406, Nov November 1998.

[20]

[11] Narten, T., Nordmark, E., E. and W. Simpson, W., "Neighbour "Neighbor Discovery
for IPv6", IETF IP Version 6 (IPv6)", RFC 2461, Dec December 1998.

[12] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.

Author's

[13] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.

Authors' Addresses

Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #04-3530 #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG

Phone: (+65) 6554 5420
Email: +65 65505420
EMail: cwng@psl.com.sg

Takeshi Tanaka
Wireless Solution Laboratories

Jun Hirano
Matsushita Communication Electric Industrial Co Ltd
5-3, Hikarinooka, Yokoshuka-shi, Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa
239-0847, Japan 239-0847
JP

Phone: +81-468-40-5494
Email: Takeshi.Tanaka@yrp.mci.mei.co.jp

Appendices +81 46 840 5123
EMail: hirano.jun@jp.panasonic.com

Appendix 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 Acknowledgement

The current proposal uses the notion of access router to allow home
agents authors would like 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 express our sincere gratitude 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 Takeshi
Tanaka for his contribution to the next available
entry initial version 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 draft. In comparison, the proposal by Thubert et. al.
addition, appreciation is more efficient. It
does not require each mobile router on the path also extended to perform binding
updates with the home agent of the lowest-level mobile router, as
this proposal do. Any change Thierry Ernst, Pascal
Thubert, and various people 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 WG who 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 given us valuable
comments.

Intellectual Property Statement

The IETF takes no way of knowing if
the reverse routing header is tampered with en-route. On the hand, position regarding the solution proposed in this memo uses Mobile IPv6 binding mechanism
to establish the chain validity or scope 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
Intellectual Property Rights or other hand, the solution proposed in this memo
merely requires an additional column in the binding cache rights that might be claimed 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
pertain to construct a routing header
from the binding cache.

B.1.3. Possible Merging implementation or use of Solutions

As the Reverse Routing Header and the proposal technology 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 document or 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 extent to specify the
prefix length in the Binding Update, so that correspondent nodes, as
well as home agent, realize that which any address falling into the home-
prefix is bound to that care-of-address. The current proposal works
well with license under such a Prefix Scope Binding Update, and can coexist rights
might or might not be
merged as one solution.

B.3. Hierarchical Mobile IPv6 (HMIPv6)

One other candidate is Hierarchical Mobile IPv6 proposal (HMIPv6)
[21]. Till date, available; nor does it is unclear how HMIPv6 can be adopted as the NEMO
solution.

C. Examples

This Section describes several examples represent that it has
made any independent effort to illustrate how the
proposed solution works. These examples are based identify any such rights. Information
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 procedures 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 respect 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 rights 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 RFC documents can be
found in HAO, checking if it
has an entry for MR1.HoA as Home Address. Next HA1 notices it has
Access Router field BCP 78 and creates/updates binding entry for MR2 with
Access Router field set. After this, the Binding Cache BCP 79.

Copies 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 IPR disclosures made 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 IETF Secretariat and encapsulates it.
Using the algorithm given in Figure 3 any
assurances 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 licenses to be made available, or the home-address
of MR2. So MR2 processes the inner packet, and updates the RH2 result 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 an
attempt made 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 obtain 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 general license or permission for the
packet and tunnels to HA2. Since access router use 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
such proprietary rights by implementers or users 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 this
specification can be obtained 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. IETF on-line IPR repository at
http://www.ietf.org/ipr.

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 IETF invites any interested party to HA2.
HA2 notices MR2 is away from home, thus HA2 encapsulates the
packet and forwards bring 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

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 attention any
copyrights, patents or patent applications, or other proprietary
rights that
the Segments Left field is 1 and verifies may cover technology 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 may be required 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 implement
this standard. Please 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 information to LFN1 and encapsulates it.
Using the algorithm given in Figure 3 IETF at
ietf-ipr@ietf.org.

Disclaimer 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 Validity

This document and processes the RH2. information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
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.

Copyright (C) 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 Internet Society (2004). This document is a valid address in its ingress
interface, and sends the packet out.

Packet sent from MR2 subject
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 rights, licenses and
sent to LFN1.

C.3. MR2 moves to new location

In this section, the messages exchange is described after MR2 moves
to a new location. This section will demonstrate that a change restrictions contained in
attachment of the upper level mobile router is transparent to nested
nodes. Note that the binding update between MR2 BCP 78, and HA2 is not shown.

C.3.1. MR2 sends binding update to HA1

After MR2 obtains a new care-of-address, it sends a new binding
update to HA1 since HA1 is on the Binding Update List of MR2.

(1) MR2 performs Return Routability test to HA1

(2) MR2 sends BU to HA1

BU sent from MR2 to HA1 looks like this:

IPv6 Hdr (src=MR2.CoA, dst=HA1)
Dst Opt
HAO (MR2.HoA)
Mobility Hdr
BU (Binding Auth data option)

(3) HA1 processes
except as set forth therein, the BU

Next HA1 checks Binding Auth data. Then HA1 updates binding entry authors retain all their rights.

Acknowledgment

Funding 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.nCoA <invalid>

It should be noted that the state of the Binding Cache RFC Editor function is very
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 currently provided by the upper
level mobile router is transparent to nested nodes.

Additional References

[21] Soliman, H., Castelluccia, C., El-Malki, K., and Bellier, L.,
"Hierarchical MIPv6 Mobility Management (HMIPv6)",
Internet
Draft: draft-ietf-mobileip-hmipv6-07-txt, Work In Progress, Oct
2002. Society.