2017-06-30 23:32:17 +08:00
|
|
|
|
6LoWPAN Contents
|
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
|
|
o 6LoWPAN Addressing
|
|
|
|
|
|
o IPv6 Neighbor Discovery
|
|
|
|
|
|
o Optimal 6LoWPAN Configuration
|
|
|
|
|
|
o Star Configuration
|
|
|
|
|
|
|
2017-06-18 23:01:18 +08:00
|
|
|
|
6LoWPAN Addressing
|
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
|
|
The current 6LoWPAN implementation uses only link local, MAC-based
|
|
|
|
|
|
addressing addressing (as discussed in more detail below). Thus if you know
|
2017-06-19 21:31:52 +08:00
|
|
|
|
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
|
|
|
|
|
|
-----------------------
|
2017-06-18 23:01:18 +08:00
|
|
|
|
|
|
|
|
|
|
IPv6 Neighbor Discovery is not supported. The current ICMPv6 and neighbor-
|
2017-06-19 21:31:52 +08:00
|
|
|
|
related logic only works with Ethernet MAC. For 6LoWPAN, a new more
|
2020-02-23 16:50:23 +08:00
|
|
|
|
conservative IPv6 neighbor discovery is provided by RFC 6775 which is not
|
2017-06-19 21:31:52 +08:00
|
|
|
|
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.
|
2017-06-18 23:01:18 +08:00
|
|
|
|
|
|
|
|
|
|
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
|
2017-04-09 00:18:44 +08:00
|
|
|
|
-----------------------------
|
2017-04-08 21:30:20 +08:00
|
|
|
|
|
|
|
|
|
|
1. Link local IP addresses:
|
|
|
|
|
|
|
|
|
|
|
|
128 112 96 80 64 48 32 16
|
|
|
|
|
|
fe80 0000 0000 0000 xxxx xxxx xxxx xxxx
|
|
|
|
|
|
|
|
|
|
|
|
2. MAC-based IP addresses:
|
|
|
|
|
|
|
|
|
|
|
|
128 112 96 80 64 48 32 16
|
|
|
|
|
|
---- ---- ---- ---- ---- ---- ---- ----
|
2017-05-04 23:05:41 +08:00
|
|
|
|
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
|
2017-04-08 21:30:20 +08:00
|
|
|
|
|
2017-05-04 23:05:41 +08:00
|
|
|
|
Where MMM is the 2-byte short address XORed 0x0200. For example, the MAC
|
2017-04-08 21:30:20 +08:00
|
|
|
|
address of 0xabcd would be 0xa9cd. And NNNN NNNN NNNN NNNN is the 8-byte
|
2017-05-04 23:05:41 +08:00
|
|
|
|
extended address address XOR 02000 0000 0000 0000.
|
2017-04-24 23:42:51 +08:00
|
|
|
|
|
|
|
|
|
|
For link-local address, AAAA is 0xfe80
|
2017-04-08 21:30:20 +08:00
|
|
|
|
|
|
|
|
|
|
3. MAC based link-local addresses
|
|
|
|
|
|
|
|
|
|
|
|
128 112 96 80 64 48 32 16
|
|
|
|
|
|
---- ---- ---- ---- ---- ---- ---- ----
|
2017-05-04 23:05:41 +08:00
|
|
|
|
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
|
2017-04-08 21:30:20 +08:00
|
|
|
|
|
2020-02-23 16:50:23 +08:00
|
|
|
|
4. To be compressible, port numbers must be in the range 0xf0b0-0xf0bf,
|
2017-06-21 00:37:32 +08:00
|
|
|
|
hexadecimal. That is 61616-61631 decimal.
|
2017-04-08 21:30:20 +08:00
|
|
|
|
|
2017-09-11 01:40:54 +08:00
|
|
|
|
5. 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
|
2018-07-05 04:10:40 +08:00
|
|
|
|
(CONFIG_NET_6LOWPAN_PKTSIZE, default 1294, plus per frame overhead).
|
2017-04-09 00:18:44 +08:00
|
|
|
|
|
|
|
|
|
|
Fragmentation Headers
|
|
|
|
|
|
---------------------
|
2017-04-17 02:18:42 +08:00
|
|
|
|
A fragment header is placed at the beginning of the outgoing packet just
|
2017-04-24 23:42:51 +08:00
|
|
|
|
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.
|
2017-04-09 00:18:44 +08:00
|
|
|
|
|
|
|
|
|
|
1. Datagram size describes the total (un-fragmented) payload.
|
|
|
|
|
|
2. Datagram tag identifies the set of fragments and is used to match
|
|
|
|
|
|
fragments of the same payload.
|
|
|
|
|
|
3. 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
|
|
|
|
|
|
|
2017-04-29 22:23:59 +08:00
|
|
|
|
41 88 2a cefa 3412 cdab ### 9-byte MAC header
|
2017-04-17 02:18:42 +08:00
|
|
|
|
c50e 000b ### 4-byte FRAG1 header
|
|
|
|
|
|
42 ### SIXLOWPAN_DISPATCH_HC1
|
2017-05-04 23:05:41 +08:00
|
|
|
|
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
|
2017-04-17 02:18:42 +08:00
|
|
|
|
|
2017-04-20 03:33:20 +08:00
|
|
|
|
104 byte Payload follows:
|
2017-04-17 02:18:42 +08:00
|
|
|
|
4f4e452064617920 48656e6e792d7065 6e6e792077617320 7069636b696e6720
|
2017-04-09 00:18:44 +08:00
|
|
|
|
757020636f726e20 696e207468652063 6f726e7961726420 7768656e2d2d7768
|
2017-04-20 03:33:20 +08:00
|
|
|
|
61636b212d2d736f 6d657468696e6720 6869742068657220 75706f6e20746865
|
|
|
|
|
|
20686561642e2027
|
2017-04-09 00:18:44 +08:00
|
|
|
|
|
|
|
|
|
|
This is the second frame of the same transfer:
|
|
|
|
|
|
|
2017-04-29 22:23:59 +08:00
|
|
|
|
41 88 2b cefa 3412 cdab ### 9-byte MAC header
|
2017-04-24 23:42:51 +08:00
|
|
|
|
e50e 000b 0d ### 5 byte FRAGN header
|
2017-04-17 02:18:42 +08:00
|
|
|
|
42 ### SIXLOWPAN_DISPATCH_HC1
|
2017-05-04 23:05:41 +08:00
|
|
|
|
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
|
2017-04-17 02:18:42 +08:00
|
|
|
|
|
2017-04-20 03:33:20 +08:00
|
|
|
|
104 byte Payload follows:
|
|
|
|
|
|
476f6f646e657373 2067726163696f75 73206d6521272073 6169642048656e6e
|
|
|
|
|
|
792d70656e6e793b 202774686520736b 79277320612d676f 696e6720746f2066
|
|
|
|
|
|
616c6c3b2049206d 75737420676f2061 6e642074656c6c20 746865206b696e67
|
|
|
|
|
|
2e270a0a536f2073
|
2017-04-09 00:18:44 +08:00
|
|
|
|
|
|
|
|
|
|
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
|
2017-04-24 23:42:51 +08:00
|
|
|
|
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.
|
2017-06-30 23:32:17 +08:00
|
|
|
|
|
|
|
|
|
|
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
|
2019-09-20 08:19:18 +08:00
|
|
|
|
recipient. The star hub is assumed to be the coordinator.
|
2017-06-30 23:32:17 +08:00
|
|
|
|
|
|
|
|
|
|
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.
|
