netdev - Re: ARP response with link local IP, why not broadcast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55AF4B1D.4030208@gmx.de>
Date:	Wed, 22 Jul 2015 09:49:49 +0200
From:	Sebastian Fett <db_extern@....de>
To:	Sowmini Varadhan <sowmini05@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: ARP response with link local IP, why not broadcast

> On Tue, Jul 21, 2015 at 4:38 PM, Sebastian Fett <db_extern@....de> wrote:
>> Hello!
>>
>> According to RFC3927 every ARP packet (reply and request) should be sent as
>> link layer broadcast as long as the sender IP is a link local address. (see
>> chapter 2.5).
>
> Because broadcast replies are noisy and should be avoided.
> if possible- it creates a broadcast flood that would wake up all receivers,
> and is especially undesirable in today's world, where bcast would wake
> up sleepy devices, or require other inefficient processes in a cloud env.
> See also https://www.ietf.org/id/draft-nordmark-6man-dad-approaches-01.txt
>
>> That functionality would help me a lot with a use case I have with our
>> application.
>
> what is your use case?
>

My problem ist a local network of audio devices. It is a valid 
possibility that two halfs of the setup are set up individually (Stage 
left and stage right). Both local networks will auto configure 
themselves via link local and will be stable. But there always can be 
two devices with the same IP in both networks.
At one point those two networks will be connected. With the current 
behaviour the conflicting devices will never know of each other and the 
address conflict.
The devices are controlled by a central PC using avahi/bonjour. It will 
know of all conflicting devices, but will only be able to talk to the 
one that happens to be in it's ARP cache. And renewing that cache will 
not change anything, because it will happen with unicast messages.

I looked at a Dante Controller (an audio data streaming device). And 
here all ARP messages are answered with broadcasts.

I think that behaviour is acceptable because it only happens in local 
networks. Waking up sleeping devices will not be a concern there.

That brings me to another question. When I react to an ARP packet in a 
userspace program, can I keep that packet from reaching the kernel as 
well? I would like to avoid to completely handle ARP in userspace.

>>
>> But it is not implemented in the kernel that way.
>> Does anyone know why?

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html