要約

  • RFC 3678はソース互換性とバイナリー互換性を守るため、既存のマルチキャスト参加APIを変更せず、その横に送信元フィルター用のオプションと関数を追加した。
  • 差分型の操作は現在のフィルターにある送信元を一つ変える。全状態型はモードとリストをまとめて置き換える。グループを離れずにINCLUDE/EXCLUDEを切り替える場合に必要で、大きなリストも一回の操作で原子的に変更できるとRFC 3678は説明する。

既存の呼び出しは拡張できなかった

最初の制約はルーターではなく、すでにソケットを使っていたプログラムだった。送信元フィルターが導入される前、マルチキャスト受信アプリはグループに参加し、必要ならローカルインターフェースも指定できた。しかし、どの送信元を受け入れるかまでは表現できない。そこに情報を追加するため既存の呼び出しを変更すると、バイナリー互換性が崩れかねない。RFC 3678は、既存プログラムを壊さずに機能を足すには従来のAPIを変えられない、と明記した。

そこで文書は置き換えではなく追加を選んだ。新しいAPIには、古いソースコードが引き続きコンパイル・動作するソース互換性と、既存の実行ファイルが拡張対応システムで引き続き動くバイナリー互換性の両方を求めた。変更を小さく保ち、新APIが使えない場合をアプリが検知して適切に対応できることも重視した。これはAPI設計の情報提供文書であり、すべてのOSが同じ呼び出しを実装した証拠ではない。RFC 3678

一件ずつ変える

差分型APIはフィルターを段階的に変える。任意の送信元から受信するマルチキャストでは、最初は原則としてすべての送信元を受け入れ、ブロック／解除によって一つの送信元の扱いを変える。送信元指定マルチキャストでは、受信対象の集合に送信元を追加または削除する。呼び出し前の状態が大切だ。RFCは、無効な参加状態とオプションの組み合わせを、すでにブロック済みの送信元や未参加の送信元を操作した場合と区別している。

小さな変更を一つだけ行うアプリには、この文法が簡潔だ。「この送信元をブロックする」「この送信元に参加する」と伝えればよく、残りの一覧を送り直す必要はない。ただし、意味は現在のフィルターと参加状態に依存する。差分は変更分だけを表し、呼び出し後にあるべき全状態を宣言するものではない。IPv4専用の IP_ADD_SOURCE_MEMBERSHIP と、プロトコル非依存の MCAST_JOIN_SOURCE_GROUP のようなオプションが定義されている。RFC 3678

状態全体を置き換える

全状態型APIは別の用途を担う。アプリケーションは MCAST_INCLUDE または MCAST_EXCLUDE のモードと、含める／除外する送信元の一覧全体を渡す。この呼び出しは旧フィルターに一項目を適用するのではなく、フィルターそのものを置き換える。

RFC 3678は、この違いが重要になる場面を二つ挙げる。グループから離脱せずINCLUDEとEXCLUDEを切り替えたいアプリには全状態型APIが必要だ。送信元一覧が大きい場合も推奨される。一回の操作で変更を原子的に適用できるからだ。差分を何度も呼び出せば同じ集合に到達できることはあるが、それは中間状態を伴う複数の編集であり、一括置換とは異なる。

読み取りAPIにも独自の契約がある。アプリはバッファーの大きさを見積もり、総送信元数を受け取り、足りなければ再度読み出せる。実装が最大件数を設けている場合、その上限を超える設定は ENOBUFS で失敗し得る。「全体を置き換える」は状態管理の方式であり、容量無制限の約束ではない。RFC 3678

一つのグループ、二つのアドレス体系

RFCは既存のIPv4アプリケーションの変更を抑えるため、IPv4専用の構造体とオプションを残した。同時に、複数のアドレス族を扱えるソケット構造体でグループと送信元を渡し、ローカルインターフェースは別のインターフェースインデックスで指定するプロトコル非依存型も定義した。RFC 3493はIPv6ソケットの基本語彙を用意していたが、プロトコル非依存のマルチキャスト参加・離脱は定義していなかった。RFC 3678はそこを補った。RFC 3493

関数の引数を眺めるだけでは三つの意味が混ざりやすい。グループアドレスはマルチキャスト先、送信元アドレスは送り手、インターフェースインデックスはローカルな接続口を示す。検証済みの技術的Erratum 2524は、5.2.2節にある getsourcefilter の説明を修正した。「インターフェースのローカルIPアドレス」ではなく「インターフェースインデックス」であり、直前のset関数と一致する。別の検証済み編集Erratumは、存在しないエラー節への参照を直した。どちらもフィルターモデルを変更するものではなく、引数の意味を明確にする訂正だ。RFC 3678のErrata

このホストでのフィルターはネット全体のフィルターではない

ルーターがIGMPv3やMLDv2に対応していなくても、OSがホスト上で送信元を絞り込むことはできる。つまりアプリケーションはローカルな効果を得られても、不要なパケットがリンクを通らなくなったとは限らない。フィルター情報をルーターに伝えるのはプロトコル側の別機構であり、ソケット呼び出しとは別の状態と経路を持つ。RFC 3376、RFC 3810、RFC 4604はネットワーク側の動作を部分的に定める。RFC 3376 RFC 3810 RFC 4604

フィルターは送信者の認証機能でもない。送信元アドレスを許可済みのものに偽装したパケットは、フィルターだけでは止められないとRFC 3678は注意する。逆方向パス確認はルーティング構成によって役立つが、保証にはならない。ソケットAPIが成功したという記録から分かるのはAPI操作までであり、ルーターの状態、帯域削減、送信元の真正性、パケット受信、アプリケーションの成功までは証明できない。RFC 3678

RFC 3678はInformational文書で、インターネット標準ではないと明記している。公式のソケット規格も別に案内する。その歴史的な意義はより限定的だ。既存の参加APIを守り、一つの送信元を変える操作は軽く保ち、状態や規模が必要とする場合にはフィルター全体を一度で置き換える道を用意した。後年のLu HengによるNote 64とNote 65は、互換性とローカルな採用を考えるための分析レンズである。RFCの著者でも、承認者でも、2004年の設計に影響した根拠でもない。RFC 3678の情報ページ Note 64 Note 65

出典