要約

  • 現行のARIN Reg-RWSはWhoWas NETレポートの入力としてIPv4またはIPv6アドレスを認め、ReadMeもIPv6レンジを表現できる。しかし入力と形式だけでは、添付レポートにどの履歴が入るかは証明できない。
  • ACSP 2025.4と2026.5はIPv6履歴を求めた。ARINは有用な改善として内部の優先順位付けへ送り、公開提案を終了したが、納期や現行文書と結ぶリリース識別子は示していない。
  • 顧客データを使わない管理下のIPv6テストで、版、受付、チケット完了、保存開始点、対象オブジェクト、既知の欠落、訂正日を結ぶ「能力受領票」があれば、この不確実性は小さくできる。

履歴を調べたい利用者に最初に届くのは、履歴そのものではない。チケットである。認可を受けたアカウントからIPv6アドレスを送ると、Reg-RWSは形式を読み取り、WhoWasの処理に載せる。入口がIPv6を理解することは、この時点で確かめられる。

だが、過去はまだ戻っていない。

後で添付される帳票には、組織の変更や登録の削除が並ぶかもしれない。何も起きていなければ空でもよい。探している出来事が保存期間より古い場合もある。昔のネットワークと組織、POCの関係が移行されていない可能性もある。IPv6の一部世代だけが対象かもしれない。チケット作成の成功は、これらを区別しない。

ARINの現行文書は、区別すべき三層を近接して見せている。Reg-RWSのメソッド説明は、IPADDRESSにIPv4またはIPv6の単一アドレスを入れるよう求め、両方の例を載せる。WhoWas ReadMeのNet Rangeは、IPv4またはIPv6アドレスの範囲を表す。サービスの説明は、認可利用者がIPアドレスまたはASNの過去の登録情報を取得でき、レポートにはその資源の公開履歴全体が入ると述べる。

一方、2025年5月と2026年3月には、利用者がIPv6の履歴を追加してほしいと二度提案した。ARINは有用性を認め、優先順位付けと実装計画の内部工程へ送った。提案の状態はどちらもClosedになったものの、完成した版や試験結果へのリンクはない。

第二の回答後に機能が実装され、文書が現在の実態を正しく示している可能性はある。入力と帳票の器だけが先に整い、履歴データの範囲には制約が残る可能性もある。時期やオブジェクト種別による部分対応も考えられる。本稿はWhoWasへの認可アクセスを持たず、実際の照会を行っていない。したがって稼働の成否を断定しない。公開記録から言えるのは、入力、形式、保存データが同じ版で試されたことを示す受領票がない、という一点である。

きっかけはIPv6の理念ではなく、消えた登録だった

2025年5月9日のSuggestion 2025.4は、一般論から始まっていない。下流の事業体に割り当てられていたIPv6資源が正しく割り当てられた状態でなくなり、以前の登録詳細を調べる必要が生じた。提案者は、当時のWhoWasがIPv4資源のプレフィックス照会だけに対応していると説明し、IPv4とIPv6の同等性を求めた。

この利用場面では、現在のWhoisやRDAPだけでは足りない。現在値は、ARINが今だれを登録主体として示すかを答える。資源が返却、取消、再割当てを経たとき、必要なのは出来事の順番である。どのネットワークがどの組織に結び付いていたか、連絡先がいつ変わったか、登録がいつ削除されたかをたどらなければ、当時の管理責任は再構成できない。

5月21日、ARINはIPv6情報をWhoWasに加えることを有用な改善だと回答した。提案を優先順位付け待ちの改善一覧に入れ、内部の実装計画へ回した。そのうえで提案は閉じられた。このClosedは、本文を読めば公開提案工程の終了を意味する。製品の出荷証明ではない。提案者は時期を指定せず、ARINも日付を約束していない。

2026年3月31日、Suggestion 2026.5が同じ問題を再び示した。IPv6空間を取り消された事業体に対応するとき、IPv4やASNと同様の過去情報が必要だという。4月2日、ARINは前年の提案を明示し、繰り返された要望を開発優先度の評価で考慮すると答えた。これも内部工程へ送られ、公開提案は閉じられた。

反復は需要の証拠だが、稼働監視ではない。利用者が静かな更新を知らないこともある。権限不足を機能不足と受け取ることもある。「IPv6履歴」という言葉が、実は古い組織関係だけの欠落を指す場合もある。ARINの回答も、未決の改善が入力解析、帳票生成、過去データ移行のどれなのかを定義していない。版を共有しない限り、状態語の解釈だけでは前に進めない。

受付、帳票、保存内容を分ける

受付の仕様は明快だ。WhoWas NETレポートは、ハンドルやCIDRプレフィックスではなく、一つのアドレスを受け取る。IPv4とIPv6のどちらでもよい。成功時にはTicket Payloadが返り、その後に利用者が状態を確認して添付レポートを取得する。

ここには二つの成功がある。最初は依頼が受理された成功であり、次は履歴システムが意味のある出力を作った成功である。前者だけでは、出来事の数、最古の日付、ネットワークと組織の関係を説明できない。空の帳票が正常でもあり得る以上、HTTPやチケットの結果だけで完全性を評価してはならない。

帳票形式は別の能力を示す。ReadMeはNet RangeをIPv4またはIPv6の範囲とし、登録の作成、変更、削除といった動作を説明する。つまり形式にはIPv6の時間軸を語る語彙がある。しかし、列の存在は行の充足を保証しない。履歴システムでは、形式が先に広がり、旧世代データの移行が後から続くことがある。同じ帳票が、深さの異なる複数のデータ世代を包むこともある。

データへの最も強い表現はWhoWasの概要にある。アドレスは時とともに複数のネットワークに属し、それぞれが複数の組織へ発行され、組織にはPOCが結び付くため、現在のWhois応答より大きく複雑な報告になるという。ところが、IPv4とIPv6を分けた保持表、IPv6の最古時点、既知の履歴を持つテスト資源は示されない。

2001:DB8::が入力例にあるから完全な過去がある、と言うのはパーサーをアーカイブ監査に仕立てることだ。2026年の提案が存在するから機能がない、と言うのは行政記録を本番監視に仕立てることだ。どちらも証明にならない。構文は構文試験で、形式は形式試験で、履歴は既知の過去を持つ資源で確かめる必要がある。

空白には理由が要る

履歴サービスの品質は、結果がないときに最も厳しく問われる。何も変わっていないため空なのか。昔は異なる親ネットワークの一部だったのか。出来事が保存開始点より古いのか。ネットワークは移行されたが、組織やPOCの関係が移っていないのか。認可の問題なのか。それともIPv6のその範囲は未対応なのか。

不正利用の調査では、事件当時の管理主体を知る必要がある。移転の確認では、旧保有者から新保有者への連続性が重要になる。事業者は、顧客の割当てが消えた理由を説明しなければならない。法務は、特定日に公開されていた登録状態を求める。「出来事がない」と「出来事が保存されていない」は、いずれの場面でも逆の判断を生む。

「公開履歴全体」には合理的な境界がある。公開とは保護情報を除くことだ。履歴には保存または移行の開始点がある。全体とは、保持された公開イベントの全てであって、現実の運用に関する全事実ではないだろう。境界を示すことは約束を弱めず、利用可能な意味に変える。

理由分類がなければ、各組織は私的な経験則を作る。ある年以前は信用しない、IPv6ではPOCが欠けやすい、空ならサポートに送る、といった口伝である。これは版も来歴も持たない。既に直った欠陥への不信を残す一方、今もある制約を一般的な評判の中に隠しかねない。

計画とリリースのページが語らないこと

ARINのPlanned Functionalityは、自らを一般的な概要と呼ぶ。2026年の項目は、高可用性、技術的負債、方針・料金変更、ウェブ改善、SOC 2 Type 2、ルーティングセキュリティの製品などで、WhoWasのIPv6履歴は独立項目にない。

Software Releasesには、2012年3月のWhoWas開始、同年5月のReg-RWSによるWhoWas等のレポート提供が載る。2025年と2026年の見える範囲には、IPv6履歴の追加を名指す項目がない。ただし複数のリリースが細かな改善と不具合修正をまとめている。

この沈黙から未実装を導くことはできない。概要は完全なバックログではなく、リリース要約はコミット履歴ではない。小さな機能は大きな出荷に含まれ得る。日付付き項目の間に文書だけが更新されることもある。言えるのは、確認した公開資料に結合点が見当たらないことだけだ。

実装済みなら、ACSPからリリースと文書改訂へリンクすればよい。部分対応なら、年代とオブジェクト別の表が二択表示より役に立つ。現行文書が将来のインターフェースを先に記述しているなら、入力可能性と履歴範囲を分けて書けばよい。いずれも実在顧客の履歴を公表する必要はない。

誰のものでもないテスト資源

WhoWasは過去の組織や連絡先を含み得るため、ARINがアクセスを審査し、利用条件を求めるのは理解できる。だからこそ、公的な証明に顧客の添付帳票を使うべきではない。文書用または評価環境用のIPv6資源を設け、公開可能な既知の変化を用意する方がよい。

ネットワークを作成し、組織の関連を替え、POCを更新し、登録を削除または置換する。受領票には、試験した版と日付、アドレス、受付結果、チケット完了、添付生成、最古の期待イベント、確認できたオブジェクト種別を書く。非移行世代や保証しない関係も列挙する。後で修正した場合は、旧結果を消さず訂正日と理由を加える。

シナリオと期待結果のハッシュを保存すれば、出力を見た後でテスト内容を都合よく変えていないことも示せる。技術的な飾りではない。APIのURLが変わらなくても、入力解析、履歴データ、帳票生成の版は変わる。試した世代を固定するための来歴である。

この受領票は全アドレスの豊富な履歴を保証しない。全レコードを認証せず、ARINが想定しない大量照会を認めるものでもない。一つの限定的な命題だけを証す。同じ版の下で、IPv6入力、チケット、帳票形式、既知の履歴イベントが端から端まで接続した、という命題である。

制限する主体だけが安全に証明できる

ARINは認可、履歴データ、帳票生成、文書、リリース情報、ACSPを管理する。利用者は調べる資源と外部証拠を選ぶ。過去の組織は履歴に現れても、保存やアクセスを決めない。一般の読者はサービス説明を読めるが、結果を再現できない。

この非対称性は、慎重なアクセス管理の代償であると同時に、解決手段でもある。ARINなら合成例で証明できる。個々の利用者に実データの公開を求めるより、プライバシー上安全で比較もしやすい。

不足する接続は、おそらく一部署の失敗ではない。API担当はパラメーターを、データ担当は移行を、ACSP担当は工程移管を、リリース担当は主要変更を扱う。それぞれの文書が局所的に正しくても、利用者は一続きのサービスを経験する。同じ版なのかを知る必要がある。

断定を狭くすることが精度になる

WhoWasがIPv6を拒否するとは言えない。現行メソッドは入力を認める。IPv6履歴が完全だとも言えない。管理下の出力を見ていない。ACSP回答は期限を約束していないため、遅延の認定もできない。ClosedはReleasedではない。

確認できる事実は十分に具体的だ。2025年と2026年に利用者がIPv6履歴を求め、ARINは優先順位付けすべき改善とした。現在の入力と形式はIPv6を記述する。これらを結ぶ版または試験の記録は、調べた公開資料にない。

能力受領票はこの隙間だけを埋める。既に提供済みなら完成を証し、未提供なら勝手な納期を作らず終了条件を示す。部分対応なら制約を判断材料に変える。入口が開いたという事実に、アーカイブ全体の意味を背負わせずに済む。

出典