Internet DRAFT - draft-wakikawa-nemo-basic

draft-wakikawa-nemo-basic





INTERNET DRAFT                                            Ryuji Wakikawa
18 Feb 2003                                               Keisuke Uehara
                                                         Koshiro Mitsuya
                                                           Thierry Ernst
                                                Keio University and WIDE

                     Basic Network Mobility Support
                    draft-wakikawa-nemo-basic-00.txt


Status of This Memo

   This document is a submission to the Network Mobility Working Group
   of the Internet Engineering Task Force (IETF). Comments should be
   submitted to the nemo@nal.motlabs.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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

   This draft proposes a solution for Basic Network Support.  It
   proposes Mobile IPv6 extensions as advocated by the NEMO working
   group.  Our solution differs from Prefix Scope Binding Update (PSBU)
   which was originally proposed before the NEMO working group was set
   up.  Our draft however uses mechanisms similar to those of PSBU, such
   as ``Prefix binding'' and ``Searching mechanism of prefix binding''.
   The main difference relies on the management of the permanent address
   of the MR, which is assigned to the ingress interface, and not to the
   egress interface.


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page i]

Internet Draft               Basic NEMO Support              18 Feb 2003


                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2

 3. Protocol Overview                                                  3

 4. Mobile IPv6 extension                                              5
     4.1. Binding Cache and Binding Update Management . . . . . . .    5
     4.2. Binding Update  . . . . . . . . . . . . . . . . . . . . .    6
     4.3. Binding Acknowledgment  . . . . . . . . . . . . . . . . .    6
     4.4. Prefix Sub-option . . . . . . . . . . . . . . . . . . . .    7
     4.5. Extended Use of Home Address Option . . . . . . . . . . .    7
     4.6. Search Algorithm of Prefix Binding in Binding Cache . . .    8

 5. Mobile Router Operation                                            9
     5.1. Packet Processing . . . . . . . . . . . . . . . . . . . .    9
           5.1.1. Forwarding Packets to the Internet  . . . . . . .    9
           5.1.2. Receiving Packets from HA . . . . . . . . . . . .    9
           5.1.3. MR acting as an end-node  . . . . . . . . . . . .    9
     5.2. Binding Processing  . . . . . . . . . . . . . . . . . . .   10
           5.2.1. Sending Binding Updates . . . . . . . . . . . . .   10
           5.2.2. Receiving Binding Acknowledgments . . . . . . . .   10
     5.3. Returning to HA link  . . . . . . . . . . . . . . . . . .   11
     5.4. Types of Tunneled Packets to HA . . . . . . . . . . . . .   12

 6. Home Agent Operation                                              12
     6.1. Processing Bindings . . . . . . . . . . . . . . . . . . .   12
           6.1.1. Receiving Binding Updates . . . . . . . . . . . .   12
           6.1.2. Sending Binding Acknowledgments . . . . . . . . .   13
     6.2. Packet Processing . . . . . . . . . . . . . . . . . . . .   14
           6.2.1. Sending Packets to MR . . . . . . . . . . . . . .   14
           6.2.2. Receiving Packets from MR . . . . . . . . . . . .   14
     6.3. Types of Tunneled Packets to MR . . . . . . . . . . . . .   15

 7. Security Overview                                                 15

 8. Multicast Support                                                 17

 9. Mobile IPv6 Compatibility                                         17


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page ii]

Internet Draft               Basic NEMO Support              18 Feb 2003


10. Nested Mobility                                                   18
    10.1. Visiting MN Attached to Mobile Network  . . . . . . . . .   18
    10.2. MR Attached to Mobile Network . . . . . . . . . . . . . .   18

Acknowledgments                                                       18

Appendices                                                            19

 A. Specification Comparison with WG requirements                     19

References                                                            19

Authors' Addresses                                                    21


1. Introduction

   The proposed protocol is designed as an extension to Mobile IPv6.
   All the requirements for a basic NEMO solution are described in [6].
   The solution for basic network mobility support is to set up a
   bi-directional tunnel between the MR and its HA. This protocol
   establishes the bi-directional tunnel by binding operation of Mobile
   IPv6.  This draft extends the usage of home address option, binding
   update option, and binding management and defines a prefix sub-option
   for binding update message.  This draft also extends the definition
   of binding to manage a various prefix length for a home address.
   Details regarding the modifications to existing Mobile IPv6 will be
   mentioned later in this document.

   A similar approach was first proposed as PSBU [7].  PSBU proposed the
   notion of prefix binding.  The difference from PSBU is the management
   of MR's home address.  This draft need not to assign a home address
   which is different from a mobile network prefix.  MR has still a
   permanent address, but is the address of the ingress interface named
   on the mobile router address instead of the address of the egress
   interface on the same link as the HA.

   This difference makes possible to communicate in various network
   topologies such as nested mobility and multiple HA links which
   are like home link of MR. It also achieves to authorize and
   authenticate mobile network prefix with MR as described in section 7.
   In addition, MR's host mobility by means of its home address
   is managed as a part of network mobility.  Therefore, it gives
   several optimization to reduce the size of packets as described in
   section 5.1.3 and section 5.3.


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 1]

Internet Draft               Basic NEMO Support              18 Feb 2003


2. Terminology

   The keywords ``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].

   Most of terms are defined in [8].

      Mobile Router Address (MR-A)

         The permanent address generated by a delegated mobile network
         prefix and statically assigned to the ingress interface.

      Mobile Router Care-of Address (MR-CoA)

         The address which is dynamically assigned to the egress
         interface of MR on the foreign link.

      Prefix Binding

         The prefix binding associates between a mobile network prefix
         and a MR-CoA. The prefix binding is stored in the binding cache
         as well as a binding of Mobile IPv6[11].  The prefix binding
         is first proposed in PSBU, but our prefix binding store the
         information in the following two way:

          -  If a prefix binding is searched with the registered prefix
             length, it becomes the binding for a mobile network prefix

          -  If a prefix binding is searched with 128-bit prefix length
             as general Mobile IPv6, it becomes the binding of the MR.
             In this case, the MR is treated as a MN.

      Home Agent (HA)

         HA MUST be able to delegate a prefix to a MR by any delegation
         protocols.  How to delegate prefix is currently out of scope
         in this draft, but any updates of prefix delegation for mobile
         network must be employed on this protocol.  This will be
         clarified in a forthcoming revision of the draft.

         The HA MUST NOT have an address belonging to a mobile network
         prefix, but it MUST be addressed by any IPv6 global address.
         For dynamic configuration, a MR obtain a HA address during
         prefix delegation operations.

         MR MUST have a HA configured either statically or dynamically
         in the Internet.  The HA MUST advertise route information


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 2]

Internet Draft               Basic NEMO Support              18 Feb 2003


         of mobile network prefix by any routing protocols such
         as OSPF6 [3], RIPng [15], BGP [14], etc.  and it MUST be
         identified as a gateway of the prefix in the Internet topology.

      HA link

         The HA link is not the link for a mobile network prefix, but
         it is the link of the HA. The prefix advertised on the HA link
         MUST be different from the mobile network prefix.  The prefix
         MUST be managed by HA. MR MAY return to the HA link.  HA can
         manage several HA links if needed.  There is no difference in
         the operations between single HA link and multiple HA links.

      Prefix Sub-option

         A mobility header sub-option is used to carry a prefix length
         of a mobile network.  This sub-option is valid only in Binding
         Update (BU).


3. Protocol Overview

   This section shows the protocol outline.  The figure 1 is a typical
   network configuration of a mobile network.  MR is attached to a
   visiting network in this figure.  Protocol operations is split into
   below steps.

    1. MR acquisition of Mobile Network Prefix:  At the beginning, MR
       MUST have a mobile network prefix delegated from its HA. Dynamic
       HA discovery can be used to discover the HA address by MR. MR
       can also have a statically configured HA before starting any
       operations.

    2. MR configuration of MR-A to egress interfaces:  The MR,
       carrying a mobile network attaching to the Internet, has a home
       address (MR-A) assigned to its ingress interface.  The MR-A is
       generated by the mobile network prefix (ex.  mobile network
       prefix and MR's EUI-64 identifier).  The MR can be identified
       with MR-A from the Internet regardless of its location in the
       Internet.

    3. MR configuration of MR-CoA to ingress interfaces:  When the MR
       moves to a different network, the MR obtains a topologically
       correct global address as a MR-CoA at the egress interface.

    4. MR sending BU to HA: The MR sends a BU to its HA to create a
       prefix binding instead of host binding.  The BU MUST contain a
       home address option containing MR-A and a prefix sub-option with
       the length of its mobile network prefix.  The prefix sub-option


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 3]

Internet Draft               Basic NEMO Support              18 Feb 2003


          CN  CN  CN  CN  CN  CN
        ___|__|___|___|___|___|___
          |
       ___|_____________________
      |                        |
      |    Internet            |
      |________________________|
         __|_           __|__ <-- HA Address 3ffe:306:1130::eui64
        |    |         |     | Prefix Binding
        | AR |         | HA  |  MR-A/64<->MR-CoA
        |____|         |_____|
           |          ____|______ HA Link (3ffe:306:1130:1::/64)
    _______|________
    foreign link 3ffe:306:5555:7777::/64
           |
           |
         __|<-- MR-CoA 3ffe:306:5555:7777::mr_eui64
        |    |
        | MR | Mobile Network Prefix 3ffe:306:1130:200::/64
        |____|
           |<-- MR-A   3ffe:306:1130:200::mr_eui64
      _____|_________
       |         |
     __|__     __|__
    |     |   |     |
    | MNN |   | MNN |
    |_____|   |_____| 3ffe:306:1130:200::eui64


            Figure 1: Example of Mobile Network Configuration


       is defined in section 4.4.  If the BU is successfully processed
       by the HA, the MR creates a tunnel to the HA as shown in [11].

    5. HA caching of Prefix Binding:  When receiving the BU, the HA
       caches prefix binding.  The HA retrieves the mobile network
       prefix from the MR-A with the mobile network prefix length in the
       prefix sub-option.  The MR-A is stored at the home address option
       in the BU. The MR-CoA is stored in a source address field of IPv6
       header.  This prefix binding can also be treated as a Mobile IPv6
       binding of the MR.

    6. HA tunneling packets addressed to Mobile Network:  The HA
       intercepts and tunnels all packets destined to the MR's mobile


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 4]

Internet Draft               Basic NEMO Support              18 Feb 2003


       network prefix by IP-in-IP encapsulation.  The HA operation of
       tunneling packets is same as Mobile IPv6 except for binding
       search.  Since the MR registers the prefix binding containing the
       prefix length, the HA MUST use address longest-match algorithm
       to scan the binding cache database.  First HA MUST search the
       binding with 128-bit prefix length for intercepted packets.
       If HA finds a binding, it MUST tunnel packets as Mobile IPv6
       operation.  Otherwise, the HA MUST compare the destination
       address of intercepted packets with the MR's mobile network
       prefix.  If the HA finds a prefix binding, the HA MUST tunnel
       packets to the registering MR-CoA.

    7. Sending packet from MNN to a CN in the global Internet:  When
       a MNN in the mobile network sends packets to the Internet, the
       MR intercepts the packets and encapsulates them to the HA. The
       source address of encapsulated packets is the MR-CoA to bypass
       ingress filtering.  MR MUST NOT insert the home address option
       as general Mobile IPv6, since falsification of MNNs' packets
       on intermediate nodes like MR should be avoided from security
       considerations.  Although encapsulation of packets [4] add
       additional IPv6 header, it does not change the orignal packets.

    8. Sending packet from MR to HA or a CN in the global Internet:
       When the MR sends packets to its registered HA as a MN, it is
       RECOMMENDED to use a home address option storing the MR-A. These
       operation is the same as Mobile IPv6.  This keeps the additional
       packet's size smaller than the additional size of tunneled
       packets.  e.x.  home address option (20byte) is smaller than IPv6
       header (40 bytes).  The HA is RECOMMENDED to reply packets with
       a routing header type 2.  The MR MAY tunnel packets to the HA
       instead of using a home address option, and vice versa.

       If the destination is CNs, the MR MUST always tunnel packets via
       HA.

    9. MR management of routing information inside mobile network
       The routing management inside a mobile network is not discussed
       in this draft, but any protocol such as OSPF6, RIPng, or any
       MANET protocol [18] can be used.


4. Mobile IPv6 extension

4.1. Binding Cache and Binding Update Management

   This draft requires to have an additional item for binding cache and
   binding update structures defined in Mobile IPv6, which is


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 5]

Internet Draft               Basic NEMO Support              18 Feb 2003


    -  Prefix Length
       The prefix length of a mobile network prefix.  The mobile network
       prefix is identified by MR-A and the prefix length.

   MR MUST keep prefix length in its binding update list database.

   HA MUST register the prefix length in its binding cache if the prefix
   length is available in the BU. HA MUST use the prefix length to
   search a binding cache database if needed.


4.2. Binding Update

   When MR registers its prefix binding to its HA, the MR MUST set 'N'
   flag and include the prefix sub-option.

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |          Sequence #           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|L|K|N|      Reserved       |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Network Mobility Flag (N)
           Network Mobility Flag:  used for a prefix binding
           registration.  This flag defines that this BU contains a
           prefix sub-option and is for a mobile network.

      Reserved
           Reserved field is reduced to 11 bits.


4.3. Binding Acknowledgment

   Since the 'N' flag is valid only for the HA (i.e.  home
   registration), HA which receives BU with 'N' flag MUST reply BA
   as described in section 6.1.2.  The receiver also MUST reply BA
   with correspondent error number if it encounters some error while
   processing BU and its sub-option.

   This document assigns new status codes for mobile network prefix
   registration.


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 6]

Internet Draft               Basic NEMO Support              18 Feb 2003


     2 Successfully registered a mobile network prefix

     3 Successfully registered a mobile network prefix at HA link

   140 Invalid Prefix Length


4.4. Prefix Sub-option

   Prefix sub-option MAY only be appended in a BU message.  Prefix
   length field contains the length of a mobile network prefix.
   Receiving nodes MUST use this prefix length whenever they refer to
   binding cache database.

 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 = 2  | Prefix Length |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       (alignment requirement: 2n)


      Type

         TBD

      Length

         2


         The length of the option (excluding the type and length fields)
         in units of 8 octets.

      Prefix Length


         The 8 bit IPv6 prefix length of a mobile network prefix

      reserved

         The 8 bit reserved field.  MUST be set to zero.


4.5. Extended Use of Home Address Option

   In Mobile IPv6 [11], Mobile Node (MN) uses one of its Care-of
   Addresses (CoAs) as the source address in the packets' IPv6 header


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 7]

Internet Draft               Basic NEMO Support              18 Feb 2003


   and puts the home address in a home address option.  CNs substitute
   the MN's home address with the CoA when processing the packet.  A
   Home Address option is used in a packet sent by the MN to inform the
   recipient of the fact that packets are of the MN's home address.

   MR only uses home address option for BU packets and MUST NOT use
   it for any packets other than control packets (i.e.  BU) and its
   originated packets.  Insertion of the home address option on MR
   alters orignal packets.  Modifying MNNs' packets on MR should be
   avoided for security considerations.  Therefore, for outgoing data
   packets from MNN, MR encapsulate packets with MR-CoA as an IPv6
   source address to bypass ingress filtering.  Although encapsulation
   of packets add additional IPv6 header, it does not change orignal
   packets.

   If MR originates packets to its registering HA as a MN, it SHOULD use
   the home address option as MN of Mobile IPv6.


4.6. Search Algorithm of Prefix Binding in Binding Cache

   The similar search algorithm was first proposed in PSBU [7].

   Prefix binding enables HA to find an appropriate prefix binding for
   packets destined to mobile network.  Mobile IPv6 always searches
   a binding cache entry with 128-bit prefix length.  Therefore, it
   can not pick a prefix binding for packets destined to MNNs, because
   addresses between MR (MR-A) and MNNs are different in 128-bit prefix
   length.  Thus, the binding cache MUST be searched by using a mobile
   network prefix (a prefix length part of MR-A). The prefix between
   MR (MR-A) and MNNs are the same.

   The efficient algorithm for this situation is the address
   longest-match.  The sequence of this search is as shown below:

     1 HA searches a binding cache database with 128-bit prefix length
       as Mobile IPv6.

     2 HA searches a binding cache database with a registered prefix
       length in a prefix binding only if a prefix length is available
       (i.e.  the binding is a prefix binding).

   When packets are destined to the MR-A itself (not MNN), the algorithm
   enables HA to find a prefix binding as a Mobile IPv6 binding for
   the MR-A. This is important when there are multiple MRs in a mobile
   network and MRs advertised a same mobile network prefix.  If HA
   search a binding cache database only by the second algorithm, HA can
   not determine which MR is the destination node of the packets.  It is
   because the mobile network prefix of each MR-A is the same value.


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 8]

Internet Draft               Basic NEMO Support              18 Feb 2003


5. Mobile Router Operation

5.1. Packet Processing

5.1.1. Forwarding Packets to the Internet

   When MR receives packet from MNNs on its ingress interface and
   intended to a CN in the global Internet, it MUSTS tunnels these
   packets to its HA.

   Outer IP header MUST be constructed as follows whenever the MR
   tunnels packets.

    -  The source IP address of the outer IP header MUST be the MR-CoA

    -  The destination IP address of the outer IP header MUST be the HA
       address.


5.1.2. Receiving Packets from HA

   While away from home, MR will receive packets from correspondent
   nodes tunneled via HA. Whenever the MR receives tunneled packets
   destined to its mobile network prefix from the HA, the MR MUST check
   the following sequences.

    -  The destination address of the outer IP header MUST be MR-CoA.

    -  The source address of the outer IP header MUST be the address of
       the HA currently registering MR's binding.

   If tunneled packets do not satisfy above conditions, the MR
   SHOULD NOT route these packets to the final destination (i.e.  The
   destination node of inner IPv6 packets (MNN)).


5.1.3. MR acting as an end-node

   If MR needs to communicate with a correspondent node with its MR-A,
   it MUST send packets through bidirectional tunneling via HA described
   in section 5.1.1.

   Instead, if the destination of MR's packet is the MR's current
   registering HA, MR SHOULD follow general Mobile IPv6 operation except
   for the operations of ``returning home'' and ``Route Optimization''.
   Packets from the MR SHOULD be carried with a home address option
   set to the MR-A. Packets to the MR SHOULD be routed by a routing
   header type 2 set to the MR-CoA. The HA MUST verify the MR-A with
   registereing bindings.  If the HA can not find the binding for the


R. Wakikawa et.al.              Expires 18 Aug 2003             [Page 9]

Internet Draft               Basic NEMO Support              18 Feb 2003


   MR-A, it MUST discard these packets and SHOULD send Binding Error
   described in the Mobile IPv6 specification.

   The MR SHOULD also accept tunneled packets originally destined to
   MR-A from the HA, and the HA SHOULD also accept tunneled packets
   originally destined to the HA from the MR-A.

   Operation of ''returning home'' is described in the section 5.3.  MR
   MUST NOT start return routability operation for route optimization.
   All the packets MUST be tunneled thorough HA (i.e.  redirectional
   tunneling).


5.2. Binding Processing

5.2.1. Sending Binding Updates

   If prefix length is available in the binding update list, MR MUST
   send BU with a prefix sub-option.  The operation of sending BUs to HA
   is same as Mobile IPv6 except for following procedure.

    -  'N' bit MUST be set in BU

    -  'L' bit MUST NOT be set in BU

    -  'H' bit MUST be set in BU if the BU is for home registration.

    -  A prefix sub-option MUST be contained in the BU. In the prefix
       sub-option, MR MUST set the length of its mobile network prefix.

   MR MUST NOT send BU which do not match the above procedure.


5.2.2. Receiving Binding Acknowledgments

   BA MUST be protected by IPsec transport mode.  If the BA is not
   protected by appropriate IPsec, MR MUST silently discard the BA.
   Other procedures to verify BA is described in [11]

   In the Mobile IPv6 specification, if the status field is less than
   '128', it indicates successful registration of its binding.  On the
   other hand, this draft requires status value either '2' or '3' for
   successful registration.  MR MUST establish a tunnel with HA after
   successful registration and starts tunneling packets from the mobile
   network.  If the value is not '2' and '3', the MR SHOULD retry to
   send BU for its mobile network prefix or MAY stop sending BU.

   If the status field is '3', the MR is back to HA link.  The MR should
   follow the operation described in section 5.3.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 10]

Internet Draft               Basic NEMO Support              18 Feb 2003


   If the status field indicates that the BU was rejected, the MR SHOULD
   NOT send BUs to this destination.


5.3. Returning to HA link


          CN  CN  CN  CN  CN  CN
        ___|__|___|___|___|___|___
          |
       ___|_____________________
      |                        |
      |    Internet            |
      |________________________|
         __|_           __|__ <-- HA Address 3ffe:306:1130::eui64
        |    |         |     | Prefix Binding
        | AR |         | HA  |  MR-A/64<->MR-CoA*
        |____|         |_____|  (*MR-CoA is on-link address for HA)
           |     _________|______ HA Link (3ffe:306:1130:1::/64)
                     |
                     |
                   __|<-- MR-CoA 3ffe:306:1130:1::mr_eui64
                  |    |
                  | MR | Mobile Network Prefix 3ffe:306:1130:200::/64
                  |____|
                    |<-- MR-A   3ffe:306:1130:200::mr_eui64
               _____|_________
                |         |
              __|__     __|__
             |     |   |     |
             | MNN |   | MNN |
             |_____|   |_____| 3ffe:306:1130:200::eui64


            Figure 2: Mobile Network attached to the HA link


   When MR returns to the link of its HA, the MR will obtain MR-CoA from
   HA's router advertisement messages.  The MR-CoA is different from the
   mobile network prefix.  Therefore, the MR MUST send BU like any other
   foreign link.  This is because the HA needs to know the exact HA link
   where the MR has attached to.  The MR detects the returning to HA
   link by receiving BA with the status code '3' from the HA.

   On the HA link, MR becomes on-link with the HA. Therefore the MR
   SHOULD route packets directly to the HA. The MR MAY receive packets
   directly route from the HA without any IP-in-IP encapsulation.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 11]

Internet Draft               Basic NEMO Support              18 Feb 2003


   The MR MUST accept these packets and route them correctly to a
   destination of packets.  The MR SHOULD route packets from MNN to the
   HA without encapsulation.


5.4. Types of Tunneled Packets to HA

   MR MUST determine whether packets should be tunneled to HA or not,
   according to the following ruleset.

    -  Global Scoped Packets sent by MNN
       If packets are sent by MNN with global scope and are addressed to
       hosts out of mobile network, MR MUST tunnel these packets to HA.

    -  Link Local Scoped Packets in a mobile network
       MR MUST NOT tunnel any link-local scoped packets inside mobile
       network such as Neighbor Discovery Protocol (NDP) [16] packets
       and packets destined to all node multicast address.

    -  Site Local Scoped Packets in a mobile network
       This draft currently does not consider site local scoped packets.
       Therefore, MR MUST NOT tunnel these packets and MUST route them
       only inside its mobile network.

    -  Routing Messages of Mobile Network Prefix
       MR MAY tunnel any routing messages of its mobile network prefix.

    -  Multicast Routing Message
       MR MUST tunnel all control messages of multicast routing
       protocols [9] [17] to HA.

    -  Multicast Packets
       MR MUST tunnel multicast routing packets destined to a multicast
       address with global scope as described in section 8

   If MR received tunneled packets which does not satisfy the ruleset
   described in section 6.3, it MUST silently discard these packets.


6. Home Agent Operation

6.1. Processing Bindings

6.1.1. Receiving Binding Updates

   BU MUST be protected by IPsec transport mode described in the
   section 7.  Otherwise, HA MUST silently discard the BU.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 12]

Internet Draft               Basic NEMO Support              18 Feb 2003


   Verification of BU is the same as Mobile IPv6 except for following
   procedure.

    -  If `N' bit is set in BU, Prefix sub-option MUST be present in the
       option field.  Otherwise, the HA MUST discard the BU and return
       BA with status code set to '140' (Invalid Prefix Length).

    -  If 'N' bit is set and 'L' bit is also set in BU, the HA MUST
       discard the BU and returns BA with status code set to '129'
       (Administratively prohibited).

    -  If the ``Prefix Length'' of the prefix sub-option is equal to
       '128', the HA MUST discard the BU and returns BA with status code
       set to '140' (Invalid Prefix Length).

    -  If the ``Prefix Length'' of the prefix sub-option is greater than
       '128', the HA MUST discard the BU and returns BA with status code
       set to '140' (Invalid Prefix Length).

    -  If 'N' bit is set and 'H' bit is also set in BU, the HA MUST
       register the prefix binding as home registration and MUST return
       BA with status code set to '2'.

    -  If the prefix binding is successfully registered and MR-CoA is
       generated by one of the HA's managed prefix, the HA MUST return
       BA with status code set to '3' to indicate returning the HA link.

   If HA successfully processes BU and registers a prefix binding for
   the requesting MR, the HA MUST establish a tunnel with the MR. After
   the registration, the HA MUST intercept packets destined to the
   mobile network and MUST forward these packets to the MR by IP-in-IP
   encapsulation.  Since the HA is identified as a gateway of the mobile
   network prefix in the Internet topology, the HA receives these
   packets routed to itself.


6.1.2. Sending Binding Acknowledgments

   Operation procedure of sending BA is same as the Mobile IPv6
   specification except for following.  MR-A is treated as a home
   address.

   IF the status code is '140', HA MUST NOT use a prefix binding for the
   destination address of BA and MUST NOT use a routing header type 2
   for BA.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 13]

Internet Draft               Basic NEMO Support              18 Feb 2003


6.2. Packet Processing

6.2.1. Sending Packets to MR

   While MR is away from HA link, HA intercepts packets destined to
   the registered mobile network prefix.  It MUST route packets to the
   registered MR. Thus, the HA tunnels packets to registered MR-CoA by
   IP-in-IP encapsulation.

   Outer IP header MUST be constructed as follows whenever the HA
   tunnels packets to the MR.

    -  The source IP address of the outer IP header MUST be the HA
       address.

    -  The destination IP address of the outer IP header MUST be the
       MR-CoA registered in the prefix binding.

   If packets do not satisfy above conditions, the MR SHOULD NOT route
   tunneled packets to the final destination (i.e.  destination node of
   inner IPv6 packets).

   When MR is attached to a HA link, on the other hand, the HA
   SHOULD route packets to the mobile network according to general
   IP routing.  The HA MAY NOT have exact routing entries for the
   mobile network prefix, but it knows the next-hop address of the
   mobile network prefix from the registered prefix binding.  If the
   MR-CoA is configured by one of the HA's prefix, the MR-CoA becomes
   on-link at HA link.  The HA should route packets to the next-hop
   address (MR-CoA) of the registered prefix binding.


6.2.2. Receiving Packets from MR

   While MR is away from HA link, HA receives packets tunneled to the HA
   from the MR. Whenever the HA receives tunneled packets from the MR,
   the HA MUST perform following common sequence.

    -  The destination address of the outer IP header MUST be the HA
       address.

    -  The source address of the outer IP header MUST be the MR-CoA
       which is registered in the prefix binding.

   If packets do not satisfy above conditions, the HA SHOULD NOT route
   tunneled packets to the final destination (i.e.  destination node of
   inner IPv6 packets).


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 14]

Internet Draft               Basic NEMO Support              18 Feb 2003


   If the MR is located at the HA link, it will route packets without
   IP-in-IP encapsulation.  The HA MUST verify MR's availability at its
   HA link.  The HA compares the MR-CoA with HA's managing prefixes.  If
   the MR-CoA is active at one of the HA link, the HA MUST route packets
   to the destination of packets.  Otherwise, the HA MUST silently
   discard these packets.  These packets may not be originated from the
   mobile network, because the owner of the mobile network prefix (MR)
   is not located at the HA link.


6.3. Types of Tunneled Packets to MR

   HA MUST determine whether packets are tunneled to MR or not,
   according to the following ruleset.

    -  Global Scoped Packets destined to a mobile network
       If HA received packets destined to a mobile network prefix, the
       HA MUST tunnel this packet to the MR.

    -  Routing Messages
       HA MAY tunnel any routing information obtained by routing
       protocols.  While away from HA link, MR MUST NOT accept any
       routing messages tunneled by the HA. Also, the MR SHOULD NOT
       accept any routing messages to update its routing table except
       for default routes at a visiting link.

    -  Multicast Routing Message
       HA MUST tunnel all control messages of multicast routing
       protocols [9] [17] to MR.

    -  Multicast Packets
       HA MUST tunnel multicast packets destined to multicast listers in
       mobile network according to multicast routing table.

   If HA received tunneled packets which do not satisfy the ruleset of
   tunneled packets described in section 5.4, it MUST silently discard
   these packets.


7. Security Overview

   BU and Binding Acknowledgment (BA) are protected by IPsec transport
   mode [12] [13] like Mobile IPv6 [1].  Since this draft uses MR-A as
   a home address of MR, BU MUST be protected by using MR-A. MR-A is
   generated by a mobile network prefix, thus HA can authenticate MR and
   also authorize the mobile network prefix by IPsec transport mode.
   The establishment of Security Association (SA) by MR-A prevents
   a malicious MR to send BUs for other MR's mobile network prefix


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 15]

Internet Draft               Basic NEMO Support              18 Feb 2003


   to the specified HA. MR is RECOMMENDED to use ESP mode to give
   confidentiality to BU by encryption of BU.

   IPsec tunnel operation for HoTI and HoT is not needed in this draft,
   because route optimization is out of scope in Basic NEMO Support.
   IKE [10] is currently not supported.

   Following example can be applied to set up Security Association
   between MR and HA. The format of description is defined in section
   4.1 of [1].

   Security Association on MR is set up manually as follows:

       MR SPD OUT:

            - IF source = MR-A & destination = HA & proto = MH
              THEN USE SA1

       MR SPD IN:

            - IF source = HA & destination = MR-A & proto = MH
              THEN USE SA2

       MR SAD:

            - SA1(OUT, spi_a, HA, ESP, TRANSPORT):
              source = MR-A & destination = HA & proto = MH

            - SA2(IN, spi_b, MR-A, ESP, TRANSPORT):
              source = HA & destination = MR-A & proto = MH

   HA MUST NOT set up Security Association for MR before delegating a
   mobile network prefix to the MR. Security Association on HA is set up
   manually as follows:

       HA SPD OUT:

            - IF source = HA & destination = MR-A & proto = MH
              THEN USE SA2

       HA SPD IN:

            - IF source = MR-A & destination = HA & proto = MH
              THEN USE SA1

       MR SAD:

            - SA2(IN, spi_b, MR-A, ESP, TRANSPORT):
              source = HA & destination = MR-A & proto = MH


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 16]

Internet Draft               Basic NEMO Support              18 Feb 2003


            - SA1(OUT, spi_a, HA, ESP, TRANSPORT):
              source = MR-A & destination = HA & proto = MH

   To replace home address with MR-A, steps of processing IPsec
   calculation is same as section 5.1, 5.2, 5.3, 5.4 of [1].


8. Multicast Support

   If a mobile network needs to support multicast, MR SHOULD be capable
   of operating Multicast Listener Discovery (MLD) [5].  The MR SHOULD
   know which multicast groups MNNs are currently joining.  Also, the
   MR MUST tunnel packets destined to a multicast address via HA. The
   MR MUST run a multicast routing protocol, because the MR needs to
   route multicast packets to the upper multicast router which is the
   HA. Thus, the HA MUST run a multicast routing protocol in order
   to exchange multicast routing information from MR. HA SHOULD also
   be capable of routing multicast packets.  The HA routes multicast
   routing messages from MR and tunnels appropriate multicast packets to
   MR if there are multicast listers in mobile network.

   If MR supports multicast, it MUST determine which multicast data
   packets to forward via the tunnel between HA. The MR operates this
   depending on address scope as follows.

    -  If multicast packet is addressed to a multicast address with
       link-local scope, the MR MUST NOT tunnel them to the HA and MUST
       silently discard them.

    -  If multicast packet is addressed to a multicast address with
       site-local scope, the MR SHOULD NOT tunnel them to the HA and
       MUST silently discard them.

    -  If multicast packet is destined to a multicast address with
       global scope, the MU MUST tunnel them to the HA.

   If the MR receives tunneled multicast packets from the HA, it MUST
   route this multicast packets to listers of this multicast group in
   the mobile network.


9. Mobile IPv6 Compatibility

   This protocol is fully compatible with Mobile IPv6 without any
   modifications.

   MR sends BU only to HA, and MUST NOT send BU to other nodes.  Even if
   Mobile IPv6 CN receives BU from MR, it MUST silently discard the BU.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 17]

Internet Draft               Basic NEMO Support              18 Feb 2003


10. Nested Mobility

10.1. Visiting MN Attached to Mobile Network

   When Visiting MN (VMN) attaches to a mobile network, it obtains a
   CoA from MR's router advertisements.  This address can be used as
   the general CoA defined in [11].  The VMN sends BU to its HA to
   register the CoA. Any additional operation is not needed to the
   VMN. Incoming packets from CN and outgoing packets from the VMN are
   tunneled between the MR and the MR's HA despite the Mobile IPv6 route
   optimization.

   Return Routability procedure can be used in this draft without any
   modifications.  The VMN sends HoT and receives HoT via its HA though
   the bi-directional tunnel to the MR's HA. The VMN also sends CoTI
   and receives CoT thorough the bi-directional tunnel.  Then, the VMN
   sends BU with Binding Authorization Data sub-option thorough the
   bi-directional tunnel.

   Outgoing packets to CN are route optimized by home address option,
   but is tunneled to the MR's HA first.  Incoming packets are tunneled
   via the MR's and are routed to the VMN by routing header type 2
   option.  Packets bypass the VMN's HA in each direction.


10.2. MR Attached to Mobile Network

   When MR attaches to another mobile network, it obtains a MR-CoA named
   after the mobile network prefix.  This address can be used as the
   general MR-CoA. The MR sends BU to its HA to register the MR-CoA.
   Any additional operation is not needed to the MR. Incoming packets
   to sub-NEMO can be routed to the sub-MR's MR-CoA by double tunneling
   both via parent-MR's HA and via sub-MR's HA. Outgoing packets from
   sub-NEMO are routed to a destination by bidirectional tunneling both
   via sub-MR's HA and via parent-MR's HA.

   The operation does not differ if there are more nested levels.


Acknowledgments

   The authors would like to thank Masafumi Watari, Susumu Koshiba and
   InternetCAR group at KEIO University for their comments.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 18]

Internet Draft               Basic NEMO Support              18 Feb 2003


A. Specification Comparison with WG requirements

   This section lists the possible issues compared to WG requirements.
   This protocol meets the requirements which are not listed in this
   section.  These requirements are proposed in NEMO WG [6].

  R12: ``The solution MUST function for multi-homed mobile networks.
       More precisely:''

       R12.1: ``The solution MUST support mobile networks with multiple
              MRs,''

       R12.2: ``The solution MUST support MR with multiple interfaces,''

       R12.3: ``The solution must support MR with multiple global
              addresses on an egress interface.''

       R12.2 and R12.3 is achieved by the same operation of Mobile IPv6.
       See section 11.5.3 of the Mobile IPv6 specification.

       R12.3 is not discussed in detail in this draft now.  we need more
       consideration.

  R15: ``The solution MUST ensure transparent continuation of routing
       and management operations over the bi-directional tunnel when the
       MR is away from home.  (this includes e.g.  routing protocols,
       router renumbering, DHCPv6, etc)''


       The solution meets the requirement of transparent continuation
       of routing, but router renumbering and DHCPv6 need more
       consideration.


References

    [1] J. Arkko, V. Devarapalli, and F. Dupont.  Using IPsec to Protect
        Mobile IPv6 Signaling between Mobile Nodes and Home Agents
        (draft-ietf-mobileip-mipv6-ha-ipsec-02).  Internet Draft,
        Internet Engineering Task Force, January 2003.

    [2] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [3] R. Coltun, D. Ferguson, and J. Moy.  OSPF for IPv6.  Request for
        Comments (Proposed Standard) 2740, Internet Engineering Task
        Force, December 1999.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 19]

Internet Draft               Basic NEMO Support              18 Feb 2003


    [4] A. Conta and S. Deering.  Generic Packet Tunneling in IPv6
        Specification.  Request for Comments (Proposed Standard) 2473,
        Internet Engineering Task Force, December 1998.

    [5] S. Deering, W. Fenner, and B. Haberman.  Multicast Listener
        Discovery (MLD) for IPv6.  Request for Comments (Proposed
        Standard) 2710, Internet Engineering Task Force, October 1999.

    [6] T. Ernst.  Network Mobility Support Requirements
        (draft-ietf-nemo-requirements-00).  Internet Draft,
        Internet Engineering Task Force, February 2003.

    [7] T. Ernst and et al.  Mobile Networks Support in Mobile IPv6
        (draft-ernst-mobileip-v6-network-03).  Internet Draft, Internet
        Engineering Task Force, March 2002.

    [8] T. Ernst and et al.  Network Mobility Support Terminology
        (draft-ernst-monet-terminology-01).  Internet Draft, Internet
        Engineering Task Force, November 2002.

    [9] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
        M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei.
        Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        specification.  Request for Comments (Experimental) 2362,
        Internet Engineering Task Force, June 1998.

   [10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE).
        Request for Comments (Proposed Standard) 2409, Internet
        Engineering Task Force, November 1998.

   [11] D. Johnson, C. Perkins, and J. Arkko.  Mobility support in
        IPv6 (draft-ietf-mobileip-ipv6-20).  Internet Draft, Internet
        Engineering Task Force, January 2003.

   [12] S. Kent and R. Atkinson.  IP Authentication Header.  Request for
        Comments (Proposed Standard) 2402, Internet Engineering Task
        Force, November 1998.

   [13] S. Kent and R. Atkinson.  IP Encapsulating Security Payload
        (ESP).  Request for Comments (Proposed Standard) 2406, Internet
        Engineering Task Force, November 1998.

   [14] K. Lougheed and Y. Rekhter.  Border Gateway Protocol (BGP).
        Request for Comments (Experimental) 1105, Internet Engineering
        Task Force, June 1989.

   [15] G. Malkin and R. Minnear.  RIPng for IPv6.  Request for Comments
        (Proposed Standard) 2080, Internet Engineering Task Force,
        January 1997.


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 20]

Internet Draft               Basic NEMO Support              18 Feb 2003


   [16] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP Version 6 (ipv6).  Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.

   [17] D. Waitzman, C. Partridge, and S. E. Deering.  Distance Vector
        Multicast Routing Protocol.  Request for Comments (Experimental)
        1075, Internet Engineering Task Force, November 1988.

   [18] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and
        A. Tuominen.  Global Connectivity for IPv6 Mobile Ad Hoc
        Networks (draft-wakikawa-manet-globalv6-02).  Internet Draft,
        Internet Engineering Task Force, November 2002.


Authors' Addresses


        Ryuji Wakikawa               Koshiro Mitsuya
        Keio University and WIDE     Keio University and WIDE
        5322 Endo Fujisawa Kanagawa  5322 Endo Fujisawa Kanagawa
        252-8520 JAPAN               252-8520 JAPAN
        Phone:  +81-466-49-1394      Phone:  +81-466-49-1394
        Fax:  +81-466-49-1395        Fax:  +81-466-49-1395
        EMail:  ryuji@sfc.wide.ad.jp EMail:  mitsuya@sfc.wide.ad.jp

        Keisuke Uehara               Thierry Ernst
        KEIO University and WIDE     Keio University and WIDE
        5322 Endo Fujisawa Kanagawa  5322 Endo Fujisawa Kanagawa
        252-8520 JAPAN               252-8520 JAPAN
        Phone:  +81-466-49-1394      Phone:  +81-466-49-1394
        Fax:  +81-466-49-1395        Fax:  +81-466-49-1395
        EMail:  kei@wide.ad.jp       EMail:  ernst@sfc.wide.ad.jp


R. Wakikawa et.al.             Expires 18 Aug 2003             [Page 21]