[v6ops] Flash renumbering

[Vasilenko Eduard <[e-mail]>]

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: 10 сентября 2020 г. 20:45
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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