RIPE NCC · RIR ウォッチ
記事
この RIR に関する BTW の報道と背景解説です。提案ごとの経緯、関係者、立場の変化をたどるには、まず「ポリシー」をご覧ください。
記事
最新記事
331記事
記事
RIPEのIPv6 PI案は24か月計画を求めるが、その後の判断がない
提案2024-01は、申請者に今後2年間の利用見込みを示させることができる。だが、その期間が終わった時に、どの証拠を見て、誰が、どの程度の対応を決めるのかはまだ書かれていない。
記事
RIPE NCCの仲裁――記録のロックと12週間の起点
仲裁の申立て、手続きの開始、裁定の通知は別の出来事だ。RIPE NCC が説明する記録の保全措置と裁定までの時間軸を分けて読むと、審査への入口があるだけでは、係争中の継続利用や救済の実効性を評価できないことが見えてくる。
記事
RIPEのRDAPは片側でも境界をまたぐ混在ASブロックを「予約済み」と判定する
RIPE の RDAP は片側でも境界をまたぐ混在 AS ブロックを「予約済み」と判定するの調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。記事の調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
記事
RIPEstatは12859:4000を12859:4xxxで説明する――ワイルドカードも証拠である
RIPEstat の Looking Glass は、判読しにくい BGP コミュニティに分かりやすい説明を添えられる。今回保存した応答では、観測値`12859:4000`に「customer routes」という説明が付いた一方、照合元はより広い`12859:4xxx`だった。説明が誤りだという話ではない。値、照合規則、規則の出所を一つの事実に潰してはいけない、という話だ。
記事
RIPE NCCの制裁調査は110件、しかし公開表に「経過時間」がない
2026年第3四半期の報告書は、制裁スクリーニングの滞留量を110件と示した。ところが、その110件が何日前に始まったのかは分からない。新規資源や移転の申請を止め得る手続だからこそ、個人を明かさない時間情報が必要になる。
記事
RIPE WHOISでは無効なAPIキーにも監査上の識別子が残る
認証の失敗は、何者でもない要求として消えるとは限らない。現在の RIPE WHOIS ソースの一経路では、Basic 認証のユーザー名が検証結果より先にセッションへ入り、無効判定の後も key ID として`Invalid APIKEY`と共に監査表現へ残る。拒否された要求を追跡できる利点と、関連付け可能な識別子を誰がどこまで扱うかという統制課題は、同じ設計から生まれている。
記事
RIPEの履歴をプレーンテキストで保存するなら、照会の情報も残す
Whois 1.124では履歴オブジェクトをプレーンテキストで読める。内容は依然としてフィルターを通り、構造化された応答ではリビジョン番号が別に加わる。本文だけの保存では、何を取得したかが分からなくなる。
記事
Sagan の traceroute「成功」は、宛先からの応答を条件にしていない
最後のホップが応答したこと、宛先アドレスが応答したこと、最後に選ばれたホップの RTT は別の判定である。ライブラリが残している違いを、運用報告の一つの「成功」で消してはならない。
記事
RIPE Atlas Toolsの10秒設定が届かないAtlas API経路
6月に加わった HTTP 設定は位置情報の問い合わせに使われる。しかし、調べた測定作成の経路には渡されていない。ネット接続のない検証が示すのは、その境界であって障害の発生ではない。
記事
StarlaのRIPE Atlasバージョン番号は、実行ファイルを特定しない
Rust による別実装は登録時に自身の名前を送る一方、計測結果には参照プローブと互換性のある番号を使う。過去の観測を比較するには、形式を読めることとは別に、その時点で実際に動いていたプログラムと収集条件を確かめる必要がある。
記事
RIPE NCCで四つの安全計画が同時進行する。必要なのは引き継ぎの公開図だ
監査、リスク管理、アプリケーション安全、監視。RIPE NCC の四つの計画には、いずれも「進行中」と記されている。しかし、四つは別々の時計で動き、別々の証拠を生む。脆弱性や統制設定を明かさずに、証拠を誰が渡し、誰が受け入れ、いつ見直すのかを示す小さな引き継ぎ表が要る。
記事
RIPE NCCはIPv6資源を監査できるが、ポリシーから手続きへ進めない
争点は監査権限の有無ではない。RIPE-738 には監査時の証拠義務が二つある一方、開始理由、範囲、期限、結果、異議申立てを定めた手続き文書への一般的な導線がない。
記事
RIPE NCCのASPA署名画面には、BGPで見える上流候補がない
RIPE NCC では AS 番号の保有者が ASPA を作成できる一方、公開ガイドは、RPKI ダッシュボードが BGP 上で見えるプロバイダーを示唆しないと明記している。必要なのは自動回答ではない。観測時刻、視点、根拠、限界を伴う候補を提示し、運用者が関係を判定した記録を署名結果につなぐことである。
記事
RIPEのNRTMv4は送信元判定をレプリカで行う。フォールバックはその先にある
読み取りをプライマリから切り離す判断は妥当だ。ただし新しい送信元を公開する瞬間だけは、配信側レプリカがその名前を認識したという証拠を、後段の通知検索に委ねることはできない。
記事
RIPE Atlasは再接続と生存信号を同じ処理系に載せた。遅いバックエンドが両方を塞いだ
6月8日、RIPE Atlas のソフトウェアプローブは、設置先のインターネットが正常でも、いったん切断すると計測網へ戻れないことがあった。RIPE NCC の障害記録が示す原因は単なる処理不足ではない。再接続時の要求とコントローラーの生存信号が同じイベントプロセッサーを通り、遅い依存先が健康判定の証拠まで遅らせたのである。
記事
RIPE NCCをめぐる古いIPv6グルーは4件から3件へ――ルート修正は一括処理ではない
`.ps`のグルーはネームサーバーの現行アドレスと一致した。一方、`.ne`、`.sd`、`.tj`には差異が残る。同じアドレス変更から生じた4件が別々の結果を迎えたことは、ルートゾーンの実際の作業単位が一つひとつの委任であると示している。
記事
RIPE Atlasファームウェア5130はOpenWrt向けハードウェア構成を加えた。展開を証明するには版番号だけでは足りない
プローブの画面に表示される「5130」は、簡潔だからこそ多くを背負わされる。だがその数字だけでは、どのソースと OpenWrt 環境がどの署名済み成果物を生み、どの世代の機器が受領対象となり、更新後に何を確認したのかは分からない。版番号を測定証拠の境界として使うなら、ビルドから端末までを結ぶ引き渡し記録が要る。
記事
宇宙向けIPv6草案は各惑星に最大五つのRIRプレフィックスを想定するが、「地域」を定義していない
五つの窓口を先に置き、どこへ並ぶかを後回しにした――新しい宇宙向けアドレス草案は、そう読める。既存の地域インターネットレジストリを使う発想には、別の番号制度を一から造らないという強みがある。しかし、所有者、運用者、地上局、打ち上げ国、目的地が異なる地域を指す移動体にとって、「適切な RIR」は自明ではない。
記事
RIPE NCCのAuthDNS台帳は43ノードを数えるが、アクセス網への到達効果は数えていない
RIPE NCC が掲げた目標は、地図上の点を増やすことではない。十分に届いていない地域で、大規模アクセス網、その接続先、そして複数事業者と交われる IXP に AuthDNS を近づけることだ。公開台帳は43の稼働ノードを証明する一方、各ノードがどのリゾルバー群の anycast 経路を変えたかまでは結び付けていない。
記事
RIPEのIPv6 PI案は拡張余地を予約する。部分移転で使えなくなり得る
RIPE で審議中の IPv6 PI 提案は、新規割り当ての外側を次のニブル境界まで空け、将来の拡張を容易にしようとしている。ところが RIPE NCC 自身の影響分析は、割り当て済みブロックを部分移転できれば、その予約が本来守るはずだった拡張に使えなくなる可能性を明記した。