Description of problem: The command "openstack baremetal node provide" fails with "Port <MAC> already exists, uuid: <port_UUID>" when using BMaaS on IPv6 When deploying with IPv4 there are no issues. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Answering the query regarding the use of DUID vs Client Link-Layer Address (option 79). The issue with DUID is that it can be generated based on different methods, quote from: https://www.rfc-editor.org/rfc/rfc3315 """ A DUID consists of a two-octet type code represented in network byte order, followed by a variable number of octets that make up the actual identifier. A DUID can be no more than 128 octets long (not including the type code). The following types are currently defined: 1 Link-layer address plus time 2 Vendor-assigned unique ID based on Enterprise Number 3 Link-layer address """ DUIDs are intended to remain constant over time, so that they can be used as permanent identifiers for a device. In the case of DUID-LLTs, they are intended to be generated once, stored in stable storage, and reused from that point forward. The issue is devices that employ multi-step network boot loading. The initial step (typically EFI firmware) will load a small image that, in turn, loads a second image and so forth until the actual target system is loaded. Each step in the booting process may invoke DHCP. Unfortunately none of the initial DUID types where ideal for this use-case. And the reality of actual implementations are fractured, different firmware, Network-Boot-Programs (NBP), bootloaders and operating system implementations selected one of DUID-type's, but not necessarily the same. The result is that the in the multi-step network boot loading use-case the DUID for each "step" is more likely to be inconsistent than consistent. An attempt to remedy this issue came with RFC 6355 which introduces the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (https://www.rfc-editor.org/rfc/rfc6355). Unfortunately, despite being 10+ years this has not yet been implemented across the industry. The variety of vendors/firmware/boot programs etc are still using a variety of DUID types. Because of this the most practical, broadly supported approach was to use the client link layer address (MAC-address) as the identifier used to map a specific system server side to consistently deliver correct options/configuration to each stage of the multi-step network boot loading process. When the client and server is on the same network segment, the server (DHCP server) can discover the clients MAC address using Neighbor Discovery Protocol (NDP). When a relay is used we require the Client Link-Layer Address (option 79) to ensure the MAC address is available when the forwarded request reach the server.