IPv6 heeft eigenschappen die het een goede toepassing maken voor Internet of Things-uitrol, zoals de ondersteuning van grote IoT-netwerken, het behouden van accuduur van IoT-apparaten en het verminderen van beheer en onderhoud. IPv4 heeft deze IoT-specifieke opties niet. Kan IoT de drijvende kracht blijken achter de adoptie van IPv6 in het bedrijfsleven?
Gigantisch aantal adressen
Een probleem dat steeds maar terugkomt in deze discussie is de 4,2 miljard mogelijke adressen van het IPv4-protcol, terwijl internetverbonden apparaten naar verwachting doorgroeien tot 28,5 miljard in 2022. Dan zit je dus met een tekort als je IoT-netwerken uitrolt met directe verbindingen en moet je een laag als network address translation (NAT) gaan gebruiken om één publiek IP-adres te verbinden aan verschillende private IP-adressen.
Afgelopen oktober schreven we hoe het inmiddels zit met de adoptie van het nieuwe IP-protocol. Na jarenlang in de marge te zijn gebleven, begint dat nu op stoom te raken. Tenminste, aan de kant van netwerkleveranciers; bedrijven blijven afwachtend. Lees meer in: Hoe staat het inmiddels met IPv6?
IPv6 ondersteunt 340 undeciljoen adressen, oftewel 340 biljoen biljoen biljoen adressen, genoeg voor 50 quadriljard adressen per mens op de aarde, wat toch wel genoeg zou moeten zijn om universeel unieke adressen toe te wijzen aan elk IoT-apparaat. En dat zonder verder te investeren in NAT.
IPv6 en IoT-accuduur
IPv4 komt ook tekort qua energiezuinigheid. Omdat veel verbonden apparaten hun energie krijgen van een accu en omdat IoT-netwerken, zoals industriële sensorsystemen, uit honderdduizenden apparaten kunnen bestaan, is het van groot belang om zo energiezuinig te werken. Stel je voor hoeveel tijd en moeite het zou kosten om de accu's van breed verspreide IoT-apparaten te vervangen.
Met IPv4 heb je regelmatig broadcasting wat onnodig accukracht vereist. Zo worden broadcastberichten gebruikt voor processen als het Address Resoultion Protocol (ARP) wat wordt gebruikt voor het koppelen van MAC-adressen aan IPv4-adressen. Een ARP-bericht wordt naar elk apparaat in het netwerk verstuurd en elk apparaat moet dit pakketje updaten en daarmee een beetje energie verbruiken, ongeacht of het nodig was dat dit apparaat meedeed aan de uitwisseling.
Dat inefficiënte gedrag kan ook het netwerk als geheel verstoren. De problemen van Broadcast Storm, wanneer er frequente broadcasts in een kort tijdbestek worden gemaakt, zijn welbekend en dit effect zou schadelijk zijn voor een IoT-netwerk.
IPv6 heeft niet zo'n broadcast-feature. In plaats daarvan wordt een efficiëntere multicastmethode gebruikt om naar meerdere apparaten te communiceren. Het Neighbor Discovery Protocol (NDP) van IPv6 grbuikt multicastadressen voor specifiek aangesproken knooppunten om een gedeelde cache op te bouwen en te onderhouden. Het Neighbor Solicitation-pakketje wordt alleen naar een kleine subset van de 64-prefix gestuurd en het Neighbor Advertisement-pakketje wordt met unicast teruggestuurd. Het All-Nodes link-local groepadres (FF02::1) van IPv6 is een soort equivalent van IPv4-broadcast en IoT-apparaten proberen unicast-berichten te gebruiken, wanneer mogelijk, om zoveel mogelijk energie te besparen.
Details: Hoe IPv6 de accu spaart
IPv6 heeft verschillende methoden om dynamisch adressen toe te wijzen aan IoT-apparaten. IPv6-knooppunten hebben meerdere adressen, in tegenstelling tot IPv4-knooppunten die een enkel unicastadres hebben. Ze hebben een link-local adres (FE80::/10) en een of meer IPv6-unicastadressen per interface. Het link-local adres wordt gebruikt enkel als 'bootstrap' gebruikt om de unicastadressen te verkrijgen als bronadres voor Router Solicitatuon-berichten (RS) om de lokale router te vinden.
De eerste router stuurt een Router Advertisement-bericht (RA) terug naar de All-Nodes multicastgroep (FF02::1) om de lokale IPv6 /64-prefix aan te geven en de methode om het unicastadres op te halen. Afhankelijk van de flags en andere opties van het RA-bericht, gebruikt een knooppunt vervolgens Stateless Address AutoConfiguration (SLAAC), Stateful DHCPv6 of Recursive DNS Server (RDNSS). Welke daarvan je moet gebruiken, is een vraag die regelmatig naar voren komt bij zakelijke netwerken.
Voor sensoren die niet de rekenkracht hebben om DHCPv6 te draaien en alleen op een plat netwerk hoeven te werken, is SLAAC een logische keuze. Voor zakelijke desktops en servers werd DHCPv6 aangeraden, maar dat is aan het verschuiven. Nu meer besturingssystemen RDNSS ondersteunen, inclusief Android, begint dit de populaire keuze te worden.
RA-pakketjes worden doorgaans elke 200 seconden door de lokale router verzonden om alle knooppunten op de hoogte te houden van wijzigingen. Nieuwe knooppunten die zich op het netwerk begeven wachten daar niet op en sturen een RS-pakketje naar de link-local multicastgroep (FF02::02) om meer te weten te komen over het netwerk waar ze mee verbinden. De router reageert op de RS door een RA naar All-Nodes te versturen. Zoals je begrijpt, kan dit de accu van een IoT-toepassing belasten en daarom zijn er opties gemaakt om RA's in toom te houden.
Een optie is bijvoorbeeld om langere RA-intervallen te gebruiken voor IoT-netwerken. IoT-apparaten kunnen wellicht af met één RA-bericht per dag, of zelfs minder. Maar elke keer dat een nieuw apparaat wordt verbonden met het netwerk, zou het een bericht naar de router sturen, waarna een All-Nodes RA-multicastbericht wordt verstuurd.
Om vanwege deze reden All-Nodes multicastpakketjes verder te beperken, kan RA worden aangepast om alléén een unicastbericht te sturen naar het knooppunt dat de RS verzond. Dat zou betekenen dat andere verbonden knooppunten geen multicast-RA zouden ontvangen zodra een nieuw apparaat koppelt. Deze 'Unicast-RA' feature is geimplementeerd in Cisco IOS-versies 15.4(2)T, 15.4(2)S, 15.2(1)SY1 en later, en geconfigureerd met de interfaceopdracht ipv6 nd ra solicited unicast.
Innovatieve IPv6 IoT-protocollen
IPv6 maakt innovatie mogelijk en er is veel ontwikkeld aan IPv6 IoT-protocollen. Hieronder noemen we een paar voorbeelden van hoe IoT-netwerken voordeel behalen uit het gebruik van IPv6.
Met IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) kunnen Ipv6-pakketjes worden gecomprimeerd, ingepakt en verdeeld worden tussen meerdere kleinere frames om over 802.15.4-netwerken te worden verzonden (zie RFC 4944 en RFC 6282). 6LoWPAN vereist een gateway-apparaat (edgerouter) om het IPv6-netwerk te verbinden met het IoT-nerwerk. Het doel hiervan is om IPv6-multicast nog verder te beperken om accudduur nog verder op te rekken (RFC 6775). Deze methoden worden gebruikt door de Zigbee-protocollen.
De IETF werkt aan IPv6 over Low Power WAN's als LoRaWAN en Light-Weight Implementation Guidance (lwig) voor kleine embedded apparaten die IPv6 gebruiken. De organisatie heeft ook protocollen gebouwd voor het gebruik op Low power and Lossy Networks (LLN). Zo zijn er het IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) en het Multicast Protocol for Low-Power and Lossy Networks (MPL). RPL gebruikt IPv6 om alle RPL-knooppunten te vinden via de IPv6 multicastgroep FF02::1A.
Verder heeft de IETF standaarden ontwikkeld voor hoe IoT-apparaten communiceren met IPv6 over web en RESTful interfaces (CoRE). Het Constrained Application Protocol (CoAP) definieert de methoden voor deze IoT-apparaten om webdiensten te gebruiken. CoAP gebruikt de IPv6 multicastgroep FF0X::FD (All CoAP Nodes). En het Mobile IPv6-protocol (MIPv6) is al jaren geleden gespecificeerd voor niet-vaste apparaten om te kunnen schakelen tussen Layer 3-netwerken.
IPv6 wordt zelfs gebruikt in IoT-productie en roboticanetwerken. Het Precision Time Protocol (PTP) gebruikt IPv6-multicast om klokken te synchroniseren op minder dan een microseconde nauwkeurig voor de precieze choreografie van heel snel bewegende componenten. PtP gebruikt multicastgroepen FF02::6B en FF0X::181.
Het is beter voor netwerkbeheerders om een IPv6-netwerk nu te onderzoeken en niet te worden gedwongen tot een overstap als IoT-netwerken met meer haast moeten worden uitgerold. Doe dit nu er nog tijd is, zodat het de organisatie geld bespaart en je niet tegen frictie aanloopt door haastwerk. Een van de eerste stappen voor een bedrijf is om IPv6-adressen te bemachtigen van RIPE (of buiten Europa een andere RIR) en dan uitrolgidsen te volgen voor het inzetten van het nieuwere protocol.
Het probleem met IPv6 is vooral de business case. Plat gezegd: nobody gives a fuck. Websites doen het, mail doet het, appjes doen het en niemand zit te wachten op de uitrol van een volledig parallel schaduwnetwerk en een welhaast verdubbeling van het risicoprofiel. IoT kan wel een killer-app worden voor IPv6 maar is dat vooralsnog niet. Het verhaal zal écht een heel stuk steviger en urgenter moeten worden, wil je de terechte risico-aversie van een heleboel bedrijven op dit vlak doorbreken.
Thuis als hobbyist vind ik het een heel ander verhaal en ben ik al lang blij met het IPv6-subnet dat ik krijg aangeboden vanuit mijn ISP. Het feit dat je gewoon een volwassen /48 krijgt van XS4ALL, maakt dat ik mezelf een heleboel practices al eigen heb kunnen maken en ook al veel valkuilen heb gezien en ervaren. Technisch ben ik er dan ook helemaal klaar voor en een groot voorstander bovendien, alleen snap ik de weerstand aan de business-kant ook echt wel. Als IT'er met een technische pet doe je er goed aan jezelf nu al te bekwamen in de materie en ontwikkelingen te volgen, ook al komt de echte vraag pas over vijf jaar.
Goed verhaal Bassman, ik ga privé ook maar eens weer aandacht hier aan besteden. Wat je zegt; niets valt nog om dus er is geen directe dwang. Toevallig hebben we dezelfde provider, die vooruitstrevend is en idd dit soort dingen al langer voor het voet het voetlicht brengt :-)
Wacht maar af tot het KPN heet. Ik heb nu al elke dag een PPPoE error Hierdoor moet ik goed opletten dat ik soms met ssh een screen gebruik. Hebben we toch nog iets gemeenschappelijks :)
Dat KPN nog steeds PPPoE gebruikt, is mij al langer een doorn in het oog. Als je er dagelijks gedoe mee hebt, lijkt me dat er iets aan de hand is met hardware. Ofwel bij jou in de meterkast, ofwel aan KPN-zijde. Tijd om je provider aan zijn jas te trekken, mits het i.c.m. de door je provider geleverde apparatuur ook nog voorkomt.
Gelukkig is het meestal op een tijdstip dat ik nog op 1 oor lig, maar ik zal ze eens bellen voordat ik met een KPN manager te maken krijg :)
Daar heb je geen business case voor nodig hoor. Doen ze zelfs in Munchen niet meer aan :)
Nieuwe werkplekken en servers werken tegenwoordig out of the box ook met IPv6 . Address auto-configuration zit ingebakken in IPv6. Als beheerder gewoon doen ((AAAA DNS record) voor resources ( in de eigen webserver 1 listen regeltje extra) op je eigen netwerk (ipv6 is namelijk ook veel efficiënter). Thuis heb ik wel een paar keer gemerkt dat er nog wel eens websites zijn die niet goed zijn geconfigureerd voor ipv6.
Het zijn inderdaad 2 aparte netwerken. Malware komt met ipv4 :) Heb nog geen bridge kunnen ontdekken wel een tunnel.
En dus heb je wel een case nodig. Je geeft zelf aan waarom: extra inspanning (ook al is het niet veel) en faalkans. Dat wil niemand als er geen voordeel tegenover staat.
Reageer
Preview