Subject: 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: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Feb 2019 10:40:30 +0100

On 19/02/2019 02:18, JORDI PALET MARTINEZ wrote:
> 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 ...

Hi,

Interesting. Can any German speaking person on this list confirm?

I also heard something like this, but can't confirm.

Cheers, Jan

> 
> 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,
> 
> 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.
> 
> 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: 
Status:
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-01 Htmlized: 
> 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
> 
> 
> 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.
> 
> 
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Feb 2019 10:50:22 +0100

> I also heard something like this, but can't confirm.

I was wondering what does this reference in the draft mean:

"Einfuhrung von IPv6 Hinweise fur Provider im Privatkundengeschaft und 
Herstellere"

Alex

>> Document date:    2019-02-18 Group:        Individual Submission 
>> Pages:        22 URL: 
>> https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/ Htmlized:
>> Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-01
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Feb 2019 11:08:20 +0100 (CET)

> "Einfuhrung von IPv6 Hinweise fur Provider im Privatkundengeschaft und 

http://www.bfdi.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv6.pdf?__blob=publicationFile

"Um das zielgerichtete Verfolgen von Nutzeraktivitäten (Tracking) zu 
vermeiden, müssen Adresspräfixe grundsätzlich dynamisch an Endkunden 
vergeben werden. Auch eine Vergabe mehrerer statischer und dynamischer 
Adresspräfixe kann datenschutzfreundlich sein, wenn Betriebssystem und 
Anwendungen den Nutzer dabei unterstützen, Adressen gezielt nach der 
erforderlichen Lebensdauer auszuwählen."

This seems to say that default should be dynamically changing prefix.

"Entscheidet sich ein Provider für die Vergabe statischer Präfixe an 
Endkunden, müssen diese Präfixe auf Wunsch des Kunden gewechselt werden 
können. Hierzu müssen dem Kunden einfache Bedienmöglichkeiten am Router
oder am Endgerät zur Verfügung gestellt werden."

This says provider must have functionality so to change prefixes at 
customer request if they provide static prefixes.

I don't know the legal standing of this document. Anyone else know?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Enno Rey <[email-masked]>
Date: Tue, 19 Feb 2019 11:24:27 +0100

Hi,

On Tue, Feb 19, 2019 at 11:08:20AM +0100, Mikael Abrahamsson wrote:
> > Le 19/02/2019 ?? 10:40, Jan Zorz - Go6 a ??crit??:

yes, I can confirm this (lack of legal authority or mandate).
Assuming the above reference to another list could point to a thing I sent I could copy+paste that if needed (avoiding cross-posting for the moment).

> 
> "Entscheidet sich ein Provider f??r die Vergabe statischer Pr??fixe an 
> Endkunden, m??ssen diese Pr??fixe auf Wunsch des Kunden gewechselt werden 
> k??nnen. Hierzu m??ssen dem Kunden einfache Bedienm??glichkeiten am Router
> oder am Endger??t zur Verf??gung gestellt werden."
> 

I think I can provide a statement on this (not being a lawyer though, but somewhat familiar with the space). From a legal perspective that document doesn't have a binding character. Reasons include:
- the "Datenschutzbeauftragte" (data protection officers) don't have (much) legal authority by themselves, but mostly a consulting (e.g. to the parliament) role and some "supervisory" tasks.
- the committee which issued the document ("Konferenz der Datenschutzbeauftragten") by itself isn't a legal or even (afaik) an institutional body. 
- the title explicitly says "Hinweise" => here to be best translated (I'd say) as "advise".

tl;dr: that document doesn't have legally binding character.

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Florian Grunow, Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Feb 2019 12:46:05 +0100

On 19/02/2019 11:24, Enno Rey wrote:
>>>>> 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 ...
>>>> 
>>>> Hi,
>>>> 
> Assuming the above reference to another list could point to a thing I
> sent I could copy+paste that if needed (avoiding cross-posting for
> the moment).

Thank you, Enno, appreciated.

> I think I can provide a statement on this (not being a lawyer though,
> but somewhat familiar with the space). From a legal perspective that
> document doesn't have a binding character. Reasons include: - the
> "Datenschutzbeauftragte" (data protection officers) don't have (much)
> legal authority by themselves, but mostly a consulting (e.g. to the
> parliament) role and some "supervisory" tasks. - the committee which
> issued the document ("Konferenz der Datenschutzbeauftragten") by
> itself isn't a legal or even (afaik) an institutional body. - the
> title explicitly says "Hinweise" => here to be best translated (I'd
> say) as "advise".
> 

If that's the case, then a reference should be removed from the I-D.

<joke>
Or even better - we could say that despite all the rumors and FUD - even 
in Germany that's not legally binding and therefore operators can do 
whatever they want with their architecture :)
</joke>

Cheers, Jan

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 19 Feb 2019 14:25:43 +0000

> Or even better - we could say that despite all the rumors and FUD - even in
> Germany that's not legally binding and therefore operators can do whatever
> they want with their architecture :) </joke>

<joke>Since all IETF RFCs (including BCPs) and RIPE advice are also not legally binding, maybe we should remove all those references, too?</joke>

What makes RIPE and IETF advice "better" than others' advice?
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 19 Feb 2019 15:14:10 +0000

On the off-chance that people in IETF might want to base recommendations on real research and statistics, here is an excellent paper regarding frequency of IP address changes. 

https://www.caida.org/publications/papers/2016/reasons_dynamic_addresses_change/ 

What we don't (publicly) have are numbers of customers who complain about the impact of IP address changes. But the number of ISPs who are saying this presents a problem for them (i.e., drives up help desk calls, causes customers to switch to other ISPs, etc.) might be an indication ...

Another data point is this:
https://www.vicimediainc.com/often-ip-addresses-change/

The claims they make as to frequency and why ISPs don't change don't seem to have any factual basis, so that's not what I consider relevant. What I consider relevant is they are a (non-ISP, non-ISP-affiliated) advertising company who claims to make money from selling ads based on mapping IP addresses to physical location. They don't claim to get their data from ISPs. 

Personally, I have no interest in enabling companies like this. I'm also not aware of any actual mass market problem related to IP address changes. Mass market products aren't about meeting the needs of 100% of people at any cost. Mass market broadband products are about meeting the needs of the mass market.

While I don't see a mass market problem related to IP address changes, I do support Fernando's goal with this draft. I think making edge networks and hosts more resilient to network changes is helpful. I think it might be good if we had more comments suggesting improvements to Fernando's proposals, rather than pretending we could obviate any need for these proposals by insisting ISPs provide static IP addresses/prefixes and that people be able to take their IP address(es) with them when they move.
Barbara

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 20 Feb 2019 12:02:40 +0400

> What makes RIPE and IETF advice "better" than others' advice?

Consensus, hopefully :)

Cheers, Jan

---

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.