Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Amazon betaalde 108 miljoen dollar voor 4 miljoen ip-adressen van radioamateurs

De Amateur Radio Digital Communications, een non-profitorganisatie, heeft vorig jaar een IPv4-block van ip-adressen aan Amazon verkocht voor in totaal 108 miljoen dollar. Het ging om zo'n vier miljoen IPv4-adressen, die voor gebruik door zendamateurs gereserveerd waren.

De verkoop van het 44.192.0.0/10-block van IPv4-adressen vond halverwege vorig jaar plaats, maar Amateur Radio Digital Communications was een geheimhoudingsplicht met Amazon overeengekomen over het totale bedrag. Die informatie maakt de president van de non-profitorganisatie voor radio-amateurs, Phil Karn, nu wel bekend. De organisatie zonder winstoogmerk gaat de opbrengst van 108 miljoen dollar investeren en verwacht hier jaarlijks minstens 5 miljoen dollar mee te verdienen. Dat geld steekt de organisatie in verschillende projecten voor radioamateurs. Begin dit jaar voorzag de ARDC bijvoorbeeld het GNU Radio Project van financiële ondersteuning. GNU Radio Project is een twintig jaar geleden gestart project voor een opensourcetoolkit voor op software gebaseerde radio en andere applicaties voor signaalverwerking.

ARDCDe verkochte ip-adressen maken deel uit van het Amateur Packetradio-netwerk, AMPRNet, ook wel Network 44 genoemd. In 1981 werden zestien miljoen ip-adressen in de 44.0.0.0/8-reeks gereserveerd voor gebruik door radioamateurs, die de adressen voor hun digitale communicatie kunnen inzetten. Radioamateurs wereldwijd kunnen een aanvraag doen om een of meerdere adressen te gebruiken.

De medewerkers van Amateur Radio Digital Communications bekijken die aanvragen en kunnen na goedkeuring adressen van 44.0.0.0 tot 44.191.255.255 verstrekken, zonder dat hier verdere kosten voor in rekening worden gebracht. De organisatie heeft als doel om wetenschappelijk onderzoek naar nieuwe protocollen en technieken voor draadloze netwerken te bevorderen en dan met name voor radioamateurs. Het besluit om aanvragen al dan niet te honoreren, wordt hier dan ook aan getoetst.

IPv4-adressen voor Nederlandse zendamateurs

Nederland heeft in de jaren tachtig de 44.137.x.x-reeks toegewezen gekregen voor gebruik door zendamateurs. Het is nog steeds mogelijk een aanvraag te doen naar een adres in die reeks, bij Rob Jansen, alias PE1CHL, de beheerder van de ip-adresruimte. Gebruikers kunnen via zo'n adres verbinding maken met andere AMPRNet-gebruikers via een OpenVPN-verbinding vanaf hun computer of telefoon met internetverbinding.

AMPRNet is een netwerk voor radiocommunicatie op basis van het Amateur X.25-protocol. Het gaat dan om communicatie op basis van packet switching. Met name in de jaren tachtig was packet radio populair, inmiddels maken zendamateurs gebruik van het Highspeed Amateur Multimedia Network, kortweg Hamnet. De hoogtijdagen van AMPRNet lagen tussen 1988 en 1995, maar zelfs toen gebruikte de gemeenschap van radioamateurs nog niet eens de helft van de toegewezen ip-adressen. De Amateur Radio Digital Communications, eigenaar van Network 44, verwacht ook niet dat de overgebleven adressen nog gebruikt gaan worden. Door de schaarste aan IPv4-adressen, is de waarde ervan nog hoog, maar de non-profitorganisatie redeneerde dat de waarde wel eens kon dalen door de opkomst van IPv6. Daarom werd besloten het block te verkopen, ook omdat Amazon met zo'n 27 dollar per adres een goede prijs bood.

Het techbedrijf was met dat bedrag de hoogste bieder. Inmiddels staan de adressen op naam van Amazon Web Services Elastic Compute Cloud. Amazon zet deze dus in voor zijn clouddienst. Amateur Radio Digital Communications heeft geen plannen om meer ip-adressen te verkopen.

De prijsstijging van IPv4

De prijs van een IPv4-adres is in de afgelopen jaren gestaag toegenomen. Was de gemiddelde prijs in 2015 nog zo'n 6 dollar, in 2018 liep dat op naar 17 dollar en deskundigen verwachten volgens het leasebedrijf voor ip-adressen Heficed dat de prijs kan oplopen naar 35 dollar. Hoewel dat bedrijf een belang heeft bij het communiceren van prijsstijgingen voor ip-adressen, toont het betaalde bedrag van Amazon aan dat bedrijven inderdaad bereid zijn flink te betalen voor de resterende IPv4-adressen.

IPv4 prijsverloop
Verloop IPv4-prijzen en omvang van verkoopdeals IPv4-verkoop, bron: IPv4 Market Group

Dat de IPv4-adressen beginnen op te raken is al lang bekend. Eind vorig jaar deelde RIPE NCC, de organisatie die ip-adressen in Europa, Rusland en West-Azië verstrekt, zijn laatste deel van de nog beschikbare IPv4-adressen uit. Organisaties kunnen nog wel de naar schatting miljoen IPv4-adressen die niet of niet meer in gebruik zijn herverdelen. Ondertussen is de sector bezig met de overstap naar IPv6. Wereldwijd staat het percentage IPv6 Capable inmiddels op 27 procent van de internetgebruikers. IPv6 gebruikt 128bit-adressen, waardoor het totaal aantal in theorie beschikbare adressen 2128 bedraagt. Bij IPv4 zijn maximaal 232 adressen te vergeven, al hangt de beschikbaarheid in de praktijk van meerdere factoren af, onder andere dankzij bijvoorbeeld multicastadressen.

Door Olaf van Miltenburg

Nieuwscoördinator

13-10-2020 • 13:54

152 Linkedin

Reacties (152)

Wijzig sortering
Bij IPv4 zijn maximaal 2^32 adressen te vergeven.
"
Da's wat te kort door de bocht, want 224.0.0.0–239.255.255.255 is bijvoorbeeld een multicast range die je niet in de pool kunt uitdelen, ook een block van 4 miljoen adressen bedoeld voor local loopback is niet mogelijk, en wat te denken van de private adres reeksen? 192.168.0.0–192.168.255.255 / 172.16.0.0–172.31.255.255 / 10.0.0.0–10.255.255.255. Dus van de beschikbare 4.294.967.296 adressen kun je maar maximaal 3.706.452.992 uitdelen.
Hoezo? Die adressen die je noemt zijn toch gewoon vergeven voor specifieke doeleinden? Dat is toch precies wat hier wordt bedoeld?
Ja en nee. De Class E range, 240.0.0.0/4, bruto zo'n 268 miljoen adressen, zijn wel altijd gereserveerd geweest maar nooit vergeven. Alleen zijn plannen om die range alsnog in te zetten gestrand op de beperkte/buggy support in veel apparatuur die 'voor het gemak' alles boven 224.0.0.0 als private ziet. Om dat aan te passen kan je net zo goed naar IPv6 aanpassen om het probleem definitief op te lossen ipv alleen maar wat meer tijd te kopen.
Die adressen die je noemt zijn toch gewoon vergeven voor specifieke doeleinden?
Nee, je moet het in de context van het artikel zien dat Amazon(AWS) een blok koopt uit de 2^32 "beschikbare" adressen, ik duid alleen dat door mitsen en maren de keuze in de pool veel kleiner is dan die 2^32 wat het artikel suggereert. Zie het als iemand die een /24 heeft gekocht en denkt daar 256 hosts onder te kunnen brengen omdat 2^8 toch echt 256 is, en dan blijkt dat je 0&255 niet in je range mag opnemen omdat het de network identifier & broadcast address is, daarmee ze zijn niet vergeven, maar simpelweg door wetmatigheid niet te kiezen.
In de private range kunnen de adressen niet echt op raken en ze worden ook niet uitgedeeld door een beheerder zoals bij de public range.
[...]
... ook een block van 4 miljoen adressen bedoeld voor local loopback is niet mogelijk
16 miljoen ;)

Loopback is 127.0.0.0/8, een totaal van 16 777 216 adressen.
Ja, ik dacht dat het een /10 was, maar ik heb mij verkeken op de 'shared addresses'
Thanks voor de verbetering, trouwens dat mogen wat mij betreft een stuk minder worden, ik gebruik uitsluitend 127.0.0.1 en 127.0.0.2, want wat moet je met 16 mln. (niet routeerbare)loopbackadressen?!?
Waarschijnlijk wou men het ruim nemen zodat ze niet later onvoorzien toch meer loopbackadressen nodig hadden en dat niet mogelijk was. Moeilijk te voorspellen dus ik snap het wel.
Omdat NAT nog niet bestond / bedacht / nodig was toen IPV4 uitgedacht werd. :)
zo kan je voor elk block of adres dat ergens al dan niet officieel voor gebruikt wordt zien als niet te vergeven, hence de huidige schaarste.

(je bent 127.0.0.0 en 0.0.0.0 trouwens vergeten :P )
Vergeet ook 100.64.0.0/10 niet, die wordt door ISPs gebruikt voor Carrier Grade NAT.
Bijzonder dat de zendamateurs al heel vroeg een eigen IPv4 block hebben bedongen/geclaimd. Weet iemand waar ze dat destijds voor nodig dachten te (gaan) hebben?

Zendamateurs zijn vaak heel technisch en hebben een gedegen examen moeten afleggen, maar dat zit hem vooral in de "analoge" materie lijkt me (zenders, zendmasten, vermogens, richtingsdiagrammen, repeaters). Natuurlijk is er wel digitale hardware, ook verbonden met internet (sites waar je bepaalde frequenties kan uitluisteren), maar ik als relatieve leek op dat gebied zou denken dat hun wereld zich vooral bevindt in de analoge lucht ;-)

[Reactie gewijzigd door Gitarist op 13 oktober 2020 14:34]

Vergis je niet, zendamateurs/ houdt niet per definitie in dat ze analoge verbindingen leggen via allerlei frequenties.

Al in de jaren '90 gebruikte zendamateurs (toen) al veelvuldig AX.25, door het aansluiten van een geschikt modem op zend- / ontvangstapparatuur kon men digitale signalen versturen via de ether. Later was het met een uitbreiding mogelijk om via een Radio Repeater en vervolgens het internet verbinding te maken met andere zendamateurs over de hele wereld.

Zo kon je verbinding maken met een zendamateur (Repeater-Station) in Rotterdam en via het repeater via internet en het repeater aan de andere kant contact maken met iemand die in de Verenigde Staten ook gebruik maakte van AX.25.

Wat je tegenwoordig ook steeds vaker ziet is dat zendamateurs gebruik maken van DMR Tier II. De werking is bijna het zelfde als AX.25. Wanneer een zendamateur zijn apparaat afstemt op een specifieke frequentie waarop een repeater actief is met de juiste credentials etc. kan men dan via die repeater praten met mensen over de hele wereld daar deze repeaters gekoppeld zijn via een IP-netwerk.

/ Dit alles even simpel uitgelegd door een niet zendamateur ;-)
Wat uitleg via: Wat is DMR Radio, Brandmeister, En wat velen niet weten maar zeker ook noemenswaardig is Dares alwaar zendamateurs hun kennis beschikbaar stellen wanneer communicatie netwerken (C2000, 112) bijvoorbeeld niet werken of wanneer zich een ramp voor doet.

[Reactie gewijzigd door DarkForce op 13 oktober 2020 15:37]

Niet alleen AX.25 maar ook regulier TCP/IP was al vroeg mogelijk op het Nederlandse Packet netwerk.

Ik (PE1KOX) heb vanaf 1999 enkele jaren de Packet Radio systemen op de KPN toren in Hilversum gebouwd en beheerd, eerst gebaseerd op de briljante software van PE1CHL (dezelfde Rob Janssen die in het artikel genoemd wordt), later een systeem bestaande uit twee computers, een Linux systeem en een AX node met software van Pieter-Tjerk de Boer PA3FWM. Om een idee te geven, het Linux systeem draaide op Slackware 7 met kernel 2.2.14, op een vette Pentium MMX met 32MB geheugen.

We hadden 4x 4800/9600 Baud links naar Eindhoven, Noordwijk, Apeldoorn en Medemblik(?), drie ingangen voor gebruikers (1200, 4800 en 9600 Baud), en een interlink naar het PI8GCB bulletin board.

Mooie tijden!
Ik meende mij te herinneren dat TCP/IP pas een jaar of 2 a 3 na AX.25 kwam. Wel ten tijden dat Packet Radio veelvuldig op CB werd gebruikt, enkele mensen hebben daar geëxperimenteerd maar helaas was het niet veel soeps.

Hoe het met TCP/IP op 2m en 70cm verliep weet ik niet, enige wat ik wel weet is dat AX.25 er inderdaad met snelheden werkte die op de CB gewoon niet (echt) haalbaar waren. Even uit mijn hoofd gebruikte ik voor hele korte tijd met een 3 anderen in de omgeving, iets waar "NOS" in voor kwam.
Ik (PE1KOX) heb vanaf 1999 enkele jaren de Packet Radio systemen op de KPN toren in Hilversum gebouwd en beheerd
Iets waar we bij Packet Radio op CB alleen maar van konden dromen. PE1CHL en PA3FWM komen mij op de één of andere manier bekend voor. Volgens mij iets omtrent NOS, TNC2's o.i.d.

Maar goed, feit blijft natuurlijk wel dat ook de (h)amateurs niet stil hebben gezeten en met werkelijk van alles bezig zijn geweest, en eigenlijk nog steeds zijn, dan alleen wat spraak of morse.


Goeie ouwe tijd.
@Z80 @DarkForce Dank voor jullie antwoorden, erg informatief! Wist niet dat er toen ook al veel data door de lucht ging (van zendamateurs)
De hardware is veelal analoog, maar daarover kan net zo makkelijk digitale data worden uitgewisseld, via modems en het IP protocol, net zoals we vroeger al internet hadden over analoge dial-up telefoonlijnen met modems. Voor IP communicatie zijn IP-adressen nodig, ook vroeger al.
Mijn 'ervaring' met zendamateurs is nog van 15-20 jaar geleden, maar toen was het vooral analoge spraak wat ze met elkaar uitwisselden. Geen data voor zover ik weet. Doen ze dat nu wel?
Dan snap ik inderdaad dat ze IP-adressen nodig dachten te hadden. Alleen veel minder dan dat ze in de jaren '80 verwachtten (aangezien ze een deel verkopen aan AWS).
Ook toen ging er al een behoorlijke bult data door de lucht. Fidonet was er met meerdere nodes te vinden.
En binnen de hcc gebruikersgroepen op het bbs zaten er ook zat in de lucht.
Ik had de pech in een kuil te wonen met rondom bos. Waardoor ik slechts bij ideale weersomstandigheden verbinding met andere nodes kon maken.
Ja hoor, de eerste packet radio (AX.25) gebruikers dateren van ergens in de jaren '70 en in de jaren '90 werd het zelfs veelvuldig gebruikt. Zelfs niet alleen bij zendamateurs maar ook bij de gewone CB-Radio gebruiker(s).

Naast AX.25 werden ook RTTY, PSK etc. gebruikt en werd overigens ook geëxperimenteerd met IP over radio waves binnen de 2m en 70cm frequentiebanden.
Dan heb je "packet radio" volledig gemist. Meer dan 20 jaar geleden was ik het relais station tussen een digitale node in Breda en één in Dordrecht omdat ik toevallig op een hoog punt zat die beiden kon "zien". Gigabytes op 9k6 verstuurd ...
Iedereen die vroeger vooraan stond met het uitdelen kreeg bijna een heel block, kennelijk hadden de zendamateurs een goede lobby en waren nauw betrokken bij het internet toen.

https://en.wikipedia.org/...4_assigned_address_blocks

[Reactie gewijzigd door GrooV op 13 oktober 2020 15:23]

Dat heeft weinig met lobby te maken denk ik. In 1981 had niemand kunnen denken dat internet en de daarbij benodigde IP adressen zo groot zou worden. Ik weet het van me zelf, ik kwam in 1994 in aanraking met internet via het instituut waar ik toen afstudeerde. Zoveel was er niet te doen, laat staan begin jaren 80. Begin jaren 80 werd er (denk ik) gecommuniceerd tussen universiteiten onderling die een aantal boeken hadden gedigitaliseerd (maar dat was destijds geen pdf).
Er komt maar 1 vraag bij mij naar boven. IPv6 is de gedoodverfde opvolger. Maar waarom is IPv4 nog steeds de standaard en verloopt de implementatie van IPv6 zo langszaam. de adoptie gaat wel erg langzaam en is niet erg hoog 35% volgens Google
De hoofdreden is de eeuwige menselijke eigenschap om niet te handelen totdat het bijna te laat is. Implementeren kost geld (mensuren, training, nieuwe hardware, software) dat je niet hoeft te investeren zolang het niet per se nodig is. Het is waarschijnlijk goedkoper als je er tijdig mee begint, maar de prioriteiten liggen dan nog vaak bij andere projecten. Een veelgehoord argument is dat er te weinig vraag naar is. Omdat het een architectuurprobleem is waar de gemiddelde eindgebruiker niks van hoeft te weten vind ik dat niet gek maar ook de verkeerde reden om het niet te doen.

Het verbaast mij ook dat er nog steeds bedrijven zijn die IPv6 niet als first-class citizen behandelen, bijv. Ziggo, Google Cloud Platform.

Ik had 20 jaar geleden al IPv6 draaien op mijn thuisnetwerk, maar het duurde vele jaren voordat providers het native begonnen te ondersteunen. De eerste 10-15 jaar heb ik tunnelproviders zoals sixxs.net en he.net gebruikt die IPv6 verkeer tunnelden door IPv4 tunnels. Niet snel en soms fragiel, maar het werkte. Het is echt werken geweest en regelmatig zeuren bij helpdesks om ondersteuning te krijgen.
De hoofdreden is de eeuwige menselijke eigenschap om niet te handelen totdat het bijna te laat is.
Dat is een beetje kort door de bocht, vind je niet?

Paar reallife redenen:
  • IPv4 zit ongelooflijk diep ingebakken in zowel technologie als kennis.
  • Daarbij is migreren vaak gewoon heel erg duur (arbeidsintensief en foutgevoelig)
  • Sommige systemen kunnen er simpelweg nog niet mee over weg. Dit is idd legacy, maar dat betekent niet dat het niet meer gebruikt wordt
  • Het alternatief, NAT, werkt gewoon heel erg goed en doeltreffend.
Edit: quote.

[Reactie gewijzigd door ZeverN op 13 oktober 2020 15:39]

NAT werkt goed? Hah...
Wanneer je IPv6 écht snapt, dan zie je pas dat het makkelijker is dan IPv4.

Mocht je inderdaad system hebben die niet overweg kunnen met ipv6, heb je NAT64.
Maar dan heb je het vaak over industriële machines/PLC’s, embedded systems E.D. Die je IMO toch niet direct op het internet wilt hebben.
NAT werkt goed? Hah...
Wanneer je IPv6 écht snapt, dan zie je pas dat het makkelijker is dan IPv4.

Mocht je inderdaad system hebben die niet overweg kunnen met ipv6, heb je NAT64.
Maar dan heb je het vaak over industriële machines/PLC’s, embedded systems E.D. Die je IMO toch niet direct op het internet wilt hebben.
Dit is denk ik waar de krux m in zit. Daarnaast de usability van ipv6, iedere ITer kent wel 127.0.0.1, 192.168.0.1, 8.8.8.8 etc. Maar ik ken persoonlijk geen enkel ipv6 adres en ik zou ook nooit de moeite gaan nemen om er eentje te typen vanwege het vreselijke formaat. Ipv6 is (of lijkt) complexer en minder user friendly als ipv4, wat de adoptie tegenhoud.
::1 is wel veel korter/makkelijker dan 127.0.0.1

De rest van IPv6 is ook zo te leren. Maar als je het nergens hoeft te gebruiken dan krijg je er ook geen ervaring mee.
Iedere IT'er kent ook zijn DNS-tooling zoals "dig" "host" en "nslookup".
Uiteindelijk leer je 2606:4700:4700::1111 of 2001:4860:4860::8888 uit je hoofd. Wat mij betreft een non-argument dat jij geen ipv6 adres uit je hoofd kent.
Enfin, een ping naar one.one.one.one of dns.google is bijna even snel te typen als het ipv4 adres.
Die real life redenen die je noemt zijn allemaal ontstaan uit het paradigma dat men pas hoeft te handelen als het echt nodig is (of zelfs erna pas).
Google cloud heeft toch al jaren ipv6. Als ik een domein moet linken, moet je beide ingeven. Het is niet omdat het niet de default is dat het er niet is. Ze willen gewoon alles bereikbaar hebben. Moet jij als bedrijf maar eens proberen alles alleen via ipv6 beschikbaar te maken, je zal snel van een kale reis terugkomen. Je wilt maximaal bereik, en niet veel omwegen, want beïnvloed dan je laadtijden. En deze wil je zolang mogelijk houden omdat mensen niet willen wachten, dus kip en het ei probleem. Nu ooit zal het moeten gebeuren. Liever eerder dan later.

En dan is er nog de software, sommige programma’s is geen actieve ontwikkeling meer op, maar worden wel dagelijks gebruikt. Natuurlijk als dit op een intern netwerk is maakt het niet uit uiteraard, daar draai je wat je wilt. Ik ken bedrijven die nog altijd een update naar Windows 10 aan het proberen zijn ...
Ja, in veel scenarios ondersteund GCP inderdaad IPv6 maar in andere maar ten dele of met teveel mitsen en maren. Neem van mij aan dat IPv6 op GKE Kubernetes op redelijke schaal (lees honderden applicaties) praktisch niet te doen is.

Bijv.: Je kunt een Google Load Balancer gebruiken die IPv6 ondersteund, maar dan móet die LB ook als Ingress functioneren dus TLS-offload doen en dan worden er maximaal 10 TLS certificaten per LB toegestaan. Je hebt dus tientallen LB's nodig om honderden applicaties te ondersteunen. Dat wordt een dure en complexe grap. De 'standaard' werkwijze in k8s, om een LB met daarachter een Ingress (bijv. Traefik of nginx) te draaien in je cluster en cert-manager te gebruiken om Let's Encrypt certificaten voor je te managen, is praktisch niet te realiseren met IPv6 op GCP, in ieder geval niet op onze schaal. Als voorstander van IPv6 ervoer ik dit als frustrerend tijdens onze migratie naar GKE.

Daarentegen draaien wij bij AWS al ruim 4 jaar 100% op IPv6. Er is geen 1 op 1 vergelijk mogelijk natuurlijk en ik beweer ook niet dat een groot deel van de GCP klanten niet voldoende heeft aan het huidige aanbod maar voor ons was het een obstakel in wat toch een van de flagship producten van GCP is. Ik ben me als ervaren IT-er echt wel bewust van de problemen en moeite die je beschrijft, maar als iemand hier oplossingen voor zou moeten kunnen vinden is het wel Google.
Ik snap wss. IPv6 niet goed, maar het lijkt me gewoon veel overhead om IPv6 te implementeren (zelfs gewoon op mijn thuisnetwerk).

Ik heb nu meerdere VLAN's thuis in de 192.168.0.0/16 range. Maar als ik het goed begrijp is IPv6 by default "publiek" en krijgt elk apparaat een publiek IPv6 adres van je provider? Dus moet ik ook extra firewalling gaan doen? En ook mijn bestaande IPv4 firewall rules (om verkeer tussen VLAN's te restricten) moeten overgezet naar IPv6.

Het lijkt me allemaal complex en omslachtig, en als ik onbewust iets verkeerd doe heb ik misschien apparaten die publiek bereikbaar zijn over IPv6, zonder dat ik het weet...

En de meerwaarde voor mij persoonlijk is op dit moment nihil (voorlopig toch), want elke website is nog steeds via IPv4 bereikbaar.

Dus laat ik IPv6 links liggen, en blijf ik bij mijn IPv4 setup achter NAT. En ja, er zullen wel nadelen zijn aan NAT, maar ik denk dat de meeste eindgebruikers hier bitter weinig last van hebben.
Dat klopt. Het is voor de eindgebruikers met een simpele router en enkele devices ook niet interessant om er iets van te weten. De provider rolt het uit en dat is dat. Ze zullen het niet eens merken. Mensen die hun netwerk opsplitsen in VLAN's e.d. krijgen er inderdaad wel mee te maken.

Het is een apart protocol, naast IPv4. Je hebt dus een dubbel nummerplan, dubbele firewall, etc. Voor IPv6 krijg je van je provider een /56 netblock toegewezen waarbinnen je mag doen wat je wilt. Het is aan je router om de adressen verder te verdelen, net zoals nu. Je krijgt bijv. 2001:DB8:1234::/56, waarbinnen jij voor je VLAN's de subnetten 2001:DB8:1234:1::/64 & 2001:DB8:1234:2::/64 toewijst. De devices in je netwerk kiezen automatisch een random adres in die range, of je wijst ze expliciet adressen toe via DHCPv6 of statisch, zoals 2001:DB8:1234:1::1/128. De automatische adressen wijzigen continu zodat je niet makkelijk te identificeren bent op het internet. Al die adressen zijn wel publiek routeerbaar, dus zonder NAT, maar niet zomaar bereikbaar.

De werkwijze bij firewalls is namelijk hetzelfde als bij IPv4. Standaard wordt alles inkomend geblokkeerd en kun je gaten maken voor dingen die je door wilt laten. Als je apparaat zowel via IPv4 als via IPv6 bereikbaar is en je een poort publiek wilt maken moet je in de firewall dus én een port-forward maken voor IPv4 én een accept-rule voor IPv6 om het via beide protocollen bereikbaar te maken. Per ongeluk apparaten publiek bereikbaar maken is echter niet waarschijnlijk, net zomin als je nu per ongeluk een port-forward aanmaakt.

Ook in DNS maak je records aan voor zowel het A (IPv4) als het AAAA (IPv6) adres van een host. Clients die het adres van een host opvragen krijgen zowel het A als het AAAA respons terug en proberen dan eerst via IPv6 te verbinden. Lukt dat niet dan vallen ze terug op IPv4. Browsers maken nog gebruik van een "happy eyeballs" algoritme waarbij ze zowel IPv4 als IPv6 tegelijk proberen en de verbinding kiezen die het snelste reageert.

Het klinkt wat complexer dan het is, maar er is zeker een leercurve. IPv6 is iets sneller maar dat zal de gemiddelde gebruiker niet merken. Voor mij is de meerwaarde vooral het verbinden met mijn eigen servers. Met NAT kon ik maar één webserver op poort 80 of 443 hosten op mijn publieke IP. Wilde ik er nog een, bijv. mijn NAS en een Raspbery Pi, dan moest ik andere poortnummers gaan forwarden en onthouden, zoals 8080, 8443, etc. Bij IPv6 heb ik poort 80 op de NAS en poort 80 op de Pi beiden geopend in mijn firewall, de IP's toegevoegd aan mijn DNS en klaar. Beide servers zijn op een eigen naam bereikbaar, net als een webserver in een datacenter. Voor mensen die in IT, Operations, webdev, e.d. werken zoals ik is dat heerlijk simpel. Ik kan ook gewoon SSH-en naar de juiste server zonder gedoe met bastion-hosts, poortnummers, etc. Ik zal wel blij zijn als IPv4 niet meer nodig is en we dus niet meer dual-stack hoeven te beheren.

Goed mogelijk dat dat voor jou niet interessant is en dan kun je inderdaad beter wachten. Persoonlijk vind ik nu een goed moment om te leren er mee om te gaan. Uiteindelijk zal alles via IPv6 gaan dus vanuit professionele en persoonlijke interesse wil ik ermee kunnen werken.
Natuurlijk moeten we over op ipv6 maar tegelijkertijd vraag ik me af of we niet eens kritisch naar de niet of weinig gebruikte blokken moeten kijken. Weet toevallig dat bij de Nederlandse (semi) overheid nog genoeg blokken vrij zijn en kan me niet voorstellen dat dit internationaal anders is

[Reactie gewijzigd door Mellow Jack op 13 oktober 2020 14:01]

Dat is een druppel op de gloeiende plaat, IPv6 is de enige duurzame oplossing en garandeert ook end-to-end connectiviteit (geen NAT meer). Eigenlijk verbaasd het me dat Amazon nog zoveel geld investeert in fossiele IP-adressen.
Die "geen NAT meer" is wat mij juist tegenhoud om IPv6 te gebruiken. Al mijn apparaten thuis hebben een private IP dat niet van buitenaf bereikbaar is. Met IPv6 krijgen dus die dus wel een publiek IP en worden al mijn apparaten by default publiek? Dus moet ik zelf met IPv6 firewalling gaan beginnen spelen en hopen dat ik het allemaal juist heb ingesteld en per ongeluk niks over het hoofd heb gezien, waardoor mijn IP cams voor het hele internet zichtbaar worden via IPv6?
Aangezien veel devices tegenwoordig via UPnP al automatisch door een firewall prikken, zonder dat de eindgebruiker dat weet (die hebben daar allemaal geen verstand van), denk ik dat het risico dat je IP Cam publiek beschikbaar wordt bij IPv4 groter is dan bij IPv6.
Valid point, maar ik sprak over mijn situatie, en hier staat uPNP uit :-D

Maar deze topic heeft mij aangemoedigd om toch IPv6 nog eens een kans te geven, en blijkbaar zijn de zaken er toch wat op vooruit gegaan sinds mijn laatste poging. Op minder dan een uurtje tijd toch IPv6 aan de praat gekregen in mijn Unifi setup met meerdere VLAN's, en blijkbaar waren de juiste firewall profielen ook al aanwezig om inkomend IPv6 verkeer te blokkeren.

Dus ja, happy me ;)
Je hoeft helemaal niet te spelen met firewalling aangezien een goede firewall als default policy alles dicht heeft staan. Dus je moet dan expliciet dingen open gaan zetten als je wil dat iets bereikbaar wordt vanuit de buitenwereld.
Zolang er vraag naar is zal er gezocht worden om aan de vraag te voldoen. AWS gaat niet tegen zn klanten zeggen dat ze moeten IPV6 gebruiken, dan gaan die klanten weg...
En toch zal er op termijn steeds meer aanbieders zijn van 'cloud'-oplossingen die geen IPv4 meer kunnen verstrekken. Simpelweg omdat het op is.

Grappige is wel, dat Amazon nog zo inversteerd in iets wat over korte tijd vrijwel al zijn waarde gaat verliezen. Nu is ipv4 redelijk schaars. Dat drijf de prijs. Wanner iedereen ipv6 heeft en gebruikt is ipv4 overbodig.
IPv6 bestaat al sinds 1998. We zijn inmiddels 22 jaar verder, en ongeveer 27% van het internet is IPv6-capable.
Ik ga er van uit dat IPv4 nog gemakkelijk 15 jaar courant blijft.
In '98 was de eerste Draft. Pas sinds 2017 is het een standaard.
https://nl.wikipedia.org/wiki/Internet_Protocol_versie_6
Drafts zijn in de regel al wel voorafgaand aan standaardisering in een dermate vergevorderd stadium dat je al live kan. Behalve IPv6 zijn bijvoorbeeld ook wifi standaarden een bekend voorbeeld waarbij producten eerder live gaan dan de standaarden gedefnieerd worden.
Amazon geeft die 108 miljoen uit zoals jij en ik in de winkel "laat maar zitten" zeggen voor de 8 cent die we terugkrijgen van de kassamedewerker. Als ze daarmee nu een berg klanten tevreden houden, dan is dat hun die paar centen wel waard.
Rare wereld :)
Voor amazon is het een nobrainer investering. Ze zullen deze adressen uiteindelijk met dikke winst weer verkopen.
Je moet wel op tijd verkopen dan :)
Als iemand de cijfers heeft voor het juiste moment van verkoop dan is het Amazon wel :P
Ik denk dat moepie bedoeld aan de klanten van Amazon. Als je diensten afneemt bij AWS die een IP adres vereisen dan zit het gewoon in de prijs. En voor extra public IP adressen betaal je al gauw enkele Euro's per maand.
Ach waarschijnlijk kunnen ze die investering nog gewoon terugverdienen om het tempo waarin ipv6 geadopteerd wordt dus waarom zouden ze het niet doen?
Amazon heeft redelijk wat enterprise-klanten waar de overgang naar IPv6 wss vrij lang gaat duren. En die bedrijven willen gerust wat meer geld neerleggen op termijn voor een IPv4 adres. Je mag er zeker van zijn dat er binnen Amazon al de nodige rekensommen zijn gemaakt die bepalen of de aankoop van die IPv4 adressen rendabel is of niet ;)

Ik heb bij redelijk wat multinationals en overheidsdiensten gezeten als consultant, en geloof me, de meesten zijn echt nog niet bezig met IPv6 (of toch niet voor de eerste jaren).
Wereldwijd staat het percentage IPv6 Capable inmiddels op 27 procent van de internetgebruikers
Andersom geredeneerd kan nog blijkbaar nog steeds iets van 70% IPv6 gebruiken. Die potentiele klanten wil je als bedrijf niet negeren.
Ik denk dat NAT een zegen is, omdat anders de ongepatchte devices rechtstreeks aan het internet zouden hangen. Nu is een device achter een router nog relatief veilig als die niet gepatcht is. Hang je dat device rechtstreeks aan het internet, dan wordt die al snel misbruikt voor NTP amplification attacks, ...
Bij IPv6 moeten thuisrouters gewoon standaard een firewall hebben die inkomende connecties blokkeert, net zoals thuisrouters nu standaard NAT doen. Daarmee zijn devices achter zo'n router even veilig als nu.

NAT biedt qua security geen enkele meerwaarde boven een firewall, maar het maakt zaken vaak wel ingewikkelder. Het is dus zeker geen zegen, integendeel.
Ik mag hopen dat alle ISP het gebruik van die firewall verplicht stellen en je die niet volledig kan uitschakelen. Maar dan kan je altijd nog je eigen router gaan plaatsen, waarbij je het wel uitschakelt. Bij een single IPv4 adres is het gewoon niet mogelijk en moet je NAT gebruiken. De grootste fout die je dan nog kan maken is je computer als DMZ instellen zodat alles ook daar naartoe gaat.

Natuurlijk kan je een IPv6 veilig instellen, maar niet iedereen is netwerkspecialist en als het neefje even je firewall volledig uitschakelt omdat die torrent dan wel werkt dan wordt het internet daar niet veiliger op.

Ik ben me ook ter dege van bewust dat NAT vele nadelen heeft en dat het een beetje een beun-oplossing is, maar ik denk dat zonder extra maatregelen het internet bij IPv6 er potentieel onveiliger op wordt.
Ik mag hopen dat alle ISP het gebruik van die firewall verplicht stellen en je die niet volledig kan uitschakelen. Maar dan kan je altijd nog je eigen router gaan plaatsen, waarbij je het wel uitschakelt.
Natuurlijk moet dat ook uit te schakelen zijn. Daar zijn best goede use cases voor.

En natuurlijk moet die firewall standaard aan staan, en niet makkelijk uit te zetten zijn; voor de overgrote meerderheid van gebruikers is dat de wenselijke situatie.
Bij een single IPv4 adres is het gewoon niet mogelijk en moet je NAT gebruiken.
Tuurlijk is dat wel mogelijk. Zet je router in bridge-mode, en hang hem rechtstreeks aan je computer. Ziedaar, een computer rechtstreeks aan het internet.

Voor de meeste consumenten inderdaad niet wenselijk, maar in sommige situaties wel.
Natuurlijk kan je een IPv6 veilig instellen, maar niet iedereen is netwerkspecialist en als het neefje even je firewall volledig uitschakelt omdat die torrent dan wel werkt dan wordt het internet daar niet veiliger op.
Nee, maar dat geldt ook als dat neefje de router in bridge-mode zet, of de verkeerde poorten forwardt, of de virusscanner uitzet omdat die lastig is, of gecrackte software vol malware installeert, of, of, of...

Het gaat er niet om dat je het onveilig kan instellen, want dat kan nu ook. Het gaat er om dat de standaard setup (IPv4: NAT, IPv6: een simpele firewall) veilig genoeg is en niet te triviaal uit te zetten is.
... maar ik denk dat zonder extra maatregelen het internet bij IPv6 er potentieel onveiliger op wordt.
En ik denk dat dat bangmakerij om niks is. Het is eigenlijk gewoon dezelfde situatie, maar dan zonder de pijn van NAT. Je verzint allerlei doemscenarios over wat mensen allemaal fout kunnen gaan doen, maar dat kunnen mensen met nu met NAT ook al.

Vergeet niet dat ISPs ook niet zitten te wachten op geïnfecteerde klanten. Die kosten helpdesktijd, imagoschade (als de ISP niet genoeg gedaan heeft voor een standaard veilige setup), en verkeer van botnet-zombies is ook niet gratis.
"Bij een single IPv4 adres is het gewoon niet mogelijk en moet je NAT gebruiken."
Tuurlijk is dat wel mogelijk. Zet je router in bridge-mode, en hang hem rechtstreeks aan je computer. Ziedaar, een computer rechtstreeks aan het internet.
Hooguit één computer en niet alle (deels onveilige) smart devices in je huis. Dat is geen situatie die mensen lang zo zullen laten, omdat het onwerkbaar is. Bridge-mode is dus helemaal geen issue in de praktijk.
Nee, maar dat geldt ook als dat neefje de router in bridge-mode zet, of de verkeerde poorten forwardt, of de virusscanner uitzet omdat die lastig is, of gecrackte software vol malware installeert, of, of, of...
Die bridge-mode is niet zo'n probleem in de praktijk, omdat de rest van je apparatuur dan meestal geen internet meer heeft. Malware blijft inderdaad een issue en ik zou het ook prima vinden dat je ISP je tijdelijk kan afsluiten als er blijkt vanaf jouw IP er grote ellende ontstaat. Bescherming van het netwerk gaat wat mij betreft voor.

Als met IPv6 een firewall niet triviaal is uit te zetten, dan heb ik er niet zoveel problemen mee. Ook eens dat ISP niet zitten te wachten op ellende in hun netwerk, maar ik ben benieuwd hoe het zal gaan met IPv6. Gaat toch nog wel een tijd overheen voordat het de standaard is.
Iemand die zijn eigen router installeert én de firewall uitschakelt heeft genoeg besef om te weten dat een misconfiguratie problemen kan geven. Ik ben nog geen enkele consumenteninstallatie van IPv6 tegen gekomen die niet via een firewall afgeschermd was door de provider. Veel providers filteren daarnaast aan hun eigen kant allerlei potentieel kwaadaardig inkomend verkeer, zoals SMTP, NTP, als veiligheidsnet tegen dit soort misconfiguratie.

Ik denk dat de voordelen van het afschaffen van NAT opwegen tegen de risico's die je noemt.
Ik kom sowieso geen consumentinstallaties tegen met IPv6, tenzij het specialisten zijn die graag IPv6 willen. Ik hoop alleen dat de standaardrouters het erg lastig maken om de firewall volledig uit te schakelen. Dat is eigenlijk het enige dat ik wou melden. :-)
Mee eens. De defaults moeten goed zijn en de gemiddelde consument beschermen tegen zichzelf.

Ik kom trouwens verrassend veel installaties tegen. Mijn provider heeft het aan staan, de provider van mijn ouders ook. Alleen op het werk hebben we het nog niet. De provider levert het wel, maar onze router ondersteund het niet.
Daarom sta je ook alleen expliciet verkeer toe van buiten naar binnen, standaard dus al het verkeer weigeren. NAT is geen security feature.
Ik denk dat NAT een zegen is, omdat anders de ongepatchte devices rechtstreeks aan het internet zouden hangen. Nu is een device achter een router nog relatief veilig als die niet gepatcht is. Hang je dat device rechtstreeks aan het internet, dan wordt die al snel misbruikt voor NTP amplification attacks, ...
Bij ipv6 hangt niets “zomaar” rechtstreeks aan het internet. Daar staan altijd de standaard firewall rules voor actief, waarbij niets mag behalve related en established van buiten naar binnen. (Iets wat vanuit binnen geïnitieerd is. Effectief is dit nagenoeg hetzelfde als NAT, zonder de overhead.

En dan heb ik nog een aantal VLAN’s thuis nog dichter gezet dan al standaard was. Die mogen niet naar buiten of extreem beperkt.
Wanneer je eindgebruiker geen IPv6 heeft kan deze geen IPv6 adressen bezoeken.
Dus zolang er veel eindgebruikers nog op IPv4 rondhangen zal er een vraag zijn naar IPv4 adressen voor bedrijven, diensten, overheden, etc.
Je kunt de bestaande IPv4 ruimte wel iets efficiënter benutten door organisaties te dwingen onbenutte ruimte vrij te geven maar het kost jaren (en waarschijnlijk miljoenen om organisaties hun netwerktopologie te laten aanpassen) terwijl het hooguit een paar maanden uitstel van IPv4 uitputting oplevert.

[Reactie gewijzigd door Maurits van Baerle op 13 oktober 2020 14:27]

Over die uitputting hoor je anders ook al decennia...
Klopt, daarom denken we ook dat port-forwarding en NAT normale dingen zijn, terwijl dat eigenljik pleisters op de IPv4 adresruimte wond zijn.
Een pure IPv6 wereld maakt communicatie tussen twee willekeurige apparaten op het internet zoveel eenvoudiger.
Het is natuurlijk nooit zo bedoeld, maar uiteindelijk heeft die pleister wel als gevolg dat apparaten nooit direct zonder expliciete goedkeuring van de eindgebruiker (port-forwarding) benadeeld kunnen worden van buitenaf.

Dat vind ik niet per se een nadeel :P
Totdat je twee corporate netwerken aan elkaar wil verbinden die beide al 10.0.0.0/24 gebruiken. Succes!

VPN tunnels er tussen, NAT achter NAT, etc. Allemaal om dergelijke dingen maar mogelijk te maken. Totale horror.

En met IPv6 blokkeer je standaard ook gewoon inkomend verkeer. Geen enkel probleem.
Dat weten wij, maar vergeet niet dat de gemiddelde consument dit niet weet.
Ik word al moedeloos als ik zie hoeveel mensen de connectie van hun 'smart home' apparaten zoals baby-cameras, thermostaten e.d. vrijwillig overhandigen aan de leveranciers.
Die pleister heeft er óók voor gezorgd dat alle IoT apparatuur die je vanaf je smartphone wilt kunnen bereiken een pijp(je) naar de Cloud leggen. Er is immers anders geen eenvoudige weg je netwerk in.

Dat vind ik wel per se een nadeel. :-(

[Reactie gewijzigd door Mijzelf op 13 oktober 2020 16:29]

Klopt voor mij is ipv6 op security gebied gewoon horror :p
Niet meer zoveel als vroeger want in het grootste deel van de wereld (waaronder hier in Europa) heeft die uitputting al een paar jaar geleden plaatsgevonden.
Er wordt zelfs in het 145.0.0.0/8 blok gebruikt als private range. Terwijl het volledige blok wel op naam van de overheid staat en minimaal wordt gebruikt.
maar de non-profitorganisatie redeneerde dat de waarde wel eens kon dalen door de opkomst van IPv6.
Gaat die uitrol nog wel zo hard als de handel in die ipv4 adressen booming wordt? Prijzen zijn de afgelopen 5 jaar grofweg verdubbeld.
Google ziet nu dat een derde van het al verkeer richting hun servers over IPv6 gaat en dat groeit gestaag door. De stijgende prijzen van IPv4 zullen dat alleen nog maar versnellen.

Er komt natuurlijk wel een kantelpunt. Ineens (maar niemand kan precies voorspellen wanneer) zullen IPv4 addressen hun waarde snel verliezen. Dat moment komt als het niet meer relevant is voor thuisgebruikers om allemaal een uniek IPv4 adres te hebben en ISPs ze op grote schaal op gaan geven. Dan zijn het alleen nog serverbeheerders die IPv4 ruimte willen hebben voor legacy gebruikers.

Dat kantelpunt hoeft niet noodzakelijk bij 50% IPv6 verkeer te liggen. Er zijn al een aantal landen waar IPv6 verkeer groter is dan IPv4 verkeer maar dat moeten er nog veel meer worden voordat wereldwijde effecten zichtbaar worden.
Zeker eens maar dit is voor Amazon een investering om de komende jaren nog IPv4 te hebben, het was een veiling en als Amazon ze niet gekocht had dan was het Google, Microsoft, Facebook, CloudFlare, Level3 of whatever geweest.

Ook al gaat AWS alles vanaf nu dualstack leveren zullen ze nog steeds voor iedere vps/server/firewall/proxy/web/cloud/whatever dienst een ipv4 adres nodig hebben.

En met een miljarden omzet is dit uiteraard een nobrainer voor Amazon om connectiviteit in de toekomst veilig te stellen, dat geldt ook voor alle andere clouddiensten.
Op een gegeven moment bereik je een kantelpunt waarop zowel steeds meer clients als servers op IPv6 zitten en het onbereikbaar zijn op IPv4 minder of zelfs niet meer van belang is. Op dat moment stort de markt van IPv4 in.
Daarvoor allicht al. Zodra 99% van het populaire internet via IPv6 te benaderen is, zullen wereldwijd veel providers hun nu waardeloze IPv4 adressen dumpen.

Veel providers zijn net als Ziggo, in principe eigenlijk al jaren klaar om over te gaan. Maar het staat op zo'n ontzettend laag pitje dat het maar niet opschiet. Maar als het financieel aantrekkelijk wordt (door bv snel die stapels IPv4 adressen te dumpen zonder dat klanten daar enige hinder aan ondervinden) zullen voor het einde van het jaar al hun gebruikers op IPv6 hebben zitten.
Die bedragen zullen alleen maar toenemen. Bijna 20 jaar geleden was er al het nodige te doen over de eindigheid van de range IPv4 adressen, en wonder boven wonder is het nog altijd goed gegaan. Destijds waren er universiteiten die een grotere adresrange tot hun beschikking hadden dan hele landen. Die ongelijke verdeling zal wellicht wat recht getrokken zijn, maar de overstap naar IPv6 wordt op den duur toch onvermijdelijk. Maar ook pijnlijk, dus tot die tijd zal er wellicht nog flink betaald worden voor IPv4 adressen.
LOL, men kan blijkbaar beter in IPv4 adressen investeren dan in goud... :+
En vervolgens wordt dit geld dus gebruikt om draadloze protocollen te ontwikkelen. Dezelfde draadloze protocollen waar het internet gedeeltelijk over loopt. Dat zelfde internet waar Amazon op leunt... handig.
Ik weet nog dat de TU Eindhoven ook zijn eigen B block had, ook in de jaren 80 toegekend omdat ze toen dachten dat het niet op kon. Philips had dat ook. De ICANN kwam op een gegeven moment aankloppen of ze dat aub terug wilde geven, weet niet of ze er een vergoeding voor hebben gehad.
Tja, 2020 en nog altijd grote partijen die er mee weg komen geen IPv6 uit te rollen naar consumenten...
En het wordt steeds duidelijker dat IPv4 op is en uit mag.

Dus Ziggo, schiet eens op! Niet alleen DS-lite, maar ook gewoon full dualstack in bridge mode! ;)
IPv4 is en wordt steeds meer voor de elite. We moeten gauw zoveel mogelijk over naar dual-stack. Helaas is bijvoorbeeld Ziggo daar te clueless voor.
Volgens mij draait Ziggo op delen van het netwerk al jaren dual-stack? Ik heb gewoon zowel een IPv6 range als IPv4 adres. Helaas wil het IPv6 subnet nog wel eens wijzigen, waardoor je op dit moment nog teveel zaken in de firewall van het modem moet regelen. Idealiter zou je dit allemal terminaten op een eigen router/firewall, maar dat kan dan weer niet met dual-stack bij Ziggo.
Nee, ze gebruiken of native IPv4 DS lite (native IPv6 + CGNAT).
Volgens mij verschilt dat nog steeds per regio. Ziggo geeft zelf aan dat ze afhankelijk van de locatie Full Dual Stack IPv6, Dual Stack Light IPv6 of IPv4 aanbieden.
Heb je enige informatie in welke regio's ze dual stack gebruiken? Wat zou de reden zijn dat ze het in sommige regio's wel en andere niet ondersteunen?
Helaas niet. Ik heb zelf het idee dat het enkel in (delen) van het oude Casema/Ziggo netwerk is en niet in het voormalige UPC netwerk. Dat maak ik ook op uit de threads op het Ziggo forum als je zoekt op full dual-stack en ds-lite. Maar alleen Ziggo weet het volgens mij zeker, en er is wel aangegeven dat de klant niet kan kiezen, omdat het van je regio afhangt. De enige optie die ze voorheen gaven was om toch weer van IPv6 met DS-Lite naar IPv4 terug te schakelen, zodat je op IPv4 weer bereikbaar was vanaf buiten.
Ja, daar heb ik destijds voor gekozen. IPv6 modem (Techicolor) was ook onstabiel. Inmiddels heb ik DSL met dual stack.


Om te kunnen reageren moet je ingelogd zijn


Microsoft Xbox Series X LG CX Google Pixel 5 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True