| TOC |
|
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.
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 12, 2011.
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.
1.
Introduction
2.
Generic Test
2.1.
In more detail
3.
IANA Considerations
4.
Security Considerations
5.
Acknowledgements
6.
Change Log
7.
References
7.1.
Normative References
7.2.
Informative References
§
Author's Address
| TOC |
The Happy Eyeballs (Wing, D. and A. Yourtchenko, “Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts,” October 2010.) [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] (Gont, F., “TCP's Reaction to Soft Errors,” February 2009.) 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 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791] and IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [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 (Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” February 2003.) [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.
| TOC |
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 computers, Alice and Bob, as shown in Figure 1 (Generic Test Environment).
|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.
| TOC |
As initial conditions, as shown in Figure 1 (Generic Test Environment),
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:
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 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:
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] (Wing, D. and A. Yourtchenko, “Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts,” October 2010.) 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.
| TOC |
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.
| TOC |
This note doesn't address security-related issues.
| TOC |
This note was discussed with Dan Wing, Andrew Yourtchenko, and Fernando Gont.
| TOC |
- -00 Version:
- Initial version - November, 2010
| TOC |
| TOC |
| [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 (TXT). |
| [RFC5461] | Gont, F., “TCP's Reaction to Soft Errors,” RFC 5461, February 2009 (TXT). |
| TOC |
| [RFC0791] | Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT). |
| [RFC2460] | Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML). |
| [RFC3493] | Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” RFC 3493, February 2003 (TXT). |
| TOC |
| Fred Baker | |
| Cisco Systems | |
| Santa Barbara, California 93117 | |
| USA | |
| Email: | fred@cisco.com |