Network Working Group W. Haddad Internet-Draft Ericsson Intended status: Informational D. Saucez Expires: April 3, 2015 INRIA Sophia Antipolis J. Halpern Ericsson September 30, 2014 Multihoming in Homenet draft-haddad-homenet-multihomed-04 Abstract Multihoming becomes popular in residential and SME networks indicating the absolute necessity of fully supporting multihoming in Homenet. While the approach followed in Homenet is to delegate multihoming management to hosts, we propose to enable multihoming in Homenet by the mean of the infrastructure instead of the hosts. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 3, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Haddad, et al. Expires April 3, 2015 [Page 1] Internet-Draft Multihoming in Homenet September 2014 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Homenet multihoming without host involvement . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Homenet multihoming with MSP . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction So far, multihoming in Homenet must be supported by the hosts with solutions like Shim6 [RFC5533] or MPTCP [RFC6182] as there is no mean to use simultaneously the different ISPs of the Homenet without risking flow disruption. In this memo, we propose the creation of a new multihoming service for Homenets. The concept relies on a middlebox added between the home network and its gateways with the ISPs. On the one hand, this middlebox is in charge to redirect the home network traffic to a multihoming service provider (MSP) by selecting the most appropriate Homenet's ISPs. On the other hand, the MSP is in charge of attracting traffic normally destined to the home network and then, the MSP can eventually redirect the traffic to its final destination, the Homenet itself, such that it enters the Homenet via the most appropriate ISP. Section 2 describes the multihoming problem in Homenet when hosts cannot support it directly. Section 3 gives the necessary requirements. Section 4 sketches a possible solution to that problem. Haddad, et al. Expires April 3, 2015 [Page 2] Internet-Draft Multihoming in Homenet September 2014 2. Homenet multihoming without host involvement It is known that multihoming reduces costs for ISPs by allowing higher aggregated bandwidth, better quality of service, and higher robustness. Alternatively, the access to multiple ISPs at the same time for residential and SME users is now a reality, e.g., ADSL + Cable + 4G, but there is currently no simple solution for home networks to exploit it. For now, the only solution is to modify end-hosts with protocols such as Shim6 or MPTCP in order for hosts to change IP addresses on elapsing communications. We claim that multihoming for Homenets will become a reality and will provide the same benefits as those observed for the ISPs. Also, requiring every single device in the Homenet to be modified to support multihoming is not acceptable as some devices have limited resources and cannot achieve it correctly and also because it would dramatically slow down the adoption of multihoming in the Homenet. Finally, letting every device deciding of the routing strategy (e.g., shall I route my traffic via left or right ISP?) might cause management issues. At the light of this, the question can be: How can we achieve multihoming in Homenets, without changing neither the devices connected to the Homenet, nor the protocols and operations of the Homenet's ISPs? 3. Requirements In order to fix the solutions space of our problem, we have isolated fours requirements. As we are in the context of Homenet, requirement (1) is to have zero configuration need at the Homenet user level. Multihoming must be transparent for users and devices. Also, residential and SME network operators (i.e., John/Jane Does) seldom have enough power to make specific settlements or negotiations with their ISP, the solution thus have to be completely independent of the network's ISPs and the ISPs cannot have any mean to forbid the solution. Requirement (2) is thus ISP independence. Multihoming offers the possibility to implement policies, and to some extend even capabilities, at any arbitrary level. For example, the home network can determine the number of ISPs it is using simultaneously or limit flows for example to only go via one Haddad, et al. Expires April 3, 2015 [Page 3] Internet-Draft Multihoming in Homenet September 2014 particular ISP at a given speed. Requirement (3) is thus policies/ capabilities. Finally, and this is related to policies and capabilities, the system must be able to provide quality of service (to some extend)to ensure Quality of Experience. We call the requirement (4) Quality of Service. 4. Homenet multihoming with MSP To offer fast and efficient deployment of multihoming in residential and SME networks, a dedicated middlebox is added to be in charge of dealing with multihoming, on behalf of the devices. This middlebox is logically linked with a Multihoming Service Provider (MSP). The role of the MSP is to achieve the multihoming for the Homenet by using offloading: the Homenets, by the mean of the middlebox, offloads all its Internet traffic to the MSP, and the offloading is such that the traffic leverages the Homenet's multihoming capability. The MSP can be seen as a service in the cloud (in a remote network or in devices widely deployed by the MSP in the ISPs). The service is two-fold. On the one hand, the MSP must attract the traffic sent by the Homenet to the Internet, this part is ensured by the middle-box deployed at the Homenet. On the other hand, the MSP must attract traffic sent by the Internet to the Homenet, before this last can receive it. Then, the MSP can send this traffic to the Homenet via the most relevant ISP. The figure below gives a reference network for the multihoming service for Homenet. Haddad, et al. Expires April 3, 2015 [Page 4] Internet-Draft Multihoming in Homenet September 2014 `. MSP ,' `.---+----.' | .-----. .+------+--------+. .' '. .' `-. | REMOTE |.-' `\ . . `. '.-----.' Internet \ | + : .-----. .-----. ; `. .' '. .' '. .' '.| ISP1 | | ISP2 |-' . .`------'. . '.--+--.' '.--+--.' | | .-----|-------------------|------. .' +--+--+ +--+--+ '. / | Gw1 | HOMENET | Gw2 | \ .' +--+--+ +--+--+ '. '. .' \ +-------+ ./ '.| MSPMB |.' +---+---+ | ____+____ LAN Figure 1: Reference Network In this figure, HOMENET is the multihomed Homenet, connected to ISP1 via gateway Gw1 and to ISP2 via gateway Gw2. The remote end of communications with the Homenet is designated by REMOTE. MSPMB designates the MSP middlebox in the home network and is logically linked to the MSP multihoming service provider. Let's imagine that the best to send traffic from the Homenet to the remote end is to go via ISP2 while for the traffic from the remote end to the Homenet it is better to go via ISP1. In this case, the traffic generated from Homenet's LAN is caught by MSPMB that divert traffic to Gw2, then crosses ISP2 and the Internet to reach MSP, then REMOTE. On the other direction, traffic sent by REMOTE goes to MSP that sends the traffic on the Internet to ISP1, then it goes to Gw1, MSPMB, and finally the LAN. The Multihoming Service Provider (MSP) would typically be operated on an AS well connected to Homenet's ISPs. Or alternatively, a Service provider that has its own devices deployed at the Homenet's ISPs. Haddad, et al. Expires April 3, 2015 [Page 5] Internet-Draft Multihoming in Homenet September 2014 As Homenet is targeting IPv6 networks, communications between the Homenet and the MSP cannot rely on NAT but instead they might use encapsulation. For that purpose, LISP [RFC6830] is a perfect candidate. In this case, the MSPMB is an xTR. To ensure zero configuration at the Homenet level, the EID-to-RLOC Cache can be populated on the fly by a mapping system hosted and managed by the MSP. A major advantage of using LISP for communications between the MSP and the Homenet is that residential and SME networks would then have access the IPv6 Internet without the need of subscribing to IPv6 ISPs. The service we propose answers the problem exposed in Section 3 in an elegant way. It also fulfills the four requirements stated above. Requirement (1) (zeroconf) is respected if MSPMB is given directly by the MSP, which can thus be pre-configured to access the MSP service provider. If it is not the case, the process can be simplified if a generalized name and protocol is used to configure the middlebox (e.g., msp.example.org). In addition, if Gw1 and Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the MSPMB will be configured automatically as well. Obviously, policies and capabilities need configuration either from the home network operator or the MSP directly (which is straightforward with LISP). Finally, UPnP can be used for special services provided to the Homenet by its ISPs. 5. Security Considerations Traffic redirection can be used for DoS or eavesdropping. 6. Conclusion Multihoming in Homenet is considered to be solved by the hosts directly. In this memo, we propose to not involving host in multihoming operations and instead rely on a Multihoming Service Provider deploying a middlebox in the Homenet network in charge of operating multihoming services. 7. Normative References [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. Haddad, et al. Expires April 3, 2015 [Page 6] Internet-Draft Multihoming in Homenet September 2014 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. Authors' Addresses Wassim Haddad Ericsson 6210 Spine Road Boulder, CO 80301 USA Email: Wassim.Haddad@ericsson.com Damien Saucez INRIA Sophia Antipolis 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Email: damien.saucez@inria.fr Joel Ericsson P.O. Box 6049 Leesburg, VA 20178 USA Email: Joel.Halpern@ericsson.com Haddad, et al. Expires April 3, 2015 [Page 7]