There are a myriad of options when it comes to assigning IPv6 attributes to a PPPox connections and in this post I’ll be exploring some of them.
In the network referenced in this post incoming PPP xDSL sessions (DSL, FTTC) are handed off from the wholesale provide over an L2TP tunnel. Upon successful authentication each connection is configured by the LNS with the attributes returned by the radius server. See below:
In the IPv4 world all the leg work was done at layer 2 with the use of IPCP within PPP. IPCP was responsible for configuring the IP address of the connection as well as providing additional information such as DNS servers. Quick and easy.
Although there is a v6 version of IPCP – IPCPv6 (RFC 5072) the process of configuring addresses differs drastically. In v6 IPCP the only use in the configuration stage is to negotiate a unique 64 interface identifier at the local end of the link. This interface Id is used with the fe80::/64 prefix to create a link local address on the PPP interface. The RFC explicitly states that the router should only use the Interface Id for creating a link local address and should not assume it can be used with a global prefix to create a global unicast address. Once this process has completed the user’s CPE can then obtain their global prefixes for their WAN and LAN interfaces using Stateless Address Autoconfiguration (SLAAC), DHCPv6 or a combination of the two.
PPP Interface
We’ll look at the assignment of the global prefix for the PPP interface first. As mentioned above IPCPv6 first negotiates a unique interface Id. You could set this statically on the CPE or assign from radius using the ‘Framed-Interface-Id’ (RFC 3162) attribute.
If using SLAAC the CPE sends a Router Solicitation message sourced from it’s link local address which is received by the LNS. The LNS has a couple of options. It can either assign the prefix from a locally configured pool or from radius using the ‘Framed-IPv6-Prefix’ (RFC 3162) attribute. If a locally configured pool is used then this can be referenced in the Virtual Template on the LNS or via radius using the ‘Framed-IPv6-Pool’ (RFC 3162) attribute. If the pool name is returned by the radius attribute it will overwrite anything already defined in the Virtual Template.
The config in our Virtual Template dictates whether the ‘M’ and ‘O’ flags are set in the router advertisement sent by the LNS. The commands are ‘ipv6 nd managed-config-flag’ and ‘ipv6 nd other-config-flag’ respectively. I found in the lab that setting the ‘M’ flag seemed to break connectivity as it tells the router to exclusively use DHCPv6 for address configuration presumably ignoring the prefix in the RA. The ‘O’ flag is set as we’re picking up name servers and prefix delegation via DHCPv6.
CPE LAN Interface
RFC 3769 describes the requirements for assigning prefixes to a IPv6 subscriber for use at their site. Typically an ISP will delegate a /48 or /56 depending on the size of the site allowing the requesting router to subnet this prefix further for individual links. For example a site assigned a /48 could then assign 65,000 /64 prefixes to it’s users.
Prefix delegation in IPV6 predominantly uses DHCPv6 to assign the prefix to the CPE for use on it’s LAN interface. At the start of the Prefix Delegation process the requesting router will send a DHCPv6 SOLICIT request to ff02::1:2 (all DHCP servers multicast address) with the IA-PD option set. If all goes well the end result is that the LNS will respond with an Advertise message containing the IAPREFIX option. Again the LNS has the option of sourcing this prefix either locally or from a radius server.
In the LNS configuration we point to an ipv6 DHCP server in our Virtual Template. In my case this is a locally configured DHCP pool which in turn points to an AAA method list that has our radius server listed. We could use a local prefix pool to deal with PD but the customer could be assigned a different prefix depending on the LNS their session ended up (which wouldn’t be too practical in real world usage). In addition to this we also have our v6 name servers listed in the DHCPv6 pool configuration. Presumably you could point to an external DHCPv6 server and relay the requests but I haven’t test this yet.
At our Radius server the attribute ‘Delegated-IPv6-prefix’ is used (RFC 4818) to return the prefix. This prefix is retrieved from the radius server at the same time as all the other attributes in Access-Accept response.
In older versions of IOS that do not support RFC 4818 the process is slightly more convoluted… Once the initial authentication had passed, and the unique interface Id assigned, the CPE would again send a DHCP PD request. However this time the LNS would then need to send another Access-Request packet to the radius server with the username set as ‘username-dhcpv6’ eg. 1234@isp.co.uk-dhcpv6. This is pretty tedious as you’d need to have an additional entry in your radius config to authenticate the modified username. There is a also a potential security hole as this user does not provide a password. The radius entry for this username just needs to contain the ‘Framed-IPv6-Prefix’ (RFC 3162) attribute.
Summary
So all in all there are several different methods of assigning IPv6 addresses to clients. It’s fairly simple to set up a lab and a box running Freeradius so I’d recommended testing all of them to get a good understanding of the mechanics and behaviour.