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

プロフィール

Analysis

Analysis のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。

方針文はネットワーク制御ではなかった: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日
フレームはデータグラムより長かった――RFC 894がEthernetパディングをIPの外に置いた理由

インターネット史

フレームはデータグラムより長かった――RFC 894がEthernetパディングをIPの外に置いた理由

受信バッファには46オクテットあるのに、IPv4 の Total Length は20を示している。どちらかが誤りとは限らない。Ethernet は最小フレームを満たすための長さを報告し、IP は自分のデータグラムの終端を宣言する。RFC 894は、同じ受信イベントに二つの正しい長さが存在できることを標準にした。

2026年8月31日