Het grote IPv6 topic

[Nakebod]

Zou het toeval zijn, of zijn de eerste Ziggo gebruikers goed voor een nieuwe piek van 40.7 Gbps afgelopen maandag, en gister ook ergens in de 36 Gbps.
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic
Hoewel er wel vaker hogere pieken zijn, maar 30 Gbps op de AMS-IX is zo te zien meer de standaard.

Google IPv6 Stats: 2.23% (Was 2.18% op 10 maart)

[Verwijderd]

Nakebod schreef op woensdag 08 april 2015 @ 09:15:
Zou het toeval zijn, of zijn de eerste Ziggo gebruikers goed voor een nieuwe piek van 40.7 Gbps afgelopen maandag, en gister ook ergens in de 36 Gbps.
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic
Hoewel er wel vaker hogere pieken zijn, maar 30 Gbps op de AMS-IX is zo te zien meer de standaard.

Google IPv6 Stats: 2.23% (Was 2.18% op 10 maart)

Vorige maand hebben we meerdere pieken gehad boven de 50Gbps en gemiddelden boven de 40 in de avonden. Het loopt zelfs een beetje terug vrees is.

https://www.vyncke.org/ip...enetration.php?country=nl

[ Voor 5% gewijzigd door Verwijderd op 08-04-2015 09:39 ]

[Dennis]

Heren, dank voor jullie IPv6 adviezen.

Vooralsnog heeft mijn provider voor alle thuislocaties nog geen IPv6 beschikbaar, dus ik heb nog geen global adresses. SPOF voor de Cloud is er natuurlijk theoretisch, maar ik heb daar juist in geïnvesteerd zodat ik geen problemen meer heb met gewijzigde IP-adressen etc. en daarom verwacht ik daar ook eigenlijk geen problemen mee.

Misschien goed om aan te vangen met een ULA op alle locaties, omdat nu alleen de cloud een /64 heeft. Op termijn kan ik dan op alle sites een global range toevoegen en theoretisch kan ik dan de ULA uitschakelen als overal IPv6 is. Blijft alleen nog het VPN-probleem over, want versleuteld dataverkeer onderling is voor mij toch een must.

[CAPSLOCK2000]

Je kan ook zelf voor lokale adressen zorgen via een tunnel van bv SiXXS of Hurricane Electric, al levert dat wel een minder mooi netwerkontwerp op.
IPv6 kan ook via je VPN lopen maar je zou ook kunnen overwegen om ipsec te gebruiken om je verkeer te encrypten.

[databeestje]

Dennis schreef op woensdag 08 april 2015 @ 10:22:
Heren, dank voor jullie IPv6 adviezen.

Vooralsnog heeft mijn provider voor alle thuislocaties nog geen IPv6 beschikbaar, dus ik heb nog geen global adresses. SPOF voor de Cloud is er natuurlijk theoretisch, maar ik heb daar juist in geïnvesteerd zodat ik geen problemen meer heb met gewijzigde IP-adressen etc. en daarom verwacht ik daar ook eigenlijk geen problemen mee.

Misschien goed om aan te vangen met een ULA op alle locaties, omdat nu alleen de cloud een /64 heeft. Op termijn kan ik dan op alle sites een global range toevoegen en theoretisch kan ik dan de ULA uitschakelen als overal IPv6 is. Blijft alleen nog het VPN-probleem over, want versleuteld dataverkeer onderling is voor mij toch een must.

HE.net tunnel aanvragen en termineren in de Colo, vervolgens subnetjes uitdelen aan de VPN netwerken. Waarom niet?

[Hipska]

databeestje schreef op woensdag 08 april 2015 @ 11:07:
[...]

HE.net tunnel aanvragen en termineren in de Colo, vervolgens subnetjes uitdelen aan de VPN netwerken. Waarom niet?

Lijkt me toch minder mooi, aangezien de Colo zelf al IPv6 heeft..

[Ximon]

Hipska schreef op woensdag 08 april 2015 @ 11:27:
[...]

Lijkt me toch minder mooi, aangezien de Colo zelf al IPv6 heeft..

databeestje schreef op woensdag 08 april 2015 @ 11:07:
[...]

HE.net tunnel aanvragen en termineren in de Colo, vervolgens subnetjes uitdelen aan de VPN netwerken. Waarom niet?

Misschien te kort door de bocht, maar zou RFC4891 kunnen helpen? Als je een VPN tunnel naar de colo hebt kan daar ook IPv6 overheen lijkt me

[Dennis]

Krijg je dan niet vage routing, omdat ik alleen maar een /64 heb van de Colo? Als ik het goed heb begrepen is dat geen ontwerp zoals het bedoeld is.

[OruBLMsFrl]

Ik heb een extra /48 range naar een colo laten routeren voor een eenmalig bedrag bij gebrek aan native ipv6, daarbinnen gesubnet. Werkt prima. Firewall scripts met variabelen opgezet voor eenvoudig aanpassen als de publieke range ooit wijzigt.

[Verwijderd]

Dennis schreef op woensdag 08 april 2015 @ 11:48:
Krijg je dan niet vage routing, omdat ik alleen maar een /64 heb van de Colo? Als ik het goed heb begrepen is dat geen ontwerp zoals het bedoeld is.

Ik heb vanuit een datacenter jarenlang diverse kantoren die alleen IPv4 hadden IPv6 connectiviteit gegeven. Kregen gewoon een subnet uit de range van het datacenter en werden via 6over4 door de VPN getunneld.

Waar je wel rekening mee moet houden is dat IPv6 verkeer op de locaties dus via je datacenter verbinding loopt, afhankelijk van je contract -fixed bandbreedte / volume- kan dit fors oplopen als thuis locaties een IPv6 adres krijgen en dus youtube over v6 doen, wat dus niet vanuit de thuislocatie het internet op gaat maar vanuit het datacenter.

[databeestje]

Dennis schreef op woensdag 08 april 2015 @ 11:48:
Krijg je dan niet vage routing, omdat ik alleen maar een /64 heb van de Colo? Als ik het goed heb begrepen is dat geen ontwerp zoals het bedoeld is.

Je zal hoe dan ook een groter subnet nodig hebben voor de meerdere sites, volgens de RIPE is het een /48 per site, maar voor deze toepassing is een /48 een goede keuze denk ik.

Aangezien je dan een publieke prefix hebt kan je in ieder geval zonder problemen hier ook mee het internet op, dat is altijd een plus punt. Liever een Global adres /48 reserveren voor dit doeleind en firewallen dan een /48 ULA die nergens heen kan. De diensten verschuiven steeds meer richting het internet in de toekomst, als je deze door gebrek aan NAT niet kan bereiken heb je jezelf in de hoek geverfd.

Meerdere adressen wil je eigenlijk niet onderhouden, IP4 en IP6 is al genoeg, om dan ook nog 2 IP6 ranges te hanteren is een ongeluk in de maak.

Een /48 van HE.net/Sixxs6 is portable tussen verschillende Co-locaties als je het tunnel endpunt verhuist.
Een /48 van de VPS provider heeft geen MTU impact, maar irrelevant als je al IPsec/OpenVPN tunnels gebruikt.

[Ximon]

Dennis schreef op woensdag 08 april 2015 @ 11:48:
Krijg je dan niet vage routing, omdat ik alleen maar een /64 heb van de Colo? Als ik het goed heb begrepen is dat geen ontwerp zoals het bedoeld is.

Om even mijn eigen fout te corrigeren: het is inderdaad niet de bedoeling om een /64 verder te gaan subnetten. Zoals hierboven wordt aangegeven zou je een extra prefix die wel gesubnet kan worden kunnen gebruiken.

[Dennis]

Verwijderd schreef op woensdag 08 april 2015 @ 11:56:
Ik heb vanuit een datacenter jarenlang diverse kantoren die alleen IPv4 hadden IPv6 connectiviteit gegeven. Kregen gewoon een subnet uit de range van het datacenter en werden via 6over4 door de VPN getunneld.

Waar je wel rekening mee moet houden is dat IPv6 verkeer op de locaties dus via je datacenter verbinding loopt, afhankelijk van je contract -fixed bandbreedte / volume- kan dit fors oplopen als thuis locaties een IPv6 adres krijgen en dus youtube over v6 doen, wat dus niet vanuit de thuislocatie het internet op gaat maar vanuit het datacenter.

Yep, hetzelfde als Bas ook al schrijft. Dat laatste is natuurlijk wel een punt. Niet alleen gaat het om mijn eigen dataverkeer, maar ook dat van mijn familie. Ik kan natuurlijk wel IPv4 preferencen boven IPv6 indien er keuze is, maar vraag me af wat dan de toevoeging is.

databeestje schreef op woensdag 08 april 2015 @ 11:59:
Je zal hoe dan ook een groter subnet nodig hebben voor de meerdere sites, volgens de RIPE is het een /48 per site, maar voor deze toepassing is een /48 een goede keuze denk ik.

Ja, een /48 totaal kan ik een /56 per fysieke site maken en dan /64 voor netwerken die ik nu per netwerk (bij mij ook meteen VLAN) gescheiden heb.

Meerdere adressen wil je eigenlijk niet onderhouden, IP4 en IP6 is al genoeg, om dan ook nog 2 IP6 ranges te hanteren is een ongeluk in de maak.

True, dit is de beste oplossing.

Een /48 van HE.net/Sixxs6 is portable tussen verschillende Co-locaties als je het tunnel endpunt verhuist.
Een /48 van de VPS provider heeft geen MTU impact, maar irrelevant als je al IPsec/OpenVPN tunnels gebruikt.

Maar dan heb je het dus over een 6-over-4 tunnel, toch? Dat is anders dan wat Bas beschreef: tegen meerprijs de Colo gewoon de routers mijn /48 laten routeren.

[databeestje]

Dennis schreef op woensdag 08 april 2015 @ 12:29:
Maar dan heb je het dus over een 6-over-4 tunnel, toch? Dat is anders dan wat Bas beschreef: tegen meerprijs de Colo gewoon de routers mijn /48 laten routeren.

Het enige /48 netblok dat de Colo gaat routeren is uit hun eigen adres blok. Tenzij je een PI space hebt is het gebonden aan de Colo provider. Als je een netblokje bij Sixxs6 of HE.net registreert kan deze alleen maar via 6in4 gerouteerd worden.

Je hebt wel enige keuze waar je deze tunnel termineert uiteraard, via 6 over 4 kan je deze op de server/firewall in de Colo termineren, de netwerken kan je daarna uiteraard rechtstreeks toewijzen aan de Vlans of IPsec tunnels. Deze kunnen dan ook probleemloos met het IPv6 adres van de server praten omdat het op dat moment dan het enige pad. Eventueel nog een statische route toevoegen zodat je zeker weet dat het verkeer via het juiste pad gaat ook als de client al dual stack heeft.

Geen idee wat voor VPN je gebruikt, als dit layer2 VLANs is of IPsec/OpenVPN. Zowel IPsec als OpenVPN in transport mode zouden prima dual stack moeten kunnen.

[Maurits van Baerle]

Nakebod schreef op woensdag 08 april 2015 @ 09:15:
Zou het toeval zijn, of zijn de eerste Ziggo gebruikers goed voor een nieuwe piek van 40.7 Gbps afgelopen maandag, en gister ook ergens in de 36 Gbps.
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic
Hoewel er wel vaker hogere pieken zijn, maar 30 Gbps op de AMS-IX is zo te zien meer de standaard.

Google IPv6 Stats: 2.23% (Was 2.18% op 10 maart)

Verwijderd schreef op woensdag 08 april 2015 @ 09:26:
Vorige maand hebben we meerdere pieken gehad boven de 50Gbps en gemiddelden boven de 40 in de avonden. Het loopt zelfs een beetje terug vrees is.

https://www.vyncke.org/ip...enetration.php?country=nl

Ik denk dat het nog te vroeg is om hier resultaten van de Ziggo uitrol te verwachten. We hebben het over een paar duizend aansluitingen. Ik denk dat je pas vanaf enkele tienduizenden aansluitingen echt iets kan gaan zien.

[OruBLMsFrl]

Ik heb een sit tunnel opgezet van dd-wrt naar een debian vm. Die kan tientallen van dat soort privé netwerken voorzien van /56 of /64. Wel oppassen met dataverkeer inderdaad. Haal zoiets 60Mbps over ipv6 ipv de 200Mbps over ipv4. Staat ook als v4 prio boven v6. Kun je wel al firewall e.d. testen, wat ipv6 only test sites, dns resolving checken. Toch liever een native ipv6 range dus hier.

[CyBeR]

Dennis schreef op dinsdag 07 april 2015 @ 23:15:
Vraagje voor de kenners hier. Op mijn (nu) IPv4 netwerk wil ik ook maar eens IPv6 "implementeren". De vraag is dan hoe ik dat ga doen met adressering. Het gaat om een thuissituatie.

Ik heb al het een en ander gelezen over dual-adressing, over network prefix translation en over /56 en /64.

Nu met IPv4 heb ik vier sites. Eén is een VPS (cloud) en de andere drie netwerken zijn thuisnetwerken. Deze drie thuisnetwerken verbinden (OpenVPN) allemaal met de cloud en zo is alles routable. Binnen een netwerk zijn meerdere VLANs om securityredenen. In de cloud staat PfSense, alle thuisnetwerken draaien op OpenWRT. Alles direct aan internet (of achter een bridged modem).

Nu leek mij het meest handig om een ULA /48 te pakken en voor elke VLAN een /64 uit te geven. Dit is dan de "lokale" layer die (via OpenVPN) volledig routable is en waarbij firewall rules redelijk open zijn. De /64 (of hopelijk /56) die dan van de provider komt kan daarbij komen. Hiervoor gelden meer strict firewall rules.

Ik las eerder in dit topic reacties over dat dit lastig onderhoudbaar is, maar is dat echt zo'n probleem? Daarnaast voorkom ik problemen met DHCPv6 allocering door providers waardoor firewall rules aangepast moeten worden. Enige echt probleem dat ik zag is dat sommige devices niet meerdere IP-adressen ondersteunen (zoals printers) en ik moet nog even kijken hoe het geheel geconfigureerd kan worden.

Hoor graag jullie reacties en adviezen als dat mag .

Zorg dat je bij elke site v6-connectivity hebt (al dan niet met tunnels) en dan kun je gewoon over 't internet praten zonder site-site tunnels. Eventueel kun je IPSec inzetten om je verkeer tussen je sites te encrypten.

[Snow_King]

CyBeR schreef op donderdag 09 april 2015 @ 01:25:
[...]


Zorg dat je bij elke site v6-connectivity hebt (al dan niet met tunnels) en dan kun je gewoon over 't internet praten zonder site-site tunnels. Eventueel kun je IPSec inzetten om je verkeer tussen je sites te encrypten.

Echt, allen, stop met denken aan Site-to-Site tunnels. Laat het internet de routeringen voor je doen. Pas gewoon firewall policies toe waar nodig en gebruik eventueel nog IPSec.

Verder maakt SSH en HTTPS de boel al gewoon veilig, dus waarom driedubbel inpakken en je MTU compleet verknallen?

Met IPv6 helemaal stoppen met denken in private networks. Het internet is je grote private network! Firewalls doen verder de rest afschermen.

[Dennis]

databeestje schreef op woensdag 08 april 2015 @ 14:00:
Geen idee wat voor VPN je gebruikt, als dit layer2 VLANs is of IPsec/OpenVPN. Zowel IPsec als OpenVPN in transport mode zouden prima dual stack moeten kunnen.

Ik gebruik voor alles OpenVPN.

Het idee van IPSec is nieuw voor mij, interessant. Ik heb al gekeken, dat zou dan met Strongswan in OpenWRT kunnen. Het onderwerp is wel redelijk nieuw, dus moet nog even kijken of ik hier eventueel zelf uit kom. Maar interessant is het zeker!

Snow_King schreef op donderdag 09 april 2015 @ 08:54:
Echt, allen, stop met denken aan Site-to-Site tunnels. Laat het internet de routeringen voor je doen. Pas gewoon firewall policies toe waar nodig en gebruik eventueel nog IPSec.

[...]

Met IPv6 helemaal stoppen met denken in private networks. Het internet is je grote private network! Firewalls doen verder de rest afschermen.

Dit is een helder advies!

[eymey]

Snow_King schreef op donderdag 09 april 2015 @ 08:54:
[...]




Echt, allen, stop met denken aan Site-to-Site tunnels. Laat het internet de routeringen voor je doen. Pas gewoon firewall policies toe waar nodig en gebruik eventueel nog IPSec.

Verder maakt SSH en HTTPS de boel al gewoon veilig, dus waarom driedubbel inpakken en je MTU compleet verknallen?

Met IPv6 helemaal stoppen met denken in private networks. Het internet is je grote private network! Firewalls doen verder de rest afschermen.

Op zich is wat je adviseert uiteindelijk de bedoeling in de "IPV6 wereld".

Helaas ontkom je voorlopig gewoon nog niet aan site to site tunnels. Div. ISP's gebruiken op dit moment nog deployment situaties zoals 6RD. En daar verandert je IPV6 prefix gewoon net zo hard als je IPV4 adres. Een hel als je met firewall regels moet werken.

En tunnelbrokers zoals he.net en SixXS introduceren weer hun eigen MTU problemen en bieden toch meestal ook niet de snelheid die je native van je ISP krijgt.

[CyBeR]

Mja, je kunt ook prima nog een site-to-site tunnel ernaast opzetten. Kwestie van er ook een routing protocol overheen draaien. Maar imo ben je dan nutteloze extra moeite aan het doen. Zo vaak veranderen je prefixen nou ook weer niet, zelfs als ze dynamisch van je isp zijn. Als je v4-adres verandert moet je ook je tunnel config aanpassen, da's niet echt anders.

[Verwijderd]

CyBeR schreef op donderdag 09 april 2015 @ 09:57:
Mja, je kunt ook prima nog een site-to-site tunnel ernaast opzetten. Kwestie van er ook een routing protocol overheen draaien. Maar imo ben je dan nutteloze extra moeite aan het doen. Zo vaak veranderen je prefixen nou ook weer niet, zelfs als ze dynamisch van je isp zijn. Als je v4-adres verandert moet je ook je tunnel config aanpassen, da's niet echt anders.

Eens, wat natuurlijk ook een punt is wat niet vergeten moet worden is dat je wel kunt beginnen om er omheen te werken maar je zeker ook bij je leverancier aan de bel moet trekken dat je er last van hebt, als je dit kan overbrengen wat de problemen en gevolgen zijn dan wordt er mogelijk wat aan gedaan.

Misschien willen ze in jouw (algemeen, ik bedoel niet CyBeR) geval als quick fix wel een reserveration aanmaken in DHCPv6.

[databeestje]

eymey schreef op donderdag 09 april 2015 @ 09:52:
[...]


Op zich is wat je adviseert uiteindelijk de bedoeling in de "IPV6 wereld".

Helaas ontkom je voorlopig gewoon nog niet aan site to site tunnels. Div. ISP's gebruiken op dit moment nog deployment situaties zoals 6RD. En daar verandert je IPV6 prefix gewoon net zo hard als je IPV4 adres. Een hel als je met firewall regels moet werken.

En tunnelbrokers zoals he.net en SixXS introduceren weer hun eigen MTU problemen en bieden toch meestal ook niet de snelheid die je native van je ISP krijgt.

Hangt er ook vanaf hoe je het inzet.

Als je de prefix gebruikt voor VPN doeleinden en niet zozeer voor internet toegang is dat niet noodzakelijk een probleem.

[Snow_King]

eymey schreef op donderdag 09 april 2015 @ 09:52:
[...]


Op zich is wat je adviseert uiteindelijk de bedoeling in de "IPV6 wereld".

Helaas ontkom je voorlopig gewoon nog niet aan site to site tunnels. Div. ISP's gebruiken op dit moment nog deployment situaties zoals 6RD. En daar verandert je IPV6 prefix gewoon net zo hard als je IPV4 adres. Een hel als je met firewall regels moet werken.

En tunnelbrokers zoals he.net en SixXS introduceren weer hun eigen MTU problemen en bieden toch meestal ook niet de snelheid die je native van je ISP krijgt.

Duidelijk, maar mijn grote angst is dat mensen een Copy-Paste doen van hun IPv4 situatie omdat "ze het nou eenmaal zo kennen".

Vervolgens gaan we allemaal halfbakken IPv6 implementaties overal zien met rare constructies waar de rillingen van over mijn rug lopen.

Ik heb overigens jaren Sixxs gehad en nooit een prefix wijziging gezien.

[CyBeR]

Prefixes bij SixXS zijn ook static inderdaad, 't zit 'm meer in de Ziggo's van de wereld die erop staan om dynamische adressen uit te delen. Dat is voor IPv4 al raar (gezien dat de meeste verbindingen always-on zijn tegenwoordig en je er dus niet zoveel mee wint) en voor IPv6 al helemaal.

[Maasluip]

Ik bij XS4ALL ook al een nieuwe prefix gekregen. Van ADSL naar glas betekent nieuwe prefix.

[CyBeR]

Maasluip schreef op donderdag 09 april 2015 @ 10:23:
Ik bij XS4ALL ook al een nieuwe prefix gekregen. Van ADSL naar glas betekent nieuwe prefix.

Dat is, routeringstechnisch, logisch; je krijgt dan ook een nieuw IPv4 IP. Maar wat ze moeten regelen is dat als er verder niks wijzigt (dus je verhuist niet en verandert ook niet van dienst), je prefix statisch blijft.

[ Voor 4% gewijzigd door CyBeR op 09-04-2015 10:25 ]

[eymey]

Snow_King schreef op donderdag 09 april 2015 @ 10:20:
[...]

Duidelijk, maar mijn grote angst is dat mensen een Copy-Paste doen van hun IPv4 situatie omdat "ze het nou eenmaal zo kennen".

Vervolgens gaan we allemaal halfbakken IPv6 implementaties overal zien met rare constructies waar de rillingen van over mijn rug lopen.

Ik heb overigens jaren Sixxs gehad en nooit een prefix wijziging gezien.

Ik moet eerlijk toegeven dat, als ik echt serieus met IPV6 zou gaan beginnen, ik het aanvankelijk ook op die manier zou doen . Maar ik zou er wel naar streven om het zo veel mogelijk meteen op de 'bedoelde' manier te doen.

Overigens... ik beweer ook niet dat Sixxs een prefix wijziging doet. Maar ISP's die met 6rd werken, doen dat wel massaal (bv. alle glasvezel ISP's die KPN ITNS gebruiken voor de internettoegang).

[ Voor 6% gewijzigd door eymey op 09-04-2015 10:31 ]

[eymey]

CyBeR schreef op donderdag 09 april 2015 @ 09:57:
Mja, je kunt ook prima nog een site-to-site tunnel ernaast opzetten. Kwestie van er ook een routing protocol overheen draaien. Maar imo ben je dan nutteloze extra moeite aan het doen. Zo vaak veranderen je prefixen nou ook weer niet, zelfs als ze dynamisch van je isp zijn. Als je v4-adres verandert moet je ook je tunnel config aanpassen, da's niet echt anders.

Ben ik niet helemaal met je eens .

Als de server-kant van mijn OpenVPN tunnels hetzelfde blijft, kan de client kant (thuislocaties) prima veranderen en wordt gewoon de tunnel opnieuw opgezet zonder tussenkomst van mijzelf.

Het wordt natuurlijk anders als je beide eindpunten statisch configureert

[CyBeR]

eymey schreef op donderdag 09 april 2015 @ 10:30:
[...]


Ben ik niet helemaal met je eens .

Als de server-kant van mijn OpenVPN tunnels hetzelfde blijft, kan de client kant (thuislocaties) prima veranderen en wordt gewoon de tunnel opnieuw opgezet zonder tussenkomst van mijzelf.

Dat is alleen geen site-to-site tunnel maar gewoon een hub-and-spokemodel.

[Verwijderd]

eymey schreef op donderdag 09 april 2015 @ 10:30:
[...]


Ben ik niet helemaal met je eens .

Als de server-kant van mijn OpenVPN tunnels hetzelfde blijft, kan de client kant (thuislocaties) prima veranderen en wordt gewoon de tunnel opnieuw opgezet zonder tussenkomst van mijzelf.

Het wordt natuurlijk anders als je beide eindpunten statisch configureert

Dat kan als je server-kant van alle IP adressen VPN accepteert, of van alle subnetten van de provider waar de thuislocaties in zitten.

Als je verkeer encrypted is (ssh / tls ) of dat je IPsec gebruikt, dan kun je in plaats van een VPN ook een source adres van je provider van de clients opgeven als extra security laag, waardoor bijvoorbeeld alleen clients (of ze nu wisselen van range of niet) van ziggo: 2001:0b88::/33 ssh naar de server-kant mogen.

[Dennis]

eymey schreef op donderdag 09 april 2015 @ 09:52:
Op zich is wat je adviseert uiteindelijk de bedoeling in de "IPV6 wereld".

Helaas ontkom je voorlopig gewoon nog niet aan site to site tunnels. Div. ISP's gebruiken op dit moment nog deployment situaties zoals 6RD. En daar verandert je IPV6 prefix gewoon net zo hard als je IPV4 adres. Een hel als je met firewall regels moet werken.

Hier ben ik het volmondig mee eens. Kijk, ik ga binnenkort op vakantie naar een ander land en ik wil gewoon kunnen internetten over een veilige verbinding, bijvoorbeeld als ik op een hotspot zit. Ik maak momenteel vanaf mijn telefoon verbinding naar mijn UPC IP-adres, maar ik zou het niet tof vinden als halverwege mijn vakantie mijn IP verandert en ik er geen gebruik meer van kan maken (en ja, recent is dat nog gebeurd vanwege werkzaamheden aan het UPC-netwerk). Met mijn nieuwe VPS is dat probleem verholpen, omdat de Colo een fixed IP geeft.

Met IPv6 geldt hetzelfde. Ik ben het dus eens dat het, totdat de providers ook IPv6 juist implementeren, in sommige situaties handiger is om met workaround de boel werkend te houden. Ik heb uiteindelijk ook geen zin om 24/7 de systeembeheerder uit te moeten hangen .

[Snow_King]

Dennis schreef op donderdag 09 april 2015 @ 10:43:
[...]


Hier ben ik het volmondig mee eens. Kijk, ik ga binnenkort op vakantie naar een ander land en ik wil gewoon kunnen internetten over een veilige verbinding, bijvoorbeeld als ik op een hotspot zit. Ik maak momenteel vanaf mijn telefoon verbinding naar mijn UPC IP-adres, maar ik zou het niet tof vinden als halverwege mijn vakantie mijn IP verandert en ik er geen gebruik meer van kan maken (en ja, recent is dat nog gebeurd vanwege werkzaamheden aan het UPC-netwerk). Met mijn nieuwe VPS is dat probleem verholpen, omdat de Colo een fixed IP geeft.

Met IPv6 geldt hetzelfde. Ik ben het dus eens dat het, totdat de providers ook IPv6 juist implementeren, in sommige situaties handiger is om met workaround de boel werkend te houden. Ik heb uiteindelijk ook geen zin om 24/7 de systeembeheerder uit te moeten hangen .

DDNS? Dat werkt prima voor zulke situaties!

eymey schreef op donderdag 09 april 2015 @ 10:27:
[...]


Ik moet eerlijk toegeven dat, als ik echt serieus met IPV6 zou gaan beginnen, ik het aanvankelijk ook op die manier zou doen . Maar ik zou er wel naar streven om het zo veel mogelijk meteen op de 'bedoelde' manier te doen.

Overigens... ik beweer ook niet dat Sixxs een prefix wijziging doet. Maar ISP's die met 6rd werken, doen dat wel massaal (bv. alle glasvezel ISP's die KPN ITNS gebruiken voor de internettoegang).

Hopelijk kan ik je er van weerhouden zulke zaken te implementeren. Ik heb het tijden gedaan met mijn Sixxs tunnel en ben nu érg blij met mijn statische IPv6 subnet.

Bij XS4All in 2 jaar nooit een nieuw IPv6 subnet gekregen en bij ZeelandNet in de afgelopen 7 maanden ook niet.

[eymey]

CyBeR schreef op donderdag 09 april 2015 @ 10:33:
[...]


Dat is alleen geen site-to-site tunnel maar gewoon een hub-and-spokemodel.

OK, akkoord (networking is niet mijn dagelijkse vak en zeker niet in grote netwerkomgevingefn met heel veel sites, meeste is hobbymatig met wel VPS en wat thuislokaties )

Verwijderd schreef op donderdag 09 april 2015 @ 10:35:
[...]


Dat kan als je server-kant van alle IP adressen VPN accepteert, of van alle subnetten van de provider waar de thuislocaties in zitten.

Als je verkeer encrypted is (ssh / tls ) of dat je IPsec gebruikt, dan kun je in plaats van een VPN ook een source adres van je provider van de clients opgeven als extra security laag, waardoor bijvoorbeeld alleen clients (of ze nu wisselen van range of niet) van ziggo: 2001:0b88::/33 ssh naar de server-kant mogen.

Dat is idd ook een optie

Dennis schreef op donderdag 09 april 2015 @ 10:43:
[...]


Hier ben ik het volmondig mee eens. Kijk, ik ga binnenkort op vakantie naar een ander land en ik wil gewoon kunnen internetten over een veilige verbinding, bijvoorbeeld als ik op een hotspot zit. Ik maak momenteel vanaf mijn telefoon verbinding naar mijn UPC IP-adres, maar ik zou het niet tof vinden als halverwege mijn vakantie mijn IP verandert en ik er geen gebruik meer van kan maken (en ja, recent is dat nog gebeurd vanwege werkzaamheden aan het UPC-netwerk). Met mijn nieuwe VPS is dat probleem verholpen, omdat de Colo een fixed IP geeft.

Met IPv6 geldt hetzelfde. Ik ben het dus eens dat het, totdat de providers ook IPv6 juist implementeren, in sommige situaties handiger is om met workaround de boel werkend te houden. Ik heb uiteindelijk ook geen zin om 24/7 de systeembeheerder uit te moeten hangen .

Mja, op vakantie zijn, op vreemde netwerken zitten, etc. is natuurlijk ook wel weer een ander verhaal dan met (statische site-to-site verbindingen (afgezien van evt dynamische endpoints ) die beveiligd moeten zijn. In zulke situaties ontkom je denk ik nog steeds niet aan een VPN tunnel. Tenzij die lokaties ook volledig en correct ipv6 draaien, maar dan zul je dus nog wel voor je encryptie moeten zorgen .

Snow_King schreef op donderdag 09 april 2015 @ 11:06:

[...]
Hopelijk kan ik je er van weerhouden zulke zaken te implementeren. Ik heb het tijden gedaan met mijn Sixxs tunnel en ben nu érg blij met mijn statische IPv6 subnet.

Bij XS4All in 2 jaar nooit een nieuw IPv6 subnet gekregen en bij ZeelandNet in de afgelopen 7 maanden ook niet.

Mja, connecties met XS4ALL verlopen (voor zo ver ik weet) ook nog steeds via PPP. Waarbij alle IP assignment dus eigenlijk op 1 (of hooguit een paar) locatie(s) gebeurt. Dus ik verwacht inderdaad dat er daar zelden of nooit een reden zal zijn om IP-adressen te veranderen. En sowieso werkt xs4all met native ipv6 en zou een herverdeling, zelfs al deden ze regio-verdeelde IP-blokken, voor ipv6 nooit meer nodig moeten zijn. Nadeel van glas / KPN ITNS blijft dat daar alles per regio verdeeld is (en met DHCP relays wordt uitgegeven). En dat bij uitbreiding dus nog wel eens opnieuw verdeeld moet worden. En bij 6rd is een deel van je prefix eenmaal verbonden met je IPV4 adres.

Maar het ligt wel in lijn der verwachting (of iig hoop) dat providers bij de uitrol van native IPV6 dit nooit meer hoeven of willen doen

[Verwijderd]

Een andere optie kan nog zijn om een KvK registratie te doen en dan de abonnementen zakelijk af te nemen, dan heb je vaak wel statische adressen met garantie. Qua prijs maakt het elkaar vaak niet uit.

[ik222]

Bij 6rd is je IPv6 prefix inderdaad net zo statisch als je IPv4 adres. In mijn geval is dat prima omdat ik een statisch IPv4 adres heb en daarmee heb ik dus ook een statische /56 IPv6 prefix.

Probleem met de 'bedoelde' implementaties van IPv6 is gewoon dat het heel sterk leunt op dat IPv6 prefixen statisch zijn. De tijd zal leren of dat in de praktijk bij consumenten verbindingen ook overal het geval zal zijn.

[CyBeR]

Verwijderd schreef op donderdag 09 april 2015 @ 13:56:
Een andere optie kan nog zijn om een KvK registratie te doen en dan de abonnementen zakelijk af te nemen, dan heb je vaak wel statische adressen met garantie. Qua prijs maakt het elkaar vaak niet uit.

Ik heb thuis UPC zakelijk inderdaad, met /29-subnet. Veel fijner dan de consumentenversie. Vroeger hadden die pakketten ook wat meer upload trouwens maar da's inmiddels gelijkgetrokken.

[Olaf van der Spek]

ik222 schreef op donderdag 09 april 2015 @ 16:03:
Probleem met de 'bedoelde' implementaties van IPv6 is gewoon dat het heel sterk leunt op dat IPv6 prefixen statisch zijn. De tijd zal leren of dat in de praktijk bij consumenten verbindingen ook overal het geval zal zijn.

Wat is het probleem met een non-static prefix?

[antartic]

Olaf van der Spek schreef op donderdag 09 april 2015 @ 16:36:
[...]

Wat is het probleem met een non-static prefix?

Firewall regels zijn static.

[Zsub]

CyBeR schreef op donderdag 09 april 2015 @ 16:05:
[...]


Ik heb thuis UPC zakelijk inderdaad, met /29-subnet. Veel fijner dan de consumentenversie. Vroeger hadden die pakketten ook wat meer upload trouwens maar da's inmiddels gelijkgetrokken.

Een klein beetje off-topic, maar bij Ziggo betaal je je blauw voor een /29 met een leuke download-snelheid, €119/mnd ex voor 160/40mbit (betaal nu 65 inc voor 200/20).

Ik hoop dat ze daar ook nog wat in gelijk gaan trekken dan

[databeestje]

Zsub schreef op donderdag 09 april 2015 @ 16:40:
[...]

Een klein beetje off-topic, maar bij Ziggo betaal je je blauw voor een /29 met een leuke download-snelheid, €119/mnd ex voor 160/40mbit (betaal nu 65 inc voor 200/20).

Ik hoop dat ze daar ook nog wat in gelijk gaan trekken dan

Ach, ik ben nu bezig met een aanvraag voor een nieuwe organisatie, nieuw AS en PI aanvraag, vingers gekruist dat we e.e.a. kunnen regelen met RIPE als nieuwe organisatie. Die IPv6 aanvraag lukt vast wel, die andere is was lastiger.

Op de vrije markt is een /24 PI 10 euro per IP, met notaris en administratie kosten erbij zit je dan op circa 4000 euro eenmalig. Dat is het slechtste geval.

[CAPSLOCK2000]

Ik krijg al wekelijks spam van bedrijven die graag een paar IP-adresjes willen overkopen.

[Roetzen]

"Overkopen"? Is dat kopen of verkopen?

[ik222]

Olaf van der Spek schreef op donderdag 09 april 2015 @ 16:36:
[...]

Wat is het probleem met een non-static prefix?

Inderdaad dat firewall regels niet dynamisch zijn. Nou zal dat voor verbindingen tussen zakelijke locaties niet direct een probleem ziijn (daar kan je waarschijnlijk wel overal statische prefixen regelen). Maar ook hier kan ik echt nog wel goede redenen bedenken om toch voor een andere oplossing te kiezen dan enkel firewalls en IPsec.

En voor bijvoorbeeld werknemers die vanuit huis inloggen is het een heel ander verhaal. Daar is het maar de vraag of iedereen thuis een statische prefix heeft. Bovendien is enkel firewallen en IPSec voor encryptie daar sowieso niet flexibel en beheersbaar genoeg voor. Denk aan inloggen vanaf meerdere locaties, verhuizingen, verloop van personeel etc.

Kortom ik geloof dat we altijd VPN oplossingen blijven zien die soortgelijk zijn als wat je nu voor ipv4 ziet. IPv6 biedt een hoop prachtige nieuwe mogelijkheden maar de 'ideale' manier van implementatie bestaat niet, dat moet altijd van geval tot geval bekeken worden.

[ Voor 19% gewijzigd door ik222 op 09-04-2015 20:46 ]

[Olaf van der Spek]

IP-based authenticatie is sowieso onveilig toch? Dus je hebt altijd iets beters nodig.

[Dennis]

Hoe zit dat trouwens met die RFC3041 (privacy extensions) met betrekking tot computers? Zijn dat functionaliteiten die bijvoorbeeld wél aanstaan bij clients (zodat 'het internet' ze niet kan traceren omdat ze elke 2 uur een nieuw IP-adres hebben) maar niet bij servers (zodat ze op een statisch adres bereikbaar zijn)?

Of zie ik daar nog iets over het hoofd?

[databeestje]

Dat heb je helemaal goed gezien. Al blijven de clients natuurlijk wel uit dezelfde prefixes komen. Het voordeel is wel dat verbindingen naar een gebruikt adres na een paar uur dus niet meer bij de laptop uitkomen, en het is ondoenlijk om een /64 te scannen (binnen een paar uur) om deze laptop terug te vinden.

Ik denk dat de xploit markt (voor ipv6) wel zal verschuiven naar een intelligenter client server model zodat dit voor botnets niet een probleem is. Het is met de huidige NAT routers immers hetzelfde probleem met inkomende verbindingen. Daar worden al enige jaren de exploits lokaal uitgevoerd met een commando kanaal van de client naar de server waardoor de NAT dus geen beveliging is in deze. Het veranderen van client adres brengt weinig tot geen toegevoegde beveiliging.

Ook het privacy stuk is leuk, maar ach, elke Ziggo klant heeft een /56, je kan toch herleiden dat het met enige zekerheid dezelfde klant is. DHCP6 voorkomt dat de prefix meteen weer uitgegeven wordt aan een andere klant, net als in IP4.

Laat ik het zo zeggen, 1-4 apparaten achter 1 IP4 adres, of 1-4 apparaten achter 1 IP6 prefix, wezelijk niet heel erg anders.

[Paul]

Dennis schreef op zondag 12 april 2015 @ 11:30:
Zijn dat functionaliteiten die bijvoorbeeld wél aanstaan bij clients maar niet bij servers?

Voor zover ik het heb begrepen heeft een device met PE twee adressen, één statisch voor binnenkomende verbindingen, en één PE-adres wat gebruikt wordt voor uitgaande verbindingen.

Op veel servers kun je PE dus ook gebruiken (let wel, ik heb het over technisch, niet over het nut en wenselijkheid vanuit beheer ), pas als je ergens een ACL op basis van source IP hebt zit PE in de weg, voor de bereikbaarheid van het device heeft het het statische adres.

[CyBeR]

Dennis schreef op zondag 12 april 2015 @ 11:30:
Hoe zit dat trouwens met die RFC3041 (privacy extensions) met betrekking tot computers? Zijn dat functionaliteiten die bijvoorbeeld wél aanstaan bij clients (zodat 'het internet' ze niet kan traceren omdat ze elke 2 uur een nieuw IP-adres hebben) maar niet bij servers (zodat ze op een statisch adres bereikbaar zijn)?

Of zie ik daar nog iets over het hoofd?

Dat gaat voor servers net zo hard op, alleen worden die meestal statisch geconfigureerd ipv SLAAC te gebruiken (en op die subnets staat RA meestal ook uit), en dan werkt dat niet.

[Verwijderd]

PE zijn zover ik het zie tegen tracking van een systeem over meerdere fysieke locaties, hoewel dat beter kan met browser signature en cookies.

Op servers gaat bij mij direct PE uit, de ellende is dat je firewall rules maakt op basis van je static adres en dat er vervolgens een PE adres gebruikt wordt voor uitgaand verkeer. Dat is erg vervelend met bijvoorbeeld OSSEC waar dan de security key (hostname / ip) niet klopt. Een vaste thuis computer of nas / ip cam / etc heeft zover ik het zie totaal geen baat bij een PE.

[CyBeR]

Verwijderd schreef op zondag 12 april 2015 @ 13:36:
PE zijn zover ik het zie tegen tracking van een systeem over meerdere fysieke locaties, hoewel dat beter kan met browser signature en cookies.

Op servers gaat bij mij direct PE uit, de ellende is dat je firewall rules maakt op basis van je static adres en dat er vervolgens een PE adres gebruikt wordt voor uitgaand verkeer. Dat is erg vervelend met bijvoorbeeld OSSEC waar dan de security key (hostname / ip) niet klopt. Een vaste thuis computer of nas / ip cam / etc heeft zover ik het zie totaal geen baat bij een PE.

Het is zowel tegen tracking over meerdere locaties (dmv mac-adres) als om de exposure van een host te verminderen als er geen firewall is. Een IPv6 subnet scannen is ondoenlijk vanwege de enorme hoeveelheid mogelijkheden, maar als je een verbinding krijgt van een host is 't een stuk simpeler aangezien je dan 't IP-adres meekrijgt. Maar je hebt met PE slechts beperkt de tijd om dat te doen omdat dat IP gaat verlopen.

[Verwijderd]

CyBeR schreef op zondag 12 april 2015 @ 13:41:
[...]


Het is zowel tegen tracking over meerdere locaties (dmv mac-adres) als om de exposure van een host te verminderen als er geen firewall is. Een IPv6 subnet scannen is ondoenlijk vanwege de enorme hoeveelheid mogelijkheden, maar als je een verbinding krijgt van een host is 't een stuk simpeler aangezien je dan 't IP-adres meekrijgt. Maar je hebt met PE slechts beperkt de tijd om dat te doen omdat dat IP gaat verlopen.

Buitenom dat iedere host een eigen (tot op zekere hoogte) firewall zou moeten hebben en dat edge apparatuur portscans en dergelijke moet blokkeren kan ik je stelling wel volgen. Maar ben zelf niet zo een fan van security through obscurity.

Het is immers vaak genoeg dat een infected host zelf sessie naar buiten opzet, iets wat we in weinig firewalls terug zien (toegepast) met outbound rules. Terwijl ik dit zelf op host niveau heb, op netwerk (acl) en op firewall niveau. Nu begrijp ik dat dat wat verder gaat dan velen.

Waarom zijn mijn koelkast met IP een ssh sessie naar buiten mogen kunnen opzetten denk ik dan maar.

[Olaf van der Spek]

Verwijderd schreef op zondag 12 april 2015 @ 13:46:
Waarom zijn mijn koelkast met IP een ssh sessie naar buiten mogen kunnen opzetten denk ik dan maar.

Welke firewall rules heb je voor je koelkast?

[Verwijderd]

Olaf van der Spek schreef op zondag 12 april 2015 @ 14:09:
[...]

Welke firewall rules heb je voor je koelkast?

Eigenlijk voor alle "devices" gaat globaal het volgende op:
- dns van de firewall
- ntp van de firewall
- https naar internet voor updates en dergelijke

[Olaf van der Spek]

Verwijderd schreef op zondag 12 april 2015 @ 14:29:
[...]


Eigenlijk voor alle "devices" gaat globaal het volgende op:
- dns van de firewall
- ntp van de firewall
- https naar internet voor updates en dergelijke

Dan heeft malware via dns en https toch gewoon een kanaal naar buiten?

[databeestje]

Olaf van der Spek schreef op zondag 12 april 2015 @ 15:15:
[...]

Dan heeft malware via dns en https toch gewoon een kaneel naar buiten?

Op het werk forceren we door uitgaand verkeer te blokkeren het gebruik van een proxy server met authenticatie. Op die manier is HTTPS content veel makkelijker te controleren.

In sommige andere gevallen is het controlen van de DNS server een goed genoeg middel, dit doen we met DNSmasq en een whitelist, alleen die domeinen worden doorgestuurd.

In pfSense gebruik ik ook firewall rules op hostnaam om te zorgen dat deze automatisch IP4 en IP6 toepassen. Werkt een stuk prettiger dan gewoon een adres, of adressen, het scheelt ook onderhoud. Iets met alles in de cloud tegenwoordig

[Raven]

Dennis schreef op zondag 12 april 2015 @ 11:30:
Hoe zit dat trouwens met die RFC3041 (privacy extensions) met betrekking tot computers? Zijn dat functionaliteiten die bijvoorbeeld wél aanstaan bij clients (zodat 'het internet' ze niet kan traceren omdat ze elke 2 uur een nieuw IP-adres hebben) maar niet bij servers (zodat ze op een statisch adres bereikbaar zijn)?

Of zie ik daar nog iets over het hoofd?

Over privacy extensions gesproken, hoe gaat 't eigenlijk met actieve connecties/downloads op het moment dat het IPv6 adres verandert, ondervinden die er hinder van?

[CyBeR]

Raven schreef op zondag 12 april 2015 @ 18:49:
[...]

Over privacy extensions gesproken, hoe gaat 't eigenlijk met actieve connecties/downloads op het moment dat het IPv6 adres verandert, ondervinden die er hinder van?

PE-adressen blijven actief zolang ze gebruikt worden. Je kunt er op eender welk moment dus een aantal van hebben.

[Osiris]

Raven schreef op zondag 12 april 2015 @ 18:49:
[...]

Over privacy extensions gesproken, hoe gaat 't eigenlijk met actieve connecties/downloads op het moment dat het IPv6 adres verandert, ondervinden die er hinder van?

Check 'ip -6 addr list' maar eens na een goeie uptime.. Staat vol met o.a. ook de oude deprecated PE-adressen

[Raven]

Dus zodra een connectie met het oude adres wegvalt, wordt dat adres niet meer gebruikt?

[Zsub]

Alleen na verloop van tijd. Ik geloof dat er iedere zoveel tijd een nieuw adres gegenereerd wordt dat dan gebruikt wordt voor alle nieuwe connecties, en het oude blijft bestaande connecties houden.

Dus het oude gaat pas echt uit gebruik als alle connecties verbroken zijn.

[Snow_King]

Raven schreef op maandag 13 april 2015 @ 08:12:
Dus zodra een connectie met het oude adres wegvalt, wordt dat adres niet meer gebruikt?

Onder Linux wordt het adres standaard nog 24 uur aan gehouden, maar niet meer gebruikt voor uitgaande connecties.


Hebben verder andere mensen via Ziggo al IPv6 er bij gekregen?

[Ximon]

Ik zal m'n router vanavond eens een trap geven, ben benieuwd of het eindelijk zo ver is.

[Jaap-Jan]

Snow_King schreef op donderdag 16 april 2015 @ 14:35:
[...]
(...)
Hebben verder andere mensen via Ziggo al IPv6 er bij gekregen?

Hier (Hoogeveen) niet. Zojuist gerefresht, maar ik krijg geen lease.

[Jeroen_R]

Dutch2007 schreef op dinsdag 07 april 2015 @ 16:50:
[...]


Dit geldt alleen voor de regio's:

Groningen
Heerhugowaard
Tilburg
Zwolle


En alleen maar voor 1 type modem momenteel ;-) (Ubee 321W)

test is zo'n 4500 klanten

Is er bekend of dit op korte termijn wordt uitgebreid?

[Maurits van Baerle]

Jaap-Jan schreef op donderdag 16 april 2015 @ 15:06:
[...]
Hier (Hoogeveen) niet. Zojuist gerefresht, maar ik krijg geen lease.

Heb je wel de Ubee 321W en al die firmware update gekregen die jouw modem IPv6 ondersteuning geeft?

Ik ben benieuwd of ze die firmware updates landelijk uitrollen en pas daarna één voor één IPv6 aanzetten op de CMTS-en. Dan zou langzaam aan regio per regio IPv6 krijgen.

[Dutch2007]

Jeroen_R schreef op vrijdag 17 april 2015 @ 09:59:
[...]


Is er bekend of dit op korte termijn wordt uitgebreid?

bij mij nog niets over bekend....

[Jerrythafast]

Maurits van Baerle schreef op vrijdag 17 april 2015 @ 12:37:
[...]

Heb je wel de Ubee 321W en al die firmware update gekregen die jouw modem IPv6 ondersteuning geeft?

Ik ben benieuwd of ze die firmware updates landelijk uitrollen en pas daarna één voor één IPv6 aanzetten op de CMTS-en. Dan zou langzaam aan regio per regio IPv6 krijgen.

Ik heb al een tijdje die firmware, maar nog altijd geen prefix...

[Bigs]

Toch blijf je met IPv6 rare dingen tegenkomen.. allerlei hosts (Macbooks) in mijn geven zichzelf naast hun normale adres een adres in de 4006:: range (overigens zonder privacy) die altijd direct deprecated staat in ifconfig. Google leert me dat dit waarschijnlijk een bug is in Apple's iOS, de Fritz!Box (die ik van XS4ALL heb) of een combinatie daarvan: http://www.famkruithof.net/4006ipv6prefix.html

Zelf nog geen onderzoek naar gedaan en het is op zich niet problematisch, maar het maakt het er allemaal niet helderder op.

[CyBeR]

Dat lijkt me een Fritz-bug te zijn.

[Osiris]

Euh, de tekst vermeldt dat andere routers het ook doen.. En dat de client gare, fucked up packets uitspuugt, waarna pas de F!B weer reageert..

[CyBeR]

't kan allicht dat andere routers een dergelijke bug ook hebben als ze op dezelfde code gebaseerd zijn. Maar die pagina zou ik niet als de meest autoritatieve bron gebruiken. Die jongen moest 0xc0a8 "hex decoden" om te weten dat dat overeen komt met 192.168, en 192.168.178.0/24 is het default subnet van alle fritzboxen dus sowieso heeft dat ding er imo *iets* mee te maken.

Maar goed dat is allemaal zonder 't zelf gezien te hebben -- mijn OSX en iOS apparaten (ik heb geen windows) doen dit allemaal niet en ik heb ook geen fritzbox want wat een kutdingen zijn dat.

[Jaap-Jan]

Ook weer veel te simpel. Elk verbonden apparaat heeft ook een adres in die reeks, dus die kunnen er net zo goed *iets* mee te maken hebben.

[Maurits van Baerle]

Jerrythafast schreef op vrijdag 17 april 2015 @ 19:46:
[...]

Ik heb al een tijdje die firmware, maar nog altijd geen prefix...

Da's goed om te weten. Ik zie dat je in Wassenaar woont en niet in één van de eerste uitrol gebieden. Dat betekent dat ze die nieuwe firmware landelijk hebben uitgerold en dat het nu dus een kwestie is van wachten tot de lokale CMTS is omgezet.

[Verwijderd]

Vers van de fax:

Vandaag is in de eerste regio, Hilversum, IPv6 aangezet.
Ruim 3200 KPN-klanten internetten nu Dual stack.
.... Glas/VDSL

AS1136

[ Voor 3% gewijzigd door Verwijderd op 24-04-2015 13:45 ]

[agresionpower]

Verwijderd schreef op vrijdag 24 april 2015 @ 13:42:
Vers van de fax:


[...]

Ik zag het net inderdaad voorbij komen.
Ben benieuwd wat hun planning is voor verdere uitrol.

[Snow_King]

Verwijderd schreef op vrijdag 24 april 2015 @ 13:42:
Vers van de fax:


[...]

Pardon!? Waar heb je dit bericht ineens vandaan?

Hoe staat het verder met Ziggo, daar zie/hoor je nu ook niets over.

[Verwijderd]

Snow_King schreef op vrijdag 24 april 2015 @ 14:32:
[...]

Pardon!? Waar heb je dit bericht ineens vandaan?

Hoe staat het verder met Ziggo, daar zie/hoor je nu ook niets over.

Ziggo heb ik ook niets van gehoord, ik zal eens polsen bij een contact daar.

IPv6 taskforce mailing list, specifiek van:

KPN NetCo FO N&SD

[ Voor 4% gewijzigd door Verwijderd op 24-04-2015 14:47 ]

[CAPSLOCK2000]

Het komt IPv6 Taskforce. De informatie daar is over het algemeen erg betrouwbaar.

[ Voor 19% gewijzigd door CAPSLOCK2000 op 24-04-2015 14:42 ]

[Maurits van Baerle]

Wat voor klanten zijn dit? Zakelijk? Consumenten? Zijn dit alleen gebruikers die hun dienst rechtstreeks bij KPN afnemen en niet bij een ISP die het KPN netwerk gebruikt?

[CyBeR]

AS1136 = consumenten. (Vroeger planet e.d., nu Direct-ADSL en co.)

[ Voor 55% gewijzigd door CyBeR op 24-04-2015 15:00 ]

[Maurits van Baerle]

CyBeR schreef op vrijdag 24 april 2015 @ 14:59:
AS1136 = consumenten. (Vroeger planet e.d., nu Direct-ADSL en co.)

Ah, helder. Goeie zaak dat het ook naar gewone consumenten uitgerold wordt! Aangezien ik er verder helemaal geen aankondiging van heb gezien vermoed ik dat de meeste mensen niet eens door zullen hebben dat ze nu op DS zitten.

Nu hopen dat ze groter dan een /64 per aansluiting uitdelen.

Artikeltje waard op de Frontpage?

[ Voor 10% gewijzigd door Maurits van Baerle op 24-04-2015 15:24 ]

[databeestje]

Maurits van Baerle schreef op vrijdag 24 april 2015 @ 15:04:
[...]

Ah, helder. Goeie zaak dat het ook naar gewone consumenten uitgerold wordt! Aangezien ik er verder helemaal geen aankondiging van heb gezien vermoed ik dat de meeste mensen niet eens door zullen hebben dat ze nu op DS zitten.

Nu hopen dat ze groter dan een /64 per aansluiting uitdelen.

Artikeltje waard op de Frontpage?

Ik wacht nog even op wat technische info van desbetreffende persoon, zonder knappe details zaait het alleen maar meer verwarring.

[Bigs]

Maurits van Baerle schreef op vrijdag 24 april 2015 @ 15:04:
[...]

Nu hopen dat ze groter dan een /64 per aansluiting uitdelen.

[...]

Ik denk dat klanten die voorheen één IPv4 adres kregen nu genoeg hebben aan een /64. Voor klanten die nu een routed subnet hebben lijkt een kortere prefix wél voor de hand liggen.

[CyBeR]

Bigs schreef op vrijdag 24 april 2015 @ 17:16:
[...]


Ik denk dat klanten die voorheen één IPv4 adres kregen nu genoeg hebben aan een /64.

Ik denk dat die klanten voorheen geen keus hadden en nu wel. KPN zou volledig tegen de standaarden ingaan als ze alleen een /64 uitdeelden.

[Nakebod]

Dus KPN kennende doen ze dat
Geen garantie, maar de KPN ITNS providers geven AFAIK een /56.
Alleen was dat wel een 6RD implementatie.

[tlpeter]

Lijkt mij toch dat KPN naar hun eigen dochten XS4all luisterd en gevraagd heeft hoe ze IPv6 hebben geimplementeerd?

[Maurits van Baerle]

Bigs schreef op vrijdag 24 april 2015 @ 17:16:
[...]


Ik denk dat klanten die voorheen één IPv4 adres kregen nu genoeg hebben aan een /64. Voor klanten die nu een routed subnet hebben lijkt een kortere prefix wél voor de hand liggen.

Als KPN een /64 zou uitdelen zou dat het kleinste blok zijn van alle Nederlandse ISP's, de rest geeft een /48 of /56. Een /64 betekent bijvoorbeeld dat gebruikers niet makkelijk een extra subnet kunnen aanmaken. Dan is een /56 een stuk prettiger (256 subnetten).

En dat terwijl KPN achter AS1136 één keer een /25, twee keer een /26 en twee keer een /48 heeft zitten. Aan capaciteit geen gebrek.

[Pietervs]

(Heb al een paar pagina's teruggelezen, maar kon het niet vinden. Dus bij voorbaat mijn excuses als de volgende vraag al aan bod is geweest, en als dat zo is hoor ik dat graag en zoek ik nog verder terug )
Welke versie software draait er op de Cisco EPC3928 in de regio's waar nu IPv6 is uitgerold?

We hebben nu Firmware Version: epc3928a-E10-5-v302r125572-131030c-ZIG er op staan, ik heb het modem al een aantal keren herstart de afgelopen weken maar zie nog niks erbij komen wat er op duidt dat IPv6 al in deze firmware zit.
En aangezien ik nieuwsgierig ben...

[databeestje]

Naar mijn weten en contacten met de KPN denk ik niet dat een /64 een realistische aaname is. Er is per gebruiker een /48 vrij gehouden, wat niet wil zeggen dat de gebruikers ook een /48 krijgen.

Gebruik niet de 6rd als uitgangspunt, dat doet de KPN ook niet.

[Zsub]

Pietervs schreef op vrijdag 24 april 2015 @ 18:59:
(Heb al een paar pagina's teruggelezen, maar kon het niet vinden. Dus bij voorbaat mijn excuses als de volgende vraag al aan bod is geweest, en als dat zo is hoor ik dat graag en zoek ik nog verder terug )
Welke versie software draait er op de Cisco EPC3928 in de regio's waar nu IPv6 is uitgerold?

We hebben nu Firmware Version: epc3928a-E10-5-v302r125572-131030c-ZIG er op staan, ik heb het modem al een aantal keren herstart de afgelopen weken maar zie nog niks erbij komen wat er op duidt dat IPv6 al in deze firmware zit.
En aangezien ik nieuwsgierig ben...

Voor zover ik weet worden alleen de Ubee WiFi modems in een select aantal locaties op dit moment aangezet voor IPv6.

[Maurits van Baerle]

Volgens mij is het zelfs alleen de Ubee EVW321b en volgt de Ubee EVW320 daarna pas. En daarna pas de andere merken modems.

Het voordeel is wel dat ze vermoedelijk eerst alle CMTS-en over gaan zetten zodat het werkt voor iedereen met een EVW321b. Daarna zou een firmwareupdate op alle andere modellen meteen een IPv6 verbinding in kunnen houden omdat de lokale CMTS dan al is overgezet.

[mastervissie]

Pietervs schreef op vrijdag 24 april 2015 @ 18:59:
We hebben nu Firmware Version: epc3928a-E10-5-v302r125572-131030c-ZIG er op staan, ik heb het modem al een aantal keren herstart de afgelopen weken maar zie nog niks erbij komen wat er op duidt dat IPv6 al in deze firmware zit.

Ik heb ook die firmware, en als je in de browser met element inspecteren (Firefox/Chrome) de tabel waar "Internet IPv4 Connection" in staat inspecteerd, dan staan daaronder 2 tabellen met een style "display: none;", als je dat weg haalt krijg je 2 tabellen erbij. Een voor Internet IPv6 Connection en eentje voor DS-Lite Configuration.

Er staan nog geen gegevens in maar het lijkt er dus op dat de firmware wel geschikt is voor IPv6.

[Pietervs]

Ik geloof dat ik dus nog wat meer geduld moet hebben...
Wij wonen in het midden van het land, dus ik heb stille hoop dat het voor ons niet al te lang zal duren voor IPv6 komt.

Mastervissie, Maurits en Zstub dank voor het reageren

[AndriesLouw]

mastervissie schreef op vrijdag 24 april 2015 @ 20:29:
[...]


Ik heb ook die firmware, en als je in de browser met element inspecteren (Firefox/Chrome) de tabel waar "Internet IPv4 Connection" in staat inspecteerd, dan staan daaronder 2 tabellen met een style "display: none;", als je dat weg haalt krijg je 2 tabellen erbij. Een voor Internet IPv6 Connection en eentje voor DS-Lite Configuration.

Er staan nog geen gegevens in maar het lijkt er dus op dat de firmware wel geschikt is voor IPv6.

Ik kan bevestigen dat dit ook geldt voor de epc3925-E10-5-v302r125572-130520c-ZIG. Wanneer je het inloggen en opvragen van deze pagina tijdens het opstarten van het modem goed timed, zijn deze tabellen niet voorzien van display:none en dus gewoon zichtbaar.

[Maurits van Baerle]

Zijn er aanwijzingen dat deze twee Cisco's ook een volledig werkende IPv6 firewall aan boord hebben?

Dat lijkt een voorwaarde voor Ziggo om IPv6 in te schakelen dus als die nog ontbreekt is er toch nog eerst een firmwareupdate voor nodig.

[ Voor 5% gewijzigd door Maurits van Baerle op 26-04-2015 18:33 ]

[Jeroen_R]

Maurits van Baerle schreef op zondag 26 april 2015 @ 17:49:
Zijn er aanwijzingen dat deze twee Cisco's ook een volledig werkende IPv6 firewall aan boord hebben?

Bij de EPC3925 ontbreekt iig de functie om poorten voor IPv6 open te zetten, dus een firmware update is bij deze router nog wel nodig.

[eymey]

CyBeR schreef op zaterdag 18 april 2015 @ 00:14:
't kan allicht dat andere routers een dergelijke bug ook hebben als ze op dezelfde code gebaseerd zijn. Maar die pagina zou ik niet als de meest autoritatieve bron gebruiken. Die jongen moest 0xc0a8 "hex decoden" om te weten dat dat overeen komt met 192.168, en 192.168.178.0/24 is het default subnet van alle fritzboxen dus sowieso heeft dat ding er imo *iets* mee te maken.

Maar goed dat is allemaal zonder 't zelf gezien te hebben -- mijn OSX en iOS apparaten (ik heb geen windows) doen dit allemaal niet en ik heb ook geen fritzbox want wat een kutdingen zijn dat.

Eerst even een off-topic vraagje: Wat voor probleem heb je precies met Fritz!boxen? Ik ben inmiddels al zo'n 9 jaar Fritz!box gebruiker en, los van de wat onlogisch ingedeelde interface, totaal geen problemen met die dingen. Vooral met m'n 7490 ben ik ontzettend tevreden, vooral qua performance en stabiliteit. Ik kan me wel voorstellen dat, als je wat meer geävanceerde dingen (vooral m.b.t. ipv6) wil kunnen instellen, dat je er dan een probleem mee hebt.

In ieder geval: Een bug in de Fritz!box zou ik het niet direct willen noemen. Want als ik, naast de eerder voorbij gekomen link van Kruithof, bv. ook deze bron lees ( http://www.kdgforum.de/viewtopic.php?f=67&t=33594 ), dan maak ik daaruit op dat het een bewuste keuze is van AVM om dit te doen.

Sterker nog, om dit te doen moeten ze zelfs nog bewust om 1 of andere bug in Vista heen werken .

Overigens, op mijn Windows 7 systeem zie ik ook van deze adressen (en ik heb geen iOS of MacOS apparaten in huis).
IPv6 Address. . . . . . . . . . . : 4006:7c4f:c0a8:997:4da6:82cb:4603:a044(Deprecated)
IPv6 Address. . . . . . . . . . . : 4006:7c81:c0a8:997:4da6:82cb:4603:a044(Deprecated)

Je kan je natuurlijk wel afvragen waarom ze dit zo doen. Maar als ik het een beetje goed begrijp, dan lijken ze dus gewoon te willen voorkomen dat een ander apparaat aan de LAN-zijde zichzelf adverteert als een router.

Ik heb op dit moment even geen tijd om heel uitgebreid te testen, maar ik heb hier wel een setting die bij mij (en wrs bij veel Fritz!box gebruikers want default) uitgeschakeld staat:

"Allow IPv6 prefixes announced by other IPv6 routers in the home network". Men heeft dus duidelijk wel bewust iets geïmplementeerd om IPv6 advertisements anders die van zichzelf te counteren.

[CyBeR]

eymey schreef op zondag 26 april 2015 @ 20:10:
[...]


Eerst even een off-topic vraagje: Wat voor probleem heb je precies met Fritz!boxen? Ik ben inmiddels al zo'n 9 jaar Fritz!box gebruiker en, los van de wat onlogisch ingedeelde interface, totaal geen problemen met die dingen. Vooral met m'n 7490 ben ik ontzettend tevreden, vooral qua performance en stabiliteit. Ik kan me wel voorstellen dat, als je wat meer geävanceerde dingen (vooral m.b.t. ipv6) wil kunnen instellen, dat je er dan een probleem mee hebt.

Instabiel, onlogische interface inderdaad, idioot met wachtwoorden (ww kwijt? reset de hele config maar lekker en elke keer dat je 't probeert mag je exponentieel langer wachten), kunnen geen VDSL bridgen (alleen ADSL), etc. etc. En deze IPv6 meuk komt er ook nog bij; Zoiets als bug hebben is nog tot daaraantoe maar bewust ongeldige prefixen adverteren is gewoon not-done.

[eymey]

Tsja, dat instabiel herken ik dus totaal niet. Interface is een kwestie van wennen. Het beleid omtrent wachtwoorden heb ik geen problemen mee (lijkt me alleen maar veiliger zo). En dit gedrag met ipv6 is dus waarschijnlijk ook gewoon uit te schakelen. Bovendien begint het dus al met een apparaat in je netwerk dat begint met het adverteren van ongeldige prefixen.

Maar goed, smaken verschillen. Ik ben meer dan tevreden... in het verleden op ADSL en de laatste jaren op glas