Subject: Re: I-D Action: draft-gont-6man-slaac-renum-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Mar 2020 16:22:39 +1300

I'm all for advancing this draft ASAP (and its v6ops companion).

I suggest that it should also formally update RFC8504 (node requirements), which mandates RFC4861/4862.

Regards
   Brian

On 17-Feb-20 16:45, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
>         Authors         : Fernando Gont
>                           Jan Zorz
>                           Richard Patterson
> 	Filename        : draft-gont-6man-slaac-renum-02.txt
> 	Pages           : 18
> 	Date            : 2020-02-16
> 
> Abstract:
>    In renumbering scenarios where an IPv6 prefix suddenly becomes
>    invalid, hosts on the local network will continue using stale
>    prefixes for an unacceptably long period of time, thus resulting in
>    connectivity problems.  This document improves the reaction of IPv6
>    Stateless Address Autoconfiguration to such renumbering scenarios.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-02
> https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Erik Kline <[email-masked]>
Date: Wed, 4 Mar 2020 20:29:29 -0800

Is the 4.4 stuff really what we want?  I kinda think there might be other
options.

For example, something like an ND Option that routers can include in their
NA (they already set the IsRouter flag).  If this option represented a kind
of "generation number", then hosts could notice when it changed during
regular NUD (they don't need to wait for an RA, which they might have
already missed for one reason or another) and start a countdown timer to
send a unicast RS to check for changes.

On Wed, Mar 4, 2020 at 7:22 PM Brian E Carpenter <
[email-masked]> wrote:

> >         Title           : Improving the Robustness of Stateless Address
> Autoconfiguration (SLAAC) to Flash Renumbering Events
> >         Authors         : Fernando Gont
> >                           Jan Zorz
> >                           Richard Patterson
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Mar 2020 09:03:57 +0100

>    Is the 4.4 stuff really what we want?  I kinda think there might
>    be other options.  For example, something like an ND Option that
>    routers can include in their NA (they already set the IsRouter
>    flag).  If this option represented a kind of "generation number",
>    then hosts could notice when it changed during regular NUD (they
>    don't need to wait for an RA, which they might have already
>    missed for one reason or another) and start a countdown timer
>    to send a unicast RS to check for changes.

I implemented something similar to the algorithm in Section 4.4, but
extended that it also detects link changes. For example, if you
have a VM on laptop then the VM doesn't see a link down event when the
laptop moves to a new network.

The advantage of Section 4.4 is that it works today. No need to change
any routers.

Some people also expressed that they don't like having to maintain
persistent state in a router (though I  guess a random number would work
as well for the option you propose).

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Mar 2020 01:51:20 -0300

Hello, Erik,

On 5/3/20 01:29, Erik Kline wrote:
> Is the 4.4 stuff really what we want?  I kinda think there might be 
> other options.

The stuff in Section 4.4 follows the principle of "do smarts at hosts", 
in this case, *without explicit signalling* from routers.  This allows 
hosts to recover from stale information even with current/legacy routers.

> For example, something like an ND Option that routers can include in 
> their NA (they already set the IsRouter flag).

The stuff in Section 4.4 doesn't exclude options like this. In fact, 
it's complementary.

> If this option 
> represented a kind of "generation number", then hosts could notice when 
> it changed during regular NUD (they don't need to wait for an RA, which 
> they might have already missed for one reason or another) and start a 
> countdown timer to send a unicast RS to check for changes.

Indeed that might be doable. However, Section 4.4 is stuff that if a 
host implements, it can already benefit from without having to wait for 
routers to be updated.

Thanks!

Cheers,
-- 
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: Fri, 06 Mar 2020 10:23:24 +0100

>The advantage of Section 4.4 is that it works today. No need to change

I forgot to mention. The current algorithm in Section 4.4 fails if a 
router sends multiple RAs with a different prefix in each RA.
As far as I know, that behavior is allowed.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Mar 2020 16:24:55 -0300

> As far as I know, that behavior is allowed.

Nope. The algorithm can accommodate such behaviour by setting 
LTA_RAS_UNPREFER and LTA_RAS_INVALID appropriately.

For exampple, with the currently specified default settings, PIOs can be 
split into two RAs, without the prefixes becoming un-preferred. The 
values of those configuration variables could be increased as deemed 
necessary -- albeit at the expense of sacrificing responsiveness.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Mar 2020 12:32:23 +0100

>necessary -- albeit at the expense of sacrificing responsiveness.

This doesn't work. LTA_RAS_UNPREFER and LTA_RAS_INVALID are fixed in the
host implementation. So the host has to guess what the router is going
to do. 

We have no limit on what the router can do so any guess is wrong by
definition.

At the same time, responsiveness goes completely down the drain for higher
values. Rendering this draft mostly irrelevant if we set those values to
something 'safe'.

In short, I consider this a bad algorithm. I have said so many times in the
past, so I'm not quite sure why the authors want to continue pushing this.

---

From: [email-masked]
Date: Mon, 9 Mar 2020 12:53:05 +0100

Philip,

> past, so I'm not quite sure why the authors want to continue pushing this.

Yes, this certainly has the potential of decreasing robustness.
You have just about 12 hours until the submission deadline for a better proposal!

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Mar 2020 13:34:42 +0100

> You have just about 12 hours until the submission deadline for a

Here is a sketch of how the algorithm could be improved.

My assuption is that the affected home routers send all information in one
RA, but some other routers split information over an unknown number of
RAs. The algorithm rapidly expires information in the first case, and 
takes longer in the second case.

The first part is to detect if all information is sent in one RA. For
the first n (currently 10) RAs received from a router, check if those RAs
advertise the same list of prefixes. If this is not the case then set a
SPLIT_RA to record this fact.

When an RA arrives and there are prefixes that were previously advertised
by the current router and are not in the current RA then
- if SPLIT_RA is set, deprecate the old prefixes if they were last seen at
  least as long as the router lifetime (if the router is not a default
  router then do nothing).
- if SPLIT_RA is not set and the prefix was last seen more than a short
  while ago (currently one minute) then set the preferred lifetime to
  a short timeout (current also one minute).

I prefer explicit timeouts over counting packets.

So far, I have been conservative when it comes to invalidating prefixes
(I just mark them deprecated). Setting the valid lifetime to the router
lifetime should be fine. Though I think it is better if higher level
protocols detect broken connections and take action.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Mar 2020 13:48:34 -0300

> host implementation. So the host has to guess what the router is going

That is correct. I'd say, though, that the guess is based on empirical 
evidence. I haven't seen any implementation that intentionally splis the 
contents of RAs among multiple RAs.

In fact, it would seem to me that from the pov of protocol development, 
that might have an unnecessary negative effect on he network.

> We have no limit on what the router can do so any guess is wrong by

That is, from a theoretical point, correct. From an engineering point of 
view, though, it's debatable (I don't think your e.g. house is prepared 
to be hit by a meteor... but it could).

That said, more on this in another email.

> values. Rendering this draft mostly irrelevant if we set those values to

There are two things going on here:
1) Unpreferring an address
2) Invalidating an address

#1 is of utmost importance. But if the algorithm fails, you just 
unpreferred the address. -- Yes, there might be undesirable oscillations 
of the preferred address,but nothing has brokon down.

#2 is what might cause breakage. In such case you can increase 
LTA_RAS_INVALID, at the expense of maintaining potentially-invalid 
addresses for longer.

> past, so I'm not quite sure why the authors want to continue pushing this.

This is the first time I see you objecting to the algorithm, but my 
memory might be failing. Could you provide a ref to any previous post, 
such that if there were other things that you raised, we can try to 
address them? (and also to figure out what happened with my mail system).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Mar 2020 14:47:58 -0300

Hello, Philip.

Thanks for the input! In-line---

On 9/3/20 09:34, Philip Homburg wrote:
> advertise the same list of prefixes. 

Questions (not objections):

* Is there a rationale for "10"? Or is it mostly "routers couldn't 
reasonably send SLAAC config split into that many RAs"?

* Are these "measurements" something you'd continually perform, or 
something you'd only do on e.g. a link-up event?

* Would a connectivity glitch reset these measurements?

* WHile measuring, do you assume "split RA" or "non-split RA"?

> If this is not the case then set a

When using "deprecate", do you mean:
1) unprefer, or,
2( invalidate

If #1, what would trigger invalidation? A receipt of a similar RA?

>    a short timeout (current also one minute).

Since this bullet implies that RAs are not split, what would be the 
rationale for "setting the preferred lifetime to a short timeout"?

And, as before: if this simply unprefers the address, what would 
actually invalidate it? Receipt of a similar RA?

> I prefer explicit timeouts over counting packets.

FWIW, counters are simpler. That's why we used them here.

> protocols detect broken connections and take action.

Part of invalidating prefixes is to remove associated routes. If you 
don't, you don't get to talk to new "owners" of the stale prefix.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Mar 2020 17:47:09 -0300

> We have no limit on what the router can do so any guess is wrong by

Section 6.2.3 of RFC4861 says:
    A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options.

So while a router might opt to omit information (I know of no 
implementation that does this), that doesn't translate into spreading 
information among multiple RAs. The second paragraph seems to convey the 
meaning of "put as much information into the packet as possible. If the 
packet becomes larger than the MTU, convey the information via multiple 
RAs".

In any case, we have added a clarification to our document.

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Mar 2020 11:34:49 +0100

>contents of RAs among multiple RAs.

I'm very much against a standard where one part of the standard imposes
no limits, and then another part implictly assumes that there is infact 
a limit.

If your code needs a limit on the number of RAs uses by a router to 
announces all prefixes, then this draft should explictly set such a limit.

>to be hit by a meteor... but it could).

We are writing a single set of standards. This has nothing to do with 
behavior outside the standards we set.

>of the preferred address,but nothing has brokon down.

If the host knows a stale address then deprecating a good address may cause
the host to use the stale address which does break things.

>LTA_RAS_INVALID, at the expense of maintaining potentially-invalid 

You cannot expect a random user of a phone to increase LTA_RAS_INVALID,
the draft doesn't even say that LTA_RAS_INVALID needs be configurable, so it
may be hardcoded in the OS.

>address them? (and also to figure out what happened with my mail system).

I found a message where you respond to me raising the issue:
https://mailarchive.ietf.org/arch/msg/ipv6/_oe8GMNO70uxaBYWcJQgtX869MY/

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Mar 2020 12:01:19 +0100

>reasonably send SLAAC config split into that many RAs"?

The 10 is not supposed to be optimal. Just something that works. 

The rational is that if a router splits the prefixes over 2 RAs, then the
chance that you only get 1 of them 10 times in a row is extremely low.

If, for example, you would set the value to 2, then just one packet need to 
be lost for a misclassification to happen.

>something you'd only do on e.g. a link-up event?

After a link up event be also when a prefix is deprecated.

>* Would a connectivity glitch reset these measurements?

A link attachment event should reset them. Just a temporary loss of 
connection should have no effect.

>* WHile measuring, do you assume "split RA" or "non-split RA"?

Split RA. Split RA is that safe version (just let the prefix expire), 
non-split RA needs to be established.

>When using "deprecate", do you mean:

Unprefer.

>If #1, what would trigger invalidation? A receipt of a similar RA?

I have no code for immediate invalidation. RFC 4862 is very conservative
in marking an address invalid (the 2 hour minimum).

It is a significant departure from RFC 4862 to invalidate addresses quickly.
If that is the behavior we want, then changing from unprefer to invalidate
would do the right thing.

>rationale for "setting the preferred lifetime to a short timeout"?

This is a bit of overly clever trickery that handles the case if a router
switches from sending one RA to multiple RAs and sends them close together.

>actually invalidate it? Receipt of a similar RA?

The current code just lets the address become invalid when the valid lifetime
expires. In my opinion, the important part is to pick a working address for
outgoing connections (i.e. making sure the right address is preferred).
Breaking exiting connections should be left to application protocols.

Though if there is consensus that existing connections should be terminated 
by the IPv6 layer, then the code can be changed to invalid addresses instead
unpreferring them.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Mar 2020 00:20:45 -0300

> no limits, and then another part implictly assumes that there is infact

I'm not necessarily arguing against this, but this happens all over the 
place. e.g., there is no limit regarding how many addresses a host can 
configure. But in practice, there are. That said, I see your point, and 
we'll work

> announces all prefixes, then this draft should explictly set such a limit.

At least the deprecation part, is an optimization.

[....]
> the host to use the stale address which does break things.

Could you please elaborate?

> may be hardcoded in the OS.

What I was meaning is that we, as a WG, can set such variables to 
whatever value we think fits.

I realize that the draft does not say those should be configurable. We 
will make this clear in the next rev.

(The bottom-line is that I'm debating the document and of course open to 
changes and improvements)

> https://mailarchive.ietf.org/arch/msg/ipv6/_oe8GMNO70uxaBYWcJQgtX869MY/

To be honest, I didn't remember such exchange, but have re-read it. -- I 
will come back with more on this in a later email...

Thanks!

Cheers,