Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

[Lorenzo Colitti <[e-mail]>]

On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson <[e-mail]> wrote:

> That said, for me having the additional DHCPv6-assigned address in
> addition to the SLAAC one has been a net negative, since it doesn't
> reconfigure along with the link prefix following a PD change (but
> nevertheless tends to be preferred for outbound traffic). Maybe this
> would have been better if it was a ULA rather than a GUA though, I
> don't know.
>

That's an excellent point.

More in general I'd say that IA_NA is a net loss in *any* network where
addressing can unexpectedly change, such as a tethering hotspot, a small
enterprise, or even a medium enterprise using PA addresses. For exactly
this reason. (In fact - I don't think we even know how to make that sort of
thing at all without NAT.)

I'm sure many will just say that I'm biased, but think about it - if you
can't tell the hosts that something has changed, then how do you deal with
routing and renumbering changes? Even if hosts were to support DHCPv6
reconfigure, which they don't, how do you reconcile that with the assertion
that the value proposition is that DHCPv6 provides centralized management?
How do you do that at scale? Does the DHCPv6 server need to know about all
topology changes so it can issue appropriate RECONFIGUREs? What if the
topology change was such that the global address of the DHCPv6 server is no
longer valid due to renumbering? And so on.