162306a36Sopenharmony_ci.. SPDX-License-Identifier: GPL-2.0
262306a36Sopenharmony_ci
362306a36Sopenharmony_ci================================
462306a36Sopenharmony_ciThe UDP-Lite protocol (RFC 3828)
562306a36Sopenharmony_ci================================
662306a36Sopenharmony_ci
762306a36Sopenharmony_ci
862306a36Sopenharmony_ci  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
962306a36Sopenharmony_ci  is a variable-length checksum. This has advantages for transport of multimedia
1062306a36Sopenharmony_ci  (video, VoIP) over wireless networks, as partly damaged packets can still be
1162306a36Sopenharmony_ci  fed into the codec instead of being discarded due to a failed checksum test.
1262306a36Sopenharmony_ci
1362306a36Sopenharmony_ci  This file briefly describes the existing kernel support and the socket API.
1462306a36Sopenharmony_ci  For in-depth information, you can consult:
1562306a36Sopenharmony_ci
1662306a36Sopenharmony_ci   - The UDP-Lite Homepage:
1762306a36Sopenharmony_ci     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
1862306a36Sopenharmony_ci
1962306a36Sopenharmony_ci     From here you can also download some example application source code.
2062306a36Sopenharmony_ci
2162306a36Sopenharmony_ci   - The UDP-Lite HOWTO on
2262306a36Sopenharmony_ci     http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
2362306a36Sopenharmony_ci
2462306a36Sopenharmony_ci   - The Wireshark UDP-Lite WiKi (with capture files):
2562306a36Sopenharmony_ci     https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
2662306a36Sopenharmony_ci
2762306a36Sopenharmony_ci   - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
2862306a36Sopenharmony_ci
2962306a36Sopenharmony_ci
3062306a36Sopenharmony_ci1. Applications
3162306a36Sopenharmony_ci===============
3262306a36Sopenharmony_ci
3362306a36Sopenharmony_ci  Several applications have been ported successfully to UDP-Lite. Ethereal
3462306a36Sopenharmony_ci  (now called wireshark) has UDP-Litev4/v6 support by default.
3562306a36Sopenharmony_ci
3662306a36Sopenharmony_ci  Porting applications to UDP-Lite is straightforward: only socket level and
3762306a36Sopenharmony_ci  IPPROTO need to be changed; senders additionally set the checksum coverage
3862306a36Sopenharmony_ci  length (default = header length = 8). Details are in the next section.
3962306a36Sopenharmony_ci
4062306a36Sopenharmony_ci2. Programming API
4162306a36Sopenharmony_ci==================
4262306a36Sopenharmony_ci
4362306a36Sopenharmony_ci  UDP-Lite provides a connectionless, unreliable datagram service and hence
4462306a36Sopenharmony_ci  uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
4562306a36Sopenharmony_ci  very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
4662306a36Sopenharmony_ci  socket(2) call so that the statement looks like::
4762306a36Sopenharmony_ci
4862306a36Sopenharmony_ci      s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
4962306a36Sopenharmony_ci
5062306a36Sopenharmony_ci  or, respectively,
5162306a36Sopenharmony_ci
5262306a36Sopenharmony_ci  ::
5362306a36Sopenharmony_ci
5462306a36Sopenharmony_ci      s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
5562306a36Sopenharmony_ci
5662306a36Sopenharmony_ci  With just the above change you are able to run UDP-Lite services or connect
5762306a36Sopenharmony_ci  to UDP-Lite servers. The kernel will assume that you are not interested in
5862306a36Sopenharmony_ci  using partial checksum coverage and so emulate UDP mode (full coverage).
5962306a36Sopenharmony_ci
6062306a36Sopenharmony_ci  To make use of the partial checksum coverage facilities requires setting a
6162306a36Sopenharmony_ci  single socket option, which takes an integer specifying the coverage length:
6262306a36Sopenharmony_ci
6362306a36Sopenharmony_ci    * Sender checksum coverage: UDPLITE_SEND_CSCOV
6462306a36Sopenharmony_ci
6562306a36Sopenharmony_ci      For example::
6662306a36Sopenharmony_ci
6762306a36Sopenharmony_ci	int val = 20;
6862306a36Sopenharmony_ci	setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
6962306a36Sopenharmony_ci
7062306a36Sopenharmony_ci      sets the checksum coverage length to 20 bytes (12b data + 8b header).
7162306a36Sopenharmony_ci      Of each packet only the first 20 bytes (plus the pseudo-header) will be
7262306a36Sopenharmony_ci      checksummed. This is useful for RTP applications which have a 12-byte
7362306a36Sopenharmony_ci      base header.
7462306a36Sopenharmony_ci
7562306a36Sopenharmony_ci
7662306a36Sopenharmony_ci    * Receiver checksum coverage: UDPLITE_RECV_CSCOV
7762306a36Sopenharmony_ci
7862306a36Sopenharmony_ci      This option is the receiver-side analogue. It is truly optional, i.e. not
7962306a36Sopenharmony_ci      required to enable traffic with partial checksum coverage. Its function is
8062306a36Sopenharmony_ci      that of a traffic filter: when enabled, it instructs the kernel to drop
8162306a36Sopenharmony_ci      all packets which have a coverage _less_ than this value. For example, if
8262306a36Sopenharmony_ci      RTP and UDP headers are to be protected, a receiver can enforce that only
8362306a36Sopenharmony_ci      packets with a minimum coverage of 20 are admitted::
8462306a36Sopenharmony_ci
8562306a36Sopenharmony_ci	int min = 20;
8662306a36Sopenharmony_ci	setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
8762306a36Sopenharmony_ci
8862306a36Sopenharmony_ci  The calls to getsockopt(2) are analogous. Being an extension and not a stand-
8962306a36Sopenharmony_ci  alone protocol, all socket options known from UDP can be used in exactly the
9062306a36Sopenharmony_ci  same manner as before, e.g. UDP_CORK or UDP_ENCAP.
9162306a36Sopenharmony_ci
9262306a36Sopenharmony_ci  A detailed discussion of UDP-Lite checksum coverage options is in section IV.
9362306a36Sopenharmony_ci
9462306a36Sopenharmony_ci3. Header Files
9562306a36Sopenharmony_ci===============
9662306a36Sopenharmony_ci
9762306a36Sopenharmony_ci  The socket API requires support through header files in /usr/include:
9862306a36Sopenharmony_ci
9962306a36Sopenharmony_ci    * /usr/include/netinet/in.h
10062306a36Sopenharmony_ci      to define IPPROTO_UDPLITE
10162306a36Sopenharmony_ci
10262306a36Sopenharmony_ci    * /usr/include/netinet/udplite.h
10362306a36Sopenharmony_ci      for UDP-Lite header fields and protocol constants
10462306a36Sopenharmony_ci
10562306a36Sopenharmony_ci  For testing purposes, the following can serve as a ``mini`` header file::
10662306a36Sopenharmony_ci
10762306a36Sopenharmony_ci    #define IPPROTO_UDPLITE       136
10862306a36Sopenharmony_ci    #define SOL_UDPLITE           136
10962306a36Sopenharmony_ci    #define UDPLITE_SEND_CSCOV     10
11062306a36Sopenharmony_ci    #define UDPLITE_RECV_CSCOV     11
11162306a36Sopenharmony_ci
11262306a36Sopenharmony_ci  Ready-made header files for various distros are in the UDP-Lite tarball.
11362306a36Sopenharmony_ci
11462306a36Sopenharmony_ci4. Kernel Behaviour with Regards to the Various Socket Options
11562306a36Sopenharmony_ci==============================================================
11662306a36Sopenharmony_ci
11762306a36Sopenharmony_ci
11862306a36Sopenharmony_ci  To enable debugging messages, the log level need to be set to 8, as most
11962306a36Sopenharmony_ci  messages use the KERN_DEBUG level (7).
12062306a36Sopenharmony_ci
12162306a36Sopenharmony_ci  1) Sender Socket Options
12262306a36Sopenharmony_ci
12362306a36Sopenharmony_ci  If the sender specifies a value of 0 as coverage length, the module
12462306a36Sopenharmony_ci  assumes full coverage, transmits a packet with coverage length of 0
12562306a36Sopenharmony_ci  and according checksum.  If the sender specifies a coverage < 8 and
12662306a36Sopenharmony_ci  different from 0, the kernel assumes 8 as default value.  Finally,
12762306a36Sopenharmony_ci  if the specified coverage length exceeds the packet length, the packet
12862306a36Sopenharmony_ci  length is used instead as coverage length.
12962306a36Sopenharmony_ci
13062306a36Sopenharmony_ci  2) Receiver Socket Options
13162306a36Sopenharmony_ci
13262306a36Sopenharmony_ci  The receiver specifies the minimum value of the coverage length it
13362306a36Sopenharmony_ci  is willing to accept.  A value of 0 here indicates that the receiver
13462306a36Sopenharmony_ci  always wants the whole of the packet covered. In this case, all
13562306a36Sopenharmony_ci  partially covered packets are dropped and an error is logged.
13662306a36Sopenharmony_ci
13762306a36Sopenharmony_ci  It is not possible to specify illegal values (<0 and <8); in these
13862306a36Sopenharmony_ci  cases the default of 8 is assumed.
13962306a36Sopenharmony_ci
14062306a36Sopenharmony_ci  All packets arriving with a coverage value less than the specified
14162306a36Sopenharmony_ci  threshold are discarded, these events are also logged.
14262306a36Sopenharmony_ci
14362306a36Sopenharmony_ci  3) Disabling the Checksum Computation
14462306a36Sopenharmony_ci
14562306a36Sopenharmony_ci  On both sender and receiver, checksumming will always be performed
14662306a36Sopenharmony_ci  and cannot be disabled using SO_NO_CHECK. Thus::
14762306a36Sopenharmony_ci
14862306a36Sopenharmony_ci	setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );
14962306a36Sopenharmony_ci
15062306a36Sopenharmony_ci  will always will be ignored, while the value of::
15162306a36Sopenharmony_ci
15262306a36Sopenharmony_ci	getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
15362306a36Sopenharmony_ci
15462306a36Sopenharmony_ci  is meaningless (as in TCP). Packets with a zero checksum field are
15562306a36Sopenharmony_ci  illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
15662306a36Sopenharmony_ci
15762306a36Sopenharmony_ci  4) Fragmentation
15862306a36Sopenharmony_ci
15962306a36Sopenharmony_ci  The checksum computation respects both buffersize and MTU. The size
16062306a36Sopenharmony_ci  of UDP-Lite packets is determined by the size of the send buffer. The
16162306a36Sopenharmony_ci  minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
16262306a36Sopenharmony_ci  in include/net/sock.h), the default value is configurable as
16362306a36Sopenharmony_ci  net.core.wmem_default or via setting the SO_SNDBUF socket(7)
16462306a36Sopenharmony_ci  option. The maximum upper bound for the send buffer is determined
16562306a36Sopenharmony_ci  by net.core.wmem_max.
16662306a36Sopenharmony_ci
16762306a36Sopenharmony_ci  Given a payload size larger than the send buffer size, UDP-Lite will
16862306a36Sopenharmony_ci  split the payload into several individual packets, filling up the
16962306a36Sopenharmony_ci  send buffer size in each case.
17062306a36Sopenharmony_ci
17162306a36Sopenharmony_ci  The precise value also depends on the interface MTU. The interface MTU,
17262306a36Sopenharmony_ci  in turn, may trigger IP fragmentation. In this case, the generated
17362306a36Sopenharmony_ci  UDP-Lite packet is split into several IP packets, of which only the
17462306a36Sopenharmony_ci  first one contains the L4 header.
17562306a36Sopenharmony_ci
17662306a36Sopenharmony_ci  The send buffer size has implications on the checksum coverage length.
17762306a36Sopenharmony_ci  Consider the following example::
17862306a36Sopenharmony_ci
17962306a36Sopenharmony_ci    Payload: 1536 bytes          Send Buffer:     1024 bytes
18062306a36Sopenharmony_ci    MTU:     1500 bytes          Coverage Length:  856 bytes
18162306a36Sopenharmony_ci
18262306a36Sopenharmony_ci  UDP-Lite will ship the 1536 bytes in two separate packets::
18362306a36Sopenharmony_ci
18462306a36Sopenharmony_ci    Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
18562306a36Sopenharmony_ci    Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes
18662306a36Sopenharmony_ci
18762306a36Sopenharmony_ci  The coverage packet covers the UDP-Lite header and 848 bytes of the
18862306a36Sopenharmony_ci  payload in the first packet, the second packet is fully covered. Note
18962306a36Sopenharmony_ci  that for the second packet, the coverage length exceeds the packet
19062306a36Sopenharmony_ci  length. The kernel always re-adjusts the coverage length to the packet
19162306a36Sopenharmony_ci  length in such cases.
19262306a36Sopenharmony_ci
19362306a36Sopenharmony_ci  As an example of what happens when one UDP-Lite packet is split into
19462306a36Sopenharmony_ci  several tiny fragments, consider the following example::
19562306a36Sopenharmony_ci
19662306a36Sopenharmony_ci    Payload: 1024 bytes            Send buffer size: 1024 bytes
19762306a36Sopenharmony_ci    MTU:      300 bytes            Coverage length:   575 bytes
19862306a36Sopenharmony_ci
19962306a36Sopenharmony_ci    +-+-----------+--------------+--------------+--------------+
20062306a36Sopenharmony_ci    |8|    272    |      280     |     280      |     280      |
20162306a36Sopenharmony_ci    +-+-----------+--------------+--------------+--------------+
20262306a36Sopenharmony_ci		280            560            840           1032
20362306a36Sopenharmony_ci					^
20462306a36Sopenharmony_ci    *****checksum coverage*************
20562306a36Sopenharmony_ci
20662306a36Sopenharmony_ci  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
20762306a36Sopenharmony_ci  header). According to the interface MTU, these are split into 4 IP
20862306a36Sopenharmony_ci  packets (280 byte IP payload + 20 byte IP header). The kernel module
20962306a36Sopenharmony_ci  sums the contents of the entire first two packets, plus 15 bytes of
21062306a36Sopenharmony_ci  the last packet before releasing the fragments to the IP module.
21162306a36Sopenharmony_ci
21262306a36Sopenharmony_ci  To see the analogous case for IPv6 fragmentation, consider a link
21362306a36Sopenharmony_ci  MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
21462306a36Sopenharmony_ci  coverage is less than 1232 bytes (MTU minus IPv6/fragment header
21562306a36Sopenharmony_ci  lengths), only the first fragment needs to be considered. When using
21662306a36Sopenharmony_ci  larger checksum coverage lengths, each eligible fragment needs to be
21762306a36Sopenharmony_ci  checksummed. Suppose we have a checksum coverage of 3062. The buffer
21862306a36Sopenharmony_ci  of 3356 bytes will be split into the following fragments::
21962306a36Sopenharmony_ci
22062306a36Sopenharmony_ci    Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
22162306a36Sopenharmony_ci    Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
22262306a36Sopenharmony_ci    Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data
22362306a36Sopenharmony_ci
22462306a36Sopenharmony_ci  The first two fragments have to be checksummed in full, of the last
22562306a36Sopenharmony_ci  fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
22662306a36Sopenharmony_ci
22762306a36Sopenharmony_ci  While it is important that such cases are dealt with correctly, they
22862306a36Sopenharmony_ci  are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
22962306a36Sopenharmony_ci  performance over wireless (or generally noisy) links and thus smaller
23062306a36Sopenharmony_ci  coverage lengths are likely to be expected.
23162306a36Sopenharmony_ci
23262306a36Sopenharmony_ci5. UDP-Lite Runtime Statistics and their Meaning
23362306a36Sopenharmony_ci================================================
23462306a36Sopenharmony_ci
23562306a36Sopenharmony_ci  Exceptional and error conditions are logged to syslog at the KERN_DEBUG
23662306a36Sopenharmony_ci  level.  Live statistics about UDP-Lite are available in /proc/net/snmp
23762306a36Sopenharmony_ci  and can (with newer versions of netstat) be viewed using::
23862306a36Sopenharmony_ci
23962306a36Sopenharmony_ci			    netstat -svu
24062306a36Sopenharmony_ci
24162306a36Sopenharmony_ci  This displays UDP-Lite statistics variables, whose meaning is as follows.
24262306a36Sopenharmony_ci
24362306a36Sopenharmony_ci   ============     =====================================================
24462306a36Sopenharmony_ci   InDatagrams      The total number of datagrams delivered to users.
24562306a36Sopenharmony_ci
24662306a36Sopenharmony_ci   NoPorts          Number of packets received to an unknown port.
24762306a36Sopenharmony_ci		    These cases are counted separately (not as InErrors).
24862306a36Sopenharmony_ci
24962306a36Sopenharmony_ci   InErrors         Number of erroneous UDP-Lite packets. Errors include:
25062306a36Sopenharmony_ci
25162306a36Sopenharmony_ci		      * internal socket queue receive errors
25262306a36Sopenharmony_ci		      * packet too short (less than 8 bytes or stated
25362306a36Sopenharmony_ci			coverage length exceeds received length)
25462306a36Sopenharmony_ci		      * xfrm4_policy_check() returned with error
25562306a36Sopenharmony_ci		      * application has specified larger min. coverage
25662306a36Sopenharmony_ci			length than that of incoming packet
25762306a36Sopenharmony_ci		      * checksum coverage violated
25862306a36Sopenharmony_ci		      * bad checksum
25962306a36Sopenharmony_ci
26062306a36Sopenharmony_ci   OutDatagrams     Total number of sent datagrams.
26162306a36Sopenharmony_ci   ============     =====================================================
26262306a36Sopenharmony_ci
26362306a36Sopenharmony_ci   These statistics derive from the UDP MIB (RFC 2013).
26462306a36Sopenharmony_ci
26562306a36Sopenharmony_ci6. IPtables
26662306a36Sopenharmony_ci===========
26762306a36Sopenharmony_ci
26862306a36Sopenharmony_ci  There is packet match support for UDP-Lite as well as support for the LOG target.
26962306a36Sopenharmony_ci  If you copy and paste the following line into /etc/protocols::
27062306a36Sopenharmony_ci
27162306a36Sopenharmony_ci    udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]
27262306a36Sopenharmony_ci
27362306a36Sopenharmony_ci  then::
27462306a36Sopenharmony_ci
27562306a36Sopenharmony_ci	      iptables -A INPUT -p udplite -j LOG
27662306a36Sopenharmony_ci
27762306a36Sopenharmony_ci  will produce logging output to syslog. Dropping and rejecting packets also works.
27862306a36Sopenharmony_ci
27962306a36Sopenharmony_ci7. Maintainer Address
28062306a36Sopenharmony_ci=====================
28162306a36Sopenharmony_ci
28262306a36Sopenharmony_ci  The UDP-Lite patch was developed at
28362306a36Sopenharmony_ci
28462306a36Sopenharmony_ci		    University of Aberdeen
28562306a36Sopenharmony_ci		    Electronics Research Group
28662306a36Sopenharmony_ci		    Department of Engineering
28762306a36Sopenharmony_ci		    Fraser Noble Building
28862306a36Sopenharmony_ci		    Aberdeen AB24 3UE; UK
28962306a36Sopenharmony_ci
29062306a36Sopenharmony_ci  The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
29162306a36Sopenharmony_ci  code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.
292