UPC schuift introductie ipv6 door naar medio 2013
Kabelaar UPC zal het eerder aangekondigde streven om ipv6 nog dit jaar uit te gaan rollen, niet halen. UPC verwacht de 'ipv4-opvolger' op zijn vroegst medio 2013 aan te zullen gaan bieden, mede omdat moederbedrijf Liberty Global nog voldoende ipv4-adressen in handen zou hebben.
Begin dit jaar kondigde UPC aan dat het voornemens was om nog dit jaar ipv6-adressen aan met name nieuwe klanten te verstrekken omdat de ipv4-adresvoorraad uitgeput dreigde te raken. De kabelaar laat echter desgevraagd aan Tweakers weten dat ipv6 dit jaar niet ingevoerd zal gaan worden op het internetnetwerk van de kabelaar. Als reden noemt woordvoerder Ronald Sutmuller van UPC dat het bedrijf nog voldoende ipv4-adressen in voorraad heeft. Deze zijn afkomstig uit de ipv4-adresvoorraad die in handen is van moederbedrijf Liberty Global.
UPC zal volgens Sutmuller vermoedelijk medio 2013 beginnen met het uitdelen van ipv6-adressen, circa een half jaar later dan de eerdere plannen. Het bedrijf laat dit ook op zijn website weten. Momenteel is de kabelaar nog steeds bezig met het testen van ipv6, maar klanten krijgen nog geen ipv6-adres toebedeeld.
Volgens Sutmuller blijkt dat UPC-klanten in de praktijk nog geen problemen ervaren door het ontbreken van een ipv6-adres en dat het bij een ipv6-uitrol 'niet gaat om een wedstrijd'. Wel belooft de internetprovider de ontwikkelingen bij de wereldwijde implementatie van ipv6 nauwgezet te blijven volgen en mogelijk de uitrol te zullen versnellen als klanten bijvoorbeeld websites niet kunnen opvragen die uitsluitend via ipv6 zijn te bereiken.
Naast UPC heeft ook Ziggo eerder dit jaar aangegeven dat het in 2012 nog ipv6 wil gaan aanbieden. Het is nog niet duidelijk of Ziggo dit streven zal gaan halen voor de consumentenmarkt; aan grootzakelijke klanten levert Ziggo al wel ipv6. De plannen van KPN met ipv6 zijn eveneens nog niet helder; alleen KPN-dochter Xs4all biedt zijn klanten een native ipv6-adres aan.
Reacties (101)
Standaard bij UPC, eerst iets aankondigen en dan als t puntje bij paaltje komt weer UITSTELLEN!,
zal waarschijnlijk ergens in 2014 worden echter ik denk dat t dan nig niet bug-vrij zal werken!!
(net als Horizon!)
zal waarschijnlijk ergens in 2014 worden echter ik denk dat t dan nig niet bug-vrij zal werken!!
(net als Horizon!)
Beetje raar waarom je -1 krijg, want je hebt gewoon gelijk, Binnekort kan bij upc zo 2a3 jaar duren, ipv6 idem binnekort binnekort, 3jaar later en nog niet, idem met updates voor oude boxen binnekort binnekort, 2,7jaar later nog geen update en zo kan ik nog wel een doorgaan.
Er is voor UPC dan ook helemaal geen reden voor haast...
IPv6 moet (voornamelijk) problemen met de beschikbaarheid van adressen oplossen. Die problemen spelen niet of nauwelijks bij de 'kabelaars', omdat die netwerken nauwelijks meer groeien. Vooral in Azie en bij mobiele operators kunnen de adressen opraken vanwege de enorme groei die die netwerken doormaken. UPC en ook Ziggo groeien niet meer in aantallen klanten, alleen nog in de diensten die ze bij die klanten wegzetten. Ze hoeven dus geen grote hoeveelheden adressen uit te delen...
Zowel UPC als ook Ziggo maken dus weinig haast: de klant schiet er bijna niets mee op, of gaat er juist op achteruit: als al mijn devices niet meer achter een NAT router staan moet ik veel meer aandacht besteden aan de beveiliging van mijn interne netwerk dan dat ik nu doe. En als ik daar al geen zin in heb - dan waarschijnlijk de overgrote meerderheid van de niet-Tweakers ook niet.
Verder zal niet alleen de beveiliging op IPv6 voor UPC/Ziggo klanten een issue zijn - ook zullen ze meer apparaten moeten herconfigureren om ze nog op het netwerk terug te vinden: netwerk printer, mediaspeler, NAS: met IPv4 nog wel te onthouden via het IP adres - via IPv6 lukt dat echt niet meer...
Kortom: wellicht misleidend van UPC dat ze hun deadline niet halen - maar ook niet meer dan dat...
IPv6 moet (voornamelijk) problemen met de beschikbaarheid van adressen oplossen. Die problemen spelen niet of nauwelijks bij de 'kabelaars', omdat die netwerken nauwelijks meer groeien. Vooral in Azie en bij mobiele operators kunnen de adressen opraken vanwege de enorme groei die die netwerken doormaken. UPC en ook Ziggo groeien niet meer in aantallen klanten, alleen nog in de diensten die ze bij die klanten wegzetten. Ze hoeven dus geen grote hoeveelheden adressen uit te delen...
Zowel UPC als ook Ziggo maken dus weinig haast: de klant schiet er bijna niets mee op, of gaat er juist op achteruit: als al mijn devices niet meer achter een NAT router staan moet ik veel meer aandacht besteden aan de beveiliging van mijn interne netwerk dan dat ik nu doe. En als ik daar al geen zin in heb - dan waarschijnlijk de overgrote meerderheid van de niet-Tweakers ook niet.
Verder zal niet alleen de beveiliging op IPv6 voor UPC/Ziggo klanten een issue zijn - ook zullen ze meer apparaten moeten herconfigureren om ze nog op het netwerk terug te vinden: netwerk printer, mediaspeler, NAS: met IPv4 nog wel te onthouden via het IP adres - via IPv6 lukt dat echt niet meer...
Kortom: wellicht misleidend van UPC dat ze hun deadline niet halen - maar ook niet meer dan dat...
[Reactie gewijzigd door Tukkertje-RaH op maandag 26 november 2012 15:19]
een nadeel wat je kan gaan krijgen is dat er sites of andere zaken niet meer beschikbaar zijn als er geen IPv4 adressen worden uitgedeeld kunnen worden..
IPv4 praat volgens mij niet zomaar met IPv6 en visa versa
uiteraard zal dit probleem zich niet vandaag of morgen voordoen, maar van uitstel komt afstel, of in iedergeval nog meer uitstel tot dat ze wel over moeten; Persoonlijk vind ik dat een hele kwalijke zaak.. Zorg er als service provider maar voor dat je bij de tijd bent en niet met de hakken over de sloot gaat..
Het is niet alsof IPv6 sinds een jaar bestaat..
IPv4 praat volgens mij niet zomaar met IPv6 en visa versa
uiteraard zal dit probleem zich niet vandaag of morgen voordoen, maar van uitstel komt afstel, of in iedergeval nog meer uitstel tot dat ze wel over moeten; Persoonlijk vind ik dat een hele kwalijke zaak.. Zorg er als service provider maar voor dat je bij de tijd bent en niet met de hakken over de sloot gaat..
Het is niet alsof IPv6 sinds een jaar bestaat..
Dat probleem wordt op twee manieren afgevangen:een nadeel wat je kan gaan krijgen is dat er sites of andere zaken niet meer beschikbaar zijn als er geen IPv4 adressen worden uitgedeeld kunnen worden..
IPv4 praat volgens mij niet zomaar met IPv6 en visa versa
Ten eerste is er simpelweg 'dual-stack': zowel een IPv4 als een IPv6 stack naast elkaar draaien. Hierdoor heeft de klant een IPv4 adres en een blok IPv6 adressen. Voorlopig zijn er nog IPv4 adressen voldoende, waardoor deze oplossing de voorkeur geniet voor maximale backwards compatibility.
Op een later moment is het mogelijk om IPv4 te tunnelen door IPv6. Het nadeel hiervan is dat de klant zelf geen IPv4 diensten meer kan hosten. Het voordeel is dat per klant geen IPv4 adres meer uitgegeven hoeft te worden.
Om dual stack te draaien moet je wel IPv6 adressen uitdelen naar je klanten. Dat deel hebben ze dus uitgesteld bij UPC.
Bij UPC wordt geen dual stack gebruikt, maar DSLite (Dual Stack Lite).
[Reactie gewijzigd door musiman op maandag 26 november 2012 21:06]
Omdat nog niemand het een +1 heeft gegeven? Je hebt trouwens maar half gelijk.
als upc genoeg adressen heeft waarom kon ik in mijn upc dagen dan geen 2e ip kreigen zonder een kvk nummer op te geven
nu zit ik bij een andere netwerk levarncier (Regfiber) en precies dezelfde KUT smoezen, mijn eigen internet verbinding, is niet eens berijkbaar over ip6, en ik kan NOOIT genoeg ip4 adressen krijgen om alle machines via het internet te kunnen berijken.
en voor de mensen die het niet snappen NAT is geen firewall. dus waar blijven mijn (minstens 16) publieke adressen?
xs4all bied er geloof ik een paar duizend per klant en dat vind ik ook wel wat overdreven,
nu zit ik bij een andere netwerk levarncier (Regfiber) en precies dezelfde KUT smoezen, mijn eigen internet verbinding, is niet eens berijkbaar over ip6, en ik kan NOOIT genoeg ip4 adressen krijgen om alle machines via het internet te kunnen berijken.
en voor de mensen die het niet snappen NAT is geen firewall. dus waar blijven mijn (minstens 16) publieke adressen?
xs4all bied er geloof ik een paar duizend per klant en dat vind ik ook wel wat overdreven,
SCHRIJF JE JE TOCH IN...
UPC Heeft er genoeg, maar voor meerdere ip-adressen heb je gewoon een zakelijk account nodig bij UPC. Dat is een regel die zij hanteren en die zij niet speciaal voor 1 klant zullen gaan breken. Wij hebben dan ook gewoon een zakelijk abonnement met 4 ip-adressen bij UPC.
Als je op IPv6 doelt: ze geven je als gebruiker een /48. Wat neerkomt op 655536 subnetten van een /64 formaat. (Het kleinste subnet dat er is voor v6)xs4all bied er geloof ik een paar duizend per klant en dat vind ik ook wel wat overdreven,
Een /64 bevat 18,446,744,073,709,551,616 IPv6 addressen.
een paar duizend IP-adressen per klant moet gaan over IPv6...
bij IPv6 is het volgens mij gebruikelijk dat je een /64 krijgt, met iets van 65.000 adressen.
Geen 2e IP krijgen gaat over IPv4, en dat is een wereld van verschil met IPv6.
Waar heb je dan ook 16-ip-adressen voor nodig op een thuis-aansluiting?
want op een business-aansluiting is het geen probleem om 16 of zelfs 32 (of nog meer) ip-adressen te krijgen, je moet er alleen wel flink de portemonnee voor trekken!
bij IPv6 is het volgens mij gebruikelijk dat je een /64 krijgt, met iets van 65.000 adressen.
Geen 2e IP krijgen gaat over IPv4, en dat is een wereld van verschil met IPv6.
Waar heb je dan ook 16-ip-adressen voor nodig op een thuis-aansluiting?
want op een business-aansluiting is het geen probleem om 16 of zelfs 32 (of nog meer) ip-adressen te krijgen, je moet er alleen wel flink de portemonnee voor trekken!
Een /64 adres betekend dat je nog 64 bits over hebt (128-64=64). Daar binnen kun je dus 2^64=18446744073709551616 ip adressen toewijzen.
Wat een makkelijke oplossing daarvoor is, is gewoon een domeinnaam registeren.
Je zet de IPv6 van je eigen zaken in de DNS, zoals router.domeinnaam.nl naar 192.168.0.1 (als het IPv4 is). Ipv. dat je de IPv4 adres invult doe je gewoon de IPv6. Vergeet btw niet dat IPv6 een andere record vereist dan IPv4.
Als je op Tweakers.net kan komen, registeren enz. dan is een domeinnaam registeren en de DNS instellen niet veel moeilijker, het wordt namelijk al zo makkelijk gemaakt door de meeste registrars. Bedoel als je bedenkt hoeveel Nederlanders als domeinnaam hebben is zelfs voor de "niet-Tweakers" niet zo moeilijk.
Maar goed het kost je dan wel paar euro per jaar.
(ik kan foutje maken vanwege de IP range maar zover ik weet kan het gewoon)
Je zet de IPv6 van je eigen zaken in de DNS, zoals router.domeinnaam.nl naar 192.168.0.1 (als het IPv4 is). Ipv. dat je de IPv4 adres invult doe je gewoon de IPv6. Vergeet btw niet dat IPv6 een andere record vereist dan IPv4.
Als je op Tweakers.net kan komen, registeren enz. dan is een domeinnaam registeren en de DNS instellen niet veel moeilijker, het wordt namelijk al zo makkelijk gemaakt door de meeste registrars. Bedoel als je bedenkt hoeveel Nederlanders als domeinnaam hebben is zelfs voor de "niet-Tweakers" niet zo moeilijk.
Maar goed het kost je dan wel paar euro per jaar.
(ik kan foutje maken vanwege de IP range maar zover ik weet kan het gewoon)
Alsof UPC daarin uniek is.
Kan me van KPN nog herinneren dat ze beloofden om een nieuwe FW uit te brengen om alle problemen met de PS3 op te lossen.
Is die er eigenlijk ooit gekomen ??
Kan me van KPN nog herinneren dat ze beloofden om een nieuwe FW uit te brengen om alle problemen met de PS3 op te lossen.
Is die er eigenlijk ooit gekomen ??
Ja, die is er wel gekomen, maar natuurlijk veel te laat zoals altijd. Als de ene 'bug' is opgelost staat de volgende al weer te wachten. Standaard bij die k.t modem/gateway 'experiabox' van KPN. gewoon een andere betere router plaatsen is het beste. Het PS3 verhaal heeft met NAT level 2 te maken.
Wil dat zeggen dat meteen ook ieder apparaat in een huishouden een eigen extern IP krijgt, of delen ze dan nog steeds een IP uit aan het modem wat vervolgens met NAT weer gewoon IP adressen (hetzij ipv4 hetzij ipv6) aan de apparaten uitdeelt?
In principe krijgt iedereen binnen je huishouden dan een extern IP. Nat zou dan verleden tijd zijn. Idealiter vervang je DHCP door router advertisement ( http://tools.ietf.org/html/rfc4861). Je router broadcast een prefix over het lokale netwerk waarmee iedere client (aan de hand van de prefix en zijn eigen MAC adres) een eigen, globaal uniek IPV6 adres berekent.
Dit wil zeggen dat al je computers dus globaal bereikbaar zijn. Je router wordt hiermee een echte 'router', en heeft dus de NAT functionaliteit niet meer nodig. Als je dus de veiligheid van een NAT wilt bewaren zul je een firewall op je router moeten voorzien die alle binnenkomende connecties blokkeert.
Edit/Correctie: DHCP bestaat nog wel voor IPV6
Dit wil zeggen dat al je computers dus globaal bereikbaar zijn. Je router wordt hiermee een echte 'router', en heeft dus de NAT functionaliteit niet meer nodig. Als je dus de veiligheid van een NAT wilt bewaren zul je een firewall op je router moeten voorzien die alle binnenkomende connecties blokkeert.
Edit/Correctie: DHCP bestaat nog wel voor IPV6
[Reactie gewijzigd door perre op maandag 26 november 2012 14:38]
Gelukkig hebben veel (profesionele) routers deze functie al jaren on-board. Nu nog mensen ze leren configureren. (of te wel, hoe maak je deze zo dat mensen ze kunnen configureren)
Niet alleen hoe mensen ze kunnen configureren is één zaak dat belangrijk is.
Juist door het toepassen van NAT, zetten veel consumenten hun firewall van computers en laptops uit. Straks met de komst van IPv6 is dat weer noodzakelijk omdat iedere computer/laptop straks in feite - dankzij IPv6 rechtstreeks aan het internet hangt.
Ik zie hier straks toch echt ongelofelijk grote problemen in ontstaan.
Zelf heb ik n.l. al eens geëxperimenteerd met IPv6 via Sixxs, UPC en Ziggo (allen beiden ze n.l. wel gewoon tunnels aan) en ik moet eerlijk zeggen; eenvoudig is het nog zo net niet. Bestanden & Printers delen in je eigen netwerk via IPv6 is kinderlijk eenvoudig, maar omdat IPv6 buiten je firewall omgaat zijn deze bronnen ook direct te benaderen via internet - tenzij ik hier iets over het hoofd zie.
Juist door het toepassen van NAT, zetten veel consumenten hun firewall van computers en laptops uit. Straks met de komst van IPv6 is dat weer noodzakelijk omdat iedere computer/laptop straks in feite - dankzij IPv6 rechtstreeks aan het internet hangt.
Ik zie hier straks toch echt ongelofelijk grote problemen in ontstaan.
Zelf heb ik n.l. al eens geëxperimenteerd met IPv6 via Sixxs, UPC en Ziggo (allen beiden ze n.l. wel gewoon tunnels aan) en ik moet eerlijk zeggen; eenvoudig is het nog zo net niet. Bestanden & Printers delen in je eigen netwerk via IPv6 is kinderlijk eenvoudig, maar omdat IPv6 buiten je firewall omgaat zijn deze bronnen ook direct te benaderen via internet - tenzij ik hier iets over het hoofd zie.
waarom? je kunt toch nog steeds gewoon op je router een firewall draaien? NAT is echt niet de manier om je netwerk te beschermen, het is eigenlijk gewoon een HACK, met als bijwerking dat het netwerk erachter niet direct bereikbaar is. Echter, als je denkt dat je door NAT veilig bent, dan zit je er goed naast! er zijn plenty technieken om gaten in een genatte firewall te prikken!
9 op de 10 consumenten heeft nauwelijks verstand van een firewall laat staan een NAT voor hun is het gewoon een of ander programma wat een pc beschermt. Tevens lijkt mij NAT niet echt een bescherm middel het verbergt weliswaar je intern netwerk maar er zijn zat andere technieken die hier een omweg voor vinden.
Als zijnde een vervangen voor dit middel is wellicht een summary naar de buiten wereld te adverteren zodat niet iedereen weet wat er achter je router/modem zit. In elk geval de toekomst zal het leren
Als zijnde een vervangen voor dit middel is wellicht een summary naar de buiten wereld te adverteren zodat niet iedereen weet wat er achter je router/modem zit. In elk geval de toekomst zal het leren
Veel consumenten denken juist dat routers veiligheid creëert doordat er een lokaal (afgeschermd) netwerk wordt gebouwd waarbij in de router een firewall aanwezig is die standaard vaak ingeschakeld staat.
NAT + Firewall (iptables) = schijnveiligheid ... true, maar maak dat de consument eens duidelijk.
Met de komt van IPv6 (zoals ik hiermee geëxperimenteerd heb) verwacht ik dat het instellen van een firewall in geval van IPv6 complexer zal gaan worden. Ieder IPv6 adres zal straks apart geconfigureerd moeten worden in geval van bijvoorbeeld P2P. Dit zie ik consumenten nog niet zo gauw doen.
NAT + Firewall (iptables) = schijnveiligheid ... true, maar maak dat de consument eens duidelijk.
Met de komt van IPv6 (zoals ik hiermee geëxperimenteerd heb) verwacht ik dat het instellen van een firewall in geval van IPv6 complexer zal gaan worden. Ieder IPv6 adres zal straks apart geconfigureerd moeten worden in geval van bijvoorbeeld P2P. Dit zie ik consumenten nog niet zo gauw doen.
Je kan gemakkelijk het gedrag achter NAT nabootsen in je IPv6 firewall op de router. Enkel lokaal (lan) geïnitieerde connecties toelaat en enkel vanuit het internet naar lokaal degene die related of established zijn . Simpel genoeg.
[Reactie gewijzigd door analog_ op maandag 26 november 2012 22:59]
Niet helemaal waar. In de IP6 standaarden is daar rekening mee gehouden. Standaard hoort een IP6 router zo zijn ingesteld dat van buiten naar binnen niet mogelijk is. Wil je het anders, dan moet je het zelf instellen. Wat dat betreft werkt het hetzelfde als een IP4 NAT. Daar kun je ook niet zondermeer van buiten naar binnen. Diensten als LogMeIn werken alleen, omdat er van binnen uit (dus op je eigen PC) een verbinding met de server gemaakt wordt en via die verbinding kun je weer terug.Juist door het toepassen van NAT, zetten veel consumenten hun firewall van computers en laptops uit. Straks met de komst van IPv6 is dat weer noodzakelijk omdat iedere computer/laptop straks in feite - dankzij IPv6 rechtstreeks aan het internet hangt.
DHCP voor IPv6 bestaat wel degelijk en een router advertisement kan zelfs zeggen dat je DHCPv6 moet gebruiken (daar kunnen nl. meer waardes mee verstuurd worden, zoals NTP-servers en zo)
Maar inderdaad, voor thuisgebruik is dat vaak overkill, en is router advertisement + RFC6106 (voor de DNS-server) genoeg.
Maar inderdaad, voor thuisgebruik is dat vaak overkill, en is router advertisement + RFC6106 (voor de DNS-server) genoeg.
Je kunt meer waarden versturen, maar NTP servers is zover ik weet ook in IPv4 standaard. Option 42 als ik het goed gok.
[Reactie gewijzigd door Fairy op maandag 26 november 2012 15:22]
Vermoedelijk gewoon via NAT. Bij XS4ALL kun je het in ieder geval wel zo laten werken volgens mij.
[Reactie gewijzigd door Killer op maandag 26 november 2012 14:39]
Die vraag zul je moeten stellen aan UPC, het hangt er namelijk van af hoe hun design qua ipv6 in elkaar steekt. Dat kan voor elke provider anders zijn.
Gezien de mogelijke hoeveelheid adressen zou je zeggen van wel, maar je haalt wel een laag beveiliging weg omdat er niet meer genat wordt.
Gezien de mogelijke hoeveelheid adressen zou je zeggen van wel, maar je haalt wel een laag beveiliging weg omdat er niet meer genat wordt.
NAT is geen beveiliging.
http://www.nexusuk.org/articles/2005/03/12/nat_security/
http://www.nexusuk.org/articles/2005/03/12/nat_security/
Zoals het gammele artikel zelf al aangeeft : "Admittedly it's pretty unlikely that the ISP will have their routers misconfigured like this. "
Sterker nog, in de meeste gevallen dat je NAT gebruikt :
a) heeft de ISP geen eens een idee welke interne IP-adressen je gebruikt, wat het wat moeilijk maakt om die routers dermate absurd te configureren;
b) gebruik je intern IP-adressen uit de niet-routeerbare reeksen 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16 en, die op het internet door geen enkele router zouden moeten worden gerouteerd, en zeker niet worden gerouteerd door de routers die je op het internet tegenkomt;
c) zal een fatsoenlijke NAT-router op het NAT-interface nog steeds geen pakketjes accepteren voor een intern IP-adres.
Terwijl NAT niet alleenzaligmakend is, doet het een verduiveld goede job om je af te schermen van de buitenwereld.
Sterker nog, in de meeste gevallen dat je NAT gebruikt :
a) heeft de ISP geen eens een idee welke interne IP-adressen je gebruikt, wat het wat moeilijk maakt om die routers dermate absurd te configureren;
b) gebruik je intern IP-adressen uit de niet-routeerbare reeksen 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16 en, die op het internet door geen enkele router zouden moeten worden gerouteerd, en zeker niet worden gerouteerd door de routers die je op het internet tegenkomt;
c) zal een fatsoenlijke NAT-router op het NAT-interface nog steeds geen pakketjes accepteren voor een intern IP-adres.
Terwijl NAT niet alleenzaligmakend is, doet het een verduiveld goede job om je af te schermen van de buitenwereld.
Dit wordt iedere keer geroepen bij de discussie over ipv6. Maar feit is dat NAT er voor zorgt dat de buitenwereld niet weet hoeveel apparaten er in je netwerk aanwezig zijn en welk van die apparaten in je netwerk bepaalde activiteiten ontplooit.NAT is geen beveiliging.
Het afschermen van dergelijk informatie is ook een vorm van beveiliging.
(En ja, ik weet dat NAT daarin ook niet 100% zeker is. )
Ik zie dus echt nog wel een rol voor ipv6 + NAT in verband met beveiliging.
waarom? als je een goed geconfigureerde firewall hebt, kan je prima instellen welke connecties wel en welke niet mogen. Ook dan kan de buitenwereld niet zien welke apparaten je thuis allemaal hebt. NAT voegt wat mji betreft niets toe aan IPV6
Dat weet de buitenwereld ook met IPv6 niet, hoe moet-de dat weten? Alleen als je een knettergekke router hebt die extern verkeer ongefilterd doorstuurt naar inderne ipv6 adressen.Maar feit is dat NAT er voor zorgt dat de buitenwereld niet weet hoeveel apparaten er in je netwerk aanwezig zijn
Bij UPC wordt IPv6 niet geNAT, maar het IPv4 verkeer wordt wél geNAT. Nu echter niet meer op je eigen routertje, maar op een router van de provider. Dit heet: Carrier Grade NAT (CGN).
Tussen jouw router en die van de provider wordt over hun IPv6 wolk een IPv4 tunneltje gebouwd en jouw lokale adressen worden gerouteerd met de IPv4 range die in deze tunnel gebruikt wordt. Bij de AFTR (=de router van UPC) vindt NAT plaats waarbij je gebruik maakt van een pool IPv4 adressen en zo naar het internet gaat. Je deelt dus met andere gebruikers die pool IPv4 adressen.
Tussen jouw router en die van de provider wordt over hun IPv6 wolk een IPv4 tunneltje gebouwd en jouw lokale adressen worden gerouteerd met de IPv4 range die in deze tunnel gebruikt wordt. Bij de AFTR (=de router van UPC) vindt NAT plaats waarbij je gebruik maakt van een pool IPv4 adressen en zo naar het internet gaat. Je deelt dus met andere gebruikers die pool IPv4 adressen.
[Reactie gewijzigd door musiman op maandag 26 november 2012 21:06]
Het wil zeggen dat je iig genoeg adressen krijgt om alles een extern adres te geven. Maar je kan natuurlijk nog steeds dingen achter een nat zetten als je dat wilt of als dat nodig is.
was bedoeld als reactie op jeroen.
was bedoeld als reactie op jeroen.
[Reactie gewijzigd door haarbal op maandag 26 november 2012 14:32]
Dit klopt. Alle apparaten krijgen een uniek adres. Wat nog niet (automatisch) betekent dat deze vanaf overal te benaderen is.
Sommige routers firewallen standaard inkomend IPv6 verkeer, net als nu al het geval is met IPv4. Meestal kunnen deze in het service center van de internet provider, of direct in het modem aangepast worden. Daar kan de firewall aangepast of uitgezet worden als je dat zou willen.
Anno 2012 is de situatie van de firewalls op de Windows en Apple computers een stuk beter, en standaard meegeleverd. Het is zeer zeker niet te vergelijken met 1995 (Windows 95/98/ME en consorten).
Sommige routers firewallen standaard inkomend IPv6 verkeer, net als nu al het geval is met IPv4. Meestal kunnen deze in het service center van de internet provider, of direct in het modem aangepast worden. Daar kan de firewall aangepast of uitgezet worden als je dat zou willen.
Anno 2012 is de situatie van de firewalls op de Windows en Apple computers een stuk beter, en standaard meegeleverd. Het is zeer zeker niet te vergelijken met 1995 (Windows 95/98/ME en consorten).
Eigenlijk heb ik maar twee woorden nodig om dit uit te leggen, maar het antwoord is Prefix Delegation.
De router krijgt een IPv6- prefix toegewezen en deelt zelf IP- adressen uit in die range. Dat kan weer zijn met behulp van Router Advertisements of DHCPv6. De router krijgt zijn prefix via DHCPv6, via RA's kan dit mechanisme namelijk niet werken.
ISP's 'moeten' (vastgelegd in RFC 6177) namelijk minimaal een /64 subnet aanbieden aan klanten, een /56 subnet wordt aangeraden. Er mag dus geen /128 (één enkel adres) worden aangeboden. Onder andere omdat NAT tot het verleden moet gaan behoren.
De router krijgt een IPv6- prefix toegewezen en deelt zelf IP- adressen uit in die range. Dat kan weer zijn met behulp van Router Advertisements of DHCPv6. De router krijgt zijn prefix via DHCPv6, via RA's kan dit mechanisme namelijk niet werken.
ISP's 'moeten' (vastgelegd in RFC 6177) namelijk minimaal een /64 subnet aanbieden aan klanten, een /56 subnet wordt aangeraden. Er mag dus geen /128 (één enkel adres) worden aangeboden. Onder andere omdat NAT tot het verleden moet gaan behoren.
[Reactie gewijzigd door Jaap-Jan op maandag 26 november 2012 15:03]
Waar in welke RFC staat dat ISP /64 moeten geven?
Moet je smartphone dan ook een /64 krijgen aangezien telecomproviders in feite ook gewoon ISP's zijn.
Overgens heeft UPC het al een paar keer uitgesteld, ik heb zo uit me hoofd medio 2011, zomer van 2012 eind 2012 al voorbij zien komen.
Moet je smartphone dan ook een /64 krijgen aangezien telecomproviders in feite ook gewoon ISP's zijn.
Overgens heeft UPC het al een paar keer uitgesteld, ik heb zo uit me hoofd medio 2011, zomer van 2012 eind 2012 al voorbij zien komen.
[Reactie gewijzigd door itarix op maandag 26 november 2012 14:50]
Ten eerste: Ik doelde op thuisgebruik, niet op mobiele providers. Maar om je vraag te beantwoorden: het is voor het eerst vastgelegd in RFC 3177.
Ik hoop alleen niet dat ze /64's gaan uitdelen. Ik heb zelf thuis een gastnetwerk (ook op IPv6). Dat zou ik graag gescheiden willen houden van mijn privénetwerk (al draait het op dezelfde router) en toch een internetverbinding aan willen bieden zonder NAT. Zonder subnets is dat niet mogelijk. Ik hoop dat ISP's op zijn minst een /56 aanbieden aan klanten.
RFC 6177 draait dit voor een deel weer terug. Omdat het gaat over 'end sites' (oftewel: een huis, een kantoor) wordt het niet aangeraden om een /128 uit te delen. RFC 6177 draait meer om redelijkheid:This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
Voor een telefoon (waar ik overigens niet op doelde), is een /128 wel redelijk, al maakt het tethering wel onmogelijk (zonder NAT). Het gaat er immers om dat er geen tekort aan adressen optreden. RFC 6177 spreekt van minimaal een /64 voor end sites indien het zeker is dat er geen subnets nodig zijn (/64 is de minimale grootte van een subnet, namelijk).A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
Ik hoop alleen niet dat ze /64's gaan uitdelen. Ik heb zelf thuis een gastnetwerk (ook op IPv6). Dat zou ik graag gescheiden willen houden van mijn privénetwerk (al draait het op dezelfde router) en toch een internetverbinding aan willen bieden zonder NAT. Zonder subnets is dat niet mogelijk. Ik hoop dat ISP's op zijn minst een /56 aanbieden aan klanten.
[Reactie gewijzigd door Jaap-Jan op maandag 26 november 2012 15:24]
RFC's vormen geen verplichting, ISP's kunnen daar zonder probleem van afwijken tenzij organisaties zoals RIPE ze daartoe verplichten.
Sommige RFCs zijn echt wel een verplichting. Als je iets wilt, dan MOET je het op een bepaalde manier doen. Dat wordt in de RFCs aangegeven. Er is verschil tussen MUST, SHOULD en MAY. Zie http://www.ietf.org/rfc/rfc2119.txt
RFC6177 heeft niet een keer MUST, SHOULD of MAY in de text staan.
Bovendien is RFC6177 een zgn BCP: Best Current Practice.
Een aanbeveling dus. En dat hoeft niet eens een onomstreden aanbeveling te zijn.
Met andere woorden, Itarix heeft gelijk. Nergens staat dat je per se een /64 moet uitdelen.
RFC6177 heeft niet een keer MUST, SHOULD of MAY in de text staan.
Bovendien is RFC6177 een zgn BCP: Best Current Practice.
Een aanbeveling dus. En dat hoeft niet eens een onomstreden aanbeveling te zijn.
Met andere woorden, Itarix heeft gelijk. Nergens staat dat je per se een /64 moet uitdelen.
De aanbeveling is dat het minstens een /64 is, maar dat een /48 overdreven is. De consensus (belangerijk in RFC's) is een /56. Minder dan een /64 mag niet.Met andere woorden, Itarix heeft gelijk. Nergens staat dat je per se een /64 moet uitdelen.
RFC 3177 heeft het over de allocatie door RIRs. Niet hoe een ISP een eindgebruiker moet behandelen.
RFC 6177 is een BCP. Zonder enige MUSTs. Dat zegt dus niks.
Consensus tussen RFCs is onzin. Het is geen "meeste stemmen gelden".
"Rough consensus and working code" heeft hier niks mee te maken.
Ik ben zelf nog van de tijd voor CIDR. Ik zat (in Montreal '96) toevallig nog bij de allerlaatste meeting van de CIDR workinggroup tijdens de IETF. VLSM, supernetting, CIDR, gaat er allemaal over hoe je bits zo optimaal mogelijk gebruikt.
Nu hebben we IPv6, en kan opeens niemand meer met bits rekenen. Moeten de "subnetten" opeens weer op 8-bit boundaries liggen. We zijn 20 jaar terug in de tijd. Stelletje amateurs.
RFC 6177 is een BCP. Zonder enige MUSTs. Dat zegt dus niks.
Consensus tussen RFCs is onzin. Het is geen "meeste stemmen gelden".
"Rough consensus and working code" heeft hier niks mee te maken.
Ik ben zelf nog van de tijd voor CIDR. Ik zat (in Montreal '96) toevallig nog bij de allerlaatste meeting van de CIDR workinggroup tijdens de IETF. VLSM, supernetting, CIDR, gaat er allemaal over hoe je bits zo optimaal mogelijk gebruikt.
Nu hebben we IPv6, en kan opeens niemand meer met bits rekenen. Moeten de "subnetten" opeens weer op 8-bit boundaries liggen. We zijn 20 jaar terug in de tijd. Stelletje amateurs.
[Reactie gewijzigd door gryz op maandag 26 november 2012 18:39]
RFC's zijn WET voor het internet, vergis je daar niet in, daar zit heel weinig vrijblijvendheid in. Dat er organisaties zijn als RIPE is meer voor de administratieve afhandeling en registratie, maar ze doen nog veel meer goeie dingen. (Zoals onderzoek)RFC's vormen geen verplichting, ISP's kunnen daar zonder probleem van afwijken tenzij organisaties zoals RIPE ze daartoe verplichten.
IPv6 adressen (en prefixes) hebben (maximaal) 128 bits.Ik hoop alleen niet dat ze /64's gaan uitdelen.
.....
Zonder subnets is dat niet mogelijk. Ik hoop dat ISP's op zijn minst een /56 aanbieden aan klanten.
Het is gebruikelijk om de laaste 48 bits aan het host-part te spenderen.
Dan hou je een prefix van 80 bits over.
Als jij een /64 krijgt, dan heb je 16 bits over om zelf je subnetten uit te snijden.
Een /56 is nergens voor nodig.
Wat je hier wilt is met IPv6 helemaal niet mogelijk.
Met IPv6 kun je namelijk geen IPv6 subnets maken die bijvoorbeeld /80 zijn.
De prefix length voor een IPv6 subnet is altijd /64.
Als je dan een /64 krijgt dan heb je maar 1 subnet tot je beschikking en meer niet.
Vandaar dat men hier ook aangeeft dat een /56 gewenst is zodat je meerdere subnetten kan maken.
Met IPv6 kun je namelijk geen IPv6 subnets maken die bijvoorbeeld /80 zijn.
De prefix length voor een IPv6 subnet is altijd /64.
Als je dan een /64 krijgt dan heb je maar 1 subnet tot je beschikking en meer niet.
Vandaar dat men hier ook aangeeft dat een /56 gewenst is zodat je meerdere subnetten kan maken.
Edit:
Arggg.
Wat ik eerst schreef gaat over de praktijk.
Maar in theorie heb je gelijk.
http://www.ietf.org/rfc/rfc3513.txt
2.5.1 Interface Identifiers
[/quote]For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.[/quote]
En dus blijven er slechts 64 bits over voor de prefix.
Wat een ramp.
-----
Wat ik in eerste instantie schreef:
Niet waar.
Even googlen:
http://seclists.org/nanog/2011/Jun/525
http://tools.ietf.org/rfc/rfc3627.txt
Daar wordt gesproken over /126 en /127 prefixes.
Duidelijke voorbeelden van prefixes langer dan 64 bits.
Ik dacht al, een max prefix-length zou ons terugbrengen naar de dagen van classfull routing (20 jaar terug in de tijd dus).
Ik blijf bij wat ik een paar posts terug schreef:
Een hoop IPv6 luitjes schijnen moeite te hebben met binair rekenen.
En daarom misschien willen ze alles op 8-bit boundaries hebben.
Amateurs.
Arggg.
Wat ik eerst schreef gaat over de praktijk.
Maar in theorie heb je gelijk.
http://www.ietf.org/rfc/rfc3513.txt
2.5.1 Interface Identifiers
[/quote]For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.[/quote]
En dus blijven er slechts 64 bits over voor de prefix.
Wat een ramp.
-----
Wat ik in eerste instantie schreef:
Niet waar.
Even googlen:
http://seclists.org/nanog/2011/Jun/525
Die post haalt ook RFC3627 aan.The use of a 64-bit prefix is a requirement if using Stateless
addressing, nothing more.
http://tools.ietf.org/rfc/rfc3627.txt
Daar wordt gesproken over /126 en /127 prefixes.
Duidelijke voorbeelden van prefixes langer dan 64 bits.
Ik dacht al, een max prefix-length zou ons terugbrengen naar de dagen van classfull routing (20 jaar terug in de tijd dus).
Ik blijf bij wat ik een paar posts terug schreef:
Een hoop IPv6 luitjes schijnen moeite te hebben met binair rekenen.
En daarom misschien willen ze alles op 8-bit boundaries hebben.
Amateurs.
[Reactie gewijzigd door gryz op dinsdag 27 november 2012 14:33]
Ik zou over IPv6 eens enkele dingen lezen. Ik zie dat bij elk artikel over ipv6 dezelfde vragen opnieuw naar boven komen. Hier is wat interessante literatuur:
Wiki: http://en.wikipedia.org/wiki/IPv6
Wat Info toepasselijk op home networking:
http://www.kloepfer.org/ipv6-homenet.html
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463251.aspx
En dan natuurlijk HET discussiepunt ( hier vind je wat ze eigenlijk willen doen met ipv6 icm NAT )
http://ipv6friday.org/blog/2011/12/ipv6-nat/
Wiki: http://en.wikipedia.org/wiki/IPv6
Wat Info toepasselijk op home networking:
http://www.kloepfer.org/ipv6-homenet.html
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463251.aspx
En dan natuurlijk HET discussiepunt ( hier vind je wat ze eigenlijk willen doen met ipv6 icm NAT )
http://ipv6friday.org/blog/2011/12/ipv6-nat/
zouden ze nou genoeg nummers hebben ... of gewoon geen project kunnen managen en daardoor nogal wat uitloop hebben? zie de lancering van horizon.
Waarschijnlijk hebben ze voorlopig nog genoeg adressen. En het bied een provider ook niet direct voordelen, dus kan me voorstellen dat er geen haast bij is. Je kan niet tegen de klant zeggen dat zijn internet sneller wordt. Voor de gemiddelde klant is het alleen maar vervelend. Modem moet eventueel vervangen worden en kunnen problemen onstaat met firewalls e.d.
Vraag me af hoe het geimplementeerd wordt, dat je een buiten ipv6 adres krijgen met nat of dat de router transprant wordt..
Vraag me af hoe het geimplementeerd wordt, dat je een buiten ipv6 adres krijgen met nat of dat de router transprant wordt..
[Reactie gewijzigd door Mr_gadget op maandag 26 november 2012 14:29]
Denniss-MacBook-Pro:~ dennis$ dig ipv6only.com -t AAAA
;; ANSWER SECTION:
ipv6only.com. 7200 IN AAAA 2001:4978:269::1
Denniss-MacBook-Pro:~ dennis$ dig ipv6only.com -t A
;; AUTHORITY SECTION:
ipv6only.com. 3582 IN SOA hidden-master.thoroquel.org. hostmaster.thoroquel.org. 2012112501 2160 3600 604800 7200
Nou, does opschiet dan UPC... er zijn al IPv6 only websites....
@hieronder, was mijn eerste wilde gok ;-)
;; ANSWER SECTION:
ipv6only.com. 7200 IN AAAA 2001:4978:269::1
Denniss-MacBook-Pro:~ dennis$ dig ipv6only.com -t A
;; AUTHORITY SECTION:
ipv6only.com. 3582 IN SOA hidden-master.thoroquel.org. hostmaster.thoroquel.org. 2012112501 2160 3600 604800 7200
Nou, does opschiet dan UPC... er zijn al IPv6 only websites....
@hieronder, was mijn eerste wilde gok ;-)
[Reactie gewijzigd door Dennizz op maandag 26 november 2012 14:53]
Je kiest er ook wel eentje uit...
En de site geeft via native IPv6 nog een 403 ook... 
[Reactie gewijzigd door eBait op maandag 26 november 2012 14:42]
De arrogante houding van UPC spreekt boekdelen, IPv6 uitrol is geen peulenschil en dit uitstellen lijdt enkel tot meer problemen wanneer dit noodzakelijk word.
Wat XS4ALL al heeft aangetoond, Het op tijd uitrollen en implementeren van IPv6 is makkelijker en effectiever dan wachten tot het 'nodig' is.
-Reactie op Dr. Cheeks
Direct een kosten plaatje kan ik je ook niet geven (ik werk niet bij xs4all )
Maar hoe ze hebben aangetoont dat het makkelijker is is door het eerst als epiriment mogenlijk te maken, dit uitbreiden tot basis aanbod en nu zelfs klanten adviseren over hoe het te gebruiken.
Het goedkoper zijn om nu te doen heeft vooral mee te maken dat (en dat is mijn aanname) de klanten bestanden van ISP's nog steeds groeien, en een uitrol van IPv6 duurder is naarmate er meer mensen zijn (meer handelingen, en meer punten waar het mis kan gaan), en het dus verstandig is om het stapsgewijs uit te rollen.
bronnen:
Wat XS4ALL al heeft aangetoond, Het op tijd uitrollen en implementeren van IPv6 is makkelijker en effectiever dan wachten tot het 'nodig' is.
-Reactie op Dr. Cheeks
Direct een kosten plaatje kan ik je ook niet geven (ik werk niet bij xs4all
)Maar hoe ze hebben aangetoont dat het makkelijker is is door het eerst als epiriment mogenlijk te maken, dit uitbreiden tot basis aanbod en nu zelfs klanten adviseren over hoe het te gebruiken.
Het goedkoper zijn om nu te doen heeft vooral mee te maken dat (en dat is mijn aanname) de klanten bestanden van ISP's nog steeds groeien, en een uitrol van IPv6 duurder is naarmate er meer mensen zijn (meer handelingen, en meer punten waar het mis kan gaan), en het dus verstandig is om het stapsgewijs uit te rollen.
bronnen:
- http://www.xs4all.nl/klant/experimenteel/ipv6/
- http://www.xs4all.nl/over...chappelijk/dossiers/ipv6/
- http://www.xs4all.nl/klant/ipv6/
[Reactie gewijzigd door Sysosmaster op maandag 26 november 2012 14:39]
Kan je dat onderbouwen? Doordat xs4all de eerste was, wil niet zeggen dat daarmee aangetoond is dat het 'makkelijk' was of 'effectiever'. Ik heb geen inzicht in de kosten die xs4all destijds gemaakt heeft on tot op heden (wellicht) extra/dubbel heeft moeten uitvoeren op al vroeg met IPv6 te komen. Jij wel?
Ongeloofelijke gedachte van UPC, omdat hun nog genoeg IPv4 op voorraad hebben, wil niet betekenen dat iedereen nog genoeg IPv4 voorraad heeft.
Zoals UPC hopelijk mag weten, werkt IPv4 <-> IPv6 niet!
Straks komen er genoeg websites en diensten online die alleen IPv6 hebben daar hún geen voorraad meer van IPv4 hebben, dan kunnen we straks vanuit het UPC netwerk dus niet meer gebruik maken van die diensten.
Met andere woorden en als voorbeeld, ik heb UPC zakelijk IPv4 only, straks kan ik dus niet meer mailen met potentiele nieuwe klanten die net een nieuwe verbinding hebben met alleen een IPv6 adres. Heel fijn
Zoals UPC hopelijk mag weten, werkt IPv4 <-> IPv6 niet!
Straks komen er genoeg websites en diensten online die alleen IPv6 hebben daar hún geen voorraad meer van IPv4 hebben, dan kunnen we straks vanuit het UPC netwerk dus niet meer gebruik maken van die diensten.
Met andere woorden en als voorbeeld, ik heb UPC zakelijk IPv4 only, straks kan ik dus niet meer mailen met potentiele nieuwe klanten die net een nieuwe verbinding hebben met alleen een IPv6 adres. Heel fijn
Zolang ISP's niet massaal naar v6 gaan zullen er geen v6 only sites en diensten ontstaan, die hebben dan namelijk nauwelijks klanten.
Daarnaast kan een ISP die echt heel erg achterloopt dan altijd nog een 6to4 NAT doos neerzetten als proxy tussen zijn v4 omgeving en het stuk Internet dat alleen v6 praat. Dat schaalt niet eindeloos maar er zijn nu ook al zat ISP's (vooral mobiele) waar ze dit voor v4 al doen.
Zo'n proxy gaat overigens volgend jaar echt nog niet nodig zijn. Toegegeven, er kan altijd iemand een app verzinnen die fantastisch, onmisbaar en the-best-thing-since-sliced-bread is en echt v6 features nodig heeft maar die kans acht ik vrij klein.
UPC, en vele andere ISP's, maken hier geen haast mee omdat het nog niet nodig is. Veel wat oudere modems ondersteunen niet of niet goed v6, dan kan een jaartje wachten erg veel kostenreductie opleveren voor een ISP. Daarnaast zit iedereen in die sector in zwaar weer dus ieder project dat later kan scheelt weer op de balans voor dit jaar.
Daarnaast kan een ISP die echt heel erg achterloopt dan altijd nog een 6to4 NAT doos neerzetten als proxy tussen zijn v4 omgeving en het stuk Internet dat alleen v6 praat. Dat schaalt niet eindeloos maar er zijn nu ook al zat ISP's (vooral mobiele) waar ze dit voor v4 al doen.
Zo'n proxy gaat overigens volgend jaar echt nog niet nodig zijn. Toegegeven, er kan altijd iemand een app verzinnen die fantastisch, onmisbaar en the-best-thing-since-sliced-bread is en echt v6 features nodig heeft maar die kans acht ik vrij klein.
UPC, en vele andere ISP's, maken hier geen haast mee omdat het nog niet nodig is. Veel wat oudere modems ondersteunen niet of niet goed v6, dan kan een jaartje wachten erg veel kostenreductie opleveren voor een ISP. Daarnaast zit iedereen in die sector in zwaar weer dus ieder project dat later kan scheelt weer op de balans voor dit jaar.
IPv4 is gewoon via IPv6 te routeren hoor. Daar heb je als klant niet zo veel mee te maken, dat doen routers intern. Nog afgezien van het feit dat je met mail uberhaupt geen directe verbinding hebt, maar communiceert via smtp servers.
@Polderdijk: Je hoeft je voorlopig echt geen zorgen te maken dat er snel IPv6-only diensten komen. Er zijn veel meer eindgebruikers dan servers aangesloten op internet. Dat wil zeggen dat servers wel echt de laatste computers zijn die IPv6-only zullen worden. In ieder geval pas nadat het grootste deel van de mobiele en thuisgebruikers over zijn op IPv6-only.
De eerste IPv6-only gebruikersaansluitingen worden al een tijdje geleverd, voornamelijk in Azie waar de schaarste veel groter is dan in EU en de US. IPv6-only servers bestaan voorlopig eigenlijk alleen voor test/voor de gein/experiment doeleinden.
Dat wil niet zeggen dat het kwaad kan als UPC het snel kan leveren, een drama is deze vertraging echter niet.
De eerste IPv6-only gebruikersaansluitingen worden al een tijdje geleverd, voornamelijk in Azie waar de schaarste veel groter is dan in EU en de US. IPv6-only servers bestaan voorlopig eigenlijk alleen voor test/voor de gein/experiment doeleinden.
Dat wil niet zeggen dat het kwaad kan als UPC het snel kan leveren, een drama is deze vertraging echter niet.
Precies. Er is wereldwijd duidelijk een probleem, en omdat UPC blijkbaar het nog even redt, werken ze niet aan de oplossing.Ongeloofelijke gedachte van UPC, omdat hun nog genoeg IPv4 op voorraad hebben, wil niet betekenen dat iedereen nog genoeg IPv4 voorraad heeft.
Daarom UPC: als je niet een deel van de oplossing bent, ben je deel van het probleem.
Valt Telenet ook niet onder Liberty Global?
Hoeze zijn deze niet helder? Op de site staat zelf:De plannen van KPN met ipv6 zijn eveneens nog niet helder; alleen KPN-dochter Xs4all biedt zijn klanten een native ipv6-adres aan.
http://kpn-klantzm.custhe...answers/detail/a_id/14826Ondertussen zorgt KPN ervoor dat de bestaande infrastructuur, apparaten, systemen en processen geschikt worden gemaakt voor IPv6, zodat de overgang van IPv4 naar IPv6 zonder grote problemen verloopt. Naar verwachting zullen vanaf het vierde kwartaal van 2012 alle diensten van KPN een volwaardig IPv6 aanbod hebben.
offtopic:
Dat ik al maanden lang geen enkele reactie krijg van de ipv6-coordinator van kpn, en dat het inmiddels bijna december is zou er echter op kunnen duiden dat het bericht op de site iets te ambitieus geweest kan zijn.
Dat ik al maanden lang geen enkele reactie krijg van de ipv6-coordinator van kpn, en dat het inmiddels bijna december is zou er echter op kunnen duiden dat het bericht op de site iets te ambitieus geweest kan zijn.
[Reactie gewijzigd door Freeaqingme op maandag 26 november 2012 14:39]
Als upc ipv6 gaat uitrollen, zijn de ipv6 blocks dan nog steeds dynamisch van aard, net zoals je eens in de zo veel tijd met ipv4 een andere krijgt toegewezen? Of krijg je dan een static block toegewezen?
Nou ben ik misschien heel makkelijk in m'n denken hoor, maar zou je als provider niet veel vroeger moeten beginnen met testen en het uitdelen van IPv6? Je kan mij niet vertellen dat het tekort aan IPv4 nummers als verrassing komt namelijk, en als ze dalijk écht zonder IPv4 nummers zitten, heb je toch een probleem als provider zijnde denk ik.
Veel vroeger ? Man, je kunt nog 5 a 10 jaar wachten met IPv6, en dan nog is er niks aan de hand. Alle vroege vogels hebben vooral tijd en geld verdaan. Het is nog maar afwachten of IPv6 er echt komt. ("Echt" in de zin van" dat er meer IPv6 hosts dan IPv4 hosts zijn op het Internet).
Het is niet een verrassing dat we IPv4 adressen te kort hebben. Dat zagen we 20 jaar geleden al aankomen. Wat wel een vraag is, is of en wanneer de mensheid IPv6 inderdaad zal gaan gebruiken.
Het is niet een verrassing dat we IPv4 adressen te kort hebben. Dat zagen we 20 jaar geleden al aankomen. Wat wel een vraag is, is of en wanneer de mensheid IPv6 inderdaad zal gaan gebruiken.
[Reactie gewijzigd door gryz op maandag 26 november 2012 18:18]
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht Galaxy S
© 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
