## 4 IETF 6 LoWPAN Working Group (IPv6)
### Key Protocols
#### 4.1.2 Header Compression
\begin{table}
\begin{tabular}{l l} \hline \hline
**Field** & **Description** \\ \hline
**Context ID Extension (CID) (1 bit)** & 0 = No Additional Context Identifier Extension is used. \\  & 1 = An additional 8-bit field follows the DAM field \\
**Source Address Compression (SAC)** & 0 = Stateless source/destination address compression \\
**(1 bit)** & 1 = Stateful, context based source/destination address \\
**Dest. Address Compression (DAC)** & compression \\
**(1 bit)** & \\ \hline
**Source Address Mode (SAM)** & 00 = The full 128 bits address is sent inline \\
**If SAC = 0** & 01 = The last 64 bits are sent inline \\  & 10 = The last 16 bits are sent inline. \\  & 11 = The entire source address is elided \\
**If SAC = 1** & 00 = The unspecified address, \(\therefore\). Nothing is sent inline \\  & 01 = 64 bits are carried inline \\  & 10 = 16 bits are carried inline \\  & 11 = The address is fully elided \\ \hline
**Multicast Compression (M)** & 0 = Destination address is not a multicast address \\  & 1 = Destination address is a multicast address \\ \hline
**Destination Address Mode (DAM)** & Same as SAM with SAC = 0 \\
**If M = 0 and DAC=0** & Same as SAM with SAC = 1 \\
**If M = 1 and DAC = 0** & 00 = The full address is sent inline \\  & 01 = Only 48 bits are sent inline \\  & 10 = Only 32 bits are sent inline \\  & 11 = Only 8 bits are sent inline \\
**If M = 1 and DAC = 1** & 00 = Only 48 bit s are sent inline. \\  & 01,10,11 = Reserved \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Summary of Dispatch Byte values. is added only if the SAC and/or DAC bits indicate its presence. If it exists, the first 4 bits indicate store context for the source address while the remaining bits store destination address context. The RFC does not specify what is stored in these fields nor how communicating parties exchange this information. The IPv6 Payload Length field can be inferred from the fragment header or from the link layer header and has to be fully elided. As was already mentioned HC2 can only compress UDP, TCP and ICMPv6 headers. To alleviate this issue LOWPAN_NHC introduces a variable length next header identifier which could be used for future next header compressions. Figure 6 illustrates the IPHC header compression when link-local, global and multicast IPv6 addresses are used for communication. In case I, since both source and destination IP addresses are link-local unicast addresses, the prefix is fixed (_i.e._, fe80::/64) and the suffix can be inferred from the IEEE 802.15.4 source and destination addresses. As shown in the figure, the entire IPv6/UDP header can be compressed from 48 bytes to just 6 bytes. The second case illustrates IPHC compression when the destination IP address is a multicast address. Here the IPv6/UDP header is compressed to 7 bytes by sending only the multicast group inline and deriving all other information from the IEEE 802.15.4 header. Cases III and IV are typical to IoT interactions where both source and destination IP addresses are global unicast addresses. In case III, the source suffix can be derived from the IEEE 802.15.4 source address and, hence, does not have to be sent in-line. The destination suffix however cannot be derived from the IEEE 802.15.4 destination address and has to be sent uncompressed. In case IV, the suffixes of both source and destination addresses cannot be derived and have to be sent inline. In cases III and IV, the IPv6 address prefixes and other information is derived based on the shared context information that is stored in the  
Figure 6: Internet Protocol Version 6 (IPv6) Header Compression Example. Context Identifier Extension_ (CIE) byte. In case 3 and case 4, the IPv6/UDP headers are compressed from 48 bytes to 10 and 12 bytes respectively.