Het grote IPv6 topic

[supayoshi]

Nou mensen van de IPv6 het werkt bij mij op OPNsense met KPN glas, alle clients krijgen een IPv6 lease, maar ik had eerst aanstaan dat ik geen controle kreeg over het netwerk, maar inmiddels de optie ;
"Allow manual adjustment of DHCPv6 and Router Advertisements" aangevinkt, en nu heb ik de optie om DHCPv6 in te stellen, dat ook gedaan... en mijn piHole IPv6 adres als DNS server ingezet bij DHCPV6, echter kan ik niet goed zien welke DNS server ik nu gebruik op Windows lijkt dit nog steeds het IPv6 adres van de router te zijn en niet van de piHole, heb de lease al vernieuwd zonder resultaat... blijft router adres en niet pihole zelf.

Maar de requests lijken wel naar piHole te gaan , hoe controleer ik nu vanaf mijn client waar mijn DNS request naar toe gaat?

[arjans]

Update over Delta Fiber Netwerk: gisteren met de helpdesk gesproken omdat zij in mijn woonplaats ook glasvezel gaan aanleggen (bij >20% inschrijving) met alleen de eerder genoemde 4 providers erop. De helpdeskmedewerker gaf aan dat IPv6 er voorlopig nog niet aan zit te komen, maar hij durfde wel een hele grove schatting te geven: "over een jaar ofzo".

[Dreamvoid]

supayoshi schreef op donderdag 10 februari 2022 @ 15:33:
Nou mensen van de IPv6 het werkt bij mij op OPNsense met KPN glas, alle clients krijgen een IPv6 lease, maar ik had eerst aanstaan dat ik geen controle kreeg over het netwerk, maar inmiddels de optie ;
"Allow manual adjustment of DHCPv6 and Router Advertisements" aangevinkt, en nu heb ik de optie om DHCPv6 in te stellen, dat ook gedaan... en mijn piHole IPv6 adres als DNS server ingezet bij DHCPV6, echter kan ik niet goed zien welke DNS server ik nu gebruik op Windows lijkt dit nog steeds het IPv6 adres van de router te zijn en niet van de piHole, heb de lease al vernieuwd zonder resultaat... blijft router adres en niet pihole zelf.

Maar de requests lijken wel naar piHole te gaan , hoe controleer ik nu vanaf mijn client waar mijn DNS request naar toe gaat?

Zo werkt het op de meeste routers tegenwoordig, ze adverteren enkel zichzelf als IPv6 DNS server, en je stelt dan op de router in waar de requests van daar uit worden verdergeleid (in jouw geval, de pi-hole).

Als je zeker wil weten dat je clients de pi-hole gebruiken, maak op de pi-hole een dummy DNS entry aan ("blaba.home" = 192.168.1.255 ofzo), en dan doe je op de client nslookup blabla.home , als je dat IP adres terugkrijgt dan weet je dat t werkt.

[ericafterdark]

Wie weet help ik er ooit iemand mee.

IPv6 op pfSense met Freedom Internet. Zal neem ik ook werken op KPN en co.

WAN




LAN




Verder worden alle IPv6-gerelateerde firewall rules in een standaard installatie automatisch aangemaakt.

[Dreamvoid]

Krijg je een /48?

[supayoshi]

Dreamvoid schreef op donderdag 10 februari 2022 @ 16:19:
Krijg je een /48?

Ja volgens mij werkt het wel want zie requests in pihole, maar heb nu een klein probleempje mijn ene raspberry wil niet aan de ipv6 fixed
maar eh ja ik moet dus een IPv6 dummy aanmaken, voor IPv4 werkt het namelijk al prima. met pihole

[ Voor 16% gewijzigd door supayoshi op 10-02-2022 16:24 ]

[Dreamvoid]

RnB schreef op donderdag 10 februari 2022 @ 09:37:
Nu dus mijn regels op prefix aangemaakt en ben dus benieuwd hoe ik dit strakker kan krijgen door ze op host basis aan te maken. Erg lastig met dynamische adressen. Met statische adressen werken is een oplossing, maar dat zie ik niet zitten. SLAAC werkt goed en simpel.

Sommige firewalls kunnen rules op basis van MAC adressen doen, dan zijn dynamische IPv6 adressen geen probleem meer.

[ericafterdark]

Dreamvoid schreef op donderdag 10 februari 2022 @ 16:19:
Krijg je een /48?

Yes!

[RnB]

Dreamvoid schreef op donderdag 10 februari 2022 @ 16:25:
[...]

Sommige firewalls kunnen rules op basis van MAC adressen doen, dan zijn dynamische IPv6 adressen geen probleem meer.

Haa, zo makkelijk kan het inderdaad zijn.
Bedankt voor de tip!

[Dreamvoid]

Merci Makkelijker ook bij een prefix-change.

[ Voor 70% gewijzigd door Dreamvoid op 10-02-2022 16:49 ]

[nero355]

supayoshi schreef op donderdag 10 februari 2022 @ 07:59:
Beste mensen in de IPV6 topic, ik heb sinds gisteren IPV6 enabled op mijn KPN lijn, dat werkt.
Alleen kan ik mijn pihole niet instellen als DNS server op ipv6 omdat de devices in het LAN nu een SLAAC adres krijgen (standaard)

Nu wil ik DHCPv6 gaan gebruiken om de controle terug te krijgen, maar lees dat je hier een /64 voor nodig hebt en KPN slechts een /48 uitdeelt? Hoe nu verder, ik maak gebruik van OPNsense en wil IPV6 graag gebruiken maar wel de DNS server kunnen instellen voor mijn clients tbh

Ik zou zeggen doe gewoon dit : Dreamvoid in "Het grote IPv6 topic"

fvbommel schreef op donderdag 10 februari 2022 @ 08:42:
Het normale probleem met globale IPv6 adressen is dat als je provider de prefix veranderd, de IPv6-adressen van al je apparaten mee veranderen.

Hij heeft KPN en die doen het als enige ISP in Nederland op een fatsoenlijke manier :

Beste (nieuwe) klant,

Dit zijn jouw gegevens die altijd hetzelfde zullen blijven :

Klantnummer : 1234567890
Jouw IPv4 adres : xxx.xxx.xxx.xxx
Jouw IPv6 subnet : < een heleboel tekens en dan blijkbaar /48 >

Deze worden dynamisch toegekend, maar zullen nooit veranderen!

Dat is tenminste wat ik heb begrepen van meerdere posts hier op GoT die door medeTweakers zijn geplaatst die KPN hebben

Een dergelijke brief kreeg ik namelijk ook ooit toen ik ergens in 1999 of zo eindelijk MXSTREAM toegang kreeg!

supayoshi schreef op donderdag 10 februari 2022 @ 15:33:
Maar de requests lijken wel naar piHole te gaan , hoe controleer ik nu vanaf mijn client waar mijn DNS request naar toe gaat?

nslookup tweakers.net

Laat vanzelf alle gegevens zien!

En vergeet natuurlijk niet om gewoon in je Pi-Hole Query Log te kijken en dan specifiek naar de AAAA Requests

Dreamvoid schreef op donderdag 10 februari 2022 @ 15:57:
Als je zeker wil weten dat je clients de pi-hole gebruiken, maak op de pi-hole een dummy DNS entry aan ("blaba.home" = 192.168.1.255 ofzo), en dan doe je op de client nslookup blabla.home , als je dat IP adres terugkrijgt dan weet je dat t werkt.

Een beetje Pi-Hole gebruiker zal sowieso voor al zijn apparaten een DNS Record hebben dus die kan je altijd nog gebruiken, echter hoeft dat dus helemaal niet als het goed is/allemaal goed gaat!

[Dreamvoid]

nero355 schreef op donderdag 10 februari 2022 @ 16:50:
Hij heeft KPN en die doen het als enige ISP in Nederland op een fatsoenlijke manier :

Nou is er op zich wel wat te zeggen voor een eens-in-het-jaar veranderende prefix: je bent wat moeilijker langjarig te tracken.

[nero355]

Dreamvoid schreef op donderdag 10 februari 2022 @ 17:00:
Nou is er op zich wel wat te zeggen voor een eens-in-het-jaar veranderende prefix: je bent wat moeilijker langjarig te tracken.

Daar is dat lelijke netwerkvervuilende Privacy MAC Address gedoe toch voor

[Dreamvoid]

Privacy addressing verandert enkel de laatste 64-bits zodat de individuele device inderdaad na 24u 'verdwijnt' (dus veiliger voor bad guys die proberen om direct te connecten naar jouw device). MAC-adres rotatie zoals op Android/iOS zorgt ervoor dat ze je niet meer eenvoudig kunnen tracken tussen WiFi netwerk bij de McDonalds en WiFi netwerk bij de Starbucks.

Maar met een voor-eeuwig-statische prefix ziet het internet wel telkens dezelfde prefix langskomen dus ze weten dat de bezoeker van telkens hetzelfde subnet vandaan komt.

[ Voor 28% gewijzigd door Dreamvoid op 10-02-2022 17:32 ]

[Snow_King]

RnB schreef op donderdag 10 februari 2022 @ 09:37:
@Snow_King Tja, wat wil ik ermee bereiken? Eigenlijk wil ik er alleen maar van leren, ervaring ermee opdoen. Ik heb geen servers draaien die van buitenaf bereikbaar moeten zijn, gewoon een gesegmenteerd thuisnetwerk waar ik continu bezig ben om alles nog vaster te draaien dan dat het al is.

Nu dus mijn regels op prefix aangemaakt en ben dus benieuwd hoe ik dit strakker kan krijgen door ze op host basis aan te maken. Erg lastig met dynamische adressen. Met statische adressen werken is een oplossing, maar dat zie ik niet zitten. SLAAC werkt goed en simpel.

Maar wat is 'strakker' dan per host? In principe moet je elke host in een prefix/VLAN het zelfde behandelen, dus waarom die wens om het per host te doen?

Daarom dus de vraag: Wat wil je bereiken?

Zoals ik aan gaf blokkeer ik alles behalve related TCP/UDP en ICMPv6. Voor mij werkt dat prima.

[Dreamvoid]

In zijn geval wil hij wellicht 1 host anders behandelen

[RnB]

Snow_King schreef op donderdag 10 februari 2022 @ 17:51:
[...]

Maar wat is 'strakker' dan per host? In principe moet je elke host in een prefix/VLAN het zelfde behandelen, dus waarom die wens om het per host te doen?

Daarom dus de vraag: Wat wil je bereiken?

Zoals ik aan gaf blokkeer ik alles behalve related TCP/UDP en ICMPv6. Voor mij werkt dat prima.

Wat @Dreamvoid zegt, bijvoorbeeld in mijn IoT segment bepaal ik per host waar deze mee mag communiceren. Nu maakt geen enkel apparaat in dit segment gebruik van IPv6 (nog), dus maakt het hier minder uit.
Maar door de filter op prefix ipv hostadres wordt alleen de eerste rule gehit en niet de rule die ik wil laten hitten.

[Snow_King]

RnB schreef op donderdag 10 februari 2022 @ 18:35:
[...]


Wat @Dreamvoid zegt, bijvoorbeeld in mijn IoT segment bepaal ik per host waar deze mee mag communiceren. Nu maakt geen enkel apparaat in dit segment gebruik van IPv6 (nog), dus maakt het hier minder uit.
Maar door de filter op prefix ipv hostadres wordt alleen de eerste rule gehit en niet de rule die ik wil laten hitten.

Kan je de IoT apparaten dan niet beter in een eigen VLAN/WiFi SSID plaatsen?

Dat lijkt mij een makkelijkere oplossing. Zo kan je per netwerk segment netjes filteren.

Wat jij wil doen heb ik nog niemand zien doen.

[RobertMe]

Snow_King schreef op donderdag 10 februari 2022 @ 18:37:
[...]

Kan je de IoT apparaten dan niet beter in een eigen VLAN/WiFi SSID plaatsen?

Dat lijkt mij een makkelijkere oplossing. Zo kan je per netwerk segment netjes filteren.

Wat jij wil doen heb ik nog niemand zien doen.

Hij heeft het over "per host".

Zelf heb ik dat ook, IoT WLAN & VLAN, internet access wordt daarop geblokkeerd en alleen bepaalde apparaten mogen internet op. (LXC container waar Home Assistant in draait, de Hue Bridge voor updates, .... Maar ESPs bv weer niet dus).

Edit:
Voor de duidelijkheid: mijn IoT VLAN is dan nog IPv4 only en dan met statische IPs. Een IPv6 oplossing heb ik dus ook niet.

[ Voor 9% gewijzigd door RobertMe op 10-02-2022 18:43 ]

[supayoshi]

Inmiddels aardig op weg met de IPv6 het begint te werken, maar nu de vraag; hoeveel prefixes heb ik beschikbaar bij KPN? ik heb nu 2 subnets met een IPV6 tracking op de KPN WAN, en dat werkt goed. Alleen mijn derde met prefix 2, krijgt geen werkende traceroute...

[Snow_King]

RobertMe schreef op donderdag 10 februari 2022 @ 18:41:
[...]

Hij heeft het over "per host".

Zelf heb ik dat ook, IoT WLAN & VLAN, internet access wordt daarop geblokkeerd en alleen bepaalde apparaten mogen internet op. (LXC container waar Home Assistant in draait, de Hue Bridge voor updates, .... Maar ESPs bv weer niet dus).

Edit:
Voor de duidelijkheid: mijn IoT VLAN is dan nog IPv4 only en dan met statische IPs. Een IPv6 oplossing heb ik dus ook niet.

Ik snap de vraag, maar per host gaat gewoon niet lekker werken.

Daarom mijn suggestie voor een IoT VLAN waar je strict kan handhaven.

Ivm de dynamische IPv6 adressen kan je niet zo maar per host filteren.

Eventueel wel als je firewall op destination MAC kan filteren?

[ericafterdark]

nero355 schreef op donderdag 10 februari 2022 @ 16:50:
Hij heeft KPN en die doen het als enige ISP in Nederland op een fatsoenlijke manier :

Freedom Internet doet dit ook op die manier.

Ik werd klant en ontving direct een mail met mijn IPv4 /32 en mijn IPv6 /48.

[ANdrode]

Snow_King schreef op donderdag 10 februari 2022 @ 18:37:
[...]

Kan je de IoT apparaten dan niet beter in een eigen VLAN/WiFi SSID plaatsen?

Dat lijkt mij een makkelijkere oplossing. Zo kan je per netwerk segment netjes filteren.

Wat jij wil doen heb ik nog niemand zien doen.

Uiteindelijk is kleinere netwerksegmenten hier een goede oplossing? Dat helpt ook met isolatie in de situatie waar een aanvaller opeens een mac adres cloned of wijzigt.

Een /64 per device is helemaal prima, je hebt zat /64s?

[Brahiewahiewa]

RobertMe schreef op donderdag 10 februari 2022 @ 18:41:
[...]Edit:
Voor de duidelijkheid: mijn IoT VLAN is dan nog IPv4 only en dan met statische IPs. Een IPv6 oplossing heb ik dus ook niet.

Een oplossing voor ipv6 gaat er ook niet komen. Ipv6 is ontwikkeld met de gedachte dat je eigen LAN "hostile" is. Ik bedoel: ip4 gaat er van uit dat het eigen LAN te vertrouwen is. Daarom werken firewall rules en managed switches. Maar al vele jaren blijkt dat je eigen LAN toch niet te vertrouwen is: je kunt er niet op vertrouwen dat een ip-adres ook daadwerkelijk verwijst naar het apparaat wat jij in gedachten had, toen je het toekende. En je kunt er ook niet op vertrouwen dat het MAC-adres toebehoort aan het apparaat waarop jij het uitgelezen hebt. En daarmee worden alle veiligheidsvoorzieningen die daar wel op vertrouwen, overbodig.

Ipv6 heeft juist allerlei mogelijkheden om zelf ip-adressen te verzinnen; je hebt er 4 miljard in een /64. Waarom zou je het gebruik daarvan willen beperken?

[Keiichi]

De storing in IPv6 waar ik gisteren mee te maken had, lag aan routers die tegen een hardware limiet aanliepen voor aantal ipv6 routes. Dit was dan op een router op het ams-ix met een goed aantal peers, probleem was voor nu opgelost door verkeer langs hun transit te laten lopen (dus default route te laten nemen en peered routes helaas niet nemen)

Ik heb zelf geen goede kijk op wat providers een beetje aan hardware gebruiken, maar zou met dat ipv6 blijft groeien niet meer partijen tegen dergelijke problemen aan gaan lopen?

[Snow_King]

Keiichi schreef op vrijdag 11 februari 2022 @ 08:50:
De storing in IPv6 waar ik gisteren mee te maken had, lag aan routers die tegen een hardware limiet aanliepen voor aantal ipv6 routes. Dit was dan op een router op het ams-ix met een goed aantal peers, probleem was voor nu opgelost door verkeer langs hun transit te laten lopen (dus default route te laten nemen en peered routes helaas niet nemen)

Ik heb zelf geen goede kijk op wat providers een beetje aan hardware gebruiken, maar zou met dat ipv6 blijft groeien niet meer partijen tegen dergelijke problemen aan gaan lopen?

Dan heb je wel echt een hele, hele oude router hoor. Alle moderne platformen kunnen echt prima IPv6 zo goed routeren als ze IPv4 kunnen.

Ik vind het een apart verhaal als ik het zo lees.

[Keiichi]

Als ik beetje rondkijk hoeveel v6 subnets er nu zijn, zou het wel meevallen op basis van https://www.cidr-report.org/v6/as2.0/ . Die zeggen een kleine 150.000

Ik weet ook niet met welke appartuur ze werken, uit de specs van willekeurige hardware van juniper/cisco word ik weiniger wijzer wat de specs zijn.

[Snow_King]

Keiichi schreef op vrijdag 11 februari 2022 @ 10:25:
Als ik beetje rondkijk hoeveel v6 subnets er nu zijn, zou het wel meevallen op basis van https://www.cidr-report.org/v6/as2.0/ . Die zeggen een kleine 150.000

Ik weet ook niet met welke appartuur ze werken, uit de specs van willekeurige hardware van juniper/cisco word ik weiniger wijzer wat de specs zijn.

Even een 'show route summary' van een router die full-table IPv4 en IPv6 heeft:

code:

inet.0: 873267 destinations, 2710884 routes (873228 active, 0 holddown, 77 hidden)
Limit/Threshold: 1048576/1048576 destinations 4194304/4194304 routes
              Direct:     14 routes,     14 active
               Local:     14 routes,     14 active
                OSPF:     97 routes,     97 active
                 BGP: 2710707 routes, 873051 active
              Static:     51 routes,     51 active
           Aggregate:      1 routes,      1 active

inet6.0: 137857 destinations, 447745 routes (137776 active, 0 holddown, 161 hidden)
Limit/Threshold: 262144/262144 destinations 524288/524288 routes
              Direct:     16 routes,     16 active
               Local:     30 routes,     30 active
               OSPF3:     84 routes,     83 active
                 BGP: 447586 routes, 137618 active
              Static:     27 routes,     27 active
           Aggregate:      1 routes,      1 active
               INET6:      1 routes,      1 active

Zo veel routes ziet deze router op dit moment dus, een 450k IPv6 routes en 2.7M IPv4 routes.

Veel IPv6 subnets worden niet als /29 of /32 ge-announced op het internet, maar in gedeeltes als een /40 of /48.

Het kan zijn dat iemand op zijn router simpelweg te weinig geheugen heeft ge-alloceerd aan de IPv6 route tabel. Ook kan het zijn dat het gewoon echt oude routers zijn.

Wij werken met Juniper MX204's, MX240's en MX960's met moderne routing Engines er in. Die hebben geen problemen met dit aantal routes.

[Keiichi]

In 2011 hadden ze een Brocade MLX8, daarna hebben ze nooit precies gezegd bij onderhoud wat ze hebben of gingen vervangen. Ga er uit van wel inmiddels :-p

[Hipska]

In het geheugen kan een IPv6 adres/netwerk tot 4x meer plaats dan IPv4 innemen he. Dus best mogelijk dat het een geheugen beperking is.

Als je dan bedenkt dat er een goeie 4 miljard IPv4 adressen zijn, en de hardware nog uit IPv4 only periodes stamt, die dmv de software IPv6 support heeft. En er zijn 0.5M IPv6 (x4) routes + 2.7M IPv4, dan kom je aan een equivalente opslagruimte van zo'n ruime 4 miljoen routes. Er van uitgaande dat elk network (gemiddeld) toch wel ruimte van een duizendtal hosts (/22) heeft, lijkt me dat geen hele vreemde berekening voor wat men toen destijds dacht om nodig te hebben aan fysiek geheugen om alle routes te kunnen opslaan.

Of maak ik hier nu een hele vreemde denkfout?

[Snow_King]

Keiichi schreef op vrijdag 11 februari 2022 @ 10:42:
In 2011 hadden ze een Brocade MLX8, daarna hebben ze nooit precies gezegd bij onderhoud wat ze hebben of gingen vervangen. Ga er uit van wel inmiddels :-p

Een MLX8 kan op het moderne internet niet meer mee komen om een full-table BGP te draaien.

Ook draaien die systemen vaak IPv6 nog in software en niet in hardware.

Maar nogmaals, een beetje moderne router die een ISP gebruikt heeft er geen enkel probleem mee.

[ericafterdark]

Keiichi schreef op vrijdag 11 februari 2022 @ 08:50:
De storing in IPv6 waar ik gisteren mee te maken had, lag aan routers die tegen een hardware limiet aanliepen voor aantal ipv6 routes. Dit was dan op een router op het ams-ix met een goed aantal peers, probleem was voor nu opgelost door verkeer langs hun transit te laten lopen (dus default route te laten nemen en peered routes helaas niet nemen)

Ik heb zelf geen goede kijk op wat providers een beetje aan hardware gebruiken, maar zou met dat ipv6 blijft groeien niet meer partijen tegen dergelijke problemen aan gaan lopen?

Welke provider?

[Keiichi]

Eiríkr schreef op vrijdag 11 februari 2022 @ 11:20:
[...]


Welke provider?

Een lokale niet al te grote datacenter provider De naam gaat geen meerwaarde bieden, het is geen leaseweb strato of wat dan ook van die grootte

Snow_King schreef op vrijdag 11 februari 2022 @ 11:19:
[...]

Een MLX8 kan op het moderne internet niet meer mee komen om een full-table BGP te draaien.

Ook draaien die systemen vaak IPv6 nog in software en niet in hardware.

Maar nogmaals, een beetje moderne router die een ISP gebruikt heeft er geen enkel probleem mee.

Ik ga er ook vanuit dat ze allang iets nieuws hebben. In die tijd zijn er al in ieder geval 2 grote maintenance windows gehad waarbij steeds 1 van de routers even down moest.

In ieder geval m'n vraag of het een 'groter' probleem zou zijn is wel ontkracht.

[nero355]

Brahiewahiewa schreef op vrijdag 11 februari 2022 @ 05:54:
Een oplossing voor ipv6 gaat er ook niet komen. Ipv6 is ontwikkeld met de gedachte dat je eigen LAN "hostile" is. Ik bedoel: ip4 gaat er van uit dat het eigen LAN te vertrouwen is. Daarom werken firewall rules en managed switches. Maar al vele jaren blijkt dat je eigen LAN toch niet te vertrouwen is: je kunt er niet op vertrouwen dat een ip-adres ook daadwerkelijk verwijst naar het apparaat wat jij in gedachten had, toen je het toekende. En je kunt er ook niet op vertrouwen dat het MAC-adres toebehoort aan het apparaat waarop jij het uitgelezen hebt. En daarmee worden alle veiligheidsvoorzieningen die daar wel op vertrouwen, overbodig.

Dat is leuk, maar je kan je ook afvragen of dat wel belangrijk is/was in een bepaalde situatie, want niet elk apparaat in je netwerk is gelijk ook een belangrijke Server/Router/Switch/Accesspoint die als het goed is sowieso een Static IP hebben

Ipv6 heeft juist allerlei mogelijkheden om zelf ip-adressen te verzinnen; je hebt er 4 miljard in een /64. Waarom zou je het gebruik daarvan willen beperken?

Maar toen wilde je iets van controle over het geheel i.p.v. dat alles maar een beetje willekeurig gebeurt en daar ging het hele verhaal over als ik me niet vergis

[fvbommel]

Brahiewahiewa schreef op vrijdag 11 februari 2022 @ 05:54:
Ipv6 heeft juist allerlei mogelijkheden om zelf ip-adressen te verzinnen; je hebt er 4 miljard in een /64. Waarom zou je het gebruik daarvan willen beperken?

Kleine correctie: een /64 heeft er ietsje() meer: 2⁶⁴ is ± 4 miljard × 4 miljard.

[Brahiewahiewa]

nero355 schreef op vrijdag 11 februari 2022 @ 15:42:
[...]
Maar toen wilde je iets van controle over het geheel i.p.v. dat alles maar een beetje willekeurig gebeurt en daar ging het hele verhaal over als ik me niet vergis

Nee. Mijn vraag was al: "Waarom wil je die controle?" Dan is het antwoord "Omdat ik controle wil" een beetje flauw natuurlijk. ;o)

Volges mijn is het vergeijkbaar met de douane op Schiphol die aan de passagiers van een binnenkomende vlucht alleen maar vraagt om een BSN. Je hoeft niet te bewijzen dat het jouw BSN is of het zelfs maar aannemelijk te maken. Gewoon het feit dat je een geldig BSN weet op te noemen doet de douanier besluiten om te zeggen: "Loopt U maar door". Maar dat is geen controle; dat is alleen maar het handhaven van de illusie van controle

[nero355]

Brahiewahiewa schreef op zaterdag 12 februari 2022 @ 12:39:
Mijn vraag was al: "Waarom wil je die controle?" Dan is het antwoord "Omdat ik controle wil" een beetje flauw natuurlijk. ;o)

Ik kan hem nog flauwer maken : Waarom zou je geen controle willen hebben

Volges mijn is het vergeijkbaar met de douane op Schiphol die aan de passagiers van een binnenkomende vlucht alleen maar vraagt om een BSN. Je hoeft niet te bewijzen dat het jouw BSN is of het zelfs maar aannemelijk te maken. Gewoon het feit dat je een geldig BSN weet op te noemen doet de douanier besluiten om te zeggen: "Loopt U maar door". Maar dat is geen controle; dat is alleen maar het handhaven van de illusie van controle

Slechte vergelijking, want die kunnen echt wel checken of jij bent wie je beweert te zijn!

Maar mijn punt is : Kom eens met oplossingen aan i.p.v. maar te roepen dat het allemaal wel prima is zoals het is want dat is het overduidelijk NIET voor iedereen zo te zien!

[Brahiewahiewa]

nero355 schreef op zaterdag 12 februari 2022 @ 14:54:
[...]

Ik kan hem nog flauwer maken : Waarom zou je geen controle willen hebben


[...]

Slechte vergelijking, want die kunnen echt wel checken of jij bent wie je beweert te zijn!

Da's een nog veel flauwer antwoord, natuurlijk. Ik geef dit voorbeeld om aan te geven dat je inderdaad, als je controle wilt, ook moet checken of de gegevens juist zijn. Maar jouw firewall doet dat niet. Die gelooft al die pakketjes op hun blauwe ogen en checkt verder helemaal niet of dat wel klopt

Maar mijn punt is : Kom eens met oplossingen aan i.p.v. maar te roepen dat het allemaal wel prima is zoals het is want dat is het overduidelijk NIET voor iedereen zo te zien!

Tja, ik heb hier een buurman die geen zin heeft om zijn tuin te sproeien en elke avond een regendansje uitvoert. Moet ik nu eerst een betrouwbare manier vinden om op commando een regenbui te veroorzaken, voordat ik mag zeggen dat hij niet zo zinnig bezig is?

[nero355]

Brahiewahiewa schreef op zaterdag 12 februari 2022 @ 15:34:
Da's een nog veel flauwer antwoord, natuurlijk. Ik geef dit voorbeeld om aan te geven dat je inderdaad, als je controle wilt, ook moet checken of de gegevens juist zijn. Maar jouw firewall doet dat niet. Die gelooft al die pakketjes op hun blauwe ogen en checkt verder helemaal niet of dat wel klopt

Ik bedoelde niet alleen de laatste discussie om heel eerlijk te zijn...

Tja, ik heb hier een buurman die geen zin heeft om zijn tuin te sproeien en elke avond een regendansje uitvoert. Moet ik nu eerst een betrouwbare manier vinden om op commando een regenbui te veroorzaken, voordat ik mag zeggen dat hij niet zo zinnig bezig is?

Die manier is er al dus nergens voor nodig!

Maar je kan die vent ook gewoon in zijn waarde laten en niks zeggen als je geen oplossing hebt verder...

[xbeam]

Brahiewahiewa schreef op zaterdag 12 februari 2022 @ 15:34:
[...]
Da's een nog veel flauwer antwoord, natuurlijk. Ik geef dit voorbeeld om aan te geven dat je inderdaad, als je controle wilt, ook moet checken of de gegevens juist zijn. Maar jouw firewall doet dat niet. Die gelooft al die pakketjes op hun blauwe ogen en checkt verder helemaal niet of dat wel klopt

Dat doet jouw firewall zeker wel. Daarom moet je bijv met iptv multicasts de sources validation losser zetten anders dropt hij de door de buurman doorgestuurde tv pakketjes.

Met source validation controleer je de pakketjes en als ze niet uit de originele bron komen kan je ze dropen.
Ps, zet dit nooit uit. En wees voorzichtig met een controle verlaging naar “loose”

JSON:

{"ip": {
      "source-validation": "loose"
        }
 }

zoals @nero355 al zegt heeft de douane net zoals je firewall wel degelijk midden om te controleren of jij de persoon horende bij het opgeven BSN nummer bent. Daarom klopt je vergelijking niet.

Nee. Mijn vraag was al: "Waarom wil je die controle?" Dan is het antwoord "Omdat ik controle wil" een beetje flauw natuurlijk. ;o)

Zonder deze controle kan ik theoretisch (waneer binnen het zelfde isp netwerk) vanaf jouw WAN door een ip uit jouw internet LAN (subnet) te gebruiken met al jouw computer communiceren. Omdat jouw firewall niet controleert of de bron zich binnen jouw LAN of aan de WAN kant bevindt. Je wil deze maten van controle wel kunnen aan aanpassen. Omdat er onderscheid is tussen trusted en not trusted sources.

[ Voor 95% gewijzigd door xbeam op 13-02-2022 16:11 ]

[Snow_King]

Dus, voor een nieuw kantoor ben ik bezig bij Tele2/T-Mobile een Zakelijke Glas verbinding te krijgen. Deze ligt al binnen in het pand, dus ik heb simpelweg de vraag gesteld voor een offerte met 1Gb/s glas en daarbij IPv4 en IPv6.

Ik heb het nogmaals nagevraagd bij verschillende collega’s. Dit is echter een special die eigenlijk bijna nooit geaccepteerd wordt ook niet voor onze grootste klanten. Ik ga hem hierdoor er zeker niet doorheen krijgen voor deze lijn.

Een 'special'? Dat is hoe er naar IPv6 gekeken wordt. Ik vind dat anno 2022 best wel interessant eigenlijk.

AS13127 announced gewoon een /32 en daar kunnen ze ons prima een /48 uit geven technisch gezien.

Ik snap echt niet waarom dit zo moeilijk moet zijn.

[c-nan]

Snow_King schreef op maandag 14 februari 2022 @ 11:54:
Dus, voor een nieuw kantoor ben ik bezig bij Tele2/T-Mobile een Zakelijke Glas verbinding te krijgen. Deze ligt al binnen in het pand, dus ik heb simpelweg de vraag gesteld voor een offerte met 1Gb/s glas en daarbij IPv4 en IPv6.


[...]


Een 'special'? Dat is hoe er naar IPv6 gekeken wordt. Ik vind dat anno 2022 best wel interessant eigenlijk.

AS13127 announced gewoon een /32 en daar kunnen ze ons prima een /48 uit geven technisch gezien.

Ik snap echt niet waarom dit zo moeilijk moet zijn.

Als er in hun workorder geen product bestaat met IPv6 dan is het al snel moeilijk

Het probleem is dus misschien geen technisch probleem maar eerder administratief.

[Snow_King]

c-nan schreef op maandag 14 februari 2022 @ 11:56:
[...]


Als er in hun workorder geen product bestaat met IPv6 dan is het al snel moeilijk

Het probleem is dus misschien geen technisch probleem maar eerder administratief.

Tja. We zijn ook grote klant bij hen waar we datacenter ruimte afnemen. Mijn account manager daar even gebeld en die gaat het nu regelen.

Punt is vooral dat het bij die partijen nog steeds niet standaard is. Het moet gewoon geen vraag meer zijn.

[Snow_King]

Nee, Tele2/T-Mobile kan geen Ipv6 leveren bij deze verbinding. Dat is een 'special' die alleen bij hele grote verbindigen kan.

Het wordt nu dan maar een Ethernet VPN verbinding naar ons datacenter waar we dan met onze routers wel IPv6 gaan routeren voor die verbinding.

De accountmanager schaamde zich er ook een beetje voor, want ook hij vond dat anno 2022 dat gewoon moest kunnen.

[Roetzen]

Snow_King schreef op maandag 14 februari 2022 @ 13:12:
Nee, Tele2/T-Mobile kan geen Ipv6 leveren bij deze verbinding. Dat is een 'special' die alleen bij hele grote verbindigen kan.

Het wordt nu dan maar een Ethernet VPN verbinding naar ons datacenter waar we dan met onze routers wel IPv6 gaan routeren voor die verbinding.

De accountmanager schaamde zich er ook een beetje voor, want ook hij vond dat anno 2022 dat gewoon moest kunnen.

En jullie zitten echt vast aan Tele2/T-Mobile? Want anders zou ik naar de concurrent gaan. Geen IPv6, dat kan toch echt niet meer Anno 2022.

[Snow_King]

Roetzen schreef op maandag 14 februari 2022 @ 13:18:
[...]

En jullie zitten echt vast aan Tele2/T-Mobile? Want anders zou ik naar de concurrent gaan. Geen IPv6, dat kan toch echt niet meer Anno 2022.

In dit pand ligt Tele2/T-Mobile glasvezel of anders een schamele 70/20Mbit VDSL. Dat laatste is onwerkbaar voor een locatie met 25 man waar iedereen de hele dag in video vergaderingen hangt.

Ik wil dus 500~1000Mb aan bandbreedte. Dan maar een Ethernet link naar onze routers en zelf routeren. Ik had het ook graag anders gedaan, maar dit is de realiteit.

[Vorkie]

Bij VF/Ziggo zakelijk zijn ze ook wel redelijk terughoudend hierin. Je krijgt het in ieder geval niet standaard en staat zeker niet op de intake-excels

Ik heb voornamelijk het gevoel dat ze vinden dat het "lastig" is.

[Dreamvoid]

Als ik het begrijp is de global IPv6 routing table nog altijd kleiner dan de IPv4 routing table dus dat zou in theorie geen probleem moeten zijn, maar goed - als iemand bij een ISP ergens tien jaar terug heeft bedacht "ach, IPv6 is toch nog zo klein, laten we op deze router maar x geheugen reserveren, fixen we later wel", daar doe je weinig aan

[Snow_King]

Vorkie schreef op maandag 14 februari 2022 @ 13:29:
Bij VF/Ziggo zakelijk zijn ze ook wel redelijk terughoudend hierin. Je krijgt het in ieder geval niet standaard en staat zeker niet op de intake-excels

Ik heb voornamelijk het gevoel dat ze vinden dat het "lastig" is.

Maar waarom? Ik snap het echt niet. Hun core netwerken draaien al jaren gewoon IPv6. Ook mijn Ziggo Zakelij Pro heeft gewoon IPv6.

Ik snap dan niet waarom het bij overpriced Business Glasvezel ineens weer onmogelijk is.

[ericafterdark]

Snow_King schreef op maandag 14 februari 2022 @ 14:04:
[...]

Maar waarom? Ik snap het echt niet. Hun core netwerken draaien al jaren gewoon IPv6. Ook mijn Ziggo Zakelij Pro heeft gewoon IPv6.

Ik snap dan niet waarom het bij overpriced Business Glasvezel ineens weer onmogelijk is.

Lijkt me puur een propositie dingetje. Heel vreemd eigenlijk, ben ik het mee eens.

[CeesBak]

Tja, het is lastig. IPV6 draait op mijn Mikrotik router, Algemene vraag. Ik heb mijn Domoticz op een Raspberry met een IPV6 adres. Dat adres pik ik op van het Domoticz board. Dan zet ik het in de browser http://[adres] en tot mijn verbazing kom ik door default firewall heen. De inlogpagina verschijnt. Kan iemand hier iets over zeggen? Alvast bedankt!

[RobertMe]

CeesBak schreef op vrijdag 18 februari 2022 @ 10:46:
Tja, het is lastig. IPV6 draait op mijn Mikrotik router, Algemene vraag. Ik heb mijn Domoticz op een Raspberry met een IPV6 adres. Dat adres pik ik op van het Domoticz board. Dan zet ik het in de browser http://[adres] en tot mijn verbazing kom ik door default firewall heen. De inlogpagina verschijnt. Kan iemand hier iets over zeggen? Alvast bedankt!

Waar draait die browser? Als die in hetzelfde netwerk draait zal dat verkeer neem ik aan niet door de firewall van jouw Mikrotik router gaan, en als het verkeer al via de Mikrotik gerouteerd wordt zal waarschijnlijk de firewall alleen op "WAN in" verkeer worden toegepast waarbij verkeer vanaf het interne netwerk natuurlijk niet via WAN gaat.

[CeesBak]

Niet aan gedacht, ik zal eens verder testen, bedankt!

[Snow_King]

Via-via heb ik vernomen dat Ziggo heel dichtbij is om ook in fUPC gebied IPv6 in bridge modus te kunnen leveren net zoals in de andere gebieden. Ook om IPv6 daar uberhaupt te gaan leveren.

Tevens zijn ze er met mobiel ook netwerktechnisch helemaal klaar voor. Het vereist enkel nog aanpassingen in het provisioningsysteem, maar daar is nu geen 'push' voor omdat het daar nog geen meerwaarde levert voor hen.

Het zit er in ieder geval wel aan te komen, fUPC en Mobiel. Goed nieuws!

[elsinga]

Weet iemand of Online.nl op glasvezel van KPN ook IPv6 levert? En (hier wat off-topic) hoe "vast" hun IPv4 is? Ik heb binnenkort de kans om over te stappen, nu er eindelijk glas binnen ligt, maar heb liever een semi-vast IP adres bij Ziggo dan veel wisselingen van IP adres en symmetrische snelheid....

[nero355]

@elsinga
Waarom neem je dan niet gewoon gelijk KPN Glasvezel

Ben je gelijk van al het gezeik af...

[aawe mwan]

Ik heb een probleem met Raspberry Pi OS 64-bit (11/bullseye), FRITZ!Box 7590 en Ubuntu 21.10

Elke paar uur verandert Raspberry Pi OS zijn IPv6 adres,
in de webinterface van de FRITZ!Box zie ik steeds de actuele (correcte) IPv6 adressen staan,
maar Ubuntu 21.10 blijft hardnekkig een oud IPv6 adres voor de Raspberry Pi hanteren.
Dus bijvoorbeeld ssh -6 raspberrypi en ping -6 raspberrypi werken dan niet meer.

Op Ubuntu maak ik de DNS cache leeg met:

sudo systemd-resolve --flush-caches

Daarna kijk ik op Ubuntu wat de actuele IPv6 adressen zijn van de Raspberry Pi, met:

nslookup raspberrypi

En dan zie ik gek genoeg nog steeds de oude IPv6 adressen (die niet meer werken).
Zelfs als ik Ubuntu opnieuw opstart en dit daarna doe, dan is het weer zo.
Alleen als ik de Raspberry Pi opnieuw opstart, worden de IPv6 adressen in Ubuntu een keer goed overgenomen. (En dat werkt dan meteen: ik hoef op Ubuntu de dnscache niet handmatig te flushen.)

De Pi is aangesloten via een kabeltje, Ubuntu is aangesloten via WiFi.

Ik welk van de 3 apparaten zit dit probleem en hoe los ik het op?

[elsinga]

nero355 schreef op zaterdag 19 februari 2022 @ 00:34:
@elsinga
Waarom neem je dan niet gewoon gelijk KPN Glasvezel

Ben je gelijk van al het gezeik af...

Want ruim duurder?

[Timple]

nero355 schreef op vrijdag 11 februari 2022 @ 15:42:
[...]Server/Router/Switch/Accesspoint die als het goed is sowieso een Static IP hebben

Waarom eigenlijk?

[RobertMe]

Timple schreef op zaterdag 19 februari 2022 @ 09:37:
[...]

Waarom eigenlijk?

In mijn UniFi omgeving heb ik wel eens gehad dat hardware op offline werd gezet. Dan kun je dus ook geen IP adres meer zien. Doordat ik wel het IP adres wist (doordat ik deze dus statisch had ingesteld) kon ik er zo naar toe SSHen en ze weer met de UniFi Controller laten verbinden. Was het IP adres via DHCP toegekend had ik dus eerst het IP adres moeten zien te achterhalen.

Zelfde voor servers: wel zo handig als ze een vast IP adres hebben zodat je niet elke 24 uur of zo de DNS entries hoeft aan te passen.

[Hipska]

@aawe mwan handigste lijkt me om privacy extensions op de RPi uit te zetten, dan veranderd het adres niet telkens.

[Brahiewahiewa]

Hipska schreef op zaterdag 19 februari 2022 @ 13:53:
@aawe mwan handigste lijkt me om privacy extensions op de RPi uit te zetten, dan veranderd het adres niet telkens.

Hmmz, privacy extensions worden alleen maar gebruikt voor zelf-geïnitieerde uitgaande verbindingen. Voor een deamon (de ping responder, in dit geval) is het totaal niet zinnig om privacy extensions te gebruiken. Dan zit-ie te wachten op een inkomende verbinding, terwijl niemand weet op welk ip-adres hij luistert.
Als de rPi daadwerkelijk zo werkt, is het imho wel een erg krakkemikkige ipv6-implementatie. Maar het is ongetwijfeld een linux distro die er op draait, dus dat zou wel erg vreemd zijn.
Als ik @aawe mwan was, zou ik eerst eens uitzoeken waarom het ip-adres op de rPi wijzigt. Gaat er misschien iets mis met dhcpv6?

[nero355]

aawe mwan schreef op zaterdag 19 februari 2022 @ 08:00:
Ik heb een probleem met Raspberry Pi OS 64-bit (11/bullseye), FRITZ!Box 7590 en Ubuntu 21.10

Elke paar uur verandert Raspberry Pi OS zijn IPv6 adres,
in de webinterface van de FRITZ!Box zie ik steeds de actuele (correcte) IPv6 adressen staan,
maar Ubuntu 21.10 blijft hardnekkig een oud IPv6 adres voor de Raspberry Pi hanteren.
Dus bijvoorbeeld ssh -6 raspberrypi en ping -6 raspberrypi werken dan niet meer.

Op Ubuntu maak ik de DNS cache leeg met:

sudo systemd-resolve --flush-caches

Daarna kijk ik op Ubuntu wat de actuele IPv6 adressen zijn van de Raspberry Pi, met:

nslookup raspberrypi

En dan zie ik gek genoeg nog steeds de oude IPv6 adressen (die niet meer werken).
Zelfs als ik Ubuntu opnieuw opstart en dit daarna doe, dan is het weer zo.
Alleen als ik de Raspberry Pi opnieuw opstart, worden de IPv6 adressen in Ubuntu een keer goed overgenomen. (En dat werkt dan meteen: ik hoef op Ubuntu de dnscache niet handmatig te flushen.)

De Pi is aangesloten via een kabeltje, Ubuntu is aangesloten via WiFi.

Ik welk van de 3 apparaten zit dit probleem en hoe los ik het op?

Jij pingt op naam en dan zou ik denken dat er iets aan de AVAHI kant misgaat

Daarnaast zou ik niet graag daarvan afhankelijk willen zijn als het om DNS gaat dus overweeg eens Static IP's en een eigen lokaal DNS Servertje voor je netwerk

Wat me gelijk bij de andere vraag brengt :

Timple schreef op zaterdag 19 februari 2022 @ 09:37:
Waarom eigenlijk?

Omdat controlefreak!

Daarnaast heb ik een apart Management VLAN waarin al mijn Routers/Switches/Accesspoints bereikbaar zijn en zelfs een stukje segmentering van de apparaten binnen dat subnet :
- 192.168.1.1 t/m 192.168.1.9 = Routers
- 192.168.1.10 t/m 192.168.1.19 = "Core" Switches
- 192.168.1.20 t/m 192.168.1.29 = "Client/Edge" Switches
- 192.168.1.30 t/m 192.168.1.39 = Accesspoints in huis
- 192.168.1.40 t/m 192.168.1.49 = Voor eventuele Accesspoints die buiten staan, waarvan er nu maar één in gebruik is

Daarnaast is ook DHCP actief, maar die begint pas vanaf 192.168.1.100 en gaat tot en met 192.168.1.254

elsinga schreef op zaterdag 19 februari 2022 @ 08:55:
Want ruim duurder?

Tja, als je bepaalde wensen hebt en KPN daar aan kan voldoen dan is die meerprijs IMHO iets om over na te denken!

Daarnaast zag ik laatst ergens een of andere "prijsvergelijklijst" met een aantal ISP' die op glasvezel actief zijn en ontliep het elkaar eigenlijk niet heel veel...

[aawe mwan]

Hipska schreef op zaterdag 19 februari 2022 @ 13:53:
@aawe mwan handigste lijkt me om privacy extensions op de RPi uit te zetten, dan veranderd het adres niet telkens.

Ja dat heb ik nu maar gedaan. In het bestand /etc/dhcpcd.conf heb ik slaac private veranderd in slaac hwaddr en nu krijgt Debian 11 (Bullseye) een vast IPv6 adres op basis van zijn MAC adres en dat is ook het adres dat de FRITZ!Box koppelt aan de naam, dus dat zal wel blijven werken.

Maar wat ik nog niet begrijp is hoe nslookup een oud, vervallen IPv6 adres kan opleveren?

Heel wonderlijk trouwens dat deze fout nooit is opgevallen bij een test door de ontwikkelaars.

[Miki]

aawe mwan schreef op zondag 20 februari 2022 @ 10:07:
[...]


Ja dat heb ik nu maar gedaan. In het bestand /etc/dhcpcd.conf heb ik slaac private veranderd in slaac hwaddr en nu krijgt Debian 11 (Bullseye) een vast IPv6 adres op basis van zijn MAC adres en dat is ook het adres dat de FRITZ!Box koppelt aan de naam, dus dat zal wel blijven werken.

Maar wat ik nog niet begrijp is hoe nslookup een oud, vervallen IPv6 adres kan opleveren?

Heel wonderlijk trouwens dat deze fout nooit is opgevallen bij een test door de ontwikkelaars.

Je kunt je Pi toch ook een static IPv6 adres meegeven zolang het maar een ULA adres is, beginnende bij Fd of Fe.
Check ook deze uitleg bijvoorbeeld: https://danielrampelt.com...raspberry-pi-docker-ipv6/

[aawe mwan]

Miki schreef op zondag 20 februari 2022 @ 11:08:
[...]
Je kunt je Pi toch ook een static IPv6 adres meegeven zolang het maar een ULA adres is, beginnende bij Fd of Fe.

Ik kan je advies niet helemaal volgen. Een „ULA adres” is een lokaal adres, dat niet bereikbaar is per internet. Dat is toch niet om die reden een betere work-around dan wat ik al heb? Het slaac hwaddr adres is gebaseerd is op het MAC adres van de Ethernet interface dus het is vast, daarnaast is het ook nog gewoon benaderbaar via internet.

De werkelijke vraag is waarom nslookup op Ubuntu 21.10 oude, vervallen IPv6 adressen meldt in plaats van de actuele. Want de FRITZ!Box is prima op de hoogte: in de webinterface zie je de actuele IPv6 adressen (en alleen actuele adressen) van Debian 11/Bullseye en als je Debian herstart dan krijg je in Ubuntu meteen al geen adres meer bij de computernaam (je hoeft niet te wachten op een timeout).

[duvekot]

vraag:
in het kader van "spelen met IPv6" .. weet iemand of het volgende mogelijk is:

ik heb een Ziggo modem in bridge modus staan. Mijn bestaande router krijgt nu een IPv4 adres vanuit het Ziggo netwerk toegewezen via een DHCP verzoek, en mijn bestaande netwerk zit met NAT achter deze router op een private IPv4 range.

omdat IPv6 werkt met een PD verzoek .. zat ik te denken .. kan ik een tweede router gebruiken en daar alleen de IPv6 range op laten binnen komen? Dus dan moet ik op de uitgang van de modem een switch zetten zodat ik twee routers kan aansluiten. En de nieuwe router zo instellen dat die niets met IPv4 doet .. en dan mijn IPv6 netwerk achter mijn tweede router opbouwen.

Op die manier veranderd er niets aan het huidige netwerk, zijn daar iig geen verstoringen en problemen (hoge WAF factor) .. en kan ik zelf naar hartenlust experimenteren met een IPv6 only netwerk.

[nero355]

duvekot schreef op zondag 20 februari 2022 @ 16:45:
vraag:
in het kader van "spelen met IPv6" .. weet iemand of het volgende mogelijk is:

ik heb een Ziggo modem in bridge modus staan. Mijn bestaande router krijgt nu een IPv4 adres vanuit het Ziggo netwerk toegewezen via een DHCP verzoek, en mijn bestaande netwerk zit met NAT achter deze router op een private IPv4 range.

omdat IPv6 werkt met een PD verzoek .. zat ik te denken .. kan ik een tweede router gebruiken en daar alleen de IPv6 range op laten binnen komen? Dus dan moet ik op de uitgang van de modem een switch zetten zodat ik twee routers kan aansluiten. En de nieuwe router zo instellen dat die niets met IPv4 doet .. en dan mijn IPv6 netwerk achter mijn tweede router opbouwen.

Op die manier veranderd er niets aan het huidige netwerk, zijn daar iig geen verstoringen en problemen (hoge WAF factor) .. en kan ik zelf naar hartenlust experimenteren met een IPv6 only netwerk.

Dat moet IMHO gewoon werken!

Ik denk zelfs dat je straks meerdere IPv6 Routers kan neerzetten in sommige gevallen!

aawe mwan schreef op zondag 20 februari 2022 @ 11:38:
De werkelijke vraag is waarom nslookup op Ubuntu 21.10 oude, vervallen IPv6 adressen meldt in plaats van de actuele. Want de FRITZ!Box is prima op de hoogte: in de webinterface zie je de actuele IPv6 adressen (en alleen actuele adressen) van Debian 11/Bullseye en als je Debian herstart dan krijg je in Ubuntu meteen al geen adres meer bij de computernaam (je hoeft niet te wachten op een timeout).

Nogmaals :

Wie geeft je het antwoord op je DNS Request tijdens zo'n Ping : AVAHI of de FRITZ!Box of misschien een totaal ander apparaat

[aawe mwan]

nero355 schreef op zondag 20 februari 2022 @ 17:52:
Wie geeft je het antwoord op je DNS Request tijdens zo'n Ping : AVAHI of de FRITZ!Box of misschien een totaal ander apparaat

Bovenaan het antwoord van nslookup zie ik staan dat de info komt van 127.0.0.53 / 127.0.0.53#53.
Als ik kijk wat er lokaal luistert op poort 53, dan is dat een proces met de naam systemd-resolve.
In de log van systemd-resolve zie ik dat deze verbinding maakt met de FRITZ!Box voor zijn dns informatie.

Volgens mij betekent dit dat ik geen AVAHI / Zeroconf / Bonjour / Rendezvous heb.

De versie van systemd-resolve die Ubuntu 21.10 draait is: systemd 248 (248.3-1ubuntu8.2)

-update- Op bullseye draait wel de avahi-daemon. Zou die roet in het eten kunnen gooien?

[ Voor 6% gewijzigd door aawe mwan op 20-02-2022 20:41 ]

[Brahiewahiewa]

aawe mwan schreef op zondag 20 februari 2022 @ 18:32:
[...]


Bovenaan het antwoord van nslookup zie ik staan dat de info komt van 127.0.0.53 / 127.0.0.53#53.
Als ik kijk wat er lokaal luistert op poort 53, dan is dat een proces met de naam systemd-resolve.
In de log van systemd-resolve zie ik dat deze verbinding maakt met de FRITZ!Box voor zijn dns informatie...

Maar zie je ook daadwerkelijk op het moment dat je de rPi probeert te pingen, een DNS-request naar de fritz gaan? Of haalt systemd-resolve het bijbehorende ip-adres ijzerenheinig uit z'n cache?

[aawe mwan]

Brahiewahiewa schreef op zondag 20 februari 2022 @ 18:58:
Maar zie je ook daadwerkelijk op het moment dat je de rPi probeert te pingen, een DNS-request naar de fritz gaan? Of haalt systemd-resolve het bijbehorende ip-adres ijzerenheinig uit z'n cache?

Ik heb de cache leeggegooid, maar ook Ubuntu opnieuw opgestart en daarna gebeurde het nog steeds.
Dan kan het toch niet meer uit de cache komen?

Overigens is Raspberry Pi OS gewoon Debian 11 (bullseye).
Zie voor andere vragen die je misschien nog hebt ook vooral mijn originele bericht.

[nero355]

aawe mwan schreef op zondag 20 februari 2022 @ 18:32:
Bovenaan het antwoord van nslookup zie ik staan dat de info komt van 127.0.0.53 / 127.0.0.53#53.
Als ik kijk wat er lokaal luistert op poort 53, dan is dat een proces met de naam systemd-resolve.
In de log van systemd-resolve zie ik dat deze verbinding maakt met de FRITZ!Box voor zijn dns informatie.

Volgens mij betekent dit dat ik geen AVAHI / Zeroconf / Bonjour / Rendezvous heb.

De versie van systemd-resolve die Ubuntu 21.10 draait is: systemd 248 (248.3-1ubuntu8.2)

-update- Op bullseye draait wel de avahi-daemon. Zou die roet in het eten kunnen gooien?

Waarom ik over AVAHI begon is omdat je dit schreef :

aawe mwan schreef op zaterdag 19 februari 2022 @ 08:00:
Ik heb een probleem met Raspberry Pi OS 64-bit (11/bullseye), FRITZ!Box 7590 en Ubuntu 21.10

Elke paar uur verandert Raspberry Pi OS zijn IPv6 adres,
in de webinterface van de FRITZ!Box zie ik steeds de actuele (correcte) IPv6 adressen staan,
maar Ubuntu 21.10 blijft hardnekkig een oud IPv6 adres voor de Raspberry Pi hanteren.
Dus bijvoorbeeld ssh -6 raspberrypi en ping -6 raspberrypi werken dan niet meer.

Dat is IMHO pingen op de hostname van de Raspberry Pi zelf die ergens geregistreerd staat : In je DHCP Servers Cache of via AVAHI toestanden, hoewel deze vaak ook nog eens .local erachter willen zien/zetten in de meeste gevallen!

Maar nou ik nog eens alles lees en dit zie :

Op Ubuntu maak ik de DNS cache leeg met:

sudo systemd-resolve --flush-caches

Daarna kijk ik op Ubuntu wat de actuele IPv6 adressen zijn van de Raspberry Pi, met:

nslookup raspberrypi

En dan zie ik gek genoeg nog steeds de oude IPv6 adressen (die niet meer werken).
Zelfs als ik Ubuntu opnieuw opstart en dit daarna doe, dan is het weer zo.
Alleen als ik de Raspberry Pi opnieuw opstart, worden de IPv6 adressen in Ubuntu een keer goed overgenomen. (En dat werkt dan meteen: ik hoef op Ubuntu de dnscache niet handmatig te flushen.)

Ik welk van de 3 apparaten zit dit probleem en hoe los ik het op?

Dan zou ik denken dat misschien je FRITZ!Box zijn DNS niet goed update tussendoor

Wat gebeurt er als je die eens een schop geeft i.p.v. één van de andere twee ??

[GarBaGe]

Voor mij ook tijd om over te stappen op dual-stack met IPv6 ondersteuning.
Ik heb KPN met een Experiabox.
Hierachter staat een EdgeRouter om mijn thuis netwerk te managen.
De 1e stap is gelukt.
Door IPv6 aan te zetten op de EdgeRouter heb ik nu een IPv6 adres ontvangen WAN interface van mijn EdgeRouter.
Die is een /64 adres

De volgende stap is om het thuisnetwerk ook te voorzien van IPv6 adressen via de juiste configuratie van de EdgeRouter.

[RobertMe]

GarBaGe schreef op woensdag 23 februari 2022 @ 11:15:
Voor mij ook tijd om over te stappen op dual-stack met IPv6 ondersteuning.
Ik heb KPN met een Experiabox.
Hierachter staat een EdgeRouter om mijn thuis netwerk te managen.
De 1e stap is gelukt.
Door IPv6 aan te zetten op de EdgeRouter heb ik nu een IPv6 adres ontvangen WAN interface van mijn EdgeRouter.
Die is een /64 adres

De volgende stap is om het thuisnetwerk ook te voorzien van IPv6 adressen via de juiste configuratie van de EdgeRouter.

Dat IP adres dat de WAN poort krijgt is er waarschijnlijk een van een subnet dat KPN gebruikt voor "routers". Daarom dat het ook een /64 is en potentieel is dat zelfs een ULA adres. Zolang de router zelf maar met KPN kan babbelen maakt dat ook niet uit. Pas nadat je DHCP-PD gaat toepassen (neem aan dat ook KPN dat gebruikt) zul je een volledig subnet krijgen toegekend (/56 uit mijn hoofd), waarbij je via het prefix id dat je per VLAN instelt dus een /64 per VLAN hebben. En op de client apparaten (PC etc) zie je dan pas daadwerkelijk wat jouw subnet is, wat dus hoogstwaarschijnlijk afwijkt van het IP dat de EdgeRouter heeft aan de WAN kant.

Houdt er overigens ook rekening mee dat de ER IIRC by default firewall loos is. Dus er is ook geen WAN firewall voor IPv6 verkeer wat betekent dat je letterlijk alles naar buiten toe open zet. Daar waar consumenten routers juist alles dicht zetten en je i.p.v. een NAT port forward bij IPv4 bij IPv6 dan een regel aan maakt dat verkeer naar bv IP van een thuisserver op poort 443 is toegestaan.

[anboni]

GarBaGe schreef op woensdag 23 februari 2022 @ 11:15:
De volgende stap is om het thuisnetwerk ook te voorzien van IPv6 adressen via de juiste configuratie van de EdgeRouter.

Zoals @RobertMe al zegt, ER heef standaard geen firewall aan staan. Ik heb recent https://davidwesterfield....ewall-rules-edgerouter-4/ gebruikt als leidraad.

[aawe mwan]

nero355 schreef op zondag 20 februari 2022 @ 23:37:
[...]
Dan zou ik denken dat misschien je FRITZ!Box zijn DNS niet goed update tussendoor
Wat gebeurt er als je die eens een schop geeft i.p.v. één van de andere twee ??

Als ik de FRITZ!Box een schop geef dan verwacht ik dat alle verbindingen opnieuw opgezet moeten worden en dat alles weer zal werken?

Het Debian systeem heeft 5 dagen goed gedraaid, tot nu toe: ineens is hij niet meer bereikbaar onder zijn hostname. In de dmesg van Debian Bullseye zie ik deze regel staan:

[Feb24 10:42] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

En dat is vreemd, want ik had WiFi juist hard uitgeschakeld met rfkill en dat zag ik ook elke inlog terug op het inlogscherm. Nu zie ik met rfkill list dat WiFi niet meer geblockt is!

In de webinterface van de FRITZ!Box zie ik nu 1 IPv4 adres en 6 IPv6 adressen staan voor deze computer:
2001...8722
2001...aeb3
2001...aeb4 (dit adres is op het laatste cijfer na identiek aan het vorige)
fe80...8722
fe80...aeb3
fe80...ca3d

De hostname werkt nu helemaal niet meer op Ubuntu 21.10: voor IPv4 ziet hij het verkeerde IPv4 adres en voor IPv6 krijgt hij helemaal geen adres. nslookup toont geen IPv6 adres en 2 IPv4 adressen: het goede en het verkeerde en Ubuntu 21.10 kiest blijkbaar het verkeerde.

Hierna heb een machine met Ubuntu 20.04 aangezet. Deze machine was de hele dag uitgeschakeld. Als ik op die machine nu nslookup draai, zie ik precies hetzelfde. Dat zie ik ook als ik kijk met dig .

Wat zegt Debian Bullseye er zelf van (ip a):
op de eth0 interface heeft hij 1 IPv4 adres en 2 IPv6 adressen die eindigen op aeb3, wat de twee laatste bytes van het MAC adres van de vaste aansluiting zijn.
op de wlan0 interface heeft hij geen adressen (deze link is DOWN), maar het MAC adres van deze interface eindigt op aeb4 (de twee MAC adressen zijn dus opvolgend).

Het lijkt er voor mij dus op dat spontaan de WiFi interface unblocked raakt (fout 1) en dan daardoor de dns op de FRITZ!Box in de war raakt (fout 2), waarbij die fout zich vooral openbaart bij IPv6.

Welke informatie zou je nu nog willen zien?

[nero355]

aawe mwan schreef op donderdag 24 februari 2022 @ 16:37:
Als ik de FRITZ!Box een schop geef dan verwacht ik dat alle verbindingen opnieuw opgezet moeten worden en dat alles weer zal werken?

Ligt er een beetje aan hoe de boel is geconfigureerd :
- Soms blijven alle leases gewoon staan en merk je pas een verandering bij de volgende DHCP Request.
- Soms raken al je Clients meteen hun IP adres kwijt en zal de boel opnieuw worden geregeld zodra je Router weer is opgestart!

Het Debian systeem heeft 5 dagen goed gedraaid, tot nu toe: ineens is hij niet meer bereikbaar onder zijn hostname. In de dmesg van Debian Bullseye zie ik deze regel staan:

[Feb24 10:42] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

En dat is vreemd, want ik had WiFi juist hard uitgeschakeld met rfkill en dat zag ik ook elke inlog terug op het inlogscherm. Nu zie ik met rfkill list dat WiFi niet meer geblockt is!

We hebben het over een Raspberry Pi toch

Dan kan je beter dit doen : https://raspberrypi.stack...-wifi-wlan0-on-pi-3#62522

In de webinterface van de FRITZ!Box zie ik nu 1 IPv4 adres en 6 IPv6 adressen staan voor deze computer:
2001...8722
2001...aeb3
2001...aeb4 (dit adres is op het laatste cijfer na identiek aan het vorige)
fe80...8722
fe80...aeb3
fe80...ca3d

Computer = De Raspberry Pi neem ik aan

De hostname werkt nu helemaal niet meer op Ubuntu 21.10: voor IPv4 ziet hij het verkeerde IPv4 adres en voor IPv6 krijgt hij helemaal geen adres. nslookup toont geen IPv6 adres en 2 IPv4 adressen: het goede en het verkeerde en Ubuntu 21.10 kiest blijkbaar het verkeerde.

Hierna heb een machine met Ubuntu 20.04 aangezet. Deze machine was de hele dag uitgeschakeld. Als ik op die machine nu nslookup draai, zie ik precies hetzelfde. Dat zie ik ook als ik kijk met dig .

Zet effe de daadwerkelijke output erbij

Wat zegt Debian Bullseye er zelf van (ip a):
op de eth0 interface heeft hij 1 IPv4 adres en 2 IPv6 adressen die eindigen op aeb3, wat de twee laatste bytes van het MAC adres van de vaste aansluiting zijn.

Volgens mij klopt daar ook iets niet helemaal... not sure...

op de wlan0 interface heeft hij geen adressen (deze link is DOWN), maar het MAC adres van deze interface eindigt op aeb4 (de twee MAC adressen zijn dus opvolgend).

Dan weten we in ieder geval waar die aeb4 vandaan komt!

Het lijkt er voor mij dus op dat spontaan de WiFi interface unblocked raakt (fout 1) en dan daardoor de dns op de FRITZ!Box in de war raakt (fout 2), waarbij die fout zich vooral openbaart bij IPv6.

Disable de WiFi effe op de eerder genoemde manier en laat ons weten hoe dat uitpakt

Welke informatie zou je nu nog willen zien?

Zie bovenstaande vragen, maar misschien overbodig vanaf het moment dat je de WiFi op de juiste manier disabled...

[aawe mwan]

nero355 schreef op donderdag 24 februari 2022 @ 17:23:
Zet effe de daadwerkelijke output erbij

Dit is wat er nu staat: (S T U V W is voor de privacy uiteraard)

nslookup

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	raspberrypi.fritz.box
Address: 192.168.178.40
Name:	raspberrypi.fritz.box
Address: 192.168.178.42

dig

; <<>> DiG 9.16.22-Debian <<>> raspberrypi @fritz.box
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55053
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;raspberrypi.			IN	A

;; ANSWER SECTION:
raspberrypi.		9	IN	A	192.168.178.40
raspberrypi.		9	IN	A	192.168.178.42

;; AUTHORITY SECTION:
raspberrypi.		9	IN	NS	fritz.box.

;; ADDITIONAL SECTION:
fritz.box.		9	IN	A	192.168.178.1
fritz.box.		9	IN	AAAA	fd00::UUUU:VVVV:WWWW:6ce6
fritz.box.		9	IN	AAAA	2001:SSSS:TTTT:1:UUUU:VVVV:WWWW:6ce6

;; Query time: 7 msec
;; SERVER: 2001:SSSS:TTTT:1:UUUU:VVVV:WWWW:6ce6#53(2001:SSSS:TTTT:1:UUUU:VVVV:WWWW:6ce6)
;; WHEN: Thu Feb 24 17:35:48 CET 2022
;; MSG SIZE  rcvd: 156

[ Voor 9% gewijzigd door aawe mwan op 24-02-2022 17:50 ]

[GarBaGe]

anboni schreef op woensdag 23 februari 2022 @ 12:29:
[...]


Zoals @RobertMe al zegt, ER heef standaard geen firewall aan staan. Ik heb recent https://davidwesterfield....ewall-rules-edgerouter-4/ gebruikt als leidraad.

Ik wist dat de ER standaard geen firewall doet.
Ik had al een WAN6 firewall aangemaakt.
Wat ik echter niet wist, wat dat een IPv6 firewall alleen via de config tree of CLI kan worden gemaakt en onderhouden en daarmee compleet onzichtbaar blijft in de GUI.
Bizar...

[aawe mwan]

Ik heb WiFi gedisabled met de bootoptie en daarna Bullseye opnieuw opgestart. WiFi is nu inderdaad uitgeschakeld en je kunt het niet meer inschakelen met rfkill.

In de webinterface van de FRITZ!Box zag ik daarna nog alle IP-adressen van hiervoor staan, inclusief de foute IPv6 adressen die niet werken. Om die weg te krijgen, heb ik de Raspberry Pi hernoemd naar een unieke naam en daarna de FRITZ!Box opnieuw opgestart.

Direct daarna werkte het (ssh of ping IPv6 met een hostname), maar na een paar minuten was er ineens weer geen IPv6 adres meer voor de nieuwe hostname. Maar als je het adres weet, dan werkt IPv6 wel. Ik heb de Raspberry Pi opnieuw opgestart en daarna was zijn IPv6 adres weer wel gekoppeld aan de hostname.

Het beeld in de webinterface van de FRITZ!Box is gelukkig veranderd, ik zie daar nu drie IPv6 adressen staan:
2001:SSSS:TTTT:1:UUUU:VVVV:WWWW:aeb3
fe80::UUUU:VVVV:WWWW:aeb3
fd00::UUUU:VVVV:WWWW:aeb3
en in de userinterface vakjes voor het "IPv6-interface-ID" zie ik nu UUUU VVVV WWWW aeb3 staan.

Dan ga ik het maar eens met deze instellingen proberen of IPv6 wil blijven werken.

[Miki]

GarBaGe schreef op donderdag 24 februari 2022 @ 19:23:
[...]

Ik wist dat de ER standaard geen firewall doet.
Ik had al een WAN6 firewall aangemaakt.
Wat ik echter niet wist, wat dat een IPv6 firewall alleen via de config tree of CLI kan worden gemaakt en onderhouden en daarmee compleet onzichtbaar blijft in de GUI.
Bizar...

Er zijn op het KPN forum standaard configuratie scripts die je helpen om in één keer goed in te stellen, wellicht helpt dit je: https://forum.kpn.com/thu...p-v-de-experia-box-458609

Ubiquiti heeft helaas weinig aandacht gehad voor de Edgerouters. IPv6 ondersteuning is ondermaats als ook het verder onderhouden van EdgeOS. Zeer waarschijnlijk omdat ze op de achtergrond al bezig zijn om over te stappen op een nieuw OS.
Zelf ga ik ga op korte termijn mijn Edgerouter X flashen met Openwrt. Daar is de ondersteuning voor IPv6 veel nadrukkelijker in het OS meegenomen en dus makkelijker te onderhouden.

[valkenier]

duvekot schreef op zondag 20 februari 2022 @ 16:45:
vraag:
in het kader van "spelen met IPv6" .. weet iemand of het volgende mogelijk is:

ik heb een Ziggo modem in bridge modus staan. Mijn bestaande router krijgt nu een IPv4 adres vanuit het Ziggo netwerk toegewezen via een DHCP verzoek, en mijn bestaande netwerk zit met NAT achter deze router op een private IPv4 range.

omdat IPv6 werkt met een PD verzoek .. zat ik te denken .. kan ik een tweede router gebruiken en daar alleen de IPv6 range op laten binnen komen? Dus dan moet ik op de uitgang van de modem een switch zetten zodat ik twee routers kan aansluiten. En de nieuwe router zo instellen dat die niets met IPv4 doet .. en dan mijn IPv6 netwerk achter mijn tweede router opbouwen.

Op die manier veranderd er niets aan het huidige netwerk, zijn daar iig geen verstoringen en problemen (hoge WAF factor) .. en kan ik zelf naar hartenlust experimenteren met een IPv6 only netwerk.

Je hebt het niet van mij, maar je kan in veel gevallen een 2 netwerkpoortje op een gebridged modem gebruiken….. en daar gewoon een extra ipv4 en ipv6 prefix halen. Misschien werkt het niet in elke regio, maar ik zou het gewoon proberen

[nero355]

valkenier schreef op vrijdag 25 februari 2022 @ 20:50:
Je hebt het niet van mij, maar je kan in veel gevallen een 2 netwerkpoortje op een gebridged modem gebruiken…

Noem dan effe enkele voorbeelden waarvan jij zeker weet dat ze goed werken, want in de meeste gevallen zullen WAN + LAN 1 met elkaar gebridged zijn en zijn alle andere poorten nutteloos...

[duvekot]

valkenier schreef op vrijdag 25 februari 2022 @ 20:50:
[...]


Je hebt het niet van mij, maar je kan in veel gevallen een 2 netwerkpoortje op een gebridged modem gebruiken….. en daar gewoon een extra ipv4 en ipv6 prefix halen. Misschien werkt het niet in elke regio, maar ik zou het gewoon proberen

Geprobeerd .. op mijn nieuwe Ubee 1318ZG.
Mijn eigen router zit op Lan1 aangesloten .. met dus een eigen en werkend IPv4 adres en werkende verbinding.

Een oud Chromebook gepakt met een USB ethernet adapter .. ingelogd als Guest .. en de ethernet kabel aangesloten op Lan2: 82.75.152.xxx/255.255.254.0 subnet

Dus idd .. tegen alle verwachtingen in .. krijg ik dus een tweede IPv4. Op beide verbindingen kan ik gewoon internet op en sites bezoeken etc.
Ik heb een speedtest uitgevoerd op beide verbindingen .. en de snelheid wordt zo te merken "netjes" over beide verbindingen verdeeld.

Nog niet nagekeken hoe IPv6 hier op reageert .. maar dat komt later nog wel .. daar moet ik nog eea voor aanpassen in mijn eigen netwerk.

Heel bijzonder om dit te merken .. ik ben benieuwd hoelang dit blijft werken, maar ik kan het wel handig gebruiken door nu mijn "thuiswerk netwerk" te splitsen van mijn eigen normale netwerk zodat ik in mijn thuiswerk netwerk wat VPN verbindingen op de "thuiswerk router" te gaan opzetten .. dan wordt de werkplek weer een beetje gelijk aan kantoor. Gewoon laptop inprikken en kunnen werken.

[RobertMe]

duvekot schreef op zaterdag 26 februari 2022 @ 12:04:
[...]


Geprobeerd .. op mijn nieuwe Ubee 1318ZG.
Mijn eigen router zit op Lan1 aangesloten .. met dus een eigen en werkend IPv4 adres en werkende verbinding.

Een oud Chromebook gepakt met een USB ethernet adapter .. ingelogd als Guest .. en de ethernet kabel aangesloten op Lan2: 82.75.152.xxx/255.255.254.0 subnet

Dus idd .. tegen alle verwachtingen in .. krijg ik dus een tweede IPv4. Op beide verbindingen kan ik gewoon internet op en sites bezoeken etc.
Ik heb een speedtest uitgevoerd op beide verbindingen .. en de snelheid wordt zo te merken "netjes" over beide verbindingen verdeeld.

Nog niet nagekeken hoe IPv6 hier op reageert .. maar dat komt later nog wel .. daar moet ik nog eea voor aanpassen in mijn eigen netwerk.

Heel bijzonder om dit te merken .. ik ben benieuwd hoelang dit blijft werken, maar ik kan het wel handig gebruiken door nu mijn "thuiswerk netwerk" te splitsen van mijn eigen normale netwerk zodat ik in mijn thuiswerk netwerk wat VPN verbindingen op de "thuiswerk router" te gaan opzetten .. dan wordt de werkplek weer een beetje gelijk aan kantoor. Gewoon laptop inprikken en kunnen werken.

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.

[ANdrode]

duvekot schreef op zaterdag 26 februari 2022 @ 12:04:
[...]


Geprobeerd .. op mijn nieuwe Ubee 1318ZG.
Mijn eigen router zit op Lan1 aangesloten .. met dus een eigen en werkend IPv4 adres en werkende verbinding.

Een oud Chromebook gepakt met een USB ethernet adapter .. ingelogd als Guest .. en de ethernet kabel aangesloten op Lan2: 82.75.152.xxx/255.255.254.0 subnet

Veel ziggo modems hadden jaren geleden al een configuratieprofiel waarop twee IPs/DHCP leases actief konden zijn.

Dit voorkomt veel problemen en support calls met eigen routers

[nero355]

Zo raken de IPv4 adressen wel een keer op dankzij Ziggo

[Roetzen]

ANdrode schreef op zaterdag 26 februari 2022 @ 14:52:
[...]

Veel ziggo modems hadden jaren geleden al een configuratieprofiel waarop twee IPs/DHCP leases actief konden zijn.

Met mijn Motorola Surfboard modem uit de Casema tijd kon dat in aanvang ook. Toe het Zigggo werd hield dat op. En ze veranderden ook het wachtwoord voor de toegang zodat ik de signaalwaardes niet meer kon zien.

[Roetzen]

nero355 schreef op zaterdag 26 februari 2022 @ 15:00:
Zo raken de IPv4 adressen wel een keer op dankzij Ziggo

Die waren tien jaar geleden al "op".

[mrdemc]

nero355 schreef op zaterdag 26 februari 2022 @ 15:00:
Zo raken de IPv4 adressen wel een keer op dankzij Ziggo

Met de 35.000 klanten die bij Ziggo zijn vertrokken het afgelopen jaar hebben ze ook weer net zoveel IP-adressen vrij om te verdelen

[Roetzen]

mrdemc schreef op zaterdag 26 februari 2022 @ 15:24:
[...]

Met de 35.000 klanten die bij Ziggo zijn vertrokken het afgelopen jaar hebben ze ook weer net zoveel IP-adressen vrij om te verdelen

Alleen als al die klanten uit fZiggo gebied vertrokken. In fUPC delen ze nog DS-Lite uit en dan delen meerdere klanten een IPv4 adres.

[mrdemc]

Roetzen schreef op zaterdag 26 februari 2022 @ 15:28:
[...]

Alleen als al die klanten uit fZiggo gebied vertrokken. In fUPC delen ze nog DS-Lite uit en dan delen meerdere klanten een IPv4 adres.

Tenzij ze bridge modus gebruiken. Dan krijg je een eigen IPv4 en geen IPv6.

quote: https://tweakers.net/nieu...odems-in-bridgemodus.html

Update, woensdag 17 november: VodafoneZiggo zegt tegen Tweakers dat de beschikbaarheid van IPv6 bij modems in bridgemodus vooralsnog alleen voor het voormalige Ziggo-gebied geldt, wegens 'technische aanpassingen'. De provider zegt ernaar te streven dat klanten in oud-UPC-gebied in de loop van 2022 IPv6 kunnen gebruiken bij modems in bridgemodus.

[Roetzen]

mrdemc schreef op zaterdag 26 februari 2022 @ 15:33:
[...]

Tenzij ze bridge modus gebruiken. Dan krijg je een eigen IPv4 en geen IPv6.
[...]

Dat wel ja...

Maar ik vind de smiley niet op zijn plaats. Ze hadden dat al lang voor elkaar moeten hebben. Net als de vrije modemkeuze.

[mrdemc]

Roetzen schreef op zaterdag 26 februari 2022 @ 15:51:
[...]

Dat wel ja...

Maar ik vind de smiley niet op zijn plaats. Ze hadden dat al lang voor elkaar moeten hebben. Net als de vrije modemkeuze.

Beter zo?
Gelijk heb je, ik ben ook niet voor niets overgestapt naar KPN Glas waarbij ik dankbaar gebruik van van m’n IPv6 reeks, want zit zelf ook in fUPC gebied.

[ Voor 4% gewijzigd door mrdemc op 26-02-2022 16:22 ]

[duvekot]

Elke keer als ik fUPC zie lees ik in mijn gedachten: f*cked UP Cable

[nero355]

Roetzen schreef op zaterdag 26 februari 2022 @ 15:15:
Die waren tien jaar geleden al "op".

Ik probeerde grappig te zijn en zo...

Dat de IPv4 adressen al lang op zijn en er een grote handel in is ontstaan weet ik ook wel...

mrdemc schreef op zaterdag 26 februari 2022 @ 16:22:
Gelijk heb je, ik ben ook niet voor niets overgestapt naar KPN Glas waarbij ik dankbaar gebruik van van m’n IPv6 reeks, want zit zelf ook in fUPC gebied.

Iets van 20 jaar in fUPC gebied gewoond en altijd KPN xDSL gehad!

Was best grappig :
- Zit je op TeamSpeak met een vriend die één wijk verder woont.
- 00:00 uur = Onderhoud bij Ziggo = Lijn plat = Vriend offline...
- Mijn KPN lijntje plutterde ondertussen zonder onderbrekingen door al die jaren!

[RobertMe]

nero355 schreef op zaterdag 26 februari 2022 @ 18:34:
Was best grappig :
- Zit je op TeamSpeak met een vriend die één wijk verder woont.
- 00:00 uur = Onderhoud bij Ziggo = Lijn plat = Vriend offline...
- Mijn KPN lijntje plutterde ondertussen zonder onderbrekingen door al die jaren!

En KPN had nooit onderhoud? Man man man... kansloze reactie weer waarbij "iets anders dan wat jij doet / hebt" meteen weer rommel is. En alsof alleen Ziggo onderhoud aan het netwerk doet. En liever dat ze 's nachts onderhoud doen, en ik lekker op één oor lig, dan midden overdag. Daarnaast kondigen ze het ook altijd aan. En in de 20 jaar dat ik nu Ziggo heb je komt het misschien gemiddeld één of twee keer per jaar voor dat ze eruit liggen door aangekondigd onderhoud, waarvan 9/10 keer dan 's nachts.
Enige keer dat ik mij onderhoud (met onderbreking) overdag kan herinneren is toen ze een jaar of twee terug de straatkasten aan het vervangen / upgraden waren. En ook dat onderhoud was uiteraard netjes aangekondigd.

[ed1703]

RobertMe schreef op zaterdag 26 februari 2022 @ 20:29:
[...]

En KPN had nooit onderhoud? Man man man... kansloze reactie weer waarbij "iets anders dan wat jij doet / hebt" meteen weer rommel is. En alsof alleen Ziggo onderhoud aan het netwerk doet. En liever dat ze 's nachts onderhoud doen, en ik lekker op één oor lig, dan midden overdag. Daarnaast kondigen ze het ook altijd aan. En in de 20 jaar dat ik nu Ziggo heb je komt het misschien gemiddeld één of twee keer per jaar voor dat ze eruit liggen door aangekondigd onderhoud, waarvan 9/10 keer dan 's nachts.
Enige keer dat ik mij onderhoud (met onderbreking) overdag kan herinneren is toen ze een jaar of twee terug de straatkasten aan het vervangen / upgraden waren. En ook dat onderhoud was uiteraard netjes aangekondigd.

Moet toch wel zeggen dat ze het tegenwoordig vaker doen. Zie het eigenlijk gelijk omdat m’n OpenVPN een onderbreking heeft gehad.
Gaat ook echt niet om meerdere minuten, maar enkele seconden tot net geen minuut.
Firmwareupgrades of ander groot onderhoud worden inderdaad keurig gecommuniceerd.

[nero355]

RobertMe schreef op zaterdag 26 februari 2022 @ 20:29:
En KPN had nooit onderhoud?

Vast wel, echter had ik er als klant nooit last van!

Man man man... kansloze reactie weer waarbij "iets anders dan wat jij doet / hebt" meteen weer rommel is.

Niet zo boos doen alleen maar omdat je zelf Ziggo hebt...

En alsof alleen Ziggo onderhoud aan het netwerk doet.

Die van Caiway is net zo irritant : Klopt!

En nu heb ik er ook nog eens last WEL last van...

En liever dat ze 's nachts onderhoud doen, en ik lekker op één oor lig, dan midden overdag.

In het weekend in de nacht als je nog effe zit te gamen is niet echt handig eerlijk gezegd!

Daarnaast kondigen ze het ook altijd aan.

Meestal wel, maar niet altijd helaas...

En in de 20 jaar dat ik nu Ziggo heb je komt het misschien gemiddeld één of twee keer per jaar voor dat ze eruit liggen door aangekondigd onderhoud, waarvan 9/10 keer dan 's nachts.

Op een gegeven moment werd het echt vaak gedaan en dan is het echt niet leuk meer!

Enige keer dat ik mij onderhoud (met onderbreking) overdag kan herinneren is toen ze een jaar of twee terug de straatkasten aan het vervangen / upgraden waren. En ook dat onderhoud was uiteraard netjes aangekondigd.

Dat je dan effe plat ligt is uiteraard logisch

[GarBaGe]

Wie o wie heeft er een hint waarom mijn IPv6 config niet werkt?

Ik heb KPN ADSL, gebruik de Experiabox met daar achter een EdgeRouter X.
De eth0 is de WAN poort van de ERX, en deze krijgt een IPv6 adres van de Experiabox.
Dit adres is A:B:C:0001:E:F:G:H/64
De "0001" is (denk ik) het subnet wat de Experiabox uitdeelt.
Ik heb begrepen dat mijn eigen subnets (en VLANs) een eigen subnet kunnen gebruiken, omdat KPN mij een /48 prefix-length geeft.

Op mijn poorten eth1, eth2 en eth3 heb ik de trunk van mijn netwerk en een aantal VLANs,
In ERX termen, heet dat ding dan een switch.
De trunk is dan "switch0" en mijn VLANs zijn dan "switch0.13 en switch0.26"
Nu wil ik (voorlopig) alleen op de trunk een dual-stack met IPv4 en IPv6 verkeer
Gezien mijn Experiabox reeds subnet 1 gebruikt, wil ik graag subnet "3" op mijn trunk.
Ik heb dus gezegd in de config:

code:

interfaces {
    ethernet eth0 {
        dhcpv6-pd {
            pd 0 {
                interface switch0 {
                    host-address ::1
                    prefix-id :3
                    service slaac

en verderop heb ik:

code:

interfaces {
    switch switch0 {
        address ...niet zo relevant
        description Local
        ipv6 {
            dup-addr-detect-transmits 1
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag false
                max-interval 600
                other-config-flag false
                prefix ::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                reachable-time 0
                retrans-timer 0
                send-advert true

wat mis ik nu nog?
Of wat kan ik doen om deze config verder te debuggen?

Onderstaan is mijn config...

code:

firewall {
    all-ping enable
    broadcast-ping disable
    group {
        .... een aantal IPv4 groep definities...
    }
    ipv6-name WAN6_IN {
        default-action drop
        rule 10 {
            action accept
            description "Allow established and related packets"
            log disable
            protocol all
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log enable
            protocol all
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow IPv6 icmp"
            icmpv6 {
                type echo-request
            }
            protocol ipv6-icmp
        }
    }
    ipv6-name WAN6_LOCAL {
        default-action drop
        rule 10 {
            action accept
            description "Allow established and related packets"
            log disable
            protocol all
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log enable
            protocol all
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow ICMPv6"
            protocol ipv6-icmp
        }
        rule 40 {
            action accept
            description "Allow DHCPv6 client/server"
            destination {
                port 546
            }
            protocol udp
            source {
                port 547
            }
        }
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name .... {
        .... een aantal IPv4 firewall definities...
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        address dhcp
        description Internet
        dhcpv6-pd {
            pd 0 {
                interface switch0 {
                    host-address ::1
                    prefix-id :3
                    service slaac
                }
                prefix-length /48
            }
            rapid-commit enable
        }
        duplex auto
        firewall {
            in {
                ipv6-name WAN6_IN
                name WAN_IN
            }
            local {
                ipv6-name WAN6_LOCAL
                name WAN_LOCAL
            }
        }
        ipv6 {
            address {
                autoconf
            }
            dup-addr-detect-transmits 1
        }
        speed auto
    }
    ethernet eth1 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth2 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth3 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth4 {
        ... wat ipV4 netwerk definities en firewall referenties
    }
    loopback lo {
    }
    switch switch0 {
        address ... niet zo relevant
        description Local
        ipv6 {
            dup-addr-detect-transmits 1
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag false
                max-interval 600
                other-config-flag false
                prefix ::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        mtu 1500
        switch-port {
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth3 {
            }
            vlan-aware disable
        }
        vif ... {
           ... wat VLAN definities
        }
    }
}
service {
    dhcp-server {
        .... IPv4 DHCP definities
    }
    dns {
        .... IPv4 DNS definities
    }
    gui {
        .... GUI config
    }
    nat {
        .... IPv4 NAT config
    }
}
system {
    .... system config, waar geen IPv6 spul in zit...
}