On 12/22/11 12:09, Tomas Podermanski wrote:
We have to use SLAAC as well because we do not have other choice. Not
all operating systems supports DHCPv6 today. But we are not happy about
it (problems with privacy extensions, security as I mentioned before).
DHCPv6 do not have to be run on a central server. DHCPv6 can be
implemented as a part of a router as well. It is common for DHCP(v4) an
implementations for DHCPv6 are available today (eg. cisco
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html).
But one of the advantages you cite for DHCPv6 was the ability for the
central DHCPv6 service to make decisions about how to configure clients.
Most US EDUs that I am familiar with do not wish to go out and touch
every router when they want to make site-wide configuration changes.
Even if you run DHCP[v6] on a router (and yes, I have done it), you're
still running a separate service beyond routing and it still increases
the complexity of your configuration.
I agree with Bill: We're not hurting for choices in IPv4. What we don't
need to do is reduce choice in IPv6 by deprecating SLAAC--a move which
would also reduce the credibility of IPv6 itself. There was at least
some criticism of the community for deprecating NAT-PT. By pushing
SLAAC for many years, then deprecating it (as opposed to simply adding
alternatives), we will be telling would be adopters "we really can't
make up our minds as to how you're supposed to use this stuff." That
would only stall IPv6 adoption, even if the ultimate result of keeping
both protocols will be that a vast majority of folks use DHCPv6.
michael
