summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4887.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4887.txt')
-rw-r--r--doc/rfc/rfc4887.txt1067
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]
+