idnits 2.17.1 draft-haddad-homenet-multihomed-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2015) is 3130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Ericsson 4 Intended status: Informational D. Saucez 5 Expires: April 3, 2016 INRIA Sophia Antipolis 6 J. Halpern 7 Ericsson 8 October 1, 2015 10 Multihoming in Homenet 11 draft-haddad-homenet-multihomed-06 13 Abstract 15 Multihoming becomes popular in residential and SOHO networks 16 indicating the absolute necessity of fully supporting multihoming in 17 Homenet. While the approach followed in Homenet is to delegate 18 multihoming management to hosts, we propose to enable multihoming in 19 Homenet by the mean of the infrastructure instead of the hosts. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 3, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Homenet multihoming without host involvement . . . . . . . . 3 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Homenet multihoming with MSP . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 So far, multihoming in Homenet must be supported by the hosts with 79 solutions like Shim6 [RFC5533] or MPTCP [RFC6182] as there is no mean 80 to use simultaneously the different ISPs of the Homenet without 81 risking flow disruption. In this memo, we propose the creation of a 82 new multihoming service for Homenets. The concept relies on a 83 middlebox added between the home network and its gateways with the 84 ISPs. On the one hand, this middlebox is in charge to redirect the 85 home network traffic to a multihoming service provider (MSP) by 86 selecting the most appropriate Homenet's ISPs. On the other hand, 87 the MSP is in charge of attracting traffic normally destined to the 88 home network and then, the MSP can eventually redirect the traffic to 89 its final destination, the Homenet itself, such that it enters the 90 Homenet via the most appropriate ISP. 92 Section 2 describes the multihoming problem in Homenet when hosts 93 cannot support it directly. Section 3 gives the necessary 94 requirements. Section 4 sketches a possible solution to that 95 problem. 97 2. Homenet multihoming without host involvement 99 It is known that multihoming reduces costs for ISPs by allowing 100 higher aggregated bandwidth, better quality of service, and higher 101 robustness. 103 Alternatively, the access to multiple ISPs at the same time for 104 residential and SOHO users is now a reality, e.g., ADSL + Cable + 4G, 105 but there is currently no simple solution for home networks to 106 exploit it. For now, the only solution is to modify end-hosts with 107 protocols such as Shim6 or MPTCP in order for hosts to change IP 108 addresses on elapsing communications. 110 We claim that multihoming for Homenets will become a reality and will 111 provide the same benefits as those observed for the ISPs. Also, 112 requiring every single device in the Homenet to be modified to 113 support multihoming is not acceptable as some devices have limited 114 resources and cannot achieve it correctly and also because it would 115 dramatically slow down the adoption of multihoming in the Homenet. 116 Finally, letting every device deciding of the routing strategy (e.g., 117 shall I route my traffic via left or right ISP?) might cause 118 management issues. 120 At the light of this, the question can be: How can we achieve 121 multihoming in Homenets, without changing neither the devices 122 connected to the Homenet, nor the protocols and operations of the 123 Homenet's ISPs? 125 3. Requirements 127 In order to fix the solutions space of our problem, we have isolated 128 fours requirements. 130 As we are in the context of Homenet, requirement (1) is to have zero 131 configuration need at the Homenet user level. Multihoming must be 132 transparent for users and devices. 134 Also, residential and SOHO network operators (i.e., John/Jane Does) 135 seldom have enough power to make specific settlements or negotiations 136 with their ISP, the solution thus have to be completely independent 137 of the network's ISPs and the ISPs cannot have any mean to forbid the 138 solution. Requirement (2) is thus ISP independence. 140 Multihoming offers the possibility to implement policies, and to some 141 extend even capabilities, at any arbitrary level. For example, the 142 home network can determine the number of ISPs it is using 143 simultaneously or limit flows for example to only go via one 144 particular ISP at a given speed. Requirement (3) is thus policies/ 145 capabilities. 147 Finally, and this is related to policies and capabilities, the system 148 must be able to provide quality of service (to some extend)to ensure 149 Quality of Experience. We call the requirement (4) Quality of 150 Service. 152 4. Homenet multihoming with MSP 154 To offer fast and efficient deployment of multihoming in residential 155 and SOHO networks, a dedicated middlebox is added to be in charge of 156 dealing with multihoming, on behalf of the devices. This middlebox 157 is logically linked with a Multihoming Service Provider (MSP). The 158 role of the MSP is to achieve the multihoming for the Homenet by 159 using offloading: the Homenets, by the mean of the middlebox, 160 offloads all its Internet traffic to the MSP, and the offloading is 161 such that the traffic leverages the Homenet's multihoming capability. 163 The MSP can be seen as a service in the cloud (in a remote network or 164 in devices widely deployed by the MSP in the ISPs). The service is 165 two-fold. On the one hand, the MSP must attract the traffic sent by 166 the Homenet to the Internet, this part is ensured by the middle-box 167 deployed at the Homenet. On the other hand, the MSP must attract 168 traffic sent by the Internet to the Homenet, before this last can 169 receive it. Then, the MSP can send this traffic to the Homenet via 170 the most relevant ISP. 172 The figure below gives a reference network for the multihoming 173 service for Homenet. 175 `. MSP ,' 176 `.---+----.' 177 | 178 .-----. .+------+--------+. 179 .' '. .' `-. 180 | REMOTE |.-' `\ 181 . . `. 182 '.-----.' Internet \ 183 | + 184 : .-----. .-----. ; 185 `. .' '. .' '. .' 186 '.| ISP1 | | ISP2 |-' 187 . .`------'. . 188 '.--+--.' '.--+--.' 189 | | 190 .-----|-------------------|------. 191 .' +--+--+ +--+--+ '. 192 / | Gw1 | HOMENET | Gw2 | \ 193 .' +--+--+ +--+--+ '. 194 '. .' 195 \ +-------+ ./ 196 '.| MSPMB |.' 197 +---+---+ 198 | 199 ____+____ LAN 201 Figure 1: Reference Network 203 In this figure, HOMENET is the multihomed Homenet, connected to ISP1 204 via gateway Gw1 and to ISP2 via gateway Gw2. The remote end of 205 communications with the Homenet is designated by REMOTE. MSPMB 206 designates the MSP middlebox in the home network and is logically 207 linked to the MSP multihoming service provider. 209 Let's imagine that the best to send traffic from the Homenet to the 210 remote end is to go via ISP2 while for the traffic from the remote 211 end to the Homenet it is better to go via ISP1. In this case, the 212 traffic generated from Homenet's LAN is caught by MSPMB that divert 213 traffic to Gw2, then crosses ISP2 and the Internet to reach MSP, then 214 REMOTE. On the other direction, traffic sent by REMOTE goes to MSP 215 that sends the traffic on the Internet to ISP1, then it goes to Gw1, 216 MSPMB, and finally the LAN. 218 The Multihoming Service Provider (MSP) would typically be operated on 219 an AS well connected to Homenet's ISPs. Or alternatively, a Service 220 provider that has its own devices deployed at the Homenet's ISPs. 222 As Homenet is targeting IPv6 networks, communications between the 223 Homenet and the MSP cannot rely on NAT but instead they might use 224 encapsulation. For that purpose, LISP [RFC6830] is a perfect 225 candidate. In this case, the MSPMB is an xTR. To ensure zero 226 configuration at the Homenet level, the EID-to-RLOC Cache can be 227 populated on the fly by a mapping system hosted and managed by the 228 MSP. A major advantage of using LISP for communications between the 229 MSP and the Homenet is that residential and SOHO networks would then 230 have access the IPv6 Internet without the need of subscribing to IPv6 231 ISPs. 233 The service we propose answers the problem exposed in Section 3 in an 234 elegant way. It also fulfills the four requirements stated above. 235 Requirement (1) (zeroconf) is respected if MSPMB is given directly by 236 the MSP, which can thus be pre-configured to access the MSP service 237 provider. If it is not the case, the process can be simplified if a 238 generalized name and protocol is used to configure the middlebox 239 (e.g., msp.example.org). In addition, if Gw1 and Gw2 provide 240 addresses by the mean of DHCPv6 or RA, addresses at the MSPMB will be 241 configured automatically as well. Obviously, policies and 242 capabilities need configuration either from the home network operator 243 or the MSP directly (which is straightforward with LISP). Finally, 244 UPnP can be used for special services provided to the Homenet by its 245 ISPs. 247 5. Security Considerations 249 Traffic redirection can be used for DoS or eavesdropping. 251 6. Conclusion 253 Multihoming in Homenet is considered to be solved by the hosts 254 directly. In this memo, we propose to not involving host in 255 multihoming operations and instead rely on a Multihoming Service 256 Provider deploying a middlebox in the Homenet network in charge of 257 operating multihoming services. 259 7. Normative References 261 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 262 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 263 June 2009, . 265 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 266 Iyengar, "Architectural Guidelines for Multipath TCP 267 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 268 . 270 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 271 Locator/ID Separation Protocol (LISP)", RFC 6830, 272 DOI 10.17487/RFC6830, January 2013, 273 . 275 Authors' Addresses 277 Wassim Haddad 278 Ericsson 279 6210 Spine Road 280 Boulder, CO 80301 281 USA 283 Email: Wassim.Haddad@ericsson.com 285 Damien Saucez 286 INRIA Sophia Antipolis 287 2004, Route des Lucioles BP 93 288 06902 Sophia Antipolis CEDEX 289 France 291 Email: damien.saucez@inria.fr 293 Joel 294 Ericsson 295 P.O. Box 6049 296 Leesburg, VA 20178 297 USA 299 Email: Joel.Halpern@ericsson.com