Summary

  • RFC 3152 selected IP6.ARPA for IPv6 address-to-name mapping, requested delegation under IAB instructions and aligned further delegation with IPv6 address assignments; it did not itself populate every reverse zone or update every client.
  • Deprecating IP6.INT meant that it was unsuitable for new implementations and should be phased out orderly. The later 2005 withdrawal date confirms that standards choice and deployed cutover were different events.
  • A trustworthy migration record separates RFC status, parent and child delegation, PTR data, resolver suffix, cache, DNS response, validation and application outcome. A reverse answer is not authenticated host identity.

The standards decision arrived before the last query moved

RFC 3152 is only a few pages long. Its brevity is part of the story. IPv6 already needed an address-derived DNS tree analogous to IPv4's IN-ADDR.ARPA. Earlier specifications referred to IP6.INT. By 2001, the IAB preferred .ARPA as the home for technical infrastructure namespaces, and IETF consensus had settled on IP6.ARPA.

The RFC therefore made three moves. It explained why the reverse tree belonged under .ARPA; it deprecated IP6.INT references in five earlier RFCs; and it asked IANA to delegate IP6.ARPA following IAB instructions. Names below that point were to follow the hierarchy of IPv6 address assignment and move onward to regional Internet registries.

None of those acts was the same as changing a running resolver. The document defined deprecation carefully: old usage was inappropriate for new implementations and would likely be phased out in an orderly fashion. It did not announce that IP6.INT had vanished, that every library had shipped a new suffix, or that each allocated prefix already had working PTR data.

That gap is not failure. It is the mechanism of a distributed migration. A common destination can be selected before every participant is ready, while the old path remains observable long enough for software and operators to move.

A reverse namespace had more than one control plane

The phrase “delegate the domain” can sound like one administrative switch. RFC 3152 described a chain. The IETF supplied the technical consensus. The IAB supplied instructions for the infrastructure namespace. IANA held the top-level operational role. Regional registries received portions according to IPv6 address-space delegation. Operators farther down the tree controlled their own reverse zones and PTR records.

RFC 3172 made that design more explicit a month later. It described .ARPA as a limited-use infrastructure domain and treated correct operation as essential. IP6.ARPA was delegated to IANA, then subdivided according to RIR allocation. The hierarchy was meant to mirror the authority structure of the number space.

Mirroring allocation did not make the layers identical. An address allocation can exist without a reverse delegation. A parent referral can exist while the child is lame. A child can answer authoritatively but contain no PTR record. A PTR record can point to a name whose forward data does not return to the address. Each observation belongs to a different operator and clock.

This is why a registry receipt cannot be substituted for a DNS trace. The former says who received a block or delegation. The latter says which servers answered a particular query at a particular time. An application result is later still.

The name of the tree and the data in the tree were different facts

RFC 3596 later consolidated the stable IPv6 DNS design. An IPv6 address becomes a sequence of hexadecimal nibbles, each placed in its own label in reverse order under IP6.ARPA. A PTR query can then ask for a name associated with that address-derived owner name.

Correct construction of the query proves only that the software asked the intended namespace. It does not prove that the parent delegation is present, that the relevant RIR and child delegations are current, or that an answer exists. A valid query may end with a referral, NXDOMAIN, timeout, SERVFAIL, unsigned answer, validated answer or stale cached result.

Even a PTR answer is a statement stored by a zone operator. It is not a certificate of the host's identity, ownership or authority. It does not prove reachability, and it does not prove that a forward lookup of the returned name leads back to the same address. Some applications perform forward-confirmed reverse DNS; others merely display the string. Neither behavior is supplied by RFC 3152.

The migration therefore had two orthogonal dimensions. Software needed to ask beneath the new root. Operators needed to make delegation and data available beneath it. One could advance while the other lagged.

“Orderly” permitted overlap without declaring equivalence

A clean historical diagram might draw an arrow from IP6.INT to IP6.ARPA. A live migration is more like two clocks. New software can prefer the new suffix while old versions continue querying the old. Operators can support both trees temporarily. Resolver caches can preserve positive or negative answers after authoritative data changes.

Overlap reduces the cost of coordination, but it also complicates evidence. If an application silently falls back, a successful displayed name does not reveal which tree supplied it. If two trees contain different PTR data, success in both places does not make the answers equivalent. If negative caching survives a newly created delegation, the authoritative change can be correct while clients still observe absence.

A useful cutover record therefore includes the exact query name, resolver, cache status, referral chain, authoritative server, response code, answer, TTL and validation state. It also records the library or application version that selected the suffix. Without those receipts, “reverse DNS worked” hides the part of the migration that actually ran.

The later chronology confirms the interval. RFC 3596 in 2003 incorporated IP6.ARPA into the standards-track IPv6 DNS specification and obsoleted RFCs 1886 and 3152. RFC 4159 then advised that, from 1 September 2005, standards-conformant IPv6 implementations should no longer use IP6.INT, while RIRs worked with their communities on stopping registration support. The 2001 decision was real; the operational withdrawal still took additional steps.

Obsoleting the memo preserved its result

An RFC metadata label can be misread as an operational verdict. RFC 3596 “obsoleted” RFC 3152 because it combined the earlier IPv6 DNS specification with the namespace change. It did not retire IP6.ARPA. The chosen tree became part of the later consolidated standard.

The surrounding design also continued to evolve. RFC 3363 moved A6 and Bitstring Label mechanisms to Experimental while favoring AAAA records. RFC 5855 later gave the IPv4 and IPv6 reverse zones a stable nameserver naming scheme. RFC 9121 recorded IP6.INT among historic infrastructure domains removed from .INT.

Those later documents should not be collapsed into a story of one perfect decision. They show different maintenance surfaces: query format, parent namespace, record design, server naming and retirement of an obsolete tree. A document can be obsolete because its rule has been absorbed elsewhere. A namespace can remain current even when the RFC that introduced its delegation is no longer the controlling specification.

“No new threats” did not make reverse DNS an identity system

RFC 3152 noted that spoofed address-to-name mappings had already been exploited in IPv4 and said delegating IP6.ARPA created no new threats. The narrow claim concerns the change of namespace root. It does not say that PTR data is trustworthy or that reverse names may authorize users, hosts or services.

RFC 3596 stated the boundary more directly: DNS information should be treated as unsafe unless the appropriate security techniques are used, and the IPv6 extensions neither created new security problems nor solved existing ones. DNSSEC validation can authenticate DNS data relative to its trust chain. It still does not prove the human meaning an application attaches to a PTR name, current endpoint custody or permission to act.

Security review must therefore preserve the join. Was the response validated? Which zone signed it? Did the application perform a forward check? Was the result merely logged, or did it influence access? A policy that grants trust from a pleasant-looking reverse name has crossed far beyond the evidence RFC 3152 supplied.

Running code had the final word on migration state

Suppose the parent delegation is correct and a prefix holder has published a valid PTR. One old library continues to query IP6.INT and returns nothing. Another asks IP6.ARPA but retains a negative cache entry from before the child delegation. A third receives the new answer and displays it. The standards position is identical for all three; the observed outcome is not.

Running-code primacy does not overturn the BCP. RFC 3152 is authoritative about the intended root and delegation model. Execution tells us whether a particular query used that root, reached the intended authority, obtained the expected data and influenced the application as claimed.

The reality layers matter precisely because the migration was voluntary and distributed. A small initial specification—choose the infrastructure root, request delegation, align it with address allocation and deprecate the old name—created a common direction without requiring one synchronized global release. That economy made the move possible. It also made honest receipts indispensable.

The enduring lesson is not that DNS trees are easy to rename. It is that coordination can precede convergence without being fictional. IP6.ARPA could be correct before every resolver used it, and IP6.INT could be obsolete before its last operational trace disappeared.

Sources