メインコンテンツへスキップ

コンテンツ種別

Analysis

コンテンツ種別の観点では、Analysis は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。

メールボックスは連絡先であって管制室ではない:RFC 1173の「口頭伝承」

インターネット史

メールボックスは連絡先であって管制室ではない:RFC 1173の「口頭伝承」

初期のインターネットでは、障害を最初に見つけた人と、その障害に関係する機器を調べたり変えたりできる人は、しばしば別の組織にいた。RFC 1173が示したのは、その隔たりを一つの中央指令所で埋める方法ではない。問題を知らせる経路を、当該資源について実際の手段と責任を持つローカルな担当者へ届かせる方法だった。連絡先があることと、相手のシステムを統制できることは、同じではない。

2026年8月31日
方針文はネットワーク制御ではなかった:RFC 1087と「許容される利用」の境界

インターネット史

方針文はネットワーク制御ではなかった:RFC 1087と「許容される利用」の境界

1989年、Internet Activities Board は、共有された研究基盤を脅かす行為を名指しにできた。意図的な侵入、妨害、浪費、破壊、プライバシー侵害を受け入れられないと述べることもできた。しかし、一つの方針文が出来事を観測し、行為者を特定し、すべてのネットワークを設定し、警告を自動的な制御へ変えることはない。その隔たりこそ、RFC 1087 に残る実務的な歴史である。

2026年8月31日
そのビットが保証したのは帰路であり、要求の認証ではない:RFC 1044 の HYPERchannel SRC

インターネット史

そのビットが保証したのは帰路であり、要求の認証ではない:RFC 1044 の HYPERchannel SRC

経路の途中で一度でも疑義が生じれば、ビットは消える。最後まで残ったときに RFC 1044 が保証したのは、`TO` と `FROM` を入れ替えれば応答が元のプロセスへ届くことだった。これは物理ネットワークに関する有用な証拠だが、要求者の身元や実行権限まで証明するものではない。

2026年8月31日
速度は表示の手がかりであって回線ではない:RFC 1079 の Telnet 境界

インターネット史

速度は表示の手がかりであって回線ではない:RFC 1079 の Telnet 境界

1988 年、遠隔端末プログラムは、相手側端末について役に立つ情報を受け取りながら、その間のネットワークを知っているふりをせずに済んだ。RFC 1079 はその境界を明確にした。片方の Telnet ピアが端末の二つの速度を求め、もう片方が限られた形式で返す。値は画面表示や遅延用パディングの選択に使えたが、帯域、輻輳、遅延、経路、TCP 接続の品質を測定するものではなかった。

2026年8月31日
DHCP より前、4オクテットが文法を選んだ:RFC 1048 と BOOTP の64オクテット境界

インターネット史

DHCP より前、4オクテットが文法を選んだ:RFC 1048 と BOOTP の64オクテット境界

ネットワークから起動する端末は、ネットワークを使うための情報をネットワークから受け取らなければならない。BOOTP の小さな `vend` 欄は、その循環を断つ最初の手掛かりだった。RFC 1048 は先頭4オクテットで後続データの読み方を共通化したが、その値を発した相手の正当性までは引き受けなかった。

2026年8月31日
その名前はアドレスだった。しかし経路ではなかった:RFC 1088 の IP-over-NetBIOS マッピング

インターネット史

その名前はアドレスだった。しかし経路ではなかった:RFC 1088 の IP-over-NetBIOS マッピング

RFC 1088 は 1989 年、IP-over-NetBIOS のホストに対し、IP アドレスから `IP.XX.XX.XX.XX` という十六バイトの NetBIOS 名を作る規則を置いた。各 `XX` はアドレス中の一バイトを ASCII の十六進表現にしたものだ。この名が分かれば、当該の NetBIOS データグラムを送るために物理アドレスを問い合わせる必要はない。だが、名が分かることと、そこへの経路、端点の本人性、あるいはアプリケーションの受理が分かることは別である。

2026年8月31日
四バイトは TCP に区切りを置いた。OSI ネットワークを作り直したのではない:RFC 1006 の TPKT 境界

インターネット史

四バイトは TCP に区切りを置いた。OSI ネットワークを作り直したのではない:RFC 1006 の TPKT 境界

TCP の受信側が得るのは、送信側の「一通のメッセージ」ではなく、順序を保ったオクテット列である。ISO Transport の TPDU を TCP 上で扱う RFC 1006 は、この差を TCP の誤りとは扱わなかった。四オクテットの先頭部で、どこまで読めば一つの TPDU になるかを定めた。

2026年8月31日
トークンは接続を見つけた。サブフローを入れたのではない:MPTCP の MP_JOIN 境界

インターネット史

トークンは接続を見つけた。サブフローを入れたのではない:MPTCP の MP_JOIN 境界

別のアドレス対から来た新しい TCP SYN が、すでに始まっている MPTCP 接続の一部になりたい、と申し出ることがある。MPTCP の肝は「経路が増えた」という標語ではない。既存状態の検索、以前の相手との連続性の確認、新しいサブフローを受け入れるローカル判断を分離したことである。

2026年8月31日
LACNICとRIRを越える移行設計の経済学

記事

LACNICとRIRを越える移行設計の経済学

列車を止めずに分岐器を切り替えるには、線路だけでなく、運行権限と時刻表の正統性まで引き継がなければならない。

2026年8月31日
バナーは画面を区切った。方針までは決めなかった:RFC 933 と Telnet の表示境界

インターネット史

バナーは画面を区切った。方針までは決めなかった:RFC 933 と Telnet の表示境界

アプリケーションが画面を描き直すたびに安全表示を繰り返す代わりに、端末側が一度受け取ったバナーを保持する。RFC 933 はこの分担をプロトコルにしたが、表示文字列に分類や許可の権限まで与えたわけではない。

2026年8月31日
NAK が拒んだのはパケットではなくポートだった:RFC 938 に見る受信と振り分けの境界

インターネット史

NAK が拒んだのはパケットではなくポートだった:RFC 938 に見る受信と振り分けの境界

1985 年の実験的プロトコルは、パケット列を受信済みとして進めながら、そのパケットが指定したローカルポートを知らない、と同時に答えられた。RFC 938 の `PORT NAK` は、輸送層の受信記録をアプリケーションへの引き渡しと取り違えないための、きわめて明確な境界線である。

2026年8月31日
UUID は接続を渡った。権限は残った:RFC 927 が二度目のログインと引き換えにしたもの

インターネット史

UUID は接続を渡った。権限は残った:RFC 927 が二度目のログインと引き換えにしたもの

パスワード入力を一度省いても、接続先の判断まで省く必要はない。RFC 927 は、認証済みユーザーを示す4オクテットを送る仕組みを定めながら、その認証を信頼するかどうかを接続先に残した。

2026年8月31日
その枝は「下流に誰もいない」と言った:RFC 1075 と DVMRP の期限付き非会員報告

インターネット史

その枝は「下流に誰もいない」と言った:RFC 1075 と DVMRP の期限付き非会員報告

1988 年の実験的なマルチキャスト経路制御では、あるグループのパケットを枝へ送り続けない判断が必要だった。RFC 1075 の答えは意図的に狭い。下流のルータは、特定グループについて自分の配下にメンバーがいないと通知でき、上流の隣接ルータは示された期間だけ、その枝への転送を止められる。これはインターネット全体の受信者名簿ではなく、転送木の一部分に関する暫定的な指示だった。

2026年8月31日
キー入力は4オクテットになった:RFC 916が反復を状態に置き換えた方法

インターネット史

キー入力は4オクテットになった:RFC 916が反復を状態に置き換えた方法

4オクテットのパケットを単独で見ても、3番目のオクテットは読めない。接続開始なら受信上限、通常時なら長さ、`SO` が立てばデータそのものになるからだ。RFC 916の短さは、バイト列の外にある接続文脈を共有することによって成立していた。

2026年8月31日
読み値を報告しない名前:RFC 1065 と管理可能なものの形

インターネット史

読み値を報告しない名前:RFC 1065 と管理可能なものの形

1988 年のインターネット管理には、観測できるものを記述しながら、その記述を観測値そのものに見せかけない仕組みが必要だった。RFC 1065 はその抑制を与えた。管理対象のオブジェクト型には安定した名前、構文、符号化、アクセス区分を与えられるが、特定のインスタンスの現在値は別途取得すべき事実として残る。

2026年8月31日
「ここから読み直す」と告げた1バイト:SLIP、RFC 1055、そしてシリアルフレームを取り戻す代価

インターネット史

「ここから読み直す」と告げた1バイト:SLIP、RFC 1055、そしてシリアルフレームを取り戻す代価

シリアル回線を流れるのは完成したパケットではなく、時間順のオクテットである。雑音が混じった後には、受信側にどのフレームにも帰属できない断片が残りうる。RFC 1055 が勧めた先頭の `END` は、その断片を直すためのものではない。次のデータグラムの前に境界を一度置き、古い蓄積を次の読み取りの先頭にしないための、意図的に小さな再開始だった。

2026年8月31日
切替は一度ではなかった――RFC 897が改名とDNS参照を分けた理由

インターネット史

切替は一度ではなかった――RFC 897が改名とDNS参照を分けた理由

RFC 921 の旧工程表には、三種類の印が並んだ。予定どおり、遅れて実施、まだ未実施。DNS の誕生を祝う年表なら消してしまいそうな失敗が、ここでは移行状態を知るための一次資料になった。

2026年8月31日
ホストに見せないはずのLAN:RFC 925とトポロジーを隠す代償

インターネット史

ホストに見せないはずのLAN:RFC 925とトポロジーを隠す代償

初期のインターネット・サイトは、ケーブルごとに外部へ姿を見せることも、複数の LAN を一つのローカルネットワークだとホストに信じさせることもできた。RFC 925は後者の錯覚を選んだ。ホストの ARP は変えず、ホストが知る必要のない経路の発見、記憶、時には代理を中間装置へ移したのである。

2026年8月31日
運ぶ網が接続そのものではなかった――RFC 892が輸送状態と経路を分けた理由

インターネット史

運ぶ網が接続そのものではなかった――RFC 892が輸送状態と経路を分けた理由

下の接続が切れたとき、上の接続も必ず死ぬのか。RFC 892 の答えは class によって違った。class 0 では寿命が結び付く。回復機能を持つ class では、別の Network Connection へ割り当て直して同期し直せる。この差が、二つの「接続」を同じものとして扱えない理由だった。

2026年8月31日
最短経路は時刻を運んだが、親時計を選ばなかった――RFC 891のHELLO

インターネット史

最短経路は時刻を運んだが、親時計を選ばなかった――RFC 891のHELLO

RFC 891では、経路表の一行に往復遅延と時計オフセットが同居した。しかし、速い経路が時刻の権威になったわけではない。経路は測定で選び、親時計は設定で指定し、補正の可否は各ホストが判断した。

2026年8月31日