Skip to main content

Happy Eyeballs: Success with Dual-Stack Hosts
RFC 6555

Revision differences

Document history

Date Rev. By Action
2020-01-21
07 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2016-11-30
07 (System) Closed request for Last Call review by TSVDIR with state 'Unknown'
2015-10-14
07 (System) Notify list changed from v6ops-chairs@ietf.org, draft-ietf-v6ops-happy-eyeballs@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Pete Resnick
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Wesley Eddy
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2012-04-07
07 (System) RFC published
2012-01-04
07 (System) IANA Action state changed to No IC
2012-01-03
07 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2012-01-02
07 Cindy Morgan IESG state changed to Approved-announcement sent
2012-01-02
07 Cindy Morgan IESG has approved the document
2012-01-02
07 Cindy Morgan Closed "Approve" ballot
2012-01-02
07 Cindy Morgan Approval announcement text regenerated
2012-01-02
07 Cindy Morgan Ballot writeup text changed
2011-12-26
07 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-12-26
07 Ron Bonica Ballot writeup text changed
2011-12-21
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sandra Murphy.
2011-12-21
07 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss
2011-12-20
07 (System) New version available: draft-ietf-v6ops-happy-eyeballs-07.txt
2011-12-15
07 Peter Saint-Andre
[Ballot discuss]
Updated to reflect discussion among the authors, WG chairs, and AppsDir reviewer.

Major Issue #1: Scope limited to TCP. The new text is …
[Ballot discuss]
Updated to reflect discussion among the authors, WG chairs, and AppsDir reviewer.

Major Issue #1: Scope limited to TCP. The new text is good. Cleared.

Major Issue #2: Why Standards Track? Waiting on feedback from Pete Resnick.

Minor Issue #1: Preferred address family. The new text is good. Cleared.

Minor Issue #2: Where algorithm is meant to be implemented. Working toward consensus on new text. Waiting on feedback from authors.

Minor Issue #3: Description of implementation work. The new text is good. Cleared

Minor Issue #4: Use of cache for debugging. The new text is good. Cleared.

Minor Issue #5: Timing recommendations. The new text is good. Cleared.

Minor Issue #6: WEBSEC review? Not explicitly completed, but OK. Cleared.

Minor Issue #7: Caching of results. Some confusion about whether to mention caching in the example, or remove it altogether. Waiting on feedback from authors.
2011-12-15
07 Cindy Morgan Removed from agenda for telechat
2011-12-15
07 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-12-15
07 Ron Bonica Ballot writeup text changed
2011-12-15
07 Ron Bonica Ballot writeup text changed
2011-12-15
07 Ron Bonica Ballot writeup text changed
2011-12-15
07 Ron Bonica Intended Status has been changed to Proposed Standard from Informational
2011-12-15
07 Ron Bonica Ballot writeup text changed
2011-12-15
07 (System) [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss by IESG Secretary
2011-12-15
07 Pete Resnick
[Ballot discuss]
I would now like to DISCUSS why this document has been moved to Informational from Standards Track. As written, I think it is …
[Ballot discuss]
I would now like to DISCUSS why this document has been moved to Informational from Standards Track. As written, I think it is inappropriate for Informational.
2011-12-15
07 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Discuss from No Objection
2011-12-15
07 Amy Vezza State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-12-15
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-12-15
07 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded
2011-12-14
07 David Harrington [Ballot comment]
I've cleared
2011-12-14
07 David Harrington [Ballot discuss]
2011-12-14
07 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss
2011-12-14
07 Wesley Eddy [Ballot comment]
2011-12-14
07 Wesley Eddy [Ballot Position Update] Position for Wesley Eddy has been changed to Yes from Discuss
2011-12-14
07 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Ballot writeup text changed
2011-12-14
07 Ron Bonica Intended Status has been changed to Informational from Proposed Standard
2011-12-14
07 Sean Turner [Ballot comment]
Please consider the editorial comments suggested by Sandy in here secdir review:

http://www.ietf.org/mail-archive/web/secdir/current/msg03016.html
2011-12-14
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-12-14
07 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-12-13
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-12-13
07 David Harrington [Ballot discuss]
1) should this be informational since it is now only a list of requirements?
2011-12-12
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-12-11
07 Pete Resnick
[Ballot comment]
I really think this document should have had a co-author in the apps area. It is written exceedingly "thinly" and doesn't really understand …
[Ballot comment]
I really think this document should have had a co-author in the apps area. It is written exceedingly "thinly" and doesn't really understand some of the application implementation issues. That said, I still think it is valuable and worth publishing (and hopefully updating in the future). Though it is a bit this for the standards track as it is now, I see the potential to fill this in over time with more proscriptive information, and therefore I don't object to go it going on the standards track now in anticipation of that. Some issues to consider for this go-round:

3.1 - This has nothing to do with URIs. It is about hostnames. Hostnames used that don't appear in URIs have exactly the same issues.

4. - Though using SYN and ACK in the diagram is fine, I recommend using words like "connection attempt" in the descriptive text. SYN and ACK are probably not as familiar to application layer folks, and since this is aimed at them, it is likely better to use the application layer terminology. Furthermore, there is a performance/resource impact to making a "connection attempt" that an apps person will understand that they might not if it is understood as only an additional packet.

I agree with Stephen's concerns regarding "MUST cache". There are valid reasons to try v6 later even if v4 succeeds first, but those reasons must be carefully considered and understood. That sounds like a SHOULD.

4.1 - The first few paragraphs strike me as introductory material, not part of the alogirthm requirements.

4.2. - "SHOULD do so every 10 minutes" I think instead you mean "SHOULD do so no more frequently than every 10 minutes". It's perfectly fine to do so every 20 minutes, or once a day.

4.3. - DNA does not describe how applications (which are the ones who are going to implement Happy Eyeballs) are to be notified of these changes. Though I agree that a Happy Eyeballs app should be able to ask its host to do a DNA for it (or more to the point, get notifications from the host), that's an additional requirement on these apps and should be noted.
2011-12-11
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-12-11
07 Adrian Farrel
[Ballot comment]
I understand why improving IPv6 experience in dual stack deployments is
valuable to the IETF in promoting migration to IPv6. For that reason, …
[Ballot comment]
I understand why improving IPv6 experience in dual stack deployments is
valuable to the IETF in promoting migration to IPv6. For that reason,
publication of this document may be beneficial and encourage
implementations to include more flexible selection algorithms such as
that described in this document. However, I don't see anything in this
document that impacts interworking, so I don't see why it is Standards
Track.
2011-12-11
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-12-09
07 Stephen Farrell
[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not: (I didn't see any change in -06 related …
[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not: (I didn't see any change in -06 related to these
nor any response email so I'll hold the discuss for now. Sorry if
I've missed something.)

#1, p5, last para, says the client "MUST cache that information" but
doesn't say what information (the IP addresses, the DNS name) nor
for how long (DNS TTL? browser session?). Is it ok to not specify
this?

#2, section 4.3 says SHOULD re-initialise on a new connection. If I
have two interfaces (e.g. WiFi and GSM) and one of them is thrashing
up and down continually, are you saying that the happy eyeballs
state on the other interface SHOULD also be re-initialised or not?
Maybe s/host/interface/ or some other change would be better if
not, or make it clear that you do want state for both interfaces to
be re-initialised if that's the case.
2011-12-08
07 Peter Saint-Andre [Ballot comment]
Much as I love XMPP, I would change "xmpp clients" to "IM clients".
2011-12-08
07 Peter Saint-Andre
[Ballot discuss]
The Apps Directorate review by Murray Kucherawy on 2011-11-26 raised two major technical issues and eight minor technical issues. These issues merit a …
[Ballot discuss]
The Apps Directorate review by Murray Kucherawy on 2011-11-26 raised two major technical issues and eight minor technical issues. These issues merit a response. The review can be found here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03819.html
2011-12-08
07 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-12-08
06 (System) New version available: draft-ietf-v6ops-happy-eyeballs-06.txt
2011-11-30
07 David Harrington
[Ballot discuss]
1) should thi sbe informational since it is now only a list of requirements?

2) 5.6 should say why the A6 should not …
[Ballot discuss]
1) should thi sbe informational since it is now only a list of requirements?

2) 5.6 should say why the A6 should not be queried.
2011-11-30
07 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-11-29
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-11-29
07 Cindy Morgan Telechat date has been changed to 2011-12-15 from 2011-12-01
2011-11-28
07 Stewart Bryant [Ballot comment]
Wes raises an interesting point, the draft needs to discuss connectionless transport protocols.
2011-11-28
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-11-26
07 Stephen Farrell
[Ballot comment]
- I agree with Wes' discuss

- p7 says there will be "less and less IPv4 traffic" but that
doesn't follow. E.g. absolute …
[Ballot comment]
- I agree with Wes' discuss

- p7 says there will be "less and less IPv4 traffic" but that
doesn't follow. E.g. absolute amounts of IPv4 traffic could still
increase even if IPv4 is decreasing proportional to IPv6. I think
you could lose that entire paragraph and the following one, which
only seem to be there to justify the "Thus," in the last para
of 4.1.
2011-11-26
07 Stephen Farrell
[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not:

#1, p5, last para, says the client "MUST …
[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not:

#1, p5, last para, says the client "MUST cache that information" but
doesn't say what information (the IP addresses, the DNS name) nor
for how long (DNS TTL? browser session?). Is it ok to not specify
this?

#2, section 4.3 says SHOULD re-initialise on a new connection. If I
have two interfaces (e.g. WiFi and GSM) and one of them is thrashing
up and down continually, are you saying that the happy eyeballs
state on the other interface SHOULD also be re-initialised or not?
Maybe s/host/interface/ or some other change would be better if
not, or make it clear that you do want state for both interfaces to
be re-initialised if that's the case.
2011-11-26
07 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-11-23
07 Wesley Eddy
[Ballot comment]
It may be worth mentioning at some point that in the "race" between an IPv4 and IPv6 SYN that the IPv6 SYN can …
[Ballot comment]
It may be worth mentioning at some point that in the "race" between an IPv4 and IPv6 SYN that the IPv6 SYN can be at a disadvantage due to potential tunneling causing an even less efficient path to be taken than the one that the IPv4 packet takes.
2011-11-23
07 Wesley Eddy
[Ballot discuss]
This is good and important work, and I will change to "Yes", if one simple item can be addressed.  There's an implicit assumption …
[Ballot discuss]
This is good and important work, and I will change to "Yes", if one simple item can be addressed.  There's an implicit assumption that applications are using connection-oriented transport (e.g. TCP or SCTP), and there isn't clear discussion of whether the technique is applicable or not to applications that use connectionless transport (e.g. it would at least have different considerations for applications using a stateful stream of UDP packets versus those that only use a request-response message pattern and don't keep much state between transactions).
2011-11-23
07 Wesley Eddy [Ballot Position Update] New position, Discuss, has been recorded
2011-11-10
07 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-11-09
07 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-11-04
07 Miguel García Request for Last Call review by GENART Completed. Reviewer: Miguel Garcia.
2011-11-02
07 David Harrington Request for Last Call review by TSVDIR is assigned to Hannes Tschofenig
2011-11-02
07 David Harrington Request for Last Call review by TSVDIR is assigned to Hannes Tschofenig
2011-11-01
07 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2011-11-01
07 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2011-10-28
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2011-10-28
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2011-10-28
07 Ron Bonica Placed on agenda for telechat - 2011-12-01
2011-10-28
07 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2011-10-28
07 Ron Bonica Ballot has been issued
2011-10-28
07 Ron Bonica Created "Approve" ballot
2011-10-27
07 Cindy Morgan Last call sent
2011-10-27
07 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Happy Eyeballs: Success with Dual-Stack Hosts) to Proposed Standard


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Happy Eyeballs: Success with Dual-Stack Hosts'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  When the IPv4 server and path is working but the IPv6 server or IPv6
  path is down, a dual-stack client application experiences significant
  connection delay compared to an IPv4-only client.  This is
  undesirable because it causes the dual-stack client to have a worse
  user experience.  This document specifies requirements for algorithms
  that reduce this delay, and provides an example algorithm.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/


No IPR declarations have been submitted directly on this I-D.


2011-10-27
07 Ron Bonica Last Call was requested
2011-10-27
07 Ron Bonica State changed to Last Call Requested from Publication Requested.
2011-10-27
07 (System) Ballot writeup text was added
2011-10-27
07 (System) Last call text was added
2011-10-27
07 (System) Ballot approval text was added
2011-10-27
07 Ron Bonica Last Call text changed
2011-10-27
05 (System) New version available: draft-ietf-v6ops-happy-eyeballs-05.txt
2011-10-11
07 Ron Bonica Ballot writeup text changed
2011-10-10
07 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had extensive review, prototyping, and multiple implementations in different browsers. I think the problem and the proposed solution are well understood.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I would not object to a security or operational review. That said, I don't think that the procedure carries significant security or operational issues.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

We are not aware of issues, IPR or otherwise.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is wide consensus behind this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist
and
http://tools.ietf.org/tools/idnits/
). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

idnits raises two issues:
** Downref: Normative reference to an Informational RFC: RFC 3363

== Outdated reference: A later version (-06) exists of
draft-ietf-websec-origin-04

The latter is due to the fact that draft-ietf-websec-origin has been updated. The RFC 3363 issue relates to the representation of an address in the draft. That can be moved to "informative" if the IESG asks (I asked and it didn't happen :-).


(1.h) Has the document split its references into normative and
informative?

Yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are none

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

When the IPv4 server and path is working but the IPv6 server or IPv6
path is down, a dual-stack client application experiences significant
connection delay compared to an IPv4-only client. This is
undesirable because it causes the dual-stack client to have a worse
user experience. This document specifies requirements for algorithms
that reduce this delay, and provides an example algorithm.

Working Group Summary

v6ops considered this carefully, and tested various possible implementations of the solution.

Document Quality

The document appears to be of high quality per the numerous reviews received.
2011-10-10
07 Cindy Morgan Draft added in state Publication Requested
2011-10-10
07 Cindy Morgan [Note]: 'Fred Baker (fred.baker@cisco.com) is the document shepherd.' added
2011-10-10
07 Fred Baker WGLC Completed 9 October. Sent to IESG 10/10/2011
2011-10-10
07 Fred Baker IETF state changed to Submitted to IESG for Publication from In WG Last Call
2011-09-22
07 Fred Baker Happy Eyeballs has been through various implementations and rewriting in response to them. It is now in WGLC.
2011-09-22
07 Fred Baker IETF state changed to In WG Last Call from WG Document
2011-09-14
04 (System) New version available: draft-ietf-v6ops-happy-eyeballs-04.txt
2011-07-11
03 (System) New version available: draft-ietf-v6ops-happy-eyeballs-03.txt
2011-05-25
02 (System) New version available: draft-ietf-v6ops-happy-eyeballs-02.txt
2011-03-14
01 (System) New version available: draft-ietf-v6ops-happy-eyeballs-01.txt
2011-03-03
00 (System) New version available: draft-ietf-v6ops-happy-eyeballs-00.txt