Summary

  • Revision 03 of draft-ietf-v6ops-ipv6-app-testing defines four base connectivity conditions and asks teams to apply the relevant ones to each application flow. A successful dual-stack path may hide IPv6 failure through fallback; it cannot certify IPv6-only-strict behavior.
  • Installation, user interface, management and update are separate lifecycle surfaces. A useful readiness claim needs an attributable coverage manifest, proof that the test harness created the claimed condition, and the observed transport and application result for each material cell.

One green result compressed a larger system

Imagine a familiar release review. The application opens in a dual-stack lab. Its main page renders. The API returns expected data. The browser prefers IPv6 on the visible requests. A dashboard reduces those observations to one green badge: IPv6 ready.

Then the application attempts an automatic update in a network with no usable IPv4. Its update helper resolves an endpoint that has only an A record, or calls a local service bound to 127.0.0.1, or reaches a licensing system through a component whose IPv6 feature gate was never enabled. The product did not suddenly lose a capability that the test had proved. The test had never covered this path.

That is the practical importance of revision 03 of the V6OPS draft. It does not define a universal certification suite. It supplies a way to reason about coverage. Its four base connectivity conditions are IPv4-only, dual-stack, IPv6-only with NAT64 or a similar transition path, and IPv6-only-strict. The last condition excludes relevant IPv4 reachability whether native, translated or encapsulated.

These are not four labels to attach to the whole product. They are conditions under which a particular flow performs a particular function. The coverage unit is therefore closer to:

version × directed flow × lifecycle function × endpoint roles × intermediary × connectivity condition × expected outcome.

If any factor is omitted, the aggregate badge silently inherits more authority than the evidence beneath it.

Dual-stack success may be fallback success

Dual-stack service is valuable, and fallback is often exactly what users need. It is not a neutral test environment.

A connection can fail on IPv6 after TCP establishment but before TLS completes, then succeed over IPv4. A broken AAAA target may be bypassed by Happy Eyeballs. A DNS64 or CLAT path may make an IPv4-only dependency reachable from an apparently IPv6-only client. A VPN or privacy relay may restore IPv4 connectivity outside the harness designer's view. The final transaction succeeds, but the selected route and failed attempt determine what the result proves.

RFC 8305 describes a race intended to reduce user-visible delay when one address family or path is poor. It does not turn the winning family into evidence that the losing family works. RFC 6147, RFC 6052 and RFC 6877 supply different translation and synthesis mechanisms. Their presence can be the intended test condition, or contamination when the declared condition is IPv6-only-strict.

A useful receipt records the DNS answer set, selected address, address family, connection attempts, fallback timing, proxy or translator, transport result and application result. “Request completed” discards the evidence needed to distinguish native success from successful escape.

The inverse error matters too. An IPv6 attempt can fail because the harness itself is defective. Disabling IPv4 may also disable a virtual-machine management path or a corporate sign-on dependency. A test environment that cannot be observed safely may report product failure when it has actually destroyed its own control plane. The harness and the application need separate health receipts.

Lifecycle functions are independent axes

The draft names four lifecycle functions: installation, user interface, management and update. That compact list prevents a common form of selective evidence.

Installation may call activation systems, package repositories or third-party services. The user interface may use a web origin, static asset hosts, authentication, authorization and telemetry. Management can include APIs, SNMP, syslog, monitoring exporters, backup or remote support. Updating may use different executables, certificates, mirrors and rollback services from ordinary operation.

Passing the main user journey does not exercise the installer. Passing an API call does not prove that logs preserve an IPv6 source address. Passing a manual update does not prove an unattended updater can reach its repository. The same program may act as a client on one flow and a server on another.

Leadership should therefore reject coverage reports organized only around product screens. The inventory needs directed flows and owners. For each flow, it should name the initiating component, receiving component, discovery mechanism, possible intermediary, address-family conditions, authentication and authorization dependency, expected result and evidence location.

This is not a demand for a blind Cartesian explosion. Revision 03 says controlled architecture can narrow the relevant combinations. If one side is deliberately and provably dual-stack, cases that assume a different condition on that controlled side may be excluded. The key word is provably. An exclusion is a versioned engineering claim with an owner and reason, not a missing row mistaken for a pass.

Complex applications turn one test into a graph

An end-to-end cloud test is a path through a graph. The visible request may cross a load balancer, gateway, identity service, policy engine, database, object store, logging service and callback. A green end state can conceal a fallback on one edge and no coverage at all on another edge that the chosen transaction did not traverse.

Proxies add a distinct problem. A client-to-proxy IPv6 success says nothing about the proxy-to-server leg. The proxy may translate between families, select a different resolver or preserve an IPv4-only upstream dependency. Peer-to-peer applications and TURN relays add still more roles; RFC 8656 explains the relay mechanism, not whether a particular application's complete candidate and relay set was exercised.

Reused services make the inventory recursive. Enabling IPv6 on one shared endpoint may cause another product to begin arriving over IPv6 before its allow list, logging or rate-control path is ready. A component owner can make a technically correct local change that alters the operational contract of every consumer.

This is why the coverage manifest must be linked to dependency versions and interaction contracts. A flow is not permanently “tested.” It is tested for a defined build, configuration, topology and policy set. Runtime, DNS, proxy, translator, dependency or routing changes reopen the relevant cells.

Addresses also travel as data

Transport success is only one surface. Applications parse, render, store, compare and authorize using addresses.

RFC 4291 defines IPv6 address architecture, while RFC 5952 recommends a canonical text form. A validator that assumes dotted-decimal input can reject a valid IPv6 literal. A field sized for an IPv4 string can truncate a record. A log normalizer can turn equivalent forms into separate actors, or erase a zone identifier needed for link-local use. An audit system can retain the transport event while losing the address necessary to investigate it.

Access lists are a sharper example. Adding an AAAA record can cause capable clients to arrive over IPv6 immediately. If the application checks an allow list only after the connection is established, Happy Eyeballs cannot rescue a missing IPv6 rule. The transport worked; authorization failed. A migration plan that enables the server before enabling policy input can create a self-inflicted outage.

The same distinction applies to telemetry and abuse response. A system that accepts IPv6 traffic but cannot represent, aggregate or search IPv6 source data has incomplete operational support. A product badge based on reachability misses the accountability surface.

Strictness is a claim about the harness

An IPv6-only-strict result carries extra evidentiary burden. The tester must show that CLAT was disabled, DNS64 did not synthesize an answer, the well-known NAT64 prefix was blocked where relevant, and tunnels, VPNs or relays did not restore access to IPv4-only resources. Otherwise the test may be a valid transition-path test with the wrong label.

When strict isolation is infeasible, tracing can support a narrower conclusion. Client logs can show which family was selected. Server logs can show which family arrived. Packet capture can show observed flows. But absence in a capture proves absence only within the capture's interface, filters, time window and known flow inventory. The draft calls network tracing the most error-prone alternative because it requires the tester to know the communication pattern already.

That circularity should be disclosed. A coverage report can say: every flow in manifest revision X was observed over IPv6 during test run Y. It should not say: no hidden IPv4 dependency exists anywhere.

The document is guidance, not the result

The exact source is revision 03, dated 29 September 2026 and expiring 2 April 2027. Datatracker records an active V6OPS Working Group document in WG Last Call and I-D Exists. The draft header proposes Best Current Practice, while the Datatracker intended-status field is empty. It is neither an RFC nor a BCP today.

That status boundary is consistent with the document's own subject. Publication can standardize a useful vocabulary for test scenarios. It cannot execute a test, discover a product's flows or observe production. RFC 8504 states requirements for IPv6 nodes; it is not a substitute for application-specific functional and lifecycle coverage. RFC 8585 describes enterprise deployment scenarios; it does not certify a particular application's dependencies.

Running-Code Primacy supplies the right order. Guidance defines comparable questions. A versioned manifest states the claimed surface. A harness creates a condition. Instrumentation records the selected path. The application produces an outcome. Deployment shows whether the result survives real dependencies and change. No earlier layer creates the next one by declaration.

Sources