Delegated IPv6 prefixes – RADIUS configuration

In the Building Large IPv6 Service Provider Networks webinar I described how Cisco IOS uses two RADIUS requests to authenticate an IPv6 user (request#1) and get the delegated prefix (request#2). The second request is sent with a modified username (-dhcpv6 is appended to the original username) and an empty password (the fact that is conveniently glossed over in all Cisco documentation I found).

FreeRADIUS server is smart enough to bark at an empty password, to force the RADIUS server to accept a username with no password you have to use Auth-Type := Accept:

Site-A-dhcpv6   Auth-Type := Accept
cisco-avpair = "ipv6:prefix#1=fec0:1:2400:1100::/56"

Having a username without a password in your RADIUS database is obviously a huge security hole – anyone can use that username to authenticate PPP sessions or log into your router. When Kurt (@networkjanitor) Bales stumbled across a similar problem, the first solution he proposed was to use a different set of RADIUS servers for login authentication, but then he wrote a great blog post describing how you can use additional check items in FreeRADIUS user definitions to ensure a PPP username can never be used for an interactive login session.

FreeRADIUS provides a variety of check items you can use, including lack of an attribute in the incoming request. As RADIUS requests used to get delegated IPv6 prefix have no other attributes but modified username and empty password, I was able to use the absence of other attributes to generate a somewhat foolproof user entry that could not be used for anything but IPv6 prefix delegation:

Site-A-dhcpv6   Service-Type !* any, NAS-Port-Id !* any, Auth-Type := Accept
cisco-avpair = "ipv6:prefix#1=fec0:1:2400:1100::/56"


  • The !* syntax indicates the attribute must not be present in RADIUS request. The value of the attribute is ignored.
  • Service-Type RADIUS attribute indicates the type of service the RADIUS client (the router) is authenticating.
  • Cisco IOS does not include Service-Type attribute when authenticating interactive users. Those requests do include NAS-Port-Id attribute.


  1. As always Ivan, this is a good post. In FreeRADIUS I would suggest adding your !* checks into a Group config and adding all -dhcpv6 users to that group to save mistyping those commands.

    I will be adding this to my RADIUS setups tomorrow :) Great catch.

    Unrelated I guess, but in the past I have used the NAS-Port-Id on a PPPoE LAC to ensure that certain users could only login from certain VLANS. (I had a college with Student and Staff networks and wanted restrict accounts to certain vlans).
  2. This is the OPPOSITE of the cisco documentation I found, which specifically said that it was the same password! Which explains why I could never get the -dhcpv6 username to authenticate. I ended up finding a number of workarounds to this, but my favourite answer was the one I commented on the other post. What a niiiiiightmare.
  3. Now I remember my discovery process:

    Step #1 - read the documentation
    Step #2 - try & fail
    Step #3 - Debug RADIUS to figure out RFC 4818 is not supported AT ALL in ANY IOS release (might work with IOS XE)
    Step #4 - use Wireshark to find out what the true password is
    Step #5 - Try to figure out how to persuade FreeRADIUS to accept empty password (included a lengthy visit to the source code ... sometimes open source products make great sense)
  4. Hi Ivan:
    Did you try this combination for IPv6 address assignment:
    1.RA To Distribute CPE Wan IPv6 Prefix via Radius
    2.DHCPv6 PD To Distribute CPE Lan IPv6 Prefix

  5. Hi Ivan:
    In my lab, I only can the following:
    *Sep 5 00:26:50.838 UTC: ICMPv6-ND: Setup RA common:Other stateful configuration
    *Sep 5 00:26:50.838 UTC: ICMPv6-ND: MTU = 1492

    Cannot see any RA advertise IPv6 prefix to CPE WAN interface, can you advise ?

    Or can you share more information: like configuration ?

Add comment