The L2TP protocol stack, shown in Figure 3-12, is an extension to PPP, which is an important component of VPNs. L2TP can support either PPPoA or PPPoE encapsulation on the PVC coming from the CPE. The LAC accepts this PPP session and establishes the L2TP tunnel to the LNS. After LCP has been negotiated, the LAC partially authenticates the end user with CHAP or PAP but does not process PPP packets. User authentication is done on the LNS, where the call terminates. At the provider’s site, such as the corporate home, information necessary to identify the remote LNS can be stored in the AAA server or can be entered directly into the LNS configuration.
Figure 3-12 L2TP Protocol Stack
L2TP uses the User Data Protocol (UDP) as the transport layer protocol.
[email protected] LAC/ Router
L2TP Connectivity
The tunnel endpoints, the LAC and the LNS, authenticate each other before any sessions are attempted within a tunnel (see Figure 3-13). Alternatively, the LNS can accept tunnel creation without any tunnel authentication by the LAC. As soon as the tunnel exists, an L2TP session is created for the end user.
Figure 3-13 L2TP Connections
The PPP session can be terminated on a Cisco 6400 or tunneled to another L2TP network server. If the L2TP session is terminated on the Cisco 6400, you can use another form of tunnel to transport traffic to the service provider. (MPLS, which is described later, is an important form of tunnel.)
L2TP uses two types of messages—control and data. Control messages are used to establish, maintain, and clear a tunnel and to set up and clear sessions. Data messages are used to encapsulate PPP frames being carried over the tunnel.
L2TP guarantees the delivery of control messages through a control channel. Messages in the control channel have sequence numbers used to detect loss or out-of-order delivery.
Lost control messages are retransmitted. Data messages may also use sequence numbers to reorder packets and detect lost packets.
LAC/ Router
6400 LNS/ Router
DSLAM 6400
CPE
IP UDP L2TP PPP PPP Payload
Tunnel
PPPoA PPPoE
L2TP L2TP Tunnel PVC
Ethernet
Suppose that the scenario requires a VPDN, meaning that the tunnel is established through the public switched telephone network (PSTN). The VPDN connection between a remote user and the LNS using L2TP is accomplished as follows:
Step 1 The remote user initiates a PPP connection to the ISP, using the analog telephone system, such as a field employee who dials the local modem bank, or ISDN.
Step 2 The ISP network LAC accepts the connection at the service provider’s Point Of Presence (POP), and the PPP link is established.
Step 3 After the subscriber-end host and the LNS negotiate LCP, the LAC partially authenticates the end user with CHAP or PAP. In DSL’s implementation of VPDN, the username or domain name is used to determine whether the user is a VPDN client.
Step 4 The LAC propagates the LCP-negotiated options and the partially authenticated CHAP/PAP information to the virtual template interface on the LNS. If the options configured on the virtual template interface do not match the negotiated options with the LAC, the connection fails, and a disconnect is sent to the LAC.
Step 5 If everything is configured properly, the username@domain** name is used to verify that the user is a VPDN client and to provide a mapping to a specific endpoint LNS. The tunnel endpoints (LAC and LNS) authenticate each other, and the tunnel opens.
L2TP tunnels are described by identifiers that have only local significance at each end of the tunnel. The LAC and LNS ends of the tunnel have different tunnel IDs. The tunnel ID sent in each message is that of the recipient’s end of the tunnel, not the sender. Tunnel IDs are selected and exchanged during the tunnel setup process. The LAC uses the tunnel ID declared by the LNS, and the LNS uses the ID declared by the LAC.
As soon as the tunnel exists, an L2TP session is created for the end user. L2TP defines that multiple PPP connections can share the same tunnel using independent sessions. L2TP sessions exist within the tunnel and also have session identifiers defined during the session setup process. Like the tunnel IDs, these session IDs also have only local significance. The session ID sent in a message is that of the recipient’s side, not that of the sender’s side.
The end result is that the exchange process appears to be between the dialup client and the remote LNS exclusively, as if no intermediary device (the LAC) were involved. PPP frames from remote users are accepted by the ISP’s POP, encapsulated in L2TP, and forwarded over the appropriate tunnel. The customer’s home gateway accepts these L2TP frames, strips the L2TP encapsulation, and processes the incoming frames.
L2TP IP Addressing
NCP negotiates what Layer 3 protocol to use. For IP you can use IPCP. During IPCP the Cisco 6400 or a similar device can dynamically assign IP addresses over PPP.
IPCP, a function of PPP, is a means by which a remote host (computer) gains an IP address when connected to the IP-based Internet. This address is used to route data to that host while the host is communicating across the Internet.
PPP/IPCP and DHCP are different methods of assigning addresses. The former method is valid only for PPPoA and PPPoE, and the latter address assignment method is valid for all DSL network architectures, including bridging. For the DHCP method, the gateway router or RADIUS server allocates the IP address to the xTU-R. The xTU-R acts as a DHCP server for the PC connected to the LAN interface.
For the host PPP session, you can use local pools, RADIUS, or Proxy RADIUS. If you are using L2TP multihop, the host gets a new IP address from the service provider during L2TP tunnel negotiations. These addresses are not routable within the service provider core.