Local Address Pool Configuration

If your network environment requires local address pools that serve as a source of IPv4 or IPv6 addresses temporarily leased for use by remote IKEv2 peers, use the procedures in the following two sections to configure such pools.

During the IKE_AUTH exchange, the IPsec initiator (the remote endpoint) often requests an internal IP address from an IPsec responder (the Oracle Communications Session Border Controller). Refer to Section 2.19 of RFC 7296, Internet Key Exchange (IKEv2) Protocol, for a description of the request process. Procuring such a local IP address ensures that traffic returning to the endpoint is routed to the OCSBC, and then tunneled back to the endpoint. Local address pools provide the source of these addresses available for temporary endpoint lease.

After address assignment from the local address pool, the endpoint retains rights to that IP address for the tunnel lifetime. Tunnels are terminated either by an INFORMATIONAL exchange, defined in Section 1.4 of RFC 7296, or by expiration of the tunnel SAs as specified by the v2-ike-life-seconds and v2-ipsec-life-seconds configuration parameters. In either case, a subsequent request for an assigned IP address may, or may not result, in the assignment of the previous IP address. However, the OCSBC can be configured to ensure that a prematurely terminated tunnel, resulting for example from the reset or re-boot of the remote IP peer, can be restored with that previous address. Refer to Persistent Tunnel Addressing in this chapter for operational and configuration details.

During the IKE_AUTH request phase, the IKEv2 initiator can use the Configuration payload in conjunction with either the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attribute to request the addresses of DNS providers from the OCSBC. In environments where authorization is performed by a RADIUS AAA server, there are two potential sources of DNS information: local OCSBC DNS configuration elements, and external RADIUS servers that may provide DNS information in the Access-Accept packet that concludes a successful authentication effort. The source of DNS information provided by the OCSBC to an IKEv2 peer is subject to user configuration.

A RADIUS source of DNS information is enabled by support for certain Microsoft vendor-specific RADIUS attributes specified in RFC2548, Microsoft Vendor-Specific RADIUS Attributes. Operationally, the OCSBC extracts the values of the 
MS-Primary-DNS-Server and MS-Secondary-DNS-Server attributes from an 
Access-Accept packet and returns these values to the IKEv2 initiator.

When the DNS information is from external source, the OCSBC installs a NAT flow (a static traffic path) that provides access to the DNS server. The NAT flow is calculated based on the location of the DNS server IP returned from RADIUS AAA server and configured realm information.

Configuration of DNS information services takes place at the local address pool and IKEv2 interface levels.