Het grote IPv6 topic

[hkoster1]

RobertMe schreef op zondag 1 januari 2023 @ 21:18:
Ik heb relatief recentelijk Wireguard op gezet en ben nu ook maar aan het puzzelen met IPv6. Intussen werkt dat ook, door simpelweg aan beide kanten ("server" en "client") een IP adres binnen de prefix van de ISP te gebruiken. Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om? Ik neig nu zelf namelijk meer naar VPN op telefoon dan maar alleen te gebruiken als ik deze daadwerkelijk nodig heb (effectief dus: tijdelijk "thuis inloggen"), i.p.v. "altijd aan". Immers ben ik met "altijd aan" dan weer op het specifieke apparaat te tracken, wat de privacy extensions dan juist voorkomen.

In plaats van je echte ISP IPv6-prefix kun je toch adressen uit fd00::/8 gebruiken voor de Wireguard tunnel?

[RobertMe]

hkoster1 schreef op maandag 2 januari 2023 @ 12:11:
[...]

In plaats van je echte ISP IPv6-prefix kun je toch adressen uit fd00::/8 gebruiken voor de Wireguard tunnel?

Klopt, maar dan kan ik niet het internet op, terwijl dat dan wel mijn bedoeling zou zijn. Of ik moet NAT66 gaan toepassen, maar dat voelt dan ook raar.

[hkoster1]

Je kunt ook je Wireguard tunnel via een VPS-met-socat (als portmapper) sturen, daarmee wordt het Endpoint op je mobiele apparaat dat van de VPS, niet je thuisaansluiting.

[NogNeetMachinaa]

RobertMe schreef op maandag 2 januari 2023 @ 12:13:
[...]

Klopt, maar dan kan ik niet het internet op, terwijl dat dan wel mijn bedoeling zou zijn. Of ik moet NAT66 gaan toepassen, maar dat voelt dan ook raar.

Mja - maar dit lijkt wel de praktijk te (gaan?) zijn:
Private IPv6 adressen en die gaan NAT-en - analoog aan IPv4.

[Muis666]

RobertMe schreef op zondag 1 januari 2023 @ 21:18:
Ik heb relatief recentelijk Wireguard op gezet en ben nu ook maar aan het puzzelen met IPv6. Intussen werkt dat ook, door simpelweg aan beide kanten ("server" en "client") een IP adres binnen de prefix van de ISP te gebruiken. Alleen is het dan dus een statisch IP adres. En dat houd mij een beetje tegen om het daadwerkelijk te gebruiken (zeker "24/7") omdat het hele "privacy extensions" dan te vervallen komt. Hoe gaan anderen hier mee om? Ik neig nu zelf namelijk meer naar VPN op telefoon dan maar alleen te gebruiken als ik deze daadwerkelijk nodig heb (effectief dus: tijdelijk "thuis inloggen"), i.p.v. "altijd aan". Immers ben ik met "altijd aan" dan weer op het specifieke apparaat te tracken, wat de privacy extensions dan juist voorkomen.

Tja, dat is een nadeel van de huidige wireguard implementatie, alleen statische IPv6 adressen. Ik liep hier zelf ook tegenaan en accepteer het voorlopig maar.

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 10:56:
[...]


Eindelijk in de gelegenheid om wat testjes te doen. Bedankt voor je informatie en suggestie, maar in alle gevallen krijg ik zonder het gebruik van de optie om IPv6 via IPv4 aan te vragen alleen een link-local adres en werkt IPv6 op mijn LAN ook niet meer. De status van de WAN_DHCP6 is dan offline.
Glasnet is een fijne provider met prima support, maar er is erg weinig informatie verder over het gebruik van IPv6 icm pfSense, wat bijv. voor KPN wel te vinden is.

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

[NogNeetMachinaa]

Snow_King schreef op maandag 2 januari 2023 @ 12:31:
[...]

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

[Keiichi]

NogNeetMachinaa schreef op maandag 2 januari 2023 @ 13:07:
[...]


Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

Mijn config voor pfsense is als volgt:

KPN Wan interface: https://frankdebot.nl/tmp/tweaker/kpn-v6/kpnwan.png
LAN: https://frankdebot.nl/tmp/tweaker/kpn-v6/locallan.png

Op m'n LAN heb ik eigenlijk niet echt iets met configuratie vanuit de PD gedaan, gewoon een subnet gepakt. Volgens mij gooit KPN alle v6 pakjes in je /48 (of /56?) die je in je PD zitten krijgt gewoon op je lijn.

[Roetzen]

RobertMe schreef op maandag 2 januari 2023 @ 06:54:
[...]

Zoals bij IPv4 dus. Wel te traceren op aansluiting (IPv4 adres of IPv6 prefix), niet op individueel apparaat (want NAT verbergt het IP bij v4 en privacy extensions soort van bij v6).

Als een apparaat verbinding maakt met het internet zijn er voor iemand die dat wil zo veel mogelijkheden om van alles over dat apparaat te weten te komen en het te volgen, dat het m.i. vrij zinloos is om te proberen het IP adres te verbergen.

Care to elaborate? Een server zet sowieso vrijwel geen uitgaande verbindingen op dus zouden de privacy extensions al minder van toepassing zijn. En voor inkomende verbindingen zijn de privacy extensions nooit bedoeld geweest

Precies Van een server kun je het IP adres sowieso niet verbergen.

en heb je de statische suffix (die meestal op het MAC adres gebaseerd is?)

Alleen bij SLAAC. Er zijn meer mogelijkheden...

Tja je vroeg hoe anderen omgaan met privacy extensions. Mijn antwoord was: op een "vaste" aansluiting: niet.

[nero355]

Muis666 schreef op maandag 2 januari 2023 @ 12:30:
Tja, dat is een nadeel van de huidige wireguard implementatie, alleen statische IPv6 adressen.
Ik liep hier zelf ook tegenaan en accepteer het voorlopig maar.

Dus totaal geen DHCPv6/SLAAC mogelijkheden

Kan je tenminste de boel met je lokale netwerk bridgen en dan op die manier eromheen werken ?!

OpenVPN heeft bijvoorbeeld de keuze tussen TUN en TAP Interfaces die je verschillende mogelijkheden geven

[RobertMe]

nero355 schreef op maandag 2 januari 2023 @ 15:14:
[...]

Dus totaal geen DHCPv6/SLAAC mogelijkheden

Nope. Overigens ook geen DHCP op IPv4. Je moet de interface een of meerdere statische IP adressen geven, en aan de andere kant moet je ook expliciet aangeven welke IP adressen gerouteerd mogen worden naar die peer. Dus de "server" stel je statisch in met IP adres X. Vervolgens geef je meerdere peers op met bij elke peer een "Allowed IPs" die (minimaal) het statische IP van die peer moet matchen. Bij elke "client" geef je dan ook weer expliciet aan "de interface heeft IP Y" en dan dat er een peer is (zijnde de "server") en daarbij moet je dan ook weer een "Allowed IPs" opgeven die minimaal X bevat (of dus het volledige subnet, of meerdere subnets, of 0.0.0.0/0 en ::/0).

Kan je tenminste de boel met je lokale netwerk bridgen en dan op die manier eromheen werken ?!

Vast niet. Dan zou je alsnog de wg interface een vast IP moeten geven om vervolgens weer een bridge te maken met daarin de wg interface en daarop zou je dan SLAAC moeten toepassen? Geeft me al koppijn als ik er aan denk. Om nog maar te zwijgen over "hoe wil je dit in godsnaam op een telefoon doen".

OpenVPN heeft bijvoorbeeld de keuze tussen TUN en TAP Interfaces die je verschillende mogelijkheden geven

Maar TUN/TAP zijn user space dingen. Wireguard zit volledig in de kernel ingebakken. De wg command line tools sturen maar de kernel aan. En de wireguard config files staan ook zaken in die je zelf kunt doen zonder wireguard tools. Zo kun (/moet) je de interface aanmaken met ip link add dev wg0 type wireguard. De statische IP configuratie doe je met ip addr add ... de Allowed IPs zijn effectief de routes die dus door ip route beheert worden etc etc. wg gebruik je alleen om de Wireguard specifieke stuff te regelen, dus de private key, peers (met de public key, optionele endpoint, etc).

[nero355]

RobertMe schreef op maandag 2 januari 2023 @ 15:38:
- Nope.
- Overigens ook geen DHCP op IPv4.
- Vast niet.

Wat een crap systeem dan!

OpenVPN is echt lichtjaren verder wat betreft al die dingen dus je moet wel heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn (Dat is tenminste wat ik hier en daar lees ?!) om voor Wireguard te kiezen

[Streamert]

Snow_King schreef op maandag 2 januari 2023 @ 12:31:
[...]

Maar zie je ergens (in de logs?) welke prefix je krijgt zodra de DHCPv6 client de Prefix Delegation (PD) vraag heeft gedaan?

Die moet in een pool of iets terecht komen. Vervolgens kan je daar uit weer /64s uit delen.

pfSense doet niet veel anders dan andere routers zullen doen, dus het is echt een heel klein detail ergens.

Goeie vraag en ik had inderdaad gezocht, maar kon er geen kaas van maken, in ieder geval heb ik een stukje uit de PPP logs wat misschien interessant is, alleen ik kan er niets mee.

code:

Jan 2 19:18:16  ppp 99184   [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Add description "WAN"
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Rename interface ng0 to pppoe0
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Up event
Jan 2 19:18:13  ppp 99184   [wan] 020c:29ff:fedd:9a41 -> 0000:0000:00f1:282f
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: LayerUp
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Ack-Sent --> Opened
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPADDR 0.0.0.0
Jan 2 19:18:13  ppp 99184   [wan] IPCP: SendConfigReq #2
Jan 2 19:18:13  ppp 99184   [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 2 19:18:13  ppp 99184   [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan_link0] rec'd unexpected protocol MPLS Control Protocol (RFC 3032), rejecting
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Req-Sent --> Ack-Sent
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: SendConfigAck #1
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPCP: state change Req-Sent --> Ack-Sent

[Streamert]

NogNeetMachinaa schreef op maandag 2 januari 2023 @ 13:07:
[...]


Mja - hetzelfde ervaar ik hier ook met OpnSense.

Binnen het KPN-forum wordt prima uitgelegd wat KPN levert en wat daarvan vrij te gebruiken is. Maar aan OpnSense/pfSense is niet zo bar veel terug te vinden over de bijbehorende instellingen - zowel aan de WAN-kant als de LAN-kant.

Er schijnt in het verleden een XS4All artikel bestaan te hebben... iemand dat nog ergens heeft opgeslagen?

Inderdaad, handige voorbeelden zijn ten minste terug te vinden.

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 19:30:
[...]


Goeie vraag en ik had inderdaad gezocht, maar kon er geen kaas van maken, in ieder geval heb ik een stukje uit de PPP logs wat misschien interessant is, alleen ik kan er niets mee.

code:

Jan 2 19:18:16  ppp 99184   [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Add description "WAN"
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Rename interface ng0 to pppoe0
Jan 2 19:18:16  ppp 99184   [wan] IFACE: Up event
Jan 2 19:18:13  ppp 99184   [wan] 020c:29ff:fedd:9a41 -> 0000:0000:00f1:282f
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: LayerUp
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Ack-Sent --> Opened
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPADDR 0.0.0.0
Jan 2 19:18:13  ppp 99184   [wan] IPCP: SendConfigReq #2
Jan 2 19:18:13  ppp 99184   [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jan 2 19:18:13  ppp 99184   [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 2 19:18:13  ppp 99184   [wan_link0] rec'd unexpected protocol MPLS Control Protocol (RFC 3032), rejecting
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: state change Req-Sent --> Ack-Sent
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: SendConfigAck #1
Jan 2 19:18:13  ppp 99184   [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent)
Jan 2 19:18:13  ppp 99184   [wan] IPCP: state change Req-Sent --> Ack-Sent

Ben je een beetje begaan met SSH? Ik zou anders eens op de terminal van de router inloggen en daar in /var/log eens door wat logfiles gaan bladeren.

Dit moet echt ergens een kleine setting zijn. Zo lastig is het allemaal niet uiteindelijk, het zijn gewoon standaard protocollen die ook Glasnet gebruikt.

[NogNeetMachinaa]

Streamert schreef op maandag 2 januari 2023 @ 19:34:
[...]

Inderdaad, handige voorbeelden zijn ten minste terug te vinden.

Proef ik daar enige ironie...?

Unne dikke mercie - vrijwel zeker overheen gekeken!

[Streamert]

NogNeetMachinaa schreef op maandag 2 januari 2023 @ 20:37:
[...]


Proef ik daar enige ironie...?

Unne dikke mercie - vrijwel zeker overheen gekeken!

Totaal niet ironisch bedoeld, maar toen ik zoekende was kwam ik dit als beste voorbeeld tegen en dacht (natuurlijk) dat ik eindelijk de oplossing had.

[Streamert]

Snow_King schreef op maandag 2 januari 2023 @ 19:39:
[...]

Ben je een beetje begaan met SSH? Ik zou anders eens op de terminal van de router inloggen en daar in /var/log eens door wat logfiles gaan bladeren.

Dit moet echt ergens een kleine setting zijn. Zo lastig is het allemaal niet uiteindelijk, het zijn gewoon standaard protocollen die ook Glasnet gebruikt.

SSH is niet zo'n punt, anders kun je beter bij pfSense wegblijven, of elke andere *nix, maar als je een tail -f /var/log/dhcpd.log /var/log/ppp.log /var/log/system.log doet, krijg je niet veel meer info dan in de Status/System Logs sectie van de web interface, als ik me niet vergis?

[Snow_King]

Streamert schreef op maandag 2 januari 2023 @ 20:59:
[...]


SSH is niet zo'n punt, anders kun je beter bij pfSense wegblijven, of elke andere *nix, maar als je een tail -f /var/log/dhcpd.log /var/log/ppp.log /var/log/system.log doet, krijg je niet veel meer info dan in de Status/System Logs sectie van de web interface, als ik me niet vergis?

De dhcpd.log file is van de DHCP server, maar je wil juist de client hebben.

Maar als je met 'ifconfig -a' kijkt, krijg je WAN interface wel een IPv6 adres?

En ergens moet je iets kunnen vinden in de logs over een DHCPv6 lease met een prefix of iets dergelijks. Vooral even blijven zoeken.

[Streamert]

Snow_King schreef op dinsdag 3 januari 2023 @ 09:48:
[...]

De dhcpd.log file is van de DHCP server, maar je wil juist de client hebben.

Maar als je met 'ifconfig -a' kijkt, krijg je WAN interface wel een IPv6 adres?

En ergens moet je iets kunnen vinden in de logs over een DHCPv6 lease met een prefix of iets dergelijks. Vooral even blijven zoeken.

De WAN interface krijgt alleen een link-local adres, fe80... en fungeert dus als gateway in dit geval. De van oorsprong meegeleverde Vigor 2130 router voor Glasnet, ook nog even een test mee gedaan, krijgt op de WAN interface netjes een publiek IPv6 adres. Kan ik er dan vanuit gaan dat je in pfSense hetzelfde is?

[Snow_King]

Streamert schreef op dinsdag 3 januari 2023 @ 11:32:
[...]


De WAN interface krijgt alleen een link-local adres, fe80... en fungeert dus als gateway in dit geval. De van oorsprong meegeleverde Vigor 2130 router voor Glasnet, ook nog even een test mee gedaan, krijgt op de WAN interface netjes een publiek IPv6 adres. Kan ik er dan vanuit gaan dat je in pfSense hetzelfde is?

pfSense zou op de WAN ook een publiek IPv6 adres moeten krijgen. Daar zit in je instellingen dan het eerste probleem.

Dat moet je oplossen met:
- SLAAC
- DHCPv6 IA (Address verkrijgen)

Kan je in die Vigor 2130 iets van instellingen opvragen?

[Streamert]

Snow_King schreef op dinsdag 3 januari 2023 @ 12:31:
[...]

pfSense zou op de WAN ook een publiek IPv6 adres moeten krijgen. Daar zit in je instellingen dan het eerste probleem.

Dat moet je oplossen met:
- SLAAC
- DHCPv6 IA (Address verkrijgen)

Kan je in die Vigor 2130 iets van instellingen opvragen?

Ik ga voor de SLAAC/DHCPv6 toch nog een keer contact opnemen met support.

Helaas heb ik de Vigor inmiddels al weer teruggestuurd, maar het was lastig om vergelijkbare settings te vinden in een interface die zo totaal anders is, gezien de aard van het beestje.

In de tussentijd ben ik ook wel benieuwd hoe de configuraties van vergelijkbare ISP's eruit zien, zoals Telford en anderen. Ik vermoed dat we nog veel van elkaar kunnen leren.

[Snow_King]

Streamert schreef op dinsdag 3 januari 2023 @ 13:11:
[...]


Ik ga voor de SLAAC/DHCPv6 toch nog een keer contact opnemen met support.

Helaas heb ik de Vigor inmiddels al weer teruggestuurd, maar het was lastig om vergelijkbare settings te vinden in een interface die zo totaal anders is, gezien de aard van het beestje.

In de tussentijd ben ik ook wel benieuwd hoe de configuraties van vergelijkbare ISP's eruit zien, zoals Telford en anderen. Ik vermoed dat we nog veel van elkaar kunnen leren.

Al die configs zijn echt bijna identiek, zo veel spannends zit er niet in. Voor IPv4 heb je DHCP en voor IPv6 heb je de keuze uit SLAAC en DHCPv6.

DHCPv6 IA voor adres allocatie en PD voor Prefix Delegation.

[alm]

Heeft er iemand recente ervaring met een HE IPv6 tunnel die daar iets over kan zeggen qua stabiliteit/betrouwbaarheid/snelheid?

Ik ben mijn opties aan het verkennen nu hier in de buurt glasvezel van T-Mobile komt en zij alleen IPv4 leveren. Heb nu XS4All/KPN via VDSL en wil IPv6 niet kwijt mocht ik daarnaar overstappen.

[xbeam]

Misschien interessant om te kijken/volgen hoe deze ipv6 post/discussie zich onder zijn wereldwijd volgers gaat ontwikkelen.
[Embed: Tom Lawrence IPv6 discussion]

[Voor 54% gewijzigd door xbeam op 06-01-2023 09:50]

[fvbommel]

alm schreef op donderdag 5 januari 2023 @ 21:44:
Heeft er iemand recente ervaring met een HE IPv6 tunnel die daar iets over kan zeggen qua stabiliteit/betrouwbaarheid/snelheid?

Ik ben mijn opties aan het verkennen nu hier in de buurt glasvezel van T-Mobile komt en zij alleen IPv4 leveren. Heb nu XS4All/KPN via VDSL en wil IPv6 niet kwijt mocht ik daarnaar overstappen.

Ik heb dit enige tijd gebruikt na de overstap naar online.nl glasvezel (via Delta/Caiway).

Het werkte op zich prima, al kan het zijn dat het niet de volledige snelheid van de verbinding kon benutten (weet ik niet meer zeker, maar was in ieder geval niet problematisch traag of zo).

Het grotere probleem was de geolocatie: ondanks dat het in het systeem van HE geregistreerd stond als Amsterdam, waren verschillende streaming-diensten er niet blij mee.

We gebruiken hier toch al niet echt veel zulke diensten, maar ook de IPTV (via Canal Digitaal) konden hier blijkbaar niet mee omgaan waardoor hun TV-boxjes vaak niet werkten. Dit was een deal breaker, dus het staat nu alweer een hele tijd uit helaas. (Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

[alm]

fvbommel schreef op vrijdag 6 januari 2023 @ 09:45:
[...]


Ik heb dit enige tijd gebruikt na de overstap naar online.nl glasvezel (via Delta/Caiway).

Het werkte op zich prima, al kan het zijn dat het niet de volledige snelheid van de verbinding kon benutten (weet ik niet meer zeker, maar was in ieder geval niet problematisch traag of zo).

Het grotere probleem was de geolocatie: ondanks dat het in het systeem van HE geregistreerd stond als Amsterdam, waren verschillende streaming-diensten er niet blij mee.

We gebruiken hier toch al niet echt veel zulke diensten, maar ook de IPTV (via Canal Digitaal) konden hier blijkbaar niet mee omgaan waardoor hun TV-boxjes vaak niet werkten. Dit was een deal breaker, dus het staat nu alweer een hele tijd uit helaas. (Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

Da's wel een minpunt dan. Heb nu totaal geen issues met IPv6 gebruik. Ik neem aan dat je deze issues met native IPv6 bij de voorgaande provider niet had? Of had je nog geen IPv6 daarvoor?

[fvbommel]

Daarvoor had ik Ziggo, maar in former UPC gebied wat destijds nog betekende dat ik moest kiezen tussen IPv4-only of DS-Lite (IPv6 + IPv4, maar geen IPv4 port forwarding). Dus toen moest ik IPv6 uit laten zetten om poorten te kunnen openen op IPv4.

Ik heb daar geprobeerd een HE tunnel op te zetten, maar dat lukte niet zonder een PC in de DMZ te zetten (effectief zonder firewall vanuit het Internet) dus dat heb ik toen ook maar achterwege gelaten.

[nero355]

fvbommel schreef op vrijdag 6 januari 2023 @ 09:45:
(Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

Apart VLAN opzetten zodra je een fatsoenlijke Router koopt of bouwt!

[Freeaqingme]

Ik zat te kijken naar een Ziggo Internet Pro abonnement vanwege de SLA. Je hoort wel eens dat supportafdelingen zeggen "wij horen nooit iemand vragen naar ipv6", dus dat dacht ik even te doen.

17:26
Hallo,

Zit er bij een internet pro pakket ook IPv6?

Een goedemiddag Freeaqingme. U spreekt nu met $medewerker en ik help u graag met uw zakelijke vragen over zowel Ziggo als Vodafone 🙂 Goed dat u contact met ons opneemt. Dit is inderdaad standaard bij onze pro pakket.

Oke. En zijn die adressen ook vast?

Nee de IPV6 is voor intern. naar de buitenwereld is het IPV4 met 1 vast ip. Gaat u ook gebruik maken van wifi via ons apparatuur?

Nee, geen wifi. Maar, IPv6 is ook echt voor extern verkeer. Dus de vraag is of dat dan ook verandert, of dat je zolang het abonnement loopt hetzelfde ipv6-subnet behoudt

Dat is een goeie vraag. Ik vraag het even na voor de zekerheid. 1 moment

Dat klopt inderdaad, dat is ook voor extern en dat zal niet wijzigen.

Oke. En hoe groot is het subnet dat je krijgt toegewezen met een pro pakket?

17:37
Ik ga u even doorverbinden naar de afdeling waar ik zojuist mee sprak. Ik moet eerlijk bekennen dat ik hier niet de info voor in huis heb. 1 moment alstublieft.

17:47
ik: Oke

18:48
Ik: Hallo?

Denk dat dat doorverwijzen nog even gaat duren.

[Snow_King]

Freeaqingme schreef op dinsdag 10 januari 2023 @ 18:52:
Ik zat te kijken naar een Ziggo Internet Pro abonnement vanwege de SLA. Je hoort wel eens dat supportafdelingen zeggen "wij horen nooit iemand vragen naar ipv6", dus dat dacht ik even te doen.


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


[...]


Denk dat dat doorverwijzen nog even gaat duren.

Ik heb Ziggo Zakelijk Pro als thuisverbinding. Dit vanwege de SLA omdat ik 3 a 4 dagen in de week thuis werk en vanwege het vaste IPv6 subnet en IPv4 adres.

Je krijgt een opleverdocument met daar in:

- IPv4 /30 subnet om te configureren op je router (geen DHCP dus!)
- IPv6 /48 subnet (static)

De eerste /64 uit deze /48 wordt gebruikt voor Ziggo <> Jouw router en ze routeren dan de rest van de /48 naar het ::2 adres uit die /64.

Zowel het IPv4 als IPv6 subnet worden vervolgens in de RIPE database op jouw naam gezet.

[CAPSLOCK2000]

nero355 schreef op maandag 2 januari 2023 @ 16:22:
OpenVPN is echt lichtjaren verder wat betreft al die dingen dus je moet wel heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn (Dat is tenminste wat ik hier en daar lees ?!) om voor Wireguard te kiezen

Zo moet je het niet zien. Dat beide producten 'VPN' genoemd worden betekent niet dat ze hetzelfde doel hebben. We gebruiken de term 'VPN' tegenwoordig vooral in relatie met privacy maar dat hoeft niet. Wireguard heeft een ander doel en een andere aanpak.

Wireguard heeft juist het doel om minimalistisch te zijn. Doe één ding goed.
Wireguard heeft niet het doel om een totaal-oplossing te zijn voor alle use-cases die OpenVPN heeft.

Het enige wat Wireguard doet is pakketjes veilig van A naar B brengen, niet meer en niet minder.
In tegenstelling tot OpenVPN dat een totaalpakket probeer te leveren en dus ook een stukje routing doet, wat adresmanagement, hele netwerken kan tunnelen, een hoop authenticatiemethodes heeft, een management interface, wat privacy dingetjes en andere zaken die je van een totaalpakket verwacht.

Als OpenVPN precies doet wat je wil (en snel genoeg is) dan is er geen goede reden om over te stappen. Maar als OpenVPN niet goed past en te veel of te weinig doet dan heb je met Wireguard meer flexibiliteit.

Wat meer theoretisch zou je kunnen zeggen dat Wireguard veiliger is omdat het veel simpeler en daardoor overzichtelijker is. OpenVPN is veel groter en daar moet je dus veel meer beveiligen en controleren. Hoe simpeler een systeem is hoe minder kans op onvoorziene problemen of verstopte fouten.

heel erg aan de betere snelheden dan wel lichtere belasting van het systeem gehecht zijn

Onderschat niet hoe gigantisch groot het verschil is. Mijn router kan Wireguard op gigabit snelheid doen (en waarschijnlijk nog sneller, maar dat heb ik niet) terwijl OpenVPN moeite heeft om meer dan 20% van de verbinding te vullen terwijl de CPU staat te roken.

OpenVPN vs Wireguard is als MS Terminal Server versus SSH.

Ik gebruik Wireguard om mijn telefoon en mijn laptop te verbinden met mijn thuisnetwerk. Privacy speelt geen rol want het is allemaal van mij en ik hoef geen adressen voor mezelf te verbergen of zo iets.

Ook heb ik een commerciele VPN voor uitgaand verkeer dat Wireguard gebruikt. Dat gebruik ik bv als ik een Facebook-pagina "moet" bekijken en ik niet wil dat ze m'n vaste IP zien.


Ten derde heb ik een geneste VPN-verbinding naar mijn werk (de binnenste tunnel is overigens geen Wireguard). Dat is niet omdat ik mijn werkgever niet vertrouw maar omdat deel van mijn werk is dat mensen soms niet zo blij met me zijn, ook mensen met zeg maar meer technische skills dan ethiek. Het soort mensen dat niet bij ons in dienst is maar wel van binnenuit meekijkt.
Daarom stuur ik de VPN-verbinding naar mijn werkgever via een commerciele VPN-aanbieder.
Ik heb niet de illusie dat dit een waterdichte beveiliging is, wie gaat zoeken kan mijn IP echt wel vinden, maar iedere extra hobbel is er een.

In mijn thuisnetwerk heb ik aparte VLANs voor de verschillende uitgaande VPNs. Als je in zo'n vlan zit wordt al het uitgaande verkeer automatisch via VPN gerouteerd. Mijn router zit er tussen om te NATten want Wireguard doet alleen de point-to-point verbinding van mijn router naar die van de provider.

Ook verkeer uit andere VLAN's kan door mijn router onderschept worden en via een geschikt VPN naar buiten worden gestuurd.

Tegenwoordig doe ik dit dus met Wireguard maar vroeger gebruikte ik OpenVPN. Het enige waar ik nog geen alternatief voor heb is dat OpenVPN met profielen/accounts kan werken met verschillende configuraties. Dat gebruikte ik om mijn telefoon/laptop in een vlan naar keuze te kunnen zetten. Wireguard heeft geen concept van gebruikers of accounts. Ik denk dat het mogelijk is om Wireguard op verschillende poorten te laten luisteren en daar dan iets aan te knopen maar dat heb ik nog niet geimplementeerd.

[RobertMe]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 12:11:
Ik denk dat het mogelijk is om Wireguard op verschillende poorten te laten luisteren en daar dan iets aan te knopen maar dat heb ik nog niet geimplementeerd.

Dat is inderdaad geen probleem. Je kunt gewoon meerdere WG interfaces aanmaken en per interface bv ook andere routering en/of NATing inregelen.

[NogNeetMachinaa]

@CAPSLOCK2000 en @RobertMe - Hoe zou zo een vergelijking met IPsec er uit kunnen zien?

[CAPSLOCK2000]

NogNeetMachinaa schreef op woensdag 11 januari 2023 @ 13:04:
@CAPSLOCK2000 en @RobertMe - Hoe zou zo een vergelijking met IPsec er uit kunnen zien?

Wireguard zit vrij dicht bij ipsec maar ipsec kan meer. Wireguard is end-to-end. ipsec kan ook onderweg worden toegepast op pakketjes die worden doorgegeven.
Het nadeel van ipsec is dat het enorm complex is.

Daarbij is er een hardnekkig gerucht dat ipsec opzettelijk verzwakt is een geheime dienst die zich heeft bemoeit met het opstellen van de standaard. Dat is nooit bewezen maar door de enorme complexiteit van ipsec is dat ook erg lastig. Eigenlijk niemand begrijpt echt hoe het precies werkt en waarom bepaalde keuzes zijn gemaakt en hoe die elkaar beinvloeden.

Dat is een van de directe redenen waarom Wireguard is gegaan voor de minimalistische aanpak. In plaats van de eindeloos veel configuratieopties en flexibele encrpytiealgoritmes en backwards compatibility van ipsec is er juist bijna niks te kiezen bij wireguard. Er is van alles één en daarbij worden geen compromis geaccepteerd. Doe het goed of niet. Als er iets te kiezen is dan maken sommige mensen de verkeerde keuze. Daarom heeft Wireguard z'n best gedaan om een 'one-size-fits-all' oplossing te kiezen en zo veel mogelijk voor eenvoud gekozen boven flexibiliteit.

Omdat de tool maar één ding doet is dat gebrek aan flexbiliteit ook niet zo erg.

Pragmatisch gezien heeft ipsec het voordeel dat het vrij breed wordt ondersteunt en niet is gebonden aan één platform of leverancier.

[nero355]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 12:11:
Zo moet je het niet zien. Dat beide producten 'VPN' genoemd worden betekent niet dat ze hetzelfde doel hebben.

Tja, ik ben nog niet echt met Wireguard bezig geweest, maar door de vele directe vergelijkingen met OpenVPN en soms zelfs IPSec/L2TP en dergelijken kreeg ik wel de indruk dat ze allemaal hetzelfde moeten kunnen, maar blijkbaar is dat niet zo...

We gebruiken de term 'VPN' tegenwoordig vooral in relatie met privacy maar dat hoeft niet. Wireguard heeft een ander doel en een andere aanpak.

Ik ben niet zo van de hypes en door mijn werkervaring heb ik daar een heel ander beeld van, maar ook op dat gebied is het best wel vreemd dat men dan opeens ook Wireguard ging gebruiken ondanks de slechtere privacy en logging opties en weet ik het wat allemaal...

Het enige wat Wireguard doet is pakketjes veilig van A naar B brengen, niet meer en niet minder.
In tegenstelling tot OpenVPN dat een totaalpakket probeer te leveren en dus ook een stukje routing doet, wat adresmanagement, hele netwerken kan tunnelen, een hoop authenticatiemethodes heeft, een management interface, wat privacy dingetjes en andere zaken die je van een totaalpakket verwacht.

Maar dan nog : Doe daar een Bridged VPN Interface bij en je laat een hoop van die nadelen over aan de beheerder die ze vervolgens kan oplossen via allerlei alternatieven!

Onderschat niet hoe gigantisch groot het verschil is. Mijn router kan Wireguard op gigabit snelheid doen (en waarschijnlijk nog sneller, maar dat heb ik niet) terwijl OpenVPN moeite heeft om meer dan 20% van de verbinding te vullen terwijl de CPU staat te roken.

Precies mijn punt : Het lijkt net of er een heleboel mensen alle nadelen negeren puur vanwege de snelheid ?!

OpenVPN vs Wireguard is als MS Terminal Server versus SSH.

Niet mee eens, want SSH kan ook dingen als Tunneling en X-Forwarding wat je weer met VNC/RDP achtigen kan combineren!

Ook heb ik een commerciele VPN voor uitgaand verkeer dat Wireguard gebruikt. Dat gebruik ik bv als ik een Facebook-pagina "moet" bekijken en ik niet wil dat ze m'n vaste IP zien.

Dat is een hoop gedoe en geld voor zoiets simpels : Blokkeer gewoon alle advertenties en tracking zoveel mogelijk en dan ben je er ook grotendeels...

Als je toevallig ergens een VPS of Dedicated Server hebt staan dan zou je zelfs die voor zoiets kunnen misbruiken

Ten derde heb ik een geneste VPN-verbinding naar mijn werk (de binnenste tunnel is overigens geen Wireguard). Dat is niet omdat ik mijn werkgever niet vertrouw maar omdat deel van mijn werk is dat mensen soms niet zo blij met me zijn, ook mensen met zeg maar meer technische skills dan ethiek. Het soort mensen dat niet bij ons in dienst is maar wel van binnenuit meekijkt.
Daarom stuur ik de VPN-verbinding naar mijn werkgever via een commerciele VPN-aanbieder.
Ik heb niet de illusie dat dit een waterdichte beveiliging is, wie gaat zoeken kan mijn IP echt wel vinden, maar iedere extra hobbel is er een.

Tijd om van baan te wisselen

[CAPSLOCK2000]

nero355 schreef op woensdag 11 januari 2023 @ 17:05:
Tja, ik ben nog niet echt met Wireguard bezig geweest, maar door de vele directe vergelijkingen met OpenVPN en soms zelfs IPSec/L2TP en dergelijken kreeg ik wel de indruk dat ze allemaal hetzelfde moeten kunnen, maar blijkbaar is dat niet zo...

Er zijn wel degelijk flinke overeenkomsten, het is ook weer geen toeval dat ze zoveel vergeleken worden.

Ik ben niet zo van de hypes en door mijn werkervaring heb ik daar een heel ander beeld van, maar ook op dat gebied is het best wel vreemd dat men dan opeens ook Wireguard ging gebruiken ondanks de slechtere privacy en logging opties en weet ik het wat allemaal...

Kun je dat wat concreter maken? Ik neem aan dat je met "hype" doelt op de VPNs die op internet worden geadverteerd. Dat is inderdaad 90% hype. Niettemin hebben ze hun plek en nut maar je moet wel weten wat je doet. Het is geen tovermiddel.

slechtere privacy en logging opties

Welke privacy opties heb je in gedachte? Ik zie wat privacy betreft geen verschil tussen openvpn en wireguard.

Maar dan nog : Doe daar een Bridged VPN Interface bij en je laat een hoop van die nadelen over aan de beheerder die ze vervolgens kan oplossen via allerlei alternatieven!

Ik zie dat dus niet als nadeel maar als flexibiliteit.

Precies mijn punt : Het lijkt net of er een heleboel mensen alle nadelen negeren puur vanwege de snelheid ?!

Welke nadelen bedoel je precies? Niet dat wireguard geen nadelen heeft maar de meeste daarvan zijn zo technisch dat de meeste mensen daar geen boodschap aan hebben. OpenVPN kan wel meer maar dat zit meer in het gemak van de beheerder dan in de veiligheid van de gebruikers.

Niet mee eens, want SSH kan ook dingen als Tunneling en X-Forwarding wat je weer met VNC/RDP achtigen kan combineren!

Juist wel mee eens dus
Ik bedoel dat SSH zich vooral richt op het bouwen van die veilige tunnel en daar kunnen andere protocolen dan weer overheen gaan. Zo kan het onderdeel zijn van een grotere totaaloplossing.

Dat is een hoop gedoe en geld voor zoiets simpels : Blokkeer gewoon alle advertenties en tracking zoveel mogelijk en dan ben je er ook grotendeels...

Maar hoe blokkeer ik tracking van mijn vaste ip?

Als je toevallig ergens een VPS of Dedicated Server hebt staan dan zou je zelfs die voor zoiets kunnen misbruiken

Die heb ik maar die hebben ook vaste IP-adressen en zijn ook op verschillende andere manieren naar mij terug te herleiden.

Tijd om van baan te wisselen

Dat vraag je toch ook niet aan een motorcoureur die een helm opzet? Het vak is niet zonder risico's, daar mee om gaan hoort er bij.

Het zou best kunnen dat ik daar vroeg of laat genoeg van heb en iets anders ga doen. Voor de duidelijkheid, ik werk in IT-security en doe niks illegaals.

[nero355]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 17:27:
Kun je dat wat concreter maken? Ik neem aan dat je met "hype" doelt op de VPNs die op internet worden geadverteerd. Dat is inderdaad 90% hype. Niettemin hebben ze hun plek en nut maar je moet wel weten wat je doet. Het is geen tovermiddel.

Ik ben het meer eens met dit verhaal : https://gist.github.com/joepie91/5a9909939e6ce7d09e29

Welke privacy opties heb je in gedachte? Ik zie wat privacy betreft geen verschil tussen openvpn en wireguard.

Vanwege het ontbreken van willekeurige adressen en het een en ander op Logging gebied was er een VPN Provider die is gaan Dubbel NATten om zodoende het een en ander te verbergen!

Verder kan je een hoop dingen in [VPN] Ervaringen & Discussie - Deel 2 vinden over het verloop van de Wireguard adoptatie zeg maar...

Maar hoe blokkeer ik tracking van mijn vaste ip?

Niet

Of je moet puur IPv6 gebruiken met Privacy Adresses om maar een beetje ontopic te blijven

Die heb ik maar die hebben ook vaste IP-adressen en zijn ook op verschillende andere manieren naar mij terug te herleiden.

Jij bent echt serieus paranoïde zo te zien ?!

En ik maar denken dat ik in bepaalde opzichten overdreef...

Dat vraag je toch ook niet aan een motorcoureur die een helm opzet? Het vak is niet zonder risico's, daar mee om gaan hoort er bij.

Het zou best kunnen dat ik daar vroeg of laat genoeg van heb en iets anders ga doen. Voor de duidelijkheid, ik werk in IT-security en doe niks illegaals.

Sorry, maar het klinkt niet echt gezond, maar dat kan natuurlijk ook afhankelijk zijn van de manier waarop je alles bekijkt!

[CAPSLOCK2000]

nero355 schreef op woensdag 11 januari 2023 @ 17:54:
Ik ben het meer eens met dit verhaal : https://gist.github.com/joepie91/5a9909939e6ce7d09e29

Dat verduidelijkt wat, het gaat niet specifiek over Wireguard maar over VPN's in het algemeen.
Ik ben het eens met vrijwel alles op die pagina, samengevat: "Because a VPN in this sense is just a glorified proxy."

Ik weet heel goed hoe het werkt en wat de beperkingen zijn. Omdat ik een statisch IP heb heeft zo'n proxy voor mij in sommige gevallen wel zin.

Op zich ben ik helemaal voor dingen zelf hosten en doe dat ook. Ik heb ook VPSen die ik hier voor kan gebruiken. In dat geval gebruik ik overigens SSH als socks proxy, dat werkt out-of-the box met zo'n beetje iedere VPS die ssh draait.

Maar er is één feature van commerciele VPN-providers die ik zelf eigenlijk niet kan nadoen, exit nodes over de hele wereld. Soms is het handig om een Amerikaans, Brits, Chinees of Russisch IP-adres te hebben. In theorie kan ik natuurlijk 200 VPS'en inzetten of iets slims bedenken met een dynamische cloud dienst maar realistisch gezien is de een commerciele aanbieder een beter optie.

Vanwege het ontbreken van willekeurige adressen en het een en ander op Logging gebied was er een VPN Provider die is gaan Dubbel NATten om zodoende het een en ander te verbergen!

Zoals die pagina aangeeft moet je geen illusies hebben over het bijhouden van logs of anonimiteit ten opzichte van je VPN-provider. Dat doe ik dus niet.
Ik geloof ook niet dat willekeurig uitgedeelde adressen daar echt bij helpen als een kwaadwillende toegang krijgt. Die kijkt dan ook wel mee wie welk tijdelijk adres gebruikt.

Niet

Of je moet puur IPv6 gebruiken met Privacy Adresses om maar een beetje ontopic te blijven

Helaas ben je in praktijk nog steeds identificeerbaar omdat je het netwerkdeel van je adres wel constant is. Voor de meest doeleinden is dat goed genoeg.

Jij bent echt serieus paranoïde zo te zien ?!

Full-time professioneel en part-time hobbyist
Het is m'n vak dus ik kan het maar beter een beetje overdrijven.

Sorry, maar het klinkt niet echt gezond, maar dat kan natuurlijk ook afhankelijk zijn van de manier waarop je alles bekijkt!

Misschien schrijf ik het wat te sappig op maar er zijn wel meer beroepen die een zeker risico met zich meebrengen. Brandweerman, politieagent of prof-voetballer is ook niet zonder risico. Dat accepteer je als je voor zo'n beroep kiest, omgaan met die risico's hoort er bij. Juist als professional die de hele dag met het onderwerp bezig is kun je (nee, moet je) wat extra doen. De een begint 's ochtends met rekken en strekken, de ander controleert of de motoren nog onder z'n vliegtuig hangen, en ik begin met m'n yubikey in te steken.

[MrMarcie]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 18:21:
[...]

Dat verduidelijkt wat, het gaat niet specifiek over Wireguard maar over VPN's in het algemeen.
Ik ben het eens met vrijwel alles op die pagina, samengevat: "Because a VPN in this sense is just a glorified proxy."

Ik weet heel goed hoe het werkt en wat de beperkingen zijn. Omdat ik een statisch IP heb heeft zo'n proxy voor mij in sommige gevallen wel zin.

Op zich ben ik helemaal voor dingen zelf hosten en doe dat ook. Ik heb ook VPSen die ik hier voor kan gebruiken. In dat geval gebruik ik overigens SSH als socks proxy, dat werkt out-of-the box met zo'n beetje iedere VPS die ssh draait.

Maar er is één feature van commerciele VPN-providers die ik zelf eigenlijk niet kan nadoen, exit nodes over de hele wereld. Soms is het handig om een Amerikaans, Brits, Chinees of Russisch IP-adres te hebben. In theorie kan ik natuurlijk 200 VPS'en inzetten of iets slims bedenken met een dynamische cloud dienst maar realistisch gezien is de een commerciele aanbieder een beter optie.


[...]

Zoals die pagina aangeeft moet je geen illusies hebben over het bijhouden van logs of anonimiteit ten opzichte van je VPN-provider. Dat doe ik dus niet.
Ik geloof ook niet dat willekeurig uitgedeelde adressen daar echt bij helpen als een kwaadwillende toegang krijgt. Die kijkt dan ook wel mee wie welk tijdelijk adres gebruikt.


[...]

Helaas ben je in praktijk nog steeds identificeerbaar omdat je het netwerkdeel van je adres wel constant is. Voor de meest doeleinden is dat goed genoeg.


[...]

Full-time professioneel en part-time hobbyist
Het is m'n vak dus ik kan het maar beter een beetje overdrijven.


[...]

Misschien schrijf ik het wat te sappig op maar er zijn wel meer beroepen die een zeker risico met zich meebrengen. Brandweerman, politieagent of prof-voetballer is ook niet zonder risico. Dat accepteer je als je voor zo'n beroep kiest, omgaan met die risico's hoort er bij. Juist als professional die de hele dag met het onderwerp bezig is kun je (nee, moet je) wat extra doen. De een begint 's ochtends met rekken en strekken, de ander controleert of de motoren nog onder z'n vliegtuig hangen, en ik begin met m'n yubikey in te steken.

Dus wat is de oplossing? Eigen VPN op een VPS? Nogal wat werk lijkt me.
Stomme vraag misschien, maar geeft een DNS server al wat 'veiligheid' voor het afkijken van jouw ISP?

[NogNeetMachinaa]

@CAPSLOCK2000 - een uitgebreide toelichting "verpakt" in een mooi verhaal - unne dikke mercie voor alle moeite!

[Voor 7% gewijzigd door NogNeetMachinaa op 12-01-2023 17:41]

[CAPSLOCK2000]

MrMarcie schreef op donderdag 12 januari 2023 @ 17:23:
Dus wat is de oplossing?

Dat ligt er aan welk probleem je wil oplossen met een VPN. Mijn "probleem" is een statisch IP. Een VPN is voor mij een manier om even een ander IP te huren.

Eigen VPN op een VPS? Nogal wat werk lijkt me.

Dat ligt een beetje aan je achtergrond, voor mij is Wireguard een van de makkelijkere applicaties.

Stomme vraag misschien, maar geeft een DNS server al wat 'veiligheid' voor het afkijken van jouw ISP?

Dat is zo'n vraag waar je geen volmondig ja of nee op kan zeggen.
Aangezien het om veiligheid gaat is het korte antwoord dus "nee".

Klassiek DNS is niet versleuteld. Je ISP kan dus gewoon meekijken en eigenlijk precies zien wat je doet. Daar heb je dus eigenlijk niks aan als je ISP probeert om je te bespioneren.

Maar als we niet uitgaan van een kwaadaardige ISP maar van een luie/gemakzuchtige ISP dan helpt het een beetje omdat jouw verzoekjes dan niet in de logboeken van de ISP terecht komen.

Wat dat betreft zou een VPN een rol kunnen spelen om je DNS-verkeer te verbergen voor je ISP (maar niet voor de VPN provider).

Er zijn wel wat nieuwere varianten van DNS die wel proberen om je privacy te beschermen maar dat is een lastig onderwerp. Al is het maar dat je in veel gevallen niet eens in DNS-verkeer hoeft te kijken om te raden wat er staat want ze zijn enorm voorspelbaar. Als mijn computer een DNS-pakketje stuurt naar de DNS-server van geslachtsziekte.nl kan iedereen wel raden wat er aan de hand is.

Een bekende fout van VPN-gebruikers is overigens dat ze vergeten om ook hun DNS-verkeer via VPN sturen en zo alsnog aan hun omgeving laten lekken wat ze aan het doen zijn.

[MrMarcie]

CAPSLOCK2000 schreef op donderdag 12 januari 2023 @ 18:18:
[...]

Dat ligt er aan welk probleem je wil oplossen met een VPN. Mijn "probleem" is een statisch IP. Een VPN is voor mij een manier om even een ander IP te huren.


[...]

Dat ligt een beetje aan je achtergrond, voor mij is Wireguard een van de makkelijkere applicaties.


[...]

Dat is zo'n vraag waar je geen volmondig ja of nee op kan zeggen.
Aangezien het om veiligheid gaat is het korte antwoord dus "nee".

Klassiek DNS is niet versleuteld. Je ISP kan dus gewoon meekijken en eigenlijk precies zien wat je doet. Daar heb je dus eigenlijk niks aan als je ISP probeert om je te bespioneren.

Maar als we niet uitgaan van een kwaadaardige ISP maar van een luie/gemakzuchtige ISP dan helpt het een beetje omdat jouw verzoekjes dan niet in de logboeken van de ISP terecht komen.

Wat dat betreft zou een VPN een rol kunnen spelen om je DNS-verkeer te verbergen voor je ISP (maar niet voor de VPN provider).

Er zijn wel wat nieuwere varianten van DNS die wel proberen om je privacy te beschermen maar dat is een lastig onderwerp. Al is het maar dat je in veel gevallen niet eens in DNS-verkeer hoeft te kijken om te raden wat er staat want ze zijn enorm voorspelbaar. Als mijn computer een DNS-pakketje stuurt naar de DNS-server van geslachtsziekte.nl kan iedereen wel raden wat er aan de hand is.

Een bekende fout van VPN-gebruikers is overigens dat ze vergeten om ook hun DNS-verkeer via VPN sturen en zo alsnog aan hun omgeving laten lekken wat ze aan het doen zijn.

Dank je, duidelijk.
Als VPN gebruik in ExpressVPN (kan ik helaas niet in elke situatie gebruiken momenteel) die doen het op dat dns gebied ook goed. Die Wireguard ga ik eens mee aan de slag.

Ik heb een MikroTik hAP ax3 besteld, zie dat ik daar waarschijnlijk mee aan de slag kan met Wireguard. Zou mooi zijn, lost wat problemen op. Zeker als ik het per device kan instellen.

[Voor 8% gewijzigd door MrMarcie op 12-01-2023 22:00. Reden: MikroTik toegevoegd]

[ANdrode]

CAPSLOCK2000 schreef op woensdag 11 januari 2023 @ 13:38:
[...]
Daarbij is er een hardnekkig gerucht dat ipsec opzettelijk verzwakt is een geheime dienst die zich heeft bemoeit met het opstellen van de standaard. Dat is nooit bewezen maar door de enorme complexiteit van ipsec is dat ook erg lastig. Eigenlijk niemand begrijpt echt hoe het precies werkt en waarom bepaalde keuzes zijn gemaakt en hoe die elkaar beinvloeden.

Puur de complexiteit is eigenlijk een zwakheid. Zowel bij implementatie als bij configuratie kan men daardoor veel meer fouten maken.

Voor mijn gevoel is dat één van de drijfveren om naar "kleinere protocollen" te gaan.

[CAPSLOCK2000]

ANdrode schreef op zaterdag 14 januari 2023 @ 10:59:
Puur de complexiteit is eigenlijk een zwakheid. Zowel bij implementatie als bij configuratie kan men daardoor veel meer fouten maken.

Voor mijn gevoel is dat één van de drijfveren om naar "kleinere protocollen" te gaan.

Klopt, deel van de beschuldiging is dat ze het opzettelijk complex hebben gemaakt zodat er veel zwakke punten zijn. Maar eerlijk gezegd heb je daar geen geheime dienst voor nodig, de meeste programmeurs werken van nature al zo

Met een internationale groep vrijwilligers vanuit verschillende bedrijven, overheden en universiteiten samenwerken aan een standaard is al helemaal vragen om een draak van een ontwerp.

[ANdrode]

CAPSLOCK2000 schreef op zaterdag 14 januari 2023 @ 11:09:
[...]
Met een internationale groep vrijwilligers vanuit verschillende bedrijven, overheden en universiteiten samenwerken aan een standaard is al helemaal vragen om een draak van een ontwerp.

Daar ben ik het niet mee eens.

Het zit vooral in de cultuur toendertijd, waarbij er veel features aan protcollen werden toegevoegd zonder dat er een noodzaak voor was voor de primaire use case. Mijn gevoel is dat men daar nu anders in staat, men heeft van IPv6 en IPSEC geleerd.

[CAPSLOCK2000]

ANdrode schreef op zaterdag 14 januari 2023 @ 11:12:
Het zit vooral in de cultuur toendertijd, waarbij er veel features aan protcollen werden toegevoegd zonder dat er een noodzaak voor was voor de primaire use case. Mijn gevoel is dat men daar nu anders in staat, men heeft van IPv6 en IPSEC geleerd.

Beetje pijnlijk voorbeeld voor het IPv6-topic maar helaas heb je gelijk

Hoewel we een hoop geleerd hebben is er ook een hoop niet veranderd. Het is inherent moeilijk om met veel mensen samen te werken, zeker als die allemaal hun eigen belangen hebben. Ik kan helaas een hoop voorbeelden van moderne standaarden geven met hetzelfde probleem. USB, HDMI, WIFI, Bluetooth en GSM hebben allemaal in meer of mindere mate last van. Alleen al dat er verschillende generaties zijn maakt het logischerwijs steeds complexer.

Ik weet eerlijk gezegd niet hoe we er naar zouden kijken als ipsec nu als nieuw protocol zou worden geintroduceerd. Voor z'n tijd was het heel complex maar we hebben sindsdien wel een hoop meer ervaring opgebouwd met complexe software. Ondanks alle complexiteit wordt ipsec vrij breed ondersteunt en zijn er verschillende implementaties die onderling compatible zijn.
Hoe dan ook, het blijft een goed principe om ieder onderdeel zo simpel mogelijk te houden en niet meer te doen dan strict noodzakelijk. Dat woord "mogelijk" is wel belangrijk want wireguard is wel een stuk simpeler dan ipsec maar het kan ook minder. Gelukkig is het meestal genoeg.

[xbeam]

ANdrode schreef op zaterdag 14 januari 2023 @ 11:12:
[...]


Daar ben ik het niet mee eens.

Het zit vooral in de cultuur toendertijd, waarbij er veel features aan protcollen werden toegevoegd zonder dat er een noodzaak voor was voor de primaire use case. Mijn gevoel is dat men daar nu anders in staat, men heeft van IPv6 en IPSEC geleerd.

De tijd dat Office op een paar floppy’s stond en in de basis precies het zelfde kon als nu met enkele GigaBytes is al lang vervlogen.

[ANdrode]

CAPSLOCK2000 schreef op zaterdag 14 januari 2023 @ 11:44:
[...]
Ik weet eerlijk gezegd niet hoe we er naar zouden kijken als ipsec nu als nieuw protocol zou worden geintroduceerd. Voor z'n tijd was het heel complex maar we hebben sindsdien wel een hoop meer ervaring opgebouwd met complexe software. Ondanks alle complexiteit wordt ipsec vrij breed ondersteunt en zijn er verschillende implementaties die onderling compatible zijn.
Hoe dan ook, het blijft een goed principe om ieder onderdeel zo simpel mogelijk te houden en niet meer te doen dan strict noodzakelijk. Dat woord "mogelijk" is wel belangrijk want wireguard is wel een stuk simpeler dan ipsec maar het kan ook minder. Gelukkig is het meestal genoeg.

Men heeft geleerd en bijvoorbeeld de IAB (https://www.iab.org/) heeft hier vast dingen over geschreven. Mijn gevoel is dat er recenter meer een voorkeur voor een compacte standaard met ruimte voor uitbreiding is.

QUIC is complex en die complexiteit is alleen ontstaan door meerdere iteraties. Niet in één shot alle features en complexiteit implementeren.

[nero355]

ANdrode schreef op zaterdag 14 januari 2023 @ 13:05:
QUIC is complex en die complexiteit is alleen ontstaan door meerdere iteraties. Niet in één shot alle features en complexiteit implementeren.

QUIC moet dood! Dan ben je in één klap van alle ellende af!

Hetzelfde geldt voor HDMI-CEC trouwens!

[mash_man02]

fvbommel schreef op vrijdag 6 januari 2023 @ 09:45:
[...]


Ik heb dit enige tijd gebruikt na de overstap naar online.nl glasvezel (via Delta/Caiway).

Het werkte op zich prima, al kan het zijn dat het niet de volledige snelheid van de verbinding kon benutten (weet ik niet meer zeker, maar was in ieder geval niet problematisch traag of zo).

Het grotere probleem was de geolocatie: ondanks dat het in het systeem van HE geregistreerd stond als Amsterdam, waren verschillende streaming-diensten er niet blij mee.

We gebruiken hier toch al niet echt veel zulke diensten, maar ook de IPTV (via Canal Digitaal) konden hier blijkbaar niet mee omgaan waardoor hun TV-boxjes vaak niet werkten. Dit was een deal breaker, dus het staat nu alweer een hele tijd uit helaas. (Als iemand me kan vertellen hoe ik specifieke apparaten IPv4-only kan zetten op een Fritz!Box 5490 zou ik 't graag horen...)

Ik had exact ook deze ervaring met een HE tunnel. Inmiddels prefix delegation op meerdere subnetten draaien.

en ipv4 only selectief vanuit een router gaat niet lukken, je adverteerde de RA's of je doet het niet.

[Jay-B]

Je kan toch een IPv4 only VLAN opzetten?

[Raven]

@fvbommel @mash_man02 Pi-Hole die AAAA-requests van bepaalde domeinnamen blokkeert?

[Voor 16% gewijzigd door Raven op 19-01-2023 19:57]

[Snow_King]

Een vriend van mij neemt bij Detla Fiber Nederland nu deel in een IPv6 pilot. Krijgt nu een /56 subnet.

Dit kan enkel in het XPS-GPON netwerk, dat kan je zien aan het Nokia kastje in de meterkast.

Vermoed dat ze het wel snel gaan uitrollen op het GPON netwerk. P2P (Genexis kastje) is nog onbekend.

[ernstoud]

Snow_King schreef op donderdag 9 februari 2023 @ 14:36:
Een vriend van mij neemt bij Detla Fiber Nederland nu deel in een IPv6 pilot. Krijgt nu een /56 subnet.

Dit kan enkel in het XPS-GPON netwerk, dat kan je zien aan het Nokia kastje in de meterkast.

Vermoed dat ze het wel snel gaan uitrollen op het GPON netwerk. P2P (Genexis kastje) is nog onbekend.

Bij de laatste versie van de Genexis 7840 (AON - PtP noemt Delta dat), versie 3.16, lijkt e.e.a. voor IPv6 voorbereid te zijn.

[Snow_King]

ernstoud schreef op donderdag 9 februari 2023 @ 15:35:
[...]


Bij de laatste versie van de Genexis 7840 (AON - PtP noemt Delta dat), versie 3.16, lijkt e.e.a. voor IPv6 voorbereid te zijn.

Mooi, zou ook tijd worden. Dat men serieus een glasnetwerk is gaan bouwen zonder IPv6 in ~2021 vond ik toen al zeer merkwaardig.

Laten we verder maar niet over T-Mobile beginnen.

[EWS99]

Snow_King schreef op donderdag 9 februari 2023 @ 14:36:
Een vriend van mij neemt bij Detla Fiber Nederland nu deel in een IPv6 pilot. Krijgt nu een /56 subnet.

Dit kan enkel in het XPS-GPON netwerk, dat kan je zien aan het Nokia kastje in de meterkast.

Vermoed dat ze het wel snel gaan uitrollen op het GPON netwerk. P2P (Genexis kastje) is nog onbekend.

Hoe heeft hij zich aan kunnen melden voor die pilot? Ik zou daar ook wel aan mee willen doen! (ik heb XGS-PON met eigen modem)

[Voor 3% gewijzigd door EWS99 op 09-02-2023 15:45]

[Snow_King]

EWS99 schreef op donderdag 9 februari 2023 @ 15:45:
[...]


Hoe heeft hij zich aan kunnen melden voor die pilot? Ik zou daar ook wel aan mee willen doen! (ik heb XGS-PON met eigen modem)

Dit is een gesloten pilot.

[Voor 11% gewijzigd door Snow_King op 09-02-2023 19:41]

[Dreamvoid]

Snow_King schreef op donderdag 9 februari 2023 @ 15:37:
Mooi, zou ook tijd worden. Dat men serieus een glasnetwerk is gaan bouwen zonder IPv6 in ~2021 vond ik toen al zeer merkwaardig.

Delta is natuurlijk niet vanaf nul begonnen, als hun core netwerk nog geen IPv6 deed, dan was dat geen hindernis voor het aanleggen van nieuwe fysieke infrastructuur. Layer 1 versus Layer 3, etc.

[Voor 3% gewijzigd door Dreamvoid op 15-02-2023 16:04]

[Roetzen]

Stichting IPv6 heft zich zelf op.

https://www.stipv6.nl/202...6-nederland-heft-zich-op/

Hun prognose dat het nog tot 2030 zal duren voordat IPv6 een beetje doorbreekt lijkt me wat pessimistisch. Maar ja, de bijdrage van de stichting had misschien wel wat assertiever kunnen zijn. Ze wijzen nu vooral naar anderen. Dus misschien is het niet zo'n groot verlies dat die stichting de handdoek in de ring gooit.

[Dreamvoid]

Er zullen anno 2023 geen providers in Nederland meer zijn die nog info nodig hebben wat IPv6 is - iedereen heeft het ofwel al uitgerold, ofwel ergens in de planning zitten.

[Freeaqingme]

Als ik kijk op https://www.stipv6.nl/media/ dan zie ik dat de laatste publicatie in de media uit 2013 stamt - zo'n 10 jaar geleden. Ik kan me voorstellen dat het opheffen vooral met een gebrek aan tijd/inzet/publiciteit te maken heeft, en verder weinig van doen heeft met de acceptatie van IPv6.

[Maasluip]

Je kunt hier ook zien welk percentage van het IP verkeer v6 is. Net geen 5% gemiddeld.

[Snow_King]

Maasluip schreef op maandag 20 februari 2023 @ 08:38:
Je kunt hier ook zien welk percentage van het IP verkeer v6 is. Net geen 5% gemiddeld.

Dat is de AMS-IX, maar dat is echt geen representatie (meer) van het verkeer in NL.

Beter kan je kijken naar:
- https://www.google.com/intl/en/ipv6/statistics.html
- https://www.akamai.com/in...v6-adoption-visualization

Daar lopen de data van Google en Akamai wel uiteen, maar NL zit op 11% danwel 30%, maar je ziet dat Frankrijk, Belgie en Duitsland op >50% zitten.

Ook de US en India doen het goed, maar NL loopt echt hopeloos achter.

[easyriider]

Daarnaast heb je nog stats.labs.apnic.net, dat geeft het percentage gebruikers dat een IPv6 aansluiting heeft, dat is momenteel 48% in Nederland.

https://stats.labs.apnic.net/ipv6/NL

[Roetzen]

Snow_King schreef op maandag 20 februari 2023 @ 08:55:
[...]
Ook de US en India doen het goed, maar NL loopt echt hopeloos achter.

Het helpt niet dat Delta en ODF nu glasvezelnetwerken uitrollen waarop alleen nog maar IPv4 te krijgen is maar KPN, Ziggo en anderen doen het goed en het zijn niet de ISPs die nu de uitrol van IPv6 in Nederland vertragen. Het zijn de bedrijven.

De ironie wil dat er op security.nl een discussie loopt over IPv6 terwijl security.nl alleen via IPv4 bereikbaar is.

https://www.security.nl/posting/785739/

Een opmerking daarover lijkt niet door de moderatie te komen.

[Snow_King]

Roetzen schreef op maandag 20 februari 2023 @ 11:09:
[...]

Het helpt niet dat Delta en ODF nu glasvezelnetwerken uitrollen waarop alleen nog maar IPv4 te krijgen is maar KPN, Ziggo en anderen doen het goed en het zijn niet de ISPs die nu de uitrol van IPv6 in Nederland vertragen. Het zijn de bedrijven.

De ironie wil dat er op security.nl een discussie loopt over IPv6 terwijl security.nl alleen via IPv4 bereikbaar is.

https://www.security.nl/posting/785739/

Een opmerking daarover lijkt niet door de moderatie te komen.

En vergeet T-Mobile en Vodafone hun mobiele netwerken niet... Zoals ik eerder aangaf, Vodafone is er technisch helemaal klaar voor, hun billing alleen nog niet.

T-Mobile (ook hun glas, ODF), Vodafone en Delta samen zijn best een groot deel van het internet in NL. Dat zien we hier helaas terug.

Frankrijk doet dat met 5G bijvoorbeeld weer goed: https://www.arcep.fr/file...ition_to_IPv6_dec2020.pdf

Arcep introduced an obligation for operators who are awarded a licence to use 5G frequencies
in the 3.4 – 3.8GHz band in Metropolitan France to be IPv6 compatible8: “The licence-holder
is required to make its mobile network compatible with the IPv6 protocol as of 31 December
2020”.

[CAPSLOCK2000]

Enkele maanden geleden ben ik aan een stukje begonnen dat ik nooit heb afgemaakt en gepubliceerd. Omdat het nog steeds relevant is dump ik mijn draft hier in de hoop dat iemand het interessant vindt. Dit is geen wetenschappelijk onderzoek maar het resultaat van een uurtje opportunistisch door cijfermateriaal heen klikken. Ik claim geen accuraatheid en een deel van het cijfermateriaal is inmiddels verouderd, al geloof ik niet dat er iets is veranderd. Ik heb mijn beweringen niet doorgerekend of statistisch geanalyseerd.


Het begon met de vraag "Enig idee hoe het komt dat Nederland toch maar achter blijft lopen? Ik dacht dat Vodafone/Ziggo en KPN toch overal IPv6 aan hadden staan."


Dat "overal" aan staan is ook maar vrij relatief.

https://ip6.nl/#!list?db=access laat zien dat de meeste providers nog geen IPv6 hebben op hun eigen website en mailservers. Dan denk ik dat je de rest van de infrastructuur niet al te serieus kan nemen.


Mijn beide mobiele telefoons (KPN & T-Mobile) krijgen geen IPv6-adressen. Als dat representatief is dan is dat al genoeg om de de nationale score laag te houden.

Ik ben eens gaan graven en kwam uit bij https://ipv6-test.com/stats/country/NL .

Het eerste waar op wil wijzen is het grafiekje "Default browser protocol in Netherlands (dual-stack users)". Daarin zie je dat zelfs als IPv6 beschikbaar is in 15% van de gevallen er toch gebruikt wordt gemaakt van IPv4. Het is waarschijnlijk de browser die daar opzettelijk voor kiest. Over het waarom later meer.

Dan ga ik een klein stukje terug naar "Default browser protocol in Netherlands". Daarin zie dat slechts de helft van de gebruikers via IPv6 binnenkomt. Als we dat combineren met het voorgaande dan is de groep internet met IPv6 dus eigenlijk 15% groter. Dan kom ik er dus op uit dat zo'n 40% van de Nederlandse aansluitingen.

Op https://ipv6-test.com/stats/country/NL wordt een poging gedaan om data per provider uit te splitsen. Wat me daar onmiddelijk opvalt is Freedom best wel hoog in de lijst staat.

Volgens de ACM telecommonitor 2022-2 (https://public.tableau.co...t/viz/Telecommonitor/OVER) hebben KPN, Ziggo, T-Mobile en Delta samen 95% van de markt in handen en is Freedom dus kleiner dan 5%. Dan is die plek van Freedom helemaal indrukwekkend.

Nu is het we zo dat Freedom wel een zeer technisch publiek trekt en minder last heeft van oudere apparatuur, zo lang bestaan ze gewoon nog niet. Dus misschien ligt het wel aan de gebruikers en hun apparatuur.

Maar als je wat verder kijkt kom je bij "Default browser protocol in Netherlands (dual-stack users)". In die tabel kun je zien dat het verschil in IPv6-gebruik tussen Freedom, Ziggo en KPN slechts een paar procentpunt is. Freedom haalt de hoogste score maar dat is niet genoeg om het verschil te verklaren. Het verschil zit dus niet bij de gebruikers. Als er IPv6 beschikbaar is dan wordt het in gelijke mate gebruikt ongeacht de provider.


Mijn gevoel is dat de Nederlandse ISPs er niet zo'n zin in hebben en nog geen korte termijn voordelen ziet om ze te motiveren. Daarom doen ze het minimum waar ze weg komen om "van het gezeur" af te zijn en te kunnen zeggen dat ze IPv6 ondersteunen.

Om daar meer gevoel voor te krijgen ben ik eens gaan kijken hoe makkelijk het is om echte informatie over IPv6 te vinden. Technische informatie en niet het praatje van de marketingafdeling. Ik heb gekozen voor DNS-servers. Die zijn zo'n beetje de eerstvolgende stap na het aanbieden van kaal IPv6 op ip-niveau.

Op de website van Ziggo kan ik alleen IPv4-adressen vinden voor hun DNS-servers (ik ben geen klant dus wellicht zie ik niet alles). Ook op websites van andere providers kan ik ze zo snel niet vinden. Meestal vind ik die info uiteindelijk wel maar dan via een gebruikersforum of andere onofficiele bron. Freedom is weer de positieve uitzondering, daar vind ik zonder enige moeite een officiele pagina met DNS-instellingen waar ook de IPv6-adressen bij staan.
Als ik op IPv6 zoek is het eerste resultaat nog al eens "Hoe schakel ik ipv6 uit?"
Dat bevestigt mijn gevoel dat de providers er eigenlijk niet zo'n zin in hebben.

Maar dat is nog steeds geen heel bevredigend antwoord want waarom zou dat in andere landen anders zijn?
En als het aan de providers ligt, wat doen ze dan precies wel of niet?
We hadden al geconcludeerd dat het niet (alleen) bij de gebruikers of hun apparatuur zit, dus gebrekkig informatie vanuit de provider kan het probleem ook niet echt zijn.

Terug naar de data van ipv6-test.com.

Ik heb de data van verschillende "goede" ipv6 landen vergelijken met NL. Belgie, Frankrijk, Duitsland, Griekenland en Finland.
Het eerste wat me opvalt is dat de grafiek "IPv6 and v4 protocol support" nauwelijks verschilt, overal zit IPv6 op ongeveer 50%. Dat verbaast me, ik had een veel groter verschil verwacht. Blijkbaar zit er dus weinig verschil in hoeveel providers in ee land "iets" met IPv6 doen én weinig verschil tussen de ISPs binnen een land? Wat dan wel?

Dan komen we bij de "default browser protocol" grafiekjes van ipv6-test.com waar we het al eerder over hadden.
Zou het verschil hier zitten?
Waarempel, er is een opvallend verschil te zien tussen NL en de "goede" landen. In NL wordt in een dual-stack configuratie in 15% van de gevallen voor IPv4 gekozen, in de andere landen minder van 5%. Dat verschil is dan weer veel groter dan ik verwachtte.

Hoe kan dat? Waarom en hoe kiest een browser IPv4 of IPv6 als beide beschikbaar zijn? Het eerste deel van het antwoord is dat IPv6 de voorkeur heeft op alle moderne systemen. Het gaat dus eigenlijk om de vraag waarom een browser er voor kiest om IPv4 te gebruiken. Volgens mij is dat een algoritme genaamd "happy eyeballs". In het kort werkt dat algoritme door zowel een IPv4- áls IPv6-verbinding te beginnen en verder te gaan met het algoritme dat het snelste antwoord. Als je IPv6-verbinding langzamer is dan je IPv4-verbinding zal je browser dus IPv4 gaan gebruiken. Kan dat de verklaring zijn?

Tot mijn blijdschap blijkt de volgende grafiek van ipv6-test.com daar inzicht in, namelijk de grafiek "Downstream bandwidth". Die grafiek laat zien of IPv6 net zo snel is als IPv4. In die grafieken zie ik weer een verschil tussen NL en de "goede" landen. NL zat heel lang rond de 80% (al is het de afgelopen 2 jaar fors verbeterd) terwijl de goede landen boven de 95% zitten als het niet rond 100% is.

Daarmee heb ik eindelijk een theorie wat er aan de hand is. NL deelt wel IPv6-adressen uit maar IPv6-verbindingen zijn langzamer. Daarom kiest de browser er voor om IPv4 te doen.

Dat roept natuurlijk direct de volgende vraag op: waarom is dat zo?
Daar krijg ik het moeilijk en nu wordt het dus echt 100% speculatie.
Ik denk dat het voor een deel komt doordat providers minder aandacht/geld investeren in IPv6 apparatuur en routes waardoor het (marginaal) langzamer is.
In andere landen merk je daar echter niet zo veel van omdat je daar tegen andere bottlenecks aanloopt. In NL zijn de netwerken echter zo compact en goed verbonden dat kleine verschillen in snelheid tussen IPv4 en IPv6 hier meer invloed hebben op het "happy eyeballs" algoritme.


Dat was 'em. Nogmaals, dit is leunstoelwetenschap en ik ben helemaal niet tevreden met die conclusie want die is flinterdun. Excuses voor alle fouten die er ongetwijfel in zitten, het is een niet uitgewerkt draft. Niettemin vind ik de data interessant genoeg om het toch te willen delen. Misschien dat het iemand anders op een beter idee brengt.

[nero355]

CAPSLOCK2000 schreef op dinsdag 21 februari 2023 @ 17:46:
Nu is het we zo dat Freedom wel een zeer technisch publiek trekt.

Dus misschien ligt het wel aan de gebruikers en hun apparatuur.

Heeft denk ik direkt te maken met dit :

Om daar meer gevoel voor te krijgen ben ik eens gaan kijken hoe makkelijk het is om echte informatie over IPv6 te vinden. Technische informatie en niet het praatje van de marketingafdeling.
Ik heb gekozen voor DNS-servers.

Op de website van Ziggo kan ik alleen IPv4-adressen vinden voor hun DNS-servers (ik ben geen klant dus wellicht zie ik niet alles). Ook op websites van andere providers kan ik ze zo snel niet vinden. Meestal vind ik die info uiteindelijk wel maar dan via een gebruikersforum of andere onofficiele bron.

Freedom is weer de positieve uitzondering, daar vind ik zonder enige moeite een officiele pagina met DNS-instellingen waar ook de IPv6-adressen bij staan.
Als ik op IPv6 zoek is het eerste resultaat nog al eens "Hoe schakel ik ipv6 uit?"
Dat bevestigt mijn gevoel dat de providers er eigenlijk niet zo'n zin in hebben.

Providers hebben helemaal geen zin om al die informatie op hun website te publiceren, want de houding lijkt bij de meesten het volgende te zijn : "Laat die domme consumenten maar gewoon onze apparatuur gebruiken en alles zoveel mogelijk op Auto/Automatisch laten staan en als ze dat niet willen dan hebben ze pech!"

Zo kon ik niet eens de IPv4 DNS Servers van Caiway vinden, totdat die hele toestand omtrent de eigen apparatuur gebruiken wet eindelijk werd ingevoerd!

Ondertussen had KPN die al jarenlang op hun website staan...

[Hipska]

CAPSLOCK2000 schreef op dinsdag 21 februari 2023 @ 17:46:

Dat roept natuurlijk direct de volgende vraag op: waarom is dat zo?
Daar krijg ik het moeilijk en nu wordt het dus echt 100% speculatie.
Ik denk dat het voor een deel komt doordat providers minder aandacht/geld investeren in IPv6 apparatuur en routes waardoor het (marginaal) langzamer is.
In andere landen merk je daar echter niet zo veel van omdat je daar tegen andere bottlenecks aanloopt. In NL zijn de netwerken echter zo compact en goed verbonden dat kleine verschillen in snelheid tussen IPv4 en IPv6 hier meer invloed hebben op het "happy eyeballs" algoritme.

Dat idee zou kunnen gestaafd worden door verschillende Ping en traceroutes te doen naar gekende instanties over v4 en v6 vanaf een NL ISP eindpunt.

[CAPSLOCK2000]

Hipska schreef op woensdag 22 februari 2023 @ 08:39:

Dat idee zou kunnen gestaafd worden door verschillende Ping en traceroutes te doen naar gekende instanties over v4 en v6 vanaf een NL ISP eindpunt.

Dat was/is mijn plan maar het is er de afgelopen maanden niet van gekomen.
Volgens mij kun je veel van die info al boven halen uit reeds bestaande bronnen zoals de Atlas Probes van RIPE.

[Dreamvoid]

Zo complex hoe je het ook weer niet te analyseren: IPv6 in Nederland betekent feitelijk kijken naar vier vaste netwerken:
- Ziggo
- KPN
- T-Mobile Thuis
- Delta

En drie mobiele netwerken:
- KPN
- Vodafone
- T-Mobile

Er zijn honderden kleine netwerken in Nederland maar voor de grote cijfers doen die er niet toe: niemand boeit het dat de computers op het interne LAN bij Bob’s Bowling Paleis geen IPv6 hebben.

Op het moment hebben Ziggo en KPN op het vaste net IPv6, en KPN op mobiel. Die zijn nooit 100% aangezien veel klanten nog een oude box of telefoon hebben, maar moderne apparatuur doet IPv6 op die netwerken.

[nero355]

Dreamvoid schreef op zondag 26 februari 2023 @ 11:10:
Niemand boeit het dat de computers op het interne LAN bij Bob’s Bowling Paleis geen IPv6 hebben.

LOL!

Op het moment hebben Ziggo en KPN op het vaste net IPv6, en KPN op mobiel. Die zijn nooit 100% aangezien veel klanten nog een oude box of telefoon hebben, maar moderne apparatuur doet IPv6 op die netwerken.

Je moet wel een heeeele oude telefoon hebben die geen IPv6 kan, want zelfs een aantal serieus oude telefoons die ik heb gezien hadden een IPv6 Status dingetje ergens in de GUI van het OS staan!

Hoe goed/slecht IPv6 daarop werkt is uiteraard weer een verhaal apart...

[Tomsworld]

Ik weet niet waar dit marketing team zit maar ...

https://twitter.com/meraki/status/1629213080985935873

Wetende dat het lang geduurd heeft voor Meraki ipv6 begreep, en het nog maar twijfelachtig is.

[Dreamvoid]

nero355 schreef op zondag 26 februari 2023 @ 22:10:
Je moet wel een heeeele oude telefoon hebben die geen IPv6 kan, want zelfs een aantal serieus oude telefoons die ik heb gezien hadden een IPv6 Status dingetje ergens in de GUI van het OS staan!

Hoe goed/slecht IPv6 daarop werkt is uiteraard weer een verhaal apart...

Dat is het niet zozeer, normaal gesproken testen mobiele operators hun IPv6 netwerk met een bepaalde Android/iOS versie (de dan meest recente), en pushen vervolgens alleen naar die versie-of-nieuwer een IPv6 APN. Dus ook al hebben bv iOS 14 en Android 11 prima IPv6 support, ze gaan het nooit (automatisch) krijgen op een hoop mobiele netwerken.

Idem met provider boxes: er zijn een hoop oude boxes die op zich wel IPv6 doen, maar providers testen alleen de huidige box grondig, en rollen alleen IPv6 uit naar die box, niet de verouderde modellen die nog bij honderdduizenden klanten liggen. Dat is puur een werkbesparende maatregel: je wil geen troubleshooting/bugfixing energie meer stoppen in oude produkten. Over tijd lost het probleem zichzelf toch op, en het maakt een provider op dit moment niet bijster veel uit of er nou 1%, 10% of 20% van zijn klanten op IPv4 blijft hangen, zolang maar een significant deel over IPv6 gaat lopen, en het gestaag blijft groeien.

[Hipska]

Tomsworld schreef op zondag 26 februari 2023 @ 22:12:
Ik weet niet waar dit marketing team zit maar ...

https://twitter.com/meraki/status/1629213080985935873

Wetende dat het lang geduurd heeft voor Meraki ipv6 begreep, en het nog maar twijfelachtig is.

Had ik ook zien passeren https://twitter.com/Hipska/status/1629373644584501248
Ondertussen is de originele tweet wel verdwenen.

[dovo]

Hipska schreef op maandag 27 februari 2023 @ 12:05:
[...]

Ondertussen is de originele tweet wel verdwenen.

Wat was het bericht/context?

Voor zover ik kan zien in de release notes staat
New MS 15.20 stable release candidate firmware - fixes routing table er on stacks when deleting SVIs (archived)
.. IPv6 static routing support .. IPv6 management interface support

Zelf heb ik maar heel weinig ervaring met meraki. Ooit op een vorige werkplaats eens een e-waste container vol met meraki hardware gezien, opgezocht of je deze kon OpenWRT flashen en een tweede leven geven. Maar blijkbaar is zelfs de hardware geen standaard ARM/MIPS/... en bestaan er geen alternatieve firmwares. Dus heb deze container mooi laten staan. Leuk voor het milieu zo een ephemeral hardware.
Networking wise - IIRC doet Meraki iets geks met 10.0.0.0/8 + MAC om zo het concept van SLAAC bij IPv6 op IPv4 te kunnen doen. Als je dan een Meraki Wifi AP gebruikt, en je VPN geeft je access naar een RFC1918 uit 10.0.0.0/8, pech! Want Meraki configureert de hele /8 als broadcast domain.

[Mattie112]

Zijn hier meer mensen met een ipv6 tunnel van HurricaneElectric(/tunnelbroker)? Ik heb sinds een aantal dagen best wel wat packetloss (atm ~12%). Merkte al dat het internet "traag" was en met het uitzetten van ipv6 weer even goed. Denk zal ff kijken hoe of wat en ja met die packetloss kan ik het me wel voorstellen.

[Raven]

@Mattie112 De server in Amsterdam lag er pas uit, misschien heeft het daarmee te maken? Was op https://tunnelbroker.net/status.php terug te zien.

[MPvDam]

Mattie112 schreef op donderdag 9 maart 2023 @ 09:45:
Zijn hier meer mensen met een ipv6 tunnel van HurricaneElectric(/tunnelbroker)? Ik heb sinds een aantal dagen best wel wat packetloss (atm ~12%). Merkte al dat het internet "traag" was en met het uitzetten van ipv6 weer even goed. Denk zal ff kijken hoe of wat en ja met die packetloss kan ik het me wel voorstellen.

Ik heb ook een tunnel van HE en de laatste dagen veel packet loss. De hoop is dat Delta/Caiway snel IPv6 aan gaat zetten op het glasvezel netwerk.

[Raven]

Mattie112 schreef op donderdag 9 maart 2023 @ 09:45:
Zijn hier meer mensen met een ipv6 tunnel van HurricaneElectric(/tunnelbroker)? Ik heb sinds een aantal dagen best wel wat packetloss (atm ~12%). Merkte al dat het internet "traag" was en met het uitzetten van ipv6 weer even goed. Denk zal ff kijken hoe of wat en ja met die packetloss kan ik het me wel voorstellen.

Mocht je net als ik weer problemen hebben:

tserv11.ams1 Amsterdam, NL Down

, * Raven doet IPv6 maar even uitzetten.

[Roetzen]

Raven schreef op zaterdag 11 maart 2023 @ 17:59:
[...]

Mocht je net als ik weer problemen hebben:

[...]

, * Raven doet IPv6 maar even uitzetten.

Misschien moeten we ons er maar op voorbereiden dat er een keer een eind aan komt. Niets is nu eenmaal eeuwig en ik heb me jaren geleden al afgevraagd hoe lang Huricane Electric deze voortreffelijke gratis dienst nog blijft aanbieden. Ik kan me voorstellen dat ze in navolging van SixXs een keer zeggen: "Het is mooi geweest, nu is het aan de providers".

[Mattie112]

Heb mn IPv6 maar weer ff aan gezet, eens kijken of het beter is.

Helaas "moet" ik wel HE gebruiken. T-mobile heeft nog steeds geen IPv6.... (en tja is het nodig naja niet 100% maar ik moet toch soms wel eens wat testen wat over IPv6 gaat haha). Misschien toch maar 1 van mijn vpsjes in gaan richten als IPv6 endpoint ofzo..... Zou best een paar euro willen betalen voor HE, wel mooie dienst zo met rDNS delegation etc

[xbeam]

Het werd eens tijd!

MS waarschuwing Vanuit de azure AD customer beheer portal.

Upcoming IPv6 deployment
Organizations that use named locations in Conditional Access or Identity Protection must take action as soon as possible to avoid any service impact.

https://learn.microsoft.c...ory/azure-ad-ipv6-support

[Voor 7% gewijzigd door xbeam op 13-03-2023 18:23]

[Snow_King]

xbeam schreef op zondag 12 maart 2023 @ 21:06:
MS waarschuwing Van de azure AD customer beheer portal:-) Het werd eens tijd!

[...]

https://learn.microsoft.c...ory/azure-ad-ipv6-support

Fijn dat ze het eindelijk doen!

Wel heb ik weer 3 weken moeten wachten op IPv6 aan te laten zetten voor inbound mail op Office365 voor een domein. Wat zonde van de tijd....

[Snow_King]

https://research.hktdc.com/en/article/MTMyMzc4NDY4OA


Vanaf Juli 2023 moet in Kenia alle apparatuur die verkocht wordt IPv6 ondersteunen :-)

[Keiichi]

Snow_King schreef op donderdag 16 maart 2023 @ 20:56:
https://research.hktdc.com/en/article/MTMyMzc4NDY4OA


Vanaf Juli 2023 moet in Kenia alle apparatuur die verkocht wordt IPv6 ondersteunen :-)

Zou het niet gewoon zijn dat het probleem met opraken van v4 adressen groter is dan hier, waardoor ze er wel aan moeten en dat consumenten op deze manier een stok achter de deur hebben als ze apparatuur krijgen die niet werkt?

[xbeam]

Keiichi schreef op donderdag 16 maart 2023 @ 21:06:
[…]
Zou het niet gewoon zijn dat het probleem met opraken van v4 adressen groter is dan hier, waardoor ze er wel aan moeten en dat consumenten op deze manier een stok achter de deur hebben als ze apparatuur krijgen die niet werkt?

Waarschijnlijk meer vanwege het beleid om Nariobi de tech hoofdstad van Afrika /niet westerse wereld te maken.
https://kenyan-post.com/2...e-tech-capital-of-africa/

Is Nairobi Set to Be the Tech Capital of Africa?
When you think about the world’s tech hubs often the first place that comes to mind is California’s Silicon Valley. After all, this is where all the true giants of the sector started out and continue to thrive. But, thousands of miles away in East Africa, there’s another exciting center for tech development that is going from strength to strength.
[…]
Silicon Savannah
The industry is focused on an area in Nairobi which has been dubbed “the Silicon Savannah”. This has rapidly grown to be the biggest

[Voor 40% gewijzigd door xbeam op 17-03-2023 00:27]

[RobertMe]

RobertMe schreef op zaterdag 26 februari 2022 @ 14:36:
[...]

offtopic:
Op basis van jouw post ook hier even geprobeerd, met de Ubee U1318 (de ZG is natuurlijk de Ziggo uitvoering en niet echt onderdeel van het model), en verrek, dat werkt inderdaad. Geeft wel wat leuke ideetjes zoals het gasten VLAN over de andere verbinding te laten lopen, en hetzelfde voor IoT etc.. Toch weer net dat beetje veiliger met bv prive VPS met IP restricties die nu natuurlijk omzeild zouden worden door apparaten op bv het gast VLAN, en daarnaast dan met het thuiswerken hier en daar wat services van het werk waar mijn IP staat ingesteld.
Leuk om eens mee te experimenteren of ik mijn UniFi Security Gateway dan hiermee kan instellen. LAN2 van het modem naar WAN2 op de USG en dan kijken of ik dus bv het gast VLAN over WAN2 kan laten lopen.

Overigens leek mijn laptop gewoon een publiek IPv6 adres te ontvangen op dan LAN2 poort van het modem. Of vervolgens DHCP-PD een volledig eigen range oplevert heb ik niet gekeken.

Deze gek is het blijkbaar ooit gelukt om op een tweede poort van het Ziggo modem zowel een IPv4 als IPv6 adres te krijgen. Nu ondergetekende gek dit probeert krijgt hij echter alleen een IPv4 adres en geen IPv6 adres. Weet iemand toevallig dus of Ziggo wel / niet nog alleen IPv4 en geen IPv6 uitdeelt op de/een additionele poort? Heb een laptop als test gebruikt, prik ik de kabel gewoon in een switch krijgt die meteen een IPv6 adres. Maar een mismatch in DHCPv6 vs router advertisement verhaal zou natuurlijk ook kunnen. Reden dat ik het vraag is omdat ik een TopTon "zachte router" onderweg heb van Ome Ali. En zou dan wel zo fijn zijn als ik die eerst kan opzetten zonder mijn bestaande router te disconnecten En dan is het wel zo handig als ik zowel IPv4 als IPv6 meteen kan fixen. * RobertMe doet nu al iets met IPv6 op bestaande router, USG. Maar wil "meer", dus daarom de USG er maar eens uitgooien en voor volledige zelfbouw gaan (ook geen *sense etc).

[ReBr]

Mattie112 schreef op donderdag 9 maart 2023 @ 09:45:
Zijn hier meer mensen met een ipv6 tunnel van HurricaneElectric(/tunnelbroker)? Ik heb sinds een aantal dagen best wel wat packetloss (atm ~12%). Merkte al dat het internet "traag" was en met het uitzetten van ipv6 weer even goed. Denk zal ff kijken hoe of wat en ja met die packetloss kan ik het me wel voorstellen.

Hier ook al een geruime tijd moeilijkheden met HE. Was al een tijdje overgeschakeld naar de server in Frankfurt, maar deze reageert ook traag, en lage bandbreedte.

Tussentijd maar weer gebruik gemaakt van Route48, maar hier zit een limiet aan, een download van Flight Simulator op de xbox, ging ongemerkt over ipv6, nu gaat er geen enkele data meer overheen. (had ong 250GB op een avond verbruikt)

Nu als alternatief weer even gekeken naar route64.org, en deze bieden nu ook weer een tunnelbroker aan via AMS2.

Deze functioneerd prima, lage ping, en snelheid is, zowel bij download, als upload, begrensd op ong 150mb/s en er is geen datalimiet.

[Dreamvoid]

Snow_King schreef op donderdag 16 maart 2023 @ 20:56:
https://research.hktdc.com/en/article/MTMyMzc4NDY4OA


Vanaf Juli 2023 moet in Kenia alle apparatuur die verkocht wordt IPv6 ondersteunen :-)

Ik weet niet of je anno 2023 nog nieuwe "computers, mobile phones, printers, tablets and scanners" kan vinden die geen IPv6 ondersteunen, maar je hebt natuurlijk ook mensen die oude spullen naar Kenia exporteren.

De vraag is wel wat ze met de Nintendo Switch doen, dat is geloof ik het laatste mainstream produkt dat geen IPv6 ondersteunt.

[Snow_King]

Keiichi schreef op donderdag 16 maart 2023 @ 21:06:
[...]


Zou het niet gewoon zijn dat het probleem met opraken van v4 adressen groter is dan hier, waardoor ze er wel aan moeten en dat consumenten op deze manier een stok achter de deur hebben als ze apparatuur krijgen die niet werkt?

Zou goed kunnen. Africa is behoorlijk benadeeld tijdens de uitgifte van IPv4.

Dreamvoid schreef op vrijdag 17 maart 2023 @ 10:12:
[...]


Ik weet niet of je anno 2023 nog nieuwe "computers, mobile phones, printers, tablets and scanners" kan vinden die geen IPv6 ondersteunen, maar je hebt natuurlijk ook mensen die oude spullen naar Kenia exporteren.

De vraag is wel wat ze met de Nintendo Switch doen, dat is geloof ik het laatste mainstream produkt dat geen IPv6 ondersteunt.

De vraag is wat er precies onder gaat vallen, maar het signaal alleen al is goed imho.

[Roetzen]

Snow_King schreef op vrijdag 17 maart 2023 @ 13:25:
[...]

Zou goed kunnen. Africa is behoorlijk benadeeld tijdens de uitgifte van IPv4.

Maar de vraag was ook veel minder dan in de rest van de wereld met als gevolg dat ze als enige "officieel" nog steeds niet door de voorraad IPv4 heen zijn:

https://www.potaroo.net/tools/ipv4/index.html

[...]

De vraag is wat er precies onder gaat vallen, maar het signaal alleen al is goed imho.

Dat staat of valt altijd met de handhaving....

[aawe mwan]

Dreamvoid schreef op vrijdag 17 maart 2023 @ 10:12:
[...]
Ik weet niet of je anno 2023 nog nieuwe "computers, mobile phones, printers, tablets and scanners" kan vinden die geen IPv6 ondersteunen, maar je hebt natuurlijk ook mensen die oude spullen naar Kenia exporteren.

De Roku ondersteunt bijvoorbeeld in 2023 ook nog geen IPv6: It's 2023 (was 2022) and still no IPv6.

Op Ubuntu 22.04 voor ARM werkte IPv6 op een gegeven moment goed, maar sinds de upgrade naar 22.10 moet je een fixed IPv6 adres instellen om het goed te laten werken. Nog steeds niet opgelost.

[Dreamvoid]

Idd, maar Roku verkoopt geloof ik niet buiten Noord-Amerika.

[RobertMe]

RobertMe schreef op donderdag 16 maart 2023 @ 22:10:
[...]

Deze gek is het blijkbaar ooit gelukt om op een tweede poort van het Ziggo modem zowel een IPv4 als IPv6 adres te krijgen. Nu ondergetekende gek dit probeert krijgt hij echter alleen een IPv4 adres en geen IPv6 adres. Weet iemand toevallig dus of Ziggo wel / niet nog alleen IPv4 en geen IPv6 uitdeelt op de/een additionele poort? Heb een laptop als test gebruikt, prik ik de kabel gewoon in een switch krijgt die meteen een IPv6 adres. Maar een mismatch in DHCPv6 vs router advertisement verhaal zou natuurlijk ook kunnen. Reden dat ik het vraag is omdat ik een TopTon "zachte router" onderweg heb van Ome Ali. En zou dan wel zo fijn zijn als ik die eerst kan opzetten zonder mijn bestaande router te disconnecten En dan is het wel zo handig als ik zowel IPv4 als IPv6 meteen kan fixen. * RobertMe doet nu al iets met IPv6 op bestaande router, USG. Maar wil "meer", dus daarom de USG er maar eens uitgooien en voor volledige zelfbouw gaan (ook geen *sense etc).

Da's gek. Ik had gisteren geprobeerd met een heel oude laptop (think: Sony Vaio uit 2007). Ik gokte dat het Ziggo modem misschien geen IPv6 zou uitgeven omdat die het als "antiek apparaat" markeert door de 100Mbit/s link. Nu even het modem op switch aangesloten en over een VLAN de boel door het huis transporteren naar "werkplek". Daar geprobeerd met (nu oude) laptop die ik vorig jaar ook gebruikt zal hebben, en dan krijg ik wel een IPv6 adres. Maar die antieke laptop doet het dus echt niet (ook nu niet via switches over VLAN etc, dus modem zal wel een gigabit link zien). Beide draaien Arch Linux en zijn up to date. En die antieke laptop krijgt dus wel netjes een IPv6 adres als ik hem gewoon aan mijn LAN hang (met dus een router ertussen die sowieso router advertisements doet op basis van prefix delegation etc).

[Dreamvoid]

Da’s niet zo raar - de router bepaalt niet of een device een IPv6 adres krijgt, het stuurt enkel router advertisements rond, de devices bepalen zelf of ze die info gebruiken om zichzelf een IPv6 adres te geven, of niet.

[RobertMe]

Dreamvoid schreef op zondag 19 maart 2023 @ 13:30:
Da’s niet zo raar - de router bepaalt niet of een device een IPv6 adres krijgt, het stuurt enkel router advertisements rond, de devices bepalen zelf of ze die info gebruiken om zichzelf een IPv6 adres te geven, of niet.

Dus is het wel raar Want antieke laptop direct aan het modem krijgt geen IPv6 adres, terwijl die gewoon achter mijn router (die SLAAC doet) wel een IPv6 adres krijgt, via RA neem ik aan. Terwijl een nieuwere laptop met dezelfde Linux distro, dezelfde network manager (NetworkManager, zonder specifieke configuratie voor eth/lan/kabeltje) wel een IPv6 adres krijgt rechtstreeks aangesloten op het modem.

Oftewel: het ligt niet perse aan het modem / gebruik extra poort op het modem. Maar het ligt ook niet aan de laptop, want achter de router doet die het wel. Dus moet er naar mijn idee ergens een mismatch zijn tussen de devices.

[Roetzen]

RobertMe schreef op zondag 19 maart 2023 @ 13:47:
[...]

Oftewel: het ligt niet perse aan het modem / gebruik extra poort op het modem. Maar het ligt ook niet aan de laptop, want achter de router doet die het wel. Dus moet er naar mijn idee ergens een mismatch zijn tussen de devices.

Bij mij borrelt dan de gedachte naar boven dat er toch iets niet helemaal in orde is met de IPv6 implementatie van de in het modem ingebouwde router functie.

[RobertMe]

Roetzen schreef op zondag 19 maart 2023 @ 14:41:
[...]

Bij mij borrelt dan de gedachte naar boven dat er toch iets niet helemaal in orde is met de IPv6 implementatie van de in het modem ingebouwde router functie.

Hoe bedoel je?

Ter volledige situatie:

• Ubee UBC1328 van Ziggo in bridge mode. Dit geeft dus twee werkende WAN poorten (met eigen extern IPv4 adres en voor zover ik kan zien eigen IPv6 adres, of er een eigen prefix is weet ik (nog) niet)
• Mijn normale router is een UniFi Security Gateway. Deze doet al om en nabij een jaar IPv6 op mijn prive VLAN. Dus een IPv6 adres op WAN en een unieke prefix voor LAN gebruik.
• Antieke laptop krijgt:
  • Aan poort van Ubee geen IPv6 adres, maar wel een extern IPv4 adres
  • Gewoon in het netwerk (achter de USG) wel een IPv6 adres (uit prefix)
• Oude(re) / andere laptop krijgt:
  • Aan de poort van de Ubee wel een IPv6 adres (in hetzelfde subnet als de WAN van USG, dus "range van Ziggo", niet binnen de prefix), en ook weer een publiek IPv4 adres
  • Gewoon aan het netwerk werkt IPv6 uiteraard ook. (Dit was ook mijn gewone laptop toen ik IPv6 instede)

Edit:
Overigens maakt het niet heel veel uit. Was maar als test. Heb een TopTon "zachte router" onderweg van AliExpress. Als IPv6 daarop werkt is het helemaal prima. Ik wilde alleen even proberen of dat met tweede poort gebruiken op de Ubee nog werkte en ik daarop ook IPv6 kreeg. Antwoord leek dus nee te zijn. Ik wist van die tweede poort af via dit topic dus daaruit even hier gezocht. En toen kwam ik dus die post van mijzelf tegen, waarin zelfs stond dat IPv6 werkte. Daarom ook nog eens getest met laptop die ik toen gebruikt moest hebben (intussen dus een nieuwe laptop) en daarop werkte het dan wel.

[Voor 19% gewijzigd door RobertMe op 19-03-2023 15:19]