doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4887.txt b/doc/rfc/rfc4887.txt
new file mode 100644
index 0000000..ade743c
--- /dev/null
+++ b/doc/rfc/rfc4887.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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]
+