調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
インターネット史
IPv4のフラグメントオフセットが8単位で数えられる理由
IPv4 は、データの位置を1バイト単位でそのまま格納しない。常にゼロになる下位ビットを省き、短いフィールドで大きな範囲を表す。その代わり、分割する側には厳密な境界が求められる。
AFNOG
AfNOGの提案種別欄は形式を示すが、形式別の根拠を定めていない
AfNOG の2007年募集は三つの形式を挙げたが、形式別の情報欄は公開していなかった。
IETF
すべてのセルが停止を告げる：RFC 9906がECC-GOSTのDNSSEC廃止を完結
影響を受ける ECC-GOST の登録簿セルはすべて **MUST NOT** になった。SHA-1 の互換性移行である RFC 9905が検証側の余地を残したのに対し、RFC 9906は生成と検証の両方の経路を閉じ、登録簿での受け入れまで停止点にする。
リーダー
Seyed Pouria Mousavizadeh TehraniとIPv6の最初の応答の前に隠れている状態
到達性を確認できることと、最初の通信が確実に成立することは同じではない。IPv6 のネットワークでは、経路が存在し、送信元ホストがルーターへパケットを渡せる状態でも、戻りのパケットを届けるために必要な近隣キャッシュの情報が、ルーター側にまだ用意されていない場合がある。Seyed Pouria Mousavizadeh Tehrani が扱う GRAND の問題は、この見えにくい準備状態を、初回通信の前にどのように扱うかという問題である。
AFNOG
AfNOGの200語要旨上限は必要な情報を示していない
2007年の AfNOG 募集は要旨を200語以内としたが、必須内容を示さなかった。
インターネット史
IPv4の識別子がすべてのデータグラムを識別しなくなったとき
*ヘッダーにフィールドが残っていても、その意味まで全パケットで保証されるとは限らない。*
IETF
署名は止め、検証は続ける：RFC 9905がSHA-1廃止を非対称にする
RFC 9905の仕組みは、対象となる DNSSEC アルゴリズム行で SHA-1 の新規生成を禁止する一方、検証実装の義務を残すというものだ。運用者は RSASHA1 と RSASHA1-NSEC3-SHA1 による DNSKEY、RRSIG、DS の作成を止めなければならない。しかし、残存する導入基盤を移行する間、再帰検証ソフトウェアはそれらを検証できなければならない。
インターネット史
添付物が種類を名乗り、ローカル機がコマンドを選んだ：RFC 1524
1993年のメール端末で、同じ本文が標準入力になるか、一時ファイルになるかは添付物自身には決められなかった。RFC 1524 は、その分岐をローカルな `mailcap` 規則に置いた。相互運用できる名前と、実行を許す権限を分離するためである。
IETF
四つのセル、一つの信頼連鎖：RFC 9904がDNSSECアルゴリズム方針をレジストリへ移す
RFC 9904は DNSSEC のアルゴリズム番号そのものを変更しない。変わるのは、その番号に結び付く推奨をどこで管理し、どの手続きで更新するかである。一つの DNSSEC アルゴリズム番号には、バリデーター実装、署名者実装、検証での利用、署名での利用という、別々に管理される四つの推奨セルがある。この四分割を単一の「アルゴリズム状態」に戻さないことが、RFC 9904を読む出発点になる。
インターネット史
メッセージは無傷で届いた。それでも読む順序には三人の責任者がいた――RFC 1556
配送完了の印は、文章が正しく読めることまで保証しない。ヘブライ文字と英単語、数字、句読点を含む一行は、同じ文字列のまま二つの画面に届き、異なる並びに見えることがある。RFC 1556 が扱ったのは、輸送後に残るこの責任だった。
インターネット史
TCPが終了マーカーとノーオペレーションの両方を必要とした理由
TCP の可変長オプション領域では、ヘッダーの物理的な終端と、意味のあるオプション列の終端を別々に扱う必要がありました。NOP は、送信側の配置上の都合を支えます。
ケースファイル
URLはトークン機関を示した。発行者を信頼済みにはしなかった
ACME クライアントが Authority Token の取得先を知ることと、サーバーがその署名者を信頼することは別の判断である。JWTClaimConstraints プロファイルの第 05 版は、この区別を出発点に、発行者、厳密なバイト列、期限、アカウント鍵、証明書の役割を別々に立証する流れを示した。
ケースファイル
共有辞書はバイトを減らした。そして秘密境界の内側に入った
圧縮辞書は性能向上用の補助ファイルに見える。しかし RFC 9841 では、その正確な内容が復元結果を左右し、圧縮サイズを介して秘密とも結び付く。管理対象はペイロードだけでは足りない。
記事
LACNICのPAIクライアントはJava 8対応を掲げるが、最新版JARはJava 17を要する
公開 README には「Java 8以上」とある。一方、JitPack から取得できる1.5.1の JAR では、十二個すべての class ファイルが major version 61、すなわち Java 17向けだ。これはサービス障害の証拠ではない。人が読む互換性の説明と、JVM が読む実行条件との間で、版の対応が切れているという証拠である。
インターネット史
リピーターはリセット前に応答した――RFC 1516
応答が届いた瞬間は、処理が終わった瞬間ではない。むしろ Ethernet リピーターが破壊的な自己試験へ入る直前だった。RFC 1516 は、管理要求への返事、装置の動作、完了通知、サービス回復を別々の時刻に置いた。
ケースファイル
パーサーは文字列を受理した。それでもプロトコルは拒否すべきだった
JSON が読めたことと、各フィールドの文字内容を受け入れてよいことは別の判断である。RFC 9839 は、構文の通過証明だけでは埋まらない第二の受け入れ境界を明文化した。
インターネット史
次のプロトコルを選ぶ前に、インターネットは誰がそれと暮らすのかを問うた：RFC 1550
RFC 1550 の冒頭に置かれたのは、パケット形式ではなく電力メーターと無線回線だった。IPv4 の後継候補を比べる前に、将来その影響を引き受ける側の条件を記録しようとしたのである。
ケースファイル
二つのインスタンスは同じ八点だった。ただし物差しが違った
CPU、待ち行列、経路遅延を一つの点数に畳めば、選択装置は軽くなる。しかし同じ値が同じ状態を表すとは限らない。IETF CATS 作業部会の新しい改訂は、比較の前提を運用契約として書き始めた。
ケースファイル
メンバーは削除された。それでも排除には二段階の鍵更新が残った
名簿から一人を消す操作は一瞬で終わる。だが暗号上の所属は、新しい KEK と TEK が配布・導入・有効化され、古い状態が役目を終えた時に初めて変わる。RFC 9838は、この時間差を設計の一部として扱う。
記事
APNICのAPI障害告知はレジストリAPIを名指ししていなかった
`api.APNIC.net` と `registry-api.APNIC.net` の間には、「registry」と一つのハイフンがある。APNIC が8月5日の障害告知で示したのは前者であり、レジストリ更新用に公開している仕様が示すのは後者だ。この差だけで両サービスの独立性は証明できない。しかし、「API」という総称だけでは、障害がどの権限面に及んだのかを特定できないことは証明できる。