Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Andrew Yourtchenko <[e-mail]>]

On Sun, 8 Dec 2013, Mark ZZZ Smith wrote:

> People who really don't like RAs can switch them off and use static configuration. They can also switch off neighbor discovery and manually configure that to eliminate ND multicasts, and configure static multicast group membership to eliminate MLD multicasts. If their complaint is RA multicasts (which can be up to 30 minutes apart per the RFC advertisement interval), then I think their actual complaint is or should be all multicasts.
>
> The point of RAs and DHCPv6 is automated configuration. To make automation work reliably you need to minimise and ideally remove options and parameters, because options and parameters can require human beings to make choices and to get them right, and that creates opportunities for human error. This includes errors in implementations of mechanisms to negotiate methods, options or parameters (see issues with misinterpretation of and between the M/O RA and PIO A options in "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-liu-bonica-dhcpv6-slaac-problem, as an example.)
>
> Technical people like choice and flexibility, because I think they think about "what ifs" - "what if I was in this situation, what if I was in that situation, and what would I like to tweak to make it work." Non-technical end-users (usually our customers or at least our relatives), who far surpass us in numbers, don't care, shouldn't care and shouldn't have to care. They just want it to work, work reliably, and don't want to have to engage technical people to either make it work or call in assistance if it doesn't work or stops working. Choices, options and parameters make things more complex and therefore more fragile and less robust.
>
> We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be wrong. DHCPv6 for default gateways would in the DHCPv6 relay scenario would require human entry of that information, creating the opportunity for human error, and potential conflict with what RAs are announcing.

All very good points.

I agree with the majority of them.

Thanks a lot for the discussion.

--a