1arp(7P) Protocols arp(7P)
2
6 arp, ARP - Address Resolution Protocol
7
9 #include <sys/fcntl.h>
10 #include <sys/socket.h>
13 #include <net/if_arp.h>
16 #include <netinet/in.h>
19 s = socket(AF_INET, SOCK_DGRAM, 0);
22 d = open ("/dev/arp", oflag);
25
28 ARP is a protocol used to map dynamically between Internet Protocol
29 (IP) and Ethernet addresses. It is used by all Ethernet datalink
30 providers (network drivers) and can be used by other datalink providers
31 that support broadcast, including FDDI and Token Ring. The only net‐
32 work layer supported in this implementation is the Internet Protocol,
33 although ARP is not specific to that protocol.
34 ARP caches IP-to-link-layer address mappings. When an interface
37 requests a mapping for an address not in the cache, ARP queues the mes‐
38 sage that requires the mapping and broadcasts a message on the associ‐
39 ated network requesting the address mapping. If a response is provided,
40 ARP caches the new mapping and transmits any pending message. ARP will
41 queue a maximum of four packets while awaiting a response to a mapping
42 request. ARP keeps only the first four transmitted packets.
43
45 The STREAMS device /dev/arp is not a Transport Level Interface (TLI)
46 transport provider and may not be used with the TLI interface.
47 To facilitate communications with systems that do not use ARP,
50 ioctl() requests are provided to enter and delete entries in the
51 IP-to-link address tables. Ioctls that change the table contents
52 require sys_net_config privilege. See privileges(5).
53 #include <sys/sockio.h>
55 #include <sys/socket.h>
56 #include <net/if.h>
57 #include <net/if_arp.h>
58 struct arpreq arpreq;
59 ioctl(s, SIOCSARP, (caddr_t)&arpreq);
60 ioctl(s, SIOCGARP, (caddr_t)&arpreq);
61 ioctl(s, SIOCDARP, (caddr_t)&arpreq);
62 SIOCSARP, SIOCGARP and SIOCDARP are BSD compatible ioctls. These ioctls
66 do not communicate the mac address length between the user and the ker‐
67 nel (and thus only work for 6 byte wide Ethernet addresses). To manage
68 the ARP cache for media that has different sized mac addresses, use
69 SIOCSXARP, SIOCGXARP and SIOCDXARP ioctls.
70 #include <sys/sockio.h>
72 #include <sys/socket.h>
73 #include <net/if.h>
74 #include <net/if_dl.h>
75 #include <net/if_arp.h>
76 struct xarpreq xarpreq;
77 ioctl(s, SIOCSXARP, (caddr_t)&xarpreq);
78 ioctl(s, SIOCGXARP, (caddr_t)&xarpreq);
79 ioctl(s, SIOCDXARP, (caddr_t)&xarpreq);
80 Each ioctl() request takes the same structure as an argument.
84 SIOCS[X]ARP sets an ARP entry, SIOCG[X]ARP gets an ARP entry, and
85 SIOCD[X]ARP deletes an ARP entry. These ioctl() requests may be applied
86 to any Internet family socket descriptors, or to a descriptor for the
87 ARP device. Note that SIOCS[X]ARP and SIOCD[X]ARP require a privileged
88 user, while SIOCG[X]ARP
89 does not.
92 The arpreq structure contains
95 /*
97 * ARP ioctl request
98 */
99 struct arpreq {
100 struct sockaddr arp_pa; /* protocol address */
101 struct sockaddr arp_ha; /* hardware address */
102 int arp_flags; /* flags */
103 };
104 The xarpreq structure contains:
108 /*
110 * Extended ARP ioctl request
111 */
112 struct xarpreq {
113 struct sockaddr_storage xarp_pa; /* protocol address */
114 struct sockaddr_dl xarp_ha; /* hardware address */
115 int xarp_flags; /* arp_flags field values */
116 };
117 #define ATF_COM 0x2 /* completed entry (arp_ha valid) */
118 #define ATF_PERM 0x4 /* permanent (non-aging) entry */
119 #define ATF_PUBL 0x8 /* publish (respond for other host) */
120 #define ATF_USETRAILERS 0x10 /* send trailer pckts to host */
121 #define ATF_AUTHORITY 0x20 /* hardware address is authoritative */
122 The address family for the [x]arp_pa sockaddr must be AF_INET. The
126 ATF_COM flag bits ([x]arp_flags) cannot be altered. ATF_USETRAILERS
127 is not implemented on Solaris and is retained for compatibility only.
128 ATF_PERM makes the entry permanent (disables aging) if the ioctl()
129 request succeeds. ATF_PUBL specifies that the system should respond to
130 ARP requests for the indicated protocol address coming from other
131 machines. This allows a host to act as an ARP server, which may be use‐
132 ful in convincing an ARP-only machine to talk to a non-ARP machine.
133 ATF_AUTHORITY indicates that this machine owns the address. ARP does
134 not update the entry based on received packets.
135 The address family for the arp_ha sockaddr must be AF_UNSPEC.
138 Before invoking any of the SIOC*XARP ioctls, user code must fill in the
141 xarp_pa field with the protocol (IP) address information, similar to
142 the BSD variant. The SIOC*XARP ioctls come in two (legal) varieties,
143 depending on xarp_ha.sdl_nlen:
144 1. if sdl_nlen = 0, it behaves as an extended BSD ioctl. The
146 kernel uses the IP address to determine the network inter‐
147 face.
148 2. if (sdl_nlen > 0) and (sdl_nlen < LIFNAMSIZ), the kernel
150 uses the interface name in sdl_data[0] to determine the net‐
151 work interface; sdl_nlen represents the length of the string
152 (excluding terminating null character).
153 3. if (sdl_nlen >= LIFNAMSIZ), an error (EINVAL) is flagged
155 from the ioctl.
156 Other than the above, the xarp_ha structure should be 0-filled except
159 for SIOCSXARP, where the sdl_alen field must be set to the size of
160 hardware address length and the hardware address itself must be placed
161 in the LLADDR/sdl_data[] area. (EINVAL will be returned if user speci‐
162 fied sdl_alen does not match the address length of the identified
163 interface).
164 On return from the kernel on a SIOCGXARP ioctl, the kernel fills in the
167 name of the interface (excluding terminating NULL) and its hardware
168 address, one after another, in the sdl_data/LLADDR area; if the two are
169 larger than can be held in the 244 byte sdl_data[] area, an ENOSPC
170 error is returned. Assuming it fits, the kernel will also set sdl_alen
171 with the length of hardware address, sdl_nlen with the length of name
172 of the interface (excluding terminating NULL), sdl_type with an IFT_*
173 value to indicate the type of the media, sdl_slen with 0, sdl_family
174 with AF_LINK and sdl_index (which if not 0) with system given index for
175 the interface. The information returned is very similar to that
176 returned via routing sockets on an RTM_IFINFO message.
177 The ARP ioctls have several additional restrictions and enhancements
180 when used in conjunction with IPMP:
181 o ARP mappings for IPMP data and test addresses are managed
183 by the kernel and cannot be changed through ARP ioctls,
184 though they may be retrieved using SIOCGARP or SIOCGXARP.
185 o ARP mappings for a given IPMP group must be consistent
187 across the group. As a result, ARP mappings cannot be
188 associated with individual underlying IP interfaces in an
189 IPMP group and must instead be associated with the corre‐
190 sponding IPMP IP interface.
191 o roxy ARP mappings for an IPMP group are automatically man‐
193 aged by the kernel. Specifically, if the hardware address
194 in a SIOCSARP or SIOCSXARP request matches the hardware
195 address of an IP interface in an IPMP group and the IP
196 address is not local to the system, the kernel regards this
197 as a IPMP Proxy ARP entry. This IPMP Proxy ARP entry will
198 have its hardware address automatically adjusted in order
199 to keep the IP address reachable (provided the IPMP group
200 has not entirely failed).
201 —
202 —
203 —P
204 ARP performs duplicate address detection for local addresses. When a
207 logical interface is brought up (IFF_UP) or any time the hardware link
208 goes up (IFF_RUNNING), ARP sends probes (ar$spa == 0) for the assigned
209 address. If a conflict is found, the interface is torn down. See
210 ifconfig(1M) for more details.
211 ARP watches for hosts impersonating the local host, that is, any host
214 that responds to an ARP request for the local host's address, and any
215 address for which the local host is an authority. ARP defends local
216 addresses and logs those with ATF_AUTHORITY set, and can tear down
217 local addresses on an excess of conflicts.
218 ARP also handles UNARP messages received from other nodes. It does
221 not generate these messages.
222
224 The arp driver registers itself with the netinfo interface. To gain
225 access to these events, a handle from net_protocol_lookup must be
226 acquired by passing it the value NHF_ARP. Through this interface, two
227 packet events are supported:
228 Physical in - ARP packets received via a network inter face
231 Physical out - ARP packets to be sent out via a network interface
234 For ARP packets, the hook_pkt_event structure is filled out as follows:
237 hpe_ifp
239 Identifier indicating the inbound interface for packets received
241 with the physical in event.
242 hpe_ofp
245 Identifier indicating the outbound interface for packets received
247 with the physical out event.
248 hpe_hdr
251 Pointer to the start of the ARP header (not the ethernet
253 header).
254 hpe_mp
257 Pointer to the start of the mblk_t chain containing the ARP packet.
259 hpe_mb
262 Pointer to the mblk_t with the ARP header in it.
264
267 In addition to events describing packets as they move through the
268 system, it is also possible to receive notification of events relating
269 to network interfaces. These events are all reported back through the
270 same callback. The list of events is as follows:
271 plumb
273 A new network interface has been instantiated.
275 unplumb
278 A network interface is no longer associated with ARP.
280
283 arp(1M), ifconfig(1M), privileges(5), if_tcp(7P), inet(7P), netinfo(9F)
284 Plummer, Dave, An Ethernet Address Resolution Protocol or Converting
287 Network Protocol Addresses to 48 .bit Ethernet Addresses for Trans‐
288 mission on Ethernet Hardware, RFC 826, STD 0037, November 1982.
289 Malkin, Gary, ARP Extension - UNARP, RFC 1868, November, 1995
292
294 Several messages can be written to the system logs (by the IP module)
295 when errors occur. In the following examples, the hardware address
296 strings include colon (:) separated ASCII representations of the link
297 layer addresses, whose lengths depend on the underlying media (for
298 example, 6 bytes for Ethernet).
299 Node %x:%x ... %x:%x is using our IP address %d.%d.%d.%d on %s.
301 Duplicate IP address warning. ARP has discovered another host on a
303 local network that responds to mapping requests for the Internet
304 address of this system, and has defended the system against this
305 node by re-announcing the ARP entry.
306 %s has duplicate address %d.%d.%d.%d (in use by %x:%x ... %x:%x); dis‐
309 abled.
310 Duplicate IP address detected while performing initial probing. The
312 newly-configured interface has been shut down.
313 %s has duplicate address %d.%d.%d.%d (claimed by %x:%x ... %x:%x); dis‐
316 abled.
317 Duplicate IP address detected on a running IP interface. The con‐
319 flict cannot be resolved, and the interface has been disabled to
320 protect the network.
321 Recovered address %d.%d.%d.%d on %s.
324 An interface with a previously-conflicting IP address has been
326 recovered automatically and reenabled. The conflict has been
327 resolved.
328 Proxy ARP problem? Node '%x:%x ... %x:%x' is using %d.%d.%d.%d on %s
331 This message appears if arp(1M) has been used to create a pub‐
333 lished permanent (ATF_AUTHORITY) entry, and some other host on the
334 local network responds to mapping requests for the published ARP
335 entry.
336SunOS 5.11 5 Feb 2009 arp(7P)