Re: A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 15/2/19 18:20, Sander Steffann wrote:
> Hi Lee,
> 
>> Seems to me several operators have offered their opinions here. If you want more opinions, maybe ask a group of operators?
> 
> Not a very helpful comment... I think the underlying problem here is that there is no technical solution available that solves stable IPv6 address delegation at residential scale in an acceptable way.
> 
> - For stable address delegation the routing inside the ISP becomes a mess, especially when it can't be guaranteed that a customer consistently ends up at the same BNG.
> - To keep ISP networks scalable, prefixes are aggregated to (roughly) BNG level, making it impossible to keep prefix delegation stable at the customer's end
> 
> With IPv4 this didn't cause massive problems because NAT disconnected the LAN addresses from the WAN side at the customer's end. With IPv6 this is no longer the case and it does cause problems.
> 
> Stability at one end causes instability at the other end, and vice versa.
> And as can be seen from this discussion it's still an unsolved problem...

While I'm not sure the extent to which one can completely solve the
problem, it *is* possible to make deployments way more robust that they
currently are.

Hopefully the next rev of our document will have things more thoroughly
spelled out.

Having thought about the problem for some time now, the lack of
robustness has a lot to do with these three items:

1) Inappropriate use of timers in SLAAC

Clearly, the whole point of having timers is that, when things go wrong,
they eventually go off. SLAAC uses default values for timers in the
order from one week to one month (!). That makes the timers completely
useless. They will never go off, and will never allow you do do anything
sensible about any problem scenario.

2) No mechanism to phase out addresses

If timers were used appropriately, you wouldn't need this. But with the
values that we currently use for SLAAC, hosts do need some smarts to
deprecate addresses and removing them. Otherwise,  an address that was
e.g. incorrectly advertised or that has become stale will be preferred
for one week and remain valid for a month. That's kind of insane.

3) Under-specification of the interaction between DHCPv6-PD and SLAAC

This is largely unspecified. Among other things, we should specify how
DHCPV6 timers are translated into SLAAC timers, that preivously-leased
prefixes should be announced with a lifetime of 0 to help remove them on
the LAN side, and also that the SLAAC timers should be dynamically
reduced as the lifetimes on the WAN-side are reduced. -- otherwise,
you'll be making promises on the LAN side based on promises you did
*not* get on the WAN side.


If we had always had 1) and 3), we probably wouldn't need 2) that much.
But the cat is out of the bag already, and we now also need 2), to deal
with scenarios where we don't have 2) and 3).

What we can achieve with the above is allowing nodes to have a more
timely reaction to network configuration changes -- infer that some
prefix has been phase out, unprefer the corresponding addresses, and
eventually remove them.

Other stuff that has been mentioned on this thread is unrelated: e.g.,
transport connections breaking. Yeah, of course this is important for
robustness, but is to be handled over layer-4, and is completely
unrelated to what we are discussing here.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1