RFC 3115：実装が選んだIANAの番号

要約

RFC 3025はCVSEを37、NVSEを133と記載したが、IANAは38と134を割り当てた。RFC 3115は、当時の実装がIANAに従っていたことを理由に旧RFCをobsoleteにした。
外側のtypeは未知拡張の扱いを決めた。0–127ならメッセージ全体を黙って破棄し、128–255ならその拡張だけを飛ばして残りを処理できた。

返事がない理由を、送信者は知らない

Mobile IPの登録要求を送った端末が、応答を待ち続ける。途中のforeign agentは要求を受け取っていた。しかし固定部の後ろにある拡張のtypeを知らず、データグラム全体を捨てた。プロトコル上、送信者へのエラー通知はない。

RFC 3115がいう「silently discard」は、何も記録しないという意味ではない。以後の処理を止め、送信者へ知らせない一方、実装は破棄したデータグラムの内容をログに残し、統計カウンターへ計上できるべきだとされた。ネットワーク上の沈黙と、運用証拠の欠如は別物だった。

この沈黙を左右するtype番号で、2001年に文書とレジストリが食い違った。2月のRFC 3025は、Critical Vendor/Organization-Specific Extension、CVSEを37、Normal版のNVSEを133とした。IANAの登録値は38と134だった。4月のRFC 3115は冒頭で差異を列挙し、RFC 3025を置き換えた。

理由は明快だった。現在の実装がIANAの割り当てに従っているからである。新しいRFCは、発行済み文書の数字を機械に押し戻さなかった。すでにwire上で選ばれていた値へ規範を修正した。

ただし資料は、実装名、版数、台数を示していない。障害の実例もない。「すべての製品が38と134を使った」とは言えない。それでも、稼働実態が二か月前のStandards Track文書をobsoleteにする判断材料になった事実は残る。

128の境界は失敗方針だった

RFC 2002はMobile IP拡張を二つの範囲に分けていた。0から127までの未知typeを受けた場合、メッセージ全体を黙って破棄する。128から255までなら、Lengthを使って未知のdataを飛ばし、残る拡張とmessage dataを処理し続ける。

CVSE 38は前者、NVSE 134は後者に置かれた。「Critical」は企業にとって重要だという形容ではない。受信者が理解できないなら、残りだけを処理してはならないという互換性宣言だった。「Normal」は、その私有機能を失っても、メッセージの残部は意味を保ち得るという宣言だった。

37と38はいずれもcritical側にあり、133と134はいずれもskippable側にある。したがって誤記が境界そのものを反転させたわけではない。それでも一致しないtypeは一致しない。38だけを知るparserに37を送れば、未知のcritical extensionとして要求全体が消える。134だけを知るparserに133を送れば、未知のnormal extensionとして飛ばされ、登録処理は私有機能抜きで進み得る。

前者はtimeoutに見え、後者は一部機能を欠いた成功に見える。最終的な成功・失敗だけを集計すると、どちらも原因を隠す。保存すべきなのは、受信したoctetとparserが選んだ分岐である。

外枠を知ることと中身を知ること

RFC 3115は、未知をもう一段分けた。受信者が外側のtype 38そのものを知らない場合と、CVSEの構造は知っているが、そのVendor/Org-IDまたはVendor-CVSE-Typeを知らない場合である。

外側が未知なら、0–127の規則によってsilent discardとなる。外枠を認識できれば、Length、組織番号、私有subtypeを読み取れる。そのうえでrequest内の組織またはsubtypeが未対応なら、適切なrejectを返さなければならない。

replyでは役割が加わる。次のentityへ転送するtransit nodeが未知の内側CVSEを見つけたなら、rejectを生成して下流へ送る。終端の受信者なら、そのreply自体をrejectとして扱う。NVSEでは、外枠を理解していて内側だけを知らない場合、そのextension全体を飛ばして処理を続ける。

したがって「unknown vendor extension」という一行ログでは足りない。外側type、parser version、外枠認識の成否、enterprise number、subtype、request/reply、ノードの役割、Length検証、drop/skip/reject、生成したcodeを残す必要がある。古い定数と、未導入の私有機能は同じ事故ではない。

enterprise numberは名前の領域だけを委ねた

CVSEとNVSEは四octetのVendor/Org-IDを持つ。上位octetは0、下位三octetはSMI Network Management Private Enterprise Codeである。その組織が二octetの私有subtypeとvalueを管理した。

ここで委譲されたのは名前空間であり、結果の支配権ではない。IANAは外側のMobile IP typeとerror codeを割り当てる。enterprise registryは組織番号を管理する。各組織は内側の意味を定義する。送信側は何を載せるかを選び、受信側は何を実装するかを選ぶ。Mobile IPのsecurity associationは必要なmessage authenticationを担い、operator policyが登録を許すか決める。

enterprise numberだけでは送信元を認証できない。正しく認証されたmessageでも、未知subtypeの意味は生まれない。意味を認識しても、実行権限は自動ではない。registration acceptedでも、利用者のtrafficやserviceが動いた証拠にはならない。

複数のCVSE/NVSEは固定部の後ろへ置けたが、中間nodeは順序を変えるべきではなかった。ログ保存時にTLVを整列すると、authenticatorが覆ったbyte列、送信者が作った順序、下流parserが見た入力が失われる。見やすい正規化が証拠を壊す場合がある。

Security Considerationsは、base Mobile IPの方法でmessageが認証されることを前提とし、新しいsecurity requirementを課さないとした。これは設計上の前提であり、実際の全経路が保護された証明ではない。authenticatorの結果と、私有意味のsupportと、local authorizationは別々に記録されなければならない。

四つのcodeが三者の経路を残した

Mobile IP登録にはmobile node、foreign agent、home agentが関わる。RFC 3115は未知のcriticalな内側情報を拒むため、100、101、140、141を定義した。

100と101はforeign agentによる拒否である。100はmobile nodeから来たCVSE、101はhome agentから来たCVSEを区別する。140と141はhome agentによる拒否で、mobile node起源かforeign agent起源かを区別した。

codeは「どの役割が、どちらから来た私有情報を理解できなかったか」の一部を表す。しかし、私有valueの業務上の意味、mobile nodeへの到達、後続の再試行、利用者が見たservice結果までは証明しない。

とりわけforeign agentがreplyのtransit nodeである場合、home agentが作った返答を受け取り、内側CVSEだけを理解できず、別のrejectへ変換し得る。一台のログだけでは、元の返答から最終結果への変化を復元できない。各hopのinput、認識、変換、outputが必要になる。

静的な番号集から生きたレジストリへ

RFC 1700は1994年時点のAssigned Numbersを一冊のsnapshotとして残した。RFC 3232は2002年、online IANA databaseがその方式を置き換え、RFC 1700は不完全で、ときに誤っていると明記した。RFC 3115は、その制度転換をwire上で先に経験した事例である。

online registryは割り当てを随時反映できる。RFCはfieldと状態遷移を深く説明できるが、発行時点で固定される。レジストリだけでは38と134の全処理規則が分からず、文書だけでは一つの誤った数値を検出できなかった。相互運用には両者のjoinが要る。

現在のIANA Mobile IPv4 NumbersにもCVSE 38、NVSE 134、四つのreject codeがRFC 3115参照で残る。これは現在状態の証拠であり、変更履歴の完全な再現ではない。2001年の判断を読むには、RFC 3025と3115の凍結文書も必要だ。

後年の仕様は利用例であって普及率ではない

RFC 4332はCiscoのVSEとして、home network prefix、default gateway、DNS、DHCP情報、configuration URLを定義した。RFC 4784はcdma2000 networkのdynamic key updateに、type 38とenterprise number 12951を使うVerizon Wirelessの三拡張を定義した。

これらは具体的な仕様用途を証明する。しかし導入台数、成功率、市場占有率、実packetの存在は証明しない。仕様にMUSTがあっても、特定装置が実行したとは限らない。

RFC 5612は後に、文書例専用のenterprise number 32473を割り当てた。架空の例さえ実組織の空間へ侵入しないようにする必要があった。RFC 6709はさらに、private extensionの柔軟性と、未知値の扱いが生むinteroperability・security・operational exposureを一般化した。

RFC 3115はその代償を早い時期に具体化していた。criticalを知らなければmessageを失い、normalを知らなければprivate functionを失う。二つの番号を直すことは、全実装が同じ失敗方針を読むための修復だった。

running codeは判決ではなく、独立した証拠だった

この話は「実装は常に正しい」という教訓ではない。コードにもbugがあり、registryにも変更があり、RFCにも誤りがある。RFC 3115が示したのは、文書とallocation authorityが衝突し、しかも当時の実装が後者を使っていたという限定された事実である。

packet captureは送信を証明しても受信側の解釈を証明しない。parser logは一台の判断を証明してもregistration successを証明しない。reject codeはprotocol transitionを証明してもuser serviceを証明しない。「current implementations」という記述も、設計意図より強く、完全な実装調査より弱い。

その強さを守れば、歴史は十分に明確である。RFC 3025は37と133を書いた。IANAは38と134を割り当てた。稼働中の機器はIANA側を話した。RFC 3115は文書をwireに合わせ、標準が自らの誤差を訂正できることを示した。

RFCは37と書いた。稼働中の機器は38を使っていた――RFC 3115

なぜ重要か

要約

返事がない理由を、送信者は知らない

128の境界は失敗方針だった

外枠を知ることと中身を知ること

enterprise numberは名前の領域だけを委ねた

四つのcodeが三者の経路を残した

静的な番号集から生きたレジストリへ

後年の仕様は利用例であって普及率ではない

running codeは判決ではなく、独立した証拠だった

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説