Network Mobility                                              P. Thubert
Internet-Draft                                                     Cisco Systems
Expires: September 30, 2004 April 5, 2005                                       R. Wakikawa
                                                         Keio University
                                                          V. Devarapalli
                                                                   Nokia
                                                           April 1,
                                                         October 5, 2004

                        NEMO Home Network models
                 draft-ietf-nemo-home-network-models-00
                 draft-ietf-nemo-home-network-models-01

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

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

   This Internet-Draft will expire on September 30, 2004. April 5, 2005.

Copyright Notice

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

Abstract

   This paper documents some usage patterns and the associated issues
   when deploying a Home Network for Nemo enabled NEMO-enabled Mobile Routers,
   conforming the NEMO Basic Support draft [7]. [8].  The aim here is
   specifically to provide some examples of organization of the Home
   Network, as they were discussed in the NEMO and NEMO
   Design related mailing lists.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and concepts . . . . . . . . . . . . . . . . . . .  4
   3.  General Expectations . . . . . . . . . . . . . . . . . . . . .  6  5
   4.  Extended Home Network  . . . . . . . . . . . . . . . . . . . .  7  6
     4.1   Configuration  . . . . . . . . . . . . . . . . . . . . . .  6
     4.2   Returning Home . . . . . . . . . . . . . . . . . . . . . .  7
     4.3   Applicability  . . .  8 . . . . . . . . . . . . . . . . . . .  7
   5.  Aggregated Home  . . . . . . . . . . . . . . . . . . . . . . .  9  8
     5.1   Configuration  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2   Returning Home . . . . . . . . . . . . . . . . . . . . . .  9
       5.2.1   Returning Home by egress . . . . . . . . . . . . . . .  9
       5.2.2   Returning Home by ingress  . . . . . . . . . . . . . . 10
     5.3   Applicability  . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 11
   7.  Mobile Home
     6.1   Configuration  . . . . . . . . . . . . . . . . . . . . . . 11
     6.2   Applicability  . . . 13
   8.  Changes from version 00 to 01 . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . 12
   7.  Mobile Home  . . . . . . . . . . . . . . . . . . . . 16
       References . . . . . 13
     7.1   Configuration  . . . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . 13
     7.2   Applicability  . . . . . . . . . . . . . . . . . . . . . 17
   A.  Returning Home emulation in the virtual case . 14
   8.  Changes  . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19

1. Introduction

   This document assumes that the reader is familiar with Mobile IPv6 as
   defined in [6], and with the concept of Mobile Router defined in the
   NEMO terminology document [9].

   Four different organizations of the Home Network including a
   hierachical construction are documented:

   Extended Home Network: In this disposition, the Home Network is but
      one subnet of a larger aggregation that encompasses the Mobile
      Networks, called extended . . . . . . . . . . . 16
     8.1   Changes from version 00 to 01  . . . . . . . . . . . . . . 16
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   A.  Returning Home Network. When at Home, a Mobile
      Router performs normal routing between emulation in the Home Link virtual case . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20

1.  Introduction

   This document assumes that the
      Mobile Networks.

   Aggregated Home Network: In this disposition, the Home Network
      actually overlaps reader is familiar with the Mobile Networks. When at Home, a Mobile
      Router acts IPv6 Mobility
   as a bridge between defined in [7], with the Home Link NEMO Basic Support [8] and with the Mobile
      Networks.

   Virtual Home Network: In this disposition, there is no physical Home
      Link at all for the Mobile Routers to come back Home to.

   Mobile Home Network: In this disposition, there is a bitwise
      hierarchy of Home Networks. A global Home Network is advertised to
      the infrastructure by a head Home Agent and further subnetted into
      Mobile Networks. Each subnet is owned by a Mobile Router that
      registers it in a NEMO fashion while acting as a Home Agent for
      that network.
   terminology document [10].

   In all cases, the Home Agents collectively advertise only the
   aggregation of order to read this document properly, the Mobile Networks.  The dichotomy is kept within distinction between the
   concepts of Home Agents Link and the Mobile Routers, as opposed to advertised by means of routing protocols to other parties.

   Also, it Home Network must be very clear.  A Home
   Link is valid for a Mobile Router physical or a virtual Link, attached to register using a Home Agent.  A
   Home Network is an address
   from one of its own NEMO-Prefixes in all three cases.

   The examples provided here aim at illustrating aggregation that can be further subnetted.  As a
   result, the NEMO Basic Support
   draft [7] but Home Network is not necessarily contained on a Home Link.
   In fact, the Mobile Network Prefixes are by no mean at limiting its scope subnets of application.

2. Terminology and the Home Network.
   How the two concepts

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL relate in this document are to be
   interpreted a given deployment depend on the
   organization of the Home Network, as described in RFC2119 [5].

   The following terms used in this document are defined in below.

   Four different organizations of the IPv6
   Addressing Architecture document [4]:

      link-local unicast address

      link-local scope multicast address

   The following terms used in this document Home Network including a
   hierarchical construction are defined in the mobile
   IPv6 specification [6]:

      home agent (HA)

   The following terms used in documented:

   Extended Home Network: In this document are defined in disposition, the mobile
   network terminology document [9]:

      mobile router (MR)

      mobile network

      mobile host (MH)

   This draft uses Home Network is only
      one subnet of a larger aggregation that encompasses the following additional or modified terminology: Mobile
      Networks, called extended Home Link: The link attached to Network.  When at Home, a Mobile
      Router performs normal routing between the interface at Home Link and the
      Mobile Networks.  More in Section 4.

   Aggregated Home Agent on
      which Network: In this disposition, the Home Prefix is configured. The interface can be Network
      actually overlaps with the Mobile Networks.  When at Home, a
      virtual interface, in which case
      Mobile Router acts as a bridge between the Home Link is a virtual Home
      Link. and the
      Mobile Networks.  More in Section 5.

   Virtual Home Network: The Network formed by the application of the In this disposition, there is no physical Home
      Prefix on
      Link at all for the Mobile Routers to come back Home Link. With NEMO, the concept of to.  More in
      Section 6.

   Mobile Home Network Network: In this disposition, there is
      extended as explained below.

   Home Address: With Mobile IPv6, a bitwise
      hierarchy of Home Address is derived from the Networks.  A global Home Network prefix.  This is generalized in NEMO, with some
      limitations: A Home Address can be either derived from advertised
      to the infrastructure by a head Home
      Network or from one of the Agent and further subnetted
      into Mobile Router's NEMO-prefixes.

   MRHA Tunnel: The bi-directional tunnel between Networks.  Each subnet is owned by a Mobile Router and
      its
      that registers it in a NEMO fashion while acting as a Home Agent
   Mobile Aggregated Prefix: An
      for that network.  More in Section 7.

   In all cases, the Home Agents collectively advertise only the
   aggregation of NEMO-Prefixes.

   Aggregated Home Network: the Mobile Networks.  The dichotomy is kept within the
   Home Network associated with a Agents and the Mobile
      Aggregated Prefix. This Aggregation is advertised Routers, as a subnet on opposed to advertised by means
   of routing protocols to other parties.

   The examples provided here aim at illustrating the NEMO Basic Support
   draft [8] but do not aim at limiting its scope of application, and
   additional cases may be added in the Home Link, future.

2.  Terminology and thus used concepts

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
   interpreted as Home Network for NEMO purposes.

   Extended Home Network: described in RFC2119 [1].

   The network associated with following terms used in this document are defined in the aggregation IPv6
   Addressing Architecture document [5]:

      link-local unicast address

      link-local scope multicast address

   Most of
      one or more Home Network(s) the mobility related terms used in this document are defined
   in the Mobility Related Terminology document [6] and Mobile Network(s). As opposed to in the Mobile
   IPv6 Home Network that is a subnet, the (MIP6) specification [7].

   Additionally, some terms were created or extended Home for NEMO.  These
   specific terms are defined in the Mobile Network is an aggregation and is further subnetted.

   Virtual Terminology document
   [10]:

      Home Network: The Link

      Home Network associated with a Virtual
      Network. The Extended

      Home Network and the Address

      MRHA Tunnel

      Mobile Aggregated Prefix

      Aggregated Home Network
      can be configured as

      Extended Home Network

      Virtual Home Network. Network

      Mobile Home Network: A Mobile Network that is also a Home Network.
      The MR that own the NEMO-Prefix acts as a Home Agent for it.

3.  General Expectations

   With  Mobile IPv6, the Home Network is generally a physical network
   interconnecting the Home Agents, and the Mobile Nodes that are at
   Home.  NEMO extends the concept of Home so that it is not only a flat
   subnet composed of Home Addresses but an aggregation that is itself
   subnetted in mobile and Home Networks.  This aggregation is still
   referred to as Home.

   As an example, say that the aggregation has a global routing prefix
   of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n +
   m = 64).

   Say that a Mobile Router, MR1, owns the NEMO-Prefix MNP A:B:C:1::/64: With basic NEMO, NEMO
   Basic Support, and depending on the deployment, MR1 may register
   using a Home Address from the Home network, A:B:C:0::1, say, or a
   Home Address, A:B:C:1::1, say, from one of its NEMO-Prefixes. MNPs.

   In a given deployment, one subnet may be reserved for the Home Link
   (say A:B:C:0::/64) while the others are attributed to Mobile Routers
   as Mobile Networks (as A:B:C:1::/64 for MR1).  Another approach could
   be to configure the Aggregation of Mobile Networks as the subnet on
   the Home Link, and let the Mobile Routers manage the overlapping
   networks.  Finally, the aggregation could be configured on a virtual
   network, with no physical Home Link at all, in which case Home means
   topologically and administratively close to the Home Agent that owns
   the virtual network.

   The following sections provide additional information on these forms
   of Home Network: Network.

4.  Extended Home Network

4.1  Configuration

   One simple approach can be is to reserve one or several subnets from an
   aggregation for the Home Link, and to use the other subnets as
   NEMO-Prefixes. MNPs.
   In that case, the Home Network and the Mobile Networks do not
   overlap.  The aggregation is called an extended Extended Home Network. Network and
   depicted in Figure 1.

                       |
             route     v  /48                        A:B:C::/48

                       HA
                       | /64                         A:B:C:0::/64
            --+-----+--+- . -+- . -+--
              |     |        |     |
              MR1   MR2      MRi   MRN
              /64   /64      /64   /64      A:B:C:i::/64  0 < i <= N

                            extended

                            Extended Home Network
          <----------------------------------------------------------->

            Home Net      Mobile Net    Mobile Net   ...   Mobile Net
          <------------><------------><------------> ... <------------>

                    Figure 1: Extended Home Network

   In that configuration:

   o  There is one physical Home Network and multiple Mobile Networks

   o  The Home and the NEMO-prefixes MNPs are tailored to allow for IPv6 Stateless
      Address Autoconfiguration with typical interface identifier length
      for the type of interface (can be for example /
      64). /64).

   o  The prefix length of the extended Extended Home Network is shorter than
      that of the Home Network and the NEMO-prefixes, MNPs, since it is an aggregation
      (can be for example /48).

   o  The Mobile Routers are assigned individually a Home Address from
      the Home Network and use is to register their NEMO-Prefix(es). MNP(es).  In that
      case, the Home Agent performs DAD in the Home Network as
      prescribed by Mobile IPv6 for the Home Addresses.

   o  Alternatively, a Mobile Router could also form a Home Address from
      one of its prefixes and use it to register, performing its own DAD
      on its ingress network.

4.1

4.2  Returning Home

   In the extended Extended Home Network model, the Home Network is configured on
   a physical interface of the Home Agent, the Home Link.

   A Mobile Router returns Home by connecting directly to the Home Link,
   and dropping the MRHA tunnel.

   If the Home Address of the Mobile Router is derived from one of its
   Mobile Networks, Network Prefixes, then the MR may connect to the Home Link
   using an egress interface and autoconfigure an address on the Home
   Link.  The MR recognizes the prefix of its Home Agent in order to
   decide that it is Home.  Note that in that case the Home Address does
   not match the Home Prefix.

   When at Home, home, the Mobile Router ensures the connectivity of the
   Mobile Network using standard router operations.

   In particular, if the HA has the necessary information to continue
   routing to the NEMO-Prefixes MNPs in the absence of registration, for instance if
   the Home Address of the Mobile Router is derived from the Home
   Network, and if the HA uses a static route to the
   NEMO-Prefix(es) MNP(es) via that
   address, then the participation of the MR to the Home IGP is not
   required.

   But in the general case, when the MR is at Home, it resumes IGP
   operations on the Home Link in order to advertise its Mobile
   Networks.

   Alternate procedures for ensuring the connectivity of the Mobile
   Networks when at Home home are described in Section 6. In Particular,

4.3  Applicability

   The extended Home Network keeps the MIP6 concept of a Home Network
   for both Mobile Nodes and Mobile Routers to take their Home Address
   from.  Since there is no overlap between the prefixes that are
   affected to MNPs and prefix(es) that are dedicated to the Home Link,
   it is possible for MNs and MRs to coexist with that model.

5.  Aggregated Home

5.1  Configuration

   One other approach is to consider that the Aggregation of all the
   NEMO-prefixes
   MNPs is used plainly as the Home Network, refered referred to as the
   Aggregated Home Network.  This means that the Mobile Aggregated
   Prefix is configured on the Home Link and advertised by the Home
   Agent as a
   subnet. subnet, as depicted in Figure 2.

                      HA
                       | /56                       Aggreg /56
            --+-----+--+- . -+- . -+--
              |     |        |     |
             MR1   MR2      MRi   MRN
          ------  ------  ------ ------
              /64   /64     /64   /64         Aggreg|i /64  0 < i <= N

                            Aggregated Home
                            ==   Home Net
          <----------------------------------------------------------->

           Mobile Net    Mobile Net    Mobile Net    ...   Mobile Net
          <------------><------------><------------> ... <------------>

   Note: a Mobile Router coming

                       Figure 2: Aggregated Home sees overlapping prefixes between
   the ingress and the egress interface and some specific support may be
   needed.

   A node on the Home Link will compute computes that the Aggregated Home Network is
   actually a subnet on the Home Link and may use it for
   autoconfiguration purposes.  Such a node may also install a connected
   route to the Aggregated Home Network over the Home Link.

   As a result, unless the node has a better (longest match) route to a
   given NEMO-Prefix, MNP, it will lookup all MNNs using Neighbor Discovery over the
   Home Link.

   Thus, the Home Agent MUST intercept all the packets to the MNNs on
   the registered prefixes.  In order to do so, the Home Agent MAY might
   perform ND proxying for all addresses in all registered Mobile
   Network Prefixes, and protect the NEMO-Prefix MNP space from autoconfiguration by
   uncontrolled visitors on the Home Link.

   Alternatives based on a routing protocol or ICMP redirect may apply
   in some cases.

5.1

5.2  Returning Home

   The Aggregated Home Prefix is configured on a physical interface of
   the Home Agent, the Home Link.  As a consequence, the Home Agent has
   a connected route to the Aggregated Home Network over the Home Link.

   A Mobile Router returns Home by connecting directly to the Home Link,
   and dropping the MRHA tunnel.  The Mobile Router recognizes its Home
   Link by a prefix match with its Home Agent.

   Note that it must expect a shorter prefix than that of its Mobile
   Networks, even if its Home Address is formed out of one of its NEMO-Prefixes, MNPs,
   but that the Home Address matches the Home Network Prefix.

   Also, Note that in that case, it makes sense for a Mobile Router to
   register using a Home Address from one of its own MNPs.  Taking the
   Home Address from its own range guarantees the unicity of the suffix.
   That unicity can be checked by the MR on its ingress network using
   DAD.

5.2.1  Returning Home by egress

   A Mobile Router coming Home via its egress interface sees overlapping
   prefixes between the ingress and the egress interface and some
   specific support may be needed:

   When a Mobile Router connects to the Home Link using its egress
   interface, it MAY might set up a bridge between its ingress interface(s)
   and the Home Link.

   Alternatively, the Mobile Router MAY might perform ND proxying for all
   addresses in its NEMO-Prefixes, MNPs, between the egress and the related ingress
   interface.  Since the prefixes on the egress and ingress interfaces
   are overlapping, routing is disallowed.

                    HA
                    | /56                         Aggreg /56
         --+-----+--+- . -+- . -+--
           |     |        |     |
          MR1   MR2      MRi   MRN
        ------  ------  ------ ------
           /64   /64     /64    /64               Aggreg|i /64  0 < i <= N

             Figure 3: Bridging between egress and ingress

5.2.2  Returning Home by ingress

   Alternatively, if the MR has a single ingress Interface, the Mobile
   Router may use the Mobile Link NEMO-Link to connect to the Home Link, merging the
   two links in a single consistent network.

                    HA
                    | /56                         Aggreg /56
          --+-----+--+- . -+- . -+--
           /64   /64     /64    /64               Aggreg|i /64  0 < i <= N
        ------  ------  ------ ------
           MR1   MR2      MRi   MRN
            |     |        |     |

           Figure 4: Merging the Home and the Mobile Networks

   This fits the connected route model, since the Aggregated Home is
   truly located on that network.  Note that in that case, it makes
   sense for a Mobile Router to register using a Home Address from one
   of its own MNPs.  .

5.3  Applicability

   With this model, there is no specific space for independent nodes as
   any address in the aggregation belongs to a MNP, and thus to a Mobile
   Router.  This configuration excludes the cohabitation with MIP6 MNs
   on the Home Link.

   A MR that is at Home must own an address from the aggregation on its
   egress interface and  an address from its MNP -a subnet of that
   aggregation- on its ingress interface.  A pure router will reject
   that configuration, and the MR needs to act as a bridge to enable it.
   In order to deploy the aggregated Home Network model, one must check
   whether that support is available in the MRs if returning Home is
   required.

6.  Virtual Home Network

6.1  Configuration

   The Home Link can be configured on the Home Agent on a virtual link,
   in which case there's no physical Home Link for Mobile Routers to
   return Home or for Home Agents to discover each others and perform
   the ND level interactions as described in Mobile IPv6. [6] [7]

                    /48                       eg: A:B:C::/48
                    HA
                    | /64                         A:C:C:E::/64
         --+-----+--+- . -+- . -+--
           |     |        |     |
           MR1   MR2      MRi   MRN
           /64   /64      /64   /64               A:B:C:i::/64  0 < i <= N

                     Figure 5: Virtual Home Network

   The Extended Home network Network and the Aggregated Home network Network models can
   be adapted for virtual links. There is no change in the way Home
   Addresses are allocated.

   As in the case of a physical link, the Home Address of a Mobile
   router is can be constructed based on a dedicated subnet of the Home
   Prefix or one of the prefixes of its Mobile Network(s). MR MNPs.

   Note that since the Home Address is never checked for DAD, it makes
   the configuration easier to take it from the MNP as opposed to a
   specific subnet.

   There are certain advantages to making the Home Link a virtual link:

      A virtual link may not experience any disruption related to
      physical maintenance or to hardware problems, so it is more
      available than a physical link.  The high availability of the Home
      Link is critical for the mobility service.

      The Home Agent does not have to defend the Mobile Router's Home
      Address through Proxy Neighbor Discovery.  The Home Agent does not
      also have to perform Duplicate Address Detection (DAD) for the
      Mobile Router's Home Address when it receives a Binding Update
      from the Mobile Router.

      The Mobile Router does not have to implement the Returning Home
      procedure (section 11.5.4 of Mobile IPv6. [6]).  [7]).

   In order for a Mobile Router to emulate returning Home, it can
   connect to one or more access link(s) configured for that purpose on
   the Home Agent.  The Mobile Router, after connecting to the access
   link, SHOULD not send any routing protocol updates on the egress
   interface because the routing information from the Mobile Router
   might adversely affect IPv6 route aggregation on the Home Network.
   However, the Mobile Router must register its binding as if it was
   accessing a foreign link.

   There are also some drawbacks to the virtual Home Link approach:

      There can be only one Home Agent since Mobile IPv6 relies on
      Neighbor Discovery on the Home Link for other HA discovery and for
      Duplicate Address Detection.

      The Home Agent must maintain a Binding Cache entry for a Mobile
      Router and forwarding state for its Mobile Network even when the
      Mobile Router is directly connected to it.  All traffic to and
      from the Mobile Network is sent through the bi-directional tunnel
      regardless of the Mobile Router location.  This results in a
      tunneling overhead even though the Mobile Router is connected to
      the Home Network.

   Some solutions can be proposed in order to perform an equivalent of
   returning Home on a virtual Home Network.  One such approach is
   sketched in appendix as an illustration.

6.2  Applicability

   At some point in the future, NEMO basic support may be extended to
   operate fully at L3 for instance if the HAHA protocol [11] gets
   standardized and deployed.  Until then, NEMO operations still inherit
   from mobile IPv6 [7] for the HA to HA communication, which is
   basically based on Neighbor Discovery extensions over the Home Link.
   Making that link virtual bars the deployment of multiple Home Agents,
   which may be desirable for reasons of load balancing.  Please refer
   to the NEMO multihoming issues [12] draft for more on this.

   Yet, for a deployment where a single HA is enough, making the Home
   Link virtual reduces the vulnerability to some attacks and to some
   hardware failures, while making the HA operation faster.

   One should check with the product specifications of an HA to see
   whether the implementation actually supports a Virtual Home Network,
   and if so, whether in that cases, it is optimized for faster DAD-less
   bindings.

7.  Mobile Home

7.1  Configuration

   In this disposition, there is a bitwise hierarchy of Home Networks.
   A global Home Network is advertised to the infrastructure by a head
   Home Agent(s) and further subnetted into Mobile Networks.  As a
   result, only the Home Agent(s) responsible for the most global
   (shortest prefix) aggregation receive all the packets for all the
   NEMO-prefixes,
   MNPs, which are leaves in the hierarchy tree.

   Each subnet is owned by a Mobile Router that registers it in a NEMO
   fashion while acting as a Home Agent for that network.  This Mobile
   Router is at Home at the upper level of hierarchy.  This
   configuration is referred to as Mobile Home.

   An example of that is the Cab Co configuration.  Say a Taxi Company
   owns a /32 prefix.  This prefix is advertised at a fixed point, the
   Headquarters say.  Regional offices are deployed around the world.
   Even though these regional offices are relatively stable in terms of
   location and prefix requirement -say this changes every few years-
   making them mobile allows a simpler management when a move has to
   take place, or should the ISP service change. Finally, each regional
   office owns a number of taxis, each one equipped with a mobile router
   and an associated /64 prefix.

   To illustrate this, here is a possible addressing scheme:

         global Home Network   CAB:C0::/32  owned by HQ
    <------------------------------------------------------------------->

      HQ extended Home Net              Mobile Home for SFO office
          (casa)
      CAB:C0:CA5A::/48                          CAB:C0:5F0::/48
    <----------------------------> ... <-------------------------------->
                                                       |
      Home for offices        HQ                       |
     CAB:C0:CA5A:CA5A::/64    MN                       |
    <----------------------><---->                     |
     CAB:C0:CA5A:CA5A::CA5A                            |
     CAB:C0:CA5A:CA5A::CA5B                            |
     are HAs on link with for each office a route like |
                                                       |
     CAB:C0:CA5A:CA5A::5F0    <---------------------- via
       is the Home addr
       of SFO office

                Figure 6:  CAB Company HQ configuration

   Finally, each regional office owns a number of taxis, each one
   equipped with a mobile router and recursively for an associated /64 prefix.

   For each Office, say San Francisco (SFO) as an example:

        Mobile Home Network CAB:C0:5f0::/48 CAB:C0:5F0::/48  owned by SFO office
    <------------------------------------------------------------------>

      HQ

      SFO Home Network             Mobile Networks for taxis
        for offices taxis        <---------------------...--------------------->
     CAB:C0:5F0:5F0::/64  CAB:C0:5F0:CAB1::/64     CAB:C0:5F0:....::/6
    <-------------------><-------------------> ... <------------------->
     CAB:C0:5F0:5F0::5F0           |
     is HA on link with for        |
     each taxi a route like        |
                                   |
     CAB:C0:5F0:5F0::CAB1 <------ via
       is the Home addrSsync
       of CAB 1

             Figure 7:  CAB Company regional configuration

   Note that the hierarchy occurs at a configuration level and may not
   be reflected in the actual connection between nodes.  For instance in
   the Cab Co case, cabs are roaming within the city, each one attaching
   to a different hot spot, while the regional office is connected to
   the infrastructure using some ISP connection.

   But it is also possible to reflect the organizational hierarchy in a
   moving cloud of Mobile Router.  If a Mobile Home Agent acts as
   root-MR for a nested configuration of its own MRs, then the
   communication between MRs is confined within the nested structure.

   This can be illustrated in the case of a fleet at sea.  Say that now
   SFO is a communication ship of a fleet, using a satellite link to
   join the infrastructure, and that the cabs are Mobile Routers
   installed on smaller ships, equipped with low range radios.

   If SFO is also the root-MR of a nested structure of cabs, the
   communication between cabs is relayed by SFO and does not require the
   satellite link.  SFO recursively terminates the nested tunnels to the
   cabs and reencapsulates all the packets between the nested cloud and
   correspondents in the infrastructure in a single tunnel to CA5A, this
   providing for nested NEMO Route Optimization.

7.2  Applicability

   This complex topology applies to large distributed fleet, mostly if
   there is a single interchange point with the internet (e.g.  a NAT or
   a socks farm) where the super HA could be located.

   One specific benefit is that when 2 MRs travel together with a common
   HA, the traffic between the 2 is not necessarily routed via the
   infrastructure, but can stay confined within the mobile cloud, the
   Mobile Home Agent acting as a rendez-vous point between the MRs.
   This applies particularly well for a fleet at sea when the long haul
   access may be as expensive as a satellite link.

8.  Changes

8.1  Changes from version 00 to 01

      Removed terminology (moved to the Nemo terminology draft).

      Added Mobile Home Section an applicability statement for all documented cases

9.  Acknowledgements

   The authors wish to thank:

   Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick
   Wetterwald and Alexandru Petrescu for their contributions.

10  References

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

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

   [2]

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

   [3]

   [4]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [4]

   [5]   Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

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

   [6]   Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
         3753, June 2004.

   [7]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
         2003.

   [7] RFC 3775, June 2004.

   [8]   Devarapalli, V., "Nemo "Network Mobility (NEMO) Basic Support
         Protocol",
         draft-ietf-nemo-basic-support-02 draft-ietf-nemo-basic-support-03 (work in progress), December
         2003.

   [8]
         June 2004.

   [9]   Ernst, T., "Network Mobility Support Goals and Requirements",
         draft-ietf-nemo-requirements-02 (work in progress), February
         2004.

   [9]

   [10]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-01 (work in progress), February
         2004.

   [10]

   [11]  Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home
         Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
         in progress), February 2004.

   [12]  Ernst, T., "Analysis of Multihoming in Network Mobility
         Support", draft-ietf-nemo-multihoming-issues-00 (work in
         progress), July 2004.

Authors' Addresses

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

   Phone: +33 4 97 23 26 34
   EMail: pthubert@cisco.com

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

   EMail: ryuji@sfc.wide.ad.jp

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

   EMail: vijay.devarapalli@nokia.com

Appendix A.  Returning Home emulation in the virtual case

   When a Home Link is virtual, all traffic to and from the Mobile
   Network is sent through the bi-directional tunnel even at the Home
   Link.  This section describes one possible mechanism that extends
   basic
   NEMO Basic Support to eliminate this tunneling overhead.

   Although the Home Link is virtual, the Home Agent has at least one
   physical link to communicate with the external world.  One or several
   of such links, called the virtual Home Access Links, are conceptually
   associated with the virtual Home Link and considered as part of Home.

   When accessing one of its virtual Home Access Links, a Mobile Router
   autoconfigures a Care-of Address from a Router Advertisement as it
   would do on any visited link, in order to perform the next binding
   flow.

   If the Mobile Router is configured to recognize the virtual Home
   Access Links as part of Home, it deregisters by sending a Binding
   update with null lifetime sourced at the CareOf.  Alternatively, the
   Home Agent may indicate that the MR has moved to the virtual Home
   Access Links as a status code in the binding acknowledgement.  The
   status code implies that Home Agent successsful de-register the
   binding at the virtual Home Access Link.  Detection of the virtual
   Home Access Links is achieved by a prefix comparison(s) between the
   care-of address and the prefix(es) on the virtual Home Access
   Link(s).

   With both approaches, the result of the binding flow is a
   deregistration.  Consequently, both the Mobile Router and the Home
   Agent disable the bi-directional tunnel.  At that point, the Home
   Agent configures its forwarding in order to reach the Mobile Router
   and its mobile networks at Home.  For instance, this may take the
   form of a route to the Mobile Network prefixes via the MR Home
   Address, and a connected host route to the MR Home Address via the
   virtual Home Access link.

   After successful binding de-registration, the Mobile Router MUST
   receive packets meant to the Mobile Router's Home Address at the
   Virtual Home Link.  How to intercept packets addressed to the Home
   Address depends on implementations of the Mobile Router.  If the Home
   Address is not configured at the egress interface, the Mobile Router
   MUST use proxy Neighbor Discovery to intercept all packets addressed
   to the Home Address on the virtual Home Link.  Otherwise, the Mobile
   Router does not have to perform any special operation at the virtual
   Home Link.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 at
   ietf-ipr@ietf.org.

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

   This document and the information contained herein is 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 DISCLAIMS 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.

Acknowledgment

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