RFC 6555
Happy Eyeballs: Success with Dual-Stack Hosts
RFC 6555: Happy Eyeballs: Success with Dual-Stack Hosts 🦋
okay bestie, RFC 6555 is giving main character energy 💅. It's from the Internet Engineering Task Force (IETF) and it's a Request for Comments, numbered 6555. The authors are D. Wing and A. Yourtchenko, both at Cisco. It's a Standards Track doc with ISSN 2070-1721, dated April 2012 🎀. The title block doesn't list anything it obsoletes or updates, so no drama there ✨.
Abstract 🌸
so picture this: a server's IPv4 path and protocol are working fine, but its IPv6 path and protocol are not 😭. a dual-stack client app then sits there with a seriously long connection delay, while an IPv4-only client connects right away. that's not it, because the dual-stack client ends up with a worse user experience. this doc lays out requirements for algorithms that shrink that user-visible delay, and it gives one of those algorithms 💖.
Status of This Memo 📜
this is an Internet Standards Track document 🔥.
it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards lives in Section 2 of RFC 5741 [RFC5741].
for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6555 🧚.
Copyright Notice ©️
Copyright (c) 2012 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) as in effect on the date of publication. please read these carefully, because they describe your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 🫶.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Additional Network and Host Traffic . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Hostnames . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Delay When IPv6 Is Not Accessible . . . . . . . . . . . . 5
4. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 6
4.1. Delay IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stateful Behavior When IPv6 Fails . . . . . . . . . . . . 8
4.3. Reset on Network (Re-)Initialization . . . . . . . . . . . 9
4.4. Abandon Non-Winning Connections . . . . . . . . . . . . . 9
5. Additional Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Determining Address Type . . . . . . . . . . . . . . . . . 10
5.2. Debugging and Troubleshooting . . . . . . . . . . . . . . 10
5.3. Three or More Interfaces . . . . . . . . . . . . . . . . . 10
5.4. A and AAAA Resource Records . . . . . . . . . . . . . . . 10
5.5. Connection Timeout . . . . . . . . . . . . . . . . . . . . 11
5.6. Interaction with Same-Origin Policy . . . . . . . . . . . 11
5.7. Implementation Strategies . . . . . . . . . . . . . . . . 12
6. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 131. Introduction 💖
okay so, to use apps over IPv6, users need to get nearly identical performance compared to IPv4 ✨. right now, a mix of today's apps, IPv6 tunneling, IPv6 service providers, and some content providers all make the user experience suffer (see Section 3) 😭. for IPv6, a content provider can keep things positive by using a DNS white list of IPv6 service providers who peer directly with them (e.g., [WHITELIST]). but that doesn't scale well (to the number of DNS servers worldwide or the number of content providers worldwide), and it doesn't react to intermittent network path outages 🙄.
so instead, apps reduce connection setup delays themselves, by making connections more aggressively on IPv6 and IPv4 🚀. there are a bunch of algorithms you could imagine. this document sets requirements for any such algorithm 🎀. the goals are that the network and servers don't get inordinately harmed by a simple doubling of traffic on IPv6 and IPv4, and that the host's address preference is honored (e.g., [RFC3484]).
1.1. Additional Network and Host Traffic 🌈
extra network traffic and extra server load show up because of the recommendations in this document, especially when connections to the preferred address family (usually IPv6) aren't completing quickly 😬.
the procedures here keep a quality user experience while you transition from IPv4-only to dual stack, and they still give IPv6 a slight preference over IPv4 🫶. the reason is to take load off IPv4 networks and, most importantly, to reduce the load on IPv4 network address translators. the user experience gets better, at the slight expense of the network, the DNS server, and the server that's serving the user 💅.
2. Notational Conventions 📏
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 [RFC2119] 🎀.
3. Problem Statement 🔍
the IPv6/IPv4 selection problem was first described in 1994 in [RFC1671]. here's the quote, and honestly it's iconic 💀:
The dual-stack code may get two addresses back from DNS; which
does it use? During the many years of transition the Internet
will contain black holes. For example, somewhere on the way from
IPng host A to IPng host B there will sometimes (unpredictably) be
IPv4-only routers which discard IPng packets. Also, the state of
the DNS does not necessarily correspond to reality. A host for
which DNS claims to know an IPng address may in fact not be
running IPng at a particular moment; thus an IPng packet to that
host will be discarded on delivery. Knowing that a host has both
IPv4 and IPng addresses gives no information about black holes. A
solution to this must be proposed and it must not depend on
manually maintained information. (If this is not solved, the
dual-stack approach is no better than the packet translation
approach.)as discussed in more detail in Section 3.1, it's important that the same hostname be used for IPv4 and IPv6 🥹. and as discussed in more detail in Section 3.2, IPv6 connectivity is broken to specific prefixes or specific hosts, or it's slower than native IPv4 connectivity 😩.
the mechanism in this document applies directly to connection-oriented transports (e.g., TCP, SCTP), and that's the scope here 💜. for connectionless transport protocols (e.g., UDP), a similar mechanism can work if the application has request/response semantics. for example, Interactive Connectivity Establishment (ICE) uses this to select a working IPv6 or IPv4 media path [RFC6157] 🦋.
3.1. Hostnames 🍓
people swap hostnames all the time to share content, on social networks, over email, through instant messaging, or in other systems 💬. if you use separate namespaces (e.g., "ipv6.example.com") that only work with certain client technology (e.g., an IPv6 client) and dependencies (e.g., a working IPv6 path), you get namespace fragmentation, and users can't share hostnames as easily. it also makes printed material that includes the hostname way more complicated 🙃.
the algorithm in this document lets production hostnames avoid those problematic references to IPv4 or IPv6 ✨.
3.2. Delay When IPv6 Is Not Accessible 😭
when IPv6 connectivity is impaired, today's IPv6-capable apps (e.g., web browsers, email clients, instant messaging clients) can sit there for many seconds before they fall back to IPv4 ⏳. that slows down overall app operation, and it also hurts the user's experience with IPv6. which is a problem, because IPv6 often gets disabled entirely on end systems just to make the user experience better, and that slows the acceptance of IPv6 💔.
the failures usually come from no connection to the IPv6 Internet, broken 6to4 or Teredo tunnels, and broken IPv6 peering 🛠️. the diagram below shows this behavior 👀.
the algorithm in this document lets clients connect to servers without significant delay, even if a path or the server is slow or down 🏃♀️.
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |==TCP SYN, IPv6===>X |
8. | |==TCP SYN, IPv6===>X |
9. | | |
10. | |--TCP SYN, IPv4------->|
11. | |<-TCP SYN+ACK, IPv4----|
12. | |--TCP ACK, IPv4------->|
Figure 1: Existing Behavior Message Flowso the client gets the IPv4 and IPv6 records for the server (steps 1-4) 📬. it tries to connect over IPv6, but the IPv6 path is broken (steps 6-8), and that eats up several seconds ⌛. eventually the client tries IPv4 (step 10), and that one works 🎉.
delays that users of various browser and operating system combinations have experienced have been studied in [Experiences] 🧐.
more of the actual algorithm is coming up next in part 2 🧚♀️✨
4. Algorithm Requirements ✨
okay so a "Happy Eyeballs" algorithm has two main goals 💖
- Give users a fast connection by quickly trying IPv6 first, and if that attempt isn't quickly successful, trying IPv4.
- Don't thrash the network 🫶 by not (always) making simultaneous connection attempts on both IPv6 and IPv4.
here's the basic vibe in this diagram 🦋
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |--TCP SYN, IPv4------->|
8. | |<-TCP SYN+ACK, IPv4----|
9. | |--TCP ACK, IPv4------->|
10. | |==TCP SYN, IPv6===>X |
Figure 2: Happy Eyeballs Flow 1, IPv6 Brokenso in this one the client sends two TCP SYNs at the same time, one over IPv6 (6) and one over IPv4 (7) 🎀 The IPv6 path is broken here, but it barely affects the user because there's no long wait before IPv4 kicks in. The IPv6 path keeps getting retried until the application gives up (10) 🥺
after all that, the client finds out whether connections to the host's IPv6 or IPv4 address worked. The client MUST cache info about the outcome of each connection attempt 💅 and it uses that info so it doesn't thrash the network with later attempts. In the example, the cache says the IPv6 attempt failed, so the system will prefer IPv4 instead. Cache entries should be flushed once their age goes past a system-defined maximum, on the order of 10 minutes ⏰
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6=======>|
7. | |--TCP SYN, IPv4------->|
8. | |<=TCP SYN+ACK, IPv6====|
9. | |<-TCP SYN+ACK, IPv4----|
10. | |==TCP ACK, IPv6=======>|
11. | |--TCP ACK, IPv4------->|
12. | |--TCP RST, IPv4------->|
Figure 3: Happy Eyeballs Flow 2, IPv6 Workingthis second one is the case where both IPv6 and IPv4 work, and IPv4 gets abandoned (12) 👑
so any Happy Eyeballs algorithm will keep living in products for as long as the client host is dual-stacked 🌈 and that lasts as long as there are IPv4-only servers on the Internet, aka the so-called "long tail" 🙈 Over time, as most content moves to IPv6, the amount of IPv4 traffic goes down. That means the IPv4 infrastructure will get sized for that smaller (and still shrinking) amount of traffic. It is critical that a Happy Eyeballs algorithm not cause a surge of unnecessary traffic on that IPv4 infrastructure 😭 So compliant Happy Eyeballs algorithms must follow the requirements in this section, no exceptions bestie 💜
4.1. Delay IPv4
the transition to IPv6 is probably going to give us a messy mix of hosts on the same subnetwork 🍓 IPv4-only hosts, IPv6-only hosts (like sensors), and dual-stack hosts. This mix shows up inside one administrative domain (a single home, enterprise, hotel, or coffee shop) and also between domains. Like, one home might have an IPv4-only TV in one room and a dual-stack TV in another, and another subscriber might have hosts that can all do dual-stack 📺✨
because of IPv4 exhaustion, a subscriber's hosts (both IPv4-only and dual-stack) will probably be sharing an IPv4 address with other subscribers 🥹 The dual-stack hosts have the advantage here. They can use IPv6 or IPv4, which means they can use the technique in this document. The IPv4-only hosts have the disadvantage: they can only use IPv4. If every host, dual-stack and IPv4-only, is on IPv4, the shared IPv4 address gets extra contention. The IPv4-only hosts can't dodge that contention since they only have IPv4, but the dual-stack hosts can dodge it by using IPv6 💅
as dual-stack hosts multiply and more content shows up over IPv6, there's going to be proportionally less IPv4 traffic. This is especially true for dual-stack hosts that don't implement Happy Eyeballs, because those hosts have a super strong preference for IPv6 (with timeouts in the tens of seconds before they'll try IPv4) 🙃
when IPv6 gets deployed, both content providers and Internet Service Providers (who supply IPv4 address sharing mechanisms like Carrier-Grade NAT (CGN)) want to cut back on their IPv4 gear: load-balancers, peering links, and address sharing devices 💸 If a Happy Eyeballs implementation treats IPv6 and IPv4 equally by connecting to whichever family is fastest, it adds load to IPv4. That load hits IPv4-only devices, since it increases contention on the shared address and load on the IPv4 load-balancers 😤 Because of that, ISPs and content providers would find it basically impossible to cut their IPv4 investment, which makes migrating to IPv6 cost more, since the IPv4 spending can't go down. Also, a metric that only measures connection speed ignores the perks IPv6 brings over IPv4 address sharing, like better geo-location [RFC6269] and not sharing fate with a big translator. Totally iconic to ignore, not 🙅♀️
so, to avoid harming IPv4-only hosts, implementations MUST prefer the first IP address family returned by the host's address preference policy, unless they're implementing a stateful algorithm described in Section 4.2 🧚 This usually means preferring IPv6 over IPv4, although users or the network can override that preference through configuration [ADDR-SELECT] ⭐ And if the host's policy is unknown or can't be reached, implementations MUST prefer IPv6 over IPv4 🌸
4.2. Stateful Behavior When IPv6 Fails
some Happy Eyeballs algorithms are stateful 🧠 which means the algorithm remembers things like "IPv6 always fails" or "IPv6 to certain prefixes always fails," and so on. This section is about those algorithms. Stateless algorithms, which don't remember how earlier connections went, aren't covered here 🦋
after trying the preferred address family (e.g., IPv6) and failing to set up a connection within a certain time period (see Section 5.5), a Happy Eyeballs implementation will decide to start a second connection attempt, using either the same address family or the other one 💖
such an implementation MAY make later connection attempts (to the same host or to other hosts) on the family that worked (e.g., IPv4) ✨ But as long as the host is still making new connections, the implementation MUST occasionally try the host's preferred address family again, because it may have come back to life, and it SHOULD do that every 10 minutes 🎀 That 10-minute wait before retrying a failed family is there so connection attempts don't just double up on both IPv6 and IPv4 🙌
Implementation note: this can be done by flushing Happy Eyeballs state every 10 minutes, and that doesn't really hurt the application's later connection setup time 💅 If connections on the preferred family start working again, the preferred family SHOULD be used for later connections 🥳 Since this implementation is stateful, it MAY track connection success (or failure) by IPv6 or IPv4 prefix (e.g., connections to the same prefix assigned to the interface work, while connections to other prefixes keep failing) 🔍
4.3. Reset on Network (Re-)Initialization
every network has its own vibe (like working or broken IPv6 or IPv4 connectivity), so a Happy Eyeballs algorithm SHOULD re-initialize whenever the interface connects to a new network 🌐 Interfaces can notice network (re-)initialization in a few ways, like Detecting Network Attachment in IPv4 (DNAv4) [RFC4436] or DNAv6 [RFC6059] 🛰️
if the client app is a web browser, also check out Section 5.6 💻
4.4. Abandon Non-Winning Connections
it is RECOMMENDED that the non-winning connections be abandoned 🫧 even though, in some cases, they could be put to reasonable use.
Justification: this cuts load on the server (file descriptors, TCP control blocks) and on stateful middleboxes (NAT and firewalls) 🧱 Also, if the abandoned connection is IPv4, it reduces IPv4 address sharing contention 💜
HTTP: some sites can break because of HTTP cookies that bake in the client's IP address and require every connection to come from the same IP address 🍪 If some connections from the same client show up from different IP addresses (or, worse, different IP address families), those apps will break 💀 For HTTP, keeping a non-winning connection around can also interfere with the browser's same-origin policy (see Section 5.6) 🙈
5. Additional Considerations 🌷
this section talks about considerations related to Happy Eyeballs 🫶
5.1. Determining Address Type
for some transitional technologies, like a dual-stack host, it's easy for the application to tell apart the native IPv6 address (learned via an AAAA query) and the native IPv4 address (learned via an A query) 🔎 Translation makes that harder, but IPv6/IPv4 translators don't need to be deployed on networks with dual-stack clients, because dual-stack clients can just use their native IP address family 🙌
5.2. Debugging and Troubleshooting
this mechanism is all about giving a reliable user experience no matter which single transport has connectivity problems. But that also means apps using these techniques are, by default, less helpful for diagnosing problems with a particular address family 😅 To help with that, implementations MAY also provide a way to turn off their Happy Eyeballs behavior via a user setting, plus data useful for debugging (e.g., a log or a way to review current preferences) 🛠️💖
5.3. Three or More Interfaces 🧚
okay so a dual-stack host normally has two logical interfaces: one for IPv6 and one for IPv4. easy, iconic, we love a simple girl.
BUT. a dual-stack host can end up with more than two because of a VPN (where a third interface is the tunnel address, often given out by the remote corporate network 🏢), or multiple physical interfaces like wired and wireless Ethernet, or because the host is in multiple VLANs, or other reasons 🙈. how Happy Eyeballs behaves with more than two logical interfaces is still for further study, so that's a plot twist for future us 🔮
5.4. A and AAAA Resource Records 💌
so a DNS query for an A or AAAA resource record can hand back MORE than one A or AAAA address 👀. when that happens, it is RECOMMENDED that a Happy Eyeballs implementation sort the responses using the host's address preference policy, and then try the first address 🥇. if that one fails after a certain time (see Section 5.5), the next address SHOULD be the IPv4 address 🌸.
if that still doesn't connect after a certain time (see Section 5.5), a Happy Eyeballs implementation SHOULD try the other addresses that came back. the order of these attempts is not important, bestie 💅.
ngl this part is giving load balancing 🎀. on the Internet today, servers commonly have multiple A records so they can spread traffic across their servers, and the same trick would be useful for AAAA records too. BUT if you return multiple AAAA records to a client that isn't using Happy Eyeballs and has broken IPv6 connectivity, it'll make the fall back to IPv4 take even longer 😭. so web site operators with native IPv6 connectivity SHOULD NOT offer multiple AAAA records 🙅♀️. if Happy Eyeballs becomes widely deployed in the future, this recommendation might get revisited, so keep an eye on it ✨.
5.5. Connection Timeout ⏰
the whole point of Happy Eyeballs is to cut down how long a dual-stack connection takes to finish, especially when the IPv6 path is broken and IPv6 is the preferred one 🚀. aggressive timeouts (we're talking tens of milliseconds) do get that done, BUT they cost network traffic 💸. that traffic can be billable on certain networks, it creates state on some middleboxes (firewalls, intrusion detection systems, NATs, etc.), and it eats up ports if IPv4 addresses are shared 🥲. so for these reasons, it is RECOMMENDED that connection attempts be paced so connections have a chance to complete 🫶. it is RECOMMENDED that the attempts be paced 150-250 ms apart to balance human factors against network load ⚖️.
stateful algorithms are expected to be more aggressive (aka they make connection attempts closer together), because they keep an estimate of how long a connection is expected to take to complete 🧠. smart girl behavior 👑.
5.6. Interaction with Same-Origin Policy 🛡️
web browsers implement a same-origin policy [RFC6454] that makes subsequent connections to the same hostname go to the same IPv4 (or IPv6) address that the previous successful connection used 🔒. this is done to prevent certain types of attacks, and honestly that's the vibe we want 💜.
BUT the same-origin policy hurts user-visible responsiveness when a new connection fails (say, from a transient event like a router failure or a load-balancer failure) 😩. it's tempting to use Happy Eyeballs to keep things responsive, but web browsers MUST NOT change their same-origin policy because of Happy Eyeballs, since that would create an additional security exposure 🚫. security first, bestie, always 🔐.
5.7. Implementation Strategies 🛠️
the simplest place to implement Happy Eyeballs is inside the application itself 📱. the algorithm in this document is pretty simple to implement and doesn't need any special support from the operating system beyond the commonly available APIs that provide transport service ✨. it could also be added to applications through a specific Happy Eyeballs API, which would replace or augment the transport service APIs 🧩.
for legacy applications (the ones that just rely on the operating system's address preference order), operating systems may consider more sophisticated approaches to improve the IPv6 experience 💖. these can include changing the default address selection sorting [RFC3484] based on configuration received from the network, or observing connection failures to IPv6 and IPV4 destinations 👀.
6. Example Algorithm 🌈
okay here's the algorithm that Google Chrome and Mozilla Firefox actually run, so this one is the real deal 💅:
- Call
getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy. - Initiate a connection attempt with the first address in that list (e.g., IPv6).
- If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
- The first connection that is established is used. The other connection is discarded.
if an algorithm were to cache connection success/failure, the caching would happen after step 4 figured out which connection won 🏆. other example algorithms include [Perreault] and [Andrews] 🦋.
7. Security Considerations 💀
okay this section is short but it is SERIOUS 😤. see Sections 4.4 and 5.6. go read those, bestie, the security stuff lives there 🔐🔥.
8. Acknowledgements 🫶
this mechanism was inspired by Stuart Cheshire's discussion at the IAB Plenary at IETF 72, the author's understanding of Safari's operation with SRV records, ICE [RFC5245], the current IPv4/IPv6 behavior of SMTP mail transfer agents, and the implementation of Happy Eyeballs in Google Chrome and Mozilla Firefox 💜.
huge thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van Beijnum for fostering the creation of this document 🎀.
thanks to Scott Brim, Rick Jones, Stig Venaas, Erik Kline, Bjoern Zeeb, Matt Miller, Dave Thaler, Dmitry Anipko, Brian Carpenter, and David Crocker for their feedback 💌.
thanks to Javier Ubillos, Simon Perreault, and Mark Andrews for the active feedback and the experimental work on the independent practical implementations they created 🙌.
also the authors would like to thank the following people, who joined various email discussions on this topic: Mohacsi Janos, Pekka Savola, Ted Lemon, Carlos Martinez-Cagnazzo, Simon Perreault, Jack Bates, Jeroen Massar, Fred Baker, Javier Ubillos, Teemu Savolainen, Scott Brim, Erik Kline, Cameron Byrne, Daniel Roesen, Guillaume Leclanche, Mark Smith, Gert Doering, Martin Millnert, Tim Durack, and Matthew Palmer 🌸✨.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.9.2. Informative References
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6",
Work in Progress, February 2012.
[Andrews] Andrews, M., "How to connect to a multi-homed server
over TCP", January 2011, <http://www.isc.org/community/
blog/201101/how-to-connect-to-a-multi-homed-server-
over-tcp>.
[Experiences] Savolainen, T., Miettinen, N., Veikkolainen, S., Chown,
T., and J. Morse, "Experiences of host behavior in
broken IPv6 networks", March 2011,
<http://www.ietf.org/proceedings/80/slides/
v6ops-12.pdf>.
[Perreault] Perreault, S., "Happy Eyeballs in Erlang", February
2011, <http://www.viagenie.ca/news/
index.html#happy_eyeballs_erlang>.
[RFC1671] Carpenter, B., "IPng White Paper on Transition and
Other Considerations", RFC 1671, August 1994.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March
2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
November 2010.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)",
RFC 6157, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011.
[WHITELIST] Google, "Google over IPv6",
<http://www.google.com/intl/en/ipv6>.Authors' Addresses 🎀
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: dwing@cisco.com
Andrew Yourtchenko
Cisco Systems, Inc.
De Kleetlaan, 7
Diegem B-1831
Belgium
EMail: ayourtch@cisco.com📦 where this page comes from
- ietf: rfc6555 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms