[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

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

                                                           October 2002

      Securing Nested Tunnels Optimization with Access Router Option
                 draft-ng-nemo-access-router-option-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 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
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   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.  However, the multiple levels of bi-
   directional tunnels in nested mobile networks lead to undesirable
   effects.  This memo proposes using a new mobility header option
   called the Access Router Option to allow a mobile router to inform
   its home agent the home-address of the access router it is currently
   attached to.  From there, this memo lays out a mechanism that allows
   mobile routers to securely achieve nested tunnels optimization.

Conventions used in this document

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



Ng & Tanaka              Expires - April 2003                 [Page 1]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



Table of Contents

   1. Introduction...................................................4
      1.1. Terms Used................................................5
      1.2. Assumptions...............................................5
      1.3. Organization..............................................6
   2. Overview of Operation..........................................6
      2.1. Router Advertisement......................................7
      2.2. Binding Update from MR1 to HA1............................7
      2.3. Binding Update from MR2 to HA1............................7
      2.4. Forwarding Packets from HA1 to MR1........................8
      2.5. Forwarding Packets from MR1 to HA1........................8
   3. Changes to Existing Protocols..................................9
      3.1. Modifications to Mobile IPv6..............................9
         3.1.1. Addition of Access Router Option.....................9
         3.1.2. Extending Type 2 Routing Header.....................10
         3.1.3. Extending Binding Acknowledgement Message...........12
         3.1.4. Modification to Conceptual Data Structures..........12
      3.2. Modifications to IPv6 Neighborhood Discovery.............12
         3.2.1. Extension to Router Advertisement...................12
         3.2.2. Addition of a New Option in Router Advertisement....13
      3.3. Extending the Router Alert Option........................14
   4. Operation of NEMO-enabledMobile Router........................15
      4.1. Operation when Mobile Router is at Home..................15
         4.1.1. Sending Router Advertisement........................15
         4.1.2. Processing Outbound Packets.........................15
         4.1.3. Processing Inbound Packets..........................16
      4.2. Operation when Mobile Router is Away.....................16
         4.2.1. Sending Router Advertisement........................16
         4.2.2. Receiving Router Advertisement......................16
         4.2.3. Sending Binding Updates.............................17
         4.2.4. Processing Outbound Packets.........................17
         4.2.5. Processing Inbound Packets..........................18
      4.3. IPSec Processing.........................................19
         4.3.1. IPSec Processing on Inbound Packets.................19
         4.3.2. IPSec Processing on Outbound Packets................19
   5. Operation of NEMO-enabled Home Agent..........................20
      5.1. Sending Router Advertisement.............................20
      5.2. Receiving Binding Updates................................20
      5.3. Receiving Tunneled Packets from Away Nodes...............20
      5.4. Tunneling Packets to Away Nodes..........................21
      5.5. IPSec Processing.........................................23
         5.5.1. IPSec Processing on Inbound Packets.................23
         5.5.2. IPSec Processing on Outbound Packets................23
   6. Considerations in the Use of Mutable Router Alert Option......24
      6.1. Router Alert Option......................................24
      6.2. Example where an Immutable RAO is Used...................24
      6.3. The Need for Mutable RAO.................................26


Ng & Tanaka              Expires - April 2003                 [Page 2]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


      6.4. Sub-Optimality of NEMO-NFwd RAO..........................26
      6.5. 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 Source Address by Intermediate Routers...............28
      7.1. Justifications...........................................28
      7.2. Alternatives.............................................28
   8. Security Considerations.......................................28
      8.1. Addition of Access Router Option.........................28
      8.2. Router Global Address Option.............................30
      8.3. Accepting Tunnel with a Source Address not Directly Bound to
      the Home Address..............................................30
      8.4. Use of Extended Routing Header Type 2....................31
      8.5. Mutable Router Alert Option..............................32
      8.6. IPSec Processing.........................................33
         8.6.1. Processing of Extended Routing Header Type 2........33
         8.6.2. Processing of Home Address Destination Option.......33
         8.6.3. Processing of Mutable Router Alert Option...........34
   Acknowledgements.................................................34
   References.......................................................34
   Author's Addresses...............................................36
   Appendices.......................................................36
   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



Ng & Tanaka              Expires - April 2003                 [Page 3]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



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 is based on
   extension of Mobile IPv6 and bi-directional tunneling between the
   mobile router controlling the mobile network and its home agent
   [11][12].  As described in the NEMO charter, a mobile router, when it
   is in a foreign domain, will set up a bi-directional tunnel with its
   home agent.  Here, the home agent will intercept packets destined for
   the subnet controlled by the mobile router and tunnel the packet to
   the mobile router's care-of-address, based on a previous Binding
   Update (possibly Prefix-Scoped Binding Update [12]) sent by the
   mobile router.  In addition, the mobile router will encapsulate
   outbound packets to its home agent through the bi-directional tunnel
   for delivery.

   This memo addresses the basic NEMO solution with some route
   optimization.  It proposes various modifications to some aspects of
   Mobile IPv6 so that problems of bi-directional tunneling that arose
   when other mobile hosts or networks attached themselves to a mobile
   network (thus forming what is called the Nested Mobile Networks) are
   solved.  More specifically, the solution described in this document
   attempts to solve the problem of Nested Tunnels Optimization as
   described in [13].  In [14], Thubert et. al. proposed the use of a
   Reverse Type 2 Routing Header to solve the problem of Nested Tunnels
   Optimization.  In essence, the proposal requires the first mobile
   router to attach a reverse routing header to the tunnel packet.
   Subsequent mobile routers along the egress path of the packet would
   not further encapsulate the packet.  Instead, they will move the
   source address of the incoming packet to the next available entry of
   the reverse routing header, and put their own care-of-address in the
   source address field.  In this way, the home agent receiving this
   packet can construct the chain of access routers the mobile router is
   attached to.  From there, a packet addressed to the mobile router (or
   to any nodes attached to the ingress interface of the mobile router)
   can be sent with an extended Type 2 Routing Header.



Ng & Tanaka              Expires - April 2003                 [Page 4]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   Security issues is one major problem of the reverse routing header
   solution, as admitted by Thubert et. al. in their proposal.  It is
   the main objective of this memo to propose a relatively secure
   solution to the nested tunnel optimization problem.  The solution
   proposed here defines a new option in mobility headers specified in
   [9].  This new option, called the Access Router Option, is used by
   the sender (i.e. the mobile router) to inform the recipient (e.g.
   home agent) the global address of the access router the sender is
   attached to.  From the information provided in the Access Router
   Option, the recipient can then construct the chain of access routers
   the sender is attached to.  This can be used to construct the
   extended Type 2 Routing Header.

1.1.  Terms Used

   It is assumed that readers are familiar with the NEMO terminology
   described in [15], and the terms described in [13].  In addition, a
   detailed description of the problem of nested tunnels optimization is
   given in Section 2 of [13].  It will not be duplicated in this memo.

   Apart from the terms described in [15] and [13], 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

          To aid our illustration, we refer to the solution proposed in
          this memo as the "Proposed NEMO Solution".  Any network nodes
          that implements the "Proposed NEMO Solution" is referred to as
          a "NEMO-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.



Ng & Tanaka              Expires - April 2003                 [Page 5]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   (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.  Organization

   In the remaining portions of this memo, we will first describe an
   overview of the operation in Section 2.  Following which, Section 3
   will list the modifications to existing protocols this memo proposes
   in detail.  The operations of mobile routers and home agents are
   described separately in Sections 4 and 5.  Section 6 discusses some
   design considerations leading to the proposal of a mutable router
   alert option, and Section 7 argues the case of allowing intermediate
   routers to change the source address of a packet.  Finally, Section 8
   presents the security considerations.

   Three appendices are attached at the end of this document.  Appendix
   A discusses the possibility of extending the proposal described in
   this memo to achieve full router optimization.  Appendix B compares
   the proposal described in this memo to other proposed solutions for
   NEMO.  Appendix C describes an example to illustrate how the solution
   proposed in this memo works.


2.  Overview of Operation

   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.

                                        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.


Ng & Tanaka              Expires - April 2003                 [Page 6]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


2.1.  Router Advertisement

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

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 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)
   of MR2.

   HA1 records this together with the binding update entry in its
   binding cache.  When returning the Binding Acknowledgement (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] is extended so that it can
   store more than one address.

   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 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.  Binding Update from MR2 to HA1

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

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

  (2)  HA1 is NEMO-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 specified in [9] must be


Ng & Tanaka              Expires - April 2003                 [Page 7]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   carried out before sending 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-
   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.  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 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.  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 packet is appended with a mutable Router Alert Option (RAO)
   [16], in addition to the Home Address destination Option (HAO).  This
   RAO requests upstream routers that support the Proposed NEMO Solution
   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


Ng & Tanaka              Expires - April 2003                 [Page 8]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   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 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 specifications [9].

   A detail example showing the sequence of message exchange can be
   found in Appendix C.


3.  Changes to Existing Protocols

3.1.  Modifications to Mobile IPv6

3.1.1.  Addition of Access Router Option

   The Access Router Option (ARO) is a new option for Mobility Header
   defined in Mobile IPv6.  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                       +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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.


Ng & Tanaka              Expires - April 2003                 [Page 9]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


     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 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
   addresses some security considerations on the use of the Access
   Router Option.

3.1.2.  Extending Type 2 Routing 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]                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Ng & Tanaka              Expires - April 2003                [Page 10]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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

     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 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 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] protocols such as
   Authentication Header (AH) [18] and Encapsulating Security Payload
   (ESP) [19] can be used with the routing header.  Security


Ng & Tanaka              Expires - April 2003                [Page 11]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   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.  Modification to Conceptual Data Structures

   In Mobile IPv6 [9], the Binding Cache data structure is defined to
   contain entries of home-address to care-of-address bindings.  This
   Proposed NEMO Solution extends the each Binding Cache entry to
   contain an additional field known as the Access Router Address.  This
   field is used to store the global address of the access router
   specified in the Access Router Option in a Binding Update message.

   When updating the Binding Cache entry, the Access Router Address
   field is overwritten with the address specified in the Access Router
   Option.  If the Access Router Option is absent, the Access Router
   Address field should be marked to be invalid.

3.2.  Modifications to IPv6 Neighborhood Discovery

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









Ng & Tanaka              Expires - April 2003                [Page 12]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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

     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 Address
        Option.




Ng & Tanaka              Expires - April 2003                [Page 13]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


     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 of the sender may prove to be useful for fast handover
   operations.

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

3.3.  Extending the Router Alert Option

   The router alert option [16] 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)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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-
   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)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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).  By zeroing the first two bits,


Ng & Tanaka              Expires - April 2003                [Page 14]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   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 extra values to be assigned.  For purpose of description,
   we call these two values the NEMO-Forward and NEMO-No-Forward.
   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 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 RAO.

   Intermediate routers that support the Proposed NEMO 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 of the router in order to pass through ingress
   filters of subsequent routers/gateways.

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

   Section 6 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.  Operation when Mobile Router is at Home

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

4.1.1.  Sending Router Advertisement

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

4.1.2.  Processing Outbound Packets

   When the mobile router intercepts an outbound packet from its ingress
   interface, it first checks if the packet contains a NEMO-Fwd RAO.
   Packets that do not contain a NEMO-Fwd RAO, or packets that contain a
   NEMO-NFwd RAO are simply forwarded to its egress interface.  For


Ng & Tanaka              Expires - April 2003                [Page 15]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   packet that contains a NEMO-Fwd RAO, since the mobile router is at
   home, it changes the NEMO-Fwd RAO to a NEMO-NFwd RAO and forwards the
   packet to its egress interface.

4.1.3.  Processing Inbound Packets

   When the mobile router is at home, it functions like a normal router.
   Thus it will consume any packet that is addressed to its home-
   address, forward any packet with a destination address that is a
   valid address in one of its ingress interface (e.g. the destination
   address must contain the same network prefix as one of the ingress
   interface), and discard any packet with an invalid destination
   address.

   When the packet is addressed to the mobile router's home-address, the
   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.  If yes, the
   packet is forwarded to the new destination.  Else, the packet is
   silently discarded.

4.2.  Operation when Mobile Router is Away

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

4.2.1.  Sending Router Advertisement

   The mobile router would continue to send Router Advertisement when it
   is away.  It should behave as specified in Section 4.1.1.  There is
   no difference in the Router Advertisement message whether the mobile
   router is at home or away.

4.2.2.  Receiving Router Advertisement

   The mobile router should solicit router advertisement from its access
   router whenever it changes its point of attachment to the Internet.
   When the mobile router receives the Router Advertisement, it should
   check if the access router has set the N-flag to 1.  If the N-flag is


Ng & Tanaka              Expires - April 2003                [Page 16]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   set to 1, the access router is NEMO-enabled.  If the flag is set to
   0, the access router is not NEMO-enabled.

4.2.3.  Sending Binding Updates

   When the mobile router sends Binding Updates to other hosts, either
   its own home agent or other correspondent nodes, it should add an
   Access Router Option to the Binding Updates if its access router is
   NEMO-enabled.  Otherwise, if its access router is not NEMO-enabled,
   the mobile router will not include the Access Router Option in the
   Binding Update messages.

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

4.2.4.  Processing Outbound Packets

   * Packet does not have a NEMO-Fwd RAO

   When the mobile router intercepts a packet from one of its ingress
   interfaces, the mobile router first checks if there is a NEMO-Fwd RAO
   attached to the packet.  When the NEMO-Fwd RAO is absent (or a NEMO-
   NFwd RAO is present), the mobile router has to route this packet
   through its own home agent.  The packet is encapsulated in an
   external packet addressed to the home agent of the mobile router.
   If the mobile router's access router is not NEMO-enabled, the outer
   packet is sent to the mobile router's home agent.  The external
   packet has the normal mobility characteristics, i.e. the source field
   contains the care-of-address of the mobile router, the destination
   field contains the address of the home agent of the mobile router,
   and a Home Address destination Option should specify the home-address
   of the mobile router.

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

   * Packet has a NEMO-Fwd RAO

   On the other hand, when the mobile router received a packet with a
   NEMO-Fwd RAO from one of its ingress interfaces, the mobile router


Ng & Tanaka              Expires - April 2003                [Page 17]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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

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

4.2.5.  Processing Inbound Packets

   When the mobile router received a packet from its access router the
   packet must contain a destination field equal the care-of-address of
   the mobile router, and a type 2 routing header.  If these conditions
   are not satisfied, the packet is silently discarded.  In addition,
   since the packet is addressed to the care-of-address of the mobile
   router, the packet must be sent from a host that has a binding entry
   of the mobile router.  If security measures warrant it, the mobile
   router may want to verify the sender is indeed a host in the mobile
   router's Binding Update List, and discard the packet if it isn't.

   The Segments Left field of RH2 is also checked.  If Segments Left
   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 (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 of the mobile
   router, the Segments Left field is checked if it is 0 (after
   decrementing).  If so, the packet is consumed by the mobile router.
   Otherwise, the packet is silently discarded.


Ng & Tanaka              Expires - April 2003                [Page 18]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   Alternatively, the new destination address may be an address in one
   of the mobile router'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 nor a valid address
   in one of the mobile router's ingress interfaces, the packet is
   silently discarded.

   When a packet is consumed by the mobile router, the payload may be an
   encapsulated packet.  In this case, sender of the outer packet must
   be the home agent of the mobile router.  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.  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 section highlights changes to the IPSec
   processing for inbound and outbound packets.

4.3.1.  IPSec Processing on Inbound Packets

   Inbound packets may contain a type 2 routing header with an AH/ESP.
   The routing header should be processed before AH.  If the mobile
   router is the final destination, the packet is passed to the IPSec
   module for AH/ESP processing.  Since the home agent will generate the
   AH/ESP in a such a way that it is consistent with the state of the
   packet headers when the receiver received the packet (see Section
   5.5.2), no additional processing needs to be done before the AH/ESP
   processing.

4.3.2.  IPSec Processing on Outbound Packets

   For outbound packets, the new option added to the packets by the
   Proposed NEMO Solution is the NEMO-Forward and NEMO-No-Forward Router
   Alert Options.  Originator of a packet will only insert the NEMO-Fwd
   RAO to a newly-created packet.  The NEMO-Fwd RAO will be changed to a
   NEMO-NFwd RAO by subsequent router, since all NEMO-enabled mobile
   routers will change the NEMO-Fwd RAO in a outgoing packet to a NEMO-
   NFwd RAO when

  (1)  the mobile router is attached to an access router that is not
       NEMO-enabled; or

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



Ng & Tanaka              Expires - April 2003                [Page 19]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   Thus the NEMO-Fwd RAO is a mutable but predictable option, where the
   receiver always received the NEMO-Fwd RAO as a NEMO-NFwd RAO.  Thus
   when generating AH authentication data, the sender should use a NEMO-
   NFwd RAO for AH processing.

   Also, when generating the AH authentication data, the originator
   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 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.  Receiving Binding Updates

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

   In addition, when returning a Binding Acknowledgement for a Binding
   Update that contains an Access Router Option, the Proposed NEMO
   Solution requires that the home agent return a Status code that is to
   be assigned (referred to as ARO-OK) to indicate that the Access
   Router Option is accepted.

   Note also that the home-agent MUST accept Binding Updates with ARO
   with or without the Home Registration bit set.

5.3.  Receiving Tunneled Packets from Away Nodes

   When the home agent 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 of the home-address in its binding cache, or the
   source address is a valid care-of-address/home-address of an access
   router that is in the upstream of the mobile node with the specified
   home-address.  Section 7.3 discusses the security considerations on


Ng & Tanaka              Expires - April 2003                [Page 20]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   accepting tunnels with a source address that is not directly bound to
   the home-address specified in the Home Address destination option.

   To establish this, the home agent can use the pseudo algorithm
   depicted in Figure 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 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 is found)
        {
           return (FALSE)
        }
        if (CoA field in the Binding Cache entry
              == source-address of outer packet)
        {
           return (TRUE)
        }
        if (the Binding Cache entry does not contain a valid access
              router address)
        {
           return (FALSE)
        }
        if (access router address field in the Binding Cache entry
              == source-address of outer packet)
        {
           return (TRUE)
        }
        set start-address = access router address field in the
                             Binding Cache entry
      }

           Figure 2: Algorithm to check source address is valid

5.4.  Tunneling Packets to Away Nodes

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

   In this case, the home agent will forward the packet to the mobile
   router at the care-of-address of the mobile router.  This is done by


Ng & Tanaka              Expires - April 2003                [Page 21]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   encapsulating the intercepted packet into a new packet.  According to
   standard Mobile IPv6 specification [9], the packet will have the
   source address set to the address of the home agent, destination set
   to the care-of-address of the mobile router, and a Type 2 Routing
   Header with only one address entry equals to the home-address of the
   mobile router.

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

      empty a stack
      set src-address = address of home agent
      set dst-address = HoA of mobile router
      set Finished = FALSE
      while (not Finished)
      {
         find entry in Binding Cache with HoA field = dst-address
         if (no Binding Cache entry is found)
         {
            Finished = TRUE
         }
         else
         {
            if (dst-address == HoA of mobile router)
            {
               push dst-address to stack
            }
            set dst-address = CoA field of the found Binding Cache entry
            if (the found Binding Cache entry contains a valid access
                   router address)
            {
               push dst-address to stack
               set dst-address = access router address field of found
                                    Binding Cache Entry
            }
            else
            {
               Finished = TRUE
            }
         }
      }
      if (stack is not empty)
      {
         prepare a type 2 routing header
         set Hdr Ext Len field of RH2 = (size of stack) x 2


Ng & Tanaka              Expires - April 2003                [Page 22]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


         set Segments Left field of RH2 = size of stack
         for n=1 to (Segments Left field of RH2)
         {
            pop top of stack to Address[n] of RH2
         }
      }

               Figure 3: Algorithm to construct extended RH2

   The 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 is a mutable but predictable header, such that
   the two end-points use the same routing header and IPv6 destination
   field for IPSec processing.  Particularly, the sender should
   calculate the IPSec parameters using values in the IPv6 headers that
   the receiver will receive.

5.5.  IPSec Processing

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

5.5.1.  IPSec Processing on Inbound Packets

   Packets that are inbound may have their source address modified en-
   route by access routers.  Thus, all home agents MUST use the
   algorithm shown in Figure 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 specified in the
   Home Address destination option, and the Home Address field of the
   Home Address destination option MUST be replaced with the care-of-
   address of the sender.  In Mobile IPv6, this care-of-address can be
   obtained from the source address field in the packet.  However, this
   Proposed NEMO Solution allows intermediate mobile routers to modify
   the source address field.  Thus, the home agent MUST obtain the care-
   of-address from its Binding cache.

   The above processing MUST be carried out before AH processing.

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



Ng & Tanaka              Expires - April 2003                [Page 23]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


6.  Considerations in the Use of Mutable Router Alert Option

   This section described the design considerations leading to the use
   of a mutable Router Alter Option.

6.1.  Router Alert Option

   The proposed solution described in this memo is designed so that it
   will work in a nested NEMO where some mobile routers are NEMO-enabled
   and some are not.  Thus, some form of indications on a packet is
   necessary to inform upstream mobile routers to attempt to use the
   Proposed NEMO Solution.  Since the indication is meant for
   intermediate routers, a hop-by-hop option is needed.

   The Router Alert Option [16] lends itself readily for use.  By
   assigning a value in RAO, a NEMO-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 access router to disable this behavior.

6.2.  Example where an Immutable RAO is Used

   To understand why a mobile router that is not attached to a NEMO-
   enabled access router should disable the NEMO-Fwd RAO, consider the
   following scenario, where MR1, MR2, and MR4 are NEMO-enabled mobile
   routers, LFR3 is a non-NEMO-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).  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)


Ng & Tanaka              Expires - April 2003                [Page 24]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   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
   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 for MR2 is
   marked invalid, the algorithm for checking the validity of the source
   address as shown in Figure 2 of Section 5.3 will fail.  Thus the
   packet will be discarded at HA1.


Ng & Tanaka              Expires - April 2003                [Page 25]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



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



Ng & Tanaka              Expires - April 2003                [Page 26]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   To solve this problem optimally, a mechanism must be defined to allow
   MR4 to notify MR2 its home-address, so that MR2 can specify the home-
   address of MR4 in the Access Router Option of a Binding Update
   message sent to the home agent of MR2.  It remains unclear how to
   provide such a mechanism without introducing additional security
   threats.

6.5.  Alternatives to the Mutable Router Alert Option

   There are other alternatives to the mutable Router Alert Option.
   These include using the Flow label in IPv6 header, and defining a new
   routing header type.  These are briefly described below.

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


Ng & Tanaka              Expires - April 2003                [Page 27]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


7.  Changing 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.  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 as the packet source address in Mobile
   IPv6.

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

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


8.  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.  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 of the mobile router that sends the
   Access Router Option.


Ng & Tanaka              Expires - April 2003                [Page 28]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   When a mobile router sends Binding Update to its home agent, current
   Mobile IPv6 draft specifies that the Binding Update 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 to correspondent node, the mobile router
   inserts the Access Router Option only when sending the actual Binding
   Update message.  The Binding Update message is protected using a key
   generated after obtaining the Care-of-Test and Home-Test 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 and Home-Test 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 message using the generated
   key, thus leading the correspondent node to believe that the mobile
   router is attached to another access router.

   To overcome this, it is suggested that the mobile router to insert
   the Access Router Option when sending the Care-of-Test Init Message.
   The NEMO-enabled corresponding node, 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 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 is protected.

   Note that if the correspondent node 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 to
   change the way the Authenticator value is generated, i.e. the value
   is generated using the method as specified in Mobile IPv6 [9]:

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

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




Ng & Tanaka              Expires - April 2003                [Page 29]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


8.2.  Router Global Address Option

   The introduction of global address of the access router in the
   Binding Update message is the crux of the Proposed NEMO Solution,
   since this is the link which allows home agents and correspondent
   nodes to set up the Type 2 Routing Header 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 sent by an away node to its home agent that
       contains the access router's global address is secure, and

  (2)  Binding Updates sent to corresponding nodes are reasonably
       protected using the Return Routablility Test.

   The weakest link is now the method in which the mobile router 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)  a malicious access router advertising false global address in
       Router Advertisement, and

  (2)  an attacker replays a Router Advertisement 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, we
   believed that the threat existed in IPv6 Neighbor Discovery [20].  In
   [20], security issues pertaining to Router Advertisement are
   discussed.  This discussion should be able to shed some light on how
   to advert such an attack.

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

   Mobile IPv6 forbids home agent from accepting tunnels with a source
   address that is not bound to the home-address 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 of Section 5.3 can be


Ng & Tanaka              Expires - April 2003                [Page 30]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   used to verify if the source address is "indirectly" bound to the
   home-address specified in the Home Address Option.

   As considered above in Section 6.1, the Access Router Option is
   secured by the fact that a Binding Update to the home agent is always
   secure.  In addition, the Access Router Option is fairly secured with
   the Return Routability Tests.  Thus the relaxation of the security
   measure of source address verification of a tunnel does not
   significantly increase the home agent'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 Solution to be administratively disabled or enabled.
   The default should be enabled.

8.4.  Use of Extended Routing Header Type 2

   The extension of the Type 2 Routing Header exposes this solution to
   additional security threats in that attackers can change the entries
   in the routing header to be routed to another entity.  However, we
   note that this extension is designed so that the extended Type 2
   Routing Header is now very similar to the Type 0 Routing Header.
   Thus, the security threats faced by Type 2 Routing Header 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)  causing the packet to be routed to another entity for snooping
       into the contents of the payloads;

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

  (3)  using the Type 2 Routing Header 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 is not used.

   For the threat where attacker construct a Type 2 Routing Header to
   reflect packets off a mobile network, we recommend that all routers
   supporting the Type 2 Routing Header to perform the following
   security measures:

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


Ng & Tanaka              Expires - April 2003                [Page 31]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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

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

   -  If the Segment Left field has a value greater than 1, the new
       destination address must contain a valid address in one of its
       ingress links.

   Effectively, the above security checks ensure the mobile router will
   discard any packets it received with a Type 2 Routing Header that
   requires the router to forward the packet through an egress link.
   This should reduce, if not eliminate, the possibility of using the
   extended Type 2 Routing Header for reflection attacks.

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

8.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 with
       the destination.  When binding update 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

      The attacker can add a NEMO-NFwd RAO to a packet.  This has no
       effect (other than causing AH to fail), since the default
       behavior of processing a packet with NEMO-NFwd RAO at a mobile
       router is the same as the default behavior of processing a
       packet without any RAO.

   -  Changing a NEMO-Fwd RAO to NEMO-NFwd RAO

      The attacker can change the value of the NEMO-Fwd RAO to a NEMO-
       NFwd RAO.  The effect of this form of attack is to cause the
       packet to be delivered sub-optimally (i.e. nested tunnels).



Ng & Tanaka              Expires - April 2003                [Page 32]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   -  Changing a NEMO-NFwd RAO to NEMO-Fwd RAO

      The attacker can change the value of the NEMO-NFwd RAO to a
       NEMO-Fwd RAO.  The effect of this form of attack is to cause
       subsequent mobile routers to perform binding update with the
       destination.  When binding update 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).

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

   As covered in Section 5.5.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.  Processing of Home Address Destination Option

   As specified in Mobile IPv6 [9], 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, when generating the AH authentication data.

   The Proposed NEMO 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 of the sender at the final
   destination.

   All home agents MUST use the algorithm shown in Figure 2 of Section
   5.3 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 specified in the Home Address destination option,


Ng & Tanaka              Expires - April 2003                [Page 33]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   and the Home Address field of the Home Address destination option
   will be replaced with the care-of-address of the sender.  This care-
   of-address is obtained from the receiver's Binding cache.

   The above processing MUST be carried out before AH processing.

8.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 to the packet, the receiver always received the RAO
   modified to NEMO-NFwd.  Thus the mutable NEMO-Fwd RAO is predictable.
   When AH is used, the originator should use the NEMO-NFwd 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 the initial draft of this memo.


References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997

   [3]  Soliman, H., and Pettersson, M., "Mobile Networks (MONET)
        Problem Statement and Scope", Internet Draft, draft-soliman-
        monet-statement-00.txt, Feb 2002, Work In Progress.

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

   [5]  Lach, H. et. al., "Mobile Networks Scenarios, Scope and
        Requirements", Internet Draft, draft-lach-monet-requirements-
        00.txt, Feb 2002, Work In Progress.

   [6]  Kniventon, T. J., and Yegin, A. E., "Problem Scope and
        Requirements for Mobile Networks Working Group", Internet
        Draft, draft-kniventon-monet-requiremetns-00.txt, Feb 2002,
        Work In Progress.




Ng & Tanaka              Expires - April 2003                [Page 34]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   [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., Perkins, C. E., and 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 Support with Mobile IP", Internet
        Draft: draft-kniveton-mobrtr-01.txt, Work In Progress, Mar
        2002.

   [12]  Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and
        Olivereau, A., "Mobile Networks Support in Mobile IPv6 (Prefix
        Scope Binding Updates)", Internet Draft: draft-ernst-mobileip-
        v6-network-03.txt, Mar 2002.

   [13] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization
        Models in the 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] Ernst, T., and Lach, H., "Network Mobility Support
        Terminology", Internet Draft, draft-ernst-nemo-terminology-
        00.txt, Oct 2002, Work In Progress.

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

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

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

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




Ng & Tanaka              Expires - April 2003                [Page 35]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   [20] Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery
        for IPv6", IETF RFC 2461, Dec 1998.


Author's Addresses

   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #04-3530
   Tai Seng Industrial Estate
   Singapore 534415
   Phone: (+65) 6554 5420
   Email: cwng@psl.com.sg

   Takeshi Tanaka
   Wireless Solution Laboratories
   Matsushita Communication Industrial Co Ltd
   5-3, Hikarinooka, Yokoshuka-shi, Kanagawa
   239-0847, Japan
   Phone: +81-468-40-5494
   Email: Takeshi.Tanaka@yrp.mci.mei.co.jp


Appendices

A.  Route Optimization

   It is possible to extend the proposed solution described in this memo
   to perform route optimization for NEMO-enabled mobile network hosts.

   For an NEMO-enabled mobile network host, when it detects that its
   access router is NEMO-enabled (from the Router Advertisement), it
   sends Binding Update with Access Router Option to its home agent.
   From here, it will use reverse tunneling with its home agent to send
   packets to corresponding nodes.  The mobile network nodes will also
   insert the NEMO-Fwd RAO into tunnel packet so as to achieve nested
   tunnel optimization.

   In order to achieve full route optimization, corresponding nodes are
   required to be NEMO-enabled.  Specifically, they should be able to
   recognize the Access Router Option in a Binding Update message and
   set the appropriate Status code in a Binding Advertisement, be able
   to construct an extended Type 2 Routing Header using the algorithm
   specified in Figure 3 of Section 5.4, and be able to verify the
   source address of a received packet using the algorithm specified in
   Figure 2 of Section 5.3.




Ng & Tanaka              Expires - April 2003                [Page 36]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


B.  Other NEMO Solution Proposals

B.1.  IPv6 Reverse Routing Header

B.1.1.   Overview of the Reversed Routing Header Solution

   The current proposal uses the notion of access router to allow home
   agents to construct routing header so that pinball effect of nested
   tunnels can be avoided in a nested NEMO.  A very similar proposal is
   the use of Reverse Type 2 Routing Header proposed by Thubert et. al.
   [14], where a reverse routing header is attached to the tunnel packet
   sent by the lowest level mobile router.  Subsequent upstream mobile
   routers would not further encapsulate the packet.  Instead, they will
   move the source address of the incoming packet to the next available
   entry of the reverse routing header, and put their own care-of-
   address in the source address field.  In this way, the home agent
   receiving this packet can construct the chain of access routers the
   mobile router is attached to.  From there, a packet addressed to the
   mobile router (or to the NEMO controlled by the mobile router) can be
   sent with an extended Type 2 Routing Header similar to the mechanism
   proposed here.

B.1.2.   Comparison

   In comparison, the proposal by Thubert et. al. is more efficient.  It
   does not require each mobile router on the path to perform binding
   updates with the home agent of the lowest-level mobile router, as
   this proposal do.  Any change in the nested NEMO topology is
   immediately reflected in the reversed routing header.  Whereas, for
   the solution proposed in this memo, changes in nested NEMO topology
   will have to be propagated slowly via binding updates sent by mobile
   routers at each nested level.

   However, the simplicity of the Reversed Routing Header solution is
   also its greatest disadvantage: it is extremely difficult to
   establish the credibility of the reverse routing header received by
   the home agent.  Because of the lack of binding updates from the
   upper layer mobile routers, the home agent has no way of knowing if
   the reverse routing header is tampered with en-route.  On the hand,
   the solution proposed in this memo uses Mobile IPv6 binding mechanism
   to establish the chain of routers an away node is attached to.  Thus
   it does not introduce any additional security threats that are not
   already present in Mobile IPv6.

   Furthermore, the Reverse Routing Header solution requires home agents
   (and correspondent nodes, if route optimization is used) to maintain
   a list of reverse routing headers for each mobile router.  This is
   more expensive (computationally and storage capacity wise) to
   maintain than a binding cache, since reverse routing header can vary


Ng & Tanaka              Expires - April 2003                [Page 37]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   in size.  On the other hand, the solution proposed in this memo
   merely requires an additional column in the binding cache to record
   the access routers' addresses.  However, admittedly, the current
   solution does increase the processing load of home agents and
   correspondent nodes by requiring them to construct a routing header
   from the binding cache.

B.1.3.   Possible Merging of Solutions

   As the Reverse Routing Header and the proposal described in this memo
   attempts to solve similar problems (i.e. nested tunnel optimization),
   it is possible to merge the two solutions.  Both extend the routing
   header type 2 to contain more than one address.  For the packet path
   from a mobile router to its home agent, [14] uses the reverse routing
   header to forward the packet and overcome ingress filtering, while
   the current proposal uses a Router Alert Option to request direct
   forwarding, and allow the upper level mobile routers to change the
   source address of the packet.

   A possible merged solution can have the following characteristics:

  (1)  mobile routers use the Access Router Option to inform home
       agents the access routers they are currently attached to;

  (2)  home agents use the Access Router Option to update their Binding
       Cache, where each entry in the Binding Cache contains an extra
       field to store the home-address of access router;

  (3)  mobile routers attach the reverse routing header on tunnel
       packets for upper level routers to append their care-of-
       addresses; and

  (4)  home agents use the extra field in the Binding Cache to check
       the legitimacy of the reverse routing header in a received
       tunnel packet.

   The above discussion outlines a possible approach to merge the two
   proposals.  Further analysis is needed to establish the feasibility
   of such an approach.

B.2.  Prefix Scope Binding Update (PSBU)

   Other proposed solution includes Prefix Scope Binding Update proposed
   by Ernst et. al. [12].   The main idea in this work is to specify the
   prefix length in the Binding Update, so that correspondent nodes, as
   well as home agent, realize that any address falling into the home-
   prefix is bound to that care-of-address.  The current proposal works
   well with such a Prefix Scope Binding Update, and can coexist or be
   merged as one solution.


Ng & Tanaka              Expires - April 2003                [Page 38]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



B.3.  Hierarchical Mobile IPv6 (HMIPv6)

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


C.  Examples

   This Section describes several examples to illustrate how the
   proposed solution works.  These examples are based on the scenario
   described in Figure C.1 below.  Here, LFN1 is a local fixed node
   attached to MR1.  MR1 and MR2 are NEMO-enabled mobile routers, and
   HA1 and HA2 are the home agents of MR1 and MR2 respectively.  LFN1 is
   communicating with a corresponding node CN1.

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

C.1.  Abbreviations

   In the following illustrations, the following abbreviations are used:

      ARO:  Access Router Option
      BU:   Binding Update
      BA:   Binding Acknowledgement
      HAO:  Home Address Destination Option
      RH2:  extended Type 2 Routing Header




Ng & Tanaka              Expires - April 2003                [Page 39]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



C.2.  MR1 attaches to MR2

   In this section, the messages exchange is described after MR1
   attaches to MR2.

C.2.1.  MR1 establishes binding to HA1

   (1) MR1 Receives RA from MR2

      When MR1 attaches to MR2, MR1 receives Router Advertisement with N
      bit set, Router Home Address Option = MR2.HoA from MR2.  MR1 knows
      it is attached to a NEMO-enabled router.

   (2) MR1 sends BU to HA1

      BU sent from MR1 to HA1 looks like this:

         IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Mobility Hdr
               BU (A bit=1)
               ARO (MR2.HoA)
   (3)   MR2 encapsulates the BU

      When the BU reaches MR2, it will be further encapsulated into a
      tunnel between MR2 and HA2.  The encapsulated packet from MR2 to
      HA2 will look like this:

         IPv6 Hdr (src=MR2.CoA, dst=HA2)
         Dst Opt
               HAO (MR2.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Mobility Hdr
               BU (A bit=1)
               ARO (MR2.HoA)
            Mobility Hdr
               BU (A bit=1)
               ARO (MR2.HoA)






Ng & Tanaka              Expires - April 2003                [Page 40]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   (4) HA2 processes the tunnel packet

      When HA2 receives the tunnel packet, it first processes AH/ESP
      with the address in HAO.  Then HA1 checks if it has an entry for
      MR1.HoA as Home Address. Next HA1 decapsulates the packet, and
      forward the inner packet to HA1.

   (5) HA1 processes the BU

      HA1 first processes AH/ESP with the address in HAO, checking if it
      has an entry for MR1.HoA as Home Address. Next HA1 notices it has
      Access Router field and creates/updates binding entry for MR2 with
      Access Router field set.  After this, the Binding Cache of HA1 has
      the following entry:

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

   (6) HA1 sends BA to MR1

      BA sent from HA1 to MR1 looks like this:

         IPv6 Hdr (src=HA1, dst=MR2.HoA)
         RH2 ( Segments Left=2,
               Address[1]=MR1.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Mobility Hdr
               BA (status=ARO-OK)

   (7) HA2 receives the BA

      HA2 intercepts the packet from HA1 to MR2 and encapsulates it.
      Using the algorithm given in Figure 3 of Section 5.4, HA2
      constructs a RH2 and attaches it to the outer packet.  Packet sent
      from HA2 looks like this:

         IPv6 Hdr (src=HA2, dst=MR2.CoA)
         RH2 ( Segments Left=1,
               Address[1]=MR2.HoA)
         AH/ESP hdr
         Encapsulated IPv6 Hdr (src=HA1, dst=MR2.HoA)
         RH2 ( Segments Left=2,
               Address[1]=MR1.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Mobility Hdr
               BA (status=ARO-OK)


Ng & Tanaka              Expires - April 2003                [Page 41]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   (8) MR2 receives BA

      MR2 receives the packet and processes the RH2.   MR2 notices that
      the Segments Left field is 1 and verifies that the last address in
      RH2 is its own home-address.  It decapsulates the packet and
      process the inner packet.

      The inner packet has destination field equals to the home-address
      of MR2.  So MR2 processes the inner packet, and updates the RH2 of
      the inner packet.  It verifies that the new destination is a valid
      address in its ingress interface, and sends it off.

      BA sent from MR2 to MR1 looks like this:

        IPv6 Hdr (src=HA1, dst=MR1.CoA)
         RH2 ( Segments Left=1,
               Address[1]=MR2.HoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Mobility Hdr
               BA (status=ARO-OK)

   (9) MR1 receives BA

      MR1 receives the packet and processes the RH2. Since Segments
      Left=1, it verifies that the last address in RH2 is its own home-
      address.  After MR1 processes RH2, the packet looks like this:

        IPv6 Hdr (src=HA1, dst=MR1.HoA)
         RH2 ( Segments Left=0,
               Address[1]=MR2.HoA,
               Address[2]=MR1.CoA )
         AH/ESP Hdr
         Mobility Hdr
               BA (status=ARO-OK)

      Since MR1 has a SA with HA1, MR1 processes AH/ESP.  After that,
      MR1 knows that the BU it sent previously was accepted by HA1.

C.2.2.  LFN1 sends packet to CN1

   (1) LFN1 sends packet to CN1

      Packet sent from LFN1 to CN1 looks like this:

         IPv6 Hdr (src=LFN1, dst=CN1)
         Data



Ng & Tanaka              Expires - April 2003                [Page 42]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


   (2) MR1 receives packet from LFN1

      MR1 notices the packet does not have NEMO-Fwd RAO in it, thus MR1
      encapsulate it.  Since access router of MR1 is NEMO-enabled, MR1
      adds NEMO-Fwd RAO to the outer packet.

      Packet sent from MR1 to MR2 looks like this:

         IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Hop-by-Hop Opt
               RAO (NEMO-Fwd)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
         Data

   (3) MR2 receives packet from MR1

      MR2 notices the packet has NEMO-Fwd RAO in it, but MR2 does not
      have binding to the destination (=HA1), thus MR2 encapsulates the
      packet and tunnels to HA2.  Since access router of MR2 is not
      NEMO-enabled, MR2 does not add NEMO-Fwd RAO to outer packet.

      Packet sent from MR2 to HA2 looks like this:

         IPv6 Hdr (src=MR2.CoA, dst=HA2)
         Dst Opt
               HAO (MR2.CoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Hop-by-Hop Opt
               RAO (NEMO-Fwd)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
         Data

   (4) HA2 receives packet from MR2

     HA2 receives the packet and verify that the source address is
     valid using the algorithm described in Figure 2 of Section 5.3.
     The packet is decapsulated and the inner packet is forwarded to
     HA1.

     The packet from HA2 to HA1 looks like this:




Ng & Tanaka              Expires - April 2003                [Page 43]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


         IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Hop-by-Hop Opt
               RAO (NEMO-Fwd)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
         Data

   (5) HA1 receives packet from HA2

     HA1 receives the packet and verify that the source address is
     valid using the algorithm described in Figure 2 of Section 5.3.
     The packet is decapsulated and the inner packet is forwarded to
     CN1.

C.2.3.  CN1 sends packet to LFN1

   (1) CN1 sends packet to LFN1

      Packet sent from CN1 to LFN1 looks like this:

         IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (2) HA1 receives packet from CN1

      Since address of LFN1 belongs to MR1, the packet is routed to HA1.
      HA1 notices MR1 is away from home, thus HA1 encapsulates the
      packet and constructs an extended RH2.

      Packet sent from HA1 looks like this:

         IPv6 Hdr (src=HA1, dst=MR2.HoA)
         RH2 ( Segments Left=2,
               Address[1]=MR1.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (3) HA2 receives packet from HA1

      Since the packet is addressed to MR2.HoA, it is routed to HA2.
      HA2 notices MR2 is away from home, thus HA2 encapsulates the
      packet and forwards to MR2.

      Packet sent from HA2 looks like this:



Ng & Tanaka              Expires - April 2003                [Page 44]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


        IPv6 Hdr (src=HA2, dst=MR2.CoA)
        RH2 ( Segments Left=1,
              Address[1]=MR2.HoA )
        AH/ESP Hdr
        Encapsulated IPv6 Hdr (src=HA1, dst=MR2.HoA)
         RH2 ( Segments Left=2,
               Address[1]=MR1.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (4) MR2 receives packet from HA2

      MR2 receives the packet and processes the RH2.   MR2 notices that
      the Segments Left field is 1 and verifies that the last address in
      RH2 is its own home-address.  It decapsulates the packet and
      process the inner packet.

      The inner packet has destination field equals to the home-address
      of MR2.  So MR2 processes the inner packet, and updates the RH2 of
      the inner packet.  It verifies that the new destination is a valid
      address in its ingress interface, and sends it off.

      Packet sent from MR2 to MR1 looks like this:

        IPv6 Hdr (src=HA2, dst=MR1.CoA)
         RH2 ( Segments Left=1,
               Address[1]=MR2.HoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (5) MR1 receives packet from MR2

      MR1 receives the packet and processes the RH2.   MR1 notices that
      the Segments Left field is 1 and verifies that the last address in
      RH2 is its own home-address.  It decapsulates the packet and sends
      the inner packet to LFN1.











Ng & Tanaka              Expires - April 2003                [Page 45]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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


Ng & Tanaka              Expires - April 2003                [Page 46]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   (2) MR1 receives packet from LFN1

      MR1 notices the packet does not have NEMO-Fwd RAO in it, MR1
      encapsulates it and adds NEMO-Fwd RAO to outer packet.  Packet
      sent from MR1 to MR2 looks like this:

         IPv6 Hdr (src=MR1.CoA, dst=HA1)
         Hop-by-Hop Opt
               RAO (NEMO-Fwd)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
         Data

   (3) MR2 receives packet from MR1

      MR2 notices the packet has NEMO-Fwd RAO in it, and MR2 has binding
      to the destination (=HA1), thus MR2 changes the source address to
      MR2.CoA and sends the packet directly to HA1.  Since access router
      of MR2 is not NEMO-enabled, MR2 changes NEMO-Fwd to NEMO-NFwd RAO.

      Packet sent from MR2 to HA1 looks like this:

         IPv6 Hdr (src=MR2.CoA, dst=HA1)
         Hop-by-Hop Opt
               RAO (NEMO-NFwd)
         Dst Opt
               HAO (MR1.HoA)
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=LFN1, dst=CN1)
         Data

   (4) HA1 receives packet from MR2

     HA1 receives the packet and verify that the source address is
     valid using the algorithm described in Figure 2 of Section 5.3.
     The packet is decapsulated and the inner packet is forwarded to
     CN1.

C.2.6.  CN1 sends packet to LFN1

   (1) CN1 sends packet to LFN1

     Packet sent from LFN1 to CN1 looks like this:

         IPv6 Hdr (src=CN1, dst=LFN1)
         Data


Ng & Tanaka              Expires - April 2003                [Page 47]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002



   (2) HA1 receives packet from CN1

     HA1 intercepts the packet from CN1 to LFN1 and encapsulates it.
     Using the algorithm given in Figure 3 of Section 5.4, HA1
     constructs a RH2 and attaches it to the outer packet.

     Packet sent from HA1 to MR1 looks like this:

         IPv6 Hdr (src=HA1, dst=MR2.CoA)
         RH2 ( Segments Left=2,
               Address[1]=MR1.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (3) MR2 receives packet from HA1

     MR2 receives the packet and processes the RH2.   The Segments Left
     field is decremented, and the destination address in the IPv6
     header is swapped with the next address in RH2.  MR2 checks that
     the new destination address is a valid address in its ingress
     interface, and sends the packet out.

     Packet sent from MR2 to MR1 looks like this:

         IPv6 Hdr (src=HA1, dst=MR1.CoA)
         RH2 ( Segments Left=1,
               Address[1]=MR2.CoA,
               Address[2]=MR1.HoA )
         AH/ESP Hdr
         Encapsulated IPv6 Hdr (src=CN1, dst=LFN1)
         Data

   (4) MR1 receives packet from MR2

     MR1 receives the packet and processes the RH2.   MR1 notices that
     the Segments Left field is 1 and verifies that the last address in
     RH2 is its own home-address.  The inner packet is decapsulated and
     sent to LFN1.

C.3.  MR2 moves to new location

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



Ng & Tanaka              Expires - April 2003                [Page 48]


Internet-Draft   Securing Nested Tunnels Optimization     October 2002


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 the BU

      Next HA1 checks Binding Auth data. Then HA1 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.nCoA          <invalid>

      It should be noted that the state of the Binding Cache 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 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.






Ng & Tanaka              Expires - April 2003                [Page 49]