Address Resolution Protocol (アドレス解決プロトコル、略称:ARP、アープ)は、与えられたインターネット層アドレス(一般的にはIPv4アドレス)に対応するリンク層アドレス(MACアドレスなど)を発見するために使用される通信プロトコルである。この対応付けは、インターネット・プロトコル・スイートにおける重要な機能である。ARPは、1982年に RFC 826 [1]インターネット標準 STD 37)で定義され、その後 RFC 5227, RFC 5494 により内容のエンハンスが行われている。

ARPは、ネットワーク層技術とデータリンク層技術の様々な組み合わせで実装されている。IEEE 802標準を使用したIPv4Chaosnet英語版DECnetPARC Universal Packet英語版(PUP)、および、FDDIX.25フレームリレーATMなどである。IEEE 802.3イーサネット)およびIEEE 802.11無線LAN)上のIPv4が最も一般的な使用法である。

IPv6ネットワークでは、ARPの機能はICMPv6近隣探索プロトコル(NDP)によって提供される。

操作範囲 編集

ARPはリクエスト=レスポンス・プロトコル英語版であり、メッセージがリンク層プロトコルによってカプセル化される。単一のサブネットワークの内部のみで通信され、ルータを越えてルーティングされることはない。この特性のため、ARPはインターネットプロトコルスイートリンク層に配置される[2]

パケット構造 編集

ARPは、1つのアドレスのみの解決要求または応答を含む単純なメッセージフォーマットを使用する。ARPメッセージのサイズは、リンク層とネットワーク層のアドレスサイズによって異なる。メッセージヘッダで、各層で使用されているネットワークの種類とそれぞれのアドレスのサイズを指定する。メッセージヘッダには、要求(1)と応答(2)のどちらかであるかを示すオペレーションコードが含まれる。パケットのペイロードは、送信側ホストと受信側ホストそれぞれのハードウェアアドレスとプロトコルアドレス、計4つのアドレスで構成されている

イーサネット上で実行されているIPv4ネットワークの場合のARPパケットの構造を次の表に示す。この例では、パケットには送信元ハードウェアアドレス(SHA)と送信先ハードウェアアドレス(THA)用の48ビットフィールドと、対応する送信元プロトコルアドレス(SPA)と送信先プロトコルアドレス(TPA)用の32ビットフィールドがある。この場合のARPパケットサイズは28バイトである。

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14~41
イーサネット宛先アドレス イーサネット送信元アドレス フレームタイプ 下図参照
イーサネットヘッダ ARPの要求と応答
Internet Protocol (IPv4) イーサネット ARP パケット
Octet offset 0 1
0 ハードウェアタイプ(HTYPE)
2 プロトコルタイプ(PTYPE)
4 ハードウェアアドレスサイズ(HLEN) プロトコルアドレスサイズ(PLEN)
6 オペレーション(OPER)
8 送信元ハードウェアアドレス(SHA)
10
12
14 送信元プロトコルアドレス(SPA)
16
18 送信先ハードウェアアドレス(THA)
20
22
24 送信先プロトコルアドレス(TPA)
26
ハードウェアタイプ (HTYPE)
ネットワークプロトコルの種類。イーサネットの場合は1。
プロトコルタイプ (PTYPE)
ARPリクエスト要求が意図するインターネットプロトコル。IPv4の場合、0x0800以降の値。使用される値は、EtherTypeのものを流用する[3][4][5]
ハードウェア長 (HLEN)
オクテットによるハードウェアアドレスの長さ。イーサネットアドレス(MACアドレス)のサイズは6。
プロトコル長 (PLEN)
上位層のプロトコル(PTYPEに指定された上位層プロトコル)が使用するオクテットによるアドレス。IPv4のアドレスサイズは4。
オペレーション
送信者が実行している動作。1は要求、2は返信。
送信元ハードウェアアドレス (SHA)
送信側のメディアアドレス(Media address、MACアドレス)。ARPリクエストでは、要求を送信するホストのアドレスを示す。ARP応答では、要求が探していたホストのアドレスを示す。(必ずしも、仮想メディアのように応答するホストのアドレスではない。)スイッチはMACアドレスを学習するが、このフィールドに注意を払っていないことに注意が必要である。ARP PDUは、イーサネットフレームにカプセル化され、データリンク層(第2層)のデバイスが調べる。
送信元プロトコルアドレス (SPA)
送信元のインターネットワークアドレス(internetwork address、IPアドレス)。
送信先ハードウェアアドレス (THA)
受信側のメディアアドレス(Media address、MACアドレス)。ARPリクエストでは、このフィールドは無視する。ARP応答では、このフィールドは、ARPリクエストを送信したホストのアドレスを示す。
送信先プロトコルアドレス (TPA)
送信先のインターネットワークアドレス(internetwork address、IPアドレス)。

ARPプロトコルのパラメータ値は Internet Assigned Numbers Authority (IANA) によって標準化され、維持されている.[6]

ARPのEtherTypeは0x0806である。これは、イーサネットヘッダ内で使用されてペイロードがARPパケットであることを示すものであり、カプセル化されるARPパケット内に含まれるPTYPEとは別である。

動作 編集

送信元は、送信元のIPアドレス・MACアドレスと送信先のIPアドレスを格納したARPリクエスト(送信先のMACアドレスはALL0)をブロードキャストで送信する。ARPリクエストを受信した各ノードは、格納された送信先IPアドレスが自身のIPアドレスと同一であれば、自身のMACアドレスを格納したARPリプライを送信元に返信する。

ARPキャッシュ 編集

効率を上げるため、多くの機器では一度取得したIPアドレスとMACアドレス間のマッピング情報をARPテーブルARPキャッシュとして保持する。BSD Unix に由来する TCP/IP スタックを実装した機器の多くは、タイムアウト値として 1200秒(20分)を採用している。また、Ciscoの機器ではタイムアウトのデフォルト値として14400秒(4時間)を採用している。キャッシュ情報はWindowsであればコマンドプロンプトから arp -a と入力すれば一覧が見られ、キャッシュ情報はハイフンで分割された6つの16進数で表示される。

ARPプローブ 編集

ARPプローブ(ARP probe)とは、送信者IPアドレス(SPA)をALL0にしたARPリクエストである。この用語は、IPv4 Address Conflict Detection(IPv4アドレス競合検出)仕様( RFC 5227 )で使用されている。この仕様を実装しているホストは、IPv4アドレスの使用を開始する前に(手動設定、DHCP、またはその他の手段でIPアドレスを受信したかどうかにかかわらず)、ARPプローブパケットをブロードキャストで送信して、アドレスが既に使用中かどうかを確認する必要がある[7]

ARPアナウンスメント 編集

ARPは、単純なアナウンスプロトコルとしても使用できる。これは、送信者のIPアドレスまたはMACアドレスが変更されたときに、他のホストのハードウェアアドレスのマッピングを更新するために使用される。このアナウンスメントはgratuitous ARP(GARP)メッセージとも呼ばれ、通常、送信先ハードウェアアドレス(THA)をALL0に設定し、送信元プロトコルアドレスを送信先プロトコルアドレスに格納した(TPA=SPA)ARPリクエストパケットであり、ブロードキャストで送信される。また、送信先アドレスと送信元アドレスの両方に送信元アドレスを格納(TPA=SPA、THA=SHA)したARPリプライをブロードキャストで送信したものもARPアナウンスメントとして使用される。

gratuitous ARPは、ARPリクエスト・ARPリプライのどちらも規格に規定されている正規の手法である[8][9]が、ARPリクエストを使用するほうが望ましい[10]。デバイスによっては、どちらかのGARPを使用するように設定されているものもある[11]

ARPアナウンスは応答を求めることを目的としていない。パケットを受信した他のホストに対し、ARPテーブル内のキャッシュエントリを更新させることを目的としている。ARPの規格では、ARPテーブルがアドレスフィールドから更新される時のみオペレーションコードを解釈することと規定しているので、オペレーションコードは要求と応答のどちらでも良い[12][13][14]

多くのオペレーティングシステムは、起動時にGratuitous ARPを実行する。これは、仮に電源を落としている間にネットワークカードが変更されていた場合に、他のホストのARPキャッシュテーブルにIPアドレスと以前のMACアドレスとのマッピングが残っていると問題が起こるためである。

ARPメディエーション 編集

ARPメディエーション(ARP mediation)とは、接続した回線で異なるアドレス解決プロトコルが使用されている場合(例えば、一方の端がイーサネットで、もう一方の端がフレームリレーであるような場合)、Virtual Private Wire Service(VPWS)を介してレイヤ2アドレスを解決するプロセスである。IPv4では、各プロバイダエッジ英語版(PE)デバイスは、ローカルに接続されているカスタマエッジ英語版(CE)デバイスのIPアドレスを検出し、そのIPアドレスを対応するリモートPEデバイスに配布する。その後、各PEデバイスは、リモートCEデバイスのIPアドレスとローカルPEデバイスのハードウェアアドレスを使用してローカルのARPリクエストに応答する。IPv6では、各PEデバイスはローカルとリモートの両方のCEデバイスのIPアドレスを検出し、次にローカルの近隣探索(ND)パケットと逆近隣探索(IND)パケットを代行受信し、それらをリモートPEデバイスに転送する[15]

Inverse ARP 編集

Inverse Address Resolution ProtocolInverse ARPInARP)は、データリンク層(レイヤ2)アドレスから他のノードのネットワーク層アドレス(IPアドレスなど)を取得するために使用される。これは主にフレームリレーDLCI英語版)やATMで使用される。これらのネットワークでは、仮想回線のレイヤ2アドレスはレイヤ2シグナリングから取得されることがあり、その仮想回線を使用する前に対応するレイヤ3アドレスを使用できるようにする必要がある[16]

ARPはレイヤ3アドレスをレイヤ2アドレスに変換するので、InARPはその逆と表現することができる。InARPはARPのプロトコル拡張として実装されている。ARPと同じパケットフォーマットを使用するが、オペレーションコードは異なる。

Reverse ARP 編集

Reverse Address Resolution Protocol(Reverse ARP、RARP)は、InARPと同様にレイヤ2アドレスをレイヤ3アドレスに変換するために使用する。ただし、InARPでは、要求側は別のノードのレイヤ3アドレスを照会するのに対し、RARPはアドレス設定の際に要求側自体のレイヤ3アドレスを取得するために使用される。RARPは現在ではほぼ使用されていない。RARPはBOOTPに置き換えられ、BOOTPも後にDHCPに置き換えられている[17]

ARPスプーフィングとプロキシARP 編集

 
ARPスプーフィング攻撃が成功した場合、攻撃者は中間者攻撃を行うことができる。

ARPにはネットワーク上のARPリプライを認証する方法がなく、ARPリプライは必要なレイヤ2アドレスを持つシステム以外のシステムから送信される可能性もある。プロキシARP(Proxy ARP)は、ネットワークの設計の一部として、他のネットワークにARP要求があった場合にルータがホストに代わって回答する仕組みであり、NAT環境下において使用される例が多い。これに対して、ARPスプーフィング(ARP spoofing)は、そのシステム宛てのデータを傍受する目的で、別のシステムのアドレスに対するARPリクエストに応答するものである。ARPスプーフィングを使用して、悪意のあるユーザがネットワーク上の他のユーザーに対して中間者攻撃DoS攻撃を行う可能性がある。ARP自体にはこのような攻撃からの保護方法は提供されておらず、ARPスプーフィング攻撃を検出して対策するための様々なソフトウェアが存在する[18]

ARPの代替 編集

それぞれのコンピュータは、レイヤ3アドレス(IPアドレスなど)とレイヤ2アドレス(イーサネットMACアドレスなど)のマッピングのデータベースを維持する。これは、主にローカルネットワークリンクからのARPパケットの受信によって維持されることから、このデータベースは一般に「ARPキャッシュ」と呼ばれる。伝統的には、静的な設定ファイル[19]や一元管理されたリストなど、このテーブルを管理するために他の方法も使われていた。

少なくとも1980年代以降[20]、ネットワーク接続のできるコンピュータは、このテーブルを表示したり操作したりするための'arp'というユーティリティを持っている[21][22][23]

ARPスタッフィング 編集

ネットワークカメラ[24]やネットワーク配電装置[25]などのユーザインタフェースのない組み込みシステムでは、「ARPスタッフィング」(ARP stuffing)を使って初期ネットワーク接続を行うことができる。ただし、この仕組みはARPは関係ないので、これは不適切な名称である。

ARPスタッフィングは、コンシューマデバイスのネットワーク管理、特にイーサネットデバイスのIPアドレスの割り当てにおける以下のような問題の解決策である。

  1. ユーザは、DHCPなどのアドレス割り当てプロトコルを制御することができない。
  2. デバイスは、それを設定するためのユーザーインターフェースを持っていない。
  3. 適切なIPアドレスがないため、ユーザのコンピュータは通信ができない。

採用された解決策は以下の通りである。

  • ユーザのコンピュータは、アドレステーブルに手動で入力(stuffed = 詰め込まれる)されたIPアドレスを持っている(通常はarpコマンドを使用し、MACアドレスをデバイスのラベルから取得する)。
  • コンピュータは特殊なパケットをデバイスに送信する。通常は、デフォルト以外のサイズのpingパケットである。
  • デバイスはこのIPアドレスを採用する。
  • その後、ユーザはtelnetWebプロトコルで通信して設定を完了する。

ARPスタッフィングを使用するデバイスは通常、攻撃に対して脆弱であるため、デバイスが正常に動作しているときはこのプロセスを無効にする。

標準文書 編集

  • RFC 826 - Ethernet Address Resolution Protocol, Internet Standard STD 37.
  • RFC 903 - Reverse Address Resolution Protocol, Internet Standard STD 38.
  • RFC 2390 - Inverse Address Resolution Protocol, draft standard
  • RFC 5227 - IPv4 Address Conflict Detection, proposed standard

関連項目 編集

脚注 編集

  1. ^ David C. Plummer (1982年11月). “RFC [https://datatracker.ietf.org/doc/html/rfc826 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware]”. Internet Engineering Task Force, Network Working Group. 2019年4月13日閲覧。
  2. ^ Braden, R. (1989年10月). “RFC 1122 - Requirements for Internet Hosts -- Communication Layers”. Internet Engineering Task Force. 2019年4月13日閲覧。
  3. ^ IANA ARP - "Protocol Type"
  4. ^ IANA - Ethertype values
  5. ^ RFC 5342
  6. ^ Address Resolution Protocol (ARP) Parameters”. www.iana.org. 2018年10月16日閲覧。
  7. ^ Cheshire, S. (2008年7月). “RFC [https://datatracker.ietf.org/doc/html/rfc5227 5227 - IPv4 Address Conflict Detection]”. Internet Engineering Task Force. 2019年4月13日閲覧。
  8. ^ Perkins, C. (2010年11月). “RFC [https://datatracker.ietf.org/doc/html/rfc5944 5944 - IP Mobility Support for IPv4, Revised]”. Internet Engineering Task Force. 2019年4月13日閲覧。 “A gratuitous ARP MAY use either an ARP Request or an ARP Reply packet. [...] 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 [...]”
  9. ^ Perkins, C. (1996年10月). “RFC [https://datatracker.ietf.org/doc/html/rfc2002 2002 - IP Mobility Support]”. Internet Engineering Task Force. 2019年4月13日閲覧。
  10. ^ Cheshire, S. (2008年7月). “RFC 5227 - IPv4 Address Conflict Detection”. Internet Engineering Task Force. 2019年4月13日閲覧。 “Why Are ARP Announcements Performed Using ARP Request Packets and Not ARP Reply Packets?”
  11. ^ FAQ: The Firewall Does not Update the Address Resolution Protocol Table”. Citrix (2015年1月16日). 2019年4月13日閲覧。 “[...] garpReply enabled [...] generates ARP packets that [...] are of OPCODE type REPLY, rather than REQUEST.”
  12. ^ Gratuitous ARP in DHCP vs. IPv4 ACD Draft Archived October 12, 2007, at the Wayback Machine.
  13. ^ RFC 2002 Section 4.6
  14. ^ RFC 2131 DHCP – Last lines of Section 4.4.1
  15. ^ Shah, H. (2012年6月). “RFC 6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs”. Internet Engineering Task Force. 2019年4月13日閲覧。
  16. ^ T. Bradley (1998年9月). “RFC 2390 - Inverse Address Resolution Protocol”. Internet Engineering Task Force. 2019年4月13日閲覧。
  17. ^ RFC 903 - A Reverse Address Resolution Protocol”. Internet Engineering Task Force (1984年6月). 2019年4月13日閲覧。
  18. ^ Steve Gibson (2005年12月11日). “ARP Cache Poisoning”. GRC. 2019年4月13日閲覧。
  19. ^ Sun Microsystems. “SunOS manual page for ethers(5) file”. 2011年9月28日閲覧。
  20. ^ University of California, Berkeley. “BSD manual page for arp(8C) command”. 2011年9月28日閲覧。
  21. ^ Canonical. “Ubuntu manual page for arp(8) command”. 2012年3月16日時点のオリジナルよりアーカイブ。2011年9月28日閲覧。
  22. ^ Apple Computer. “Mac OS X manual page for arp(8) command”. 2011年9月28日閲覧。
  23. ^ Microsoft. “Windows help for arp command”. 2011年9月28日閲覧。
  24. ^ Axis Communication. “Axis P13 Network Camera Series Installation Guide”. 2011年9月28日閲覧。
  25. ^ American Power Corporation. “Switched Rack Power Distribution Unit Installation and Quick Start Manual”. 2011年9月28日閲覧。

外部リンク 編集