主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ケースファイル
CMC メッセージが届いても、証明書発行の権限まで届いたわけではない：RFC 10003
RFC 10003 は CMC をファイル、メール、HTTP、TCP で運ぶための取り決めである。安全な運搬の仕様と、誰が証明書を決めるかという権限は、同じ問題ではない。
インターネット史
速度は表示の手がかりであって回線ではない：RFC 1079 の Telnet 境界
1988 年、遠隔端末プログラムは、相手側端末について役に立つ情報を受け取りながら、その間のネットワークを知っているふりをせずに済んだ。RFC 1079 はその境界を明確にした。片方の Telnet ピアが端末の二つの速度を求め、もう片方が限られた形式で返す。値は画面表示や遅延用パディングの選択に使えたが、帯域、輻輳、遅延、経路、TCP 接続の品質を測定するものではなかった。
欧州・中東の国内通信事業者トレンド
各代替経路が確認されるまで、2G機器台帳は安全な停止計画ではない
機器を数えても、旧ネットワーク後にその機能が続くとは証明されない。
ケースファイル
鍵は可搬になった。保管責任は可搬になっていない：RFC 9964 と AKP の境界
RFC 9964 は、ML-DSA を JOSE と COSE でどう表現するかを定める。Algorithm Key Pair（AKP）は、アルゴリズムと公開材料を必須にし、公開鍵から私的材料を隔離し、公開入力だけで鍵指紋を計算できるようにする。また `priv` には、FIPS 204 が認める展開済み秘密鍵ではなく、32 バイトのシードだけを置く。
ケースファイル
完了したSCIM要求は、ドメイン間の決定ではない：RFC 9967
非同期の SCIM 要求に202が返り、後の Security Event Token に同じ取引値が現れると、仕事全体が決着したように見える。RFC 9967が与えるのは、その二つを追跡可能に結ぶ手掛かりである。それは受信側に、同じ人物・同じ資源・同じ権限判断を受け入れよと命じる仕組みではない。
IETF
Tobias FiebigとDNSの四つの到達性証明
「四つ」と聞くと、四台のサーバーを想像しやすい。RFC 10001が求めるのはそうではない。IPv4 で応答する権威サーバーを二つ、IPv6 で応答する権威サーバーを二つ確認する。二台のデュアルスタック機が両方に数えられるからこそ、台数と障害分離を混同しない設計が必要になる。
インターネット史
DHCP より前、4オクテットが文法を選んだ：RFC 1048 と BOOTP の64オクテット境界
ネットワークから起動する端末は、ネットワークを使うための情報をネットワークから受け取らなければならない。BOOTP の小さな `vend` 欄は、その循環を断つ最初の手掛かりだった。RFC 1048 は先頭4オクテットで後続データの読み方を共通化したが、その値を発した相手の正当性までは引き受けなかった。
インターネット史
その名前はアドレスだった。しかし経路ではなかった：RFC 1088 の IP-over-NetBIOS マッピング
RFC 1088 は 1989 年、IP-over-NetBIOS のホストに対し、IP アドレスから `IP.XX.XX.XX.XX` という十六バイトの NetBIOS 名を作る規則を置いた。各 `XX` はアドレス中の一バイトを ASCII の十六進表現にしたものだ。この名が分かれば、当該の NetBIOS データグラムを送るために物理アドレスを問い合わせる必要はない。だが、名が分かることと、そこへの経路、端点の本人性、あるいはアプリケーションの受理が分かることは別である。
インターネット史
四バイトは TCP に区切りを置いた。OSI ネットワークを作り直したのではない：RFC 1006 の TPKT 境界
TCP の受信側が得るのは、送信側の「一通のメッセージ」ではなく、順序を保ったオクテット列である。ISO Transport の TPDU を TCP 上で扱う RFC 1006 は、この差を TCP の誤りとは扱わなかった。四オクテットの先頭部で、どこまで読めば一つの TPDU になるかを定めた。
ケースファイル
レガシーのコードポイントはクライアントに届いた。サーバーを再許可したわけではない：RFC 9963
レジストリに新しい値が載ると、古い方式が全面的に戻ったように見えることがある。RFC 9963 はその読み方を許さない。三つの RSASSA-PKCS1-v1_5 値は、サーバーが `CertificateRequest` で明示して初めて、TLS 1.3 のクライアントが自分の `CertificateVerify` に使える。サーバーの署名には使えず、既定では無効にすべきで、IANA でも推奨されない。一時的なクライアント互換の通路であって、レガシー RSA の一般許可ではない。
ケースファイル
逆向接続は届いた。装置の本人性はまだ証明されていない：RFC 10011
Call Home の画面で「接続済み」と表示される瞬間は、運用者に強い安心感を与える。だが、その表示が示すのはまず TCP 到達という一場面である。RFC 10011 は RESTCONF のクライアント、サーバー、Call Home を設定する YANG の形を与える。RFC 8071 は逆向きの TCP 開始を規定する。どちらも、到着した接続が期待した装置の本人性、認証済み RESTCONF セッション、まして変更権限まで証明するとは言っていない。
インターネット史
トークンは接続を見つけた。サブフローを入れたのではない：MPTCP の MP_JOIN 境界
別のアドレス対から来た新しい TCP SYN が、すでに始まっている MPTCP 接続の一部になりたい、と申し出ることがある。MPTCP の肝は「経路が増えた」という標語ではない。既存状態の検索、以前の相手との連続性の確認、新しいサブフローを受け入れるローカル判断を分離したことである。
ケースファイル
耐量子鍵を追加しても、従来鍵の受信者はまだメールを開ける：RFC 9980
RFC 9980 は OpenPGP に耐量子暗号の選択肢を加え、ML-KEM と X25519 または X448 を一つの複合鍵として扱う方法を定めた。移行に必要な共通語彙ではあるが、メール全体に「耐量子」という印を付ける規格ではない。送信者は通信を止めないため、同じメールを PQ/T 鍵と従来鍵の双方に向けて暗号化できる。そこで RFC 9980 は条件を狭く置く。使われた受信者鍵のすべてが PQ(/T) 暗号化を支える場合に限り、そのメールの機密性を耐量子的と呼べる。
IETF
Weiqiang Cheng：SRv6 locatorのリースには、なお別の経路が必要だった
Release を受けたサーバーが binding を消しても、経路と広告が同時に消えたとは限らない。RFC 10038は、locator の払い出しを自動化すると同時に、解除時に別々の状態を逆順に確認しなければならない理由を示している。
欧州・中東の国内通信事業者トレンド
デジタル固定電話の最終通知は、重要な通話経路が確認されるまで安全な停止ではない
日付入りの通知は、事業者が最終手続を始めた証拠にはなる。しかし、それだけで利用者、テレケア、重要な通話経路が安全に引き継がれたことにはならない。
インターネット史
バナーは画面を区切った。方針までは決めなかった：RFC 933 と Telnet の表示境界
アプリケーションが画面を描き直すたびに安全表示を繰り返す代わりに、端末側が一度受け取ったバナーを保持する。RFC 933 はこの分担をプロトコルにしたが、表示文字列に分類や許可の権限まで与えたわけではない。
ケースファイル
高速パケットはセッションを Up に保った。変更を承認したわけではない：RFC 9985
RFC 9985が扱うのは、BFD の高頻度な生存確認を認証しながら、認証処理そのものを拡張性の障害にしないための境界である。状態を変える制御パケットには実装負荷の大きい MCI を使い、変化のない`Up`状態を保つ多数のパケットには負荷の小さい LCI を使える。この区分は BFD セッションの保護を整理する。経路変更、フェイルオーバー、顧客向けの正常宣言を自動的に承認するものではない。
インターネット史
NAK が拒んだのはパケットではなくポートだった：RFC 938 に見る受信と振り分けの境界
1985 年の実験的プロトコルは、パケット列を受信済みとして進めながら、そのパケットが指定したローカルポートを知らない、と同時に答えられた。RFC 938 の `PORT NAK` は、輸送層の受信記録をアプリケーションへの引き渡しと取り違えないための、きわめて明確な境界線である。
インターネット史
UUID は接続を渡った。権限は残った：RFC 927 が二度目のログインと引き換えにしたもの
パスワード入力を一度省いても、接続先の判断まで省く必要はない。RFC 927 は、認証済みユーザーを示す4オクテットを送る仕組みを定めながら、その認証を信頼するかどうかを接続先に残した。
インターネット史
その枝は「下流に誰もいない」と言った：RFC 1075 と DVMRP の期限付き非会員報告
1988 年の実験的なマルチキャスト経路制御では、あるグループのパケットを枝へ送り続けない判断が必要だった。RFC 1075 の答えは意図的に狭い。下流のルータは、特定グループについて自分の配下にメンバーがいないと通知でき、上流の隣接ルータは示された期間だけ、その枝への転送を止められる。これはインターネット全体の受信者名簿ではなく、転送木の一部分に関する暫定的な指示だった。