One more thing I would like to mention:
When I set the bootfile-url to the "tftp://[fe80::2]/" (where fe80::2 is a statically assigned link local address of the TFTP server), RPi4 is able to communicate with the TFTP server, and it does receive the packet from the SLAAC-produced address (global, from the router advertisement).
According to the https://datatracker.ietf.org/doc/html/r ... ection-2.1, unicast link-local address is required.
Although IPv6 netboot does solicit the router advertisement, the absence of any routers on the network should not preclude the PI from booting, if DHCP6 offer & parameters are available.
E.g. it's expected that communicating with "fe80::2" (unicast link-local address of the TFTP server) should be happening from the link-local source of RPi4, not from the global address.
Hope we can make things better, and push this feature to beta stage.
Thanks for your responses!
When I set the bootfile-url to the "tftp://[fe80::2]/" (where fe80::2 is a statically assigned link local address of the TFTP server), RPi4 is able to communicate with the TFTP server, and it does receive the packet from the SLAAC-produced address (global, from the router advertisement).
According to the https://datatracker.ietf.org/doc/html/r ... ection-2.1, unicast link-local address is required.
Although IPv6 netboot does solicit the router advertisement, the absence of any routers on the network should not preclude the PI from booting, if DHCP6 offer & parameters are available.
E.g. it's expected that communicating with "fe80::2" (unicast link-local address of the TFTP server) should be happening from the link-local source of RPi4, not from the global address.
Hope we can make things better, and push this feature to beta stage.
Thanks for your responses!
Statistics: Posted by vintozver — Mon Oct 21, 2024 11:14 pm