Commit 2f77a3f50c4336dd5358aec0abb5247ded168515
Committed by
David S. Miller
1 parent
789a4a2c61
Exists in
master
and in
4 other branches
l2tp: Update documentation
This patch adds documentation about the L2TPv3 functionality. Signed-off-by: James Chapman <jchapman@katalix.com> Reviewed-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Showing 1 changed file with 213 additions and 34 deletions Side-by-side Diff
Documentation/networking/l2tp.txt
1 | -This brief document describes how to use the kernel's PPPoL2TP driver | |
2 | -to provide L2TP functionality. L2TP is a protocol that tunnels one or | |
3 | -more PPP sessions over a UDP tunnel. It is commonly used for VPNs | |
1 | +This document describes how to use the kernel's L2TP drivers to | |
2 | +provide L2TP functionality. L2TP is a protocol that tunnels one or | |
3 | +more sessions over an IP tunnel. It is commonly used for VPNs | |
4 | 4 | (L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP |
5 | -network infrastructure. | |
5 | +network infrastructure. With L2TPv3, it is also useful as a Layer-2 | |
6 | +tunneling infrastructure. | |
6 | 7 | |
8 | +Features | |
9 | +======== | |
10 | + | |
11 | +L2TPv2 (PPP over L2TP (UDP tunnels)). | |
12 | +L2TPv3 ethernet pseudowires. | |
13 | +L2TPv3 PPP pseudowires. | |
14 | +L2TPv3 IP encapsulation. | |
15 | +Netlink sockets for L2TPv3 configuration management. | |
16 | + | |
17 | +History | |
18 | +======= | |
19 | + | |
20 | +The original pppol2tp driver was introduced in 2.6.23 and provided | |
21 | +L2TPv2 functionality (rfc2661). L2TPv2 is used to tunnel one or more PPP | |
22 | +sessions over a UDP tunnel. | |
23 | + | |
24 | +L2TPv3 (rfc3931) changes the protocol to allow different frame types | |
25 | +to be passed over an L2TP tunnel by moving the PPP-specific parts of | |
26 | +the protocol out of the core L2TP packet headers. Each frame type is | |
27 | +known as a pseudowire type. Ethernet, PPP, HDLC, Frame Relay and ATM | |
28 | +pseudowires for L2TP are defined in separate RFC standards. Another | |
29 | +change for L2TPv3 is that it can be carried directly over IP with no | |
30 | +UDP header (UDP is optional). It is also possible to create static | |
31 | +unmanaged L2TPv3 tunnels manually without a control protocol | |
32 | +(userspace daemon) to manage them. | |
33 | + | |
34 | +To support L2TPv3, the original pppol2tp driver was split up to | |
35 | +separate the L2TP and PPP functionality. Existing L2TPv2 userspace | |
36 | +apps should be unaffected as the original pppol2tp sockets API is | |
37 | +retained. L2TPv3, however, uses netlink to manage L2TPv3 tunnels and | |
38 | +sessions. | |
39 | + | |
7 | 40 | Design |
8 | 41 | ====== |
9 | 42 | |
10 | -The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by | |
11 | -which PPP frames carried through an L2TP session are passed through | |
12 | -the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all | |
13 | -PPP interaction with the peer. PPP network interfaces are created for | |
14 | -each local PPP endpoint. | |
43 | +The L2TP protocol separates control and data frames. The L2TP kernel | |
44 | +drivers handle only L2TP data frames; control frames are always | |
45 | +handled by userspace. L2TP control frames carry messages between L2TP | |
46 | +clients/servers and are used to setup / teardown tunnels and | |
47 | +sessions. An L2TP client or server is implemented in userspace. | |
15 | 48 | |
16 | -The L2TP protocol http://www.faqs.org/rfcs/rfc2661.html defines L2TP | |
17 | -control and data frames. L2TP control frames carry messages between | |
18 | -L2TP clients/servers and are used to setup / teardown tunnels and | |
19 | -sessions. An L2TP client or server is implemented in userspace and | |
20 | -will use a regular UDP socket per tunnel. L2TP data frames carry PPP | |
21 | -frames, which may be PPP control or PPP data. The kernel's PPP | |
49 | +Each L2TP tunnel is implemented using a UDP or L2TPIP socket; L2TPIP | |
50 | +provides L2TPv3 IP encapsulation (no UDP) and is implemented using a | |
51 | +new l2tpip socket family. The tunnel socket is typically created by | |
52 | +userspace, though for unmanaged L2TPv3 tunnels, the socket can also be | |
53 | +created by the kernel. Each L2TP session (pseudowire) gets a network | |
54 | +interface instance. In the case of PPP, these interfaces are created | |
55 | +indirectly by pppd using a pppol2tp socket. In the case of ethernet, | |
56 | +the netdevice is created upon a netlink request to create an L2TPv3 | |
57 | +ethernet pseudowire. | |
58 | + | |
59 | +For PPP, the PPPoL2TP driver, net/l2tp/l2tp_ppp.c, provides a | |
60 | +mechanism by which PPP frames carried through an L2TP session are | |
61 | +passed through the kernel's PPP subsystem. The standard PPP daemon, | |
62 | +pppd, handles all PPP interaction with the peer. PPP network | |
63 | +interfaces are created for each local PPP endpoint. The kernel's PPP | |
22 | 64 | subsystem arranges for PPP control frames to be delivered to pppd, |
23 | 65 | while data frames are forwarded as usual. |
24 | 66 | |
67 | +For ethernet, the L2TPETH driver, net/l2tp/l2tp_eth.c, implements a | |
68 | +netdevice driver, managing virtual ethernet devices, one per | |
69 | +pseudowire. These interfaces can be managed using standard Linux tools | |
70 | +such as "ip" and "ifconfig". If only IP frames are passed over the | |
71 | +tunnel, the interface can be given an IP addresses of itself and its | |
72 | +peer. If non-IP frames are to be passed over the tunnel, the interface | |
73 | +can be added to a bridge using brctl. All L2TP datapath protocol | |
74 | +functions are handled by the L2TP core driver. | |
75 | + | |
25 | 76 | Each tunnel and session within a tunnel is assigned a unique tunnel_id |
26 | 77 | and session_id. These ids are carried in the L2TP header of every |
27 | -control and data packet. The pppol2tp driver uses them to lookup | |
28 | -internal tunnel and/or session contexts. Zero tunnel / session ids are | |
29 | -treated specially - zero ids are never assigned to tunnels or sessions | |
30 | -in the network. In the driver, the tunnel context keeps a pointer to | |
31 | -the tunnel UDP socket. The session context keeps a pointer to the | |
32 | -PPPoL2TP socket, as well as other data that lets the driver interface | |
33 | -to the kernel PPP subsystem. | |
78 | +control and data packet. (Actually, in L2TPv3, the tunnel_id isn't | |
79 | +present in data frames - it is inferred from the IP connection on | |
80 | +which the packet was received.) The L2TP driver uses the ids to lookup | |
81 | +internal tunnel and/or session contexts to determine how to handle the | |
82 | +packet. Zero tunnel / session ids are treated specially - zero ids are | |
83 | +never assigned to tunnels or sessions in the network. In the driver, | |
84 | +the tunnel context keeps a reference to the tunnel UDP or L2TPIP | |
85 | +socket. The session context holds data that lets the driver interface | |
86 | +to the kernel's network frame type subsystems, i.e. PPP, ethernet. | |
34 | 87 | |
35 | -Note that the pppol2tp kernel driver handles only L2TP data frames; | |
36 | -L2TP control frames are simply passed up to userspace in the UDP | |
37 | -tunnel socket. The kernel handles all datapath aspects of the | |
38 | -protocol, including data packet resequencing (if enabled). | |
88 | +Userspace Programming | |
89 | +===================== | |
39 | 90 | |
40 | -There are a number of requirements on the userspace L2TP daemon in | |
41 | -order to use the pppol2tp driver. | |
91 | +For L2TPv2, there are a number of requirements on the userspace L2TP | |
92 | +daemon in order to use the pppol2tp driver. | |
42 | 93 | |
43 | 94 | 1. Use a UDP socket per tunnel. |
44 | 95 | |
... | ... | @@ -86,6 +137,35 @@ |
86 | 137 | to retrieve tunnel and session statistics from the kernel using the |
87 | 138 | PPPoX socket of the appropriate tunnel or session. |
88 | 139 | |
140 | +For L2TPv3, userspace must use the netlink API defined in | |
141 | +include/linux/l2tp.h to manage tunnel and session contexts. The | |
142 | +general procedure to create a new L2TP tunnel with one session is:- | |
143 | + | |
144 | +1. Open a GENL socket using L2TP_GENL_NAME for configuring the kernel | |
145 | + using netlink. | |
146 | + | |
147 | +2. Create a UDP or L2TPIP socket for the tunnel. | |
148 | + | |
149 | +3. Create a new L2TP tunnel using a L2TP_CMD_TUNNEL_CREATE | |
150 | + request. Set attributes according to desired tunnel parameters, | |
151 | + referencing the UDP or L2TPIP socket created in the previous step. | |
152 | + | |
153 | +4. Create a new L2TP session in the tunnel using a | |
154 | + L2TP_CMD_SESSION_CREATE request. | |
155 | + | |
156 | +The tunnel and all of its sessions are closed when the tunnel socket | |
157 | +is closed. The netlink API may also be used to delete sessions and | |
158 | +tunnels. Configuration and status info may be set or read using netlink. | |
159 | + | |
160 | +The L2TP driver also supports static (unmanaged) L2TPv3 tunnels. These | |
161 | +are where there is no L2TP control message exchange with the peer to | |
162 | +setup the tunnel; the tunnel is configured manually at each end of the | |
163 | +tunnel. There is no need for an L2TP userspace application in this | |
164 | +case -- the tunnel socket is created by the kernel and configured | |
165 | +using parameters sent in the L2TP_CMD_TUNNEL_CREATE netlink | |
166 | +request. The "ip" utility of iproute2 has commands for managing static | |
167 | +L2TPv3 tunnels; do "ip l2tp help" for more information. | |
168 | + | |
89 | 169 | Debugging |
90 | 170 | ========= |
91 | 171 | |
... | ... | @@ -102,6 +182,69 @@ |
102 | 182 | PPPOL2TP_MSG_SEQ sequence numbers handling |
103 | 183 | PPPOL2TP_MSG_DATA data packets |
104 | 184 | |
185 | +If enabled, files under a l2tp debugfs directory can be used to dump | |
186 | +kernel state about L2TP tunnels and sessions. To access it, the | |
187 | +debugfs filesystem must first be mounted. | |
188 | + | |
189 | +# mount -t debugfs debugfs /debug | |
190 | + | |
191 | +Files under the l2tp directory can then be accessed. | |
192 | + | |
193 | +# cat /debug/l2tp/tunnels | |
194 | + | |
195 | +The debugfs files should not be used by applications to obtain L2TP | |
196 | +state information because the file format is subject to change. It is | |
197 | +implemented to provide extra debug information to help diagnose | |
198 | +problems.) Users should use the netlink API. | |
199 | + | |
200 | +/proc/net/pppol2tp is also provided for backwards compaibility with | |
201 | +the original pppol2tp driver. It lists information about L2TPv2 | |
202 | +tunnels and sessions only. Its use is discouraged. | |
203 | + | |
204 | +Unmanaged L2TPv3 Tunnels | |
205 | +======================== | |
206 | + | |
207 | +Some commercial L2TP products support unmanaged L2TPv3 ethernet | |
208 | +tunnels, where there is no L2TP control protocol; tunnels are | |
209 | +configured at each side manually. New commands are available in | |
210 | +iproute2's ip utility to support this. | |
211 | + | |
212 | +To create an L2TPv3 ethernet pseudowire between local host 192.168.1.1 | |
213 | +and peer 192.168.1.2, using IP addresses 10.5.1.1 and 10.5.1.2 for the | |
214 | +tunnel endpoints:- | |
215 | + | |
216 | +# modprobe l2tp_eth | |
217 | +# modprobe l2tp_netlink | |
218 | + | |
219 | +# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \ | |
220 | + udp_dport 5000 encap udp local 192.168.1.1 remote 192.168.1.2 | |
221 | +# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1 | |
222 | +# ifconfig -a | |
223 | +# ip addr add 10.5.1.2/32 peer 10.5.1.1/32 dev l2tpeth0 | |
224 | +# ifconfig l2tpeth0 up | |
225 | + | |
226 | +Choose IP addresses to be the address of a local IP interface and that | |
227 | +of the remote system. The IP addresses of the l2tpeth0 interface can be | |
228 | +anything suitable. | |
229 | + | |
230 | +Repeat the above at the peer, with ports, tunnel/session ids and IP | |
231 | +addresses reversed. The tunnel and session IDs can be any non-zero | |
232 | +32-bit number, but the values must be reversed at the peer. | |
233 | + | |
234 | +Host 1 Host2 | |
235 | +udp_sport=5000 udp_sport=5001 | |
236 | +udp_dport=5001 udp_dport=5000 | |
237 | +tunnel_id=42 tunnel_id=45 | |
238 | +peer_tunnel_id=45 peer_tunnel_id=42 | |
239 | +session_id=128 session_id=5196755 | |
240 | +peer_session_id=5196755 peer_session_id=128 | |
241 | + | |
242 | +When done at both ends of the tunnel, it should be possible to send | |
243 | +data over the network. e.g. | |
244 | + | |
245 | +# ping 10.5.1.1 | |
246 | + | |
247 | + | |
105 | 248 | Sample Userspace Code |
106 | 249 | ===================== |
107 | 250 | |
108 | 251 | |
109 | 252 | |
110 | 253 | |
... | ... | @@ -158,13 +301,49 @@ |
158 | 301 | } |
159 | 302 | return 0; |
160 | 303 | |
304 | +Internal Implementation | |
305 | +======================= | |
306 | + | |
307 | +The driver keeps a struct l2tp_tunnel context per L2TP tunnel and a | |
308 | +struct l2tp_session context for each session. The l2tp_tunnel is | |
309 | +always associated with a UDP or L2TP/IP socket and keeps a list of | |
310 | +sessions in the tunnel. The l2tp_session context keeps kernel state | |
311 | +about the session. It has private data which is used for data specific | |
312 | +to the session type. With L2TPv2, the session always carried PPP | |
313 | +traffic. With L2TPv3, the session can also carry ethernet frames | |
314 | +(ethernet pseudowire) or other data types such as ATM, HDLC or Frame | |
315 | +Relay. | |
316 | + | |
317 | +When a tunnel is first opened, the reference count on the socket is | |
318 | +increased using sock_hold(). This ensures that the kernel socket | |
319 | +cannot be removed while L2TP's data structures reference it. | |
320 | + | |
321 | +Some L2TP sessions also have a socket (PPP pseudowires) while others | |
322 | +do not (ethernet pseudowires). We can't use the socket reference count | |
323 | +as the reference count for session contexts. The L2TP implementation | |
324 | +therefore has its own internal reference counts on the session | |
325 | +contexts. | |
326 | + | |
327 | +To Do | |
328 | +===== | |
329 | + | |
330 | +Add L2TP tunnel switching support. This would route tunneled traffic | |
331 | +from one L2TP tunnel into another. Specified in | |
332 | +http://tools.ietf.org/html/draft-ietf-l2tpext-tunnel-switching-08 | |
333 | + | |
334 | +Add L2TPv3 VLAN pseudowire support. | |
335 | + | |
336 | +Add L2TPv3 IP pseudowire support. | |
337 | + | |
338 | +Add L2TPv3 ATM pseudowire support. | |
339 | + | |
161 | 340 | Miscellaneous |
162 | -============ | |
341 | +============= | |
163 | 342 | |
164 | -The PPPoL2TP driver was developed as part of the OpenL2TP project by | |
343 | +The L2TP drivers were developed as part of the OpenL2TP project by | |
165 | 344 | Katalix Systems Ltd. OpenL2TP is a full-featured L2TP client / server, |
166 | 345 | designed from the ground up to have the L2TP datapath in the |
167 | 346 | kernel. The project also implemented the pppol2tp plugin for pppd |
168 | 347 | which allows pppd to use the kernel driver. Details can be found at |
169 | -http://openl2tp.sourceforge.net. | |
348 | +http://www.openl2tp.org. |