<pre>Network Working Group                                     V. Devarapalli
Request for Comments: 3963                                         Nokia
Category: Standards Track                                    R. Wakikawa
                                                         Keio University
                                                             A. Petrescu
                                                                Motorola
                                                              P. Thubert
                                                           Cisco Systems
                                                            January 2005


             <span class="h1">Network Mobility (NEMO) Basic Support Protocol</span>

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the Network Mobility (NEMO) Basic Support
   protocol that enables Mobile Networks to attach to different points
   in the Internet.  The protocol is an extension of Mobile IPv6 and
   allows session continuity for every node in the Mobile Network as the
   network moves.  It also allows every node in the Mobile Network to be
   reachable while moving around.  The Mobile Router, which connects the
   network to the Internet, runs the NEMO Basic Support protocol with
   its Home Agent.  The protocol is designed so that network mobility is
   transparent to the nodes inside the Mobile Network.















<span class="grey">Devarapalli, et al.         Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .    <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . .    <a href="#page-4">4</a>
   <a href="#section-3">3</a>.  Overview of the NEMO Protocol. . . . . . . . . . . . . . . .    <a href="#page-4">4</a>
   <a href="#section-4">4</a>.  Message Formats. . . . . . . . . . . . . . . . . . . . . . .    <a href="#page-7">7</a>
       <a href="#section-4.1">4.1</a>. Binding Update. . . . . . . . . . . . . . . . . . . . .    <a href="#page-7">7</a>
       <a href="#section-4.2">4.2</a>. Binding Acknowledgement . . . . . . . . . . . . . . . .    <a href="#page-7">7</a>
       <a href="#section-4.3">4.3</a>. Mobile Network Prefix Option. . . . . . . . . . . . . .    <a href="#page-8">8</a>
   <a href="#section-5">5</a>.  Mobile Router Operation. . . . . . . . . . . . . . . . . . .    <a href="#page-9">9</a>
       <a href="#section-5.1">5.1</a>. Data Structures . . . . . . . . . . . . . . . . . . . .   <a href="#page-10">10</a>
       <a href="#section-5.2">5.2</a>. Sending Binding Updates . . . . . . . . . . . . . . . .   <a href="#page-10">10</a>
       <a href="#section-5.3">5.3</a>. Receiving Binding Acknowledgements. . . . . . . . . . .   <a href="#page-11">11</a>
       <a href="#section-5.4">5.4</a>. Error Processing  . . . . . . . . . . . . . . . . . . .   <a href="#page-12">12</a>
            <a href="#section-5.4.1">5.4.1</a>. Implicit Mode. . . . . . . . . . . . . . . . . .   <a href="#page-12">12</a>
            <a href="#section-5.4.2">5.4.2</a>. Explicit Mode. . . . . . . . . . . . . . . . . .   <a href="#page-12">12</a>
       <a href="#section-5.5">5.5</a>. Establishment of Bi-directional Tunnel  . . . . . . . .   <a href="#page-13">13</a>
       <a href="#section-5.6">5.6</a>. Neighbor Discovery for Mobile Router  . . . . . . . . .   <a href="#page-13">13</a>
       <a href="#section-5.7">5.7</a>. Multicast Groups for Mobile Router  . . . . . . . . . .   <a href="#page-14">14</a>
       <a href="#section-5.8">5.8</a>. Returning Home  . . . . . . . . . . . . . . . . . . . .   <a href="#page-14">14</a>
   <a href="#section-6">6</a>.  Home Agent Operation . . . . . . . . . . . . . . . . . . . .   <a href="#page-15">15</a>
       <a href="#section-6.1">6.1</a>. Data Structures . . . . . . . . . . . . . . . . . . . .   <a href="#page-15">15</a>
            <a href="#section-6.1.1">6.1.1</a>. Binding Cache. . . . . . . . . . . . . . . . . .   <a href="#page-15">15</a>
            <a href="#section-6.1.2">6.1.2</a>. Prefix Table . . . . . . . . . . . . . . . . . .   <a href="#page-15">15</a>
       <a href="#section-6.2">6.2</a>. Mobile Network Prefix Registration  . . . . . . . . . .   <a href="#page-16">16</a>
       <a href="#section-6.3">6.3</a>. Advertising Mobile Network Reachability . . . . . . . .   <a href="#page-17">17</a>
       <a href="#section-6.4">6.4</a>. Establishment of Bi-directional Tunnel  . . . . . . . .   <a href="#page-18">18</a>
       <a href="#section-6.5">6.5</a>. Forwarding Packets  . . . . . . . . . . . . . . . . . .   <a href="#page-18">18</a>
       <a href="#section-6.6">6.6</a>. Sending Binding Acknowledgements  . . . . . . . . . . .   <a href="#page-19">19</a>
       <a href="#section-6.7">6.7</a>. Mobile Network Prefix De-Registration . . . . . . . . .   <a href="#page-19">19</a>
   <a href="#section-7">7</a>.  Modifications to Dynamic Home Agent Address Discovery. . . .   <a href="#page-20">20</a>
       <a href="#section-7.1">7.1</a>. Modified Dynamic Home Agent Discovery Request . . . . .   <a href="#page-20">20</a>
       7.2. Modified Dynamic Home Agent Discovery Address Request .   20
       <a href="#section-7.3">7.3</a>. Modified Home Agent Information Option  . . . . . . . .   <a href="#page-21">21</a>
   <a href="#section-8">8</a>.  Support for Dynamic Routing Protocols. . . . . . . . . . . .   <a href="#page-22">22</a>
   <a href="#section-9">9</a>.  Security Considerations. . . . . . . . . . . . . . . . . . .   <a href="#page-23">23</a>
   <a href="#section-10">10</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . .   <a href="#page-24">24</a>
   <a href="#section-11">11</a>. Contributors . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-25">25</a>
   <a href="#section-12">12</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-25">25</a>
   <a href="#section-13">13</a>. References . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-25">25</a>
   Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-27">27</a>
       <a href="#appendix-A">A</a>. Examples of NEMO Basic Support Operation. . . . . . . . .   <a href="#page-27">27</a>
       B. Running Link State Routing Protocol with NEMO Basic
          Support . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-30">30</a>
          <a href="#appendix-B.1">B.1</a>. Tunnel Interface Considerations. . . . . . . . . . .   <a href="#page-30">30</a>
          <a href="#appendix-B.2">B.2</a>. OSPF Area Considerations . . . . . . . . . . . . . .   <a href="#page-30">30</a>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-32">32</a>
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .   <a href="#page-33">33</a>



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes protocol extensions to Mobile IPv6 (MIPv6)
   [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>] to enable support for network mobility.  The extensions are
   backward compatible with Mobile IPv6.  In particular, a NEMO-
   compliant Home Agent can operate as a Mobile IPv6 Home Agent.  The
   solution described here satisfies the goals and requirements
   identified in [<a href="#ref-11" title="&quot;Network Mobility Support Goals and Requirements&quot;">11</a>] for network mobility.

   The NEMO Basic Support ensures session continuity for all the nodes
   in the Mobile Network, even as the Mobile Router changes its point of
   attachment to the Internet.  It also provides connectivity and
   reachability for all nodes in the Mobile Network as it moves.  The
   solution supports both mobile nodes and hosts that do not support
   mobility in the Mobile Network.

   Within the context of this document, the definition of a Mobile
   Router extends that of a Mobile IPv6 [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>] Mobile Node, by adding
   routing capability routing between its point of attachment (Care-of
   Address) and a subnet that moves with the Mobile Router.

   The solution described in this document proposes a bi-directional
   tunnel between the Mobile Router and its Home Agent.  This tunnel is
   set up when the Mobile Router sends a successful Binding Update to
   its Home Agent, informing the Home Agent of its current point of
   attachment.

   All traffic between the nodes in the Mobile Network and Correspondent
   Nodes passes through the Home Agent.  This document does not describe
   route optimization of this traffic.

   The terminology document [<a href="#ref-10" title="&quot;Network Mobility Support Terminology&quot;">10</a>] describes Nested Mobility as a scenario
   where a Mobile Router allows another Mobile Router to attach to its
   Mobile Network.  There could be arbitrary levels of nested mobility.
   The operation of each Mobile Router remains the same whether the
   Mobile Router attaches to another Mobile Router or to a fixed Access
   Router on the Internet.  The solution described here does not place
   any restriction on the number of levels for nested mobility.  But
   note that this might introduce significant overhead on the data
   packets as each level of nesting introduces another IPv6 header
   encapsulation.

   This document does not discuss multihoming for Mobile Routers.








<span class="grey">Devarapalli, et al.         Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-7" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">7</a>].

   Network Mobility - related terminology is defined in [<a href="#ref-9" title="&quot;Mobility Related Terminology&quot;">9</a>] and [<a href="#ref-10" title="&quot;Network Mobility Support Terminology&quot;">10</a>].
   This document in addition defines the following terms.

      Mobile Network Prefix

         An IPv6 prefix delegated to a Mobile Router and advertised in
         the Mobile Network.  More than one Mobile Network Prefix could
         be advertised in a Mobile Network.

      Prefix Table

         A list of Mobile Network Prefixes indexed by the Home Address
         of a Mobile Router.  The Home Agent manages and uses Prefix
         Table to determine which Mobile Network Prefixes belong to a
         particular Mobile Router.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Overview of the NEMO Protocol</span>

   A Mobile Network is a network segment or subnet that can move and
   attach to arbitrary points in the routing infrastructure.  A Mobile
   Network can only be accessed via specific gateways called Mobile
   Routers that manage its movement.  Mobile Networks have at least one
   Mobile Router serving them.  A Mobile Router does not distribute the
   Mobile Network routes to the infrastructure at its point of
   attachment (i.e., in the visited network).  Instead, it maintains a
   bi-directional tunnel to a Home Agent that advertises an aggregation
   of Mobile Networks to the infrastructure.  The Mobile Router is also
   the default gateway for the Mobile Network.

   A Mobile Network can also comprise of multiple and nested subnets.  A
   router without mobility support may be permanently attached to a
   Mobile Network for local distribution.  Also, Mobile Routers may be
   attached to Mobile Networks owned by different Mobile Routers and may
   form a graph.  In particular, with Basic NEMO Support, each Mobile
   Router is attached to another Mobile Network by a single interface.
   If loops are avoided, the graph is a tree.

   A Mobile Router has a unique Home Address through which it is
   reachable when it is registered with its Home Agent.  The Home
   Address is configured from a prefix aggregated and advertised by its
   Home Agent.  The prefix could be either the prefix advertised on the
   home link or the prefix delegated to the Mobile Router.  The Mobile



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   Router can have more than one Home Address if there are multiple
   prefixes in the home link.  The Mobile Router also advertises one or
   more prefixes in the Mobile Network attached to it.  The actual
   mechanism for assigning these prefixes to a given Mobile Router is
   outside the scope of this specification.

   When the Mobile Router moves away from the home link and attaches to
   a new access router, it acquires a Care-of Address from the visited
   link.  The Mobile Router can at any time act either as a Mobile Host
   or as a Mobile Router.  It acts as a Mobile Host as defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>]
   for sessions it originates and provides connectivity to the Mobile
   Network.  As soon as the Mobile Router acquires a Care-of Address, it
   immediately sends a Binding Update to its Home Agent as described in
   [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  When the Home Agent receives this Binding Update, it creates a
   cache entry binding the Mobile Router's Home Address to its Care-of
   Address at the current point of attachment.

   If the Mobile Router seeks to act as a Mobile Router and provide
   connectivity to nodes in the Mobile Network, it indicates this to the
   Home Agent by setting a flag (R) in the Binding Update.  It MAY also
   include information about the Mobile Network Prefix in the Binding
   Update by using one of the modes described in <a href="#section-5.2">section 5.2</a>, so that
   the Home Agent can forward packets meant for nodes in the Mobile
   Network to the Mobile Router.  A new Mobility Header Option for
   carrying prefix information is described in <a href="#section-4.3">section 4.3</a>.  If the
   Mobile Network has more than one IPv6 prefix and wants the Home Agent
   to setup forwarding for all of these prefixes, it includes multiple
   prefix information options in a single Binding Update.  The Home
   Agent sets up forwarding for each of these prefixes to the Mobile
   Router's Care-of Address.  In some scenarios the Home Agent would
   already know which prefixes belong to a Mobile Router by an alternate
   mechanism such as static configuration.  In these scenarios, the
   Mobile Router does not include any prefix information in the Binding
   Update.  The Home Agent sets up forwarding for all prefixes owned by
   the Mobile Router when it receives a Binding Update from the Mobile
   Router with the Mobile Router Flag (R) set.

   The Home Agent acknowledges the Binding Update by sending a Binding
   Acknowledgement to the Mobile Router.  A positive acknowledgement
   with the Mobile Router Flag (R) set means that the Home Agent has set
   up forwarding for the Mobile Network.  Once the binding process
   finishes, a bi-directional tunnel is established between the Home
   Agent and the Mobile Router.  The tunnel end points are the Mobile
   Router's Care-of Address and the Home Agent's address.  If a packet
   with a source address belonging to the Mobile Network Prefix is
   received from the Mobile Network, the Mobile Router reverse-tunnels
   the packet to the Home Agent through this tunnel.  This reverse-
   tunneling is done by using IP-in-IP encapsulation [<a href="#ref-3" title="&quot;Generic Packet Tunneling in IPv6 Specification&quot;">3</a>].  The Home



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   Agent decapsulates this packet and forwards it to the Correspondent
   Node.  For traffic originated by itself, the Mobile Router can use
   either reverse tunneling or route optimization, as specified in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   When a Correspondent Node sends a data packet to a node in the Mobile
   Network, the packet is routed to the Home Agent that currently has
   the binding for the Mobile Router.  The Mobile Router's network
   prefix would be aggregated at the Home Agent, which would advertise
   the resulting aggregation.  Alternatively, the Home Agent may receive
   the data packets destined to the Mobile Network by advertising routes
   to the Mobile Network Prefix.  The actual mechanism by which these
   routes are advertised is outside the scope of this document.  When
   the Home Agent receives a data packet meant for a node in the Mobile
   Network, it tunnels the packet to the Mobile Router's current Care-of
   Address.  The Mobile Router decapsulates the packet and forwards it
   onto the interface where the Mobile Network is connected.  Before
   decapsulating the tunneled packet, the Mobile Router has to check
   whether the Source address on the outer IPv6 header is the Home
   Agent's address.  This check is not necessary if the packet is
   protected by IPsec in tunnel mode.  The Mobile Router also has to
   make sure that the destination address on the inner IPv6 header
   belongs to a prefix used in the Mobile Network before forwarding the
   packet to the Mobile Network.  If it does not, the Mobile Router
   should drop the packet.

   The Mobile Network could include nodes that do not support mobility
   and nodes that do.  A node in the Mobile Network can also be a fixed
   or a Mobile Router.  The protocol described here ensures complete
   transparency of network mobility to the nodes in the Mobile Network.
   Mobile Nodes that attach to the Mobile Network treat it as a normal
   IPv6 access network and run the Mobile IPv6 protocol.

   The Mobile Router and the Home Agent can run a routing protocol
   through the bi-directional tunnel.  In this case, the Mobile Router
   need not include prefix information in the Binding Update.  Instead,
   the Home Agent uses the routing protocol updates to set up forwarding
   for the Mobile Network.  When the routing protocol is running, the
   bi-directional tunnel must be treated as a tunnel interface.  The
   tunnel interface is included in the list of interfaces on which
   routing protocol is active.  The Mobile Router should be configured
   not to send any routing protocol messages on its egress interface
   when it is away from the home link and connected to a visited link.

   Finally, the Home Agent may be configured with static routes to the
   Mobile Network Prefix via the Mobile Router's Home Address.  In this
   case, the routes are set independently of the binding flows and the
   returning home of a Mobile Router.  The benefit is that such movement
   does not induce additional signalling in the form of routing updates



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   in the home network.  The drawback is that the routes are present
   even if the related Mobile Routers are not reachable (at home or
   bound) at a given point of time.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Message Formats</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Binding Update</span>

   A new flag (R) is included in the Binding Update to indicate to the
   Home Agent whether the Binding Update is coming from a Mobile Router
   and not from a mobile node.  The rest of the Binding Update format
   remains the same as defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |          Sequence #           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|L|K|M|R|      Reserved     |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Flag (R)

         The Mobile Router Flag is set to indicate to the Home Agent
         that the Binding Update is from a Mobile Router.  If the flag
         is set to 0, the Home Agent assumes that the Mobile Router is
         behaving as a Mobile Node, and it MUST NOT forward packets
         destined for the Mobile Network to the Mobile Router.

      Mobility Options

         A variable length field that can include zero or more mobility
         options.  This document defines a new mobility option in
         addition to what is defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   For descriptions of the other fields in the message, see [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Binding Acknowledgement</span>

   A new flag (R) is included in the Binding Acknowledgement to indicate
   that the Home Agent that processed the corresponding Binding Update
   supports Mobile Routers.  The flag is set only if the corresponding
   Binding Update had the Mobile Router Flag (R) set to 1.  The rest of
   the Binding Acknowledgement format remains the same, as defined in
   [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|  Reserved |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Sequence #            |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Flag (R)

         The Mobile Router Flag is set to indicate that the Home Agent
         that processed the Binding Update supports Mobile Routers.  It
         is set to 1 only if the corresponding Binding Update had the
         Mobile Router Flag set to 1.

   For descriptions of the other fields in the message, see [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   This document also introduces the following new Binding
   Acknowledgement status values.  The values shown below are decimal
   values.

      140     Mobile Router Operation not permitted

      141     Invalid Prefix

      142     Not Authorized for Prefix

      143     Forwarding Setup failed (prefixes missing)

   Status values less than 128 indicate that the Binding Update was
   processed successfully by the receiving nodes.  Values greater than
   128 indicate that the Binding Update was rejected by the Home Agent.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Mobile Network Prefix Option</span>

   The Mobile Network Prefix Option is included in the Binding Update to
   indicate the prefix information for the Mobile Network to the Home
   Agent.  There could be multiple Mobile Network Prefix Options if the
   Mobile Router has more than one IPv6 prefix in the Mobile Network and
   wants the Home Agent to forward packets for each of these prefixes to
   the Mobile Router's current location.

   The Mobile Network Prefix Option has an alignment requirement of
   8n+4.  Its format is as follows.




<span class="grey">Devarapalli, et al.         Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


    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    | Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                   Mobile Network Prefix                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         6

      Length

         Eight-bit unsigned integer indicating the length in octets of
         the option, excluding the type and length fields.  Set to 18.

      Reserved

         This field is unused for now.  The value MUST be initialized to
         0 by the sender and MUST be ignored by the receiver.

      Prefix Length

         Eight-bit unsigned integer indicating the prefix length of the
         IPv6 prefix contained in the option.

      Mobile Network Prefix

         A sixteen-byte field containing the Mobile Network Prefix

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Mobile Router Operation</span>

   Mobile Router operation is derived largely from the combined
   behaviors of a host, of a router [<a href="#ref-5" title="&quot;Internet Protocol, Version 6 (IPv6) Specification&quot;">5</a>], and of a Mobile Node [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   A Mobile Node can act in two ways: (1) as a Mobile Host, in which
   case the Home Agent doesn't maintain any prefix information related
   to the Mobile Host's Home Address but does maintain a binding cache
   entry related to the Mobile Host's Home Address, and (2) as a Mobile
   Router, in which case, in addition to maintaining the binding cache
   entry corresponding to the Mobile Router Home Address, the Home Agent



<span class="grey">Devarapalli, et al.         Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   maintains forwarding information related to prefixes assigned to the
   Mobile Network.  The distinction between the two modes is represented
   by the value of the Mobile Router Flag (R).

   A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes
   as described in section 8.5 of [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Data Structures</span>

   Like a Mobile Host, a Mobile Router also maintains a Binding Update
   List, described in <a href="#section-11.1">section 11.1</a> of the Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].
   The Binding Update list is a conceptual data structure that records
   information sent in the Binding Updates.  There is one entry per each
   destination to which the Mobile Router is currently sending Binding
   Updates.

   This document introduces a new Prefix Information field in the
   Binding Update list structure.  This field is used to store any
   prefix information that the Mobile Router includes in the Binding
   Update.  If the Mobile Router sets the Mobile Router Flag (R) in the
   Binding Update but does not include any prefix information in it this
   field is set to null.  The Mobile Router does not include prefix
   information in the Binding Update in the implicit mode or when it,
   runs a dynamic routing protocol with its Home Agent.

   As does a Mobile Host, a Mobile Router stores the information
   regarding status of flags of the Binding Update in the corresponding
   Binding Update List entry.  This document introduces a new Mobile
   Router Flag (R) for this entry.  The status of this flag is stored in
   the Binding Update list whenever a Binding Update is sent.

   A Mobile Router also maintains a Home Agent list populated according
   to the same procedure as a Mobile Host.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Sending Binding Updates</span>

   A Mobile Router sends Binding Updates to its Home Agent, as described
   in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  If the Mobile Router is not running a routing protocol as
   described in <a href="#section-8">section 8</a>, it uses one of the following modes to tell
   the Home Agent to determine which prefixes belong to the Mobile
   Router.  In both modes, the Mobile Router sets the Mobile Router Flag
   (R).

      Implicit:

         In this mode, the Mobile Router does not include a Mobile
         Network Prefix Option in the Binding Update.  The Home Agent
         can use any mechanism (not defined in this document) to



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


         determine the Mobile Network Prefix(es) owned by the Mobile
         Router and to set up forwarding for the Mobile Network.  One
         example would be manual configuration at the Home Agent mapping
         the Mobile Router's Home Address to the information required
         for setting up forwarding for the Mobile Network.

      Explicit:

         In this mode, the Mobile Router includes one or more Mobile
         Network Prefix Options in the Binding Update.  These options
         contain information about the Mobile Network Prefix(es)
         configured on the Mobile Network.

   A Mobile Router MUST implement at least one mode and MAY implement
   both.  In the latter case, local configuration on the Mobile Router
   decides which mode to use.  This is out of scope for this document.

   If the Mobile Router Flag is set, the Home Registration Flag (H) MUST
   be set.

   If the Mobile Router has a valid binding cache entry at the Home
   Agent, subsequent Binding Updates for the same Home Address should
   have the same value as the value in the binding cache for the Mobile
   Router Flag (R).  In explicit mode, the Mobile Router MUST include
   prefix information in all Binding Updates, including those sent to
   refresh existing binding cache entries, if it wants forwarding
   enabled for the corresponding Mobile Network Prefixes.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Receiving Binding Acknowledgements</span>

   The Mobile Router receives Binding Acknowledgements from the Home
   Agent corresponding to the Binding Updates it sent.  If the Binding
   Acknowledgement status is set to 0 (Binding Update accepted) and the
   Mobile Router Flag (R) is set to 1, the Mobile Router assumes that
   the Home Agent has successfully processed the Binding Update and has
   set up forwarding for the Mobile Network.  The Mobile Router can then
   start using the bi-directional tunnel to reverse-tunnel traffic from
   the Mobile Network.  If the Mobile Router Flag (R) is not set, then
   the Mobile Router concludes that its current Home Agent does not
   support Mobile Routers and it performs Dynamic Home Agent Address
   Discovery again to discover Home Agents that do.  The Mobile Router
   MUST also de-register with the Home Agent that did not support it
   before attempting registration with another.








<span class="grey">Devarapalli, et al.         Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Error Processing</span>

   If the Binding Acknowledgement status is set to a value between 128
   and 139, the Mobile Router takes necessary actions as described in
   the Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  For the Binding Acknowledgement
   status values defined in this document, the following sections
   explain the Mobile Router's behavior.

<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  Implicit Mode</span>

   In Implicit mode, the Mobile Router interprets only error statuses
   140 (Mobile Router Operation not permitted) and 143 (Forwarding Setup
   failed).  The Mobile Router MUST treat Binding Acknowledgements with
   statuses '141' and '142' as fatal errors, since they should not be
   sent by the Home Agent in implicit mode.

   If the Binding Acknowledgement from the Home Agent has the status
   140, the Mobile Router SHOULD send a Binding Update to another Home
   Agent on the same home link.  If no Home Agent replies positively,
   the Mobile Router MUST refrain from sending Binding Updates with the
   Mobile Router Flag set to any Home Agent on the home link, and it
   must log the information.

   If the Binding Acknowledgement has the status 143, the Mobile Router
   SHOULD send a Binding Update to another Home Agent on the same home
   link.  If no Home Agent replies positively, the Mobile Router SHOULD
   refrain from sending this Binding Update to any Home Agent on the
   home link, and MAY send Binding Updates in Explicit mode to a Home
   Agent on the same home link.

<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  Explicit Mode</span>

   If the Mobile Router sent a Binding Update to the Home Agent in
   explicit mode, then the Mobile Router interprets only error statuses
   140 (Mobile Router Operation not permitted), 141 (Invalid Prefix),
   and 142 (Not Authorized for Prefix).  The Mobile Router MUST treat
   Binding Acknowledgements with status '143' as a fatal error, since it
   should not be sent by the Home Agent in explicit mode.

   If the Binding Acknowledgement from the Home Agent has the status
   140, the Mobile Router SHOULD send a Binding Update to another Home
   Agent on the same home link.  If no Home Agent replies positively,
   then the Mobile Router MUST refrain from sending Binding Updates with
   the Mobile Router Flag set to any Home Agent on the home link, and it
   must log the information.

   If the Binding Acknowledgement has the status 141 or 142, the Mobile
   Router SHOULD send a Binding Update to another Home Agent on the same



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   home link.  If no Home Agent replies positively, then the Mobile
   Router SHOULD refrain from sending Binding Updates to any Home Agent
   on the home link.  The Mobile Router MUST also stop advertising the
   prefix in the Mobile Network and try to obtain new IPv6 prefix
   information for the Mobile Network.  It would do this by the same
   means that it initially got assigned the current Mobile Network
   Prefix.  Alternatively, the Mobile Router MAY send Binding Updates in
   Implicit mode to a Home Agent on the same home link.

   If by the end of this Error Processing procedure, as described in
   sections <a href="#section-5.4.1">5.4.1</a> and <a href="#section-5.4.2">5.4.2</a>, the Mobile Router has tried every available
   mode and still has not received a positive Binding Acknowledgement,
   the Mobile Router MUST stop sending Binding Updates with the Mobile
   Router Flag set for this Home Address and it must log the
   information.

   In all cases above, the Mobile Router MUST conclude that the Home
   Agent did not create a binding cache entry for the Mobile Router's
   Home Address.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Establishment of Bi-directional Tunnel</span>

   When a successful Binding Acknowledgement is received, the Mobile
   Router sets up its endpoint of the bi-directional tunnel.

   The bi-directional tunnel between the Mobile Router and the Home
   Agent allows packets to flow in both directions, while the Mobile
   Router is connected to a visited link.  The bi-directional tunnel is
   created by merging two unidirectional tunnels, as described in <a href="./rfc2473">RFC</a>
   <a href="./rfc2473">2473</a> [<a href="#ref-3" title="&quot;Generic Packet Tunneling in IPv6 Specification&quot;">3</a>].  The tunnel from the Mobile Router to the Home Agent has
   the Care-of address of the Mobile Router as the tunnel entry point
   and the Home Agent's address as the tunnel exit point.  The tunnel
   from the Home Agent to the Mobile Router has the Home Agent's address
   and the Mobile Router's Care-of Address as the tunnel entry point and
   exit point, respectively.  All IPv6 traffic to and from the Mobile
   Network is sent through this bi-directional tunnel.

   A Mobile Router uses the Tunnel Hop Limit normally assigned to
   routers (not to hosts).  Please refer to [<a href="#ref-3" title="&quot;Generic Packet Tunneling in IPv6 Specification&quot;">3</a>] for more details.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Neighbor Discovery for Mobile Router</span>

   When the Mobile Router is at home, it MAY be configured to send
   Router Advertisements and to reply to Router Solicitations on the
   interface attached to the home link.  The value of the Router
   Lifetime field SHOULD be set to 0 to prevent other nodes from
   configuring the Mobile Router as the default router.




<span class="grey">Devarapalli, et al.         Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   A Mobile Router SHOULD NOT send unsolicited Router Advertisements and
   SHOULD NOT reply to Router Solicitations on any egress interface when
   that interface is attached to a visited link.  However, the Mobile
   Router SHOULD reply with Neighbor Advertisements to Neighbor
   Solicitations received on the egress interface, for addresses valid
   on the visited link.

   A router typically ignores Router Advertisements sent by other
   routers on a link.  However, a Mobile Router MUST NOT ignore Router
   Advertisements received on the egress interface.  The received Router
   Advertisements MAY be used for address configuration, default router
   selection, or movement detection.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Multicast Groups for Mobile Router</span>

   When at home, the Mobile Router joins the multicast group All Routers
   Address with scopes 1 interface-local (on the home-advertising
   interface), and 2 link-local, on any of its egress interfaces.  When
   in a visited network, the Mobile Router MUST NOT join the above
   multicast groups on the corresponding interface.

<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>.  Returning Home</span>

   When the Mobile Router detects that it has returned to its home link,
   it MUST de-register with its Home Agent.  The Mobile Router MUST
   implement and follow the returning-home procedures defined for a
   mobile node in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  In addition, the Mobile Router MAY start
   behaving as a router on its egress interface, especially as follows:

   -  The Mobile Router MAY send Router Advertisements on its egress
      interfaces, but the router lifetime SHOULD be set to 0 so that
      hosts on the home link do not pick the Mobile Router as the
      default router.

   -  The Mobile Router MAY join the All Routers Address multicast group
      on the home link.

   -  The Mobile Router MAY send routing protocol messages on its egress
      interface if it is configured to run a dynamic routing protocol.

   When the Mobile Router sends a de-registration Binding Update in
   Explicit mode, it SHOULD NOT include any Mobile Network Prefix
   options in the Binding Update.  When the Home Agent removes a binding
   cache entry, it deletes all associated Mobile Network Prefix routes.







<span class="grey">Devarapalli, et al.         Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Home Agent Operation</span>

   For a Mobile Router to operate correctly, the Home Agent MUST satisfy
   all the requirements listed in section 8.4 of [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  The Home Agent
   MUST implement both modes described in <a href="#section-5.2">section 5.2</a> of this document.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Data Structures</span>

<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>.  Binding Cache</span>

   The Home Agent maintains Binding Cache Entries for each Mobile Router
   currently registered with the Home Agent.  The Binding Cache is a
   conceptual data structure described in detail in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   The Home Agent might need to store the Mobile Network Prefixes
   associated with a Mobile Router in the corresponding Binding Cache
   Entry.  This is required if the Binding Update that created the
   Binding Cache Entry contained explicit prefix information.  This
   information can be used later to clean up routes installed in
   explicit mode, when the Binding Cache Entry is removed, and to
   maintain the routing table, for instance, should the routes be
   removed manually.

   The Home Agent also stores the status of the Mobile Router Flag (R)
   in the Binding Cache entry.

<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>.  Prefix Table</span>

   The Home Agent SHOULD be able to prevent a Mobile Router from
   claiming Mobile Network Prefixes belonging to another Mobile Router.
   The Home Agent can prevent such attacks if it maintains a Prefix
   Table and verifies the prefix information provided by the Mobile
   Router against Prefix Table entries.  The Prefix Table SHOULD be used
   by the Home Agent when it processes a Binding Update in explicit
   mode.  It is not required when a dynamic routing protocol is run
   between the Mobile Router and the Home Agent.

   Each entry in the Prefix Table contains the following fields:

   -  The Home Address of the Mobile Router.  This field is used as the
      key for searching the pre-configured Prefix Table.

   -  The Mobile Network Prefix of the Mobile Router associated with the
      Home Address.







<span class="grey">Devarapalli, et al.         Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Mobile Network Prefix Registration</span>

   The Home Agent processes the Binding Update as described in <a href="#section-10.3.1">section</a>
   <a href="#section-10.3.1">10.3.1</a> of the Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  This section describes
   the processing of the Binding Update if the Mobile Router (R) Flag is
   set.  The Home Agent performs the following check.

   -  The Home Registration (H) Flag MUST be set.  If it is not, the
      Home Agent MUST reject the Binding Update and send a Binding
      Acknowledgement with status set to 140.  Note: The basic support
      does not allow sending a Binding Update for a Mobile Network
      Prefix to correspondent nodes (for route optimization).

   -  Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>] requires that the Home Address in
      the Binding Update be configured from a prefix advertised on the
      home link.  Otherwise the Binding Update is rejected with status
      value 132 [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  This specification relaxes this requirement so
      that the Home Agent rejects the Binding Update only if the Home
      Address does not belong to the prefix that the Home Agent is
      configured to serve.

   If the Home Agent has a valid binding cache entry for the Mobile
   Router, and if the Binding Update has the Mobile Router Flag (R) set
   to a value different from that in the existing binding cache entry,
   then the Home Agent MUST reject the Binding Update and send a Binding
   Acknowledgement with status set to 139 (Registration type change
   disallowed).  However, if the Binding Update is a de-registration
   Binding Update, the Home Agent ignores the value of the Mobile Router
   Flag (R).

   If the Lifetime specified in the Binding Update is 0 or the specified
   Care-of address matches the Home Address in the Binding Update, then
   this is a request to delete the cached binding for the home address
   and specified Mobile Network Prefixes.  The Binding Update is
   processed as described in <a href="#section-6.7">section 6.7</a>.

   If the Home Agent does not reject the Binding Update as invalid, and
   if a dynamic routing protocol is not run between the Home Agent and
   the Mobile Router as described in <a href="#section-8">section 8</a>, then the Home Agent
   retrieves the Mobile Network Prefix information as described below.

   -  If a Mobile Network Prefix Option is present in the Binding
      Update, the prefix information for the Mobile Network Prefix is
      retrieved from the Mobile Network Prefix field and the Prefix
      Length field of the option.  If the Binding Update contains more
      than one option, the Home Agent MUST set up forwarding for all the
      Mobile Network Prefixes.  If the Home Agent fails to set up
      forwarding to all the prefixes listed in the Binding Update, then



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


      it MUST NOT forward traffic to any of the prefixes.  Furthermore,
      it MUST reject the Binding Update and send a Binding
      Acknowledgement with status set to 141 (Invalid Prefix).

      If the Home Agent verifies the prefix information with the Prefix
      Table and the check fails, the Home Agent MUST discard the Binding
      Update and send a Binding Acknowledgement with status set to 142
      (Not Authorized for Prefix).

   -  If there is no option in the Binding Update carrying prefix
      information, the Home Agent uses manual pre-configured information
      to determine the prefixes assigned to the Mobile Router and to set
      up forwarding for the Mobile Network.  If there is no information
      that the Home Agent can use, it MUST reject the Binding Update and
      send a Binding Acknowledgement with status set to 143 (Forwarding
      Setup failed).

   If the Home Agent has a valid binding cache entry for the Mobile
   Router, it should compare the list of prefixes in the Binding Update
   against the prefixes stored in the binding cache entry.  If the
   binding cache entry contains prefixes that do not appear in the
   Binding Update, the Home Agent MUST disable forwarding for these
   Mobile Network Prefixes.

   If all checks are passed, the Home Agent creates a binding cache
   entry for Mobile Router's Home Address or updates the entry if it
   already exists.  Otherwise, the Home Agent MUST NOT register the
   binding of the Mobile Router's Home Address.

   The Home Agent defends the Mobile Router's Home Address through Proxy
   Neighbor Discovery by multicasting a Neighbor Advertisement message
   onto the home link on behalf of the Mobile Router.  All fields in the
   Proxy Neighbor Advertisement message should be set the same way they
   would be by the Mobile Router if it sent this Neighbor Advertisement
   while at home, as described in [<a href="#ref-6" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">6</a>].  There is an exception:  If the
   Mobile Router (R) Flag has been set in the Binding Update, the Router
   (R) bit in the Advertisement MUST be set.

   The Home Agent also creates a bi-directional tunnel to the Mobile
   Router for the requested Mobile Network Prefix or updates an existing
   bi-directional tunnel as described in <a href="#section-6.4">section 6.4</a>.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Advertising Mobile Network Reachability</span>

   To receive packets meant for the Mobile Network, the Home Agent
   advertises reachability to the Mobile Network.  If the Home Link is
   configured with an aggregated prefix and the Mobile Network Prefix is
   aggregated under that prefix, then the routing changes related to the



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   Mobile Network may be restricted to the Home Link.  If the Home Agent
   is the only default router on the Home Link, routes to the Mobile
   Network Prefix are aggregated naturally under the Home Agent, which
   does not have to do anything special.

   If the Home Agent receives routing updates through a dynamic routing
   protocol from the Mobile Router, it can be configured to propagate
   those routes on the relevant interfaces.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Establishment of Bi-directional Tunnel</span>

   The implementation of the bi-directional tunnels and the mechanism
   for attaching them to the IP stack are outside the scope of this
   specification.  However, all implementations MUST be capable of the
   following operations:

   -  The Home Agent can tunnel packets meant for the Mobile Network
      prefix to the Mobile Router's current location, the Care-of
      Address.

   -  The Home Agent can accept packets tunneled by the Mobile Router
      with the source address of the outer IPv6 header set to the Mobile
      Router's Care-of Address.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Forwarding Packets</span>

   When the Home Agent receives a data packet destined for the Mobile
   Network, it MUST forward the packet to the Mobile Router through the
   bi-directional tunnel.  The Home Agent uses either the routing table,
   the Binding Cache, or a combination to route packets to the Mobile
   Network.  This is implementation specific.  Two examples are shown
   below.

   1. The Home Agent maintains a route to the Mobile Network Prefix with
      the next hop set to the Mobile Router's Home Address.  When the
      Home Agent tries to forward the packet to the next hop, it finds a
      binding cache entry for the home address.  Then the Home Agent
      extracts the Mobile Router's Care-of address and tunnels the
      packet to the Care-of address.

   2. The Home Agent maintains a route to the Mobile Network Prefix with
      the outgoing interface set to the bi-directional tunnel interface
      between the Home Agent and the Mobile Router.  For this purpose,
      the Home Agent MUST treat this tunnel as a tunnel interface.  When
      the packets are forwarded through the tunnel interface, they are
      encapsulated automatically, with the source address and





<span class="grey">Devarapalli, et al.         Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


      destination address in the outer IPv6 header set to the Home
      Agent's address and the Mobile Router's Care-of address,
      respectively.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Sending Binding Acknowledgements</span>

   A Home Agent serving a Mobile Router sends Binding Acknowledgements
   with the same rules it uses for sending Binding Acknowledgements to
   Mobile Hosts [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>], with the following enhancements.

   The Home Agent sets the status code in the Binding Acknowledgement to
   0 (Binding Update accepted) to indicate to the Mobile Router that it
   successfully processed the Binding Update.  It also sets the Mobile
   Router Flag (R) to indicate to the Mobile Router that it has set up
   forwarding for the Mobile Network.

   If the Home Agent is not configured to support Mobile Routers, it
   sets the status code in the Binding Acknowledgement to 140 (Mobile
   Router Operation not permitted).

   If one or more prefixes received in the Binding Update are invalid
   and the Home Agent cannot set up forwarding for the prefixes, the
   Home Agent sets the status code in the Binding Acknowledgement to 141
   (Invalid Prefix) to indicate this to the Mobile Router.

   If the Mobile Router is not authorized to use this Home Address to
   forward packets for one or more prefixes present in the Binding
   Update, the Home Agent sets the status code in the Binding
   Acknowledgement to 142 (Not Authorized for Prefix) to indicate this.

   The Home Agent sets the status code to 143 (Forwarding Setup failed)
   if it is unable to determine the information needed to set up
   forwarding for the Mobile Network.  This is used in the Implicit
   mode, in which the Mobile Router does not include any prefix
   information in the Binding Update.

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>.  Mobile Network Prefix De-registration</span>

   When the Home Agent successfully processes the de-registration BU, it
   deletes the Binding Cache Entry for the Mobile Router's Home Address
   and stops proxying the Home Address.  This is described in detail in
   the Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   In addition, the Home Agent removes the bi-directional tunnel and
   stops forwarding packets to the Mobile Network.  The Home Agent
   should keep all necessary information to clean up whichever routes it
   installed, whether they come from an implicit or explicit source.




<span class="grey">Devarapalli, et al.         Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   In Explicit mode, the Home Agent MUST ignore any Mobile Network
   Prefix Options present in the de-registration Binding Update.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Modifications to Dynamic Home Agent Address Discovery</span>

   This document extends the Dynamic Home Agent Address Discovery
   (DHAAD) defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>] so that Mobile Routers only attempt
   registration with Home Agents that support them.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Modified Dynamic Home Agent Discovery Address Request</span>

   A new flag (R) (Support for Mobile Routers) is introduced in the
   DHAAD Request message, defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  The Mobile Router sets this
   flag to indicate that it wants to discover Home Agents supporting
   Mobile Routers.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Identifier           |R|          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Support Flag (R)

         A one-bit flag that when set indicates that the Mobile Router
         wants to discover Home Agents supporting Mobile Routers.

      For a description of the other fields in the message, see [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Modified Dynamic Home Agent Discovery Address Request</span>

   A new flag (R) (Support for Mobile Routers) is introduced in the
   DHAAD Reply message, defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  If a Home Agent receives a
   Dynamic Home Agent Discovery request message with the Mobile Router
   Support Flag set, it MUST reply with a list of Home Agents supporting
   Mobile Routers.  The Mobile Router Support Flag MUST be set if there
   is at least one Home Agent supporting Mobile Routers.  If none of the
   Home Agents support Mobile Routers, the Home Agent MAY reply with a
   list of Home Agents that only support Mobile IPv6 Mobile Nodes.  In
   this case, the Mobile Router Support Flag MUST be set to 0.









<span class="grey">Devarapalli, et al.         Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   The modified message format is as follows.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |R|           Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Support Flag (R)

         A one-bit flag that when set indicates that the Home Agents
         listed in this message support Mobile Routers.

      For a description of the other fields in the message, see [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Modified Home Agent Information Option</span>

   A new flag (R) (Support for Mobile Routers) is introduced in the Home
   Agent Information Option defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].  If a Home Agent supports
   Mobile Routers, it SHOULD set the flag.

    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     |R|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Home Agent Preference     |      Home Agent Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Support Flag (R)

         A one-bit flag that when set indicates that the Home Agent
         supports Mobile Routers.

      For a description of the other fields in the message, see [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].









<span class="grey">Devarapalli, et al.         Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Support for Dynamic Routing Protocols</span>

   In the solution described so far, forwarding to the Mobile Network at
   the Home Agent is set up when the Home Agent receives a Binding
   Update from the Mobile Router.  An alternative to this is for the
   Home Agent and the Mobile Router to run an intra-domain routing
   protocol such as RIPng [<a href="#ref-12" title="&quot;RIPng for IPv6&quot;">12</a>] and OSPF [<a href="#ref-13" title="&quot;OSPF for IPv6&quot;">13</a>] through the bi-directional
   tunnel.  The Mobile Router can continue running the same routing
   protocol that it ran when attached to the home link.

   Support for running a intra-domain routing protocol is optional and
   is governed by the configuration on the Mobile Router and the Home
   Agent.

   This feature is very useful when the Mobile Network is large with
   multiple subnets containing different IPv6 prefixes.  Routing changes
   in the Mobile Network are quickly propagated to the Home Agent.
   Routing changes in the home link are quickly propagated to the Mobile
   Router.

   When the Mobile Router is attached to the home link, it runs a
   routing protocol by sending routing updates through its egress
   interface.  When the Mobile Router moves and attaches to a visited
   network, it should stop sending routing updates on the interface by
   which it attaches to the visited link.  This reduces the chances that
   prefixes specific to the Mobile Network will be leaked to the visited
   network if routing protocol authentication is not enabled in the
   visited network and in the Mobile Network.  It is expected that
   normal deployment practices will include proper authentication
   mechanisms to prevent unauthorized route announcements on both the
   home and visited networks.  The Mobile Router then starts sending
   routing protocol messages through the bi-directional tunnel toward
   the Home Agent.  Most routing protocols use link-local addresses as
   source addresses for the routing information messages.  The Mobile
   Router is allowed to use link-local addresses for the inner IPv6
   header of an encapsulated packet.  But these MUST NOT be forwarded to
   another link by either the Mobile Router or the Home Agent.

   When the Home Agent receives the inner packet, it processes the
   encapsulated routing protocol messages and updates its routing table
   accordingly.  As part of normal routing protocol operation, the next
   hop information in these routing entries is filled with the Mobile
   Router's link-local address, with the outgoing interface set to the
   bi-directional tunnel.

   Similarly, the Home Agent sends routing updates through the bi-
   directional tunnel to the Mobile Router.  The Mobile Router processes
   these routing protocol messages and updates its routing table.  For



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   all routes advertised by the Home Agent, the Mobile Router sets the
   outgoing interface to the bi-directional tunnel to the Home Agent.

   When the Mobile Router and the Home Agent exchange routes through a
   dynamic routing protocol, the Mobile Router SHOULD NOT include Mobile
   Network Prefixes in the Binding Update to the Home Agent.  Depending
   on its configuration, the Home Agent might not add routes based on
   the prefix information in the Binding Updates and might use only the
   routing protocol updates.  Moreover, including prefix information in
   both the Binding Updates and the routing protocol updates is
   redundant.

   As the routing protocol messages from the Home Agent to the Mobile
   Router could potentially contain information about the internal
   routing structure of the home network, these messages require
   authentication and confidentiality protection.  Appropriate
   authentication and confidentiality protection mechanisms, defined in
   [<a href="#ref-14" title="&quot;Authentication/Confidentiality for OSPFv3&quot;">14</a>], MUST be used.  For protecting routing protocol messages by
   using IPsec ESP [<a href="#ref-4" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">4</a>], the bi-directional tunnel between the Mobile
   Router and the Home Agent should be treated as the outgoing
   interface, with the Home Agent and Mobile Router's addresses as
   source and destination addresses for the inner encapsulated messages.

   If a link state routing protocol such as OSPFv3 is run by the Mobile
   Router and the Home Agent, the recommendations in <a href="#appendix-B">Appendix B</a> should
   be followed.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   All signaling messages between the Mobile Router and the Home Agent
   MUST be authenticated by IPsec [<a href="#ref-8" title="&quot;Security Architecture for the Internet Protocol&quot;">8</a>].  The use of IPsec to protect
   Mobile IPv6 signaling messages is described in detail in the HA-MN
   IPsec specification [<a href="#ref-2" title="&quot;Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents&quot;">2</a>].  The signaling messages described in this
   document extend Mobile IPv6 messages and do not require any changes
   to what is described in [<a href="#ref-2" title="&quot;Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents&quot;">2</a>].

   The Mobile Router has to perform ingress filtering on packets
   received from the Mobile Network to ensure that nodes in the Mobile
   Network do not use the bi-directional tunnel to launch IP spoofing
   attacks.  In particular, the Mobile Router SHOULD check that the IP
   source addresses in the packets received belong to the Mobile Network
   Prefix and are not the same as one of the addresses used by the
   Mobile Router.  If the Mobile Router receives an IP-in-IP tunneled
   packet from a node in the Mobile Network and it has to forward the
   decapsulated packet, it SHOULD perform the above mentioned checks on
   the source address of the inner packet.





<span class="grey">Devarapalli, et al.         Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   The Home Agent has to verify that packets received through the bi-
   directional tunnel belong to the Mobile Network.  This check is
   necessary to prevent nodes from using the Home Agent to launch
   attacks that would have otherwise been prevented by ingress
   filtering.  The source address of the outer IPv6 header MUST be set
   to the Mobile Router's current Care-of Address.  The source address
   of the inner IPv6 header MUST be topologically correct with respect
   to the IPv6 prefixes used in the Mobile Network.

   If the Mobile Router sends a Binding Update with a one or more Mobile
   Network Prefix options, the Home Agent MUST be able to verify that
   the Mobile Router is authorized for the prefixes before setting up
   forwarding for the prefixes.

   When the Mobile Router runs a dynamic routing protocol as described
   in <a href="#section-8">section 8</a>, it injects routing update messages into the Home Link.
   As the routing protocol message could contain information about the
   internal routing structure of the home network, these messages
   require confidentiality protection.  The Mobile Router SHOULD use
   confidentiality protection through IPsec ESP as described in [<a href="#ref-14" title="&quot;Authentication/Confidentiality for OSPFv3&quot;">14</a>].
   If the bi-directional tunnel between the Mobile Router and the Home
   Agent is protected by ESP, in tunnel mode for all IP traffic, then no
   additional confidentiality protection specific to the routing
   protocol is required.

   Home Agents and Mobile Routers may use IPsec ESP to protect payload
   packets tunneled between themselves.  This is useful to protect
   communications against attackers on the path of the tunnel.

   Please refer to the Mobile IPv6 specification [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>] for security
   considerations when the Mobile Router operates as a Mobile Host.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  IANA Considerations</span>

   This document defines a new Mobility Header Option, the Mobile
   Network Prefix Option as described in <a href="#section-4.3">section 4.3</a>.  The type value
   for this option MUST be assigned from the same space used by the
   mobility options defined in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

   This document also defines the following new Binding Acknowledgement
   status values.  These status values are defined in <a href="#section-4.2">section 4.2</a> and
   MUST be assigned from the same space used for Binding Acknowledgement
   status values in [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>].

      -  Mobile Router Operation not permitted
      -  Invalid Prefix
      -  Not Authorized for Prefix
      -  Forwarding Setup failed (prefixes missing)



<span class="grey">Devarapalli, et al.         Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Contributors</span>

   We would like to acknowledge Ludovic Bellier, Claude Castelluccia,
   Thierry Ernst [<a href="#ref-15" title="&quot;Network Mobility Support in IPv6&quot;">15</a>], Miguel Catalina-Gallego, Christophe Janneteau,
   T.J.  Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya,
   Alexis Olivereau, Charles E. Perkins, and Keisuke Uehara for their
   work on earlier proposals for Network Mobility.  This document has
   inherited a lot of ideas from these proposals.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Acknowledgements</span>

   We thank all members of the NEMO Working Group, and of the preceding
   MONET BoF, for fruitful discussions on the mailing list and at IETF
   meetings.

   Kent Leung, Marco Molteni, and Patrick Wetterwald are acknowledged
   for their work on Network Mobility for IPv4 and IPv6.

   Tim Leinmueller is acknowledged for many insightful remarks and for
   <a href="#section-7">section 7</a>.

   Jari Arkko, James Kempf, Chan-Wah Ng, and Erik Nordmark are
   acknowledged for their thorough review and comments.

   Souhwan Jung, Fan Zhao, S. Felix Wu, HyunGon Kim, and SungWon Sohn
   are acknowledged for identifying threats related to tunneling between
   the Mobile Network and the Home Agent.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  References</span>

<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>.  Normative References</span>

   [<a id="ref-1">1</a>]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.

   [<a id="ref-2">2</a>]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
        Protect Mobile IPv6 Signaling between Mobile Nodes and Home
        Agents", <a href="./rfc3776">RFC 3776</a>, June 2004.

   [<a id="ref-3">3</a>]  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
        Specification", <a href="./rfc2473">RFC 2473</a>, December 1998.

   [<a id="ref-4">4</a>]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.

   [<a id="ref-5">5</a>]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.




<span class="grey">Devarapalli, et al.         Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   [<a id="ref-6">6</a>]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December 1998.

   [<a id="ref-7">7</a>]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>.  Informative References</span>

   [<a id="ref-8">8</a>]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-9">9</a>]  Manner, J. and M. Kojo, Eds., "Mobility Related Terminology",
        <a href="./rfc3753">RFC 3753</a>, June 2004.

   [<a id="ref-10">10</a>] Ernst, T., and H.-Y. Lach, "Network Mobility Support
        Terminology", Work in Progress, October 2004.

   [<a id="ref-11">11</a>] Ernst, T., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Network+Mobility+Support+Goals+and+Requirements%22'>"Network Mobility Support Goals and Requirements"</a>,
        Work in Progress, October 2004.

   [<a id="ref-12">12</a>] Malkin, G. and R. Minnear, "RIPng for IPv6", <a href="./rfc2080">RFC 2080</a>, January
        1997.

   [<a id="ref-13">13</a>] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", <a href="./rfc2740">RFC 2740</a>,
        December 1999.

   [<a id="ref-14">14</a>] Gupta, M. and N. Melam, "Authentication/Confidentiality for
        OSPFv3", Work in Progress, December 2004.

   [<a id="ref-15">15</a>] Ernst, T., "Network Mobility Support in IPv6", PhD Thesis,
        University Joseph Fourier, Grenoble, France. October 2001.

   [<a id="ref-16">16</a>] Moy, J., "Extending OSPF to Support Demand Circuits", <a href="./rfc1793">RFC 1793</a>,
        April 1995.

   [<a id="ref-17">17</a>] Thubert, P., et al., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22NEMO+Home+Network+models%22'>"NEMO Home Network models"</a>, Work in
        Progress, October 2004.














<span class="grey">Devarapalli, et al.         Standards Track                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Examples of NEMO Basic Support Operation</span>

   This section tries to illustrate the NEMO protocol by using a Mobile
   Router and a Mobile Node belonging to different administrative
   domains.  The Mobile Router's Mobile Network consists of a Local
   Fixed Node (LFN) and a Local Fixed Router (LFR) [<a href="#ref-10" title="&quot;Network Mobility Support Terminology&quot;">10</a>].  The LFR has an
   access link to which other Mobile Nodes or Mobile Routers could
   attach.

   Figure 1 depicts the scenario where both the Mobile Router and the
   Mobile Node are at home.


                +----+       +-------+
                | MN |       | HA_MN |
                +--+-+  1::  +---+---+
                  2+-------------+3
                                 |
                                 |
   +-------+2 2:: +-------------------+ 3:: 2+-------+
   | CN_MN |------|     Internet      |------| CN_MR |
   +-------+      +-------------------+      +-------+
                        4::      |
                                 |
                  2+-------------+3
                +--+-+       +---+---+
                | MR |       | HA_MR |
                +--+-+       +-------+
               5:: |1
           ----------
           2|      |3
       +--+-+   +--+-+
       | LFN|   | LFR|
       +--+-+   +--+-+
               6:: |1
           ----------

   Figure 1.  Mobile Router and Mobile Node at home.













<span class="grey">Devarapalli, et al.         Standards Track                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   The Mobile Router then moves away from the home link and attaches to
   a visited link.  This is shown in Figure 2.  The Mobile Router sends
   a Binding Update to HA_MR when it attaches to a visited link and
   configures a Care-of Address.  HA_MR creates a binding cache entry
   for the Mobile Router's Home Address and also sets up forwarding for
   the prefixes on the Mobile Network.

                +----+       +-------+
                | MN |       | HA_MN |
                +--+-+  1::  +---+---+
                  2+-------------+3
                                 |
                                 |
   +-------+2 2:: +-------------------+ 3:: 2+-------+
   | CN_MN |------|     Internet      |------| CN_MR |
   +-------+      ++------------------+      +-------+
                   | 7::     4:: |           4::2-&gt;7::2
                   |             |
                  2+             +3
                +--+-+       +---+---+
                | MR |       | HA_MR | 4::2-&gt;7::2
                +--+-+       +-------+ 5::/prefixlen -&gt; forward
               5:: |1                                   to MR
           ----------                  6::/prefixlen -&gt; forward
           2|      |3                                   to MR
       +--+-+   +--+-+
       | LFN|   | LFR|
       +--+-+   +--+-+
               6:: |1
           ----------

   Figure 2.  Mobile Router on a visited link.



















<span class="grey">Devarapalli, et al.         Standards Track                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   Figure 3 shows the Mobile Node moving away from its home link and
   attaching to the Mobile Router.  The Mobile Node configures a Care-of
   Address from the prefix advertised on the Mobile Network and sends a
   Binding Update to its Home Agent (HA_MN) and to its Correspondent
   Node (CN_MN).  Both HA_MN and CN_MN create binding cache entries for
   the Mobile Node's Home Address.

                              +-------+
                              | HA_MN | 1::2-&gt;6::2
                         1::  +---+---+
                         ---------|3
                                  |
                                  |
    +-------+2 2:: +-------------------+ 3:: 2+-------+
    | CN_MN |------|     Internet      |------| CN_MR |
    +-------+      ++------------------+      +-------+
   1::2-&gt;6::2       | 7::     4:: |           4::2-&gt;7::2
                    |             |
                   2+             +3
                 +--+-+       +---+---+
                 | MR |       | HA_MR | 4::2-&gt;7::2
                 +--+-+       +-------+ 5::/prefixlen -&gt; forward
                5:: |1                                   to MR
            ----------                  6::/prefixlen -&gt; forward
            2|      |3                                   to MR
        +--+-+   +--+-+
        | LFN|   | LFR|
        +--+-+   +--+-+
                6:: |1
            --------+-
                    |2
                 +--+-+
                 | MN |
                 +----+


       Figure 3.  Mobile Node attached to Mobile
                  Router on a visited link













<span class="grey">Devarapalli, et al.         Standards Track                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Running Link State Routing Protocol with NEMO Basic Support</span>

   The bi-directional tunnel between the Mobile Router and the Home
   Agent is used as a virtual interface over which routing protocol
   messages are exchanged.  When a link state routing protocol is run,
   the following recommendations should be followed.

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  Tunnel Interface Considerations</span>

   If the tunnel interface goes up and down every time the Mobile Router
   moves to a new visited network with a high level of mobility and a
   sufficient number of Mobile Routers, the amount of interface state
   changes will adversely affect the Home Agent's performance.  This
   also introduces a high level of instability in the home network.  To
   avoid this, the following should be considered when the bi-
   directional tunnel is implemented:

   -  A tunnel interface is consistently assigned to each Mobile Router,
      as long as it has a valid binding cache at the Home Agent.

   -  Every time the Mobile Router moves and updates the binding cache
      entry, the bi-directional tunnel should not be torn down and set
      up again.  The tunnel end points should be updated dynamically
      with the Mobile Router's current Care-of Address.

   -  With a large number of interfaces, Hello packet processing may
      become a burden.  Therefore, the tunnel interface should be
      treated as On-Demand circuits for OSPF [<a href="#ref-16" title="&quot;Extending OSPF to Support Demand Circuits&quot;">16</a>].

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  OSPF Area Considerations</span>

   The following should be considered when the Home Network is
   configured for running OSPF:

   -  The entire Home domain SHOULD NOT be configured as a single area
      if a Home Agent supports Mobile Routers.  At least the home
      network should be configured as a separate area.

   -  The bi-directional tunnel interfaces to the Mobile Routers should
      never be included in the same area as the backbone links.

   For a more detailed discussion on configuring a home network for NEMO
   Basic Support, please see [<a href="#ref-17" title="&quot;NEMO Home Network models&quot;">17</a>].








<span class="grey">Devarapalli, et al.         Standards Track                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


   One disadvantage of running OSPFv3 with NEMO Basic Support is the
   possibility that the Mobile Networks will be told of the topology of
   the entire home network, including all the fixed and Mobile Routers.
   The only thing the Mobile Routers might really need is a default
   route through the Home Agent.

   To reduce the amount of routing protocol messages received by a
   Mobile Router, one can configure each bi-directional tunnel to a
   Mobile Router as a separate area.  But this requires that the Home
   Agent support a large number of OSPF areas if it supports a large
   number of Mobile Routers, and it might not be possible with most
   router implementations.

   Another option is to configure multiple areas on the Home Link and
   group a number of Mobile Routers into each area.  This reduces the
   number of areas that a Home Agent needs to support but also reduces
   the amount of routing protocol traffic that a Mobile Router receives.


































<span class="grey">Devarapalli, et al.         Standards Track                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


Authors' Addresses

   Vijay Devarapalli
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   EMail:  vijay.devarapalli@nokia.com


   Ryuji Wakikawa
   Keio University and WIDE
   5322 Endo Fujisawa Kanagawa
   252-8520
   Japan

   EMail:  ryuji@sfc.wide.ad.jp


   Alexandru Petrescu
   Motorola Labs
   Parc les Algorithmes Saint Aubin
   Gif-sur-Yvette 91193
   France

   EMail:  Alexandru.Petrescu@motorola.com


   Pascal Thubert
   Cisco Systems Technology Center
   Village d'Entreprises Green Side
   400, Avenue Roumanille
   Biot - Sophia Antipolis 06410
   France

   EMail:  pthubert@cisco.com














<span class="grey">Devarapalli, et al.         Standards Track                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc3963">RFC 3963</a>              NEMO Basic Support Protocol           January 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Devarapalli, et al.         Standards Track                    [Page 33]
</pre>