SIDN: prijzen van IPv4-adressen dalen weer na opkoopgekte tijdens corona

De prijzen van IPv4-adressen dalen weer, stelt de Stichting Domein Registratie Nederland. Volgens de SIDN komt dat onder meer doordat cloudproviders zulke adressen minder massaal opkopen. Ook daalt de behoefte aan IPv4-adressen nu IPv6 doorgroeit.

Het afgelopen halfjaar zijn de prijzen voor IPv4-adressen flink gedaald ten opzichte van de piek die in 2020 en 2021 was ontstaan, zegt de SIDN. De prijzen liggen volgens de stichting tussen de 30 en 40 euro, een significante daling sinds het hoogtepunt halverwege 2021, toen de prijzen tot tussen de 50 en 60 euro waren opgelopen.

De prijzen van IPv4-adressen liggen nog steeds hoger dan voor de coronacrisis, toen ze nog vaak tot maximaal 20 euro schommelden. De daling is dan ook relatief ten opzichte van de sterke prijsstijging van die periode. Tweakers schreef in 2022 ook al een achtergrondartikel over de prijsstijgingen. Die werden voornamelijk veroorzaakt doordat cloudbedrijven toen in allerijl IPv4-adressen begonnen te verzamelen. Inmiddels is dat opkopen grotendeels gestopt, wat de SIDN ziet als een oorzaak van het verlagen van de prijzen.

De SIDN ziet ook dat het aantal IPv4-routes niet meer toeneemt. De adoptie van IPv6 neemt nog wel toe, maar volgens de SIDN minder snel dan zou moeten. "De zorgwekkende conclusie is dat het IPv4-netwerk zijn werk nog steeds doet, maar dat dit ten koste is gegaan van de innovatie, openheid en diversificatie op internet", zo citeert de stichting Geoff Huston, chief scientist bij Apnic. "De markt heeft zich geconcentreerd rondom een klein aantal heel grote partijen die belang hebben bij risicoaversie, behoudendheid en controledrang. Daarbij lopen we het risico dat het huidige internet desintegreert."

Door Tijs Hofmans

Nieuwscoördinator

29-04-2024 • 17:45

125

Submitter: Anonymoussaurus

Reacties (125)

125
122
66
8
0
46
Wijzig sortering
De laatste alinea beschrijft het wel goed, IPv4 zit innovatie in de weg.

Voorbeeld: Europa zou graag een concurrent voor AWS, GCP of Azure willen. Stel het lukt je technisch deze te bouwen, dan moet je wel een IPv6-first/only cloud starten. Je kan simpelweg niet meer de IPv4 adresruimte verkrijgen om een serieus grote cloud te bouwen, die ruimte is er niet meer.

Je zal er dus voor moeten kiezen een IPv6-only cloud te bouwen waar je VM's, Databases, Caches, alles enkel via IPv6 bereikbaar is. Je kan daar dan voor een premium een IPv4 adres huren die je kan door proxy'en naar je IPv6 servers, maar primair zal alles op IPv6 moeten draaien.

IPv4 zit innovatie en expansie van het internet in de weg. Maar als je nu al IPv4 hebt, dan heb je daar helaas weinig last van.

IPv6 gaat de overhand krijgen en heeft dat op veel plekken al. Alleen niet iedereen begrijpt dat of wil het begrijpen.
Wat ik mij afvraag is hoe het zal gaan met de huidige en oudere online games en IPv6.
CGNAT is de grote bedreigen voor on-line spelen, dan is het niet meer doenlijk dat computers met elkaar contact kunnen maken. IPv6 biedt aldus grote kansen voor de spelfanaat.

Wat oude spellen betreft: Het klinkt tegenstrijdig, maar je moet juist overstappen naar IPv6 om IPv4 beschikbaar te houden voor wie dat nodig heeft. Alleen als de surfende en mailende meute naar IPv6 omschakelt, komen er IPv4-adressen vrij voor degene die oude soft- en hardware wil blijven gebruiken. In een wereld waar iedereen op V6 zit, zou je tegen een habbekrats een abonnementje voor een V4-tunnel kunnen afnemen en dan je oude V4-spellen kunnen spelen (V4-VPN-verbindingen zullen overigens altijd mogelijk zijn). Het is de huidige schaarste doordat mensen niet op V6 overstappen, die V4 duur maakt en degene die echt nood aan V4 heeft op hoge kosten kan jagen. Of het helemaal onbereikbaar maakt (als je CGNAT hebt).
Onderschat de gemiddelde consument niet met een smart lampje hier en een handig netwerkcameraatje daar. Voor je het weet zijn die niet zo netjes geprogrammeerd, dan werken die domweg niet meer op een ipv6 only netwerkverbinding. Of iemands niche site is verkeerd geconfigureerd en de provider krijgt de schuld, klant loopt weg. Ik ben groot ipv6 fan, maar snap die providers wel met altijd nog iets van ipv4 aanbod voor elke klant zolang het kan. Niemand wil de eerste zijn met zulk gezever.
Voor die simpele klanten is CGNAT een prima oplossing, die merken er niet zo veel van.
Laat het nu het geval zijn dat op "smart"-gebied de Aziaten mijlen voorlopen op Europeanen.
Het grootste gedeelte van Azie heeft geen IPv4.
Wil een producent dus producten afzetten dan moet hij IPv6 ondersteunen.
Als er genoeg fanaten last van hebben dan komt er echt wel een ws2_32.dll replacement of iets dergelijks die transparent IPv6 toevoegt aan IPv4 only applicaties/games.

Verder bestaat er nog altijd zoiets als VPNs, het heet niet voor niks... Private Network, gewoon iemand een VPN laten hosten op IPv6 en via de VPN IPv4 laten lopen, iedereen die wil spelen verbind en gaan met die banaan.

[Reactie gewijzigd door grasmanek94 op 22 juli 2024 20:03]

Verder bestaat er nog altijd zoiets als VPNs, het heet niet voor niks... Private Network, gewoon iemand een VPN laten hosten op IPv6 en via de VPN IPv4 laten lopen, iedereen die wil spelen verbind en gaan met die banaan.
Weer zoals we het vroegâh deden: Hamachi virtual LANs voor "local" network co-op :D
Het grootste probleem met IPv6, naast compatibiliteit, is dat zo'n adres gewoon niet te onthouden is wanneer die willekeurig gegenereerd is. 4x 3 cijfers is prima te doen, als ze daar een 5e keer 3 cijfers aan toe zouden voegen ook nog wel, maar 45 tekens die ook nog eens meer dan 0-9 zijn wordt toch wel een stuk lastiger, en dat is als systeembeheerder wel vervelend.
Tja, we kunnen daar heel moeilijk over doen, maar langere adressering was gewoon nodig. En dan ben ik blij dat men voor een flinke stap gekozen heeft, i.p.v. een kleine fix die over tien jaar weer vervangen moet worden.
Ben het met je eens dat in de onderlinge communicatie er nog wat verbeterd kan worden.

Je hebt toch tegenwoordig ctrl/command c en v keyboard shortcuts.

En qua verbaal communiceren zal je misschien een shorthand moeten ontwikkelen, voor je lookup, zodat je erna een copy/paste kan doen als support medewerker.

Bijvoorbeeld alleen de eerste en laatste x characters gebruiken. Hoe groot zal de kans zijn dat bijvoorbeeld de eerste 6 en de laatste 6 exact overeenkomen bij een en hetzelfde bedrijf in de ip pool? En als je een collision hebt, dan pak je de volgende 6.
Je hebt toch tegenwoordig ctrl/command c en v keyboard shortcuts.
Dat wel ja, maar er zijn genoeg situaties waar je die niet hebt. Als je fysiek bij een server staat om het netwerk te configureren bijvoorbeeld.

IPv4 is gewoon een stuk simpeler, en korter :)
Dat is ook wel weer zo. Maar ja, overtypen is iets anders dan onthouden
Welkom01 gebruik je zeker ook als wachtwoord?
Ik ben zo oud dat ik nog weet dat we een lokaal telefoonnummer hadden van 4 cijfers. Nu is dat 10. Het enige nummer dat ik uit m'n hoofd ken, is mijn eigen nummer. De rest staat in m'n telefoon. Dus misschien DNS gebruiken? Het enige IP adres wat je dan hoeft te onthouden is die van de DNS-server. Je prefix is vast en de rest kun je zelf bedenken en mag ook xxx::1 zijn.
Nog steeds is de wachtlijst voor IPv4 adressen in Europa echt heel lang, op het moment van schrijven staan er 1006 LIR's in de wachtrij voor een /24 block, de langste wacht al 483 dagen.

https://www.ripe.net/mana...s/ipv4/ipv4-waiting-list/
Voor de adoptie van IPv6 is er teveel nadruk gelegd op de client kant en te weinig op de server kant. Voor service providers is er nog enige reden om op IPv6 te gaan, omdat het aantal IPv4 adressen beperkt is. Als je een webserver hebt, is er werkelijk geen reden. Je zult IPv4 moeten aanbieden want je hebt IPv4-only klanten. Maar aangezien er nog geen IPv6-only klanten zijn, heeft IPv6 geen toegevoegde waarde.

Maak servers die IPv4 only zijn duurder. Standaardisatie gaat niet zonder enige dwang. De USB-C stekker, het metrische systeem in VS, om maar een paar dingen te noemen.

Adoptie is nu lineair en zo'n 3% per jaar. In dit tempo duurt het nog 18 jaar.
IPv6 heeft wel dergelijk meerwaarde, ook voor websites. Je hebt geen reverse proxies meer nodig, geen gedoe met NAT. Juist IPv6 maakt het hebben van meerdere webservers gunstig omdat je een overvloed aan addressen hebt. Sommige hosters rekenen ook al extra voor een IPv4.

Het zou helpen als er browser foutmelding kwam die je een IPv6-Only error kan geven als je op IPv4-Only zit. Is al een tijdje een feature request in Chrome maar denk niet dat het spoedig zal komen.

En overheden moeten internetproviders gewoon dwingen tot het uitrollen van IPv6. Het protocol is al meer dan 25 jaar oud en werkt uitstekend in de praktijk, voorlopig nog met dualstack, maar interne netwerken kunnen veelal IPv6-Only draaien.
Je hebt geen reverse proxies meer nodig? Gaat IPv6 ineens magisch mijn SSL offloading oplossen, of heb ik door IPv6 ineens betere HA mogelijkheden, of biedt het ineens betere beveiliging (scheiding van netwerken, centraal beheer punt).

Voor meerdere websites heb je niet ineens meer IPs nodig.

Ik heb thuis ook IPv6, maar in een datacenter omgeving kost IPv6 mij meer tijd om te onderhouden, beheren en beveiligen.

[Reactie gewijzigd door c-nan op 22 juli 2024 20:03]

In de basis is het precies hetzelfde als IPv4. Meerdere websites kunnen onder één IP draaien ja, maar dan ben je wel weer afhankelijk van SNI proxies. Subnetting en centrale monitoring is ook gewoon te vergelijken met dat van IPv4, het is zelfs nog iets simpeler omdat je subnets (bijna) altijd 64 bits groot zijn.

Als je al heel veel infrastructuur op IPv4 hebt draaien dan kan de overstap aardig wat voeten in de aarde hebben. Maar als je nu een nieuw datacenter bouwt, je clustering, beheer, beveiliging en je beschouwt IPv6 als een normaal, standaard protocol (de IPv6-first mindset) dan hoef je ook niet meer tijd te spenderen aan het onderhoud dan bij IPv4. Dualstacken is een lastig en helaas noodzakelijk kwaad in dit geval.
Anno 2024 is SNI gewoon standaard/default, wat is het probleem?

Wikipedia: Server Name Indication

Het zal aan mij liggen maar ipv6 is gewoon een draak, te complex. Anders zou de adoptie ervan echt veel sneller gaan.
.
  • Geeft een work-around aan die ipv4 ranzig complex maakt.
  • Gaat vervolgens ipv6 beschuldigen te complex te zijn. 8)7
IPv6 is de eenvoud zelve omdat je van al die complexiteit af bent.
SNI is geen work-around voor ipv4, IP komt niet in een certificaat voor en dit is een inherent gebrek aan het ontwerp van certificering.

En IPv6 is best complex, "ze" wilden teveel problemen tegelijk oplossen terwijl voor transitie slechts één ding prioriteit had, nl. adresruimte.

DHCP, DNS had best op de oude manier gehandhaafd kunnen worden, al dan niet tijdelijk, maar nu heb je meerdere adressen per device b.v. op basis van MAC adres dat toch niet helemaal uniek is, meerdere opties in de protocollen waar je van moet afvragen wat het effect is op netwerkbeheer.

Verder is de notatie buitengewoon mensonvriendelijk, het uitgangspunt dat slechts namen nodig zijn gaat voorbij aan het feit dat alles via IP ingeregeld wordt, niet via naam en zoek het maar uit.
Aan de andere kant, het gebrek aan adresruimte is het enige wat mensen dwingt te upgraden. Als je die dingen niet NU uitrolt zal het misschien helemaal nooit meer lukken. Ik denk niet dat een IPv7 ooit adoptie krigt.
Wat is er dan lastig aan als je uitgaat van prefix delegation en het hele idee van DHCP gewoon vergeet? Het systeem werkt namelijk perfect. En meerdere adressen per device is alleen maar handig. Zo hoef je lokaal alleen maar naar link local adressen te kijken. Die kun je voor bijv een router ook met de hand instellen op zeg fe80::1. Dat is nog korter dan 192.168.x.1 zelfs. En de adres ruimte binnen het subnet is gigantisch tegenover de 256 combinaties die je maar hebt met een klassiek /24 subnet.

Met IPv6 haal je m.i. juist complexiteit weg uit het netwerk. Met name NAT maar die dirty hack zijn we met zijn allen als heel normaal gaan beschouwen. Terwijl als je er even bij stilstaat het juist heel raar is om een router in elk data pakketje constant de adressering te laten aanpassen. Dat is alsof de koerier alleen maar een gebouwnummer op je pakketje zet en er een receptie is die telkens alles omstickert naar het juiste deurnummer. Dat zouden we met slakkenpost uiteraard nooit accepteren. Je wilt je eigen adres aan de voordeur en dat zou met IP-verkeer op elk device niet anders moeten zijn.
Ik denk dat "fe80::" genoeg zegt over de UX vaardigheden van de IPv6 bedenkers. Dat had gewoon "1::" moeten zijn. Ja, NAT kwijt, dat is een klein voordeel, maar eerlijk gezegd is dat ook wel het enige voordeel.

Ik heb net afgelopen vrijdag IPv6 aangezet op kantoor. Dat heeft me een hele dag gekost. Voor IPv4 was het 5 minuten. DHCP, 192.168.4.10-200, subnet mask /22, NAT is standaard, klaar.
Ik heb dit jaar ook IPv6 met PD aangezet op onze nieuwe router en dat kostte mij maar een paar minuten. Alle devices waren meteen IPv6 reachable. En wat fe80:: betreft, tja als je daarover valt dan ben je wel een beetje een mierenneukert. :P
UX is heel erg de vraag beantwoorden "kan het simpeler?" ::1 voor je lokale PC is logisch. Daar is over nagedacht. Dan is 1:: voor je lokale netwerk de logische keuze. 2:: zou al onlogisch zijn. Het is niet dat ik erover struikel, maar ik ben al niet de gemiddelde doelgroep.
En heb je ook netwerkscheiding met meerdere vlans en firewall rules? Ik zou ook graag ipv6 aanzetten bij ons maar met rond de 20 vlans heb ik nu al 1300 firewall rules op ipv4. Dat moet dan allemaal ook gedaan worden met ipv6, adres objecten aanmaken. Niet ondoenlijk, maar een flinke klus van maanden. Dus dat stel je dan uit
VLAN zit helemaal niet op de laag waar IP zich bevindt maar op de laag eronder. Die bestaat uit de netwerk frames die weer rechtstreeks op de fysieke laag eronder leunen. Deze frames kunnen getagged worden met een VLAN ID. Elk communicatieprotocol dat hier bovenop ligt (dus ook IPv6) kan gecombineerd worden met VLAN's.

Firewalls werken uiteraard ook gewoon met IPv6. Zonder zou een IPv6 router niet bepaald veilig zijn en je LAN onbeveiligd aan het internet hangen. Iptables bijv ondersteunt gewoon IPv6 via de ip6tables variant.
Firewalls werken uiteraard ook gewoon met IPv6. Zonder zou een IPv6 router niet bepaald veilig zijn en je LAN onbeveiligd aan het internet hangen. Iptables bijv ondersteunt gewoon IPv6 via de ip6tables variant.
Dat snap ik maar hoe kun je dan zorgen dat met ipv6 je desktop bv een vaste reservering geven? Want dhcp wil je niet meer. Kun je dan in RD iets regelen?
Een client stelt het IP-adres samen obv de prefix en het mac-adres. Mits de prefix niet verandert, heeft die client dus altijd hetzelfde adres. Voorwaarde is dan wel dat je de privacy setting op het device uitzet. Anders maakt deze wel elke keer een willekeurig adres aan. In Windows staat die setting bijv standaard aan maar is makkelijk uit te zetten. Intern kun je ook de link local gebruiken beginned met fe80::. Samen met het mac-adres is dat dus ook een statisch adres. Of je stelt natuurlijk gewoon fe80::1 op de router in, en dan fe80::2, fe80::3 etc op de overige devices. Die range is praktisch oneindig vergeleken met de 256 combinaties met een /24 IPv4 blok. Of prefix::2 op een machine als die routable moet zijn vanaf internet. Geen port forwards meer nodig. Je hoeft alleen maar de firewall op de router open te zetten naar deze machine.

Persoonlijk zou ik gewoon het auto gegenereerde IPv6 adres gebruiken en dit in je lokale DNS zetten. Of in een publieke DNS met een domein of subdomein als je die machine van buitenaf nodig hebt.

[Reactie gewijzigd door watabstract op 22 juli 2024 20:03]

Je moet het dus wel op de host zelf doen ipv op de firewall die nu onze dhcpv4 doet. Er is dus, behalve dhcpv6, geen systeem om dit centraal te regelen?
Als je bedoelt dat je per se de router de IP adressen wilt laten bepalen dan kan dat nog steeds, met DHCPv6. Ik zie het voordeel daar niet van, behalve hooguit dat het vertrouwd is. En let erop dat bijv Android het niet ondersteunt.

Het centrale afregelwerk zou ik op DNS niveau doen in de plaats. Geef elke machine een simpele naam in de DNS server settings van je router en je kunt ze allemaal op je LAN bereiken. Ik draai zelf thuis een pi hole en die fungeert ook meteen als DNS server voor het complete LAN. Voor het LAN gebruik ik de .hole TLD. Zo is de router bijv bereikbaar via router.hole en de pi 4 die als mediaspeler fungeert in de woonkamer via kodi.hole. En de pi hole zelf is pi.hole. Deze domeinnamen hangen zowel IPv4 als de link local IPv6 adressen aan in de interne DNS records. Die v6 adressen weet ik niet uit mijn hoofd maar dat hoeft dus ook niet. Moderne browsers geven v6 verkeer hogere prioriteit dus als ik bijv op de pi hole inlog via pi.hole dan gaat dat vanzelf via IPv6.

IP adressen zijn bedoeld voor machines. Voor mensen hebben ze het DNS systeem bedacht zodat we die lastige nummers niet hoeven te onthouden.
Dank, ik draai zelf Adguard in Home Assistant. Thuis is ook het probleem niet, op het werk moet ik nog bedenken hoe ik ipv6 kan implementeren zodat ik de juiste firewall rules kan blijven gebruiken.
Als je een lange lijst met rules hebt dan is IPv6 bijschakelen even wat lastig inderdaad. Maar goed, de bestaande rules stonden er vast ook niet in 5 minuten. Succes!
Ipv6 addressing ja. Ze hebben te veel tegelijk willen doen met ipv6. Prefix delegation, router advertisements, dhcp v6. Allemaal dingen die niet letterlijk doorvertalen en dus in praktijk wel eens misgaan. En haast overal krijgt heel het concept ipv6 de schuld. Er is onvoldoende gedacht aan KISS.
Prefix delegation gebeurt via router advertisements dus dat zijn geen losse dingen. Een IPv6 enabled lan device maakt verbinding en doet een router solicitation. Een router die ook gateway is antwoordt en stuurt de prefix waarop de client zelf zijn publieke extern routeerbare IPv6 adres samenstelt, naast een link local adres dat alleen via het LAN bereikbaar is.

DHCPv6 is m.i. bedacht om conservatieve twijfelaars over de brug te halen. In de praktijk zou ik die overbodige techniek gewoon vergeten. Er is niks ingewikkelds aan IPv6. Dat een dual stack oplossing de boel compliceert is een andere zaak maar dat betekent niet dat de overstap traag is omdat IPv6 ingewikkeld zou zijn. Dat is het namelijk niet.
Router advertisements, router sollicatiation, neigbour discovery, SLAAC. Het is niet simpeler geworden. En het is ook bepaald niet volwassen. Ik heb net even voor de grap gekeken wat de IPv6 status op ons netwerk is, sinds ik het op de router heb aangezet. Er zijn 285 IPv6 adressen verdeeld, en daarvan zijn er 274 in status "failed" en maar 11 "reachable". (Waarvan dan nog 1 onze ISP router is). Nee, we hebben geen oude Windows 8 machines of zo, alles hier is nog supported.
En dit is via DHCPv6? Niet alle clients ondersteunen dat namelijk. Android bijv al niet dus als je geen PD doet dan sluit je veel smartphones al uit. Voor IPv6 moet je DHCP gewoon vergeten en PD gebruiken.

DHCP voor IPv4 is overigens ook gewoon een compleet eigen protocol. Dat is echt niet eenvoudiger dan bijv PD. Alleen zoals ik al zei, zijn mensen dat zo gewend dat het als eenvoudig wordt ervaren. En wat een boer niet kent...
Het grote voordeel van DHCP is dat het simpel en volwassen is. Alle software support het. Koop een willekeurige WiFi router voor thuis, en alles werkt met de DHCP server van die router. Is het eenvoudiger dan IPv6 oplossingen? Ik denk het wel. Het werkt doorgaans out-of-the-box, met exact 0 instellingen.

IPv6 "PD" ? Ik moest het al googlen, "prefix delegation". Het is niet eens een optie in de IPv6 instellingen van mijn router.
Dan heb je wel een vrij obscure router. PD is ook simpel en volwassen. Het werkt namelijk gewoon. Al zeker 25 jaar. 🤷🏼
Ik zou Microtik niet obscuur willen noemen, maar ze hebben wel known issues met DHCPv6 wat maar half werkt. PD is niet eens een optie onder de IPv6 settings. Het werkt geloof ik nu via address advertisement, nadat ik EUI64 uitgezet heb
Ik ken het merk, heb er geen ervaring mee maar zou het obscuur genoeg willen noemen omdat het niet bepaald een mainstream merk is, ook niet in de grote corporate netwerken. PD is de go-to methode om een IPv6 netwerk op te zetten. Er is geen enkele reden om aan DHCP leases vast te houden want het werkt prima zonder.

Lang verhaal versimpeld: router advertisements met PD komen in de plaats van DHCP, en NAT verdwijnt want alle clients zijn routable van buitenaf. Niks complex aan. Voor interne diensten gebruik je link local adressen want die zijn statisch. Heb je een vaste prefix van de provider dan kun je ook prima de publieke wereldadressen gebruiken. Vanuit het perspectief van de router is het ook allemaal een stuk simpeler geworden: die hoeft niet meer interne en externe adressen in datapakketjes te pennen (NAT) en er hoeft geen DHCP table meer bijgehouden te worden met leases en expiry times. In een IPv6-only wereld waarin PD de standaard is en DHCP niet meer bestaat, is het leven van een netwerkbeheerder een stuk makkelijker.
Op het eerste gezicht en vanuit een IPv4 mindset lijken Router Advertisements, NDP en SLAAC heel erg eng. Toch werken RAs best handig en goed: je hebt geen centrale entiteit meer nodig waardoor het makkelijk kan schalen (bij DHCP zit je met lease tijden, moet je eventueel statische delegaties bijhouden en weer je pool inkorten) en bij IPv4 hebben we geen eens een mechanisme om dubbele adressen te kunnen detecteren, je moet maar hopen dat je DHCP server dan geen gekke dingen doet.

SLAAC kan meerdere adressen uitdelen (zo krijg je op een Windows machine zowel een vast als een roterend adres die wordt gebruikt voor outbound)

DHCPv6 is dan weer een compleet eigen gedrocht dat je gewoon niet hoort te gebruiken, met uitzondering van PDs.
Hoe regel je dan dat device 1 wel bij bepaalde resources mag met bepaalde poorten en device 2 niet? Dan moet je toch iets van een reservering uitdelen lijkt me. Kan dat ook met PD? Ik ben er thuis volop mee bezig maar dat is gewoon 1 netwerk. Hoe je het regelt met meerdere vlans en dan per vlan adressen uitdelen: geen idee nog
Router advertisements, router sollicatiation, neigbour discovery, SLAAC.
Drie termen voor nagenoeg hetzelfde. SLAAC de overkoepelende term, neighbour discovery wat je client doet, router advertisement wat je router doet. Als we alle componenten in DHCP gaan benoemen, zijn we veel langer bezig.
Het is niet simpeler geworden. En het is ook bepaald niet volwassen. Ik heb net even voor de grap gekeken wat de IPv6 status op ons netwerk is, sinds ik het op de router heb aangezet. Er zijn 285 IPv6 adressen verdeeld, en daarvan zijn er 274 in status "failed" en maar 11 "reachable". (Waarvan dan nog 1 onze ISP router is). Nee, we hebben geen oude Windows 8 machines of zo, alles hier is nog supported.
Het enige dat een IPv6-host nodig heeft om in de lucht te komen op v6 is ICMP. Er gaan geen ARP/RARP-pakketjes meer over je netwerk en er is geen DHCP-verkeer. Door middel van ICMP vinden ze je routers en geven ze zichzelf ip-adressen. IP6-adressen worden niet verdeeld, dat is een denkfout. Aan router-advertisements valt veel minder de te configureren dan een DHCP-server, de kans dat instellingen verkeerd staan is dan ook ook een stuk kleiner. Ik zou zeggen dat het haast niet fout kan gaan tenzij je de boel expliciet gaat saboteren door bijvoorbeeld ICMP te firewallen.
De reden dat we geen DHCP componenten hoeven te benoemen is omdat het gewoon werkt. Ik heb in 20 jaar inderdaad nooit hoeven afvragen wat DHCP options zijn. Ik weet toevallig van het bestaan, maar het werkt gewoon.

Maar SLAAC op IPv6 vereistte al op dag 1 dat ik wél naar de individuele componenten moest gaan kijken. Je kunt wel claimen dat "alleen ICMP" nodig is, maar hoe kan het dan dat de bulk van de machines faalt op een plat Ethernet LAN? Ethernet switches doen niets met IPv6, laat staan iets ingewikkeld als ICMP firewallen. De Ethernet switch kijkt alleen naar MAC.
De reden dat we geen DHCP componenten hoeven te benoemen is omdat het gewoon werkt. Ik heb in 20 jaar inderdaad nooit hoeven afvragen wat DHCP options zijn. Ik weet toevallig van het bestaan, maar het werkt gewoon.

Maar SLAAC op IPv6 vereistte al op dag 1 dat ik wél naar de individuele componenten moest gaan kijken. Je kunt wel claimen dat "alleen ICMP" nodig is, maar hoe kan het dan dat de bulk van de machines faalt op een plat Ethernet LAN? Ethernet switches doen niets met IPv6, laat staan iets ingewikkeld als ICMP firewallen. De Ethernet switch kijkt alleen naar MAC.
Ik zou eerder kijken naar triviale zaken, als "heb ik iets uitgezet?", dan in SLAAC duiken, de kans dat je de oorzaak in het binnenwerk gaat vinden is gezien de trivialiteit van het mechanisme klein. Je machine hoort de advertisement niet of hij negeert hem, dat zijn zo'n beetje de twee mogelijkheden.

Het is een ervaring die ik niet deel, mijn ervaring is vinkje zetten in de router en alles in het netwerk heeft een v6-adres, vaak zelfs inclusief apparaten die in hun configuratie niet eens ipv6-instellingen hebben.
DHCPv6 is m.i. bedacht om conservatieve twijfelaars over de brug te halen. In de praktijk zou ik die overbodige techniek gewoon vergeten. Er is niks ingewikkelds aan IPv6.
Dit is toch complex. Het bestaat wel, maar je moet het maar vergeten. Staat ook nog regelmatig wel vrolijk bij een router in de opties. Mijn punt blijft: dit had allemaal met een veel kleinere stap gekund, veel meer op ipv4 gelijkend, en dan had je veel minder weerstand bij de adoptie gezien. 64 bits ipv 128 bits nog zo iets. Technologisch fan van ipv6, maar qua change management onhandig.
En dual stack heb je al snel eens nodig qua tussenfase. Dat moet je juist meenemen in zo een design, dat miljoenen mensen wereldwijd jarenlang beiden moeten kunnen. Voor een selecte groep gaat dat allemaal wel erbij, maar niet voor de massa. En waar is nu ipv6 nauwelijks succesvol: bij de massa

En dan bedoel ik niet per se consumenten. Maar nog heel veel meer mkb, kleine websites, iot en noem het allemaal maar op. Premium aanbod vast wel, maar doorsnee, budget, dat wordt nog een decennium dweilen helaas...
Dé massa weet niet eens iets van IPv4 dus ik vind dit wel spijkers op laag water zoeken. Voor Jan en alleman moet internet gewoon werken punt. Als een provider routers uitlevert en daarop gewoon IPv6 al heeft voorgeprogrammeerd (wat in grote delen van de wereld overigens al jaren gebeurt) dan merkt de consument er niks van. Wat nog moet gebeuren is dat al die luie IT'ers die IPv6 keihard negeren door het hoofd in het zand te steken eindelijk eens hun werk fatsoenlijk doen en zorgen dat alle cloud omgevingen, datacenters, servers, routers etc gewoon IPv6 ondersteunen. Deze discussie duurt nu niet eens jaren meer maar decennia. Het is gewoon belachelijk dat we het hier nog over hebben. IPv6 is zo simpel als maar zijn kan, simpelweg omdat je geen achterlijk NAT meer nodig hebt. En daar zou de discussie moeten stoppen. IPv6 is al wat, 30 jaar oud of zo? Het is bizar dat het archaische IPv4 nog zoveel support krijgt. Het gezeur mag nu wel klaar zijn.
Geen idee... ik zet het vinkje router-advertisements aan en kan het hele boek DHCP opeens vergeten. Als dat geen KISS is, wat dan wel.
Altijd een afweging voor wie de KISS is:
- Gebruikers
- Beheerders
- Ontwikkelaars

You can't have all three :p
Dat klopt natuurlijk wel en ik ben niet heel bekend met webhosting op grote schaal, maar zaken als reverse proxies zijn natuurlijk doodnormaal, in overvloed te krijgen en is het bekende materie voor beheerders. Het is dus niet dat men ineens voor een enorme uitdaging staat, waar dat met de overgang naar IPv6 wellicht wel is. Of, dat kost in ieder geval tijd (=geld).
Wat tijd kost, is continu om de beperkingen van v4 heen moeten werken. Reverse-proxy's zijn maar één voorbeeld van zaken die met v6 overbodig worden.
Ik weet niet genoeg van ipv6, maar mijn RPs zijn er niet alleen voor NAT if fwd, maar ook voor hardening (ssl, geoblock, ipban etc)

Ik zou dan ook nog steeds een RP willen voor mijn dienst, ook bij ipv6, toch?
Ik weet niet genoeg van ipv6, maar mijn RPs zijn er niet alleen voor NAT if fwd, maar ook voor hardening (ssl, geoblock, ipban etc)

Ik zou dan ook nog steeds een RP willen voor mijn dienst, ook bij ipv6, toch?
Ja, al die andere zaken wil je nog steeds. Het geheel wordt 1 stapje eenvoudiger omdat je geen NAT meer hebt. Minder onderdelen, minder problemen ;)

Conceptueel is het ook handiger als je verbinding van begin tot einde hetzelfde adres heeft, in plaats van dat je tijdens het definieren van je security policies ook nog twee verschillende adressen (intern/extern) in de gaten moet houden. Als je ook nog meerdere applicaties/diensten op dezelfde poort hebt draaien kan het nog weer een stapje lastiger worden.

Zonder NAT is eenvoudiger en dat maakt de kans op foutjes kleiner.
Minder onderdelen is minder werk.
Aangezien ik mijn firewall zowieso voor IPv4 geschikt moet maken is extra regeltjes opstellen voor IPv6 meer werk.
Die paar regeltjes voor de port-forward is dan het werk ook niet meer.
Ik gebruik IPv6 enkel en alleen als ik het (zakelijk) moet gebruiken en dan het liefst met een host alias zodat ik dat lelijke nummer niet te vaak hoef te zien ;)
Dat is helaas ook waar, het nadeel van een overganssituatie. Die had nooit zo lang moeten duren. Hadden we op 6 juni 1996 maar doorgebeten. Als we toen toch eens hadden geweten hoe groot internet nu is.
Maar, sorry voor de domme vraag, heb je dan een losse rp voor iedere server/ip ? Of routeer je het op dest address in de rp? Dus wel routing maar geen nat
Zie het als volgt:
In IPv4 heb je NAT. Pakketje komt binnen op de router. Gaat door de NAT (vertalen naar intern adres/poort wijzigen), dan door de firewall heen en eventuele andere RPs, daarna komt het pakketje bij de server.

Bij IPv6 heb je die vertaalslag van NAT niet meer. IPv6 pakketje komt binnen op de router en daar heb je een firewall rule die verkeer naar dit server adres X op poort Y toestaat. Hij laat dus gewoon het pakketje door maar past er geen NAT of andere poespas op toe. Daarna zijn je RPs verder gewoon hetzelfde.
Het is een keus, als je webserver dat gewoon zelf kan, zie ik niet waarom je het op een proxy zou willen. Maar je kunt het doen, de proxy bestond ook al toen er nog geen ipv4-tekort was.
Websites zijn vaak opgebouwd o.b.v. meerdere servers en een reverse proxy kan dat samenvoegen zodat je bijv geen last hebt van cross site scripting enz. Ook functioneert een reverse proxy vaak als load balancer, web application firewall en de centrale plek voor certificaat beheer (hoe graag security ook de backend encrypted wilt zien ;) )
Mijn punt was dus dat die wel mee valt. Vele van die zaken zijn gewoon gesneden koek, een WAF en LB heb je eigenlijk binnen enkele minuten draaien. Als je het van begin af aan op moet bouwen en uit moet vinden is het een ander verhaal, dan is IPv6 heel logisch.
Ja, en ik stel dat dat niet zo is :) Breder gekeken dus: Een firewall configureren met alle NAT-regeltjes kan je bijvoorbeeld zo grijze haren van de complexiteit bezorgen. Maar ook de kleine zaken: Naar een server ssh'en via een jumphost (met tot overmaat van ramp vaan een verkeerde firewall ertussen die keepalive blokkeert), kost alles bij elkaar toch handenvol tijd. Ik gerust te stellen dat in in een wereld zonder v4 veel productiever zou zijn in mijn dagelijkse werk.
Een jumphost wil je net behouden.
Niet elke server hoeft direct accessible te zijn via internet en wil je ook niet direct accessible hebben.
Management moet via een beveiligde manier gebeuren, dat heb je met IPv6 ook niet zomaar, daar komt een jumphost dan te pas.
Een jumphost blijft zijn nut behouden en zal blijven bestaan.
Ik heb inderdaad niet de illusie dat jumphosts helemaal verdwijnen net als dat http-proxy's niet helemaal zullen verdwijnen. Ik verwacht evenwel dat het gros van de jumphosts bestaat vanwege ip-tekorten en slechts een minderheid vanwege beveiligingsbeleid. Als het beveiliging is, dan worden vaak VPN's ingezet i.p.v. jumphosts.
Zelfs met een VPN heb je nog altijd een jumphost nodig, toch in een bedrijfsomgeving. Je wilt nooit vanuit je VPN rechstreeks naar een secured subnet gaan.

Maar de meeste mensen zetten in de prive nooit geen jumphost in. Voor een thuisnetwerk is het meestal nutteloos, daar zet je, als je een beetje it kennis hebt, een VPN voor op.

Reverse proxies gaan zeker en vast nooit verdwijnen, Alleen al om het gros van de SSL offloading te doen.
En verder zullen load balancers ook altijd blijven bestaan. Daar heeft ipv6 zelfs geen meerwaarde in want je wilt sowieso altijd een firewall tussen je reverse proxies/load balancers en je webservers. (en daar zit ook geen NAT tussen, gewoon aparte vlan's op de firewall getermineerd)
Het zal vast ergens gebeuren, ik kan geen voorbeelden van jumphosts die op die manier ingezet worden.
We zitten nu al op het punt waar de meeste grote internet providers in Nederland IPv6 ondersteuning bieden met uitzondering van Odido. Voor de meeste webservers is het zo simpel als een IPv6 adres toewijzen, voor het domein een AAAA record toe te voegen en klaar is kees. Natuurlijk komt er wel iets meer qua kijken qua beveiliging, maar de basis blijft hetzelfde. Het is zeker niet de grote kostenpost wat sommigen denken dat het is, terwijl IPv4 zich nu al heeft bewezen als een schaars goed waar de prijs erg volatiel is.

Een redelijk goede deployment zou zijn om je load balancers te dualstacken en voor de achterliggende servers IPv6-Only te doen. Je hebt dan nog een proxy voor IPv4 verkeer maar IPv6 hoeft daar niet langs. Naarmate meer mensen over IPv6 beschikken zal je de proxy steeds minder zien gebruiken totdat ie weg kan. Facebook maakt al gebruik van deze implementatie, alles draait IPv6 bij ze.
Als zakelijke KPN klant krijgt mijn werkgever geen IPv6. Dat was volgens de KPN medewerker alleen nog voor particulieren. Belachelijk antwoord vind ik, maar we krijgen dus geen v6. Idioot gedoe. Maar ik zal daar binnenkort eens werk van maken, want het is toch van de zotte dat onze zakelijke account geen v6 krijgt terwijl een minder betalende particulier het wel krijgt?
Ik heb zowel KPN EEN (op de zaak) als KPN kleinzakelijk thuis. Beiden glasvezel en met IPv6 blok. Bij KPN EEN ging dat niet met het KPN modem (eigenlijk een router). Voor mij geen probleem want ik gebruik op beide verbindingen eigen hardware (Unifi).
Het zou helpen als er browser foutmelding kwam die je een IPv6-Only error kan geven als je op IPv4-Only zit. Is al een tijdje een feature request in Chrome maar denk niet dat het spoedig zal komen.
Hé ja, impact op performance why not... alsof browsers bij veel mensen al niet genoeg ellende te verwerken hebben. Checken of een website veilig is, opslaan in de geschiedenis en synchroniseren met Google of Mozilla en dan ondertussen ook nog checken of een IPv6 record bestaat om vervolgens een foutmelding te tonen dat IPv4 niet beschikbaar is maar wel IPv6 en de gemiddelde surfer denken dat er iets met z'n internet aan de hand is omdat er iets niet werkt.

Nee dank je... een website werkt of een website (of welke service ook) werkt niet, ga geen meuk voorschotelen waar de gemiddelde boerenl*l niks van snapt en vervolgens gaat lopen klagen of de klantenservice gaat lastigvallen die toch niet kunnen zorgen dat IPv6 sneller wordt uitgerold.
"Je hebt geen reverse proxies meer nodig..."
Mja...het klopt dat het zonder reverse proxy kan, maar wil je zonder reverse proxy?

De reverse proxy is internet hardened.
Het is in een enterprise omgeving met honderden applicaties simpelweg niet mogelijk om alle applicatieservers hardened te krijgen.
De incompetentie bij levernciers is eenvoudigweg te groot.
Knal er een reverse proxy tussen en een hele grote hap van je vulnerabilities zijn verdwenen.

Met de opkomst van internet hardened reverse proxies, heeft ieder bedrijf toegang tot contenswitching en kan een kleine multinational gewoon alle hosting verzorgen met 1 of 2 IPv4 adressen (versus het minumum van 32 dat 15 jaar geleden gold)
Er ligt extreem veel ongebruikt IPv4 potenteel op de plank.
Als je 500 webservers hebt die door 50+ man beheerd worden, is er wellicht onzekerheid of al die servers allemaal de laatste beveiliging hebben. In geval een kleine omgeving is de overweging anders: Een webserver is prima internetgeschikt, de kans dat daar een lek in wordt gevonden is niet groter dan dat er een lek in een proxy wordt gevonden. Een revproxy is dan onnodige complexiteit.

Sowieso is de kans dat je webapplicatie een lek heeft vele malen groter dan dat er een groot veiligheidslek in bijv. Apache ontdekt wordt, daar zijn webservers simpelweg te volwassen voor. En tegen een lek in je webapplicaties helpt een revproxy helemaal niets.
Een Windows server is per-definitie kwetsbaar op het internet. Al is het maar omdat Windows nog altijd TLS1.0 ondersteunt.
De reverse proxy voegt geen complexiteit toe, maar neemt deze juist weg.
  • Je hoeft maar 1 NAT translatie en 1x 80 +443 open te zetten in de firewall voor al je webservers.
  • Je hoeft maar 1x je certificaat te managen voor al je webservers
  • Je hoeft maar 1x een configuratie te maken welke ciphersuite je wil toestaan voor al je webservers
  • Je hoeft maar 1x je score bij SSL-labs te bewaken voor al je webservers
Het is ook niet voor niets dat webservers de eerste Linux killerapp waren in de jaren '90. :)

Een Windows-server aan het internet hangen vereist wat meer voorzorgen. Toch werkt het basisrecept ook heel goed voor Windows: Een IPv6-adres toevoegen speciaal voor de webserver, de webserver is de enige open poort op dat adres. Het managementadres is bij ipv6 haast niet te achterhalen, de server gebruikt voor internetverkeer wat hij zelf genereert een tijdelijk adres volgens de ipv6 privacy extensions. Dus al je het managementadres niet weet, je komt er nooit achter. Zelfs al weet je mijn prefix, 2^80 mogelijke adressen, fijne wedstrijd gewenst.

Daarom, zelfs met Windows, ik zou het aandurven. Het is waarschijnijk lastiger dan onder Linux om alleen poort 80/443 op het webip-adres open te hebben, Windows is daar minder flexibel in. Wat extra maatregelen om het management-ip-adres af te sluiten, dan zou het zelfs met Windows veilig kunnen.

Maar, ik gebruik sinds 2005 geen Windows meer... een virtuele WIndows XP voor noodgevalletjes is de enige Windowsinstallatie die ik nog heb.
Tja, in een zakelijke omgeving (anders dan een hostingprovider) ontkom je lastig aan Windows: een Windows server voor het (brand)alarmsysteem, een Windows server voor de klimaat installatie, één voor de slagbomen, één voor het welkom-scherm bij de recepie, een stuk of wat servers om de Windows clientcomputers te beheren. Daar heb je al een hele serie aan opgelegde Windows webservers en dan heb je de business applicaties nog niet eens gehad.

Overigens heeft Windows ook wel signifikante voordelen als het gaat om identities en autorisaties binnen een bedrijfsomgeving. Heb je veel servers met 1 taak(set), dan is Linux al gauw een stuk beter dan Windows. Ga je 200 unieke servers neerzetten, met centraal beheerde delegation of control, dan kom je lastig om Windows heen, zeker als je gaat kijken naar de kosten.
Veel clients hebben al IPv6. Als alle servers ook IPv6 hebben hebben de clients geen IPv4 meer nodig, en daarna de servers ook niet meer.
En zo wacht iedereen op elkaar.
Zo lang alle clients nog beschikken over IPv4 is er namelijk geen enkele noodzaak om je servers IPv6 te geven. En zo lang de servers geen IPv6 ondersteunen, wil je als client perse IPv4 hebben.
Alleen bij Odido zijn ze nog niet over op IPv6 helaas. Zal wel aan het budgetmerk zitten.
Ik zie het probleem niet zozeer bij Odido liggen, maar meer aan de kant van sites die het nog steeds weigeren te implementeren...

https://whynoipv6.com/
Nee, Odido is de boosdoener. Klanten lopen al jaren te smeken om IPv6, maar ze blijven het stoïcijns weigeren. De forumsbeheerders weten ondertussen niet meer wat ze moeten zeggen. Dat er websites zonder v6 zijn is nul reden om geen v6 te willen hebben.
Ik ben klant bij Odido en het interesseert me echt helemaal niks. De meeste klanten zullen niet eens weten wat ipv6 is.

Dat het tijd wordt dat ze het wel implementeren mogen duidelijk zijn maar om nou te zeggen dat klanten aan het smeken zijn behalve een paar procent?

[Reactie gewijzigd door Zackito op 22 juli 2024 20:03]

Een gemiddelde gebruiker mist helemaal niets. Degene die zeggen dat ze het missen zijn Tweakers (en ik ben er 1 van) omdat we bijv. eigen servers ergens hebben hangen en die via IPv6 willen beheren, of omdat VPSjes goedkoper zijn zonder IPv4 adres.

Begrijp me goed, ik gebruik al 25+ jaar IPv6 op allerlei manieren, maar dat is puur als techneut.

En dat is ook m'n punt: zolang er een aantal grote websites zijn die het weigeren te ondersteunen zal ook een Odido of welke ISP ook niet gedreven zijn om het op te gaan nemen. Een beetje een "10% upload van je downloadsnelheid is voldoende". Het klopt gewoon vaak voor de "gemiddelde" gebruiker, en daar richtten ze zich op.
Dan zit je goed, ik ben er om die reden weggegaan.
Wat ik me wel afvraag, wat mis je precies? Ik heb geen diensten die niet via ipv4 bereikbaar zijn.
Het probleem zit hem meer in de onhoudbaarheid van IPv4. Het is een beetje het kip-ei verhaal. Om geen koppijn te bezorgen aan klanten moeten we IPv4 op zoveel mogelijk plekken ondersteunen, ook al is dit duur en op de langere termijn onhoudbaar. IPv6 kent geen NAT meer. Sommige VOIP en Zoom achtige apps willen nog wel eens NAT hole punch vereisen om een directe verbinding op te zetten tussen twee computers. Dit werkt zolang je een 100% eigen IPv4 adres hebt. Door het tekort aan IPv4 adressen gaan steeds meer providers op CGNAT springen waardoor je je IPv4 adres deelt. Delta/Caiway en Trined doen dit bijvoorbeeld al. Dan werken dit soort hole punching/port forward truckjes niet meer, en mag een partij als Zoom gaan werken met relays om al je verkeer erdoorheen te tunnelen. Dit vreet bandbreedte, verslechterd de latency en is een gigantische kostenpost voor zo'n partij. Uiteindelijk worden die kosten gewoon weer verhaald op de consument. Daarom heeft iedereen er baat bij om IPv6 te hebben.
Ik wel, genoeg servers die geen ipv4-adres meer hebben en alles via een tussenhost ssh'en kost bakken vol met tijd. Portforwards op je eigen modem configureren kosten handenvol tijd.

Met kan ik gewoon direct een bestand naar mijn desktop thuis kopiëren als ik bijvoorbeeld met m'n laptop ergens anders ben.

Tot slot: Ik ben mijn virtuele server bij Strato aan het ontruimen, dat neemt een Raspberry Pi in mijn meterkast over. Met v6 is er geen reden meer om Strato €25 de maand te betalen, ik heb thuis ip-adressen genoeg.
Huh.... Meer reactie kan ik niet verzinnen sorry. Zoveel dingen die ik mijn klanten niet zo adviseren en dat heeft weinig met IPv6 te maken
Dus daar zit geen firewall tussen?

Als je een raspberry pi gaat gebruiken voor de zaken die je nu 25 euro per maand kost ben ik erg benieuwd wat je gaat hosten en waarvoor je dan zoveel IP adressen nodig zou hebben.

Thuis maak ik niks via internet beschikbaar (wan -> lan) enige mogelijkheid bij mij is via openvpn cloud connexa.
De Raspberry Pi heeft zijn eigen firewall. Voorlopig zitten er 3 ip-adressen op: Twee webservers op poort 80 en een beheeradres.
Waarom geen reverse proxy of dergelijke gebruiken? Cloudflare kan je ook gebruiken om je webservers beschikbaar te maken zonder poorten open te zetten. Ben je ook nog eens beter beveiligd.
Het enige nut is om ze via V4 bereikbaar te krijgen. Een Apache is al tientallen jaren veiligheidsgeschikt om aan het publieke internet te hangen, daar zit vrijwel nul veiligheidsrisico in, zeker als je met enige regelmaat je Linuxdistributie-updates binnenhaalt. Als er een veiligsheidsrisico is, dan zit dat vooral in de webapplicaties zelf, maar daar zal ook een proxy je niet tegen beschermen.

Ze via V4 bereikbaar maken staat op het lijstje van dingen die nog moeten gebeuren voordat Strato eruit kan. De Fritzbox heeft m'n v4-adres en daar zal V4-ontsloten gaan worden.Nou moet ik zeggen dat zodra je aan de andere kant bent, v4 helemal niet zo belangrijk meer blijkt, maar toch, v4 is ook nog niet overbodig. Ik heb twee strategieën: De eerste is Freetz-ng op de Fritzbox installeren en een proxy op de Fritzbox-draaien. Tweede is poort 80 naar de Pi forwarden en aldaar iets als Squid draaien. Ik vind de V4-proxy op de Fritzbox momenteel de meest elegante optie, maar als er beren op de weg blijken te liggen dan zal ik de andere uit gaan voeren.

Ik voel weinig voor Cloudfare, het is een commercieel bedrijf, en alhoewel ze een gratis dienst hebben, ik hou m'n zaken toch liever in eigen hand.
Het aanbieden van een ipv4 + ipv6 adres staat los van wat websites doen. Zoals @handoff al noemt lijkt het een budget keuze om geen "nieuwe" (25 jaar oude) techniek aan te willen bieden. Het is de norm om beide aan te bieden. Odido is een uitzondering.
Zolang is het nog niet dat een significante hoeveelheid aansluitingen native IPv6 kan. Ik weet nog dat ik minder dan 10 jaar geleden dagen aan de telefoon gehangen heb met Ziggo omdat ze IPv6 maar niet aan de praat kregen en het vooral nog experimenteel was. Voor een select groepje (zakelijke) gebruikers. Of dat ik een jaar of wat geleden 5x doorverbonden moest worden bij KPN omdat ze geen raad wisten met IPv6 vragen want "we leveren dat pas sinds kort". Delta? Uitrol sinds minder dan een half jaar...

En dan nog (en dat zeg ik als IPv6 aanhanger): wat mist een gemiddelde gebruiker? Een provider kan er pas echt niet meer omheen wanneer de gemiddelde gebruiker vraagt om de enorm populaire applicatie X (en dan bedoel ik juist niet dat speeltje van Elon Musk) en dat blijkt alleen via IPv6 bereikbaar te zijn.
Ik denk dat de kans groot is dat die applicatie X uiteindelijk ook in een tweakeromgeving ontwikkeld zal gaan worden: Big Tech zal altijd voldoende v4-adressen kunnen kopen en alles in de cloud centraliseren, d.w.z., ieder apparaat in je huis aan de cloud koppelen vinden ze prachtig en dan kunnen die apparaten ook onderling via de cloud met elkaar communiceren.

Amateurs zullen wel interesse hebben P2P-applicaties zonder centrale servers, dat is in het verleden al meerdere malen gebeurd (bittorrent bijvoorbeeld). Als een tweaker een schot in roos maakt, dan kan de killerapplicatie er zo liggen. Voorwaarde is wel dat tweakertjes op grote schaal beschikking over v6 hebben, maar die situatie is bijna bereikt.
Ik zat eerst bij Tweak, ipv6 geen probleem. Zelfde infra nu Odido vanwege overname: ja ipv6 te moeilijk. Ik kon wel een ipv6 krijgen maar dat is voor zakelijke klanten, dus gaat niet, maar wel met KvK nummer, die heb ik niet. "Maakt niet uit meneer, een bekende met een nummer dat gebruikt mag worden?" Geef ik die van mijn broer: ja een Duits nummer accepteert de computer niet.

Helpdesk zegt dat de router geen ipv6 kan ondanks dat de hele infra het wel kan. Ik kan dus de oude houden en ipv6 aanzetten. Blijkt dat de nieuwe router die ze leveren wel ipv6 kan, maar gewoon geen ip krijgt. De oude zelfde verhaal.

Odido heeft alles klaar, maar zet het gewoon niet aan, zelfde aansluiting deed het voorheen wel jaren. Leg het mij maar uit.
Ook geen vast IPv4. Odido zakelijk biedt wel "Een vast IP-adres". Toon ik met veel moeite Chatbot Izzi gepasseerd had en contact had met een echte medewerker bleek die niet te weten wat IPv6 was.
Is dat per IP adres en dan per tijdvak of een eenmalige betaling?

Als dit de prijzen zijn voor eenmalige aanschaf zou ik zo een IP adres willen kopen (ja ik snap dat dat niet als privé persoon kan)…
Je koopt minimaal een /24
Is een /22 niet het kleinste wat je kan kopen om zelf te kunnen routeren?
Nee, dat is al vrij lange tijd /24

Sterker nog, als je je nu aanmeld als LIR bij RIPE krijg je maximaal een /24.
Sterker nog, als je je nu aanmeld als LIR bij RIPE krijg je maximaal een /24.
Dat is RIPE NCC. RIPE is de community.

Voor ipv4 is een wachtlijst dus het kan even duren voordat je ipv4 in bruikleen "krijgt".
Ze hebben van IPv6 dan ook een monster gemaakt dat in geen enkel opzicht iets te maken heeft met IPv4, buiten de naam dan die doet vermoeden dat er een grote gelijkenis en compatibiliteit zou zijn.

2 cijfertjes bij IPv4 en backwards compatibel en we waren er al lang.
Je kunt niet twee cijfertjes toevoegen en backwards compatible zijn. IPv4 heeft een vaste lengte van 32 bits gereserveerd voor het IP adres. Als je daar 33 bits van maakt is het gewoon incompatible omdat geen enkel stuk hardware of software het pakketje nog fatsoenlijk zal verwerken. Immers schuift ineens alle informatie op. Als de eerste 32 bits het IP adres zijn en de 33e bit de eerste payload bit en je gaat naar een 33 bits IP adres dan zal alle hard en software die 33e bit lezen als payload en is alles stuk / werkt het niet zoals verwacht.
En het protocol is natuurlijk nooit gemaakt om een IP adres van een variabele lengte te hebben (dus dat elk IP pakket zou aangeven "het IP adres is 32 bits"). Dat geeft een enorme overhead. En dan nog heb je geen garantie dat alles goed werkt en blijft werken in de toekomst. En dat het ook nog eens toepasbaar is over 20, 30, 40 jaar.

Want IPv4 heeft natuurlijk meer zaken die niet echt lekker werken in de huidige tijd. Dus "clean" sheet iets nieuws maken en pogen zoveel mogelijk problemen op te lossen kan dan gewoon de betere route zijn. Zoals IPv6 nu meteen het hele NAT gebeuren "verwijderd". DHCP aan de LAN kant eruit haalt waardoor het ook prima werkt in (zeer) grote netwerken waardoor je geen switches meer nodig hebt die zich met DHCP bezig moeten houden zoals layer 3 switches doen. Etc, etc.
Wat prima had gekund is bits van de port-range hergebruiken. 256 poorten is ook al meer dan genoeg. Sterker nog, de gemiddelde webserver kan er met 2 toe, en dat is omdat HTTPS óók al de backward compatibility negeerde.

De impact op je IP stack zou vrij klein zijn, want elke IPv4 verbinding heeft nu toch al een 96 bits ID in de stack (local IP, local port, remote IP, remote port). Dat zou dan ook zo blijven (40+8+40+8) . En zelfs de interworking is niet ingewikkeld (32+16+40+8).
Huh, 256 poorten genoeg? Succes met een database gebruiken dan (MySQL gebruikt 3306? PostgreSQL 5432). Kun je eerst weer alle software aanpassen om op die lage poorten te zitten. En daarnaast dus dat alle (gelijktijdige) uitgaande verkeer ook unieke poorten gebruikt natuurlijk. 3 SSH sessies open? 3 poorten. Website laden die CSS & JS van verschillende CDNs downloaden? Hoppa, alweer een aantal poorten extra.
Ik denk zelfs dat 256 poorten voor een client al weinig zouden kunnen zijn om gelijktijdige verbindingen te onderhouden. En aan de server kant wordt het en een grote shitshow om alle software andere poorten te laten gebruiken. En dan kun je een hele lijst gaan bijhouden van welke software je op welke poort hebt draaien en bij installeren nieuwe software een vrij plekje zoeken.

Om nog maar te zwijgen over OSen die privileged ports hebben. Als in, bij Linux, en ik verwacht ook andere Unix varianten, mogen poorten onder de 1024 uberhaupt alleen door de root user (/software draaiende als root user) geopend worden. Waarbij dus zo ongeveer de hele networking stack aangepast moet worden om compatible te zijn met zo'n Frankenstein oplossing. Terwijl er nu een networking stack naast is gezet die 0 invloed heeft op de bestaande stack die dus prima geschikt blijft om te werken met het "oude" internet. Terwijl even met wat bitjes schuiven in IPv4 betekent dat eerst alle hard- en software compatible moet zijn daarmee en je vervolgens maar een harde switch moet doen waarbij het hele internet de overstap maakt. Oftewel, Y2K of Y2k38 zijn er niks bij.
Geen enkel probleem. Postgres kan prima op 5 draaien en MySQL prima op 3.

En nee, uitgaande verbindingen hebben geen unieke poort nodig. Dat is een grote misvatting. Elke IPv4 stack (BSD, Linux, Windows) werkt met de 96 bits quad (localIP, localPort, remoteIP, remotePort). Je kunt dus 3 SSH sessies hebben naar dezelfde remote IP/remote port, met 3 verschillende lokale poorten, en dan alsog 3 HTTP sessies naar dezelfde remote IP, want de remote port is al anders. Dan kun je dus dezelfde 3 lokale poorten gebruiken. Er hoeft maar één van de 96 bits te verschillen. Kortom, je kunt op die manier.256 biljoen (256 duizend miljard) verbindingen hebben vanuit één 5-octet IP.

Ja, je zult de "reserved port numbers" range moeten afschaffen. Dat was toch al een vrij zinloze secutiry maatregel anno 2024, en dat heeft exact 0 impact op de IP stack. Niet "zo ongeveer de hele stack", niethet grootste deel. Nul impact. Je verwijdert de hardcoded check en klaar.
Die discussie is in de jaren '90 daadwerkelijk gevoerd: Er is serieus overwogen om bits van poort naar adres te verplaatsen voor het volgende generatie-internet-protocol. Het zou bepaalde zaken in de overgang wellicht eenvoudiger gemaakt hebben. Er is evenwel uiteindelijk gekozen voor een geheel nieuw protocol. We kunnen de argumenten erbij zoeken, maar heeft niet zoveel zin meer. We zijn nabij het punt dat v6 v4 gaat overvleugelen, niet het moment om ontwerpkeuzen nog over te gaan doen.
Als je bedoelt dat het vergroten van de ip-reeks handig zou zijn geweest, dan zou een verdubbeling als eerste handig zijn. Van 32 bits (4*8) naar 64 (8*8) bits. Dat zou IPv5 geweest kunnen zijn. Dat station hebben we eind vorige eeuw al gepasseerd.

Bij IPv6 is dat gewoon nog een keer verdubbeld naar 128 bits. En dat is vooral gedaan om andere onvolkomenheden van IPv4 te verbeteren.

Enneh, IPv4 en IPv6 hebben wel degelijk een zekere compatibiliteit. De administratie kan en mag altijd in /etc/hosts en in de dns. Daar kan je ze eventueel ook weer uit terug halen. Ook het reizen over het netwerk gaat vergelijkbaar met zo iets als een netmask en een netwerk-deel van het adres en zo. Het is alleen maar dat IPv6 meer mogelijkheden heeft.
Ze hebben van IPv6 dan ook een monster gemaakt dat in geen enkel opzicht iets te maken heeft met IPv4, buiten de naam dan die doet vermoeden dat er een grote gelijkenis en compatibiliteit zou zijn.

2 cijfertjes bij IPv4 en backwards compatibel en we waren er al lang.
Ik denk juist dat ze het veel te veel hetzelfde hebben gemaakt waardoor er buiten het aantal adressen weinig reden is om over te stappen naar IPv6.

Backwards compatibility zou mooi zijn maar ik heb nog nooit een goed voorstel gezien hoe dat zou moeten werken (buiten wat we hebben: NAT).
Dat vind ik ook ja. Helemaal mee eens. IPv6 is echt een oplossing dat het probleem voorbij schiet. Het is te ingewikkeld gemaakt en 128 bits is gewoon te groot.

[Reactie gewijzigd door Llopigat op 22 juli 2024 20:03]

Bedoel je slechts 2 cijfertjes of 2 hele delen? Dan kom je uit op 281 biljoen adressen. Lijkt veel, totdat je rekent dat dit per aardbewoner "slechts" ~32000 adressen zijn. Dan moeten we daar ook nog in gaan subnetten. Krijg je hetzelfde verhaal met IPv4 waar je subnets of te groot of te klein zullen zijn als je niet goed plant met drastische gedrochten van routing tables tot gevolg.

IPv6 is niet moeilijk, het is gewoon een kwestie van leren en de oude aannames en praktijken van IPv4 te vergeten. Dan ontdek je de voordelen: geen DHCP meer, geen NAT en dus ook geen hairpin routing, subnets zijn altijd dezelfde grootte (/64)

IPv6 is gemaakt om te kunnen schalen zodat je er geen omkijken meer naar hebt en dat NAT nooit meer een ding wordt.

Tevens kan je het wel degelijk backwards compatible maken doormiddel van DNS/NAT64 technieken. T-Mobile in de VS draait zo IPv6-Only terwijl klanten nogsteeds naar IPv4-Only resources kunnen navigeren.
Zou het ook niet komen doordat een aantal providers CGNAT toepassen naar hun klanten en zo hele blokken IP-adressen vrij komen of zie ik dat verkeerd?
Ook. Als je 1000 klanten met een NAT box achter 1 IPv4 adres kan gooien kun je er 999 verkopen.
IPv4 is bijna net zoiets als de olie. Je weet dat het theoretisch eens op zou moeten zijn, maar magisch komen er altijd toch weer nieuwe adressen beschikbaar en blijven we de overgang maar vooruit schuiven.
Er komen niet magisch nieuwe adressen bij, die worden nu met kleine blokken doorverkocht van de een naar de ander, de grote partijen die de blokken als eerste opdelen zijn er nu al lang doorheen. Die gaan smeken bij partijen die ze in de begindagen van het internet grote blokken gaven maar die verkopen ze lekker voor veel geld natuurlijk en ze geven RIPE/APNIC etc een heel klein blokje hier en daar, soms.

En maar verder hakkelen met CGNAT. Ja zo kan ik er magisch ook een miljoen adressen bij hangen per dag.
Oh mooi. Voor mijn VPS'en kosten de IPv4 adressen nu meer dan de VPS zelf... :/

Mijn provider heeft nog steeds geen IPv6 dus ik heb dat gewoon nodig.
Het leek wel cryptocurrency.

Op dit item kan niet meer gereageerd worden.