Address assignment

Overview of the address assignment, and details on the supported local (ODSA) and AAA-based 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

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 following commands:
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 config>mobile>pdn>laa>network-realm>pool>ipv6>pd>delegated-prefix context.
  • 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.

  1. Session 1 with prefix length 56 leads to the allocation of micro-net A.
  2. Session 2 with prefix length 64 leads to the allocation of a new micro-net B.
  3. Session 3 with prefix length 64 re-uses micro-net B.
  4. Session 4 with prefix length 56 re-uses micro-net A.
  5. 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 config>mobile>pdn>laa>network-realm>pool>ipv6>pd context. 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 config>mobile>pdn>laa>network-realm>pool context, is adapted as follows.

  • 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, NA) or the exclude-prefixes command (SLAAC, PD) in the following contexts:
  • config>mobile>pdn>laa>network-realm>pool>ipv4>prefix
  • config>mobile>pdn>laa>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:
  • config>mobile>pdn>laa>network-realm>pool>ipv4>prefix
  • config>mobile>pdn>laa>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 config>mobile>profile>adb>entry>address-assignment context.
  • In the absence of any pool during authentication, a pool can be provisioned per APN using the unmanaged command in the config>mobile>pdn>apn>address-assignment-defaults context.

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 to have 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 config>mobile>profile>adb>entry>address-assignment context.

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 config>mobile>pdn>apn context. 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.