要約

  • RFC 1973 は Q.922 ヘッダーの後に PPP の NLPID 0xcf を置いたが、受信側は先頭バイト、Protocol-Field-Compression、対応する NCP の交渉状態を一緒に見なければならない。
  • 同じ LCP Identifier への応答が異なる framing address から複数届けば多地点への誤接続を疑え、NCP 完了後の同等な別封装は peer の状態喪失を示すため Link Establishment へ戻す。

1990年代の回線監視を想像すると、「Up」は強い言葉に見える。物理インターフェースは上がり、仮想回線にはフレームが流れ、DLCI も観測できる。しかし一方が PPP の交渉結果を保持し、もう一方が一般的な Frame Relay 封装へ戻っていたら、Up は会話の成立を意味しない。双方が送信を続けながら、受信側だけが捨て続ける黒穴ができる。

1996年6月の RFC 1973 は、点対点として構成された Frame Relay 回線で PPP を使う方法を定めた。PPP の LCP、NCP、認証、圧縮は二者の peer 関係を前提とし、多地点・多元接続向けではない。したがって問題は単なる多重化ではなかった。二者の状態機械を、必ずしも二者性を証明しない下位網の上でどう守るか、という問題だった。

同居できなかった二つのフレーム

PPP は ISO 3309 を基礎にした HDLC-like framing を用いる。かつては、それを Frame Relay framing と同じリンクで共存させる構想があった。RFC 1973 はその不可能性を率直に記す。Q.922 はアドレスを1オクテットから2または4オクテットへ拡張するが、DLCI サブフィールドの形は ISO 3309 の解釈と常に区別できるわけではない。受信側が境界を一意に読めない以上、共存は退けられた。

代わりに、フレームは明示的な順序を持った。0x7e の Flag、Q.922 Address、Control、NLPID 0xcf、PPP Protocol、その後に Information と Padding が続く。Q.922 の部分は Frame Relay の配達文脈、0xcf は PPP の選択、PPP Protocol は LCP、NCP、または運ばれるプロトコルの選択である。各フィールドは構文を絞るが、次の処理が成功したことまでは証明しない。

Address-and-Control-Field-Compression が禁止された理由もここにある。HDLC-like PPP では定数である値を省略できるが、Frame Relay の Address と Control は一定せず、交換網の通過中に変化しうる。冗長ではない配送文脈を圧縮してはならなかった。

PFC がバイトに状態を持ち込む

一方、Protocol-Field-Compression は二オクテットの PPP Protocol を一オクテットにできる。RFC 1973 は、NLPID を取り除き Protocol を圧縮すると Information が32ビット境界に揃うため、処理効率が上がる場合には PFC を交渉すべきだとした。

受信側の分類は段階的だった。Frame Relay ヘッダー直後の最初のオクテットがゼロなら RFC 1490 形式とみなす。0xcf なら PPP NLPID である。ゼロでも 0xcf でもない値を圧縮 PPP Protocol と見込めるのは、PFC が有効で、対応 NCP がすでに交渉済みの場合だけだ。それ以外では RFC 1490 形式として扱わなければならない。

つまり、バイトは単独でプロトコルにならない。同じ値でも、ローカルに保存された能力とフェーズがなければ別の構文へ進む。PPP Protocol の 0x00cf が予約されたのも PFC 時の曖昧さを避けるためである。RFC は「さらに PPP Protocol パケットが続く」という意味に使う余地を残したが、認証や上位配送の証拠にはしていない。IANA の現行表にも、NLPID の 0xCF と予約済み PPP Protocol 00cf が別々に残る。

三バイトの向こうに何人いるか

初期 LCP パケットはヘッダー後に cf-c0-21 を持つ。cf は PPP NLPID、c021 は圧縮されていない LCP Protocol である。LCP Configure-Request を認識すると、リンクは Link Establishment に入る。

ただし、これは開始の目印でしかない。要求の内容、長さ、オプション、応答はまだ検証されていない。LCP は Opened ではなく、認証も NCP も終わっていない。パケットキャプチャで三バイトを見つけても、「PPP 成功」とは言えない。

RFC 1973 はさらに、点対点フィードが誤って multipoint network や multicast group に接続された場合を扱う。一つの Configure-Request に対し、同じ Identifier を持つ応答が異なる framing address から複数戻れば、misconfiguration を表示すべきだとした。

Identifier は応答を同じ要求へ結び付ける。異なるアドレスは複数の観測元を示す。この組合せが診断を強くする。しかし一件の応答は peer の唯一性を証明せず、DLCI は組織の恒久的な身元でもない。アドレスを物理的に記録・報告できない実装もあると RFC 自身が認めているため、警告がないことも正常性の証明にはならない。

相手が以前の約束を忘れたとき

Link Establishment に入ると、Network-Layer Protocol phase まで他の NLPID は送信できず、受信しても黙って捨てる。未完成の PPP 状態機械へ、別の構文でデータを先回りさせないための隔離である。

特定 PPP Protocol の NCP が成功した後は、同じネットワーク層データを運ぶ RFC 1490 の同等封装が重要な異常になる。それを受けたリンクは Link Establishment へ戻り、新しい LCP Configure-Request を送らなければならない。相手が PPP 状態を失った可能性があり、古い合意に従う送信を続ければ黒穴になるからだ。

再交渉は原因を断定しない。相手の再起動、交換経路の変更、設定投入の失敗は別々の可能性である。捨てられたデータも戻らず、次の交渉成功も保証されない。それでも、曖昧なデータ面の症状を、結果を観測できる制御交換へ変える。

失敗時の方針はローカル要件で分かれた。PPP 設定や認証などの機能が必須なら Termination に進める。必須でなければ、Configure-Request が Max-Configure に達した後は RFC 1490 の封装だけへフォールバックする。一方は条件を守って停止し、他方は条件を下げて配送を残す。仕様は両者を同じ成功として扱わない。

1600 と 259 が語る実装条件

リンクは full-duplex が必須で、永久回線でも交換回線でもよい。Frame Relay の制御信号は LCP に Up/Down を渡すが、その信号の故障が PPP の正しい動作を壊してはならない。推奨オプションは Magic Number と PFC。初期 MRU は1600で、peer MRU 2048以上を明示的に交渉しない限り、ネットワーク層 MTU は1500以下が望ましい。

262オクテットのフレームしか扱えないスイッチもあったため、LCP 完了までは LCP パケットを259オクテットに制限できる必要があった。残りは NLPID と Protocol のためである。PPP 回線では XID と Inverse ARP を必須とせず、NCP 交渉がその役目を担った。これは特定の構成における相互運用条件であり、Frame Relay 全般の説明ではない。

RFC 2427 が後に廃止したのは一般多重封装の RFC 1490 と RFC 1294 であり、RFC 1973 ではない。RFC と IANA の登録は構文と番号を示すが、現在の導入率、製品実装、障害や成果を示さない。RFC 1973 の Security Considerations は安全性を論じないとだけ記す。番号から認証・完全性・機密性を補うことはできない。

出典