Escalated to Bugzilla from IssueTracker
The duplicate address detection scheme outlined in RFC2131 results in an ARP reply with the source and target addresses being the same. The ARP reply contents are: ARP REQUEST SHA - 00-0A-23-44-2A-3F SPA - 0.0.0.0 THA - 00-00-00-00-00-00 TPA - 192.168.10.1 ARP REPLY SHA - 00-0B-AA-88-C7-1D SPA - 192.168.10.1 THA - 00-0B-AA-88-C7-1D TPA - 192.168.10.1 According to RFC 826, the algorithm should swap the source and target fields: 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. And later, an explanation of target hardware address: The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. We can see the arp.c kernel file calling arp_send with the target ip in the dest_ip and src_ip: /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { if (arp->ar_op == htons(ARPOP_REQUEST) && inet_addr_type(tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } arp_send signature: void arp_send(int type, int ptype, u32 dest_ip, struct net_device *dev, u32 src_ip, unsigned char *dest_hw, unsigned char *src_hw, unsigned char *target_hw) Nothing could be found in any RFC that states an ARP reply can have the same hardware and protocol address for the source and target. This ARP reply is causing problems for some customer applications. From the RFCs and lack of an explanation in the source code, this appears to be a defect.
I'll need to see the complete set of arptables commands they're using on their system. arptables is a dangerous tool that can be configured to break network connectivity in many wierd ways. Most likely they're not DROPping packets that they should, or rewriting them incorrectly.
The system is a normal install of redhat and no modification has been made through arptables. We're simply sending a standard dhcp duplicate address detection ARP packet to a vanilla system and are not receiving the correct response. When we send: ARP REQUEST SHA - 00-0A-23-44-2A-3F SPA - 0.0.0.0 THA - 00-00-00-00-00-00 TPA - 192.168.10.1 We SHOULD see: ARP REPLY SHA - 00-0B-AA-88-C7-1D SPA - 192.168.10.1 THA - 00-0A-23-44-2A-3F TPA - 0.0.0.0 However, we are seeing: ARP REPLY SHA - 00-0B-AA-88-C7-1D SPA - 192.168.10.1 THA - 00-0B-AA-88-C7-1D TPA - 192.168.10.1 Since we have done no mangling of arp packets on the RedHat system via arptables, we believe this is a violation of the Address Resolution module algorithm outlined in RFC 826.
If you aren't using arptables, why did you open this bug against the arptables package? I'm assuming you meant to open this against the kernel, and brainod it, so I'm reassigning it to the kernel maintainers.
Oops, sorry.
There is nothing explicitly forbidding both target and source being the same. If you can find chapter and verse of an RFC which explicitly forbids this, I'll look into fixing it. But it's totally legal as far as I can tell, and we've behaved this way for many years and this is the first complaint I've ever header of about this issue.