DHCPv6 server on Cisco IOS: making progress

DHCPv6 server on Cisco IOS got several highly useful enhancements since the first time I started looking into its behavior. Seems like most of them are implemented only in 15.xS trains (where they are most badly needed one would assume), but there’s hope those changes will eventually trickle down into mainstream IOS.

VRF-aware DHCPv6 server in 15.1(2)S. Previous it was impossible to do DHCPv6 prefix delegation to CPEs connected to VRF interfaces on the PE-routers. With the VRF-aware DHCPv6 server you can get rid of PE-CE static routing (a static route is automatically inserted on the PE-router when an IPv6 prefix is delegated to a CPE router) and deploy scalable IPv6 MPLS/VPN networks.

Even better –using VRF-aware DHCPv6 relay, it’s possible to allow the customer to provision all its CPEs (including the inside LAN interfaces on the CPE routers and the PE-CE routing) remotely using its own central DHCPv6 server.

DHCPv6 Relay Chaining in 15.2(1)S. This feature enables a series of DHCPv6 relays – access switch forwarding a DHCPv6 request to an aggregation-layer switch that forwards the request to the central DHCPv6 server.

Benefit: due to automatic creation of IPv6 static routes toward downstream DHCPv6 clients (or relays), it’s possible to build large-scale access networks without a routing protocol. All you have to do is to advertise an aggregate prefix from the aggregation-layer switch into the core and let DHCPv6-based static routes do their job in the access layer.

DHCPv6 Bulk Lease-Query in 15.1(1)S. This feature nicely solves the problem of PE-router reload.

The PE-router loses all PE-to-CPE static routes for delegated DHCPv6 prefixes during the reload. The lease-query functionality (RFC 5007) allows it to query the central DHCPv6 server, receive the information about the delegated prefixes, and reinstall the static routes. Bulk Lease-Query (RFC 5460) is an enhancement that enables bulk transfer of delegated information over a TCP session.

Summary: A major showstopper to DHCPv6 deployment solved. Good job!

Update 2012-01-19: The following paragraph has been rewritten; Cisco IOS release 15.1S supports RFC 4818.

DHCPv6-RADIUS integration (RFC 4818) works correctly in Cisco IOS release 15.1(3)S and IOS XE. The documentation still totally confuses a careless reader (the sample RADIUS configuration is awesome #FAIL, just check the IPv6 prefixes). Just in case you might need it I published a sample tested Cisco IOS and RADIUS configuration.

4 comments:

  1. Great post again Ivan, regarding DHCPv6 Relay Chaining

    "Benefit: due to automatic creation of IPv6 static routes toward downstream DHCPv6 clients (or relays), it’s possible to build large-scale access networks without a routing protocol. All you have to do is to advertise an aggregate prefix from the aggregation-layer switch into the core and let DHCPv6-based static routes do their job in the access layer."

    Pretty cool would this be akin to a version of ODR? And would there be any security implications/exploits with this approach? Regards..
  2. ODR - Not exactly, but sort-of ;)

    Security implications - as soon as you "own" the backbone, you can do anything you want (DHCPv6 is not signed or anything like that). Apart from that, the DHCPv6 requests get validated by the DHCPv6 server.
  3. Hi Ivan

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    I wasn’t able to find any progress on the DHCPv6-RADIUS integration front. The standard Delegated-IPv6-Prefix RADIUS attribute works only in IOS XE, where the documentation totally confuses a careless reader (the sample RADIUS configuration is awesome #FAIL , just check the IPv6 prefixes).
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    I tried with Dynamips using 72K running c7200-adventerprisek9-mz.151-3.S0a.bin and Freeradius on Ubuntu 11.10 and works fine. The RADIUS [123] is forwarded normally (RFC 4818 is present) as it seems (no need for two accounts on radius). Previously i have faced issues with older versions of Freeradius where the decoding of attribute was failing. Actually i wanted to ask for something else there. In an Broadband scenario using dual-stack PPPoE where customer CPE should be request and assigned a DHCPv6 PD prefix, is it mandatory the use of flags ('M') on the virtual-template ? According to informational RFC 5887 it is stated the following:

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    We should note a currently unresolved ambiguity in the interaction
    between DHCPv6 and SLAAC from the host's point of view. RA messages
    include a 'Managed Configuration' flag known as the M bit, which is
    supposed to indicate that DHCPv6 is in use. However, it is
    unspecified whether hosts must interpret this flag rigidly (i.e., may
    or must only start DHCPv6 if it is set, or if no RAs are received) or
    whether hosts are allowed or are recommended to start DHCPv6 by
    default. An added complexity is that DHCPv6 has a 'stateless' mode
    [RFC3736] in which SLAAC is used to obtain an address, but DHCPv6 is
    used to obtain other parameters. Another flag in RA messages, the
    'Other configuration' or O bit, indicates this.

    Until this ambiguous behaviour is clearly resolved by the IETF,
    operational problems are to be expected, since different host
    operating systems have taken different approaches. This makes it
    difficult for a site network manager to configure systems in such a
    way that all hosts boot in a consistent way. Hosts will start SLAAC,
    if so directed by appropriately configured RA messages. However, if
    one operating system also starts a DHCPv6 client by default, and
    another one starts it only when it receives the M bit, systematic
    address management is [...]
  4. SLAAC/DHCPv6: http://blog.ioshints.info/2012/01/ipv6-nd-managed-config-flag-is-just.html

    DHCPv6-RADIUS integration: http://blog.ioshints.info/2012/01/dhcpv6-prefix-delegation-with-radius.html

    Thanks for the comment!
    Ivan
Add comment
Sidebar