Internet Engineering Task Force J. Palet Internet-Draft M. Diaz Expires: January 10, 2005 C. Olvera A. Vives Consulintel E. Fleischman Boeing D. Lanciani July 12, 2004 Analysis of IPv6 Multihoming Scenarios draft-palet-multi6-scenarios-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Multihoming seems to be one of the key pieces for the deployment of IPv6 in the enterprise scenario, but is becoming a frequent Palet, et al. Expires January 10, 2005 [Page 1] Internet-Draft IPv6 Multihoming Scenarios July 2004 requirement in all kinds of networks. In addition, other factors including the deployment of broadband networks, the increase in the variety of access technologies, the increase in the demand for resilience/redundancy, etc., in non-enterprise environments, for example in SOHO/home, necessarily imply the increase of IPv6 multihoming demand for a number of scenarios, which are described in this memo. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multihoming Motivations . . . . . . . . . . . . . . . . . . . 3 2.1 Technical motivations . . . . . . . . . . . . . . . . . . 3 2.2 Non-technical motivations . . . . . . . . . . . . . . . . 4 3. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 4 3.1 Internet Service Provider (ISP) . . . . . . . . . . . . . 4 3.2 IX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Enterprise . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 University/Campus . . . . . . . . . . . . . . . . . . . . 6 3.5 Security, Defense and Emergency . . . . . . . . . . . . . 6 3.6 SOHO and Home . . . . . . . . . . . . . . . . . . . . . . 7 3.7 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8 Add-hoc . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.9 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Special Services and Applications within the Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 GRIDs and other temporary networks . . . . . . . . . . . . 9 4.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Multihomed devices . . . . . . . . . . . . . . . . . . . . 9 4.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Real Time Traffic . . . . . . . . . . . . . . . . . . . . 9 4.6 Specific protocols/applications . . . . . . . . . . . . . 10 4.7 Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Palet, et al. Expires January 10, 2005 [Page 2] Internet-Draft IPv6 Multihoming Scenarios July 2004 1. Introduction The term multihoming refers to the practice of having a network connected to more than one ISP (connectivity provider, transit provider, upstream provider, etc.). A device can also be multihomed (e.g. host-centric multihoming), when it has more than one interface, and each of the interfaces is attached to different networks (may be within a multihomed network). In addition to that, in IPv6, each interface can have multiple addresses, which also means than even with a single interface, a host can be multihomed. Multihoming provides certain degree of resilience/redundancy against failures (link, hardware, protocols, others) and also enables features such as load balancing. Moreover, multihoming can be used in order to differentiate traffic based on policy, for non-technical reasons, such as cost associated with different flows, time of the day, etc. For highly distributed enterprises, it can also occur as an aid to address that enterprise's geographical distribution, and as a traffic engineering mechanism to improve local performance such as latency and hop count reductions for real time protocols. The scope of this document is to provide a brief description of the motivations for multihoming and an analysis of different scenarios where IPv6 multihoming could be relevant. 2. Multihoming Motivations Considering the goals for requiring multihoming described in [1], as well as other frequent issues, we can classify the motivations as both technical and non-technical. 2.1 Technical motivations The technical motivations are intended to provide resilience for the multihomed networks. 1. Redundancy: In order to protect the network against failures. These failures could be either in the multihomed network itself, or in the upstream (e.g. provider) network. The failures can be of very different types, including and not limited to: Link failures (physical, logical, configuration, ...), hardware failures (interfaces, routers, other equipment), protocol failures (routing protocol, others). 2. Load sharing/balancing: In order to distribute the inbound and/or Palet, et al. Expires January 10, 2005 [Page 3] Internet-Draft IPv6 Multihoming Scenarios July 2004 outbound traffic (e.g. between multiple providers). 3. Performance: As a traffic engineering mechanism to dampen the affects of upstream hub congestion through the use of "complementary" providers (e.g., in case the local Internet Exchanges are congested), avoiding for example, the traffic being forwarded thru longer routes than logically required. Some of these technical motivations could be partially solved by multi-attaching the network to the same ISP (i.e. load balancing), either in the same point-of-presence (POP) or via geographically separated POPs. Resilience can also be increased by using different routers, instead of just different interfaces. But in any case, load balancing alone doesn't provide a complete protection from failures in the upstream provider. For this reason, many sites may choose to attach to multiple ISPs (i.e. multihoming) so that a failure within the ISP will not necessarily isolate that site from the Internet as a whole. 2.2 Non-technical motivations A network can require multihoming for non-technical reasons. Financial considerations may influence the deployment, such as different cost or fees associated with with different traffic flows (with different priorities), or differing costs at different times of the day use, destination networks, accumulated bandwidth used, etc. Political motivations may exist such as the desire to be able to quickly change the provider, without renumbering. This motivation could stem from a wide variety of considerations including service charges, improved SLA, ISP bankruptcy, etc. Another non-technical motivation, which occurs very frequently in some scenarios (e.g. research and educations networks), is acceptable usage policy, where commodity traffic is not accepted, in general. 3. Multihoming Scenarios Different networking scenarios provide different multihoming cases or scenarios, which may have different peculiarities and requirements. They are listed below with no specific order or priority. 3.1 Internet Service Provider (ISP) An ISP is naturally multihomed when connected to two or more upstream providers. Actually this is a very common case, especially for medium and large ISPs. Palet, et al. Expires January 10, 2005 [Page 4] Internet-Draft IPv6 Multihoming Scenarios July 2004 In this scenario, the ISP will usually have its own address pool, in a provider independent fashion, allocated from a Regional Internet Registry (RIR). A multihomed ISP uses routing protocols to advertise its address space to several upstream providers. Some small ISPs only use one upstream provider, so in this case, multihoming will not apply. The National Research and Education Networks (NRENs) can be considered, from the multihoming perspective, as ISPs, because they are usually connected to several upstream providers, but they also have their own addressing space (allocated from a RIR). 3.2 IX Can an IX be multihomed, for example if they are layer 3 transit providers, distributed IXs ???. TBD. 3.3 Enterprise The size of any given enterprise network is a function of the size of the corporation it supports. Enterprise networks can therefore range from being small to being enormous. Larger enterprises may link together multiple buildings within a campus, multiple campuses within a region, multiple regions within a country, as well as have sites of various sizes within multiple countries. A few corporations even have corporate sites located within every country of the world. These sites may themselves be linked together via public (e.g., ISP) or private (e.g., dark fiber, satellite communications, modem connections over telephone networks) means. A distinction therefore needs to be made between a large corporation's private use of public (ISP) networking facilities to privately link together disparate parts of that corporation and that same corporation's public POPs to the worldwide Internet. The former is solely known (or, at least, it should be solely known) to the corporation and the supplier, the latter is advertised to the worldwide Internet infrastructure as the standard mechanism by which that corporation can be accessed. This distinction is important because the security mechanisms protecting these different uses (e.g., firewalls) are often very distinct from each other. Medium and large corporations are frequently attached to several ISPs, often for multihoming and load balancing reasons. Highly distributed corporations often have additional motivations for connectivity to multiple ISPs stemming from traffic engineering and performance considerations, particularly if real time traffic (e.g. Palet, et al. Expires January 10, 2005 [Page 5] Internet-Draft IPv6 Multihoming Scenarios July 2004 VoIP) is being internally supported. This kind of networks usually require a high resilience, because any outage, even when minimal, could mean a very high cost, that could justify the adoption of a multihoming solution even if this is expensive. Medium and small enterprise networks could fall in the category of Enterprise or in the SOHO one, which is very dependent on the specific resilience requirements. 3.4 University/Campus In principle, it seems that a University or Campus network fits in the same category as the enterprise network, except that its policies and security systems are very different, particularly because the university will not go out of business if the information contained within its computers becomes compromised. Is also important to recognize one more special non-technical requirement. Often they are connected in addition to commercial ISPs to non-commercial ISPs (NRENs), which don't allow commodity traffic, and consequently the network must control traffic based on policy. 3.5 Security, Defense and Emergency Military networks differ from university and corporate networks in that their computers and the networks themselves operate at specific classification levels. In military jargon, these are known as "Red networks". Each red network instance operates at a specific classification level (e.g., secret, sensitive-but-unclassified, etc.). Red networks operating at different classification levels may have disjoint (i.e., unrelated) address spaces from each other. In some military environments, Red networks are conveyed over physical media that can be protected. This is in contrast to Black networks, whose media cannot be similarly protected (e.g., wireless transmissions). Packets from Red networks may be conveyed over Black networks if the Red packets are first encrypted. In some cases, the encrypted Red packet may be encapsulated within an appropriate IP header of the Black network. But from the multihoming perspective, in principle, it seems that security and military networks fit into the same category as the enterprise network (for instance, as different networks for the Red and Black ones, and both could be also multihomed). This is also the case for civil and emergency networks, for example those used in airports, or by police/law enforcement, fireman, health Palet, et al. Expires January 10, 2005 [Page 6] Internet-Draft IPv6 Multihoming Scenarios July 2004 care, etc. and specially in the avenue of catastrophic events. The importance of multihoming here is related to the need of high reliability, because the failure could potentially increase the risk for human life. 3.6 SOHO and Home A Small Office/Home Office or Home, can fall into the category of a managed or unmanaged network. Usually there is a minimum management of the network, that could be done in-house, or as part of the service provided by the ISP, external consultants or systems integrators. Is becoming very frequent the case where different ISPs provide service to the same SOHO/Home network, by means of different access networks (xDSL, Cable, Wireless, PLC/BPL, etc.). A SOHO/Home network was usually a very small network with a single subnet, but this is also rapidly changing, and several subnets will be more frequently present in this scenario. Some times this network can be part of an enterprise network, and consequently managed, usually connected via a VPN to the corporate network, so in this case, the multihoming could depend on the VPN access itself. But is also the case when different hosts or different applications need to chose either the VPN (for example email or corporate applications), or the ISP (for example regular web access); in this case the multihoming case is the same as in the enterprise network scenario (the VPN behaves as a separate ISP). Today, the complete resilience of this network is already required, even if the solution cost is usually still too high. We can envision that the requirement for multihoming will become more frequent, specially considering the increase of tele-work and the usage of Internet for voice and video applications. So the SOHO/Home network is positioned to enjoy the greatest benefit from multihoming. Although those networks typically do not have access to "enterprise-class" links with guaranteed uptime (or any guarantee at all) it is not uncommon for multiple providers to offer technologically diverse residential services in a single area. Multihoming to two or more such services (e.g., DSL, cable, satellite, BPL/PLC, etc.) can dramatically increase the resistance of a SOHO/Home network to external single points of failure. Resilience in those networks is becoming an important issue in the face of residential VoIP deployment. While it is unlikely that an enterprise environment will be without any conventional phone lines in the near Palet, et al. Expires January 10, 2005 [Page 7] Internet-Draft IPv6 Multihoming Scenarios July 2004 future, residential consumers are already experimenting with Internet-only phone service. It will become critical to deliver reliability approaching that of conventional phone lines if we are to maintain E911 service, fire alarm monitoring, and similar life safety functions at their current levels of effectiveness. While such reliability may be delivered by a single provider in select areas, multihoming should allow a larger set of consumers to set and meet their own standards through multiple attachment. SOHO/Home networks may ultimately support life safety functions (e.g., health care, detectors, surveillance, etc.). The required reliability to monitor a smoke detector while a family sleeps is as least as great as that required by an enterprise where the most serious consequence of a network failure is likely financial. In some cases, a host-centric multihoming approach could be sufficient for this scenario. This could be the case when single devices are directly connected to several access networks, for example for safety or security reasons. 3.7 3GPP Is this the same as the mobility case ???. Can a GGSN be multi-homed ???. As IPv6 allows to have multiple addresses in each interface, the 3GPP terminal with a single interface can be multihomed using multiple IPv6 addresses with a single radio connection. Furthermore some 3GPP terminals are available with more than one interface (3GPP and WLAN) can be multihomed using one or several IP addresses in each interface. Similarly, a GGSN can have multiple IPv6 addresses per interface and several upstream links. 3.8 Add-hoc is this a special case ???. what about managed ad-hoc networks for the military domain ? 3.9 Mesh Mesh networks are those that use its nodes as routers so that every node does not have to hear every other node directly (as in the classic ad-hoc case). It is more likely in this case that the entire network may touch more than one "external" provider, and consequently is multihomed. Palet, et al. Expires January 10, 2005 [Page 8] Internet-Draft IPv6 Multihoming Scenarios July 2004 4. Special Services and Applications within the Multihoming Scenarios In addition to the generic scenarios, there are some special situations, services or applications, that could be parallel to any of the previously described cases, and should be considered in order to have a complete perspective for each of the above mentioned scenarios. 4.1 GRIDs and other temporary networks An organization with his own network and addressing being connected to a bigger network, for example in a GRID situation, in a temporary or quasi-permanent basis. This can be also the example for research institutions that often connect their networks to other networks and may receive new addressing space creating a multi-homing situation. 4.2 Mobility A mobile host or a mobile network can be simultaneously moving and still be attached to more than just one ISP. For example when connected simultaneously to a GPRS or 3GPP networks and a WISP (WLAN ISP). Much more text needed here !. 4.3 Multihomed devices Cellular phones with for example 3GPP and WLAN interfaces, laptops with 3GPP and Ethernet or even WLAN, all those are good examples of multihomed devices. This seems to be same as the host-centric multihoming case, but could also be related to the mobility scenario. 4.4 Renumbering When a network is being renumbered, temporarily, during the renumbering process itself, it may become a multihomed network. 4.5 Real Time Traffic The increase of the usage data networks and Internet for real time traffic (VoIP, video/audio streaming, videoconferencing, etc.). For example, the impact of the penetration of VoIP for residential usage (SOHO, home), could bring situations where the conventional phone lines disappear, while several access networks connect those sites. In this case, multihoming is much more critical to maintain the level of service required for emergency (e.g. E911, medical, security, ...) and similar life facilities that today depend on the Palet, et al. Expires January 10, 2005 [Page 9] Internet-Draft IPv6 Multihoming Scenarios July 2004 telephone. This is also specially relevant for rural areas, which today don't have copper connectivity, but are already attached to Internet by other means (satellite, PLC, WLAN, etc.). Of course this could be also true for other kind of networks, like enterprise, emergency, etc. 4.6 Specific protocols/applications Content Delivery Networks (CDNs), Internet Data Centers (IDC), DNS, DHCP, RA, ????. TBD. 4.7 Others any ??? TBD. 5. Security Considerations This memo does not generate any new security considerations. 6. IANA Considerations This document requests no action for IANA. [[Note to RFC-editor: this section can be removed upon publication.]] 7. Acknowledgements The authors would like to acknowledge the inputs from Jim Bound, Munechika Sumikawa, Antonio Tapiador, and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 8 Informative References [1] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. Palet, et al. Expires January 10, 2005 [Page 10] Internet-Draft IPv6 Multihoming Scenarios July 2004 Authors' Addresses Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Miguel Angel Diaz Fernandez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: miguelangel.diaz@consulintel.es Cesar Olvera Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: cesar.olvera@consulintel.es Alvaro Vives Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: alvaro.vives@consulintel.es Palet, et al. Expires January 10, 2005 [Page 11] Internet-Draft IPv6 Multihoming Scenarios July 2004 Eric Fleischman Boeing Phone: Fax: EMail: eric.fleischman@boeing.com Dan Lanciani Phone: Fax: EMail: ddl@danlan.com Palet, et al. Expires January 10, 2005 [Page 12] Internet-Draft IPv6 Multihoming Scenarios July 2004 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 ietf-ipr@ietf.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 (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. Palet, et al. Expires January 10, 2005 [Page 13]