Summary

  • ARIN’s current Reg-RWS method accepts an IPv6 address for a WhoWas NET report, and its current ReadMe can describe IPv6 ranges; neither fact, by itself, proves what IPv6 history the attached report contains.
  • ACSP suggestions in May 2025 and April 2026 asked for IPv6 history and were closed into internal prioritisation, without a delivery date or a release identifier that reconciles them with the current documentation.
  • A privacy-safe capability receipt could bind one controlled IPv6 test case to request acceptance, ticket completion, retained-event horizon, populated record classes, known gaps and a dated software version.

The first reassuring event happens before the evidence arrives. An authorised operator submits an IPv6 address to ARIN’s WhoWas method. The address has the right form. The service accepts the request and returns a ticket. For an engineer watching the exchange, that is useful evidence: the route exists, the parameter parser recognises IPv6, and the workflow has begun.

It is not yet historical evidence.

The distinction sounds fussy only until the attached report matters. A ticket can prove that a request entered a system. A schema can prove that a field is able to hold an IPv6 range. A service description can promise history for an IP address. The archive, however, has to do a different job. It must contain the earlier registration events, associate them with the relevant networks and organisations, preserve the limits of the record, and return them for the resource under investigation. The success of the envelope does not certify the contents of the drawer.

ARIN’s public material currently places these layers close enough to invite a conclusion but not close enough to support one. Its Reg-RWS methods page tells users that the WhoWas NET report takes an IPv4 or IPv6 address. The WhoWas ReadMe describes a Net Range as a range of IPv4 or IPv6 addresses. The service overview says authorised users can obtain historical registration information for a given IP address or ASN and calls the report the entire public history of that resource. Yet two public suggestions, submitted ten months apart, describe IPv6 history as the missing capability.

ARIN’s replies call it useful and send it into prioritisation.

Perhaps the service was improved after the second reply and the documentation moved first. Perhaps the documentation describes a generic input and output contract while the historical data behind it remains uneven. Perhaps a report works for some IPv6 histories and not others. The available public sources do not decide among those possibilities, and this article does not pretend to have run the authorised service. The interesting failure is narrower: the public record lacks a common capability receipt.

The case arrived as an operational need

The 2025 suggestion did not begin with a standards argument. It began with a downstream entity whose IPv6 resource was no longer properly allocated. The operator wanted to recover previous registration details and said WhoWas supported prefix queries only for IPv4. That use case matters because current registration data are weakest precisely when the question is historical. A present Whois or RDAP response can tell an investigator what the registry publishes now. It cannot, by itself, reconstruct the chain through which a network range was created, modified, returned, revoked or associated with a different organisation.

The request was modest: feature parity between address families. On 21 May 2025, ARIN agreed that IPv6 information would be a useful addition. It placed the item on a list of suggested improvements pending prioritisation and referred it to the internal process for prioritisation and implementation planning. The suggestion was then marked closed.

That status is easy to misread. In a support queue, closed can mean that the user’s problem was solved. In ACSP, the accompanying prose says something else: the public suggestion has completed its passage into an internal planning process. Nothing in the response supplies a promised delivery date, a project identifier, a test result or a completion link. Closed is a workflow event, not a release attestation.

On 31 March 2026, a second operator asked again. The phrasing was even more direct: enable V6 for WHOWAS so users could see the history of IPv6 ranges, including cases in which entities had space revoked. ARIN’s reply on 2 April linked back to the 2025 request and said the repetition would be considered in prioritising the development effort. It again sent the matter into internal planning and closed the suggestion.

The repeat request is evidence of demand. It is not proof that the first submitter’s description remained technically complete in April 2026. Users can be unaware of a quiet deployment; a feature can exist in one channel and not another; an entitlement can make an available function look absent. ARIN’s own response is stronger evidence that some work was still being considered, but even that does not describe the exact boundary of the intended improvement. The disciplined conclusion is that the suggestion record and the current documentation are not joined by a shared, dated identity.

Three layers that should not be collapsed

The input layer is the clearest. ARIN’s current “Request WhoWas NET Report” method says the IPADDRESS field must be an IPv4 or IPv6 address. It gives an example from each family and rejects a handle or a CIDR prefix as the form of the request. If successful, the call returns a Ticket Payload. The user later checks the ticket and retrieves the report attached to it.

That is a carefully staged interface. “Successful” at the request step means that a ticket was returned. It does not say that the report contains an event, much less a complete sequence of IPv6 events. An address might have no prior changes. A range might fall before a retention boundary. A migrated record might lack a relationship that exists for newer data. A report might be technically valid and historically sparse. None of these outcomes can be distinguished by knowing that the request parser accepts IPv6.

The schema layer is also explicit. The WhoWas ReadMe says Net Range can contain IPv4 or IPv6 addresses and documents actions including creation, modification and removal of registration. A format with those fields can carry the evidence an investigator needs. But a capable schema is not a census of populated records. Databases often add a column before all historical sources have been migrated; export formats commonly describe the widest supported object while particular cohorts have narrower coverage. Conversely, an updated ReadMe may accurately announce that the backend now fills those fields. The text proves representational capacity.

It does not prove the population, horizon or exception classes.

The data layer is where operational assurance belongs. ARIN’s overview uses broad language: a WhoWas report contains the entire public history of an IP address or ASN. That promise is meaningful, but it does not publish an address-family matrix. It gives no controlled IPv6 example with known transitions, no earliest retained IPv6 event, no expected network–organisation–POC relationship set, and no gap classification. An authorised user may receive an excellent report. A public reader cannot establish that fact from the documents alone.

Keeping the layers separate is not scepticism for its own sake. It prevents two symmetrical errors. The first is to declare success because the endpoint accepts 2001:DB8::. The second is to declare failure because two suggestion pages still speak in the future tense. Both conclusions outrun the evidence. A registry should be assessed at the level where its claim operates: grammar by a parser test, schema by a format test, and historical coverage by a controlled result with a known expected past.

“Entire public history” needs a visible boundary

History is not merely a longer version of current state. It is a sequence with missingness, corrections and changes in meaning. An IPv6 range can move among parent and child networks. Organisations can merge or change identifiers. Points of Contact can be created, replaced or removed. A revocation may be visible as a registration action without disclosing why it occurred. Older systems may have stored a field differently from newer systems. The archive must distinguish “nothing happened” from “nothing was retained”.

That distinction changes professional decisions. An abuse team may be trying to identify who controlled a range when harmful traffic was observed. A transfer adviser may need to separate the present holder from a former registrant. A network operator may be investigating why a customer’s allocation no longer appears as expected. Counsel may be checking the evidentiary chain around a disputed resource. Researchers may study allocation and return patterns, although ARIN explicitly says WhoWas is not intended for high-volume querying.

In each case, an empty result has several possible meanings. The address may never have had a public historical transition. The query may identify the wrong point within a changing parent range. History may begin after the event of interest. Some object relationships may not have migrated. Access controls may limit the request rather than the underlying data. Or the desired IPv6 capability may not yet exist. Without a published taxonomy of outcomes, users have to infer which absence they are seeing.

The phrase “entire public history” therefore deserves a scope statement, not because the promise is necessarily false but because “public”, “history” and “entire” each have operational boundaries. Public excludes protected material. History begins at some retention or migration point. Entire can mean every retained public event, not every real-world fact about control. A capability receipt would make those boundaries legible without exposing a single customer record.

The planning pages cannot settle the runtime question

ARIN’s Planned Functionality page says that its lists provide a general overview. The 2026 projects are broad: high availability, technical-debt and policy work, website improvements, SOC 2 Type 2 compliance, and routing-security products. IPv6 history in WhoWas is not named. The Software Releases page identifies the original WhoWas service in March 2012 and WhoWas reports through Reg-RWS in May 2012. Its 2025 and 2026 summaries do not explicitly identify an IPv6-history release.

Those absences are worth recording and dangerous to overstate. A general plan is not a complete backlog. A release summary is not a commit log. Several releases group unspecified minor improvements and bug fixes. A small capability can ship under a larger item; a documentation change can appear between dated summaries; a feature can be deployed to authorised accounts without receiving a public headline. Silence does not prove cancellation or non-delivery.

But silence also does not perform reconciliation. If current documentation now reflects an implemented IPv6 history path, a dated cross-reference from either suggestion to the release would close the public loop. If the documents describe only the intended interface, the current service page should state the coverage boundary. If support is partial, a matrix would be more useful than a binary “supported” label. The present ambiguity is not that no source exists. It is that each source answers a different question.

A test address is more valuable than another adjective

The smallest useful disclosure would not be a new promise. It would be a controlled example. ARIN could maintain an IPv6 documentation fixture with a deliberately known sequence: a network record created, an organisation association changed, a POC relationship revised, and the registration removed or superseded. The record need not belong to a real customer. It could be reserved for documentation or reproduced in an authorised test environment.

A capability receipt would then record the version tested, the date, the submitted IPv6 address, the ticket outcome, whether an attachment was produced, the earliest expected event, the event classes present, and any known omissions. The result could be expressed as checks rather than as the full report. Personal data, customer evidence and internal notes would remain private. What becomes public is the assertion that a named software/data generation passed a named end-to-end test.

This approach is deliberately narrower than a service-level guarantee. It does not claim that every real address has a long history. It does not certify that every relationship in the database is correct. It does not transform WhoWas into a bulk research product. It only joins the three layers already visible in ARIN’s materials: an IPv6-capable request, an IPv6-capable report format, and a historical dataset capable of populating the expected transitions.

Versioning matters because capability can change without the URL changing. A parser can begin accepting compressed IPv6 notation. A migration can extend the retained horizon. A correction can restore organisation links. A new privacy rule can remove a field from public history. The receipt should therefore be append-only in spirit: keep the tested version, publish the correction date, and explain whether a later result supersedes or narrows the earlier one. A bare “yes” cannot carry that history.

Who controls the ambiguity

ARIN controls access to WhoWas, the underlying registry history, the ticket workflow, the documentation and the ACSP responses. The authorised operator controls the requested resource and the external evidence brought to the investigation. A former holder or downstream entity may be represented in the record but does not control the investigator’s access or the archive’s retention model. The unauthorised public can read the promises but cannot reproduce the result.

This arrangement is reasonable for a service containing historical contact and registration material. It also concentrates the ability to resolve ambiguity inside ARIN. An external user cannot safely publish a customer report merely to prove that IPv6 works. ARIN can publish a synthetic or controlled assurance result without exposing anyone. That makes a capability receipt unusually low-cost evidence: the institution with both access and stewardship can answer a narrow public question that individual users are poorly placed to answer.

The incentive to leave the surfaces separate is understandable. API documentation changes when request syntax changes. A ReadMe changes when fields change. Suggestion staff close a community item once it enters another workflow. Release writers summarise what seems material. No single team may own the join. But users experience the joined system. They need to know whether a valid input, a completed ticket and a populated report belong to the same release generation.

The honest conclusion is a request for binding evidence

There is no basis here to say that ARIN’s WhoWas rejects IPv6. The current method says the opposite at the input layer. There is no basis to say that IPv6 history is complete. No controlled output has been published in the sources reviewed here, and BTW did not run the authorised service. There is no missed deadline to announce because the ACSP responses promised none. There is also no basis to treat a closed suggestion as delivery.

What can be said is precise. In May 2025 and April 2026, public users asked for IPv6 history. ARIN described the capability as a useful improvement subject to prioritisation. Current documentation accepts IPv6 in the request and can represent it in the report. The planning and release summaries do not provide the common identity that explains when or how those statements converged.

That is exactly the scale of problem a receipt can solve. Name the version. Run one controlled IPv6 history. Record the request, ticket and expected event classes. State the earliest retained horizon and the known gaps. Link the result to the two suggestions and to the documentation revision. If the capability is already present, this is completion evidence. If it is not, the same checklist defines completion without manufacturing a date. Either way, the archive stops asking a valid request to carry more meaning than it can.

Sources