Address assignment

The cMAG-c supports various address assignment options, including local address assignment via ODSA, local static address assignment via authentication database, AAA-based address assignment, non-provisioned address assignment, and external DHCPv4 and DHCPv6 server address assignment.

Overview of address assignment

For sessions that require direct connectivity to a Layer 3 network, the cMAG-c supports the following address assignment options:

  • local address assignment via ODSA
  • local static address assignment via authentication database
  • AAA-based address assignment
  • non-provisioned address assignment
  • external DHCPv4 and DHCPv6 server address assignment

Additionally, the cMAG-c allocates corresponding prefixes (micro-nets) for the MAG-u, to allow a MAG-u device to send aggregate routes without announcing the per-session routes. For IPv4, the cMAG-c assigns a dedicated gateway address per prefix. It is possible to select different address allocation methods for different address types of the same session. For example, IPv4 can use AAA-based address assignment while IPv6 PD can use a local pool. However, all allocation methods should be known after session authentication.

After session authentication, an address is allocated based on the local address assignment or the AAA-based address assignment. Addresses are always set up on the MAG-u as soon as they are allocated, independent of whether they are already signaled in associated assignment protocols such as DHCP or IPCP.

ODSA and local address assignment

ODSA can be used to assign a local address, to assign an aggregate prefix per MAG-u, and to derive the default gateway.

ODSA

On demand subnet allocation (ODSA) is a dedicated CUPS address assignment system.

ODSA is a dedicated CUPS address assignment system that can automatically split a common subnet into smaller subnets (micro-nets). The micro-nets are automatically installed on the associated MAG-u. The MAG-u announces the micro-nets in routing. ODSA can either assign an address itself (local address assignment) or work in combination with external address assignment systems (for example, AAA-based).

ODSA pools are configured on a per-network instance basis. A network instance represents a single IP routing context and maps to an IP service on the MAG-u (for example, to a VPRN). See Service selection for more information. ODSA guarantees that there is no overlap between addresses within one network instance.

The main function of ODSA is to assign subnets to an allocation context. The default allocation context is a single MAG-u. In resilient environments, the allocation context is a single fate sharing group (FSG). Each ODSA pool consists of one or more prefixes and is either configured in dedicated mode or with a target micro-net length.

  • dedicated mode

    In dedicated mode, a prefix is assigned directly to an allocation context. It is not divided into smaller micro-nets.

    To enable the dedicated mode, use the following command.
    subscriber-management services network-instance pool dedicated
    Note: The term micro-net in the documentation, state output, or show commands refers to the full prefix when using dedicated mode.
  • target micro-net length
    With a target micro-net length, all prefixes are divided into smaller, equally sized, micro-nets. Those smaller micro-nets are assigned to an allocation context.
    Note:

    In case of DHCPv6 prefix delegation, you can allocate a variable prefix length per session and a variable micro-net size.

    The following example shows the configuration of an ODSA pool with a target micro-net length.
    # info from running /subscriber-management services network-instance hsi pool hsi
    subscriber-management {
        services {
            network-instance hsi {
                pool hsi {
                    hold-time 300
                    ipv4 {
                        micro-net-length 28
                        prefix 192.0.2.0/24 {
                        }
                    }
                    ipv6 {
                        na {
                            micro-net-length 120
                            prefix 2001:db8:a00::/116 {
                            }
                        }
                        pd {
                            micro-net {
                                length 48
                            }
                            prefix 2001:db8:b00::/40 {
                            }
                        }
                        slaac {
                            micro-net-length 56
                            prefix 2001:db8:c00::/48 {
                            }
                        }
                    }
                }
            }
        }
    }

A subnet (either micro-net or dedicated prefix) can be assigned to only one context. When the first address of a subnet is assigned to a session, the subnet is assigned to the context of the session (for example, to a MAG-u). To guarantee that the full subnet can always be announced in routing without introducing routing conflicts, the following applies:

  • The subnet is only unlinked from the context after the last address of the subnet is released.
  • While a subnet is linked to a context, no address of the subnet can be assigned to another context, even if ODSA does not do the address assignment for the other context.
To generate a log event when the number of available free micro-nets is minimal, set a threshold using the following command.
subscriber-management services network-instance pool minimum-free
For IPv4 subnets, ODSA also assigns a default gateway address. To define whether the first or the last address in the subnet is selected for the default gateway address, set the default-gateway command to respectively first-address or last-address in the following context.
subscriber-management services network-instance pool ipv4
To associate default DNS servers with the ODSA pool, use the following commands.
subscriber-management services network-instance pool ipv4 dns primary
subscriber-management services network-instance pool ipv4 dns secondary
subscriber-management services network-instance pool ipv6 dns primary
subscriber-management services network-instance pool ipv6 dns secondary
Default DNS servers can be reflected in protocols such as IPCP, DHCP, ICMPv6, and DHCPv6, but sessions can get more specific individual DNS servers.

Local address assignment

ODSA can act as a stand-alone subnet allocation mechanism for MAG-u devices, but it can also assign addresses to individual sessions, without the need for additional configuration.

To allocate an address for a session, ODSA performs the following checks:

  • Are there subnets already linked to the allocation context of the session?
  • Do any of the linked subnets have available addresses?

If the answer to both questions is yes, an address from any of the linked subnets is allocated to the session.

If the answer to one of the questions is no, a new address is allocated from any subnet that is not yet linked to an allocation context. The subnet is automatically linked to the allocation context of the session. If no subnets are available, the address allocation fails.

To exclude one or more address ranges in a prefix from address allocation, use the following commands.
subscriber-management services network-instance pool ipv4 prefix exclude-address
subscriber-management services network-instance pool ipv6 slaac prefix exclude-prefix
subscriber-management services network-instance pool ipv6 na prefix exclude-address
subscriber-management services network-instance pool ipv6 pd prefix exclude-prefix

Excluded address ranges can be assigned with other allocation methods (for example, via AAA). In case of IPv4, excluded address ranges are not used for default gateway selection.

To stop assigning addresses from a prefix, use the following commands.
subscriber-management services network-instance pool ipv4 prefix drain
subscriber-management services network-instance pool ipv6 slaac prefix drain
subscriber-management services network-instance pool ipv6 na prefix drain
subscriber-management services network-instance pool ipv6 pd prefix drain

When a prefix is being drained, existing address allocations from the prefix remain allocated until the corresponding sessions are terminated.

When a prefix or entire pool is removed while allocations still exist, the prefix or pool is retained internally and put in a similar automatic drain mode. As with regular drain, existing allocations and sessions are not automatically removed. To expedite the cleanup of these pools, sessions must be manually removed, for example, by using the following command with the ip-prefix parameter set.
tools subscriber-management session clear

Local address assignment can be combined with AAA-based address assignment for different address types. For example, IPv4 and IPv6 PD can use local address assignment while IPv6 NA can use AAA-based assignment.

AAA-based address assignment from RADIUS, HSS, or UDM

AAA services such as RADIUS, HSS, or UDM can provide an address during authentication. The cMAG-c marks the AAA-based address as in use in the ODSA pools and allocates the micro-net to the corresponding context (for example, the MAG-u). In the case of IPv4, the default gateway is assigned using ODSA.

AAA-based addresses can fall within an exclude-addresses range.

Setup of the new session fails in specific situations including the following:

  • The address is already allocated to another session.
  • The corresponding micro-net is allocated to a context (for example, UP or FSG) that does not match the context of the session.

The prefix pool on which ODSA operates can be used in the following ways:

  • If the AAA service provisions both an address pool and an explicit IP address for the same address type (for example, IPv4 or IPv6 PD), ODSA uses the explicit IP address for assignment and the pool for marking the address and allocating MAG-u prefixes and IPv4 gateway addresses.
  • In the absence of a pool signaled by AAA itself, pools can be provisioned using the following commands.
    subscriber-management authentication-database entry address-assignment unmanaged ipv4-pool
subscriber-management authentication-database entry address-assignment unmanaged ipv6-slaac-pool
subscriber-management authentication-database entry address-assignment unmanaged ipv6-na-pool
subscriber-management authentication-database entry address-assignment unmanaged ipv6-pd-pool
  • In the absence of any pool during authentication, a default fallback pool can be provisioned per service using the following commands.
    subscriber-management services service address-assignment-defaults unmanaged ipv4-pool
subscriber-management services service address-assignment-defaults unmanaged ipv6-slaac-pool
subscriber-management services service address-assignment-defaults unmanaged ipv6-na-pool
subscriber-management services service address-assignment-defaults unmanaged ipv6-pd-pool

When no dedicated pools are available, ODSA assigns micro-nets to a context. It is important that the AAA service is aware of the micro-net sizes and that addresses are allocated per context within the scope of a micro-net.

For example, the prefix 192.168.0.0/16 is available, to which addresses are allocated per MAG-u in the AAA. All sessions of MAG-u "east" fall within 192.168.1.0/24 and all sessions of MAG-u "west" fall within 192.168.2.0/24. In this case, it is not necessary to provision these per-MAG-u prefixes on the cMAG-c. The cMAG-c has provisioned a non-dedicated pool with prefix 192.168.0.0/16 and micro-net length 24 and automatically derives the /24 prefixes based on the AAA-based addresses.

The following requirements apply when using ODSA pools for a mix of AAA-based addresses and locally assigned addresses:

  • The AAA-based addresses must fall within the configured exclude-addresses ranges to avoid conflicts with local assigned addresses.
  • If a pool is not dedicated to a specific context (for example, the MAG-u), the exclude-addresses ranges should align with a micro-net size. This is required to avoid the case where a locally-assigned address allocates the corresponding micro-net to a different context.

Because of the complexity of the requirements, Nokia recommends having a non-dedicated pool for AAA-based address assignment and a separate non-dedicated pool for local address assignment.

AAA framed routes

The cMAG-c supports AAA provisioned framed routes for sessions with ip-anti-spoof disabled (set to false); for example, using the Framed-Route and Framed-IPv6-Route RADIUS attributes. The cMAG-c installs these routes on the MAG-u using the PFCP protocol. The cMAG-c does not check these routes for overlap with other framed routes or session allocated addresses. Framed routes are supported for all address assignment types, and not restricted to AAA-based address allocation.

Non-provisioned address assignment

Configuration of the support for non-provisioned addresses in the ADB allows an external entity to assign the session address.

When an external entity managed by a third party assigns the session address, the operator is not aware of the subnet/prefix where the address is assigned from. Therefore, the operator cannot provision this subnet/prefix on the BNG system.

To support the above use case, the operator can configure the support of non-provisioned addresses in the ADB for one or multiple address types. The address assigned by the external entity becomes the unmatching address for the session if the following applies:
  • After ADB lookup, non-provisioned addresses are supported for the new session.
  • The external source assigns an address of a configured address type.
  • The address is not within any subnet/prefix of the configured ODSA pool.
To support unmatching addresses of specified address types, use the following command.
subscriber-management authentication-database entry address-assignment unmatching-prefix allow

The cMAG-c cannot send the subnet/prefix information to the MAG-u because the subnet/prefix for the unmatching address is not provisioned on the BNG system. Therefore, the MAG-u has /32 or /128 routes for each unmatching address, or the exact prefix route for an IPv6 SLAAC delegated prefix.

The following applies to an unmatching address via DHCPv4:

  • The cMAG-c automatically generates a default router address and returns it in the DHCP reply. This auto-generated default router address is not passed to the MAG-u, so the MAG-u uses the ARP proxy to answer the client’s ARP request for the default router address.

    To generate the default router address, the host address part of the assigned address is set to one, or to two if the host address part already equals one. The following examples illustrate the generation of the default router address:

    • The assigned address is 172.16.3.139 and the netmask is /28, so the host bits are the last 4 bits. 139 equals the binary number 0b10001011. The value of the host bits does not equal 1. When setting the value of the last 4 bits to 1, it becomes 0b10000001 or 129. The default router address is 172.16.3.129.
    • The assigned address is 172.16.3.129 and the netmask is /28, so the host bits are the last 4 bits. 129 equals the binary number 0b10000001. The value of the host bits already equals 1. When setting the value of the last 4 bits to 2, it becomes 0b10000010 or 130. The default router address is 172.16.3.130.
  • If the external source does not return a subnet mask, the cMAG-c automatically generates one, and returns it in the DHCP reply.

Local static address assignment via authentication database

To return the same configured address to a specific client, the cMAG-c supports the following static address options:

  • IPv4 address
  • IPv6 NA address
  • IPv6 PD prefix
  • IPv6 SLAAC prefix
Configure the address using the following commands.
subscriber-management authentication-database entry address-assignment unmanaged ipv4-address
subscriber-management authentication-database entry address-assignment unmanaged ipv6-slaac-prefix
subscriber-management authentication-database entry address-assignment unmanaged ipv6-na-address
subscriber-management authentication-database entry address-assignment unmanaged ipv6-pd-prefix
These addresses interact with ODSA micro-nets in the same manner as AAA-based address assignment, as described in AAA-based address assignment from RADIUS, HSS, or UDM.

External DHCPv4 and DHCPv6 server address assignment

An external DHCPv4 or DHCPv6 server can assign a session address via cMAG-c acting as a DHCPv4 or DHCPv6 relay agent, which relays DHCP messages between the client and the external server.

During authentication, only the ADB (and not RADIUS) can return DHCP relay configuration, including an external server address, a tracking pool, a DHCPv4 giaddr, and a DHCPv6 link address. The cMAG-c uses that ADB configuration to relay the DHCP messages.

Note: Relaying a DHCP server initiated exchange (such as DHCPv4 Force-renew or DHCPv6 Reconfigure) is not supported.

Local ODSA pool tracking

In case of DHCP relay, the external server assigns the address and the cMAG-c tracks the assigned address, subnet, and default gateway to make sure there is no conflict in the assignments.

To track the DHCP relay address assignments, specify a local ODSA tracking pool under the DHCP relay configuration in the ADB. The subnets and prefixes configured in the tracking pool must be the same as in the external server. The tracking pool is not used to allocate micro-nets; it is a dedicated pool that can only be used to track the DHCP relay assignments.

Use the following command to create a tracking pool.
subscriber-management services network-instance pool tracking dhcp-relay
Use the commands in the following context to configure the tracking pool.
subscriber-management services network-instance pool

DHCPv4 relay

The following figure shows the DHCPv4 call flow.
Figure 1. DHCPv4 call flow

Because the DHCPv4 server sends responses to the giaddr, the giaddr must be provisioned via the Kubernetes service. See the cMAG-c Installation Guide for more information.

ADB configuration for DHCPv4 relay

# info from running /subscriber-management authentication-database adb1 entry 10 address-assignment

    dhcp-relay {
        ipv4 {
            gi-address 172.100.100.101
            pool relay-pool
            server-list {
                server [
                    10.96.212.90
                ]
            }
        }
    }

DHCPv6 relay

The cMAG-c as a DHCPv6 relay server supports the following cases:
  • The DHCPv6 client starts the call flow with a Router Solicit (RS) message.
  • The DHCPv6 client does not send the RS message.
  • The DHCPv6 client is behind a lightweight DHCPv6 relay agent (LDRA).

Call flow with RS message

The DHCPv6 client first sends an RS message. When the M bit in the Router Advertisement (RA) message is set, the client starts the DHCPv6 message exchange.

The following figure shows the DHCPv6 call flow for a client sending the RS.
Figure 2. DHCPv6 call flow with RS message

Call flow without RS message

The following figure shows the DHCPv6 call flow when a DHCPv6 client starts the DHCPv6 message exchange without first sending an RS message.

Figure 3. DHCPv6 call flow without RS message

Call flow behind an LDRA

The DHCPv6 client is behind an LDRA. The LDRA sends a Relay-forward message to the cMAG-c and the cMAG-c replies with a Relay-reply message.

Configuration specifics

The configuration of an RA profile in the ADB customizes the content of the RA message. Use the following command to configure an RA profile.
subscriber-management profiles ra-profile

The source address of the Relay-forward message is typically the worker, because the DHCPv6 proxy pod, which is deployed as a daemon, handles the message forwarding between the cMAG-c and the DHCPv6 server.

Use the following command to configure a link address that the server can use to select a pool and prefix.
subscriber-management authentication-database entry address-assignment dhcp-relay ipv6 link-address

DHCPv6 relay configuration

# info from running /subscriber-management authentication-database adb1 entry 10 address-assignment

    dhcp-relay {

        ipv6 {
            link-address 2001:9999::1
            pool p2
            server-list {
                server [
                    2001:beef::100
                ]
            }
        }
    }

DHCP options

DHCPv4

Use the following commands to configure a DHCPv4 profile for the specified direction:

  • from the cMAG-c toward the DHCP server
    subscriber-management authentication-database entry address-assignment dhcp-relay ipv4 to-server-dhcp-option-profile
    This profile references a DHCP option profile that specifies the DHCP options that are sent to the server, including the relay-agent options such as the circuit ID and remote ID. A drop or replace action can be configured for the received DHCPv4 Request message from the client.
  • from the cMAG-c toward the DHCP client
    subscriber-management authentication-database entry to-client-dhcp-option-profile
    This profile specifies the DHCPv4 options that are sent to the client. Relay-agent options do not apply in this direction.

DHCPv6

Use the following command to configure a DHCPv6 profile that specifies the DHCPv6 options for the Relay-forward message.
subscriber-management authentication-database entry address-assignment dhcp-relay ipv6 to-server-dhcpv6-option-profile
Because a relay agent cannot modify the encapsulated message (per RFC 8415), the cMAG-c inserts the options at the top level of the generated Relay-forward message, and not in the encapsulated message.

This profile can include relay agent options, such as interface ID and remote ID.

DHCP relay and MAG-u redundancy

Note: The content of this chapter only applies if the following conditions are both met:
  • MAG-u redundancy is enabled.
  • The server relies on the cMAG-c insert option for pool or subnet, and client identification.
If the external server uses a DHCP option inserted by the access node, not configuring any to-server-dhcp-option-profile or to-server-dhcpv6-option-profile ensures that the option inserted by the access node is not changed during MAG-u switchover.

Access ports and VLANs on multiple MAG-u nodes can be part of the same UP group in case of MAG-u redundancy. Consequently, the same set of sessions may come from different ports, VLANs, or MAG-u nodes depending on the active MAG-u. Therefore, when the DHCP server assigns an address or prefix to a session with MAG-u redundancy enabled and while relying on an option inserted by the cMAG-c to select pool or subnet, it must take the UP group into consideration to avoid sharing subnets or prefixes between different UP groups.

Use one of the following options to prevent sharing subnets or prefixes between different UP groups:

  • If the DHCP server uses the giaddr or link address to select a pool or subnet, configure one unique giaddr or link address per UP group on the cMAG-c and use one pool or subnet per UP group on the DHCP server.
  • Use the following commands to configure the UP group ID as circuit ID, remote ID, or interface ID in the DHCPv4 or DHCPv6 profile for sessions with MAG-u redundancy enabled. The UP group does not change during MAG-u switchover.
    subscriber-management profiles dhcp-option-profile relay-agent sub-option circuit-id
subscriber-management profiles dhcp-option-profile relay-agent sub-option remote-id
subscriber-management profiles dhcpv6-option-profile append option remote-id 
subscriber-management profiles dhcpv6-option-profile append option interface-id

For the DHCP renew to work, the client identification as seen by the DHCP server must be the same during the MAG-u switchover; for example, in case of a MAG-u switchover to a different MAG-u, port, or VLAN, the client identification must be the same. When the DHCP server uses the circuit ID, remote ID, or interface ID as the client identification, and if the port ID is different on the MAG-u nodes for a specific UP group, configure the same Layer 2 access ID alias on all MAG-u nodes in the UP group to obtain the same client identification.