Transparent Happy Eyeballs

Transparent Happy Eyeballs assigns "cookie" IPv6 addresses to domain names used by a website; despite the addresses not likely correlating to the actual IP address of the domain name, the website still functions normally.

Transparent Happy Eyeballs is a feature of Universal Relay that allows the Happy Eyeballs algorithm for fast IPv6 to IPv4 fallback (RFC6555, RFC8305) to be implemented on the network layer, even if the end application doesn't support it natively.

Method of operation

This article or section needs to be updated.

Explain why it is necessary to use a pool of IPv6 addresses, namely due to the fact that we need to establish a bijective mapping, and IP addresses on the Internet won't suffice since multiple domains may have the same IP address. Also explain why u-relay.home.arpa was chosen over simply "passing through" IPv4/IPv6 literals to Universal Relay's listening sockets using the default route.

Transparent Happy Eyeballs is implemented using a DNS server coupled to a TCP relay which allows domain names to be recovered from TCP connections in a transparent and L7-independent manner. Without Transparent Happy Eyeballs, the client has to manage the IPv4 fallback, but Transparent Happy Eyeballs allows the IPv4 fallback to be shifted from the client to Universal Relay instead, so that the benefits of Happy Eyeballs can be realized by all clients on the private side network, as long as it generally supports IPv6 connections. From the perspective of the client, the connection to the "cookie" IPv6 address appears as a single, unbroken connection, which transparently falls back to IPv4 if the IPv6 connection fails.

Anatomy of "cookie" IPv6 addresses generated by Universal Relay's programmatic DNS server.

The client might request a domain name which does not actually exist on the Internet. In this case, the programmatic DNS server will still assign a "cookie" IPv6 address, but the real DNS resolution will fail, so Universal Relay will simply reset and terminate the connection; this error message is different from the normal "Server not found" error message if a domain does not exist on the Internet. The client's requested domain name, however, may still be interpreted in other ways, such as to extract the IPv4 or IPv6 literal from a u-relay.home.arpa subdomain.

A programmatic DNS server is internally set up to return "cookie" IPv6 addresses for every domain that it receives queries, and subsequently record the cookie IPv6 to domain mapping. The returned IPv6 addresses point to a ip route add local region (see also Snippets:Nginx geo local server address) which Universal Relay listens on. One address is allocated per domain name queried (see also Universal Relay/Domain Mapping), so that Universal Relay can recover the original DNS name that was associated with the "cookie" IP address, even if the protocol does not have the equivalent of SNI or a Host header (e.g. SMTP or SSH). Now that we have the original DNS name, it can be resolved to real IPv4 and IPv6 addresses, and Universal Relay can then make the upstream connection using a variant of the standard Happy Eyeballs algorithm.

We have to use "cookie" IPv6 addresses instead of the real IPv6 addresses because the latter fails to account for the fact that there could be two different domains with the same IPv6 address, but different IPv4 addresses, and the common IPv6 address is unreachable; without any other observable flags or indicators telling the domain names apart, Universal Relay could not reliably fall back to the correct IPv4 address.

This procedure can work well with domain names, but it does not work well with bare IPv4/IPv6 literals. To mitigate this shortcoming, Universal Relay recognizes the special u-relay.home.arpa zone, which is used to, among other things, represent IPv4/IPv6 literals. Example domains under that zone are ip6-2001-db8--1.u-relay.home.arpa and ip4-192-0-2-1.u-relay.home.arpa. These domains represent the IPv6 address 2001:db8::1 and IPv4 address 192.0.2.1. Universal Relay allocates a cookie IPv6 address for those domains just like with any other domain, but resolves the domains in the final stage to the fixed IPv4 or IPv6 address that is embedded within the first level subdomain of u-relay.home.arpa.

Transparent Happy Eyeballs was built upon a number of premises:

• The vast majority of applications do not care about the IP addresses of domain names embedded within the application. If google.com resolved to a different IP address from a different perspective, then applications don't really care about that, as long as it's actually reaching a google.com server. With the rising use of SSL certificates attached to domain names rather than IP addresses, as well as name-based virtual hosting with the Host header and SNI, the vast majority of applications no longer hard code IP addresses. The effect of all this is that it is possible to assign any IP address to any domain name, provided that the IP address can be routed to, and the ultimate connection to that IP address leads to an actual Internet connection to that domain name on the Internet.
• Happy Eyeballs is a feature that ought to exist in all TCP-based applications. Adding Happy Eyeballs support requires that all applications be modified to support it. If there are many applications, then this can be burdensome.

Transparent Happy Eyeballs also has a couple of other advantages:

• It is now possible to read any domain name that the client requests, in its exact, original form, and apply transformations and/or filters based on that domain name, even if that domain name does not exist on the Internet, that domain name shares an IP address or set of IP addresses with another domain (by way of CNAME or otherwise), or the client uses a non-HTTP and non-SSL protocol like SMTP, SSH, or FTP (extended passive mode only) to connect to the domain name. For example, www.example.com and www.example.org could have the same IPv4 and IPv6 address, which is problematic if we want to use network layer software to route on only one of those domains. By using the programmatic DNS server to assign different IPv6 addresses to those two domains, the domains can now be differentiated using the fact that they are destined towards a different IPv6 address.
• It is possible to statically assign a fixed IPv6 address to a particular domain name (using relay_map, see Universal Relay/Static region allocations), which allows network-level filters to be constructed on that domain name, even if the IPv4 or IPv6 address of that domain name changes on the Internet.
• The Happy Eyeballs algorithm is applied to all connections, so it is much more feasibly possible to use a less-reliable IPv6 transition mechanism like 6to4 or a Hurricane Electric tunnel (which has peering issues with Cogent) for IPv6 Internet access.
• The Happy Eyeballs implementation allows rewriting of addresses to apply a NAT64 prefix on the Internet side, which allows Happy Eyeballs to be realized even if the DNS64 server doesn't synthesize AAAA records for the IPv4 addresses on dual-stack destinations.
• Domain names can now connect to destinations that cannot be represented in a DNS A or AAAA record (see Out-of-band DNS record), including, but not limited to, IPv6 link local addresses with scope ID, alternate ports or port numbers, Unix domain sockets, Tor onion domains, and resources only available through a proxy or VPN in circumstances where they have the same IP address as some other unrelated resource on a different network.
• An actual internet connection is not required to assign cookie IP addresses to domains within the programmatic DNS server. Universal Relay does not intercept pings (they just stop in the network namespace of Universal Relay's listening sockets, and the network namespace always responds), so a ping to www.google.com will always appear to work even if there is no Internet connection.
• The default route is freed up and can be used for other purposes, such as to connect to alternative Internets like DN42 or to peer with other instances of Universal Relay's private-side network. (It is also possible to use a DN42 VPN as an upstream, where domains under *.dn42 and ULAs represented in domain names like ip4-172-20-0-1s-dn42.u-relay.home.arpa or ip6-fd42-d42-d42--1s-dn42.u-relay.home.arpa cause the DN42 VPN to be selected instead of the regular IANA/ICANN internet. This is especially useful if your normal Internet connection uses the same IP address ranges as DN42 networks, and you want to access both DN42 and something on your local network without having to change network or proxy settings.)
• From the client's perspective, all domain names appear to have exactly one IPv6 address, which allows the private-side network to be IPv6 only and still have access to IPv4-only websites, just like a DNS64/NAT64 system. No separate DNS64/NAT64 is needed. Alternatively, there is a NAT64 region within the static region, and this NAT64 region is made aware to clients with a CLAT by generating AAAA records on the ipv4only.arpa domain. Though it is seldom used unless the client used a DNS resolver on the Internet, since real IPv4 addresses of Internet destinations are not passed through the programmatic DNS server. It was miraculously used without even realizing it, if DNS-over-HTTPS is enabled in Firefox (disabled by default since use-application-dns.net is blocked)