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

                      Nemo Basic Support Protocol
                  draft-ietf-nemo-basic-support-00.txt
                  draft-ietf-nemo-basic-support-01.txt

Status of This Memo

   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 of RFC2026.

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

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

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

Abstract

   This document describes a the Nemo Basic Support protocol to support
   network mobility as the mobile network attaches to different points
   in the Internet.  The protocol is based on extensions to 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 protocol is
   based on extensions to Mobile IPv6 [1].  The Mobile Router [2]
   Router, which connects the network to the Internet 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.

                                 Contents

Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       4

 2. Terminology                                                        5

 3. Overview of the NEMO Nemo Protocol                                      7                                      6

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

 5. Mobile Router Operation                                           14                                           13
     5.1. Data Structures . . . . . . . . . . . . . . . . . . . . .   14   13
     5.2. Sending Binding Updates . . . . . . . . . . . . . . . . .   15   13
     5.3. Receiving Binding Acknowledgements  . . . . . . . . . . .   15   14
     5.4. Error Processing  . . . . . . . . . . . . . . . . . . . .   16   15
     5.5. Establishment of Bi-directional Tunnel  . . . . . . . . .   17   16
     5.6. Neighbour Discovery for Mobile Router . . . . . . . . . .   18   17
     5.7. Multicast Groups for Mobile Router  . . . . . . . . . . .   18   17

 6. Home Agent Operation                                              19                                              18
     6.1. Prefix Table Data Structures . . . . . . . . . . . . . . . . . . . . .   18
           6.1.1. Binding Cache .   19 . . . . . . . . . . . . . . . . .   18
           6.1.2. Prefix Table  . . . . . . . . . . . . . . . . . .   18
     6.2. Mobile Network Prefix Registration  . . . . . . . . . . .   19
     6.3. Advertising Mobile Network Reachability . . . . . . . . .   21   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 . . . . . . . . . .   23   22

 7. Extended Home Network                                             24

 8. Support for Dynamic Routing Protocols                             26

 9. Use of IPsec to protect the Signaling Messages                    27

10.                             23

 8. Security Considerations                                           28

11.                                           25

 9. IANA Considerations                                               28

12.                                               25

10. Contributors                                                      28

13.                                                      25

11. Acknowledgements                                                  28                                                  26

 A. Examples of Operation                                             28

 B. Changes from Previous Version                                     31

Addresses                                                             34                                                             32

1. Introduction

   This document describes protocol extensions to Mobile IPv6 (MIPv6)
   [1] to enable support for network mobility.  The extensions provide
   a
   backward compatibility with Mobile IPv6, and in particular, a Nemo
   compliant Home Agent can operate as a MIPv6 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 Local Fixed
   Nodes [2] [8] and Mobile Nodes in the Mobile Metwork. 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
   how to route optimize this traffic.  Route Optimization will be dealt
   with in later specifications.

   IPsec is used to secure all signalling messages between the Mobile
   Router and its Home Agent.  The use of IPsec to protect the signaling
   messages is described in [3].  This document does not introduce any
   additional requirements as far as the use of IPsec is concerned.

   The terminology document [2] [8] 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 important significant overhead on
   the data packets as each level of nestedness introduces another IPv6
   header encapsulation.

2. Terminology

   There is a separate NEMO terminology document [2], which defines the
   terms related to Network Mobility used in the document.

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

   There is a separate NEMO terminology document [8], which defines the
   terms related to Network Mobility used in the document.

      Prefix Table

              It is a list of a mobile network prefixes Mobile Network Prefixes indexed
              by the extended Home Address of a Mobile Router.  The prefix table
              is managed by the Home Agent.  When a Agent and is used by the Home Agent receives a Binding Update without any options,
              it searches a correspondent
              to determine which Mobile Network prefix in
              the prefix table, keying with the Home Address of the
              requesting Prefixes are owned
              a particular Mobile Router.  This is an optional data
              structure.

      Mobile Network Prefix

              The IPv6 prefix advertised in the Mobile Network
              by one or more Mobile Routers.  There could be multiple
              prefixes in the Mobile Network.

      extended Home Network Prefix

              The aggregation of one or more Home Network and
              Mobile Network prefixes.  The extended Home Network
              is generally the granularity that is exposed by the
              Home Agents to the routing infrastructure over routing
              protocols.

      extended Home Network

              The network associated with the extended Home
              Network Prefix.  The extended Home Network may be physical
              or virtual.

      extended Home Address

              The Home Address is derived from the Home Network
              prefix.  The extended Home Address is taken from the
              extended Home Network.  More precisely, the extended Home
              Address can be either from the Home Network or from one of
              the Mobile Router's Mobile Network prefixes.  The extended
              Home Address inherits from the properties of the Home
              Address and can be used for registration to the Home Agent
              as described in this document.

3. Overview of the NEMO Nemo Protocol

   A Mobile Network is a network segment or subnet which can move
   and attach to arbitrary points in the Internet.  A Mobile Network
   does not allow any transit traffic and can only be accessed via
   specific Gateways gateways called Mobile Routers that manage its movement.
   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.  In
   particular, a  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 always
   reachable.  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.  This is described in detail in Section 7.  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 allocating these Mobile
   Network Prefixes is outside the scope of this specification.  However, it is recommended
   that these prefixes are allocated in such a manner that they can be
   aggregated under the home link.

   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 at any time can appear and behave
   as a Mobile Host or a Mobile Router.  If the Mobile Router wants
   connectivity, rechability reachability and session continuity for nodes in the
   Mobile Network, it acts as a Mobile Router.  In either case, 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
   includes include information about the Mobile Network Prefix in the
   Binding Update using one of the modes described in Section section 5.2, so
   that the Home Agent can forward packets meant for nodes in the mobile
   network to the Mobile Router.  Two new Mobility Header Options are
   described in this document to carry prefix information.  These new
   options are described in Section section 4.3 and section 4.4.  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 are owned by a Mobile Router.  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.

   If
   router with the router flag 'R' set.

   The Home Agent successfully processes acknowledges the Binding Update and
   sets up forwarding for the Mobile Network Prefix, it sends by sending a Binding
   Acknowledgement to the Mobile Router.  A positive acknowledgement
   means that the HA 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 [4]. [3].
   The Home Agent decapsulates this packet and forwards it to the CN.
   Correspondent Node.  The Mobile Router is however free to use route
   optimization as described in [1] for packet originated by the Mobile
   Router itself.

   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 meant for 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 for now. 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 link interface where the Mobile
   Network is connected.  The Mobile Network could consist of nodes which are Local Router before decapsulating the
   tunneled packet, has to check if the Source address on the outer IPv6
   header is the Home Agent's address.  It also has to make sure the
   destination address on the inner IPv6 header belongs to one of its
   Mobile Network Prefixes before forwarding the packet to the Mobile
   Network.

   The Mobile Network could consist of nodes which are Local Fixed
   Nodes, Local Mobile Nodes and Visiting Mobile Nodes [2]. [8].  The
   protocol described here ensures complete transparency of network
   mobility to the Local Fixed Nodes.  Visiting Mobile Nodes are those
   nodes which are Mobile Nodes as described in Mobile IPv6.  Visiting
   Mobile Nodes treat the Mobile Network as just 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.  The  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 as the list of
   interfaces on which routing protocol is active.  The Mobile Router
   should be careful to configured not to run the routing protocol on its egress
   interface when it is away from the home link.

   Finally, the Home Agent(s) Agent may be configured with static routes to the
   Mobile Network Prefix via the Mobile Router home address.. 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 that the
   routes are present even if the related Mobile Routers that are not
   reachable (at Home or bound) at a given point of time.

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

      Mobile Router Flag(R) 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 should not 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 two new mobility options in
         addition to what is defined in [1].  The receiver MUST skip and
         ignore any options which it does not understand.

4.2. Binding Acknowledgement

   There is no change in the Binding Acknowledgement format from what
   is used in Mobile IPv6 [1].  However, this document introduces the
   following new status values for the binding acknowledgement.

   Status
      2       Mobile Router Binding Update accepted

      140     Mobile Router Operation not permitted

      141     Invalid Prefix

      142     Not Authorized for Prefix

      143     Mobile Network Prefix information unavailable.     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 receiving
   node.

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

         TBD

         TBA
      Length

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

      Reserved

         Set to 0.  Ignored

         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.

4.4. Mobile Network Prefix Length Option

   The Mobile Network Prefix Length Option can be used by the Mobile
   Router if the Mobile Network Prefix can be deduced from the Home
   Address of the Mobile Router.  If there is only one Mobile Network
   Prefix owned by the Mobile Router, using this option helps in
   saving 16 bytes in the Binding Update by not including the prefix
   information.

   There can only be one instance of this option in a Binding Update.
   The Mobile Network Prefix Option cannot be present in the Binding
   Update if this option is present.

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

      Type

         TBD

         TBA

      Length

         8 bit unsigned integer indicating the length in octets of the
         option excluding the type and length field.  Set to 2.

      Reserved

         Set to 0.  Ignored

         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 from which the Home Address included in the option Binding
         Update was configured.

5. Mobile Router Operation

   Mobile Router operation is derived largely from the combined
   behaviors of a Host, of a Router [8], [6], and of a Mobile Node [1] (also
   please see definition of a Mobile Host in [2] and the definition of
   an IPv4 Mobile Node [10]). [8]).

   A Mobile Node can act in two different ways:  (1) as a Mobile Host
   (in which case the Mobile IPv6 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 Mobile IPv6 Home Agent also maintains
   forwarding information related to prefixes assigned to the Mobile
   Network). mobile
   network).  The distinction between the the two modes is represented
   by the value of the 'R' bit. Mobile Router uses various data structures, exchanges specific
   binding messages with Home Agent, performs a specific Neighbour
   Discovery behavior and joins certain multicast groups. flag 'R'.

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' bit in the
   Binding Update, but does not include any prefix information in it
   (implicit mode), this field is set to null.

   Similar to a Mobile Host, a Mobile Router also stores the information
   regarding status of flags of the Binding Update, in the corresponding
   Binding Update List entry.  Additionally, this  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.

   Similarly to a Mobile Host, a

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

5.2. Sending Binding Updates

   A Mobile Router will send sends Binding Updates to its Home Agent according to
   the same procedures that a Mobile Host uses.  The Mobile Router
   MUST use uses
   one of the following modes to instruct the Home Agent to determine
   the prefixes owned by the Mobile Network prefix. Router.  In all three modes, the
   Mobile Router sets the 'R' bit to 1. Mobile Router flag 'R'.

      Implicit:

         In this mode, the Mobile Router does not include either a
         Mobile Network Prefix Option or a Mobile Network Prefix Length
         Option in the Binding Update (but it does include the Home
         Address Option in the Destination Options header, as all Mobile
         Hosts do).  The Home Agent can use any mechanism (not defined
         in this document) to determine the Mobile Network Prefix(es)
         owned by the Mobile Router.  One of Router and setup forwarding for the well known mechanisms is
         where Mobile
         Network.  One example would be manual configuration at the
         Home Agent maintains a Pre-configured Prefix Table
         listing all mapping the Mobile Network prefixes owned by a particular
         Mobile Router.  This table is keyed on the Router's Home Address of to the
         information required for setting up forwarding for the Mobile Router.

      Explicit:

         In
         Network.

      Explicit Network:

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

      Explicit combined: Prefix Length:

         In this mode, the Mobile Router instructs the Home Agent to
         derive the Mobile Network Prefix by using:  (1) the Home
         Address in the Home Address Option carried in the Destination
         Options header of the same packet that carries the Mobility
         Header containing this Binding Update and (2) the prefix length
         carried in the Mobile Network Prefix Length Option.  In this
         case, Mobile Router includes one and only one Mobile Network
         Prefix Length Option.  It MUST not NOT include a Mobile Network
         Prefix Option if this method is used.

   If the Mobile Router flag is set, The Mobile Router MUST also set the Home Registration flag 'H'. 'H' MUST be
   set.

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 a value less than 128, '2' (Mobile Router Binding
   Update accepted), the Mobile Router assumes that the Home Agent has
   successfully processed the Binding Update was processed succesfully
   by and has set up forwarding
   for the Home Agent.  The Mobile Network.The Mobile Router can then start using the
   bi-directional tunnel for reverse tunneling traffic from the mobile
   network.

5.4. Error Processing

   If the Binding Acknowledgement status is set to a value between 128
   and 140, the Mobile Router takes necessary actions as described in
   the Mobile IPv6 specification [1].

   If the Binding Acknowlegement status is set to '0' (Binding Update
   accepted), the Mobile Router concludes that the Home Agent which
   processed the Binding Update is a MIPv6 Home Agent that has not
   implemented support for Mobile Routers.  It should send a similar
   Binding Update to another Home Agent on the link.  If no Home Agent
   replies positively then the Mobile Router MUST refrain from sending
   any Binding Update with the Mobile Router flag set to any home agent
   on the home link and log the information.

   If the Mobile Router sent a Binding Update to the Home Agent in
   implicit mode (i.e.  the prefix field in the Binding Update list
   entry is null) then the Mobile Router interprets only the error
   status '140' (Mobile Router Operation not permitted) and '143'
   (Mobile Network Prefix information unavailable).
   (Forwarding Setup failed) For this Binding Update, the Mobile Router will
   MUST discard Binding Acknowledgements with codes '141' and '142', and log the information. '142'.

   For the same Binding Update, if the status is '140', then the Mobile
   Router
   SHOULD should send a similar Binding Update (implicit mode) to
   another Home Agent on the same home link.  If no Home Agent replies
   positively then the Mobile Router MUST refrain from sending any
   Binding Update with the 'R' bit Mobile Router flag set to any Home Agent on
   the home link, and log the information.

   For the same Binding Update, if the status is '143', then the Mobile
   Router
   SHOULD should send a similar Binding Update (implicit mode) to
   another Home Agent on the same home link.  If no Home Agent replies
   positively then Mobile Router SHOULD refrain from sending this
   Binding Update to any Home Agent on the home link, and MAY send
   Binding Updates in another mode (e.g.  explicitly include a prefix)
   to a Home Agent on the same home link.

   If the Mobile Router sent a Binding Update to Home Agent in any other
   mode than implicit mode (i.e.  the prefix field in the Binding Update
   list entry is not null) then the Mobile Router interprets only the
   error status '141' (Invalid Prefix) and '142' (Not Authorized for
   Prefix).  For this Binding Update, the Mobile Router will MUST discard
   Binding Acknowledgements with codes '140' and '143', and log the
   information. '143'.

   For the same Binding Update, if the status is set to '141', then the
   Mobile Router should send a similar Binding Update (same explicit
   prefix(es) or prefix lens) lengths) to another Home Agent on the same home
   link.  If no Home Agent replies positively then Mobile Router SHOULD
   refrain from sending this Binding Updates to any Home Agent on the
   home link.  At this point, Mobile Router MAY try try to obtain and own a
   prefix by the same means that it initially got attributed the Invalid
   Prefix in question.  Alternatively, Mobile Router MAY send Binding
   Updates in another mode (e.g.  implicit mode) to a Home Agent on the
   same home link.

   For the same Binding Update, if the status is set to '142', then the
   Mobile Router should send a similar Binding Update (same explicit
   prefix(es) or prefix lens) to another Home Agent on the same home
   link.  If no Home Agent replies positively then Mobile Router SHOULD
   refrain from sending this Binding Updates to any Home Agent on the
   home link.  Additionally, the Home Agent MUST stop advertising
   the respective prefix(es) in the mobile network with associated
   Router Advertisements, and modify its own forwarding information
   accordingly.  Following this, the Mobile Router MAY send Binding
   Updates in another mode (e.g.  implicit) to a Home Agent on the same
   home link.

   If at the end of this Error Processing procedure the Mobile Router
   has tried every available modes of sending Binding Updates and still
   has not received a positive Binding Acknowledgement (status valued 0) value
   between 0 and 127) for this Home Address from any Home Agent on its
   home link, then the Mobile Router MUST stop sending Binding Updates
   with the 'R' bit Mobile Router flag set for this Home Address and log the
   information.

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

5.5. Establishment of Bi-directional Tunnel

   Only when

   When a successful Binding Acknowledgement ('Status' field valued
   0) with status set to '2'
   (Mobile Router Binding Update accepted) is received will received, the Mobile
   Router set 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 Visisted Visited Link.  The bi-directional
   tunnel involves two virtual links [4]: [3]:  one virtual link has the
   address of the tunnel entry point as the Care-of Address of the
   Mobile Router and the tunnel exit point as the address of the
   Home Agent; the other virtual link has as tunnel entry point the
   Home Agent address and as tunnel exit point the Care-of Address
   of the Mobile Router.  Both addresses are unicast addresses.

   Packets sent by  All
   IPv6 traffic to and from the nodes in Mobile Network is sent through this
   bi-directional tunnel.

   A Mobile Router MAY limit the number of mobile network (including the Mobile
   Router) and addressed routers that attach to any nodes other than nodes in the
   its mobile network are encapsulated by Mobile Router and decapsulated by (the number of levels in the
   Home Agent.  Packets sent by any nodes other than nodes in the mobile
   network and addressed to nodes in the mobile network are encapsulated
   by the Home Agent and decapsulated by the Mobile Router.

   A Mobile Router MAY limit the number of mobile routers that attach to
   its mobile network (the number of levels in the nested aggregation) nested aggregation)
   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); see IANA numbers.

   Following the successful setup of the bi-directional tunnel on the
   Mobile Router, the forwarding information on the Mobile Router is
   updated such as to allow forwarding of packets as described above. hosts).  See [3].

5.6. Neighbour Discovery for Mobile Router

   A Mobile Router 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 any other link than the home 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 Mobile Router MAY use the received MUST NOT ignore Router Advertisements received on
   the
   interface connected to the home link, but only for logging and
   administrative purposes.  Only when that interface is connected to
   a visisted link, the Mobile Router uses information in the egress interface.  The received Router Advertisements MAY be
   used for purposes other than logging; this includes address configuration, setting up a default route and 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),
   interface) and '2' link-local and '5' site-local on any of its egress interfaces.  When
   in a visited network, the Mobile Router MUST NOT join any of the above
   multicast groups on the respective corresponding interface.

6. Home Agent Operation

   In order for a Mobile Router to operate correctly, the home agent Home Agent
   MUST satisfy all the requirements listed in Section section 8.4 of [1].

6.1. Prefix Table

   In some scenarios, the  The
   Home Agent might need to maintain a Prefix
   Table of Mobile Routers and MUST implement all the IPv6 prefixes owned by Mobile
   Routers. modes described in Section 5.2.

6.1. Data Structures

6.1.1. Binding Cache

   The Home Agent MUST maintain this table if the maintains Binding Cache Entries for each Mobile
   Routers operate under the implicit mode where they do not include any
   prefix information in Router
   that is currently registered with the Home Agent.  The Binding Updates.

   Each entry Cache
   is a conceptual data structure described in the Prefix Table conceptually contains the following
   fields:

    - detail in [1].

   The Home Address of Agent might need to store the Mobile Router. Network Prefixes
   associated with a Mobile Router in the corresponding Binding Cache
   Entry.  This field is required if the Binding Update (that created the
   Binding Cache Entry) contained explicit prefix information.  This
   information can be used as later to cleanup routes installed in explicit
   mode, when the
       key Binding Cache Entry is removed, and to maintain the
   routing table, for searching instance should the pre-configured prefix table.

    - routes be manually removed.

   The Mobile Network prefix Home Agent also stores the status of the Mobile Router associated with Flag 'R'
   in the Home Address. Binding Cache entry.

6.1.2. Prefix Table

   In some deployment scenarios it is important that may be necessary for the Home Agent
   prevents
   to prevent a misbehaving Mobile Router from claiming Mobile Network
   Prefixes mobile network
   prefixes belonging to another Mobile Router.  The Home Agent can
   prevent such attacks if it maintains the a Prefix Table and verifies the
   Prefix Information provided by the Mobile Router against the entries
   in the Prefix Table.  However, this verification is done only if the
   Binding Update contained explicit prefix information in the form of
   either the Mobile Network Prefix Option or the Mobile Network Prefix
   Length Option.

   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.

6.2. Mobile Network Prefix Registration

   The Home Agent processes the Binding Update as described in Section section
   10.3.1 of the Mobile IPv6 specification. 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 Binding Update MUST be authenticated by IPsec according to
       Section 5.1 of [1].

    -  The Home Registration (H) bit 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 Prefix
       to correspondent nodes (for route optimization).. optimization).

    -  If the Mobile Network Prefix Length option is present in
       the Binding Update, then there MUST be only one instance of
       this option in the Binding Update.  Also the Mobile Network
       Prefix Option MUST not NOT be present in the same Binding Update.
       Otherwise, the Home Agent MUST discard the Binding Update and
       send an ICMP Parameter Problem, Code 0, message to the Mobile
       Router
       Router.

   If the home agent Home Agent does not reject the Binding Update as described
   above, then it retrieves the Mobile Network Prefix information as
   described below.

    -  If a Mobile Network Prefix Length Option is present in the
       Binding Update, the Home Address in the Home Address destination
       option MUST be an extended Home Address.  In that case, the Mobile Network
       Prefix is obtained from that Home Address and the prefix length
       in the Mobile Network Prefix Length Option.

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

    -  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.  Otherwise  If the Home Agent fails to setup
       forwarding to all the prefixes listed in the Binding Update, then
       it MUST
       not 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 verfies verifies the prefix information with the Prefix
       Table and the check fails, the Home Agent MUST discard the
       Binding Update and send a Binding Acknowldegement with status set
       to 142 (Not Authorized for Prefix).

    -  If there are no options in the Binding Update, the Home Agent
       MUST figure out which
       uses manual pre-configured information to determine the prefixes are
       assigned to the Mobile Router
       from and for setting up forwarding for
       the Pre-configured Prefix Table. Mobile Network.  If there is no information that the home agent Home
       Agent can not
       find the correspondent Mobile Network prefix, it MUST reject use, it MUST reject the Binding Update and send a
       Binding Acknowledgement with the Status
       field status set to 143 (Prefix Information unavailable). (Forwarding Setup
       failed).

   If the Lifetime specified in the Binding Update is zero or the
   specified care-of Care-of address matches the home address for Home Address in the binding, Binding
   Update, then this is a request to delete the cached binding for
   the home address and specified mobile network prefixes. Mobile Network Prefixes.  The
   Binding Update is processed according to the procedure described in Section
   section 6.7.

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

   The Home Agent defends the Mobile Router's Home Address through Proxy
   Neighbor Discovery by multicasting onto the home agent like a Neighbor
   Advertisement message on behalf of the mobile router.  All fields in
   each such 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 [7], 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, Prefix, or update an existing
   bi-directional tunnel as described in Section 6.4 section 6.4.

6.3. Advertising Mobile Network Reachability

   In order to be able to receive packets meant for the Mobile Network, mobile network,
   the Home Agent advertises reachability to the Mobile Network. mobile network.  If the
   Home Link is configured with a prefix that is an aggregation and if
   the Mobile Network Prefix can be is aggregated under the Home Link that prefix, then the
   routing updates advertising reachability to the Mobile
   Network mobile network are
   sent only on the Home Link.  If the Home Agent is the only default
   router on the Home Link, routes to the Mobile Network Prefix
   gets get
   aggregated naturally under the Home Agent and the Home Agent does not
   have to do anything special.

   If the Home Agent receives routing updates through a dynamic routing
   protocol from the Mobile Router, those routes are propogated propagated by
   the routing protocol running on the Home Agent on the relevant
   interfaces.

6.4. Establishment of Bi-directional Tunnel

   The establishment and operation of the bi-directional tunnel is
   implementation specific.  However, all implementations MUST be
   capable of the following operations.

    -  The Home Agent can tunnel packets meant for the Mobile Network
       Prefix 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 fowards 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. 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.

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, with the following enhancements.

   The Home Agent sets the status code in the Binding Acknowledgement
   to '0' (Binding '2' (Mobile Router Binding Update accepted) in order to indicate
   to the Mobile Router that it accepted the Binding Update, set up the
   tunnel endpoint and the necessary forwarding information.

   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 in the Binding Acknowledgement to '143' (Mobile Network Prefix 143 (Forwarding Setup
   failed) if it is unable to determine the information unavailable) in order needed to indicate setup
   forwarding for the Mobile Router that the received Home Address in the
   Binding Update does not match any prefix entry in the pre-configured
   prefix table. Network.  This is used in the Implicit case 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.  This Binding
   Update MUST be secured as described in [3].  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.

7. Extended Home Network

   With MIPv6, the Home Network is generally a physical network
   interconnecting the Home Agents, and the Mobile Nodes that are at
   Home.  The Network Mobility concept introduces the extended Home
   Network that aggregates the Home Network(s) and the Mobile Network(s)
   in a single, shorter prefix.

   For most practical situations, it is expected that:

    -  There is a single Home Network and multiple Mobile Networks

    -  The Home Network and Mobile Network prefixes are tailored to
       allow for IPv6 Stateless Address Autoconfiguration with typical
       interface identifier length for the type of interface.

    -  The prefix length of the extended Home Network is shorter than
       the Home Network and the Mobile Network prefixes, since it is an
       aggregation.

    -  The Home Agents collectively advertise the extended Home Network
       aggregation only.  The dichotomy of the extended Home Network is
       kept within the Home Agents and the Mobile Nodes, as opposed to
       advertised by means of routing protocols to other parties.

   The Home Network is configured on a physical interface as defined in
   MIPv6.  A Mobile Router may own a Home Address that is built out of
   the Home Network prefix and use it for Nemo registration and to come
   back Home.  In that case, the Home Network Prefix and prefix length
   are used in the Binding Update.

   A Mobile Router owns one or several Mobile Networks.  It may form
   extended Home Addresses from the prefixes of its Mobile Network(s)
   and register them to the Home Agent using the extended Home Network
   prefix and prefix length.  An extended Home Address may be used for
   only one registration that it identifies uniquely, regardless of the
   Home Agent, as for normal Home Addresses.

   An extended Home Network may be configured on a virtual or a physical
   interface of the Home Agent.  It is partitioned in Mobile Networks
   and Home Networks.  If the extended Home Network is configured on a
   physical Network, a Mobile Router that registers using an extended
   Home Address may come back home by:

    -  Autoconfiguring a Care-of Address from the Home Network and
       providing Proxy Neighbor Discovery for its Mobile Network
       Prefixes

       or
    -  Attaching directly by its Ingress Link if it has only one of
       them.

   Multihoming, and in particular the associated coordination of
   the Home Agents, is out of the scope of this document.  Yet, this
   specification does not prevent that:

    -  More than one Mobile Network may be connected to a Mobile Router

    -  A Mobile Network Prefix may be shared between Mobile Routers and
       registered by some of them

    -  An Mobile Network Prefix may be registered several times to
       several Home Agents using different (extended) Home Addresses for
       each registration.

   This description is open to a:

    -  Mobile Router autoconfiguring one or several extended Home
       Address to carry out many registrations in parallel.  It owns the
       full prefix so it may use any address in there for a MNLP based
       registration, and several of them for multihoming.

    -  Mobile Node autoconfiguring one or several Care-of Addresses from
       the Mobile Network Prefix

    -  Mobile Host autoconfiguring one or several Home Addresses from processes the de-registration BU, it deletes the Binding
   Cache Entry for the Home Network. Mobile Nodes' Router's Home Addresses may still be configured manually from Address and stops proxying
   the Home Network Prefix as Address.  This is described in detail in the Mobile IPv6.

8. IPv6
   specification [1].

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

7. 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 a intra-doamin intra-domain routing
   protocol like RIPng [6] [10] and OSPF [7] [11] 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.

   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 propogated 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 very important so
   that IPv6 prefixes specific to the Mobile Network do not leak into
   the visited network.  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 messages after decapsulation MUST NOT
   be forwarded to another link by either the Mobile Router or the Home
   Agent.

   When the Home Agent receives the encapsulated routing protocol
   message, it processes the inner packets and updates its routing table
   accordingly.  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
   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 be careful in
   including the same mobile network prefixes in the Binding Update to
   the HA and in the routing protocol updates.  The HA 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 the same prefix information in both the
   Binding Update and the routing protocol update is redundant.

   The tunneled routing messages MUST be authenticated and encrypted by
   using IPsec ESP [5] [4] in tunnel mode.

9. Use of IPsec to protect

8. Security Considerations

   All signaling messages between the Signaling Messages Mobile Router and the Home Agent
   MUST be authenticated by IPsec [5].  The use of IPsec to protect to
   Mobile IPv6 signaling messages is described in detail in the HA-MN
   IPsec specification [3].  This [2].  The signaling messages described in this
   document
   does just extend Mobile IPv6 messages and do not require any
   changes or anything more that to what is described in the HA-MN IPsec specification.

10. Security Considerations

   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
   the Mobile Router's current Care-of address.  The source address of
   the inner IPv6 header MUST belong to the Mobile Network Prefix owned
   by the Mobile Router.

   When the Mobile Router is running a dynamic routing protocol as
   described in Section 8, section 7, it injects routing update messages into the
   Home Link.  The Home Agent MUST verify that the Mobile Router is
   allowed to send routing updates before processing the messages and
   propagating the routing information.

   Please refer to the Mobile IPv6 specification [1] for security
   considerations when the Mobile Router operates as a Mobile Host.

11.

9. IANA Considerations

   This document defines two new Mobility Header Options.

    -  Mobile Network Prefix Option Option.

    -  Mobile Network Prefix Length Option.

   These options are described in section 4.3 and section 4.4.  The type
   values for these options need to assigned from the same space used by
   the mobility options defined in [1]

12.

10. 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 earlier proposals.

13.

11. Acknowledgements

   We also 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 Leinumeller Leinmueller for many insightful remarks and implementation
   aspects.

Normative References

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

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

   [3]

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

   [4]

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

   [5]

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

   [6] G. Malkin

   [5]  S. Kent and R. Minnear. RIPng for IPv6. RFC 2080, IETF. January
       1997.

   [7] R. Coltun, D. Ferguson and J. Moy. OSPF Atkinson. Security Architecture for IPv6. the Internet
        Protocol. RFC 2470, 2401, IETF.
       December 1999.

   [8] November 1998.

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

   [9]

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

   [10] C. Perkins, ed. IP

Informative References

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

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

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

   [11] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv4. IPv6. RFC 3344, 2470,
        IETF.
       August 2002. December 1999.

A. Examples of 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) [2]. [8].  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.

   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.

   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 |
        +-------+      ++------------------+      +-------+
       3::2->6::2
       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

B. Changes from Previous Version

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

    -  Clarified that Router flag must be set in the Proxy Neighbor
       Advertisement sent for a Mobile Router by the Home Aagent.
       (Issue 1).

    -  Clarified that if the Router flag in the Binding Update is set,
       then the HA should assume that the Mobile Router wants to be
       treated as a mobile node.  (Issue 3).

    -  Added text to make it clear that the Home Agent must perform
       ingress filtering on all packets reverse tunneled by the Mobile
       Router.  (Issue 3).

    -  Extended Home Network concept has been removed from this
       document.  (Issue 5).

    -  Added text to clarify differences between Implicit mode and
       running a dynamic routing protocol.  (Issue 6).

    -  Clarified that Prefix Table is used only in explicit mode.  In
       Implicit mode the Prefix Table is not used.  (Issue 7 and 12).

    -  Added text to specify the Home Agent must support all modes.  The
       Mobile Router needs to support only one mode.  (Issue 11).

    -  Added text to support interoperability between a Mobile Router
       and a legacy MIPv6 Home Agent.  (Issue 15).

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
        Espace Technologique de St
        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

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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