idnits 2.17.1 draft-baker-v6ops-session-start-time-02.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 7, 2010) is 4912 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-baker-bmwg-testing-eyeball-happiness-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational November 7, 2010 5 Expires: May 11, 2011 7 Opening TCP Sessions in Complex Environments 8 draft-baker-v6ops-session-start-time-02 10 Abstract 12 A barrier to the deployment of IPv6 is the amount of time it takes to 13 open a session using common transport APIs. This note addresses 14 issues and requests solutions that may respond to them. 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 11, 2011. 33 Copyright Notice 35 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Informative References . . . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 One of the issues in IPv6 deployment is the time, from a user's 62 perspective, that it takes to open a standard application, which is 63 to say the time it takes to open a TCP session that the application 64 can use to accomplish its mission. 66 One thing to understand is that each source/destination pair of 67 addresses (IPv4 and IPv6 addresses, including link-local, 68 organizational scope such as [RFC1918] or ULA [RFC4193], and global 69 addresses) defines a path between those interfaces. The path may or 70 may not actually work (the two addresses may not be in the same 71 domain or the same scope, or routing may not be defined, or 72 forwarding may be filtered), and even if the network workds, the peer 73 may or may not be willing to respond to any given address. Hence, in 74 the worst case, every pair of addresses may need to be tried in the 75 process of finding a pair that enables communication. 77 In the immortal words of [RFC1958], 79 The current exponential growth of the network seems to show that 80 connectivity is its own reward, and is more valuable than any 81 individual application such as mail or the World-Wide Web. This 82 connectivity requires technical cooperation between service 83 providers, and flourishes in the increasingly liberal and 84 competitive commercial telecommunications environment. 86 An application or API that fails to quickly enable connectivity 87 between any two systems that are authorized to communicate has 88 fundamentally missed the point, and can expect its customers to 89 migrate to solutions that don't miss the point. 91 Part of the issue has to do with source address choice in multihomed 92 networks, as described in [I-D.troan-multihoming-without-nat66]; if 93 the host selects the wrong source address for a session with a peer, 94 BCP 38 [RFC2827] ingress filtering will prevent its delivery. Any 95 delay in selecting an alternative source address will irritate the 96 user, making IPv6 appear less desirable. 98 Part of it has to do with the standard response of TCP and SCTP 99 clients to RST and ICMP Unreachable messages; if another address pair 100 exists, any delay in selecting an alternative source address will 101 irritate the user, making IPv6 appear less desirable. 103 Part of it has to do with the rate of session attempts; if one takes 104 multiple seconds per attempt and, present implementations require as 105 much as 40 seconds to open a basic web page. Again, such delays 106 irritate the user, making IPv6 appear less desirable. 108 2. Possible Solutions 110 TCP's standard reaction to soft errors, which includes its response 111 to an abrupt RST from the peer and its response to ICMP "unreachable 112 messages", doesn't help. [RFC5461] makes pragmatic suggestions to 113 address the issues. From an operator's perspective, it is felt that 114 the fundamental suggestion is a good one, and either should be 115 standardized and widely deployed or a better suggestion should be 116 standardized and widely deployed. 118 The Happy Eyeballs [I-D.wing-v6ops-happy-eyeballs-ipv6] draft 119 addresses the startup question. From an operator's perspective, it 120 is felt that the fundamental suggestion is a good one, and either 121 should be standardized and widely deployed or a better suggestion 122 should be standardized and widely deployed. 124 The Testing Eyeball Happiness 125 [I-D.baker-bmwg-testing-eyeball-happiness] draft outlines a 126 relatively simple test that can be applied to determine whether a 127 given application is likely to meet the operational intent of the 128 Happy Eyeballs draft. It does not test for correct implementation of 129 the algorithm per se; it tests whether the algorithm implemented 130 addresses the operational concern. 132 3. IANA Considerations 134 This memo asks the IANA for no new parameters. 136 Note to RFC Editor: This section will have served its purpose if it 137 correctly tells IANA that no new assignments or registries are 138 required, or if those assignments or registries are created during 139 the RFC publication process. From the author"s perspective, it may 140 therefore be removed upon publication as an RFC at the RFC Editor"s 141 discretion. 143 4. Security Considerations 145 This note doesn't address security-related issues. 147 5. Acknowledgements 149 This note was discussed with Joel Jaeggli, Dan Wing, Andrew 150 Yourtchecnko, and Fernando Gont. 152 6. Change Log 154 -00 Version: October 6, 2010 156 -01 Version: update Happy Eyeballs reference. 158 -02 Version: Add Happy Eyeballs test proposal. 160 7. Informative References 162 [I-D.baker-bmwg-testing-eyeball-happiness] 163 Baker, F., "Testing Eyeball Happiness", 164 draft-baker-bmwg-testing-eyeball-happiness-00 (work in 165 progress), November 2010. 167 [I-D.troan-multihoming-without-nat66] 168 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 169 Wing, "IPv6 Multihoming without Network Address 170 Translation", draft-troan-multihoming-without-nat66-01 171 (work in progress), July 2010. 173 [I-D.wing-v6ops-happy-eyeballs-ipv6] 174 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending 175 Towards Success with Dual-Stack Hosts", 176 draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in 177 progress), October 2010. 179 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 180 E. Lear, "Address Allocation for Private Internets", 181 BCP 5, RFC 1918, February 1996. 183 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 184 RFC 1958, June 1996. 186 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 187 Defeating Denial of Service Attacks which employ IP Source 188 Address Spoofing", BCP 38, RFC 2827, May 2000. 190 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 191 Addresses", RFC 4193, October 2005. 193 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 194 February 2009. 196 Author's Address 198 Fred Baker 199 Cisco Systems 200 Santa Barbara, California 93117 201 USA 203 Email: fred@cisco.com