Network Mobility P. Thubert Internet-Draft Cisco Expires:
April 13,August 21, 2006 R. Wakikawa Keio University V. Devarapalli Nokia October 10, 2005February 17, 2006 NEMO Home Network models draft-ietf-nemo-home-network-models-05draft-ietf-nemo-home-network-models-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 13,August 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005).(2006). Abstract This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft .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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 5 4. MIP Home Network . . . . . . . . . . . . . . . . . . . . . . . 6 5. NEMO Extended Home Network . . . . . . . . . . . . . . . . . . 7 5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Home Address from MNP . . . . . . . . . . . . . . . . . . 8 5.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 9 5.4.1 Mobile Router side . . . . . . . . . . . . . . . . . . 9 5.5 Applicability . . . . . . . . . . . . . . . . . . . . . . 9 6. NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 10 6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1 Returning Home with the Egress interface . . . . . . . 11 6.2.2 Returning Home with the Ingress interface . . . . . . 1211 6.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 12 6.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 12 6.4.1 Home Agent Side . . . . . . . . . . . . . . . . . . . 12 6.4.2 Mobile Router side . . . . . . . . . . . . . . . . . . 13 7. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 14 7.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 15 8. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 16 8.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 19 11.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 19 11.3 Changes from version 02 to 03 . . . . . . . . . . . . . . 19 11.4 Changes from version 03 to 04 . . . . . . . . . . . . . . 19 11.5 Changes from version 04 to 05 . . . . . . . . . . . . . . 19 11.6 Changes from version 05 to 06 (IESG review) . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 2021 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 2021 13.1 normative reference . . . . . . . . . . . . . . . . . . . 2021 13.2 informative reference . . . . . . . . . . . . . . . . . . 2122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 2122 Intellectual Property and Copyright Statements . . . . . . . . 2223 1. Introduction This document assumes that the reader is familiar with IPv6 Mobility as defined in , withby Mobile IPv6 and the NEMO Basic Support .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 depend on the organization of the Home Network, as described below. Five different organizations of the Home Network including a hierarchical construction are documented: MIPv6 Home Network: A short reminder of what the Home Network is with Mobile IP, in order to help the reader figure out the evolution towards NEMO. NEMO Extended Home Network: In this 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  but do not aim at limiting its scope of application, and additional cases may be added in the future. 2. Terminology and concepts The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119 . The following terms used in this document are defined in the IPv6 Addressing Architecture document : link-local unicast address link-local scope multicast addressMost of the mobility related terms used in this document are defined in the Mobility Related Terminology document  and in the Mobile IPv6 (MIP6) specification . Additionally, some terms were created or extended for NEMO. These specific terms are defined in the Mobile Network Terminology document : Home Link Home Network Home Address MRHA Tunnel Mobile Aggregated Prefix Aggregated Home Network Extended Home Network Virtual Home Network Mobile Home Network 3. General Expectations With Mobile IPv6, the Home Network is generally a physical network interconnecting the Home Agents, and the Mobile Nodes that are at Home. NEMO extends the concept of Home so that it is not only a flat subnet composed of Home Addresses but an aggregation that is itself subnetted in mobile and Home Networks. This aggregation is still referred to as Home. As an example, considering the case where the aggregation has a global routing prefix of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + m = 64).64): When a Mobile Router, MR1, ownsuses the MNP A:B:C:1::/64Mobile 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 ownsadvertises 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  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 on the Home Link, and Home Agents discover each other by means of Neighbor Discovery 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. | 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 and the MNPs are tailored to allow for IPv6 Stateless Address Autoconfiguration with typical interface identifier length for the type of interface (can be for example /64). o The prefix length of the Extended Home Network is shorter than that of the Home Network and the MNPs, since it is an aggregation (can be for example /48). o Since the Extended Home Network operations inherit trivially from MIPv6, it can be seen as natural that the Mobile Routers be assigned their Home Addresses from the prefix on the Home Link. In that case, a Home Agent can perform DAD on the Home Link as prescribed by Mobile IPv6 for the Mobile Router Home Addresses. 5.2 Returning Home In the Extended Home Network model, the Home Network is configured on a physical interface of the Home Agent, the Home Link. A Mobile Router returns Home by connecting directly to the Home Link, and dropping the MRHA tunnel. When at home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations. In implicit mode, the Home Agent has the necessary information to continue routing to the MNPs in the absence of registration, assuming that the Mobile Router is at Home, and the participation of the Mobile Router to the Home 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. 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. This support mightThe NEMO Basic Support does not mandate a specific routing protocol though the support for some well known routing protocols can be present in allexpected 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. HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN | | | | ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <= N Aggregated Home == Home Net <-----------------------------------------------------------> Mobile Net Mobile Net Mobile Net ... Mobile Net <------------><------------><------------> ... <------------> Figure 2: Aggregated Home In that model, it seems natural to subnet the whole range of addresses into Mobile Network prefixes, as opposed to reserving one prefix for the Home Link, which would boil down to the Extended Home Network model. If the prefix on the Home Link is really an aggregation and not a final prefix, it should not be allowed for autoconfiguration or Home Address allocation. Note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs. Taking the Home Address from its own range guarantees the uniqueness of the suffix. That uniqueness can be checked by the Mobile Router on its Ingress network (see ) 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. Since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address that an MR forms from one of its Mobile Network Prefixes will actually match both the Home Network prefix and its Mobile Network prefix. To properly identify the Home Network, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed.When the Mobile Router forms its Home Address out of one of its Mobile Network Prefixes,MNPs, since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address actually matches both prefixes. As a result,To properly identify the Home Network as it returns Home, the MR must expect a shorter prefix length than that of the Mobile NetworkMNP from which the Home Address was formed. 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 interface 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 and the related Ingress interface, as described in . 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 MNNsMobile 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 This fits the connected route model, since the Aggregated Home is truly located on that network. Note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs. 6.3 Applicability With this model, there is no specific space for independent nodes, 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 lookup 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 tofor ALL the Mobile Network Nodes on the registered prefixes. In orderprefixes - that is for ALL nodes attached to do so, theMobile Routers that are away from Home. This should be a layer 2 operation, rather than layer 3. The Home Agent mightagent 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. Alternatives based on a routing protocol or ICMP redirect may apply in some cases. In any case, thereThere 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 a Mobile Router is at Home or not. This support might not be present in all implementations. 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. Virtual Home Network 7.1 Configuration The Home Link can be configured on the Home Agent on a virtual link, in which case there's no physical Home Link for Mobile Routers to return Home to, or for Home Agents to discover each others and perform the ND level interactions on, as described in Mobile IPv6 . /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 ). There are also some drawbacks to the Virtual Home Link approach: RFC 3775  and RFC 3963  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. 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  draftfor more on this. Yet, for a deployment where a single Home Agent is enough, making the Home Link virtual reduces the vulnerability to some attacks and to some hardware failures, while making the Home Agent operation faster. One should check withNote that NEMO basic does not mandate the product specificationssupport of an Home Agent to see whether the implementation actually supports aVirtual Home Network, and if so, whether in that cases, it is optimized for faster DAD-less bindings.Networks. 8. Mobile Home 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.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 ownsuses a /32 prefix,prefix for its Home Network, this prefix being advertised by the company Head Quarters. Regional offices are deployed around the world.coutry. Even though these regional offices are relatively stable in terms of location and prefix requirement -say this changes every few years- making them mobile allows a simpler management when a move has to take place, or should the ISP service change. 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 ownedadvertised 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: 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 RO problem statement . 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. Assuming that SFO is a communication ship of a fleet, using a satellite link to join the infrastructure, and that the cabs are Mobile Routers installed on smaller ships, equipped with low range radios. If SFO is also the root-MR of a nested structure of its own cabs, the communication between cabs is relayed by SFO and does not require the satellite link. As for traffic to the outside of the nested NEMO, SFO recursively terminates the nested tunnels 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. 8.2 Applicability This complex topology applies to a large distributed fleet, mostly if there is a single interchange point with the internet (e.g. a NAT or a socks farm) where the super Home Agent could be located. One specific benefit is that when 2 Mobile Routers travel together with a common Home Agent, the traffic between the 2 is not necessarily routed via the infrastructure, but can stay confined within the mobile cloud, the Mobile Home Agent acting as a rendez- vous point between the Mobile Routers. This applies particularly well for a fleet at sea when the long haul access may be as expensive as a satellite link. 9. IANA considerations This document does not require any IANA action. 10. Security Considerations This document only explains how a home network can be deployed to support Mobile Routers and does not introduce any additional security concerns. Please see [RFC3963] for security considerations for the NEMO Basic Support protocol. 11. Changes An issue list is maintained at http://www.mobilenetworks.org/ ~pthubert/draft-ietf-nemo-home-network-models-issues.html . 11.1 Changes from version 00 to 01 Removed terminology (moved to the Nemo terminology draft).terminology). Added an applicability statement for all documented cases 11.2 Changes from version 01 to 02 Issue 1: Editorial Issue 2: Added a caveat part in Extended and Aggregated Home Network sections. Also added a MIP Home Network section prior to those. Issue 4: Added a subsection to the Extended Home Network case for the case when the mr takes a home address from its MNP 11.3 Changes from version 02 to 03 Issue 5: Editorial fixes. 11.4 Changes from version 03 to 04 Issue 6: Pass idnits. Thanks Henrik for this great tool :) 11.5 Changes from version 04 to 05 Issue 7: Virtual Home discussion Issue 8: Whether to recommend not to form a Home Address from MNP in Extended HN. Jari and Henrik's reviews Editorial changes 11.6 Changes from version 05 to 06 (IESG review) Issue 9: "Alternatives based on a routing protocol or ICMP redirect may apply in some cases." is not clear Issue 10: in a number of places text says "present in ... implementations" .. but what about the specifications?. Other review comments Editorial changes 12. 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. 13. References 13.1 normative reference  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.  Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03draft-ietf-nemo-terminology-04 (work in progress), FebruaryOctober 2005.  Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04draft-ietf-nemo-requirements-05 (work in progress), FebruaryOctober 2005. 13.2 informative reference  Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-00draft-ietf-nemo-ro-problem-statement-02 (work in progress), JulyDecember 2005.  Thaler, D., "Neighbor Discovery Proxies (ND Proxy)", draft-ietf-ipv6-ndproxy-03draft-ietf-ipv6-ndproxy-04 (work in progress), JulyOctober 2005.  Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-03draft-ietf-nemo-multihoming-issues-04 (work in progress), JulyOctober 2005. Authors' Addresses Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: email@example.com Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: firstname.lastname@example.org Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005).(2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.