要約

  • RFC 1547 は、機能の有効・無効を互いに互換な状態とし、実装が両方を扱い、ローカルな利用者が動的に選べることを求めた。
  • 生存確認の停止、圧縮の拒否、既定MTUへの復帰は、交渉の失敗ではなくプロトコル上の正しい終点だった。
  • 後のPPP仕様は、あるオプションを持たない実装も、それを持つ実装と相互運用しなければならないと明記した。

1993年に現れた1989年の要件

RFC 1547 の刊行は1993年12月だが、収められた要件文書の日付は1989年6月である。冒頭の履歴によれば、この要件は RFC 1134 以降の PPP 設計で用いられた。後に RFC として公刊したのは、設計記録を完全にし、将来の標準化にも役立てるためだった。

したがって、二つの日付を一つにしてはいけない。RFC 1547 は完成後の PPP に付け足した評論でも、フレーム形式の仕様書でもない。Internet Standard となるポイント・ツー・ポイント・プロトコルが満たすべき条件を保存した文書である。RFC 1134、1171、1331、1548、1661 は仕様の系譜を示すが、普及率や全実装の準拠を証明しない。

文書は一つの設計案を押しつけることも避けた。例は要件を説明するためで、別解を排除しない。問われていたのは、異なる現場条件を持つ二者が、それでも共通の動作点を見つけられるかだった。

オフはプロトコルの外ではない

生存確認が不可欠な回線もあれば、余分なトラフィックにしかならない回線もある。雑音の多い回線では追加の誤り訂正が有効でも、良好な回線ではトランスポート層と仕事が重なる。圧縮も、両端が共通のアルゴリズムを持ち、使う意思があるときにしか成立しない。

RFC 1547 は、どちらかを普遍的な正解にしなかった。対立する機能について、有効状態と無効状態が互換であること、実装が両方を支えること、そしてローカルな「利用者」が接続ごとに選べることを要求した。この利用者は人間とは限らない。自動方針も選択主体になり得る。

UDP チェックサムが例に挙げられた。UDP にはチェックサム無効を示す表現があり、受信側はそれを受理できる。PPP が UDP の形式を模倣すべきだという話ではない。欠如にも共有された意味を与える、という設計上の類推である。

設定画面にオン・オフがあるだけでは足りない。一方が他方のオフを異常と解釈すれば、両製品にスイッチがあっても互換ではない。相互運用性は、賛成がそろった場所より、意見が割れた場所で試される。

ハートビートの請求書

生存確認の要件は、この問題を具体的にする。RFC 1547 はリンクが動作しているか判定する仕組みを求め、既定では有効とした。リンクは down から始まり、双方向のパケット交換を確かめて初めて up とみなされる。

同時に、その仕組みは無効化できなければならなかった。公衆データ網では、keepalive のトラフィック自体が課金対象になり得たからである。専用線で障害検知を早めるパケットが、従量制サービスでは継続費用になる。技術的に同じ機能でも、経済的な環境が判断を変える。

既定値は共通の出発点であり、永久命令ではなかった。費用を負担するかはローカルに決められ、オフにした後の意味は双方に残る。

証拠の範囲も狭く読む必要がある。双方向交換の成功は、その時点のリンクを示すだけで、アプリケーションの正常性までは示さない。誤設定を検出するための識別確認は、厳密な認証ではないと明記された。さらに RFC 1547 はセキュリティ問題を論じていない。後世から保証を付け足してはならない。

圧縮しない、で交渉は完了する

RFC 1547 は圧縮アルゴリズムを標準化しなかった。両方のシステムが同意し、共通のアルゴリズムを持つ場合だけ圧縮する。交渉は単純で、必ず終わる必要があった。

決定的なのは、圧縮の拒否が常に優先する点である。一方の帯域節約願望は、相手が受け入れていない能力や負担を強制できない。「圧縮なし」は途中放棄ではなく、基礎リンクを保つ正式な終端状態だった。

これにより、任意の改善が隠れた入場試験になるのを防いだ。高度なモードを提案した瞬間に通常モードが壊れるなら、機能の多い装置ほど組み合わせを狭めてしまう。非圧縮の床を残すことで、未採用を排除せずに改良できる。

資料は、どのアルゴリズムが何回使われ、どれほど帯域を節約したかを示さない。確認できるのは統制の配置である。実装は能力を用意し、運用者は方針を選び、両端が合意する。拒否した側は基礎モードを守れる。

既定値は沈黙を埋める

MTU も同じ構造だった。各リンク種別には少なくとも1500オクテットの既定値を設ける。明示的な交渉または私的合意があれば別の値を選べる。合意がなければ既定値が共通値として機能する。

ローカルな最適化を禁じたのではない。片側の設定値だけを共有事実にしないため、二者の合意を求めたのである。

共通リンクに必要なのは、透過性、フレーミング、基本的な誤り検出、基本 MTU だった。リンク層の誤り訂正、フロー制御、順序制御は一律要件とされなかった。トランスポート層が関連サービスを持つためである。ただし雑音の強いリンクでは、他の要件を破らない範囲で私的合意により誤り訂正を追加できた。

古い全プロトコルとの後方互換、マルチポイント、半二重・単方向、7ビット非同期も非要件に置かれた。不要と断じたのではなく、全リンクが負う最低費用から外した。

固定された上下関係を持ち込まない

RFC 1547 は master/slave や gateway/host といった固定役割も避けた。異なる役が必要なら、その接続のために動的に選べばよい。

この対称性は拒否を正当なものにする。永久的な上位側がいれば、下位側の「使わない」をエラーにしやすい。対等な端点は共通文法から始め、必要な一時差だけを作る。ネットワークアドレスと圧縮の交渉は、いずれも単純で終端可能でなければならなかった。

将来オプションを受け入れる拡張性も要件だった。新機能が安全なのは、それを知らない既存の共通モードが消えないからである。

PPPは「ない側」にも相互運用を課した

RFC 1548 と後継 RFC 1661 は、成熟した PPP の語彙で要件を具体化した。標準既定値が一般的な構成を処理し、一端の改善は自動的に相手へ伝えられ、運用者は例外を設定できる。拡張可能なオプションで両端が能力と要求を記述する。

後の文書が示す optional の意味は厳しい。あるオプションを持たない実装も、それを含む実装と相互運用しなければならない。任意とは、開発者が作らなくてもよいという自由だけではない。存在と不在が安全に出会う責任をプロトコルが負う。

既定受信単位は1500オクテットのまま、同意する実装には別値が許された。LCP の Ack/Nak/Reject の詳細は別稿の対象である。RFC 1547 が扱うのはその前段、拒否とフォールバックを成功に含める要件判断だ。

一つの緑表示に四つの事実を詰めない

資料から運用上の推論が得られる。機能を実装していること、ローカルで有効にしたこと、相手と合意したこと、実際にそのモードで動いたことは別々の事実である。

製品資料は能力を、設定はローカルな意図を、完了した交渉は相互同意を、パケットやカウンターは実効動作を示す。それぞれは他の証拠を代用しない。

RFC の既定 MTU は現場値の証明ではない。設定済み keepalive は受信の証明ではない。link-up はアプリケーション成功の証明ではない。私的合意も実装済みとは限らない。

この四分類は RFC 1547 の逐語表現ではなく、資料から導いた編集上の推論である。それでも、オフ、拒否、既定復帰を意味ある状態とした設計には欠かせない台帳になる。

最小契約がローカルな未来を守る

Heng Lu の Minimum Initial Specification、Localized Future Decision、Voluntary Adoption は、現代からこの構造を読む枠組みになる。厳密な初期仕様が決定可能な互換集合を作り、その後の選択はローカルに残る。公刊だけでは採用の現実にならず、稼働系と自発的な協調が必要になる。

このレンズでは、オフを許すことは標準の弱体化ではない。共通の床を強くし、圧縮、追加誤り訂正、生存確認方針をリンク分断なしで進化させた。拒否の先にも有効な状態が残った。

ただし、これは現代の解釈であり、1989年の著者の主観を証明しない。彼らは Heng Lu の後年の用語を使っていない。史料が確かに示すのは、ポイント・ツー・ポイント標準が双方の yes だけでなく、一方の no でも評価されたことだ。機能は欠けてもよい。相手まで欠けたことにしてはならなかった。

出典