Het grote IPv6 topic

[CAPSLOCK2000]

SiXXS is inderdaad extreem streng, maar volgens mij is het in praktijk 1 persoon die de hele tent draaiend houdt. Ik snap wel dat hij maatregelen neemt om z'n workload te managen. Leuk is anders en af en toe gaat het er nogal lomp aan toe, maar zo veel gebruikers in je eentje helpen is haast niet te doen.

[Jogai]

Dan probeer ik het binnenkort nog een keertje. Misschien is hij dan in een betere bui. Voor de rest had ik het idee dat ik wel aan de regels voldeed.

[joopv]

Ik gebruik tegenwoordig een password manager tool. Kan ik iedereen aanbevelen. Er staan nu 110 records in.

[Maurits van Baerle]

Snow_King schreef op dinsdag 12 augustus 2014 @ 13:26:


Ik zal ze eens een mailtje sturen of ze zich daar willen aan melden.

Maurits van Baerle schreef op dinsdag 12 augustus 2014 @ 13:50:
[...]

Dan hebben ze er nu twee.

Vandaag een mailtje terug gekregen van Zeelandnet en ze hebben zich nu aangemeld. Even kijken wanneer ze verschijnen...

[Keiichi]

Sinds wanneer gaat de speedtest van ziggo over Ipv6?

http://speedtest6.ziggo.nl/

[Verwijderd]

Keiichi schreef op dinsdag 19 augustus 2014 @ 00:11:
Sinds wanneer gaat de speedtest van ziggo over Ipv6?

http://speedtest6.ziggo.nl/

Van wat ik zo snel zie circa begin juni 2014.

[databeestje]

Prima snelheid via de HE.net tunnel, valt me erg mee.

[Snow_King]

databeestje schreef op dinsdag 19 augustus 2014 @ 19:20:
Prima snelheid via de HE.net tunnel, valt me erg mee.

Tunnel... Ik heb het met je te doen!

Ben érg blij met native IPv6 op mijn ZeelandNet verbinding thuis en op de kantoren.

Op kantoor gaan we zelfs over door onze hele VOIP IPv6-only te draaien. Eigen VLAN voor telefoons (is er al) waar niet eens meer IPv4 in aanwezig is.

Geen gedoe meer met NAT en/of VPN tunnels voor de telefoons. Gewoon peer-to-peer RTP tussen de telefoons.

[Raven]

Lol, dat is helemaal niet nodig , HE-tunnels kunnen aardig rap zijn

[elsinga]

Ik heb de Zigo ipv6 speedtest even geprobeerd, via mijn native 6to4-tunnel. Ik haal vrijwel dezelfde snelheden als met ipv4.

[Roetzen]

Ik krijg maar de helft van mijn IPv4 snelheid via mijn he.net tunnel.

[ Voor 56% gewijzigd door Roetzen op 19-08-2014 22:35 ]

[Jogai]

Roetzen schreef op dinsdag 19 augustus 2014 @ 22:26:
Ik krijg maar de helft van mijn IPv4 snelheid via mijn he.net tunnel.

Met ^^
Kunnen de HE tunnel gebruikers eens uitleggen hoe wij ook de volle snelheid krijgen?

[Nakebod]

Minder snel internet nemen?
Kan mij voorstellen dat iemand met een 20 Mbit abo wel de maximale snelheid via een tunnel haalt, maar 100+ Mbit bijvoorbeeld niet, want die tunnels hebben ook geen oneindige capaciteit.

[Raven]

Jogai schreef op woensdag 20 augustus 2014 @ 07:58:
[...]

Met ^^
Kunnen de HE tunnel gebruikers eens uitleggen hoe wij ook de volle snelheid krijgen?

Een 50/50Mb lijntje wil prima hier, heb ook wel eens mensen gezien met een minstens 2 keer zo hoge download (maar véél lagere upload) die ook zonder problemen via een HE-tunnel de snelheid konden halen.

[Zsub]

Ik haal meestal in de ordegrootte 90-100mbit via die ziggo ipv6 speedtest en een hè.net tunnel in Amsterdam.

[Roetzen]

Resultaat ziggo.speedtetst.nl:

•
Op IPv4 Ping 15 ms, Down 31,60 Up 2,81
Via he.net Ping 16 ms Down 14,71 Up 2,33
Via SixXs Ping 20 ms Down 4,35 Up 2,33

[CAPSLOCK2000]

Ik haal zo'n 150mbit via m'n sixxs-tunnel (Ziggo 180mbit inet). Dat is zo goed dat ik nog niet de moeite heb genomen om uit te zoeken waar de beperking zit, de bron, de tunnel of mijn verbinding met Ziggo.

[Roetzen]

Ik heb wel gezocht naar de oorzaak van de vertraging, maar ik heb het nog niet kunnen vinden...

[Raven]

Misschien zit het probleem op het gebruikte eindpunt van de tunnel? Ik gebruik al jaren geen htk-router meer, maar een simpele singlecore Atom pc met 1GB RAM en IPFire.

[ Voor 4% gewijzigd door Raven op 20-08-2014 18:07 ]

[Roetzen]

Ik kan het niet uitsluiten. De he.net tunnel eindigt op een Linksys WRT54GL met OpenWrt. Ik heb geen mogelijkheid die "even" te vervangen voor een test.

De SixXs tunnel eindigt op een Windows XP machine waarop AICCU draait. De snelheid verbetert niet als ik de router er tussen uit haal en die machine rechtstreeks op de kabelmodem aansluit.

[Jogai]

Ik had aiccu draaien op een i5 laptop met ubuntu server. 30Mbit down op mijn 20Mbit adsl abbonement. Dat haalde ik niet via HE, maar misschien moet ik dat eens opnieuw configureren...

[antartic]

Ook eens even testen, ik heb een ziggo 180Mbit down 18Mbit up met een HE tunnel op mijn Asus AC66U met Merlin firmware.

speedtest6.ziggo.nl ping: 19ms down: 131.62Mbps up: 16.89Mbps
speedtest4.ziggo.nl ping: 12ms down: 176.68Mbps up: 17.38Mbps

Beide tests iets na 21:00 dus redelijk primetime.
Valt mij persoonlijk niet tegen.

[Snow_King]

Aangezien de speedtest nu ook ineens IPv6 doet verwacht ik dat ze bij Ziggo ook druk bezig zijn en 2014 best een mooi IPv6 jaar kan worden.

ZeelandNet gaat het voor iedereen aan zetten, wellicht Ziggo en UPC ook nog. Dan gaat het ineens hard met IPv6!

[gekkie]

wat doet men eigenlijk zo al met al aan firewall bij ipv6 ?

met ipv4 en NAT is het opzich vrij helder wie wat waar en hoe .. maar ipv6 ..

[FatalError]

gekkie schreef op woensdag 20 augustus 2014 @ 22:15:
wat doet men eigenlijk zo al met al aan firewall bij ipv6 ?

met ipv4 en NAT is het opzich vrij helder wie wat waar en hoe .. maar ipv6 ..

Nou, dat werkt bij IPv6 precies hetzelfde

[Jaap-Jan]

Met mijn Sixxs- tunnel (nlede01 PoP) komt ook in de buurt van IPv6 snelheden:
IPv6: Ping: 20 ms, Down: 87,78Mbps, Up: 8,49 Mbps
IPv4: Ping: 8 ms, Down: 90,21 Mbps, Up: 8,75 Mbps

Ik heb 1 run gedaan, maar de grafiek was redelijk stabiel, dus ik verwacht niet veel variantie.

Getest met een laptop met Intel Gigabit ethernet, verbonden meteen Netgear R7000 met Tomato firmware.

Ping blijft een klein beetje achter, maar de snelheden zijn niet slecht.

FatalError schreef op woensdag 20 augustus 2014 @ 22:22:
[...]


Nou, dat werkt bij IPv6 precies hetzelfde

Precies. Inbound alleen established connections en een paar poorten naar mijn server.

[ Voor 7% gewijzigd door Jaap-Jan op 20-08-2014 22:29 ]

[Snow_King]

gekkie schreef op woensdag 20 augustus 2014 @ 22:15:
wat doet men eigenlijk zo al met al aan firewall bij ipv6 ?

met ipv4 en NAT is het opzich vrij helder wie wat waar en hoe .. maar ipv6 ..

Ik heb geen firewall aan staan op IPv6, want dat heb ik op de hosts zelf gedaan.

In mijn thuis (en ook kantoor) situatie is het 100% Ubuntu systemen waar enkel OpenSSH open zal staan.

Omdat ik het juist fijn vind dat het spul weer peer-to-peer kan werken heb ik geen firewall.

De privacy extension van IPv6 maken het ook een stuk moeilijker mijn apparatuur te vinden. Als je mijn IP weet, dan werkt dat IP maar een paar uur, daarna ben ik weer 'weg'.

[gekkie]

Jaap-Jan schreef op woensdag 20 augustus 2014 @ 22:25:
Precies. Inbound alleen established connections en een paar poorten naar mijn server.

Hmm naja m'n ipv4 scriptje dan maar eens gaan aanvullen voor ipv6 .. bergje logging .. is kijken wat het doet

[CAPSLOCK2000]

De Belgen zijn weer bezig hoor, 28.2% IPv6 gebruikers... http://6lab.cisco.com/stats/cible.php?country=be

[gekkie]

CAPSLOCK2000 schreef op woensdag 20 augustus 2014 @ 23:44:
De Belgen zijn weer bezig hoor, 28.2% IPv6 gebruikers... http://6lab.cisco.com/stats/cible.php?country=be

Nah niet eens een klein bobbeltje rond fosdem in die grafiek .. valt weer tegen

[Raven]

gekkie schreef op woensdag 20 augustus 2014 @ 22:15:
wat doet men eigenlijk zo al met al aan firewall bij ipv6 ?

met ipv4 en NAT is het opzich vrij helder wie wat waar en hoe .. maar ipv6 ..

Standaard al het inkomende blocken, tenzij het voor een verbinding is dat van binnenuit is opgezet. Lekker simpel, maar wel doeltreffend. Bij ipv6 moet je echter overigens wel bepaalde icmpv6 pakketten toestaan.

[gekkie]

Raven schreef op donderdag 21 augustus 2014 @ 10:04:
[...]
Standaard al het inkomende blocken, tenzij het voor een verbinding is dat van binnenuit is opgezet. Lekker simpel, maar wel doeltreffend. Bij ipv6 moet je echter overigens wel bepaalde icmpv6 pakketten toestaan.

Mjah in feite wat bij ipv4 impliciet door je NAT al geregeld is. Je bedoeld icmpv6 altijd doorlaten ook zonder verbinding van buitenaf ? (zal wel met die autodiscovery te maken hebben ?)

[Snow_King]

Raven schreef op donderdag 21 augustus 2014 @ 10:04:
[...]

Standaard al het inkomende blocken, tenzij het voor een verbinding is dat van binnenuit is opgezet. Lekker simpel, maar wel doeltreffend. Bij ipv6 moet je echter overigens wel bepaalde icmpv6 pakketten toestaan.

Nadeel is wel dat peer-to-peer applications dus niet werken.

Juist met IPv6 kunnen we daar omheen werken.

Je kan er voor kiezen een aantal poorten dicht te zetten, zoals:
- 3389 (RDP)
- 5900 (VNC)
- < 1024

Dan kunnen je services nog wel netjes functioneren peer-to-peer zonder tussenkomst van firewall.s

ICMPv6 zou ik altijd door laten.

[gekkie]

Snow_King schreef op donderdag 21 augustus 2014 @ 10:20:
[...]
Nadeel is wel dat peer-to-peer applications dus niet werken.

Juist met IPv6 kunnen we daar omheen werken.

Je kan er voor kiezen een aantal poorten dicht te zetten, zoals:
- 3389 (RDP)
- 5900 (VNC)
- < 1024

Dan kunnen je services nog wel netjes functioneren peer-to-peer zonder tussenkomst van firewall.s

ICMPv6 zou ik altijd door laten.

Mjah met ipv4 heb ik er een aantal geforward naar de machine(s) waarvoor dat relevant is, naja de firewalls van alle individuele apparaten moeten dan dus nog eens langsgelopen worden .. vooral tablet meuk enzo.

[Raven]

gekkie schreef op donderdag 21 augustus 2014 @ 10:09:
[...]


Mjah in feite wat bij ipv4 impliciet door je NAT al geregeld is. Je bedoeld icmpv6 altijd doorlaten ook zonder verbinding van buitenaf ? (zal wel met die autodiscovery te maken hebben ?)

Jep, leesvoer: Wikipedia: ICMPv6

Ik gebruik

code:

ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp -j ACCEPT

al staat

code:

ip6tables -A FORWARD -p ipv6-icmp -j ACCEPT

er ook nog bij. Niet per se nodig voor een werkende verbinding (althans, zo leek het iig), maar bepaalde IPv6-test sites geven dan een hogere score

Snow_King schreef op donderdag 21 augustus 2014 @ 10:20:
[...]
Nadeel is wel dat peer-to-peer applications dus niet werken.

Juist met IPv6 kunnen we daar omheen werken.

Je kan er voor kiezen een aantal poorten dicht te zetten, zoals:
- 3389 (RDP)
- 5900 (VNC)
- < 1024

Dan kunnen je services nog wel netjes functioneren peer-to-peer zonder tussenkomst van firewall.s

ICMPv6 zou ik altijd door laten.

Niet? uTorrent doet iig prima op deze pc, zonder poorten open te zetten in zowel iptables als ip6tables doen zowel ipv4 als ipv6 verbindingen het prima. En nee, er is bij mijn weten geen UPnP aanwezig in IPFire.

gekkie schreef op donderdag 21 augustus 2014 @ 10:38:
[...]


Mjah met ipv4 heb ik er een aantal geforward naar de machine(s) waarvoor dat relevant is, naja de firewalls van alle individuele apparaten moeten dan dus nog eens langsgelopen worden .. vooral tablet meuk enzo.

Op Windows clients gebruik ik altijd Eset Smart Seciruty in interactive modus, dan zie ik tenminste wat er gebeurt. Werkt ook met IPv6, althans, ik heb popups gezien met IPv6 adressen erin.

[ Voor 15% gewijzigd door Raven op 21-08-2014 10:51 ]

[databeestje]

ICMPv6 is een fundamenteel onderdeel van IPv6. Helaas ziet iedereen ICMP alleen als de "echo" in ICMP. Met IPv4 was dat in zekere zin waar, met IPv6 is dat iets anders.

Het is namelijk noodzakelijk voor de "Packet too big" berichten, en dat is een cruciaal onderdeel voor TCP communicatie met een host die een andere MTU hanteert.

Beter zou je kunnen stellen, laat ICMPv6 toe en blokkeer ICMPv6 "echo". Daarnaast is het noodzakelijk voor Neigbor Discovery, Router Solications en Router discovery. M.a.w. blokkeer ICMPv6 op de host en je kan de gateway niet meer vinden of doorkrijgen.

Meestal zijn firewalls slim genoeg om ICMPv6 op de fe80:: link-local addressen altijd door te laten. Mocht je zelf rules samenstellen vergeet daar dan geen uitzondering voor te maken.

[CyBeR]

ICMP is bij IPv4 net zo hard een fundamenteel onderdeel. Path MTU detection gaat ook mis als je ICMP (v4) blokkeert bijvoorbeeld.

[Snow_King]

Raven schreef op donderdag 21 augustus 2014 @ 10:41:

Niet? uTorrent doet iig prima op deze pc, zonder poorten open te zetten in zowel iptables als ip6tables doen zowel ipv4 als ipv6 verbindingen het prima. En nee, er is bij mijn weten geen UPnP aanwezig in IPFire.

Wellicht doet uTorrent wat fancy dingen, maar zaken zoals SIP gaan kapot door firewalls/NAT.

Voor SIP moeten er bijvoorbeeld inbound packets komen zonder dat daarvoor een uitgaande connectie bij is.

databeestje schreef op donderdag 21 augustus 2014 @ 11:34:
ICMPv6 is een fundamenteel onderdeel van IPv6. Helaas ziet iedereen ICMP alleen als de "echo" in ICMP. Met IPv4 was dat in zekere zin waar, met IPv6 is dat iets anders.

Het is namelijk noodzakelijk voor de "Packet too big" berichten, en dat is een cruciaal onderdeel voor TCP communicatie met een host die een andere MTU hanteert.

Beter zou je kunnen stellen, laat ICMPv6 toe en blokkeer ICMPv6 "echo". Daarnaast is het noodzakelijk voor Neigbor Discovery, Router Solications en Router discovery. M.a.w. blokkeer ICMPv6 op de host en je kan de gateway niet meer vinden of doorkrijgen.

Meestal zijn firewalls slim genoeg om ICMPv6 op de fe80:: link-local addressen altijd door te laten. Mocht je zelf rules samenstellen vergeet daar dan geen uitzondering voor te maken.

fe80:: is link-local en zal nooit door een Layer 3 firewall/router heen gaan. Hoogsteens een Layer 2 transparant firewall, maar die zie ik veel mensen nog niet direct op zetten.

Wel heb je gelijk, ICMPv6 moet je gewoon niet blokkeren. Je wil MTU Path Detection e.d. werkend hebben. Echo-request zou je kunnen blokkeren, maar ik vind het persoonlijk altijd wel fijn als 'ping' werkt.

CyBeR schreef op donderdag 21 augustus 2014 @ 11:37:
ICMP is bij IPv4 net zo hard een fundamenteel onderdeel. Path MTU detection gaat ook mis als je ICMP (v4) blokkeert bijvoorbeeld.

Verschil is dat het bij IPv6 mandatory is en bij IPv4 niet. Maar verder heb je volledig gelijk.

ICMP is gewoon een essentieel underdeel van een goed werkend netwerk.

[ Voor 10% gewijzigd door Snow_King op 21-08-2014 11:44 ]

[databeestje]

Snow_King schreef op donderdag 21 augustus 2014 @ 11:43:
[...]
Wellicht doet uTorrent wat fancy dingen, maar zaken zoals SIP gaan kapot door firewalls/NAT.

Voor SIP moeten er bijvoorbeeld inbound packets komen zonder dat daarvoor een uitgaande connectie bij is.


[...]
fe80:: is link-local en zal nooit door een Layer 3 firewall/router heen gaan. Hoogsteens een Layer 2 transparant firewall, maar die zie ik veel mensen nog niet direct op zetten.

Toch ben ik firewall softwaren tegengekomen die ook op fe80:: actief waren en blokkeerden. Dat zal niet de bedoeling zijn maar toch gebeuren. Ik doel hier op de lokale firewall diensten van een host, niet de router

Inmiddels zal het wel beter zijn, oudere Symantec was hier een voorbeeld van.

Wel heb je gelijk, ICMPv6 moet je gewoon niet blokkeren. Je wil MTU Path Detection e.d. werkend hebben. Echo-request zou je kunnen blokkeren, maar ik vind het persoonlijk altijd wel fijn als 'ping' werkt.


[...]
Verschil is dat het bij IPv6 mandatory is en bij IPv4 niet. Maar verder heb je volledig gelijk.

ICMP is gewoon een essentieel underdeel van een goed werkend netwerk.

+1

[gekkie]

Snow_King schreef op donderdag 21 augustus 2014 @ 11:43:
Wel heb je gelijk, ICMPv6 moet je gewoon niet blokkeren. Je wil MTU Path Detection e.d. werkend hebben. Echo-request zou je kunnen blokkeren, maar ik vind het persoonlijk altijd wel fijn als 'ping' werkt.

Rate-limited dan wel .. althans dat heb ik bij ipv4 wel.

Zijn er eigenlijk al ipv6 specifieke "attacks"ala syn, christmas etc bekend ?

[Snow_King]

databeestje schreef op donderdag 21 augustus 2014 @ 11:46:
[...]

Toch ben ik firewall softwaren tegengekomen die ook op fe80:: actief waren en blokkeerden. Dat zal niet de bedoeling zijn maar toch gebeuren. Ik doel hier op de lokale firewall diensten van een host, niet de router

Inmiddels zal het wel beter zijn, oudere Symantec was hier een voorbeeld van.

Ah, dan praten we langs elkaar. Jij hebt het over een lokale firewall op een device zoals een desktop/laptop. Ik sprak over een firewall in een router. Daar komt fe80:: nooit langs.

Lokaal op een machine met ip6tables (Linux) moet je idd al het fe80:: ICMPv6 verkeer er door laten.

gekkie schreef op donderdag 21 augustus 2014 @ 11:52:
[...]


Rate-limited dan wel .. althans dat heb ik bij ipv4 wel.

Kan wel handig zijn ja. Persoonlijk doe ik het nooit, maar echo-requests limiten is geen probleem.

[databeestje]

Snow_King schreef op donderdag 21 augustus 2014 @ 12:06:
[...]

Kan wel handig zijn ja. Persoonlijk doe ik het nooit, maar echo-requests limiten is geen probleem.

Rate limiters kan een probleem zijn als je het nummer niet correct uitrekent voor je implementatie.

Zo lijkt 1000pps een mooi getal, maar niet als je > 10k connecties hebt, deze zullen met enige regelmaat PtB gebruiken. Als je een limiter gaat gebruiken dan raad ik aan om echt alleen de "echo" te limiteren.

Diverse 6to4, teredo en 6rd relays kwamen hier hardhandig achter. Dat is natuurlijk inherent een tunnel interface waardoor het aantal PtB berichten veel hoger lag. En 1 gemist PtB bericht betekent een (mogelijk) falende TCP connectie.

[gekkie]

databeestje schreef op donderdag 21 augustus 2014 @ 18:02:
[...]

Rate limiters kan een probleem zijn als je het nummer niet correct uitrekent voor je implementatie.

Zo lijkt 1000pps een mooi getal, maar niet als je > 10k connecties hebt, deze zullen met enige regelmaat PtB gebruiken. Als je een limiter gaat gebruiken dan raad ik aan om echt alleen de "echo" te limiteren.

Diverse 6to4, teredo en 6rd relays kwamen hier hardhandig achter. Dat is natuurlijk inherent een tunnel interface waardoor het aantal PtB berichten veel hoger lag. En 1 gemist PtB bericht betekent een (mogelijk) falende TCP connectie.

Thanks for the pointer .. even wat zoeken en lezen laat zelfs het bestaan van een heuze RFC over ICMP6 filteren zien

[Raven]

Zojuist heb ik in mijn W8.1 VM eens gekeken of IPv6 al werkte. Volgens http://ipv6-test.com/ werkt het wel, maar is er wel een probleem: ICMP wordt gefilterd door de firewall.

Nou heb ik "Bestands- en printerdeling (Echoaanvraag - ICMPv6-In)" op toestaan gezet, zowel bij inkomend als uitgaand en voor beide profielen (prive,openbaar/domein), maar ik krijg alsnog die melding.

Firewall uit en het is goed.

Mis ik nog iets?

edit: ESS er maar opgezet en Windows Firewall ging automatisch uit, nu werkt het goed

[ Voor 9% gewijzigd door Raven op 24-08-2014 12:51 ]

[Verwijderd]

Gezien het tijdstip op de dag, vandaag behoorlijk (relatief) wat IPv6 traffic op de ams-ix
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Niet veel nieuws afgelopen dagen maar misschien na de zomer meer?

[CAPSLOCK2000]

De studenten komen weer thuis en op de universiteit omdat het studiejaar weer gaat beginnen. Die hebben relatief vaak IPv6 en dat heeft duidelijk invloed.

[Maurits van Baerle]

Verwijderd schreef op zondag 24 augustus 2014 @ 18:19:
Gezien het tijdstip op de dag, vandaag behoorlijk (relatief) wat IPv6 traffic op de ams-ix
https://ams-ix.net/techni.../sflow-stats/ipv6-traffic

Niet veel nieuws afgelopen dagen maar misschien na de zomer meer?

Met een piek van 10 Gbps naar een totaal van 35,6 Gbps gisteravond!

[Verwijderd]

Vandaag is het volume van het verkeer ook al weer vroeg hoger dan de afgelopen dagen, mogelijk zijn er nieuwe (grote) netwerken bij gekomen. Misschien is de uitrol bij ziggo gestart.

[elsinga]

Hier zondag op maandag onderhoud gehad, waardoor mijn modem van slag was en het internet een interniet was. Toch nog steeds geen ipv6. Helaas.

[Snow_King]

Wellicht leuk: Snow_King in "SIP telefoons met IPv6 en TLS ondersteuning"

Wij zijn op kantoor bezig om onze SIP telefoons te vervangen en willen de VOIP helemaal IPv6-only gaan draaien. Single stack IPv6 dus.

Kunnen we van alle IPSec en STUN servers af. Ook direct peer-to-peer media, niet meer via de Asterisk server routeren.

[Verwijderd]

Snow_King schreef op vrijdag 29 augustus 2014 @ 10:20:


Kunnen we van alle IPSec en STUN servers af. Ook direct peer-to-peer media, niet meer via de Asterisk server routeren.

En wat voor plannen heb je voor SIP verkeer met IPv4 (soort proxy) ? NAT64/DNS64 ?

Voor een aantal domeinen heb ik afgelopen week IPv6 mailservers beschikbaar gemaakt (postfix) maar heb nog niet (gezocht) gekeken hoe je eenvoudig statistieken eruit haalt om te zien hoevel procent van de mail IPv4 en IPv6 is.

Suggesties iemand?

[ Voor 28% gewijzigd door Verwijderd op 29-08-2014 10:24 ]

[tlpeter]

Snow_King schreef op vrijdag 29 augustus 2014 @ 10:20:
Wellicht leuk: Snow_King in "SIP telefoons met IPv6 en TLS ondersteuning"

Wij zijn op kantoor bezig om onze SIP telefoons te vervangen en willen de VOIP helemaal IPv6-only gaan draaien. Single stack IPv6 dus.

Kunnen we van alle IPSec en STUN servers af. Ook direct peer-to-peer media, niet meer via de Asterisk server routeren.

Leuk maar ik zou dit toch echt zo niet doen.
Op het moment wordt er erg veel gehackt (belkosten genereren) en ook al is het IPv6 dit is gewoon een security issue.
Of begrijp ik het verkeerd en is er wel beveiliging?

[ Voor 4% gewijzigd door tlpeter op 29-08-2014 10:37 ]

[Verwijderd]

tlpeter schreef op vrijdag 29 augustus 2014 @ 10:34:
[...]

Leuk maar ik zou dit toch echt zo niet doen.
Op het moment wordt er erg veel gehackt (belkosten genereren) en ook al is het IPv6 dit is gewoon een security issue.

Ik keek ook even op van het opheffen van VPN tunnels, echter met 2 firewall's en source /destination restricties en daarop nog TLS heb je zo goed als een VPN tunnel.

Daarnaast is het voor intern verkeer, ik las in het topic dat communicatie met de buitenwereld op dit moment nog IPv4 is. Hoewel ik wel de SIP providers aan hun jasje zou trekken met de vraag "Hey, wat zijn jullie IPv6 roadmaps".

[Snow_King]

Verwijderd schreef op vrijdag 29 augustus 2014 @ 10:22:
[...]


En wat voor plannen heb je voor SIP verkeer met IPv4 (soort proxy) ? NAT64/DNS64 ?

Geen. De telefoons praten enkel met elkaar en de PBX.

Verwijderd schreef op vrijdag 29 augustus 2014 @ 10:22:
[...]Voor een aantal domeinen heb ik afgelopen week IPv6 mailservers beschikbaar gemaakt (postfix) maar heb nog niet (gezocht) gekeken hoe je eenvoudig statistieken eruit haalt om te zien hoevel procent van de mail IPv4 en IPv6 is.

Suggesties iemand?

Met een beetje parsen in de logs moet je IPv6 adressen er uit kunnen halen.

tlpeter schreef op vrijdag 29 augustus 2014 @ 10:34:
[...]

Leuk maar ik zou dit toch echt zo niet doen.
Op het moment wordt er erg veel gehackt (belkosten genereren) en ook al is het IPv6 dit is gewoon een security issue.
Of begrijp ik het verkeerd en is er wel beveiliging?

Wat is er niet veilig aan IPv6? Op de PBX sta je enkel connecties toe van een bepaald aantal subnets en op de firewalls op de kantoren sta je enkel verkeer toe van de subnets van de andere kantoren.

Is totaal niet onveilig.

Verwijderd schreef op vrijdag 29 augustus 2014 @ 10:39:
[...]


Ik keek ook even op van het opheffen van VPN tunnels, echter met 2 firewall's en source /destination restricties en daarop nog TLS heb je zo goed als een VPN tunnel.

Daarnaast is het voor intern verkeer, ik las in het topic dat communicatie met de buitenwereld op dit moment nog IPv4 is. Hoewel ik wel de SIP providers aan hun jasje zou trekken met de vraag "Hey, wat zijn jullie IPv6 roadmaps".

Inderdaad, maar we regelen nu het meeste op applicatie laag. Met IPSec heb je met MTU problemen te maken ipv de overhead, waar dat bij TLS makkelijker gaat.

Onze SIP provider heb ik uiteraard ook al betrokken in het verhaal en zij geven aan in Q1 2015 IPv6-ready te zijn.

We gaan eerst in de aankomende maanden onze telefoons vervangen en naar IPv6-only. Dan volgend jaar de PBX op IPv6-only draaien.

[Freeaqingme]

Verwijderd schreef op vrijdag 29 augustus 2014 @ 10:22:
Voor een aantal domeinen heb ik afgelopen week IPv6 mailservers beschikbaar gemaakt (postfix) maar heb nog niet (gezocht) gekeken hoe je eenvoudig statistieken eruit haalt om te zien hoevel procent van de mail IPv4 en IPv6 is.

Suggesties iemand?

Ik gebruik zelf onderstaande one-liners. Is weliswaar op een FreeBSD bak, maar logformat zou nagenoeg 't zelfde moeten zijn op LInux.

To get the number of mails sent via IPv4:

code:

 bzgrep 'status=sent' /var/log/maillog.0.bz2  | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\.' | wc -l

To get the number of mails sent via IPv6:

code:

bzgrep 'status=sent' /var/log/maillog.0.bz2  | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\:' | wc -l

Percentage of IPv6 traffic:

code:

logfile=/var/log/maillog.*.bz2; v4=$(bzgrep 'status=sent' ${logfile}  | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\.' | wc -l); v6=$(bzgrep 'status=sent' ${logfile} | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\:' | wc -l); echo "(${v6}*100)/(${v6}+${v4})" | bc

Percentage of Servers doing IPv6:

code:

 logfile=/var/log/maillog.*.bz2; v4=$(bzgrep 'status=sent' ${logfile}  | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\.' | sort | uniq | wc -l); v6=$(bzgrep 'status=sent' ${logfile} | awk '{print $8}' | cut -d ']' -f1 | cut -d'[' -f2 | grep '\:' | sort | uniq | wc -l); echo "(${v6}*100)/(${v6}+${v4})" | bc

Op dit moment gaat 60% van de email bij ons over IPv6 naar buiten, en van alle servers waar we mail naartoe versturen is 16% bereikbaar over IPv6.

[CyBeR]

Inkomend bij mij:

# IPv6
root@mailsrv01:/var/log/exim4# zgrep '<=' mainlog mainlog.[123456].gz| grep '\[2...:' | awk '{ print $3 }' | sort | uniq | wc -l
4267

# Totaal
root@mailsrv01:/var/log/exim4# zgrep '<=' mainlog mainlog.[123456].gz | awk '{ print $3 }' | sort | uniq | wc -l
28195

[Lord Anubis]

Helaas nog niet alle 151 pagina's kunnen lezen, maar ben op zoek naar leesvoer m.b.t het volgende.

Internet of Things.
Zit bij XS4ALL e.a
Heb nu al wat Things draaien op enkele locaties en wat servers. Ik wil eigenlijk ( mijn eigen ) een vast IPv6 incl /64 of /48 space, waar ik al mijn zaakjes heb rondhangen of ze nu hier thuis, op de zaak of waar dan ook op het netwerk zitten.

Is hier leesvoer over? Of iemand die er ervaring mee heeft?

Gerelateerde vraag, in hoeverre is mijn IPv6 adres static bij XS4ALL en kan ik een sub range ergens anders gebruiken?

[FatalError]

Bij XS4ALL is je IPv6 /48 blokje net zo vast als je IPv4 adres.
Je kan prima een deel 'vast' configureren op bepaalde apparaten of zelfs een deel via een VPN naar een andere lokatie transporteren.

[Lord Anubis]

Zo werkt het nu, maar ik wil straks weinig cofigureren, dan alleen mijn eigen IPv6 range.
Ik zet mijn IP in mijn MCU, Rasp PI of device en het moet alleen praten in eigen subnet, waar ook ter wereld.

[CAPSLOCK2000]

Dan heb je Mobile IPv6 nodig, maar daar is nog zo weinig support voor dat je er niet van uit moet gaan dat het in het wild werkt. Erg veilig lijkt het me ook niet.

[Lord Anubis]

O, dus nog even geduld hebben? Wel al een goed artikel voor me?

[databeestje]

Je kan natuurlijk ook een /48 van HE.net met een tunnel en een dynamisch IP adres overal mee naartoe slepen.

Daarnaast gebruik ik NAT NPt voor als ik af en toe de Leaseweb prefix gebruik. (SIXXS)

[dion_b]

Zo, mooi voorbeeldje van hoe stiekem veel van het internet al op v6 over is: m'n HTPC/server bleek gisteren niet benaderbaar op IP(v4). Vandaag even uitgezocht: geen v4-adres, wel publiek v6. Kwam geheid door gekloot aan m'n router begin vorige week. Even sudo dhclient eth0 gedraaid en het was opgelost. Maar in de tussentijd helemaal niets van gemerkt, ondanks gebrek aan v4 connectivity

[Snow_King]

dion_b schreef op maandag 01 september 2014 @ 21:46:
Zo, mooi voorbeeldje van hoe stiekem veel van het internet al op v6 over is: m'n HTPC/server bleek gisteren niet benaderbaar op IP(v4). Vandaag even uitgezocht: geen v4-adres, wel publiek v6. Kwam geheid door gekloot aan m'n router begin vorige week. Even sudo dhclient eth0 gedraaid en het was opgelost. Maar in de tussentijd helemaal niets van gemerkt, ondanks gebrek aan v4 connectivity

De 'grote jongens' zijn al een tijdje prima bereikbaar via IPv6, het zijn helaas de veel kleinere diensten die het nog lang niet op orde hebben.

Al zouden Microsoft en Twitter ook eens bereikbaar moeten worden via IPv6!

[Maurits van Baerle]

Snow_King schreef op dinsdag 02 september 2014 @ 10:52:
[...]
De 'grote jongens' zijn al een tijdje prima bereikbaar via IPv6, het zijn helaas de veel kleinere diensten die het nog lang niet op orde hebben.

Al zouden Microsoft en Twitter ook eens bereikbaar moeten worden via IPv6!

Inderdaad, er zitten nog best veel witte gaten in Microsofts IPv6 ondersteuning: IPv6 Support in Microsoft Products and Services.

Ik zou zelf bijvoorbeeld graag eindelijk IPv6 ondersteuning in Azure willen zien.

[CAPSLOCK2000]

Bij ons is Azure afgevallen vanwege het gebrek aan IPv6.

[Maurits van Baerle]

Wij zitten nu nog op Azure maar als er volgend jaar nog steeds geen IPv6 beschikbaar is zullen we moeten uitkijken naar een ander platform.

[Verwijderd]

Snow_King schreef op dinsdag 02 september 2014 @ 10:52:

Al zouden Microsoft en Twitter ook eens bereikbaar moeten worden via IPv6!

Microsofts BING deed mee met de world IPv6 launch, dus zou via IPv6 bereikbaal blijven, helaas is dat op dit moment niet meer het geval, erg jammer.

Het is verdomd moeilijk zoeken naar Twitter en IPv6 plannen je krijgt steeds verkeerde resultaten.

Wel zag ik dat linkedin een week? geleden aan het testen was, ik heb daarna ook wat van de top NL sites in mijn monitoring gegooid zodat ik een seintje krijg wanneer een van deze sites via IPv6 bereikbaar is geworden. Hetzelfde voor een aantal grote providers.

Wat me opviel is dat een redelijk deel cnames gebruikt en naar een cdn verwijst en dat zelfs bij een bank.... gelukkig dan weer niet op de inlog gedeeltes.

[ Voor 9% gewijzigd door Verwijderd op 03-09-2014 05:11 ]

[Raven]

Stuur een feature request naar https://twitter.com/feedback ? Heb daar IPv6 onlangs al eens gemeld.

[CAPSLOCK2000]

Twee pixels!
Dagenlang fanatiek op F5 drukken heeft dan eindelijk een tweede pixel opgeleverd voor IPv6 over de AMSIX.



Het ging sowieso wel lekker de afgelopen dagen, maar ook IPv4 groeit enorm aan het begin van het schooljaar.



Maar IPv6 groeit dus harder.

[Verwijderd]

Ik ben niet zo bang voor de groei, als ik kijk naar de klachten online (bv twitter) en diverse fora dan wordt IPv6 redelijk gebruikt en komen er allerlei bugs naarvoren. Dat is goed nieuws en ook te verwachten in de aanloop.

In NL is niet veel meer nodig dan een UPC en een ZIGGO om een grote omslag te maken. Data volume welliswaar want dat is waar vooral naar gekeken wordt. Bijvoorbeeld in bandbreedte naar Youtube en Netflix.

[begintmeta]

En Ziggo schrijft nog steeds op de website dat het in 2014 gaat gebeuren

[Snow_King]

begintmeta schreef op woensdag 03 september 2014 @ 16:05:
En Ziggo schrijft nog steeds op de website dat het in 2014 gaat gebeuren

Laten we het vooral hopen!

De vooruitzichten zien er vooralsnog goed uit. Op de NLUUG meeting eerder dit jaar (Mei) zei een Ziggo engineer nog tegen me dat IPv6 er dit jaar komt.

[Raven]

Ligt het aan mij of doet de nieuwe berichten-indicator het niet meer in dit topic?

[CAPSLOCK2000]

Raven schreef op woensdag 03 september 2014 @ 18:00:
Ligt het aan mij of doet de nieuwe berichten-indicator het niet meer in dit topic?

Zeker geen IPv6.

[ Voor 4% gewijzigd door CAPSLOCK2000 op 03-09-2014 18:09 ]

[Raven]

In andere topics doet ie, maar hier om de een of andere reden niet meer. Heb een 2e tab met dit topic en daar staat geen melding van dit, jouw en mijn vorige bericht.

[Verwijderd]

Maurits van Baerle schreef op maandag 18 augustus 2014 @ 17:53:
[...]


[...]

Vandaag een mailtje terug gekregen van Zeelandnet en ze hebben zich nu aangemeld. Even kijken wanneer ze verschijnen...

Ik zag ze helaas nog niet op http://www.worldipv6launch.org/author/fordisoc-org/

[Verwijderd]

En nu is ook linkedin IPv6 na de test recent.

http://engineering.linkedin.com/ipv6/permanent-launch-ipv6

[Raven]

.... en gelijk slaat de beveiliging daar op tilt:

Hi * Raven ,


We noticed someone just tried to sign in to your LinkedIn account from a location you haven't used before, so we want to make sure it's really you.

[Tales]

Het lijkt er op dat UPC nu eindelijk eens gaat beginnen met IPv6, echter eerst nog een test onder klanten. Ben benieuwd of de eindimplementatie er ook zo uit zal gaan zien. https://www.chelloo.com/upc/index.php?topic=53541.0

[Orion84]

Interessant, ze leggen de noodzaak voor een firewall dus bij de endpoints van de klant neer, in plaats van een firewall in de modemrouter die alleen related/established toestaat. Ben benieuwd of dat alleen bij deze test is, of dat dat is wat ze ook voor de uiteindelijke uitrol in gedachten hebben...

[JackBol]

Orion84 schreef op dinsdag 09 september 2014 @ 15:38:
Interessant, ze leggen de noodzaak voor een firewall dus bij de endpoints van de klant neer, in plaats van een firewall in de modemrouter die alleen related/established toestaat.

Waarom zou een provider moeten bepalen welk inbound traffic door moet komen?

[CyBeR]

JackBol schreef op dinsdag 09 september 2014 @ 15:58:
[...]


Waarom zou een provider moeten bepalen welk inbound traffic door moet komen?

Op zich ondersteun ik dat idee wel maar ik denk toch dat een default-deny firewall verstandiger is. Moet wel in te stellen zijn uiteraard. En ik denk dat in deze test ze die stap inderdaad overgeslagen hebben.

[databeestje]

CyBeR schreef op dinsdag 09 september 2014 @ 16:03:
[...]


Op zich ondersteun ik dat idee wel maar ik denk toch dat een default-deny firewall verstandiger is. Moet wel in te stellen zijn uiteraard. En ik denk dat in deze test ze die stap inderdaad overgeslagen hebben.

Default deny zonder aanpas mogelijkheid wordt een drama. Maar standaard open is dan ook weer een probleem. We missen echt de capable uPNP laag die dit op IPv4 gemakkelijk maakt.

Wellicht een compromis als default Deny op 22,25,80,137-139,443,445 ter bescherming van de mensen een mooie bescherming tegen exploitatie van de standaard NAS e.d.

Je kan lang en breed argumenteren over hoeveel en welke poorten, maar dingen zoals p2p, chat en filesharing werkt dan zonder al te veel problemen.

Lijkt me een beetje raar om die verantwoordelijkheid bij de provider neer te leggen. Als ik de PC rechtstreeks aan mijn kabelmodem aansluit krijg ik ook een ongefiltered publiek IP adres. Waarom is dit ineens zo bijzonder? Ze gebruiken de wifi router alleen maar als verkoop argument voor de schrale batsen die geen knappe router willen kopen.

Om maar niet te beginnen over het vastzitten aan beperkte apparatuur van alles-in-een kabelmodem-routers-wifi ondingen.

[Paul]

databeestje schreef op dinsdag 09 september 2014 @ 16:18:
Als ik de PC rechtstreeks aan mijn kabelmodem aansluit krijg ik ook een ongefiltered publiek IP adres. Waarom is dit ineens zo bijzonder? Ze gebruiken de wifi router alleen maar als verkoop argument voor de schrale batsen die geen knappe router willen kopen.

Bij UPC misschien, maar bijvoorbeeld Ziggo niet, daar zit de wifi-router bij het kabelmodem in. Als je het Ziggo-modem in bridge laat zetten verlies je functionaliteit (waaronder het gebruik van het landelijke 'Ziggo'-SSID en sowieso je lokale AP).

Veel andere providers staan een 'knappe router' al helemaal niet toe, je moet en zult de Experiabox gebruiken...

Bij vrijwel alle gebruikers doet het apparaat dat je standaard bij je levering krijgt out of the box al NAT, en 'dus' (eigenlijk als side-effect) inbound firewalling. Om dan op IPv6 ineens alles open te zetten is dus een grotere change dan er een established, related-firewall bij aan te zetten. In plaats van alleen IPv4-sites kun je ook IPv6-sites bezoeken, maar behalve dat kan men ineens ook zomaar direct verbinden met je lokale device. Met IPv4 moest je daar (in 99,99% van de thuissituaties) zelf iets voor doen... En dan heb ik het nog niet over smartphones, tablets en consoles, hoe je daar ooit fatsoenlijk een firewall op kunt krijgen (en managen) weet ik vooralsnog niet.

Tot zover het technische gedeelte, dan het menselijke: 80% van de thuisgebruikers weet niet eens hoe ze het op hun PC aan moeten zetten of beheren, en omdat we 'verwend' (?) zijn met IPv4-NAT zal die firewall vaak het eerste zijn wat uit is gezet door een 'handig neefje' wanneer er een probleem is.

Ik moet bekennen dat ik niet weet hoe Windows 7 of 8 daar met IPv6 precies mee omgaat maar de meeste mensen zullen thuis 'thuisnetwerk' aanklikken als Windows vraagt wat er mee moet, en dus staan er al heel veel exclusions in de Windows Firewall, en ik heb daar eigenlijk nog nooit een beperking op gezien qua hosts (waar met name Server 2003 de remote desktop-poort nog graag alleen voor 'LocalSubnet' open zette).

Ik zie dus eigenlijk best grote bezwaren tegen het niet standaard filteren van inbound verkeer...

[CyBeR]

databeestje schreef op dinsdag 09 september 2014 @ 16:18:
[...]
Lijkt me een beetje raar om die verantwoordelijkheid bij de provider neer te leggen. Als ik de PC rechtstreeks aan mijn kabelmodem aansluit krijg ik ook een ongefiltered publiek IP adres. Waarom is dit ineens zo bijzonder?

Dat was vroeger zo maar tegenwoordig leveren ze om de een of andere reden routers ipv bridges. Waarschijnlijk omdat vroeger 1 aansluiting = 1 computer (en in die veronderstelling hebben de kabeltoko's erg lang geleefd.) Tegenwoordig gaat die vlieger niet op en dan is 't makkelijker (== minder support-telefoontjes) om een router mee te leveren.

[Maurits van Baerle]

Op OpenWRT.org is er op de devel list een mooie discussie over geweest afgelopen zomer over of de IPv6 firewall in hun nieuwe release standaard aan moet staan. Hij is hier al wel eens eerder gepost.

Aan de ene kant mensen die zeggen dat geen enkele IPv6 firewall standaard aan hebben gevaarlijk is. Vrijwel iedereen die een IPv4 NAT gewend is (al helemaal de doorsnee consument) verwacht even veilig te zijn achter IPv6 als achter IPv4. Zij pleiten voor een default-deny op alle IP's en poorten (tenzij het related-established is natuurlijk).

Aan de andere kant mensen die zeggen dat dankzij IPv6 het internet eindelijk gebruikt kan worden zoals het bedoeld was met directe verbindingen. Zij pleiten voor firewalls op afzonderlijke devices en niet in de router. Zij zijn bang dat uitgerekend mensen die geen kaas hebben gegeten van netwerken ook niet zullen weten hoe je een IP/Poort open zet. De voordelen zijn dan dat complexere zaken als VOIP etc. eindelijk fatsoenlijk out-of-the-box werken.

Een aardig compromis dat nog is genoemd is een default deny op alle poorten onder 1024 maar daarboven standaard niet filteren.

Ik vind voor alle drie wel iets te zeggen hoewel ik enigszins neig naar het eerste standpunt.

[Maurits van Baerle]

Overigens, ik vermoed dat UPC en Ziggo uiteindelijk (bij de definitieve implementatie) wel zullen kiezen voor een default-deny op alles. Dan verandert er voor de consument eigenlijk merkbaar niets. Dat scheelt ze veel support gedoe en geïnfecteerde klanten met vervelende bots.

Een groter probleem lijkt me dat het DS-Lite is en klanten dus geen volwaardig IPv4 adres meer hebben in deze UPC proef. Dat gaat een reeks klachten van testers met XBOX360s etc. opleveren.

[Tales]

Maurits van Baerle schreef op dinsdag 09 september 2014 @ 17:13:
Overigens, ik vermoed dat UPC en Ziggo uiteindelijk (bij de definitieve implementatie) wel zullen kiezen voor een default-deny op alles. Dan verandert er voor de consument eigenlijk merkbaar niets. Dat scheelt ze veel support gedoe en geïnfecteerde klanten met vervelende bots.

Een groter probleem lijkt me dat het DS-Lite is en klanten dus geen volwaardig IPv4 adres meer hebben in deze UPC proef. Dat gaat een reeks klachten van testers met XBOX360s etc. opleveren.

Ze geven het duidelijk aan dat dit het geval is, je krijgt er ook een tweede modem bij tijdens de test welke de IPv6 opstelling zal draaien.

Echter is het natuurlijk de vraag of UPC ook in productie straks zal kiezen voor een DS-Lite omgeving.

[Verwijderd]

In de testfase alles maar opengooien, als er een extra modem komt en het verzoek aan de klant is zelf firewalling te regelen (zo expliciet lees ik dat overigens niet) dan lijkt me dat OK.

Op dit moment denk ik niet dat ze op de "standaard" thuis gebruiker wachten maar eerder wat technisch onderlegde mensen. Maar dat kan ik mishebben.

Ik zou zeggen "doe mij maar IPv6 ongefilterd" dan doe ik zelf de rest wel en hoor je me wel als ik rare dingen tegenkom. Dan bedoel ik natuurlijk niet dat mijn Xbox het niet doet maar dat ik rare routing of onverwachte packet loss zie.

[CAPSLOCK2000]

Als IPv6 betekent dat je geen "echt" IPv4-adres meer krijgt maar het met NAT moet doen zal dat een hoop weerstand tegen IPv6 oproepen. Ik hoop dus niet dat ze dat doen. Ik verwacht wel dat dit in de toekomst ooit al gebeuren. Er komt een moment dat er een enorm tekort aan IPv4-adressen is en/of dat IPv4 niet meer belangrijk is. Op dat moment zullen steeds meer mensen achter NAT verdwijnen. Ik hoop (en denk) wel dat dit nog lang zal duren en we eerst rustig IPv6 kunnen invoeren.

[Verwijderd]

CAPSLOCK2000 schreef op dinsdag 09 september 2014 @ 17:54:
Als IPv6 betekent dat je geen "echt" IPv4-adres meer krijgt maar het met NAT moet doen zal dat een hoop weerstand tegen IPv6 oproepen. Ik hoop dus niet dat ze dat doen. Ik verwacht wel dat dit in de toekomst ooit al gebeuren. Er komt een moment dat er een enorm tekort aan IPv4-adressen is en/of dat IPv4 niet meer belangrijk is. Op dat moment zullen steeds meer mensen achter NAT verdwijnen. Ik hoop (en denk) wel dat dit nog lang zal duren en we eerst rustig IPv6 kunnen invoeren.

Van de IPv6 transitie mogelijkheden ben ik ook het minst voorstander van DS-lite. Los van dat zag ik talloze klachten van UPC gebruikers in Duitsland en Tsjechie? dat ze niet meer bij hun thuis ip cam of nas konden. Dat was dus een goede demostratie van wat we zeker niet willen zien.

Ik hoop dat de ISP's die DS-lite toepassen mensen wel een statisch IPv6 range toewijzen zodat de apparaten van de afgelopen jaren in iedergeval via een eigen domein of ddns oplossing te bereiken zijn mits genoeg andere providers (je bent immers niet thuis als je bij die systemen wilt) ook IPv6 gaan aanbieden.

De tijd zal het leren, ik ben in iedergeval ondanks de mankementen blij met deze volgende stap in de uitrol in plaats van "dit jaar" en later "dat" jaar "volgend jaar".

[Orion84]

Paul schreef op dinsdag 09 september 2014 @ 16:34:
[...]
Bij UPC misschien, maar bijvoorbeeld Ziggo niet, daar zit de wifi-router bij het kabelmodem in.

Mits je recent een nieuw modem hebt gehad. Mijn ouders bijvoorbeeld hebben nog een Ubee zonder (wifi-)router functie.

Verwijderd schreef op dinsdag 09 september 2014 @ 17:45:
In de testfase alles maar opengooien, als er een extra modem komt en het verzoek aan de klant is zelf firewalling te regelen (zo expliciet lees ik dat overigens niet) dan lijkt me dat OK.

Op dit moment denk ik niet dat ze op de "standaard" thuis gebruiker wachten maar eerder wat technisch onderlegde mensen. Maar dat kan ik mishebben.

Dat zou inderdaad heel goed kunnen, al ben je dan dus wel een afwijkende setup aan het testen, maar voor het deel dat ze willen testen is dat wellicht al nuttig genoeg. Sowieso wijkt de setup nogal af van de eindsituatie denk ik.

CAPSLOCK2000 schreef op dinsdag 09 september 2014 @ 17:54:
Als IPv6 betekent dat je geen "echt" IPv4-adres meer krijgt maar het met NAT moet doen zal dat een hoop weerstand tegen IPv6 oproepen. Ik hoop dus niet dat ze dat doen. Ik verwacht wel dat dit in de toekomst ooit al gebeuren. Er komt een moment dat er een enorm tekort aan IPv4-adressen is en/of dat IPv4 niet meer belangrijk is. Op dat moment zullen steeds meer mensen achter NAT verdwijnen. Ik hoop (en denk) wel dat dit nog lang zal duren en we eerst rustig IPv6 kunnen invoeren.

Ik mag hopen dat dit ook enkel voor die test is en (net als het firewall aspect) geen voorbode is van hoe de uiteindelijke Dual Stack oplossing er uit gaat zien. Tegen de tijd dat een groot deel van de wereld IPv6 capable is zou zo'n setup nog wel een optie zijn, voor de beperkte momenten waarop je nog IPv4 nodig hebt, maar tot die tijd hoop ik toch wel gewoon een volwaardig IPv4 adres te krijgen.

[Verwijderd]

Orion84 schreef op dinsdag 09 september 2014 @ 17:59:

Dat zou inderdaad heel goed kunnen, al ben je dan dus wel een afwijkende setup aan het testen, maar voor het deel dat ze willen testen is dat wellicht al nuttig genoeg. Sowieso wijkt de setup nogal af van de eindsituatie denk ik.

Nu ken ik de situatie bij UPC niet nog wat ze precies willen testen maar om de keten na de point of access (home connection) door te testen en eventueel dingen te testen met switches / routing / peering / failovers mbt de NL infra, zou dit een valide en goede test kunnen zijn.

Tuurlijk kunnen ze dit ook met wat UPC medewerkers thuis testen, echter de groep (NL) van medewerkers bereid hier toe, met kennis van IPv6 en represenatief zou toch beperkt zijn. Even daargelaten dat ze ervaring hebben in DE en CZ waar ze aan het uitrollen zijn. Ik hoop dat Ziggo ook een status update geeft binnenkort, gezien hun statement "eind 2014".

[Osiris]

Tales schreef op dinsdag 09 september 2014 @ 15:27:
Het lijkt er op dat UPC nu eindelijk eens gaat beginnen met IPv6, echter eerst nog een test onder klanten. Ben benieuwd of de eindimplementatie er ook zo uit zal gaan zien. https://www.chelloo.com/upc/index.php?topic=53541.0

Wat een achterlijke uitspraak staat er in

"Android ondersteunt vooralsnog geen IPv6 en is derhalve veilig."

Android ondersteunt sowieso via WiFi sinds versie 4 SLAAC IPv6-adressering. Sure, het is niet volledig, DHCPv6 en ND-RDNSS zijn stuQ, maar dan nog. Zeggen dat 't niet ondersteund wordt is wel erg kortzichtig.

[Maurits van Baerle]

Osiris schreef op dinsdag 09 september 2014 @ 18:09:
[...]

Wat een achterlijke uitspraak staat er in

"Android ondersteunt vooralsnog geen IPv6 en is derhalve veilig."

Android ondersteunt sowieso via WiFi sinds versie 4 SLAAC IPv6-adressering. Sure, het is niet volledig, DHCPv6 en ND-RDNSS zijn stuQ, maar dan nog. Zeggen dat 't niet ondersteund wordt is wel erg kortzichtig.

Er staat wel meer in wat een beetje kort door de bocht is. iOS heeft op IPv4 en IPv6 een soort applicatiefirewall die standaard op default-deny staat tenzij die betreffende app iets open zet of verbinding met buiten legt.

[Maurits van Baerle]

CAPSLOCK2000 schreef op dinsdag 09 september 2014 @ 17:54:
Als IPv6 betekent dat je geen "echt" IPv4-adres meer krijgt maar het met NAT moet doen zal dat een hoop weerstand tegen IPv6 oproepen. Ik hoop dus niet dat ze dat doen. Ik verwacht wel dat dit in de toekomst ooit al gebeuren. Er komt een moment dat er een enorm tekort aan IPv4-adressen is en/of dat IPv4 niet meer belangrijk is. Op dat moment zullen steeds meer mensen achter NAT verdwijnen. Ik hoop (en denk) wel dat dit nog lang zal duren en we eerst rustig IPv6 kunnen invoeren.

Er zijn op zich ook andere transitiemodellen. Mijn eigen ISP (BT) is aan het experimenteren met CGNAT, ik vermoed als voorportaal voor DS-Lite. Het is opt-out dus er is een kans dat je soms of ineens achter CGNAT zit, tenzij je je expliciet afmeld hiervoor via een simpele webinterface.

In de praktijk betekent dat dat ze straks CGNAT in kunnen zetten als de nood aan de man is (ineens ergens een IPv4 tekort hebben) maar dat powerusers het kunnen voorkomen. Verreweg de meeste gewone gebruikers zullen er weinig van merken denk ik. En mocht iemand met een XBOX360 de helpdesk bellen kunnen die een verbinding aan de opt-out toevoegen.

[ Voor 4% gewijzigd door Maurits van Baerle op 09-09-2014 19:03 ]

[DJSmiley]

Maurits van Baerle schreef op dinsdag 09 september 2014 @ 18:35:
[...]

Er zijn op zich ook andere transitiemodellen. Mijn eigen ISP (BT) is aan het experimenteren met CGNAT, ik vermoed als voorportaal voor DS-Lite. Het is opt-out dus er is een kans dat je soms of ineens achter CGNAT zit, tenzij je je expliciet afmeld hiervoor via een simpele webinterface.

In de praktijk betekent dat dat ze straks CGNAT in kunnen zetten als de nood aan de man is (ineens ergens een IPv4 tekort hebben) maar dat powerusers het kunnen voorkomen. Verreweg de meeste gewone gebruikers zullen er weinig van merken denk ik. En mocht iemand met een XBOX360 de helpdesk bellen kunnen die een verbinding aan de opt-out toevoegen.

CGNAT zal idd steeds meer voorkomen. In NL hoor je er nog weinig over, maar (bv) KickXL heeft (of had?) dit wel in gebruik...

KickXL en Portforwarding]

Wat wel zou kunnen is dat straks de budgetabbo's achter CGN komen. Tenslotte is voor heel veel mensen dat geen punt, die doen niet veel meer dan surfen en mailen. Vanuit provideroogpunt is het geen gekke keuze om mensen die een eigen IPv4 adres nodig hebben om die een (sneller/duurder) abbonement te laten nemen...

[Verwijderd]

Ik snap je redenatie maar het is ook niet dat een IPv4 adres in NL onbetaalbaar is. Afwegend tegen verschil in ondersteuning van je klanten.

Zelf ben ik voorstander van IPv6 in tegenstelling tot wat netwerk collega's die er niets van willen weten. Meer zie ik in oplossingen als xlat dat de endpoints eventueel iets simuleren als proxy voor app's die nog IPv4 willen maar dat het vanaf het end-point tot de rest van de wereld IPv6 is.

[CAPSLOCK2000]

Verwijderd schreef op dinsdag 09 september 2014 @ 19:09:
Ik snap je redenatie maar het is ook niet dat een IPv4 adres in NL onbetaalbaar is. Afwegend tegen verschil in ondersteuning van je klanten.

Een paar adressen gaat nog wel, maar als je een nieuwe ISP of telefoonprovider wil oprichten dan heb je toch wel een probleem.