調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
記事
9社の申立てと消えた和解書――ARIN仲裁が実際に認めたもの
最初に争点となったのは詐欺の総額ではなく、実在顧客を確かめるための名簿だった。誰がその情報を持ち、誰が登録を動かせるかという非対称性が、裁判から仲裁、そして非公開和解への流れを決めた。
IETF
Jeff Tantsura と、まだ結果ではなかったインテント
画面の表示は緑のままだ。保護経路を維持するというインテントは受理され、必要な変更も一度は適用された。ところが、その後のトポロジー変更で代替経路が失われている。残っているのは望んだ状態の記録であり、現在の通信が得ている結果ではない。Jeff Tantsura が共著した RFC 9315 は、このずれを見分けるための重要な線を引いている。
インターネット史
オリジンの代わりにネットワークが答えた――HTTP 511が必要だった理由
行き先は天気サービスなのに、返ってきたのは施設のログイン画面だった。HTTP 511は、経路上のネットワークが応答を差し替える場面で、接続条件の通知とオリジンの人格を切り分けようとした。その限界をたどると、キャプティブポータルが後に、事前通知された認証可能な状態 API へ向かった理由が見えてくる。
ケースファイル
次の鍵は通知されたが、届けられてはいなかった：TCP-AOと鍵エポックの権威
説明用の鍵切替シナリオでは、午前2時7分、監視画面が緑になった。双方の BGP ルーターに鍵42が表示され、packet capture にも`RNextKeyID=42`が見える。運用者は切替完了と判断し、鍵17を削除した。数秒後、TCP 再送が増え、BGP は Established を離れた。相手に届いたのは番号であって、新しい鍵を使えるという共同事実ではなかった。
インターネット史
安定化が復旧を遅らせたとき――ルートフラップ・ダンピングの選択
IP プレフィックスを正しく保有し、障害を直し、BGP で再広告しても、それだけでは世界中のルーターが直ちに経路を採用するとは限らない。1990年代の限られた処理能力を守ったルートフラップ・ダンピング（RFD）の歴史は、番号資源の記録と実際の到達性が別の権力によって動くことを示している。
インターネット史
折り返し電話をやめたサーバー――パッシブFTPはいかにファイアウォールを越えたか
FTP がファイアウォールに適応した核心は、転送方式の全面刷新ではなかった。二本目の接続を誰が開始するかを入れ替えたのである。サーバーは待ち、クライアントがかける。その小さな反転は到達性を改善したが、相手を信頼してよいという証明までは与えなかった。
ケースファイル
距離の余白を使い切ったパケット：BGP GTSMが近接性に与える権限
説明用のシナリオでは、午前2時の経路切り替え後、ping は通るのに BGP だけが戻らなかった。送信側は引き続き TTL 255で TCP セグメントを出している。ところが復路にルータが一台増え、受信値は253から252へ下がった。受信側の GTSM は253以上しか認めない。障害の原因は鍵でも経路ポリシーでもなく、「この近さなら通す」という約束と現実の距離の不一致だった。
インターネット史
本文が始まる前に大きすぎたリクエスト：HTTP に 431 が必要だった理由
HTTP リクエストは、本文を読まれる前に拒否されることがある。プロトコルが世界共通の上限を決めたからではない。受信側が、どれだけの制御コンテキストを処理するかを決めたからだ。431 は、その局所的な境界を共通の返答にした。
インターネット史
小さな経路表を覚えたホスト――IPv6は最初のルーターをどう順位づけたか
IPv6 はホストを経路制御プロトコルの参加者にしなかった。ルーターが少数の期限付き候補を示し、ホストが最長一致、到達性、ローカル方針を組み合わせる。その境界こそが設計だった。
ケースファイル
フィルターはセッションを越えたが、境界は越えなかった――BGP ORFと「少なく求める」権限
顧客は受信 prefix-list をフルルートから数百経路へ変更した。自分の RIB はすぐ小さくなった。しかし上流は、依然として全経路を計算し、queue に入れ、送信し、最後に顧客が捨てているかもしれない。Outbound Route Filtering は「不要」という希望を sender 側へ運び、無駄を手前で止める。その希望は、sender の export 境界の所有権まで運ばない。
IETF
Linda Dunbarと、隣接先を作り出してはならないディレクトリ
「該当なし」は、常に同じ意味ではない。情報が不完全なディレクトリなら、まだ知らないだけかもしれない。対象範囲を完全に把握しているなら、存在しないという判断に近づく。Linda Dunbar が共同執筆した四つの TRILL RFC は、この差が単なるデータ品質ではなく、フレームを探索するか捨てるかを分ける運用上の権限であることを示している。
インターネット史
返事の前に数えたサーバー――HTTP 429 が必要になった理由
扉が壊れたのでも、要求の形が突然誤ったのでもない。サーバーが選んだ数え方の中で、今使える枠を越えただけである。HTTP 429 はその拒否を共有語にしたが、誰を一人と数えるかまでは決めなかった。
ケースファイル
セッションは Established、経路はゼロ――RFC 8212が問い直す「明示的な許可」の権限
更改直後の境界ルーターで、BGP セッションは `Established` と表示されている。KEEPALIVE は続き、障害アラームもない。しかし IPv4 の経路は一つも採用されず、相手にも何も広告されない。通信路は成立しているが、経路を運ぶ権限は成立していない。RFC 8212 は、この一見矛盾した状態を障害ではなく、安全側に倒れた正常な初期条件として定義する。
インターネット史
沈黙がアドレスを許した――IPv6 DADが証明できた範囲
IPv6 DAD は、限られた local probe で競合が見えなかったという負の観測から address 利用を許した。重要なのは、その沈黙の権限を広げないことだった。
記事
RIPE Atlasの復旧記録に、影響を受けた測定集合がない
障害の終点は時刻だけで示せるだろうか。RIPE Atlas は8月18日、`worldwide`以外のエリア選択でプローブ割り当てに問題が生じたと公表し、バックエンドを修正した。しかし、どの測定がその経路を通ったのかは公開記録に残っていない。
ケースファイル
セッションは沈黙する前に理由を残した：BGP停止通知と「閉じる理由」を語る権限
予定時刻に peering が落ちる。隣接側の log には`Cease`だけでなく、change 番号、短い理由、復旧見込みが残った。この一文は誤調査を防げる一方、偽造、盗み見、log 表示の欺瞞、あるいは traffic drain 済みという誤解も生む。RFC 9003が与えるのは、自分の閉鎖を説明する小さな権限であり、相手 network の判断を操作する権限ではない。
ケースファイル
二つの接続が OPEN に達しても、残せるのは一つ：BGP 接続衝突と安定した識別子の権限
両方のルータが同時に発信する。同じアドレス対の間に二つの TCP 接続が完成し、どちらにも正しい BGP OPEN が流れる。輸送は壊れていない。それでも一つの設定済みピアリングに二つの状態機械と二つの履歴を残すことはできない。BGP は到着順ではなく、四オクテットの識別子で一方を捨てる。
インターネット史
書き込みが過去を名乗るまで――HTTP 428 が必要になった理由
形式も権限も正しい要求が、安全な変更に必要な事実を欠くことがある。HTTP 428 は、その書き手がどの状態を見て判断したのかを、作用が始まる前にオリジンが求めるための応答である。
インターネット史
サービスを選ぶ名前：DNS SRVのサーバー選択
かつて domain は一つの address と既定 port を示した。DNS SRV は service の所在を、順位と重みを持つ限定的な候補集合へ変えた。
ケースファイル
送信を続ける隣接者が受信を止めたとき：BGP SendHoldTimer と一方向セッションを終える権限
BGP セッションは Established のまま、交換関係としては壊れ得る。相手からの KEEPALIVE は届き、HoldTimer は更新される。しかし相手の TCP 受信ウィンドウがゼロなら、こちらの経路撤回は一つも出ていかない。緑色の表示は「受信できている」という半分の事実であり、相手が古い経路を保持している危険を隠す。