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

[Fernando Gont <[e-mail]>]

Hello, Philip,

Thanks so much for your feedback! Comments in-line...

On 19/3/19 09:35, Philip Homburg wrote:
> I spent some time thinking about Section 5.1.3 of
> draft-gont-6man-slaac-renum-01. This the part where the host deals with
> stale prefixes.
> 
> I'm interested in the host part for two reasons:
> - Solving the issue at the CPE requires persistent storage of network state,
>   which may be hard to require from all devices.
> - It may take quite a long time before all CPEs are replaced.

100% agree. The solution to the problem is mainly 5.1.3. The other stuff
may be of help, though, when the host has not been updated.



> So for any host it is worth dealing with the problem locally instead of 
> relying on the network.

Exactly.



> I find the following issues in draft-gont-6man-slaac-renum-01:
> - In the notes it says "The aforementioned processing assumes that while
>   network configuration information might be split into multiple RAs, PIOs
>   will be spread among *at most* two RAs."
> 
>   I think it is bad to deploy something on hosts that would force all
>   routers to comply with this.

Note:
The same concept can be implemented as follows:
keep a counter of consecutive RAs with PIOs that have not advertised the
existing prefix. And trigger actions after some locally-defined value "n".




> - The draft proposes many changes to router behavior in particular 
>   increasing the frequency of RA multicasts.

It's not really a change in the behaviour. It is playing with the knobs
that the protocol has, within the acceptable boundaries.



>   One problem is that hosts will only benefit from those changes when new
>   CPEs are deployed. The draft doesn't describe what will happen in networks
>   with unmodified CPEs

5.1.3 makes hosts benefits without updated CPEs.

The other stuff makes hosts befefit when the CPEs are updated, but the
hosts are not.



> - Increased multicast rates may have a negative effect on battery lifetime.

Point taken. However, it would seem to me that if you care about battery
life, rather than banning what a protocol does, the strategy
would/should be different. You have lots of protocols,
HTTP-based applications, etc., etc. You cannot police all at the
protocol level to save battery life.



> - The algorithm has a tight coupling between modifying the preferred and
>   valid lifetimes of addresses. In most cases, accidentially marking an
>   address as deprecated has little effect on connectivity. Deleting an
>   addresses by setting the valid time to zero immediately disrupts all
>   communication that uses the address.

But if you don't, you cannot communicate with the new "owners" of your
stale prefixes.



>   What is worse, these changes to the valid time are not necessary do deal
>   with the problem at hand: flash renumbering situations.

Not sure what you mean.



>   With respect to valid lifetimes, if two hosts are communicating locally
>   using global addresses, is it worth breaking that communication just
>   because the router ceases to send RAs for the prefix (i.e. well before
>   the lifetime of the prefix or the onlink status expires)

OTOH, if you don't, you will not be able to communicate with the new
owner of the prefix.


> 
> So I was looking at a change to host processing of RAs such that:
> - The host will quickly (on a human time scale) stop using the old
>   prefix
> - Any mistakes because the algorithm gets confused are relatively benign
> - No changes to routers are required for the algorithm to work, though
>   some currently allowed router behavior may lead to sub-optimal results.
> 
> The basic concept that I came up with is the following:
> - I assume that for each addresses that is configured using SLAAC the host
>   already maintains an associated default router to deal with poor man's
>   multihoming setups.
> - Add to each address a timetamp value that records when the last time
>   a PIO (with A bit set) was seen that covers the prefix (last_time_seen).
> 
> For each RA that is received, if the RA contains any PIO with the A bit set,
> processes those PIOs and update the last_time_seen value for addresses
> covered. Update the default router as well.
> 
> For each PIO with A bit set and preferred lifetime non-zero, collect
> the label values (based on the policy table in RFC 6724 "Default Address
> Selection") in a set.

What do you mean by "label"?


> 
> After processing all PIOs in the RA go over all addresses:
> - Skip any addresses that have a different default router
> - Skip any addresses that have a label not in the set that resulted
>   from processing the PIOs
> - Skip any addresses that have a last_seen_value that was less than 60
>   seconds ago
> - If the address has a preferred lifetime of more than 60 seconds,
>   reduce the lifetime to 60 seconds.

Counting RAs or using timers is essentially the same...


> 
> I picked 60 seconds because it is a value that works well on a human
> time scale. At the same time, if a router announces PIOs in multiple RAs
> then they should be sent within 60 seconds to see no change in host behavior.

In timeframe of 60 seconds you'll get at most one RA. If it happens to
be lost, you will not get any.


> (I guess that for battery lifetime it is best to send all multicasts
> together). If a router would spread RAs out over a longer period, 
> hosts will follow the RAs causing load to be distributed over multiple
> prefixes in a predictable fashion.

>From the pov of the folk doing troubleshooting, this is not of much help.



> 
> In simple CPE situations, this will cause old addresses to be deprecated
> 60 seconds after the CPE first announces the new prefix (most of the time).
> In rare cases, where the CPE quickly reboots just after sending an RA,
> it may take one extra round of RAs (at the moment 10 minutes).
> 
> In cases where a router spreads PIOs over multiple RAs, if those are 
> sent within 60 seconds and there is no packet loss, all addresses remain
> preferred. If the RAs are spread over a longer interval or if there is
> packet loss, one or more addresses may get deprecated.

If you just play with the "preferred lifetime", then the host will not
be able to communicate with the new owner of the prefix...


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492