If no matching entry is found, NULL is returned.

     Link_Level_ARP_Req_Add(IP_Add,Phys_Int) returns the link level
      address to which an ARP Request to resolve IP_Add should be
      forwarded.  If ARP is not used to perform local address resolution
      of IP_Add, NULL is returned.

     Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level
      address associated with IP_Add, using address resolution
      procedures associated with address, IP_Add, and interface,
      Phys_Int.  If address resolution is unsuccessful, NULL is

      returned.  Note that different address resolution procedures may
      be used for different IP networks.

     Next_Hop(Entry) returns the IP address in the next-hop field of
      (routing table) Entry.

     Interface(Entry) returns the physical interface field of (routing
      table) Entry.

     ARP_Helper_Add(Entry) returns the IP address in the ARP Helper
      Address field of (routing table) Entry.

     Source_Link_Level(ARP_Request) returns the link level address of
      the sender of ARP_Request.

   Receive(ARP_Request,Interface)
   {
   If (Is_Local_IP_Add(Target_IP(ARP_Request),Interface))
     Do_ARP_Processing(ARP_Request,Interface);
   else  /*  Not my IP Address  */
     If (I_Am_Router)  /*  Hosts don't Direct ARP Requests  */
       If (Filter(ARP_Request,Interface))  /*  Passes Filter Test  */
                                           /*  See Section 3.4  */
         Direct(ARP_Request,Interface);  /*  Directed ARP Procedures  */
   Return;
   }

   Figure 3:  C Pseudo-Code for Receiving ARP Requests.

   Direct(ARP_Request,Phys_Int)
   {
   Entry = Look_Up_Next_Hop_Route_Table(Target_IP(ARP_Request));
   If (Entry == NULL)  /* Target_IP Address is not a next-hop */
     {                 /*  in Routing Table */
     Entry = Look_Up_Dest_Route_Table(Target_IP(ARP_Request));
       If (Entry == NULL)  /* Not a destination either */
         Return;  /* Discard ARP Request */
       else
         If (Next_Hop(Entry) != NULL) /* Not a next-hop and Not local */
           Return;  /* Discard ARP Request */
     }
   If (Interface(Entry) != Phys_Int)
                            /* Must be same physical interface */
     Return;  /* Discard ARP Request */
   If (ARP_Helper_Add(Entry) != NULL)
     {
     L_L_ARP_Helper_Add = Resolve(ARP_Helper_Add(Entry),Phys_Int,NULL);
     If (L_L_ARP_Helper_Add != NULL)
       Forward(ARP_Request,L_L_ARP_Helper_Add,Phys_Int);
         /*  Forward ARP_Request to ARP Helper Address  */
     Return;
     }
   else  /*  Do local address resolution.  */
     {
     L_L_ARP_Req_Add =
                Link_Level_ARP_Req_Add(Target_IP(ARP_Request),Phys_Int);
     If (L_L_ARP_Req_Add != NULL)
       {  /*  Local address resolution procedure is ARP. */
          /*  Forward ARP_Request. */
       Forward(ARP_Request,L_L_ARP_Req_Add,Phys_Int);
       Return;
       }
     else
       {  /*  Local address resolution procedure is not ARP.  */
          /*  Do "published ARP" on behalf of Target IP Address  */
       Target_Link_Level =
                      Local_Add_Res(Target_IP(ARP_Request),Phys_Int);
       If (Target_Link_Level != NULL)  /*  Resolved Address  */
         {
         Forward(ARP_Response,Source_Link_Level(ARP_Request),Phys_Int);
         }
       Return;
       }
     }
   }
直接ARP回應的C語言源代碼。
3.4 過濾過程
路由器執行的直接ARP過程必須能過濾ARP請求包的蔓延 強制ARP洪泛的范圍不侵擾主機或路由器，并終止在路由協議不穩定或錯誤的人為配置引起的可能發生潛在的ARP環。具體過濾ARP請求包的過程超出了本文檔的范圍。下述過程建議應當被充分的執行。其他過程更好的被其他指定的過程執行。
ARP請求包的轉發introduces可能的ARP環。這個過程用來控制潛在的ARP洪泛的范圍并終止一些ARP環，但是需要那些必須橫越環時間比用來控制ARP洪泛的要長的過程。路由器能拒絕轉發每T分鐘同一ARP請求超過N，N和T是管理的數量。如果T和N被選擇，則T/N分鐘是大于需要橫越環的最大時間，如一個過濾可以終止環。主機一些情況下可以發送不止一個有相同源IP地址、目的IP地址對的ARP請求（例如：N應該大于1）。例如：第一個ARP請求應該丟棄。然而，一旦ARP響應被公認，主機通常保留映射信息，因此在連續的一段時間內不發生相同的ARP請求。所以，T應該大到可以保證T/N大于橫越環的時間。在實行鏈路層幀的目的地址用來給路由器傳輸ARP請求時，可以利用路由器的直接ARP過濾過程。如果路由器不轉發ARP請求到同一個收到ARP請求的鏈路層地址，一類重要的ARP環從開始將被阻止。當然，其他過程也是需要的例如上一段的描述將阻止所有的環，縱使過濾被執行從開始就阻止環。主機要求[5]指定“在IP層和鏈路收到包的接口必須尋址到鏈路層廣播地址”。如果路由器不轉發尋址到鏈路層廣播地址的ARP請求，則一類簡單的重要的ARP烘泛能被限制。
4.路由直接ARP的用途
路由信息的交換和用途被通用地址解析過程所強制。如果主機或路由器不能解析下一跳IP地址到鏈路層地址的映射，則不能通過動態路由信息獲取下一跳IP地址。沒有一致的動態地址解析過程，路由器不能通告收到的不在同一IP網絡的主機、路由器通告的下一跳地址。直接ARP是能使路由器通告使路又有效的路由信息、提供輔助解析下一跳IP地址映射的過程。
以下小節描述擴大的直接ARP應用范圍：ICMP的重定向，距離向量路由協議（如：BGP[3]），鏈路狀態路由協議（如：OSPF[4]）。
4.1 ICMP的重定向
如果路由器在同一鏈路層網絡轉發主機創建的原始包到下一跳地址，路由器可以發送ICMP重定向給主機。但是如果主機沒有下一跳地址到他映射的鏈路層地址的解析，不能用下一跳地址通過ICMP重定向通告。
主機執行直接ARP過程包括每條路由記錄的ARP求助地址。如果映射的下一跳地址是一條空的下一跳和空的ARP求助地址（例如：主機已經知道如何解析下一跳地址）的路由記錄，則通過ICMP重定向映射的記錄的ARP協助地址是空的。否則，ARP的求助地址是發送直接ICMP重定向路由器的IP地址。因此在主機的地址解析表中應該有一條關于新的ARP求助地址的記錄。如果主機在ICMP重定向中不能解析下一跳IP地址通告（例如：因為ARP協助地址是外部IP網絡；通過老的ICMP重定向得知的，ARP求助地址的地址解析記錄超時），主機必須flush路由表記錄的解析。直接ARP過程不能用直接ARP解析ARP求助地址。
運行直接ARP過程的路由器可以給沒有運行直接ARP的主機通告下一跳。下述已有的過程主機將立刻丟棄ICMP重定向。不執行直接ARP的路由器在外部IP網絡上不能通告，作為現行過程的說明。如果照作，ICMP重定向將被運行直接ARP過程的主機收到，主機將給外部IP地址發送一個ARP請求給通告將立刻拋棄ARP請求的路由器。當地址解決失敗，主機將更新路由表記錄的映射。
基于不同的理由主機可以忽略ICMP重定向并繼續轉發包到發送ICMP重定向的同一個路由器。例如，在外部網絡上主機不執行直接ARP過程并立刻丟棄到下一跳地址的ICMP重定向通告。路由器強制執行去控制發送到主機的ICMP重定向的數量。例如，路由器可以限制重復的每T分鐘不超過N條ICMP重定向的數量，T、N是建議的變量。
4.2距離矢量路由協議
距離矢量路由協議是路由器通告目的地址的過程（例如；IP網絡），下一跳地址的映射，及其他信息（例如：距離的映射）。如果路由器沒有通告的下一跳地址到鏈路層地址映射的解析的過程，則不能通告路由。直接ARP是路由器能用來解析通告下一條地址的過程，縱使當路由器在同一IP網絡通告下一跳沒有地址。
下述過程假設如果知道更新發送者的IP地址并能解析發送者的IP地址到它的映射的鏈路層地址，當發送者有相同的鏈路層網絡，則路由器僅僅能接受路由更新，。
路由器執行包括每個路由器記錄的ARP求助地址的直接ARP過程如果映射的下一跳地址對應的路由表記錄是他的下一跳和他的ARP求助地址（例如：路由器已經知道如何解析下一跳地址），記錄映射的ARP求助地址的學習通過的路由更新。否則，ARP求助地址是那個發送路由更新的路由器的IP地址。
有些距離矢量路由協議（例如：BGP[3]）提供方法，從而允許路由器可以在外部IP網絡通告下一跳的地址。如果運行直接ARP協議過程的路由器通告一個外部的下一跳的IP地址給第二個沒有運行直接ARP協議過程的路由器，第二個路由器不能用通告的外部的下一跳。依靠路由協議的詳細執行，他可以正確的提供給第一個路由器，也可以通告不在外部IP網絡的下一跳（例如：他自己），也許是更大的花費。或者，如果路由方案是可管理的的鏈接（例如：BGP方案是可管理的TCP/IP連接），那些管理過程能決定是否通告外部的下一跳IP地址。
距離矢量路由協議能通告目的地是可直接到達的，通過具體的路由器收到的公告信息、他本身、下一跳到目的地。另外，路由的通告花費可以為0。如果路由器沒有一條通告目的地對應的路由記錄是本地的（例如：他的下一跳地址），路由器將添加新的空的下一跳路由，并且發送更新的路由器的IP地址作為ARP求助地址。
4.3鏈路狀態路由協議
鏈路狀態路由協議為路由器提供通過標識鏈路到達其他記錄（例如：其他路由器和網絡），取決于在路由區域內鏈路的狀態和花費，可靠的描述鏈路狀態信息給其他路由器，從其他路由器收到的鏈路狀態信息，計算路由。一個路由器接口通過同一鏈路層接口連接到兩個（或更多）IP網絡，被連接到IP網絡通過一個單獨的鏈路，象上面的描述。如果用相同鏈路連接到兩個（或更多）IP網絡上，并且能提供直接ARP過程的路由器，在任何IP網絡上都能直接轉發包給任何IP網上的用直接ARP過程在外部IP網絡解析地址的主機和路由器。直接ARP，直接到達外部IP網絡的路徑花費比通過所有IP網絡上路由器地址的路徑花費更小。
直接ARP過程帶來的好處，鏈路狀態路由協議必須包含為路由器去通告通過同一鏈路連接到多IP網絡的過程，并且路由表的計算處理必須包括計算ARP求助地址的過程和正確計算直接通過直接ARP過程到外部IP網絡減少路徑花費的過程的過程。
為計算最少花路由最短路徑優先算法是基于Dijkstra[7]工作的，首先被ARPANET應用路由協議，由McQuillan[8]所描述。路由器通過構造自己為根的最短路徑樹構造路由表。此過程是迭代的，開始時最短路徑樹沒有任何記錄，在候選表上路由器本身作為唯一的候選人。路由器重下述兩個步驟：
1. 從候選表刪除最靠近根的記錄，把他添加最短路徑樹。
2. 檢查從第一步中添加到最短路徑樹的鏈路狀態通告。對每個鄰居（例如連接的路由器或IP網絡）：
——如果鄰居已經在最短路徑樹上，不作任何改變。
——如果鄰居在候選表里，重新計算根到鄰居的距離。也重新計算下一跳到鄰居的距離。
——如果鄰居不在候選表里，計算從根到鄰居和從根到下一跳的距離并添加鄰居到候選表。
當沒有記錄在候選表的時候，終止此處理。
運行直接ARP過程的優點，鏈路狀態協議必須提路由器通過同一鏈路訪問兩個或多個IP網絡的通告的過程。另外，最短路徑優先路由協議的計算被改變去計算ARP求助地址和識別通過直接ARP減少的到達路徑花費。
1. 如果考慮的鄰居是IP網絡，他的父節點（例如：在上述第一步添加到最短路徑樹中的記錄）已經通告鄰居通過網絡中已經在最短路徑樹上的同一條鏈路可到達。從根和下一跳的距離——從根到鄰居的距離是相同的當距離和下一跳已經對應的網絡在最短路徑樹上。如果ARP求助地址對網絡的映射已經在最短路徑樹上，并不為空，鄰居也從已經在最短路徑樹上的網絡繼承那個ARP求助地址。    
2. 如果計算的下一跳到鄰居為空，則鄰居從他的父節點繼承ARP求助地址。否則，除非在第一條中描述過，ARP求助地址是到鄰居父節點的下一跳的IP地址。注意下一跳到根是空的。
對于在最短路徑樹上的每個路由器或IP網絡，最短路徑優先算法必須發現一個或更多能用來訪問路由器或IP網絡的下一跳。路由器通告一條鏈路給IP網絡必須包括在IP網絡上能被別的路由器使用的下一跳路由器的IP地址。路由器可以通過被通告的從兩個IP網絡訪問的同一個下一跳IP地址的同一條鏈路連接到兩個IP網絡。路由器可以通過被通告的從兩個IP網絡訪問的同一個下一跳IP地址的同一條鏈路連接到兩個IP網絡。作為對從兩個IP網絡訪問的下一跳IP地址  容納在兩個IP網絡上強制的路由器的地址解析  路由器可以通告兩個IP地址（每個IP網絡一個）。
主機路由器能用直接ARP解析三組下一跳地址；例如從路由協議或對等的通用的下一跳路由器知道的。不刪除失敗的第三組下一跳會導致路由黑洞。避免路由黑洞，主機需要[5]指定主機“...MUST能發現失敗的下一跳網關并在路由緩存的列表中選擇一個代替的網關”。主機能從IP層的協議（例如：TCP）收到反饋  指定下一跳路由器的狀態，并且用別的過程（例如：ICMP echo）去檢測下一跳路由器的狀態。路由器產生路由的復雜性，路由信息必須和對等知道他們信息的一致。如BGP[3]，OSPF[4]和其他的路由協議需要路由器必須保持他們通告后面的路由信息。通告路由器的IP地址作為附加路由信息。如果路由信息是無效的，路由器將通告必須通告舊的信息不再有效。如果源路由信息變為無效，則從源路由器收到的所有信息必須被標記為無效的。從過程得到的復雜的動態路由協議項使路由器確信能收到對等的路由更新，或能決定他們不能收到路由更新（例如：因為對等的連接不再有效）。
如果下面鏈路層的連接不能傳輸則第三組的下一跳也能在路由黑洞解析。例如：SMDS過濾能夠被管理去允許在R1的SMDS地址和R2之間通訊，在R2的SMDS地址和R3之間通訊，可以鎖定在R1的SMDS地址和R3之間的通訊。R2能把R3作為下一跳通告給R1，但是SMDS過濾將阻止在R1和R3之間的直接通訊。不對稱的過濾可以允許R3發送包到R1，但是瑣定從R1地址到R3的包。
主機或路由器能驗證鏈路層和被發送ICMP echo到下一跳路由器鏈路層地址的下一跳的路由器的連接。（注意ICMP echo被直接發送給下一跳路由器的鏈路層地址，如果ICMP echo是可路由的，他可以跟隨沒有被證實的鏈路層連接的路徑。）這種檢測能在添加路由表記錄的映射之前被執行，或者在首先應用路由表記錄之前。隨后發現鏈路層連接的改變是動態路由協議的問題并且超越了本文本的范圍。
參考：
[1] Piscitello, D., and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, Bell Communications Research, March 1991.
[2] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics, Inc., ovember 1982.
[3] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems and IBM T. J. Watson Research Center, October 1991.
[4] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
[5] Braden, R., editor, "Requirements for Internet Hosts --Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.
[6] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
[7] Dijkstra, E. W., "A Note on Two Problems in Connection with Graphs", Numerische Mathematik, Vol. 1, pp. 269-271, 1959.
[8] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing Algorithm for the ARPANET", IEEE Transactions on Communications, Vol. COM-28, May 1980.
[9] "Generic System Requirements In Support of Switched Multi-megabit Data Service", Technical Reference TR-TSV-000772, Bell Communications Research Technical Reference, Issue 1, May 1991.
安全考慮：
安全問題不在本文檔討論的范圍內。
作者地址：
   John Garrett
   AT&T Bell Laboratories
   184 Liberty Corner Road
   Warren, N.J. 07060-0906
   Phone: (908) 580-4719
   EMail: jwg@garage.att.com

   John Dotts Hagan
   University of Pennsylvania
   Suite 221A
   3401 Walnut Street
   Philadelphia, PA 19104-6228
   Phone: (215) 898-9192
   EMail: Hagan@UPENN.EDU

   Jeffrey A. Wong
   AT&T Bell Laboratories
   184 Liberty Corner Road
   Warren, N.J. 07060-0906
   Phone: (908) 580-5361
   EMail: jwong@garage.att.com

RFC1433——Directed ARP                                                      直接ARP




1
RFC文檔中文翻譯計劃