| ======= |
| 6LoWPAN |
| ======= |
| |
| 6LoWPAN Addressing |
| ------------------ |
| |
| The current 6LoWPAN implementation uses only link local, MAC-based |
| addressing addressing (as discussed in more detail below). Thus if you know |
| the node addressing, then you know the IPv6 address (and vice-versa). |
| |
| As a configuration option, the 6LoWPAN implementation will use either the |
| node's 2-byte short address or 8-byte extended address as the MAC address |
| that the IPv6 address is based on. This is determined by the configuration |
| setting ``CONFIG_NET_6LOWPAN_EXTENDEDADDR``. By default, the 2-byte short |
| address is used for the IEEE802.15.4 MAC device's link layer address. If |
| this option is selected, then an 8-byte extended address will be used, |
| instead. |
| |
| All nodes operating on a network have unique, 8-byte extended address, |
| that was assigned before the network is configured. 6LoWPAN will use |
| either the extended address for direct communication within the PAN or |
| the short 2-byte address. The short 2-byte address, however, is allocated |
| by the PAN coordinator when the device associated. If short addresses are |
| used, the network cannot be brought up until is is associated. |
| |
| Node addressing is modified through IOCTL calls from application logic. |
| The network must be in the DOWN state when ever the node addressing is |
| modified. The modified node addresses will have no effect on the reported |
| IPv6 address until the network is brought to the UP state. The new IPv6 |
| MAC-based addresses are only instantiated when the network transitions |
| from the DOWN to UP state. |
| |
| IPv6 Neighbor Discovery |
| ----------------------- |
| |
| IPv6 Neighbor Discovery is not supported. The current ICMPv6 and neighbor- |
| related logic only works with Ethernet MAC. For 6LoWPAN, a new more |
| conservative IPv6 neighbor discovery is provided by RFC 6775 which is not |
| currently supported. With IPv6 neighbor discovery, any IPv6 address may be |
| associated with any short or extended address. In fact, that is the whole |
| purpose of the neighbor discover logic: It plays the same role as ARP in |
| IPv4; it ultimately just manages a neighbor table that, like the arp table, |
| provides the mapping between IP addresses and node addresses. |
| |
| The NuttX, Contiki-based 6LoWPAN implementation circumvents the need for |
| the neighbor discovery logic by using only MAC-based addressing, i.e., the |
| lower two or eight bytes of the IP address are the node address. |
| |
| Most of the 6LoWPAN compression algorithms exploit this kind of addressing |
| to compress the IPv6 address to nothing but a single bit indicating that the |
| IP address derives from the node address. In this use case, IPv6 neighbor |
| discover is not useful: If we want to use IPv6 neighbor discovery, we could |
| dispense with the all MAC based addressing. But if we want to retain the |
| more compact MAC-based addressing, then we don't need IPv6 neighbor discovery. |
| |
| However, it would still be nice to have enough in place to support ping6. |
| Full neighbor support would be necessary if we wanted to route 6LoWPAN frames |
| outside of the WPAN. |
| |
| Optimal 6LoWPAN Configuration |
| ----------------------------- |
| |
| #. Link local IP addresses:: |
| |
| 128 112 96 80 64 48 32 16 |
| fe80 0000 0000 0000 xxxx xxxx xxxx xxxx |
| |
| #. MAC-based IP addresses:: |
| |
| 128 112 96 80 64 48 32 16 |
| ---- ---- ---- ---- ---- ---- ---- ---- |
| AAAA xxxx xxxx xxxx xxxx 00ff fe00 MMMM 2-byte short address IEEE 48-bit MAC |
| AAAA 0000 0000 0000 NNNN NNNN NNNN NNNN 8-byte extended address IEEE EUI-64 |
| |
| Where MMM is the 2-byte short address XORed 0x0200. For example, the MAC |
| address of 0xabcd would be 0xa9cd. And NNNN NNNN NNNN NNNN is the 8-byte |
| extended address address XOR 02000 0000 0000 0000. |
| |
| For link-local address, AAAA is 0xfe80 |
| |
| #. MAC based link-local addresses:: |
| |
| 128 112 96 80 64 48 32 16 |
| ---- ---- ---- ---- ---- ---- ---- ---- |
| fe80 0000 0000 0000 0000 00ff fe00 MMMM 2-byte short address IEEE 48-bit MAC |
| fe80 0000 0000 0000 NNNN NNNN NNNN NNNN 8-byte extended address IEEE EUI-64 |
| |
| #. To be compressible, port numbers must be in the range 0xf0b0-0xf0bf, |
| hexadecimal. That is 61616-61631 decimal. |
| |
| #. IOBs: Must be big enough to hold one IEEE802.15.4 frame (typically 127). |
| There must be enough IOBs to decompose the largest IPv6 packet |
| (``CONFIG_NET_6LOWPAN_PKTSIZE``, default 1294, plus per frame overhead). |
| |
| Fragmentation Headers |
| --------------------- |
| |
| A fragment header is placed at the beginning of the outgoing packet just |
| after the MAC header when the payload is too large to fit in a single IEEE |
| 802.15.4 frame. The fragment header contains three fields: Datagram size, |
| datagram tag and datagram offset. |
| |
| #. Datagram size describes the total (un-fragmented) payload. |
| #. Datagram tag identifies the set of fragments and is used to match |
| fragments of the same payload. |
| #. Datagram offset identifies the fragment’s offset within the un- |
| fragmented payload (in units of 8 bytes). |
| |
| The length of the fragment header length is four bytes for the first header |
| (FRAG1) and five bytes for all subsequent headers (FRAGN). For example, |
| this is a HC1 compressed first frame of a packet:: |
| |
| 41 88 2a cefa 3412 cdab ### 9-byte MAC header |
| c50e 000b ### 4-byte FRAG1 header |
| 42 ### SIXLOWPAN_DISPATCH_HC1 |
| fb ### SIXLOWPAN_HC1_HC_UDP_HC1_ENCODING |
| e0 ### SIXLOWPAN_HC1_HC_UDP_UDP_ENCODING |
| 00 ### SIXLOWPAN_HC1_HC_UDP_TTL |
| 10 ### SIXLOWPAN_HC1_HC_UDP_PORTS |
| 0000 ### SIXLOWPAN_HC1_HC_UDP_CHKSUM |
| |
| 104 byte Payload follows: |
| 4f4e452064617920 48656e6e792d7065 6e6e792077617320 7069636b696e6720 |
| 757020636f726e20 696e207468652063 6f726e7961726420 7768656e2d2d7768 |
| 61636b212d2d736f 6d657468696e6720 6869742068657220 75706f6e20746865 |
| 20686561642e2027 |
| |
| This is the second frame of the same transfer:: |
| |
| 41 88 2b cefa 3412 cdab ### 9-byte MAC header |
| e50e 000b 0d ### 5 byte FRAGN header |
| 42 ### SIXLOWPAN_DISPATCH_HC1 |
| fb ### SIXLOWPAN_HC1_HC_UDP_HC1_ENCODING |
| e0 ### SIXLOWPAN_HC1_HC_UDP_UDP_ENCODING |
| 00 ### SIXLOWPAN_HC1_HC_UDP_TTL |
| 10 ### SIXLOWPAN_HC1_HC_UDP_PORTS |
| 0000 ### SIXLOWPAN_HC1_HC_UDP_CHKSUM |
| |
| 104 byte Payload follows: |
| 476f6f646e657373 2067726163696f75 73206d6521272073 6169642048656e6e |
| 792d70656e6e793b 202774686520736b 79277320612d676f 696e6720746f2066 |
| 616c6c3b2049206d 75737420676f2061 6e642074656c6c20 746865206b696e67 |
| 2e270a0a536f2073 |
| |
| The payload length is encoded in the LS 11-bits of the first 16-bit value: |
| In this example the payload size is 0x050e or 1,294. The tag is 0x000b. In |
| the second frame, the fifth byte contains the offset 0x0d which is 13 << 3 = |
| 104 bytes, the size of the payload on the first packet. |
| |
| Star Configuration |
| ------------------ |
| |
| The 6LoWPAN stack can be specially configured as member in a star topology; |
| either as a endpoint on the star os the star hub. The endpoint is |
| created with the following settings in the configuration file:: |
| |
| CONFIG_NET_STAR=y |
| CONFIG_NET_STARPOINT=y |
| |
| The ``CONFIG_NET_STARPOINT`` selection informs the endpoint 6LoWPAN stack that |
| it must send all frames to the hub of the star, rather than directly to the |
| recipient. The star hub is assumed to be the coordinator. |
| |
| The star hub configuration, on the other hand, uses these setting:: |
| |
| CONFIG_NET_STAR=y |
| CONFIG_NET_STARHUB=y |
| CONFIG_NET_IPFORWARD=y |
| |
| The ``CONFIG_NET_IPFORWARD`` selection informs the hub that if it receives any |
| packets that are not destined for the hub, it should forward those packets |
| appropriately. This affects the behavior of IPv6 packet reception logic but |
| does not change the behavior of the 6LoWPAN stack. |
