On Feb 3, 2015, at 3:44 AM, Markus Stenberg
<markus(_dot_)stenberg(_at_)iki(_dot_)fi> wrote:
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.)
I think this is future work. The MIF working group did consider whether to
separate IPv4 and IPv6 PVDs; my belief was that we should, but the consensus
was that they should be able to be kept together. I think it's true that the
capability to authenticate an explicit provisioning domain's container across a
home gateway that is doing NAT for IPv4 is unlikely to work without some care.
However, it's not clear to me that this is even a use case that we care about.
If it is, then it can be addressed by treating the NATted provisioning domain
as a different provisioning domain than the external IPv4 provisioning domain.
It's actually not usual however for HGs to even pass the external PVD
information into the home network on IPv4 NATs. Instead, it sets up a DNS
proxy and advertises that, and passes nothing else through at all.
- 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)
This is another alternative, but it would only be necessary in the case where
you wanted to advertise a translated prefix internally and have that be treated
as the same PVD as the externally advertised prefix. Since the current
architecture document doesn't make specific recommendations about this, I don't
think that we need to add anything, but if you think it's worthwhile we could
add text that just explains the issue you've raised and talks about your
proposed solution and possibly the one I've suggested.
I don't really want to add text about this, because I don't think it's been
thought through carefully, and there are some holes in it that I can see. For
example, there's no way to prove that an advertised NAT prefix actually reaches
the PVD that it is claimed to reach. So you are pretty much at the mercy of
the HG anyway.
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.
Me too, but I think that ship has already sailed. And if you think about it,
your point about RA and DHCPv6 is clearly an implementation issue: the
implementation for explicit PVDs has to make it possible to connect them,
because in practice they are related. So there's no technical reason why this
can't also work for DHCPv4 and explicit PVDs.
Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have TLS
transport? (X.509 certificate would fit better.)
How about "PKI" instead of "TLS"? I know PKI generally means X.509, but it
isn't restricted to X.509.
Nit: In section 9, I am Markus, not Marcus ;)
Sorry about that. Thanks for the thorough review!