IETF Advances Happy Eyeballs v3: How Dual-Stack Proxy Clients Should Test Route Selection

The IETF HAPPY Working Group published version 04 of the Happy Eyeballs v3 Internet-Draft in July 2026. The work continues the goal of giving applications responsive connectivity when both IPv6 and IPv4 are available, while improving how clients schedule concurrent attempts, use DNS results and remember prior outcomes.

This is an active Internet-Draft, not a final standard. Implementations can change as the working group resolves feedback. Even so, the direction matters now for teams operating dual-stack proxy clients: a race that makes sense for a direct connection can measure the wrong leg when an HTTP CONNECT or SOCKS gateway sits between the client and the destination.

A proxy creates two routing decisions

For a direct request, the application resolves the destination and selects among IPv6 and IPv4 addresses. With a proxy, at least two paths may exist:

1. the client-to-proxy-gateway path;
2. the proxy-gateway-to-destination path.

Those paths can use different address families. A client may reach the gateway over IPv6 while the gateway connects to the target over IPv4. A client may also reach an IPv4 gateway that performs remote DNS and selects an IPv6 target. Calling the result simply “IPv6” or “IPv4” hides which segment actually won.

The proxy protocol changes who owns the decision. An HTTP CONNECT client normally chooses the gateway address family, while the gateway establishes the target tunnel. A SOCKS request can carry either a resolved address or a hostname; hostname mode can shift destination DNS and address-family selection to the gateway. Product documentation and test records must identify that behavior explicitly.

Why the first successful socket is not enough

Happy Eyeballs is designed to reduce visible delay, not to certify proxy quality. The fastest initial connection can still produce a poor session because of:

• an unstable IPv6 path that resets after the handshake;
• an IPv4 path with reliable setup but high target latency;
• DNS answers that differ by resolver location;
• a gateway that accepts IPv6 but falls back to IPv4 upstream;
• a browser or runtime connection pool that reuses a warm route;
• different authentication, allowlist or pricing rules by gateway family;
• target throttling or policy responses unrelated to transport.

Measure useful authorized outcomes after connection establishment. A winning SYN race followed by a failed tunnel, incomplete response or unexpected route is not a successful proxy request.

Build a four-layer observation model

1. DNS evidence

Record which component resolved the proxy gateway and the target, the A and AAAA result sets, answer order, resolver region, cache state and timestamps. Do not log sensitive internal hostnames when a sanitized route label is sufficient.

2. Gateway connection

Capture the client address family, selected gateway address, connection-start time, handshake completion, TLS result, proxy authentication outcome and whether another attempt was still in flight. This is the layer the local Happy Eyeballs implementation usually controls.

3. Tunnel or SOCKS result

Record CONNECT or SOCKS status, remote-DNS mode, target hostname or sanitized target label, target address family when observable, tunnel time and structured failure category. Separate proxy_auth_failed, gateway_unreachable, target_connect_failed and tunnel_timeout.

4. Application outcome

Record first byte, complete response time, bytes returned, useful-result status and whether the request respected authorization, robots directives, terms and rate limits. Keep destination 403, 429 and application errors out of the gateway-transport score unless evidence shows the gateway caused them.

A controlled dual-stack test matrix

Use a gateway and destination you own or are explicitly authorized to test. Run bounded samples across these cases:

Keep credentials, gateway region, target, request method, payload, timeout and workload purpose constant. Change one variable at a time. Use a fresh process or controlled connection-pool state when the experiment needs cold-start behavior.

Metrics that reveal route quality

Report the two legs separately and then combine them into a useful-result metric:

• gateway DNS time and answer-family mix;
• first and second connection-attempt start times;
• winning gateway family and cancellation delay;
• gateway handshake and proxy-auth success;
• tunnel establishment time;
• observable target family;
• p50 and p95 time to first byte;
• complete-response and useful-result rates;
• mid-session reset rate;
• fallback rate and fallback success;
• extra connection attempts per useful request;
• bytes and cost per useful authorized result.

The preferred outcome is not “IPv6 always wins.” It is a responsive, stable path that preserves IPv6 preference when IPv6 performs adequately and falls back without long stalls when it does not.

Failure injections worth testing

Use controlled infrastructure to introduce one impairment at a time:

1. delay the IPv6 gateway handshake without dropping it;
2. drop IPv6 gateway packets before connection establishment;
3. allow the gateway connection but delay target tunnel creation;
4. return incomplete AAAA or A results from an authorized test resolver;
5. make the first path succeed and then reset after headers;
6. exhaust one gateway family within a small, reversible capacity limit.

Confirm that the client cancels losing attempts, closes timers and sockets, preserves retry budgets and does not create duplicate application requests. A racing algorithm must race connection setup, not duplicate a state-changing transaction.

Procurement questions for proxy buyers

Before purchasing dual-stack proxy capacity, ask the provider:

• Are gateway hostnames dual stack, and are IPv4-only and IPv6-only endpoints available for controls?
• Does HTTP CONNECT expose the target address family in sanitized logs?
• Does SOCKS hostname mode perform DNS at the gateway, and in which region?
• Can the client pin a gateway family without changing the target policy?
• Are authentication, allowlists, concurrency limits and pricing identical across families?
• Is direct fallback impossible when the proxy gateway fails?
• Can route evidence be exported without credentials or customer data?
• How are mid-session resets, target-connect failures and gateway failures distinguished?

A provider that only reports the public exit IP cannot explain the full route-selection decision.

Release checklist

• Treat the v3 document as an active draft, not a final standard.
• Identify who resolves the gateway and destination.
• Record gateway and target address families separately.
• Use owned or explicitly authorized test infrastructure.
• Keep one variable per comparison.
• Test cold and warm connection-pool states.
• Inject bounded IPv4 and IPv6 impairments.
• Verify losing sockets, timers and pages are cleaned up.
• Prevent duplicate state-changing requests during racing.
• Exclude target policy denials from proxy transport scores.
• Compare stability and useful results, not only connection speed.
• Revalidate after runtime, resolver, proxy or draft changes.

For adjacent diagnostics, use the 98IP guides on IPv6 scope-aware retry testing, proxy-pool ASN concentration and residential session stickiness.

FAQ

Does Happy Eyeballs select the proxy exit IP?

Not necessarily. The local client usually selects how it reaches the proxy gateway. The gateway may independently resolve and connect to the destination, so the exit family must be observed separately.

Should the client start IPv4 and IPv6 at exactly the same time?

Do not invent a fixed delay without considering the runtime and current draft. Test the implementation's documented scheduling under controlled impairments and record actual attempt timing.

Can a successful IPv6 gateway connection prove end-to-end IPv6?

No. The gateway may reach the target over IPv4. End-to-end claims require evidence for both segments.

Should a failed race trigger rapid proxy rotation?

No. First classify DNS, gateway transport, proxy authentication, tunnel creation and destination policy. Rotation is appropriate only when it is authorized and supported by transport evidence.

Compliance note

Run connectivity experiments only against gateways, destinations, accounts and data you are authorized to test. Respect destination terms, robots directives, privacy obligations and rate limits. Never use address-family racing or proxy rotation to bypass a publisher's decision, evade throttling or duplicate a state-changing request.

Source note: IETF HAPPY Working Group, “Happy Eyeballs Version 3: Better Connectivity Using Concurrency,” working-group Internet-Draft version 04, published July 2026. The external source location is retained only in 98IP's internal operations record.