8. L2TP Over Specific Media
This chapter describes implementation details of L2TP over specific media types. L2TP is designed to operate over various packet transport media, including UDP/IP, Frame Relay, ATM, and others.
8.1 L2TP over UDP/IP
L2TP uses the registered UDP port 1701 for communication between tunnel endpoints. UDP provides packet transport service for both L2TP control messages and data messages.
Port Assignment:
- Source Port: The sender may use any available UDP port as the source port.
- Destination Port: Must use UDP port 1701.
Packet Encapsulation:
The encapsulation format for L2TP packets over UDP/IP is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message or |
| PPP Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Checksum:
The UDP checksum should be calculated and included in all L2TP packets. Receivers must verify the checksum if present. If checksum verification fails, the packet must be discarded.
MTU Considerations:
Since L2TP adds additional encapsulation layers (L2TP header + UDP header + IP header), implementations must consider the path MTU. Typical encapsulation overhead:
- IP Header: 20 bytes (IPv4) or 40 bytes (IPv6)
- UDP Header: 8 bytes
- L2TP Header: At least 6 bytes (may be more depending on options)
Fragmentation:
L2TP implementations are recommended to avoid IP fragmentation. This can be achieved through:
- Path MTU Discovery
- Negotiating MRU (Maximum Receive Unit) during tunnel establishment
- Performing fragmentation at the PPP layer rather than the IP layer
8.2 IP
L2TP packets use IP as their packet transport protocol. IP provides end-to-end packet transport service for L2TP.
IP Version Support:
L2TP is designed to operate over both IPv4 [RFC791] and IPv6 [RFC2460]. Implementations should support at least one IP version and may optionally support both.
IPv4-Specific Considerations:
- Protocol Type: When using UDP encapsulation, the IP protocol field is set to 17 (UDP).
- Type of Service (TOS): L2TP implementations may set the IP TOS field to indicate quality of service requirements. Control messages may require higher priority than data messages.
- Time to Live (TTL): An appropriate TTL value should be set to prevent packets from looping indefinitely in the network.
IPv6-Specific Considerations:
- Next Header: When using UDP encapsulation, set to 17 (UDP).
- Flow Label: The IPv6 flow label can be used to identify packet flows belonging to the same tunnel for QoS processing.
- Hop Limit: Equivalent to IPv4's TTL.
Address Selection:
LACs and LNSs must be able to determine the peer's IP address. This can be achieved through:
- Static configuration
- DNS resolution
- Dynamic discovery mechanisms
Multi-homing Considerations:
If a tunnel endpoint has multiple IP addresses (multi-homed), implementations must ensure that all packets for a tunnel use a consistent source address. This is critical for maintaining tunnel state and preventing confusion.
Security:
When L2TP operates over IP, it is strongly recommended to use IPsec [RFC2401] to protect tunnel traffic. IPsec can provide:
- Confidentiality: Through ESP encryption
- Integrity: Through AH or ESP authentication
- Endpoint Authentication: Through IKE
Detailed security considerations are covered in Chapter 9.
Implementation Notes:
-
Port Multiplexing: Multiple tunnels can be established between the same pair of IP addresses, differentiated by Tunnel ID.
-
NAT Traversal: When L2TP needs to traverse NAT devices, additional mechanisms may be required (such as L2TP/IPsec NAT-T).
-
Firewall Considerations: Firewalls must allow bidirectional communication on UDP port 1701 to support L2TP.
-
QoS Mapping: Implementations can map QoS requirements from the PPP layer to the IP layer's DSCP or TOS field.