Testing Eyeball Happiness
RFC 6556

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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]