Review if any items of draft-ietf-v6ops-dhcp-pd-per-device-04 are useful / applicable to stub router

[EskoDijk]

See draft: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device-04

which just passed WGLC today.

This has some potentially useful considerations and requirements related to the SNAC stub router. In particular,

• Section 8: PD prefix length - required to be /64 or smaller
• Section 9: Client Mobility - do we consider this? Also relates to #37 requirements for DHCPv6-PD rebind/renew.
• Section 11: refers to a new PIO flag that indicates DHCPv6-PD is "preferred" in this network. Should a SNAC stub router do anything with this flag (yet)?
• Section 11: considerations when running out of PD prefixes - e.g. in a home network. What would a SNAC stub router do if no more prefixes are available? (e.g. fallback to self-generated prefix for stub network)

[EskoDijk]

Note the draft that defines the new "P" flag for PIO in RA to signal that DHCPv6-PD is preferred over SLAAC is https://datatracker.ietf.org/doc/html/draft-collink-6man-pio-pflag-03

[Abhayakara]

Regarding section 11, this has no bearing on what we do for the stub network, but does bear on what we do for the AIL. If the AIL provides PD-per-host, then this means we don't need to advertise a prefix with the 'A' bit set on the AIL: PD-per-host addresses our concern, because Android will support PD-per-host and everything else supports at least NA-per-host.

[Abhayakara]

Regarding section 9 as mentioned above, we have a separate issue for that, so we will not address that point in this issue.

[Abhayakara]

So the last two points Esko mentions above are what needs to be addressed in this issue. We should also make sure that the first point is addressed, but I think it already is.

[EskoDijk]

@Abhayakara Indeed the first point on /64 prefix length is addressed in the current -04 draft already, Section 5.2.3.

On the handling of the P flag: if the P flag is set (meaning PD-preferred-over-SLAAC) - I don't think this has any impact on the determination of a suitable prefix on the AIL, and the generation of a suitable prefix by the stub router.

Suppose the A flag = 0 and P flag = 1: to get an address, DHCPv6-PD would be required. And we have our basic assumption in 5.1.1:

Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"—not all hosts can actually use it.

Therefore the infrastructure-advertised prefix is not suitable.

[Abhayakara]

Hm. Yes, that's the statement. But the reason we make that statement is that both of these are true:

1. DHCPv6 is not required
2. There are a lot of devices that therefore don't do DHCPv6

The point with PD-per-host is that although (1) remains true, (2) would no longer be true.

So I guess the question is, are we determining suitability as a matter of principle, or as a matter of practice? My answer was considering it a matter of practice.

[EskoDijk]

@Abhayakara Could you explain why point (2) would no longer be true? There could be legacy (IoT) hosts on an AIL that don't do DHCPv6, that certainly don't do PD-client / PD-per-host, and are not going to be sw-upgraded to use any of these.
The legacy hosts could include years-old printers, Matter devices, older Android devices, etc. Any prefix with A=0 would not be usable by these hosts regardless of the 'P' value or the presence of DHCPv6-server or not.