Testing Eyeball Happiness
RFC 6556
Document | Type |
RFC - Informational
(April 2012; No errata)
Was draft-baker-bmwg-testing-eyeball-happiness (individual in ops area)
|
|
---|---|---|---|
Author | Fred Baker | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6556 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ron Bonica | ||
IESG note | Al Morton (acmorton@att.com) is the document shepherd. | ||
Send notices to | acmorton@att.com |
Internet Engineering Task Force (IETF) F. Baker Request for Comments: 6556 Cisco Systems Category: Informational April 2012 ISSN: 2070-1721 Testing Eyeball Happiness Abstract The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6556. Copyright Notice Copyright (c) 2012 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 Baker Informational [Page 1] RFC 6556 Testing Eyeball Happiness April 2012 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 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Measuring Eyeball Happiness . . . . . . . . . . . . . . . . . 3 2.1. Happy Eyeballs Test-Bed Configuration . . . . . . . . . . 4 2.2. Happy Eyeballs Test Procedure . . . . . . . . . . . . . . 5 2.3. Metrics for Happy Eyeballs . . . . . . . . . . . . . . . . 7 2.3.1. Metric: Session Setup Interval . . . . . . . . . . . . 7 2.3.2. Metric: Maximum Session Setup Interval . . . . . . . . 8 2.3.3. Metric: Minimum Session Setup Interval . . . . . . . . 8 2.3.4. Descriptive Metric: Attempt Pattern . . . . . . . . . 9 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 1. Introduction The Happy Eyeballs [RFC6555] specification notes an issue in deployed multi-prefix IPv6-only and dual-stack networks, and proposes a correction. [RFC5461] similarly looks at TCP's response to so-called "soft errors" (ICMP host and network unreachable messages), pointing out an issue and a set of possible solutions. In a dual-stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 ingress filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side effect of making the worst- case delay in establishing a session far longer than human patience normally allows. Baker Informational [Page 2]Show full document text