要約

  • 受信 ETR は、自分が参加できるアンダーレイ multicast group をローカルに選ぶ。RFC 9798 は、グループの世界的な割当て機関や能力証明の手続きを設けていない。
  • 根 ITR は、固有のアンダーレイ・マッピングごとに outgoing-interface-list のエントリを作る。Join を送った ETR を追跡する場合は、グループ値ではなく、ETR RLOC でなければならない Join/Prune の送信元 IP を使う。
  • PIM 認証が裏付けられるのはメッセージの送信元と完全性であり、グループの権限、経路の能力、メンバーの存在、配送までは証明しない。

一つのグループから人数は読めない

根 ITR に Transport=0 の Join/Prune が届き、Receiver RLOC に multicast address が入っている。このとき確定するのは、受信 ETR がそのアドレスでカプセル化フローを受けたいと要求したことだ。そこから ETR の数や、各サイトのホスト数を逆算する規則はない。

RFC 9798 は ETR の追跡方法を別に定める。ITR が Join を送った ETR の一覧を必要とするなら、受信した PIM Join/Prune の送信元 IP を使い、その IP は ETR RLOC でなければならない。要求先の group と要求主体の RLOC は、同じメッセージにあっても異なる役割を持つ。

RFC 9798 は 2025 年 6 月に Experimental RFC として公開され、RFC 8059 を更新した。Transport Attribute の構文や意味は変更せず、対象を Transport=0 の場合だけに限定している。Receiver RLOC の定義を広げ、unicast encapsulation には unicast address、multicast encapsulation には multicast address を使えるようにした。後者は、LISP core の underlay が IP multicast transport をサポートするときに限られる。

この MUST は、導入実績や遠隔測定を生み出さない。ETR は multicast underlay を使うと判断した後、自分が参加できる group を選び、tree の root とすべき上流 LISP site を特定し、RFC 8059 の形式で Join/Prune を作る。group 選択は RFC の範囲外にあるローカル判断だ。「参加できる」という判断を監査するには、能力試験、設定、許可 range、判断時刻を別途残す必要がある。

状態節約と不要トラフィックは同じ選択の両面

RFC 6831 は、site 内の (S-EID,G) と core の (S-RLOC,G) を分離する。ITR が packet を encapsulate し、core の multicast tree が複製し、受信 ETR が decapsulate した後に内側の state を照合する。

RFC 9798 は overlay と underlay の対応を三つに整理する。複数の overlay flow を一つの underlay flow に束ねる many-to-one、一つの overlay flow を下流 xTR の事情に合わせて複数の underlay flow に分ける one-to-many、そして一対一である。

many-to-one は core state を減らす一方、RFC 6831 が示すように、同じ core tree に束ねられた別 source の traffic が、参加していない受信 site にも届き得る。ETR は decapsulation 後に内側の (S-EID,G) がなければ捨てる。one-to-many は range 制約を分離できるが、root 側の copy を増やす。一対一は分離性を高める代わりに mapping と state を消費する。

根 ITR の実装責任は、固有の underlay multicast mapping ごとに OIF-list の新しい entry を割り当てることだ。copy 数にはローカルな rate limit を適用してよいが、その内容は RFC の範囲外である。したがって容量管理では、要求された group 数ではなく、mapping key、OIF、要求 copy、許可 copy、制限理由を照合する。

PxTR は range の境界をつくる。site-facing tree と外部 LISP core で異なる multicast range を用いる場合があり、hardware resource の制約で利用可能 range がさらに狭くなることもある。group が有効かどうかは、境界と platform と policy version に依存する。

Attribute の受理は capability negotiation ではない

RFC 5384 は PIM Join Attribute の TLV encoding と共通処理を定める。tree の構築に影響する attribute は、関係する router が encoding と個別 attribute を理解すると事前に分かる協調 domain で使う必要がある。通常の PIM では Hello option が、特殊な source encoding を理解しない neighbor への送信を防ぐ。

ところが RFC 8059 の LISP xTR は PIM Hello を交換せず、attribute 対応を交渉する Hello option もない。unicast head-end replication をサポートする system が attribute も理解すると仮定される。Transport と Receiver RLOC は non-transitive である。RFC 9798 は multicast underlay を追加しても、動的な capability discovery や中央 group registry を追加していない。

だから、証拠の層を分ける必要がある。parse 成功は表現の受理、range 設定は運用意図、OIF は control state、packet counter は動作中の forwarding、受信 trace は outcome を示す。仕様書に書かれた条件や一つの “valid” flag だけで、これらを代用してはならない。

認証は意味の正しさを承認しない

RFC 8059 によれば Join Attribute の security は PIM packet の security に依存し、attribute 自体は authenticity を増やさない。RFC 9798 は、多数の異なる group や重複 group を持つ Join が正当な traffic を妨げたり、複製資源を枯渇させたりする可能性を挙げる。そして RFC 5796 の PIM authentication を利用できること、ETR RLOC ごとの group 上限を設け得ることを示す。

これは新しい強制認可方式ではない。RFC 5796 は PIM-SM の link-local message を IPsec で守る方式と、SA、key、peer authentication の条件を扱う。適切な設定と記録があれば、message origin と integrity の根拠になる。それでも group の割当て、全 hop の multicast support、実在する member、data delivery は別問題である。

実務上の receipt は、Join/Prune bytes、parse 済み attribute、認証結果と SA、source ETR RLOC、ETR の選択根拠、root site、mapping cardinality、OIF、rate-limit、core state と counter、decapsulation、inner forwarding、受信結果を同じ correlation ID で結ぶべきだ。欠けた段階だけを不確実として残せる。

情報源