I am not sure if this document has been really thought through in terms of IPv4, or the dual-stack case. Notably, in section 2: * Source address prefixes for use by connections within the provisioning domain If we have a home router, which does NAT (and I dare you to find one that does not), the e.g. potential authentication mentioned in Section 2.3 becomes invalid in case of IPv4 as the source address prefix information has to change (or be omitted) for it to be useful. Section 2.5 further advocates combining both IPv4 and IPv6 PVDs, and as a result, whole authentication scheme becomes more or less invalid if not directly connected to the network PVD lives in. (And IPv4 source address prefix information has to change.) My proposal: - make use of source address specific optional with IPv4? (or note somewhere that prefix should be 0.0.0.0/0 if any use of NAT is ever thought reasonable using the PVD) On not so serious note, as PvD has (more or less) binding to the protocol it was used to acquire the configuration information (e.g. DHCPv4, DHCPv6, or RA), I would much rather advocate single-AF PvDs so their lifetime would map to the lifetime of the other network information received/updated via that particular protocol. My proposal (but I can live without too, this is mostly just elegance-of-design criteria for me): - unbundle dual-stack case so that IPv4 PVD comes from DHCPv4, and IPv6 PVD from DHCPv6/RA. Or at least make bundling optional; in case of e.g. IKEv2, having both from same source makes still sense. Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have TLS transport? (X.509 certificate would fit better.) Nit: In section 9, I am Markus, not Marcus ;) Cheers, -Markus