Het grote IPv6 topic

[HarmoniousVibe]

Osiris schreef op dinsdag 07 juli 2009 @ 18:26:
Euhm, bij Sixxs kun je kiezen uit meerdere protocollen. Dus "als Sixxs" kun je niet echt zeggen

Sorry, AYIYA dan.

[CyBeR]

LB06 schreef op dinsdag 07 juli 2009 @ 18:12:
Wat zijn technisch gezien eigenlijk de verschillen tussen 6to4, Teredo en oplossingen als sixxs?

Ik heb begrepen dat Teredo is ontwikkeld als verbetering van 6to4, aangezien deze niet werkt in een NAT opstelling. Dus dat is op zich duidelijk.

Maar wat is niet snap is wat de verschillen zijn tussen Teredo en sixxs. Kan iemand me dit uitleggen? Teredo lijkt makkelijker: geen DNS handler nodig, niet registreren en geen gezeur met credits enzo. Wat zijn dan de voordelen van Sixxs-achtige oplossingen?

Nou ja 't is eigenlijk vrij simpel: teredo en 6to4 zijn hacks en daardoor kut, sixxs is een tunnelprovider. Bij SixXS krijg je ook echt IP-space toegewezen, daarom moet je bekend zijn. Anders kun je gaan zitten spammen met hun IP-space en ben jij niet te achterhalen. In 6to4 en Teredo zit je ipv4-adres verwerkt zodat die ontraceerbaarheid al wat minder is.

[ Voor 14% gewijzigd door CyBeR op 07-07-2009 19:22 ]

[CAPSLOCK2000]

sixxs (of een andere tunnel provider):
Je bouwt een tunnel naar sixxs, daarvoor moet je je wel registreren bij sixxs

6to4:
Voor ieder IPv4 adres is een IPv6 netwerkje gereserveerd. Als jij een IPv4 adres hebt, heb je dus ook een IPv6 adres. Je moet nu alleen nog een tunnel naar de rest van het IPv6 netwerk maken. Je doet dat niet zoals bij sixxs naar een vast adres, maar naar een speciaal anycast adres. Het komt er op neer dat jouw verkeer wordt doorgegeven tot het op een router komt die IPv6 snapt, en het dan voor jouw doorstuurt.
Het voordeel is dat je niks hoeft te registreren, en je (in ieder geval in Nederland) automatisch bij een relatief snelle tunnelprovider uit komt.
Het nadeel is dat je adres aan je IPv4 adres gekoppeld is. Als dat verandert, verdanderen je IPv6 adressen ook. Het andere nadeel is dat je wel een extern bereikbaar IPv4 adres hebt. Als je achter een NAT of firewall zit moet je poorten open gaan zetten, wat niet altijd kan.

toredo: Om bovenstaand probleem op te lossen is er een methode bedacht om automatisch gaten te prikken. Het nadeel is dat dit nogal inefficient is.

XS4All biedt haar klanten (net als sixxs) een tunnel aan, en is (net) begonnen met "echte" IPv6 verbindingen. Daarvoor zal je waarschijnlijk wel een nieuw modem moeten krijgen.

[8-Track]

Klopt. Alleen de FritzBox 7270 heeft ondersteuning voor v6, en die is sinds kort leverbaar. De 7170, die een hoop mensen hebben, zou naar wat ik gehoord heb te weining geheugen bezitten om v6 te draaien. Er zou een theoretische optie zijn om een hoop features zoals de voicemailbox en de faxoptie uit de huidige 7170 firmware te slopen en dat te vervangen door v6, zodat ook huidige bezitters van een Fritzbox ook v6 kunnen draaien, maar voor zover ik heb begrepen voelt AVM daar vooralsnog weinig voor.

Overigens ben ik op *dit* moment een interview aan het editen met XS4ALL over dit onderwerp. Ik hoop dat volgende week online te krijgen. In de tussentijd staat een interview met David Freedman van Claranet online, die onder andere praat over de problemen met MPLS tijdens hun roll-out, die in 2002 begonnen is. Later deze week heb ik Google op de rol staan over ipv6.google.com.

[8-Track]

Verwijderd schreef op dinsdag 23 juni 2009 @ 17:00:
Dat interview is een puur propaganda filmpje. Van RIPE. Wat had je anders verwacht ?

Ik moet hier toch even op reageren hoor. Een van de doelen van de RIPE NCC als organisatie is de continuiteit en stabiliteit van het Internet. IPv6 is daar volgens een groot deel van de Internetgebruikers een onderdeel van. Volgens jou misschien niet, maar dat maakt het nog geen propaganda.

Het hele verhaal van "get experience now, or you'll be in problems in 3 years", dat heb ik al vaker gehoord. Om precies te zijn, dat hoor ik al sinds 1996. Dat "real soon now(tm)" blijft altijd hetzelfde.

Dat is onzin. In 2003 voorspelde Geoff Huston dat IPv4 nog ruim 20 jaar mee zou gaan. Er is heel veel veranderd de laatste jaren. De urgentie was er niet, maar is er nu wel degelijk. En een hele hoop mensen hebben dat nog niet in de gaten. De vraag naar ip adressen is enorm gestegen, en groeit nog steeds door.

En altijd worden er oplossingen gevonden om IPv4 door te laten draaien. Ik heb meer vertrouwen in de vindingrijkheid van mensen om IPv4 meer leven in te blazen dan dat het hele net naar IPv6 overstapt.

We zullen zien wie er gelijk gaat krijgen. Persoonlijk vind ik de pijn die de uitrol van v6 gaat veroorzaken minder erg dan de pijn van v4 achter NAT achter nog meer NAT. Als IPv4 straks op is, hebben we 15% van de wereldbevolking op Internet aangesloten. Gaan we de rest achter NAT zetten?

[Osiris]

CAPSLOCK2000 schreef op woensdag 08 juli 2009 @ 03:09:
sixxs (of een andere tunnel provider):
Je bouwt een tunnel naar sixxs, daarvoor moet je je wel registreren bij sixxs

Correctie: Je bouwt een tunnel naar een ISP die zich via Sixxs daarvoor beschikbaar stelt als Point of Presence. Sixxs is zelf geen tunnelbroker.

[HarmoniousVibe]

Misschien lichtelijk off-topic, maar zijn er hier ook mensen die bij XSnews meer dan 20mbit/s halen? Ik haal namelijk tegen de 100mbit/s, wat mijn volledige dowstream bandwidth is. Ik heb een tunnel via de PoP van Surfnet (SixXS dus) en ik zit zelf ook op het surfnet-netwerk. Het vreemde is ook dat de grafiekjes van SixXS niet meer dan 2,5MB/s laten zien (die 20mbit dus). Misschien dat er per abuis nog 80mbit/s over ipv4 wordt verstuurd ofzo? Ik weet het ook niet...

Ik heb het 'probleem' al aangekaard bij XSnews. Leek me wel zo netjes om geen misbruik te maken van deze mooie service. Er is echter nooit op gereageerd, dus dan kan ik er verder ook niks meer aan doen. Maar ik ben sowieso wel benieuwd hoe dit kan.

Ik gebruik sabnzbd+ op OS X.5.7 en ik weet 100% zeker dat ik maar één server heb ingesteld en dat is de ipv6 server van XSnews. Iemand die hier zijn licht over kan laten schijnen?

[Tomsworld]

LB06 schreef op maandag 13 juli 2009 @ 14:42:
Misschien lichtelijk off-topic, maar zijn er hier ook mensen die bij XSnews meer dan 20mbit/s halen? Ik haal namelijk tegen de 100mbit/s, wat mijn volledige dowstream bandwidth is. Ik heb een tunnel via de PoP van Surfnet (SixXS dus) en ik zit zelf ook op het surfnet-netwerk. Het vreemde is ook dat de grafiekjes van SixXS niet meer dan 2,5MB/s laten zien (die 20mbit dus). Misschien dat er per abuis nog 80mbit/s over ipv4 wordt verstuurd ofzo? Ik weet het ook niet...

Ik heb het 'probleem' al aangekaard bij XSnews. Leek me wel zo netjes om geen misbruik te maken van deze mooie service. Er is echter nooit op gereageerd, dus dan kan ik er verder ook niks meer aan doen. Maar ik ben sowieso wel benieuwd hoe dit kan.

Ik gebruik sabnzbd+ op OS X.5.7 en ik weet 100% zeker dat ik maar één server heb ingesteld en dat is de ipv6 server van XSnews. Iemand die hier zijn licht over kan laten schijnen?

Scale aangepast van je grafiekje op sixxs.net dat durf af en toe verkeerd gaan. Misschien is de cap eraf ik weet dat ze even de ipv6 service offline hebben gehad afgelopen week.

[Verwijderd]

8-Track schreef op zondag 12 juli 2009 @ 17:05:
Ik moet hier toch even op reageren hoor. Een van de doelen van de RIPE NCC als organisatie is de continuiteit en stabiliteit van het Internet. IPv6 is daar volgens een groot deel van de Internetgebruikers een onderdeel van. Volgens jou misschien niet, maar dat maakt het nog geen propaganda.

Ripe is primair een organizatie die IP-adressen uitdeelt. Dit interview met Bush doet het lijken alsof het adressen-tekort het enige grote probleem is. En RIPE kan ons redden door IPv6 adressen uit te delen. Alsof de Nederlandse vereniging van tandartsen een persbericht doet uitgaan dat de tandjes van de Nederlanse jeugd hard achteruit gaat, en iedereen echt deze week nog naar de tandarts moet.

Niet dat RIPE kwaad in de zin heeft. Helemaal niet. Maar er waren meer problemen die opgelost hadden moeten worden met IPv6. En dat is niet gebeurd. Omdat de designers van IPv6 geen oog (en geen weet) hadden van andere echte problemen. IPv6 is een lapmiddel, met als NAT een lapmiddel is. Als je een echte oplossing voor een "next-generation" netwerk protocol wilt hebben, dan moet je wachten op iets dat na IPv6 komt. IPv6 is gewoon niet goed genoeg. Behalve meer bits in de adressen is er echt helemaal niks dat IPv6 voor heeft op IPv4. Niet voor providers, niet voor end-users, niet voor grote bedrijven, niet voor wetenschappers. Helemaal niks. Gemiste kans.
En als er geen voordelen zijn, dan willen mensen er geen geld aan spenderen. En dus gebeurt er niks.

Dat is onzin. In 2003 voorspelde Geoff Huston dat IPv4 nog ruim 20 jaar mee zou gaan. Er is heel veel veranderd de laatste jaren. De urgentie was er niet, maar is er nu wel degelijk. En een hele hoop mensen hebben dat nog niet in de gaten. De vraag naar ip adressen is enorm gestegen, en groeit nog steeds door.

Zoals dat artikel toen al zei: "voorspellen is moeilijk, voorals als het over de toekomst gaat".
Die voorspelling uit 2003 was dus vooral een hoop gezuig uit de duim.
En dat geld voor alle voorspellingen op het moment.

Het probleem met voorspellen zit hem in het feit dat als er echt tekort komt, de mensen vindingrijker zullen worden. Bijvoorbeeld: er zijn hopen ongebruikte addres-space. Of erg inefficient gebruikte addresspace. Maar waarom zou je je netwerk strakker hernummeren ? Of ongebruikte addressspace teruggeven. Wel, IP adressen zouden kunnen worden "verkocht" of "geleend" of "geleased". Mag iemand anders een stuk van je class B gebruiken, voor $2k per jaar of zo.
Zelf zie ik gewoon meer NAT. Simpel. Klaar.

We zullen zien wie er gelijk gaat krijgen. Persoonlijk vind ik de pijn die de uitrol van v6 gaat veroorzaken minder erg dan de pijn van v4 achter NAT achter nog meer NAT. Als IPv4 straks op is, hebben we 15% van de wereldbevolking op Internet aangesloten. Gaan we de rest achter NAT zetten?

En wat is de pijn van v4-achter-NAT ?
Ik ben een vrij technisch iemand. En ik zit al zo lang als ik ADSL heb achter NAT. Vind ik wel prima. Vind ik wel veilig. Als ik een bedrijfs-netwerk zou runnen, zou ik ook willen dat iedereen in mijn bedrijf achter NAT zat. Dan prik ik wel een gaatje voor een ieder die echte een service available wil maken.

Ik denk dat je het uitrollen van v6 zwaar onderschat. ISPs zijn panisch om de software op hun apparatuur te upgraden. De laatste keer dat ik software schreef (en dat was jaren geleden) hadden een hoop grote ISPs al een beleid waar ze nieuwe releases eerst 3 tot 6 maanden intern testen. Zo paranoia waren ze. En nu wil je even de hele santekraam naar een nieuwe techniek en nieuwe software over zetten. Dat gaat geheid mis. En daar zit niemand op te wachten.

Het adressen tekort is een probleem. Dat is zeker waar.
Maar is IPv6 de oplossing ? Denk daar maar eens over na.

IPv6 is een waardeloze technologie. Brengt niks meer dan IPv4.
Ik durf zelfs te stellen dat het minder brengt. Bij voorbeeld: in IPv4 wordt de addressspace optimaal benut. Onder andere door CIDR. Toen IPv6 uitkwam, vonden de luitjes dat maar lastig, die classless addressen. En dus begonnen ze meteen weer classes in te voeren. En iedereen kreeg meteen bakken met nieuwe adressen. Zelfs al heb je er een ziljoen, dan nog hebben mensen thuis geen /48 nodig. Allemaal gerommel.

IPv6 is een gemiste kans. Komt het er ooit ? Misschien. Misschien heb je gelijk en komt het RealSoonNow(tm). Misschien duurt het nog 10 jaar. Of 20. Naar mijn mening zou het mooi zijn als IPv6 op de schop zou gaan, en er echt een nieuw protocol zou komen dat echte problemen op zou lossen. Identifier en locator separation enzo. Multi-homing support. Mobile support. Noem naar op. Daar hoeft niet heel IPv6 voor te worden weggegooid. Maar je moet beginnen met de vooronderstelling dat niks heilig is. Dan krijg je misschien iets dat de moeite waard is. En wat de moeite waard is, daar gaan mensen vanzelf achteraan. Dan hoeft je niet 15 of 20 jaar lang te smeken of ze toch alsjeblieft eens naar IPv6 willen kijken.

Afijn, allemaal mijn persoonlijke mening. Die er niet toe doet.
Maar ik heb wel gelijk.

[axis]

Gryz, ik snap je mening, en ik denk dat veel mensen je mening delen, ben het alleen niet helemaal met je eens.

Ik wil end-to-end communicatie tussen alle devices ter wereld kunnen hebben, zonder tussenkomst van NAT, zodat voortaan ook protocollen zoals SIP, GRE, FTP, etc, fatsoenlijk kunnen werken zonder truukjes of de nodige interventie op je firewall.

Daarnaast heeft meer IP's ook meer voordelen. Als je als content provider (lees iemand die webservers beheert) een /48 krijgt, kun je 64.000 /64 subnetjes maken, en bijvoorbeeld iedere klant in een publiek subnetje isoleren. Gevolg is weer makkelijker firewallen en betere security. (nu zetten content providers meestal al hun klanten in 1 enkel publiek subnet).

Ik ben het wel met je eens dat IPv6 niet zoveel meer brengt dan IPv4, alleen meer addressen, dat klopt helemaal. Maar het gevolg daarvan is wel aanzienlijk. Iedereen krijgt meer ip's, en NAT wordt eindelijk de deur uit gedaan.

Er zijn mensen die denken dat je zonder NAT meteen minder security hebt, maar dat zal ook niet echt het geval zijn. Nu is het bij de meeste firewall/routers zo dat standaard alle outbound connecties worden toegestaan, en de responses daarop. Dat zal straks exact hetzelfde zijn, alleen dan zonder NAT. Dus qua security verandert er niets, alleen dat je aan de buitenkant het ip-adres ziet van de afzender.

En ipv6 komt, of je nu wilt of niet. Nog sterker, het is er al. Er zijn genoeg ISP's die compleet op ipv6 draaien (in Azie), met ipv4 achterop voor backwards compatibility. De Amerikaanse overheid heeft hun overheidsnetwerken nu ipv6-ready, en over een paar jaar draait alles daar verplicht op ipv6.

De meeste sites die we (lees: het bedrijf waarvoor ik werk) hosten zijn ondertussen ook bereikbaar over IPv6, en elke zelfrespecterende contentprovider is hiermee bezig.

Ik ben het met je eens dat naarmate x-day dichterbij komt (704 dagen volgens huidige berekening) mensen een stuk vindingrijker zullen worden. Ik krijg nu nog van mijn ISP makkelijk /26 subnetjes op IPv4, dat zal volgend jaar waarschijnlijk al niet meer het geval zijn.

En ja, misschien dat over 2-3 jaar je duizenden euro's moet gaan betalen voor IPv4 adressen, maar dat is juist prachtig! Hoe duurder IPv4 adressen worden, hoe hoger de incentive is om zoveel mogelijk over IPv6 te doen Marktwerking zal zijn ding wel doen.

En een van de andere voordelen van projecten zoals deze is natuurlijke selectie. Colocation-klanten (voornaamste bron van content providers) vragen om IPv6, and als providers daarin niet meewerken, zullen ze klanten verliezen, en zo doet de marktwerking weer zijn ding. Slechte ISP's die over 2 jaar pas gaan spelen met IPv6 zijn te laat.

Hetzelfde geldt voor systeembeheerders, developers, etc. Als je over 2 jaar pas je applicaties ipv6-ready gaat maken, ben je waarschijnlijk te laat, en je heb een kennisachterstand op je branchegenoten. Dat kan vervelend uitpakken voor je als je klant dan opeens een applicatie wil en als eis stelt dat ipv6 bereikbaarheid een harde requirement is.

[CAPSLOCK2000]

Een erg belangrijk voordeel van IPv6 dat vaak over het hoofd gezien wordt is de versimpelde route structuur.
IPv4 is een lappendeken, met overal kleine netwerkjes die vrijwel willekeurig aan elkaar zijn geplakt. Daarom heb je gigantische routetabellen nodig, en bloedsnelle hardware om al die regels uit te voeren. In veel bestaande hardware is de ruimte gewoon op. Daar moet men dan besluiten om kleine netwerken niet meer apart bij te houden, maar de data maar een beetje op geluk de goede kant op te duwen.

IPv6 is veel hierarchischer, waardoor het routen in de meeste gevallen poepsimpel is, en je dus met eenvoudigere hardware toe kan (of voor het zelfde geld meer data verwerken).

NAT is bruikbaar zolang je er van uit gaat dat Internet voornamelijk een een-richting systeem is met een duidelijke scheiding tussen clients en servers. We gaan echter steeds meer de P2P kant op, en als beide kanten van een verbinding geNAT zijn heb je een probleem. Dan moet je ofwel poorten gaan forwarden, ofwel een derde partij vragen om als tussenpersoon te spelen.
Beide zijn onwenselijk. Als ik twee computers op internet heb wil ik dat die rechtstreeks met elkaar kunnen praten.

Zolang je het over een handvol computers hebt kun je je nog behelpen met port forwards of upnp. Ook in een eenvoudig bedrijfsnetwerk met 100 computers die alleen een beetje hoeven te browsen is het nog wel te doen. In complexere situaties wordt het al snel een ramp.
Met 5.000 mensen vanaf 1 IP proberen te Skypen of te Bittorrenten lijkt me een totale hel voor de beheerders.

5.000 mensen lijkt misschien veel, maar stel je nu even voor dat je een telefoon provider bent, dan is 5.000 gebruikers helemaal niks. Momenteel komt het ze wel handig uit dat internet op je telefoon nog niet helemaal serieus wordt genomen, maar vroeg of laat willen mensen ook naar hun telefoon verbinden, en niet alleen vanaf.

[Verwijderd]

Ik ben bezig met een onderzoek naar redenen die bedrijven hebben om niet te investeren in IPv6. Dit is in het kader van mijn bachelorscriptie aan de TU Delft.

Ik zou alle IT'ers op dit forum graag willen vragen om mijn enquete in te vullen, duurt maar 5 min en jullie mening is van belang in dit onderzoek! Ik zal de resultaten van het onderzoek posten in dit forum bij respons

Link: http://spreadsheets.googl...tc0FLRXA3bTc1NVhEZFE6MA..

TIA!!

[axis]

Verwijderd schreef op vrijdag 24 juli 2009 @ 15:13:
Ik zou alle IT'ers op dit forum graag willen vragen om mijn enquete in te vullen, duurt maar 5 min
..
TIA!!

Ingevuld..

Trouwens nog een tip voor mensen die professioneel bezig zijn met ipv6, schrijf je in op de ipv6 taskforce mailing list, komt interessante info voorbij.

@Booker, misschien kun je daar ook nog je onderzoekje spammen

[ Voor 7% gewijzigd door axis op 24-07-2009 17:18 . Reden: url toegevoegd ]

[tim427]

Ingevuld!

Ik volg de techniek op de voet!

---------------EDIT-------------

Is er al iemand bekend met SIXXS (of evt. een andere provider) om in combinatie met Server 2008 en Routing and Remote Access Service role?

Oftewel de Window Server router in combinatie met IPv6..

Ik wil dus mijn router (win2k8) IPv6 adressen uit laten delen met RRAS (niet met een router paketje van de provider zelf).

[ Voor 80% gewijzigd door tim427 op 24-07-2009 18:55 ]

[Snow_King]

CAPSLOCK2000 schreef op dinsdag 14 juli 2009 @ 11:48:
Een erg belangrijk voordeel van IPv6 dat vaak over het hoofd gezien wordt is de versimpelde route structuur.
IPv4 is een lappendeken, met overal kleine netwerkjes die vrijwel willekeurig aan elkaar zijn geplakt. Daarom heb je gigantische routetabellen nodig, en bloedsnelle hardware om al die regels uit te voeren. In veel bestaande hardware is de ruimte gewoon op. Daar moet men dan besluiten om kleine netwerken niet meer apart bij te houden, maar de data maar een beetje op geluk de goede kant op te duwen.

IPv6 is veel hierarchischer, waardoor het routen in de meeste gevallen poepsimpel is, en je dus met eenvoudigere hardware toe kan (of voor het zelfde geld meer data verwerken).

NAT is bruikbaar zolang je er van uit gaat dat Internet voornamelijk een een-richting systeem is met een duidelijke scheiding tussen clients en servers. We gaan echter steeds meer de P2P kant op, en als beide kanten van een verbinding geNAT zijn heb je een probleem. Dan moet je ofwel poorten gaan forwarden, ofwel een derde partij vragen om als tussenpersoon te spelen.
Beide zijn onwenselijk. Als ik twee computers op internet heb wil ik dat die rechtstreeks met elkaar kunnen praten.

Zolang je het over een handvol computers hebt kun je je nog behelpen met port forwards of upnp. Ook in een eenvoudig bedrijfsnetwerk met 100 computers die alleen een beetje hoeven te browsen is het nog wel te doen. In complexere situaties wordt het al snel een ramp.
Met 5.000 mensen vanaf 1 IP proberen te Skypen of te Bittorrenten lijkt me een totale hel voor de beheerders.

5.000 mensen lijkt misschien veel, maar stel je nu even voor dat je een telefoon provider bent, dan is 5.000 gebruikers helemaal niks. Momenteel komt het ze wel handig uit dat internet op je telefoon nog niet helemaal serieus wordt genomen, maar vroeg of laat willen mensen ook naar hun telefoon verbinden, en niet alleen vanaf.

Daar heb je inderdaad een héél goed punt.

Ik beheer een netwerk waar een Full BGP tabel geladen is, dat gaat over de 500.000 routes. Zo sturen wij als ISP al 31 routes uit, dat is er met IPv6 nog maar één.

Dat scheelt natuurlijk gigantisch veel routes waardoor verwerkingen in de routers met minder rekenkracht kan.

Maar dat is nog even toekomst muziek, want IPv4 gaat echt niet weg zijn over 10 jaar.

[Verwijderd]

axis schreef op vrijdag 24 juli 2009 @ 17:17:
[...]

Ingevuld..

Trouwens nog een tip voor mensen die professioneel bezig zijn met ipv6, schrijf je in op de ipv6 taskforce mailing list, komt interessante info voorbij.

@Booker, misschien kun je daar ook nog je onderzoekje spammen

Tnx voor de tip en het invullen

[Jaap-Jan]

@Booker: Je hebt een spelfoutje in de eerste vraag van je enquête: Developer/Programmeur/Web Designer.

Verder: Ik heb hem ook ingevuld. Nette enquête.

---

Verder, ik vind het wel opvallend hoe weinig consumentenrouters worden uitgerust met IPv6- support.
Één van de weinige is de D-Link DIR-825 (ook ondersteuning voor 6-to-4 en dus Sixxs), die op mijn verlanglijstje staat nu Ziggo de snelheden gaat verhogen en mijn WRT54G tegen zijn max. throughput aanloopt. Linksys heeft nog steeds niets laten horen en er zou sprake van zijn dat D-link zijn huidige line-up zou uitrusten met IPv6, maar daar blijft het ook angstvallig stil. Verder vind ik de AirPort Extreme met zijn €150,- redelijk prijzig en Cisco lijkt mij een beetje over-the-top voor een thuissituatie.

[ Voor 66% gewijzigd door Jaap-Jan op 27-07-2009 08:16 ]

[Equator]

Verwijderd schreef op vrijdag 24 juli 2009 @ 15:13:
Ik ben bezig met een onderzoek naar redenen die bedrijven hebben om niet te investeren in IPv6. Dit is in het kader van mijn bachelorscriptie aan de TU Delft.

Ik zou alle IT'ers op dit forum graag willen vragen om mijn enquete in te vullen, duurt maar 5 min en jullie mening is van belang in dit onderzoek! Ik zal de resultaten van het onderzoek posten in dit forum bij respons

Link: http://spreadsheets.googl...tc0FLRXA3bTc1NVhEZFE6MA..

TIA!!

De enquete ziet er goed uit, maar zou je in het vervolg daar eerst even toestemming voor willen vragen

Nu heeft dit 100% te maken met dit topic, dus heb ik er totaal geen problemen mee, maar we moeten ons wel een beetje aan de regels houden.

[8-Track]

Lorenzo Colitti, Network Engineer bij Google, praat over de uitrol van IPv6 bij Google en het beschikbaar maken van de verschillende services.

Quotes:

"IPv6 is another way of reaching Google services. If we can serve our users better over IPv6 than we can over IPv4 then we'll do it."

"We're committed to a good user experience and IPv6 will give us that when IPv4 addresses run out."

"For the moment we're catering to early adopters and trying to gain operational experience and trying to help other people gain operational experience by doing Google over IPv6."

"We basically went from zero to being able to serve most Google services over IPv6 to users that had good connectivity in a year and a half. Lots of progress can be made because it's not a huge undertaking."

"One of the best things you can do is tap into the enthusiasm that no doubt exists in your company. Look at the people who might be willing to do this, who might be excited about IPv6 and just let them do their thing."

[Verwijderd]

Equator schreef op maandag 27 juli 2009 @ 06:51:
[...]

[mbr]
De enquete ziet er goed uit, maar zou je in het vervolg daar eerst even toestemming voor willen vragen

Nu heeft dit 100% te maken met dit topic, dus heb ik er totaal geen problemen mee, maar we moeten ons wel een beetje aan de regels houden.[/mbr]

Sorry daarvoor! Ik zal volgende keer toestemming vragen

[Verwijderd]

Jaap-Jan schreef op maandag 27 juli 2009 @ 06:37:
@Booker: Je hebt een spelfoutje in de eerste vraag van je enquête: Developer/Programmeur/Web Designer.

Verder: Ik heb hem ook ingevuld. Nette enquête.

---

Verder, ik vind het wel opvallend hoe weinig consumentenrouters worden uitgerust met IPv6- support.
Één van de weinige is de D-Link DIR-825 (ook ondersteuning voor 6-to-4 en dus Sixxs), die op mijn verlanglijstje staat nu Ziggo de snelheden gaat verhogen en mijn WRT54G tegen zijn max. throughput aanloopt. Linksys heeft nog steeds niets laten horen en er zou sprake van zijn dat D-link zijn huidige line-up zou uitrusten met IPv6, maar daar blijft het ook angstvallig stil. Verder vind ik de AirPort Extreme met zijn €150,- redelijk prijzig en Cisco lijkt mij een beetje over-the-top voor een thuissituatie.

Tnx Jaap-Jan

[Verwijderd]

De IPv6 Task Force Nederland is van plan om dit jaar opnieuw de IPv6 Awards uit te reiken (http://awards.ipv6-taskforce.nl/).

Vorig jaar was het hele evenement afgeblazen omdat er te weinig animo voor was. Ik ben benieuwd welke impact die awards hebben op het gebruik van IPv6 in NL...denk persoonlijk dat het niet veel helpt...

[Verwijderd]

Verwijderd schreef op vrijdag 24 juli 2009 @ 15:13:
Ik ben bezig met een onderzoek naar redenen die bedrijven hebben om niet te investeren in IPv6. Dit is in het kader van mijn bachelorscriptie aan de TU Delft.

Ik zou alle IT'ers op dit forum graag willen vragen om mijn enquete in te vullen, duurt maar 5 min en jullie mening is van belang in dit onderzoek! Ik zal de resultaten van het onderzoek posten in dit forum bij respons

Link: http://spreadsheets.googl...tc0FLRXA3bTc1NVhEZFE6MA..

TIA!!

Ik zal de enquete moeten afronden op vrijdag 15 augustus, 23:59. Als iemand nog de enquete zou willen invullen, graag .

De link: http://spreadsheets.googl...tc0FLRXA3bTc1NVhEZFE6MA..

TIA

[n41r0j]

Heb een klein probleempje. Ik ben de laatste dagen bezig geweest met het opzetten van ipv6. Nu heb ik via SiXXs een tunnel lopen, en dit werkt allemaal op Win7. Nu kan ik pingen met 'ping -6 ipv6.google.com' , dat lukt gewoon, maar als ik dan met FF/Safari/IE naar ipv6.google.com ga, krijg ik geen verbinding. Hoe is dit op te lossen?

[CAPSLOCK2000]

Geen idee of dit voor jouw van toepassing is, maar er zijn nogal wat handleidingen op internet te vinden die beloven je browser sneller te maken en IPv6 uitschakelen.

Owja, check ook ff je firewall.

[boonie]

Jorian29 schreef op dinsdag 18 augustus 2009 @ 22:39:
Heb een klein probleempje. Ik ben de laatste dagen bezig geweest met het opzetten van ipv6. Nu heb ik via SiXXs een tunnel lopen, en dit werkt allemaal op Win7. Nu kan ik pingen met 'ping -6 ipv6.google.com' , dat lukt gewoon, maar als ik dan met FF/Safari/IE naar ipv6.google.com ga, krijg ik geen verbinding. Hoe is dit op te lossen?

Gebruik je toevallig NOD32? Dan even de-installeren en opnieuw installeren. In dat geval zal Opera wel gewoon werken maar IE en FF niet. Van Safari kan ik niets zeggen.

[axis]

Voor de geinteresseerden, nu Cisco voor zijn ASA lijn de 8.2 software uit heeft, ondersteunen ze ook ipv6 in de software (inclusief de ASDM, de gui).

Ik moet op onze colocation locaties nog upgraden voordat we de native ipv6 kunnen firewallen/routeren door een ASA, maar ik ben benieuwd.

Thuis heb ik ook een ASA met de 8.2 software, maar tweakdsl heeft nog geen native ipv6, dus ik kan er niets mee. De ASA kan geen ipv6ip tunnels termineren, nog doorlaten door PAT Dus thuis zit ik nog met een sixxs ayiya tunnel door de router heen.

[Verwijderd]

Hierbij de resultaten van de enquete over investeren in IPv6. Nogmaals bedankt dat ik de link op het forum mocht posten en dat ik zoveel respons heb gekregen

Link: http://www.scribd.com/doc...Pv6-Research-Report-FINAL

[CAPSLOCK2000]

Dank je wel, het ziet er interessant uit. Dat ga ik vanavond eens rustig doorlezen. Bedankt!

[Bl@ckbird]

axis schreef op dinsdag 01 september 2009 @ 10:29:
Voor de geinteresseerden, nu Cisco voor zijn ASA lijn de 8.2 software uit heeft, ondersteunen ze ook ipv6 in de software (inclusief de ASDM, de gui).

IPv6 zat al in de software in ieder geval sinds release 7.0.
Het is wel zo dat met elke nieuwe software release, er IPv4 features worden overgezet naar IPv6.
Zoals Transparent Firewall mode en IPv6 support voor de IPS modules.

[axis]

Bl@ckbird schreef op dinsdag 08 september 2009 @ 23:28:
[...]


IPv6 zat al in de software in ieder geval sinds release 7.0.
Het is wel zo dat met elke nieuwe software release, er IPv4 features worden overgezet naar IPv6.
Zoals Transparent Firewall mode en IPv6 support voor de IPS modules.

Weet ik, alleen nu ook in de ASDM, dus nu ook toegankelijk voor gui n00bs zoals ik..

[Verwijderd]

Op vrijdag 11 september was er een nieuws post over IPv6.
Omdat niemand comments leest in news item van gisteren, dacht ik hier de discussie verder te zetten.

Nogmaals: de kern van mijn betoog is: IPv6 biedt bijna geen voordelen over IPv4. En daarom willen ISPs niet betalen (tijd = geld) voor de implementatie van IPv6 in hun netwerken. Als IPv6 meer problemen had opgelost dan alleen de grote van adressen, dan was een nieuw protocol wel de moeite waard geweest.

Stef Nighthawk schreef:

>IPv6 kan IPsec en SSL beter implementeren dankzij de specifieke headers.

Dus IPSec en SSL werkt nu niet ? En wat malen gebruikers om een betere implementatie ?
Bovendien, naar mijn mening hoort security thuis in hogere layers, niet in de netwerk layer.
IPSec en SSL werken ongeveer hetzelfde in IPv4 en IPv6. Geen reden om over te stappen.

> IPv6 kan door het niet nodig zijn van NAT veel gemakkelijker end-to-end beveiligen.

En wat doet IPv6 dan allemaal aan beveiliging meer ? Niks.
Als je een eindgebruiker bent, dan wil je je netwerk beveiligen tegen ongewenste inkomende connecties. Dat doen ze nu met NAT. Als je een service binnen wilt opzetten, dan moet je een "gat prikken". Als je met IPv6 geen NAT gebruikt, moet je een firewall opzetten. Ik vertrouw PC software minder dan een router. Dus zal een IPv6 router degene zijn die binnenkomende connecties blokt. Als je een server wilt opzetten moet je dus je router configureren. Precies even veel werk.

> De summaries in IPv6 verbergen een pak meer host/netwerken dan die van IPv4.

Wat een onzin. Ja, in IPv4 kan de grootste summary maar 2^32 addresses sumnmarizen, en IPv6 2^128. Nou nou. In de praktijk maakt dat niks uit.

Het probleem is het aantal routes in de routingtabels in het midden van het Internet. En dat aantal kun je verminderen door te summarizen. Om te summarizen heb je 3 dingen nodig:
1) Authorities die hierarchisch addressen uitdelen. dat gebeurt bij IPv6 niet veel beter dan bij IPv4. Het zijn dezelfde regeltjes. Opgesteld door de regustries. Ze worden uitgedeeld naar administratieve normen. Niet naar technische normen. Ik geef toe, is niet makkelijk om beter te doen. Maar IPv6 biedt niks beters.
2) Als klanten van provider veranderen, breekt de hierarchie. Of ze moeten hernummeren. IPv6 biedt geen manieren om on-fhe-fly te hernummeren. On-the-fly betekent dat niemand hoeft te rebooten. Geen flag-days. TCP verbindingen zouden moeten blijven werken. Een ISP of een groot bedrijf zou moeten kunnen hernummeren zo vaak als het wil, zonder dat de eindgebruikers hier iets van merken.
IPv6 biedt hier niks meer dan IPv4. Resultaat: iedere keer dat een ISP of een bedrijf van "plaats" verandert in het Internet, worden de global routing tables iets groter. Na verloop van tijd zijn alle addressen "flat address space", en niks hierarchies.
3) Multihoming. Als een bedrijf connectivity wil via 2 ISPs, is hier niets voor geregeld in IPv4. Je zult je bedrijf's IP range moeten laten adverteren via beide ISPs. En er kan niet gesummarized worden. Iedere multihomed bedrijf krijgt zijn eigen prefix in de global routing tabel. IPv6 doet hier hetzelfde als IPv4. Gemiste kans. Als er een fatsoenlijke oplossing was voor multihoming in IPv6, dan was dat een grote reden voor de ISPs om om te gaan.

> Bij IPv6 mogen hosts meerdere adressen gebruiken waardoor zo defacto tot meerdere netwerken kunnen thuishoren.

In IPV4 kunnen hosts ook meerdere adressen gebruiken.
Om goede multihoming te doen, moet je weten welk source address je gebruikt, zodat return traffic een optimaal pad neemt. Niks voor geregeld in IPv6 (noch in IPv4). Als een van je providers down gaat, dan wil je automatisch alle traffic via de andere hebben. Werkt niet, omdat je IP addressen gebruikt van de ISPs die down is. Niks voor geregeld. Echt, multi-homing is een hack. Je kunt dit alleen oplossen door een echt andere "networking architecture" te gebruiken. Niet door alleen de addressspace uit te breiden en je header formaat anders te kleuren.

> on-the-fly re-addressing is geen probleem met IPv6.

Zie hierboven.
Readdressing is niet veel anders dan bij IPv4. Als Philips zegt "we gaan nu heel het bedrijf naar een andere range zetten", kan dat dan ? Nope. Gemiste kans. Is nodig om de global routing table onder controle te houden.

> Zo is de broadcast-ARP vervangen door de iet wat vriendelijkere neighbour discovery.

Oh ja. Dus eerst gaf het network interface een broadcast door naar de CPU. En de CPU zei: niet voor mij, weggooien. En nu krijgt het network interface een multicast, en denkt "he, discovery protocol, interessant" en geeft het aan de CPU. CPU denkt "niet voor mij" en gooit het weg. Peanuts.

Goed netwerk design is dat je je layer-2 netwerken niet al te groot maakt. Zelfs als je er bridges (switches) tussen zet, dan gaan zowel ARP als discovery packetjes overal doorheen. Maakt allemaal niks uit.

Als we het over multicast hebben, dan hebben we het over applicatie-level data streams die gemulticast worden. TV en zo. De verschillen tussen IPv4 en IPv6 zijn minimaal.
Bovendien wordt IP-multicast amper gebruikt. Zelfs na 15 jaar. (Ja, cisco begon zijn multicast implementatie in 1994). Ooit gehoord van Dino Farinnaci ? Multicast guru bij cisco. Hij zei: "als je minder dan 1000 or 10000 listeners hebt, dan heb je niks aan multicast, kan je net zo goed unicasten". Dat betekent voor mij dat multicast op het Internet dood is. (En Dino zei dat in 2000 of 2001).

Met andere woorden: multicast in IPv6 is niet veel beter dan in IPv4. En dus duidelijk geen reden om naar IPv6 over te stappen.

> Anycast adressen; iets waar ik echter nog niet mee gespeeld heb, maar het concept klinkt goed.

Fantastisch ! Een goed concept !
Maar wat betekent het voor de praktijk ? Wordt het gebruikt ? Welke services gebruiken het ? Wat is de verbetering voor ISPs en eindgebruikers ? Allemaal vaag. En dus weer geen reden om over te stappen.

Ik hou van nieuwe technologie. Ik hou van verbetering en vernieuwing. Maar IPv6 is geen verbetering. En het Internet is geen technologisch speeltje meer. En dus moeten er echte redenen zijn om alles op zijn kop te zetten.

> 15 jaar geleden, wel raar dat ik in Wikipedia terug vind dat dit pas vanaf eind 1998 door het IETF werd gedefinieerd.

Jij moet het opzoeken in Wikipedia. Ik was er bij.

Natuurlijk was het vanaf het begin duidelijk dat 4 miljard addressen niet genoeg was voor de hele wereld. Maar dat was ook niet de bedoeling. Pas eind jaren tachtig werd duidelijk dat IPv4 succesvoller was dan gedacht, en misschien langer mee zou gaan dan een phase in een research project. In 1991en 1992 werd het IP Next Generation project opgestart. Mensen konden nieuwe ideen aandragen. TUBA, Nimrod, het voorstel dat IPv6 werd, en nog een paar anderen. In 1994 werd gekozen voor wat nu IPv6 heet. Dat was 15 jaar geleden.

Ik zal je wat historie brengen.
Al in 1991-1994 begon het gedonder. Daarom zei ik dat IPv6 al meer dan 15 jaar een failure was.

In 1990-1995 was er een enorme boom in het Internet. In November 1988 werd het Internet geen puur research netwerk meer. In 1989 werd de oude Arpanet backbone vervangen door nieuwe, deels commerciele backbones (net het NSF net). in 1993 kwam het WWW. Tegen 1995 begonnen gewone mensen opeens te leren wat email was. Iedereen met een clue was bezig nieuwe protocollen te bouwen, scalable routing en routers te bouwen (CIDR, nieuwe forwarding technieken, scalable routing protocolen, etc).

Maar er was ook een groep mensen die de boot gemist hadden. Die niet voor Cisco of Fore werkten. Die wilden ook wat. Toen kwam IPng. Mensen met een clue waren bezig het Internet te laten groeien, en geld te verdienen. De losers hadden niks om handen. Dus gingen vooral de clueless lui aan de slag met IPng en IPv6. En juist die lui hadden geen idee van scalability. Ze hadden geen idee hoe netwerken te bouwen, en hoe software implementaties te bouwen. En dat zijn de roots van IPv6.

Er was een hoop politiek gekonkel. Technology is religion, after all. Iedereen die bezig was, liet IPng een beetje zitten. De politiek in de IETF heeft IPv6 er toen door gedrukt. IPv6 is een politiek protocol. Een hele boel technische problemen zijn toen niet opgelost. Omdat het of te moeilijk was. Of omdat alles "snel snel" moest. 15 jaar later is dat "snel snel" een beetje achterhaald.

Er waren twee redelijke alternatieven.
1) Een "snel snel" oplossing was TUBA. TCP and UDP with Bigger Addresses. Het was een voorstel om TCP en UDP boven op CLNP te laten draaien. CLNP was een OSI-developed netwerk protocol. Met addressen van 20 bytes. Cisco had het werken in 1994. De forwarding speed van CLNS op een cisco7000 (snelste cisco router toen) was net zo snel als IP forwarding speed. (Iets van 150k pps). TUBA werkte dus.

Maar CLNP was van OSI. En dus van de duivel. Voorstel neergeschoten. En de IETF zorgde er voor dat IPv6 16bytes addressen had, zodat 20 byte CLNP addressen er niet in pasten. Om alle CLNP gebruikers een hak te zetten.

Btw, imho, was CLNP een beter protocol toen, dan IPv6 nu is.

2) Ander alternatief: Nimrod. Zie rfc1753 bv.
Voorstel van een "crazy professor" Noel Chiappe. Zette de hele routing architecture op zijn kop. Maar werd niet serieus genomen, omdat het te "moeilijk" was.

Uiteindelijk werd IPv6 gekozen. Bracht alleen maar grotere address space. Heb je ooit gehoord van X.25 ? Was een netwerk technologie uit de jaren 70 en 80. In gebruik bij commerciele data netwerken bij telcos. Zwaar kut. Iemand had ooit gezegd: "als er een X.25 Next Generation project was geweest, dan waren ze niet met IPv4 gekomen. Dan hadden ze de X.25v2 met grotere sequence numbers".

Zie hier de historie waarom IPv6 een gemiste kans is. En waarom het technologies niet zo goed is als het had gekund. Zonder duidelijke verbetering is er geen reden om over te stappen. En dat is het hele probleem.

> En als je de implementatie bekijkt van de fabrikant van netwerkmateriaal, Operating systemen en applicaties dan zou ik denken dat men er zeker nog geen decennia mee bezig is.

Cisco's eerste IPv6 implementie is gedaan door Pedro Marques in de zomer van 1996. Dat was IPv6 forwarding, en RIPv6. Dat is dus 13 jaar geleden.
Nogmaals: 15 jaar IPv6 flop, daarmee bedoelde ik dat het hele process al 15 jaar niks is.

Je hebt het over betere implementaties. Dat zal allemaal best. Maar het neemt niet weg dat het betere implementaties zijn van een protocol dat niks nieuws brengt. Een gemiste kans. ISPs gaan nog steeds geen IPv6 implementeren. Omdat ze geen risico willen lopen als eerste te failen. Omdat ze geen geld/mankracht willen spenderen aan een converisie en het trainen van al hun personeel. Omdat er geen fatsoenlijke conversie is. (Behalve dual stack draaien).

> Je kritiek lijkt me er eentje uit onwetendheid.

Dank je wel. Je hebt geen idee tegen wie je praat. Maar ja, jou Wikipedia zal wel altijd gelijk hebben.

>Het zou me zelfs niet verbazen dat je het niet zou doorhebben als er applicaties op je PC gebruik zouden maken van IPv6.

Niet op mijn PC.
Niet op mijn router.
Zou knap zijn, voor IPv6 pakketjes om daar door te komen.

> De grootste hinder voor de implementatie van IPv6 wordt imho veroorzaakt door onwilige ISPs.

Ja, klote he. Terwijl jij weet waar je het over hebt. En die ISPs dus duidelijk niet. Tenslotte, jij hebt wikipedia gelezen, en thuis met 2 PCs en 2 routers gespeeld. En die ISPs hebben alleen maar netwerken gebouwd met honderden, duizenden router, en miljoenen gebruikers. Wat weten die ISPs nou ?

> Hoeveel zouden er eigenlijk beseffen dat hun routers al IPv6 ondersteunt?

Allemaal weten ze dat. Ben maar niet bang.
ISPs willen niet over naar IPv6 omdat ze weten wat dat betekent. Niet uit onwetendheid.
Als je denkt dat het alleen een kwestie is van nieuwe software laden en een nieuwe configuratie, dan heb je duidelijk nul benul wat het betekent om een groot commercieel netwerk te runnen.

Afijn, de tijd zal leren wie er gelijk heeft.
Tot dusverre, heb ik de laatste 15 jaar gewonnen.
Ik denk dat ik nog wel 5 jaar ga winnen. Misschien nog wel 10 jaar.

[CyBeR]

Verwijderd schreef op zaterdag 12 september 2009 @ 13:39:

> Zo is de broadcast-ARP vervangen door de iet wat vriendelijkere neighbour discovery.

Oh ja. Dus eerst gaf het network interface een broadcast door naar de CPU. En de CPU zei: niet voor mij, weggooien. En nu krijgt het network interface een multicast, en denkt "he, discovery protocol, interessant" en geeft het aan de CPU. CPU denkt "niet voor mij" en gooit het weg. Peanuts.

Goed netwerk design is dat je je layer-2 netwerken niet al te groot maakt. Zelfs als je er bridges (switches) tussen zet, dan gaan zowel ARP als discovery packetjes overal doorheen. Maakt allemaal niks uit.

En dit is dus pertinent onwaar. Het geval wil dat ik hier wat onderzoek naar heb gedaan, bij een organisatie waar de grote hoeveelheden ARPs in bepaalde gevallen zorgde dat aangesloten routers omvielen. Moderne NICs (en soortgelijk spul bij routers) programmeert de MAC chips zo dat alleen bepaalde MAC adressen doorkomen. Uiteraard die van de nic zelf (of die in het os geconfigureerd is), maar ook een aantal multicastadressen. Op het moment dat een multicast binnenkomt die daar niet onder valt kan de MAC chip al zeggen 'DROP'. De CPU merkt daar niets van. Dit kun je bij ARP niet doen zonder de nic ook complete ARP offloading te laten doen (wat sommige nics overigens inderdaad ook kunnen.)

[ Voor 5% gewijzigd door CyBeR op 12-09-2009 13:49 ]

[Verwijderd]

OK, ik zie in rfc4861 dat het neighbor discovery request gestuurd wordt naar een "gehashed" multicast address. Inderdaad, daarmee kun je er voor zorgen dat minder machines het request van de NIC naar de CPU moeten doorgeven. Je hebt gelijk.

Maar maakt dat wat uit ?
Als jij een netwerk designed met 1000 of meer hosts in een "broadcast domain", dan heb je een fout netwerk ge-designed. Als er een host op dat netwerk zit dat een groot aantal ND requests (of ARPs) per seconde uitzend, dan is dat een bug.
Neighbor discovery mag dan inderdaad een slimmere, meer gepolijste versie van ARP zijn. Maar is het de moeite waard om naar IPv6 over te gaan ? En in het bijzonder, is het de moeite waard voor grote ISPs ?

Nee dus.

[riddles]

Aan de hand van dit topic dacht ik toch ook eindelijk maar eens met IPv6 aan de slag te gaan. In plaats van een Sixxs tunnel, leek 6to4 me een mooier protocol. In plaats van een tunnel wordt dan met een Multicast adres (192.88.99.1) de dichtsbijzijnde tunnel provider opgezocht. Omdat noch mijn provider (Telfort), noch mijn router (ST716v5) enige ondersteuning voor IPv6 bieden, heb ik op mijn router protocol 41 geforward naar mijn Linux (CentOS 5.3) machine. Daarop heb ik netjes mijn 6to4 interface geconfigureerd (br0 is mijn ethernet device, omdat ik Xen instances draai - deze configuratie is voor Dom0):

code:

[root@wodan ~]# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.0.50
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
IPV6INIT=yes
IPV6TO4INIT=yes
IPV6TO4_IPV4ADDR=84.169.125.135

Alles komt mooi op verder. Echter, de eerste test is een ping. Dan gebeurt er iets heel raars:

code:

[root@host ~]# tcpdump -n -i br0 proto 41 or host 192.88.99.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
13:49:33.071771 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 0, length 64
13:49:33.118725 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 0, length 64
13:49:34.082392 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 1, length 64
13:49:34.129396 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 1, length 64
13:49:35.082348 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 2, length 64
13:49:35.130952 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 2, length 64
13:49:36.082347 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 3, length 64
13:49:36.131973 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 3, length 64
13:49:37.082341 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 4, length 64
13:49:37.131578 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 4, length 64

Het request dat ik uitstuur klopt en bevat netjes mijn publieke ipv4 adres (enigzins aangepast t.b.v. anonimiteit). Echter, de response die ik terugkrijg bevat mijn private IP adres (c0a8:32 = 192.168.0.50). Mijn host begrijpt hier niets van en negeert de pakketjes die terugkomen volkomen - ze hebben immers het verkeerde adres Van wat ik gelezen heb moet 6to4 achter een NAT gewoon werken. Het IPv4 verkeer wordt goed gerouteerd (en geNAT), ik krijg immers pakketjes terug. Waarom stuurt de 6to4 host aan de andere kant dan het foutieve adres terug? Waar halen ze dit vandaan? Heb ik iets fout geconfigureerd? Volgens mij verstuur ik het juiste request...

[CyBeR]

Verwijderd schreef op zaterdag 12 september 2009 @ 14:05:
Maar maakt dat wat uit ?
Als jij een netwerk designed met 1000 of meer hosts in een "broadcast domain", dan heb je een fout netwerk ge-designed. Als er een host op dat netwerk zit dat een groot aantal ND requests (of ARPs) per seconde uitzend, dan is dat een bug.

Je hebt dan helemaal gen fout netwerk gedesigned. Met IPv4 is 't niet aan te radan vanwege de grote hoeveelheid ARP die je dan krijgt, maar er zijn legio situaties waar 't gewoon niet anders kan. Elke IXP ter wereld bijvoorbeeld.

En IPv6 haalt dus weg dat dat een enorm probleem is. Met IPv6 kun je makkelijk duizenden hosts in een subnet proppen omdat dit probleem opeens niet meer bestaat.

Neighbor discovery mag dan inderdaad een slimmere, meer gepolijste versie van ARP zijn. Maar is het de moeite waard om naar IPv6 over te gaan ? En in het bijzonder, is het de moeite waard voor grote ISPs ?

Nee dus.

ND alleen is idd geen reden, nee. End-to-end addresseerbaarheid wel, evenals de aflopende hoeveelheid IPv4 adressen.

[Verwijderd]

Met IPv6 kun je makkelijk duizenden hosts in een subnet proppen omdat dit probleem opeens niet meer bestaat.

Je vergeet dan een paar dingen even voor het gemak.

1) De multicasts zullen, net als broadcasts, door all switches (bridges) en hubs gewoon overal naar toe worden gecopieerd. Inclusielf de discovery packetjes. De hosts zullen inderdaad iets minder cpu-cycles kwijt zijn aan het processen van ARPs. Maar de bandbreedte zal nog steeds gebruikt worden. Met duizenden hosts op een subnet zal dit weer langzaam oplopen naar onacceptable percentages. Slecht netwerk design imho.

2) Veel moeilijker troubleshooten.
Als je een probleem hebt, zoals duplicate IP addresses, dan is dat op een klein subnet veel makkelijker op te lossen dan op een groot subnet. Veel plezier op zoek bij twee duizend machines in een gebouw, op zoek naar een bepaald MAC address.

BTW, voor zover ik me kan herinneren, was ARP vooral een probleem in de jaren tachtig en vroege jaren negentig. ARP storms. Door foute implementaties en bugs konden hosts soms in een staat komen waar ze constant ARPs aan het zenden waren, waar andere hosts dan weer op reageerden. Door bugs dus. Wanneer iedereen naar IPv6 overstapt, zullen de nieuwe bugs in de nieuwe IPv6 implementaties weer boven water komen. En zullen deze problemen weer terug komen. (Tenzij je gelooft in de onfeilbaarheid van software. ) Het gaat dan een tijdje duren voor alle vendors hun bugs hebben gefixed, en alle gebruikers hun software hebben geupgrade. Dit soort problemen zijn de problemen waar ISPs bang voor zijn. Niet dat iets niet op te lossen valt. Maar ze kunnen zich nog herinneren hoe veel moeite het kost om alles te fixen en geupgrade te krijgen. Allemaal kosten waar geen enkele extra winst tegenover staat.

[CyBeR]

Verwijderd schreef op dinsdag 15 september 2009 @ 12:20:
[...]


Je vergeet dan een paar dingen even voor het gemak.

1) De multicasts zullen, net als broadcasts, door all switches (bridges) en hubs gewoon overal naar toe worden gecopieerd. Inclusielf de discovery packetjes. De hosts zullen inderdaad iets minder cpu-cycles kwijt zijn aan het processen van ARPs. Maar de bandbreedte zal nog steeds gebruikt worden. Met duizenden hosts op een subnet zal dit weer langzaam oplopen naar onacceptable percentages. Slecht netwerk design imho.

Is geen probleem hoor. Vroeger hadden we 10mbit netwerkjes (of minder). Op een gigabit netwerk kun je zo hard arpen als je wilt, het netwek zelf geeft er geen kik om. Een broadcast of multicast forwarden kost maar heel subtiel meer moeite voor een switch dan een unicast frame.

2) Veel moeilijker troubleshooten.
Als je een probleem hebt, zoals duplicate IP addresses, dan is dat op een klein subnet veel makkelijker op te lossen dan op een groot subnet. Veel plezier op zoek bij twee duizend machines in een gebouw, op zoek naar een bepaald MAC address.

code:

ProCurve Switch 4204vl# sh mac 001185-a2ec80

 Status and Counters - Address Table - 001185-a2ec80

  MAC Address : 001185-a2ec80
  Located on Port : B24

Heuj. Dat is juist makkelijker met IPv6 omdat 't mac-adres in het IP-adres verwerkt zit. Dit is een probleem dat je niet oplost met kleine subnetjes, want dat maakt die tweeduizend hosts niet minder. Dit probleem los je op met administratie.

BTW, voor zover ik me kan herinneren, was ARP vooral een probleem in de jaren tachtig en vroege jaren negentig. ARP storms. Door foute implementaties en bugs konden hosts soms in een staat komen waar ze constant ARPs aan het zenden waren, waar andere hosts dan weer op reageerden. Door bugs dus. Wanneer iedereen naar IPv6 overstapt, zullen de nieuwe bugs in de nieuwe IPv6 implementaties weer boven water komen. En zullen deze problemen weer terug komen. (Tenzij je gelooft in de onfeilbaarheid van software. ) Het gaat dan een tijdje duren voor alle vendors hun bugs hebben gefixed, en alle gebruikers hun software hebben geupgrade. Dit soort problemen zijn de problemen waar ISPs bang voor zijn. Niet dat iets niet op te lossen valt. Maar ze kunnen zich nog herinneren hoe veel moeite het kost om alles te fixen en geupgrade te krijgen. Allemaal kosten waar geen enkele extra winst tegenover staat.

Ik geloof niet inde onfaalbaarheid van software. Ik geloof ook dat er best bugjes zullen zitten in ND implementaties. Cisco maakt er bijvoorbeeld gewoon weer een potje van m.b.t. het programmeren van MAC chips (daar 10k ND's per seconde op afvuren geeft 't ding nog best wat te doen). Dat is hun probleem (en ze doen wel meer dingen fout, daar stoort ook niemand zich aan ) Maar verder bestaat IPv6 inmiddels al een jaar of 10 (meer geloof ik) en dat soort geintjes is er voor het grootste deel wel uitgehaald.

[CAPSLOCK2000]

riddles schreef op zondag 13 september 2009 @ 13:54:
Aan de hand van dit topic dacht ik toch ook eindelijk maar eens met IPv6 aan de slag te gaan. In plaats van een Sixxs tunnel, leek 6to4 me een mooier protocol. In plaats van een tunnel wordt dan met een Multicast adres (192.88.99.1)

Anycast om precies te zijn.

Het request dat ik uitstuur klopt en bevat netjes mijn publieke ipv4 adres (enigzins aangepast t.b.v. anonimiteit). Echter, de response die ik terugkrijg bevat mijn private IP adres (c0a8:32 = 192.168.0.50). Mijn host begrijpt hier niets van en negeert de pakketjes die terugkomen volkomen - ze hebben immers het verkeerde adres Van wat ik gelezen heb moet 6to4 achter een NAT gewoon werken. Het IPv4 verkeer wordt goed gerouteerd (en geNAT), ik krijg immers pakketjes terug. Waarom stuurt de 6to4 host aan de andere kant dan het foutieve adres terug? Waar halen ze dit vandaan? Heb ik iets fout geconfigureerd? Volgens mij verstuur ik het juiste request...

Ik denk dat de netwerkscriptjes van CentOS niet overweg kunnen met je NAT. Normaal gesproken wordt 6to4 gedaan op de machine met het externe IP.
Ik vraag me af of er misschien te veel geNAT wordt. Misschien kun je je NAT configuratie hier eens posten
(iptables -n -L -t nat).
Owja, en m'n glazen bol vraagt zich af wat die sit0 interface daar doet.

[HarmoniousVibe]

riddles schreef op zondag 13 september 2009 @ 13:54:
Aan de hand van dit topic dacht ik toch ook eindelijk maar eens met IPv6 aan de slag te gaan. In plaats van een Sixxs tunnel, leek 6to4 me een mooier protocol. In plaats van een tunnel wordt dan met een Multicast adres (192.88.99.1) de dichtsbijzijnde tunnel provider opgezocht. Omdat noch mijn provider (Telfort), noch mijn router (ST716v5) enige ondersteuning voor IPv6 bieden, heb ik op mijn router protocol 41 geforward naar mijn Linux (CentOS 5.3) machine. Daarop heb ik netjes mijn 6to4 interface geconfigureerd (br0 is mijn ethernet device, omdat ik Xen instances draai - deze configuratie is voor Dom0):

code:

[root@wodan ~]# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.0.50
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
IPV6INIT=yes
IPV6TO4INIT=yes
IPV6TO4_IPV4ADDR=84.169.125.135

Alles komt mooi op verder. Echter, de eerste test is een ping. Dan gebeurt er iets heel raars:

code:

[root@host ~]# tcpdump -n -i br0 proto 41 or host 192.88.99.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
13:49:33.071771 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 0, length 64
13:49:33.118725 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 0, length 64
13:49:34.082392 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 1, length 64
13:49:34.129396 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 1, length 64
13:49:35.082348 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 2, length 64
13:49:35.130952 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 2, length 64
13:49:36.082347 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 3, length 64
13:49:36.131973 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 3, length 64
13:49:37.082341 IP 192.168.0.50 > 192.88.99.1: IP6 2002:54a9:7d87::1 > 2001:660:3301:8061:290:27ff:feac:7980: ICMP6, echo request, seq 4, length 64
13:49:37.131578 IP 192.88.99.1 > 192.168.0.50: IP6 2001:660:3301:8061:290:27ff:feac:7980 > 2002:c0a8:32::1: ICMP6, echo reply, seq 4, length 64

Het request dat ik uitstuur klopt en bevat netjes mijn publieke ipv4 adres (enigzins aangepast t.b.v. anonimiteit). Echter, de response die ik terugkrijg bevat mijn private IP adres (c0a8:32 = 192.168.0.50). Mijn host begrijpt hier niets van en negeert de pakketjes die terugkomen volkomen - ze hebben immers het verkeerde adres Van wat ik gelezen heb moet 6to4 achter een NAT gewoon werken. Het IPv4 verkeer wordt goed gerouteerd (en geNAT), ik krijg immers pakketjes terug. Waarom stuurt de 6to4 host aan de andere kant dan het foutieve adres terug? Waar halen ze dit vandaan? Heb ik iets fout geconfigureerd? Volgens mij verstuur ik het juiste request...

6to4 ondersteunt alleen NAT transversal als je proto-41 forward naar je ipv6-node.

Zie ook deze tabel voor een handig overzicht: http://www.sixxs.net/faq/connectivity/?faq=comparison

edit: sorry niet goed gelezen dat je proto 41 al forward . Maar goed, de tabel is sowieso wel handig voor future reference

[CAPSLOCK2000]

LB06 schreef op dinsdag 15 september 2009 @ 15:02:
6to4 ondersteunt alleen NAT transversal als je proto-41 forward naar je ipv6-node.

Hij zegt dat hij dat doet, en aangezien er wel degelijk antwoorden arriveren op z'n host geloof ik dat ook.

[Mafketel]

riddles schreef op zondag 13 september 2009 @ 13:54:
[...]Echter, de response die ik terugkrijg bevat mijn private IP adres (c0a8:32 = 192.168.0.50).

Waarom gebruik je je modem niet als bridge en maak je een extra virtual router aan onder xen?

[Keiichi]

Ik heb een klein netwerk van eigen linux servers die met tunnels aan elkaar gelinkt zijn. Er word met verschillende distro's en verschillende kernels gebruik gemaakt. Een eigen tunnel broker staat er centraal in (Die hangt weer aan sixxs)

Hiermee ondervind ik rare problemen, zoals:
- Routes die opeens vergeten worden (Alles staat statisch ingesteld )
- Spontane route loop

Weet iemand zo snel of bepaalde linux kernels deze problemen hebben?

[CAPSLOCK2000]

Keiichi schreef op dinsdag 15 september 2009 @ 21:02:
Ik heb een klein netwerk van eigen linux servers die met tunnels aan elkaar gelinkt zijn. Er word met verschillende distro's en verschillende kernels gebruik gemaakt. Een eigen tunnel broker staat er centraal in (Die hangt weer aan sixxs)

Hiermee ondervind ik rare problemen, zoals:
- Routes die opeens vergeten worden (Alles staat statisch ingesteld )
- Spontane route loop

Weet iemand zo snel of bepaalde linux kernels deze problemen hebben?

ja, nee

Iets meer info graag.
Routes die spontaan vergeten worden daar geloof ik niet zo in. Het lijkt me een stuk waarschijnlijker dat je een stuk software hebt dat er aan zit te morrelen. Je hebt een tunnelbroker, dat lijkt me een goede kandidaat.

[riddles]

riddles schreef op zondag 13 september 2009 @ 13:54:Het request dat ik uitstuur klopt en bevat netjes mijn publieke ipv4 adres (enigzins aangepast t.b.v. anonimiteit). Echter, de response die ik terugkrijg bevat mijn private IP adres (c0a8:32 = 192.168.0.50). Mijn host begrijpt hier niets van en negeert de pakketjes die terugkomen volkomen - ze hebben immers het verkeerde adres Van wat ik gelezen heb moet 6to4 achter een NAT gewoon werken. Het IPv4 verkeer wordt goed gerouteerd (en geNAT), ik krijg immers pakketjes terug. Waarom stuurt de 6to4 host aan de andere kant dan het foutieve adres terug?

Uiteindelijk ben ik toch maar met Sixxs aan de slag gegaan. Met een bijna identieke configuratie werkt daar alles probleemloos. Ik configureer de tunnel en ping6 geeft direct antwoord. Ook routeren naar het aangevraagde subnet gaat goed. Ik heb zo'n vermoeden dat de fout zit bij de remote 6to4 node, maar dat is lastig aan te tonen. Voorlopig werkt alles perfect .

[CAPSLOCK2000]

riddles schreef op woensdag 16 september 2009 @ 14:26:
[...]

Uiteindelijk ben ik toch maar met Sixxs aan de slag gegaan. Met een bijna identieke configuratie werkt daar alles probleemloos. Ik configureer de tunnel en ping6 geeft direct antwoord. Ook routeren naar het aangevraagde subnet gaat goed. Ik heb zo'n vermoeden dat de fout zit bij de remote 6to4 node, maar dat is lastig aan te tonen. Voorlopig werkt alles perfect .

Fijn dat het werkt met sixxs.

Maar je 6to4 conclusie kan niet kloppen. Je interne netwerkadres lijkt namelijk zichtbaar voor de andere kant. Dat zou nooit moeten gebeuren.

[riddles]

CAPSLOCK2000 schreef op woensdag 16 september 2009 @ 15:52:
Fijn dat het werkt met sixxs.

Maar je 6to4 conclusie kan niet kloppen. Je interne netwerkadres lijkt namelijk zichtbaar voor de andere kant. Dat zou nooit moeten gebeuren.

Precies, maar waar dan? In de IPv4 header kan het niet zitten, dan zou het pakketje nooit teruggerouteerd kunnen worden. Volgens tcpdump is het IPv6 adres correct (extern IPv4 in 6to4 formaat). Tenzij er stiekem in het 6to4 protocol nog ergens een IP adres zit, heb ik geen idee. Ik heb al wat gegoogled over wat meer uitleg over het 6to4 protocol en packet formaat, maar heb weinig kunnen vinden.

[boonie]

Had je dit probleem met alle IP's die je pingt? Of was dit alleen met dit specifieke adres? Dat zou iets kunnen zeggen over waar je het zoeken moet.

[CAPSLOCK2000]

riddles schreef op woensdag 16 september 2009 @ 18:03:
[...]

Precies, maar waar dan? In de IPv4 header kan het niet zitten, dan zou het pakketje nooit teruggerouteerd kunnen worden. Volgens tcpdump is het IPv6 adres correct (extern IPv4 in 6to4 formaat). Tenzij er stiekem in het 6to4 protocol nog ergens een IP adres zit, heb ik geen idee. Ik heb al wat gegoogled over wat meer uitleg over het 6to4 protocol en packet formaat, maar heb weinig kunnen vinden.

Ik vraag me af of er niet iets te veel geNAT wordt. In 6to4 heb je inderdaad twee ip adressen.
6to4 (wat beter 6in4 genoemd had kunnen worden, maar die naam was al bezet) bestaat uit een "gewoon" ipv4 pakketje, met in de payload een "gewoon" ipv6 pakketje. Het IPv4 gedeelte brengt het pakketje tot aan de 6to4 router. Daar wordt het IPv6 pakketje er uit gehaald, en verder gestuurd. Het IPv6 pakketje kan dus in principe onzin bevatten, het wordt pas bij aankomst op het IPv6 netwerk geopend.
Het antwoord gaat via de omgekeerde route.

Het IPv4 gedeelte gaat zeker goed, anders zouden de (foutieve) antwoorden nooit op zijn machine aankomen.


Het zou dus mogelijk kunnen zijn dat er foute adressen in het IPv6 pakketje zitten. Maar volgens tcpdump hebben de uitgaande pakketjes wel degelijk een correct IPv6 adres. Het antwoord verwijst naar een intern adres, dus er moet iets gebeurd zijn binnen zijn netwerk. Buiten zijn netwerk is er niks dat kan raden wat zijn interne adres is. Het kan fout gaan bij het versturen of bij de ontvangst, maar ergens wordt er een IP adres vervangen. Dat is precies wat NAT doet, vandaar mijn vermoeden dat er iets te veel geNAT wordt.

@TS als je nog de behoefte voelt om het verder uit te zoeken moet je maar even DM'en, dan kun je mijn machine pingen en vertel ik je welke adressen ik zie, dan weten we of het fout gaat bij het versturen of het ontvangen.

[riddles]

Eerlijk gezegd niet zo heel veel behoefte meer om er nog dieper op in te gaan om het uit te zoeken. Ik kon weinig pagina's met voorbeelden en/of troubleshooting vinden voor een 6to4 met anycast config voor CentOS. Voor Sixxs kan ik meer dan genoeg vinden en is er een zeer bruikbaar forum op Sixxs ter ondertsteuning. Voorlopig draait het goed en is het afwachten op native ipv6 van een DSL of kabel provider (maar dat kan nog wel even duren ).

[XJos88]

Verwijderd schreef op zaterdag 12 september 2009 @ 13:39:

> 15 jaar geleden, wel raar dat ik in Wikipedia terug vind dat dit pas vanaf eind 1998 door het IETF werd gedefinieerd.

Jij moet het opzoeken in Wikipedia. Ik was er bij

In je profiel staat als geboortedatum: 22 juni 1984. Je was dus 10 toen je 'erbij was'. Okee, net 11 geworden.

> Je kritiek lijkt me er eentje uit onwetendheid.

Dank je wel. Je hebt geen idee tegen wie je praat. Maar ja, jou Wikipedia zal wel altijd gelijk hebben.

Nou, doe me versteld staan. wie ben je, en waarom zou ik je serieus nemen?

[Yen]

Verwijderd schreef op dinsdag 15 september 2009 @ 12:20:
[...]
2) Veel moeilijker troubleshooten.
Als je een probleem hebt, zoals duplicate IP addresses, dan is dat op een klein subnet veel makkelijker op te lossen dan op een groot subnet. Veel plezier op zoek bij twee duizend machines in een gebouw, op zoek naar een bepaald MAC address.

Met Neighbor Discovery mag dit geen probleem zijn

[JackBol]

Heeft er iemand ervaring met Hurricane Electric en Ziggo?

Ik heb sinds kort ziggo en probeer mijn tunnel om te zetten, maar omdat mijn WAN IP niet te pingen is vanaf internet pikt HE dat niet.


edit: btw. dat ping filter is iets van Ziggo, niet van mijn routertje.

[ Voor 16% gewijzigd door JackBol op 28-09-2009 20:04 ]

[JackBol]

Verwijderd schreef op dinsdag 15 september 2009 @ 12:20:
[...]
2) Veel moeilijker troubleshooten.
Als je een probleem hebt, zoals duplicate IP addresses, dan is dat op een klein subnet veel makkelijker op te lossen dan op een groot subnet. Veel plezier op zoek bij twee duizend machines in een gebouw, op zoek naar een bepaald MAC address.

Netwerkpoortje erbij zoeken in de CAM tabel, poortje in de patchadministratie opzoeken, naar de outlet lopen en de gebruiker slaan?

Ik had een heel betoog getypt om je grote anti-ipv6 post te ontkrachten, maar die heb ik perongeluk weggegooid.

Anyways, volgens mij heb jij geen enkele ervaring met netwerken op de betreffende schaal. Het komt me nogal over als een of ander principieel betoog gebaseerd op anti-ipv6 sentimenten. Ik zie IPv6 nochtans graag tegemoet.

[Uberprutser]

Verwijderd schreef op dinsdag 15 september 2009 @ 12:20:

1) De multicasts zullen, net als broadcasts, door all switches (bridges) en hubs gewoon overal naar toe worden gecopieerd. Inclusielf de discovery packetjes.

Dan bestaan er vast nog wel zaken zoals VLANnetejes en VTPjes om dat soort dingen op te vangen.

[ Voor 5% gewijzigd door Uberprutser op 28-09-2009 20:29 ]

[Keiichi]

Ballebek schreef op maandag 28 september 2009 @ 20:29:
[...]

Dan bestaan er vast nog wel zaken zoals VLANnetejes en VTPjes om dat soort dingen op te vangen.

Sowieso, aangezien VLANnetjes op L2 werken en IPv6 op L3 zit

[CyBeR]

_DH schreef op maandag 28 september 2009 @ 20:08:
[...]


Netwerkpoortje erbij zoeken in de CAM tabel, poortje in de patchadministratie opzoeken, naar de outlet lopen en de gebruiker slaan?

Ik had een heel betoog getypt om je grote anti-ipv6 post te ontkrachten, maar die heb ik perongeluk weggegooid.

Ik ook, maar mijn sentiment was op een gegeven moment meer 'ugh, laat ook maar'.

Ik zie IPv6 nochtans graag tegemoet.

Speaking of which...

[JackBol]

CyBeR schreef op maandag 28 september 2009 @ 20:55:
[...]
Speaking of which...

Daar werk ik helaas niet meer... Maar ik heb van insiders vernomen dat tdf via ipv6 beschikbaar was... Dat geeft de burger moet mbt. komend jaar...

[CyBeR]

_DH schreef op maandag 28 september 2009 @ 22:09:
[...]

Daar werk ik helaas niet meer... Maar ik heb van insiders vernomen dat tdf via ipv6 beschikbaar was... Dat geeft de burger moet mbt. komend jaar...

Ah, ok. tdf?

[Hooglander1]

Ik heb een aiccu tunnel geinstalleerd op Ubuntu en dat werkt prima, maar ik krijg het helaas niet voor elkaar om het automatisch te laten opstarten. Standaard zou het in een daemon moeten lopen, maar dat werkt dus niet. Tevens werkt aiccu zetten onder startup programs niet, waarom kan ik zelf als ik eerlijk ben niet vinden.

Mensen ervaring met aiccu onder Ubuntu en die het wel aan de praat hebben gekregen?

---

aiccu start in /etc/rc.local toevoegen did the trick.

Werkt hier nu dus prima.

[ Voor 10% gewijzigd door Hooglander1 op 05-10-2009 20:35 ]

[Snow_King]

Maar dat moet niet nodig zijn, dus wat je nu gedaan hebt is eigenlijk niet goed.

Als je met ps aux keek, draaide aiccu dan wel?

[Hooglander1]

in ps aux is niets te zien, in syslog:

code:

Oct  6 12:35:29 ruben-laptop aiccu: Succesfully retrieved tunnel information for T18272
Oct  6 12:35:29 ruben-laptop aiccu: AICCU running as PID 2459
Oct  6 12:35:29 ruben-laptop aiccu: [AYIYA-start] : Anything in Anything (draft-02)
Oct  6 12:35:29 ruben-laptop aiccu: [AYIYA-tun->tundev] : (Socket to TUN) started
Oct  6 12:35:29 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/sixxs, iface: sixxs)
Oct  6 12:35:29 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/sixxs, iface: sixxs): no ifupdown configuration found.
Oct  6 12:36:06 ruben-laptop wpa_supplicant[1022]: CTRL-EVENT-SCAN-RESULTS 
Oct  6 12:36:44 ruben-laptop console-kit-daemon[1033]: WARNING: Couldn't read /proc/1800/environ: Failed to open file '/proc/1800/environ': No such file or directory
Oct  6 12:36:45 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/sixxs, iface: sixxs)

en later nog:

code:

Oct  6 12:37:41 ruben-laptop aiccu: Couldn't resolve host tic.sixxs.net, service 3874
Oct  6 12:37:41 ruben-laptop aiccu: Couldn't connect to the TIC server tic.sixxs.net
Oct  6 12:37:41 ruben-laptop aiccu: Couldn't retrieve first tunnel for the above reason, aborting

Volgens mij start aiccu gewoon te vroeg in het hele opstartproces, wat ook kan blijken uit de volgende melding bij een install:

code:

ruben@ruben-laptop:~$ sudo apt-get install aiccu
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  aiccu
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/48.2kB of archives.
After this operation, 209kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously deselected package aiccu.
(Reading database ... 140793 files and directories currently installed.)
Unpacking aiccu (from .../aiccu_20070115-9_i386.deb) ...
Processing triggers for man-db ...
Processing triggers for sreadahead ...
Setting up aiccu (20070115-9) ...
update-rc.d: warning: aiccu start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (29 3 4 5)
update-rc.d: warning: aiccu stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (29 0 1 6)

ruben@ruben-laptop:~$

[Snow_King]

Oct 6 12:37:41 ruben-laptop aiccu: Couldn't resolve host tic.sixxs.net, service 3874
Oct 6 12:37:41 ruben-laptop aiccu: Couldn't connect to the TIC server tic.sixxs.net
Oct 6 12:37:41 ruben-laptop aiccu: Couldn't retrieve first tunnel for the above reason, aborting

Je hebt nog geen netwerk zodra AICCU start, heb je toevallig wireless thuis?

[Loekie]

Snow_King schreef op dinsdag 06 oktober 2009 @ 15:14:
Oct 6 12:37:41 ruben-laptop aiccu: Couldn't resolve host tic.sixxs.net, service 3874
Oct 6 12:37:41 ruben-laptop aiccu: Couldn't connect to the TIC server tic.sixxs.net
Oct 6 12:37:41 ruben-laptop aiccu: Couldn't retrieve first tunnel for the above reason, aborting

Je hebt nog geen netwerk zodra AICCU start, heb je toevallig wireless thuis?

Hier heb ik het zelfde met bedrade aansluiting, aiccu komt dan weer op na herstart van service.

[CAPSLOCK2000]

Hooglander1 schreef op dinsdag 06 oktober 2009 @ 12:45:
in ps aux is niets te zien, in syslog:

code:

Oct  6 12:35:29 ruben-laptop aiccu: Succesfully retrieved tunnel information for T18272
Oct  6 12:35:29 ruben-laptop aiccu: AICCU running as PID 2459
Oct  6 12:35:29 ruben-laptop aiccu: [AYIYA-start] : Anything in Anything (draft-02)
Oct  6 12:35:29 ruben-laptop aiccu: [AYIYA-tun->tundev] : (Socket to TUN) started
Oct  6 12:35:29 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/sixxs, iface: sixxs)
Oct  6 12:35:29 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/sixxs, iface: sixxs): no ifupdown configuration found.
Oct  6 12:36:06 ruben-laptop wpa_supplicant[1022]: CTRL-EVENT-SCAN-RESULTS 
Oct  6 12:36:44 ruben-laptop console-kit-daemon[1033]: WARNING: Couldn't read /proc/1800/environ: Failed to open file '/proc/1800/environ': No such file or directory
Oct  6 12:36:45 ruben-laptop NetworkManager:    SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/sixxs, iface: sixxs)

Hier zie ik niets dat echt vreemd is. NetworkManager ziet opeens een nieuwe netwerkverbiding, en pruttelt een beetje dat hij daar geen configuratie voor weet. Dat is niet erg want aiccu zorgt er voor.


en later nog:

code:

Oct  6 12:37:41 ruben-laptop aiccu: Couldn't resolve host tic.sixxs.net, service 3874
Oct  6 12:37:41 ruben-laptop aiccu: Couldn't connect to the TIC server tic.sixxs.net
Oct  6 12:37:41 ruben-laptop aiccu: Couldn't retrieve first tunnel for the above reason, aborting

Volgens mij start aiccu gewoon te vroeg in het hele opstartproces, wat ook kan blijken uit de volgende melding bij een install:

Daar lijkt het inderdaad op want DNS doet het nog niet.

code:

<knip>
update-rc.d: warning: aiccu start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (29 3 4 5)
update-rc.d: warning: aiccu stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (29 0 1 6)

He, die 29 is maar raar. Dat kan bijna niet kloppen en zou een prima verklaring zijn voor waarom dingen niet in de juiste volgorde worden uitgevoerd.

[Hooglander1]

maar goed, ik haal hem daar wel weg en stop hem in rc.local

[Loekie]

Ik heb bij Sixxs nu een tunnel lopen waar ik een subnet bij wil aanvragen zodat de tunnen naar m'n modem kan verplaatsen. Ik heb echter niet genoeg credits en heb een credit boost/loan aangevraagd en heb daar o.a. mijn linkedin-profiel bij genoemd voor extra credits. Iemand enig idee hoe lang zo'n request normaal gesproken duurt?

[boonie]

Laat die credits liggen en neem een tunnel bij hurricane electric (tunnelbroker.net). Die hebben een POP in Amsterdam. Je kunt een /48 of /64 krijgen. Wat je wil. Even registreren en je kunt meteen aanmaken wat je hebben wil.

Zelf heb ik een tunnel met een /64 die op mijn fritzbox (modem/router) "leeft" van hun. Dit werkt prima. De fritzbox heeft radvd aan boord en staat de prefix dus te broadcasten het lan op. De rest gaat vanzelf.

[Hooglander1]

Loekie schreef op woensdag 07 oktober 2009 @ 11:47:
Ik heb bij Sixxs nu een tunnel lopen waar ik een subnet bij wil aanvragen zodat de tunnen naar m'n modem kan verplaatsen. Ik heb echter niet genoeg credits en heb een credit boost/loan aangevraagd en heb daar o.a. mijn linkedin-profiel bij genoemd voor extra credits. Iemand enig idee hoe lang zo'n request normaal gesproken duurt?

Niet zo heel lang hoor, dat gaat vrij snel is mijn ervaring in ieder geval.

boonie schreef op woensdag 07 oktober 2009 @ 18:16:
Laat die credits liggen en neem een tunnel bij hurricane electric (tunnelbroker.net). Die hebben een POP in Amsterdam. Je kunt een /48 of /64 krijgen. Wat je wil. Even registreren en je kunt meteen aanmaken wat je hebben wil.

Zelf heb ik een tunnel met een /64 die op mijn fritzbox (modem/router) "leeft" van hun. Dit werkt prima. De fritzbox heeft radvd aan boord en staat de prefix dus te broadcasten het lan op. De rest gaat vanzelf.

Wat voor snelheden en pings haal je daaruit?

[Loekie]

boonie schreef op woensdag 07 oktober 2009 @ 18:16:
Laat die credits liggen en neem een tunnel bij hurricane electric (tunnelbroker.net). Die hebben een POP in Amsterdam. Je kunt een /48 of /64 krijgen. Wat je wil. Even registreren en je kunt meteen aanmaken wat je hebben wil.

Zelf heb ik een tunnel met een /64 die op mijn fritzbox (modem/router) "leeft" van hun. Dit werkt prima. De fritzbox heeft radvd aan boord en staat de prefix dus te broadcasten het lan op. De rest gaat vanzelf.

Tja, ik heb een 'standaard' fritzbox, zonder radvd dus. Standaard optie gaat alleen van sixx uit..
Zit nu al een dag of 3 te wachten op antwoord en gezien hun opmerkingen op de site vermoed ik dat mijn mail in hun spamfilter geland is.

[LauPro]

Verwijderd schreef op zaterdag 12 september 2009 @ 13:39:
Dus IPSec en SSL werkt nu niet ? En wat malen gebruikers om een betere implementatie ?
Bovendien, naar mijn mening hoort security thuis in hogere layers, niet in de netwerk layer.
IPSec en SSL werken ongeveer hetzelfde in IPv4 en IPv6. Geen reden om over te stappen.

Het gaat erom dat bestaande work-a-rounds eruit worden gewerkt. De implementatie van SSL bij IPv4 voor HTTP is uiterst zwak, voor elke host is bijvoorbeeld een apart IP nodig (zonder poort-hacks) die dus al zo schaars zijn.

Als je een eindgebruiker bent, dan wil je je netwerk beveiligen tegen ongewenste inkomende connecties. Dat doen ze nu met NAT. Als je een service binnen wilt opzetten, dan moet je een "gat prikken". Als je met IPv6 geen NAT gebruikt, moet je een firewall opzetten. Ik vertrouw PC software minder dan een router. Dus zal een IPv6 router degene zijn die binnenkomende connecties blokt. Als je een server wilt opzetten moet je dus je router configureren. Precies even veel werk.

Dit is gewoon lariekoek. Een goede IPv6 router zal ook verbindingen van buitenaf niet accepteren, nat is gewoon een farce als je dit als 'firewall' beschouwd. De mogelijkheden voor een IPv6-firewall zijn dan ook veel groter.

2) Als klanten van provider veranderen, breekt de hierarchie. Of ze moeten hernummeren. IPv6 biedt geen manieren om on-fhe-fly te hernummeren. On-the-fly betekent dat niemand hoeft te rebooten. Geen flag-days. TCP verbindingen zouden moeten blijven werken. Een ISP of een groot bedrijf zou moeten kunnen hernummeren zo vaak als het wil, zonder dat de eindgebruikers hier iets van merken.

Waar baseer je dit op? Juist bij IPv6 wil men een strenger geografisch georiënteerd ip-adresuitgiftebeleid uitvoeren. Organisaties die verhuizen krijgen een nieuwe range en zullen die over moeten zetten. Dat is overigens met IPv6 geen enkel probleem want het IP-adres is gebaseerd op het Mac-adres. Met het aanpassen van de router kan je in 1 keer een hele range porteren. Met een simpele forward kan je bestaand verkeer doorsturen, dit is met een paar commando's te doen terwijl je nu nog hele tunnels op moet zetten.

3) Multihoming. Als een bedrijf connectivity wil via 2 ISPs, is hier niets voor geregeld in IPv4. Je zult je bedrijf's IP range moeten laten adverteren via beide ISPs. En er kan niet gesummarized worden. Iedere multihomed bedrijf krijgt zijn eigen prefix in de global routing tabel. IPv6 doet hier hetzelfde als IPv4. Gemiste kans. Als er een fatsoenlijke oplossing was voor multihoming in IPv6, dan was dat een grote reden voor de ISPs om om te gaan.

Wat je nu voorstelt ondermijnt het hele concept van multihoming. Juist door spreiding aan te brengen in je netwerk creëer je redundantie. Als er dan een SPOF ontstaat gooi je die weg. Als je zo nodig toch naar buiten toe wil kunnen kletsen over 1 IP dan zul je een VPN op moeten zetten waarbij je intern de traffic over 2 verbindingen routeert.

Werkt niet, omdat je IP addressen gebruikt van de ISPs die down is. Niks voor geregeld. Echt, multi-homing is een hack. Je kunt dit alleen oplossen door een echt andere "networking architecture" te gebruiken. Niet door alleen de addressspace uit te breiden en je header formaat anders te kleuren.

Kwestie van goede routing instellen? Dit heeft meer te maken met de implementatie op het OS zelf, ik heb implementaties gezien waarbij men dmv een ping op de gateway checkt of een gateway nog up is en deze derhalve gebruikt kan worden voor routing. Het probleem is o.a. in de Linux-kernel dat men dergelijke userspace-gerelateerde zaken liever niet in de kernel ziet, kwestie van tijd.

Is nodig om de global routing table onder controle te houden.

Zoals gesteld loop je nu echt te blaten want hier is gewoon rekening mee gehouden, juist door het simplificeren van uitgifte van adressen.

Als we het over multicast hebben, dan hebben we het over applicatie-level data streams die gemulticast worden. TV en zo. De verschillen tussen IPv4 en IPv6 zijn minimaal.
Bovendien wordt IP-multicast amper gebruikt. Zelfs na 15 jaar. (Ja, cisco begon zijn multicast implementatie in 1994). Ooit gehoord van Dino Farinnaci ? Multicast guru bij cisco. Hij zei: "als je minder dan 1000 or 10000 listeners hebt, dan heb je niks aan multicast, kan je net zo goed unicasten". Dat betekent voor mij dat multicast op het Internet dood is. (En Dino zei dat in 2000 of 2001).

Multicast kan en gaat prima werken. Op onze klassieke coaxkabel is al een gedeelte van de bandbreedte gereserveerd voor de (hd)tv uitzendingen. Straks krijgen we een glasvezel waar een gedeelte van de bandbreedte gereserveerd zal zijn dmv multicast voor dergelijke uitzendingen. En bij providers die miljoenen abonnees hebben is multicast wel degelijk een goede oplossing. Wat denk je hoeveel werk het kost om nu al die zenders (per regio) te transmitten door de kabel?

Met andere woorden: multicast in IPv6 is niet veel beter dan in IPv4. En dus duidelijk geen reden om naar IPv6 over te stappen.

Nee, want IPv4 zuigt door de slechte geografische verdeling en is derhalve niet geschikt om fatsoenlijk mee te multicasten op landelijk niveau. Multicast op IPv4 is enkel binnen grote subnets bruikbaar.

Fantastisch ! Een goed concept !
Maar wat betekent het voor de praktijk ? Wordt het gebruikt ? Welke services gebruiken het ? Wat is de verbetering voor ISPs en eindgebruikers ? Allemaal vaag. En dus weer geen reden om over te stappen.

Ga je het nu afschieten op 1 onderdeel? Misschien een hint, het wordt o.a. voor DNS-rootservers gebruikt.

Ik hou van nieuwe technologie. Ik hou van verbetering en vernieuwing. Maar IPv6 is geen verbetering. En het Internet is geen technologisch speeltje meer. En dus moeten er echte redenen zijn om alles op zijn kop te zetten.

Je loopt hier gewoon te bashen op een vernieuwing die noodzakelijk is. Door je IPv4-bril zie je allemaal beren op de weg die bij IPv6 niet meer bestaan of anders zijn opgelost.

Er waren twee redelijke alternatieven.
1) Een "snel snel" oplossing was TUBA. TCP and UDP with Bigger Addresses.

Wat denk je zelf? Een work-a-round die ook nog eens volledig incompatibel is met bestaande systemen?

Het was een voorstel om TCP en UDP boven op CLNP te laten draaien. CLNP was een OSI-developed netwerk protocol. Met addressen van 20 bytes. Cisco had het werken in 1994. De forwarding speed van CLNS op een cisco7000 (snelste cisco router toen) was net zo snel als IP forwarding speed. (Iets van 150k pps). TUBA werkte dus.

Wat je nu allemaal noemt zou ook weer een compleet incompatibel systeem opleveren wat ook nog eens gebaseerd is op hacks en waar verder geen verbeteringen in zitten voor andere prangende problemen. Zo ga je volledig voorbij aan de grote routing issues die je gaat krijgen. Verder geef je misschien ook de technische (on)haalbaarheid aan, als toen de snelste routert het net aan kon...

2) Ander alternatief: Nimrod. Zie rfc1753 bv.
Voorstel van een "crazy professor" Noel Chiappe. Zette de hele routing architecture op zijn kop. Maar werd niet serieus genomen, omdat het te "moeilijk" was.

Dus waar wil je voor pleiten? Dat alle ervaring die is opgedaan met IPv4 meteen maar opzij werd gezet? Ik denk juist dat het wenselijk is dat er nog bepaalde overeenkomsten zijn voordat je weer in een testfase komt.

daarmee bedoelde ik dat het hele process al 15 jaar niks is.

Tja, zoals je zelf al wel stellig weet te brengen zal men niet overstappen zolang er geen noodzaak is. Zolang er dus voldoende IPv4-adressen zijn zullen partijen niet overstappen. Je kan ook stellen dat het in 15 jaar tijd helemaal uitgewerkt zodat de overgang straks vlekkeloos verloopt. Zal misschien de eerste grote transitie in de IT-wereld zijn die wel vlekkeloos verloopt....

Niet op mijn PC.
Niet op mijn router.
Zou knap zijn, voor IPv6 pakketjes om daar door te komen.

Ik weet niet welk OS je draait, maar elk modern OS doet out of the box IPv6. En in 2004 was er op Megabit bijvoorbeeld al native IPv6 connectiviteit. Destijds moest je dat in Windows XP alleen even activeren, inmiddels staat het default aan.

Ja, klote he. Terwijl jij weet waar je het over hebt. En die ISPs dus duidelijk niet. Tenslotte, jij hebt wikipedia gelezen, en thuis met 2 PCs en 2 routers gespeeld. En die ISPs hebben alleen maar netwerken gebouwd met honderden, duizenden router, en miljoenen gebruikers. Wat weten die ISPs nou ?

Die ISP's weten geen drol. Die werken met bestaande technologie en als er geen noodzaak is zullen ze zich (op een paar uitzonderingen na) niet wagen te experimenten.

Ik denk dat ik nog wel 5 jaar ga winnen. Misschien nog wel 10 jaar.

Droom lekker veder, IPv6 is bij verschillende grote partijen al zeker meer dan 5 jaar actief in gebruik. Sommige IX's werken intern al op IPv6 omdat anders de routering niet te botvieren valt.

Ik zou zeggen vanuit de EU: Zo snel mogelijk IPv6-implementatie op mobiele telefoons verplichten! Je wil niet weten hoe snel IPv6 dan uitgerold gaat worden.

[boonie]

Wat voor snelheden en pings haal je daaruit?

De snelheid is net onder mijn DSL topsnelheid als ik met meerdere lijntjes aan een newsserver hang. Niets te klagen dus. Dit zal verklaard kunnen worden door de extra overhead van het tunnelen.

De ping tijd op IPv4 is hier minimaal 36 ms
De ping tijd op IPv6 is hier minimaal 37 ms

Ik sta er zelf van te kijken. Het blijkt maar 1 milliseconde te schelen. Hurricane is dus ook prima wat dit betreft.

Voor alle duidelijkheid: Ik heb Freetz op mijn Fritzbox geïnstalleerd. Maar ook op een linksys wrt54g heb ik het werkend gehad. Ook deze zette de tunnel netjes op en had radvd aan boord om de netwerk prefix te broadcasten.

Wat trekt jullie aan sixxs? Het credit systeem vind ik niet prettig en de beheerders zijn ook niet erg sympathiek.

[Osiris]

boonie schreef op donderdag 08 oktober 2009 @ 08:07:
[...]

Wat trekt jullie aan sixxs? Het credit systeem vind ik niet prettig en de beheerders zijn ook niet erg sympathiek.

Toentertijd kwam Sixxs gewoon wat 'officieler'/geregelder over. Ff een webformpje invullen en binnen 5 minuten een tunnel krijgen, leek zo, tja, Hokkie-Tokkie-achtig ofzo

En volgens mij is maar één van die beheerders een beetje onsympathiek en we weten allemaal wie ik dan bedoel geloof ik

[axis]

Osiris schreef op donderdag 08 oktober 2009 @ 08:26:
[...]

Toentertijd kwam Sixxs gewoon wat 'officieler'/geregelder over. Ff een webformpje invullen en binnen 5 minuten een tunnel krijgen, leek zo, tja, Hokkie-Tokkie-achtig ofzo

En volgens mij is maar één van die beheerders een beetje onsympathiek en we weten allemaal wie ik dan bedoel geloof ik

Ik respecteer die dude wel ('t is en blijft een guru natuurlijk), maar ik heb al tien keer eerder mezelf tegengehouden een topic te openen op dat forum, omdat het toch geen nut heeft. Jeroen bekt je toch gewoon af en sluit je topic, hoeveel werk je er ook in steekt..

Voor de mensen die dachten dat we hiet op GoT soms streng zijn...

[CyBeR]

boonie schreef op donderdag 08 oktober 2009 @ 08:07:
[...]

Wat trekt jullie aan sixxs? Het credit systeem vind ik niet prettig en de beheerders zijn ook niet erg sympathiek.

Het sixxs systeem is stabiel en snel, en omdat 't fatsoenlijk en creditabel is zijn de adressen niet al per definitie overal geblacklist.

[Loekie]

axis schreef op donderdag 08 oktober 2009 @ 14:21:
[...]

Ik respecteer die dude wel ('t is en blijft een guru natuurlijk), maar ik heb al tien keer eerder mezelf tegengehouden een topic te openen op dat forum, omdat het toch geen nut heeft. Jeroen bekt je toch gewoon af en sluit je topic, hoeveel werk je er ook in steekt..

Voor de mensen die dachten dat we hiet op GoT soms streng zijn...

Hij verwijst je graag naar FAQ heb ik gemerkt en als je dan een credit-verzoek doet(stom zelf wat dingen geprobeert, out of credits dus) duurt het enorm lang voordat je iets hoort. Ik durf nu dus ook niet te zeggen of ze m'n mail ontvangen hebben of juist niet.
Ik kijk het nog een dag aan en dan mail ik wel weer oid..

[Keiichi]

axis schreef op donderdag 08 oktober 2009 @ 14:21:
[...]
Jeroen bekt je toch gewoon af en sluit je topic, hoeveel werk je er ook in steekt..

Voordat ik jou post las, had ik het geraden.

[axis]

CyBeR schreef op donderdag 08 oktober 2009 @ 14:40:
[...]
Het sixxs systeem is stabiel en snel, en omdat 't fatsoenlijk en creditabel is zijn de adressen niet al per definitie overal geblacklist.

Laatst lag de surfnet pop er een paar dagen (!) uit, en o wee als je durfde te vragen wat de status was.. "je merkt het wel" was zijn enige antwoord. Natuurlijk snap ik ook wel dat het niet zijn verantwoordelijkheid is om te communiceren hoe een niet-supported service ervoor staat bij een van zijn partners (pop is van surfnet, heeft sixxs weinige mee van doen neem ik aan), zou enige communicatie dan toch wel fijn zijn.

Ondertussen stonden al onze bellen 3 dagen te rinkelen in onze monitoringsystemen omdat die tunnels overal plat lagen (en ik wilde ook geen andere tunnel kiezen, omdat sommige van onze ip's hier gebruikt worden voor semi-test doeleinden). Irritante is dat je dan ook niet weet waar je aan toe bent. Is het iets kleins dat een uurtje duurt? Is er een datacenter uitgebrand?

[CyBeR]

axis schreef op donderdag 08 oktober 2009 @ 17:13:
[...]

Laatst lag de surfnet pop er een paar dagen (!) uit, en o wee als je durfde te vragen wat de status was.. "je merkt het wel" was zijn enige antwoord. Natuurlijk snap ik ook wel dat het niet zijn verantwoordelijkheid is om te communiceren hoe een niet-supported service ervoor staat bij een van zijn partners (pop is van surfnet, heeft sixxs weinige mee van doen neem ik aan), zou enige communicatie dan toch wel fijn zijn.

Ondertussen stonden al onze bellen 3 dagen te rinkelen in onze monitoringsystemen omdat die tunnels overal plat lagen (en ik wilde ook geen andere tunnel kiezen, omdat sommige van onze ip's hier gebruikt worden voor semi-test doeleinden). Irritante is dat je dan ook niet weet waar je aan toe bent. Is het iets kleins dat een uurtje duurt? Is er een datacenter uitgebrand?

Euh, sixxs is volgens mij ook niet bedoeld om je hele bedrijfsinfra op te zetten. En zal zeker de SURFNet-pop niet. Als je een SURFnetaansluiting hebt kun je van SURF native IPv6 krijgen.

Ik heb m'n servers ook niet aan sixxs hangen. Die hebben gewoon native ipv6 connectiviteit.

[ Voor 4% gewijzigd door CyBeR op 08-10-2009 17:28 ]

[axis]

CyBeR schreef op donderdag 08 oktober 2009 @ 17:27:
[...]


Euh, sixxs is volgens mij ook niet bedoeld om je hele bedrijfsinfra op te zetten. En zal zeker de SURFNet-pop niet. Als je een SURFnetaansluiting hebt kun je van SURF native IPv6 krijgen.

Ik heb m'n servers ook niet aan sixxs hangen. Die hebben gewoon native ipv6 connectiviteit.

Nee klopt, de datacenters waar we onze servers hebben hangen hebben ook native ipv6, alleen ons kantoor nog niet, die hangt nog met een sixxs tunneltje aan het net (ziggo zakelijk fiber, laatste keer dat ik die belde vertelde een dame van mijn account management team me doodleuk dat ze nog nooit van ip-v6-dinges had gehoord. Naja, we krijgen daar veel voor weinig en zitten nog even aan contract vast)

[HarmoniousVibe]

CyBeR schreef op donderdag 08 oktober 2009 @ 17:27:
[...]


Euh, sixxs is volgens mij ook niet bedoeld om je hele bedrijfsinfra op te zetten. En zal zeker de SURFNet-pop niet. Als je een SURFnetaansluiting hebt kun je van SURF native IPv6 krijgen.

Ik heb m'n servers ook niet aan sixxs hangen. Die hebben gewoon native ipv6 connectiviteit.

Niet alle surfnetaansluitingen. Anders zou er ook geen Surfnet PoP meer zijn volgens mij. Ik kan in ieder geval geen native ipv6 krijgen omdat de UvT het niet ondersteunt. De infrastructuur is wel ipv6 ready maar het is nog niet uitgerold. Waarom niet weet ik zo niet meer.

[Osiris]

Keiichi schreef op donderdag 08 oktober 2009 @ 15:49:
[...]


Voordat ik jou post las, had ik het geraden.

Osiris schreef op donderdag 08 oktober 2009 @ 08:26:
[...]

(...) en we weten allemaal wie ik dan bedoel geloof ik

[CyBeR]

LB06 schreef op donderdag 08 oktober 2009 @ 21:41:
[...]

Niet alle surfnetaansluitingen. Anders zou er ook geen Surfnet PoP meer zijn volgens mij. Ik kan in ieder geval geen native ipv6 krijgen omdat de UvT het niet ondersteunt. De infrastructuur is wel ipv6 ready maar het is nog niet uitgerold. Waarom niet weet ik zo niet meer.

Die SURFnet-pop bestaat om twee redenen:

• SURFnet-gelicenceerden die thuis een IPv6 tunnel willen (dus medewerkers of studenten van een SURFnet-aangesloten instelling)
• SURFnet-gebruikers die geen IPv6 kunnen hebben omdat hun instelling dat niet ondersteunt. Bijvoorbeeld zoals jij.

SURFnet kan aan de UvT echter prima een IPv6-verbinding leveren. Het complete SURFnet-netwerk is dual-stack namelijk. Dat de UvT het niet ondersteunt is iets anders, maar als je in de situatie zit waarin axis zich in bevindt dan is 't waarschijnlijk dat dat geen drempel is.

[Equator]

Modbreak:

Heren,
Alhoewel de discussie er af en toe stevig aan toe gaat, wil ik wel dat we netjes tegen elkaar blijven. Zonder daadwerkelijk elkaar te kennen, weten jullie niet wat voor ervaring de ander heeft. Blijf dus a.u.b. een beetje respect houden voor elkaar.

[Skinkie]

Het lijkt er op dat GeenStijl.nl meer visie heeft dan Tweakers.net op techie gebied Hulde!

PING geenstijl.nl(2a00:d00:ff:131:94:228:131:131) 56 data bytes
64 bytes from 2a00:d00:ff:131:94:228:131:131: icmp_seq=1 ttl=58 time=19.7 ms

[CyBeR]

Skinkie schreef op vrijdag 09 oktober 2009 @ 13:22:
Het lijkt er op dat GeenStijl.nl meer visie heeft dan Tweakers.net op techie gebied Hulde!

PING geenstijl.nl(2a00:d00:ff:131:94:228:131:131) 56 data bytes
64 bytes from 2a00:d00:ff:131:94:228:131:131: icmp_seq=1 ttl=58 time=19.7 ms

Het probleem is meer dat True gewoon geen IPv6 doet op dit moment.

[Skinkie]

CyBeR schreef op vrijdag 09 oktober 2009 @ 13:28:
[...]


Het probleem is meer dat True gewoon geen IPv6 doet op dit moment.

Dan zou True ook geen nieuwe IPv4-reeksen meer krijgen. Onwaarschijnlijk

En tevens is tunnelen geen enkel probleem

[CyBeR]

Skinkie schreef op vrijdag 09 oktober 2009 @ 13:47:
[...]

Dan zou True ook geen nieuwe IPv4-reeksen meer krijgen. Onwaarschijnlijk

True heeft wel IPv6 subnets en ze hebben 't vroeger ook wel gedaan, maar het daadwerkelijk routen ervan zijn ze mee gestopt. Of ze moeten er zeer recent weer mee begonnen zijn..

En tevens is tunnelen geen enkel probleem

Euh, dat is dus wel een probleem.

[Skinkie]

CyBeR schreef op vrijdag 09 oktober 2009 @ 13:54:
True heeft wel IPv6 subnets en ze hebben 't vroeger ook wel gedaan, maar het daadwerkelijk routen ervan zijn ze mee gestopt. Of ze moeten er zeer recent weer mee begonnen zijn..

Categorie prutsers dus?

Euh, dat is dus wel een probleem.

Geenstijl draait via een IPv6 proxy dus geen probleem

[CyBeR]

Skinkie schreef op vrijdag 09 oktober 2009 @ 14:01:
[...]

Categorie prutsers dus?

Ze vinden 't op dit moment nog niet belangrijk.

Geenstijl draait via een IPv6 proxy dus geen probleem

Daar kwam ik ook net achter. Wel een beetje nep imo

[Skinkie]

CyBeR schreef op vrijdag 09 oktober 2009 @ 14:24:
Daar kwam ik ook net achter. Wel een beetje nep imo

Even nep als NAT overigens met een typische direct routing infra hoeft het een proxy IPv6->v4 niet eens zo'n slecht idee te zijn.

[CyBeR]

Skinkie schreef op vrijdag 09 oktober 2009 @ 18:53:
[...]

Even nep als NAT overigens met een typische direct routing infra hoeft het een proxy IPv6->v4 niet eens zo'n slecht idee te zijn.

Dit is niet typisch, dit is een isp (Prolocation) die een ipv6 reverse-proxy heeft die je kunt gebruiken om je site ipv6-bereikbaar te maken. Het is niet de isp van geenstijl (NetHolding). Geen idee waarom ze 't gebruiken dus.

[Olaf van der Spek]

CyBeR schreef op vrijdag 09 oktober 2009 @ 13:28:
Het probleem is meer dat True gewoon geen IPv6 doet op dit moment.

Waarom niet?

Skinkie schreef op vrijdag 09 oktober 2009 @ 18:53:
Even nep als NAT

Het concept van NAT is eigenlijk helemaal niet zo nep, de huidige implementatie mist alleen een belangrijk deel.

[ Voor 39% gewijzigd door Olaf van der Spek op 10-10-2009 15:19 ]

[TrailBlazer]

Ik ben ook ipv6 weer eens aan het aanslingeren. ik kan www.ipv6.org prima pingen. IRC op ipv6 gaat ook prima alleen websites op ipv6 werken niet vanaf mijn windows XP machine. Ik zie in wireshark de SYN, SYN ACK en ACK tussen mijn PC en de server plaatsvinden alleen dan blijft het stil vanaf de andere kant. Het lijkt een MTU probleem alleen ik zie nergens iets raars staan.
Tunnel provider is hurricane

net nog even geprobeerd via mijn andere tunnel en subnet van sixxs en dan werkt het ook niet . Snap er niks van. Ik heb nog even gekeken op mijn linux bak met tcpdump op de tunnel interfaces en daar zie ik het pakket naar buiten gaan alleen never een reactie.

[ Voor 33% gewijzigd door TrailBlazer op 11-10-2009 20:18 ]

[Olaf van der Spek]

TrailBlazer schreef op zondag 11 oktober 2009 @ 19:40:
Ik zie in wireshark de SYN, SYN ACK en ACK tussen mijn PC en de server plaatsvinden alleen dan blijft het stil vanaf de andere kant.

Eh, dan ben jij toch aan zet en moet je het HTTP request versturen?

[TrailBlazer]

kan best maar waarom doe ik dat niet dan. Zowel firefox and ie doen het in ieder geval niet. Morgen wel even een linux live cdtje erin proppen kijken of die het wel doet.


had nog een live cdtje liggen en die werkt uiteraard wel gewoon direct. Morgen IPv6 op XP maar eens reinstallen.

[ Voor 25% gewijzigd door TrailBlazer op 11-10-2009 21:37 ]

[boonie]

Laat me raden... Je gebruikt NOD32? Even de-installeren en weer opnieuw installeren en het feest kan beginnen.

Overigens zou Opera wel goed werken. IE en FF niet.

Als het niet NOD32 mocht zijn dan gooi eerst maar eens de andere beveiligingspakketten van je PC

[TrailBlazer]

NOD32 staat er inderdaad op. Is wel de PC van mijn werk dus even erafgooien is niet echt een optie. Ik kan in ieder geval weer even verder thx

[TrailBlazer]

nod32 naar versie 4 geupgrade en nu werkt wel alles goed.

[boonie]

Goed te horen dat het dat inderdaad was. Ik had precies hetzelfde. De "oude" versie eraf en opnieuw erop zetten zou de truuk ook gedaan hebben.