Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <20150123153536.10431.23196.idtracker@ietfa.amsl.com>
Date: Tue, 3 Feb 2015 10:44:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi>
References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/cKJgd1syXOmYcLet22Cmbp3Mhw0>
Cc: Markus Stenberg <markus.stenberg@iki.fi>, mif@ietf.org,
 IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple
 Provisioning Domain Architecture) to Informational RFC
Precedence: list

I am not sure if this document has been really thought through in terms =
of IPv4, or the dual-stack case.=20

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=