ARP は MAC アドレスを調べ上げるプロトコルで Ethernet で使われます。ある PC に対してデータを送信したいとき、あて先の IP アドレスを知っていれば通信できそうですが、実は MAC アドレスも知らなければ通信ができません。IP アドレスはレイヤー3の世界で使われる位置情報ですが、MAC アドレスはレイヤー2の位置情報。Ethernet ではこの2つのアドレスが必要不可欠です。
話を戻しますが、相手にパケットを届かせるためには 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 がブロードキャスト)。
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 にはこれら構成に必要な情報が記載されています。
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の下)。
オプションは図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 のレスポンス動作としてはユニキャストでの送信がされるようです。
と、覚えた英単語が増えたことの方が、実は IPv6 の仕組みを覚えたことよりも嬉しかったりします。というわけで、もしかしたらこのブログでは英語の勉強も兼用して 「カタカナ文字を英語で書く」 ことになるかもしれません。ただでさえ見づらい Blog が更に見づらくなるかもしれませんが、Infrastructure まわりの Professional になるためには大切であるとの判断でございます。