RIPE NCC heeft zijn laatste ipv4-adressen uitgedeeld

RIPE NCC, de organisatie die ip-adressen in Europa, Rusland en West-Azië verstrekt, meldt dat het maandag zijn laatste deel van de nog beschikbare ipv4-adressen heeft uitgedeeld. Daarmee zijn de adressen nu op bij de organisatie.

RIPE NCC zegt dat het opraken van de ipv4-adressen niet als een verrassing komt voor netwerkoperators, mede omdat dit opraken al langer bekend en gepland was. De organisatie gaf in september nog aan dat het nog dit jaar zijn laatste ipv4-adressen zou uitdelen, al was toen nog onduidelijk wanneer dat precies zou zijn. De organisatie waarschuwt overigens al jarenlang voor het opraken van ipv4-adressen.

Het opraken betekent overigens niet dat de organisatie in zijn geheel geen ipv4-adressen meer zal toekennen. RIPE NCC gaat in de toekomst nog ipv4-adressen herstellen van organisaties die failliet zijn gegaan of anderszins niet meer bestaan, of van netwerken die de adressen niet langer nodig hebben. Via een kleinere ipv4/24-toewijzing kunnen de Local Internet Registry's of LIR's alsnog in aanmerking komen voor deze vrijgekomen adressen. Deze leden van de RIPE NCC krijgen de adressen op basis van hun positie op een wachtlijst, die inmiddels is opgesteld. Hierbij gaat het om zeer kleine aantallen van ipv4-adressen.

Volgens RIPE NCC is het opraken weer een stap op een pad naar de wereldwijde uitputting van de overgebleven ruimte voor ipv4-adressen. De organisatie stelt dat zonder een brede uitrol van ipv6 er een risico bestaat op een toekomst waarin de groei van ons internet onnodig beperkt wordt, omdat er een tekort is aan unieke netwerk-identifiers. De organisatie roept alle stakeholders dan ook op om hun rol te spelen in het ondersteunen van de overstap op ipv6.

Volgens een overzicht is in Europa 19,3 procent ipv6 capable, wat betekent dat dat percentage van de internetgebruikers in Europa met een ipv6-adres online kan. Daarbij zijn er overigens grote verschillen tussen individuele landen. Zo ligt dat percentage in Nederland op 22,3, terwijl België op 58,6 procent zit. In een overzicht van Google staat dat de ipv6-adoptie in Nederland op 20,1 procent ligt, terwijl dat in België op bijna vijftig procent uitkomt.

Reacties (217)

[cool0]

Een van de zaken wat met IPv6 vervelend is naar mijn inzicht als beheerder is dat de drang er is om elk apparaat met een uniek IP adres aan het internet te knoppen. Dat is heel erg irritant omdat je geen boarder security kan toepassen als alles publiek staat. Met andere woorden je CV ketel bv. gewoon rechtstreeks zonder NAT op het internet, waarom? Waarom niet gewoon IPv6 voor je router/ gateway en intern Ipv4 gebruken? Dan blijft alles beheersbaar.

Echter is het nu zo dat als je naar een data center gaat en daar een rack krijgt dan krijg je bv 30 Ipv4 adressen wat voldoende is maar je krijgt dan bv. 17 triljoen onder het mom van ja we hebben er toch genoeg van! Ja dat zal dan wel zo zijn maar wij hebben er helemaal niet zoveel nodig dus waarom zoveel vergeven?

[dmantione]

Mensen zijn inderdaad zo verslaafd aan NAT geraakt wat beveiliging betreft dat ze niet meer weten wat ze moeten doen zonder NAT. Ik zal je een geheimpje vertellen: Het is een non-probleem. Mijn Fritzbox schermt mijn apparaten bijvoorbeeld net zo af met ipv6 als ipv4: Verbindingen van buitenaf worden standaard geblokkeerd. Alleen als ik een apparaat persé van buiten bereikbaar wil hebben, dan zet ik een vinkje bij "exposed host". Die mogelijkheid heb je dan weer niet bij ipv4 en dat is je grote winst.

Kortom, in praktijk verandert er niets ten nadele.

[3raser]

Het vereist inderdaad een bepaalde manier van anders denken. We zijn gewoon gewend om bij internet toegang te denken aan PC -> Router -> Internet. Als een PC vervolgens met zijn eigen IPv6 adres op internet surft dan ben je geneigd om te denken dat de Router helemaal niet meer nodig is. Maar die PC legt nog steeds dezelfde route af en kan dus niet zonder die router. Al je dataverkeer verloopt dus nog steeds via datzelfde beveiligde apparaatje. Je hebt nog steeds dezelfde firewall. Je hebt alleen geen NAT meer nodig. Wat eigenlijk heel fijn is want probeer nu bijvoorbeeld maar eens meerdere webservers op dezelfde poort achter 1 router te plaatsen. Met IPv6 zou dit geen probleem meer moeten zijn omdat ze allemaal naar hun eigen IPv6 adres luisteren in plaats van dat ze allemaal naar hetzelfde IPv4 adres luisteren. En dat is dan ook gelijk de reden waarom iedereen 17 triljoen IPv6 adressen krijgt. Zo heb je de mogelijkheid om elk apparaat zijn eigen adres te geven zodat NAT niet nodig is. Als je lokaal graag IPv4 blijft gebruiken dan kun je altijd nog je IPv6 adressen gebruiken om deze aan een apart IPv4 adres te koppelen. Zo blijf je flexibel.

Het enige nadeel van IPv6 is dat ik die adressen waarschijnlijk nooit meer uit mijn hoofd ga leren.

[Verwijderd]

Het enige nadeel van IPv6 is dat ik die adressen waarschijnlijk nooit meer uit mijn hoofd ga leren.

Precies dit.

Gelukkig hebben we daar DNS voor. 😎

Maar zonder gekheid: je kunt intern je adressen aardig vereenvoudigen, door in je IPv6 adres wel je prefix te gebruiken, maar intern eenvoudige fixed adressen te gebruiken. Vervolgens kun je alle 0-en uit je adres weglaten:
Het adres: 2341:1000:150E:0000:0000:0000:0000:0212
wordt dan: 2341:1000:150E::212

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:28]

[Pietervs]

Of, als je heel erg gehecht bent aan je huidige adressen, pas je huidige interne netwerk toe in je IPv6 implementatie.
Als je nu netwerk 192.168.10.0/24 hebt, wordt het dan:
2341::192:168:10:x

[DaanHetEendje]

Denk je dat alles dan open en bloot aan het internet hangt?

Mijn modem dropped verkeer wat van buitenaf naar mijn devices toe komt. En dan krijg je netjes een ICMPv6 administratively prohibited terug.

[Kain_niaK]

Ook erg vervelend om nog IP adres bans uit te delen.
Stel dat elke gebruiker toegang heeft tot duizenden IPv6 adressen.

Stop dat nog maar eens een troll. Of dat je een online poll hebt.

[dmantione]

Neuh, je blokkeert de prefix in plaats van het ip, het resultaat is identiek.

[hahaha2223]

Je kan het hele /64 subnet bannen

[Nox]

Totdat je niet weet of de user een /64, een /60 of de aanbevolen /56 heeft gekregen. Ban je een /56 by default kan je ook zomaar nog een 255 andere users bannen.

[Blokker_1999]

Of vandaag reset die user zijn modem, krijgt een ander IP adres en is terug binnen terwijl een andere, onschuldige mogelijk een ban te zien krijgt. Met IPv6 kunnen we op zijn minst gelukkig naar statische IP adressen gaan. Daarnaast zou het me niet verbazen dat we nu al databases hebben waarin staat welke ISP wat voor subnet uitdeelt op IPv6

[Nox]

Veelal zijn leases redelijk lang, een reset van een modem is niet altijd (vaak niet eens) een nieuw IP krijgen.

[fluffy1]

Hangt er van af. Ik zit bij een provider waar ik standaard iedere 36 uur een nieuw IP krijg.
Krijg je lekker om de 3 dagen 's avonds een korte internet outage omdat ie een nieuw IP gaat ophalen. Vervelend als je een potje online wil gamen of met wat vrienden zit te kletsen via voice chat.

Gelukkig doet hij zijn refresh ook bij een reboot van het modem. De instellingen zijn dicht getimmerd, dus ik kan niet een reconnect forceren op modem niveau. Maar ze kunnen me niet tegen houden om iedere dag op een uur dat het me niet stoort de stroom af en aan te zetten met een tijdschakelaar.

[Nox]

Jeetje, is dat een Nederlandse ISP? Want dat lijkt me voor iedereen erg onwenselijk.

[Pietervs]

Eerste vroeg ik me ook af

Of het onwenselijk is? Ja, het heeft natuurlijk zijn nadelen.
Maar vanuit het oogpunt van privacy is het natuurlijk wel een klapper: laat de firma (gebrek-aan-)Brein maar aantonen dat jij op dag x tijdstip y daadwerkelijk ip adres x.x.x.x op jouw router had...

[fluffy1]

Nope, BE.

[Core2016]

De lease is niet oneindig maar wat jij stelt lijkt me ook een dingetje opzich.

Wat ik bijvoorbeeld bij tmobile thuis heb ervaren is als ik het mac verander van de wan interface dan krijg ik een nieuw ip. Als ik dan na 3 dagen ofzo om wat voor reden ook naar het voorgaande mac terug ga krijg ik gewoon dat ip wat bij die mac hoorde.

[ewoutw]

Waarom je geen IPv6 adres voor buiten krijg en IPv4 voor intern krijgt? Simpel, IPv4 en IPv6 werken niet samen. De hele keten moet v4 of v6 zijn.

Verder is nat geen veiligheidsmethode. Heeft een leuk effect. Maar is er niet voor ontwikkeld. Ik zou een firewall nemen (zoals dat nu ook al in je modem heb).

[DB LucF]

Natuurlijk kun je wel van IPv6 extern naar IPv4 op je interne netwerk of andersom. Daar zijn veel verschillende mogelijkheden voor naar gelang je wensen: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
Dit zal ook wel moeten om een brede acceptatie van IPv6 te krijgen onder eindgebruikers, uiteindelijk zal voor hen alles transparant moeten gaan. Dus ook bijvoorbeeld die oude spelcomputer die geen updates meer krijgt om IPv6 te ondersteunen zal gewoon moeten blijven werken. Daarvoor zou je in dit voorbeeld NAT64 gebruiken.

[Naafkap]

Is een NAT niet alleen schijnveiligheid?

[batjes]

Het is geen echte manier van je bende veilighouden, maar bij NAT zit doorgaans een bijbehorende Firewall. IPv4 NAT is voornamelijk gewoon een stuk beter en makkelijker te beheersen. Nu zijn er tal van oplossingen om veel problemen te voorkomen. Maar jij kan van buitenaf niet zien wat er allemaal wel of niet achter mijn IPv4 adres hangt. Omdat elk apparaat in mijn netwerk het internet op hetzelfde publieke IP toegewezen krijgt. Bij IPv6 krijgt elk apparaat zijn eigen publieke IP adres en met een portscan op mijn range uit te voeren zou je kunnen zien wat er allemaal wel niet thuis in mijn netwerk hangt. Zo zou je heel snel al kunnen inschatten van "hè, daar valt wat te halen". Of is met een beetje proben te achterhalen van hè, die gare IoT koelkast of deurbel is een makkelijkere target dan je up to date laptop/pc/server. Terwijl veel van die apparaten voor hun security voor een groot gedeelte op je modem vertrouwen

Veel oudere hardware maakt ook keihard onderscheid tussen publieke ranges zoals 192.168, 172.16 en 10. ranges en hebben een stuk minder security maatregelen tegen interne IP ranges, want "er zit toch een NAT/Firewall tussen". Als je dat ineens een public IP adres geeft (al ondersteunen die vaak niet eens ipv6) kan dat leuke effecten geven.

Persoonlijk vind ik security en privacy ook erg aan elkaar gerelateerd en is het voor Google/Facebook/etc nu enigszins gokken op welk apparaat ik welke content consumeer.

Het is bij IPv6 verhoudingsgewijs een stuk meer werk/moeite om je netwerk veilig te houden, je modem wordt meer een ordinaire router. Terwijl momenteel een modem je 'endpoint' is vanaf het internet gezien. Een centraal punt is veel beter en makkelijker om te beheren en er zit in de huidige IPv4 opzet een duidelijke scheiding tussen het WAN en LAN. Maar nogmaals, het is niet erg veel moeite om je IPv6 netwerk op soortgelijke wijze als een IPv4 netwerk veilig te houden. Alleen komt voor de gemiddelde consument deze verantwoordelijkheid bij de providers te liggen, en daar heb ik zelf geen hoge pet van op.

[Maurits van Baerle]

Bij IPv6 krijgt elk apparaat zijn eigen publieke IP adres en met een portscan op mijn range uit te voeren zou je kunnen zien wat er allemaal wel niet thuis in mijn netwerk hangt.

Alleen als je de firewall uitschakelt. Dat ze een publiek IP adres hebben wil nog niet zeggen dat de firewall zomaar al het verkeer doorlaat. Dat bij IPv6 standaard al je apparaten zomaar van buitenaf benaderbaar zijn is een fabeltje.

[tomz_]

> Dat ze een publiek IP adres hebben wil nog niet zeggen dat de firewall zomaar al het verkeer doorlaat.

Dat is niet wat hij zei.

Bereikbaar zijn (data wordt naar jou toegestuurd) en zichtbaar zijn (mensen kunnen zien dat een device bestaat) zijn twee verschillende dingen.

[MSalters]

Twee verschillende dingen, en allebei non-issues met IPv6 firewalls in 2019.

[JackBol]

Een portscan op een IPv6 range? De zon dooft nog eerder uit voordat die scan klaar is.

Daarnaast weten Google en FB al precies van welk endpoint je komt. Dat is via de browser gewoon opvraagbaar, daar hebben ze echt geen publiek IP voor nodig.

[Martink]

Een Port scan op range? Een hele /64 range (18.446.744.073.709.551.616 adressen) is een hele lange scan hoor. Zou je daar geen zorgen over maken. En een firewall op je router blokkeer je toch standaard alles wat binnenkomt dus haalt een scan niks uit. Een NAT maakt je netwerk niet veiliger.

Denk dat het door het grote aantal ip adressen zelfs veiliger zou worden omdat je niet snel een pc vind in netwerk.

[Reactie gewijzigd door Martink op 23 juli 2024 01:28]

[Yggdrasil]

SLAAC adressen zijn inderdaad vrij verdeeld over een /64 range, maar voor servers kiezen mensen vaak statische adressen met een laag nummer zoals 2001:db8:85a3::1 in plaats van 2001:db8:85a3::8a2e:370:7334, of soms gebruikt men de laatste cijfers van het IPv4 adres van dezelfde server, dus met een maximum van 254.

En als een gebruiker een /56 of /48 heeft zie je vaak dat men subnets maakt met lage nummers (vaak nullen, of bijv. een 1- of 2-cijferig VLAN nummer er in verwerkt).

De range die je moet scannen als je zoekt naar servers wordt daardoor enorm verkleind, door onderaan in de range te beginnen met scannen met de juiste limieten.

[Blokker_1999]

Bij NAT zit helemaal geen firewall. Het gedraagt zich alleen een beetje als een firewall doordat inkomend verkeer waarvan de poort niet gekend is en dus niet vertaald kan worden naar een intern IP gewoon gedropped wordt. Ik wil je zo mijn IPv6 prefix geven. Veel plezier met te ontdekken wat er allemaal achter hangt. Ja, sommige hosts staan volledig open naar het internet, maar de meeste daar kan je gewoonweg niet aan.

Ik ken ook geen enkel apparaat dat specifiek zijn veiligheid verlaagt als er een intern IP adres gebruikt wordt. En admins die het zo instellen mogen ze van mij direct op bijscholing sturen. Als je dat begint te doen heb je maar 1 gecompromiteerd toegangspunt nodig om heel de beveiliging in je netwerk onderuit te halen. Dat kan een bezoeker zijn die op je wifi aanmeld of even zijn laptop inplugd in een netwerkpoort danwel een apparaat waarop een virus staat.

Google en FB weten verdomd goed op welk apparaat jij je content consumeert. Dat weten ze door enorm veel parameters bij elkaar te gooien. Ga maar eens op zoek naar zogenaamde fingerprinting technieken. Gewoon hun websites weten al enorm veel van je en als je hun apps gebruikt dan hebben ze ineens toegang tot nog veel meer informatie. Surf bijvoorbeeld eens naar whatismyip.com en je zal zien dat je interne IP adres ook gewoon wordt meegegeven. Van zodra een website een script kan uitvoeren kan het zelfs weer heel je interne netwerk gaan afscannen om te zien wat je nog allemaal hebt. Als jij security en privacy belangrijk vindt, blijf dan weg van Google en Facebook.

In de IPv4 opzet zit helemaal geen onderscheid tussen LAN en WAN. Toen IPv4 werd bedacht was het wel degelijk de bedoeling dat elke PC zijn eigen, publieke IP zou krijgen. Een concept zoals NAT heeft men pas veel later bedacht als oplossing voor het tekort aan IPv4 adressen en heeft men tot enkele jaren terug bij IPv6 ook tegengehouden (hoewel het vandaag wel kan geloof ik).

[lonaowna]

Wat is het voordeel van NAT? (niks) Waarom kan je geen border security toepassen? (kan wel)

[Maurits van Baerle]

Waarom zou je met IPv6 alles ineens publiek zetten? Gewoon lekker de firewall in je router/modem aan laten staan en je CV ketel is niet van buiten af zichtbaar.

[Countess]

NAT is geen beveiliging. Als je wil dat je ipv6 netwerk net zo veilig is als met NAT stel je de regel in dat by-default al het verkeerd van buiten af geblokkeerd word. That's it. That is alle extra 'veiligheid' die NAT bied.
En laat dat nu net bij default al zo zijn ingesteld.

[mdavids]

kuch... ehm... kuch... firewall misschien? Kuch...

[Odie]

IPv6 is natuurlijk net zo goed te firewallen als IPv4. Daarbij is een host op IPv4 veel sneller gevonden bij een scan van een prefix dan bij IPv6, in dat opzicht is V6 dus veiliger.

[Freeaqingme]

Echter is het nu zo dat als je naar een data center gaat en daar een rack krijgt dan krijg je bv 30 Ipv4 adressen wat voldoende is

In welke wereld is 30 ip-adressen voldoende voor een rack? In een rack kan je zomaar 1000-2000 VM's kwijt als dat je ding is. Dat moet allemaal een ip-adres krijgen.

De reden dat er allerlei bedrijven zijn met een /8 is omdat ip-adressen helemaal geen schaarse factor hoort te zijn in je ip-plan, en het dat oorspronkelijk ook niet was. Over tijd is dit langzaamaan veranderd, en dat is nou precies hetgeen wat ipv6 oplost.

[hahaha2223]

NAT is geen beveiliging, het is hoogstens een kleine drempel.
Echt knappe beveiliging komt vanuit de apparaten en of uit de firewall, dat is de knappe manier om het te doen.

[Urk]

Maar toch, als ik geen poorten heb geforward van buiten naar binnen dan kan ik vanaf buiten toch nooit bij dat "interne" device komen? Lekken in de router uiteraard daargelaten...

[Maurits van Baerle]

Da's niet zo moeilijk hoor, daar heb malware voor. NAT "beschermt" meestal maar één kant op, van buiten naar binnen, en staat standaard van binnen naar buiten wagenwijd open.

Een trojan op iemands systeem kan van binnenuit prima door NAT heen een verbinding met een externe Command and Control Server opbouwen, daarna kan die server alles sturen wat hij wil want de NAT ziet een legitieme verbinding. Een dubieus attachment met malware payload kan dat ook.

[blorf]

Hm, zoiets moet volgens mij met iets als netcat wel gedemonstreerd kunnen worden. Een string wegsturen naar een remote computer die hem weer terug stuurt over een poort die niet expliciet voor NAT is geconfigureerd maar binnen de LAN wel anders is...
Die server buiten kan zelfstandig een connectie maken omdat er eerder eenzelfde connectie van binnen naar buiten is geweest?

[Reactie gewijzigd door blorf op 23 juli 2024 01:28]

[Maurits van Baerle]

Een connectie is altijd tweerichtingsverkeer, het enige waar NAT een beperking aan legt is wie die verbinding initieert. Een server kan dus niet zomaar een client achter NAT benaderen. Zodra een client van binnen een verbinding met een server heeft gemaakt is er een verbinding geopend waarover van alles in twee richtingen kan lopen. Anders zou een browser ook niet kunnen werken.

Een kleine trojan die door een gebruiker geinstalleerd is of een simpele executable die als attachment door een gebruiker is geopend kan daarna zonder problemen een zwaardere payload gestuurd worden door een server, zolang de client de verbinding maar initieert.

Een simpele NAT kan jouw machine daar niet tegen beschermen, daar heb je een geavanceerdere firewall voor nodig.

[hahaha2223]

Dat is niet perse door NAT, dat is meer door de firewall.

[JackBol]

Wanneer je interne netwerk verkeer genereert worden er automatisch poorten open gezet voor het retour verkeer.

[dmantione]

Dat geldt met name voor UDP, daar is na één uitgaand pakketje de poort vanaf geopend voor iedereen bij de meeste NAT-implementaties, dit omdat veel protocollen dat vereisen. Bij TCP lukt dit niet, daar is geen ingaand verkeer mogelijk buiten de opgezette TCP-socket.

[JackBol]

Op het endpoint klopt dat maar een NAT box houdt niet altijd deze state bij.

[Blokker_1999]

En die worden gesloten op het moment dat die verbinding gesloten wordt. Hetzelfde gebeurd ook bij IPv6 trouwens. Het feit dat sommige NAT implementaties die poort wat langer openhouden toont trouwens nog maar eens aan waarom NAT geen veiligheidssysteem is en je er niet op mag vertrouwen om je veilig te houden.

[fantafriday]

Als jij die poort forward hoort/zit daar een ACL bij (het zij onzichtbaar) die het verkeer naar je publieke adres toestaat.

[Halfscherp]

Omdat je dan geen NAT problemen meer hebt. Dingen als een dubbele NAT zijn verschrikkelijk om omheen te werken en als ieder apparaat een uniek adres heeft heb je dat probleem niet meer

[ro8in]

Een SPI firewall doet gewoon wat je wil hoor ook met elk apparaat een publieke IP.

[Mushroomician]

Daartegen heb je dus statefull firewalls. Omdat NAT standaard de poorten niet doorlust naar je LAN, is men uit luiheid het gaan gebruiken als een firewall, maar daarvoor is NAT niet ontworpen. Daar is, zoals de naam als zegt, een firewall voor.

[Tozz]

Als je deze vraag cq. opmerking plaatst dan heb je onvoldoende ingelezen over IPv6.

Het is de defaco standaard bij SoHo routers is dat inkomend al het IPv6 verkeer is geblokkeerd. Feitelijk niet veel anders dan met IP-NAT. Dit is een standaard die vastgelegd is in een RFC (vraag me zo niet welke) en zal dus bij alle routers van toepassing zijn.

Je CV-ketel hangt dus net zo goed aan het Internet met IPv6 als met IPv4 IP-NAT. In beide gevallen is inkomend verkeer (van Internet naar je ketel) onmogelijk tenzij je het expliciet aanzet. Het enige voordeel is dat het routeren voor je router een stuk makkelijker is, minder geheugen kost, sneller werkt en betrouwbaarder is met allerlei vage protocollen.

[Mathi159]

Dit lijkt me nou echt zo'n dingetje voor de EU, iedereen over op ipv6 binnen x jaar. Wat zijn de barrières die dat belemmeren? (Qua uitrol dan)

[WhatsappHack]

Ik heb het gevoel dat dat uiteindelijk veelal aankomt op puur de wil om het te doen en er in te investeren of niet.

[Yordi-]

Nee hoor. Er zijn een aantal dingen die meespelen;

- IPv6 brengt wat meer complexiteit met zich mee, doet zaken fundamenteel anders dan IPv4, iets wat beheerders al jaren kennen. Naar mijn mening deels een ontwerpfout in IPv6, ondanks dat veel zaken slimmer worden aangepakt. Er zijn echt veel beheerders die niet weten wat ICMPv6 bijvoorbeeld inhoudt.
- Nog steeds hebben grote spelers als Cisco en Juniper niet altijd IPv6 support voor al hun oplossingen. Als je de "guidelines & limitations" van veel oplossingen op de Cisco en Juniper KB leest zie je toch nog bijzonder vaak "currently only supports IPv4".
- Er is bijzonder veel legacy spul bij heel veel bedrijven dat helemaal geen weet heeft van IPv6. Daar zijn oplossingen voor met NAT, maar ook dat is voor veel beheerders complex of minder schaalbaar.
- IPv4 doet (deed) het gewoon nog, dus de noodzaak was er ook niet.
- Zolang niet alles op het internet meedoet is de winst ook minimaal.

Dat laatste punt gaat veranderen, hoewel de zwarte markt voor IPv4's alleen maar zal aanzwengelen en er ook bijzonder veel IPv4 space ongebruikt is. Hoe die markt er echt uit gaat zien is maar de vraag.

[Reactie gewijzigd door Yordi- op 23 juli 2024 01:28]

[freaky]

Heb bij aardig wat bedrijven IPv6 geimplementeerd en de meeste apparatuur ondersteund het al jaren.

Grootste probleem is simpelweg: men wil niet investeren - want ze zien geen noodzaak. Dat was zelfs de voornaamste reden bij m'n vorige werk, terwijl ze wel een eigen datacenter hadden met IPv6 capable uplinks en apparatuur.

- IPv6 brengt wat meer complexiteit met zich mee, doet zaken fundamenteel anders dan IPv4, iets wat beheerders al jaren kennen. Naar mijn mening deels een ontwerpfout in IPv6, ondanks dat veel zaken slimmer worden aangepakt. Er zijn echt veel beheerders die niet weten wat ICMPv6 bijvoorbeeld inhoudt.

Geen idee wat je bedoelt. Wat is die ontwerpfout? Dat zogenaamde 'vak'mensen te lui zijn om zich in te lezen? Dat is geen ontwerpfout -- die mensen zijn prutsers. Ze hadden 10 jaar geleden al op de hoogte kunnen zijn en hadden het 5 jaar geleden toch eigenlijk al wel moeten zijn. Dat ze het nu nog niet zijn is erg triest op z'n minst.

[satisf]

Bij ICMPv6 is er eigenlijk al het simpele begin dat er eigenlijk geen nood was aan een nieuw protocol. Het formaat is heel gelijkaardig aan ICMP en ICMP zelf heeft nog meer dan 200 types over, maar toch moest en zou ICMPv6 een nieuw protocol type (58) krijgen. Dat lijkt triviaal maar het had packet matching code een pak eenvoudiger en consistenter gemaakt had dit geen nieuw protocol geweest.

Velen zullen ook vinden dat ICMPv6 een beetje een vuilnisbak protocol is geworden dat ARP/DHCP/IGMP en nog enkele protocollen probeert te combineren.Hier ga ik zelf niet mee akkoord om dezelfde reden als hierboven, het maakt packet matching rules en dus implementaties eenvoudiger als je maar een beperkt aantal mgmt-protocols hebt. Maar het feit is wel dat de werking van pakweg een ICMPv6 NS, Echo en MLD query alledrie zeer verschillend zijn en buiten die header weinig in common hebben. Hetzelfde kan echter gezegd worden voor pakweg BGP en HTTP(/2), we zijn geevolueerd naar grote, multi-purpose, stabiele L4 protocollen ipv specifieke protocollen en dat is niet IPv6 specifiek.

Laten we dan eens ingaan op een specifiekere applicatie, namelijk de address assignment opties. Initieel was er immers enkel het ICMPv6 gebaseerde SLAAC (StateLess Address AutoConfiguration), waarbij eenvoudig gesteld een gateway zegt "dit /64 prefix mag gebruikt worden, kies er maar een /128 adres uit.". Dit leek allemaal zeer simpel en mooi, maar dat is wat kort door de bocht.

• Stateless werkt goed voor specifieke scenarios, maar er zijn gevallen waar je wilt weten of een adres in gebruik is of niet, of zelfs een niveau erboven of een bepaald toestel geconnecteerd is of niet. Soms simpelweg om commerciele redenen (pay-per-hour), soms omdat elke connecties system resources verbruikt. SLAAC zelf mist die capaciteit, je kan zaken als NUD gebruiken, maar het feit blijft dat implementaties moesten wijzigen in vergelijking met het gekende DHCP.
• SLAAC was origineel vooral bedoeld voor simpele netwerken: je hebt een shared link en 1 of meerdere gateways op die link. Binnen die link neemt dan elke PC een prefix uit die /64. Werkt bijvoorbeeld prachtig binnen een thuisnetwerk of binnen een DataCenter (rack). Het werkt wat minder als je routed devices een prefix wilt geven, met als voornaamste voorbeeld jouw home router een prefix geven dat die dan weer op zijn beurt via bv SLAAC kan anouncen binnenshuis. Dat concept noemt men ook wel 'prefix delegation'.
• Het heeft tot 2007 (RFC 5006- experimental) en zelfs 2010 (RFC 6106 - standard track) geduurd voor men door had dat een adres alleen niet genoeg was en DNS servers signalen naast je adres allocatie eigenlijk noodzakelijk waren..
• SLAAC gaf de mogelijkheid tot meerdere /128s per device, en dat wordt in feite zelfs aangeraden voor nogal vergezochte privacy maatregelen (RFC 4941). Waar men echter geen rekening mee hield was dat dit bij grote aggregatie gatways tot een enorme ontploffing van de neighbor cache kon leiden. Side note: ik vind RFC 4941 niet onterecht, maar de periodieke wijziging zorgt voor nogal veel overhead, men had beter een network-change based methode gepromoot zoals een nieuwe interface-id genereren bij elke /64 change, of bij elke BSSID change. Dat had hetzelfde bereikt en minder neighbor cache entries gekost.

SLAAC voldeed dus zeker niet voor alle toepassingen, dus heeft men maar DHCPv6 toegevoegd, in twee stappen. Eerst voor IA_NA en IA_TA support, beiden bedoeld voor het uitdelen van exacte /128 addressen waarvan IA_TA nooit echt van de grond is gekomen (SLAAC + privacy extensions lijkt populairder). Later ook IA_PD voor het ondersteunen van prefix delegation zoals hierboven beschreven. En om de combinatie lijst compleet te maken kan je ook nog eens pakweg SLAAC combineren met iets dat men 'stateless DHCPv6' noemt. In die modus krijg je een adres via SLAAC maar ga je DNS en mogelijks andere opties via DHCPv6 ophalen. Ravensburger zou er jaloers op zijn.

Het resultaat is dat je dus een hele resem mogelijke combinaties krijgt afhankelijk van de toepassingen. Voor vaste lijnen zijn zowel PD-only, PD+SLAAC, als PD+NA (geen SLAAC) vrij common. Maar het heeft een tijd geduurd voor men naar deze stabielere combinaties geevolueerd is.

Om duidelijk te zijn, niet alles van IPv6 en ICMPv6 is slecht. Ik vind persoonlijk het concept van directe L2-gateways zonder IP adres properder dan IPv4 waar je een L3 gateway moest signalen en dan moest ARP'en. Ik vind ook het concept van preferred/valid lifetime properder dan de DHCP lease times al hebben ze sommige procedures errond (SLAAC deprecation) wat vreemd beschreven. Het idee van link-local adressen en alles multicast ipv 0.0.0.0 en broadcast is ook een pak eleganter. Het 'by default' vermijden van fragmentatie en promoten van PMTU discovery via ICMPv6 is ook stukken beter.

Vandaag is de markt inderdaad redelijk matuur aan het worden en is de kennis en convergentie over het bovenstaande steeds beter. Maar die complexiteit heeft er zeker mee voor gezorgd dat de roll-out zo lang duurde.

[dmantione]

Google heeft DHCPv6 min of meer opgeblazen tot te weigeren het in Android en ChromeOS te ondersteunen. Daarmee ben je verplicht routing advertisements voor SLAAC goed in te regelen en zou je alleen DHCPv6 kunnen doen voor de overige apparaten. Daarom denk ik dat DHCPv6 langzaam uit beeld verdwijnt en dat zorgt weer voor een vereenvoudiging van de chaos.

[MrFax]

Exact, ICMPv6 kent bijvoorbeeld helemaal geen packet fragmentation. Dat maakt het voor sommige (oudere) apparatuur wat lastiger, omdat niet alle apparatuur allemaal dezelfde MTU heeft.

[tweaknico]

Dus ook geen problemen met halfslachtige pakketten met halve informatie. waarbij eerst op de rest moet worden gewacht voor er geforward kan worden, kortom ook veel minder buffer problemen.
(Bij ontwerp IPv4 waren pakketten vaak nog kleiner, dus de morne netwerken hebben dat aspect een beetje ingehaald).

[Reactie gewijzigd door tweaknico op 23 juli 2024 01:28]

[johnkeates]

Maar je hoeft intern toch helemaal geen IPv6 te gebruiken? Daar heb je die IPv4 private ranges voor.

[tweaknico]

Jij hebt het helemaal begrepen..., maar mogelijk moet je even inlezen.
IPv4 kan niet 1-op-1 naar IPv6. Er zijn semantische verschillen naast het adres aspect.
Bij IPv6 zijn ook wat issues die in IPv4 ontstaan waren opgelost.
Het is een makeover van het IP protocol.

(edit: Ipv6 -> IPv4 NAT werkt niet, IPv4 -> IPv4 nat wel, nou een beetje).
nav. onderliggend commentaar van @johnkeates

[Reactie gewijzigd door tweaknico op 23 juli 2024 01:28]

[johnkeates]

Hoezo? IPv4 kan prima 1-op-1 naar IPv4. En op internet mag je de private ranges niet gebruiken dus die komen daar niet voor. NAT was een lapmiddel voor mensen die maar 1 IP adres kregen van hun providers maar wel meer dan 1 host hadden.

[Reactie gewijzigd door johnkeates op 23 juli 2024 01:28]

[tweaknico]

Best een hoop onzin....

Het in feite hetzelfde protocol as IPv4 alleen staat er een 6 in het versie veld ipv. een 4.
Zelfde packets zelfde infrastructuur. De OS'en kunnen er al een jaar of 15 mee overweg , sinds een jaar of 10 ook redelijk betrouwbaar. Voor switches is het een non-issue die hebben weinig met IP te maken.
Voor management van apparatuur kun je gewoon IPv4 gebruiken achter een management server op een private adres reeks als je dat wil.

Met legacy stuff... tja veel hardware kan gewoon blijven. Windows, ondersteund het ook al enkele jaren, linux en unix derived systemen al wat langer.
NAT is in welke vorm dan ook een draak... ook IPv4 achter IPv4.. (en levert op z'n best een 8 tal bitjes adres ruimte extra op.).
IPv4 zal ook wel nog even blijven werken totdat de protocol versies verwijderd worden.

Azie is vooreen groot deel al om, (daar zijn ze al jaren door alle adressen heen). Alle grote partijen hebben al IPv6 lopen. Ik heb thuis al een jaar of 6 IPv6 dual stack. destijds was er nog wel eens een probleem.
"zwarte" markt?... er zijn adressen maar die zijn soms al jaren gebruikt door allerlei spam farms etc. Je kan voor een onredelijk bedrag een reeks huren/kopen maar of die adressen bruikbaar zijn is nog maar de vraag.

Netwerk beheerders die de afgelopen 20 jaar onder een steen hebben gelegen kunnen daar maar beter blijven. Afgezien dat adressen ECHT niet meer uit het hoofd te leren zijn.. en de administratie op orde moet zijn zie ik niet zoveel problemen.

[Yordi-]

Sorry Nico, maar als je zegt dat IPv6 hetzelfde protocol is als IPv4 met een 6 i.p.v. een 4 zou ik me nog eens inlezen. Tweaker satisf heeft hierboven een voorzetje gedaan.

[tweaknico]

Natuurlijk is het sub protocol anders, adressering anders.... maar het is en blijft IP...

Speciale MAC adressen veranderen niet, Protocol mapping voor IPv4 geen change.
Low level link protocollen als DSL, Ethernet.. malen niet om IPv4 of IPv6.. Voor die onderdelen is het een pot nat. Van de onderkant af gezien is er geen verschil tussen IPv4 of IPv6. (Kabels, switches).
Maar lees het gerust nog eens na.

Binnen IP begint het verschil met een ander versie nummer en daarna een nieuwe header layout als vervolg daarop. Dus van boven af gezien ziet het er anders uit. (UDP, TCP, ... )
Voor de IPv6 basics kijk begin eens met: Hurricane Internet. https://ipv6.he.net/certification/
Ook hier is zijn de nodige startpunten: https://en.wikipedia.org/wiki/IPv6

[itlee]

hoewel de zwarte markt voor IPv4's alleen maar zal aanzwengelen en er ook bijzonder veel IPv4 space ongebruikt is

jaar 2033, Drugs dealers zijn niet meer lucratief,.... je wordt IPv4 dealer...

[tweaknico]

Maar je moet adressen ook niet uit je hoofd leren, daar is DNS voor....
daarnaast een ISP geeft je niet een adres maar altijd een ruime reeks. (als het tenminste een serieuze ISP is). krijg je een adres met 56 bits prefix. De rest kan je zelf bepalen...)

[MrFax]

Je hebt ook de privacy extension, waarbij je een random ipv6 adres krijgt, die wel nog steeds globaal uniek is.

[tweaknico]

Dat is alleen mogelijk BINNEN je prefix ... en die moet dan kleiner of gelijk zijn dan /64.

[MrFax]

IPv6 kent wel enige versimpeling waarbij je rijen nullen weg mag halen. Daarom hou je bij loopback/localhost alleen ::1 over

[Reactie gewijzigd door MrFax op 23 juli 2024 01:28]

[Blokker_1999]

Ook IPv4 kende dat trucje. Die maar eens een ping 127.1

[Milmoor]

There's no place like ::1

[FvdM]

Mwa dat is gewenning. Ik werk al zeker 10 jaar met v6 en kan de voor mij belangrijkste adressen prima onthouden. De syntax is juist erg handig omdat je devices en services kan groeperen of een passend adres geven. Bijvoorbeeld:

- 2001:abc:def::80:1 - Webserver 1
- 2001:abc:def::80:2 - Webserver 2
- 2001:abc:def::25 - SMTP

En er is niet voor niets DNS uitgevonden.

[wica]

Zolang er CGNAT is, is het idd puur wil.
Dat iedereen thuis een Publiek IP heeft, is eigenlijk pure luxe. En Ziggo zou er ook voor kunnen kiezen om iedereen een IP uit de 10.0.0.0/16 pool te geven. En naar het "echte" internet via een shared IP te werken.

Ondanks dat er dus van dit soort oplossingen zijn, is naar mijn mening, IPv6 wel de toekomst.
Gelukkig zie ik steeds meer bedrijven overschakelen naar IPv6 en ook de grote jongens zoals AWS, Google bieden IPv6 aan.

Wat het denk ik nu nog is, dat iets wat onbekend is, onbemind maakt. Of wel, ik denk een gebrek aan kennis, de meeste nog tegenhoud.

[tweaknico]

Joepie... CGNAT als er een probleem is dat de wereld uit moet is het wel NAT.
NAT sloopt veel meer dan dat het oplost. Zolang je ZELF de issue nog kan opkossen door bv. een portforward is er nog een soort van oplossing mogelijk.

Hoe wil je mail kunnen ontvangen (of VOIP) op een publiek adres dat he deelt met 100-den anderen?..
Er is maar een poort 5060. Of leg je ALLES bij de ISP neer. ook wat je wel/niet mag?.

[Houtenklaas]

Dat is uiteraard geen oplossing. Steeds meer mensen gebruiken camera's thuis en deurbellen die via het internet bereikbaar moeten zijn vanaf de buitenkant. Het Cripplenet wat je voorstelt met private range IP adressen vormt daar een enorme belemmering voor. De enige oplossing die er al jaren is, heet IPv6 en niets anders dan dat.

[aequitas]

Dat blijft gewoon prima werken hoor. Veel apparaten zijn nu toch al niet vanaf buiten benaderbaar omdat iedereen thuis een NAT heeft en geen poorten opzet of uPNP aanzet. Veel apparaten bouwen gewoon een outbound verbinding op en houden die in stand (of pollen). Dan loopt al je verkeer via een centrale server/cloud en niet p2p. Ideaal? Nee. Werkt het, Ja. Is de consument hiermee tevreden? Ja hoor, die weet niet beter, als het maar 'gewoon' werkt.

IPv6 brengt veel voor ons techneuten. Maar IPv4 ook met zijn default 'firewall' in de vorm van NAT. Ik zie de chaos al straks als elke consument poorten/adressen in zijn firewall moet gaan configureren in zijn router om een deurbel of camera aan de praat te krijgen. In het ergste geval zetten ze te veel open of uPNP aan en is hun netwerk lek als een mandje.

Enige zieltjes die je voor IPv6 kan winnen met P2P zijn misschien de gamers die hierdoor met nog minder lag kunnen gamen. Maar hoe dat dan weer samenwerkt met anti-cheat wat server side draait?

Dus nee. IPv6 is hier totaal geen oplossing voor het overgrote deel van de internet gebruikers, helaas.

[Maurits van Baerle]

Ik zie de chaos al straks als elke consument poorten/adressen in zijn firewall moet gaan configureren in zijn router om een deurbel of camera aan de praat te krijgen. In het ergste geval zetten ze te veel open of uPNP aan en is hun netwerk lek als een mandje.

Dat is nou juist veel makkelijker bij IPv6. Niet meer dat gedoe met poort X die al in gebruik is door een apparaat dus waardoor je dus allemaal trucs met non-standard ports en vertaalslagen moet werken.

Met IPv6 kun je in de router/firewall gewoon zeggen dat apparaat X en Y een extern zichtbare webserver mogen draaien terwijl het voor de overige apparaten standaard dicht staat.

[Houtenklaas]

Veel apparaten bouwen gewoon een outbound verbinding op en houden die in stand (of pollen).

Je hebt het over camera's en zo die via de website van de leverancier te benaderen zijn. Of over Toon die via de servers van Eneco werkt. Dat je je thuisnetwerk dus openzet voor bedrijven waar jij totaal geen invloed op hebt. Nee, mij niet gezien. Daarnaast zie ik nog een ander probleem en dat is het Justitieel aftappen. Eén foute gast die op een gedeeld IP nummer zit is nauwelijks meer te achterhalen. En zoals @Maurits van Baerle al meldt is het juist met IPv6 veel eenvoudiger dan met IPv4. Wat er mist is een dummy-proof gestandaardiseerd dashboard waar je je poorten visueel kunt mappen op je apparaten, daar zie ik genoeg ruimte voor verbetering, zou daar al niet eens door iemand een RFC aan gewijd zijn?

De chaos die je voorspelt gaat er ook niet komen. Net als nu met IPv4 zal Jan de Consument zijn handen hier ook niet aan gaan branden, dat gaat met IPv6 niet anders zijn. Door de groei van de wereldbevolking, maar ook door Internet of Things, Machine-to-Machine, het online komen van steeds meer vervoermiddelen zal IPv6 pure noodzaak zijn om te gaan gebruiken. Dat de IPv4 nummers nu echt op raken gaat alleen maar meehelpen. Overigens snap ik niet goed wat IP6 met "lag" te maken heeft, dat hangt meer af van de snelheid van je verbinding, de apparatuur die je onderweg tegenkomt, je internet knooppunt en zo.

[tweaknico]

IPv6 is wel degelijk een oplossing. Alle NAT de wereld uit.
Dan ben je ook van allerlei issues bij bv. VOIP af (eenzijdige gesprekken).
Je hebt helemaal geen servers van derde partijen nodig ==> minder afhankelijkheid.
Apparatuur kan veel eenvoudiger worden.

Geen omweg protocollen meer nodig zoals STUN, TURN, UPnP etc.etc.

[Monochrome]

Ehm, het is heel plezierig dat die devices niet adresseerbaar zijn vanaf het internet. Wat mij betreft is het actief moeten instellen van een port forward een enorme security feature...

Edit: ik begreep je reactie verkeerd. Ik dacht dat je natting van het modem bedoelde met "cripplenet". Je hebt natuurlijk gelijk.

[Reactie gewijzigd door Monochrome op 23 juli 2024 01:28]

[hahaha2223]

Ik denk dat de meeste toch UPnP gebruiken om een port te reserveren en dat het gewoon zoeken is naar de port die gebruikt wordt. Dat wordt security through obscurity en dat is nooit een goed idee.

[Houtenklaas]

Check. En verkijk je niet op NAT. Eén verkeerde click op een advertentie, een 0-day of wat dan ook en de malware zoekt zelf contact met zijn control/command server. En dan helpt NAT totaal niet meer, je netwerk staat dan wagenwijd open voor de buitenwereld.

[tweaknico]

Je hebt meer aan een firewall met goede policies... is nog sneller ook.

[i-chat]

public nat zoals waar jij over schrijft is ECHT ondoenlijk, probeer maar eens te bedenken hoe dat zal gaan met gaming. straks kun je in WOW alleen nog maar gamen tegen mensen die ook zigo hebben omdat hun Natting-table de druk niet aan kan.

Network Adres Translation is in beginsel een prima manier om op korte afstanden meerdere hosts beschikbaar te stellen. dus als jij als bedrijf (nog) niet over kunt schakelen met (een deel van) je netwerk zou je daar helemaal aan de voorkant een ip6-to-4 translation moeten maken. er is daar zelfs een speciale methode voor bedacht

daarmee wil ik ook nog even duidelijk aangeven dat ik de huidige toewijzing van ip6 subnets ook wel raar vind. Het lijkt me niet heel toekomst bestendig als je mensen een een meer dan duizendvoud aan adressen toeweist van wat ze ooit werkelijk nodig gaan hebben (zelfs als je elk apparaat in huis (inclusief je tandenstokers) een ip toewijst kom je er nog niet.

in dat opzicht wordt het inderdaad tijd dat alle ip4's worden ingetrokken en alleen nog worden toegewezen als extra service voor die gevallen dat het echt nodig is.

in alle overige gevallen werk je maar met de 10.x reeks en met 6to4 nats

[Houtenklaas]

in dat opzicht wordt het inderdaad tijd dat alle ip4's worden ingetrokken en alleen nog worden toegewezen als extra service voor die gevallen dat het echt nodig is.

Dat zou de grootst mogelijke chaos opleveren met een tot stilstand komende economie. Bruggen, sluizen, verkeerslichten, Schiphol, de NS, logistieke bedrijven werken zonder uitzondering met IPv4 waarvan een flink deel embedded is. Dat vervangen voor apparatuur die dual stack / IPv6 aankan zal technisch zeker haalbaar zijn, maar financieel en logistiek een onvoorstelbaar lastige puzzel. Niets meer uitdelen vanaf nu ben ik het helemaal mee eens, al was het alleen maar omdat ze "op" zijn. Aan de andere kant, als je even op zoek gaat naar het aantal IP adressen wat bijvoorbeeld KPN en Ziggo hebben, kan je je afvragen of zij die allemaal echt nodig hebben of überhaupt in gebruik hebben. Maar zelfs dat levert wellicht korte termijn winst op. De enige weg naar de toekomst heet IPv6.

[dmantione]

Wat me een goede manier lijkt om ipv6 op te dringen is om een internetverbinding standaard ipv6 te maken. Er zit standaard geen IPv4 op. IPv4 is echter wel beschikbaar, je moet alleen zelf een tunnel opzetten. Je hoeft er waarschijnlijk niet eens geld voor te vragen. Puur die extra handeling aan de zijde van de eindgebruiker zal de industrie bewegen dat alle internetdiensten via V6 bereikbaar zijn en na verloop van tijd zou de behoefte van eindgebruikers aan die V4-tunnels vanzelf dalen.

[denBoom]

Welke grote internetdiensten zijn dan nog niet bereikbaar via ipv6? Volgens mij zijn er al regelmatig dagen dat er bijna geen ipv4 packets mijn huis verlaten.
Een dual stack oplossing waarbij je zowel ipv4 als ipv6 naast elkaar gebruikt is al een tijdje normaal. En gebruikers zullen dan standaard ipv6 gebruiken, toch als daar de nodige dns records voor bestaan. Hier heeft iedereen voorlopig nog ipv4 als fallback.
Wanneer het merendeel van het verkeer effectief over is op ipv6. Dan kan ipv4 gestopt worden voor (bijna) iedereen en aangeboden worden via CGnat voor de paar sites die nog volledig op ipv4 blijven hangen. CG nat kost de providers geld dus zij zullen op hun beurt druk zetten op aanbieders die nog altijd geen ipv6 praten.

[dmantione]

Ebay, Marktplaats, Bol.com, Nu.nl, Volkskrant.nl, ing.nl, Amazon.com helaas hoef je niet ver te zoeken. Wat over is zijn de grote jongens als Google en Microsoft en dat is een heleboel verkeer, maar dat je een dag lang geen ipv4 gebruikt kan ik mij eigenlijk niet voorstellen. In de Googe-statistieken is het ipv6-aandeel inmiddels 30%, dus dat is bemoedigend, we komen er uiteindelijk wel, maar aan de andere kant moet je constateren dat het bizar is dat 20 jaar na introductie nog altijd een minderheid van het internet ipv6 gebruikt. Een beetje drang had de introductie van ipv6 flink kunnen bespoedigen en dat kan nog steeds.

[Reactie gewijzigd door dmantione op 23 juli 2024 01:28]

[Houtenklaas]

Heb je een idee hoeveel embedded IP devices er langs de kant van de weg staan, in allerhande automaten, matrixborden die geen IPv6 kunnen kletsen? In principe ben ik het met je eens, met de toevoeging dat elke nieuw op te leveren IP verbinding verplicht IPv6 gaat ondersteunen. En dan bloed het oude wel een keer dood ...

[dmantione]

Je zou het alleen voor nieuwe verbindingen kunnen doen, maar ik zou de beslissing om die IPv4-tunnel wel of niet op te zetten bij de eindgebruiker willen leggen, zodat als je een embedded apparaatje hebt, je je apparaten nog steeds van v4 kunt voorzien. En wat mij betreft blijft die mogelijkheid dan nog 20 jaar bestaan. Drang, geen dwang.

[PPie]

Lijkt mij dat die matrixborden in een privaat netwerk zouden moeten zitten.
En daar is de beheerder natuurlijk degene die gewoon IPv4 kan gebruiken.
Mocht je het via internet willen beheren, dan zet je er een VPN doosje tussen die site to site de IPv4 pakketten via een IPv6 vpn verbinding weet te transporteren...

[tweaknico]

IP nat van 6->4 is ook een draak. Het is bedacht en afgeserveerd omdat TCP bevoorbeeld best anders werkt. Ook UDP is niet helemaal een op een. Het is evt. mogelijk via L7 ... omzetting maar dat is veel meer overhead. Dat komt ping tijden weer niet ten goede.

[MSalters]

in dat opzicht wordt het inderdaad tijd dat alle ip4's worden ingetrokken

Praktisch punt: dat kan helemaal niet. Er is geen enkele organisatie of regering die dat recht heeft. Op z'n best zou een regering alle IPv4 adressen in een land kunnen onteigenen volgens nationale wetgeving, maar in de meeste landen moet de regering een marktprijs betalen bij onteigenen. Nu is die prijs zo'n 20 dollar per adres, dus een regering die een /8 wil onteigenen is daar zo'n 320 miljoen voor kwijt.

[mkools24]

Genoeg barrieres, bijv legacy software die enkel IPv4 praat. Een andere barrière is de learning curve, IPv4 adressering is toch een stuk makkelijker/overzichtelijker dan IPv6 met die vreselijk lange adressen die je dan ook nog op allerlei manieren in kunt korten. Ja er is DNS dus je hoeft ze niet te onthouden maar toch.

Het zou een stuk makkelijker geweest zijn wanneer IPv6 ook met IPv4 kon praten en dus backwards compatibel was. Nu draait heel het internet al op IPv4, pas dat maar eens 'even' aan.

Er is inmiddels ook een levendige handel in IPv4 adressen. Een /24 kost je al een duizendje of 5 geloof ik of je kunt een subnet leasen voor 100 euro per maand.

Ik zie ook al situaties waar providers gaan NAT-ten op het internet en een IP delen over 20 klanten en iedere klant een reeks poorten toekent....

Men stapt toch niet over tot het echt moet en alles volledig is uitgeput. De volgende stap is waarschijnlijk eerst dat thuisverbindingen een lokaal adres krijgen net als 4G verbindingen momenteel.

[kamerplant]

Legacy software? Zolang we niet overgaan wordt er nieuwe legacy software bijgemaakt.

Niet gebruikersvriendelijk? Voor wie? Voor eindgebruikers is het irrelevant. IT professionals moeten ip adressen niet uit hun hoofd willen leren.

[hahaha2223]

IPv6 is niet ineens in klingon, en ondanks dat het langer is vind ik het niet heel veel moeilijker.
Backwards compatibilty had niet gewerkt, dan zit je alsnog gewoon op ipv4 (wat nu met dual stack bereikt wordt)

[.oisyn]

Het zou een stuk makkelijker geweest zijn wanneer IPv6 ook met IPv4 kon praten en dus backwards compatibel was.

Stel je hebt een envelop met daarop 2 vakjes voor een postcode, een voor de bestemming en een voor de retour (zodat de ontvanger je een brief terug kan sturen).

Nu komt er een nieuw postcodesysteem met langere postcodes, want de oude postcodes zijn op. Jij woont inmiddels op een adres met zo'n nieuwe postcode, en je hebt een nieuw soort envelop waar de nieuwe postcodes op kunnen (en de oude, want "backwards compatible"), en je stuurt een brief naar je opa. Je opa heeft echter alleen de oude enveloppen. Hoe moet hij een brief terug gaan sturen? Jouw nieuwe postcode past niet in het vakje van zijn oude envelop.

IPv4 backwards compatibility in een notendop. Dat kán gewoon niet, want een IPv6 destination address past niet in een IPv4 packet.

[dmantione]

Wat men had kunnen doen, was de 96 extra bits aanvankelijk reserveren. Vervolgens 1-op-1 vertalen in routers. Van 4 naar 6 migreren was dan pijnloos geweest, alles wat via 4 bereikbaar was, was via 6 bereikbaar geweest.

Op het moment dat de v4-adressen op waren had men dan enkel-v6-adressen kunnen beginnen uit te delen. Die nieuwe adressen zouden dan onbereikbaar zijn geweest voor v4-apparatuur. Maar omdat de uitgifte van deze nieuwe adressen geleidelijk gaat, zou v4-apparatuur ook geleidelijk minder bruikbaar geworden zijn.

[tweaknico]

Nee want er zijn meer verschillen. Er zijn in de loop der jaren allerlei extra opties gekomen, die zijn in IPv4 verstopt in allerlei velden waarvan bitjes gereserveerd waren.
Bij IPv6 zijn alle content delen (ook opties, of payload, etc.) allemaal aparte gestructureerde velden.
Dus de migratie van IPv4 -> IPv6 is niet alleen adres aanpassing maar ook gelijk een meer consistent en uitbreidbaar IP protocol.

Daarnaast is er al een verdeel plan gemaakt voor IPv6 adressen, en op dit moment krijgt iedereen er een uit de IPv4 migratie reeks. Daar is voor elk IPv4 adres in princiepe een /48 adresreeks beschikbaar. (daar is later /56 van gemaakt omdat 64K pive-netwerken wat overdreven leek, 256 is ook wel genoeg. en laat gelijk 256 * meer klanten toe voor een ISP).

[mae-t.net]

Dat er meer verschillen zijn, neemt niet weg dat je best op backwards compatibility van adressering had kunnen inzetten. Dat is altijd een compromis maar kan de zaken wel versimpelen. Het is vaak genoeg eerder vertoond. FM-stereo, kleurentelevisie, telefoonnummers.

[tweaknico]

Niet echt. IPv4 was te rigide en te weinig op aanpassingen van de basis ingesteld.
Met IPv6 is de header van een packet behoorlijk beter geregeld. Addressering is iets wat zeer goed moet schalen ook (juist) op routing niveau. Te veel opties in een adres schema maken dat het hele netwerk trager wordt ivm route evaluatie.
Backward compatibiliteit zou alleen kunnen als bv. een bepaald IP adres dezelfde betekening zou krijgen als een nl IP versie nummer. maar dat veld is er al.

Ruim 20 jaar geleden was te voorzien dat de Internet IPv4 kruik op enig moment zou gaan barsten. een jaar of 8 geleden. Begonnen de scheuren echt zichtbaar te worden. Het is echt tijd voor een andere grotere kruik.

[.oisyn]

Het vereist nog steeds een aanpassing van alle apparatuur, net zoals met IPv6 nodig is. En bereikbaarheid van IPv4 vanuit IPv6 is nooit echt een probleem geweest, daar zijn tal van tunneling opties voor. Wat jij voorstelt is niet veel anders.

[MSalters]

De meest simpele oplossing was geweest om 8 bits van de TCP poort nummer over te hevelen naar het IP adres. Dan has je instantaan 256 keer zoveel IP adressen gehad. Dan houd je 256 poorten per IP adres; dat is nog steeds genoeg. Zelfs de meest zware servers kunnen typisch met 2 poorten toe (HTTP en HTTPS, of SMTP/POP). Elke verbinding blijft nog steeds geïdentificeerd door de 12 byte tuple {src ip, src port, dst ip, dst port}

[deadinspace]

De meest simpele oplossing was geweest om 8 bits van de TCP poort nummer over te hevelen naar het IP adres.

Dat vereist nog steeds een aanpassing aan alle software en netwerkapparatuur, precies datgene wat dus veel te langzaam gebeurt.

Ook heb je daarmee een gigantisch compatibiliteitsprobleem; onder jouw voorstel zou je dus een computer hebben met IP 1.2.3.4 en poorten 0-255, en een computer met IP 1.2.3.4 en poorten 256-511. Dat is niet iets wat routers en andere netwerkapparaten snappen. En als je dan een derde PC hebt met 1.2.3.4 die jouw nieuwe regel nog niet snapt, dan kan die doodleuk alle poorten gebruiken, inclusief 0-511, met alle conflicten van dien. Dit in tegenstelling tot IPv6, wat gewoon naast IPv4 kan bestaan zonder conflicten.

En dan moet alle software die iets met poorten doet aangepast worden. HTTP is ineens niet meer poort 80, maar kan ook 80+256=336 zijn, of 80+512=592, etc. HTTP en HTTPS met de huidige poorten kunnen niet eens meer op dezelfde server (meer dan 256 poorten uit elkaar). Ik snap echt niet hoe je denkt dat het zo simpeler wordt.

Bovendien werkt wat jij beschrijft niet voor alle protocollen. Ja, het zou kunnen met TCP en UDP, maar bv niet met ARP en ICMP, welke geen poorten kennen.

Dan houd je 256 poorten per IP adres; dat is nog steeds genoeg. Zelfs de meest zware servers kunnen typisch met 2 poorten toe (HTTP en HTTPS, of SMTP/POP).

Grapjas, een server kan makkelijk op 10-20 poorten luisteren (vergeet niet de poorten die alleen op localhost open staan); en uitgaand kun je makkelijk nog veel meer poorten gebruiken. 256 zal in veel gevallen wel voldoende zijn, maar ook vaak niet.

[MSalters]

Het grappige is, nee, je hoeft een heleboel software niet aan te passen. Voor een heleboel servers zou het lijken alsof je 256 clients achter een NAT hebt zitten. En client software die een verbinding initieert naar een remote adres/poort kiest meestal geen lokaal poortnummer, dus die kun je gewoon een 8 bits poortnummer geven.

Om je voorbeeld te hergebruiken, je hebt dus een computer met IP adres 1.2.3.4.0 en poorten 0-255, en een andere computer met IP adres 1.2.3.4.1 en poorten 0-255. IPv4 Routers snappen dat niet nee, maar voor het core netwerk maakt dat niet veel uit. Alleen bij de ISP moet je die laatste byte naar een klant vertalen. Dat is een statische mapping en dus simpeler dan CG-NAT.

HTTP kan inderdaad vanuit een IPv4 perspectief op andere poorten komen, maar dat was toch al lang mogelijk. En sowieso is dat niet zo'n heel groot argument: HTTP servers kunnen meerdere websites tegelijk serven, dus daar heb je niet veel IP's voor nodig. Dan is het doenlijk om die op IPv4-compatible adressen te houden, dus a.b.c.d.0:80 en a.b.c.d.1:187 voor HTTPS. De overige 254 adressen zijn voor andere doeleinden bruikbaar.

Uiteraard kan een PC met adres a.b.c.d.1 niet naast een oude printer staan die a.b.c.d.* claimt. Dat is logisch. Dat zijn 256 nieuwe adressen, waarvan er één overlapt. Maar het kan wel samen met een printer die gewoon een DHCP adres uit de 10.* range krijgt.

ARP en ICMP hebben inderdaad een aanpassing nodig, maar dat is niet anders dan bij IPv6.

Uitgaand heb je vaak aan 1 poort genoeg, ook voor een webserver. Vergeet niet; een lokale poort kun je praktisch onbeperkt hergebruiken. Zolang er maar één bit verschil zit in de end point identificatie heb je een unieke verbinding, en met IPv4 heb je daar al 96 bits aan identificatie voor.

[deadinspace]

HTTP kan inderdaad vanuit een IPv4 perspectief op andere poorten komen, maar dat was toch al lang mogelijk. En sowieso is dat niet zo'n heel groot argument: HTTP servers kunnen meerdere websites tegelijk serven, dus daar heb je niet veel IP's voor nodig. Dan is het doenlijk om die op IPv4-compatible adressen te houden, dus a.b.c.d.0:80 en a.b.c.d.1:187 voor HTTPS. De overige 254 adressen zijn voor andere doeleinden bruikbaar.

Zoals welke doeleinden?

Zolang clients standaard poorten willen gebruiken moet a.b.c.d.0 dus HTTP doen (poort 80), en bijvoorbeeld smtp (25) en imap (143). a.b.c.d.1 kan HTTPS doen (poort 256+187=443), en a.b.c.d.3 mag imaps doen (poort 768+225=993). En de andere adressen eigenlijk niks zinnigs, want browsers, mail clients, en andere software gaan nog gewoon uit van de standaard poorten (80/443, 25/143/993).

Nou zijn dit maar twee toepassingen (web en mail), maar daarmee heb je misschien al zo'n beetje de helft van het Internet te pakken. Ik denk dat de toepasbaarheid (en de resulterende verwarring) echt wel tegenvalt.

En als je browsers wel van andere poorten gebruik wil laten maken dan wordt het pas echt een zooitje. Stel, tweakers.net draait op 1.2.3.4.5:80 (dus IPv4 IP 1.2.3.4, poort 1360), hoe moeten mensen dat dan benaderen?

Browsers kennen jouw plan niet, dus we hebben dan in DNS tweakers.net -> 1.2.3.4, en dan moeten bezoekers voortaan ook het poortnummer meegeven om t.net te bezoeken op http://tweakers.net:1360/.

Als we browsers willen aanpassen om dit te doen zonder dat mensen expliciet het poortnummer hoeven op te geven, dan moeten we DNS aanpassen om te zorgen dat we tweakers.net -> 1.2.3.4.5 kunnen doen. En de browsers aanpassen om hier gebruik van te maken.

Om dit plan effectief te kunnen gebruiken moeten we dus DNS aanpassen en alle software die uitgaande verbindingen maakt. Naast de al eerder genoemde routers, ICMP, en ARP. Ik zie echt niet hoe dit simpeler is dan IPv6 uitrollen.

Uitgaand heb je vaak aan 1 poort genoeg, ook voor een webserver.

Niet als je webserver 32 connecties met de database server heeft. Nou past dat ook nog wel binnen jouw 256 poorten, maar ik denk nog steeds dat je te optimistisch bent.

[Houtenklaas]

Het nadeel van "backwords compatible" zijn is dat je allerhande overbodige troep uit het verleden meezeult de toekomst in en veel van de elegantie van nieuwe systemen onderuit haalt. Met veel gebreken en andere onzin die je moet kan missen waarmee je ook allerhande bedrijven en ontwikkelaars mee opzadelt om dat backwards compatible ook werkend te houden. Ik vind het juist van enorm inzicht getuigen dat ze niet eens geprobeerd hebben om IPv4 te embedden in IPv6.

[Blokker_1999]

Lange adressen. Zucht. Waarom blijven mensen dat toch verkondigen?
127.0.0.1 -> ::1
10.0.0.1 -> fd00::1
169.254.0.1 -> fe80::1

En ken jij vandaag het IP adres van tweakers.net of google.com? Natuurlijk niet. Daar gebruiken we DNS voor. En ja, steeds meer ISPs zullen CGNAT moeten gaan toepassen op hun netwerk. De gevestige orde hier bij ons heeft evenwel meer dan voldoende IPv4 adressen om dat op de vaste verbindingen niet te moeten doen op dit moment en zullen over tijd gewoon omschakelen naar IPv6. Nieuwe ISPs daarentegen zullen volop moeten inzetten op IPv6 alsook ISPs in regios die veel minder rijkelijk bedeeld zijn geweest met v4 adressen.

Het zullen dan ook die regios zijn die de adoptatie van v6 zullen pushen en dan moet men in landen zoals Nederland maar oppassen dat men niet achterblijft. België heeft de omschakeling al grotendeels gedaan zonder dat mensen er veel van gemerkt hebben.

[mkools24]

Ja leuk zo'n selectief voorbeeld

Cloudflare DNS IPv4: 1.1.1.1

Nu de IPv6: 2606:4700:4700::1111

[Verwijderd]

De EU die dit soort hardcore ICT dingen gaat verplichten? Wat kan er fout gaan?

[hahaha2223]

Weinig, het is niet alsof IPv6 nieuw is en nog kinderziektes bevat

[Maurits van Baerle]

Een soort bemoedigingsbeleid vanuit de EU lijkt me prima (al is het maar vanwege internationale competitie en Azië straks veel beter voorbereid is op een IPv6 wereld dan Europa), een verplichting niet. Dat lijkt me een veel te zwaar middel en eentje waarvoor je in de Raad van de Europese Unie echt niet de handen voor op elkaar krijgt.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 01:28]

[SuperDre]

Oude hardware die nog goed functioneert maar geen ipv6 ondersteund?

[The Zep Man]

Je kan dual-stack draaien en natuurlijk altijd een lokaal netwerk hebben. Als je het op afstand moet benaderen dan kan je over IPv6 een VPN verbinding maken met daarin (ook) IPv4.

Overigens heb je het waarschijnlijk over embedded appliances, die ondertussen economisch afgeschreven zijn of zouden moeten zijn, of zo onveilig zijn dat het ontbreken van IPv6 ondersteuning het minste van je zorgen zou moeten zijn. Populaire besturingssystemen ondersteunen al meer dan 15 jaar IPv6. Tijd om dat te omarmen en je infrastructuur daarvoor in te richten.

Don't look back. You're not going that way.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:28]

[dmantione]

Zelfs in een wereld waarin je internetaanbieder geen IPv4 meer levert zul je altijd nog zelf protocolvertaling kunnen opzetten om IPv4-apparaten aan te kunnen sluiten. Ik vermoed dat het leeuwendeel van de IPv4-apparatuur die de moeite waard is om in bedrijf te houden beperkt is tot een LAN, zoals bijvoorbeeld een netwerkprinter en dat kan sowieso altijd gewoon. Apparatuur die daadwerkelijk het internet op moet is vaak al dusdanig verouderd dat die niet goed bruikbaar is. Maar.. zoals gezegd, als jij een Windows 95-machine kost wat kost van internet wilt voorzien, het blijft mogelijk.

[johnkeates]

Fax machines kunnen het zelfs zonder IP! En die werken nog prima!

[ajolla]

Ontbrekende regelgeving?

[The Zep Man]

Wat @Mathi159 schrijft kan je zien als dwang, maar ook als ambitie. Je hoeft het niet te verplichten, maar IPv6 biedt zoveel voordelen ten opzichte van (enkel) IPv4 dat het dom is om het niet te omarmen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:28]

[laptopleon]

RIPE doet al zeker sinds 2011 regelmatig oproepen, waarschuwingen, voorlichting etc hierover, dus dat het geen verrassing is, is zacht uitgedrukt.

En dat providers etc het gebruik ervan uitstellen is simpelweg gemakzucht. Waarom je verdiepen in IPv6 als je met minder moeite op het oude IPv4 kunt voortkabbelen?

[Cergorach]

Er gaan al veel langer alarm bellen af, het heeft slechts ruim 20 jaar geduurd voordat daadwerkelijk de ipv4 adressen op zijn (voor de EU dan)...

13 mei 1999:
nieuws: Tekort aan IP adressen in nabije toekomst

[Kain_niaK]

Ik vind dat soort 20 jaar oude t.net artikelen met reacties zo prachtig.

Alsof je even in een teletijds machine stapt. Heerlijk.
Even doorklikken naar een 20 jaar oud artikel over winamp en dan eentje over een nieuwe voodoo cart. Fantastisch! Alleen jaar van de linkrot voor plaatjes, die zijn bijna altijd allemaal kapot.

[Reactie gewijzigd door Kain_niaK op 23 juli 2024 01:28]

[djs909]

Mooi he. In de jaren 80 hoorde ik ook al dat de olie in 20 jaar op zou zijn.

[Yggdrasil]

Rare vergelijking. Voorspellen is moeilijk, maar bij IPv4 adressen een stuk eenvoudiger dan bij olie. We weten immers precies hoeveel adressen er in totaal zijn en wie ze gebruikt.

[ajolla]

Dat is marketing. Suggereer schaarste en de prijs gaat omhoog.
Rockefeller heeft heel slim door z'n ingenieurs op de eerste belangrijke internationale olieconferentie het verhaal laten verspreiden dat olie 'mineraal' ipv abiogeen van oorsprong is.
De meesten geloven dat nog steeds.
Maar waar komen dan die grote zwavelconcentratieverschillen vandaan?
En waar komt het methaan op kometen en asteroïden vandaan?

[vDorst]

Ik ben benieuwd wat er gebeurt is met de "The IPv4 Cleanup Project" van Dave Taht.
Zie: https://github.com/dtaht/unicast-extensions
Tevens heeft linux kernel er al support voor.
Zie: https://git.kernel.org/pu...4055f3525c780142fc72e543f

[Reactie gewijzigd door vDorst op 23 juli 2024 01:28]

[Maurits van Baerle]

Ik denk dat het daar veel te laat voor is. Zou jij als bedrijf willen betalen voor een IP range die vrijgemaakt is uit een voorheen geblokkeerde range? Je zult je jarenlang je af moeten vragen of die ene klant die jouw IP niet kan bereiken misschien ergens op de route van zijn/haar client naar jouw server een router met hard gecodeerde ranges tegenkomt. OS-en, modems en routers thuis hebben een redelijke omloopsnelheid. Printers, scanners of routers op belangrijke knooppunten al een stuk minder. Voor dat die allemaal zijn aangepast...

Zo'n project als dit was welkom geweest als het rond 2000 resultaten had geboekt. Nu is IPv6 als alternatief al zo ver dat je een beetje achter de feiten aan loopt.

[Blokker_1999]

Hangt ook weer van het doel af. Denk dat wij er wel gebruik van zouden maken.

[Raizio]

De grootste voorloper in Nederland, XS4All, gaat nu verdwijnen in KPN. Gaat ons percentage nog meer omlaag

[Moartn]

Bij mijn huis-tuin-en-keuken Ziggo abonnementje met standaardmodem/router heb ik anders keurig IPv6, sinds een paar weken. Als ze dat bij iedereen aanzetten gaat het opeens heel hard.

Weet je wie bij Ziggo geen IPv6 hebben? Tweakers, met eigen routers. Daar durven ze het niet aan te zetten omdat ze bang zijn dat ze hun custom netwerkinstellingen niet goed hebben staan waardoor het stuk gaat als er opeens IPv6 bij komt. Vind ik best grappig

[Dorank]

Dus Ziggo doet niet gewoon dhcpv6-pd? Wat mij betreft de standaard methode om de enduser dat lekker zelf te laten regelen?

[dmantione]

Ziggo doet geen dual-stack, maar ds-lite. Dat betekent dat als je bij Ziggo ipv6 hebt, je modem geen ipv4-adres meer krijgt. Het modem moet voor ipv4 een tunnel opzetten. Dat men dat de eindgebruiker niet ongevraagd zomaar wil laten opbouwen snap ik wel.

[Brahiewahiewa]

Ziggo doet geen dual-stack

ligt er aan waar je woont; ik heb gewoon dual-stack van ziggo

[ASS-Ware]

Ziggo doet geen dual-stack, maar ds-lite. Dat betekent dat als je bij Ziggo ipv6 hebt, je modem geen ipv4-adres meer krijgt. Het modem moet voor ipv4 een tunnel opzetten. Dat men dat de eindgebruiker niet ongevraagd zomaar wil laten opbouwen snap ik wel.

Dat is niet overal zo, ik heb gewoon IPv6 en een publiek IPv4 adres.
Bovendien denk ik niet dat er voor IPv4 een tunnel moet worden opgezet voor DS-Lite, volgens mij krijg je gewoon een 10.x.x.x adres achter NAT.

[dmantione]

Je hoeft die tunnel natuurlijk niet zelf op te zetten, dat doet het modem voor je. Dus voor jou als eindgebruiker lijk je gewoon ipv4 en ipv6 te hebben. Het is pas op het moment dat het modem in bridging mode gezet wordt dat je het verschil gaat zien: Bij dualstack krijgt je router via DHCP dan zowel een IPv4- als v6-adres, terwijl bij een DS-lite je dan nog een tunnel moet gaan opzetten om het IPv4-adres te krijgen.

[Naafkap]

Ik heb via Ziggo nog steeds geen IPv6. Enkele jaren geleden hebben ze getest en werkte het een paar weken, maar nog steeds niks. Dus zo geweldig is Ziggo niet bezig hoor.

En nee, geen bridgemodus.

[computerjunky]

3 jaar geleden toen ik hier ziggo aan vroeg kreeg ik ipv6 al standaard. Ik heb het alleen terug laten zetten omdat ipv4 sneller was bij een aantal websites en veel software niet geschikt is voor ipv6.

Ze gaan je alleen geen nieuwe modem geven puur om je aan een ipv6 adres te helpen.

[krakendmodem]

KPN heeft/biedt ook gewoon IPv6. En KPN kan en zal de kennis van XS4ALL ongetwijfeld in kunnen zetten om dit later alsnog toe te kunnen passen.

Op onze KPN lijn hebben we dan weer net geen IPV6. Maar dat buren die net op een andere DSLAM hangen weer wel. Ach, het ze zo. .

Aan de andere kant heeft geen enkele Ziggo klant in deze straat IPv6. Dat praat het nog niet goed, maar mogelijk komt het wel als die glasvezel hier binnenkort in de meterkast zit.

[MagicTempest]

Wel of geen IPv6 hebben heeft niets te maken met de DSLAM. De DSLAM doet eigenlijk alleen maar het laag 1 deel. Over de DSL lijn zet je modem een PPP tunnel op. Aan die tunnel kunnen IP adressen toegekend worden, meestal door middel van DHCP. Dat je buren wel IPv6 hebben en jij niet zal eerder met de versie/software van je modem, of met instellingen die je buren zelf aangepast hebben, te maken hebben dan met de DSLAM.

[krakendmodem]

De buren hebben allemaal hetzelfde modem (KPN Experiabox V10 met dezelfde KPN firmware en een VDSL2 lijn zonder vectoring.).

Als ik een Fritzbox aan de telefoonlijn hang, laat deze mij netjes zien dat ik op een ander type DSLAM hang dan de buren. We hangen allebei aan de wijkcentrale, er zit dus geen actieve straatkast tussen. Natuurlijk loop ik niet dagelijks bij iedereen over de vloer en kan ik niet af hoc zien welke DSLAM ik hang.

Ik heb KPN wel eens de vraag gesteld waarom ik nog geen IPv6 had, er kwam toen als antwoord uit dat de DSLAM hier niet voor geschikt was. Nu ik jou reactie lees klinkt dat inderdaad een beetje vreemd. En voor mij meteen een mooi moment om de Cisco boeken maar weer eens in te duiken .

[rc5proxy]

Nooit ergens gelezen dat XS4all gebruikers na overgang hun ipv6 adres kwijt gaan raken ?

[tweaknico]

Tja dat adres is uit een reeks die toegekend is aan XS4ALL... (je krijgt van hun ook een Prefix Delegation).
Het is niet aan JOU persoonlijk toegekend.
2001:980::/29 ( t/m 2001:987::) en 2001:888::/29 (t/m 2001:88F::) zijn toegewezen aan XS4ALL.
(AS3265)

Dus dat adres raak je weer kwijt na een overstap. idd. er zit een hernummering aan te komen.

[tweaknico]

Freedom Internet heeft aangekondigd om ten minste IPv6 direct te ondersteunen.

[Blokker_1999]

Ze kunnen waarschijnlijk niet anders. Ze gaan moeite hebben om voldoende IPv4 adressen vast te krijgen

[tweaknico]

Die kunnen ze via een partner die ook WBA regelt lenen als het goed is.

[ajolla]

Zit jij in AU/NZ?

[Joopie]

Bij KPN heb ik ook een IPv6 adres voor elk apparaat. Daarnaast gebruikt XS4All toch ook gewoon het netwerk van KPN? Of mis ik nu iets belangrijks?

[krakendmodem]

XS4ALL gebruikt wel het KPN netwerk, maar XS4ALL heeft zeker wel een eigen netwerk/AS naar het internet.

KPN wordt in dit geval gebruikt om de internet verbinding thuis te krijgen. Maar zodra je naar Google gaat is het DSL/glas > KPN infra > netwerk XS4ALL > internet > Google.

[Kabouterplop01]

herstel:

DSL/glas > KPN infra > netwerk XS4ALL > KPN infra > internet > Google

[hottestbrain]

Onjuist. netwerk XS4ALL kan gewoon via eigen connecties met bijvoorbeeld AMS-IX naar buiten, komt KPN niet aan te pas momenteel.

Edit: Juist, dus wel. Vlaag van verstandsverbijstering blijkbaar want hoe komt het van DC binnen bij AMS-IX?

[Reactie gewijzigd door hottestbrain op 23 juli 2024 01:28]

[tweaknico]

IPv4:
1 lo0.dr16.d12.xs4all.net (194.109.5.227) 1.835 ms 1.785 ms 1.757 ms - xs4all net. (na glas wba access)
2 0.ae26.xr4.3d12.xs4all.net (194.109.7.141) 3.411 ms 0.ae26.xr3.1d12.xs4all.net (194.109.7.137) 1.695 ms 1.663 ms (xs4all core..?
3 0.et-7-1-0.xr1.sara.xs4all.net (194.109.5.3) 2.014 ms 2.003 ms 0.et-7-1-0.xr1.tc2.xs4all.net (194.109.5.5) 1.863 ms
4 * google.xs4all.net (194.109.11.2) 3.912 ms *

IPV6:
1 lo0.dr16.d12.xs4all.net (2001:888:1:1006::1) 1.836 ms 1.753 ms 1.766 ms
2 2001:888:1:4055::1 (2001:888:1:4055::1) 1.728 ms 2001:888:1:4054::1 (2001:888:1:4054::1) 1.712 ms 1.692 ms
3 et-7-1-0.xr1.tc2.xs4all.net (2001:888:1:4000::1) 1.881 ms 0.so-1-2-0.xr1.tc2.xs4all.net (2001:888:1:4001::1) 1.925 ms 0.ge-1-2-0.xr1.sara.xs4all.net (2001:888:1:4005::1) 1.906 ms
4 google.xs4all.net (2001:888:1:8004::2) 2.024 ms * *
5 2001:4860:0:f8d::1 (2001:4860:0:f8d::1) 3.708 ms 2001:4860:0:f8c::1 (2001:4860:0:f8c::1) 2.171 ms 2001:4860:0:f8d::1 (2001:4860:0:f8d::1) 3.683 ms


Ze hebben zelfs een directe peering met Google.
DSL /glas -> KPN-WBA - netwerk XS4ALL -> network google.

[Kabouterplop01]

Dat zegt niet alles; niet overal worden de hops gepropageerd. En niet overal gaat het verkeer over die infra.
Een direct / private peering is voor hen heel voordelig, maar er zit kpn infra tussen.

[Reactie gewijzigd door Kabouterplop01 op 23 juli 2024 01:28]

[tweaknico]

Een ook niet alle glas in NL is van KPN er zijn voldoende anderen die dark fiber aanbieden.
Dus ja er zal andere infra tussen zitten van zowel wel als niet KPN. .Maar dat is niet zichtbaar.

[Kabouterplop01]

Dat klopt. Het heeft ook te maken met het verschil tussen peering en transit.

[TweakerVincent]

Wat een onzin. Dat was mss in de jaren 90 zo. Sentiment is blijven hangen.

[mae-t.net]

Ik was abonnee bij xs4all rond die tijd, en kan me niet herinneren in de jaren '90 ooit iets over IPv6 gehoord te hebben (was in 1998 net uitgewerkt als standaard), dus dat lijkt niet te kloppen.

[TweakerVincent]

Ik doelde op het stukje dat xs4all zo geweldig innovatief is. Niet ip6. Hebben een leuk imago maar is allang niet meer zo

[dmantione]

IPv6 werd door XS4All in 2010 geïntroduceerd, als eerste in Nederland, ver voor de nummer 2. We kunnen over de definitie van lang twisten, maar 2010 is geen jaren '90.

[necessaryevil]

Kan je modem/router die ipv6 ondersteund je interne netwerk nog op ipv4 laten draaien? Ook naar buiten toe? Bijvoorbeeld voor je mediaplayer of je Arduino?

[dmantione]

Ja, dat kan. Er zijn een hoop methoden om beide naast elkaar te gebruiken, het beste is als je internetaanbieder dual-stack doet, maar in alle gevallen zijn er oplossingen voor ipv4-apparaten.

[necessaryevil]

Oké. Stel nu dat er alleen nog ipv6 is, kunnen de meeste ipv6 routers dat dan ook zeg maar een soort van vertalen naar ipv4?

[dmantione]

IPv4 en IPv6 zijn aparte internetten. Als je alleen nog maar aangesloten bent op het IPv6-internet, dan zul je een tunnel moeten opzetten naar het IPv4-internet. In IPv6-modems en routers zit de functionaliteit om die tunnels op te zetten, zodat je toch IPv4 kunt krijgen.

Waarschijnlijk zullen internetaanbieders in een dergelijk zelf voor een tunneleindpunt zorgen voor toegang tot het IPv4-internet, maar stel een internetaanbieder zou dat niet doen, dan kun je via een derde partij een tunneleindpunt regelen. Kwestie van het IP-adres van het eindpunt in je modem aanpassen. Net als dat er nu aanbieders zijn van IPv6-tunnels voor mensen die geen IPv6 van hun internetaanbieder hebben, zal dat in de toekomst ook omgekeerd het geval zijn.

Geen zorgen dus.

[necessaryevil]

Dankjewel! Ja ik had ergens wel verwacht dat het op de een of andere manier wel goed zou komen met legacy. Dat maakt het toch nog vreemder dat de ipv6 uitrol zo moeilijk verloopt.

[pdukers]

IPv4 en IPv6 zijn aparte internetten.

Dat is m.i. de grootste flater die men heeft gemaakt. Men had IPv6 backwards compatible moeten maken.

[deadinspace]

Dat is m.i. de grootste flater die men heeft gemaakt. Men had IPv6 backwards compatible moeten maken.

IPv6 is backwards compatible in de zin dat IPv4 adressen bevat zijn in de IPv6 adressen; 192.0.1.73 binnen de IPv6 wereld is ::ffff:192.0.1.73.

Volledig backwards compatible in de zin dat IPv4 hosts met alle IPv6 hosts kunnen praten is simpelweg onmogelijk. IPv4 biedt zo'n 4 miljard adressen, en dat is te weinig. Het aantal adressen vergroten breekt de compatibiliteit, want IPv4 biedt die mogelijkheid simpelweg niet.

In die zin is het probleem meer dat IPv4 niet forwards compatible is, en daar kunnen we nu niks meer aan veranderen.

[tweaknico]

IPv6 hosts kunnen verbinding maken met een IPv4 host (als de machine dual stack is) en gebruikt dan de IPv4 stack voor deze dienst. Dit is een adres schema om dat te kunnen aangeven aan de IPv6 stack.
Het blijft een IPv4 connectie over de kabel. (Het is ook niet dat dat de andere kant een IPv6 adres ziet.)

[tweaknico]

IPv6 -> IPv4 en omgekeerd zal je via een soort van proxy moeten doen.
probleem is dat niet alleen het lopende protocol moet worden omgezet, maar ook allerlei aanpalende zaken zoals bv. DNS ( A ---> AAAA en omgekeerd) moet een goede mapping hebben.

Maar IPv4 naast IPv6 is minder een probleem. En als een IPv4 apparaat lokaal alleen en A record heeft dan is benaderen op naam geen probleem.
Je kan ook een conventie bedenken...
server -> CNAME SERVER4 RR
server -> CNAME SERVER6 RR
SERVER4 > A RR
SERVER6 -> AAAA RR.

[HKLM_]

Tijd dat ziggo ipv6 gaat uitdelen aan de mensen die hun modem in bridge hebben staan.

[Naafkap]

Laat ze eerst maar eens beginnen met IPv6 uitdelen voor alle gewone gebruikers zonder bridgemode

[fantafriday]

Daar zijn ze al een aantal jaar mee bezig.

[Naafkap]

Daar merk ik dan weinig van. Het wordt al heel lang door Ziggo beloofd, maar tot op heden is het bij een aantal weken testen gebleven en dat is inmiddels ook alweer een jaar of 2 a 3 geleden. Het heeft gewoon geen prioriteit omdat het geen geld oplevert.

[lonaowna]

Als je de klantenservice om een nieuw modem (ConnectBox) vraagt kan je meteen gebruik maken van IPv6. Nieuwe klanten krijgen meteen zo'n modem en kunnen het dan ook meteen gebruiken. Dit is al meer dan een jaar het geval.

[Naafkap]

Duidelijk. Dank voor deze informatie. Jammer dat ik dat niet via ziggo verneem, maar ik begrijp het ook wel. Noodzaak is er voor het overgrote deel van de gebruikers niet en het kost alleen maar geld. Maar ik zal eens een belletje wagen.

[lonaowna]

Ja, ik kan het Ziggo ook niet kwalijk nemen dat ze niet meteen nieuwe modems opsturen. Zonde van het geld, de meeste klanten zullen er geen baat bij hebben en alleen maar geïrriteerd zijn dat ze hun apparatuur moeten omwisselen, en het is slecht voor het milieu.

Ik had via de chat op https://ziggo.nl/ gezegd dat ik graag een nieuw modem wou om van IPv6 gebruik te maken, en toen stuurde ze er meteen een op. Er is overigens een kans dat het dan nog niet meteen werkt, dan moet je vragen of ze de "IPv4-voorkeursregel" bij je account weghalen.

[xoniq]

Ik heb al geruime tijd een IPV6 adres bij Ziggo.

[tweaknico]

1 adres of een prefix van /48...? (oudere stanaard) /56...? (huidige standaard) , /64 (ISP die het niet helemaal begrepen heeft), /128 (ISP het helemaal NIET begrepen heeft).

[xoniq]

Geen idee hoe je dat bedoelt. (Een string van 8 secties met 4 tekens per sectie (totaal, 32 tekens lang).
Ik check het enkel via watismijnip.net.
Verder ben ik niet zo in to de opbouw van IP-adressen.

EDIT: Toch even verder gelezen in de opbouw van het IPV6 adres, zoals ik het lees, zijn de eerste 4 blokken de prefix, en de laatste 4 de host. En de eerste 4x4 = 16 hexadecimale tekens, x 4 (bits) = 64 bit prefix. Correct me if i'm wrong.

[Reactie gewijzigd door xoniq op 23 juli 2024 01:28]

[tweaknico]

In IPv4 heb je een "prefix" ook wel bekend als CIDR (192.168.10.0/24 .... 24 is de prefix lengte).
Bij IPv6 heb je dat ook. volledig adres is /128. (De achterste 64 worden feitelijk door hardware bepaald MACADRES bv. Hierdoor is er lokaal ook nauwelijks DHCP nodig voor IPv6)
de allereerste paar bitjes (links) bepalen if het een lokaal, globaal, unicast of multicast adres is.
Het gaat om de /xxx bij de adres reeks. Dat geeft whasismyip.net niet.

[xoniq]

Met "/sbin/ifconfig | grep inet6" zie ik het volgende:

inet6 ::1 prefixlen 128
inet6 ####::1%lo0 prefixlen 64 scopeid 0x1
inet6 ####::####:####:####:####%en1 prefixlen 64 secured scopeid 0x6
inet6 ####:####:####:####:###:####:####:#### prefixlen 64 autoconf secured
inet6 ####:####:####:####:####:####:####:#### prefixlen 64 autoconf temporary
inet6 ####:####:####:#:####:####:####:#### prefixlen 64 detached autoconf secured
inet6 ####:####:####:#:####:####:####:#### prefixlen 64 detached autoconf temporary
inet6 ####::####:####:####:####%awdl0 prefixlen 64 scopeid 0xb
inet6 ####::####:####:####:####%llw0 prefixlen 64 scopeid 0xc
inet6 ####::####:####:####:####%utun0 prefixlen 64 scopeid 0xd
inet6 ####::####:####:###:####%utun1 prefixlen 64 scopeid 0xe
inet6 ####::####:####:####:####%utun2 prefixlen 64 scopeid 0xf
inet6 ####::####:####:####:####%utun3 prefixlen 64 scopeid 0x10
inet6 ####::####:####:####:####%en5 prefixlen 64 secured scopeid 0x11

Snap er zelf de ballen van
(Waarden gesanitized i.p.v. openbaar)

[Reactie gewijzigd door xoniq op 23 juli 2024 01:28]

[tweaknico]

Op de public interface van je router/modem?
De lan zijde is meestal /64..

[xoniq]

Geen idee, hoe kan ik dat het beste checken? (Heb macOS en Linux tot mijn beschikking) Via de modem zelf kan ik niet zoveel, is Ziggo connect box.

[tweaknico]

Sorry ik heb geen Ziggo. of toegang tot een modem.
als dit de binnenkant van je aansluiting is dan denk ik dat je een /64 public prefix hebt.
Dan is UPC erg zuinig met de adresjes...

[hahaha2223]

Wij hebben al sinds Juni ipv6, daar heb je inderdaad de connectbox voor nodig die je meestal zonder problemen kan aanvragen

[ajolla]

Precies. Waarom geld uitgeven als je het niet terugkrijgt?

[Naafkap]

Omdat er ook nog zoiets bestaat als service naar je trouwe klanten toe die elke maand netjes betalen en ervoor zorgen dat je je bedrijf kan voeren?

Meeste Nederlanders zien dat niet in en kijken alleen maar naar de centen.

[ajolla]

Ze léveren toch ook internet? Alleen misschien niet zoals jij 't wilt.

[Yoshi]

Ik denk niet dat het uitmaakt welke adressen je achter je modem hebt, het is de modem zelf en alles naar en ophet internet dat telt. Meeste organisaties kunnen nog decennia door met ipv4 adressen op de lan, zolang er geen nood aan is zal men dat niet snel veranderen, zelf met iot op het oog. Dat laatste heeft dan weer met geld en tijd te maken natuurlijk, het is niet dat netwerkbeheerders er geen oren naar hebben. Was als reactie bedoeld op @Joopie1994 .

[Reactie gewijzigd door Yoshi op 23 juli 2024 01:28]

[tweaknico]

Het gaat erom dat je een PREFIX krijgt (/48, /56... ) en dat je thuis een paar netwerkjes kan inrichten (Private LAN, Gast VLAN, IOT-LAN) etc.

[dmantione]

Ik zou bijna zeggen "Jippie! Joehoe!"... Vanzelfsprekend kun ik iedereen een ipv4-adres en CGNAT wat steeds meer in zwang raakt is een drama. Echter, zullen partijen nu pas met de neus op de feiten gedrukt worden dat ze toch echt ipv6 in moeten gaan voeren en eenmaal op ipv6... het is zo lekker dat je altijd ip-adressen tot je beschikking hebt, je wilt niet meer terug.

[Verwijderd]

Hopen dat Ziggo nu eindelijk eens met IPv6 komt! (in bridge mode)
Wachten pas 21 jaar tot Multikabel > Quicknet > Ziggo er aan gaat beginnen...