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

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Mar 2019 13:35:02 +0100

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.

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

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.

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

  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

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

- 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.

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

  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)

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.

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.

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.
(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.

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.

To deal with accidentally deprecated addresses, the algorithm makes sure
that an address gets deprecated only if there is a new address with the same
label. The biggest risk here is that a ULA may accidentally cause a
global address to be deprecated.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Mar 2019 09:25:59 -0300

Hello, Philip,

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

> - 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 

Exactly.

>   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".

>   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.

>   CPEs are deployed. The draft doesn't describe what will happen in networks

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.

>   communication that uses the address.

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

>   with the problem at hand: flash renumbering situations.

Not sure what you mean.

>   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.

> the label values (based on the policy table in RFC 6724 "Default Address

What do you mean by "label"?

>   reduce the lifetime to 60 seconds.

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

> 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.

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

> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Mar 2019 15:31:21 +0100

>existing prefix. And trigger actions after some locally-defined value "n".

I'm not sure that will work. If you set 'n' high to be safe, then it will
take long time before the hosts takes action. If you set 'n' low, then you
still have a risk that a particular network exceeds this value.

>that the protocol has, within the acceptable boundaries.

I think 'playing' with knobs should be left to operators. If we change 
default values of timers, then effectively we are changing the protocol.

>protocol level to save battery life.

I think we should design protocols such that the use of periodic multicasts is
minimized. A node receives these multicasts even if it is otherwise idle.

Making these multicasts more frequent is a step in the wrong direction.

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

I don't think that's true for two reasons:
- If the ISP re-assigns the prefix within the valid-lifetime of the
  IA_PD prefix option, then the ISP is violating the DHCPv6 RFC.
- The source address selection algorithm avoids deprecated addresses.
  So the only way this can lead to trouble is if the a new node would
  use the exact same address. With SLAAC that basically cannot happen.

>>   with the problem at hand: flash renumbering situations.

In my opinion there is no need to actually remove old addresses to deal
with flash renumbering. It is sufficient to make them deprecated.

>What do you mean by "label"?

See Section 2.1 in RFC 6724 (the 'Policy Table')

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

It is not clear how to me could get the same effect using counters. Maybe
you can give an example algorithm.

>be lost, you will not get any.

Yes, the algorithm will perform worse in the context of packet loss.

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

You are right. I have an idea how to deal with this issue.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Mar 2019 12:14:24 -0300

> still have a risk that a particular network exceeds this value.

If you have another (working) address, then that's safe.

> default values of timers, then effectively we are changing the protocol.

If one were to change the defaults, one would be changing the spec, but
not the protocol.

That said, even if one wasn't changing the defaults but rather
suggesting tweaking of the timers, advice is warranted: you cannot
expect the operator to figure out all the relevant details....

> minimized. A node receives these multicasts even if it is otherwise idle.

But, ironically, these multicast messages are easier to policy (e.g. at
an AP) than the unicast messages.

>   IA_PD prefix option, then the ISP is violating the DHCPv6 RFC.

You may be right in "the ISP is violating the dhcpv6 rfc"... but this
doesn't make  what I describe an inexistent scenario.

>   use the exact same address. With SLAAC that basically cannot happen.

That's not correct. Normally, when a PIO has A=1, it normally has L=1.
Therefore, that prefix will be considered on-link, and any packets meant
for it will be sent on the local link, as opposed to forwarded to the
local router...

> you can give an example algorithm.

Yep:

1) c=0
2) Whenever you receive a PIO from the same router that does not include
the currently-configured prefix: c++;
3) if c >= N1 -> address deprecated
4) If c >= N2  (where N2>N1) -> address removed.

> You are right. I have an idea how to deal with this issue.

I'm listening ;-)

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Mar 2019 21:13:04 +0100

>If you have another (working) address, then that's safe.

I think my very first proposal was effectively n=1:
after receiving an RA, deprecate all addresses from the same router
not covered by PIOs in the RA.

If I remember correctly, you didn't like it.

For higher values of n, it will take longer to deprecate addresses, which
may lead to shorter RA intervals, which has it's own problems.

>expect the operator to figure out all the relevant details....

But increasing multicast rates to deal with a rather obscure problem doesn't
strike me as a good trade-off.

>doesn't make  what I describe an inexistent scenario.

I don't think we should introduce risky code on hosts to deal with 
broken DHCPv6 server implementations. 

And even then, the problem seems mostly theoretical.

>for it will be sent on the local link, as opposed to forwarded to the

That's a separate issue. Deleting an address will immediately disrupt
any flows that use that address.

Deleting a prefix from the list of onlink prefixes is more complex.
If the router still knows about the prefix, then there is no issue.
The router is supposed to forward the packet to the destination and
send a redirect.

If the router lost knowledge of the prefix and two hosts are communicating
locally then marking the prefix as offlink may disrupt that communication.

So there is no obvious way to deal with DHCPv6 servers that violate the
specs.

>4) If c >= N2  (where N2>N1) -> address removed.

So for high values of N1, communication will be disrupted for a long time.
For values of N1 less than the number of RAs that a router uses, prefixes
will periodically marked as deprecated.

If the router also exceeds N2, then addresses will periodically be removed.

>> You are right. I have an idea how to deal with this issue.

My current idea is that is is safe mark an address as deprecated if no
PIO that covers the address was seen for the 'Router Lifetime' field 
in the RA. Unless the field is zero, then do nothing. This should make
sure that eventually, stale addresses are marked deprecated. An obvious
edge case is PIOs advertised only by a router that is not a default router.

However for the case at hand, it is worth looking at deprecating an
address much quicker. So my proposal is to deprecate an address on a much
shorter time scale if the PIO is advertised by only one router and if that
router sends all PIOs in one RA.

Multiple routers advertising a single PIO is easy to detect. Detecting that
a single router puts all PIO in a single RA is harder. My currently
idea is to use a counter that counts how often a single RA covers all PIOs.
For low values of the counter, an PIO that was left out is evidence that the
router puts PIO in multiple RAs. If the counter is high enough (say above 10)
then assume that a missing PIO is stale and deprecate the address.

There are some corner cases, but they should be rare, and the effect 
relatively benign.