IPv6 RA vs DHCPv6 - The chosen one?

Mohacsi Janos mohacsi at niif.hu
Tue Dec 20 08:08:07 UTC 2011



On Mon, 19 Dec 2011, Owen DeLong wrote:

> Different operators will have different preferences in different environments.
>
> Ideally, the IETF should provide complete solutions based on DHCPv6 and
> on RA and let the operators decide what they want to use in their environments.

Agree. Selection also influenced by the availability of the particular 
feature on a particular environments and habits of the operators.
 	Best Regards,
 		Janos Mohacsi

>
> Owen
>
> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote:
>
>> Hi,
>>
>> IPv6 devices (routers and hosts) can obtain configuration information
>> about default routers, on-link prefixes and addresses from Router
>> Advertisements as defined in   Neighbor Discovery.  I have been told
>> that in some deployments, there is a strong desire not to use Router
>> Advertisements at all and to perform all configuration via DHCPv6.
>> There are thus similar IETF standards to get everything that you can
>> get from RAs, by using DHCPv6 instead.
>>
>> As a result of this we see new proposals in IETF that try to do
>> similar things by either extending RA mechanisms or by introducing new
>> options in DHCPv6.
>>
>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
>> DHCPv6 to do what RA does. And now, we have
>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
>> the NTP information that is currently done via DHCPv6.
>>
>> My question is, that which then is the more preferred option for the
>> operators? Do they prefer extending RA so that the new information
>> loaded on top of the RA messages gets known in the single shot when
>> routers do neighbor discovery. Or do they prefer all the extra
>> information to be learnt via DHCPv6? What are the pros and cons in
>> each approach and when would people favor one over the other?
>>
>> I can see some advantages with the loading information to RA since
>> then one is not dependent on the DHCPv6 server. However, the latter
>> provides its own benefits.
>>
>> Regards,
>> Ravi D.
>
>
>




More information about the NANOG mailing list