Address assignment protocols

Get a generic overview of the address assignment protocols supported in a MAG-c solution.

This section provides a generic overview of the address assignment protocols supported in a MAG-c solution.

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 ✓
IPCP ✓
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 MAG-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 APN, use the dhcpv4-server-ip command in the following context.
configure mobile-gateway pdn apn

The MAG-c maintains a DHCP lease for every successfully negotiated DHCP transaction and extends the lease on renew or rebind. If a lease expires, the MAG-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 dhcp-profile command in the following context
    configure mobile-gateway profile bng
  • 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.

IPCP

IPCP is used for PPPoE sessions and is defined in RFC 1332 and RFC 1877. IPCP is used to signal an allocated IPv4 address and any DNS or NBNS address.

After IPCP is successfully negotiated, the MAG-c never initiates an IPCP Terminate Request. The client can bring down the IPCP stack and renegotiate if the underlying session is still alive. However, this does not trigger a reallocation of the IP address.

ICMPv6 Router Advertisements and SLAAC

The MAG-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 the MAC address of the MAG-c. The MAG-c installs the link-local address on the BNG-UP via PFCP so the BNG-UP can answer any ND request for it.

In some cases, this may lead to address conflicts; for example, when two BNG-UPs are connected to the same layer 2 aggregation. To solve this, you can override the link-local address using the link-local-address command in the following context. 
configure mobile-gateway profile authentication-database entry interface
The MAG-c installs the override on the BNG-UP via PFCP. While this allows very granular overrides, a Nokia BNG-UP can only have one unique link-local address per realm.

ICMPv6 RA messages use an RA profile. The RA profile is configured during authentication.

Use the ra-profile command in the following context to configure the RA profile locally.
configure mobile-gateway profile bng

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 MAG-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 MAG-c sends ICMPv6 RA messages to the unicast MAC address of the session, otherwise the MAG-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 by default enabled.
    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 MAG-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 IPv6 header of 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 other-configuration flag in the ICMPv6 RA message is enabled. If the other-configuration 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 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 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 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 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 MAG-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 BNG-UP/MAG-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 and preferred commands in the following context. 
configure mobile-gateway profile authentication-database entry address-assignment lifetimes
Valid and preferred lifetimes are common for all IPv6 addresses of a session.
The server DUID is by default based on the MAG-c system name. To override the default server DUID per APN, use the dhcpv6-server-duid command in the following context.
configure mobile-gateway pdn apn

The MAG-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 MAG-c considers the IA-NA address or IA-PD prefix for the session down and takes appropriate actions for the corresponding session (for example, bring the session down, or bring IPv6CP down).

As with DHCP, 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 dhcpv6-profile command in the following context 
    configure mobile-gateway profile bng
  • 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:
    • explicit options
    • authentication bulk options
    • DHCPv6 profile options
    • 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 MAG-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 MAG-c sends ICMPv6 RA messages so the client can learn its default gateway address. For consistency, the MAG-c sends DHCPv6 messages with a link-local address that is the same as the source address in ICMPv6 RA messages.