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]
