## 3 Background and Related Works
### HIP DEX Packet's Format Analysis and Proposed Compression
#### 3.4.2 HIP DEX-6 LoWPAN Header's Compressibility  
To apply a 6 LoWPAN header compression in a given protocol, it is required to modify the existing NHC encoding or determine a different NHC for the target protocol with different ID bits. The first proposition enforces modification in the current standard. We judge this solution as not a kind one. The possible second solution, used in this paper, is to propose an extension to the 6 LoWPAN standard such as the approach applicable to distinguish NHC from GHC. Among encoding bits in the IPHC, is the NH bit that, if set, indicates the next header is compressed using NHC. The NHC is used to encode the IPv6 extension headers and the encapsulated header protocol. Generally, the NHC encoding is only one octet and contains variable-length ID bits and the encoding bits for a specific header. Compression possibilities for different next headers are concerned a bit motif that is variable fixed immediately after the LOWPAN_IPHC compressed header. The next header compression format must be defined after determining obligatory by the perceived frequency of using that format. As HIP DEX header will be associated with the 6 LoWPAN header after compression. We can consider that the HIP header is the adaptation of the 6 LoWPAN extension header. Therefore, we propose a 6 LoWPAN Next \begin{table}
\begin{tabular}{l l l} \hline \hline
**HIP DEX Header Field** & \
\begin{tabular}{l} **Length before Compression** \\ **(bits)** \\ \end{tabular} &
\begin{tabular}{l} **Length After Compression** \\ **(bits)** \\ \end{tabular} \\ \hline Next header & 8 & 0 or 8 \\ Header length & 8 & 0 \\ Packet type & 7 & 3 \\ VER. & 4 & 0 \\ RES. & 3 & 0 \\ Fixed bits 0 and 1 & 2 & 0 \\ Checksum & 16 & 0 \\ Controls & 16 & 0 \\ HIT\_I & 128 & 96 \\ HIT\_R & 128 & 0 \\
**Header length** & **40 bytes** & **Min header = 12 bytes, Max** \\  & **header = 13 bytes** \\ \hline \hline \end{tabular}
\end{table} 
Table 2: HIP DEX header fields before and after proposed compression with LC-DEX. uses optional transmission of NOTIFY messages to inform the initiator by the reception of an I2 message. However, the responder can not guarantee the authenticity of this packet as it did not yet set up the Master Key Security Association [16]. So, an attacker can send spoofed reception acknowledgment for an I2 packet and signal an arbitrary I2 processing time to the initiator. For example, indicating lower processing time for I2 messages induces a premature transmission by the responder. Another possible optimization is concerning the CLOSE and CLOSE_ACK messages. The CLOSE message initiates the termination procedure, and the CLOSE_ACK is sent to confirm the termination of the process. When the initiator sends the CLOSE message, it waits for a waiting period until receiving the CLOSE_ACK message. This waiting time is defined as the period that waits for the device if no packet is sent or received (UAL: Unused Association Lifetime). UAL is important for a constrained IoT node because it can not, mainly, be switched to an energy-saving state. Therefore, we have proposed to remove the confirmation message. The authors of [22], also proposed to remove CLOSE_ACK messages (in HIP DEX protocol), but their solution is feasible only if the responder is a powerful network device with high capabilities in terms of memory and computation (They implemented the responder as a laptop computer). As a replacement scheme, we propose to terminate, immediately, the connection, by the initiator, when the CLOSE message is sent to the CTTP (waiting time for the initiator is null). The CTTP is charged to forward the termination message to the responder. We treated the case where the CLOSE message is lost during the transmission. In this situation, the initiator terminates the connection, but it is not the case for the responder that normally waits for a backup time to terminate the connection or retransmission of the lost message. The maximum required time for a TCP segment to be spent in the network is called the MSL (Maximum Segment Lifetime).