RFC 1433

Directed ARP

📅 published March 1993, from ietf

RFC 1433: Directed ARP 💖

Okay bestie, let's get into this one ✨ It's from the Network Working Group, written in March 1993 by J. Garrett (AT&T Bell Laboratories), J. Hagan (University of Pennsylvania), and J. Wong (AT&T Bell Laboratories). It's an Experimental Protocol, and the title block doesn't list anything it obsoletes or updates 🦋

Status of This Memo 📜

This memo defines an Experimental Protocol for the Internet community. The authors are asking for discussion and suggestions for improvement 🫶 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 👑 And distribution of this memo is unlimited, so share away 💅

Abstract 🌈

Okay so picture a router with an interface on two IP networks through the same link level interface 🧚 It could notice that those two IP networks actually share the same link level network, and then it could tell hosts (through ICMP Redirects) and routers (through dynamic routing protocols) about it ✨

Here's the catch though 😭 A host or router that's only on one of the IP networks couldn't use that info to talk directly to hosts and routers on the other IP network. It would need to resolve IP addresses on the "foreign" IP network to their link level addresses first, and that's the part that's stuck.

That's where Directed ARP comes in 💜 It's a dynamic address resolution procedure that lets hosts and routers resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. Iconic, honestly 👑

Acknowledgments 🫶

The authors are so grateful to Joel Halpern of Network Systems Corporation and David O'Leary, who gave them valuable comments, insight, and ongoing moral support while the presentation went through many, many drafts 😭 Members of the IPLPDN working group also gave valuable comments during presentations and on the IPLPDN mailing list 💖

Chuck Hedrick of Rutgers University, Paul Tsuchiya of Bell Communications Research, and Doris Tillman of AT&T Bell Laboratories also gave early insight, plus comments on early drafts. The main character supporting cast 🎀

1. Terminology 🌸

A "link level network" is the upper layer of what some people call the "subnetwork" (that's OSI parlance), so basically the layers below IP 🧚 The term "link level" is used so nobody confuses it with "IP sub-network". It also names the "link level address" tied to the network that carries IP datagrams 💅

From the view of a host or router, an IP network is "foreign" if that host or router doesn't have an address on that IP network 🦋

2. Introduction 🍓

Multiple IP networks can be administered on the same link level network, like on a big public data network 🌈 A router with a single interface on two IP networks could use the existing routing update procedures to advertise that those two IP networks share the same link level network ✨

Here's why that's a big deal 💖 If hosts and routers that aren't on the same IP network could use that advertised info, they could exchange packets directly. That means better cost and performance, instead of bouncing everything through the dual-addressed router 🔥 The problem is that a host or router can not send packets directly to an IP address until it has resolved that IP address to its link level address 😭

IP address resolution procedures are set up independently for each IP network, and that's where things get messy 💀 For example, on an SMDS network [1], address resolution can use the Address Resolution Protocol (ARP) [2], with a separate SMDS ARP Request Address (like an SMDS Multicast Group Address) for each IP network 🦋 A host or router that wasn't configured with the right ARP Request Address would have no way to learn it, so it would never send an ARP Request to the right place 🙈

On an Ethernet network, a host or router might guess that it can resolve an IP address by sending an ARP Request to the broadcast address 🤷‍♀️ But if the IP network uses a different address resolution procedure (say, administered address resolution tables), that ARP Request might just go unanswered 💀

Directed ARP is a procedure that lets a router, which is advertising that an IP address sits on a shared link level network, also help resolve that IP address to its associated link level address ✨ By removing those address resolution constraints, Directed ARP lets dynamic routing protocols like BGP [3] and OSPF [4] advertise and use routing information that leads to next-hop addresses on "foreign" IP networks 🌸 It also lets routers advertise (via ICMP Redirects) next-hop addresses that are "foreign" to hosts, because hosts can then use Directed ARP to resolve those "foreign" next-hop addresses 💖

3. Directed ARP 💜

Directed ARP uses the normal ARP packet format 📦 It's consistent with the ARP procedures defined in [1] and [2], and with routers and hosts that implement those procedures, so everything lines up nicely 🫶

3.1. ARP Helper Address 🧚

Hosts and routers keep routing information, logically organized as a routing table 🗂️ Each routing table entry links one or more destination IP addresses to a next-hop IP address and a physical interface, which is what gets used to forward a packet to that next-hop IP address 🦋

If the destination IP address is local (meaning it can be reached without the help of a router), the next-hop IP address is NULL 🌈 Or a logical equivalent works too, like the IP address of the associated physical interface ✨ Otherwise, the next-hop IP address is the address of a next-hop router 👑

A host or router that implements Directed ARP procedures associates an ARP Helper Address with each routing table entry 💅 If that host or router has been configured to resolve the next-hop IP address to its associated link level address (or to resolve the destination IP address, when the next-hop IP address is NULL), then the associated ARP Helper Address is NULL 🙌

Otherwise, the ARP Helper Address is the IP address of the router that provided the routing information saying that the next-hop address sits on the same link level network as the associated physical interface 💖 Section 4 has detailed examples of how dynamic routing procedures figure out ARP Helper Addresses, so keep that in your back pocket 🎀

3.2 Address Resolution Procedures ✨

okay so bestie, when a host or router needs to forward an IP packet, it searches its routing table for the entry that's the best match for the destination IP address (and maybe other stuff too, like Type of Service 💅). That chosen entry holds the IP address of a next-hop router (which may be NULL 🙈), the physical interface the packet should leave through, an ARP Helper Address (also possibly NULL), and some other info. The routing function passes the next-hop IP address, the interface, and the ARP Helper Address over to the address resolution function. That function must then resolve the next-hop IP address (or the destination IP address, if the next-hop is NULL) to its associated link level address 🔍

Then the IP packet, the link level address, and the interface all get handed to the link level driver for that physical interface. The driver wraps the IP packet up in one or more link level frames (which may do fragmentation 🧩) addressed to that link level address, and sends them out the right physical interface. The C pseudo-code below spells out every detail 🎀

The procedures are organized as two main functions, Route() and Resolve(), which handle routing and address resolution. There are also these low level helper functions:

Get_Route(IP_Add,Other) returns a pointer to the routing table entry whose destination field best matches IP_Add. If nothing matches, NULL comes back. Other info, like Type of Service, may be considered when picking the best route.
Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if needed), encapsulates Packet in one or more Link Level Frames addressed to Link_Level_Add, and forwards the frame(s) through interface Phys_Int.
Look_Up_Add_Res_Table(IP_Add,Phys_Int) returns a pointer to the link level address associated with IP_Add in the address resolution table for interface Phys_Int. If IP_Add isn't in that table, NULL is returned.
Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level address associated with IP_Add, using the address resolution procedures tied to IP_Add and interface Phys_Int. If address resolution fails, NULL is returned. Different IP networks may use different address resolution procedures 🌈
Receive_ARP_Response(IP_Add,Phys_Int) returns a pointer to an ARP Response received through interface Phys_Int that resolves IP_Add. If no ARP response is received, NULL is returned.
Dest_IP_Add(IP_Packet) returns the IP destination address from IP_Packet.
Next_Hop(Entry) returns the IP address in the next-hop field of the (routing table) Entry.
Interface(Entry) returns the physical interface field of the (routing table) Entry.
ARP_Helper_Add(Entry) returns the IP address in the ARP Helper Address field of the (routing table) Entry.
ARP_Request(IP_Add) returns an ARP Request packet with IP_Add as the Target IP address.
Source_Link_Level(ARP_Response) returns the link level address of the sender of ARP_Response.

Here's the routing function, the main character of this whole section 👑

ROUTE(IP_Packet)
{
Entry = Get_Route(Dest_IP_Add(IP_Packet),Other(IP_Packet));
If (Entry == NULL)  /* No matching entry in routing table */
  Return;  /*  Discard IP_Packet */
else
  {  /* Resolve next-hop IP address to link level address */
  If (Next_Hop(Entry) != NULL) /* Route packet via next-hop router */
    Next_IP = Next_Hop(Entry);
  else  /* Destination is local */
    Next_IP = Dest_IP_Add(IP_Packet);
  L_L_Add = Resolve(Next_IP,Interface(Entry),ARP_Helper_Add(Entry));
  If (L_L_Add != NULL)
    Forward(IP_Packet,L_L_Add,Interface(Entry));
  else  /* Couldn't resolve next-hop IP address */
    Return;  /* Discard IP_Packet */
  Return;
  }
}

Figure 1: C Pseudo-Code for the Routing function.

And now the resolve function, which is where all the ARP drama happens 🫶

Resolve(IP_Add,Interface,ARP_Help_Add)
{
If ((L_L_Add = Look_Up_Add_Res_Table(IP_Add,Interface)) != NULL)
  {   /* Found it in Address Resolution Table */
  Return L_L_Add;
  }
else
  {
  If (ARP_Help_Add == NULL)
    {  /* Do local Address Resolution Procedure */
    Return Local_Add_Res(IP_Add,Interface);
    }
  else  /* ARP_Help_Add != NULL */
    {
    L_L_ARP_Help_Add = Look_Up_Add_Res_Table(ARP_Help_Add,Interface);
    If (L_L_ARP_Help_Add == NULL)
                           /* Not in Address Resolution Table */
      L_L_ARP_Help_Add = Local_Add_Res(ARP_Help_Add,Interface);
    If (L_L_ARP_Help_Add == NULL)  /* Can't Resolve ARP Helper Add */
      Return NULL;  /*  Address Resolution Failed */
    else
      {  /* ARP for IP_Add */
      Forward(ARP_Request(IP_Add),L_L_ARP_Help_Add,Interface);
      ARP_Resp = Receive_ARP_Response(IP_Add,Interface);
      If (ARP_Resp == NULL) /* No ARP Response (after persistence) */
        Return NULL;  /* Address Resolution Failed */
      else
        Return Source_Link_Level(ARP_Resp);
        }
      }
    }
  }
}

Figure 2: C Pseudo-Code for Address Resolution function.

3.3 Forwarding ARP Requests 🦋

so a host that does Directed ARP still uses the normal procedures to process ARP Requests it receives 🙌 If the Target IP address is the host's own address, the host uses normal procedures to respond. If the Target IP address is not the host's address, the host silently discards the ARP Request. Simple, right? 💖

Routers get to do a little more. If the Target IP address of a received ARP Request is the router's address, the router uses normal procedures to respond. But if the Target IP address isn't the router's address, the router may forward the ARP Request back out through the same interface it came in on. It addresses it to a Link Level Address that corresponds to an ARP Helper Address in the router's routing table 🍓

The procedures for processing an ARP Request are written up as C pseudo-code below. The function Receive() describes what hosts and routers both follow, and the function Direct() describes the extra steps that only routers follow ✨ Here are the low level helpers used along the way:

Is_Local_IP_Add(IP_Add,Phys_Int) returns TRUE if Phys_Int has been assigned IP address, IP_Add. Otherwise, it returns FALSE.
Do_ARP_Processing(ARP_Request,Interface) processes ARP_Request using ARP procedures described in [2].
I_Am_Router returns TRUE if the device is a router, and False if the device is a host.
Target_IP(ARP_Request) returns the Target IP address from ARP_Request.
Filter(ARP_Request,Phys_Int) returns TRUE if ARP_Request passes filtering constraints, and FALSE if filtering constraints are not passed. See section 3.4.
Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if needed), encapsulates Packet in one or more Link Level Frames addressed to Link_Level_Add, and forwards the frame(s) through interface Phys_Int.
Look_Up_Next_Hop_Route_Table(IP_Add) returns a pointer to the routing table entry with the next-hop field that matches IP_Add. If no matching entry is found, NULL is returned.
Look_Up_Dest_Route_Table(IP_Add) returns a pointer to the routing table entry with the destination field that best matches IP_Add. 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. Different IP networks may use different address resolution procedures.
Next_Hop(Entry) returns the IP address in the next-hop field of the (routing table) Entry.
Interface(Entry) returns the physical interface field of the (routing table) Entry.
ARP_Helper_Add(Entry) returns the IP address in the ARP Helper Address field of the (routing table) Entry.
Source_Link_Level(ARP_Request) returns the link level address of the sender of ARP_Request.

First up is the receive function, which is what every host and router runs first 🌸

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.

And here's the directing function, the router-only part where the real magic happens 🔥

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;
    }
  }
}

Figure 4: C Pseudo_Code for Directing ARP Requests.

3.4. Filtering Procedures ✨

Okay so, a router doing Directed ARP procedures must filter the propagation of ARP Request packets 🚧 to keep potential "ARP floods" from getting out of hand. Those can be caused by misbehaving routers or hosts 💀, and filtering also helps end ARP loops that can pop up during routing protocol instability or because of inappropriate manual configurations 🙈. Specific filtering procedures are beyond the scope of this document, but here are some suggested approaches that should be sufficient 💅. Other procedures may be better suited to a particular implementation 🌸.

To control an "ARP flood", a router performing Directed ARP procedures could limit the number of identical ARP Requests (i.e., same Source IP address and same Target IP address) that it would forward per small time interval (e.g., no more than one ARP Request per second) ⏱️. This is consistent with the procedure suggested in [5] to prevent ARP flooding 🦋.

Forwarding ARP Request packets introduces the possibility of ARP loops 🔁. The procedures used to control the scope of potential ARP floods may terminate some ARP loops, but additional procedures are needed if the time required to traverse a loop is longer than the timer used to control ARP floods. A router could refuse to forward more than N identical ARP Requests per T minutes, where N and T are administered numbers 🔢. If T and N are chosen so that T/N minutes is greater than the maximum time required to traverse a loop, such a filter would terminate the loop 🔚.

In some cases a host may send more than one ARP Request with the same Source IP address,Target IP address pair (i.e., N should be greater than 1) 🤔. For example, the first ARP Request might be lost. However, once an ARP Response is received, a host would normally save the associated information, and therefore would not generate an identical ARP Request for a period of time on the order of minutes 🧠. Therefore, T may be large enough to ensure that T/N is much larger than the time to traverse any loop ✨.

In some implementations the link level destination address of a frame used to transport an ARP Request to a router may be available to the router's Directed ARP filtering process 📦. An important class of simple ARP loops will be prevented from starting if a router never forwards an ARP Request to the same link level address to which the received ARP Request was addressed. Of course, other procedures such as the one described in the paragraph above will stop all loops, and are needed, even if filters are implemented that prevent some loops from starting 😭.

Host requirements [5] specify that "the packet receive interface between the IP layer and the link layer MUST include a flag to indicate whether the incoming packet was addressed to a link-level broadcast address." An important class of simple ARP floods can be eliminated if routers never forward ARP Requests that were addressed to a link-level broadcast address 🎀.

4. Use of Directed ARP by Routing 🛣️

The exchange and use of routing information is constrained by available address resolution procedures 🧭. A host or router can not use a next-hop IP address learned via dynamic routing procedures if it is unable to resolve the next-hop IP address to the associated link level address 🙅. Without compatible dynamic address resolution procedures, a router may not advertise a next-hop address that is not on the same IP network as the host or router receiving the advertisement. Directed ARP is a procedure that enables a router that advertises routing information to make the routing information useful by also providing assistance in resolving the associated next-hop IP addresses 💖.

The following subsections describe the use of Directed ARP to expand the scope of ICMP Redirects [6], distance-vector routing protocols (e.g., BGP [3]), and link-state routing protocols (e.g., OSPF [4]) 🌈.

4.1. ICMP Redirect 🦋

If a router forwards a packet to a next-hop address that is on the same link level network as the host that originated the packet, the router may send an ICMP Redirect to the host 📨. But a host can not use a next-hop address advertised via an ICMP Redirect unless the host has a procedure to resolve the advertised next-hop address to its associated link level address 🤷‍♀️. Directed ARP is a procedure that a host could use to resolve an advertised next-hop address, even if the host does not have an address on the same IP network as the advertised next-hop address 👑.

A host that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry 📋. The ARP Helper Address associated with an entry learned via an ICMP Redirect is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and a NULL ARP Helper Address (i.e., the host already knows how to resolve the next-hop address) 🧠. Otherwise, the ARP Helper Address is the IP address of the router that sent the ICMP Redirect. Note that the router that sent the ICMP Redirect is the current next-hop to the advertised destination [5]. Therefore, the host should have an entry in its address resolution table for the new ARP Helper Address 📒.

If the host is unable to resolve the next-hop IP address advertised in the ICMP Redirect (e.g., because the associated ARP Helper Address is on a foreign IP network; i.e., was learned via an old ICMP Redirect, and the address resolution table entry for that ARP Helper Address timed out), the host must flush the associated routing table entry 🗑️. Directed ARP procedures do not recursively use Directed ARP to resolve an ARP Helper Address 🔁🚫.

A router that performs Directed ARP procedures might advertise a foreign next-hop to a host that does not perform Directed ARP. Following existing procedures, the host would silently discard the ICMP Redirect. A router that does not implement Directed ARP should not advertise a next-hop on a foreign IP network, as specified by existing procedures. If it did, and the ICMP Redirect was received by a host that implemented Directed ARP procedures, the host would send an ARP Request for the foreign IP address to the advertising router, which would silently discard the ARP Request. When address resolution fails, the host should flush the associated entry from its routing table 🙃.

For various reasons a host may ignore an ICMP Redirect and may continue to forward packets to the same router that sent the ICMP Redirect. For example, a host that does not implement Directed ARP procedures would silently discard an ICMP Redirect advertising a next-hop address on a foreign IP network 🤐. Routers should implement constraints to control the number of ICMP Redirects sent to hosts 🚦. For example, a router might limit the number of repeated ICMP Redirects sent to a host to no more than N ICMP Redirects per T minutes, where N and T are administered values ⏳.

4.2. Distance Vector Routing Protocol 📡

A distance-vector routing protocol provides procedures for a router to advertise a destination address (e.g., an IP network), an associated next-hop address, and other information (e.g., associated metric) 📣. But a router can not use an advertised route unless the router has a procedure to resolve the advertised next-hop address to its associated link level address. Directed ARP is a procedure that a router could use to resolve an advertised next-hop address, even if the router does not have an address on the same IP network as the advertised next-hop address 🫶.

The following procedures assume a router only accepts routing updates if it knows the IP address of the sender of the update, can resolve the IP address of the sender to its associated link level address, and has an interface on the same link level network as the sender 🔐.

A router that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry 📝. The ARP Helper Address associated with an entry learned via a routing protocol update is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and NULL ARP Helper Address (i.e., the router already knows how to resolve the next-hop address). Otherwise, the ARP Helper Address is the IP address of the router that sent the routing update 💫.

Some distance-vector routing protocols (e.g., BGP [3]) provide syntax that would permit a router to advertise an address on a foreign IP network as a next-hop. If a router that implements Directed ARP procedures advertises a foreign next-hop IP address to a second router that does not implement Directed ARP procedures, the second router can not use the advertised foreign next-hop 😬. Depending on the details of the routing protocol implementation, it might be appropriate for the first router to also advertise a next-hop that is not on a foreign IP network (e.g., itself), perhaps at a higher cost 💸. Or, if the routing relationship is an administered connection (e.g., BGP relationships are administered TCP/IP connections), the administrative procedure could determine whether foreign next-hop IP addresses should be advertised 📋.

A distance-vector routing protocol could advertise that a destination is directly reachable by specifying that the router receiving the advertisement is, itself, the next-hop to the destination. In addition, the advertised metric for the route might be zero. If the router did not already have a routing table entry that specified the advertised destination was local (i.e., NULL next-hop address), the router could add the new route with NULL next-hop, and the IP address of the router that sent the update as ARP Helper Address 🏁.

4.3. Link State Routing Protocol ✨

okay so a link-state routing protocol is how routers figure out what they're linked to (other routers and networks, bestie 🧚), how much each of those links costs, and then reliably spread that link-state info to every other router in the routing domain. then they use all that info to calculate their routes 💅. a router with an interface to two (or more) IP networks through the same link-level interface is connected to those networks by a single link, same as we covered above 🎀. if a router could advertise that it used the same link to reach both networks and it did Directed ARP, routers on either network could send packets straight to hosts and routers on both networks, using Directed ARP to resolve addresses on the foreign IP network 😭. with Directed ARP, the direct path to the foreign IP network would cost less than going through the router that has addresses on both networks 🔥.

to get those Directed ARP perks, the link-state routing protocol must include procedures so a router can advertise connectivity to multiple IP networks over the same link. the routing table calculation must also include procedures to calculate ARP Helper Addresses, plus procedures to accurately calculate the reduced cost of the path to a foreign IP network that gets reached directly via Directed ARP 🧁.

the Shortest Path First algorithm for calculating least cost routes is based on Dijkstra's work [7], and it was first used in a routing protocol by the ARPANET, as described by McQuillan [8] 🦋. a router builds its routing table by making a shortest path tree with itself as the root 🌳. the process is iterative. it starts with no entries on the shortest path tree, and the router itself is the only entry in the list of candidate vertices. then the router loops on these two steps:

Remove the entry from the candidate list that is closest to root, and add it to the shortest path tree.
Examine the link state advertisement from the entry added to the shortest path tree in step 1. For each neighbor (i.e., router or IP network to which a link connects):
- If the neighbor is already on the shortest path tree, do nothing.
- If the neighbor is on the candidate list, recalculate the distance from root to the neighbor. Also recalculate the next-hop(s) to the neighbor.
- If the neighbor is not on the candidate list, calculate the distance from root to the neighbor and the next-hop(s) from root to the neighbor, and add the neighbor to the candidate list.

the whole thing wraps up when there are no entries left on the candidate list 🏁.

to take advantage of Directed ARP, the link-state protocol must provide procedures to advertise that a router accesses two or more IP networks via the same link. on top of that, the Shortest Path First calculation gets modified so it can calculate ARP Helper Addresses and recognize the path cost reductions achieved via Directed ARP ✨.

If a neighbor under consideration is an IP network, and its parent (i.e., the entry added to the shortest path tree in step 1, above) has advertised that the neighbor is reached via the same link as a network that is already on the shortest path tree, the distance from root and next-hop(s) from root to the neighbor are the same as the distance and next-hop(s) associated with the network already on the shortest path tree. If the ARP Helper Address associated with the network that is already on the shortest path tree is not NULL, the neighbor also inherits the ARP Helper Address from the network that is already on the shortest path tree.
If the calculated next-hop to the neighbor is not NULL, the neighbor inherits the ARP Helper Address from its parent. Otherwise, except as described in item 1, the ARP Helper Address is the IP address of the next-hop to the neighbor's parent. Note that the next-hop to root is NULL.

for each router or IP network on the shortest path tree, the Shortest Path First algorithm described above must calculate one or more next-hops that can be used to access it. a router that advertises a link to an IP network must include an IP address that other routers on that IP network can use when they pick the router as a next-hop. a router might advertise that it's connected to two IP networks via the same link by advertising the same next-hop IP address for access from both IP networks. to keep the address resolution constraints of routers on both IP networks happy, the router might advertise two IP addresses (one from each IP network) as next-hop IP addresses for access from both IP networks 🫶.

5. Robustness 🛡️

hosts and routers can use Directed ARP to resolve third-party next-hop addresses, which are next-hop addresses they learned from a routing protocol peer or from their current next-hop router 💜. an undetected failure of a third-party next-hop can lead to a routing "black hole" 🕳️. to avoid "black holes", host requirements [5] say that a host "...MUST be able to detect the failure of a 'next-hop' gateway that is listed in its route cache and to choose an alternate gateway." a host may get feedback from protocol layers above IP (e.g., TCP) that shows the status of a next-hop router, and it may use other procedures (e.g., ICMP echo) to test that status too. but the complexity of routing is mostly carried by routers, whose routing information must be consistent with the information known to their peers 🧠.

routing protocols such as BGP [3], OSPF [4], and others require that routers must stand behind the routing information that they advertise. routers tag routing information with the IP address of the router that advertised it. if the information becomes invalid, the router that advertised it must advertise that the old information is no longer valid. if a source of routing information becomes unavailable, all information received from that source must be marked as no longer valid. the complexity of dynamic routing protocols comes from procedures that make sure routers either receive routing updates sent by a peer, or can determine that they didn't receive those updates (e.g., because connectivity to the peer is no longer available) 🌀.

third-party next-hops can also cause "black holes" if the underlying link layer network connectivity is not transitive. for example, SMDS filters [9] could be set up to permit communication between the SMDS addresses of router R1 and router R2, and between the SMDS addresses of router R2 and router R3, while blocking communication between the SMDS addresses of router R1 and router R3. router R2 could advertise router R3 as a next-hop to router R1, but the SMDS filters would prevent direct communication between router R1 and router R3. non-symmetric filters might permit router R3 to send packets to router R1, but block packets sent by router R1 addressed to router R3 💀.

those filters are the sneaky part: traffic can work one way and still get blackholed the other way 🙈

a host or router could verify link level connectivity with a next-hop router by sending an ICMP echo to the link level address of the next-hop router. (Note that the ICMP echo is sent directly to the link level address of the next-hop router, and is not routed to the IP address of the next-hop router. If the ICMP echo is routed, it may follow a path that does not verify link level connectivity.) this test could be performed before adding the associated routing table entry, or before the first use of the routing table entry. detecting later changes in link level connectivity is a dynamic routing protocol issue and is beyond the scope of this memo 🎀.

References 📚

[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., November 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.

Security Considerations 🔒

security issues are not discussed in this memo 🙈

Authors' Addresses 💌

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

📦 where this page comes from

ietf: rfc1433 1993-03
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms