コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。
ケースファイル
プレフィックスはIPv4、そこへ至る道はIPv6：RFC 8950と異種アドレスファミリー間next hopの権限
説明用の移行シナリオでは、判定は成功だった。BGP session はすべて Established、双方の OPEN に capability 5があり、IPv4 prefix も消えていない。それでも一つの rack から IPv4 顧客へ届かない。経路は存在するが、IPv6 next hop が誤った table で再帰解決されていた。合意された文法が、転送の成功として扱われたのである。
IETF
Jeff Tantsura と、まだ結果ではなかったインテント
画面の表示は緑のままだ。保護経路を維持するというインテントは受理され、必要な変更も一度は適用された。ところが、その後のトポロジー変更で代替経路が失われている。残っているのは望んだ状態の記録であり、現在の通信が得ている結果ではない。Jeff Tantsura が共著した RFC 9315 は、このずれを見分けるための重要な線を引いている。
ケースファイル
次の鍵は通知されたが、届けられてはいなかった：TCP-AOと鍵エポックの権威
説明用の鍵切替シナリオでは、午前2時7分、監視画面が緑になった。双方の BGP ルーターに鍵42が表示され、packet capture にも`RNextKeyID=42`が見える。運用者は切替完了と判断し、鍵17を削除した。数秒後、TCP 再送が増え、BGP は Established を離れた。相手に届いたのは番号であって、新しい鍵を使えるという共同事実ではなかった。
インターネット史
安定化が復旧を遅らせたとき――ルートフラップ・ダンピングの選択
IP プレフィックスを正しく保有し、障害を直し、BGP で再広告しても、それだけでは世界中のルーターが直ちに経路を採用するとは限らない。1990年代の限られた処理能力を守ったルートフラップ・ダンピング（RFD）の歴史は、番号資源の記録と実際の到達性が別の権力によって動くことを示している。
ケースファイル
距離の余白を使い切ったパケット：BGP GTSMが近接性に与える権限
説明用のシナリオでは、午前2時の経路切り替え後、ping は通るのに BGP だけが戻らなかった。送信側は引き続き TTL 255で TCP セグメントを出している。ところが復路にルータが一台増え、受信値は253から252へ下がった。受信側の GTSM は253以上しか認めない。障害の原因は鍵でも経路ポリシーでもなく、「この近さなら通す」という約束と現実の距離の不一致だった。
ケースファイル
フィルターはセッションを越えたが、境界は越えなかった――BGP ORFと「少なく求める」権限
顧客は受信 prefix-list をフルルートから数百経路へ変更した。自分の RIB はすぐ小さくなった。しかし上流は、依然として全経路を計算し、queue に入れ、送信し、最後に顧客が捨てているかもしれない。Outbound Route Filtering は「不要」という希望を sender 側へ運び、無駄を手前で止める。その希望は、sender の export 境界の所有権まで運ばない。
IETF
Linda Dunbarと、隣接先を作り出してはならないディレクトリ
「該当なし」は、常に同じ意味ではない。情報が不完全なディレクトリなら、まだ知らないだけかもしれない。対象範囲を完全に把握しているなら、存在しないという判断に近づく。Linda Dunbar が共同執筆した四つの TRILL RFC は、この差が単なるデータ品質ではなく、フレームを探索するか捨てるかを分ける運用上の権限であることを示している。
ケースファイル
セッションは Established、経路はゼロ――RFC 8212が問い直す「明示的な許可」の権限
更改直後の境界ルーターで、BGP セッションは `Established` と表示されている。KEEPALIVE は続き、障害アラームもない。しかし IPv4 の経路は一つも採用されず、相手にも何も広告されない。通信路は成立しているが、経路を運ぶ権限は成立していない。RFC 8212 は、この一見矛盾した状態を障害ではなく、安全側に倒れた正常な初期条件として定義する。
ケースファイル
セッションは沈黙する前に理由を残した：BGP停止通知と「閉じる理由」を語る権限
予定時刻に peering が落ちる。隣接側の log には`Cease`だけでなく、change 番号、短い理由、復旧見込みが残った。この一文は誤調査を防げる一方、偽造、盗み見、log 表示の欺瞞、あるいは traffic drain 済みという誤解も生む。RFC 9003が与えるのは、自分の閉鎖を説明する小さな権限であり、相手 network の判断を操作する権限ではない。
ケースファイル
二つの接続が OPEN に達しても、残せるのは一つ：BGP 接続衝突と安定した識別子の権限
両方のルータが同時に発信する。同じアドレス対の間に二つの TCP 接続が完成し、どちらにも正しい BGP OPEN が流れる。輸送は壊れていない。それでも一つの設定済みピアリングに二つの状態機械と二つの履歴を残すことはできない。BGP は到着順ではなく、四オクテットの識別子で一方を捨てる。
ケースファイル
送信を続ける隣接者が受信を止めたとき：BGP SendHoldTimer と一方向セッションを終える権限
BGP セッションは Established のまま、交換関係としては壊れ得る。相手からの KEEPALIVE は届き、HoldTimer は更新される。しかし相手の TCP 受信ウィンドウがゼロなら、こちらの経路撤回は一つも出ていかない。緑色の表示は「受信できている」という半分の事実であり、相手が古い経路を保持している危険を隠す。
ケースファイル
パケットを消すために受理された経路：BGP BLACKHOLEと到達性を破壊する権限
宛先型ブラックホールでは、経路が選ばれた結果として通信が届かなくなる。DDoS で共有回線を守るための合理的な犠牲になり得る一方、誤った一つの/32を正常なサービス停止へ変える力でもある。重要なのは`65535:666`という記号ではなく、誰が、どの宛先について、どの境界まで、いつまで廃棄を許可したかである。
ケースファイル
このセッションは運べたが、次は運べなかった：BGP Extended Messagesと共有サイズ予算の権限
12 KB の UPDATE を受理して route を選んでも、次の peer が4,096 octets のままなら完全な広告は止まる。Malformed でも policy reject でもない。受信容量は一つの session の約束であり、reachability は全 hop の合成だからだ。
IETF
Hannes Gredler と双方向にドレインすべき OSPF リンク
片側のコストを最大にして経路が迂回し始めても、回線が空になったとは限らない。隣接ルーターは逆方向の状態を自ら広告しているため、そちらからのトラフィックは残り得る。Hannes Gredler が共著者となった RFC 8379 は、この非対称性を保守手順の中心に据えた。必要なのは単なる高コスト化ではなく、対象リンクの特定、対向側の応答、そして双方向の実測である。
ケースファイル
監視装置が見たのは経路であり、パケットではない：BGP BMPと制御プレーン証人の権限
監視データが正確でも、結論が正しいとは限らない。BMP は policy 前、policy 後、選択後、送信前後の経路を見せるが、それぞれ別の証言である。運用者が最初に示すべきものは、どの証人がどの範囲について語っているかだ。
ケースファイル
メトリックがAS境界を越えるとき：BGP AIGPと「一つの内部コスト」を定義する権限
数字を足せることと、意味を足せることは同じではない。AIGP は、同一事業者が運用する複数 AS にまたがって IGP に似たコストを累積できる。だが、その合計を経路判断に使う正当性は、各項が同じ量を表し、境界と変更権限が検証できる場合に限られる。
ケースファイル
障害前に選ばれていた予備経路：BGP PICと事前計算された転送を認可する権限
バックボーンのリンクが落ちた瞬間、最初に救われるパケットは、BGP が何十万もの宛先を再評価するのを待たない。BGP Prefix Independent Convergence では、事故より前に FIB へ置かれた経路へ流れる。速さの源は、先に済ませた判断である。危険も同じ場所にある。
ケースファイル
Route reflectorは間違った都市から選んだ：BGP ORRと他のrouterの最適出口を計算する権限
中央の route reflector は、client traffic が一度も通らない場所から path を決めることがある。BGP Optimal Route Reflection は client の logical position から計算させる。失われた視点を戻す一方で、どの topology、policy、candidate を別 router の視界とみなすかを中央に委任する。
ケースファイル
ルートリフレクターが選択肢を隠した：BGP ADD-PATHと代替経路を見せる権限
route reflector は、自ら選んだ経路を client へ配ることで iBGP の規模を抑える。減るのは session だけではなく情報でもある。ADD-PATH は同じ prefix の複数経路を共存させるが、どの候補を見せるか、どれだけの state を許すか、何が実際に packet を運ぶかまでは決めない。
IETF
John Scudder と、能力を先に名乗る BGP セッション
TCP がつながっただけでは、二台のルーターが同じ BGP を話せるとは限らない。新しい拡張を片方だけが実装している場合も、両方が実装していても今回の OPEN では片方しか表明しない場合もある。John Scudder の名が残る標準文書は、この曖昧さを小さな相互記録へ変えた。未知の能力は無視して共存し、目的に不可欠な能力が欠けるときだけ、理由を示して止まる。拡張性とは、何でも受け入れることではなく、同意した範囲と終点を見える形にすることである。