[ipxe-devel] Need to release DHCPv6 address before booting image

[Harald Jensås]

On Fri, 2019-11-15 at 17:01 +0000, Michael Brown wrote:
> On 14/11/2019 10:45, Harald Jensås wrote:
> > The DHCP server (dnsmasq) is configured with static addressing
> > matching
> > on MAC address. I get to stage 3 because the OVMF UEFI firmware is
> > kind
> > enough to do a RELEASE before booting the Network Boot Program
> > (NBP);
> > iPXE in my case. Since the UEFI firmware released the address iPXE
> > successfully get IP and configuration so that it can download the
> > deploy kernel and ramdisk. When the deploy ramdisk boot's and
> > attempt
> > DHCPv6 the DHCP server respond with "no addresses available".
> > 
> > The DHCP server is correct, the address assigned to the client's
> > MAC is
> > already leased to the iPXE client.
> > 
> > As far as I can tell there is no way to tell iPXE to do something
> > like
> > this?
> > 
> > #!ipxe
> > 
> > imgfree
> > kernel --timeout 60000 http://[fd12:3456:789a:1::1]:8088/vmlinuz
> > BOOTIF=${mac} i initrd=initrd
> > initrd --timeout 60000 http://[fd12:3456:789a:1::1]/initrd
> > <%- Command to release DHCPv6 address -%>
> > boot
> 
> No, there is no way to instruct iPXE to release a DHCP lease.
> 

ack, this was my conclusion as well. I still think it would be good to
have the option to do so. Or at-least expose the necessary data so that
it can be passed to the chainloaded OS.

> Even if there were such a way, this would not provide a general
> solution 
> to the problem, since there are situations in which iPXE would have
> no 
> opportunity to release the DHCP lease before handing over control to
> the 
> loaded OS.  For example, when performing an iSCSI boot, there is no 
> point at which iPXE is able to determine that the INT 13 interface
> will 
> no longer be used.
> 

Indeed, I guess iSCSI systems would have to be able to renew their
addresses as well at some point? The changeing DUID/IAID problem would
still be a problem.

> The correct solution is a server-side fix: if the DHCPv6 server is 
> matching on MAC address and sees a new request from a MAC address,
> then 
> it should assume that the old lease is dead regardless of the IAID 
> value.  This solution is robust in all edge cases (e.g. when a VM 
> reboots unexpectedly without the OS releasing its address).
> 

Personally I don't dissagree. There is a patch[2] for dnsmasq that does
this, and it works well. I have lifted it on the dnsmasq list again.

The problem with this solution is that it goes outside the DHCPv6
RFC8415[1] section 12 which discuss Identity Association for both
clients/servers and address assignments. In other words, we may be able
to get one DHCP server implementation to side-track the RFC spec and
ignore changed DUID/IAID's of the client. Other DHCP servers are likely
to follow RFC.

An alternatives to doing a RELEASE in iPXE could be to pass the DHCP
client information in arguments. It is already possible to pass the ip
with ${net0.dhcpv6/ip6}. If it was also possible to also pass:
 ${net0.dhcpv6/client-id}
 ${net0.dhcpv6/server-id}
 ${net0.dhcpv6/iaid}

Those 3 in addition to the ip6 address would be sufficient to allow
whatever boot's next to do a RELEASE or RENEW of the current lease if
it should desire to do so.

I wrote a patch to expose those as settings under the dhcpv6 scope, are
patches proposed on the mailing list or as pull requests on the github
mirror? (I could'nt figure out from the docs.)


Regards
Harald


[1] https://tools.ietf.org/html/rfc8415
[2] 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012707.html