[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 RFC 3963

NEMO Working Group                                     Vijay Devarapalli
INTERNET DRAFT                                                     Nokia
Category:  Standards Track                                Ryuji Wakikawa
Expires December 2004                                    Keio University
                                                      Alexandru Petrescu
                                                                Motorola
                                                          Pascal Thubert
                                                           Cisco Systems
                                                               June 2004

             Network Mobility (NEMO) Basic Support Protocol
                  draft-ietf-nemo-basic-support-03.txt


Status of This Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

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

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

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.


Abstract

   This 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 for 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 in such a way
   that network mobility is transparent to the nodes inside the mobile
   network.






Devarapalli, et al.                                             [Page 1]

Internet Draft               NEMO Basic Support                June 2004




                                 Contents


Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       4

 2. Terminology                                                        5

 3. Overview of the NEMO Protocol                                      6

 4. Message Formats                                                    9
     4.1. Binding Update  . . . . . . . . . . . . . . . . . . . . .    9
     4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . .    9
     4.3. Mobile Network Prefix Option  . . . . . . . . . . . . . .   10

 5. Mobile Router Operation                                           12
     5.1. Data Structures . . . . . . . . . . . . . . . . . . . . .   12
     5.2. Sending Binding Updates . . . . . . . . . . . . . . . . .   13
     5.3. Receiving Binding Acknowledgements  . . . . . . . . . . .   13
     5.4. Error Processing  . . . . . . . . . . . . . . . . . . . .   14
           5.4.1. Implicit Mode . . . . . . . . . . . . . . . . . .   14
           5.4.2. Explicit Mode . . . . . . . . . . . . . . . . . .   14
     5.5. Establishment of Bi-directional Tunnel  . . . . . . . . .   15
     5.6. Neighbor Discovery for Mobile Router  . . . . . . . . . .   16
     5.7. Multicast Groups for Mobile Router  . . . . . . . . . . .   16
     5.8. Returning Home  . . . . . . . . . . . . . . . . . . . . .   16

 6. Home Agent Operation                                              18
     6.1. Data Structures . . . . . . . . . . . . . . . . . . . . .   18
           6.1.1. Binding Cache . . . . . . . . . . . . . . . . . .   18
           6.1.2. Prefix Table  . . . . . . . . . . . . . . . . . .   18
     6.2. Mobile Network Prefix Registration  . . . . . . . . . . .   19
     6.3. Advertising Mobile Network Reachability . . . . . . . . .   20
     6.4. Establishment of Bi-directional Tunnel  . . . . . . . . .   21
     6.5. Forwarding Packets  . . . . . . . . . . . . . . . . . . .   21
     6.6. Sending Binding Acknowledgements  . . . . . . . . . . . .   22
     6.7. Mobile Network Prefix De-Registration . . . . . . . . . .   22

 7. Modifications to Dynamic Home Agent Discovery                     24
     7.1. Modified Dynamic Home Agent Discovery Request . . . . . .   24
     7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . .   24
     7.3. Modified Home Agent Information Option  . . . . . . . . .   25

 8. Support for Dynamic Routing Protocols                             26



Devarapalli, et al.                                             [Page 2]

Internet Draft               NEMO Basic Support                June 2004


 9. Security Considerations                                           28

10. IANA Considerations                                               29

11. Contributors                                                      29

12. Acknowledgements                                                  29

 A. Examples of NEMO Basic Support Operation                          32

 B. Running Link State Routing Protocol with NEMO Basic Support       35
     B.1. Tunnel Interface Considerations . . . . . . . . . . . . .   35
     B.2. OSPF Area Considerations  . . . . . . . . . . . . . . . .   35

 C. Changes from Previous Version                                     37





































Devarapalli, et al.                                             [Page 3]

Internet Draft               NEMO Basic Support                June 2004


1. Introduction

   This document describes protocol extensions to Mobile IPv6 (MIPv6)
   [1] 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 as well.

   The NEMO Basic Support works in such a way that session continuity is
   ensured 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 the network 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 [1] Mobile Node, by adding
   the capability of routing between its point of attachment (Care-of
   Address) and a subnet which moves with the Mobile Router.

   The solution described in this document requires setting up 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 [10] 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 it
   should be noted 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.











Devarapalli, et al.                                             [Page 4]

Internet Draft               NEMO Basic Support                June 2004


2. Terminology

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

   Network Mobility related terminology is defined in [9] and [10].
   This document in addition defines the following terms.

      Mobile Network Prefix

              An IPv6 prefix that is delegated to a Mobile
              Router and advertised in the mobile network.  There could
              be more than one Mobile Network Prefix being advertised in
              a mobile network.

      Prefix Table

              It is a list of Mobile Network Prefixes indexed by
              the Home Address of a Mobile Router.  The prefix table is
              managed by the Home Agent and is used by the Home Agent
              to determine which Mobile Network Prefixes belong to a
              particular Mobile Router.





























Devarapalli, et al.                                             [Page 5]

Internet Draft               NEMO Basic Support                June 2004


3. Overview of the NEMO Protocol

   A Mobile Network is a network segment or subnet which 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
   bidirectional tunnel to a Home Agent that advertises an aggregation
   of mobile networks to the infrasructure.  The Mobile Router is also
   the default gateway for the mobile network.

   A mobile network can also consist of multiple and nested subnets.  A
   router with no support for mobility 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
   form a graph.  In particular, with Basic NEMO Support, each Mobile
   Router is attached to another mobile network by a single interface,
   and if loops are avoided, the graph is a tree.

   A Mobile Router has an unique Home Address through which it is
   reachable when it is registered with its Home Agent.  The Home
   Address is configured from a prefix that is aggregated and advertised
   by its Home Agent.  The prefix could either be the prefix advertised
   on the home link or the prefix delegated to the Mobile Router.
   The Mobile 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 a Mobile Router.  It acts as a Mobile Host as defined in [1] for
   sessions originated by itself, while providing 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 [1].  When the Home Agent receives this Binding Update
   it creates a binding cache entry binding the Mobile Router's Home
   Address to its Care-of address at the current point of attachment.

   If the Mobile Router wishes 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 using one of the modes described in Section 5.2, so that the
   Home Agent can forward packets meant for nodes in the mobile network



Devarapalli, et al.                                             [Page 6]

Internet Draft               NEMO Basic Support                June 2004


   to the Mobile Router.  A new Mobility Header Option is described in
   this document to carry prefix information.  This option is described
   in Section 4.3.  If the mobile network has more than one IPv6 prefix
   and wants the Home Agent to setup forwarding for all 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 already knows 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 router flag (R) set.

   The Home Agent acknowledges the Binding Update by sending a Binding
   Acknowledgement to the Mobile Router.  A positive acknowledgement
   means that the Home Agent has set up forwarding for the mobile
   network.  Once the binding process completes, a bi-directional tunnel
   is established between the Home Agent and the Mobile Router.  The
   tunnel end points are 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 [3].  The Home 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 [1].

   When a data packet is sent by a Correspondent Node to a node in the
   mobile network, it gets routed to the Home Agent which currently
   has the binding for the Mobile Router.  It is expected that the
   Mobile Router's network prefix would be aggregated at the Home Agent,
   which advertises 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 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.  The Mobile Router before decapsulating the tunneled
   packet, has to check if the Source address on the outer IPv6 header
   is the Home Agent's address.  However, this check is not necessary
   if the packet is protected by IPsec in tunnel mode.  The Mobile
   Router also has to make sure 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.  Otherwise it should
   drop the packet.



Devarapalli, et al.                                             [Page 7]

Internet Draft               NEMO Basic Support                June 2004


   The mobile network could consist of nodes that do not support
   mobility and nodes that support mobility.  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.

   It is also possible for the Mobile Router and the Home Agent to run
   a routing protocol through the bi-directional tunnel.  In that case,
   the Mobile Router need not include prefix information in the Binding
   Update.  Instead the Home Agent uses the routing protocol updates to
   setup forwarding for the mobile network.  When running the routing
   protocol it is required that the bi-directional tunnel 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 that
   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 any additional signalling in the form of
   routing updates in the Home Network.  The drawback of that model is
   the routes are present even if the related Mobile Routers are not
   reachable (at Home or bound) at a given point of time.
























Devarapalli, et al.                                             [Page 8]

Internet Draft               NEMO Basic Support                June 2004


4. Message Formats

4.1. Binding Update

   A new flag (R) is included in the Binding Update to indicate to the
   Home Agent if 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 [1].


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


      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
         just behaving as a Mobile Node, and MUST NOT forward packets
         destined for the mobile network to the Mobile Router.

      Mobility Options

         Variable length field which can include zero or more mobility
         options.  This document defines a new mobility option in
         addition to what is defined in [1].

   For descriptions of the other fields in the message, see [1].


4.2. Binding Acknowledgement

   A new flag (R) is included in the Binding Acknowledgement to indicate
   that the Home Agent which 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




Devarapalli, et al.                                             [Page 9]

Internet Draft               NEMO Basic Support                June 2004


   the Binding Acknowledgement format remains the same as defined in
   [1].


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


      Mobile Router Flag (R)

         The Mobile Router Flag is set to indicate that the Home Agent
         which 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 [1].

   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

   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.


4.3. Mobile Network Prefix Option

   The Mobile Network Prefix Option is included in the Binding Update
   to indicate to the Home Agent the prefix information for the mobile



Devarapalli, et al.                                            [Page 10]

Internet Draft               NEMO Basic Support                June 2004


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


        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

         TBA

      Length

         8 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
         zero by the sender, and MUST be ignored by the receiver.

      Prefix Length

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

      Mobile Network Prefix

         A 16 byte field contains the Mobile Network Prefix.






Devarapalli, et al.                                            [Page 11]

Internet Draft               NEMO Basic Support                June 2004


5. Mobile Router Operation

   Mobile Router operation is derived largely from the combined
   behaviors of a Host, of a Router [5], and of a Mobile Node [1].

   A Mobile Node can act in two different 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 also maintains forwarding information related to
   prefixes assigned to the mobile network).  The distinction between
   the 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 [1].


5.1. Data Structures

   Like a Mobile Host, a Mobile Router also maintains a Binding Update
   List, described in Section 11.1 of Mobile IPv6 specification[1].  The
   Binding Update list is a conceptual data structure which records
   information that is sent in the Binding Updates.  There is one entry
   per each destination that the Mobile Router is currently sending
   Binding Updates to.

   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.

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






Devarapalli, et al.                                            [Page 12]

Internet Draft               NEMO Basic Support                June 2004


5.2. Sending Binding Updates

   A Mobile Router sends Binding Updates to its Home Agent as described
   in [1].  If the Mobile Router is not running a routing protocol
   as described in Section 8, it uses one of the following modes to
   instruct the Home Agent to determine the prefixes that belong to the
   Mobile Router.  In all the 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
         determine the Mobile Network Prefix(es) owned by the Mobile
         Router and setup 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 modes.  If a Mobile Router implements both modes, 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, 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 for the Mobile Router Flag (R) as the value in
   the binding cache.


5.3. Receiving Binding Acknowledgements

   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



Devarapalli, et al.                                            [Page 13]

Internet Draft               NEMO Basic Support                June 2004


   can then start using the bi-directional tunnel for reverse tunneling
   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 performs Dynamic Home
   Agent Discovery again to discover Home Agents which support Mobile
   Routers.  Additional the Mobile Router MUST also de-register with the
   Home Agent which did not support Mobile Routers before attempting
   registration with another Home Agent.


5.4. Error Processing

   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 [1].  For the Binding Acknowledgement
   status values defined in this document, the following sections
   explain the Mobile Router's behavior.


5.4.1. Implicit Mode

   In Implicit mode, the Mobile Router interprets only error
   status '140' (Mobile Router Operation not permitted) and '143'
   (Forwarding Setup failed).  The Mobile Router MUST discard Binding
   Acknowledgements with status '141' and '142'.

   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 log
   the information.

   If the Binding Acknowledgemnet 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.


5.4.2. Explicit Mode

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




Devarapalli, et al.                                            [Page 14]

Internet Draft               NEMO Basic Support                June 2004


   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
   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 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 by the same means
   that it initially got assigned the current Mobile Network Prefix.
   Alternatively, Mobile Router MAY send Binding Updates in Implicit
   mode to a Home Agent on the same home link.

   If at the end of this Error Processing procedure, as described in
   Sections 5.4.1 and 5.4.2, the Mobile Router has tried every available
   modes of sending Binding Updates 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 log the information.

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


5.5. Establishment of Bi-directional Tunnel

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

   The bi-directional tunnel between Mobile Router and Home Agent allows
   packets to flow in both directions between these entities, while the
   Mobile Router is connected to a visited link.  The bi-directional
   tunnel is created by merging two unidirectional tunnels as described
   in RFC 2473 [3].  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 MAY limit the number of mobile routers that attach to
   its mobile network (the number of levels in the nested aggregation)



Devarapalli, et al.                                            [Page 15]

Internet Draft               NEMO Basic Support                June 2004


   by means of setting the Tunnel Encapsulation Limit field of the
   Tunnel Encapsulation option.

   A Mobile Router uses the Tunnel Hop Limit that is normally assigned
   to routers (not to hosts).  Please refer to [3] for more details.


5.6. Neighbor Discovery for Mobile Router

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

   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 topologically
   correct addresses.

   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.


5.7. Multicast Groups for Mobile Router

   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.


5.8. Returning Home

   When the Mobile Router realizes it has returned to its home link
   through movement detection mechanisms, 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 [1].  In
   addition, the Mobile Router MAY start behaving as a router on its
   egress interface.  In particular,

    -  The Mobile Router MAY send router advertisements on its egress
       interfaces.  But the router lifetime SHOULD be set to 0, so that



Devarapalli, et al.                                            [Page 16]

Internet Draft               NEMO Basic Support                June 2004


       hosts on the home link do not pick the Mobile Router as the
       default router.

    -  The Mobile Router MAY join the All Routers 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 the associated Mobile Network Prefix
   routes.





































Devarapalli, et al.                                            [Page 17]

Internet Draft               NEMO Basic Support                June 2004


6. Home Agent Operation

   In order for a Mobile Router to operate correctly, the Home Agent
   MUST satisfy all the requirements listed in Section 8.4 of [1].  The
   Home Agent MUST implement both modes described in Section 5.2 of this
   document.


6.1. Data Structures

6.1.1. Binding Cache

   The Home Agent maintains Binding Cache Entries for each Mobile Router
   that is currently registered with the Home Agent.  The Binding Cache
   is a conceptual data structure described in detail in [1].

   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 cleanup routes installed in explicit
   mode, when the Binding Cache Entry is removed, and to maintain the
   routing table, for instance should the routes be manually removed.

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


6.1.2. Prefix Table

   The Home Agent SHOULD be able to prevent a Mobile Router from
   claiming Mobile Network Prefixes that belong 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 the entries in the Prefix Table.  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 conceptually 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.





Devarapalli, et al.                                            [Page 18]

Internet Draft               NEMO Basic Support                June 2004


6.2. Mobile Network Prefix Registration

   The Home Agent processes the Binding Update as described in Section
   10.3.1 of the Mobile IPv6 specification [1].  This section describes
   the processing of the Binding Update if the Mobile Router (R) flag is
   set.  The Home Agent performs the following check in addition.

    -  The Home Registration (H) flag MUST be set.  If 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 Binding Update for a Mobile Network Prefix
       to correspondent nodes (for route optimization).

    -  Mobile IPv6 specification [1] requires that the Home Address in
       the Binding Update should be configured from a prefix advertised
       on the home link.  Otherwise the Binding Update is rejected
       with status value 132 [1].  This specification relaxes this
       requirement so that the Home Agent rejects the Binding Update
       only if 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 the value in the existing binding
   cache entry, 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 Home Agent does not reject the Binding Update as described
   above, and if a dynamic routing protocol is not being run between
   the Home Agent and the Mobile Router as described in Section 8, 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 of
       the Mobile Network Prefixes.  If the Home Agent fails to setup
       forwarding to all the prefixes listed in the Binding Update, then
       it MUST NOT forward traffic to any of the prefixes, 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



Devarapalli, et al.                                            [Page 19]

Internet Draft               NEMO Basic Support                June 2004


       Binding Update and send a Binding Acknowldegement with status set
       to 142 (Not Authorized for Prefix).

    -  If there are is no option in the Binding Update carying
       prefix information, the Home Agent uses manual pre-configured
       information to determine the prefixes assigned to the Mobile
       Router and for setting 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 Lifetime specified in the Binding Update is zero 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 according to the procedure described in
   Section 6.7.

   If all checks are passed, the Home Agent creates a binding cache
   entry for Mobile Router's Home Address, or updates the binding cache
   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 onto the home link a Neighbor
   Advertisement message on behalf of the mobile router.  All fields in
   the Proxy Neighbor Advertisement message should be set in the same
   way they would be set by the Mobile Router itself if sending this
   Neighbor Advertisement while at home, as described in [6], with the
   exception that the Router (R) bit in the Advertisement MUST be set if
   the Mobile Router (R) flag has been set in the Binding Update.

   The Home Agent also creates a bi-directional tunnel to the mobile
   router for the requested Mobile Network Prefix, or update an existing
   bi-directional tunnel as described in Section 6.4.


6.3. Advertising Mobile Network Reachability

   In order to be able to receive packets meant for the mobile network,
   the Home Agent advertises reachability to the mobile network.  If
   the Home Link is configured with a prefix that is an aggregation and
   if the Mobile Network Prefix is aggregated under that prefix, then
   the routing changes related to the 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 get aggregated
   naturally under the Home Agent and the Home Agent does not have to do
   anything special.




Devarapalli, et al.                                            [Page 20]

Internet Draft               NEMO Basic Support                June 2004


   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.


6.4. Establishment of Bi-directional Tunnel

   The implementation of the bi-directional tunnels and the mechanism
   of 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 of the Mobile Router.

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


6.5. Forwarding Packets

   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 either uses only the routing
   table, only the Binding Cache or a combination of routing table
   and Binding Cache 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 get encapsulated automatically with the source
       address and destination address in the outer IPv6 header set to
       the Home Agent's address and the Mobile Router's Care-of address,
       respectively.






Devarapalli, et al.                                            [Page 21]

Internet Draft               NEMO Basic Support                June 2004


6.6. Sending Binding Acknowledgements

   A Home Agent serving a Mobile Router sends Binding Acknowledgements
   according to the same rules it uses for sending Binding
   Acknowledgements to Mobile Hosts [1], with the following
   enhancements.

   The Home Agent sets the status code in the Binding Acknowledgement
   to '0' (Binding Update accepted) in order 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 setup forwarding for the mobile network.

   If the Home Agent is configured not 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 setup forwarding for the prefixes, the Home
   Agent sets the status code in the Binding Acknowledgement to '141'
   (Invalid Prefix) in order 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 that are present in the
   Binding Update, the Home Agent sets the status code in the Binding
   Acknowledgement to '142' (Not Authorized for Prefix) in order 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 setup
   forwarding for the mobile network.  This is used in the Implicit mode
   where the Mobile Router does not include any prefix information in
   the Binding Update.


6.7. Mobile Network Prefix De-Registration

   The Mobile Router de-registers with the Home Agent by sending a
   Binding Update with the lifetime set to zero.  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 [1].

   In addition, the Home Agent also 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 implicit or explicit source.




Devarapalli, et al.                                            [Page 22]

Internet Draft               NEMO Basic Support                June 2004


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


















































Devarapalli, et al.                                            [Page 23]

Internet Draft               NEMO Basic Support                June 2004


7. Modifications to Dynamic Home Agent Discovery

   This document extends the Dynamic Home Agent Discovery mechanism
   defined in [1], so that Mobile Routers attempt registration only with
   Home Agents that support Mobile Routers.


7.1. Modified Dynamic Home Agent Discovery Request

   A new flag (R) (Support for Mobile Routers) is introduced in the
   Dynamic Home Agent Discovery Reguest message defined in [1].  The
   Mobile Router sets this flag to indicate that it wants to discover
   Home Agents that support 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 1 bit flag which when set indicates that the Mobile Router
         wants to discover Home Agents that support Mobile Routers.

      For a description of the other fields in the message, see [1].


7.2. Modified Dynamic Home Agent Discovery Reply

   A new flag (R) (Support for Mobile Routers) is introduced in the
   Dynamic Home Agent Discovery Reply message defined in [1].  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 that support Mobile Routers.  The Mobile Router Support flag
   MUST be set if there is at least one Home Agent that supports Mobile
   Routers.  If none of the Home Agents support Mobile Routers, the Home
   Agent MAY reply with a list of Home Agents that support just Mobile
   IPv6 Mobile Nodes.  In this case, the Mobile Router Support flag MUST
   be set to 0.










Devarapalli, et al.                                            [Page 24]

Internet Draft               NEMO Basic Support                June 2004


   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          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       .                                                               .
       .                      Home Agent Addresses                     .
       .                                                               .
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Mobile Router Support Flag (R)

         A 1 bit flag which 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 [1].


7.3. Modified Home Agent Information Option

   A new flag (R) (Support for Mobile Routers) is introduced in the Home
   Agent Information Option defined in [1].  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 1-bit flag which when set indicates that the Home Agent
         supports Mobile Routers.

      For a description of the other fields in the message, see [1].






Devarapalli, et al.                                            [Page 25]

Internet Draft               NEMO Basic Support                June 2004


8. Support for Dynamic Routing Protocols

   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 like RIPng [12] and OSPF [13] through the bi-directional
   tunnel.  The Mobile Router can continue running the same routing
   protocol that it was running when it was 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 propagated to the Home Agent quickly.
   Routing changes in the home link are also propagated to the Mobile
   Router very quickly.

   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 MUST stop sending routing updates on the interface
   with which it attaches to the visited link.  This is to reduce the
   chances that prefixes specific to the Mobile Network are leaked to
   the visited network in the case where 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 home and visited networks.  The Mobile Router then starts
   sending routing protocol messages through the bi-directional tunnel
   towards 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 routing
   protocol messages with link local address 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.

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



Devarapalli, et al.                                            [Page 26]

Internet Draft               NEMO Basic Support                June 2004


   table.  For 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.  The
   Home Agent depending on its configuration might not add routes based
   on the prefix information in the Binding Updates at all, and might
   use only the routing protocol updates.  Moreover, including prefix
   information in both the Binding Updates and the routing protocol
   updates is redundant.

   Since 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
   [14] MUST be used.  For protecting routing protocol messages using
   ESP, the bi-directional tunnel between the Mobile Router and the
   Home Agent should be treated as the outgoing interface, with the
   Home Agent's and Mobile Router's addresses as source and destination
   addresses for the inner encapsulated messages.

   If a link state routing protocol like OSPFv3 is run by the Mobile
   Router and the Home Agent, the recommendations in Appendix B should
   be followed.

























Devarapalli, et al.                                            [Page 27]

Internet Draft               NEMO Basic Support                June 2004


9. Security Considerations

   All signaling messages between the Mobile Router and the Home Agent
   MUST be authenticated by IPsec [8].  The use of IPsec to protect
   Mobile IPv6 signaling messages is described in detail in the HA-MN
   IPsec specification [2].  The signaling messages described in this
   document just extend Mobile IPv6 messages and do not require any
   changes to what is described in the HA-MN IPsec specification.

   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 address in the packets received from the nodes in the Mobile
   Network belongs to the Mobile Network Prefix and is not the same as
   one of the addresses used by the Mobile Router.  In case the Mobile
   Router receives a IP-in-IP tunneled packet from a node in the Mobile
   Network and the Mobile Router has to forward the decapsulated packet,
   it SHOULD perform the above mentioned checks on the source address of
   the inner packet.

   The Home Agent has to verify that packets received through the
   bi-directional tunnel belong to the mobile network.  This check is
   necessary in order 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 a topologically correct address with
   respect to the IPv6 prefixes used in the mobile network.

   When the Mobile Router is running a dynamic routing protocol as
   described in Section 8, it injects routing update messages into
   the Home Link.  Since the routing protocol message could contain
   information about the internal routing structure of the home network,
   these messages require confidentiality protection.  Confidentiality
   protection through IPsec ESP as described in [14] SHOULD be used.
   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 [1] for security
   considerations when the Mobile Router operates as a Mobile Host.





Devarapalli, et al.                                            [Page 28]

Internet Draft               NEMO Basic Support                June 2004


10. IANA Considerations

   This document defines a new Mobility Header Option, the Mobile
   Network Prefix Option.  This option is described in Section 4.3.  The
   type value for this option needs to be assigned from the same space
   used by the mobility options defined in [1].

   This document also defines the following new Binding Acknowledgement
   status values.  These status values are defined in Section 4.2
   and need to be assigned from the same space used for Binding
   Acknowledgement status values in [1].

    -  Mobile Router Operation not permitted

    -  Invalid Prefix

    -  Not Authorized for Prefix

    -  Forwarding Setup failed


11. Contributors

   We would like to acknowledge Ludovic Bellier, Claude Castelluccia,
   Thierry Ernst, 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 inherits a lot
   of ideas from these proposals.


12. Acknowledgements

   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 for their work on
   Network Mobility for IPv4 and IPv6.

   Tim Leinmueller for many insightful remarks and for Section 7.

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








Devarapalli, et al.                                            [Page 29]

Internet Draft               NEMO Basic Support                June 2004


Normative References

   [1]  D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6.
        Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in
        progress). June 2003.

   [2]  J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect
        Mobile IPv6 Signaling between Mobile Nodes and Home Agents.
        Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
        (work in progress). June 2003.

   [3]  A. Conta and S. Deering. Generic Packet Tunneling in IPv6
        Specification. RFC 2473, IETF. December 1998.

   [4]  S. Kent and R. Atkinson. IP Encapsulating Security Payload
        (ESP). RFC 2402, IETF. November 1998.

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

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

   [7]  S. Bradner. Key words for use in RFCs to Indicate Requirement
        Levels. RFC 2119, IETF. March 1997.


Informative References

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

   [9]  J. Manner and M. Kojo. Mobility Related Terminology. Internet
        Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt
        (work in progress). November 2003.

   [10] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology.
        Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work
        in progress). May 2003.

   [11] T. Ernst. Network Mobility Support Goals and Requirements.
        Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work
        in progress). May 2003.

   [12] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF.
        January 1997.

   [13] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470,
        IETF. December 1999.



Devarapalli, et al.                                            [Page 30]

Internet Draft               NEMO Basic Support                June 2004


   [14] M. Gupta and N. Melam. Authentication/Confidentiality for
        OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt
        (work in progress). December 2003.

   [15] T. Ernst. Network Mobility Support in IPv6. PhD Thesis,
        University Joseph Fourier, Grenoble, France. October 2001.

   [16] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the
        InternetCAR perspective. Journal of Interconnection Networks
        (JOIN), Vol. 4, No. 3. September 2003.

   [17] J. Moy. Extending OSPF to Support Demand Circuits. RFC 1793,
        IETF. April 1995.

   [18] P. Thubert, et. al. NEMO Home Network models. Internet Draft,
        IETF. draft-ietf-home-network-models-00.txt (work in progress).
        April 2004.



































Devarapalli, et al.                                            [Page 31]

Internet Draft               NEMO Basic Support                June 2004


A. Examples of NEMO Basic Support Operation

   This section tries to illustrate the NEMO protocol 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) [10].  The LFR has
   an access link to which other Mobile Nodes or Mobile Routers could
   attach to.

   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.













Devarapalli, et al.                                            [Page 32]

Internet Draft               NEMO Basic Support                June 2004


   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 Addres.  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->7::2
                        |             |
                       2+             +3
                     +--+-+       +---+---+
                     | MR |       | HA_MR | 4::2->7::2
                     +--+-+       +-------+ 5::/prefixlen -> forward
                    5:: |1                                   to MR
                ----------                  6::/prefixlen -> forward
                2|      |3                                   to MR
            +--+-+   +--+-+
            | LFN|   | LFR|
            +--+-+   +--+-+
                    6:: |1
                ----------



               Figure 2: Mobile Router on a Visited Link.

















Devarapalli, et al.                                            [Page 33]

Internet Draft               NEMO Basic Support                June 2004


   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 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->6::2
                             1::  +---+---+
                             ---------|3
                                      |
                                      |
        +-------+2 2:: +-------------------+ 3:: 2+-------+
        | CN_MN |------|     Internet      |------| CN_MR |
        +-------+      ++------------------+      +-------+
       1::2->6::2       | 7::     4:: |           4::2->7::2
                        |             |
                       2+             +3
                     +--+-+       +---+---+
                     | MR |       | HA_MR | 4::2->7::2
                     +--+-+       +-------+ 5::/prefixlen -> forward
                    5:: |1                                   to MR
                ----------                  6::/prefixlen -> forward
                2|      |3                                   to MR
            +--+-+   +--+-+
            | LFN|   | LFR|
            +--+-+   +--+-+
                    6:: |1
                --------+-
                        |2
                     +--+-+
                     | MN |
                     +----+


                Figure 3: Mobile Node attached to Mobile
                        Router on a Visited Link













Devarapalli, et al.                                            [Page 34]

Internet Draft               NEMO Basic Support                June 2004


B. Running Link State Routing Protocol with NEMO Basic Support

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


B.1. Tunnel Interface Considerations

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

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

    -  Everytime the Mobile Router moves and updates the binding cache
       entry, the bi-directional tunnel should not be torn down and
       setup 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 [17].


B.2. OSPF Area Considerations

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

   One disadvantage of running OSPFv3 with NEMO Basic Support is that
   there is a possibility that the Mobile Networks will be told of the
   topology of the entire Home Network, including all the fixed and



Devarapalli, et al.                                            [Page 35]

Internet Draft               NEMO Basic Support                June 2004


   mobile routers, while 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 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 at the same
   time reduces the amount of routing protocol traffic that a Mobile
   Router receives.





































Devarapalli, et al.                                            [Page 36]

Internet Draft               NEMO Basic Support                June 2004


C. Changes from Previous Version

   The following changes have been made to this document from version 02

    -  Clarified that Mobile Network Prefix Options should be ignored in
       de-registration binding updates.  (Issue #30)

    -  Addressed tunnel interface concerns when dynamic routing
       protocols are used.  Added section B.1.  (Issue #31)

    -  Addressed OSPF Area configuration considerations.  Added section
       B.2.  (Issue #31)

    -  Clarified the use of link local addresses on the inner
       encapsulated packets when routing protocol messages are exchanged
       between the Mobile Router and the Home Agent.  (Issue #31)

    -  Clarified that binding acknowledgement status values are in
       decimal.  (Issue #32)

    -  Clarifed that the Home Agent does not have to check the source
       address of the outer IPv6 header against the binding cache if the
       tunneled packet is protected by ESP in tunneled mode.  (Issue
       #33)

    -  Fixed the text which says Mobile Router does not process binding
       acknowledgement with status value 140.  (Issue #33)

    -  Added text to clarify the relationship between the use of a
       Prefix Table and running a dynamic routing protocol.  (Issue #33)

    -  Clarified the terminology used in describing bi-directional
       tunnel setup.  (Issue #34)

    -  Added text to specify that the Mobile Router has to implement
       atleast one mode and may implement both.  (Issue #34)

    -  Re-wrote section 5.4 for better clarity.  (Issue #34)

    -  Mobile Router Flag in Binding Update conflicts with HMIPv6's M
       flag.  Moved the flag to a new position.  (Issue #35)

    -  Clarified Binding Acknowledgement status value 139 and the Mobile
       Router Flag.  (Issue #38)








Devarapalli, et al.                                            [Page 37]

Internet Draft               NEMO Basic Support                June 2004


Authors' Address


        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






















Devarapalli, et al.                                            [Page 38]

Internet Draft               NEMO Basic Support                June 2004


Intellectual Property Statement

   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 procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

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

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgement

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





Devarapalli, et al.                                            [Page 39]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/