Ziggo zet uitrol ipv6 tijdelijk op lager pitje

Ziggo zet de uitrol van ipv6 tijdelijk op een lager pitje, om te onderzoeken of de uitrol voor problemen zorgt. Zijn die er niet, of kunnen ze worden opgelost, dan gaat de uitrol weer verder, zo belooft de kabelaar.

Op een Ziggo-gebruikersforum merkten Ziggo-abonnees op dat ze opeens geen ipv6 meer konden gebruiken, waar ze eerst wel een ipv6-adres hadden. Ziggo bevestigt dat desgevraagd. Volgens Ziggo-woordvoerder Gradus Vos is de invoering deels teruggedraaid. "Maar we gaan zeker niet stoppen", zegt hij.

Ziggo rolt ipv6 in batches uit. Bij de meest recente uitrol traden daarbij problemen op; de helpdesk kreeg meer klachten van mensen met internetproblemen. "We willen onderzoeken of de activatie van ipv6 daar de oorzaak van is", aldus Vos. "We hebben de laatste uitrol daarom teruggedraaid." Momenteel worden ipv6-adressen in kleinere batches uitgerold, om te kijken of de problemen zijn te wijten aan de ipv6-uitrol. "Momenteel zijn daar nog geen aanwijzingen voor", zegt Vos. De provider hervat de reguliere uitrol van ipv6 daarom waarschijnlijk binnenkort.

Ziggo begon in april met de uitrol van ipv6. Daarbij gaat het in eerste instantie enkel om klanten uit het oude Ziggo-gebied, en niet om UPC-klanten. Ook moeten ze een bepaald modem hebben. UPC gaf eerder al aan snel te willen beginnen met de uitrol van ipv6, maar het is nog onduidelijk wanneer klanten een ipv6-adres krijgen.

Het aantal ipv4-adressen is aan het opraken; een overstap naar ipv6 wordt gezien als de enige optie om het internet te kunnen laten groeien. Waar er circa 4,3 miljard ipv4-adressen zijn, ligt het aantal ipv6-adressen fors hoger. Er zijn om en nabij de 340 sextiljoen ip-adressen - dat is een getal van 39 cijfers - wat betekent dat er per aardbewoner veel meer ipv6-adressen beschikbaar zijn dan dat er in totaal ipv4-adressen zijn. Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.

Reacties (151)

[Tozz]

Ik had IPv6 van Ziggo en heb het zelf weer uitgezet. Ik had namelijk enorm veel problemen, dat ik ook gemeld heb bij Ziggo. Dat probleem was destijds nieuw, maar inmiddels kunnen ze het probleem reproduceren.

Het probleem is dat verbindingen (zowel in- als uitgaand) soms niet werken. Een connectie naar een IPv6-enabled website blijft dan hangen totdat je uiteindelijk een timeout krijgt. Er zit echter geen logica in, want een zelfde request een paar seconden later kan soms wel goed gaan.. maar soms ook niet.

Het lijkt alleen mis te gaan bij statefull (TCP) connecties. Zaken als ICMP en volgens mij ook UDP gingen wel gewoon goed. Tijdens mijn laatste navraag was er nog geen zicht op een oplossing.

Ik kan dus uit eigen ervaring melden dat Ziggo inderdaad problemen heeft met de IPv6 connectiviteit.

[Maurits van Baerle]

Dat is interessant. Welk modem heb je?

[Karmic Bob]

Ik kan niet voor Tozz spreken maar ik had de laatste paar maanden veel last van timeouts met de geleverde Cisco EPC3928AD. Daarvoor had ik nooit connectie problemen. Ik zit in het oude Ziggo gebied en de problemen begonnen naar nu blijkt indd in de periode dat Ziggo met IPv6 begon.
Nu vandaag lijkt het voor het eerst in lange tijd weer mogelijk om behoorlijk te downloaden en surfen tegelijk (jippie!) (eigelijk had ik ook al lang moeten klagen bij Ziggo!)

[Reactie gewijzigd door Karmic Bob op 26 juli 2024 22:34]

[Acidrain]

Same here, oude Ziggo gebied en UBEE evw321b modem.
Dacht eerst dat het aan de wifi lag omdat mijn pc (bedraad) nergens last van had en alle mobiele apparaten wel.
Toen mijn laptop bedraad het zelfde probleem had bedacht ik me dat ik lang geleden ip6 had uitgeschakeld op de pc.
Op de laptop ook uitgeschakeld en probleem ook weg.
Bleef mobile over..
Oude hotspot er tussen geknald die geen ip6 ondersteund en wifi op het Ziggo modem uitgezet en nu werkt alles weer min of meer...

[Maurits van Baerle]

Zou je jouw ervaring misschien willen delen in Het Grote IPv6 Topic op GoT? Daar proberen we uit te vinden wat er nou precies mis gaat met Ziggo en IPv6.

[Maurits van Baerle]

Zou je je ervaring misschien willen delen in Het Grote IPv6 Topic op GoT? Daar proberen we uit te vinden wat er nou precies mis gaat met Ziggo en IPv6.

[Tozz]

Op moment dat ik 't had aangesloten was de Ubee 321b de enige modem die werd ondersteund voor IPv6. Ik begreep dat later de 320 toegevoegd is aan 't lijstje.

De Cisco's hebben voor zover mij bekend nog geen IPv6 support gehad bij Ziggo.

Voor de volledigheid, ik had een Ubee 320 maar heb speciaal voor IPv6 een 321b van Marktplaats geplukt.

[Maurits van Baerle]

Zou je je ervaring misschien willen delen in Het Grote IPv6 Topic op GoT? Daar proberen we uit te vinden wat er nou precies mis lijkt te gaan met Ziggo en IPv6.

[Verwijderd]

Tsja.... Als ze wel een pilot programma waren gestart dan hadden ze waarschijnlijk mensen met meer kennis en goodwill gehad die eventuele problemen aankaarten en daarbij wat meer info geven dan "het werkt niet".

"We willen onderzoeken of de activatie van ipv6 daar de oorzaak van is", aldus Vos.

Er is iets veranderd dus we zetten een verandering maar weer uit. Dat is echt zo amateuristisch, dat moet je niet willen. Doe onderzoek naar een oorzaak, niet gewoon een verandering terug draaien onder het mom van "misschien is dat het wel".

Er zijn talloze landen een stuk verder dan NL, lijkt me eerder een Ziggo probleem dan een IPv6 probleem.

[the_stickie]

Een deel van het omgaan met een probleem van die aard is de impact beperken door mogelijk gerelateerde changes terug te draaien, en vervolgens een analyse van de 'root cause' te maken. In een complexe infrastructuur is het vaak moeilijk om retrospectief de juiste data te verkrijgen (zoals specifieke performance data, debuglogs, netwerk trafiek,...) en is het dus absoluut noodzakelijk alles in gereedheid te brengen om, met zo weinig mogelijk impact, het incident te reproduceren of althans opnieuw de omstandigheden te scheppen (door bv gradueel load bij te voegen of failures te reproduceren).
Dit artikel bevat volgens mij te weinig technische info en interne keuken om uitspraak te doen over de graad van amateurisme of professionaliteit. Ik vind de communicatie alvast netjes.

[Verwijderd]

Als de situatie dermate urgent is ("van die aard") dat je een roll-back doet dan zijn er diverse situatie's die daar aan voorafgingen een paar die ik nu zo kan bedenken.

* Een uitrol doen met te weinig monitoring of proces bewaking voor analyse, niet reptrospectief klagen dat je info niet hebt.
* Geen goede tests/pilots gedaan, te kleine groep om een dergelijk groot probleem te ontdekken
* Indien het specifieke gevallen zijn, dus kleinschalige impact deze verbindingen terugdraaien. Er zou een situatie kunnen zijn die buiten de pilot/test groep viel.
* Indien uniek / complex IPv6 bug, melden! Zodat ook anderen op deze zandkorrel op de hoogte zijn.

>>Dit artikel bevat volgens mij te weinig technische info en interne keuken om uitspraak te doen over de graad van amateurisme of professionaliteit.

Als Ziggo door wat betere communicatie (bv op hun site of twitter) wat specifiekere informatie zou geven dan zou er wellicht ook meer begrip zijn. Maar blijkbaar wilt Ziggo in tegenstelling tot vele ander ISP's hun uitrol zoveel mogelijk in de mist houden.

/Edit
Ik wilde nog even aanhalen dat er niets van op de Ziggo site staat, maar gelukkig is dat recent veranderd want nu vind je wel iets.
https://www.ziggo.nl/klantenservice/internet/verbinding/ipv6

[Reactie gewijzigd door Verwijderd op 26 juli 2024 22:34]

[PcDealer]

Ik vind de communicatie alvast netjes.

Ik niet. Ik verwacht van een professionele partij dat ze mij als consument inlichten over een rollback van een van mijn diensten. Dat is hier niet gebeurd. "Desgevraagd" komt Ziggo met een reactie.

[Reactie gewijzigd door PcDealer op 26 juli 2024 22:34]

[ppl]

Ze hebben het project opgestart voor er sprake was van een fusie van twee grote kabelmaatschappijen waarbij het netwerk van de een op gaat in dat van de ander. Zo ergens tussendoor is die fusie op technisch vlak gebeurd dus dan zou je verwachten dat men het project voor de IPv6 uitrol opnoem bekijkt om te zien of het nog opgaat voor de nieuwe situatie. Als dat niet is gedaan en ze gaan nu direct naar technische oorzaken kijken dan kun je inderdaad een paar vraagtekens zetten bij professionaliteit.

Als ik het zo lees is het netwerk kennelijk toch nog niet compleet gefuseerd en lijkt alleen het tv deel te zijn gefuseerd. Dan kun je ook zonder problemen doorgaan met de uitrol maar of het verstandig is zo met een mogelijke fusie van de netwerken in het verschiet is vers 2. Als je toch al de investering hebt gedaan en niet zeker weet wanneer dat samengaat kun je tot die tijd eigenlijk net zo goed doorgaan; afmaken waar je mee begonnen bent.

Wat betreft het terugrollen van de wijziging kunnen we daar heel kort over zijn: klanten hebben massaal geklaagd dat dingen niet functioneren en als je niet weet wat de oorzaak is kun je beter terug naar de oude situatie. Vanuit de klant gezien is het wel fijn dat je ook datgene krijgt waar je voor betaald niet waar?

[Moosenl]

Tuurlijk, jij zou gewoon doorgaan met uitrollen. Wetende dat dat de enige verandering was en problemen veroorzaakt bij je klanten.

[Verwijderd]

Mijn indruk is dat er gewoon te weinig getest is, bij andere providers gaat het immers wel goed.

[huntedjohan]

ik ben niet zo heel technisch aangelegd, maar als ik dit lees

Ziggo zet de uitrol van ipv6 tijdelijk op een lager pitje, om te onderzoeken of de uitrol voor problemen zorgt. Zijn die er niet, of kunnen ze worden opgelost, dan gaat de uitrol weer verder, zo belooft de kabelaar.

zie ik daar weinig amateuristisch in, maar eerder gewoon een normale gang van zaken bij een verandering die mogelijk problemen geeft. Je schakel het TIJDELIJK uit, ga kijken wat er dan veranderd, en ga van daaruit weer verder werken. Zolang je niet weet waar een mogelijk probleem vandaan komt kun je toch moeilijk een service blijven verlenen die onderhevig is aan problemen? Durf te wedden dat ze dat het woord amateuristisch ook naar hun hoofd zouden krijgen als ze door gingen met IPV6 terwijl ze wisten dat er problemen waren en gewoon door gingen met de service verlenen.

[Maurits van Baerle]

Er is iets veranderd dus we zetten een verandering maar weer uit. Dat is echt zo amateuristisch, dat moet je niet willen. Doe onderzoek naar een oorzaak, niet gewoon een verandering terug draaien onder het mom van "misschien is dat het wel".

Ik ga er dan ook van uit dat ze zelf wel veel meer weten waar er mogelijk een probleem zit dan wat je aan de doorsnee consument communiceert. Aan een Gradus Vos: "Er is een probleem met de routingtabellen in de Ubee321 en de Ubee320 die moeite heeft met onze /56 Prefix Delegation doorzetten naar achtergelegen subnets." heeft een doorsnee consument niet zoveel.

Als je naar de grafieken kijkt dan lijkt het dat twee van de drie modellen modems weer uitgezet zijn. Mogelijk zijn ze nu samen met de leverancier tests aan het draaien.

[Verwijderd]

Ze traineren net zo lang tot ze er extra geld voor kunnen vangen.
Wie dacht dat de lieverdjes UPC en Ziggo (Liberty Global) dat niet doen, check hun lobby tegen het openstellen van de kabel maar.

[TD-er]

En hoe zou je meer geld kunnen vangen voor IPv6?

[Verwijderd]

@: TD-er

"En hoe zou je meer geld kunnen vangen voor IPv6? "

Het antwoord op die vraag is heel simpel:

Omdat je dan toch nieuwe klanten kunt aansluiten en dan meer geld ontvangt als de IPv4 adressen zo goed als op zijn, anders zou je immers nee moeten verkopen.

[SA007]

Wachten tot ipv4 zover op is dat er 'grote' websites komen die alleen op ipv6 zitten en dan extra geld vragen voor de toegang tot die websites.

[joco]

zal dat niet vallen onder netwerk neutraliteit?

[Botros84]

Nee dat doet het niet. Ik heb deze vraag voorgelegd aan de Autoriteit Consument en Markt toentertijd. Zij zijn van mening dat IPv6 een dienst is die Ziggo kan aanbieden en ik de vrijheid heb om van provider te wisselen die wel IPv6 aanbied. Dit inmiddels ook gedaan.

Ik heb ze ook de situatie voorgehouden dat je zometeen websites hebt die alleen maar via IPv6 te bereiken zijn. Hier hadden deze heldere lichten bij de Autoriteit Consument en Markt geen boodschap aan en ze bleven bij hun standpunt dat IPv6 een dienst is.

Neutraliteit?

[SA007]

Dat is een hele goede vraag.

Technisch gezien vraag je niet extra geld voor toegang tot ipv6 websites, maar voor ipv6 zelf.
Op een 56k modem kan je ook veel websites niet gebruiken ook al is het niet effectief geblokkeerd.

Ik heb geen idee hoe ver de netneutraliteit gaat met 'isp die een techniek niet ondersteund'.

[ppl]

Of het nou om toegang tot een bepaalde dienst zoals Sizz gaat of om het gebruik van IPv6 maakt voor de wet niets uit. Het is het actief blokkeren van (een deel) het internet om commerciële redenen dat bij wet verboden is. Als het om een technische reden gaat ligt het iets anders daar de wet wel voorziet in bepaalde uitzonderingen.

Eigenlijk is het heel simpel: als ze je toegang tot het internet geven dan mag er niks geblokkeerd zijn. Je moet overal toegang toe hebben voor zover dat technisch mogelijk is.

[SA007]

Dat technisch mogelijk is dus een beetje vaag.
Het is technisch mogelijk dat een isp ipv6 levert.
Als jouw isp dat niet doet omdat hun het niet technisch mogelijk vinden is dat niet actief blokkeren, maar niet mogelijk maken.

[Verwijderd]

Waarom i.p.v. afhankelijk te zijn van ISP's, maken we niet een klein stukje software (OpenWRT kernel moduletje) dat van ieder IPv6 apparaat een kleine router maakt? Dan tracht ieder zulk apparaat een een mesh netwerk te bouwen waarbij het andere toestellen die bereikbaar zijn onthoudt om naartoe te routen. Beetje zoals het OLPC het met IPv4 het eens heeft geprobeerd te doen. Ah, en degene die een kortere route naar het IPv4-internet aanbiedt krijgt dan wat voorrang voor de IPv6 traffiek die naar IPv4 moet getunneled worden. Het zijn maar ideetjes :-)

[Adm.Spock]

Centrale infrastructuur?

[Verwijderd]

Waarom? Bij een toenemende densiteit van toestellen met IP(v6) connectiviteit zie ik het nieuwe Internet als een gedecentarlizeerd ipv ene gecentralizeerd systeem. Een groot probleem zal zijn dat men toezicht op de communicatie wil. Maar, hoe willen ze het tegenhouden? In zo'n systeem kan een toezichthouder ook nodes opzetten om af te luisteren. Net zoals bij bv. Tor. En hoe is zo'n gedecentralizeerd systeem van communicatie onveiliger als dat praatjes in de samenleving zijn? Laten we dat stukje software anders deels in userland bouwen en het gossipmongerd noemen. Neh :-)

Maar eigenlijk zie ik niet wat het voordeel van een centrale infrastructuur is. Behalve misschien dat een gedecentralizeerde infrastructuur voor deelnemers die veel hops van hun communicatiedoel af zitten een grotere latency zullen hebben dan bij een centrale infrastructuur.

[Yamotek]

Probleem met decentralisatie is dat alles ook op vele apparaten aanwezig moet zijn. Wat als gedeelte x maar op een y aantal apparaten aanwezig is en de helft offline gaat?

Bij een hoge traffic is dit niet ideaal. Daarbij komt ook, hoe weet iedere 'router' wie welk stukje heeft? Dan moet er toch iets centraal blijven waar de aanvragen naar toe gaan (DNS?) of er ontstaat een hele hoge latency omdat er veel aanvragen overal naar toe worden gestuurd om een bepaald pakketje op te halen.

Het idee is leuk, maar nog veel beter is een overheid die te vertrouwen is en die onze informatie niet met een sleepnet-methode binnen harkt.

[Verwijderd]

Het gaat me niet enkel over de overheid niet te vertrouwen (ofzo), maar wel over hoe leuk het zou zijn dit experiment te proberen bouwen :-). Ik denk wel dat het een aantal privacy-problemen zou oplossen. Maar, eigenlijk is het vooral gewoon een toffe engineering oplossing voor allerlei zaken (de laatste maanden is die Snowden en NSA toestand nogal pervasive. Dus ik snap wel dat 'privacy' wat aandacht krijgt. Maar eigenlijk moeten tweakers-en/of-ingenieurs zich vooral met het verbeteren van de samenleving en haar noden bezig houden)

[Wim-Bart]

Decentralisatie van een netwerk protocol via mesh is anders dan een decentraal data sharing model. Bij een data sharing model zoals P2P bijvoorbeeld zijn resources op meerdere plaatsen aanwezig en zal bij wegvallen van een host de data ergens anders vandaan komen.

Een decentraal mesh netwerk (anders dan een mesh netwerk zoals nu ook gebruikt wordt) is andere koek. Daarbij wil je snelle redundante verbindingen en niet afhankelijk zijn van buurman drie straten verder die je game kill't omdat ie zo nodig om 23:00 zijn router wil uitzetten vanwege de groen gedachte.

Goed beschouwd is het Internet zoals we nu kennen 1 groot mesh netwerk met meerdere paden (bepaalde verbindingen daargelaten). Zo een netwerk kost geld en ik zie niet dat Pietje uit Katwijk aan Zee even een kabeltje legt naar John in Engeland.

Een decentraal mesh netwerk model is gewoon onbetrouwbaar en dus onbruikbaar. En voor een betrouwbaar netwerk moet geld worden neergelegd en zitten er ook andere risico's aan.

Maar niemand zegt dat data uitwisseling niet kan volgens mesh zoals Tor bij IPv6.

[Verwijderd]

Ik geef je gelijk dat het mesh-netwerk dat ik in gedachten heb (vooral initieel) onbetrouwbaar zou zijn. Het zou dan ook (initeel) geen vervanger voor het huidige Internet zijn.

[Verwijderd]

Zo'n mesh heeft twee grote problemen:

1) Niemand verdient er geld aan, dus geen commercieel bedrijf gaat zoiets opzetten. Het moet dan van enthousiastelingen of een non-profit komen en die hebben simpelweg niet het geld om zoiets op grote schaal te doen. Daarnaast zal een iedere dus het probeert actief tegengewerkt worden door bestaande partijen.

2) De overheid zal het tegenwerken en misschien zelfs wel gewoon blokkeren. Zo'n mesh maakt het praktisch onmogelijk om mensen af te luisteren of content te censureren.

[TheekAzzaBreek]

Ad 1): Dat kan wel eens meevallen.
Mesh netwerken bieden kansen voor apparatenbouwers. Goedkopere en (soms) stabielere/veiliger verbindingen zijn een stevig verkoopargument. Dat de netwerkjongens er niet blij mee zijn hoeft niet per se een probleem te zijn.

[Verwijderd]

Ik ben het helemaal eens met 1. Met 2 niet: Net zoals bij Tor (wat ook bij een gecentralizeerd systeem zal blijven bestaan) is een gedecentralizeerd systeem afluisterbaar gegeven je voldoende endpoints beheert.

Bv. wil je weten wie er kwalijke informatie nodig heeft, ga je vlak voor de bron van die kwalijke informatie alles afluisteren. Dat is zoveel apparaten om af te luisteren als dat de dichtheid van apparaten keer de straal van de huidige technologie rondom de bron van de informatie is. Piece of cake voor een overheid. Alle andere minder-populaire informatiebronnen zijn net zo gevaarlijk als dat praatjes zijn. Wil men misschien het spreken met elkaar ook gaan verbieden en afluisteren? Mensen chippen met micro's?

Eigenlijk is een gedecentralizeerd systeem waarschijnlijk beter voor de veiligheidsdiensten dan een gecentralizeerd systeem met sterke encryptie en tientalle Tor-achtige netwerken. Omdat kwalijke informatie uiteindelijk een bron heeft. En die bron is erg eenvoudig traceerbaar. Al was het maar door latency te gebruiken om al maar meer in de buurt te komen van de bron.

[TheekAzzaBreek]

Het voordeel van gecentraliseerde infrastructuur is dat je een gegarandeerde kwaliteit kan bieden. Veel partijen, bij voorbeeld je eigen ISP, kunnen domweg niet zonder.

[Verwijderd]

Leg jij zelf de kabels neer naar andere routers?

[Verwijderd]

Wifi en andere wireless technologie, en kabels (met hogere routing prioriteit). Die chipjes en antennes worden al maar kleiner en goedkoper en komen in al maar meer toestellen voor. Ik vrees wel dat radio antennes aan bepaalde fysische beperkingen zitten wat betreft ze kleiner maken (= ik ben hier geen expert in) ...

[Verwijderd]

WiFi om een wereldwijd netwerk mee te bouwen ? Wireless ?

WiFi is een access-technolgie. Die moet je alleen gebruiken aan de buitenste buitenkant van het Internet. En zelfs dan, imho, alleen voor handheld devices. Phones, tablets, en misschien ook laptops. Bovendien komt WiFi maar enkele tientallen meters ver. En het gaat amper door muren en objecten heen. In mijn ogen speelgoed-technologie. Heel handig in huis, en misschien op kantoor voor je tablet. En dan zelfs alleen als het bedrijf om de 50 meter een access-point ophangt.

Er zijn te veel haken en ogen om WiFi serieus voor iets anders te gebruiken. De Ether heeft maar een beperkt aantal frequenties. Kabels kun je net zo veel leggen als je zelf wilt.

Dit jaar zijn er verschillende serieuze pilots om 400 Gbps over een paar glasvezel-aders te pompen. En dat is over een wave-length. Als je op die snelheid DWDM zou doen (verschillende signalen in verschillende kleuren door een paar glasvezel-aders), dan kun je 17.6 Terabits/sec doen. Zie hier voor meer info.

Dat zijn de snelheden waarmee moderne transmissie technieken werken. En jij wilt dat allemaal vervangen door WiFi die <100Mbps over 50 meter kan doen ?

[Reactie gewijzigd door Verwijderd op 26 juli 2024 22:34]

[Verwijderd]

Wifi is maar één van de opties. En @Wim-Bart: een betrouwbaar netwerk is geen doel. Wel het plezier van zoiets te bouwen.

[Wim-Bart]

En toen zette je buurman zijn router uit. En pof, server disconnect in BO.

[Verwijderd]

Daarom dat nodes in zo'n meshnetwerk constant aan error-correctie en het opnieuw opbouwen van routering moeten bezig zijn. M.a.w. zou de software, op de nodes, die dit doet, veel meer gefocust moeten zijn daarop dan op er van uit te gaan dat er wel een connectie is.

De wel-connectie use-case zal m.a.w. de uitzondering zijn die moet bereikt worden.

Dit is gewoon een ander uitgangspunt dan de huidige CISCO routers hun software hun uitgangspunt is. Maar wat betreft engineering lijkt het me wel haalbaar om zulke nodes te ontwikkelen. Ze zouden als kakkerlakken niet uit te roeien zijn. Gewoon omdat het geheel van nodes massaal constant kei hard bezig is zichzelf te corrigeren.

[bantoo]

Gigantisch inefficiënt. De hele reden waarom al die ISPs samen de kern van het internet vormen is het feit dat er zo genakkelijk gerouteerd kan worden. De gehele core negeren en allemaal tunneltjes er over heen leggen(ipv4 tunneltjes) heeft geen enkele toegevoegde waarde.

[Verwijderd]

De meeste traffiek zou lokaal blijven. Bv. als de lantaarnpalen IPv6 routers worden en ik wil communiceren met de auto voor me (niet als bestuurders maar mss. wel de machines) dan tracht mijn wagen connectie te maken met de dichtsbijzijnde lantaarnpaal en die lantaarnpaal met de volgende, en zo verder, tot het de wagen voor me bereikt. Die communicatie heeft minder latency dan auto->3g->ISP->3g->auto. De routering kan relatief snel opgezet worden tussen toestellen gegeven dat de implementatie goed is. Ik ga wat kort door de bocht (in bochten rijden zal bv. letterlijk de auto vaak onbereikbaar maken voor de vorige IPv6 lantaarnpaal, dus heel wat constante correctie enzo nodig). Maar het kan volgens mij net zo efficient en vaak efficienter als een gecentralizeerd systeem van ISPs.

[Wim-Bart]

IP adressen zijn al min of meer geografisch bepaald per provider. Wanneer jouw auto en fiets en pc en telefoon in het zelfde subnet zitten dan zal de data ook rechtstreeks gaan. Zeker wanneer je een /48 subnet hebt.

Daarnaast zou ik niet die persoon willen zijn die opeens een half wijk over mijn verbinding krijg omdat ik toevallig aan de rand woon en mijn buren hem uit zetten.

Een netwerk zoals jij beschrijft bestaat al, alleen loopt alles buiten jouw subnet over "centrale" high speed, betrouwbare verbindingen.

[Verwijderd]

IP adressen zijn al min of meer geografisch bepaald per provider.

Onzin.
Adressen zouden de topologie van het netwerk moeten volgen. Niet de topologie van landsgrenzen. En zelfs dat is niet het geval. Adressen zijn in het verleden vrij random uitgedeeld. Pas later zijn er registries gekomen die per continent adressen uitdelen. Bij IPv6 zijn ze iets beter begonnen. Maar daar zal het ook snel een radjetoe worden (net woord: entropie).

Providers zijn internationaal. Het Internet is internationaal. Netwerken van ISP overspannen meerdere landen. Een land heeft meerdere ISPs. Er is geen enkele garantie dat de 10 ip-adressen van 10 mensen bij jou in de straat ook maar iets met elkaar te maken hebben. Het is allemaal een stuk ingewikkelder, een stuk meer random, en een stuk minder gestructureerd dan je zou denken.

Thank god for BGP.
Dankzij BGP kunnen we probleemloos leven met 500 duizend routes op het globale Internet !

[Wim-Bart]

Wanneer je ziet hoe blokken uitgedeeld zijn is het allemaal geografisch bepaald. Niet dat dat het uitgangspunt was, maar zo was het nu eenmaal.

sterker nog, als voormalig eigenaar van een Engels bedrijf met een vestiging hier in NL wilde ik een IP reeks welke zou resolven naar Engeland. Helaas niet mogelijk omdat ik gewoon een KPN blok kreeg met NL locatie.

De IPv4 reeks is nu eenmaal opgedeeld in blokken bestaande uit subnetten. Per continent zijn er blokken uitgedeeld en per land of groep landen zijn hier weer blokken uitgedeeld uit die blokken. Hierdoor zijn de routeringstabellen zelfs veel kleiner dan je je kan voorstellen op onze verbindingen naar andere delen van de wereld.

[Verwijderd]

In de jaren tachtig, en in de eerste helft van de jaren negentig was de allocatie nog niet per continent. Dan hebben we het over de eerste 10-20k prefixes, die random geallocaard zijn. Bovendien, internationals hebben eigen prefixes, en die verdelen ze gewoon over vestigingen in meerdere landen. Internationale ISPs (niet de KPN dus) delen ook gewoon hun ip-adressen uit waar ze het het hardst nodig hebben.

Hierdoor zijn de routeringstabellen zelfs veel kleiner dan je je kan voorstellen op onze verbindingen naar andere delen van de wereld.

Wishful thinking.
CIDR is pas van 1994. En zelfs CIDR kon maar eventjes de groei van de default-free zone tegenhouden. "Andere delen van de wereld" ? Routing gebeurd niet op basis van welk land het heen moet. Het gebeurd 100% op basis van naar welk netwerk (welke ISP) het toe moet. Geografie en topologie hebben er helemaal niks mee te maken.

We hebben nu zo'n 550k prefixes in het net. Hoe efficient is dat ? Volgens jou zou dat heel efficient moeten zijn, want we adverteren maar een paar summaries naar het buitenland. Toch ?

2^32 ip addressen = 4 miljard.
2^24 /24 prefixes (langste prefix toegestaan in de praktijk in BGP) dat zijn 2^24 = 16 miljoen prefixes.
Haal daar class D en E vanaf. Dat zijn er zo'n 2 miljoen.
Laten we hopen dat de oude class A en B prefixes niet in stukken zijn geknipt.
Houden we over: 126 oude klasse A netwerken, 16k oude klasse B netwerken, en 2,097,152 oude klasse C netwerken.

Als we geen CIDR hadden gehad, dan hadden we dus maximaal 2104k prefixes in de global bgp table gehad. Maar we hebben er nu geen 2.1 miljoen, we hebben er 550k. Dat betekent dat al die fantastisch summarization van jou, omdat volgens jou alle netwerken zo mooi zijn uitgedeeld, slecht het effect hebben dat gemiddeld minder dan 4 gebruikte prefixes worden gesummarized in 1 geadverteerde prefix.

Niet bepaald optimaal dus.
En het word niet beter. Ook niet met IPv6.

Geloof je nu dat addressen niet zo netjes zijn uitgedeeld ? En dat addressen niks zeggen over topografie ?

[Reactie gewijzigd door Verwijderd op 26 juli 2024 22:34]

[TheKmork]

Internationale ISPs (niet de KPN dus)

Slecht voorbeeld, KPN is ook een internationale ISP. Het internationale netwerk heeft eigen subnetten, een apart AS tov het nationale netwerk, en weliswaar geen eindgebruikers aangesloten (het is meer een backbone netwerk + zakelijk VPN), maar om nou te zeggen dat ze geen internationale ISP zijn is incorrect
Dit doet verder niets af aan je uitleg, wilde alleen deze misvatting even de wereld uit helpen.

[Reactie gewijzigd door TheKmork op 26 juli 2024 22:34]

[FreshMaker]

En waar zou de database met route's dan opgslagen moeten worden ?

Jouw voorbeeld, elke 50m staat er een lantarenpaal, met 120km/u passeer je heel wat palen, op niet alleen jouw auto moeten oppikken, maar ook voorgangers, en aankomende achterliggers
Hoelang moet jouw tracker actief blijven, want misschien haalt auto 7 wel met hoge snelheid in, en passeer je elkaar tegen de tijd dat je op paal 16 zit pas.

Nee, point to point via een dataverbinding en elkaar daar 'treffen' is dan toch wat handiger lijkt mij

[Verwijderd]

In RAM geheugen. Als dat vol is smijt je met een LRU de slechtere peers eruit.

[jerkitout]

https://www.reddit.com/r/darknetplan

Er zijn verschillende pogings al gedaan of in planning, maar het is een logistiek nachtmerrie.

[Toettoetdaan]

NAT dus, daar willen we juist van af

[Verwijderd]

NAT op IPV6? Waarom? Nee. Dat zou niet de bedoeling zijn van een IPv6 mesh-netwerk.

[Verwijderd]

Om eerlijk te zijn blijf ik liever op IPv4 hangen totdat een bepaalde site (die het woord unblock in zijn adres heet) over is op IPv6.
Het is de enige site die me echt problemen geeft, maar mijn tv plezier wil ik niet missen. Ik liep daar al tegenaan toen ik via XS4ALL over was naar IPv6, het was een van de redenen om over te stappen naar Ziggo. (De veel hogere snelheid een andere.)

[bantoo]

Hoezo? Je hebt gewoon nog steeds een IPv4 adres, waarom zou je overstappen om deze niet bestaande reden?

[Verwijderd]

DNS lookup. Ik kon met geen (mij bekende) mogelijkheid bij het IPv4 adres van de site, niet van mij, komen. De IPv6 tabel nam het voortouw.
Geen mogelijkheid om het in mijn router te veranderen. Ik ben geen netwerkspecialist, en had daarnaast de keuze om van een effectief 15/1 mbit lijn naar 120/12 te gaan voor een lagere prijs. Eenvoudige keuze dus.

[.oisyn]

Heb je het over unblock-us.com? Daar krijg ik echt geen AAAA records van hoor als ik een DNS query doe.

Name: d2z2eomnanw2yj.cloudfront.net
Addresses: 54.230.184.160
54.230.187.147
54.192.186.244
54.230.184.126
54.192.187.97
54.192.187.67
54.192.186.133
54.192.187.12
Aliases: www.unblock-us.com

Welke van de twee prioriteit krijgt is overigens een client-ding, dus dat ga je niet oplossen in je router (al zou je natuurlijk het IPv6 adres kunnen blokkeren in je DNS)

[Maurits van Baerle]

Dat is wel erg overdreven. Mocht het een specifiek probleem zijn met één website zou je dat prima in een hostfile kunnen blokkeren.

Mocht je een router hebben die problemen geeft kun het natuurljk sowieso gewoon in je modem of op je computer uitzetten.

Geen reden om van ISP te wisselen in ieder geval.

[matty___]

Wat een gedoe. Ben overgestapt naar Onsbrabantnet heb gewoon zonder gezeik een ipv4 en native ipv6 via 6rd.

[Verwijderd]

https://tools.ietf.org/html/rfc5569

Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.

De RFC van 6rd zegt dat IPv6 traffic in IPv4 pakketjes ge-encapsuleerd wordt. Dat is toch duidelijk een tunnel. En tunnels zijn precies het tegenovergestelde van "native". Jij hebt "native ipv6" over tunnels ?

Of mis ik hier iets ?

[matty___]

dan had ik het fout. Dacht dat 6rd een manier was om IPv6 te krijgen zonder tunnels etc

[Verwijderd]

No problem. Ik ben zelf geen IPv6-expert. (Hoewel ik hier op Tweakers welzeker de "Karma King of IPv6" ben. In het land der blinden ....
Ik vroeg me gewoon af of ik iets niet begrepen had.

Veel plezier met je IPv6 !

[WhizzKid-Eddy]

Toch leuk je eigen ego opkrikken...

[Verwijderd]

Inderdaad grappig. Ik heb er niet om gevraagd, die labels. Als ik een optie zou hebben om ze niet te laten zien, zou ik het direct doen.

Het vreemde is, ik ben zelf helemaal geen fan van IPv6. In tegendeel zelfs. Vorige week heb ik toevallige alle RFCs over IPv6 geteld. Dat waren er toen 437. 437 extra RFCs met allemaal toegevoegde complexiteit. Zonder dat we er eigenlijk veel voordeel van hebben. (Let wel: het voordeel is voor de mensen die nog geen IPv4 adres hebben, en toch willen. Degene die al wel een IPv4 adres hebben (zoals wij allemaal), hebben voorlopig helemaal nul niks zappa noppes voordeel bij IPv6).

Tijd voor een T-shirt met een slogan:

437 RFCs of added complexity, and all I got were these lousy 96 extra bits".

[WhizzKid-Eddy]

Krijgen we straks nu ook allemaal van die omreken machientjes zoals je destijds had bij de invoering van de Euro om je IPV4 adres om te rekenen naar een IPV6 adres?

[Hipska]

Nee, ze staan los van elkaar.

[Yggdrasil]

Kreeg je dat vanzelf?

Ik heb sinds enkele jaren IPv6 via 6rd bij ON.nl (voormalig OnsNetEindhoven), maar heb daar wel expliciet om moeten vragen. Het werkt overigens uitstekend en inschakelen was een fluitje van een cent op mijn Asus RT-AC66U.

ON vermeldt nergens op hun site dat ze IPv6 ondersteunen, wat me verbaasd. Misschien zien ze het nog als experimenteel. Lijkt me toch een pluspunt voor potentiële klanten.

[matty___]

Staat gewoon op hun website met de gegevens die je moet invullen. Topic in got heeft dan nog geholpen bij de openwrt config
edit: https://www.onsbrabantnet.nl/ipv6/

[Reactie gewijzigd door matty___ op 26 juli 2024 22:34]

[Edgarz]

Niets aan de hand, met een tunneltje werkt het ook. En blijkbaar zijn de IP adressen nog ruim voorhanden. Beter een goede en iets vertraagde implementatie dan haast en broddelwerk (alhoewel het een het andere niet garandeerde ).

[velenski]

nou nee die zijn niet voldoende voorhanden.
ip adressen zijn op hun max nu en geloof zelfs dat er minder dan 100.000 adressen beschikbaar zijn in nederland.
wij als hosting kunnen ze al geeneens meer krijgen op eigen ranges en moeten huren van anderen. (raar maar waar)

en was het KPN niet die vorig jaar al aangaf dat de adressen bijna op waren bij hun?

Wij spelen nu zelfs met 192.xx rommel

[RobbyTown]

192.xx gaat dat geen ellende geven met intern verkeer?

[Soldaatje]

Zolang die xx geen 168 is komt het wel goed.
https://en.wikipedia.org/wiki/Private_network

[velenski]

correct

[velenski]

Wat @Soldaatje zegt

geen 168 erin gooien

is veel routing en andere problemen zoals licenties van Directadmin en andere control panels die niet geinstalleerd mogen worden op interne ip's

lekker als je klant hebt die 20 ip's erbij wilt hebben maar DA staat dit niet toe
cpanel werkt ookal niet zo lekker met internals

[Edgarz]

Genoeg voor Ziggo in ieder geval, daar gaat het artikel immers over. Over het tekort van een ander zal Ziggo zich weinig zorgen hoeven te maken.

[velenski]

vanmorgen nog in Leeuwarden op UPC CC (nu ziggo) geweest en over gehad n.a.v. dit artikel gister, en nee dus.
Op dit moment hebben ze in stock, +/- 16000 IPv4 adressen.

Dat is bar weinig, theoretisch gezien zouden ze maar 16000 nieuwe klanten erbij kunnen hebben.
Hoop niet dat ze een enorme groei gaan doormaken dit jaar

[Tomaat]

Kakkie Ik was juist heel blij met het bericht dat Ziggo "nu echt" was begonnen met de uitrol van IPv6. Uiteraard heb ik het niet perse nodig maar ik vind het wel mega interessant.

[henk717]

Als je het mega interresant vindt kun je natuurlijk al aan de slag.
Ik heb zelf al een jaar of twee IPv6 bij ziggo door gebruik te maken van TunnelBroker.net , het is niet de meest mooie oplossing maar wel effectief.

[FreshMaker]

imo zolang je nog niet native ipv6 intern en extern draait ( met de subnets ) is het inzetten van ipv6 gewoon een stap te veel.
Ik zou graag willen dat KPN ipv6 aan ging bieden inclusief de subnets, zodat ik mijn netwerk gewoon kan opzetten.

Met lapmiddelen als tunnelbroker. sixnet en anderen blijf je maar modderen in het diepe omdat het op elk moment kan wijzigen.

[Zydronium]

KPN glasvezel deeld gewoon een /48 IPv6 range uit...

[Maurits van Baerle]

Klopt, en in een /48 kun je als eindbruiker dus ruim 65000 subnetten aanmaken.

[FreshMaker]

Moet je wel in de gelukkige staat zijn om überhaupt glas te kunnen afnemen, ik krijg niet meer dan 50/5 xdsl.
afgelopen 3 weken zelfs 55/10 maar helaas gooide een stormpje dit weekend de wijkcentrale plat, en na 45 minuten zaten we weer online op het vertrouwde 50/5

[RobinF]

Dit is niet helemaal waar. In 2015 wordt het netwerk (KPN kant) klaar gemaakt voor ipv6. Dan kunnen in feite alle glas en VDSL klanten ipv6 ontvangen. ADSL klanten volgen iets later.

[Audiodude]

Hmm. Het is dat de kpn router geen ipv6 ondersteund maar ik moest afgelopen maand ipv6 blokkeren omdat ik van kpn automatisch een ipv6 dns kreeg toegewezen. Ik heb mijn eigen apparatuur aan de glasvezel hangen. Het lijkt erop dat kpn intern wel ipv6 heeft draaien.

Geeft hoop voor de toekomst.

[bobsquad]

Dat kan kloppen de enige router die bij KPN geen IPv6 ondersteund is de Experiabox V8 de overige Experiaboxen ondersteunen dit wel. Bij KPN wordt dit ook in batches gedaan om IPv6 te activeren. En mensen je hoeft je V8 Experiabox niet om te wisselen voor een nieuwe. Gezien deze binnenkort een firmware update krijgt waardoor de V8 ook IPv6 ondersteund.

[Wim-Bart]

Volgens mij is KPN al geheel IPv6 op de backbone en draaien ze IPv4 gewoon in tunnels over IPv6 heen.

[Bacchus]

Met lapmiddelen als tunnelbroker. sixnet en anderen blijf je maar modderen in het diepe omdat het op elk moment kan wijzigen.

Hoe bedoel je "op elk moment wijzigen"? Ik heb al een jaar of twaalf dezelfde IPv6-range bij SixXS. In die tijd heb ik op twee verschillende woonadressen vier verschillende internetproviders gehad en waarschijnlijk tientallen verschillende IPv4-adressen. Daarbij bood slechts een van de providers mij ooit de optie om native meerdere systemen aan te sluiten op statische adressen.

[Verwijderd]

Ik heb er totaal geen verstand van maar als ik de link lees dan hou ik het liever nog ff bij ipv4

https://torrentfreak.com/...y-ipv6-peer-flood-150619/

[Verwijderd]

Die aanval gebruikte gespoofte adressen, dat kan met IPv4 net zo goed.

[Verwijderd]

Het artikel heeft het over "non-routable".

Update: The IPv6 addresses which are used appear to be fictional. They haven’t been allocated yet and are non-routable.

Ik kan het me niet voorstellen. Als een adres non-routable is, dan kan de attack nooit zijn SYN+ACK TCP pakketje terug krijgen. En dus nooit de laatste ACK sturen om de TCP-verbinding officieel op te zetten. De Torrent-client ziet dan niet eens dat er geprobeerd werd een verbinding te maken.

De verbinding blijft half-open. Dat kan een probleem zijn. Vroeger (20 jaar geleden !) had je deze aanvallen ook met IPv4. SYN-flooding heette dat. Maar kernels zijn daar tegen bewapend. Die gaan half-open verbindingen er sneller uit gooien als ze een SYN-flood vermoeden.

Vreemd dat deze oude aanval opeens opnieuw wordt gebruikt. De bewoording van het artikel doet vermoeden dat het om iets anders gaat. "Request queue" lijkt iets in de Torrent-client te zijn.

[WhizzKid-Eddy]

Ik denk dat je met IPV6 toch ietwat meer mogelijkheden hebt qua spoofing, er zijn immers veel meer adressen beschikbaar.

[MadEgg]

Het zal ook eens anders. Zeer jammer.

Maar ja, ik moet sowieso nog wel even wachten op native IPv6 geloof ik. In mijn gebied (Groningen) deelt Ziggo meen ik wel IPv6 uit, maar dan alleen als je je modem niet in bridge-modus hebt staan. En met de waardeloze router-functionaliteiten en beperkte configureerbaarheid is het natuurlijk geen optie om de router-functie weer in te schakelen. Dus ondanks dat ik eigen router erachter prima IPv6 ondersteund en ik al jaren gebruik maak van een IPv6-tunnel via Sixxs moet ik als enthousiaste early adopter toch langer wachten dan de "gemiddelde consument" die geen idee heeft wat IPv6 betekent...

Heb nog bar weinig goede redenen gehoord om dit niet gewoon aan te bieden op aanvraag. De netwerktechnologie is al enorm lang volwassen. Misschien moeten ze eens wat capabelere netwerkbeheerders inhuren bij Ziggo.

[joker1977]

Ik kan bevestigen dat Ziggo in Groningen deels IPv6 heeft uitgerold: Ik ben woonachtig in Groningen, heb Ziggo en IPv6. Ik draai inderdaad niet in bridge-modus,

Overigens heb ik geen reden om in bridge-mode te draaien, mag ik vragen waar je precies moeilijkheden mee ondervindt in de router-functionaliteit ? Ben wel nieuwsgierig

[MadEgg]

* Performance bij hoog aantal verbindingen (zoals torrents) is slecht, ik haal dan bij lange na de beschikbare bandbreedte niet meer, met mijn Asus RT-AC87U is dat geen probleem.
* Geen QoS
* geen VPN Server
* geen shell-toegang tot de router om custom services te draaien (geautomatiseerd periodiek wijzigen van WPA2 wachtwoord bijvoorbeeld), * geen extra SSID's
* geen dual band WiFi (2.4GHz en 5GHz)
* geen ondersteuning voor WiFi-AC
* en het allerergste: geen controle over de firmware. Ziggo heeft extern toegang tot mijn moden en duwt daar updates in als zij dat nodig vinden. Die controle wil ik zelf hebben.

[henk717]

Klinkt redelijk, er zijn mogelijke problemen met de uitrol en uit voorzorg wordt er een stap terug gegaan in plaats van de klanten met de schade te laten zitten. Ik vind het zelf een erg nette oplossing en hoop dat mijn mede tweakers dit met mij eens zijn. Helaas verwacht ik veel Ziggo haat dat het zo lang moet duren, en dat is ook zo IPv6 had al lang klaar moeten zijn. Dat betekend niet dat ze dit gehaast door moeten voeren met alle gevolgen van dien.

Als ik alleen de titel las vroeg ik me af waarom nou weer, maar met de redenatie erbij vind ik het erg netjes opgelost.

[Maurits van Baerle]

Het lijkt er op dat er problemen zijn met sommige modems. Althans, zo te zien is het op twee van de drie modellen weer uitgezet. Dat moet eerst uitgezocht worden. Nu was IPv6 maar in vier gebieden actief en je wil eventuele problemen natuurlijk niet over het hele land uitbreiden.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 22:34]