Processing NCP Negotiations in a Dual-Stack Environment Overview

JunosE Software enables interoperability of clients running Windows Vista platforms with ICMPv6 router advertisements that are sent from an E Series router configured for IPv6. This interoperability with Windows Vista clients is available only in environments where the PPP or PPPoE link is established over the Gigabit Ethernet interface on the provider edge (PE) router from the customer edge (CE) device. This functionality is not supported on connections established over other types of interfaces on the PE router. Support for Windows Vista clients is available only when ERX1440 and E320 routers are used as the requesting routers at the service provider edge of the network. The PPP or PPPoE link between the CE and PE devices can be configured for both IPv4 and IPv6 protocols for transmission of data. Such networks require that PE devices run a dual stack of IPv4 and IPv6 services. Neighbor Discovery and Prefix Delegation are supported in environments in which the subscriber is either an IPv6 subscriber or a combined IPv4 and IPv6 subscriber in a dual stack.

PPP includes a family of Network Control Protocols (NCPs) to establish and configure different network layer protocols. Internet Protocol version 6 Control Protocol (IPv6CP) is negotiated during the NCP phase and the interface ID is also negotiated during this phase. PPP’s Link Control Protocol (LCP) establishes a PPP link by negotiating with the PPP peer at the other end of a proposed connection.

ERX routers save the order of the NCP negotiation process as soon as the process begins. When the router sends NCP configuration request packets for each NCP peer, it checks the recorded order and avoids sending the configuration request packet until the first NCP negotiation process is completed. The completion or failure of the first NCP negotiation process triggers the remaining NCP negotiation attempts.

For dynamic interfaces, NCP configuration request packets are sent after the corresponding upper interface (IPv4 or IPv6) is created and stacked. Therefore, the dynamic creation of interfaces is still permitted in any order until the upper interface is stacked. However, after the upper interface is stacked, the corresponding NCP configuration request packet is not sent if the first NCP negotiation process is not completed successfully.

In the case of static interface columns, because the upper interfaces are previously stacked, ERX routers initiate the NCP configuration requests as soon as LCP changes to the up state, instead of waiting for the client. In such a case, ERX routers do not send the NCP negotiation packets until they receive NCP configuration requests from the client and process the configuration requests based on the order of those received packets.

During Internet Protocol Control Protocol (IPCP) negotiations between a customer premises equipment (CPE) and the PE router, which can function as an LNS device in an L2TP tunnel, if RADIUS is used to authenticate the PPP clients, the Access-Accept message sent from the RADIUS server to the PE router or the RADIUS client might contain the MS-Primary-DNS-Server [311-28] and the MS-Secondary-DNS-Server [311-29] RADIUS VSA attributes. In such a scenario, the PE router or the B-RAS server processes these Microsoft VSAs and uses the primary and secondary DNS server addresses in the IPCP negotiation with the CPE for allocation of IP addresses. For more information about the handling of Microsoft VSAs during IPCP negotiations, see Processing DNS Addresses from Microsoft RADIUS VSAs for PPP Clients During IPCP.

Enabling IPCP and IPv6CP Negotiations for IPv4 and IPv6 Clients Based on RADIUS-Returned Attributes

Point-to-Point Protocol (PPP) uses Internet Protocol Control Protocol (IPCP) and Internet Protocol version 6 Control Protocol (IPv6CP) negotiations for assigning IP version 4 (IPv4) and IP version 6 (IPv6) addresses to authenticated PPP Broadband Remote Access Server (B-RAS) subscribers by using RADIUS-returned attributes or the local address pool configured on the router.

You can now enable IPCP and IPv6CP negotiations for IPv4 and IPv6 clients based only on RADIUS-returned attributes by issuing the aaa radius-override-ncp-negotiation command with the enable keyword.

IPCP negotiation is initiated for IPv4 clients only when the Framed-Ip-Address [8] attribute or Framed-Pool [88] attribute is returned by the RADIUS server. IPv6CP negotiation is initiated for IPv6 clients only when the Framed-Interface-Id [96] attribute, IPv6 prefix attributes, or IPv6 pool name attributes are returned by the RADIUS server.

Sending the Acct-Start and Acct-Update Messages After NCP Negotiation Is Completed

When authentication, authorization, and accounting (AAA) receives authentication-grant permission from the RADIUS server before NCP negotiation is started, an Acct-Start message is sent immediately to the RADIUS server. An Acct-Update message is sent from the B-RAS to the RADIUS server immediately after IP notifies AAA to set a user IP address or user interface ID.

However, you can use the aaa accounting delay-start command to delay the sending of the Acct-Start message from the B-RAS to the RADIUS server until Network Control Protocol (NCP) negotiation is completed.

You can use the aaa accounting immediate-update-framed-ipv6-interfaceId-negotiation command to send the Acct-Update message with the Framed-Interface-Id [96] RADIUS attributes from the B-RAS to the RADIUS server for PPPv6 users immediately after NCP negotiation is completed.

Related Documentation