Apparatuur is grootste struikelblok bij IPv6

[qless]

Enkel verkeer routeren is zeer licht voor de cpu, waarbij in principe ipv6 niet zwaarder of lichter is dan ipv4. Wat wel zeer zwaar is, en dat kan je makkelijk merken als je bijvoorbeeld 2000 torrent connecties probeert op te bouwen, is het gebruik van NAT bij ipv4. Dat laatste hoeft niet meer bij ipv6.

Overigens zou het mooi zijn moest Belgacom eens een nieuwe firmware uitbrengen voor de bbox2/sagem die dat tr proces eens onder de knie houdt...

Aangezien de eerste tijd zowel ipv4 als ipv6 tegelijk in gebruik zullen zijn zal NAT ook nog even in gebruik blijven, dus zal inderdaad de modem iets meer werk moeten doe en wat meer geheugen gebruiken, maar al bij al lang niet zoveel als bijvoorbeeld de interne webserver, het tr98 process etc.

[quistnix]

Bedankt om de uitleg in mijn plaats te doen. Maar het is wel Sagem die een oplossing moet vinden voor het te grote verbruik van het TR-098 protocol.

[Goztow]

Ik heb die nu gekilled...

[Trojan]

Enkel verkeer routeren is zeer licht voor de cpu, waarbij in principe ipv6 niet zwaarder of lichter is dan ipv4. Wat wel zeer zwaar is, en dat kan je makkelijk merken als je bijvoorbeeld 2000 torrent connecties probeert op te bouwen, is het gebruik van NAT bij ipv4. Dat laatste hoeft niet meer bij ipv6.

Overigens zou het mooi zijn moest Belgacom eens een nieuwe firmware uitbrengen voor de bbox2/sagem die dat tr proces eens onder de knie houdt...

Aangezien de eerste tijd zowel ipv4 als ipv6 tegelijk in gebruik zullen zijn zal NAT ook nog even in gebruik blijven, dus zal inderdaad de modem iets meer werk moeten doe en wat meer geheugen gebruiken, maar al bij al lang niet zoveel als bijvoorbeeld de interne webserver, het tr98 process etc.

En daarbovenop komt nog eens het extra rekenwerk dat nodig is voor de modem in fully routed te zetten voor mensen die tv on pc nemen.

[ubremoved_539]

Aangezien de eerste tijd zowel ipv4 als ipv6 tegelijk in gebruik zullen zijn zal NAT ook nog even in gebruik blijven, dus zal inderdaad de modem iets meer werk moeten doe en wat meer geheugen gebruiken, maar al bij al lang niet zoveel als bijvoorbeeld de interne webserver, het tr98 process etc.

Concreet gaat hij dus enkel wat meer geheugen gebruiken... maar wat performance betreft zal het dus niets uitmaken (iets minder IPv4 werk, iets meer IPv6 werk). De andere rotzooi als TR-098 heeft trouwens niets met IPv6, noch met IPv4 te maken (en is dus altijd actief ongeacht welke versie je gebruikt) dus ik zie niet in wat het met de vraag te maken heeft.

[quistnix]

Voila. Probleem is dus opgelost. Sagem/Belgacom hoeven dus niets meer te doen volgens eigenverklaarde expert hierboven.

[honda4life]

ipv6 vraagt meer rekenkracht PUNT!
quistnix heeft dus gelijk.

Hier heb je één van de mooie bewijzen: http://www.ripe.net/ripe/meetings/ripe- ... v6-lsr.pdf
Met misschien het volgende wijze besluit: ipv6 hoeft daarom niet meer rekenkracht te vragen, de stack kan misschien nog verbeterd worden om tot eenzelfde rekenkracht te komen

[Trojan]

Kortom, het zit hem vooral in de implementatie van ipv6. Zoveel te beter deze geprogrammeerd is en efficienter zijn taken kan afhandelen, zoveel te minder rekenkracht er nodig is.

Maar we kennen allemaal de bbox2 en zijn tekorkomingen ...

[simon1205]

Op naar de BBox3 ene die wa meer functies heeft

[Trojan]

fritzbox 7390 of draytek vigor 2750

[ubremoved_539]

Voila. Probleem is dus opgelost. Sagem/Belgacom hoeven dus niets meer te doen volgens eigenverklaarde expert hierboven.

Mr. Wonder weet het allemaal en de rest is hier een bende domme kloten zeker ? Wel, dezen domme kloot kan in het RIPE document van 2004 (da's begot een eeuwigheid in IT termen) de volgende conclusie lezen...

No serious performance penalty for IPv6 with respect to IPv4, but still some differences in the end system TCP/IP stack implementations.

En daaruit durf ik tot op heden concluderen dat IPv6 niet meer of minder performance vraagt dan IPv4 mits de network stack correct ontwikkeld is (en blijkbaar was men daar in 2004 dus al niet ver vanaf). Dus IPv6 vraag meer rekenkracht... PUNT... no I don't think so (dat jij hieruit trouwens de conclusie wil trekken dat Sagem/Belgacom niets meer moeten doen is trouwens een andere discussie).

Je zou volgende keer beter je arrogantie eens gebruiken om de domme kloten onder ons eens te voorzien van een deftige verklaring Misschien had je dan kunnen verwijzen naar een iets recentere (datum staat er niet in, maar gezien de referenties van 2009 en Windows 7 kan het nooit echt oud zijn) studie... http://www.ecst.csuchico.edu/~juliano/c ... Thomas.pdf

[Trojan]

En daaruit durf ik tot op heden concluderen dat IPv6 niet meer of minder performance vraagt dan IPv4 mits de network stack correct ontwikkeld is (en blijkbaar was men daar in 2004 dus al niet ver vanaf). Dus IPv6 vraag meer rekenkracht... PUNT... no I don't think so (dat jij hieruit trouwens de conclusie wil trekken dat Sagem/Belgacom niets meer moeten doen is trouwens een andere discussie).

We hebben het hier toch ngo steeds over de bbox2 he?

[ubremoved_539]

Volgens mij over het feit of IPv6 nu meer CPU power vereist of niet... ongeacht welke implementatie (inclusief die van een BBOX2).

Dat bepaalde toestellen problemen hebben met IPv6 daar zal niemand over twijfelen... maar als er niet meer CPU nodig is, is dit dus louter een firmware issue (implementatie van een deftige IP stack, al zou je verwachten dat die er anno 2011 stilaan is). Indien IPv6 echter wel meer CPU zou verbruiken (maar op marginale amper te bewijzen verschillen na kan ik niets vinden) dan wordt het meteen een hardware issue (en dan moet je effectief nieuwe toestellen gaan uitrollen).

[redman]

En daarbovenop komt nog eens het extra rekenwerk dat nodig is voor de modem in fully routed te zetten voor mensen die tv on pc nemen.

Ik denk inderdaad ook dat dit een veel groter probleem is dan de ipv6 stack die eventueel meer rekenkracht zou kunnen gebruiken.

[quistnix]

No serious performance penalty for IPv6 with respect to IPv4, but still some differences in the end system TCP/IP stack implementations.

En daaruit durf ik tot op heden concluderen dat IPv6 niet meer of minder performance vraagt dan IPv4 mits de network stack correct ontwikkeld is (en blijkbaar was men daar in 2004 dus al niet ver vanaf).

De conclusies die je daar uit trekt zijn voor je eigen rekening. Aangaande de implementatie in de BBOX2: daar heb ik interne informatie over uit eerste hand. En dat is informatie die ik niet mag posten en waarvan niet direct links te vinden zijn op het internet.

Als jij al googelend denkt meer te weten dan Belgacom experts in het labo, tja ... Einde discussie wat mij betreft.

Ik vraag me wel af wie er hier de echte Mister Wonder is, just a thaught

[ubremoved_539]

Aangaande de implementatie in de BBOX2: daar heb ik interne informatie over uit eerste hand.

Als de BBOX2 veel meer CPU nodig heeft voor IPv6 dan is de enige conclusie op dit moment dat de implementatie s.cks... diverse testen tonen namelijk aan dat er geen reden is dat IPv6 meer performance nodig heeft dan IPv4.

Als jij al googelend denkt meer te weten dan Belgacom experts in het labo, tja ... Einde discussie wat mij betreft.

Ik meer weten dan een expert die niet mag zeggen wat hij weet... da's jou conclusie... ik geef alléén aan dat niet meteen te vinden is dat IPv6 meer CPU vereist. Ik wist trouwens niet dat de performantie van apparatuur nu al staatsgeheim was... ofwel zijn er geen problemen (prima dan), ofwel zijn er wel problemen en ga je gewoon op zoek naar een andere leverancier of zorg je dat je huidige het oplost (bij BGC schrijven ze heus geen firmware zelf).

[Jelly]

Belgacom experten die te kennen geven dat ze problemen hebben met het implementeren van het nodige IPv6 protocol zou wel eens invloed kunnen hebben op de beurswaarde

[quistnix]

Lezen en begrijpen wat er geschreven is lijkt voor sommigen een brug te ver. De meeste snappen er nog iets van. Jij daarentegen: je spant echt de kroon Invloed op de beurswaarde ? Waar haal je het in godsnaam vandaan ?

- er is nooit te kennen gegeven dat het implementeren van het nodige IPv6 protocol een probleem is. Verre van zelfs. De ondersteuning ervan zit al van in het begin in de design.

- IPv6 heeft helemaal niet meer performance nodig dan IPv4, dat heb ik nooit beweerd. @r2504: in deze heb je perfect gelijk.

- IPv6 zal in de nabije toekomst echter wel moeten draaien in parallel met IPv4 (voor de franstaligen: "en plus"). Er is reeds uitgelegd dat hierdoor meer processen moeten draaien op de BBOX2. En, ja hoor, hierdoor stijgt de CPU load (@r2504: ben je nog mee ?). Dat er processen zijn die op dit moment te veel load veroorzaken en die zoals - terecht opgemerkt - niets te doen hebben met IPv4 noch IPv6 is in deze niet relevant, ze zijn er voor een goede reden, of je die nu snapt of niet !

- hét probleem voor alle technische afdelingen: maak dat de toestellen - zij het decoders, modems, routers, ... - ALLES aan kunnen wat Marketing beloofd. Zelfs als het voor de hardware overkill is

En probeer nu eens en voor altijd te begrijpen dat we als technieker, technisch medewerker, technisch expert er NIETS aan kunnen doen wat de top (sowieso marketing) beslist of ooit beslist heeft.

We proberen technische vragen te beantwoorden, dus sla ons niet in het gezicht met quotes dat Belgacom woekerwinsten heeft, wurgprijzen hanteert en dergelijke meer. Daar kunnen wij for God's sake niets aan doen. Ik denk niet dat er op dit of enig ander forum veel "marketingboys van BGC" zitten om mensen proberen te helpen. Die denken toch alleen aan zichzelf.

[ubremoved_539]

- IPv6 heeft helemaal niet meer performance nodig dan IPv4, dat heb ik nooit beweerd. @r2504: in deze heb je perfect gelijk.

Waarvoor dank.

- En, ja hoor, hierdoor stijgt de CPU load (@r2504: ben je nog mee ?). Dat er processen zijn die op dit moment te veel load veroorzaken en die zoals - terecht opgemerkt - niets te doen hebben met IPv4 noch IPv6 is in deze niet relevant, ze zijn er voor een goede reden, of je die nu snapt of niet !

Ik ben mee hoor... al zou ik eerder zeggen dat het gebruik van resources stijgt. De vraag is wat het effect is van een dual stack (waarbij je dan kan uitgaan van verschillende scenario's van 0% IPv6 tot 100% IPv6) op de totale CPU belasting. Concreet, gebruikt een IPv6 stack CPU als er geen IPv6 verkeer is. Trouwens ik veronderstel dat de BBOX2 voorzien is voor meer dan 30 MBits, dus in die context moeten er ook nog resources genoeg zijn.

Wat TR-069 en TR-098 betreft... als het daar tenminste over gaat... zie ik trouwens ook niet in waarom dat veel CPU zou gebruiken (het achterliggend protocol is namelijk niet dramatisch complex)... maar het is alvast niet relevant in de discussie rond IPv6 zoals jezelf ook aangeeft.

[tomw]

Heel interessant topic. Wel grappig dat sommige mensen hun mening nastreven die zogezegd verschillend is, maar op het einde blijkt dan dat ze eigelijk hetzelfde menen.

Ik vraag mij toch af of een IPv6 stack samen met een IPv4 stack echt wel zoveel meer resources gebruikt.
Memory zal wss toch wel veel schelen want je zit dan met dubbele buffers. Maar voor CPU is het toch redelijk beperkt behalve dat het opstarten wat langer duurt. Als een IPv6 pakket verwerkt wordt zal de IPv4 stack niets hoeven doen en omgekeerd. Het enige wat ongeveer meer geprocessed moet worden is een extra if.
if (proto == IPv4)
{
..
}
else if(proto == IPv6)
{
...
}

Ik ben erg benieuwd naar wat de echte verklaring misschien zou kunnen zijn.

[ubremoved_539]

Dat een dubbele stack meer resources gebruikt is niet meer dan normaal (eigen ARP, eigen NAT, eigen... tabellen). Wat CPU gebruik betreft... dit is een quote uit een Cisco document...

The CPU usage was essentially the same for a dual stack environment as compared to an IPv4 only environment, indicating that dual stack does not impact CPU usage.

[tomw]

Ewel das beetje wat ik zei hé. Het CPU gebruik gaat maar minimaal omhoog, maar het geheugengebruik (RAM en ROM) strijgt wel.

[Trojan]

Wat TR-069 en TR-098 betreft... als het daar tenminste over gaat... zie ik trouwens ook niet in waarom dat veel CPU zou gebruiken (het achterliggend protocol is namelijk niet dramatisch complex)... maar het is alvast niet relevant in de discussie rond IPv6 zoals jezelf ook aangeeft.

Het zijn juist deze processen die het meeste verbruiken, en normale mensen laten deze draaien. Is het dan zo abnormaal dat ze daar rekening mee moeten houden?

Dat een dubbele stack meer resources gebruikt is niet meer dan normaal (eigen ARP, eigen NAT, eigen... tabellen).

ipv6 gebruikt geen arp en nat.

[ubremoved_539]

ipv6 gebruikt geen arp en nat.

I know... het gebruikt NDP en je hebt inderdaad geen reden meer voor NAT (al zal je andere oplossingen moeten implementeren om de nodige security, die je oneigenlijk kreeg door NAT, terug te hebben). In ieder geval, een aantal dingen blijven hetzelfde, andere dingen worden vervangen... maar een dual stack zal sommige dingen in ieder geval "dubbel" hebben.

[Trojan]

(al zal je andere oplossingen moeten implementeren om de nodige security, die je oneigenlijk kreeg door NAT, terug te hebben)

Firewall, antivirus en een gigantisch grote dosis gezond verstand. En net dat laatste ontbreekt bij de meeste mensen.

[quistnix]

(al zal je andere oplossingen moeten implementeren om de nodige security, die je oneigenlijk kreeg door NAT, terug te hebben)

Firewall, antivirus en een gigantisch grote dosis gezond verstand. En net dat laatste ontbreekt bij de meeste mensen.

Ik denk toch eerder dat het onwetendheid is.

[lithion]

Ja, het blijft uiteindelijk nog de apparatuur die niet volgt. Heb zelf nog geen volledige implementatie kunnen kunnen doen omdat het nog even wachten is op de firmware-updates. 2011 wordt echt wel het jaar van ipv6.

[Sasuke]

2011 het jaar van IPv6 ... dat wil ik nog zien. Misschien voor sommige internet gebruikers (al zullen de ISP's dan 6to4 tunnels moeten voorzien), maar bijvoorbeeld voor het bedrijfsleven ... no way. De leercurve en aangepaste DNS, of het feit dat de 80% mainframe omgeschoolde sysadmins nog via het IP adres willen werken i.p.v. een FQDN houden volgens mij nog meer tegen dan de simpele implementatie van nieuwe apparatuur.

Just my 2 cents,
Sasuke

[quistnix]

Voor een bedrijf als Belgacom is 2011 wél het jaar van IPv6. Is niet meer dan normaal uiteraard.

[Ofloo]

Nee... maar ik wil wel graag een verklaring voor ik iets aanneem.

Waarom zou 30 Mbps IPv4 routen meer of minder CPU gebruiken dan diezelfde 30 Mbps IPv6 verkeer routen ?

- grotere routing tables ?
- zowel routing tables voor ipv4 en ipv6 ? 1+1=2 && 2 > 1
- mtu kleiner meer pakketjes
... ?

[lithion]

2011 het jaar van IPv6 ... dat wil ik nog zien.

Een ding staat alleszins vast: de 7 vrije /8 blokken zullen binnen enkele maanden op zijn. RIPE en de isp's op zich zullen wel nog maanden, misschien jaren vrije adressen hebben, maar bij velen zal de frank beginnen vallen en zal er gepraat worden over ipv6. Of dat ze massaal ipv6 gaan implementeren is idd een andere zaak.

[Trojan]

Van zodra er nog maar 5 blokken over zijn zullen deze gelijk verdeeld worden over de 5 RIR's die deze dan moeten uitgeven aan hun isp's.

Sowieso moeten we ons in belgie geen zorgen maken, zolang de mobiele markt niet te hard groeit. Belgacom en telenet staan op een goed blaadje bij ripe ncc en kunnen (voorlopig) zonder problemen extra ip's krijgen.

Telenet kan ipv6 gemakkelijk uitrollen bij klanten die reeds een docsis 3 modem hebben. En belgacom is er ook volop mee bezig om het werkende te krijgen.

Ik gok dat tegen half 2011 de eerste testfases beginnen en dat tegen eind 2011 iedereen ipv6 kan krijgen.