コメント
承認待ちコメント
このコメントは管理者の承認待ちです
管理人のみ閲覧できます
このコメントは管理人のみ閲覧できます
Neighbor Discovery - ICMPv6 Type133~136
- 2013/12/13
- 19:10
コンピュータネットワークといえば TCP/IP の IPv4 がデファクトスタンダード化してますが、近年は IPv6 が徐々に表舞台に出てきました。Windows 7 や 8 は標準で IPv6 に対応していますし、NTT の NGN 網でも v6 オプションが知らぬうちに付いてきたりと、IPv6 が身近な存在になりつつあります。
そんな IPv6 ですが、僕の勤める病院では 「院内ネットワークをオール IPv6 化にしよう！」 というプランが持ち上がっています。ただでさえ IT 化が遅れている医療業界なのに、院内 LAN をオール IPv6 にするとは…… IT 好きの院長先生には心から脱帽します。
―――が！！
（院内を IPv6 化かとか、スゲーなぁ…）
なんて思っている暇はなくって、僕もその IPv6 化プロジェクトの一員 に任命されています。 IPv6 が身近になっているどころか、むしろ IPv6 を扱うことが仕事になりつつあり、ブログのタイトルが 「IPv6 まわりのプロになりたい」 になる日が近くなるかもしれませんね。。（笑）
そんな IPV6 についての記事第一弾は 「Neighbor Discovery」 についてメモしたいと思います。
ICMP
Neighbor Discovery は ICMPv6 を使っていますので、まずは簡単に ICMP についてメモします。
IPv4 の世界には ICMP (Internet Control Message Protocol) というプロトコルが存在します。これは主に IP パケットのエラー通知を担当するプロトコルです。
この ICMP の特性を利用したものに Ping や Traceroute コマンドがあります。ネットワークの疎通を確認するための Ping。宛先ノードへの通信経路を確認するための Traceroute。ネットワークに馴染みのある方でしたら、一度は活用されたことがあると思います。ちなみに僕は「ピング」と読む派です（笑）。
↑図1：Ping コマンド。これ無いと生きていけない
↑図2：Traceroute コマンドは Linux。Tracert コマンドは Windows
このように IPv4 の ICMP は、エラー通知や経路状況の把握にとても重宝するプロトコルで、IP の通信には無くてはならない存在です。そんな ICMP は IPv6 では ICMPv6 という名でバージョンアップされましたが、ICMP とは比較にならないほど ICMPv6 は多機能になっています。
たぶんですが、IPv6 をマスターするには ICMPv6 の理解が欠かせない と思います。それに ICMPv6 を理解すれば、芋づる式に色々な機能まで理解できるはず （と信じてる…） ですから、ここは押さえておきたいですね。
ARP
さっそく Neighbor Discovery について書こう……と思いますが、その前にちょっと ARP (Address Resolution Protocol) についてメモします。
ARP は MAC アドレスを調べ上げるプロトコルで Ethernet で使われます。ある PC に対してデータを送信したいとき、あて先の IP アドレスを知っていれば通信できそうですが、実は MAC アドレスも知らなければ通信ができません。IP アドレスはレイヤー3の世界で使われる位置情報ですが、MAC アドレスはレイヤー2の位置情報。Ethernet ではこの2つのアドレスが必要不可欠です。
↑図3：パケットには IP アドレス以外にも位置情報が必要
※ 上の図にもありますように、TCP/IP でやり取りするデータ全体のことを パケット と表記していましたが、これでは OSI 参照モデルのレイヤー3の PDU とかぶってしまうことから、OSI 参照モデルの PDU に関しては 英語表記 に変えました。例えば、ネットワークセグメントを表すときは 「セグメント」 と書きますが、レイヤー4の PDU では 「Segment」 と書き、またネットワークで扱うデータ（小包にたとえるアレ）のことを 「パケット」 と呼ぶ一方、レイヤー3 の PDU では 「Packet」 と書いていきます。概念を理解するには、区別化した方がいいと思っての判断です。ただでさえ読みづらい文章が更に読みづらくなりますが、そんなことを気にしてはいけません（笑）。
話を戻しますが、相手にパケットを届かせるためには IP アドレスの他に MAC アドレスが必要です。以下に MAC アドレスと ARP の関係をパケットの流れを追いながらメモします。「PC1 がそれぞれ PC2 と PC3 へパケットを送る流れ」 を例に挙げます。
まず PC1 から PC2 へパケットを送り出すときですが、そのパケットには PC1 の IP アドレスと MAC アドレスが送信元アドレスとして書き込まれます。またこれと同時に、あて先となる PC2 の IP アドレスと MAC アドレスも、それぞれの PDU に書き込まれます。このとき PC1 が PC2 の MAC アドレスを知っていれば問題ありませんが、もし PC2 の MAC アドレスを知らない 場合は Frame のあて先に MAC アドレスを書き込めませんので、前述したように通信ができません。
↑図4：IP アドレス以外にも MAC アドレスが必要
そこで使われるのが ARP です。PC1 が PC2 へ「PC2 の MAC アドレス教えてください」（ARP Request） といった ARP メッセージを投げます。これを PC2 が受け取ると 「自分の MAC アドレスは○○です」（ARP Reply） とアドレス情報を記載して PC1 へ送り返します。この ARP Reply を受け取ってようやくあて先 MAC アドレスに PC2 の情報を書き込むことができ、通信準備が整います。
ちなみに ARP Reply は双方の MAC アドレスを知っていることからユニキャスト通信ができますが、前者の ARP Request はそもそもあて先 MAC アドレスを知らないため、ここではブロードキャスト通信が使われます （Frame ではは FF:FF:FF:FF:FF:FF がブロードキャスト）。
↑図5：ARP で相手の MAC アドレスを取得する
また PC1 から PC3 への通信では PC3 はネットワークセグメントが違うため、あて先 MAC アドレスはルータ （または L3 スイッチ） が指定されます。これは ARP （ブロードキャスト） はルータを越えられないためです。ルータは PC3 へのパケットを受け取ると あて先 MAC アドレスを書き換えた上 で PC3 へ再転送させます。
↑図6：ルータも ARP から PC3 の MAC アドレスを得る
ただ、毎回通信のたびに ARP Request をブロードキャストしていては無駄なネットワーク負荷をかけてしまうため、MAC アドレス情報を 「ARP テーブル」 に保存します。次回の通信からはこの ARP テーブルを参照しながら MAC アドレスを参照して通信効率を高めます。
↑図7：ARP テーブル
ARP のメモは以上です。でもどうして ARP をメモしたのか？ 疑問に思っていただけるとありがたいのですが、実は IPv4 で MAC アドレス解決に使われていた ARP は IPv6 では撤廃されます。では IPv6 ではどうやって MAC アドレスを解決するのか。それは今回メモする Neighbor Discovery (ICMPv6) が IPv6 で使われる MAC アドレス解決のプロトコル だからです。
Neighbor Discovery
ではそろそろ Neighbor Descovery についてメモしていきます。
Neighbor Descovery は 「近隣探索プロトコル」 とも呼ばれ、名前の通り近隣ノード（ネットワークに接続された PC や機器など）の情報を収集するものですが、IPv6 の世界ではこの収集した情報を基に 「IPv6 アドレス環境を自動生成」 することができます。
IPv6 では IPv4 と同じく DHCP を使ったステートフルな IPv6 アドレスの自動構成ができますが、それとは別に Neighbor Discovery からもステートレスな IPv6 アドレスを自動構成できます。これは IPv4 には無い仕組みで、クライアントが RA という情報をリンク内でやり取りすることで、リンク内に DHCP サーバが存在しなくとも自動的に IPv6 を生成してくれます。高度な IPv6 APIPA といったところでしょうか。
↑図8：DHCP と RA
Neighbor Descovery は以下の5つを実現し、これら情報のやり取りには ICMPv6 メッセージを使っています。
1．ルータ要請 (Router Solicitation - RS)
2．ルータ広告 (Router Advertisement - RA)
3．ネイバー要請 (Neighbor Solicitation - NS)
4．ネイバー広告 (Neighbor Advertisement - NA)
5．リダイレクト (Redirect) ← 今回は全力でスルーします
また ICMPv6 のタイプ番号は以下の通りです。
1．RS (Type = 133)
2．RA (Type = 134)
3．NS (Type = 135)
4．NA (Type = 136)
5．Redirect (Type = 137) ← 今回は(ry
↑図9：ICMPv6 の基本フォーマット
ルータ広告 (RA)
Type 133 の RS を飛ばして、とにかく一番重要（と思われる） RA からメモしてしまいます。
RA (Router Advertisement) は、リンク内または隣接ノード内のプレフィックスや MTU 値などの情報が記載された ICMPv6 メッセージです。ルータはこの RA メッセージを定期的に 「全ノードマルチキャストアドレス (FF02::1)」 で送信していますが、後にメモする RS を受け取った場合に限り、RS 送信元へユニキャスト通信の RA を送り返します。
↑図10：IPv6 ではマルチキャストを使う
また、前項でもメモしましたように、IPv6 では RA を基に IPv6 アドレスを自動生成しますが、その他にもデフォルトルータ （IPv4 でいう Default Gateway） の選出、リンク内の MTU 自動設定やリンクローカル通信範囲の識別なども構成できます。RA にはこれら構成に必要な情報が記載されています。
↑図11:RA の ICMPv6 フォーマット
※図11は Wireshark と RFC 4861 の仕様書を比較しながら描いた ICMPv6 フォーマットです。
「プロトコルは沢山あんだ！全部覚えられねぇよ！」 と思うかもしれませんが、まさにその通りだと思います。僕自身、プロトコルごとのフォーマットを覚えられるほどの記憶力はありませんし、そもそも覚えたくないっす。。ただ、今までノーマークだったプロトコルのフォーマットを今回初めて覗いたところ、「なるほど！あのルータに設定したパラメータはこういう意味だったのか！」 と気づかされることがありました。
今後新しいプロトコルを扱うときは、今回のように一通りフォーマットを確認する“癖”をつけたいと思います。この“癖”が身に着くまで、このメモのようにフォーマットを毎回図化していく予定です。なんかフォーマットを描くと 「わかってる人」 みたいでカックイイ気がするけど、僕はそこまで分かっていないから無問題（笑）。
さて RA の話題に戻りましょう。
リンク内の通信に必要な情報は、ICMPv6 フォーマットの オプション部分 に格納されて各ノードに届けられます。オプションのフォーマットは以下の通りで、TYPE フィールド内の数値 によってオプションの内容が変わっていきます。この仕組みはどのフォーマットでも共通しているようですね。
↑図12：ND オプション基本フォーマット
また ND メッセージのオプションは、以下の5種類があるようです。
1．送信元 MAC アドレス
2．送信先 MAC アドレス
3．プレフィックス情報
4．リダイレクトヘッダー ← 大人の事情によりガン無視
5．MTU
RA では、主に 「1.3.5」 のオプションを使うことになりそうです。
「Type 1．送信元 MAC アドレス」 ですが、ルータはリンク内のクライアントに自分自身の存在を知らせる必要があります。そのときに自身の MAC アドレスを送る必要があることから、RA では Type 1 を扱います。
↑図13：Type1 自分自身を通知する送信元 MAC アドレス
あと RFC 4861 によると、プレフィックス情報と MTU 値を扱うのは RA だけのようで、オプション3.5は RA 専用のオプションと考えて問題ないかもしれません。
↑図14：Type5 リンク内の MTU 値
↑図15：Type3 リンク内のプレフィックス
あと Flag フィールドに関しての小さなメモ。図15 の Type3 の Flag は 8bit のフィールドが描かれてますが、これは 8bit 分の Flag があるわけではなく、Flag 用に 8bit フィールドを確保しているだけで、余ったところを 0 で埋めているようですね。たぶん従来のプロトコルでも同じように使われてきたのだろうけど、意識してなかったからちょっと新鮮。。
↑図16：Flag フィールドは使わないところを 0 で予約する
RA のフォーマットや役割に関しては、こんなところでしょうか。
ざっくり言ってしまえば、RA は ICMPv6 パケットのオプション1.3.5部に色々な情報が格納されていて、クライアントはこれを基に IPv6 アドレスを EUI-64 といった仕組みを使って自動生成したり、またそれら以外の仕組みを実現しています。これら詳細のメモは別に機会で取り上げてみようと思います。
ルータ要請 (RS)
RS (Router Solicitation) は、クライアントがルータへ送る RA のリクエストメッセージです。ICMPv6 の Type 133 で使われます。
↑図17：RS の ICMPv6 フォーマット。中身少なすぎ。。
クライアントは RA を基に IPv6 アドレスを自動生成などを行うため、なんらかの方法で RA を受信する必要があります。ルータは RA を FF02::1 で定期的にマルチキャストしていますので、クライアントは待てばいつかは RA を受信できますが、定期的に送られてくる RA の受信を待てない場合などは、クライアントは意図的に RS をルータに対して FF02::2 でキャストします。ルータは RS を受け取ると RA を返す 仕組みになっており、RS を送信したクライアントは RA を早めに受け取ることができます。DHCP リクエストメッセージみたいですね。
↑図18：マルチキャストアドレスに参加したときなどに RS 送信
また、RS のオプションは図13の Type1 、すなわち送信元 MAC アドレスが格納されます。基本的に RA は FF02::1 で送られますが、オプション入りの RS に対するレスポンスは、このオプション内の MAC アドレスを参考に RA をユニキャストするようです（図10の下）。
あと簡単に、マルチキャストについてメモします。
IPv4 の世界では全ノードに対しての通信を ブロードキャスト通信（255.255.255.255） が担当していましたが、IPv6 ではブロードキャストが撤廃され、大幅に進化したマルチキャストが代替になりました。また 「ルータ→クライアント」 に対するメッセージは 「全ノードマルチキャスト(FF02::1)」 と呼ばれ、「クライアント→ルータ」 に対するメッセージを 「全ルータマルチキャスト(FF02::2)」 と呼びます。
ただ、個人的には疑問もあります。
FF02::2 でキャストしたパケットを受け取ったクライアントは、そのパケットを どの段階で破棄 するのでしょうか。もしブロードキャストのように CPU レベルの破棄ではなく、NIC などの下位レイヤーで破棄されるのでしたら、ルータとクライアントでマルチキャストを使い分けることは、とても賢い仕組みかもしれませんね。この辺りは別の機会で調査してみようと思います。
ネイバー要請 (NS)
RA と RS はルータがらみの ICMPv6 メッセージでしたが、Type 135 と 136 からは 「ネイバー (Neighbor)」 という言葉が出てきます。ネイバーとは、IPv6 の世界でいうと近隣のノードを表しますが、英単語的にも 【Neighbor / 隣人・隣り合う】 といった意味があるようです。英単語に一つ詳しくなったわい。(^ω^ )
そんな NS (Neighbor Solicitation) はリンク内に属するノードに対して、ARP や アドレス重複検出 を処理するために必要なパケットを流す役割を担います。ICMPv6 の TYPE は 135 です。アドレス重複検出 は、IPv6 アドレスを自動生成する際に重複を防ぐための仕組みです。これに関しては EUI-64 のメモと一緒に扱う予定なので、今回は取り上げないことにします。
↑図19：リンク内でアドレスが重複しないような仕組み
ICMPv6 パケットとしては Target Address という 128bit フィールドがあり、この中に MAC アドレスを調べたい相手の IPv6 アドレスを格納するようです。ただこの IPv6 アドレスは 「Solicited-node Multicast Address」 といったマルチキャストアドレスが入ることがあります。残念ですが今の僕はマルチキャストアドレスの概念をまだ理解していないので、Solicited-node Multicast Address に関しては別の機会に取り上げてみたいと思います。
↑図20：NS のフォーマット
オプションは図13の Type1 、送信元 MAC アドレスが格納されます。ARP のような MAC アドレスを解決するときは、レスポンス用のアドレスとしてこのオプションを付加しますが、まだ送信元クライアントの IPv6 アドレスが生成されていない（アドレス重複解決）ときには、このオプションは使わないようです。確かにこのオプションがないときは、Packet の送信元アドレスも 「::」 になってました。
ネイバー広告 (NA)
NA (Neighbor Advertisement) は、NS に対するレスポンスメッセージで ICMPv6 の Type 136 が使われます。NA のフォーマットは NS とほぼ同じでした。しいて言うなら Reserved の Flag 有無に差があったくらいです。…ってか、ここでようやく気づいたんだけどフォーマットって結構使い回して（雛形があるという意味で）いるんですかね。もし使いまわしているのなら、Reserved の意味が少し理解できたかも。。
↑図21：NA フォーマット。NS の Reserved にフラグが足されたイメージ
NA の ARP 動作の場合、または送信元 MAC アドレスが変更になった場合などには、オプションの Type2 に送信元 MAC の値が格納された ICMPv6 メッセージがキャストされます。自発的に送る場合は FF01::1 で、NS のレスポンス動作としてはユニキャストでの送信がされるようです。
↑図22：Type2 ARP 動作のレスポンス
と、おそらく ND に関しての大まかなイメージはコレくらいの理解でいいと思います。
ただ文中にも書きましたが、マルチキャストの種類や仕組み、EUI-64 での IPv6 アドレス自動生成、ガン無視した Redirect メッセージやアドレス重複 (DAD) の仕組みなどなど、まだまだ理解すべき課題はたくさん残っています。今回はそれらを理解するための下準備だと思いながらメモしましたが、なんとまぁ我ながらよくこんなに図を描いたものだ（笑）。
最後に
今回の記事をメモした中での 「一番の収穫」 は、IPv6 の仕組みを理解した……こともありますが、それよりも 英語能力の重要さを肌で感じたこと が一番の収穫かもしれません。
コンピュータ系の情報は日本より海外の方が豊富ですから、英語が読めない人は IT 業界ではちょい不利なんですよね。。「コンピュータに強い人が英語を学ぶよりも、英語に強い人がコンピュータを学んだ方が IT 業界では将来性がある」 という言葉を聞いたことがあるくらいです。
ちなみに僕は アリエナイくらい英語ができませんｗｗｗ
IT エンジニア以前に、人として必要な最低限の英語能力も持ち合わせておらず、RFC 4861 の資料を読んでも 1厘 も理解できませんでした。。それでも英語に憧れるアメリカコンプレックスの僕は、RFC 4861 の資料に目を通したときに （あっ、ここの単語は分かるわウレシイワｗｗｗ） という心境になり、そこまで苦ではありませんでした。
【Advertisement / 広告】
【Neighbor / 隣人・隣り合う】
【Solicitation / 勧誘】
と、覚えた英単語が増えたことの方が、実は IPv6 の仕組みを覚えたことよりも嬉しかったりします。というわけで、もしかしたらこのブログでは英語の勉強も兼用して 「カタカナ文字を英語で書く」 ことになるかもしれません。ただでさえ見づらい Blog が更に見づらくなるかもしれませんが、Infrastructure まわりの Professional になるためには大切であるとの判断でございます。
……なんかルー○柴っぽくなってきた（笑） m9っ｀Д´）
そんな IPv6 ですが、僕の勤める病院では 「院内ネットワークをオール IPv6 化にしよう！」 というプランが持ち上がっています。ただでさえ IT 化が遅れている医療業界なのに、院内 LAN をオール IPv6 にするとは…… IT 好きの院長先生には心から脱帽します。
―――が！！
（院内を IPv6 化かとか、スゲーなぁ…）
なんて思っている暇はなくって、僕もその IPv6 化プロジェクトの一員 に任命されています。 IPv6 が身近になっているどころか、むしろ IPv6 を扱うことが仕事になりつつあり、ブログのタイトルが 「IPv6 まわりのプロになりたい」 になる日が近くなるかもしれませんね。。（笑）
そんな IPV6 についての記事第一弾は 「Neighbor Discovery」 についてメモしたいと思います。
ICMP
Neighbor Discovery は ICMPv6 を使っていますので、まずは簡単に ICMP についてメモします。
IPv4 の世界には ICMP (Internet Control Message Protocol) というプロトコルが存在します。これは主に IP パケットのエラー通知を担当するプロトコルです。
この ICMP の特性を利用したものに Ping や Traceroute コマンドがあります。ネットワークの疎通を確認するための Ping。宛先ノードへの通信経路を確認するための Traceroute。ネットワークに馴染みのある方でしたら、一度は活用されたことがあると思います。ちなみに僕は「ピング」と読む派です（笑）。
↑図1：Ping コマンド。これ無いと生きていけない
↑図2：Traceroute コマンドは Linux。Tracert コマンドは Windows
このように IPv4 の ICMP は、エラー通知や経路状況の把握にとても重宝するプロトコルで、IP の通信には無くてはならない存在です。そんな ICMP は IPv6 では ICMPv6 という名でバージョンアップされましたが、ICMP とは比較にならないほど ICMPv6 は多機能になっています。
たぶんですが、IPv6 をマスターするには ICMPv6 の理解が欠かせない と思います。それに ICMPv6 を理解すれば、芋づる式に色々な機能まで理解できるはず （と信じてる…） ですから、ここは押さえておきたいですね。
ARP
さっそく Neighbor Discovery について書こう……と思いますが、その前にちょっと ARP (Address Resolution Protocol) についてメモします。
ARP は MAC アドレスを調べ上げるプロトコルで Ethernet で使われます。ある PC に対してデータを送信したいとき、あて先の IP アドレスを知っていれば通信できそうですが、実は MAC アドレスも知らなければ通信ができません。IP アドレスはレイヤー3の世界で使われる位置情報ですが、MAC アドレスはレイヤー2の位置情報。Ethernet ではこの2つのアドレスが必要不可欠です。
↑図3：パケットには IP アドレス以外にも位置情報が必要
※ 上の図にもありますように、TCP/IP でやり取りするデータ全体のことを パケット と表記していましたが、これでは OSI 参照モデルのレイヤー3の PDU とかぶってしまうことから、OSI 参照モデルの PDU に関しては 英語表記 に変えました。例えば、ネットワークセグメントを表すときは 「セグメント」 と書きますが、レイヤー4の PDU では 「Segment」 と書き、またネットワークで扱うデータ（小包にたとえるアレ）のことを 「パケット」 と呼ぶ一方、レイヤー3 の PDU では 「Packet」 と書いていきます。概念を理解するには、区別化した方がいいと思っての判断です。ただでさえ読みづらい文章が更に読みづらくなりますが、そんなことを気にしてはいけません（笑）。
話を戻しますが、相手にパケットを届かせるためには IP アドレスの他に MAC アドレスが必要です。以下に MAC アドレスと ARP の関係をパケットの流れを追いながらメモします。「PC1 がそれぞれ PC2 と PC3 へパケットを送る流れ」 を例に挙げます。
まず PC1 から PC2 へパケットを送り出すときですが、そのパケットには PC1 の IP アドレスと MAC アドレスが送信元アドレスとして書き込まれます。またこれと同時に、あて先となる PC2 の IP アドレスと MAC アドレスも、それぞれの PDU に書き込まれます。このとき PC1 が PC2 の MAC アドレスを知っていれば問題ありませんが、もし PC2 の MAC アドレスを知らない 場合は Frame のあて先に MAC アドレスを書き込めませんので、前述したように通信ができません。
↑図4：IP アドレス以外にも MAC アドレスが必要
そこで使われるのが ARP です。PC1 が PC2 へ「PC2 の MAC アドレス教えてください」（ARP Request） といった ARP メッセージを投げます。これを PC2 が受け取ると 「自分の MAC アドレスは○○です」（ARP Reply） とアドレス情報を記載して PC1 へ送り返します。この ARP Reply を受け取ってようやくあて先 MAC アドレスに PC2 の情報を書き込むことができ、通信準備が整います。
ちなみに ARP Reply は双方の MAC アドレスを知っていることからユニキャスト通信ができますが、前者の ARP Request はそもそもあて先 MAC アドレスを知らないため、ここではブロードキャスト通信が使われます （Frame ではは FF:FF:FF:FF:FF:FF がブロードキャスト）。
↑図5：ARP で相手の MAC アドレスを取得する
また PC1 から PC3 への通信では PC3 はネットワークセグメントが違うため、あて先 MAC アドレスはルータ （または L3 スイッチ） が指定されます。これは ARP （ブロードキャスト） はルータを越えられないためです。ルータは PC3 へのパケットを受け取ると あて先 MAC アドレスを書き換えた上 で PC3 へ再転送させます。
↑図6：ルータも ARP から PC3 の MAC アドレスを得る
ただ、毎回通信のたびに ARP Request をブロードキャストしていては無駄なネットワーク負荷をかけてしまうため、MAC アドレス情報を 「ARP テーブル」 に保存します。次回の通信からはこの ARP テーブルを参照しながら MAC アドレスを参照して通信効率を高めます。
↑図7：ARP テーブル
ARP のメモは以上です。でもどうして ARP をメモしたのか？ 疑問に思っていただけるとありがたいのですが、実は IPv4 で MAC アドレス解決に使われていた ARP は IPv6 では撤廃されます。では IPv6 ではどうやって MAC アドレスを解決するのか。それは今回メモする Neighbor Discovery (ICMPv6) が IPv6 で使われる MAC アドレス解決のプロトコル だからです。
Neighbor Discovery
ではそろそろ Neighbor Descovery についてメモしていきます。
Neighbor Descovery は 「近隣探索プロトコル」 とも呼ばれ、名前の通り近隣ノード（ネットワークに接続された PC や機器など）の情報を収集するものですが、IPv6 の世界ではこの収集した情報を基に 「IPv6 アドレス環境を自動生成」 することができます。
IPv6 では IPv4 と同じく DHCP を使ったステートフルな IPv6 アドレスの自動構成ができますが、それとは別に Neighbor Discovery からもステートレスな IPv6 アドレスを自動構成できます。これは IPv4 には無い仕組みで、クライアントが RA という情報をリンク内でやり取りすることで、リンク内に DHCP サーバが存在しなくとも自動的に IPv6 を生成してくれます。高度な IPv6 APIPA といったところでしょうか。
↑図8：DHCP と RA
Neighbor Descovery は以下の5つを実現し、これら情報のやり取りには ICMPv6 メッセージを使っています。
1．ルータ要請 (Router Solicitation - RS)
2．ルータ広告 (Router Advertisement - RA)
3．ネイバー要請 (Neighbor Solicitation - NS)
4．ネイバー広告 (Neighbor Advertisement - NA)
5．リダイレクト (Redirect) ← 今回は全力でスルーします
また ICMPv6 のタイプ番号は以下の通りです。
1．RS (Type = 133)
2．RA (Type = 134)
3．NS (Type = 135)
4．NA (Type = 136)
5．Redirect (Type = 137) ← 今回は(ry
↑図9：ICMPv6 の基本フォーマット
ルータ広告 (RA)
Type 133 の RS を飛ばして、とにかく一番重要（と思われる） RA からメモしてしまいます。
RA (Router Advertisement) は、リンク内または隣接ノード内のプレフィックスや MTU 値などの情報が記載された ICMPv6 メッセージです。ルータはこの RA メッセージを定期的に 「全ノードマルチキャストアドレス (FF02::1)」 で送信していますが、後にメモする RS を受け取った場合に限り、RS 送信元へユニキャスト通信の RA を送り返します。
↑図10：IPv6 ではマルチキャストを使う
また、前項でもメモしましたように、IPv6 では RA を基に IPv6 アドレスを自動生成しますが、その他にもデフォルトルータ （IPv4 でいう Default Gateway） の選出、リンク内の MTU 自動設定やリンクローカル通信範囲の識別なども構成できます。RA にはこれら構成に必要な情報が記載されています。
↑図11:RA の ICMPv6 フォーマット
※図11は Wireshark と RFC 4861 の仕様書を比較しながら描いた ICMPv6 フォーマットです。
「プロトコルは沢山あんだ！全部覚えられねぇよ！」 と思うかもしれませんが、まさにその通りだと思います。僕自身、プロトコルごとのフォーマットを覚えられるほどの記憶力はありませんし、そもそも覚えたくないっす。。ただ、今までノーマークだったプロトコルのフォーマットを今回初めて覗いたところ、「なるほど！あのルータに設定したパラメータはこういう意味だったのか！」 と気づかされることがありました。
今後新しいプロトコルを扱うときは、今回のように一通りフォーマットを確認する“癖”をつけたいと思います。この“癖”が身に着くまで、このメモのようにフォーマットを毎回図化していく予定です。なんかフォーマットを描くと 「わかってる人」 みたいでカックイイ気がするけど、僕はそこまで分かっていないから無問題（笑）。
さて RA の話題に戻りましょう。
リンク内の通信に必要な情報は、ICMPv6 フォーマットの オプション部分 に格納されて各ノードに届けられます。オプションのフォーマットは以下の通りで、TYPE フィールド内の数値 によってオプションの内容が変わっていきます。この仕組みはどのフォーマットでも共通しているようですね。
↑図12：ND オプション基本フォーマット
また ND メッセージのオプションは、以下の5種類があるようです。
1．送信元 MAC アドレス
2．送信先 MAC アドレス
3．プレフィックス情報
4．リダイレクトヘッダー ← 大人の事情によりガン無視
5．MTU
RA では、主に 「1.3.5」 のオプションを使うことになりそうです。
「Type 1．送信元 MAC アドレス」 ですが、ルータはリンク内のクライアントに自分自身の存在を知らせる必要があります。そのときに自身の MAC アドレスを送る必要があることから、RA では Type 1 を扱います。
↑図13：Type1 自分自身を通知する送信元 MAC アドレス
あと RFC 4861 によると、プレフィックス情報と MTU 値を扱うのは RA だけのようで、オプション3.5は RA 専用のオプションと考えて問題ないかもしれません。
↑図14：Type5 リンク内の MTU 値
↑図15：Type3 リンク内のプレフィックス
あと Flag フィールドに関しての小さなメモ。図15 の Type3 の Flag は 8bit のフィールドが描かれてますが、これは 8bit 分の Flag があるわけではなく、Flag 用に 8bit フィールドを確保しているだけで、余ったところを 0 で埋めているようですね。たぶん従来のプロトコルでも同じように使われてきたのだろうけど、意識してなかったからちょっと新鮮。。
↑図16：Flag フィールドは使わないところを 0 で予約する
RA のフォーマットや役割に関しては、こんなところでしょうか。
ざっくり言ってしまえば、RA は ICMPv6 パケットのオプション1.3.5部に色々な情報が格納されていて、クライアントはこれを基に IPv6 アドレスを EUI-64 といった仕組みを使って自動生成したり、またそれら以外の仕組みを実現しています。これら詳細のメモは別に機会で取り上げてみようと思います。
ルータ要請 (RS)
RS (Router Solicitation) は、クライアントがルータへ送る RA のリクエストメッセージです。ICMPv6 の Type 133 で使われます。
↑図17：RS の ICMPv6 フォーマット。中身少なすぎ。。
クライアントは RA を基に IPv6 アドレスを自動生成などを行うため、なんらかの方法で RA を受信する必要があります。ルータは RA を FF02::1 で定期的にマルチキャストしていますので、クライアントは待てばいつかは RA を受信できますが、定期的に送られてくる RA の受信を待てない場合などは、クライアントは意図的に RS をルータに対して FF02::2 でキャストします。ルータは RS を受け取ると RA を返す 仕組みになっており、RS を送信したクライアントは RA を早めに受け取ることができます。DHCP リクエストメッセージみたいですね。
↑図18：マルチキャストアドレスに参加したときなどに RS 送信
また、RS のオプションは図13の Type1 、すなわち送信元 MAC アドレスが格納されます。基本的に RA は FF02::1 で送られますが、オプション入りの RS に対するレスポンスは、このオプション内の MAC アドレスを参考に RA をユニキャストするようです（図10の下）。
あと簡単に、マルチキャストについてメモします。
IPv4 の世界では全ノードに対しての通信を ブロードキャスト通信（255.255.255.255） が担当していましたが、IPv6 ではブロードキャストが撤廃され、大幅に進化したマルチキャストが代替になりました。また 「ルータ→クライアント」 に対するメッセージは 「全ノードマルチキャスト(FF02::1)」 と呼ばれ、「クライアント→ルータ」 に対するメッセージを 「全ルータマルチキャスト(FF02::2)」 と呼びます。
ただ、個人的には疑問もあります。
FF02::2 でキャストしたパケットを受け取ったクライアントは、そのパケットを どの段階で破棄 するのでしょうか。もしブロードキャストのように CPU レベルの破棄ではなく、NIC などの下位レイヤーで破棄されるのでしたら、ルータとクライアントでマルチキャストを使い分けることは、とても賢い仕組みかもしれませんね。この辺りは別の機会で調査してみようと思います。
ネイバー要請 (NS)
RA と RS はルータがらみの ICMPv6 メッセージでしたが、Type 135 と 136 からは 「ネイバー (Neighbor)」 という言葉が出てきます。ネイバーとは、IPv6 の世界でいうと近隣のノードを表しますが、英単語的にも 【Neighbor / 隣人・隣り合う】 といった意味があるようです。英単語に一つ詳しくなったわい。(^ω^ )
そんな NS (Neighbor Solicitation) はリンク内に属するノードに対して、ARP や アドレス重複検出 を処理するために必要なパケットを流す役割を担います。ICMPv6 の TYPE は 135 です。アドレス重複検出 は、IPv6 アドレスを自動生成する際に重複を防ぐための仕組みです。これに関しては EUI-64 のメモと一緒に扱う予定なので、今回は取り上げないことにします。
↑図19：リンク内でアドレスが重複しないような仕組み
ICMPv6 パケットとしては Target Address という 128bit フィールドがあり、この中に MAC アドレスを調べたい相手の IPv6 アドレスを格納するようです。ただこの IPv6 アドレスは 「Solicited-node Multicast Address」 といったマルチキャストアドレスが入ることがあります。残念ですが今の僕はマルチキャストアドレスの概念をまだ理解していないので、Solicited-node Multicast Address に関しては別の機会に取り上げてみたいと思います。
↑図20：NS のフォーマット
オプションは図13の Type1 、送信元 MAC アドレスが格納されます。ARP のような MAC アドレスを解決するときは、レスポンス用のアドレスとしてこのオプションを付加しますが、まだ送信元クライアントの IPv6 アドレスが生成されていない（アドレス重複解決）ときには、このオプションは使わないようです。確かにこのオプションがないときは、Packet の送信元アドレスも 「::」 になってました。
ネイバー広告 (NA)
NA (Neighbor Advertisement) は、NS に対するレスポンスメッセージで ICMPv6 の Type 136 が使われます。NA のフォーマットは NS とほぼ同じでした。しいて言うなら Reserved の Flag 有無に差があったくらいです。…ってか、ここでようやく気づいたんだけどフォーマットって結構使い回して（雛形があるという意味で）いるんですかね。もし使いまわしているのなら、Reserved の意味が少し理解できたかも。。
↑図21：NA フォーマット。NS の Reserved にフラグが足されたイメージ
NA の ARP 動作の場合、または送信元 MAC アドレスが変更になった場合などには、オプションの Type2 に送信元 MAC の値が格納された ICMPv6 メッセージがキャストされます。自発的に送る場合は FF01::1 で、NS のレスポンス動作としてはユニキャストでの送信がされるようです。
↑図22：Type2 ARP 動作のレスポンス
と、おそらく ND に関しての大まかなイメージはコレくらいの理解でいいと思います。
ただ文中にも書きましたが、マルチキャストの種類や仕組み、EUI-64 での IPv6 アドレス自動生成、ガン無視した Redirect メッセージやアドレス重複 (DAD) の仕組みなどなど、まだまだ理解すべき課題はたくさん残っています。今回はそれらを理解するための下準備だと思いながらメモしましたが、なんとまぁ我ながらよくこんなに図を描いたものだ（笑）。
最後に
今回の記事をメモした中での 「一番の収穫」 は、IPv6 の仕組みを理解した……こともありますが、それよりも 英語能力の重要さを肌で感じたこと が一番の収穫かもしれません。
コンピュータ系の情報は日本より海外の方が豊富ですから、英語が読めない人は IT 業界ではちょい不利なんですよね。。「コンピュータに強い人が英語を学ぶよりも、英語に強い人がコンピュータを学んだ方が IT 業界では将来性がある」 という言葉を聞いたことがあるくらいです。
ちなみに僕は アリエナイくらい英語ができませんｗｗｗ
IT エンジニア以前に、人として必要な最低限の英語能力も持ち合わせておらず、RFC 4861 の資料を読んでも 1厘 も理解できませんでした。。それでも英語に憧れるアメリカコンプレックスの僕は、RFC 4861 の資料に目を通したときに （あっ、ここの単語は分かるわウレシイワｗｗｗ） という心境になり、そこまで苦ではありませんでした。
【Advertisement / 広告】
【Neighbor / 隣人・隣り合う】
【Solicitation / 勧誘】
と、覚えた英単語が増えたことの方が、実は IPv6 の仕組みを覚えたことよりも嬉しかったりします。というわけで、もしかしたらこのブログでは英語の勉強も兼用して 「カタカナ文字を英語で書く」 ことになるかもしれません。ただでさえ見づらい Blog が更に見づらくなるかもしれませんが、Infrastructure まわりの Professional になるためには大切であるとの判断でございます。
……なんかルー○柴っぽくなってきた（笑） m9っ｀Д´）
スポンサーサイト
