メインコンテンツまでスキップ

RFC 826 - イーサネットアドレス解決プロトコル

An Ethernet Address Resolution Protocol​

サブタイトル: ネットワークプロトコルアドレスをイーサネットハードウェア上での伝送のための48ビットイーサネットアドレスに変換する

著者: David C. Plummer (DCP@MIT-MC)
発行日: 1982年11月
ステータス: 標準プロトコル (Standard)

概要 (Abstract)​

送信ホストS上で実装されたプロトコルPは、プロトコルPのルーティング機構を通じて、接続された10Mbitイーサネットケーブルのどこかに位置するターゲットホストTに送信したいと判断します。実際にイーサネットパケット (Ethernet Packet) を送信するには、48ビットのイーサネットアドレス (Ethernet Address) を生成しなければなりません。プロトコルP内のホストのアドレスは、対応するイーサネットアドレスと必ずしも互換性がありません (長さや値が異なります)。本文書で提案するプロトコルは、プロトコルPのアドレス空間内のアドレスAを48ビットイーサネットアドレスに変換するテーブルを構築するために必要な情報を動的に配布することを可能にします。

このプロトコルは、10Mbitイーサネット以外のハードウェアでも使用できるように一般化されています。パケット無線ネットワーク (Packet Radio Networks) は、このようなハードウェアの例です。

本文書で説明するプロトコルは、特にJ. Noel Chiappa、Yogen Dalal、James E. Kulpをはじめとする数名との多くの議論の結果であり、David Moonからの有益なコメントも含まれています。

[このRFCの目的は、プロトコルアドレス (例: IPアドレス) をローカルネットワークアドレス (例: イーサネットアドレス) に変換する方法を提示することです。これは現在ARPAインターネットコミュニティで広く関心を持たれている問題です。ここで提案する方法は、皆様の検討とコメントのために提示されています。これはインターネット標準の仕様ではありません。]

注記 (Notes)​

このプロトコルは、もともとDEC/Intel/Xerox 10Mbitイーサネット用に設計されました。他のネットワークタイプでも使用できるように一般化されています。議論の大部分は10Mbitイーサネットに向けられています。一般化については、該当する場合、イーサネット固有の議論の後に説明します。

DODインターネットプロトコル (DOD Internet Protocol) は、インターネット (Internet) と簡略化して呼びます。

ここでの数値はイーサネット標準、すなわち高位バイト優先 (High Byte First) を採用しています。これはPDP-11やVAXなどのマシンのバイトアドレッシングとは逆です。したがって、以下で説明するオペコードフィールド (ar$op) には特別な注意が必要です。

ハードウェア名前空間の値を管理する権威機関が必要です (以下を参照)。公式な権威機関が存在する前は、リクエストは以下に送信されていました:

David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts  02139

または、ネットワークメールを <DCP@MIT-MC> に送信することができます。

問題 (The Problem)​

全体として、世界はジャングルであり、ネットワークゲームは多くの動物を生み出しています。ネットワークアーキテクチャのほぼすべての層で、使用できる可能性のあるプロトコルがいくつか存在します。例えば、高レベルでは、リモートログインのためのTELNETとSUPDUPがあります。その下には、信頼性の高いバイトストリームプロトコル (Reliable Byte Stream Protocol) があり、それはCHAOSプロトコル、DOD TCP、Xerox BSP、またはDECnetである可能性があります。ハードウェアにさらに近いのは論理トランスポート層 (Logical Transport Layer) であり、それはCHAOS、DODインターネット、Xerox PUP、またはDECnetである可能性があります。10Mbitイーサネットは、イーサネットパケットヘッダーのタイプフィールド (Type Field) を通じて、これらすべてのプロトコル (およびそれ以上) が単一のケーブル上で共存することを可能にします。しかし、10Mbitイーサネットは物理ケーブル上で48ビットアドレスを必要としますが、ほとんどのプロトコルアドレスは48ビット長ではなく、ハードウェアの48ビットイーサネットアドレスと必ずしも関係があるわけでもありません。例えば、CHAOSアドレスは16ビット、DODインターネットアドレスは32ビット、Xerox PUPアドレスは8ビットです。<プロトコル, アドレス> ペアと48ビットイーサネットアドレスとの対応関係を動的に配布するプロトコルが必要です。

動機 (Motivation)​

DECとIntelとXeroxが発表した仕様に準拠したインターフェースを提供するメーカーが増えるにつれて、10Mbitイーサネットの利用が増加しています。この利用可能性の増加に伴い、これらのインターフェース用のソフトウェアがますます多く書かれています。2つの選択肢があります: (1) 各実装者が何らかの形式のアドレス解決を行う独自の方法を発明する、または (2) 各実装者が標準を使用して、彼/彼女のコードを修正なしで他のシステムに配布できるようにする。本提案は標準を設定しようとするものです。

定義 (Definitions)​

イーサネットパケットヘッダーのTYPEフィールドに入れられる値を参照するために、以下を定義します:

  • ether_type$XEROX_PUP
  • ether_type$DOD_INTERNET
  • ether_type$CHAOS

そして新しい値:

  • ether_type$ADDRESS_RESOLUTION

また、以下の値も定義します (後で議論します):

  • ares_op$REQUEST (= 1, 高位バイトが最初に送信される)
  • ares_op$REPLY (= 2)

および:

  • ares_hrd$Ethernet (= 1)

パケットフォーマット (Packet Format)​

<プロトコル, アドレス> ペアから48ビットイーサネットアドレスへのマッピングを通信するために、アドレス解決プロトコル (Address Resolution Protocol) を具現化したパケットフォーマットが必要です。フォーマットは次のとおりです。

イーサネット伝送層 (必ずしもユーザーがアクセスできるわけではない):

48ビット: 宛先イーサネットアドレス
48ビット: 送信元イーサネットアドレス
16ビット: プロトコルタイプ = ether_type$ADDRESS_RESOLUTION

イーサネットパケットデータ:

16ビット: (ar$hrd) ハードウェアアドレス空間 (例: イーサネット, パケット無線ネット)
16ビット: (ar$pro) プロトコルアドレス空間。イーサネットハードウェアの場合、これはタイプフィールドセット ether_typ$<protocol> から取得されます
 8ビット: (ar$hln) 各ハードウェアアドレスのバイト長
 8ビット: (ar$pln) 各プロトコルアドレスのバイト長
16ビット: (ar$op)  オペコード (ares_op$REQUEST | ares_op$REPLY)
nバイト: (ar$sha) このパケットの送信者のハードウェアアドレス, nはar$hlnフィールドから取得
mバイト: (ar$spa) このパケットの送信者のプロトコルアドレス, mはar$plnフィールドから取得
nバイト: (ar$tha) このパケットのターゲットのハードウェアアドレス (既知の場合)
mバイト: (ar$tpa) ターゲットのプロトコルアドレス

パケット生成 (Packet Generation)​

パケットがネットワーク層を下に送信されるとき、ルーティング (Routing) はパケットの次のホップのプロトコルアドレスと、直接のターゲットプロトコルアドレスを持つステーションをどのハードウェア上で見つけることを期待するかを決定します。10Mbitイーサネットの場合、アドレス解決が必要であり、いくつかの下位層 (おそらくハードウェアドライバー) がアドレス解決モジュール (Address Resolution Module) (おそらくイーサネットサポートモジュールに実装されている) に相談して、<プロトコルタイプ, ターゲットプロトコルアドレス> ペアを48ビットイーサネットアドレスに変換しなければなりません。アドレス解決モジュールは、このペアをテーブル内で検索しようとします。ペアが見つかった場合、対応する48ビットイーサネットアドレスを呼び出し元 (ハードウェアドライバー) に返し、その後パケットを送信します。見つからない場合、おそらく呼び出し元にパケットを破棄していることを通知し (パケットはより高いネットワーク層によって再送信されると仮定して)、タイプフィールドが ether_type$ADDRESS_RESOLUTION のイーサネットパケットを生成します。その後、アドレス解決モジュールは、ar$hrdフィールドを ares_hrd$Ethernet に、ar$proを解決されるプロトコルタイプに、ar$hlnを6 (48ビットイーサネットアドレスのバイト数) に、ar$plnをそのプロトコルのアドレスの長さに、ar$opを ares_op$REQUEST に、ar$shaを自身の48ビットイーサネットアドレスに、ar$spaを自身のプロトコルアドレスに、ar$tpaをアクセスしようとしているマシンのプロトコルアドレスに設定します。ar$thaは特定の値に設定しません。なぜなら、これが決定しようとしている値だからです。実装の何らかの側面にとって都合が良い場合、ar$thaをハードウェアのブロードキャストアドレス (10Mbitイーサネットの場合は全て1) に設定することもできます (may)。その後、このパケットをルーティング機構によって最初に決定されたイーサネットケーブル上のすべてのステーションにブロードキャストします。

パケット受信 (Packet Reception)​

アドレス解決パケットを受信したとき、受信側のイーサネットモジュールはパケットをアドレス解決モジュールに渡し、そのモジュールは以下のようなアルゴリズムを実行します。否定条件は処理の終了とパケットの破棄を示します。

?ar$hrdに指定されたハードウェアタイプを持っているか?
はい: (ほぼ確実に)
  [オプションでハードウェア長ar$hlnをチェック]
  ?ar$proに指定されたプロトコルを使用しているか?
  はい:
    [オプションでプロトコル長ar$plnをチェック]
    Merge_flag := false
    <プロトコルタイプ, 送信者プロトコルアドレス> ペアが
        既に変換テーブルに存在する場合、
        エントリの送信者ハードウェアアドレスフィールドをパケット内の新しい情報で更新し、
        Merge_flagをtrueに設定する。
    ?自分がターゲットプロトコルアドレスか?
    はい:
      Merge_flagがfalseの場合、三つ組 <プロトコルタイプ,
          送信者プロトコルアドレス, 送信者ハードウェアアドレス> を
          変換テーブルに追加する。
      ?オペコードはares_op$REQUESTか? (ここでオペコードを確認!!)
      はい:
        ハードウェアフィールドとプロトコルフィールドを交換し、
            ローカルのハードウェアアドレスとプロトコルアドレスを送信者フィールドに入れる。
        ar$opフィールドをares_op$REPLYに設定する
        リクエストが受信されたのと同じハードウェア上で、
            パケットを (新しい) ターゲットハードウェアアドレスに送信する。

<プロトコルタイプ, 送信者プロトコルアドレス, 送信者ハードウェアアドレス> の三つ組は、オペコードが確認される前にテーブルにマージされることに注意してください。これは、通信が双方向であるという仮定に基づいています; AがBと通信する理由がある場合、BもおそらくAと通信する理由があるでしょう。また、<プロトコルタイプ, 送信者プロトコルアドレス> ペアのエントリが既に存在する場合、新しいハードウェアアドレスが古いものに優先することにも注意してください。関連する問題 (Related Issues) では、これに対する動機を説明しています。

一般化: ar$hrdとar$hlnフィールドにより、このプロトコルとパケットフォーマットは10Mbitイーサネット以外でも使用できるようになります。10Mbitイーサネットの場合、<ar$hrd, ar$hln> は値 <1, 6> を取ります。他のハードウェアネットワークの場合、ar$proフィールドはもはやイーサネットタイプフィールドに対応しない可能性がありますが、アドレス解決が求められているプロトコルに関連付けられているべきです (should)。

なぜこの方法なのか? (Why is it done this way?)​

定期的なブロードキャストは絶対に望ましくありません。単一のイーサネット上に100台のワークステーションがあり、それぞれが10分ごとにアドレス解決情報をブロードキャストする (可能なパラメータセットの1つとして) ことを想像してください。これは6秒ごとに1パケットです。これはほぼ合理的ですが、それに何の意味があるのでしょうか? ワークステーションは通常、互いに通信しません (したがって、テーブルに100個の無用なエントリがあります); 主にメインフレーム、ファイルサーバー、またはブリッジと通信しますが、他のワークステーションとは少数だけ通信します (例えば、インタラクティブな会話のため)。本文書で説明するプロトコルは、必要に応じて情報を配布し、おそらくマシンの起動ごとに1回だけです。

このフォーマットは、同じパケット内で複数の解決を行うことを許可しません。これは簡素化のためです。複数の解決が多重化された場合、パケットフォーマットは消化するのがかなり難しくなり、情報の多くは無駄になる可能性があります。4つのプロトコルを使用するブリッジが、ワークステーションに4つすべてのプロトコルアドレスを伝え、そのうち3つはワークステーションがおそらく使用しないことを考えてください。

このフォーマットは、応答が生成される場合、パケットバッファを再利用できるようにします; 応答はリクエストと同じ長さであり、いくつかのフィールドは同じです。

ハードウェアフィールド (ar$hrd) の値は、この目的のためのリストから取得されます。現在定義されている唯一の値は、10Mbitイーサネット (ares_hrd$Ethernet = 1) 用です。このプロトコルをパケット無線ネットワーク (Packet Radio Networks) にも使用することについて議論があり、これには別の値が必要になります。また、このプロトコルを使用したい他の将来のハードウェアメディアも同様です。

10Mbitイーサネットの場合、プロトコルフィールド (ar$pro) の値はセット ether_type$ から取得されます。これは、割り当てられたプロトコルタイプの自然な再利用です。これをオペコード (ar$op) と組み合わせると、このプロトコルで解決できるプロトコルの数が事実上半減し、モニター/デバッガーがより複雑になります (以下のネットワーク監視とデバッグを参照)。32768のプロトコルを見ることは決してないと期待されていますが、マーフィーの法則により、そのような仮定はできません。

長さフィールド (ar$hlnとar$pln) は、理論的には冗長です。なぜなら、プロトコルアドレスの長さは、ハードウェアタイプ (ar$hrdに存在) とプロトコルタイプ (ar$proに存在) によって決定されるべきだからです。オプションの一貫性チェック、およびネットワーク監視とデバッグ (以下を参照) のために含まれています。

オペコードは、これがリクエスト (応答を引き起こす可能性がある) か、以前のリクエストに対する応答かを判断するために使用されます。このために16ビットを使用するのは過剰ですが、フラグ (フィールド) が必要です。

送信者ハードウェアアドレスと送信者プロトコルアドレスは絶対に必要です。これらのフィールドが変換テーブルに入れられます。

ターゲットプロトコルアドレスは、パケットのリクエスト形式で必要です。これにより、マシンは送信者情報をテーブルに入力するか、応答を送信するかを判断できます。応答がリクエストによってのみ引き起こされると仮定する場合、応答形式では必ずしも必要ではありません。完全性、ネットワーク監視、および上記で提案された処理アルゴリズムを簡素化するために含まれています (このアルゴリズムは、送信者情報をテーブルに入れた後にオペコードを確認します)。

ターゲットハードウェアアドレスは、完全性とネットワーク監視のために含まれています。リクエスト形式では意味がありません。なぜなら、これはマシンが要求している番号だからです。応答形式でのその意味は、リクエストを行っているマシンのアドレスです。いくつかの実装では (ターゲットハードウェアアドレスを取得する必要がある)、このフィールドをパケットのハードウェア宛先アドレスとしてハードウェアドライバーに送信することで、いくつかのレジスタシャッフリングやスタックスペースを節約できる可能性があります (may)。

アドレス間に詰め物バイトはありません。パケットデータは、3つのバイトペアのみがワード (ar$hrd、ar$pro、ar$op) として定義されるバイトストリームとして見なされるべきです。これらは最上位バイト優先 (イーサネット/PDP-10バイトスタイル) で送信されます。

ネットワーク監視とデバッグ (Network Monitoring and Debugging)​

上記のアドレス解決プロトコルにより、マシンはイーサネットケーブル上のより高レベルのプロトコル活動 (例えば、CHAOS、インターネット、PUP、DECnet) に関する知識を得ることができます。使用されているイーサネットプロトコルタイプフィールド (値による) と各プロトコルタイプ内のプロトコルアドレスを特定できます。実際、モニターは関与するより高レベルのプロトコルのいずれかを使用する必要はありません。以下のように実行できます:

モニターがアドレス解決パケットを受信すると、常に <プロトコルタイプ, 送信者プロトコルアドレス, 送信者ハードウェアアドレス> をテーブルに入力します。パケットのar$hlnとar$plnフィールドから、ハードウェアアドレスとプロトコルアドレスの長さを決定できます。オペコードがREPLYの場合、モニターはパケットを破棄できます。オペコードがREQUESTで、ターゲットプロトコルアドレスがモニターのプロトコルアドレスと一致する場合、モニターは通常どおりREPLYを送信します。モニターは、REQUESTに対するREPLYが要求ホストに直接送信されるため、この方法で1つのマッピングしか取得しません。モニターは独自のREQUESTを送信しようとする可能性がありますが、これにより2つのモニターがREQUEST送信ループに陥る可能性があるため、注意が必要です。

プロトコルとオペコードが1つのフィールドに結合されていないため、モニターは同じより高レベルのプロトコルに対してどのリクエストオペコードがどの応答オペコードと一致するかを知る必要がありません。長さフィールドは、プロトコルアドレスの意味を知らなくても、プロトコルアドレスを「解析」できるようにするのに十分な情報を提供するべきです (should)。

アドレス解決プロトコルの動作実装は、動作しない実装をデバッグするためにも使用できます。ハードウェアドライバーは、おそらくイーサネットタイプフィールドが ether_type$ADDRESS_RESOLUTION のパケットをブロードキャストすることに成功するでしょう。パケットのフォーマットは完全に正しくない可能性があります。なぜなら、初期実装にはバグがある可能性があり、テーブル管理が少し厄介な可能性があるからです。リクエストはブロードキャストされるため、モニターはパケットを受信し、必要に応じてデバッグのために表示できます。

例 (An Example)​

同じ10Mbitイーサネットケーブル上にマシンXとYが存在するとします。それらはイーサネットアドレスEA(X)とEA(Y)、およびDODインターネットアドレスIPA(X)とIPA(Y)を持っています。インターネットのイーサネットタイプをET(IP)とします。マシンXが起動したばかりで、遅かれ早かれ同じケーブル上のマシンYにインターネットパケットを送信したいとします。XはIPA(Y)に送信したいことを知っており、ハードウェアドライバー (ここではイーサネットドライバー) にIPA(Y)を伝えます。ドライバーは、<ET(IP), IPA(Y)> を48ビットイーサネットアドレスに変換するためにアドレス解決モジュールに相談しますが、Xが起動したばかりなので、この情報を持っていません。インターネットパケットを破棄し、代わりにADDRESS RESOLUTIONパケットを作成します:

(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op)  = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = 気にしない
(ar$tpa) = IPA(Y)

そして、このパケットをケーブル上のすべての人にブロードキャストします。

マシンYはこのパケットを取得し、ハードウェアタイプ (イーサネット) を理解し、指定されたプロトコル (インターネット) を使用し、パケットが自分宛て ((ar$tpa)=IPA(Y)) であることを判断します。情報 <ET(IP), IPA(X)> がEA(X)にマッピングされることを入力します (おそらく既存のエントリを置き換えます)。その後、これがリクエストであることに気づき、フィールドを交換し、EA(Y)を新しい送信者イーサネットアドレスフィールド (ar$sha) に入れ、オペコードを応答に設定し、パケットをEA(X)に直接 (ブロードキャストではなく) 送信します。この時点でYはXへの送信方法を知っていますが、XはまだYへの送信方法を知りません。

マシンXはYから応答パケットを取得し、<ET(IP), IPA(Y)> からEA(Y)へのマップを形成し、パケットが応答であることに気づき、それを破棄します。次にXのインターネットモジュールがイーサネット上のYにパケットを送信しようとすると、変換は成功し、パケットは (うまくいけば) 到着します。Yのインターネットモジュールがその後Xと通信したい場合、Yは既にXのアドレス解決リクエストから情報を記憶しているため、これも成功します。

テーブルのエージングおよび/またはタイムアウトが望ましい場合があります。これらの実装は、このプロトコルの範囲外です。ここに、より詳細な説明があります (MOON@SCRC@MIT-MCに感謝)。

ホストが移動した場合、そのホストによって開始された接続は機能します。移動時に自身のアドレス解決テーブルがクリアされると仮定します。しかし、他のホストによって開始されたそのホストへの接続は、古いアドレスを破棄する特別な理由がありません。ただし、48ビットイーサネットアドレスは、ユニークで永久に固定されているべきなので、変更されるべきではありません (should not)。ホスト名 (および他のプロトコルのアドレス) が異なる物理ハードウェアに再割り当てされた場合、ホストが「移動」する可能性があります。さらに、経験から知っているように、ハードウェアまたはソフトウェアのエラーによって誤ったルーティング情報が誤って送信される危険性は常に存在します; これが永久に存続することを許可すべきではありません (should not)。おそらく、接続の開始の失敗は、ホストが到達不能であるという理由で情報を削除するようにアドレス解決モジュールに通知すべきです (should)。おそらくホストがダウンしているか、古い変換がもはや有効ではないためです。あるいは、ホストからパケットを受信すると、そのホストへパケットを送信するために使用されるアドレス解決エントリのタイムアウトをリセットする可能性があります; 適切な時間内にホストからパケットが受信されない場合、アドレス解決エントリは忘れられます。これにより、各着信パケットのテーブルをスキャンする追加のオーバーヘッドが発生する可能性があります。おそらく、ハッシュまたはインデックスを使用すると、これをより高速にできます。

提案されたアドレス解決パケット受信アルゴリズムは、ホストが実際に移動した場合の回復時間を短縮しようとします。<プロトコルタイプ, 送信者プロトコルアドレス> ペアが既に変換テーブルに存在する場合、新しいハードウェアアドレスが既存のエントリに優先することを思い出してください。したがって、ブロードキャストREQUESTがケーブル上のすべてのステーションに到達する完璧なイーサネットでは、各ステーションが新しいハードウェアアドレスを取得します。

別の選択肢は、デーモンにタイムアウトを実行させることです。適切な時間の後、デーモンはエントリの削除を検討します。最初に、オペコードがREQUESTのアドレス解決パケットをテーブル内のイーサネットアドレスに直接送信します (必要に応じて少数の再送信を行います)。短時間でREPLYが見られない場合、エントリは削除されます。リクエストは、イーサネット上のすべてのステーションに迷惑をかけないように直接送信されます。エントリを忘れるだけでは、有用な情報が忘れられる可能性があり、再取得する必要があります。

ホストは自分自身以外の誰の情報も送信しないため、ホストを再起動すると、そのアドレスマッピングテーブルは最新になります。悪い情報がマシン間で受け渡されることによって永久に存続することはできません; 存在できる唯一の悪い情報は、他のマシンが48ビットイーサネットアドレスを変更したことを知らないマシン内のものです。おそらく、アドレスマッピングテーブルを手動でリセット (またはクリア) するだけで十分でしょう。

この問題が重要であると考えられる場合、デーモンがタイムアウトして質問を再度尋ねることが重要です。エントリを削除するだけではありません。デーモンは、このプロトコルよりも再送信をより適切に処理することもできます。なぜなら、物理的に接続されているが到達不能なターゲットマシン (例えば、ソフトウェア障害のため) は、リクエストに応答する必要がないからです。このプロトコルは、次のホップゲートウェイのイーサネットアドレスを決定するために使用され、そのゲートウェイはイーサネット上のすべてのアドレス解決パケットに応答する必要はありません。これは重要な問題ではありません。なぜなら、デーモンは独自のプロトコルを使用するのではなく、アドレス解決プロトコルを使用して質問をすることができるからです。

関連リソース​

  • 公式原文: https://www.rfc-editor.org/rfc/rfc826.txt
  • 公式ページ: https://datatracker.ietf.org/doc/html/rfc826
に最終更新