要約

  • ARINは、2024年5月に提出された提案2024.8を現在もOpenとして掲示している。申請者は、AS-SETを認証済みARIN IRRへ移す際、remarksに1,024文字と思われる上限があったと報告した。
  • 長い備考には、Lumenの生成器が読む Level3 members: 形式の参照が入る。Lumenの文書では、この形式が通常の members や mbrs-by-ref より優先される。
  • そのため同じAS-SETでも、一般的なRPSLの読み方とLumenの読み方で有効なメンバー集合が異なり得る。
  • 欄の拡張はAS-SETを連鎖させる回避策を減らせる。しかし、どの集合からフィルターが作られ、さらに配備されたかは証明しない。
  • 私有の互換文法を残すなら、解釈プロファイルの版と、標準展開との差分を含む生成記録を残すべきだ。

分析

文字数から始まり、意味の所在へ至る

Dale Carderが2024年5月9日に提出した内容は具体的だった。第三者の非権威IRRからARINへAS-SETを移行しようとしたところ、備考欄が1,024文字で止まるように見えた。複数の remarks を許すか、上限を増やしてほしい。現場では複数のAS-SETを鎖のようにつないで回避したという。

連鎖は単なる見栄えの問題ではない。一つの顧客集合が複数のオブジェクトと再帰参照に分かれれば、追加と削除の同期点が増える。ARINも、認証済みIRRへの移行に役立つ改善だと認め、他の開発項目とともに検討すると答えた。2026年9月9日の現行一覧でも、2024.8はOpenのままである。

ただし、Openは「何もしていない」の同義語ではない。当初から期限は示されず、今回もログイン後の環境で上限を再現していない。公開資料で確定できるのは、2024年の申告と現在の追跡状態までだ。

それでも、なぜ備考が1,024文字を超えたのかを追うと、製品改善の範囲を越える。

説明欄がメンバー欄を上書きする

RFC 2622では remarks は自由記述の説明である。AS-SETの構成員は members にASNまたは別のAS-SETとして書かれ、mbrs-by-ref は保守者を介した間接的な参加を定義する。通常の読者なら、集合の中身を知るためにメンバー属性を見る。

Lumenの2023年4月版LEVEL3 IRRガイドには、別の読み方が明記されている。AS-SETの備考に Level3 members: または Level3 mbrsby-ref: があると、その内容は通常の属性より優先される。個々の参照にはデータベース名を付けられ、複数IRRをまたぐ展開先を指定できる。

ガイド自身が「フィルター生成器に依存する集合オブジェクトの解釈」と呼んでいる。一般の生成器は標準の members を展開し、Lumenは印の付いた備考を見つけると標準欄を無視して別の集合を作る。RADbの現行ヘルプも、<DatabaseName>::<ReferencedObject> を備考に置く慣行を説明している。

この方式には運用上の理由がある。IRRは一枚岩の台帳ではなく、RIR、通信事業者、第三者が運営するデータベースとミラーの集合だ。同じ名前をどのソースで解決するかが重要になる。LumenはAS3356への顧客セッションに適用するフィルターをIRR情報から作り、日次で更新すると説明している。参照ごとにソースを固定できれば、誤ったデータベースを引く危険を減らせる。

従って、私有拡張の存在だけを欠陥とは呼べない。問題は、説明に見える文字列がある消費者には優先命令となり、その事実がオブジェクト単体からは読み取りにくいことだ。

台帳、解釈、生成、適用を分ける

まず保守者が意図を登録する。ARINが認証と入力検査を行い、オブジェクトを公開する。次に利用者が参照するIRRとミラーを選ぶ。Lumenの解析系は私有マーカーを認識するか判断し、ソースを束縛して有効集合を作る。その後、経路オブジェクトの収集とフィルター生成が続く。

生成結果のレビュー、配備、ルーターへの反映はさらに別だ。IRRの行からBGPの伝播やパケット到達を直接推論してはならない。ARINはLumenのパーサーを運営せず、LumenはARINの登録権限を決めない。各層の証拠は、次の層の事実ではない。

欄を広げると、分割されたAS-SETを一つに戻せるかもしれない。更新箇所が減り、移行は安全になる。しかし標準メンバーと私有備考が不一致なら、容量増加は不一致を解消しない。保守者が members を直しても、優先される備考が古いままなら、Lumen向け集合は変わらない可能性がある。逆にパーサーだけが変われば、オブジェクトの文字列が同じでも結果が変わる。

保存成功を合格条件にしてはいけない。二つの解釈が何を出したかを比較して初めて、変更の意味が分かる。

秘密を出さずに解釈を残す

最小の記録には、公開オブジェクトのキー、権威ソース、読み取った版のハッシュまたはシリアルを置く。次に、解析プロファイル名と版、発火したマーカー、優先順位を記す。受理した参照、拒否した参照と理由、各参照に結び付けたIRRソースが続く。

標準展開と私有展開の双方について集合のダイジェストを作り、追加・削除・未解決の差分を限定的に示せばよい。生成時刻とソースのスナップショットがあれば再現性が増す。「生成」「承認」「配備」「ルーターで観測」は別の状態として扱う。

ARINが担うのは保存側の説明だ。上限や複数行の扱いを変えるなら、対象オブジェクト、操作経路、既存値の扱い、外部パーサーの意味までは検証しないことを示す。採用しないなら、その判断と代替移行策を追跡ページに残す。

Lumenは解釈側の証拠を持つ。2023年ガイドは規則の存在を立証するが、2026年の全顧客環境を立証しない。現行プロファイルと比較出力があれば、顧客は保守作業前に結果を確認できる。

事故を推定しない

資料には、誤ったフィルター、経路拒否、リーク、障害、侵害、顧客被害の実例はない。利用中のマーカー件数も分からない。1,024文字は申請者の観測であり、今回の実測ではない。ARINの内部作業がないとも言えない。

結論は限定される。互換文法を直ちに捨てる必要はない。ただし、名前、版、入力、出力、差分、移行状態を持たせる。欄の拡張が保守性を改善し、解釈記録が意味の継続性を守る。この二つを一つの成果と呼ばないことが重要だ。

情報源