Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-07-22 Thread Josh Soref
Can you cheat and just set the lease expiration to be measured in seconds?

I suspect that you can have different lease times, so if you can
discriminate between first state and second state systems, you can provide
more reasonable lease durations once the systems are stage two...
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-06 Thread Oliver Freyermuth
Am 06.06.2018 um 10:36 schrieb Roy Marples:
> On 06/06/2018 09:14, Oliver Freyermuth wrote:
>> I finally managed to test this in my testing setup - it works perfectly fine!
> 
> Awesome :D
> 
>> Could you let me know once it's integrated upstream?
> 
> I *am* the upstream for dhcpcd :)
> It will be in the next dhcpcd release for sure.

Oh! I noted the manpages were authored by you, but I did not investigate you're 
much more than the manpage author - nice. 
Then, even more thanks for noticing my issue on the dnsmasq-discuss list here 
and taking care of it at the more correct place :-). 

> 
>> I plan to open issues for dhclient, systemd-networkd etc. then and could 
>> reference that RFC6355 is already handled fine
>> in a very portable way on a wide range of OS by dhcpcd.
>>
>> In a later step, I'll then ping the debian-installer and kickstart 
>> developers, since they should also adopt this (I think they use dhclient, 
>> but I may be wrong).
>>
>> It's nice to see that dhcpcd is first on this :-).
> 
> Generally, dhcpcd is the first to support new stuff.

I know. Sadly, the most widespread distros (Debian, Ubuntu, RHEL, CentOS) have 
adoped dhclient (via NetworkManager) or systemd-networkd by default,
even though I'm not convinced this is a good move, but I won't enter 
philosophical discussions with them (with Gentoo, I can easily choose myself 
;-) ). 

> Thanks for testing and taking it to other upstreams.

Thanks to you for being really quick in adding well-tested portable support for 
this! 

Cheers,
Oliver



> 
> Roy


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-06 Thread Roy Marples

On 06/06/2018 09:14, Oliver Freyermuth wrote:

I finally managed to test this in my testing setup - it works perfectly fine!


Awesome :D


Could you let me know once it's integrated upstream?


I *am* the upstream for dhcpcd :)
It will be in the next dhcpcd release for sure.


I plan to open issues for dhclient, systemd-networkd etc. then and could 
reference that RFC6355 is already handled fine
in a very portable way on a wide range of OS by dhcpcd.

In a later step, I'll then ping the debian-installer and kickstart developers, 
since they should also adopt this (I think they use dhclient, but I may be 
wrong).

It's nice to see that dhcpcd is first on this :-).


Generally, dhcpcd is the first to support new stuff.
Thanks for testing and taking it to other upstreams.

Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-06 Thread Oliver Freyermuth
Dear Roy,

Am 05.06.2018 um 13:34 schrieb Roy Marples:
> On 04/06/2018 11:49, Roy Marples wrote:
>> These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
>> where UUID is taken from the hosts firmware. The UUID can then be displayed 
>> on the node alongside the MAC address for provisioning.
>> https://tools.ietf.org/html/rfc6355
>>
>> The downside is that no client I know of supports this and I keep meaning to 
>> add support to dhcpcd for it.
>> The other downside is that not all hosts have a retrievable UUID as it 
>> depends on both the OS and host itself - for example some OS's present a 
>> UUID based on the CPUID. Of course this only works if all OS's generate the 
>> same UUID from the base data.
> 
> I've just implemented DUID-UUID for dhcpcd.
> Patch here:
> https://roy.marples.name/git/dhcpcd.git/commit/?id=71981cab0e41ea2833489bc51307611727276aff
> 
> Tested on NetBSD, OpenBSD, FreeBSD and Linux.
> Unsure how to get system-uuid for Solaris or QNX at this time, which are the 
> only other platforms dhcpcd works on (but isn't as well supported).

I finally managed to test this in my testing setup - it works perfectly fine! 
Could you let me know once it's integrated upstream? I plan to open issues for 
dhclient, systemd-networkd etc. then and could reference that RFC6355 is 
already handled fine
in a very portable way on a wide range of OS by dhcpcd. 

In a later step, I'll then ping the debian-installer and kickstart developers, 
since they should also adopt this (I think they use dhclient, but I may be 
wrong). 

It's nice to see that dhcpcd is first on this :-). 

All the best and many thanks,
Oliver

> 
> Roy
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-05 Thread Simon Kelley



> 
> Alternatively: 
> Does somebody know of a clean way to administratively expire a lease handed 
> out by dnsmasq? 
> Then deployment tooling could forcefully expire an old lease when 
> reinstalling a node, and after the final reboot in the installed OS. 
> 
> Right now, I only know one could:
> - Stop dnsmasq.
> - Purge the lease from the leases-file. 
> - Restart dnsmasq. 
> 
> Is there a more convenient way? 
> 


There's a method in the DBus API to delete a DHCP lease. See
dbus/DBus-interface for details.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-05 Thread Roy Marples

On 04/06/2018 11:49, Roy Marples wrote:
These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
where UUID is taken from the hosts firmware. The UUID can then be 
displayed on the node alongside the MAC address for provisioning.

https://tools.ietf.org/html/rfc6355

The downside is that no client I know of supports this and I keep 
meaning to add support to dhcpcd for it.
The other downside is that not all hosts have a retrievable UUID as it 
depends on both the OS and host itself - for example some OS's present a 
UUID based on the CPUID. Of course this only works if all OS's generate 
the same UUID from the base data.


I've just implemented DUID-UUID for dhcpcd.
Patch here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=71981cab0e41ea2833489bc51307611727276aff

Tested on NetBSD, OpenBSD, FreeBSD and Linux.
Unsure how to get system-uuid for Solaris or QNX at this time, which are 
the only other platforms dhcpcd works on (but isn't as well supported).


Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 23:27 schrieb Roy Marples:
> On 25/05/2018 13:07, Oliver Freyermuth wrote:
>> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
>> way to overcome it with dnsmasq...
>>
>> When automatically deploying machines via PXE / network installer, there's 
>> usually first a DHCPv6 client running in the installer,
>> and afterwards (when the machine is installed) the "real" DHCPv6 client 
>> running on the machine.
>> Naturally, both will usually have different client DUIDs...
> 
> The partial solution to this, without any dnsmasq hackery OR DHCPv6 client 
> fixes, would be to seed the installed image with the duid from the installer.
> The only issue is if you re-run the installer it will create a new duid - 
> unless it performs a disk scan, finds the installation and then uses it. This 
> is an issue because there could be more than one installed target found, and 
> which to use?
> 
> NetBSD installer has been doing this with great success for some time now, no 
> reason why others cannot.

That's indeed a good point. It seems at least the Debian Installer is not doing 
that, I'm not 100% sure about RedHats kickstart, since I never had it in my 
test setup. 
But I know that some Linux installers, e.g. autoyast (openSUSE) also scrape 
existing installations for SSH host keys, to deploy them to the new 
installation. 
So the concept is certainly not new also for Linux, but apparently it has not 
made its way to the end just yet. 
I should probably go ahead at some point and open a bug report against 
Debian-Installer, and check out how Kickstart behaves. 

Of course, something which would fail in any case would be the approach to boot 
e.g. a temporary "bare-metal discovery" image to detect hardware, then the 
installer, and only then provision the machine. 
That's commonly done (see e.g. Foreman's discovery image). We're not doing that 
yet, but are planning to. 
The only solution for that would be RFC 6355, or using a type-3 DUID in the 
discovery image, since that's really volatile by design. 
Once we start to use the Foreman discovery image, I'll have a look what it 
does. 

Cheers,
Oliver

> 
> Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Roy Marples

On 25/05/2018 13:07, Oliver Freyermuth wrote:

I fear the following is a design issue of DHCPv6, but I wonder if there's a way 
to overcome it with dnsmasq...

When automatically deploying machines via PXE / network installer, there's 
usually first a DHCPv6 client running in the installer,
and afterwards (when the machine is installed) the "real" DHCPv6 client running 
on the machine.
Naturally, both will usually have different client DUIDs...


The partial solution to this, without any dnsmasq hackery OR DHCPv6 
client fixes, would be to seed the installed image with the duid from 
the installer.
The only issue is if you re-run the installer it will create a new duid 
- unless it performs a disk scan, finds the installation and then uses 
it. This is an issue because there could be more than one installed 
target found, and which to use?


NetBSD installer has been doing this with great success for some time 
now, no reason why others cannot.


Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 18:46 schrieb wkitt...@gmail.com:
> On 06/04/2018 07:36 AM, Oliver Freyermuth wrote:
>> Right now, I only know one could:
>> - Stop dnsmasq.
>> - Purge the lease from the leases-file.
>> - Restart dnsmasq.
> 
> 
> i think the process is:
> 
>   rewrite the leases file as needed
>   HUP dnsmasq
> 
> but i'm not positive... if not HUB, maybe one of the other signals... if none 
> of them, then something with DBUS...

I think this works for some separate files specified explicitly, e.g. 
dhcp-hostsfile, 
but the lease file is not reloaded on SIGHUP, but kept in memory and flushed 
from time to time... 
That's also what the manpage suggests in the "NOTES" section. 

I'm not sure if leases are destroyed when the corresponding entry in 
dhcp-hostsfile is removed and SIGHUP is sent. This might be a possibility,
but I would not expect that this destroys a still-valid lease. 

But indeed I find "RemoveDhcpLease" in:
https://github.com/imp/dnsmasq/blob/master/dbus/DBus-interface

This would certainly be a possibility :-). 

Cheers,
Oliver

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread wkitty42

On 06/04/2018 07:36 AM, Oliver Freyermuth wrote:

Right now, I only know one could:
- Stop dnsmasq.
- Purge the lease from the leases-file.
- Restart dnsmasq.



i think the process is:

  rewrite the leases file as needed
  HUP dnsmasq

but i'm not positive... if not HUB, maybe one of the other signals... if none of 
them, then something with DBUS...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Oliver Freyermuth
Am 04.06.2018 um 12:49 schrieb Roy Marples:
> On 03/06/2018 22:20, Simon Kelley wrote:
>> I agree that this is an annoying problem. In DHCPv6 even determining the
>> MAC address of a client is a slightly dodgy operation - there are
>> circumstances where it's not possible. That notwithstanding, dnsmasq
>> does it's best, and allows you to configure an address to allocated by
>> MAC address.
>>
>> The problem here is that the client changes DUID - the desired address
>> gets allocated by MAC address once, but when the DUID changes, the
>> address is already in use by a first DUID/IAID combination, so it can't
>> be allocated, even if the MAC address is the same.
> 
> The problem is how the DUID is generated, not the DUID itself.
> DUID-LL is not the default (and shouldn't be either).
> DUID-LLT is a good default, but comes with the aforementioned problems.
> 
> These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
> where UUID is taken from the hosts firmware. The UUID can then be displayed 
> on the node alongside the MAC address for provisioning.
> https://tools.ietf.org/html/rfc6355
> 
> The downside is that no client I know of supports this and I keep meaning to 
> add support to dhcpcd for it.

This sounds like a really nice solution - it would be cool if this was added to 
dhclient and dhcpcd and systemd-networkd, and would be the default. 
This should then also fix the problem with automated deployments. 

Still, even if support for that is added, it will likely take some years until 
all components are fixed... 

> The other downside is that not all hosts have a retrievable UUID as it 
> depends on both the OS and host itself - for example some OS's present a UUID 
> based on the CPUID. Of course this only works if all OS's generate the same 
> UUID from the base data.
> 
> TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should not 
> allow nor encourage RFC violations.

I fully agree it's not a dnsmasq issue (I already mentioned that in my first 
mail). I was mainly unaware of RFC6355 (which should indeed be *the* solution), 
and am convinced that a workaround on the DHCP server end is significantly 
easier to deploy for a full network than to get rid of all clients not yet 
using RFC6355, 
so I keep wondering whether an optional feature to violate the "old" RFCs would 
be feasible until all clients are fixed, which will surely take half a century 
or longer. 

Alternatively: 
Does somebody know of a clean way to administratively expire a lease handed out 
by dnsmasq? 
Then deployment tooling could forcefully expire an old lease when reinstalling 
a node, and after the final reboot in the installed OS. 

Right now, I only know one could:
- Stop dnsmasq.
- Purge the lease from the leases-file. 
- Restart dnsmasq. 

Is there a more convenient way? 

Cheers,
Oliver

> 
> Roy
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-04 Thread Roy Marples

On 03/06/2018 22:20, Simon Kelley wrote:

I agree that this is an annoying problem. In DHCPv6 even determining the
MAC address of a client is a slightly dodgy operation - there are
circumstances where it's not possible. That notwithstanding, dnsmasq
does it's best, and allows you to configure an address to allocated by
MAC address.

The problem here is that the client changes DUID - the desired address
gets allocated by MAC address once, but when the DUID changes, the
address is already in use by a first DUID/IAID combination, so it can't
be allocated, even if the MAC address is the same.


The problem is how the DUID is generated, not the DUID itself.
DUID-LL is not the default (and shouldn't be either).
DUID-LLT is a good default, but comes with the aforementioned problems.

These problems are very nicely solved with RFC 6355 which adds DUID-UUID 
where UUID is taken from the hosts firmware. The UUID can then be 
displayed on the node alongside the MAC address for provisioning.

https://tools.ietf.org/html/rfc6355

The downside is that no client I know of supports this and I keep 
meaning to add support to dhcpcd for it.
The other downside is that not all hosts have a retrievable UUID as it 
depends on both the OS and host itself - for example some OS's present a 
UUID based on the CPUID. Of course this only works if all OS's generate 
the same UUID from the base data.


TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should 
not allow nor encourage RFC violations.


Roy

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-03 Thread Oliver Freyermuth
Am 03.06.2018 um 23:20 schrieb Simon Kelley:
> I agree that this is an annoying problem. In DHCPv6 even determining the
> MAC address of a client is a slightly dodgy operation - there are
> circumstances where it's not possible. That notwithstanding, dnsmasq
> does it's best, and allows you to configure an address to allocated by
> MAC address.
> 
> The problem here is that the client changes DUID - the desired address
> gets allocated by MAC address once, but when the DUID changes, the
> address is already in use by a first DUID/IAID combination, so it can't
> be allocated, even if the MAC address is the same.
> 
> The obvious solution is to prioritise MAC address over DUID/IAID and
> allocate anyway, but there are at least two reasons why I'm not happy
> with that.
> 
> First, as I mentioned above getting the MAC address is not always
> possible/reliable.
> 
> Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on
> clients being identified by DUID/IAID. Allocating the same address to
> two different DUID/IAIDs, because of hints from an (unreliable) MAC
> address violates the DHCP prime directive: thou shall not give the same
> address to two different machines.

I fully agree. The problem is that for my case, the RFCs do not offer any 
solution. 
My case is: A machine boots via PXE, fetches an address in the installer 
environment,
deploys the operating system, reboots - and gets no address anymore, since the 
DUID/IAID
will necessarily be different between the temporary installer environment and 
the final runtime environment. 

In short, DHCPv6 is impossible to use (in accordance with thr RFCs) for any 
automated deployment via PXE. 
The only way is to use IPv4 in addition, and trust in the fallbacks, and wait 
for leases to time out. 

So the RFCs are broken for this very common usecase - that's why my statement 
was if dnsmasq is willing to offer a workaround
for the RFCs, which don't cover one of the most common usecases, unless I'm 
missing something. 

> 
> Looking at Kevin's logs, the client is flat out buggy. It's using a
> type-1 DUID which consists of a time and a MAC address. The reason for
> the time is to ensure uniqueness when the DUID is created, but the NAS
> seems to be updating it on every reboot. That's just plain wrong. type-1
> DUID are meant for devices which have non volatile storage: they
> generate the DUID once and store it. If they can't store it (which seems
> unlikely for a NAS, but let's give it the benefit of the doubt), they
> should use type-3 DUIDs, without the time field. It's all very clear in
> RFC 3315, section 9.

The other option would be to modify all automated Linux installers (Kickstart / 
Anaconda,
Preseed / Debian Installer) to use type-3 DUIDs. Since right now they appear to 
use dhclient / dhcpce
without any special configuration, that's not the case... 

That would be a way out in accordance with the RFCs, but things would still 
fail if a machine is reinstalled - 
it can't fetch an address when rebooting via PXE, until the old DUID/IAID lease 
from the past life is expired,
which may take days. 

TL;DR: The RFCs did not think about automated machine deployment :-(. 
One needs to violate the RFCs to allow for that in a DHCPv6 environment. 

Cheers,
Oliver

> 
> TLDR; these clients are violating the RFCs. The only feasible way to
> make them behave is for dnsmasq to violate the RFC too, in a way which
> may well break stuff badly. I'm not prepared to implement that in dnsmasq.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 27/05/18 18:36, Oliver Freyermuth wrote:
>> Am 25.05.2018 um 17:23 schrieb P W:
>>> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
 Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
>> On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
>>
>> Dear dnsmasqers,
>>
>> I fear the following is a design issue of DHCPv6, but I wonder if 
>> there's a way to overcome it with dnsmasq...
> 
>
> Hi Oliver,
>
> I???ve a similar/same problem when rebooting some QNAP NAS boxen,
> first boot/introduction to dnsmasq and they get both IPv4 & v6
> addresses set to fixed values based on MAC address.  On reboot whilst
> IPv4 is fine, IPv6 is not reallocated to the original address but
> rather a new one.  By curious co-incidence I just started looking
> into this problem today though it has been bugging me for months :-)
> Have tried various combinations of MAC address & DUID.
>

 Dear Kevin, 

 I think it's exactly the same issue. 
 Comparing:
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
> DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
 with
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
 it seems the QNAP NAS box is using a fresh client DUID each reboot... 
>>>
>>>
>>> 

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-03 Thread Pali Rohár
There is an extension for DHCPv6 to send client's MAC address as DHCP
option 79. And in case there is no DHCPv6 relay and packets comes from
ethernet, you can read MAC address directly from ethernet frame which
contains that UDP (DHCPv6) packet. In other cases MAC address is really
not available, but then it would not work. But I guess that in most
cases is dnsmasq on same segment as hosts and ethernet is used for UDP
packets. In all other cases DHCPv6 relay can be configured to fill
option 79 (RFC 6939).

I agree that clients which generates after every boot new DUID are
buggy, but this is reality. DHCPv6 was designed in this way and for
implementing DHCPv6 clients it was easier to introduce these bugs as
doing it properly (via permanent storage for DUID).

And I doubt that in future it would be better...

There still would be a problem with dual-booting. Linux and Windows
DHCPv6 clients would *never* use one common permanent storage for DUID.

So I would really propose to thing about it and trying to find a way how
to make dnsmasq better on network with these devices.

On Sunday 03 June 2018 22:20:17 Simon Kelley wrote:
> I agree that this is an annoying problem. In DHCPv6 even determining the
> MAC address of a client is a slightly dodgy operation - there are
> circumstances where it's not possible. That notwithstanding, dnsmasq
> does it's best, and allows you to configure an address to allocated by
> MAC address.
> 
> The problem here is that the client changes DUID - the desired address
> gets allocated by MAC address once, but when the DUID changes, the
> address is already in use by a first DUID/IAID combination, so it can't
> be allocated, even if the MAC address is the same.
> 
> The obvious solution is to prioritise MAC address over DUID/IAID and
> allocate anyway, but there are at least two reasons why I'm not happy
> with that.
> 
> First, as I mentioned above getting the MAC address is not always
> possible/reliable.
> 
> Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on
> clients being identified by DUID/IAID. Allocating the same address to
> two different DUID/IAIDs, because of hints from an (unreliable) MAC
> address violates the DHCP prime directive: thou shall not give the same
> address to two different machines.
> 
> Looking at Kevin's logs, the client is flat out buggy. It's using a
> type-1 DUID which consists of a time and a MAC address. The reason for
> the time is to ensure uniqueness when the DUID is created, but the NAS
> seems to be updating it on every reboot. That's just plain wrong. type-1
> DUID are meant for devices which have non volatile storage: they
> generate the DUID once and store it. If they can't store it (which seems
> unlikely for a NAS, but let's give it the benefit of the doubt), they
> should use type-3 DUIDs, without the time field. It's all very clear in
> RFC 3315, section 9.
> 
> 
> TLDR; these clients are violating the RFCs. The only feasible way to
> make them behave is for dnsmasq to violate the RFC too, in a way which
> may well break stuff badly. I'm not prepared to implement that in dnsmasq.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 27/05/18 18:36, Oliver Freyermuth wrote:
> > Am 25.05.2018 um 17:23 schrieb P W:
> >> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
> >>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
> > On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
> >
> > Dear dnsmasqers,
> >
> > I fear the following is a design issue of DHCPv6, but I wonder if 
> > there's a way to overcome it with dnsmasq...
>  
> 
>  Hi Oliver,
> 
>  I???ve a similar/same problem when rebooting some QNAP NAS boxen,
>  first boot/introduction to dnsmasq and they get both IPv4 & v6
>  addresses set to fixed values based on MAC address.  On reboot whilst
>  IPv4 is fine, IPv6 is not reallocated to the original address but
>  rather a new one.  By curious co-incidence I just started looking
>  into this problem today though it has been bugging me for months :-)
>  Have tried various combinations of MAC address & DUID.
> 
> >>>
> >>> Dear Kevin, 
> >>>
> >>> I think it's exactly the same issue. 
> >>> Comparing:
>  Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
>  DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
> >>> with
>  Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
>  DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
> >>> it seems the QNAP NAS box is using a fresh client DUID each reboot... 
> >>
> >>
> >> Patches Welcome
> > 
> > At the moment, there's sadly too much in my queue to start on another 
> > OpenSource project - but I'll look into it once this changes,
> > which sadly won't be in the very near future. 
> > If anybody else has time at hand, of course I can offer to test a patch 
> > (the setup is here). 
> > 
> > Cheers,
> > Oliver
> > 

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-06-03 Thread Simon Kelley
I agree that this is an annoying problem. In DHCPv6 even determining the
MAC address of a client is a slightly dodgy operation - there are
circumstances where it's not possible. That notwithstanding, dnsmasq
does it's best, and allows you to configure an address to allocated by
MAC address.

The problem here is that the client changes DUID - the desired address
gets allocated by MAC address once, but when the DUID changes, the
address is already in use by a first DUID/IAID combination, so it can't
be allocated, even if the MAC address is the same.

The obvious solution is to prioritise MAC address over DUID/IAID and
allocate anyway, but there are at least two reasons why I'm not happy
with that.

First, as I mentioned above getting the MAC address is not always
possible/reliable.

Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on
clients being identified by DUID/IAID. Allocating the same address to
two different DUID/IAIDs, because of hints from an (unreliable) MAC
address violates the DHCP prime directive: thou shall not give the same
address to two different machines.

Looking at Kevin's logs, the client is flat out buggy. It's using a
type-1 DUID which consists of a time and a MAC address. The reason for
the time is to ensure uniqueness when the DUID is created, but the NAS
seems to be updating it on every reboot. That's just plain wrong. type-1
DUID are meant for devices which have non volatile storage: they
generate the DUID once and store it. If they can't store it (which seems
unlikely for a NAS, but let's give it the benefit of the doubt), they
should use type-3 DUIDs, without the time field. It's all very clear in
RFC 3315, section 9.


TLDR; these clients are violating the RFCs. The only feasible way to
make them behave is for dnsmasq to violate the RFC too, in a way which
may well break stuff badly. I'm not prepared to implement that in dnsmasq.


Cheers,

Simon.



On 27/05/18 18:36, Oliver Freyermuth wrote:
> Am 25.05.2018 um 17:23 schrieb P W:
>> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
>>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
> On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
>
> Dear dnsmasqers,
>
> I fear the following is a design issue of DHCPv6, but I wonder if there's 
> a way to overcome it with dnsmasq...
 

 Hi Oliver,

 I???ve a similar/same problem when rebooting some QNAP NAS boxen,
 first boot/introduction to dnsmasq and they get both IPv4 & v6
 addresses set to fixed values based on MAC address.  On reboot whilst
 IPv4 is fine, IPv6 is not reallocated to the original address but
 rather a new one.  By curious co-incidence I just started looking
 into this problem today though it has been bugging me for months :-)
 Have tried various combinations of MAC address & DUID.

>>>
>>> Dear Kevin, 
>>>
>>> I think it's exactly the same issue. 
>>> Comparing:
 Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
 DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
>>> with
 Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
 DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
>>> it seems the QNAP NAS box is using a fresh client DUID each reboot... 
>>
>>
>> Patches Welcome
> 
> At the moment, there's sadly too much in my queue to start on another 
> OpenSource project - but I'll look into it once this changes,
> which sadly won't be in the very near future. 
> If anybody else has time at hand, of course I can offer to test a patch (the 
> setup is here). 
> 
> Cheers,
>   Oliver
> 
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-27 Thread Oliver Freyermuth
Am 25.05.2018 um 17:23 schrieb P W:
> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
 On 25 May 2018, at 13:07, Oliver Freyermuth wrote:

 Dear dnsmasqers,

 I fear the following is a design issue of DHCPv6, but I wonder if there's 
 a way to overcome it with dnsmasq...
>>> 
>>>
>>> Hi Oliver,
>>>
>>> I???ve a similar/same problem when rebooting some QNAP NAS boxen,
>>> first boot/introduction to dnsmasq and they get both IPv4 & v6
>>> addresses set to fixed values based on MAC address.  On reboot whilst
>>> IPv4 is fine, IPv6 is not reallocated to the original address but
>>> rather a new one.  By curious co-incidence I just started looking
>>> into this problem today though it has been bugging me for months :-)
>>> Have tried various combinations of MAC address & DUID.
>>>
>>
>> Dear Kevin, 
>>
>> I think it's exactly the same issue. 
>> Comparing:
>>> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
>>> DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
>> with
>>> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
>>> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
>> it seems the QNAP NAS box is using a fresh client DUID each reboot... 
> 
> 
> Patches Welcome

At the moment, there's sadly too much in my queue to start on another 
OpenSource project - but I'll look into it once this changes,
which sadly won't be in the very near future. 
If anybody else has time at hand, of course I can offer to test a patch (the 
setup is here). 

Cheers,
Oliver

> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-25 Thread P W
On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote:
> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
> >> On 25 May 2018, at 13:07, Oliver Freyermuth wrote:
> >>
> >> Dear dnsmasqers,
> >>
> >> I fear the following is a design issue of DHCPv6, but I wonder if there's 
> >> a way to overcome it with dnsmasq...
> > 
> > 
> > Hi Oliver,
> > 
> > I???ve a similar/same problem when rebooting some QNAP NAS boxen,
> > first boot/introduction to dnsmasq and they get both IPv4 & v6
> > addresses set to fixed values based on MAC address.  On reboot whilst
> > IPv4 is fine, IPv6 is not reallocated to the original address but
> > rather a new one.  By curious co-incidence I just started looking
> > into this problem today though it has been bugging me for months :-)
> > Have tried various combinations of MAC address & DUID.
> > 
> 
> Dear Kevin, 
> 
> I think it's exactly the same issue. 
> Comparing:
> > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
> > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
> with
> > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
> > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
> it seems the QNAP NAS box is using a fresh client DUID each reboot... 


Patches Welcome

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-25 Thread Oliver Freyermuth
Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant:
> 
> 
>> On 25 May 2018, at 13:07, Oliver Freyermuth  
>> wrote:
>>
>> Dear dnsmasqers,
>>
>> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
>> way to overcome it with dnsmasq...
> 
> 
> Hi Oliver,
> 
> I’ve a similar/same problem when rebooting some QNAP NAS boxen, first 
> boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to 
> fixed values based on MAC address.  On reboot whilst IPv4 is fine, IPv6 is 
> not reallocated to the original address but rather a new one.  By curious 
> co-incidence I just started looking into this problem today though it has 
> been bugging me for months :-)  Have tried various combinations of MAC 
> address & DUID.
> 
> Without meaning to thread hijack!  If it’s not effectively the same issue 
> will gladly start a new thread.

Dear Kevin, 

I think it's exactly the same issue. 
Comparing:
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
> DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
with
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
it seems the QNAP NAS box is using a fresh client DUID each reboot... 

Cheers,
Oliver

> 
> 
> First boot with fresh dnsmasq
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 client MAC 
> address: 24:5e:be:0c:bc:ba
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
> DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
> DHCPREPLY(br-lan) 2a02:c7f:beef:2000::e 
> 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Statler
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 tags: lan, 
> known, dhcpv6, br-lan
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 
> 14 option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 
> 40 option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 nest size: 
> 24 option:  5 iaaddr  2a02:c7f:beef:2000::e PL=43200 VL=43200
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  
> 9 option: 13 status  0 success
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  
> 1 option:  7 preference  255
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 
> 29 option: 24 domain-search  lan.darbyshire-bryant.me.uk
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 
> 16 option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 
> 38 option: 39 FQDN  Statler.lan.darbyshire-bryant.me.uk
> 
> 
> And now a reboot of the client:
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 available 
> DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000::
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 client MAC 
> address: 24:5e:be:0c:bc:ba
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
> DHCPADVERTISE(br-lan) 2a02:c7f:beef:2000::9c72 
> 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 tags: lan, 
> known, dhcpv6, br-lan
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
> 14 option:  1 client-id  00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
> 14 option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
> 40 option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 nest size: 
> 24 option:  5 iaaddr  2a02:c7f:beef:2000::9c72 PL=43200 VL=43200
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
>  9 option: 13 status  0 success
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
>  1 option:  7 preference  255
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
> 29 option: 24 domain-search  lan.darbyshire-bryant.me.uk
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
> 16 option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
>  9 option: 39 FQDN  Statler
> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 available 
> DHCP range: 2a02:c7f:beef:2000::1000 -- 

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-25 Thread Kevin Darbyshire-Bryant


> On 25 May 2018, at 13:07, Oliver Freyermuth  
> wrote:
> 
> Dear dnsmasqers,
> 
> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
> way to overcome it with dnsmasq...


Hi Oliver,

I’ve a similar/same problem when rebooting some QNAP NAS boxen, first 
boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to fixed 
values based on MAC address.  On reboot whilst IPv4 is fine, IPv6 is not 
reallocated to the original address but rather a new one.  By curious 
co-incidence I just started looking into this problem today though it has been 
bugging me for months :-)  Have tried various combinations of MAC address & 
DUID.

Without meaning to thread hijack!  If it’s not effectively the same issue will 
gladly start a new thread.


First boot with fresh dnsmasq
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 
DHCPREPLY(br-lan) 2a02:c7f:beef:2000::e 
00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Statler
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 14 
option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 40 
option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 nest size: 24 
option:  5 iaaddr  2a02:c7f:beef:2000::e PL=43200 VL=43200
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  9 
option: 13 status  0 success
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size:  1 
option:  7 preference  255
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 29 
option: 24 domain-search  lan.darbyshire-bryant.me.uk
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 16 
option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 38 
option: 39 FQDN  Statler.lan.darbyshire-bryant.me.uk


And now a reboot of the client:
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 available 
DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000::
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 
DHCPADVERTISE(br-lan) 2a02:c7f:beef:2000::9c72 
00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
14 option:  1 client-id  00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
14 option:  2 server-id  00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
40 option:  3 ia-na  IAID=3132886206 T1=21600 T2=37800
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 nest size: 
24 option:  5 iaaddr  2a02:c7f:beef:2000::9c72 PL=43200 VL=43200
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
9 option: 13 status  0 success
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
1 option:  7 preference  255
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
29 option: 24 domain-search  lan.darbyshire-bryant.me.uk
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 
16 option: 23 dns-server  2a02:c7f:beef:2000::da2b:da2b
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size:  
9 option: 39 FQDN  Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 available 
DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000::
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 client MAC 
address: 24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 
DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 
DHCPREPLY(br-lan) 2a02:c7f:beef:2000::9c72 
00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 tags: lan, 
known, dhcpv6, br-lan
Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 sent size: 
14 option:  1 client-id  

Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-25 Thread Pali Rohár
On Friday 25 May 2018 14:07:34 Oliver Freyermuth wrote:
> Dear dnsmasqers,
> 
> I fear the following is a design issue of DHCPv6, but I wonder if there's a 
> way to overcome it with dnsmasq... 
> 
> When automatically deploying machines via PXE / network installer, there's 
> usually first a DHCPv6 client running in the installer,
> and afterwards (when the machine is installed) the "real" DHCPv6 client 
> running on the machine. 
> Naturally, both will usually have different client DUIDs... 
> 
> Using dnsmasq's functionality to perform DHCPv6 address assignment based on 
> MAC address,
> this works fine for the first client, but the second DHCPv6 client will not 
> get an address until the old lease is expired. 
> 
> In general, I feel this is the correct behaviour, but it's of course rather 
> inconvenient when deploying machines automatically - 
> they will retrieve an IPv6 address with the network installer, and then not 
> get one after the first reboot. 
> Also, when reinstalling them, they will not get an address in the installer 
> if the lease from their "old life" is still valid. 
> 
> Does somebody have a good solution for this? 
> Is there something like "id:*" for IPv4 implemented for the IPv6 world (i.e. 
> something like "duid:*")? 
> 
> Cheers and all the best,
>   Oliver

Hi Oliver!

dnsmasq for DHCPv6 stores in lease file IAID, not DUID. But assignment
of address is done either by DUID or MAC address.

I think you hit some problem affected by the way how is IPv6 address
assigned according to DUID, IAID, MAC address and status of lease file.

2 years ago I tried to discuss with Simon about possibility to assign
one address to more DHCP requests identified by MAC address and one of
needed thing was probably extension of lease file (to include also MAC
address and DUID) and handling of requests which already have address
assigned in lease file. Apparently until now Simon has not response
about it and I gave up trying to ping him again...

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010404.html

-- 
Pali Rohár
pali.ro...@gmail.com

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments

2018-05-25 Thread Oliver Freyermuth
Dear dnsmasqers,

I fear the following is a design issue of DHCPv6, but I wonder if there's a way 
to overcome it with dnsmasq... 

When automatically deploying machines via PXE / network installer, there's 
usually first a DHCPv6 client running in the installer,
and afterwards (when the machine is installed) the "real" DHCPv6 client running 
on the machine. 
Naturally, both will usually have different client DUIDs... 

Using dnsmasq's functionality to perform DHCPv6 address assignment based on MAC 
address,
this works fine for the first client, but the second DHCPv6 client will not get 
an address until the old lease is expired. 

In general, I feel this is the correct behaviour, but it's of course rather 
inconvenient when deploying machines automatically - 
they will retrieve an IPv6 address with the network installer, and then not get 
one after the first reboot. 
Also, when reinstalling them, they will not get an address in the installer if 
the lease from their "old life" is still valid. 

Does somebody have a good solution for this? 
Is there something like "id:*" for IPv4 implemented for the IPv6 world (i.e. 
something like "duid:*")? 

Cheers and all the best,
Oliver

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss