On 26/08/2024 16:34, Sven Wiltink via ipxe-devel wrote:
We are running a setup where there are two machines sending Router
Advertisements. One of which sends a /64 prefix with slaac enabled , a
router lifetime of 0 and the O flag set to trigger dhcp. The other
machine ( the router) in the meantime sends a /48 prefix, which should
be used to configure the gateway.
The problem however is that is looks like the iPXE network stack doesn’t
support this. When performing ipv6 autoconf in
`ipv6conf_rx_router_advertisement` the packets are discarded if ipv6conf
has been completed or if a different packet is being processed. This
causes a race condition between our two Router Advertisements. Depending
on which packet arrives first either the gateway is missing or no slaac
has been performed.
A dirty hack to get the setup to work in a test was to simply ignore the
ipv6conf and timer_running and always apply the received settings. This
‘works’ but I assume the check for ipv6conf are in place for a reason.
Do you have any suggestions on how to get our setup to work with iPXE?
That's an interesting problem. The checks in
ipv6conf_rx_router_advertisement() are there for two reasons.
Internally, we have various other parts of iPXE assume that the list of
registered settings blocks will not change spontaneously while e.g.
waiting for keyboard input, and so life is simpler (and avoids bad
pointer dereferences) if we ensure that this happens.
More importantly, and unlike a general purpose operating system, iPXE
needs to have a well-defined decision point at which a boot attempt has
either succeeded or failed. We cannot in general assume that the user
would like to continue retrying the current attempt indefinitely, so
everything has to be geared to reaching this success/failure decision.
This is why, for example, register_usb_bus() will ensure that all
devices already present on the bus have been enumerated before it
returns (even though we do fully support USB hotplug): this is done so
that we can have a well-defined answer to the question "do we have any
network devices to try booting from?".
In your network setup, there is no well-defined point at which iPXE
could reliably know that it is going to receive a further router
advertisement containing critical information. The problem is analogous
to the use of ProxyDHCP, which we support by deliberately stalling the
DHCP state machine transition to allow time for an inherently unreliable
ProxyDHCPOFFER to arrive.
So, I think the proper solution would have to involve some careful
thought about how to define the end point of IPv6 autoconfiguration to
allow for setups such as yours. You'd need to handle corner cases such
as ensuring that at least two router solicitations are sent, to allow
for the possibility that one router might have missed seeing the
solicitation. I would probably start by looking at the way that the
DHCPv4 state machine handles transitions out of the DHCPDISCOVER state,
since this is essentially an isomorphic problem.
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
