My question is, when host B receives the message, does it update the
ARP table to have the MAC address of host A automatically, or will it
have to send an ARP broadcast to find host A the next time it wants to
communicate to host A?
Only ARP messages update an ARP table.
ARP is a process, like IPv4 is a process. Ethernet has an EtherType field (other IEEE protocols that use MAC addressing have something similar). The field tells ethernet to which process it should send the payload of the frame.
When the EtherType is 0x0800, the frame payload is sent to IPv4 because it is an IPv4 packet; when the EtherType is 0x86dd, the frame payload is sent to IPv6 because it is an IPv6 packet; when the EtherType is 0x0806 the frame payload is sent to ARP because it is an ARP packet. As you can see, ARP never sees any packets except ARP packets.
This may seem a weakness, but it is by design. Ethernet has a lot of broadcasts for various reasons, and a host must process all of them to see if the broadcast pertains to it. Many of the broadcasts are for ARP, but other broadcasts are for other reasons, and you would be putting entries into the ARP table for hosts with which your host has no interest in communicating. Even a host seeing an ARP broadcast not destined for it will first check to see if the source host is in its ARP table. If so, it updates the ARP table, if not, it ignores it. This may not seem like a big deal today, but back when hosts (even what were considered large hosts) had minimal RAM, it was a very big deal. ARP was defined in 1982, when IBM PCs (released in 1981) were still shipping with 64K of RAM.
ARP is detailed in RFC 826, An Ethernet Address Resolution Protocol, and it has pseudo code for how to process received ARP packets:
Negative conditionals indicate an end of processing and a discarding
of the packet.
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
