Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Conservation of IPv4 Addresses for Dual-Stack PPP Subscribers Using On-Demand IPv4 Address Allocation

Conserving IPv4 Addresses for Dual-Stack PPP Subscribers Using On-Demand IPv4 Address Allocation

In a dual stack over PPP access network scenario, the dual-stack session remains running as long as either the IPv4 or IPv6 session is active. By default, when a subscriber terminates the IPv4 session, the BNG retains the IPv4 address that was allocated by AAA at login. The address is not released while the dual-stack PPP session is running. If the IPv4 session is renegotiated while the session is running, the same IPv4 address is assigned to the subscriber’s IPv4 session. This functionality results in inefficient use of IPv4 addresses.

You can conserve IPv4 addresses by configuring the router to release the IPv4 address if a subscriber is no longer using an IPv4 service. This feature provides on-demand IP address allocation or de-allocation after the initial PPP authentication and IPv6 address or prefix allocation.

The on-demand configuration does not take effect when the destination (peer) IP address is statically configured in the inet family of the PPP interface.

On-Demand IPv4 Address Negotiation and Release for Static PPP Subscribers Overview

This topic describes how on-demand IPv4 address allocation and de-allocation works for static dual-stack PPP subscribers.

IPv4 Address Negotiation for Static PPP Subscribers

The process for IPv4 address negotiation for a static inet family and address over a static PPP interface is as follows:

  1. PPP Link Control Protocol (LCP) is established and an IPv6 control protocol is successfully negotiated.

  2. The broadband network gateway (BNG) receives an Internet Protocol Control Protocol (IPCP) Configure Request with a 0.0.0.0 IPv4 address option from the customer premises equipment (CPE).

  3. The BNG sends an IPCP Configure Request with a local IPv4 address option to the CPE.

  4. The BNG sends an Access-Request message with the IPv4-Release-Control VSA (26-164) (if configured) to the RADIUS server.

  5. The BNG receives an IPCP Configure ACK from the CPE.

  6. The BNG receives an Access-Accept message from the RADIUS server.

    • If a Framed-IP-Address attribute is received, the BNG performs a duplicate address check (if configured). If a duplicate address check is completed successfully, PPP continues IPCP negotiation with the CPE. Otherwise, the entire PPP session is brought down by sending an LCP terminate request to the CPE.

    • If a Framed-Pool attribute is received, then the IPv4 address is allocated from the specified local address pool configured in the BNG. If the IP pool is not configured in the BNG and there is no other IP pool available, the BNG sends an LCP Protocol-Reject message to the CPE.

    • If neither a Framed-IP-Address attribute nor a Framed-Pool attribute is received, then the BNG allocates an IPv4 address from one of the configured local address pools. If the BNG cannot allocate an IPv4 address, the BNG sends an LCP Protocol-Reject message to the CPE.

    • If ADFv4 filters are present in the Access-Accept message, they need to be reinstalled for that subscriber in the BNG.

    • If both IPv4 primary and secondary DNS addresses are present in the Access-Accept message, then both need to be updated for that subscriber in the BNG. If either an IPv4 primary DNS address or an IPv4 secondary DNS address is present in the Access-Accept message, then only the corresponding DNS address needs to be updated for that subscriber.

    If an IPv4 address is not available, and the BNG receives an Access-Reject message from the RADIUS server, the following occurs:

    • If the Access-Reject message includes the IPv4-Release-Control VSA (26-164), the BNG sends an IPCP terminate request to the CPE. The CPE is then allowed to renegotiate IP NCP.

    • If the Access-Reject message does not include the IPv4-Release-Control VSA (26-164), the BNG sends an LCP Protocol-Reject message to the CPE. The CPE must renegotiate the LCP link before it is allowed to renegotiate IP NCP.

      If the RADIUS Access-Reject message includes the IPCP Terminate-Request field, the text of Reply Message attribute (18) is appended to the information in the Terminate-Request field, and will be shown in PPP data.

    If there is no response from the RADIUS server, then IPCP is terminated.

  7. The BNG sends an IPCP Configure NACK with the new IPv4 address option to the CPE.

  8. The subscriber secure policy service (if present for inet family) is activated.

    The BNG sends an immediate Interim-Accounting message (if configured) with the IPv4-Release-Control VSA (26-164) (if configured) and the Framed-IP-Address attribute to the RADIUS server.

  9. The BNG receives an IPCP Configure Request with new IPv4 address option from the CPE.

  10. The BNG receives an Interim-Accounting response from the RADIUS server.

  11. The BNG sends an IPCP Configure ACK to the CPE.

IPv4 Address Release for Static PPP Subscribers

The process for IPv4 address release for static inet family and address over static PPP interface is as follows:

  1. The BNG receives an IPCP terminate request from the CPE.

  2. The BNG sends an IPCP terminate ACK to the CPE.

  3. The following actions occur:

    • The subscriber secure policy service (if present for inet family) is de-instantiated.

    • If an IPv4 address was allocated from local address pool, the address then becomes available.

    • The IPv4 address entry is cleared from the subscriber record.

    • The BNG sends an immediate Interim-Accounting message (if configured) with the IPv4-Release-Control VSA (26-164) (if configured) to the RADIUS server and the Framed-IP-Address attribute is not included.

    • User Session Statistics are retained for the entire PPP session and are not cleared when the IPv4 address is released.

  4. The BNG receives an Interim-Accounting response from the RADIUS server.

    No action is taken in the BNG whether or not it receives a response from the RADIUS server.

On-Demand IPv4 Address Negotiation and Release for Dynamic PPP Subscribers Overview

This topic describes how on-demand IPv4 address allocation and de-allocation works for dynamic dual-stack PPP subscribers.

IPv4 Address Negotiation for Dynamic PPP Subscribers

The process for IPv4 address negotiation for a dynamic inet family and address over a static PPP interface is as follows:

  1. PPP Link Control Protocol (LCP) is established and IPv6 control protocol is successfully negotiated.

  2. The broadband network gateway (BNG) receives an Internet protocol Control Protocol (IPCP) Configure Request with a 0.0.0.0 IPv4 address option from the CPE.

  3. The BNG sends an Access-Request message with the IPv4-Release-Control VSA (26-164) (if configured) to the RADIUS server.

  4. The BNG receives an Access-Accept message from the RADIUS server.

    • If a Framed-IP-Address attribute is received, then a duplicate address check (if configured) is performed on the BNG. If a duplicate address check is completed successfully, then PPP continues IPCP negotiation with the CPE. Otherwise, the entire PPP session is brought down by sending an LCP terminate request to the CPE.

    • If Framed-Pool attribute is received, then the IPv4 address is allocated from the specified local address pool configured in the BNG. If the pool is not configured in the BNG and there is no other IP pool available, then an IPCP protocol reject is sent to the CPE.

    • If neither a Framed-IP-Address attribute nor a Framed-Pool attribute is received, then the BNG allocates an IPv4 address from one of the configured local address pools. If the BNG cannot allocate an IPv4 address, then an IPCP protocol reject is sent to the CPE.

    • If ADFv4 filters are present in the Access-Accept message, then they need to be reinstalled for that subscriber in the BNG.

    • If both IPv4 primary and secondary DNS addresses are present in the Access-Accept message, then both of them need to be updated for that subscriber in the BNG. If either an IPv4 primary DNS address or an IPv4 secondary DNS address is present in the Access-Accept message, then only the corresponding DNS address needs to be updated for that subscriber.

    If an IPv4 address is not available, and the BNG receives an Access-Reject message from the RADIUS server, the following occurs:

    • If the Access-Reject message includes the IPv4-Release-Control VSA (26-164), the BNG sends an IPCP terminate request to the CPE. The CPE is then allowed to renegotiate IP NCP.

    • If the Access-Reject message does not include the IPv4-Release-Control VSA (26-164), the BNG sends an LCP Protocol-Reject message to the CPE. The CPE must renegotiate the LCP link before it is allowed to renegotiate IP NCP.

      If the RADIUS Access-Reject message includes the IPCP Terminate-Request field, the text of Reply Message attribute #18 is appended to the information in the Terminate-Request field, and will be shown in PPP data.

    If an Access-Challenge message is received instead of an Access-Accept, then the IPCP protocol reject is sent to the CPE.

    If there is no response from the RADIUS server, then IPCP is terminated.

  5. The BNG sends an IPCP Configure NACK with the new IPv4 address option to the CPE.

  6. The dynamic inet family and local address are added and all IPv4 (family inet) services for the dynamic client profile are instantiated.

    The BNG sends an IPCP Configure Request with a local IPv4 address option to the CPE.

  7. The BNG sends an immediate Interim-Accounting message (if configured) with the IPv4-Release-Control VSA (26-164) (if configured) and a Framed-IP-Address attribute to the RADIUS server.

  8. All IPv4 services, such as ascend data filters (ADF) and firewall filters, for the dynamic service profile and the lawful intercept service (if present for inet family) are instantiated and the Service Accounting-Start messages (if service accounting is configured and IPv4 service is not part of a multi-family service profile) are sent to the RADIUS server. If service instantiation fails, then IPCP is terminated and an IPv4 address release process is initiated.

  9. The BNG receives an IPCP Configure Request with a new IPv4 address option from the CPE.

  10. The BNG sends an IPCP Configure ACK to the CPE.

  11. The BNG receives a Service Accounting-Start response from the RADIUS server.

  12. The BNG receives an Interim-Accounting response from the RADIUS server.

  13. The BNG receives an IPCP Configure ACK from the CPE.

IPv4 Address Release for Dynamic PPP Subscribers

The process for IPv4 address release for dynamic inet family and address over static PPP interface is as follows:

  1. The BNG receives an IPCP terminate request from the CPE.

  2. The BNG sends an IPCP terminate ACK to the CPE.

  3. The following actions occur:

    • All IPv4 (family inet) services for the dynamic client profile are de-instantiated and the dynamic inet family and local address are removed.

    • All IPv4 services, such as ascend data filters (ADF) and firewall filters, for a dynamic service profile and the lawful intercept service (if present for inet family) are de-instantiated. The Service Accounting-Stop messages (if service accounting is configured and IPv4 service is not part of a multi-family service profile) is sent to the RADIUS server.

    • If an IPv4 address was allocated from a local address pool, then it is available.

    • The IPv4 address entry is cleared from the subscriber record

  4. The BNG sends an immediate Interim-Accounting message (if configured) with the IPv4-Release-Control VSA (26-164) (if configured) to the RADIUS server and the Framed-IP-Address attribute must not be included.

    User Session Statistics and service session statistics for multi-family service are retained for the entire PPP session and is not cleared when the IPv4 address is released.

  5. The BNG receives an Interim-Accounting response from the RADIUS server.

    No action taken in the BNG whether or not it receives a response from the RADIUS server.

IPCP Negotiation with Optional Peer IP Address

During normal operation for an Internet Protocol Control Protocol (IPCP) negotiation, if the Point-to-Point Protocol (PPP) client does not request a specific IP address, the MX Series server sends an IP address obtained from RADIUS or from the local address pool.

Typically, when the CPE negotiates a statically provisioned IP address, the BNG receives a Framed-IP-Address of 255.255.255.255, and optionally a Framed Route, during PPP authorization. The CPE presents the configured IP WAN address in the IP Address option of the IPCP confReq message. The BNG then accepts the peer’s proposed address.

In some other cases, however, the subscriber's public IP address is provisioned locally on the CPE but not explicitly negotiated via IPNCP. If the PPP client seeks a specific IP address, on receiving a NAK from the server, it sends a confReq message without specifying the IP address option. In this case, even though the server sends an IPCP confAck message, the server terminates the client because the server requires an IP address from the client.

You can configure the peer-ip-address-optional statement to enable the IPCP negotiation to succeed even though the peer does not include the IP address option in an IPCP configuration request for static and dynamic, and terminated and tunneled, Point-to-Point Protocol over Ethernet (PPPoE) subscribers. By default, this statement is disabled. This feature also supports high availability (HA) and unified in-service software upgrade (unified ISSU).

If the client does not include the IP address option in an IPCP configuration request and the IPCP negotiation succeeds by configuring the peer-ip-address-optional statement, then the server does not have the client IP address.

Note:

If the client does include the IP address option in an IPCP configuration request, it does not matter whether the peer-ip-address-optional statement is configured because the subscriber is always available and the server has the client IP address.

An IP address from RADIUS or from the local pool is allocated to the client and the route towards this is added on the server even though the client is not assigned with this address. IPCP is successful and the subscriber becomes available. If you want the server to have the route to the client-requested IP address, use the Framed-Route RADIUS attribute or configure static routes. The client adds or configures static routes towards the server for proper forwarding.

See Also

How RADIUS Attributes Are Used During Authentication When On-Demand Address Allocation is Enabled

The following describes the behavior of the border network gateway (BNG) during authentication when on-demand IP address allocation is enabled:

  • If the RADIUS server returns a Framed-IP-Address attribute, the BNG does not go to the RADIUS server for address allocation on the first Internet Protocol Control Protocol (IPCP) negotiation. It uses the Framed-IP-Address attribute returned in the initial Access-Accept message. Accounting-Start and periodic Interim-Accounting messages include the Framed-IP-Address attribute. Immediate Interim Accounting messages are not sent to RADIUS server. Address allocation is similar to the process described for a static or dynamic subscriber.

    When a Framed-IP-Address is returned from the RADIUS server during authentication and the customer premises equipment (CPE) does not negotiate IPCP, the IPv4 address is not released whether or not the on-demand IP address allocation is enabled.

  • If the RADIUS server returns a Framed-Pool attribute. the BNG does not go to the RADIUS server for address allocation upon first IPCP negotiation and it allocates an IPv4 address from the specified local address pool. Accounting-Start and periodic Interim-Accounting messages do not include the Framed-IP-Address attribute until IPCP negotiation. Immediate Interim Accounting messages (if configured) are sent to the RADIUS server. Address allocation is similar to the process described for a static or dynamic subscriber.

  • If the RADIUS server does not return either the Framed-IP-Address attribute or the Framed-Pool attribute. address allocation is similar to the process described for a static or dynamic subscriber. Because IPCP is the only Network Control Protocol (NCP) active for these subscribers, the entire PPP session is terminated upon an IPCP terminate request and an Accounting-stop message is sent to the RADIUS server. Immediate Interim-Accounting messages to release the IPv4 address are not sent in this case.

Configuring Static On-Demand IPv4 Address Allocation for Dual-Stack PPP Subscribers

To configure static on-demand IPv4 address allocation for dual-stack PPP subscribers:

  1. Specify the name and logical unit number of the interface.
  2. Enable on-demand IP address allocation.

Configuring Dynamic On-Demand IPv4 Address Allocation for Dual-Stack PPP Subscribers

To configure dynamic on-demand IPv4 address allocation for dual-stack PPP subscribers:

  1. Access the dynamic profile.
  2. Specify the name and logical unit number of the interface.
  3. Enable on-demand IP address allocation.

Configuring Global On-Demand IPv4 Address Allocation for Dual-Stack PPP Subscribers

To configure static on-demand IP address IPv4 address allocation for dual-stack PPP subscribers at the system level:

  1. Specify the protocol.
  2. Specify the ppp-service option.
  3. Enable on-demand IP address allocation.

Enabling Immediate Interim Accounting Messages for On-Demand IPv4 Address Changes

To enable the BNG to send an immediate interim accounting message:

  1. Create a profile and assign a name to it.
  2. Under accounting, specify the address-change-immediate-update option.

Enabling IPv4 Release Control VSA (26–164) in RADIUS Messages

When you are using on-demand address allocation for dual-stack PPP subscribers, you can configure the BNG to include the IPv4-Release-Control VSA (26–164) in the Access-Request that is sent during on-demand IP address allocation and in the Interim-Accounting messages that are sent to report an address change.

If no IPv4 address is available during negotiation for static or dynamic PPP subscribers, the RADIUS server includes this VSA in the Access-Reject message it sends to the BNG. The consequence is that the BNG sends an IPCP terminate request to the CPE and the CPE can then renegotiate IPCP.

If you have not enabled VSA 26–164 to be sent, then the Access-Reject message does not include the VSA, and the BNG sends an LCP Protocol-Reject message to the CPE. The CPE must renegotiate the LCP link before it is allowed to renegotiate IP NCP.

The configuration of this statement has no effect when on-demand IP address allocation or deallocation is not configured.

You can optionally configure a message that is included in the VSA when it is sent to the RADIUS server.

To enable the IPv4-Release-Control VSA (26-164) in RADIUS messages:

  1. Create a profile and assign a name to it.
  2. Specify that you want to configure RADIUS.
  3. (Optional) Configure the VSA to be sent and optionally specify a text message to be included in the VSA.

Related Documentation