L2F, Layer 2 Forwarding

Description Glossary RFCs Publications Obsolete RFCs


Protocol suite: TCP/IP.
Protocol type:Application layer tunneling protocol.
Ports:1701 (UDP) host, server.
Related protocol: L2TP, Level 2 Tunneling Protocol.
MIME subtype:
Working groups:

L2F header PPP | SLIP message L2F checksum

L2F header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
F K P S reserved C Version Protocol Sequence
Multiplex ID Client ID
Length Offset
Data ::: Checksum

F. 1 bit.
The Offset field is present if this bit is set.

K, key field present. 1 bit.
The Key field is present if this bit is set.

P, priority. 1 bit.
This packet is a priority packet if this bit is set. 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. It is recommended that PPP keepalive traffic be sent with this bit set.

S, Sequence valid. 1 bit.
The Sequence field is present if this bit is set. This bit MUST be set for all management packets.

reserved. 8 bits.
Always cleared to zero.

C, Checksum present. 1 bit.
If set, a 16 bit checksum follows the encapsulated payload.

Version. 3 bits. Always set to 1.
The protocol version.

Protocol. 8 bits.
Specifies the protocol encapsulated within the L2F packet.

1L2F management.
2PPP tunneling.
3SLIP tunneling.

Sequence. 0 or 8 bits.
Sequence number. This field is cleared to zero for the first sequenced L2F packet.

MID, Multiplex ID. 16 bits.
This field identifies a particular connection within the tunnel. Each new connection is assigned an 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. An 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 initialized as such. MID = zero is used to communicate the state of the tunnel itself. Only L2F management packets may be sent using an MID of 0.

Client ID. 16 bits.
This fieldis 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.

Length. 16 bits.
The size of the packet in bytes not including the checksum field.

Offset. 0 or 16 bits.
Payload Offset. This field is present if the F bit is set. This field contains the number of bytes past the L2F header at which the payload data is expected to start. If it is cleared to 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.

Key. 32 bits.

Data. Variable length.

Checksum. 0 or 16 bits.
This field is present if the C bit is set. It is a 16 bit CRC as used by PPP/HDLC. 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.



[RFC 2341] Cisco Layer Two Forwarding (Protocol) "L2F".


Obsolete RFCs:

Description Glossary RFCs Publications Obsolete RFCs