Ben ik de enige die geen snars snapt van IPv6? 4 kan ik berekenen en dat snap ik, maar 6..?

@Mysterio: ik denk dat je een kleine minderheid bent, als je IPv4 wel echt snapt en geen ene snars van IPv6.

Ja, een aantal dingen zijn anders, en sommige wel behoorlijk anders, maar voordat je daar bent heb je al een hoop gezien waar V6 "meer van hetzelfde" is vgl met V4.

Tsja, jammer dat sommige providers (zoals tele2) denken dat het internet bestaat uit tcp/udp en icmp op ipv4 niveau en alle andere protocollen hard blokkeren op hun modem. :( Zo doet mijn sixxs tunneltje het niet.

Het goede nieuws is dat ook hostingproviders zoals pcextreme ook native ipv6 gaan aanbieden. Kan ik toch nog gebruik maken van mijn 2 /48's ... :D

@mysterio, het is minder moeilijk dan je denkt: je hebt met een /48 gewoon 64k aan subnetten van 64 bits. Kun je voorlopig mee vooruit. Niet meer met de hand uitrekenen, dat gaat meestal niet goed.

Mooi! Even poortscannen! :D Duurt even, maar dan heb je ook niets.

2001:980:5388::/48 :)

Misschien leuk om een linkje naar http://ipv6.wiki.xs4all.nl/ aan je post toe te voegen.

Vreemd want dan gebruik je een 6-over-4 tunnel en tele2 ziet dan alleen maar ipv4 verkeer.

Ik heb inmiddels al vele jaren IPv6, via de tunnel broker van XS4ALL. Mijn modem ondersteund het zeker niet. Een nieuw modem ga ik niet aanschaffen, althans nog niet omdat ik zit te wachten op VDSL.

2001:888:1c5b::/48 veel plezier!

Nee, het is niet vreemd, want inderdaad is het IPv4 getunneld, maar het is geen tcp en geen udp (en al helemaal geen icmp). Tele2 filtert echt op deze protocollen. Defserver opzetten helpt niet. Heel irritant.

Noch bij xs4all, noch bij tweakdsl ooit problemen hiermee gehad, alleen bij tele2.

Het was lichtelijk sarcastisch bedoeld, om de scriptkiddies aan het werk te zetten. :D Ik weet ook wel dat het 'eventjes' duurt voordat je die range gescanned hebt, ik zei niet voor niets 'maar dan heb je ook niets'.

Laatst heb ik wel gebeld met xs4all, en de claim "Alle" klopt in dit geval niet, ten minste, niet native, dat werkt alleen met xs4all only. Als je (zoals xs4all het noemt) ADSL van KPN met XS4ALL als ISP hebt (de oude mxstream constructie) dan kan je alleen via een tunnel IPv6 krijgen.

Ik mag toch aannemen dat de Providers ons hier ook mee gaan helpen of gaat het zo dat alle kosten weer voor de consument zijn? En dus dat bijna iedereen zelf een nieuw modem mag aanschaffen?

Hoe zit het met wat in dit oude bericht aangekaart werd en in de reacties besproken werd?
21-07-2008
Talloze systemen kwetsbaar door IPv6-ondersteuning
http://www.security.nl/artikel/19129/1/Talloze_systemen_kwetsbaar_door_IPv6-ondersteuning.html

" Volgens beveiligingsonderzoeker Joe Klein weten zowel zakelijke als thuisgebruikers niet dat IPv6 op hun systeem is ingeschakeld. Ze zijn ook niet beschermd omdat veel firewalls en IDS geen IPv6 verkeer monitoren en blokkeren."

Dit betrof toen onder andere Vista en 2008 (en inmiddels natuurlijk ook Win 7).

SirDice gaf aan thuis IPv6 te draaien, om mee te experimenteren,
Nomen Nescio gaf aan dat hij IPv6-ondersteuning had uitgeschakeld.
Ikzelf heb IPv6 onder Vista uitgeschakeld.

Maar hoe zit het nu momenteel?
Zijn de huidige firewall en IDS versies inmiddels wél goed ingericht op IPv6?
Het zou wel tijd raken, lijkt me, maar weet iemand of de huidige firewalls en IDS nu inmiddels ook wérkelijk goed omgaan met IPv6?

Dat is al een oud nummer, die komt uit 2001.

Dank je voor je reactie van gisteravond 22.55 uur, Peter,
bedankt voor je onderzoek en voor de update van 23.55.

Ikzelf heb zonet per e-mail navraag gedaan bij G DATA, ik hoop daar morgen een reactie op te krijgen.
Op de G DATA site zie ik dat bij de Business en Enterprise versies vermeld wordt dat deze IPv6 ondersteunen.
Bij de thuisgebruikers-versies ontbreekt een dergelijke vermelding, maar dat wil natuurlijk niet zeggen dat die versies geen IPv6 zouden ondersteunen.
Ik ben benieuwd naar de reactie van G DATA.

@Root: Heel grappig :)

IPv6 werkt met HEX-Decimalen, IPv4 met gewone decimalen (nummers).
Om hex-decimalen om te rekenen wil je echt een calculator hebben! Verder is het eigenlijk heel simpel.

"Het goede nieuws is dat ook hostingproviders zoals pcextreme ook native ipv6 gaan aanbieden. Kan ik toch nog gebruik maken van mijn 2 /48's ... :D"
Niet alleen zij, maar ook andere providers bieden al IPv6 (Wij sinds bieden het ook sinds enige tijd).

Wil je weten of jouw provider iets met IPv6 gaat/aan het doen is.
http://www.ispam.nl/archives/18474/meeste-isp%E2%80%99s-nog-lang-niet-klaar-voor-ipv6/

UPC is er gelukkig al mee bezig, ik zal alleen wel een andere router moeten kopen of deze upgraden :)

@spiff: Lange, lange tijd is pf van OpenBSD (en FreeBSD tegenwoordig) de enige firewall geweest die _echt_ goed met IPv6 omging (echt stateful bijvoorbeeld), ik betwijfel ten zeerste of dat daar nu verandering in is gekomen. De grote jongens (checkpoint cs) roepen wel dat ze het filteren maar ik moet het nog goed zien werken. Dat kan natuurlijk ook aan mij liggen. ;)

pf laat in ieder geval toe dat je selectief poorten en ip adressen al dan niet door laat, en zo bescherming van binnen naar buiten, en van buiten naar binnen biedt.

Ik denk dat Ubuntu Linux Lucid dit ook al onderetsteund,Windows7 ok al,alleen weet ik niet of mijn Modem van Tele2 dit protocol al ondersteund,zo niet dan denk ik dat al ze over gaan op ipv6,ik wel bericht krijg en een nieuwe modem in bruikleen.

De Vigor 120 is een simpel (en goedkoop, ca 50 euro) modem dat als een van de weinige modems PPPoA naar PPPoE kan bridgen.
Naast de genoemde Vigor210n router kun je dus ook IPv6 native termineren direct op je host (oa Linux), als die PPPoE (en dhcpv6 met PD) doet.
De enige caveat is dat de Vigor120 geen jumbo frames (zelf geen mini jumbo) doet. De PPPoE overhead (8 bytes) gaat dus af van de 1500 byte ethernet MTU, en netto blijft een 1492 byte MTU over.
Een netwerk wat je daarachter laat routeren kan dus last krijgen bij bestemmingen die path mtu discovery vernaggelen.
De Vigor120 is een ADSL2/2+ modem.

Een FritzBox!7340 krijg je (bij xs4all) gratis als je je abonnement (lite en basic) naar VDSL2 upgrade en voor een jaar afsluit.

Ook de Linux standaard firewall (netfilter) doet al een aantal jaren stateful IPv6.

Ubuntu Lucid en IPv6 werkt perfect!
Wel moet je IPv6 bij de firewall inschalen, anders werkt het niet..

In Dapper werd IPv6 wel ondersteund, maar de Firewall Iptables ondersteunde toen nog geen enkel IPv6 filter-type.

Heb ook Tele2, maar geen enkel probleem met mijn SixXS tunnel, zelfs zonder enige vorm van portforwarding werkt het perfect. Weet je zeker dat je config geen probleem is?

Hangt van je tunnel type af denk ik. Ik gebruik 6-in-4-static. OpenBSD als endpoint aan mijn kant. Ayiya werkt inderdaad wel, maar heeft niet mijn voorkeur. Volgens http://www.sixxs.net/faq/connectivity/?faq=firewalled wordt inderdaad proto 41 dorgegeven bij static tunnels, en wordt dat inderdaad in het stomme tele2 modem geblokkeerd.

Vanaf 2000 debian + IPv6 gebruikt. De firewall deed het inderdaad niet, daar gebruik(te) ik OpenBSD voor. Omdat debian het ondersteunde moeten alle ubuntu versies (ubuntu werd pas in 2004 gevormd) het ook gewoon goed ondersteund hebben. ;)

Een andere vraag is natuurlijk welke daemons en welke client software IPv6 ondersteund(e)...

Ik heb een ALIX met M0n0wall erop als router, ipv6 werkt al ruim een jaar prima daarmee.

Voor degenen die problemen hebben met het bouwen van de zone files: http://www.fpsn.net/tools&tool=ipv6-inaddr

Het zal allemaal wel. Ik ben wel klaar voor twee maal OCZ Vertex 2 SSD in Raid 0. Dat vind ik veel interessanter.
Kom maar op met die speeeeeeeeeeeeeeeeeeeeeeeeeeed

Want je moet steeds rebooten en Windows gaat zoveel harder op SSD?

Met IPv6 is ineens RIP weer terug; heet nu RIP ng (Next Generation). Het gebruikt het link-local adres als source adres en de multicast naar alle routers is FF02::9. (was 224.0.0.9 in IPv4)
Voor kleine netwerkjes prima te gebruiken

Ja, eigenlijk wel. De wachttijden met programma's openen zoals Autocad en Photoshop zijn nihil. Alles gaat gewoon sneller.
Met een notebook op de zaak ook gedaan en het is zeker te merken. Dan was dit nog met een Intel SSD 250/70MBps read/write op de notebook.
Intel zuigt schijnbaar want met de OCZ Vertex 2 haal je 285/275MBps read/write.
Om even flink offtopic te zijn.

Inmiddels heb ik een reactie ontvangen van G DATA:
De achterliggende technologie is in beide gevallen dezelfde, voor zowel de Business en Enterprise versies als voor de thuisgebruikers-versies, alle ondersteunen IPv6. Ook voor de consumentenproducten is er geen probleem met de ondersteuning van IPv6.

Ik vind IPv6 geen slimme uitvinding, waarom niet het huidige systeem met 1 octet extra, of misschien 2 extra octetten.

IPv4 + 0 (255^4) = 4.228.250.625 adressen, is binnenkort op.
IPv4 + 1 (255^5) = 1.078.203.909.375 adressen, dat lijkt me genoeg.
IPv4 + 2 (255^6) = 274.941.996.890.625 adressen.... you get the point.

88.159.209.175 of 88.159.209.175.123 is makkelijker te onthouden dan 2002:0:0:0:0:0:589f:d1af

Daar is dns voor uitgevonden. Je gaat toch geen ip adressen ergens voor gebruiken behalve voor dns?

IPv6 heeft andere voordelen dan het huidige systeem, of jouw voorstellen. Onder andere routing wordt (veel) eenvoudiger en dus sneller. Belangrijke stap. Daarnaast zijn een aantal van de ontwerpfouten van IPv4 weggehaald (en gelukkig weer nieuwe geintroduceerd).

Leg eens uit waarom je denkt dat routing eenvoudiger en dus sneller wordt ?
De routing protocollen en beslissing (prefix,longest match e.d.) zijn vrijwel hetzelfde gebleven.
Qua forwarding moet er naar vier keer zoveel data per pakket gekeken worden, dus daar mag je echt geen versnelling van verwachten.

Op z'n best kun je hopen dat adressen meer geaggregeerd blijven, zodat de global routing table kleiner blijft. Dat is wel fijn, maar niet _sneller_ qua forwarding. Op de typische core routers is de forwarding snelheid onafhankelijk van het aantal routes. (Als er teveel routes inzitten, houdt het op voor prefixen die niet passen. Terugvallen naar een trager software pad is kansloos).

Naast een groter bereik in IP adressen heeft IPv6 een aantal voordelen tov v4:

- Geen public-to-private NAT; dus echte end-to-end adressering,
- Geen broadcast meer, unicast, multicast en anycast,
- Simpelere header wat de ten goede komt van router effectiviteit, fowarding-rate scalabilty, geen processing van checksums, simpelere en meer efficiente extension header mechanisme,
- Flow labels voor per-flow processing waarbij er geen noodzaak is om de transport layer te onderzoeken voor het identificeren van de verschillende traffic flows,
- Support voor mobility en security; betere compliance met mobiele IP en IPsec standaarden. Mobilty is als het ware ingebouwd.
- Stateless autoconfiguration,
- Prefix renumbering,
- Meerdere IP adressen per interface
- Link-local adressen,
- Provider-dependent of provider-independent adressering
Zie RFC 2460 voor meer info

Omdat er met zekerheid geaggregreerd wordt. Opdeling zoals bij IPv4 mag niet meer. Uiteindelijk wordt de routing engine daar (heel veel) simpeler van, en, zeker gezien het enorme adresbereik, ook de routingtabellen. Die zouden onmogelijk groot worden als aggregratie niet zou worden verplicht. Ze zijn nu al enorm groot voor IPv4.

Ha, hij wordt nu ges

Dat is dus niet helemaal juist, zoals ik al schreef. Een gegeven router gaat niet sneller forwarden bij het hebben van minder routes. En soms is de PPS rate inderdaad lager voor V6 vs V4 forwarding.

Wel is bijvoorbeeld een router die maximaal 128,000 routes aankan simpeler/goedkoper dan een router die bijvoorbeeld 512,000 routes aankan. (Bij routers met hardware forwarding; De routers die een volledige routing tabel voeren hebben gewoonlijk ook aansluitsnelheden waarbij software forwarding ('gewone' cpu) niet voldoet.Een software gebaseerde router hoeft heel weinig beperkingen in het aantal routes te hebben).

Maar hoewel inderdaad een kleinere globale routing table inderdaad fijn zou zijn, wil ik dan toch graag horen waar de _grote_ winst die je qua aggregatie noemt vandaan moet komen.
Met een standaard allocatie van een /32 per isp en een /48 per site voorkom je misschien een stuk van de in ipv4 tijden historisch gegroeide de-aggregatie (blokje hier, nieuw blokje daar) , maar andere drivers voor de groei van het aantal V4 routes zijn net zo aanwezig voor IPv6.
Misschien dat een stuk van het schone-lei/nieuwe bezems vegen schoon/ ervaring vanuit IPv4 helpt om *policies* (assigment, en acceptatie door ISP) zodanig te kiezen dat de V6 tabel kleiner blijft dan een V4 tabel, maar ik zie niet meteen reden om enorm optimistisch te zijn.
En voor minimaal het komende decennium draait V6 natuurlijk parallel met V4, en zal vrijwel altijd dezelfde router zowel een V6 als een V4 tabel moeten voeren. (V6 zal wel erg hard moeten groeien om een dedicated router te verdienen)

@anoniem 16:26. Je denkfout zit in het feit dat je over het hoofd ziet dat route tabellen immens zouden groeien als IPv6 niet zou zijn geimplementeerd zoals het is geimplementeerd.

Een router gaat wel degelijk sneller routeren trouwens, er zijn geen zoektabellen nodig voor IPv6. Dat is 1 van de geheime grappen.

Ik wil graag van je horen hoe jij denkt efficient te kunnen routeren bij IPv6 grootte van adresbereik. En nee, de limieten bij de /32 voor de isp's en /48 (of iets kleiner) tot en met de /64 per site zijn nog steeds dusdanig dat we niet kunnen zien waar daarbij de grens ligt... Die aggregratie is voldoende om de winst voor IPv6 te garanderen. Er is geen schijn van kans dat IPv6 zo gefragmenteerd gaat worden als IPv4 nu is.

Het is realiteit dat het uitgifte beleid zodanig is dat fragmentatie voorkomen wordt. http://www.ripe.net/ripe/docs/ipv6policy.html. Dat is realiteit. Geen optimisme.

@jdenhaer: Graag!

De telefoonmevrouw van mijn provider liet een lang "uuuuuuuuuuhm" horen toen ik erover begon. Ik denk niet dat het op haar lijstje stond :D

Ik zet hier een downloadlink. Hopelijk heb je er iets aan... Het is eenvoudig geschreven van A tot Z met een stuk praktijk op het einde. Je kan het nadien helemaal afbreken. ;)

http://rs805.rapidshare.com/files/420780315/THESIS_HBO_GRADUAAT_IPv6_Den_Haerynck_Jan.pdf

Ben anoniem 16:26 ..

Even punt voor punt werken.
Ook met IPv6 heeft een router nog steeds een forwarding tabel van prefixen. Op moment weinig, in de toekomst meer.
Die moet nog steeds doorzocht worden, geen geheime grappen. De routing regel is en blijft een match binnen de meest specifieke prefix.
Als je kijkt naar de forwarding rate (PPS dus) van V6 capable routers zie je op z'n best dezelfde rate als voor IPv4, en soms minder (de helft bijvoorbeeld).

IPv4 routeer je *niet* door een destination in een volledige 32 bit (4G) tabel op te zoeken, ook al zou dat tegenwoordig net kunnen in een dram gebaseerd systeem. (dan nog wil je het zo niet ontwerpen).
Je zoekt een match met een meest-specifieke passende prefix (netwerk + masker) in een tabel van momenteel ~340K prefixen, voor een default-free router.

Op de gebruikelijke core routers is die forwarding lookup constant-time en onafhankelijk van het aantal aanwezige prefixen, zolang die passen op het platform.
Een dergelijke router wordt bijvoorbeeld niet sneller van het hebben van alleen een default route (1 prefix).

Een routing beslissing voor een IPv6 pakket is niet anders, ook dat is de meest-specifieke passende prefix, alleen zijn hier de prefixen langer, en zal er wat minder variatie in masker lengtes zijn.
Natuurlijk is een theoretische lookup in een 2^128 tabel out of the question. Maar zo werkt V4 routing dus ook niet.

In je eerste zin lijkt je te suggereren dat het aantal routes zou 'moeten' schalen met de lengte van adressen.
2^96 keer zoveel adressen, dus evenzeer keer meer routes. Dat is natuurlijk niet zo.

Wat dat betreft gaat routeren gewoon precies hetzelfde als met IPv4. Het is wel zo dat de combinatie "extreem snel" en "grote routing table" (500K+,1M+) erg lastig is , en daarom wil je het aantal routes beperken.

En omdat de adresruimte groter is, kun je een *deel* van achtergrond van V4 de-agreggatie voorkomen, doordat een partij in 1x "genoeg" adressen kan krijgen.
Maar min of meer vergelijkbare allocatie policies zijn er ook voor IPv4.
Bedenk overigens dat de echt kleine IPv4 subnetjes (meer specifiek dan een /23 of een /24) op behoorlijke delen van het internet ook al niet gerouteerd worden.
Dus ja, hopelijk blijft de V6 tabel structureel wat kleiner dan een vergelijkbare V4 tabel omdat er wat minder vaak een extra netwerk gevraagd wordt wat niet meer binnen een aggregeerbare reservering viel.

Maar een ander deel van de table groei bestaat uit meer partijen die multi-homen, en "poor man's traffic engineering'" (aggregaat + meer specifieke routes om verkeer te verdelen), en ik zie niet waarom _die_ redenen verdwenen zouden zijn bij IPv6.

Dus nogmaals, leg eens uit waarom volgens jou:
1 : forwarding van IPv6 bij een routing table van bv 200K prefixen veel sneller zou gaan dan IPv4 forwarding bij een routing table van 200K prefixen.
2 : Ik heb al gezegd dat er wel enige reden is om _wat_ minder prefixen in de V6 table te verwachten. Maar ik hoor graag in welke mate je dat voordeel verwacht op moment dat een vergelijkbare connectiviteit bereikt is als voor IPv4.
Kortom, kun je aangeven in welke mate het formaat van de huidige V4 tabel te wijten is aan gebrekkige allocatie policy, of een een policy gedwongen door het V4 adresformaat.

Bedenk overigens dat de-aggregatie ook typisch niet bij uitgifte gebeurt, maar bij gebruik. Een partij kan heel wel een /16 krijgen, en die /16 en 16 x een /20 eruit aan routes announcen. (of nog specifiekere routes).
En de redenen waarom dat soms gedaan wordt zijn niet verdwenen bij V6.
Daarom denk ik dat je erg stellige bewering 'geen schijn van kans' ,blijkbaar op basis van de aanname dat de enige of primaire reden van de-aggregatie ligt bij de allocatie policy van de registries, niet correct is.

Ben anoniem 16:26 ..

Even punt voor punt werken.
Ook met IPv6 heeft een router nog steeds een forwarding tabel van prefixen. Op moment weinig, in de toekomst meer.
Die moet nog steeds doorzocht worden, geen geheime grappen. De routing regel is en blijft een match binnen de meest specifieke prefix.
Als je kijkt naar de forwarding rate (PPS dus) van V6 capable routers zie je op z'n best dezelfde rate als voor IPv4, en soms minder (de helft bijvoorbeeld).

IPv4 routeer je *niet* door een destination in een volledige 32 bit (4G) tabel op te zoeken, ook al zou dat tegenwoordig net kunnen in een dram gebaseerd systeem. (dan nog wil je het zo niet ontwerpen).
Je zoekt een match met een meest-specifieke passende prefix (netwerk + masker) in een tabel van momenteel ~340K prefixen, voor een default-free router.

Op de gebruikelijke core routers is die forwarding lookup constant-time en onafhankelijk van het aantal aanwezige prefixen, zolang die passen op het platform.
Een dergelijke router wordt bijvoorbeeld niet sneller van het hebben van alleen een default route (1 prefix).

Een routing beslissing voor een IPv6 pakket is niet anders, ook dat is de meest-specifieke passende prefix, alleen zijn hier de prefixen langer, en zal er wat minder variatie in masker lengtes zijn.
Natuurlijk is een theoretische lookup in een 2^128 tabel out of the question. Maar zo werkt V4 routing dus ook niet.

In je eerste zin lijkt je te suggereren dat het aantal routes zou 'moeten' schalen met de lengte van adressen.
2^96 keer zoveel adressen, dus evenzeer keer meer routes. Dat is natuurlijk niet zo.

Wat dat betreft gaat routeren gewoon precies hetzelfde als met IPv4. Het is wel zo dat de combinatie "extreem snel" en "grote routing table" (500K+,1M+) erg lastig is , en daarom wil je het aantal routes beperken.
(vervolg in tweede posting, preview suggereert een size limit)

(vervolg posting, ben nog steeds anoniem 16:26)

En omdat de adresruimte groter is, kun je een *deel* van achtergrond van V4 de-agreggatie voorkomen, doordat een partij in 1x "genoeg" adressen kan krijgen.
Maar min of meer vergelijkbare allocatie policies zijn er ook voor IPv4.
Bedenk overigens dat de echt kleine IPv4 subnetjes (meer specifiek dan een /23 of een /24) op behoorlijke delen van het internet ook al niet gerouteerd worden.
Dus ja, hopelijk blijft de V6 tabel structureel wat kleiner dan een vergelijkbare V4 tabel omdat er wat minder vaak een extra netwerk gevraagd wordt wat niet meer binnen een aggregeerbare reservering viel.

Maar een ander deel van de table groei bestaat uit meer partijen die multi-homen, en "poor man's traffic engineering'" (aggregaat + meer specifieke routes om verkeer te verdelen), en ik zie niet waarom _die_ redenen verdwenen zouden zijn bij IPv6.

Dus nogmaals, leg eens uit waarom volgens jou:
1 : forwarding van IPv6 bij een routing table van bv 200K prefixen veel sneller zou gaan dan IPv4 forwarding bij een routing table van 200K prefixen.
2 : Ik heb al gezegd dat er wel enige reden is om _wat_ minder prefixen in de V6 table te verwachten. Maar ik hoor graag in welke mate je dat voordeel verwacht op moment dat een vergelijkbare connectiviteit bereikt is als voor IPv4.
Kortom, kun je aangeven in welke mate het formaat van de huidige V4 tabel te wijten is aan gebrekkige allocatie policy, of een een policy gedwongen door het V4 adresformaat.

Bedenk overigens dat de-aggregatie ook typisch niet bij uitgifte gebeurt, maar bij gebruik. Een partij kan heel wel een /16 krijgen, en die /16 en 16 x een /20 eruit aan routes announcen. (of nog specifiekere routes).
En de redenen waarom dat soms gedaan wordt zijn niet verdwenen bij V6.
Daarom denk ik dat je erg stellige bewering 'geen schijn van kans' blijkbaar op basis van de aanname dat de enige of primaire reden van de-aggregatie ligt bij de allocatie policy van de registries, niet correct is.

Koop een Mac, die hebben al standaard EFI in plaats van BIOS

Webwereld:
"Telfort volgt IPv6-voorbeeld Xs4all
ADSL-provider Telfort start begin volgend jaar met een IPv6-pilot. Het is de volgende isp na koploper Xs4all. Andere Nederlandse providers zijn nog bezig hun netwerk geschikt te maken voor IPv6."
http://webwereld.nl/nieuws/67430/telfort-volgt-ipv6-voorbeeld-xs4all.html

Jammer dat die IP6 modems zo schreeuwend duur zijn. Ik zit ook bij Xs4all en wil graag met IP6 aan de slag, maar een paar honderd euries neerleggen voor een IP6 modem gaat me even te ver

De Vigor 120 is een simpel (en goedkoop, ca 50 euro) ADSL2(+) modem dat als een van de weinige modems PPPoA naar PPPoE kan bridgen.
Hiermee kun je PPPoE termineren op je PC (bv Linux) en heb je dus ook native IPv6.

De enige caveat is dat de Vigor120 geen jumbo frames (zelf geen mini jumbo) doet. De PPPoE overhead (8 bytes) gaat dus af van de 1500 byte ethernet MTU, en netto blijft een 1492 byte MTU over.
Een netwerk wat je daarachter laat routeren kan dus last krijgen bij bestemmingen die path mtu discovery vernaggelen.

Een Fritz!Box 7340 krijg je (bij xs4all) gratis als je je abonnement (lite en basic) naar VDSL2 upgrade en voor een jaar afsluit.

Je kunt natuurlijk ook nog je IPv6 via een tunnel laten lopen, bij xs4all of elders.

Je kunt ook de tunnel broker gebruiken. Die gebruik ik al jaren. Mijn modem ondersteund het ook niet en ik wacht met aanschaffen van een nieuw modem tot ik VDSL heb. De tunnel broker kun je vinden op de service pagina onder experimentele diensten.

Leuke IPV6 cursus/queeste te vinden op
http://ipv6.he.net/
Als dank nog een fraai t-shirt aan overgehouden :-)