Opening TCP Sessions in Complex Environments
draft-baker-v6ops-session-start-time-00

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 9, 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.

Table of Contents

1.  Introduction
2.  Possible Solutions
3.  IANA Considerations
4.  Security Considerations
5.  Acknowledgements
6.  Change Log
7.  Informative References
§  Author's Address

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] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) or ULA (Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses,” October 2005.) [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] (Carpenter, B., “Architectural Principles of the Internet,” June 1996.),

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 communication. 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] (Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, “IPv6 Multihoming without Network Address Translation,” July 2010.); if the host selects the wrong source address for a session with a peer, BCP 38 (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.) [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.

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] (Gont, F., “TCP's Reaction to Soft Errors,” February 2009.) 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 (Wing, D., Yourtchenko, A., and P. Natarajan, “Happy Eyeballs: Trending Towards Success (IPv6 and SCTP),” August 2010.) [I‑D.wing‑http‑new‑tech] 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

Initial Version:

October 6, 2010

7. Informative References

Author's Address