On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote:
On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin
s...@cs.columbia.edu wrote:
My question is this: what are your goals? What are you trying to
achieve?
As I read this whole thread, I had similar questions coming to mind.
The greater concern is that SLAAC makes IPv6 available to hosts that
may not be prepared for it. If administrators are asked if they would
like IPv6 enabled, having been explained the implications of such if
SLAAC is used for configuration, the majority of the time they come
back and say thanks, but no thanks. In this situation, SLAAC is
holding back deployment of IPv6. I suspect other have seen this as
well.
I do not understand the big concern here, but that is probably because
my own perspective and approach is somewhat different than yours. In
my humble opinion, those of us that are network operators need to
provide robust IPv6 connectivity and services to our customers today,
and customers with IPv6-enabled devices should automatically have IPv6
connectivity (i.e. automatically get an address and default route)
with minimal hassle and configuration effort on their side. If they
decide they don't want IPv6, it is up to them to disable it, because
they are the exception, not the rule. Besides, systems administrators
are probably the wrong ones to ask, because they will most often opt
for don't change anything that might break something or make me do
more work.
I just don't see how SLAAC is holding back deployment. In my
experience, SLAAC is your friend, given that DHCPv6 is not yet
available for most of the client world (i.e. Windows XP, Mac OSX).
I've seen only one case out of thousands of customers where enabling
IPv6 on the client broke access to a single remote web site, but that
was because of a flaw in the DNS implementation for that remote site.
Wait, there was one other case where the problem turned out to be a
bad NIC. I think you are overly concerned about breaking someone by
enabling SLAAC on all your nets. Rather, focus on making sure that
you have robust IPv6 connectivity and infrastructure and peering/
transit. If you do find situations where something breaks, then put
your energies into resolving those situations, which benefits the
whole community. Our philosophy has been aggressive IPv6-enablement
is the right thing to do, and don't be afraid to break some glass.
Part of the problem here is that IPv6 isn't new; it's old.
Implementations have been in place for years on certain systems
without proper testing as they have gone largely unused. We've seen
cases where older versions of Linux can be crashed by enabling SLAAC
on a network being one example.
Those cases are increasingly rare, and can be fixed. Don't let such
concerns stop you from IPv6-enabling your nets. As a network
operator, you are doing the right thing by enabling IPv6 on all your
nets, and it is not your fault if sys admins aren't keeping their
systems patched.
By using DHCPv6 we gain some advantages: We can automatically update
DNS for hosts so that IPv4 records and IPv6 records match; We have the
ability to roll out DHCPv6 on a per-host basis without causing
problems on the production IP network; and we can roll it in to our
existing [home grown] tools for network management in a way that is
easy for users of the system to understand (keep in mind, we provide
tools to delegate network control to hundreds of sub-administrators
throughout the State).
When I started rolling out IPv6 to my nets many years ago, I was of
the same mindset. I wanted the same mechanisms for managing addresses
and DNS as I had in place for IPv4, and do dynamic DNS updates out of
DHCP. But, I quickly changed my approach after seeing the huge lack
of client side support for DHCPv6, and serious interoperability issues
where it did exist. What we did find is a fairly simple means to use
SLAAC and still keep DNS updated automatically for IPv6 addresses by
polling the routers and doing the mapping to clone the IPv4 DNS
entries for IPv6. That works very well for us.
The original question here wasn't SLAAC vs. DHCPv6. I think many
network operators here who are tasked with managing anything of scale
will agree that SLAAC doesn't quite cut it and is often a step
backwards. The overhead of implementing and administering such a
system at this scale generally wins out over not doing so.
The question I was mainly concerned with was if anyone has encountered
issues with the use of an 80-bit prefix to prevent SLAAC from being
active. While the prefix advertisement does have the autonomous flag
which can be set to false, the underlying problem of IPv6
implementations not being consistent across hosts operating systems
yet doesn't change. I'm not convinced that there aren't
implementations out there that will enable SLAAC regardless of what
the prefix flag is set to, so using
