Network Mobility P. Thubert Internet-Draft Cisco
SystemsExpires: September 30, 2004April 5, 2005 R. Wakikawa Keio University V. Devarapalli Nokia April 1,October 5, 2004 NEMO Home Network models draft-ietf-nemo-home-network-models-00draft-ietf-nemo-home-network-models-01 Status of this Memo This document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and isany of which I become aware will be disclosed, in full conformanceaccordance with all provisions of Section 10 of RFC2026.RFC 3668. 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.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 September 30, 2004.April 5, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This paper documents some usage patterns and the associated issues when deploying a Home Network for Nemo enabledNEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft .. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in theNEMO and NEMO Designrelated mailing lists. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 65 4. Extended Home Network . . . . . . . . . . . . . . . . . . . . 76 4.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Applicability . . . 8. . . . . . . . . . . . . . . . . . . 7 5. Aggregated Home . . . . . . . . . . . . . . . . . . . . . . . 98 5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1 Returning Home by egress . . . . . . . . . . . . . . . 9 5.2.2 Returning Home by ingress . . . . . . . . . . . . . . 10 5.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 10 6. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 11 7. Mobile Home6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Applicability . . . 13 8. Changes from version 00 to 01. . . . . . . . . . . . . . . . 15 9. Acknowledgements. . . 12 7. Mobile Home . . . . . . . . . . . . . . . . . . . . 16 References. . . . . 13 7.1 Configuration . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses. 13 7.2 Applicability . . . . . . . . . . . . . . . . . . . . . 17 A. Returning Home emulation in the virtual case. 14 8. Changes . . . . . . . . 18 Intellectual Property and Copyright Statements. . . . . . . . 19 1. Introduction This document assumes that the reader is familiar with Mobile IPv6 as defined in , and with the concept of Mobile Router defined in the NEMO terminology document . Four different organizations of the Home Network including a hierachical construction are documented: Extended Home Network: In this disposition, the Home Network is but one subnet of a larger aggregation that encompasses the Mobile Networks, called extended. . . . . . . . . . . 16 8.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Returning Home Network. When at Home, a Mobile Router performs normal routing betweenemulation in the Home Linkvirtual case . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 1. Introduction This document assumes that the Mobile Networks. Aggregated Home Network: In this disposition, the Home Network actually overlapsreader is familiar with the Mobile Networks. When at Home, a Mobile Router actsIPv6 Mobility as a bridge betweendefined in , with the Home LinkNEMO Basic Support  and with the Mobile Networks. Virtual Home Network: In this disposition, there is no physical Home Link at all for the Mobile Routers to come back Home to. Mobile Home Network: In this disposition, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent and further subnetted into Mobile Networks. Each subnet is owned by a Mobile Router that registers it in aNEMO fashion while acting as a Home Agent for that network.terminology document . In all cases, the Home Agents collectively advertise only the aggregation oforder to read this document properly, the Mobile Networks. The dichotomy is kept withindistinction between the concepts of Home AgentsLink and the Mobile Routers, as opposed to advertised by meansof routing protocols to other parties. Also, itHome Network must be very clear. A Home Link is valid fora Mobile Routerphysical or a virtual Link, attached to register usinga Home Agent. A Home Network is an address from one of its own NEMO-Prefixes in all three cases. The examples provided here aim at illustratingaggregation that can be further subnetted. As a result, the NEMO Basic Support draft  butHome Network is not necessarily contained on a Home Link. In fact, the Mobile Network Prefixes are by no mean at limiting its scopesubnets of application. 2. Terminology andthe Home Network. How the two concepts The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONALrelate in this document are to be interpreteda given deployment depend on the organization of the Home Network, as described in RFC2119 . The following terms used in this document are defined inbelow. Four different organizations of the IPv6 Addressing Architecture document : link-local unicast address link-local scope multicast address The following terms used in this documentHome Network including a hierarchical construction are defined in the mobile IPv6 specification : home agent (HA) The following terms used indocumented: Extended Home Network: In this document are defined indisposition, the mobile network terminology document : mobile router (MR) mobile network mobile host (MH) This draft usesHome Network is only one subnet of a larger aggregation that encompasses the following additional or modified terminology:Mobile Networks, called extended Home Link: The link attached toNetwork. When at Home, a Mobile Router performs normal routing between the interface atHome Link and the Mobile Networks. More in Section 4. Aggregated Home Agent on whichNetwork: In this disposition, the Home Prefix is configured. The interface can beNetwork actually overlaps with the Mobile Networks. When at Home, a virtual interface, in which caseMobile Router acts as a bridge between the Home Link is a virtual Home Link.and the Mobile Networks. More in Section 5. Virtual Home Network: The Network formed by the application of theIn this disposition, there is no physical Home Prefix onLink at all for the Mobile Routers to come back Home Link. With NEMO, the concept ofto. More in Section 6. Mobile Home NetworkNetwork: In this disposition, there is extended as explained below. Home Address: With Mobile IPv6,a bitwise hierarchy of Home Address is derived from theNetworks. A global Home Network prefix. Thisis generalized in NEMO, with some limitations: A Home Address can be either derived fromadvertised to the infrastructure by a head Home Network or from one of theAgent and further subnetted into Mobile Router's NEMO-prefixes. MRHA Tunnel: The bi-directional tunnel betweenNetworks. Each subnet is owned by a Mobile Router and itsthat registers it in a NEMO fashion while acting as a Home Agent Mobile Aggregated Prefix: Anfor that network. More in Section 7. In all cases, the Home Agents collectively advertise only the aggregation of NEMO-Prefixes. Aggregated Home Network:the Mobile Networks. The dichotomy is kept within the Home Network associated with aAgents and the Mobile Aggregated Prefix. This Aggregation is advertisedRouters, as a subnet onopposed to advertised by means of routing protocols to other parties. The examples provided here aim at illustrating the NEMO Basic Support draft  but do not aim at limiting its scope of application, and additional cases may be added in the Home Link,future. 2. Terminology and thus usedconcepts 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 Home Network for NEMO purposes. Extended Home Network:described in RFC2119 . The network associated withfollowing terms used in this document are defined in the aggregationIPv6 Addressing Architecture document : link-local unicast address link-local scope multicast address Most of one or more Home Network(s)the mobility related terms used in this document are defined in the Mobility Related Terminology document  and Mobile Network(s). As opposed toin the Mobile IPv6 Home Network that is a subnet, the(MIP6) specification . Additionally, some terms were created or extended Homefor NEMO. These specific terms are defined in the Mobile Network is an aggregation and is further subnetted. VirtualTerminology document : Home Network: TheLink Home Network associated with a Virtual Network. The ExtendedHome Network and theAddress MRHA Tunnel Mobile Aggregated Prefix Aggregated Home Network can be configured asExtended Home Network Virtual Home Network.Network Mobile Home Network: A MobileNetwork that is also a Home Network. The MR that own the NEMO-Prefix acts as a Home Agent for it.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, say that 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). Say that a Mobile Router, MR1, owns the NEMO-PrefixMNP A:B:C:1::/64: With basic NEMO,NEMO Basic Support, and depending on the deployment, MR1 may register using a Home Address from the Home network, A:B:C:0::1, say, or a Home Address, A:B:C:1::1, say, from one of its NEMO-Prefixes.MNPs. In a given deployment, one subnet may be reserved for the Home Link (say A:B:C:0::/64) while the others are attributed to Mobile Routers as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be to configure the Aggregation of Mobile Networks as the subnet on the Home Link, and let the Mobile Routers manage the overlapping networks. Finally, the aggregation could be configured on a virtual network, with no physical Home Link at all, in which case Home means topologically and administratively close to the Home Agent that owns the virtual network. The following sections provide additional information on these forms of Home Network:Network. 4. Extended Home Network 4.1 Configuration One simple approach can beis to reserve one or several subnets from an aggregation for the Home Link, and to use the other subnets as NEMO-Prefixes.MNPs. In that case, the Home Network and the Mobile Networks do not overlap. The aggregation is called an extendedExtended Home Network.Network and depicted in Figure 1. | route v /48 A:B:C::/48 HA | /64 A:B:C:0::/64 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N extendedExtended Home Network <-----------------------------------------------------------> Home Net Mobile Net Mobile Net ... Mobile Net <------------><------------><------------> ... <------------> Figure 1: Extended Home Network In that configuration: o There is one physical Home Network and multiple Mobile Networks o The Home and the NEMO-prefixesMNPs are tailored to allow for IPv6 Stateless Address Autoconfiguration with typical interface identifier length for the type of interface (can be for example / 64)./64). o The prefix length of the extendedExtended Home Network is shorter than that of the Home Network and the NEMO-prefixes,MNPs, since it is an aggregation (can be for example /48). o The Mobile Routers are assigned individually a Home Address from the Home Network and use is to register their NEMO-Prefix(es).MNP(es). In that case, the Home Agent performs DAD in the Home Network as prescribed by Mobile IPv6 for the Home Addresses. o Alternatively, a Mobile Router could also form a Home Address from one of its prefixes and use it to register, performing its own DAD on its ingress network. 4.14.2 Returning Home In the extendedExtended 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. If the Home Address of the Mobile Router is derived from one of its Mobile Networks,Network Prefixes, then the MR may connect to the Home Link using an egress interface and autoconfigure an address on the Home Link. The MR recognizes the prefix of its Home Agent in order to decide that it is Home. Note that in that case the Home Address does not match the Home Prefix. When at Home,home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations. In particular, if the HA has the necessary information to continue routing to the NEMO-PrefixesMNPs in the absence of registration, for instance if the Home Address of the Mobile Router is derived from the Home Network, and if the HA uses a static route to the NEMO-Prefix(es)MNP(es) via that address, then the participation of the MR to the Home IGP is not required. But in the general case, when the MR is at Home, it resumes IGP operations on the Home Link in order to advertise its Mobile Networks. Alternate procedures for ensuring the connectivity of the Mobile Networks when at Homehome are described in Section 6. In Particular,4.3 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 affected to MNPs and prefix(es) that are dedicated to the Home Link, it is possible for MNs and MRs to coexist with that model. 5. Aggregated Home 5.1 Configuration One other approach is to consider that the Aggregation of all the NEMO-prefixesMNPs is used plainly as the Home Network, referedreferred to as the 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.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 <------------><------------><------------> ... <------------> Note: a Mobile Router comingFigure 2: Aggregated Home sees overlapping prefixes between the ingress and the egress interface and some specific support may be needed.A node on the Home Link will computecomputes that the Aggregated Home Network is actually a subnet on the Home Link and may use it for autoconfiguration purposes. Such a node may 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 NEMO-Prefix,MNP, it will lookup all MNNs using Neighbor Discovery over the Home Link. Thus, the Home Agent MUST intercept all the packets to the MNNs on the registered prefixes. In order to do so, the Home Agent MAYmight perform ND proxying for all addresses in all registered Mobile Network Prefixes, and protect the NEMO-PrefixMNP space from autoconfiguration by uncontrolled visitors on the Home Link. Alternatives based on a routing protocol or ICMP redirect may apply in some cases. 5.15.2 Returning Home The Aggregated Home Prefix is configured on a physical interface of the Home Agent, the Home Link. As a consequence, the Home Agent has a connected route to the Aggregated Home Network over the Home Link. A Mobile Router returns Home by connecting directly to the Home Link, and dropping the MRHA tunnel. The Mobile Router recognizes its Home Link by a prefix match with its Home Agent. Note that it must expect a shorter prefix than that of its Mobile Networks, even if its Home Address is formed out of one of its NEMO-Prefixes,MNPs, but that the Home Address matches the Home Network Prefix. Also, 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 unicity of the suffix. That unicity can be checked by the MR on its ingress network using DAD. 5.2.1 Returning Home by egress 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 MAYmight set up a bridge between its ingress interface(s) and the Home Link. Alternatively, the Mobile Router MAYmight perform ND proxying for all addresses in its NEMO-Prefixes,MNPs, between the egress and the related ingress interface. Since the prefixes on the egress and ingress interfaces are overlapping, routing is disallowed. HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <= N Figure 3: Bridging between egress and ingress 5.2.2 Returning Home by ingress Alternatively, if the MR has a single ingress Interface, the Mobile Router may use the Mobile LinkNEMO-Link to connect to the Home Link, merging the two links in a single consistent network. HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- /64 /64 /64 /64 Aggreg|i /64 0 < i <= N ------ ------ ------ ------ MR1 MR2 MRi MRN | | | | 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. . 5.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. A MR 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 MR needs to act as a bridge to enable it. In order to deploy the aggregated Home Network model, one must check whether that support is available in the MRs if returning Home is required. 6. Virtual Home Network 6.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 or for Home Agents to discover each others and perform the ND level interactions as described in Mobile IPv6.  /48 eg: A:B:C::/48 HA | /64 A:C:C:E::/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 networkNetwork and the Aggregated Home networkNetwork models can be adapted for virtual links. There is no change in the way Home Addresses are allocated.As in the case of a physical link, the Home Address of a Mobile router iscan be constructed based on a dedicated subnet of the Home Prefix or one of the prefixes of its Mobile Network(s).MR 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. ).). In order for a Mobile Router to emulate returning Home, it can connect to one or more access link(s) configured for that purpose on the Home Agent. The Mobile Router, after connecting to the access link, SHOULD not send any routing protocol updates on the egress interface because the routing information from the Mobile Router might adversely affect IPv6 route aggregation on the Home Network. However, the Mobile Router must register its binding as if it was accessing a foreign link. There are also some drawbacks to the virtual Home Link approach: There can be only one Home Agent since Mobile IPv6 relies on Neighbor Discovery on the Home Link for other HA discovery and for Duplicate Address Detection. The Home Agent must maintain a Binding Cache entry for a Mobile Router and forwarding state for its Mobile Network even when the Mobile Router is directly connected to it. All traffic to and from the Mobile Network is sent through the bi-directional tunnel regardless of the Mobile Router location. This results in a tunneling overhead even though the Mobile Router is connected to the Home Network. Some solutions can be proposed in order to perform an equivalent of returning Home on a virtual Home Network. One such approach is sketched in appendix as an illustration. 6.2 Applicability At some point in the future, NEMO basic support may be extended to operate fully at L3 for instance if the HAHA protocol  gets standardized and deployed. Until then, NEMO operations still inherit from mobile IPv6  for the HA to HA communication, which is basically based on Neighbor Discovery extensions over the Home Link. Making that 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  draft for more on this. Yet, for a deployment where a single HA is enough, making the Home Link virtual reduces the vulnerability to some attacks and to some hardware failures, while making the HA operation faster. One should check with the product specifications of an HA to see whether the implementation actually supports a Virtual Home Network, and if so, whether in that cases, it is optimized for faster DAD-less bindings. 7. Mobile Home 7.1 Configuration In this disposition, 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 NEMO-prefixes,MNPs, which are leaves in the hierarchy tree. Each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network. This Mobile Router is at Home at the upper level of hierarchy. This configuration is referred to as Mobile Home. An example of that is the Cab Co configuration. Say a Taxi Company owns a /32 prefix. This prefix is advertised at a fixed point, the Headquarters say. Regional offices are deployed around the world. Even though these regional offices are relatively stable in terms of location and prefix requirement -say this changes every few years- making them mobile allows a simpler management when a move has to take place, or should the ISP service change. Finally, each regional office owns a number of taxis, each one equipped with a mobile router and an associated /64 prefix. To illustrate this, here is a possible addressing scheme:global Home Network CAB:C0::/32 owned 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 recursively foran associated /64 prefix. For each Office, say San Francisco (SFO) as an example: Mobile Home Network CAB:C0:5f0::/48CAB:C0:5F0::/48 owned by SFO office <------------------------------------------------------------------> HQSFO Home Network Mobile Networks for taxis for officestaxis <---------------------...---------------------> CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/6 <-------------------><-------------------> ... <-------------------> CAB:C0:5F0:5F0::5F0 | is HA on link with for | each taxi a route like | | CAB:C0:5F0:5F0::CAB1 <------ via is the Home addrSsync of CAB 1 Figure 7: CAB Company regional configuration Note that the hierarchy occurs at a configuration level and may not be reflected in the actual connection between nodes. For instance in the Cab Co case, cabs are roaming within the city, each one attaching to a different hot spot, while the regional office is connected to the infrastructure using some ISP connection. But it is also possible to reflect the organizational hierarchy in a moving cloud of Mobile Router. If a Mobile Home Agent acts as root-MR for a nested configuration of its own MRs, then the communication between MRs is confined within the nested structure. This can be illustrated in the case of a fleet at sea. Say that now 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 cabs, the communication between cabs is relayed by SFO and does not require the satellite link. SFO recursively terminates the nested tunnels to the cabs and reencapsulates all the packets between the nested cloud and correspondents in the infrastructure in a single tunnel to CA5A, this providing for nested NEMO Route Optimization. 7.2 Applicability This complex topology applies to 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 HA could be located. One specific benefit is that when 2 MRs travel together with a common HA, 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 MRs. This applies particularly well for a fleet at sea when the long haul access may be as expensive as a satellite link. 8. Changes 8.1 Changes from version 00 to 01 Removed terminology (moved to the Nemo terminology draft). Added Mobile Home Sectionan applicability statement for all documented cases 9. Acknowledgements The authors wish to thank: Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick Wetterwald and Alexandru Petrescu for their contributions. 10 References  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.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. RFC 3775, June 2004.  Devarapalli, V., "Nemo"Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-02draft-ietf-nemo-basic-support-03 (work in progress), December 2003. June 2004.  Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02 (work in progress), February 2004.  Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004.  Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004.  Ernst, T., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-00 (work in progress), July 2004. Authors' Addresses Pascal Thubert Cisco Systems Technology CenterVillage 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 Appendix A. Returning Home emulation in the virtual case When a Home Link is virtual, all traffic to and from the Mobile Network is sent through the bi-directional tunnel even at the Home Link. This section describes one possible mechanism that extends basicNEMO Basic Support to eliminate this tunneling overhead. Although the Home Link is virtual, the Home Agent has at least one physical link to communicate with the external world. One or several of such links, called the virtual Home Access Links, are conceptually associated with the virtual Home Link and considered as part of Home. When accessing one of its virtual Home Access Links, a Mobile Router autoconfigures a Care-of Address from a Router Advertisement as it would do on any visited link, in order to perform the next binding flow. If the Mobile Router is configured to recognize the virtual Home Access Links as part of Home, it deregisters by sending a Binding update with null lifetime sourced at the CareOf. Alternatively, the Home Agent may indicate that the MR has moved to the virtual Home Access Links as a status code in the binding acknowledgement. The status code implies that Home Agent successsful de-register the binding at the virtual Home Access Link. Detection of the virtual Home Access Links is achieved by a prefix comparison(s) between the care-of address and the prefix(es) on the virtual Home Access Link(s). With both approaches, the result of the binding flow is a deregistration. Consequently, both the Mobile Router and the Home Agent disable the bi-directional tunnel. At that point, the Home Agent configures its forwarding in order to reach the Mobile Router and its mobile networks at Home. For instance, this may take the form of a route to the Mobile Network prefixes via the MR Home Address, and a connected host route to the MR Home Address via the virtual Home Access link. After successful binding de-registration, the Mobile Router MUST receive packets meant to the Mobile Router's Home Address at the Virtual Home Link. How to intercept packets addressed to the Home Address depends on implementations of the Mobile Router. If the Home Address is not configured at the egress interface, the Mobile Router MUST use proxy Neighbor Discovery to intercept all packets addressed to the Home Address on the virtual Home Link. Otherwise, the Mobile Router does not have to perform any special operation at the virtual Home Link. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual 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; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto 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 implementorsimplementers or users of this specification can be obtained from the IETF Secretariat.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 whichthat may cover technology that may be required to practiceimplement this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purposeat firstname.lastname@example.org. Disclaimer of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.Validity This document and the information contained herein isare 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 DISCLAIMSDISCLAIM 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 (2004). 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.