IPv6 の /64 を普遍化しない – 現行仕様の整理と固定境界への異議

IPv6 の設計では、/64、/48、/56、/127、/128 といったプレフィックス長が頻繁に登場します。

一般的な解説では、通常の IPv6 LAN、組織への委譲、家庭への委譲、ルーター間リンク、ループバックなどが、いくつかの代表的なプレフィックス長と結び付けて説明されることがあります。

これらは実際によく使われる値ですが、すべてが同じ理由から選ばれているわけではありません。ホスト収容 LAN の固定境界は、現在の IPv6 アドレスアーキテクチャと Ethernet 上の SLAAC に関係します。サイトへの委譲サイズは割り当て方針です。ルーター間ポイントツーポイントリンクには、そのリンクに固有の技術的理由があります。

これらを区別せず、すべてを「IPv6 ではそう決まっている」と理解すると、限定された機能や用途に由来する条件が、IPv6 全体の普遍的な規則として扱われてしまいます。

この記事の中心は、固定割り当てと動的割り当てを同じ設計対象として扱わないことです。SLAAC を使うなら、SLAAC とリンク種別の仕様に従えばよいです。DHCPv6 を使うなら、その実装と運用要件に従えばよいです。一方、固定割り当て前提のネットワークであれば、必要な収容数、探索耐性、Neighbor Discovery の負荷、経路集約、運用上の見通しから、自由な Prefix を設計要件として選べるべきです（たとえば /120 や /104 などでもよい）。

この記事では、まず現行仕様における各プレフィックス長の位置付けを整理します。そのうえで後半では、筆者の設計上の主張として、64 ビットのインターフェース ID や SLAAC に由来する固定境界を、固定割り当てを含む IPv6 のホストサブネット全体へ一律に適用すべきではないと論じます。

現行仕様の説明と、現行仕様に対する評価は分けて考える必要があります。

現行仕様と筆者の主張

最初に、現行仕様と現在の実務、そして筆者の主張を分けておきます。

観点	現行仕様と現在の実務	筆者の主張
IPv6 ルーティング	/0 から /128 までの任意長を扱う	現在のクラスレスなモデルを維持する
一般的なユニキャストアドレス	原則として 64 ビットの IID を持つ	IID 長を普遍的な固定値にしない
Ethernet 上の SLAAC	現行仕様では 64 ビット境界が必要	その要求を、動的割り当て機能の適用範囲に限定する
固定アドレス割り当て	SLAAC の条件は受けないが、現行アドレス仕様との不一致は残る	動的割り当てと分離し、特定の固定値ではなく自由な Prefix を設計要件から選べるようにする
現在の実環境	動的割り当てや相互運用性を考慮して保守的に設計する	将来の仕様では固定境界を IPv6 全体の普遍的な規則にしない

この記事は、現在の実環境で無条件に非 /64 を採用するよう勧めるものではありません。現在の仕様、OS、ルーター、ネットワーク機器との相互運用性を考えれば、SLAAC を使う一般的なホスト収容 LAN を保守的に構成するのは安全側の判断です。

しかし、その実務上の判断と、固定境界をアーキテクチャ上の普遍規則にすることが妥当かどうかは別の問題です。特に固定割り当てでは、アドレス生成の都合ではなく、設計要件からプレフィックス長を決められるべきです。この記事の主張は、結局その固定境界へ戻れという話ではありません。動的割り当ては仕様に従い、固定割り当ては固定割り当ての要件で設計できるべきだという話です。

IPv6 のルーティングはクラスレスである

IPv6 のルーティングとフォワーディングでは、/0 から /128 までのプレフィックス長を扱えます。RFC 7608 は、IPv6 のプレフィックス長も CIDR に従うパラメーターであり、ルーターやソフトウェアは特定のプレフィックス長だけを前提にせず、任意長のプレフィックスを最長一致で処理すべきだとしています。

インターネット全体を示す /0、ISP や組織の集約経路、サイトに委譲された /48 や /56、LAN に割り当てられたサブネット、ルーター間リンクの /127、特定アドレスへの /128 は、いずれも IPv6 の経路として扱えます。

したがって、IPv6 のルーティングそのものにホスト収容 LAN 向けの固定境界はありません。その境界は IPv6 経路の構造から導かれたものではなく、主に IPv6 アドレス内部の構造とアドレス設定方式に由来します。

64 ビット IID はアドレスアーキテクチャ側の境界である

RFC 4291 は、IPv6 ユニキャストアドレスを、サブネットプレフィックスとインターフェース ID に分ける構造を定義しています。この表現だけを見ると、境界の長さは任意であるように見えます。

領域	長さ	意味
サブネットプレフィックス	n ビット	ネットワーク側の識別子
インターフェース ID	128 – n ビット	インターフェース側の識別子

しかし、RFC 4291 は、先頭ビットが 000 ではないユニキャストアドレスについて、インターフェース ID を 64 ビットとするよう規定しています。一般的なグローバルユニキャストアドレスはこの条件に該当するため、通常は 64 ビットのサブネット側と 64 ビットの IID に分かれます。

したがって、現在の一般的な IPv6 アドレスにおける 64 ビット境界は、単なる運用上の慣行ではありません。RFC 4291 が定める 64 ビット IID から導かれる、アドレス構造上の境界です。

RFC 7136 が変更したものと、変更しなかったもの

IPv6 の IID は、当初、Modified EUI-64 形式と強く結び付けられていました。しかし、実際には MAC アドレスに由来しない IID 生成方式が広く使われるようになり、IID 内部の各ビットを第三者が意味のある構造として解釈することは妥当ではなくなりました。

RFC 7136 は、IID 全体を原則として不透明なビット列として扱うよう整理し、RFC 4291 の記述を更新しました。これにより、IID が必ず Modified EUI-64 形式でなければならないという条件は緩和されました。

ただし、RFC 7136 は IID の長さを可変にしたわけではありません。RFC 7136 による更新後も、一般的なユニキャストアドレスの IID は 64 ビットであるという条件は残っています。変更されたのは、主に 64 ビットの内部をどのような意味や生成方式で扱うかという点です。

論点	RFC 7136 の整理
IID 内部のビットに普遍的な意味を持たせるか	不透明なビット列として扱う方向へ整理した
IID の長さを 64 ビットに固定するか	64 ビット IID という条件は維持した

SLAAC 自体は IID 長を固定定数として設計していない

SLAAC では、Router Advertisement で通知されたプレフィックスと、リンクに対応する IID を組み合わせて 128 ビットの IPv6 アドレスを生成します。概念的には、プレフィックス長と IID 長の合計が 128 ビットになる関係です。

RFC 4862 §5.5.3(d) は、プレフィックス長と IID 長の合計が 128 ビットにならなければ、その Prefix Information Option を SLAAC によるアドレス生成には使用しないよう定めています。同時に、IID 長はリンク種別ごとの文書で定義され、IPv6 アドレスアーキテクチャと整合していなければならないとしています。

ここで重要なのは、RFC 4862 §5.5.3(d) が、将来のアドレスアーキテクチャとリンク種別仕様が双方とも改訂されれば、現在とは異なる IID 長を許容し得ると明記していることです。さらに、実装は特定の IID 長を固定定数として仮定せず、異なる長さを扱える構造にすべきだとしています。

つまり、SLAAC の処理モデル自体は、プレフィックスは必ず 64 ビット、IID は必ず 64 ビット、と普遍的にハードコードする設計ではありません。正確には、リンク種別とアドレスアーキテクチャが定める IID 長に応じて、残りのビットをプレフィックスとして使用する構造です。

現在の一般的な Ethernet では IID 長が 64 ビットであるため、結果としてホスト収容 LAN の境界が決まります。したがって、SLAAC というプロトコルそのものが将来にわたって 64 ビット IID を固定している、という理解は正確ではありません。

Ethernet 上の SLAAC では現在 64 ビット境界が必要である

RFC 4862 が IID 長を固定値として定義していないからといって、現在の Ethernet 上で任意長の SLAAC が標準化されているわけではありません。Ethernet については RFC 2464 が、SLAAC に使用する IPv6 プレフィックスを 64 ビットとするよう規定しています。

仕様	役割
RFC 4291 / RFC 7136	一般的なユニキャストアドレスの IID は 64 ビット
RFC 4862	プレフィックスと IID を組み合わせて 128 ビットのアドレスを生成する
RFC 2464	Ethernet 上の SLAAC 用プレフィックスは 64 ビット

したがって、Ethernet 上で SLAAC を使用する LAN には 64 ビット境界を前提にしたプレフィックスを割り当てる、という説明は現在の仕様として正確です。一方で、SLAAC という仕組みそのものが、あらゆるリンクと将来の IPv6 仕様を同じ固定境界へ閉じ込めている、という説明は正確ではありません。

固定割り当てでは Prefix を設計要件から決める

アドレスを手動で固定設定する場合、SLAAC によるアドレス生成処理は使用しません。端末が RA で受け取ったプレフィックスと IID を組み合わせてアドレスを作るわけではないため、動的割り当てのために定義されたプレフィックス長の条件を、そのまま固定割り当てへ持ち込む必要はありません。

固定割り当てで見るべきなのは、管理対象の数、台帳や命名のしやすさ、障害時の追跡性、Neighbor Discovery の負荷、未使用アドレスへの探索面、経路集約、将来の拡張余地です。管理対象が明確な小規模セグメント、閉じた管理ネットワーク、機器間接続、仮想 IP アドレス群、サービス用アドレス群では、膨大な IID 空間を on-link に見せること自体が設計上の必然ではありません。

たとえば、管理対象が限られたセグメントでは、台帳管理、障害解析、未使用アドレスへの探索耐性を考えると、自由な Prefix を選んだ方が説明しやすい場合があります（たとえば /120 や /104 などでもよい）。反対に、将来の拡張や集約を優先して、より広い Prefix を選ぶ判断もあり得ます。固定割り当ての Prefix は、あらかじめ決められた境界へ合わせるものではなく、アドレス設定方式と運用要件から導くものです。

もちろん、これは現行 RFC の読み方として、自由な Prefix のホストサブネットが何の制約もなく標準化されている、という意味ではありません。RFC 4291 と RFC 7136 が一般的なユニキャストアドレスに 64 ビット IID を要求しているため、64 ビット境界より長い通常のホストサブネットは、/127 などの標準化された例外を除き、現在の IPv6 アドレス仕様の範囲外です。RFC 7421 も、64 ビットより短い IID、つまり 64 ビット境界より長いサブネットプレフィックスの使用は、標準化された例外を除いて現行仕様の範囲外であり、結果は実装によって異なり得ると整理しています。

だからこそ、ここで問題にしているのは現行仕様の説明ではなく、仕様としてどうあるべきかです。固定割り当てで SLAAC を使わない場合まで、SLAAC と 64 ビット IID に由来する境界へ従わせる必要があるのか。筆者の答えは、必要ない、です。

観点	固定割り当てで見るべきこと
アドレス設定方式	SLAAC を使わないなら、動的割り当てのプレフィックス長条件を設計理由にしない
ルーティング	任意長の経路を扱える
アドレス管理	収容数、台帳、命名、障害解析に合う範囲を選ぶ
Neighbor Discovery	不要に広い on-link 空間を見せない設計を選べる
標準上の位置付け	現行仕様では曖昧さが残るため、将来仕様で明確化すべき

固定設定なら SLAAC とは関係がない、という説明は正しいです。さらに踏み込めば、固定設定ならプレフィックス長も固定割り当ての要件から決められるべきです。この点を曖昧にしたまま「実務上は固定境界が無難」で終えると、結局、動的割り当ての都合を固定割り当てにまで普遍化することになります。

固定 64 ビット境界には利点もある

固定された 64 ビット IID 境界には、設計上の利点もあります。RFC 7421 は、固定境界によって、LAN ごとのサブネットサイズ計算が不要になり、ネットワーク設計や運用を均質化できること、十分に大きな IID 空間を確保できることなどを挙げています。

同 RFC は、固定境界を変更する場合の互換性や既存実装への影響も分析し、少なくとも文書作成時点では、64 ビット境界を維持する利点が変更理由を上回るというコミュニティの見解を記録しています。

したがって、この記事の主張は、64 ビット境界には何の合理性もないというものではありません。その境界の利点を認めたうえで、その境界を必要としない用途にまで普遍的に適用すべきかを問い直すものです。

サイトへの委譲サイズをホスト境界と混同しない

/48、/56、/60 は、IID の 64 ビット境界とは異なる種類の数字です。これらは主に、ISP などがエンドサイトへどれだけの IPv6 アドレス空間を委譲するかを表します。

委譲プレフィックス	構成できるホストサブネット数
/48	65,536
/52	4,096
/56	256
/60	16

RFC 6177 は、すべてのサイトに一律の /48 を割り当てるという過去の推奨を見直し、実際の割り当てサイズはサイトの現在および将来の利用、必要なサブネット数、運用ポリシーから決めるべきだとしています。

ただし、RFC 6177 が直接扱っているのは、エンドサイトへのアドレス割り当てサイズです。64 ビット IID の是非を直接論じた文書ではありません。RFC 6177 を、固定 64 ビット IID を否定する直接的な根拠として使うべきではありません。

/127 にはポイントツーポイントリンク固有の理由がある

2 台のルーターだけを接続するポイントツーポイントリンクでは、RFC 6164 に基づいて /127 を使用できます。/127 を使う理由は、単にアドレスを節約するためではありません。主な理由は、Ping-Pong 問題と Neighbor Cache Exhaustion の回避です。

Neighbor Discovery を使用しないポイントツーポイントリンクに /127 より短いプレフィックスを設定すると、どちらのルーターにも割り当てられていない on-link アドレスが残ります。その未使用アドレス宛てのパケットを一方のルーターが相手へ転送し、相手も同じ判断で送り返すと、パケットが 2 台のルーター間を往復する可能性があります。

また、Ethernet のルーター間リンクに広大なホストサブネットを設定すると、膨大な数の未使用アドレスが on-link に存在するように見えます。未使用アドレスへ大量のパケットが送信されると、ルーターは Neighbor Cache エントリを作成し、Neighbor Solicitation を送信し、再送タイマーを管理します。これにより、CPU、メモリー、Neighbor Cache などのリソースが消費されます。

/127 を使えば未使用の on-link アドレスをなくせるため、この攻撃面を縮小できます。RFC 6164 は、/127 を使用する場合、そのプレフィックスについて Subnet-Router anycast を無効化することも要求しています。ここでも、/127 は固定クラスではなく、特定のリンクに存在する問題を解決するためのプレフィックス長です。

/128 は単一アドレスを表す

/128 は、IPv6 アドレスの 128 ビットすべてが固定されていることを示します。主な用途は、ループバック、ホストルート、仮想 IP アドレス、サービスアドレス、トンネル終端、経路制御上の識別子などです。

これは一般的な LAN のサブネットサイズではなく、特定の 1 アドレスを表すプレフィックス長です。RFC 4291 も、IPv6 のループバックアドレスを ::1 として定義しています。

局所的な制約を全体規則へ拡張すべきではない

ここからは、64 ビット IID 境界に対する筆者の評価です。Ethernet 上の SLAAC が固定境界を必要とすることには、明確な仕様上の根拠があります。しかし、そのことから、SLAAC を使わないネットワークを含め、すべての IPv6 ホストサブネットが同じ固定境界に従わなければならない、という結論が自動的に導かれるわけではありません。

前者は、現在の 64 ビット IID を使ったアドレス自動生成を成立させるための条件です。後者は、アドレス設定方式に関係なく、IPv6 のインターフェースアドレス全体を固定境界へ従わせるアーキテクチャ上の規則です。

現行の RFC 4291 と RFC 7136 が 64 ビット IID を基本としていることは事実です。しかし、RFC 4862 §5.5.3(d) は、将来のアドレスアーキテクチャとリンク種別仕様の変更によって、異なる IID 長が使われる可能性を明示的に認めています。また、実装が 64 ビットという固定定数を前提にすべきではないともしています。

これは、64 ビット IID が IPv6 や SLAAC から不可避に導かれる自然法則ではないことを示しています。現在の仕様によって選択されている値であり、関連仕様を整合的に変更すれば、異なる値を採用できる余地が当初から残されています。

対象	判断の軸
現在の 64 ビット IID を使う SLAAC	その IID 長に対応するプレフィックス長を要求する
/127 が必要なルーター間リンク	/127 を使う
単一アドレス	/128 を使う
サイトへの委譲サイズ	必要なサブネット数から決める
経路集約	CIDR とネットワーク階層から決める

SLAAC の都合で必要になった境界を、その機能を使用しない固定割り当てネットワークへも一律に適用するのは、制約の適用範囲を広げすぎています。

クラスレスなルーティングと固定境界の不整合

IPv6 のルーティングでは、プレフィックス長は任意です。一方、一般的なインターフェースアドレスでは、上位 64 ビットをサブネット側、下位 64 ビットを IID 側とする境界が固定されています。

その結果、IPv6 には、経路と集約はクラスレスである一方、一般的なホストアドレスの内部構造は 64 ビット境界へ固定される、という二つの性質が同居しています。

これは IPv4 のクラス A、クラス B、クラス C と同じ仕組みではありません。それでも、用途やアドレス設定方式にかかわらず、特定のビット位置をサブネット境界として固定する発想には、クラスフル設計に近い不自然さがあります。

固定境界を使用すること自体が問題なのではありません。その境界を必要とする機能が存在することも問題ではありません。問題は、その機能に必要な条件を、IPv6 のインターフェースアドレス全体へ普遍的に適用していることです。

固定割り当てと動的割り当てを分ける

動的割り当てでは、SLAAC、DHCPv6、リンク種別、OS 実装の条件に従う必要があります。端末が自律的にアドレスを生成し、複数の実装が相互接続する以上、そこには互換性のための制約があります。

一方、固定割り当てでは、同じ制約をそのまま持ち込む必要はありません。管理者がアドレスを決め、台帳で管理し、経路やフィルタリングと対応付けるのであれば、Prefix は設計上の変数です。特定の代表値へ寄せるのではなく、用途、規模、運用、実装能力から決めるべきです。

仕様と実装の曖昧さを減らす

現在の自由な Prefix には、OS やルーターが設定を受け付ける場合がある、実際に通信できる場合がある、ルーティングも可能である、SLAAC は利用できない、現行のアドレス仕様の範囲外である、機器や OS によって挙動が異なる、という曖昧さがあります。

この状態では、利用者が固定境界をどの程度の強さの規則として扱うべきか判断しにくくなります。解決策は、自由な Prefix を全面禁止するか、無条件に解禁するかという二択ではありません。

方向性	意味
現行仕様を厳格に維持する	通常のホストサブネットでは固定境界だけを認め、それ以外の設定を実装が拒否する
警告付きで許可する	固定境界以外の設定時に、SLAAC や相互運用性に関する警告を表示する
実装能力を宣言する	固定割り当て、DHCPv6、SLAAC ごとに対応できるプレフィックス長を明示する
可変長 IID を段階的に標準化する	SLAAC を含め、IID 長をインターフェースごとのパラメーターとして扱う

筆者が提案したいのは、自由な Prefix を無条件に解禁することではありません。動的割り当てでは SLAAC、DHCPv6、リンク種別、OS 実装の条件に従えばよいです。一方、固定割り当てでは特定の代表値に縛られず、設計要件から自由にプレフィックス長を選べるべきです。固定境界を必要とする機能と、必要としない機能を分離し、実装が対応範囲を明確に示せる構造へ変えることです。

個人 Internet-Draft「IPv6 is Classless」

固定 64 ビット境界を見直す問題意識は、個人 Internet-Draft「IPv6 is Classless」でも示されています。2026 年 7 月 27 日時点で IETF Datatracker に掲載されている最新版は、2026 年 3 月 31 日付の draft-bourbaki-6man-classless-ipv6-14 です。

ただし、これはワーキンググループ採択文書でも IETF の合意文書でもなく、作業中の個人 Internet-Draft です。RFC と同じ重みの資料として扱うことはできません。

この Draft が提案しているのは、単純に「今すぐ固定境界をやめる」ということではありません。Draft は RFC 4862 §5.5.3(d) を引用し、IID 長は本来パラメーターであり、実装が 64 ビットという固定値を前提にすべきではないと論じています。

一方、実務上の推奨はかなり保守的です。Recommendations 節は、他に強い理由がなければ、リンクには従来どおりの固定境界を推奨しています。SLAAC についても、実装内に 64 ビットがハードコードされていることによる不具合を避け、端末や OS の移植性を確保するため、現時点では 64 ビット IID を使うことを推奨しています。

そのうえで長期的には、IID 長を固定定数ではなくインターフェースごとのパラメーターとして扱い、必要に応じて 64 ビット境界より長いプレフィックスを利用できるようにすることを提案しています。この立場は、現在の実環境で従来の境界を使うことと、その境界を将来にわたって普遍的な固定境界にすることを区別しています。

現在の実務ではどうするべきか

現行仕様と現在の機器間相互運用性を前提にするなら、次の判断が妥当です。

設計対象	現在の一般的な選択	理由
SLAAC を使う Ethernet LAN	64 ビット IID に対応する境界	RFC 4291、RFC 7136、RFC 4862、RFC 2464 との整合
固定割り当ての管理セグメント	自由な Prefix を設計要件から選べるべき（たとえば /120 や /104 などでもよい）	収容数、ND 負荷、探索耐性、運用単位から決める
自由な Prefix を使う検証環境	個別に判断	実装依存であり、現行仕様の範囲外
エンドサイトへの委譲	/48、/56、/60 など	必要なサブネット数と割り当て方針
ルーター間ポイントツーポイント	/127	RFC 6164 が対象とする問題の回避
ループバック、ホストルート	/128	単一アドレスの表現
経路集約	任意長	CIDR とネットワーク階層

現在、SLAAC を使う一般的な LAN を従来の境界にする判断は妥当です。しかし、その理由は、IPv6 が本質的にその境界を持つからではありません。現行のアドレスアーキテクチャ、SLAAC、機器実装、相互運用性が 64 ビット境界を前提としているためです。固定割り当てのネットワークまで同じ結論に閉じ込める必要はありません。

参考情報

• RFC 7608: IPv6 Prefix Length Recommendation for Forwarding
• RFC 4291: IP Version 6 Addressing Architecture
• RFC 7136: Significance of IPv6 Interface Identifiers
• RFC 4862: IPv6 Stateless Address Autoconfiguration
• RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
• RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing
• RFC 6177: IPv6 Address Assignment to End Sites
• RFC 6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links
• IETF Datatracker: draft-bourbaki-6man-classless-ipv6

関連する記事

まとめ

IPv6 で頻繁に使われるプレフィックス長には、それぞれ異なる由来があります。ホスト収容 LAN の固定境界は一般的な 64 ビット IID と Ethernet SLAAC、/48、/56、/60 はエンドサイトへの委譲サイズ、/127 はルーター間ポイントツーポイントリンク、/128 は単一の IPv6 アドレスを表します。これらを同じ種類の固定境界として扱うべきではありません。

固定割り当てでは、SLAAC のアドレス生成条件は適用されません。それでも自由な Prefix が現行仕様との不一致を持つのは、SLAAC ではなく、RFC 4291 と RFC 7136 が一般的なユニキャストアドレスに 64 ビット IID を要求しているためです。

一方、RFC 4862 §5.5.3(d) は、将来のアドレスアーキテクチャとリンク種別仕様の改訂によって、異なる IID 長を使用できる可能性を明示しています。また、実装は 64 ビットという特定の定数を仮定すべきではないとしています。この点は重要です。

64 ビット IID は、SLAAC から不可避に導かれる自然法則ではありません。現在のアドレスアーキテクチャとリンク種別仕様によって選択されている値です。

筆者は、この 64 ビット境界を IPv6 のインターフェースアドレス全体へ普遍的に適用する設計には疑問があります。固定境界を必要とする機能にはその境界を要求し、その機能を使わない固定割り当てネットワークでは、特定の代表値ではなく自由な Prefix を要件と実装能力に基づいて選べるようにする。非標準構成を認める場合は、警告、明示的な有効化、対応能力の宣言などによって曖昧さを減らす。さらに将来は、可変長 IID や可変長 SLAAC を段階的に標準化する。

SLAAC を使う場面では、その仕様が要求する境界を使う。固定割り当てでは特定の固定値ではなく、設計要件から自由な Prefix を決める。実装内部では 64 ビットを変更不能な定数として扱わない。この三つは両立します。制約は、その制約を必要とする範囲だけに適用すべきです。64 ビット IID や Ethernet 上の SLAAC に由来する固定境界を、IPv6 全体の普遍的なサブネット境界として扱う必要はありません。