[ipxe-devel] iPXE ipv6 autoconf with multiple Router Advertisements

[Sven Wiltink]

Thanks for the quick response. I think it can be well defined when ipv6 conf
has been completed, but I'm lacking the C programming skills to implement it.

We should be able to define ipv6conf as finished when the following statements are true:
1) an RA has been received that pushed a prefix with slaac enabled
2) an RA has been received that advertises itself as default router (lifetime > 0)

Once both are true, which can be achieved by the same packet, within the autoconf timeout we are done.
There is a problem however, the RA packet could trigger dhcpv6 if the O flag is set. In that case
autoconf is currently terminated when dhcp6 finished. In the new situation that isn't always true as dhcp6
could still be running before the other RA packet arrives. To prevent this both the processing of the RA
packets and the ending of dhcp6 should check if all the other parts of autoconf have been completed. 
This means we could define it as finished when:

1) an RA has been received that pushed a prefix with slaac enabled
2) an RA has been received that advertises itself as default router (lifetime > 0)
3) dhcpv6 was triggered and completed successfully

I'm not sure how this would work in the code or where to add the state, would like to hear
your thoughts.

-Sven
On 26/08/2024, 17:10, "Michael Brown" <mcb30 at ipxe.org <mailto:mcb30 at ipxe.org>> wrote:


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