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

["Fred Baker (fred)" <[e-mail]>]

>>> 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.

Speaking as a pretty random individual.

First, I don't think that the statement "they never will" holds. They indeed never will while the equation remains the same - IPv6 costs them something and doesn't give them a measurable ROI, or enough of one. The premise of an adoption curve is that the equation indeed changes - the cost of not deploying eventually exceeds the cost of deploying, and as a result people deploy. The question here is not the current state, it's the eventual state. The data tells me that the equation is slowly changing. If we don't believe that, we're all wasting our time.

As to the RA vs DHCP dispute, I think it's largely religious. If you live in, or choose to live in, an RA/SLAAC world, and the information elements in the RA meet your needs, by all means use it. If DHCP does something an RA doesn't, and your network needs it, you're going to use DHCP for at least that purpose. To the extent they are functionally interchangeable  - you can get an address from either, or advertise the address of the DNS server, or etc -  its the cook's choice. 

The primary argument for the RA, from my perspective, is that it identifies a preferred router on a LAN for a prefix that it is advertising, and in the unusual case in which a large number of devices simultaneously join a subnet (such as when the subnet is first turned up or a network is renumbered), or if some other attribute needs to be assigned to every device on a LAN in multicast fashion, it has improved scaling characteristics. The primary argument for DHCP is control - you can say what you mean to an individual system and have that not need to be the same as you say to another, and if you have a requirement to know for sure what system is using what address (for example for Source Address Verification), you own the table.

If it's your network, it will be about the policies your network follows. There is no inherently "right" answer about policy, and as a result there is no inherently "right" answer about the implementation of policy.