GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4887

Network Working Group P. Thubert Request for Comments: 4887 Cisco Systems Category: Informational R. Wakikawa

                                              Keio University and WIDE
                                                        V. Devarapalli
                                                       Azaire Networks
                                                             July 2007
                Network Mobility Home Network Models

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

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

Thubert, et al. Informational [Page 1] RFC 4887 Home Network Models with NEMO Basic July 2007

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  4
 3.  General Expectations . . . . . . . . . . . . . . . . . . . . .  4
 4.  MIP Home Network . . . . . . . . . . . . . . . . . . . . . . .  5
 5.  NEMO Extended Home Network . . . . . . . . . . . . . . . . . .  5
   5.1.  Configuration  . . . . . . . . . . . . . . . . . . . . . .  5
   5.2.  Returning Home . . . . . . . . . . . . . . . . . . . . . .  6
   5.3.  Home Address from MNP  . . . . . . . . . . . . . . . . . .  7
   5.4.  Deployment Caveats . . . . . . . . . . . . . . . . . . . .  8
     5.4.1.  Mobile Router Side . . . . . . . . . . . . . . . . . .  8
   5.5.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  8
 6.  NEMO Aggregated Home Network . . . . . . . . . . . . . . . . .  8
   6.1.  Configuration  . . . . . . . . . . . . . . . . . . . . . .  8
   6.2.  Returning Home . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.1.  Returning Home with the Egress Interface . . . . . . . 10
     6.2.2.  Returning Home with the Ingress Interface  . . . . . . 10
   6.3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 11
   6.4.  Deployment Caveats . . . . . . . . . . . . . . . . . . . . 11
     6.4.1.  Home Agent Side  . . . . . . . . . . . . . . . . . . . 11
     6.4.2.  Mobile Router Side . . . . . . . . . . . . . . . . . . 11
 7.  NEMO Virtual Home Network  . . . . . . . . . . . . . . . . . . 12
   7.1.  Configuration  . . . . . . . . . . . . . . . . . . . . . . 12
   7.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 14
 8.  NEMO Mobile Home Network . . . . . . . . . . . . . . . . . . . 14
   8.1.  Configuration  . . . . . . . . . . . . . . . . . . . . . . 14
   8.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 17
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
   11.2. Informative References . . . . . . . . . . . . . . . . . . 18

Thubert, et al. Informational [Page 2] RFC 4887 Home Network Models with NEMO Basic July 2007

1. Introduction

 This document assumes that the reader is familiar with IPv6 Mobility
 as defined by Mobile IPv6 and the Network Mobility (NEMO) Basic
 Support.  In order to read this document properly, it is important to
 realize that in NEMO, the Home Network can encompass much more than
 the Home Link, as it spans the Home Link and all the Links that the
 Mobile Routers (MRs) carry with them.  Exactly how the two concepts
 relate in a given deployment depends 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 toward NEMO.
 NEMO Extended Home Network:  In this 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 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 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 arrangement, there is a bitwise
    hierarchy of Home Networks.  A global Home Network is advertised
    to the infrastructure by a head Home Agent (HA) 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 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
 [5] but do not aim at limiting its scope of application; additional
 cases may be added in the future.

Thubert, et al. Informational [Page 3] RFC 4887 Home Network Models with NEMO Basic July 2007

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 RFC 2119 [2].
 Most of the mobility-related terms used in this document are defined
 in the Mobility Related Terminology document [3] and in the Mobile
 IPv6 (MIP6) specification [4].
 In addition, some terms were created or extended for NEMO.  These
 specific terms are defined in the Mobile Network Terminology document
 [6]:
    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, consider the case where the aggregation has a global
 routing prefix of m = 48 bits (A:B:C::/48), with a subnet ID size of
 n = 16 bits (n + m = 64):

Thubert, et al. Informational [Page 4] RFC 4887 Home Network Models with NEMO Basic July 2007

 When a Mobile Router, MR1, uses the Mobile Network Prefix (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
 advertises the virtual network.
 The following sections provide additional information on these forms
 of Home Network.

4. MIP Home Network

 In the Mobile IPv6 (MIP6) specification [4], 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 Duplicate Address Detection (DAD) on the Home Link,
 and Home Agents discover each other by means of Neighbor Discovery
 (ND) extensions over that link.
 The Home Prefix that is advertized on the Home 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.

Thubert, et al. Informational [Page 5] RFC 4887 Home Network Models with NEMO Basic July 2007

                      |
            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 arrangement:
 o  There is one physical Home Network and multiple Mobile Networks
 o  The Home Prefix and the MNPs are tailored to allow for IPv6
    Stateless Address Autoconfiguration with typical interface
    identifier length for the type of interface (for example, can be
    /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
    (for example, can be /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.
    In that case, a Home Agent can perform DAD on the Home Link as
    prescribed by Mobile IPv6 for the Mobile Router Home Addresses
    (MRHAs).

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.

Thubert, et al. Informational [Page 6] RFC 4887 Home Network Models with NEMO Basic July 2007

 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 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.
 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 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 interface as opposed to
 assigning its home Address to the interface.
 For all these reasons, this submode of Extended Home Network is not a
 trivial extension of the MIPv6 Home Model, and it might not be
 compatible with all implementations.

Thubert, et al. Informational [Page 7] RFC 4887 Home Network Models with NEMO Basic July 2007

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 in the IGP
 if and only if the Mobile Router is at home.
 The NEMO Basic Support does not mandate a specific routing protocol
 though the support for some well-known routing protocols can be
 expected from many implementations.  An implementation might provide
 an automatic toggle to start/stop routing on an egress interface when
 the mobile router comes back/leaves home.  When such a toggle is
 unavailable, then a specific interface should be reserved to attach
 to home with the appropriate settings for security and routing.

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

Thubert, et al. Informational [Page 8] RFC 4887 Home Network Models with NEMO Basic July 2007

                  HA
                   | /56                       Aggreg /56
        --+-----+--+- . -+- . -+--
          |     |        |     |
         MR1   MR2      MRi   MRN
          |     |        |     |
      ------  ------  ------ ------
          /64   /64     /64   /64         Aggreg|i /64  0 < i <= N
                Aggregated Home Network == Home Network
      <----------------------------------------------------------->
       Mobile Net    Mobile Net    Mobile Net    ...   Mobile Net
      <------------><------------><------------> ... <------------>
                   Figure 2: Aggregated Home Network
 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 network (see [3]) 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.
 When the Mobile Router forms its Home Address out of one of its MNPs,
 since the Home Network prefix is an aggregation that encompasses all
 the MNPs, the Home Address actually matches both prefixes.  To
 properly identify the Home Network as it returns home, the MR must
 expect a shorter prefix length than that of the MNP from which the
 Home Address was formed.

Thubert, et al. Informational [Page 9] RFC 4887 Home Network Models with NEMO Basic July 2007

6.2.1. Returning Home with the Egress Interface

 A Mobile Router coming home via its Egress interface sees overlapping
 prefixes between the Ingress and the Egress interfaces and some
 specific support may be needed:
 When a Mobile Router connects to the Home Link using its Egress
 Interface, it might set up a bridge between its Ingress interface(s)
 and the Home Link, if the interfaces are compatible.
 Alternatively, the Mobile Router might perform ND proxying for all
 addresses in its MNPs, between the Egress interface and the related
 Ingress interface, as described in [8].  Since the prefixes on the
 Egress and Ingress interfaces are overlapping, routing is disallowed.
 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
 Mobile Network Nodes (MNNs) will be reachable over the Home Link.
                  HA
                   |
         -------+--+--- /56
                |
         Egress |
               MR at home
                |
              --+---  /64
             Figure 3: Bridging between Egress and Ingress

6.2.2. Returning Home with the Ingress Interface

 Alternatively, if the Mobile Router has a single 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
                |
             ---+-- /64
                |
               MR at home
         Egress |
          Figure 4: Merging the Home and the Mobile Networks

Thubert, et al. Informational [Page 10] RFC 4887 Home Network Models with NEMO Basic July 2007

 This fits the connected route model, since the Aggregated Home
 Network 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, 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.

6.4. Deployment Caveats

6.4.1. Home Agent Side

 A node on the Home Link receiving a Router Advertisement that
 includes the Aggregated Home Network prefix might use that prefix for
 Address Autoconfiguration.  Such a node 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 would look up all MNNs on that MNP
 using Neighbor Discovery over its interface to the Home Link, and
 fail.
 Thus, on the Home Link, the Home Agent must intercept all the packets
 for ALL the Mobile Network Nodes on the registered prefixes; that is,
 for ALL nodes attached to Mobile Routers that are away from home.
 This should be a layer 2 operation, rather than layer 3.  The Home
 Agent might, for example, 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.
 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, a specific support is
 required to control the bridging operation depending on whether or
 not a Mobile Router is at home.  This support might not be present in
 all implementations.

Thubert, et al. Informational [Page 11] RFC 4887 Home Network Models with NEMO Basic July 2007

 The NEMO Basic Support does not mention a specific behavior for
 bridging though bridging capabilities can be expected from many
 implementations.  An implementation might provide an automatic toggle
 to start/stop bridging on an Egress interface when the Mobile Router
 comes back/leaves home.  When such a toggle is unavailable, then a
 specific interface should be reserved to attach to home with the
 appropriate settings for security and bridging.
 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 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 over time.
 It is thus possible for 2 different Mobile Routers to register the
 same prefix with different Home Addresses, and this will cause an
 undetected problem if the corresponding 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 interface as
 opposed to statically 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 -- 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. NEMO Virtual Home Network

7.1. Configuration

 The Home Link can be configured on the Home Agent on a virtual link,
 in which case there is no physical Home Link for Mobile Routers to
 return home to, or for Home Agents to discover each other and perform
 the ND-level interactions on, as described in Mobile IPv6 [4].

Thubert, et al. Informational [Page 12] RFC 4887 Home Network Models with NEMO Basic July 2007

                  /48                       e.g.: A:B:C::/48
                  HA
                  | /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 [4]).
 There are also some drawbacks to the Virtual Home Link approach:
    RFC 3775 [4] and RFC 3963 [5] do not provide the specific support
    for a Mobile Node to emulate returning home on a Virtual Home
    Network.  In particular, in the 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.
    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.

Thubert, et al. Informational [Page 13] RFC 4887 Home Network Models with NEMO Basic July 2007

    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.
 Suggestions on how to perform an equivalent of returning home on a
 Virtual Home Network have been proposed, but this topic is outside of
 the scope of this document.

7.2. Applicability

 NEMO operations rely on ND extensions over the Home Link for the Home
 Agent to Home Agent communication.
 Making the Home 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 [9] 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.
 Note that NEMO basic does not mandate the support of Virtual Home
 Networks.

8. NEMO Mobile Home Network

8.1. Configuration

 In this 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 this is the Cab Co configuration.  Cab Co is a taxi
 company that uses a /32 prefix for its Home Network, this prefix
 being advertised by the company headquarters (HQ).  Regional offices
 are deployed around the country.  Even though these regional offices

Thubert, et al. Informational [Page 14] RFC 4887 Home Network Models with NEMO Basic July 2007

 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.
 To illustrate this configuration, we make up the prefixes to reflect
 their role, like CAB:C0::/32 for the Home Network:
       global Home Network   CAB:C0::/32  advertised 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 an associated /64 prefix.
 For each Office, say San Francisco (SFO) as an example:

Thubert, et al. Informational [Page 15] RFC 4887 Home Network Models with NEMO Basic July 2007

      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:....::/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 Address
     of CAB 1
             Figure 7:  CAB Company regional configuration
 Note that this is a hierarchy in terms of MR-HA relationship, which
 may not be reflected in the physical arrangement of nodes at a given
 point of time.  For instance, in the Cab Co case, some SFO cabs might
 attach to any hot spot or Cab Co office in a different city, and the
 SFO office might be at home if it is 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 NEMO Route Optimization (RO) problem statement [7].
 But it is also possible to reflect the organizational hierarchy in a
 moving cloud of Mobile 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.  Assume 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 from its cabs and
 reencapsulates all the packets between the nested cloud and
 correspondents in the infrastructure in a single tunnel to CA5A.  As
 a result, the unwanted effect of nesting of tunnels is avoided over
 the Internet part of the packet path.

Thubert, et al. Informational [Page 16] RFC 4887 Home Network Models with NEMO Basic July 2007

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
 Network Address Transition (NAT) or a SOCKS [1] server 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 rendezvous
 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. 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 RFC 3963 [5] for security considerations for
 the NEMO Basic Support protocol.

10. Acknowledgements

 The authors wish to thank Erik Nordmark, Jari Arkko, Henrik
 Levkowetz, Scott Hollenbeck, Ted Hardie, David Kessens, Pekka Savola,
 Kent Leung, Thierry Ernst, TJ Kniveton, Patrick Wetterwald, Alexandru
 Petrescu, and David Binet for their contributions.

11. References

11.1. Normative References

 [1]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L.
      Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
 [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [3]  Manner, J. and M. Kojo, "Mobility Related Terminology",
      RFC 3753, June 2004.
 [4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
      IPv6", RFC 3775, June 2004.
 [5]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
      "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
      January 2005.

Thubert, et al. Informational [Page 17] RFC 4887 Home Network Models with NEMO Basic July 2007

 [6]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
      July 2007.

11.2. Informative References

 [7]  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
      Route Optimization Problem Statement", RFC 4888, July 2007.
 [8]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
      Proxies (ND Proxy)", RFC 4389, April 2006.
 [9]  Ng, C., "Analysis of Multihoming in Network Mobility Support",
      Work in Progress, February 2007.

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
 Azaire Networks
 3121 Jay Street
 Santa Clara, CA  94054
 USA
 EMail: vijay.devarapalli@azairenet.com

Thubert, et al. Informational [Page 18] RFC 4887 Home Network Models with NEMO Basic July 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the 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.

Acknowledgement

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

Thubert, et al. Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4887.txt · Last modified: 2007/07/17 01:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki