Embedded Internet and the Internet of Things WS 12/13 6. 6LoWPAN - - PowerPoint PPT Presentation

▶
embedded internet and the internet of things ws 12 13 6
SMART_READER_LITE
LIVE PREVIEW

Embedded Internet and the Internet of Things WS 12/13 6. 6LoWPAN - - PowerPoint PPT Presentation

Jan 05, 2024 376 likes •1.2k views

Embedded Internet and the Internet of Things WS 12/13 6. 6LoWPAN Prof. Dr. Mesut Gne Distributed, embedded Systems (DES) Institute of Computer Science Freie Universitt Berlin 1 Prof. Dr. Mesut Gne 6. 6LoWPAN 6LoWPAN: The

slide-1
SLIDE 1

Embedded Internet and the Internet of Things WS 12/13

  • 6. 6LoWPAN
  • Prof. Dr. Mesut Güneş

Distributed, embedded Systems (DES) Institute of Computer Science Freie Universität Berlin

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

1

slide-2
SLIDE 2

6LoWPAN: ¡The ¡Wireless ¡Embedded ¡Internet ¡ Companion ¡Lecture ¡Slides ¡

¡

Figures ¡on ¡slides ¡with ¡book ¡symbol ¡from ¡6LoWPAN: ¡The ¡Wireless ¡Embedded ¡Internet, ¡ Shelby ¡& ¡Bormann, ¡ISBN: ¡978-­‑0-­‑470-­‑74799-­‑5, ¡(c) ¡2009 ¡John ¡Wiley ¡& ¡Sons ¡Ltd ¡ This ¡work ¡is ¡licensed ¡under ¡the ¡CreaRve ¡Commons ¡ATribuRon-­‑Noncommercial-­‑Share ¡Alike ¡ 3.0 ¡Unported ¡License. ¡To ¡view ¡a ¡copy ¡of ¡this ¡license, ¡visit ¡ hTp://creaRvecommons.org/licenses/by-­‑nc-­‑sa/3.0/ ¡or ¡send ¡a ¡leTer ¡to ¡CreaRve ¡Commons, ¡ 171 ¡Second ¡Street, ¡Suite ¡300, ¡San ¡Francisco, ¡California, ¡94105, ¡USA ¡ ¡

slide-3
SLIDE 3

Outline

  • Introduction to 6LoWPAN
  • Refresher
  • The Internet Architecture & Protocols
  • Link Layer Technologies
  • The 6LoWPAN Format
  • Bootstrapping
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

3

slide-4
SLIDE 4

Introduction to 6LoWPAN

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

4

slide-5
SLIDE 5

Relationship of Standards

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

5 International Society of Automation www.isa.org

www.etsi.org/technologies- clusters/technologies/m2m www.opengeospatial.org www.ip500alliance.org

slide-6
SLIDE 6

What is 6LoWPAN?

  • IPv6 over Low-Power wireless Area Networks (LoWPAN)
  • LowPAN = LLN?
  • Defined by IETF standards
  • Stateless header compression
  • Enables a standard socket API
  • Minimal use of code and memory
  • Direct end-to-end Internet integration
  • Multiple topology options
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

6

IPv6

slide-7
SLIDE 7

What is 6LoWPAN?

  • RFC 4919 (draft-ietf-6lowpan-problem), 08/2007
  • IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,

Problem Statement, and Goals

  • RFC 4944 (draft-ietf-6lowpan-format), 09/2007
  • Transmission of IPv6 Packets over IEEE 802.15.4 Networks
  • RFC 6282 (draft-ietf-6lowpan-hc), 09/2011
  • Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
  • RFC 6775 (draft-ietf-6lowpan-nd), 11/2012
  • Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks

(6LoWPANs)

  • RFC 6568 (draft-ietf-6lowpan-usecases), 04/2012
  • Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks

(6LoWPANs)

  • RFC 6606 (draft-ietf-6lowpan-routing-requirements), 05/2012
  • Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area

Network (6LoWPAN) Routing

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

7

http://datatracker.ietf.org/wg/6lowpan/

slide-8
SLIDE 8

What is 6LoWPAN?

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

8

RFC4919 RFC6568 RFC6606

slide-9
SLIDE 9

Protocol Stack

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

9

slide-10
SLIDE 10

Architecture

  • LoWPANs are stub networks
  • Ad-hoc LoWPAN
  • No route outside

the LoWPAN

  • Simple LoWPAN
  • Single Edge Router
  • Extended LoWPAN
  • Multiple Edge Routers

with common backbone link

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

10

slide-11
SLIDE 11

Architecture

  • Device types
  • H Host
  • R Router
  • ER Edge router
  • Edge router
  • Runs special protocols
  • Simplifies operation
  • Shared database: Whiteboard
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

11

slide-12
SLIDE 12

Architecture

  • Internet Integration issues
  • Maximum transmission unit (1500 vs 127 bytes)
  • Application protocols
  • IPv4 interconnectivity
  • Firewalls and NATs
  • Security
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

12

IPv6-LoWPAN Router Stack

slide-13
SLIDE 13

Refresher

The Internet Architecture & Protocols

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

13

slide-14
SLIDE 14

IP Protocol Stack

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

14

slide-15
SLIDE 15

Internet Protocol v6

  • IPv6 = the next generation Internet Protocol
  • Complete redesign of IP addressing
  • Hierarchical 128-bit address with decoupled host identifier
  • Stateless autoconfiguration
  • Simple routing and address management
  • Majority of traffic not yet IPv6 but...
  • Most PC operating systems already have IPv6
  • Governments are starting to require IPv6
  • Most routers already have IPv6 support
  • So the IPv6 transition is coming
  • 1400% annual growth in IPv6 traffic (2009)
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

15

[RFC2460]

slide-16
SLIDE 16

IPv4 vs. IPv6 Addressing

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

16

Image source: Indeterminant (Wikipedia) GFDL

slide-17
SLIDE 17

Address Space Comparison

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

17

Image source: Smurrayinchester (Wikipedia) CC 3.0

slide-18
SLIDE 18

IPv4 vs. IPv6: Header

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

18

En sion Prio rity Flow label PayloadLen NEXT headers Hop limit Source Address Destination Address Next Header / Data SOURCE ADDRESS Destination ADDRESS Destination ADDRESS Destination ADDRESS Destination ADDRESS NEXT header/DATA En sion IHL Totally length Type OF service Identification Fragment offset Time to Live Protocol Header Checksum SOURCE ADDRESS Destination ADDRESS Option (variable)/Padding DATA

The IPv6 header is longer, but this is only caused by the longer addresses.

Ver- sion 4 ¡ 8 ¡ 16 ¡ 32 ¡ Traffic Class Flow Label PayloadLen Next Header Hop Limit Next Header / Data 4 ¡ 8 ¡ 16 ¡ 32 ¡ Ver- sion IHL Total Length Type of Service Identification Time to Live Protocol Source Address Destination Address Options (variable)/Padding Data Source Address ¡ Destination Address ¡

slide-19
SLIDE 19

IPv6 Neighbor Discovery (ND)

  • IPv6 is the format - ND is the brain
  • “One-hop routing protocol” defined in RFC4861
  • Defines the interface between neighbors
  • Finding Neighbors
  • Neighbor Solicitation (NS) / Neighbor Acknowledgement (NA)
  • Finding Routers
  • Router Solicitation (RS) / Router Advertisement (RA)
  • Address resolution using NS/NA
  • Detecting Duplicate Addresses using NS/NA
  • Neighbor Unreachability Detection using NS/NA
  • DHCPv6 may be used in conjunction with ND
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

19

[RFC4861]

slide-20
SLIDE 20

IPv6 Neighbor Discovery

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

20

slide-21
SLIDE 21

ICMPv6

  • The Internet Control Message Protocol (ICMPv6)
  • Used for control messaging between IPv6 nodes
  • ICMPv6 Error Messages
  • Destination Unreachable Message
  • Packet Too Big Message
  • Time Exceeded Message
  • Parameter Problem Message
  • ICMPv6 Informational Messages
  • Echo Request Message
  • Echo Reply Message
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

21

[RFC4443]

slide-22
SLIDE 22

ICMPv6

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

22 The ICMPv6 messages have the following general format:

  • 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | |

  • The type field indicates the type of the message. Its value

determines the format of the remaining data.

  • The code field depends on the message type. It is used to create an

additional level of message granularity.

  • The checksum field is used to detect data corruption in the ICMPv6

message and parts of the IPv6 header.

  • [RFC4443]
slide-23
SLIDE 23

TCP

  • The Transmission Control Protocol (TCP)
  • A reliable, ordered transport for a stream of bytes
  • TCP is connection oriented, forming a pairing between 2 hosts

using a 3-way handshake

  • Positive ack windowing is used with flow control
  • Congestion control mechanism critical for the Internet
  • TCP is not suitable for every application
  • Support for unicast communications only
  • Reacts badly to e.g. wireless packet loss
  • Not all protocols require total reliability
  • TCP connection not suitable for very short transactions
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

23

[RFC793]

slide-24
SLIDE 24

The TCP Header

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

24

[RFC793]

slide-25
SLIDE 25

UDP

  • The User Datagram Protocol (UDP)
  • Used to deliver short messages over IP
  • Unreliable, connectionless protocol
  • Can be used with broadcast and multicast
  • Common in streaming and VoIP, DNS, and network tools

0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ...

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

25

[RFC768]

slide-26
SLIDE 26

Refresher

Stateless Autoconfiguration RFC4862 obsoletes RFC2462

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

26

[RFC4862]

slide-27
SLIDE 27

Design goals

  • Manual configuration of individual machines before connecting

them to the network should not be required.

  • Address autoconfiguration assumes that each interface can provide a

unique identifier for that interface (i.e., an "interface token")

  • Plug-and-play communication is achieved through the use of

link-local addresses

  • Small sites should not need stateful servers
  • A large site with multiple networks and routers should not

require the presence of a stateful address configuration server.

  • Address configuration should facilitate the graceful

renumbering of a site's machines

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

27

slide-28
SLIDE 28

Design goals

  • Tentative address
  • An address whose uniqueness on a link is being verified
  • An interface discards received packets addressed to a tentative

address, but accepts Neighbor Discovery packets

  • Preferred address
  • An address assigned to an interface whose use by upper-layer

protocols is unrestricted.

  • Deprecated address
  • An address assigned to an interface whose use is discouraged, but

not forbidden

  • Valid address
  • A preferred or deprecated address
  • Invalid address
  • An address that is not assigned to any interface.
  • A valid address becomes invalid when its valid lifetime expires.
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

28

slide-29
SLIDE 29

Design goals

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

29

slide-30
SLIDE 30

Stateless Autoconfiguration

Generate a link local address Tentative address Address is in use. A neighbor advertisement Message will be returned. Address is not used! Assign the address to the Interface. At this point the Node can communicate. Fail and go to manual Configuration or choose A different interface token Test address

Msg Timer expires

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

30

slide-31
SLIDE 31

Stateless Autoconfiguration

Assign address to Interface. Node joins the All Routers Multicast group. FF02::1 Sends out a router solicitation message to that group. Router responds with a Router advertisement.

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

31

slide-32
SLIDE 32

Refresher

Link Layer Technologies

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

32

slide-33
SLIDE 33

The Link-Layer and IP

  • The Internet Protocol interconnects heterogeneous links
  • Key link-layer features to support IP
  • Framing
  • Addressing
  • Error checking
  • Length indication
  • Broadcast and unicast
  • RFC3819 discusses IP subnetwork design
  • 6LoWPAN enables IPv6 over very constrained links
  • Limited frame size and bandwidth
  • Wireless mesh topologies and sleeping nodes
  • No native multicast support
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

33

slide-34
SLIDE 34

IEEE 802.15.4

  • Important standard for home

networking, industrial control and building automation

  • Three PHY modes
  • 20 kbps at 868 MHz
  • 40 kbps at 915 MHz
  • 250 kbps at 2.4 GHz (DSSS)
  • Beaconless mode
  • Simple CSMA algorithm
  • Beacon mode with superframe
  • Hybrid TDMA-CSMA algorithm
  • Up to 64k nodes with 16-bit

addresses

  • Extensions to the standard
  • IEEE 802.15.4a, 802.15.4e,

802.15.5

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

34

slide-35
SLIDE 35

Other Link-Layers for 6LoWPAN

  • Sub-GHz Industrial, Scientific and Medical band radios
  • Typically 10-50 kbps data rates, longer range than 2.4 GHz
  • Usually use CSMA-style medium access control
  • Example: CC1110 from Texas Instruments
  • Power-Line Communications
  • Some PLC solutions behave like an 802.15.4 channel
  • Example: A technology from Watteco provides an 802.15.4

emulation mode, allowing the use of 6LoWPAN

  • Z-Wave
  • A home-automation low-power radio technology
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

35

slide-36
SLIDE 36

The 6LoWPAN Format

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

36

slide-37
SLIDE 37

Architecture

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

37

slide-38
SLIDE 38

The 6LoWPAN Format

  • 6LoWPAN is an adaptation header format
  • Enables the use of IPv6 over low-power wireless links
  • IPv6 header compression
  • UDP header compression
  • Format initially defined in RFC4944 updated by RFC6282
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

38

slide-39
SLIDE 39

The 6LoWPAN Format

  • 6LoWPAN makes use of IPv6 address compression
  • RFC4944 Features:
  • Basic LoWPAN header format
  • HC1 (IPv6 header) and HC2 (UDP header) compression formats
  • Fragmentation & reassembly
  • Mesh header feature (depreciation planned)
  • Multicast mapping to 16-bit address space
  • RFC6282 Features:
  • New HC (IPv6 header) and NHC (Next-header) compression
  • Support for global address compression (with contexts)
  • Support for IPv6 extension header compression
  • Support for UDP
  • Support for compact multicast address compression
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

39

slide-40
SLIDE 40

The 6LoWPAN Format

Addressing

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

40

slide-41
SLIDE 41

IPv6 Addressing

  • 128-bit IPv6 address Interface ID (IID)

64-bit prefix + 64-bit

  • The 64-bit prefix is hierarchical
  • Identifies the network you are on and where it is globally
  • The 64-bit IID identifies the network interface
  • Must be unique for that network
  • Typically is formed statelessly from the interface MAC address
  • Called Stateless Address Autoconfiguration (RFC4862)
  • There are different kinds of IPv6 addresses
  • Loopback (0::1) and Unspecified (0::0)
  • Unicast with global (e.g. 2001::) or link-local (FE80::) scope
  • Multicast addresses (starts with FF::)
  • Anycast addresses (special-purpose unicast address)
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

41

[RFC2373]

slide-42
SLIDE 42

6LoWPAN Addressing

  • IPv6 addresses are compressed in 6LoWPAN
  • A LoWPAN works on the principle of
  • flat address spaces (wireless network is one IPv6 subnet)
  • with unique MAC addresses (e.g. 64-bit or 16-bit)
  • 6LoWPAN compresses IPv6 addresses by
  • Eliding the IPv6 prefix
  • Global prefix known by all nodes in network
  • Link-local prefix indicated by header compression format
  • Compressing the IID
  • Elided for link-local communication
  • Compressed for multihop dst/src addresses
  • Compressing with a well-known “context”
  • Multicast addresses are compressed
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

42

slide-43
SLIDE 43

6LoWPAN Addressing

  • Forming addresses out of 16-bit short addresses
  • Pseudo 48-bit address is formed in two steps:

(1) 16_bit_PAN:16_zero_bits (2) 32_bits_as_specified_previously:16_bit_short_address

  • The interface identifier is formed from this 48-bit

address

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

43

slide-44
SLIDE 44

6LoWPAN Addressing

IPv6 Link Local Address

  • The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface

is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.

  • 10 bits 54 bits 64 bits

+----------+-----------------------+----------------------------+ |1111111010|00 (zeros) 00| Interface Identifier | +----------+-----------------------+----------------------------+ F E 8 0

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

44

slide-45
SLIDE 45

Addressing Example

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

45

slide-46
SLIDE 46

The 6LoWPAN Format

Header compression

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

46

slide-47
SLIDE 47

Header compression

  • Large IPv6 datagram needs to be transmitted
  • How to compress the header to save resources?
  • Integrate Layer 2 and Layer 3 compression
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

47

slide-48
SLIDE 48

UDP/IPv6 Headers

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

48

IPv6 UDP Payload 48 Bytes

slide-49
SLIDE 49

Encoding of IPv6 Header Fields

  • Encode different combinations with “HC1 encoding”
  • 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • LOWPAN_HC1 (common compressed header encoding)
  • The address fields encoded by "HC1 encoding" are interpreted as follows:

PI: Prefix carried in-line PC: Prefix compressed (link-local prefix assumed) II: Interface identifier carried in-line IC: Interface identifier elided -> derivable from link-layer address

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

49

[RFC4944]

slide-50
SLIDE 50

Encoding of IPv6 Header Fields

  • Encode different combinations with “HC1 encoding”
  • 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S A|D A|T|N H|H| Non-Compressed fields follow... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • SA Source address (bits 0 and 1)
  • DA Destination address (bits 2 and 3)
  • T

Traffic class and Flow Label (bit 4)

  • NH Next header (bits 5 and 6)
  • H

HC2 encoding (bit 7)

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

50

[RFC4944]

slide-51
SLIDE 51

LoWPAN Adaptation Layer and Frame Format

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

51 These examples show typical header stacks that may be used in a LoWPAN network.

  • A LoWPAN encapsulated IPv6 datagram:

+---------------+-------------+---------+ | IPv6 Dispatch | IPv6 Header | Payload | +---------------+-------------+---------+

  • A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:

+--------------+------------+---------+ | HC1 Dispatch | HC1 Header | Payload | +--------------+------------+---------+

  • A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires mesh

addressing: +-----------+-------------+--------------+------------+---------+ | Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload | +-----------+-------------+--------------+------------+---------+

  • A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires

fragmentation: +-----------+-------------+--------------+------------+---------+ | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload | +-----------+-------------+--------------+------------+---------+

slide-52
SLIDE 52

LoWPAN Adaptation Layer and Frame Format

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

52 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both mesh addressing and fragmentation:

  • +-------+-------+-------+-------+---------+---------+---------+

| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload | +-------+-------+-------+-------+---------+---------+---------+

  • A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both

mesh addressing and a broadcast header to support mesh broadcast/multicast:

  • +-------+-------+-------+-------+---------+---------+---------+

| M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload | +-------+-------+-------+-------+---------+---------+---------+

slide-53
SLIDE 53

Dispatch Type and Header

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

53

The dispatch type is defined by a zero bit as the first bit and a one bit as the second bit. The dispatch type and header are shown here:

  • 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| Dispatch | type-specific header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Dispatch 6-bit selector:

Identifies the type of header immediately

  • following the Dispatch Header.
  • type-specific header:
  • A header determined by the Dispatch Header.
  • The dispatch value may be treated as an unstructured namespace. Only a few symbols are

required to represent current LoWPAN functionality. Although some additional savings could be achieved by encoding additional functionality into the dispatch byte, these measures would tend to constrain the ability to address future alternatives.

slide-54
SLIDE 54

Dispatch Value Bit Pattern

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

54

Pattern Header Type +------------+-----------------------------------------------+ | 00 xxxxxx | NALP - Not a LoWPAN frame | | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | | 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 | | 01 000011 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 01 001111 | reserved - Reserved for future use | | 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast | | 01 010001 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 01 111110 | reserved - Reserved for future use | | 01 111111 | ESC - Additional Dispatch byte follows | | 10 xxxxxx | MESH - Mesh Header | | 11 000xxx | FRAG1 - Fragmentation Header (first) | | 11 001000 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 11 011111 | reserved - Reserved for future use | | 11 100xxx | FRAGN - Fragmentation Header (subsequent)| | 11 101000 | reserved - Reserved for future use | | ... | reserved - Reserved for future use | | 11 111111 | reserved - Reserved for future use | +------------+-----------------------------------------------+

slide-55
SLIDE 55

Header Comparison

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

55

LoWPAN dispatch

slide-56
SLIDE 56

LoWPAN UDP/IPv6 Headers

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dispatch with LOWPAN_IPHC | LOWPAN_NHC | Src | Dst | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Checksum | UDP Payload ...

  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

56 IPv6 ¡ UDP ¡ Payload ¡

6 ¡Bytes ¡

LoWPAN ¡

[RFC6282]

slide-57
SLIDE 57

IP Header Compression (IPHC)

  • In the best case, the LOWPAN_IPHC can compress the IPv6

header down to two octets

  • the dispatch octet and
  • the LOWPAN_IPHC encoding with link-local communication
  • When routing over multiple IP hops, LOWPAN_IPHC can

compress the IPv6 header down to 7 octets

  • 1 octet dispatch
  • 1 octet LOWPAN_IPHC
  • 1 octet Hop Limit
  • 2 octet Source Address
  • 2 octet Destination Address
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

57

LOWPAN_IPHC Header

  • +-------------------------------------+----------------------------

| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields +-------------------------------------+----------------------------

  • [RFC6282]
slide-58
SLIDE 58

IP Header Compression (IPHC)

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

58

LOWPAN_IPHC Encoding

  • 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

  • TF = Traffic Class, Flow Label

NH = Next Header Flag HLIM = Hop Limit CID = Context Identifier Extension SAC = Source Address Compression SAM = Source Address Mode M = Multicast Compression DAC = Destination Address Compression DAM = Destination Address Mode ¡

[RFC6282]

slide-59
SLIDE 59

IP Header Compression (IPHC)

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

59

IPv6 Extension Header Encoding

  • 0 1 2 3 4 5 6 7

+---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 0 | EID |NH | +---+---+---+---+---+---+---+---+

  • EID: IPv6 Extension Header ID

NH: Next Header

slide-60
SLIDE 60

UDP Header Compression

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

60

NHC Format

  • +----------------+---------------------------

| var-len NHC ID | compressed next header... +----------------+---------------------------

  • UDP NHC Encoding
  • 0 1 2 3 4 5 6 7

+---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 0 | C | P | +---+---+---+---+---+---+---+---+

  • C = Checksum Compression

P = UDP Port Compression

  • [RFC6282]
slide-61
SLIDE 61

The 6LoWPAN Format

Fragmentation

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

61

slide-62
SLIDE 62

Fragmentation

  • IPv6 requires underlying links to support Minimum

Transmission Units (MTUs) of at least 1280 bytes

  • IEEE 802.15.4 leaves approximately 80-100 bytes of

payload!

  • RFC4944 defines fragmentation and reassembly of IPv6
  • The performance of large IPv6 packets fragmented over

low-power wireless mesh networks is poor!

  • Lost fragments cause whole packet to be retransmitted
  • Low-bandwidth and delay of the wireless channel
  • 6LoWPAN application protocols should avoid fragmentation
  • Compression should be used on existing IP application protocols

when used over 6LoWPAN if possible

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

62

slide-63
SLIDE 63

Fragmentation

  • Impact of fragmentation in LoWPANs
  • Assumptions
  • p Uncorrelated packet loss probability
  • n Number of fragments
  • Probability of datagram loss: 1-(1-p)n
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

63

slide-64
SLIDE 64

Fragmentation

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

64

Initial Fragment

  • 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Following Fragments
  • 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0| datagram_size | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |datagram_offset| +-+-+-+-+-+-+-+-+ ¡

Encodes the size of the entire IP packet before link-layer fragmentation Identification of fragments of the same IPv6 datagram

slide-65
SLIDE 65

Bootstrapping

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

65

slide-66
SLIDE 66

6LoWPAN Setup & Operation

  • Autoconfiguration is important in embedded

networks

  • In order for a 6LoWPAN network to start

functioning:

  • 1. Link-layer connectivity between nodes (commissioning)
  • 2. Network layer address configuration, discovery of

neighbors, registrations (bootstrapping)

  • 3. Routing algorithm sets up paths (route initialization)
  • 4. Continuous maintenance of 1-3
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

66

slide-67
SLIDE 67

Link-layer Commissioning

  • In order for nodes to communicate with each other, they

need to have compatible physical and link-layer settings.

  • Example IEEE 802.15.4 settings:
  • Channel, modulation, data-rate (Channels 11-26 at 2.4 GHz)
  • Usually a default channel is used, and channels are scanned to find a

router for use by Neighbor Discovery

  • Addressing mode (64-bit or 16-bit)
  • Typically 64-bit is a default and 16-bit used if address available
  • MAC mode (beaconless or super-frame)
  • Beaconless mode is easiest for commissioning (no settings needed)
  • Security (on or off, encryption key)
  • In order to perform secure commissioning a default key should already

be installed in the nodes

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

67

slide-68
SLIDE 68

6LoWPAN Neighbor Discovery

  • Standard ND for IPv6 is not appropriate for 6LoWPAN:
  • Assumption of a single link for an IPv6 subnet prefix
  • Assumption that nodes are always on
  • Heavy use of multicast traffic (broadcast/flood in 6LoWPAN)
  • No efficient multihop support over e.g. 802.15.4
  • 6LoWPAN Neighbor Discovery provides:
  • An appropriate link and subnet model for low-power wireless
  • Minimized node-initiated control traffic
  • Node Registration (NR) and Confirmation (NC)
  • Duplicate Address Detection (DAD) and recovery
  • Support for extended Edge Router infrastructures
  • ND for 6LoWPAN has been specified in RFC6775
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

68

slide-69
SLIDE 69

Architecture

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

69

slide-70
SLIDE 70

Prefix Dissemination

  • In normal IPv6 networks RAs are sent to a link based on

the information (prefix etc.) configured for that router interface

  • In ND for 6LoWPAN RAs are also used to automatically

disseminate router information across multiple hops

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

70

slide-71
SLIDE 71

Node Registration

  • 6LoWPAN-ND Optimizes only the host-router interface
  • RFC4861 = signaling between all neighbors (distributed)
  • Nodes register with their neighboring routers
  • Exchange of NR/NC messages
  • Binding table of registered nodes kept by the router
  • Node registration exchange enables
  • Host/router unreachability detection
  • Address resolution (a priori)
  • Duplicate address detection
  • Registrations are soft bindings
  • Periodically refreshed with a new NR message
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

71

slide-72
SLIDE 72

NR/NC Format

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

72

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • | Type (NR)/(NC)| Code | Checksum |
  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • | TID | Status |P|_____________________________|
  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • | Binding Lifetime | Advertising Interval |
  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • | |
  • + Owner Interface Identifier +
  • | |
  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • | Owner Nonce |
  • +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • | Registration option(s)...

+-+-+-+-+-+-+-+-+-+-+-+-+-+

slide-73
SLIDE 73

Typical 6LoWPAN-ND Exchange

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

73

slide-74
SLIDE 74

The Whiteboard

  • The whiteboard is used in the LoWPAN for:
  • Duplicate address detection for the LoWPAN (= prefix)
  • Dealing with mobility (Extended LoWPANs)
  • Short address generation
  • Locating nodes
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

74

slide-75
SLIDE 75

Extended LoWPANs

  • Extended LoWPANs consist of two or more LoWPANs:
  • Which share the same IPv6 prefix
  • Which are connected together by a backbone link
  • Whiteboards are synchronized over the backbone link
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

75

slide-76
SLIDE 76

Security

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

76

slide-77
SLIDE 77

Security for 6LoWPAN

  • Security is important in wireless embedded networks
  • Wireless radios are easily overheard
  • Autonomous devices with limited processing power
  • A system usually has three main security goals
  • Confidentiality
  • Integrity
  • Availability
  • See the threat model for Internet security in RFC3552
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

77 L2 ¡Mechanisms ¡ L3 ¡Mechanisms ¡ L5 ¡Mechanisms ¡

slide-78
SLIDE 78

Layer-2 Mechanisms

  • Internet security is usually thought of as end-to-end
  • In wireless networks the channel itself is very vulnerable
  • The channel is easy to overhear
  • Nodes and packets are easy to spoof
  • The goals of security at the data-link layer
  • Protect the wireless network against attackers
  • Increase robustness against attacks
  • IEEE 802.15.4 provides built-in encryption
  • Based on the 128-bit Advanced Encryption Standard (AES)
  • Counter with CBC-MAC mode (CCM)
  • Provides both encryption and an integrity check
  • Most chips include an AES-128 hardware engine
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

78

slide-79
SLIDE 79

Layer-3 Mechanisms

  • End-to-end security can be provided by IP
  • Protects the entire path between two end-points
  • The IPsec standard [RFC4301] defined IP security
  • Two packet formats are defined:
  • Authentication Header (AH) in [RFC4302]
  • Integrity protection and authentication only
  • Encapsulating Security Payload (ESP) [RFC4303]
  • Also encrypts for confidentiality
  • ESP is most widely used
  • A mode of ESP defines using AES/CCM [RFC4309]
  • Suitable for use with 6LoWPAN nodes
  • The same L2 IEEE 802.15.4 hardware engine can be applied!
  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

79

slide-80
SLIDE 80

Literature

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

80

slide-81
SLIDE 81

Literature

[RFC4919] “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals”, N. Kushalnagar, G. Montenegro, C. Schumacher [RFC4944] “Transmission of IPv6 Packets over IEEE 802.15.4 Networks”, G. Montenegro, N. Kushalnagar, J. Hui, D. Culler [RFC6282] “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”, J. Hui, P. Thubert, September 2011 [RFC6775] “Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, Z. Shelby, S. Chakrabarti, E. Nordmark,

  • C. Bormann, November 2012

[RFC4861] “Neighbor Discovery for IP version 6 (IPv6)” T. Narten, E. Nordmark,

  • W. Simpson, H. Soliman

[RFC2463] “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, A. Conta, S. Deering [RFC793] “Transmission Control Protocol”, J. Postel [RFC768] “User Datagram Protocol” J. Postel [RFC3819] “Advice for Internet Subnetwork Designers”, P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood [RFC4443] “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, A. Conta, S. Deering, M. Gupta, March 2006 [RFC2373] “IP Version 6 Addressing Architecture”, R. Hinden, S. Deering, July 1998

  • Prof. Dr. Mesut Güneş ・ 6. 6LoWPAN

81