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"