【2026年最新版】Wi-Fi IPv6ルーター広告のプレフィックス委任が機能しない原因と対処法【完全ガイド】

公開日：2026/04/14　更新日：2026/04/14　

※本ページにはプロモーション(広告)が含まれています

Wi-Fi IPv6ルーター広告（RA）のプレフィックス委任が機能しない原因と対処法

IPv6環境を構築しようとしたとき、ルーターがRAを送信しているはずなのにクライアント端末がIPv6アドレスを取得できない、またはプレフィックス委任（Prefix Delegation / PD）が機能せずLAN側にIPv6アドレスが配布されない——こうした問題はネットワーク管理者や自宅サーバー運用者が直面しやすい複雑なトラブルです。

本記事ではIPv6のルーター広告（Router Advertisement / RA）とプレフィックス委任の仕組みを基礎から解説し、動作しない原因を特定して解決するための手順を詳しく説明します。

この記事でわかること

IPv6ルーター広告（RA）とプレフィックス委任（PD）の基礎知識
RAが送信されているのにアドレス取得できない原因
ISPのDHCPv6-PD対応状況の確認方法
ルーター・OS別の設定確認と修正手順
RAフラグ（M/Oフラグ）の設定ミスとその直し方
radvdまたはdnsmasqの設定例

IPv6ルーター広告とプレフィックス委任の基礎知識

ルーター広告（RA）とは

ルーター広告（Router Advertisement）はIPv6ネットワークでルーターがマルチキャストで定期送信するICMPv6メッセージです。クライアント端末はこのRAを受信することで以下の情報を取得します。

デフォルトゲートウェイのアドレス
ネットワークプレフィックス（例: 2001:db8:1234::/64）
SLAAC（ステートレス自動アドレス設定）の使用可否
DHCPv6を使うかどうか（M/Oフラグ）

プレフィックス委任（DHCPv6-PD）とは

プレフィックス委任（Prefix Delegation）はISP（インターネットサービスプロバイダー）がルーターに対してIPv6プレフィックスブロック（通常/56または/48）を割り当てる仕組みです。ルーターはこのプレフィックスをさらに細分化（例: /64に分割）してLAN側のサブネットに配布します。

家庭向けIPv6環境では一般的に以下のフローになります。

ISPがWAN側でDHCPv6-PDによりルーターに/56プレフィックスを委任
ルーターが委任されたプレフィックスからLAN用/64を切り出してRAで配信
LAN内のクライアントがRAを受信してSLAACでIPv6アドレスを自動設定

RAフラグ（M/Oフラグ）の役割

RAには動作を制御する重要なフラグが2つあります。

フラグ	名称	意味	典型的な設定値
M (Managed)	管理アドレス設定フラグ	1=DHCPv6でアドレス取得 / 0=SLAACで自動設定	0（SLAAC環境）または 1（DHCPv6環境）
O (Other)	その他設定フラグ	1=DNSなどの追加情報をDHCPv6から取得	1推奨（DNS配布のため）

プレフィックス委任が機能しない原因

原因1: ISPがDHCPv6-PDに対応していない

日本の主要ISPはIPv6を提供していてもDHCPv6-PDに対応していない場合があります。特にMAP-E・DS-Lite方式でIPv6を提供しているISPは、プレフィックス委任ではなく固定のプレフィックスを静的に割り当てる方式を採用しているため、ルーターでDHCPv6-PDクライアントを有効にしても委任が受けられません。

原因2: ルーターのWAN側DHCPv6クライアントが無効

ルーターの設定でWAN側に「DHCPv6クライアント」を有効にしていないとプレフィックスの委任を受けられません。また「プレフィックス委任を要求する」オプションが別途存在するルーターもあり、これを見落としているケースがあります。

原因3: RAのプレフィックス情報（PIO）が設定されていない

ルーターがRAを送信していても、Prefix Information Option（PIO）にLAN側のプレフィックスが正しく含まれていないとクライアントはアドレスを生成できません。radvdやdnsmasqでRAを送信している場合、プレフィックスの指定が誤っていることがあります。

原因4: RAのM/Oフラグの設定ミス

M=1に設定するとクライアントはSLAACを使わずDHCPv6でアドレスを取得しようとします。しかしLAN側にDHCPv6サーバーがない場合、クライアントはアドレスを取得できません。SLAAC環境ではM=0・O=1が正しい設定です。

原因5: ルーターのファイアウォールがICMPv6をブロック

ルーターまたはPCのファイアウォールがICMPv6（タイプ134=RA、タイプ133=RS）をブロックしていると、RAを受信できません。特にWindowsのファイアウォール設定ではICMPv6を個別に許可する必要があります。

原因6: OSのIPv6受信設定が無効化されている

Linuxサーバーでは`sysctl`の`net.ipv6.conf.all.accept_ra`が0に設定されている場合、RAを受信しません。また`net.ipv6.conf.all.forwarding=1`（IPv6フォワーディング有効）にすると、デフォルトで`accept_ra`が0に変わるという挙動があります。

対処法（ステップ順）

対処法1: ISPのIPv6方式を確認する

まず契約しているISPがどのIPv6方式を採用しているか確認します。

ISPのサポートページまたは会員ページで「IPv6接続方式」を確認
「IPoE（DS-Lite / MAP-E）」の場合 → DHCPv6-PDではなく静的プレフィックスが配布される方式
「DHCPv6-PD」または「ネイティブIPv6」と記載がある場合 → DHCPv6-PDが使える

DS-Lite・MAP-E環境でもIPv6アドレスはクライアントに配布されますが、ルーターの設定UIでの表記がDHCPv6-PDと異なる場合があるため、ISPの設定ガイドを参照してください。

対処法2: ルーターのDHCPv6クライアント設定を有効にする

ルーターの管理画面にアクセス（通常は192.168.1.1または192.168.0.1）
「WAN設定」→「IPv6設定」を開く
「DHCPv6クライアント」または「IPv6アドレス取得方式：DHCPv6」を選択
「プレフィックス委任を要求する（Request Prefix Delegation）」にチェックを入れる（表示される場合）
設定を保存してルーターを再起動

対処法3: RAのプレフィックス情報を正しく設定する（radvd使用の場合）

radvdを使用している場合、`/etc/radvd.conf`を以下のように設定します。

interface eth0 {
    AdvSendAdvert on;
    MinRtrAdvInterval 30;
    MaxRtrAdvInterval 100;
    AdvManagedFlag off;   # M=0: SLAACを使用
    AdvOtherConfigFlag on; # O=1: DNSをDHCPv6から取得
    prefix ::/64 {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
    };
};

`prefix ::/64`とすることで、DHCPv6-PDで委任されたプレフィックスを自動的に使用します（radvd 2.x以降）。

対処法4: dnsmasqでRAを設定する

dnsmasqを使用している場合は`/etc/dnsmasq.conf`に以下を追加します。

# DHCPv6-PDでプレフィックスを取得している場合
dhcp-range=::1,::ffff:ffff:ffff:ffff,constructor:eth0,ra-stateless,64
enable-ra

対処法5: ファイアウォールでICMPv6を許可する

Linuxのiptables / nftablesを使用している場合、以下のルールでICMPv6 RAを許可します。

# ip6tables でICMPv6全許可（推奨）
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -A FORWARD -p icmpv6 -j ACCEPT

Windowsの場合は「Windows Defender ファイアウォール」→「詳細設定」→「受信の規則」で「コアネットワーク – ルーターアドバタイズメント（ICMPv6受信）」を有効にします。

対処法6: Linuxのaccept_ra設定を確認・修正する

LinuxサーバーでIPv6フォワーディングを有効にしながらRAも受信したい場合は以下のsysctl設定が必要です。

# /etc/sysctl.conf に追記
net.ipv6.conf.all.accept_ra = 2      # フォワーディング有効時でもRA受信
net.ipv6.conf.eth0.accept_ra = 2     # インターフェース個別設定
net.ipv6.conf.all.forwarding = 1

設定反映は`sudo sysctl -p`を実行します。

対処法7: tcpdumpでRAの送受信を確認する

RAが実際に送受信されているか確認するには以下のコマンドが有効です（Linux / macOS）。

sudo tcpdump -i eth0 -n "icmp6 and (ip6[40] == 134 または ip6[40] == 133)"

タイプ134がRA（Router Advertisement）、タイプ133がRS（Router Solicitation）です。RAが表示されれば送信側は正常です。

原因別・対処法マトリクス

症状	疑われる原因	確認方法	対処法
WAN側にIPv6アドレスが付かない	ISP非対応または DHCPv6クライアント無効	ISPの設定ガイド確認	対処法1・2
WAN側はOKだがLANにアドレスが配布されない	RA未送信または PIO設定ミス	tcpdumpでRA確認	対処法3・4
RAは届くがSLAACアドレスが生成されない	M/Oフラグ誤設定または accept_ra=0	radvd.conf確認 / sysctl確認	対処法3・6
Linuxルーターでのみ問題が起きる	accept_ra=0（フォワーディング有効時）	sysctl net.ipv6.conf確認	対処法6
Windowsクライアントだけが取得できない	ICMPv6ブロック	WFWの受信ルール確認	対処法5

よくある質問（FAQ）

Q1. ISPからIPv6が提供されているのにルーターのWAN側にアドレスが付きません。確認方法は？

ルーターの管理画面でWAN側のIPv6アドレス欄を確認してください。空欄の場合はDHCPv6クライアントが無効か、ISPがDHCPv6-PDではなく静的割り当てを使っている可能性があります。ISPのサポートに「DHCPv6-PDに対応しているか」を直接問い合わせるのが最も確実です。

Q2. RAを送信しているのにクライアントがIPv6アドレスを取得できません。原因は？

最も多い原因はRAのプレフィックス情報（PIO）が正しく設定されていないケースです。radvdであれば`prefix ::/64`の設定を確認してください。また、クライアント側でICMPv6がブロックされていないかも確認が必要です。tcpdumpでRAパケットがクライアントに届いているかを確認するのが最初のステップです。

Q3. LinuxルーターでIPv6フォワーディングを有効にしたらLAN側がIPv6アドレスを取得できなくなりました。

これはLinuxカーネルの仕様です。`net.ipv6.conf.all.forwarding=1`を設定すると、デフォルトで`accept_ra`が0になります。`/etc/sysctl.conf`に`net.ipv6.conf.all.accept_ra = 2`を追加して`sysctl -p`で反映させてください。値「2」はフォワーディング有効時でもRAを受け入れる特別な設定です。

Q4. IPv6プレフィックスは/56と/48のどちらを要求すべきですか？

一般家庭向けISPは通常/56を委任します。/48はエンタープライズ向けの大きなブロックで、家庭向けISPでは提供していないことがほとんどです。ルーターの設定では「要求するプレフィックス長」を/56にしておくのが標準的です。

Q5. SLAACとDHCPv6ステートフルはどちらを使うべきですか？

家庭・小規模オフィスではSLAACが推奨されます。設定が簡単でDHCPv6サーバーが不要なためです。RAのM=0・O=1（DNS情報のみDHCPv6から取得）の組み合わせがバランスの取れた設定です。DHCPv6ステートフル（M=1）は固定IPアドレス管理が必要な企業ネットワーク向けです。

Q6. Windows 11でIPv6アドレスが「一時アドレス」しか表示されません。なぜですか？

Windows 11はプライバシー拡張機能（RFC 4941）が有効になっており、SLAACで生成されるアドレスにランダム化処理が加わります。これは正常な動作です。「固定の」IPv6アドレスが必要な場合はNetshコマンドまたはPowerShellでプライバシー拡張を無効化できますが、プライバシー上の理由から一般ユーザーへの無効化は推奨しません。

まとめ

IPv6ルーター広告のプレフィックス委任が機能しない問題は、ISPの対応方式・ルーターのDHCPv6クライアント設定・RAのプレフィックス情報（PIO）設定・M/Oフラグの設定ミス・ファイアウォールによるICMPv6ブロック・Linuxのaccept_ra設定——これらが複合して起きることがほとんどです。

まずISPがDHCPv6-PDに対応しているかを確認し、次にルーターのWAN側DHCPv6クライアントを有効にしてプレフィックスが委任されるかを確認します。LAN側に問題が残る場合はradvdまたはdnsmasqの設定とファイアウォールルールを順番に見直してください。

tcpdumpを使ったパケット確認が問題の切り分けに最も効果的です。RAパケットが届いているかいないかによって、問題がルーター側にあるのかクライアント側にあるのかを明確に特定できます。焦らず一つずつ確認することが解決への最短経路です。