IPv6 pools support

The IPv6 address pool name is specified by the Framed-IPv6-Pool attribute in Access-Accept.

Attributes that set IPv6 addresses to the subscriber (Framed-IPv6-Address, Framed-IPv6-Prefix, Delegated-IPv6-Prefix) take precedence over Framed -IPv6-Pool: if there is a pool in the response and at least one of the above attributes specifying an IPv6 address or prefix, PCRF ignores Framed-IPv6-Pool

Upon detecting the Framed-IPv6-Pool attribute in the Radius response, the PCRF shall:

contact the DHCPv6 server for the address and/or prefix of the subscriber by passing the pool name to the DHCPv6 server in one of the DHCPv6 options;

after receiving a DHCPv6 server response, generate a general authorization response by combining the DHCPv6 response options and the Access-Accept attributes

Configuring fastPCRF

At least one DHCPv6 server serving the pools must be specified in fastpcrf.conf. The server address is set in the dhcp6_server parameter of the following form:

# Each server is specified by a separate parameter dhcp6_server
# Format:
# dhcp6_server = [ipv6% dev] {: port} {; option} +
# where:
# ipv6 - DHCPv6 server address
# dev is the name of the interface from which to connect
# port - port, default = 547
# options: additional options:
# source_ip = address - source IPv6 address, on behalf of which the request to the DHCPv6 server is made
# If source_ip is not set, then:
# - if the server address is link-local - the link-local address of the dev interface is taken
# - if the server address is global - the global address of the dev interface is taken
# relay_ip = address - IPv6 address of the relay. It is this address that the DHCPv6 server regards as the relay address.
# If not set - equal to source_ip
# Example: two DHCPv6 servers: one with a global address, the other with a link-local address
# dhcp6_server=[2001:4860:4860::8888%eth1];source_ip=2a01:a282:3:11:92b1:1cff:fe18:d298;relay_ip=2001::1
# dhcp6_server=[fe80::92b1:1cff:fe18:d298%em2];relay_ip=2001::1
dhcp6_server=[fe80::92b1:1cff:fe18:d298%em2];relay_ip=2001::1

Each DHCPv6 server is specified in fastpcrf.conf with a separate parameter. For example, two servers can be defined like this:

# Main server - on interface eth1
dhcp6_server=[fe80::92b1:1cff:fe18:d298%eth1];relay_ip=2001::1
# Backup server - on em2 interface
dhcp6_server=[fe80::92b1:1cff:fe18:4509%em2];relay_ip=2001::1

Supports up to 16 DHCPv6 servers. This parameter does not have any default value - to support Framed-IPv6-Pool, it is necessary to register at least one DHCPv6 server in fastpcrf.conf.

In addition to DHCPv6 servers, you should also specify in which DHCPv6 request option to send the pool name. This is done using the dhcp6_poolname_opt parameter. The following DHCP options are supported:

dhcp6_poolname_opt=1 - [15] User-Class. If the option is already present, its value is replaced with the name of the pool

dhcp6_poolname_opt=2 - [17] Vendor-Specific (vendorId=43823, subopt=1). Option is always added

If dhcp6_poolname_opt=0 (default) - the pool name will be passed in the Vendor-Specific option.

FastPCRF addresses DHCPv6 servers as a relay to make DHCPv6 traffic unique. All DHCPv6 requests are always sent to all servers specified in the dhcp6_server parameters. If multiple DHCPv6 servers are configured, PCRF takes into account the first timed response, replies from other DHCPv6 servers are ignored.

Peculiarities of issuing IPv6 addresses/prefixes in Stingray Service Gateway

Note that Stingray SG currently requires the client to be given a prefix with the length specified by the ipv6_subnetwork parameter in fastdpi.conf (by default ipv6_subnetwork=64). This applies to both PD prefixes and the actual IPv6 address given to the client. That is, in fact, the client is given two prefixes - a PD-prefix and a prefix, from which SSG itself forms the client's full IPv6 address.

Most DHCPv6 servers can issue a PD prefix of any length to a client, but they cannot - a specified length prefix as the client's IPv6 address. In other words, the DHCPv6 server cannot be instructed to "issue IPv6 addresses to clients at this step" (for example, with a / 64 step). To get around this limitation, SSG uses the following trick: only the PD-prefix is requested, and the DHCPv6-server must issue a PD-prefix of length ipv6_subnetwork - 1 to the subscriber (that is, by default, 64 - 1 = 63 - /63 prefix). SSG itself divides such a PD-prefix into two / ipv6_subnetwork-prefixes: the lower prefix is for allocating an IPv6 address to the client, and the older one is for the client's PD prefix.

Kea DHCPv6 Server Configuration Examples

The DHCPv6 server is configured differently depending on which DHCPv6 option the pool name will come in (the dhcp6_poolname_opt parameter). Below are not complete configuration files /etc/kea/kea-dhcp6.conf Kea DHCP, but only extracts related to configpool management

example for option 17 (dhcp6_poolname_opt=2)

example for option 15 User-Class (dhcp6_poolname_opt=1)

Forming a DHCPv6 request in DHCPv6 Radius Proxy mode

In the DHCP Radius Proxy mode, the original DHCPv6 subscriber request is sent to the DHCPv6 server with the addition of the pool name in accordance with the dhcp6_poolname_opt parameter. But the server is requested only PD-prefix, see above "peculiarities of issuing IPv6 addresses/prefixes in SSG".

Be careful when specifying the pool name in the opt15 User-Class option: if this option is already present in the DHCPv6 subscriber request, its value is changed to the pool name. If the original value of this option is important when configuring a DHCPv6 server, you should use option 17 for the pool name, which is always added

Forming a DHCPv6 request for PPPoE clients

For PPPoE-PCRF subscribers form a DHCPv6 request, in which Client-Id (option 1, client DUID) is built as DUID-EN (vendorId=43823, 32 bits), then the client's VLANs (2 fields of 16 bits, if there is no VLAN, its value is 0), then 6 bytes of the client's MAC address. This Client-Id design ensures that the DUID remains unchanged, which is important for a DHCPv6 server.

Forming Access-Accept

After receiving a response from the DHCPv6 server, PCRF combines it with the one previously received from the "Access-Accept" Radius. Recall that in Access-Accept you can also specify DHCPv6 options in the form special VSA. When aggregating responses, DHCPv6 options returned by the DHCPv6 server take precedence over these VSA attributes; for example, if a different list of DNS servers is specified in both the DHCPv6 response and the Access-Accept, then the subscriber will be sent a list of DNS servers from the DHCPv6 server response.