Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
NG_L2TP(4)		 BSD Kernel Interfaces Manual		    NG_L2TP(4)

NAME
     ng_l2tp --	L2TP protocol netgraph node type

SYNOPSIS
     #include <netgraph/ng_l2tp.h>

DESCRIPTION
     The ng_l2tp node type implements the encapsulation	layer of the L2TP pro-
     tocol as described	in RFC 2661.  This includes adding the L2TP packet
     header for	outgoing packets and verifying and removing it for incoming
     packets.  The node	maintains the L2TP sequence number state and handles
     control session packet acknowledgment and retransmission.

HOOKS
     The ng_l2tp node type supports the	following hooks:

	lower	      L2TP frames
	ctrl	      Control packets
	session_hhhh  Session 0xhhhh data packets

     L2TP control and data packets are transmitted to, and received from, the
     L2TP peer via the lower hook.  Typically this hook	would be connected to
     the inet/dgram/udp	hook of	an ng_ksocket(4) node for L2TP over UDP.

     The ctrl hook connects to the local L2TP management entity.  L2TP control
     messages (without any L2TP	headers) are transmitted and received on this
     hook.  Messages written to	this hook are guaranteed to be delivered to
     the peer reliably,	in order, and without duplicates.

     Packets written to	the ctrl hook must contain a two byte session ID
     prepended to the frame (in	network	order).	 This session ID is copied to
     the outgoing L2TP header.	Similarly, packets read	from the ctrl hook
     will have the received session ID prepended.

     Once an L2TP session has been created, the	corresponding session hook may
     be	used to	transmit and receive the session's data	frames:	for the	ses-
     sion with session ID 0xabcd, the hook is named session_abcd.

CONTROL	MESSAGES
     This node type supports the generic control messages, plus	the following:

     NGM_L2TP_SET_CONFIG
	 This command updates the configuration	of the node.  It takes a
	 struct	ng_l2tp_config as an argument:

	 /* Configuration for a	node */
	 struct	ng_l2tp_config {
	     u_char	 enabled;	 /* enables traffic flow */
	     u_char	 match_id;	 /* tunnel id must match 'tunnel_id' */
	     u_int16_t	 tunnel_id;	 /* local tunnel id */
	     u_int16_t	 peer_id;	 /* peer's tunnel id */
	     u_int16_t	 peer_win;	 /* peer's max recv window size	*/
	     u_int16_t	 rexmit_max;	 /* max	retransmits before failure */
	     u_int16_t	 rexmit_max_to;	 /* max	delay between retransmits */
	 };

	 The enabled field enables packet processing.  Each time this field is
	 changed back to zero the sequence number state	is reset. In this way,
	 reuse of a node is possible.

	 The tunnel_id field configures	the local tunnel ID for	the control
	 connection.  The match_id field determines how	incoming L2TP packets
	 with a	tunnel ID field	different from tunnel_id are handled.  If
	 match_id is non-zero, they will be dropped; otherwise,	they will be
	 dropped only if the tunnel ID is non-zero.  Typically tunnel_id is
	 set to	the local tunnel ID as soon as it is known and match_id	is set
	 to non-zero after receipt of the SCCRP	or SCCCN control message.

	 The peer's tunnel ID should be	set in peer_id as soon as it is
	 learned, typically after receipt of a SCCRQ or	SCCRP control message.
	 This value is copied into the L2TP header for outgoing	packets.

	 The peer_win field should be set from the "Receive Window Size" AVP
	 received from the peer.  The default value for	this field is one;
	 zero is an invalid value.  As long as enabled is non-zero, this value
	 may not be decreased.

	 The rexmit_max	and rexmit_max_to fields configure packet retransmis-
	 sion.	rexmit_max_to is the maximum retransmission delay between
	 packets, in seconds.  The retransmit delay will start at a small
	 value and increase exponentially up to	this limit.  The rexmit_max
	 sets the maximum number of times a packet will	be retransmitted with-
	 out being acknowledged	before a failure condition is declared.	 Once
	 a failure condition is	declared, each additional retransmission will
	 cause the ng_l2tp node	to send	a NGM_L2TP_ACK_FAILURE control message
	 back to the node that sent the	last NGM_L2TP_SET_CONFIG.  Appropriate
	 action	should then be taken to	shutdown the control connection.

     NGM_L2TP_GET_CONFIG
	 Returns the current configuration as a	struct ng_l2tp_config.

     NGM_L2TP_SET_SESS_CONFIG
	 This control message configures a single data session.	 The corre-
	 sponding hook must already be connected before	sending	this command.
	 The argument is a struct ng_l2tp_sess_config:

	 /* Configuration for a	session	hook */
	 struct	ng_l2tp_sess_config {
	     u_int16_t	 session_id;	 /* local session id */
	     u_int16_t	 peer_id;	 /* peer's session id */
	     u_char	 control_dseq;	 /* we control data sequencing?	*/
	     u_char	 enable_dseq;	 /* enable data	sequencing? */
	     u_char	 include_length; /* include length field? */
	 };

	 The session_id	and peer_id fields configure the local and remote ses-
	 sion ID's, respectively.

	 The control_dseq and enable_dseq fields determine whether sequence
	 numbers are used with L2TP data packets.  If enable_dseq is zero,
	 then no sequence numbers are sent and incoming	sequence numbers are
	 ignored.  Otherwise, sequence numbers are included on outgoing	pack-
	 ets and checked on incoming packets.

	 If control_dseq is non-zero, then the setting of enable_dseq will
	 never change except by	another	NGM_L2TP_SET_SESS_CONFIG control mes-
	 sage.	If control_dseq	is zero, then the peer controls	whether	se-
	 quence	numbers	are used: if an	incoming L2TP data packet contains se-
	 quence	numbers, enable_dseq is	set to one, and	conversely if an in-
	 coming	L2TP data packet does not contain sequence numbers,
	 enable_dseq is	set to zero.  The current value	of enable_dseq is al-
	 ways accessible via the NGM_L2TP_GET_SESS_CONFIG control message (see
	 below).  Typically an LNS would set control_dseq to one while a LAC
	 would set control_dseq	to zero	(if the	Sequencing Required AVP	were
	 not sent), thus giving	control	of data	packet sequencing to the LNS.

	 The include_length field determines whether the L2TP header length
	 field is included in outgoing L2TP data packets.  For incoming	pack-
	 ets, the L2TP length field is always checked when present.

     NGM_L2TP_GET_SESS_CONFIG
	 This command takes a two byte session ID as an	argument and returns
	 the current configuration for the corresponding data session as a
	 struct	ng_l2tp_sess_config.  The corresponding	session	hook must be
	 connected.

     NGM_L2TP_GET_STATS
	 This command takes a two byte session ID as an	argument and returns a
	 struct	ng_l2tp_stats containing statistics for	the corresponding data
	 session.  The corresponding session hook must be connected.

     NGM_L2TP_CLR_STATS
	 This command takes a two byte session ID as an	argument and clears
	 the statistics	for that data session.	The corresponding session hook
	 must be connected.

     NGM_L2TP_GETCLR_STATS
	 Same as NGM_L2TP_GET_STATS, but also atomically clears	the statistics
	 as well.

SHUTDOWN
     This node shuts down upon receipt of a NGM_SHUTDOWN control message, or
     when all hooks have been disconnected.

SEE ALSO
     netgraph(4), ng_ksocket(4), ng_ppp(4), ng_pptp(4),	ngctl(8)

     W.	Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and	B. Palter,
     Layer Two Tunneling Protocol L2TP,	RFC 2661.

HISTORY
     The ng_l2tp node type was developed at Packet Design, LLC.
     http://www.packetdesign.com/

AUTHORS
     Archie Cobbs <archie@packetdesign.com>

BSD				April 22, 2002				   BSD

NAME | SYNOPSIS | DESCRIPTION | HOOKS | CONTROL MESSAGES | SHUTDOWN | SEE ALSO | HISTORY | AUTHORS

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=ng_l2tp&sektion=4&manpath=FreeBSD+4.7-RELEASE>

home | help