idnits 2.17.1 draft-baker-happier-eyeballs-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 5, 2012) is 4183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1164 (Obsoleted by RFC 1268) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational November 5, 2012 5 Expires: May 9, 2013 7 Happier Eyeballs 8 draft-baker-happier-eyeballs-00 10 Abstract 12 Multihoming in modern networks has problems with differing quality of 13 routes. This note generalizes the concept of happy eyeballs across a 14 variety of multihoming scenarios. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 9, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction: define "Multihoming"? . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 52 2. Generalizing RFC 6555 . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Implications of multihoming . . . . . . . . . . . . . . . 4 54 2.2. The implications of multihoming for applications . . . . . 5 55 2.3. The implications of multihoming for operating systems . . 6 56 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction: define "Multihoming"? 69 In the Internet, we have a variety of definitions and implementations 70 of multi-homing. 72 The concept first comes up in [RFC0760], which states that "A host 73 should also be able to have several physical interfaces (multi- 74 homing)." [RFC0799] restates this in another way, which the author 75 likely thought of as equivalent but given history is tantalizing: 76 "Furthermore, hosts can be multi-homed, that is, respond to more than 77 one address." [RFC0830] goes on to discuss a given host (as shown in 78 its name record) being multihomed via more than one network, and 79 [RFC0917] refers to routers as a class as "Internet hosts that are 80 multi-homed and thus can serve as gateway." These cases all refer to 81 an individual system as being multihomed, defining the term as 82 implying a multiplicity of addresses or interfaces that the host 83 might use. 85 The IP Version 6 Addressing Architecture [RFC4291] goes on to assert 86 that "A single interface may also have multiple IPv6 addresses of any 87 type (unicast, anycast, and multicast) or scope", which is to say 88 that a particular model which is possible but unusual in IPv4 (that a 89 given interface might have more than one address) is possible and 90 normal in IPv6 - and as a result any IPv6 interface, by [RFC0799]'s 91 logic, may itself be multihomed. 93 [RFC1164] introduces the concept of a network being multihomed. This 94 is not absolutely new; if [RFC0830]'s host is attached to and derives 95 addresses from multiple networks, it is a short step to assert that a 96 network containing it is multihomed. However, it sets forth four 97 definitions that have proven seminal in operational deployment: 99 "Autonomous System" or "AS" a set of routers under a single 100 technical administration, interconnected to other networks using 101 an exterior gateway protocol (in this case BGP), that appears to 102 other ASs to have a single coherent interior routing plan, and 103 presents a consistent picture of what networks are reachable 104 through it. [author's restatement of a larger paragraph] 106 Stub AS: an AS that has only a single connection to another AS. 107 Naturally, a stub AS only carries local traffic. 109 Multihomed AS: an AS that has more than one connection to other ASs, 110 but refuses to carry transit traffic. 112 Transit AS: an AS that has more than one connection to other ASs and 113 is designed (under certain policy restrictions) to carry both 114 transit and local traffic. 116 [RFC6555] goes on to describe a scenario in which a host has multiple 117 addresses and is therefore, by [RFC0799]'s logic, multihomed - but 118 with a wrinkle. In this case, some of the addresses might be IPv4 119 [RFC0791] addresses, and some might be IPv6 [RFC2460] addresses, and 120 they might be on the same or different interfaces. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Generalizing RFC 6555 130 [RFC6555] makes it fairly clear that the applications it is thinking 131 of are wide-ranging, referring to "(e.g., web browsers, email 132 clients, instant messaging clients)". However, its examples and text 133 mostly refer to web browsers, which in turn run on TCP. As a result, 134 some commentators have inferred that it only deals with web browsers 135 or only with TCP, and have gone on to repeat the specification for 136 other applications. This was not the intention of the authors, and 137 is unfortunate. But the specification does concern itself primarily 138 with Dual Stack networks and hosts and applications in them. The 139 best application is wider yet. This is to multihoming in all of its 140 forms. 142 2.1. Implications of multihoming 144 A key implication of multihoming, regardless of the type of 145 multihoming in view, is that there is potentially more than one route 146 between two interfaces or systems, and the routes may have differing 147 characteristics. If a host has multiple interfaces, they are often 148 of differing technology, such as Ethernet and WiFi or WiFi and LTE, 149 and those interfaces may have differences in delay, capacity, loss 150 rate, monetary cost, or routing policy. Multihomed addressing 151 implies multiple routes between systems, even if only in the first or 152 final hop. In addition, routing information or policy may come into 153 play; 155 o [RFC6724] wonders whether any form of network address translation 156 is in use, 158 o ULAs [RFC4193] may be preferred within a domain but not advertised 159 between domains, 161 o a network may be using a prefix or address family internally but 162 not externally, 164 o a filter may be in place in a firewall, or 166 o a normally-available route may be in flux or temporarily 167 inoperative. 169 In the extreme, routing may offer multiple paths between two AS's, 170 and the differences among them may be satellite vs. terrestrial 171 paths, which differ markedly in end-to-end delay, or between fiber 172 and microwave, which can differ markedly in loss rate. 174 In short, a {source, destination} address pair implies a route 175 between those addresses, and multiple address pairs may imply 176 multiple routes with different characteristics. 178 2.2. The implications of multihoming for applications 180 As such, the implication of multihoming for applications is that any 181 application that finds itself on a multihomed host or attempting to 182 open a session with a multihomed host - a host that has more than one 183 address regardless of address family or underlying hardware - SHOULD 184 be prepared to use any or all of them at any time, and SHOULD 185 organize its algorithms to find one among them that provides adequate 186 service with the least effort on its own part and impact on its user. 187 If the application operates without user intervention or awareness, 188 such as SMTP between MTAs, the decision should be transparent and 189 immaterial to any user; one among the better routes should be chosen, 190 and a user should not perceive non-intrinsic variability among them. 191 If the application operates with user involvement, such as voice or 192 video on RTP, web browser access, or electronic mail, the decision 193 should be performed in a manner that minimizes user impact, including 194 connection setup delays. 196 An implementation MAY prefer IPv6 routes over IPv4 routes, such as by 197 trying IPv6 addresses first. If the difference is known, an 198 application is well-advised to prefer native routes over translated 199 routes, as is suggested in [RFC6724], for reasons such as those 200 mentioned in [RFC2993]. 202 When comparing operational characteristics such as route quality, it 203 is difficult to make a single recommendation for all applications, as 204 applications may have differing requirements. [RFC6555] suggests 205 initiating a set of connection attempts at some cadence, and 206 accepting the first to succeed, which at least obtains a route that 207 provably works and may have a lower round-trip-time than other 208 choices. 210 If the implementation caches session metadata across multiple 211 sessions, it may be useful to include and consider information such 212 as 214 o Some sense of the success rate in connecting to a given address or 215 prefix, such as succeeding in N out of M attempts. M=0 implies 216 that the address or prefix has not been tested. 218 o The round trip time on successful connection set-up, allowing the 219 implementation to try lower-RTT routes first. 221 o If the connection moved at least a stated among of data to or from 222 the peer, the effective throughput achieved, enabling an 223 implementation to select high throughput routes first. Short 224 exchanges that do not achieve sustained throughput are likely to 225 produce unreasonable numbers, and should therefore not be included 226 in such a cache. 228 In TCP terms, TCP's estimate of its throughput rate is the final 229 value of cwnd*pmtu/mean_rtt times a scaling constant. 231 2.3. The implications of multihoming for operating systems 233 An unfortunate characteristic of the current Socket API 234 [RFC3493][RFC5014] is that it forces the application to have 235 knowledge of the IPv4 or IPv6 address of its peer and potentially of 236 itself. While there are cases in which it is useful to know that 237 address, such as for logging, it is seldom required or useful once 238 the session has been established. A side-effect of having the 239 application store the address as a result of one call and then use it 240 in another is that the process of updating systems to use IPv6 forces 241 a change to every implicated application. As a result, we find 242 operating systems deploying technologies such as Bump-in-the-Host 243 [RFC6535] APIs, which translate IPv4 system calls into IPv6 behavior 244 without informing the application. Many of the issues encountered in 245 renumbering [RFC4192] also derive from application shortcuts such as 246 directly referring to addresses rather than names, or not updating 247 cached information when it expires. 249 It would be better if the socket "connect" API accepted a character 250 string, which might contain a DNS name, an IPv4 address literal, or 251 an IPv6 address literal, negotiated the connection in an [RFC6555]- 252 compliant manner, and then returned either a connected socket or an 253 error code, and additionally provided an API that enabled a 254 application to obtain its peer's address from a connected socket, 255 ideally as a character string. In this way, the application using a 256 network can be independent of the network, and insulated from changes 257 to the network layer. 259 Ideally, the API also enables the specification of the transport 260 protocol or at least the type of service it seeks. It might enable 261 an octet stream interface using TCP [RFC0793], or a dynamic set of 262 message stream interfaces associated with one peer using SCTP 263 [RFC4960][RFC5061]. On a "listener" interface, the Socket API should 264 be able to do the counterpart, permitting This has two values; the 265 socket interface it replaces permits specification of the underlying 266 transport, and support for more modern transports enables their 267 convenient use. This would be useful, for example, in obviating the 268 issues of head-of-line blocking among exchanges in a pipelined TCP, 269 obtaining web objects or performing Map/Reduce message exchanges in 270 parallel instead. 272 Creation of such an API in the ANSI standard would allow the Socket 273 API to remove gethostbyname(), with its IPv4-only limitation, and 274 getaddrinfo(), whose use results in the issue [RFC6555] addresses. 276 One example of such an API, which unfortunately always uses TCP, is 277 the java.net.Socket class 279 public Socket(String host, int port) throws IOException 280 public InetAddress getInetAddress() 281 public InetAddress getLocalAddress() 282 public int getPort() 283 public int getLocalPort() 285 The Windows WSAConnectByName and StreamSocket.ConnectAsync APIs, and 286 the MacOSX CFStreamCreatePairWithSocketToHost API, are also examples 287 of such an API, with the same limitation regarding the transport 288 service. 290 3. Conclusions 292 In summary, although [RFC6555]'s examples are largely drawn from TCP 293 and web service, is best understood as generalizing to all 294 applications and transports. It comments on session initiation in 295 what this note points out are essentially multihomed environments. 296 Whenever there exist a multiplicity of possible routes, selectable by 297 the session originator through its choice of {source, destination} 298 address pair, the application is best served by finding a useful 299 route, or set of routes, quickly. It SHOULD do so. 301 4. IANA Considerations 303 This memo asks the IANA for no new parameters. 305 5. Security Considerations 307 This note makes no observations regarding security, and does not 308 impact it. 310 6. Privacy Considerations 312 This note makes no observations regarding privacy, and does not 313 impact it. 315 7. Acknowledgements 317 The author received comments from Dan Wing, Dave Thaler, Erik 318 Nordmark, Mark Townsley, Ralph Droms, and Stuart Cheshire. 320 8. Change Log 322 Initial Version: November 2012 324 9. References 326 9.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 332 Dual-Stack Hosts", RFC 6555, April 2012. 334 9.2. Informative References 336 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, 337 January 1980. 339 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 340 September 1981. 342 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 343 RFC 793, September 1981. 345 [RFC0799] Mills, D., "Internet name domains", RFC 799, 346 September 1981. 348 [RFC0830] Su, Z., "Distributed system for Internet name service", 349 RFC 830, October 1982. 351 [RFC0917] Mogul, J., "Internet subnets", RFC 917, October 1984. 353 [RFC1164] Honig, J., Katz, D., Mathis, M., Rekhter, Y., and J. Yu, 354 "Application of the Border Gateway Protocol in the 355 Internet", RFC 1164, June 1990. 357 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 358 (IPv6) Specification", RFC 2460, December 1998. 360 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 361 November 2000. 363 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 364 Stevens, "Basic Socket Interface Extensions for IPv6", 365 RFC 3493, February 2003. 367 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 368 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 369 September 2005. 371 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 372 Addresses", RFC 4193, October 2005. 374 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 375 Architecture", RFC 4291, February 2006. 377 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 378 RFC 4960, September 2007. 380 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 381 Socket API for Source Address Selection", RFC 5014, 382 September 2007. 384 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 385 Kozuka, "Stream Control Transmission Protocol (SCTP) 386 Dynamic Address Reconfiguration", RFC 5061, 387 September 2007. 389 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 390 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 392 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 393 "Default Address Selection for Internet Protocol Version 6 394 (IPv6)", RFC 6724, September 2012. 396 Author's Address 398 Fred Baker 399 Cisco Systems 400 Santa Barbara, California 93117 401 USA 403 Email: fred@cisco.com