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