Looking for general feedback on IPv6 deployment to the edge.
As it turns out delivering IPv6 to the edge in an academic setting has
been a challenge. Common wisdom says to rely on SLAAC for IPv6
addressing, and in a perfect world it would make sense.
Given that historically we have relied on DHCP for a means of NAC and
host registration, like many academic institutions, the idea of
sweeping changes to accommodate IPv6 was just not going to happen in
the near future.
The only solution that lets us expand our roll out IPv6 to the edge
without major changes to the production IPv4 network seems to point to
making use of DHCPv6, so the effort has been focused there.
Our current IPv6 allocation schema provides for a 64-bit prefix for
each network. Unfortunately, this enables SLAAC; yes, you can
suppress the prefix advertisement, and set the M and O flags, but that
only prevents hosts that have proper implementations of IPv6 from
making use of SLAAC. The concern here is that older hosts with less
than OK implementations will still enable IPv6 without regard for the
stability and security concerns associated with IPv6.
Needless to say, the thought of being able to enable IPv6 on a
per-host basis is met with far less resistance than opening up the
floodgates and letting SLAAC take control.
Ultimately, the best solution that I've been able to come up with is
to preserve the IPv6 allocation schema and reserve a 64-bit prefix for
each network, but for the initial deployment use an 80-bit one in its
place with the extra 16 bits given a value of 1. The advantages of
this: Guarantee that SLAAC will not be initiated for the prefix;
Allow for a migration path to 64-bit prefixes in the future; and, Make
it easy to identify a network that us making use of an 80-bit prefix
by setting the extra bits to a value of 1.
This allows us to be fairly confident that extending IPv6 to edge
networks will not impact production services, and focus on DHCPv6 for
host configuration and address assignment.
We have no problem using a 64-bit prefix and letting SLAAC take care
of addressing for certain networks where we actually manage the hosts,
so that has been included as an exception. All other networks,
however, will make use of DHCPv6 or manual configuration to receive
So far, this has proven to work well with testing of various hosts and
Has anyone run into issues with applications in not using a 64-bit prefix?
Of course, the other challenge here is proper DHCPv6 client
implementations for host operating systems. Linux, Windows Server
2003 and later, Windows Vista, and Windows 7 all support DHCPv6.
Windows XP has a poor implementation of IPv6 but has the option of
using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a
challenge; it currently has no option for DHCPv6, though newer
releases provide for manual configuration of IPv6 addressing.
Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X?
Since the goal for this initial wave is to make IPv6 available to
those who request it or have a need for it, we feel its acceptable
that there will need to be some user participation in enabling IPv6
for a host. I think the hope is that more systems, like Windows 7,
will begin including mature DHCPv6 clients which are enables when the
M flag for a router advertisement is set and perhaps make it the
default behavior. Is this likely to happen or am I being too
Anyway, just thought I'd bounce it to NANOG and get some feedback.