Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Ole Troan <[e-mail]>]

>>> 
>>> Well, the problem is that you are making a contract on the LAN side for
>>> a contract you may not have on the WAN side. If the router reboots and
>>> the CEP no longer "owns" some prefix, then that contract is void.
>> 
>> You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020.
>> A reboot doesn’t change that. 
>> 
>>> Ideally, the CPE will advertise that the contract is void. But it is
>>> clear that for most deployed CPEs, that will not happen.
>> 
>> So a bug. 
>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 
> 
> The CPE is the middle-man between the ISP and the LAN. No matter what
> you may *expect* the CPE to do, the CPE is currently not actually
> required to e.g. clean after the contract that the ISP broke (if you
> assume/think there's such a thing), or even adjust prefix timers
> according to the DHCPv6 lease times -- talk about under-specification of
> the glue between e.g. DHCPv6-PD and SLAAC.

RFC3633:
   Each prefix has an associated valid and preferred lifetime, which
   constitutes an agreement about the length of time over which the
   requesting router is allowed to use the prefix.  A requesting router
   can request an extension of the lifetimes on a delegated prefix and
   is required to terminate the use of a delegated prefix if the valid
   lifetime of the prefix expires.

This really isn’t hard.

> Besides, the layer-8 contract between the user and the ISP may be that
> you get dynamic prefixes. This means that whenever you request a lease,
> you get a different prefix. You might say that if you don't do another
> DHCPv6-PD request, you should be able to use the same prefix. But if you
> do ask a new prefix, you might indeed get a new one -- and this is what
> normally happens after reboots.

Not normally. That’s ISP allocation policy.
And not recommended.
But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message.

> The CPE should -- if possible -- be faithful to its LAN hosts, and
> advertise if previous contracts between the CPE and the LAN hosts are
> void. i.e., if the CPE does  not get leased the same prefix as before,
> it shoudl notifiy its "clients". However, possibly for simplicity sake,
> CPEs don't record what
> information was previously advertised on the LAN -- they are not
> required, so.... when they reboot, they may not not be in a position to
> notify hosts accordingly.
> 
> That's the environment hosts operate in -- no matter whether you or me
> like it.
> 
> In that environment, hosts can and should be smarter.

Sure. Hosts should always be smarter.
That doesn’t mean an addressing policy which breaks connections are not broken.

>>>> What you seem to be talking about is either a bug a misconfiguration or both. 
>>> 
>>> It's neither of those. If anything, it's the result of
>>> under-specification of the necessary glue between automatic
>>> configuration on the WAN side, and automatic configuration on the LAN side.
>>> 
>>> e.g., there were no requirements for CPEs to keep track of prefixes that
>>> they have been leased in the past -- if at all possible.
>> 
>> DHCP PD will give you the old prefix back. 
> 
> Not necessarily. In fact, it may intentionally not do that. If you no
> longer own the addresses, the sessions will have to be torn down.

That’s not how IPv6 addressing and renumbering is intended to work.
I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens.
(Which of course might encourage ISPs to do just that.)

>>>> If you want something like session survivability,
>>>> that’s not a trivial problem to solve.
>>> 
>>> Not sure what you mean by "session survivability"
>> 
>> Try to keep a TCP session active while changing addresses. 
> 
> Of course that's not what we're trying to solve here.

No, but it is important to understand the implications of your work.

>>>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.
>>> 
>>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes?
>>> 
>>> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages
>>> are soft errors. And it would be a huge mistake (and huge
>>> vulnerability!) to behave otherwise.
>> 
>> It’s a strong hint to the host stack to pick a different source address. 
> 
> You said "deprecate the invalid prefix if it has information to do so."
> -- selecting a different address is a very different thing than
> deprecating an address. In fact, for connection-less protocols that
> might not even make sense -- since it implies resending stuff that you
> might not even be able to resend (send buffer is gone).

No, I didn’t say that.
I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0.
And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38.


> 
> Besides,
> 
> * You are assuming somebody will send an ICMPs. But they may not.

Is it interesting discussion assumptions that aren’t part of the specifications?

> 
> * You are assuming that if they do, they will send code 5. But they may not.

See above.

> 
> * You are assuming that code 5 is an indication of wrong address... but
> it may be an indication of incorrect route.

No.

> 
> * You are assuming that nodes will process icmp code 5 in one specific
> way. I don't know of any implementation that behaves in the way you
> describe.

Hosts can improve.
My point was that it isn’t obivous that very much more can be done from the network side.

>>>> Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. 
>>> 
>>> Not sure what you mean. If the same router that advertised those
>>> prefixes doesn't advertise those prefixes anymore, why would you think
>>> they are still valid?
>> 
>> Because that’s what the network previously advertised. 
>> If source addresses from that prefix no longer works that’s a good hint to the host to try something else. There’s a list of heuristics the host must use. 
>> 
>> I still don’t see how your draft improves much on this. Can you explain?
> 
> What our document wants to address is this:
> 
> * Initially, unprefer addresses for the deprecated prefix.
> 
> * subsequently, clean up the lagging addresses.
> 
> 
> One (more complex) way to achive this would be to e.g., wait for N *
> ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at
> least M RAs with PIOs have been received, but none of them contain PIOs
> for the (now invalid) prefix, deprecate the prefix.
> 
> The solution we currently propose in the I-D is simpler, and just
> involves one additional bit per prefix in the local data structures.
> 
> For a sample scenario, please check Appendix B of our draft. THe idea is
> simple: if two consecutive RAs with PIOs don't contain the
> previously-advertised prefix, un-prefer addresses for such prefix.
> Subsequently, once addresses have already been un-preferred, if you
> receive two additional RAs with PIOs that don't advertise the
> previously-advertised prefix, remove (invalidate) the corresponding
> addresses.
> 
> So, after two RAs, the lagging addresses are not preferred anymore.
> After four RAs, you get rid of them.

So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes?

I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this.

Cheers,
Ole