Deployed Modules

Header Compression and Packet Handling

In order to enable and provide packet filtering solutions, the IPv6 packet must be previously retrieved from the MAC Data frame payload. Therefore, when an IEEE 802.15.4 Data frame is stored in the IEEE 802.15.4 Frame Buffer, it is automatically decompressed into an IPv6 packet and all the fields set available to the OS and the filtering modules. The decompression mechanisms are based on the algorithm explained previously in Section 5.2.2.

Address Filtering

The 6LoWPAN packet filter is composed by a source and destination address filter modules. Both can be configured with a desired number of IPv6 addresses to be compared with the received packet. If the received packet matches any of the

con-figured addresses (e.g., Link-Local and Global addresses), an output for the network accelerator interface module is triggered. For vital network protocols, e.g., mDNS, RPL routing messages, and ICMPv6 messages, the 6LoWPAN modules will always flag a valid packet. This way, the network nodes can keep up-to-date information about the network topology while maintaining the network integrity. For handling the IPHC mechanisms of the IPv6 protocol, these modules are able to retrieve all the existing fields and calculate the IPv6 addresses, when compressed, from the cor-responding MAC Addressing fields. Offloading this task from the OS alleviates the overhead caused by the heavy processing of the 6LoWPAN headers.

TCP/UDP Filter

When the received packet contains a UDP/TCP payload, this module verifies the local and remote ports. When combined with the previous modules it turns the network accelerator into a powerful IPv6 UDP/TCP filter that is able to discard packets if there are no bind connections with the node’s IP address. If the configured socket is listening on different ports than the received on the UDP/TCP packet fields, the packet is discarded. When the node is configured as a router, the module can still forward the packet to the OS in order to generate an ICMPv6 "Destination Unreachable Message" to notify the sender. This can be disabled if port scan probes are undesired.

Other 6LoWPAN modules in development

There are other crucial features that are required by the 6LoWPAN in order to main-tain the IPv6 network working in a more efficient way. Besides compressing the IPv6 addresses in an efficient manner, the LOWPAN_IPHC also introduces an extension that is used to identify IPv6 Global Addresses that are commonly used in the network, e.g., a remote server address. Thus, the addresses have not to be carried in-line every time a message is exchanged between a node and the remote server. For that purpose, the LOWPAN_IPHC introduces the Context IDentifier (CID) Extension that expects a conceptual context is shared between the node that compresses a packet and the node(s) that needs to expand it. However, how the contexts are shared and maintained is out of the scope of the standard specification [181]. The specification enables a node to use up to 16 contexts and the context used to encode the source address has not to be the same as the context used to encode the destination ad-dress. If the CID field is set to 1 in the LOWPAN_IPHC encoding, then an additional

octet will extend the LOWPAN_IPHC encoding following the DAM bits, but before the IPv6 header fields that are carried in-line. The additional octet identifies the pair of contexts to be used when the IPv6 source and/or destination address is compressed.

The context identifier reserves 4 bits for each address type, supporting up to 16 contexts, where context 0 is the default context. A Context Table (CT) maps the most frequent Internet address prefixes to context identifiers of several bits, which are used in the packets generated by the border router. The CT design and how the tables are maintained are not specified. However, few approaches to dynamically update each CT, and how the information is disseminated over the network have been proposed by [185,186]. Since the dynamic algorithm applied is heavy, and with the increased number of global host that might need to communicate with the nodes inside the 6LoWPAN network, it is also proposed the addition of a module to the 6LoWPAN accelerator in order to handle these tables and how the information is disseminated. Such task, in the Contiki-OS, is being under evaluation and proposed to be offloaded.

5.3.3 Peripheral Interface

After deploying the 6LA on the RCU, and since it shares the same memory space with the MAC accelerator, it was necessary to update the peripheral interface created in Section 4.3.3 from Chapter 4. The update concerns the registers FILTER_REG, CMD_1_REG and CMD_1_REG bit fields on the core_accelerator_regs.h file. Regarding the FILTER_REG, Figure 5.5, the reserved bit fields were updated as follows:

Reserv

Figure 5.5: FILTER_REG register field.

SRC_IP, DST_IP and enables/disables, respectively, the filtering functionalities of source/destination IPv6 addresses (can be Local-Link, Global, etc.), and UDP_-IP adds the functionality to additionally filter the packet by the UDP remote/lo-cal) ports in use. Regarding the CMD_1_REG register, Figure 5.6, the reserved bit

fields are now used as follows: SRCUDP_PCKT, DSTUDP_PCKT, SRCIP6_PCKT_MASK and DSTIP6_PCKT_MASK are used to request the number of filtered packets for source and destination UDP ports and source and destination IPv6 addresses, respectively.

SR

Figure 5.6: CMD_1_REG register field.

For the CMD_2_REG register, Figure 5.7, there were added new bit fields as follows:

WR_UDP_PORTS_MASK is used to set a new pair of local/remote ports to be added to the filter. New ports were added to the BUFF_0_REG, BUFF_1_REG, BUFF_2_REG and BUFF_3_REG, to be next added to the list of remote/local ports. The same procedure is used to add source and destination IPv6 addresses. Because the IPv6 uses 16 octets, the transfer occurs in two steps, first the network prefix is set by asserting the WR_SRCIP6_PREFIX_MASK bit and followed by the 64-bit IPv6 address when the WR_DSTIP6_ADDR_MASK bit is set. Listing 5.1 summarizes the file with the performed updates.

Figure 5.7: CMD_2_REG register field.

Listing 5.1: Updated core_accelerator_regs.h file.

6 #define SRC_IP6_MASK 0x10u //enable src IPv6 address filtering

7 #define DST_IP6_MASK 0x20u //enable dst IPv6 address filtering

8 #define UDP_PORTS_MASK 0x40u //enable UDP remote/local filtering

9

10 /* Command 1 Register */

11 #define CMD1_REG_OFFSET 0x30u

12 ...

13 #define SRCUDP_PCKT_MASK 0x05u //filtered src udp packets

14 #define DSTUDP_PCKT_MASK 0x06u //filtered dst udp packets

15 #define DSTIP6_PCKT_MASK 0x07u //filtered dst ipv6 packets

16 #define SRCIP6_PCKT_MASK 0x08u //filtered src ipv6 packets

17

18 /* Command 2 Register */

19 #define CMD2_REG_OFFSET 0x34u

20 ...

21 #define WR_UDP_PORTS_MASK 0x04u //write udp ports

22 #define WR_SRCIP6_PREFIX_MASK 0x05u //write src ipv6 prefix

23 #define WR_SRCIP6_ADDR_MASK 0x06u //write dst ipv6 address

24 #define WR_DSTIP6_PREFIX_MASK 0x07u //write src ipv6 prefix

25 #define WR_DSTIP6_ADDR_MASK 0x08u //write dst ipv6 address

26 ...