Summary

  • A6 could assemble an IPv6 address from separately maintained DNS fragments, reducing some renumbering edits but turning every chain link into another lookup, cache state, failure opportunity and administrative dependency.
  • RFC 3363 moved A6 and binary labels from Proposed Standard to Experimental and preferred AAAA for production. That status change narrowed the recommendation; it did not rewrite deployed code or zones.

There is an appealing way to store an address that might change: do not store the whole address in one place. Store the stable host part near the host. Store the provider prefix where the provider can replace it. Let a resolver compose the pieces when somebody asks.

That was the distinctive promise of the A6 record defined in RFC 2874. It aligned DNS data with the administrative fact that an IPv6 prefix and a local identifier could change on different schedules. For rapid renumbering, a higher-level prefix might be replaced without editing every leaf record. For multihoming, the same mechanism could express several prefix relationships. In design terms, it was more general than a full 128-bit AAAA record.

The cost appeared when the address had to become an answer. A resolver could not necessarily read one record and stop. It followed the prefix name to another record, and perhaps another. Each step might require an independent authoritative query. Each result had its own cache state, lifetime, operator and possibility of absence.

RFC 3363 turned that dependency graph into the standards decision. Published in August 2002 as an Informational document, it updated RFC 2673 and RFC 2874 and moved both specifications from Proposed Standard to Experimental. It recorded a perceived consensus from the DNSEXT and NGTRANS communities: AAAA was preferable for production; A6 had interesting properties that needed better understanding; and nobody yet knew whether its benefits outweighed its costs and risks.

The wording matters. This was not a finding that composition had no value. The companion RFC 3364 spent considerable effort explaining A6's real advantage. A6 could represent addresses whose prefixes might change without warning in ways that static AAAA records could not reproduce at lookup time. Preprocessing could regenerate AAAA zone data, but that moved the same dependency information into an external provisioning system.

RFC 3363 focused on the path a query had to run. It reasoned that an N-link A6 chain would take time roughly proportional to N unless the necessary answers were already cached. The probability of failure would likewise grow roughly with N because each subquery faced a failure chance. These were architectural estimates, not a global measurement. The document did not publish a latency census or claim a universal multiplier.

The administrative boundary was as important as the query count. Some of the most interesting A6 arrangements pointed out of the leaf zone and into a zone controlled by a different organization. DNS can contain such pointers. The problem was upkeep. Experience with glue and reverse pointers suggested that cross-organization references often aged badly because no single operator controlled the complete repair.

A chain could therefore be correct at every local edit and still fail globally. The host administrator preserved the suffix. The provider published the prefix. A third party maintained another delegation. The resolver needed a mutually consistent temporal snapshot. A stale cache could make one observer assemble a different address from another without any individual record being syntactically invalid.

AAAA made a different trade. The full IPv6 address lived in one resource record. Renumbering could require more records to change, and automation still mattered. But the lookup dependency was visibly bounded. RFC 3363 recommended leaving RFC 1886 on the standards track and advancing it while moving RFC 2874 to Experimental. RFC 3596 later specified the AAAA and IP6.ARPA model that became the ordinary production reference.

The reverse tree supplied a second correction. RFC 2673 had introduced binary labels, the first new DNS label type since RFC 1035. The mechanism could group one-bit labels into bit strings and represented a technically compact form for reverse mapping. Deployment taught a harsher lesson: servers that did not support the new label form could reject queries containing it as malformed.

RFC 3363 concluded that hexadecimal text labels could express the reverse-delegation structures then expected. It moved binary labels to Experimental as well. The intended use of DNAME in the reverse tree was deprecated alongside fragmented A6. The separate question of the reverse-tree root was out of scope and had been handled by RFC 3152.

This was standards work as subtraction. Two documents had reached Proposed Standard, yet deployment discussion revealed that their novelty enlarged the compatibility surface before operational evidence was strong enough. The response was not to erase the work. Experimental status preserved it for study while removing it from the preferred production path.

That status act must not be overstated. A document can change the formal track of another document. It cannot reach into a resolver and remove code. It cannot rewrite a zone, flush a cache, repair a cross-organization pointer or prove that an operator migrated to AAAA. Standards status, implementation support, published records and live query outcome remain separate facts.

The same separation prevents AAAA from becoming a victory myth. One full record avoids serial address assembly, but it does not guarantee fresh provisioning, correct reverse data, DNSSEC validation, reachable routing or a working service. RFC 4472 later catalogued many IPv6 DNS operational issues after AAAA had become the ordinary representation. Simpler dependency structure reduced one class of uncertainty; it did not abolish operations.

RFC 3597 adds a useful neighboring lesson. DNS software needs mechanisms for handling unknown resource-record types so that protocol extension does not always require immediate semantic understanding. Yet generic handling of an unknown type and support for a new label syntax are different compatibility surfaces. A server might carry unfamiliar record data and still reject an unfamiliar name encoding.

The current IANA DNS parameters registry records identifiers and statuses. It is a durable coordination artifact. It does not reveal which resolver versions once supported A6, which zones published it, how long records survived the downgrade or what users observed. A present registry row is not a historical deployment trace.

Two Lu Heng essays provide the disclosed analytical frame. “Minimum Initial Specification” argues that a common layer should contain only the deterministic structure necessary for compatibility and should leave later adoption to participants running code. A6 placed more dynamic composition into the shared resolution path; AAAA left more renumbering work with provisioning and operators. “On Reality Layers” prevents the standards downgrade from being mistaken for an instantaneous operational event. The document changed first. Code, zones, caches and outcomes could change on different clocks.

The historical lesson is not that elegance is suspect. It is that composability spends reliability. A component is valuable when it can change independently. The same independence becomes risk when the final answer cannot exist unless every component, administrator and query is available at once.

RFC 3363 made a disciplined retreat. It kept the idea available as an experiment, narrowed the production recommendation and allowed running systems to determine adoption. The address could still be assembled in pieces. Production DNS no longer had to pretend that every extra piece was free.

Sources