One document matched: draft-baker-bmwg-testing-eyeball-happiness-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-bmwg-testing-eyeball-happiness-00"
ipr="trust200902">
<front>
<title abbrev="">Testing Eyeball Happiness</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2010" />
<area>Operations and Management</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>bmwg
-->
<!--
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>The <xref target="I-D.wing-v6ops-happy-eyeballs-ipv6">Happy
Eyeballs</xref> draft observes on an issue in deployed IPv6-only and
dual stack networks, and proposes a correction. <xref
target="RFC5461"></xref> 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 <xref target="RFC0791">IPv4</xref> and <xref
target="RFC2460">IPv6</xref> 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 <xref
target="RFC3493">Sockets API</xref> 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.</t>
<t>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.</t>
</section>
<section title="Generic Test">
<t>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.</t>
<t>What I have proposed as a test is essentially this: consider two
computers, Alice and Bob, as shown in <xref target="test1"></xref>.</t>
<figure anchor="test1" title="Generic Test Environment">
<artwork align="center"><![CDATA[
|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
]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="In more detail">
<t>As initial conditions, as shown in <xref target="test1"></xref>,
<list style="symbols">
<t>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,</t>
<t>Router1 and Router2 each have addresses in 203.0.113.0/24 and
2001:DB8:0:3::/64 on the same LAN,</t>
<t>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,</t>
<t>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</t>
<t>Router2 has routes to 192.0.2.0/24, 2001:DB8:1:0::/64, and
2001:DB8:0:1::/64 via Router1,</t>
<t>DNS has appropriate A and AAAA records for Alice and Bob
listing their addresses.</t>
</list></t>
<t>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.</t>
<t>In addition, there are three means of disrupting routes: <list
style="symbols">
<t>An ACL filter, configured to respond with no ICMP response</t>
<t>An ACL filter, configured to result in an ICMP
"administratively unreachable"</t>
<t>A null or lacking route, which would result in an ICMP
destination unreachable.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>Subsequent instances of the test should test a variety of scenarios
including:<list style="symbols">
<t>Bob is unreachable from Alice, for each of the various reasons,
using IPv4.</t>
<t>Bob is unreachable from Alice, for each of the various reasons,
using IPv6 at any address.</t>
<t>Bob is reachable from Alice using only one IPv6 address
(testing each address assigned to Bob in the setup), with various
kinds of blockage.</t>
</list></t>
<t>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.</t>
<t>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 <xref
target="I-D.wing-v6ops-happy-eyeballs-ipv6"></xref> 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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This note doesn't address security-related issues.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note was discussed with Dan Wing, Andrew Yourtchenko, and
Fernando Gont.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="-00 Version:">Initial version - November, 2010</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.5461" ?>
<?rfc include="reference.I-D.wing-v6ops-happy-eyeballs-ipv6" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.3493" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:10:26 |