{SPAM?} Re: IPv6 Deployment for the LAN

Sun Oct 18 16:26:41 UTC 2009

I generally agree with the design of RA and using DHPCv6 as a
supplement to it.  The problems here seem to be more along the lines
of implementation in clients.  I suspect it will take some time for
the dust to settle and vendors to get their act together.

I notice that Cisco has a "prefix no-autoconfig" statement in some
releases in addition to no-advertise.  The code I'm running doesn't
seem to support this yet.  I'll have to dig deeper to see what series
support it and how it interacts with hosts.  If hosts actually do
respect it, it will likely lead to our migration to using /64s, though
a lot will depend on the time tables we can set to move to code that
will support this on our routers.  I do remember seeing some notes
about some implementations of IPv6 simply ignoring that flag for the
prefix, though, so I'm still hesitant to endorse it until I've had a
chance to test a wide variety of hosts in this configuration.

Still, using a prefix other than a /64, but maintaining a migration
path to /64 in the future, seems to be the best way to get IPv6 rolled
out to the edge from a political standpoint.  It's easier to make the
case to extend IPv6 if you can be fairly certain that it won't cause
hosts to suddenly start using IPv6 on their own.  I have yet to run
into an IPv6 implementation that will use SLAAC with a prefix other
than a /64, thankfully.

>From what I've been told, Cisco is actively working on RA-gaurd for
their managed switching platforms, which will be nice to see.

Reading a bit of the discussions regarding IPv6 in the Apple world, it
seems that they're after supporting DNS server information in RA using
RFC 5006.  I think RFC 5006 is a very bad idea personally.  DHCPv6 was
designed to work in harmony with RA, and providing host configuration
is beyond the scope of RA.  I hope that we don't start seeing
implementations of this as it will lead to an environment where some
clients support DHCPv6 and some do not.

The SLAAC vs. DHCPv6 war all seems a bit silly.  They're both tools
that are designed to compliment one another, and both have their uses.

DHCPv6 does complicate things with the DUID rather than using the
physical address, but I can appreciate the problems they're trying to
overcome.  It just makes this a little more complicated for those of
us who would like to maintain associations between a hosts IP and IPv6
information in a dual-stack environment.

On Sun, Oct 18, 2009 at 11:45 AM, Kevin Loch <kloch at kl.net> wrote:
> Nathan Ward wrote:
>>
>> On 19/10/2009, at 1:10 AM, Owen DeLong wrote:
>>
>>> On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote:
>>>
>>>> On 18/10/2009, at 11:02 PM, Andy Davidson wrote:
>>>>
>>>>> On 18 Oct 2009, at 09:29, Nathan Ward wrote:
>>>>>
>>>>>> RA is needed to tell a host to use DHCPv6
>>>>>
>>>>> This is not ideal.
>>>>
>>>> Why?
>>>> Remember RA does not mean SLAAC, it just means RA.
>>>
>>> Because RA assumes that all routers are created equal.
>>
>> RFC4191
>
> In some cases different devices on a segment need a different
> default router (for default).  This is the fundamental
> problem with RA's, they shotgun the entire segment.
>
>>
>>> Because RA is harder to filter.
>>
>> DHCP in IPv4 was hard to filter before vendors implemented it, too.
>>
>>> Because the bifercated approach to giving a host router/mask information
>>> and address information
>>>    creates a number of unnecessary new security concerns.
>>
>> Security concerns would be useful to explore. Can you expand on this?
>
> What would be useful would be having the option to give a default
> router to a dhcpv6 client, and having vrrpv6 work without RA's.
> Why can't we have those options in our toolbox in addition to
> this continuously evolving RA+hacks?
>
> - Kevin
>
>

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/