時間軸
複数年
複数年 は、時間軸 の観点から、シグナルが重要であり続けると見込まれる期間という時間軸で BTW Media の記事を整理するページです。直近の運用の変化と、四半期や年単位で進むガバナンス、投資、標準、インフラの長期的な変化を見分けるのに役立ちます。時間軸の前提を、公開された証拠、関係組織、市場環境、顧客への影響、政策圧力、インフラ計画と結び付けることで、動きが緊急なのか、戦略的なのか、裏付けとなる証拠を待つ段階なのかを判断できます。また、時間軸によってシグナルの意味がどう変わるか、影響を受ける可能性のある組織、短期的な対応が必要なインフラ判断と長期的な監視が必要な判断を解説します。
IETF
Russ Housleyと、証明書には記せても一意にはできないMACアドレス
証明書は6個または8個のオクテットを正確に固定できる。だが、その値を現在使っているインターフェースや、通信を許可した現場の判断まで固定できるわけではない。
インターネット史
最短経路は時刻を運んだが、親時計を選ばなかった――RFC 891のHELLO
RFC 891では、経路表の一行に往復遅延と時計オフセットが同居した。しかし、速い経路が時刻の権威になったわけではない。経路は測定で選び、親時計は設定で指定し、補正の可否は各ホストが判断した。
インターネット史
フレームはデータグラムより長かった――RFC 894がEthernetパディングをIPの外に置いた理由
受信バッファには46オクテットあるのに、IPv4 の Total Length は20を示している。どちらかが誤りとは限らない。Ethernet は最小フレームを満たすための長さを報告し、IP は自分のデータグラムの終端を宣言する。RFC 894は、同じ受信イベントに二つの正しい長さが存在できることを標準にした。
IETF
Benoît Claiseと、ベースモジュール自身には見えないaugment
依存関係を読むとき、出発点のファイルがすべてを語るとは限らない。YANG では、別のモジュールが外からノードを差し込める。RFC 10035は、その逆向きの関係をサーバーの現在形として記録する。
インターネット史
「誰かいるか」と「あなたが提供しているか」は別の質問だった――RFC 887のサービス発見
ブロードキャストへの沈黙は、明示的な否定応答ではない。RFC 887はこの違いを、質問そのものを二種類に分けて表した。さらに第三者の案内を、提供者本人の確認より弱い情報として扱った。
IETF
Kazuho Okuと、拒否を見える化してもストリーミングを約束しないHTTPフィールド
接続が切れず、サーバーも応答を作っているのに、最初のデータだけが届かない。RFC 10036は、その原因の一部を「対応する仲介者の明示的な拒否」に変える。一方で、フィールドを知らないホップまで従わせるものではない。
インターネット史
「公式リスト」は実装証明ではなかった――RFC 880が状態と動作中コードを分けた方法
Telnet の欄には、仕様書があるかだけでなく、古い手引きに残っているか、改訂版に収録されたか、一般に使われているかという別々の列があった。RFC 880は、ひとつの「対応済み」という言葉ではオプションの現実を表せないことを表の形で示していた。
IETF
Aaron Pareckiと、トークン窃取を止めてもクライアント乗っ取りは止めないBFF
OAuth トークンをブラウザの JavaScript から隔離すれば、持ち出して別の場所で使う攻撃は大きく減る。しかし、正規オリジン内で動く悪意あるコードは、利用中のセッションを通じて BFF に処理を依頼できる。RFC 10017は、この「守れたもの」と「まだ呼び出せるもの」を同じ成功表示にまとめない。
インターネット史
バックドアは経路ではなかった――RFC 831が分断されたSATNETへ届くまで
宛先だけを書き換えても、返事は戻らない。送信元だけを書き換えても、要求は届かない。RFC 831が想定した SATNET の分断では、往路と復路が別々の理由で失われていた。そこで UCL のマルチホーム・ホストは、限られた保守通信の両端を二度書き換える。ただし自らを経路として広告してはならなかった。
インターネット史
ゲートウェイはバイトを運べても、欠けた意味は作れない――RFC 875が問うたプロトコル変換
端末に文字が表示された。その事実だけなら、ゲートウェイは成功したように見える。だが、エコー以外のオプション、相手側の受信確認、緊急信号、障害時の会話まで同じ意味で渡ったのか。RFC 875は、最初の成功の背後に残る問いを設計の中心へ戻した。
IETF
Hannes Tschofenigと、token署名者ではなかったauthority ID
component を署名した key と、その測定結果を運ぶ EAT を署名した key は、同じ token の中に現れても別の責任を持つ。RFC 10013はその違いを注釈ではなく拒否条件にした。profile が分からないまま authority を推測してはならない。
インターネット史
マスターファイルは最新でも、ネットワークは古いまま――RFC 849 がプッシュとポーリングを分けた理由
更新時に停止していた一台は、通知を受け取れないまま昨日の HOSTS.TXT で再起動する。1983 年の RFC 849 は、この小さな空白を版の確認、配布、完全性、導入、回復という別々の状態として捉えた。
IETF
Corey Bonnellと、署名できてもCRL署名を許されていなかった鍵
検証画面に「signature valid」と出ても、CRL を信頼する判断は終わらない。署名した鍵が正しい主体に結び付いていることと、その鍵が失効情報を署名してよいことは別だからだ。RFC 10007は、v3 証明書で欠けていた後者の確認を明文化した。
IETF
Kireeti Kompellaと、serviceを証明しなかったEcho Reply
MPLS Echo Reply が示せるのは、明示した FEC に対して作った一つの probe が、その FEC を説明できる router へ届いたという事実である。全 ECMP path、待機中の backup、同一の復路、customer payload、application 完了まで一緒に証明するわけではない。LSP Ping の価値は緑の結果より、問いの境界を残すところにある。
インターネット史
毎週失効する「TCP対応」：RFC 832が稼働実態を測った方法
1982年12月7日の結果は、翌週にはもう最新版ではなかった。David Smallberg の「Who Talks TCP?」調査は、NIC のホスト表を完成した事実一覧として扱わず、検査対象を選ぶための申告一覧として扱った。Telnet、FTP、SMTP へ実際に接続し、拒否・到達不能・無応答・受理を分け、負の結果を再試行する。価値があったのは一枚の順位表ではなく、観測が必ず時刻と観測地点を持つという設計だった。
IETF
Eliot Learと、機器の証明ではなかった通信ポリシー
用途の限られた機器は、正常に動くために必要な通信をネットワークへ伝えられる。しかし、その申告だけでは、接続してきた個体の身元も、内部の健全性も、申告どおりに振る舞う将来も証明できない。RFC 8520の Manufacturer Usage Description は、この小さな申告を利用可能にしつつ、受入れ、絞り込み、実装、取消しの判断を local network に残した。URL、署名付き file、local policy、enforcement、観測 traffic を別々の証拠として扱うことが、この仕組みを attestation…
インターネット史
User と Server は機械の肩書ではなかった――RFC 818 がポート107に置いた Telnet クライアント
TC68K は、外から来た接続には Server として振る舞い、その数文字後には別の接続を開く User になった。同じ筐体が立場を変えたのではない。二つの関係が同時に存在したのである。RFC 818 はその間を疑似端末で結び、通常なら利用する側にある Telnet プログラムを、遠隔から呼び出せるサービスにした。
インターネット史
名前サービスは交渉役になりかけた――RFC 830がドメインと能力を分けた方法
宛先から二つのアドレスが返ったとしても、どちらが要求したサービスを実行できるかはまだ分からない。RFC 830の提案では、複数アドレスは選択肢であり、能力の証明ではなかった。ドメインを見つける処理の後に、別のプロセス同士が「何を提供できるか」を交渉したからである。この二段構えは、後に定着した DNS とは異なる共通層を描いていた。
IETF
Tero Kivinenと、稼働中のChild SAを引き継ぐ新しいIKE SA
IKEv2 の「rekey 完了」という表示は、どの鍵が変わったかをまだ語っていない。制御を守る IKE SA だけが新しくなり、ESP や AH のパケットを運ぶ Child SA は従来の SPI と鍵のまま、新しい親へ引き継がれることがある。RFC 7296が示すのは単純な鍵交換ではなく、制御の継承、Child の保管、実際の通信を別々に証明する必要性である。
IETF
古いセグメントが新しい接続を殺した：TCPのTIME-WAIT暗殺
TCP 接続が閉じても、その接続に属するパケットの複製がすべてネットワークから消えたとは限らない。TIME-WAIT は同じ通信の前後の世代を隔てる。RFC 1337は、古いセグメントが通常の TCP 応答を連鎖させ、その隔離を早すぎる時点で消し去る仕組みを示した。