Subject: [v6ops] 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: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2020 09:07:04 +1200

> Partially agree. Better to fix.

25 years watching vendors of low price devices have convinced me that there will always be broken devices in millions of SOHO networks. Hosts absolutely must be as robust as possible. Ideally that means applying quite complex heuristics, not fixed default timers, but all the IETF can do is suggest the best compromise on timers for unmanaged networks.

The timers should all be configurable in a managed network.

  Brian

---

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Sep 2020 08:48:50 +1200

> handle things better?  Only half joking here :-)

SLAAC is only one of the victims of flash renumbering. (If there was
more widespread use of ULAs that might not be true.)

    Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 18 Sep 2020 07:04:32 +0000

Hi Brian,
> SLAAC is only one of the victims of flash renumbering. (If there was more
> widespread use of ULAs that might not be true.)
[Ed: ] But How? Subscriber needs access to Global Internet.
Is it possible to connect Google by ULA?
Ed/
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: 17 сентября 2020 г. 23:49
> To: [email-masked]
> Subject: Re: [v6ops] Flash renumbering
> 
> >> persistent/static as possible so networks/hosts behind CPEs don't
> >> suffer from this issue.
> >
> > You mean to have the ISPs to provide persistent state so that SLAAC
> > can handle things better?  Only half joking here :-)
> 
> SLAAC is only one of the victims of flash renumbering. (If there was more
> widespread use of ULAs that might not be true.)
> 
>     Brian
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Fri, 18 Sep 2020 11:32:59 +0200

> Is it possible to connect Google by ULA?

If you have ephemeral global addresses, at the two extremes on the scale you have:

1) ULA + NAT.
   Aka the IPv4 model. Provides stable addressing on the local network.
   Transport sessions do not survive renumbering events.

2) Ephemeral addressing support on hosts.
   Including support in the network layer, transport layer and application layer.
   This is not any different than what a host supporting multi-prefix multi-homing
   needs to do. It means transport / application layer must detect changes in
   connectivity and change address pairs as required.

Ole

---

From: Richard Patterson <[email-masked]>
Date: Fri, 18 Sep 2020 16:55:21 +0100

> Is it possible to connect Google by ULA?

Well if ULAs were used more often for local connectivity, they wouldn't be
impacted by an outage of the WAN interface causing the GUA prefix to change.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Sep 2020 13:11:50 -0400

All

I really still feel this use case being Broadband provider PD related stale
prefix issue  is really a corner case for SOHO users as it does not impact
enterprises with manually configured stable prefix which is 100% of the
enterprise dual stack use case.

>From an operations impact there is considerable monetary impact to
enterprises if the IPv6 standards change proposed by flash renumbering
 does not take into account the  enterprise stable prefix scenario that
does not fall into this one size fits all bucket being proposed.

I am worried about adverse effects of the changes being proposed to SLAAC
standard that could impact enterprises.  We just need to be very careful
that every used case out there is accounted for.

Gyan

On Fri, Sep 18, 2020 at 11:56 AM Richard Patterson <[email-masked]>
wrote:

> On Fri, 18 Sep 2020 at 08:05, Vasilenko Eduard <
> [email-masked]> wrote:
>
>> Hi Brian,
>>
>>
>> more

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 18 Sep 2020 19:21:29 +0000

Some traffic could be local inside the apartment (TV from Server/NAS),
But definitely bigger proportion of traffic is going from real Internet.
It is additional burden to have ULA for local and GUA for wild Internet.
I do not see ULA usefulness without NAT.

From: Richard Patterson [mailto:[email-masked]]
Sent: 18 сентября 2020 г. 18:55
To: Vasilenko Eduard <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Flash renumbering

On Fri, 18 Sep 2020 at 08:05, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

Well if ULAs were used more often for local connectivity, they wouldn't be impacted by an outage of the WAN interface causing the GUA prefix to change.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 15:25:37 -0400

> I do not see ULA usefulness without NAT.

The usefulness is for supporting the traffic within the home, which you admit exists (and can actually be substantial). This has to work. Having it fail because the uplink went away is not acceptable. There’s no meaningful cost to having a ULA, so this is just an obvious thing to do. FWIW, the commercial home router setup I have (an Eero mesh) advertises a ULA even if there is no IPv6 service to the global internet, so apparently I’m not alone in thinking that ULAs are useful.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 18 Sep 2020 19:47:45 +0000

From standard point of view
local traffic should not stop after CPE would lose uplink,
Because internal CPE switch should still switch traffic
After internal CPE router would stop promoting itself a router for this link

From: Ted Lemon [mailto:[email-masked]]
Sent: 18 сентября 2020 г. 22:26
To: Vasilenko Eduard <[email-masked]>
Cc: Richard Patterson <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Flash renumbering

On Sep 18, 2020, at 3:21 PM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 15:51:51 -0400

> After internal CPE router would stop promoting itself a router for this link

That’s at layer 2. At layer 3, we need a stable prefix so that the traffic continues to flow during the external renumbering event without breaking internal traffic.

---

From: Richard Patterson <[email-masked]>
Date: Fri, 18 Sep 2020 21:31:13 +0100

> After internal CPE router would stop promoting itself a router for this

In this scenario, when the WAN interface (native Ethernet or PPP) goes
down, would you expect the CPE router to:
a) continue sending RAs with the old prefix PIO as if nothing has happened.
b) send an RA with PIO prefered lifetime of 0
c) simply stop sending RAs with the PIO

a. messes up multihoming, and is a bit disingenuous of the CPE to continue
advertising
b. Helps deprecate the stale GUA prefix but means we lose local IPv6
connectivity
c. Prevents new devices from attaching and getting local IPv6 connectivity

ULA would help retain local IPv6 connectivity behind CPEs that implement b
& c.
I'm kinda wishing we included a recommendation for the use of ULA in
draft-ietf-v6ops-cpe-slaac-renum.  But I imagine that would be rather
contentious

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2020 08:51:41 +1200

> Is it possible to connect Google by ULA?

I'm not referring to off-site traffic. Once we see SOHO networks with
internal routing, internal traffic can run over ULAs whatever disturbance
happens in the outside world. Without ULAs, that is only possible on
a link-local basis.

I think you are persistently thinking of IPv6 as IPv4 with bigger addresses.
It's more than that.

Regards
   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2020 08:56:56 +1200

On 19-Sep-20 05:11, Gyan Mishra wrote:
> 
> All
> 
> I really still feel this use case being Broadband provider PD related stale prefix issue  is really a corner case for SOHO users 

Why is that a "corner case"? We can count SOHO networks by the hundreds of millions, compared with enterprise networks in millions. They both matter, but SOHOs are about two orders of magnitude greater in number.

   Brian

> as it does not impact enterprises with manually configured stable prefix which is 100% of the enterprise dual stack use case. 
> 
> From an operations impact there is considerable monetary impact to enterprises if the IPv6 standards change proposed by flash renumbering  does not take into account the  enterprise stable prefix scenario that does not fall into this one size fits all bucket being proposed.  
> 
> I am worried about adverse effects of the changes being proposed to SLAAC standard that could impact enterprises.  We just need to be very careful that every used case out there is accounted for.
> 
> Gyan
> 
> On Fri, Sep 18, 2020 at 11:56 AM Richard Patterson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Fri, 18 Sep 2020 at 08:05, Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Brian,
> 
> 
>     [email-masked] <mailto:[email-masked]>
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Sep 2020 23:21:16 +0200

> On 18 Sep 2020, at 22:57, Brian E Carpenter <[email-masked]> wrote:
> 

Corner case because Service Providers generally do not flash renumber their customers. 

Cheers 
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 18 Sep 2020 22:33:02 +0100

Brian E Carpenter wrote on 18/09/2020 21:56:
> Why is that a "corner case"? We can count SOHO networks by the
> hundreds of millions, compared with enterprise networks in millions.
> They both matter, but SOHOs are about two orders of magnitude greater
> in number.

tbh, there's no clear divide for fixed-line provisioning.  There's a 
giant arc of configuration styles, ranging from granny's internet feed 
to corporates with hundreds of thousands of desktops, and everything in 
between. But yes, it's heavily weighted in terms of numbers, traffic and 
just about everything else towards residential / soho, and usually 
there's no difference between residential and soho.  It's the modem in 
the corner with a couple of people connecting to wifi.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 18:14:43 -0400

> Corner case because Service Providers generally do not flash renumber their customers. 

Just saying that way implies so many assumptions that really aren’t general. E.g.:

- The ISP can never have a reason to flash renumber, or so rarely that if it blows up your network that’s fine (when is that ever fine?)
- All of the boxes between you and your ISP are carefully curated so that nothing ever goes wrong that results in a theoretically-preventable flash renumber event.
- The network topology is completely stable.
- Your uplink is wired, so there’s no possibility of RFI forcing a renumbering event
- It’s not many hops to the backbone, and all of the intermediate links are reliable and stable
- Reliability in the on-site infrastructure is nice-to-have, not required (light switches don’t have to work)

Etc.

I think that when this position is put forward as a sort of universal ground truth, it is actively harmful to end users.

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Sep 2020 08:32:30 +1000

On Sat, 19 Sep 2020, 07:21 Ole Troan, <[email-masked]> wrote:

> >> I really still feel this use case being Broadband provider PD related
> stale prefix issue  is really a corner case for SOHO users
> >
> > Why is that a "corner case"? We can count SOHO networks by the hundreds
> of millions, compared with enterprise networks in millions. They both
> matter, but SOHOs are about two orders of magnitude greater in number.
>

As IP addresses are currently used as locators, flash renumbering is really
flash moving hosts to another point of attachment to the network.

Dynamic addresses don't align with the reality that the customers' layer 2
point of attachment to the network (and geographic location) doesn't
normally change.

Regards,
Mark.

> Cheers
> Ole
>
>
> >
> >   Brian
> >
> >> as it does not impact enterprises with manually configured stable
> prefix which is 100% of the enterprise dual stack use case.
> >>
> does not take into account the  enterprise stable prefix scenario that does
> not fall into this one size fits all bucket being proposed.
> >>
> >> I am worried about adverse effects of the changes being proposed to
> SLAAC standard that could impact enterprises.  We just need to be very
> careful that every used case out there is accounted for.
> >>
> >> Gyan
> >>
> >> On Fri, Sep 18, 2020 at 11:56 AM Richard Patterson <
> [email-masked] <mailto:[email-masked]>> wrote:
> >>
> [email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>        Hi Brian,
> >>
> >>
> >>    Well if ULAs were used more often for local connectivity, they
> wouldn't be impacted by an outage of the WAN interface causing the GUA
> prefix to change.
> >>
> >>
> >>

---

From: Ole Troan <[email-masked]>
Date: Sat, 19 Sep 2020 02:29:54 +0200

Ted,

Why don’t you write a draft on how you would like flash renumbering to work. 

Ole

> On 19 Sep 2020, at 00:15, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 20:43:48 -0400

ISTM that there is already quite a bit of good work going on in this space, which I support. I may have more to offer later, but it requires running code to test. 

> On Sep 18, 2020, at 20:30, Ole Troan <[email-masked]> wrote:
> 
> 
> Ted,
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 19 Sep 2020 03:16:11 +0200

> On 19 Sep 2020, at 02:44, Ted Lemon <[email-masked]> wrote:
> 
> 

OK, I wasn’t aware of any work to support flash renumbering. Only to mask some the worst effects of it. 

Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 21:29:33 -0400

That’s all you can really do. 

> On Sep 18, 2020, at 21:16, Ole Troan <[email-masked]> wrote:
> 
> 
> 
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 19 Sep 2020 04:00:18 +0200

> On 19 Sep 2020, at 03:29, Ted Lemon <[email-masked]> wrote:
> 
> 

That’s incorrect. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2020 14:13:04 +1200

> Corner case because Service Providers generally do not flash renumber their customers. 

Can you put a percentage on that? Where I live, they do, whenever there's a glitch on the local loop, even if the local loop is made of glass.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Sep 2020 22:29:44 -0400

The whole issue with flash renumbering is related to PD.  Instead of
changing SLAAC to react better to flash renumbering event could we just
make PD sticky so it keeps your last prefix doled out similar to DHCPv4
where you get your last leased prefix.

Is that possible?

On Fri, Sep 18, 2020 at 10:13 PM Brian E Carpenter <
[email-masked]> wrote:

> Can you put a percentage on that? Where I live, they do, whenever there's
> a glitch on the local loop, even if the local loop is made of glass.
>
>
>
>     Brian
>
>
>
> --

*Gyan Mishra*

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Sep 2020 22:39:54 -0400

It’s possible, but isn’t always done, and doesn’t address the problem of topology changes. 

> On Sep 18, 2020, at 22:30, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> The whole issue with flash renumbering is related to PD.  Instead of changing SLAAC to react better to flash renumbering event could we just make PD sticky so it keeps your last prefix doled out similar to DHCPv4 where you get your last leased prefix.
> 
> Is that possible?
> 
>> On Fri, Sep 18, 2020 at 10:13 PM Brian E Carpenter <[email-masked]> wrote:
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Sep 2020 22:44:33 -0400

So I think from a Fortune 500 perspective small, mid and large cap
companies representing big business and outages can be catastrophic costing
millions of dollars where a SOHO broadband user community it’s not
catastrophic from a monetary perspective that the SOHO or home user
watching Netflix is has to reboot his CPE from a renumbering event.

The impact on enterprises is more catastrophic then impact to SOHO user
communities and I guess from trickle down to economics perspective, if that
impacts your bottom line and don’t meet your earnings it impacts all
shareholders and of course the trickle down to everybody’s 401k’s.

Bottom line is even though for the broadband subscriber it disappointing to
have to reset your router when your video flix freezes ...but if your 401k
is being impacted by the SLAAC changes proposed I think we all may think
otherwise.

We just have to be a million percent sure that there is no impact to all
use cases.

Kind Regards

Gyan

On Fri, Sep 18, 2020 at 4:56 PM Brian E Carpenter <
[email-masked]> wrote:

> Why is that a "corner case"? We can count SOHO networks by the hundreds of
> millions, compared with enterprise networks in millions. They both matter,
> but SOHOs are about two orders of magnitude greater in number.
>
>
>
>    Brian
>
>
>
> > as it does not impact enterprises with manually configured stable prefix
> which is 100% of the enterprise dual stack use case.
>
> >
>

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2020 15:01:32 +1200

On 19-Sep-20 14:44, Gyan Mishra wrote:
> 
> So I think from a Fortune 500 perspective small, mid and large cap companies representing big business and outages can be catastrophic costing millions of dollars where a SOHO broadband user community it’s not catastrophic from a monetary perspective that the SOHO or home user watching Netflix is has to reboot his CPE from a renumbering event.  

This isn't the Internet Profit Task Force. We should be worrying about all end users.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Sep 2020 23:21:49 -0400

I browsed through the PD RFC and was wondering instead of changing the VL
PL timers and other changes on the SLAAC side, could the PD default timers
be changed to short VL PL.

I think the problem is their is not any glue logic between PD and SLAAC
communication so the renumbering event does not update SLAAC.

So as I suggested even if PD had short VL PL that would not help at all per
what I stated.

Is their a way to build some signaling between PD WAN broadband  and the
SLAAC interfaces so the renumbering event is automatically propagated
downstream.

https://tools.ietf.org/html/rfc3633#page-9

On Fri, Sep 18, 2020 at 10:39 PM Ted Lemon <[email-masked]> wrote:

>> hundreds of millions, compared with enterprise networks in millions. They
>> both matter, but SOHOs are about two orders of magnitude greater in number.
>>
>> >
>>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Sep 2020 23:37:39 -0400

As far as flash renumbering per RIPE-690 below question.

https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/

Are the renumbering events occurring due to smaller allocations less than
/56, and as long as /56 or larger is doled our for privacy that limits the
frequency of renumbering events?

RIPE-690 outlines best current operational practices for the assignment of
IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making
wrong choices when designing an IPv6 network will eventually have negative
implications for deployment and require further effort such as renumbering
when the network is already in operation. In particular, assigning IPv6
prefixes longer than /56 to residential customers is strongly discouraged,
with /48 recommended for business customers. This will allow plenty of
space for future expansion and sub-netting without the need for
renumbering, whilst persistent prefixes (i.e. static) should be highly
preferred for simplicity, stability and cost reasons.

The target audience of RIPE-690 is technical staff working in ISPs and
other network operators who currently provide or intend to provide IPv6
services to residential or business end-users. Up until now, there have
been no clear recommendations on how to assign IPv6 prefixes to customers,
and a variety of different and sometimes problematic solutions have been
implemented.

On Fri, Sep 18, 2020 at 11:21 PM Gyan Mishra <[email-masked]> wrote:

> So as I suggested even if PD had short VL PL that would not help at all
> per what I stated.
>
>>> >>> I really still feel this use case being Broadband provider PD
>>> related stale prefix issue  is really a corner case for SOHO users
>>>
>>> >>
>>>
>>> Can you put a percentage on that? Where I live, they do, whenever
>>> there's a glitch on the local loop, even if the local loop is made of glass.
>>>
>>>
>>>
>>>     Brian
>>>
>>>
>>>
>>> --
>>

*Gyan Mishra*

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 02:35:27 -0300

Hi, Ole,

> If you have ephemeral global addresses, at the two extremes on the scale you have:

At the end of the day, global addresses *are* ephemeral. And the case 
where they are not should be treated as a special case.

>     connectivity and change address pairs as required.

I think 2) should be split into multiple pieces.

One part is having the network layer handle multiple prefixes and 
fresh/stale information nicely. Then transport/app may need to improve 
on that -- e.g., make connections survive across address changes, make 
appropriate choices for src/dst addresses, etc.

The network part is currently very broken, due, among other things, to 
like of widespread support for RFC8028. MP-TCP, for example, has taken 
care of *part* of the transport/app layer issues.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 02:39:41 -0300

Gyan,

On 18/9/20 14:11, Gyan Mishra wrote:
> stale prefix issue  is really a corner case for SOHO users as it does 
> not impact enterprises with manually configured stable prefix which is 
> 100% of the enterprise dual stack use case.

We have authored an entire I-D on the operational aspecs of 
flsh-renumbering (draft-ietf-v6ops-slaac-renum), which lists the SOHO 
scenario as one of *many* possible scenarios. I wonder why people keep 
insisting on that scenario as the only one, even after we have 
repeatedly pointed to the multiple scenarios listed in 
draft-ietf-v6ops-slaac-renum.

> careful that every used case out there is accounted for.

We *are* being very careful. Could you please point at the sceneario 
where any of what we have been proposing introduces breakage? Otherwise, 
without concrete comments, it's hard to have a meaningful converstion.

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 02:43:23 -0300

> After internal CPE router would stop promoting itself a router for this link

When you use an address, you are claiming you are attached to a specific 
point of the network topology. If the up link is broken, then I wonder 
how one could possibly continue using addresses that claim to be part of 
the network topology when, in reality, you are not.

So yes, if you want local traffic to survive uplink issues, you should 
be using ULAs. Those are, for the most part, addresses with 
local-significance and independent of global topology.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 02:50:12 -0300

> Corner case because Service Providers generally do not flash renumber their customers.

This was already discussed in v6ops. We have at least 30% of those. 
While we can debate on the meaning of "generally", I bet we'd all agree 
that a 30% of failure rate is unacceptable.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 03:08:07 -0300

> Because internal CPE switch should still switch traffic

GUAs are, for obvious reasons, topologically-dependent. Unless you have 
a static prefix assigned (and I mean static, not stable as in "generally 
stays the same), then when the uplink fails, it's conceptually wrong to 
keep using addresses that claim you're part of a network topology when 
you're not attached to such network in the first place.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 03:15:36 -0300

> Can you put a percentage on that? Where I live, they do, whenever there's a glitch on the local loop, even if the local loop is made of glass.

Same here. FWIW, I'm manually setting PL to 15' and VL to 30' as a way 
to cope with flash renumbering events.

In any case, when so many things need to happen and work in a certain 
way for the network to be usable, that's arguing for broken design.

And that doesn't seem to align well with the goal that "the network 
works as long as there's a working path between source and destination".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Sep 2020 03:17:35 -0300

> where you get your last leased prefix.

It is not. Please check draft-ietf-v6ops-slaac-renum.

> Is that possible?

If your solution is about keeping additional state in the network, 
that's generally not much of a robust design. As much as it's good to 
improve the network, we do need smarts in the hosts. That's what leads 
to more robust network design.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 10:51:09 +0000

Hi Fernando,
CPE requirements have been developed in such a way that ULA is not needed.
If router does not claim itself as a default, - it does not mean that the router should deprecate prefixes distributed early.
Look carefully to below, specifically to "This advertisement is independent of having or not having IPv6 connectivity on the WAN interface.".

RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
L-3:   An IPv6 CE router MUST advertise itself as a router for the  delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) using the "Route Information Option" specified in Section 2.3 of [RFC4191].
This advertisement is independent of having or not having IPv6 connectivity on the WAN interface.
L-4:   An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime [RFC4861] greater than zero if it has no prefixes configured or delegated to it.

Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 19 сентября 2020 г. 8:43
> To: Vasilenko Eduard <[email-masked]>; Ted Lemon
> <[email-masked]>
> Cc: [email-masked]
> When you use an address, you are claiming you are attached to a specific point
> of the network topology. If the up link is broken, then I wonder how one could
> possibly continue using addresses that claim to be part of the network topology
> when, in reality, you are not.
> 
> So yes, if you want local traffic to survive uplink issues, you should be using
> ULAs. Those are, for the most part, addresses with local-significance and
> independent of global topology.
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 10:57:06 +0000

Hi Fernando,
Generalization does not work always. Look my other reply to you.
ND is very complex - it did have many interesting corner cases (bad and good) that would not be possible to squeeze into any high level concept. Like "topologically-dependent".

We were talking below about the case when just uplink is disconnected, it is not known yet would it be the same prefix or not after reconnect.
Eduard
> Sent: 19 сентября 2020 г. 9:08
> GUAs are, for obvious reasons, topologically-dependent. Unless you have a
> static prefix assigned (and I mean static, not stable as in "generally stays the
> same), then when the uplink fails, it's conceptually wrong to keep using
> addresses that claim you're part of a network topology when you're not
> attached to such network in the first place.
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 11:00:24 +0000

If you account for
how many subscribers have 2 box solution in the apartment
how many have IPv6
how many insist to provision some box as bridge,
Then 30% would be converted to 0.27%

> From: v6ops [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: 19 сентября 2020 г. 8:50
> To: Ole Troan <[email-masked]>; Brian E Carpenter
> <[email-masked]>
> Cc: [email-masked]
> of millions, compared with enterprise networks in millions. They both matter,
> While we can debate on the meaning of "generally", I bet we'd all agree that a
> 30% of failure rate is unacceptable.
> 
> Thanks,
> --
> Fernando Gont

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 11:05:23 +0000

Hi Richard,
I have sent in reply to Fernando details: RFC 7084 has chosen different option:
d) continue sending old PIO, but inform hosts that this router is not default anymore
IMHO: it is right!

Sent: 18 сентября 2020 г. 23:31

On Fri, 18 Sep 2020 at 20:47, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

In this scenario, when the WAN interface (native Ethernet or PPP) goes down, would you expect the CPE router to:
a) continue sending RAs with the old prefix PIO as if nothing has happened.
b) send an RA with PIO prefered lifetime of 0
c) simply stop sending RAs with the PIO

a. messes up multihoming, and is a bit disingenuous of the CPE to continue advertising
b. Helps deprecate the stale GUA prefix but means we lose local IPv6 connectivity
c. Prevents new devices from attaching and getting local IPv6 connectivity

ULA would help retain local IPv6 connectivity behind CPEs that implement b & c.
I'm kinda wishing we included a recommendation for the use of ULA in draft-ietf-v6ops-cpe-slaac-renum.  But I imagine that would be rather contentious

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 11:09:55 +0000

Hi Ted,
No problem, just follow RFC 7084.
Old GUA prefix could be used up to the point that WAN link would be reconnected and GUA would be changed with 37% probability.
Eduard
From: Ted Lemon [mailto:[email-masked]]
Sent: 18 сентября 2020 г. 22:52
To: Vasilenko Eduard <[email-masked]>
Cc: Richard Patterson <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Flash renumbering

On Sep 18, 2020, at 3:47 PM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 11:14:08 +0000

> I think you are persistently thinking of IPv6 as IPv4 with bigger addresses.

Yes, IPv6 has much more flexibility (and associated complexity),
But I am not the big fun to create excessive IPv6 addresses on hosts
Just because IPv6 architecture could do it easily.
I have being tough for many years that any state has associated CAPEX and OPEX cost.

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 18 сентября 2020 г. 23:52
> To: Vasilenko Eduard <[email-masked]>; [email-masked]
> I'm not referring to off-site traffic. Once we see SOHO networks with internal
> routing, internal traffic can run over ULAs whatever disturbance happens in the
> outside world. Without ULAs, that is only possible on a link-local basis.
> 
> >>>> This problem is so real in deployments where operators decided to
> >>>> go with non-persistent IPv6 prefix delegations that we documented
> >>>> it in

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 11:30:49 +0000

SOHO is 2% compare to overall number of households. This statistics is easily available for every country.
Majority of them are fully satisfied with 4 GE ports that CPE has - they do not need second box - they could not have renumbering problem.
Therefore, SOHO is even smaller problems than geeks.

Small braches of big corporate could be the problem, because they could have more than 1 room and more than 3 PCs + Printer - separate switch could happen here.
If this branch is sitting in a residential area (bank, post, insurance company) then it is connected to BNG, not Business-PE. I have seen many such cases - it is applicable to discussed renumbering.
But it is not very big problem again, because they typically have Internet blocked at branch level (only through centralized FW), local encrypted tunnel is connected to corporate that announce to branch only very stable private addresses (or PI).
Yes, I have seen small number of big corporates that do not care about security - they did have permission to connect to Internet on every branch. Then renumbering could be the problem.

> Sent: 18 сентября 2020 г. 23:57
> To: Gyan Mishra <[email-masked]>; Richard Patterson
> <[email-masked]>
> Cc: [email-masked]
> > I really still feel this use case being Broadband provider PD related stale prefix
> issue  is really a corner case for SOHO users
> 
> millions, compared with enterprise networks in millions. They both matter, but
> SOHOs are about two orders of magnitude greater in number.
> 
>    Brian
> 
> > as it does not impact enterprises with manually configured stable prefix which
> is 100% of the enterprise dual stack use case.
> >
> enterprises if the IPv6 standards change proposed by flash renumbering  does
> not take into account the  enterprise stable prefix scenario that does not fall
> into this one size fits all bucket being proposed.
> >
> standard that could impact enterprises.  We just need to be very careful that
> every used case out there is accounted for.
> >
> > Gyan
> >
> >     On Fri, 18 Sep 2020 at 08:05, Vasilenko Eduard
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >         Hi Brian,
> >
> >

---

From: Philip Homburg <[email-masked]>
Date: Mon, 21 Sep 2020 13:47:32 +0200

> SOHO is 2% compare to
> overall number of households. This statistics is easily available
> for every country.  Majority of them are fully satisfied with 4 GE
> ports that CPE has - they do not need second box - they could not
> have renumbering problem.  Therefore, SOHO is even smaller problems
> than geeks.

In my opinion it is really bad to lock us into a single box deployment.
Wifi technology moves independently from DSL technology. There is no
reason to assume that a single, ISP provided box will do everything well.
In fact it is quite common for people to buy new wifi APs when stuff
doesn't work as well. There is a whole market of wifi mesh devices. That
market would not exist is everybody was happy with their ISP provided router.

This an area where IPv6 does worse than IPv4. We really need to avoid that.
It is very easy for people to disable IPv6, and it is unlikely that they
will turn it on again.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 12:01:44 +0000

Agree.

> From: [email-masked] [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 21 сентября 2020 г. 14:48
> To: [email-masked]
> Cc: Vasilenko Eduard <[email-masked]>
> > overall number of households. This statistics is easily available for
> > every country.  Majority of them are fully satisfied with 4 GE ports
> > that CPE has - they do not need second box - they could not have
> > renumbering problem.  Therefore, SOHO is even smaller problems than
> > geeks.
> 
> Wifi technology moves independently from DSL technology. There is no reason
> to assume that a single, ISP provided box will do everything well.
> In fact it is quite common for people to buy new wifi APs when stuff doesn't
> work as well. There is a whole market of wifi mesh devices. That market would
> not exist is everybody was happy with their ISP provided router.
> 
> It is very easy for people to disable IPv6, and it is unlikely that they will turn it on
> again.
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 Sep 2020 14:21:29 +0200

Hi,

> In my opinion it is really bad to lock us into a single box deployment.

This.

Looking at "what SOHO has *today*" is totally missing what IETF should
be focusing on: how to improve SOHO networking with IPv6 for *tomorrow*.

Homenet demonstrated what IETF can do if looking beyond "today".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Richard Patterson <[email-masked]>
Date: Mon, 21 Sep 2020 13:50:57 +0100

That is actually still just option a), and could result in packets being
sourced from the wrong prefix in a multi-homed, multi-prefixed environment.

On Mon, 21 Sep 2020 at 12:05, Vasilenko Eduard <[email-masked]>
wrote:

> L-3:   An IPv6 CE router MUST advertise itself as a router for the
> delegated prefix(es) (and ULA prefix if configured to provide ULA
> addressing) using the "Route Information Option" specified in Section 2.3
> of [RFC4191].
>
> *This advertisement is independent of having or not having IPv6
> connectivity on the WAN interface*.
>
> L-4:   An IPv6 CE router MUST NOT advertise itself as a default router
> with a Router Lifetime [RFC4861] greater than zero if it has no prefixes
> configured or delegated to it.
>
> Eduard
>
> *From:* Richard Patterson [mailto:[email-masked]]
> *Sent:* 18 сентября 2020 г. 23:31
> *To:* Vasilenko Eduard <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [v6ops] Flash renumbering
>
>
>
> On Fri, 18 Sep 2020 at 20:47, Vasilenko Eduard <

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Sep 2020 10:43:29 -0400

On Sep 21, 2020, at 8:50 AM, Richard Patterson <[email-masked]> wrote:
> That is actually still just option a), and could result in packets being sourced from the wrong prefix in a multi-homed, multi-prefixed environment.

Exactly. Whether we are able, 37% of the time, to use a GUA that is no longer externally reachable on-link until such time as it is reachable, all we are really doing when we do this is postponing breakage. If we are lucky (I don’t know where that 37% number comes from, but let us say that it is valid) then when the external link comes back, we will see no glitch in the network. If we are unlucky (63% of the time) we will see broken connections.

What this actually looks like to users is flakiness. The network isn’t 100% reliable, and we don’t know why. If we have real need for intra-home connections, such as building controls, then this flakiness will have potentially serious consequences—wasted energy, lights that don’t operate, a slow but steady development of the belief that relying on the local network to operate reliably enough to be used in this way is unreasonable.

In order to avoid this, we need hosts to be smart about how they use the network. We need them to notice reachability problems quickly when they exist, and we need them to proactively maintain the freshness of data about the network.

I don’t mean to say that there aren’t use cases for really stable numbering. What I mean is that we can’t assume that all use cases can be addressed through the assumption that numbering will always be really stable. If we care to build a resilient network, one that survives the slings and arrows of outrageous fortune, the way to achieve that is not to try to artificially create a steady state and simply accept that when that attempt fails, things will fall apart.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Sep 2020 11:52:40 -0300

Eduard,

> CPE requirements have been developed in such a way that ULA is not needed.

Not sure what this means.

> If router does not claim itself as a default, - it does not mean that the router should deprecate prefixes distributed early.

The router needs to take care of the information is has distributed.

> Look carefully to below, specifically to "This advertisement is independent of having or not having IPv6 connectivity on the WAN interface.".

Not really. If a router does not have IPv6 connectivity on the WAN 
interface, then it presumably never got any prefixes to advertise, and 
hence would never advertise itself as a default router.

Then there's the question on what should happen when such WAN 
connectivity is lost -- and when it can be declared to be lost in the 
first place. The text you've quoted doesn't cover this.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Sep 2020 11:56:12 -0300

> Then 30% would be converted to 0.27%

I'm not sure what's the point of trying to rule out perfectly-valid 
deployment scenarios with statistics that are, for the most part, made 
up, and that are simply that: statistics -- that doesn't rule out a case 
where a router is connected to a switch.

If one doesn't want to support that common case, then I guess that 
should be said up front in IPv6 specs or deployment documents. Of 
course, one would never rule out such common deployment scenario.

Ironically, most of the folks participating on this mailing list employ 
such set up at home.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Sep 2020 11:57:46 -0300

On 21/9/20 08:09, Vasilenko Eduard wrote:
> Old GUA prefix could be used up to the point that WAN link would be 
> reconnected and GUA would be changed with 37% probability.

Wrong math. If your ISP is part of that 37%, then you have way more of 
37% probability that they prefix may change. -- that's my case, for 
instance.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Sep 2020 12:10:34 -0300

> d) continue sending old PIO, but inform hosts that this router is not 

In the context of RFC8028, that would seem *very* ill-advised to me.

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 15:24:08 +0000

Hi Richard,
Thanks. You have pointed to interesting case. I have investigated.
Unfortunately, RFC 8028 (1st hop router selection) has not considered what to do when router is up, but all uplinks are down.

I have not found anywhere else the similar instructions for router (as discussed below for CPE requirements: router life 0, prefixes advertised). It is fully legal by ND, just not recommended anywhere as a general case.

But I have found that host should be ready:
RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)
5<https://tools.ietf.org/html/rfc6724#section-5>.  Source Address Selection
Rule 5: Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA.

Ed/
From: Richard Patterson [mailto:[email-masked]]
Sent: 21 сентября 2020 г. 15:51
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Flash renumbering

On Mon, 21 Sep 2020 at 12:05, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,
I have sent in reply to Fernando details: RFC 7084 has chosen different option:
d) continue sending old PIO, but inform hosts that this router is not default anymore
IMHO: it is right!

L-4:   An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime [RFC4861] greater than zero if it has no prefixes configured or delegated to it.
Eduard
From: Richard Patterson [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 18 сентября 2020 г. 23:31
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Flash renumbering

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 15:30:09 +0000

Unfortunately, Multi-homing RFC 8028 has forgotten to consider this case.

> Sent: 21 сентября 2020 г. 18:11
> To: Vasilenko Eduard <[email-masked]>; Richard Patterson
> <[email-masked]>
> Cc: [email-masked]
> > I have sent in reply to Fernando details: RFC 7084 has chosen
> > different
> > option:

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 21 Sep 2020 15:35:07 +0000

Fernando,

Do you still claim that situation is not resolved for single-home CPE?

G-4:  By default, an IPv6 CE router that has no default router(s) on

         its WAN interface MUST NOT advertise itself as an IPv6 default

         router on its LAN interfaces.  That is, the "Router Lifetime"

         field is set to zero in all Router Advertisement messages it

         originates [RFC4861].

          delegated prefix(es) (and ULA prefix if configured to provide

          ULA addressing) using the "Route Information Option" specified

          in Section 2.3 of [RFC4191].  This advertisement is

          independent of having or not having IPv6 connectivity on the

          WAN interface.

Eduard

> Sent: 21 сентября 2020 г. 17:53

> To: Vasilenko Eduard <[email-masked]>; Fernando Gont

> <[email-masked]>

> > If router does not claim itself as a default, - it does not mean that the router

> should deprecate prefixes distributed early.

> > Look carefully to below, specifically to "This advertisement is independent of

> having or not having IPv6 connectivity on the WAN interface.".

> Not really. If a router does not have IPv6 connectivity on the WAN interface,

> then it presumably never got any prefixes to advertise, and hence would never

> advertise itself as a default router.

> Then there's the question on what should happen when such WAN connectivity

> is lost -- and when it can be declared to be lost in the first place. The text you've

> quoted doesn't cover this.

> e-mail: [email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Sep 2020 09:02:58 +1200

> On Mon, Sep 21, 2020 at 01:47:32PM +0200, Philip Homburg wrote:
[EV wrote:]
>>> SOHO is 2% compare to
>>> overall number of households. 

SOHO stands for "small office/home office". In practice that
includes all home networks where anybody does on-line banking or
purchasing or any other kind of personal business, so I don't even
begin to understand that "2%" figure. (It might be the case that 
only a few % of people claim a home office as a tax deduction,
but that has nothing to do with our topic.)

>>> This statistics is easily available

Exactly. We are not here to discuss how to make IPv6 as much like IPv4
as possible.

> Homenet demonstrated what IETF can do if looking beyond "today".

Exactly. That's our job here.

   Brian

---

From: Richard Patterson <[email-masked]>
Date: Tue, 22 Sep 2020 10:45:57 +0100

That presumes the end-host is multihomed with different interfaces to
different networks, rather than attached to a single network that is
multihomed.

On Mon, 21 Sep 2020 at 16:24, Vasilenko Eduard <[email-masked]>
wrote:

> Unfortunately, RFC 8028 (1st hop router selection) has not considered
> what to do when router is up, but all uplinks are down.
>
>
>
> I have not found anywhere else the similar instructions for router (as
> discussed below for CPE requirements: router life 0, prefixes advertised).
> It is fully legal by ND, just not recommended anywhere as a general case.
>
>
>
> 5 <https://tools.ietf.org/html/rfc6724#section-5>.  Source Address
> Selection
>
>    If SA is assigned to the interface that will be used to send to D and
> SB is assigned to a different interface, then prefer SA.
>
>
>
> Ed/
>
> *Sent:* 21 сентября 2020 г. 15:51
> On Mon, 21 Sep 2020 at 12:05, Vasilenko Eduard <

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Sep 2020 10:17:12 +0000

Hi Richard,
I have not understood you.
We are talking about the situation of uplink lost, then Router could continue sending old PIOs, but inform hosts that this router is not default anymore (router lifetime 0).

If it is the single router, then hosts could continue to use PIO for local communication. Nothing could be done for global connectivity (redundancy needed).

If it is multi-home on single link, then rule 5 of RFC 6724 would give the hint to all hosts to use PIO of other router.

Hence, problem of lost uplinks is resolved – just support of RFC 6724 is needed on hosts (rule 5) and RFC 7084 on routers (G-4 and L-3 requirements).
Why you claim that it should be separate links to separate routers?

Ed/
From: Richard Patterson [mailto:[email-masked]]
Sent: 22 сентября 2020 г. 12:46
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Flash renumbering

That presumes the end-host is multihomed with different interfaces to different networks, rather than attached to a single network that is multihomed.

On Mon, 21 Sep 2020 at 16:24, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,
Thanks. You have pointed to interesting case. I have investigated.
Unfortunately, RFC 8028 (1st hop router selection) has not considered what to do when router is up, but all uplinks are down.

Ed/

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Sep 2020 13:44:27 +0200

>    We are talking about the situation of uplink lost, then Router
>    could continue sending old PIOs, but inform hosts that this
>    router is not default anymore (router lifetime 0).

If it is a simple router with one uplink and one downlink it makes sense to
do so. If it isn't already in the CPE requirements then it make sense to do
so.

If there are multiple downstream subnets and the router announces a ULA,
then it becomes more complex because for the ULA, the router is still a
default router.

One option would be to change the priority of the router, but that would
make address section more complex in the case of a multi-homed network.

One option would be to move away from default routers and only have 
Route Information Options (RFC 4191).

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Sep 2020 13:19:58 +0000

Hi Philip,
Your comments are always very deep. Thanks!
Could we assume that "IPv6 link" is never disjoint? See in-line.
Eduard
> Sent: 22 сентября 2020 г. 14:44
> To: [email-masked]
> If it is a simple router with one uplink and one downlink it makes sense to do so.
> If it isn't already in the CPE requirements then it make sense to do so.
[Ed: ] It is in CPE requirements from Dec 2013 (requirements G-4 and L-3). It is very low probability that any CPE does not support RFC 7084.
> 
> If there are multiple downstream subnets and the router announces a ULA, then
> it becomes more complex because for the ULA, the router is still a default
> router.
[Ed: ] Good comment. But sorry it is even more complicated. I propose to simplify a little.
1. Following this logic we would come to the situation when default router announcement should be related to the fact that routing table has some particular route. It means: ND would become involved into routing. IMHO: it is too much.
2. I propose to disable "default router" in RA only If all uplinks are disconnected (the router could not play router primary role anyway). On-link ULA (or GUA) communication would not be affected (if L flag was set).
You would probably say in response that router is not just forwarding traffic to outside - it is additionally redirect and switch locally for the case when prefix was announced with L bit cleared.
Well, it is possible to fix by small ND update: 
- it is not prohibited by current ND specification to redirects and forward local traffic for the state when router announce 0 default router lifetime - probably should work for many current implementations.
- but host would probably not send traffic to router that is not default (even for traffic inside PIO).
What if we add the rule: host could always send traffic to the router (irrespective to router lifetime) if traffic is destined to node that is inside prefix announced by this router.
It is effectively different definition of "local": "router is always local for all hosts in the prefix announced by this router". Or in another way: "link is never disjoint"
?????
Then would be the nice solution for router that lost global connectivity. Irrespective: ULA or GUA.
> 
> One option would be to change the priority of the router, but that would make
> address section more complex in the case of a multi-homed network.
> 
> One option would be to move away from default routers and only have Route
> Information Options (RFC 4191).
[Ed: ] I am hesitant to qualify: was it right or wrong.
But I would like to point that this ND extension was not included into the current ND specification.
[Ed: ] It means that there were 6man consensus in 2007: it is too much to inject routing information into ND.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Sep 2020 15:59:15 +0200

> [Ed: ] Good comment. But sorry it is even more complicated. I
> propose to simplify a little.  1. Following this logic we would
> come to the situation when default router announcement should be
> related to the fact that routing table has some particular route.
> It means: ND would become involved into routing. IMHO: it is too
> much.  

Suppose that a router has 2 downstream subnets, fd00:0:0:1/64 and fd00:0:0:2/64
and one of these subnets has an extra router that connects to the internet
without knowing about these ULA prefixes. This is common in poor man's 
multi-homing

In that case hosts need to have some understanding of routing and RIOs, or
it becomes a very tricky game of default routers and preferences.

> 2. I propose to disable "default router" in RA only If all
> uplinks are disconnected (the router could not play router primary
> role anyway). 

In my example, if the router has no connection to the internet, but it does
connect to another subnet, does that mean that all of it's uplinks are
disconnected?

> On-link ULA (or GUA) communication would not be
> affected (if L flag was set).  You would probably say in response
> that router is not just forwarding traffic to outside - it is
> additionally redirect and switch locally for the case when prefix
> was announced with L bit cleared.  Well, it is possible to fix by
> small ND update:  - it is not prohibited by current ND specification
> to redirects and forward local traffic for the state when router
> announce 0 default router lifetime - probably should work for many
> current implementations.  - but host would probably not send traffic
> to router that is not default (even for traffic inside PIO).  What
> if we add the rule: host could always send traffic to the router
> (irrespective to router lifetime) if traffic is destined to node
> that is inside prefix announced by this router.  It is effectively
> different definition of "local": "router is always local for all
> hosts in the prefix announced by this router". Or in another way:
> "link is never disjoint" ????? Then would be the nice solution for
> router that lost global connectivity. Irrespective: ULA or GUA.

Instead we could have a RIO that covers the prefix...

> [Ed: ] I am hesitant to qualify: was it right or wrong.  But I
> would like to point that this ND extension was not included into
> the current ND specification.  [Ed: ] It means that there were 6man
> consensus in 2007: it is too much to inject routing information
> into ND.

RFC 4191 is standards track. I don't think it needs to be textually included
in ND.

---

From: [email-masked]
Date: Tue, 22 Sep 2020 16:58:06 +0200

> On 22 Sep 2020, at 15:59, Philip Homburg <[email-masked]> wrote:
> 

RFC7084 suggests that already.
To use RIO for ULA routing and router-lifetime for router to default.

All routers in the network obviously need to follow that rule.
If you have more than one, it's very likely that the answer is homenet.
Possibly combined with SADR. (and a different generation of hosts than we have now).

Best regards,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Sep 2020 17:05:19 +0000

Yes, routed network should have routing protocol - no way around. Standard protocols (ISIS, OSPF) look not very suitable for residential environment, hence homenet.
And yes, PA prefixes injected from different nodes into residential network would push to source routing, because Carrier would filter out source addresses of other Carrier. I hope it would be not SRv6 at least in this case.

But I have intention to show that SADR and homenet is not related to ND robustness.
It looks like it is possible to disconnect these problems and solve it separately.
One just need to think that router (or 2 routers) that is visible to hosts
do have all needed information (by other means)
then we could concentrate what they should do properly in ND.

Ed/
> From: v6ops [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 22 сентября 2020 г. 17:58
> To: Philip Homburg <[email-masked]>
> Cc: [email-masked]

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 22 Sep 2020 17:19:39 +0000

Hi Philip,
My proposal is still looks reasonable (at least for me).
I am not sure that I have understood you comment right, because it was not pointed where is host that should have difficulties.
But let me generalize:
Routed network in the apartment needs routing to inform all default gateways about external network conditions (if any prefix to any carrier is not available anymore - all routers should know this).
It would give every router the information: is it isolated or not?
Then we would have again the situation when we could discuss just ND on last hop.
Then it is possible not to use ND for routing information.
ND is complex enough without RFC 4191. If it is possible to avoid this complexity - it is better to avoid.
Use cases for RFC 4191 has been shown inside - is anybody would like to use it - fine.
IMHO: let's keep RFC 4191 as an optional.
IMHO2: use cases for RFC 4191 not powerful enough to gain any considerable market share.
Eduard
> Sent: 22 сентября 2020 г. 16:59
> To: [email-masked]
> > > If there are multiple downstream subnets and the router announces a
> > > ULA, the
> > n
> > > it becomes more complex because for the ULA, the router is still a
> > > default router.
> > [Ed: ] Good comment. But sorry it is even more complicated. I propose
> > to simplify a little.  1. Following this logic we would come to the
> > situation when default router announcement should be related to the
> > fact that routing table has some particular route.
> > It means: ND would become involved into routing. IMHO: it is too much.
> 
> Suppose that a router has 2 downstream subnets, fd00:0:0:1/64 and
> fd00:0:0:2/64 and one of these subnets has an extra router that connects to the
> internet without knowing about these ULA prefixes. This is common in poor
> man's multi-homing
> 
> In that case hosts need to have some understanding of routing and RIOs, or it
> becomes a very tricky game of default routers and preferences.
> 
> > 2. I propose to disable "default router" in RA only If all uplinks are
> > disconnected (the router could not play router primary role anyway).
> 
> > On-link ULA (or GUA) communication would not be affected (if L flag
> > was set).  You would probably say in response that router is not just
> > forwarding traffic to outside - it is additionally redirect and switch
> > locally for the case when prefix was announced with L bit cleared.
> > Well, it is possible to fix by small ND update:  - it is not
> > prohibited by current ND specification to redirects and forward local
> > traffic for the state when router announce 0 default router lifetime -
> > probably should work for many current implementations.  - but host
> > would probably not send traffic to router that is not default (even
> > for traffic inside PIO).  What if we add the rule: host could always
> > send traffic to the router (irrespective to router lifetime) if
> > traffic is destined to node that is inside prefix announced by this
> > router.  It is effectively different definition of "local": "router is
> > always local for all hosts in the prefix announced by this router". Or
> > in another way:
> > > One option would be to change the priority of the router, but that
> > > would mak
> > e
> > [Ed: ] I am hesitant to qualify: was it right or wrong.  But I would
> > like to point that this ND extension was not included into the current
> > ND specification.  [Ed: ] It means that there were 6man consensus in
> > 2007: it is too much to inject routing information into ND.
> 
> RFC 4191 is standards track. I don't think it needs to be textually included in ND.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Sep 2020 09:09:03 +1200

On 22-Sep-20 21:45, Richard Patterson wrote:
> On Mon, 21 Sep 2020 at 16:24, Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>     Hi Richard,
>> 

As Richard says, a case with one router connected to the Internet is of no interest
to RFC8028, whatever the state of the uplinks.

If you have uplinks from more than one router, RFC8028 is useful. If one of those uplinks gets flash-renumbered, RFC8028 will react when and only when the relevant RA/PIO is updated. If I'm not mistaken, that is exactly when SLAAC will react too.

When all uplinks are down, who cares? (That's when you would be happy to have a valid ULA prefix, of course. Using GRUAs for internal traffic is not robust in that case.)

(You could argue that RFC8028 should have mentioned renumbering consisderations and ULA considerations, but I think there is very little to say.)

   Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 23 Sep 2020 08:23:32 +0000

Hi Brian,
It is too later to discuss 8028. But yes, it should discuss what if
1) uplink is down
2) all uplinks are down
Because multi-homing has been organized to improve resiliency. Then it was logical to analyze resiliency fully.
Eduard
> Sent: 23 сентября 2020 г. 0:09
> To: Richard Patterson <[email-masked]>; Vasilenko Eduard
> <[email-masked]>
> Cc: [email-masked]
> different networks, rather than attached to a single network that is multihomed.
> >
> > On Mon, 21 Sep 2020 at 16:24, Vasilenko Eduard
> As Richard says, a case with one router connected to the Internet is of no
> interest to RFC8028, whatever the state of the uplinks.
> 
> If you have uplinks from more than one router, RFC8028 is useful. If one of
> those uplinks gets flash-renumbered, RFC8028 will react when and only when
> the relevant RA/PIO is updated. If I'm not mistaken, that is exactly when SLAAC
> will react too.
> 
> When all uplinks are down, who cares? (That's when you would be happy to
> have a valid ULA prefix, of course. Using GRUAs for internal traffic is not robust
> in that case.)
> 
> (You could argue that RFC8028 should have mentioned renumbering
> consisderations and ULA considerations, but I think there is very little to say.)
> 
>    Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Sep 2020 14:17:22 +0200

> My proposal
> is still looks reasonable (at least for me).  I am not sure that
> I have understood you comment right, because it was not pointed
> where is host that should have difficulties.  But let me generalize:
> Routed network in the apartment needs routing to inform all default
> gateways about external network conditions (if any prefix to any
> carrier is not available anymore - all routers should know this).
> Then we would have again the situation when we could discuss just
> ND on last hop.  Then it is possible not to use ND for routing
> information.  ND is complex enough without RFC 4191. If it is
> possible to avoid this complexity - it is better to avoid.  Use
> cases for RFC 4191 has been shown inside - is anybody would like
> to use it - fine.  IMHO: let's keep RFC 4191 as an optional.  IMHO2:
> use cases for RFC 4191 not powerful enough to gain any considerable
> market share.  

Having a network that uses a routing protocol is certainly desirable but
I doubt that it is realistic at the moment.

I.e., if we are talking about networks where users just plug in devices
but don't configure anything, then in theory you can have a routing protocol.
In practice, we basically have no deployment.

For example, just about all ISPs see a CPE as a host. ISP's don't speak 
routing protocols with CPEs. The same way, CPEs see all downstream devices
as hosts and don't speak routing protocols.

We know that this creates issues with DHCPv6 PD, but this is the way it is
at the moment.

Homenet has the potential to change this (within a customer network), but so
far homenet does not have a lot of traction.

So one option is to assume that all routers have a consistent view of the
network. That certainly makes things easy for hosts, but this is not the
reality at small networks.

The alternative is that routers inform hosts about what they know. That makes
life harder for hosts, but is a lot easier to deploy.

In addition to that, some hosts, like phones, tend to be connected to two
networks. So for those devices it is even more essential that they have a
good view on the local network structure. 

So in my opinion, we should move to a model where routers announce what they
know as RIOs and hosts take the collection of RIOs into account for address
and next hop selection.

---

From: [email-masked]
Date: Wed, 23 Sep 2020 15:16:22 +0200

Philip,

> know as RIOs and hosts take the collection of RIOs into account for address

Homenet looked at many options for simplifying ways of supporting arbitrary topologies or more complex scenarios than a single router.
I believe homenet looked at all the requirements and came up with the best solution possible.

Redoing this with ND and the resultign implementation of a spanning tree in DHCP PD/ND doesn't sound tempting. At all.

Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Sep 2020 15:33:08 +0200

>Redoing this with ND and the resultign implementation of a spanning tree 
>in DHCP PD/ND doesn't sound tempting. At all.

I fully agree that we should not try to do a spanning tree in DHCP. However,
most home setups tend to have a tree structure. And hierarchical routing is
easy enough to implement.

Does homenet really solve the phone problem I described? Suppose we have a
network with multiple subnets. Assume the connection to the internet
is down.

The phone can easily use its radio link to connect to the internet, but how
does the phone know the extent of the local network? Does the phone assume
that if you have ULA /64 then the router that announced the PIO can also handle
traffic for the ULA /48? 

What if the local network actually has a static prefix and the routers continue
to send PIOs with a global prefix?

---

From: [email-masked]
Date: Wed, 23 Sep 2020 15:40:31 +0200

Philip,

> easy enough to implement.

They only have a tree structure until the home owner or his kids plug in the red wire into the yellow hole.

> to send PIOs with a global prefix?

The phone would then act as a new homenet border gateway. Particpiate in routing on the LAN side, and offer a new addressing block to the homenet.
It doesn't care about the PIOs of other routers as such.

Each host will then appear multi-prefix multi-homed. One prefix from the phone connection and one prefix from the regular ISP (that's down).

So yes, homenet solves this. Although there are clearly lacking implementations here. Both on phones and on hosts.
Note that this also solves the flash renumbering case.

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Sep 2020 16:01:22 +0200

> They only have a tree structure until the home owner or his kids
> plug in the red wire into the yellow hole.

I'm not sure if this is guaranteed to fail. But if it does, it would create a
nice market demand for homenet.

There is no homenet for IPv4, nor do consumer ethernet switches run SPF by
default, so it seems that this may not be such a big issue.

> The phone would then act as a new homenet border gateway. Particpiate
> in routing on the LAN side, and offer a new addressing block to
> the homenet.  It doesn't care about the PIOs of other routers as
> such.

Not everybody has an unlimited data plan. And in places we people do have
unlimited data, do all phones of all people in the room announce themselves
as homenet border gateways?

Do phones receive a suitably large prefix these days to number the local
networks. Last thing I knew was that phone companies didn't want to do
DHCP PD for some reason.

---

From: [email-masked]
Date: Wed, 23 Sep 2020 17:33:08 +0200

Philip,

> nice market demand for homenet.

not sure what point you are trying to make.
it's a fact that unless you have protocol protections in place, it is possible to make loops in networks with more than one device.

> default, so it seems that this may not be such a big issue.

homenet supports both v4 and v6.

> networks. Last thing I knew was that phone companies didn't want to do

I think this is a somewhat disingenuous way to argue.
The question was "Does homenet really solve the phone problem I described?".

Yes, it does, but if you want rather to talk about how people currently use their phones as backup, independent of Internet protocol standardisation, we can of course do that.
In e.g. my case each family member uses their own phone and tethers whatever devices they need. So good bye home network in those cases.
(which would be an indication that we should stop considering the LAN as a special case, with e.g. MDNS).

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Sep 2020 14:28:12 +0200

> not sure what point you are trying to make.  it's a fact that unless
> you have protocol protections in place, it is possible to make
> loops in networks with more than one device.

I'm saying that it not clear what effect a loop will have on DHCP PD.

> homenet supports both v4 and v6.

I tried to say that without homenet, existing IPv4 networks are fine.

It could be that people quickly manage to remove the link that causes the loop
or that the impact of a loop is not as serious as portrayed.

> I think this is a somewhat disingenuous way to argue.  The question
> was "Does homenet really solve the phone problem I described?".

If the homenet answer to the question 'how does a phone reach a 
disconnected local network' is that the phone has to become the uplink of the 
network, then I can see plenty of people trying to work around that.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Sep 2020 08:37:44 -0400

> I'm saying that it not clear what effect a loop will have on DHCP PD.

We studied this. I don’t think there’s a risk of a loop. The problem is that routing might be pessimal, and the system is not resilient in the face of unplug/replug events. If we assume that PD and relays set up routes, we’re going to always have routes that lead to the top of the tree. If a router has multiple links, it will only ever route packets northward, or to links to which it is directly connected. This is not ideal, and doesn’t work for every topology, but I don’t think it forms loops. You can’t use RAs to advertise routes to non-adjacent links.

> I tried to say that without homenet, existing IPv4 networks are fine.

Existing IPv4 home networks aren’t fine. If you take a bunch of IPv4 home routers and plug them together, every host will be able to reach the cloud, but intra-home communication will not work in most cases.

---

From: [email-masked]
Date: Thu, 24 Sep 2020 15:05:20 +0200

> We studied this. I don’t think there’s a risk of a loop. The problem is that routing might be pessimal, and the system is not resilient in the face of unplug/replug events. If we assume that PD and…

What use of DHCP PD are you referring to here?
DHCP PD is only defined to work across administrative boundaries.
"Hierarchical DHCP PD"?

Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Sep 2020 17:05:50 +0200

>DHCP PD is only defined to work across administrative boundaries.

In practice, CPEs offer DHCPv6 PD to downstream routers even if there is no
clear administrative boundary.

---

From: [email-masked]
Date: Thu, 24 Sep 2020 17:18:10 +0200

> clear administrative boundary.

Right, and it's failure cases have been discussed before.

I see Ted is on an 8 year long loop. ;-)
https://mailarchive.ietf.org/arch/msg/homenet/oOZ8a1eEYkc0WoTuq917dzOn-fc/

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Sep 2020 11:20:58 -0400

Right, if your cpe router gets a /56 it can do dhcp internally. The network can be layered by having routers that done have subdividable delegations forward the PD request north and the answer back south. There is nothing in the DHCPv6 rfc about PD only working across admin boundaries. 

> On Sep 24, 2020, at 11:06, Philip Homburg <[email-masked]> wrote:
> 
> 
>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Sep 2020 11:23:20 -0400

> https://mailarchive.ietf.org/arch/msg/homenet/oOZ8a1eEYkc0WoTuq917dzOn-fc/

Hey, don’t put it all on me. You were in that conversation too. History has shown pretty clearly that the complex and wonderful solution is a failure. PD is really simple, and not as good. But you can get CPE routers that do it.

---

From: [email-masked]
Date: Thu, 24 Sep 2020 21:32:09 +0200

> Hey, don’t put it all on me. You were in that conversation too. History has shown pretty clearly that the complex and wonderful solution is a failure. PD is really simple, and not as good. But you…

But perhaps you could have taken a little more of the learnings from those homenet discussions to heart.
I don't think there is any purpose of rehashing that debate. Homenet had a very good look at it and reached it's conclusions.

People from Cablelabs were the ones who hashed out in most detail how DHCPv6 PD could work in such a scenario.
At least draft-gmann-homenet-relay-autoconf, possibly other drafts too.

Ole