Grote websites stappen over op ipv6
Vandaag is de World Ipv6 Launch: de dag waarop een aantal grote internetbedrijven officieel ipv6 in gebruik nemen. Onder meer Google, Facebook en YouTube zijn voortaan via ipv6 bereikbaar, net als een aantal Nederlandse sites.
De World Ipv6 Launch betekent voor onder meer Google, Facebook, YouTube, Bing en Netflix dat ze ipv6 officieel in gebruik nemen. Voor internetgebruikers met een ipv6-verbinding - dat zijn er nog maar weinig - zijn deze sites ook met het nieuwe internetprotocol te bereiken. In Nederland stappen onder meer Rijksoverheid.nl, de website van het SIDN en die van de gemeente Alkmaar over. De overstap is noodzakelijk omdat de ipv4-adressen beginnen op te raken.
Vorig jaar werd op 8 juni de World Ipv6 Day gehouden, waarop internetbedrijven ondersteuning voor ipv6 tijdelijk inschakelden. Na afloop werd de ondersteuning weer uitgezet. Dit keer is het de bedoeling dat de ipv6-ondersteuning permanent beschikbaar blijft.
Wereldwijd doen slechts 66 internetproviders aan de launch mee; in Nederland gaat het alleen om Xs4all en onderwijs-isp SURFnet. Beide internetproviders boden al ipv6-uplinks aan, waardoor de deelname aan World Ipv6 Launch vooral symbolisch is. Xs4all is de enige internetprovider die consumenten via ipv6 met het internet verbindt. Sinds kort activeert de provider het nieuwe protocol voor alle nieuwe klanten; wie al langer een Xs4all-verbinding heeft, kan ipv6 handmatig activeren.
UPC, Ziggo en KPN, de grootste isp's van Nederland, verwachten nog dit jaar ipv6 te kunnen aanbieden. UPC denkt eind dit jaar geen ipv4-adressen meer te hebben; voor die tijd is een overstap noodzakelijk, wil het bedrijf nog nieuwe klanten kunnen aannemen. Ziggo streeft ernaar eind dit jaar over te zijn, 'maar dat kan ook 2013 worden', zegt woordvoerder Gradus Vos. KPN spreekt op zijn website de verwachting uit dat eind 2012 alle diensten ipv6 zullen ondersteunen.
Het is nog niet bekend wanneer Tweakers.net ipv6 volledig zal ondersteunen. "Onze apparatuur is er in principe klaar voor, maar we moeten nog even goed nadenken over de implementatie", zegt systeembeheerder Kees Hoekzema. De overstap naar ipv6 had voor Tweakers.net de afgelopen jaren geen heel hoge prioriteit.
Het grootste verschil tussen ipv4 en ipv6 is het aantal beschikbare ip-adressen. Waar er circa 4,3 miljard ipv4-adressen zijn, ligt het aantal ipv6-adressen fors hoger. Er zijn om en nabij de 340 sextiljoen ip-adressen - dat is een getal van 39 cijfers - wat betekent dat er per aardbewoner veel meer ipv6-adressen beschikbaar zijn dan dat er in totaal ipv4-adressen zijn. Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.
Reacties (143)
Die zin impliceert imho dat dat voorheen dus niet mogelijk was?Onder meer Google, Facebook en YouTube zijn voortaan via ipv6 bereikbaar, net als een aantal Nederlandse sites.
Nee... Er staat dat die websites vanaf nu via ipv6 bereikbaar zijn. Over wat er eerder het geval is wordt geen informatie gegeven.
Kon dus wel, en er werd hier nog informatie over gegeven. Even doorlezen voordat er een onnodig vraag-reactie komt.De afgelopen jaren werd op 6 juni de World Ipv6 Day gehouden, waarop internetbedrijven ondersteuning voor ipv6 tijdelijk inschakelden. Na afloop werd de ondersteuning weer uitgezet. Dit keer is het de bedoeling dat de ipv6-ondersteuning permanent beschikbaar blijft.
Tikfoutjes
[Reactie gewijzigd door Raven_X3 op woensdag 6 juni 2012 12:00]
job_h bedoelt niet "Nee.. dat was niet mogelijk". Hij bedoelt dat die zin niet impliceert dat het voorheen niet mogelijk was.
Maar de zin impliceert wel dat het voorheen onmogelijk was en wel vanwege het woordje "voortaan"
Wel een gigantische operatie trouwens, als alle hardware op het internet handmatig omgezet moet worden (veel hardware zal al geschikt zijn, maar toch).
Uitzondering was dus die ene dag vorig jaar op World ipv6 day.Onder meer Google, Facebook en YouTube zijn voortaan via ipv6 bereikbaar
Wel een gigantische operatie trouwens, als alle hardware op het internet handmatig omgezet moet worden (veel hardware zal al geschikt zijn, maar toch).
Dat vroeg ik mij inderdaad ook af. Maar het lijkt me nogal onwaarschijnlijk niet?
Leuk, welk internet heb jij?
Ja.. nieuw abonnement van KPN, maar ik kan alleen nog niet naar Google, Facebook en Youtube
[Reactie gewijzigd door dsmink op woensdag 6 juni 2012 11:59]
Google en YouTube waren hiervoor ook al via IPv6 bereikbaar, maar de DNS servers van Google gaven alleen aan bepaalde partijen AAAA records terug (waaronder ook XS4ALL). Maar vanaf vandaag is dit voor iedereen.
De diensten van Google waaren voorheen al via IPV6 te bereiken, maar alleen als je op een puur IPV6-netwerk zat. Via IPV4 kreeg je via DNS alleen een A-record terug en zat er geen AAAA-record op. Wel was er altijd al http://ipv6.google.com, maar daar had je niets aan voor bijv. Youtube.
Vanaf vandaag zitten er op alle domeinnamen zowel A als AAAA-records.
Vanaf vandaag zitten er op alle domeinnamen zowel A als AAAA-records.
Dat is correct. Die hadden veelal aparte subdomeinen waarop ze via IPv6 bereikbaar waren, maar geen AAAA records op hun hoofddomein. Deze zijn nu wel toegevoegd.
In de zin ervoor staat "officieel".
Hoe zit het eigenlijk met het 48 bits Mac adres icm met IPV6 op 128 bits ?
Die hebben niets met elkaar te maken.
Je kan het een beetje zien als je kenteken op je auto en het serienummer van je auto. Beide zijn uniek voor jouw auto, maar hebben een betekenis op een totaal ander nivo.
/edit
Goed, tijd voor mij om eens wat meer over ipv6 te lezen.
Je kan het een beetje zien als je kenteken op je auto en het serienummer van je auto. Beide zijn uniek voor jouw auto, maar hebben een betekenis op een totaal ander nivo.
/edit
Goed, tijd voor mij om eens wat meer over ipv6 te lezen.
[Reactie gewijzigd door PiepPiep op woensdag 6 juni 2012 12:35]
Quote van wikipedia:
http://nl.wikipedia.org/wiki/Internet_Protocol_versie_6Soms bestaat een IPv6-adres uit twee logische delen: een 64-bitnetwerkprefix en een "host-addressing"-deel van 64 bits, dat vaak automatisch van de interface ofwel het MAC-adres wordt afgeleid.
Onzin.
Per definitie bestaat een adres uit 2 gedeelten. Waar. Maar de lengte is variabel.
Als dat niet zo zou zijn, dan kun je ranges niet onderverdelen. Dan kun je niet summarizen. Dan kun je niet subnetten. Dat zou een gigantisch stap terug zijn. Variable-length prefixes bestaan ook in IPv4, sinds CIDR uit 1992.
Per definitie bestaat een adres uit 2 gedeelten. Waar. Maar de lengte is variabel.
Als dat niet zo zou zijn, dan kun je ranges niet onderverdelen. Dan kun je niet summarizen. Dan kun je niet subnetten. Dat zou een gigantisch stap terug zijn. Variable-length prefixes bestaan ook in IPv4, sinds CIDR uit 1992.
Het zit ingewikkelder. Bij IPv6 kun je uiteraard met CIDR subnetten, maar SLAAC (stateless autoconfiguration) gaat ervan uit dat het binnen een /64 opereert. Dat is gelijk waarom ISP's meer dan een /64 aanbieden aan klanten, als je iemand de gelegenheid wil geven om meerdere subnets te hebben en vervolgens daarbinnen SLAAC te gebruiken moet je dus meer dan een /64 geven. XS4All deelt bijv /48 prefixes uit aan individuele klanten, wat dus de mogelijkheid biedt om 2^16 (65535) netwerken van 2^64 hosts (veel, erg veel) te maken.
IMHO is het trouwens erg onverstandig geweest om die /64 beperking op SLAAC te hebben. Het lijkt misschien alsof we bijna oneindig veel IPv6-adressen hebben, maar als we per klant nota bene 2^80 adressen uitdelen (gevolg van een /48 geven) raken we er alsnog veel te snel doorheen.
Reken maar na, sinds invoering van IPv4 in 1981 zien we grof gezegd elk jaar een verdubbeling van het aantal gebruikte IP-adressen. Na 32 jaar (2013) is het 32b-adresruimte van IPv4 dan ook op. Met IPv6 heb je 2^128, dat zou bij gelijke addressering en gelijke groei genoeg moeten zijn tot 2109 (gerekend vanaf 1981, omdat de volle adresruimte van IPv4 in IPv6 zit). Maar als je minimaal /64 subnets moet gebruiken hou je maar over tot 2045 - en als je /48 uitdeelt aan iedere gebruiker voldoet IPv6 maar tot 2029
Ik durf dan ook stellig te voorspellen dat we voor 2045 (een jaartal waarop veel van ons nog aan het werk zijn) door onze IPv6-adressen heen zijn
Niet omdat ze allemaal in gebruik zijn (verre van), wel omdat we er zo ongelofelijk verkwistend mee omgaan. Het is nog erger dan de manier waarop we bij IPv4 in het begin te pas en onpas A-class networks (/8) uitdeelden
IMHO is het trouwens erg onverstandig geweest om die /64 beperking op SLAAC te hebben. Het lijkt misschien alsof we bijna oneindig veel IPv6-adressen hebben, maar als we per klant nota bene 2^80 adressen uitdelen (gevolg van een /48 geven) raken we er alsnog veel te snel doorheen.
Reken maar na, sinds invoering van IPv4 in 1981 zien we grof gezegd elk jaar een verdubbeling van het aantal gebruikte IP-adressen. Na 32 jaar (2013) is het 32b-adresruimte van IPv4 dan ook op. Met IPv6 heb je 2^128, dat zou bij gelijke addressering en gelijke groei genoeg moeten zijn tot 2109 (gerekend vanaf 1981, omdat de volle adresruimte van IPv4 in IPv6 zit). Maar als je minimaal /64 subnets moet gebruiken hou je maar over tot 2045 - en als je /48 uitdeelt aan iedere gebruiker voldoet IPv6 maar tot 2029
Ik durf dan ook stellig te voorspellen dat we voor 2045 (een jaartal waarop veel van ons nog aan het werk zijn) door onze IPv6-adressen heen zijn
Niet omdat ze allemaal in gebruik zijn (verre van), wel omdat we er zo ongelofelijk verkwistend mee omgaan. Het is nog erger dan de manier waarop we bij IPv4 in het begin te pas en onpas A-class networks (/8) uitdeelden
Volledig mee eens. Want nu moet je zelfs tussen 2 routers een /64 netwerk aanleggen wat pure verkwisting is. Ze hadden de scopes beter iets kleiner gemaakt. Want hetgeen ze nu doen is vrij harde verkwisting vind ik ook wel.
Nope, daar mag je ook /127 voor gebruiken.Want nu moet je zelfs tussen 2 routers een /64 netwerk aanleggen wat pure verkwisting is.
Overigens is die "verkwisting" omdat IPv6 z'n leven is begonnen met 64bit adressering. Pas iets later dachten ze "mwa waarom niet 64bit erbij en daar de host id van maken?"
Je hebt natuurlijk gelijk in wat je zegt.
Maar ik heb ook gelijk.
Als je een IPv6 adres bekijkt vanaf het routing standpunt, dan is er geen enkele beperking om het host-part minimaal (of precies) 48-bits te laten zijn.
Als je bv in de originele IPv6 RFC kijkt, dan zie je nergens het getal 48 terug.
http://www.ietf.org/rfc/rfc2460.txt
Een verschil tussen de theoretisch benadering (protocol design) en de praktische benadering (deployement).
Je verhaal over exponentiele groei is mooi. Maar hoewel de groei in het verleden exponentieel was, wil dat niet zeggen dat hij in de toekomst ook exponentieel zal zijn. We hebben geen glazen bol. Ik denk dat de groei af zal nemen als ieder mens op de aardbol connected is. En de hoeveelheid mensen is beperkt (zal niet opeens 100 miljard zijn). En de hoeveelheid aparaten per mens. (En ik denk dat daar ook een limiet aan zal zijn, omdat aparaten functionaliteit combineren. Bv je hebt geen 3 adressen nodig voor je telefoon, je horloge en je rekenmachine. Dat is een aparaat nu).
Ik ben het desondanks helemaal met je eens dat we IPv6 adressen verkwisten.
Echter, het grote probleem is niet zozeer dat ze dan op raken. Het grote probleem is dat al die adressen geadverteerd moeten worden. Dat "scaled" alleen als je ze kan summarizen. En summarizen werkt alleen goed als het protocol daar goede hulpmiddelen voor biedt. Zoals automated renumbering, locator-identifier separation, betere support for multi-homing, goede mobile ip, etc. En IPv6 heeft daar geen enkele vernieuwing. Dus na een tijdje zullen de global IPv6 routing tabels net zo'n puinhoop zijn als de IPv4 global table. En hoe slordiger er met IPv6 adressen wordt omgesprongen, hoe erger het probleem wordt. End-users merken hier niks van, maar ISPs moeten overbodig dure apparatuur kopen om dit probleem op te lossen.
Maar ik heb ook gelijk.
Als je een IPv6 adres bekijkt vanaf het routing standpunt, dan is er geen enkele beperking om het host-part minimaal (of precies) 48-bits te laten zijn.
Als je bv in de originele IPv6 RFC kijkt, dan zie je nergens het getal 48 terug.
http://www.ietf.org/rfc/rfc2460.txt
Een verschil tussen de theoretisch benadering (protocol design) en de praktische benadering (deployement).
Je verhaal over exponentiele groei is mooi. Maar hoewel de groei in het verleden exponentieel was, wil dat niet zeggen dat hij in de toekomst ook exponentieel zal zijn. We hebben geen glazen bol. Ik denk dat de groei af zal nemen als ieder mens op de aardbol connected is. En de hoeveelheid mensen is beperkt (zal niet opeens 100 miljard zijn). En de hoeveelheid aparaten per mens. (En ik denk dat daar ook een limiet aan zal zijn, omdat aparaten functionaliteit combineren. Bv je hebt geen 3 adressen nodig voor je telefoon, je horloge en je rekenmachine. Dat is een aparaat nu).
Ik ben het desondanks helemaal met je eens dat we IPv6 adressen verkwisten.
Echter, het grote probleem is niet zozeer dat ze dan op raken. Het grote probleem is dat al die adressen geadverteerd moeten worden. Dat "scaled" alleen als je ze kan summarizen. En summarizen werkt alleen goed als het protocol daar goede hulpmiddelen voor biedt. Zoals automated renumbering, locator-identifier separation, betere support for multi-homing, goede mobile ip, etc. En IPv6 heeft daar geen enkele vernieuwing. Dus na een tijdje zullen de global IPv6 routing tabels net zo'n puinhoop zijn als de IPv4 global table. En hoe slordiger er met IPv6 adressen wordt omgesprongen, hoe erger het probleem wordt. End-users merken hier niks van, maar ISPs moeten overbodig dure apparatuur kopen om dit probleem op te lossen.
/64 is absoluut geen beperking bij het routeren inderdaad, maar als hosts in kleinere subnets niet aan een IP-adres kunnen komen schiet het niet op Het gaat om /64, niet /48 overigens. Enige reden om meer dan /64 uit te delen aan een individuele klant is om subnetting mogelijk te maken. Of de grotere providers zo riant gaan uitdelen weet ik niet.
Comcast (VS) biedt klanten een /64 aan, ik vermoed dat XS4All vreemde eend in de bijt zal blijken
Mbt exponentiele groei: ik heb geen idee waar in 2030 of 2040 al die adressen voor gebruikt gaan worden, evenmin als dat iemand in 1985 geraden zou hebben dat we ze nu massaal inzetten voor telefoons en pinautomaten, maar de trend is duidelijk en opmerkelijk constant. Sterker nog, de trend is nu een dramatische onderschatting omdat NAT massaal toegepast wordt - zodra al die apparaten op IPv6 terechtkomen ga je een forse piek boven de verdubbelingstrend uit zien steken.
Het gaat sowieso niet over daadwerkelijke gebruik van alle adressen, slechts van het niet meer kunnen uitdelen ervan. Er zijn etterlijke miljoenen IPv4-adressen die ongebruikt zijn maar toegewezen zijn aan een bedrijf of instantie en dus niet meer uitgedeeld kunnen worden. Datzelfde ga je bij IPv6 nog sterker hebben. Ik weet vrij zeker dat geen enkele XS4All klant daadwerkelijk 1208925819614629174706176 apparaten tegelijk gaat aansluiten, maar hij gaat wel die hele reeks aan adressen bezet houden. ISP's kunnen mogelijk IP's nog teruggrissen bij individuele klanten, maar als een bedrijf eenmaal een reeks te pakken heeft is die reeks weg, ongeacht of ze allemaal gebruikt worden of geen enkele.
Eens mbt scaling. Sterker nog, dat kan de reden zijn waarom men geen netwekern kleiner dan /64 wil
Het gaat om /64, niet /48 overigens. Enige reden om meer dan /64 uit te delen aan een individuele klant is om subnetting mogelijk te maken. Of de grotere providers zo riant gaan uitdelen weet ik niet.Comcast (VS) biedt klanten een /64 aan, ik vermoed dat XS4All vreemde eend in de bijt zal blijken
Mbt exponentiele groei: ik heb geen idee waar in 2030 of 2040 al die adressen voor gebruikt gaan worden, evenmin als dat iemand in 1985 geraden zou hebben dat we ze nu massaal inzetten voor telefoons en pinautomaten, maar de trend is duidelijk en opmerkelijk constant. Sterker nog, de trend is nu een dramatische onderschatting omdat NAT massaal toegepast wordt - zodra al die apparaten op IPv6 terechtkomen ga je een forse piek boven de verdubbelingstrend uit zien steken.
Het gaat sowieso niet over daadwerkelijke gebruik van alle adressen, slechts van het niet meer kunnen uitdelen ervan. Er zijn etterlijke miljoenen IPv4-adressen die ongebruikt zijn maar toegewezen zijn aan een bedrijf of instantie en dus niet meer uitgedeeld kunnen worden. Datzelfde ga je bij IPv6 nog sterker hebben. Ik weet vrij zeker dat geen enkele XS4All klant daadwerkelijk 1208925819614629174706176 apparaten tegelijk gaat aansluiten, maar hij gaat wel die hele reeks aan adressen bezet houden. ISP's kunnen mogelijk IP's nog teruggrissen bij individuele klanten, maar als een bedrijf eenmaal een reeks te pakken heeft is die reeks weg, ongeacht of ze allemaal gebruikt worden of geen enkele.
Eens mbt scaling. Sterker nog, dat kan de reden zijn waarom men geen netwekern kleiner dan /64 wil
[Reactie gewijzigd door dion_b op woensdag 6 juni 2012 14:42]
Dat is een manier om er naar te kijken maar net zo als RIPE en andere ooit aan de bel trokken en simpel weg stelde dat je als ISP niet meer IP's kreeg dan je aantal klanten +25% groei of iets in die richting zal dat ook hier weer gebeuren. 99.99% van de gebruikers van een IPv6 IP zullen op dit moment niet meer dan een handje vol hardware hebben dat ook daadwerkelijk een IP gebruiken kan. Daar van zal het meeste mobiel verbonden zijn en maar een heel erg klein deel via een vaste (Xs4All verbinding lopen) om die reden ook zal het helemaal geen probleem zijn als in de toekomst Xs4All besluit de toegekende adres ruimte te beperken tot een /64 of eventueel zelfs nog kleiner want zo als je zelf al aangeeft een /64 is nog bizar veel IP's die een mens echt in zijn of haar woon/werk omgeving niet allemaal kan gebruiken.
Het is nu simpel weg een luxe verhaal waar ISP's zo extreem veel IP's hebben dat ze van gekkigheid niet meer weten wat ze er mee moeten doen en dus simpel weg enorme blokken aan klanten overhandigen. Het is een kwestie van tijd voor de voorwaarden aan gepast worden en dat simpel weg niet meer kan.
Ooit heeft bijvoorbeeld @Home nu Ziggo klanten tot wel 3 IP's gegeven en als ik het nog goed weet tegen betaling zelfs tot wel 5, ook Xs4All stond gebruikers toe meerdere IP's aan te vragen. Tegenwoordig gebruikt eigenlijk iedere modem een kleine DHCP server die de computers er achter van IP's voorziet en is het het modem dat een publiek IP krijgt.
Dit soort excessen zijn dan ook alleen voor de begin periode waar mensen simpel weg wat te enthousiast zijn wat betreft de beschikbare ruimte.
Het is nu simpel weg een luxe verhaal waar ISP's zo extreem veel IP's hebben dat ze van gekkigheid niet meer weten wat ze er mee moeten doen en dus simpel weg enorme blokken aan klanten overhandigen. Het is een kwestie van tijd voor de voorwaarden aan gepast worden en dat simpel weg niet meer kan.
Ooit heeft bijvoorbeeld @Home nu Ziggo klanten tot wel 3 IP's gegeven en als ik het nog goed weet tegen betaling zelfs tot wel 5, ook Xs4All stond gebruikers toe meerdere IP's aan te vragen. Tegenwoordig gebruikt eigenlijk iedere modem een kleine DHCP server die de computers er achter van IP's voorziet en is het het modem dat een publiek IP krijgt.
Dit soort excessen zijn dan ook alleen voor de begin periode waar mensen simpel weg wat te enthousiast zijn wat betreft de beschikbare ruimte.
Die verdubbeling blijft natuurlijk niet door gaan omdat er niet oneindig veel mensen zijn.
Als je /48 uitgeeft per persoon zijn dat er nog ongeveer 2^15 = ruim 32.000 per persoon.
Als je /48 uitgeeft per persoon zijn dat er nog ongeveer 2^15 = ruim 32.000 per persoon.
dion, Leuk stuk maar u maakt een klein rekenfoutje
Als 32 bits in 32 jaar opgaan gaan 128 bits niet in 4*32 jaar op
Laten we even stellen dat de groei van IPv6 /48 netwerken even snel gaat als de groei van IPv4 adressen.
Dan gaat /48 netwerken dus niet 32 + 16 jaar, maar 32 * 2^16 jaar mee!
Elke bit is namelijk een verdubbeling!
Duuuss.. Als alle registrars nu alleen maar IPv6 /48 netten gaan aanbieden aan iedere individuele klant net zoals ze vroeger losse IPv4 adressen uitdeelden en de groei blijft gelijk dan kunnen we 32 * 65536 = 2^5 * 2^16 = 2^21 jaar mee.
Dat is 2,097,152 ofwel ruim 2 miljoen jaar. Nu zal de groei wel niet gelijk blijven maar toenemen maar dan nog zitten we de eerstkomende paar eeuwen wel goed
PS: resultaten uit het verleden bieden geen garantie voor de toekomst..... Als ze over 100 jaar of zo zandkorrels een IP adres gaan geven gaat het hard ;-)
Edit: in de eerste drafts voor wat uiteindelijk IPv6 zou worden werd nog gesproken over 64-bits adressen. 1 van de redenen waarom het uiteindelijk 128 bits is geworden is is SLAAC
Als 32 bits in 32 jaar opgaan gaan 128 bits niet in 4*32 jaar op
Laten we even stellen dat de groei van IPv6 /48 netwerken even snel gaat als de groei van IPv4 adressen.
Dan gaat /48 netwerken dus niet 32 + 16 jaar, maar 32 * 2^16 jaar mee!
Elke bit is namelijk een verdubbeling!
Duuuss.. Als alle registrars nu alleen maar IPv6 /48 netten gaan aanbieden aan iedere individuele klant net zoals ze vroeger losse IPv4 adressen uitdeelden en de groei blijft gelijk dan kunnen we 32 * 65536 = 2^5 * 2^16 = 2^21 jaar mee.
Dat is 2,097,152 ofwel ruim 2 miljoen jaar. Nu zal de groei wel niet gelijk blijven maar toenemen maar dan nog zitten we de eerstkomende paar eeuwen wel goed
PS: resultaten uit het verleden bieden geen garantie voor de toekomst..... Als ze over 100 jaar of zo zandkorrels een IP adres gaan geven gaat het hard ;-)
Edit: in de eerste drafts voor wat uiteindelijk IPv6 zou worden werd nog gesproken over 64-bits adressen. 1 van de redenen waarom het uiteindelijk 128 bits is geworden is is SLAAC
[Reactie gewijzigd door no-sense op woensdag 6 juni 2012 15:43]
Hij maakt geen rekenfoutje, maar jij maakt een leesfoutje.
Hij zegt dat elk jaar het aantal IP adressen verdubbelt. Dus elk jaar wordt er een bit extra gebruikt. (of het ook echt zal blijven verdubbelen is een ander verhaal)
Hij zegt dat elk jaar het aantal IP adressen verdubbelt. Dus elk jaar wordt er een bit extra gebruikt. (of het ook echt zal blijven verdubbelen is een ander verhaal)
Een /48 uitgeven aan consumenten is helemaal niet verkeerd. Als je uitrekent voor elke aardbewoner (7 miljard) een /48 uitgeven: dan krijg je
((2^80)*(7*10^9) / 2^128) * 100%
is
0,00248689958% van alle adresruimte.
Dus dan heeft iedere aardbewoner 2^80 adressen en dan gebruiken we minder dan 0,01% van alle adressen!
((2^80)*(7*10^9) / 2^128) * 100%
is
0,00248689958% van alle adresruimte.
Dus dan heeft iedere aardbewoner 2^80 adressen en dan gebruiken we minder dan 0,01% van alle adressen!
Misschien heb je ergens geen rekening mee gehouden. Elk jaar een verdubbeling ja, maar dat komt omdat er in het begin zo goed als niemand een adres had, omdat het internet nog niet bestond in 1981. De explosieve groei kon plaatsvinden zolang er grote delen van de bevolking geen aansluiting hadden. Nu heeft bijna iedereen in de ontwikkelde landen een internetaansluiting, dus dat is zo goed als verzadigd. De enige grote groei zit nu in de ontwikkelende landen. Ook die landen zullen op den duur verzadigd raken en dan vlakt de groei af. Ik denk dus dat je helemaal niet uit moet gaan van een verdubbeling elk jaar, maar eerder van een curve die op den duur afvlakt, dus heb je veel minder adressen nodig dan in jouw berekening.Reken maar na, sinds invoering van IPv4 in 1981 zien we grof gezegd elk jaar een verdubbeling van het aantal gebruikte IP-adressen. Na 32 jaar (2013) is het 32b-adresruimte van IPv4 dan ook op. Met IPv6 heb je 2^128, dat zou bij gelijke addressering en gelijke groei genoeg moeten zijn tot 2109
Niet waar. Standaard (tenzij privacy option ingesteld) hoort een IPv6 adres te eindigen met de de 48 bits van het mac adres!
Of beter nog met EUI-64, welke afgeleid is van je MAC adres...
Ook dat is niet helemaal waar.
In een dual stack implementatie bestaat het laatste gedeelte van een IPv6 adres uit je IPv4 adres.
Om de transitie naar IPv6 zo soepel mogelijk te laten verlopen zal er nog heel lang heel veel dual stack gebruikt worden.
Daarnaast zijn
In een dual stack implementatie bestaat het laatste gedeelte van een IPv6 adres uit je IPv4 adres.
Om de transitie naar IPv6 zo soepel mogelijk te laten verlopen zal er nog heel lang heel veel dual stack gebruikt worden.
Daarnaast zijn
Nee, dat is niet helemaal correct, het mag eindigen met je mac adres of de EUI-64 variant daarvan. Het hoort, hoeft of moet niet. Je kan ook gewoon een DHCPv6 server in je netwerk hebben die random adressen uitdeelt, en dat is prima toegestaan. Net zo goed als zelf handmatig statische adressen uitdeelt.Niet waar. Standaard (tenzij privacy option ingesteld) hoort een IPv6 adres te eindigen met de de 48 bits van het mac adres!
Dat de meest gangbare situatie is wat jij omschrijft ( nou ja, EUI-64 vooral dan ), is wel correct. Dat is zo'n beetje standaard, en ik denk voor de meeste consumenten aansluitingen ook de toekomst. Maar 'het hoort' is iets te zwaar, je hebt er veel vrijheid in.
Offtopic maar relevant:
Yep. Hoe dan ook, zonder NAT zijn tracking-cookies straks dus ook niet eens meer nodig
Yep. Hoe dan ook, zonder NAT zijn tracking-cookies straks dus ook niet eens meer nodig
[Reactie gewijzigd door BramT op woensdag 6 juni 2012 13:58]
Da's niet waar :-)Offtopic maar relevant:
Yep. Hoe dan ook, zonder NAT zijn tracking-cookies straks dus ook niet eens meer nodig
De meeste OS'en hebben standaard de privacy extensies aan staan, en dan genereert het OS iedere zoveel tijd random een nieuw IPV6 adres als alias op je nic naast het echte (bijvoorbeeld EUI-64) adres. En op dat adres doen je ontbound applicaties dingen. Ook je webbrowser, etc.
Ze kunnen je net zoals nu pinnen op een aansluiting, door middel van de eerste 3 segmenten. Maar zeker als je met meerdere mensen en devices achter een verbinding zit, zegt dat niets. Ik weet het niet zeker of Windows na XP en android dat doen, maar OS X vanaf Lion en iOS sinds 5.0 zeker wel.
"hoort" ?
Waar in de RFC's staat een 'SHOULD' die dit aanbeveelt?
Waar in de RFC's staat een 'SHOULD' die dit aanbeveelt?
MAC adressen blijven bestaan zoals ze al bestaan, IPv6 is geen reden om daar verandering in te brengen.
Vergeet niet dat IPv4 32-bit is; het is niet zo dat het MAC adres gelijk moet zijn aan het IPvn adres qua bits.
Vergeet niet dat IPv4 32-bit is; het is niet zo dat het MAC adres gelijk moet zijn aan het IPvn adres qua bits.
Dit is zeer goed mogelijk.
Dit noemt men EUI-64 adressering.
Als je router / switch hiervoor is ingesteld, dan krijg je als client de prefix, en dan met een combinatie van je MAC address word automatisch een uniek adres gemaakt. (uniek, er bestaat een heel kleine kans dat dit niet zo is).
Heb laatst nog enkele labo omgevingen nagemaak voor ipv6 en deze feature vond ik zeer handig.
http://wiki.nil.com/IPv6_EUI-64_interface_addressing
http://packetlife.net/blog/2008/aug/4/eui-64-ipv6/
Dit noemt men EUI-64 adressering.
Als je router / switch hiervoor is ingesteld, dan krijg je als client de prefix, en dan met een combinatie van je MAC address word automatisch een uniek adres gemaakt. (uniek, er bestaat een heel kleine kans dat dit niet zo is).
Heb laatst nog enkele labo omgevingen nagemaak voor ipv6 en deze feature vond ik zeer handig.
http://wiki.nil.com/IPv6_EUI-64_interface_addressing
http://packetlife.net/blog/2008/aug/4/eui-64-ipv6/
Laag 2 (MAC-adres) zal het spreekwoordelijke worst zijn wat de payload (het bovenliggende laag 3 pakket) is. Wat dat betreft verandert er niets met de komst van IPv6.
Wat echter wel voorzien is in IPv6, is dat het laag2 MAC-adres (met een kleine vertaalslag) een deel van het IPv6 adres wordt. De voorste 64 bits zijn dan het netwerkdeel van het IP-adres en de achterste 64bits zijn dan het hostdeel (en die achterste 64 bits zijn dus afgeleid van het 48 bits MAC-adres). Op die manier heeft een host genoeg aan het ontvangen van het netwerkadres (via router-advertisements) om automatisch een uniek adres te maken.
Deze methode van werken -al vast gelegd in standaarden- zorgt er wel voor dat het aantal bruikbare ipv6-adressen significant afneemt. Zo heb ik thuis een gerouteerd ipv6 netwerkje dat een /64 subnetmasker heeft. Ik heb daarom dus 128-64=64 bits over voor de aansluitingen binnen dat ene subnet. 2^64, dat is 2^32 keer zo groot als de huidige ipv4 ruimte. Iets zegt me dus dat ik die NOOIT (ik dit geval durf ik nooit te zeggen) nodig zal hebben.
edit: typo's
Wat echter wel voorzien is in IPv6, is dat het laag2 MAC-adres (met een kleine vertaalslag) een deel van het IPv6 adres wordt. De voorste 64 bits zijn dan het netwerkdeel van het IP-adres en de achterste 64bits zijn dan het hostdeel (en die achterste 64 bits zijn dus afgeleid van het 48 bits MAC-adres). Op die manier heeft een host genoeg aan het ontvangen van het netwerkadres (via router-advertisements) om automatisch een uniek adres te maken.
Deze methode van werken -al vast gelegd in standaarden- zorgt er wel voor dat het aantal bruikbare ipv6-adressen significant afneemt. Zo heb ik thuis een gerouteerd ipv6 netwerkje dat een /64 subnetmasker heeft. Ik heb daarom dus 128-64=64 bits over voor de aansluitingen binnen dat ene subnet. 2^64, dat is 2^32 keer zo groot als de huidige ipv4 ruimte. Iets zegt me dus dat ik die NOOIT (ik dit geval durf ik nooit te zeggen) nodig zal hebben.
edit: typo's
[Reactie gewijzigd door whatevernow op woensdag 6 juni 2012 13:14]
Eens kijken hoe kleinere ISP's hierop gaan reageren. Hoe snel zij zullen overgaan.
[Reactie gewijzigd door Xmoo op woensdag 6 juni 2012 11:48]
De grote DSL jongens lijken er nog niet echt zin in te hebben xs4all daargelaten.
Hoe zit het eigenlijk met DSL modems en ipv6? Ik heb hier een retro Tele2 bak staan.
Hoe zit het eigenlijk met DSL modems en ipv6? Ik heb hier een retro Tele2 bak staan.
Ik zou zeggen duik er eens in of pak de handleiding. Als het een wat nieuwer apparaat is zou die het moeten ondersteunen. Beetje research had wel gemogen.
Mijn Fritz!box 7340 doet 't al een ruim een jaar prima op een native IPv6 verbinding, maar dat is op een xs4all lijn, waarvan we al wisten dat 't kon. Draytek Vigor's schijnen het ook prima te doen, en Cisco's ook.Hoe zit het eigenlijk met DSL modems en ipv6? Ik heb hier een retro Tele2 bak staan.
Voor de rest vind ik 't angstaanjagend stil op dat vlak.
Aan de kabelkant is het vrij simpel. Alle Docsis/EuroDocsis 3.0 kabelmodems die al een paar jaar worden verspreid ondersteunen IPv6. Het zal alleen vaak aan de ISP liggen om het van afstand in te schakelen. Het heeft als consument niet veel zin (als het uberhaupt al kan) om het in te schakelen als de ISP het aan de andere kant nog niet heeft ingeschakeld.
Mijn Franse provider Free is al een paar jaar over (DSL), maar moet zeggen dat ik er niks van merk en alles intern op mn netwerk gewoon nog via ipv4 heb geconfigureerd.
Intern zul je toch altijd gewoon alles via ipv4 configureren....
hoe kom je daarbij? ik heb thuis juist alles op ipv6 zitten. Ben je gelijk van alle NAT onzin af! geen gezeik meer met collisions in private ip ranges als je vpn tunnels gebruikt. Ik vind het heerlijk!
Overigens is XS4all dus niet de enige, op de Universiteit Twente is er al jaren een native ipv6 netwerk beschikbaar. utwente.nl haalt dan ook 5 sterren op de ipv6 check!
Overigens is XS4all dus niet de enige, op de Universiteit Twente is er al jaren een native ipv6 netwerk beschikbaar. utwente.nl haalt dan ook 5 sterren op de ipv6 check!
Waarom zou je in godsnaam? Het enige wat je nog nodig hebt is een goede firewall
of je moet al dd-wrt hebben, deze kan dan een ipv4 aan je router geven, en de DhCPv6 requests door sturen aan je echte pc's, waardoor je router min of meer een bridge/switch wordt
Dat verwacht ik ook nog erg lang.
Ik weet niet precies hoe het zit als je bv het scenario wat ik nu heb heb.
Modem(ziggo) -> router (LAN DHCP) -> lan (ipv4)
Ik kan de router gewoon ipv6 laten uitdelen. En de pc's zullen dan gewoon werken. Maar dat heeft geen nut als je lokale ipv6 krijgt.
Dus logischerwijs gebruik je dan de DHCP van de modem. Of kan je de router zo instellen dat hij deze binnen een range uitdeelt welke je van de provider hebt gekregen.
Ik weet niet precies hoe het zit als je bv het scenario wat ik nu heb heb.
Modem(ziggo) -> router (LAN DHCP) -> lan (ipv4)
Ik kan de router gewoon ipv6 laten uitdelen. En de pc's zullen dan gewoon werken. Maar dat heeft geen nut als je lokale ipv6 krijgt.
Dus logischerwijs gebruik je dan de DHCP van de modem. Of kan je de router zo instellen dat hij deze binnen een range uitdeelt welke je van de provider hebt gekregen.
6 juni voor de Ipv6 day waarbij 66 internetproviders meedoen. Vooral het laatste is een leuk toeval
Ik hoop dat de providers wel snel over zijn. Maar geeft dat nog extra werk voor ze mee, behalve een schakelaar omzetten? Moeten providers nu voor Ipv4 sites de boel voor Ipv6 gebruikers converteren?
Ik hoop dat de providers wel snel over zijn. Maar geeft dat nog extra werk voor ze mee, behalve een schakelaar omzetten? Moeten providers nu voor Ipv4 sites de boel voor Ipv6 gebruikers converteren?
Indien nodig dient er een vinkje aangezet te worden op je network adapter.
En je thuis netwerk, lees modem en router moeten compatible zijn met IPv6
Volgens mij zou het daarna gewoon moeten werken!
En je thuis netwerk, lees modem en router moeten compatible zijn met IPv6
Volgens mij zou het daarna gewoon moeten werken!
Wat ik heb begrepen is dat het als het ware twee verschillende internets (internetten?) zijn. als v4 kan je niet op v6 en viceversa je zou dus via een proxy of protocolconverter moeten werken. (geen idee of het bestaat/kan, ik speculeer het terplekke).
Dat converteren lijkt mij niet waarschijnlijk van wegen de extra kosten die dit denk ik mee brengt.
Vermoedelijk zal voor een X periode een aantal websites wel, niet en dubbel te bereiken zijn afhankelijk van de versie die beschikbaar is op de host en de provider.
Maar waneer de meesten/iedereen over zijn/is en alles via v6 gaat, zal v4 dan een old school netwerk worden? of zal gewoon geen enkel ISP meer v4 ondersteunen?
Dat converteren lijkt mij niet waarschijnlijk van wegen de extra kosten die dit denk ik mee brengt.
Vermoedelijk zal voor een X periode een aantal websites wel, niet en dubbel te bereiken zijn afhankelijk van de versie die beschikbaar is op de host en de provider.
Maar waneer de meesten/iedereen over zijn/is en alles via v6 gaat, zal v4 dan een old school netwerk worden? of zal gewoon geen enkel ISP meer v4 ondersteunen?
Er bestaan brokers tussen IPv4 en IPv6 en die zullen dan vooral bij jouw ISP staan. Overigens is dat geen ideale situatie, aangezien het vrijwel altijd eenrichtings geiniteerd verkeer is zoals bv. bij NAT. Dus dual-stack netwerk-apparatuur die dus zowel IPv4 als IPv6 tegelijkertijd ondersteunen hebben de voorkeur.
Die brokers zul je dus alleen tijdeljik aantreffen bij grote providers die geen zin/geld hebben om alle modems in een keer te vervangen.
Zie hiervoor wat voorbeelden voor ISP oplossingen: http://aimp.apec.org/Docu...0_tel41_dsg_wksp2_012.pdf
edit: linkje toegevoegt
Die brokers zul je dus alleen tijdeljik aantreffen bij grote providers die geen zin/geld hebben om alle modems in een keer te vervangen.
Zie hiervoor wat voorbeelden voor ISP oplossingen: http://aimp.apec.org/Docu...0_tel41_dsg_wksp2_012.pdf
edit: linkje toegevoegt
[Reactie gewijzigd door RitBit op woensdag 6 juni 2012 12:08]
Er zullen gewoon tunnels worden opgezet en pakketten in pakketten.
Voor IPv6 over IPv4 infrastructure zal meestal 6RD gebruikt worden en voor IPv4 over IPv6 infrastructure DS-Lite
Voor IPv6 over IPv4 infrastructure zal meestal 6RD gebruikt worden en voor IPv4 over IPv6 infrastructure DS-Lite
Kabel internet providers zullen op grote schaal DHCP6 uitrollen, ook een aantal ADSL providers gaan DHCP6 gebruiken in plaats van tunnels.
Simpel. Het kost ze anders 2 keer geld om te migreren. Dan beter in 1 keer naar native IPv6 zonder tunnel.
Simpel. Het kost ze anders 2 keer geld om te migreren. Dan beter in 1 keer naar native IPv6 zonder tunnel.
Dan heb je nog steeds DS Lite nodig voor je klanten die op je IPV6 infrastructure zijn aangesloten omdat ze anders simpelweg niet meer kunnen verbinden met IPv4 websites.
En aangezien je niet al je klanten in 1 keer van je IPv4 netwerk naar je IPv6 netwerk gaat migreren heb je wellicht ook nog 6RD nodig.
En denk dat ze eerder SLAAC gebruiken dan DHCPv6
En aangezien je niet al je klanten in 1 keer van je IPv4 netwerk naar je IPv6 netwerk gaat migreren heb je wellicht ook nog 6RD nodig.
En denk dat ze eerder SLAAC gebruiken dan DHCPv6
SLAAC is aan de binnenkant van de CPE (het klant netwerk dus), voor hoe je ISP je verteld wat je aan IPv6 hebt zijn andere methoden waaronder DHCPv6 en router advertisements. Die laatste zou mijn router automatisch een /64 pakken, maar hij krijgt netjes een /48 toegekend., dus het zal wel DHCPv6 zijn, ook omdat er een leasetijd aan hangt.En denk dat ze eerder SLAAC gebruiken dan DHCPv6
Helaas is het niet een enkele schakelaar. Ten eerste moeten ze uitzoeken OF de systemen IPv6-support hebben (moderne OS-en hebben dan bijna allemaal, maar denk ook aan routers en ander netwerkcomponenten).
Als dat zo is dan kunnen ze gaan voor een dual-stack situatie, waarbij zowel IPv6 als IPv4 actief zijn op betrokken componenten. Dit betekent testen, het maken van nummerplannen, implementatieplannen, aanpassen van firewall-rulez, herconfiguren DHCP enz enz enz. Ook de opnamen van alle adressen in DNS verdient aandacht omdat een zin als "de 133.20.1.1 router heeft een probleem" niet meer de formuleren is.
Je moet het zien als het activeren van een geheel nieuw netwerk (op laag 3) naast een bestaand netwerk. En dus later ook het gelijktijd supporten en onderhouden van 2 netwerken (en dus meer kosten maken). Kortom: het is een flinke opgave... vandaar dat niet iedereen zo happig is.
edit: typo's
Als dat zo is dan kunnen ze gaan voor een dual-stack situatie, waarbij zowel IPv6 als IPv4 actief zijn op betrokken componenten. Dit betekent testen, het maken van nummerplannen, implementatieplannen, aanpassen van firewall-rulez, herconfiguren DHCP enz enz enz. Ook de opnamen van alle adressen in DNS verdient aandacht omdat een zin als "de 133.20.1.1 router heeft een probleem" niet meer de formuleren is.
Je moet het zien als het activeren van een geheel nieuw netwerk (op laag 3) naast een bestaand netwerk. En dus later ook het gelijktijd supporten en onderhouden van 2 netwerken (en dus meer kosten maken). Kortom: het is een flinke opgave... vandaar dat niet iedereen zo happig is.
edit: typo's
[Reactie gewijzigd door whatevernow op woensdag 6 juni 2012 13:20]
IPv6 had al een slechte naam (niet backwards compatible, eigenlijk niet nodig, onefficient) en met al die 6en maken ze het nog des duivels ook.
niet backwards compatible: klopt
eigenlijk niet nodig: klopt niet, vind ik
onefficient: nee.
De header van IPv6 t.o.v. IPv4 is zodanig herontworpen dat de forwarding van pakketten (een van de twee belangrijke taken van een router) SNELLER (efficienter) is. Zo is bijv. de checksum verdwenen (die in ipv4 door elke route opnieuw uitgerekend moet worden ivm gewijzigde TTL). Ook fragmentatie wordt niet meer gesupport in IPv6 .. en ook dat scheelt rekenwerk.
eigenlijk niet nodig: klopt niet, vind ik
onefficient: nee.
De header van IPv6 t.o.v. IPv4 is zodanig herontworpen dat de forwarding van pakketten (een van de twee belangrijke taken van een router) SNELLER (efficienter) is. Zo is bijv. de checksum verdwenen (die in ipv4 door elke route opnieuw uitgerekend moet worden ivm gewijzigde TTL). Ook fragmentatie wordt niet meer gesupport in IPv6 .. en ook dat scheelt rekenwerk.
Onzin.De header van IPv6 t.o.v. IPv4 is zodanig herontworpen dat de forwarding van pakketten (een van de twee belangrijke taken van een router) SNELLER (efficienter) is.
Heb je ooit software geschreven die packet-forwarding doet ?
IPv6 headers zijn groter.
IPv6 adressen zijn groter.
Dat betekent dat je er minder van kunt opslaan in de cache van je processor. En low-end, en zelfs mid-size routers gebruiken gewone processors met cache. De beperkende factor bij packet-forwarding door zulke processoren is memory-access/cache-access. Hoe minder je gebruik kunt maken van je processor-cache, hoe langzamer forwarding is.
Onzin !!!!Zo is bijv. de checksum verdwenen (die in ipv4 door elke route opnieuw uitgerekend moet worden ivm gewijzigde TTL).
Weet je hoe die checksum werkt ?
De IPv4-header-checksum is een simpele optelling van de bytes in de IP header. Dat heeft een mooie bijwerking voor het herberekenen van de checksum nadat je de TTL gewijzigd hebt.
Namelijk, als je de TTL met 1 verminderdt, moet je ook gewoon de IPv4-header-checksum gewoon met 1 verminderen. Dat is alles ! 1 Instructie ! De header zit toch al in je processor cache als je -1 op de TTL doet. Dus de -1 op de hdrchksum is ook zo gedaan.
Dat het ontbreken van de checksum IPv6 sneller zou maken is allemaal lulkoek. Gedaan door mensen die nog nooit een algorithme hebben ontworpen, of real-world code hebben geschreven. Dezelfde soort lui dus die IPv6 hebben ontworpen.
Heb je enig idee welke algorithmes worden gebruikt om een adres op te zoeken in een forwarding table ? Enig idee hoe dat anders is (zou kunnen zijn) tussen IPv4 en IPv6 ?
IPv4 heeft mtu-discovery. Net als IPv6. Wat op grote schaal gebruikt wordt. Fragmentation is geen issue in de werkelijke wereld.Ook fragmentatie wordt niet meer gesupport in IPv6 .. en ook dat scheelt rekenwerk.
Bovendien is het probleem van fragmentatie gebrek aan memory, niet gebrek aan rekenkracht.
eigenlijk niet nodig? zonder ip-adressen redden we het ook wel? voor het voortbestaan van het internet is het zeker nodig. over efficiëntie kan ik niet zeggen ..
Er zijn aanhangers van de "NATTEN tot je niet meer kan" theorie
Ook leuk: http://ip6.nl Hier op de Universiteit Twente zijn we er dus klaar voor 
Sowieso kunnen alle gebruikers die IPv6 gebruiken ook IPv4 gebruiken (zolang ze zelf maar een IPv4 adres hebben).
Het meeste werk zit hem in de apparatuur, deze moet IPv6 ondersteunen.
Voor zover ik weet, begint het voor huis-tuin-en-keukerouters en -modems nu pas een beetje te lopen.
Het meeste werk zit hem in de apparatuur, deze moet IPv6 ondersteunen.
Voor zover ik weet, begint het voor huis-tuin-en-keukerouters en -modems nu pas een beetje te lopen.
Het probleem met huis tuin en keuken routers is niet native IPv6. Dit zit al jaren in de linux kernel meegebakken wat in de meeste routertjes gebruikt wordt. Het grootste probleem was de support voor transition mechanisms.
Pas toen de ISP's icm de cisco's van deze wereld besloten hadden om DS-Lite te gebruiken en 6RD (in tegenstelling tot bv 4-in-6 en 6-in-4 of 6to4 of elk van de willekeurig andere 74 smaken voor transition mogelijkheden) konden de huis tuin en keuken router bouwertjes aan hun firmwares gaan werken.
Pas toen de ISP's icm de cisco's van deze wereld besloten hadden om DS-Lite te gebruiken en 6RD (in tegenstelling tot bv 4-in-6 en 6-in-4 of 6to4 of elk van de willekeurig andere 74 smaken voor transition mogelijkheden) konden de huis tuin en keuken router bouwertjes aan hun firmwares gaan werken.
Eindelijk kan ik het Ipv6 verkeer op men firewall dan eens naar boven zien gaan. Momenteel was dit minder dan 2% van alle verkeer. Google is inderdaad al enige tijd bereikbaar via IPv6.
Het zal tijd worden dat iedereen eens mee overstapt op dit protocol. De andere oplossing zoals een extra NAT doen voor je klanten zijn uiteindelijk maar lap middeltjes. Het is jammer dat deze implementatie zo lang op zich heeft laten wachten.
Het zal tijd worden dat iedereen eens mee overstapt op dit protocol. De andere oplossing zoals een extra NAT doen voor je klanten zijn uiteindelijk maar lap middeltjes. Het is jammer dat deze implementatie zo lang op zich heeft laten wachten.
Dit is nog wel redelijk interessant: http://www.youtube.com/watch?v=lMcf6LxMgYI
Het komt allemaal maar langzaam van de grond met IPv6. Logisch, bedrijven gaan pas ergens geld insteken en moeite doen als ze echt pijn beginnen te voelen en dat is blijkbaar nog niet zo.
Ik kan me herinneren dat er vorig jaar hoog van de toren werd geblazen dat de IPv4 adressen op zouden raken, maar dat bleek toch niet meteen tot grote problemen te leiden omdat er nog dingen zoals NAT mogelijk zijn waardoor het gebruik van IPv4 nog jarenlang gerekt kan worden.
Maar nu krijgt een bedrijf als UPC het blijkbaar toch echt moeilijk met het tekort aan IPv4 adressen.
Ik kan me herinneren dat er vorig jaar hoog van de toren werd geblazen dat de IPv4 adressen op zouden raken, maar dat bleek toch niet meteen tot grote problemen te leiden omdat er nog dingen zoals NAT mogelijk zijn waardoor het gebruik van IPv4 nog jarenlang gerekt kan worden.
Maar nu krijgt een bedrijf als UPC het blijkbaar toch echt moeilijk met het tekort aan IPv4 adressen.
[Reactie gewijzigd door jj71 op woensdag 6 juni 2012 11:55]
Nog beschikbare Europese Ipv4 adressen: http://www.ripe.net/inter...ipv4-available-pool-graph
En evt. voor meer informatie: http://www.ripe.net/internet-coordination/ipv4-exhaustion
En evt. voor meer informatie: http://www.ripe.net/internet-coordination/ipv4-exhaustion
Ja, wacht even maar als RIPE adressen uitgeeft betekent dat nog niet dat ze ook in gebruik zijn, daar kan nogal een verschil tussen zitten.
De nood in Azië is het grootst. Daarom zullen bedrijven die zaken doen met bedrijven in Azië als eerste IPv6 gaan draaien. Er ontstaan nu steeds meer eilandjes van IPv6 en na verloop van tijd zal IPv6 de overhand hebben op IPv4. Het is een glijdende schaal.
Met Dual Stack kan je prima IPv6 naast IPv4 draaien. IPv4 zal nog jaren naast IPv6 bestaan en zijn we afhankelijk van technieken als tunnelen, LISP en NAT om IPv6 met IPv6 en IPv4 met IPv6 te laten praten.
Met Dual Stack kan je prima IPv6 naast IPv4 draaien. IPv4 zal nog jaren naast IPv6 bestaan en zijn we afhankelijk van technieken als tunnelen, LISP en NAT om IPv6 met IPv6 en IPv4 met IPv6 te laten praten.
Raar dan dat mijn Chinese TP-Link router geen ipv6 doet, terwijl mijn Amerikaanse Cisco dat wel doet
Probleem voor veel isp's is ook dat veel routers/ modems helemaal geen ipv6 aankunnen en die dus eerst bij alle klanten vervangen moeten worden. Ook thuisnetwerkjes hangen vaak nog aan apparatuur wat daar helemaal niet geschikt voor is.
Zelfs veelgebruikte routers als de TP-Link WR1043 hebben (nog) geen ipv6 ondersteuning.
Zelfs veelgebruikte routers als de TP-Link WR1043 hebben (nog) geen ipv6 ondersteuning.
En ik zie consumenten niet zomaar hun thuisnetwerk aanpassen / vervangen.
IPv6 zal nog wel een tijdje op zich laten wachten of de providers moeten iets verzinnen waardoor thuisnetwerken kunnen blijven werken...
IPv6 zal nog wel een tijdje op zich laten wachten of de providers moeten iets verzinnen waardoor thuisnetwerken kunnen blijven werken...
Het is niet onmogelijk om er wat voor de verzinnen: Ziggo heeft vorig jaar iedereen nog een nieuwe docsis3 modem met ingebouwde wifi-router gegeven (in bruikleen, maar toch). Keurig ipv6-compatible allemaal. Dat consumenten niet klaar zijn hoeft voor Ziggo dus geen argument te zijn iig.
Ik mag dan wel tweaker zijn en het liefst ook op IPv6 gaan draaien, punt is dat me dat gewoonweg in de portemonnee zou gaan raken.
M'n router, een D-Link DIR-855, is niet IPv6-compatible en krijgt ook geen update van D-Link. Ik zou dus een nieuwe moeten kopen maar dan wil ik wel een gelijkwaardige of betere router en zit ik dus al snel over de 100 euro heen.
En m'n intern netwerk... stel dat ik dat ook op IPv6 zou willen laten overgaan. Ik weet niet of de PlayStation 3 al IPv6-compatible is maar dat zal nog wel volgen mag ik hopen. Maar bv. mijn IP bewakingscamera ondersteunt alleen IPv4 en ik voorzie niet dat daar een update voor komt.
Ik heb iig wel begrepen dat Ziggo haar bestaande IPv4 klanten op IPv4 laat zitten. Vraag me af of dat voor altijd is... wordt IPv4 niet ooit uitgefaseerd in de toekomst?
M'n router, een D-Link DIR-855, is niet IPv6-compatible en krijgt ook geen update van D-Link. Ik zou dus een nieuwe moeten kopen maar dan wil ik wel een gelijkwaardige of betere router en zit ik dus al snel over de 100 euro heen.
En m'n intern netwerk... stel dat ik dat ook op IPv6 zou willen laten overgaan. Ik weet niet of de PlayStation 3 al IPv6-compatible is maar dat zal nog wel volgen mag ik hopen. Maar bv. mijn IP bewakingscamera ondersteunt alleen IPv4 en ik voorzie niet dat daar een update voor komt.
Ik heb iig wel begrepen dat Ziggo haar bestaande IPv4 klanten op IPv4 laat zitten. Vraag me af of dat voor altijd is... wordt IPv4 niet ooit uitgefaseerd in de toekomst?
Ooit wordt IPv4 natuurlijk uitgefaseerd. Maar de tijd dat het echt uitgezet wordt is je DIR-855 al lang met pensioen. Zolang er nog devices zijn die enkel IPv4 aankunnen zal het nog nodig zijn om IPv4 in een of andere vorm aan te bieden.
Die uitfasering zal veel sneller beginnen aangezien linksom of rechtsom de IPv4-adressen op zijn en je dus niet meer iedereen een eigen publieke IPv4 kunt geven.
Kijk bijvoorbeeld naar Comcast (ISP in de VS) die nieuwe klanten "DS-Lite" aanbiedt, dus IPv6 native plus IPv4 via CG-NAT (Carrier Grade NAT). Zo kunnen ze met een enkele IPv4 honderden klanten aansluiten. Nadeel is dus dat ze op IPv4 allemaal achter NAT zitten, maar met IPv6 hebben ze wel volledige internettoegang.
Iets vergeljkbaars ga je zien bij de ISP's in NL: DS-Lite oid voor nieuwe abonnees, die dus geen eigen publieke IPv4-adres meer krijgen, en full dual stack voor bestaande abonnees die hun huidige IPv4-adres behouden en er een IPv6 prefix naast krijgen.
Die DIR-855 gaat trouwens lang voordat je je IPv4-adres kwijtraakt op een andere manier raken: zodra er IPv6-only resources op internet zijn, moet je IPv6 hebben om erbij te kunnen. Als jouw router geen IPv6 ondersteunt zul je - ook al biedt Ziggo je IPv6 aan - toch via een tunnel moeten gaan om erbij te kunnen, en die tunnel moet je op je PC opzetten, dat kan niet op de router die geen IPv6 praat.
Die uitfasering zal veel sneller beginnen aangezien linksom of rechtsom de IPv4-adressen op zijn en je dus niet meer iedereen een eigen publieke IPv4 kunt geven.
Kijk bijvoorbeeld naar Comcast (ISP in de VS) die nieuwe klanten "DS-Lite" aanbiedt, dus IPv6 native plus IPv4 via CG-NAT (Carrier Grade NAT). Zo kunnen ze met een enkele IPv4 honderden klanten aansluiten. Nadeel is dus dat ze op IPv4 allemaal achter NAT zitten, maar met IPv6 hebben ze wel volledige internettoegang.
Iets vergeljkbaars ga je zien bij de ISP's in NL: DS-Lite oid voor nieuwe abonnees, die dus geen eigen publieke IPv4-adres meer krijgen, en full dual stack voor bestaande abonnees die hun huidige IPv4-adres behouden en er een IPv6 prefix naast krijgen.
Die DIR-855 gaat trouwens lang voordat je je IPv4-adres kwijtraakt op een andere manier raken: zodra er IPv6-only resources op internet zijn, moet je IPv6 hebben om erbij te kunnen. Als jouw router geen IPv6 ondersteunt zul je - ook al biedt Ziggo je IPv6 aan - toch via een tunnel moeten gaan om erbij te kunnen, en die tunnel moet je op je PC opzetten, dat kan niet op de router die geen IPv6 praat.
Geen zorgen, er komt vanzelf een snellere Wireless variant van je modem dat je wel wil hebben. En _daar_ zit IPv6 dan weer wel in.
Wat Dlink en Linksys afgesproken hebben is dat al het nieuwe spul altijd IPv6 ondersteunt.
De Xbox of playstation krijgt nog wel een keer een update waar IPv6 ondersteuning in zou kunnen zitten. Je kan thuis prima die bewakingscamera blijven gebruiken.
Het is wel zo dat we nu op het punt zijn aangekomen dat elk zichzelf respecterende fabrikant wel nieuwe producten met aan gaat bieden. Dat was een jaar geleden niet zo.
Ziggo gaat het in eerste instantie voor nieuwe abonnees aanzetten, wellicht dat er later een knop in het service center voor komt.
Wat Dlink en Linksys afgesproken hebben is dat al het nieuwe spul altijd IPv6 ondersteunt.
De Xbox of playstation krijgt nog wel een keer een update waar IPv6 ondersteuning in zou kunnen zitten. Je kan thuis prima die bewakingscamera blijven gebruiken.
Het is wel zo dat we nu op het punt zijn aangekomen dat elk zichzelf respecterende fabrikant wel nieuwe producten met aan gaat bieden. Dat was een jaar geleden niet zo.
Ziggo gaat het in eerste instantie voor nieuwe abonnees aanzetten, wellicht dat er later een knop in het service center voor komt.
Ik heb een D-Link DIR-655, die weliswaar geen native IPv6 verbinding kan opzetten maar probleemloos proto-41 (6in4) kan forwarden. Als je ergens een Linux servertje in je LAN hebt staan kun je kostenloos IPv6 gaan gebruiken, d.m.v. een 6in4 tunnel. Het is dan niet native, maar werkt snel en probleemloos in mijn ervaring. Zolang je ISP nog geen native v6 levert, is dit alles wat je als Tweaker nodig hebt.
Ik heb dus een gratis 6in4 tunnel aangevraagd bij sixxs.net. Mijn servertje bouwt deze tunnel naar sixxs op. Om te zorgen dat de tunnel bidirectioneel werkt moet je router weten waar inkomende pakketjes naartoe moeten. In mijn DIR-655 heb ik proto-41 (de in IPv4 ingepakte IPv6 pakketjes) geforward naar mijn servertje. Vergelijkbaar met port-forwarding, alleen doe je het nu met een protocol. Deze haalt de IPv6 pakketjes uit de tunnel en forward ze naar het LAN.
Effectief heb je dus twee verschillende gateways. Je router is de default gateway voor IPv4 pakketten, en je server is de default gateway voor IPv6 pakketten. Voor je LAN is het verder onzichtbaar dat ze daarna een tunnel ingeschoten worden en alsnog via je IPv4 gateway de wijde wereld in gaan.
Op je servertje kun je radvd installeren waarmee de clients op je LAN d.m.v. autoconfiguration van IPv6 adressen worden voorzien. Dit werkt iets anders dan IPv4's DHCP, maar de analogie is voor nu goed genoeg.
Let er wel op dat je bij IPv6 niet meer 'by default' beschermt wordt door NAT als een soort pseudo-firewall. Al die miljarden adressen die je krijgt zijn 'globally routable'. Het volledige IPv6 netblock dat door sixxs naar je tunnel gerouteerd wordt kan dus van buiten bereikt worden. Je moet het eindpunt van je tunnel dus zien als een potentiële ingang van je netwerk, dus moet je een IPv6 firewall installeren met een default-deny policy. Ik gebruik hiervoor Shorewall6.
Het klinkt misschien overweldigend, maar is heel goed te doen voor een Tweaker, en kost je niks als je de server al hebt staan. Een leerzame ervaring.
Ik heb dus een gratis 6in4 tunnel aangevraagd bij sixxs.net. Mijn servertje bouwt deze tunnel naar sixxs op. Om te zorgen dat de tunnel bidirectioneel werkt moet je router weten waar inkomende pakketjes naartoe moeten. In mijn DIR-655 heb ik proto-41 (de in IPv4 ingepakte IPv6 pakketjes) geforward naar mijn servertje. Vergelijkbaar met port-forwarding, alleen doe je het nu met een protocol. Deze haalt de IPv6 pakketjes uit de tunnel en forward ze naar het LAN.
Effectief heb je dus twee verschillende gateways. Je router is de default gateway voor IPv4 pakketten, en je server is de default gateway voor IPv6 pakketten. Voor je LAN is het verder onzichtbaar dat ze daarna een tunnel ingeschoten worden en alsnog via je IPv4 gateway de wijde wereld in gaan.
Op je servertje kun je radvd installeren waarmee de clients op je LAN d.m.v. autoconfiguration van IPv6 adressen worden voorzien. Dit werkt iets anders dan IPv4's DHCP, maar de analogie is voor nu goed genoeg.
Let er wel op dat je bij IPv6 niet meer 'by default' beschermt wordt door NAT als een soort pseudo-firewall. Al die miljarden adressen die je krijgt zijn 'globally routable'. Het volledige IPv6 netblock dat door sixxs naar je tunnel gerouteerd wordt kan dus van buiten bereikt worden. Je moet het eindpunt van je tunnel dus zien als een potentiële ingang van je netwerk, dus moet je een IPv6 firewall installeren met een default-deny policy. Ik gebruik hiervoor Shorewall6.
Het klinkt misschien overweldigend, maar is heel goed te doen voor een Tweaker, en kost je niks als je de server al hebt staan. Een leerzame ervaring.
beste idee zou zijn om alle websites om te zetten al die miljoenen ip4 adressen waar de websites op draaien komen van vrij voor privegebruik en de provider kan aan zijn kant doorlinken naar de websites.
waardoor er thuis ip4 gebruikt kan worden en websites ip6 gebruiken.
al is ook dat een tijdelijk oplossing.
ook het offline halen van inactieve websites van domijn hoggers scheeld miljoenen ip adressen.
het is immers te gek voor woordendat er vele miljoenen sites opgekocht worden en vervolgens inactief het web staan te vervuilen totdat iemand een smak geld voor een domein van 6 euro betaald.
waardoor er thuis ip4 gebruikt kan worden en websites ip6 gebruiken.
al is ook dat een tijdelijk oplossing.
ook het offline halen van inactieve websites van domijn hoggers scheeld miljoenen ip adressen.
het is immers te gek voor woordendat er vele miljoenen sites opgekocht worden en vervolgens inactief het web staan te vervuilen totdat iemand een smak geld voor een domein van 6 euro betaald.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
