lcolitti
commented
2 months ago In -06 we changed the title and added text to clarify that the P bit signals that the network supports the pd-per-device draft. That draft specifies a SLAAC-sized prefix (currently /64) and contains address usage considerations.
The reason it's important to signal "network supports pd-per-device" and not "network supports DHCPv6 PD, but there is no expectation on what prefix length will be assigned" is that pd-per-device implementations ask for a SLAAC-sized prefix. Many networks today (e.g., home networks) will respond to this by delegating /64s, but will run out of space if many devices ask. This makes it impossible to safely roll out support for pd-per-device on the device side.
The DHCPv6 server cannot easily fix this exhaustion problem because it cannot know if DHCPv6 client needs a /64 (e.g., RFC 7084 router) or could use a /64 (pd-per-device). Even if the server did detect this and returned NoPrefixAvail, that would slow down pd-per-device clients, which would have to wait to see if there's another server that can provide a SLAAC-sized prefix, or fall back to SLAAC. And obviously, existing servers wouldn't have code to do this.
This does not prevent us from defining other deployment models that uses prefixes longer than /64, or even deploying them today. Because delegating prefixes longer than /64 (e.g., /80) will not cause prefix exhaustion, these new deployment models would not need to be signalled - the device can just send a prefix delegation request with a longer hint and see if it gets a response.
ekline
While this draft triggers concerns about address space. The mechanism in this draft, both for network extensions and for host addressing from a PD does not depend on a particular prefix length. This draft is regardlessly not the place to change the 64 bit interface-id.
I would like to ensure that this mechanism is available to all networks, large and small, and that ensure further network extensions are possible.
Prefix delegation (or as I’d rather like to call it in this context prefix assignment) supports that.
There is a simple fix to the document to achieve that I belive. Simply remove the following:
OLD: "If the host does not obtain any suitable prefixes via DHCPv6 PD that are suitable for SLAAC, it MAY choose to disable further processing of the P flag on that interface, allowing the host to fall back to other address assignment mechanisms, such as forming addresses via SLAAC (if the PIO has the A flag set to 1) and/or requesting individual addresses via DHCPv6. “ NEW: —
OLD: "If the delegated prefix is too long to be used for SLAAC, the host MUST ignore it. If the prefix is shorter than required for SLAAC, the host SHOULD accept it, allocate one or more longer prefix suitable for SLAAC and use the prefixes as described below.”
OLD: "When a host requests a prefix via DHCPv6 PD, it MUST use the prefix length hint Section 18.2.4 of [RFC8415] to request a prefix that is short enough to form addresses via SLAAC.”
NEW: "The host MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more."