IPv6 in IoT Network Information Center Institute of Network Technology BUPT Website: niclab.bupt.edu.cn E-mail: huangxh@bupt.edu.cn
Catalogue Introduction of ICMPv6 Standards in IoT related to IPv6 Introduction of 6LoWPAN Status and trends of 6LoWPAN deployment
Data packet of ICMPv6 The Next Header field of IPv6 header configured as 58 Two classes of message: Error messages Informational messages New function: Neighbor discovery Stateless configuration Type Description 1 Destination Unreachable 2 Packet Too Big 3 Time Exceeded 4 Parameter Problem 128 Echo Request 129 Echo Reply 130 Group Membership Query 131 Group Membership Report 132 Group Membership Reduction 133 Router Solicitation 134 Router Advertisement 135 Neighbor Solicitation 136 Neighbor Advertisement 137 Redirect Error messages Ping Group membership Neighbor discovery
Types of ICMPv6 in the neighbor discover protocols Mechanism Type 133 (RS) Router Solicitation Type 134 (RA) Router Advertisement Type 135 (NS) Neighbor Solicitation Type 136 (NA) Neighbor Advertisement Type 137 Redirect Substitute ARP Prefix Advertisement Prefix Readdressing DAD Router Redirect RFC4861
Function Display of Substitution ARP ARP Table:? Source MAC 00:50:3e:e4:4c:00 Destination MAC? Source IP FEC0::1:0:0:1:A Destination IP FEC0::1:0:0:1:B Data FEC0::1:0:0:1:A 00:50:3e:e4:4c:00 FEC0::1:0:0:1:B 00:50:3e:e4:4b:01 A B C
Stateless Autoconfiguration Related Mechanisms about IPv6 RFC 1971 Allows a host to configure his/her address without ever registering or authenticating hiself/herself with the local site. DAD to ensure that all configured addresses are likely to be unique on a given link. Prefix Advertisement advertise a prefix and parameters on the local link, the advertised information is used by the node to configure its IPv6 address. Prefix Update advertise a modified or a new prefix and parameters on the local link, update a previously advertised prefix A router cannot use the Stateless Autoconfiguration to configure a IPv6 address to its interface. Stateless Autoconfiguration is only designed for nodes!
Steps of Stateless Autoconfiguration IPv6 Stateless Autoconfiguration The node must configure the link-local address. (e.g., IEEE EUI-64 address) The unique of the link-local address must be validated. ( Duplicate Address Detection ) A node must determine the required configuration information. (The configuration information may be the IP address of the node, or any other configuration information, or both. If the IP address is required, the node must decide the mechanism to obtain the IP address, stateless or stateful.)
DAD(Duplicate Address Detection) 1. Host A starts to configure the temporary address on the interface FEC0::1:0:0:1:A 2. Host A sends a Neighbor Solicitation, sets (::) as the source address, and uses the Solicited-Node Address (FF02::1:FF01:000A) of FEC0::1:0:0:1:A as the destination address. 3. If there is a response, it means the temporary address has been used and then has been changed. Otherwise, it means the temporary address is unique and can be used. Source IPv6 :: Destination IPv6 FF02::1:FF01:A ICMPv6 Type 135 DATA FEC0::1:0:0:1:A Ok,this address is mine This address is using by me, Change another one FEC0::1:0:0:1:B FEC0::1:0:0:1:A A B C
Prefix Advertisement 1. The host multicasts Router Solicitation for obtaining the prefix of the local network. 2. The router will response a Routing Advertisement (Router Advertisement Prefix) 3. The host obtain the prefix 3FFE:0:0:1 4. The address of the host is prefix+id, e.g., 3FFE:0:0:1:0:0:1:A Source IPv6 FE80::250:3EFF:FEE4:4C00 FEC0::1:0:0:1:A new address: I am the router, IPv6 routers are the only kind of devices Great, that with 3FFE:0:0:1:0:0:1:A the are prefix, allowed Is there any routers to to advertise the prefixes a on is coming the I local got a new link. address. The nodes Destination IPv6 ICMPv6 ICMPv6 tell me the prefix? are forbidden to advertise the prefixes. The length of Prefix the prefix is 64bits. FF02::2(All FF02::1(All routers) nodes) Type Type 134(Router 133(Router DATA Advertisement) Solicitation) 3FFE:0:0:1/64 link-local address of the router: FE80::250:3EFF:FEE4:4C00 Prefix= 3FFE:0:0:1/64 After DAD: FEC0::1:0:0:1:A
Catalogue Introduction of ICMPv6 Standards in IoT related to IPv6 Introduction of 6LoWPAN Status and trends of 6LoWPAN deployment
IETF http://www.ietf.org 6LoWPAN Working Group( IPv6 over Low-power and Lossy Networks,Closed):discuss how to adapt the IPv6 protocol to the IEEE 802.15.4 MAC layer and PHY layer protocol stack RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals (Informational) RFC 4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks (Proposed Standard) / Updated by RFC6282, RFC6775 RFC 6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4- Based Networks (Proposed Standard) RFC 6568: Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (Informational) RFC 6606: Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing (Informational) RFC 6775: Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (Proposed Standard)
IETF http://www.ietf.org ROLL Working Group(Routing Over Low Power and Lossy Networks):It mainly discusses routing protocols in low-power networks, and defines routing requirements for various scenarios and RPL (Routing Protocol for LLN) routing protocols for sensor networks. RFC 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (Proposed Standard) RFC 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (Proposed Standard) RFC 6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (Proposed Standard) RFC 6719 The Minimum Rank with Hysteresis Objective Function (Proposed Standard)
IETF http://www.ietf.org CoRE Working Group (Constrained Restful Environment):discuss information read and control issues in a resource-constrained network environment, aiming to develop a lightweight application layer protocol (Constrained Application Protocol,CoAP) RFC 6690 Constrained RESTful Environments (CoRE) Link Format RFC 7252 The Constrained Application Protocol (CoAP)
IPSO Alliance http://www.ipso-alliance.org/ IPSO Alliance(IP Smart Object Alliance)is an industry alliance that promotes the lightweight IPv6 protocolrelated applications developed by the IETF. IPSO is mainly based on the technical standards formulated by the IETF to promote application and industry development, interoperability testing, qualification certification, etc., and is the main promoter of IETF Internet of Things technology. Whitebook:Why IP; Lightweight OS; 6LoWPAN; Security Introduction; Low Power Link Layer; IP in Commercial Buildings; RPL; Benefits of IP in Commercial Buildings
Zigbee Alliance http://www.zigbee.org Industry alliance corresponding to IEEE 802.15.4 organization Smart Energy 2.0 application of Zigbee's Smart Power will also adopt the adaptation layer developed by IETF 6LoWPAN, while supporting 6LoWPAN as a mandatory option. At the application layer, the new specification also supports the lightweight COAP protocol. Zigbee has established an IP-stack working group internally to develop the ZigBee IP Specification for the IPv6 protocol.
ISA https://www.isa.org ISA100.11a One of the international standards for industrial wireless sensor networks. Based on IEEE 802.15.4, but only using its 2.4GHz ISM band (sub-1ghz band is not applicable) Including industrial wireless network architecture, coexistence, robustness, interoperability with wired field networks
Catalogue Introduction of ICMPv6 Standards in IoT related to IPv6 Introduction of 6LoWPAN Status and trends of 6LoWPAN deployment
The difficulties in supporting for IPv6 on IEEE 802.15.4 Large IPv6 header TCP header IPv6 header 20+40 字节 >1280 Bytes IPv6 header:40 bytes TCP header: 20 bytes UDP header or ICMP header: 4 bytes Min MTU: 1280 bytes 127 802.15.4 MTU:127 bytes Max frame header=25 bytes 127-25=102 For link layer security 21 bytes, 102-21=81 Must compress the IPv6 header Thus,we need: Define an adaptation layer to implement fragmentation and assembly work Compress the header
Protocol Stack Application Application Application Transport Transport Transport IPv6 Ethernet or other MAC/PHY Ethernet or other MAC/PHY IPv6 Adaptation 802.15.4MAC /PHY IPv6 Adaptation 802.15.4MAC /PHY Internet 6LoWPAN
6LoWPAN adaptation layer function IPv6 header compression IPv6 packages fragmentation and reassembly Neighbor discovery and multicast function for IoT Routing function Mesh routing in the PAN domain; Routing between PAN domain and IPv6 domain;
Header compression There may be several headers before each data packet, called the header stack, e.g., IPv6 Header, HC1 Header,Mesh Header,Frag Header, Broadcast Header etc. When more than one header is used in the same packet, it is recommended that those headers appear in the following order: Mesh Addressing Header Broadcast Header Fragmentation Header +--------+---------+---------+--------+-------------+---------------+-----------+------------+-----------+ M Typ M Hdr B Dsp B Hdr Frag Type Frag Header HC1 Dsp HC1 Hdr Payload +--------+---------+---------+--------+-------------+---------------+-----------+------------+-----------+
IPv6 header compression Problem: Each domain of the original IPv6 header is in fixed bytes. The location of each domain after compression will not be fixed. How to distinguish? Solution: dispatch mechanism (RFC4944) That is, add a dispatch before each header in the header stack to identify each header.
Dispatch Dispatch represents the compression policy identifier, which uses IPHC compression coding. IPHC indicates the encoding format. In-line indicates the uncompressed portion of the IPv6 header. In a local connection, in the best case, compression can be 2 bytes (1 byte dispatch and one byte IPHC encoding) In multi-hop routing, it can be compressed to 7 bytes (1 byte dispatch, 1 byte IPHC, 1 byte hop limit, 2 byte source address, and 2 byte destination address)
When using stateless address compression, IPHC is 2 bytes, and stateful address compression is 3 bytes. A stateful compression uses a context table which maintain the address prefixes used over a period of time. TF: Traffic Class, Flow Label 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes) 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided. 10: ECN + DSCP (1 byte), Flow Label is elided. 11: Traffic Class and Flow Label are elided.
NH: Next Header 0: Full 8 bits for Next Header are carried in-line. 1: The Next Header field is compressed and the next header is encoded using LOWPAN_NHC. Extension Header EID: IPv6 Extension Header ID: 0: IPv6 Hop-by-Hop Options Header[RFC2460] 1: IPv6 Routing Header[RFC2460] 2: IPv6 Fragment Header[RFC2460] 3: IPv6 Destination Options Header[RFC2460] 4: IPv6 Mobility Header [RFC3775] 5: Reserved 6: Reserved 7: IPv6 Header
HLIM: Hop Limit 00: The Hop Limit field is carried in-line. 01: The Hop Limit field is compressed and the hop limit is 1. 10: The Hop Limit field is compressed and the hop limit is 64. 11: The Hop Limit field is compressed and the hop limit is 255. CID: Context Identifier Extension 0: No additional 8-bit Context Identifier Extension is used. If context-based compression is specified in either Source Address Compression (SAC) or Destination Address Compression (DAC), context 0 is used. (stateless address compression) 1: An additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field. ( stateful address compression )
Stateless address compression (E.g., source address) SAC: Source Address Compression, SAC=0 SAM: Source Address Mode: 00: 128 bits. All the addresses are saved in the in-line section 01: 64 bits. The first 64-bit address is omitted. The prefix is fe80::. The last 64 bits are saved in the in-line section. 10: 16 bits. The first 64-bit address is omitted. The prefix is fe80::. The last 64 bits are 0000:00ff:fe00:XXXX. 16-bit XXXX is reserved in the in-line part. (16-bit short address of IEEE 802.15.4) 11: 0 bits. The whole address is omitted. The prefix is fe80::. The last 64 bits can be obtained by the link layer address.
Stateful address compression (E.g. source address) SAC: Source Address Compression,SAC=1 SAM: Source Address Mode: 00: 0 bits. Addresses, such as UNSPECIFIED(::), are all omitted. 01: 64 bits. The first 64-bit address is omitted, the prefix can be read in the context table, and the last 64 bits are stored in the in-line section. 10: 16 bits. The first 64-bit address is omitted, the prefix can be read in the context table, and the last 64-bit address is in the format 0000:00ff:fe00:XXXX, where 16-bit XXXX is reserved in the in-line part. 11: 0 bits. All addresses are omitted. The prefix can be read in the context table, and the last 64-bit address can be derived from the link layer address. At this time, the value of SCI is the index of the prefix in the context table.
M: Multicast Compression 0: Destination address is not a multicast address. 1: Destination address is a multicast address. DAC: Destination Address Compression 0: Destination address compression uses stateless compression. 1: Destination address compression uses stateful, context-based compression. DAM: Destination Address Mode (refer to the source address)
UDP header encoding C: Checksum 0:All the16-bit Checksums are saved in the in-line section 1:All the16-bit Checksums are omitted. Recalculate at the target node. P: Ports: 00: Source port and destination port are totally saved in the in-line part 01: The source port is saved in the in-line part. If the first 8 bits of the destination port are 0xF0, then omitted. And the last 8 bits are saved in the in-line part. 10: The destination port is saved in the in-line part. If the first 8 bits of the source port are 0xF0, then omitted. The last 8 bits are saved in the in-line part. 11: If the first 12 bits of the source and destination ports are 0xF0B, then omitted. The last 4 bits are saved in the in-line part.
Conclusion for header compression +---------------------+------------+---------------------+-----------------+----------+ LOWPAN_IPHC In-line LOWPAN_NHC In-line Next Payload -----------------------+------------+---------------------+------------------+----------+ The order of header compression is IP header, IP extension header and UDP header. The format of compression strategy is basically the same, both compression coding + In-Line part.
Example for compression Uncompressed IPv6/UDP(the worst case), Dispatch (01000001) represents uncompressing The best case of compression is mainly for the local link address, Dispatch (01000010) represents HC1 compression
Traditional neighbor discovery for IPv6 (RFC4861) Based on ICMP(Type 133-137) Include 5 kinds of messages: Router Solicitation : Host -> Router Router Advertisement : the router advertises its presence and configured link and network parameters. Caused by the host's router request, unicast Sent in the fixed time, multicast Neighbor Solicitation: request the link-layer address of the neighbor, or verify the reachability of the address in the cache, or use it for duplicate address detection. Neighbor Advertisement:1)caused by a neighbor request;2)sent when the link layer address changes Redirection
The features of 6LoWPAN IEEE802.15.4 does not support multicast, only provides unreliable broadcast. Broadcasting causes a large amount of energy consumption in sensor nodes The neighbor discovery protocol requires a lot of code space for the complete processing of the message, and is not suitable for sensor nodes with limited storage resources. Sensor node has a sleep condition
ND(RFC6775)--the improvement of RFC4861 Increase host-initiated interactions so that the host goes into sleep state to reduce energy consumption Remove multicast-based address resolution Remove duplicate address detection DAD if EUI-64 based IPv6 address is used Remove redirect Add new options new option: used in neighbor request and neighbor advertisement to increase the registration function of the host address. new option: optionally, the neighbor information is used in the neighbor advertisement to send the 6lowpan header compressed context information to the host. new option: optionally, used in neighbor advertisements to specify an authoritative router in a multi-router network In the Route-over network, two new messages are used for duplicate address detection DAD
New functions of ND Address registration function 6CO maintenance function
Address registration process 6LN is the sensor node and 6LR is the edge router. This option attached to Neighbor Solicitation Message (NS) and Neighbor Advertisement Message (NA) ARO:Address Registration Option SLLAO: Source Link-Layer Address Option
ARO option The purpose of this feature is to improve the duplicate address detection feature in RFC 4861. Register the option ARO with the address above.
Reply to address registration The status of NA
6CO maintenance function The purpose of this function is to provide context table maintenance for the address compression part of 6LoWPAN header compression. This is achieved by 6CO (6LoWPAN Context Option) option.
6CO maintenance process 6LN is the sensor node and 6LR is the edge router. This option is attached to Router Solicitation Message (RS) and Router Advertisement Message (RA). PIO: Prefix Information Option ABRO: Authoritative Border Router Option
Duplicate address detection Used in multihop environment, sending between 6LBR and 6LR Based on ICMPv6, Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC)
Address registration(including DAD)
Catalogue Introduction of ICMPv6 Standards in IoT related to IPv6 Introduction of 6LoWPAN Status and trends of 6LoWPAN deployment
Open source implementation of 6LoWPAN Contiki http://www.contiki-os.org/ Adopts the small, open source, highly portable multitasking computer operating system developed in C language, requires only a few kilobytes of memory to run. Supported protocol IPv4 and IPv6 6Lowpan RPL CoAP Support various hardware platforms, participating in research and development personnel from Atmel, Cisco, ETH, Redwire LLC, SAP, etc.
Product/Prototype Foreign Commsignia Ltd. Aalborg University JPR IT ASSOCIATES NIVIS RIOT - INRIA Telecom Bretagne University of Bremen Ghent University - iminds Uiversity of New Hamshire Purdue University Virtenio GmbH
Product/ Prototype Domestic Maxim Lingke Ningbo Institute of Information Technology Application Research Institute Tsinghua University Chongqing University of Posts and Telecommunications Hong Kong Polytechnic University Harbin Institute of Technology Hitachi (China) Research and Development Co., Ltd. Wuxi Meixin
Smart home Thread Thread:Google's acquisition of Nest, combined with ARM, Samsung, Fiskar and other heavyweight hardware players to set up the Thread Alliance, the launch of the Internet of Things protocol Thread, designed to provide better networking services for smart home. Thread is a low-power mesh network protocol that also supports the IPv6 protocol. Thread is built on top of the wireless hardware currently used by ZigBee devices (802.15.4), which means that companies can adopt the Thread standard as long as they update their ZigBee devices. Thread's goal is to be the new standard for smart home wireless networks instead of Wi-Fi and Bluetooth. HomeKit, Nest's development plansand even Qualcomm's AllJoyn project will be built on top of the Thread standard. The Nest thermostat has adopted the Thread standard.
MeshSPAIS-- Precision Agriculture Intelligent Detection System Solution Precision agriculture Information system based on Internet of Things technology wireless sensor network The MeshSPAIS system extends the Internet from the desktop to the field, allowing the greenhouse to be online in real time, thus enabling the fusion of vegetable greenhouses and the data world.
monitoring system for Shenzhen mobile computer room temperature and humidity Based on 6LoWPAN technology, it provides realtime monitoring information on the temperature and humidity of the equipment room, providing similar "weather forecast" services.
The necessity of IPv6 in IoT applications The IETF began to propose alternative IPv4 solutions in 1992 - IPv6. At the end of 1995, the IPv6 protocol was released with RFC1883. In this RFC, compared to IPv4, the improvements in IPv6:the huge address space, the level of effective routing scheme, the standardized IPsec encryption mechanism, the mobility and QoS support. RFC8200 released in 2017, became the STD86. IPv6 and IPv4 are incompatible. The advantages of IPv6 are not enough to attract network operators and ICPs to change the direction in IPv6 when IPv4 can still support them. Now faced with the problem of no more IPv4 address available, this should be a rare opportunity for IPv6 development, and the future network cannot evade IPv6. The Internet is the most commonly used and most convenient bearer network for the Internet of Things. The Internet of Things will inevitably need to communicate with IPv6 in the future, because the number of IPv6 addresses is originally designed for ubiquitous networks.
Network Information Center Institute of Network Technology BUPT