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

コンテンツ種別

Research

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

NATの「外側」は一つではなかった

IETF

NATの「外側」は一つではなかった

リフレクターが返したアドレスを端末の恒久的な外部名と呼んだ瞬間、観測地点と経路と時刻が消える。RFC 3424は、その省略こそが暫定策を設計原理へ変えると警告した。

2026年10月2日
権威サーバーは未知フラグを返した。その後を見ていない

IETF

権威サーバーは未知フラグを返した。その後を見ていない

応答側から DNS greasing を行っても、送信した事実だけではクエリアが受理したか、別サーバーへ再試行したか、アプリケーションが失敗したかを判定できない。

2026年10月2日
強い保護は提示されていた。攻撃者は選択前にそれを消した:RFC 3329

インターネット史

強い保護は提示されていた。攻撃者は選択前にそれを消した:RFC 3329

交渉で選ぶ対象は、交渉が終わるまで保護の外にある。RFC 3329が記憶させたのは、その不都合な順序だった。サーバーが一度提示した機構一覧を、保護が有効になった次の要求でもう一度返させ、相手側の静的な一覧と照合する。

2026年10月2日
REGISTER は終わる。経路はその先に残る:RFC 3327

インターネット史

REGISTER は終わる。経路はその先に残る:RFC 3327

登録応答を受け取った UA は、後の着信にどのプロキシ列が使われるのかを確認できる。RFC 3327 が Path を登録サーバーから UA に返した理由は、単に経路を保存することだけではない。追加された中継点を読み手に見える形にしつつ、その列を REGISTER の実測経路と取り違えないためでもあった。

2026年10月2日
レジストラは連絡先を知っていた。それでも到達経路は分からなかった:RFC 3327

インターネット史

レジストラは連絡先を知っていた。それでも到達経路は分からなかった:RFC 3327

登録の成功は、次の要求が届くことまで保証しない。SIP のレジストラは公開アドレスと現在の Contact を正しく結び付けても、その Contact へ戻る際に必ず通るべきプロキシ列を失うことがあった。RFC 3327は、その消えやすい経路知識を登録状態へ持ち込んだ。

2026年10月2日
暗号化は上限値を守らせない

IETF

暗号化は上限値を守らせない

通信路を暗号化すれば ECS の選択信号は途中で書き換えられにくくなる。しかし、再帰リゾルバーが実際に何ビット送ったかまで保証されるわけではない。

2026年10月2日
最初のRSTを信じず、二度目だけを信じる設計になった

IETF

最初のRSTを信じず、二度目だけを信じる設計になった

ECN 付き SYN への RST を受けても、実装はフラグを消して再送できる。RFC 3360が示したのは接続回復の工夫だけではない。中間装置の誤動作によって、RST という制御信号そのものが二段階の推測へ変わった事実である。

2026年10月2日
DE-CIXピアの大量BGPメッセージでRIPEのRRC12更新配信が停止

記事

DE-CIXピアの大量BGPメッセージでRIPEのRRC12更新配信が停止

RIPE NCC によると、DE-CIX の1ピアから通常を大きく上回る BGP メッセージが届き、RRC12 の更新ファイルを作る Kafka 処理プロセスが繰り返しタイムアウトした。確認時点で公開アーカイブは10月2日01:00 UTC のままだった。

2026年10月2日
電話は鳴り止んだ。それでもプロトコルは理由を残す必要があった:RFC 3326

インターネット史

電話は鳴り止んだ。それでもプロトコルは理由を残す必要があった:RFC 3326

Reason は処理に影響しない。それでも失われれば、端末は成功した通話を不在着信として記録し、クライアントは分岐中の失敗を正しく扱えないことがある。RFC 3326 は「無視できる情報」が持つ重い結果を設計した。

2026年10月2日
John CurranとARINが2019年に受けたレジリエンスの試験

リーダー

John CurranとARINが2019年に受けたレジリエンスの試験

2019年12月、ARIN では共有ストレージの障害により、仮想マシンの切り替えが機能しなかった。公開サイトと ARIN Online は別々の時刻に復旧した。その後の議事録からは、是正策、インフラのリスク、サービス状態を見える形にする取り組みを追える。ただし、すべての復旧目標が達成されたことまで証明する記録ではない。

2026年10月2日
ADT がない。それでも応答は直ちに bogus ではない

IETF

ADT がない。それでも応答は直ちに bogus ではない

署名済みゾーンから正しい DELEG RRset が届いたが、DNSKEY の ADT は設定されていなかった。検証器が選ぶべき結論は「偽物」でも「ダウングレード耐性あり」でもない。その中間を記録できるかが運用の成熟度を決める。

2026年10月2日
CANCEL に理由は添えられる。それでも取消を実行するのは SIP:RFC 3326

インターネット史

CANCEL に理由は添えられる。それでも取消を実行するのは SIP:RFC 3326

分岐した呼の一つが応答すると、プロキシは残りの枝を止め、その理由を短く添えられる。RFC 3326 は説明を運べるようにしたが、プロトコル上の操作まで説明欄に委ねなかった。

2026年10月2日
利用者は希望する身元を選べたが、プロキシはその選択を消さねばならなかった:RFC 3325

インターネット史

利用者は希望する身元を選べたが、プロキシはその選択を消さねばならなかった:RFC 3325

RFC 3325 が設計したのは、身元を運ぶための単純なヘッダーではない。利用者の希望を受け取り、その希望を検証済みの集合と照合し、ネットワーク自身の主張を作った後で、元の希望を意図的に消す手続きだった。

2026年10月2日
コンソールは開いた。ボーレートを知る人はいなかった

IETF

コンソールは開いた。ボーレートを知る人はいなかった

非常用経路は、必要になった瞬間に初めて触るものではない。RFC 3871 が通信設定の既知の初期化方法と単純な端末を求めた理由から、到達性・認証・権限・復旧結果を分離して読む。

2026年10月2日
同じ信頼ドメインにいても、互いを信頼してはいなかった:RFC 3324

インターネット史

同じ信頼ドメインにいても、互いを信頼してはいなかった:RFC 3324

RFC 3324 が描いた境界線の内側には複数のノードがいた。しかし A は C を信頼し、同じ内側の B は信頼しなかった。この非対称性こそ、ネットワーク表明アイデンティティを単なる「内部情報」にしなかった条件である。

2026年10月2日
LACNICの47大学セキュリティ指標、分母が明らかでない

記事

LACNICの47大学セキュリティ指標、分母が明らかでない

LACNIC が9月に公開した回顧記事は、エクアドルの大学でセキュリティ評価が最も深刻な段階にある割合が大きく下がったと改めて紹介した。公開資料には割合と対象群の説明はあるが、前後の変化を再計算するための人数が示されていない。

2026年10月2日
権限は変わった。キャッシュされた参照値は変わらなかった

IETF

権限は変わった。キャッシュされた参照値は変わらなかった

利用者が非公開ワークスペースから外された後も、以前に解決された識別子がキャッシュから返された。JSON は正しく、パスも同じだった。しかし、その値を使う資格だけが既に失われていた。

2026年10月2日
発信者は受信者には匿名でも、プライバシーサービスには匿名ではなかった:RFC 3323

インターネット史

発信者は受信者には匿名でも、プライバシーサービスには匿名ではなかった:RFC 3323

SIP が二者間を直接結べば、互いのネットワークアドレスを隠せない。RFC 3323 はこの物理的な限界から、匿名化には経路へ入る第三者が必要だと認めた。

2026年10月2日
相手には匿名でも、対話内では応答できる:RFC 3323

インターネット史

相手には匿名でも、対話内では応答できる:RFC 3323

RFC 3323 は SIP の発信者を消し去る仕様ではない。誰にどの識別情報を見せるのか、そして対話を継続するためにサービスがどの状態を保持すべきかを問うた。

2026年10月2日
空のLSPでは、戻ってきたルーターを安全に待たせられない

IETF

空のLSPでは、戻ってきたルーターを安全に待たせられない

再起動直後のルーターを経路計算から完全に消せば、早すぎるトランジット復帰は防げそうに見える。ところが iBGP の復旧には、そのルーター自身の loopback 到達性が必要になる。必要な到達性だけを残し、通過する権限を止める――RFC 3277の難しさは、この中間状態を順序どおりに広めることにある。

2026年10月2日