Het grote IPv6 topic

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.)

begintmeta wijzigde dit bericht 16-11-2011 21:11 (37%)

quote:

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

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.

quote:

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

quote:

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 )

.. 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

GeeBee wijzigde dit bericht 16-11-2011 21:37 (67%)

quote:

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

quote:

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.

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?

quote:

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.

quote:

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.

quote:

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

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.

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?

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

[edit]

netsh interface ipv6 show route

Is iets makkerlijker te lezen qua output.

Cheatah wijzigde dit bericht 18-11-2011 00:59 (42%)

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

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}

quote:

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

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

quote:

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.

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

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.

quote:

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.

quote:

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).

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

Opgelost: gateway stond naar zichzelf te wijzen.

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

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

Sendy wijzigde dit bericht 25-11-2011 22:06 (13%)

quote:

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

Wikipedia: Solicited-node multicast address

quote:

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

quote:

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

quote:

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.

quote:

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.

quote:

_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?

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.

quote:

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.

CyBeR wijzigde dit bericht 26-11-2011 14:30 (3%)

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...

quote:

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 ?

Sendy wijzigde dit bericht 26-11-2011 14:34 (12%)

quote:

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..

quote:

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.

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:
console:

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?

Sendy wijzigde dit bericht 26-11-2011 21:56 (38%)

Waarschijnlijk z'n MAC-adres niet (meer)

quote:

Sendy schreef op zaterdag 26 november 2011 @ 21:13:
Maar nu krijg ik deze packets:
console:

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?

Strict gezien wel want 't staat in het link-localadres, maar die aanname wordt niet gemaakt.

Als je volgende keer dat je tcpdumpt de -e flag geeft, zul je waarschijnlijk zien dat het destination MAC-adres een multicastadres is. Of, als dat niet zo is, gaat 't hier waarschijnlijk om de Neighbour Unreachability Detection. Ja, IPv6 detecteert nogal wat

Bij normaal verkeer kan de reachability-tabel geupdate worden als er verkeer ontvangen wordt, maar verkeer van een gateway heeft zelden het adres van die gateway als afzender.

CyBeR wijzigde dit bericht 26-11-2011 23:56 (9%)

Oh, ik dacht dat het macadres niet in de neighbor adv stond, dat dat adres gewoon uit het link-localadres gehaald wordt? (en dat dus afleveren van pakketjes allemaal op IP-niveau plaatsvind, i.p.v. met een ethernetconstructie zoals ARP in IPv4)

Met -e switch (goed idee):
console:

21:44:28.330447 00:16:3e:7e:ac:f0 (oui Unknown) > 00:90:cc:f4:9c:b4 (oui Unknown), ethertype IPv6 (0x86dd), length 86: fe80::216:3eff:fe7e:acf0 > fe80::290:ccff:fef4:9cb4: ICMP6, neighbor solicitation, who has fe80::290:ccff:fef4:9cb4, length 32

Met ip -6 neigh show zie ik de entry:
console:

fe80::290:ccff:fef4:9cb4 dev eth0 lladdr 00:90:cc:f4:9c:b4 router STALE

Er is dus een tabel met link-local naar mac-adres. Met de vraag in het pakketje zou je deze tabel van het "STALE" kunnen ontdoen... Ik ben matig overtuigd van het nut van het pakketje.

Sendy wijzigde dit bericht 27-11-2011 22:34 (56%)

Weet iemand hier hoe het nu zit met de irc van tweakers over ipv6? Ik heb een HE.net tunnel nu en ipv6 werkt. Als ik naar irc.tweakers.net ga komt die nog op ipv4 uit en de oude osiris.ipv6 werkt niet meer.

quote:

jimmy87 schreef op zondag 18 december 2011 @ 22:08:
Weet iemand hier hoe het nu zit met de irc van tweakers over ipv6? Ik heb een HE.net tunnel nu en ipv6 werkt. Als ik naar irc.tweakers.net ga komt die nog op ipv4 uit en de oude osiris.ipv6 werkt niet meer.

Dns record voor irc is v4 en v6
code:

tom$ host irc.tweakers.net
irc.tweakers.net is an alias for arethusa.tweakers.net.
arethusa.tweakers.net has address 213.239.154.12
arethusa.tweakers.net has IPv6 address 2001:990:0:1386:12::1

Hmm stom dat mirc hem dan niet pakt. Ik heb irc enabled bij HE.net dus dan zou het moeten werken. Maar als ik wil connecten omet mirc werkt het niet. Connection timeout.

mIRC doet toch geen IPv6?

quote:

CyBeR schreef op maandag 19 december 2011 @ 00:29:
mIRC doet toch geen IPv6?

Dat is jaren zo geweest maar:

http://www.mirc.com/whatsnew.txt

...
30/07/2010 - mIRC v7.1
...
IPv6 support
...

Dus als mIRC recent genoeg is doet die ipv6.

Ah, ok. Niks gezegd

Voor mensen die wachten op cisco anyconnect client met volledige ipv6 support :

quote:

I received confirmation that indeed the IPv6 feature, along with complete split-tunneling for IPv6, and correct handling of the exculsion, will be available in the Anyconnect version 3.1, expected for summer 2012.

Correspondingly there is no plan to fix this issue in the current versions, this is considered part of the new features.

Ik heb thuis een IPV6 tunnel liggen van sixxs.net. Ik gebruik de software AYIYA. Nu heb ik dus 2 adapters, 1 LAN, en 1 tunnel adapter.

Ping -6 ipv6.google.com werkt
tracert -6 ipv6.google.com werkt
Browsen naar het http://[2a00:1450:8005::68] lukt

Maar als ik wil surfen naar http://ipv6.google.com werkt dit niet. (server not found) Dus ik vermoed dat het een DNS fout is. Ik gebruik de opendns servers.

Als ik http://www.test-ipv6.com/ laat testen krijg ik de melding:
code:

IPv6 verbindingen werken maar verbindingen op basis van DNS namen gebruiken geen IPv6. Om een of andere reden voert uw browser of OS geen IPv6 DNS 'AAAA' opzoekingen uit.

Iemand een idee wat ik vergeten ben aan te passen? Het probleem is met elke browser.

Welk OS, welke router, en gebeurt het ook als je geen OpenDNS gebruikt maar google's public DNS (8.8.8.8, 8.8.4.4).

CyBeR wijzigde dit bericht 28-12-2011 19:33 (69%)

--edit---

Oplossing gevonden, blijkbaar moet je bij windows 7 elke fysieke adapter ook een ipv6 adres meegeven. In mijn geval dus een vast aangezien mijn router dit niet ondersteund

wouterDE wijzigde dit bericht 28-12-2011 19:52 (77%)

Sommige routers doen geintjes met DNS zodat shit 'beter werkt'.

Wat gebeurt er als je zelf een nslookup met type AAAA doet?

/meldt

Heb nu door de aanschaf van een Cisco 1811 eindelijk beschaafde IPv6 support. Ik had een 851W welke dit helemaal niet kon.

Router kwam met een 12.4(15) IOS geinstalleerd welke de router tijdelijk liet vastlopen bij een simpele nmap poortscan van de Sixxs tunnel endpoint. Hij draait nu 15.1 en alles lijkt nu redelijk te functioneren. Windows 7 bak erachter krijgt netjes een autoconfiguration adres en kan IPv6 websites oproepen.

Verder een apart ipv6 domeintje aangemaakt, ipv6.phoropter.nl en een al bestaand domein een AAAA record gegeven zodat ie ook naar ipv6 resolved.

Audiostreams in mijn signature zouden dus ook via ipv6 moeten werken

Krijg ipv6.phoropter.nl niet open van buiten af, staat webserver etc goed geconfigureerd?

quote:

wopper schreef op dinsdag 03 januari 2012 @ 07:30:
Krijg ipv6.phoropter.nl niet open van buiten af, staat webserver etc goed geconfigureerd?

Je Die server laat zich niet pingen en geeft geen antwoord op poort 80 of poort 443. Firewall nakijken?

Edit: niet goed gelezen

FiscBiker wijzigde dit bericht 03-01-2012 14:52 (8%)

Zou nu allemaal moeten werken, het een en ander met access lists lopen rommelen. Ik heb op basis van http://remcobressers.nl/2...co-877-cpe-device-simple/ een in en uitgaande access list gemaakt welke op basis van uitgaand verkeer terugkomend verkeer toelaten.

Zat nog lekker te klooien in de access list, /128 is een enkel IPv6 ip, niet /0, dat is het hele bereik aan adressen

Website werkt volgens http://ipv6-test.com/validate.php . Poorten 80, 8000 en 443 staan open naar mijn server. Heb ook al een luisteraar op mijn Icecast streams gehad.

Klopt het werkt nu je krijgt nu een 403 forbidden dus qua routering werkt het nu nog de webserver inrichten ;-)

Website is al jaren ingericht, echter alles wat ik niet expliciet toegang geef is 403

Zijn er bepaalde situaties waaronder tracerouting niet goed werkt? Ik heb een simpele setup die er ongeveer zo uitziet: client -(native)-> server -(tunnel)> broker . Tracerouting naar buiten gaat niet (althans, ik krijg alleen de router en eindpoint te zien. Maar de andere kant op gaat het probleemloos

Alles linux

Op 6 juni gaat het gebeuren:

http://www.worldipv6launch.org/

Eigenlijk is het nog grappig ook.

IPv6 had op 6-6-2006 het default protocol moeten worden. We hebben 6 jaar vertraging

Maar wat een goed nieuws, dit klinkt veelbelovend, er zitten genoeg grote jongens bij om echt een grote stap te maken. Ik ben misschien nog wel het meest onder de indruk van akamai. Ik hoop dat er nog een paar video-websites mee gaan doen. Ik denk dat Youtube het wel zal doen en ik hoop dat Netflix ook mee doet.

quote:

CAPSLOCK2000 schreef op vrijdag 20 januari 2012 @ 00:33:
Eigenlijk is het nog grappig ook.

IPv6 had op 6-6-2006 het default protocol moeten worden. We hebben 6 jaar vertraging

Maar wat een goed nieuws, dit klinkt veelbelovend, er zitten genoeg grote jongens bij om echt een grote stap te maken. Ik ben misschien nog wel het meest onder de indruk van akamai. Ik hoop dat er nog een paar video-websites mee gaan doen. Ik denk dat Youtube het wel zal doen en ik hoop dat Netflix ook mee doet.

Youtube is bij mij al maanden via IPv6, maar misschien is dat omdat ik via surfnet internet heb. Het lijkt me in ieder geval vreemd als ze niet mee zouden doen.

Volgens mijn verkeersstatistieken van m'n thuisverbinding bestaat het totaal verkeer voor 8% (laatste week) uit ipv6.

Zal voornamelijk youtube idd zijn en wat torrentzooi.

Youtube heeft geen AAAA- records (ook niet op Google's DNS server 8.8.4.4), dus het lijkt me sterk dat je nu wel op IPv6 zit.

Youtube gebruikt al heel lang IPv6 in productie, maar alleen voor hun videoservers; niet voor de website zelf.

Voorbeeld:

$ host o-o.preferred.ams04s07.v12.lscache1.c.youtube.com
o-o.preferred.ams04s07.v12.lscache1.c.youtube.com has address 74.125.100.140
o-o.preferred.ams04s07.v12.lscache1.c.youtube.com has IPv6 address 2a00:1450:400e:a::c

CyBeR wijzigde dit bericht 20-01-2012 23:38 (54%)

quote:

Jaap-Jan schreef op vrijdag 20 januari 2012 @ 23:34:
Youtube heeft geen AAAA- records (ook niet op Google's DNS server 8.8.4.4), dus het lijkt me sterk dat je nu wel op IPv6 zit.

Op de nameserver van xs4all wel
code:

@xs8:~$ host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.79.93
youtube-ui.l.google.com has address 74.125.79.136
youtube-ui.l.google.com has address 74.125.79.190
youtube-ui.l.google.com has address 74.125.79.91
youtube-ui.l.google.com has IPv6 address 2a00:1450:8005::5d

quote:

Keiichi schreef op vrijdag 20 januari 2012 @ 23:40:
[...]


Op de nameserver van xs4all wel
code:

@xs8:~$ host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 74.125.79.93
youtube-ui.l.google.com has address 74.125.79.136
youtube-ui.l.google.com has address 74.125.79.190
youtube-ui.l.google.com has address 74.125.79.91
youtube-ui.l.google.com has IPv6 address 2a00:1450:8005::5d

XS4ALL doet dan ook mee aan Google IPv6 whitelist. Maar Youtube's videoservers krijgen altijd een AAAA record.

Welke namen hebben die videoservers dan? Want ook ytimg.com (wat volgens mij het adres is van de serverpool) heeft bij mij geen AAAA- record.

Jaap-Jan wijzigde dit bericht 20-01-2012 23:47 (20%)

't is niet alsof er een in m'n post staat...

Sorry voor deze slowchat, maar .

quote:

TNW schreef op maandag 02 januari 2012 @ 16:24:
/meldt

Heb nu door de aanschaf van een Cisco 1811 eindelijk beschaafde IPv6 support. Ik had een 851W welke dit helemaal niet kon.

Router kwam met een 12.4(15) IOS geinstalleerd welke de router tijdelijk liet vastlopen bij een simpele nmap poortscan van de Sixxs tunnel endpoint. Hij draait nu 15.1 en alles lijkt nu redelijk te functioneren. Windows 7 bak erachter krijgt netjes een autoconfiguration adres en kan IPv6 websites oproepen.

Verder een apart ipv6 domeintje aangemaakt, ipv6.phoropter.nl en een al bestaand domein een AAAA record gegeven zodat ie ook naar ipv6 resolved.

Audiostreams in mijn signature zouden dus ook via ipv6 moeten werken

Ik heb een 1801w en alhoewel dit waarschijnlijk niet met die router te maken heeft, toch nog een aantal bugs in Windows wat betreft IPv6. Soms verliest Windows zijn default IPv6 gateway zonder reden (ik gebruik SLAAC met other-config-flag voor de DNS servers) en als ik inbel via PPTP dan verliest de verbinding stipt na 20 minuten zijn IPv6 gateway (op die PPTP verbinding).

Als je zelf ook begint te experimenteren met VPN's, PPTP+IPv6 & Cisco's IPv6 CEF is broken, met CEF aan op IPv6 niveau dan routert hij helemaal geen IPv6 pakketjes. Met CEF uit werkt het wel.

nieuws: Ziggo levert nog dit jaar ipv6-verbindingen

Het zal eens tijd worden

nu alle andere providers nog

Nu nog IPv6 ondersteuning in IPFire, dan kan ik eindelijk weer van mijn HE-tunnel gebruik maken.

Raven wijzigde dit bericht 02-02-2012 10:16 (34%)

quote:

Keiichi schreef op donderdag 02 februari 2012 @ 10:11:
nieuws: Ziggo levert nog dit jaar ipv6-verbindingen

Het zal eens tijd worden

nu alle andere providers nog

Op zich geen (goed/echt) nieuws, al lange tijd gaf Ziggo midden 2012 aan als doel voor ondersteuning van IPv6, het nieuws is dat het kennelijk wat later gaat worden.

quote:

RT @ayourtch: So far, there's been 6052 mac addresses on #cleur network, 1470 with only IPv4, 4238 with both v4 and v6, and 344 with only v6.

Laat ons zeggen dat je ipv6 dual stack wel populair kan hebben op sommige netwerken ;-)

Zal ziggo een /56, /48 of /64 subnet gaan uitdelen? Ik hoop toch echt ten minste een /56 zodat we zelf ons netwerk verder kunnen subnetten in meerdere /64s met op elk subnet SLAAC.

quote:

Magnetra schreef op donderdag 02 februari 2012 @ 19:00:
Zal ziggo een /56, /48 of /64 subnet gaan uitdelen? Ik hoop toch echt ten minste een /56 zodat we zelf ons netwerk verder kunnen subnetten in meerdere /64s met op elk subnet SLAAC.

Een /64 lijkt me niet het meest logisch. Je wil altijd wel een situatie hebben dat je router ook daadwerkelijk kan routeren en firewallen.

Op een colocatie van mij heb ik ook native IPv6, die bestaat uit een routing subnet. Hierin zit dan de gateway van de provider en het adres van mijn router. Richting dit IP adres van m'n router is een /56 of /48 geroutered.

Ik gok erop (ik weet niet hoe het bij xs4all native zit) dat het zo'n constructie zal zijn. Als ik ga gokken zal het niet groter dan /56 zijn.

Xs4all doet gewoon /48''s. Deden ze bij tunnels eerder ook, echter werd dat op een gegeven moment /56. Wellicht dat ze met native ook nog een keer die kant op gaan.

Voor het gemak zijn alle subnets (Behalve degene door lir's uitgegeven) veelvouden van 8. (blokje van 2 hex-chars). Heeft dit ook een router-technische rede?

Op een FreeBSD router ben ik namelijk een /64 block aan het verdelen in /126 blokjes. Rede dat ik hiermee aan het spelen ben, is dat ik het eigenlijk maar raar vind dat bv voor een tunnel er een gehele /64 gebruikt word alleen voor de endpoints.

Het is natuurlijk niet zo dat we snel IPv6 adressen tekort gaan komen, maar ik kan me voorstellen dat als je op hele grote schaal gaat werken dat je toch ergens tegen limieten aan kan komen en weer een nieuw subnet moet gaan aanvragen (/48 -> /56 is slehts een opdeling van 256 subnets)

sinds 24 januari worden er IPv6 prefixes van ziggo geannounced: 2001:41f0::/32, 2001:b88::/33, 2001:1c00::/23 . Wat zou 'later' dit jaar zijn. Ik vermoed dat ze al een eind op weg zijn.

quote:

henet (Hurricane Electric @ Twitter)
Heard this one already? "Maybe we should take advantage of Apple's popularity. Instead of IPv6, we could all start writing iPV6."

Misschien wordt IPv6/iPv6 dan wat sneller ingevoerd (Of Apple stapt naar de rechter....)

Raven wijzigde dit bericht 03-02-2012 09:43 (7%)

Er was op ciscolive vorige week een sessie over ipv6 deployment bij comcast, spijtig genoeg niet kunnen volgen, maar ik zal eens kijken of de sessie opgenomen is. Slides moeten in ieder geval beschikbaar zijn.

Iemand idee hoe je osx (lion) zover kan krijgen om ook z'n ipv6 adressen te registreren bij de dns server ?

(op windows moet dit door DisableReverseAddressRegistrations registry entry aan te maken met waarde 0 (default is 1))

Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

Ik hoor hier iedereen over subnets bij IPv6 e.d., maar ik heb altijd begrepen dat IPv6 aan vaste "subnets" van /64 heeft. In radvd kun je ook geen range >/64 opgeven om te advertisen.

Volgens mij mag je subnetten tot in de kleinste bits, maar autoconfiguration (waarvoor radvd nodig is) kan niet met een kleiner subnet dan /64

quote:

Keiichi schreef op woensdag 08 februari 2012 @ 11:01:
Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

Ben het net tegengekomen in mijn ccie boek het 7e bit is het U/L bit van het Mac adres. De reden dat het gedaan wordt wordt ook niet behandeld. Ik kan mijn ipv6 boek er nog even bijpakken.

quote:

The flip in step 2 has a reason. Ethernet devices usually come with a pre-configured MAC address, which is globally unique - this bit happens to be 0 if the MAC is globally assigned. This flip ensures that autoconfigured host IDs always use a large number as host ID, so that the administrator can use small numbers for manually configured hosts without risking a random collision with a MAC address.

Beetje hypothetisch geval want als je al iets statisch toewijst zal je vaker enkel de laatste 2 of 4 bytes aanpassen en de rest ervoor 0 dus altijd lager doordat die FFFE van autoconfig het al redelijk random maakt.

TrailBlazer wijzigde dit bericht 08-02-2012 21:16 (39%)

quote:

Sendy schreef op woensdag 08 februari 2012 @ 21:06:
Volgens mij mag je subnetten tot in de kleinste bits, maar autoconfiguration (waarvoor radvd nodig is) kan niet met een kleiner subnet dan /64

Klopt daarom kan je in radvd nooit kleiner dan /64 want stateloze autoconfig gaat dan de mist in. Op een PtP kan je wel een /126 gebruiken. /127 schijnt problemen te geven om een of andere reden ik vindt het sowieso onhandig om te doen.

quote:

Osiris schreef op woensdag 08 februari 2012 @ 20:59:
Ik hoor hier iedereen over subnets bij IPv6 e.d., maar ik heb altijd begrepen dat IPv6 aan vaste "subnets" van /64 heeft. In radvd kun je ook geen range >/64 opgeven om te advertisen.

Wat je met je subnets doet moet je helemaal en volledig zelf weten. Maar Stateless-autoconfig werkt alleen met /64 subnets.

quote:

Keiichi schreef op woensdag 08 februari 2012 @ 11:01:
Ik ben eigenlijk op zoek naar het verhaal van de 7de bit die geflipped word bij het maken van een LL adres. Maar ik kan het nergens vinden. Heeft iemand een kleine uitleg van het hoe en waarom?

quote: http://tools.ietf.org/html/rfc5342#section-2.2.1

The Local/Global bit was inverted to make it easier for network
operators to type in local-scope identifiers. Thus, such Modified
EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are
local. Without the modification, they would have to be
02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local.

CyBeR wijzigde dit bericht 08-02-2012 21:24 (36%)

Dat heeft mijn inziens niks met elkaar te maken. Je zou ook zonder die Flip een geldig adres krijgen.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:22:
Dat heeft mijn inziens niks met elkaar te maken. Je zou ook zonder die Flip een geldig adres krijgen.

Geldig is 't sowieso, maar 't gaat om semantiek.

Anyway, ik heb mijn post geupdate met de werkelijke reden uit de RFC; eerder had ik 't ergens anders van.

Dat zou dus beteken dat ik geen ipv6 adres
02-00-00-00-00-00-00-02 zou kunnen configureren omdat dat ipv6 adres bij autoconfig zou horen.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:38:
Dat zou dus beteken dat ik geen ipv6 adres
02-00-00-00-00-00-00-02 zou kunnen configureren omdat dat ipv6 adres bij autoconfig zou horen.

Strict gezien correct.

<< Even het logo van kame.net wat verkleind voor dit forum. En natuurlijk alleen te zien indien de client verbindt met IPv6.

Ehm, ik zie gewoon een plaatje, zonder IPv6 (helaas). Of hoort het een animatie te zijn indien IPv6 werkt?

Hij zwemt weg

quote:

Raven schreef op donderdag 09 februari 2012 @ 16:38:
Ehm, ik zie gewoon een plaatje, zonder IPv6 (helaas). Of hoort het een animatie te zijn indien IPv6 werkt?

Dan werkt het precies zoals het hoort.

Verbindt je met IPv4: statisch plaatje.
Verbindt je met IPv6: bewegend plaatje.

Zo was het ook op http://www.kame.net/

quote:

Keiichi schreef op donderdag 09 februari 2012 @ 16:40:
Hij zwemt weg

Ik heb alleen een of andere lelijkerd met een nikon strap om z'n hoofd.

quote:

Jaap-Jan schreef op donderdag 09 februari 2012 @ 16:41:

Althans, dat probeert ie.

quote:

TrailBlazer schreef op woensdag 08 februari 2012 @ 21:09:
[...]

Klopt daarom kan je in radvd nooit kleiner dan /64 want stateloze autoconfig gaat dan de mist in. Op een PtP kan je wel een /126 gebruiken. /127 schijnt problemen te geven om een of andere reden ik vindt het sowieso onhandig om te doen.

Bij /127 heb je alleen een netwerk en 'broadcast' adres. Het lijkt me dan vrij logisch dat het problematisch is.

Keiichi wijzigde dit bericht 09-02-2012 16:46 (61%)

quote:

CyBeR schreef op donderdag 09 februari 2012 @ 16:42:
Ik heb alleen een of andere lelijkerd met een nikon strap om z'n hoofd.

Check. Dan heb je webicons uitgeschakeld. En bedankt voor het compliment.

Jaap-Jan wijzigde dit bericht 09-02-2012 16:45 (7%)

quote:

Jaap-Jan schreef op donderdag 09 februari 2012 @ 16:41:
[...]

Dan werkt het precies zoals het hoort.

Verbindt je met IPv4: statisch plaatje.
Verbindt je met IPv6: bewegend plaatje.

Zo was het ook op http://www.kame.net/

Ah okee
Hopelijk komt er eens een keer IPv6 ondersteuning in IPFire...

quote:

Keiichi schreef op donderdag 09 februari 2012 @ 16:43:
[...]
Bij /127 heb je alleen een netwerk en 'broadcast' adres. Het lijkt me dan vrij logisch dat het problematisch is.

Met IPv4 heb je dat probleem ook met /31's op p2p interfaces. Echter hebben ze daar wel een RFC over geschreven: http://www.ietf.org/rfc/rfc3021.txt

Tweakers.net op 6 juni over IPv6 bereikbaar?
Bron: reviews: Tweakers.net-serverbeheer: Project Phoenix

Goed zoeken waar het staat

quote:

Magnetra schreef op zondag 12 februari 2012 @ 01:28:
Tweakers.net op 6 juni over IPv6 bereikbaar?
Bron: reviews: Tweakers.net-serverbeheer: Project Phoenix

Goed zoeken waar het staat

Gevonden!

Ik ben benieuwd! Het zou wel eens tijd worden