RIPE NCC · RIR ウォッチ
記事
この RIR に関する BTW の報道と背景解説です。提案ごとの経緯、関係者、立場の変化をたどるには、まず「ポリシー」をご覧ください。
記事
最新記事
332記事
記事
RIPE の member-of が証明するのは集合への認可であり、経路伝播ではない
RIPE Database が更新を受理しても、BGP 広告を観測したことにはならない。証明されるのは、対象オブジェクトが RPSL 集合へ参加するための認可条件を満たしたことだ。集合展開をフィルター生成に使う場面ほど、この境界が重要になる。
記事
RIPE Databaseのmnt-refが認可するのは組織参照であり、企業支配ではない
RIPE Database で受理された`org:`リンクは、意味のある認可確認を通過している。それはデータベース参照の承認を示すが、所有、企業グループへの所属、関連ネットワークの支配を直ちに証明するものではない。
記事
RIPEのIPv6 PI草案では加盟がコンプライアンス事象になる
ルーターも顧客機器も `/56` も、その場から動いていない。それでも保有者の LIR アカウントが有効になった瞬間、同じ構成への適用ルールが変わり得る。RIPE NCC の影響分析が示したのは、ネットワーク変更ではなく資格変更が生む境界だ。
記事
RIPE の assignment-size が示すのは IPv6 集約の粒度であり、稼働中の契約者数ではない
`/46` には理論上 1,024 個の `/56` が入る。RIPE Database の集約オブジェクトに `assignment-size: 56` があれば、この計算自体は正しい。しかし 1,024 をそのまま契約者数にするのは誤りだ。この属性は集約内の End User 割り当ての大きさを記録するもので、全区画の利用、稼働、経路広告、顧客との一対一対応を示さない。
記事
RIPE NCCの光回線は数分で復旧、RIPE Accessの全面復旧には約30分
障害対応では「回線が戻った時刻」と「利用者が再び安全に操作できた時刻」が同じとは限らない。RIPE NCC が5月27日の障害について公表した数分と約30分という二つの時間は、ネットワーク経路と認証サービスを別々の回復対象として測る必要性を示している。
記事
RIPE NCCは7か月で1,799件を確認した 公表目標にはカバレッジ台帳がない
RIPE NCC の月次更新を足し合わせると、2026年1月から7月までに完了した Assisted Registry Check は1,799件になる。年間目標2,400件のほぼ4分の3だ。作業量の進捗としては明快である。しかし、異なる LIR をいくつ確認したのか、再確認は何件か、なぜ開始され、どこまで調べ、修正が再発しなかったかは、この数字だけでは分からない。
記事
RIPE Database の sponsoring-org は管理上のスポンサーを示し、ネットワーク運用者を示さない
「スポンサー」という語からは、所有、資金提供、運用上の指揮を想像しやすい。しかし RIPE Database の `sponsoring-org` は、より限定された意味を持つ。登録機関の契約枠組みのもとで、独立インターネット番号資源のスポンサーとして管理責任を負う組織を示す属性である。
記事
RIPE DatabaseはUnicodeを正規化する。テキストの証拠連鎖には記録が要る
画面では同じ `ř` に見えても、その内側は一つの符号位置とは限らない。RIPE Database 1.123は、分解された入力を NFC へそろえてから、残る UTF-8 処理へ渡す。この選択は相互運用性を強める。同時に、入力・正規形・インターフェース出力を同じ証拠として扱えない理由も生む。
記事
RIPE RPSL aut-num は観測済み BGP ではなく方針を宣言する
import/export は登録済み方針であり、現在の経路測定ではない。
記事
TTLの跳ね上がりはRIPE Atlasの経路に存在しないAS間リンクを描かせる
トレース上では、あるネットワークの次に宛先が現れる。だが実際のパケットは、その間にある複数のルータを通っているかもしれない。RIPE Atlas を使った新しい研究は、経路上の装置がプローブの TTL を大きな値に書き換え、その後の期限切れをすべて回避させる現象を示した。飛び越えたのはパケットではなく、観測記録である。
記事
RIPE NCC RDAP の国コードはネットワークの所在地を示さない
2文字の国コードは地図に置けそうに見える。しかし RIPE NCC の RDAP ネットワークオブジェクトでは登録フィールドであり、ルーター、利用者、通信、サービスの座標ではない。
記事
RIPEのRDAP typeは登録区分であり、経路起点の証明ではない
RIPE の RDAP type は登録区分であり、経路起点の証明ではないの調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。記事の調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
記事
RIPE データベースの更新失敗は「変更なし」ではない
まとめて送った更新が失敗しても、個々のレコードは既に変わっているかもしれない。RIPE NCC の文書が示すのは、再実行の前に確かめるべき処理の境界だ。
記事
RIPE の質問ボード、その出会いを次の仕事につなげるには
研究者と運用者を紹介する仕組みは、どこまで仕事を引き受けるべきか。RIPE NCC が公開した小さな試行の振り返りは、データを集める前に、双方が取り組める問いを定める意味を浮かび上がらせる。
記事
RIPEstat の空の IP 検索は、経路の消失を意味するのか
アドレスでは結果がなく、対応するプレフィックスでは経路が見える。利用者が報告した差は今回の確認では再現しなかったが、検索の途中にある処理を見落とせば、空の応答から強すぎる結論が生まれる。
記事
RIPE の IRR 研究：RPKI が置き換えられるのは経路オブジェクトで、顧客コーンではない
RIPE Labs の新しい研究は、IRR を一括して置き換えるという結論ではない。プレフィックスと起点の根拠と、顧客コーンを見つける関係の根拠を分け、どちらが何を支えているかを問うている。
記事
RIPEはLatencyMONを再構築した。グラフにはなお解釈の受領証が要る。
RIPE NCC は、RIPE Atlas のプローブ間で遅延傾向を比較する LatencyMON を再構築した。新しい画面では測定種別が増え、グループ化の選択肢があり、集約範囲外の結果にも届き、共有時には表示状態を持ち運べる。見やすさは大きく向上する。しかし、それだけでグラフが運用上の結論を完結して証明するわけではない。
記事
RIPE NCC は複数サービスにまたがる脆弱性を修正した。必要なのは修復の連鎖を残す記録だ。
セキュリティの公表で「修正済み」と書かれていても、その語だけでは何が確認されたのかは分からない。RIPE NCC が2026年6月に公表した複数サービスにまたがる脆弱性開示は、その曖昧さを避けている。CSRF の問題について、最初の修正は問題の一部にしか届かず、その後の確認で当初の概念実証がなお実行可能だと分かった。さらに追加の経路が見つかり、作業を重ねて完全な修正に至ったという。
記事
RIPE の RPKI 鍵計画は、まだ ROA の権限範囲を示す受領記録ではない
RIPE NCC が RPKI API 鍵を OpenID Connect ベースへ移す計画は、将来のアクセス方式についての記述である。個々の ROA 変更について、どのリソース権限とどの操作が根拠になったかを公開的に再構成できる記録には、まだなっていない。
記事
RIPE NCCのRISはピアリング方針を見直す。アーカイブには選定の記録が要る
経路データのアーカイブは、ただ保存容量を増やせば公共性を得るわけではない。誰がどの観測を持ち込み、どんな制約の下で残されたかによって、後から読む人が見ている世界の輪郭も決まる。RIPE NCC の RIS に関する2026年第3四半期の計画は、ピアリング方針の更新・明確化を進行中の仕事として挙げた。資源上の制約で延期された仕事であり、関連性と多様性を備えた長期アーカイブを、持続可能なデータ成長の範囲に収めることを目的にしている。