Subject: draft-gont-6man-slaac-renum (was: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes)

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 17:57:58 -0300

On 8/4/20 17:46, [email-masked] wrote:
>>> Sorry, I don't see the gap.
>>> All deployments I am aware of use the remote-id / option-82 equivalent option to identify subscribers.
>>> Most operators are a lot more clueful about this than us here.
>>>
>>> Think of PD as a contract. The ISP promises to lease the prefix to the subscriber for the time stated.
>>> The ISP can still do flash renumbering (although that's likely to induce a customer call) in two ways.
>>> One, just ignore it's earlier promise and give the subscriber a new prefix (which introduces all the problems Fernado wants to use prefix lifetimes to solve), or it can include the old prefix with lifetimes 0 (violating it's earlier promise, but at least being explicit) and advertise a new prefix.
>>
>> I’m trying to figure out why this is such an utterly unsatisfying response.  Yes, I get that in the ideal case, which is what you are describing here, there is no problem.  But you are missing _all_ of the edge cases.  And you’re assuming that things on a home network are a lot cleaner than I think is safe to assume.
>>
>> So yes, in the case you describe, where everything is done correctly, there is no problem.  I would not expect to see the persistent prefix problem routinely.  But I think it’s worth designing for—there are a lot of reasons why renumbering might happen in a way that is not as clean as you’re saying it should be, and we ought to handle it gracefully when it happens.
> 
> s/ideal/typical/
> 
> This small problem has a couple of simple solutions:
>   - change to an ISP that operate better

Seriously? Please think twice. (Hint: in many countries there's only one 
ISP -- welcome to the real world).

>   - the CPE sends back an ICMP in these cases, it's just for the host to act upon it

We devoted a section to this, such that we can save electrons in the 
emails: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.1

> A host that has multiple addresses with different reachability is typical in IPv6. Every host is essentially multihomed. With ephemeral addresses.
> The case you describe above is not any different from that. The host-stack/application needs to react to the connection not making progress and try a different SA/DA pair.
> Similarly on initial connection.

We're fine with you boiling any ocean you want.

> You don't solve that problem by tweaking prefix lifetimes.

As Ted noted, getting rid of insanely long prefixes is part of that.

Basic stuff that can make a fresher prefix be used, and old addresses to 
be garbage collected.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 18:01:52 -0300

On 8/4/20 17:57, Fernando Gont wrote:
>>>> All deployments I am aware of use the remote-id / option-82 
>>>> equivalent option to identify subscribers.
>>>> One, just ignore it's earlier promise and give the subscriber a new 
>>>> prefix (which introduces all the problems Fernado wants to use 
>>>> prefix lifetimes to solve), or it can include the old prefix with 
>>>> lifetimes 0 (violating it's earlier promise, but at least being 
>>>> explicit) and advertise a new prefix.
>>>
>>> I’m trying to figure out why this is such an utterly unsatisfying 
>>> response.  Yes, I get that in the ideal case, which is what you are 
>>> describing here, there is no problem.  But you are missing _all_ of 
>>> the edge cases.  And you’re assuming that things on a home network 
>>> are a lot cleaner than I think is safe to assume.
>>>
>>> So yes, in the case you describe, where everything is done correctly, 
>>> there is no problem.  I would not expect to see the persistent prefix 
>>> problem routinely.  But I think it’s worth designing for—there are a 
>>> lot of reasons why renumbering might happen in a way that is not as 
>>> clean as you’re saying it should be, and we ought to handle it 
>>> gracefully when it happens.
>>
>> s/ideal/typical/
>>

To add to that, in many countries, as soon as you get away from major 
cities, the same is true.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 18:24:46 -0300

Hi, Bernie,

On 8/4/20 16:44, Bernie Volz (volz) wrote:
> 
> Ole, perhaps if there was a concrete proposal for an alternative approach, we would go there? So maybe this debate needs to be put on hold a bit to allow alternative approaches to come about. Though as stated earlier, some of this has been discussed for a while and I don't think there are any yet?

We have discussed this for over a year now. Ole has repeatedly argued 
that this is not a problem, or that this is not a problem worth solving, 
because the networks that face these problems suffer from the 
incompetence/lack of knowledge of their admins/operators (even after 
multiple-statements from operators on why these scenarios take place). 
He deems these occurrences as rare, while concrete data and anecdotal 
evidence suggests 40% of deployments doing dynamic addresses. In such 
scenarios, he argues that the user should switch ISPs, when in so many 
different places I know of, there is no other ISP to switch to.

Now, the topic has been debated for over a year now. Nobody prevented 
anybody to come up with something better.. and as you correctly note, 
nobody did.

On our side, we kept working on this. A few folks (Jen and Philip to 
name a few) found flaws in our early proposal, and suggested 
improvements, which we did our best to incorporate.

We also discussed this with as many operators (this was discussed, IIRC, 
in RIPE, UKNOF, LACNOG..) and developers as possible, and received very 
positive feedback. And we also took the time to produce implementations 
of some of the improvements we propose (please see: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#section-6), 
or discuss this with developers that might want to improve SLAAC.

Maybe in order to honor the motto of "we reject kings", it would be time 
for the working group to be polled for adoption of this document. 
Certainly not to rubber-stamp it, but to continue polishing and 
improving it where/as appropriate.

Thanks,

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 9 Apr 2020 01:35:59 +0400

On Thursday, April 9, 2020, Fernando Gont <[email-masked]> wrote:

>> Ole, perhaps if there was a concrete proposal for an alternative
>> approach, we would go there? So maybe this debate needs to be put on hold a
>> bit to allow alternative approaches to come about. Though as stated
>> earlier, some of this has been discussed for a while and I don't think
>> there are any yet?
>>
>
> We have discussed this for over a year now. Ole has repeatedly argued that
> this is not a problem, or that this is not a problem worth solving, because
> the networks that face these problems suffer from the incompetence/lack of
> knowledge of their admins/operators (even after multiple-statements from
> operators on why these scenarios take place). He deems these occurrences as
> rare, while concrete data and anecdotal evidence suggests 40% of
> deployments doing dynamic addresses. In such scenarios, he argues that the
> user should switch ISPs, when in so many different places I know of, there
> is no other ISP to switch to.

This will be the case of many isps in Africa who believe that customers
should not get static IPs. Their concern is that customers will host
servers at home.

I've heard of isps in Europe or the us having offers for static IPs. This
is not the case for mauritius despite making multiple requests for it.

> On our side, we kept working on this. A few folks (Jen and Philip to name
> a few) found flaws in our early proposal, and suggested improvements, which
> we did our best to incorporate.
>
> positive feedback. And we also took the time to produce implementations of
> some of the improvements we propose (please see:
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#section-6), or
> discuss this with developers that might want to improve SLAAC.
>
>
> for the working group to be polled for adoption of this document. Certainly
> not to rubber-stamp it, but to continue polishing and improving it where/as
> appropriate.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: James R Cutler <[email-masked]>
Date: Wed, 8 Apr 2020 18:13:14 -0400

> On Apr 8, 2020, at 5:24 PM, Fernando Gont <[email-masked]> wrote:
> 
> We have discussed this for over a year now. Ole has repeatedly argued that this is not a problem, or that this is not a problem worth solving, because the networks that face these problems suffer from the incompetence/lack of knowledge of their admins/operators (even after multiple-statements from operators on why these scenarios take place). He deems these occurrences as rare, while concrete data and anecdotal evidence suggests 40% of deployments doing dynamic addresses. In such scenarios, he argues that the user should switch ISPs, when in so many different places I know of, there is no other ISP to switch to.

The suggestion to switch ISPs is ludicrous if the ‘ISP’ is a corporate network. 

Yet, I seldom hear any real business considerations. In my experience, large corporate networks maintain a division of both responsibility between routing configuration and end system configuration. Every ‘router engineer’ I have worked with had to serve his management’s desire for robust and reliable routing of packets in a manner completely orthogonal to end system configuration. Router firmware and configuration updates are considered to be a business risk to be minimized so adding miscellaneous options ND/RA is strongly discouraged. Conversely, management of services and end systems rarely even consider how packets are routed. Rather, services like print, ntp, DNS, email, file servers, and, even Windows Domain Servers are managed with a view to supporting business functions. Often, the business requirements of various internal divisions only overlap in the common routing domain and enterprise DNS root servers. Division management is often by local fiefdom with minimal concern for other divisions so local changes and optimizations are done independently, often at the whim of the current division leader.

The usual dialog between these two ‘worlds’ revolves around the number of ethernet jacks and existence of DHCP forwarders with an occassional foray into capacity planning. So the existence of two tool sets to meet the differing needs should not be unexpected. RA’s should provide all necessary routing information for stateless configuration of adjacent end systems. Differently, DHCPv6 and DHCP-PD are driven by business allocation of resources and must be allowed to exist in parallel to meet business requirements. Mixing router configuration and operation requirements with end system configuration and operation requirements by enforcing a single multi-tool for all may simplify life for some particular set of technicians, but in the end, it will make corporate management more complicated and expensive that it already has become.