xref: /OK3568_Linux_fs/kernel/Documentation/networking/udplite.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0
2*4882a593Smuzhiyun
3*4882a593Smuzhiyun================================
4*4882a593SmuzhiyunThe UDP-Lite protocol (RFC 3828)
5*4882a593Smuzhiyun================================
6*4882a593Smuzhiyun
7*4882a593Smuzhiyun
8*4882a593Smuzhiyun  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
9*4882a593Smuzhiyun  is a variable-length checksum. This has advantages for transport of multimedia
10*4882a593Smuzhiyun  (video, VoIP) over wireless networks, as partly damaged packets can still be
11*4882a593Smuzhiyun  fed into the codec instead of being discarded due to a failed checksum test.
12*4882a593Smuzhiyun
13*4882a593Smuzhiyun  This file briefly describes the existing kernel support and the socket API.
14*4882a593Smuzhiyun  For in-depth information, you can consult:
15*4882a593Smuzhiyun
16*4882a593Smuzhiyun   - The UDP-Lite Homepage:
17*4882a593Smuzhiyun     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
18*4882a593Smuzhiyun
19*4882a593Smuzhiyun     From here you can also download some example application source code.
20*4882a593Smuzhiyun
21*4882a593Smuzhiyun   - The UDP-Lite HOWTO on
22*4882a593Smuzhiyun     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
23*4882a593Smuzhiyun
24*4882a593Smuzhiyun   - The Wireshark UDP-Lite WiKi (with capture files):
25*4882a593Smuzhiyun     https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
26*4882a593Smuzhiyun
27*4882a593Smuzhiyun   - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
28*4882a593Smuzhiyun
29*4882a593Smuzhiyun
30*4882a593Smuzhiyun1. Applications
31*4882a593Smuzhiyun===============
32*4882a593Smuzhiyun
33*4882a593Smuzhiyun  Several applications have been ported successfully to UDP-Lite. Ethereal
34*4882a593Smuzhiyun  (now called wireshark) has UDP-Litev4/v6 support by default.
35*4882a593Smuzhiyun
36*4882a593Smuzhiyun  Porting applications to UDP-Lite is straightforward: only socket level and
37*4882a593Smuzhiyun  IPPROTO need to be changed; senders additionally set the checksum coverage
38*4882a593Smuzhiyun  length (default = header length = 8). Details are in the next section.
39*4882a593Smuzhiyun
40*4882a593Smuzhiyun2. Programming API
41*4882a593Smuzhiyun==================
42*4882a593Smuzhiyun
43*4882a593Smuzhiyun  UDP-Lite provides a connectionless, unreliable datagram service and hence
44*4882a593Smuzhiyun  uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
45*4882a593Smuzhiyun  very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
46*4882a593Smuzhiyun  socket(2) call so that the statement looks like::
47*4882a593Smuzhiyun
48*4882a593Smuzhiyun      s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
49*4882a593Smuzhiyun
50*4882a593Smuzhiyun  or, respectively,
51*4882a593Smuzhiyun
52*4882a593Smuzhiyun  ::
53*4882a593Smuzhiyun
54*4882a593Smuzhiyun      s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
55*4882a593Smuzhiyun
56*4882a593Smuzhiyun  With just the above change you are able to run UDP-Lite services or connect
57*4882a593Smuzhiyun  to UDP-Lite servers. The kernel will assume that you are not interested in
58*4882a593Smuzhiyun  using partial checksum coverage and so emulate UDP mode (full coverage).
59*4882a593Smuzhiyun
60*4882a593Smuzhiyun  To make use of the partial checksum coverage facilities requires setting a
61*4882a593Smuzhiyun  single socket option, which takes an integer specifying the coverage length:
62*4882a593Smuzhiyun
63*4882a593Smuzhiyun    * Sender checksum coverage: UDPLITE_SEND_CSCOV
64*4882a593Smuzhiyun
65*4882a593Smuzhiyun      For example::
66*4882a593Smuzhiyun
67*4882a593Smuzhiyun	int val = 20;
68*4882a593Smuzhiyun	setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
69*4882a593Smuzhiyun
70*4882a593Smuzhiyun      sets the checksum coverage length to 20 bytes (12b data + 8b header).
71*4882a593Smuzhiyun      Of each packet only the first 20 bytes (plus the pseudo-header) will be
72*4882a593Smuzhiyun      checksummed. This is useful for RTP applications which have a 12-byte
73*4882a593Smuzhiyun      base header.
74*4882a593Smuzhiyun
75*4882a593Smuzhiyun
76*4882a593Smuzhiyun    * Receiver checksum coverage: UDPLITE_RECV_CSCOV
77*4882a593Smuzhiyun
78*4882a593Smuzhiyun      This option is the receiver-side analogue. It is truly optional, i.e. not
79*4882a593Smuzhiyun      required to enable traffic with partial checksum coverage. Its function is
80*4882a593Smuzhiyun      that of a traffic filter: when enabled, it instructs the kernel to drop
81*4882a593Smuzhiyun      all packets which have a coverage _less_ than this value. For example, if
82*4882a593Smuzhiyun      RTP and UDP headers are to be protected, a receiver can enforce that only
83*4882a593Smuzhiyun      packets with a minimum coverage of 20 are admitted::
84*4882a593Smuzhiyun
85*4882a593Smuzhiyun	int min = 20;
86*4882a593Smuzhiyun	setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
87*4882a593Smuzhiyun
88*4882a593Smuzhiyun  The calls to getsockopt(2) are analogous. Being an extension and not a stand-
89*4882a593Smuzhiyun  alone protocol, all socket options known from UDP can be used in exactly the
90*4882a593Smuzhiyun  same manner as before, e.g. UDP_CORK or UDP_ENCAP.
91*4882a593Smuzhiyun
92*4882a593Smuzhiyun  A detailed discussion of UDP-Lite checksum coverage options is in section IV.
93*4882a593Smuzhiyun
94*4882a593Smuzhiyun3. Header Files
95*4882a593Smuzhiyun===============
96*4882a593Smuzhiyun
97*4882a593Smuzhiyun  The socket API requires support through header files in /usr/include:
98*4882a593Smuzhiyun
99*4882a593Smuzhiyun    * /usr/include/netinet/in.h
100*4882a593Smuzhiyun      to define IPPROTO_UDPLITE
101*4882a593Smuzhiyun
102*4882a593Smuzhiyun    * /usr/include/netinet/udplite.h
103*4882a593Smuzhiyun      for UDP-Lite header fields and protocol constants
104*4882a593Smuzhiyun
105*4882a593Smuzhiyun  For testing purposes, the following can serve as a ``mini`` header file::
106*4882a593Smuzhiyun
107*4882a593Smuzhiyun    #define IPPROTO_UDPLITE       136
108*4882a593Smuzhiyun    #define SOL_UDPLITE           136
109*4882a593Smuzhiyun    #define UDPLITE_SEND_CSCOV     10
110*4882a593Smuzhiyun    #define UDPLITE_RECV_CSCOV     11
111*4882a593Smuzhiyun
112*4882a593Smuzhiyun  Ready-made header files for various distros are in the UDP-Lite tarball.
113*4882a593Smuzhiyun
114*4882a593Smuzhiyun4. Kernel Behaviour with Regards to the Various Socket Options
115*4882a593Smuzhiyun==============================================================
116*4882a593Smuzhiyun
117*4882a593Smuzhiyun
118*4882a593Smuzhiyun  To enable debugging messages, the log level need to be set to 8, as most
119*4882a593Smuzhiyun  messages use the KERN_DEBUG level (7).
120*4882a593Smuzhiyun
121*4882a593Smuzhiyun  1) Sender Socket Options
122*4882a593Smuzhiyun
123*4882a593Smuzhiyun  If the sender specifies a value of 0 as coverage length, the module
124*4882a593Smuzhiyun  assumes full coverage, transmits a packet with coverage length of 0
125*4882a593Smuzhiyun  and according checksum.  If the sender specifies a coverage < 8 and
126*4882a593Smuzhiyun  different from 0, the kernel assumes 8 as default value.  Finally,
127*4882a593Smuzhiyun  if the specified coverage length exceeds the packet length, the packet
128*4882a593Smuzhiyun  length is used instead as coverage length.
129*4882a593Smuzhiyun
130*4882a593Smuzhiyun  2) Receiver Socket Options
131*4882a593Smuzhiyun
132*4882a593Smuzhiyun  The receiver specifies the minimum value of the coverage length it
133*4882a593Smuzhiyun  is willing to accept.  A value of 0 here indicates that the receiver
134*4882a593Smuzhiyun  always wants the whole of the packet covered. In this case, all
135*4882a593Smuzhiyun  partially covered packets are dropped and an error is logged.
136*4882a593Smuzhiyun
137*4882a593Smuzhiyun  It is not possible to specify illegal values (<0 and <8); in these
138*4882a593Smuzhiyun  cases the default of 8 is assumed.
139*4882a593Smuzhiyun
140*4882a593Smuzhiyun  All packets arriving with a coverage value less than the specified
141*4882a593Smuzhiyun  threshold are discarded, these events are also logged.
142*4882a593Smuzhiyun
143*4882a593Smuzhiyun  3) Disabling the Checksum Computation
144*4882a593Smuzhiyun
145*4882a593Smuzhiyun  On both sender and receiver, checksumming will always be performed
146*4882a593Smuzhiyun  and cannot be disabled using SO_NO_CHECK. Thus::
147*4882a593Smuzhiyun
148*4882a593Smuzhiyun	setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );
149*4882a593Smuzhiyun
150*4882a593Smuzhiyun  will always will be ignored, while the value of::
151*4882a593Smuzhiyun
152*4882a593Smuzhiyun	getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
153*4882a593Smuzhiyun
154*4882a593Smuzhiyun  is meaningless (as in TCP). Packets with a zero checksum field are
155*4882a593Smuzhiyun  illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
156*4882a593Smuzhiyun
157*4882a593Smuzhiyun  4) Fragmentation
158*4882a593Smuzhiyun
159*4882a593Smuzhiyun  The checksum computation respects both buffersize and MTU. The size
160*4882a593Smuzhiyun  of UDP-Lite packets is determined by the size of the send buffer. The
161*4882a593Smuzhiyun  minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
162*4882a593Smuzhiyun  in include/net/sock.h), the default value is configurable as
163*4882a593Smuzhiyun  net.core.wmem_default or via setting the SO_SNDBUF socket(7)
164*4882a593Smuzhiyun  option. The maximum upper bound for the send buffer is determined
165*4882a593Smuzhiyun  by net.core.wmem_max.
166*4882a593Smuzhiyun
167*4882a593Smuzhiyun  Given a payload size larger than the send buffer size, UDP-Lite will
168*4882a593Smuzhiyun  split the payload into several individual packets, filling up the
169*4882a593Smuzhiyun  send buffer size in each case.
170*4882a593Smuzhiyun
171*4882a593Smuzhiyun  The precise value also depends on the interface MTU. The interface MTU,
172*4882a593Smuzhiyun  in turn, may trigger IP fragmentation. In this case, the generated
173*4882a593Smuzhiyun  UDP-Lite packet is split into several IP packets, of which only the
174*4882a593Smuzhiyun  first one contains the L4 header.
175*4882a593Smuzhiyun
176*4882a593Smuzhiyun  The send buffer size has implications on the checksum coverage length.
177*4882a593Smuzhiyun  Consider the following example::
178*4882a593Smuzhiyun
179*4882a593Smuzhiyun    Payload: 1536 bytes          Send Buffer:     1024 bytes
180*4882a593Smuzhiyun    MTU:     1500 bytes          Coverage Length:  856 bytes
181*4882a593Smuzhiyun
182*4882a593Smuzhiyun  UDP-Lite will ship the 1536 bytes in two separate packets::
183*4882a593Smuzhiyun
184*4882a593Smuzhiyun    Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
185*4882a593Smuzhiyun    Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes
186*4882a593Smuzhiyun
187*4882a593Smuzhiyun  The coverage packet covers the UDP-Lite header and 848 bytes of the
188*4882a593Smuzhiyun  payload in the first packet, the second packet is fully covered. Note
189*4882a593Smuzhiyun  that for the second packet, the coverage length exceeds the packet
190*4882a593Smuzhiyun  length. The kernel always re-adjusts the coverage length to the packet
191*4882a593Smuzhiyun  length in such cases.
192*4882a593Smuzhiyun
193*4882a593Smuzhiyun  As an example of what happens when one UDP-Lite packet is split into
194*4882a593Smuzhiyun  several tiny fragments, consider the following example::
195*4882a593Smuzhiyun
196*4882a593Smuzhiyun    Payload: 1024 bytes            Send buffer size: 1024 bytes
197*4882a593Smuzhiyun    MTU:      300 bytes            Coverage length:   575 bytes
198*4882a593Smuzhiyun
199*4882a593Smuzhiyun    +-+-----------+--------------+--------------+--------------+
200*4882a593Smuzhiyun    |8|    272    |      280     |     280      |     280      |
201*4882a593Smuzhiyun    +-+-----------+--------------+--------------+--------------+
202*4882a593Smuzhiyun		280            560            840           1032
203*4882a593Smuzhiyun					^
204*4882a593Smuzhiyun    *****checksum coverage*************
205*4882a593Smuzhiyun
206*4882a593Smuzhiyun  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
207*4882a593Smuzhiyun  header). According to the interface MTU, these are split into 4 IP
208*4882a593Smuzhiyun  packets (280 byte IP payload + 20 byte IP header). The kernel module
209*4882a593Smuzhiyun  sums the contents of the entire first two packets, plus 15 bytes of
210*4882a593Smuzhiyun  the last packet before releasing the fragments to the IP module.
211*4882a593Smuzhiyun
212*4882a593Smuzhiyun  To see the analogous case for IPv6 fragmentation, consider a link
213*4882a593Smuzhiyun  MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
214*4882a593Smuzhiyun  coverage is less than 1232 bytes (MTU minus IPv6/fragment header
215*4882a593Smuzhiyun  lengths), only the first fragment needs to be considered. When using
216*4882a593Smuzhiyun  larger checksum coverage lengths, each eligible fragment needs to be
217*4882a593Smuzhiyun  checksummed. Suppose we have a checksum coverage of 3062. The buffer
218*4882a593Smuzhiyun  of 3356 bytes will be split into the following fragments::
219*4882a593Smuzhiyun
220*4882a593Smuzhiyun    Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
221*4882a593Smuzhiyun    Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
222*4882a593Smuzhiyun    Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data
223*4882a593Smuzhiyun
224*4882a593Smuzhiyun  The first two fragments have to be checksummed in full, of the last
225*4882a593Smuzhiyun  fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
226*4882a593Smuzhiyun
227*4882a593Smuzhiyun  While it is important that such cases are dealt with correctly, they
228*4882a593Smuzhiyun  are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
229*4882a593Smuzhiyun  performance over wireless (or generally noisy) links and thus smaller
230*4882a593Smuzhiyun  coverage lengths are likely to be expected.
231*4882a593Smuzhiyun
232*4882a593Smuzhiyun5. UDP-Lite Runtime Statistics and their Meaning
233*4882a593Smuzhiyun================================================
234*4882a593Smuzhiyun
235*4882a593Smuzhiyun  Exceptional and error conditions are logged to syslog at the KERN_DEBUG
236*4882a593Smuzhiyun  level.  Live statistics about UDP-Lite are available in /proc/net/snmp
237*4882a593Smuzhiyun  and can (with newer versions of netstat) be viewed using::
238*4882a593Smuzhiyun
239*4882a593Smuzhiyun			    netstat -svu
240*4882a593Smuzhiyun
241*4882a593Smuzhiyun  This displays UDP-Lite statistics variables, whose meaning is as follows.
242*4882a593Smuzhiyun
243*4882a593Smuzhiyun   ============     =====================================================
244*4882a593Smuzhiyun   InDatagrams      The total number of datagrams delivered to users.
245*4882a593Smuzhiyun
246*4882a593Smuzhiyun   NoPorts          Number of packets received to an unknown port.
247*4882a593Smuzhiyun		    These cases are counted separately (not as InErrors).
248*4882a593Smuzhiyun
249*4882a593Smuzhiyun   InErrors         Number of erroneous UDP-Lite packets. Errors include:
250*4882a593Smuzhiyun
251*4882a593Smuzhiyun		      * internal socket queue receive errors
252*4882a593Smuzhiyun		      * packet too short (less than 8 bytes or stated
253*4882a593Smuzhiyun			coverage length exceeds received length)
254*4882a593Smuzhiyun		      * xfrm4_policy_check() returned with error
255*4882a593Smuzhiyun		      * application has specified larger min. coverage
256*4882a593Smuzhiyun			length than that of incoming packet
257*4882a593Smuzhiyun		      * checksum coverage violated
258*4882a593Smuzhiyun		      * bad checksum
259*4882a593Smuzhiyun
260*4882a593Smuzhiyun   OutDatagrams     Total number of sent datagrams.
261*4882a593Smuzhiyun   ============     =====================================================
262*4882a593Smuzhiyun
263*4882a593Smuzhiyun   These statistics derive from the UDP MIB (RFC 2013).
264*4882a593Smuzhiyun
265*4882a593Smuzhiyun6. IPtables
266*4882a593Smuzhiyun===========
267*4882a593Smuzhiyun
268*4882a593Smuzhiyun  There is packet match support for UDP-Lite as well as support for the LOG target.
269*4882a593Smuzhiyun  If you copy and paste the following line into /etc/protocols::
270*4882a593Smuzhiyun
271*4882a593Smuzhiyun    udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]
272*4882a593Smuzhiyun
273*4882a593Smuzhiyun  then::
274*4882a593Smuzhiyun
275*4882a593Smuzhiyun	      iptables -A INPUT -p udplite -j LOG
276*4882a593Smuzhiyun
277*4882a593Smuzhiyun  will produce logging output to syslog. Dropping and rejecting packets also works.
278*4882a593Smuzhiyun
279*4882a593Smuzhiyun7. Maintainer Address
280*4882a593Smuzhiyun=====================
281*4882a593Smuzhiyun
282*4882a593Smuzhiyun  The UDP-Lite patch was developed at
283*4882a593Smuzhiyun
284*4882a593Smuzhiyun		    University of Aberdeen
285*4882a593Smuzhiyun		    Electronics Research Group
286*4882a593Smuzhiyun		    Department of Engineering
287*4882a593Smuzhiyun		    Fraser Noble Building
288*4882a593Smuzhiyun		    Aberdeen AB24 3UE; UK
289*4882a593Smuzhiyun
290*4882a593Smuzhiyun  The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
291*4882a593Smuzhiyun  code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.
292