## 4 IETF 6 LoWPAN Working Group (IPv6)
### Key Protocols
#### 4.1.2 Header Compression  
One of the services provided by the 6 LoWPAN adaptation layer is header compression. RFC 4944 defines header compression techniques that can be used to compress IPv6 headers and to allow more data from layers on top of IPv6 to be included in a single 802.15.4 frame. The LOWPAN_HC1, the main compression technique specified in RFC 4944, is optimized for compressing IPv6 packets that contain link-local IPv6 addresses. The technique attempts to reduce the size of the packet by removing common fields (Version, TC, Flow label), inferring the IPv6 addresses from the link-layer addresses in the 802.15.4 header and the static IPv6 link-local prefix (fe80::/64), inferring the IP packet length from the layer 2 frame length (or the fragmentation header) and limiting the values of the next header field to TCP, UDP and ICMP. [22]. The RFC also defines HC2 compression for transport layer compression, which allows compressing UDP, TCP and ICMP. Other transport layer protocols cannot be compressed by HC2. HC1 compression has very low compression factors for global and multicast addresses, which are needed for direct host-to-host interactions between constrained devices and clients as envisioned by the Internet of Things, therefore its use is limited and not further detailed here. RFC 6282 specifies two new compression mechanisms named LOWPAN_IPHC and LOWPAN_NHC. According to the RFC, LOWPAN_IPHC, uses 13 bits for compression (the last 5 bits of the dispatch byte and an additional byte) and an extra 8 bits to store context information, when necessary. Figure 5 shows the IPHC header format and Table 2 summarizes the address compression fields. IPHC is based on a number of basic assumptions about common 6 LoWPAN communication cases. The first assumption regards commonly used fields. It is assumed that IPv6 header fields such as Version, Traffic Class and Flow Label have fixed values and do not have to be transmitted. Therefore, IPHC totally ignores the 4 bit version and attempts to compress the Traffic Class and Flow Label into the TF bits (2 bits). By assuming hop limits will be set to well-known values such as 1, 64 and 255 by the host, IPHC compresses the hop limit from 8 bits to 2 bits. Figure 5: IPHC Compression. Assuming that addresses could be generated from link-layer addresses and that mostly link local addresses are used inside LLNs, IPHC attempts to compress the IPv6 address fields. To further improve the efficiency of compression of global and multicast addresses, IPHC uses context information. The _Context ID_ Extension bit (CID) bit indicates whether an additional 8-bit Context Identifier Extension field is added or not. IPHC supports stateless and stateful methods of addresses compression. The _Source Address Compression_ (SAC) and _Destination Address Compression_ (DAC) bits indicate which of these two compression methods is used for the source and destination address, respectively. The _Source Address Mode_ (SAM) bits in combination with the SAC bit determine how many of the source address bits are actually elided and how many bits are sent in-line. The number of bits sent inline can be 128, 64, 16 or 0 bits for stateless compression and 64, 16, or 0 bits for stateful compression. In all cases, the bits that are elided are assumed to be calculated from the link-local prefix, link layer address and stored context. The destination address compression varies based on the address type. Multicast destination addresses are indicated by the M bit in the compression header. Unicast destination addresses are compressed in the same way as unicast source addresses. However, multicast addresses follow a different rule based on the DAC bit. Accordingly, 128, 48, 32, or 8 bits has to be sent inline when multicast destination addresses are compressed. The 8 bit context identifier