During the last months i've been experimenting a lot with all possible IPv6 address assignment methods to a broadband subscriber. As is the case with most ISPs and IPv6, we are testing every possible scenario before we put one (or a combination) of them into production; nevertheless we still haven't decided which path to follow on every aspect. And although we have made up our minds on many of those dilemmas, the one that will remain unresolved for a little bit more is the choice between dynamic vs static addresses.
Based on various RFCs, Broadband Forum's TRs, blogs (i.e. Ivan's) and IETF WG presentations, i have gathered below all possible address assignment scenarios/methods, when it comes to a broadband (PPPoE) IPv6 subscriber CPE. Single host connectivity is out of the scope of this list, because it doesn't seem applicable for wireline providers.
Some of these methods have already been verified internally (using mostly Cisco equipment, followed closely by Juniper), others are waiting to be verified and a few are under evaluation whether they actually can be implemented and verified. So, if you believe that something is not applicable, please write down your objection, so we can discuss it. Also, if you find something missing, please feel free to add it in your comment.
I have put them in 3 different areas, based on the interface and the address type. Each area includes various mechanisms related to address assignment.
- CPE WAN Interface - Link-Local IPv6 Address
- CPE WAN Interface - Global Unicast IPv6 Address/Prefix
- SLAAC (RFC 4862)
- RA using a locally configured IPv6 pool on BRAS
- RA using a "Framed-IPv6-Pool" from Radius (RFC 3162) to define a locally configured IPv6 pool
- RA using "Framed-IPv6-Prefix" from Radius (RFC 3162)
- Stateful DHCPv6 (RFC 3315)
- IA_NA using a locally configured IPv6 address prefix pool on BRAS
- IA_NA using an external DHCPv6 server, having BRAS as Relay Agent
- IA_NA using "Framed-IPv6-Pool" from Radius (RFC 3162) to define a locally configured IPv6 pool on BRAS
- IA_NA using "Framed-IPv6-Address" from Radius (draft-ietf-radext-ipv6-access)
- CPE LAN Interface - Global Unicast IPv6 Prefix
- DHCPv6-PD (RFC 3633)
- IA_PD using "Delegated-IPv6-Prefix" from Radius (RFC 4818)
- IA_PD using "Framed-IPv6-Prefix" from Radius (RFC 3162) for $username-dhcpv6 (if RFC 4818 is not supported)
- IA_PD using "Framed-IPv6-Prefix" from Radius (RFC 3162) (if global addresses are not used on the WAN interface)
- IA_PD using a locally configured IPv6 prefix pool on BRAS
- IA_PD using an external DHCPv6-PD server, having BRAS as Relay Agent
- IA_PD using "Framed-IPv6-Pool" from Radius (RFC 3162) to define a locally configured IPv6 prefix pool on BRAS
- IA_PD using "Delegated-IPv6-Prefix-Pool" from Radius (draft-ietf-radext-ipv6-access) to define a locally configured IPv6 prefix pool on BRAS
RA = Router Advertisement
IA_NA = Identity Association for Non-temporary Addresses
IA_PD = Identity Association for Prefix Delegation
GREEN : Verified
ORANGE : To be verified
BLUE : To be implemented and verified
RED : Probably not applicable
What i see as the most interesting options are the following two:
- "Framed-IPv6-Prefix" for WAN (through SLAAC) and "Delegated-IPv6-Prefix" for LAN
- "Framed-IPv6-Address" for WAN (through DHCPv6) and "Delegated-IPv6-Prefix" for LAN
Hopefully we'll soon have support of "draft-ietf-radext-ipv6-access" by BRAS vendors and we'll be able to verify another bunch of them.
- Radiator has been used as the radius server for all our internal tests. Its flexibility probably puts it at the top of the market.
- Technically, IPv6CP is not an address assignment method (like IPCP). It just helps/hints the peer to build a possible IPv6 link-local address by negotiating a 64bit Interface-Id option. There have been various draft RFCs (draft-huang-ipv6cp-options, draft-qin-pppext-ipv6-addr-pref) that were supposed to add more options to it (like Prefix, IPv6-Address, Delegated-Prefix, DNS-IPv6-Address, etc.), but they expired and never moved into standard status. Two new ones (draft-hu-pppext-ipv6cp-requirements, draft-hu-pppext-ipv6cp-extensions) have brought the issue into surface again. IETF members' usual answer is that PPP is a link-layer protocol, so higher level (i.e network,application) protocols should be left outside.