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 a prefix other than a 64 provides
an easy way to [attempt to] avoid this, all the while allowing for us
to eventually migrate to a 64-bit prefix when host support improves.
I would be more concerned with deviating from the mainstream of /64,
and the potential problems you will encounter when doing so, than I
would be for the few machines that might break when encountering SLAAC.
Another concern is that we certainly don't want to use SLAAC for
servers, and I'm hesitant to promote the use of manual IP
configuration as it can quickly become a nightmare if you need to move
networks (admittedly there should be less need for network moves, but
all the same).
Using SLAAC for servers has not been a problem for us at all. Many
server admins also want to use manual IPv6 addressing, and that is
perfectly fine with us if that is their choice. I just don't see a
problem with this.
DHCP has long solved many of these issues in the IP world, and it is
perfectly reasonable, and desirable, to apply them to IPv6 though the
use of DHCPv6. Perhaps in the future, as we see less legacy hosts
online we'll be in a position to make use of both SLAAC and DHCPv6 for
host configuration, but in all honesty, once DHCPv6 is in place, why
would you want to use SLAAC?
Until every network device has a built-in DHCPv6 client, I need
SLAAC. Even then, I have a number of special case networks where DHCP
is overkill if I have SLAAC available to me. But on the other hand,
for some network situations (like if you are using IVI as a transition
mechanism for your net) then DHCPv6 is mandatory. So I argue that we
need both.
My other question was DHCPv6 support from Apple (who seems to be one
of the few in resistance of DHCPv6). This list managed to point me in
the right direction to nag them about it.
I agree that this is a huge shortcoming on the part of Apple.
Everyone needs to file appropriate bug reports with Apple and complain
about lack of DHCPv6 support.
Good luck on your IPv6 deployment efforts.
Regards,
--Ron