Overview

PPP provides a standard method for transporting multiprotocol datagrams over a point-to-point link. PPP uses the High-Speed Data Link Control (HDLC) protocol for its physical interface and provides a packet-oriented interface for the network-layer protocols.

Internet Protocol Control Protocol (IPCP) (which negotiates for transport of IP version 4 datagrams), IPv6CP (which negotiates for transport of IP version 6 datagrams), the OSI Network Layer Control Protocols (OSINLCPs), and Multiprotocol Label Switching (MPLS) run within PPP.

The router supports dynamic PPP interfaces. For details, see Configuring Dynamic Interfaces.

Framing

The software restricts the use of the general HDLC protocol (RFC 1662) to unnumbered mode:

• HDLC address field is 0xFF (all stations)
• HDLC control field is 0x03 (to indicate unnumbered mode)

The router does not support the following framing features:

• Numbered mode (RFC 1663)
• Autodetection of encapsulation

Error Frames

The router relies on higher-layer protocols to recover from PPP data loss. All unrecognized protocol data units (PDUs) are discarded; however, statistics are maintained for packets dropped.

Link Control Protocol

PPP’s Link Control Protocol (LCP) establishes a PPP link by negotiating with the PPP peer at the other end of a proposed connection. When two routers initialize a PPP dialogue, each router sends control packets to the peer. The control packets contain a list of LCP options and corresponding values that the sending peer uses to define its end of the link, such as the maximum receive unit (MRU).

LCP negotiations continue until the peers either converge (that is, reach an agreement about values for connection parameters) or abandon attempts to establish a connection.

If you configure a PPP interface without an IP interface or profile, the router negotiates LCP, but then terminates LCP after 2 to 3 minutes. Previously, the behavior in such a circumstance was to negotiate LCP and then leave LCP open.

For static PPP interfaces, whenever LCP achieves a stopped state because of termination, negotiation failure, or some other cause, it goes into passive mode and waits for the other side of the connection to restart the negotiation process. Once in passive mode, the router periodically attempts to negotiate with the other side according to an exponential timeout algorithm.

For static PPP interfaces, the router waits 15 seconds, attempts negotiation, waits 30 seconds if it fails, attempts negotiation, waits 60 seconds if it fails, and so on. The timeout periods are 15 seconds, 30 seconds, 60 seconds, 2 minutes, 4 minutes, 8 minutes, and 15 minutes. Once it reaches the 15-minute timeout, the router attempts negotiation every 15 minutes until successful. When LCP reaches the open state, the timer resets to 15 seconds.

Dynamic PPP interfaces are always torn down when LCP achieves a stopped state. For more information, see Configuring Dynamic Interfaces.

LCP Negotiation Parameters

LCP can negotiate many PPP options, as follows:

• MRU size—Maximum receive unit size (always accepted).
• Magic number—Randomly generated number used to identify one end of a point-to-point connection. Each side negotiates its magic number, taking note of each other’s magic number. If both sides discover that the magic numbers they are negotiating are the same, each side attempts to change its magic number. If they are not successful, and the magic numbers remain the same, the session terminates because of the loopback that is detected. Magic numbers are always accepted.

  By default, the router always attempts to negotiate a local magic number. The peer can also determine whether to negotiate its magic number—the peer magic number. The router always accepts a peer’s attempt to negotiate its magic number.

  If the peer does not attempt to negotiate its magic number, you can configure the router to ignore a mismatch of the peer magic number and retain the PPP connection. For details, see Validation of LCP Peer Magic Number.

• Authentication—Requested if configured.
• Protocol-Field-Compression (PFC) and Address-and-Control-Field-Compression (ACFC)—Accepted, but never requested.
• Multilink PPP—Additional options can be negotiated when Multilink PPP is configured. See Configuring Multilink PPP.
• Async-Control-Character-Map (ACCM—Supported by PPP when used with an L2TP Network Server (LNS). ACCM allows PPP to indirectly support asynchronous PPP connections tunneled via a third-party L2TP Access Concentrator (LAC). PPP on the router uses the ACCM configuration data as supplied by the LAC via proxy LCP. The router does not directly support asynchronous PPP connections and will not negotiate an ACCM option unless directed to do so by a third-party LAC.

PPP can also detect a loopback that occurs after LCP is negotiated, provided that:

• No loopback occurs during LCP negotiations.
• A loopback is introduced after LCP negotiation without forcing LCP renegotiation. (LCP is renegotiated if the lower layer goes down or if an LCP confReq is received from the other end.)

Validation of LCP Peer Magic Number

If the peer has not negotiated an LCP magic number, you can configure the router to ignore a mismatch of the LCP peer magic number and retain the PPP connection.

Previously, the router terminated a PPP connection with a non-conforming peer when it received LCP echo request packets or LCP echo reply packets from the peer with a magic number that did not match the LCP peer magic number on the router. This is still the current default behavior if you do not explicitly configure the router to ignore the LCP peer magic number mismatch if the peer has not negotiated the magic number and retain the PPP connection.

Configuring the router to ignore the peer magic number mismatch and retain the PPP connection is useful if your network includes peers that send a non-null or invalid magic number in the LCP echo request and reply packets despite having not negotiated the magic number. In this situation, the router expects to receive a null magic number from the peer, and terminates the PPP connection unless you configure it to ignore the peer magic number mismatch and retain the connection.

To configure the router to ignore the LCP peer magic number mismatch and retain the PPP connection, use the ppp magic-number ignore-mismatch command from Interface Configuration mode or Subinterface Configuration mode. For more information, see ppp magic-number ignore-mismatch.

To verify configuration of LCP peer magic number validation on the router, you can use the show ppp interface command. For more information, see show ppp interface.

Keep the following points in mind when configuring the router to ignore the peer magic number mismatch and retain the PPP connection:

• If the peer negotiates the magic number but sends the router an LCP echo request or reply packet that contains a null or invalid magic number, the router strictly terminates the PPP connection. The router can ignore a mismatch of the LCP peer magic number only when the peer has not negotiated the magic number.
• Using the ppp magic-number disable command to disable negotiation of the magic number on the router does not affect validation of the peer magic number. When you issue the ppp magic-number disable command, the router sets only the local magic number to null, but does not change or validate the peer magic number. (For more information, see ppp magic-number disable.)

You can also configure validation of the LCP peer magic number for static MLPPP interfaces, dynamic PPP interfaces, and dynamic MLPPP interfaces. For more information about configuring static MLPPP interfaces, see Configuring Multilink PPP. For more information about using profiles to configure dynamic PPP and dynamic MLPPP interfaces, see Configuring a Dynamic Interface from a Profile in Configuring Dynamic Interfaces.

B-RAS Support

Broadband Remote Access Server (B-RAS) is an application that aggregates the output from digital subscriber line access multiplexers (DSLAMs). B-RAS provides user PPP sessions and PPP session termination and routes traffic onto the backbone. See JunosE Broadband Access Configuration Guide for details on B-RAS.

The router provides an enhanced version of PPP to accommodate B-RAS with the following features:

• Internet Protocol Control Protocol (IPCP) extensions for Windows Internet Name Service (WINS) and Domain Name System (DNS) name server addresses
• Password Authentication Protocol (PAP)
• Challenge Handshake Authentication Protocol (CHAP)
• Keepalive timeout
• Session timeout
• Inactivity timeout
• Accounting

Authentication

The router acts as an authenticator. It demands authentication from a remote PPP peer but refuses to authenticate itself.

Rate Limiting for PPP Control Packets

The router implements rate limiting for PPP control packets to protect the corresponding PPP interface from denial-of-service (DoS) attacks. The interface discards control packets when the rate of control packets received exceeds the rate limit for PPP interfaces.

A PPP interface has a rate limit control that is non-configurable and always in effect; the rate limit is the same for all PPP interfaces. In addition, each interface instance maintains its own state and statistics counters for tracking the rate. The rate limit for PPP control packets is approximately 10 packets per second.

For a PPP interface, the router increments the discards counter in the show ppp interface command display to track the number of PPP control packets discarded on receipt (in) or discarded before they were transmitted (out) on this interface.

For examples of the show ppp interface command display, see show ppp interface.

Extensible Authentication Protocol

The JunosE Software supports Extensible Authentication Protocol (EAP) for authenticating a peer before allowing network layer protocols to transmit over the link. EAP supports multiple authentication methods, including EAP-TLS and EAP-MD5-Challenge. The EAP server and the peer negotiate the specific authentication method to be used. Figure 34 illustrates the three components required for EAP: an EAP authenticator, an EAP server, and an EAP client.

Figure 34: Authentication with EAP

After LCP negotiation, JunosE starts the EAP negotiation process by initiating an identity exchange with the EAP client on the peer. The router sends an EAP identity request packet to the peer, which replies with an EAP identity response packet. After this exchange, the E Series router acts only as a pass-through device, enabling the EAP server residing on the backend authentication server to select and negotiate the particular EAP authentication method directly with the EAP client on the peer.

The JunosE Software forwards or discards packets received from the backend authentication router and the peer depending on the identifying code contained in the packet.

The E Series router forwards:

• Packets received from the peer with a Response code
• Packets received from the backend authentication server with a Request, Success, or Failure code

The E Series router discards:

• Packets received from the peer with a Request, Success, or Failure code
• Packets received from the backend authentication server with a Response code

The JunosE Software determines the outcome of the authentication based only on the Accept or Reject indication sent by the RADIUS server

EAP Types

The JunosE Software has been qualified to work with the EAP authentication methods—known as EAP types—described in Table 15. Other EAP authentication methods have not been qualified with the JunosE Software

EAP Packet Retransmission

PPP retransmits the EAP request packets to the peer. The RADIUS client retransmits the EAP response packets to the RADIUS Server. The request packets to the peer are governed by nonconfigurable values for retransmission attempts and interval. The configuration of the RADIUS client determines retransmission values for response packets to the RADIUS server. The retransmission values are as follows:

• PPP makes five attempts to retransmit an EAP request before the authentication attempt is terminated. You cannot configure the number of retransmission attempts.
• When an EAP request is transmitted, a timer is started with a nonconfigurable retransmission interval value of 3 seconds. When the timer expires, the EAP request is retransmitted.

In some cases, you might want a longer retransmission interval. For example, you might need to accommodate the additional time required by a user to enter information or scan a fingerprint or retina. RADIUS can instruct the JunosE Software to wait longer by passing an appropriate Session-Timeout attribute in the RADIUS Access-Challenge packet. This retransmission interval value applies only to the EAP request packet present in the RADIUS Access-Challenge packet.

The Session-Timeout attribute value overrides the default retransmission interval value, up to a maximum of 30 seconds. If RADIUS recommends a greater value, then PPP resets it back to 30 seconds in order to avoid longer or infinite delays.

EAP Behavior in an L2TP Environment

EAP behavior in an L2TP environment varies depending on whether the router acts as a LAC or an LNS,

When the E Series Router Acts as a LAC

When PPP forwards an EAP identity response packet to AAA, AAA might be configured to return a tunnel response upon successful validation of the packet. You can use AAA domain maps, a AAA profile, or both to force such tunneling.

On an LAC, PPP forwards the PPP EAP authentication information to the LNS during the establishment of the L2TP session. This authentication information consists of the EAP type, the data appropriate to the type (such as a username) contained in the EAP identity response packet, and the identifier of the EAP identity response packet. If the LNS trusts the LAC, then the LNS uses this authentication information to resume the EAP negotiation where the LAC left off.

L2TP on an LAC forwards the PPP EAP authentication information in the Proxy Authen AVPs as described in L2TP Proxy Authenticate Extensions for EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration).

When the E Series Router Acts as an LNS

PPP on an LNS resumes the EAP negotiation operation by detecting the presence of EAP information in the proxy authentication data supplied by L2TP. PPP reconstructs the EAP identity response packet from the proxy authentication data and forwards it to AAA.

L2TP on an LNS processes the received Proxy Authen AVPs as described in L2TP Proxy Authenticate Extensions for EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration).

Limitations

EAP is subject to internal limits. When the E Series router acts as a pass-through between the backend authentication server and the peer, EAP packets traverse the controllers within the router. The size of EAP packets and fragments tends to be larger than the buffer exchange limit—1450 bytes—between the controllers. This intercontroller buffer exchange limit is tuned for the optimal system performance and scalability; also, when stacked over L2TP on LNS, it prevents PPP control packets from causing IP fragmentation and reassembly on the Ethernet downlink. Hence, if EAP is configured as a PPP authentication protocol, then EAP packet or fragment size is affected by the intercontroller buffer exchange limit as follows:

• The MRU value advertised by JunosE in the LCP request packet takes the lowest of the following values:
  • the lower layer MRU minus the PPP overhead
  • the configured MRU
  • 1450 bytes
• The MTU value is initialized by JunosE to the lowest of the following values:
  • the lower layer MTU minus the PPP overhead
  • the peer MRU
  • 1450 bytes

The MTU value is passed to RADIUS in an Access-Request packet by means of the Framed-Mtu attribute.

Performance

When EAP is configured on the router, it affects the performance and scalability of PPP in terms of round-trip packet exchanges, negotiations, EAP server requirements, and EAP client requirements. For information on the number of PPP interfaces supported with EAP, see the Link Layer Maximums tables in Appendix A, System Maximums, of the current JunosE Release Notes.

• Performance depends on the number of packets exchanged during the negotiation. When the number of packets exchanged increases—that is, when the number of round-trips increases—it takes longer to finish the interface negotiation. System resources are locked for a longer duration. As a result it takes longer to bring up all the interfaces.

  The number of round-trip message exchanges varies with the EAP authentication method. When no retransmission of packets takes place and there is no fragmentation, PAP and CHAP require one round-trip, EAP-MD5-Challenge requires two round-trips, and EAP-TLS requires four round-trips.

  Retransmission increases the number of round-trips. When the negotiated EAP authentication method requires fragmentation, such as for the exchange of large certificate chains, then the number of round-trips increases.

• The number of simultaneous EAP negotiations is limited to 50 because of resource limitations. Consequently, the time required to bring up interfaces when you configure EAP authentication is longer than when you specify PAP or CHAP authentication.
• EAP authentication methods fragment packets when the EAP packet size is greater than the link MTU. The EAP server must fragment the EAP packet to the size of the Framed-Mtu attribute contained in the RADIUS Access-Request packet.

  If the server fragments the packet to a larger size than specified by the attribute, then JunosE drops the packet, because the E Series router acts as a pass-through device and is not involved in the authentication method's fragmentation and reassembly mechanisms.

  On the other hand, if the EAP server fragments the EAP packet to a smaller size than specified by the attribute, then performance decreases because of the increased number of smaller packets that must be exchanged.

• The EAP client on the peer must fragment the EAP packets to the size of the link MTU on the E Series router. When it does not do so, performance can be affected.

Remote Peer Scenarios During Negotiation of PPP Options

During a PPP configuration request, if any of the primary or secondary DNS option is rejected, or if they are unacceptable, the CPE (Customer Premises Equipment) is prompted to negotiate the IPCP primary and secondary DNS options that are locally available with the B-RAS (Broadband Remote Access Server). This provision is controlled by CLI and SNMP configuration options.

The following describes the peer negotiations in different scenarios:

• The CPE does not send the prompted options in the subsequent configure request
  • If B-RAS sends another NAK, it prompts the options again, until max configure-nak is exceeded
  • If B-RAS sends an ACK, it ignores the options and brings up the link
• The CPE negotiates a different option from the prompted options
  • If B-RAS sends another NAK, it prompts the options again, until max configure-nak is exceeded
  • If B-RAS sends an ACK, it ignores the options and brings up the link
• The CPE negotiates the prompted options but the option values are not acceptable
  • B-RAS sends another NAK with the prompted options, until max configure-nak is exceeded
• The CPE negotiates the prompted options but some option values are not acceptable
  • B-RAS sends a NAK for unacceptable options, until max configure-nak is exceeded
• The CPE stops responding on receiving the prompted options
  • B-RAS negotiation timer expires and the link is terminated
• The CPE negotiates the prompted option after the link comes up
  • This is treated as a renegotiation request and B-RAS sends an ACK/NAK until max renegotiation and max configure-nak counters are exceeded, respectively
• The CPE starts renegotiation without the prompted options
  • B-RAS renegotiates, until max renegotiation is exceeded
  • If B-RAS sends a NAK, it prompts the options, until max configure-nak is exceeded
  • If B-RAS sends an ACK, it ignores the options and brings up this link
• The CPE NAKs or rejects the prompted options
  • This behavior is non-compliant with RFC because a configure-rej or a configure-nak must be sent only in response to a configure-req

IPCP Lockout and Local IP Address Pool Restoration

You can configure the router to terminate invalid IPv4 subscribers and return the unused IPv4 addresses to the local address pool. When Internet Protocol version 6 Control Protocol (IPv6CP) is negotiated, the router waits for 10 seconds for Internet Protocol Control Protocol (IPCP) negotiation. If IPCP is not negotiated in 10 seconds, the interface blocks IPv4 over Network Control Protocol (NCP) packets and the IP address is returned to the local address pool. The subscribers must then reconnect to negotiate IPCP again.

The router assigns IPv4 and IPv6 addresses for a PPP subscriber after authentication in the following ways:

• RADIUS returns a valid IP address or a IPv6 prefix
• The configured local address pool returns a valid IP address

The subscriber can negotiate IPv4 addresses, IPv6 addresses, or both. After an IPv6 address is negotiated for an IPCP service, the PPP application waits for the negotiation of IPv4 address and then returns the assigned unused addresses to the local pool. By default, this feature is disabled. To enable the feature, issue the ppp ipcp lockout command from Interface Configuration, Subinterface Configuration, or Profile Configuration modes. This command terminates the invalid subscriber entry and prevents additional IPCP negotiations. When IPv6CP is active and if the IPCP must close, the router does not terminate PPP and Link Control Protocol (LCP) and does not return the address to the pool. In this case, AAA uses the assigned IP address and reassigns the same address when IPCP is negotiated again.

IPCP Negotiation with Optional Peer IP Address

During normal operation for an IPCP negotiation, if the client does not request a specific IP address, the server sends an IP address obtained from RADIUS or from the local address pool.

If the 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 use the ppp peer-ip-address-optional command in Global Configuration mode to specify that the peer IP address is optional. By default, this command is disabled. This feature also supports high availability (HA) and unified in-service software upgrade (Unified ISSU).

Note: Even though the ppp peer-ip-address-optional command is configured, on receiving a NAK from the server, if the client sends an IPCP confReq message with specific IP address, IPCP is terminated after a maximum of five attempts.

When the IPCP negotiation succeeds by configuring the ppp peer-ip-address-optional command, the server does not have 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. If you want the server to have the route to the client-requested IP address, use the framed-route RADIUS attribute or configure statics routes. The client adds or configures static routes towards the server for proper forwarding.