[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 6556

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


                       Testing Eyeball Happiness
             draft-baker-bmwg-testing-eyeball-happiness-00

Abstract

   A barrier to the deployment of IPv6 is the amount of time it takes to
   open a session using common transport APIs in dual stack networks and
   networks with filtering such as proposed in BCP 38.  This note
   describes a test that can be used by a manufacturer or network
   operator to determine whether an application adequately meets the
   "happy eyeballs" requirements.  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 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



Baker                     Expires May 11, 2011                  [Page 1]

Internet-Draft          Testing Eyeball Happiness          November 2010


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Generic Test  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  In more detail  . . . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
































Baker                     Expires May 11, 2011                  [Page 2]

Internet-Draft          Testing Eyeball Happiness          November 2010


1.  Introduction

   The Happy Eyeballs [I-D.wing-v6ops-happy-eyeballs-ipv6] draft
   observes on an issue in deployed 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 solutions.
   In short, in a network that contains both IPv4 [RFC0791] and IPv6
   [RFC2460] prefixes and routes, the fact that two hosts that need to
   communicate have an addresses using the same architecture doesn't
   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 opening 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 opening a session far longer than human patience
   normally allows.

   This note describes a test that can be used by a manufacturer or
   network operator to determine whether an application adequately meets
   the "happy eyeballs" requirements.  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.


2.  Generic Test

   The proposed test assumes that the application works in an IPv4
   network; the IPv4 option has to be part of the test.  That question
   devolves to whether the application can open a session in a timely
   fashion.  The issue that ISPs are reporting is that a host (MacOSX,
   Windows, Linux, FreeBSD, etc) that has more than one address (an IPv4
   and an IPv6 address, two global IPv6 addresses, etc) may serially try
   addresses, allowing the TCP setup to expire (3 seconds or
   thereabouts) for each attempt.  There have been reports of a session
   setup taking as long as 40 seconds as a result.  In addition, at
   least Apple and apparently some versions of Windows wonder about A
   and AAAA records, and if there is a AAAA record try to use the
   indicated IPv6 address and *never*fail*over*to*IPv4*.  As a result,
   there is at least one ISP that has told me that it can't advertise
   AAAA records for its mail services because the neighboring (and
   dominant) ISP runs IPv6 as a walled garden.

   What I have proposed as a test is essentially this: consider two



Baker                     Expires May 11, 2011                  [Page 3]

Internet-Draft          Testing Eyeball Happiness          November 2010


   computers, Alice and Bob, as shown in Figure 1.

                     |192.0.2.0/24
             +-----+ |2001:DB8:1:0::/64     | +-----+
             |Alice+-+2001:DB8:0:1::/64     +-+ Bob |
             +-----+ | +-------+  +-------+ | +-----+
                     +-+Router1|  |Router2+-+
             +-----+ | +-----+-+  +-+-----+ |198.51.100.0/24
             | DNS +-+       |      |       |2001:DB8:0:2::/64
             +-----+ |      -+------+-      |2001:DB8:1:4::/64
                          203.0.113.0/24    |2001:DB8:2:4::/64
                          2001:DB8:0:3::/64

                    Figure 1: Generic Test Environment

   Alice and Bob each have a set of one or more IPv4 and two or more
   IPv6 addresses in DNS, and the router is configured to route the
   relevant prefixes.  The test plays with an ACL in the router that
   would prevent traffic Alice->Bob using each of Bob's addresses.  If
   Bob has a total of N addresses, we run the test N times, permitting
   exactly one of the addresses each time.  The test is presumed to have
   passed if, on each attempt, the session can be set up within a stated
   interval, on the order of 500 ms perhaps.

   Multiple routers are used to facilitate the use of null routing or
   the removal of routes in Router1 that Router would serve as local and
   therefore non-removable routes.  In some operating systems, this can
   be simulated within a single router.

   In addition, for some applications, a more elaborate test environment
   may be necessary.  For example, when testing an application that uses
   IP multicast, it may be appropriate to provide multiple instances of
   Bob, perhaps on different LANs, in order to test the application
   behavior adequately.  This is considered beyond the scope of this
   present note, as it is very specific to the application, but test
   engineers should ask themselves that question when designing a test
   for a new application.

2.1.  In more detail

   As initial conditions, as shown in Figure 1,

   o  Alice, DNS, and Router1 each have addresses in 192.0.2.0/24, 2001:
      DB8:1:0::/64, and 2001:DB8:0:1::/64 on the same LAN,

   o  Router1 and Router2 each have addresses in 203.0.113.0/24 and
      2001:DB8:0:3::/64 on the same LAN,




Baker                     Expires May 11, 2011                  [Page 4]

Internet-Draft          Testing Eyeball Happiness          November 2010


   o  Router2 and Bob have addresses in 198.51.100.0/24, 2001:DB8:0:
      2::/64, 2001:DB8:1:4::/64, and 2001:DB8:2:4::/64 on the same LAN,

   o  Router1 has routes to 198.51.100.0/24 2001:DB8:0:2::/64 2001:DB8:
      1:4::/64 2001:DB8:2:4::/64 via Router2

   o  Router2 has routes to 192.0.2.0/24, 2001:DB8:1:0::/64, and 2001:
      DB8:0:1::/64 via Router1,

   o  DNS has appropriate A and AAAA records for Alice and Bob listing
      their addresses.

   The means of accomplishing this configuration - static configuration
   of addresses and prefixes, DHCP/DHCPv6, and SLAAC, and the routing
   protocol or static route configuration - are irrelevant beyond noting
   them in the test report.  If only DHCPv6 is tested, the test report
   should say so, for example.

   In addition, there are three means of disrupting routes:

   o  An ACL filter, configured to respond with no ICMP response

   o  An ACL filter, configured to result in an ICMP "administratively
      unreachable"

   o  A null or lacking route, which would result in an ICMP destination
      unreachable.

   Alice is the unit under test.  Most of the applications in real world
   obtain the addresses their correspondents from DNS.  Therefore, the
   IPv4 and IPv6 addresses for Alice and Bob need to be stored within a
   test DNS server, and the communication done by name.  The test is
   conducted several times with varying routing and filtering
   combinations, testing if not every combination of addresses, every
   combination of relevant condition sets.  If the ordering received
   from DNS is deterministic, the test simply requires testing of each
   scenario.  However, the order of the addresses within the DNS reply
   is not always deterministic; in such a case, there SHOULD be enough
   iterations of the test performed to ensure that the set of scenarios
   is adequately tested.

   The test is first conducted with no disruptions.  One should be able
   to observe the application working as expected between Alice and Bob;
   if it is a web service, for example, one should be able to load a web
   page, and if it is instant messaging, one should be able to have a
   breif conversation.  Which set of addresses is chosen is irrelevant.
   What is important is an observation that the application works as
   expected under some set of sircumstances, and the duration from



Baker                     Expires May 11, 2011                  [Page 5]

Internet-Draft          Testing Eyeball Happiness          November 2010


   Alice's initial DNS request for Bob's addresses to the arrival of
   Bob's first application response at Alice.

   Subsequent instances of the test should test a variety of scenarios
   including:

   o  Bob is unreachable from Alice, for each of the various reasons,
      using IPv4.

   o  Bob is unreachable from Alice, for each of the various reasons,
      using IPv6 at any address.

   o  Bob is reachable from Alice using only one IPv6 address (testing
      each address assigned to Bob in the setup), with various kinds of
      blockage.

   It would be worthwhile to go through the test once clearing all state
   in the UUT (Alice) between tests, and again ensuring that Alice is
   unaware of any changes in the network so that memory effects between
   tests can be explored.  In at least one case, the DNS resource
   records obtained by Alice's resolver should be permitted to time out,
   testing whether Alice will re-retreive them.  The fact that Alice was
   able to contain Bob at a given address should not preclude Alice
   trying other addresses on subsequent attempts.

   One would expect, in the worst case in an environment with nominal
   end to end delay, for an application to be set up in the time
   measured in the first instance of the test plus at most one inter-
   attempt interval per address that Bob has.  One might allow an
   additional 50 ms for natural host variability.  The
   [I-D.wing-v6ops-happy-eyeballs-ipv6] section 4.1, calls this "p*10"
   for some value of p, which must not exceed 4 seconds in the worst
   case.  The test is considered to have been passed if, on each pass
   through the test, an application session succeeded in opening, and
   they each took approximately the same amount of time within the
   parameters of the Happy Eyeballs draft.


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.



Baker                     Expires May 11, 2011                  [Page 6]

Internet-Draft          Testing Eyeball Happiness          November 2010


4.  Security Considerations

   This note doesn't address security-related issues.


5.  Acknowledgements

   This note was discussed with Dan Wing, Andrew Yourtchenko, and
   Fernando Gont.


6.  Change Log

   -00 Version:  Initial version - November, 2010


7.  References

7.1.  Normative References

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

   [RFC5461]  Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
              February 2009.

7.2.  Informative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.











Baker                     Expires May 11, 2011                  [Page 7]

Internet-Draft          Testing Eyeball Happiness          November 2010


Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com











































Baker                     Expires May 11, 2011                  [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/