/dev/null
- Overig
Netneutraliteit en IPv6
03-10-2021, 09:47 door Anoniem, 37 reacties
In een van de posts over het blokkeren van poort 25 bij een provider stond vandaag de vraag of dit netneutraliteit schendt.
Een interessante vraag. Na zelf eens wat te hebben gelezen over netneutraliteit vraag ik me af of providers die geen IPv6 aanbieden daar eigenlijk ook problemen mee veroorzaken.
Immers is niet het gehele internet meer bereikbaar op IPv4.
Hoe zit dat? Waar ligt de grens tussen wat van de wet nog mag?
Een interessante vraag. Na zelf eens wat te hebben gelezen over netneutraliteit vraag ik me af of providers die geen IPv6 aanbieden daar eigenlijk ook problemen mee veroorzaken.
Immers is niet het gehele internet meer bereikbaar op IPv4.
Hoe zit dat? Waar ligt de grens tussen wat van de wet nog mag?
Reacties (37)
Het niet aanbieden van IPv6 is een gebrek. Reden voor in ieder geval de power user om over te stappen. Het is geen (bewuste) schending van netneutraliteit, maar gewoon onkunde of onwil van de isp. Blijkbaar zit uitbreiding van hun ICT er niet in. Kost geld. Simpel.
Meeste ISP's kijken slechts naar de behoeften van het Marginaal: Als het maar functioneert en je kan facebooken.
Meeste ISP's kijken slechts naar de behoeften van het Marginaal: Als het maar functioneert en je kan facebooken.
Het is een keus om geen IPv6 te hebben. Het staat je vrij om een tunnel met HÉ op te zetten, het is derhalve een non-argument om naar net neutraliteit te wijzen. Geef eens voorbeelden van significante sites die niet via IPv4 te bereiken zouden zijn? Ook dat is een non-argument.
Door Anoniem: Geef eens voorbeelden van significante sites die niet via IPv4 te bereiken zouden zijn? Ook dat is een non-argument.
Wat zijn significante sites? Voor de een is dat https://ipv6.google.com/ en voor de ander is dat een niche-blog op een chinese webserver. Maar op zich maakt dat helemaal niet uit. Als ik de teksten over netneutraliteit lees ik "dat internetproviders alle gegevens op het internet gelijk behandelen en niet discrimineren naar gebruiker, inhoud, website, platform, toepassing, soort aangesloten apparatuur of communicatiemethode." (bron: wikipedia).
Als ik dus niet op die Chinese webserver kan komen omdat die alleen IPv6 heeft worden die gegevens toch niet gelijk behandeld?
(note: Chinese webserver is niet random gekozen, maar gebaseerd op https://tweakers.net/nieuws/184872/china-wil-tegen-2030-volledig-zijn-overgestapt-op-ipv6.html).
Door Anoniem: Nee, het is backward compatible.
De reden dat IPv6 zo moeilijk van de grond komt is nou juist dat het NIET backward compatible is!Als het dat wel was dan was allang de hele ISP wereld over en draaiden er alleen nog wat interne bedrijfsnetwerken
op IPv4.
Maar helaas is bij het ontwerp de onvergeefbare beoordelingsfout gemaakt om het niet backward compatible te maken...
Overigens is de reden dat ISP's niet staan te trappelen om IPv6 uit te rollen al vaak genoemd hier: als je al IPv4 hebt
en je hebt genoeg adressen (wat bij Nederlandse ISP's meestal wel het geval is, wellicht met uitzondering van nieuwkomers
zoals Freedom) dan is het invoeren van IPv6 iets wat alleen "technisch leuk" is, maar je gemiddelde klant gaat daar
helemaal geen enkel voordeel van hebben en niks van merken.
Echter er is wel altijd het risico dat er tijdens het invoeringstraject dingen fout gaan, of dat klanten geconfronteerd worden
met situaties die eigenlijk al fout waren maar daar hadden ze nog geen last van. Gevolg: als je IPv6 invoert zijn er
klanten waarvoor het eerst werkte en nu niet meer, en er zijn geen of vrijwel geen klanten die blij zijn met de verbetering.
Plus dat je wellicht nog nieuwe apparatuur moet gaan sturen naar heel oude klanten die nog spullen hebben die niet
met IPv6 kunnen omgaan.
Netto resultaat van een IPv6 invoeringstraject is dus altijd negatief: het kost geld en het geeft mogelijk problemen.
Dan is het verleidelijk om het maar weer uit te stellen.
03-10-2021, 20:19 door
Briolet
Door Anoniem: Maar helaas is bij het ontwerp de onvergeefbare beoordelingsfout gemaakt om het niet backward compatible te maken...
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
In landen waar al een redelijke infrastructuur was, zijn er nog genoeg IPv4 adressen. Bij landen met een infrastructuur in opbouw is er wel een behoorlijk tekort en zijn er veel IPv6 only verbindingen. Maar ik neem aan dat ook de belangrijke websites in die landen een duur IP4 adres kopen om ook zo bereikbaar te zijn. Dit wederom stelt in de rest van de wereld de noodzaal uit om overal IPv6 te implementeren.
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Door Briolet:
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
In landen waar al een redelijke infrastructuur was, zijn er nog genoeg IPv4 adressen. Bij landen met een infrastructuur in opbouw is er wel een behoorlijk tekort en zijn er veel IPv6 only verbindingen. Maar ik neem aan dat ook de belangrijke websites in die landen een duur IP4 adres kopen om ook zo bereikbaar te zijn. Dit wederom stelt in de rest van de wereld de noodzaal uit om overal IPv6 te implementeren.
Door Anoniem: Maar helaas is bij het ontwerp de onvergeefbare beoordelingsfout gemaakt om het niet backward compatible te maken...
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
In landen waar al een redelijke infrastructuur was, zijn er nog genoeg IPv4 adressen. Bij landen met een infrastructuur in opbouw is er wel een behoorlijk tekort en zijn er veel IPv6 only verbindingen. Maar ik neem aan dat ook de belangrijke websites in die landen een duur IP4 adres kopen om ook zo bereikbaar te zijn. Dit wederom stelt in de rest van de wereld de noodzaal uit om overal IPv6 te implementeren.
Adressen zijn niet land-gebaseerd, maar "wie er vroeg bij was" gebaseerd. Dat komt natuurlijk deels overeen met landen waar de infrastructuur (telco, isp, industrie) in de jaren 80/90/00 al met Internet bezig was).
Freedom Internet zit in Nederland, maar heeft echt een uitdaging met IP adressen.
Adressen voor websites zijn er verhoudingsgewijs weinig, dat is wel oplosbaar. Maar genoeg voor clients is wel een probleem.
India heeft een enorme sprong gemaakt in IPv6 gebruik toen een startup mobile operator (Reliance Jio) naar IPv6 only ging (met een xlat voor V4 connectivity) .
Door Briolet:
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Het ene moment wordt Facebook volledig afgebrand en nu zouden ze een voortrekkersrol moeten vervullen?Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
03-10-2021, 22:44 door
Japie Apie
Door Briolet:
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
In landen waar al een redelijke infrastructuur was, zijn er nog genoeg IPv4 adressen. Bij landen met een infrastructuur in opbouw is er wel een behoorlijk tekort en zijn er veel IPv6 only verbindingen. Maar ik neem aan dat ook de belangrijke websites in die landen een duur IP4 adres kopen om ook zo bereikbaar te zijn. Dit wederom stelt in de rest van de wereld de noodzaal uit om overal IPv6 te implementeren.
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Eerst Facebook totaal afkraken en nu moeten ze een voorbeeld zijn?Door Anoniem: Maar helaas is bij het ontwerp de onvergeefbare beoordelingsfout gemaakt om het niet backward compatible te maken...
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
In landen waar al een redelijke infrastructuur was, zijn er nog genoeg IPv4 adressen. Bij landen met een infrastructuur in opbouw is er wel een behoorlijk tekort en zijn er veel IPv6 only verbindingen. Maar ik neem aan dat ook de belangrijke websites in die landen een duur IP4 adres kopen om ook zo bereikbaar te zijn. Dit wederom stelt in de rest van de wereld de noodzaal uit om overal IPv6 te implementeren.
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Door Anoniem: Het ene moment wordt Facebook volledig afgebrand en nu zouden ze een voortrekkersrol moeten vervullen?
Door Japie Apie: Eerst Facebook totaal afkraken en nu moeten ze een voorbeeld zijn?
Misschien bedoelt Briolet niet dat hij ze als voorbeeld of voortrekker ziet maar constateert hij simpelweg dat het een enorme impact zou hebben als een partij die miljarden mensen bereikt met IPv4 zou stoppen.Het lijkt wel alsof jullie denken dat een bedrijf dat iets heel kwalijks doet onmogelijk in staat kan zijn om iets te doen dat goed uitpakt. Mensen, zo werkt de realiteit niet. Je zal altijd slechterikken aantreffen die toch ook wel eens iets goed doen en goeierikken die toch ook wel eens iets slechts doen. Als je denkt dat een slechterik alleen maar slechte dingen kan doen en dat een goeierik alleen maar goede dingen kan doen, dan moet je een hoop niet snappen van wat er in de wereld gebeurt.
04-10-2021, 10:48 door
Briolet
Door Anoniem:
Door Briolet:
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Het ene moment wordt Facebook volledig afgebrand en nu zouden ze een voortrekkersrol moeten vervullen?Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Blijkbaar snapte je de ironie van deze opmerking niet. (-:
Bovendien is het duidelijk dat Facebook dit nooit zou doen omdat het hun veel gebruikers zou kosten.
Door Briolet:
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
Door Anoniem: Maar helaas is bij het ontwerp de onvergeefbare beoordelingsfout gemaakt om het niet backward compatible te maken...
Om iets backwards compatibel te maken moet je ook weer een heleboel foute ontwerpen mee ondersteunen. Ze zullen gekozen hebben om het protocol grondig te vernieuwen zonder de ballast van het oude protocol.
Ja dat is duidelijk dat ze daarvoor gekozen hebben, maar dat is dus wel een onvergeefbare beoordelingsfout!
Net zoals er wel meer domme fouten gemaakt zijn zoals SLAAC ipv (of als voorkeur boven) DHCP.
Nu zitten we met een protocol "zonder ballast van het oude protocol" (niet waar overigens...) maar helaas wel een protocol
wat nooit helemaal het oude zal vervangen en wat na 20 jaar advocacy nog lang niet overal ingevoerd is.
Dat probleem was er niet geweest als het backward compatible was.
Vraag: Waarom hebben ze nooit een 64-bit protocol bedacht? 64-bit is MEER dan genoeg (incl. 16-bit poorten erbij)! Dus een 48-bit protocol met poorten (16-bit) erbij zou meer dan genoeg moeten zijn voor de gehele IOT onzin die er nog gaat volgen.
Door Briolet:
Blijkbaar snapte je de ironie van deze opmerking niet. (-:
Bovendien is het duidelijk dat Facebook dit nooit zou doen omdat het hun veel gebruikers zou kosten.
<Sarcasme aan>Fijn te weten, dat jij zo bekend bent met het beleid van Facebook. <Sarcasme uit>Door Anoniem:
Door Briolet:
Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Het ene moment wordt Facebook volledig afgebrand en nu zouden ze een voortrekkersrol moeten vervullen?Misschien zou het helpen de transitie te versnellen als Facebook zou aankondigen dat ze over 1 jaar alleen nog maar via IPv6 bereikbaar zijn.
Blijkbaar snapte je de ironie van deze opmerking niet. (-:
Bovendien is het duidelijk dat Facebook dit nooit zou doen omdat het hun veel gebruikers zou kosten.
HTTPS-Everywhere is ook nog niet overal op onze globe gerealiseerd.
Je maakt wel een zekere slag naar betere beveiliging. Maar zie met CSP.
Alle maatregelen - too little too late en velen snappen (nog) niet waarvoor het nodig is.
Het is als met website beveiliging. Te veel gelikt, maar niet veilig per se.
En onderschat de rol in deze niet van de niet technisch onderlegde knutselaars.
Als je niet eens kunt spellen, hoe kun je dan goed coderen? Rekendoven en leesblinden overal.
luntrus
Je maakt wel een zekere slag naar betere beveiliging. Maar zie met CSP.
Alle maatregelen - too little too late en velen snappen (nog) niet waarvoor het nodig is.
Het is als met website beveiliging. Te veel gelikt, maar niet veilig per se.
En onderschat de rol in deze niet van de niet technisch onderlegde knutselaars.
Als je niet eens kunt spellen, hoe kun je dan goed coderen? Rekendoven en leesblinden overal.
luntrus
Door Anoniem: Vraag: Waarom hebben ze nooit een 64-bit protocol bedacht? 64-bit is MEER dan genoeg (incl. 16-bit poorten erbij)! Dus een 48-bit protocol met poorten (16-bit) erbij zou meer dan genoeg moeten zijn voor de gehele IOT onzin die er nog gaat volgen.
De 128 bits worden verdeeld in 64 bits voor een subnetadres en 64 bits voor aansluitingen binnen een subnet. De 64 bits die jij voorstelt zijn precies wat gebruikt wordt om elke internetaansluiting een eigen subnet te geven, zodat elke aansluiting een 64-bit adresruimte voor het interne netwerk heeft. Daar passen dan weer de 48 bits van een ethernetadres in, zodat adressen toekennen op basis van de hardware een mogelijke strategie wordt.Door Anoniem: Vraag: Waarom hebben ze nooit een 64-bit protocol bedacht? 64-bit is MEER dan genoeg (incl. 16-bit poorten erbij)! Dus een 48-bit protocol met poorten (16-bit) erbij zou meer dan genoeg moeten zijn voor de gehele IOT onzin die er nog gaat volgen.
Nee, dat is niet genoeg omdat je subnetten toekent - liefst eenmalig - en geen individuele adressen.
Lees een hoop over het maken van een IP adresplan voor een organisatie - dan snap je waarom je fors meer adressen wilt dan exact genoeg voor het aantal devices.
Op moment dat de keus gemaakt werd voor 'blanko nieuw ontwerp' was de keus voor een veel groter adresveld heel terecht.
Door Anoniem: Vraag: Waarom hebben ze nooit een 64-bit protocol bedacht? 64-bit is MEER dan genoeg (incl. 16-bit poorten erbij)! Dus een 48-bit protocol met poorten (16-bit) erbij zou meer dan genoeg moeten zijn voor de gehele IOT onzin die er nog gaat volgen.
Ja dat heb ik me ook altijd afgevraagd. 64 bits was wel genoeg geweest. Maar men dacht toen nog "we kunnen alslokaal adres gewoon het MAC adres gebruiken" en dat was dan al 48 bits waarvoor men voor het gemak 64 bits pakte.
En dan moest er nog genoeg bij om iedereen een eigen netwerk te geven, door ervaring rijk geworden met IPv4 pakte
men daar ook 64 bits voor.
Later bleek pas hoe dom het was om het MAC adres als lokaal adres te gebruiken en moest daar weer wat op verzonnen
worden.
Afijn uit het hele ontwerp blijkt dat er meer genavelstaard is dan naar de werkelijke behoeften gekeken. En dat wreekt zich nu.
Zolang ipv6 mtu path discovery niet werkt op de helft van het internet zet ik het nog niet aan.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Door Anoniem: Zolang ipv6 mtu path discovery niet werkt op de helft van het internet zet ik het nog niet aan.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Onzin. In de VS is bijna de helft van het internet verkeer al IPv6. Denk je nu echt dat pMTU niet werkt als zo veel verkeer al IPv6 is? pMTU voor IPv6 werkt anders dan pMTU voor IPv4 (gelukkig). Ik draai al sinds 2001 met IPv6, en eigenlijk zonder problemen. Steeds meer sites en systemen ondersteunen het.
64 bits protocol als QR natuurlijk.
Zit je in lijn met hoe ze ons willen "managen" als the speople to be..
Iedereen voor. Even nog een beetje jennen, is het erdoor.
Vast wel,
#sockpuppet
Zit je in lijn met hoe ze ons willen "managen" als the speople to be..
Iedereen voor. Even nog een beetje jennen, is het erdoor.
Vast wel,
#sockpuppet
Door Anoniem: Zolang ipv6 mtu path discovery niet werkt op de helft van het internet zet ik het nog niet aan.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Vertel eens over je eigen ervaring ? Want ik denk dat je theoretisch neuzelt en graag interessant doet.
Kom maar op met 10 onbereikbare IPv6 sites wegens pMTU probleem .
De wereld bij de ISPs (50% van België, 30+ % in NL) is niet ingestort toen ze dat aanzetten - en IPv6 IS de eerste keuze van browsers. Reken maar dat een half hangende browser bij alle klanten opvalt in de helpdesk stats.
En nu kom jij beweren dat "de helft" van Pv6 internet niet werkt . Ik geloof er geen woord van.
Door Anoniem:
Vertel eens over je eigen ervaring ? Want ik denk dat je theoretisch neuzelt en graag interessant doet.
Kom maar op met 10 onbereikbare IPv6 sites wegens pMTU probleem .
De wereld bij de ISPs (50% van België, 30+ % in NL) is niet ingestort toen ze dat aanzetten - en IPv6 IS de eerste keuze van browsers. Reken maar dat een half hangende browser bij alle klanten opvalt in de helpdesk stats.
En nu kom jij beweren dat "de helft" van Pv6 internet niet werkt . Ik geloof er geen woord van.
Door Anoniem: Zolang ipv6 mtu path discovery niet werkt op de helft van het internet zet ik het nog niet aan.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Vertel eens over je eigen ervaring ? Want ik denk dat je theoretisch neuzelt en graag interessant doet.
Kom maar op met 10 onbereikbare IPv6 sites wegens pMTU probleem .
De wereld bij de ISPs (50% van België, 30+ % in NL) is niet ingestort toen ze dat aanzetten - en IPv6 IS de eerste keuze van browsers. Reken maar dat een half hangende browser bij alle klanten opvalt in de helpdesk stats.
En nu kom jij beweren dat "de helft" van Pv6 internet niet werkt . Ik geloof er geen woord van.
Het zijn meestal niet de servers die een lagere MTU hebben, het probleem zit meestal bij de clients die achter PPPoE
zitten of achter een tunnel. De mensen die gewoon een 1500 byte MTU hebben op hun verbinding die hebben
uiteraard geen centje pijn. Degenen die wat minder hebben die zijn afhankelijk van (de instellingen van) hun router.
Bijvoorbeeld de AVM Fritz routers adverteren als je een kleinere MTU hebt (bijv 1492) richting LAN ook een kleinere
MTU (ondanks dat op je LAN de MTU gewoon 1500 is) met als gevolg dat de clients TCP sessies opzetten met
een kleinere MSS. Dan werkt het allemaal top.
Net als dat ze bij IPv4 ook de MSS aanpassen in de packets, en daarmee het probleem onder de tafel vegen.
Heb je zo'n router dan heb je weinig problemen.
Heb je een andere router dan kun je wel degelijk problemen hebben!
Door Anoniem:
Het zijn meestal niet de servers die een lagere MTU hebben, het probleem zit meestal bij de clients die achter PPPoE
zitten of achter een tunnel. De mensen die gewoon een 1500 byte MTU hebben op hun verbinding die hebben
uiteraard geen centje pijn. Degenen die wat minder hebben die zijn afhankelijk van (de instellingen van) hun router.
Bijvoorbeeld de AVM Fritz routers adverteren als je een kleinere MTU hebt (bijv 1492) richting LAN ook een kleinere
MTU (ondanks dat op je LAN de MTU gewoon 1500 is) met als gevolg dat de clients TCP sessies opzetten met
een kleinere MSS. Dan werkt het allemaal top.
Net als dat ze bij IPv4 ook de MSS aanpassen in de packets, en daarmee het probleem onder de tafel vegen.
Heb je zo'n router dan heb je weinig problemen.
Heb je een andere router dan kun je wel degelijk problemen hebben!
Door Anoniem:
Vertel eens over je eigen ervaring ? Want ik denk dat je theoretisch neuzelt en graag interessant doet.
Kom maar op met 10 onbereikbare IPv6 sites wegens pMTU probleem .
De wereld bij de ISPs (50% van België, 30+ % in NL) is niet ingestort toen ze dat aanzetten - en IPv6 IS de eerste keuze van browsers. Reken maar dat een half hangende browser bij alle klanten opvalt in de helpdesk stats.
En nu kom jij beweren dat "de helft" van Pv6 internet niet werkt . Ik geloof er geen woord van.
Door Anoniem: Zolang ipv6 mtu path discovery niet werkt op de helft van het internet zet ik het nog niet aan.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Overijverige paranoia mensen blokkeren al het icmp verkeer vanaf hun routers met alle gevolgen van dien.
Vertel eens over je eigen ervaring ? Want ik denk dat je theoretisch neuzelt en graag interessant doet.
Kom maar op met 10 onbereikbare IPv6 sites wegens pMTU probleem .
De wereld bij de ISPs (50% van België, 30+ % in NL) is niet ingestort toen ze dat aanzetten - en IPv6 IS de eerste keuze van browsers. Reken maar dat een half hangende browser bij alle klanten opvalt in de helpdesk stats.
En nu kom jij beweren dat "de helft" van Pv6 internet niet werkt . Ik geloof er geen woord van.
Het zijn meestal niet de servers die een lagere MTU hebben, het probleem zit meestal bij de clients die achter PPPoE
zitten of achter een tunnel. De mensen die gewoon een 1500 byte MTU hebben op hun verbinding die hebben
uiteraard geen centje pijn. Degenen die wat minder hebben die zijn afhankelijk van (de instellingen van) hun router.
Bijvoorbeeld de AVM Fritz routers adverteren als je een kleinere MTU hebt (bijv 1492) richting LAN ook een kleinere
MTU (ondanks dat op je LAN de MTU gewoon 1500 is) met als gevolg dat de clients TCP sessies opzetten met
een kleinere MSS. Dan werkt het allemaal top.
Net als dat ze bij IPv4 ook de MSS aanpassen in de packets, en daarmee het probleem onder de tafel vegen.
Heb je zo'n router dan heb je weinig problemen.
Heb je een andere router dan kun je wel degelijk problemen hebben!
De vraag is niet _of_ je IPv6 stuk kunt maken , of dat er apparatuur denkbaar is waarbij het stuk is - natuurlijk kan dat, en is dergelijke apparatuur denkbaar - , de bewering van 14:48 is dat het nu nog onbruikbaar zou zijn wegens "op veel plaatsen stuk dus "hij zet niet aan" " .
Die 50% Belgen of 34% Nederlanders (of 62% Indiers) zijn voor 99% eindgebruikers die niks kunnen diagnosticeren, en niks aan of uit zetten maar voor wie het 'gewoon vanzelf' werkt met de standaard modems die hun ISPs hebben uitgerold.
Dat maakt 14:48's claim dat hij het niet aanzet wegens 'teveel is kapot' onzin.
Door Anoniem:
De vraag is niet _of_ je IPv6 stuk kunt maken , of dat er apparatuur denkbaar is waarbij het stuk is - natuurlijk kan dat, en is dergelijke apparatuur denkbaar - , de bewering van 14:48 is dat het nu nog onbruikbaar zou zijn wegens "op veel plaatsen stuk dus "hij zet niet aan" " .
Die 50% Belgen of 34% Nederlanders (of 62% Indiers) zijn voor 99% eindgebruikers die niks kunnen diagnosticeren, en niks aan of uit zetten maar voor wie het 'gewoon vanzelf' werkt met de standaard modems die hun ISPs hebben uitgerold.
Dat maakt 14:48's claim dat hij het niet aanzet wegens 'teveel is kapot' onzin.
De vraag is niet _of_ je IPv6 stuk kunt maken , of dat er apparatuur denkbaar is waarbij het stuk is - natuurlijk kan dat, en is dergelijke apparatuur denkbaar - , de bewering van 14:48 is dat het nu nog onbruikbaar zou zijn wegens "op veel plaatsen stuk dus "hij zet niet aan" " .
Die 50% Belgen of 34% Nederlanders (of 62% Indiers) zijn voor 99% eindgebruikers die niks kunnen diagnosticeren, en niks aan of uit zetten maar voor wie het 'gewoon vanzelf' werkt met de standaard modems die hun ISPs hebben uitgerold.
Dat maakt 14:48's claim dat hij het niet aanzet wegens 'teveel is kapot' onzin.
Omdat ik goed bekend ben met MTU problemen herken ik deze nogal eens als er mensen op forums komen met (voor hen)
totaal onverklaarbare problemen zoals "ik kan sommige sites wel en andere niet bereiken" maar die dan wel kunnen
pingen. Dit komt zowel op IPv4 als IPv6 voor maar op IPv4 is dit vaak beter geregeld in routers.
Het is zeker onzin om te stellen dat er "teveel kapot" is maar ik ben zeker blij dat ik bij mijn provider gewoon een 1500
byte MTU heb (PPPoE met RFC4638) want dat scheelt zeer zeker een hoop gezeik.
Op het werk heb ik eens lopen tobben met een verbinding die MTU 1492 had en waar achter de ISP router nog een
2e router zat die de geadverteerde MTU 1492 negeerde en naar de LAN zijde weer MTU 1500 adverteerde en ik kan
je verzekeren dat dit een hoop ellende geeft! Sommige sites doen het prima, andere NIET. En als je moet afgaan op
meldingen van gebruikers dan is er geen touw aan vast te knopen.
(dit probleem was er op IPv4 niet en je krijgt dan uiteraard dat sites die alleen IPv4 hebben perfect werken, sites die
ook IPv6 aanbieden normaal gesproken ook wel, maar degenen die ook nog eens ICMP(v6) blokkeren die gaan de
mist in. "we kunnen wel Teams gebruiken maar geen Zoom" krijg je dan te horen, bijvoorbeeld)
Door Anoniem:
Omdat ik goed bekend ben met MTU problemen herken ik deze nogal eens als er mensen op forums komen met (voor hen)
totaal onverklaarbare problemen zoals "ik kan sommige sites wel en andere niet bereiken" maar die dan wel kunnen
pingen. Dit komt zowel op IPv4 als IPv6 voor maar op IPv4 is dit vaak beter geregeld in routers.
Het is zeker onzin om te stellen dat er "teveel kapot" is maar ik ben zeker blij dat ik bij mijn provider gewoon een 1500
byte MTU heb (PPPoE met RFC4638) want dat scheelt zeer zeker een hoop gezeik.
Op het werk heb ik eens lopen tobben met een verbinding die MTU 1492 had en waar achter de ISP router nog een
2e router zat die de geadverteerde MTU 1492 negeerde en naar de LAN zijde weer MTU 1500 adverteerde en ik kan
je verzekeren dat dit een hoop ellende geeft! Sommige sites doen het prima, andere NIET. En als je moet afgaan op
meldingen van gebruikers dan is er geen touw aan vast te knopen.
Door Anoniem:
De vraag is niet _of_ je IPv6 stuk kunt maken , of dat er apparatuur denkbaar is waarbij het stuk is - natuurlijk kan dat, en is dergelijke apparatuur denkbaar - , de bewering van 14:48 is dat het nu nog onbruikbaar zou zijn wegens "op veel plaatsen stuk dus "hij zet niet aan" " .
Die 50% Belgen of 34% Nederlanders (of 62% Indiers) zijn voor 99% eindgebruikers die niks kunnen diagnosticeren, en niks aan of uit zetten maar voor wie het 'gewoon vanzelf' werkt met de standaard modems die hun ISPs hebben uitgerold.
Dat maakt 14:48's claim dat hij het niet aanzet wegens 'teveel is kapot' onzin.
De vraag is niet _of_ je IPv6 stuk kunt maken , of dat er apparatuur denkbaar is waarbij het stuk is - natuurlijk kan dat, en is dergelijke apparatuur denkbaar - , de bewering van 14:48 is dat het nu nog onbruikbaar zou zijn wegens "op veel plaatsen stuk dus "hij zet niet aan" " .
Die 50% Belgen of 34% Nederlanders (of 62% Indiers) zijn voor 99% eindgebruikers die niks kunnen diagnosticeren, en niks aan of uit zetten maar voor wie het 'gewoon vanzelf' werkt met de standaard modems die hun ISPs hebben uitgerold.
Dat maakt 14:48's claim dat hij het niet aanzet wegens 'teveel is kapot' onzin.
Omdat ik goed bekend ben met MTU problemen herken ik deze nogal eens als er mensen op forums komen met (voor hen)
totaal onverklaarbare problemen zoals "ik kan sommige sites wel en andere niet bereiken" maar die dan wel kunnen
pingen. Dit komt zowel op IPv4 als IPv6 voor maar op IPv4 is dit vaak beter geregeld in routers.
Het is zeker onzin om te stellen dat er "teveel kapot" is maar ik ben zeker blij dat ik bij mijn provider gewoon een 1500
byte MTU heb (PPPoE met RFC4638) want dat scheelt zeer zeker een hoop gezeik.
Op het werk heb ik eens lopen tobben met een verbinding die MTU 1492 had en waar achter de ISP router nog een
2e router zat die de geadverteerde MTU 1492 negeerde en naar de LAN zijde weer MTU 1500 adverteerde en ik kan
je verzekeren dat dit een hoop ellende geeft! Sommige sites doen het prima, andere NIET. En als je moet afgaan op
meldingen van gebruikers dan is er geen touw aan vast te knopen.
Been there, done that.
Inderdaad zijn MTU problemen in combinatie met het kapot zijn van detectie/rapportage mechanisme (icmp) aanleiding voor mysterie problemen, vooral omdat de standaard ping test (met 64 bytes) natuurlijk gewoon werkt.
Heb je een goed idee dat het best wel eens een MTU probleem zou kunnen zijn, dan is het constateren _of_ dat het geval is wel te doen - maar de hunch 'zou wel eens mtu + kapotte pMTUd kunnen zijn' moet je aan de hand van de sympomen krijgen.
En ga je in de verkeerde richting zoeken want "de frontpage van site abc doet het dus het netwerk is OK' dan ga je een heel eind de verkeerde richting op.
Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is. Klein genoeg om geen problemen met PPoE apparaten of andere meuk te hebben. Als je wilt kun je de MTU aanpassen en automatisch laten bepalen. Het is echte kolder om IPv4 MTU grootte te gebruiken om problemen met IPv6 te noemen. Je hebt geen idee waar je het over hebt.
Veel reacties, niet allemaal een antwoord op jouw vraag.
Ja, ik ben (al heel lang) van mening dat het niet aanbieden van IPv6 een inbreuk is op de netneutraliteit.
Wie de letter van de wet, of de netneutraliteitsverordening, heel precies leest, kan niet anders concluderen dan dat een internettoegansdienst vandaag de dag gezien moet worden als iets dat zowel IPv4 als IPv6 dient te ondersteunen.
ISP's die dit niet bijleveren, hinderen de toegang naar eindpunten die IPv6-only zijn en het is, naar mijn mening, niet aan de ISP om dat voor de klant te bepalen.
Ja, ik ben (al heel lang) van mening dat het niet aanbieden van IPv6 een inbreuk is op de netneutraliteit.
Wie de letter van de wet, of de netneutraliteitsverordening, heel precies leest, kan niet anders concluderen dan dat een internettoegansdienst vandaag de dag gezien moet worden als iets dat zowel IPv4 als IPv6 dient te ondersteunen.
ISP's die dit niet bijleveren, hinderen de toegang naar eindpunten die IPv6-only zijn en het is, naar mijn mening, niet aan de ISP om dat voor de klant te bepalen.
Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is. Klein genoeg om geen problemen met PPoE apparaten of andere meuk te hebben. Als je wilt kun je de MTU aanpassen en automatisch laten bepalen. Het is echte kolder om IPv4 MTU grootte te gebruiken om problemen met IPv6 te noemen. Je hebt geen idee waar je het over hebt.
Door Anoniem: Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is. Klein genoeg om geen problemen met PPoE apparaten of andere meuk te hebben. Als je wilt kun je de MTU aanpassen en automatisch laten bepalen. Het is echte kolder om IPv4 MTU grootte te gebruiken om problemen met IPv6 te noemen. Je hebt geen idee waar je het over hebt.
Niet zo scherp zijn als je het ook niet precies weet.
De RFC vereiste *minimum* MTU van IPv6 is 1280 bytes. De MTU kan en mag wel degelijk groter zijn / groeien met PMTUD ondersteuning.
De diverse heel grote internet partijen (google, cloudflare) beperken de MTU van hun uitgaand verkeer tot waarden waarbij de kans op de noodzaak van PMTUD beperkt is.
Deels ook afhankelijk van interne architectuur - bijvoorbeeld de noodzaak om verkeer nog te kunnen encapsuleren. En om latency sprongen te vermijden voor gebruikers van een VPN.
https://blog.cloudflare.com/increasing-ipv6-mtu/
Door Anoniem:
Niet zo scherp zijn als je het ook niet precies weet.
De RFC vereiste *minimum* MTU van IPv6 is 1280 bytes. De MTU kan en mag wel degelijk groter zijn / groeien met PMTUD ondersteuning.
De diverse heel grote internet partijen (google, cloudflare) beperken de MTU van hun uitgaand verkeer tot waarden waarbij de kans op de noodzaak van PMTUD beperkt is.
Deels ook afhankelijk van interne architectuur - bijvoorbeeld de noodzaak om verkeer nog te kunnen encapsuleren. En om latency sprongen te vermijden voor gebruikers van een VPN.
https://blog.cloudflare.com/increasing-ipv6-mtu/
Door Anoniem: Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is. Klein genoeg om geen problemen met PPoE apparaten of andere meuk te hebben. Als je wilt kun je de MTU aanpassen en automatisch laten bepalen. Het is echte kolder om IPv4 MTU grootte te gebruiken om problemen met IPv6 te noemen. Je hebt geen idee waar je het over hebt.
Niet zo scherp zijn als je het ook niet precies weet.
De RFC vereiste *minimum* MTU van IPv6 is 1280 bytes. De MTU kan en mag wel degelijk groter zijn / groeien met PMTUD ondersteuning.
De diverse heel grote internet partijen (google, cloudflare) beperken de MTU van hun uitgaand verkeer tot waarden waarbij de kans op de noodzaak van PMTUD beperkt is.
Deels ook afhankelijk van interne architectuur - bijvoorbeeld de noodzaak om verkeer nog te kunnen encapsuleren. En om latency sprongen te vermijden voor gebruikers van een VPN.
https://blog.cloudflare.com/increasing-ipv6-mtu/
Beter lezen. Dat is precies wat ik schrijf. Wat begrijp je niet aan ‘default’?
Er zijn geen problemen met IPv6. 40% van het Amerikaanse verkeer is IPv6. Denk je niet dat er een stortvloed van probleem meldingen zou zijn als de onzin die wordt verkondigd ook maar een kern van waarheid zou bevatten?
Door Anoniem: Beter lezen. Dat is precies wat ik schrijf. Wat begrijp je niet aan ‘default’?
Default is iets anders dan minimum. Het eerste betekent dat dat de waarde is die wordt gekozen als er geen andere waarde is opgegeven, het tweede betekent dat de waarde niet kleiner kan of mag worden.Aangezien dat verschillende dingen zijn was het niet precies wat je schreef, maar iets wezenlijk anders.
Beter lezen? Nee, beter schrijven.
Door Anoniem:
Beter lezen. Dat is precies wat ik schrijf. Wat begrijp je niet aan ‘default’?
Door Anoniem:
Niet zo scherp zijn als je het ook niet precies weet.
De RFC vereiste *minimum* MTU van IPv6 is 1280 bytes. De MTU kan en mag wel degelijk groter zijn / groeien met PMTUD ondersteuning.
De diverse heel grote internet partijen (google, cloudflare) beperken de MTU van hun uitgaand verkeer tot waarden waarbij de kans op de noodzaak van PMTUD beperkt is.
Deels ook afhankelijk van interne architectuur - bijvoorbeeld de noodzaak om verkeer nog te kunnen encapsuleren. En om latency sprongen te vermijden voor gebruikers van een VPN.
https://blog.cloudflare.com/increasing-ipv6-mtu/
Door Anoniem: Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is. Klein genoeg om geen problemen met PPoE apparaten of andere meuk te hebben. Als je wilt kun je de MTU aanpassen en automatisch laten bepalen. Het is echte kolder om IPv4 MTU grootte te gebruiken om problemen met IPv6 te noemen. Je hebt geen idee waar je het over hebt.
Niet zo scherp zijn als je het ook niet precies weet.
De RFC vereiste *minimum* MTU van IPv6 is 1280 bytes. De MTU kan en mag wel degelijk groter zijn / groeien met PMTUD ondersteuning.
De diverse heel grote internet partijen (google, cloudflare) beperken de MTU van hun uitgaand verkeer tot waarden waarbij de kans op de noodzaak van PMTUD beperkt is.
Deels ook afhankelijk van interne architectuur - bijvoorbeeld de noodzaak om verkeer nog te kunnen encapsuleren. En om latency sprongen te vermijden voor gebruikers van een VPN.
https://blog.cloudflare.com/increasing-ipv6-mtu/
Beter lezen. Dat is precies wat ik schrijf. Wat begrijp je niet aan ‘default’?
Dat het niet waar is ?
De pakketgrootte is NIET 1280 bij default - de pakketgrootte is ook niet 'default beperkt' tot 1280 .
Misschien moet je die cloudflare link lezen voor wat operationele ervaring - je haalt er minimaal uit dat het verkeer NIET "default" 1280 is of daar 'default' op gelimiteerd.
Niet (meer) door hen, en absoluut ook niet door de grote meerderheid van hun bezoekers.
Hint : 'default' betekent "standaard altijd zo ingesteld " .
Dat is niet hetzelfde als 'minimum dat iedere link en router moet supporten' .
Er zijn geen problemen met IPv6. 40% van het Amerikaanse verkeer is IPv6. Denk je niet dat er een stortvloed van probleem meldingen zou zijn als de onzin die wordt verkondigd ook maar een kern van waarheid zou bevatten?
*Dat* is wel absoluut waar - en ik ben ook niet de idioot die schreef dat ie IPv6 uitzet wegens 'half internet heeft een PMTUD probleem ermee" .
Misschien wordt het tijd voor je om eens op te zoeken wat de defaults zijn: OpenBSD: 1280, Linux: 1280, Windows: 1280, DAARNA wordt (eventueel!) pMTU discovery aangezet. Het minimum is, heel toevallig, de default. Heel gek. Want daarmee ontstaan er nooit MTU problemen…
Netneutraliteit gaat over dat elk eindpunt op het netwerk (IPv4 en/of IPv6) waar toegang toe wordt geboden bereikbaar is
en dat verkeer naar die eindpunten gelijk (neutraal) wordt behandeld.
Netneutraliteit gaat er niet over dat zowel aan ipv4 als ipv6 toegang moet worden geboden.
BEREC is de club die bezig is met een plan om ipv6-toegang in de hele EU de standaard te maken.
Omdat het nu nog geen officiële Europese standaard is, hoeven internetproviders in de EU nu nog niet beslist ipv6 te leveren, maar als ze wel al ipv6 leveren dan valt dit onder de wet van netneutraliteit.
en dat verkeer naar die eindpunten gelijk (neutraal) wordt behandeld.
Netneutraliteit gaat er niet over dat zowel aan ipv4 als ipv6 toegang moet worden geboden.
BEREC is de club die bezig is met een plan om ipv6-toegang in de hele EU de standaard te maken.
Omdat het nu nog geen officiële Europese standaard is, hoeven internetproviders in de EU nu nog niet beslist ipv6 te leveren, maar als ze wel al ipv6 leveren dan valt dit onder de wet van netneutraliteit.
Door Anoniem: Misschien wordt het tijd voor je om eens op te zoeken wat de defaults zijn: OpenBSD: 1280, Linux: 1280, Windows: 1280, DAARNA wordt (eventueel!) pMTU discovery aangezet. Het minimum is, heel toevallig, de default. Heel gek. Want daarmee ontstaan er nooit MTU problemen…
Je begon met: Wat een kolder. Als je bekend zou zijn met IPv6 dan zou je weten dat de pakket grootte 1280 by default is.
"Als je bekend zou zijn met IPv6". Volgens mij beweer je daar dat de default van 1280 voor IPv6 geldt. Staat dat ergens in een RFC? Bij mijn weten niet. In RFC8200 staat dat 1280 het minimum is en dat voor links met een configureerbare MTU een waarde van 1500 of groter wordt aanbevolen.Je noemt defaults die verschillende besturingssystemen aanhouden. Dat zijn geen defaults van IPv6 maar van die besturingssystemen. Zelfs als iedereen in de praktijk 1280 als default aanhoudt is dat niet de default van IPv6, maar van al die specifieke implementaties. En dat is een relevant onderscheid, omdat dat betekent dat die grootte van 1280 die je ziet niet in beton gegoten is. Als een ander besturingssysteem, of een nieuwe versie van een van de genoemde, opeens een grotere default gaat aanhouden, dan wijkt die niet af van wat de bedoeling van IPv6 is, maar dan ben jij met je slordige interpretaties en formuleringen degene die dingen anders is gaan zien dan ze bedoeld zijn.
"Goed lezen", schreef je ook. Wat hier volgens mij gebeurt is dat verschillende mensen beter hebben gelezen wat je geschreven had dan jij in de gaten hebt dat je schreef. Probeer eens precies te zijn met je begrip van de materie en met de taal waarin je dat begrip uitdrukt.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.