Subject: [v6ops] Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Feb 2019 20:48:11 -0300

Folks,

We have posted a revision of our I-D, which expands a lot on the problem
and possible solutions, based on the email discussion we had on this list.

The revised I-D is available at:
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt

Comments will be very welcome.

Thanks!
Fernando & Jan

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-slaac-renum-01.txt
Date: Mon, 18 Feb 2019 15:45:21 -0800
From: [email-masked]
To: Fernando Gont <[email-masked]>, Jan Zorz <[email-masked]>

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

Name:		draft-gont-6man-slaac-renum
Revision:	01
Title:		Reaction of Stateless Address Autoconfiguration (SLAAC) to
Renumbering Events
Document date:	2019-02-18
Group:		Individual Submission
Pages:		22
URL:
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
Diff:
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-01

Abstract:
   In scenarios where network configuration information related to IPv6
   prefixes becomes invalid without any explicit signaling of that
   condition (such as when a CPE crashes and reboots without knowledge
   of the previously-employed prefixes), nodes on the local network will
   continue using stale prefixes for an unacceptably long period of
   time, thus resulting in connectivity problems.  This document
   analyzes these problem scenarios, and proposes workarounds to improve
   network robustness.  This document updates RFC4861 and RFC4862 to
   allow for a more robust reaction to network configuration changes.

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: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Feb 2019 10:18:14 +0900

As just said in another list in Spanish, the reference to GERMAN-DP is wrong, in the sense that is not a law or anything similar. German folks can confirm. At least that has been said a few weeks ago by Germans in another list ...

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Fernando Gont <[email-masked]>
Fecha: martes, 19 de febrero de 2019, 8:49
Para: "[email-masked]" <[email-masked]>
CC: IPv6 Operations <[email-masked]>
Asunto: Revision of the SLAAC/renum I-D (Fwd: New Version Notification for draft-gont-6man-slaac-renum-01.txt)

    Folks,

    
    
    Thanks!
    Fernando & Jan

    
    -------- Forwarded Message --------
    Subject: New Version Notification for draft-gont-6man-slaac-renum-01.txt
    Date: Mon, 18 Feb 2019 15:45:21 -0800
    From: [email-masked]
    To: Fernando Gont <[email-masked]>, Jan Zorz <[email-masked]>

    
    Abstract:

    
    
    The IETF Secretariat

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 20 Feb 2019 20:08:59 +1100

Hi Fernando,

> and possible solutions, based on the email discussion we had on this list.

A few comments:
- (sorry if I missed another thread on it - I'm catching up with
emails slowly): any reason for setting Valid Lifetime to 0 as well? It
looks to me that just deprecating the prefix would be enough..What
would be a benefit of completely removing an address already
deprecated?

- "After normal processing of Router Advertisement messages, Router
   Advertisements that contain at least one PIO MUST be processed as
   follows" - I'd suggest you make it explicit that PIOs must of of
the global scope. I did see CPEs including PIOs for fe80::/64 (and
AFAIR such behavior is not explicitly prohibited);

- the draft makes an assumption that "while network
      configuration information might be split into multiple RAs, PIOs
      will be spread among *at most* two RAs." - I'm not sure where
this assumption is coming from - is there any requirements for routers
saying it MUST/SHOULD do this? Adding any references to support such
assumption would be very helpful.

-  as I've mentioned earlier, it would be nice not to break other
scenarios while fixing DHCP-PD case. So what do you think about
modifying the algorithm so the addresses are deprecated only if *all*
routers the PIO has been received from stopped advertising it? Again,
my point is that while proposed behavior *does* help in a single-homed
residential case, it would be nice to keep in mind other cases and
avoid breaking them;

- the proposed changes say that PIOs MUST be processed as
follows....and relies on hosts tracking prefix <> nexthop as per
RFC8028...However RFC8028 (and RFC8504) uses  'SHOULD' ...so it seems
to be inconsistency here..If a host does not implement RFC8029, all
those MUST in the draft do not make much sense.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Feb 2019 06:49:33 -0300

Hello, Jen,

> would be a benefit of completely removing an address already

You mean in the host-side algorithm specified in Section 5.1.3? The
benefit would be garbage collection. -- another alternative would be,
instead removing the addresses, reduce the current Valid Lifetime -- say
to 10 minutes or whatever, so that the stale addresses do not stay
around forever. (if SLAAC was using sensible timer values, you wouldn't
need these... but you probably don't want stale addresses to stay around
for one months, as per the default "Valid Lifetime").

> AFAIR such behavior is not explicitly prohibited);

Item b) in Section 5.5.3 says:
    b)  If the prefix is the link-local prefix, silently ignore the
      Prefix Information option.

albeit not with normative language. But, anyway, if you've seen CPEs
send them, we better make this explicit!

> assumption would be very helpful.

I've never seen a scenario where information actually needs to be split
among multiple RAs. I have a hard time thinking of filling up a whole RA.

So the logic here was "Ok, all information is normally transmitted in a
single RA. But for the sake of (rather insane :-) ) flexibility, let's
assume that you send all the info is sent in as many RAs as you want,
with PIOs split among two RAs". I believe it's quite unlikely that PIO
information needs to be split into more than two RAs -- you'd need ~
(2*1280)/16 worth of prefixes)

> residential case, it would be nice to keep in mind other cases and

Yes, we should update the algorithm as you suggest.

Thinking our loud: best thing would probably be that, in the case the
prefix has been advertised by multiple routers, it is dis-associated
with the prefix that ceased advertising it. Otherwise, you might end up
sending packets sourced from that prefix to the next-hop router that has
ceased advertising it.  That is, if multiple routers were advertising a
prefix, and one has ceased advertising it, you want packets sourced from
that prefix to use a next-hop router that keeps advertising the prefix.

> those MUST in the draft do not make much sense.

That's a good point. I wonder if we should change the "MUST" to
"SHOULD", or whether we should stick to "MUST" with a rationale of "a
host that implements this standard MUST implement RFC8028 and MUST
process PIOs as follows..."

Thoughts?

Thinking out loud: I wonder if support for RFC8028 should have actually
been a MUST in RFC8504 -- reality is that in many multiprefix/multihomed
scenarios, if you don't do RFC8504 it's quite likely your packets will
be dropped -- i.e., an interoperability issue that would have warranted
a "MUST" for 8028.

Thanks!

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

---

From: Jen Linkova <[email-masked]>
Date: Thu, 21 Feb 2019 15:25:08 +1100

> for one months, as per the default "Valid Lifetime").

Do we have any data on how much pain this is causing? I  mean those
addresses are not staying forever,
just one month  in the worst case scenario. So they will disappear eventually.
On the other hand if I have an tcp session opened - why do we need to
kill it in 10 mins?
I agree that default times should be more reasonable, so I agree that
defaults should be changed and depend on the
AdvDefaultLifetime.

Speaking of exact numbers - how did you come up with values? Just
curious if the is any background for choosing them...

> send them, we better make this explicit!

I must be blind, I can not see that sentence in the draft ;(

> among multiple RAs. I have a hard time thinking of filling up a whole RA.

Let's wait for the new shiny world of mPVD to come...

> that prefix to use a next-hop router that keeps advertising the prefix.

So...it looks to me that the only change should be:
- if a host supports prefix <> advertizing router mapping and supports
the Rule 5.5:
   --  deassociate prefix - next-hop if the given router stops advertizing it;
   -- deprecate the prefix if there is no routers advertizing it;

Then the default address selection takes care of selecting the right
source address.
No need for complex algorithm described in the draft (and potential
implementation bugs).

If the host does not support Rule 5.5 + prefix<>next-hop mapping, this
draft (PIO processing part) would not work for them anyway.

Combined with reduced default timers it should help significantly (at
least for hosts and routers implementing this..)

> process PIOs as follows..."

See above. All we need to do in terms of PIO processing by a host is
to say 'host SHOULD refresh prefix-next-hop mapping while processing
RAs' (which would mean 'remove all mappings for that next-hop if they
are not in that RA you are processing') and 'host SHOULD deprecate
addresses with no next-hops'.

Even if you say 'MUST' here (and explicitly state 'MUST implement
RFC8028') it would only mean 'hosts MUST support a standard which says
they SHOULD do smth' => effectively that requirement means 'SHOULD'.

> be dropped -- i.e., an interoperability issue that would have warranted

See above. Then 8028 should have said 'MUST support rule 5.5
-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Feb 2019 04:21:56 -0300

On 21/2/19 01:25, Jen Linkova wrote:
> Do we have any data on how much pain this is causing? 

Not that I know of. Problem is: you still have v4, and if v6 fails, HE
makes it work over v4.

> I  mean those

Many stacks limit the number of prefixes they will use for address
configuration. Some limit such number to 16. That means that if you
experience crash-and-reboot 16 during the same month, your host may fail
to configure addresses for the fresh prefix.

> On the other hand if I have an tcp session opened - why do we need to

Not sure what you mean....

> curious if the is any background for choosing them...

The only one you really choose is MaxRtrAdvInterval. The rest are set as
a function of it.

For the most part, I picked MaxRtrAdvInterval such that there were more
ferquent RAs, but in the worst-case scenario, never more than 1 every
1.5-2 minutes. (trade-off beween responsiveness and not bothering the
network a lot, unnecessarily)

> I must be blind, I can not see that sentence in the draft ;(

Sorry, that section is not in the draft, but in rfc4862.

Same text appears in Section 6.3.4 of RFC4861.

> Let's wait for the new shiny world of mPVD to come...

Same router, PIOs split over more than three RAs?

>    -- deprecate the prefix if there is no routers advertizing it;

In response to what?

I was thinking this would be an action by algorithm from 5.1.3 once the
prefix has been un-preferred.

If not, what would be the event that would trigger such dis-association?

> least for hosts and routers implementing this..)

With appropriate timers + modification to SAS you get the problem
solved. However, if you have multiple prefixes, and the source address
will flap among them. -- I'd try, to the extent that is possible, to
avoid that....

> addresses with no next-hops'.

This enforces a more strict requirement on RAs. i.e., PIOs can only be
sent in one RA. I'm not saying that's necessarily bad, but the reasons
for the algorithm in Section 5.1.3 is to allow PIOs to be split in at
most two RAs.

> they SHOULD do smth' => effectively that requirement means 'SHOULD'.

Agreed.