Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: MAC randomisation and DHCP pools (Michael De Roover)
2. Re: MAC randomisation and DHCP pools (Joshua Stark)
3. division of responsibility client/dhcp/bind (Boylan, Ross)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Jul 2020 19:28:49 +0200
From: Michael De Roover <i...@nixmagic.com>
To: dhcp-users@lists.isc.org
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <f53993b2-9bf6-0afa-43d4-2d7e4ee7b...@ghnou.su>
Content-Type: text/plain; charset=utf-8; format=flowed
On 7/24/20 11:48 AM, glenn.satch...@uniq.com.au wrote:
> This is not something new, it has been around since IOS 8 in 2014. I
> think this page summarises how it works and has links to Apple's site
> with more details.
>
> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>
>
>
> It appears that it randomises the MAC address when the device is
> passively scanning for networks and other particular settings are
> enabled or disabled, so systems can't use the MAC address to
> persistently track wherever you go. However, it seems that any
> associations/joining of networks is based on the actual MAC address.
On Android this has also been implemented since either 9 or 10 I think..
not 100% sure. In it the option to use the real device MAC can be chosen
on a per-network basis though. By default both the discovery and the
eventual connection have the MAC randomized. So for my DHCP server which
gives static leases based on the MAC address, making it use the real MAC
ended up being imperative. I really hope that this option will not be
removed. Development on ISC dhcp seems to have pretty much ended since
about half a year ago, so if it does get removed client-side I'd
probably have to rethink the server side.
--
Met vriendelijke groet / Best regards,
Michael De Roover
------------------------------
Message: 2
Date: Sat, 25 Jul 2020 11:46:39 +1000
From: Joshua Stark <star...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <060f1dcf-0374-3612-fafc-76b735f06...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
The user can decide to turn the feature off on the Apple device per WiFi
network:
Rarely, a network might allow you to join with a private address, but
won't allow Internet access. If that happens,?you can choose to stop
using private addresses
<https://support.apple.com/en-us/HT211227#onoff>?with that network
(https://support.apple.com/en-us/HT211227)
I agree, this will make things different, harder initially. One example
that comes to mind is white/black lists on WiFi networks, that will go
out the window.
And the other of being able to set a static IPv4 will be next to impossible.
But was that not the point of IPv6 - totally random
In my mind this means we need an evolution of how we do things, like how
AWS/GCP have taken the classic firewall of IP/Port to a Service Layer
Firewall.
There is going to need to be another way to identify a device to allow
automatic re-authentication, like public WiFi where you purchase access
for greater then 24hrs.
How we do that, I don't know, but it's time to start thinking about how
to implement the next evolution in technology!
Thanks
Josh
On 24/7/20 20:59, Mike Richardson wrote:
>> Hi Mike,
>>
>> This is not something new, it has been around since IOS 8 in 2014. I think
>> this page summarises how it works and has links to Apple's site with more
>> details.
>>
>> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>>
>> It appears that it randomises the MAC address when the device is passively
>> scanning for networks and other particular settings are enabled or disabled,
>> so systems can't use the MAC address to persistently track wherever you go.
>> However, it seems that any associations/joining of networks is based on the
>> actual MAC address.
>>
>> Or am I talking about something else entirely different?
> Something new I believe:
>
> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
> https://support.apple.com/en-us/HT211227
>
> Apple, in IOS14, are going to implement the changing of MACs every 24 hours
> as the default, and different ones for each SSID, I believe.
>
> I'm just trying to evaluate the impact on things like DHCP, but I'm not sure
> about exactly what happens when pools are, sort of, exhausted.
>
> Thanks,
>
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200725/10e18f09/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4044 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200725/10e18f09/attachment-0001.bin>
------------------------------
Message: 3
Date: Sat, 25 Jul 2020 07:15:35 +0000
From: "Boylan, Ross" <ross.boy...@ucsf.edu>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Cc: "rossboy...@stanfordalumni.org" <rossboy...@stanfordalumni.org>
Subject: division of responsibility client/dhcp/bind
Message-ID:
<byapr05mb573671717603f3bd859647b387...@byapr05mb5736.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
I have a small private network with machines that go on and off. Some of those
machines may come up with the same hardware/mac address, and yet be running
different OS's. The different OS's have different host names, and I would like
that reflected in DNS. An additional complication is that some of the system
netboot into an NFS root. I'm having trouble getting things to work, and think
I'm missing something basic about how this is all supposed to work together.
Using ISD dhcpd 4.1, bind 9.11.5 with Debian buster. Initial testing used an
NFS root client that PXE booted (using dhcpd's support for that).
I don't understand why the DDNS update responsibility is potentially split
between the server and the client. It seems the default is that the client
updates the A record while the dhcp server requests the update of the PTR
record for reverse DNS. This seems like a recipe for trouble. First, they
could get out of sync. Second, if a key is required for updates, as was true
in my initial configuration, the clients won't ordinarily have it, and so the
update will fail. Because of the second concern, I set dhcpd.conf to "ignore
client-updates;". But my reading of the manual is that this means the client's
notion of its hostname will be ignored, defeating the ultimate goal of allowing
different hostnames for same MAC.
Another problem was that because of the NFS boot the usual code to bring up the
interface was skipped. So the client system didn't run dhclient. As a
result, I got DDNS entries when the client started. But when the lease expired
without further expression of interest from the client, dhcpd (successfully)
requested deletion of the DNS records for the client.
Also, since dhcpd only handed out parameters during the PXE boot, many of the
parameters like the domain and search list, didn't make it to the main system
once it was booted.
I tried forcing the interface up on the client (specifying auto in
/etc/network/interfaces). This solved some problems while introducing others:
the NIC ended up with 2 IP addresses. Initially only the first was in DNS.
When its lease expired, there were no entries in DNS, but since dhclient was
running for the 2nd IP, its lease was renewed and entered into DNS at that
time. In principle it seemed the first IP address could be handed out to
another machine, and then 2 machines that would think they had the same IP. It
may be that the discovery process would suffice to prevent this, but at any
rate it didn't seem to be a good state of affairs that the client thought it
had an IP address that both DHCP and BIND thought was free. Finally, the
client was unable to shutdown without a manual power off because it was waiting
for a response on one of the IP's "after" it shutdown.
In all the above I was assigning the client IPs from a pool, although the
client had a host declaration (with the MAC but without an IP). Some
discussion on this list says host declarations should use fixed IPs outside of
the pool range. So I gave the host declaration in dhcpd.conf a fixed IP
outside the pool range, as well as a very long lease. I also changed to the
default "allow client-updates" while changing bind to accept update without a
key.
The client came up, but no dynamic DNS entries were requested or created as a
result. So does that only happen for IP's allocated out of the pool? And
lease time is irrelevant for an IP not in the pool?
For now, I manually entered the forward and reverse DNS entries into my local
zone in bind.
These last choices (dhcpd.conf gets host with fixed ip; bind gets corresponding
forward and reverse entries; client does not try to bring interface up after
nfs boot) mostly work. The fact that the entries exist even when the system is
down doesn't seem like much of a practical problem, but this obviously can not
satisfy my original desire to allow different hostnames/OS's for the same
machine and MAC.
Suggestions?
Thanks.
Ross Boylan
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 141, Issue 11
*******************************************
