Het grote IPv6 topic

[xbeam]

Paul schreef op maandag 12 oktober 2020 @ 15:01:
[...]
Uiteindelijk is het (hoop ik) aan de klant:
- Applicatie nu vervangen en IPv6 aan laten staan
- Applicatie vervangen volgens schema, en IPv6 uitzetten
Beide heeft uiteraard zijn eigen voors en tegens.

Op mijn werk hebben we applicaties die alleen al aan licenties meer dan een half miljoen kosten, en daar komt nog hardware, implementatie, migratie, training, etc. etc. bovenop. Dat was toch echt wel een dingetje bij de XP -> Windows 7, en daarna de Windows 7 -> 10 migratie. Geen idee wat ze met die applicaties gedaan hebben (ik zit niet in dat team), maar ik kan me bij dat soort applicaties prima voorstellen dat men besluit IPv6 uit te zetten als dat een probleem geeft, en er ook IPv4-connectiviteit naar die applicaties mogelijk is en blijft.

Uiteraard meld je dat aan de fabrikant in de hoop dat ze de problemen oplossen (bij voorkeur in een patch voor je huidige versie, en niet als feature in die nieuwe versie à €€€€€ ), maar hoe graag we dat in dit topic ook anders zouden zien, voor veruit de meeste bedrijven is IPv6 geen core business.

Hij snapt het probleem heel goed. En doet zelf precies het omgekeerde. Hij neemt ook de moeite niet om zijn fileserver via ipv4 juist beschikbaar te maken zo dat zijn website geen fout meldingen geeft.


Het probleem is het op dit moment voor de beheerder dubbel werk is.

Zoals 2 keer een firewall inrichten en onderhouden en daarvoor wil niet iedereen betalen en de kans op een foutje in de instellingen is daardoor ook groter.

[Vorkie]

xbeam schreef op maandag 12 oktober 2020 @ 16:27:
[...]


Hij snapt het probleem heel goed. En doet zelf precies het omgekeerde. Hij neemt ook de moeite niet om zijn fileserver via ipv4 juist beschikbaar te maken zo dat zijn website geen fout meldingen geeft.
[Afbeelding]

Het probleem is het op dit moment voor de beheerder dubbel werk is.

Zoals 2 keer een firewall inrichten en onderhouden en daarvoor wil niet iedereen betalen en de kans op een foutje in de instellingen is daardoor ook groter.

Dat dubbel beheer is wel een beetje "onzin" en meer luiheid

Elke firewall heeft mooie objecten / networks die je kan gebruiken.
Webserver = 2a03:1111:1111:1111:443/64, maar ook 10.10.14.43 is dat 1 object in je firewall.

Clientsubnet 2a03:1337:1111:1111::/64, maar ook 192.168.11.0/24 is 1 object in je firewall.

Je ruleset blijft, op het stukje dNAT na, hetzelfde...

Je moet dus alleen de administratie op orde houden....

[Roetzen]

xbeam schreef op maandag 12 oktober 2020 @ 16:27:
[...]


Hij snapt het probleem heel goed. En doet zelf precies het omgekeerde. Hij neemt ook de moeite niet om zijn fileserver via ipv4 juist beschikbaar te maken zo dat zijn website geen fout meldingen geeft.

Leuk dat je dat gevonden hebt. Maar het is andersom, ik heb juist (een beetje) moeite gedaan om alleen die ene afbeelding alleen via IPv6 zichtbaar te maken en de rest van de site zowel via IPv4 als IPv6 toegankelijk te houden. Ik heb dat overigens niet zelf bedacht. Ik heb het afgekeken van Iljitsch van Beijnum en zijn oproep tot navolging opgevolgd.

http://www.iljitsch.com/2...f-ipv4-just-a-little.html

Het probleem is het op dit moment voor de beheerder dubbel werk is.

Dat is dan vervelend voor die beheerder, had hij (of zij) maar een vak moeten leren.

Zoals 2 keer een firewall inrichten en onderhouden en daarvoor wil niet iedereen betalen en de kans op een foutje in de instellingen is daardoor ook groter.

Een uitstekende reden om zo snel mogelijk te streven naar een situatie waar IPv4 uitgeschakeld kan worden...

[xbeam]

Vorkie schreef op maandag 12 oktober 2020 @ 16:31:
[...]


Dat dubbel beheer is wel een beetje "onzin" en meer luiheid

Elke firewall heeft mooie objecten / networks die je kan gebruiken.
Webserver = 2a03:1111:1111:1111:443/64, maar ook 10.10.14.43 is dat 1 object in je firewall.

Clientsubnet 2a03:1337:1111:1111::/64, maar ook 192.168.11.0/24 is 1 object in je firewall.

Je ruleset blijft, op het stukje dNAT na, hetzelfde...

Je moet dus alleen de administratie op orde houden....

Ik probeer alleen maar te gegeven waarom er veel kleinere mbk bedrijven zijn die hun infra niet op orde hebben.

[Dreamvoid]

xbeam schreef op maandag 12 oktober 2020 @ 16:27:
Het probleem is het op dit moment voor de beheerder dubbel werk is.

Zoals 2 keer een firewall inrichten en onderhouden en daarvoor wil niet iedereen betalen en de kans op een foutje in de instellingen is daardoor ook groter.

Exact, daarom is het ook praktischer om een IPv6-only netwerk te draaien. Hoef je maar 1 stack te beheren, en je overgebleven IPv4 verkeer gaat daar dan via NAT64 overheen.

Je ziet dat de ISP's een voor een tot diezelfde conclusie komen, en grote hosters als bv Facebook ook: IPv4 kan je al termineren op de reverse proxy/CDN service aan de rand, je hele backend kan dan verder netjes single stack IPv6 blijven.

[ Voor 20% gewijzigd door Dreamvoid op 12-10-2020 18:13 ]

[ANdrode]

Dreamvoid schreef op maandag 12 oktober 2020 @ 18:03:
[...]
Je ziet dat de ISP's een voor een tot diezelfde conclusie komen, en grote hosters als bv Facebook ook: IPv4 kan je al termineren op de reverse proxy/CDN service aan de rand, je hele backend kan dan verder netjes single stack IPv6 blijven.

Of grote hosters zoals AWS: Je termineert IPv6 op de loadbalancer en verder is alles nog IPv4

[Hipska]

Inderdaad, maar dat is dan ook een boekenwinkel

[Bigs]

Dreamvoid schreef op maandag 12 oktober 2020 @ 18:03:
[...]

Exact, daarom is het ook praktischer om een IPv6-only netwerk te draaien. Hoef je maar 1 stack te beheren, en je overgebleven IPv4 verkeer gaat daar dan via NAT64 overheen.

[...]

Heeft iemand dit al ooit in een thuissituatie werkend gekregen met een goedkope of software router? Mijn IPv6-only SSID is niet heel bruikbaar zonder dit

[Vorkie]

Bigs schreef op woensdag 14 oktober 2020 @ 10:02:
[...]


Heeft iemand dit al ooit in een thuissituatie werkend gekregen met een goedkope of software router? Mijn IPv6-only SSID is niet heel bruikbaar zonder dit

http://www.litech.org/tayga/

Deze heb ik wel eens mee gespeeld, deed wel ongeveer wat ik er van kon verwachten.

Weet alleen niet of het nog werkt

[Dreamvoid]

Bigs schreef op woensdag 14 oktober 2020 @ 10:02:
[...]


Heeft iemand dit al ooit in een thuissituatie werkend gekregen met een goedkope of software router? Mijn IPv6-only SSID is niet heel bruikbaar zonder dit

NAT64 kan eigenlijk op drie manieren:

1) Je provider draait de NAT64 service. Zo gaat het met mobiele netwerken. Je hoeft eigenlijk niets te doen, de DNS server van de provider doet DNS64, en het verkeer met 64:ff9b prefix wordt naar de NAT64 server van de provider gerouteerd, en van daar naar de rest van het IPv4 internet. Probleem: op het moment wordt bij de vaste lijn abonnees het 64:ff9b verkeer niet naar die NAT64 gerouteerd.

2) Je draait NAT64 zelf: als je dual stack aan de WAN kant hebt, draai je een NAT64 server op je eigen router. Je LAN kan dan IPv6-only zijn. Dan moet je wel een router hebben die een NAT64 server aan boord heeft, en dat zie je niet vaak buiten custom Linux firmwares (tayga, jool) of enterprise-level spul. De DNS kan je dan ofwel ook op die router draaien, ofwel een willekeurige andere DNS64 server die de 64:ff9b prefix gebruikt, zoals Cloudflare of Google.

3) De DNS64 en NAT64 gebeurt bij een 3rd party (dus geen 64:ff9b prefix). Je moet dan een router hebben die custom DNS servers kan pushen. Veel provider-boxes zijn hardcoded op de DNS servers van de provider, dus dan werkt het niet (of je moet DNS servers per-client handmatig gaan instellen), maar verder kan het in principe met elke router. Laat de router een DNS64 server naar je clients pushen van een publieke NAT64 service (bv die van
https://www.tuxis.nl/en/public-doh-dot-dns64-nat64-service/ of een van dit lijstje), en het draait. Dit betekent wel dat alle IPv4 verkeer via die 3rd party NAT64 server loopt. Dat is in principe niet zo'n probleem, maar kan wel voor rare geolocatie issues zorgen.

[ Voor 67% gewijzigd door Dreamvoid op 14-10-2020 18:09 ]

[Maurits van Baerle]

@Bigs

Vorkie schreef op woensdag 14 oktober 2020 @ 10:04:
[...]

http://www.litech.org/tayga/

Deze heb ik wel eens mee gespeeld, deed wel ongeveer wat ik er van kon verwachten.

Weet alleen niet of het nog werkt

Tayga staat nog steeds in de OpenWRT repository met versie 0.9.2-2. Ik heb hem zelf nooit gebruikt maar als je OpenWRT draait op je router kun je hem gewoon onder System -> Software installeren.

[ Voor 6% gewijzigd door Maurits van Baerle op 14-10-2020 12:22 ]

[JP.PC Supplies]

Ik woon in een boven appartement, onder is mijn meterkast, afstanden; 15 meter naar woonkamer en 20 meter naar slaapkamer.
Vanaf de meterkast gaan 3 kabels, twee naar de woonkamer (voor en achter woonkamer) en één naar de slaapkamer.

Ik kan helaas niet een kabel vanuit de woonkamer naar de slaapkamer krijgen.

Meterkast beneden Ziggo modem/router DHCP wifi uit.
Woonkamer achter "bedraad" AX88U perfecte wifi, maar A.P hierbij vervallen router functie, en IPv6
Woonkamer voor switch met,TV/Playstation/Stereo-installatie met netwerk functie.
Slaapkamer "bedraad" AX58U perfecte wifi maar A.P hierbij vervallen router functie, en IPv6

Ik zit nu in twijfel, en hoop dat jullie mij kunnen helpen, als ik mijn Ziggo modem/router in bridge modus zet vervalt IPv6?
En kan ik alleen nog maar 1 lan poort krijgen, dus probleem in slaapkamer en in woonkamer voor,is dan een switch achter een Ziggo modem (in bridge) mogelijk?

Waarom kan Ziggo, in bridge modus niet IPv6 door sturen?

Als ik mijn Ziggo modem/router laat voor wat het is, en mijn dure Asus AX88U en AX58U als access point instel vervallen alle router opties, en dan had ik net zo goed een switch kunnen plaatsen, maar dan heb ik weer een wifi probleem.

Ik heb het nodige getest,

Routers in ander subnet als de Ziggo modem, maar dan krijg ik dus 3 verschillende netwerken, en dan word het voor mij heel moeilijk om vanuit de slaapkamer mijn Asus AC88U te bereiken.(streamen films)

Hoe zit het met modem Ziggo modem lan - lan router Asus, is dat hetzelfde als access point?
of kan je in die optie wel router functie behouden van de Asus. uiteraard DHCP uit.

Mooiste zou zijn, zonder conflicten, routers boven het wifi netwerk laten uitdelen, modem Ziggo, in bridge maar wel met IPv6 (toekomst), daarachter een switch zodat ik toch nog 4 Lan poorten beneden heb

Ik zie door de bomen het netwerk niet meer en hoop op antwoord waarop ik een goede keus kan maken.

gr J

[Roetzen]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 15:30:
als ik mijn Ziggo modem/router in bridge modus zet vervalt IPv6?

Ja.

En kan ik alleen nog maar 1 lan poort krijgen, dus probleem in slaapkamer en in woonkamer voor,is dan een switch achter een Ziggo modem (in bridge) mogelijk?

Ja.

Waarom kan Ziggo, in bridge modus niet IPv6 door sturen?

Verkeerde vraag. Het kan wel, maar om hun moverende redenen bieden ze die mogelijkheid niet aan bij een consumenten aansluiting.

Als ik mijn Ziggo modem/router laat voor wat het is, en mijn dure Asus AX88U en AX58U als access point instel vervallen alle router opties, en dan had ik net zo goed een switch kunnen plaatsen, maar dan heb ik weer een wifi probleem.

Los Wifi AP gebruiken?

[ANdrode]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 15:30:
Waarom kan Ziggo, in bridge modus niet IPv6 door sturen?

Daar kan ik alleen maar naar raden. Ik zie wat mogelijkheden:

• Bij vendor selectie is dual stack in bridge niet meegenomen als optie.
• Implementatie krijgt geen prioriteit.
• Minachting van de klanten.

[Jay-B]

Optie 2 lijkt me de meest voor de hand liggende.

Ik meen me te herinneren dat een medewerker op het forum aangaf dat er een stukje access control gedaan wordt op het modem zelf. Blijkbaar is dit met de huidige configuratie van het netwerk niet mogelijk wanneer het modem in bridge staat en dus potentieel een beveiligingsissue. Ik ken de details niet dus ik weet niet hoe dit anders is in vergelijking met IPv4 maar het is dus niet zomaar.

[ Voor 22% gewijzigd door Jay-B op 17-10-2020 16:31 ]

[Brahiewahiewa]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 15:30:
...
Woonkamer achter "bedraad" AX88U perfecte wifi, maar A.P hierbij vervallen router functie, en IPv6
...

Dat je router functie vervalt, klopt. Maar IPv6 wordt gewoon doorgegeven

[Roetzen]

@Brahiewahiewa
Heb je dat uit eigen waarneming of alleen van horen zeggen? En indien uit eigen waarneming, welk pakket heb je? fZiggo of fUPC?

[Brahiewahiewa]

Roetzen schreef op zaterdag 17 oktober 2020 @ 17:56:
@Brahiewahiewa
Heb je dat uit eigen waarneming of alleen van horen zeggen? En indien uit eigen waarneming, welk pakket heb je? fZiggo of fUPC?

Welke ipv6 provider je hebt maakt niets uit. Een router in AP-mode zou gewoon een switch moeten zijn en alle protocollen moeten doorgeven. Tenzij de AX88U een dedicated AP-mode heeft waarbij je ook de WAN poort kunt gebruiken èn een of andere wijsneus heeft verzonnen dat je op de LAN ports en of wifi geen ipv6 nodig hebt en het actief geblokkeerd wordt

FYI: ik heb waargenomen dat een als AP geschakelde wifirouter (dhcp uit, aangesloten op één van de LAN ports) zowel ziggo full stack's ipv6 doorgeeft als die van m'n he.net tunnel

[JP.PC Supplies]

Brahiewahiewa schreef op zaterdag 17 oktober 2020 @ 18:12:
[...]

Welke ipv6 provider je hebt maakt niets uit. Een router in AP-mode zou gewoon een switch moeten zijn en alle protocollen moeten doorgeven. Tenzij de AX88U een dedicated AP-mode heeft waarbij je ook de WAN poort kunt gebruiken èn een of andere wijsneus heeft verzonnen dat je op de LAN ports en of wifi geen ipv6 nodig hebt en het actief geblokkeerd wordt

FYI: ik heb waargenomen dat een als AP geschakelde wifirouter (dhcp uit, aangesloten op één van de LAN ports) zowel ziggo full stack's ipv6 doorgeeft als die van m'n he.net tunnel

Oke, maar in AP-mode vervallen een hele hoop optie's van mijn Asus AX88U.

[Brahiewahiewa]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 18:28:
[...]


Oke, maar in AP-mode vervallen een hele hoop optie's van mijn Asus AX88U.

Ja, je zult een keuze moeten maken tussen ipv6 en de opties van de dure router. Beiden tegelijk gaat niet.

Althans, er is eventueel nog wel een mogelijkheid om je dure router als DMZ host te schakelen en om ipv6 dan via dhcp6-pd te verkrijgen. Maar er zit een bug in (sommige?) connectbox die dhcp6-pd om zeep helpt. En bovendien heb je dan ip4 dubbel NAT

[JP.PC Supplies]

Brahiewahiewa schreef op zaterdag 17 oktober 2020 @ 19:05:
[...]

Ja, je zult een keuze moeten maken tussen ipv6 en de opties van de dure router. Beiden tegelijk gaat niet.

Althans, er is eventueel nog wel een mogelijkheid om je dure router als DMZ host te schakelen en om ipv6 dan via dhcp6-pd te verkrijgen. Maar er zit een bug in (sommige?) connectbox die dhcp6-pd om zeep helpt. En bovendien heb je dan ip4 dubbel NAT

Oke,dat klinkt interessant,maar stel ik zet 3 aparte netwerken op alles in een ander subnet, is het moeilijk om visa versa, alles te bereiken van elk netwerk onderling?

Ziggo 192.168.1.1
Asus AX 88U 192.168.2.1
Asus AX 58U 192.168.3.1


Zijn ze alle onderling te benaderen?
Of word dat een heel gedoe met vaste ip en poortforwarding?

[Brahiewahiewa]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 19:23:
[...]


Oke,dat klinkt interessant,maar stel ik zet 3 aparte netwerken op alles in een ander subnet, is het moeilijk om visa versa, alles te bereiken van elk netwerk onderling?

Ziggo 192.168.1.1
Asus AX 88U 192.168.2.1
Asus AX 58U 192.168.3.1


Zijn ze alle onderling te benaderen?
Of word dat een heel gedoe met vaste ip en poortforwarding?

Dat wordt best wel een gedoe. De ziggo router heeft geen optie om intern te routeren. Dus op dat segment kun je dan geen client devices aansluiten. De Asus routers kunnen naar elkaar verwijzen. Maar houdt er rekening dat allerlei broadcast based mechanismes niet gaan werken. Dus je zult bijv. handmatig name resolution moeten onderhouden. Of je streaming device de routers kan passeren is ook maar de vraag.

Anyway, dit is allemaal ip4 technologie. Als je echt met dit gegeven aan de slag wilt gaan, moet je misschien een eigen topic in netwerken openen

[Snow_King]

Brahiewahiewa schreef op dinsdag 6 oktober 2020 @ 16:48:
[...]

Laat je even weten of het blijft werken?
Mijn ervaring is dat het één keer werkt. Maar na een reboot van de router zegt-ie dat er geen lease verkregen kan worden. Kennelijk is de dhcp refresh stuque.
Ook een reboot van de ziggo modem lost dat niet op

We zijn nu een tijdje verder en het werkt nog steeds!

Ik heb een systemd service draaien op een server van mij waarop ik Docker draai. Met een DHCP hook zorg ik dat Docker het juiste subnet krijgt:

/etc/dhcp/dhclient-enter-hooks.d/docker-ipv6

code:

#!/bin/bash

SUBNET_SIZE=80
DOCKER_CFG="/etc/docker/daemon.json"

if [ ! -z "$new_ip6_prefix" ]; then
    SUBNET=$(sipcalc -S $SUBNET_SIZE $new_ip6_prefix|grep Network|head -n 1|awk '{print $3}')

    TMPFILE=$(mktemp)

    jq --arg c "$SUBNET" '.["fixed-cidr-v6"] = $c/${SUBNET_SIZE}' $DOCKER_CFG > $TMPFILE
    cat $TMPFILE > $DOCKER_CFG
    rm $TMPFILE

    if [ "$old_ip6_prefix" != "$new_ip6_prefix" ]; then
        systemctl restart docker
    fi
fi

Mijn containers hebben nog steeds IPv6

[easyriider]

JP.PC Supplies schreef op zaterdag 17 oktober 2020 @ 15:30:
Waarom kan Ziggo, in bridge modus niet IPv6 door sturen?

Als ik mijn Ziggo modem/router laat voor wat het is, en mijn dure Asus AX88U en AX58U als access point instel vervallen alle router opties, en dan had ik net zo goed een switch kunnen plaatsen, maar dan heb ik weer een wifi probleem.

Je kunt gewoon je Asus router achter het Ziggo modem plaatsen zonder hem als access point te hoeven instellen. Zo heb ik m'n AC86U als router achter het Ziggo modem, en die gebruik ik voor allerlei taken zoals NextDNS en CakeQos. Helemaal perfect zou het zijn als het modem in bridge zou staan, als router achter router heb je dubbel NAT, maar daar valt wel mee te leven.

[valkenier]

Jay-B schreef op zaterdag 17 oktober 2020 @ 16:28:
Optie 2 lijkt me de meest voor de hand liggende.

Ik meen me te herinneren dat een medewerker op het forum aangaf dat er een stukje access control gedaan wordt op het modem zelf. Blijkbaar is dit met de huidige configuratie van het netwerk niet mogelijk wanneer het modem in bridge staat en dus potentieel een beveiligingsissue. Ik ken de details niet dus ik weet niet hoe dit anders is in vergelijking met IPv4 maar het is dus niet zomaar.

Dat is wel ongeveer de reden ja. Details kan ik niet geven, maar je hebt gelijk.

[JP.PC Supplies]

Voor ieder hartelijk dank, ik denk dat ik voorlopig bij A.P mode blijf, beetje dure (maar fantastische) router voor gekocht.

Maar alles draait stabiel en snel.
Misschien ooit de Ziggo in bridge

[Dreamvoid]

Doet die Ziggo modem eigenlijk prefix delegation? Dan heb je in principe geen bridge mode nodig, maar schuif je de prefix gewoon door.

De Ziggo modem krijgt dan de /56 van Ziggo, je volgende eigen router vraagt een /60 aan de Ziggo router, en verdeelt zelf 1 of meerdere /64’s.

[ Voor 4% gewijzigd door Dreamvoid op 19-10-2020 02:06 ]

[Brahiewahiewa]

Dreamvoid schreef op maandag 19 oktober 2020 @ 02:06:
Doet die Ziggo modem eigenlijk prefix delegation? ...

Die van @Snow_King doet het; die van mij niet
Kortom: YMMV

[Snow_King]

Dreamvoid schreef op maandag 19 oktober 2020 @ 02:06:
Doet die Ziggo modem eigenlijk prefix delegation? Dan heb je in principe geen bridge mode nodig, maar schuif je de prefix gewoon door.

De Ziggo modem krijgt dan de /56 van Ziggo, je volgende eigen router vraagt een /60 aan de Ziggo router, en verdeelt zelf 1 of meerdere /64’s.

Mijn ConnectBox (Arris ding) doet het in ieder geval wel. Bij @Brahiewahiewa werkt het weer niet goed, maar ik heb nu al twee weken netjes een /64 gekregen van mijn ConnectBox via PD op een Linux host.

Daar draai ik vervolgens Docker containers (Influx en Grafana) welke een native IPv6 adres hebben.

De IPv6 firewall op de ConnectBox heb ik uit staan zodat ik vanaf buiten gewoon bij mijn containers kan. ip6tables is wel weer in gebruik om het grote boze internet buiten de deur te houden.

Al blijft het lekker dat je met IPv6 praktisch geen port scans ziet.

[Muis666]

Snow_King schreef op maandag 19 oktober 2020 @ 09:59:
[...]

Mijn ConnectBox (Arris ding) doet het in ieder geval wel. Bij @Brahiewahiewa werkt het weer niet goed, maar ik heb nu al twee weken netjes een /64 gekregen van mijn ConnectBox via PD op een Linux host.

Daar draai ik vervolgens Docker containers (Influx en Grafana) welke een native IPv6 adres hebben.

De IPv6 firewall op de ConnectBox heb ik uit staan zodat ik vanaf buiten gewoon bij mijn containers kan. ip6tables is wel weer in gebruik om het grote boze internet buiten de deur te houden.

Al blijft het lekker dat je met IPv6 praktisch geen port scans ziet.

Dit lijkt me toch niet helemaal veilig. Alles wat je nu rechtrstreeks via je connectbox aansluit hangt nu zonder ipv6 firewall aan het internet...

[Gogol]

Ik heb een OPNsense firewall in de DMZ van mijn Ziggo router (UBC1318ZG) geplaatst. Werkt prima met IPv6.

[Dreamvoid]

Muis666 schreef op maandag 19 oktober 2020 @ 11:02:
[...]

Dit lijkt me toch niet helemaal veilig. Alles wat je nu rechtrstreeks via je connectbox aansluit hangt nu zonder ipv6 firewall aan het internet...

@Snow_King draait zo te zien wel een firewall op zijn Linux server, maar idd als je een ander device zonder eigen firewall in je LAN hangt dan is-ie vrij bereikbaar.

[Snow_King]

Muis666 schreef op maandag 19 oktober 2020 @ 11:02:
[...]

Dit lijkt me toch niet helemaal veilig. Alles wat je nu rechtrstreeks via je connectbox aansluit hangt nu zonder ipv6 firewall aan het internet...

Klopt. Ik heb echter nog een Linux server er tussen zitten in bridge modus waar ik op br0 met ip6tables nog kan filteren.

Ik doe dat echter minimaal en doe het eigenlijk al jaren zo. Ik weet dat er risico's zijn, maar tot op heden werken Privacy Extensions prima zodat als je al een IPv6 adres hebt van een device van mij deze enkele uren later al niet meer werkt.

Dreamvoid schreef op maandag 19 oktober 2020 @ 11:15:
[...]

@Snow_King draait zo te zien wel een firewall op zijn Linux server, maar idd als je een ander device zonder eigen firewall in je LAN hangt dan is-ie vrij bereikbaar.

Zoals ik aan gaf: Bewuste keuze. De SSH poortscans die je op IPv4 hebt zijn er gewoon niet op IPv6.

[Vorkie]

Snow_King schreef op maandag 19 oktober 2020 @ 11:38:
[...]

Klopt. Ik heb echter nog een Linux server er tussen zitten in bridge modus waar ik op br0 met ip6tables nog kan filteren.

Ik doe dat echter minimaal en doe het eigenlijk al jaren zo. Ik weet dat er risico's zijn, maar tot op heden werken Privacy Extensions prima zodat als je al een IPv6 adres hebt van een device van mij deze enkele uren later al niet meer werkt.


[...]

Zoals ik aan gaf: Bewuste keuze. De SSH poortscans die je op IPv4 hebt zijn er gewoon niet op IPv6.

Die port-scans zijn er echt wel
Onderzoeksbureau's, maar ook een aantal Chinese /48's die zo nu en dan voorbij komen in mijn logs.

Kijk hoeveel er bijvoorbeeld aan verkeer naar mijn /48 wordt tegengehouden uit Azië....

[Snow_King]

Vorkie schreef op maandag 19 oktober 2020 @ 11:45:
[...]


Die port-scans zijn er echt wel
Onderzoeksbureau's, maar ook een aantal Chinese /48's die zo nu en dan voorbij komen in mijn logs.

Kijk hoeveel er bijvoorbeeld aan verkeer naar mijn /48 wordt tegengehouden uit Azië....

[Afbeelding]

Ja? Wow. Ik zie ze echt nooit. Ik monitor het vaak met tcpdump om te kijken wat er voorbij komt.

Maar hoe weten ze een IPv6 adres van je? De /56 die ik van Ziggo heb is zo groot, daar kan je niet even alles op scannen.

De servers die ik draai filter ik wel met ip6tables, maar de client devices zoals een MacBook, Linux laptop en iOS devices hebben allemaal Privacy Extensions.

Jay-B schreef op zaterdag 17 oktober 2020 @ 16:28:
Optie 2 lijkt me de meest voor de hand liggende.

Ik meen me te herinneren dat een medewerker op het forum aangaf dat er een stukje access control gedaan wordt op het modem zelf. Blijkbaar is dit met de huidige configuratie van het netwerk niet mogelijk wanneer het modem in bridge staat en dus potentieel een beveiligingsissue. Ik ken de details niet dus ik weet niet hoe dit anders is in vergelijking met IPv4 maar het is dus niet zomaar.

Waarschijnlijk iets met DHCPv6 en de Identifier die op de DHCP server aan komt. Grote kans dat de ConnectBox nu zelf zijn "ID" mee stuurt. Als je dat gewoon open zet voor de hele wereld kan iedereen die gaan faken.

Dat zal de implementatie van het Ziggo netwerk zijn. Bij Delta/ZeelandNet was dit weer geen probleem.

[ Voor 31% gewijzigd door Snow_King op 19-10-2020 11:50 ]

[Vorkie]

Snow_King schreef op maandag 19 oktober 2020 @ 11:49:
[...]

Ja? Wow. Ik zie ze echt nooit. Ik monitor het vaak met tcpdump om te kijken wat er voorbij komt.

Maar hoe weten ze een IPv6 adres van je? De /56 die ik van Ziggo heb is zo groot, daar kan je niet even alles op scannen.

De servers die ik draai filter ik wel met ip6tables, maar de client devices zoals een MacBook, Linux laptop en iOS devices hebben allemaal Privacy Extensions.

Ja hoe ze dat weten, lastig verhaal, maar ze scannen die blokken gewoon op basis van een /48? of misschien gewoon bij 1 beginnen

Ik kan mij voorstellen dat de kans natuurlijk klein is, maar als jij binnen een subnet vaak een SSH server tegenkomt, is deze natuurlijk wel interessant

[Snow_King]

Vorkie schreef op maandag 19 oktober 2020 @ 11:50:
[...]


Ja hoe ze dat weten, lastig verhaal, maar ze scannen die blokken gewoon op basis van een /48? of misschien gewoon bij 1 beginnen

Ik kan mij voorstellen dat de kans natuurlijk klein is, maar als jij binnen een subnet vaak een SSH server tegenkomt, is deze natuurlijk wel interessant

Een /48 zijn meer IP-adressen dan het gehele internet met IPv4 nu heeft. Veel meer!

- /56: 4,722,366,482,869,645,213,696
- /48: 1,208,925,819,614,629,174,706,176

Dat kan je gewoon niet even scannen. Niet elk IP opzoeken en dan OOK nog een portscan doen.

De latency vanuit China is gewoon al te hoog. Ga je ook nog eens parallel meerdere scans doen begin je zo veel packet/s danwel bytes aan verkeer te versturen dat de internet verbinding danwel de router er last van begint te krijgen dat het op begint te vallen.

Met IPv6 het gehele internet danwel een lokaal LAN scannen is gewoon bijna onmogelijk. Latency en de hoeveelheid adressen.

[Vorkie]

Snow_King schreef op maandag 19 oktober 2020 @ 12:10:
[...]

Een /48 zijn meer IP-adressen dan het gehele internet met IPv4 nu heeft. Veel meer!

- /56: 4,722,366,482,869,645,213,696
- /48: 1,208,925,819,614,629,174,706,176

Dat kan je gewoon niet even scannen. Niet elk IP opzoeken en dan OOK nog een portscan doen.

De latency vanuit China is gewoon al te hoog. Ga je ook nog eens parallel meerdere scans doen begin je zo veel packet/s danwel bytes aan verkeer te versturen dat de internet verbinding danwel de router er last van begint te krijgen dat het op begint te vallen.

Met IPv6 het gehele internet danwel een lokaal LAN scannen is gewoon bijna onmogelijk. Latency en de hoeveelheid adressen.

Je hoeft mij niet te overtuigen, ik geef alleen aan dat ik het voorbij zie komen en daadwerkelijk verkeer gedropt wordt als port-scans op mijn IPv6 subnet. Is een ::1/64 bereikbaar > scannen, anders door!

En waar mogelijk geld gehaald kan worden, zal gescand worden het is gewoon kosten/baten voor de hackers.

Ik zal het in ieder geval niet zakelijk op die manier inzetten (zonder firewall)

:-)

[ Voor 7% gewijzigd door Vorkie op 19-10-2020 12:26 ]

[downtime]

Snow_King schreef op maandag 19 oktober 2020 @ 12:10:
[...]

Dat kan je gewoon niet even scannen. Niet elk IP opzoeken en dan OOK nog een portscan doen.

Wie zegt dat ze dat doen? Sommige apparaten (m.n. servers) hebben vaste IP’s en ik kan me voorstellen dat bepaalde ranges veel meer gebruikt worden dan andere. Mensen hebben nu eenmaal de neiging om voor logische (en goed te onthouden) adressen te gaan.

Vergelijk het met passwords: Je kunt brute force scannen of je beperken tot een paar honderd (of duizend) veelgebruikte passwords.

[Brahiewahiewa]

Snow_King schreef op maandag 19 oktober 2020 @ 12:10:
[...]

Een /48 zijn meer IP-adressen dan het gehele internet met IPv4 nu heeft. Veel meer!

- /56: 4,722,366,482,869,645,213,696
- /48: 1,208,925,819,614,629,174,706,176

Dat kan je gewoon niet even scannen. Niet elk IP opzoeken en dan OOK nog een portscan doen...

Nee, maar de /48 en /56 adressen zijn ook niet interessant. Je weet gewoon als je een ipv6 adres harvest, dat het /64 gebruikt wordt op een netwerk en dat daar dus eventueel targets te vinden zijn. Nog steeds veel werk, granted. Maar rekenen met de immense grootte van een /56 of /48 geeft een vals gevoel van veiligheid

[Snow_King]

Vorkie schreef op maandag 19 oktober 2020 @ 12:25:
[...]


Je hoeft mij niet te overtuigen, ik geef alleen aan dat ik het voorbij zie komen en daadwerkelijk verkeer gedropt wordt als port-scans op mijn IPv6 subnet. Is een ::1/64 bereikbaar > scannen, anders door!

En waar mogelijk geld gehaald kan worden, zal gescand worden het is gewoon kosten/baten voor de hackers.

Ik zal het in ieder geval niet zakelijk op die manier inzetten (zonder firewall)

:-)

Ik snap het :-) Ik neem het risico thuis in ieder geval wel.

downtime schreef op maandag 19 oktober 2020 @ 12:37:
[...]

Wie zegt dat ze dat doen? Sommige apparaten (m.n. servers) hebben vaste IP’s en ik kan me voorstellen dat bepaalde ranges veel meer gebruikt worden dan andere. Mensen hebben nu eenmaal de neiging om voor logische (en goed te onthouden) adressen te gaan.

Vergelijk het met passwords: Je kunt brute force scannen of je beperken tot een paar honderd (of duizend) veelgebruikte passwords.

Zeker, mijn servers thuis hebben wel vaste IP's (SLAAC) en ook DNS entries die er heen wijzen.

Op die servers draai ik weer wel een ip6tables firewall om verkeer te filteren.

Brahiewahiewa schreef op maandag 19 oktober 2020 @ 12:38:
[...]

Nee, maar de /48 en /56 adressen zijn ook niet interessant. Je weet gewoon als je een ipv6 adres harvest, dat het /64 gebruikt wordt op een netwerk en dat daar dus eventueel targets te vinden zijn. Nog steeds veel werk, granted. Maar rekenen met de immense grootte van een /56 of /48 geeft een vals gevoel van veiligheid

Fair enough. Maar je bent het met mij eens, een /64 is hels veel werk. Niet iets wat je ff gaat scannen voor de lol. Doe dat keer X miljoen aansluitingen in Nederland en je begint wel ergens op te vallen bij ISP's.

Met IPv6 is even het internet scannen met portscans gewoon veel lastiger geworden. Ik zeg eigenlijk onmogelijk.

[Dreamvoid]

Ik geloof niet dat er iemand serieus een complete /64 gaat scannen, maar specifieke IPv6 adressen zijn natuurlijk wel te "harvesten". Ten eerste de PE adressen waarvanaf devices verbinden, die kan je loggen met websites/ads/etc. Tuurlijk, je hebt maar <24u om iets met dat adres te doen, maar dat kan genoeg zijn. Verder heb je ook publieke DNS records, elk IPv6 adres met een AAAA record kan je in principe proberen, en dat zijn vaak vaste adressen. Verder zullen er vast wel wat "domme" DHCPv6 servers zijn ingericht die adressen netjes op volgorde uitdelen vanaf ::1, ::2, ::3 etc.

Ik denk dat IPv6 best een vruchtbaar 'jachtgebied' is, zeker omdat je veel 'beginners' hebt qua beheerders die nog niet helemaal weten wat ze precies doen, en veel monitoring/anti-bruteforcing tools er nog geen oogje op houden. Het heeft bv geen zin om zoals bij IPv4 source adressen te blokkeren na 10 foute inlogpogingen, want een aanvaller kan makkelijk elke seconde een nieuw IPv6 adres voor zichzelf genereren.

[ Voor 45% gewijzigd door Dreamvoid op 19-10-2020 15:08 ]

[linkforsoad]

linkforsoad schreef op maandag 28 september 2020 @ 17:45:
Hoop het van harte

Helaas, geen witte rook, 'wij hebben nog genoeg IPv4 en dat wordt nog veel gebruikt door klanten'. Maar eventueel kon men wel wat extra v4-adressen aanbieden

[Snow_King]

Nog een leuke! Ik heb een LG 65CX OLED in de woonkamer hangen.

Via ethernet verbonden en in het menu toont deze netjes dat de TV IPv4 en IPv6 connectiviteit heeft.

Als ik https://test-ipv6.com/ bezoek in de browser haal ik een score van 9/10 (ligt aan de Ziggo DNS servers). Tot zo ver allemaal goed.

Tussen mijn Ziggo ConnectBox en de uplink van mijn switch zit een Linux server waar ik twee poorten in een bridge heb gezet. Zo kan ik al het verkeer inspecteren en tellen wat mijn netwerk in en uit gaat.

code:

bridge name bridge id       STP enabled interfaces
br1     8000.8eb20d8d9b94   no      enp0s20f0
                            enp0s20f1

code:

tcpdump -i br1 -n ether host 64:95:6c:f0:67:4a

Wat valt mij op? YouTube en Netflix op deze TV gebruiken IPv4. De TV doet enkel lookups voor A-records en vervolgens zie ik dat de streams van beide diensten over IPv4 gaan

Vraag mij weer af wat de reden daar achter is

[Roetzen]

linkforsoad schreef op dinsdag 20 oktober 2020 @ 15:29:
[...]

Helaas, geen witte rook, 'wij hebben nog genoeg IPv4 en dat wordt nog veel gebruikt door klanten'.

Alsof "nog genoeg IPv4 hebben" een goede reden is om IPv6 voor je uit te schuiven. En ja, als je je klanten alleen IPv4 aanbiedt is het logisch dat ze dat dan ook gebruiken.

Maar eventueel kon men wel wat extra v4-adressen aanbieden

Een IPv6 adres is 128 bit dus vier IPv4 adressen is samen ook 128 bit?

Zit je echt aan die provider vast met die glasvezel? Tegenwoordig zie je veel constructies waarbij men uit meerdere aanbieders kan kiezen op dezelfde glasvezel. Misschien kan Freedom ook wel leveren via hetzelfde glas.

Als het even kan zou ik niet voor een provider gaan die nu nog komt met "we hebben nog genoeg IPv4".

[linkforsoad]

Helaas zit ik er echt aan vast > http://www.glasvezelassendorp.nl/
In de wandelgangen werd er wat gezegd over gesprekken die gaande zouden zijn met KPN v.w.b. WBA-aanbod, maar niks concreets.

Mijn voorkeur gaat naar XS (of Freedom), omdat we vaste klant zijn bij XS. Helaas kunnen die louter DSL leveren, wat er reeds is, maar de onderliggende verbinding is erg instabiel. Ook Ziggo is geen optie, want de CAI is nog steeds van dezelfde lokale stichting.

[ Voor 9% gewijzigd door linkforsoad op 20-10-2020 15:50 ]

[ed1703]

Roetzen schreef op dinsdag 20 oktober 2020 @ 15:46:
[...]

Alsof "nog genoeg IPv4 hebben" een goede reden is om IPv6 voor je uit te schuiven. En ja, als je je klanten alleen IPv4 aanbiedt is het logisch dat ze dat dan ook gebruiken.

Maar vragen die klanten er wel om? Dan ga je als ISP ook wat meer moeite doen om het te leveren.
95% van de klanten weet niet eens wat het is. Goed vooruit, 90%.

[Roetzen]

linkforsoad schreef op dinsdag 20 oktober 2020 @ 15:49:
Helaas zit ik er echt aan vast > http://www.glasvezelassendorp.nl/

Helaas, dan ben je de Sjaak. Jammer dat er dan weer een de facto monopolie situatie ontstaat.

ed1703 schreef op dinsdag 20 oktober 2020 @ 15:54:
[...]

Maar vragen die klanten er wel om? Dan ga je als ISP ook wat meer moeite doen om het te leveren.
95% van de klanten weet niet eens wat het is. Goed vooruit, 90%.

Anno 2020 zou dat helemaal geen "kwestie" meer moeten zijn. Anno 2020 is een IPv4 only verbinding geen volwaardige Internet aansluiting meer. De klanten zouden er al lang niet meer om hoeven vragen, anno 2020 moet een fatsoenlijke ISP het gewoon aanbieden. Punt.

Ik ga niet meer in discussie met een ISP die geen IPv6 aanbiedt. Ik hoef de redenen waarom ze het nou nog niet hebben niet meer te horen. Ik stem met de voeten.

Maar ja, ik heb makkelijk praten.Toen ik de pensioengrechtigde leeftijd bereikte was die nog 65 jaar. Ik heb geen baas meer, ik ben geen baas meer en ik heb geen kiezers. Ik kan gewoon zonder "met belangen rekening te houden" zeggen wat ik er van vind.

[linkforsoad]

Roetzen schreef op dinsdag 20 oktober 2020 @ 18:22:
[...]

Helaas, dan ben je de Sjaak. Jammer dat er dan weer een de facto monopolie situatie ontstaat.

Ach, we vinden ook wel weer een oplossing, maar mijn hoop was dat iemand hier misschien ervaring met deze club had. Ze doen meer op lokale netwerkjes.

In eerste instantie gaf men aan dat ze ruim voldoende IPv4-space hadden, later in het gesprek begreep ik dat het met de komst van ook dit project wel nijpender werd. Er zouden wel mensen aan het nadenken zijn over IPv6, maar concreet nog niks waar ik iets aan had (op afzienbare termijn).

Gelukkig geen CG-NAT op v4, daar was ik ook nog even bang voor in het begin.

[Snow_King]

linkforsoad schreef op dinsdag 20 oktober 2020 @ 15:49:
Helaas zit ik er echt aan vast > http://www.glasvezelassendorp.nl/
In de wandelgangen werd er wat gezegd over gesprekken die gaande zouden zijn met KPN v.w.b. WBA-aanbod, maar niks concreets.

Mijn voorkeur gaat naar XS (of Freedom), omdat we vaste klant zijn bij XS. Helaas kunnen die louter DSL leveren, wat er reeds is, maar de onderliggende verbinding is erg instabiel. Ook Ziggo is geen optie, want de CAI is nog steeds van dezelfde lokale stichting.

ed1703 schreef op dinsdag 20 oktober 2020 @ 15:54:
[...]

Maar vragen die klanten er wel om? Dan ga je als ISP ook wat meer moeite doen om het te leveren.
95% van de klanten weet niet eens wat het is. Goed vooruit, 90%.

Klanten vragen er (vaak) niet om. Het is aan ons als techneuten om er voor te zorgen dat het internet nu en morgen ook nog werkt.

Om die reden zie ik het als mijn 'plicht' om IPv6 overal uit te rollen.

Roetzen schreef op dinsdag 20 oktober 2020 @ 18:22:
[...]

Anno 2020 zou dat helemaal geen "kwestie" meer moeten zijn. Anno 2020 is een IPv4 only verbinding geen volwaardige Internet aansluiting meer. De klanten zouden er al lang niet meer om hoeven vragen, anno 2020 moet een fatsoenlijke ISP het gewoon aanbieden. Punt.

Ik ga niet meer in discussie met een ISP die geen IPv6 aanbiedt. Ik hoef de redenen waarom ze het nou nog niet hebben niet meer te horen. Ik stem met de voeten.

Zo had ik gisteren een call met een leverancier van NAS/SAN systemen voor op mijn werk. Onze infra draait volledig IPv6-only in de backend. We willen een paar honderd TB NVMe storage kopen.

Mijn eis: Het systeem moet IPv6-only kunnen draaien met alle functionaliteit die jullie beloven en daar over ook iSCSI en NFS serveren.

Op hun website staat immers "IPv6 compatible", dus goed, laat maar zien dat het ding ook zonder IPv4 werkt. Anders gaat de deal niet door.

[ed1703]

Snow_King schreef op dinsdag 20 oktober 2020 @ 18:36:
[...]




[...]

Klanten vragen er (vaak) niet om. Het is aan ons als techneuten om er voor te zorgen dat het internet nu en morgen ook nog werkt.

Om die reden zie ik het als mijn 'plicht' om IPv6 overal uit te rollen.

Het probleem is juist dat de industrie en ook nog veel te veel techneuten om het IPv4 probleem heen gaat en er niet voor zorgt dat je IPv6 moet hebben, want men pleistert het wel weer weg met een oplossing. Daarom doen sommige providers ook geen moeite. Je moet eigenlijk gewoon zorgen dat je zaken alleen nog maar KUNT gebruiken via ipv6. Dan gaan veel mensen klagen.

[Dreamvoid]

Het vervelendste is dat er behoorlijk veel, en steeds meer, IPv6-only servers zijn inmiddels, bijvoorbeeld alle thuisservers van mensen met DS-Lite. Daar kan je met een IPv4-only verbinding niet bij.

Snow_King schreef op dinsdag 20 oktober 2020 @ 15:44:
Nog een leuke! Ik heb een LG 65CX OLED in de woonkamer hangen.

Wat valt mij op? YouTube en Netflix op deze TV gebruiken IPv4. De TV doet enkel lookups voor A-records en vervolgens zie ik dat de streams van beide diensten over IPv4 gaan

Wat gebeurt er als je dat ding op een IPv6-only netwerk hangt?

Maar idd, er zit nog veel legacy in dingen als smart tv's enzo. Ik keek onlangs ook of ik een andere DNS server kon instellen op mijn smart tv: kan wel - maar alleen eentje met een IPv4 adres.

[ Voor 65% gewijzigd door Dreamvoid op 20-10-2020 19:13 ]

[Snow_King]

Dreamvoid schreef op dinsdag 20 oktober 2020 @ 19:04:

[...]


Wat gebeurt er als je dat ding op een IPv6-only netwerk hangt?

Maar idd, er zit nog veel legacy in dingen als smart tv's enzo. Ik keek onlangs ook of ik een andere DNS server kon instellen op mijn smart tv: kan wel - maar alleen eentje met een IPv4 adres.

Heb ik net getest en dat werkt dus wel.

De DHCP staat uit op mijn Ziggo ConnectBox en heb zelf een dnsmasq server draaien die hier de DHCP doet.

code:

iptables -A INPUT -m mac --mac-source 64:95:6c:f0:67:4a -j DROP

Zo kon mijn TV geen DHCP verzoek doen en kreeg dus ook geen IPv4 adres.

De UI zegt dan "Controleren".

YouTube werkt, maar Netflix niet. Netflix zegt in de app ook hun servers niet te kunnen bereiken. De TV probeert met zijn IPv4 Link-Local nog steeds naar Netflix servers te verbinden.

Ik dacht dat Netflix helemaal IPv6-ready was?

[Vorkie]

Snow_King schreef op dinsdag 20 oktober 2020 @ 19:39:
[...]

Heb ik net getest en dat werkt dus wel.

De DHCP staat uit op mijn Ziggo ConnectBox en heb zelf een dnsmasq server draaien die hier de DHCP doet.

code:

iptables -A INPUT -m mac --mac-source 64:95:6c:f0:67:4a -j DROP

Zo kon mijn TV geen DHCP verzoek doen en kreeg dus ook geen IPv4 adres.

De UI zegt dan "Controleren".

YouTube werkt, maar Netflix niet. Netflix zegt in de app ook hun servers niet te kunnen bereiken. De TV probeert met zijn IPv4 Link-Local nog steeds naar Netflix servers te verbinden.

Ik dacht dat Netflix helemaal IPv6-ready was?

Netflix is IPv6, op mijn PC kan die 100% IPv6 draaien via de browser.

Dit is 1 v/d adressen van Netflix.

ping6 nrdp-ixanycast.ftl.netflix.com

16 bytes from 2a00:86c0:2040::1, icmp_seq=0 hlim=58 time=20.784 ms
16 bytes from 2a00:86c0:2040::1, icmp_seq=1 hlim=58 time=19.500 ms
^C

En natuurlijk het hoofddomein:

ping6 netflix.com
16 bytes from 2a01:578:3::22fa:377, icmp_seq=0 hlim=48 time=36.063 ms
16 bytes from 2a01:578:3::22fa:377, icmp_seq=1 hlim=48 time=38.933 ms
16 bytes from 2a01:578:3::22fa:377, icmp_seq=2 hlim=48 time=36.410 ms

Op de LG TV met WebOS nog niet getest, ze geven aan dat ie IPv6 ondersteund.

[Dreamvoid]

Ja, Netflix heb ik hier ook even getest op mijn Mac met IPv4 uitgeschakeld, werkt gewoon. Zal dan aan de WebOS app van Netflix, of aan WebOS zelf liggen.

Ook een leuke trouwens voor de liefhebbers van eigen DNS servers: ik kan op mijn providerbox wel DHCP uitschakelen (zodat de clients op mijn LAN geen v4 DNS servers krijgen), maar RA+RDNSS kan ik niet uitschakelen (dus clients krijgen altijd de v6 DNS server van de provider). Nogal vervelend als ik die wil vervangen door een DNS server die DNS64 doet.

[ Voor 53% gewijzigd door Dreamvoid op 20-10-2020 19:55 ]

[Snow_King]

Vorkie schreef op dinsdag 20 oktober 2020 @ 19:47:
[...]


Netflix is IPv6, op mijn PC kan die 100% IPv6 draaien via de browser.

Dit is 1 v/d adressen van Netflix.

Op mijn iPad werkt het ook prima. Het is iets van de app op webOS.

Vorkie schreef op dinsdag 20 oktober 2020 @ 19:47:
[...]

En natuurlijk het hoofddomein:


[...]


Op de LG TV met WebOS nog niet getest, ze geven aan dat ie IPv6 ondersteund.

Dat geef ik juist aan in mijn post ;-) webOS of de apps er op lijken de voorkeur aan IPv4 te geven.

Ook kan webOS niet echt overweg met een IPv6-only omgeving lijkt het. De TV zegt dan ook "Connecting".

Dreamvoid schreef op dinsdag 20 oktober 2020 @ 19:51:
Ja, Netflix heb ik hier ook even getest op mijn Mac met IPv4 uitgeschakeld, werkt gewoon. Zal dan aan de WebOS app van Netflix, of aan WebOS zelf liggen.

Laat even weten! Anders wordt het een bugreport bij Netflix.

Dreamvoid schreef op dinsdag 20 oktober 2020 @ 19:51:
Ook een leuke trouwens voor de liefhebbers van eigen DNS servers: ik kan op mijn providerbox wel DHCP uitschakelen (zodat de clients op mijn LAN geen v4 DNS servers krijgen), maar RA+RDNSS kan ik niet uitschakelen (dus clients krijgen altijd de v6 DNS server van de provider). Nogal vervelend als ik die wil vervangen door een DNS server die DNS64 doet.

Ziggo ConnectBox? Daar heb ik precies het zelfde. DHCP doet ik zelf voor v4, maar voor IPv6 kan ik geen andere nameservers ingeven in de RA. Dat is wel jammer.

[ik222]

De Netflix apps voor smart TV's doet inderdaad geen IPv6, op mijn LG OLED GX gaat Netflix ook via IPv4 terwijl bijvoorbeeld Youtube gewoon netjes standaard via IPv6 gaat op mijn dualstack netwerk.

Via de Chromecast werkt het wel netjes via IPv6 (only).

[Roetzen]

Dreamvoid schreef op dinsdag 20 oktober 2020 @ 19:51:

Ook een leuke trouwens voor de liefhebbers van eigen DNS servers: ik kan op mijn providerbox wel DHCP uitschakelen (zodat de clients op mijn LAN geen v4 DNS servers krijgen), maar RA+RDNSS kan ik niet uitschakelen (dus clients krijgen altijd de v6 DNS server van de provider). Nogal vervelend als ik die wil vervangen door een DNS server die DNS64 doet.

Mijn notoir onbetrouwbare geheugen fluistert mij in dat er onlangs iemand in "[Ziggo] Ervaringen & Discussie - Deel 10" rapporteerde dat er voor de Compal Connect Box een firmware update is uitgebracht die zelf instellen van de DNS servers wel mogelijk maakt. Ik kan dat bericht niet meer terug vinden.

Maar als het klopt ligt het in de lijn der verwachtingen dat het voor de Arris versie ook wel een keer zal komen. En anders allemaal zeuren bij Ziggo...

[Dreamvoid]

Snow_King schreef op woensdag 21 oktober 2020 @ 08:35:
Ziggo ConnectBox? Daar heb ik precies het zelfde. DHCP doet ik zelf voor v4, maar voor IPv6 kan ik geen andere nameservers ingeven in de RA. Dat is wel jammer.

Nee geen Ziggo, ik woon in het buitenland. Ik heb wel netjes dual stack aan de WAN kant, maar op de providerbox is nauwelijks iets in te stellen. Hardcoded nameservers en gateway, geen prefix delegation, geen NAT64 of CLAT.

[Maurits van Baerle]

Iljitsch van Beijnum meldt op de IPv6 mailinglist dat als hij de WiFi uit zet op zijn iPhone hij nu een IPv6 adres krijgt. Dit betekent dat KPN Mobiel nu Dual Stack draait (en geen NAT64 omdat hij gewoon kan pingen).

Is er iemand die dit ook merkt?

[jk-5]

Maurits van Baerle schreef op maandag 26 oktober 2020 @ 11:57:
Iljitsch van Beijnum meldt op de IPv6 mailinglist dat als hij de WiFi uit zet op zijn iPhone hij nu een IPv6 adres krijgt. Dit betekent dat KPN Mobiel nu Dual Stack draait (en geen NAT64 omdat hij gewoon kan pingen).

Is er iemand die dit ook merkt?

Jup, KPN doet al een tijdje NAT64 voor Android, maar heeft het sinds kort ook geactiveerd voor iOS. Het is een 464XLAT setup, geen dual-stack.

[henk-willem]

Maurits van Baerle schreef op maandag 26 oktober 2020 @ 11:57:
Iljitsch van Beijnum meldt op de IPv6 mailinglist dat als hij de WiFi uit zet op zijn iPhone hij nu een IPv6 adres krijgt. Dit betekent dat KPN Mobiel nu Dual Stack draait (en geen NAT64 omdat hij gewoon kan pingen).

Is er iemand die dit ook merkt?

Heb je misschien een linkje naar die mailinglist? Ik merk er overigens nog niks van op mijn iPhone (ook niet na een reboot).

[Maurits van Baerle]

henk-willem schreef op maandag 26 oktober 2020 @ 12:44:
[...]


Heb je misschien een linkje naar die mailinglist? Ik merk er overigens nog niks van op mijn iPhone (ook niet na een reboot).

Het is de list van de IPv6 taskforce, die krijg ik mijn mailbox. Volgens mij is het een closed list want ik zie nergens de inhoud van die lijst op het WWW waar ik naar kan linken.

Het is feitelijk wat ik boven melde, plus een screenshot van ipv6-test.com. Uit de discussie die op zijn email volgde lijkt het misschien regionaal te zijn. Iljitsch zit in Den Haag terwijl iemand in Amstelveen zegt dat het voor hem niet werkt. Iljitsch vermoed dat onderhoud aan de lokale zendmasten wel eens het verschil zou kunnen hebben gemaakt.

Misschien hebben ze nieuwe apparatuur geinstalleerd die nu IPv6 doorgeeft.

[jk-5]

Maurits van Baerle schreef op maandag 26 oktober 2020 @ 12:57:
[...]

Het is de list van de IPv6 taskforce, die krijg ik mijn mailbox. Volgens mij is het een closed list want ik zie nergens de inhoud van die lijst op het WWW waar ik naar kan linken.

Het is feitelijk wat ik boven melde, plus een screenshot van ipv6-test.com. Uit de discussie die op zijn email volgde lijkt het misschien regionaal te zijn. Iljitsch zit in Den Haag terwijl iemand in Amstelveen zegt dat het voor hem niet werkt. Iljitsch vermoed dat onderhoud aan de lokale zendmasten wel eens het verschil zou kunnen hebben gemaakt.

Misschien hebben ze nieuwe apparatuur geinstalleerd die nu IPv6 doorgeeft.

Er kan geen onderscheid worden gemaakt op niveau van zendmast om dit te realiseren, omdat al het verkeer word getunneld naar een centrale core. Volgens mij activeren ze het in batches voor iOS gebruikers, net zoals ze het begin dit jaar ook in batches hebben geactiveerd voor Android gebruikers.

[easyriider]

Bij mij was ook IPv6 ingeschakeld bij KPN maar dat werkte echter niet samen met Private DNS. Die heb ik op NextDNS ingesteld om o.a. advertenties te blokkeren. Dus bij de SIM instellingen IPv6 uitgeschakeld en toen werkte Private DNS weer.

[St00mwals]

Dan ben ik dus bij KPN een van de gelukkigen op mijn iPhone 7 met IPv6

[henk-willem]

St00mwals schreef op maandag 26 oktober 2020 @ 14:48:
Dan ben ik dus bij KPN een van de gelukkigen op mijn iPhone 7 met IPv6

Heb je dat met een zakelijk of een privé abonnement?

[St00mwals]

henk-willem schreef op maandag 26 oktober 2020 @ 16:11:
[...]


Heb je dat met een zakelijk of een privé abonnement?

Privé en net afgelopen voorjaar/zomer gemigreerd van Telfort naar KPN.
Dat was een administratieve omzetting, later zelf een (gratis) nieuwe SIM aangevraagd zodat ik ook technisch over ben gezet.
Zag een paar weken geleden ineens dat ik de beschikking heb over een IPv6 adres.

[Dreamvoid]

easyriider schreef op maandag 26 oktober 2020 @ 14:29:
Bij mij was ook IPv6 ingeschakeld bij KPN maar dat werkte echter niet samen met Private DNS. Die heb ik op NextDNS ingesteld om o.a. advertenties te blokkeren. Dus bij de SIM instellingen IPv6 uitgeschakeld en toen werkte Private DNS weer.

Je moet wel een DNS server instellen die DNS64 doet, anders kan je telefoon niet bij het IPv4 internet.

(edit: ah wacht, PrivateDNS is een IPv4-only service, dat werkt natuurlijk nooit. Raar, in 2020 nog een IPv4-only service bieden)

[ Voor 23% gewijzigd door Dreamvoid op 28-10-2020 12:10 ]

[overhyped]

easyriider schreef op maandag 26 oktober 2020 @ 14:29:
Bij mij was ook IPv6 ingeschakeld bij KPN maar dat werkte echter niet samen met Private DNS. Die heb ik op NextDNS ingesteld om o.a. advertenties te blokkeren. Dus bij de SIM instellingen IPv6 uitgeschakeld en toen werkte Private DNS weer.

Wat raar.. Je schakelt een moderne dienst uit omdat een verouderde dienst niet werkt. Klinkt als verkeerd om

[Dreamvoid]

overhyped schreef op woensdag 28 oktober 2020 @ 12:21:
[...]


Wat raar.. Je schakelt een moderne dienst uit omdat een verouderde dienst niet werkt. Klinkt als verkeerd om

Zo raar is het ook weer niet, dat gebeurt met talloze dingen in de tech wereld.

[Roetzen]

Dreamvoid schreef op woensdag 28 oktober 2020 @ 12:41:
[...]

Zo raar is het ook weer niet, dat gebeurt met talloze dingen in de tech wereld.

Maar dit is niet zomaar "de tech wereld", dit is het hoekje in de techwereld waar de Tweakers bij elkaar komen. En niet zomaar Tweakers, de IPv6 Tweakers. En dan gaan we toch niet bij het eerste hobbeltje IPv6 uitschakelen als we het even niet werkt?

NextDNS ondersteunt wel IPv6. En het ondersteunt ook mobiele platforms. En aangezien die als ze IPv6 hebben allemaal IPv4AES doen via DNS64/NAT64 zou het me verbazen als NextDNS dat niet ondersteunt of in elk geval het niet op zeer korte termijn zal gaan ondersteunen...

Ik zou er in elk geval niet voor gaan betalen als ze dat niet zouden doen...

[easyriider]

Thuis heb ik al enkele jaren IPv6 van Ziggo en op m'n Asus router draait ook NextDNS zonder problemen via IPv6 voor ieder apparaat dat daarmee verbinding heeft op m'n netwerk dus ook m'n telefoon.

Op m'n telefoon onderweg heb ik daar niets aan en heb dus bij de Android verbindings instellingen privé dns ingesteld op de betreffende hostnaam van NextDNS zodat alle apps in Android daar gebruik van maken. Om de een of andere reden werkt dat niet met IPv6, dus kan ik privé dns uitschakelen zodat IPv6 werkt op m'n telefoon, maar heb gekozen om IPv6 uit te schakelen. Voor m'n telefoon is het leuk om IPv6 te hebben via de provider maar dat kan ik voorlopig wel even missen.

Roetzen schreef op woensdag 28 oktober 2020 @ 15:55:

Ik zou er in elk geval niet voor gaan betalen als ze dat niet zouden doen...

Voor NextDNS betaal je niets bij minder dan 300.000 queries per maand.

[ Voor 16% gewijzigd door easyriider op 28-10-2020 21:48 ]

[Dreamvoid]

Roetzen schreef op woensdag 28 oktober 2020 @ 15:55:
[...]
NextDNS ondersteunt wel IPv6. En het ondersteunt ook mobiele platforms. En aangezien die als ze IPv6 hebben allemaal IPv4AES doen via DNS64/NAT64 zou het me verbazen als NextDNS dat niet ondersteunt of in elk geval het niet op zeer korte termijn zal gaan ondersteunen...

DNS64 is wel een iets lastiger verhaal voor 3rd party DNS providers - ik weet niet hoe KPN het heeft ingesteld maar veel mobiele providers gebruiken een eigen prefix (dus niet 64.ff9b::/96), dus een generieke DNS64 server werkt dan niet.

[jk-5]

Dreamvoid schreef op donderdag 29 oktober 2020 @ 08:43:
[...]

DNS64 is wel een iets lastiger verhaal voor 3rd party DNS providers - ik weet niet hoe KPN het heeft ingesteld maar veel mobiele providers gebruiken een eigen prefix (dus niet 64.ff9b::/96), dus een generieke DNS64 server werkt dan niet.

KPN gebruikt gelukkig wel de standaard prefix

[Dreamvoid]

jk-5 schreef op donderdag 29 oktober 2020 @ 08:44:
[...]


KPN gebruikt gelukkig wel de standaard prefix

Ah da’s mooi. Neemt niet weg dat de markt voor 3rd party DNS64 voor mobiel nog ietwat in de kinderschoenen staat. Alleen Cloudflare en Google hebben een DNS64 server, maar andere grote spelers als OpenDNS, Quad9, Level3, Comodo, DNS.WATCH etc allemaal nog niet.

[zx9r_mario]

Dreamvoid schreef op donderdag 29 oktober 2020 @ 08:43:
[...]

DNS64 is wel een iets lastiger verhaal voor 3rd party DNS providers - ik weet niet hoe KPN het heeft ingesteld maar veel mobiele providers gebruiken een eigen prefix (dus niet 64.ff9b::/96), dus een generieke DNS64 server werkt dan niet.

Kijk eens op https://www.tuxis.nl/en/public-doh-dot-dns64-nat64-service/

[Dreamvoid]

Dat ken ik, maar dat is niet enkel een DNS64 service, maar ook NAT64 - oftewel, al je IPv4 verkeer loopt via Tuxis. Normaal gesproken wil je toch liever het verkeer via de NAT64 van je eigen telco blijven sturen - uit oogpunt van snelheid, geolocatie (v4 en v6 verkeer blijven in de zelfde ASN), etc.

Bovendien gaat Tuxis snel plat als de halve wereld hun gratis NAT64 gaat gebruiken

[ Voor 54% gewijzigd door Dreamvoid op 29-10-2020 09:00 ]

[Roetzen]

easyriider schreef op woensdag 28 oktober 2020 @ 21:37:
Thuis heb ik al enkele jaren IPv6 van Ziggo en op m'n Asus router draait ook NextDNS zonder problemen via IPv6 voor ieder apparaat dat daarmee verbinding heeft op m'n netwerk dus ook m'n telefoon.

Thuis heb je Full Dual Stack of DS-Lite.

Op m'n telefoon onderweg heb ik daar niets aan

Want op je mobiele verbinding heb je IPv4AES via DNS64/NAT64 en dan wordt het anders...

en heb dus bij de Android verbindings instellingen privé dns ingesteld op de betreffende hostnaam van NextDNS zodat alle apps in Android daar gebruik van maken. Om de een of andere reden werkt dat niet met IPv6,

En je wilt niet weten wat die reden is?

Privé dns doet geen IPv6 en het begint er op te lijken dat dat de reden is. Of in elk geval het eerste struikelblok...

[...]

Voor NextDNS betaal je niets bij minder dan 300.000 queries per maand.

Dat is mooi. Ik heb geen idee of ik daar genoeg aan zou hebben voor bescheiden privé gebruik. Maar mooi is het.

[ Voor 8% gewijzigd door Roetzen op 29-10-2020 10:20 ]

[Roetzen]

Dreamvoid schreef op donderdag 29 oktober 2020 @ 08:49:
[...]

Ah da’s mooi. Neemt niet weg dat de markt voor 3rd party DNS64 voor mobiel nog ietwat in de kinderschoenen staat. Alleen Cloudflare en Google hebben een DNS64 server, maar andere grote spelers als OpenDNS, Quad9, Level3, Comodo, DNS.WATCH etc allemaal nog niet.

Dan zullen ze er toch een tandje bij moeten doen. Zeker degenen die ook expliciet diensten aanbieden voor mobiel. De mobiele providers gaan over op IPv6 only netwerken met IPv4 As A Service en wie niet meegaat mist de boot. IPv6 dan maar uitschakelen is AD 2020 natuurlijk geen oplossing. Zolang dat überhaupt nog kan... Nu kan het kennelijk nog bij KPN maar dat zal niet zo blijven. Als je als provider voor een IPv6 only kern netwerk gaat, dan wil je er niet tot in de eeuwigheid een IPv4 only netwerk naast blijven draaien.

[Dreamvoid]

Roetzen schreef op donderdag 29 oktober 2020 @ 11:17:
[...]

Dan zullen ze er toch een tandje bij moeten doen. Zeker degenen die ook expliciet diensten aanbieden voor mobiel. De mobiele providers gaan over op IPv6 only netwerken met IPv4 As A Service en wie niet meegaat mist de boot.

Komt allemaal wel. Er zijn al niet heel veel mensen die op hun desktop hun DNS server aanpassen, op mobiel zal dat aantal nog een stuk kleiner zijn. Ik zat net even te kijken, op mijn iPhone kan ik niet eens een andere DNS server instellen.

[Snow_King]

Ik kan er maar bar weinig over vinden, maar iemand een idee of Starlink eigenlijk IPv6 gaat ondersteunen? En via welk ASN routeren ze op internet?

Je komt wel quotes tegen dat ze iets gebruiken wat nog efficiënter is dan v6, maar dat snap ik niet helemaal.

[Brahiewahiewa]

Snow_King schreef op dinsdag 3 november 2020 @ 00:11:
...
Je komt wel quotes tegen dat ze iets gebruiken wat nog efficiënter is dan v6, maar dat snap ik niet helemaal.

Wordt samen met het DoD ontwikkeld dus zal wel staatsgeheim zijn

[ANdrode]

Snow_King schreef op dinsdag 3 november 2020 @ 00:11:
Ik kan er maar bar weinig over vinden, maar iemand een idee of Starlink eigenlijk IPv6 gaat ondersteunen? En via welk ASN routeren ze op internet?

Je komt wel quotes tegen dat ze iets gebruiken wat nog efficiënter is dan v6, maar dat snap ik niet helemaal.

https://www.peeringdb.com/net/18747

Adverteert nu twee ranges (RIPEstat) waarvan één /24 voor IPv4 en een IPv6 range.

Een techniek waarbij je alleen IPv6 ondersteunt en layer 2/3 combineert lijkt mij logisch.

DOCSIS (en waarschijnlijk ook satelliet internet over tv-satellieten) heeft een vrij aparte encapsulatie waarbij je meerdere micro-slots in een transport stream in een mux gebruikt. Dat kan wel compacter.

Routing beslissingen zou ik op de grond doen in verband met beschikbare rekenkracht én de voorspelbaarheid van de routes. Het klinkt bijna als een use case voor segment routing - maar ik ben geen expert hierin.

[duvekot]

Snow_King schreef op dinsdag 3 november 2020 @ 00:11:
Ik kan er maar bar weinig over vinden, maar iemand een idee of Starlink eigenlijk IPv6 gaat ondersteunen? En via welk ASN routeren ze op internet?

Je komt wel quotes tegen dat ze iets gebruiken wat nog efficiënter is dan v6, maar dat snap ik niet helemaal.

Ik kwam dit tegen:

https://caseyhandmer.word.../starlink-packet-routing/

(Maar misschien is dit onderwerp wel goed voor een eigen topic?)

[aawe mwan]

Toevallig zijn beide IPv6 bugs deze week weer langsgekomen bij mij.

• IPv6 connectiviteit valt weg in Ubuntu 18.04 tijdens apt upgrade:
  het bleek dat vaste IPv6-adres dat ik ingesteld had, als gevolg van de upgrade verdween uit de lijst die je ziet met ip -6 addr show . De upgrade zelf leek afgerond. Een reboot loste het probleem op.
• IPv6 connectiviteit valt weg in Ubuntu 16.04 bij SSH sessies naar IPv6:
  Niet alleen de SSH sessies kunnen niet meer communiceren, maar kan ik ook geen enkel IPv6 adres meer pingen of benaderen via de browser. Als ik op de desktop het vinkje bij "Enable WiFi" uit zet en weer aan zet, dan doet ongeveer een halve minuut later IPv6 het weer (de SSH sessies draaien weer).

[Bigs]

Glasvezelprovider TriNed gaat de komende tijd actief al haar klanten migreren naar IPv6 met CGNAT voor IPv4: https://www.trined.nl/ipv6/

Een publiek IPv4 adres blijft optioneel verkrijgbaar.

[Roetzen]

Nieuwe metingen:




KPN gaat lekker...

[Vorkie]

https://www.abuseipdb.com...00:2700:30:1270:f9c2:7897

Hier zo'n voorbeeld van een IPv6 scanner... @Snow_King

[Snow_King]

Vorkie schreef op zondag 22 november 2020 @ 11:32:
https://www.abuseipdb.com...00:2700:30:1270:f9c2:7897

Hier zo'n voorbeeld van een IPv6 scanner... @Snow_King

Interessant! Heb ik nog niet voorbij zien komen.

[Dreamvoid]

Je zou toch verwachten dat men de /64 prefix logt voor abuse-doeleinden, individuele adressen is nogal zinloos. Ik bedoel, het PE adres dat vandaag aan het scannen is, zie je na morgen nooit meer terug.

[ Voor 28% gewijzigd door Dreamvoid op 23-11-2020 21:09 ]

[Maurits van Baerle]

Dreamvoid schreef op maandag 23 november 2020 @ 21:06:
Je zou toch verwachten dat men de /64 prefix logt voor abuse-doeleinden, individuele adressen is nogal zinloos. Ik bedoel, het PE adres dat vandaag aan het scannen is, zie je na morgen nooit meer terug.

Hoe weet je dat een /64 volstaat? Redelijk wat ISP's geven /56 of zelfs /48 uit.

[Dreamvoid]

Maurits van Baerle schreef op woensdag 25 november 2020 @ 11:18:
[...]

Hoe weet je dat een /64 volstaat? Redelijk wat ISP's geven /56 of zelfs /48 uit.

Je kan ook /48's of /56's gaan blacklisten, maar hoe groter de prefix, hoe groter de kans dat je ongewild andermans netwerken ook gaat blokkeren. Veel hosting bedrijven geven bv aan VM's/VPSsen een /64, als je dan /56's gaat blacklisten dan zijn er 255 andere VPS klanten 'collateral damage'. Idem met mobiel, waar de klant een enkele /64 krijgt voor tethering. Je kan het natuurlijk per AS anders doen, maar dat wordt een hele administratie (welke provider geeft welk soort prefixes aan hun klanten).

En laten we wel zijn, in het algemeen runnen dit soort scanners op geinfecteerde systemen (in botnets) die niet zelf hun prefix kunnen wijzigen, wel hun 64-bit suffix. Idem met kinderen die lopen te klooien op een gameserver, blacklist de /64 en je bent die gamer kwijt (en iedereen in zijn huis). Blacklist een enkel IPv6 adres, en hij kan morgen weer inloggen (of eerder, als hij weet hoe hij zijn PE adres kan verversen).

[ Voor 6% gewijzigd door Dreamvoid op 25-11-2020 12:00 ]

[Maurits van Baerle]

Ja, da’s waar. Een /64 blokkeren is niet perfect maar waarschijnlijk meestal goed genoeg.

[aawe mwan]

Ik wilde de WiFi aansluiting van mijn computer delen met een Raspberry Pi die geen WiFi heeft, beide draaien Ubuntu 20.04. Ik heb ze op elkaar aangesloten met een netwerkkabeltje en op de computer "shared to other computers" ingesteld voor de netwerkpoort. En dat werkt prima, dit zijn de adressen de Pi krijgt:

$ ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:xx:yy:zz brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.253/24 brd 10.42.0.255 scope global dynamic eth0
       valid_lft 3358sec preferred_lft 3358sec
    inet6 fe80::dea6:32ff:fexx:yyzz/64 scope link 
       valid_lft forever preferred_lft forever

Via IPv4 kan de Pi prima het internet op, om Ubuntu updates op te halen. Geen issues, daar gaat het niet over.

Maar de aandachtige lezer heeft al gezien dat het IPv6 adres dat ik krijg een Link-local adres is.
Dus als ik vanaf mijn computer verbinding zoek met deze Pi (via IPv6), moet dat op deze manier:

$ ping fe80::dea6:32ff:fexx:yyzz%eno1
$ ssh fe80::dea6:32ff:fexx:yyzz%eno1

Dat %eno1 is verplicht bij local-link adressen, waarom?

Nou wil ik het mezelf natuurlijk gemakkelijk maken door dit IPv6 adres in /etc/hosts toe te voegen.
Als ik dit doe compleet met %eno1, dan herkent hij de naam die ik het adres geef niet eens.

Ik moet het adres dus zonder %eno1 in /etc/hosts zetten, maar hoe kan ik het dan gebruiken?
Je kunt %eno1 niet achter een hostname plakken op dezelfde manier als je dat wel kunt doen met het IPv6-adres zelf, in plaats daarvan moet je de "bind" optie gebruiken die per commando verschilt:

$ ping -I eno1 pi-v6
$ ssh -B eno1 pi-v6

Er zijn volgens mij meerdere IPv6-dingen die beter kunnen. Is ergens een oplossing mogelijk?

[Dreamvoid]

Het probleem van je hosts file is een bug in glibc : https://sourceware.org/bugzilla/show_bug.cgi?id=14413

Maar dit is een beetje een X-Y probleem, want dat is niet je echte probleem hier Wat je nl hiermee doet is NAT opzetten voor IPv6: je Ubuntu computer heeft een global IPv6 adres, en zou dat dan via link-local adressering doorzetten naar de Pi. Zo gaat het inderdaad met klassieke IPv4 NAT (global adres aan de ene kant, lokale adressen aan de andere kant), maar IPv6 heeft geen NAT, en link-local addressen zijn nooit bedoeld om richting het internet gerouteerd te worden.

Normaal gesproken werkt IPv6 connection sharing in Ubuntu (NetworkManager) via prefix delegation: de Ubuntu computer vraagt een /64 prefix aan bij de router, en adverteert die /64 richting de Pi, die vervolgens een volledig adres voor zichzelf genereert. Zo werkt bv ook "tethering" op IPv6 mobiele netwerken - maar dat vereist wel dat de router prefix delegation doet en ook netjes een /64 afgeeft. Veel consumenten routers doen dat niet.

Andere opties (die je wel zelf moet uitzoeken/beunen) zijn NDP/RA relaying, of de WiFi en Ethernet interfaces op de Ubuntu computer koppelen via bridging, zodat de Pi rechtstreeks met de router kan praten.

[ Voor 3% gewijzigd door Dreamvoid op 29-11-2020 01:52 ]

[Brahiewahiewa]

aawe mwan schreef op zaterdag 28 november 2020 @ 20:51:
... Is ergens een oplossing mogelijk?

'k Heb het al eerder gezegd maar: koop nou gewoon een switch!

[ Voor 15% gewijzigd door Brahiewahiewa op 29-11-2020 06:43 ]

[aawe mwan]

Dreamvoid schreef op zondag 29 november 2020 @ 01:49:
Het probleem van je hosts file is een bug in glibc : https://sourceware.org/bugzilla/show_bug.cgi?id=14413

Maar dit is een beetje een X-Y probleem, want dat is niet je echte probleem hier

Op deze manier heb je inderdaad geen IPv6 connectiviteit naar internet, dat zie je goed.

X-Y probleem ja en nee: ik heb als gebruiker gewoon het vinkje "share to other computers" aangezet bij IPv4 en IPv6, ik heb niet gevraagd om er voor IPv6 ook een NAT van te maken of iets anders dat niet kan.

Wat ik bijvoorbeeld verwacht had, was dat mijn computer gewoon standaard een "pooltje" aan IPv6 adressen zou krijgen van de router, die hij naar eigen inzicht zou kunnen verdelen over zijn virtuele machines, containers en ook de computers waarmee het internet gedeeld wordt. In plaats daarvan vraagt/krijgt (?) Ubuntu 20.04 maar 1 of 2 /64 IPv6 adressen van mijn router. Dat is toch veel te weinig?

[aawe mwan]

Brahiewahiewa schreef op zondag 29 november 2020 @ 06:41:
koop nou gewoon een switch!

Waar moet ik die switch op aansluiten dan en op welke manier gaat die het IPv6 probleem oplossen?

[Muis666]

aawe mwan schreef op zondag 29 november 2020 @ 10:24:
[...]
Wat ik bijvoorbeeld verwacht had, was dat mijn computer gewoon standaard een "pooltje" aan IPv6 adressen zou krijgen van de router, die hij naar eigen inzicht zou kunnen verdelen over zijn virtuele machines, containers en ook de computers waarmee het internet gedeeld wordt. In plaats daarvan vraagt/krijgt (?) Ubuntu 20.04 maar 1 of 2 /64 IPv6 adressen van mijn router. Dat is toch veel te weinig?

Zoals hierboven al vermeld ondersteunt jouw router waarschijnlijk geen prefix delegation. Daarom werkt jouw verwachting niet.

Zoals ook al eerder is voorgesteld kun je je ethernet poort en je wifi poort bridgen. Hiermee kan je Pi rechtstreeks met je router praten en krijgt hij hiervan ook een globaal IPv6 adres.

Je virtuele machines geef je ook toegang tot je wireless lan adapter. Daarmee kunnen ze dan ook met je router praten en een globaal IPv6 adres krijgen. Een tweede IPv6 router is in jouw geval echt niet noodzakelijk...