[Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
Lonnie Abelbeck
lists at lonnie.abelbeck.com
Sun Jul 26 19:36:47 BST 2020
Greetings,
So how would dnsmasq users go about not granting DHCP leases to LAA (anonymous) MAC addresses ?
I liken this to a PBX not accepting calls with anonymous/invalid caller-id entries.
Lonnie
> On Jul 26, 2020, at 10:04 AM, themiron.ru at gmail.com wrote:
>
> Hi,
>
> LAA stands for locally-administrated address itself, so from my opinion "laa-address" is a bit tautologic.
> Let's use just "laa", also it ~fits already used one word tags:
> "bootp"
> "cpewan-id"
> "dhcpv6"
> "known"
> "known-othernet"
> <interface>
> --
> Best Regards, Vladislav Grishenko
>
> -----Original Message-----
> From: Dnsmasq-discuss <dnsmasq-discuss-bounces at lists.thekelleys.org.uk> On Behalf Of Pali Rohar
> Sent: Sunday, July 26, 2020 7:20 PM
> To: dnsmasq-discuss at lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
>
> On Sunday 26 July 2020 15:35:24 Geert Stappers wrote:
>> On Sun, Jul 26, 2020 at 06:07:52AM -0700, dev at lutean.com wrote:
>>>>> iOS 14
>>>>
>>>> CISCO provides an IOS, https://en.wikipedia.org/wiki/Cisco_IOS
>>>> My second guess on IOS is an Apple Computer Inc product.
>>>>
>>>>
>>>>> will by default use randomized, private MAC addresses.
>>>>
>>>> Yeah right, let's sell a depleted MAC address pool as a privacy
>>>> improvement ...
>>>>
>>>
>>> It is an upcoming feature of Apple products that will be on by
>>> default: https://support.apple.com/en-ca/HT211227
>
> Ah :-( So Apple devices would be broken on lot of networks. Another reason why to not buy them. I heard from lot of people that they are not supporting Apple devices on networks anymore and I now I'm seeing reasons for such decisions. Maintaining such crap must be really pain.
>
>>> It is already available through the public beta.
>>>
>>> So Apple devices as of October or sooner will be changing their MAC
>>> addresses by default
>>>
>>>>
>>>>> In my testing these devices use a MAC address with the LAA bit
>>>>> set (2nd least significant bit of the first byte of the MAC). It
>>>>> restricts this to host addresses (least significant bit is set to 0).
>>>>
>>>> Speaks about two bits
>>>>
>>>>
>>>>> This patch detects MAC addresses with this bit set and tags the
>>>>> request with the tag "laa-address". This would allow other rules
>>>>> to decide what to do with these requests (such as ignoring them).
>>>>
>>>> Speaks about one bit
>>>>
>>>>
>>>>
>>>> Speaking about bits, see
>>> https://en.wikipedia.org/wiki/MAC_address#/media/File:MAC-48_Address
>>> .svg
>>>> for the "exploded view"
>>>>
>>>
>>> https://en.wikipedia.org/wiki/MAC_address#Unicast_vs._multicast
>>>
>>> The reason two bits are tested is because:
>>> - one bit is the UAA / LAA bit
>>> - one bit is the unicast / multicast bit
>>>
>>> so this patch wouldn't tag LAA multicast MAC addresses should those
>>> happen to be in use somewhere.
>>>
>>> So specifically a device with an LAA unicast MAC address would get a
>>> tag. This requires testing two bits.
>>>
>>
>> OK, thanks for elaborating
>
> I think that big misunderstanding comes from commit message which says that one bit (LAA) is tested, but in patch itself are tested two bits.
>
> I guess that fixing commit message to properly describe that testing both bits (and which) are needed should be enough.
>
> Anyway, I'm not sure if 'laa-address' is correct name if it is not set for every laa-address, but only for unicast laa-address.
>
> --
> Pali Rohár
> pali.rohar at gmail.com
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
More information about the Dnsmasq-discuss
mailing list