The following example shows typical IPv4 address and IPv6 prefix pools.

The management of address pools in RBFS offers the flexibility to remove or modify them without causing any disruptions to existing subscribers. This means that even after an address pool has been deleted, the subscribers who were assigned addresses from that pool can still retain and utilize those addresses.

To illustrate, let’s consider a scenario where a subscriber has been allocated an IP address from a specific pool, and later on, that pool is deleted. Despite the pool’s removal, the subscriber can continue using the assigned IP address until their session is terminated. Operators are responsible for ensuring that the address pool is not allocated elsewhere until it’s finally released.

RBFS supports an optional feature known as duplicate address detection. This functionality aims to prevent sessions from logging in if they attempt to use an already-used address. However, it’s important to note that this safeguard doesn’t apply if the address pool is moved to a different BNG. In such cases, duplicate address detection might not work as anticipated, emphasizing the need for careful management and planning when migrating address pools across different BNGs.

Multiple address pools can be linked together using the next-pool-name attribute to form a larger pool of discontinuous ranges.

A -→ B -→ C -→ D

The actual address pool assigned to a subscriber from the access configuration profile or RADIUS defines the start pool, which could be any pool in the chain. If this pool is already full, the next pool is requested, which repeats until a free pool is found or the end of the chain is reached. RBFS also stops automatically as soon as one pool of the chain was entered twice (loop protection).

This chain can also be closed to a loop to ensure that all pools of a chain are considered if one pool from the middle of the chain is allocated.

A -→ B -→ C -→ D -→ A