Your message dated Fri, 24 Jan 2025 23:37:39 +0100
with message-id <[email protected]>
and subject line Re: undionly.kpxe doesn't handle IPv6 NDP
has caused the Debian Bug report #1011947,
regarding undionly.kpxe doesn't handle IPv6 NDP
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1011947: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011947
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ipxe
Version: 1.0.0+git-20190125.36a4c85-5.1
Severity: normal
Tags: ipv6
Hi,
My infrastructure has IPv6 and is announcing IPv6-only DNS servers over
Router Announcements in addition to having regular DHCPv4. The Router
Announcements have the Managed Bit set, but the DHCPv6 server doesn't
answer if there is no host-specific data in the DHCP configuration.
I have a certain machine that doesn't boot in this environment. A trace
shows the following.
- machine is turned on, link up
- Intel Boot Agent does DHCPv4, gets next-server and boot file name
undionly.kpxe
- Intel Boot Agent does tftp, downloading undionly.kpxe.
- undionly.kpxe does DHCPv4, gets next server and URL to an ipxe menu.
- undionly.kpxe does Router Solicitation and receives a Router
Announcement
- undionly.kpxe tries to reach a DHCPv6 server multiple times, no reply
- I do NOT see the system doing IPv6 DAD, nor do I see the system
joining any multicast groups. According to RFC4861 7.2.1, the node
MUST join at least the all-nodes multicast group and the
solicited-node multicast group belonging to the MAC address of the
Interface.
- undionly.kpxe sends out an AAAA query for the host name part of the
URL via IPv6 to one of the name servers given in the Router
Announcements (the DNS server is on a different network, so the packet
gets actually sent to the default gateway).
- The default gateway sends a neighbor solicitation for the IPv6 address
that the DNS query was sent from, using the correct solicited-node
multicast IPv6 and MAC addresses
- the system doesn't react to this neighbor solicitation
- the system re-sends the DNS query and ignores the neighbor
solicitation again.
- this repeats a couple of times until ipxe gives up
The IPXE feature list given on the console while running also does not
contain any reference to IPv6 being enabled.
What kind of confuses me is that a Thinkpad X121e connected to the same
switch port with the same cable boots off this network just fine. It
doesn't join the multicast groups either, but it looks like it is able
to make sense out of the neighbor solicitation, responds properly, gets
its DNS queries answered and is able to continue the boot process
despite the RFC violation of not joining those multicast groups.
Turning off the RDNSS option in the router announcements made the system
use the IPv4 name servers from the DHCPv4 assignment, which eventuelly
allowed the machine to boot.
So I think we're having three bug reports here:
- the IPv6 RFC violation of not doing IPv6 DAD and not joining required
multicast groups
- not being able to properly receive the multicasted neighbor
solicitation of the gateway on one particular type of hardware
- not trying one of the other DNS servers after the queries to the first
one were unsuccessful
I am not reporting this upstream since upstream has advanced
considerably since this package was uploaded to Debian. Do you need help
packaging a current version of ipxe?
Can I do anything else to help with this bug report and/or ipxe?
Greetings
Marc
--- End Message ---
--- Begin Message ---
Source: ipxe
Version: 1.21.1+git20220113.fbbdc3926+dfsg-1
On Sun, 19 Jan 2025 16:02:50 +0100 Sven Geuer <[email protected]> wrote:
> On Fri, 27 May 2022 15:46:38 +0200 Marc Haber
> <[email protected]> wrote:
> > So I think we're having three bug reports here:
> >
> > - the IPv6 RFC violation of not doing IPv6 DAD and not joining required
> > multicast groups
> > - not being able to properly receive the multicasted neighbor
> > solicitation of the gateway on one particular type of hardware
> > - not trying one of the other DNS servers after the queries to the first
> > one were unsuccessful
>
> From reading upstream's commit messages up to the currently packaged
> ipxe version 1.21.1+git20220113.fbbdc3926, I believe your case has been
> covered. Unfortunately I have no environment available to verify this.
> Would you please check and report back?
Meanwhile I could verify the version listed above has full IPv6
support. I could boot an image via IPv6 running ipxe from a ROM as well
as chainloading undionly.kpxe first and booting the image from there.
Closing this bug therefore.
Sven
--
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585
signature.asc
Description: This is a digitally signed message part
--- End Message ---
