RouterAdvertisement

RA(Router Advertisement)

ルーターが自分の存在や割りあてたいprefixを知らせるための仕組み。

一定周期でマルチキャストするケースと、ホストからのRSをうけてマルチキャストするケースの二つ

主にルーターとクライアントでステートレスにIPv6アドレスを割り当てるために仕組み。RFC4862。

正確に書くとRAはIPを割りてるのではなくprefixを通知するだけ

実アドレスはホスト側でprefix情報等を元に自動生成をしている形

SLAACと呼ばれる。

インターフェースIDが/64が前提となっている仕組み

つまりRAでのアドレス自動設定はprefix調が/64以上では使えなということに注意

IPv6クライアントはRouter Solicationメッセージをマルチキャスト(全ルーターマルチキャスト FF02::2)送信。

ルーターはRSメッセージをうけとりRAメッセージをマルチキャスト(全ノードマルチキャスト FF02:1)送信。

ノードはRAメッセージによりそのネットワークのネットワークプレフィックスを取得

EUI-64でインタフェースIDを生成することでIPアドレスを生成する。

EUI-64だけだとMACアドレスベースで生成するので常に固定されたIPになってしまうので特定されうる。

なのでランダムにIPを変えるプライバシー拡張がある、実際はこちらが主に使われる。

だいたいのOS(windows等)ではこちらのオプションがデフォルト有効

RAでは初期はDNS情報は送信できなかったが、RFC 6106で送信できるように標準化された。

RA情報

prefix

prefix length

current hop limit

このRAを利用するノードのipv6 パケットのhop limit

Mフラグ（Managed Flag）

0: Stateless Address Autoconfigで自動的にアドレスを生成して設定

1: Statefull Address Autoconfig。DHCPv6でipv6アドレスを割り当てないといけない

Oフラグ（Other Flag）

0: アドレス以外の情報をDHCPv6で取得

1: アドレス以外の情報をDHCPv6で取得

デフォルトルーターの情報

子のデフォルトルーターをデフォルトルートとして利用する。

ルータライフタイム

このRAの送信元ルーターをデフォルトルートとして使う時間。

RAの送信元ルーターのアドレスをデフォルトゲートウェイとして採用する。

デフォルトゲートウェイとして使われるのはリンクローカルアドレス。

RAがlink localのIPをソースにしてくるから。

Reachableタイム

NSを送る間隔

Retransmissionタイム

NS応答が無い場合のNSの再送時間

MTU長

MTU通知。デフォルト 1500

DNS情報

RDNSSに対応している場合のみ

最近だと一般的に有効？

NS(近隣要請)

v4でいうARP

要請ノードマルチキャストアドレスにたいして発信

調べたいアドレスの末尾3byteを要請ノードマルチキャストアドレスに埋め込む

NA(近隣広告)

要請ノードマルチキャストアドレスをうけて応答をする。

自信への要請化は埋め込まれた3byteの末尾アドレス値を自身と比較して判定

NSとNAは双方向で行う必要がある

双方向で行いお互いのMACを学習しあう

ARPは片方向の解決で双方でmac学習できたのとは違う。

RS(Router Solicitation

ff02::2

ホストがI/F upと同時にマルチキャスト(FF02::2)に送信

ルーターはRSをうけてRAをマルチキャストしている。

自動アドレス設定

RA: SLAAC

ステートレス

RAのprefix情報+ノードのMACアドレスで生成

SLAACはmac address (48bit) を ipv6 interface (64bit)に変換するアルゴリズム

DHCPv6

サーバーが割り当てる

default gatewayの通知はできない。

ここはRAで行う。

単独での運用がipv4と違いできない。RAとの組み合わせは必須

DNSやSIPサーバーの通知ができる

流れ

アドレス

RAとDHCPv6の違い

RAはあくまでprefixを通知。

ホストの実IPはEUI-64等のルールで固有のIPを生成する

DHCPv6は直接固有のIPをホストに付与する

prefixの譲渡はDCHPv6-PD

サーバー側でホストとIPの対応を管理できる。

DHCPv6のほうが細かい情報も追加で付与できる。

最たる例がDNSサーバー

ただし現在はRAでもDNSサーバーは通知できる

このRAでのDNSサーバーの通知するオプション仕様をRDNSSと呼ぶ

ただルーターによってはRDNSS非対応の場合もあるので利用する場合は注意。

一部のandroidがこの非対応な機種。androidはDHCPv6にすら対応していないものも。

windows10 creators update以前も非対応。数年前なのでもうあまりいないと信じたい。

DNSサーバー以外の情報もDHCPv6なら通知可能

IP管理や追加で細かいところまでやるならDHCPv6が必要になりがち

RAで追加情報をわたせるようになっているが、機種によっては対応できてないこともある

DHCPv6 ではデフォルトゲートウェイをわたせない

RAによってデフォルトゲートウェイを付与すること前提になっている。

DHCPv6だけでは実は完結しない

ただしドラフトレベルでDHCPv6でデフォルトゲートウェイを渡せる仕様が策定中らしい

DHCPv6

大きくは3種類

Statefule DHCPv6

DHCP for IPv6

DHCPv4と同じ。デフォルトゲートウェイのみRAで広報する

RAのMフラグでDHCPからIP取得するようにクライアントに通知。

クライアントはDHCPからIPやDNS情報等を得る。

Rapiid clientオプションを使うと情報項目の確認をすっ飛ばせる。問答無用で情報を配る。

DHCPv6-PD

ルーターからDHCPv6にIPv6 prefixの払い出しをしてもらう。 IA_PDオプション

払い出されたpfrefixを用いてクライアントにRAを配布する。

Stateless DHCPv6

RAのOフラグでクライアントにprefixを付与

OフラグでDHCPv6クライアントが稼働、prefixからIPを生成。

その他のDNS等の情報はDHCPサーバーから得る

RAがステートレスなIPv6アドレス割り当てを行うのに対して、DHCPv6ではステートフルなIPv6アドレス割り当てを行える。

RFC 8415。

DHCPv6ではRAでは通知できない情報も追加で通知可能

具体的にはDNSサーバー

RDNSSが現在はあるが

DHCPv6をつかってもアドレス割り当てはRAを使い追加情報の通知のみにDHCPv6を使う運用も

ステートレスDHCPv6と表現される

おそらく管理も楽で主流な使い方はコレ

ステートフルに割り当てればどのクライアントがなんのIPを持っているかの管理がDHCPv6サーバー側で可能

特定macaddressの機材に固定のアドレスを振ったりとRA(SLAAC)にはできない細かな制御が可能。

クライアントへのPrefix割り当てはDHCPv6-PD(PrefixDelegation)を利用しないと実現できない。

DHCPv6ではデフォルトゲートウェイは通知できない

デフォルトゲートウェイはRAで行う。

つまりDHCPv6だけでの運用は不可能。

一応ゲートウェイを通知機能のドラフトはあるらしいが

RA vs DHCPv6

ipv6ではDNSサーバーアドレスをRAとDHCPv6どちらでも配布できるが、どちらでやるべきか。

クライアント側の問題でRA(RDNSS)しか対応しない(android)、DHCPv6しか対応しない(windows8.1未満)とかある

どのクライアントをターゲットにするかで運用方式が変わる。

両対応するというのもよくある話。

windows10だとRDNSSサポートしているので、最新環境ならRA(RDNSS)でDNSは対応してしまうのが一元的になるか

一部の特別な端末のIP管理のためだけに別途ステートフルDHCPv6を使うとかももちろんあり。

SLAACだとホストのIPアドレス管理はできない

社内ネットワークだとIP管理のためにステートフルDHCPv6を使うとかになるか

DNS以外上の特殊な情報を通知するためにRA+ステートレスDHCPv6として使うのももちろんあり。

NDのキャッシュ情報を定期的に記録しておけば一応RA(SLAAC)運用でもアドレスの払い出しの後追いは可能。

偽RA問題

ipv6では一つのIFに複数のIPアドレスが与えられる。

攻撃者は偽RAで特定のprefixをon-link(L flag = 1)をユーザーに送ることで、特定のprefixだけをon-link(ローカルネットワーク)として誤認させることができる。L flagを立てないとon-linkとして誤認せず、パケットはルーターに経由になってしまう。

仮に誘導したい偽サイトのipv6アドレスをon-linkとして誤認させればユーザーはNDを発行する。

同一リンク上で攻撃者の用意した偽サーバでこのNDに応答させれば本来のゲートウェイルーターへのいくはずのパケットを

偽サイトのウェブサーバーにパケットを直接誘導させることができる。

不正なDHCPv6でも同様のことはできる。対策はRA guard RFC7113を実装する。

DHCPv6-Shield RFC7610というのもある。

ホスト側でRAを受け取らない設定も場合によってはあり。

NDproxy

RFC4861,RFC4389

RAproxy機能を有する場合も

RAをproxyする場合はデフォルトルートゲートウェイ IPをNDproxyのものに書き換えている

RAのPbitを1にして転送

P bitが1になっているとNDproxyで転送されたRAとわかる

P bitが1のRAはNDproxyは転送しない。

ループ防止

fletsだとNGN側のルータはRAの場合はホームゲートウェイ配下へのIPv6ホストは直接L2でぶら下がっている前提

NDproxyがないとホームゲートウェイ配下のホストIPのMACアドレス解決ができない。

NDP(ICMPv6 NS)をproxyすることでNGN側ルーターがMACアドレスを解決できてパケットを投げてくれる

ホームゲートウェイまでパケットがくれば後はフォワーディングできる。

RAの下でルーターを設置する場合に必要になる。

RAを広報する区間というのはひとつのL2ドメインという前提なので

すべてのIPのMACアドレスを解決できないといけない。

似た機能にipv6 path throughがある

これは単純にL2 bridgeとしての機能。全てのipv6パケットを下に通す

NDproxy自体は本来ただのRA,NDをproxyするだけの機能

ルーターによってはファイアウォール機能の有効化をするのにNDproxyを有効化が必要なものがある

グローバルアドレスをホストに直接付与する都合で単純にファイアウォール機能が必須なだけ

NDproxyを使っていようがipv6のファイアウォール機能が有効化されてないければ危険なことに変わりはない

IPv6対応プラン

IPv4 IPv6 Dual tack

シンプル。機器も使いまわせる。

v4とv6のログが混ざる。障害時の影響が大。

複雑になる。

別々に構築するParallel Stack

機器が多くなる。

単純に物理から別になるので構造が簡単。

現在はipv6トラフィック量も多いので小規模スタートできないかもしれない

一部をDual, 一部をParallel stackなHybrid stack

管理が大変

わりとやっているところも多い。

部分ごとにDual stackで進められるか、parallelでやるべきかを考える。

一気にやると大変なので部分ごとにプランを分けて考えてやるべき