Re: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue

[Mark Andrews <[e-mail]>]

> On 10 Nov 2020, at 15:27, Joel M. Halpern <[e-mail]> wrote:
> 
> Ted, I'm not an operator, but I sure find that a very dismissive response.  (I doubt that was your intent)
> There are operational complexities to adding a new kind of server into an operational network.
> (Side note, we are in this case not talking about the IT department.  We are talking about the operational efforts of an ISP.)
> 
> When operators tell us they have constraints, it is fair for us to inquire as to the nature of the constraints.  It is not fair for us to say "you MUST make different operational choices."
> 
> We as a community decided that there were going to be two paths to operating an IPv6 network.  (SLAAC and DHCP, let's not worry about other corner cases.)  When we made that choice, we should ahve recognized that there were operational implications, complications, and trades inherent in that decision.  Just as we need to (and usually have) listened when operators have asked for DHCP capabilites that they need, we should be listening when operators tell us there are RA / SLAAC capabilities they need.

RA has the O bit for a reason.  It was so every client didn’t have to code 2 solutions for getting information.  It was designed to be used with a minimal DHCPv6 server in the router.  A server that didn’t hand out addresses.  A server that didn’t need to save state.  Instead we now have every device having to be coded with 2 solutions (RA + DHCPv6).  The same data that would have been handed out in a DHCPv6 packet is now being handed out in a ICMPv6 packet.  The router is still returning the information to the client.  The only difference from the routers perspective is that it has opened one socket to listen for ICMPv6 traffic instead of 2 sockets (ICMPv6 + DHCPv6).  It still has to encode the data.  It still has to be configured with the data it is handing out.  The big difference is every other device on the planet now has to support 2 ways to get the same information.

I suspect most of this came down to operators and equipment vendors not realising how the O bit was supposed to be implemented.  If you think you have to run a DHCPv6 servers with failover that is keeping state that has to be co-ordinated with the router just to hand out nameserver addresses, etc. then yes a complaint was valid, but that was never the intention.  It could be done with seperate machines for the DHCPv6 servers but it didn’t have to be done that way.

> In particular, Cameron has been very forthcoming and clear about what he wants to deliver and what his operational constraints are.  Implying he should just use DHCP anyway seems an odd answer.
> 
> Quite a number of us have said over the years that we want operators to participate more, and we want to understand what they need.  We may or may not decide to make changes (listening does not mean agreeing).  But we really should be paying attention to what the range of operators are telling us.

> I hope that my notes to Gyan have been questioning and done dismissing.  Apologies if they have come off otherwise.
> 
> Yours,
> Joel
> 
> 
> On 11/9/2020 10:31 PM, Ted Lemon wrote:
>> On Nov 9, 2020, at 10:15 PM, Ca By <[e-mail] <mailto:[e-mail]>> wrote:
>>> The force required to break the current stasis is more than i have, if i must use dhcpv6.  Again, many years of proof. 
>> So, to summarize, the problem is that you can’t get your IT department to install DHCPv6 servers?
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]