## 3 Background and Related Works
### HIP DEX Packet's Format Analysis and Proposed Compression
#### 3.4.1 HIP Header Fix Parameters Compressibility  
In HIP DEX as such in HIPv2, there are eight basic HIP packets. The mandatory ones for the handshake process are (I1, R1, I2, R2). Details on these messages were presented in Section 3.2. The rest of the messages are used for signalization: UPDATE, NOTIFY, CLOSE and, CLOSE_ACK. The fixed HIP header is similar in design to the IPv6 extension header. It starts with the required Next Header and Header Length fields and contains an 8-byte alignment for the HIP DEX packet content. This content is constant for all HIP packets and can be concluded from lower layers by summing the sizes of the frames (e.g., MAC service data units) referring to the same HIP packet, with the elimination of the excluded 8 bytes cited above. Consequently, the header length byte can be compressed. As such, the specific part of the HIP header begins with information that is necessary for the correct analysis of a packet, that is, the packet type and the protocol version. As there are eight packet types in HIP DEX, five bits are sufficient for coding the packet type field rather than seven bits according to the proposition in [32]. In our solution, we proposed to remove both NOTIFY and CLOSE_ACK messages. So, the total number of exchanged HIP messages becomes six, and only _three bits are sufficient for coding the packet type field_. The HIP Version field (VER). is four bits, and there was not defined version for HIP DEX separately from HIP BEX. So, currently, the existing version is 2 for HIP BEX and consequently the same for DEX. There are two possibilities: (1) the two communicating sensor nodes use the same version; (2) different versions are executed in the HIP peers and if it is the case we may assume that the 6 LoWPAN bridge router (6 BR) is charged by the adaptation for the incoming packets from the Internet. In our work, we suppose that the communicating peers use the same version. The _version field_ maybe, as a consequence, compressed for the generating packets from the sensor nodes and carried unchanged for those coming from outside the network. Additionally, the following three bits are _reserved (RES. )_ for future use and set to zero, that is why they can be eliminated. Thus, the checksum is covering the source and destination addresses in the IP header, it MUST be recomputed on HIP-aware NAT devices. So, the 6 LoWPAN packets sustaining HIP packets will be fragmented in the 6 LoWPAN layer and specifically in the 6 BR. So, keeping the original checksum value will be useless. Consequently, we can remove the _checksum_ field from the HIP header in the WSN board. R1 and I2 packets contain one bit (A-bit) that is set when the Responder's or Initiator's HIT, is anonymous, respectively, and if it should be stored or not by the peer. The management of anonymous nodes must be removed in the context of constrained networks such as an IoT based-WSNs. _A-bit_ is a part of the controls bit array (16 bits) that we, accordingly, revoke safely. In the same context, _HIT_R_ as redundant information can even be completely revoked in both R1 and I2 messages which reach the source host identifier information. The two _fixed bits_ 0 and 1 in the header are used for compatibility issues and must be set only in implementations referring to particular specifications and so, they can be eliminated. Another important target for compression in the header is the HIT_I field that has the heavy length of the header (128 bits). As we proposed to revoke the HIT_R [9], we focus at this stage only on the HIT_R. HIT is a precision representation of the Host Identifier and that is similar in structure to IPv6 addresses. HITs are composed of three components: (a) an IANA fixed 28-bits prefix used to differentiate HITs from standard IPv6 addresses; (b) a code identifier to indicate the compression algorithm used to generate HIT from HI (4 bits); and (c) left-truncation of the HI to 96 bits as a representation of HIT from HI (compression of HI).