調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
記事
RIPE Atlasは「異質な」プローブ選択を完了した。だが公開APIは選択器を名指ししていない
測定基盤の信頼性は、観測点の数だけでは決まらない。どの候補から、どの規則で、どのプローブが選ばれたのかを第三者が後から確かめられるかどうかでも決まる。RIPE Atlas の2026年第3四半期計画は、プローブ・ファーミングを抑える制約と「異質なプローブ」を選ぶ機能を前四半期に完了した項目としている。一方、今回確認した公開の選択 API 契約は、通常の選択タイプを説明しているものの、その異質性を指定・識別する選択器、手法名、版番号を示していない。この差は機能が存在しないという証拠ではない。運用上の重要な判断が、公開契約から再現できる形で外に出ていない、と…
グローバルのデータセンタートレンド
IEEEの200G多モード光規格案、未確定の上限値が受入条件を結び直す
光リンクの予算を大きな数字だけで比べると、何に配分された予算なのかを見失う。P802.3ds の新資料は、試験方法と数値を同じ版にそろえる必要性を具体的に示している。
IETF
Diameterでタイマーが切れてもサービスが続く理由
RETRY_AND_TERMINATE という名前だけでは、停止までの手順は分からない。確立済みセッションの更新待ちでは、Tx の満了後もサービスを提供する場合がある。問われるのは、その間の利用を誰が引き受け、何をもって待機を終えるかだ。
IETF
K. K. Ramakrishnanと、輻輳回数ではなかったECEの反復
一つの CE マークから、ECE 付き ACK が何個も返ることがある。K. K. Ramakrishnan らが定めた古典的 TCP では、それは通知を失わないための仕組みだ。受信側は送信側の CWR が届くまで ECE を保持する。反復したフラグを一件ずつ輻輳として数えると、状態の継続時間が架空の発生回数へ変わってしまう。
IETF
共通するネームサーバー1台は継続性の印であり、委任支配の証明ではない
キャッシュ済みの委任をリゾルバーが確かめ直す。親側の NS は大半が入れ替わったが、以前と同じ名前が一つだけ残っている。この共通部分は、キャッシュを継続扱いできるかという問いには役立つ。しかし、移行を誰が承認し、古い入口をなぜ残し、いつ消すのかまでは語らない。
インターネット史
20文字でアドレスは短くなった。照合は難しくなった――RFC 1924
アドレスの表記は、単なる容器ではない。人は形を覚え、ログは文字列を索引し、URI は区切りを解釈する。RFC 1924 は IPv6 の全128ビットを20文字に収めた。その可逆な仕掛けは、値が同じであることと、現場で同じ証拠として扱えることの距離を鮮やかに示した。
IETF
Bob Hindenと、空パケットを意味しないペイロード長ゼロ
IPv6 の解析画面に「Payload Length: 0」と表示されると、データが存在しないように見える。しかし Bob Hinden らの標準は、そのゼロを終点ではなく参照先を示す合図として使う。直後に Hop-by-Hop Options ヘッダーがあり、なおバイトが続くなら、受信側は Jumbo Payload オプションを読み、32ビットで記録された本当の長さを確認しなければならない。
記事
APNICのNIR SIGは憲章について4問を示したが、結果は無記名の1組だけだった
APNIC 62に向けて公開された NIR SIG 憲章見直し資料には、性質の異なる4つの設問が並ぶ。ところが結果として示されたのは、支持86%、中立14%、不支持0%という円グラフ1点だけで、どの設問への回答かが書かれていない。複数の意見を EC に届ける役割を担うなら、集約の前に問いと答えの対応を残す必要がある。
IETF
IPv4 のリースを保ったまま、IPv6 の起点を変える
トンネルを動的に設定すれば、IPv4 サービスを置く機器の選択肢は広がる。ただし、その自由は無条件ではない。使える場所、変更の間隔、識別子の扱いを、事業者と利用者の双方が整合させる必要がある。
記事
LACNICはIPv6-onlyの2,100ドル到達を2029年へ延ばした――2020年の告知はなお2026年で終わる
2026年の1,200ドルは、2,100ドルを誤って計算した結果ではない。LACNIC 理事会が割引の縮小を緩やかにする新しい日程を全会一致で決めたからだ。問題は決定そのものではなく、旧告知、後続決議、現行表を一つの履歴としてたどるための継承表示がないことにある。
IETF
DNS GREASEを既定動作にする前に、実験の統治ルールが要る
DNS に、役に立たない値をあえて流す。受信側が未知の値を正しく無視すれば、名前解決は普段どおりに終わる。拒めば、再試行の待ち時間、余分な問い合わせ、あるいは利用者の失敗として表面化する。将来の拡張余地を守るための小さな負荷だが、その負荷を誰の通信に載せるのかは技術だけでは決められない。
IETF
Ralph Dromsと、アドレス所有権ではないDHCPACK
DHCPACK を受け取ると、端末にアドレスが入り、通信が始まる。確定的な瞬間に見えるが、Ralph Droms が記した仕様の効力はもっと限定されている。通常の割り当てでは、サーバーがリースのバインディングを確定し、クライアントは最後に競合を調べてから BOUND へ進む。これは時間の付いた使用許可であって、人の身元証明でも永久所有でもない。
IETF
EVPN の復旧は、重複した端末を直した後も続く
ホスト側のアドレス重複を解消しても、ネットワークが保持した凍結状態まで同時に消えるとは限らない。二つの処理の間に残る時間を、サービスの責任者はどう扱うべきか。
インターネット史
二バイトだけ借りて、元の状態へ戻る――RFC 1922
`SS2`と`SS3`は、別の文字集合を二バイトだけ借りる合図だった。一文字を読み終えれば、解釈はそれ以前の状態へ自動的に戻る。RFC 1922は、この短い借用と行末での ASCII 復帰を組み合わせ、長い中国語メールの状態を小さく、復元可能な範囲に閉じ込めた。
IETF
Scott Roseと、エンドツーエンド証明ではない認証済みデータビット
DNS 応答の`AD`ビットは、検証を行った再帰リゾルバーが対象データを真正と判断した、という有用な結果を伝える。しかし、その一ビットがクライアントまでの経路を自ら保護するわけではなく、すべての検証方針を同一にせず、接続先やアプリケーションの行為も保証しない。Scott Rose が策定に加わった DNSSEC の設計は、信頼を万能化するのではなく、誰のどこまでの判断かを明確にする。
IETF
DNSSECのドライランが試すのは一群のリゾルバーであり、インターネット全体ではない
署名済みゾーンの検証が失敗したのに、通常の利用者には名前解決の答えが返る。DNSSEC のドライランが作ろうとするのは、この意図的な矛盾である。障害をまず観測し、まだ強制しない。ただし、その場にいたことを知らせられるのは仕組みを理解するリゾルバーだけだ。静かな画面の外側は、合格した母集団ではなく未観測の領域である。
IETF
回線の検収で、速さと一緒に何を引き受けたのか
合計の転送速度が目標に届いても、個々の処理時間や負荷時の待ち時間まで決着したとは限らない。TCP の測定結果を業務の判断へ渡すには、試験条件と残された課題の引き受け先が必要になる。
IETF
Nat Sakimuraと、有効な署名でも無視できないクリティカルヘッダー
署名の計算が成功しても、JWS 全体が有効とは限らない。RFC 7515の`crit`は、受信者が理解して処理しなければならない拡張を、保護ヘッダーの中で指定する。真正なバイト列と、共有された意味と、アプリケーションによる受理は、同じ判定ではない。
インターネット史
ネットワーク更新で、最初の参加者を待たせるのは誰か
新旧の機器が共存できても、先行導入の効果がすぐに現れるとは限らない。Quick-Start の歩みをたどると、技術の性能とは別に、協力を待つ時間を誰が引き受けるのかという問題が見えてくる。
インターネット史
二つ目の要求は捨てられ、違反応答は追い越せなかった――RFC 1921
画面への要求が返答待ちでも、同じ Telnet 接続上のプリンターまで必ず止まるわけではない。だが、同じ装置アドレスへ二つ目を送れば話は別だった。TNVIP は後着要求を捨て、その違反応答さえ先着要求の返答より前には出さなかった。RFC 1921が守ろうとしたのは、速さよりも「どの返答がどの要求に属するか」だった。