ARP (読み方:アープ) とは、IP アドレスに紐付く MAC アドレスを知るために利用するプロトコルです。Ethernet 上で IP 通信をするためには必須のプロトコルです。
ARP の概要
端末 A IP アドレス = 192.168.5.11 , MAC アドレス = 01:23:45:67:89:aa) から同一セグメント内の端末 C (IP アドレス = 192.168.5.13 , MAC アドレス = 01:23:45:67:89:ab) に通信する場合を考えます。
このとき、端末 A は宛先の IP アドレスを 192.168.5.13 と指定しますが、宛先の MAC アドレスが分からないので、このままではレイヤー 2 通信が出来ません。
そこで、このとき端末 A は ARP 要求をブロードキャストします。ARP 要求の中には自身の IP アドレスと MAC アドレス情報、および、端末 C の IP アドレス 192.168.5.13 が含まれいます。端末 C は、その ARP 要求を受け取ると、ARP 応答に自分の MAC アドレス (01:23:45:67:89:ab) を格納して、L2 ユニキャストで端末 A に返します。
ARP 応答を受け取った端末 A は自身の内部に持つ ARP テーブルに、192.168.5.13 と 01:23:45:67:89:ab の組合せを記憶すると同時に、LAN インタフェースから、渡したかった Ethernet フレームを端末 C に向けて送出します。
以下にイメージ図を示します。
なお、あまり知られていませんが、ARP 応答を受け取ったときだけでなく、ARP 要求を受け取ったときにも ARP テーブルの更新が実施されます。
つまり、端末 A が ARP 要求をブロードキャストすると、ARP 応答をした端末 C はもちろんのこと、同セグメントにいる他の全ての端末も、端末 A の IP アドレス、MAC アドレスの組み合わせを記憶します。
ARPの種類
ARP には以下の種類があります。
- 通常の ARP・・・上記の説明の通り、IP 機器が他の IP 機器への通信が必要なタイミングで ARP 要求をブロードキャストし、その IP を持つ機器が ARP 応答をユニキャストで返信します。
- Gratuitous-ARP・・・IP 機器がその宛先に通信するタイミングではなく、自らが積極的に相手に自身の IP アドレスを周知するために ARP を送信します。詳しくはこちらを参照下さい。
- Proxy-ARP・・・ARP 要求を受信したIP機器が、自身がその IP を付与されていないが、ルート情報を持っている場合に自身の MAC アドレスを ARP 応答します。詳しくはこちらを参照下さい。
- Reverse-ARP・・・MAC アドレスを元に、IP アドレスを配布する。ただし、この機能は DHCP サーバに置き換わっているため、今はまず使われていません。
ARP テーブル (ARP キャッシュ) のキャッシュ保持時間
一度 ARP 応答により受信した IP/MAC アドレス紐付け情報は、一定時間持ち続けます。
Windows および Linux の実装としては、15 秒から 45 秒の範囲でランダムに決まった時間を保持します。これは IPv6 の ARP 相当である NDP に関する仕様を定めた RFC 4861 に準拠する動作です。
Windows に関しては Micrisoft のブログでその旨が書かれています。
Linux に関しては以下のカーネルパラメータにて定められています。
[root@localhost ~]# sysctl net.ipv4.neigh.default.base_reachable_time_ms
net.ipv4.neigh.default.base_reachable_time_ms = 30000
このパラメータの 0.5 倍から 1.5 倍の範囲でキャッシュを保持するというのが man ページに書かれています。
なので Wireshark 等でパケットキャプチャすると、NW 機器に比べてホストからの『who has <ip>? tell <ip>』という ARP 要求が大量に表示され、多いと感じることもあるかと思います。もしくはそのセグメント内に端末が多すぎて、ARP テーブルが溢れている可能性もあります。
もう少し具体的なシナリオについて、以下で紹介しています。
NW 機器においてはメーカによってまちまちのようで、Cisco のデフォルトはかなり長めで 4 時間となっています。ただし、これは前述の Gratuitous-ARP という MAC アドレス更新を周知する仕組みが働く前提でこのような長い時間を取っています。
WindowsでのARP関連の操作
Windows 端末で ARP テーブルを確認するには、コマンドプロンプトで以下を打ちます。
C:\> arp -a
また、ARPテーブルをクリアするには以下を打ちます。
C:\> arp -d *
ARPのフォーマット
ARP プロトコルのフォーマットを以下に示します。イーサネットを利用する場合、 Ethernet のタイプフィールドは "Ox0806" となります。
ハードウェアタイプ
ARP は、イーサネットだけでなく、様々なレイヤー 2 通信をサポートします。ハードウェアタイプフィールドはどのレイヤー 2 通信を 利用するかを表します。
以下に ARP のハードウェアタイプ値とそれに対応するプロトコルを示します。
ハードウェアタイプ | プロトコル |
Ox0001 | Ethernet |
Ox0003 | Amateur Radio AX.25 |
Ox0004 | トークンリング |
Ox0006 | IEEE802.1x |
Ox000F | フレームリレー |
Ox0010 | ATM |
ARP 要求元プロトコル
ARP は、IP だけでなく様々なレイヤー 3 通信をサポートします。ARP 要求元プロトコルフィールドはどのレイヤー 3 通信を利用するかを 表します。この ARP 要求元プロトコル値とそれに対応するプロトコルは、イーサネットフレームで紹介した"タイプ番号"と同じで、 IPv4 は "Ox0800" となります。
ハードウェアアドレス長
レイヤー 2 通信のアドレスを 8 bit 単位で表します。イーサネットの場合、MAC アドレスの長さである 48 bit を表す "Ox06" が入ります。
プロトコルアドレス長
レイヤー 3 通信のアドレスを 8 bit 単位で表します。IPv4 の場合、IPv4 アドレスの長さである 32 bit を表す "Ox04" が入ります。
オペレーションコード
ARP 要求や ARP 応答などを表現します。ARP 要求は "Ox0001"、ARP 応答は "Ox0002" となります。
以上より、端末Aの ARP 要求と端末Cの ARP 応答をまとめますと、以下のようになります。
Field | 端末AのARP要求 | 端末CのARP応答 | ||
Field値 | 内容 | Field値 | 内容 | |
ハードウェア タイプ | Ox0001 | Ethernet | Ox0001 | Ethernet |
ARP要求元 プロトコル | Ox0800 | IPv4 | Ox0800 | IPv4 |
ハードウェア アドレス長 | Ox06 | 48bit | Ox06 | 48bit |
プロトコル アドレス長 | Ox04 | 32bit | Ox04 | 32bit |
オペレーション コード | Ox0001 | ARP要求 | Ox0002 | ARP応答 |
送信元 ハードウェア アドレス | 0123456789aa | 端末AのMAC アドレス | 0123456789ab | 端末CのMAC アドレス (応答値) |
送信元 IPアドレス | C0A8050b | 端末AのIP アドレス 192.168.5.11 | C0A8050d | 端末CのIP アドレス 192.168.5.13 |
宛先 ハードウェア アドレス | 000000000000 (要求値) | Null | 0123456789aa | 端末AのMAC アドレス |
宛先 IPアドレス | C0A8050d | 端末CのIP アドレス 192.168.5.13 | C0A8050b | 端末AのIP アドレス 192.168.5.11 |
コメント
> 一度 ARP 応答により受信した IP/MAC アドレス紐付け情報は、一定時間持ち続けます。
> WindowsおよびLinuxにおいては、RFC2461 に従い、15秒から45秒の範囲でランダムに決まった時間を保持します。
IPv4のMAC保持時間を15-45秒としている情報の出所を調べて
いました。MSのブログにそんな記述があったのですね。
RFC2461は、IPv6のNDPの動作について書いているので、IPv4には
適用されないはずですが、準用してコードを作っているなんて
MSが書くものだから、混乱させているのですね。
RFCに沿って動いているとは限らないのに・・・・・。
ふぇんさん
コメントありがとうございます。
すみません、誤解を招く書き方をしていました。MSのブログには「Windows Vista以降のARPキャッシュの振る舞いは、IPv6 の NDPに関する仕様である RFC4861 に従います」と書かれています。この辺りのニュアンスが出るように記事を修正させて頂きます。
ご指摘ありがとうございました!
いつも参考にさせていただいております。
>つまり、端末 A が ARP 要求をブロードキャストすると、ARP 応答をした端末 C はもちろんのこと、同セグメントにいる他の全ての端末も、端末 A の IP アドレス、MAC アドレスの組み合わせを記憶します。
とありますが、誤っていませんでしょうか?
↓では「ARP応答を返したPC2だけが書き込みます。一方、PC3とPC4は、このやりとりに関与していないので、ARPテーブルには書き込みません。」とあります。
https://nw.seeeko.com/archives/50559138.html
そこで、Packet TracerとHyper-Vの仮想マシン群で検証をしてみましたが、ARP応答をしなかったPCのARPキャッシュにはARP要求の送信元マシンの情報は登録されませんでした。
>勉強中さん
コメントありがとうございます。
この動作は RFC5944 (https://datatracker.ietf.org/doc/html/rfc5944) に記載されています。正確に言うと、Gratuitous ARP と呼ばれる動作仕様なのですが、フォーマットなどはARPとまったく同じで、動作仕様について再定義したものになります。
—引用—
any node receiving any ARP packet (Request or Reply) MUST update its local ARP cache with the Sender Protocol and Hardware Addresses in the ARP packet
—
間違っているかどうか、というよりかは、この仕様に準拠するか否か、という話ですね。(そういう意味では私の記事は言い切ってしまっていますので、そのご指摘ならその通りです。)
ただ、私が2,3年前に確認した限りでは Windows でも Linux でも HPE スイッチでも更新されていました。
ご参考までに。
>この仕様に準拠するか否か、という話ですね。
そういうことだったのですね。お陰様で理解が深まりました。(RFCまでご提示していただき恐縮するばかりです)
“なお、あまり知られていませんが、ARP 応答を受け取ったときだけでなく、ARP 要求を受け取ったときにも ARP テーブルの更新が実施されます。”
長年NWエンジニアやっていましたが、これは新たな発見でした。ルータ実機でも確認しました。arp要求のブロードキャストを受け取っただけでも更新されるんですね。勉強になりました。ありがとうございました。
k さん、コメントありがとうございます。
私もNWエンジニア8年目くらいに ARP がテーブルに乗らない問題を調査中にたまたま知ったものでして、こういった教科書には出てこない現場ならではの知識って共有されにくいよなぁ、と思ったものでした。
お役に立てたようでよかったです。