IPv6 RA vs DHCPv6 - The chosen one?

Doug Barton dougb at dougbarton.us
Thu Dec 22 21:33:10 UTC 2011


On 12/22/2011 04:48, Glen Kent wrote:
>> In many environments RA is a catastrophic disaster. Some operators need
>> to be able to do everything with RA turned off on routers, disabled on
>> hosts and filtered on switches.
> 
> While in some environments, typically with small number of devices,
> its indispensable. Small businesses may not want the complexity of
> setting up a central server (for DHCP) - SLAAC works very well in such
> environments.

Please show me the small businesses that don't already have a DHCP
server. Or (equally unlikely) show me the small business whose DHCP
server isn't baked into their SOHO router/toaster and works with nearly
zero human intervention.

> Today, we can get NTP server information only with DHCP (DNS info is
> supported by both DHCP and RAs). DHCP only works after RAs have been
> processed. In some environments (mobile IPv6) delays in acquiring NTP
> and other servers information is critical and waiting for DHCP to come
> up may not be acceptable.

So clearly the right answer is to make DHCPv6 a superset of RA
functionality so that the people who need more than what RA provides
only have to run DHCP.

Over strenuous objection DNS resolver data was added to RA and the folks
over in MIF are just now getting around to sorting out the damage caused
by having the same category of information arrive over 2 different
configuration protocols with subtly different data. (A 100% foreseen
problem that was part of the core of the previously mentioned strenuous
objections.)

RA was an interesting idea that came to light in an era when DHCP was
new, clunky, unreliable, and not widely deployed. None of those things
are true anymore, so it would be very helpful if IPv6 deployment
planning moved into the 21st Century.


Doug

-- 

		[^L]

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/





More information about the NANOG mailing list