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

[James R Cutler <[e-mail]>]

> On Apr 8, 2020, at 5:24 PM, Fernando Gont <[e-mail]> 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.