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

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Andrew Yourtchenko <[e-mail]>
> To: Bernie Volz (volz) <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: Sunday, 8 December 2013 5:44 PM
> Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 
> On Sun, 8 Dec 2013, Bernie Volz (volz) wrote:
> 
>>>  While I would like to see routing options added to DHCP for a variety 
> of reasons (mostly political and organizational rather than technical), I do not 
> for one second believe that eliminating RAs is useful in any significant 
> proportion of environments.
>> 
>>  Yeah, I don't think they should go either.
> 
> Again, I am *not* proposing to deprecate them.
> 
> I'm proposing to decriminalize the thinking of allowing to not use them.


Firstly, please stop using hyperbolic words such as "decriminalize" unless you actually mean them. I'd start to doubt your ability to create a balanced document if you think people advocating for leaving things as they are to be accusing others who want to change things to be criminals. It makes you sound like you're extremely subjective about this topic, and therefore will end up with an agenda to distort arguments against doing it to support your view.

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.

Regards,

Mark.
 

> --a
> 
>> 
>>  - Bernie
>> 
>>  -----Original Message-----
>>  From: v6ops [mailto:[e-mail]] On Behalf Of Owen DeLong
>>  Sent: Saturday, December 07, 2013 4:23 PM
>>  To: Andrew Yourtchenko (ayourtch)
>>  Cc: [e-mail]
>>  Subject: Re: [v6ops] New Version Notification for 
> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
>> 
>>>>  I don't think RAs are the single reason some people are 
> resisting deploying IPv6 at all. I think some people are resisting deploying 
> IPv6 because it needs to do one or both of two things for them - solve a 
> foreseeable problem that will effect them, or provide a tangible benefit. If it 
> won't do either of those things, then they don't currently see any value 
> from the effort involved. What are foreseeable problems or tangible benefits is 
> completely up to the perspective of the decision maker. Eventually they'll 
> see value in it, and deploy it. In some cases, some people who could deploy IPv6 
> may never see any value in deploying it, so they never will.
>>> 
>>>  It's not binary. You can represent as a number both the amount of 
> pain that a given problem (or set of problems) causes, and the amount of pain 
> that the big change in the network like adding a new protocol causes.
>>> 
>>>  As soon as the first number is smaller than the second one, nothing 
> gets done.
>>> 
>>>  Judging by the feedback I get from talking with people, even the 
> possibility of eventually eliminating RAs from their network might make the 
> second number smaller for a nontrivial amount folks, whose situation dictates 
> the DHCPv6.
>>> 
>> 
>>  I find this very hard to believe. RAs are virtually automatic and free in 
> 99% of cases. If you feel the need to tune them, then that's pretty trivial 
> if you know enough to tune them properly.
>> 
>>  If you don't know what you are doing, then you can really mess yourself 
> up with RA tweaking that you shouldn't be doing.
>> 
>>  However, I do not advocate IETF breaking the internet just to prevent 
> people from breaking their LANs out of ignorance.
>> 
>>>>  There is no single answer to why people might resist deploying 
> IPv6, no single solution, and things that motivate people to deploy or not IPv6 
> may have nothing to do with how IPv6 itself works.
>>>> 
>>>> 
>>>> 
>>>>>  I think in this discussion are again getting into the argument 
> of "the best solution" instead of trying to collect the properties of 
> the RA and DHCP.
>>>>>  My position is that single best solution does not exist, 
> because
>>>> 
>>>>>  everyone's problems are slightly different. So, rather than 
> preaching for everyone to adopt the single solution which is the best in one 
> scenario and suboptimal in the other, we should be engineering a way to be able 
> to apply different solutions in different circumstances without the overhead of 
> double work.
>>>> 
>>>>  A single solution that solves most cases is better than two 
> different,
>>> 
>>>  That's the point. The single solution that solves most cases, does 
> not exist. For a good part of the cases, you need to apply two solutions at 
> once. Justifiably, the question is "why", given in legacy IP they did 
> not need to do that.
>> 
>>  Actually, the problem is that people have conflated two different problems 
> and like to pretend that they are one.
>> 
>>  In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem.
>> 
>>  RAs solve the problem of telling a host which routers are available on 
> link.
>>  RAs also sort of solve the problem of dynamic host configuration (address, 
> RDNS servers, DNS Search list)
>> 
>>  For better or worse, to keep RAs very light weight, they do not provide a 
> complete or robust solution to host autoconfiguration.
>>  For that, you need DHCPv6 which is a protocol designed to do host 
> configuration.
>> 
>>  While I would like to see routing options added to DHCP for a variety of 
> reasons (mostly political and organizational rather than technical), I do not 
> for one second believe that eliminating RAs is useful in any significant 
> proportion of environments. Even if we made the changes you are proposing, 
> eliminating RAs would be unlikely in the vast majority of circumstances, at 
> least for many years to come.
>> 
>>  Owen
>> 
>> 
>>  _______________________________________________
>>  v6ops mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/v6ops
>> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>