要約

  • RFC 2043は二つのSNA Network Control Protocolを別々に交渉する。0x804Bは0x004Bで運ぶLLC 802.2付きSNAを、0x804Dは0x004Dで運ぶHPR NLPを制御する。
  • Openedは対応する包形式をPPPで送信できることだけを示す。SNACPには設定オプションがなく、セキュリティも論じられていないため、もう一方の形式、回復結果、身元、認可、配送、実装、運用、業務セッションの成功は証明しない。

「SNAが開いた」という運用上の略記には、RFC 2043がわざわざ保存した区別がない。正確には、どちらか一方のSNA NCPが、対応するNetwork-Layer Protocolの送信を許す状態へ到達したのである。

1996年10月に刊行されたこの文書は、PPPやIBMネットワーク全体の歴史を語るものではない。点対点リンクの上で、二種類のSNA包をどう識別し、どう別々に有効化するかを定めた短い仕様である。その短さゆえに、許可と結果の境界がよく見える。

共通リンクの上に独立した状態が置かれた

RFC 1661のPPPには段階がある。まず物理層が利用可能になり、LCPがデータリンクを確立・設定・試験する。必要なら認証やリンク品質判定が行われ、その後にNetwork-Layer Protocolフェーズへ進む。そこで各ネットワーク層プロトコルが固有のNCPを実行する。

したがって、LCPのOpenedは運搬路の状態であって、搭載される全プロトコルの状態ではない。各NCPは独立に開閉できる。対応するNCPがOpenedでないのに、実装が対応しているネットワーク層パケットを受信した場合、RFC 1661はそれを黙って破棄するよう求める。

RFC 2043はSNAについて、さらに二分する。「実際には二つ」のSNA NCPがあり、一つはSNA over LLC 802.2、もう一つはLLC 802.2を伴わないSNA用である。二つは別々かつ独立に交渉される。一本の回線は、二つの状態を一つにする理由にはならない。

四つの値は二つの制御・データ対である

PPPのProtocol fieldでは、0***–3***がネットワーク層パケットを、8***–b***が対応するNCPを識別する。この規則に沿って、RFC 1700と現在のIANAレジストリは四つの値を記録している。

上側の対では、0x804BがSNA over LLC 802.2の制御を担う。NCPが開くと、0x004BはLLC 802.2付きのSNA XIDまたはFID2 PIUを一つだけ運ぶ。そこにはDSAP、SSAP、Control、LLC InformationというLLCの構造が残る。

もう一方では、0x804DがLLCなしSNAの制御を担い、0x004DがHPR Network Layer Packetを一つ運ぶ。包はNHDR、THDR、dataで構成され、LLCの各フィールドを含まない。

0x804BのOpenedから0x804Dの状態を推論することはできない。逆も同じである。監視記録が二つを「SNACP」という一語へ統合した瞬間、障害解析に必要な識別子が消える。

回復を行う場所と、回復したという証拠は違う

LLC付き経路について、RFC 2043はLLC(2)をリンクレベルのエラー回復に用い、その回復をPPPリンク両端のルータが実行すると明記する。これは責任の位置を示す重要な設計情報である。

しかし、責任の割当ては成功記録ではない。0x004Bを観測して分かるのは、その地点でLLC付き包が使われたことまでだ。再送が起きたか、遠端ルータが受理したか、PIUが処理されたか、SNAのhalf-sessionがBIUを扱ったかは、別のログや観測が必要になる。

HPRの0x004DはLLCを持たない。ただしRFC 2043は、オプションのHPRリンクレベル回復towerを実装すれば、HPR NLPをLLC over PPPの0x004Bで運ぶことも構造上可能だと述べる。それは実装の選択肢であり、二つのNCPを統合する規定ではない。

オプションのない交渉は大きな保証を運べない

SNACPはLCPと同じ交換機構を使い、Configure-RequestからCode-Rejectまでのコード1～7だけを利用する。一方で、RFC 2043はSNAにもSNA over LLC 802.2にもConfiguration Optionが存在しないと明記する。

ここにOpenedの意味の上限がある。固定された包形式を有効にすることはできるが、SNAの身元、アプリケーションprofile、回復目標、経路、認可、暗号特性、取引結果を交渉する欄はない。要求に含まれない情報をConfigure-Ackが承認することはできない。

Openedは狭いオートマトンの状態名であり、サービス全体の品質証明書ではない。

セキュリティは明示的に射程外だった

RFC 2043のSecurity Considerationsは、セキュリティ問題を論じないとだけ記す。PPPはネットワーク層フェーズの前に認証を行えるが、RFC 1661では既定で必須ではない。認証が実施された場合でも、その方式、相手、結果を示す独自の証拠が必要である。

SNACPのOpenedは身元、SNA内部の認可、機密性、エンドツーエンド完全性を証明しない。パケット長の上限も同様である。SNAパケットはPPP Information fieldの最大長に従い、RFC 1661の既定MRUは1500 octetである。それは容器の寸法であって、内容の到達結果ではない。

文書の存続と運用の存続を分ける

RFC 2200は1997年にPPP-SNACPをElectiveと記載した。RFC 3790は後にRFC 2043にIPv4依存がないと確認した。IANAは今も四つの割当てを掲載する。これらは文書上の位置、構造上の性質、番号の同一性を支えるが、導入数を示さない。

ここから特定製品の適合、相互接続試験、運用トラフィック、業務成果を導くことはできない。RFC Editorに現在登録errataがないことも、errataレジストリの状態を示すだけである。

Heng Luの枠組みで読めば、この仕様が共有層へ置いたのは最小限の規則だった。包を識別し、対応するNCPを開き、開く前のデータを拒む。実装、セキュリティ、回復の実績、採用は各参加者のrunning realityに残された。刊行は互換可能性を記述するが、運用事実を創造しない。

履歴には四つの証拠を別々に残すべきである。PPPがNetwork-Layer Protocolフェーズへ到達したこと。どちらのSNACPがOpenedになったか。対応するデータ番号が流れたこと。その後の受信やセッション結果が何であったか。この四つを一つの緑灯へ縮めれば、情報量ではなく確実性の錯覚だけが増える。

出典