happy eyeballs
Happy Eyeballs connection racing
happy eyeballs RFCs (4)
RFC 9622: An Abstract Application Programming Interface (API) for Transport Services
Proposed Standard- B. Trammell
- M. Welzl
- R. Enghardt
- G. Fairhurst
- M. Kühlewind
- C. S. Perkins
- P.S. Tiesel
- T. Pauly
- January 2025
- IETF publication
- Web and Internet Transport
Abstract
This document describes an abstract Application Programming Interface (API) to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of Messages. It is intended to replace the BSD Socket API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols.
Abstract
This document describes an abstract Application Programming Interface (API) to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of Messages. It is intended to replace the BSD Socket API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols.
RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency
Proposed Standard- D. Schinazi
- T. Pauly
- December 2017
- IETF publication
- Operations and Management Area
Abstract
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.
Abstract
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.
RFC 7984: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network
Proposed Standard- O. Johansson
- G. Salgueiro
- V. Gurbani
- D. Worley
- September 2016
- IETF publication
- Applications and Real-Time Area
Abstract
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.
Abstract
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.
RFC 6555: Happy Eyeballs: Success with Dual-Stack Hosts
Proposed Standard- D. Wing
- A. Yourtchenko
- April 2012
- IETF publication
- Operations and Management Area
Abstract
When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, 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 user-visible delay and provides an algorithm. [STANDARDS-TRACK]
Obsoleted by RFC 8305
Abstract
When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, 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 user-visible delay and provides an algorithm. [STANDARDS-TRACK]
Subscribe to happy eyeballs
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.