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

主要領域

基盤

主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。

二つ目のセグメントを待った確認応答:TCP 遅延 ACK の境界

インターネット史

二つ目のセグメントを待った確認応答:TCP 遅延 ACK の境界

順序どおりのデータを受け取っても、TCP は必ずしも直ちに ACK を返さない。短い待機には効率上の意味があるが、二つ目のセグメント、タイマー、損失の兆候が沈黙の終点を決める。

2026年9月4日

IETF

SRv6 ロケーターのリースが DHCPv6 をルーティング制御面に組み込む

SRv6 ロケーターは、セグメント・エンドポイントが SID を生成するためのアドレス空間の基盤である。RFC 10038は、その基盤を DHCPv6 リースとして配布できるようにした。利便性は明らかだが、権限も移る。プール選択、リース更新、経路の導入と撤回が一つの運用経路に並ぶ。ロケーターは単なる設定値ではなく、付与され、期限を持ち、到達可能にされる資源になる。

2026年9月4日
ここで許可されたヘッダーが常に信頼できるとは限らない:RFC 9878と SIP P-Header の適用範囲

IETF

ここで許可されたヘッダーが常に信頼できるとは限らない:RFC 9878と SIP P-Header の適用範囲

送信側が P-Header を含めてよいと判断した SIP メッセージを、受信側が含めてはならないと判断すれば、相互運用は失敗する。実装によって削除、拒否、受け入れが分かれ、料金処理、在圏ネットワーク、アクセスネットワーク情報の扱いまで不一致になる。値の真偽を確かめる前の問題である。

2026年9月4日

ケースファイル

登録者は海外に、.com レジストリはバージニアにあった:CNN 対 CNNews.com

`cnnews.com` を使う事業者と主たる読者は中国にいたと記録されている。それでも、名称の処分を実行し得る `.com` の登録記録はバージニアに結び付いていた。このずれが、名称そのものを対象とする手続を可能にした。外国の運営会社全般に裁判所の人的管轄が及んだ、という意味ではない。第四巡回区の判断は、その二つを混同しないための記録である。

2026年9月4日
リンクは位置情報そのものではない:RFC 9877と RDAP Geofeed の制御

IETF

リンクは位置情報そのものではない:RFC 9877と RDAP Geofeed の制御

Geofeed のリンクを見つけることは、参照先が分かるという意味にすぎず、ファイル内の位置情報の主張が検証済みになるわけではない。RFC 9877 は RDAP を範囲の限定された発見・権威性のシグナルとして扱い、鮮度、真正性、プライバシーを別々の統制に委ねる。

2026年9月4日
1バイトずつ開くことを拒んだウィンドウ:TCP の Silly Window Syndrome 回避

インターネット史

1バイトずつ開くことを拒んだウィンドウ:TCP の Silly Window Syndrome 回避

受信側に数バイトの空きが生まれても、その空きを直ちに通知する必要はない。TCP はあえて待つことで、小さな許可が小さなセグメントを延々と再生産する事態を防ぐ。

2026年9月4日
2バイトの番号がペイロードを偽るとき:RFC 9876と CoAP レジストリ管理

IETF

2バイトの番号がペイロードを偽るとき:RFC 9876と CoAP レジストリ管理

CoAP では、Content-Format を、ペイロードのメディアタイプと必要に応じたコンテンツ符号化を示す小さな整数として定義しています。RFC 9876が厳格化するのは、この整数に対応する登録手続きです。メディアタイプ、パラメータ、符号化、意味が一意でなければ、コードポイントの意味も確定しません。

2026年9月4日
bdNOG は執行委員会を監督する主体を示すが、方法は示していない

BDNOG

bdNOG は執行委員会を監督する主体を示すが、方法は示していない

bdNOG の公式ページは、理事会を最高権限、執行委員会(EC)を運営担当として示す。理事会は年次活動を承認し、EC に説明責任を負わせると説明される。一方、審査したページには、その説明責任を実行する手続きがない。

2026年9月4日

IETF

DNS 運用者の事前調整がなくても、リゾルバーは暗号化を選べる

利用者と再帰リゾルバーの間を暗号化しても、その先の通信まで自動的に保護されるわけではない。キャッシュに答えがなければ、リゾルバーは権威サーバーへ平文で問い合わせることがあり、経路上の受動的な観測者には別の区間が見える。RFC 9539は実験的な折衷案を示す。双方が事前に合意しなくても暗号化トランスポートを導入できるようにするものだ。調整の障壁は下がるが、いつプライバシー保護を試し、成功を記憶し、平文へ戻すかをリゾルバーの方針が決めるようになる。

2026年9月4日
接続を終わらせずに閉じた窓――TCP の persist 状態

インターネット史

接続を終わらせずに閉じた窓――TCP の persist 状態

受信ウィンドウがゼロになれば、送信側は立ち止まる。しかし、それは接続の死を意味しない。再び送れるようになったという知らせが失われたとき、TCP はどうやって待ち状態を解くのか。

2026年9月4日
一つのヘッダーでサイト区画全体を無効化する:RFC 9875 と HTTP キャッシュグループ

IETF

一つのヘッダーでサイト区画全体を無効化する:RFC 9875 と HTTP キャッシュグループ

レスポンスは、同じキャッシュと同じ URI オリジンの範囲で、保存されたレスポンスに不透明なグループ識別子を付けられます。その後、安全でないリクエストに対するレスポンスが、そのグループを指定して無効化を示せます。これは局所的な関連付けであり、複数キャッシュや異なるオリジンの同期ではありません。

2026年9月3日

IETF

DNS カタログゾーンはメンバー一覧をフリート全体の設定権限に変える

空のファイルは通常、情報がないことを示す。だが空の DNS カタログは命令になり得る。生成処理がメンバーを含まない有効なカタログを誤って公開すれば、そのカタログから設定されたセカンダリはゾーンと関連状態を削除し始める可能性がある。統治すべき対象はデータ量ではなく、一覧を書き換える権限である。

2026年9月3日
経路外の攻撃者が予測しにくくなった数値――TCP 初期シーケンス番号

インターネット史

経路外の攻撃者が予測しにくくなった数値――TCP 初期シーケンス番号

TCP 接続は数値の交換から始まる。歴史的な変更点は交換を隠すことではなく、観測された一つの数値から次の接続の開始位置を読めなくすることだった。

2026年9月3日

ICANN

ゾーンファイルの共有アクセスは、名前空間を再公開する権限ではない

午前9時、承認を受けた調査担当者が ICANN の CZDS から gTLD のゾーンファイルを取得し、チェックサムの一致を確認した。証明されたのは特定のバイト列が届いたことまでである。各ドメインの実質的な管理者、利用目的、ファイル全体の再公開権限は証明されていない。アクセスと権限を分けることが、この仕組みの統制点になる。

2026年9月3日
一つの削除命令が他者のドメインを壊す:RFC 9874 と EPP 依存関係の制御

IETF

一つの削除命令が他者のドメインを壊す:RFC 9874 と EPP 依存関係の制御

破壊的な EPP 状態遷移は、削除を要求したクライアントだけに閉じないことがある。従属ホストが別のクライアントのスポンサーするドメインと関連付いたままなら、その削除は DNS の依存関係、名前解決、クライアント間の整合性に波及し得る。RFC 9874 の権威は RFC Editor にあり、新しい EPP コマンドやレジストリ所有権の変更を定義するものではない。

2026年9月3日
第2のアドレスが主アドレスになる:RFC 9873 が変える EPP 連絡先データ

IETF

第2のアドレスが主アドレスになる:RFC 9873 が変える EPP 連絡先データ

EPP の連絡先更新は、より明確な状態遷移を表せるようになる。連絡先オブジェクトに追加のメールアドレスを一つ保持し、任意の `primary` 属性で主として扱うアドレスを示す。ただし、プロトコルが記録するのは関係であり、メールボックスの所有、配送、下流処理全体を保証するものではない。

2026年9月3日

IETF

デフォルト拒否は欠落した EBGP ポリシーを暗黙の権限から明示的な障害へ変える

外部 BGP セッションが確立していても、経路を受信・広告する権限が未定義のことがある。RFC 8212 はこの境界の既定値を変える。インポートポリシーがなければ受信せず、エクスポートポリシーがなければ広告しない。経営上の問いはセッションが稼働しているかではなく、誰が各方向を承認し、その承認がアップグレード後も維持されるかである。

2026年9月3日
公開鍵を信じられるものにした連鎖――PEM の証明書管理

インターネット史

公開鍵を信じられるものにした連鎖――PEM の証明書管理

公開鍵を入手しただけでは、その公開鍵が指定された通信相手のものだとは判断できない。RFC 1422は、証明書、認証機関、検証経路、失効情報を組み合わせ、Privacy Enhanced Mail における鍵の帰属を検討可能な制度的手続きとして構成した。

2026年9月3日

IETF

拡張 uRPF は全経路を信頼せず、実現可能な送信元経路を許可する

マルチホーム接続の顧客から届く正当なパケットが、受信ルーターの返路とは別のリンクを通ることがある。厳格な検査はそれを誤って破棄し、緩い検査は経路がある送信元を広く許す。RFC 8704 はその中間として、インターフェースごとに実現可能な送信元集合を作り、その権限と費用を明示する。

2026年9月3日
問い合わせより先に届くプレフィックス:RFC 9872 が変える NAT64 発見

IETF

問い合わせより先に届くプレフィックス:RFC 9872 が変える NAT64 発見

IPv6 のみのネットワークから IPv4 サービスへ到達する端末は、アドレス合成に使う IPv6 プレフィックスを知る必要がある。RFC 9872 は、その情報をアクセス網の信号として扱う。まず Router Advertisement から PREF64 を学習し、利用できない場合だけ DNS 発見を使う。

2026年9月3日