Work has already started on adding L2TPv3 support to OpenL2TP. This topic describes the work being done and will be updated as the work progresses. If you'd like to get involved, please contact email@example.com
L2TPv3 is defined in http://www.ietf.org/rfc/rfc3931.txt
and provides several interesting features.
- A mechanism to tunnel protocols other than PPP. Specifications exist to carry raw ethernet, VLAN, ATM, PPP, HDLC and other traffic types over L2TP. The frame type is referred to as a pseudowire type. The L2TP control protocol is extended such that L2TP peers can configure the pseudowire type to be used for each L2TP session. Pseudowires of different types can be carried over the same L2TP tunnel.
- The ability to carry L2TP frames over IP without UDP. The L2TPv3 specification states that IP encapsulation is mandatory while UDP encapsulation (as used in L2TPv2) is optional. L2TP/IP packets use IP protocol 115.
- Increased sequence number sizes in data packets to avoid wrapping too quickly when L2TP is used in fast, modern networks.
- Automatic fallback from L2TPv3 to L2TPv2 if a peer doesn't support L2TPv3. This simplifies network upgrades.
OpenL2TP was designed from the beginning with the L2TP data path being handled by the kernel and the control protocol implemented in userspace. This results in optimal performance and seamless integration with other Linux subsystems such as IPSec and packet filtering. For L2TPv3, the same approach will be used.
In the data path, the separation of the L2TP parts of the protocol from data packet formats requires significant work in the existing kernel code. In L2TPv2, only PPP frames can be carried, so the kernel code naturally reflects that. For L2TPv3, however, we must separate the PPP code from L2TP, and split the driver to handle different pseudowire types. Add to that, the new IP encapsulation (no UDP) means that the implementation must support two different tunnel socket types, namely UDP and L2TPIP.
The existing pppol2tp kernel driver is to be split into separate drivers. The common L2TP part is handled by one driver, and each pseudowire type is implemented in separate drivers (one per pseudowire type). The L2TP IP encapsulation type is handled by another new driver which implements a new L2TPIP socket type. The result is a set of L2TP drivers which can be installed by the user according to the features required. When built as kernel modules, automatically generated module dependencies will allow the user to load the required pseudowire driver and its dependent modules will be loaded automatically. Ethernet pseudowires will expose ethernet network interfaces which may be added to a Linux bridge or configured with a network address using standard Linux tools. For backwards compatibility, the PPP pseudowire driver will be called pppol2tp.ko, so existing userspace scripts need not change if only the PPP pseudowire type is required.
The L2TPv3 data packet header is different to the L2TPv2 header. Tunnel and session ids are 32-bit values in L2TPv3, not 16-bit values. In data packets, some fields from L2TPv2 are moved from the header into a Layer 2 specific header which follows the main L2TP header. The Layer 2 specific header is variable length and typically contains sequence numbers, if present. L2TPv3 data packets also have an optional cookie, which may be 0, 4 or 8 bytes long and contains a value exchanged with the peer when the session is set up. Another difference is that the optional offset field in the L2TPv2 header is replaced by a configurable offset value which is signalled to the peer when the session is set up.
Things must change in the control protocol implementation too (openl2tpd). Fortunately, for L2TP control packets, the changes in L2TPv3 are minor. Sequence numbers of control packets remain at 16-bits and the optional offset field is no longer present. However, there are many new AVPs and user-configurable parameters. Fortunately, the OpenL2TP implementation is straightforward to extend. However, the changes are still significant. The most complex part is how to implement a userspace-kernel interface to carry the many configuration settings of L2TPv3. The existing L2TPv2 solution uses L2TP-specific socket options with fixed size parameter structures. In L2TPv3, some pseudowire types don't have a socket per session (e.g. ethernet), so we can't use socket options to pass session configuration parameters to the kernel. Therefore, the userspace-kernel interface will use Linux netlink sockets, which come with features such as TLV parameter helpers. (Netlink sockets are commonly used to control kernel subsystems such as IPSec and firewall.) The updated openl2tpd will try to use netlink sockets, but if they are unavailable, it will revert to the existing L2TPv2 functionality using the sockopt-based APIs.When will all this be available?
It is a goal to release initial alpha code early in 2009.
Much of the above is already implemented and running in lab conditions. PPP and ethernet pseudowires are working. However, it is not yet suitable for alpha release. The following must be completed before the software is made available.
Can I help?
- Prepare kernel patches for discussion in the Linux networking community.
- Write documentation. There are many new configurable parameters. The complexity of this stuff means that good installation and troubleshooting guides are essential.
- Implement the new L2TPv3 ACK message in openl2tpd
- Implement more L2TPv3 AVPs. Only a minimal subset has been implemented so far, just enough to get L2TPv3 tunnels and sessions running with OpenL2TP at both ends. It is unlikely that OpenL2TP will work with other L2TPv3 implementations until more work is done in this area.
- Implement an L2TPv3 protocol plugin for wireshark. Unfortunately, wireshark only knows how to display a specific Cisco HDLC L2TPv3 format; it doesn't know about Layer 2 specific headers, cookies and negotiated offsets. While a good protocol handler in wireshark isn't essential for deployment of OpenL2TP, it will help with interopability testing.
If you're a developer and would like to get involved in OpenL2TP, please contact firstname.lastname@example.org
. You will need to be comfortable with patching and building custom kernels.
If you're not a developer but you'd like to test early versions of OpenL2TP's L2TPv3 support, please let us know. Also, if you're a network design consultant, we're particularly interested in feedback on features and common L2TPv3 use cases.Who is paying for this development?
Katalix Systems (http://www.katalix.com
) owns and develops OpenL2TP. However, development proceeds in spare time as time allows, since the developers at Katalix work most of the time for its paying customers. Sometimes, other project work takes priority so development on OpenL2TP can be sporadic at times. If you would like to see L2TPv3 supported sooner, please consider sponsoring some of the development.