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