Het grote IPv6 topic

[Raven]

Vandaag iets vaags gehad. Op een pc ESET Smart Security zo ingesteld* dat ie ook uitgaande verbindingen blocked maar wel vraagt of een app wel verbinding mag maken met de buitenwereld. Dat ging goed.
(*De interactieve modus dus ipv automatische.)

Maar de IPv6 tunnel kon ineens niet meer gebruikt worden Dacht eerst dat het aan ESET lag, omdat het precies na het veranderen van het gedrag van de firewall optrad, bleek dat niet het geval. Andere pc had het ook. Gekke was, router kon gewoon van de tunnel gebruik maken (pingen naar buiten lukte) en de pc's kregen een IPv6 toegewezen. Verder niks raars gezien.

Toen de 2 scripts die ik gebruik om pfSense van de HE-tunnel te voorzien weer uitgevoerd en nu werkt het weer. Vaag

[ Voor 3% gewijzigd door Raven op 02-09-2011 21:57 ]

[Brahiewahiewa]

Heeft er iemand een he.net tunnel werkend gekregen met een Draytek Vigor 2130?
Zo ja: hoe?
Ik krijg de volgende errors in het syslog (onderaan beginnen):

Sep  6 02:38:38 info user : TSP session done 
Sep  6 02:38:38 info user : Error is 1: TSP_ERROR 
Sep  6 02:38:38 info user : template must be specified! 
Sep  6 02:38:38 info user : if_tunnel_v6v4 must be specified! 
Sep  6 02:38:38 info user : if_tunnel_v6udpv4 not specified, forcing tunnel_mode to v6v4. 
Sep  6 02:38:38 info user : server must be specified! 
Sep  6 02:38:38 info user tspc:  tspMain: TSP session done 
Sep  6 02:38:38 err user tspc:  tspMain:  Error is 1: TSP_ERROR 
Sep  6 02:38:38 err user tspc:  tspVerifyConfig: template must be specified! 
Sep  6 02:38:38 err user tspc:  tspVerifyConfig: if_tunnel_v6v4 must be specified! 
Sep  6 02:38:38 err user tspc:  tspVerifyConfig: if_tunnel_v6udpv4 not specified, forcing tunnel_mode to v6v4. 
Sep  6 02:38:38 err user tspc:  tspVerifyConfig: server must be specified! 
Sep  6 02:38:38 info user : Try to start program : tspc.... 

Ik heb voor de server-url zowel het IP4-adres (216.66.84.46) als de volledige fdqn (brahiewahiewa-1.tserv11.ams1.ipv6.he.net) geprobeerd. Zowel met als zonder userID/password

[Verwijderd]

Afaik doet die 2130 alleen 6to4, AICCU (SixXS meuk) en TSPC. Geen simpele 6in4 static proto-41 tunnel (wat HE gebruikt). Vond ik ook al een beetje vaag...

[Raven]

Hier vandaag iets vaags tegengekomen.

Als ik met IPv6 enabled (onder XP) met Outlook probeer te werken kan deze wél testmails versturen maar e-mails ophalen kan niet vanaf de emailserver van eigen domeinnaam, de 0x800ccc0f fout.

Bij taak 'servernaam - Verzenden en ontvangen' is een fout opgetreden (0x800ccc0f): 'De verbinding met de server is onderbroken. Als het probleem blijft bestaan, neemt u contact op met de serverbeheerder of internetprovider (ISP).'

Telnet naar de emailserver via cmd werkt ook niet (knipperende underscore), maar vanaf mijn pfSense router wél Host ziet mijn ip niet in de logboeken voorbij komen, dus het gaat aan deze kant mis lijkt het.
IPv6 uninstall en Outlook werkt meteen normaal.

edit: Telnet onder 7, met de firewall in interactieve modus, laat zien dat telnet eerst via IPv6 probeert verbinding te maken en een paar sec later met IPv4 dat wél lukt.
Waarom kapt XP ermee als er geen antwoord is via IPv6?

edit2: Host heeft teruggemailt, bleek dat de SMTP server wél luisterde naar IPv6 maar de POP3/IMAP server niet, dat is nu gefixed .

Blijft de vraag waarom XP niet IPv4 probeerde nadat het via IPv6 niet lukte.

[ Voor 36% gewijzigd door Raven op 08-09-2011 11:00 ]

[Brahiewahiewa]

Verwijderd schreef op dinsdag 06 september 2011 @ 11:50:
Afaik doet die 2130 alleen 6to4, AICCU (SixXS meuk) en TSPC. Geen simpele 6in4 static proto-41 tunnel (wat HE gebruikt). Vond ik ook al een beetje vaag...

Da's duidelijk. Heb ondertussen gevonden dat je via telnet dit kunt doen:

ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 83.87.0.xxx ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f14:yyyy::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

Maar nu moet ik nog m'n router advertisement voor 2001:470:1f15:yyyy::/64 voorelkaar krijgen.
RADVD zegt: can't open /etc/radvd.conf: No such file or directory
terwijl-ie wel draait (althans volgens de web-gui).

[Verwijderd]

Brahiewahiewa schreef op donderdag 08 september 2011 @ 16:54:
[...]

Da's duidelijk. Heb ondertussen gevonden dat je via telnet dit kunt doen:

ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 83.87.0.xxx ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f14:yyyy::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

Maar nu moet ik nog m'n router advertisement voor 2001:470:1f15:yyyy::/64 voorelkaar krijgen.
RADVD zegt: can't open /etc/radvd.conf: No such file or directory
terwijl-ie wel draait (althans volgens de web-gui).

Wat staat er in je /etc/radvd.conf?
Heeft die Draytek 2130 echt iproute2 (die "ip"-commando's)? Dat is dan nieuw voor mij

(heb hem zelf niet persoonlijk in bezit overigens)

[ Voor 3% gewijzigd door Verwijderd op 08-09-2011 19:51 ]

[Brahiewahiewa]

Verwijderd schreef op donderdag 08 september 2011 @ 19:45:
[...]

Wat staat er in je /etc/radvd.conf?
Heeft die Draytek 2130 echt iproute2 (die "ip"-commando's)? Dat is dan nieuw voor mij

(heb hem zelf niet persoonlijk in bezit overigens)

Nou, niks dus. De file bestaat niet; gecheckt met putty.
Vermoed dat de router RADVD opstart met een hele reeks commandline options.

En ja, die Draytek heeft iproute2 commando's sinds firmware 1.4.0

[databeestje]

Heeft iemand nog recentelijk iets vernomen van Ziggo met betrekking tot IPv6?

[Raven]

https://www.ziggo.nl/#ent...uwe-internetprotocol-ipv6
"Naar verwachting ondersteunt Ziggo medio 2012 het IPv6 protocol voor haar klanten, die een juiste huisinstallatie hebben."

[Roetzen]

Wel, wel, kijk eens aan. Eindelijk wordt de stilte bij Ziggo doorbroken. Beter laat dan nooit.

[Verwijderd]

KPN, iemand toevallig meer informatie? Misschien zelfs betrokken bij een testtraject?

[databeestje]

De zaak staat op de lijst voor een testtraject, v6 peering was overigens niet mogelijk met mogelijke uitzondering via het eurorings netwerk. Wel van de KPN maar niet echt voor de (zakelijke) userbase.

De partijen die via het reseller kanaal van de KPN afnemen hebben wel v6 mogelijk via dat eurorings netwerk.

Nog geen antwoord gehad wanneer onze native of tunneled v6 geschakeld kan worden op ons corporate internet. Het zal wel nieuw jaar worden op zijn vroegst.

[CyBeR]

Interessant dat KPN en Ziggo ongeveer dezelfde termijn hanteren.

[Jaap-Jan]

Nog interessanter dat Ziggo deze 'urban myth' aanhaalt:

quote: https://www.ziggo.nl/#ent...uwe-internetprotocol-ipv6

Oorspronkelijk dacht men dat er met Internet Protocol Versie 4 (IPv4) genoeg adressen waren. Het protocol is in 1980 ontwikkeld en toen voorzag niemand dat het aantal internetprogramma's zoals video, e-mail en chat zo gigantisch zou groeien. IPv4 heeft in totaal 3,7 miljard unieke adressen.

De eerste aanzet voor IPv6 (toen nog bekend als IPng) dateert al van 1992, ruim voordat het internet echt mainstream begon te worden in huis:

quote: http://ipv6forum.com.au/timeline.php

1992 Mar: IETF calls for proposal for next generation IP. Rejects calls from IAB to adopt ISO CLNP

De daadwerkelijke reden dat de implementatie van IPv6 zo lang duurde kwam doordat zo'n beetje alle ISP's IPv6 compleet genegeerd hebben tot nu toe. In 2002 (9 jaar geleden!) was xs4all al bezig met experimenteren met IPv6.

---

Maar het allerinteressantste is dat Ziggo terugkomt op hun ridicule besluit (zie update met reactie van Gradus Vos) om IPv6 eerst alleen bij nieuwe klanten uit te rollen.

[ Voor 14% gewijzigd door Jaap-Jan op 10-09-2011 19:58 ]

[fagao]

Maar het allerinteressantste is dat Ziggo terugkomt op hun ridicule besluit (zie update met reactie van Gradus Vos) om IPv6 eerst alleen bij nieuwe klanten uit te rollen.

Het probleem vaak is dat het Modem of router bij de klant nog niet geschikt is. Daarom dat het makkelijk is om bij nieuwe klanten uit te rollen, dan bij bestaande.

Solcon heeft trouwens ook al sinds 2002 IPv6 in haar netwerk geconfigureerd. Bovendien is Solcon ook druk bezig om IPv6 aan klanten te gaan aanbieden.

Voor een partij als KPN/Ziggo is het vaak redelijk omvangrijk om zo maar even IPv6 uit te rollen. Ik verwacht dat IPv6 binnen het bedrijf gewoon geen extreem hoge prioriteit heeft. Vaak werken bedrijven met een Projecten Programma waarin Projecten die meer winst opleveren (Beter business case) vaak hogere prioriteit krijgen. Ipv6 levert KPN geen winst op, maar is gewoon iets wat een keer moet.Daarom zal het pas hoge prio krijgen als er echt geen IPv4 adressen meer zijn. Ik denk dat KPN (net als Ziggo) nog makkelijk 2 jaar voorruit kunnen.

[ Voor 52% gewijzigd door fagao op 10-09-2011 20:45 ]

[Jaap-Jan]

fagao schreef op zaterdag 10 september 2011 @ 20:40:
[...]

Het probleem vaak is dat het Modem of router bij de klant nog niet geschikt is. Daarom dat het makkelijk is om bij nieuwe klanten uit te rollen, dan bij bestaande.

Ziggo heeft bij 'snelle' >30Mb/s klanten al EuroDOCSIS 3.0- modems uitgedeeld, die zijn per definitie al geschikt voor IPv6. De router is ook een probleem, maar vooral voor de klant zelf.

Maar ik vind het een stap in de goede richting dat ze in ieder geval een start maken met de uitrol voor bestaande klanten.

[Zsub]

Ja, een tijd geleden al heeft iemand eens in de routing-table van in ieder geval de Ubee zitten wroeten en daar staan gewoon IPv6 entries in.

Ik hoop dat ik binnenkort aan de native kan, hoewel ik met mijn tunnel denk ik in principe meer in zal kunnen stellen.

[boonie]

Behalve de modems zijn er nog wat lastige zaken. De automatisering voor het provisioning process (is daar eigenlijk een Nederlands woord voor?) en Lawfull intercept (tappen) bijvoorbeeld.

Monitoring systemen zijn ook wenselijk als je publiek live gaat.

Het zou waarschijnlijk helpen als er meer vraag zou zijn. Ik mail elke paar maanden met mijn ISP. Maar online kan nog niets concreets zeggen.

[DDX]

Iemand idee waarom een windows dhcp (2008 r2) server vrolijk ipv6 adressen blijft uitdelen aan clients als ze al een static ipv6 adress hebben ?

In de ipv6 settings staat dus de optie 'Use the following IPv6 address' en niet op 'Obtain an IPv6 address automaticly'
De dhcp server zelf krijgt zelfs een ipv6 address van zichzelf. (naast z'n static ipv6 address)

[ Voor 3% gewijzigd door DDX op 20-09-2011 15:57 ]

[Miepermans]

DDX schreef op dinsdag 20 september 2011 @ 15:57:
Iemand idee waarom een windows dhcp (2008 r2) server vrolijk ipv6 adressen blijft uitdelen aan clients als ze al een static ipv6 adress hebben ?
<----->

De dhcp server zelf krijgt zelfs een ipv6 address van zichzelf. (naast z'n static ipv6 address)

Jup, dat is het Link Local Adres iets in de trant van : fe80::/10
dit is vergelijkbaar ( om en nabij ) met het 169.254.x.y adres van vroeger.

Zoals ik het begrepen heb, en verbeter me daar waar nodig is de link local meer voor provisioning en andere services van de netwerkstack

------ Edit :

Wikipedia: Link-local address

[ Voor 7% gewijzigd door Miepermans op 20-09-2011 16:09 ]

[DDX]

Nee ik heb het niet over het link local address.
Op de server krijg ik dus :

IPv6 Address. . . . . . . . . . . : 2001:4c08:2001:500::2
IPv6 Address. . . . . . . . . . . : 2001:4c08:2001:500::83cd:f765:f3d6:a872
Link-local IPv6 Address . . . . . : fe80::4ae:739a:d494b:379d%11

Waarbij 2001:4c08:2001:500::2 het static ipv6 address is, en de andere uit de ipv6 dhcp range komt.
Als ik de ipv6 scope disable dan verdwijnt dit address ook weer.

[ Voor 7% gewijzigd door DDX op 20-09-2011 17:14 ]

[databeestje]

Ik denk dat je tegen stateless autoconfig aan loopt. Hier had ik op mijn server ook last van. Ik heb mijn router aangepast naar managed mode zodat dhcp6 wel werkt en de gateway geadverteerd maar geen stateless autoconfig plaats vindt.

WIndows 2008 zal ook met een vast ingesteld adres nog via DHCP6 een adres oppikken en ik kan nergens zo snel vinden waar dit dan weer uit kan. Er zal wel een service zijn die ik kan stoppen maar intuitief is het niet.

[DDX]

Inmiddels via microsoft antwoord :

Method 1:
===========
Disable the DHCP IPv6 scope on the DHCP server side.

Method 2:

===========
Run the following commands to disable M Flag and O Flag on the client side.

netsh int ipv6 set int [index] routerdiscovery=disabled

netsh int ipv6 set int [index] managedaddress=disabled

netsh int ipv6 set int [index] otherstateful=disabled

And then run the below commands to see if you can still renew IPv6 address.

ipconfig /release6 [index]

ipconfig /renew6 [index]

For more information about our issue, I suggest that you see the below articles:

How to configure a Windows Vista client to obtain an IPv6 DHCP address

How to configure a Windows Vista client to obtain an IPv6 DHCP address

The DHCPv6 Protocol

http://technet.microsoft....ine/2007.03.cableguy.aspx

Optie 1 is ook echt een optie

[ Voor 7% gewijzigd door DDX op 21-09-2011 10:45 ]

[databeestje]

Een vinkje of select box in de adapter config zou ik ook wel een leuke (intuitieve) optie gevonden hebben naast de shell commando's maar dat is iets voor microsoft.

[webfreakz.nl]

meuk: Linksys E4200 1.0.03 build 14 Weer IPv6 updates voor deze router.

[stormfly]

Hi heeft iemand de E4200 werkend met SIXXS? Volgens de E4200 gui lijken ze allen 6rd tunnels te ondersteunen (nu naar tunnelbroker.net) maar ik zou hem graag naar SIXXS zetten.

Als ik in de lijst kijk dan is 6rd gelijk aan 6in54 static, maar 6rd lijkt niet supported http://www.sixxs.net/faq/connectivity/?faq=comparison

Van daar de vraag of iemand het werkend heeft, ben namelijk door wat stoeien meer dan ver door mijn ISK's heen.

[begintmeta]

Ik gebruik wel eens een ipv6-tunnel via freenet6, maar momenteel lijkt de boel niet te werken... Is HE beter?

[FiscBiker]

begintmeta schreef op maandag 31 oktober 2011 @ 12:08:
Ik gebruik wel eens een ipv6-tunnel via freenet6, maar momenteel lijkt de boel niet te werken... Is HE beter?

Met freenet6 geen ervaring, maar HE was een absolute verademing na Sixxs. Ben er zeer tevreden over.

[stormfly]

tunnelbroker.net == HE ==

ze hebben nu nog routed /48's beschikbaar op de POP Amsterdam

[ Voor 49% gewijzigd door stormfly op 31-10-2011 14:36 ]

[CyBeR]

Dat krijg ik ook van SixXS hoor. Uit ede dan wel maar da's meer historisch gegroeid.

[eymey]

Einde van de week krijg ik een Linksys E4200 router in bruikleen voor een IPV6 pilot bij Lijbrandt (glasvezel)

Helaas gaan ze nog geen native ipv6 doen maar via 6rd, maar dus al wel op ipv6 address space van de provider zelf (voor native ipv6 zal de wholesale operator, in mijn geval kpn, nog geen support hebben I guess).

[Raven]

Vanmorgen in de krant:


Oud nieuws ondertussen aangezien dit allemaal al bekend was.

Maar in het artikel staat vanaf volgend jaar, komen er volgend jaar dan al IPv6-only sites? En ISP's die daadwerkelijk IPv6 aanbieden? (XS4All is toch niet nog steeds de enige....?)

[eymey]

Lijbrandt en xms hopen het binnenkort aan te gaan bieden. Er loopt nu een laatste test.

[begintmeta]

Bij Ziggo was midden '12 het streefdoel, maar het lijkt me sterk dat ze dan overgaan op alleen ipv6.

Freenet6 doet het trouwens alweer*.

[stormfly]

Er zijn verschillende overgangs fases per provider geheel afhankelijk van het modem, bijvoorbeeld.

Native IPv6 support en Native IPv4 support, of tijdelijk embedded in het modem native IPv4 met tunnel IPv6 support. En als IPv4 aan het uitsterven is kan zelfs native IPv6 met een IPv4 tunnel een oplossing zijn voor die paar sites welke nog op IPv4 werken.

Maar goed in het laatste geval zijn we velen jaren verder en zal je modem wel eens vervangen kunnen zijn ;-)

Naar wat ik vernam is Ziggo nu eerst overal die Ubee modems aan het plaatsen, daarna komt er op een onbekende manier IPv6 ontsluiting. Zou mooi zijn als dat direct native is

[Snow_King]

Gisteren ging mijn Asus WL500G (4 jaar) kapot, dus ik snel naar de Media Markt om een nieuw AP te halen voor de WiFi hier. De WL500 stond altijd al in enkel access point, want ik heb een Linux doos die routering hier doet.

Tot mijn verbazing zie ik ineens dat IPv6 het niet meer doet. Het AP wat ik gekocht heb is een WL-331, lijkt mij niets meer dan een Layer 2 bridge tussen mijn bekabelde netwerk en mijn WiFi, right?

Voor de IPv6 gebruik ik RADVD en vertrouw ik dus op Router Announcements, dat heeft 2 jaar prima gewerkt.

Nu krijgen mijn clients over WiFi dus geen IPv6 meer en de boosdoener is overduidelijk het access point, maar waarom?

Handmatig een IPv6 adres geven aan de clients werkt perfect, ze kunnen vervolgens gewoon IPv6 verkeer doen.

Doe ik dit:

code:

ping6 -I wlan0 ip6-allnodes

Dan krijg ik alleen response van de node zelf, op mijn router zie ik vervolgens:

code:

09:46:33.954282 IP6 fe80::219:d2ff:fec0:b754 > ff02::1: ICMP6, echo request, seq 21, length 64
09:46:34.955540 IP6 fe80::219:d2ff:fec0:b754 > ff02::1: ICMP6, echo request, seq 22, length 64

De router stuurt echter geen echo reply terug, apart?

Maar het is niet alleen deze laptop die geen IPv6 meer krijgt, ook mijn telefoon (N900) en tablet krijgen geen IPv6 adres meer.

Ik zou alleen nog naar een logische verklaring, want een AP zou dergelijk verkeer toch helemaal niet moeten blokkeren?

[Freeaqingme]

Just checking, maar als ik een router in bridged mode zet, en de ppp verbinding door een linux bak laat oplossen, is in 1 keer toch iedere router 'ipv6-ready'?

[Zsub]

Freeaqingme schreef op zaterdag 05 november 2011 @ 13:54:
Just checking, maar als ik een router in bridged mode zet, en de ppp verbinding door een linux bak laat oplossen, is in 1 keer toch iedere router 'ipv6-ready'?

Nee. De router heeft geen sjoege van IPv6, dus die is niet 'IPv6-ready'. Dat een router het niet verhindert maakt niet dat het ding meteen geschikt ergens voor

[Freeaqingme]

True

Overigens gaat het hier om een kpn fiber aansluiting. Dus ik heb denk ik zelfs geen modem nodig (wel een terminator).

[Ultraman]

Na mijn verhuizinig ben ik even van IPv6 af geweest omdat hier in het studentenstadspad een ADSL verbinding van Telfort ligt. Met een Netgear router waar iedereen alles mee over WiFi deed ()

Dus ik heb op eigen kosten een TP-Link WD1043ND geplaatst met OpenWRT er op en die achter de Netgear gehangen zodat er getest en gehacked kon worden zonder de huisgenoten zonder internet te zetten. Daarna gezorgd dat alle bekabelde wandcontacten bij iedereen werken, helaas ben ik nog steeds de enige die het gebruikt, maar ach... Iedereen een eigen VLAN gegeven en een eigen WiFi AP SSID voor de drie VLANs.
Mooi, gescheiden netwerk.
Dat nu een maand getest en ik heb nul klachten gehad terwijl uit mijn stats blijkt dat iedereen inmiddels van de router ("olifant" zo heet ie) gebruik maakt.

Gisteren dus de Netgear er tussenuit getrokken en olifant direct aan het Telfort modem gehangen. It works.

Mooi, nu kan ik eindelijk IPv6 voor mezelf gaan regelen (en als de andere behoefte hebben hun ook, maar het is mijn tunnel op mijn naam, dus...).
Gisteren dus een tunnel bij HE.net aangemaakt en OpenWRT geconfigureerd. Kwartiertje verder en hopla IPv6. IPv6 pingen, ipv6 google werkt. Alleen op test-ipv6 kreeg ik maar 9/10 punten omdat de DNS niet IPv6 only was. Ok, maar het werkt nu wel al, mooi. Kijken we nog wel naar.

Gisteravond radvd ook rDNS laten aanbieden met de IPv6 adressen van OpenDNS.
En zo net nog eens een testje gedraaid:


Hopla
Ik ben weer fully IPv6 capable.

eymey schreef op zaterdag 05 november 2011 @ 09:23:
Lijbrandt en xms hopen het binnenkort aan te gaan bieden. Er loopt nu een laatste test.

Is XMS hier inderdaad mee bezig?
Want de laatste keer dat ik hier over informeerde is mij verteld dat dit nog wel een flinke poos ging duren en het glasvezelnet voorlopig IPv4 zou blijven.
Want ik moet daar hun jaar oude OpenWRT firmware eens voorzien van een nieuwe versie, dus ik dacht ik zet ook gelijk een tunnel voor hun op. Maar als XMS hier binnen een half jaar mee komt dan hoeft dat natuurlijk niet.
Eens kijken of ik wat meer info kan vinden hierover...

[eymey]

Dat had ik inderdaad ook altijd begrepen: Dat zowel het Wholesale Operator netwerk van KPN als dat van Reggefiber nog lang niet IPV6-ready was.

Maar goed, werd door Lijbrandt ineens (in het desbetreffende topic) benaderd voor een IPV6 pilot en had inmiddels al op meer plekken gelezen dat men het vanaf eind dit jaar ook standaard wil gaan aanbieden. Overigens, Lijbrandt is technisch nagenoeg hetzelfde als XMS.... ookal verschillen ze marketing-technisch.

In ieder geval, er is wel een catch: Het is nog niet 'native' ipv6 (iig niet op het KPN-deel waar ik op zit). Ze gebruiken een "6rd" implementatie waarbij de configuratie automatische wordt ge-pushed met dhcpv4 opties (dwz, ik moest de configuratie op "automatic" zetten in de leenrouter die ik heb gekregen en volgens de RFC kan dit met dhcpv4 opties).

Ik moet nog uitgebreid aan de test gaan om er wat meer over te kunnen oordelen (bijvoorbeeld of deze 6rd implementatie wel de volledige 50/50 mbit van mijn verbinding haalt... dit doen HE.net en SIXXS namelijk bij lange na niet).

Ik zit alleen met het probleem dat MAC OSx Lion (waar ik meestal achter zit) een bitch is met ipv6. Er wordt een ipv6 adres verkregen maar zowel Chrome als Firefox zijn ontzettend wispelturig in welke versie ze pakken, soms binnen een zelfde browsersessie. Googlen levert nog niet zo veel op, behalve dat er veel klachten zijn over de DNS resolver in OSX.....

Anyway, ik moet dus nog ff wat dingen doen:
* IPV6 vs. Mac OSX uitzoeken (en anders ga ik het meeste gewoon vanaf m'n Ubuntu netbook testen)
* Navragen of ik ook een statische 6rd configuratie mag/kan doen. De leenrouter (linksys e4200) irriteert me nu alweer op sommige punten maar m'n normale router, een Fritz!box 6390, kan alleen statische 6rd config aan.
* Testformulier van de provider invullen na het doen van alle door hun aangevraagde tests

[Zsub]

Voor IPv6 testen wil je geen OS X gebruiken. Die implementatie is matig, at best.

[CyBeR]

In tegendeel, die is prima. Hij heeft alleen geen absolute voorkeur meer voor IPv6 over IPv4, maar kiest wat op dat moment het beste is.

Als SixXS nlede01 kapot is om welke reden dan ook dan merk ik dat in m'n browser op mijn Lion laptop niet eens, terwijl m'n Leopard machine enorme timeouts geeft en dergelijke.

[ Voor 39% gewijzigd door CyBeR op 06-11-2011 15:06 ]

[Verwijderd]

Is nlede01 bij jou vaak kapot dan?

[CyBeR]

Nee, maar een tijdje geleden wel een paar keer en toen heb ik 't eigenlijk nauwelijks doorgehad.

[eymey]

Tsja... en toch is dit wisselvallige gedrag van Mac OSX Lion dus niet handig. Er jammer dat je dat dan blijkbaar ook nergens kan configureren. Voor testen moet iig het OS dat ik gebruik gewoon voorspelbaar werken .

Ik kan me bij normaal gebruik best voorstellen dat het automatisch goed zal gaan, mits de site die je bezoekt ook goed multistack verbonden is.

[CyBeR]

Op dat moment moet je dus utilities gebruiken die je in staat stellen om expliciet voor het een of het ander te kiezen, zoals ping versus ping6 en telnet -4 en telnet -6. Die heeft osx ook gewoon.

Voor het gewone geval waar je niet aan het testen bent maar gewoon wilt dat 't werkt is de implementatie van IPv6 in OSX absoluut niet "matig" te noemen.

http://www.ietf.org/mail-...ops/current/msg09805.html

[ Voor 8% gewijzigd door CyBeR op 06-11-2011 18:44 ]

[eymey]

Interessant document! Het klinkt ook wel erg logisch (iig voor de gewone eindgebruiker die toch meestal de doelgroep voor de Mac is).

Thanks voor de link iig. Ik ga eens zoeken naar test tools voor Mac maar onderdeel van de test is ook juist om gewoon te surfen, zowel naar v6 sites als dualstack sites. En dan ben je dus weer afhankelijk van de manier van werken van Mac OSX.

Maar ik ga sowieso ook testen vanuit Ubuntu en Win7.

Android werkt trouwens ook fantastisch met IPV6 .

test-ipv6.com en ipv-6test.com werken voortreffelijk (waar de ipv6 speedtest op ipv6-test.com onder MacOSX dus regelmatig claimt dat er ineens geen v6 verbinding meer is).

edit:
zo.... in de Linksys E4200 firewall entries toegevoegd voor het IPV6-adres van m'n NAS (waar ook paar kleine website'jes op draaien). En AAAA records opgegeven in DNS. De website-test op ipv6-test.com is een mooi controlemiddel

[ Voor 35% gewijzigd door eymey op 06-11-2011 21:44 ]

[Verwijderd]

Beste mensen,

Ik heb zojuist toch iets bereikt waar ik al meer dan 1,5 jaar mee in de pruts zat en waar ik nooit uit kwam. Geen idee of één van de Nederlandse pfSense-ontwikkelaars meeleest, want die stelde er ook een vraag over een hele tijd terug toen ik nog lid was van de [ipv6-tf].

Het betreft hier het reserveren van een DHCPv6-adres op basis van het MAC-adres. Wat, zal je denken? Dat is toch een fluitje net zoals bij IPv4? Helaasch, DHCPv6 heeft iets nieuws bedacht op clients te identificeren, de zogenaamde DUID. En nog meer helaasch is die DUID ook nog is softwaregebonden, en om het nog erger te maken gebruikt Windows voor alle interfaces hetzelfde DUID.

Oftewel, het reserven van DHCPv6-adressen voor netwerkapparaten wordt je erg lastig gemaakt op deze manier. En al helemaal als je bijvoorbeeld twee dualboot-systemen hebt die allebij hetzelfde adres moeten krijgen. Bij DHCPv4 deed je het dus gewoon op basis van het MAC-adres, maar die informatie stuurt de DHCPv6-client niet meer door naar de server.

Wel is er nog een ander trucje, en dat is het gebruiken van de combinatie DUID+IAID om een OS-installatie+netwerkinterface een uniek IPv6-adres te geven. Zo doet de DHCPv6 server van Windows Server 2008 het bijvoorbeeld.

Maar helaas, de de facto standaard ISC DHCPv6 server kan geen adressen uitdelen op basis van die combi. Die kan enkel statische leases uitdelen op basis van kale DUIDs met alle ellende van dien.

Ik ben de oplossing gaan zoeken in het link-local adres dat wel meegezonden wordt logischerwijs door de DHCPv6-client. Want het link-local adres is bovendien ook nog is gegenereerd aan de hand van het MAC-adres. ISC DHCPv6 en Windows Server 2008 kunnen niet een client matchen op basis van het link-local.

Doet zijn intrede: Dibbler!

Dibbler kan als enige van alle DHCPv6-servers statische adressen uitdelen op basis van het link-local! Zij het via een kleine "hack", maar het wil. Hiermee lossen we het probleem op, want we zijn niet afhankelijk van het Windows-only trucje dat gebruik maakt van DUID+IAID en we zijn ook niet afhankelijk van het Linux-only trucje van elke interface zijn eigen DUID (ook niet altijd zo, trouwens).

Op deze manier kunnen we een statische IPv6-lease koppelen aan de netwerkkaart van een PC, ongeacht het OS en de door software-gegenereerde DUID.

Om geïnteresseerden het stof voor de voeten weg te vegen hierbij een demonstratie van een mogelijk configuratiebestand:

code:

log-mode syslog

iface br-lan {
        T1 1800-7200
        T2 3600-9000
        prefered-lifetime 345600
        valid-lifetime 432000
        client-max-lease 5

        option lifetime 7200
        option dns-server 2001::1337:bad:c0f:fee
        option domain "ip6.tweakers.net","domein2.ip6.tweakers.net"
        class {
                # static client 1
                accept-only fe80::XXXX:XXXX:XXXX:XXXX
                pool 2001:XXX:XXX:10:2::53
        }
        class {
                # dynamic
                pool 2001:XXX:XXX:10:3::50-2001:XXX:XXX:10:3::499
        }
}

Getest met Dibbler 0.7.3. Succes en plezier ermee, het heeft mij meer dan 1,5 jaar gekost om hier achter te komen (vrijwel niets over op internet te vinden).

Samengevat nog een keer je mogelijkheden om static leases uit te delen:

• Enkel op basis van het DUID. Werkt alleen goed als je maar 1 interface hebt, of als alle interfaces zijn eigen DUID hebben. Dit is niet het geval bij Windows. Bij meerdere Windows-installaties op dezelfde PC verschilt het DUID. Deze manier van matchen ondersteunt de ISC server.
• Op basis van het DUID en IAID. Werkt alleen maar voor Windows-clients en alleen Windows Server 2008 kan aan de hand van deze combi een static lease uitdelen.
• Op basis van het link-local. Op dit moment ondersteunt zowel Windows Server 2008 als ISC DHCP deze manier niet. Het is wel niet-OS gebonden (hardwaregebonden) en het werkt voor alle OS'es (inclusief OSX). De enige DHCPv6-server die dit ondersteund is dus Dibbler (zie hierboven).

[CyBeR]

Euh, ik gebruik geen DHCPv6 maar ik kan me niet voorstellen dat je link-layer het MAC-adres van de betreffende machine niet krijgt. Die lijkt me nog altijd gewoon onderdeel van de ethernet header...

Moet de software dat wel ondersteunen natuurlijk, maar ik kan me voorstellen dat de overweging om 't uit het application-layer packet te halen juist was dat die link-layer tevoorschijn zou moeten komen.

Hoewel er over nadenkend dat wellicht lastig is met dhcp relaying in routers e.d.

[ Voor 42% gewijzigd door CyBeR op 09-11-2011 18:11 ]

[Verwijderd]

Feit is dat de ISC DHCPv6-server niet kan en wil matchen op basis van het link-local

En ja, bij DHCPv4 werd het MAC-adres nog als extra optie meegestuurd. Bij DHCPv6 niet meer.

Bij DHCPv4 gold dit nog:

DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address.

Bij DHCPv6 wordt er een solicit verzonden met als bestemming een multicast-adres en afzender het link-local adres. In het pakketje wordt er dan nog is weer het DUID+IAID meegezonden. Wat Dibbler dus in feite kan doen is kijken naar de afzender van het pakketje. Dat kunnen ISC en Windows Server dus kennelijk niet.

[ Voor 105% gewijzigd door Verwijderd op 09-11-2011 18:17 ]

[databeestje]

Snow_King schreef op zaterdag 05 november 2011 @ 10:50:
Gisteren ging mijn Asus WL500G (4 jaar) kapot, dus ik snel naar de Media Markt om een nieuw AP te halen voor de WiFi hier. De WL500 stond altijd al in enkel access point, want ik heb een Linux doos die routering hier doet.

Tot mijn verbazing zie ik ineens dat IPv6 het niet meer doet. Het AP wat ik gekocht heb is een WL-331, lijkt mij niets meer dan een Layer 2 bridge tussen mijn bekabelde netwerk en mijn WiFi, right?

Je kastje stuurt kennelijk niet al het multicast verkeer door. Daarnaast is het ether id van IPv6 verkeer anders als IPv4 verkeer. Wellicht dat dit AP heel specifiek is.

Ik heb boven een windows 7 PC met een oude ralink usb 54g dongle welke dus ook weigert om een v6 adres te accepteren. Beetje bijzonder, zal wel in een "oude" driver zitten die dwars ligt. Met mijn telefoon of macbook werkt het wel naar berhoren.

Multicast is altijd een ondergeschoven kind geweest en sommige wifi access points zien het als "broadcast" verkeer en filteren het daarom uit.

[Raven]

Ik zit nu zonder IPv6-tunnel helaas daar ik voor het huidige OS van mijn mITX router nog geen howto heb kunnen vinden. pfSense zorgde er met 10k DHCP requests in 30min voor dat mijn ISP de verbinding dichtgooide, hier kon ik geen oorzaak van vinden en een re-install hielp niet dus ik zit nu met IPFire te werken waar net als bij pfSense geen ondersteuning voor IPv6 aanwezig is.

Nou ja geen, bij pfSense bleek het onderliggende OS (FreeBSD) het wel te ondersteunen en daar had ik een mooie howto voor gevonden. Of iets vergelijkbaars voor IPFire beschikbaar is weet ik niet.

[Snow_King]

databeestje schreef op woensdag 09 november 2011 @ 19:49:
[...]


Je kastje stuurt kennelijk niet al het multicast verkeer door. Daarnaast is het ether id van IPv6 verkeer anders als IPv4 verkeer. Wellicht dat dit AP heel specifiek is.

Ik heb boven een windows 7 PC met een oude ralink usb 54g dongle welke dus ook weigert om een v6 adres te accepteren. Beetje bijzonder, zal wel in een "oude" driver zitten die dwars ligt. Met mijn telefoon of macbook werkt het wel naar berhoren.

Multicast is altijd een ondergeschoven kind geweest en sommige wifi access points zien het als "broadcast" verkeer en filteren het daarom uit.

Inmiddels (vandaag) heb ik het AP vervangen door een AP700 van Draytek, die doet het wel prima met IPv6!

Die Sitecom gaat terug naar de MM iig.

[CyBeR]

Kijk eens of die sitecom toevallig aan IGMP snooping doet en of dat uit te zetten is.

[WoC]

Raven schreef op donderdag 10 november 2011 @ 15:00:
...pfSense zorgde er met 10k DHCP requests in 30min voor dat mijn ISP de verbinding dichtgooide, hier kon ik geen oorzaak van vinden en een re-install hielp niet...

Hoe krijg je dat voor elkaar? pfSense draait standaard geen DHCP server op de WAN poort.

...Of iets vergelijkbaars voor IPFire beschikbaar is weet ik niet...

Das toch gewoon een Linux implementatie? Niet gelezen, maar via de wiki dit (Duitse) documentje gevonden. Succes!

[Raven]

Uhm, volgensmij snap je me niet goed . Er zit geen DHCP server op de WAN-poort, maar pfSense moet wel requests sturen omdat het IP van de ISP via DHCP wordt verkregen. Van wat ik heb begrepen reageerde pfSense niet (meer) op de response van de ISP's DHCP-server die na elke DHCP aanvraag werd verstuurd.
Zoiets gebeurde er dus:

pfSense: ik wil een IP-adres
ISP's DHCP-server: hier heb je een adres
pfSense: negeert antwoord en vraagt nog een keer een IP-adres

En dat telkens overnieuw.

Die howto heb ik gezien, maar daar moet je aan het (her)compileren als ik het goed begrijp, bij pfSense was het zo simpel als 2 scriptjes en 1 config file schrijven.

[ Voor 33% gewijzigd door Raven op 11-11-2011 10:00 ]

[WoC]

Raven schreef op vrijdag 11 november 2011 @ 09:56:
Uhm, volgensmij snap je me niet goed . Er zit geen DHCP server op de WAN-poort, maar pfSense moet wel requests sturen omdat het IP van de ISP via DHCP wordt verkregen. Van wat ik heb begrepen reageerde pfSense niet (meer) op de response van de ISP's DHCP-server die na elke DHCP aanvraag werd verstuurd.

Iets te snel gelezen... Maar ik begrijp wat je bedoelt. Toch vind ik het vreemd, pfSense kan prima als cliënt dienen. Je modem voor de pfSense bak al eens herstart? Maar goed, dit is verder off-topic hier.

Die howto heb ik gezien, maar daar moet je aan het (her)compileren als ik het goed begrijp, bij pfSense was het zo simpel als 2 scriptjes en 1 config file schrijven.

Hmm, ja, kan me voorstellen dat je daar niet aan wilt beginnen (vandaar wellicht je pfSense probleem verder troubleshooten, nieuwe image plaatsen, etc). Je zou ook kunnen kijken naar M0n0wall. pfSense is hier van afgeleid, maar m0n0wall heeft al standaard IPv6 ondersteuning aan boord. Wel wat beperkter qua features, maar als dit goed werkt, zou je daarna ook weer makkelijk terug moeten kunnen naar pfSense.

[Raven]

offtopic:
Ik heb de modem meermaals geherstart, pfSense bijgewerkt naar v2, dan nog een schone installatie gedaan, de NIC's in de config omgewisseld (probleem ging mee naar de andere NIC), andere kabel naar de modem geprobeerd, niks hielp. Pc met Windows rechtstreeks aan modem en het werkt gelijk, na install IPfire op router-pc werkte het ook meteen.
Ik ben trouwens niet van plan pfSense er weer op te doen, als dit probleem langer blijft doorgaan duurt de block van ISP ook langer....

m0n0wall is ook gebaseerd op FreeBSD, ik was nou juist al van plan om te overstappen op een op Linux gebaseerd OS....

[ Voor 12% gewijzigd door Raven op 12-11-2011 13:59 ]

[DDX]

Issue gevonden nu ik ipv6 ook op wat windows server gebruik, dns registratie op 2 machines registreert enkel AAAA records, 1 server A en AAAA records.
Wat logging gedaan ed en de client stuurt geen A record registratie request naar de dns server.

Maar een case geopend bij microsoft, ze hadden een soortgelijke case gehad en daar lag het aan vmware.
Laat de 2 probleemservers nou toevallig ook vmware zijn en de werkende server een fysieke server.

Wat dingen geprobeerd samen met microsoft, maar nog geen oplossing.

[GeeBee]

Ik heb dit topic doorzocht op "vervangen" omdat ik hier het verhaalde wilde controleren dat laatst in De Stentor stond, getiteld Nieuw internet kost geld. Strekking: bij de overstap naar IPv6 zou alle netwerkapparatuur moeten worden vervangen.
Morgen is hier een voorlichtingsavond van Reggefiber en die zitten ook al over je interne netwerk op IPv6 te zeuren.

Als ik hier het zo'n beetje doorlees kom ik tot de volgende conclusies:

Modem/router van de provider
- moet vervangen worden
- of via firmware upgrade geschikt gemaakt worden voor IPv6

Switches 100 mbit of Gbit
Kunnen gewoon gebruikt blijven worden, ook al zijn het oude IPv4-dingen

Bedrading
Heeft nergens last van en kan allemaal blijven liggen.

Computers
Als de lijn PC -> ... -> modem compleet IPv6 is prima, anders kun je gewoon zonder problemen IPv4 blijven werken op je eigen interne netwerk. Elk modern OS probeert het eerst via IPv6 en schakelt anders gewoon weer over op IPv4 (heet dit fallback?).

Andere netwerkverbindingen (netwerkprinters, printservers, NAS-servers, mediastreamers etc)
Voor zover ze geen IPv6 ondersteunen zal bv een PC die wil printen dit via IPv4 doen. Idem voor welke andere verbinding tussen PC's onderling of PC/ welk ander netwerkapparaat dan ook.
Ook bv een IPv4-mediastreamer zal gewoon via IPv4 van internet gegevens op kunnen halen zoals filminfo etc.

Kort gezegd: de router moet IPv6 worden, intern hoeft er niets te veranderen als je dat niet wilt.

Klopt dit verhaal zo een beetje?
En zo ja: hoe zit het dan met eigen (game)server draaien op je interne netwerk die voor de buitenwereld via internet bereikbaar moet worden/ blijven? Moet je dan je externe IPv6-adres door gaan geven?

[ Voor 3% gewijzigd door GeeBee op 16-11-2011 20:13 ]

[Osiris]

GeeBee schreef op woensdag 16 november 2011 @ 20:10:
Hoe zit het dan met eigen (game)server draaien op je interne netwerk die voor de buitenwereld via internet bereikbaar moet worden/ blijven? Moet je dan je externe IPv6-adres door gaan geven?

"Externe IPv6-adres"? Hoe bedoel je dat?

[GeeBee]

Osiris schreef op woensdag 16 november 2011 @ 20:44:
[...]

"Externe IPv6-adres"? Hoe bedoel je dat?

Nu moet je je IP-adres doorgeven van je internetverbinding dat je van je provider toegekend hebt. Misschien heet dat bij IPv6 geen adres meer, dat je dit vraagt?

[DDX]

Je eigen game server zal een eigen ipv6 adres hebben.
(Wel even zorgen op de firewall dat de poorten ook openstaan)

[ Voor 37% gewijzigd door DDX op 16-11-2011 20:58 ]

[Osiris]

GeeBee schreef op woensdag 16 november 2011 @ 20:55:
[...]

Nu moet je je IP-adres doorgeven van je internetverbinding dat je van je provider toegekend hebt. Misschien heet dat bij IPv6 geen adres meer, dat je dit vraagt?

Toch wel enigszins jammer dat in onze huidige tijd de jongere generatie zó verpest is door NAT dat ze alleen maar op deze manier kunnen denken Makes me sad..

edit:

Jeetje, uit '68, nou OK, jongere generatie: not so much Dan was je d'r toentertijd nog niet zo mee bezig denk ik..

"Vroggâh" kreeg men bij een internetverbinding gewoon meerdere IP's en konden meerdere apparaten achter de router gewoon een publiek IP krijgen, zoals het ook bedoeld was.

Maar toen raakten de IPv4-adresjes op...

Dus kwam er het verduivelde NAT. Helaas. Want vervolgens waren pure end-to-end-connections (ofzo) niet meer mogelijk.

Vervolgens hebben we nu IPv6 met achterlijk veel publieke adressen per aansluiting.

Kortom: "externe adressen" doen we niet meer aan, nergens voor nodig, alles krijgt "gewoon" een publiek IP-adres

[ Voor 42% gewijzigd door Osiris op 16-11-2011 21:02 ]

[begintmeta]

precies, er is eigenlijk geen nadeel (tenminste, als je aan een firewall denkt, die krijg je bij NAT er vaak zonder nadenken bij, maar dat zal met IPv6 ook wel zo worden.)

[ Voor 37% gewijzigd door begintmeta op 16-11-2011 21:11 ]

[GeeBee]

Osiris schreef op woensdag 16 november 2011 @ 21:00:
[...]

Toch wel enigszins jammer dat in onze huidige tijd de jongere generatie zó verpest is door NAT dat ze alleen maar op deze manier kunnen denken Makes me sad..

edit:

Jeetje, uit '68, nou OK, jongere generatie: not so much Dan was je d'r toentertijd nog niet zo mee bezig denk ik..

Ik wilde net even opzoeken wie er jonger is, maar dat staat niet in je profiel

* GeeBee is blij dat hij bij iedereen in zijn omgeving de hele IPv6-paniek van hardware-vervangen nu kan ontzenuwen dankzij het denkwerk van de jongeren hier aanwezig

[eymey]

Haha tsja.... ik weet niet hoe oud jij bent... ben zelf 32 en inderdaad wel helemaal met ipv4 'opgegroeid' en opgeleid.

Het is ook echt even een wezenlijk andere denkstap die je moet maken, vooral qua je beveiliging en firewalling..... tenzij je natuurlijk voor je werk al veel grotere netwerken hebt beheerd met veel routers en zonder NAT, maar met firewalls .

Zelf niet echt ervaring daarin, dus een omschakeling.

Maar "extern ipv6 adres" klinkt wat dat betreft inderdaad nogal komisch, zogezegd.

[Osiris]

GeeBee schreef op woensdag 16 november 2011 @ 21:22:
[...]

Ik wilde net even opzoeken wie er jonger is, maar dat staat niet in je profiel

Uit '85

GeeBee schreef op woensdag 16 november 2011 @ 21:22:
* GeeBee is blij dat hij bij iedereen in zijn omgeving de hele IPv6-paniek van hardware-vervangen nu kan ontzenuwen dankzij het denkwerk van de jongeren hier aanwezig

Wikipedia: OSI model



IPv4 en IPv6 zitten in laag 3: de network layer. Switches werken op 't niveau van layer 2: data link layer. Wat voor layer daarboven zit boeit ze geen flikker. (Tenzij je een layer-3-switch hebt )

[GeeBee]

.. oftewel non-IPv6 switches bestaan niet? Het maakt switches niet uit welke IP-versie er doorheen gaat?
HTS-opleiding met één module ICT over OSI is net ff te lang geleden

[ Voor 67% gewijzigd door GeeBee op 16-11-2011 21:37 ]

[Verwijderd]

eymey schreef op woensdag 16 november 2011 @ 21:23:
Maar "extern ipv6 adres" klinkt wat dat betreft inderdaad nogal komisch, zogezegd.

Ik vind het wel meevallen eigenlijk, je hebt namelijk ook link-local adressen

[Osiris]

GeeBee schreef op woensdag 16 november 2011 @ 21:34:
.. oftewel non-IPv6 switches bestaan niet? Het maakt switches niet uit welke IP-versie er doorheen gaat?
HTS-opleiding met één module ICT over OSI is net ff te lang geleden

De "simpele" boeit 't geen flikker, de wat ingewikkeldere wellicht wel, da's eigenlijk 't enige wat ik weet.

Maar je huis-tuin-en-keuken-switchje die mensen thuis hebben staan van de lokale PC-boer: maakt geen moer uit wat er doorheen gaat.

[GeeBee]

OK, duidelijk.
Maar hoe zit het met mijn mediastreamer die (wellicht) geen IPv6 aan boord heeft? Kan die, als die is aangesloten op een IPv6 modem/router nog gegevens binnenhalen van internet?

[begintmeta]

Osiris schreef op woensdag 16 november 2011 @ 21:53:
... maakt geen moer uit wat er doorheen gaat.

Oud bier vontie vroeger in het studentenhuis toch niet lekker.

[Osiris]

GeeBee schreef op woensdag 16 november 2011 @ 22:05:
OK, duidelijk.
Maar hoe zit het met mijn mediastreamer die (wellicht) geen IPv6 aan boord heeft? Kan die, als die is aangesloten op een IPv6 modem/router nog gegevens binnenhalen van internet?

IPv4 verdwijnt niet zomaar hoor Beide protocollen zullen nog wel lange tijd naast elkaar bestaan, kan prima. Echter zullen er steeds meer IPv6-only-hosts ontstaan. Dat zal dan alweer wat lastiger gaan, maar als je Wikipedia afstruint zie je dat daar ook wel weer mogelijkheden zijn geloof ik.

begintmeta schreef op woensdag 16 november 2011 @ 22:05:
[...]

Oud bier vontie vroeger in het studentenhuis toch niet lekker.

Ik vind oud bier ook niet lekker. Volgende keer vers bier proberen

[eymey]

Huidige apparatuur IPV6-geschikt maken (dus ook van de Mediastreamer) zal over het algemeen slechts een kwestie zijn van het upgraden van de software. Aan hardware kan nauwelijks een limitatie zitten, hoogstens in de microcode van dure netwerkkaarten die eigen chipjes/processor units hebben om bepaalde dingen van het host systeem te offloaden.

Maar alles wat gewoon netjes op layer 2 werkt waarbij herprogrammeerbare/vervangbare software de layer 3 afhandelt is te upgraden. Of fabrikanten het doen is natuurlijk een tweede......

@Nightspirit: Mja, true . Maar die link-local adressen zijn puur voor die betreffende IP-stack/netwerk interface op 1 apparaat... dat is toch weer net iets anders dan het verschil tussen private IP adressen aan de 'binnenkant' van het netwerk en het publieke IP aan de internet zijde.

[Roetzen]

Op de machine waarop ik dit schrijf zijn er twee IPv6 interfaces actief. De ene is het eindpunt van een AYIYA SixXs tunnel. De andere is een bedrade netwerk kaart die z'n IPv6 adres van de router krijgt waarop een he.net tunnel eindigt.

Het OS is WinXP Pro, SP3.

Bij een uitgaande verbinding wordt steeds de SixXs tunnel gebruikt. Kennelijk heeft die prioriteit. Ik zou eigenlijk liever hebben dat de andere verbinding de prioriteit had. Die is iets sneller en iets betrouwbaarder naar mijn idee. Ik kan natuurlijk aiccu uit zetten, maar dan stopt ook de ISK teller. Die wil ik wel laten doortellen.

Iemand enig idee hoe ik dat kan doen?

[Verwijderd]

Default route aanpassen? Wat is de output van "route print -6"?

[edit]

netsh interface ipv6 show route

Is iets makkerlijker te lezen qua output.

[ Voor 42% gewijzigd door Verwijderd op 18-11-2011 00:59 ]

[Roetzen]

Dit:

C:\Dokumente und Einstellungen\Michiel>netsh interface ipv6 show route
Der aktive Status wird abgefragt...

Veröff.  Typ       Met   Präfix                    Idx  Gateway/Schnittstelle
-------  --------  ----  ------------------------  ---  ---------------------
no       Autokonf    10  2001::/32                   6  Teredo Tunneling Pseudo-Interface
no       Autokonf   256  2002:470:1f15:1117::/64     4  fe80::f842:9dff:feda:aec
no       Autokonf     8  2001:470:1f15:1117::/64     4  LAN-Verbindung
no       Autokonf   256  ::/0                        4  fe80::f842:9dff:feda:aec
no       Manuell      0  2001:7b8:2ff:3a9::/64       5  aiccu
yes      Manuell      0  ::/0                        5  2001:7b8:2ff:3a9::1

[begintmeta]

Men is nu ook bij netfilter aan het ontwikkelen geslagen.

NAT voor IPv6. (er zijn wel al andere projecten voor meen ik)

Poll: NAT is een goed idee, ook voor IPv6.
• Ja
• Nee
• Maakt me niet uit

^{Ook een poll maken? Klik hier}

[Osiris]

During the last netfilter workshop it was agreed that there are legitimate
use cases for IPv6 NAT (…)

Nou, daar ben ik wel ernstig benieuwd naar dan

[begintmeta]

Men houdt het erg op afstand, maar er wordt wel iets geopperd (maar ook dat andere oplossingen denkbaar zijn):

While we do not consider IPv6 NATs to be desirable, we understand that some deployment of them is likely unless workable solutions to avoiding renumbering, facilitating multihoming without adversely impacting routing scalability, and homogeneity are generally recognized as useful and appropriate.

[Snow_King]

Oh nee, daar gaan we weer! Ik zie dit al weer gebeuren bij veel ISP's, hebben straks alle apparaten weer een intern IP.

Men gaat dan NAT weer als firewall zien

[CAPSLOCK2000]

Dat er zoveel mee geprutst wordt betekend niet dat er geen legitieme toepassingen zijn. Een 1-op-1 NAT zou handig kunnen zijn als je ooit van internet-provider wisselt. Je hele interne netwerk omnummeren (in korte tijd) kan behoorlijk lastig zijn. Het IPv6 antwoord daarop is "dan moet je maar je eigen (provider independent) adresruimte aanschaffen" . Dat is niet onmogelijk maar wel best lastig en alleen voor de allergrootste weggelegd.

[Snow_King]

CAPSLOCK2000 schreef op vrijdag 25 november 2011 @ 17:15:
Dat er zoveel mee geprutst wordt betekend niet dat er geen legitieme toepassingen zijn. Een 1-op-1 NAT zou handig kunnen zijn als je ooit van internet-provider wisselt. Je hele interne netwerk omnummeren (in korte tijd) kan behoorlijk lastig zijn. Het IPv6 antwoord daarop is "dan moet je maar je eigen (provider independent) adresruimte aanschaffen" . Dat is niet onmogelijk maar wel best lastig en alleen voor de allergrootste weggelegd.

Nee, dat is het zeker niet. Echter maakt de huidige vorm waarop NAT gebruikt wordt wel héél veel kapot.

[CAPSLOCK2000]

Snow_King schreef op vrijdag 25 november 2011 @ 17:29:
Nee, dat is het zeker niet. Echter maakt de huidige vorm waarop NAT gebruikt wordt wel héél veel kapot.

Breek me de bek niet open... Ik heb de (misschien naieve) hoop dat als er maar genoeg adressen zijn het probleem vanzelf weg valt. Wat die mensen eigenlijk willen is een firewall. Gelukkig richten de meeste mensen niet hun eigen netwerk in maar krijgen ze een kastje van hun provider en dat gebruiken ze, wat er verder ook in dat kastje zit.
De echte experts en professionals kunnen er vast wel goed mee om gaan. Het echte gevaar zit in de tussenlaag. De sector MKB en handige-neefjes waarin veel ITers actief zijn die weinig inzicht hebben in wat ze doen. Ze hebben de klok horen maar weten niet waar de klepel hangt. Die zouden hun slechte gewoontes wel eens mee kunnen nemen.
Als we iedereen maar kunnen overtuigen dat een simpele inboud-firewall minstens zoveel veiligheid geeft als NAT dan komt het wel goed. De meeste ITers weten best wel dat een echte firewall beter is, maar die NAT hebben ze sowieso nodig, dus waarom niet gebruiken wat je toch al hebt (is dan de redenering).

[webfreakz.nl]

Het maakt voor de thuisgebruiker ook echt niet uit of ze nou een firewall configureren of een NAT rule toepassen.

Het komt er op neer dat verkeer een Host X op Port Y wil bereiken. Allow / Deny is het enige interessante, en Deny-All is de default

[Sendy]

Opgelost: gateway stond naar zichzelf te wijzen.

Ik ben een Xen setup aan het debuggen. Dit valt me op in een tcpdump sessie:

Bash Session:

21:22:23.335224 IP6 2001:32:abcd:deaf::1:5 > ff02::1:ff01:5: ICMP6, neighbor solicitation, who has 2001:32:abcd:deaf::1:5, length 32

De afzender is de machine die probeert te pingen naar ipv6.google.com. De DNS aanvragen zijn net geweest. De geadresseerde ff02:: nogiets is een multicast adres ("Sollicited-Node Multicast" als ik het goed heb opgezocht.) De vraag is "Wie heeft mijn ip?"

De machine vraagt aan iets over zijn eigen adres? Is dat niet gek? Er wordt trouwens niet op geantwoord.

Kan iemand uitleggen wat een sollicited-node multicast is?

edit:

Publieke ip's

[ Voor 13% gewijzigd door Sendy op 25-11-2011 22:06 ]

[webfreakz.nl]

Sendy schreef op vrijdag 25 november 2011 @ 21:55:
Kan iemand uitleggen wat een sollicited-node multicast is?

Wikipedia: Solicited-node multicast address

Solicited-node Multicast Addresses are used with IPv6 Neighbor Discovery to provide the same function as the Address Resolution Protocol (ARP) in IPv4.

[Osiris]

webfreakz.nl schreef op zaterdag 26 november 2011 @ 00:55:
[...]


Wikipedia: Solicited-node multicast address


[...]

Dan nog is het apart. Want normaliter is de sender gewoon 't publieke adres van de afzender en is de destination dat Solicited-noded multicast address. En zie je netjes in Wireshark "Neighbor solicitation for <adres-wat-je-wil-hebben> from <jouw-adres>".

Maar in dit geval lijkt hij 't idd aan zichzelf te vragen

[Snow_King]

CAPSLOCK2000 schreef op vrijdag 25 november 2011 @ 17:58:
[...]

Breek me de bek niet open... Ik heb de (misschien naieve) hoop dat als er maar genoeg adressen zijn het probleem vanzelf weg valt. Wat die mensen eigenlijk willen is een firewall. Gelukkig richten de meeste mensen niet hun eigen netwerk in maar krijgen ze een kastje van hun provider en dat gebruiken ze, wat er verder ook in dat kastje zit.
De echte experts en professionals kunnen er vast wel goed mee om gaan. Het echte gevaar zit in de tussenlaag. De sector MKB en handige-neefjes waarin veel ITers actief zijn die weinig inzicht hebben in wat ze doen. Ze hebben de klok horen maar weten niet waar de klepel hangt. Die zouden hun slechte gewoontes wel eens mee kunnen nemen.
Als we iedereen maar kunnen overtuigen dat een simpele inboud-firewall minstens zoveel veiligheid geeft als NAT dan komt het wel goed. De meeste ITers weten best wel dat een echte firewall beter is, maar die NAT hebben ze sowieso nodig, dus waarom niet gebruiken wat je toch al hebt (is dan de redenering).

Bij de handige neefjes en het MKB zie ik inderdaad veel problemen ontstaan, daar wordt vaak toch maar heel erg aan geklungelt.

NAT is voor veel van die mensen 'heilig' en zullen het ook direct weer aangrijpen zodra ze de kans krijgen.

1:1 NAT kan ik nog wel mee leven, maar zolang elke PC in het netwerk maar een direct IP met de buitenwereld heeft.

[JackBol]

Osiris schreef op zaterdag 26 november 2011 @ 08:41:
[...]

Dan nog is het apart. Want normaliter is de sender gewoon 't publieke adres van de afzender en is de destination dat Solicited-noded multicast address. En zie je netjes in Wireshark "Neighbor solicitation for <adres-wat-je-wil-hebben> from <jouw-adres>".

Maar in dit geval lijkt hij 't idd aan zichzelf te vragen

In IPv6 heb je een broadcast meer, dus zul je moeten multicasten. Om het niet naar iedereen te hoeven multicasten verkleint de client de scope waar naar gemulticast word. Dit is het splicited node multicast adres. Als je een link local adres hebt, ben je veplicht om lid te worden van het bijbehorende solicited node multicast adres, waardoor je link-local communicatie mbt. je eigen IP adres mee krijgt.

[Osiris]

_DH schreef op zaterdag 26 november 2011 @ 14:02:
[...]


In IPv6 heb je een broadcast meer, dus zul je moeten multicasten. Om het niet naar iedereen te hoeven multicasten verkleint de client de scope waar naar gemulticast word. Dit is het splicited node multicast adres. Als je een link local adres hebt, ben je veplicht om lid te worden van het bijbehorende solicited node multicast adres, waardoor je link-local communicatie mbt. je eigen IP adres mee krijgt.

Ik snap niet zo goed wat je hier nou precies probeert uit te leggen.

Is dit de uitleg voor het "IP A stuurt een neighbor-discovery-packet om achter het hardware-adres van IP A (zichzelf en dus niet van een andere PC) te komen"-issue?

[eymey]

Ik zat me eigenlijk af te vragen: Is er ergens documentatie (of desnoods een door IPV4 en NAT verpeste dummy-guide) waar al deze zaken basic en zo concreet mogelijk met concrete praktijkvoorbeelden worden uitgelegd?

De adressering en de routing advertisement e.d. snap ik wel maar alle mechanismen zoals bij broadcast e.d. zijn nog steeds wat abstract voor me.

[CyBeR]

Osiris schreef op zaterdag 26 november 2011 @ 14:12:
[...]

Ik snap niet zo goed wat je hier nou precies probeert uit te leggen.

Is dit de uitleg voor het "IP A stuurt een neighbor-discovery-packet om achter het hardware-adres van IP A (zichzelf en dus niet van een andere PC) te komen"-issue?

Nee, dat is de uitleg voor waarom het solicited-node multicast-adres gebruikt wordt. (Dat kan overigens een stuk simpeler: namelijk omdat broadcast zuigt en met multicast je nic slim kan zijn en ND's die niet voor jou zijn weg kan filteren omdat ze niet naar 't goede multicastadres gaan.)

De reden dat je ND-queries ziet voor je eigen adres is ook heel simpel: dat is de Duplicate Address Detection die gebruikt wordt om te checken of een aan te nemen IPv6-adres niet toevallig al in gebruik is. Als je goed oplet zie je dat IPv4-stacks hetzelfde doen.

[ Voor 3% gewijzigd door CyBeR op 26-11-2011 14:30 ]

[Sendy]

Nu ook dat wikipedia-artikel gelezen. Het is een multicast-address met een heel beperkt publiek (in principe alleen interfaces die op 1:5 eindigen.)

Nog even over dat pakketje; blijkbaar is er geen code die controleerd of die multicastpakketjes zinnig zijn. Het pakketje wordt gewoon gemaakt en verstuurd.

Na nog wat te hebben geprogrammeerd is mijn Xen-host met virtuele firewall in DomU en Dom0 en andere DomU's helemaal ipv6 bedraad. (De clients waren dat al.) nu bedenken hoe ik DNS ga doen voor al die hosts. De ipv6-hosts zijn natuurlijk allemaal publiek bereikbaar en moeten dus een naam krijgen, terwijl ze niet (direct) via ipv4 te bereiken zijn...

[Sendy]

CyBeR schreef op zaterdag 26 november 2011 @ 14:30:
[...]
De reden dat je ND-queries ziet voor je eigen adres is ook heel simpel: dat is de Duplicate Address Detection die gebruikt wordt om te checken of een aan te nemen IPv6-adres niet toevallig al in gebruik is. Als je goed oplet zie je dat IPv4-stacks hetzelfde doen.

Dat dacht ik eerst ook, maar dit soort pakketjes zie ik niet meer nu ik de gateway correct heb ingesteld. Hoe dat ook zou moeten werken als er zo'n andere host is met hetzelfde ipadres snap ik niet. Waarheen stuurt deze z'n antwoord? Naar zichzelf ?

[ Voor 12% gewijzigd door Sendy op 26-11-2011 14:34 ]

[Osiris]

CyBeR schreef op zaterdag 26 november 2011 @ 14:30:
[...]

De reden dat je ND-queries ziet voor je eigen adres is ook heel simpel: dat is de Duplicate Address Detection die gebruikt wordt om te checken of een aan te nemen IPv6-adres niet toevallig al in gebruik is. Als je goed oplet zie je dat IPv4-stacks hetzelfde doen.

Dat zou m'n eerste gok zijn, al vind ik 't een beetje vaag.. Stel er is een duplicate in je netwerk. Gaat dan die 2e host (die dus het IP-adres "als eerste" had) ook reageren naar 'zichzelf'?

Ik kan met Google nergens goed vinden hoe DAD nou exact in z'n werk gaat helaas..

[CyBeR]

Sendy schreef op zaterdag 26 november 2011 @ 14:32:
[...]

Dat dacht ik eerst ook, maar dit soort pakketjes zie ik niet meer nu ik de gateway correct heb ingesteld. Hoe dat ook zou moeten werken als er zo'n andere host is met hetzelfde ipadres snap ik niet. Waarheen stuurt deze z'n antwoord? Naar zichzelf ?

Naar "zichzelf" inderdaad, dat wil zeggen het adres waar om gevraagd wordt.

[Sendy]

Ik meen dat ik vandaag geleerd heb dat een gatewayadres het best het link-localadres kan zijn. In mijn situatie heb ik twee routers en hosts op hetzelfde netwerk. Als het link-localadres gebruikt wordt is het mogelijk om ICMPv6-Redirect messages te versturen. Deze informeren de host voor betere routers.

En minder goed is dat je met xs4all native IPv6 geen reverse DNS kan krijgen

...

Maar nu krijg ik deze packets:

Bash Session:

21:35:36.858380 IP6 fe80::290:ccff:fef4:9cb4 > fe80::216:3eff:fe7e:acf0: ICMP6, neighbor solicitation, who has fe80::216:3eff:fe7e:acf0, length 32
21:35:36.858584 IP6 fe80::216:3eff:fe7e:acf0 > fe80::290:ccff:fef4:9cb4: ICMP6, neighbor advertisement, tgt is fe80::216:3eff:fe7e:acf0, length 24

Dit is een neighbor solicitation aan een link-localadres, voor hetzelfde link-localadres. Je weet zijn adres toch al?

[ Voor 38% gewijzigd door Sendy op 26-11-2011 21:56 ]