From what I've been told, Cisco is actively working on RA-gaurd for
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. 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@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/