要約

  • James Kennedyは、LIRがPA空間を別の組織に割り当てるinetnumレコードで、既存のorg:参照を必須にする案を提案した。
  • 下流の利用組織が見つかれば、ネットワーク障害の対応先を絞れる。LIRには追加レコードの作成と更新が発生し、参照先が実際の利用者でなければ効果は薄い。

分析

ネットワークのセッションが切れた。担当者がRIPE Databaseを調べると、記録は仲介者で止まり、アドレスを使う組織には届かなかった。影響を受けたサービスの重要度も、次に連絡すべき相手も分からない。KennedyはRIPE 93でこの例を挙げ、IPv4 Provider Aggregatable（PA）ブロックの利用組織を記録する案をAddress Policy Working Groupに持ち込んだ。

現行のRIPE-826は、LIRが複数の下流ネットワーク事業者へサブアロケーションすることを認める。ポリシー順守の契約責任はLIRに残り、割り当てとサブ割り当てはRIPE Databaseへの登録対象だ。登録義務があることと、各レコードが誰を示すかは別の設計問題になる。

RIPE-767は2021年に、その違いをすでに記していた。通常のPA割り当てを記録するかは資源保有者に委ねる案を示す一方、別組織へのサブ割り当てや割り当ては記録するよう強く勧めた。公開データの確認にはAssisted Registry Checksも提案している。2024年版のRIPE-826は、引き続き全割り当ての登録を求める。

Kennedyが求めるのは新しい属性ではない。既存のorg:を、第三者が使うPAブロックのinetnumにも必須にする案だ。RIPE Databaseの仕様ではorg:は条件付きで、RIPE NCCと共同管理するオブジェクトなど、ソフトウェア規則が要求する場合がある。自社インフラ向けの記録、個人データ、RIPE NCCの執行手続きは、彼が説明した対象から外れている。

会場では、追加作業を誰が負うかが争点になった。Gert Döringは、自分のLIRでは組織オブジェクトを増やすための自動化変更が必要になると話した。既存データが正確な場合、誰が利益を得るのかという疑問も示した。Peter Hesslerは重複した組織IDや、実在の利用者につながらない値を懸念した。必須欄は、正確さを保証しない。

Kennedyは提案文がまだ公開されていないと説明し、議論を求めた。公開資料には、現在何件のPAレコードが下流の利用組織を示していないかという集計がない。その件数が分かれば、LIRの負担が少数の修正なのか、広範な自動化投資なのか判断できる。

出典