Het grote IPv6 topic

[DDX]

Osiris schreef op donderdag 17 maart 2011 @ 12:00:
Overigens snap ik niet echt waarom je ULA's zou willen gebruiken. Gewoon je apparaten die niet het interwebz op mogen zoals printers fatsoenlijk firewallen, iets wat sowieso goed moet gebeuren bij IPv6.

Waarvoor ik het hier waarschijnlijk ga gebruiken :
Een (virtuele)webserver die op 2 lokaties kan draaien (een locatie is disaster recovery locatie)
Waarbij de 2e lokatie een andere isp heeft, dus ook een andere ipv6 range.

Webserver zelf zal dus een ULA range moeten hebben, waarbij ik via de router poort 80 doorstuur.

Goed ik kan natuurlijk op de dr locatie ook een ipv6 range van locatie 1 gebruiken, maar ik denk dat ula de meest nette manier is.

[Osiris]

Dan ga je een soort NAT uithalen ofzo?

[DDX]

Dat is wel het idee ja, dat doen we nu met ipv4 wel voor die server.

[Freeaqingme]

Dat is echt de meest non-legitieme reden als 't om ipv6 gaat.

[DDX]

Hoe zou je het dan wel doen met ipv6 ?
Ik wil de virtuele machine nml op locatie 2 zo kunnen opstarten, maar vanuit de buitenwereld heb ik op locatie 2 een compleet andere ipv6 range....

[CyBeR]

Het is compleet onnodig natuurlijk, maar 't zou volgens mij prima kunnen om een rtadvd zowel een globale prefix uit te laten delen als een ULA. Je printers enzo zou je dan wel handmatig in moeten stellen ipv autoconfig te gebruiken.

Maar dit gaat voorbij aan dat 't compleet onzin is. Gewoon fatsoenlijk firewallen.

Aangaande het probleem van DDX: regel dat beide ISP's dezelfde prefix adverteren, en regel onderlinge connectiviteit tussen de twee. Als dat eerste niet kan en een beetje manual failoverwerk is niet geschuwd: regel bij de 2e isp dat ze je prefix adverteren als de 1e down is. Dát is de netste manier.

[ Voor 32% gewijzigd door CyBeR op 17-03-2011 21:18 ]

[Olaf van der Spek]

CyBeR schreef op donderdag 17 maart 2011 @ 21:17:
Maar dit gaat voorbij aan dat 't compleet onzin is. Gewoon fatsoenlijk firewallen.

Wat is fatsoenlijk? De router dichtzetten?

[CyBeR]

Olaf van der Spek schreef op donderdag 17 maart 2011 @ 21:25:
[...]

Wat is fatsoenlijk? De router dichtzetten?

Wat is er zo moeilijk aan?

[Olaf van der Spek]

CyBeR schreef op donderdag 17 maart 2011 @ 21:38:
Wat is er zo moeilijk aan?

Wie zegt dat daar iets moeilijk aan is?

[CyBeR]

Olaf van der Spek schreef op donderdag 17 maart 2011 @ 21:39:
[...]

Wie zegt dat daar iets moeilijk aan is?

Dan stel je dus een domme vraag.

[Olaf van der Spek]

CyBeR schreef op donderdag 17 maart 2011 @ 21:48:
Dan stel je dus een domme vraag.

Waarom? Wat jij fatsoenlijk vindt hoeft een ander toch niet fatsoenlijk te vinden?
Alleen een firewall in de router heeft als nadeel dat de rest kwetsbaar is voor aanvallen vanaf het netwerk zelf op wat voor manier dan ook.

[ Voor 23% gewijzigd door Olaf van der Spek op 17-03-2011 21:50 ]

[CyBeR]

Ja, und? Als jij wilt dat je printer vanaf internet bereikbaar moet zijn, moet je dat zelf weten. Als je dat niet wilt is alles wat daar voor zorgt fatsoenlijk genoeg. Echt…

Alleen een firewall in de router heeft als nadeel dat de rest kwetsbaar is voor aanvallen vanaf het netwerk zelf op wat voor manier dan ook.

Oh, want op 't moment dat ik L2 verbonden ben met m'n target kan ik niet sowieso al alles, ongeacht of ik IPv4, IPv6 met ULA of IPv22 gebruik?

[ Voor 45% gewijzigd door CyBeR op 17-03-2011 21:52 ]

[Olaf van der Spek]

CyBeR schreef op donderdag 17 maart 2011 @ 21:51:
Oh, want op 't moment dat ik L2 verbonden ben met m'n target kan ik niet sowieso al alles, ongeacht of ik IPv4, IPv6 met ULA of IPv22 gebruik?

Dat hangt ervan af welke services toegankelijk zijn via het netwerk.

[CyBeR]

Dit gaat nergens over.

[Hooglander1]

On a completely different note:

Zijn er meer mensen waarbij 6tunnel met een specified source address stuk is gegaan sinds een upgrade naar ubuntu natty?

edit:
Een oude versie installeren lost het probleem bij mij in ieder geval op.

[ Voor 21% gewijzigd door Hooglander1 op 21-03-2011 18:26 ]

[MrDucky]

zijn hier mensen die nogmeer last hebben van een onstabiele teredo??

[Osiris]

Natuurlijk niet, want niemand gebruikt Teredo

[axis]

Even een kickje om het topic in beweging te houden

nieuws: Microsoft betaalt 7,5 miljoen dollar voor voorraad ipv4-adressen

[CAPSLOCK2000]

MrDucky schreef op zondag 20 maart 2011 @ 23:39:
zijn hier mensen die nogmeer last hebben van een onstabiele teredo??

Ja, teredo is niet stabiel.

[Roetzen]

Microsoft betaalt 7,5 miljoen dollar voor voorraad ipv4-adressen

Ze hebben ze kennelijk (nog) niet echt nodig, want wie kan aantonen het nodig te hebben kan nog steeds adressen via de reguliere weg krijgen. Voor niets. Nu hebben ze iets meer dan €8 per IPv4 adres betaald. Niet echt een koopje zou ik zeggen. Puur uit oogpunt van investering is die aankoop wat lastig te begrijpen. Het is maar de vraag of die zich ooit terug betaald. Er komt immers een tijd dat IPv4 uitgefaseerd zal worden en dan zijn die adressen ineens net zo veel waard als 5 inch floppies.

Aan de andere kant, 7,5 M$ is voor µ$oft klein bier. Dus misschien hebben ze ze maar ingepikt onder het motto dan heeft iemand anders ze in elk geval niet. Eerst het bordje van de tegenstander leeg eten zegt Maarten Ducrot altijd als het om strategisch wielrennen gaat...

[ Voor 5% gewijzigd door Roetzen op 26-03-2011 15:20 ]

[Snow_King]

MS bied tegenwoordig ook cloud diensten aan, dat vreet IP's. Daarnaast gaat IPv4 er nog wel eventjes zijn, dus het lijkt me helemaal geen verkeerde zet van ze.

[Roetzen]

Clouddiensten vreten IP's? Hmmm... als jij het zegt...

Als dat klopt, dan bevestigt dat mijn theorie dat ze er eerder op uit zijn de concurrent droog te zetten, dan dat ze zelf droog dreigen te komen te staan. Was dat laatste namelijk het geval, dan zou het voor de hand hebben gelegen eerst nog even gauw wat adressen via de reguliere weg aan te vragen. Dat laatste zal nu niet zo makkelijk meer gaan, want ARIN geeft alleen nog adressen uit als je kunt aantonen ze de komende drie maanden nodig te hebben.

[Snow_King]

Roetzen schreef op zaterdag 26 maart 2011 @ 16:03:
Clouddiensten vreten IP's? Hmmm... als jij het zegt...

In cloud's draaien er honderden, duizenden, miljoenen VM's die allemaal een IP nodig hebben.

Diensten werden 'vroeger' vaak gedeeld door een server, maar draaien nu virtueel en elke VM heeft een IP nodig.

Waar ik vroeger mijn MySQL, Mail en Web op één server had is dat nu nog steeds het geval, maar dan in 3 VM's. Heb ik in totaal dus 4 IP's nodig (de host wil ook een IP).

[eth0]

Snow_King schreef op zaterdag 26 maart 2011 @ 16:26:
[...]
In cloud's draaien er honderden, duizenden, miljoenen VM's die allemaal een IP nodig hebben.

Diensten werden 'vroeger' vaak gedeeld door een server, maar draaien nu virtueel en elke VM heeft een IP nodig.

Waar ik vroeger mijn MySQL, Mail en Web op één server had is dat nu nog steeds het geval, maar dan in 3 VM's. Heb ik in totaal dus 4 IP's nodig (de host wil ook een IP).

En waarom zou je MySQL een publiek ip geven, dit vind ik vaak zo'n onzin? Een private IP voor de koppling Web SQL is prima.

En voor cloud diensten de geloadbalanced worden kan je ook met private ip's prima af. JE hebt maar 1 Pub ip nodig. Er wordt te vaak pub ip's ingezet waar het helemaal niet nodig is.

[CyBeR]

Private IP's zijn (wanneer toegepast in een netwerk dat verbonden is met het internet) een pest die uitgeroeid moet worden.

[Roetzen]

Hoezo? Ik zie geen probleem met het naast elkaar gebruiken van private en public IPv6 adressen in een netwerk. Of bedoel je dat NAT uitrgeroeid moet worden? In dat geval ben ik het met je eens. En als alles IPv6 is, zal dat (hopelijk) ook zo worden. Maar zolang als IPv4 nog niet uitgeroeid is, zal NAT er ook nog zijn vrees ik...

[databeestje]

Je kan prima nat66 gebruiken, op het werk gebruik ik een ULA range voor het lan, deze wordt bij het verlaten van een van onze 3 verbindingen vertaald naar het juiste global prefix van de betreffende lijn.

Werkt prima. Dit is overigens 1:1 nat, dus inkomend verkeer werkt prima met een bijpassende firewall rule.

pfSense ftw.

En nee, met de verbindingen die we hebben is BGP geen optie.

[Roetzen]

Het werkt vast wel. Net zo goed of slecht als NAT44. Dus bijvoorbeeld problemen met ipvsec. Ik begrijp niet waarom je niet gewoon globale adressen gebruikt voor die machines die contact met de buitenwereld moeten maken. En als het om drie verschillende verbindingen gaat, kun je ze toch elk drie globale adressen toewijzen?

[Snow_King]

eth0 schreef op zaterdag 26 maart 2011 @ 16:45:
[...]


En waarom zou je MySQL een publiek ip geven, dit vind ik vaak zo'n onzin? Een private IP voor de koppling Web SQL is prima.

En voor cloud diensten de geloadbalanced worden kan je ook met private ip's prima af. JE hebt maar 1 Pub ip nodig. Er wordt te vaak pub ip's ingezet waar het helemaal niet nodig is.

Het was een voorbeeld waar ik aanhaal dat je tegenwoordig snel meerdere IP's verbruikt voor VM's.

Daarnaast zijn er genoeg scenario's waar MySQL een publiek IP krijgt, bijv wanneer je replication gebruikt.

[databeestje]

Roetzen schreef op zondag 27 maart 2011 @ 00:56:
Het werkt vast wel. Net zo goed of slecht als NAT44. Dus bijvoorbeeld problemen met ipvsec. Ik begrijp niet waarom je niet gewoon globale adressen gebruikt voor die machines die contact met de buitenwereld moeten maken. En als het om drie verschillende verbindingen gaat, kun je ze toch elk drie globale adressen toewijzen?

Ik heb liever dat de enkele firewall bepaalt welke verbinding het uitgaande verkeer uitgaat in het geval dat 1 of meer van de verbindingen het niet doet. Daarnaast is het op deze manier zo dat al het verkeer via 1 firewall het netwerk in en uitgaat.

Dit is geen nat met poort vertaling, dit is rechtstreeks adres vertaling. Alles is nog steeds 1 op 1 vanaf het internet adreseerbaar.

Het IPsec argument is wel grappig, omdat dat een drama kan worden met het troubleshooten van firewalls en routing. Je kan dan hetzelfde publieke netblock via IPsec benaderen of via het globale adres. Ik zie een ongeluk in de maak.

Met de ULA ranges weet je in ieder geval dat je niet naar een globale prefix verbindt. Dat is voor site-site tunnels toch wel prettig.

Voor je het weet vinden mensen IPsec niet meer nodig omdat alles globaal te bereiken is. Wat niet weg neemt dat je sommige (bedrijfs) communicatie niet onversleuteld over het internet wil laten lopen. Vaak ook omdat de applicaties zich er niet altijd voor lenen. Niet alles is een website of een mailserver.

[Roetzen]

Eh.. volgens mij haal je IPsec en VPN door elkaar....

[databeestje]

Roetzen schreef op zondag 27 maart 2011 @ 11:48:
Eh.. volgens mij haal je IPsec en VPN door elkaar....

Toegegeven, het een en het ander zijn niet onlosmakelijk met elkaar verbonden, maar dat wil nog niet zeggen dat het niet veel tegelijkertijd van toepassing is.

Het hele nat uitroeien lijkt op een religieuze oorlog. Ik zie het wat grijzer, hier en daar is er best wel nut voor. De perfecte netwerken zonder rare conflicten bestaan niet, soms moet je door hoepels springen, anders wordt er soms geen geld verdient.

Je wil connectie failover niet door alle systemen onderling laten uitvechten als de upstream router uitstekend in staat is het de juiste verbinding uit te sturen.

De crux is dat voor veel ISP global prefixes deze onlosmakelijk met de verbinding verbonden zijn, en tenzij je echt de resources hebt je ook internet verbindingen met BGP kan krijgen.

Alle apparaten zelfstandig dit uit laten zoeken lijkt me beheers technisch een slecht idee. Outages komen voor, ook bij glas. Afgelopen week nog een half uur geen internet omdat een graaf machientje de straat verderop de stroom kabel van de PoP had geraakt.

Veel software en hardware is ook nog niet in staat met meerdere prefixes om te gaan, zeker simultaan. En wachten tot ze het wel kunnen is een beetje kip en ei.

Laten we voort maken. Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

[Osiris]

Als je dan tóch die failovers wil hebben, dan NAT je toch gewoon vanaf je standaard publieke prefix naar een back-up-prefix? Alsnog geen reden om private IP's te gebruiken.

[bdegroot]

databeestje schreef op zondag 27 maart 2011 @ 17:22:
[...]
Laten we voort maken. Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

Ik kan je helpen met Sixxs credits! Ik heb er genoeg.
Het zou heel mooi zijn als Sixxs ondersteuning in PfSense komt!

PM maar indien ik je kan helpen.

[databeestje]

@bdegroot, PM verstuurd, helemaal het bos in geweest om het PM knopje in mijn profiel te vinden.

[Osiris]

Je kunt geen SixXS-credits naar elkaar overschrijven naar mijn weten.

[ Voor 9% gewijzigd door Osiris op 27-03-2011 19:47 ]

[Roetzen]

databeestje schreef op zondag 27 maart 2011 @ 17:22:
Het hele nat uitroeien lijkt op een religieuze oorlog.

Nah, geloof is iets als vaststaand feit ervaren zonder enig bewijs. Geloof is wat mij betreft niet aan de orde bij de wens van NAT af te komen. NAT is een kludge. Nodig bij IPv4 om het gebrek aan adressen te omzeilen. Het werkt, meestal, maar wel met veel kunst en vliegwerk. Voor IPv6 is het niet nodig omdat er geen gebrek aan adressen is. Je kunt weer terug naar volledige end to end connectivity zoals het internet oorspronkelijk bedoeld was en daarmee vermijd je een boel problemen. Bij IPv6 is NAT een onnodige complicatie. Als techneut en wetenschapper zie ik die liever verdwijnen.

soms moet je door hoepels springen, anders wordt er soms geen geld verdient.

Als je commercieel bezig bent, zou je juist de zaak simpel willen houden. Onnodige kludges leiden alleen maar tot meer problemen en problemen oplossen kost geld.

Outages komen voor, ook bij glas. Afgelopen week nog een half uur geen internet omdat een graaf machientje de straat verderop de stroom kabel van de PoP had geraakt.

Als je commercieel bezig bent wil je natuurlijk graag dat half uur overbruggen. Maar wat ik dan niet begrijp is...

Nu bezig om Sixxs ondersteuning in pfSense te proggen. Tunnels met statisch IP bleken al gewoon te werken met wat er is. Dynamische tunnels kan nog niet, en ik kom er net achter dat ze een kredit systeem hebben wat niet echt helpt om snel een paar dingen in de lucht te gooien.

... waarom je dan met SIxXs in zee gaat. SixXs is draait opvrijwilligers. Ik ben blij met ze, maar ik ben met VUT en voor mij is het aleen nog maar hobby. Ik kan leven met vrijwilligers die geen 24/7 ondersteuning bieden. Ik raak geen klanten kwijt als de zaak een dag plat ligt. Als ik nog commercieel bezig was, dan zou ik het ook professioneel aanpakken en BGP regelen. Sja, dat kost dan iets meer, maar qualiteit kan niet gratis zijn.

Osiris schreef:
Je kunt geen SixXS-credits naar elkaar overschrijven naar mijn weten.

Inderdaad dat kan niet.

Dat puntensysteem heeft mij overigens ook wat afstand doen nemen van SixXs. Aan de ene kant kan ik het wel begrijpen dat ze ondoordachte acties wat willen afremmen, aan de ander kant snap ik niet waarom het 50 punten moet kosten om een subnet terug te geven wat ik bij nader inzien niet meer nodig heb. Sja, dus houd ik het maar...

[databeestje]

Roetzen schreef op maandag 28 maart 2011 @ 13:39:

... waarom je dan met SIxXs in zee gaat. SixXs is draait opvrijwilligers. Ik ben blij met ze, maar ik ben met VUT en voor mij is het aleen nog maar hobby. Ik kan leven met vrijwilligers die geen 24/7 ondersteuning bieden. Ik raak geen klanten kwijt als de zaak een dag plat ligt. Als ik nog commercieel bezig was, dan zou ik het ook professioneel aanpakken en BGP regelen. Sja, dat kost dan iets meer, maar qualiteit kan niet gratis zijn.

Sorry voor de verwarring, 2 losse onderwerpen. Op de zaak hebben we 1 native ipv6 verbinding vna Unet, dus dat valt wel mee. Unet is ook we bereid om BGP aan te gooien. Probleem is dat ik dan nog steeds met 2 kpn glas verbindingen zit waar het niet mee kan.

Die ondersteuning voor Sixxs heeft niets specifiek te maken met het NAT verhaal. Het is meer dat er een schare pfSense gebruikers is die het toch wil gebruiken. Het zal toch een keer gemaakt moeten worden.
Programmeren gebeurt meestal om persoonlijke behoeftes, dit is er niet een van.

Er zijn nu een aantal providers waarbij je als alternatief een tunnel broker van de provider krijgt voor het termineren van de IPv6. Dat is gelukkig een goede oplossing voor migratie tot alles in het pad het fatsoenlijk ondersteund.

Ik ben een enorme tijd kwijt geweest samen met Unet om IPv6 fatsoenlijk afgeleverd te krijgen op locatie. Het BBned netwerk hielp niet echt mee. Gelukkig is het dankzij de inzet van Unet toch gelukt. Hulde.

[Roetzen]

databeestje schreef op maandag 28 maart 2011 @ 14:16:
Sorry voor de verwarring, 2 losse onderwerpen.

Sorry voor het verkeerd begrijpen.

Op de zaak hebben we 1 native ipv6 verbinding vna Unet, dus dat valt wel mee. Unet is ook we bereid om BGP aan te gooien.

Nou, dan heb je het al voor 33% voor elkaar..

Probleem is dat ik dan nog steeds met 2 kpn glas verbindingen zit waar het niet mee kan.

Je loopt in elk geval lekker voorop. Er zijn zat bedrijven die nog helemaal niet met IPv6 bezig zijn. Jij bent al met multi homing bezig...

Die ondersteuning voor Sixxs heeft niets specifiek te maken met het NAT verhaal. Het is meer dat er een schare pfSense gebruikers is die het toch wil gebruiken. Het zal toch een keer gemaakt moeten worden.
Programmeren gebeurt meestal om persoonlijke behoeftes, dit is er niet een van.

Ah, je bent voor de goede zaak bezig.

Er zijn nu een aantal providers waarbij je als alternatief een tunnel broker van de provider krijgt voor het termineren van de IPv6. Dat is gelukkig een goede oplossing voor migratie tot alles in het pad het fatsoenlijk ondersteund.

Dat een aantal providers zelf tunnels gaat aanbieden is natuurlijk mooi, maar er zijn er nog te veel die achter blijven en over het geheel gaat de introductie van IPv6 veel te traag naar mijn smaak. De goeden niet te na gesproken natuurlijk..

Ik ben een enorme tijd kwijt geweest samen met Unet om IPv6 fatsoenlijk afgeleverd te krijgen op locatie. Het BBned netwerk hielp niet echt mee. Gelukkig is het dankzij de inzet van Unet toch gelukt. Hulde.

Waarvan akte!

[Keiichi]

Onder FreeBSD gebruik ik vrij dichte firewall. Alles staat dicht, tenzij ik zeg dat het openstaat

Maar ik krijg het niet voor elkaar om op een goede manier een tunnel door te laten.

De enige manier is 'ipfw allow 41 from any to any' wanneer ik eigenlijk alleen mijn ipv4 en het ipv4 adres van de tunnelbroker wil opgeven. Maar protocol 41 is ipv6, dus ik kan schijnbaar niets met ipv4 adressen doen, behalve de hele bende openzetten

[Osiris]

Hm, da's bij iptables toch iets anders. Daarbij heb je IPv4 en IPv6 strikt los van elkaar d.m.v. `iptables` voor IPv4 en `ip6tables` voor IPv6. En als jij dus dingetjes in `iptables` aan het kloppen bent met als payload protocol 41, dan ben je an sich gewoon bezig met rules aan het opstellen voor de onderliggende IPv4-packets. En kun je dus prachtig filteren op je tunnelbrokers IPv4-adres.

[databeestje]

Keiichi schreef op dinsdag 29 maart 2011 @ 12:20:
Onder FreeBSD gebruik ik vrij dichte firewall. Alles staat dicht, tenzij ik zeg dat het openstaat

Maar ik krijg het niet voor elkaar om op een goede manier een tunnel door te laten.

De enige manier is 'ipfw allow 41 from any to any' wanneer ik eigenlijk alleen mijn ipv4 en het ipv4 adres van de tunnelbroker wil opgeven. Maar protocol 41 is ipv6, dus ik kan schijnbaar niets met ipv4 adressen doen, behalve de hele bende openzetten

met pf zou een allow protocol any inet from <tunnelbroker remote> to <local endpoint>
genoeg moeten zijn om de payload afgeleverd te krijgen. Begrijp ik hieruit dat je probeert om een tunnel achter de firewall te termineren?

[Roetzen]

IPv6 toch niet nodig?

The global migration to IPv6 has been slow coming. Even as the last few remaining chunks of IPv4 address space are being allocated, many organizations around the world are just now beginning to look at IPv6. And what they’re finding often isn’t pretty: mediocre application support, security issues, and really long addresses that are hard to rattle off. It has been estimated that a significant move toward IPv6 won’t be seen for at least five years, and IPv6 won’t be on par with its predecessor for at least another ten.

This got some people within the IETF thinking about an alternative to the new protocol. Realizing that the primary goal of IPv6 was to provide an increased address space, they began to reconsider whether an entirely new protocol was really necessary in the first place.Still in its infancy, work is underway on a new IETF draft which ditches IPv6 altogether in favor of a simple extension to its predecessor: IPv4.1.

Lees meer: http://packetlife.net/blo...1/alternative-ipv6-works/

[Jaap-Jan]

April Fools' enzo.

De eerste reactie is al gelijk een hint naar IPoAC (IP over Avian Carriers, oftewel: IP per postduif): http://www.faqs.org/rfcs/rfc2549.html.

[ Voor 101% gewijzigd door Jaap-Jan op 01-04-2011 13:51 ]

[Roetzen]

he.net tunnel na paar minuten dicht

Het is al weer een paar weken terug dat ik dat probleem aankaartte. Mijn he.net tunnel die draait op een Linksys WRT54GL met OpenWrt ging na een paar minuten spontaan dicht. Met een ping naar buiten ging ie weer open. De suggestie was het op te lossen met een cron job die elke minuut even iets pingt. Ik heb nu de "nette" oplossing gevonden. In de firewall rules opnemen:

config rule
        option src      wan
        option proto    41
        option target   ACCEPT

De tunnel blijft nu open.

[Zsub]

Roetzen schreef op zondag 03 april 2011 @ 00:47:
he.net tunnel na paar minuten dicht

Het is al weer een paar weken terug dat ik dat probleem aankaartte. Mijn he.net tunnel die draait opeem Linksys WRT54GL met OpenWrt ging na een paar minuten spontaan dicht. Met eenping naar buiten ging ie weer open. De suggestie was het op te lossen met een cron job die elke minuut even iets pingt. Ik heb nu de "nette" oplossing gevonden. In de firewall rules opnemen:

config rule
        option src      wan
        option proto    41
        option target   ACCEPT

De tunnel blijft nu open.

Huh. Niet verwacht dat het daaraan zou liggen. Maar wel mooi dat er nu een oplossing is

[Roetzen]

Zsub schreef op maandag 04 april 2011 @ 10:35:
[...]

Huh. Niet verwacht dat het daaraan zou liggen. Maar wel mooi dat er nu een oplossing is

Achteraf is het wel te verklaren. Mjn theorie is deze: Het tunnel eindpunt ligt achter de IPv4 firewall en vóór de IPv6 firewall.

                       |
                       |                       Proto41 packet
                      \_/ 
[red]=============================================  IPv4 firewall[/red]
                       O                       Tunnel eindpunt
[green]=============================================  IPv6 firewall
[/green]

De IPv4 firewall staat default dicht. Een pakketje bestemd voor de tunnel is een IPv4 pakketje met als inhoud een protocol 41 payload. Dus als dat pakketje ongenood is, stoot het zijn neus op de IPv4 firewall. Om het toch door te laten moet die dus expliciet voor pakketjes met als inhoud proto 41 worden open gezet. Dan alleen kunnen ze het tunneleindpunt bereiken.

                       |
                       |                       Proto41 packet
                       |  
[red]=======================[/red]|[red]=====================  IPv4 firewall[/red]
                       O                       Tunnel eindpunt
                       |                       IPv6 ping packet
                      \_/
[green]=============================================  IPv6 firewall
[/green]

En vervolgens moet de IPv6 firewall dan ook nog open staan voor het PING pakketje zoals dat door het tunneleindpunt uit het IPv4 proto41 pakketje is uitgepakt.

                       |
                       |                       Proto41 packet
                       |  
[red]=======================[/red]|[red]=====================  IPv4 firewall[/red]
                       O                       Tunnel eindpunt
                       |                       IPv6 ping packet
[green]=======================[/green]|[green]=====================  IPv6 firewall[/green]
                       |
                       |
                      PING

(Heel gedoe zo'n plaatje maken, met krijt en schoolbord gaat het makkelijker.)

[ Voor 3% gewijzigd door Roetzen op 05-04-2011 11:24 ]

[Zsub]

Haha! Krijt en schoolbord, dat was wel echt de bom trouwens. Als je visueel moest denken werkte er niets zo goed als een leeg lokaal met een schoolbord, inderdaad

Maar zo zie ik het inderdaad ook voor me. Ik maakte altijd wel netjes een FW rule ervoor, dacht dat dat standaard was ofzo, maar blijkbaar was dat de oplossing

[Roetzen]

Je zou het nog iets kunnen verfijnen door alleen proto 41 pakketjes te accepteren die van het tunnel startpunt komen.

config rule
        option src      wan
        option proto    41
        option src_ip   xxx.xxx.xxx.xxx   # Hier IP4 van tunnel startpunt
        option target   ACCEPT

Dat geeft dan ook nog de mogelijkheid om proto 41 pakketjes van een andere tunnel ergens anders heen te sturen.

[Zsub]

Roetzen schreef op dinsdag 05 april 2011 @ 11:50:
Je zou het nog iets kunnen verfijnen door alleen proto 41 pakketjes te accepteren die van het tunnel startpunt komen.

config rule
        option src      wan
        option proto    41
        option src_ip   xxx.xxx.xxx.xxx   # Hier IP4 van tunnel startpunt
        option target   ACCEPT

Dat geeft dan ook nog de mogelijkheid om proto 41 pakketjes van een andere tunnel ergens anders heen te sturen.

Dat zou ik eens moeten testen, dat zou behoorlijk fantastisch zijn

[Roetzen]

Het biedt wel interessante mogelijkheden, maar ik zie voor mezelf niet direct een toepassing. De ironie is dat ik aan dit project begonnen ben omdat ik met een AYIYA tunnel van SIxXs niet uit de voeten kon, omdat die in combinatie met Windows geen subnet kan routen. Zou ik een router gehad hebben die protocol 41 kan doorsturen, dan had ik de SixXs tunnel een statische kunnen maken en had ik Windows wel een subnet kunnen laten routeren en had ik geen IPv6 router nodig gehad. En nu hèb ik dus een router die proto 41 kan redirecten, zo blijkt...

Maar de oplossing die ik nu heb waarbij de router allles voor zijn rekening neemt is natuurliijk veel eleganter.

[AmonTobin]

Ik ben zelf nu pas een beetje in IPv6 aan het verdiepen en dan op het moment specifiek 6to4 tunneling. Begrijp ik het goed als ik het volgende scenario voorleg?

• Router van eindgebruiker heeft ipv6 adres: 2002:c000:022a:1::1/64
• Router van eindgebruiker bouwt ipv4 tunnel op met externe 6to4 relay server (bijv: Hurricane Electric)

Vervolgens:

1. Client PC met ipv6 adres 2002:c000:022a:1::2/64 stuurt ipv6 pakketje naar router (gateway) van de gebruiker.
2. Router detecteert routable ipv6 adres, extract het public ipv4 adres uit het ipv6 adres van de client en stelt dit in als source adres en stelt het public ipv4 adres van de externe 6to4 relay server als destination. In de payload van het ipv4 pakketje komen de originele ipv6 destination en source adressen te staan.
3. Het ipv4 pakketje wordt "over de tunnel" naar de externe 6to4 relay server verzonden.
4. De externe 6to4 relay server stript de ipv4 headers
5. De externe 6to4 relay server stuurt het pakketje door naar het ipv6 destination adres a.d.h.v. de ipv6 adressen die hij uit de ipv4 payload kan herleiden.
6. De reply pakketjes worden door de 6to4 relay server weer encapsulated door ipv4 headers waarbij de source ditmaal het public ipv4 adres van de externe 6to4 relay server is en de destination het public ipv4 adres van de eindgebruiker.
7. Het ipv4 pakketje wordt "over de tunnel" naar de router van de eindgebruiker verzonden.
8. De router van de gebruiker stript de ipv4 headers
9. De router stuurt pakketje door naar de client PC a.d.h.v. de ipv6 adressen die de router uit de ipv4 payload heeft.

Klopt dit een beetje?

Edit: Hmmn, volgens mij zit ik wat zaken door elkaar te halen. 6to4 is schijnbaar wat anders dan wat zo'n ipv6 tunnel broker als Hurricane Electrics aanbiedt. Ik ga even verder zoeken.

[ Voor 10% gewijzigd door AmonTobin op 09-04-2011 00:06 ]

[Yintha]

Hoe komt een Windows 7 client aan zijn router adres?

Ik heb virtueel in vmware workstation een W2k8 Ras server gezet, met wireshark kan ik zijn router advertisement berichten zien.

echter van de windows 7 client zie ik geen router solicits. ik heb al met netsh gekeken of ik iets vreemds zag in de settings maar kon niks vinden.

Kan niet veel settings posten want kan de machines momenteel niet bereiken : (

[databeestje]

AmonTobin schreef op vrijdag 08 april 2011 @ 23:16:

Edit: Hmmn, volgens mij zit ik wat zaken door elkaar te halen. 6to4 is schijnbaar wat anders dan wat zo'n ipv6 tunnel broker als Hurricane Electrics aanbiedt. Ik ga even verder zoeken.

Wat hurricane electric en Sixxs onder andere doen is 6in4. Dat is dus een Tunnel over IPv4 waar je het v6 verkeer in vervoert. Dit gebeurt eigenlijk altijd met een "tunnelbroker" waarschijnlijk een mooie router met een gigabit poortje. Geen encryptie oid dus redelijk snel allemaal.

Ik geloof dat 6to4 iets anders is.... snor snor ... aha, het is echt iets anders, het gebruikt anycasting waardoor je op de eerste de beste 6to4 relay het ipv6 internet op gaat. Je lokale PC heeft dan al IPv6 aanstaan, de meeste routers adverteren dit overigens niet. Het zou wel kunnen.

Ik zal eens zien of dat in pfSense kan. Op die manier kan je zonder tunnel broker ook op het ipv6 internet komen.

Betrouwbaarheid van het geheel is overigens wel sterk afhankelijk van de Publieke 6to4 relays. Gelukkig hebben we in Nederland een Surfnet relay dichtbij.

[Whizzer]

Vorige week (5 april) was er bij Surfnet een Surfacademy waarin in de ochtend veel over IPv6 te doen was. Iemand daar geweest toevallig?

[AmonTobin]

databeestje schreef op maandag 11 april 2011 @ 22:14:
[...]


Wat hurricane electric en Sixxs onder andere doen is 6in4........Gelukkig hebben we in Nederland een Surfnet relay dichtbij.

Bedankt voor het meedenken. Heb het een beetje druk gehad de afgelopen dagen, maar ik heb me er vandaag nog even wat verder op ingelezen en volgens mij zit het ongeveer zo:

6to4:

• 6to4 router van <site_A> heeft ipv4 adres: 128.131.88.64
• 6to4 router van <site_A> heeft, d.m.v. 6to4 ipv6 prefix: 2002:8083:5840::/48
• 6to4 router van <site_A> heeft ipv6 adres: 2002:8083:5840:1:1/64
• <PC_1> op <site_A> heeft ipv6 adres: 2002:8083:5840:1:2/64

<PC_1> op <site_A> stuurt pakket naar <PC_2> op <site_B>

1. <PC_1> op <site_A> (2002:8083:5840:1:2/64) stuurt ipv6 pakketje naar router (2002:8083:5840:1:1/64)
2. 6to4 router van <site_A> detecteert ipv6 adres en roept 6to4 mechanisme aan
3. 6to4 router encapsuleert het ipv6 pakketje met de ipv4 addressen die hij uit de ipv6 header (source en destination adressen) kan herleiden.
4. Het ipv4 pakketje wordt over de "ipv4 tunnel" naar de externe 6to4 router van <site_B> gestuurd.
5. De 6to4 router van <site_B> decapsuleert het ipv4 pakketje en heeft dus de originele ipv6 header
6. De 6to4 router van <site_B> forward het ipv6 pakketje naar de <PC_2> op <site_B>

In het geval het gewenst is om ook naar native ipv6 netwerken te connecten, kan er gebruik gemaakt worden van een relay router:

1. Client PC op <site_A> (2002:8083:5840:1:2/64) stuurt ipv6 pakketje naar router (2002:8083:5840:1:1/64)
2. 6to4 router van <site_A> detecteert ipv6 adres en roept 6to4 mechanisme aan
3. 6to4 router encapsuleert het ipv6 pakketje met de ipv4 addressen die hij uit de ipv6 header (source en destination adressen) kan herleiden, maar zet als destination ipv4 adres het adres van de relay router die op de router is ingesteld.
4. Het ipv4 pakket wordt over de "ipv4 tunnel" naar de relay router gestuurd.
5. De relay router forward het pakketje naar de native of 6to4 site.

Nu weet ik alleen niet precies hoe de het verkeer terugkomt waneer het via de relay router doorgestuurd wordt naar een native ipv6 site. Het lijkt me dat de relay router zijn ipv6 adres als source instelt wanner hij het pakketje naar de native ipv6 site stuurt en vervolgens het retourverkeer weer, over de "ipv4 tunnel", terugstuurt naar <site_A>.

6in4 werkt zover ik begrijp hetzelfde als 6to4, echter worden dan de source en destination adressen statisch ingesteld, i.p.v. dat ze uit de ipv6 prefix herleid worden.

[Roetzen]

Het raakt nu echt op...

Ieder APNIC lid kan nog maximaal één /22 (1024 IPv4 adressen) krijgen en dat is het dan.

APNIC has announced that they are running out of IPv4 addresses. They have less than 1 x /8 left. This trigger a very strict delegation policy and IPv4 addresses will not be available the conventional way any longer in the region.

Meer... http://www.ipv4depletion.com/?p=595

[Staatslot]

geen idee of ik hier goed zit, ik doe een poging:

Ik heb de beschikking over een aantal servers met native ipv6 en ipv4, OS is Ubuntu 10.04 x64.
Thuis heb ik alleen IPv4..

Onder Ubuntu kan ik met pptpd een vpn opzetten, die ervoor zorgt dat ik een lokaal ip-adres krijg toegewezen (bv 192.168.1.40). Ik heb in de firewall de volgende regel toegevoegd:

code:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Het internet verkeer wordt dus echt gerouteerd en ik surf thuis via mijn Ubuntu server via de VPN.

Nu wilde ik een private IPv6 tunnel maken, zonder afhankelijk te zijn van een derde partij.
Ik stel me zo voor een zelfde VPN op te zetten, maar dan één die ipv6 uitdeelt.
Helaas gaat het daar mis... Op mijn pc krijg ik na het verbinden geen ipv6 toegekend.

Ik heb gezocht op tal van pagina's, en o.a. net.ipv6.conf.all.forwarding=1 aangezet in /etc/sysctl.conf, maar tot nu toe weinig succes.

Om een lang verhaal kort te maken, hoe kan ik mijn Ubuntu server zo instellen dat ik mijn werkplek thuis kan connecten om zo via mijn server gebruik te kunnen maken van IPv6. Is een VPN de oplossing, of moet ik iets anders doen om dit voor elkaar te krijgen? Bedankt!

p.s. thuis gebruik ik op mijn werkplek overigens Windows7

edit: ik heb net een ssh tunnel gemaakt, dat werkt in firefox dus daarmee kan ik nu ipv6 websites bezoeken via mijn Ubuntu server. Opzich gaaf, maar ik wil eigenlijk alles over IPv6, zodat ik ook kan pingen en andere applicaties via IPv6 kan connecten. Hoop dat jullie me een zetje kunnen geven in de goede richting...

[ Voor 13% gewijzigd door Staatslot op 16-04-2011 15:14 . Reden: ssh tunnel toegevoegd ]

[Osiris]

Is encryptie van belang (VPN) of mag 't ook gewoon unencrypted? Want met dezelfde simpele iproute2-commando's waarmee men normaliter een 6in4-tunnel opzet op de workstation, kun je ook prima een "4to6-tunnel" op een server maken (door de tunnelargumenten als 't ware gewoon om te draaien), waardoor je effectief een soort tunnelbroker voor jezelf wordt.. Vervolgens natuurlijk op je client simpelweg een tunneltje opbouwen naar je servert en uiteraard op je server IPv4-protocol 41 (= IPv6, dus 6in4) goed firewallen voor iedereen behalve jezelf

[Staatslot]

Osiris schreef op zaterdag 16 april 2011 @ 17:32:
Is encryptie van belang (VPN) of mag 't ook gewoon unencrypted? Want met dezelfde simpele iproute2-commando's waarmee men normaliter een 6in4-tunnel opzet op de workstation, kun je ook prima een "4to6-tunnel" op een server maken (door de tunnelargumenten als 't ware gewoon om te draaien), waardoor je effectief een soort tunnelbroker voor jezelf wordt.. Vervolgens natuurlijk op je client simpelweg een tunneltje opbouwen naar je servert en uiteraard op je server IPv4-protocol 41 (= IPv6, dus 6in4) goed firewallen voor iedereen behalve jezelf

Als het kan dan is encrypted natuurlijk mooier, vpn werkt prima voor mij, alleen het ipv6 gedeelte nog niet.
Enig idee hoe ik dat echt kan realiseren, ik gebruikte nu pptpd maar dat schijnt niet altijd even goed te werken met ipv6 begrijp ik? Anders is een andere vpn, openvpn?, ook prima zolang ik maar ergens te weten kom hoe ik het werkend kan krijgen..

Kortom, alle hulp is meer dan welkom want ik krijg er grijze haren van

offtopic:
en daar voel ik me toch echt nog te jong voor haha

[Osiris]

Sorry, VPN + IPv6 heb ik zelf ook nog geen ervaring mee verder.

[CertLog]

@Staatslot
Geen idee of Ubuntu dat ondersteund, maar ik heb het zelf opgelost door mijn Windows 2003 server te configureren als ISATAP router.
Een client (Windows) maakt met ipv4 een VPN verbinding met de server (PPTP of L2TP/IPSec) en vervolgens krijgt de ISATAP interface van de client een ipv6 address toegewezen.
(Zeker als je het voor elkaar krijgt om "isatap" via DNS te laten resolven naar je ISATAP router, dan hoef je eigenlijk niks te configureren op je clients)
Werkt best goed.

[databeestje]

Osiris schreef op zondag 17 april 2011 @ 00:11:
Sorry, VPN + IPv6 heb ik zelf ook nog geen ervaring mee verder.

in de huidige pfSense 2.0 IPv6 code heb ik al wel support gemaakt voor IPv6 in combinatie met IPsec. Dus een v6 tunnel via v4 eindpunten, of een v4 tunnel over v6 eindpunten. Het is kennelijk de enige VPN oplossing die wel een beetje op de toekomst was voorbereid. (ipsec-tools uit het BSD kamp).

OpenVPN heb ik naar gekeken maar daar moet ik een compleet gepatchte Openvpn install van maken. Deze ondersteunt wel IPv6 voor het transport maar niet door de eigenlijke VPN verbinding zelf. Heeft in ieder geval veel meer voeten in de aarde dan de IPsec tools.

Ik durf dan ook niet te zeggen of het ombouwen van de server component genoeg is om de clients een IPv6 adres toe te wijzen.

PPtP raak ik niet aan. Niet mijn ding.

[dupondje]

De default OpenVPN in Debian Squeeze heeft bv wel de IPv6 patch. Waarmee je dus een IPv4 tunnel kan opzetten over 2 IPv6 endpoints

[DDX]

Ik ben inmiddels weer iets verder met ipv6 configuratie binnen ons netwerk.
Had eerst wat issues om ospf3 werkend te krijgen.

Nu nog leuke issue dat de junipers die we hier hebben (ex4200) nog geen ipv6 accesslist support met de software release die we draaien.
Er zijn wel software releases die het supporten, maar als we die installeren hebben we weer last van een bug die in deze oude software wel werkt.... (leuk die verschillende versies met steeds weer een andere issue/bug)

Daarnaast ook weer last dat level3 niet alle ipv6 netwerken kan bereiken, ook maar weer eens een case voor geopend.

Misschien dat er wat mensen kunnen testen of ze het netwerk hier kunnen bereiken ?
2001:4c08:2001:10::2 (ping / http)

[sPENKMAN]

Die loop bij mij dood na mijn eigen radvd server > gateway van de ipv6 tunnel

code:

 3  gige-g2-20.core1.ams1.he.net (2001:470:0:7d::1)  11.75 ms  4.671 ms  3.929 ms

[jep]

DDX schreef op vrijdag 22 april 2011 @ 15:49:
Misschien dat er wat mensen kunnen testen of ze het netwerk hier kunnen bereiken ?
2001:4c08:2001:10::2 (ping / http)

Yep, dat werkt goed.

code:

root@web01:~# traceroute6 2001:4c08:2001:10::2
traceroute to 2001:4c08:2001:10::2 (2001:4c08:2001:10::2), 30 hops max, 80 byte packets
 1  exonet-gw.jun1.bit-2a.network.bit.nl (2001:7b8:621::3)  0.431 ms  0.392 ms  0.384 ms
 2  700.xe-0-0-0.jun1.bit-1.network.bit.nl (2001:7b8:0:2bc::1)  0.314 ms  0.308 ms  0.309 ms
 3  ge-1-11.r01.amstnl02.nl.bb.gin.ntt.net (2001:728:1800:5000::1)  2.145 ms  2.222 ms  2.233 ms
 4  ae-0.r22.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::5)  1.448 ms  1.578 ms  1.487 ms
 5  GigabitEthernet6-17.car2.ams1.level3.net (2001:7f8:1::a500:3356:1)  2.280 ms  2.312 ms  2.095 ms
 6  vl-4084.edge3.Amsterdam1.Level3.net (2001:1900:5:1::226)  15.086 ms  15.207 ms  15.078 ms
 7  router-l3-1.thepeoplesvalley.net (2001:1900:5:2:2::d2)  15.724 ms  15.791 ms  15.866 ms
 8  2001:4c08:2001::1 (2001:4c08:2001::1)  16.246 ms  15.724 ms  15.658 ms
 9  2001:4c08:2001:10::2 (2001:4c08:2001:10::2)  16.014 ms

code:

root@web01:~# telnet -6 '2001:4c08:2001:10::2' 80
Trying 2001:4c08:2001:10::2...
Connected to 2001:4c08:2001:10::2.
Escape character is '^]'.
get /
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Verb</h2>
<hr><p>HTTP Error 400. The request verb is invalid.</p>
</BODY></HTML>
Connection closed by foreign host.
root@web01:~#

[DDX]

sPENKMAN schreef op vrijdag 22 april 2011 @ 15:59:
Die loop bij mij dood na mijn eigen radvd server > gateway van de ipv6 tunnel

code:

 3  gige-g2-20.core1.ams1.he.net (2001:470:0:7d::1)  11.75 ms  4.671 ms  3.929 ms

level3 kent ook weer geen routering naar dat netwerk :

~]# traceroute6 2001:470:0:7d::1
traceroute to 2001:470:0:7d::1 (2001:470:0:7d::1), 30 hops max, 40 byte packets
1 ge-5-0-2.edge3.Amsterdam1.Level3.net (2001:1900:5:2:2::d1) 0.274 ms !N 0.277 ms !N 0.297 ms !N

Had ze aantal maanden heb ik ze ook al eens gevraagd waarom ik google niet via ipv6 kon bereiken :
DDX in "Het grote IPv6 topic"

Benieuwd wat ze nu als antwoord geven.

[DDX]

Weer zo'n mooi antwoord waar je niets mee kan :

We are not getting any routes from Hurricane Electric and they are not a peer. This is a policy decision.

Rest assured that Level 3 network is fully enabled for native IPv6 Connectivity. The global IPv6 routing table environment is still evolving and Level 3 continues to work on filling out its IPv6 connectivity in the most efficient and most cost effective way for our customers."

[Skinkie]

Oh dit wordt interessant. Dit zou mogelijk kunnen verklaren waarom Vircon ook zulke rare problemen heeft.

[zx9r_mario]

Wanneer gaat tweakers eigenlijk over op ipv6?

[Osxy]

zx9r_mario schreef op zaterdag 23 april 2011 @ 22:38:
Wanneer gaat tweakers eigenlijk over op ipv6?

IRC draait al op Ipv6.

Webservers wachten op een IPV6 compatible load balancer volgens mij.

[zx9r_mario]

Osxy schreef op zondag 24 april 2011 @ 16:08:
[...]

IRC draait al op Ipv6.

Webservers wachten op een IPV6 compatible load balancer volgens mij.

Blijkbaar wacht iedereen wel op elkaar totdat ze ipv6 gereed zijn. Zo kan het nog lang duren en dit speelt al 10 jaar.

[DDX]

Tja wij hebben ook loadbalancers staan die niet echt ipv6 support (op papier kan het maar je wilt het niet)
Je kan ze natuurlijk direct vervangen, maar als ze nog niet echt afgeschreven zijn....

En dan een provider die ook niet echt meerwerkt kwa support schiet ook niet op.

[zx9r_mario]

Mijn provider Online biedt ook geen ipv6 aan, nu heb ik m0n0wall met een HE tunnel.

Nog een voorbeeld, Zyxel heeft ook geen ipv6 apparatuur. Hun firewall serie, de USG reeks biedt geen ondersteuning voor ipv6.

[databeestje]

De situatie met de peering is een beetje naar. Cogent en HE willen bijvoorbeeld ook niet peeren. De reden die Cogent (ook Level3?) aandraagt is dat het een kleine (IPv4) speler is en dus moet betalen.

De situatie met IPv6 is daarentegen weer andersom, daar is HE een van de grootsten met het aantal IPv6 prefixes.

Hurricane Electric heeft al eens een heuze taart opgestuurd naar Cogent, hij zal vast wel opgegeten zijn, maar aan de peering veranderde niets.

Afgelopen weekeinde heb ik de OpenVPN met IPv6 payload patches ook in pfSense geimporteerd. Config maken lukt ook al maar ik krijg er nog geen verkeer overheen. Ik zal nog wel wat rules in de achtergrond moeten maken denk ik.

Traceroute is wild. Helemaal de Oceaan over en weer terug. Top!

code:

$ traceroute 2001:4c08:2001:10::2
traceroute to 2001:4c08:2001:10::2 (2001:4c08:2001:10::2), 30 hops max, 80 byte packets
 1  fde9:556:866f:1::1 (fde9:556:866f:1::1)  0.225 ms  0.216 ms  0.211 ms
 2  fde9:556:866f:9800::241 (fde9:556:866f:9800::241)  0.483 ms  0.481 ms  0.583 ms
 3  2a02:120:200:1cc::1 (2a02:120:200:1cc::1)  3.298 ms  3.386 ms  3.385 ms
 4  2a02:120:200:1::1 (2a02:120:200:1::1)  8.272 ms  8.271 ms  8.477 ms
 5  ams-unet-tc1-dx01-vl160.network.unet.nl (2a02:120:0:200::1:39)  9.240 ms  9.450 ms  9.690 ms
 6  ams-unet-nik-cx02-vl485.network.unet.nl (2a02:120:0:200::1:35)  9.837 ms  9.675 ms  9.907 ms
 7  ams-unet-nik-br01-gi3-1.network.unet.nl (2a02:120:0:200::1:15)  9.905 ms  9.126 ms  9.597 ms
 8  ams-unet-sar-br01-gi3-13.network.unet.nl (2a02:120:0:200::1:5)  8.840 ms  8.682 ms  8.908 ms
 9  2001:450:2002:1b6::1 (2001:450:2002:1b6::1)  8.505 ms  7.964 ms  8.208 ms
10  xe-8-0-0.edge1.SanJose3.Level3.net (2001:1900:4:3::129)  101.918 ms  101.002 ms  101.044 ms
11  vl-52.car1.Chicago1.Level3.net (2001:1900:10:2::3)  102.642 ms vl-51.car1.Chicago1.Level3.net (2001:1900:10:1::3)  102.148 ms  101.411 ms
12  vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22)  103.521 ms  103.502 ms  104.082 ms
13  vl-4081.car1.NewYork2.Level3.net (2001:1900:4:1::f5)  104.318 ms  103.858 ms  103.450 ms
14  vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101)  274.481 ms  273.924 ms  270.443 ms
15  vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11)  103.023 ms  104.181 ms  104.049 ms
16  vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106)  104.294 ms vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102)  106.441 ms vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106)  103.806 ms
17  vl-4060.edge4.Amsterdam1.Level3.net (2001:1900:5:1::206)  112.147 ms  111.584 ms  173.366 ms
18  vl-4080.edge4.Amsterdam1.Level3.net (2001:1900:5:1::10d)  111.909 ms  112.193 ms vl-4080.edge3.Amsterdam1.Level3.net (2001:1900:5:1::109)  111.456 ms
19  router-l3-1.thepeoplesvalley.net (2001:1900:5:2:2::d2)  111.944 ms  113.079 ms  132.739 ms
20  2001:4c08:2001::1 (2001:4c08:2001::1)  133.008 ms  132.949 ms  131.757 ms
21  2001:4c08:2001:10::2 (2001:4c08:2001:10::2)  128.748 ms  122.752 ms  121.988 ms

[ Voor 62% gewijzigd door databeestje op 27-04-2011 13:22 ]

[DDX]

Lekker omweggetje idd.
Vanaf hier naar 2a02:120:200:1cc::1 gaat iets minder ver volgens mij :

code:

traceroute to 2a02:120:200:1cc::1 (2a02:120:200:1cc::1), 30 hops max, 40 byte packets
 1  ge-5-0-2.edge3.Amsterdam1.Level3.net (2001:1900:5:2:2::d1)  0.173 ms  0.146 ms  0.134 ms
 2  vl-4081.edge4.Amsterdam1.Level3.net (2001:1900:5:1::10e)  0.409 ms  0.402 ms  0.393 ms
 3  vl-4060.edge4.London1.Level3.net (2001:1900:5:1::205)  50.696 ms  50.676 ms  50.660 ms
 4  vl-4085.sar1.London1.Level3.net (2001:1900:5:1::221)  8.550 ms  8.526 ms  8.646 ms
 5  2001:7f8:4::ddd:1 (2001:7f8:4::ddd:1)  14.125 ms  8.980 ms  9.097 ms
 6  2001:450:2002:1b6::2 (2001:450:2002:1b6::2)  104.584 ms  104.815 ms  104.549 ms
 7  ams-unet-sar-cx01-gi3-4.network.unet.nl (2a02:120:0:200::1:a)  114.715 ms  114.262 ms  114.250 ms
 8  ams-unet-tc1-dx01-vl152.network.unet.nl (2a02:120:0:200::1:32)  115.317 ms  115.309 ms  115.887 ms
 9  ams-unet-tc1-er01-gi0-1-160.network.unet.nl (2a02:120:0:200::1:3a)  114.571 ms  114.060 ms  114.549 ms
10  2a02:120:200:1::2 (2a02:120:200:1::2)  121.259 ms  121.735 ms  121.511 ms

Hopenlijk gaat level3 nog eens wat verbeteren, want op deze manier ga ik (nog) geen ipv6 enablen op meer servers)

[ Voor 4% gewijzigd door DDX op 27-04-2011 13:36 ]

[Roetzen]

Het jaar van de waarheid voor IPv6

COMPUTABLE EXPERT Erik Huizer:

Is 2011 het jaar van de waarheid voor IPv6? Ik denk het niet. Aan de introductie van IPv6 wordt sinds 1994 hard gewerkt en dat gaat nog vele jaren duren. Dat de IPv4-adressen dit jaar zijn opgeraakt (in de top van de uitdeel-hierarchie) maakt 2011 wel een bijzonder jaar voor IPv4, maar niet zozeer voor IPv6.

Read more: http://www.computable.nl/...r-ipv6.html#ixzz1KjYm8wrG

[Dirtyrockers]

op vmware esx host heb ik 2 nics. op 1 komt ipv4 binnen. op de andere ipv6.

hierop staat een windows 2008 r2 server met 2 nics naar de ipv4 en ipv6.

1 daarvan heeft een ipv6 adres (met gateway en dns etc)

als ik deze alleen op de server gebruik kan ik alleen naar ipv6 adressen toe. (logisch want ander protocol bla bla)

als ik op de 2e nic een ipv4 configureer (met gateway en dns etc) dan kan ik opeens niet meer naar ipv6 adressen toe. terwijl beide nics aan staan.

Ik vermoed dat hij dan over de ipv4 gateway probeert te gaan om bij een ipv6 te komen.

dual stack heb ik van begrepen dat alles daarvoor op 1 nic binnen moet komen?

Maar twijfel om een vSwitch aan te maken met de 2 nics op de vmware doos (volgens mij gaat de host dan dood)

wat zie ik hier over het hoofd? en kan mij een zetje in de juiste richting geven?

[ Voor 22% gewijzigd door Dirtyrockers op 29-04-2011 14:32 ]

[MORCIK]

Dirtyrockers schreef op vrijdag 29 april 2011 @ 14:29:
op vmware esx host heb ik 2 nics. op 1 komt ipv4 binnen. op de andere ipv6.

Kun je me uitleggen hoe je netwerkverbindingen zijn? Wat voor een internetabonnement heb je? Heb je native IPv6 of gebruik je een tunnel?

[Roetzen]

Zo hoor je het ook eens van een ander...

[axis]

Roetzen schreef op zondag 15 mei 2011 @ 17:10:
Zo hoor je het ook eens van een ander...

[afbeelding]

Briljant!!

[Keiichi]

Een deel van m'n server omgeving heb ik nu eindelijk ook op IPv6. M'n datacenter heeft nu in ieder geval 2 tranists actief. Ik heb nog niet gelijk alles dual stacked gemaakt, maar alle dingen die niet kritisch zijn wel op ipv6 gezet.

[vanaalten]

Een beetje HK niveau, en een beetje reklame (is tenslotte mijn werkgever):
An Internet Address for Every Light Bulb

... zo te zien een chip voor in spaar- en LED lampjes, met IPv6 support.

(...) supporting IPv4 and IPv6 with over-network upgradability.

"Sinds ik m'n bureaulamp een firmware-upgrade heb gegeven geeft 'ie veel warmer licht."

[Raven]

IPv6 Day Could Stress-Test Small ISPs

ISPs had better be ready for World IPv6 Day on June 8, because they may hear from customers whose IPv6 connections don't work as expected.

That's the word from Martin Levy, director of IPv6 strategy at Hurricane Electric , a competitive service provider that has been touting its IPv6 roots for years now.

Levy is generally positive about the recent growth in IPv6 deployments, noting that IPv6 connections make up about 10 percent of Internet traffic now. But Levy is encouraging all ISPs to reach out to customers -- especially businesses -- as the IPv4 numerical addresses dwindle down to a precious few.

On June 8, major Internet sites such as Google, Facebook, Yahoo! and more will turn up IPv6 connectivity to allow IPv6-enabled endpoints to test their connectivity. Generally speaking, the Internet community thinks between 0.12 percent and 0.5 percent of connections will fail -- a small percentage overall but still a large number to companies that count on millions of transactions daily to fuel their Internet businesses.

When those customers don't succeed in connecting to their favorite websites, however, they aren't likely to call Google or Yahoo!, but they will call their ISP, and the volume of calls could disrupt business as usual if service providers aren't prepared.

"That's really who they should be calling," Levy says. "And the easiest way for those folks to fix the problem is to enable v6."

Levy says about 50 percent of service providers have IPv6 enabled, but those service providers tend to be well connected, that is, connected to eight or more other service providers. Networks in less densely populated areas with fewer connection options aren't as likely to have IPv6 networking available. (See Cable Show to Highlight IPv6 Transition , Verizon Expands IPv6 Support, AT&T Pushes IPv6 and Cable: We're Ready for IPv6.)

Levy says he deals daily with businesses that need IPv6 connections and are forced to connect to a network such as Hurricane Electric's through tunnels because of the lack of local IPv6 connection. Those tunnels are better than nothing, but not as robust as native IPv6 service. (See Hurricane Electric Offers IPv6 Aid to Enterprises.)

Smaller ISPs are the ones less likely to have IPv6 access available, even though they may have equipment that can handle the newer Internet addressing scheme. Wireless services also are less likely to be IPv6 on an end-to-end basis, using proxy servers and network address translation to handle conversions between IPv4 and IPv6, Levy says.

The big splash made earlier this year about IPv4 number exhaust at the global registry, as the final IPv4 address blocks were handed out to regional registries, has more ISPs and business customers taking action on v6 transition plans. At Interop last week, American Registry for Internet Numbers (ARIN) President John Curran said the IPv4 numbers left in North America should last "until the end of this year, maybe a little longer." (See Global IPv4 Counter Hits Zero.)

— Carol Wilson, Chief Editor, Events, Light Reading

Waarschijnlijk domme vraag, maar ik stel 'm toch. Wat heeft die test voor zin als die sites gewoon via IPv4 beschikbaar blijven? Je zou eigenlijk IPv4 moeten blokkeren om een goed beeld te krijgen van of IPv6 goed werkt voor degenen die daar al gebruik van kunnen maken, maar dat is mijn mening.
(Waarschijnlijk hebben de callcenters van de verschillende ISP's, op XS4All na dan, heel wat overspannen medewerkers als die sites alleen via IPv6 bereikbaar zouden zijn als test....)

[CyBeR]

Dit gaat meer om hosts die denken ipv6 te hebben waar dat helemaal niet het geval is. Dat levert een probleem op bij dual-stack sites.

[Verwijderd]

Goedemiddag,

Recentelijk ben ik zelf ook aan de slag gegaan met IPv6.
Ik maak gebruik van Cisco ASA firewalls.

Nu heb ik van het datacentrum een /64 adres prefix gekregen.

Nu is mijn vraag:
Hoe zorg ik dat ik kan communiceren met de backbone van het datacentrum?
Bij IPv4 kreeg je een "extern" adres voor je outside interface en kon je doormiddel van NAT je eigen deel, de inside interface, van het netwerk invullen. Hiermee werd je firewall als het ware ook gelijk een soort router.

Nu met IPv6 loop ik tegen het probleem dat de outside en inside interfaces in hetzelfde netwerk zitten.
Moet ik hiervoor mijn firewall op "transparant mode" zetten in plaats van routed mode zetten? en hoe regel ik de addressering verder?

Alvast bedankt.

[MORCIK]

Verwijderd schreef op woensdag 18 mei 2011 @ 16:25:

Moet ik hiervoor mijn firewall op "transparant mode" zetten in plaats van routed mode zetten? en hoe regel ik de addressering verder?

In geval van IPv6 kun je beide toepassen, maar wat voor jouw situatie handiger is kan ik niet bepalen. Lees je goed in wat het verschil is tussen die twee. Met IPv6 heb je geen NAT meer, net zoals vroeger (voor 1999). Je werkt met directe adressen zoals internet bedoeld is. NAT is een workaround in het IPv4 protocol om te voorkomen dat IPv4 adressen te snel zouden opraken. Dit dreigde al eind jaren '90 maar IPv6 was nog lang niet klaar, wel in ontwikkeling. Als je een /64 reeks hebt gekregen heb je maar 1 subnet. Heb je daar voldoende aan?

[Verwijderd]

MORCIK schreef op vrijdag 20 mei 2011 @ 01:10:
[...]


In geval van IPv6 kun je beide toepassen, maar wat voor jouw situatie handiger is kan ik niet bepalen. Lees je goed in wat het verschil is tussen die twee. Met IPv6 heb je geen NAT meer, net zoals vroeger (voor 1999). Je werkt met directe adressen zoals internet bedoeld is. NAT is een workaround in het IPv4 protocol om te voorkomen dat IPv4 adressen te snel zouden opraken. Dit dreigde al eind jaren '90 maar IPv6 was nog lang niet klaar, wel in ontwikkeling. Als je een /64 reeks hebt gekregen heb je maar 1 subnet. Heb je daar voldoende aan?

Allereerst dank voor je reactie.
Ik heb ondertussen ook niet stilgezeten, ik ben erachter gekomen dat je op je "outside" interface helemaal geen adres hoeft in te stellen ! Ik hoef alleen maar een prefix aan te kondigen volgens mij. In zo verre, ik kan pingen naar een host die bij wijze van test aan de buitenkant een compleet ander ipv6 adres heeft.
Het is allemaal wel even wennen voor mij.

Aan de binnenkant heb ik uiteraard ook dezelfde prefix aangekondigd, met EUI 64 voor de clients.
Schijnbaar werkt het alleen als ik ook op de link local ( FE80::) een adres voor de firewall definieer. Deze wordt dan aan de clients gegeven als soort van default gateway. Hierna kan ik pas pingen naar andere hosts op andere subnets.

Wat die /64 prefix betreft, deze prefix is alleen voor het testen hier binnen het bedrijf. Clients met EUI 64 werkt als een zonnetje en servers hebben een ipv6 mapped adres ( laatste 32 bits voor het gemak decimaal genoteerd van hun "oude" IPv4 adres).

We hebben hosting op meerdere locaties waar we op den duur ook ipv6 willen gaan gebruiken. Daar zullen uiteraard andere prefixes gebruikt gaan worden omdat het "internet" daar geregeld wordt door een andere ISP.

Tot zo ver mijn ervaring met IPv6 nog een hoop te ontdekken zie ik al

[Raven]

CyBeR schreef op woensdag 18 mei 2011 @ 11:56:
Dit gaat meer om hosts die denken ipv6 te hebben waar dat helemaal niet het geval is. Dat levert een probleem op bij dual-stack sites.

Okee. Maar dan nog zou je dus een IPv6 connectie moeten forceren toch om te checken of het goed werkt omdat het anders gewoon via IPv4 gaat. Of zit ik er helemaal naast
Als ik een willekeurige site open gaat het namelijk via IPv4, vandaar mijn verwarring

[Jaap-Jan]

Hoe het meestal werkt bij dual-stack sites is dat eerst IPv6 wordt gebruikt en mocht dat niet werken: IPv4. Dat gaat wel in serie: als IPv6 een timeout geeft, wordt IPv4 geprobeerd en dan zit je toch eventjes (minstens een seconde of 15) te wachten.

[CyBeR]

Raven schreef op vrijdag 20 mei 2011 @ 12:45:
[...]

Okee. Maar dan nog zou je dus een IPv6 connectie moeten forceren toch om te checken of het goed werkt omdat het anders gewoon via IPv4 gaat. Of zit ik er helemaal naast
Als ik een willekeurige site open gaat het namelijk via IPv4, vandaar mijn verwarring

Je zit er gedeeltelijk naast.

In principe heeft een native IPv6 verbinding voorrang op IPv4. Dus als jij en de server volledig dual-stack zijn, zal die verbinding over IPv6 gaan. Ben jij echter alleen voorzien van Teredo of 6to4 (2000::/32 of 2002::/16) connectiviteit, dan heeft IPv4 voorrang omdat dat (teredo, 6to4) 'inferieure' connectiviteit is, die eigenlijk alleen bedoeld is voor de situatie waar jij geen native IPv6 hebt en de server die je probeert te bereiken geen IPv4.

De meeste willekeurige sites hebben geen IPv6, maar probeer eens www.ripe.net; of je IPv4 of IPv6 gebruikt staat dan rechtsboven.

[Raven]

Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

[Jaap-Jan]

Een 6in4- tunnel is bijna net zo goed als native, dus krijgt voorrang. Het gaat om de technieken 6to4 en Teredo, of in het algemeen: protocollen die IPv6- connectiviteit bieden zonder expliciet tunnels te hoeven configureren.

[ Voor 3% gewijzigd door Jaap-Jan op 20-05-2011 16:31 ]

[CyBeR]

Raven schreef op vrijdag 20 mei 2011 @ 16:25:
Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

Nee, een dergelijke tunnel wordt door de software gezien als gelijk aan native. Het is alleen 6to4 en teredo (waarbij je een adres in eerder genoemde ranges hebt) wat, normaal gesproken, geen voorrang krijgt.

[zzattack]

Raven schreef op vrijdag 20 mei 2011 @ 16:25:
Ah kijk, ik wist niet dat IPv6 voorrang heeft tov IPv4.
Heb zelf een HE tunnel naar mijn pfSense router, alle pc's in mijn LAN kunnen er gebruik van maken. Dus hier heeft IPv4 voorrang als ik het goed begrijp?

Al lang? Build van Seth gebruikt of gitsync? Ik krijg geen enkele ipv6 build stabiel
De webui wordt na een aantal dagen unreachable maar routen blijft goed gaan. WebUI restarten helpt niet. SSH werkt soms iets langer, maar wat later kunnen shared libraries niet meer geladen worden en kan ik zelfs niet meer in pfSense sshen. Ik wacht wel op 2.1 voorlopig.

[ Voor 25% gewijzigd door zzattack op 20-05-2011 16:44 ]

[Raven]

Deze gebruik ik: http://www.xaero.org/inde...-on-the-pfsense-firewall/ icm pfSense 1.2.3.
Moet alleen nog even paar commands (/etc/rc.conf_mount_rw en /etc/rc.conf_mount_ro) aan de scriptjes toevoegen omdat het FS als RW gemount moet zijn tijdens het uitvoeren van de scripts. Daar ik de embedded versie van pfSense draai is het FS als RO gemount...

Ehm, gebruik die al een tijdje, maar zo vaak bezoek ik geen IPv6 sites. Was alleen om te kijken of ik mijn LAN alvast klaar kon maken voor IPv6. Sindsdien nog niet echt veel mee gedaan

edit: wtf, die scriptjes zijn niet meer aanwezig. Dan maar opnieuw maken.

Jaap-Jan schreef op vrijdag 20 mei 2011 @ 16:31:
Een 6in4- tunnel is bijna net zo goed als native, dus krijgt voorrang. Het gaat om de technieken 6to4 en Teredo, of in het algemeen: protocollen die IPv6- connectiviteit bieden zonder expliciet tunnels te hoeven configureren.

CyBeR schreef op vrijdag 20 mei 2011 @ 16:33:
[...]


Nee, een dergelijke tunnel wordt door de software gezien als gelijk aan native. Het is alleen 6to4 en teredo (waarbij je een adres in eerder genoemde ranges hebt) wat, normaal gesproken, geen voorrang krijgt.

Okido

edit: scriptjes weer aangemaakt, dit keer zonder die veelgemaakte fout
Router kan pingen naar ipv6.google.com, pc's krijgen IPv6 adres toegewezen maar kunnen niet van de tunnel gebruik maken. Pingen geeft timeouts of doelhost niet bereikbaar, maar IPv6 adres van de te pingen site is blijkbaar wel opvraagbaar. Pfffff....

edit2: Onder 7 werkt het , is dus iets met XP, maar wat. Vorige keer hoefde ik daar niks in te stellen
edit3: En nu werkt het ineens niet meer onder 7, wtf is dit nu weer....
edit4: dan werkt het ineens weer wel, dan niet, wel, niet, maar router heeft continu connectie
edit5:

Hele diepe zucht

Had de commando's om het FS als RW en RO te mounten aan de scripts toegevoegd, dat was blijkbaar geen goed idee. Dat zorgde ervoor dat het niet werkte. Maar nu moet ik dus na elke reboot van de router (gebeurt gelukkig niet zo vaak) met de hand het FS als RW mounten, beide scripts runnen, FS weer als RO mounten, niet echt handig

[ Voor 54% gewijzigd door Raven op 20-05-2011 22:46 ]

[databeestje]

Ik kan geen support geven op 1.2.3 met wat zelfbouw scripts. Ik weet dat het in de 2.0 ipv6 code wel een stuk beter gaat. Daarvoor kan je gewoon in het pfSense forum terecht in het IPv6 board.

In ander nieuws, DHCP-PD wordt ondersteunt op de WAN interface met mijn image. Ik ben inmiddels ook zo ver dat je op de LAN dhcp 6 server ook prefix delegatie kan doen.

1 openstaand issue is dat met de HE of Sixxs tunnel de default gateway soms kan wegvallen. Deze open issue zal binnenkort worden opgepikt.

Ik ben nog opzoek naar een vrijwilliger die native ipv6 krijgt op een ADSL in combinatie met PPPoE of een dergelijke verbinding van Xs4all, BusinessConnect, Unet of Signet. Dit om de DHCP-PD support af te kunnen maken en veldtesten.

[Raven]

Hmm, okee. Mocht ik ooit overstappen op 2.* dan zal ik daar eens naar kijken.
Maar (nu ietwat offtopic) zit er aan te denken pfSense aan de kant te gooien en over te stappen op Zentyal, dit vanwege de gebrekkige wifi support in FreeBSD. Voor zover ik kan terugvinden moet ik daar ook een zelfbouw script gebruiken om IPv6 werkend te krijgen. Daar kijk ik later wel naar.

[zenith]

wanneer komt pfsense met ipv6 support? (in de GUI enzo)

[ Voor 18% gewijzigd door zenith op 22-05-2011 20:48 ]