Summary

  • Tore AndersonとJeroen Lauwersが起草したRIPE提案2023-04は2024年4月15日に承認され、IPv4 PA割り当てにAGGREGATED-BY-LIRを導入した。
  • LIRは連続した割り当てを、用途と連絡先が共通なら一つのオブジェクトにまとめられる。監査では中にある個別割り当ての件数を示す必要がある。

細かすぎる帳簿と空白の帳簿

RIPE提案2023-04が載せた2023年8月の数字は、台帳の悩みをよく表す。IPv4 PAの/32割り当て記録は546,402件。/32はIPv4アドレス一つ分だ。一方、10,052のLIRが持つ19,221件のPA割り振りには、子の割り当て記録がなかった。ネジ一本ごとに伝票を書く棚と、箱の中身を一度も書かない棚が同じ倉庫に並んでいた。

Tore AndersonとJeroen Lauwersは、その対照を登録方式の問題として扱った。LIRが顧客や自社設備にPA空間を割り当てると、RIPE DatabaseのINETNUMオブジェクトが使用範囲を記録する。小さな割り当てが頻繁に変わるプールでは、目的と連絡先が同じでも記録を一件ずつ作り直すことになる。提案によれば、子の記録をほとんど作らないLIRも、/32を大量に登録するLIRもいた。事務作業の量が記録の品質を左右していた。

新しいAGGREGATED-BY-LIR状態は、その間に引き出しを一つ作る。採用されたRIPE-822では、連続するIPv4 PA割り当ての用途と連絡先が一致すれば、一つの外側のオブジェクトにまとめてよい。公開台帳には範囲と責任者が残る。LIRはその中の個別割り当てを数え、RIPE NCCの監査時に統計を示せるようにする。書類が一枚になっても、中身の数は消えない。

IPv6に先例があっても、仕様を丸写しにはしなかった。IPv6では拡張時の計算に使うassignment-sizeが必須だが、IPv4のグループ内の割り当ては大きさが違ってよい。この属性は任意となった。一方、用途と連絡先の一致は条件として残る。隣り合うというだけで無関係な利用を同じ箱に放り込む規則ではない。

議論には気になる声もあった。外側にLIRの連絡先だけが載る場合、顧客の情報をどこまで見られるのか。提案記録はその異議を載せ、RIPE NCCが既存規則でも一定のLIR連絡先による登録を認めていたと記す。連絡先要件の広い見直しは別の議論に回り、この提案は反復作業を減らしながら監査可能な記録を残すことに集中した。

2024年4月15日に承認された。2023年の件数は出発点の数字であり、その後の利用実績ではない。Andersonたちが整えたのは、公開台帳を分厚くすることと白紙にすることの間にある、使える引き出しだった。

一次資料