IPv6 Operations F. Baker Internet-Draft Cisco Systems Intended status: Informational October 18, 2010 Expires: April 21, 2011 Opening TCP Sessions in Complex Environments draft-baker-v6ops-session-start-time-01 Abstract A barrier to the deployment of IPv6 is the amount of time it takes to open a session using common transport APIs. This note addresses issues and requests solutions that may respond to them. 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 21, 2011. Copyright Notice Copyright (c) 2010 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 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. Baker Expires April 21, 2011 [Page 1] Internet-Draft It takes too long... October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Baker Expires April 21, 2011 [Page 2] Internet-Draft It takes too long... October 2010 1. Introduction One of the issues in IPv6 deployment is the time, from a user's perspective, that it takes to open a standard application, which is to say the time it takes to open a TCP session that the application can use to accomplish its mission. One thing to understand is that each source/destination pair of addresses (IPv4 and IPv6 addresses, including link-local, organizational scope such as [RFC1918] or ULA [RFC4193], and global addresses) defines a path between those interfaces. The path may or may not actually work (the two addresses may not be in the same domain or the same scope, or routing may not be defined, or forwarding may be filtered), and even if the network workds, the peer may or may not be willing to respond to any given address. Hence, in the worst case, every pair of addresses may need to be tried in the process of finding a pair that enables communication. In the immortal words of [RFC1958], The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web. This connectivity requires technical cooperation between service providers, and flourishes in the increasingly liberal and competitive commercial telecommunications environment. An application or API that fails to quickly enable connectivity between any two systems that are authorized to communicate has fundamentally missed the point, and can expect its customers to migrate to solutions that don't miss the point. Part of the issue has to do with source address choice in multihomed networks, as described in [I-D.troan-multihoming-without-nat66]; if the host selects the wrong source address for a session with a peer, BCP 38 [RFC2827] ingress filtering will prevent its delivery. Any delay in selecting an alternative source address will irritate the user, making IPv6 appear less desirable. Part of it has to do with the standard response of TCP and SCTP clients to RST and ICMP Unreachable messages; if another address pair exists, any delay in selecting an alternative source address will irritate the user, making IPv6 appear less desirable. Part of it has to do with the rate of session attempts; if one takes multiple seconds per attempt and, present implementations require as much as 40 seconds to open a basic web page. Again, such delays irritate the user, making IPv6 appear less desirable. Baker Expires April 21, 2011 [Page 3] Internet-Draft It takes too long... October 2010 2. Possible Solutions TCP's standard reaction to soft errors, which includes its response to an abrupt RST from the peer and its response to ICMP "unreachable messages", doesn't help. [RFC5461] makes pragmatic suggestions to address the issues. From an operator's perspective, it is felt that the fundamental suggestion is a good one, and either should be standardized and widely deployed or a better suggestion should be standardized and widely deployed. The Happy Eyeballs [I-D.wing-v6ops-happy-eyeballs-ipv6] draft addresses the startup question. From an operator's perspective, it is felt that the fundamental suggestion is a good one, and either should be standardized and widely deployed or a better suggestion should be standardized and widely deployed. 3. IANA Considerations This memo asks the IANA for no new parameters. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author"s perspective, it may therefore be removed upon publication as an RFC at the RFC Editor"s discretion. 4. Security Considerations This note doesn't address security-related issues. 5. Acknowledgements This note was discussed with Joel Jaeggli, Dan Wing, and Fernando Gont. 6. Change Log -00 Version: October 6, 2010 -01 Version: update Happy Eyeballs reference. Baker Expires April 21, 2011 [Page 4] Internet-Draft It takes too long... October 2010 7. Informative References [I-D.troan-multihoming-without-nat66] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", draft-troan-multihoming-without-nat66-01 (work in progress), July 2010. [I-D.wing-v6ops-happy-eyeballs-ipv6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", draft-wing-v6ops-happy-eyeballs-ipv6-00 (work in progress), October 2010. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009. Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Email: fred@cisco.com Baker Expires April 21, 2011 [Page 5]