Het grote IPv6 topic

[jimmy87]

Ik heb dus dezelfde howto gebruikt als Raven, nog bedankt voor de link
Nu heeft mijn pfsense bakje mooi ipv6 maar hij deelt geen ips uit aan de workstations.

Ik heb de Allow ipv6 optie ingeschakeld staan.
Even de volgende gegevens, misschien zien jullie waaar ik wat fout heb gedaan want ik zie het niet meer

mijn HE.net info:

code:

Server IPv4 address: 216.66.84.46 
Server IPv6 address: 2001:470:1f14:91::1/64 
Client IPv4 address: 82.101.251.5 
Client IPv6 address: 2001:470:1f14:91::2/64 
Routed /64: 2001:470:1f15:91::/64

em0 = wan
em1 = lan

00_config-ipv6-if.sh

code:

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

####### Configure the stuff

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

ifconfig $IFIN inet6 alias 2001:470:1f14:91::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:db8:0:2::":prefixlen#64:tc=ether:
#
# Startup rtadvd
/usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf $IFIN

10_config-ipv6-pf.sh

code:

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

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

/etc/rtadvd.conf

code:

em1:\
:addrs#1:addr="2001:470:1f15:91::":prefixlen#64:tc=ether:

Ik dacht eerst misschien draait rtadvd niet maar dat is dus wel het geval.

code:

# ps auxww|grep rtadvd
root    1121  0.0  0.1  3156  1012  ??  Is    9:20PM   0:00.00 /usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf em1
root    1570  0.0  0.2  3508  2228  p0  RV    9:23PM   0:00.00 grep rtadvd (tcsh)
#

Het gaat hier allemaal om Windows 7 pc's.

[Snow_King]

Zie je met iets als Wireshark op de Windows 7 PC's wel RA's binnen komen?

[jimmy87]

Inmiddels werkt het
Iets met firewall op Windows pc die het tegenhield.

Als ik nu een ipv6 website wil opvragen of pingen werkt deze niet.
Ik heb die ipv6 optie enabled in pfsense.
Nu moeten er natuurlijk een aantal rules zijn voor dat verkeer maar die worden met dat 2de config bestand aangemaakt.

Pings geven aan de doelhost is niet bereikbaar of geven een time-out.

[ Voor 30% gewijzigd door jimmy87 op 16-01-2011 22:48 ]

[Raven]

Heb je heel toevallig ook de embedded/nanobsd versie van pfSense?

[ Voor 6% gewijzigd door Raven op 17-01-2011 11:03 ]

[Staatslot]

Ik hoop dat ik hier goed zit, ik heb een vraag waar volgens mij nog geen sluitend antwoord op is maar om het zeker te weten wil ik het graag hier checken..

Ik heb een aantal servers bij Leaseweb draaien, nog 1 vrij ipv4 adres op de vmware-server waar het om gaat, en zat ipv6 adressen. Nu wil ik ervoor zorgen dat mijn virtuele servers ook nog door ipv4 only hosts te benaderen zijn. Het gaat om webhosting, overigens. Zowel http als https-sites.

Ik heb van alles gevonden over de omzetting van ipv4 naar ipv6, bijvoorbeeld de dual stack oplossing.
Ik leidde daaruit af dat je alle (virtuele) servers voorziet van zowel een ipv4 als een ipv6 adres, waarmee het probleem is opgelost. Mijn probleem is dat ik dus geen ipv4 adressen meer heb..

Mijn vraag is kort en simpel, wat moet ik nou precies doen om ervoor te zorgen dat alle websites die komen te draaien op die virtuele servers bereikbaar blijven voor mensen die alleen nog ipv4 gebruiken (wat volgens mij nog 95% van Nederland is). Ik begrijp dat sixxs.net iets kan betekenen, maar als ik het zo zie dan krijg je dan ook websites die eindigen op sixxs.net en dat is niet de bedoeling. Ook lees ik dat je op je eigen pc een tunnel kunt maken, maar ik kan natuurlijk niet heel Nederland wijsmaken dat ze eerst een tunnel moeten aanmaken, zodat ze de rest van het internet ook weer kunnen vinden..

Andere oplossing als NAT64 ook bekeken, maar die lijken andersom te werken..
Kortom, na uren zoeken en me door engelstalige presentaties heen te hebben gewerkt, heb ik echt geen flauw idee wat ik moet doen om mijn toekomstige websites met een ipv6 adres bereikbaar te krijgen voor mensen met ipv4 only. Kunnen jullie me meer duidelijkheid verschaffen? Heel erg bedankt!

kleine aanvulling:
De dns draait extern en ondersteunt AAAA records

[ Voor 3% gewijzigd door Staatslot op 17-01-2011 13:08 ]

[Snow_King]

Staatslot schreef op maandag 17 januari 2011 @ 13:02:
Ik hoop dat ik hier goed zit, ik heb een vraag waar volgens mij nog geen sluitend antwoord op is maar om het zeker te weten wil ik het graag hier checken..

Ik heb een aantal servers bij Leaseweb draaien, nog 1 vrij ipv4 adres op de vmware-server waar het om gaat, en zat ipv6 adressen. Nu wil ik ervoor zorgen dat mijn virtuele servers ook nog door ipv4 only hosts te benaderen zijn. Het gaat om webhosting, overigens. Zowel http als https-sites.

Ik heb van alles gevonden over de omzetting van ipv4 naar ipv6, bijvoorbeeld de dual stack oplossing.
Ik leidde daaruit af dat je alle (virtuele) servers voorziet van zowel een ipv4 als een ipv6 adres, waarmee het probleem is opgelost. Mijn probleem is dat ik dus geen ipv4 adressen meer heb..

Mijn vraag is kort en simpel, wat moet ik nou precies doen om ervoor te zorgen dat alle websites die komen te draaien op die virtuele servers bereikbaar blijven voor mensen die alleen nog ipv4 gebruiken (wat volgens mij nog 95% van Nederland is). Ik begrijp dat sixxs.net iets kan betekenen, maar als ik het zo zie dan krijg je dan ook websites die eindigen op sixxs.net en dat is niet de bedoeling. Ook lees ik dat je op je eigen pc een tunnel kunt maken, maar ik kan natuurlijk niet heel Nederland wijsmaken dat ze eerst een tunnel moeten aanmaken, zodat ze de rest van het internet ook weer kunnen vinden..

Andere oplossing als NAT64 ook bekeken, maar die lijken andersom te werken..
Kortom, na uren zoeken en me door engelstalige presentaties heen te hebben gewerkt, heb ik echt geen flauw idee wat ik moet doen om mijn toekomstige websites met een ipv6 adres bereikbaar te krijgen voor mensen met ipv4 only. Kunnen jullie me meer duidelijkheid verschaffen? Heel erg bedankt!

kleine aanvulling:
De dns draait extern en ondersteunt AAAA records

Als je geen IPv4 hebt en je alles op IPv6 only draait, dan kunnen mensen met enkel IPv4 je niet bereiken.

Wat je kan doen is IP's gaan uitsparen, dus je managent console e.d. op IPv6 only te draaien zodat je IP's over houd voor je VM's. (Maar dan moet je zelf wel over IPv6 beschikken).

[Jaap-Jan]

@Staatslot:

Ten eerste: sixxs.net heeft niets te maken met domeinnamen. SiXXS is gewoon een tunnel broker, die ervoor zorgt dat je een IPv6- tunnel kunt 'aanleggen' over IPv4. Hoe je de DNS daarvan regelt is volledig jouw probleem, evenals de aangeboden services. Het is geen webhoster.

Met IPv4- only is het onmogelijk om IPv6 services te benaderen. OS'sen moeten of dual- stack zijn, of Teredo of iets dergelijks gebruiken.Dat komt omdat IPv4 geen enkel benul heeft dat er ooit zoiets zou komen (niet helemaal waar, maar er is niet aan gedacht) als IPv6. Dus je zult voorlopig je virtuele websites ook beschikbaar moeten maken over IPv4.

Als het alleen websites zijn kun je name- based virtual hosting gebruiken om meerdere websites beschikbaar te maken onder 1 IP- adres.

Snow_King schreef op maandag 17 januari 2011 @ 13:12:
[...]
Als je geen IPv4 hebt en je alles op IPv6 only draait, dan kunnen mensen met enkel IPv4 je niet bereiken.

Wat je kan doen is IP's gaan uitsparen, dus je managent console e.d. op IPv6 only te draaien zodat je IP's over houd voor je VM's. (Maar dan moet je zelf wel over IPv6 beschikken).

Of zelf gaan NAT'ten.

[ Voor 22% gewijzigd door Jaap-Jan op 17-01-2011 13:22 ]

[Staatslot]

heel erg bedankt voor jullie reacties.

@Snow_King, ik best 4 of 5 ipv4 adressen uitsparen, maar dan heb ik er in totaal misschien 5 of 6. Dat zijn 5 of 6 websites met SSL die ik kan maken. Dat is (lang) niet genoeg..

@Jaap-Jan

Dus je zult voorlopig je virtuele websites ook beschikbaar moeten maken over IPv4.

Dat is helaas precies het probleem, dat kan ik niet want ik krijg van Leaseweb geen ipv4 adressen meer

Wat ik niet goed begrijp, is dat toch iedereen met dit probleem zit?
Er is toch niemand meer die (genoeg) IPv4 adressen krijgt op dit moment? En zoals gezegd, het kan toch niet zo zijn dat (zolang providers in Nederland hun klanten geen nieuw modem sturen en overzetten op IPv6) iedereen maar een tunnel moet maken op zijn/haar pc? Dat betekent dat websites door bijna niemand zullen kunnen worden bezocht?

[Jaap-Jan]

Staatslot schreef op maandag 17 januari 2011 @ 13:29:
heel erg bedankt voor jullie reacties.

@Snow_King, ik best 4 of 5 ipv4 adressen uitsparen, maar dan heb ik er in totaal misschien 5 of 6. Dat zijn 5 of 6 websites met SSL die ik kan maken. Dat is (lang) niet genoeg..

@Jaap-Jan

[...]

Dat is helaas precies het probleem, dat kan ik niet want ik krijg van Leaseweb geen ipv4 adressen meer

Wat ik niet goed begrijp, is dat toch iedereen met dit probleem zit?
Er is toch niemand meer die (genoeg) IPv4 adressen krijgt op dit moment? En zoals gezegd, het kan toch niet zo zijn dat (zolang providers in Nederland hun klanten geen nieuw modem sturen en overzetten op IPv6) iedereen maar een tunnel moet maken op zijn/haar pc? Dat betekent dat websites door bijna niemand zullen kunnen worden bezocht?

Nou, het valt nog mee, maar ze zullen wel opraken, ja.

En nee, een tunnel is geen optie voor de meerderheid. En providers moeten, naast het uitdelen van nieuwe modems, ook mensen gaan informeren dat hun huidige router waarschijnlijk in de vuilnisbak kan. Maar ik vind dat ze behoorlijk laks reageren, want dit probleem is al meer dan 10 jaar bekend en nu geven ze nog steeds geen openheid over hoe ze gaan migreren, laat staan dat ze de consument informeren over die migratie.

Maar los daarvan: heb je al gekeken naar name-based virtual hosting, want het is voorlopig wel een oplossing voor jouw probleem.

[axis]

Staatslot schreef op maandag 17 januari 2011 @ 13:29:
heel erg bedankt voor jullie reacties.

@Snow_King, ik best 4 of 5 ipv4 adressen uitsparen, maar dan heb ik er in totaal misschien 5 of 6. Dat zijn 5 of 6 websites met SSL die ik kan maken. Dat is (lang) niet genoeg..

@Jaap-Jan

[...]

Dat is helaas precies het probleem, dat kan ik niet want ik krijg van Leaseweb geen ipv4 adressen meer

Wat ik niet goed begrijp, is dat toch iedereen met dit probleem zit?
Er is toch niemand meer die (genoeg) IPv4 adressen krijgt op dit moment? En zoals gezegd, het kan toch niet zo zijn dat (zolang providers in Nederland hun klanten geen nieuw modem sturen en overzetten op IPv6) iedereen maar een tunnel moet maken op zijn/haar pc? Dat betekent dat websites door bijna niemand zullen kunnen worden bezocht?

Je zult bij leaseweb moeten zeuren voor meer ip's, en daarbij als reden aan moeten geven dat je meerdere SSL sites nodig hebt. En als je niet meer ip's krijgt, heb je pech. Je zou kunnen overstappen naar een andere hostingpartij die nog wel wat meer ipv4 adressen over heeft of die een wat groter blokje voor je bij RIPE kan regelen.

Maar inderdaad, steeds meer en meer mensen gaan tegen deze problemen aanlopen, en het Internet zal nog wel een vervelende plaats worden op deze manier, tot iedereen over is op ipv6. (Lees: iedere grote ISP zoals UPC, Ziggo, etc, zijn klanten standaard IPv6 ip's uitdeelt).

[Staatslot]

nogmaals bedankt voor de antwoorden.

Volgens mij is name based virtual hosts ook geen optie, want voor SSL moet volgens mij toch iedere site een eigen IP adres blijven gebruiken.. Ik ben werkelijk verbaasd dat er geen goede oplossing is, maar zo te zien kan ik achteraan in de rij aansluiten bij de overigen die net zo verbaasd zijn als ik.

Een andere hostingpartij lijkt me geen optie, ze geven allemaal aan dat het moeilijk wordt en dat er volgens RIPE maximaal 5 ip's per U worden uitgedeeld. Zijn er uberhaupt plannen van ISP's om uit te rollen naar IPv6? Want dit wordt echt een groot probleem, in ieder geval voor mij en mijn klanten..

[Zsub]

@Staatslot: enigszins off-topic hier, maar een kleine Google opdracht levert dit op: http://en.gentoo-wiki.com..._Name_Based_Virtual_Hosts

(via http://www.google.nl/sear...ed+virtual+hosts+with+ssl)

[Roetzen]

Staatslot schreef op maandag 17 januari 2011 @ 14:52:

Ik ben werkelijk verbaasd dat er geen goede oplossing is, maar zo te zien kan ik achteraan in de rij aansluiten bij de overigen die net zo verbaasd zijn als ik.

Sja, de experts roepen al tien jaar dat de IPv4 adressen toch ècht een keer op zullen raken en dat we aan IPv6 moeten. Maar iedereen behalve een paar uitzondelringen die je hier vind, heeft de kop in het zand gestoken. En nu is het huilie huilie...

Een andere hostingpartij lijkt me geen optie, ze geven allemaal aan dat het moeilijk wordt en dat er volgens RIPE maximaal 5 ip's per U worden uitgedeeld.

Ik wist niet dat de broekriem al zo ver was aangehaald.

Zijn er uberhaupt plannen van ISP's om uit te rollen naar IPv6?

https://www.sixxs.net/faq/connectivity/?faq=native

Want dit wordt echt een groot probleem, in ieder geval voor mij en mijn klanten..

Als je klanten hebt, ben jij dus één van degenen die zijn kop in het zand heeft gestoken. Als ondernemer had je dit moeten zien aankomen en aan de bel moeten trekken.

Maar goed, toch nog een suggestie. Wat als je nu namens je klanten op naam van de klant accounts aanvraagt. Geldt die beperking van in totaal vijf IPV4 adressen dan ook, of kun je dan per klant vijf IP adressen krijgen?

[Olaf van der Spek]

Staatslot schreef op maandag 17 januari 2011 @ 14:52:
nogmaals bedankt voor de antwoorden.

Volgens mij is name based virtual hosts ook geen optie, want voor SSL moet volgens mij toch iedere site een eigen IP adres blijven gebruiken..

Nee hoor, daarvoor heb je SNI.

[Staatslot]

Als je klanten hebt, ben jij dus één van degenen die zijn kop in het zand heeft gestoken. Als ondernemer had je dit moeten zien aankomen en aan de bel moeten trekken.

Maar goed, toch nog een suggestie. Wat als je nu namens je klanten op naam van de klant accounts aanvraagt. Geldt die beperking van in totaal vijf IPV4 adressen dan ook, of kun je dan per klant vijf IP adressen krijgen?

Beginnende ondernemer en ben direct begonnen met informeren over en naar IPv6, dus kop in het zand valt bij mij gelukkig mee Vandaar ook dat ik hier aan het lezen en het informeren ben natuurlijk..

Ik kreeg te horen dat ze graag meer adressen uitdelen, maar dat ze zelf de restrictie opgelegd hebben gekregen nog maar 5 ip adressen per U te mogen uitdelen. Heb echt doorgevraagd, maar ik kon hoog en laag springen ik kreeg er maar 5. En er werd ook gezegd, als u ze nu niet neemt en u komt over 2 maanden heb je kans dat het tot 3 is gedaald.. Dus heb die 5 ip-adressen natuurlijk direct besteld.. En het gaat om colocation dus dat kun je niet op naam van de klant aanvragen (zou ook geen nut hebben, ivm max 5 per U).

Ik ga verder kijken en proberen, erg bedankt voor alle reacties!

[Roetzen]

Staatslot schreef op maandag 17 januari 2011 @ 18:16:
[...]

Beginnende ondernemer en ben direct begonnen met informeren over en naar IPv6, dus kop in het zand valt bij mij gelukkig mee Vandaar ook dat ik hier aan het lezen en het informeren ben natuurlijk..

Ok, dan neem ik dat terug. Het ziet er dan naar uit dat je op een ongelukkig moment bent ingestapt...

[jimmy87]

Raven schreef op maandag 17 januari 2011 @ 11:01:
Heb je heel toevallig ook de embedded/nanobsd versie van pfSense?

Nee helaas hier draait het op een 80GB Sata schijf.
Maar waar dacht je aan?

[Raven]

Embedded/NanoBSD heeft het fs (op een CF-kaart in mijn geval) readonly gemaakt, bij het uitvoeren van een van die 2 scriptjes moet er iets weggeschreven worden. Dat kan dus niet met een readonly fs

Hier moet ik dan eerst /etc/rc.conf_mount_rw uitvoeren, dan scripts runnen, gevolgd door /etc/rc.conf_mount_ro.
Na elke (her)start van pfSense dus, wat niet vaak voorkomt.

[ Voor 3% gewijzigd door Raven op 17-01-2011 21:53 ]

[jimmy87]

Volgens mij heb ik daar geen last van, de pfsense bak werkt al wel op ipv6 en rtadvd deelt ook gewoon ip's uit. Het lijkt net of er een paar dingen ontbreken ofzo.

[Raven]

Hmm, in dat geval, zeker weten dat je het vinkje voor "Allow IPv6 traffic" hebt aangezet onder system -> advanced?

Of misschien dezelfde fout gemaakt als ik? (Een nummertje verkeerd...)

[axis]

Olaf van der Spek schreef op maandag 17 januari 2011 @ 16:46:
[...]

Nee hoor, daarvoor heb je SNI.

Ik heb me gisteren voor het eerst ingelezen in SNI, en ik las dat het standaard niet werkt op IE op WinXP, is dat dus geen optie voor een site die toegankelijk moet zijn voor een breed publiek. Voor sommige sites kan dat prima, maar andere sites absoluut niet. Die zijn voor hun boterham afhankelijk van de honderdduizenden henk en anita's met hun antieke winxp machines met IE.

[jimmy87]

Raven schreef op dinsdag 18 januari 2011 @ 09:40:
Hmm, in dat geval, zeker weten dat je het vinkje voor "Allow IPv6 traffic" hebt aangezet onder system -> advanced?

Of misschien dezelfde fout gemaakt als ik? (Een nummertje verkeerd...)

Hmm nee dat is het ook niet. Dat vinkje staat er ook inderdaad. Moet ik die proto 41 trouwens forwarden naar de pfsense bak zelf of kan ik die gewoon leeg laten?

[Raven]

Als je de howto hebt gebruikt die ik ook heb gebruikt, hoef je geen proto 41 te forwarden.

En de fout die ik heb gemaakt? Raven in "Het grote IPv6 topic"
edit: zo te zien niet.

Scripts van mij en die van jou naast elkaar gelegd, enigste wat ik zo kan bedenken is dat je misschien em0 en em1 hebt verwisselt?

[ Voor 58% gewijzigd door Raven op 18-01-2011 10:43 ]

[jimmy87]

em1 is bij mij lan en em0 wan.
Dat heb ik express zo gedaan zodat ik meteen weet welke voor de wan kant is en welke voor de lan kant.

[Raven]

Okee, bij mij juist andersom

Wel juiste externe ip ingesteld bij de tunnel bij HE?

Welke versie van pfSense heb je trouwens? v1.2.3 of een v2 beta?

[ Voor 27% gewijzigd door Raven op 18-01-2011 13:00 ]

[jimmy87]

Het ip bij HE komt inderdaad overeen met mijn externe ip
Ik gebruik de 1.2.3 release.

[Zsub]

Zou het kunnen dat je ergens een /64 ofzo wel of niet achter hebt staan? Maakte op mijn Openwrt nogal uit

[Raven]

jimmy87 schreef op dinsdag 18 januari 2011 @ 13:16:
Het ip bij HE komt inderdaad overeen met mijn externe ip
Ik gebruik de 1.2.3 release.

Dan is het dat iig niet, die howto is voor 1.2.3 geschreven, niet voor v2. (Al weet ik niet of dat uitmaakt )

@Zsub, zijn scripts komen zo te zien overeen met die van mij, op zijn gegevens na dan, kan niet zo gauw een fout ontdekken.

[ Voor 39% gewijzigd door Raven op 18-01-2011 13:32 ]

[jimmy87]

Ik dus ook niet, vandaar dat ik hier reageerde
Mijn scripts komen op de adressen na overeen met jou scripts en toch werkt het bij jou wel en bij mij niet.

Denk eens een centos vm online gooien en kijken of het dan werkt.

[Raven]

Ah

Kun je de IPv4 server van HE wel pingen trouwens?
En even checken of je fs toch niet heel toevallig readonly is?

[ Voor 36% gewijzigd door Raven op 18-01-2011 16:06 ]

[jimmy87]

Ipv4 adres van HE is wel te pingen en fs is volgens mij writable, dit krijg ik als ik fstab opvraag namelijk:

# cat fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/ad0s1a / ufs rw 1 1

Ik heb even een screenshot gemaakt van hoe de netwerk instellingen eruit ziet op een Windows 7 client.



Wat ik me afvraag is die gateway en geen dns adres Hoe staat dit bij jou?

[Jaap-Jan]

DNS kan ook over IPv4 en Windows doet niks de RDNSS- optie, dus dat daar geen IPv6- DNS- servers staan is geen probleem.

En als je dit in je /etc/rtadvd.conf zet?

code:

em1:\
:addr="2001:470:1f15:91::":prefixlen#64:

En anders zou 'nolladdr' kunnen helpen. En als dat niet helpt moet je even met Wireshark naar je RA's kijken.

[ Voor 33% gewijzigd door Jaap-Jan op 21-01-2011 10:55 ]

[FiscBiker]

Let op dat het screenshot 1f14 toont waar dit 1f15 zou moeten zijn

[Snow_King]

jimmy87 schreef op dinsdag 18 januari 2011 @ 21:58:
Ipv4 adres van HE is wel te pingen en fs is volgens mij writable, dit krijg ik als ik fstab opvraag namelijk:

# cat fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/ad0s1a / ufs rw 1 1

Ik heb even een screenshot gemaakt van hoe de netwerk instellingen eruit ziet op een Windows 7 client.

[afbeelding]

Wat ik me afvraag is die gateway en geen dns adres Hoe staat dit bij jou?

Die gateway klopt, dat is je link-local adres van de gateway, niets mis mee.

De DNS wordt standaard niet door radvd uitgestuurd, dus dat is ook in orde.

Ik denk dat het in de routering fout gaat in de pfSense. Ik gebruik echter de zelfde scripts en die werken prima.

[Zsub]

FiscBiker schreef op woensdag 19 januari 2011 @ 01:33:
Let op dat het screenshot 1f14 toont waar dit 1f15 zou moeten zijn

Edit: bovenstaande heeft gelijk. Ik denk dat regel 18 van 00_config-ipv6-if.sh ipv

code:

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

dit moet zijn:

code:

ifconfig $IFIN inet6 alias 2001:470:1f15:91::1 prefixlen 64

Edit2: waarbij het verder niet eindeloos uitmaakt wat je achter de :: zet, denk ik. Meestal doe ik ::1 (vanwege routers die in IPv4 ook vaak op .1 gaan zitten).

[ Voor 53% gewijzigd door Zsub op 19-01-2011 11:27 ]

[Sypher]

Sinds het weekend een HE tunnel thuis aangezet op mijn server en workstations. Werkt opzich goed, al heb ik wel het gevoel dat het allemaal net iets trager werkt.

Ik vraag me af of er een optie was om met Radvd (of iets anders) IPv6 addressen uit te delen uit mijn /48 van HE zonder zelf voor router te moeten spelen (de server is geen router).
Is er een optie om gateway op te geven, die de clients dan moeten gebruiken?

Zag dat zo 123 niet staan in de configuratie voorbeelden die ik tegenkwam.

[Jaap-Jan]

Radvd moet draaien op de server die de IPv6 gateway draait, dat is inherent aan het protocol zoals gespecificeerd in RFC 2461.

[ Voor 36% gewijzigd door Jaap-Jan op 19-01-2011 13:29 ]

[jimmy87]

Zsub je bent mijn held

@Raven, dus toch weer dat ene nummertje verkeerd

code:

C:\Users\jimmy>ping -6 ipv6.google.com

Pingen naar ipv6.l.google.com [2a00:1450:8005::93] met 32 bytes aan gegevens:
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=16 ms

Ping-statistieken voor 2a00:1450:8005::93:
    Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
    (0% verlies).

De gemiddelde tijd voor het uitvoeren van één bewerking in milliseconden:
    Minimum = 15ms, Maximum = 16ms, Gemiddelde = 15ms

Vanaf een Windows 7 client

[Zsub]

Welkom in de IPv6-wereld

Ik vindt het wel echt jammer dat je met RA's niet standaard DNS mee kan geven (behalve dan sommige Linux distros die daar een package voor hebben).

[CyBeR]

Zsub schreef op woensdag 19 januari 2011 @ 18:26:
Welkom in de IPv6-wereld

Ik vindt het wel echt jammer dat je met RA's niet standaard DNS mee kan geven (behalve dan sommige Linux distros die daar een package voor hebben).

Dat komt omdat die RA's door de kernel ontvangen worden, en de meeste kernel developers vinden dat resolven == userland == hoort niet in kernel == hoeven zij niet te doen.

[Raven]

jimmy87 schreef op woensdag 19 januari 2011 @ 18:04:
Zsub je bent mijn held

@Raven, dus toch weer dat ene nummertje verkeerd

code:

C:\Users\jimmy>ping -6 ipv6.google.com

Pingen naar ipv6.l.google.com [2a00:1450:8005::93] met 32 bytes aan gegevens:
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=15 ms
Antwoord van 2a00:1450:8005::93: tijd=16 ms

Ping-statistieken voor 2a00:1450:8005::93:
    Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
    (0% verlies).

De gemiddelde tijd voor het uitvoeren van één bewerking in milliseconden:
    Minimum = 15ms, Maximum = 16ms, Gemiddelde = 15ms

Vanaf een Windows 7 client

->

databeestje schreef op vrijdag 05 november 2010 @ 22:41:
Het is veruit de meest gemaakte fout die ik op de diverse fora heb gezien. Het routed subnet verschilt 1 karakter met het subnet dat voor de routing gebruikt wordt van de gif tunnel.

Mooi dat het nu werkt

[jimmy87]

Ja En jij ook bedankt natuurlijk Raven Zonder jou tutorial was het helemaal nooit gelukt

[Zsub]

CyBeR schreef op woensdag 19 januari 2011 @ 18:48:
[...]


Dat komt omdat die RA's door de kernel ontvangen worden, en de meeste kernel developers vinden dat resolven == userland == hoort niet in kernel == hoeven zij niet te doen.

Hoe zit dat dan eigenlijk met DHCP? Want alle OS'en doen wel standaard een IPv4 DHCP, maar niet zomaar IPv6, sterker nog, volgens dit lijstje zijn er meerdere die geen van beiden doen: Wikipedia: Comparison of IPv6 support in operating systems

Ik vraag me af waarom dan alles en iedereen wel aan DHCP4 doet, maar niet aan DHCP6...

[Olaf van der Spek]

Zsub schreef op woensdag 19 januari 2011 @ 23:06:
Ik vraag me af waarom dan alles en iedereen wel aan DHCP4 doet, maar niet aan DHCP6...

Omdat het met IPv6 niet nodig is.

[Zsub]

Maar zou je dan niet zeggen dat ze standaard óf RDDNS óf DHCP6 zouden 'moeten' doen? Dat lijkt mij dan logisch, dat je toch op z'n minst out of the box één van de twee doet. Zodat je toch volledige IPv6 connectivity kan hebben.

[CAPSLOCK2000]

DHCP draait helemaal in userland.
Omdat bij IPv6 adres-autoconfiguratie ingebakken zit valt de belangrijkste taak van DHCP weg.

Misschien dat het er ook nog iets mee te maken heeft dat nog maar weinig eindgebruikers iets doen met IPv6. De servers en routers die wel gebruik maken van IPv6 hebben meestal statische adressen, daar wil je helemaal geen autoconfiguratie.

[moto-moi]

Olaf van der Spek schreef op donderdag 20 januari 2011 @ 18:56:
Omdat het met IPv6 niet nodig is.

dnsservers zou toch wel fijn zijn volgens mij? Geen idee hoe ik die dynamisch kan voeren aan m'n clients..

[BarthezZ]

DNS is maar een puntje, maar er zijn er veel meer die ik vaak via DHCPv4 voer (aan bijvoorbeeld een client of SIP toestel)
- DNS dus
- PXE/TFTP Server
- NTP
- Domain Name
En aan sommige devices ook nog wel dingen als Log of SMTP server. (Gewoon omdat het makkelijk is dat centraal te doen dan om per device in te stellen)

Hoe ik dat zonder verhoogde beheerstlast op al die devices ga instellen met IPv4 weet ik nog niet eigenlijk. Het is denk ik dus echt wel nodig dat er hier een algehele standaard in ontstaat die ook voor embedded devices ook geïmplementeerd wordt.

[Freeaqingme]

moto-moi schreef op donderdag 20 januari 2011 @ 23:35:
[...]

dnsservers zou toch wel fijn zijn volgens mij? Geen idee hoe ik die dynamisch kan voeren aan m'n clients..

RFC5006?

[moto-moi]

Freeaqingme schreef op vrijdag 21 januari 2011 @ 03:02:
[...]

RFC5006?

Als ik die ff snel doorscan en dus 4339 ook, zeggen die dat je dhcpv6 moet gebruiken. En dat wordt volgens mij juist weer ruk ondersteund door bijvoorbeeld MacOS X, en ik kan het, onder Debian, rot naast ipv4 draaien omdat het dezelfde daemon(dhcpd) is, maar toch ook weer niet

[Roetzen]

X-Day

De teller van Geoff Huston staat nu ook op nul: http://www.potaroo.net/tools/ipv4/index.html

IANA heeft de laatste blokken nog niet daadwerkelijk uitgegeven, maar mijn stellige verwachting is dat dat vandaag nog gebeurt. De "last minute rush" is duidelijk begonnen, dus we gaan spannende tijden tegemoet. Voor degenen die nu nog niks gedaan hebben aan IPv6, is het tijd voor lichte paniek

[Olaf van der Spek]

Zsub schreef op donderdag 20 januari 2011 @ 20:57:
Maar zou je dan niet zeggen dat ze standaard óf RDDNS óf DHCP6 zouden 'moeten' doen? Dat lijkt mij dan logisch, dat je toch op z'n minst out of the box één van de twee doet. Zodat je toch volledige IPv6 connectivity kan hebben.

Wat is RDDNS? Je hebt zonder toch al volledige IPv6 connectivity?

moto-moi schreef op donderdag 20 januari 2011 @ 23:35:
[...]

dnsservers zou toch wel fijn zijn volgens mij? Geen idee hoe ik die dynamisch kan voeren aan m'n clients..

Via Router Announcement (gok ik)?

[ Voor 24% gewijzigd door Olaf van der Spek op 21-01-2011 10:25 ]

[axis]

@Roetzen,
Spannend, ik zie het ja..

Ik kijk er wel naar uit, maar da's logisch aangezien we al jaren wachten op deze dag (naja, eigenlijk tot RIPE leeg is). Ik kan niet wachten tot ik al die huilende projectmanagers van onze klanten en leveranciers uit kan lachen als ze weer eens een nieuw project op willen zetten en geen ipv4 adressen meer krijgen.. Gelukkig kunnen wij ze dan met onze kennis weer helpen, en verdient mijn baas weer een boel centjes.. Fijn, die open marktwerking

[Jaap-Jan]

Olaf van der Spek schreef op vrijdag 21 januari 2011 @ 10:24:
[...]

Wat is RDDNS? Je hebt zonder toch al volledige IPv6 connectivity?

RDNSS bedoeld 'ie. En zonder dat of DHCPv6 kun je geen IPv6- only draaien met stateful of stateless autoconfiguration.

[Zsub]

Olaf van der Spek schreef op vrijdag 21 januari 2011 @ 10:24:
[...]

Wat is RDDNS? Je hebt zonder toch al volledige IPv6 connectivity?

[...]

Via Router Announcement (gok ik)?

Ik bedoel inderdaad RDNSS, en dat is juist de techniek om een DNS via RAs aan je host te voeren, en dat werkt nou juist niet out of the box op een heleboel systemen.

En probeer maar eens geen IPv4 DNS servers op te geven op je systeem, dat noem je toch ook geen volledige IPv4 connectivity?

[ Voor 13% gewijzigd door Zsub op 21-01-2011 11:31 ]

[axis]

Deze presentatie legt het ook wel mooi uit: http://lacnic.net/documen...taciones/DNS_and_IPv6.pdf met nog wat extra uitleg.

Currently there are four ways to configure the DNS servers on the client:
- Static configuration
- RA Option (RDNSS)
- DHCPv6
- Well known anycast DNS Servers

Maar ik ben zelf nu ook even aan het zoeken welke OS'sen nu standaard welke functionaliteit ondersteunen..

Edit: als ik deze pagina bekijk: Wikipedia: Comparison of IPv6 support in operating systems maak ik dus ook op dat een boel OSsen (we gebruiken hier Windows, CentOS5 en FreeBSD) wel DHCPv6 gebruiken, maar dus niet de RDNSS optie.. Sja, dan wordt het een makkelijke keus.

[ Voor 33% gewijzigd door axis op 21-01-2011 11:34 ]

[Roetzen]

axis schreef op vrijdag 21 januari 2011 @ 10:28:
Ik kijk er wel naar uit, maar da's logisch aangezien we al jaren wachten op deze dag (naja, eigenlijk tot RIPE leeg is).

Het afknijpen schijnt albegonnen te zijn. Lazen we hier een paar dagen geleden niet dat iemand nog maar 5 adressen kon krijgen?

Ik kan niet wachten tot ik al die huilende projectmanagers van onze klanten en leveranciers uit kan lachen als ze weer eens een nieuw project op willen zetten en geen ipv4 adressen meer krijgen..

Ja,dat wordt huiliehuilie...

Gelukkig kunnen wij ze dan met onze kennis weer helpen, en verdient mijn baas weer een boel centjes..

Waar dan hopelijk ook wat van naar jou vloeit...

[Jaap-Jan]

axis schreef op vrijdag 21 januari 2011 @ 11:30:
Deze presentatie legt het ook wel mooi uit: http://lacnic.net/documen...taciones/DNS_and_IPv6.pdf met nog wat extra uitleg.


[...]


Maar ik ben zelf nu ook even aan het zoeken welke OS'sen nu standaard welke functionaliteit ondersteunen..

Edit: als ik deze pagina bekijk: Wikipedia: Comparison of IPv6 support in operating systems maak ik dus ook op dat een boel OSsen (we gebruiken hier Windows, CentOS5 en FreeBSD) wel DHCPv6 gebruiken, maar dus niet de RDNSS optie.. Sja, dan wordt het een makkelijke keus.

Er is bij DHCPv6 ook gedacht aan Router Advertisements. Je kunt ook beide draaien en alleen DHCPv6 gebruiken om DNS toe te kennen (option granting) en dan ook RDNSS aanzetten, of zelfs radvd en DHCPv6 naast elkaar draaien.Op die manier kunnen clients gebruiken wat ze ondersteunen. Hoe dat werkt staat beschreven in RFC 5006.

Ik ben wel benieuwd hoe dat in de praktijk werkt met verschillende OS'sen.

[IcE_364]

Wie weet een oplossing of zoektermen voor het volgende probleem:

Op kantoor hebben wij (omdat onze provider nog geen native IPv6 heeft) een SixXS tunnel met een /48 voor de clients, dit werkt allemaal perfect. Het locale subnet is 2001:1af8:aaaa::/48, welke we gesubnet hebben in o.a. 2001:1af8:aaaa:28::/64.

Daarnaast hebben we via RIPE een allocatie 2a02:bbbb::/32. Het idee was om een deel van de /32 te reserveren voor gebruik over ons VPN, deze word dus niet geannounced op het internet en is voor ons alleen lokaal voor ons te routeren.

Zo gezegd zo gedaan, dus 2a02:bbbb:ff::/40 gereserveerd hiervoor en 2a02:bbbb:ff01::/48 toegekend aan de kantoorlocatie. Voor het bovenstaande VLAN (van de tunnel) ook de RA prefix 2a02:bbbb:ff01:28::/64 toegevoegd en alle clients kregen netjes 2 IPv6 adressen + link-local:

code:

en0:
    ether c4:2c:03:21:89:02 
    inet6 fe80::c62c:3ff:fe21:8902%en0 prefixlen 64 scopeid 0x4 
    inet6 2001:1af8:aaaa:28:c62c:3ff:fe21:8902 prefixlen 64 autoconf
    inet6 2a02:bbbb:ff01:28:c62c:3ff:fe21:8902 prefixlen 64 autoconf

Verbindingen e.d. getest en alles lijkt te werken. Wanneer een client een website via IPv6 bezoekt gaat dit gewoon goed en de clientpc initieert dan netjes z'n verbinding via z'n 2001:1af8:aaaa:28::/64 adres, welke routeerbaar is.

Echter vanochtend kreeg ik de vraag van een collega die www.dumpert.nl (2a00:d00:ff:235:81:23:247:230) niet meer kon bereiken. Nu blijkt dat de clients wanneer ze verbinding proberen te maken naar dumpert, ze deze verbinding initieren vanaf hun 2a02:bbbb:ff01:28::/64 adres, de request gaat dus wel naar buiten, maar het antwoord komt nooit terug aangezien 2a02:bbbb:ff::/40 niet geannounced word.

code:

$ ping6 dumpert.nl
PING6(56=40+8+8 bytes) 2a02:bbbb:ff01:28:c62c:3ff:fe21:8902 --> 2a00:d00:ff:235:81:23:247:230
Request timeout for icmp_seq=0

Alle clients zijn Mac OSX of Windows. Beide OS-en hebben hetzelfde probleem.

Flow capture van 1 ping naar dumpert:
http://pastie.org/1483824

Concrete vragen:
Waarop baseert de client zijn uitgaande adres?
Waarom pakt de client bij bijna elke site de goede, behalve (tot nu toe) bij dumpert (en geenstijl)?
Is dit wel de correcte methode om toch nog een soort privaat vpn te hebben?

[Roetzen]

IcE_364 schreef op vrijdag 21 januari 2011 @ 12:15:
Is dit wel de correcte methode om toch nog een soort privaat vpn te hebben?

Waren daar de Unique Local Unicast adressen ( RFC 4193 ), niet voor bedoeld?

[IcE_364]

Roetzen schreef op vrijdag 21 januari 2011 @ 13:04:
[...]

Waren daar de Unique Local Unicast adressen ( RFC 4193 ), niet voor bedoeld?

Die behoren ook tot de global scope en veroorzaken in theorie hetzelfde probleem. Voordeel van het gebruik van onze eigen assignment boven ULA space is dat onze eigen assignment 100% zeker uniek is, ULA enkel theoretisch.

[ Voor 20% gewijzigd door IcE_364 op 21-01-2011 13:08 ]

[Jaap-Jan]

IcE_364 schreef op vrijdag 21 januari 2011 @ 13:07:
[...]

Die behoren ook tot de global scope en veroorzaken in theorie hetzelfde probleem. Voordeel van het gebruik van onze eigen assignment boven ULA space is dat onze eigen assignment 100% zeker uniek is, ULA enkel theoretisch.

Hoe bedoel je? Local unicast adressen worden niet gerouteerd, dus accouncements komen nooit voorbij een router.

[IcE_364]

Jaap-Jan schreef op vrijdag 21 januari 2011 @ 13:12:
[...]
Hoe bedoel je? Local unicast adressen worden niet gerouteerd, dus accouncements komen nooit voorbij een router.

Ze worden niet gerouteerd, maar technisch gezien behoren ze wel tot de global scope. Na wat zoekwerk ben ik al verder (helaas niet met een oplossing). Het source address selection algorithme maakt hier schijnbaar geen uitzondering voor:

http://web.archiveorange.com/archive/v/Wh4ryQzHphXEt68nboog
http://www.sixxs.net/forum/?msg=general-2642533
http://etherealmind.com/i...efault-address-selection/

Daarnaast wordt onze 2a02:bbbb:ff::/40 ook niet geannounced dus dit komt op hetzelfde neer.

Edit:
Zou het te maken kunnen hebben met de volgende regel uit http://etherealmind.com/i...fault-address-selection/:

If all criteria are similar, address pairs with the longest common prefix are preferred.

Omdat zowel onze prefix als die van dumpert uit 2a02:: komt, wordt voor dumpert het 2a02:bbbb:ff:: adres gepakt als source adres. In principe zou je het probleem dan met ULA niet (minder vaak?) moeten hebben omdat die veel verder van de op internet bruikbare prefixes af ligt?

Hoe gaan anderen om met de adressering op hun vpn? Of gebruikt iedereen ULA?

[ Voor 34% gewijzigd door IcE_364 op 21-01-2011 13:31 ]

[Roetzen]

IcE_364 schreef op vrijdag 21 januari 2011 @ 13:18:
Hoe gaan anderen om met de adressering op hun vpn? Of gebruikt iedereen ULA?

Het lijkt me dat je geen global routeerbare adressen moet gebruiken voor een VPN. Dat doe je toch met IPv4 ook niet? Het hele idee van een VPN is toch juist dat het private is?

[Freeaqingme]

Roetzen schreef op vrijdag 21 januari 2011 @ 14:13:
[...]

Dat doe je toch met IPv4 ook niet?

Met ipv4 delen we ook geen /64 blokken uit aan particulieren. Dat je met ipv4 iets niet doet lijkt me geen reden het daarom met ipv6 ook niet te doen. Je maakt 't private door er een firewall tussen te zetten die jou wel toelaat alsof je op 't interne netwerk zit, en de rest van de wereld niet...

[Roetzen]

Freeaqingme schreef op vrijdag 21 januari 2011 @ 20:42:
Met ipv4 delen we ook geen /64 blokken uit aan particulieren. Dat je met ipv4 iets niet doet lijkt me geen reden het daarom met ipv6 ook niet te doen.

Dat is waar. Er zijn ook zat adressen, dus daarom hoef je het ook niet te laten.

Je maakt 't private door er een firewall tussen te zetten die jou wel toelaat alsof je op 't interne netwerk zit, en de rest van de wereld niet...

Door echter geen publiek routeerbare adressen te gebruiken voor je VPN, voorkom je dat ze "per ongeluk" toch ontsnappen naar de buitenwereld. Dat argument geldt zowel voor IPv4 als IPv6

[ Voor 3% gewijzigd door Roetzen op 22-01-2011 11:36 ]

[Icingdeath]

Iemand hier ervaring met routeren vanuit een ISATAP IPv6 subnet naar een native IPv6 subnet, is het gewoon een kwestie van een extra interface op je ISATAP router toevoegen die in het native ipv6 subnet zit?

[ Voor 30% gewijzigd door Icingdeath op 22-01-2011 12:40 ]

[databeestje]

Ik zie hier een vergelijkbaar probleem als waar ik zelf ook tegenaanliep. Wat ik heb gedaan is gebruik maken van ULA adressen op de LAN netwerken, bij Sixxs even een unieke ULA geregistreerd en een ::/48 toegewezen gekregen.

Daarnaast heb ik in mijn pfSense source tree "Network Prefix Translation" ondersteuning ingebouwd.

Met andere woorden, ik kan weer gewoon policy routing en multiwan doen voor de hele toko. En pfSense bepaalt waar het verkeer heen gaat op 1 centrale plaats. Statisch routes en firewall rules regelen alles. Wel zo beheersbaar.

Wat Network Prefix Translation (NPt voorheen NAT66 genoemd) doet is het vervangen van het linker 64 bit deel door het global unicast network prefix, de rechter 64 bits, het computer adres blijft hetzelfde.

Wat dit realiseert is dat ik op alle 3 de WAN verbindingen (1 native ::/56 en 2 HE.net ::/48's) verbinding naar binnen en buiten kunnen maken. Het is dus geen Port translatie maar enkel een adres mapping. Hierdoor blijft end-to-end connectiviteit gewaarborgt en is het gehele netwerk via alle 3 verbindingen te bereiken.

Omdat van de 3 wan verbindingen deze verschillen in snelheid kan ik door policy routing alles per default de snelle pijp uit sturen.

Ik heb wel gekeken naar de PI space voor IPv6 en IPv4 maar dat is een beetje lastig scenario aan het worden met de huidige crunch voor ipv4. Daarnaast moet het ook maar zo zijn dat de ISP's BGP ondersteunen, en een ::/56 wordt ook niet door alle Peers in de BGP table opgenomen.

[sPENKMAN]

Vandaag maar weer eens verder gegaan met het ipv6 verhaal. Ik heb nu 2 gateways (1 in het DC en 1 thuis) voorzien van een ipv6 tunnel en het werkt eindelijk naar behoren. Op beide locaties worden ipv6 adressen netjes uitgedeeld door radvd en kan ik vanaf mijn desktop (W7) ipv6 sites bezoeken.

De timeout op de tunnel heb ik ook opgemerkt, als er enige tijd geen ipv6 connectiviteit naar buiten toe is valt de tunnel stil. Heb nu op beide locaties een cron iedere minuut draaien die een ping doet naar het ipv6 tunnel endpoint.

Zojuist een van de domeinen die ik heb online gebracht op IPv6, eindelijk werkt het gewoon goed. Volgende stap wordt de loadbalancer zover te krijgen dat deze het IPv6 adres gaat loadbalancen over mijn 3 webnodes, gaat volgens mij ook wel een leuke uitdaging worden....

EDIT:
Hmm ik zie dat keepalived inmiddels fully ipv6 supported is, allicht dat het nog mee gaat vallen. Binnenkort maar even de laatste versie compileren dan

[ Voor 9% gewijzigd door sPENKMAN op 23-01-2011 16:18 ]

[Snow_King]

sPENKMAN schreef op zondag 23 januari 2011 @ 16:08:

Zojuist een van de domeinen die ik heb online gebracht op IPv6, eindelijk werkt het gewoon goed. Volgende stap wordt de loadbalancer zover te krijgen dat deze het IPv6 adres gaat loadbalancen over mijn 3 webnodes, gaat volgens mij ook wel een leuke uitdaging worden....

Met LVS werkt dat inderdaad prima!

EDIT:
Hmm ik zie dat keepalived inmiddels fully ipv6 supported is, allicht dat het nog mee gaat vallen. Binnenkort maar even de laatste versie compileren dan

Klopt, daar is de laatste tijd hard aan gewerkt! Zaten wat bugjes in, maar die zijn inmiddels verholpen.

Zitten nog wel wat haken en ogen aan, maar die zijn prima op te lossen.

Heb nu KeepAlived al zo'n 2 maanden draaien met Full IPv6 support en werkt prima! (Als je de haken en ogen opgelost hebt).

Ik had bijvoorbeeld last dat de Health checkers het VIP gebruikte om de Real servers te monitoren, maar dat werkt niet, want de RS kent het VIP ook lokaal. Daar moet je dus een "bindto" voor in je health sectie zitten.

Anders zijn vragen op de KeepAlived mailinglist welkom, ik ben daar ook actief

[axis]

Ik lees ook mee op de keepalived mailing list, maar ik gebruik nu al een half jaar tot een jaar pacemaker voor ipv6+ipv4 high-availability. Werkt als een trein, en een stuk robuuster dan de carp die ik op freebsd gebruikte.

Ik gebruik trouwens op al mijn balancers Varnish of Squid 3.1 luisterend op poort 80, en die supporten netjes ipv6. Daarachter hangt in mijn geval haproxy, welke nog niet ipv6 doet, maar dat maakt mij nog niet zoveel uit. Zolang de clients maar ipv6 kunnen doen

[Snow_King]

axis schreef op zondag 23 januari 2011 @ 21:19:
Ik lees ook mee op de keepalived mailing list, maar ik gebruik nu al een half jaar tot een jaar pacemaker voor ipv6+ipv4 high-availability. Werkt als een trein, en een stuk robuuster dan de carp die ik op freebsd gebruikte.

Ik gebruik trouwens op al mijn balancers Varnish of Squid 3.1 luisterend op poort 80, en die supporten netjes ipv6. Daarachter hangt in mijn geval haproxy, welke nog niet ipv6 doet, maar dat maakt mij nog niet zoveel uit. Zolang de clients maar ipv6 kunnen doen

Mag ik vragen waarom ja HAProxy ACHTER Varnish zet? Want Varnish kan zelf ook al HTTP loadbalancen (doe ik ook), ik zie niet waarom HAProxy er nog bij moet.

Ik balance met KeepAlived over twee Varnish machines die vervolgens over een pool met webservers balancen.

[Verwijderd]

Ik had een IPv6 tunnel van HE op mijn dedicated server geinstalleerd, en dit werkte prima.
Nadeel was dat de verbinding met de IPv6 tunnelbroker iedere keer werd verbroken, en ik de tunnel opnieuw moest opstarten door deze te resetten.

Is er een mogelijkheid vanuit Linux een keepalive te versturen naar de server, zodat de verbinding actief blijft?

[axis]

Snow_King schreef op zondag 23 januari 2011 @ 22:00:
[...]
Mag ik vragen waarom ja HAProxy ACHTER Varnish zet? Want Varnish kan zelf ook al HTTP loadbalancen (doe ik ook), ik zie niet waarom HAProxy er nog bij moet.

Ik balance met KeepAlived over twee Varnish machines die vervolgens over een pool met webservers balancen.

Omdat ik de balancing van haproxy beter ken, meer vertrouw, en deze betere statistieken laat zien (duidelijk voor onze operators).. En mijn varnish werdt een beetje traag toen ik boven de 30.000 regels kwam in mijn vcl, haproxy heeft er geen enkel probleem mee. Waarschijnlijk doen we ook gewoon rare dingen, maar in de huidige setup werkt het prima

Haproxy is bij ons de spil in het web. Doorvoor zit Varnish voor HTTP acceleration, en Squid 3.1 voor HTTPS acceleration..

[ Voor 7% gewijzigd door axis op 24-01-2011 15:22 ]

[Zsub]

Verwijderd schreef op maandag 24 januari 2011 @ 15:17:
Ik had een IPv6 tunnel van HE op mijn dedicated server geinstalleerd, en dit werkte prima.
Nadeel was dat de verbinding met de IPv6 tunnelbroker iedere keer werd verbroken, en ik de tunnel opnieuw moest opstarten door deze te resetten.

Is er een mogelijkheid vanuit Linux een keepalive te versturen naar de server, zodat de verbinding actief blijft?

Een ping6 laten draaien (of via cron draaien) werkt. Ongeveer iedere minuut een pakketje houdt je verbinding in stand, voor zover ik weet.

Insta-edit: mijn HE tunnel blijft gewoon op... Zonder dat ik expliciet pings stuur, e.d...

[elsinga]

Op de frontpage trouwens nu een ipv6 poll.

[Zsub]

Er is natuurlijk maar één 'goed' antwoord voor de mensen in dit topic

[axis]

Iemand een goede ULA generator?

Zoiets als dit, alleen staat deze al erg lang op 'coming soon': https://www.ultratools.com/tools/rangeGenerator

edit: duh, kom net deze tegen: http://www.sixxs.net/tools/grh/ula/

[ Voor 19% gewijzigd door axis op 24-01-2011 17:10 ]

[Roetzen]

Computable wordt wakker....

IANA deelt laatste IPv4-adressen uit

Naar alle waarschijnlijkheid is de Internet Assigned Numbers Authority (IANA) op 2 februari 2011 door haar voorraad IPv4-adressen heen. Dat voorspelt het Asia Pacific Network Information Centre (APNIC) in het Australische Brisbane.

Read more: http://www.computable.nl/...tml#3752475#ixzz1ByHSxI2t

Gisteren stond volgens Huston de teller afgelopen woensdag al op nul. Hij heeft hem kennelijk bijgesteld, want nu loopt ie weer en zal op 2 februari op nul komen. De teller van Lagerholm staat als een paar dagen op nul. Het kan dus net zo goed vandaag nog gebeuren. Wie het zegt weet het niet en wie het weet wil het niet zeggen...

Het commentaar op computable onder de naam Michiel is van mij.

[Raven]

Nog 8 dagen te gaan aldus IPv4Countdown @ Twitter:

The number of allocatable IPv4s just dropped below thirty-six million. #IPv6

19 hours ago

[Roetzen]

De teller op he.net zegt hetzelfde. De geruchtenmachine draait op volle toeren. Het lijkt er op dat er een soort happening gepland is op 2 februari. We zullen zien.

[databeestje]

Mooie post apocolyptische datum, 02-02-2011

[Verwijderd]

Ik ben er inmiddels in geslaagd om mijn IPv6 tunnel op CentOS 5.5 gewoon stabiel up te laten zonder dat ik hem opnieuw moet connecten.

Nog heb ik alleen nog de vraag, hoe kan ik er voor zorgen dat mijn IPv6 tunnel weer automatisch tot stand komt na een reboot? Ik moet nu iedere keer na een reboot van mijn server de ip commando's opnieuw opgeven in de terminal. Is er een mogelijkheid dat dit na een reboot automatisch gebeurt?

[Zsub]

Je kan een klein scriptje schrijven en dat door je init laten doen :-)

Misschien zelfs binnen het netwerk-gedeelte van je init hangen

[Nox]

Ziggo heeft geen ipv6 mogelijkheid Morgen bellen, wil ik alvast een nieuwe modem voordat we zonder ipadres zitten. Zie ook: Ziggo IPV6 wel beschikbaar?

Als je straks storing hebt dan kun je dus geen nieuw ip-adres krijgen? Of kom je dan in de wachtlijst te staan bij de dikke uber-1337-DHCP server van 'de wereld' ? Wat gebeurt er dus eigenlijk als alles op is?

[Jaap-Jan]

NoxiuZ schreef op woensdag 26 januari 2011 @ 00:11:
Ziggo heeft geen ipv6 mogelijkheid Morgen bellen, wil ik alvast een nieuwe modem voordat we zonder ipadres zitten. Zie ook: Ziggo IPV6 wel beschikbaar?

Als je straks storing hebt dan kun je dus geen nieuw ip-adres krijgen? Of kom je dan in de wachtlijst te staan bij de dikke uber-1337-DHCP server van 'de wereld' ? Wat gebeurt er dus eigenlijk als alles op is?

Je hoeft ook weer niet zó dramatisch te doen. Zolang Ziggo er geen duizenden klanten bij krijgt, zullen daar de IP- adressen niet zo snel opraken.

Dit gaat over IANA, die blokken IP- adressen uitdeelt aan RIR's zoals RIPE, ARIN, AfriNIC, APNIC en LACNIC. Elke RIR is verantwoordelijk voor de uitgifte van IP- adressen voor een bepaalde regio. Voor Europa is dat RIPE. Als Ziggo IP- adressen tekort komt, vragen ze nieuwe aan bij RIPE. Elke RIR heeft wel een aantal blokken op voorraad liggen, maar er komt een dat dat IANA het laatste blok uitdeelt aan een RIR, op dat moment is het afwachten totdat er een RIR begint te schreeuwen dat 'ie niets meer kan uitdelen en op dat moment breekt de pleuris uit (), want dan kunnen er geen nieuwe mensen/ bedrijven worden aangesloten en beginnen ISP's en dergelijke zich te realiseren dat ze te laat aan IPv6 zijn begonnen.

[Freeaqingme]

nouja, ook dat duurt dan nog wel even. De grotere ISP's hebben al een leuk voorraadje opgebouwd, en daarna gaan ze gewoon CGN en 6rd gebruiken...

[axis]

Volgens woordvoerders van Ziggo hebben ze een enorme ipv4 pool, mede dankzij het feit dat ze een aantal fusies achter de rug hebben. Ondanks dat ze al lang in hun testlab bezig zijn met ipv6, geven ze het dus niet zo'n hoge prio.. Grrr..

[Keiichi]

Ik wou de DHCP server van isc gaan opzetten voor alleen IPv6. Kan dit eigenlijk wel, zonder ook maar ergens enige referentie op IPv4 te gebruiken?

In het netwerk zit nog een dhcp server die alleen ipv4 doet en die mogen niet met elkaar ruzieen.

-edit-

Nu ga ik iets heel moeilijks vragen. Waarschijnlijk is het iets veroorzaakte door een verandering in de linux kernel.

Ik heb een tap device aangemaakt, hier ken ik een IPv4 adres aan toe. Niets aan het handje, het adres is gewoon lokaal te pingen.

Nu ga ik een IPv6 er aan vast hangen. Bij een wat oudere systeem met kernel 2.6.31.2 werkt dit zonder probleem, op andere systeem waar ik de kernels 2.6.36.3 en 2.6.37 op geinstalleerd heb, gaat dit niet. Ik krijg zelfs te horen: "Destination unreachable: Address unreachable"

Wie kan er tussen de kernels ergens een verandering vinden die dit veroorzaakt?

Een detail dat ik hierbij ook gevonden heb, is dat de 'tap' device ook geen linklocal ipv6 adres heeft.

[ Voor 59% gewijzigd door Keiichi op 26-01-2011 12:09 ]

[Roetzen]

axis schreef op woensdag 26 januari 2011 @ 10:30:
Volgens woordvoerders van Ziggo hebben ze een enorme ipv4 pool, mede dankzij het feit dat ze een aantal fusies achter de rug hebben. Ondanks dat ze al lang in hun testlab bezig zijn met ipv6, geven ze het dus niet zo'n hoge prio.. Grrr..

Ze mogen nog tot St Juttemis IPv4 adressen in reserve hebben, zo vergeten dat als ze verder niks doen een steeds groter deel van het InterNet voor hun klanten onbereikbaar zal worden. Want dat vanaf eind van dit jaar er delen van het InterNet IPv6 only zullen worden staat wel vast. Let ook op de spelletjes markt. Er zal een tipping point komen waarbij de echt blitse snelle on-line games via IPv6 werken. En de die-hard gamer zal geen 150 mS extra delay door een tunnel accepteren. Dus de ISPs die dan nog geen native IPv6 kunnen bieden staan op achterstand. Ik denk dat Ziggo zich te veel concentreert op leuke dingen als interactieve TV en te weinig prioriteit geeft aan IPv6. Ze zijn te veel met content bezig en te weinig met techniek. En dat kon ze nog wel eens lelijk opbreken.

[Zsub]

Ach, ik denk dat dat wel mee zal vallen. Voordat games echt IPv6 only worden zal niet in de komende vijf jaar gebeuren, gok ik. En waarschijnlijk niet eens in de komende tien jaar.

[axis]

Ik ben het eens met Roetzen, ik denk dat dit jaar aan een grote boel content IPv6 only gaat worden, zij het niet vooral in Australië en Azië. De rest van de wereld zal niet lang achter blijven. Maar blijf dit topic in de gaten houden en je komt erachter

[Zsub]

Nouja, mocht het zo zijn dat er een boel content v6 only wordt zijn er natuurlijk nog altijd de standaard oplossingen zoals een tunneltje. Ik ping via HE.net in ongeveer 15 ms naar Google, dus dat is ruim vlot genoeg om te gamen. Heck, ik kan me nog herinneren dat ik CounterStrike speelde met 100ms lag via 56k6

offtopic:
@Roetzen: mS is millisiemens, siemens is de SI-eenheid voor geleidingsvermogen

[Kees]

Roetzen schreef op woensdag 26 januari 2011 @ 13:47:
[...]

Ze mogen nog tot St Juttemis IPv4 adressen in reserve hebben, zo vergeten dat als ze verder niks doen een steeds groter deel van het InterNet voor hun klanten onbereikbaar zal worden. Want dat vanaf eind van dit jaar er delen van het InterNet IPv6 only zullen worden staat wel vast. Let ook op de spelletjes markt. Er zal een tipping point komen waarbij de echt blitse snelle on-line games via IPv6 werken. En de die-hard gamer zal geen 150 mS extra delay door een tunnel accepteren. Dus de ISPs die dan nog geen native IPv6 kunnen bieden staan op achterstand. Ik denk dat Ziggo zich te veel concentreert op leuke dingen als interactieve TV en te weinig prioriteit geeft aan IPv6. Ze zijn te veel met content bezig en te weinig met techniek. En dat kon ze nog wel eens lelijk opbreken.

Ik denk dat je wel wat overdrijft. De meeste ISP's zullen nog jaren dmv NAT of een 6to4 gateway je (proberen) zoveel mogelijk in de ipv4 te houden. Niemand zal de eerste willen zijn die ipv6 only gaat, want het heeft geen voordelen tov een mixed oplossing. Pas als meer dan 95% van de NL aansluitingen native ipv6 heeft zie ik de eerste nederlandse v6-only websites ontstaan, niet eerder.

[Snow_King]

Kees schreef op woensdag 26 januari 2011 @ 16:49:
[...]

Ik denk dat je wel wat overdrijft. De meeste ISP's zullen nog jaren dmv NAT of een 6to4 gateway je (proberen) zoveel mogelijk in de ipv4 te houden. Niemand zal de eerste willen zijn die ipv6 only gaat, want het heeft geen voordelen tov een mixed oplossing. Pas als meer dan 95% van de NL aansluitingen native ipv6 heeft zie ik de eerste nederlandse v6-only websites ontstaan, niet eerder.

Ik denk dat hij op de andere kant van de wereld doelt, daar is het namelijk wel bijna over en uit.

Ook dat is onderdeel van het internet

[Zsub]

Er is natuurlijk niks mis mee om IPv4 connectivity te houden vanwege met backwards compatibility. En IPv6-only zal pas gaan gebeuren als écht alles op is, alle RIR's niks meer hebben en dat soort dingen.

[axis]

Wat ga je doen als content provider als je 20 ssl sites moet opzetten (die ook in IE6 op XP moeten werken) en je krijgt van je isp maar 5 IPv4 ip's? Hoe ga je dat oplossen met NAT of 6-to-4 gateways dan?

[databeestje]

Leuk, maar dan moet je nog steeds ipv4 adressen hebben voor de gateways. Manco

Voor het gros aan mobieltjes in 2012 en later zullen er vast wel een stuk of wat ipv6 only zijn. Ik geloof niet dat de telecom aanbieders echt zitten te springen om dual stack telefoons, terwijl een NAT64 daar weer erg weinig uitmaakt.

Behalve dan dat een gros aan skype en sip clients in een deuk gaat. Oeps.

[Verwijderd]

axis schreef op woensdag 26 januari 2011 @ 18:25:
Wat ga je doen als content provider als je 20 ssl sites moet opzetten (die ook in IE6 op XP moeten werken) en je krijgt van je isp maar 5 IPv4 ip's? Hoe ga je dat oplossen met NAT of 6-to-4 gateways dan?

Overstappen naar een ISP die dat snapt en je gewoon die adressen geeft als er een goede reden voor is

[Mawlana]

Kees schreef op woensdag 26 januari 2011 @ 16:49:
[...]

Niemand zal de eerste willen zijn die ipv6 only gaat, want het heeft geen voordelen tov een mixed oplossing.

Veel ISPs zullen van elkaars fouten willen leren en derhalve IPv6 niet grootschalig willen uitrollen. De uitrol van IPv6 zal bij de eerste ISPs mogelijk chaotisch verlopen doordat bijv. de impact ervan is onderschat (hoe gaat de apparatuur van de klanten om met IPv6? hoever gaan we met support op klantapparatuur mbt IPv6?).