... >> Sending ARP Replies using broadcast does increase broadcast traffic, >> but in the worst case by no more than a factor of two. In the >> traditional usage of ARP, a unicast ARP Reply only occurs in response >> to a broadcast ARP Request, so sending these via broadcast instead >> means that we generate at most one broadcast Reply in response to >> each existing broadcast Request. On many networks, ARP traffic is >> such an insignificant proportion of the total traffic that doubling >> it makes no practical difference. However, this may not be true of >> all networks, so broadcast ARP Replies SHOULD NOT be used >> >> Spencer: slightly confused about why SHOULD NOT, if this is not a >> problem in most cases. Is this stronger (or broader) than it needs to be? > > The "SHOULD NOT" term is used in the "harm to the network" sense, i.e. > "Some people argued that broadcast replies will cause harm to the > network, so don't do it unless you really know what you're doing, and > have a very good reason to go against what the RFC recommends, and are > willing to defend your decision to all those people who will scream that > you're causing harm to their networks."
Back in the days of large bridged networks, redundant broadcasts of any kind were regarded as highly undesirable. Every bridge and every host stack had to process the packet, and this definitely seemed like a Bad Thing. I don't recall that broadcast ARP replies were ever proved to start ARP storms, but I was certainly paranoid about that sort of thing. I think a SHOULD NOT is quite defensible. Brian _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
