HTTP Signaling of Planned IPv4 Unavailability

1.1. Why Planned IPv4 Outages

IPv6 deployment has been validated through coordinated industry events. On World IPv6 Day (8 June 2011), major content providers enabled IPv6 for 24 hours to measure brokenness in clients, networks, and middleboxes [WORLD-IPV6-DAY]. World IPv6 Launch (6 June 2012) moved many of those sites to permanently enabled IPv6 [WORLD-IPV6-LAUNCH]. Some participants retained IPv6; others reverted toward IPv4-only operation until a later 6/6 commitment. These events tested enabling IPv6; the inverse problem --- identifying what still breaks when IPv4 is intentionally unavailable --- remains under-specified at the application layer.¶

Operators have adopted time-bounded planned IPv4 outages as a complement: deliberately making IPv4 service unavailable for minutes, hours, or days to expose software, protocol, and operational gaps before irreversible decommissioning. The IETF meeting network ran an early example at IETF 71 (Philadelphia, March 2008): an IPv6-only wireless network was available throughout the week, and IPv4 on the main meeting network was disabled for roughly one hour during the Wednesday plenary on 12 March 2008 so attendees could use IPv6-only Internet access and surface client stacks, applications, and services that still depended on IPv4 [IETF71-IPV4-OUTAGE].¶

Governments are publishing IPv6 transition policies with varying specificity. The Czech Republic approved a plan for state administration services to stop providing IPv4 on 6 June 2032 (6/6/2032) [KONEC-IPV4-CZ] --- one of the few published fixed IPv4 end dates. Other governments set phased milestones or adoption requirements rather than a single shutdown date. The United States Office of Management and Budget Memorandum M-21-07 [OMB-M-21-07] requires federal agencies to operate at least 20%, 50%, and 80% of IP-enabled assets in IPv6-only environments by the end of fiscal years 2023, 2024, and 2025 respectively, with strategic intent to phase out IPv4. The Netherlands places IPv6 on the mandatory "use-or-explain" list for public-sector procurement [NL-FS-IPV6]. Washington State policy EA-04 [WA-EA-04] requires state agencies to migrate infrastructure and applications to IPv6 as IPv4 becomes unsupported. Such mandates are frequently declared yet only partially met; a contributing factor may be the absence of standardized, reversible transition mechanisms at the application layer, which this document aims to address. Operators facing such deadlines need staged transition mechanisms --- including time-bounded planned outages, clear user messaging, and measurable HTTP-layer signals --- long before the final cutover date.¶

Network-layer IPv4 removal is a poor fit for staged drills:¶

• Rollback is hard --- routing, ACL, and DNS changes propagate slowly and are error-prone under pressure.¶
• Blast radius is all-or-nothing --- withdrawing A records (or equivalent DNS changes) typically affects every client that resolves the name, or none; there is no fine-grained way to limit exposure to a canary cohort, percentage of traffic, or single application while leaving others on IPv4.¶
• End users lack context --- a silent timeout looks like a site outage, not an IPv4-path policy.¶
• Impact is unmeasured --- without an HTTP-visible signal, operators cannot count affected clients or quantify business loss (even a small percentage of requests can be material).¶

HTTP-layer IPv4 outages address these gaps:¶

• Easy rollback --- disable the IPv4-unavailability policy at the load balancer or origin without waiting for DNS TTL expiry.¶
• Controlled blast radius --- enable the signal per virtual host, path, method, or traffic slice at the edge without changing DNS for the whole authority.¶
• Advance communication --- site banners, email, and status pages can reference the same window as IPv4-Unavailable-Until.¶
• Clear user messaging --- a response body explains that IPv4 is intentionally unavailable, when service may resume, and what the reader can try next (including an IPv6-only link when published).¶
• Operator metrics --- count responses that carry Retry-Over-IPv6: ?1 and join them with Retry-Over-IPv6-Recovery (and optional tokens) in centralized logs to estimate soft versus hard failure rates.¶

1.2. Scope

HTTP is not the only application protocol on the Internet. This document addresses HTTP first because it is widely deployed, visible to end users (for example in browsers), and pervasive in enterprise environments for web applications, APIs, and microservices behind load balancers. Container networking, prefix delegation, and CNI configuration are out of scope; this document defines HTTP signaling only on paths where it is deployed. Operators MAY apply the same signaling on internal HTTP load balancers, API gateways, or service-mesh ingress when IPv4 is intentionally unavailable on that hop. Other protocols might adopt analogous techniques for planned IPv4 outages; defining those signals is out of scope for this document.¶

1.3. Intended Deployment

Operators deploying planned IPv4 outages with this signaling on the public Internet SHOULD do so with care. Public use can annoy users: legacy clients treat 503 Service Unavailable as a general outage (and may wait and retry on IPv4 if Retry-After is present), aware clients must close the IPv4 connection and retry over IPv6, and users on IPv4-only paths see an error even when the service remains available over IPv6 on other paths. Unannounced or frequent public drills can increase support load and reputational risk. Operators SHOULD weigh those effects against the operational value of the signal, prefer advance notice, and limit duration and frequency where impact on unrelated users is likely.¶

When an operator is obliged to run a planned IPv4 outage --- for example, a fixed government cutover deadline, a coordinated industry drill with advance notice, or an irreversible network-layer change --- HTTP-layer signaling is a viable interim step compared with silent timeouts or DNS-only withdrawal: it is reversible, measurable, and gives aware clients an explicit retry path.¶

This mechanism is primarily intended for closed or operator-controlled environments where the service provider and the user population are the same entity or share operational responsibility --- for example, enterprise intranets, government administration networks, internal API gateways, staging environments, and microservice deployments where clients are operated by the same organization. In those settings, operators can communicate maintenance windows and interpret soft versus hard failure metrics without imposing unexplained errors on unrelated Internet users. Even so, operators typically do not control every application, client, or coding library deployed in the environment: vendor software, open-source dependencies, partner integrations, and third-party SDKs may still prefer IPv4 or lack a shared retry convention. This document provides a common HTTP signal so those diverse code bases can coordinate recovery toward IPv6 for the benefit of adopters of IPv6-only environments.¶

Public Internet use MAY remain appropriate for time-bounded, widely communicated events (for example, 6/6 drills) when advance user communication is proportional to expected impact.¶

This specification is HTTP-version-agnostic: the status code usage, header fields, and client behavior apply equally to HTTP/1.1 [RFC9112], HTTP/2 [RFC9113], and HTTP/3 [RFC9114], as they are defined in terms of HTTP semantics [RFC9110]. Wire-format examples use HTTP/1.1 message syntax for readability. Implementations MUST determine whether a request was received over IPv4 at the transport layer (TCP for HTTP/1.1 and HTTP/2, QUIC for HTTP/3), not from the HTTP version alone.¶

1.4. Technical Motivation

Some operators plan to remove or disable IPv4 while retaining IPv6 service. During migration, maintenance, or decommissioning, a client that connects over IPv4 may observe connection failures or HTTP errors even though the same origin remains available over IPv6.¶

IPv4-only clients cannot switch address families; they need a clear, loggable explanation that the service no longer supports IPv4 (optionally until a stated time). Dual-stack clients on networks where Happy Eyeballs [RFC8305] selects IPv4 may treat the failure as a general outage unless the server explicitly signals that IPv4 is intentionally unavailable and IPv6 should be used instead.¶

Application-to-application traffic carried over HTTP (for example REST-style APIs, gRPC, GraphQL, or JSON-RPC) benefits from a machine-readable signal distinct from connectivity failures on other addresses. For example, a gRPC client that tries multiple resolved addresses may surface an error from the first failing attempt, masking the fact that the meaningful signal was returned on an IPv4 connection.¶

HTTP APIs behind ingress are a common place to start IPv6 transition drills, especially in operator-controlled environments (see Section 1.3). Some application architectures exhibit asymmetric dual-stack: dual-stack or IPv6-capable north-south paths (clients to ingress) alongside IPv4-only east-west paths (ingress to pods, service-to-service calls, or background workers). Planned IPv4 outages at the HTTP layer help find client and partner dependencies; they may miss internal-only IPv4 unless the same policy is also applied on internal HTTP entry points (see Section 9.5).¶

1.5. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.6. Terminology

This document uses terms from [RFC9110]. Additional terms:¶

Authority: The host and port derived from the target URI.¶

Planned IPv4 outage: An operator-initiated period during which IPv4 HTTP service for an authority is intentionally unavailable while IPv6 service is expected to remain available.¶

Aware client: A client implementation that supports the mechanisms defined in this document.¶

Legacy client: A client that does not implement this document.¶

Soft failure: A client receives 503 Service Unavailable with Retry-Over-IPv6: ?1 over IPv4 and subsequently completes the same request successfully over IPv6. Soft and hard failure classification is per aware client and per signaling hop (the entity that returned the signal), not end-to-end application success. A soft failure does not guarantee that downstream processing (for example, origin work reached over an IPv4-only pod network) succeeded.¶

Hard failure: A client receives 503 with Retry-Over-IPv6: ?1 over IPv4 but cannot successfully complete the request over IPv6.¶

IPv4-unavailability signal: A 503 Service Unavailable response that includes Retry-Over-IPv6: ?1, sent only on an IPv4 client-facing connection when IPv6 service for the authority is expected to remain available.¶

3.1. New Status Code (5NN / 566)

Earlier revisions of this document proposed a new 5xx status code (5NN, with interim tests using 566) analogous to 505 HTTP Version Not Supported (Section 15.6.6 of [RFC9110]): refuse to complete the request on the path characteristic the client used (here, IPv4). A dedicated code would appear as a distinct bucket in status-only metrics (for example Prometheus label status="566").¶

HTTP status codes are a scarce, generic resource (Section 16.2.2 of [RFC9110]). They are potentially applicable to any resource, not one operational practice. Where the primary deployment is closed or operator-controlled and only aware clients change behavior, registering a new code mainly for log or dashboard convenience puts unreasonable pressure on the status code registry. Unaware clients treat an unrecognized 5xx as 500 Internal Server Error and still do not switch address family. Aware clients need the header-defined retry semantics either way. This document therefore does not register a new status code.¶

3.2. Existing 503 with Retry-After Only

503 Service Unavailable with Retry-After (Sections 15.6.4 and 10.2.3 of [RFC9110]) tells the client to wait, then make a follow-up request. That encodes delay-then-retry on the same path, not an immediate switch to IPv6. Using Retry-After as the IPv6-retry or outage-end signal teaches the wrong behavior. This document uses IPv4-Unavailable-Until for the planned IPv4 window and keeps Retry-After optional only for legacy clients that wait on IPv4 (see Section 5.2).¶

3.3. Existing 500 with Descriptive Body Only

500 Internal Server Error with a human-readable body does not provide structured address-family retry semantics. It also misframes an intentional policy as an unexpected server fault. Bodies alone are a poor machine trigger: clients often decide retry policy before parsing content, and operators also need HTML or plain text for browsers.¶

3.4. Dedicated Media Type without Headers

A media type such as application/ipv4-unavailable+json could carry structured fields in the body. Content-Type identifies the format of the representation; it does not by itself trigger protocol behavior. Many clients act on status and header fields before reading a body; bodies may be empty, stripped, or not buffered. Human-facing text/html responses would lose machine signaling unless JSON were mandatory. Recovery telemetry still needs a request header to echo a token. This document therefore keeps response headers as the control plane and uses application/problem+json with a registered problem type URI for API-oriented bodies (see Section 7), rather than minting a dedicated media type.¶

3.5. Redirect (3xx)

A 3xx (Redirection) response with a Location URI (Section 15.4 of [RFC9110]) is a poor fit. There is no standard URI flag meaning "resolve this name for IPv6 only" on a dual-stack hostname; redirecting to the same name risks an infinite loop or repeated IPv4 selection under Happy Eyeballs. Redirecting to a distinct IPv6-only-reachable hostname requires DNS and certificate operations that remain optional for human messaging in the body, not a prerequisite for machine retry of the same target URI. For IPv4-only clients, a redirect to an IPv6-only name typically becomes a connection or name-resolution failure rather than a stable HTTP error with a representation.¶

3.6. Misdirected Request (421)

421 Misdirected Request (Section 15.5.20 of [RFC9110]) rejects a request when connection context is inappropriate and allows retry on a different connection. It is defined for HTTP origin routing and connection coalescing (Section 7.4 of [RFC9110]), not for intentional IPv4 path withdrawal. Reusing it risks confusion with existing HTTP/2 deployments and still requires IPv6-specific header fields.¶

3.7. Chosen Approach

This document uses:¶

• 503 Service Unavailable as the status code (already registered; maps cleanly in many stacks, including gRPC HTTP-to-RPC mapping);¶
• Retry-Over-IPv6: ?1 as the mandatory machine trigger for address-family retry;¶
• optional IPv4-Unavailable-Until, Retry-Over-IPv6-Token, and Retry-Over-IPv6-Recovery for window and soft/hard failure telemetry; and¶
• application/problem+json with a registered problem type URI for machine-readable bodies, without a new status code or dedicated media type.¶

Aware clients MUST NOT treat every 503 as an IPv4-unavailability signal --- only those with Retry-Over-IPv6: ?1 on an IPv4 connection.¶

4.1. Relationship to Retry-After

Retry-After on a 503 response suggests how long the client ought to wait before a follow-up request (Section 10.2.3 of [RFC9110]). That is the wrong primary control for planned IPv4 unavailability: aware clients SHOULD retry over IPv6 promptly, not wait for IPv4 to return.¶

IPv4-Unavailable-Until marks the end of the planned IPv4 window (see Section 5.2). Operators MAY also send Retry-After so legacy clients that only understand 503 delay before retrying on IPv4; aware clients MUST prefer Retry-Over-IPv6 and IPv4-Unavailable-Until over inferring address-family retry from Retry-After.¶

4.2. Cacheability and Intermediaries

Intermediaries and caches MUST NOT transform an IPv4-unavailability response into a successful response. Caching is governed by normal HTTP cache rules [RFC9111]; operators SHOULD send Cache-Control: private, no-store when responses are generated dynamically based on the client-facing address family (see Section 12).¶

A 503 response MUST NOT disallow content. The response MAY include a representation and SHOULD include one for human guidance (see Section 7). Any representation explains the IPv4 outage; an optional IPv6-only-reachable alternate URI in the body is informational and does not redefine the identity of the original target resource (Section 6.4.2 of [RFC9110]).¶

An IPv4-unavailability response MUST include Retry-Over-IPv6 with value ?1. It MAY include IPv4-Unavailable-Until, a response body, and Retry-Over-IPv6-Token.¶

4.3. Example

HTTP/1.1 503 Service Unavailable
Retry-Over-IPv6: ?1
IPv4-Unavailable-Until: Sun, 07 Jun 2026 00:00:00 GMT
Retry-Over-IPv6-Token: "a1b2c3d4e5f6"
Content-Type: application/problem+json
Cache-Control: private, no-store

5.1. Retry-Over-IPv6

The Retry-Over-IPv6 response header field indicates that the client should retry the same request over IPv6.¶

Retry-Over-IPv6 = "Retry-Over-IPv6" OWS ":" OWS boolean
boolean         = "?0" / "?1"

5.2. IPv4-Unavailable-Until

The IPv4-Unavailable-Until response header field indicates the time after which IPv4 service for this authority may be restored.¶

IPv4-Unavailable-Until = "IPv4-Unavailable-Until" OWS ":"
                          OWS HTTP-date

5.3. Retry-Over-IPv6-Token

The Retry-Over-IPv6-Token response header field carries an opaque token that a client MAY echo on a subsequent successful IPv6 retry so operators can correlate an IPv4-unavailability response with a recovery in centralized logs.¶

Retry-Over-IPv6-Token = "Retry-Over-IPv6-Token" OWS ":"
                        OWS quoted-string

5.4. Legacy Client Compatibility

Legacy clients that do not implement this document might still benefit from:¶

• Retry-After with seconds until the outage ends.¶
• Cache-Control: no-store on dynamically generated outage responses.¶
• A response body with plain language (see Section 7).¶

Aware clients MUST prefer Retry-Over-IPv6 and IPv4-Unavailable-Until over inferring outage semantics from the body or from 503 alone.¶

6.1. Retry-Over-IPv6-Recovery

The Retry-Over-IPv6-Recovery request header field allows an aware client to confirm that a successful request over IPv6 is the retry following an IPv4-unavailability signal (503 with Retry-Over-IPv6: ?1) received over IPv4.¶

Retry-Over-IPv6-Recovery = "Retry-Over-IPv6-Recovery" OWS ":"
                           OWS "recovered"
                           *( OWS ";" OWS recovery-param )
recovery-param           = token "=" ( token / quoted-string )

GET /api/v1/resource HTTP/1.1
Host: example.com
Retry-Over-IPv6-Recovery: recovered; token="a1b2c3d4e5f6"

7.1. IPv6-Only-Reachable Alternate Site

When an operator publishes a distinct hostname or URI that is IPv6-only-reachable --- for example, a name with AAAA records and no usable A records, or where IPv4 is deliberately not served --- and that name has a valid certificate for HTTPS, the response body SHOULD include a clear human-readable link to that URI. For example, an IPv4-unavailability response for https://www.example.com/ MAY point users to https://ipv6.example.com/ when the latter is IPv6-only-reachable.¶

This link is intended for end users when Happy Eyeballs or other connection selection keeps preferring IPv4 on the original dual-stack name: refreshing the same hostname may not establish IPv6, while opening an IPv6-only hostname can force a native IPv6 path. The alternate URI MUST identify a resource the operator intends users to visit (same organization or otherwise expected destination). Operators MUST NOT use this guidance as a license for open redirects to unrelated third parties.¶

Aware clients and automated HTTP clients MUST NOT be required to follow the alternate-site link. They continue to apply Retry-Over-IPv6 on the same target URI and authority as specified in Section 8.2. The link is presentation for humans; it does not replace machine-readable retry signaling.¶

The following plain-text examples are suitable for Content-Type: text/plain or as the text content of an HTML page as Content-Type: text/html.¶

7.2. Machine-Readable Problem Details

For machine-readable errors, deployments SHOULD use Problem Details [RFC9457] with Content-Type: application/problem+json and the problem type URI registered for IPv4 unavailability (see Section 13):¶

{
  "type": "urn:ietf:params:problem:ipv4-unavailable",
  "title": "IPv4 Unavailable",
  "status": 503,
  "detail": "IPv4 unavailable until 2026-06-07T00:00:00Z.",
  "ipv4UnavailableUntil": "2026-06-07T00:00:00Z",
  "ipv6OnlySite": "https://ipv6.example.com/"
}

The type member identifies this problem class. Extension members such as ipv4UnavailableUntil and ipv6OnlySite are optional. Omit ipv6OnlySite when no such alternate URI is available. Extension members are for presentation layers that render Problem Details to users. They are not a substitute for Retry-Over-IPv6. The detail field is primarily for developers and aware clients; deployments SHOULD still provide a separate human-oriented body (plain text or HTML) with the guidance above when the response may be shown to end users.¶

Aware clients MUST NOT require a Problem Details body to perform the IPv6 retry: Retry-Over-IPv6: ?1 on the response is sufficient. This document does not define a dedicated media type such as application/ipv4-unavailable+json; see Section 3.¶

8.1. Processing the Signal

When a client receives 503 with Retry-Over-IPv6: ?1:¶

1. If the client knows the response arrived on an IPv4 connection, it SHOULD proceed with an IPv6 retry as below.¶
2. If the address family is unknown, it MAY retry over IPv6 once.¶
3. If a successful HTTP response for this logical request attempt was already delivered over IPv6 (including when Happy Eyeballs [RFC8305] raced the underlying connections; see Section 6.1.5), the client MUST NOT perform another retry or send Retry-Over-IPv6-Recovery based on a late IPv4 response.¶

8.2. IPv6 Retry

The client SHOULD close or abandon the IPv4 connection before retrying over IPv6, consistent with the lifecycle described in Section 6.1. The retry MUST use the same method, target URI, and authority. The client SHOULD force address-family selection to IPv6 for this retry. The client MUST NOT change the host, scheme, or port solely because of Retry-Over-IPv6.¶

8.3. Idempotent Methods

Aware clients that receive 503 with Retry-Over-IPv6: ?1 SHOULD retry the same method, target URI, and body over IPv6 (see Section 8.2). For safe methods [RFC9110], such a retry is generally acceptable. For non-idempotent methods such as POST, the same retry can cause duplicate processing --- for example, a duplicate payment, order, or database insert. Responding entities and operators SHOULD follow the guidance in Section 9.2 on when not to send this signal for such requests.¶

8.4. Loop Prevention

The client MUST NOT perform more than one IPv4-to-IPv6 retry per logical request attempt triggered by Retry-Over-IPv6.¶

After receiving the signal, the client SHOULD prefer IPv6 for subsequent connections to the authority until IPv4-Unavailable-Until (if present) or for a default period (for example, 10 minutes).¶

If the IPv6 retry fails with connectivity errors, the client SHOULD apply backoff before further attempts and SHOULD NOT fall back to IPv4 while IPv4-Unavailable-Until is in the future.¶

8.5. IPv4-Only Clients

Clients without IPv6 connectivity cannot retry over IPv6. They SHOULD surface IPv4-Unavailable-Until (if present) and the response body to the user or calling application for logging and support tickets.¶

8.6. Recovery Signaling

On the first successful IPv6 request following a fully received IPv4-unavailability signal over IPv4, the client SHOULD send Retry-Over-IPv6-Recovery: recovered and SHOULD echo Retry-Over-IPv6-Token in the token parameter when a token was provided.¶

8.7. NAT64 and Translation

Clients on translated IPv4 paths (for example NAT64/464XLAT) might not be able to initiate a native IPv6 retry even when dual-stack is reported at the API layer. Implementations SHOULD present the response body explanation to the user; operators SHOULD not assume all "IPv4" clients can switch address families.¶

9.1. When to Send the Signal

The responding entity SHOULD send 503 with Retry-Over-IPv6: ?1 when:¶

• IPv4 HTTP service for the authority is intentionally unavailable;¶
• IPv6 service for the requested resource is expected to be available; and¶
• The request was received over IPv4 on the client-facing path; and¶
• For non-idempotent methods, duplicate processing of an IPv6 retry is acceptable or prevented (see Section 9.2).¶

The responding entity MAY omit this signal for requests received on the IPv4 loopback interface --- for example, when the client-facing connection uses addresses in 127.0.0.0/8 such as 127.0.0.1. Routable IPv4 service may be disabled during a planned outage while loopback remains available for local health checks, monitoring, and administration; those clients do not need a signal to retry over IPv6.¶

Operators MAY run staged rollouts: short canary outages (for example, one minute), longer windows (hours or a full day aligned with 6/6), and eventually permanent IPv6-only service. Operators on the open Internet SHOULD follow Section 1.3 before enabling IPv4-unavailability policy.¶

9.2. Idempotent Methods and Duplicate Processing

As described in Section 8.3, aware clients SHOULD retry after this signal, including for non-idempotent methods --- which can cause duplicate processing. Clients cannot generally determine whether a given application or resource tolerates duplicate processing. Responding entities MUST NOT assume that end-user clients will suppress IPv6 retries for non-idempotent methods.¶

An IPv4-unavailability response does not guarantee that the first request had no effect. Duplicate risk arises when:¶

• The signal is generated at an edge or load balancer while an origin server already started or completed processing the request on the IPv4 path.¶
• Policy races during rollout --- IPv4-unavailability policy may be enabled or disabled while requests are in flight.¶
• Late IPv4 responses versus an IPv6 retry --- when Happy Eyeballs [RFC8305] or a prior IPv6 attempt is in play, a client may retry or complete work without deduplication at the application layer (see Section 6.1.5).¶

Because of this uncertainty, the responding entity SHOULD NOT send 503 with Retry-Over-IPv6: ?1 for non-idempotent methods such as POST when an IPv6 retry of the same request would cause unacceptable duplicate side effects, unless the application provides deduplication (for example, an idempotency key), a request identifier, or another mechanism that makes the retry safe. Where duplicate processing is unacceptable and no such mechanism exists, omitting the signal MAY be preferable to signaling a retry the client cannot safely evaluate.¶

Operators SHOULD prefer applying this signal to idempotent methods during outage tests. APIs that must remain available for non-idempotent methods through a planned IPv4 outage SHOULD document and implement application-level deduplication or other safe-retry semantics explicitly.¶

9.3. Measuring Outage Impact

Operators SHOULD instrument at the edge or load balancer, aggregating all backends. Status code 503 alone is insufficient to distinguish planned IPv4 unavailability from overload: operators SHOULD count responses that include Retry-Over-IPv6: ?1 (or emit a dedicated metric label) rather than relying on generic 503 dashboards. Common monitoring stacks such as Prometheus and Grafana do not automatically parse application/problem+json bodies or response headers into time series; those fields must be logged or exported explicitly.¶

Hard-failure counts are estimates: clients with no IPv6 path cannot send recovery signals in-band.¶

Interpreting metrics during a drill:¶

• High soft-failure rate with low user-visible errors --- client path to the signaling entity is likely OK; a good result at that hop.¶
• High soft-failure rate with elevated origin 5xx or latency --- possible split-stack deployment: clients reached IPv6 at the edge while backends or internal hops still depend on IPv4 (see Section 9.5).¶
• Low recovery relative to signal count --- hard failures, legacy clients, or clients without an IPv6 path.¶

Operators SHOULD correlate edge signal and recovery metrics with origin, worker, and downstream dependency health during an outage window, not rely on edge metrics alone.¶

The responding entity SHOULD log recovery headers but MUST NOT alter the response based on them.¶

9.4. CDN and Reverse Proxy Deployment

When an edge terminates client IPv4 and connects to an origin over IPv6, the edge sends the IPv4-unavailability signal to the client when IPv4 to the edge is disabled --- not necessarily the origin application. The entity that generates the signal MUST know the client-facing address family.¶

When ingress terminates IPv6 from clients but uses IPv4 toward origin servers or pods, disabling IPv4 to the edge exercises client paths; disabling IPv4 on an internal HTTP gateway (ingress-to-origin, API gateway, or service-mesh ingress) exercises service-to-service HTTP that still uses operator-controlled hostnames. The same signal semantics apply on each hop where IPv4 is intentionally unavailable.¶

9.5. Split-Stack and Multi-Hop Deployments

In some container and cloud deployments, public ingress is dual-stack while pod or cluster networks remain IPv4-only (or use IPv6 only for ULA or translation, not for the paths clients use). Platform IPv6 inside the cluster often lags public dual-stack at the edge.¶

The signal is emitted based on the client-facing transport at the responding entity (see Section 9.1). It does not probe east-west paths, sidecars, background workers, or callbacks that use cluster-internal IPv4 names or addresses.¶

A drill can therefore show high soft-failure rates (the client retried over IPv6 and received success from the load balancer) while internal HTTP still depends on IPv4 and fails or degrades downstream.¶

Operators SHOULD treat edge-only drills as necessary but not sufficient for IPv6-only readiness. Operators SHOULD extend staged outages to internal HTTP gateways where policy applies and SHOULD correlate edge signal and recovery metrics with origin and downstream error rates during the window, as described in Section 9.3.¶

9.6. Token Generation

Token format and validation are deployment-specific. Tokens SHOULD be unguessable, short-lived, and loggable without affinity to the issuing server.¶

10.1. HTTP Versions

No change to the on-the-wire status code or header field definitions is required across HTTP versions. Deployment considerations differ mainly in how connections are managed:¶

• HTTP/1.1 --- An IPv4-unavailability response typically applies to one request on a single TCP connection. The client closes that IPv4 connection before retrying over IPv6, as described in Section 6.1.3.¶
• HTTP/2 --- The signal applies to that TCP connection. A client SHOULD close the IPv4 HTTP/2 connection (affecting all streams on it) before opening an IPv6 connection for the retry. Servers SHOULD emit the signal on every IPv4 HTTP/2 connection that receives a request during an outage, not only on the first stream.¶
• HTTP/3 --- The same semantics apply on a QUIC connection to the authority. HTTP/3 is a separate transport from HTTP/1.1 or HTTP/2 over TCP; a client MAY hold concurrent connections of different HTTP versions and address families. A signal received on an IPv4 QUIC connection does not automatically invalidate an existing IPv6 HTTP/3 connection, but the client MUST still apply Section 8.2 when the logical request attempt that received the signal has not yet succeeded over IPv6.¶

Clients that discover HTTP/3 via Alt-Svc or similar mechanisms on an IPv4 connection still need to evaluate Retry-Over-IPv6 before treating the request as a general failure. Operators SHOULD configure load balancers and origins to emit the same signaling on all HTTP versions they expose.¶

10.2. gRPC and Other HTTP APIs

gRPC over HTTP maps response status codes to RPC status when the grpc-status header is absent ([GRPC-HTTP-MAPPING]). That table maps 503 Service Unavailable (and selected gateway timeouts and overload responses) to UNAVAILABLE. Implementations that support this document SHOULD inspect Retry-Over-IPv6 on the HTTP response before aggregating multi-address connection errors or applying same-path retry, so that an IPv4 policy signal is not confused with IPv6 connectivity failure or ordinary overload.¶

Suggested error text for logs: "IPv4 unavailable until <date>; retry over IPv6."¶

Retry policies SHOULD retry over IPv6 when Retry-Over-IPv6: ?1 is present, not blindly retry the same address list.¶

13.1. HTTP Field Names

In the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (https://www.iana.org/assignments/http-fields/):¶

13.2. Problem Type

This document registers the following Problem Details type under the registry established by [RFC9457]:¶

This document does not register a new HTTP status code.¶

14.1. Dual-Stack Browser

A browser receives:¶

HTTP/1.1 503 Service Unavailable
Retry-Over-IPv6: ?1
IPv4-Unavailable-Until: Sun, 07 Jun 2026 00:00:00 GMT
Cache-Control: private, no-store
Content-Length: 0

It closes the IPv4 connection, retries over IPv6, and completes the page load without displaying an error page.¶

14.2. Legacy Browser with HTML Body

The following example includes an IPv6-only-reachable alternate URI. When no such URI is published, omit the corresponding paragraph (see Section 7.1.2).¶

HTTP/1.1 503 Service Unavailable
Retry-After: 86400
Content-Type: text/html; charset=utf-8

<html><body><p>This site is not available on your current
Internet connection.</p><p>The Internet is moving to a newer protocol
generation called IPv6. This service is not reachable over the older
generation (IPv4) on your network. You probably cannot fix this
yourself.</p><p>If you can open this IPv6-only address in your
browser, try:</p>
<p><a
href="https://ipv6.example.com/"
>https://ipv6.example.com/</a></p>
<p>If that does not work either, the problem may be your
network, your device, or your browser --- not necessarily
your Internet provider. Some software prefers the older
connection even when a newer one would work. Try another
browser or device if you can. You can also check whether
IPv6 works for you on a &quot;what is my IP&quot; site or an IPv6
test such as <a href="https://test-ipv6.com/"
>https://test-ipv6.com/</a>. If you still need help,
contact your organization's IT help desk, or ask your
Internet provider to check whether IPv6 works on your
connection.</p>
<p>Service over the older connection may
resume after 7 June 2026, 00:00 UTC.</p></body></html>

14.3. Cross-Backend Recovery

Backend A (IPv4 path) returns:¶

HTTP/1.1 503 Service Unavailable
Retry-Over-IPv6: ?1
Retry-Over-IPv6-Token: "abc123"
Content-Length: 0

The client retries over IPv6; backend B receives:¶

GET /index.html HTTP/1.1
Host: example.com
Retry-Over-IPv6-Recovery: recovered; token="abc123"

An edge log pipeline joins both events on token=abc123.¶

14.4. Ingress Soft Failure with Internal IPv4 Dependency

This example is informative. It illustrates that edge soft failure does not imply stack-wide IPv6 readiness (see Section 9.5).¶

1. A dual-stack client connects to public ingress over IPv4 and receives 503 with Retry-Over-IPv6: ?1.¶
2. The client retries over IPv6; ingress returns 200 OK with Retry-Over-IPv6-Recovery --- a soft failure at the edge.¶
3. Ingress forwards the request to a worker pod over cluster IPv4; the pod cannot reach a dependency that was only tested over internal IPv4, and the client eventually receives 502 Bad Gateway or 504 Gateway Timeout.¶

Operators SHOULD not conclude IPv6-only migration is complete from edge recovery metrics alone when internal paths were not exercised.¶