Zenn
📥

IPv6アドレス自動設定

2023/04/11に公開
network
IPv6
tech

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

はじめに

IPv4では、DHCP（Dynamic Host Configuration Protocol）によりクライアントのIPアドレスを自動設定することが知られていると思います。流れとしては、最初にクライアントが所属ネットワーク内にDHCP Discoverをブロードキャストした後、それを受信したDHCPサーバがDHCP Offerにより応答し、クライアントへIPアドレスを提案します。

注目すべきポイントとして、このOfferのタイミングでIPアドレス以外の情報を返すことが挙げられます。

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

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

など、IPアドレス以外の情報も含まれていることがわかります[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）を配布する訳ではないという点があげられます。すなわち、1.と3.は、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で配布

流れ

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

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

次に、ルーターがRA（Router Advertisement）を返信します。宛先は全クライアントが必ず属しているマルチキャストグループである ff02::1 宛です。

このRAを受け取ったクライアントは、送信元アドレスがそのままデフォルトゲートウェイとして認識されます。デフォルトゲートウェイは通常、リンクローカルアドレス[2]となります。

さて、RAの中身を見ていきます。最も重要なフィールドは、このRA中のM-FlagとO-Flagと呼ばれる箇所です。

  • M-Flag: IPv6アドレスのインターフェースIDをクライアント自身が決めるのではなく、DHCPv6で配布させるためのフラグ。パケットキャプチャ上、Managed address configurationと表記。
  • O-Flag: DNSサーバなど様々な情報をDHCPv6で取得させるためのフラグ。パケットキャプチャ上、Other configurationの表記。

以下表のように、この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 宛であることにも注目してください。

これにて晴れて必要な情報がそろいました。以上がRA+ステートレスDHCPv6です。

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