Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 103 reacties
Submitter: Snow_King

ZeelandNet zoekt klanten om ipv6 in een dualstack-configuratie te testen. De kabelaar wil nog dit jaar ipv6-ondersteuning gaan uitrollen voor zowel zakelijke klanten als consumenten. Daarmee is het na Xs4all de tweede grote isp die ondersteuning voor het 'nieuwe' netwerkprotocol aanbiedt.

Op zijn website meldt ZeelandNet dat het al een aantal interne pilots heeft gehouden om te bekijken of ipv6 op zijn ip-netwerk goed functioneert. De provider wil in aanloop naar een uitrol van de ipv4-opvolger een volgende stap zetten door een aantal klanten het protocol te laten testen. Daarbij wordt een zogenaamde dualstack-configuratie aangeboden, waarbij ipv4 naast ipv6 blijft functioneren.

Deelnemers aan de proef wordt gevraagd om hun bevindingen te delen met ZeelandNet. De isp kan op afstand het kabelmodem activeren voor ipv6. Uiteindelijk wil de kabelaar nog dit jaar aan alle klanten ipv6 gaan aanbieden, maar een specifieker tijdstip voor de invoering noemt ZeelandNet nog niet.

Na Xs4all zou ZeelandNet de tweede grote isp in Nederland worden die aan al zijn klanten toegang geeft tot ipv6. Andere partijen zeggen weliswaar plannen te hebben voor het uitrollen van ipv6, maar houden zich op de vlakte wanneer zij precies de ipv4-opvolger zullen introduceren.

Moderatie-faq Wijzig weergave

Reacties (103)

Ovrigens heeft Icann hierover net een persbericht uitgestuurd dat het nu toch echt door de IPV4 addressen heen is: https://www.icann.org/news/announcement-2-2014-05-20-en

Het begint nu toch wel problematisch te worden als ik het bericht goed lees. Overigens wel apart dat tweakers volgens sixornot nog steeds op IPv4 draait?

(geschreven vanaf XS4all IPv6 verbinding) ;)
Grappig dat er al jaaren wordt geroepen dat de IPv4-adressen op zijn en het telkens nog steeds bleek goed te gaan (nee het Internet is niet uitgegaan). Zelfs in 1999 al !

nieuws: Tekort aan IP adressen in nabije toekomst

[+1 voor degene die de kwaliteit van de nieuwsitem spot in vergelijking met nu :-]

Voor wie even wil nalezen hoe het ook alweer zit met IPv4 vs IPv6: hier heeft Tweakers.net het mooi uitgelegd: reviews: Ipv4 en ipv6: hoe zat dat ook alweer? .

[Reactie gewijzigd door ZeroSect0r op 2 juni 2014 13:58]

Grappig dat er al jaaren wordt geroepen dat de IPv4-adressen op zijn en het telkens nog steeds bleek goed te gaan (nee het Internet is niet uitgegaan). Zelfs in 1999 al !
Hoeveel apparaten heb jij die op internet zitten? Hoeveel IP-adressen krijg je van je provider?
Wel eens gevraagd of je er nog 32 adressen bij kan krijgen op je consumentenlijn?

IPv4 is eigenlijk al op sinds de jaren negentig. Het is niet voor niets dat NAT toen is uitgevonden om nog een beetje ruimte te maken. Adresruimte is als tandpasta: als je maar hard genoeg knijpt komt er steeds weer een beetje uit de tube. Nu wordt er begonnen met een dubbele laag NAT maar de boel zo ver uitknijpen begint behoorlijk pijn te doen.
De IPv4 adressen waren helemaal nog niet op in de jaren negentig. Ze zijn pas sinds een jaar of 2 op.

Wel wisten we al begin jaren negentig dat ze op zouden raken. Natuurlijk wisten de engineers die de IPv4 standaard maakten dat 4B adressen niet genoeg zouden zijn als iedereen IPv4 zou gaan gebruiken. Echter, in 1981 hadden ze niet verwacht dat de hele wereld 35 jaar laten nog steeds hun experimentele protocol zou gebruiken.

De eerste RFCs die het probleem van het adres-tekort aan wilden pakken die ik kon vinden was deze uit juni 1992. De beschrijving van het idee achter CIDR. Als de RFC uit Juni 1992 stamt, dan waren ze er al in 1991 mee aan het werk. CIDR was een "work-around" die snel toegepast zou worden, terwijl IPng (IP Next Generation) een echte oplossing zou worden. IPng vroeg om voorstellen voor nieuwe protocollen, en IPv6 heeft dat gewonnen, ergens in 1995. In 1996 kwamen de eerste RFCs uit. Maar dat er te weinig adressen zouden zijn, dat was met al jaren eerder van doordrongen.

[Reactie gewijzigd door gryz op 2 juni 2014 15:39]

De IPv4 adressen waren helemaal nog niet op in de jaren negentig. Ze zijn pas sinds een jaar of 2 op.
Dat is een kwestie van perspectief. Helemaal op was, en is, IPv4 niet, maar je kan al lang niet meer zo veel adressen krijgen als je wil. Er zijn steeds meer hacks nodig om de boel werkbaar te houden. Het zal wel nooit zo zijn dat alle IPv4 adressen in gebruik zijn, maar een tekort is er al tijden.
Dat is dan ook omdat bedrijven ze in grote aantal inkopen, die zijn dan al "ingenomen", maar hoeven nog niet echt gebruikt te worden.
De noodzaak voor een nieuwe protocol wordt netjes weergegeven (IPadressen raken op) echter zijn er tal van extra verbeteringen/ veranderingen doorgevoerd.

Enkele voorbeelden:

* Geen NAT meer. Ieder verbonden device heeft dus een eigen unieke IP adres.
* Network Auto-configuratie dmv Router Advertisement
* Native IPSec
* QOS door flow labeling
" the timeline for a rollout is sketchy--estimates range from the next 5 to 25 years"
Gelukkig konden ze in '99 al zien dat het wel even ging duren met de implementatie.
Het word inderdaad al jaren geroepen. En de dag dat er problemen ontstaan gaan er alsnog mensen staan alsof ze het in keulen horen donderen. Spijtig genoeg is dat de realiteit waarin wij leven vandaag.

Er zijn nu al ISPs die carrier grade NAT moeten toepassen om hun consumenten op het internet te krijgen met alle nadelen die erbij horen.
Dat plan(volledige uitrol) komt al uit 2010. Ik heb hier letterlijk op een uitgeprint blad "Zeeland gaat voor IPv6! In 2010 gaan wij voor alle klanten IPv6 beschikbaar maken. " staan.

Ik doe al tijdje mee met de pilot. Elke keer als mijn IPv4-adres verandert, ben ik mijn IPv6-access kwijt.

Maar goed, beter laat dan nooit :')

[Reactie gewijzigd door timmie1 op 2 juni 2014 14:01]

IPv6 is zeker niet zalig makend, maar ik ben blij om dit bericht te lezen.

Op http://gathering.tweakers.net/forum/list_messages/1540083 is al een voorbeeld te vinden in NL waarbij een provider een oplossing heeft ingevoerd om zijn IPv4 te kort aan te pakken.

Gevolg, gebruiker kan niet over IPv4 internet bij thuis systemen. Nu is IPv6 hier geen oplossing voor maar het laat wel zien dat de problemen niet een ver van je bed show hoeven te zijn.

Afgelopen week ving ik op dat UPC prioriteit geeft aan zijn Horizon issues en het aanmelden als test gebruiker nog niet mogelijk was wat ik erg jammer vind omdat ik IPv6 tunnels ook geen productie waardige oplossing vind.
Misschien een gevalletje als 1 schaap over de dam is, volgen er meer?
Kenbaar hebben de ISP nog genoeg op voorraad want ik zie ze niet echt heel erg in paniek raken.
passen ze niet gewoon nog een niveautje nat toe in dat geval? :p
Carrier Grade NAT is niet echt een fijne oplossing, niet voor de ISP en niet voor de klant. Het is niet goedkoop en je krijgt er veel gezeur met je klanten mee wiens VOIP of game console ineens niet meer werkt. Het gaat je een drukke helpdesk en overstappende klanten opleveren.

NAT444 (CGN/LSN) and What it Breaks"
FTP download
-Large files
BitTorrent and Limewire
-Seeding (upload)
On-line gaming
-Xbox
-PlayStation
-Etc.
Video streaming
-Hulu
-Netflix
-Slingcatcher
-Etc.
Webcam
-Remote viewing
Tunneling
-6to4
-Teredo
-Etc.
VPN & Encryption
-IPSec
-SSL
VoIP
-Limited ALG/SIP support
All custom applications with the IP embedded
-Lack of ALGs

[Reactie gewijzigd door Maurits van Baerle op 2 juni 2014 14:52]

Iedere keer dat je NAT maak je problemen die steeds moeilijker worden om op te lossen. Bij twee keer NAT heb je internet al bijna gereduceerd tot televisie: je kan kijken wat anderen doen maar niet zelf bijdragen.
Ik hoop inderdaad dat dit doet volgen. Mijn huidige ISP gaat van de zomer volledig over op glas. Ik had gehoopt dat ze dit direct gepaard gingen doen met een overstap op IPv6, maar dat laat vrees ik nog even op zich wachten.
Het is nooit een strak plan om twee grote veranderingen tegelijk door te voeren. Echter ben ik met de geest van de meeste reacties eens dat IPv6 allang geÔmplementeerd had mogen worden.
Alleen al daarom ben ik tegen de UPC/Ziggo-fusie. Dan wilen ze natuurlijk eerst hun netwerken samenvoegen en hebben ze weer een reden om IPv6 nog een paar jaar uit te stellen.
Netwerken samenvoegen gaat denk ik veel beter met IPv6 dan met IPv4 (grotere adres ruimte, moeten toch al dingen omnummeren, etc.).
Als de andere kant van het internet geen IPv4 meer heeft dan heb je er weinig aan dat jouw ISP nog wel IPv4 heeft.

Juist daarom moeten we IPv6 hebben, zodat het hele internet zonder dat dramatische NAT verder kan groeien.
Eigenlijk zegt dit niet veel... Ik bedoel Ziggo is al 3 jaar bezig hiermee en blijft het ook jaar na jaar uitstellen (muv zakelijke gebruikers.)
Heb vaak genoeg met hun helpdesk aan de lijn gehangen om te smeken naar een /64 subnetje maar helaas nog steeds niks..

Een jaar of 2 geleden dan ook maar besloten om een tunneltje via sixxs.net op me pfsense router in te stellen... tot nu toe geen problemen mee gahad en ik ben weer voor het hele internet bereikbaar.

Vindt het eigenlijk wel een beetje jammer dat de providers zo langzaam zijn met het uitrollen hiervan...

Edit: Ik hoop troiuwens wel dat als de providers ipv6 uitrollen dat je dan statische adressen krijgt want ik zie het niet zitten om na iedere router reboot de firewall opnieuw te configureren.... :):) :o

[Reactie gewijzigd door back2basic op 2 juni 2014 14:30]

Ik zou er vanuit gaan dat je per abonnement een statische /64 (dus met 18.446.744.073.709.551.616 adressen) krijgt. Dat is de standaard en ervan afwijken betekend extra werk voor een ISP zonder dat er voordelen aan verbonden zitten. Bij XS4ALL krijg je ook gewoon een /64 en staat je toegewezen IP-range gewoon in de bevestigingsbrief.

Vroeger had het misschien zin om dynamisch IPv4 adressen uit delen zodat je eventuele schaarste kon opvangen. Met IPv6 speelt dat probleem niet en zou dynamisch alleen maar extra complexiteit opleveren.
en toch vraag ik me af, waarom een /64 zul je dan niet zien dat we over 20 jaar weer het zelfde gezeik hebben als alle kindertjes in africa ook een eigen /64 willen...

ik snap dat voor routering je hele blokken wilt hebben, de notatie in ip6 is: ::xxxx.yyyy

nu snap ik dat voor heel veel toepassingen als (internet of things), aan 1 digit (16 adressen), niet genoeg hebt, maar voor private use zou je de komende 10 jaar toch genoeg moeten hebben aan een class c netwerk xxxx.xxyy of als je echt iets raars wilt doen een xxxx.xyyy (4096 adressen)... wat mij betreft mogen ze ip6 morgen verplicht stellen... maar zou er ook maar iemand zijn (de komende 100 jaar) die meer dan 6500 ips nodig heeft, op die paar bedrijven na,
Die /64 is omdat er een heel MAC adres in het laatste segment van het adres moet kunnen passen. Als je kleinere blokken uitdeelt pas het niet meer.

Overigens is het grote risico van het inrichten van een IPv6 topologie dat er inefficiŽnte indelingen worden gemaakt omdat mensen strategieŽn in hun hoofd hebben die logisch waren met IPv4. Bijvoorbeeld omdat er met IPv4 wel schaarste was.

Bij IPv6 is het juist belangrijk dat je gebruik maakt van de mogelijkheden zodat het minder gefragmenteerd kan zijn. Simpel voorbeeld: waar je vroeger een subnet aan een heel gebouw toekende om adressen te besparen kun je nu juist iedere verdieping (of zelfs elke afdeling als er meerdere op ťťn verdieping zitten) een eigen subnet geven. Als je dan moet troubleshooten of beveiligen kun je veel gedetailleerder segmenten in je topologie aanwijzen.
met 64 bit aan adres ruimte kan je onder elk ipv4 adress op internet nog een heel ipv4 internet hangen...

dat is dus echt niet over 20 jaar op.

die /64 is omdat je dan /64 overhoudt en dat is precies even lang als een mac adres wat het mogelijk maakt om ipv6 adressen automatische te assignen. je hebt alleen iets nodig dat even tegen het netwerk zegt welke prefix te moeten gebruiken en ze kunnen hun ipv6 adres verder zelf maken,.

[Reactie gewijzigd door Countess op 2 juni 2014 16:42]

met 64 bit aan adres ruimte kan je onder elk ipv4 adress op internet nog een heel ipv4 internet hangen...
kun je nagaan hoe dat is met 128 bit. Want ipv6 is 128 bit adresruimte. :)
dat weet ik maar ISP's gaan prefixes van 64bit's of korter uitdelen (56 of 48)

daar doelde ik op. de rest van de adres ruimte word alleen intern gebruikt.

[Reactie gewijzigd door Countess op 3 juni 2014 05:18]

Ah, nu snap ik hoe je 't bedoelde :) Inderdaad, dat klopt wel.
Een MAC-adres is maar 48 bits maar in de IT is men nog al dol op machten van twee. 48 is geen macht van twee, 64 wel.
Ik zou er vanuit gaan dat je per abonnement een statische /64 (dus met 18.446.744.073.709.551.616 adressen) krijgt. Dat is de standaard en ervan afwijken betekend extra werk voor een ISP zonder dat er voordelen aan verbonden zitten.
Volgens mij is de standaard om een /48-/56 te leveren, meer dan 1 /64 per klant dus. Dat geeft wat ruimte om in de toekomst nog wat verder onder te verdelen. Zo heb ik gehoord van een provider die stukjes adresruimte van de klant wil reserveren voor IPTV en VOIP.
Volgens mij is de standaard om een /48-/56 te leveren, meer dan 1 /64 per klant dus.
daar was geloof ik nogal wat discussie over. een /64 per aansluiting is ruimschoots voldoende, voor zakelijke netwerken die meerdere gescheiden netwerken willen hebben met ieder hun eigen netwerk blok ( een /64 is het kleinst adresseerbare subnet) is een /48 logischer. Maar voor thuis-verbindingen?

ok, ik heb een /48 van xs4all, en ik zit toepassingen ervoor te verzinnen. omdat het kan. maar ik ben geen doorsnee gebruiker.

[Reactie gewijzigd door arjankoole op 2 juni 2014 17:16]

Een aantal Nederlands providers heeft ooit toegezegd dat ze minimaal een /56 zullen gaan leveren maar dat is inmiddels al weer een hele tijd geleden. Eerst maar eens zien, dan geloven.
Een /64 is niet de standaard, da's eerder een /48 of een /56 zoals al gezegd is. Als providers slechts een /64 uitgeven dan wordt het wel erg beperkt, want dan heb je in principe maar 1 netwerksegment (uitgaande van automatische IPv6 'toewijzing') en kun je dus niet een apart segment opzetten voor bijvoorbeeld een gasten-netwerk, enz. Je zou denken dat je met zoveel adressen in een /64 wel meerdere segmenten kunt maken, maar dan kun je geen automatische toewijzing van IPv6 adressen meer gebruiken en moet je handmatig gaan toewijzen...
Ik krijg van xs4all anders echt een /48 hoor.
Die router heb je niet meer nodig bij ipv6, dat wordt een bridge. Die firewall moet verplaatst worden naar de devices, die krijgen een directe link naar internet. Of wilde je nog steeds alles door 1 firewall/nat/proxy sturen? Dan kun je net zo goed ipv4 blijven gebruiken
Zolang het dual stack is zul toch nog een router moeten hebben voor ipv4 gedeelte.
Als tweakers draaien we natuurlijk meerdere services via thuis.

Maar als we straks alleen maar v6 hebben denk ik dat ik de firewall wel laat hangen....
De firewall van windows als enige redmiddel krijg ik geen lekker gevoel bij...
In Nederland heeft iedereen een modem/router van z'n provider waar al een firewall in zit. Zo'n beetje al die kastjes draaien tegenwoordig op Linux. Onder Linux is NAT een onderdeel van de firewall. Wanneer providers updates uitsturen om IPv6 aan te zetten zullen ze ook wel zorgen dat de firewall aan staat.
Da's niet helemaal waar wat je daar zegt volgens mij.
Ik heb nog een ziggo modem van cisco (dus alleen modem zonder wifi en zo). hier zit zover ik heb kunnen ontdekken niks van firewall in.. want als ik direct een pc inplug op de modem hang ik aan het gevaarlijk wereld wijde internet....
Het zit er zeker wel in, maar blijkbaar is die firewall dan niet zichtbaar in de interface. Slecht hoor :(
Het zit er zeker wel in, maar blijkbaar is die firewall dan niet zichtbaar in de interface. Slecht hoor :(
volgens mij heeft ie gelijk, in die oude ziggo meuk was 't puur een bridge, en werd je publieke IP direct aan je ethernet interface op je PC/Laptop/Whatever gemikt. Geen NAT, geen Firewall, misschien DHCP om automatisch dat IP toe te kennen.

In die tijd mocht je ook pertinent niet meer dan 1 computer er mee verbinden, want dat zou zakelijk gebruik zijn ofzo. :)
Ok, ik wist niet dat Ziggo nog pure modems had, ik dacht dat ze alleen nog modems met router hadden die je ook als bridge kan laten configureren.
Ok, ik wist niet dat Ziggo nog pure modems had, ik dacht dat ze alleen nog modems met router hadden die je ook als bridge kan laten configureren.
ze hebben ze niet officieel meer volgens mij, maar als ik het zo hoor is dit een geval van 10 jaar terug ofzo.
Het is een docsis3 modem van cisco.
Volgens mij een jaar of 4 geleden vervangen..(net voordat ze met die modem/router/wifi kwamen.)
Maar ik ben er best blij mee :) kan op deze manier bv wel van anderen de hotspot gebruiken terwijl bij mij niks openstaat.

Maar idd hij heeft maar 1 poort en daar krijg ik mijn wan ip op.
Er zit wel iets van configpagina in maar daar kom ik helaas alleen op als hij aan het opstarten is op 192.168.100.1.
eenmaal hierop ingelogd met admin/admin zie je echter alleen de verbinding naar het netwerk van ziggo.

[Reactie gewijzigd door back2basic op 2 juni 2014 19:58]

sterker nog je kunt strax per pc beslissen welke poorten er open staan als je software dat ondersteunt... en aangezien er geen NAT meer is zal het apparaat vermoedelijk aanzienlijk beter werken (minder ram / cpu verbruik)
De firewall blijft met IPv6 gewoon in je modem of router zitten (tenzij je die uitschakelt natuurlijk). Het is bovendien een stuk makkelijker dan ook nog NAT moeten toepassen omdat ze niet meer alle verschillende poorten aan interne IP's hoeven te koppelen en bij te houden.
wat je nu zegt is gewoon klinklare onzin,

ja elk device krijgt een publiek ip, en routering werkt op een iets andere manier,
maar tcp-ip is nog steeds een ethernet protocol dat wil zeggen, je schreeuwd door de gang een naam die iedereen kan horen, en alleen de aangeroepene schreeuwd terug dat ie het gehoord heeft...

wat jij nu beweerd is dat elke pc fysiek zonder interventie aan het internet hangt maar dat is helemaal niet waar, je hebt namelijk nog steeds een bridge of switch of NTU nodig, en die kan toegang nog steeds omleiden via een firewall of een network access controller, dat er geen (of nauwelijks want ook ip6 kent gewoon routering) routering meer nodig is, maakt verder niets uit...
Edit: Ik hoop troiuwens wel dat als de providers ipv6 uitrollen dat je dan statische adressen krijgt want ik zie het niet zitten om na iedere router reboot de firewall opnieuw te configureren.... :):) :o
je firewall moet je ook configureren om de prefix-variable en mac adress te gebruiken. als de prefix veranderd blijft het mac adress gedeelte van de achterliggende machine het zelfde en dus je firewall rules ook.
subnetting het zelfde. de routers krijgen van hoger hand een prefix op gelegd maar hun subnet daarvan blijft elke keer het zelfde.

het veranderen van ISP is dus met ipv6 voor een bedrijf VEEL eenvoudiger als dat dat nu is met ipv4 waarbij altijd het hele netwerk opnieuw moet worden ingericht om het nieuwe ip adress te kunnen gebruiken. maar met ipv6 kan dat mitst goed ingericht zelfs geheel automatische.

ook handig als een van je ISP's uit valt. het hele netwerk kan automatische over naar de andere.

[Reactie gewijzigd door Countess op 2 juni 2014 16:46]

Is er misschien iemand in de zaal die bij een ISP werkt en uit kan leggen waarom de uitrol zo langzaam gaat en telkens maar uitgesteld wordt?
Het is niet de techniek die lastig is. Dat is echt zo gedaan allemaal.
De providers zijn voornamelijk bang om de klachten/storingen die het gaan geven naar de eindgebruikers die niks van ipv4/ipv6 weten.
De helpdesk moet dus opgeleid worden. Dat kost geld. IPv6 levert niks op. Dus geen business case.
De vraag is kan je met IPV6 alle websites en services bereiken of moet je steeds terugschakelen.
Nee, de meeste websites zijn nog niet bereikbaar over IPv6. De grote wel (Google, Facebook, ...).

Met dual-stack is dat echter geen probleem. Je computer gebruikt IPv6 automatisch waar het kan en IPv4 waar 6 niet kan. Heeft geen impact op de snelheid of stabiliteit.
In de praktijk misschien weinig impact op de snelheid, maar theoretisch is IPv6 als ik het goed heb wel iets sneller dan IPv4. Minder overhead ofzoiets.
Er is iets beter nagedacht over de indeling van de paketten zodat het makkelijker is om ze in hardware af te handelen. Daarnaast is de adresruimte sterk hierarchisch ingedeeld waardoor het voor routers makkelijker wordt om pakketjes de juiste kant op te sturen. IPv4 is zo versnipperd dat een router een enorme lijst met netwerken moet bijhouden en doorzoeken.
Ik word een beetje moe van mezelf. Maar daar gaan we weer.
Er is iets beter nagedacht over de indeling van de paketten
Niet echt. Er zijn geen fragmentatie velden in de header. (Er is een aparte header voor fragmentatie, die alleen door begin- en eindpunt mogen worden gebruikt). Maar met pmtu-discovery wordt er zowiezo geen fragementatie meer gebruikt.
zodat het makkelijker is om ze in hardware af te handelen.
Onzin. In de praktijd is het aantal pps (packets per second) altijd lager bij IPv6 dan bij IPv4. Bovendien, omdat adressen veel groter zijn, past er in de praktijk maar de helft aantal entries in TCAM tables. En TCAM is een van de duurdere compontenten in routers.
Daarnaast is de adresruimte sterk hierarchisch ingedeeld waardoor het voor routers makkelijker wordt om pakketjes de juiste kant op te sturen. IPv4 is zo versnipperd dat een router een enorme lijst met netwerken moet bijhouden en doorzoeken.
Dat is alleen vanwege historische redenen. En omdat IPv4 meer gebruikt wordt. IPv6 heeft geen enkele techniek of richtlijn die anders is dan IPv4. En dus zal de entropie in de IPv6 routing table net zo groot worden. Er is geen Locator-Identifier Separation. De toewijzing van adressen is niet anders. Er is geen techniek voor multi-homing van sites. Er is geen techniek om hele sites snel te hernummeren (met behoud van bestaande verbindingen). Afijn, de routing van IPv4 en IPv6 is precies hetzelfde.

De enige reden om over te stappen op IPv6 is zodat meer Aziaten, Afrikanen en Zuid-Amerikanen ook gebruik kunnen maken van het net. Als je al een IPv4 adres hebt, is er geen enkel voordeel te behalen.
Niet echt. Er zijn geen fragmentatie velden in de header. (Er is een aparte header voor fragmentatie, die alleen door begin- en eindpunt mogen worden gebruikt). Maar met pmtu-discovery wordt er zowiezo geen fragementatie meer gebruikt.
Daar had ik het niet over, de IPv6 adressen zitten handiger gealigned in de header.
Onzin. In de praktijd is het aantal pps (packets per second) altijd lager bij IPv6 dan bij IPv4.
IPv4 krijgt al 30 jaar alle aandacht, IPv6 hangt er vaak maar een beetje bij. In praktijk is IPv4 nu sneller, in theorie zou IPv6 makkelijker moeten zijn.
Bovendien, omdat adressen veel groter zijn, past er in de praktijk maar de helft aantal entries in TCAM tables. En TCAM is een van de duurdere compontenten in routers.
Maar je hoeft minder adressen bij te houden omdat je netwerkstructuur simpelere kan zijn.
Dat is alleen vanwege historische redenen. En omdat IPv4 meer gebruikt wordt. IPv6 heeft geen enkele techniek of richtlijn die anders is dan IPv4.
Dat klopt, maar IPv6 heeft veel meer adressen. Niemand vind het leuk om z'n subnetten zo ver te versnipperen maar onder IPv4 hebben we geen keuze meer. Onder IPv6 hebben we een kans om het wel goed te doen.

Ik ben het met je eens dat versnippering een grote bedrijging is. Als we niet oppassen en IPv6 net zo inrichten als IPv4 lopen we binnen de kortste keren tegen problemen aan.
De enige reden om over te stappen op IPv6 is zodat meer Aziaten, Afrikanen en Zuid-Amerikanen ook gebruik kunnen maken van het net. Als je al een IPv4 adres hebt, is er geen enkel voordeel te behalen.
Ik wil niet 1 IPv4-adres. Een stuk of 32 zou ik wel kunnen gebruiken hier in huis en dan woon ik nog alleen. Ok, ik ben misschien niet helemaal representatief voor de gemiddelde Nederlander, maar de behoefte aan meer adressen zal alleen maar blijven stijgen.

[Reactie gewijzigd door CAPSLOCK2000 op 2 juni 2014 15:17]

Daar had ik het niet over, de IPv6 adressen zitten handiger gealigned in de header.
Alsof dat wat uit zou maken. En alsof IPv4 addressen ook niet netjes op 32-bit boundaries zijn gealigned.
IPv4 krijgt al 30 jaar alle aandacht, IPv6 hangt er vaak maar een beetje bij. In praktijk is IPv4 nu sneller, in theorie zou IPv6 makkelijker moeten zijn.
En waarom zou het sneller moeten zijn ? Ten eerste implementeren snelle routers alles in ASICs en TCAM en andere hardware oplossingen. Ten tweede is een grote factor bij het forwarden hoe snel je een pakket (of header) kunt kopiereen in memory. IPv6 headers zijn groter, dus duurt het langer om te kopieren. Er is geen enkele reden waarom het sneller zou zijn.
Als je begint over "IPv6 heeft geen checkum", dan ga ik huilen. Het herbereken van de IPv4 header-checksum is een enkele instructie (subtract - 1).
Maar je hoeft minder adressen bij te houden omdat je netwerkstructuur simpelere kan zijn.
Onzin. De physieke netwerk structuur blijft precies hetzelde. Bij zowel IPv4 als IPv6 heeft iedere segment een eigen prefix (aka subnet). Ieder interface heeft een eigen ip-adres. Alles is dus hetzelfde. Je statement is dus onzin.
Dat klopt, maar IPv6 heeft veel meer adressen. Niemand vind het leuk om z'n subnetten zo ver te versnipperen maar onder IPv4 hebben we geen keuze meer. Onder IPv6 hebben we een kans om het wel goed te doen.
Nogmaals, alles blijft hetzelfde. Ieder interface op een machine heeft zijn eigen adres. Ieder netwerk-segment heeft een eigen subnet. Alleen de hoeveelheid bits wordt groter. Geen enkel verschil.

Het had anders kunnen zijn als IPv6 het model van OSI-routing (aka CLNS) had overgenomen. Dan had ieder machine precies een adres gehad. En ieder "administrative domain" slechts een prefix. Binnen zo'n domain hadden alle routers dan hostroutes moeten hebben voor iedere machine. Een veel betere oplossing imnsho. Maar ja, OSI deed het zo, dus *moest* de IPv6 community het anders doen. En dus slechter. Met dit adres-model zou het makkelijker zijn om de adressering te plannen. En nog belangrijker, multi-homed machines zouden automatisch werken, zonder dat de application-layer iets hoeft de doen. Een gemiste kans.

Ik ben het met je eens dat versnippering een grote bedrijging is. Als we niet oppassen en IPv6 net zo inrichten als IPv4 lopen we binnen de kortste keren tegen problemen aan.
Ik wil niet 1 IPv4-adres. Een stuk of 32 zou ik wel kunnen gebruiken hier in huis en dan woon ik nog alleen. Ok, ik ben misschien niet helemaal representatief voor de gemiddelde Nederlander, maar de behoefte aan meer adressen zal alleen maar blijven stijgen.
Het gaat erom welk device je een publiek ip-adres wilt geven. Op het moment zou dat voor mij alleen een http-server en een sshd-server zijn. Dan moet je twee "gaten prikken" in je NAT (voor poort 22 en 80). En klaar is kees. Ik zou zeker niet willen alles thuis direct te benaderen is. Dat zou een security-nightmare zijn.

[Reactie gewijzigd door gryz op 2 juni 2014 15:38]

Alsof dat wat uit zou maken. En alsof IPv4 addressen ook niet netjes op 32-bit boundaries zijn gealigned.
dat wel, maar wat precies waar zit binnen die boundries is in een aantal gevallen variabel bij ipv4. en daarom veel lastiger(duurder) om uit te lezen. je moet eerst weten hoe het pakket er uit ziet voor je het kunt interpreteren. verder is de header checksum verwijderd en zijn weinig gebruikte optie zijn uit de header gehaald en naar een veel beter systeem van option headers verplaatst. en TTL is vervangen door een hop limit

dat alles maakt het zeker voor de tussenliggende routers veel goedkoper om ipv6 te routen als ipv4.

http://en.wikipedia.org/w...ied_processing_by_routers
Het gaat erom welk device je een publiek ip-adres wilt geven. Op het moment zou dat voor mij alleen een http-server en een sshd-server zijn. Dan moet je twee "gaten prikken" in je NAT (voor poort 22 en 80). En klaar is kees. Ik zou zeker niet willen alles thuis direct te benaderen is. Dat zou een security-nightmare zijn.
nou nee.
een enorm simpele default policy van block all vanaf het internet en je het precies de zelfde veiligheid als je met nat zou hebben. met dat verschil dat je veel flexibeler bent met wat je wel toe laat. je kan meerdere machines op de zelfde poort publiekelijk bereikbaar maken, of zelfs meerdere machines op alle poorten.

[Reactie gewijzigd door Countess op 2 juni 2014 16:44]

en daarom veel lastiger(duurder) om uit te lezen.
Wat een onzin.
verder is de header checksum verwijderd
Iedere keer wanneer iemand over de verwijderde header-checksum begint, dan moet Baby Jezus een beetje huilen. De header-checksum is heel goedkoop. 1 Instructie. Verwaarloosbaar.
en zijn weinig gebruikte optie zijn uit de header gehaald en naar een veel beter systeem van option headers verplaatst.
En nog steeds is een IPv4 header 2x kleiner dan een IPv6 header.
en TTL is vervangen door een hop limit
En dit is wel het bewijs dat je gewoon een lijstje afrafelt dat je ergens gelezen hebt. Hop limit is slechts een NIEUWE NAAM VOOR HETZELFDE DING. We doen hier niet aan marketing, dit is tweakers. Een beetje inhoud graag.
dat alles maakt het zeker voor de tussenliggende routers veel goedkoper om ipv6 te routen als ipv4.
En daarom is de ipv6 pps altijd lager dan de ipv4 pps zeker ? Allemaal hype, marketing, blahblah, drinking the cool-aid.
Een of andere IPv6 fan die een wiki-page heeft geschreven. Alsof dat wat zegt.

DE IPv4 HEADER-CHECKUM IS EEN ECHTE CHECKSUM. JE TELT DE WAARDEN VAN DE 20 BYTES IN DE HEADER BIJ ELKAAR OP. DAT DOET DE VERZENDER. EEN ROUTER VERANDERT DE CHECKSUM NIET, BEHALVE HET VERLAGEN VAN DE TTL MET 1. ALS DE CHECKSUM DE SOM VAN DE BYTES IS, EN JE VERLAAGT 1 BYTE MET 1, DAN VERANDERD DE CHECKSUM OOK 1 MINDER !!
Duidelijk ? De checksum wordt ge-decrement met 1. Da's alles. Een simpele machine-instructie. Verwaarloosbaar. En al 20 jaar lang wordt er onzin verkocht dat IPv6 snellere forwarding zou hebben. Allemaal myth en hype.
je kan meerdere machines op de zelfde poort publiekelijk bereikbaar maken, of zelfs meerdere machines op alle poorten.
Da's waar. Echter, ik denk niet dat veel thuisgebruikers daar veel gebruik van zullen maken.
Da's waar. Echter, ik denk niet dat veel thuisgebruikers daar veel gebruik van zullen maken.
En daar zit een groot stuk van het probleem, "je (JIJ) denkt" terwijl ik vind dat we daar niet zo stellig in moeten zijn. Ik wil wel mijn koelkast publiek kunnen benaderen om maar iets te noemen.

Wat jij ervan vind is voor mij bijzaak. Steeds mensen beschuldigen van onwetendheid en het voorlezen van marketing is ook een zwakte bod vind ik. Ik werk in de IT en heb niet van ieder vakgebied evenveel kaas gegeten, maar kan met een hoop zaken wel meekomen.

Ik zie bijvoorbeeld in dit http://www.ipv4depletion.com/?p=672 een aardige uitleg en ook met de reacties erbij waarvan ik redelijkerwijs kan aannemen dat het geen onzin verhaal is als ik afga op de kennis die ik reeds heb over de materie en consistentie van het verhaal.

Wat betreft je opmerkingen over dat alles intern bereikbaar is en dat je dat niet wilt, zou een security guru je ook de tent uit kunnen vloeken mbt NAT en "firewall".
Dat je geen NAT nodig hebt bij IPv6 is inderdaad een voordeel. Helemaal mee eens. Of het in de praktijk zo'n gigantisch voordeel is als IPv6-lovers doen voorkomen valt nog te bezien. Zeker wel als je nog geen eigen IPv4 adres hebt. Maar in ons geval (een land met veel v4-adressen) maakt het minder uit.

Het noemen van de headerchecksum en de TTL/hoplimit is echt een voorbeeld van ontwetendheid. Ik zal daar niet mijn mond over houden.

De link die je geeft is heel goed. Interessant, to-the-point, en accuraat. Het geeft aan dat TCAM een schaarse resource is. Met IPv4 is er een probleem. Echter, ik geloof niet dat IPv6 dat probleem oplost. Er zijn weinig IPv6 routes nu, omdat er veel minder sites zijn die IPv6 draaien. Als de hele wereld over gaat, dan zal het aantal toenemen. Zie deze grafieken:
http://bgp.he.net/report/prefixes
550K v4-prefixes.
21K v6-prefixes.
47K ASes met v4-prefixes.
8K ASes met v6-prefixes.
ASes (Autonomous System, ieder onafhankelijk netwerk heeft er eentje. ISPs, grote multinationals, etc).

Ieder AS adverteert dus ~10 v4-prefixes.
En ieder AS dat v6 doet, adverteert ~2.4 v6-prefixes.

Daarom geloof ik dat als iedereen v6 doet, er minimaal 47K *2.5 = 125K v6-prefixes zullen zijn.
En als klanten multi-homing willen, dan verhoogt dat aantal flink.
Voor je het weet brengt de entropie ons naar 250K v6-prefixes. En dan heb je hetzelde probleem met de TCAM als v4 nu heeft.

Het gaat er om dat IPv4 en IPv6 precies hetzelde model hebben voor routing. En precies hetzelfde systeem om adressen uit te delen. Beide hebben geen fatsoenlijke manier om snel je hele AS te hernummeren. En beide hebben geen fatsoenlijke manier om multi-homing te doen. Daarom denk ik dat uiteindelijk IPv6 niet beter zal zijn dan IPv4. IPv6 had routing structureel kunnen en moeten verbeteren. En dat heeft het niet gedaan.

Het grootste bewijs is de rate of adaptation. Het feit dat IPv6 zo langzaam wordt ingevoerd geeft aan hoe weinig echte verbetering er is.
Daarom geloof ik dat als iedereen v6 doet, er minimaal 47K *2.5 = 125K v6-prefixes zullen zijn.
wat totaal niet relevant voor je punt is omdat in tegenstelling tot ipv4 de subnets niet overal en nergens terrecht gaan komen.
je kan dus in je routing tables grote hoeveelheiden van die prefixes bundelen omdat je weet dat alles uit het zelfde land komt of zelfde wereld deel.

elk wereld deel heeft maar een aantal ranges. elke ISP heeft maar 1 prefix nodig. elk bedrijf is onderdeel van de range van een ISP. dat alles maakt routing veel eenvoudiger.
Ik probeer twee punten te maken:
1) De IPv6 header maakt packet-forwarding niet sneller. Hoogstens (een klein beetje) trager.

2) Het routing systeem van IPv4 is verre van perfect. Echter, het routing systeem van IPv6 is precies, maar dan ook precies hetzelfde. En dus niet beter.

Als je denkt dat IPv6 de wereld gaat verbeteren omdat adressen hierarchies worden uitgedeeld, dan staat er je nog een verrassing te wachten. Als het zo simpel was, waarom hebben ze dan niet gewoon in 1996 het hele Internet hernummert ? Dat was veel makkelijker geweest dan een nieuw incompatible protocol in te voeren.

Je kunt adressen hierarchisch uitdelen. Maar dan ben je vergeten dat 1) er altijd multi-homing is, waarbij iedere multi-homed site een extra prefix in de globabl routing space injecteert, 2) er multi-nationals zijn, 3) het Internet geen geograpische topologie volgt, 4) de topologie constant veranderd. Voor we 5-10 jaar verder zijn, is de global-routing-table net zo groot.
En nog steeds is een IPv4 header 2x kleiner dan een IPv6 header.
waarvan een router echter het grootste deel NIET hoeft te lezen. in tegenstelling tot ipv4. en alles wat hij WEL moet uitlezen zit altijd precies op de zelfde plekken, wat het heel eenvoudig maakt om dat hardwarematig te optimaliseren en te versneller.

je kan wel wegwuiven dat de verschillen verwaarloosbaar klein zijn, met miljoenen packets per seconde op een backbone tikt het wel aan!
En in een IPv4 header veranderen de velden dagelijks van plaats of zo ?
En in een IPv4 header veranderen de velden dagelijks van plaats of zo ?
Eens met je punt.

Met het risico omdat ik het niet na heb gezocht ik nu wat doms ga zeggen;

Ik denk dat er dan met IPv6 wel meer ruimte / flexibiliteit is voor uitbreiding. Voor zaken die nu nog niet worden gebruikt maar die er wellicht wel aan komen in de komende X jaar. Risicovol discussie onderwerp met QOS en netneutraliteit maar volgens mij is daar de IPv6 pakket beter geschikt voor (ook met oog op routing) dan het IPv4 pakket.

Even daargelaten hoeveel beter IPv6 dan zou mogen zijn, IK heb in iedergeval in de laatste paar discussies/ nieuwsberichten weer een hoop bijgeleerd.

En vanuit mijn oogpunt vind ik dat alleen maar goed :D
Maar ja, OSI deed het zo, dus *moest* de IPv6 community het anders doen.
volgens mij heeft dat geen fluit te maken met 'dan moeten wij wat anders'. Internet (ethernet) is altijd al platter geweest dan het OSI model (daarom moet ik altijd lachen als iemand het OSI model er bij pakt, OSI heeft 3 lagen meer dan Ethernet)

Daaruit komt het voort. Het is ethernet, geen OSI.
volgens mij heeft dat geen fluit te maken met 'dan moeten wij wat anders'.
In de jaren negentig was er echt oorlog wat betreft netwerk standaarden. Groter dan PC vs Mac. Aan de ene kant had je de gevestigde orde. De standarisatie-comitees (ISO in dit geval), de PTTs, de overheden, etc. Surfnet bv stond aan de kant van OSI. Aan de andere kant had je de wereld van TCP/IP. Universiteiten, startups, researchers, en een handvol fanatieke individueen. Echt, alles wat op CLNS leek, was niet welkom in de TCP/IP wereld.
Internet (ethernet) is altijd al platter geweest dan het OSI model (daarom moet ik altijd lachen als iemand het OSI model er bij pakt, OSI heeft 3 lagen meer dan Ethernet)
1) Internet en Ethernet hebben niks met elkaar te maken.
2) Ik heb het niet over het OSI-model. Ik heb het over de OSI-protocol suite. Da's CLNS voor layer-3, TP4 voor layer-4, X.400 in plaats van rfc822/SMTP, etc.

Ik begrijp niet wat je bedoelt met al je opmerkingen over Ethernet. De hele discussie heeft niks met Ethernet te maken.
En waarom zou het sneller moeten zijn ? Ten eerste implementeren snelle routers alles in ASICs en TCAM en andere hardware oplossingen. Ten tweede is een grote factor bij het forwarden hoe snel je een pakket (of header) kunt kopiereen in memory. IPv6 headers zijn groter, dus duurt het langer om te kopieren. Er is geen enkele reden waarom het sneller zou zijn.
Als de interface / bandbreedte zoals bij veel componenten ook groter is geworden waardoor een IPv4 pakket 1x maar ook een IPv6 pakket in 1x kan worden verwerkt dan gaat dat niet op.

Dan zou de afweging weer zijn hoeveel routing entries een router zou hebben en mogelijke performance verlies op andere typen van lookups. Hoe meer IPv4 wordt opgehakt, hoe groter de routing tabel zal worden opeen backbone netwerk.

Aangezien ze de tcam moeten delen zal het interessant worden hoe de verdeel sleutel zal zijn. Maar dan hebben we het over dual-stack routers.

Al met al is IPv6 routering performance niet een goed punt om als verbetering aan te voeren.

Voor wat betreft routering tussen verschillende netwerken bv over VPN's zou ik het wel een verademing vinden tenopzichte van IPv4 nu met double NAT.
Al met al is IPv6 routering performance niet een goed punt om als verbetering aan te voeren.
En dat is precies wat ik wilde zeggen.
Dank je wel dat je mijn mening acknowledgt.
En waarom zou het sneller moeten zijn ? Ten eerste implementeren snelle routers alles in ASICs en TCAM en andere hardware oplossingen. Ten tweede is een grote factor bij het forwarden hoe snel je een pakket (of header) kunt kopiereen in memory. IPv6 headers zijn groter, dus duurt het langer om te kopieren. Er is geen enkele reden waarom het sneller zou zijn.
Als je begint over "IPv6 heeft geen checkum", dan ga ik huilen. Het herbereken van de IPv4 header-checksum is een enkele instructie (subtract - 1).
Het is meer dan alleen de adressen. De theorie is dat je een IPv6 pakketje onder normale omstandingeheden niet hoeft te kopieren maar het hele routeren in place kan doen. Of dat in praktijk ook lukt durf ik niet te zeggen.

Voor de duidelijheid, ik verwacht zelfs in het beste geval geen schokkende verschillen, maar in theorie zou het sneller kunnen zijn.
Onzin. De physieke netwerk structuur blijft precies hetzelde. Bij zowel IPv4 als IPv6 heeft iedere segment een eigen prefix (aka subnet). Ieder interface heeft een eigen ip-adres. Alles is dus hetzelfde. Je statement is dus onzin.
Ik heb het over versnippering van subnetten. In IPv4 is het zo dat twee aangrenzende /16's in totaal andere netwerken aan verschillende kanten van de wereld kunnen zitten en hoe groter de nood wordt hoe verder het zal versnipperen. Hoe meer versnippering hoe groter de routetabellen en hoe moeilijker de routers het krijgen. Onder IPv6 hebben we weer genoeg ruimte om lekker grote blokken uit delen die niet verder worden opgesplitst naar verschillende geografische locaties.
Er zal wel een omslag in het denken bij veel netwerkbeheerders moeten komen maar uiteindelijk denk ik dat niemand de versnippering leuk vindt.

Het is ook niet meer nodig dat grote internetbedrijven allerlei kleine subnetjes opkopen om maar genoeg adressesn te hebben.
moeten hebben voor iedere machine. Een veel betere oplossing imnsho. Maar ja, OSI deed het zo, dus *moest* de IPv6 community het anders doen. En dus slechter. Met dit adres-model zou het makkelijker zijn om de adressering te plannen. En nog belangrijker, multi-homed machines zouden automatisch werken, zonder dat de application-layer iets hoeft de doen. Een gemiste kans.
Daar kan ik het alleen maar met je eens zijn, IPv6 had zoveel meer kunnen zijn, het is maar een erg minimale upgrade ten opzichte van IPv4. Als er een bedreiging is voor IPv6 dan is dat van een ander protocol dat veel meer echte verbeteringen heeft.

Ik ben het met je eens dat versnippering een grote bedrijging is. Als we niet oppassen en IPv6 net zo inrichten als IPv4 lopen we binnen de kortste keren tegen problemen aan.
Het gaat erom welk device je een publiek ip-adres wilt geven. Op het moment zou dat voor mij alleen een http-server en een sshd-server zijn. Dan moet je twee "gaten prikken" in je NAT (voor poort 22 en 80). En klaar is kees. Ik zou zeker niet willen alles thuis direct te benaderen is. Dat zou een security-nightmare zijn.
Voor mij hoeft ook niet alles direct benaderbaar zijn maar ik wil graag zelf kiezen. Nu heb je precies 1 poort 80 (22/25/443/whatever) per aansluiting terwijl het gemiddelde huishouden al meer dan 10 apparaten met een internetaansluiting heeft en dat zullen er alleen maar meer worden. Natuurlijk zijn er oplossing bedacht die om de beperkingen heen werken maar het blijft extra gedoe wat er niet zou zijn als er voldoende adressen waren.
Als jij alles achter 1 adres wil proppen, prima, maar anderen maken misschien een andere keuze. Die is er nu niet.

[Reactie gewijzigd door CAPSLOCK2000 op 2 juni 2014 17:24]

Natuurlijk, maar dual-stack is niet trager dan enkel IPv6 of enkel IPv4. Het is niet zo dat je computer eerst IPv6 gaat proberen, na een tijdje opgeeft en dan pas naar IPv6 gaat. Dat is wat ik wou zeggen :)
Je hoeft zelf niets te doen zodra je eenmaal op dual-stack zit. Er zal standaard IPv6 gebruikt worden tenzij het niet beschikbaar is. In dat geval zal je computer terugvallen naar IPv4.

Tenzij je dingen als SixOrNot installeert zul je er als gewone gebruiker niets van merken.

[Reactie gewijzigd door Maurits van Baerle op 2 juni 2014 14:34]

het terug schakelen gebeurt vanzelf
ik zit via xs4all al jaren via dual stack en mits juist ingesteld
wordt een adres altijd eerst via ipv6 opgevraagd.
bij geen reactie wordt er uitgeweken naar ipv4.
ik bemerkt in de praktijk geen vertraging als iets via ipv4 benaderd wordt.
Ik denk, dus ik doe IPV6.
Dat dacht ik ook. En ik heb dus al meer dan een jaar IPv6. Het gaat echter niet vlekkeloos.
Je Primairy DNS zal je IPv6 adres worden dus mocht je om bepaalde redenen je IPv4 DNS willen wijzigen loop je tegen problemen aan.
Het word tijd dat er een gebruiks vriendelijk handleiding geschreven word.
wat de Providers ( xs4all en Kpn ) doen ze geven je een IPv6 adress, maar waar moet je het gebruiken ? in je Hub ,in je Modem? wat zijn de sub nummers in je eigen netwerk ? wat als je geen DHCP gebruikt , hoe moet je je net werk Nrs/adressen opozetten ? hoe moet je de instellingen definieren als je de client/Lan adressen dirtect via het net wilt aanspreken ? etc etc. Het staat of valt bij een duidelijke begrijpelijke instructie. we zijn niet allemaal leden van : The Internet Society , RFC 4291, of Cisco enginerds : http://www.6net.org/book/
Meer goede documentatie is altijd welkom mara ik denk dat het in praktijk wel mee gaat vallen. In de meeste gevallen hoeven eindgebruikers helemaal niks te doen. Ieder OS dat de afgelopen 10 jaar is uitgebracht ondersteunt IPv6 out-of-the-box. De routers/modems worden door de providers zelf beheerd, dus daar zullen de meeste eindgebruikers ook niks aan hoeven te doen.
Wie meer wil valt automatisch in de klasse gevorderde gebruikers en die redden zich wel.

Er zijn al een paar grote providers die IPv6 leveren en daar hoor ik eigenlijk nooit klachten over. In de meeste gevallen lijkt het dus gewoon te werken.
Het gaat niet om het feit of het werkt , maar hoe IK, het kan inrichten, niet DHCP etc. van de Provider krijg ik : IPV6 : 2001:980:17DC::/48, wat moet ik met dat getal, waar moet ik het invoeren , en hoe moet ik mijn lokale subnet inrichten ?
Als je met de apparatuur van je provider werkt hoef je zelf niks te doen. Je PC's configureren zich zelf.

Als je meer wil, bv omdat je een tweaker bent die z'n eigen router heeft ingericht en een complex netwerk in huis heeft, dan moet je eens zoeken op "ipv6 adress plan" dan vind je zat informatie.


http://www.internetsociet...-ipv6-address-allocation/
http://www.ripe.net/lir-s...-IPv6-Addressing-Plan.pdf
Bedankt voor de Links, ik had de surfnet versie van 2012 al bestudeerd, maar of ik ben dom of zij zijn te theoretisch in hun oplossing. gewoon simpel, welke ip adressen waar in vullen en hoe je het subnet opstellen.
heel simpel, Ik hoef het NET niet te ontleden. ZOO moeilijk zou dat toch niet moeten zijn. Simpel stroom diagrammetje .
IPv6 gaat uit van DHCPv6 danwel auto-ip...

Er is gewoon geen NAT... door IPv6 is Internet of things mogelijk..

DHCP client aan op de pc, en als het altijd het zelfde IP dient te zijn --> IP reservering
NAT is/was inderdaad een lapmiddel. Maar de vraag is natuurlijk hoe je een thuisnetwerk opzet met IPv6.

Ik heb overigens zelf xs4all en in de praktijk merk ik er niets van dat ik IPv6 heb. Achter de Fritz!box hangen verschillende netwerkapparatuur, maar vooralsnog werkt dat allemaal middels DHCP/NAT.
NAT is/was inderdaad een lapmiddel. Maar de vraag is natuurlijk hoe je een thuisnetwerk opzet met IPv6.

Ik heb overigens zelf xs4all en in de praktijk merk ik er niets van dat ik IPv6 heb. Achter de Fritz!box hangen verschillende netwerkapparatuur, maar vooralsnog werkt dat allemaal middels DHCP/NAT.
bij mij krijgt alles achter de fritzbox wat ipv6 kan doen, direct netjes een v6 adres, en babbelt daar ook meer naar buiten. M'n smarttv bijvoorbeeld? Ipv6, en babbelt vrolijk met youtube over v6, en dat geld ook voor de PS3 en PS4. Heck, zelfs m'n laserprinter van 3 jaar oud.

Standaard staat die fritzbox helemaal dicht, dus van binnen naar buiten kan wel, maar andersom niet tot je het open zet.
Standaard staat die fritzbox helemaal dicht, dus van binnen naar buiten kan wel, maar andersom niet tot je het open zet.
Maar bedoel je daarmee dat het standaard dus goed werkt, of moet je nog wat configureren voordat het standaard huis-tuin-en-keuken-internetten werkt via IPv6? Aangenomen dus dat je geen servers hebt draaien.

[Reactie gewijzigd door Evanescent op 3 juni 2014 00:20]

[...]

Maar bedoel je daarmee dat het standaard dus goed werkt, of moet je nog wat configureren voordat het standaard huis-tuin-en-keuken-internetten werkt via IPv6? Aangenomen dus dat je geen servers hebt draaien.
out of the box werkt het perfect. Alleen als je servers hebt draaien zul je nog expliciet wat open moeten gooien. Voor de rest doet de fritzbox het dynamisch. (dan wel via related firewall rules, dan wel via uPNP)
Ok, voor thuisgebruik is dat een beetje overkill. Een aardige vuistregel is dat alles precies zou werkt als met IPv4 met langere adressen maar dat alle subnetten precies een /64 zijn.
Als je met statische adressen werkt kom je daarmee een heel eind. Als je iets dynamisch wil moet je eens zoeken op dhcpv6 en/of router advertisements.
bedankt, zal even zoeken.
Dit gaat normaal automatisch. Dus "normale" gebruikers hoeven dit allemaal niet te weten, net zo min als die nu ook niks weten over hun IPv4-adressen.

Maar als je bedoelt wat moet ik, als tweaker die zijn eigen netwerk wil inrichten, ermee, dan heb je denk ik pech. Dat is meestal niet waar een provider tijd/geld aan besteedt.
Welke DNS server je gebruikt maakt niet uit hoor. Je kunt rustig een DNS server over IPv4 gebruiken bij een IPv6 verbinding.
Ik heb er problemen mee. Zonder in ban problemen te willen komen zeg ik Netflix. De DNS van IPv6 heeft prioriteit. Dus wat je aan de IPv4 kant invult maakt niets uit.
Ik ben benieuwd hoeveel mensen er dan vrijwillig aan zo'n pilot mee zullen doen. Ze zouden ook een bepaalde groep gebruikers alvast kunnen overzetten. Ik heb trouwens nog geen uitnodiging gezien.
Als ik ZeelandNet zou hebben zou ik direct overstappen. Zit echter al bij XS4ALL, dus profiteer ik al van de vele voordelen van IPv6.
Ik zit ook bij Xs4all (en ik zou ook voor Zeelandnet kunenn kiezen), maar welke voordelen heeft IPv6 helemaal? Ik merk er eigenlijk helemaal niets van.
Voor mij zijn de voordelen dat ik alle apparaten uit mijn thuisnetwerk van buiten kan benaderen zonder gedoe met port-forwarding.

Ik kan nieuwe projecten die ik ontwikkel eenvoudig een aantal IP-adressen toewijzen om mee te testen (dat is lastig met IPv4).

Bijkomend voordeel is ook dat IPv6 minder zwaar is voor routers en modems omdat ze geen NAT-tabel meer hoeven bij te houden.
Wij doen met ons bedrijf (15 verbindingen) direct mee! Wij willen als IT bedrijf juist IPv6 omdat het een stuk makkelijker is dan met IPv4 en NAT werken.
Ik ben zeer benieuwd wanneer andere grote partijen gaan beginnen met het uitrollen van IPv6. Je zou toch zeggen hoe eerder je er mee begint hoe beter je het kunt testen en implementeren.
Zolang de grote ISPs niet aan IPv6 doen zit de markt voor internetproviders op slot. Je kan immers niet genoeg adressen meer krijgen om een nieuwe ISP te beginnen. Voor de grote providers is het dus best fijn zo.

Verder denk ik dat ze investeringen het liefst zo lang mogelijk uitstellen. Liever wat meer winst maken dan investeren in iets dat niemand ziet.

Als laatste zullen ze ook wel geen zin hebben in de problemen die het met zich mee zal brengen. Bij de uitrol van IPv6 zullen er echt wel wat problemen ontstaan en dan krijgen ze ontevreden klanten die de helpdesk bellen. Ik bel daarom maar af en toe de helpdesk om te vragen waar IPv6 blijft.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True