📥

IPv6アドレス自動設定

2023/04/11に公開

「クライアントにIPv6アドレスを自動で設定させる手法」について、パケットキャプチャつきで説明します。

はじめに

IPv4は、DHCP(Dynamic Host Configuration Protocol)によりクライアントのIPアドレスを自動設定します。流れとしては、最初にクライアントがDHCP Discoverをブロードキャストした後、DHCPサーバがDHCP Offerにより応答し、クライアントへIPアドレスを提案します。特筆すべきポイントとして、このOfferのタイミングでIPアドレス以外の情報を返すことが上げられます。

このパケットキャプチャのように、

  1. IPアドレス
  2. プレフィックス長(サブネットマスク)
  3. デフォルトゲートウェイ(ルーターアドレス)
  4. DNSサーバーアドレス(フルリゾルバのアドレス)

などが含まれます[1]

DHCPの要旨は以上です。シンプルです。しかし、同じことをIPv6でやろうとすると、単にアドレスがIPv6になるだけではありません。全く違う仕組みが使われます。さらにその方式が複数あることも、IPv6アドレスの自動設定を複雑にしています。

3つの方式

DHCPのようにDNSサーバーアドレスの配布方式もセットで考える場合、IPv6アドレスの自動設定は以下3つの方式があります。

  1. RA+ステートレスDHCPv6
  2. RA+ステートフルDHCPv6
  3. RA Only

ここで、RAはRouter Advertisementの略で、プロトコルとしてはICMPv6です。

最初に理解すべき注意点として、1.と3.はPrefix(通常64bit)を配布するだけで、IPv6アドレスのすべて(128bit)を配布する訳ではありません。Prefixを基に、他の部分はクライアントが自動で生成します。言い換えると、(実は大半の場合はその必要はないのですが)IPv4のDHCPのように完全なIPアドレスを配布したければ2.を使うしかないということです。

なお、FTTHサービスでよく聞くDHCPv6-PDはこの記事では対象外です。主にISPから64bitより広いIPv6アドレス空間を委譲される際に使われるプロトコルですが、これは決してクライアントにIPv6アドレス(またはそのPrefix)を配布するためのプロトコルではないからです。

1. RA+ステートレスDHCPv6

特徴

  • 家庭用ルータでは最も一般的な実装
  • AndroidではDHCPv6をサポートしていないため、Android端末にIPv6のDNSサーバー情報を配布できない

配布方式

項目 配布方式
IPアドレス PrefixをRAで配布し、インタフェースIDはクライアントが生成
プレフィックス長 RAで配布
デフォルトゲートウェイ RAの送信元として認識
DNSサーバーアドレス DHCPv6で配布

流れ

最初に、(これは1.-3.のどの方式でも共通なのですが、)クライアントがネットワーク内にRS(Router Soliciation)をマルチキャストで送信します。

なぜマルチキャストなのかというと、IPv6にはブロードキャストがないためです。代わりに、ルーターが必ず属しているマルチキャストグループである ff02::2 宛にマルチキャストを行うことで、必要なところへRSを送信します。

次に、ルーターがRA(Router Advertisement)を返信します。宛先は全クライアントが必ず属しているマルチキャストグループである ff02::1 宛で、送信元アドレスがそのままデフォルトゲートウェイとして認識されます。デフォルトゲートウェイは通常、リンクローカルアドレス[2]となります。

最も重要なポイントは、このRA中のM-FlagとO-Flagと呼ばれる箇所です。

  • M-Flag: IPv6アドレスのインターフェースIDをクライアント自身が決めるのではなく、DHCPv6で配布させるためのフラグ
  • O-Flag: DNSサーバなど様々な情報をDHCPv6で取得させるためのフラグ

以下表のように、このFlagの有無で、先ほどの1.-3.の方式のいずれを利用するかクライアントに伝えます。

方式 M-Flag O-Flag
1. RA+ステートレスDHCPv6 0 1
2. RA+ステートフルDHCPv6 1 1
3. RA 0 0

1.の方式では、キャプチャに示したとおりM-Flagが0でしたので、これを受け取ったクライアントはIPv6アドレスのインターフェースIDを作成します。インターフェースIDの作成方法は大きく以下の3つがありますが、この記事では詳しく触れません。

  • MACアドレスと紐付け[3] ※現在ほぼ使われていない少し古い方法
  • ランダム[4]
  • インターフェース固有の情報に基づいて決定[5]

いずれかの方法でインターフェースID(64bit)が作成できれば、あとはRAで受けとったPrefix情報(64bit)と組み合わせ、IPv6のホストアドレス(128bit)を設定します。なお、実際のクライアントでは、複数のインターフェースIDを作成し、複数のグローバルなIPv6アドレスを持つケースが多いです。

残りはDNSサーバーアドレスです。キャプチャに示したとおりO-Flagが1でしたので、クライアントが新たにDHCPv6リクエストを送り、DHCPv6サーバーがDHCPv6応答を返すことで、DNSサーバーの情報を入手します。DHVPv6リクエストの送信先は、DHCPサーバーが属しているマルチキャストグループである ff02::1:2 宛であることにも注目してください。

これにて晴れて必要な情報がそろいましたね。

2. RA+ステートフルDHCPv6

特徴

  • 家庭用ルータで実装されている例はあまり見ない(主に企業向けの方式)
  • AndroidではDHCPv6をサポートしていないため、Android端末はIPv6通信が一切できない
  • IPv4のDHCPに最も近い方式

配布方式

項目 配布方式
IPアドレス DHCPv6で配布
プレフィックス長 DHCPv6で配布
デフォルトゲートウェイ 通常はRAの送信元として認識
DNSサーバーアドレス DHCPv6で配布

流れ

RS・RAまでは1. の方式に準じます。

受信したRAのM-Flagが1となっている場合、クライアントはDHCPv6サーバーにアドレスを聞きにいきます。設定すべきアドレスをAdvertiseしてくれますが、なんと残念ながらデフォルトゲートウェイ(ルータアドレス)は教えてくれません。そのため、結局RAと組み合わせる必要があり、DHCPv6単体では事実上使えないのが実態です。

主に、エンタープライズのネットワークで、クライアントを厳密に管理しているとか、ファイアウォールの設定上全てのクライアントのIPv6アドレスを固定したいとか、そういった目的でのみ使われます。家庭で使うメリットはありません。

この環境を作ることができなかったため、キャプチャはありません。

3. RA Only

特徴

正確には「RAによるRDNSSオプション」と呼ばれることがあります。

  • 家庭用ルータでの実装は比較的少なめ[6]
  • 最も新しい方式でかつシンプル(DHCPv6に依存せずRAだけで完結するため)
  • Androidを"きちんと"IPv6対応させるためには現状これしかない

配布方式

項目 配布方式
IPアドレス PrefixをRAで配布し、インタフェースIDはクライアントが生成
プレフィックス長 RAで配布
デフォルトゲートウェイ RAの送信元として認識
DNSサーバーアドレス RAで配布

流れ

基本的には1. の方式に準じます。

RAのオプションにて、DNSサーバアドレスが広告されているのが分かります。

組み合わせ

1.-3.の方式を説明しましたが、実際には複数の方式が組み合わされて使われることがあります。先ほどの3. で紹介したキャプチャですが、実はよくみると、 M-Flag と O-Flag いずれも0ではなくて、O-Flagが1となっています(でも、RDNSSオプションでDNSサーバアドレスが広告されています)。

この場合、DHCPv6サーバーにステートレスなDHCPv6でDNSサーバアドレスを聞きに行くかどうかはクライアントの実装依存です[7]

Androidが唯一対応している3. の方式だけ対応しておけば十分ではないか?と思われるかもしれませんが、古いクライアントでは3. のRDNSSオプションに対応していない場合もあるため、こういった複数の方式をケアしておくのが一般的なようです。特に様々なOSのクライアントが混在しているネットワークでは、注意が必要です。

脚注
  1. 実際にはDHCPサーバの仕様に依存し、Offerのタイミングで全てが必ず通知されるわけではありません。クライアントが必要なオプションをRequestし、そのACKのタイミングで通知されるものもあります。このスクリーンショットでは、特定のルーター(YAMAHA RTX1200)のDHCPサーバーの場合で説明しています。 ↩︎

  2. 同一L2ドメイン内だけで使うIPv6アドレス。デフォルトゲートウェイであるルーターは必ず同じL2ドメイン内に存在するため、リンクローカルアドレスを使います。 ↩︎

  3. RFC4291。Modified EUI-64。最も初期に使われていた方式だが、MACアドレスをほぼそのままインターフェースIDにするため、プライバシーの懸念がある。 ↩︎

  4. RFC4941。RFC4291の課題を解決するため、定期的にインターフェースIDを変更する仕組みを採用したが、一方でエンタープライズのネットワークでは扱いにくいという欠点がある。 ↩︎

  5. RFC7217。IPv6アドレスからMACアドレスが推察できないが、クライアントの環境が変わらない限りIPv6アドレスが変わらないという特徴がある。 ↩︎

  6. 公式に対応を謳っているルーターとしてNEC製のAtermがあります。ご家庭のWi-FiにAndroid端末を接続しており、IPv6対応をしたい方はオススメです。https://www.aterm.jp/product/atermstation/special/ipv6/ipv6_ra_rdnss.html ↩︎

  7. 手元のMacOSではDHCPv6リクエストを送信していました。Android以外はこの実装の場合が多いのではないでしょうか。 ↩︎

Discussion