Het grote IPv6 topic

[CyBeR]

code:

[marco@elara www]$ ping6 -I vlan4 ff02::1
PING6(56=40+8+8 bytes) fe80::217:f2ff:fed6:bfa2%vlan4 --> ff02::1
16 bytes from fe80::217:f2ff:fed6:bfa2%vlan4, icmp_seq=0 hlim=64 time=0.138 ms
16 bytes from fe80::200:24ff:fec9:6051%vlan4, icmp_seq=0 hlim=64 time=17.127 ms
16 bytes from fe80::20c:42ff:fe2e:a247%vlan4, icmp_seq=0 hlim=64 time=17.280 ms

Maar dan moeten die hosts wel op multicast ping reageren.

1000 \o/

[Osiris]

Snow_King schreef op vrijdag 24 september 2010 @ 16:17:
[...]
Wel even je NIC meegeven, dus -I eth0, eth1 of whatever.

Ah, ja, ik dacht van: ik heb maar 1 ethX, dus hoeft niet

Maar de hosts reageren met hun fe80::/64-adres. Dus dan weet je alleen maar dat ze een IPv6-stack hebben (mag ik hopen voor kees ), maar niet of ze ook een publiek IP uit de RA gebruiken.

[ Voor 29% gewijzigd door Osiris op 24-09-2010 16:29 ]

[Kees]

Uhuh, ik krijg ook alleen de fe80 te zien. In principe kun je daar dus wel weer mbv het mac adres achterhalen welke hosts dat zijn, maar niet of ze ook een publiek adres hebben. Toch true eens verzoeken de router advertisements uit te zetten

Anyway, true heeft het uitgezet, dus nu maar weer wachten op mijn sixxs tunnel, en dan kan ik weer verder testen op tweakers.net (irc, en 1 webserver hebben het al). Overigens; welke tweaker heeft mijn account daar geapproved? Bedankt voor de extra credits

[ Voor 35% gewijzigd door Kees op 24-09-2010 18:12 ]

[CyBeR]

True zou dat overal uit moeten hebben staan.

[Snow_King]

CyBeR schreef op vrijdag 24 september 2010 @ 18:48:
True zou dat overal uit moeten hebben staan.

Eens, want je wil niet dat ineens al je hosts IPv6 doen.

De multicast ping is idd niet wat je zoekt, je kan wel wat scripten er omheen, maar dat schiet niet op lijkt me.

Ik blijf het nog steeds leuk vinden voor op een kantoor / thuis, maar verder niet. Daarnaast krijgt de client ook geen DNS, dus waarom dan geen DHCPv6? Dan heb je direct meer controle.

[axis]

Bij xs4all colo krijg je iig gewoon op verzoek een /48, router advertisements staan daar ook uit. Ondertussen bijna ons hele serverpark bij xs4all native op ipv6, werkt allemaal als een zonnetje. Xs4all had me laatst ook nog gevraagd om een praatje te komen houden bij een ipv6 informatieavond voor hun coloklanten (crazy colonight), maar is afgeblazen omdat er te weinig animo was. Snap nog steeds niet dat er te weinig animo is. Iedereen zou nu toch als een gek bezig moeten zijn om ipv6 door te voeren in hun colo? Naja..

[Osiris]

Kees schreef op vrijdag 24 september 2010 @ 17:44:
Uhuh, ik krijg ook alleen de fe80 te zien. In principe kun je daar dus wel weer mbv het mac adres achterhalen welke hosts dat zijn, maar niet of ze ook een publiek adres hebben.

Maar a.d.v. die MAC-adressen kun je wél hun auto-negotiated public IP's gokken

Nou ja, gokken.. Gewoon fe80 vervangen door m'n prefix en ik had 't autonegotiated IP van m'n desktop. M'n server draait radvd en doet derhalve blijkbaar niet aan autonegotiated IP's van zichzelf verkrijgen, dus die was niet "beschikbaar" en voor de rest staat er niets aan in m'n netwerk. Maar ik gok dat 't in 't algemeen wel werkt

axis schreef op vrijdag 24 september 2010 @ 19:25:
Iedereen zou nu toch als een gek bezig moeten zijn om ipv6 door te voeren in hun colo? Naja..

Ach, als zelfs de heren bij Tweakers note bene al zoiets hebben van "Huh? IPv6? Kun je dat eten?" (gechargeerd ), dan kun je moeilijk verwachten dat anderen daar wél enorm mee bezig zijn

[ Voor 53% gewijzigd door Osiris op 24-09-2010 23:52 ]

[Mawlana]

Tot vandaag had ik alleen IPv6-access vanaf mijn router (Debian-bak). Ik kreeg het maar niet werkend op mijn lan-clients. Zodra ik radvd gebruikte werkte IPv6 ook niet meer op de router. Vandaag wilde ik nog een poging wagen, en met succes!

Volgens tunnelbroker.net is mijn Client IPv6 address 2001:470:1f14:xxxx::2/64. In radvd.conf had ik dan ook 2001:470:1f14:xxxx::/64 als prefix staan. Mijn routed /64 prefix is echter 2001:470:1f15:xxxx::/64.

Wat een tikfout (en gebrek aan IPv6-kennis) al niet kan doen hè?

* Mawlana gaat weer verder experimenteren met IPv6....

[Verwijderd]

Ik heb sinds kort een Fritzbox 7340 met Firmware-Version 99.04.85-18221. (let op: is beta firmware)

Momenteel draait hij dual stack met ipv4 en ipv6 naast elkaar. Nu wil ik ook dat mijn router (fritzbox) naast het uitdelen van lokale ipv4 adressen ook ipv6 uitdeelt. Ik heb Ubuntu draaien op mijn pc.

Ik heb het idee dat ik zelf zal moeten rommelen op mijn bak om eerst ipv6 adres (d.m.v. dhcp) van de fritzbox moet afvangen, en als laaste ipv4. Maar tot nu toe wil dat allemaal niet echt lukken.

radvd is geen optie. Hiermee maak je je eigen pc tot een router. Maar ik wil juist dat mijn fritzbox het zelf uitdeelt in mijn lokale netwerk.
Een overzicht van mijn huidige ipconfig:

jpvzijst@AMD3000:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:92:2b:9e:35
inet addr:192.168.178.20 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 2001:980:XXXX:1:21a:XXXX:fe2b:9e35/64 Scope:Global
inet6 addr: fe80::21a:92ff:fe2b:9e35/64 Scope:Link Dit is mijn lokale adres, maar komt niet overeen op de fritzbox!)
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6740 errors:0 dropped:0 overruns:0 frame:0
TX packets:7162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4946026 (4.9 MB) TX bytes:1268046 (1.2 MB)
Interrupt:20 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2236 errors:0 dropped:0 overruns:0 frame:0
TX packets:2236 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:112233 (112.2 KB) TX bytes:112233 (112.2 KB)

Googlen leverde mij niet echt een goede howto om mijn netwerkkaart ipv6 als voorkeursadres te krijgen.
Misschien dat jullie mij de goede richting op kunnen duwen?

Wat ook wel jammer is dat de fritzbox alleen maar 1 ipv6 adres toont die hij van xs4all heeft. De adressen op mijn lokale netwerk is alleen maar in ipv4

[ Voor 3% gewijzigd door Verwijderd op 27-09-2010 22:19 ]

[Osiris]

Hij heeft toch al gewoon een publiek IP-adres?

En je Linux heeft verder geen moer te maken met de keuze tussen IPv4 of IPv6. Dat is geheel aan de applicatie.

Zo heeft Firefox de optie `network.dns.disableIPv6` in `about:config`. Zet die op "true" en je zult alleen via IPv4 werken. Laat je hem op "false" staan, dan zal ie eerst IPv6 proberen.

De Fritz!Box doet aan LAN-zeide gewoon stateless address autoconfiguration, as in, radvd-achtige praktijken.

[ Voor 13% gewijzigd door Osiris op 27-09-2010 22:28 ]

[Verwijderd]

Osiris schreef op maandag 27 september 2010 @ 22:25:
Hij heeft toch al gewoon een publiek IP-adres?

Zo heeft Firefox de optie `network.dns.disableIPv6` in `about:config`. Zet die op "true" en je zult alleen via IPv4 werken. Laat je hem op "false" staan, dan zal ie eerst IPv6 proberen.

Dat staat standaard al op false. Het gaat niet om de browser, maar om het lokale netwerk.

[Osiris]

Wat heeft je lokale netwerk er mee te maken? Layer 2 switches zijn transparant voor IPv4 of IPv6.

En je bak heeft gewoon een publiekelijk IPv6-adres?

Wát werkt er niet en wát heb je allemaal al geprobeerd?

Je hebt het over éérst IPv6 met DHCP zien te verkrijgen en dáárna pas IPv4 ofzo. Waarom in vredesnaam? Nergens voor nodig? Nog afgezien van het feit dat je sowieso geen DHCP dient te gebruiken voor IPv6 (De Fritz!Box doet alleen SLAAC, er draaien geen DHCP-daemons) maakt het echt he-le-maal niets uit wanneer je je IPv6 of IPv4 IP krijgt. De applicatie maakt contact met een bepaald IP-adres en die bepaalt of het IPv4 of IPv6 is. Niet de kernel.

[ Voor 54% gewijzigd door Osiris op 27-09-2010 22:36 ]

[CyBeR]

Verwijderd schreef op maandag 27 september 2010 @ 22:17:

jpvzijst@AMD3000:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:92:2b:9e:35
inet addr:192.168.178.20 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 2001:980:XXXX:1:21a:XXXX:fe2b:9e35/64 Scope:Global

Je hebt al IPv6.

inet6 addr: fe80::21a:92ff:fe2b:9e35/64 Scope:Link Dit is mijn lokale adres, maar komt niet overeen op de fritzbox!)

Dat hoort ook niet, want dat adres is je link-local adres.

[Verwijderd]

CyBeR schreef op maandag 27 september 2010 @ 22:41:
[...]


Je hebt al IPv6.

Maar dat is het adres dat de fritzbox reachtstreeks van xs4all heeft. Ik wou juist graag zien dat de fritz sub ip's uitdeelt op basis van mijn hoofd-IP adres. M.a.w. zodat mijn bakkie van buitenaf benaderbaar is.

Dat hoort ook niet, want dat adres is je link-local adres.

Link local klopt, maar je kan met de ipv4 / ipv6 calculator zien of het gegeven ipv6 adres op mijn bak, ook hetzelfde is als het ipv4 adres op mijn modem. Bijvoorbeeld AAB -->> calculator --->> BBC en vice versa.


Ik hoop dat ik het nog een beetje helder uitgelegd heb met wat ik in gedachten heb. Want zeg nou zelf, een /64 aan eigen ip adressen Dan wil ik graag dat mijn pc's ook een eigen ipadres heeft. Op veiligheid heb ik al prima voor elkaar. Hetzelfde heb ik nu al met ipv4, maar dan met NAT en poortforwarding op mijn fritzje.

[Snow_King]

Huh, ik volg je niet? Dat IP adres wat je desktop heeft is gewoon publiek bereikbaar?

[Verwijderd]

Snow_King schreef op dinsdag 28 september 2010 @ 18:44:
Huh, ik volg je niet? Dat IP adres wat je desktop heeft is gewoon publiek bereikbaar?

Nee, want dat is een publiek ipv6 adres van mijn modem zelf


Wat ook jammer is dat portforwarding op ivp6 niet gaat op de fritz. Hij slikt alleen maar ip4.

In dat geval zou ik eens moeten kijken voor een 2de hands Cisco.

[ Voor 23% gewijzigd door Verwijderd op 28-09-2010 19:36 ]

[CyBeR]

Verwijderd schreef op dinsdag 28 september 2010 @ 18:47:
[...]


Nee, want dat is een publiek ipv6 adres van mijn modem zelf

AMD3000 is toch niet je modem? Dat is dus een adres dat je computer bedacht heeft aan de hand van een router advertisement van je modem.

Wat ook jammer is dat portforwarding op ivp6 niet gaat op de fritz. Hij slikt alleen maar ip4.

Dat is ook de bedoeling. Het idee is dat je met IPv6 geen poorten meer hoeft te forwarden omdat je machine gewoon direct bereikbaar is. Port forwarding moet met NAT en dat hoeft met IPv6 niet.


Volgens mij denk je teveel in IPv4 + NAT. Laat dat idee eens compleet gaan.

[ Voor 6% gewijzigd door CyBeR op 28-09-2010 19:45 ]

[Verwijderd]

CyBeR schreef op dinsdag 28 september 2010 @ 19:44:
[...]


AMD3000 is toch niet je modem? Dat is dus een adres dat je computer bedacht heeft aan de hand van een router advertisement van je modem.


[...]


Dat is ook de bedoeling. Het idee is dat je met IPv6 geen poorten meer hoeft te forwarden omdat je machine gewoon direct bereikbaar is. Port forwarding moet met NAT en dat hoeft met IPv6 niet.


Volgens mij denk je teveel in IPv4 + NAT. Laat dat idee eens compleet gaan.

You're right. Ik denk iets teveel NAT en ipv4 Nu realiseer ik mij ineens dat ik van xs4all 2001:980:4a22::/48 heb, dus alles na de 3 blokken heb ik voor mijzelf. Toch?

In dat geval praat mijn Ubuntu-bak goed Weer wat geleerd!

[CyBeR]

Ja, en je modem maakt daar dan weer automatisch 2001:890:4a22:1::/64 van, en daarin zit je amd3000 machine met bovenstaand adres.

[Verwijderd]

tnx voor het wakker schudden dat ik teveel in ipv4 constructies zat te denken

[Snow_King]

Verwijderd schreef op dinsdag 28 september 2010 @ 20:13:
tnx voor het wakker schudden dat ik teveel in ipv4 constructies zat te denken

Np!

Nog voor de zekerheid:

code:

ping6 ipv6.google.com

Dat werkt toch gewoon? En het hele fijne aan IPv6 is juist het ontbreken van al die NAT constructies!

[Osiris]

Overigens heb je in je 1e post 't een en ander gecensureerd, maar we kunnen probleemloos ondertussen met de nieuwe info door je gegeven achter het publieke IP van je AMD3000 komen

[CyBeR]

En zonder zou 't ook een kwestie zijn van 65536 mogelijkheden.

[moto-moi]

Ik ben inmiddels wat verder met m'n opzet thuis, maar ik loop tegen het volgende aan: ik vind het hip als ik hosts op hun hostname kan benaderen.Daar valt uiteraard weinig over te vinden , maar ik kwam op een gegeven moment de optie dhcpv6 of radv tegen. Aangezien ik isc-dhcp ken, dacht ik die te gebruiken, tegenslotte heb ik bij ipv4 ook dhcp en een locale dns-server nodig. Ik wil dus hetzelfde met ipv6. Probleem waar ik tegenaan loop is dat het met isc-dhcpd niet mogelijk is om 1 daemon te starten die allebei doet.
Uiteraard kan ik de daemon een 2e keer starten, maar ik vraag me af hoe jullie dat opgelost hebben want ik geloof niet dat dit de beste oplossing is.

Puur ipv6 kan niet, want ik geloof niet dat mijn blik, mijn xbox en mijn chumby allemaal lief ipv6 ondersteunen

[Osiris]

DHCPv6 is in principe niet nodig zodra je d.m.v. radvd je LAN voorziet van SLAAC.

En BIND kan prima AAAA-records bevatten uiteraard.

Of wil je de hostnames echt automagisch kunnen benaderen i.p.v. "static" in een zone-file?

Hm, maar wacht eens, zo'n "automagische hostname" is toch dat Windows NetBIOS-gedoe? Of heb ik dat mis?

Verder:

quote: http://ipv6int.net/software/isc_dhcp_dhcpv6.html

The original ISC DHCP software package includes IPv6 support for DHCPv6 since the 4.x releases, with basic DHCPv6 server, client and relay functionality. Not all IPv6 features work on all platforms.

Zou dus ook gewoon met 1 daemon moeten kunnen?

[ Voor 46% gewijzigd door Osiris op 29-09-2010 08:05 ]

[Keiichi]

Osiris schreef op woensdag 29 september 2010 @ 07:57:
DHCPv6 is in principe niet nodig zodra je d.m.v. radvd je LAN voorziet van SLAAC.

Ik zal wel spuit 11 zijn, maar RA geeft volgens mij geen DNS servers mee. ( in ieder geval de laatste keer dat ik keek )

[axis]

moto-moi schreef op woensdag 29 september 2010 @ 07:30:
Ik ben inmiddels wat verder met m'n opzet thuis, maar ik loop tegen het volgende aan: ik vind het hip als ik hosts op hun hostname kan benaderen.Daar valt uiteraard weinig over te vinden , maar ik kwam op een gegeven moment de optie dhcpv6 of radv tegen. Aangezien ik isc-dhcp ken, dacht ik die te gebruiken, tegenslotte heb ik bij ipv4 ook dhcp en een locale dns-server nodig. Ik wil dus hetzelfde met ipv6. Probleem waar ik tegenaan loop is dat het met isc-dhcpd niet mogelijk is om 1 daemon te starten die allebei doet.
Uiteraard kan ik de daemon een 2e keer starten, maar ik vraag me af hoe jullie dat opgelost hebben want ik geloof niet dat dit de beste oplossing is.

Puur ipv6 kan niet, want ik geloof niet dat mijn blik, mijn xbox en mijn chumby allemaal lief ipv6 ondersteunen

Wat wil je nu precies? Want ik begrijp je denk ik niet goed.. Als je hosts op hun hostname wilt bereiken heb je toch alleen een dns server nodig met daarin records voor elke host? Met dynamic updates kunnen hosts hun ip wijzigen in de dns, en klaar. Geen dhcpv6 nodig.

Je kunt ook zowel de dhcp als de dhcpv6 daemon installeren en draaien, beide losse daemons met losse installatiefiles last time I checked:

$ yum search dhcp | grep -i server | grep -i dhcp
dhcp.x86_64 : DHCP (Dynamic Host Configuration Protocol) server and relay agent.
dhcpv6.x86_64 : DHCPv6 - DHCP server and client for IPv6


Ik heb een keer dhcpv6 draaiend gehad in een testinstelling, om nameservers uit te delen aan clients. Dat is nou net een optie die je niet met radvd aan je clients kunt geven, en dus nodig in een ipv6-only opstelling. Maar toen kwam ik erachter dat je op de meeste clients ook nog handmatig een dhcpv6-client moest installeren, omdat die niet standaard aanwezig is op FreeBSD/CentOS distro's. Vond ik teveel moeite..

[ Voor 4% gewijzigd door axis op 29-09-2010 08:56 ]

[moto-moi]

axis schreef op woensdag 29 september 2010 @ 08:55:
Wat wil je nu precies? Want ik begrijp je denk ik niet goed.. Als je hosts op hun hostname wilt bereiken heb je toch alleen een dns server nodig met daarin records voor elke host? Met dynamic updates kunnen hosts hun ip wijzigen in de dns, en klaar. Geen dhcpv6 nodig.

dat dynamic update gedeelte wordt getriggered vanuit dhcp, zo werkt het in ieder geval met dhcpv4

Je kunt ook zowel de dhcp als de dhcpv6 daemon installeren en draaien, beide losse daemons met losse installatiefiles last time I checked:
$ yum search dhcp | grep -i server | grep -i dhcp
dhcp.x86_64 : DHCP (Dynamic Host Configuration Protocol) server and relay agent.
dhcpv6.x86_64 : DHCPv6 - DHCP server and client for IPv6

Dat is waarschijnlijk dezelfde daemon, die net even anders wordt aangeroepen ( -4 vs -6 )

Ik heb een keer dhcpv6 draaiend gehad in een testinstelling, om nameservers uit te delen aan clients. Dat is nou net een optie die je niet met radvd aan je clients kunt geven, en dus nodig in een ipv6-only opstelling. Maar toen kwam ik erachter dat je op de meeste clients ook nog handmatig een dhcpv6-client moest installeren, omdat die niet standaard aanwezig is op FreeBSD/CentOS distro's. Vond ik teveel moeite..

Gelukkig gebruik ik debian/ubuntu, dus die adressen worden wel opgeprikt zodra ik ze uit zou geven op mijn netwerk

[axis]

Leuk artikel: http://arstechnica.com/bu...ansition-will-be-ugly.ars (kwam langs op de ipv6-tf list)

[moto-moi]

Ik heb het nu half aan de praat met radvd:

code:

interface eth0
{
   AdvSendAdvert on;
   AdvHomeAgentFlag off;
   
   prefix <xs4allprefix>::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
   };
};

code:

# First, delete all:
ip6tables -F
ip6tables -X

# Allow anything on the local link
ip6tables -A INPUT  -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

# Allow anything out on the internet
ip6tables -A OUTPUT -o sixxs -j ACCEPT

# Allow the localnet access us:
ip6tables -A INPUT    -i eth0  -j ACCEPT
ip6tables -A OUTPUT   -o eth0   -j ACCEPT

# Filter all packets that have RH0 headers:
ip6tables -A INPUT -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP

# Allow Link-Local addresses
ip6tables -A INPUT -s fe80::/10 -j ACCEPT
ip6tables -A OUTPUT -s fe80::/10 -j ACCEPT

# Allow multicast
ip6tables -A INPUT -s ff00::/8 -j ACCEPT
ip6tables -A OUTPUT -s ff00::/8 -j ACCEPT

# Allow ICMPv6 everywhere
ip6tables -I INPUT  -p icmpv6 -j ACCEPT
ip6tables -I OUTPUT -p icmpv6 -j ACCEPT
ip6tables -I FORWARD -p icmpv6 -j ACCEPT

ip6tables -A INPUT -i xs6all -p ipv6-icmp -j ACCEPT
ip6tables -A OUTPUT -o xs6all -p ipv6-icmp -j ACCEPT

# Allow forwarding
ip6tables -A FORWARD -m state --state NEW -i eth0 -o xs6all -s <xs4allprefix>::/48 -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH in
ip6tables -A FORWARD -i xs6all -p tcp --dport 22 -j ACCEPT
# Bittorrent
ip6tables -A FORWARD -i xs6all -p tcp --dport 33600:33604 -j ACCEPT

# Set the default policy
ip6tables -P INPUT   DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT  DROP

Alleen heb ik geen toffe ddns, dus ik gok dat ik toch naar isc-dhcpd moet gaan kijken

[jschot]

Keiichi schreef op woensdag 29 september 2010 @ 08:55:
Ik zal wel spuit 11 zijn, maar RA geeft volgens mij geen DNS servers mee. ( in ieder geval de laatste keer dat ik keek )

RFC 5006 (uit 2007) geeft RA een extra Recursive DNS Server (RDNSS) optie hiervoor. Ik weet dat radvd dit serverside implementeerd. Ik weet niet welke platformen dit clientside implementeren, maar ik verwacht dat Linux hier mee over weg kan. Mijn mac in ieder geval niet.

[Snow_King]

jschot schreef op donderdag 30 september 2010 @ 22:03:
[...]


RFC 5006 (uit 2007) geeft RA een extra Recursive DNS Server (RDNSS) optie hiervoor. Ik weet dat radvd dit serverside implementeerd. Ik weet niet welke platformen dit clientside implementeren, maar ik verwacht dat Linux hier mee over weg kan. Mijn mac in ieder geval niet.

Dat is wel ideaal! Heb het hier gelijk in radvd.conf gezet, kijken of mijn netwerk het gaat snappen.

Ben bezig met een IPv6 only (Is alleen intern gebruik) netwerk in het datacenter en daar komt stateless configuratie zo wel uit.

[axis]

Kwam er deze week achter dat er schijnbaar al maanden (jaren) lang een bug zit in de named version die bij CentOS 5.4 en 5.5 zit (BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2), waardoor ie niet luistert op ipv6 interfaces. Ook al heb je perfecte ipv6 interfaces, hij spuugt bij het opstarten altijd uit: "no IPv6 interfaces found".

Ik ben niet de enige: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/249824.

Je zou toch verwachten dat als je RHEL of CentOS gebruikt dit soort bugs allang verholpen zouden zijn, maar goed..

[ Voor 3% gewijzigd door axis op 30-09-2010 23:21 ]

[Osiris]

Hm, dat RDNSS is leuk en aardig in radvd en werkt ook:



Máár... Zodra ik alles comment in /etc/resolv.conf, dan vindt m'n systeem dus mooi geen DNS-server meer, ondanks dat er in `man radvd.conf` staat dat de meegegeven RDNSS in de RA's resolv.conf aanvullen cq. overrulen..

Moet ik 't nog "aanzetten" op m'n Linux-bak ofzo? Ik kon er niets over vinden in /proc/sys/net/ipv6/conf/all...

edit:

Grom, daar heb je blijkbaar weer losse tooltjes voor nodig als rdnssd e.d...

Mooizo, dat werkt ook weer

Nu nog een DNS-"proxy" op m'n server die bij 't opvragen van een AAAA-record een A-record opvraagt (bij afwezigheid van daadwerkelijk AAAA-record) en daar een AAAA-record van bouwt met een 6to4-IPv6-IP, zodat mijn bak daarmee gaat connecten. En uiteraard moet m'n server dan ook weer de conversiestap 6to4-IPv6-IP -> IPv4 maken en vica versa.
Op die manier zou m'n LAN compleet IPv6 kunnen worden mét backwards compatibility

[ Voor 33% gewijzigd door Osiris op 01-10-2010 02:49 ]

[CAPSLOCK2000]

moto-moi schreef op woensdag 29 september 2010 @ 07:30:
Ik ben inmiddels wat verder met m'n opzet thuis, maar ik loop tegen het volgende aan: ik vind het hip als ik hosts op hun hostname kan benaderen.Daar valt uiteraard weinig over te vinden , maar ik kwam op een gegeven

Wil je dat je hosts voor de hele wereld benaderbaar zijn of alleen binnen je eigen LAN?
In dat laatste geval moet je eens kijken naar MDNS (multicast dns). Onder debian heb je de pakketten libnss-mdns en avahi-daemon nodig. Dat installeer je op al je machines en dan kunnen ze elkaar op naam vinden. ('t zou ook met MacOSX moeten werken).

[moto-moi]

CAPSLOCK2000 schreef op zaterdag 02 oktober 2010 @ 23:32:
Wil je dat je hosts voor de hele wereld benaderbaar zijn of alleen binnen je eigen LAN?

Alleen binnen mijn eigen lan, de rest hoeft niet te weten waar m'n clienst precies uithangen, al zijn ze via ssh wel direct vanaf buiten bereikbaar

In dat laatste geval moet je eens kijken naar MDNS (multicast dns). Onder debian heb je de pakketten libnss-mdns en avahi-daemon nodig. Dat installeer je op al je machines en dan kunnen ze elkaar op naam vinden. ('t zou ook met MacOSX moeten werken).

Ah, Avahi, dat zegt me wel vaag iets, ga ik naar kijken. Thanks

[Verwijderd]

Ik weet niet of het aan de orde geweest is, maar hoe gaat Ziggo bijvoorbeeld ipv6 aan de klanten (noobs) aanbieden? Wat met de in gebruik zijnde routers? Nu is ipv6 nog iets voor "nerds" Straks moet iedereen eraan. Vertel.......

[axis]

Verwijderd schreef op donderdag 07 oktober 2010 @ 03:02:
Ik weet niet of het aan de orde geweest is, maar hoe gaat Ziggo bijvoorbeeld ipv6 aan de klanten (noobs) aanbieden? Wat met de in gebruik zijnde routers? Nu is ipv6 nog iets voor "nerds" Straks moet iedereen eraan. Vertel.......

Men krijgt dan gewoon nieuwe modems.. Net zoals mensen die van ADSL naar ADSL2+ gingen een nieuwe modem nodig hadden en mensen die van DOCSIS2.0 naar DOCSIS3.0. En ziggo zal er nog wel een paar jaar voor uittrekken denk ik

[Roetzen]

Je kunt nu al van Ziggo een DOCSIS 3.0 modem krijgen door je snelheid te upgraden tot 50 Mbps of meer. Maar daar heb je qua IPv6 weinig of niets aan, want als Ziggo al plannen heeft voor het op korte termijn beschikbaar maken van native IPv6, dan zijn ze daar heel stilletjes over.

[Osiris]

Roetzen schreef op donderdag 07 oktober 2010 @ 09:59:
Je kunt nu al van Ziggo een DOCSIS 3.0 modem krijgen door je snelheid te upgraden tot 50 Mbps of meer. Maar daar heb je qua IPv6 weinig of niets aan, want als Ziggo al plannen heeft voor het op korte termijn beschikbaar maken van native IPv6, dan zijn ze daar heel stilletjes over.

IPv6-support zit pas sinds DOCSIS 3.0 d'r in Dus zonder 3.0 kon je überhaupt niets met IPv6. Dat haalde ik niet echt uit je post. Maar verder heb je wel gelijk idd. Je hebt er nog geen klap aan, maar, dat ligt niet aan het modem.

De klant koopt sowieso zelf de router die achter 't kabelmodem gehangen wordt, dus in dat opzichte, mits de klant een DOCSIS 3.0-modem heeft en mits de ISP native IPv6 aanbiedt, is de klant zélf verantwoordelijk voor een werkende IPv6-infrastructuur.

[Keiichi]

Osiris schreef op donderdag 07 oktober 2010 @ 11:36:
[...]
De klant koopt sowieso zelf de router die achter 't kabelmodem gehangen wordt, dus in dat opzichte, mits de klant een DOCSIS 3.0-modem heeft en mits de ISP native IPv6 aanbiedt, is de klant zélf verantwoordelijk voor een werkende IPv6-infrastructuur.

Behalve dat je vrijwel altijd een gratis of anders tegen een laag bedrag van de provider een routertje kan kopen. In die zin is het de verantwoording van de providers.

Ik zie mijn moeder nog geen router uitzoeken op het feit dat deze IPv6 snapt. Sterker nog, ze staat je raar aan te kijken als je het over IPv6 hebt (Of IP uberhaupt )

[Osiris]

Hm, ik dacht dat dat meer iets van ADSL-ISP's was, routertjes aanbieden, en dat kabelaars alleen een modem "gaven" en dat de klant de rest maar uit moest zoeken. My bad

[Mawlana]

Ik weet niet hoe het bij Ziggo is, maar UPC heeft ook enkele routers in het assortiment dat je kan kopen.

[Sypher]

Iemand hier ervaring met IPv6 in combinatie met KVM (virtualisatie, niet keyboard..v...)?
Ik probeer mijn virtuele machines een IPv6 adres te geven, maar moet aan de slag met NDP_Proxy oid.

[ Voor 15% gewijzigd door Sypher op 07-10-2010 13:31 ]

[Keiichi]

sylvesterrr schreef op donderdag 07 oktober 2010 @ 13:27:
Ik weet niet hoe het bij Ziggo is, maar UPC heeft ook enkele routers in het assortiment dat je kan kopen.

En het lijkt mij dat consumenten sneller deze kopen dan eentje uit de winkel uitzoeken. Dus ik blijf bij mijn statement.

--

Met 1 website heb ik iets vreemd. Recentelijk wou ik www.brocade.com bezoeken, een IPv6 enabled site toevallig. Deze krijg ik in FireFox niet geopend, hij blijft op Loading... staan. Maar met telnet naar poort 80 krijg ik wel eea geladen

[Jaap-Jan]

Sypher schreef op donderdag 07 oktober 2010 @ 13:29:
Iemand hier ervaring met IPv6 in combinatie met KVM (virtualisatie, niet keyboard..v...)?
Ik probeer mijn virtuele machines een IPv6 adres te geven, maar moet aan de slag met NDP_Proxy oid.

Dat kan toch op dezelfde manier als je zou doen met een fysieke computer? Gewoon radvd draaien of zelf een ip, subnet, router en dns- server vastleggen zoals je normaal doet.

CAPSLOCK2000 schreef op zaterdag 02 oktober 2010 @ 23:32:
[...]


Wil je dat je hosts voor de hele wereld benaderbaar zijn of alleen binnen je eigen LAN?
In dat laatste geval moet je eens kijken naar MDNS (multicast dns). Onder debian heb je de pakketten libnss-mdns en avahi-daemon nodig. Dat installeer je op al je machines en dan kunnen ze elkaar op naam vinden. ('t zou ook met MacOSX moeten werken).

Goed idee. Onder Windows kan het ook met Apple's Bonjour. De naam voor de techniek is trouwens 'zeroconf'.

Ik heb IPv6 nu draaien op m'n D-Link DIR-825 met dd-wrt. Werkt soepeltjes

Keiichi schreef op donderdag 07 oktober 2010 @ 13:32:
[...]


En het lijkt mij dat consumenten sneller deze kopen dan eentje uit de winkel uitzoeken. Dus ik blijf bij mijn statement.

--

Met 1 website heb ik iets vreemd. Recentelijk wou ik www.brocade.com bezoeken, een IPv6 enabled site toevallig. Deze krijg ik in FireFox niet geopend, hij blijft op Loading... staan. Maar met telnet naar poort 80 krijg ik wel eea geladen

Hij is niet snel, maar laadt hier wel op Firefox 4.0b6.

[ Voor 25% gewijzigd door Jaap-Jan op 07-10-2010 14:01 ]

[Osiris]

Keiichi schreef op donderdag 07 oktober 2010 @ 13:32:
[...]

Met 1 website heb ik iets vreemd. Recentelijk wou ik www.brocade.com bezoeken, een IPv6 enabled site toevallig. Deze krijg ik in FireFox niet geopend, hij blijft op Loading... staan. Maar met telnet naar poort 80 krijg ik wel eea geladen

Ff Wiresharken welke pakketjes er wel en niet over de verbinding gaan? Hier geen enkel probleem met Fx 3.6.9 @ Gentoo Linux.

[Snow_King]

Sypher schreef op donderdag 07 oktober 2010 @ 13:29:
Iemand hier ervaring met IPv6 in combinatie met KVM (virtualisatie, niet keyboard..v...)?
Ik probeer mijn virtuele machines een IPv6 adres te geven, maar moet aan de slag met NDP_Proxy oid.

Werkt prima? Gewoon een Layer 2 bridge waar je je VM aan koppelt. Vervolgens kan je zonder problemen IPv6 doen in de VM, niets anders dan IPv4.

Wel even opletten, de VNC server bind nog niet aan IPv6!

[Roetzen]

Osiris schreef op donderdag 07 oktober 2010 @ 11:36:
[...]

IPv6-support zit pas sinds DOCSIS 3.0 d'r in Dus zonder 3.0 kon je überhaupt niets met IPv6.

Dat klopt niet helemaal, er is voor DOCSIS 2.x een extensie voor IPv6. Of dat ergens gebruikt wordt weet ik niet. Ik heb begrepen dat Ziggo dat niet zal gaan gebruiken, maar het hele netwerk ombouwt naar DOCSIS 3.0. Vanwege de hogere snelheden die ze aanbieden.

Dat haalde ik niet echt uit je post. Maar verder heb je wel gelijk idd. Je hebt er nog geen klap aan, maar, dat ligt niet aan het modem.

Ik meende dat het wel bekend was, daar het in dit topic al eerder ter sprake is geweest.

Overigens krijgen we dan ook weer dat level 2 vs level 3 verhaal. Een modem is in principe level 2. Dus net als een level 2 switch transparant voor IPv4/IPv6. Zou je denken... Dus helemaal helder is het me nog niet.

[Osiris]

Roetzen schreef op donderdag 07 oktober 2010 @ 15:48:
[...]

Dat klopt niet helemaal, er is voor DOCSIS 2.x een extensie voor IPv6. Of dat ergens gebruikt wordt weet ik niet. Ik heb begrepen dat Ziggo dat niet zal gaan gebruiken, maar het hele netwerk ombouwt naar DOCSIS 3.0. Vanwege de hogere snelheden die ze aanbieden.

Meh, dan heeft Wikipedia me voorgelogen Althans, er stond dat 3.0 support bood voor IPv6. Verder niet verder gekeken dan m'n neus lang was voor extensies op 2.x

Roetzen schreef op donderdag 07 oktober 2010 @ 15:48:
[...]

Overigens krijgen we dan ook weer dat level 2 vs level 3 verhaal. Een modem is in principe level 2. Dus net als een level 2 switch transparant voor IPv4/IPv6. Zou je denken... Dus helemaal helder is het me nog niet.

Tja, maar zo helder is 't inderdaad niet.. Zo kun je met MPoA (Multiprotocol Encapsulation over ATM Adaptation Layer 5/RFC 1483/RFC 2684) bij XS4ALL ook geen native IPv6 krijgen. En volgens hun ligt dat dan geloof ik weer aan KPN ofzo... Hoe dat precies relateert a.d.v. modems, I dunno, maar je kunt layer 2 en 3 niet zomaar 100% los van elkaar zien.

[Roetzen]

Osiris schreef op donderdag 07 oktober 2010 @ 16:38:
[...]

Meh, dan heeft Wikipedia me voorgelogen Althans, er stond dat 3.0 support bood voor IPv6. Verder niet verder gekeken dan m'n neus lang was voor extensies op 2.x

http://en.wikipedia.org/wiki/DOCSIS
Het staat er wel maar je moet even verder doorlezen:

The new 'DOCSIS 2.0 + IPv6' standard also supports IPv6, which may on the cable modem side only require a firmware upgrade[

[...]

hun ligt dat dan geloof ik weer aan KPN ofzo... Hoe dat precies relateert a.d.v. modems, I dunno, maar je kunt layer 2 en 3 niet zomaar 100% los van elkaar zien.

Blijkbaar...

[Sypher]

Snow_King schreef op donderdag 07 oktober 2010 @ 14:30:
[...]
Werkt prima? Gewoon een Layer 2 bridge waar je je VM aan koppelt. Vervolgens kan je zonder problemen IPv6 doen in de VM, niets anders dan IPv4.

Wel even opletten, de VNC server bind nog niet aan IPv6!

Het zou ook prima moeten werken, zij het niet dat het dus niet werkt. De router kent de MAC niet, dus moet je aan de slag met de proxy. (blijkbaar).

De setup in kwestie:

Dom0:
Op eth0 zit een ander IPv6 adres voor eigen connectivity
Op virrou0 zit het gateway IP voor de VM (::2). Deze is toegevoegd als /64
Een ping6 naar ipv6.google.com werkt. No problemo.

/etc/sysctl.conf bevat:

code:

net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1

Uitgevoerd:
ip -6 neigh add proxy 2a01:xxx:xxx:xxxx:xx:xx:xx:f8 dev virrou0
(virrou0 is de bridge waarop de VM's zitten)

Resultaat:

• IPv6 google is te pingen
• Adres op eth0 is te pingen van buitenaf
• Adres van virrou0 is niet pingbaar van buitenaf
• IP van VM is niet pingbaar ( Destination unreachable: Address unreachable)

VM:

code:

iface eth1 inet6 static
        address 2a01:xxx:xxx:xxxx:xx:xx:xx:f8
        netmask 64
        gateway 2a01:xxx:xxx:xxxx::2

Resultaat:

• Gateway (::2) is te pingen
• Adres op eth0 van de dom0 is niet te pingen
• Google is niet te pingen (Destination unreachable: Beyond scope of source address)

Er zit dus ergens in de setup iets verkeerd.
Voor IPv4 maakt de VM echter gebruik vanaf het IP wat op eth0 zit bij dom0 en niet van virrou0, wellicht moet ik het daar zoeken.

Suggesties zijn welkom :-)

[ Voor 4% gewijzigd door Sypher op 07-10-2010 17:20 ]

[Raven]

Verwijderd schreef op donderdag 07 oktober 2010 @ 03:02:
Ik weet niet of het aan de orde geweest is, maar hoe gaat Ziggo bijvoorbeeld ipv6 aan de klanten (noobs) aanbieden? Wat met de in gebruik zijnde routers? Nu is ipv6 nog iets voor "nerds" Straks moet iedereen eraan. Vertel.......

Schijnt dat ze intern al aan het testen zijn, verder is er niks bekend: http://www.webhostingtalk...iggo-en-ipv6-zucht-5.html

[Snow_King]

Hoe zien je bridges er op je fysieke host er uit? Gewoon een br0 direct naar eth0 toe?

[Olaf van der Spek]

Sypher schreef op donderdag 07 oktober 2010 @ 17:14:
Het zou ook prima moeten werken, zij het niet dat het dus niet werkt. De router kent de MAC niet, dus moet je aan de slag met de proxy. (blijkbaar).

Als je alles bridged moet de router het MAC gewoon vinden.

[Keiichi]

Ik kom er met iets triviaals niet uit.

Ik was altijd gewend om een /48 subnet van een broker te krijgen, maar nu heb ik ook te maken met een /56 . Ik kan er geen handigheid in krijgen tot waar het subnet nu eigenlijk loopt.

Bij een /48 mag je heel de 4de positie in het adres geheel gebruiken. Wie weet een foefje om dit snel te bepalen bij een /56 (Bij IPv4 kan ik dit dromen )

[Sypher]

Nou, het is gelukt. Hoe heb ik het opgelost?

• Alle IP's overal verwijderen, handmatig aangezien ik geen reboots / restarts wil doen :-)
• Dom0: IP toegevoegd aan virrou0, default gateway ingesteld, ping6 ipv6.google.com = werkt
• Dom0: ip -6 neighbor add proxy %domu_ipv6% dev eth0
• Domu: IP toegevoegd op de interface. Gateway ingesteld op het adres wat op virrou0 staat
• Domu: Ping6 ipv6.google.com: werkt
• Domu: Ping naar andere VM (zelfde virrou0 bridge).. Voila, werkt.

Ik deed gewoon te lastig. Ik had namelijk een IPv4-to-IPv6 generator gemaakt welke het IPv4 adres omzette in IPv6, met het netwerkdeel er voor. Leverde wel logische beredeneerde IPv6 adressen op, maar wellicht ging het daar niet helemaal goed mee.

Enfin, net even netjes rDNS ingesteld (zoals het hoort, wat veel mensen vergeten helaas), en zo even in de forward DNS zetten en voila.

Volgende week weer verder aan de slag met een andere KVM machine, welke compleet anders is opgezet qua network. Sommige machines werken prima (gingen van ipv6-in-v4 naar native) maar anderen weer niet. Ik blijf IPv6 toch wel een hoog voodoo gehalte hebben

[StefSybo]

Keiichi schreef op vrijdag 08 oktober 2010 @ 18:44:
Ik kom er met iets triviaals niet uit.

Ik was altijd gewend om een /48 subnet van een broker te krijgen, maar nu heb ik ook te maken met een /56 . Ik kan er geen handigheid in krijgen tot waar het subnet nu eigenlijk loopt.

Bij een /48 mag je heel de 4de positie in het adres geheel gebruiken. Wie weet een foefje om dit snel te bepalen bij een /56 (Bij IPv4 kan ik dit dromen )

Een /56 betekent dat het netwerkdeel ook nog de eerste twee hex-digits van het vierde deel bevat. Dus als je 1234:5678:9abc:de00::/56 hebt, kan je subnetten gebruiken vanaf 1234:5678:9abc:de00::/64 tot en met 1234:5678:9abc:deff::/64

@hieronder: volgens mij zijn dat 8 bits hoor

[ Voor 3% gewijzigd door StefSybo op 08-10-2010 19:06 . Reden: foutje in adres ]

[Orion84]

Twee hex digits zijn 1 byte, 48-56==12bits -> 1,5byte. Dus volgens mij klopt je redenatie niet helemaal

Het loopt in jouw voorbeeld dan dus tot 1234:5678:9abc:de0f::/64

* Orion84 kan niet tellen

[ Voor 36% gewijzigd door Orion84 op 08-10-2010 19:07 ]

[Keiichi]

Orion84 schreef op vrijdag 08 oktober 2010 @ 19:04:
Twee hex digits zijn 1 byte, 48-56==12bits -> 1,5byte. Dus volgens mij klopt je redenatie niet helemaal

48 + 8 is toch 56?

@Orion84


In mijn documentatie heb ik wat extra leading zero's erbij gezet om het wat overzichtelijk te maken. (Ik heb het eerste subnet gekregen ). Gewoon de 2 laatste hex van de 4de positie aanpassen en het is klaar.

Ik mag trouwens hopen dat ze niet gaan verzinnen om te gaan subnetten in stappen anders dan 4bits. Anders worden het echt hersenkrakers volgens mij.

[ Voor 44% gewijzigd door Keiichi op 08-10-2010 19:11 ]

[CyBeR]

Hoezo? Dat werkt gewoon hetzelfde als in IPv4 hoor, waar 't ook prima mogelijk is om een /27 te krijgen.

[Olaf van der Spek]

CyBeR schreef op vrijdag 08 oktober 2010 @ 19:24:
Hoezo? Dat werkt gewoon hetzelfde als in IPv4 hoor, waar 't ook prima mogelijk is om een /27 te krijgen.

Omdat een hex digit dan zowel bits voor het netwerk deel en bits voor het host deel bevat en dat is niet zo handig.

[CyBeR]

Olaf van der Spek schreef op vrijdag 08 oktober 2010 @ 19:34:
[...]

Omdat een hex digit dan zowel bits voor het netwerk deel en bits voor het host deel bevat en dat is niet zo handig.

Ja, dat snap ik maar wat maakt dat uit, precies?

[Keiichi]

Ik ben wat aan het rondzoeken voor tooltjes om mijn IP spaces in beheersing te nemen. Het meeste wat ik kan vinden, doe alleen nog maar IPv4...

[Osiris]

Olaf van der Spek schreef op vrijdag 08 oktober 2010 @ 19:34:
[...]

Omdat een hex digit dan zowel bits voor het netwerk deel en bits voor het host deel bevat en dat is niet zo handig.

Ach, bij IPv4 had je één 8 bits getal staan waarin een stukkie netwerk en een stukkie host-deel kon staan. Alleen idiote imbicielen die d'r geen reet van snappen kunnen d'r niet mee omgaan en voor de rest is 't geen probleem

[Raven]

Telfort volgt IPv6-voorbeeld Xs4all

Geen quote, gaat wat moeilijk op mobieltje....

[Roetzen]

Een quote hoeft ook niet, de link is wel zo handig. Bovendien kan ik dan ook de commentaren zien. Daarin lees ik tot mijn verbazing dat:

1) Tele2 aan het NATten is geslagen.

2) Veel ISPs ventileren dat ze nog voldoende IP4 adressen op vooraad hebben om het rustig aan te kunnen doen met de omschakeling naar IPv6.

En dat laatste is natuurlijk een drogargument. Het zal best zijn dat er bij de Nederlandse ISPs nog geen acuut tekort aan IPv4 adressen is, maar als ze elders in de wereld wel op zijn en er dus daar hosts zijn die alleen nog maar via IPv6 bereikbaar zijn, dan moeten we hier ook IPv6 hebben, anders zijn die voor ons onbereikbaar. Er is dus wel degelijk haast geboden.

[CyBeR]

Roetzen schreef op dinsdag 12 oktober 2010 @ 12:43:
Een quote hoeft ook niet, de link is wel zo handig. Bovendien kan ik dan ook de commentaren zien. Daarin lees ik tot mijn verbazing dat:

1) Tele2 aan het NATten is geslagen.

Die gast legt dat wat krom uit. Hij bedoelt gewoon dat tele2 doet wat elke DSL-isp doet, namelijk het modem laten NATten.

[Roetzen]

Aha. Ik was al even bang dat Tele2 overgegaan was op CGN. Dat zou een slechte zaak zijn. Maar nu ik het nog eens goed lees, zal ie inderdaad wel bedoeld hebben dat adsl boeren modem/routers leveren die standaard NAT doen om het LAN aan het WAN te koppelen..

[Raven]

Roetzen schreef op dinsdag 12 oktober 2010 @ 12:43:
Een quote hoeft ook niet, de link is wel zo handig.

Ik doe meestal beide, zowel link als quote

[ Voor 5% gewijzigd door Raven op 12-10-2010 18:09 ]

[Osiris]

quote: http://vragen.upc.nl/app/answers/detail/a_id/412/

Veiliger
Bij IPv6 is al het dataverkeer versleuteld. Dat houdt in dat niet iedereen zomaar kan zien wat voor informatie u ophaalt of verstuurt via uw internetverbinding. Dit gebeurt met dezelfde techniek (IPsec) die ook vaak wordt gebruikt om via het internet een verbinding te maken met een bedrijfsnetwerk (een VPN verbinding).

Volgens mij vergeet UPC daar eventjes te vermelden dat het versleuteld kán worden. Het enige voordeel aan IPv6 qua veiligheid is dat IPSec verplicht in 't protocol moet "zitten" (ofzoiets), maar ze slaan volledig de plank mis door te concluderen dat IPv6 veiliger is wánt het is versleuteld.. Da's zeker niet default the case.

[Jap]

Modbreak:

SPAM removed

[ Voor 98% gewijzigd door Koffie op 13-10-2010 17:59 ]

[Roetzen]

Osiris schreef op dinsdag 12 oktober 2010 @ 19:09:
[...]

Volgens mij vergeet UPC daar eventjes te vermelden dat het versleuteld kán worden. Het enige voordeel aan IPv6 qua veiligheid is dat IPSec verplicht in 't protocol moet "zitten" (ofzoiets), maar ze slaan volledig de plank mis door te concluderen dat IPv6 veiliger is wánt het is versleuteld.. Da's zeker niet default the case.

En er is meer:

Sneller
IPv6 werkt efficiënter dan IPv4. Daardoor is een internetverbinding met IPv6 sneller dan dezelfde verbinding met IPv4. Daarnaast is IPv6 geschikter voor het bekijken van video's en online gaming.

Daar klopt volgens mij ook niks van, behalve de opmerking over online gaming. Sneller is het niet, waarom zou het? Waarom het geschikter is voor het bekijken van video's is me ook onduidelijk. Online gaming? Ja dat wel omdat er geen gedonder is met NAT en er weer full end to end connectivity is.

[CyBeR]

Roetzen schreef op donderdag 14 oktober 2010 @ 02:04:
[...]

Daar klopt volgens mij ook niks van, behalve de opmerking over online gaming. Sneller is het niet, waarom zou het? Waarom het geschikter is voor het bekijken van video's is me ook onduidelijk. Online gaming? Ja dat wel omdat er geen gedonder is met NAT en er weer full end to end connectivity is.

Video streams hebben soms ook last van NAT.

[Osiris]

Roetzen schreef op donderdag 14 oktober 2010 @ 02:04:
[...]

Daar klopt volgens mij ook niks van, behalve de opmerking over online gaming. Sneller is het niet, waarom zou het?

Wellicht bedoelen ze dat de IPv6-header minder overhead geeft t.o.v. de IPv4-header.

[Snow_King]

Osiris schreef op donderdag 14 oktober 2010 @ 06:50:
[...]

Wellicht bedoelen ze dat de IPv6-header minder overhead geeft t.o.v. de IPv4-header.

Zoiets gok ik en ook de automatische MTU detectie waardoor je minder fragmentatie hebt.

Maar dat zal in praktijk denk ik weinig verschil maken.

[Roetzen]

Aan de andere kant moeten er wel 128 bits adressen verwerkt worden in plaats van 32 bit adressen. Maar dat zijn toch marginale verschillen en het lijkt me ook sterk dat de eindgebruiker daar iets van merkt.

Natuurlijk heeft IPv6 voordelen. Maar daar zal de grote meerderheid van de gewone gebruikers weing of niets van merken in de praktijk. Het is dan ook niet handig van ISPs om die voordelen in publikaties voor het grote publiek te gaan ophemelen. Dat leidt alleen maar tot teleurstelling. Ze moeten gewoon eerlijk zijn en zeggen dat de invoering van IPv6 noodzakelijk is om te zorgen dat alles over een paar jaar ook nog werkt.

[Kees]

Snow_King schreef op donderdag 14 oktober 2010 @ 08:46:
[...]
Zoiets gok ik en ook de automatische MTU detectie waardoor je minder fragmentatie hebt.

Maar dat zal in praktijk denk ik weinig verschil maken.

Het zal eerder zo zijn dat de checksum niet meer ook over de header gaat, en dus niet door elke router opnieuw berekend hoeft te worden als hij bv de ttl verlaagt. Verder is de header kleiner, en moet je inderdaad eerst path MTU detection doen.

Vooral de checksum zal wel een slok op een borrel schelen voor de meeste routers. Zie ook: Wikipedia: IPv6

[Olaf van der Spek]

CyBeR schreef op donderdag 14 oktober 2010 @ 02:07:
[...]


Video streams hebben soms ook last van NAT.

Want?

Osiris schreef op donderdag 14 oktober 2010 @ 06:50:
Wellicht bedoelen ze dat de IPv6-header minder overhead geeft t.o.v. de IPv4-header.

Dat is leuk voor router vendors, maar niet significant voor de latency die eindgebruikers ondervinden.

Kees schreef op donderdag 14 oktober 2010 @ 12:55:
Het zal eerder zo zijn dat de checksum niet meer ook over de header gaat, en dus niet door elke router opnieuw berekend hoeft te worden als hij bv de ttl verlaagt. Verder is de header kleiner, en moet je inderdaad eerst path MTU detection doen.

MTU detection lijkt erg onhandig. Dat kost toch veel te veel tijd?

[ Voor 76% gewijzigd door Olaf van der Spek op 14-10-2010 14:04 ]

[Keiichi]

Olaf van der Spek schreef op donderdag 14 oktober 2010 @ 13:58:
[...]
MTU detection lijkt erg onhandig. Dat kost toch veel te veel tijd?

De minimale MTU is 1280, dus bij het opzetten van een verbinding kan daarmee al gelijk gewerkt worden. Als er daarna wat tijd overheen gaat, zeg maar 2 seconden ofzo) om een hogere mtu te vinden en vervolgens daarvan gebruik maken , dan zou het niet zo geheel bezwaarlijk zijn lijkt me.

Verder heb ik me nog niet verdiept in mtu discovery enzo.

[DDX]

Inmiddels ook maar paar machines voorzien van ipv6 adressen.
Moet wel zeggen dat het erg opletten is met de ip adressen, vooral reverse is leuke uitdaging.
Hoe doen julie dat eigenlijk, ik heb nu 1 zonefile waarin hele /48 staat.
Maar echt overzichtelijk is het niet (bind9).

Backup colocation is op dit moment volledig ready (en deels voorzien) van ipv6 dus.
Primary colocation is het wachten nog even op nieuwe routers die waarschijnlijk volgend jaar komen, we hebben nu nml last van een paar foundry's die gelimiteerd zijn in aantal ip's en nu met ipv4 al erg op het randje zitten.

[ Voor 11% gewijzigd door DDX op 15-10-2010 17:28 ]

[CyBeR]

Olaf van der Spek schreef op donderdag 14 oktober 2010 @ 13:58:
[...]

Want?

Veel streams zijn UDP streams en dat is óók lastig met NAT.

[Snow_King]

DDX schreef op vrijdag 15 oktober 2010 @ 17:27:
Inmiddels ook maar paar machines voorzien van ipv6 adressen.
Moet wel zeggen dat het erg opletten is met de ip adressen, vooral reverse is leuke uitdaging.
Hoe doen julie dat eigenlijk, ik heb nu 1 zonefile waarin hele /48 staat.
Maar echt overzichtelijk is het niet (bind9).

Backup colocation is op dit moment volledig ready (en deels voorzien) van ipv6 dus.
Primary colocation is het wachten nog even op nieuwe routers die waarschijnlijk volgend jaar komen, we hebben nu nml last van een paar foundry's die gelimiteerd zijn in aantal ip's en nu met ipv4 al erg op het randje zitten.

Let even op! Koop geen RX-8 van Brocade/Foundry. Wij hebben die ook gekocht, nu blijken ze achteraf geen IPv6 VRRPv3 te doen, dus je hebt dan geen redundant gateway,

Je kan dan beter voor de MLX serie gaan, die doen dat wel.

[Keiichi]

Snow_King schreef op vrijdag 15 oktober 2010 @ 17:52:
[...]
Let even op! Koop geen RX-8 van Brocade/Foundry. Wij hebben die ook gekocht, nu blijken ze achteraf geen IPv6 VRRPv3 te doen, dus je hebt dan geen redundant gateway,

Je kan dan beter voor de MLX serie gaan, die doen dat wel.

Werk je toevallig voor een bedrijf in Gilze/Rijen?

[Olaf van der Spek]

CyBeR schreef op vrijdag 15 oktober 2010 @ 17:29:
Veel streams zijn UDP streams en dat is óók lastig met NAT.

Wat is er lastig aan dan?

[Snow_King]

Keiichi schreef op vrijdag 15 oktober 2010 @ 18:39:
[...]


Werk je toevallig voor een bedrijf in Gilze/Rijen?

Nope, helaas Iemand daar met het zelfde probleem?

[Keiichi]

Snow_King schreef op vrijdag 15 oktober 2010 @ 23:42:
[...]
Nope, helaas Iemand daar met het zelfde probleem?

Volgens mij niet hetzelfde, maar werken volgens mij wel met hetzelfde platform.

-edit-

Correctie, ik zie dat ze op het MLX platform draaien.

[ Voor 11% gewijzigd door Keiichi op 18-10-2010 10:19 ]

[DDX]

Snow_King schreef op vrijdag 15 oktober 2010 @ 17:52:
[...]
Let even op! Koop geen RX-8 van Brocade/Foundry. Wij hebben die ook gekocht, nu blijken ze achteraf geen IPv6 VRRPv3 te doen, dus je hebt dan geen redundant gateway,

Je kan dan beter voor de MLX serie gaan, die doen dat wel.

We houden het wat kleiner bij ons, we hebben nu 2 serveriron 4g's hangen.
Uitbreiding die we gaan doen is 2 Juniper EX4200's, waarbij de serveriron dan dienst blijven doen als loadbalancers maar aantal subnetten (ipv4) verhuisd zullen worden naar de Junipers.

En daardoor ook ruimte krijgen om ipv6 op de serveriron's te gaan doen. (en uiteraard ook op de nieuwe junipers)

Leuke van de serverirons is dat je max 64ips kan gebruiken, leuk dat dit nergens in de docs staat en je er opeens achter komt als je 65e ip wilt gebruiken...

[DDX]

Vandaag ipv6 geconfigureerd op de eerste colocation bij level3.
Level3 doet een of andere manier van tunneling op ipv6 aan te bieden in hun netwerk.

traceroute via ipv4:

code:

traceroute to router-xs4-1.thepeoplesvalley.net (194.109.7.86), 30 hops max, 40 byte packets
 1  ge-5-0-2.edge3.Amsterdam1.Level3.net (212.72.33.121)  0.122 ms  0.104 ms  0.094 ms
 2  tiscali-level3-xe.Amsterdam1.Level3.net (4.68.110.86)  0.175 ms  0.167 ms  0.193 ms
 3  xe-2-0-0.ams12.ip4.tinet.net (89.149.186.246)  0.230 ms  0.219 ms xe-0-0-0.ams12.ip4.tinet.net (89.149.186.234)  0.211 ms
 4  xs4all-internet-gw.ip4.tinet.net (77.67.74.210)  0.399 ms  0.361 ms  0.274 ms
 5  0.so-2-0-0.xr4.1d12.xs4all.net (194.109.5.9)  0.827 ms  0.862 ms  0.900 ms
 6  te5-4.swcolo2.3d12.xs4all.net (194.109.12.34)  1.074 ms  1.110 ms  1.348 ms
 7  router-xs4-1.thepeoplesvalley.net (194.109.7.86)  0.885 ms  0.877 ms  0.859 ms

via ipv6 :

code:

traceroute to router-xs4-1.thepeoplesvalley.net (2001:888:2000:31::2), 30 hops max, 40 byte packets
 1  2001:1900:5:2:2::d1 (2001:1900:5:2:2::d1)  0.204 ms  0.178 ms  0.159 ms
 2  vl-4081.edge3.Amsterdam1.Level3.net (2001:1900:5:1::10a)  0.321 ms  0.305 ms  0.339 ms
 3  vl-4060.edge4.London1.Level3.net (2001:1900:5:1::205)  8.807 ms  8.801 ms  8.788 ms
 4  vl-4085.sar1.London1.Level3.net (2001:1900:5:1::221)  9.023 ms  8.801 ms  9.144 ms
 5  2001:7f8:4::1935:1 (2001:7f8:4::1935:1)  12.363 ms  12.184 ms  11.792 ms
 6  2001:5a0:c00:600::2 (2001:5a0:c00:600::2)  9.127 ms 2001:5a0:c00:600::6 (2001:5a0:c00:600::6)  9.207 ms *
 7  if-1-0-0.1693.core1.AD1-Amsterdam.ipv6.as6453.net (2001:5a0:c00:100::6)  23.896 ms * *
 8  if-3-0-0.6bb1.AD1-Amsterdam.ipv6.as6453.net (2001:5a0:200::5)  38.463 ms  30.229 ms  29.933 ms
 9  2001:5a0:200::42 (2001:5a0:200::42)  24.252 ms  24.830 ms  24.420 ms
10  0.so-1-0-0.xr3.3d12.xs4all.net (2001:888:0:105::1)  24.308 ms  35.197 ms  25.435 ms
11  te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2)  24.520 ms  25.004 ms  24.626 ms
12  vlan5.swcolo2.3d12.xs4all.net (2001:888:0:3101::2)  25.370 ms  24.841 ms  24.741 ms
13  router-xs4-1.thepeoplesvalley.net (2001:888:2000:31::2)  24.638 ms  24.625 ms  24.571 ms

Leuke responsetijden krijg je dus als je via ipv6 gaat.
En ipv6 google hebben ze geen zin in :

code:

traceroute to ipv6.google.com (2a00:1450:8003::67), 30 hops max, 40 byte packets
 1  2001:1900:5:2:2::d1 (2001:1900:5:2:2::d1)  0.230 ms !N  0.240 ms !N  0.326 ms !N

Volgende week maar eens vragen of ze plannen hebben om ipv6 service te verbeteren en waarom ik google niet kan bereiken via ipv6.

[zenith]

Snow_King schreef op vrijdag 15 oktober 2010 @ 17:52:
[...]
Let even op! Koop geen RX-8 van Brocade/Foundry. Wij hebben die ook gekocht, nu blijken ze achteraf geen IPv6 VRRPv3 te doen, dus je hebt dan geen redundant gateway,

Je kan dan beter voor de MLX serie gaan, die doen dat wel.

De MLX doet nu ook nog geen VRRPv3, strakjes wel

[Snow_King]

DDX schreef op woensdag 20 oktober 2010 @ 21:00:
[...]


We houden het wat kleiner bij ons, we hebben nu 2 serveriron 4g's hangen.
Uitbreiding die we gaan doen is 2 Juniper EX4200's, waarbij de serveriron dan dienst blijven doen als loadbalancers maar aantal subnetten (ipv4) verhuisd zullen worden naar de Junipers.

En daardoor ook ruimte krijgen om ipv6 op de serveriron's te gaan doen. (en uiteraard ook op de nieuwe junipers)

Leuke van de serverirons is dat je max 64ips kan gebruiken, leuk dat dit nergens in de docs staat en je er opeens achter komt als je 65e ip wilt gebruiken...

Zelfde gehad met de ServerIron 4G, drama appliance. Daarom voel ik me door Foundry/Brocade nu met de RX-8 voor de tweede keer gen***d, want ze verkopen spul wat eigenlijk te beperkt is op veel vlakken.

zenith schreef op zaterdag 23 oktober 2010 @ 20:52:
[...]


De MLX doet nu ook nog geen VRRPv3, strakjes wel

Klopt, maar de RX-8 gaat het dus nooit doen, hardware-matige limitatie.

Overigens zijn wij bezig met Brocade te regelen dat zei onze RX-8 terug kopen en wij een MLX aanschaffen, als iemand daar ook interesse in heeft, neem contact op, samen staan we sterker.

[Freeaqingme]

Vannacht browsede ik tweakers via http://tweakers.net.sixxs.org, alleen 't postte lukte niet..

Kan t.net nu heel sneel ipv6 gaan doen?! (jaja, ik zal verder vriendelijk blijven )

In verband met een storing bij danwel xs4all, danwel mijn Fritz!box heb ik momenteel enkel ipv6 connectiviteit. Imho moet iedere site anno 2010 ipv6 doen, al helemaal als 't een userbase ter grootte van tweakers heeft, en al helemaal als 't een ict site betreft. Ik weet niet of de loadbalancers 't al snappen, maar wellicht is 't anders mogelijk ipv6.tweakers.net aan te maken, en die gewoon om de loadbalancer heen te leiden (of gewoon een RoundRobin voor ipv6 gebruiken, en ook 't ipv6 gebeuren buiten de loadbalancer om doen).

Na na drie uur maar mijn router te hebben gereboot had ik overigens weer ipv4 connectiviteit, dus ik gok dat 't niet aan xs4all lag.

[DDX]

DDX schreef op vrijdag 22 oktober 2010 @ 23:28:
en waarom ik google niet kan bereiken via ipv6.

mooi antwoord :

Problem Summary: We do not have a route for the destination network in which 2a00:1450:8003::93 exists from. I don't know for sure, but I don't know if Level 3 is setup up yet to recieve those routes. May have to investigate with IP ATS when they get in to see what they say in regards to this.
Next course of action: Reach out to IP ATS
ETR/ETA: N/A

Problem Summary: Looking through documentation that we have, I don't believe we have the routes nor the connectivity yet to be able to reach google through IPv6.
Next course of action: Give customer the update on this
ETR/ETA: N/A

[ Voor 18% gewijzigd door DDX op 26-10-2010 12:33 ]

[databeestje]

Shameless Plug: Ik ben de afgelopen week bezig geweest om wat ipv6 support in pfSense in te bouwen.
Ik ben inmiddels op het punt aangekomen dat ik het thuis op m'n Alix 2C3 kan gaan zetten.

Het verhaal om de pfSense install de andere broncode boom binnen te laten zuigen staat hier: http://forum.pfsense.org/....msg153037.html#msg153037

Af is het niet, maar iets boven niets geldt hier. De code stelt je nu in ieder geval in staat om een he.net ipv6 tunnel van tunnelbroker.net te termineren en het /64 subnet te gebruiken op het LAN.
Firewalling werkt iig ook, de route advertising daemon staat nog op de todo voor DNS servers. Stateless autoconf werkt wel iig.

[bdegroot]

databeestje schreef op vrijdag 29 oktober 2010 @ 16:50:
Shameless Plug: Ik ben de afgelopen week bezig geweest om wat ipv6 support in pfSense in te bouwen.
Ik ben inmiddels op het punt aangekomen dat ik het thuis op m'n Alix 2C3 kan gaan zetten.

Het verhaal om de pfSense install de andere broncode boom binnen te laten zuigen staat hier: http://forum.pfsense.org/....msg153037.html#msg153037

Af is het niet, maar iets boven niets geldt hier. De code stelt je nu in ieder geval in staat om een he.net ipv6 tunnel van tunnelbroker.net te termineren en het /64 subnet te gebruiken op het LAN.
Firewalling werkt iig ook, de route advertising daemon staat nog op de todo voor DNS servers. Stateless autoconf werkt wel iig.

Goed werk!!

Ik werk al jaren met Pfsense, maar alleen ipv6 support ontbreekt nog. Staat volgens mij voor versie 2.1 op de planning.

Pfsense is tenslotte een fork van M0n0wall en die ondersteunt al jaren ipv6. Kan je daar niet wat code van gerbuiken?

[Raven]

IPv6 ondersteuning zit er wel in, althans, in het onderliggende OS (FreeBSD). Maar pfSense zelf dus niet.
Heb hier v1.2.3 en wil deze howto een keer proberen.

[ Voor 8% gewijzigd door Raven op 29-10-2010 18:41 ]

[databeestje]

bdegroot schreef op vrijdag 29 oktober 2010 @ 17:34:
[...]


Goed werk!!

Ik werk al jaren met Pfsense, maar alleen ipv6 support ontbreekt nog. Staat volgens mij voor versie 2.1 op de planning.

Pfsense is tenslotte een fork van M0n0wall en die ondersteunt al jaren ipv6. Kan je daar niet wat code van gerbuiken?

Klopt inderdaad, we zitten inmiddels al redelijk dicht bij een RC release voor pfSense 2.0 Er zijn nog wel wat dingen die gepolijst moeten worden. Er worden er inmiddels al redelijk wat uitgezet voor productie. Het wordt inmiddels ook al ondersteund van de commerciele support.

Er zijn gewoon dingen die 1.2.3 niet kan welke wel mogelijk zijn met 2.0.

Ik heb het afgelopen week er nog over gehad maar we focussen de efforts eerst op 2.0, dan 2.1. Maar wees gerust. De ipv6 feature is het eerste wat aangepakt gaat worden voor 2.1.

Wat betreft die code van m0n0wall, nou, nee. Het kost me meer tijd om de code van m0n0wall te schoenlepelen in pfSense dan het zelf nieuw te schrijven. Met een weekje tijd en wat tussen de werkzaamheden door programmeren op het werk ben ik al een heel eind gekomen.

IPv6 support raakt gewoon alles wat je doet in pfSense, dus nee, ik schiet er niet veel mee op.

@raven: Die howto heb je met die git repo van mij dus niet meer nodig. Je kan nu gewoon in de UI een gif tunnel aanmaken op 2.0Beta 4, dan vervolgens als een opt interface toewijzen.
Vervolgens kan je een gateway aanmaken onder "routing" welke dan ook zichtbaar wordt in de UI en op de interfaces pagina.

Als je een bestaande pfSense 2.0 Beta 4 hebt van october 26 of later kan je via optie 12 "playback gitsync" uitvoeren. Dan geef je de url van mijn git repo op en heb je circa 5 minuten later de code op je firewall staan.

Het is nog niet helemaal duidelijk of we deze code boom straks weer mergen met mainline of dat dit geschrapt wordt. Daarvoor is het nog te vroeg. In mainline mocht mijn code iig niet

Voor volgende week staat het afmaken van de route advertising deamon op het plan.
Statische ipv6 configuratie op wan en lan werkte overigens al, ik heb met name die tunnel optie gebouwd omdat het gros van de providers in nederland geen native ipv6 heeft.

Overigens dezelfde kwaal die de andere devvers ondervinde, er zijn nog geen isps die zich ermee bezig houden.

Afgelopen week met onze account manager van de KPN gemailed over het FTTO product (we hebben er 2) en waarom er nog niet ipv6 netblokken gereserveerd zijn voor alle klanten met een bestaand ipv4 netblok.
De aanvraag voor een ipv6 netblok voor onze ftto aansluitingen is nog niet succesvol beantwoord. Het wordt opgenomen in de organisatie en we nemen je vraag serieus. Ze komen volgende week met een antwoord/reactie.

Ik had liever gezien dat ze met ipv6 netblokken aan kwamen

[Raven]

Maar dan moet ik wel de beta draaien dus?
Dan wacht ik wel op de final en gebruik ik de howto die ik postte wel, die is voor 1.2.3

[Raven]

Net http://www.xaero.org/inde...-on-the-pfsense-firewall/ eens geprobeerd, de test-pc kan niet pingen/tracert'en ("rapporten: ongeldige bronroute opgegeven") over IPv6, ook niet browsen naar IPv6 sites en pfSense geeft dit in het logboek aan:

code:

rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[54427]: <ra_output> sendmsg on em0: Operation not permitted
rtadvd[59373]: <getconfig> em0 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default

Ik denk dat er ergens een foutje in is geslopen, maar waar?

De gegevens van de tunnel:

code:

Server IPv4 address:    216.66.84.46
Server IPv6 address:    2001:470:1f14:e04::1/64
Client IPv4 address:    82.74.212.183
Client IPv6 address:    2001:470:1f14:e04::2/64 
Anycasted IPv6 Caching Nameserver:      2001:470:20::2
Anycasted IPv4 Caching Nameserver:  74.82.42.42
Routed /64:     2001:470:1f15:e04::/64

Note: em0 = LAN, em1 = WAN

code:

#!/bin/sh
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em0"
DFGW="2001:470:1f14:e04::1"

####### Configure the stuff

# Configure the interfaces
ifconfig $IFOUT create
ifconfig $IFOUT tunnel 82.74.212.183 216.66.84.46
ifconfig $IFOUT inet6 2001:470:1f14:e04::2 prefixlen 64
route -n add -inet6 default 2001:470:1f14:e04::1
ifconfig $IFOUT up

ifconfig $IFIN inet6 alias 2001:470:1f14:e04::2 prefixlen 64

# Set the default route
route -n add -inet6 default $DFGW

# Configure IPv6 forwarding
sysctl net.inet6.ip6.forwarding=1

# My /etc/rtadvd.conf looks like this
#
# bce1:\
#   :addrs#1:addr="2001:470:1f14:e04::":prefixlen#64:tc=ether:
#
# Startup rtadvd
/usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf $IFIN

code:

#!/bin/sh
#
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="gif0"
IFIN="em0"

####### Configure the stuff

# Configure PF
# pfSense puts it's rules in /tmp/rules.debug for debugging purposes after boot
# We will use these rules, add IPv6 additions, read the config with pfctl and
# disable and enable PF
cat /tmp/rules.debug | sed "/User-defined rules follow/{
p;s/.*/\
pass in quick on $IFIN inet6 from any to any\\
pass out quick on $IFIN inet6 from any to any\\
pass out quick on $IFOUT inet6 from any to any\\
pass quick proto ipv6-icmp from any to any\\
# pass in on $IFOUT inet6 proto tcp from any to any port 22\\
/;}" > /tmp/rules.config-ipv6.txt

# Read the new PF configuration file
pfctl -f /tmp/rules.config-ipv6.txt
pfctl -d; pfctl -e

code:

em0:\
:addrs#1:addr="2001:470:1f14:e04::":prefixlen#64:tc=ether:

code:

Windows IP-configuratie
Ethernet-adapter LAN-verbinding:
        Verbindingsspec. DNS-achtervoegsel: local
        IP-adres. . . . . . . . . . . . . : 192.168.1.197
        Subnetmasker. . . . . . . . . . . : 255.255.255.0
        IP-adres. . . . . . . . . . . . . : fe80::217:3fff:fe9b:f056%4
        Standaardgateway. . . . . . . . . : 192.168.1.1
Ethernet-adapter LAN-verbinding 2:
        Status van medium . . . . . . . . : medium ontkoppeld
Tunnel-adapter Teredo Tunneling Pseudo-Interface:
        Verbindingsspec. DNS-achtervoegsel: 
        IP-adres. . . . . . . . . . . . . : fe80::ffff:ffff:fffd%6
        Standaardgateway. . . . . . . . . : 
Tunnel-adapter Automatic Tunneling Pseudo-Interface:
        Verbindingsspec. DNS-achtervoegsel: local
        IP-adres. . . . . . . . . . . . . : fe80::5efe:192.168.1.197%2
        Standaardgateway. . . . . . . . . :

code:

Interface 6: Pseudo-interface van Teredo Tunneling
  Guid {8793CB06-D619-460F-B8EE-E3D148261B88}
  zones: link 6 site 3
  netwerkkabel niet aangesloten
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  routeringsvoorkeur 2
  adres van Link-laag: 0.0.0.0:0
    preferred link-local fe80::ffff:ffff:fffd, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
  koppelt MTU 1280 (ware MTU-koppeling 1280)
  huidige hop-limiet 128
  bereiktijd 25000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 5: Ethernet: LAN-verbinding 2
  Guid {64CD5864-B715-4A09-ADD8-0A0512937F4F}
  netwerkkabel niet aangesloten
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  adres van Link-laag: 00-1f-d0-36-3e-59
    tentative link-local fe80::21f:d0ff:fe36:3e59, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1:ff36:3e59, 1 refs, laatste melding
  koppelt MTU 1500 (ware MTU-koppeling 1500)
  huidige hop-limiet 128
  bereiktijd 38000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 1
  standaardlengte van voorvoegsel van site 48
Interface 4: Ethernet: LAN-verbinding
  Guid {E3AFFD6F-06CC-4A4E-8E42-BA98E9CB8255}
  zones: link 4 site 2
  gebruikt Neighbor Discovery
  gebruikt Router Discovery
  adres van Link-laag: 00-17-3f-9b-f0-56
    preferred link-local fe80::217:3fff:fe9b:f056, levensduur infinite
    multicast interface-local ff01::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1, 1 refs, kan niets over worden gemeld
    multicast link-local ff02::1:ff9b:f056, 1 refs, laatste melding
  koppelt MTU 1500 (ware MTU-koppeling 1500)
  huidige hop-limiet 128
  bereiktijd 16000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 1
  standaardlengte van voorvoegsel van site 48
Interface 3: Pseudo-interface voor 6to4-tunneling
  Guid {A995346E-9F3E-2EDB-47D1-9CC7BA01CD73}
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  routeringsvoorkeur 1
  koppelt MTU 1280 (ware MTU-koppeling 65515)
  huidige hop-limiet 128
  bereiktijd 21500 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 2: Pseudo-interface voor automatische tunneling
  Guid {48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  routeringsvoorkeur 1
  In EUI-64 ingesloten IPv4-adres: 0.0.0.0
  adres van Link-laag van router: 0.0.0.0
    preferred link-local fe80::5efe:192.168.1.197, levensduur infinite
  koppelt MTU 1280 (ware MTU-koppeling 65515)
  huidige hop-limiet 128
  bereiktijd 16000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48
Interface 1: Loopback-pseudo-interface
  Guid {6BD113CC-5EC2-7638-B953-0B889DA72014}
  zones: link 1 site 4
  gebruikt geen Neighbor Discovery
  gebruikt geen Router Discovery
  adres van Link-laag: 
    preferred link-local ::1, levensduur infinite
    preferred link-local fe80::1, levensduur infinite
  koppelt MTU 1500 (ware MTU-koppeling 4294967295)
  huidige hop-limiet 128
  bereiktijd 41000 ms (basistijd 30000ms)
  herverzendingsinterval 1000ms
  DAD-verzendingen 0
  standaardlengte van voorvoegsel van site 48

[ Voor 45% gewijzigd door Raven op 31-10-2010 18:35 ]

[Icingdeath]

Goed om te horen dat ipv6 support er dan eindelijk aan zit te komen voor Pfsense
Binnenkort maar bleeding edge draaien dan.

Het configureren van ipv6 in freebsd bij pfsense zoals in die link hierboven werkt goed, draait nu zo al een maand of 4 zonder problemen

Kan overigens wel merken of een site over ipv6 bereikbaar is, want die tunnel broker (he.net) die ik gebruik is hier behoorlijk traag.