Network Mobility                                              P. Thubert
Internet-Draft                                                     Cisco
Expires: December 26, 2005 April 13, 2006                                      R. Wakikawa
                                                         Keio University
                                                          V. Devarapalli
                                                                   Nokia
                                                           June 24,
                                                        October 10, 2005

                        NEMO Home Network models
                 draft-ietf-nemo-home-network-models-04
                 draft-ietf-nemo-home-network-models-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on December 26, 2005. April 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and concepts . . . . . . . . . . . . . . . . . . .  5  4
   3.  General Expectations . . . . . . . . . . . . . . . . . . . . .  6  5
   4.  MIP Home Network . . . . . . . . . . . . . . . . . . . . . . .  7  6
   5.  NEMO Extended Home Network . . . . . . . . . . . . . . . . . .  8  7
     5.1   Configuration  . . . . . . . . . . . . . . . . . . . . . .  8  7
     5.2   Returning Home . . . . . . . . . . . . . . . . . . . . . .  9  8
     5.3   Home Address from MNP  . . . . . . . . . . . . . . . . . .  9  8
     5.4   Deployment Caveats . . . . . . . . . . . . . . . . . . . . 10  9
       5.4.1   Mobile Router side . . . . . . . . . . . . . . . . . . 10  9
     5.5   Applicability  . . . . . . . . . . . . . . . . . . . . . . 10  9
   6.  NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 11 10
     6.1   Configuration  . . . . . . . . . . . . . . . . . . . . . . 11 10
     6.2   Returning Home . . . . . . . . . . . . . . . . . . . . . . 11 10
       6.2.1   Returning Home by egress . . . . . . . . with the Egress interface . . . . . . . 12 11
       6.2.2   Returning Home by ingress  . . . . . . . . with the Ingress interface  . . . . . . 12
     6.3   Applicability  . . . . . . . . . . . . . . . . . . . . . . 13 12
     6.4   Deployment Caveats . . . . . . . . . . . . . . . . . . . . 13 12
       6.4.1   Home Agent Side  . . . . . . . . . . . . . . . . . . . 13 12
       6.4.2   Mobile Router side . . . . . . . . . . . . . . . . . . 14 13
   7.  Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 15 14
     7.1   Configuration  . . . . . . . . . . . . . . . . . . . . . . 15 14
     7.2   Applicability  . . . . . . . . . . . . . . . . . . . . . . 16 15
   8.  Mobile Home  . . . . . . . . . . . . . . . . . . . . . . . . . 17 16
     8.1   Configuration  . . . . . . . . . . . . . . . . . . . . . . 17 16
     8.2   Applicability  . . . . . . . . . . . . . . . . . . . . . . 18
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 19 18
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 19 18
   11.   Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . 20 19
     11.1  Changes from version 00 to 01  . . . . . . . . . . . . . . 20 19
     11.2  Changes from version 01 to 02  . . . . . . . . . . . . . . 20 19
     11.3  Changes from version 02 to 03  . . . . . . . . . . . . . . 20 19
     11.4  Changes from version 03 to 04  . . . . . . . . . . . . . . 20 19
     11.5  Changes from version 04 to 05  . . . . . . . . . . . . . . 19
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 20
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21 20
     13.1  normative reference  . . . . . . . . . . . . . . . . . . . 21 20
     13.2  informative reference  . . . . . . . . . . . . . . . . . . 22 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
   A.  Returning Home emulation in the virtual case . . . . . . . . . 23 21
       Intellectual Property and Copyright Statements . . . . . . . . 24 22

1.  Introduction

   This document assumes that the reader is familiar with IPv6 Mobility
   as defined in [7], with the NEMO Basic Support [8] and with the NEMO
   terminology document [9]. [8].  In order to read
   this document properly, the distinction between the
   concepts of Home Link and of Home Network must be very clear.  A Home
   Link it is a physical or a virtual Link, attached important to a Home Agent.  A realize that in NEMO, the
   Home Network is an aggregation that can be further subnetted.  As a
   result, encompass much more than the Home Network is not necessarily contained on a Link, as it spans
   the Home Link.
   In fact, Link and all the Mobile Network Prefixes are subnets of Links that the Home Network.
   How Mobile Routers carry with
   them.  Exactly how the two concepts relate in a given deployment
   depend on the organization of the Home Network, as described below.

   Five different organizations of the Home Network including a
   hierarchical construction are documented:

   MIPv6 Home Network: A short reminder of what the Home Network is with
      Mobile IP, in order to help the reader figure out the evolution
      towards NEMO.

   NEMO Extended Home Network: In this disposition, arrangement, the Home Network is
      only one subnet of a larger aggregation that encompasses the
      Mobile Networks, called extended Home Network.  When at Home, a
      Mobile Router performs normal routing between the Home Link and
      the Mobile Networks.  More in Section 5.

   NEMO Aggregated Home Network: In this disposition, arrangement, the Home Network
      actually overlaps with the Mobile Networks.  When at Home, a
      Mobile Router acts as a bridge between the Home Link and the
      Mobile Networks.  More in Section 6.

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

   NEMO Mobile Home Network: In this disposition, arrangement, 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.  More in Section 8.

   In all cases, the Home Agents collectively advertise only the
   aggregation of the Mobile Networks.  The dichotomy subnetting is kept within
   the Home Agents and the Mobile Routers, as opposed to advertised by
   means of routing protocols to other parties.

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

2.  Terminology and 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 described in RFC2119 [1].

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

      link-local unicast address

      link-local scope multicast address

   Most of the mobility related terms used in this document are defined
   in the Mobility Related Terminology document [6] and in the Mobile
   IPv6 (MIP6) specification [7].

   Additionally, some terms were created or extended for NEMO.  These
   specific terms are defined in the Mobile Network Terminology document
   [9]:

      Home Link

      Home Network

      Home Address

      MRHA Tunnel

      Mobile Aggregated Prefix

      Aggregated Home Network

      Extended Home Network

      Virtual Home Network

      Mobile Home Network

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, considering the case where 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).

   When a Mobile Router, MR1, owns the MNP A:B:C:1::/64 with the NEMO
   Basic Support, MR1 may register using a Home Address from the Home
   network (i.e.  A:B:C:0::1) or a Home Address from one of its MNPs
   (i.e.  A:B:C:1::1) depending on the deployment.

   In a given deployment, one subnet may be reserved for the Home Link
   (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.

4.  MIP Home Network

   With

   In the Mobile IPv6 (MIP6) specification [7] Mobile Nodes are at Home
   when they are connected to their Home Link, where they recognize
   their Home Prefix in Router Advertisement messages.  Also, a binding
   is checked using of Duplicate Address Detection on the Home Link, and
   Home Agents discover each other by means of Neighbor Discovery
   extensions over that link.

   The Home Prefix, Prefix that is advertized on the Home Link, Link is a final
   prefix, as opposed to an aggregation, and it may be used by hosts on
   the Home Link for autoconfiguration purposes.

   As we see, the concept of a Home Network for Mobile IPv6 is really a
   prefix on a link, served by one or more Home Agents as opposed to a
   routed mesh.  We will see in the next sections that NEMO needs
   additional prefixes for use by the Mobile Networks.  For that reason,
   NEMO extends the concept of Home Network into a more complex,
   aggregated structure.

5.  NEMO Extended Home Network

5.1  Configuration

   One simple way of extending the MIP Home Network is to use additional
   prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as
   Mobile Network Prefixes.  As this model trivially extends the MIP
   Home Network, the resulting aggregation is called a NEMO Extended
   Home Network.  It is depicted in Figure 1.

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

                        HA
                        | /64         Home Link: A:B:C:0::/64
             --+-----+--+- . -+- . -+--
               |     |        |     |
               MR1   MR2      MRi   MRN
               |     |        |     |
            ------  ------  ------ ------
              /64   /64      /64   /64   MNP:  A:B:C:i::/64

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

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

                      Figure 1: Extended Home Network

   In that configuration: arrangement:

   o  There is one physical Home Network and multiple Mobile Networks

   o  The Home and the 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).

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

   o  Since the Extended Home Network operations inherit trivially from
      MIPv6, it can be seen as natural that the Mobile Routers be
      assigned their Home Addresses from the prefix on the Home Link, as
      opposed to their own MNP, which is allowed by the NEMO
      specification. Link.
      In that case, a Home Agent can perform DAD on the Home Link as
      prescribed by Mobile IPv6 for the Mobile Router Home Addresses.

5.2  Returning Home

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

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

   In implicit mode, the Home Agent has the necessary information to
   continue routing to the MNPs in the absence of registration, assuming
   that the Mobile Router is at Home,  and the participation of the
   Mobile Router to the Home IGP Interior Gateway Protocol (IGP) is not
   required.

   But in explicit mode, or if the Mobile Router uses an IGP over the
   MRHA tunnel, then it needs to resume its IGP operations on the Home
   Link in order to advertise its Mobile Networks to the HA, unless some
   other means such as static routes are deployed to cover the case.

   Alternate

   Alternative procedures for ensuring the connectivity of the Mobile
   Networks when at home are described in Section 7.

5.3  Home Address from MNP

   We saw that a natural extension of the MIP procedure is to derive the
   Home Address of a Mobile Router from the prefix on the Home Link.
   Alternatively, NEMO basic support allows that a Mobile Router forms
   its Home Address from one of its Mobile Network Prefixes.

   In that case, the Home Address does not match the Home Link Prefix,
   and there is a need to configure the Home Agent in a specific mode
   with the support for the extended Extended Home Network and the range of the
   Mobile Network Prefixes.  Based on that new configuration, the Home
   Agent can accept a Home Address that is not from the Home Link, and
   it will know that it should not perform any DAD.

   Also, if the Mobile Router uses a Home Address that is derived from
   its MNP, some specific support is required on the Mobile Router as
   well.  In order to determine that it is at Home, the Mobile Router
   recognizes the well-known prefix of its Home Agent as opposed to
   matching the prefix on the Home Link with that of its Home Address.

   When connecting to the Home Link, the Mobile Router also need to
   autoconfigure an address on the egress Egress interface as opposed to
   assigning its Home Address to the interface.

   For all these reasons, this submode of extended Extended Home Network is no more not a
   trivial extension to of the MIPv6 Home Model, and it might not be
   compatible with all implementations.

5.4  Deployment Caveats

5.4.1  Mobile Router side

   In explicit mode, the routing to the MNP via the Mobile Router must
   be restored when the Mobile Router is at Home.  This is normally
   performed by the Mobile Router by means of the existing IGP.  In that
   case, a specific support is required on the Mobile Router to control
   the routing protocol operation, enabling the participation to in the IGP
   if and only if the Mobile Router is at home.  This support might not
   be present in all implementations.

5.5  Applicability

   The extended 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
   assigned to MNPs and prefix(es) that are dedicated to the Home Link,
   it is possible for MNs and Mobile Routers to coexist with that model.

   Also, when the Home Address is derived from the prefix on the Home
   Link, the Home Agent behavior on the link trivially extends that of
   MIP and the support should for that configuration should be available with
   all implementations.

   There are a number of issues with returning home when a mobile router
   configures its home address from the MNP as described in Section 5.3.
   Therefore we do not recommend this mechanism if the mobile routers
   attach to the home network.

6.  NEMO Aggregated Home Network

6.1  Configuration

   One other approach is to consider that the Aggregation of all the
   MNPs is used plainly as the Home Link Prefix.  In this model, the
   Home Network is referred to as a NEMO 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, 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
        <------------><------------><------------> ... <------------>

                         Figure 2: Aggregated Home

   In that model, it seems natural to subnet the whole range of
   addresses into Mobile Network prefixes, as opposed to reserving one
   prefix for the Home Link, which would boil down to the Extended Home
   Network model.  If the prefix on the Home Link is really an
   aggregation and not a final prefix, it should not be allowed for
   autoconfiguration or Home Address allocation.

   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 uniqueness of the
   suffix.  That uniqueness can be checked by the Mobile Router on its
   ingress
   Ingress network (see [6]) using DAD.

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

   Since the Home Network prefix is an aggregation that it encompasses all
   the MNPs, the Home Address that an MR forms from one of its Mobile
   Network Prefixes will actually match both the Home Network prefix and
   its Mobile Network prefix.  To properly identify the Home Network,
   the MR must expect a shorter prefix than that of its the Mobile
   Networks, even if Network
   from which the Home Address was formed.

   When the Mobile Router forms its Home Address is formed out of one of its MNPs,
   but
   Mobile Network Prefixes, since the Home Network prefix is an
   aggregation that encompasses all the MNPs, the Home Address still actually
   matches both prefixes.  As a result, the Home MR must expect a shorter
   prefix than that of the Mobile Network Prefix. from which the Home Address
   was formed.

6.2.1  Returning Home by egress with the Egress interface

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

   When a Mobile Router connects to the Home Link using its egress Egress
   interface, it might set up a bridge between its ingress Ingress interface(s)
   and the Home Link. Link, if the interfaces are compatible.

   Alternatively, the Mobile Router might perform ND proxying for all
   addresses in its MNPs, between the egress Egress and the related ingress
   interface. Ingress
   interface, as described in [12].  Since the prefixes on the egress Egress
   and ingress Ingress interfaces are overlapping, routing is disallowed.

   On the positive side, the

   The Mobile Router does not need to join the local IGP when returning
   Home, even if it is using the explicit Prefix Mode.  When the Mobile
   Router is not registered, the Home Agent simply expects that all MNNs
   will be reachable over the Home Link.

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

               Figure 3: Bridging between egress and ingress

6.2.2  Returning Home by ingress with the Ingress interface

   Alternatively, if the Mobile Router has a single ingress Interface, Ingress interface,
   the Mobile Router may use the 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
            |
                  |
               ---+-- /64
                  |
                 MR at Home
           Egress |

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

6.3  Applicability

   With this model, there is no specific space for independent nodes 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 Mobile Router 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 Mobile Router 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 Mobile Routers if returning Home is required.

6.4  Deployment Caveats

6.4.1  Home Agent Side

6.4  Deployment Caveats

6.4.1  Home Agent Side

   A node on the Home Link discovers receiving a Router Advertisement that
   includes the Aggregated Home Network is
   actually a subnet on the Home Link and may prefix might use the that prefix on the Home
   Link to autoconfigure a Home Address. for
   Address Autoconfiguration.  Such a node may would 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 Mobile Network Prefix, it will would lookup all MNNs on that MNP
   using Neighbor Discovery over its interface to the Home Link. Link, and
   fail.

   Thus, on the Home Link, the Home Agent must intercept all the packets
   to ALL the Mobile Network Nodes on the registered prefixes.  In order
   to do so, the Home Agent might perform some form of ND proxying for
   all addresses in all registered Mobile Network Prefixes.  The Home
   Agent must also protect the MNP space from autoconfiguration by
   uncontrolled visitors at Neighbor Discovery level.

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

   In any case, there is a need to provide a specific configuration on
   the Home Agent to specify that it operates in Aggregated Mode.  If a
   Home Agent implementation is simply derived from that of MIP, then
   the capability to perform the required proxying might not exist, and
   the Aggregated Mode will not operate properly for nodes on the Home
   Link.

6.4.2  Mobile Router side

   If the Mobile Router returns Home by egress, Egress, a specific support is
   required to control the bridging operation depending on whether a
   Mobile Router is at Home or not.  This support might not be present
   in all implementations.

   Also, note that NEMO authorizes multiple registrations for a same MNP
   by different Mobile Routers.  This is a case of multihoming, and it
   normally means that the Mobile Routers are interconnected by the
   ingress
   Ingress network that bears the common MNP.  But there is no provision
   in NEMO basic support to test that this condition is met at binding
   time and maintained overtime. over time.

   It is thus possible for 2 different Mobile Routers to register a the
   same prefix with different Home Addresses, and this will cause an
   undetected problem if the corresponding ingress links Ingress interfaces are not
   connected.

   When the Home Address of a Mobile Router is derived from its MNP,
   there is thus an additional risk of an undetected misconfiguration if
   the Home Address is autoconfigured from the ingress link Ingress interface as
   opposed to statically assigned with assigning an address and MNP.

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

7.  Virtual Home Network

7.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 to, or for Home Agents to discover each others and
   perform the ND level interactions on, as described in Mobile IPv6. [7] IPv6
   [7].

                    /48                       eg:                       e.g.: A:B:C::/48
                    HA
                    | /64                         A:C:C:E::/64                         A:B:C::/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 and the Aggregated Home Network models can
   be adapted for virtual links.

   As in the case of a physical link, the Home Address of a Mobile
   router can be constructed based on a dedicated subnet of the Home
   Prefix or one of the Mobile Router 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. IPv6 [7]).

   In order

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

      RFC 3775 [7] and RFC 3963 [8] do not provide the specific support
      for a Mobile Router Node to emulate returning Home, it can
   connect to one or more access link(s) configured for that purpose Home on
   the a Virtual Home Agent.  The Mobile Router, after connecting to the access
   link, SHOULD not send any routing protocol updates on
      Network.  In particular, in the egress
   interface because case of NEMO, the routing
      information from the Mobile Router being injected on the IGP 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 Home Agent 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

   Suggestions on how to perform an equivalent of returning Home on a virtual
   Virtual Home Network.  One such approach Network have been proposed, but this topic is
   sketched in appendix as an illustration. outside of
   the scope of this document.

7.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] rely on ND extensions over the Home Link for the Home
   Agent to Home Agent communication,
   which is basically based on Neighbor Discovery extensions over communication.

   Making the Home Link.  Making that link 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] [13] draft for more on this.

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

   One should check with the product specifications of an Home Agent 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.

8.  Mobile Home

8.1  Configuration

   In this disposition, arrangement, 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
   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 this is the Cab Co configuration.  When  Cab Co is a Taxi taxi
   Company that owns a /32 prefix, this prefix is being advertised at a fixed point in by the
   company Head Quarters.  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.

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

      HQ extended 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 an associated /64 prefix.

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

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

      SFO Home Network             Mobile Networks for taxis
        for taxis        <---------------------...--------------------->
     CAB:C0:5F0:5F0::/64  CAB:C0:5F0:CAB1::/64     CAB:C0:5F0:....::/6     CAB:C0:5F0:....::/64
    <-------------------><-------------------> ... <------------------->
     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 Address
       of CAB 1

               Figure 7:  CAB Company regional configuration

   Note that the hierarchy occurs at this is a configuration level and hierarchy in terms of MR-HA relationship, which
   may not be reflected in the actual connection between nodes. physical arrangement of nodes at a given
   point of time.  For instance instance, in the Cab Co case, cabs are roaming within the city, each one attaching some SFO Cabs might
   attach to any hot spot or Cab Co office in a different hot spot, while city, and the regional
   SFO office might be at Home if it is connected co-located with the
   Headquarters.  But note that SFO should never attach to one of its
   own Cabs.  This would create a stalemate situation, as documented in
   the infrastructure using some ISP connection. NEMO RO problem statement [11].

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

   This can be illustrated in the case of a fleet at sea.  Assuming that
   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 its own cabs, the
   communication between cabs is relayed by SFO and does not require the
   satellite link.  As for traffic to the outside of the nested NEMO,
   SFO recursively terminates the nested tunnels to the from its 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. CA5A. As a
   result, the unwanted effect of nesting of tunnels is avoided over the
   Internet part of the packet path.

8.2  Applicability

   This complex topology applies to a 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 Home Agent could be located.

   One specific benefit is that when 2 Mobile Routers travel together
   with a common Home Agent, 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 Mobile Routers.  This applies particularly
   well for a fleet at sea when the long haul access may be as expensive
   as a satellite link.

9.  IANA considerations

   This document does not require any IANA action.

10.  Security Considerations

   This document only explains how a home network can be deployed to
   support Mobile Routers and does not introduce any additional security
   concerns.  Please see [RFC3963] for security considerations for the
   NEMO Basic Support protocol.

11.  Changes

   An issue list is maintained at http://www.mobilenetworks.org/
   ~pthubert/draft-ietf-nemo-home-network-models-issues.html .

11.1  Changes from version 00 to 01

      Removed terminology (moved to the Nemo terminology draft).

      Added an applicability statement for all documented cases

11.2  Changes from version 01 to 02

   Issue 1: Editorial

   Issue 2: Added a caveat part in extended Extended and aggregated Aggregated Home Network
      sections.  Also added a MIP Home Network section prior to those.

   Issue 4: Added a subsection to the extended Extended Home Network case for the
      case when the mr takes a home address from its MNP

11.3  Changes from version 02 to 03

   Issue 5: Editorial fixes.

11.4  Changes from version 03 to 04

   Issue 6: Pass idnits.  Thanks Henrik for this great tool :)

11.5  Changes from version 04 to 05

   Issue 7: Virtual Home discussion

   Issue 8: Whether to recommend not to form a Home Address from MNP in
      Extended HN.

   Jari and Henrik's reviews Editorial changes

12.  Acknowledgements

   The authors wish to thank:

   Erik Nordmark, Jari Arkko, Henrik Levkowetz, Kent Leung, Thierry
   Ernst, TJ Kniveton, Patrick Wetterwald, Alexandru Petrescu and David Binet.
   Binet for their contributions.

13.  References

13.1  normative reference

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

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

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

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

   [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", RFC 3775, June 2004.

   [8]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

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

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

13.2  informative reference

   [11]  Thubert, P., "Global HA to HA protocol",
         draft-thubert-nemo-global-haha-00  Ng, C., "Network Mobility Route Optimization Problem
         Statement", draft-ietf-nemo-ro-problem-statement-00 (work in
         progress),
         October 2004. July 2005.

   [12]  Ernst, T.,  Thaler, D., "Neighbor Discovery Proxies (ND Proxy)",
         draft-ietf-ipv6-ndproxy-03 (work in progress), July 2005.

   [13]  Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-02
         draft-ietf-nemo-multihoming-issues-03 (work in progress), February
         July 2005.

Authors' Addresses

   Pascal Thubert
   Cisco Systems
   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
   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 Mobile Router 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 Mobile Router
   Home Address, and a connected host route to the Mobile Router's 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 Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

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

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

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.