要約

  • IPv6アドレス、BGP経路、通常のpingが正常でも、Fragment、Destination Options、Hop-by-Hop、Routing Headerを持つパケットが同じように通るとは限らない。能力の単位は「IPv6」ではなく、方向・経路・ヘッダー列・時刻を固定した試験である。
  • RFC 7872、APNIC、RIPEの測定は、ヘッダー種別、長さ、サーバー環境、宛先母集団で大きく結果が変わることを示した。歴史的な損失率は警告として有効だが、2026年の世界比率ではない。
  • 実際の許可権は、解析器、ファイアウォール、DDoSサービスを運用するネットワークと、その限界を実装するベンダーにある。反証可能な基準は通常IPv6とのA/B測定であり、代替案は無制限処理の強制ではなく、期限付きの能力契約と診断である。

固定された解析窓と可変長の約束

IPv6の基本ヘッダーは40バイトで、その後ろに0個以上の拡張ヘッダーを置ける。RFC 8200ではNext Headerを順にたどり、最終的にTCPやUDPなどの上位層へ到達する。ポート番号を使うACL、DDoS防御、負荷分散器は、その位置まで解析しなければならない。

仕様上の柔軟性と転送装置の物理条件は一致しない。シリコンには解析段数、固定バッファ、CPUへ送る容量がある。基本ヘッダーだけなら線速、チェーンが深くなればslow path、rate limit、dropという実装は十分に起こり得る。フォーマットは共有されるが、解析予算は装置ごとに調達される。

RFC 7045は、転送ノードが拡張ヘッダーの存在だけを理由に捨てないことを求め、検査するファイアウォールには標準種別を適切に扱う能力を求める。一方で、意図的に設定されたポリシーまで禁止していない。規格が相互運用の期待を示すことと、第三者の設備に処理能力を供給することは別だ。

RFC 7112は、最初のフラグメントに上位層までの完全なヘッダーチェーンを含めるよう要求する。検査可能性は上がるが、装置が任意の深さを読める保証にはならない。RFC 9098が指摘する通り、Path MTU以外にはチェーンの数や上位層ヘッダーの深さに共通上限がなく、ポートを知りたい装置は順番にたどる必要がある。

したがって「IPv6対応」はアドレスファミリーの基礎条件であり、オプション機能の受入試験ではない。この違いは故障時だけでなく、調達時に測るべきである。

過去の数字を現在の市場占有率にしない

2016年のRFC 7872は、World IPv6 LaunchとAlexa Top 1Mから得たWeb、メール、ネームサーバーへ試験パケットを送った。World IPv6 LaunchのWebサーバーでは、8バイトのDestination Optionsが11.88%、8バイトのHop-by-Hopが40.70%、試験したFragment条件が30.51%のdropだった。AlexaのWeb条件は10.91%、39.03%、28.26%。宛先種別で異なり、AlexaのネームサーバーFragment条件は55.23%だった。

これらは通常パケットの到達だけでは説明できない差を示す。しかし、当時のリスト、パケット構成、サーバー役割、経路を含む実験結果である。数字から条件を外せば、精密に見えるだけの誤用になる。

APNICは後に、広告で参加したクライアントへ少数のサーバーからパケットを送る逆向きの測定を行った。2022年の説明では1日約400万回。2023年の追試では、Destination OptionsとHop-by-HopのPadNを8、16、32、64、128バイトとし、Fragmentの初期サイズを1,200から1,416オクテットまで変えた。

2023年のAPNIC記事では、Destination Optionsは64バイト以下で約30%、128バイトで約55%のdrop。2023年4月初めには約90%から55%へ変わったが、原因は特定されなかった。同じAPNIC記事は、2023年4月27日から5月15日まで、University of Aberdeenのサーバーと英国向け広告標本で370,742回のHop-by-Hop試験を行い、全体99.04%のdrop、8バイトで98.25%、128バイトで99.99%を記録したと報告した。

99%という値は強いが、責任主体を1社に決める証拠ではない。アクセスASNごとの差があり、著者自身もLinode、仮想ネットワーク、中継、終端のどこで落ちたかを断定しなかった。むしろ、サーバー配置とオプション長で推論が変わることが、経路単位の測定を必要にする。

RIPE Atlasのpacket-size実験は隣接する基準を与える。参加IPv6プローブの約10%でfragmentation問題を報告する一方、100バイトでも約11%が全損だった。サイズ別に約1,284–1,292プローブで、より広いInternetへの一般化は不明だと明記した。拡張ヘッダー試験でも、同じ宛先・時刻の通常IPv6 controlに成功したものだけを分母にすべきである。

製品資料に現れる実権

Ciscoの拡張ヘッダー資料は、特定の旧プラットフォームについて固定された解析資源を説明し、64バイトのEHチェーンをhardware pathの例にし、上位層フィルターがある場合に資源を超えるチェーンをsoftware pathへ送る挙動を記す。Cisco IOS XR 7.1.1のNCS 5500 ACL資料はline card差を示し、指定EHをhardwareで扱うモデルと、EH付きでLayer 4 matchを使えない条件を分けている。

Juniperにはextension-headers matchとプラットフォーム差があり、あるIDS面ではallow-ipv6-extension-headerを明示しないとEHを含むパケットがblockedになる。Nokiaの資料はipv6-eh maxとlimitedを公開し、対象releaseの一部filter matchでは最大6個を探索する。

これはベンダー優劣表ではない。解析バイト数、認識種別、default、counter、fast/slow pathが製品・release属性である証拠だ。利用者はIPv6を買うと同時に、見えない解析窓も買っている。cloudやDDoSサービスでは、その機種名すら知らないことがある。

セキュリティ側にも正当な費用がある。RFC 8504は、ホストが個々のヘッダー長、数、option数、aggregate chainに上限を置くことを認める。RFC 8883はheader too big、chain too long、too many headers、too many optionsなどのICMPv6 codeを定義する。RFC 9288はtransit filteringの推奨を整理する。

RFC 9673は2024年10月、Hop-by-Hopを実用的にするためRFC 8200を更新し、全routerが全optionを処理する前提を置かない。RFC 9740は2025年、IPFIXに観測EH、個数、chain length、exportが装置上限までかどうかを示すfieldを追加した。RFC 9805はRouter Alertを新規protocol用途ではdeprecatedとした。制度は、無限処理ではなく境界の可視化へ動いている。

反証のための90日

最低でもaccess、transit、cloud/DDoSを各3 family、router silicon、firewall、host stackを各3 family、service familyごとに独立したsource/destination path 100組を測る。条件は通常IPv6、Fragment、Destination Options、Hop-by-Hop、RoutingまたはSRH。

aggregate EHを8、16、32、64、128バイト、適用可能なrecommended orderと別のvalid order、TCP・UDP・QUIC相当UDP、packet size 256・1,200・1,400バイト、1 cell 100回とする。delivery、silent loss、p95 latency、throughput、ICMP、fast/slow path counter、管理下装置のCPUを記録する。

全valid EH cellが通常IPv6のdeliveryから0.1 percentage point以内、100,000回にEH固有silent dropが1回以下、p95 latencyとthroughputが2%以内、CPU増加が5 percentage point未満、128 EH bytesまでslow-path cliffなし、宣言上限を意図的に超えた試験の99.9%以上でRFC 8883 errorが送信元へ戻るなら、傾向を棄却できる。さらにtype、bytes、order、device、policyが通常到達性以上の説明力を持たず、新しいEH利用がtunnel、allowlist、probe、hardware交換なしに増える必要がある。

逆に、validな8-byte EHが管理対象pathの10%以上で5 percentage point超のdelivery gap、64から128バイトで再現可能なcliff、p95 latency 25%増、throughput 20%減、CPU 15 percentage point増、limit dropの半数超でusable ICMPなし、またはdevice・firmware・DDoS・pathだけの変更で結果が変われば傾向は強まる。これは将来の判定値で、現状の世界統計ではない。

番号資源の証明とサービス能力の証明

IPv6 allocationはuniqueな番号とregistry recordを与える。BGP announcementはcontrol-plane visibilityを与える。どちらも、supplier chain全体のoptional packet handlingを保証しない。番号資源保有者は、address quantity、route visibility、通常reachabilityとEH capabilityを別々に調達すべきだ。

providerにはsupported type/option、byte/count limit、fast/slow path、firewall default、RFC 8883 counter、firmware・chassis・cloud edge・policy変更後のexpiryを尋ねる。双方向で試験する。「IPv6 connectivity」だけのSLAは誤りでないかもしれないが、applicationが期待する範囲を含まない。

権力の出所も分ける必要がある。IANAはidentifier、IETFは共通syntaxとprocessing expectation、RIRはnumber resourceのallocationとrecordを担う。transit parserを運用するわけではない。経路上のboxは実効powerを持つが、それだけでglobal mandateを得ない。自設備を守る権限は、影響の開示、比例したpolicy、diagnostic、代替可能性と結びつく。

lock-inは需要不足を自ら作る。applicationは通らないのでEHを避ける。trafficが少ないのでsilicon upgradeが正当化されない。固定siliconが次の利用を阻む。encapsulationやclosed SRv6 domainは回避策だが、tunnelやcontrollerへの依存に置き換わる。紙の上では拡張可能、実運用では例外契約である。