Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    IPCP Renegotiation of IPv4 Addresses for Dual-Stack Subscribers

    After the PE device or the router receives an IPCP configuration request from the CPE, which starts the IPCP negotiation process, the B-RAS application running on the router requests a new IPv4 address from the RADIUS server. The router or the RADIUS client sends an Access-Request message with the Ipv4-release-control RADIUS VSA attribute [26-164] included in it, along with all the other attributes that are supported for inclusion in the Access-Request message. After successful authentication, the RADIUS server sends the Access-Accept message with all of the supported attributes for all established sessions. For IPCP negotiations, the following attributes are not contained in the Access-Accept message if the Access-Request message contains the Ipv4-release-control attribute:

    • [26-58] LI-Action
    • [27] Session-Timeout
    • [28] Idle-Timeout
    • Service Manager attributes

    The Access-Accept message received from the RADIUS server contains the updated IPv4 settings in the Ascend-Data-Filter attribute for IPv4 sessions. This modified policy defined in the Ascend-Data-Filter attribute for IPv4 clients is applied on the RADIUS client. The IPv4 policy associated with the Ascend-Data-Filter attribute is removed when the IPv4 address is released. If the Access-Accept message during an IPCP negotiation contains the IPv6 policy in the Ascend-Data-Filter attribute, it is disregarded. IPv6 policy parameters are already configured on the router when the authentication of the dual-stack subscriber occurred previously during initial establishment of the session. After an IPv4 address is received from the RADIUS server, a validation for a duplicate address is performed. If the received IPv4 address is determined to be a duplicate address, the subscriber session is completely terminated. If the duplicate address validation completes successfully, PPP performs IPCP negotiation with the CPE.

    If the IPCP negotiation is successful, the RADIUS client sends an immediate accounting message with the Ipv4-release-control [26-164] and Framed-Ip-Address [8] attributes included in it without waiting for the configured interim accounting interval. If the IPCP negotiation is not successful, the Interim-Acct message is sent with the Ipv4-release-control [26-164] attribute added and the Framed-Ip-Address [8] attribute excluded. This type of interim accounting message indicates to the RADIUS server to release the IPv4 address to enable optimal utilization of the addresses in the pool.

    After the IPCP renegotiation for the IPv4 address, the interim accounting message is sent with all of the supported attributes, including the negotiated address, the Framed-Ip-Address attribute, and IPv6 prefixes. If the RADIUS server sends only IPv6 prefixes and does not return an IPv4 address when the CPE sends an IPCP renegotiation for an IPv4 address, PPP sends a Protocol Reject message to the CPE. In this case, the interim accounting interval for communicating to the RADIUS server about released IPv4 addresses does not impact the configured interval for Acct-Start and Acct-Stop messages. If the RADIUS server sends only IPv4 addresses and does not return an IPv4 address when the CPE sends an IPCP renegotiation for an IPv6 address, PPP sends a Protocol Reject message to the CPE.

    If the RADIUS server returns both the IPv4 and IPv6 addresses in the initial Access-Accept message, and if the CPE does not negotiate the IPv4 address, the IPv4 address is not released and the client can perform IPCP negotiations for the IPv4 address. The router initiates the IPCP negotiation only when the Framed-Ip-Address attribute is contained in the Access-Accept message. If the CPE sends a Protocol Reject packet to the router, the IPCP negotiation is not conducted for the current user session.

    When the IPCP negotiations for both IPv4 and IPv6 addresses are terminated in a particular established subscriber session because no service is available, the complete session is closed. In this scenario, the router does not attempt to initiate an IPCP negotiation and sends an LCP terminate request packet and a PPPoE Active Discovery Termination (PADT) packet when NCP is not active in that session.

    The attributes contained in the RADIUS access and accounting messages during an IPCP renegotiation for IPv4 addresses for clients in a dual-stack network is slightly different from the attributes included in these messages during the initial session establishment. See AAA Access Messages During IPCP Negotiations for Dual-Stack Subscribers and AAA Accounting Messages During IPCP Negotiations for Dual-Stack Subscribers for detailed information on the attributes transmitted in these messages.

    Rate Limit on IPCP Negotiations

    With the capability to enable PPP to notify the AAA server regarding released IPv4 addresses, the CPE can dynamically negotiate IPv4 addresses and exchange IPCP packets at any point during the PPP session. To prevent the B-RAS application on the router from being flooded with a large burst of IPCP packets from the CPE, a rate-limit is pre-configured for the IPCP negotiations for IPv4 addresses per subscriber and for the number of IPv4 address requests received per line module. These rate-limit settings are configured in the interface controller and not the forwarding controller. The time interval during which the number of renegotiation requests must be restricted is set to 60 seconds by default. Within this period, the maximum number of renegotiations permitted per client is six. For each PPP subscriber, a counter is maintained in the PPP application to record the number of IPCP negotiations performed during this time period to avoid a flood of IPCP packets. This counter is incremented after a successful IPCP negotiation. You can configure the maximum number of successful IPCP renegotiations for IPv4 addresses that the router can receive per subscriber by using the ppp ipcp-max-negotiation maxRenegotiationsCount command. These settings are effective when you configure the router with the capability to send a notification to the AAA server regarding released IPv4 addresses in a dual-stack environment by using the aaa ipv4-addr-saving command. You can also specify the interval during which the maximum number of IPCP renegotiations per subscriber needs to be restricted by using the ppp ipcp-nego-duration RenegotiationsInterval command.

    If the CPE attempts to send an IPCP negotiation after the maximum permissible value is exceeded, a system logging message is generated and the statistics counter for rejected PPP sessions is incremented. IPCP negotiation is gracefully terminated by the PE device or the router. After the maximum number of configured IPCP negotiations per subscriber is exceeded, the router blocks that particular subscriber from further IPCP negotiations for a pre-configured time period.

    Published: 2014-08-14