Bug 1779187

Created attachment 1664021 [details]
A bug fix from upstream, this fix also solves conflicts in following cherry-picks

Created attachment 1664022 [details]
This is the primary fix for this bug

This patch cherry-picks the commits from upstream master which implements support to use a prefixed ipv6 address, or multiple ipv6 addresses in a single dhcp-host entry. Using multiple addresses allows the network boot chainloading to work, as each step get's a different lease.

*** Bug 1804382 has been marked as a duplicate of this bug. ***

Created attachment 1664023 [details]
cherry-pick of upstream patch which add tag filtering support to dhcp-host entries

Tag filtering support for dhcp-host entries are useful for network booting scenarios, one can have a general dhcp-host entry using a prefix or multiple IPv6 addresses for the network chain booting steps. The final OS can be configured to include a userclass option, wich can then be used to ensure the final OS always get's the same address leased.

Config example:
  dhcp-userclass=set:dhclient,dhclient

  dhcp-host=52:54:00:3f:5c:c0[fd12:3456:789a:1::aa04/126],host1
  dhcp-host=tag:dhclient,52:54:00:3f:5c:c0,[fd12:3456:789a:1::aa01],host1

Created attachment 1664024 [details]
RPM SPEC file with the 3 patches attached to this bug.

@Petr Menšík

I've attached three patches and a RPM SPEC file, two fo patches cherry picks the changes that landed in upstream dnsmasq, see mailing list thread: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013772.html. The first patch is cherry-picks a bugfix from dnsmasq-2.80 which also help solve some merge conflicts in the two patches implementing a fix for this bug.

I did a little testing with the resulting RPM built with these patches and did'nt run into any issues.

Please review the changes, we need this fixed in dnsmasq to deliver functionality in layered products.

Thanks!

(In reply to Harald Jensås from comment #6)
> @Petr Menšík
> 
> I've attached three patches and a RPM SPEC file, two fo patches cherry picks
> the changes that landed in upstream dnsmasq, see mailing list thread:
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013772.html.
> The first patch is cherry-picks a bugfix from dnsmasq-2.80 which also help
> solve some merge conflicts in the two patches implementing a fix for this
> bug.
> 
> I did a little testing with the resulting RPM built with these patches and
> did'nt run into any issues.
> 
> Please review the changes, we need this fixed in dnsmasq to deliver
> functionality in layered products.
> 
> Thanks!

Looks great, thanks for porting it to the supported version.

Just one question occurred to me when looking at the change. What would "dig -t AAAA @${SERVER} host1" command return on those leases? When there is four addresses allocated and used more addresses during boot, would temporary iPXE address disappear only after lease time for it expired? Would it bother you, when such name would give multiple addresses? Because only one of them would probably work, other would be from previous boot stage only and no longer reachable.

In provided example configuration, port=0 suggests DNS features are not used at all. If lease could be configured significantly shorter for special network booting configurations, it would reduce possible timeout when using name to access the host. Unless boot stage releases such lease before it continues, I do not think there is somethink to do about it. Maybe only use special name (for example -boot suffix?) for netboot related addresses and normal (dhclient) lease would have different name. But that would kind of defeat simplicity of those changes.

(In reply to Petr Menšík from comment #7)
> Just one question occurred to me when looking at the change. What would "dig
> -t AAAA @${SERVER} host1" command return on those leases? When there is four
> addresses allocated and used more addresses during boot, would temporary
> iPXE address disappear only after lease time for it expired? Would it bother
> you, when such name would give multiple addresses? Because only one of them
> would probably work, other would be from previous boot stage only and no
> longer reachable.
> 

For the openstack ironic provisioning usecase we don't care about the AAAA records.

This was discussed on the upstream mailing list[1], the AAAA record will be the last leased address. So during boot the record would keep changing as addresses are used and end up pointing at the address leased to the final OS. It's not ideal, but between PXE/HTTP boot firmware behaviour and the DHCPv6 RFC we could'nt come up with anything better. The AAAA record pointing to the temporary iPXE address would be replaced when the next in chain get's a different lease.

The support for tag's on dhcp-host entries helps, since it's relatively easy to ensure the final OS always get the same address leased. For example:

a) Set userclass option on the client:

  File: dhclient.conf
  -------------------
  options dhcp6.userclass code 15 = string;
  # len: 00:08, "dhclient"
  send dhcp6.userclass 00:08:64:68:63:6c:69:65:6e:74;
  -------------------

b) Match on userclass, and always assign 2001:db8::aa01 to the final OS:

  dhcp-userclass=set:dhclient,dhclient
  dhcp-host=52:54:00:3f:5c:c0,[2001:db8::aa04/126],host1
  dhcp-host=tag:dhclient,52:54:00:3f:5c:c0,[2001:db8::aa01],host1


Another option would be to remove the hostname from the entry with the prefix address range to avoid "poisoning" the DNS, i.e:
  dhcp-userclass=set:dhclient,dhclient
  dhcp-host=52:54:00:3f:5c:c0,[2001:db8::aa04/126]
  dhcp-host=tag:dhclient,52:54:00:3f:5c:c0,[2001:db8::aa01],host1


> In provided example configuration, port=0 suggests DNS features are not used
> at all. If lease could be configured significantly shorter for special
> network booting configurations, it would reduce possible timeout when using
> name to access the host. Unless boot stage releases such lease before it
> continues, I do not think there is somethink to do about it. Maybe only use
> special name (for example -boot suffix?) for netboot related addresses and
> normal (dhclient) lease would have different name. But that would kind of
> defeat simplicity of those changes.

Yes, using short lease times for the temporary addresses is a good idea. Again the tag support for dhcp-host entries makes this possible. For example a 1 minute lease time for addresses used by temporary, and infinite address for the address provided to the final OS:

  dhcp-userclass=set:dhclient,dhclient
  dhcp-host=52:54:00:3f:5c:c0,[2001:db8::aa02],[2001:db8::aa03],[2001:db8::aa04],[2001:db8::aa05],1m
  dhcp-host=tag:dhclient,52:54:00:3f:5c:c0,[2001:db8::aa01],host1,infinite 



[1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013684.html

Created attachment 1668131 [details]
Prefix length fix for prefixes under 96

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1715