要約

  • 2026年9月9日に公開されたdraft-dong-sidrops-rpki-rtr-moa-pdu revision 01は、複数PDUに分けた集合の全部・一部撤回と、Refresh、Retry、Expire、Serial Numberの扱いを追加した。現時点では個人投稿のInternet-Draftであり、SIDROPS WG文書でもIETF標準でもない。
  • 本文は、MOA検証とIPv6 ROA検証の順序およびフォールバックを、profileに付随する予定の検証仕様の仕事としている。必要な最小成果物は、新しい中央命令ではなく、二つの検証面を結ぶ公開結果表である。

一つのMOAに四つのIPv4プレフィックスが入っているとする。キャッシュはサイズ上の都合で二つのPDUに分けてルーターへ送った。その後、元の各PDUから一つずつだけ認可が撤回された。撤回側は、以前の分割を記憶し、同じ箱に詰め直さなければならないのか。

revision 01は、その必要がないことを明記した。全部撤回なら全プレフィックスを一つにまとめても、元と同じ複数集合に分けてもよい。一部撤回なら、一つ以上のWithdrawal PDUの和集合が、撤回対象だけを過不足なく含まなければならない。ルーターはその和集合に対応するMOV認可を削除し、公告時と撤回時のPDU数の一致を求めない。

重要なのはパケット数ではない。認可された集合と、ある時点でその集合を運んだ分割方法を切り離した点にある。輸送上の偶然が認可の永続的な識別子にならない。

revision 00にはこの処理がなかった。公式差分では、正規順序、ライフサイクル節、検証範囲の切り分けも新設されたことが分かる。

sidropsという文字列はWG採用を意味しない

技術上の状態と同じく、手続上の状態も分けて読む必要がある。Datatrackerの文書ページとAPIレコードは、この案をActiveなIndividual Submissionとしている。IETF stream、担当Area Director、shepherd、目標の標準化レベルはいずれも記録されていない。履歴はGuozhen Dongによる9月9日の更新を示し、submission APIは著者と文書日を保存している。

文書名のsidropsは議論先を示唆するが、採用決定ではない。参照先のMOA profileはSIDROPS WG文書だが、その地位がPDU案へ自動的に移ることもない。IANAコードも依然TBDであり、割当要求と割当済みは別の状態である。

署名から転送までには別々の五段階がある

第一に、アドレス保有者がMOAへ署名する。MOA profile revision 04では、一つのIPv6 mapping prefixが一つ以上のIPv4 prefixについてmappingをoriginateすることを認可する。同じIPv4集合を複数のIPv6 prefixに認可する場合は、MOA自体を複数発行する。これは経路でも転送命令でもない。

第二に、relying partyが署名オブジェクトを検証する。RFC 6488の検査に加え、MOA内の全IPv4 prefixがEE証明書のIP address delegation extensionに含まれるかを確認する。profileは、RPKIが与えるのはauthorizationであって、本人認証やnon-repudiationではないとも記す。

第三に、キャッシュが検証済みMOAからPDUを生成する。prefix集合を正規順序にし、ルーター向けの状態へ投影する。認証されたキャッシュ接続は輸送を保護できるが、派生データを元の署名オブジェクトへ変えるものではない。

第四に、ルーターがローカルMOV databaseへ格納する。revision 01が基礎にするRFC 8210では、Serial Numberは一つのキャッシュの論理版である。別キャッシュ、別プロトコル版のserialは比較できず、reset後に維持されるとも限らない。Protocol Version、Session ID、Serial Numberの組み合わせは状態の比較可能性を示すが、保有者の意思を単独で証明しない。

第五に、4map6のBGP公告を評価する。4map6 revision 06は、IPv6 mapping prefixの到達可能性を調べ、Mapping rule Databaseを更新し、配布範囲をローカルポリシーで制御する。ここでようやく経路上の動作へ近づくが、実際の転送結果はさらに別の証拠である。

MOAとROAも同じものではない。RFC 9582のROAは、あるASがaddress prefixの経路をoriginateする権限を表す。提案中のMOAは、IPv6 mapping prefixがIPv4 prefixのmappingをoriginateする権限を表す。同じRPKI基盤を使っても、認可対象の行為は異なる。

WithdrawalとExpireは異なる失効である

revision 01はRFC 8210のRefresh、Retry、ExpireをMOA PDUへ適用する。Refreshの期限が来るとルーターはReset Queryを送り、応答待ちの間は既存MOAデータを使い続けることが推奨される。失敗後はRetry間隔で再試行する。成功しないままExpireへ達すれば、全MOAデータを削除し、接続回復までMOAに基づくMOV判断を停止しなければならない。

MOAデータが変わればSerial Numberも増分される。適切なセッション文脈の中で、古い状態や同期ずれを見つけるためである。

Withdrawalは特定の認可変更をキャッシュから受け取ることだ。Expireは新しい完全なビューを取得できない状態が長引いたため、ローカル側が古い集合全体を判断材料から外すことだ。一部撤回は他の認可を残せるが、期限超過はMOA入力全体を止める。

どちらもBGP経路の撤回やFIB変更、パケット回復を直接証明しない。署名MOA、PDU、MOV entry、BGP route、packet pathを一つの「無効」にまとめてはならない。

二つの検証が食い違う場所

MOA profileは、IPv4保有者の認可が正しくても、第三者が基礎となるIPv6 prefixを不正にoriginateすればtraffic hijackが起こり得ると説明する。そのためIPv6 ROA validationも推奨している。

PDU案はこの依存を繰り返したうえで、MOAとIPv6 ROAの詳細な相互作用、特に検証順序とfallback behaviorをscope外とした。そこはMOA profileに付随する予定のverification specificationが扱うという。

調査時点でDatatrackerの公開文書名をMOA、タイトルをMapping Originで検索すると、profile、PDU案、会議資料は見つかったが、その検証機能を名乗る現行文書は確認できなかった。これは公開記録の範囲内の所見であり、非公開実装にルールがないという証明ではない。将来の投稿も否定しない。

未解決の分岐は具体的だ。MOAがValidでもIPv6 ROAがInvalidならどうするか。NotFoundならどうか。installを止めるのか、選好を下げるのか、未評価として残すのか、operator profileへ渡すのか。MOA cacheがExpire前でIPv6 routeだけ変わった場合、どの観測時刻を使うのか。再接続時、mappingを戻す前に何を再検査するのか。

serialは一つのcache historyの順序しか示さない。二つの認可面の優先順位も、network policyも選ばない。厳密なwithdrawalは「何を消すか」を決めるが、「何を信じるか」は決めない。

4map6案が想定するcontrolled environmentは、初期範囲を限定する。一事業者または少数の協力事業者なら、事故を協議で解決できるという前提である。より広い利用には別文書の専用認証が必要とも述べる。閉じた運用合意は合理的でも、そのローカル規則をprotocol consensusに見せてはいけない。

二面の結果表を最小仕様にする

PDUを肥大化させる必要はない。配下のverification specificationまたは公開operator profileに、二面検証結果表を置けばよい。

各行には、MOA resultと理由、cache endpoint、Protocol Version、Session ID、Serial Number、観測時刻、mapping prefixのIPv6 ROA resultを並べる。そのうえで評価順序、一方が他方をblock・degrade・unevaluatedのどれにするか、保持または削除したlocal mapping state、policy version、実行action、復旧条件を明示する。

最低限、valid MOAとIPv6のValid、Invalid、NotFoundの組み合わせ、invalidまたはexpired MOA、Expire内外のstale cache、部分・全部撤回、cache reset、再接続後のresyncを含める。NotFoundをValidへ丸めず、未実施の検査を成功と表示しない。

Heng LuのMinimum Initial Specificationが示すように、共通化するのは相互運用に必要な最小境界でよい。各ネットワークの最終判断は残せる。Running Code Primaryの観点からは、実際に走った規則の証拠も必要になる。この表は私の編集上の提案であり、IETFやSIDROPSが採用した要件ではない。

revision 01は、認可集合を過去の分割方法に縛られず正確に退場させた。次は、二つの証拠が一致しないとき、その認可をどう判断へ戻すかを同じ精度で示す番である。

出典