コンテンツにスキップ
宛先の IP アドレスが分かっているのに、同じネットワーク内の相手へフレームを送り出せない。何が足りないのか。

線の上を流れるフレームに書く宛先、つまりハードウェアアドレスが足りない。 RFC 826 は、たいていの上位プロトコルのアドレスは 48 ビット長ではなく、48 ビットの Ethernet アドレスと必ずしも関係を持たないとしている。 ARP で相手に問い合わせて解決する。

ARP の問い合わせと答えは、それぞれどう送られるか。

問い合わせの REQUEST はブロードキャストされ、送信元のハードウェアアドレスと上位プロトコルアドレスを載せる。 答えの REPLY は要求元へユニキャストで返る。

データリンク層は直接つながったネットワークの中の通信を担う。ARP は IP アドレスなどの上位プロトコルアドレスからハードウェアアドレスを解決する。

sequenceDiagram
    participant A as ホスト A(送信したい側)
    participant T as ホスト T(宛先)
    Note over A: T の IP アドレスは分かるが<br/>ハードウェアアドレスを知らない
    A->>T: ARP REQUEST(ブロードキャスト。網内の全ホストが受け取る)
    Note over A,T: 送信元の hw / protocol アドレスと<br/>宛先の protocol アドレスを載せる
    Note over T: 宛先の protocol アドレスが<br/>自分のものだと分かる
    T->>A: ARP REPLY(ユニキャスト)
    Note over A,T: T の hw アドレスが返る。<br/>A はこの対応を表に記録する

RFC 1122 の 4 層のうち最下層が Link Layer で、直接つながっているネットワークの中での通信を担う。 Ethernet や IEEE 802 のように、ネットワークの種類ごとに異なる媒体アクセスの方式がこの層に入る。

RFC 826 は問題をこう述べている。10Mbit の Ethernet は物理的なケーブル上で 48 ビットのアドレスを必要とするが、 たいていの上位プロトコルのアドレスは 48 ビット長ではなく、48 ビットの Ethernet アドレスと 必ずしも何らかの関係を持っているわけでもない。

そこで ARP は、上位プロトコルのアドレス(IP アドレスなど)からハードウェアアドレス (48 ビットの Ethernet アドレスなど)への対応付けを行う。

送信したいホストは、自分のハードウェアアドレスと上位プロトコルアドレス、そして 知りたい相手の上位プロトコルアドレスを載せた REQUEST パケットをブロードキャストする。

ブロードキャストを受け取ったホストのうち、要求されている上位プロトコルアドレスが自分のものであれば、まだ記録が無い場合に 送信元の対応を表へ追加し、パケットのハードウェアアドレスと上位プロトコルアドレスの欄を入れ替えて 自分のアドレスを送信元の欄に置き、要求元のハードウェアアドレス宛てに REPLY を直接返す。 これで要求元は必要な対応を得る。

変換表への新規追加は、要求されている上位プロトコルアドレスが自分のものだったホストだけが行う。 既存の対応の更新は条件付き(Merge_flag)で、ブロードキャストを受け取った全ホストが無条件に記録するわけではない。

前提

関連