Het grote IPv6 topic

[gertvdijk]

Dutch2007 schreef op vrijdag 3 mei 2019 @ 10:36:
Via het communicty forum de regels voorkeurs regels laten wijzigen?

Yep, inmiddels heb ik "Mark Ziggo" daar gevraagd of hij wat voor mij kan betekenen. In een aantal eerdere topics was het gewoon geregeld door hem.

Update: inmiddels is het gelukt door hulp van een alleraardigste medewerker in een VFZiggo-winkel.

gertvdijk wijzigde deze reactie 03-05-2019 23:00 (21%)

[Dreamvoid]

mdavids schreef op vrijdag 3 mei 2019 @ 09:53:
Port-forwarding mis ik niet, want 'aan de andere kant' van de lijn heb ik ook IPv6, dus ik kan prima van buitenaf bij mijn thuis-apparaten.

Ook met IPv6 op de client zal je toch een port in de firewall van je router open moeten zetten, hoe kan je anders contact maken met je server thuis?

[Hipska]

Correct! Dat is gewoon firewall configuratie, geen port forwarding.

[Raven]

Het resultaat is toch hetzelfde? Een (inkomende) poort dat open wordt gezet.

Raven schreef op donderdag 2 mei 2019 @ 12:38:
* Raven doet IPv6 uitzetten.

De laatste tijd krijg ik steeds vaker Cloudflare captcha pagina's (o.a. te merken door niet werkende plaatjes op GoT) en zojuist kwam ik een website tegen waar geen captcha mogelijkheid beschikbaar is, die website kan ik dus niet eens meer openen (via IPv6 dus).

Ik vraag mij af of dit probleem gerelateerd is aan het probleem dat Facebook nog steeds beweerd dat mijn IPv6-addressen in DE uitkomen i.p.v. NL, met deels naar Duits vertaalde news feed tot gevolg

Kent iemand die Claudflare captcha pagina toevallig? Heb het alleen met IPv6.

Cloudflare: There has been a number of security events relating to this IP address, which has caused you to hit bad reputation. Please review your network and confirm that you have no infected devices. Once that has been confirmed, the IP reputation will naturally improve.

Raven wijzigde deze reactie 07-05-2019 11:13 (86%)

[Roetzen]

Het resultaat is inderdaad hetzelfde, maar het is zuiverder om de juiste terminologie te gebruiken. Port Forwarding is wat men doet bij NAT. Bij NAT wordt een binnenkomend pakketje middels de NAT tabel naar een bepaalde bestemming geleid. Bij IPv6 is er geen NAT. Om een ongevraagd pakketje op een poort bij de bestemming te laten komen, hoeft het alleen maar doorgelaten te worden. De bestemming is al bekend.

[Raven]

Agreed

[markmjb]

Net mijn internetverbinding verneukt door het ipv4 adres te vernieuwen maar niet het ipv6 adres. Wist niet dat je aparte parameters aan ipconfig moet meegeven als je dat soort dingen wil resetten Gelukkig werkt je router opnieuw opstarten dan weer wel.

Ik ben wat ipv6 echt een leek, maar waarom werken dit soort dingen in chrome niet? Heeft google een apart adres voor het Ping command ofzo ?

[Roetzen]

Nieuwe metingen:




t'Kon beter...

[Freeaqingme]

markmjb schreef op dinsdag 14 mei 2019 @ 11:52:

Ik ben wat ipv6 echt een leek, maar waarom werken dit soort dingen in chrome niet? Heeft google een apart adres voor het Ping command ofzo ?

Wat werkt er niet?

[wopper]

markmjb schreef op dinsdag 14 mei 2019 @ 11:52:
Net mijn internetverbinding verneukt door het ipv4 adres te vernieuwen maar niet het ipv6 adres. Wist niet dat je aparte parameters aan ipconfig moet meegeven als je dat soort dingen wil resetten Gelukkig werkt je router opnieuw opstarten dan weer wel.

Ik ben wat ipv6 echt een leek, maar waarom werken dit soort dingen in chrome niet? Heeft google een apart adres voor het Ping command ofzo ?
[Afbeelding]

Denk dat de webserver niet weet waar je heen wilt, maar dat je hem wel bereikt?

https://ipv6.google.com is wat jij wilt testen

[markmjb]

wopper schreef op dinsdag 14 mei 2019 @ 12:28:
[...]


Denk dat de webserver niet weet waar je heen wilt, maar dat je hem wel bereikt?

https://ipv6.google.com is wat jij wilt testen

Yeah, zo te zien ping ik de router en wil ik de webserver hebben.
Tweakers is http://[2001:9a8:0:e:1337:0:80:1] ( 1337 web adres) maar geeft ook een error.
http://[2001:9a8:0:e:1337:0:80:3] is elect.tweakers.net dus dat bevestigt mijn vermoeden haha.

[Dutch2007]

markmjb schreef op dinsdag 14 mei 2019 @ 11:52:
Net mijn internetverbinding verneukt door het ipv4 adres te vernieuwen maar niet het ipv6 adres. Wist niet dat je aparte parameters aan ipconfig moet meegeven als je dat soort dingen wil resetten Gelukkig werkt je router opnieuw opstarten dan weer wel.

Ik ben wat ipv6 echt een leek, maar waarom werken dit soort dingen in chrome niet? Heeft google een apart adres voor het Ping command ofzo ?
[Afbeelding]

http://[2001:4860:0:2001::68]/

https://www.cyberciti.biz...ess-used-with-webbrowser/

e.g. http(s) d'r voorzetten?

[Hipska]

Verkiezingstijd in België, nog veel werk te doen:

Let’s start with the IPv6-enabled:
https://ecolo.be/, IPv6, CBlue SPRL (Namur)
http://www.lecdh.be/, IPv6, TLS but no TLS redirection, OVH
https://www.n-va.be/, IPv6, Cloudflare

Then, the legacy web sites (no IPv6, no AAAA):
https://defi.eu/, no IPv6, OVH
https://partipopulaire.be/, no IPv6, OVH
https://www.cdenv.be/, no IPv6, OpenMinds (Ghent)
https://www.groen.be/, no IPv6, Akamai
http://www.mr.be, no IPv6, OVH
https://www.ps.be, no IPv6, OVH
https://www.ptb.be/, no IPv6, Akamai
https://www.pvda.be/, no IPv6, Akamai
https://www.s-p-a.be, no IPv6, Upcloud (Finland)
https://www.vlaamsbelang.org/, no IPv6, iWeb Technologies Inc. (Québec)
https://www2.openvld.be/, no IPv6, SiteGround (Netherlands)

Bron: https://www.ipv6council.b...ropean-elections-and-ipv6

[Jef61]

Kan iemand bevestigen dat transip.nl via IPv6 niet lekker werkt? Ik heb steeds haperingen op die site, schakel ik IPv6 uit dan gaat alles goed. Ik heb dit al eens aangegeven bij hun maar merk geen verbetering. Ik heb ook hun stack in mijn firewall op IPv6 geblokkeerd omdat de backup dan wel goed loopt. Iemand die dit herkend?

[KRGT]

Jef61 schreef op donderdag 30 mei 2019 @ 10:42:
Kan iemand bevestigen dat transip.nl via IPv6 niet lekker werkt? Ik heb steeds haperingen op die site, schakel ik IPv6 uit dan gaat alles goed. Ik heb dit al eens aangegeven bij hun maar merk geen verbetering. Ik heb ook hun stack in mijn firewall op IPv6 geblokkeerd omdat de backup dan wel goed loopt. Iemand die dit herkend?

Ik herken dit niet, wat voor IPv6 gebruik je? Native of via HE.net? of?

[Jef61]

Native, via xs4all. Heb dit alleen bij Transip. Bij het browsen op die site regelmatig een timeout van de browser, na een F5 gaat het weer even goed.

Jef61 wijzigde deze reactie 30-05-2019 10:48 (52%)
Reden: Toevoeging

[KRGT]

Jef61 schreef op donderdag 30 mei 2019 @ 10:44:
Native, via xs4all. Heb dit alleen bij Transip.

https://ipv6-test.com/ geeft alles groen en 20/20?

[Jef61]

17/20. Geen hostname, geen icmp naar mijn PC (windows firewall denk ik), geen reverse DNS.

Jef61 wijzigde deze reactie 30-05-2019 10:51 (0%)
Reden: Typo

[KRGT]

Jef61 schreef op donderdag 30 mei 2019 @ 10:51:
17/20. Geen hostname, geen icmp naar mijn PC (windows firewall denk ik), geen reverse DNS.

ICMP is wel belangrijk, op de onderstaande site staan eigenlijk diegene die je door moet laten.

http://shouldiblockicmp.com/

[Jef61]

OK, windows firewall uitgezet, nu 19/20. Helaas geen verbetering.

[mauricej]

Geen idee of het gerelateerd is, maar ik merk ook dat mijn VPS bij TransIP soms niet via IPv6 bereikbaar is. Via IPv4 geen probleem, maar via IPv6 gaat er ergens iets mis.
Vanaf mijn VPS kan ik wel met IPv6 naar bijvoorbeeld google.com ping6-en, vanaf thuis (XS4ALL glas) ook, maar vanaf thuis naar mijn VPS werkt niet.
Als eens geprobeerd met traceroute te achterhalen waar het mis gaat, maar ik kwam er niet achter.

[Jef61]

Ik heb gisteren nog een tijdje een ping (6) laten lopen naar transip.nl maar daar is niets bijzonders aan te zien, ook niet op het moment dat de website begint te haperen.

[Samueldw]

Weet iemand hoe het zit met KPN i.c.m. VDSL en IPv6? Ik kan er maar weinig over vinden. Ik heb een eigen modem/router. IPv6 staat daar nu op uit, maar ik heb ook geen idee wat de eventuele instellingen moeten zijn om IPv6 werkend te krijgen op VDSL.

[Jef61]

En weer een website die het bij mij niet doet op IPv6: www.maldenwandelt.nl
Ga je je zoeken waar die gehost is blijkt dat opnieuw bij Transip te zijn.

Zou toch graag willen weten waar dit fout gaat, toch bij xs4all misschien?

[Zr40]

Hier met XS4ALL werkt die website gewoon goed via IPv6.

[Jef61]

Zr40 schreef op maandag 10 juni 2019 @ 13:07:
Hier met XS4ALL werkt die website gewoon goed via IPv6.

Glas of DSL?

[KRGT]

Jef61 schreef op maandag 10 juni 2019 @ 12:47:
En weer een website die het bij mij niet doet op IPv6: www.maldenwandelt.nl
Ga je je zoeken waar die gehost is blijkt dat opnieuw bij Transip te zijn.

Zou toch graag willen weten waar dit fout gaat, toch bij xs4all misschien?

Werkt hier ook goed, IPv6 /48 blok van ExtraIP.com.

[ik222]

@Jef61 Hier werkt die site ook gewoon goed via XS4ALL glasvezel. Net zoals ik eigenlijk nooit problemen met IPv6 heb, zeker niet met TransIP.

Je hebt niet zelf ergens een issue in je netwerk?

[Jef61]

Ik kan natuurlijk niet uitsluiten dat ik zelf ergens een issue heb maar ben al zo lang aan het zoeken. Enige houvast is dat het alleen bij Transip of bij Transip gehoste sites is. Het is ook niet dat het helemaal niet werkt. Soms gaat het enkele minuten goed en dan plots begint het weer gigantisch te haperen. IPv4 geen enkel probleem. Ping6 laat geen problemen zien, ook niet tijdens haperen.

Ik weet dat er een tijdje geleden problemen waren met de bereikbaarheid van de nos.nl via IPv6. Oorzaak was toen dat ze icmp dicht hadden zitten. Problemen kwamen echter alleen tevoorschijn bij dsl gebruikers omdat die vanwege pppoe een mtu hebben van 1492.

Ik heb steeds het idee dat er nu ook zoiets speelt (hoewel de ping werkt), iets dus wat alleen bij een klein aantal gebruikers speelt. (vandaar mijn vraag glas of dsl).

Jef61 wijzigde deze reactie 10-06-2019 15:05 (0%)
Reden: npo.nl gewijzigd naar nos.nl

[ik222]

Ik heb wel mijn MTU op 1500 gezet middels RFC4638 wat XS4ALL ondersteund. Volgens mij zowel op glas als op VDSL.

[Jef61]

Oké goede tip, ga ik naar kijken.

[randomnumber]

Test anders online je MTU, weet je iig wat de andere kant ziet wat je aankan.

Bv:
http://ipv6-test.com/pmtud/

[Jef61]

ik222 schreef op maandag 10 juni 2019 @ 15:53:
Ik heb wel mijn MTU op 1500 gezet middels RFC4638 wat XS4ALL ondersteund. Volgens mij zowel op glas als op VDSL.

Heb mijn Vigor 130 firmware geupdate en aangepast, daarna Mikrotik pppoe client op mtu1500 gezet. En idd hij connect nu op mtu 1500

Uitgebreid getest op Transip en het lijkt succesvol, geen haperingen meer!!
Zou betekenen dat er toch iets met de icmp6 bij Transip niet goed staat, en bepaald type misschien?

@ik222 Bedankt voor het op het juiste spoor zetten!


Uit RFC4890

4.3.1. Traffic That Must Not Be Dropped

Error messages that are essential to the establishment and
maintenance of communications:

o Destination Unreachable (Type 1) - All codes
o Packet Too Big (Type 2)
o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only

4.3.2. Traffic That Normally Should Not Be Dropped

Error messages other than those listed in Section 4.3.1:

o Time Exceeded (Type 3) - Code 1
o Parameter Problem (Type 4) - Code 0

Jef61 wijzigde deze reactie 10-06-2019 18:15 (31%)
Reden: RFC toegevoegd

[Jef61]

Kleine laatste toevoeging:

Heb helaas de wijziging moeten terugdraaien omdat ik met de nieuwe configuratie IPTV niet werkende krijg en heb dus weer connectie problemen. Zoek ook nog contact hierover met Transip of ze hun firewall settings willen nalopen maar heb weinig hoop.

[henk-willem]

Helaas heb ik ook problemen met het bereiken van TransIP sites over IPv6. De TransIP homepagina geeft geen problemen, maar mijn TransIP stack en de eerder genoemde www.maldenwandelt.nl willen niet laden. Dit probleem vindt zowel plaats op een XS4ALL verbinding met native IPv6 als op een verbinding waarbij IPv6 via TunnelBroker gaat. Beide verbindingen zijn voorzien van een pfSense firewall/router.
http://ipv6-test.com/pmtud/ Geeft aan dat ik geen problemen zou moeten hebben een MTU van 1500.

[Zr40]

Vreemd, met een IPv6 tunnel zou je MTU 1480 moeten zijn, niet 1500, want een 6in4 tunnel heeft 20 bytes nodig per packet. Als die test 1500 zegt op de verbinding met de tunnel, dan is er iets mis.

Controleer ook of je native IPv6 verbinding gebruik maakt van RFC4638. Zo niet, dan is 1492 de juiste MTU en is 1500 ook een onjuist resultaat uit die test.

[Jef61]

Die test geeft bij mij ook altijd 1500 aan. Denk dat de test niet klopt of iets anders aan geeft.

[ik222]

Die test geeft volgens mij enkel aan of path MTU werkt tussen jou verbinding en de test server. Ze proberen daarvoor een packet van 1500 bytes te sturen en als die in kleinere stukjes aan komt op basis van PMTU is de test ook succesvol. Het zegt dus niets over de absolute MTU op jou verbinding.

Ik heb het zelf niet uitgebreid getest maar het lijkt er inderdaad op gezien de ervaringen dat TransIP ergens iets teveel ICMPv6 blokkeert. Daardoor heb je problemen als de MTU op je verbinding lager is dan 1500.

[Jef61]

Zoals verwacht kom ik bij Transip zelf niet verder, ook wel begrijpelijk omdat ze verder geen klachten krijgen. Ik zal het ermee moeten doen lijkt het.

[Hipska]

Misschien bij je ISP klagen?

[Roetzen]

New measurements:

Liberty global: geen verandering. KPN: een tandje terug

[Dreamvoid]

Telt bij KPN eigenlijk hun mobiele netwerk ook mee?

[St00mwals]

Dreamvoid schreef op dinsdag 18 juni 2019 @ 00:09:
Telt bij KPN eigenlijk hun mobiele netwerk ook mee?

Volgens mij zijn er in NL nog geen mobiele providers die IPv6 doen.

Hoewel dat volgens mij een van de meest eenvoudige zaken is om aan te pakken...

[Dreamvoid]

Dat weet ik (in de meeste Europese landen is er geen ipv6 op het mobiele netwerk), maar als het mobiele netwerk ook bij die KPN cijfers zit, dan gaat het dus bij de vaste aansluitingen iig harder dan het lijkt (en dat zou ook die daling kunnen verklaren - mobiel verkeer dat groeit tov vast internet)

Dreamvoid wijzigde deze reactie 18-06-2019 09:48 (18%)

[Bram D]

Jef61 schreef op dinsdag 11 juni 2019 @ 15:11:
Zoals verwacht kom ik bij Transip zelf niet verder, ook wel begrijpelijk omdat ze verder geen klachten krijgen. Ik zal het ermee moeten doen lijkt het.

Ik heb precies hetzelfde probleem. HE tunnel op een MikroTik router over een Ziggolijn. MTU van de HE tunnel interface is 1480.

Zeer irritant, nu zijn Stack en het Transip control panel ook erg onbetrouwbaar over ipv6. Toch maar eens een issue openen, had ik nog niet gedaan omdat ik geen idee had waar het probleem kon zitten.

[SpitfireNL]

Thuis op mijn eigen wifi netwerk krijgt mijn telefoon telkens een nieuw ipv6 adres. Gruwelijk irritant. Dit terwijl ik een vast IP-adres heb via glasvezel xs4all.

Nu elke keer als ik op 1 van mn favoriete sites via mijn telefoon inlog moet ik weer het nieuwe ipv6 adres via een email van die site toestaan om op die site te mogen inloggen.

Hoe kan ik er voor zorgen dat ook mijn telefoon op thuiswifi het vaste ipv4 adres van mijn xs4all provider gebruikt in plaats van telkens een nieuw ipv6 adres? En waar ligt dit aan?

Mijn telefoon instellingen heb ik al in gezocht maar onder wifi instellingen is er geen mogelijkheid ipv4 only te kiezen.
Kan ik dit nog via mijn router forceren? Ik heb een asus ac88u.

SpitfireNL wijzigde deze reactie 29-06-2019 14:42 (15%)

[Raven]

Kun je bij die site niet je gehele /64 (of wat je ook hebt) in een keer toestaan? Of alleen individuele IPv6 adressen.

[SpitfireNL]

Heb ik idd ook al gecontroleerd maar dat gaat daar niet in die site. Alleen individuele adressen.

Heb al overwogen om ipv6 in mijn router in zn geheel uit te schakelen maar dan ga ik andere problemen krijgen misschien?

SpitfireNL wijzigde deze reactie 29-06-2019 14:53 (38%)

[Brahiewahiewa]

SpitfireNL schreef op zaterdag 29 juni 2019 @ 14:36:
Thuis op mijn eigen wifi netwerk krijgt mijn telefoon telkens een nieuw ipv6 adres. Gruwelijk irritant. Dit terwijl ik een vast IP-adres heb via glasvezel xs4all.
...

Misschien privacy extensions eens uitzetten?

[ANdrode]

SpitfireNL schreef op zaterdag 29 juni 2019 @ 14:36:
Hoe kan ik er voor zorgen dat ook mijn telefoon op thuiswifi het vaste ipv4 adres van mijn xs4all provider gebruikt in plaats van telkens een nieuw ipv6 adres? En waar ligt dit aan?

Ten eerste: Ik merkte dit in 2014 op bij een security incident (ik wilde sessies fixeren aan IP adressen) en kreeg de terechte reactie dat dit bij IPv6 issues geeft. Het is een slechte implementatie van deze site.

Wat je kan vragen aan de site is om bij IPv6 subnetten te whitelisten.

Wat jij zelf kan doen is een statisch DNS record aanmaken in de router (kan bij bv openwrt dmv de hostname functie) waarmee je als eerste poging alleen een A record toevoegd. Daarna moet je kijken of er een AAAA record is en dat zo nodig ook overschrijven met iets anders.

Een plan B is om in de firewall van de router uitgaand verkeer naar de ip range van deze site te blokkeren. Maar als het om een CDN gaat is dat lastiger (zou zou ik de rest van het cloudflare/akamai verkeer wel via IPv6 willen)

[Dreamvoid]

IPv6 troubleshooting 'in het wild':

https://www.drivereasy.co...e-with-the-scanner-fixed/

Spot de fout in de uitleg van "Fix 2"

[Jef61]

Bram D schreef op maandag 24 juni 2019 @ 18:39:
[...]


Ik heb precies hetzelfde probleem. HE tunnel op een MikroTik router over een Ziggolijn. MTU van de HE tunnel interface is 1480.

Zeer irritant, nu zijn Stack en het Transip control panel ook erg onbetrouwbaar over ipv6. Toch maar eens een issue openen, had ik nog niet gedaan omdat ik geen idee had waar het probleem kon zitten.

Probleem laat me niet los en ben er vandaag weer eens ingedoken.
Ik denk dat ik een aardige workaround heb gevonden:

Ik kwam op de volgende website tegen dat je kunt overwegen om aan de PC kant je MTU wat betreft IPv6 op 1492 kunt zetten via router advertisement.
https://blog.ipspace.net/...-tcp-mss-clamping-in.html

Voor Mikrotik kun je dat in WinBox doen via: IPv6, ND, Bridge interface van je LAN, MTU (1492 in mijn geval).

Hierna kun je op je (windows) PC zien dat je IPv6 interface een MTU heeft gekregen van 1492:
netsh interface ipv6 show subinterface
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1492 1 8011563 734944 Wi-Fi

Na uitgebreid testen blijkt Transip.nl bij mij hiermee prima te werken
Moet nog uitgebreid testen of hiermee misschien andere problemen zijn ontstaan...

Ben benieuwd of dit voor jou ook een oplossing is.

Jef61 wijzigde deze reactie 01-07-2019 18:13 (0%)
Reden: Typos

[Bram D]

Jef61 schreef op maandag 1 juli 2019 @ 17:44:
[...]

Probleem laat me niet los en ben er vandaag weer eens ingedoken.
Ik denk dat ik een aardige workaround heb gevonden:

Ik kwam op de volgende website tegen dat je kunt overwegen om aan de PC kant je MTU wat betreft IPv6 op 1492 kunt zetten via router advertisement.

Ik heb het hier aangepast (naar 1480). Eens kijken hoe dat loopt de komende dagen.

In je link wordt MSS clamping als lelijke workaround beschreven en dat is het misschien ook wel, maar toch vind ik het wat vreemd om het lokale netwerk ook een lagere MTU te geven zoals nu gebeurt. Niet dat ik er op het LAN in praktijk veel van ga merken verwacht ik, maar we zullen zien. Afls het de issues met TransIp (en wellicht andere sites) oplost ben ik blij.

[Jef61]

Bram D schreef op maandag 1 juli 2019 @ 22:11:
[...]
Niet dat ik er op het LAN in praktijk veel van ga merken verwacht ik, maar we zullen zien

Je IPv4 blijft op MTU=1500 werken met deze configuratie dus tenzij je je interne NAS/servers op IPv6 benaderd zul je er niets van merken. Ik heb nog geen andere issues ontdekt dus laat het vooralsnog zo.

[Roetzen]

Nieuwe metingen:





Een stapje naar beneden. een iets groter stapje omhoog. Veel schot zit er nog niet in..

[St00mwals]

Roetzen schreef op zondag 21 juli 2019 @ 18:30:
Nieuwe metingen:

[Afbeelding]

[Afbeelding]

Een stapje naar beneden. een iets groter stapje omhoog. Veel schot zit er nog niet in..

De snelheid van uitrol blijft gewoon zeer matig...☹️

[the7thstranger]

Ik heb een korte vraag tussendoor voor medegebruikers van HE.net. Ik gebruik deze dienst nu al een tijdje aangezien Ziggo nog altijd geen IPv6 in bridge mode aanbiedt. Qua betrouwbaarheid en latency ben ik best tevreden, maar qua throughput merk ik dat ik er best enorm op achteruit ga.

Mijn Ziggo-lijn is 250/25Mbps. Dat haal ik over ethernet ook makkelijk. Maar over de IPv6-tunnel naar tserv11.ams1.ipv6.he.net (die preferred is op alle apparaten) haal ik doorgaans niet meer dan 15/15Mbps. Nu lees ik op het internet toch dat mensen wel beter krijgen dan dat.

Ik heb contact gehad met HE.net hierover, maar de antwoorden die ik krijg zijn tamelijk vaag en lijken canned responses.

Each tserv is a shared resource with upwards of thousands of other users at the same time. While their uplinks aren't generally congested, you are still trying to send your data through a single node with all the other users. Also you've still got the IPv4 overhead of packets inside packets, TCP window tuning, latencies, etc. Speed parity isn't guaranteed on our part, to be similar to your native IPv4. Also your ISP could be doing QoS (sometimes unlikely, but only they'd know) that might inhibit. It is generally tough to narrow down where and why speeds aren't close to parity, but usually a bit of tuning of TCP windowing, MTU/MSS can make things better, when done on the client side.

Ik heb een WDR4300 met OpenWrt 18.06.4. De MTU van de tunnel en op m'n router staan op 1480. Verder zou ik niet direct weten wat ik dan moet tweaken, of hoe.

Hoe is de throughput die anderen halen ongeveer?

[Roetzen]

the7thstranger schreef op maandag 29 juli 2019 @ 20:53:
Hoe is de throughput die anderen halen ongeveer?

Ik heb mijn he.net tunnel niet meer gebruikt sinds ik twee jaar geleden Native IPv6 van Ziggo kon krijgen. Maar met de tunnel haalde ik ook nooit meer dan 15 MBps. Ik ben er nooit achter kunnen komen waar dat aan lag.

[hkoster1]

@the7thstranger De schakel tussen IPv4 en IPv6 is een portmapper die je bij voorbeeld op een minimale VPS kunt draaien. Een beetje VPS zal zeker qua snelheid beter presteren dan een HE-tunnel. De VPS moet zowel een publiek IPv4- als IPv6-adres hebben; dat IPv6-adres is het adres waarop je vanaf het internet te bereiken bent.
Op een VPS met voorgeïnstalleerd Debian GNU/Linux OS kun je het programma "socat" gebruiken om de IPv6-naar-IPv4 portmapping in te stellen, zie verder de man-pages voor instructies. Er wordt gebruik gemaakt van een TCP-verbinding op een zelf gekozen poort.

[the7thstranger]

Roetzen schreef op maandag 29 juli 2019 @ 21:31:
[...]
Ik heb mijn he.net tunnel niet meer gebruikt sinds ik twee jaar geleden Native IPv6 van Ziggo kon krijgen. Maar met de tunnel haalde ik ook nooit meer dan 15 MBps. Ik ben er nooit achter kunnen komen waar dat aan lag.

Ondervond je daarvan geen hinder dan? Want op het moment dat een device een IPv6-gateway heeft, zal die altijd de voorkeur hebben, dus al je traffic wordt door die veel tragere tunnel geduwd.

Ik heb in ieder geval nog geen nette manier gevonden om IPv4 de voorkeur te geven over IPv6, op smerige hacks als het aanpassen van /etc/gai.conf na en zo.

Ik blijf niet snappen dat Ziggo niet gewoon IPv6 in bridge mode kan aanbieden. Ik kan zelf echt wel DS-Lite instellen..

[hkoster1]

Begrijp niet wat je bedoelt. Als je zelf van de ISP geen publiek IPv6-adres krijgt, dan is toch het enige probleem om daar in te voorzien? Dat doet nu HE bij jou (langzaam), dat zou door een portmapper op een VPS kunnen worden gedaan (sneller waarschijnlijk).
Verder wil ik je geen mening opdringen over IPv4 vs IPv6 voorkeuren...

[the7thstranger]

@hkoster1 Volgens mij doel je nu op iets anders dan waar ik het over heb. Ik weet welke opties er zijn om zelf 6in4-tunnels te regelen. Ik heb op mijn VPS ook al jaren een OpenVPN-server draaien die voor alle clients automatisch IPv6-tunnels opzet. Dus als ik met mijn VPN verbind, heb ik gewoon IPv6 wat behoorlijk snel is (rond de 150Mbps).

Helaas heeft mijn VPS zelf echter een SLAAC-adres, dus ik kan hem - voor zover ik weet - niet gebruiken om een prefix aan mijn router te delegeren.

Maar goed, waar ik op doelde met mijn vraag aan @Roetzen ging over HE.net. Die tunnels zijn traag, maar als je je router configureert om hun tunnel te gebruiken, gaan alle clients in je LAN die tunnel prefereren boven je (veel snellere) IPv4 WAN. Dat vind ik doorgaans lastig, want zo duren downloads en updates letterlijk 15x zo lang.

Dus in het geval van HE.net zou ik dan waarschijnlijk liever de insteek hebben dat IPv4 de voorkeur heeft, en die IPv6-tunnel alleen moet worden gebruikt voor IPv6-only zaken. Maar dat is bij mijn weten niet netjes te configureren zonder lelijke hacks of andere dingen te breken.

Uiteraard zou ik het liefst zelf een soort tunnelbroker.net opzetten door op een VPS een Protocol41-setup te draaien, maar dan moet ik wel een VPS hebben waar ik een /60 of /56 subnet op toegewezen kan krijgen.

[Roetzen]

the7thstranger schreef op maandag 29 juli 2019 @ 23:06:
[...]
Ondervond je daarvan geen hinder dan? Want op het moment dat een device een IPv6-gateway heeft, zal die altijd de voorkeur hebben, dus al je traffic wordt door die veel tragere tunnel geduwd.

Klopt, maar ik had er weinig of geen last van. Ik ben geen datavreter. Ik doe niet aan gamen, ik download geen films of andere grote bestanden. Ik had altijd het pakket met de laagste snelheid. Ik gebruik mijn internet verbinding voornamelijk voor een beetjes surfen over het net en e-mailem.

Ik heb in ieder geval nog geen nette manier gevonden om IPv4 de voorkeur te geven over IPv6, op smerige hacks als het aanpassen van /etc/gai.conf na en zo.

Ik weet niet hoe het in Linux gaat. Met Windows kan het met netsh... prefixpolicies.

https://gavindraper.com/2...To-Prefer-IPV4-Over-IPV6/

Maar dat is dan alleen voor die ene Windows machine. Ik zou ook niet weten hoe je het voor alle aangesloten apparaten op het LAN moet doen. Ik heb er nooit mee ge-experimenteerd.

Ik blijf niet snappen dat Ziggo niet gewoon IPv6 in bridge mode kan aanbieden. Ik kan zelf echt wel DS-Lite instellen..

Ik hoop dat ze daar ooit nog eens iets aan gaan doen. Voorlopig kan ik wel uit de voeten met de Dual Stack van de Connectbox. Maar ik zou ook liever native IPv6 hebben met een eigen router.

[Dreamvoid]

Roetzen schreef op zondag 21 juli 2019 @ 18:30:
Nieuwe metingen:

[Afbeelding]

[Afbeelding]

Een stapje naar beneden. een iets groter stapje omhoog. Veel schot zit er nog niet in..

KPN zit ws nu op het vervangingstempo van oude modems? Blijft lastig om te zien hoeveel van het totale aantal verbindingen huishoudens zijn, hoeveel enterprise en hoeveel mobile. Zelfs al zit 100% van de Experiabox-klanten op IPv6 dan zal je deze grafiekjes ws niet boven de 40% zien uitkomen, gezien de miljoenen devices op het mobile netwerk. En zodra ze bijvoorbeeld 646XLAT uitrollen op het mobiele netwerk schieten ze waarschijnlijk in 1 klap naar 90% ofzo.

[ANdrode]

the7thstranger schreef op maandag 29 juli 2019 @ 20:53:
Ik heb een WDR4300 met OpenWrt 18.06.4. De MTU van de tunnel en op m'n router staan op 1480. Verder zou ik niet direct weten wat ik dan moet tweaken, of hoe.

Hoe is de throughput die anderen halen ongeveer?

Archer C7

offtopic:
(100/100 T-Mobile Thuis met QoS layer_cake op mijn router, HE.net naar tserv1.ams1.he.net, iperf3 tests naar VM op een host met native dual stack 1000/1000, haalt +- 930-940 mbit/s effectief naar een ESX VM in ander netwerk)

ipv6 down: 103 mbit/s
ipv4 down: 108 mbit/s

up heeft issues bij T-Mobile thuis bij één verbinding. Pakketten worden gedropt en daardoor klein TCP window/lage throughput.

1 verbinding:
ipv4 up: 19,8 mbit/s (issue bij T-Mobile thuis)
ipv6 up: 16,5 mbit/s

8 verbindingen:
ipv4 up: 108 mbit/s
ipv6 up: 75,8 mbit/s

[Dutch2007]

Roetzen schreef op dinsdag 30 juli 2019 @ 00:55:
[...]

Klopt, maar ik had er weinig of geen last van. Ik ben geen datavreter. Ik doe niet aan gamen, ik download geen films of andere grote bestanden. Ik had altijd het pakket met de laagste snelheid. Ik gebruik mijn internet verbinding voornamelijk voor een beetjes surfen over het net en e-mailem.

[...]

Ik weet niet hoe het in Linux gaat. Met Windows kan het met netsh... prefixpolicies.

https://gavindraper.com/2...To-Prefer-IPV4-Over-IPV6/

Maar dat is dan alleen voor die ene Windows machine. Ik zou ook niet weten hoe je het voor alle aangesloten apparaten op het LAN moet doen. Ik heb er nooit mee ge-experimenteerd.

[...]

Ik hoop dat ze daar ooit nog eens iets aan gaan doen. Voorlopig kan ik wel uit de voeten met de Dual Stack van de Connectbox. Maar ik zou ook liever native IPv6 hebben met een eigen router.

In windows kan je gewoon via de volgende link:

https://support.microsoft...indows-for-advanced-users

IPv4 de voorkeur geven ipv IPv6

Of een reg key aanpassen

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
Name: DisabledComponents
Type: REG_DWORD
Min Value: 0x00
Max Value: 0xFF (IPv6 disabled)

IPv4 boven IPv6 verkiezen

Dec 32

Hex 0x20

Bin xx1x xxxx

Aanbevolen in plaats van uitschakelen.

[the7thstranger]

ANdrode schreef op dinsdag 30 juli 2019 @ 09:29:
[...]
Archer C7

offtopic:
(100/100 T-Mobile Thuis met QoS layer_cake op mijn router, HE.net naar tserv1.ams1.he.net, iperf3 tests naar VM op een host met native dual stack 1000/1000, haalt +- 930-940 mbit/s effectief naar een ESX VM in ander netwerk)

ipv6 down: 103 mbit/s
ipv4 down: 108 mbit/s

up heeft issues bij T-Mobile thuis bij één verbinding. Pakketten worden gedropt en daardoor klein TCP window/lage throughput.

1 verbinding:
ipv4 up: 19,8 mbit/s (issue bij T-Mobile thuis)
ipv6 up: 16,5 mbit/s

8 verbindingen:
ipv4 up: 108 mbit/s
ipv6 up: 75,8 mbit/s

Heb je daarvoor nog configuratie aangepast? Maakt QoS nog verschil voor zovel je weet?

Dutch2007 schreef op dinsdag 30 juli 2019 @ 11:37:
[...]
In windows kan je gewoon via de volgende link:

https://support.microsoft...indows-for-advanced-users

IPv4 de voorkeur geven ipv IPv6

Of een reg key aanpassen

Dat lijkt hetzelfde te zijn als het aanpassen van /etc/gai.conf in UNIX om getaddrinfo IPv4 te laten prefereren. Maar dan gebeurt dat dus op ieder netwerk en moet je het op iedere client aanpassen. Dat is ook niet wenselijk.

[Dutch2007]

the7thstranger schreef op dinsdag 30 juli 2019 @ 12:18:
[...]


Dat lijkt hetzelfde te zijn als het aanpassen van /etc/gai.conf in UNIX om getaddrinfo IPv4 te laten prefereren. Maar dan gebeurt dat dus op ieder netwerk en moet je het op iedere client aanpassen. Dat is ook niet wenselijk.

Zakelijk / bedrijfsmatig kan je natuurlijk eea via een Group Policy laten lopen:

https://theitbros.com/add...-keys-using-group-policy/

[ANdrode]

the7thstranger schreef op dinsdag 30 juli 2019 @ 12:18:
[...]
Heb je daarvoor nog configuratie aangepast? Maakt QoS nog verschil voor zovel je weet?

Het is de default configuratie van de tunnel in OpenWRT .

QoS zorgt er voor dat de throttling aan mijn kant plaatsvindt in plaats van door de ISP. Daardoor is er minder last van packet loss en lagere latency. Zou dit soweiso aanraden.

[the7thstranger]

@ANdrode Ik kwam zojuist ook nog dit topic tegen: https://community.ziggo.n...verstap-connect-box-40842

Als een bridged modem dit echt kan veroorzaken, is dat toch wel zeer ernstig..

[ANdrode]

the7thstranger schreef op dinsdag 30 juli 2019 @ 12:40:
Als een bridged modem dit echt kan veroorzaken, is dat toch wel zeer ernstig..

Bij ConnectBox is de bridge een software implementatie die lijkt op bridge. Alle effecten met niet-geoptimaliseerde protocollen blijven aanwezig.

Heb je de Arris ConnectBox of de Compal? Vooral de tweede was eerder praktisch onbruikbaar door dit issue.

[the7thstranger]

@ANdrode

code:

$  curl http://192.168.100.1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta http-equiv="pragma" content="no-cache" />
<!-- release 061213-->
<!-- (c) Copyright 2011-2012, ARRIS Group, Inc., All rights reserved. -->
<link rel="stylesheet" type="text/css" media="all" href="css/global.css?ver=9.1.1802.613"/>

[ANdrode]

the7thstranger schreef op dinsdag 30 juli 2019 @ 12:58:
@ANdrode

code:

$  curl http://192.168.100.1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta http-equiv="pragma" content="no-cache" />
<!-- release 061213-->
<!-- (c) Copyright 2011-2012, ARRIS Group, Inc., All rights reserved. -->
<link rel="stylesheet" type="text/css" media="all" href="css/global.css?ver=9.1.1802.613"/>

Oef. Voor zover ik weet zijn er weinig mogelijkheden om een ander modem te krijgen.

Een TC7210 wordt nog geactiveerd door webcare als je er één hebt. Er is ook een nieuw en degelijk Ubee modem met DOCSIS 3.1 maar volgens mij is er geen gestandaardiseerd proces om zo'n modem te krijgen.

@wopper heb jij IPv6 tunnels getest op de TC7210 en de Arris?

[wopper]

ANdrode schreef op dinsdag 30 juli 2019 @ 14:19:
[...]


Oef. Voor zover ik weet zijn er weinig mogelijkheden om een ander modem te krijgen.

Een TC7210 wordt nog geactiveerd door webcare als je er één hebt. Er is ook een nieuw en degelijk Ubee modem met DOCSIS 3.1 maar volgens mij is er geen gestandaardiseerd proces om zo'n modem te krijgen.

@wopper heb jij IPv6 tunnels getest op de TC7210 en de Arris?

Nope ik ben al een tijdje van IPv6 af, als Ziggo het ooit in bridge gaat ondersteunen dan join ik weer. Overigens is de Arris uit de html content degene welke ik nu ook gebruik. Ik ben er zeer tevreden over, had met oude modems nog wel eens dat het vooruit scrollen in filmcontent niet lekker ging. Daar heeft de Arris geheel geen last van.

Ondanks dat ik in het begin (software release 1) heel sceptisch was, nu tevreden.

[the7thstranger]

ANdrode schreef op dinsdag 30 juli 2019 @ 14:19:
Oef. Voor zover ik weet zijn er weinig mogelijkheden om een ander modem te krijgen.

Een TC7210 wordt nog geactiveerd door webcare als je er één hebt. Er is ook een nieuw en degelijk Ubee modem met DOCSIS 3.1 maar volgens mij is er geen gestandaardiseerd proces om zo'n modem te krijgen.

Ik zou op Marktplaats wel een TC7210 kunnen kopen. Maar ik woon in fUPC-gebied. Ik weet niet of ze die daar ooit hebben gebruikt. Ik ben best bereid om zelf een beter modem te regelen, alleen ik weet niet of ze daar niet moeilijk over gaan doen. Moet je dan nog een bepaalde medewerker zien te vinden?

Is er eigenlijk een technische beschrijving van hoe ze dan "nep" bridgemode dan implementeren op die Connectboxen? Daar ben ik wel benieuwd naar.

[the7thstranger]

Nu hopen dat degene die het hem uitlegde het voor het eerst een keer aan iedereen kan uitleggen..

[Groentjuh]

the7thstranger schreef op dinsdag 30 juli 2019 @ 15:31:
[Afbeelding]

Nu hopen dat degene die het hem uitlegde het voor het eerst een keer aan iedereen kan uitleggen..

Ik denk dat hij juist bedoeld: In bridge zit alles meestal nog steeds "veilig" achter NAT bij ipv4.

Dat zal echter niet zo zijn bij ipv6 en dan hangen alle apparaten met ipv6 ondersteuning binnen je hele lan ineens direct aan het internet zonder firewall of NAT. En dan zou best wel eens een beetje onveilig zijn voor sommige minder goed beveiligde apparatuur.

Ik geloof namelijk niet dat Ziggo hun interne systemen gevaar lopen door een modem in bridge met ipv6 profiel.

[the7thstranger]

@Groentjuh Dat zou toch helemaal een belachelijk argument zijn? Klanten die zelf expliciet kiezen voor IPv6 in bridge mode snappen echt wel dat ze zelf een stateful firewall moeten regelen in dat geval. En iedere degelijke router doet dat ook gewoon.

Bovendien krijgen LAN clients bij IPv6 in "Ziggo router mode" toch ook gewoon een publiek routeerbaar IP-adres?

Ik geloof best dat het waar kan zijn dat ze een rare routingtabel op hun modems in router mode zetten om zo te voorkomen dat je bij bepaalde Ziggo-systemen kunt komen. Dan droppen ze gewoon pakketten vanaf je modemrouter naar die subnets toe in plaats van dat ze zelf goed firewallen. Zo incompetent durf ik ze ondertussen echt wel te noemen..

[ANdrode]

Groentjuh schreef op dinsdag 30 juli 2019 @ 15:45:
[...]
Dat zal echter niet zo zijn bij ipv6 en dan hangen alle apparaten met ipv6 ondersteuning binnen je hele lan ineens direct aan het internet zonder firewall of NAT. En dan zou best wel eens een beetje onveilig zijn voor sommige minder goed beveiligde apparatuur.

Het is gebruikelijk om bij IPv6 stateful te filteren (RFC4864 samengevat door RFC6092):

The operational goals of security capabilities in Internet gateways
are described with more detail in "Local Network Protection for IPv6"
[RFC4864], but they can be summarized as follows.

o Check all traffic to and from the public Internet for basic
sanity, e.g., filter for spoofs and misdirected (sometimes called
"Martian") packets [RFC4949].

o Allow tracking of application usage by source and destination
network addresses and ports.

o Provide a barrier against untrusted external influences on the
interior network by requiring filter state to be activated by
traffic originating at interior network nodes.

o Allow manually configured exceptions to the stateful filtering
rules according to network administrative policy.

o Isolate local network DHCPv6 and DNS resolver services from the
public Internet.

the7thstranger schreef op dinsdag 30 juli 2019 @ 15:52:
Ik geloof best dat het waar kan zijn dat ze een rare routingtabel op hun modems in router mode zetten om zo te voorkomen dat je bij bepaalde Ziggo-systemen kunt komen. Dan droppen ze gewoon pakketten vanaf je modemrouter naar die subnets toe in plaats van dat ze zelf goed firewallen. Zo incompetent durf ik ze ondertussen echt wel te noemen..

Dat dit via SNMP modems in gepusht wordt in plaats van het interne netwerk goed te configureren geloof ik ook direct . Security boundary ligt net anders bij DOCSIS.

ANdrode wijzigde deze reactie 30-07-2019 15:53 (17%)

[the7thstranger]

Het lijkt dus echt zo te zijn. Man man man, wat erg..

[Dreamvoid]

the7thstranger schreef op dinsdag 30 juli 2019 @ 15:52:
Ik geloof best dat het waar kan zijn dat ze een rare routingtabel op hun modems in router mode zetten om zo te voorkomen dat je bij bepaalde Ziggo-systemen kunt komen. Dan droppen ze gewoon pakketten vanaf je modemrouter naar die subnets toe in plaats van dat ze zelf goed firewallen. Zo incompetent durf ik ze ondertussen echt wel te noemen..

Wellicht doen ze allebei - zowel firewall als routing tabellen bij de clients, defence-in-depth zeg maar?

Dreamvoid wijzigde deze reactie 31-07-2019 09:51 (24%)

[ANdrode]

the7thstranger schreef op dinsdag 30 juli 2019 @ 20:45:
[Afbeelding]

Het lijkt dus echt zo te zijn. Man man man, wat erg..

Maar waarschijnlijk gaat het om IPv4 adressen.

Wat een drama als het interne netwerk van ziggo (office.ziggo.nl?) echt alleen beschermt wordt door firewall regels in modems. Dit geloof ik bijna niet.

[the7thstranger]

Hoe zou dat om IPv4-adressen kunnen gaan dan? Ik heb nu gewoon IPv4 in bridge mode (met een WAN IP op m'n router).

Ik maak er toch uit op dat ze geen IPv6 bieden in bridge mode omdat er kennelijk een client-side egress firewall (of routingtabel die pakketten naar bepaalde subnets dropt) tussen moet zitten. En dan kunnen ze niet pushen naar eigen routers, dus dan zetten ze de hele dienst maar uit.

[ANdrode]

the7thstranger schreef op woensdag 31 juli 2019 @ 13:30:
Hoe zou dat om IPv4-adressen kunnen gaan dan? Ik heb nu gewoon IPv4 in bridge mode (met een WAN IP op m'n router).

In de implementaties die ik bekenen heb (De TC7210) was bridge mode softwarematig op layer 3, die alleen pakketten geadresseerd naar het publieke IP (en bij sommige modems broadcast verkeer) doorstuurt.

Ik verwacht dat egress filtering voor IPv4 geimplementeerd is bij bridge mode. Dat geeft geen garanties over dezelfde modems met bridge mode en IPv6

[the7thstranger]

@ANdrode Hoe heb je die implementatie kunnen bekijken? Is de broncode van Ziggo's firmware ergens gedumpt?

Weet je ook of er Ziggo-modems bestaan die wel een echte level 2 bridge-implementatie hebben? Wellicht dat ik dan kan gaan zeuren om er zo één te krijgen.

[ANdrode]

De broncode van Ziggo's firmware is niet beschikbaar. Binaries ook niet (maar ik zou wel interesse hebben).

Technicolor heeft firmwares publiek beschikbaar gemaakt.

Ik denk dat een echte L2 bridge niet mogelijk is door de architectuur van het netwerk (uitgangspunt dat CPE security/filtering doet).. Mogelijk zit hiervoor iets in EuroDOCSIS 3.0 of DOCSIS 3.1, tweede vraag is dan of dit uitgerold is.

ANdrode wijzigde deze reactie 31-07-2019 15:56 (11%)

[Freeaqingme]

SIDN: Zuid-Koreaanse en Vietnamese telco's doen grote IPv6-only-implementaties

[Dreamvoid]

464XLAT lijkt inderdaad de meest logische weg naar mobile IPv6, dat is inmiddels bij diverse telco's uitgerold. Je hebt dan idd geen eigen van buiten benaderbaar IPv4 adres meer, maar die heb je nu met de huidige IPv4-met-CGNAT ook niet.

De vraag is dan wel, zet de telco dan een IPv6 firewall tussen gebruiker en internet?

[ANdrode]

Dreamvoid schreef op vrijdag 2 augustus 2019 @ 10:35:
De vraag is dan wel, zet de telco dan een IPv6 firewall tussen gebruiker en internet?

Dat wordt sowieso aangeraden voor customer premises equipment

RFC6092 (informational RFC) raadt stateful filtering aan voor IPv6.

[Dreamvoid]

Lastig dus als je je huishouden vanachter een 4G router draait. Leuk dat je eindelijk een eigen (ongedeeld) IPv6 adres krijgt, maar als de ISP vervolgens de boel dichttimmert met een firewall kan je je eigen servers alsnog niet bereiken.

Dreamvoid wijzigde deze reactie 02-08-2019 21:43 (7%)

[ANdrode]

Dreamvoid schreef op vrijdag 2 augustus 2019 @ 21:42:
Lastig dus als je je huishouden vanachter een 4G router draait. Leuk dat je eindelijk een eigen (ongedeeld) IPv6 adres krijgt, maar als de ISP vervolgens de boel dichttimmert met een firewall kan je je eigen servers alsnog niet bereiken.

Aan de CPE kant, in dit geval dus in de 4G router.

Dat je port forwarding bewust moet aanzetten vind ik een goede trade-off tussen security en gemak voor een thuisgebruiker.

[Dreamvoid]

Dat snap ik, maar dat kan alleen als de telco niet zelf de boel aan hun kant ook firewalled.

[valkenier]

ANdrode schreef op woensdag 31 juli 2019 @ 13:26:
[...]


Maar waarschijnlijk gaat het om IPv4 adressen.

Wat een drama als het interne netwerk van ziggo (office.ziggo.nl?) echt alleen beschermt wordt door firewall regels in modems. Dit geloof ik bijna niet.

Er zit blijkbaar toch een of ander filter in de software van de modems. Ook in bridge. Wat ik er bij docsis.org over kan vinden is dit:

https://www.docsis.org/node/917

Helaas werken de links in dat draadje niet meer, maar het zou dus kunnen zijn dat er een aanpassing in het Ziggo netwerk moet plaatsvinden, voor dat IPv6 in bridge beschikbaar komt.

Ik weet niet helemaal hoe de Ziggo modems vanuit het Ziggonetwerk worden benaderd, maar het lijkt er op dat er naast het internet verkeer, ook nog een manier is om de interface van het modem te benaderen (bijvoorbeeld voor de klantenservice) die interface is voor de consument niet te benaderen, ook niet als het modem is gebridged. Daar zit denk ik een soort filter/firewall op, die dus mogelijk alleen voor IPv4 werkt.... zoiets?

[ANdrode]

valkenier schreef op zondag 4 augustus 2019 @ 13:57:
[...]
Er zit blijkbaar toch een of ander filter in de software van de modems. Ook in bridge. Wat ik er bij docsis.org over kan vinden is dit:

https://www.docsis.org/node/917

Goed gevonden . Wat ik snel over de upstream drop classifiers vond:

To simplify the filtering implementation in DOCSIS 3.1 cable modems, downstream filtering is only carried out in the CMTS and upstream filtering is carried out in the CM. A DOCSIS 3.1 CM is no longer required to support IP/LLC filters. All upstream filtering is to be done through Upstream Drop Classifiers (UDC), which also support IPv6 and provide better performance.

Het is dus echt zo ontworpen op protocolniveau. DOCSIS 3.1 vertrouwt de modems.

Ik weet niet helemaal hoe de Ziggo modems vanuit het Ziggonetwerk worden benaderd, maar het lijkt er op dat er naast het internet verkeer, ook nog een manier is om de interface van het modem te benaderen (bijvoorbeeld voor de klantenservice) die interface is voor de consument niet te benaderen, ook niet als het modem is gebridged. Daar zit denk ik een soort filter/firewall op, die dus mogelijk alleen voor IPv4 werkt.... zoiets?

Ik denk dat modems daar óf een extra extern IP voor hebben of dat dit met een IP filter werkt. In IPv4 bridge mode zou je kunnen kijken welke poorten gefilterd zijn – dan draait op één daarvan waarschijnlijk zo'n interface.

Het lijkt mij ook logisch als dit IP onafhankelijk is van het WAN-adres van een modem. Ze managen modems met SNMP (iirc) dus dan is een vast adres handig.

[the7thstranger]

@ANdrode Daarvoor krijgen modems een tweede IP in een interne range (10.8.0.0/16). Dat zie je gewoon in de webinterface bij de meeste modellen.

[ANdrode]

the7thstranger schreef op zondag 4 augustus 2019 @ 17:16:
@ANdrode Daarvoor krijgen modems een tweede IP in een interne range (10.8.0.0/16). Dat zie je gewoon in de webinterface bij de meeste modellen.

Horizon boxen kregen heel lang een publiek IPv4 adres (voor management?). Heb even geen Ziggo modem bij de hand om daar in de UI te kijken. Ik kan mij herinneren dat je meerdere "service flows" zag met brandbreedte limieten en elk waarschijnlijk een eigen ip.

In Nederland past dit - behalve als het echt heel goed met een ISP gaat - inderdaad prima in 10.0.0.0/8.

[Dreamvoid]

Een private IP adres dus, geen publiek?

[the7thstranger]

@Dreamvoid Alles dat ik heb gezien, was een private IP voor management inderdaad. Maar ik heb altijd alleen maar modems gehad; nooit van die mediaboxen of andere DRM-meuk.

Verder sluit ik niet uit dat ze die ranges nog natten van achter een access router of dat ze verschillende VLAN's gebruiken voor verschillende regio's en zo.

[ANdrode]

Vanochtend werd ik door T.net gethrottled nadat ik vanaf de bookmark pagina wat links aanklikte. Dit ging inderdaad wat snel maar was niet geautomatiseerd.

Bij IPv4 heb ik dit nooit gezien. Is iemand anders dit bij IPv6 tegengekomen?
Wel grote kans dat er vanuit de /48 veel meer gebruikers actief waren

[Raven]

ANdrode schreef op woensdag 14 augustus 2019 @ 09:42:
Vanochtend werd ik door T.net gethrottled nadat ik vanaf de bookmark pagina wat links aanklikte. Dit ging inderdaad wat snel maar was niet geautomatiseerd.

Bij IPv4 heb ik dit nooit gezien. Is iemand anders dit bij IPv6 tegengekomen?
Wel grote kans dat er vanuit de /48 veel meer gebruikers actief waren

Melden in Sorry, je gaat even iets te snel ? ?