IPv6 Operations                                                 F. Baker
Internet-Draft                                             Cisco Systems
Intended status: Informational                          November 7, 2010
Expires: May 11, 2011


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

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 May 11, 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 May 11, 2011                  [Page 1]

Internet-Draft            It takes too long...             November 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  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5









































Baker                     Expires May 11, 2011                  [Page 2]

Internet-Draft            It takes too long...             November 2010


.  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 May 11, 2011                  [Page 3]

Internet-Draft            It takes too long...             November 2010


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

   The Testing Eyeball Happiness
   [I-D.baker-bmwg-testing-eyeball-happiness] draft outlines a
   relatively simple test that can be applied to determine whether a
   given application is likely to meet the operational intent of the
   Happy Eyeballs draft.  It does not test for correct implementation of
   the algorithm per se; it tests whether the algorithm implemented
   addresses the operational concern.


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


.  Security Considerations

   This note doesn't address security-related issues.


.  Acknowledgements

   This note was discussed with Joel Jaeggli, Dan Wing, Andrew
   Yourtchecnko, and Fernando Gont.





Baker                     Expires May 11, 2011                  [Page 4]

Internet-Draft            It takes too long...             November 2010


.  Change Log

   -00 Version:  October 6, 2010

   -01 Version:  update Happy Eyeballs reference.

   -02 Version:  Add Happy Eyeballs test proposal.


.  Informative References

   [I-D.baker-bmwg-testing-eyeball-happiness]
              Baker, F., "Testing Eyeball Happiness",
              draft-baker-bmwg-testing-eyeball-happiness-00 (work in
              progress), November 2010.

   [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-01 (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.







Baker                     Expires May 11, 2011                  [Page 5]

Internet-Draft            It takes too long...             November 2010


Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com











































Baker                     Expires May 11, 2011                  [Page 6]