Mika Hämäläinen
6LOWPAN JA INTERNET OF THINGS
Tekniikan ja luonnontieteiden tiedekunta
Kandidaatintyö
05/2021
TIIVISTELMÄ
Mika Hämäläinen: 6LoWPAN ja Internet of things Kandidaatintyö
Tampereen yliopisto
Teknisten tieteiden TkK-tutkinto-ohjelma, Automaatiotekniikka 05/2021
Internet of Things, eli esineiden internet, on nopeimmin kasvava osa Internetiä ja koostuu enimmäkseen ilman ihmisen valvontaa toimivista laitteista. Osan esineiden internetistä muodostavat pienitehoisien laitteiden langattomat verkot. Suurella osalla näistä on vielä käytössä IP:n (engl. Internet protocol) neljäs versio, mutta sen 32-bittiset osoitteet loppuvat väistämättä Internetin kasvaessa. Tällöin joudutaan ottamaan käyttöön 128-bittinen IPv6.
Pienitehoisista langattomista verkoista, jotka käyttävät IPv6-protokollaa, käytetään nimitystä 6LoWPAN (engl. IPv6 over low-power wireless area networks).
6LoWPAN-verkoille on tehty paljon kehitystyötä. Kehitys vauhdittui huomattavasti, kun Internet Engineering Task Forcen avoin 802.15.4-radiostandardi julkaistiin. Se mahdollistaa langattoman tiedonsiirron pienillä tehoilla, sisältää vahvan salauksen ja pitää avoimena millaisia tekniikoita sen päälle voidaan rakentaa. 802.15.4-standardi toimii siis hyvänä alustana
monenlaiselle jatkokehitykselle 6LoWPAN-verkkoja varten, mutta 6LoWPAN-verkot voivat nykyään toimia myös monen muun radiotekniikan päällä.
Työn tarkoituksena on selvittää kirjallisuustutkimuksen keinoin tärkeimpiä standardeja joita 6LoWPAN-verkoille on kehitetty ja muita samaa teknistä ongelmaa varten kehitettyjä tekniikoita.
Myös hieman erilaiseen tarkoitukseen kehitettyjä LPWAN (engl. low power wide-area network) - verkkoja voidaan käyttää osittain samoihin käyttötapauksiin. Työssä kerrotaan lyhyesti
muutamasta suurimmasta erilaisesta LPWAN-verkosta. Lopulta spekuloidaan tulevatko 6LoWPAN-tyyppiset verkot vielä jatkossakin olemaan osa esineiden internetiä, vai onko joku toinen teknologia viemässä niiden paikan.
Työn tuloksena saatiin selville, että 6LoWPAN-tekniikan on mahdollista selvitä myös tulevaisuudessa, koska sitä on mahdollista käyttää monen erilaisen radiotekniikan päällä ja se on jo käytössä laajalle levinneissä kaupallisissa tuotteissa. IPv6-osoitteiden laajempi
käyttöönotto saattaa myös lisätä 6LoWPAN-tyyppisten verkkojen suosiota.
Avainsanat: 6LoWPAN, IoT, Internet of things, esineiden internet
ALKUSANAT
Kiitos kaikille, jotka ovat olleet mukana mahdollistamassa etäopiskelua näissä poikkeusoloissa. Kiitos myös Mikko Salmenperälle ohjauksesta ja Suvi Pelliselle palautteesta kieliasuun liittyvissä asioissa.
Tampereella 3.5.2021 Mika Hämäläinen
SISÄLLYSLUETTELO
1. JOHDANTO ... 1
1.1 Tutkimusongelma ... 2
1.2 Metodologia ... 2
1.3 Työn rakenne ... 2
1.4 Mikä on 6LoWPAN-verkko ... 3
2. 6LOWPAN-VERKON HAASTEET... 5
2.1 Virrankulutus ... 5
2.2 Liikkuvuus ja reitittäminen ... 5
2.3 Boottaaminen ja alustaminen ... 6
2.4 Turvallisuus ... 6
3. 6LOWPAN-STANDARDIT ... 7
3.1 Fyysinen ja linkkitaso ... 8
3.1.1IEEE 802.15.4 -radio ... 9
3.1.2 Muita linkki- ja fyysisen tason tekniikoita ... 10
3.2 LoWPAN-sovituskerros ... 11
3.3 Pakkaus ... 12
3.3.1 LOWPAN_HC ... 12
3.3.2Kohti geneerisempää pakkaustapaa ... 13
4.REITITYS ... 15
4.1 RPL-reititysprotokolla ... 16
4.2 AODV ... 17
4.3 Link state routing -protokollat ... 17
5.TURVALLISUUS ... 19
5.1 Fyysiset hyökkäykset ... 19
5.2 6LoWPAN-kerroksen fragmentaation hyödyntäminen ... 20
5.3 Reititysalgoritmeja hyödyntävät hyökkäykset ... 21
5.4 Sybil-hyökkäys ... 22
6.SOVELLUSESIMERKKEJÄ ... 23
6.1 Zigbee IP ... 23
6.2 Thread ja Openthread ... 24
6.3 Project Connected Home over IP ... 25
6.4 San Leandron älykkäät katuvalot ... 26
6.5 ISA-100 Wireless ... 26
7.MUITA VAIHTOEHTOJA ... 28
7.2 Zigbee ... 28
7.3 Bluetooth ... 28
7.4 Z-Wave ... 29
7.5 Wi-Fi HaLow ... 30
7.6 LPWAN-verkot ... 30
7.6.1Sigfox ... 31
7.6.2LoraWan ... 31
7.6.3 Nb-IoT ... 32
7.7 WirelessHART ... 32
8.YHTEENVETO ... 34
9.LÄHTEET ... 35
LYHENTEET JA MERKINNÄT
3GPP 3rd Generation Partnership Project
6lo IPv6 over Networks of Resource-Constrained Nodes (IETF:n työryhmä)
6LoWPAN IPv6 over low-power wireless area networks 6LoWPAN-GHC 6LoWPAN Generic Header Compression
AES Advanced Encryption Standard
Bluetooth LE Bluetooth Low Energy
CSMA Carrier Sense Multiple Access
CSS Chirp Spread Spectrum
DECT ULE DECT Ultra Low Energy
DTLS Datagram Transport Layer Security EDDL Electronic Device Description Language
ETSI European Telecommunication Standards Institute
FFD Full-function device
HART Highway Addressable Remote Transducer HTTP Hypertext Transfer Protocol
ICMPv6 Internet Control Message Protocol version 6 IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers
IEEE 802.15.4 IEEE:n julkaisema standardi fyysiselle- ja linkkikerrokselle IETF Internet Engineering Task Force
IoT Internet of Things
IP Internet Protocol
IPsec IP Security Architecture
J-PAKE The Password Authenticated Key Exchange by Juggling LoRaWAN Long Range Wide Area Network
LoWPAN Low Power Wireless Area Network LoWPAN_HC LoWPAN Header Compression LPWAN Low Power Wide Area Network
LTE Long Term Evolution
LTE-M Long Term Evolution Machine Type Communication LPWAN Low-Power, Wide Area Network
LZ77 Lempel-Ziv
MAC Medium Access Control
MANET Mobile Ad-hoc Networks (IETF:n työryhmä)
MPR Multi Point Relay
MS/TP Master-Slave/Token Passing Nb-IoT Narrowband Internet of Things
NFC Near Field Communication
OLSR Optimized Link State Routing protocol PPDU Physical Protocol Data Unit
ROLL Routing Over Low power and Lossy Networks (IETF:n työryhmä)
RFC Request for Comments
RFD Reduced-function device
RPL IPv6 Routing Protocol for Low-Power and Lossy Networks RTP Real-time Transport Protocol
TCP Transmission Control Protocol TDMA Time Division Multiple Access TSCH Time Slotted Channel Hopping
UDP User Datagram Protocol
1. JOHDANTO
Internetiin liitettyjen laitteiden määrä on kasvanut viime vuosina räjähdysmäisesti, ja tämä trendi luultavasti tulee jatkumaan edelleen lähitulevaisuudessa. Suurin osa näistä uusista laitteista ei ole enää perinteisiä tietokoneita, vaan merkittävän osan kasvusta muodostavat pienet laitteet, jotka ovat yhteydessä Internetiin. Näitä pieniä ja hinnaltaan yhä edullisempia laitteita löytyy muun muassa teollisuudesta sensoriverkkoina valvomassa prosessien ja laitosten turvallisuutta, kotiautomaatiossa, logistiikassa, sekä mobiileissa laitteissa, kuten autoissa. Useamman ennusteen mukaan tämä trendi ei tule kääntymään, vaan Internetiin liitettyjen laitteiden ja pöytäkoneiden suhde tulee olemaan yhä enemmän laitteiden puolella. Tästä laitteiden valtaamasta osuudesta Internetistä puhutaankin esineiden Internetinä (Internet of things).
Esineiden Internetin kasvuennusteet ovat olleet erittäin vaihtelevia ja tulevaisuuden ennustaminen nopeasti kehittyvällä kentällä on tunnetusti aina vaikeaa. Merkittävät IT- alan toimijat, Cisco ja Ericsson, ennustivat 2010-luvun alussa, että vuonna 2020 esineiden Internetissä olisi yli 50 miljardia laitetta [8] [41]. Vuonna 2018 laitteiden määrä oli vasta lähempänä 17 miljardia. Tähän jos ottaa vielä mukaan matkapuhelimetkin, ei luku silti pääse lähellekään näitä ennusteita [19]. Kasvu on kuitenkin ollut huomattavaa ja sellaisia ennusteita on vaikea löytää varteenotettavista lähteistä, joiden mukaan se olisi hiipumassa.
Monesti halutaan, että Internetiin liitetty laite on myös tavoitettavissa itsenäisesti, julkisen Internetin kautta, oman IP-osoitteen avulla. Tätä varten se tarvitsee oman uniikin IP-osoitteen. Uniikkeja 32-bittisiä IPv4-osoitteita voidaan generoida vain hieman yli 4 miljardia kappaletta, minkä takia ne tulevat loppumaan lähitulevaisuudessa. Tähän ongelmaan on luotu ratkaisuksi 128-bittinen IPv6, josta IETF (Internet Engineering Task Force) teki virallisen standardin vuonna 2017 [7]. Tällä tavalla saadaan luotua jo 2128 uniikkia osoitetta, mutta luonnollisena seurauksena myös verkossa liikkuvien pakettien otsikkokentän tulee olla pidempi, mikä kasvattaa liikenteen kokonaismäärää.
Monet näistä laitteista, joiden toivotaan olevan muun Internetin kautta tavoitettavissa, ovat niin pienikokoisia ja -tehoisia, että tästä suuremmasta liikenteen määrästä muodostuu niiden suunnittelulle merkittäviä haasteita. Koska alan markkinat ovat kasvaneet huomattavasti lähiaikoina, on ollut painetta kehittää uusia ratkaisuja näihin ongelmiin.
Näille pienille, IPv6-protokollalla Internetiin liitetyille laitteille, jotka pystyvät keskenään muodostamaan langattoman, 6LoWPAN-verkoksi kutsutun lähiverkon, kehitettiin IETF:n työryhmissä monia uusia, avoimia standardeja 2000-luvun alusta lähtien. Osa näistä otettiin laajasti käyttöön, mutta osa jäi kokeellisiksi ja lähinnä akateemisen kiinnostuksen kohteiksi. Näistä vuosista eteenpäin ala on kasvanut kiihtyvällä vauhdilla eteenpäin.
Uusia sovellusalueita, rautaa ja erilaisia protokollia on kehitetty, joista osa rakentuu alkuperäisten IETF:n työryhmien standardien päälle ja osa vaihtoehdoiksi samaa toiminnallisuutta toteuttamaan.
1.1 Tutkimusongelma
Työssä selvitetään, millaisia tärkeimpiä standardeja on lähivuosina kehitetty IPv6- kytkentää käyttäville pienitehoisille langattomille lähiverkoille, eli 6LoWPAN-verkoille.
Työssä kerrotaan myös pintapuolisesti, miten tälläiset verkot toimivat ja millaisia turvallisuusongelmia niiden kanssa on kohdattu. Lisäksi esitellään muutamia vaihtoehtoisia tekniikoita liittää joukko pienitehoisia laitteita, jotka muodostavat langattoman verkon, esimerkiksi sensoriverkko, osaksi esineiden Internetiä. Myös näihin standardeihin pohjautuvia jatkokehityksiä esitellään.
Tarkoituksena on selvittää, ovatko 6LoWPAN-standardit varmistaneet paikkansa osana nykyistä ja lähitulevaisuuden esineiden Internetiä. Tulevaisuuteen vaikuttavia tuntemattomia muuttujia on liian monta, jotta sitä voisi ennustaa. Voidaan kuitenkin tutkia, millaisia muita tekniikoita on jo laajalti markkinoilla, mitkä pystyisivät täyttämään 6LoWPAN:in tehtävän. Selvitetään myös, tehdäänkö kehitystyötä vielä, ja onko sen avulla parannettu mahdollisuuksia käyttää 6LoWPAN-verkkoja tulevaisuudessa.
1.2 Metodologia
Työ on tehty kirjallisuustutkimuksena. Tietoa työtä varten on kerätty tutkimalla tieteellisistä artikkeleita, IETF:n työryhmiä, sekä relevanttien yritysten ja erilaisten standardointihankkeiden verkkosivuja.
6LoWPAN-sanalla tarkoitetaan tässä työssä pienitehoista, langatonta verkkoa, jolla on IPv6-mahdollisuus. Sanalla voidaan jossain muualla myös tarkoittaa IETF:n (Internet Engineering Task Force) 6lowpan-työryhmää, mutta tässä työssä mainitaan aina erikseen, jos viitataan tähän. 6LoWPAN-sana edustaa myös kirjallisuudessa usein niitä standardeja, jotka 6lowpan-työryhmä on kehittänyt 6LoWPAN-verkoille. Niistä puhutaan tarkemmin luvussa 3.
1.3 Työn rakenne
Alussa kerrotaan, millaisia ongelmia pienitehoisilla, langattomilla, Internetiin liitetyillä verkoilla on ratkaistavana. Siitä siirrytään esittelemään, miten IETF:n julkaisemat 6LoWPAN-standardit ratkovat näitä ongelmia. Myöhemmissä luvuissa kerrotaan myös uusista kehityssuuntauksista 6LoWPAN-verkkojen parissa tehtävässä tutkimuksessa.
Näiden verkkojen kanssa on tehty paljon tutkimusta 2000-luvulla, ja tässä työssä pystytään käsittelemään vain pientä osaa siitä. Pienitehoisten langattomien verkkojen reititysprotokollat ovat saaneet merkittävän määrän tutkimusta 2000-luvulla, ja näiden tuloksena syntyneistä uusista reititysprotokollista esitellään muutama.
Turvallisuuspuolelta esitellään pintapuolisesti muutamia tapoja hyökätä 6LoWPAN- verkkoa vastaan ja miten näitä hyökkäyksiä vastaan voisi olla mahdollista puolustautua.
Työssä annetaan myös esimerkkejä, millaisia valmiita, 6LoWPAN-standardeja käyttäviä,
sovelluksia löytyy teollisuudesta ja kuluttajamarkkinoilta. Lopulta esitellään joitakin vaihtoehtoisia tekniikoita, jotka mahdollisesti pystyvät täyttämään saman tehtävän kuin 6LoWPAN.
1.4 Mikä on 6LoWPAN-verkko
6LoWPAN-verkko koostuu joukosta langattomia, pienitehoisia laitteita, jotka muodostavat tyypillisesti verkkomaisen topologian keskenään. Näillä laitteilla on uniikit IPv6-osoitteet, mikä mahdollistaa kommunikoinnin ulkomaailman kanssa IPv6- protokollalla. Yhteys ulkomaailmaan päin on mahdollista tähän tarkoitukseen erikseen tarkoitetun reunareitittimen (edge router) kautta. Jos näitä reitittimiä on vain yksi, puhutaan yksinkertaisesta LoWPAN:sta (simple LoWPAN). Mikäli reitittimiä on enemmän, ne voivat yhdistää monta yksinkertaista LoWPAN-verkkoa keskenään ja muodostaa näin jatketun LoWPAN:in (extented LoWPAN). Jatketussa LoWPAN:ssa reunareitittimien välillä on tyypillisesti nopea linkki, kuten langallinen Ethernet, ja niiden tulee toteuttaa sekä IP:n että LoWPAN:n protokollapinot. Nämä protokollapinot on kuvattu taulukkoon 1.
http RTP
TCP UDP ICMP
IP Ethernet MAC Ethernet fyysinen
Ohjelmisto Kuljetus
Verkko Linkki Fyysinen
Ohjelmistoprotokollat
UDP ICMP
IPv6 LoWPAN IEEE 802.15.4 MAC IEEE 802.15.4 fyysinen
On myös muunlaisia pienitehoisia verkkoja jotka ovat yhteydessä Internetiin, mutta 6LoWPAN-verkoksi kutsutaan sellaista jonka laitteet ovat tavoitettavissa oman IPv6- osoitteen kanssa ja verkon topologia on vapaammin muokattavissa, eli ei ole rajoitettu esimerkiksi pelkästään tähti- tai puutopologiaan. 6LoWPAN-laitteiden ei kuitenkaan tarvitse aina olla yhteydessä Internetiin, vaan ne voivat toimia myös omana verkkonaan, jolloin puhutaan ad-hoc -verkosta. [32 s. 14–15] Nämä kolme mahdollista tapausta on kuvattu kuvassa 1.
Taulukko 1: IP:n ja 6LoWPAN:n protokollapinot
Tälläistä verkkoa voidaan tarvita monenlaisessa paikassa, jossa tarvitaan helposti skaalautuvaa määrää toimilaitteiden ohjaimia ja/tai sensoreita, joiden kanssa täytyy päästä kommunikoimaan Internetin välityksellä, eikä voida tukeutua täysin käyttöpaikan omaan verkko-infraan. Esimerkiksi asunnon hälytysjärjestelmän varmasti halutaan toimivan vielä, vaikka asunnon oma Wi-Fi-reititin olisi pois päältä tai Internet- operaattorilla olisi joku ongelma.
Näitä verkkoja voi löytää esimerkiksi kodeista, tehtaista, maataloudesta tai kaupoista.
Käyttökohteita ei ole tarkasti rajattu.
Kuva 1: Esimerkkejä erilaisista LoWPAN-verkoista. R-solmut suorittavat reitittämistä.
2. 6LOWPAN-VERKON HAASTEET
Internetiin liitetyllä langattomalla laitteella, jolta vaaditaan mahdollisuutta olla yhteydessä muuhun Intenetiin, on omat haasteensa pöytäkoneeseen verrattuna. Tässä luvussa esitellään niistä tärkeimmät.
Alla listattujen yleisten haasteiden lisäksi 6LoWPAN-verkoilla on myös käyttökohteesta riippuvia erityisiä haasteita, koska niitä voidaan käyttää monissa erilaisissa ympäristössä, kuten kotiautomaatiossa, tehdashallissa, tai ulkotiloissa.
Näissä kaikissa on erilaiset haasteensa, ongelmansa ja mahdollisesti myös laitteiston valmistus- ylläpito- ja asennuskustannuksiin liittyvät rajoitteensa.
2.1 Virrankulutus
Akkujen kesto, ja sitä kautta virrankulutus, on merkittävä rajoitus, kun puhutaan pienikokoisista langattomista laitteista. Tämä on totta, varsinkin jos niiden tulee olla yhteydessä Internetiin. Mahdollisimman hyvä tavoitettavuus, joka on IP-protokollan oletus, vaatii laitteilta mahdollisimman vähän energiaa säästävää nukkumisaikaa, mutta energiansäästön kannalta olisi hyvä pystyä olemaan lepotilassa mahdollisimman suuri osa ajasta. [32 s. 5]
Suuren sensoriverkon ylläpitoa hankaloittaa merkittävästi, jos laitteiden akut tai paristot täytyy ladata usein. Tähän voidaan käyttää ratkaisuna ympäristön tarjoaman energian, esimerkiksi aurinkoenergian tai jonkin laitteen tuottaman lämmön, hyödyntämistä. Tosin, teollisuuskäytössä olevat laitteet sijaitsevat monesti sisätiloissa, eikä auringonvalon saatavuuteen ole aina luottamista.
Pidemmän IP-osoitteen haittapuolena on siirrettävien pakettien koon kasvaminen, koska osoite täytyy yleensä lähettää jokaisen paketin mukana. Tämä tuottaa ongelmia, kun käytetään pieniä laitteita, joilta vaaditaan matalaa energiankulutusta, esimerkiksi osana älykästä sensoriverkkoa
2.2 Liikkuvuus ja reitittäminen
Langattoman verkon laitteiden paikat ovat monesti liikkeessä. Ne saattavat sijaita liikkuvissa laitteissa, jotka voivat liikkua välillä kokonaan muiden verkon laitteiden kantaman ulkopuolelle. Fyysistä topologiaa voidaan myös haluta muuttaa, jos vaikka halutaan mittauksia eri paikoista tuotantolaitosta. Langattoman signaalin kantavuus voi myös vaihdella. Esimerkiksi metallinen ovi, jonka kummallakin puolella on yksi langaton laite, saatetaan välillä sulkea ja avata, minkä seurauksena laitteet ovat välillä verkon näkökulmasta vierekkäin ja välillä saavutettavissa vain monen hypyn kautta. Joskus
voidaan haluta, että joku laite siirtyy jopa kokonaan toisen LoWPAN-verkon alueelle ja pystyy siellä kommunikoimaan edelleen myös Internetiin päin.
Pienet, itsenäiset, langattomat laitteet ovat myös herkempiä vikaantumaan, esimerkiksi pariston loppumisen takia ja ne voivat sijaita paikoissa, joihin ei aina päästä tekemään korjauksia nopealla aikataululla. Myös tämä muuttaa verkon topologiaa ja pakottaa mahdollisesti muuttamaan reittejä, joita pitkin data kulkee verkossa. [32 s. 93]
Iso osa Internetistä käyttää edelleen IPv4-protokollaa ja monesti tarkoituksena on, että 6LoWPAN-verkon laitteet pystyvät kommunikoimaan myös näiden palvelimien tai asiakkaiden kanssa.
2.3 Boottaaminen ja alustaminen
Monet myynnissä olevat 6LoWPAN-laitteet ovat sen verran geneerisiä, että niihin ei ole suoraan tehtaalla asennettuna loppukäyttäjän haluamaa ohjelmistoa, vaan se täytyy saada asennettua jokaiseen laitteeseen erikseen.
Myös tarvittavat kryptografiset avaimet täytyy saada jollakin tavalla toimitettua verkon laitteille. Tämän voi tehdä joko manuaalisesti, fyysisen yhteyden yli, lataamalla avain jokaiselle laitteelle erikseen. Tämä menetelmä vie paljon aikaa ja vaatii tarkoitusta varten fyysisen portin, jota ei ehkä muuten olisi laitteessa, mikä lisää tuotantokustannuksia. Avaimet olisi mahdollista siirtää myös langattomasti, mutta tällöin haasteena on salakuuntelu, tai tiedon korruptoiminen.
Koska 6LoWPAN-verkon laitteet toimivat monesti paristoilla, tulee väistämättä eteen myös tilanteita, joissa paristo täytyy vaihtaa. Yksinkertaisessa laitteessa tämä toimenpide saattaa samalla myös nollata muistin, jonka jälkeen laitteen täytyy kuitenkin pystyä edelleen suoriutumaan tehtävästään. Laitteen tulee siis löytää itsensä taas osana verkkoa, löytää lähimmät naapurinsa ja pystyä jatkamaan toimintaansa sopivasta tilasta.
[32 s. 63–65]
2.4 Turvallisuus
Internetiin liitettyjen laitteiden kanssa turvallisuus on aina otettava huomioon järjestelmää suunniteltaessa. Pienissä laitteissa on kuitenkin se haitta, että ei ole aina mahdollista toteuttaa pöytäkoneita varten suunniteltuja turvallisuustandardeja sellaisenaan, koska ne veisivät liikaa muistia, kaistaa ja/tai prosessoritehoa.
On myös helpompi päästä fyysisesti käsiksi johonkin verkon laitteista, koska ne ovat pienikokoisia ja voivat sijaita myös paikoissa, joissa ei ole ympärivuorokautista valvontaa. Tämän takia potentiaalisen tunkeutujan lisäksi myös ympäristön vaikutukset voivat osoittautua uhaksi, kun kosteus ja lämpötila vaihtelevat päivän myötä, ulos sijoitetuilla laitteilla. Jos oikein huono onni käy, myös eläimet voivat kiinnostua laitteista ja aiheuttaa vahinkoa.
3. 6LOWPAN-STANDARDIT
Tarve ratkaista edellisessä luvussa mainittuja ongelmia on ollut tiedossa jo pidemmän aikaa, mutta vielä 2000-luvun alussa ei ollut tarjolla kunnollisia avoimia standardeja ratkaisuiksi näihin ongelmiin. Vuonna 2003 julkaistu IEEE 802.15.4 -standardi loi pohjan, joka kiihdytti 6LoWPAN-verkkojen standardointia, koska se oli ensimmäinen maailmanlaajuinen standardi pienitehoisien langattomien verkkojen fyysiselle ja linkkikerrokselle. Tästä enemmän seuraavassa luvussa.
Melko pian 802.15.4-standardin julkaisun jälkeen, vuonna 2005, IETF:n 6lowpan- työryhmä perustettiin luomaan avoimia standardeja ratkaisuna edellisessä luvussa esitettyihin ongelmiin. [32 s. 6] Vuonna 2007 työryhmä julkaisi RFC (Request for Comments) 4494-standardiehdotuksen, joka määritteli tavan, jolla IPv6-datagrammeja voidaan lähettää IEEE 802.15.4 -verkon yli pakattuna. Standardiehdotuksessa määriteltiin myös keino luoda linkkitason osoitteita ja IPv6-osoitteita automaattisesti.
Ehdotuksessa määriteltiin ensimmäistä kertaa 6LoWPAN-sovituskerros, jonka avulla IPv6-paketit saadaan lähetettyä 802.15.4-radion yli pakattuina ja palasteltuina. Tätä standardiehdotusta on käytetty pohjana suurelle määrälle jatkokehitystä, mutta siihen on myös myöhemmin tehty paljon korjauksia uusien RFC-julkaisujen muodossa. [26]
Vuonna 2011 6lowpan-työryhmä julkaisi standardiin päivityksen RFC 6282, joka ehdotti parannuksia RFC 4944:n IPv6-pakettien pakkausalgoritmiin, sekä monta muutakin parannusehdotusta [14]. Pakkausalgoritmeistä kerrotaan enemmän alaluvussa 3.3.
Vuonna 2012 6lowpan-työryhmä julkaisi taas päivityksen standardiehdotukseen, RFC 6775:n, jossa ehdotettiin yksinkertaisia parannuksia IPv6-protokollan neighbour discovery -ominaisuuteen, eli tapaan, jolla laitteet löytävät naapureita linkkitason yhteyksien muodostamista varten. Alkuperäisessä IPv6:n neighbour discovery - protokollassa määriteltiin monta tärkeää ominaisuutta, joita tarvitaan verkkoon liityttäessä. Tälläisiä olivat esimerkiksi osoitteiden luominen, moninkertaisten verkko- osoitteiden havaitseminen, reitittimien löytäminen ja verkon parametrien löytäminen.
Siinä ei kuitenkaan ollut otettu huomioon kaikkia langattomien verkkojen erityispiirteitä.
IPv6:n neighbour discovery -protokollan moninkertaisten verkko-osoitteiden havainnointi esimerkiksi oletti, että verkon laitteet ovat aina tavoitettavissa. Tämä ei pidä usein paikkaansa langattomien, pienitehoisten verkkojen kanssa. IPv6:n neighbour discovery käytti myös runsaasti multicast-toimintoa, joka syö paljon resursseja. RFC 6775 määritteli myös optimisaatioita kaksinkertaisten osoitteiden löytämistä varten, koska IPv6:n tavassa tehdä tämä on tehty samankaltaisia oletuksia verkon toiminnasta kuin neigbour discovery -protokollan kanssa. [32 s. 21] [33]
Vuonna 2012 6LoWPAN-sovituskerroksen katsottiin olevan valmis ja 6lowpan- työryhmä suljettiin. Kommunikaatioteknologian kehitys ei kuitenkaan ollut pysähtynyt, joten uusia fyysisen ja linkkitason tekniikoita oli tullut ja oli edelleen tulossa markkinoille.
Näiden uusien tekniikoiden päällä toimivalle IPv6-protokollalle oli kysyntää. Tästä syystä
jo vuonna 2013 päätettiin perustaa uusi työryhmä, 6lo (IPv6 over Networks of Resource- Constrained Nodes), sovittamaan 6lowpan-työryhmän kehittämiä tekniikoita uusille alustoille ja tarvittaessa päivittämään vanhoja standardeja. 6Lo-työryhmä sai luotua 6LoWPAN-tyyppiset sovituskerrokset monille tekniikoille, joista enemmän alaluvussa 3.1.2. [10]
IoT-kentällä on samalla huomattu myös jatkuvan standardointi- ja yhteensovittamistyön lisäksi tekniikoiden erikoistumista. Suurimpana esimerkkinä LPWAN (Low-Power Wide Area Network) -tekniikka. LPWAN-verkot toimivat huomattavasti pienemmillä lähetysnopeuksilla ja yleensä suuremmilla lähetysetäisyyksillä kuin 6LoWPAN-verkot. Linkit voivat olla myös epäsymmetrisiä eli lähetysnopeus ja vastaanottonopeus ovat eri suuret. Siksi 6LoWPAN-sovituskerroksen toteuttaminen ei tämän tyyppisiin verkkoihin ole aina mahdollista. [10]
Tässä mainitut 6lowpan- ja 6lo-työryhmien julkaisemat standardit ovat oikeastaan standardiehdotuksia eivätkä vielä virallisesti standardeja. IETF ei aseta standardiehdotuksille niin suuria vaatimuksia kuin varsinaisille standardeille. Niiden ei tarvitse olla yhtä stabiileja, eikä niillä tarvitse olla vielä muuta kuin akateemista käyttöä.
Alun perin IETF:n standardiehdotuksien oli tarkoitus kehittyä standardiksi asti, mutta tästä on nykyään luovuttu. Usein jo standardiehdotus otetaan teollisuudessa laajasti käyttöön ja kehittyy pisteeseen, jossa siinä ei ole teknisiä puutteita vaatimustensa täyttämisessä, ennen kuin se etenee IETF-standardiksi asti. Ehdotukseksi jättäminen mahdollistaa kuitenkin helpommin uusien versioiden julkaisun, jos uusia ongelmia tai parempia ratkaisuja löydetään. [22]
3.1 Fyysinen ja linkkitaso
Vuonna 2007 julkaistussa RFC 4494 -standardissa määriteltiin perusvaatimuksia linkkikerroksen teknologialle:
• lähetettävän tiedon pilkkominen paketteihin, joissa on otsikko-osa, eli framing
• unicast-lähetys, eli vain yhdelle vastaanottajalle tarkoitettu lähetys
• linkkikerrostasolla täytyy olla osoitteet (addressing).
[26]
IEEE 802.15.4 -standardi 2,4 GHz:n langattomille laitteille oli aluksi 6LoWPAN- standardin oletusteknologia fyysiselle ja linkkikerrokselle, mutta jätettiin auki myös mahdollisuus käyttää sitä muiden pohjateknologioiden kanssa. Niiden täytyy vain täyttää yllä mainitut pohjavaatimukset. Tätä mahdollisuutta on myöhemmin myös hyödynnetty, mistä enemmän alaluvussa 3.1.2.
3.1.1 IEEE 802.15.4 -radio
IEEE 802.15.4 on IEEE 802.15 -työryhmän kehittämä standardi, joka mahdollistaa kommunikoinnin radion välityksellä, erittäin pienellä teholla ja valmistuskustannuksiltaan edullisella laitteistolla. Standardi käsittelee fyysistä ja linkkikerrosta eikä ota kantaa ylempien protokollapinon kerrosten toimintaan. [32 s. 18] Standardin päälle onkin rakennettu monenlaisia teknologioita, ja se on laajasti käytetty.
Fyysistä kerrosta käsittelevä osuus määrittelee, miten tiedon lähettäminen ja vastaanottaminen käytännössä tapahtuu. Se siis määrittelee muun muassa käytettäviä taajuuksia, niiden vaihtamiseen liittyviä sääntöjä ja maksimisiirtonopeuksia. Osuutta on vuosien mittaan laajennettu, jotta standardi on saatu käsittämään useampia taajuusalueita.
Linkkikerrosta käsittelevä osio on erityisen kiinnostava 6LoWPAN-standardin kannalta, koska se luo monia rajoitteita, joita 6LoWPAN-standardien määrittelyssä on noudatettu, ja määrittelee myös hyödyllisiä ominaisuuksia. Näistä eräs tärkeimmistä on 128-bittinen AES (Advanced Encryption Standard) -suojaus. [16]
IEEE 802.15.4:n mukainen verkko voi olla järjestetty joko tähti- tai verkkotopologiaan.
Tähtitopologiassa yksi laite toimii kontrollerina, johon kaikki muut laitteet ovat yhteydessä ja verkkotopologiassa laitteet voivat olla yhteydessä toisiinsa lähes mielivaltaisessa topologiassa, jota rajoittaa lähinnä vain radion kantomatka.
Verkossa oleva laite voi olla asetettu toimimaan joko RFD (reduced-function device) tai FFD (full-function device) -tilassa. Ensin mainitussa tilassa laite toimii verkon jäsenenä vain rajoitetulla tavalla ja kuluttaa myös vähemmän resursseja. Se toimintatapa sopii laitteelle, jonka rooli verkossa on yksinkertainen, kuten infrapunasensori, joka vain lähettää dataa eteenpäin yhden toisen solmun kautta. Jälkimmäisessä mainitussa tilassa laite on verkon jäsen, jolla on enemmän mahdollisuutta vaikuttaa verkon toimintaan, ja se myös välittää muiden verkon solmujen viestejä eteenpäin.
IEEE 802.15.4 tukee kanavoiden jakamiseen nykyään sekä TDMA- (Time Division Multiple Access) että CSMA (Carrier Sense Multiple Access) -tekniikoita. Ensin mainitussa lähetyksien lähettämiseen ja vastaanottamiseen on varattu tietty määrä ennalta määrätyn kokoisia aikalohkoja. Tämä helpottaa verkon laitteiden virransäästön optimointia, koska laitteet voivat helpommin ennustaa milloin oma lähetysvuoro tulee.
Näin vältytään sellaisilta yhteentörmäyksiltä, joissa useampi laite koittaa lähettää samaan aikaan samalla taajuudella. Jälkimmäisellä tavalla laitteet tunnustelevat sopivaa hetkeä lähettää kuuntelemalla muiden laitteiden lähetyksiä, ja yhteentörmäyksiä saattaa syntyä. Myös 6LoWPAN tukee nykyään kumpaakin tapaa.
Vuonna 2013 perustettu IETF:n 6TiSCH (IPv6 over the TSCH [Time Slotted Channel Hopping] mode of IEEE 802.15.4e) -työryhmä on kehittänyt standardia eteenpäin lisäämällä siihen ominaisuutena ajoitettuun taajuuden vaihteluun perustuvan kommunikaation. Sitä voidaan käyttää väistämään törmäyksiä, kun liikennettä samoilla taajuusalueilla on paljon. [10]
3.1.2 Muita linkki- ja fyysisen tason tekniikoita
6Lo-työryhmän ja heidän yhteistyökumppaniensa työn ansiosta 6LoWPAN- sovituskerros on saatu sovitettua yhä useammalle alemman protokollapinon tason tekniikalle. Tässä näistä muutama esimerkki.
- Bluetooth LE (Low Energy): Versio Bluetoothista, joka käyttää vähemmän energiaa, jotta sitä voitaisiin käyttää pienitehoisissa, patterikäyttöisissä laitteissa.
Bluetooth LE -tuki löytyy myös useimmista uusissa älypuhelimissa, joten tekniikalla on paljon potentiaalisia käyttäjiä. RFC 7668 määrittelee IPv6:n Bluetooth LE:n yli. [10]
- ITU-T G.9959 (Z-Wave): Z-Wavella on jo suuri käyttäjäkunta kotiautomaatiossa, koska se tuli markkinoille jo yli 10 vuotta sitten. Se alkoi suljettuna ratkaisuna, mutta vuonna 2012 määrittely julkaistiin G.9959-nimisenä. 6Lo on julkaissut RFC 7428 standardiehdotuksen, joka määrittelee IPv6:n Z-Waven yli. [10]
- DECT ULE (Ultra Low Energy): DECT-radiorajapintaa on käytetty jo yli kahden vuosikymmenen ajan langattomiin puheluihin ja tiedonsiirtoon sisätiloissa. ETSI (European Telecommunications Standards Institute) standardoi tästä vuonna 2013 version nimeltään DECT ULE, joka on tarkoitettu langattomiin, pienitehoisiin verkkoihin, mutta säilyttää kuitenkin yhteensopivuuden DECT-rajapinnan käyttämän fyysisen kerroksen kanssa. Tämä mahdollistaa sen käyttämisen monissa sellaisissa käyttökohteissa, jotka käyttävät jo entuudestaan DECT- radiorajapintaa. Näihin olisi mahdollista asentaa tulevaisuudessa DECT ULE - versio. 6Lo-työryhmä on julkaissut RFC 8105 -spesifikaation, jossa määritellään IPv6 DECT ULEn yli. [10]
- MS/TP (Master-Slave/Token Passing): MS/TP määrittelee MAC (Medium Access Control) -mekanismin RS-485:n fyysisen yhteyden päälle. Tämä linkki- ja fyysisen kerroksen yhdistelmä on yleinen rakennusautomaatiossa. MS/TP eroaa muista tämän kappaleen tekniikoista siten, että siinä verkon laitteilla on käytössään kiinteä voimanlähde, jonka takia ne eivät ole siltä osin resursseiltaan rajoitettuja. MS/TP -verkoissa on kuitenkin rajoitetut tiedonsiirtonopeudet, ja verkon laitteet ovat usein muistiltaan ja laskentatehoiltaan vaatimattomia. 6Lo- työryhmä on julkaissut RFC 8163 spesifikaation, jotta MS/TP -verkot voivat myös hyötyä IPv6:sta. [10]
- NFC (Near Field Communication): NFC on kokoelma standardeja lyhyen etäisyyden langatonta tiedonsiirtoa varten. NFC-laitteiden myynti lasketaan vuosittain sadoissa miljoonissa, joten teknologia on jo laajasti käytössä. 6Lo- työryhmä on kehittämässä tapaa siirtää IPv6-paketteja NFC:n yli. [10]
- IEEE 1901.2 (Power line communications): PLC on ollut jo vuosikymmeniä teollisuuden käytössä, ja IEEE 1901.2 on vuonna 2013 hyväksytty standardi siitä, joka on tähdätty älykkäiden voimansiirtoverkkojen käyttöön. Näissä verkoissa tiedonsiirto joutuu erilaisten haasteiden pariin, koska signaalin suhde kohinaan voi olla erittäin huono. Tämän takia PLC-verkoilla on myös yhteistä langattomien, pienitehoisten verkkojen kanssa, koska myös langattomilla verkoilla on suuri virheprosentti tiedonsiirrossa. 6Lo-työryhmä on julkaissut ehdotuksen siitä, miten IPv6-paketteja voidaan siirtää IEEE 1901.2 -verkon yli, vaikka IEEE 1902.2 -
standardissa itsessäänkin on ohjeet siitä, miten IEEE 1902.2- verkon saa toimimaan myös IPv6-verkkona. [10]
- IEEE 802.11ah: IEEE 802.11ah on lisäys IEEE 802.11 -standardiin, joista jälkimmäisenä mainitusta käytetään yleisesti myös nimitystä Wi-Fi. Sen on tarkoitus päivittää Wi-Fi:n standardia tukemaan myös pienitehoisia sensoriverkkoja ja erityisesti parantamaan mittarointiverkkojen tiedonkeräystä. Se ei kuitenkaan ole taaksepäin yhteensopiva, joten ei voi heti käyttää täysimittaisesti hyödyksi vanhojen Wi-Fi-reitittimien suurta määrää. 6Lo-työryhmä on kehittämässä IPv6-tukea IEEE 802.11ah:lle. [10]
3.2 LoWPAN-sovituskerros
Tavallinen Ipv6 vaatii, että käytössä on myös multicast-mahdollisuus, mutta 6LoWPAN ei vaadi tätä linkkitasolta. Broadcast-ominaisuus on riittävä. [32 s. 17]
IPv6-standardi vaatii, että linkkikerroksen MTU (maximum transmission unit) on vähintään 1280 oktettia. Tämän takia IPv6-paketit eivät sellaisenaan mahdu IEEE 802.15.4 -kehykseen. 6LoWPAN ratkaisee tämän LoWPAN adaptation layer - kerroksella, joka sijoittuu protokollapinossa linkkikerroksen ja IPv6-kerroksen väliin. Tällä kerroksella IPv6-paketit pilkotaan fyysiselle ja linkkikerrokselle sopiviksi paloiksi ja niiden kokoa pienennetään edelleen pakkaamalla. [26]
6LoWPAN:in protokollapino näyttää lähes vastaavalta kuin perinteisen Ethernet- pohjaisen IP:n protokollapino. Se on tarkoitettu käytettäväksi ainoastaan IPv6 kanssa.
Suurimpana muutoksena siinä on linkkikerroksen ja IP-kerroksen välillä LoWPAN adaptation layer -sovituskerros, joka mahdollistaa IPv6:n toiminnan IEEE 802.15.4:n fyysisen ja linkkikerroksen kanssa. Tämä tarvitaan, koska IEEE 802.15.4 -standardissa pakettien maksimikoko on huomattavasti pienempi kuin IPv6:ssa. Paketteja täytyy siis pilkkoa kuljetusta varten. Sovituskerros myös pakkaa lähetettävää tietoa, mikä myös osaltaan säästää pienitehoisien laitteiden rajallista tehoa verkossa.
6LoWPAN:in kanssa käytetään harvoin TCP-lähetyksiä (transmission control protocol) suorituskykyyn ja monimutkaisuuteen liittyvistä syistä. UDP (user datagram protocol) on yleisemmin käytössä oleva kuljetustason protokolla.
Alkuperäisen 6LoWPAN-standardin julkaisemisen jälkeen 6LoWPAN-verkoille on tehty paljon uutta tutkimusta, ja nykyään TCP:n käyttö kuljetuskerroksessa on yhä yleisempää myös pienen tehon laitteissa. Ohjelmistokerrokselle on myös kehitetty sellaisia protokollia, joiden avulla saadaan tarvittaessa lähetettyä viestejä luotettavamminkin, mutta 6LoWPAN-standardissa ei oteta niihin kantaa, koska se käsittelee alemman tason asioita.
3.3 Pakkaus
IPv6-paketit ovat pienimmillään vain 40 tavun kokoisia, jolloin ne sisältävät pelkästään otsikkotiedon, eikä näin pienestä paketista luultavasti olisi mitään käytännön hyötyä.
Teoriassa IPv6-paketin koko saattaa olla jopa yli 65 000 tavua, jolloin monella verkolla olisi jo ongelmia käsitellä näin isoa pakettia.
Jokaisessa paketissa täytyy olla mukana otsake. Jos sen kokoa saadaan pienennettyä hävittämättä pakettien välityksen tai reitityksen kannalta välttämätöntä tietoa, saadaan verkossa lähetettävän tiedon määrää huomattavasti pienennettyä.
Tämän tavoitteen saavuttamiseksi onkin tehty paljon tutkimusta, ja useampi erilainen tapa pakata otsikkokenttiä on kehitetty. [32 s. 41]
Taulukossa 2 kuvatussa IPv6-otsakkeessa tulee mukana paljon sellaista tietoa, joka voidaan 6LoWPAN-verkossa päätellä, eikä sitä siten tarvitse kuljettaa mukana jokaisessa paketissa. Kaikilla yhteen tiettyyn 6LoWPAN-verkkoon liittyneillä laitteilla on joitakin samoja tiloja, joita voidaan hyödyntää pakkauksessa. [26]
Versio luokka vuon tunniste
kuorman pituus seuraava otsikko elinaika Lähdeosoite
Kohdeosoite
Tämä luku keskittyy esittelemään muutamia kehitysaskeleita otsikkokentän pakkauksessa, nimenomaan 6LoWPAN-verkkoihin liittyen. Kovin syvälle teknisiin yksityiskohtiin ei tässä työssä mennä, mutta pakkaustapoihin liittyvät standardit ovat julkisesti saatavilla.
3.3.1 LOWPAN_HC
Vuonna 2007 ilmestyneen 6LoWPAN-standardin, RFC 4955:n, mukaisessa LOWPAN_HC1-pakkaustavassa (HC tulee sanoista Header Compression) otsikko pakataan pakkauksen suhteen tilattomasti, käyttäen kuitenkin tietoja paikallisen linkin tilasta ja tehden oletuksia koko verkon laitteille yhteisestä tilasta. Pakkaustapa olettaa, että IP-protokollan versio on 6. 6LoWPAN-standardi on tarkoitettu toimimaan vain IPv6- osoitteiden kanssa, joten sitä tietoa ei tarvitse kuljettaa mukana jokaisessa paketissa.
Alimmat 64 bittiä IPv6-osoitteesta, eli vähiten merkitsevät puolet lähde- ja kohdeosoitteista, päätellään linkkikerroksen lähde- ja kohdeosoitteista. Tämä osa osoitteesta on verkkoliitynnän tunniste (Interface Identifier). Tämä on mahdollista vain, jos alla olevassa kerroksessa käytetään 802.15.4:n MAC-osoitteita. Kuorman pituus (packet length) voidaan johtaa linkkikerroksen kehyksen pituus (frame lenght) -kohdasta, jos sen tekniikkana on IEEE 802.15.4 PPDU (physical protocol data unit). Se voidaan päätellä myös 6LoWPAN Fragment Header -otsikkeesta, joka luodaan pilkkoessa IPv6- kehyksiä adaptation layer -kerroksella. Luokka, eli Traffic Class, ja vuon tunniste, eli Flow
Taulukko 2: IPv6-otsakkeen rakenne
Label, ovat kumpikin aina 0. Seuraava otsikko on aina UDP, ICMP tai TCP. Ainoastaan vuon tunniste (hop limit) täytyy aina kuljettaa pakkaamattomana, mutta jos pakettiin ei voi soveltaa kaikkea perustilanteen oletuksia, täytyy joitain muitakin kenttiä jättää pakkaamatta. Tavallinen IPv6-otsake voidaan parhaassa tapauksessa pakata jopa 2 oktettiin 40 oktetista. Verkkokerroksella voidaan pakata myös UDP:n otsake 4 oktettiin 8 oktetista. [26]
Vuonna 2011 IETF:n 6lowpan-työryhmä julkaisi päivitetyn version 6LoWPAN-standardin pakkausalgoritmista julkaisussa RFC 6282. Vuoden 2007 standardin tilattomasta pakkaustavasta sanotaan siinä, että se on tehokkaimmillaan vain erityistapauksessa, jossa kyseessä on linkille paikallinen unicast-lähetys ja IPv6-osoitteen verkkoliitännän tunniste saadaan IEEE 802.15.4 -osoitteesta. Käytännössä tietoliikennettä kulkee 6LoWPAN-verkossa myös paljon muunlaisissa tilanteissa, joita varten tarvittiin myös parempi pakkaustapa. Tähän ongelmaan kehitettiin ratkaisuksi LOWPAN_IPHC, joka toimii tehokkaammin myös muun muassa multicast-lähetyksissä.
LOWPAN_IPHC:n suurimpana erona aikaisempaan pakkaustapaan on mahdollisuus hyödyntää tilallista pakkausta monen otsakkeen kentän pakkaamisessa.
Lisäksi hyppyjen määrä -kentälle annetaan tunnettu arvo lähettävällä laitteella, 6LoWPAN:n osoitteet muodostetaan linkille paikallisesta etuliitteestä tai koko 6LoWPAN-verkolle yhteisestä joukosta etuliitteitä, ja 6LoWPAN-verkkoliitännöille johdetaan osoitteet IEEE 802.15.4 -osoitteesta. Standardiin tuli kyseisessä päivityksessä monia muitakin muutoksia, joita on liikaa tähän listattavaksi. [14]
3.3.2 Kohti geneerisempää pakkaustapaa
Kun 2000-luvun alussa oli kehitetty ensimmäisiä yleisesti käyttöön otettuja pakkaustapoja IPv6-otsakkeen koon pienentämistä varten, huomattiin laajennettavuuteen liittyvä ongelma. Aina kun haluttiin lisätä pakkaustandardilla pakattaviin otsakkeisiin uudenlainen kenttä, täytyi standardi avata uudestaan päivitystä varten.
Vuonna 2014 IETF:n 6lo-työryhmä julkaisi uuden geneerisen version IPv6-otsakkeen pakkaustavasta, nimeltään 6LoWPAN-GHC (Generic Header Compression). Tämä standardi määritteli yksinkertaisemman pakkaustavan, joka muistuttaa yleisesti käytössä olevaa, häviötöntä LZ77 (Lempel-Ziv) -pakkausalgoritmia. Tämän avulla voidaan pakata ennalta määrittämättömiä otsikkokenttiä sekä otsikkokentän tapaisia hyötykuormia, kuten joitakin reititysprotokollien viestejä. Tämä mahdollistaa muun muassa ICMPv6 (Internet Control Message Protocol version 6) -viestien pakkauksen.
Koska 6LoWPAN:ssa on käytössä useampi rinnakkainen pakkaustapa, täytyy olla myös mekanismi, jonka avulla verkon topologiassa vierekkäiset solmut voivat kommunikoida toisilleen millaista pakkaustapaa käyttävät. 6LoWPAN-GHC mahdollistaa käyttää tähän sekä implisiittistä että eksplisiittistä tapaa. Solmu voi ilmaista käyttävänsä GHC-pakkaustapaa lähettämällä naapurilleen tällä pakattua tietoa, tai jo naapuria etsiessään, eli neighbor discovery -viestissä, ilmoittaa tietyllä bitillä käyttävänsä sitä. [4]
Eräs mahdollinen pakkaustandardi 6LoWPAN-verkoille on, alun perin puhelinverkkojen käyttöön suunniteltu, Robust Header Compression -niminen
pakkausstandardi. Se on aikaisemmissa kappaleissa esiteltyihin pakkausmenetelmiin verrattuna monimutkaisempi pakkaustapa ja lisäksi vielä tilallinen. Monimutkaisuudesta seuraa myös pienitehoisilla laitteilla, kuten paristoilla toimivan sensoriverkon solmuilla, suuremmat vasteajat lähetyksissä. Laitteiden suorituskyky kuitenkin kasvaa koko ajan, ja tämä pakkaustapa pakkaa tiiviisti, joten sillä voi tulevaisuudessa olla enemmän jalansijaa 6LoWPAN-verkkojen käytössä. Varsinkin jos tulevaisuudessa sillä saadaan pakattua 6LoWPAN-verkkojen viestejä ja niiden linkkikerroksen otsakkeita entistä tiiviimmin. [23]
4. REITITYS
6LoWPAN-verkolla on reitityksen kannalta erityisiä haasteita verrattuna perinteiseen, Ethernet-linkin kautta toimivaan ja staattisessa paikassa sijaitsevaan tietokoneeseen.
Näistä kerrottiin tarkemmin alaluvussa 2.2. Tässä luvussa kerrotaan lyhyesti millaisia ratkaisuja on kehitetty ratkaisemaan kyseisiä ongelmia.
Alkuperäisessä 6LoWPAN-standardissa annettiin kaksi mahdollisuutta lähteä lähestymään reitityksen ongelmaa. Toinen on niin sanottu mesh under -tekniikka, jossa reititystiedot välitetään linkkikerroksen tasolla, 6LoWPAN-sovitinkerroksen käyttäessä tällöin erityistä mesh header -otsaketta. Tässä mesh header -otsakkeessa voidaan pitää tallessa reitityksen kannalta oleellista tietoa, kuten lopullinen osoite ja lähettäjän osoite, joita ei ole mahdollista säilyttää linkkikerroksen otsakkeissa. Tämä johtuu siitä, että linkkikerroksella lähettäjän ja vastaanottajan osoitteet kirjoitetaan jokaista hyppyä varten uudestaan, jolloin alkuperäisen lähettäjän ja lopullisen vastaanottajan osoitteet katoavat linkkikerroksen otsakkeesta. [32 s. 38–39] Toinen tapa toteuttaa reititys on route over - tekniikka, jossa reitityspäätösiä tehdään IPv6-osoitteiden perusteella. Koska Ipv6- osoitteet pilkotaan jokaista hyppyä varten useampaan pakettiin linkkikerroksella, täytyy vastaanottajan koota tälläinen useammasta paketista koostuva pätkä ennen lähetyksen pakettien välittämistä eteenpäin. Tässä helpottaa se, että IPv6-osoite on aina lähetyksen alussa, eli jos paketit tulevat järjestyksessä, saadaan se ensimmäisten pakettien joukossa. [32 s. 40–41]
IPv6-standardin reititykseen olennaisesti liittyvä naapurin löytäminen (neighbour discovery) -protokolla on tärkeä osa myös 6LoWPAN-verkon reititystä. Sen avulla verkon laitteet voivat löytää yhden hypyn päässä olevat naapurinsa, eli paikalliset linkit, ja sitä kautta saada tietoa mahdollisista seuraavista hypyistä reititystä varten. IPv6:n normaali neighbor discovery -protokolla ei kuitenkaan sellaisenaan soveltunut pienitehoisten langattomien verkkojen käyttöön, mutta 6lowpan-työryhmän vuonna 2012 julkaisema päivitys vuoden 2007 standardiin päivitti sitä sopimaan paremmin 6LoWPAN-verkkoihin.
[33]
6LoWPAN-verkkojen kanssa hyvin toimivat reititysprotokollat voidaan pääpiirteittäin jakaa kahteen ryhmään: distance-vector routing (etäisyysvektorireititys) ja link-state routing (linkin tila -reititys). Ensin mainitussa jokaiselle linkille, ja mahdollisesti myös solmulle, asetetaan aluksi oma kustannus. Kun halutaan sitten lähettää kahden solmun välillä paketti, valitaan reitti, jonka kaikkien hyppyjen yhteenlaskettu kustannus on pienin. Jokainen reititin pitää kirjaa tunnetuista kohdesolmuista ja niihin johtavien reittien yhteenlasketuista kustannuksista. Tätä reititystaulua päivitetään reititysalgoritmin määrittäminä hetkinä. Jälkimmäisenä mainitussa tavassa jokainen solmu pyrkii saamaan tiedon koko verkon rakenteesta graafin muodossa. Tämän jälkeen ne laskevat etäisyyden kaikkiin mahdollisiin kohdeosoitteisiin verkon sisällä käyttämällä tehtävään soveltuvaa reitinhakualgoritmia. Tämä tapa ei yleensä toimi 6LoWPAN-verkoissa muuten kuin tehokkaampien reunareitittimien osalta, koska jokainen verkon topologian muutos aiheuttaa reititysgraafien päivityksen ja siten suuren määrän liikennettä ja laskentaa solmuille. [32 s. 106]
Myös tekniikat, joita käytetään reititystiedon päivittämiseen 6LoWPAN-verkon solmujen välillä, voidaan jaotella kahteen ryhmään: proaktiiviset algoritmit ja reaktiiviset algoritmit. Ensin mainitut selvittävät ja tallentavat reititystietoa solmuille jo hyvissä ajoin, ennen kuin sitä tarvitaan. Tästä saadaan se hyöty, että tarvittava reititystieto on heti saatavilla, kun usean hypyn kautta reititettävä paketti lähetetään, ja verkko voi toimia nopeammin siinä tilanteessa. Haittapuolena tällä lähestymistavalla ovat suuret kaista- ja laskentateho-kustannukset, jos verkon topologia muuttuu. Varsinkin jos kyseessä on suuri verkko. Jälkimmäisellä tavalla saadaan minimoitua ylimääräinen reititystiedon säilyttäminen ja välittäminen, koska reitit lasketaan vasta siinä vaiheessa, kun halutaan lähettää reititystä vaativa paketti. [32 s. 107]
Reititysprotokollat 6LoWPAN-verkoille ja yleisemmin, pienitehoisille verkoille, ovat olleet aktiivisen tutkimuksen kohteena koko 2000-luvun ajan, ja jokaisesta alla esitetystä protokollasta on olemassa monia vaihtoehtoisia versioita, joista osa on kokeellisella asteella ja osa jo ottanut paikkansa teollisuuden käytössä.
4.1 RPL-reititysprotokolla
Pienitehoisten langattomien IPv6-verkkojen reititys on ollut tutkimuksen ja kehityksen alla koko 2010-luvun ajan. Eräs aiheen parissa työskentelevistä ryhmistä on IETF:n roll- työryhmä, joka on julkaissut standardeja aiheesta. RPL (IPv6 Routing Protocol for Low- Power and Lossy Networks) on roll-työryhmän julkaisema reititysprotokolla, joka on tarkoitettu erityisesti 6LoWPAN-verkkojen käyttöön.
RPL erottaa pakettien käsittelyn ja välittämisen reitityksen optimointiin liittyvistä tavoitteista ollakseen mahdollisimman yhteensopiva erilaisien verkkojen kanssa. RPL- protokollan tapa reitittää sijoittuu, kappaleen 2.4 alussa mainituista kategorioista, etäisyysvektorireitityksen ryhmään. Siinä muodostetaan syklittömiä suunnattuja graafeja, jotka päättyvät haluttuun kohdeosoitteeseen, joita graafin juuressa on lähes aina vain yksi. Jos juurisolmuja on graafissa useampi, ne ovat todennäköisesti yhdistetty nopealla yhteydellä toisiinsa ja halutaan sen takia kuvata verkon topologiassa samaan paikkaan. Graafeja luodaan proaktiivisesti, mikä mahdollistaa optimoidummat vasteajat pakettien lähetyksessä, koska osa tarvittavasta reititystiedosta saattaa olla jo valmiina kun pakettia lähetetään uutta reittiä pitkin. Graafeja voidaan päivittää tarvittaessa myös reaktiivisesti, joten RPL sopii hyvin verkoille joiden topologia muuttuu usein ja jonka verkon solmujen resurssit ovat rajalliset.
RPL vaatii toimiakseen kaksisuuntaiset linkit, mutta linkkien ei tarvitse kuitenkaan olla symmetrisiä. Linkkikerroksen toteutukselle tai toimintavarmuudelle ei myöskään ole asetettu tarkkoja vaatimuksia, jotta protokolla olisi yhteensopiva mahdollisimman monessa tilanteessa. RPL vaatii kuitenkin jonkun protokollan ulkopuolisen mekanismin, joka ilmoittaa, jos naapurisolmu ei ole tavoitettavissa. Tässä roolissa voi toimia esimerkiksi IPv6:n Neighbor Unreachability Detection. [31] [42]
4.2 AODV
AODV (Ad hoc On-Demand Distance Vector) on etäisyysvektoreihin perustuva reititystapa. Se kehitettin sellaisia suurikokoisia verkkoja varten, joiden solmut ovat pienitehoisia ja saattavat olla liikkeessä.
Verrattuna RPL-reititysprotokollaan AODV on reaktiivisempi. Uusia reittejä muodostetaan vasta silloin, kun niitä ensimmäisen kerran tarvitaan. Kun verkon solmu haluaa lähettää paketin kohteeseen, johon tällä ei ole ennestään tiedossa reittiä, lähettää se erityisen Route Request -viestin, joka leviää verkossa eteenpäin. Jos viesti löytää reitin haluttuun kohteeseen, lähetetään vastauksena Ruote Reply -viesti kohdeosoitteelta takaisin viestiä lähettävälle solmulle. Tämän viestin kulkeman reitin perusteella muodostetaan kaksisuuntainen reitti, jota lähettävä solmu säilyttää muistissaan. [31] AODV vaatii verkon solmuilta vain sellaisten reittien aktiivista ylläpitoa, jotka ovat aktiivisessa käytössä. Erityistä huomiota kiinnitettiin myös siihen, että reititysviestit eivät jäisi erikoistapauksissakaan kiertämään loputtomiin. Tämä on ollut mahdollista joissakin aikaisemmissa etäisyysvektoreihin perustuvissa reititysprotokollissa, mutta pienitehoisten ja liikkuvien solmujen kanssa toimiessa verkkoliikenne tulee minimoida. Tämä lisää vasteaikaa, kun lähetetään viestejä uusia reittejä pitkin, mutta tekee protokollasta hieman geneerisemmän.
Tärkeänä vaatimuksena reititysprotokollan käytölle on se, että solmut voivat luottaa toisiinsa. Tämä tapahtuu usein vaihdettujen salausavaimien avulla. Protokolla toimii myös IPv6:n kanssa ilman erityisiä muutoksia. Tässä tapauksessa vain osoitekentän koko on erilainen. [27]
4.3 Link state routing -protokollat
Linkin tilaan perustuvia reititysprotokollia ei 6LoWPAN-verkkojen käyttöön ole
tutkittu niin paljon, kuin reaktiivisempia, etäisyysvektoreihin perustuvia. Tämä voi johtua luvun alussa esitetyistä haittapuolista, eli suuresta reititysviestien ja solmujen
ylläpitämän reititystiedon määrästä. Tälläisellä reititystavalla on kuitenkin etunaan pienemmän vasteajat hyötyviestejä lähetettäessä, sillä reitit muodostetaan jo ennen viestin lähettämistä. Tutkimusta on tehty myös näiden proaktiivisten reititystapojen kehityksen kanssa. [32 s. 107]
Eräs tähän kategoriaan kuuluva reititysprotokolla on IETF:n MANET (Mobile Ad-hoc Networks) -työryhmän kehittämän OLSR (Optimized Link State Routing) -protokolla.
Protokolla julkaistiin ensin kokeellisena vuonna 2003, mutta päivitettiin vuonna 2014 ja nimettiin samalla OLSRv2-nimiseksi. Nyt se on nostettu standardiksi ja saanut
lähivuosina vielä lisää jatkokehitystä.
Kuten kaikki proaktiiviset reititysprotokollat, myös OLSR käyttää paljon
reititysviestejä, ennen kuin yhtään varsinaista hyötykuormallista viestiä on lähetetty.
Protokolla luo jokaiselle solmulle reititystaulut, joiden avulla reitityspäätökset voidaan
tehdä hyppy kerrallaan, paikallisesti ja ilman keskitettyä auktoriteettia. Tavoitteena on saada jokaiselle reitittävälle solmulle tieto jokaisesta mahdollisesta kohteesta verkon sisällä ja nopeimmista reiteistä näihin kohteisiin. Tässä käytetään apuna niin sanottuja HELLO-viestejä, joita jokainen solmu säännöllisesti lähettää.
OLSR vähentää reititystaulujen luomiseksi tarvittavaa reititysviestinnän tulvaa määrittämällä tietyt verkon solmut MPR-solmuiksi (Multi Point Relay), jotka vastaavat täysin reititysviestien uudelleenlähettämisestä. Verkon solmut valitsevat MPR-solmut joukostaan tietyn algoritmin perusteella, pyrkien siihen, että jokainen viesti välitetään jokaiselle verkon solmulle näiden valittujen solmujen kautta.
OLSRv2 on parhaimmillaan tiheässä ja laajassa verkossa, jossa käytettävä reitti on mahdollisimman satunnainen. Näin saadaan suurin hyöty siitä, että nopeimmat reitit on laskettu valmiiksi. Etäisyysvektoreihin perustuvat reititystavat toimivat todennäköisesti nopeammin, jos samoja reittejä käytetään usein.
OLSRv2 vaatii, että verkon solmut käyttävät MANET-työryhmän kehittämää naapurin löytämisprotokollaa. [6]
5. TURVALLISUUS
Tässä luvussa esitellään hyökkäyksiä, joita 6LoWPAN-verkkoja vastaan voidaan käyttää, sekä esimerkkejä puolustautumiskeinoista niitä vastaan. Useimmat näistä hyökkäystyypeistä ovat sellaisia, joita voidaan käyttää yleisestikin langatonta ja/tai pienitehoista verkkoa vastaan, eivätkä ne koske vain IPv6-kytkentäistä verkkoa. Listan tarkoituksena on esitellä esimerkkejä eri tyyppisistä uhista, eikä toimia täydellisenä listana niistä.
Hyökkäys 6LoWPAN-verkkoa kohtaan voi tulla verkon sisältä, eli verkon jäsenenä toimivalta laitteelta, jonka hyökkääjä on saanut haltuunsa, tai laitteelta, jonka hyökkääjä on tuonut verkon kuuluvuusalueelle ja saanut verkon tunnistamaan sen osaksi itseään.
Hyökkäys voi tulla myös 6LoWPAN-verkon ulkopuolelta, Internetin kautta. Jos halutaan rakentaa turvallinen verkko, täytyy kaikki nämä mahdollisuudet ottaa huomioon.
Langattomalla verkolla, kuten kaikilla tietoa käsittelevillä järjestelmillä, on pääpiirteittäin kolme tärkeintä turvallisuustavoitetta, jotta sitä voidaan pitää turvallisena:
Ensinnäkin tietoa ei saa päätyä kolmannen osapuolen käsiin. Tämä ei ole aina mahdollista, mutta tarpeeksi hyvällä salauksella voidaan estää ulkopuolista tahoa hyödyntämästä saamaansa tietoa. Toisekseen ulkopuoliset tahot eivät saa päästä muokkaamaan järjestelmän tietoa. Kolmanneksi järjestelmälle ei saa olla liian helppo tehdä sellaista hyökkäystä, joka estää sen toiminnan. [32 s. 84–85]
5.1 Fyysiset hyökkäykset
Koska 6LoWPAN-verkon laitteet ovat usein pieniä ja tarkoitettu toimimaan itsenäisesti, voi olla vaikea estää tunkeutujaa pääsemästä fyysisesti langattoman verkon kuuluvuuden alueelle tai jopa käsiksi verkon solmuna toimivaan laitteeseen. On siis usein mahdollista, että tunkeutuja pystyy halutessaan tuhoamaan tai varastamaan verkkoon kuuluvan laitteen ja lähettämään viestejä verkon laitteille.Tämä mahdollistaa salakuuntelun, minkä takia täytyy olettaa, että kaikki salaamattomana lähetetty tieto voi päätyä myös ulkopuolisten haltuun. On myös mahdollista, että verkon laitteiden signaalia häiritään, tai lähetyksiä nauhoitetaan ja lähetetään uudestaan. Mikäli turvallisuus perustuu avaimeen, joka on asetettu jokaiselle verkon laitteelle, tunkeutuja voi koittaa saada sen selville myös varastamastaan laitteesta. Huolimattomasti pois heitetty, toimimaton laite, voi olla riski koko verkolle, jos se sisältää edelleen toimivan avaimen.
Jos hyökkääjällä on fyysisesti pääsy laitteelle, hän voi myös haitata laitteen mittaustuloksia ilman tietoteknisiä välineitä. Esimerkiksi lämpötilasensorin mittauksia voi sabotoida muuttamalla ympäristön lämpötilaa keinotekoisesti. [32 s. 85]
5.2 6LoWPAN-kerroksen fragmentaation hyödyntäminen
Taulukossa 1 kuvattu 6LoWPAN-sovituskerros pilkkoo 6LoWPAN-verkossa lähetettävät datagrammit sopivan kokoisiksi linkkitason protokollalle, jolla on rajoitettu pakettikoko.
Se myös kokoaa ne uudestaan vastaanottavalla solmulla. Paketit eivät aina tule oikeassa järjestyksessä, joten vastaanottajalla täytyy olla jonkinlainen puskuri, jossa se säilyttää keskeneräisiä vastaanotettuja lähetyksiä. Jonkin tietyn ajan kuluttua keskeneräiset lähetykset täytyy poistaa puskurista, jos enemmän paketteja ei saavu, jotta niiden säilyttämiseen varatut resurssit saadaan vapautettua uudestaan. Pienillä laitteilla nämä puskuriresurssit eivät todennäköisesti ole kovin suuret. Hyökkääjä tai huonosti konfiguroitu solmu voi käyttää tässä mekanismissa olevia heikkouksia hyödykseen useammalla tavalla.
Eräs tälläinen hyökkäys on packet duplication attack. Siinä verkon kuuluvuusalueelle sijoittunut hyökkääjä lähettää kuulemastaan paketista kopion.
Protokollapinon 6LoWPAN-tasolla ei ole mahdollisuutta varmistaa, onko paketti tullut alkuperäiseltä lähettäjältä. Tämän voisi päätellä protokollatasolla ylemmän kerroksen tiedosta, mutta sitä varten vastaanottajan pitäisi vastaanottaa ensin kaikki lähetyksen fragmentit.
Hyökkääjän lähettämä identtinen paketti aiheuttaa jonkin ei-toivotun reaktion vastaanottajalla. 6LoWPAN-standardissa tälläinen paketti aiheuttaa koko datagrammin hylkäämisen. Hyökkääjä voi siis yhdellä paketilla parhaimmillaan keskeyttää pidemmän lähetyksen, haitaten verkon toimintaa.
Tälläisiä hyökkäyksiä voidaan estää, jos pystytään tunnistamaan vastaanottajan päässä, että lähettävä taho on sama kuin muissa lähetyksen fragmenteissa. Koska 6LoWPAN-verkon laitteiden resurssit ovat rajalliset, voi olla vaikea toteuttaa matalan tason avaimien vaihtoon perustuvaa tunnistautumistapaa. Yksi ehdotettu tapa tunnistaa kuuluuko vastaanotettu paketti samaan lähetykseen, vai onko se kopio oikeasta paketista, on content chain -niminen menetelmä. Siinä lähettävä solmu muodostaa jokaiselle paketille tarkistussumman iteratiivisella funktiolla. Tarkistussumman arvo määräytyy jokaiselle paketille niin, että siihen vaikuttaa myös seuraavien pakettien arvo.
Ensimmäisessä paketissa, eli fragmentissa, oleva tarkistussumma riippuu siis koko datagrammista, ja sitä voidaan käyttää varmistamaan, mitkä paketit ovat osa lähetystä.
Eräs toinen tapa hyödyntää 6LoWPAN-kerrosta hyökkäyksessä on buffer reservation attack. Siinä verkon solmuksi soluttautunut hyökkääjä lähettää yksittäisiä fragmentteja vastaanottajalle, jotta vastaanottajan vastaanottopuskuri säilyttäisi niitä mahdollisimman kauan, ja ne veisivät siltä rajallisia muistiresursseja. Hyökkääjä voi lähettää näitä paketteja satunnaisesti, tai sitten selvittää kuinka kauan vastaanottaja säilyttää keskeneräisiä datagrammeja puskurissaan, optimoidakseen hyökkäystä.
Tälläisen hyökkäyksen vaikutuksia voidaan heikentää sopivilla stradegioilla, puskureiden jakamiseen, pakettien säilytysaikoihin, pakettien priorisointiin ja pakettien hylkäämiseen liittyvissä säännöissä. Täysin tämän kaltaisen palvelunestohyökkäysten vaikutuksia ei voida poistaa, jos hyökkääjä on verkon sisältä, mutta ainakin sen 6LoWPAN-tason fragmentoinnista johtuvia vaikutuksia on mahdollista pienentää huomattavasti. [15]
5.3 Reititysalgoritmeja hyödyntävät hyökkäykset
Sinkhole-hyökkäyksessä huonosti toimiva tai kaapattu verkon sisäinen solmu kieltäytyy välittämästä paketteja eteenpäin. Sen kautta lähetetyt paketit käytännössä hukkuvat. Jos kyseessä on yritys suorittaa palvelunestohyökkäys, tälläinen solmu todennäköisesti pyrkii mainostamaan itseään hyvänä reititysväylänä muille verkon solmuille tai hyvänä paikallisena linkkinä naapureilleen.
Tälläistä hyökkäystä vastaan voidaan puolustautua ensinnäkin kryptografisesti. Jos sinkhole-hyökkäystä toteuttamaan pyrkivä laite ei pysty tunnistautumaan osaksi verkkoa, ja siten kommunikoimaan muiden laitteiden kanssa, ei hyökkäys voi onnistua. Tälläisiä hyökkäyksiä vastaan on tutkittu myös sellaisia suojautumiskeinoja, jotka eivät perustu kryptografiaan. Osa näistä perustuu sumeaan logiikkaan ja koneoppimiseen, joiden keinoin verkon solmut voivat yhdessä äänestää epäilyttäviksi katsomistaan solmuista. [5]
Wormhole -hyökkäyksessä hyökkääjä nauhoittaa verkossa lähetetyn paketin yhdessä kohdassa verkkoa ja tunneloi sen toiseen kohtaan, toiselle hyökkääjälle, esimerkiksi langallisen yhdeyden kautta. Tämä sinällään ei vielä aiheuta verkon toiminalle suurta häiriötä, vaan voi jopa nopeuttaa sen toimintaa, jos madonreiän muodostavat solmut välittävät kaiken liikenteen muokkaamatta sitä.
Madonreikä kuitenkin asettaa sen muodostavat solmut erityiseen asemaan muihin verkon solmuihin nähden, koska niiden kautta reititetty liikenne saattaa tulla perille paljon paremmin kuin muiden verkon reittien, jotka kulkevat monen langattoman hypyn kautta. Näin monet reititysprotokollat alkavat automaattisesti suosia reittiä, joka kulkee madonreiän kautta. Joidenkin protokollien saattaa olla jopa mahdotonta löytää reittejä, jotka eivät kulje tätä kautta.
Kun madonreikä on muodostettu, ja sen kautta kulkee suuri osa verkon liikenteestä, mahdollistaa se hyökkääjälle valikoivan reitittämisen ja muuta verkon toimintaa haittaavaa toimintaa. Tämä on mahdollista varsinkin, jos hyökkääjällä on oleellista tietoa verkon toiminnasta. Esimerkiksi välittämällä viestit, joiden avulla verkon solmut tunnistavat virheellisesti olevansa yhden hypyn päässä toisistaan olevia naapureita, mutta jättämättä näiden väliset yhden hypyn suorat viestit välittämättä.
Madonreikähyökkäys ei välttämättä vaadi edes verkon kryptografisia avaimia, mutta sitä varten hyökkääjän täytyy kuitenkin päästä verkon kuuluvuusalueelle.
Madonreikähyökkäystä on vaikea torjua, mutta siihen on ehdotettu vastatoimeksi esimerkiksi tekniikoita, jotka perustuvat siihen, että verkon solmujen täytyy tietää fyysinen paikkansa ja tiukasti synkronoituja kelloja aikaleimattuihin paketteihin yhdistettynä. [13]
5.4 Sybil-hyökkäys
Sybil-hyökkäys on mahdollinen, jos hyökkääjä pystyy luomaan verkkoon aidon näköisiä uusia solmuja. Tämä voi tapahtua esimerkiksi hyökkääjän haltuunsa saaman yksittäisen solmun avulla. Hyökkääjä käyttää tätä ominaisuutta luodakseen suuren määrän virtuaalisia väärennettyjä solmuja. Niiden tarkoitus on toimia yhdessä ja haitata verkon toimintaa, huolimatta mahdollisista vikoja torjuvista mekanismeista, kuten hajautettu tallennustila ja redundantit reitit. Jos hyökkääjän hallitsemia solmuja on tarpeeksi, ne pystyvät toimimaan tehokkaasti, esimerkiksi äänestämiseen perustuvia, tunkeutujan tunnistamiseen tarkoitettuja algoritmeja vastaan.
Jos hyökkäys on mahdollinen, on sen torjuminen erittäin vaikeaa. Tähän on esitetty puolustukseksi monen laisia, matemaattisia, kryptografisten avainten jakamiseen liittyviä stradegioita, joilla on omia hyviä ja huonoja puoliaan. [40]
6. SOVELLUSESIMERKKEJÄ
6LoWPAN-laitteita on jo käytössä ympäri maailman, mutta yritykset eivät välttämättä halua mainostaa millaista matalan tason teknologiaa he käyttävät omissa langattomissa verkoissaan, mahdollisesti turvallisuussyistäkin. 6LoWPAN-standardit itsessään myös jättävät vielä monta käytännön toteutukseen liittyvää yksityiskohtaa, koska ne käsittelevät vain tiettyjä osia protokollapinosta. On siis vaikea löytää tietoa sellaisista toteutuksista, joissa on lähdetty rakentamaan omaa protokollapinoa julkisten standardien pohjalle. Tässä luvussa esitellään yksi sellainenkin.
Yrityksille ja kuluttajille on sen sijaan tarjolla useampi ratkaisu, jossa joitakin 6LoWPAN-standardeista on käytetty osana rakentamassa suurempaa kokonaisuutta.
Tässä luvussa esitellään niistä muutama.
6.1 Zigbee IP
Zigbee on vuodesta 2004 markkinoilla ollut Zigbee-allianssin kehittämä standardi, joka määrittelee IEEE 802.15.4 -radion päällä toimivan, pienitehoisille IoT-laitteille tarkoitetun protokollapinon. Standardilla tavoiteltiin osittain samoja asioita, kuin 6LoWPAN-standardeissakin. Standardi oli erittäin suosittu IoT-kentällä, mutta ei mahdollistanut aluksi IPv6-osoitteita, joten se ei ollut suoraan yhteensopiva IPv6- pohjaisten protokollien kanssa, vaan yhteydet ulos Zigbee-verkosta täytyi hoitaa erillisen gatewayn kautta. Tätä ongelmaa ratkaisevaksi vaihtoehdoksi kehitettiin Zigbee IP, joka mahdollistaa IPv6-osoitteiden käyttämisen. Zigbee IP käyttää IEEE 802.15.4 -radion päällä 6LoWPAN-sovituskerrosta, jonka päällä taas on mahdollista käyttää IETF:n standardien mukaisia kuljetus- ja sovelluskerroksia. Zigbee IP -verkon laitteet voivat siis kommunikoida suoraan ulkoisen Internetin kanssa, mutta liikenne ulos Zigbee-verkosta ohjataan kuitenkin erityisen gateway-reitittimen kautta. [21]
Eräs esimerkki Zigbee IP -protokollaa käyttävästä, markkinoilla käytössä olevasta järjestelmästä on Philips Hue -valaistusjärjestelmä. Siihen kuuluvien lamppujen ominaisuuksia, kuten väri ja teho, voi säätää etänä. On myös mahdollista määritellä valaistukseen liittyviä automaattisia toimintoja, kuten erilaisten asetusten aktivoituminen liiketunnistimien, äänen tai vaikka kellonajan mukaan.
Järjestelmää voi ohjata halutessaan Bluetoothin välityksellä, esimerkiksi älypuhelimella, jolloin käyttäjän täytyy olla samassa huoneessa ohjattavien laitteiden kanssa. Kaikkiin Hue-laitteisiin on myös sisäänrakennettu Zigbee-tuki, joka mahdollistaa laitteiden verkottumisen keskenään ja viestien välittämisen myös monen hypyn takana oleviin laitteisiin. Tämän verkon käyttäminen vaatii Hue Bridge -lisälaitteen, johon käyttäjän tulee olla yhteydessä, jos haluaa käyttää järjestelmäänsä Zigbee-verkon kautta. [28]
6.2 Thread ja Openthread
Vuonna 2014 perustetun Thread Groupin kehittämä teknologiapino. Thread Groupin jäseniksi liittyi pian monta merkittävää laitteisto- ja ohjelmistovalmistajaa, sekä lukuisia yhdistyksiä. Lista on edelleen kasvanut perustamisesta lähtien. Ryhmän tavoite on luoda tekniikka, joka helpottaisi iot-ratkaisujen yhteensopivuutta, turvallisuutta ja käyttöönottoa. Spesifikaatio on saatavilla, mutta Threadia käyttävien laitteiden julkaisemiseen vaaditaan ryhmän maksullinen jäsenyys. Vuonna 2017 Google julkaisi virallisen ohjelmistorajapinnan Threadille Android-käyttöjärjestelmässä [11]. [37]
Ohjelmistoprotokollat
UDP + DTLS Distance Vector Routing
IPv6 6LoWPAN IEEE 802.15.4 MAC IEEE 802.15.4 fyysinen
Thread perustuu 6LoWPAN-standardeihin 802.15.4-radion päällä. Kuten taulukosta 2 voidaan nähdä, Threadin linkki ja fyysinen kerros on lähes suoraan IEEE 802.15.4-radio, jonka päällä on standardien mukainen 6LoWPAN-sovituskerros. Protokollaa varten on myös tehty omaa jatkokehitystä, joka erottaa sitä hieman tavallisesta IEEE 802.15.4- radion linkkikerroksesta ja ottaa myös kantaa protokollapinon ylempien kerrosten toimintaan. Linkkikerroksella verkon toimintaa optimoidaan niin, että osa verkon laitteista määritellään Sleepy end device -tyyppisiksi. Tämän tyyppiset laitteet kommunikoivat muun verkon kanssa vain yhden tietyn välittäjäsolmun (Parent Router) kanssa. Tämä mahdollistaa paljon pidemmät inaktiiviset lepoajat. [35] Myös reititykseen on otettu kantaa Threadissa. Thread-verkon sisällä Thread käyttää etäisyysvektorireititystä. [35]
Threadissa on määritelty tavat, joilla uusi laite voi liittyä osaksi Thread-verkkoa.
Uudella laitteella ei tarvitse olla kaikkia pääsytietoja, kuten verkon laajuista avainta, jolla linkkikerroksen kehykset on salattu, vielä ennen liittymistään. Uuden laitteen täytyy vain saada yhteys Thread-verkon reunareitittimeen ja sitä kautta tietyssä auktoriteettiroolissa toimivalle palvelimelle. Tämän palvelimen ei tarvitse olla fyysisesti Thread-verkossa, vaan se voi sijaita vaikka älypuhelimessa tai pilvessä. Uuden laitteen tulee suorittaa reunareitittimen kautta salasanalla varmistettu avaimen vaihto. Sen onnistuessa verkon avain toimitetaan uudelle laitteelle salattuna. Tässä käytetään J-PAKE (The Password Authenticated Key Exchange by Juggling)- ja DTLS (Datagran Transport Layer Security) -protokollia. [35] [37] [38]
Taulukko 2: Threadin protokollapino [36]
