要約

  • RFC 3019のMLD MIBはinterfaceとmembership cacheを観測対象にした一方、管理者にcache行の作成・削除、local membership、MLDの有効・無効、timerやproxyの変更を許した。
  • したがって、cache行、last-reporter address、成功したSETが証明するのはagent上の限定された状態であり、現在のremote listener、認証された意思、forwarding、packet delivery、application receiptではない。

障害対応で欲しいのは、たいてい短い答えだ。「このgroupを聞いているhostはいるのか」。

RFC 3019の表には、その答えらしいものが並んでいた。IPv6 multicast groupとinterfaceの組ごとにcache行があり、最後にMembership Reportを送ったaddressも読めた。expiry timeもあった。

ところが、この表は受動的な観測帳簿ではない。managerは行を作れた。行を消せた。local systemがmemberかどうかを書けた。interface上のMLDを止めることも、query intervalやproxy interfaceを変えることもできた。

だから表が間違っているのではない。表が答える問いが、運用者の問いより狭いのである。

Interface行には設定と観測が同居した

RFC 3019は二つのtableを定義した。MLD Interface TableはMLDが有効なinterfaceごとに一行、MLD Cache Tableはmulticast addressとinterfaceの組ごとに一行を持つ。hostとrouterの双方が対象で、一部のobjectだけがrouter専用だった。

interface行には、Queryの周期、最大応答遅延、MLD version、現在のQuerier、累積join回数、現在のgroup数、Robustness Variable、last-listener query interval、proxy interface、Querierの経過時間と残り時間が並んだ。

同じ行にあるからといって、同じ性質の証拠ではない。join counterは過去の累積、group gaugeはagentが現在保持する行数、expiryは将来の条件付き予測である。書き込み可能なintervalはpolicyであり、受信eventではない。

cache行にもlocal membership、last reporter、row uptime、expiry、RowStatusが同居した。画面では一つに見える。調査では分けなければならない。

Last reporterは「今いる人」ではない

mldCacheLastReporterの定義は明快だった。そのgroupとinterfaceについて、最後に受信したMembership ReportのIPv6 source addressである。Reportを一度も受けていなければ0::0になる。

このobjectはlistener一覧ではない。継続中のsubscriptionを認証するobjectでもない。

RFC 2710のMLDは、直結linkに少なくとも一つlistenerがあるかをrouterに知らせる。複数hostは同じgroupのReportを聞くと、自分の重複Reportを抑止できる。最後に見えた一台のaddressが、実際のmember全体を代表することになる。そのhostが後で離れても、別のhostやlocal systemが状態を維持し得る。

mldCacheExpiryTimeもliveness checkではない。entryがage outするまでの最小残り時間を示す。ゼロは、mldCacheSelfだけがentryを残しており、router自身が離脱すれば直ちに消える状態を表し得る。ただしlocal Reportを他hostと同じように処理する実装では、ゼロである必要もなかった。

現在のremote listenerを主張するには、Report時刻、local membership、timer epoch、agentの連続性が要る。traffic receiptを主張するなら、forwardingとreceiver側の観測がさらに要る。

読み返した行をmanager自身が作れた

mldCacheStatusはread-createだった。managerは新しいcache entryを作り、既存entryを削除できた。base compliance groupの説明も、managerによるMLD cache entryの作成と削除を目的に挙げていた。

mldCacheSelfもread-createで、defaultはtrueだった。

現在の一行には複数の成因がある。link上のReportから学習したのかもしれない。local systemがjoinしたのかもしれない。管理操作で作られたのかもしれない。古いeventがtimerによってまだ残っているのかもしれない。

rowの値だけでは、その系譜が失われる。

たとえば測定用automationがentryを作り、その直後にGETして確認したとする。GETはagentが要求状態を保持した証拠になる。remote hostがReportを送った独立証拠にはならない。書き手と証人が同じ表だからである。

書き込み機能が悪いのではない。control recordをexternal eventのcorroborationとして使うとき、originを捨てることが問題になる。

一行のdestroyがMLDを止めた

mldInterfaceStatusをactiveにするとinterface上でMLDが有効になり、行をdestroyすると無効になった。

managerはQuery interval、最大応答時間、lossを想定したrobustness、最後のmemberを確認するintervalも調整できた。短いlast-listener intervalはleave latencyを下げるが、応答が状態を維持できる時間窓も変える。

mldInterfaceProxyIfIndexは影響範囲を別interfaceへ伸ばした。あるinterfaceで学習したmembershipを、指定したinterfaceからのMLD Reportに反映できた。ゼロならproxyなし、非ゼロならlocal cache stateがupstream actionの入力になる。

SET responseはagentが要求を扱った証拠である。次のQueryがwireに出たこと、neighborが受けたこと、multicast forwardingが変わったこと、applicationがdataを得たことまでは証明しない。

read-createでもwrite実装は必須ではなかった

MIB moduleでread-createを見ても、すべてのconforming agentがwriteを提供したとは限らない。

hostとrouterのcompliance statementは、mldInterfaceStatusのminimum accessをread-onlyにしていた。write accessはrequiredではない。schema上の最大権限、agent capability、VACM view、個別requestのauthorizationは別々である。

RFC 2579のRowStatusは行のgeneric lifecycleを定めるが、activeをdata-plane outcomeには変えない。再起動後の永続性やMLD engineとの同期も、別に確かめる必要がある。

「標準が書けると定義した」「このagentが書ける」「このprincipalが書ける」「今回の変更がprotocolとforwardingに効いた」は四つの命題である。

Security sectionはreadとwriteを別の危険として扱った

RFC 3019は、readable objectがmulticast sessionに関する情報を漏らし得ると述べた。mldCacheSelfとmldCacheLastReporterは、groupを聞くmachineの特定に使われ得る。unauthorized readをrelatively innocuousとした評価は当時の記述であり、今日のあらゆるgroupに適用できるprivacy ruleではない。

unauthorized writeはdenial of serviceを起こし得た。保護のない環境でSETを許すことはnetwork operationに悪影響を与える。

SNMPv1単独はそのようなinsecure environmentだと明記された。IPsecでnetworkを守っても、誰がどのobjectを変更できるかは決まらない。そこでRFC 2574のUSMとRFC 2575のVACMが推奨された。

channel protection、principal identity、view authorization、SET acceptance、protocol state、forwarding、receiver outcomeは別のreceiptである。

RFC 5519は後から粒度を増やした

RFC 5519は2009年にRFC 3019をobsoletesした。IGMPとMLDを一つのMGMD MIBにまとめ、host tableとrouter tableを分け、IGMPv3/MLDv2のsource filtering stateを追加した。

後継moduleは初期の二表modelにない区別を表現した。しかし、その区別を2001年のrowへ遡及させることはできない。RFC lineageはdesignの変化を証明するが、特定vendorの実装、deployment、migration、incidentを証明しない。

Lu Hengの考えは明示した分析lensとして使う。Running-Code PrimacyはMIB宣言とrunning agentを分ける。Reality Layersはrow、Report、policy、forwarding、receiptを分ける。Minimum Initial Specificationは小さな初期surfaceの価値と限界を同時に読む。

Lu HengはRFC 3019のauthorでもendorserでもない。

一行の表は役に立つ。役に立つからこそ、その行が語っていないことまで語らせてはいけない。

Sources