Hi,
The following lines from arp.c refer to somethign in RFC2131 as an excuse for
sending out a malformed arp packet.
/* Special case: IPv4 duplicate address detection packet (RFC2131) */
if (sip == 0) {
if (arp->ar_op == __constant_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;
}
In practice, when using a dhcp relay agent, and a client
(PowerPC Open Firmware in this example) sends a "gratutitous arp"
'arp who-has' from 0.0.0.0 to 192.168.2.1 for example,
the above lines of code send an arp reply that does not have the mac address
of the interface that made the 'arp who-has' and thus this interface
is not able to see the reply. This means that now 192.168.2.1
is invisible to this machine and it can communicate with it.
Asjusting the above line to :
arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);
fixes the problem and normal communication can occur.
This of course makes this paragraph completely irrelevant.
Furthemre the following section from RFC2131 makes NO reference
to sending an arp packet with such a malformed structure.
"must fill in its own hardware address as the sender's hardware address"
is not strange behaviour, and DOES NOT refer to what a machine should
do when it RECEIVES an arp request packet from IP 0.0.0.0, but refers to
what a machine should do when it SENDS a gratuitous arp packet, one that
is not a response to an 'arp who-has' but IS an 'arp who-has'.
RFC2131 snippet BEGIN
The client SHOULD perform a check on the
suggested address to ensure that the address is not already in use. For
example, if the client is on a network that supports ARP, the client may
issue an ARP request for the suggested request. When broadcasting an ARP
request for the suggested address, the client must fill in its own hardware
address as the sender's hardware address, and 0 as the sender's IP address,
to avoid confusing ARP caches in other hosts on the same subnet. If the
network address appears to be in use, the client MUST send a DHCPDECLINE
message to the server. The client SHOULD broadcast an ARP reply to announce
the client's new IP address and clear any outdated ARP cache entries in
hosts on the client's subnet.
RFC2131 snippet END
Furthermore,
In http://alternic.net/drafts/drafts-j-k/draft-jou-duplicate-ip-address-01.html
Which Updates RFC 826
We see reference to the gratuitous arp packet reception and the proper reply.
BEGIN snippet
(ii) If a host receives an ARP request packet in which the
Target IP address and the Sender IP address are the same and it
matches one of its interface addresses, it then implies
IP address duplication happens. The host MUST send a link layer
broadcast ARP reply as defined below. The host MAY also log or
display warning messages to indicate the detection of IP address
duplication.
48.bit Destination Address = 0xffffffffffff (broadcast)
48.bit Source Address = Hardware adderss of interface
16.bit Frame type = 0x806 (ARP)
----------------------
16.bit Hardware type = 0x1 (Ethernet)
16.bit Protocol Type = 0x800 (IP)
8.bit Hardware Address size = 6
8.bit Protocol Address size = 4
16.bit Opcode = 2 (Reply)
48.bit Sender Ethernet Address = Hardware address of interface
32.bit Sender IP Address = Local IP address
48.bit Target Ethernet Address = Sender Addr in Request packet
32.bit Target IP Address = Local IP Address
END snippet
So here yes we see sender and target IP and ethernet addresses being
sent out as the local addresses, but note that the first two lines refer to
(ii) If a host receives an ARP request packet in which the
Target IP address and the Sender IP address are the same and it
So again, how does the snippet of code at the top of this message from arp.c
in any way follow this scheme. It looks for arp packets from 0.0.0.0
not packets with 'target and sender IP address are the same'.
So, can we have this apparently stupid error fixed please.
.. or can someone show the stupidity in my reasoning.
Kind regards,
Peter
Hello,
[email protected] wrote:
> 16.bit Opcode = 2 (Reply)
> 48.bit Sender Ethernet Address = Hardware address of interface
> 32.bit Sender IP Address = Local IP address
> 48.bit Target Ethernet Address = Sender Addr in Request packet
> 32.bit Target IP Address = Local IP Address
It seems in this experimental draft we see that the symmetry
is broken. The reply is from SIP to TIP and both are "Local IP address"
but the SHA and THA are different. When in replies SIP==TIP this is
something like we reply ourselfs. IMO, the same should be for SHA and
THA. Why to do duplicate address detection with SIP loaded with TIP?
There is already a way to do DAD: with SIP=0. May be the authors don't
know this solution? SIP=0 is used exactly for this purpose, not to
disturb the other hosts that already know TIP by some MAC. In this
draft I was not able to understand how DAD is performed. Of course,
with any mechanism used there is a race where two host can do DAD,
then nobody replies and then the both decide to configure the IPs.
But then who will agree to remove its IP? Someone would require
election process, something like VRRP. Or may be to configure the
IP (but not to advertise it if other hosts ask, i.e. passive mode),
to do DAD with SIP 0, to wait 1-2 seconds (or short random time) and
during that time to listen for remote hosts doing DAD and if
there are no other hosts that do DAD to advertise the IP. I agree that
after the IP is configured gratuitous ARP can be sent (and it is used in
setups where the IP is moved between the hosts to update the cached
values in remote caches) but I'm not sure the proposed scheme to remove
the duplicated IP is the best we can see, how you feel it?:
[
(iii) If a host receives an ARP reply with both sender IP address
and the target IP address fields match one of its interfaces,
it MUST turn off the interface to stop using this address.
It May log or display warning messages to indicate the error.
]
What happens if we don't want to do it? Also, think for
shared IP addresses (same IP on many hosts, not advertised with
ARP from all hosts but still configured on some interface).
> So again, how does the snippet of code at the top of this message from arp.c
> in any way follow this scheme. It looks for arp packets from 0.0.0.0
> not packets with 'target and sender IP address are the same'.
IMO, the clients that do duplicate address detection shouldn't
drop replies that have THA != Destination Hardware Address. What is
that? A security measure? Linux does not check THA at all. And DAD
should be performed with SIP=0, why with SIP==TIP and when detection
is detected (and the remote caches damaged) the TIP to be unconfigured?
SIP=0 is the only way not to disturb the others because both the
requests and the replies with SIP!=0 can damage the caches (because
they are broadcasts destined to ff:ff:ff:ff:ff:ff).
If your fix works for "PowerPC Open Firmware" then this
stack performs extra checks that I'm not sure they are specified
somewhere and are needed at all. May be I'm missing some standard?
Regards
--
Julian Anastasov <[email protected]>
> Hello,
hi.
> > 16.bit Opcode = 2 (Reply)
> > 48.bit Sender Ethernet Address = Hardware address of interface
> > 32.bit Sender IP Address = Local IP address
> > 48.bit Target Ethernet Address = Sender Addr in Request packet
> > 32.bit Target IP Address = Local IP Address
> THA. Why to do duplicate address detection with SIP loaded with TIP?
> There is already a way to do DAD: with SIP=0. May be the authors don't
> know this solution? SIP=0 is used exactly for this purpose, not to
Could you point me to some documentation on this method, if you know
where some is ?
> election process, something like VRRP. Or may be to configure the
VRRP ?
> values in remote caches) but I'm not sure the proposed scheme to remove
> the duplicated IP is the best we can see, how you feel it?:
I would have to study the problem in more depth to give a good answer,
I am primarily concerned with not having to maintain a 'personal'
kernel patch to get DHCP relaying to work for G4's. I doubt
writing Apple would get any responses :(
> [
> (iii) If a host receives an ARP reply with both sender IP address
> and the target IP address fields match one of its interfaces,
> it MUST turn off the interface to stop using this address.
> It May log or display warning messages to indicate the error.
> ]
>
> What happens if we don't want to do it? Also, think for
> shared IP addresses (same IP on many hosts, not advertised with
> ARP from all hosts but still configured on some interface).
I agree this MUST is overkill. but then also
'what is we want to send a normal arp packet ?'
> IMO, the clients that do duplicate address detection shouldn't
> drop replies that have THA != Destination Hardware Address. What is
> that? A security measure? Linux does not check THA at all. And DAD
I believe this is common behaviour for non-promiscuous interfaces .. ?
I agree it would be nicer if it didn't drop it but it does, and
DHCP relaying is a perfectly valid thing to do, so the current
code breaks this (for the G4 OF, possibly for other platforms as well).
> Should be performed with SIP=0, why with SIP==TIP and when detection
> is detected (and the remote caches damaged) the TIP to be unconfigured?
> SIP=0 is the only way not to disturb the others because both the
> requests and the replies with SIP!=0 can damage the caches (because
> they are broadcasts destined to ff:ff:ff:ff:ff:ff).
Indeed that experimental document does not address arp cache corruption
at all. Presumably hosts would have to ignore packets
that have SIP and TIP the same unless it is what they are using...
> If your fix works for "PowerPC Open Firmware" then this
> stack performs extra checks that I'm not sure they are specified
> somewhere and are needed at all. May be I'm missing some standard?
Who can we ask for an answer as to why this might be done ?
Hmm. http://www.freesoft.org/CIE/RFC/826/6.htm
Shows a pseudo-code that indicates a check should
be performed to see if THA is "ours" and if not, discard the packet
-- BEGIN snippet --
When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an
algorithm similar to the following. 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 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:
-- END snippet --
Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?
Regards,
Peter
> When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an
> algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet.
> ?Am I the target protocol address?
> Yes:
> Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?
No. Shake my head, the above is a reference to TIP, not THA.
and DHA is already set correctly anyway. (what was I drinking..)
Anyway.. RFC2131 only talks about the format of the arp request and not of
the arp reply. I will test again to see if OF is testing THA or TIP.
My guess is TIP.
So how to get the fix incorporated into the kernel though.
I don't see why it would break anything else.
Peter
In article <20011125181921.A16765@panama> you wrote:
> Shows a pseudo-code that indicates a check should
> be performed to see if THA is "ours" and if not, discard the packet
Ethernet cards are dropping other addresses, but if it is in promisc mode it
may catch some miss addressed. Therefore Linux Kernel is checking all
incoming frames and mark them OTHERHOST. This means they can travel up the
packet capture sockets, but are never handed to application tcp/udp sockets.
Greetings
Bernd
Hello,
On Sun, 25 Nov 2001 [email protected] wrote:
> > THA. Why to do duplicate address detection with SIP loaded with TIP?
> > There is already a way to do DAD: with SIP=0. May be the authors don't
> > know this solution? SIP=0 is used exactly for this purpose, not to
>
> Could you point me to some documentation on this method, if you know
> where some is ?
You already mentioned it, DHCP SHOULD use SIP=0.0.0.0.
> > election process, something like VRRP. Or may be to configure the
>
> VRRP ?
RFC2338. It guarantees unique IP but tries to keep the MAC.
It has other purposes.
> I am primarily concerned with not having to maintain a 'personal'
> kernel patch to get DHCP relaying to work for G4's. I doubt
> writing Apple would get any responses :(
Hm
> I agree this MUST is overkill. but then also
> 'what is we want to send a normal arp packet ?'
Can you explain? I don't understand the Q
> > IMO, the clients that do duplicate address detection shouldn't
> > drop replies that have THA != Destination Hardware Address. What is
> > that? A security measure? Linux does not check THA at all. And DAD
>
> I believe this is common behaviour for non-promiscuous interfaces .. ?
No, the ARP reply is destined directly to the target MAC but
with ARP data SIP==TIP and SHA==THA, i.e. THA!=target MAC
> > If your fix works for "PowerPC Open Firmware" then this
> > stack performs extra checks that I'm not sure they are specified
> > somewhere and are needed at all. May be I'm missing some standard?
>
> Who can we ask for an answer as to why this might be done ?
If the maintainers don't read this thread then contact them
directly. I'm not sure there is a standard for duplicate address
detection. For now ARP is used to do the detection but without
protocol adapted from all vendors I'm not sure it will be race-free.
There are other client-server oriented protocols where the server
guarantees that the given IP is unique. I don't see an easy solution for
DAD for other purposes, i.e. when two hosts try to use same IP without
obtaining it from some authority. May be this is the reason iproute2 to
come with script (user space solution) to configure the IP addresses.
In this case the gap for race is small.
> Maybe the right fix then is to set DHA to all ones. ffffffffffff. ?
You can try to feed the arp_send call that you change with
dest_hw=NULL and to see whether it works. If it works you will have
a second solution. In any case you need the maintainers' opinion
because it seems nobody recommends anything about the ARP replies,
i.e. for THA when SIP==TIP.
You are not sure it will not break something else (answering your
next posting). You can also look at RARP (RFC903) where THA==Target MAC
is already a requirement but the request is SIP=0 and TIP=0 (similar
but not related to DAD). RFC2131 states that the client SHOULD perform
DAD for the suggested address from DHCP. Later: "may issue an ARP request".
It seems Linux doesn not like these recommendations.
> Regards,
>
> Peter
Regards
--
Julian Anastasov <[email protected]>
Hello!
> directly. I'm not sure there is a standard for duplicate address
> detection.
The procedure is prescribed in rfc on dhcp, which is sort of standard.
> In this case the gap for race is small.
There is no races there. Before DAD did not pass address must not be used,
that's all. This is also described unambigously in dhcp specs.
Alexey