Cisco Layer Two Forwarding (Protocol) "L2F"
A tunneling protocol that carries a dial-up user's link-layer frames to their own home network.
Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, DOI 10.17487/RFC2341, May 1998, <https://www.rfc-editor.org/info/rfc2341>.
@misc{rfc2341,
series = {Request for Comments},
number = 2341,
howpublished = {RFC 2341},
publisher = {RFC Editor},
doi = {10.17487/RFC2341},
url = {https://www.rfc-editor.org/info/rfc2341},
author = {A. Valencia and M. Littlewood and T. Kolar},
title = {{Cisco Layer Two Forwarding (Protocol) "L2F"}},
pagetotal = 29,
year = 1998,
month = may,
} RFC text
Contents
Network Working Group A. Valencia
Request for Comments: 2341 M. Littlewood
Category: Historic T. Kolar
Cisco Systems
May 1998
Cisco Layer Two Forwarding (Protocol) "L2F"
Status of Memo
This memo describes a historic protocol for the Internet community.
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Virtual dial-up allows many separate and autonomous protocol domains
to share common access infrastructure including modems, Access
Servers, and ISDN routers. Previous RFCs have specified protocols
for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
PPP [2]. This document describes the Layer Two Forwarding protocol
(L2F) which permits the tunneling of the link layer (i.e., HDLC,
async HDLC, or SLIP frames) of higher level protocols. Using such
tunnels, it is possible to divorce 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 provided.
Table of Contents
1.0 Introduction 3
1.1 Conventions 3
2.0 Problem Space Overview 3
2.1 Initial Assumptions 3
2.2 Topology 4
2.3 Virtual dial-up Service - a walk-though 5
3.0 Service Model Issues 7
3.1 Security 7
3.2 Address allocation 8
3.3 Authentication 8
3.4 Accounting 8
4.0 Protocol Definition 9
4.1 Encapsulation within L2F 10
4.1.1 Encapsulation of PPP within L2F 10
4.1.2 Encapsulation of SLIP within L2F 10
4.2 L2F Packet Format 10
4.2.1 Overall Packet Format 10
4.2.2 Packet Header 11
4.2.3 Version field 11
4.2.4 Protocol field 11
4.2.5 Sequence Number 12
4.2.6 Packet Multiplex ID 12
4.2.7 Client ID 13
4.2.8 Length 13
4.2.9 Packet Checksum 13
4.2.10 Payload Offset 14
4.2.11 Packet Key 14
4.2.12 Packet priority 14
4.3 L2F Tunnel Establishment 14
4.3.1 Normal Tunnel Negotiation Sequence 15
4.3.2 Normal Client Negotiation Sequence 17
4.4 L2F management message types 18
4.4.1 L2F message type: Invalid 18
4.4.2 L2F_CONF 19
4.4.3 L2F_OPEN, tunnel establishment 20
4.4.4 L2F_OPEN, client establishment 20
4.4.5 L2F_CLOSE 22
4.4.6 L2F_ECHO 22
4.4.7 L2F_ECHO_RESP 23
4.5 L2F Message Delivery 23
4.5.1 Sequenced Delivery 23
4.5.2 Flow Control 23
4.5.3 Tunnel State Table 24
4.5.4 Client State Table 25
5.0 Protocol Considerations 26
5.1 PPP Features 26
5.2 Termination 26
5.3 Extended Authentication 26
5.4 MNP4 and Apple Remote Access Protocol 27
5.5 Operation over IP/UDP 27
6.0 Acknowledgments 27
7.0 References 27
8.0 Security Considerations 28
9.0 Authors' Addresses 28
10.0 Full Copyright Statement 29
1.0 Introduction
The traditional dial-up network service on the Internet is for
registered IP addresses only. A new class of virtual dial-up
application which allows multiple protocols and unregistered IP
addresses is also desired on the Internet. Examples of this class of
network application are support for privately addressed IP, IPX, and
AppleTalk dial-up via SLIP/PPP across existing Internet
infrastructure.
The support of these multiprotocol virtual dial-up applications is of
significant benefit to end users and Internet Service providers as it
allows the sharing of very large investments in access and core
infrastructure and allows local calls to be used. It also allows
existing investments in non-IP protocol applications to be supported
in a secure manner while still leveraging the access infrastructure
of the Internet.
It is the purpose of this RFC to identify the issues encountered in
integrating multiprotocol dial-up services into an existing Internet
Service Provider's Point of Presence (hereafter referred to as ISP
and POP, respectively), and to describe the L2F protocol which
permits the leveraging of existing access protocols.
1.1. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
2.0 Problem Space Overview
In this section we describe in high level terms the scope of the
problem that will be explored in more detail in later sections.
2.1 Initial Assumptions
We begin by assuming that Internet access is provided by an ISP and
that the ISP wishes to offer services other than traditional
registered IP address based services to dial-up users of the network.
We also assume that the user of such a service wants all of the
security facilities that are available to him in a dedicated dial-up
configuration. In particular, the end user requires:
+ End System transparency: Neither the remote end system nor his
home site hosts should require any special software to use this
service in a secure manner.
+ Authentication as provided via dial-up PPP CHAP or PAP, or through
other dialogs as needed for protocols without authentication
(e.g., SLIP). This will include TACACS+ and RADIUS solutions as
well as support for smart cards and one-time passwords. The
authentication should be manageable by the user independently of
the ISP.
+ Addressing should be as manageable as dedicated dial-up solutions.
The address should be assigned by the home site and not the ISP.
+ Authorization should be managed by the home site as it would in a
direct dial-up solution.
+ Accounting should be performed both by the ISP (for billing
purposes) and by the user (for charge-back and auditing).
2.2 Topology
Shown below is a generic Internet with Public switched Telephone
Network (PSTN) access (i.e., async PPP via modems) and Integrated
Services Digital Network (ISDN) access (i.e., synchronous PPP
access). Remote users (either async PPP or SLIP, or ISDN) will
access the Home LAN as if they were dialed into the Home Gateway,
although their physical dial-up is via the ISP Network Access Server.
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
2.3 Providing Virtual dial-up Services - a walk-through
To motivate the following discussion, this section walks through an
example of what might happen when a Virtual dial-up client initiates
access.
The Remote User initiates a PPP connection to an ISP via either the
PSTN or ISDN. The Network Access Server (NAS) accepts the connection
and the PPP link is established.
The ISP undertakes a partial authentication of the end system/user
via CHAP or PAP. Only the username field is interpreted to determine
whether the user requires a Virtual dial-up service. It is
expected-- but not required--that usernames will be structured (e.g.
littlewo@cisco.com). Alternatively, the ISP may maintain a database
mapping users to services. In the case of Virtual dial-up, the
mapping will name a specific endpoint, the Home Gateway.
If a virtual dial-up service is not required, standard access to the
Internet may be provided.
If no tunnel connection currently exists to the desired Home Gateway,
one is initiated. L2F is designed to be largely insulated from the
details of the media over which the tunnel is established; L2F
requires only that the tunnel media provide packet oriented point-
to-point connectivity. Obvious examples of such media are UDP, Frame
Relay PVC's, or X.25 VC's. Details for L2F operation over UDP are
provided in section 5.5. The specification for L2F packet formats is
provided in section 4.2, and the message types and semantics starting
in section 4.4.
Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is
allocated, and a connect indication is sent to notify the Home
Gateway of this new dial-up session. The Home Gateway either accepts
the connection, or rejects. Rejection may include a reason
indication, which may be displayed to the dial-up user, after which
the call should be disconnected.
The initial setup notification may include the authentication
information required to allow the Home Gateway to authenticate the
user and decide to accept or decline the connection. In the case of
CHAP, the set-up packet includes the challenge, username and raw
response. For PAP or text dialog (i.e., for SLIP users), it includes
username and clear text password. The Home Gateway may choose to use
this information to complete its authentication, avoiding an
additional cycle of authentication.
For PPP, the initial setup notification may also include a copy of
the the LCP CONFACKs sent in each direction which completed LCP
negotiation. The Home Gateway may use this information to initialize
its own PPP state (thus avoiding an additional LCP negotiation), or
it may choose to initiate a new LCP CONFREQ exchange.
If the Home Gateway accepts the connection, it creates a "virtual
interface" for SLIP or PPP in a manner analogous to what it would use
for a direct-dialed connection. With this "virtual interface" in
place, link layer frames may now pass over this tunnel in both
directions. Frames from the remote user are received at the POP,
stripped of any link framing or transparency bytes, encapsulated in
L2F, and forwarded over the appropriate tunnel.
The Home 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,
with the exception that the hardware in this case is physically
located at the ISP POP. The other direction behaves analogously,
with the Home Gateway encapsulating the packet in L2F, and the POP
stripping L2F before transmitting it out the physical interface to
the remote user.
At this point, the connectivity is a point-to-point PPP or SLIP
connection whose endpoints are the remote user's networking
application on one end and the termination of this connectivity into
the Home Gateway's SLIP or PPP support on the other. Because the
remote user has become simply another dial-up client of the Home
Gateway access server, client connectivity can now be managed using
traditional mechanisms with respect to further authorization,
protocol access, and filtering.
Accounting can be performed at both the NAS as well as the Home
Gateway. This document illustrates some Accounting techniques which
are possible using L2F, but the policies surrounding such Accounting
are outside the scope of this specification.
Because L2F connect notifications for PPP clients contain sufficient
information for a Home Gateway to authenticate and initialize its LCP
state machine, it is not required that the remote user be queried a
second time for CHAP authentication, nor that the client undergo
multiple rounds of LCP negotiation and convergence. These techniques
are intended to optimize connection setup, and are not intended to
deprecate any functions required by the PPP specification.
3.0 Service Model Issues
There are several significant differences between the standard
Internet access service and the Virtual dial-up service with respect
to authentication, address allocation, authorization and accounting.
The details of the differences between these services and the
problems presented by these differences are described below. The
mechanisms used for Virtual Dial-up service are intended to coexist
with more traditional mechanisms; it is intended that an ISP's POP
can simultaneously service ISP clients as well as Virtual dial-up
clients.
3.1 Security
For the Virtual dial-up service, the ISP pursues authentication only
to the extent required to discover the user's apparent identity (and
by implication, their desired Home Gateway). As soon as this is
determined, a connection to the Home Gateway is initiated with the
authentication information gathered by the ISP. The Home Gateway
completes the authentication by either accepting the connection, or
rejecting it.
The Home Gateway must also protect against attempts by third parties
to establish tunnels to the Home Gateway. Tunnel establishment
involves an ISP-to-Home Gateway authentication phase to protect
against such attacks.
3.2 Address Allocation
For an Internet service, the user accepts that the IP address may be
allocated dynamically from a pool of Service provider addresses.
This model often means that the remote user has little or no access
to their home network's resources, due to firewalls and other
security policies applied by the home network to accesses from
external IP addresses.
For the Virtual dial-up service, the Home Gateway can exist behind
the home firewall, allocating addresses which are internal (and, in
fact, can be RFC1597 addresses, or non-IP addresses). Because L2F
tunnels exclusively at the frame layer, the actual policies of such
address management are irrelevant to correct Virtual dial-up service;
for all purposes of PPP or SLIP protocol handling, the dial-in user
appears to have connected at the Home Gateway.
3.3 Authentication
The authentication of the user occurs in three phases; the first at
the ISP, and the second and optional third at the Home gateway.
The ISP uses the username to determine that a Virtual dial-up service
is required and initiate the tunnel connection to the appropriate
Home Gateway. Once a tunnel is established, a new MID is allocated
and a session initiated by forwarding the gathered authentication
information.
The Home Gateway undertakes the second phase by deciding whether or
not to accept the connection. The connection indication may include
CHAP, PAP, or textual authentication information. Based on this
information, the Home Gateway may accept the connection, or may
reject it (for instance, it was a PAP request and the
username/password are found to be incorrect).
Once the connection is accepted, the Home Gateway is free to pursue a
third phase of authentication at the PPP or SLIP layer. These
activities are outside the scope of this specification, but might
include an additional cycle of LCP authentication, proprietary PPP
extensions, or textual challenges carried via a TCP/IP telnet
session.
3.4 Accounting
It is a requirement that both the Access gateway and the Home Gateway
can provide accounting data and hence both may count packets, octets
and connection start and stop times.
Since Virtual dial-up is an access service, accounting of connection
attempts (in particular, failed connection attempts) is of
significant interest. The Home Gateway can reject new connections
based on the authentication information gathered by the ISP, with
corresponding logging. For cases where the Home Gateway accepts the
connection and then continues with further authentication, the Home
Gateway might subsequently disconnect the client. For such
scenarios, the disconnection indication back to the ISP may also
include a reason.
Because the Home Gateway can decline a connection based on the
authentication information collected by the ISP, accounting can
easily draw a distinction between a series of failed connection
attempts and a series of brief successful connections. Lacking this
facility, the Home Gateway must always accept connection requests,
and would need to exchange a number of PPP packets with the remote
system.
4.0 Protocol Definition
The protocol definition for Virtual dial-up services requires two
areas of standardization:
+ Encapsulation of PPP packets within L2F. The ISP NAS and the
Home gateway require a common understanding of the encapsulation
protocol so that SLIP/PPP packets can be successfully transmitted
and received across the Internet.
+ Connection management of L2F and MIDs. The tunnel must be
initiated and terminated, as must MIDs within the tunnel.
Termination includes diagnostic codes to assist in the diagnosis
of problems and to support accounting.
While providing these services, the protocol must address the
following required attributes:
+ Low overhead. The protocol must impose a minimal additional
overhead. This requires a compact encapsulation, and a structure
for omitting some portions of the encapsulation where their
function is not required.
+ Efficiency. The protocol must be efficient to encapsulate and
deencapsulate.
+ Protocol independence. The protocol must make very few
assumptions about the substrate over which L2F packets are
carried.
+ Simple deployment. The protocol must not rely on additional
telecommunication support (for instance, unique called numbers,
or caller ID) to operate.
4.1 Encapsulation within L2F
4.1.1 Encapsulation of PPP within L2F
The PPP packets may be encapsulated within L2F. The packet
encapsulated is the packet as it would be transmitted over a physical
link. The following are NOT present in the packet:
+ Flags
+ Transparency data (ACCM for async, bit stuffing for sync)
+ CRC
The following ARE still present:
+ Address and control flags (unless negotiated away by LCP)
+ Protocol value
4.1.2 Encapsulation of SLIP within L2F
SLIP is encapsulated within L2F in much the same way as PPP. The
transparency characters are removed before encapsulating within L2F,
as is the framing.
4.2 L2F Packet Format
4.2.1 Overall Packet Format
The entire encapsulated packet has the form:
---------------------------------
| |
| L2F Header |
| |
---------------------------------
| |
| Payload packet (SLIP/PPP) |
| |
---------------------------------
| |
| L2F Checksum (optional) |
| |
---------------------------------
4.2.2 Packet Format
An L2F packet has the form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|P|S|0|0|0|0|0|0|0|0|C| Ver | Protocol |Sequence (opt)|\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Multiplex ID | Client ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2F
| Length | Offset (opt) | |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Key (opt) | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
+ (payload) |
+ ..... |
+ ..... |
+ ..... |
+ (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2F Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.3 Version field
The Ver ("Version") field represents the major version of the L2F
software creating the packet. It MUST contain the value 001.
If Ver holds a value other than 1, or any bits are non-zero after bit
S but before bit C, this corresponds to a packet containing
extensions not understood by the receiving end. The packet is
handled as an invalid packet as defined in 4.4.1.
4.2.4 Protocol field
The Protocol specifies the protocol carried within the L2F packet.
Legal values (represented here in hexadecimal) are:
Value Type Description
0x00 L2F_ILLEGAL Illegal
0x01 L2F_PROTO L2F management packets
0x02 L2F_PPP PPP tunneled inside L2F
0x03 L2F_SLIP SLIP tunneled inside L2F
If a packet is received with a Protocol of L2F_ILLEGAL or any other
unrecognized value, it MUST be treated as an illegal packet as
defined in 4.4.1.
4.2.5 Sequence Number
The Sequence number is present if the S bit in the L2F header is set
to 1. This bit MUST be 1 for all L2F management packets. It MAY be
set to 1 for non-L2F management packets. If a non-L2F management
packet is received with the S bit set, all future L2F packets sent
for that MID MUST have the S bit set (and, by implication, be sent
using sequence numbers). For instance, the Home Gateway might choose
to force sequenced packet delivery if it detects an NCP opening for a
protocol which can not operate with out-of-sequence packets.
The Sequence number starts at 0 for the first sequenced L2F packet.
Each subsequent packet is sent with the next increment of the
sequence number. The sequence number is thus a free running counter
represented modulo 256. There is distinct Sequence number state
(i.e., counter) for each distinct MID value.
For packets with S bit and sequence number, the sequence number is
used to protect against duplication of packets, as follows:
The receiving side of the tunnel records the sequence number of each
valid L2F packet it receives. If a received packet appears to have a
value less than or equal to the last received value, the packet MUST
be silently discarded. Otherwise, the packet is accepted and the
sequence number in the packet recorded as the latest value last
received.
For purposes of detecting duplication, a received sequence value is
considered less than or equal to the last received value if its value
lies in the range of the last value and its 127 successor values.
For example, if the last received sequence number was 15, then
packets with sequence numbers 0 through 15, as well as 144 through
255, would be considered less than or equal to, and would be silently
discarded. Otherwise it would be accepted.
4.2.6 Packet Multiplex ID
The Multiplex ID ("MID") identifies a particular connection within
the tunnel. Each new connection is assigned a MID currently unused
within the tunnel. It is recommended that the MID cycle through the
entire 16-bit namespace, to reduce aliasing between previous and
current sessions. A MID value which has been previously used within
a tunnel, has been closed, and will now be used again, must be
considered as an entirely new MID, and initialised as such.
The MID with value 0 is special; it is used to communicate the state
of the tunnel itself, as distinct from any connection within the
tunnel. Only L2F_PROTO packets may be sent using an MID of 0; if any
other type is sent on MID 0, the packet is illegal and MUST be
processed as defined in 4.4.1.
4.2.7 Client ID
The Client ID ("CLID") is used to assist endpoints in demultiplexing
tunnels when the underlying point-to-point substrate lacks an
efficient or dependable technique for doing so directly. Using the
CLID, it is possible to demultiplex multiple tunnels whose packets
arrive over the point-to-point media interleaved, without requiring
media-specific semantics.
When transmitting the L2F_CONF message (described below), the peer's
CLID must be communicated via the Assigned_CLID field. This MUST be
a unique non-zero value on the sender's side, which is to be expected
in the Home Gateway's L2F_CONF response, as well as all future non-
L2F_CONF packets received.
The CLID value from the last valid L2F_CONF message received MUST be
recorded and used as the CLID field value for all subsequent packets
sent to the peer.
Packets with an unknown Client ID MUST be silently discarded.
For the initial packet sent during tunnel establishment, where no
L2F_CONF has yet been received, the CLID field MUST be set to 0.
Thus, during L2F_CONF each side is told its CLID value. All later
packets sent, tagged with this CLID value, serve as a tag which
uniquely identifies this peer.
4.2.8 Length
Length is the size in octets of the entire packet, including header,
all fields present, and payload. Length does not reflect the
addition of the checksum, if one is present. The packet should be
silently discarded if the received packet is shorter than the
indicated length. Additional bytes present in the packet beyond the
indicated length MUST be silently ignored.
4.2.9 Packet Checksum
The Checksum is present if the C bit is present in the header flags.
It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]).
Is is applied over the entire packet starting with the first byte of
L2F flags, through the last byte of payload data. The checksum is
then added as two bytes immediately following the last byte of
payload data.
4.2.10 Payload Offset
The Offset is present if the F bit is set in the header flags. This
field specifies the number of bytes past the L2F header at which the
payload data is expected to start. If it is 0, or the F bit is not
set, the first byte following the last byte of L2F header is the
first byte of payload data.
It is recommended that data skipped due to the payload offset be
initialized to 0's.
For architectures where it is more efficient to have the payload
start at an aligned 32-bit boundary with respect to the L2F header,
it is recommended that the F bit be set, and an offset of 0 be used.
4.2.11 Packet Key
The Key field is present if the K bit is set in the L2F header. The
Key is based on the authentication response last given to the peer
during tunnel creation (the details of tunnel creation are provided
in the next section). It serves as a key during the life of a
session to resist attacks based on spoofing. If a packet is received
in which the Key does not match the expected value, the packet MUST
be silently discarded. Such handling takes precedence over 4.4.1.
The Key value is generated by taking the 128-bit authentication
response from the peer, interpreting it as four adjacent 32-bit words
in network byte order, XOR'ing these words together, and using the
resulting 32-bit value as the Key.
4.2.12 Packet priority
If the P bit in the L2F header is set, this packet is a "priority"
packet. When possible for an implementation, a packet received with
the P bit should be processed in preference to previously received
unprocessed packets without the P bit.
The P bit may be set by an implementation based on criteria beyond
the scope of this specification. However, it is recommended that PPP
keepalive traffic, if any, be sent with this bit set.
4.3 L2F Tunnel Establishment
When the point-to-point link is first initiated between the NAS and
the Home Gateway, the endpoints communicate on MID 0 prior to
providing general L2F services to clients. This communication is
used to verify the presence of L2F on the remote end, and to permit
any needed authentication.
The protocol for such negotiation is always 1, indicating L2F
management. The message itself is structured as a sequence of single
octets indicating an option, followed by zero or more further octets
formatted as needed for the option.
4.3.1 Normal Tunnel Negotiation Sequence
The establishment sequence is best illustrated by a "typical"
connection sequence. Detailed description of each functions follows,
along with descriptions of the handling of exceptional conditions.
Each packet is described as a source->destination on one line, a
description of the L2F packet field contents on the next, and the
contents of the packet's body on following lines. The exact encoding
of octets will be described later.
Note that this example uses the Key option, but does not use the
Offset and Checksum options. The Length field would be present,
reflecting the actual length of the packets as encoded as an octet
stream.
1. NAS->GW:
Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
L2F_CONF
Name: NAS_name
Challenge: Rnd
Assigned_CLID: 22
The NAS decides that a tunnel must be initiated from the NAS to the
GW. An L2F packet is sent with the Proto field indicating an L2F
management message is contained.
Because the tunnel is being initiated, Key is set to 0. The sequence
number starts at 0; the MID is 0 to reflect the establishment of the
tunnel itself. Since the NAS has not yet received an L2F_CONF, the
CLID is set to 0.
The body of the packet specifies the claimed name of the NAS, and a
challenge random number which GW will use in authenticating itself as
a valid tunnel endpoint. Assigned_CLID is generated to be a value
not currently assigned out to any other tunnel to any other Home
Gateway.
2. GW->NAS:
Proto=L2F, Seq=0, MID=0, CLID=22, Key=0
L2F_CONF
Name: GW_name
Challenge: Rnd2
Assigned_CLID: 73
The Home Gateway has processed the previous packet, and sends a
response. The protocol continues to be L2F, with a sequence number 0
(each side maintains its own sequence number for transmissions). MID
continues to be 0 to reflect tunnel establishment. CLID reflects the
Assigned_CLID field of the L2F_CONF received. The Key continues to
be 0 during this phase of tunnel establishment.
The body contains the Home Gateway's name, its own random number
challenge, and its own Assigned_CLID for the NAS to place in the CLID
field of future packets. The CLID is generated in an analogous
manner to that of the NAS. After this, all packets received from the
NAS must be tagged with a CLID field containing 73, and all packets
sent to the NAS must be tagged with a CLID field containing 22.
3. NAS->GW
Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
L2F_OPEN
Response: C(Rnd2)
The NAS responds with its Key now set to reflect the shared secret.
The Key is a CHAP-style hash of the random number received; each
packet hereafter will reflect this calculated value, which serves as
a key for the life of the tunnel. Both the Home Gateway and the NAS
use such Keys for the life of the tunnel. The Key is a 32-bit
representation of the MD5 digest resulting from encrypting the shared
secret; the full MD5 digest is included in the L2F_OPEN response, in
the "response" field.
4. GW->NAS
Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
L2F_OPEN
Response: C(Rnd)
The Home Gateway provides closure of the key from the NAS, reflected
in both the Key field as well as the "response" field. The tunnel is
now available for clients to be established.
4.3.2 Normal Client Negotiation Sequence
This section describes the establishment of a Virtual dial-up client
on a NAS into a Home Gateway. It assumes a tunnel has been created
in the way described in 4.3.1. The client for this example is a PPP
client configured for CHAP.
Treatment of Checksum, Length, and Offset are as in 4.3.1.
1. NAS->GW
Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
L2F_OPEN
Type: CHAP
Name: CHAP-name
Challenge: Rnd3
Response: <Value received, presumably C(Rnd3)>
ID: <ID used in challenge>
The NAS has received a call, tried CHAP with a challenge value of
Rnd3, and found that the client responded. The claimed name lead the
NAS to believe it was a Virtual dial-up client hosted by the Home
Gateway. The next free MID is allocated, and the information
associated with the CHAP challenge/response is included in the
connect notification.
2. GW->NAS
Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
L2F_OPEN
The Home Gateway, by sending back the L2F_OPEN, accepts the client.
3. NAS->GW
Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
<Frame follows>
4. GW->NAS
Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
<Frame follows>
Traffic is now free to flow in either direction as sent by the remote
client or the home site. The contents is uninterpreted data, HDLC in
this case. Data traffic, since it is not the L2F protocol, does not
usually use the Seq field, which is set to 0 in non-L2F messages (see
the S bit in section 4.2.5 for details on an exception to this).
4.4 L2F management message types
When an L2F packet's Proto field specifies L2F management, the body
of the packet is encoded as zero or more options. An option is a
single octet "message type", followed by zero or more sub-options.
Each sub-option is a single byte sub-option value, and further bytes
as appropriate for the sub-option.
Options in L2F are:
Hex Value Abbreviation Description
-------- ------------ -----------
0x00 Invalid Invalid message
0x01 L2F_CONF Request configuration
0x02 L2F_CONF_NAME Name of peer sending L2F_CONF
0x03 L2F_CONF_CHAL Random number peer challenges with
0x04 L2F_CONF_CLID Assigned_CLID for peer to use
0x02 L2F_OPEN Accept configuration
0x01 L2F_OPEN_NAME Name received from client
0x02 L2F_OPEN_CHAL Challenge client received
0x03 L2F_OPEN_RESP Challenge response from client
0x04 L2F_ACK_LCP1 LCP CONFACK accepted from client
0x05 L2F_ACK_LCP2 LCP CONFACK sent to client
0x06 L2F_OPEN_TYPE Type of authentication used
0x07 L2F_OPEN_ID ID associated with authentication
0x08 L2F_REQ_LCP0 First LCP CONFREQ from client
0x03 L2F_CLOSE Request disconnect
0x01 L2F_CLOSE_WHY Reason code for close
0x02 L2F_CLOSE_STR ASCII string description
0x04 L2F_ECHO Verify presence of peer
0x05 L2F_ECHO_RESP Respond to L2F_ECHO
4.4.1 L2F message type: Invalid
If a message is received with this value, or any value higher than
the last recognized option value, or if an illegal packet as defined
by other parts of this specification is received, the packet is
considered invalid. The packet MUST be discarded, and an L2F_CLOSE
of the entire tunnel MUST be requested. Upon receipt of an
L2F_CLOSE, the tunnel itself may be closed. All other received
message MUST be discarded. An implementation MAY close the tunnel
after an interval of time appropriate to the characteristics of the
tunnel.
Note that packets with an invalid Key are discarded, but disconnect
is not initiated. This prevents denial-of-service attacks. Invalid
option types within a message MUST be treated as if the entire
message type was invalid.
4.4.2 L2F_CONF
The L2F message type is used to establish the tunnel between the NAS
and the Home Gateway. MID is always set to 0. The body of such a
message starts with the octet 0x01 (L2F_CONF), followed by all three
of the sub-options below.
The L2F_CONF_NAME sub-option MUST be present. It is encoded as the
octet value 0x02, followed by an octet specifying a non-zero length,
followed by the indicated number of bytes, which are interpreted as
the sender's ASCII name.
The L2F_CONF_CHAL sub-option MUST be present. It is encoded as the
octet value 0x03, followed by a non-zero octet, followed by a number
of bytes specified by this non-zero octet.
The challenge value should be generated using whatever techniques
provide the highest quality of random numbers available to a given
implementation.
The L2F_CONF_CLID sub-option MUST be present. It is encoded as the
octet 0x04, followed by four bytes of Assigned_CLID value. The
Assigned_CLID value is generated as a non-zero 16-bit integer value
unique across all tunnels which exist on the sending system. The
least significant two octets of Assigned_CLID are set to this value,
and the most significant two octets MUST be set to 0.
The CLID field is sent as 0 in the initial L2F_CONF packet from NAS
to Home Gateway, and otherwise MUST be sent containing the value
specified in the Assigned_CLID field of the last L2F_CONF message
received.
Key MUST be set to 0 in all L2F_CONF packets, and no key field is
included in the packet.
When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
packet in the conversation.
When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
Home Gateway's recognition of the tunnel creation request. The Home
Gateway MUST provide its name and its own challenge in the message
body.
In all packets following the L2F_CONF, the Key MUST be set to the
CHAP-style hash of the received challenge bytes. The CHAP-style hash
is done over the concatenation of the low 8 bits of the assigned
CLID, the secret, and the challenge value. Generation of the 32-bit
key value is discussed in section 4.2.11.
4.4.3 L2F_OPEN, tunnel establishment
The L2F_OPEN message is used to provide tunnel setup closure (for a
MID of 0) or to establish a client connection within a tunnel
previously established by L2F_CONF and L2F_OPEN messages (MID not
equal to 0). This section describes tunnel establishment; section
4.4.4 following describes clients established within the tunnel.
An L2F_OPEN for tunnel establishment MUST contain only the sub-option
0x03, L2F_OPEN_RESP. This option MUST be followed by the octet 0x10,
specifying the size of the 128-bit MD5 digest resulting from
encrypting the challenge value in the L2F_CONF, along with the low
byte of the Assigned_CLID. After this byte MUST be the sixteen bytes
of the generated MD5 digest.
If during tunnel establishment an L2F_OPEN is received with an
incorrect L2F_OPEN_RESP, the packet MUST be silently discarded. It
is recommended that such an event generate a log event as well.
4.4.4 L2F_OPEN, client establishment
An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway
indicates the presence of a new dial-in client. When sent back from
the Home Gateway to the NAS, it indicates acceptance of the client.
This message starts with the octet 0x02. When sent from the NAS, it
may contain further sub-options. When sent from the Home Gateway, it
may not contain any sub-options. All further discussion of sub-
options in this section apply only to the NAS to Home Gateway
direction.
The L2F_OPEN_TYPE sub-option MUST be present. It is encoded as the
octet 0x06, followed by a single byte describing the type of
authentication the NAS exchanged with the client in detecting the
client's claimed identification. Implicit in the authentication type
is the encapsulation to be carried over the life of the session. The
authentication types are:
0x01 Textual username/password exchange for SLIP
0x02 PPP CHAP
0x03 PPP PAP
0x04 PPP no authentication
0x05 SLIP no authentication
The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed
by an octet specifying the length of the name, followed by the
indicated number of bytes of the name. This field MUST be present
for any authentication type except 0x04 (None). It MUST contain the
name specified in the client's authentication response.
The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
by an octet specifying the length of the challenge sent, followed by
the challenge itself. This field is only present for CHAP, and MUST
contain the challenge value sent to the client by the NAS.
The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
by an octet specifying the length of the response received, followed
by the client's response to the challenge. For CHAP, this field
contains the response value received by the NAS. For PAP or textual
authentication, it contains the clear text password received from the
client by the NAS. This field is absent for authentication 0x04
"None".
The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
octets 0x04 and 0x05 respectively, followed in either case by two
octets in network byte order specifying the length of the LCP CONFACK
last received from or sent to the client. Following these octets is
an exact copy of the CONFACK packet. L2F_ACK_LCP1 specifies a copy
of the closing CONFACK received from the client, and L2F_ACK_LCP2
specifies a copy of the closing CONFACK sent to the client by the
NAS.
The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by
two octets in network byte order specifying the length of the LCP
CONFREQ initially received from the client. This may be used by the
Home Gateway to detect capabilities of the client which were
negotiated away while starting LCP with the NAS. Detection of such
options may be used by the Home Gateway to decide to renegotiate LCP.
The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by
a single octet. This sub-option is only present for CHAP; the single
octet contains the CHAP Identifier value sent to the client during
the CHAP challenge.
The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
and accept the connection anyway. The Home Gateway would then have
to undertake its own LCP negotiations and authentication. To
maximize the transparency of the L2F tunnel, it is recommended that
extra negotiations and authentication be avoided if possible.
4.4.5 L2F_CLOSE
This message is encoded as the byte 0x03. An L2F_CLOSE may be sent
by either side of the tunnel at any time. When sent with MID of 0,
it indicates the desire to terminate the entire tunnel and all
clients within the tunnel. When sent from the Home Gateway in
response to an L2F_OPEN, it indicates that the Home Gateway has
declined the connection. When sent with a non-zero MID, it indicates
the termination of that client within the tunnel.
The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
four bytes in network byte order specifying a bit mask of reasons for
the disconnection. The bits are encoded as:
0x00000001 Authentication failed
0x00000002 Out of resources
0x00000004 Administrative intervention
0x00000008 User quota exceeded
0x00000010 Protocol error
0x00000020 Unknown user
0x00000040 Incorrect password
0x00000080 PPP configuration incompatible
0x00000100 Wrong multilink PPP destination
Bits in the mask 0xFF000000 are reserved for per-vendor
interpretation.
An implementation can choose to not provide status bits even if it
detects a condition described by one of these bits. For instance, an
implementation may choose to not use 0x00000020 due to security
considerations, as it can be used to probe user name space.
The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
a two-byte length in network byte order, followed by the indicated
number of bytes, which are interpreted as descriptive ASCII text
associated with the disconnection. This string may be ignored, but
could be recorded in a log to provide detailed or auxiliary
information associated with the L2F_CLOSE.
4.4.6 L2F_ECHO
Transmission of L2F_ECHO messages is optional. If an implementation
transmits L2F_ECHO messages, it MUST not transmit more than one such
request each second. The payload size MUST be 64 bytes or less in
length. It is recommended that at least 5 L2F_ECHO messages be sent
without response before an implementation assumes that its peer has
terminated.
The L2F_ECHO message is encoded as the single byte 0x04. It may be
sent by either side once the tunnel is established. MID MUST be 0.
An L2F_ECHO_RESP (documented below) MUST be sent back in response.
4.4.7 L2F_ECHO_RESP
All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP.
The received packet MUST be sent back verbatim, except that the CLID,
sequence number, and checksum (if any) MUST be updated, and the
L2F_ECHO message type changed to an L2F_ECHO_RESP. Payload data
following the 0x04 octet, if any, MUST be preserved in the response.
When an L2F_ECHO_RESP is received, the payload data may be used to
associate this response with a previously sent L2F_ECHO, or the
packet may be silently discarded.
4.5 L2F Message Delivery
L2F is designed to operate over point-to-point unreliable links. It
is not designed to provide flow control of the data traffic, nor does
it provide reliable delivery of this traffic; each protocol tunnel
carried via L2F is expected to manage flow control and retry itself.
Thus, it is only L2F control messages which must be retransmitted;
this process is described in this section.
4.5.1 Sequenced delivery
All L2F control messages (i.e., those L2F packets with a protocol
type of 0x01) are transmitted with a sequence number. The sequence
number is a per-L2F tunnel free running counter which is incremented
(modulo 256) after each packet is transmitted. It is used to permit
the receiving end to detect duplicated or out-of-order packets, and
to discard such packets. Section 4.2.5 describes the process in
detail.
4.5.2 Flow control
L2F control messages are expected to be exchanged lock-step. Thus,
per-client activities can not occur until tunnel setup is complete.
Neither can one client be serviced until the L2F message exchange is
complete for a previous client. Thus, it is expected that rarely--if
ever--should a flow control action be required. If the input queue
of L2F control messages reaches an objectionable level for an
implementation, the implementation may silently discard all messages
in the queue to stabilize the situation.
4.5.3 Tunnel State table
The following enumerates the handling of L2F messages for tunnel
creation in state table format. Events name an L2F_ message type
(the L2F_ portion of the named message is omitted to permit a more
compact table). A start ("*") matches any event not otherwise
matched for the named state.
A NAS starts at initial state Start0, sending a packet before waiting
for its first event. A Home Gateway starts at Start1, waiting for an
initial packet to start service.
If an event is not matched for a given state, the packet associated
with that event is silently discarded.
Tunnel establishment (MID == 0), NAS side.
State Event Action New State
----- ----- ------ ---------
Start0 Send CONF Start1
Start1 CONF Send OPEN Start2
Start1 timeout 1-3 Send CONF Start1
Start1 timeout 4 Clean up tunnel (done)
Start2 OPEN (initiate 1st client) Open1
Start2 timeout 1-3 Send OPEN Start2
Start2 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 no MIDs open Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
Close2 CLOSE Clean up tunnel (done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up tunnel (done)
Tunnel establishment (MID == 0), Home Gateway side.
State Event Action New State
----- ----- ------ ---------
Start0 CONF Send CONF Start1
Start1 CONF Send CONF Start1
Start1 OPEN Send OPEN Open1
Start1 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 OPEN (MID > 0) (1st client, below) Open2
Open1 CLOSE Send CLOSE Close1
Open1 timeout 4 Clean up tunnel (done)
Open2 OPEN (MID > 0) (below) Open2
Open2 CLOSE Send CLOSE Close1
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
4.5.4 Client State table
This table is similar to the previous one, but enumerates the states
for a client connection within a tunnel in the opened state from
4.5.3. As this sequence addresses clients, MID will be non-zero.
Client establishment (MID != 0), NAS side.
State Event Action New State
----- ----- ------ ---------
Start0 Send OPEN Start1
Start1 OPEN (enable forwarding) Open1
Start1 CLOSE Clean up MID (MID done)
Start1 timeout 1-3 Send OPEN Start1
Start1 timeout 4 Clean up MID (MID done)
Start1 client done Send CLOSE Close2
Open1 OPEN (no change) Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Client establishment (MID != 0), Home Gateway side.
State Event Action New State
----- ----- ------ ---------
Start0 OPEN Send OPEN Open1
Start0 OPEN (fail) Send CLOSE Close3
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Close3 OPEN Send CLOSE Close3
Close3 timeout 4 Clean up MID (MID done)
5. Protocol Considerations
Several aspects of operation over L2F, while outside the realm of the
protocol description itself, serve to clarify the operation of L2F.
5.1 PPP Features
Because L2F in operation carries uninterpreted frames, it permits
operation of features without explicit knowledge of these features.
For instance, if a PPP session is carried, L2F is simply transporting
HDLC frames. The two PPP endpoints can negotiate higher-level
features, such as reliable link, compression, multi-link, or
encryption. These features then operate between the two PPP
endpoints (the dial-in client on one end, and the Home Gateway on the
other), with L2F continuing to simply ship HDLC frames back and
forth.
For similar reasons, PPP echo requests, NCP configuration
negotiation, and even termination requests, are all simply tunneled
HDLC frames.
5.2 Termination
As L2F simply tunnels link-layer frames, it does not detect frames
like PPP TERMREQ. L2F termination in these scenarios is driven from
a protocol endpoint; for instance, if a Home Gateway receives a
TERMREQ, its action will be to "hang up" the PPP session. It is the
responsibility of the L2F implementation at the Home Gateway to
convert a "hang up" into an L2F_CLOSE action, which will shut down
client's session in the tunnel cleanly. L2F_CLOSE_WHY and
L2F_CLOSE_STR may be included to describe the reason for the
shutdown.
5.3 Extended Authentication
L2F is compatible with both PAP and CHAP protocols. SLIP does not
provide authentication within the protocol itself, and thus requires
an ASCII exchange of username and password before SLIP is started.
L2F is compatible with this mode of operation as well.
One-time password cards have become very common. To the extent the
NAS can capture and forward the one-time password, L2F operation is
compatible with password cards. For the most general solution, an
arbitrary request/response exchange must be supported. In an L2F
environment, the protocol must be structured so that the NAS can
detect the apparent identity of the user and establish a tunnel
connection to the Home Gateway, where the arbitrary exchange can
occur.
5.4 MNP4 and Apple Remote Access Protocol
L2F appears compatible with Apple's ARAP protocol. Its operation
under L2F has not been described simply because this experimental RFC
does not have a corresponding implementation of such operation.
5.5 Operation of IP and UDP
L2F tries to be self-describing, operating at a level above the
particular media over which it is carried. However, some details of
its connection to media are required to permit interoperable
implementations. This section describes the issues which have been
found when operating L2F over IP and UDP.
L2F uses the well-known UDP port 1701 [4]. The entire L2F packet,
including payload and L2F header, is sent within a UDP datagram. The
source and destination ports are the same (1701), with demultiplexing
being achieved using CLID values. It is legal for the source IP
address of a given CLID to change over the life of a connection, as
this may correspond to a peer with multiple IP interfaces responding
to a network topology change. Responses should reflect the last
source IP address for that CLID.
IP fragmentation may occur as the L2F packet travels over the IP
substrate. L2F makes no special efforts to optimize this. A NAS
implementation MAY cause its LCP to negotiate for a specific MRU,
which could optimize for NAS environments in which the MTUs of the
path over which the L2F packets are likely to travel have a
consistent value.
6.0 Acknowledgments
L2F uses a packet format inspired by GRE [5]. Thanks to Fred Baker
for consultation, Dave Carrel for consulting on security aspects, and
to Paul Traina for philosophical guidance.
7.0 References
[1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988.
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
July 1994.
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
8.0 Security Considerations
Security issues are discussed in Section 3.1.
9.0 Authors' Addresses
Tim Kolar
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: tkolar@cisco.com
Morgan Littlewood
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: littlewo@cisco.com
Andy Valencia
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: valencia@cisco.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
ISO Plain Language
On this page
§1Why Virtual Dial-Up Needs a Tunnel
The traditional dial-up service on the Internet is for registered IP addresses only. The RFC describes a different class of service, virtual dial-up, which allows multiple protocols and unregistered IP addresses, for example privately addressed IP, IPX and AppleTalk dial-up carried over SLIP or PPP across existing Internet infrastructure. The benefit is that a very large investment in access and core infrastructure can be shared, local calls can be used, and existing non-IP applications can be supported securely while still riding on the Internet's access infrastructure.
The user of such a service is assumed to want everything a dedicated dial-up line gives. The remote end system and the home site hosts must need no special software. Authentication must be available as PPP CHAP or PAP, or through other dialogs for protocols such as SLIP, including TACACS+ and RADIUS solutions and support for smart cards and one-time passwords, and the user must be able to manage it independently of the provider. Addressing must be as manageable as with a dedicated line, with the address assigned by the home site rather than the provider. Authorization must be managed by the home site, and accounting must be possible both for the provider's billing and for the user's own charge-back and auditing.
The topology the RFC assumes has a home gateway at the user's site, home LANs behind it, routers on the Internet, remote users dialling in over the PSTN or ISDN, and the provider's network access server at the point of presence. A remote user reaches the home LAN as if they had dialled into the home gateway directly, even though the physical connection goes through the provider's network access server.
Dial in to a provider and you normally get one of their addresses and reach their network, not yours. L2F is for the case where the user wants to reach their own network instead, with their own addresses and their own rules, while the telephone call still goes to the provider.
§2How a Virtual Dial-Up Session Works
The RFC walks through a complete session. The remote user starts a PPP connection to the provider over the PSTN or ISDN. The network access server accepts it and the PPP link is established. The provider then does a partial authentication with CHAP or PAP, and interprets only the username field to decide whether the user wants a virtual dial-up service. Usernames are expected, though not required, to be structured, such as littlewo@cisco.com; alternatively the provider may keep a database mapping users to services, and for a virtual dial-up user that mapping names a specific endpoint, the home gateway.
If no tunnel to the wanted home gateway exists yet, one is created. L2F is deliberately insulated from the details of the media carrying the tunnel, and requires only that the media provide packet-oriented point-to-point connectivity. The RFC names UDP, Frame Relay permanent virtual circuits and X.25 virtual circuits as examples. Once the tunnel exists, an unused multiplex ID is allocated and a connect indication is sent to the home gateway to announce the new session. The home gateway either accepts or rejects, and a rejection may carry a reason that is shown to the user before the call is disconnected.
The connect indication can carry the authentication information the provider gathered, so that the home gateway can complete the authentication itself without another round. For CHAP that means the challenge, the user name and the raw response; for PAP or a plain text dialog it means the user name and the clear-text password. For PPP it can also carry copies of the LCP CONFACK packets sent in each direction to complete LCP negotiation, which lets the home gateway initialise its own PPP state or start a fresh LCP CONFREQ exchange.
When the home gateway accepts, it creates a virtual interface for SLIP or PPP, much as it would for a directly dialled connection, and link-layer frames can now pass over the tunnel in both directions. Frames from the remote user arrive at the provider's point of presence, are stripped of their link framing and transparency bytes, are encapsulated in L2F and are forwarded over the tunnel. The home gateway strips the L2F header and processes them as ordinary incoming frames. The virtual interface behaves much like a hardware interface, except that the hardware sits at the provider's point of presence rather than at the user's site. Accounting can be done at both ends.
The provider checks the user name to find out which home network the call belongs to, opens a tunnel to that network, and passes the connection along with the credentials it already collected. From then on the call behaves like an ordinary dial-in to the home site.
§3Authentication, Addresses and Accounting
On security, the provider authenticates only far enough to discover the user's apparent identity and, by implication, the home gateway they want. It then opens a connection to that gateway carrying the information it gathered, and the home gateway completes the authentication by accepting or rejecting. The home gateway must also protect itself against third parties opening tunnels to it, so tunnel establishment includes an authentication phase between the provider and the home gateway.
On addressing, the ordinary Internet service hands out addresses from a pool of provider addresses, which often means the remote user has little or no access to the home network's resources because firewalls apply to traffic from outside addresses. With virtual dial-up the home gateway can sit behind the home firewall and allocate internal addresses, which may be private addresses under RFC 1597 or addresses of another kind entirely. Because L2F tunnels exclusively at the frame layer, the address management policy is irrelevant to the correctness of the service: for all purposes of PPP or SLIP handling, the dial-in user appears to have connected at the home gateway.
Authentication happens in three phases. The first is at the provider, which uses the user name to decide a virtual dial-up service is needed and to open the tunnel. The second is at the home gateway, which decides whether to accept the connection using the CHAP, PAP or textual information it was sent. The third is optional, at the PPP or SLIP layer, and lies outside the scope of the specification, but might include another cycle of LCP authentication, proprietary PPP extensions or textual challenges carried over a TCP/IP telnet session.
For accounting, the RFC makes it a requirement that both the access gateway and the home gateway can produce accounting data, so both may count packets, octets and connection start and stop times. Because the home gateway can decline a connection on the strength of the information the provider collected, the accounting can tell a series of failed connection attempts apart from a series of brief successful connections. Without that facility the home gateway would have to accept every request and exchange PPP packets with the remote system to find out.
Four things have to be worked out: who is calling, which address they get, who decides what they may do, and how the call is billed. L2F splits these between the provider and the home site, with the home site making the final decision on all of them.
§4.2The L2F Packet Header
An L2F packet is an L2F header, the payload packet, which is the SLIP or PPP frame, and an optional L2F checksum. When PPP is carried, the encapsulated packet is the packet as it would be transmitted over a physical link, with the flags, the transparency data and the CRC removed but the address and control flags and the protocol value still present. SLIP is encapsulated in much the same way, with the transparency characters and the framing removed first.
The header carries a set of flag bits and then the fields. The F bit says that a payload offset is present. The K bit says a packet key is present. The P bit marks a priority packet, and the RFC recommends that PPP keepalive traffic be sent with it set. The S bit says a sequence number is present and must be set for all L2F management packets. Eight bits after the S bit are reserved and must be zero. The C bit says a checksum follows the payload.
The three-bit Version field holds the major version of the L2F software and must contain the value 001. A packet whose version is not 1, or that has non-zero bits between the S bit and the C bit, carries extensions the receiver does not understand and is handled as an invalid packet. The 16-bit Protocol field says what the packet carries: 0x00 is illegal, 0x01 is an L2F management packet, 0x02 is PPP tunnelled inside L2F and 0x03 is SLIP tunnelled inside L2F.
The 16-bit Sequence field is present when the S bit is set. It starts at 0 for the first sequenced packet of each multiplex ID and is a free running counter modulo 256. The receiver records the sequence number of each valid packet and silently discards any packet whose value is less than or equal to the last one it accepted, which is how duplicates are caught. A value counts as less than or equal when it falls in the range of the last value and its 127 successor values, so with 15 as the last value, numbers 0 through 15 and 144 through 255 are discarded.
The 16-bit Multiplex ID identifies one connection within the tunnel, and each new connection gets a value not currently in use. The RFC recommends that the value cycle through the whole 16-bit space to reduce aliasing between sessions. The value 0 is special and carries the state of the tunnel itself, so only L2F management packets may use it. The 16-bit Client ID helps the endpoints sort out which packets belong to which tunnel when several tunnels arrive interleaved over the same point-to-point media. The value the peer assigned during L2F_CONF is used on every later packet sent to it, packets with an unknown client ID are silently discarded, and the first packet of a tunnel carries 0.
The 16-bit Length is the size in octets of the whole packet, header and payload, not counting the checksum. A shorter packet is discarded and extra bytes beyond the stated length are ignored. The optional 16-bit Offset, present when the F bit is set, says how many bytes past the header the payload begins. The optional 32-bit Key, present when the K bit is set, is derived from the authentication response given when the tunnel was created, and resists spoofing for the life of the session; a packet whose key does not match is silently discarded. The optional checksum is the 16-bit CRC used by PPP and HDLC, applied from the first byte of the L2F flags to the last byte of the payload and appended after the payload.
Each L2F packet has a fixed header describing what it carries, which connection it belongs to and how to check it. Most of the header fields are fixed size, and a few are only present when a flag bit says so, which keeps the overhead small.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
F | F | 1 bits | Set when the payload offset field is present. | |
K | K | 1 bits | Set when the packet key field is present. | |
P | P | 1 bits | Set on a priority packet. PPP keepalive traffic should carry it. | |
S | S | 1 bits | Set when the sequence number is present. It must be set for L2F management packets. | |
RESERVED | Reserved | 1 byte | Must be zero in a version 1 packet. Any other value means the receiver does not understand the extensions. | |
C | C | 1 bits | Set when a checksum follows the payload. | |
VER | Ver | 3 bits | Major version of the L2F software. It must contain the value 001. | |
PROTOCOL | Protocol | 2 bytes | What the packet carries: 0x00 illegal, 0x01 L2F management, 0x02 PPP tunnelled, 0x03 SLIP tunnelled. | |
SEQUENCE | Sequence (opt) | 2 bytes | Free running counter modulo 256, one per multiplex ID. Present only when the S bit is set. | |
MULTIPLEX-ID | Multiplex ID | 2 bytes | Identifies one connection within the tunnel. The value 0 carries the state of the tunnel itself. | |
CLIENT-ID | Client ID | 2 bytes | Tag that identifies the peer and separates tunnels arriving interleaved over the same media. | |
LENGTH | Length | 2 bytes | Size in octets of the whole packet, header and payload, not counting the checksum. | |
OFFSET | Offset (opt) | 2 bytes | Number of bytes past the header at which the payload starts. Present only when the F bit is set. | |
KEY | Key (opt) | 4 bytes | Value derived from the authentication response, used to resist spoofing. Present only when the K bit is set. |
- 0x00L2F_ILLEGAL — Illegal. A packet with this value must be treated as an illegal packet.
- 0x01L2F_PROTO — L2F management packets, the tunnel and client setup messages.
- 0x02L2F_PPP — PPP tunnelled inside L2F.
- 0x03L2F_SLIP — SLIP tunnelled inside L2F.
§4.3Establishing a Tunnel and a Client
When the point-to-point link between the network access server and the home gateway is first brought up, the two ends talk on multiplex ID 0 before serving any clients. This exchange verifies that L2F is present at the far end and allows any authentication that is needed. The protocol value is 1, meaning L2F management, and the body of the message is a sequence of single octets naming an option, followed by octets formatted as that option requires.
The tunnel negotiation has four steps. The network access server sends an L2F_CONF with the sequence number 0, multiplex ID 0, client ID 0 and a key of 0, and the body carries its claimed name, a challenge random number and the client ID value it has chosen for the peer. The home gateway replies with its own L2F_CONF, giving its name, its own challenge and its own assigned client ID. The access server then sends an L2F_OPEN whose response is the hash of the challenge it received, and sets the packet key from the shared secret; the home gateway answers with the matching hash, which closes the key exchange. From that point every packet carries the key, and the tunnel is ready for clients.
Establishing a client on that tunnel takes four more steps. The access server allocates the next free multiplex ID and sends an L2F_OPEN carrying the authentication type, the user name, and for CHAP the challenge, the response and the identifier. The home gateway answers with an L2F_OPEN of its own, which accepts the client. After that, PPP frames flow in both directions inside L2F, carrying the same sequence number of 0 because the data traffic is not L2F control traffic.
The management messages themselves are built from options. An option is a single octet naming a message type, followed by sub-options. The message types are L2F_CONF to request configuration, L2F_OPEN to accept configuration and to open a client, L2F_CLOSE to disconnect, and L2F_ECHO and L2F_ECHO_RESP to check that the peer is still there. A packet with an invalid message type, or with an illegal field, must be discarded and an L2F_CLOSE of the whole tunnel requested, although a packet with a wrong key is discarded without disconnecting, which stops denial-of-service attempts. L2F_CLOSE carries a bit mask of reasons, such as authentication failed, out of resources, administrative intervention, user quota exceeded, protocol error or unknown user, and may carry an ASCII description. L2F_ECHO is optional, no implementation may send more than one per second, and its payload must be 64 bytes or less.
L2F is designed to run over point-to-point unreliable links. It does not provide flow control or reliable delivery for the data traffic; each protocol tunnel carried inside L2F is expected to manage flow control and retries itself. Only the L2F control messages have to be retransmitted, and they all carry a sequence number so the receiver can spot duplicates.
Setting up takes two rounds. First the provider and the home site agree a secret and label each other's packets, so neither end can be impersonated. Then, for each call, the provider passes the user's credentials across and the home site accepts or rejects. Only the setup messages are reliable; the user's data is left to PPP to manage.
- L2F_CONFThe access server gives its name, a challenge random number and the client ID it has chosen for the peer.
- L2F_CONFThe home gateway replies with its own name, its own challenge and its own assigned client ID.
- L2F_OPENThe access server returns the hash of the challenge, which sets the key carried by every later packet.
- L2F_OPENThe home gateway returns the matching hash, closing the key exchange.
- L2F_OPEN, MID 1A client has arrived. The access server allocates a multiplex ID and sends the user name and the CHAP challenge and response.
- L2F_OPENThe home gateway accepts the client.
- PPP framesThe client's link-layer frames now travel inside L2F.
- PPP framesAnd back the other way.
§5Running L2F Over IP and UDP
Because L2F carries uninterpreted frames, it lets the two PPP endpoints negotiate higher-level features such as a reliable link, compression, multi-link and encryption without L2F needing to know about them. PPP echo requests, NCP configuration negotiation and even termination requests are simply tunnelled HDLC frames. L2F does not detect a frame such as a PPP TERMREQ: termination is driven from a protocol endpoint, so if the home gateway receives a TERMREQ it hangs up the PPP session, and the L2F implementation at the home gateway turns that hang-up into an L2F_CLOSE that shuts the client's session down cleanly, optionally with a reason code and a text description.
L2F works with both PAP and CHAP. SLIP offers no authentication of its own, so it requires an ASCII exchange of user name and password before SLIP starts, and L2F is compatible with that mode too. One-time password cards work to the extent that the access server can capture and forward the one-time password. The RFC also says that Apple's ARAP protocol appears compatible with L2F, but that its operation under L2F was not described because this experimental RFC has no corresponding implementation of it.
L2F runs over IP and UDP in a particular way. It uses the well-known UDP port 1701, and the entire L2F packet, header and payload alike, is sent inside one UDP datagram. The source and destination ports are the same, 1701, and tunnels are told apart by their client ID values rather than by port numbers. The source IP address for a given client ID may change over the life of a connection, which can happen when a peer with several interfaces answers after a topology change, and responses should reflect the last source address seen for that client ID. IP fragmentation may occur on the way, and L2F makes no special efforts to avoid it, though an access server may have its LCP negotiate a specific maximum receive unit to suit the path the L2F packets will take.
L2F can run over any point-to-point network, and the RFC works through how it behaves over the Internet. The whole packet travels inside one UDP datagram on port 1701, and several tunnels share that port, told apart by a tag in the header.