Address assignment protocols

A cMAG-c solution supports various address assignment protocols per session type.

Some address assignment protocols are specific to a session type (for example, IPCP for PPPoE) while other protocols are common for multiple session types (for example, SLAAC for IPoE and PPPoE).

The following table lists the supported address assignment protocols per session type.

Table 1. Address assignment protocols per session type
Address assignment protocol IPoE session PPPoE session
DHCP ✓
DHCPv6 NA ✓ ✓
DHCPv6 PD ✓ ✓
SLAAC (see ICMPv6 Router Advertisements and SLAAC) ✓ ✓

DHCP

The DHCP protocol, as defined in RFCs 2131, 2132, 3046, 4679, and 6842, is supported for IPv4 address assignment. The address allocation provides the address and the associated default gateway address. The subnet mask, as signaled in DHCP, is based on the micro-net subnet as provided by ODSA.

For messages sent by the cMAG-c, the source IP, the DHCP server IP option, and the siaddr option are by default equal to the default gateway. To override the default per service, use the following command.
subscriber-management services network-instance local-server-ip

The cMAG-c maintains a DHCP lease for every successfully negotiated DHCP transaction and extends the lease on renew or rebind. If a lease expires, the cMAG-c considers the IPv4 address for the session down and takes appropriate actions for the corresponding session (for example, bring the session down).

The following sources define the DHCP options sent in messages to the client:

  • explicit option values provided by authentication sources
  • bulk options signaled during authentication; for example, via the RADIUS Alc-ToClient-Dhcp-Options VSA
  • bulk options derived from a locally configured DHCP profile using the following command
    subscriber-management profiles dhcp-option-profile
  • DNS options from local address assignment (used in ODSA)

DHCP Offer and Ack messages to the client are constructed using the explicit option values. The option values of the two bulk sources (authentication and DHCP profile) are appended after the explicit option values.

The following rules apply to the options:

  • Only one source can provide DNS or NBNS. If a source with higher priority provides DNS or NBNS, DNS or NBNS are filtered out of lower-priority bulk options if present. The sources have the following priority:
    1. explicit options
    2. authentication bulk options
    3. DHCP profile options
    4. local address assignment options
  • Lease time, renew, and rebind timers are only provided by explicit per-session authentication sources and are filtered out of bulk options if present.
  • Specific options cannot be configured in the message and are filtered out of authentication bulk options. Overriding these options leads to incorrect DHCP behavior. Examples of these options are subnet mask, router, and DHCP message type.

ICMPv6 Router Advertisements and SLAAC

The cMAG-c periodically generates ICMPv6 Router Advertisements (RA) messages when an IPv6 address is allocated for the session. A client can trigger the generation of an ICMPv6 RA message by sending an ICMPv6 Router Solicitation (RS) message, but this is not mandatory.

Note: RFC 4861 and RFC 4443 define the ICMPv6 RA messages.

The client uses the source address of the ICMPv6 RA message as its default gateway address. By default, this source address is a link-local address derived from a hash of the cMAG-c system name. The cMAG-c installs the link-local address on the MAG-u via PFCP so the MAG-u can answer any ND request for it.

In some cases, this may lead to address conflicts; for example, when two MAG-u nodes are connected to the same Layer 2 aggregation. To solve this, you can override the link-local address using the following command.
subscriber-management authentication-database entry up-parameters link-local-address
The cMAG-c installs the override on the MAG-u via PFCP. While this allows very granular overrides, a Nokia MAG-u can only have one unique link-local address per network instance.
ICMPv6 RA messages use an RA profile. The RA profile is assigned to a session during authentication. To configure the RA profile in the ADB, use the following command.
subscriber-management authentication-database entry ra-profile
If no RA profile is retrieved during authentication, the session behaves as if it is using an RA profile with all default values.
Use the following command to configure the RA profile locally.
subscriber-management profiles ra-profile

The RA profile defines the following parameters:

  • advertisement-interval min and advertisement-interval max

    These parameters define the interval between periodical unsolicited ICMPv6 RA messages. The cMAG-c sends periodical unsolicited ICMPv6 RA messages with a random interval between the configured min and max. The random interval is regenerated after every unsolicited RA message.

    By default, the maximum advertisement interval is 600s and the minimum advertisement interval is 33% of the maximum interval.

  • force-unicast-mac

    This parameter defines which MAC address to use.

    If force-unicast-mac is enabled, the cMAG-c sends ICMPv6 RA messages to the unicast MAC address of the session, otherwise the cMAG-c sends the ICMPv6 RA messages to the all-nodes multicast MAC address (33:33:00:00:00:01).

    To avoid sending ICMPv6 RA messages to the wrong client, the force-unicast-mac parameter is enabled by default.
    Note: The destination IP address is always the all-nodes multicast IP address (FF02::1).

  • router-lifetime

    This parameter defines the validity period of the default router after receipt of the ICMPv6 RA message. By default, the router-lifetime is equal to (advertisement-interval max × 3).

  • reachable-time and retransmit-timer

    The reachable-time parameter defines the period that a neighbor can be reached after receiving a reachability confirmation.

    The retransmit-timer parameter defines the interval between retransmitted NS messages.

    By default, both parameters are set to zero, that is, the cMAG-c does not specify a value, and the client can choose a value based on local configurations.

  • hop-limit

    This parameter defines the value of the Hop Limit field in the outgoing ICMPv6 RA messages.

    By default, the hop-limit value equals 255 hops.

  • mtu

    This parameter defines whether the MTU option is included in the ICMPv6 RA messages and, if included, what value the MTU option contains. By default, the MTU option equals not-included.

  • other-configuration

    This parameter defines whether the O flag (other configuration) in the ICMPv6 RA message is enabled. If the O flag is enabled, a client can receive options via DHCPv6 without acquiring an address via DHCPv6; for example, in combination with SLAAC based address assignment. By default, the other-configuration parameter is disabled. To indicate whether address assignment via DHCPv6 is available, the related M flag (managed address configuration) is automatically set if a DHCPv6 IA-NA or an IA-PD prefix was allocated to the session.

  • on-link

    This parameter defines whether the L (on-link) flag is set in the SLAAC prefixes that are present in the ICMPv6 RA messages.

    By default, this flag is set.

When an SLAAC address is allocated to the client, each ICMPv6 RA message includes the SLAAC prefix with the A (autonomous address-configuration) flag enabled. With the A flag enabled, the client can autonomously allocate an IPv6 address from the signaled SLAAC prefix (as defined in RFC 4862).

The SLAAC prefix contains the preferred and valid lifetime that is learned during authentication. The default values of the preferred and valid lifetime are equal to 7 and 30 days respectively.
Note: Nokia recommends that the preferred lifetime is at least double or more than the configured maximum advertisement interval. This avoids the expiration of the preferred lifetime on the client side because of the loss of a single ICMPv6 RA message.

The ICMPv6 RA messages do not contain any other prefixes. A prefix that is derived from either DHCPv6 IA-PD or IA-NA, is not present.

The ICMPv6 RA messages include all IPv6 DNS servers that are discovered during session authentication (as defined in RFC 8106).

DHCPv6

The cMAG-c supports the DHCPv6 protocol, as defined in RFC 8415, with additional support for a lightweight DHCPv6 relay agent (LDRA) between the DHCPv6 client and the MAG-u/cMAG-c as defined in RFC 6221.

Within the DHCPv6 lease, the following is signaled to the client:

  • an allocated IA-NA address, an IA-PD prefix, or both
  • preferred and valid lifetimes
  • IPv6 DNS servers
  • DUID of the server
Preferred and valid lifetimes can be locally configured or received from an external AAA server in the Alc-v6-Preferred-Lifetime and Alc-v6-Valid-Lifetime VSAs. To locally configure the lifetimes, use the valid-lifetime and preferred-lifetime commands in the following context. 
subscriber-management authentication-database entry address-assignment ipv6-lifetimes
Valid and preferred lifetimes are common for all IPv6 addresses of a session.
The server DUID is by default based on the cMAG-c system name. To override the default server DUID per service, use the following command.
subscriber-management services service dhcpv6-server-duid

The cMAG-c maintains a DHCP6 lease for every successfully negotiated DHCPv6 transaction and extends the lease on renew or rebind. The lease time is based on the IPv6 valid lifetime. If a lease expires, the cMAG-c considers the IA-NA address or IA-PD prefix for the session down and takes appropriate actions for the corresponding session (for example, remove dataplane state, bring the session down, or bring IPv6CP down).

DHCPv6 options can come from multiple sources. The following sources define the DHCPv6 options sent in messages to the client:

  • explicit option values provided by authentication sources
  • bulk options signaled during authentication; for example, via the RADIUS Alc-ToClient-Dhcp6-Options VSA
  • bulk options derived from a locally configured DHCP profile using the following command
    subscriber-management profiles dhcpv6-option-profile
  • DNS options from local address assignment (ODSA)

DHCPv6 Advertise and Reply messages to the client are constructed using the explicit option values. The option values of the two bulk sources (authentication and DHCPv6 profile) are appended after the explicit options.

The following rules apply to the options:

  • Only one source can provide DNS. If a source with higher priority provides DNS options, they are filtered out of lower priority bulk options if present. The sources have the following priority:
    1. explicit options
    2. authentication bulk options
    3. DHCPv6 profile options
    4. local address assignment options
  • Identity association (IA) options, server DUID, server unicast, relay message, status code, interface ID, and other similar options are filtered out of the bulk options because these must be in full control of the cMAG-c.
  • In case of LDRA, all options are included in the relayed message.

If an IA-PD prefix or IA-NA address is allocated, the cMAG-c sends ICMPv6 RA messages so the client can learn its default gateway address. For consistency, the cMAG-c sends DHCPv6 messages with a link-local address that is the same as the source address in ICMPv6 RA messages.