Subject: Flash renumbering

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 15 Sep 2020 20:29:37 +0000

Hi all,
I did think on the problem today and come to the conclusion that the problem has very small corner case. We could say that it does not exist. It definitely does not need urgent solution.
Probably, statistics that 37% of Carriers do use dynamic IPv6 addresses for FBB is right.
90+% of subscribers (from this 37%) would have just 1 box in the apartment. CPE reload will disconnect hosts on L2 (WiFi, Ethernet). Host could not be sure that new connection is to the same link. Host has no choice except to discard all information and start link initialization again (including learning PIO). No primary problem described in “draft-gont-v6ops-slaac-renum-02”.
A few percentages of subscribers (from 37%) could have big apartment or would like to have WiFi 5Ghz in every room – they could have CPEs chain. Root CPE reload would not be visible for host connected to subtended CPE. But subtended CPE has no problem to deprecate old prefix (set preferred lifetime 0) and announce new one. No standardization problem, but could be the problem of particular CPE vendor.
Subtended CPE in IPv4 world were put in “bridge mode” to avoid additional NAT, that does not make sense in IPv6 world. Every IPv6 CPE should be in routed mode. It is not the problem when minimal delegated prefix is /56 by RIPE recommendations (there is push to /48). We have to teach carriers how properly developed complicated solutions for residential broadband. No standardization problem again.
Other cases discussed in “draft-gont-v6ops-slaac-renum-02” are for the situation when admin deleted old PIO without any signaling to host (no preferred lifetime = 0), then introduced new PIO. It does not matter: manual or automated through OSS or automated by 802.1x port. It is definitely admin mistake – he treat IPv6 as IPv4. Education is needed again. Vendor could help here sending preferred lifetime = 0 in such situations (for any admin attempt to delete PIO from link). No standard problem again.
I am not worried too much for the case when Multicast announcement about preferred lifetime 0 could be lost, because if multicast lost then new PIO would not be delivered too – host would be left without connectivity at all. I am not the big fan of multicast too, but it is different case.

I do accept 1 low probable corner cases as really persisting:
Some advanced subscriber could really have separate Router and Switch in the apartment (or small business branch). Then Switch port would not go through initialization at the same time as router would do reload. Then we would witness the problem discussed in “draft-gont-v6ops-slaac-renum-02”. Only host reload could help here.
Probability for that case is extremely low, because everybody likes integrated solution (no separate dumb switch). If we have WiFi AP then it is probably Enterprise site with static addresses anyway.

Robustness for abrupt renumbering is indeed not good – we need to rely on proper network admin behavior and/or vendor code development in the smart way. Hence, it make sense to improve robustness by plain announcement what is the complete package of information. I still see the reason to add “Complete” flag into RA. But it is not urgent now – there are plenty of workarounds for a few cases with small probability, except the least probable.
I would develop the draft.
I am strictly against tampering with times: it could not be fast for reasonable level of nodes interruption.

Ed/
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 10 сентября 2020 г. 20:45
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-6man-slaac-renum: Processing of PIO Lifetimes at Hosts

Eduard,

> You probably mean only long-term solution (RA improvement). No problem. I will.
> Because short term idea from Lorenzo should be probably added to the current draft of Fernando. 30min interruption for soccer live translation is definitely not acceptable solution.
> Please confirm, that I have understood you right.
> Potentially I could specify both.

When we adopted this work, we adopted the problem, and we would certainly encourage alternative solutions.
Perhaps we need to go back to requirements, and also see what's short-comings in implementations versus what's shortcomings in specifications.
To see if we can properly solve the larger robustness problems. If there is one.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2020 07:19:49 -0300

Eduard,

On 15/9/20 17:29, Vasilenko Eduard wrote:
> Hi all,
> I did think on the problem today and come to the conclusion that the 
> problem has very small corner case. We could say that it does not exist. 

Can you come up and fix my internet connection every now and then this 
problems happens at my own home?

It puzzles me to hear you say that the problem doesn't existing when 
v6ops agreed otherwise, and when I've experienced it myself recently.

(and there are multiple scenarios where it does happen, from the CPE 
case, to VMs being moved around. etc).

[...]
> 
> 90+% of subscribers (from this 37%) would have just 1 box in the 
> apartment.

Range extenders are pretty widespread over here. I do use them at 
relatives' houses, cause houses are made out of bricks (as opposed to 
wood) over here, so the wifi signal won't go thorough.

[...]
> A few percentages of subscribers (from 37%) could have big apartment or 
> would like to have WiFi 5Ghz in every room – they could have CPEs chain. 
> Root CPE reload would not be visible for host connected to subtended 
> CPE. But subtended CPE has no problem to deprecate old prefix (set 
> preferred lifetime 0) and announce new one. No standardization problem, 
> but could be the problem of particular CPE vendor.

When you use range extenders, you don't have "subtended CPEs".

> Subtended CPE in IPv4 world were put in “bridge mode” to avoid 
> additional NAT, that does not make sense in IPv6 world. 

Disagreed. You keep it that way because otherwise ip comeras and others 
will most likely not work.

SImilarly, link-local protocols such as mdns and other will not work. SO 
you want a bridged network, not a routed one.

> Every IPv6 CPE 
> should be in routed mode. It is not the problem when minimal delegated 
> prefix is /56 by RIPE recommendations (there is push to /48). 

Reality-check here: for various reasons, many ISPs lease a /64. As an 
example, Telefonica/Movistar do so in Peru, and Telececentro a 
Fibertel/Cablevision do so in Argentina.

> We have to 
> teach carriers how properly developed complicated solutions for 
> residential broadband. No standardization problem again.

We have to make IPv6 work flawlessly. Unless we want that the solution 
to networking problems starts to be "disabling IPv6".

> Other cases discussed in “draft-gont-v6ops-slaac-renum-02” are for the 
> situation when admin deleted old PIO without any signaling to host (no 
> preferred lifetime = 0), then introduced new PIO. It does not matter: 
> manual or automated through OSS or automated by 802.1x port. It is 
> definitely admin mistake – he treat IPv6 as IPv4.

THere are deamons that don't deprecate the prefix before terminating. 
And there are multiple reasons for which that might simply fail. whether 
that's because the daemon crashes, or other reasons.

> I am not worried too much for the case when Multicast announcement about 
> preferred lifetime 0 could be lost, because if multicast lost then new 
> PIO would not be delivered too – host would be left without connectivity 
> at all. I am not the big fan of multicast too, but it is different case.

Not true. IN order to reliably deprecate a prefix you should be sending 
RAs deprecating the old prefix for at least the previous Preferred Lifetime.

FOr obvious reaosns, that's not what normal deamons do -- they simply 
send a few back to back RAs. If there happened to be a temporary 
disconnection, or the like, those won't get through.

> Some advanced subscriber could really have separate Router and Switch in 
> the apartment (or small business branch). Then Switch port would not go 
> through initialization at the same time as router would do reload. Then 
> we would witness the problem discussed in 
> “draft-gont-v6ops-slaac-renum-02”. Only host reload could help here.
> Probability for that case is extremely low, because everybody likes 
> integrated solution (no separate dumb switch). If we have WiFi AP then 
> it is probably Enterprise site with static addresses anyway.

It's pretty normal for small enterprises over here to have the CPE and a 
switch. Normally, the CPE provided by the ISP will have not more than a 
few switch ports. So as soon as you have a printer, and a few other 
wired devices, you run out of ports and need to connect a switch to the CPE.

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 11:50:32 +0000

Hi Fernando,
Good. You have confirmed my expectations.
You did not mention in any document that problem is possible only if switch is separated from router. It is applicable only for many-box situation.

I have external wall 0.64m thick (huge bricks with big holes for air), internal walls are 12cm bricks.
5Ghz does not work even over internal wall (4*4 MIMO does not help - it is not supported by smartphones anyway).
2.4Ghz works over 2 internal and 1 external wall (to veranda).
2.4Ghz works over floor: 22cm with heavy armature inside.
I still have 1 WiFi in my House that put in one corner of the building. It is enough. 5Ghz is not much important for me when everything high performance is connected by 1GE.
But it does not matter what I have - it is very special situation (like yours).
Majority of countries have urbanization for 70%-80%. We are talking about apartments, not houses.
I have been involved into massive construction of FBB (36M of ports that resulted in 12M of subs) - I know what is typical. It is one CPE in the apartment for most cases.
It already creates the huge problem with interference, because WiFi 2.4 penetrates cross-apartments, but we have only 3 non-overlapping frequency in 2.4G band. We had a problem how to cut number of WiFi radios. It just does not work.
It does convert discussed problem to some small corner case that is relevant only for geeks that are willing to install many devices. But do not forget to multiply small number of geeks on 0.37 - Carrier need to create the problem in 1st place.
Yes, we need to solve problem for geeks too.

I did participate in a few tenders (on both sides) for B2B CPEs. Nobody likes "many box solution" (cost , maintenance, size, power). Vendors have Enterprise CPEs with enough L2 ports (up to 48). 2 box solution is not typical used even here.

v6ops have a reference to good excel (on google disk) in 2017 for details about 85 biggest Telco. Not all have disclosed prefix size. RIPE has started push to /48 too later:
/48 - 3
/56 - 11
/60 - 1
/62 - 1
/64 - 12
You are right here. It is exacerbate geeks problem.

Could you tell me why IP camera needs bridged (L2) network? Why router network is not suitable?

If some daemon is not capable to deprecate PIO properly - it is more vendor problem than standard. The same for CPE. But yes, some robustness from ND is welcome here.

Draft is needed. Despite the problem is much smaller.
I am just extremely unhappy fors timer optimization.

Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 16 сентября 2020 г. 13:20
To: Vasilenko Eduard <[email-masked]>; [email-masked]; IPv6 Operations <[email-masked]>
Subject: Re: Flash renumbering

Eduard,

> problem has very small corner case. We could say that it does not exist.

Can you come up and fix my internet connection every now and then this problems happens at my own home?

It puzzles me to hear you say that the problem doesn't existing when v6ops agreed otherwise, and when I've experienced it myself recently.

(and there are multiple scenarios where it does happen, from the CPE case, to VMs being moved around. etc).

[...]

[...]

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2020 09:41:27 -0300

On 16/9/20 08:50, Vasilenko Eduard wrote:
> Hi Fernando, Good. You have confirmed my expectations. You did not
> mention in any document that problem is possible only if switch is
> separated from router. It is applicable only for many-box situation.

No.

As noted multiple scenarios where this problem may occur. Section 1 of
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 , contains a
non-exhaustive list of some of the scenarios.

I've mentioned others in my previous email.

If you move VMs around, you may get the same thing.

[...]
> I still have 1 WiFi in my House that put in one corner of the
> building. It is enough. 5Ghz is not much important for me when
> everything high performance is connected by 1GE. But it does not
> matter what I have - it is very special situation (like yours).

Can you please back your claims? My family has always lived in a
residential area, where wifi signal having to traverse through multiple 
walls is the *rule*, not the exception.

> about apartments, not houses.

Please let me know where you get your stats from.

And, are you seriously meaning that this group should only care about
IPv6 being robust in "apartment scenarios"?

> I did participate in a few tenders (on both sides) for B2B CPEs.
> Nobody likes "many box solution" (cost , maintenance, size, power).
> Vendors have Enterprise CPEs with enough L2 ports (up to 48). 2 box
> solution is not typical used even here.

It is quite common over here. And for a small office, you will most 
likely get the same CPE as a home user.

> v6ops have a reference to good excel (on google disk) in 2017 for
> details about 85 biggest Telco. Not all have disclosed prefix size.
> RIPE has started push to /48 too later: /48 - 3 /56 - 11 /60 - 1 /62
> - 1 /64 - 12 You are right here. It is exacerbate geeks problem.
> 

Because they cannot traverse multiple NATs.

Many applications will employ upnp to install port mappings in the CPE. 
But the CPE will not try to "relay" such mappings elsewhere.

Similarly, mDNS has typically only worked on a single network segment.
If you put a multiple cascading CPEs, you break that.

> If some daemon is not capable to deprecate PIO properly - it is more
> vendor problem than standard. The same for CPE. But yes, some
> robustness from ND is welcome here.

It is not. Because since the recommended default for the Valid Lifetime,
the daemon wasn't going to keep sending RAs for 7 days, and only start
announcing the new prefix after 7 days.

When doing things such as installing a simple range extender may lead to 
total brokenness, there's a robustness flaw being exposed. And you 
should address the flaw, rather trying to find every possible reason not 
to solve it. -- unless you make a case that the only people that should 
deply v6 are the one that live in apartments or wooden-wall houses, plus 
they use a single box to connect to the Internet, the ISP does static 
prefixes, etc., etc., etc.   And, still, you would have other possible 
scenarios, that are completely unrelated, such as moving VMs around.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 15:55:44 +0000

Hi Fernando,
I do not believe that other cases are representative except many-box solution.
Because all other cases are: somebody forgotten to deprecate prefix in his software (including VM - just need to send at least one RA before prefix change).
It was better to push Industry to properly develop software to deprecate prefixes, then to compromise timers.

For the multi-box scenario:
30% is the probability that residential subs have IPv6 (in reality less, 30% is mainly attributed by mobile)
37% that his Carrier do dynamic DHCP-PD
5% that he has 2 boxes in the household (reminder: relationships between number of businesses to households is about 2% for majority of countries, number of branches for big Enterprise could be big (+), but many SMBs would be satisfied by typical CPE(-))
50% that he is not capable to create routed network inside (/64 from Carrier - now should be less such cases compare to 2017).
What we have? 0.3% from world-wide subscriber base? It is what I call "corner case".
Make sense to fix.

In response to "why IP camera needs bridged network" you have answered "to avoid NAT".
We are in IPv6 alias. Whatever you would do in IPv6 - you will avoid NAT. Hence, Routed network inside household is not a problem for IP camera. Right?

I do not know mDNS - may be it needs bridged network. It would be additional extremely small corner case (10^-5). Better to fix.

Eduard
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 16 сентября 2020 г. 15:41
To: Vasilenko Eduard <[email-masked]>; [email-masked]; IPv6 Operations <[email-masked]>
Subject: Re: Flash renumbering

No.

As noted multiple scenarios where this problem may occur. Section 1 of
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 , contains a non-exhaustive list of some of the scenarios.

[...]
> matter what I have - it is very special situation (like yours).

Can you please back your claims? My family has always lived in a residential area, where wifi signal having to traverse through multiple walls is the *rule*, not the exception.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2020 13:40:15 -0300

> Because all other cases are: somebody forgotten to deprecate prefix in his software (including VM - just need to send at least one RA before prefix change).

All these things expose a stituation that is not robust. You are 
essentially arguing for brokenness.

> It was better to push Industry to properly develop software to deprecate prefixes, then to compromise timers.

What do you mean by "compromise timers"?

> 30% is the probability that residential subs have IPv6 (in reality less, 30% is mainly attributed by mobile)

Where do you get this numbers from?

> 5% that he has 2 boxes in the household (reminder: relationships between number of businesses to households is about 2% for majority of countries, number of branches for big Enterprise could be big…

Again where do you get this "5%". Do you just make it up?

And, anyway, the possibility is irrelevant. I don't think I need to 
point out that the use of range extenders and the like are not unusual. 
THat kind of thing works pretty well with IPv4, and could be very broken 
with IPv6.

> 50% that he is not capable to create routed network inside (/64 from Carrier - now should be less such cases compare to 2017).

Same here. WHere do you get these numbers for. Besides, in many cases, 
you *don't want* to have a subneted local network.

[...]
> We are in IPv6 alias. Whatever you would do in IPv6 - you will avoid NAT. Hence, Routed network inside household is not a problem for IP camera. Right?

A subneted network breaks mDNS.

> I do not know mDNS - may be it needs bridged network. It would be additional extremely small corner case (10^-5).

huh? Most people access their home devices with technologies such as 
mDNS and LLMNR, which operate on a single segment. Because they are plug 
and ply without the need to set up a name server, or anything.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 17:32:48 +0000

> All these things expose a stituation that is not robust. You are essentially arguing for brokenness.
Partially agree. Better to fix.

>Where do you get this numbers from?
Many open sources: Google, APNIC (most accurate, Huston behind it), Akamai. Results are very comparable.

> Again where do you get this "5%". Do you just make it up?
Yes, I have increased 2% for business (that is possible to prove) to something bigger. The error here is not principal for our discussion.

>Same here. WHere do you get these numbers for. Besides, in many cases, you *don't want* to have a subneted local network.
I have shown you statistic below - it was 2017 before strong push from RIPE for /56->/48. It should be more /56 now.

> huh? Most people access their home devices with technologies such as  mDNS and LLMNR, which operate on a single segment. Because they are plug  and ply without the need to set up a name server, or anything.
Most here means "most geeks" - it is much smaller portion then 0.3%

Ed/
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 16 сентября 2020 г. 19:40
To: Vasilenko Eduard <[email-masked]>; [email-masked]; IPv6 Operations <[email-masked]>
Subject: Re: Flash renumbering

> Because all other cases are: somebody forgotten to deprecate prefix in his software (including VM - just need to send at least one RA before prefix change).

All these things expose a stituation that is not robust. You are essentially arguing for brokenness.

[...]

Thanks,

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 17 Sep 2020 00:44:39 +0200

On 15/09/2020 22:29, Vasilenko Eduard wrote:
> It definitely does not need urgent solution.

This problem is so real in deployments where operators decided to go 
with non-persistent IPv6 prefix delegations that we documented it in 
RIPE-690 where we suggest to deploy prefix delegations as 
persistent/static as possible so networks/hosts behind CPEs don't suffer 
from this issue.

My personal preference strongly lies towards static/persistent IPv6 
prefixes, but that doesn't mean we should not make SLAAC at least more 
robust to more accurately and timely follow the topology changes (one of 
them being PD change).

Cheers, Jan Zorz

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Sep 2020 09:05:18 +0100

> persistent/static as possible so networks/hosts behind CPEs don't suffer 

You mean to have the ISPs to provide persistent state so that SLAAC can 
handle things better?  Only half joking here :-)

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 17 Sep 2020 09:29:54 +0000

Hi Jan,
Delivering the same prefix to CPE after reload (by DHCP-PD).
Yes, I am with you. Good comment.

Unfortunately, Fernando has shown a few additional (even smaller) corner cases that needs to be addressed anyway.
When I have started to think seriously - I have found a few additional tiny corner cases (not show in Fernando drafts). That is better to address too.
It would be ND renumbering nitting draft.
Ed/
> From: Jan Zorz - Go6 [mailto:[email-masked]]
> Sent: 17 сентября 2020 г. 1:45
> This problem is so real in deployments where operators decided to go with non-
> persistent IPv6 prefix delegations that we documented it in
> RIPE-690 where we suggest to deploy prefix delegations as persistent/static as
> possible so networks/hosts behind CPEs don't suffer from this issue.
> 
> My personal preference strongly lies towards static/persistent IPv6 prefixes, but
> that doesn't mean we should not make SLAAC at least more robust to more
> accurately and timely follow the topology changes (one of them being PD
> change).
> 
> Cheers, Jan Zorz