Het grote IPv6 topic

[hkoster1]

Roetzen schreef op dinsdag 24 oktober 2017 @ 22:18:
[...]

Ik bedoelde lokaal. Vanaf een apparaat op het LAN. Dus 192.168.178.1 of zo iets.

Ja, uiteraard een volledig IPv4 192.168.178.0/24 (W)LAN, met de ConnectBox als 192.168.178.1.
De meeste van mijn aangesloten apparaten hebben ook een IPv6-adres, alleen een paar rookmelders niet.

[St00mwals]

hkoster1 schreef op dinsdag 24 oktober 2017 @ 22:29:
[...]

Ja, uiteraard een volledig IPv4 192.168.178.0/24 (W)LAN, met de ConnectBox als 192.168.178.1.
De meeste van mijn aangesloten apparaten hebben ook een IPv6-adres, alleen een paar rookmelders niet.

Dat is toch belachelijk!!!
Die rookmelders zijn hooguit een jaar of 2-3 oud (als je er vroeg bij was, gok ik zo) en toch geen IPv6 ondersteuning
Zo zie je maar weer dat op het gebied van IOT fabrikanten echt niet verder kijken dan connectiviteit.

[Maurits van Baerle]

Ziggo start vanaf volgende week levering Connect Box van Arris

Het verschil met de Compal-variant is dat de Arris direct WifiSpots ondersteunt en voor klanten in de voormalige Ziggo-regio van voor april 2017 ipv6 full dual stack biedt. De Compal Connect Box krijgt deze functionaliteit later dit jaar. Ziggo meldt nog dat het netwerk in voormalig UPC-gebied niet geschikt is voor full dual stack. Gebruikers die na april 2017 Ziggo-klant werden, krijgen standaard ipv6 DS Lite.

Vooruitgang.

[agresionpower]

Maurits van Baerle schreef op vrijdag 27 oktober 2017 @ 16:11:
Ziggo start vanaf volgende week levering Connect Box van Arris


[...]


Vooruitgang.

ben benieuwd of we daarna iets in de cijfers gaan terugzien.

[Morax]

Maurits van Baerle schreef op vrijdag 27 oktober 2017 @ 16:11:
Ziggo start vanaf volgende week levering Connect Box van Arris


[...]


Vooruitgang.

Ik maak me als fUPC gebruiker een beetje zorgen dat Ziggo gewoon zegt dat het fUPC netwerk niet geschikt is voor dual stack, dus daar krijgt iedereen DS Lite. Einde verhaal.

MAAK het dan geschikt!

[stormfly]

Morax schreef op vrijdag 27 oktober 2017 @ 21:55:
MAAK het dan geschikt!

Nee dat lukt niet, want daar zijn waarschijnlijk niet genoeg IPv4 adressen meer voor. You know IPV6 is ontstaan vanwege het dreigende tekort aan IPv4 adressen.

[Roetzen]

fUPC geschikt maken voor Dual Stack? Dat gaan ze niet doen natuurlijk. Een DS-Lite netwerk is technisch veel eenvoudiger en overzichtelijker dan een Dual Stack netwerk. Dual Stack is sowieso geen eindoplossing omdat er niet genoeg IPv4 adressen zijn om in de toekomst iedereen een eigen IPv4 adres te geven. Dat is nu juist de belangrijkste reden waarom we naar IPv6 moeten. Dus wie een goedlopend netwerk heeft met DS-Lite gaat niet investeren om het geschikt te maken voor Dual Stack. Uiteindelijk moeten we allemaal aan de DS-Lite. Wen er maar aan.

[ Voor 3% gewijzigd door Roetzen op 27-10-2017 22:23 ]

[Verwijderd]

https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Tegen mijn verwachting in toch wel een redelijk stijging recent in het ipv6 volume.

Ik ben even weg geweest (druk druk) en heb ook weer nieuwe situaties gezien waarbij men -netwerk beheerders- gek werden van dubbel nat ivbm overlappende private ip ranges. Maar als je dan aangeeft dat er een oplossing is......... Tsja, dan is het toch allemaal weer eng en vreemd.

[agresionpower]

Verwijderd schreef op zaterdag 4 november 2017 @ 16:23:
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Tegen mijn verwachting in toch wel een redelijk stijging recent in het ipv6 volume.

Ik ben even weg geweest (druk druk) en heb ook weer nieuwe situaties gezien waarbij men -netwerk beheerders- gek werden van dubbel nat ivbm overlappende private ip ranges. Maar als je dan aangeeft dat er een oplossing is......... Tsja, dan is het toch allemaal weer eng en vreemd.

Eigenlijk vind ik deze grafiek dan belangrijker
https://ams-ix.net/techni...cs/sflow-stats/ether-type

Maar ook daar zit gelukkig groei in.

[Paul]

Roetzen schreef op vrijdag 27 oktober 2017 @ 22:21:
Uiteindelijk moeten we allemaal aan de DS-Lite. Wen er maar aan.

Iemand die het nog niet heeft een IPv4-adres geven wordt lastig, ben ik met je eens. Ik heb wel het idee dat de keuze DS-Lite of geen IPv6 er voor zorgt dat de adoptie onder technici er onder leidt, wat er weer voor zorgt dat ze er minder van af weten, wat er weer voor zorgt dat ze het minder makkelijk zakelijk inzetten, wat er weer voor zorgt dat we nog steeds op heel veel plekken geen IPv6 hebben,wat er weer voor zorgt dat die techneuten hun IPv4-adres niet kwijt willen...

Bij mij op het werk (een ziekenhuis) wil men intern geen IPv6 want nieuw en eng en niet nodig. Als we het al gaan doen dan is het op de internetlijn naar de websites en andere diensten die we intern hosten, via een load balancer (die dus het IPv6-adres krijgt en intern IPv4 blijft praten). Dan zijn we dus wel bereikbaar over IPv6 maar kunnen we zelf nog steeds niet naar IPv6-only diensten

[stormfly]

Paul schreef op zondag 5 november 2017 @ 23:11:
[...]
Bij mij op het werk (een ziekenhuis) wil men intern geen IPv6 want nieuw en eng en niet nodig. Als we het al gaan doen dan is het op de internetlijn naar de websites en andere diensten die we intern hosten, via een load balancer (die dus het IPv6-adres krijgt en intern IPv4 blijft praten). Dan zijn we dus wel bereikbaar over IPv6 maar kunnen we zelf nog steeds niet naar IPv6-only diensten

Hmmm ja en nee, je kan dan prima maar een IPv6 only website toe omdat de Proxy uitgaand en LB inkomend de translatie verzorgt van IPv6 only extern naar IPv4 web frontend. Nee het is niet end to end native, maar je bent bereikbaar op IPv6 dat is volgens mij belangrijker dan native.

IPv6 op je LAN zie ik totaal de meerwaarde niet in. Behalve dat het veel extra werk is voor, een nihil aantal voordelen. Dubbel design, dubbel switch config, dubbel DNS beheer, dubbel firewall beheer, dubbele lasten 1e lijns helpdesk etc etc.

Ik geloof in IPv6, maar de komende 15 jaar is op de edges van het netwerk ruim voldoende.Zodat we met zijn alle de transformatie van oud-v4 naar nieuw-v6 door gaan maken. En als er dan echt ziekenhuizen zijn die met 10.0.0.0/8 en alle andere RFC 1918 blokken intern niet uitkomen, ja voor die partijen is IPv6 op het LAN een must en deel ik jouw visie.

[Paul]

stormfly schreef op maandag 6 november 2017 @ 07:07:
de Proxy

Als we het daar ook naar doortrekken wel ja

IPv6 op je LAN zie ik totaal de meerwaarde niet in. Behalve dat het veel extra werk is voor, een nihil aantal voordelen. Dubbel design, dubbel switch config, dubbel DNS beheer, dubbel firewall beheer, dubbele lasten 1e lijns helpdesk etc etc.

Hoezo switch config? DNS heb je een punt, qua firewall hoop ik dat je met objecten werkt en dat een host-object anno 2017 niet meer alleen IPv4 of alleen IPv6 heeft.

Ik geloof in IPv6, maar de komende 15 jaar is op de edges van het netwerk ruim voldoende.

Het is natuurlijk wachten op de eerste dienst die we willen gebruiken die niet via de proxy werkt, de lijst in onze WPAD is behoorlijk lang Geen idee waarom, ik zit niet bij netwerkbeheer al doe ik wel dat rare hybride geval genaamd loadbalancer

[ANdrode]

stormfly schreef op maandag 6 november 2017 @ 07:07:
[...]
IPv6 op je LAN zie ik totaal de meerwaarde niet in. Behalve dat het veel extra werk is voor, een nihil aantal voordelen. Dubbel design, dubbel switch config, dubbel DNS beheer, dubbel firewall beheer, dubbele lasten 1e lijns helpdesk etc etc.

Aan de applicatie kant valt de last door IPv6 mee. Wanneer je dual stack uitrolt schuift jouw verkeer vanzelf naar IPv6 toe.

Wat inderdaad echt veranderd is de configuratie. Die moet je eigenlijk al genereren om te schalen. En als je eenmaal genereert dan is IPv6 geen lastige extra stap. Routering bij IPv6 is ook een stuk simpeler. Je hebt praktisch ongelimiteerd veel adressen om hierarchisch/logisch op te delen en hoeft niet met kleine subnetten te werken.

Een /48 of meer per gebouw is makkelijker te verdelen dan die IPv4 subnetten.
Sowieso zijn firewalls lastig consistent te houden zonder dat de configuratie uit IP Address Management tools volgt

Ik geloof in IPv6, maar de komende 15 jaar is op de edges van het netwerk ruim voldoende.Zodat we met zijn alle de transformatie van oud-v4 naar nieuw-v6 door gaan maken. En als er dan echt ziekenhuizen zijn die met 10.0.0.0/8 en alle andere RFC 1918 blokken intern niet uitkomen, ja voor die partijen is IPv6 op het LAN een must en deel ik jouw visie.

Ik heb recent met een senior netwerk engineer van een grote organisatie gesproken. Een organisatie waar zelfs binnen één deel de grote RFC 1918 blokken te klein zijn.
IPv6 was een pijnlijk onderwerp

Tot mijn verbazing was de segmentatie in overlappend RFC 1918 volgens deze medewerker geen beperking. Netwerk segmentatie in zo'n vorm (lagen voor security, kleine broadcast domains) pasten ze sowieso toe. Shared services zijn bereikbaar dmv routing.

Het is "lastig" dat een individuele machine niet uniek adresseerbaar is. Maar daar loop je tegenaan wanneer de architectuur niet aansluit bij de toepassing.

Het is wel tricky dat IP's overlappen. Maar dat lijkt *eigenlijk* erg op wat er bij DHCP voorkomt.
Weet ook niet hoe hun windows netwerk dit opvangt. Ik geloof dat ze zonder lokale opslag/met "flex" plekken werken met VPN met RSA securid naar de omgeving waar je echt in werkt.

[Bigs]

Roetzen schreef op vrijdag 27 oktober 2017 @ 22:21:
fUPC geschikt maken voor Dual Stack? Dat gaan ze niet doen natuurlijk. Een DS-Lite netwerk is technisch veel eenvoudiger en overzichtelijker dan een Dual Stack netwerk. Dual Stack is sowieso geen eindoplossing omdat er niet genoeg IPv4 adressen zijn om in de toekomst iedereen een eigen IPv4 adres te geven. Dat is nu juist de belangrijkste reden waarom we naar IPv6 moeten. Dus wie een goedlopend netwerk heeft met DS-Lite gaat niet investeren om het geschikt te maken voor Dual Stack. Uiteindelijk moeten we allemaal aan de DS-Lite. Wen er maar aan.

Ik zie ook nog wel een voordeel in DS-Lite; er is hier al eerder een onderzoek voorbij gekomen van een grote content speler die aantoonde dat IPv6 sneller is dan IPv4. Met DS-Lite zal dat verschil mogelijk nog groter zijn (ookal wordt CGNAT natuurlijk in hardware uitgevoerd en zal de impact niet super groot zijn). Dit kan toch helpen om content providers aan te moedigen eerder over te stappen op IPv6 en zo het kip-ei probleem nog verder te verkleinen.

[stormfly]

@ANdrode @Paul

Ik redeneerde vanuit mgmt perspectief kosten/baten ;-) Maar als techneut deel ik toch wel een deel van de visie van managers, aan de edges meer dan voldoende.

Ik zou al in mijn handen klappen als ik overal waar ik internet krijg aangeboden ook een IPv6 adres zou krijgen tussen nu en 2020. Native op het LAN, nice to have, bereikbaar op het internet must have

[Snow_King]

Ach, ik zie het zo. Elk bedrijf wat intern zijn IPv6 niet op orde krijgt (of wil krijgen) zal over een tijdje gewoon tegen problemen gaan aanlopen.

Zodra de ISP's (kan even duren!) IPv6 hebben en het meerendeel van het verkeer (zie België) over IPv6 gaat krijgt op een gegeven moment IPv4 minder aandacht,.

Succes dan met al je dubbele NAT netwerken e.d!

[ANdrode]

stormfly schreef op maandag 6 november 2017 @ 12:35:
@ANdrode @Paul
Ik redeneerde vanuit mgmt perspectief kosten/baten ;-) Maar als techneut deel ik toch wel een deel van de visie van managers, aan de edges meer dan voldoende.

Ik zou al in mijn handen klappen als ik overal waar ik internet krijg aangeboden ook een IPv6 adres zou krijgen tussen nu en 2020. Native op het LAN, nice to have, bereikbaar op het internet must have

Ik zie juist nog geen prikkel om via IPv6 bereikbaar te zijn. Dual stack zorgt voor extra werk en vraagtekens wat betreft beveiliging. Je moet dezelfde ACL's en firewall opgezet hebben voor beide. In de binnenste netwerkring wil je zulke complexiteit liever niet.

De vraag naar IPv6 op LAN zie ik eerder vanuit een andere hoek komen dan klassieke laptop/telefoon/desktops:

Ik heb een pilot gezien die ontstond vanuit facilitair management (!) die IPv6 effectief toepaste (6LowPAN). Waarom? Camera's, sensor nodes, schakelaars, lampen moeten uniek adresseerbaar zijn en kan je dus niet makkelijk wegstoppen achter routing/nat
En IPv6 toepassen hoeft natuurlijk niet te betekenen dat iets vanaf het internet te bereiken is, dat wil je in zo'n geval juist meestal [nog] niet

[ Voor 8% gewijzigd door ANdrode op 06-11-2017 12:52 ]

[Snow_King]

ANdrode schreef op maandag 6 november 2017 @ 12:50:
[...]


Ik zie juist nog geen prikkel om via IPv6 bereikbaar te zijn. Dual stack zorgt voor extra werk en vraagtekens wat betreft beveiliging. Je moet dezelfde ACL's en firewall opgezet hebben voor beide. In de binnenste netwerkring wil je zulke complexiteit liever niet.

De vraag naar IPv6 op LAN zie ik eerder vanuit een andere hoek komen dan klassieke laptop/telefoon/desktops:

Dan haal je IPv4 toch gewoon weg? Heb je één protocol, namelijk IPv6. Op je Edge kan je dan nog Ipv4 doen met een proxy oid, maar intern heb je het niet nodig.

[Maurits van Baerle]

Snow_King schreef op maandag 6 november 2017 @ 13:21:
[...]

Dan haal je IPv4 toch gewoon weg? Heb je één protocol, namelijk IPv6. Op je Edge kan je dan nog Ipv4 doen met een proxy oid, maar intern heb je het niet nodig.

Dat is precies wat Facebook heeft gedaan. IPv4 ondersteuning intern volledig verwijderen en alleen nog toepassen op de webserver die met de klant moeten praten.

[ANdrode]

Snow_King schreef op maandag 6 november 2017 @ 13:21:
[...]
Dan haal je IPv4 toch gewoon weg? Heb je één protocol, namelijk IPv6. Op je Edge kan je dan nog Ipv4 doen met een proxy oid, maar intern heb je het niet nodig.

Ja dat is het waard en eigenlijk de enige uitweg. Het is een natuurlijke oplossing in de container/k8s wereld

[Paul]

Snow_King schreef op maandag 6 november 2017 @ 13:21:
Dan haal je IPv4 toch gewoon weg?

Dat is nog niet zo simpel, dat kost dezelfde moeite en testen als het aanzetten van IPv6, alle applicaties die je hebt doortesten of het in de nieuwe situatie nog werkt.

Thuis durf ik dat wel aan, als ik zie wat we voor soft- en hardware hebben draaien @work dan weet ik dat zo nog niet. En als bijvoorbeeld Philips zegt dat hun MRI van een paar miljoen (waar we het gebouw omheen hebben gebouwd ipv dat we het apparaat in het gebouw hebben geïnstalleerd) geen IPv6 snapt dan hang je al.

Goed, niet iedereen moet direct bij die MRI kunnen; veruit de meeste mensen hoeven enkel de plaatjes maar uit het PACS te kunnen opvragen, maar je snapt het idee

Ik geloof dat we nog ergens een segmentje met NetBEUI hebben

[Bigs]

Snow_King schreef op maandag 6 november 2017 @ 12:36:
Ach, ik zie het zo. Elk bedrijf wat intern zijn IPv6 niet op orde krijgt (of wil krijgen) zal over een tijdje gewoon tegen problemen gaan aanlopen.

Zodra de ISP's (kan even duren!) IPv6 hebben en het meerendeel van het verkeer (zie België) over IPv6 gaat krijgt op een gegeven moment IPv4 minder aandacht,.

Succes dan met al je dubbele NAT netwerken e.d!

Dat gaat nog wel even duren denk ik. Wij hadden onlangs een probleem met een transitprovider die een ongeldige route naar bepaalde IPv6 prefixen van KPN aankondigde. Het duurde even voordat we dat hier doorhadden (meldingen van twee individuele KPN gebruikers dat het verbinden naar onze diensten lang duurde ivm falende IPv6 verbinding). Die routes hebben er dus bijna drie weken gestaan. Het antwoord van de transitprovider over hoe dit zo lang kon gebeuren (KPN is geen kleine partij en het trof niet alleen ons) laat zich raden: IPv6 wordt zo weinig gebruikt dat het nog niemand was opgevallen de prijs die je betaalt als early adopter.

[Snow_King]

Paul schreef op maandag 6 november 2017 @ 15:01:
[...]
Dat is nog niet zo simpel, dat kost dezelfde moeite en testen als het aanzetten van IPv6, alle applicaties die je hebt doortesten of het in de nieuwe situatie nog werkt.

Thuis durf ik dat wel aan, als ik zie wat we voor soft- en hardware hebben draaien @work dan weet ik dat zo nog niet. En als bijvoorbeeld Philips zegt dat hun MRI van een paar miljoen (waar we het gebouw omheen hebben gebouwd ipv dat we het apparaat in het gebouw hebben geïnstalleerd) geen IPv6 snapt dan hang je al.

Goed, niet iedereen moet direct bij die MRI kunnen; veruit de meeste mensen hoeven enkel de plaatjes maar uit het PACS te kunnen opvragen, maar je snapt het idee

Ik geloof dat we nog ergens een segmentje met NetBEUI hebben

Snap ik helemaal. Ik ben blij in een omgeving te werken met bar weinig legacy. En wat er is wordt er heel snel uit gesloopt.

Zo draaien wij al duizenden (ja, zo veel) servers op Dual-Stack en honderden al IPv6-only.

Al jaren geleden mee begonnen en blijven we nog altijd gewoon door zetten.

Ben heel blij al lang van IPv4 af te zijn. Mensen klagen bij ons als IPv6 niet werkt. v4 boeit veel mensen niet zo.

[databeestje]

Hier lekker aan het hobbyen geweest en IPv6 voor onze winkels aangezet, vooralsnog weinig problemen. Wel een prefix -> shopid tool gebouwd voor winkel identificatie voor het intranet. In het verleden konden we dat gewoon afleiden van het IPv4 adres, maar daar moest nu iets meer voor komen.

Gelukkig doen de meeste apparaten netjes een EUI64, dus kunnen we het adres ook matchen aan de geregistreerde apparatuur, dat helpt.

Uiteraard zitten er nog wat haken en ogen aan, de HP MFP 426 printers ondersteunen wel IPv6, maar geen handmatig adres waardoor deze alleen via de EUI64 te bereiken is. Dat is dus niet erg handig voor IP nummer plannen en dergelijke, zoals volautomatisch printer poorten installeren op de Backoffice PC's. Dan moet dat stuk provisioning ook weer vanuit de hardware registratie gedreven worden met alle issues bij hardware vervanging.

Vooruitgang is geboekt.

[hkoster1]

Als ik in een terminal op mijn iMac de opdracht "ping6 -c 4 -I en1 ff02::1" geef krijg ik een lange lijst van met IPv6 aangesloten apparaten. Ik kan ze bijna allemaal identificeren, inclusief mijn Connect Box modem/router met DS-Lite.

Maar er is er eentje waar ik geen vat op kan krijgen. Uit het fe80::250:f1ff:fe64:xxxx adres maak ik op dat het een apparaat is met MAC-adres 00:50:F1:64:xx:xx, en dat is van Intel Corp. Maar ik heb zo'n apparaat helemaal niet, althans niet dat ik weet... Het is er nog steeds als ik alle apparaten (behalve de iMac en de Connect Box) uit zet. Er is ook geen apparaat met dat MAC-adres in de lijst met aangesloten apparaten op de Connect Box.

Weet iemand raad? De Connect Box (Compal) draait een Intel Puma-6 chip, is dat een idee?

[ Voor 6% gewijzigd door hkoster1 op 07-11-2017 22:26 ]

[Verwijderd]

hkoster1 schreef op dinsdag 7 november 2017 @ 22:24:
Als ik in een terminal op mijn iMac de opdracht "ping6 -c 4 -I en1 ff02::1" geef krijg ik een lange lijst van met IPv6 aangesloten apparaten. Ik kan ze bijna allemaal identificeren, inclusief mijn Connect Box modem/router met DS-Lite.

Maar er is er eentje waar ik geen vat op kan krijgen. Uit het fe80::250:f1ff:fe64:xxxx adres maak ik op dat het een apparaat is met MAC-adres 00:50:F1:64:xx:xx, en dat is van Intel Corp. Maar ik heb zo'n apparaat helemaal niet, althans niet dat ik weet... Het is er nog steeds als ik alle apparaten (behalve de iMac en de Connect Box) uit zet. Er is ook geen apparaat met dat MAC-adres in de lijst met aangesloten apparaten op de Connect Box.

Weet iemand raad? De Connect Box (Compal) draait een Intel Puma-6 chip, is dat een idee?

http://[fe80::250:f1ff:fe64:xxxx]
httpS://[fe80::250:f1ff:fe64:xxxx]

Misschien wireshark starten, komen ook wel eens namen en berichten voorbij. Als de rest uitstaat zie je het misschien wel aan een mogelijk aanwezig ipv4 adres.

[hkoster1]

Nee, http, https, telnet, ssh werken allemaal niet, ook niet als het IPv6-adres volledig wordt uitgeschreven.
Ik heb net nog eens de test herhaald: wifi uitgezet en alleen een laptopje bekabeld aangesloten. Ook dan is dit spookadres nog actief (naast de ConnectBox zelf en het laptopje). Het ligt dus niet aan de iMac.

Mijn conclusie is dat dit een IPv6-interface is in of via de Connect Box zelf, maar wat?

Overigens staat bij mij ook het delen van de aansluiting met andere Ziggoklanten uit, maar een van mijn buren binnen bereik heeft dat wel aan staan... misschien antwoordt dat interface op de ff02::1 ping6-vraag.

Zien andere gebruikers met Connect Box + DS-Lite ook zo'n fe80::250::f1xx:xxxx:xxxx interface?

[Crazy-]

Vandaag mijn MirkoTik een 6to4 tunnel gegeven via Hurricane

helaas gaat het niet helemaal lekker en kom er niet helemaal uit waarom niet.

ik heb de mikrotik ingesteld als volgt:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=86.80.xx.xx mtu=1280 name=sit1 remote-address=216.66.84.46

/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:xxxx:dd5::1 scope=30 target-scope=10

/ipv6 address add address=2001:470:xxxx:dd5::2/64 advertise=no disabled=no eui-64=no interface=sit1

/ipv6 address add address=2001:470:yyyy:dd5::/64 interface=bridge-local advertise=yes
/ipv6 nd set [ find default=yes ] advertise-dns=yes
/ip dns set allow-remote-requests=yes servers=2001:4860:4860::8888,2001:4860:4860::4444

DHCPipV6 : 2001:470:yyyy:dd5::/64

maar helaas; behalve Google & Tweakers (zo ver ik ipv6 hosts ken ;-)) kan ik verder niets bereiken zodra IPv6 aan staat.

ergens mis ik een hopje / vertaling naar ipv4 gok ik...

[Raven]

Crazy- schreef op woensdag 8 november 2017 @ 22:44:
Vandaag mijn MirkoTik een 6to4 tunnel gegeven via Hurricane

helaas gaat het niet helemaal lekker en kom er niet helemaal uit waarom niet.

ik heb de mikrotik ingesteld als volgt:


[...]


DHCPipV6 : 2001:470:yyyy:dd5::/64

maar helaas; behalve Google & Tweakers (zo ver ik ipv6 hosts ken ;-)) kan ik verder niets bereiken zodra IPv6 aan staat.

ergens mis ik een hopje / vertaling naar ipv4 gok ik...

Sta je ICMPv6 (met name packet-too-big) toe?

[Crazy-]

Raven schreef op donderdag 9 november 2017 @ 10:01:
[...]

Sta je ICMPv6 (met name packet-too-big) toe?

Op dit moment is de firewall van IPv6 leeg. Ik zie verder hier niets over terug komen?

[stormfly]

Crazy- schreef op woensdag 8 november 2017 @ 22:44:
Vandaag mijn MirkoTik een 6to4 tunnel gegeven via Hurricane

helaas gaat het niet helemaal lekker en kom er niet helemaal uit waarom niet.

ik heb de mikrotik ingesteld als volgt:


[...]


DHCPipV6 : 2001:470:yyyy:dd5::/64

maar helaas; behalve Google & Tweakers (zo ver ik ipv6 hosts ken ;-)) kan ik verder niets bereiken zodra IPv6 aan staat.

ergens mis ik een hopje / vertaling naar ipv4 gok ik...

Er zijn ook niet gek veel meer IPv6 sites ja google/akamai en Facebook. Dan heb je het gros van de bulk data wel gehad.

Ik denk dat je iets gesloopt hebt in IPv4 NAT waardoor je niet meer op het IPv4 internet komt?

[MrNGm]

Crazy- schreef op donderdag 9 november 2017 @ 10:34:
[...]


Op dit moment is de firewall van IPv6 leeg. Ik zie verder hier niets over terug komen?

Ik heb vergelijkbare regels als hier in de firewall van m'n router staan (Mikrotik RB750GL). Met de config die je hebt gebruikt kan je waarschijnlijk alleen vanaf je router naar het wereldwijde IPv6-web.

[Crazy-]

MrNGm schreef op donderdag 9 november 2017 @ 14:24:
[...]


Ik heb vergelijkbare regels als hier in de firewall van m'n router staan (Mikrotik RB750GL). Met de config die je hebt gebruikt kan je waarschijnlijk alleen vanaf je router naar het wereldwijde IPv6-web.

ik ga er even naar kijken; let wel dat ik nu geen IPv4 meer kan bereiken... ipv6 werkt juist wel

[MrNGm]

Crazy- schreef op donderdag 9 november 2017 @ 17:37:
[...]


ik ga er even naar kijken; let wel dat ik nu geen IPv4 meer kan bereiken... ipv6 werkt juist wel

Weird, enige regel (nu ik er nogmaals naar kijk) lijkt deze te zijn:

/ip dns set allow-remote-requests=yes servers=2001:4860:4860::8888,2001:4860:4860::4444

[Zaffo]

Crazy- schreef op donderdag 9 november 2017 @ 10:34:
[...]


Op dit moment is de firewall van IPv6 leeg. Ik zie verder hier niets over terug komen?

Sinds RouterOS versie 6.40 is er een IPv6 firewall als onderdeel van de default config (eindelijk). Kijk daar ook eens naar.

Ik ga van het weekend ook eens kijken naar een HE tunnel. Dan kan ik eens kijken of het interne IPv6 hier een beetje op orde is en hebben de firewall regels ook wat te doen.

[Crazy-]

Ai! eest maar eens updaten dan ;-)

code:

Current Version     6.27
Latest Version      6.40.5

dat is geregeld ... maar eens verder testen

Helaas; nog geen soelaas
heb de boel opnieuw ingeregeld, nu krijg ik de volgende melding:

/ipv6 add address address=2001:470:yyyy:dd5::/64 interface=bridge-local advertise=yes

duplicate address

ik kan echter nergens de yyyy address/range terug vinden

[ Voor 50% gewijzigd door Crazy- op 09-11-2017 21:39 ]

[hkoster1]

MrNGm schreef op donderdag 9 november 2017 @ 18:19:
[...]


Weird, enige regel (nu ik er nogmaals naar kijk) lijkt deze te zijn:

/ip dns set allow-remote-requests=yes servers=2001:4860:4860::8888,2001:4860:4860::4444

Moet die laatste dns-server niet 2001:4860:4860::8844 zijn?

[Zaffo]

Oke, de tunnel naar Hurricane Electric draait nu een tijdje en alles lijkt te werken. Ik kan nu zowel naar IPv6 adressen pingen, alswel hostnames pingen met ping6, als ook websites bezoeken over de tunnel. Yeeh, eindelijk een IPv6 verbinding met de buitenwereld.

De gebruikte configuratie (Mikrotik RouterOS):

code:

/interface 6to4
add comment="IPv6 Tunnel - Hurricane Electric" !keepalive local-address=212.187.***.*** mtu=1280 name=6to4-tunnel_he1 remote-address=216.66.84.46

/interface list member
add interface=6to4-tunnel_he1 list=WAN

/ipv6 address
add address=2001:470:***4:****::2 advertise=no comment="IPv6 Tunnel - Hurricane Electric" interface=6to4-tunnel_he1
add address=2001:470:***5:****:: comment="IPv6 prefix - Hurricane Electric - local use" interface=ether2

/ipv6 nd
set [ find default=yes ] advertise-dns=yes

/ipv6 route
add comment="IPv6 tunnel - HE" distance=1 dst-address=2000::/3 gateway=6to4-tunnel_he1

Ten opzichte van de gegeven voorbeeld configuratie heb ik voor de route te gateway veranderd van IP adres naar interface naam. Het duurde ook even voor ik doorhad dat de prefix voor locaal gebruik een andere is dan die voor de tunnel gebruikt wordt.

[Roetzen]

Heb je ook iets IPv6 pingbaars in het LAN hangen?

[Zaffo]

Intern pingbaar wel (en benaderbaar), maar dit was de IPv6 capabele apparatuur al met link-local adressen.

Vanaf extern wordt voor zover ik nu getest heb alles door de firewall afgevangen. Ik heb o.a. dit en dit tooltje gebruikt.

[ Voor 11% gewijzigd door Zaffo op 11-11-2017 17:01 ]

[maikel]

Ik zit toch weer eens te kijken naar de mogelijkheid om IPv6 te gebruiken, ondanks dat Ziggo het, bij mij, nog niet heeft uitgerold. Ik heb een Sophos Firewall XG draaien en heb daar een HE-tunnel (6in4) op geconfigureerd.
Tevens heb ik een static route ingesteld voor ::/0 naar de tunnel.

Deze firewall staat als DMZ in mijn modem ingesteld en verder staat in het modem alles qua firewall en 'WAN blocking' uit.

Maar toch kan ik niet pingen naar het IPv6-adres van bijvoorbeeld Google.

Zie ik nog iets over het hoofd?

[Roetzen]

Nieuwe Measurements. KPN nog steeds in de lift Nu boven 20% . Ziggo blijft hangen op rondr 8%.





Met de aantekening dat nog steeds niet duidelijk is of de cijfers van Ziggo representatief zijn voor de situatie.

[Maurits van Baerle]

Ik ben de laatste stand een beetje kwijt. Als je nu in fZiggo gebied zit en een nieuwe aansluiting krijgt (of een oud modem laat vervangen door de nieuwste) wat voor modem krijg je dan en krijg je dan een DS, DS-Lite of alleen IPv4 verbinding?

Zowel mijn broertje als mijn zusje hebben nog zo'n antieke Motorola Surfboard staan. Ik wil ze wel eens gaan overhalen om die te vervangen maar wil dat pas doen als het ook gevolgen heeft voor hun IPv6 connectivity.

[Roetzen]

Maurits van Baerle schreef op donderdag 23 november 2017 @ 12:19:
Ik ben de laatste stand een beetje kwijt. Als je nu in fZiggo gebied zit en een nieuwe aansluiting krijgt (of een oud modem laat vervangen door de nieuwste) wat voor modem krijg je dan en krijg je dan een DS, DS-Lite of alleen IPv4 verbinding?

Het gerucht gaat dat iedereen, nieuwe aansluiting of modem vervangen, nu een connect box krijgt. (Die met de PUMA6 chip). In fUPC gebied krijg je dan DS-Lite. In fZiggo gebied krijgen oude klanten Dual Stack en nieuwe klanten DS-Lite.

Hang me er niet aan op, het is geen officieel gepubliceerd beleid van Ziggo, het is wat we hier zo'n beetje geconcludeerd hebben uit wat door gebruikers gerapporteerd werd.

Zowel mijn broertje als mijn zusje hebben nog zo'n antieke Motorola Surfboard staan. Ik wil ze wel eens gaan overhalen om die te vervangen maar wil dat pas doen als het ook gevolgen heeft voor hun IPv6 connectivity.

Die Motorola Surfboards waren prima modems. Maar ze halen niet meer dan 30 Mbps. Ik heb de mijne nog tot medio verleden jaar in gebruik gehad.

[Maurits van Baerle]

Roetzen schreef op donderdag 23 november 2017 @ 12:46:
[...]

Het gerucht gaat dat iedereen, nieuwe aansluiting of modem vervangen, nu een connect box krijgt. (Die met de PUMA6 chip). In fUPC gebied krijg je dan DS-Lite. In fZiggo gebied krijgen oude klanten Dual Stack en nieuwe klanten DS-Lite.

Hang me er niet aan op, het is geen officieel gepubliceerd beleid van Ziggo, het is wat we hier zo'n beetje geconcludeerd hebben uit wat door gebruikers gerapporteerd werd.

[...]

Die Motorola Surfboards waren prima modems. Maar ze halen niet meer dan 30 Mbps. Ik heb de mijne nog tot medio verleden jaar in gebruik gehad.

Thanks! Ga me er dan eens in verdiepen, als oude klanten DS krijgen dan is het wel de moeite waard. Ff checken in hoeverre dat PUMA6 verhaal nu nog steeds een probleem is of dat het met nieuwere firmware is opgelost.

[Roetzen]

Maurits van Baerle schreef op donderdag 23 november 2017 @ 13:18:
[...]

Thanks! Ga me er dan eens in verdiepen, als oude klanten DS krijgen dan is het wel de moeite waard. Ff checken in hoeverre dat PUMA6 verhaal nu nog steeds een probleem is of dat het met nieuwere firmware is opgelost.

Dat PUMA 6 probleem is niet met firmware oplosbaar. In hoeverre je broer en zus daar last van gaan hebben kan ik niet beoordelen."Gewone gebruikers" schijnen er niet veel last van te hebben. Als dat wel een probleem gaat worden is het misschien een optie dat oude Motorola ding nog maar even in ere te houden. En anders maar in het diepe springen...

Een Ubee die IPv6 doet van marktplaats halen is helaas geen optie meer....

[loyske]

Het viel mij gisteren bij mijn ouders (fZiggo gebied) op, dat ze sinds gisteren een Dual Stack hebben op hun ConnectBox!

[Compizfox]

loyske schreef op dinsdag 28 november 2017 @ 09:58:
Het viel mij gisteren bij mijn ouders (fZiggo gebied) op, dat ze sinds gisteren een Dual Stack hebben op hun ConnectBox!

Echte dual-stack of DS-Lite?

[loyske]

Compizfox schreef op dinsdag 28 november 2017 @ 11:14:
[...]

Echte dual-stack of DS-Lite?

Full Dual Stack en pas sinds gisteren geactiveerd!

[ Voor 9% gewijzigd door loyske op 28-11-2017 11:23 ]

[St00mwals]

loyske schreef op dinsdag 28 november 2017 @ 09:58:
Het viel mij gisteren bij mijn ouders (fZiggo gebied) op, dat ze sinds gisteren een Dual Stack hebben op hun ConnectBox!

Welke regio van het fZiggo gebied zitten ze?
Ik zal (als ik er weer eens ben) bij mijn schoonouders in Twente kijken of ze daar nu ook DS hebben.

[Glashelder]

Kunnen jullie de site van Forza Refurbished bereiken (https://www.forza-refurbished.nl/) ? Volgens mij hebben ze iets verprutst in hun ipv6 config

[daxy]

loyske schreef op dinsdag 28 november 2017 @ 11:23:
[...]


Full Dual Stack en pas sinds gisteren geactiveerd!

Oh, vertel meer!!! Is het echt Full Dual Stack en geen DS-Lite? En welk modem hebben ze? Bij Connectbox is het Arris of Compal? Dat wordt modem rebooten als ik weer in het land ben

[Roetzen]

Glashelder schreef op dinsdag 28 november 2017 @ 14:15:
Kunnen jullie de site van Forza Refurbished bereiken (https://www.forza-refurbished.nl/) ? Volgens mij hebben ze iets verprutst in hun ipv6 config

Geen probleem hier. fZiggo gebied, Driebergen, Full Dual Stack met Ubee EVW 321b.
.

[Hipska]

Glashelder schreef op dinsdag 28 november 2017 @ 14:15:
Kunnen jullie de site van Forza Refurbished bereiken (https://www.forza-refurbished.nl/) ? Volgens mij hebben ze iets verprutst in hun ipv6 config

Op een DS verbinding in BE geen probleem mee..

[agresionpower]

Glashelder schreef op dinsdag 28 november 2017 @ 14:15:
Kunnen jullie de site van Forza Refurbished bereiken (https://www.forza-refurbished.nl/) ? Volgens mij hebben ze iets verprutst in hun ipv6 config

werkt bij mij op v6

volledige ipvfoo zegt:

Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. www.forza-refurbished.nl 2001:1460::6:8ce9
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. app.trengo.eu 37.252.126.22
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. bat.bing.com 204.79.197.200
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. beacon.krxd.net 54.217.209.77
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. cdn.widget.trengo.eu 2600:9000:2001:1800:12:e853:eec0:93a1 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. cdnjs.cloudflare.com 2400:cb00:2048:1::6813:c166 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. criteo-partners.tremorhub.com 52.205.154.205
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. csi.gstatic.com 2a00:1450:400e:800::2003
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. cw.addthis.com 34.253.118.195
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. dis.criteo.com 178.250.2.76
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. dis.eu.criteo.com 178.250.0.77
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. fonts.googleapis.com 172.217.20.74 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. fonts.gstatic.com 2a00:1450:400e:800::2003 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. i.liadm.com 52.5.81.66
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. idsync.rlcdn.com 34.201.232.85
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. img.youtube.com 2a00:1450:400e:808::200e Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. insights.hotjar.com 52.209.227.123
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. maps.googleapis.com 2a00:1450:400e:802::200a
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. maxcdn.bootstrapcdn.com 108.161.189.121 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. p.adsymptotic.com 94.31.6.159
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. script.crazyegg.com 54.192.13.161 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. script.hotjar.com 23.111.9.32 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. sslwidget.criteo.com 178.250.2.82
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. static.criteo.net 178.250.0.74 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. static.hotjar.com 151.139.236.194 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. tags.bluekai.com 23.206.93.162
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. vars.hotjar.com 94.31.29.64 Data from cached requests only.
Connection uses HTTPS.
Warning: IPvFoo does not verify the integrity of encryption. www.facebook.com 2a03:2880:f106:83:face:b00c:0:25de

[loyske]

St00mwals schreef op dinsdag 28 november 2017 @ 13:52:
[...]

Welke regio van het fZiggo gebied zitten ze?
Ik zal (als ik er weer eens ben) bij mijn schoonouders in Twente kijken of ze daar nu ook DS hebben.

Zuid Limburg

daxy schreef op dinsdag 28 november 2017 @ 15:15:
[...]

Oh, vertel meer!!! Is het echt Full Dual Stack en geen DS-Lite? En welk modem hebben ze? Bij Connectbox is het Arris of Compal? Dat wordt modem rebooten als ik weer in het land ben

Het is echt Full DS (een IPv4 en IPv6 adres) en geen DS-Lite (staat op off oid in het overzicht).
Ik gok dat het een Compal CB is, maar moet ik nakijken als ik er weer ben.

Zit zelf in dezelfde regio, maar mijn modem is bridged ivm eiger router. Ben beetje huiverig om dit aan te gaan passen.

[Glashelder]

Roetzen schreef op dinsdag 28 november 2017 @ 15:35:
[...]

Geen probleem hier. fZiggo gebied, Driebergen, Full Dual Stack met Ubee EVW 321b.
.

Hipska schreef op dinsdag 28 november 2017 @ 17:28:
[...]

Op een DS verbinding in BE geen probleem mee..

Kunnen jullie ook inloggen? Dat is waar het hier mis gaat.. (wat ik niet duidelijk over sorry ).

[Hipska]

Ik heb er geen account, dus ik kan niet inloggen..

[Roetzen]

loyske schreef op woensdag 29 november 2017 @ 10:01:
Zit zelf in dezelfde regio, maar mijn modem is bridged ivm eiger router. Ben beetje huiverig om dit aan te gaan passen.

Voorlopig kun je nog altijd terug naar IPv4 only en bridged. Dus je loopt geen risico iets onomkeerbaars te doen. Laat je modem uit bridge halen, kijk of je IPv6 krijgt en zo ja, speel er een tijdje mee. Als het bevalt houd je het en als het niet bevalt, laat je het modem weer in bridge zetten en je bent weer terug in de situatie zoals die nu is. Kan je geen buil aan vallen denk ik.

[maikel]

maikel schreef op dinsdag 14 november 2017 @ 09:59:
Ik zit toch weer eens te kijken naar de mogelijkheid om IPv6 te gebruiken, ondanks dat Ziggo het, bij mij, nog niet heeft uitgerold. Ik heb een Sophos Firewall XG draaien en heb daar een HE-tunnel (6in4) op geconfigureerd.
Tevens heb ik een static route ingesteld voor ::/0 naar de tunnel.

Deze firewall staat als DMZ in mijn modem ingesteld en verder staat in het modem alles qua firewall en 'WAN blocking' uit.

Maar toch kan ik niet pingen naar het IPv6-adres van bijvoorbeeld Google.

Zie ik nog iets over het hoofd?

Iemand die hier nog een ideetje over heeft? Alles lijkt mij correct ingesteld te staan, maar toch wel het niet werken. In de logs zie ik wel dat er verkeer naar de HE-interface wordt gestuurd (en doorgelaten), maar ipv6-test.com geeft nog steeds aan dat IPv6 ' not supported' is.

[stormfly]

maikel schreef op vrijdag 1 december 2017 @ 11:33:
[...]


Iemand die hier nog een ideetje over heeft? Alles lijkt mij correct ingesteld te staan, maar toch wel het niet werken. In de logs zie ik wel dat er verkeer naar de HE-interface wordt gestuurd (en doorgelaten), maar ipv6-test.com geeft nog steeds aan dat IPv6 ' not supported' is.

Wat geeft een traceroute aan?

[maikel]

Die gaf alleen maar timeouts. Toen zag ik in m'n firewall dat er nog een static route gedefinieerd was voor 2001:470:1f15:282:: (de 'Routed /64' van HE). Ik kon ook vanaf mijn LAN de firewall niet pingen.

Nadat ik die route verwijderd heb (en dus alleen ::0/64 nog bestond, kon ik wel mijn firewall pingen. Vanaf dat moment geeft tracert eerste stap mijn Sophos Firewall aan en daarna een 'Destination host unreachable'.

Klopt het dat ik intern ook de range van adressen moet gebruiken die HE als 'Routed /64' aangeeft?

Hmm, nu is http://ipv6-test.com/ ook onbereikbaar van m'n LAN. Als ik de static route voor 2001:470:1f15:282::/64 weer toe voeg, kan ik die site wel weer openen. Maar die geeft nog steeds aan dat IPv6 unsupported is.

[ Voor 27% gewijzigd door maikel op 01-12-2017 14:26 ]

[Roetzen]

Maurits van Baerle schreef op donderdag 23 november 2017 @ 13:18:
[...]

Thanks! Ga me er dan eens in verdiepen, als oude klanten DS krijgen dan is het wel de moeite waard. Ff checken in hoeverre dat PUMA6 verhaal nu nog steeds een probleem is of dat het met nieuwere firmware is opgelost.

En? Al iets te melden?

[ik222]

Net even bezig geweest met een IPv6 packetloss issue op een paar Ubuntu 16.04 LTS VM's. Ik had specifiek op die VM's ongeveer 8 tot 10% packetloss via IPv6 (zowel met pings als met ander verkeer en zowel intern als extern) terwijl IPv4 wel zonder problemen werkte. Uiteindelijk captures gemaakt achter de firewall en tot daar zag ik al het verkeer gewoon terugkomen, het raakte dus echt pas kwijt op de VM.

Uiteindelijk heb ik op de betreffende VM's de NIC teruggezet naar E1000 (was VMXNET3) en daarmee is alles opgelost en werkt IPv6 wel gewoon goed.

Lijkt een beetje op deze bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605494 Al zou ik verwachten dat die fix inmiddels wel in de kernel van 16.04 LTS zou zitten? In elk geval lijkt het echt Ubuntu specifiek (kernel driver waarschijnlijk), want de firewall zelf (pfSense 2.4.2) draait op dezelfde host met ook VMXNET3 nics en die heeft geen problemen.

[ Voor 12% gewijzigd door ik222 op 02-12-2017 14:17 ]

[Raven]

ik222 schreef op zaterdag 2 december 2017 @ 14:14:

Heb je open-vm-tools geïnstalleerd op de Ubuntu VM's? pfSense installeert dat pakket dacht ik zelf al als ie een VM detecteert.

[ANdrode]

ik222 schreef op zaterdag 2 december 2017 @ 14:14:
Lijkt een beetje op deze bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1605494 Al zou ik verwachten dat die fix inmiddels wel in de kernel van 16.04 LTS zou zitten? In elk geval lijkt het echt Ubuntu specifiek (kernel driver waarschijnlijk), want de firewall zelf (pfSense 2.4.2) draait op dezelfde host met ook VMXNET3 nics en die heeft geen problemen.

Wat raar dat zulke issues nog steeds bestaan

Mijn vSphere VM's die ik gebruik hebben geen IPv6 dus heb daar geen ervaring mee. Mogelijk is dat (SLAAC announcements) juist hiervoor in dat subnet uitgezet. Heb er wel een redelijk aantal op KVM met virtio netwerkkaart, dat werkt zonder problemen.

[maikel]

maikel schreef op vrijdag 1 december 2017 @ 14:14:
Die gaf alleen maar timeouts. Toen zag ik in m'n firewall dat er nog een static route gedefinieerd was voor 2001:470:1f15:282:: (de 'Routed /64' van HE). Ik kon ook vanaf mijn LAN de firewall niet pingen.

Nadat ik die route verwijderd heb (en dus alleen ::0/64 nog bestond, kon ik wel mijn firewall pingen. Vanaf dat moment geeft tracert eerste stap mijn Sophos Firewall aan en daarna een 'Destination host unreachable'.

Klopt het dat ik intern ook de range van adressen moet gebruiken die HE als 'Routed /64' aangeeft?

Hmm, nu is http://ipv6-test.com/ ook onbereikbaar van m'n LAN. Als ik de static route voor 2001:470:1f15:282::/64 weer toe voeg, kan ik die site wel weer openen. Maar die geeft nog steeds aan dat IPv6 unsupported is.

Het laatste puntje is opgelost door de DNS correct te laten verwijzen (deze stond nog op 'Choose IPv4 DNS server over IPv6'). Maar ipv6-test.com geeft nog steeds aan dat er geen IPv6-verbinding is.

[stormfly]

maikel schreef op maandag 4 december 2017 @ 16:19:
[...]


Het laatste puntje is opgelost door de DNS correct te laten verwijzen (deze stond nog op 'Choose IPv4 DNS server over IPv6'). Maar ipv6-test.com geeft nog steeds aan dat er geen IPv6-verbinding is.

Als je vanaf de router via CLI ping naar buiten toe werkt dat wel? Heb je bij HE (website) je tunnel naar je thuis IP laten wijzen?

Routed segment -> Op de LAN interface van je router, de ::1 zou je hierop kunnen plaatsen.


Server IPv4 Address:216.66.84.46
Server IPv6 Address:2001:470:knip::1/64
Client IPv4 Address:knip
Client IPv6 Address:2001:470:knip::2/64

Het Server 2001:470:knip::1/64 IP is waar je default route naar wijst, de Client 2001:470:knip::2/64 staat op je WAN port.

[ Voor 28% gewijzigd door stormfly op 04-12-2017 16:38 ]

[ik222]

Raven schreef op zaterdag 2 december 2017 @ 18:18:
[...]

Heb je open-vm-tools geïnstalleerd op de Ubuntu VM's? pfSense installeert dat pakket dacht ik zelf al als ie een VM detecteert.

Nee dat draait daar niet, geen zin in alle compiler rommel die daarvoor nodig is op elke VM (tenzij je ze vooraf ergens gaat compileren voor elke kernel opnieuw). En ik mag hopen dat die tools niet nodig zijn voor iets simpels als fatsoenlijke netwerk connectiviteit.

@ANdrode: In het betreffende subnet gebruik ik static IPv6 only, RA staat dus uit evenals DHCPv6. Overigens heb ik voor de grap even een VMXNET3 NIC in een subnet met RA gehangen maar dan zie ik exact hetzelfde probleem. Zet ik er een good old E1000 virtuele NIC in dan werkt IPv6 probleemloos, dat is overigens voorlopig prima op deze VM's.

Moet wel toegeven dat VMWare ESXi niet helemaal up to date is (de Ubuntu 16.04 VM's wel), zit ergens in de 6.0 nog. Als ik wat meer tijd heb wellicht eens updaten.

[ Voor 6% gewijzigd door ik222 op 04-12-2017 17:00 ]

[maikel]

stormfly schreef op maandag 4 december 2017 @ 16:25:
[...]


Als je vanaf de router via CLI ping naar buiten toe werkt dat wel? Heb je bij HE (website) je tunnel naar je thuis IP laten wijzen?

Routed segment -> Op de LAN interface van je router, de ::1 zou je hierop kunnen plaatsen.


Server IPv4 Address:216.66.84.46
Server IPv6 Address:2001:470:knip::1/64
Client IPv4 Address:knip
Client IPv6 Address:2001:470:knip::2/64

Het Server 2001:470:knip::1/64 IP is waar je default route naar wijst, de Client 2001:470:knip::2/64 staat op je WAN port.

Een ping werkt wel, een ping6 niet.
En ik heb mijn thuis-IP inderdaad als 'Client IPv4 Address' geconfigureerd.

De LAN-interface op mijn Sophos Firewall heeft een IPv6-adres dat binnen het segment valt dat HE aan mij heeft toegekend.
De default route verwijst naar de interface HE. Dat is bij mij de tunnel. In die tunnel gebruik ik alleen maar IPv4-adressen aangezien het een 6in4-tunnel is.
Op mijn WAN-poort heb ik echter geen IPv6 ingesteld. Als ik dat doe, moet ik ook een gateway invullen. En mijn idee was dat dat juist niet de bedoeling is, omdat ik via een tunnel ga.

[stormfly]

maikel schreef op maandag 4 december 2017 @ 17:04:
[...]


Een ping werkt wel, een ping6 niet.
En ik heb mijn thuis-IP inderdaad als 'Client IPv4 Address' geconfigureerd.

De LAN-interface op mijn Sophos Firewall heeft een IPv6-adres dat binnen het segment valt dat HE aan mij heeft toegekend.
De default route verwijst naar de interface HE. Dat is bij mij de tunnel. In die tunnel gebruik ik alleen maar IPv4-adressen aangezien het een 6in4-tunnel is.
Op mijn WAN-poort heb ik echter geen IPv6 ingesteld. Als ik dat doe, moet ik ook een gateway invullen. En mijn idee was dat dat juist niet de bedoeling is, omdat ik via een tunnel ga.

Als je de default route naar de HE interface alleen hebt staan, heb je kans dat je het verkeer slechts binnen in je router houdt. Je moet het naar de next hop (overzijde) sturen dus het HE server v6 adres.

Iemand moet de 6in4 translatie uitvoeren, wie doet dat bij jou? Volgens mij zie jij de setup als "routed" maar het is een tunnel, iemand moet verkeer in de tunnel stoppen.

Op Ubuntu ziet dat er zo uit, misschien kan je dat beter eerst proberen gewoon op een Ubuntu servertje e.a. optuigen. Of de sophos is zo secure dat hij 6in4 default blokt, of je gaat de mist in met je interfaces/routing, of je sophos kan helemaal geen 6in4 aan.

Meer opties zijn er niet

code:

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:knip::2
netmask 64
mtu 1280
endpoint 216.66.84.46
ttl 255
gateway 2001:470:knip::1

[anboni]

Mag ik even gebruik maken van de collectieve kennis hier om na te gaan of ik nou gek aan het worden ben?

Ik probeer @work onze IPv6 verbinding aan de praat te krijgen. Situatieschets:

(we hebben x:y:z::/48 toegewezen gekregen)

Vanaf Ubuntu kan ik probleemloos pingen naar Mail en de wan interface van de Fortigate (x:y:z::2). Ping naar de CPE of verder geeft geen respons.
Vanaf de Fortigate kan ik pingen naar de CPE en verder. Op de fortigate heb ik voor alle combinaties van interfaces uit de schets accept ALL_ICMP6 staan van en naar alle hosts.

Ik denk (maar misschien pas ik teveel m'n IPv4 kennis toe) dat er simpelweg een route ontbreekt voor onze /48 vanaf de CPE naar de Fortigate. Ik heb het aan m'n ISP gevraagd. De eerste keer kreeg ik de interface config als antwoord. Toen ik nog een keer specifiek vroeg of het de routering van onze /48 kan zijn, kreeg ik als reactie pings van en naar de CPE. Ik heb ze uiteraard alweer gevraagd of ze mijn eigenlijke vraag nou eens willen beantwoorden, maar ondertussen begin ik ook aan mezelf te twijfelen. Zie ik iets over het hoofd of heb ik te maken met incompetente of onwillige supportmedewerkers?

[Raven]

ik222 schreef op maandag 4 december 2017 @ 16:59:
[...]

Nee dat draait daar niet, geen zin in alle compiler rommel die daarvoor nodig is op elke VM (tenzij je ze vooraf ergens gaat compileren voor elke kernel opnieuw). En ik mag hopen dat die tools niet nodig zijn voor iets simpels als fatsoenlijke netwerk connectiviteit.

, hier was een simpele apt-get install voldoende, of mis ik iets

[ik222]

Raven schreef op maandag 4 december 2017 @ 17:59:
[...]
, hier was een simpele apt-get install voldoende, of mis ik iets

Klopt maar heb je ook gekeken welke dependencies je toen allemaal mee kreeg voordat je "y" intypte?

Die VM tools worden namelijk on the fly gecompileerd bij installatie. Werkt allemaal wel maar vervolgens staan er dus een hele zooi compiler en dev library packages op je systeem. Ik geef toe voor thuis niet zo erg maar vanuit mijn werk ben ik daar allergisch voor.

[ANdrode]

anboni schreef op maandag 4 december 2017 @ 17:55:
Ik denk (maar misschien pas ik teveel m'n IPv4 kennis toe) dat er simpelweg een route ontbreekt voor onze /48 vanaf de CPE naar de Fortigate. Ik heb het aan m'n ISP gevraagd. De eerste keer kreeg ik de interface config als antwoord. Toen ik nog een keer specifiek vroeg of het de routering van onze /48 kan zijn, kreeg ik als reactie pings van en naar de CPE. Ik heb ze uiteraard alweer gevraagd of ze mijn eigenlijke vraag nou eens willen beantwoorden, maar ondertussen begin ik ook aan mezelf te twijfelen. Zie ik iets over het hoofd of heb ik te maken met incompetente of onwillige supportmedewerkers?

Hoe geeft de CPE de /48 door aan de Fortigate?

Bij de meeste consumenten routers die ik gebruikt heb moet je een (actieve) DHCPv6 lease hebben met prefix delegation voordat dit werkt. Bij veel CPE kan je de prefix grootte instellen.
Hele /48 zal niet lukken, CPE moet ook nog in een subnet

Als de provider PPPoE gebruikt zou ik de ISP-router overslaan

[anboni]

ANdrode schreef op maandag 4 december 2017 @ 19:46:
[...]
Hoe geeft de CPE de /48 door aan de Fortigate?

Native ethernet, het is een zakelijke provider.

[ANdrode]

anboni schreef op maandag 4 december 2017 @ 20:04:
[...]
Native ethernet, het is een zakelijke provider.

Bedankt voor deze duidelijke en uitputtende reactie…

In jouw diagram geef je aan dat de CPE én fortigate een IPv6 adres hebben. Zoek uit hoe dit geconfigureerd is. Hints: NDP & SLAAC

[maikel]

stormfly schreef op maandag 4 december 2017 @ 17:47:
[...]


Als je de default route naar de HE interface alleen hebt staan, heb je kans dat je het verkeer slechts binnen in je router houdt. Je moet het naar de next hop (overzijde) sturen dus het HE server v6 adres.

Iemand moet de 6in4 translatie uitvoeren, wie doet dat bij jou? Volgens mij zie jij de setup als "routed" maar het is een tunnel, iemand moet verkeer in de tunnel stoppen.

Op Ubuntu ziet dat er zo uit, misschien kan je dat beter eerst proberen gewoon op een Ubuntu servertje e.a. optuigen. Of de sophos is zo secure dat hij 6in4 default blokt, of je gaat de mist in met je interfaces/routing, of je sophos kan helemaal geen 6in4 aan.

Meer opties zijn er niet

code:

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:knip::2
netmask 64
mtu 1280
endpoint 216.66.84.46
ttl 255
gateway 2001:470:knip::1

Die 'next hop' is in de tunnel gedefinieerd. Daarin staat als remote address het IPv4-adres dat HE mij geeft. Met 'HE-interface' bedoelde ik ook de tunnel. Bij m'n route, kan ik die selecteren als 'interface'.
Ik heb alles geconfigureerd volgens deze posts: https://community.sophos..../10910/ipv6-tunnel-broker

Overigens is de route door Sophos zelf aangemaakt nadat ik de tunnel heb geconfigureerd. Het lijkt me dat dat ook gewoon goed zou zijn.

In mijn firewall is vanuit LAN naar WAN alles toegestaan via IPv4 en Ipv6. Bovendien is de tunnel in Sophos gedefinieerd waarbij de optie '6in4' is geselecteerd. Het lijkt me dus sterk dat deze het niet zou ondersteunen.

[ Voor 7% gewijzigd door maikel op 04-12-2017 21:02 ]

[Raven]

ik222 schreef op maandag 4 december 2017 @ 18:12:
[...]

Klopt maar heb je ook gekeken welke dependencies je toen allemaal mee kreeg voordat je "y" intypte?

Not really

ik222 schreef op maandag 4 december 2017 @ 18:12:
Die VM tools worden namelijk on the fly gecompileerd bij installatie. Werkt allemaal wel maar vervolgens staan er dus een hele zooi compiler en dev library packages op je systeem. Ik geef toe voor thuis niet zo erg maar vanuit mijn werk ben ik daar allergisch voor.

Kun je die niet met apt-get (auto)clean er later weer afknikkeren dan?

[maikel]

maikel schreef op maandag 4 december 2017 @ 20:58:
[...]


Die 'next hop' is in de tunnel gedefinieerd. Daarin staat als remote address het IPv4-adres dat HE mij geeft. Met 'HE-interface' bedoelde ik ook de tunnel. Bij m'n route, kan ik die selecteren als 'interface'.
Ik heb alles geconfigureerd volgens deze posts: https://community.sophos..../10910/ipv6-tunnel-broker

Overigens is de route door Sophos zelf aangemaakt nadat ik de tunnel heb geconfigureerd. Het lijkt me dat dat ook gewoon goed zou zijn.

In mijn firewall is vanuit LAN naar WAN alles toegestaan via IPv4 en Ipv6. Bovendien is de tunnel in Sophos gedefinieerd waarbij de optie '6in4' is geselecteerd. Het lijkt me dus sterk dat deze het niet zou ondersteunen.

Wat me wel opvalt: als ik in de console de IP-gegevens check, zie ik dat de tunnel een IP-adres heeft van fe80::20e... Moet dat niet in dezelfde range zitten als de rest van mijn netwerk/de range die ik van HE heb gekregen?
Ik kan dat alleen nergens instellen. Bij de tunnel moet ik IPv4-adressen instellen.

[MrNGm]

maikel schreef op dinsdag 5 december 2017 @ 09:32:
[...]


Wat me wel opvalt: als ik in de console de IP-gegevens check, zie ik dat de tunnel een IP-adres heeft van fe80::20e... Moet dat niet in dezelfde range zitten als de rest van mijn netwerk/de range die ik van HE heb gekregen?
Ik kan dat alleen nergens instellen. Bij de tunnel moet ik IPv4-adressen instellen.

Dat is een link-local adres. Dat wordt gebruikt om andere hosts op dezelfde link (switchlaag) te vinden via neighbour discovery.

Misschien ten overvloede, maar heb je gezien dat je routed /64 een net iets andere prefix heeft dan het server-client subnet?

[maikel]

MrNGm schreef op dinsdag 5 december 2017 @ 10:31:
[...]


Dat is een link-local adres. Dat wordt gebruikt om andere hosts op dezelfde link (switchlaag) te vinden via neighbour discovery.

Misschien ten overvloede, maar heb je gezien dat je routed /64 een net iets andere prefix heeft dan het server-client subnet?

Ja, dat heb ik gezien. Die range gebruik ik momenteel voor mijn interne netwerk.

[dion_b]

Mopper...

Iedere keer dat je echt goed naar een IPv6-gerelateerd onderwerp gaat kijken zie je prut.

Ik zat laatst in wat DHCP server logs te kijken en zag veel meer entries dan verwacht. Wat grondiger kijken: het waren allemaal DHCPv6 Solicit-berichten. Gek want IPv6 zou tussen de hosts en die server weggefilterd moeten worden. Toch kwamen ze binnen. Prut#1. Filter was vrij simpel: default deny all, allow IPv4 en ARP only. Maar dan prut #2: die DHCPv6 Solicits bevatten allemaal een unieke DUID, maar de DUID's leken verdacht op elkaar: de hosts gebruikten DUID-LLT, oftewel MAC-adres plus timestamp. Dat is valide, zie RFC6355/3315. In die RFC's staat echter:

DUIDs are intended to remain constant over time, so that they can be used as permanent identifiers for a device. In the case of the DUID-LLTs, they are intended to be generated once, stored in stable storage, and reused from that point forward.

Uhuh. Nou, blijkbaar heeft niemand die de DHCPv6 implementatie in OpenWRT gedaan heeft dat laatste stuk gelezen. Iedere request van OpenWRT (of LEDE, of commerciele meuk op basis van een van die twee, iig bij een paar TP-Link apparaten gespot) gaat gepaard met nieuwe DUID-LLT met de timestamp van dat moment

Nu, als m'n filters gewoon werkten (of ik daadwerkelijk reageerde op de Solicits) zouden de clients niet spammen met Solicits, maar is het nou echt zo moeilijk om de RFC te volgen...?

[Maurits van Baerle]

dion_b schreef op dinsdag 5 december 2017 @ 12:19:

Uhuh. Nou, blijkbaar heeft niemand die de DHCPv6 implementatie in OpenWRT gedaan heeft dat laatste stuk gelezen. Iedere request van OpenWRT (of LEDE, of commerciele meuk op basis van een van die twee, iig bij een paar TP-Link apparaten gespot) gaat gepaard met nieuwe DUID-LLT met de timestamp van dat moment

LEDE developers kennende zullen ze zich dat zeker aantrekken. Misschien even een bugje inschieten in hun bug tracker? https://lede-project.org/bugs

[dion_b]

Maurits van Baerle schreef op dinsdag 5 december 2017 @ 12:30:
[...]

LEDE developers kennende zullen ze zich dat zeker aantrekken. Misschien even een bugje inschieten in hun bug tracker? https://lede-project.org/bugs

Moet even een duidelijke packet capture regelen en een account daaro. Ik doe genoeg met LEDE dat het hoog tijd wordt iets terug te geven - al is het maar een bugmelding

[anboni]

anboni schreef op maandag 4 december 2017 @ 17:55:
Mag ik even gebruik maken van de collectieve kennis hier om na te gaan of ik nou gek aan het worden ben?

Om maar even mezelf te quoten: Nee, ik ben inderdaad niet gek geworden. Configuratie aan mijn kant was prima in orde, provider was "vergeten" een route vanaf de CPE naar binnen toe in te stellen (mijn eerste vermoeden dus) en daarnaast hadden ze in hun netwerk alleen maar x:y:z::/64 naar onze CPE gerouteerd ipv de volledige /48. Inmiddels dus werkende IPv6 connectivity!

[Snow_King]

Een kleine cross-post deze kant op: Snow_King in "Vrije router keuze - hulp van je provider obv besluit ACM"

Mag een ISP straks nog wel IPv6 niet leveren als ik het wél kan krijgen met een modem/router van hen?

[Dreamvoid]

Snow_King schreef op vrijdag 8 december 2017 @ 10:06:
Mag een ISP straks nog wel IPv6 niet leveren als ik het wél kan krijgen met een modem/router van hen?

Als er een gegronde reden voor is (teveel 3rd party routers doen IPv6 verkeerd) dan lijkt me dat ze wel een case hebben.

[Snow_King]

Dreamvoid schreef op vrijdag 8 december 2017 @ 11:53:
[...]

Als er een gegronde reden voor is (teveel 3rd party routers doen IPv6 verkeerd) dan lijkt me dat ze wel een case hebben.

Nou, het gaat mij om een verplichting. Ik heb het al eerder aan gehaald, maar wanneer komt het punt dat je mag zeggen dat je internet niet werkt als IPv6 het niet doet?

Want als een ISP ineens je IPv4 weg haalt en je IPv6 aan laat staan gaan heel veel mensen schreeuwen: "het is down".

Maar wat is de definitie van "down" dan? IPv4?

IPv6 wordt steeds maar als gimmick gezien, als iets extra's, een leuk dingetje er bij, etc. Ik wil gewoon IPv4/IPv6 op mijn verbinding zonder extra vragen.

Als één van de twee niet werkt is mijn verbinding down.

[Dreamvoid]

Dat punt komt als cruciale delen van het internet IPv6-only worden.

[anboni]

Snow_King schreef op vrijdag 8 december 2017 @ 11:59:
[...]
Als één van de twee niet werkt is mijn verbinding down.

De realiteit is dat alles vooralsnog prima werkt op een IPv4-only verbinding (en heel veel waarschijnlijk niet op een IPv6-only). Wij als techneuten hechten belang aan IPv6, maar ik denk niet dat je juridisch veel kans maakt om een ISP aan te spreken op het niet beschikbaar stellen ervan.

[Snow_King]

Dreamvoid schreef op vrijdag 8 december 2017 @ 12:28:
Dat punt komt als cruciale delen van het internet IPv6-only worden.

Wie stelt dat dan? Het gaat om het feit 'wat is internet'.

Ik heb heel wat IPv6-only systemen draaien. Waarom? Tekort aan IPv4, noodzaak en technische hobby.

Dat eerste stuk is echter wel degelijk een groot probleem. Ik heb als ISP gewoon bijna geen IPv4 meer. Daarom draai ik uit noodzaak IPv6-only systemen.

Als ik die niet kan bereiken is mijn internet "down".

anboni schreef op vrijdag 8 december 2017 @ 12:34:
[...]


De realiteit is dat alles vooralsnog prima werkt op een IPv4-only verbinding (en heel veel waarschijnlijk niet op een IPv6-only). Wij als techneuten hechten belang aan IPv6, maar ik denk niet dat je juridisch veel kans maakt om een ISP aan te spreken op het niet beschikbaar stellen ervan.

Wat ik hier boven zeg

"Alles" is niet mijn systemen. Achter CGNAT zitten van een ISP is anders dan IPv6.

We zouden er juist voor moeten strijden dat IPv6 een onderdeel van de definitie "internet" wordt.

Als een ISP het levert dan moet het ook echt een onderdeel zijn

De overheid én EU onderkennen dit in veel van de aanbestedingen al, maar ISP's doen maar niets.

[Dreamvoid]

Ik snap je positie als IPv6 supporter, maar de dagelijkse praktijk kan 99.9% van de bevolking op het moment prima zonder IPv6. In de toekomst niet meer, en tegen die tijd zal het ook voor de ISP's wel een vereiste worden om het aan te bieden.

[Verwijderd]

Een ISP is sowieso alleen gehouden datgene te leveren wat ze in hun marketing noemen en (specifiek) beschrijven in hun algemene voorwaarden. Iedere ISP heeft in hun voorwaarden staan dat ze niet (kunnen) garanderen dat alle websites via hun verbinding bereikbaar zijn. Als je gaat klagen dat ipv6-only sites niet te bereiken zijn zullen ze zich daar zonder twijfel op beroepen.

Kijk, als je nu een ipv6-only verbinding levert dan werken verreweg de meeste websites niet, dan kun je bij een rechter best beargumenteren dat het product niet is zoals geadverteerd. Maar dat geldt niet als een paar grote websites ipv6-only zouden worden. Mochten we ooit op het punt komen dat - laten we zeggen - driekwart van het internet ipv6-only is dan heb je een punt, maar tot het zo ver is heb je geen poot om op te staan. Ook niet als google ipv6-only zou worden.

Het zou misschien leuk zijn als het anders was, en je kunt natuurlijk proberen om een of ander obscuur wetsartikel te vinden en e.e.a. helemaal in je eigen voordeel te beredeneren, maar een rechter zal daar nooit in meegaan. Zolang een ISP zichzelf niet verplicht om ipv6 aan te bieden kun jij dat ook niet afdwingen.

[Harrie666]

Verwijderd schreef op vrijdag 8 december 2017 @ 21:58:
.......
Mochten we ooit op het punt komen dat - laten we zeggen - driekwart van het internet ipv6-only is dan heb je een punt, maar tot het zo ver is heb je geen poot om op te staan. Ook niet als google ipv6-only zou worden.

Als Google, Facebook en Microsoft IPv6 only zouden worden dan denk dat ik 95%+ van de gemiddelde gebruiker in Nederland heel hard zou gaan klagen omdat ie betaald voor internet maar er eigenlijk niks mee kan. Tuurlijk gaan ze dat niet doen omdat dan meteen ook de klanten die diverse diensten afnemen ook niet meer bereikbaar zijn maar dan zou de bal ineens wel eens heel erg snel kunnen gaan rollen

[Snow_King]

Harrie666 schreef op maandag 11 december 2017 @ 10:50:
[...]


Als Google, Facebook en Microsoft IPv6 only zouden worden dan denk dat ik 95%+ van de gemiddelde gebruiker in Nederland heel hard zou gaan klagen omdat ie betaald voor internet maar er eigenlijk niks mee kan. Tuurlijk gaan ze dat niet doen omdat dan meteen ook de klanten die diverse diensten afnemen ook niet meer bereikbaar zijn maar dan zou de bal ineens wel eens heel erg snel kunnen gaan rollen

Alleen het gerucht al dat een website die óók IPv6 heeft hoger in de Google ranking komt zou al voldoende zijn.

Google schijnt dit te doen met SSL, dus als ze hun macht daarvoor óók zouden in zetten bij IPv6 gaat het ineens een stuk harder.

Maar ik blijf er bij: Pornhub of iets dergelijks moet zijn content gewoon een Ultra Full HD 4k met alles er op en der aan gratis aanbieden over IPv6 en tunnels blokkeren. Dan gaan mensen héél hard zeuren bij hun ISP.

[Freee!!]

Snow_King schreef op maandag 11 december 2017 @ 11:12:
[...]
Alleen het gerucht al dat een website die óók IPv6 heeft hoger in de Google ranking komt zou al voldoende zijn.

Google schijnt dit te doen met SSL, dus als ze hun macht daarvoor óók zouden in zetten bij IPv6 gaat het ineens een stuk harder.

Maar ik blijf er bij: Pornhub of iets dergelijks moet zijn content gewoon een Ultra Full HD 4k met alles er op en der aan gratis aanbieden over IPv6 en tunnels blokkeren. Dan gaan mensen héél hard zeuren bij hun ISP.

+2
+1 voor Google en +1 voor Porn (daarmee werd de videomarkt uiteindelijk bepaald).

[Roetzen]

Snow_King schreef op maandag 11 december 2017 @ 11:12:
Maar ik blijf er bij: Pornhub of iets dergelijks moet zijn content gewoon een Ultra Full HD 4k met alles er op en der aan gratis aanbieden over IPv6 en tunnels blokkeren. Dan gaan mensen héél hard zeuren bij hun ISP.

Klagen bij de ISP zou in mijn geval huilen tegen de verkeerde boom zijn. Ik moet gaan klagen bij Samsung. Mijn half jaar oude Samsung 102 cm 4K TV heeft nog steeds alleen IPv4. Ik ben vast niet de enige met een IPv4 only smart TV

[iMars]

Ik ben nieuw met IPv6, maar ben al spelenderwijs aan het leren Ik heb een tunnel geregistreerd bij Hurricane en de example config in mijn router (MikroTik) geladen:

code:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=94.x.x.x mtu=1280 name=sit1 remote-address=216.66.84.46
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:1f14:f31::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:1f14:f31::2/64 advertise=no disabled=no eui-64=no interface=sit1

Ik heb in dit topic naar MikroTik gezocht om te zien wat anderen hebben Het grote IPv6 topic maar ik kom er nog niet echt uit.

Moet ik nog een dhcp (stateful of stateless) configureren om het werkend te krijgen? Of moet het gelijk werken? Als ik met een browser naar ipv6test.google.com ga, krijg ik de melding dat ik geen IPv6 heb, maar geen problemen mag ondervinden op websites met IPv6-ondersteuning.

Ik heb een Ziggo modem in Bridge staan met mijn MikroTik.

Edit: verder zoeken dan alleen Tweakers https://wiki.mikrotik.com...l_Broker_Example_for_Home

Edit 2:
Prima pagina! Duidelijk

Snow_King schreef op maandag 11 december 2017 @ 11:12:
[...]

Alleen het gerucht al dat een website die óók IPv6 heeft hoger in de Google ranking komt zou al voldoende zijn.

Google schijnt dit te doen met SSL, dus als ze hun macht daarvoor óók zouden in zetten bij IPv6 gaat het ineens een stuk harder.

Maar ik blijf er bij: Pornhub of iets dergelijks moet zijn content gewoon een Ultra Full HD 4k met alles er op en der aan gratis aanbieden over IPv6 en tunnels blokkeren. Dan gaan mensen héél hard zeuren bij hun ISP.

Op zo'n manier had VHS het ook van Betamax gewonnen

[ Voor 31% gewijzigd door iMars op 15-12-2017 11:37 ]

[Zaffo]

@iMars Mooi! Heb je ook een IPv6 firewall? En deel je de "interne" adresses stateless of statefull uit?

Kan je je ipv6 config delen? Ik ben benieuwd hoe die afwijkt van mijn hier eerder geposte config.