Re: IPv6 Stable Private Addresses RFC 7217

[Ted Lemon <mellon%fugue.com@localhost>]

On Jun 4, 2014, at 8:36 AM, Roy Marples <roy%marples.name@localhost> wrote:
> Surely a diskless host should be able to cope with address changes? I mean, 
> changing address via DHCPv4 is neither new nor rocket science.

The issue would arise if you were using IP addresses to authenticate your NFS 
mounts.   I haven't followed the state of the art in NFS for a long time, so I 
don't know if this is still required, but it certainly was back when I used to 
use it, and there's a PR for dhclient that remains unaddressed that has to do 
with this issue.

The right way to fix it is definitely to use a different authentication 
mechanism that is robust in the face of IP address changes.

> If you want the same behavioral traits as IPv4 then at a guess you would need 
> to make IN6_IFF_NODAD assignable from userland (currently it's rejected).
> I'm not entirely sure that's a good idea though.

As a general rule, if you want the behavior traits of IPv4, the best way to get 
them is to use IPv4.   Trying to make IPv6 look like IPv4 because of some IPv4 
behavior to which one is accustomed is generally not a good idea, because you 
are likely to break something in the process.

That said, there are unaddressed problems with respect to server numbering for 
IPv6 in the presence of DAD, as well as in the presence of prefix deprecation 
during renumbering.

The DAD problem is that if a server is supposed to have address MY_PREFIX::1, 
and some other device on the network claims that address, the server ought to 
win, because its address is no doubt published in the DNS, and isn't suitable 
for changing.

This is related to the renumbering problem: you have a host that you want to be 
reachable using a particular domain name, but numbering on your network is not 
guaranteed to be stable: you are subject to renumbering from your ISP, or when 
switching ISPs.   You'd like the host's AAAA record to change when it's 
renumbered. Right now there's no way to do this.

Addressing this problem by providing a mechanism for updating the DNS 
automatically when DAD fails or when you get renumbered would be a win.   
However, DNS doesn't guarantee freshness for updates that occurred more 
recently than the TTL on the record, so this still doesn't really solve the DAD 
problem--it just mitigates it somewhat.   To solve it you need something like 
SAVI on your switches, so that they can prevent address stealing.   IOW, this 
is not something you can actually prevent on the host.