ARP messages: Request, Reply, Probe, Announcement

Konstantin Shemyak — Tue, 26 Jan 2016 18:46:00 GMT

ARP, as originally specified in RFC 826, had two message types: REQUEST and REPLY. But besides that one can hear of two "other" ARP messages: PROBE ANNOUNCEMENT, the latter also called "gratuitous ARP". They happen when a host send the reply message not in response to any preceding request; this has been formalized in RFC 5227.

One may find confusing that:

The two "new" messages do not extend the protocol. In particular, they do not introduce new ARP message types. How can we speak about "new messages"?
Source and destination MAC addresses are present in the MAC headers, but there are also "Source Hardware Address" and "Target Hardware Address" fields in the ARP body. Why this duplication?

These two questions are related. The table below shows the MAC headers and (relevant) ARP protocol fields for each of the four messages. The differences help to understand how each field is used.

Message	Sent when the host...	MAC headers		ARP body
Message	Sent when the host...	src MAC	dst MAC	message type	Source Hardware Address	Source Protocol Address	Target Hardware Address	Target Protocol Address
request	wants to send an IP packet, but does not know the MAC address of the destination	own	broadcast	REQUEST	own	own	0	destination's
reply	receives an ARP request to an IP address this host owns	own	destination's, or broadcast¹	REPLY	own	own	requestor's	requestor's
probe (RFC 5227, 2.1)	configures a new IP address for an interface	own	broadcast	REQUEST²	own	0³	0	probed
announcement (RFC 5227, 2.3)	after a probe, concludes that it will use the probed address	own	broadcast	REQUEST²	own	new own	0	new own

Notes to the table

RFC 5227, section 2.6 explains why "Broadcast replies are not universally recommended, but may be appropriate in some cases".
RFC 5227, section 3 notes that the type here could be REPLY as well, then continues to give reasons why REQUEST is recommended.
Zero is specified here in order not to pollute ARP caches of other hosts in case when the probed address is already taken by someone else.

Possible implications of netmask mismatch

Konstantin Shemyak — Sat, 03 Oct 2015 10:51:00 GMT

Summary: an IPv4 host with a netmask not matching that of the subnet to which the interface is connected likely builds incorrect routing tables, misses some broadcasts, may incorrectly identify broadcasts as unicasts, and unintentionally broadcast to own subnet.

What does it mean - a "wrong netmask"?

The netmask (in IPv4 terminology) and network prefix (in IPv6 terminology) can be associated with an IP subnet, and correspondingly with a network interface. This post handles IPv4 only, so the term "netmask" will be used. Together with own IP address, the netmask determines whether another IP address belongs to the same IP subnet as the NIC.

Good, so how is this knowledge used?

Processing of multicast packets is not affected by the netmask, thus multicast would not be mentioned here further. For unicast and broadcast, the netmask is consulted in three different situations, listed in the following sections.

Case 1. Netmask can be used as input for constructing the routing table.

The routing system normally automatically creates routes to the subnet to which each network interface belongs. I.e. for each network interface I with address AI and netmask M, the host calculates the subnet of this interface as SI = AI & M. Outgoing packets to any address AP such that AP & M = SI would be emitted from the interface I.

While this behavior is typical, nothing mandates hosts to create such routing table entry. For example, if a host has two interfaces on the same subnet, then obviously some more information is needed to decide, which of the interfaces shall emit the packets destined to their common subnet. Another example is a firewall with more restrictive forwarding policy than just "put every packet for subnet SI to interface I".

Case 2. Netmask is used to determine whether an arrived packet is a (directed) broadcast to a subnet of some local interface.

After the routing is covered, we can limit our further investigation to only:

Unicast packets, destined to "this host" (i.e. one of its interfaces).
Directed broadcast packets to "this network". There can be more than one "this" network if the host has more than one network interface (the host can be or not be a router).

Really,

Directed broadcast to a network not in "our network" set is handled as any other packet subject to possible routing.
Local broadcast packets are obviously not affected by the netmask setting.

For hosts which are not routers RFC922 defines handling of broadcast packets in a simple way:

In the absence of broadcasting, a host determines if it is the
recipient of a datagram by matching the destination address against
all of its IP addresses.  With broadcasting, a host must compare the
destination address not only against the host's addresses, but also
against the possible broadcast addresses for that host.

Now imagine that an interface of some host has netmask, which does not match one of the subnet this interface is connected to. This is what happens.

Netmask of the interface is shorter

Interface misconfigured with a shorter netmask fails to process broadcasts: they are understood as unicasts by such host.
Example: in /24 network 1.1.1.0, a packet to a broadcast address 1.1.1.255 will not be recognized as broadcast by a misconfigured interface 1.1.1.1/16.

That is, unless the network has all bits in the netmask difference equal to 1.

Example: in /24 network 1.1.255.0, a packet to a broadcast address 1.1.255.255 will be, by a coincidence, correctly accepted as broadcast by a misconfigured interface 1.1.1.1/16.
Broadcast packet which is incorrectly understood as unicast by a misconfigured interface can also happen to bear the destination address of this interface itself.
Example: in /16 network 1.1.0.0, a broadcast packet to 1.1.255.255 will be received as unicast by a misconfigured interface 1.1.255.255/8.
Additionally, the host may attempt to send a unicast packet which would appear as a valid broadcast on the network.
Example: in /16 network 1.1.0.0, a host misconfigured as 1.1.1.1/8 sends a unicast to destination address 1.1.255.255. It appears as broadcast on this network. In fact, there can be no host with address 1.1.255.255 on this network (as it is a broadcast address), so nobody answers ARP query and the host will not be able to send such packet.

Netmask of the interface is longer

Interface misconfigured with a longer netmask fails to process broadcasts as well: it will consider them not belonging to own subnet.
Example: in /8 network 1.0.0.0, a packet to a broadcast address 1.255.255.255 will not be received by a misconfigured interface 1.1.1.1/16.

Again, unless the address of the misconfigured interface happens to have all bits in the netmask difference being equal to 1.

Example: in that same network, that same broadcast packet will be accepted just fine by a misconfigured interface 1.255.1.1/16.

For hosts which are routers, RFC922 adds the clause concerning for broadcast packets destined to other interface than the one on which the packet is received:

...if the datagram is addressed to a hardware network
to which the gateway is connected, it should be sent as a
(data link layer) broadcast on that network.  Again, the
gateway should consider itself a destination of the datagram.

In this case, the netmask of the router's interface, where the packet has been received, is not relevant - packet should be processed anyway. Instead, the packet's destination interface configuration is the basis for the decision. Correspondingly, mismatch between the netmask of the destination interface and the sender's expectation of the netmask leads to same consequences as listed above for non-forwarding hosts.

Have we covered all cases? Three independent factors affect the outcome:

Is the receiver's netmask shorter or longer than of the subnet it is connected to?
Are the bits from the difference in netmask lengths all equal to one?
Is the packet unicast or (directed) broadcast?

All 8 possibilities have been considered above.

Case 3. Netmask is used for setting destination address of outgoing broadcast packets.

When a host wishes to send a broadcast packet from certain interface, it sets the destination address to that of the interface and puts 1 to all bits which are zeros in the netmask. Correspondingly:

Netmask of the network interface is shorter

Host with shorter netmask will set too many bits to 1. On the local subnet, these packets will be recognized as belonging to other subnet by other hosts and consequently not processed.

Example: in /24 network 1.1.1.0/24, host misconfigured as 1.1.1.1/16 sends what it thinks a "broadcast" with destination 1.1.255.255. (It will be sent as link-layer broadcast.) No other host on this network accepts it.

Unless if the network has all bits in the netmask difference being equal to one.

Example: in /24 network 1.1.255.0/24, a misconfigured host 1.1.255.1/16 sends a "broadcast" packet to 1.1.255.255, which happens to be a valid broadcast on this network.

Netmask of the network interface is longer

Host with longer netmask will not set enough bits to 1. The packets sent as broadcast will be recognized as unicast by other hosts on this subnet.

Example: in /8 network 1.0.0.0/8, a host misconfigured as 1.1.1.1/16 sends what it thinks to be a broadcast packet to 1.1.255.255. It appears as valid unicast on this subnet. If there is a host with address 1.1.255.255, this host will accept this packet. (Besides probably unexpected IP content, the host may also notice that the layer 2 address of this packet was a layer 2 broadcast.)

Naturally, these cases are "reversed" repetition of the cases for the receiving hosts.

Conclusion

Netmask is normally (but not necessarily) used as input for the routing table construction. If used, then a wrong interface netmask makes possible the following routing failures:

Too long netmask: the host will have no route for some packets, actually belonging to a subnet of this interface. Attempt to send packet to a host outside the too long misconfigured netmask but inside the correct netmask of the net results in ICMP error "Destination net unreachable". If there is a default outgoing interface, the host will not generate the error, but send the packets to the default interface instead of the interface of this subnet.
Too short netmask: the host may attempt to send to the interface packets, which would not be received by any host of the connected subnet. This attempt probably fails, because no host answers the ARP request. This results in ICMP error "Destination host unreachable".

In IPv4, directed broadcast packets are sent and received utilizing the netmask information. Directed broadcast is a marginal case; such packets are rarely used and dropped by most routers as per RFC2644. But if directed broadcasts are used, then mismatched netmask results in any of:

failure to receive broadcast packets
failure to forward broadcast packets by routers
forwarding broadcast packets, destined to own network
accepting unicast packets, destined to some host, as broadcasts
accepting broadcast packets as unicast.

Konstantin Shemyak - Tech Notes (Posts about network)