Address assignment

Overview of address assignment

For sessions that require direct connectivity to a Layer 3 network, the MAG-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 MAG-c allocates corresponding prefixes (micro-nets) for the BNG-UP, to allow a BNG-UP device to send aggregate routes without announcing the per-session routes. For IPv4, the MAG-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 BNG-UP 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 BNG-UP, 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 BNG-UP. The BNG-UP 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-realm basis. A network realm represents a single IP routing context and maps to an IP service on the BNG-UP (for example, to a VPRN). ODSA guarantees that there is no overlap between addresses within one network realm.

The main function of ODSA is to assign subnets to an allocation context. The default allocation context is a single BNG-UP. 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.
```
configure mobile-gateway pdn local-address-assignment network-realm pool dedicated
```
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.

A:BNG-CPF# /configure mobile-gateway pdn 1 local-address-assignment
A:BNG-CPF>config>mobile>pdn>laa# info  
----------------------------------------------
                network-realm "hsi"
                    pool "hsi"
                        ipv4
                            micro-net-length 28
                            prefix 192.0.2.0/24
                            exit
                        exit
                        ipv6 
                            pd 
                                micro-net length 48 
                                prefix 2001:db8:b00::/40 
                                exit 
                            exit 
                            na 
                                micro-net-length 120 
                                prefix 2001:db8:a00::/116 
                                exit 
                            exit 
                        exit 
                    exit
                exit
----------------------------------------------

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 BNG-UP). 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.

configure mobile-gateway pdn local-address-assignment network-realm 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 choice variable to respectively first-address or last-address in the following command:

configure mobile-gateway pdn local-address-assignment network-realm pool ipv4 default-gateway

To associate default DNS servers with the ODSA pool, use the primary-dns and secondary-dns commands in the following contexts:

configure mobile-gateway pdn local-address-assignment network-realm pool ipv4 dns
configure mobile-gateway pdn local-address-assignment network-realm pool ipv6 dns

Default DNS servers can be reflected in protocols such as IPCP, DHCP, ICMPv6, and DHCPv6, but sessions can get more specific individual DNS servers.

Variable prefix length and micro-net length

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

You can allocate a variable prefix length per session instead of a fixed prefix length for the whole pool in case of DHCPv6 prefix delegation. The following enables a variable prefix length per session.

Configure a minimum and maximum prefix length for ODSA using the variable command in the following context.
```
configure mobile-gateway pdn local-address-assignment network-realm pool ipv6 pd delegated-prefix
```
Provision different prefix lengths per session during session setup.

ODSA allocates a micro-net per prefix length. For example, consider the following sequence of session setups, all within the same ODSA pool and BNG-UP.

Session 1 with prefix length 56 leads to the allocation of micro-net A.
Session 2 with prefix length 64 leads to the allocation of a new micro-net B.
Session 3 with prefix length 64 re-uses micro-net B.
Session 4 with prefix length 56 re-uses micro-net A.
Session 5 with prefix length 60 leads to the allocation of a new micro-net C.

When only one micro-net length is configured, this leads to unequally loaded micro-nets. For example, for a micro-net length of 52 with variable prefix lengths 64 and 56, each micro-net can hold up to 4096 /64 prefixes, but only 16 /56 prefixes. When the variable prefix length range is big, this is not wanted. For example, an allowed prefix length range of 48 to 64 requires at least a /44 micro-net, which can cover up to 1048576 /64 prefixes.

To solve this, you can provision a variable micro-net length. Configure a minimum and a maximum micro-net length using the micro-net variable command in the following context.

configure mobile-gateway pdn local-address-assignment network-realm pool ipv6 pd

With a variable micro-net length, the system automatically chooses the micro-net length that best fits the corresponding prefix length. The following examples illustrate that the configuration must be done carefully.

For a variable micro-net length between 42 and 50, and a variable prefix-length between 56 and 64, the system allocates a /50 micro-net for a /64 prefix, a /42 micro-net for a /56 prefix, and a /46 micro-net for a /60 prefix. Each micro-net holds up to 16384 prefixes, independent of its length.
For a variable micro-net length between 48 and 50, and a variable prefix-length between 54 and 64, the system allocates a /50 micro-net for a /64 prefix which holds 16384 prefixes, and a /48 micro-net for a /54 prefix which holds 64 addresses.

When using variable micro-net lengths, the number of free micro-nets is not deterministic. A micro-net with a small length uses a bigger chunk of the pool than a micro-net with a large length. Therefore, the threshold mechanism, configured using the minimum-free command in the following context, is adapted as follows.

configure mobile-gateway pdn local-address-assignment network-realm pool

When the minimum-free configuration is an absolute value, the threshold takes into account the biggest micro-net size. A log event is generated as soon as there is not enough space in the pool to allocate the configured amount of micro-nets with the minimum length.
When the minimum-free configuration is a percentage, the threshold takes into account the smallest micro-net size. A log event is generated as soon as there is not enough space in the pool to allocate the configured percentage of micro-nets with the maximum length.

Local address assignment

ODSA can act as a stand-alone subnet allocation mechanism for BNG-UP 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 exclude-addresses command (IPv4, IPv6 NA) or the exclude-prefixes command (SLAAC, IPv6 PD) in the following contexts:

configure mobile-gateway pdn local-address-assignment network-realm pool ipv4 prefix

configure mobile-gateway pdn local-address-assignment network-realm pool ipv6

slaac prefix
na prefix
pd prefix

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

To stop assigning addresses from a prefix, configure the drain mode for the prefix using the drain command in the following contexts:

configure mobile-gateway pdn local-address-assignment network-realm pool ipv4 prefix

configure mobile-gateway pdn local-address-assignment network-realm pool ipv6

slaac prefix
na prefix
pd prefix

Existing address allocations from the prefix remain allocated until the corresponding sessions are terminated.

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

AAA services can provide an address during authentication. The MAG-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 BNG-UP). In the case of IPv4, the default gateway is assigned using ODSA.

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

Setup of the new session fails in situations such as the following:

the address is already allocated to another session
the corresponding micro-net is allocated to a context 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 BNG-UP prefixes and IPv4 gateway addresses.
In the absence of an AAA pool, a pool can be provisioned using the unmanaged command in the following context.
```
configure mobile-gateway profile authentication-database entry address-assignment
```
In the absence of any pool during authentication, a pool can be provisioned per APN using the unmanaged command in the following context.
```
configure mobile-gateway pdn apn address-assignment-defaults
```

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 BNG-UP in the AAA. For example, all sessions of BNG-UP1 fall within 192.168.1.0/24 and all sessions of BNG-UP2 fall within 192.168.2.0/24. In this case, it is not necessary to provision these per-BNG-UP prefixes on the MAG-c. The MAG-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 BNG-UP), 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.

The MAG-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 MAG-c installs these routes on the BNG-UP using the PFCP protocol. The MAG-c does not check these routes for overlap with other framed routes or session allocated addresses.

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 (for example, a RADIUS server) 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 unmatching-prefix allow command in the following context.

configure mobile-gateway profile authentication-database entry address-assignment

The MAG-c cannot send the subnet/prefix information to the BNG-UP because the subnet/prefix for the unmatching address is not provisioned on the BNG system. Therefore, the BNG-UP 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 MAG-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 BNG-UP, so the BNG-UP 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 MAG-c automatically generates one, and returns it in the DHCP reply.

For an unmatching IPv4 address of a PPPoE session, to configure the IPv4 loopback address used as the BNG address in the IPCP negotiation in the corresponding APN, use the realm-loopback-address in the following context.

configure mobile-gateway pdn apn

The MAG-c sends the loopback address to the BNG-UP in the PFCP Session Establishment Request message.

Local static address assignment via authentication database

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

IPv4 address
IPv6 NA address
IPv6 PD prefix
IPv6 SLAAC prefix

Configure the address in the following context.

configure mobile-gateway profile authentication-database entry address-assignment unmanaged

Optionally, use the same context to configure the ODSA pool name.

If the authentication returns an unmanaged ODSA pool name with the address, the address is with the ODSA pool.
If no unmanaged ODSA pool name is returned with the address, the static address assignment is treated as a non-provisioned address assignment.

Address assignment for data-triggered IPoE sessions

Data-triggered IPoE sessions support the following address assignment methods:

AAA-based static address assignment
static address assignment from ADB
using the source IP address of the data trigger

The addresses and prefixes assigned during data-triggered IPoE session setup are also used in DHCP/DHCPv6 address assignment when MAG-c receives DHCP/DHCPv6 packets from data-triggered IPoE sessions.

Use the commands in the following context to configure data-triggered source IP handling in address assignment.

configure mobile-gateway profile authentication-database entry address-assignment initial-ip-handling data-trigger

Use the following command to configure source IP options for data-triggered IPoE sessions. The ignore option for this command forces address assignment from the ADB entry or AAA. The unmanaged-default option populates an unmanaged address or prefix based on a source IP address.

configure mobile-gateway profile authentication-database entry address-assignment initial-ip-handling data-trigger source-ip

Configure the following command together with the unmanaged-default option, to define the source IPv6 address modeling in the IPoE session.

configure mobile-gateway profile authentication-database entry address-assignment initial-ip-handling data-trigger ipv6-address-assignment-type

External DHCPv4 and DHCPv6 server address assignment

An external DHCPv4/v6 server can assign a session address via MAG-c acting as a DHCPv4/v6 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 MAG-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 MAG-c tracks the assigned address, subnet, and default-gw 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 same as in 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 with the tracking dhcp-relay keywords to create a tracking pool. Use the commands in this context to configure the tracking pool.

configure mobile-gateway pdn local-address-assignment network-realm pool

DHCPv4 relay

The following figure shows the DHCPv4 call flow.

The DHCPv4 server sends its responses to the giaddr. Therefore, the giaddr must configured on a MAG-c IP interface that is reachable by the DHCPv4 server. Typically, this is a /32 address on a loopback interface.

If the giaddr is also used for pool or subnet selection by the server, the MAG-c must advertise a /32 route for the giaddr to make sure that the DHCP response from the server reaches the MAG-c, and not the BNG-UP.

ADB configuration for DHCPv4 relay

config>mobile>profile>adb>entry# info
----------------------------------------------
                    address-assignment
                        dhcp-relay
                            ipv4
                                gi-address 21.21.0.1
                                pool "p2"
                                router "Base"
                                server 172.16.20.100
                            exit
                        exit
                    exit

DHCPv6 relay

The MAG-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 DHCPv6 client starts the DHCPv6 message exchange without first sending an RS message.

The following figure shows the DHCPv6 call flow when a client does not send the RS.

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 MAG-c and the MAG-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.

configure mobile-gateway profile authentication-database entry ra-profile

Use the following command to configure the source address of the relay-forward message to the server. The DHCPv6 server sends its response to the source address of the received request message.

configure mobile-gateway profile authentication-database entry address-assignment dhcp-relay ipv6 source-ip-address

Use the following command to configure a link address that the server can use to select a pool and prefix.

configure mobile-gateway profile authentication-database entry address-assignment dhcp-relay ipv6 link-address

DHCPv6 relay configuration

config>mobile>profile>adb>entry>address-assignment# info
----------------------------------------------
                        dhcp-relay
                            ipv6
                                link-address 2001:9999::1
                                pool "p2"
                                router "Base"
                                source-ip-address 2001:beef::1
                                server 2001:beef::100
                            exit
                        exit
----------------------------------------------

DHCP and DHCPv6 for data-triggered IPoE sessions

For data-triggered IPoE sessions, MAG-c supports address assignment for IPv4, IPv6 NA, and IPv6 PD address stacks.

The following packets can trigger an address-assignment process with lease-state creation and signaled-address association with the IP stack created by a data-trigger.

DHCP discover and request
DHCPv6 solicit, request, renew, and rebind

DHCP and DHCPv6 release messages that are received on a data-triggered IP stack, trigger removal of the entire IPoE session.

Dual-stack relay

If the ADB returns both a DHCPv4 and a DHCPv6 relay configuration, the MAG-c treats this as a dual-stack session.

The MAG-c behavior when relaying dual-stack sessions is as follows:

When the MAG-c receives a DHCPv4 Discover or a DHCPv6 Solicit message for a new session, it starts a 60s timer to guard the session setup time. The MAG-c relays the messages and waits until the message exchange with the external server for both stacks is finished (for example, until the reception of both DHCPv4 ACK and DHCPv6 Reply messages from the server) before starting the final PFCP session modification message exchange.

If the 60s timer expires before the message exchange for both stacks is finished, the session setup fails.
When the MAG-c receives a DHCPv4 or DHCPv6 Release message, it sends both the DHCPv4 and DHCPv6 Release messages to the server.
If the MAG-c initiates a session deletion, it sends both the DHCPv4 and DHCPv6 Release messages to the server.

Caution: The preceding behavior causes failure of a single-stack session setup when the ADB returns both a DHCPv4 and a DHCPv6 configuration. Therefore, for single-stack sessions, configure only a single-stack relay in the ADB.

Because the MAG-c removes both stacks at the same time, the DHCP server must use the same lease time for both DCHPv4 and DHCPv6 to avoid a stale lease on the client side.

DHCP options

DHCPv4

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

from the MAG-c toward the DHCP server
```
configure mobile-gateway profile authentication-database entry address-assignment dhcp-relay ipv4 options request-dhcp-profile
```
This profile specifies the DHCP options sent to the server, including relay agent options like circuit ID and remote ID.
from the MAG-c toward the DHCP client
```
configure mobile-gateway profile authentication-database entry address-assignment dhcp-relay ipv4 options response-dhcp-profile
```
This profile specifies the DHCPv6 options 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.

configure mobile-gateway profile authentication-database entry address-assignment dhcp-relay ipv6 options request-dhcp6-profile

Because a relay agent cannot modify the encapsulated message (see RFC 8415), the MAG-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 BNG-UP redundancy

Note: The content of this chapter only applies if the following conditions are both met:

BNG-UP redundancy is enabled.
The server relies on the MAG-c insert option for pool/subnet and client identification.

If the external server uses a DHCP option inserted by the access node, not configuring any request-dhcp-profile or request-dhcp6-profile makes sure that the option inserted by the access node is not changed during BNG-UP switchover.

Access ports and VLANs on multiple BNG-UPs can be part of the same UP group in case of BNG-UP redundancy. Consequently, the same set of sessions may come from different ports, VLANs, or BNG-UPs depending on the active BNG-UP. Therefore, when the DHCP server assigns an address or prefix to a session with BNG-UP redundancy enabled and while relying on an option inserted by the MAG-c to select pool/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 MAG-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 BNG-UP redundancy enabled. The UP group does not change during BNG-UPswitchover.

configure mobile-gateway profile bng dhcp-profile options relay-agent-options circuit-id
configure mobile-gateway profile bng dhcp-profile options relay-agent-options remote-id
configure mobile-gateway profile bng dhcpv6-profile options relay-agent-options remote-id
configure mobile-gateway profile bng dhcpv6-profile options relay-agent-options interface-id

If the preceding options are not feasible, provision a Python script on the MAG-c that converts the UP group VSO into an option and format that the server supports.

For the DHCP renew to work, the client identification as seen by the DHCP server must be the same during the BNG-UP switchover; for example, in case of a BNG-UP switchover to a different BNG-UP, 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, use one of the following methods to obtain the same client identification:

If the port ID is different on the BNG-UPs for a specific UP group, configure the same Layer 2 access ID alias on all BNG-UPs in the UP group, or use a Python script to change the circuit ID, remote ID, or interface ID to be the same.
If the VLAN tags are different on different BNG-UPs, use a Python script to change the circuit ID, remote ID, or interface ID to be the same.