The Layer 2 Forwarding Protocol
The Layer 2 Forwarding (L2F) protocol was created by Cisco Systems. It permits the tunneling of the link layer—that is, High-Level Data Link Control (HDLC), async HDLC, or Serial Line Internet Protocol (SLIP) frames---of higher-level protocols. Figure 2-25 shows the format of the tunneled packet.
|
Figure 2-25: The Format of a Tunneled Packet |
||
Using such tunnels, it is possible to decouple the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network is provided. These tunnels also enable applications that require support for privately addressed IP, IPX, and AppleTalk dial-up using SLIP/PPP across the existing Internet infrastructure.
A Sample Scenario
Figure 2-26 shows a sample virtual dial-up scenario for L2F. The following steps are carried out: Step 1 The remote user initiates a PPP connection to an ISP over the PSTN (or natively over ISDN). Step 2 The NAS accepts the connection, and the PPP link is established. Step 3 The ISP authenticates the end system or user using CHAP or PAP.
Note If permitted by the organization's security policy, the authorization of the dial-in user at the NAS can be performed only on a domain name within the username field and not on every individual username. This setup can substantially reduce the size of the authorization database. If a virtual dial-up service is not required, traditional access to the Internet may be provided by the NAS. All address assignment and authentication would be performed locally by the ISP in this situation.
Step 4 NAS initiates the L2F tunnel to the desired corporate gateway.
Step 5 The corporate gateway authenticates the remote user and either accepts or rejects the tunnel.
NOTE The initial setup notification may include the authentication information required to allow the corporate gateway to authenticate the user and decide to accept or decline the connection. In the case of CHAP, the setup packet includes the challenge, username, and raw password; for PAP, the setup packet includes the username and cleartext password. The corporate gateway can be configured to use this information to complete its authentication, avoiding an additional cycle of authentication.
Note also that the authentication takes place at the corporate customer, allowing the corporation to impose its own security and corporate policy on the remote users accessing its network. In this way, the organization does not have to fully trust the authentication performed by the ISP.
Step 6 The corporate gateway confirms acceptance of the call and L2F tunnel.
NOTE If the corporate gateway accepts the connection, it creates a virtual interface for PPP in a manner analogous to what it would use for a direct-dialed connection. With this virtual interface in place, Link layer frames can now pass over this tunnel in both directions. Frames from the remote user are received at the NAS, stripped of any link framing or transparency bytes, encapsulated in L2F, and forwarded over the appropriate tunnel.
The corporate gateway accepts these frames, strips L2F, and processes them as normal incoming frames for the appropriate interface and protocol. The virtual interface behaves very much like a hardware interface, except that the hardware in this case is physically located at the ISP NAS. The reverse traffic direction behaves analogously, with the corporate gateway encapsulating the packet in L2F, and the NAS stripping L2F encapsulation before transmitting it out the physical interface to the remote user.
Step 7 The corporate gateway exchanges PPP negotiations with the remote user. Because the remote user has become simply another dial-up client of the corporate gateway access server, client connectivity can now be managed using traditional mechanisms with respect to further authorization, address negotiation, protocol access, accounting, and filtering.
Step 8 End-to-end data is tunneled between the remote user and the corporate gateway.
|
Figure 2-26: A Sample Scenario for L2F |
||
Continue reading here: The Pointto Point Tunneling Protocol
Was this article helpful?