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]