Skip to main content

4.3. UDP Header Compression

This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 0 through 4 represent the NHC ID and '11110' indicates the specific UDP header compression encoding defined in this section.

4.3.1. Compressing UDP Ports​

This specification allows a particular range of ports number (0xf0b0 to 0xf0bf) to be compressed down to 4 bits. This is a stateless compression that is inherited from [RFC4944], as opposed to a new stateful compression.

The range of ports compressible down to 4 bits is not in a reserved range. A network stack implementation that is designed to communicate over a 6LoWPAN should avoid using those ports as dynamic ports whenever possible.

Considering that this represents only 16 contiguous ports, it can be expected that many incompatible applications will use the same value of port numbers for their own end-to-end needs. Thus, a port number in the (0xf0b0 to 0xf0bf) range provides very little information about the application at the remote end.

The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that are reserved at IANA. As a result, it is recommended that the use of those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that makes sure that the content is what is expected and is checked.

4.3.2. Compressing UDP Checksum​

The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason, [RFC4944] disallows the compression of the UDP checksum.

With this specification, a compressor in the source transport endpoint MAY elide the UDP Checksum if it is authorized by the upper layer. The compressor MUST NOT set the C bit unless it has received such authorization. Requiring upper-layer authorization ensures that the intended transport peer will have sufficient means to deal with any data corruption that occurs before reaching the destination. The upper layer MUST NOT provide the authorization unless one of the following cases is satisfied:

Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-fieldbus by tunneling existing field protocols over UDP. If the tunneled Protocol Data Unit (PDU) possesses its own addressing, security and integrity check (e.g., IPsec Encapsulating Security Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the tunneling mechanism MAY authorize eliding the UDP checksum in order to save on the encapsulation overhead.

Message Integrity Check: In this case, either IPsec Authentication Header [RFC4302] or some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength.

To help ensure that the UDP Checksum will be properly restored when expanding a 6LoWPAN packet, an additional integrity check (e.g., a Layer 2 (L2) Message Integrity Check) MUST be used whenever transmitting link frames that carry a compressed UDP datagram that elides the checksum. Without this additional integrity check, a UDP packet may be delivered to an unintended destination since corruption in data covered by the pseudo-header can go undetected.

A compressor MUST verify the UDP Checksum before it is elided and MUST ensure that the additional integrity check is in place before verifying and eliding the checksum. If verification of the UDP Checksum fails, the compressor MUST drop the packet.

A decompressor that expands a 6LoWPAN packet with the C bit set MUST compute the UDP Checksum on behalf of the source node and place that value in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously determine that an additional integrity check was put in place by the compressor and verify the integrity check and SHOULD do so after restoring the UDP Checksum. If the decompressor cannot unambiguously determine the presence of an integrity check or verification fails, the decompressor MUST drop the packet.

The recommended ordering of computing and verifying the UDP Checksum and additional integrity check ensures that data is never stored unprotected in memory. In practice, functionality separation between layers may preclude the recommended ordering. However, implementors should take special note and understand the risks when dealing with unprotected data covered by the pseudo-header.

To allow intermediate nodes to compress the UDP Checksum, a forwarding node MAY infer upper-layer authorization for an incoming packet if it has the C bit set and it can unambiguously determine that an integrity check covering the same data as the UDP Checksum was in place while the UDP Checksum was elided. A forwarding node MUST NOT infer authorization if it cannot unambiguously determine the presence of and verify an integrity check while the UDP Checksum was elided.

4.3.3. UDP LOWPAN_NHC Format​

                    0   1   2   3   4   5   6   7
                  +---+---+---+---+---+---+---+---+
                  | 1 | 1 | 1 | 1 | 0 | C |   P   |
                  +---+---+---+---+---+---+---+---+

                   Figure 14: UDP Header Encoding

C: Checksum:

  • 0: All 16 bits of Checksum are carried in-line.
  • 1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it on the 6LoWPAN termination point.

P: Ports:

  • 00: All 16 bits for both Source Port and Destination Port are carried in-line.
  • 01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xf0 and elided. The remaining 8 bits of Destination Port are carried in-line.
  • 10: First 8 bits of Source Port are 0xf0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line.
  • 11: First 12 bits of both Source Port and Destination Port are 0xf0b and elided. The remaining 4 bits for each are carried in-line.

Fields carried in-line (in part or in whole) appear in the same order as they do in the UDP header format [RFC0768]. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.

Last updated on