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

[Fernando Gont <[e-mail]>]

Bert,

On 15/2/19 18:51, Manfredi (US), Albert E wrote:
> -----Original Message----- From: ipv6 <[e-mail]> On
> Behalf Of Sander Steffann
> 
>> - 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...
> 
> Right, but I would come back to my previous point. In the IID
> discussions, a lot of time was spent justifying why stable IIDs are
> not a good idea, and testing was done to see what breaks when IIDs
> are changed frequently. If changing the IID is doable, seems not to
> break many applications, and is touted as a meaningful security
> measure, then those same considerations should apply to the prefix.
> Yet, we're not seeing a push for varying prefixes, as we got for
> keeping IIDs unpredictable or even short-lived.

Agreed.



> Instead, now there's a shift in thinking, where changing the IPv6
> address is not so useful for security (which I too have been thinking
> all along).

That's certainly not me.

Please let me be crystal clear on this one: if you make prefixes stable,
then things like RFC4941 become mostly useless -- as an attacker, I
wouldn't need to care about the IID, because I'd use your prefix for
tracking.

I'm not arguing in favor of dynamic prefixes. But I'm not arguing
against them, either. -- there are trade-offs involved.

What we should not do is making stable prefixes a "must". In fact, we
are moving towards "do temporary-addresses only if you wish" when it
comes to address generation, so it wouldn't be consistent to try to
force stable prefixes.


> 
> We should be consistent. Just as stable IIDs, even EUI-64 based
> IIDs,

FWIW, we recommend against EUI-64 (see RFC8064 and RFC7721). You don't
need EUI-64 to get stable addresses -- that's what we have RFC7217 for.
But, as long as EUI-64 is not the default, and the user needs to do work
to go against the advice (i.e., SLAAC defaults to RFC7217, as it does)
I'm fine.



> should be permissible, when they make sense (such as in enterprise
> networks), we are no longer depending on them or suggesting to do
> this. 

Exactly.


> They are a special case. Perhaps the same ought to apply to
> stable prefixes. Networks which want those can use whatever means
> they need, such as non-volatile memory in CPE devices. Otherwise,
> they should not be recommended and not be the norm? Just asking.
> Maybe this problem should go away.

As usual, I think this is the tip of an iceberg. If things break when
you don't do stable prefixes, then that's an indication that there's
underlying network brittleness. It turns out that we have put state in
the middle of the network -- e.g. on the CPE -- and that the network
fails to recover from that.  The current SLAAC timers essentially tell
you that it will take nodes one week to un-prefer an address, and one
month to remove it. Clearly, that's unacceptable.

Clearly, a CPE crashing and rebooting is one scenario in which nodes may
end up with stale information. But there are many others (e.g., what if
radvd crashes and rebobots?  Does radvd advertise prefixes with a
lifetime of 0 when information is changed, or before the daemon is exiting?)

Yes, the network should behave more nicely. And I'm all for that. But we
should not rely on state in the network for the network to be robust.
That seems to go against the very Internet architecture and design
principles.

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