Subject: SLAAC renum -- revised algorithm (Fwd: New Version Notification for draft-gont-6man-slaac-renum-04.txt)

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Mar 2020 10:38:43 -0300

Folks (Philip/Michael in particular),

I took the chance of bein able to post document revs, and submitted a 
rev of our I-D. The revised draft is at: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-04

Other than minor editorial changes, I have added an alternative 
algorithm that allows hosts to infer that a prefix has become stale, 
that is meant to address Philip's and Michael's concerns (as expressed 
on this list).

The original algorithm (Algorithm #1) is now Section 4.5.1, while the 
new algorithm (Algorithm #2) is in Section 4.5.2.

As noted in the document, it will be up to the WG to decide whether to 
keep both algorithms (or pick one of them (I guess the new one)) if/once 
the wg decides to work on this document.

Thoughts?

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-slaac-renum-04.txt
Date: Wed, 11 Mar 2020 06:26:36 -0700
From: [email-masked]
To: Jan Zorz <[email-masked]>, Richard Patterson <[email-masked]>, 
Fernando Gont <[email-masked]>

A new version of I-D, draft-gont-6man-slaac-renum-04.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-slaac-renum
Revision:	04
Title:		Improving the Robustness of Stateless Address Autoconfiguration 
(SLAAC) to Flash Renumbering Events
Document date:	2020-03-11
Group:		Individual Submission
Pages:		23
URL: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-04
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-04

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.

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.

The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Mar 2020 14:12:26 +0100

>new algorithm (Algorithm #2) is in Section 4.5.2.

I think your new algorithm fails if a router sends two prefixes in two
RAs and one RA gets lost.

Note RFC 4861 says (Section 6.2.1):
MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

So if one RA gets lost, the next one may come only after 1800 seconds.

I forgot one issue, a router may send two RAs, one with a ULA, and one
with a routable prefix. If the routable prefix accidentally gets deprecated,
then the host loses connectivity.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 11:33:39 -0300

> So if one RA gets lost, the next one may come only after 1800 seconds.

Yes, this is noted in the I-D where we say LTA_IVALID_DEFAULT could be 
1800 seconds if we wanted to be more conservative.

I see a number of possible ways forward:

1) Keep "as is", since in order for this to happen, this woudl require:
   + that implementations use a non-defualt value for MaxRtrAdvInterval, 
*and*

   + that they spread PIOs among multiple RA messages, *and*

   + one of such messages with PIOs get lost

2) Increase LTA_INVALID_DEFAULT to 1800, as noted in the I-D. I wouldn't 
mind, although this comes at the expense of reduced responsiveness

3) Keep the current default timer, but not that an implementation may 
want to send a unicast RA to the router when expiration is imminent 
(this is probably in RFC4861, already)

Thoughts?

> then the host loses connectivity.

This is a good point, and we will fix it (thanks!). Essentially, this 
behavior should be triggered by "RAs that contain one PIO that 
advertises a non-ULA prefix".

Or, even better, ULA addresses should be deprecated by PIOs that carry 
other ULA prefixes (but not the currently used one), where global 
addresses should be deprecated by "RAs that carry PIOs that advertise 
global prefixes, but not the currently used ones".

Thoughts?

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: Thu, 12 Mar 2020 15:42:03 +0100

>1800 seconds if we wanted to be more conservative.

Please write drafts that actually work when implemented. If you know that
the values in your draft can causes failures why put them in?

>   + that implementations use a non-defualt value for MaxRtrAdvInterval, 

That is specifically allowed

>   + that they spread PIOs among multiple RA messages, *and*

Also allowed

>   + one of such messages with PIOs get lost

It is safe to assume that every once in a while a RA gets losts.

>mind, although this comes at the expense of reduced responsiveness

If the interval is 1800, then LTA_INVALID_DEFAULT has to be 3600
to handle one lost packet. 

>(this is probably in RFC4861, already)

Sending unicast RAs is way more complex than my algorithm, so I don't see
the point.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 12:03:29 -0300

On 12/3/20 11:42, Philip Homburg wrote:
> Please write drafts that actually work when implemented. 

Please be constructive.

> If you know that

Any values that you put may cause trouble under given circumstances. For 
instance, you could be simply unlucky and have all multicasted RAs that 
are sent to be lots. There's *nothing* that warrants that that's not the 
case.

So, in engineering, we always operate on probability and statistics.

>>    + that they spread PIOs among multiple RA messages, *and*

There's a recommendation that you SHOULD send all information in the 
smallest possible number of packets. You're supposend to go against 
SHOULDs if you really know what you are doing.

> It is safe to assume that every once in a while a RA gets losts.

It is also allowed for an arbitrarily large number of packets to get lost.

[...]
> Sending unicast RAs is way more complex than my algorithm, so I don't see

Could you explain the complexity of sending a unicast RS?

I don't know how you consider the the measuring part of your algorithm 
any more simpler thatn firing a unicast RS.

Besides, your alggorithm does make assumptions about how information in 
RAs is spread, and also about packet loss. Why are you fine with those 
assumptions?

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Mar 2020 16:14:50 +0100

>> Please write drafts that actually work when implemented. 

You keep creating drafts that have issues and then when I point out
those issues there is constant in your draft that can be increased and
that makes the performance much worse.

I'm done with this. Good luck. I'll comment during the wg last call.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 12:35:47 -0300

> that makes the performance much worse.

You point out corner cases where things might go wrong. All protocols 
have that, starting from the fact that we normally employ best-effort 
transimission technologies, and hence there are no reliability warrants. 
And what I've mentioned is that even in such scenarios, one can be even 
more conservative if one wanted. -- For instance, I don't mind 
LTA_INVALID being 1800 sends, if that's the show stopper. Or even double 
that.

Performance does not get any worse. If anything, it takes longer to 
*garbage-collect* stale addresses. The high order bit is that you want 
new communication instances to work asap. And this draft achieves that.

Your input is indeed heard. We did add a whole section in response to 
your feedback.

Thanks,