IPv6 autoconfiguration: too many cooks spoil the broth

Andrej Kobal from Astec shared a few interesting facts during the 3rd Slovenian IPv6 summit: they were deploying a pilot IPv6 subnet in a large network and wanted to retain tight control over the IPv6 address assignment (some people don’t consider random address chasing embraced by Windows the best use of their time), so they’ve decided to use DHCPv6. Bad luck: DHCPv6 can’t tell you the IPv6 address of the default router (like DHCP does). You need ICMPv6 RA (part of IPv6 Neighbor Discovery) to figure out who the router is.

If you want to protect the integrity of your network, you need to deploy SeND or RA guard as well as DHCPv6 guard on your switches. These features are not yet available on many L2 switches ... Catalyst 4500 and Catalyst 6500 are a notable exception. Catalyst 3750 also supports IPv6 port access lists.

Need a brief overview of IPv6? You’ll find it in the Market Trends in Service Provider Networks webinar.

Interested in enterprise IPv6 deployment issues? They’re described in the Enterprise IPv6 Deployment workshop.

Advanced Service Provider engineer? Check out the Building IPv6 Service Provider Core webinar.

OK, so maybe SLAAC (RFC 4862) is the way to go. Not really: you cannot pass the address of the DNS server in ICMPv6 messages unless you use the experimental extensions defined in RFC 5006, not to mention the inability to create dynamic reverse DNS mappings (which any decent DHCP server should support). Furthermore, don’t count on RFC 5006 being supported in mainstream operating systems right now (if you’re really brave you could deploy open-source freeware in your production network).

For more autoconfiguration gotchas, read the comments in this blog post.

Bottom line: to get what DHCP gives you in IPv4 world, you have to use two protocols in IPv6 world.

8 comments:

  1. and after you install RA and DHCPv6 you find out that it only works "out of the box" on Windows Vista and Windows 7. For it to work on Windows XP or Ubuntu Linux you must install another dhcpv6 client.

    one would expect that 15+ years of IPv6 development would clarify and simplify those "simple tasks", but no....

    Those things might work ok for some lab rats and ipv6 enthusiast, but "Janez Novak" 8-) just "wants it to work" (TM) - no installs, no configs and no manual configuration of either IP address OR rDNS server...

    ReplyDelete
  2. SLAAC --> RFC 4862 (updates RFC 2462)
    RFC 5006 (EXP) will probably be rewritten and put on the ztandards track (see IETF work in progress in 6man wg)

    ReplyDelete
  3. Fixed the SLAAC RFC#. Thank you!

    ReplyDelete
  4. Ivan Pepelnjak13 June, 2010 08:46

    Fixed the SLAAC RFC#. Thank you!

    ReplyDelete
  5. Problem is that some people wanted stateless IPv6 address autoconfiguration, and others wanted stateful. So somehow you need to express that policy to the end-nodes as to what to use. RAs do this. You could add a default gateway option to DHCPv6, and stop RA emitting routers from announcing themselves as default routers by setting the router lifetime to zero. But you're going to have need a SLAAC verses DHCPv6 conveyance mechanism regardless - and as RAs serve this purpose, why not use RAs to express that policy as well as announce a default router. In other words, the root cause of this situation is the dual and conflicting requirements of stateless and stateful addressing. I don't mind either of them too much, although I prefer stateless, but would have much preferred one or the other methods of address configuration, just not both. *DONT_KNOW*

    ReplyDelete
  6. As most of the people trying to deploy IPv6 in production networks have found out, today you need BOTH - DHCPv6 to tell you the DNS server's address and RA to tell you who the default router is. One or the other could be used to set the host's IPv6 address.

    ReplyDelete
  7. I think you've missed my point. How are you going to tell end-nodes to use stateful DHCPv6 OR stateless (SLAAC)? If you don't automate that via a link based announcement and/or request/response protocol of some sort, the only option left is manual end-node configuration - not practical in a large number of cases. RAs could be better described as "IPv6 addressing model and parameter configuration protocol". Routers are a logical device to perform this function, and using their announcements to convey default router information is also a reasonable optimisation if they're going to be making periodic announcements or responding to solicitations for addressing configuration information anyway. Note that if you set the router lifetime in an RA to zero, then end-nodes won't use the router as a default gateway, yet can still use the information in them e.g. PIO, for addressing model etc. configuration.

    The main reason people seem to say they want to use stateful DHCPv6 is that they want to record MAC address / IPv6 address mappings for audit purposes. I think that can easily be achieved in the stateless model by having a router (or another appropriate device) notice when DAD is initially occurring, tentatively place that end-node information in the neighbor cache if it doesn't conflict with existing entries, and then have NUD generate a SNMP trap when the address is determined to be not a duplicate, and have NUD genarate another SNMP trap when the neighbor cache entry is removed. Since it would be quite simple to create audit logs of address usage in a stateless model using this method, I think DHCPv6 for addressing mostly just exists because "that's how hit works in IPv4". A shame really, it seems like the most popular criticism of IPv6 is support for the two different addressing configuration models.

    ReplyDelete
  8. Ivan Pepelnjak08 March, 2011 08:30

    Mark, I understand all you're saying and I agree with most of it. However, I still claim it's stupid you need BOTH SLAAC and stateless DHCPv6 (to pass DNS server address) if you want to auto-configure your end hosts.

    I know the new RFCs are out, but yet again, why did it take 10+ years to realize the problem ... and when will we have them available in all desktop OS where they matter most?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.