Amazon schakelt ipv6 in voor S3-opslag

Amazon heeft aangekondigd dat zijn Simple Storage Service, beter bekend als S3, nu ook via ipv6 te bereiken is via dual-stack-endpoints. Ipv6-toegang staat niet standaard aan, maar is via een simpel commando aan te zetten.

Jeff Barr van Amazon legt op het S3-blog uit hoe de functionaliteit aangezet moet worden, namelijk door over te schakelen naar nieuwe dual-stack-endpoints. Dit kan door via de AWS command line of via AWS Tools voor de Windows PowerShell de '--enabledualstack'-flag in te voeren.

Na het aanzetten van dual-stack-endpoints, kan de S3-server zowel via ipv4 als ipv6 bereikt worden. Wel waarschuwt Barr dat het belangrijk is om bij gebruik van ip-restricties de gewenste ipv6-reeks toe te voegen aan de reeks ip-adressen omdat anders bepaalde clients mogelijk niet meer kunnen verbinden. Ook is het belangrijk om end-to-end-verbindingen te testen omdat het in uitzonderlijke gevallen zo is dat bepaalde clients wel voor ipv6 geconfigureerd zijn, maar uiteindelijk niet met internet verbinden via ipv6.

De nieuwe mogelijkheden kunnen gebruikt worden voor alle S3-opties, behalve webhosting, S3 Transfer Acceleration en BitTorrent-toegang. Ook is ipv6-toegang niet beschikbaar in China. Beschikbaarheid van ipv6 is belangrijk, omdat het aantal ipv4-adressen praktisch uitgeput is.

Reacties (78)

[slijkie]

Wat ik mij dan afvraag, brengt dit performance-winst met zich mee? of juist het tegendeel?

EDIT:

Volgens RIPE, is ipv4 'net' iets sneller.

Als je data verstuurd waarin andere adressen staan, is het pakketje net iets groter doordat ipv6 adressen groter zijn? vandaar mijn denkwijze, is natuurlijk een miniscuul verschil, maar toch.

[Reactie gewijzigd door slijkie op 22 juli 2024 14:14]

[musiman]

In tegenstelling tot andere reacties zal ik jouw vraag wel even serieus behandelen.

Met IPv6 krijg je in principe geen snelheidswinst, maar eerder het tegenovergestelde. Hoe dat komt? Heel simpel: een netwerkpakketje (ethernet frame) heeft standaard een maximale grootte van 1514 bytes. Zo'n pakketje bestaat grofweg gezegd uit twee delen: header en data. De header bevat de addressering en informatie over wat voor type pakket dit is (denk bijvoorbeeld aan TCP of UDP, HTTP, FTP, DNS of DHCP etc.)
Wanneer de header groter wordt, blijft er logischerwijs minder ruimte over voor de data. Hierdoor heb je meer pakketjes nodig om dezelfde hoeveelheid data te versturen.

Met IPv6 wordt de standaard header grootte 2x zo groot: van 20 bytes naar 40 bytes. Dit komt, omdat de source en destination ipadressen nou eenmaal 4x zo lang zijn geworden. Eigenlijk had de header nog groter kunnen zijn, maar om het niet té groot te laten worden, zijn er meer opties die standaard in de IPv4 header zaten, weggelaten en zijn daarmee optioneel geworden.

edit: ik zie dat je nu jouw vraagpost geëdit hebt en zelf antwoord gegeven. HAHAHA Top.

[Reactie gewijzigd door musiman op 22 juli 2024 14:14]

[slijkie]

Dank! Dit is nou precies wat ik dacht, maar niet zeker wist, had mijn bericht ge-edit met een RIPE onderzoek, wat dit inderdaad ook deels bevestigd.

Wat mij nu lijkt is dat (we moeten uiteraard) we over gaan op ipv6, in de toekomst zullen dan de ipv4 adressen naar grote bedrijven gaan voor het gemak en snelheidswinst (gebruik op grote schaal). Dit lijkt mij dan een realistisch scenario. Algemene consumenten op ipv4, grote bedrijven op beide en server infrastructuur op ipv4.

[musiman]

Wat ik van één van onze providers heb begrepen (was oorspronkelijk insider information), is dat op den duur IPv4 geheel uitgeschakeld gaat worden op hun netwerk. Dat stond in hun forecast.
Ik denk dat "men" dat ook heel graag wil. De reden hiervoor is: routetabellen.

De routers op het internet hebben routetabellen nodig om te weten waar pakketjes naartoe mogen. Met IPv4 was de verdeling van de IP ranges erg gefragmenteerd. Hiermee bedoel ik, dat opvolgende ip ranges wisselend bestemd waren voor bijvoorbeeld een bedrijf in Europa, dan weer voor een bedrijf in Japan, dan weer voor een bedrijf in China, dan weer in Europa, etc.
Hierdoor moe(s)ten de internet routers een enorme routetabel bijhouden. Sinds de jaren 90 hebben vele internet experts het einde van het internet voorspeld, puur om die reden. Men verwachtte dat de routers het niet meer aan zouden kunnen, omdat de routetabellen exponentieel (!!!) groeiden.

Met IPv6 is er een hiërarchische adressering geïntroduceerd die dit moet voorkomen. Oftewel, met IPv6 worden in theorie de routetabellen kleiner. Echter... op dit moment worden ze dankzij IPv6 alleen maar groter, omdat de routers nu én IPv4 én IPv6 routes moeten kennen.

Met het uitschakelen van IPv4 verwacht ik een enorme ontlasting van de routers.

[Verwijderd]

op den duur IPv4 geheel uitgeschakeld gaat worden op hun netwerk.

Mooi voornemen. En hoe lang is "op den duur" ? Ik denk dat dat nog wel 20-30 jaar gaat duren.

Sinds de jaren 90 hebben vele internet experts het einde van het internet voorspeld, puur om die reden. Men verwachtte dat de routers het niet meer aan zouden kunnen, omdat de routetabellen exponentieel (!!!) groeiden.

Nah. Dat valt wel mee. Omdat er een probleem is, wil nog niet zeggen dat dat probleem niet kan worden opgelost.

In 1992 begon de CIDR werkgroep met een snelle tijdelijke oplossing (Classless Inter-Domain Routing en BGP-4). En de IPng werkgroep begon met een lange termijn oplossing. Dat werd IPv6.
De route-tabellen in "het globale Internet" groeiden hard, maar wel lineair. Alleen gedurende een paar jaar (99-01 en 05-07) groeide het iets sneller dan lineair. Zie hier een graph van de groei.

Met IPv6 is er een hiërarchische adressering geïntroduceerd die dit moet voorkomen. Oftewel, met IPv6 worden in theorie de routetabellen kleiner.

Dat is inderdaad theorie. Er zijn twee redenen dat de IPv6 global routing table zo groot is. 1) inderdaad niet opletten bij het uitdelen van addressen, 2) multi-homing (google dat maar). Bij IPv6 is er wel de intentie om hierarchisch uit te delen, maar dat wordt niet altijd netjes gevolgd. Bovendien, als netwerken verhuizen is het nog steeds niet makkelijk om je (IPv6-)adres te veranderen. Hoe langer het duurt, hoe meer entropie in de IPv6-tabel. En hoe meer grote (en kleine) bedrijven overstappen, des te meer entries in de IPv6-tabel vanwege multi-homing. Na verloop van tijd zal de IPv6 tabel net zo veel entries bevatten als de IPv4 tabel.

Met het uitschakelen van IPv4 verwacht ik een enorme ontlasting van de routers.

Als dat al gebeurd, over 20 a 30 jaar, dan zal het weinig meer gaan uitmaken.

[musiman]

[...]
Mooi voornemen. En hoe lang is "op den duur" ? Ik denk dat dat nog wel 20-30 jaar gaat duren.

De toenmalige forecast was: 2022. Die forecast was in 2011. Inmiddels zijn we 5 jaar verder en weet ik niet wat de huidige forecast is van deze provider.

[Verwijderd]

En die provider heeft dat jaartal ook gewoon uit zijn duim gezogen. De waarheid is dat niemand, ook geen enkele expert, weet wat er gaat gebeuren.

[musiman]

Dat weet ik. Maar het is wel een teken aan de wand dat zo'n (enorm grote) provider in de forecast heeft staan dat IPv4 een keer uitgezet gaat worden. Dat staat er niet voor niks.
Maar we gaan nu echt ietsje teveel off-topic.

[Verwijderd]

Niks off-topic, imho. We hebben het over IPv6 en alles wat daar bij komt kijken. Het feit dat Amazon nu IPv6 doet is een grote stap vooruit voor de acceptatie van IPv6.

[Yariva]

Echter zijn de laatste paar ipv4 reeksen nu wel uitgegeven, ik verwacht geen enorme groei meer op IPv4 routes op BGP AS niveau. En grote providers kunnen nog meer met summary routes injecteren op het net, wat de tabel wederom zou moeten verkleinen.

Daarnaast worden die dikke ISP routers alleen maar sneller en sneller, die kunnen al die routes nu nog redelijk behappen.

[TD-er]

Echter zijn de laatste paar ipv4 reeksen nu wel uitgegeven, ik verwacht geen enorme groei meer op IPv4 routes op BGP AS niveau. [...]

Eigenlijk verwacht ik nog meer fragmentering nu de IPv4 pool leeg is.
Je krijgt nu namelijk een handel in adressen, wat zorgt voor verdere fragmentering.

[Yariva]

Dit is inderdaad een mogelijkheid. Echter, wanneer service providers (en kleinere bedrijven) dit goed zouden doen met summary routes en private AS numbers zou dit mee moeten vallen.

Maar ik kan je niets anders dan gelijk geven. Theorie en praktijk ligt vaak erg ver uit elkaar met dit soort dingen.

[slijkie]

Ah, dat is dan weer goed om te weten. Maar vergeet de lijn van groei mbt. rekenkracht, enkele jaren verder en die routers gebruiken nog maar 1% belasting of minder voor die hele ipv4 routetabellen. Ofniet?

In iedergeval zeer interesante ontwikkeling Dank voor alle uitgebreide uitleg, weer een stuk wijzer

[Verwijderd]

Maar vergeet de lijn van groei mbt. rekenkracht, enkele jaren verder en die routers gebruiken nog maar 1% belasting of minder voor die hele ipv4 routetabellen. Ofniet?

Niet.

Het protocol dat gebruikt wordt om alle internet-routes uit te wisselen tussen providers heet BGP (Border Gateway Protocol). Op core-routers (routers in het midden van het Internet) is BGP de grootste gebruiker van CPU. En van memory. Groter dan alle andere componenten bij elkaar.

(Uitleg: in je thuis-router zit meestal maar een reken-chip. De CPU. Die doet twee dingen. 1) hij doet alle administratie, alle routing-protocollen (indien nodig), DHCP (client en server), de web-interface, de command-line interface. de CPU verzorgt het booten en initialisatie, etc. 2) de andere functie is packet-forwarding. Ieder gebruikers-pakketje moet worden door gestuurd. Dat gebeurd ook door de CPU.

Op grote routers zijn die twee gescheiden. Er zit een CPU in voor alle administratie, configuratie, routing protocollen, etc. En er zit dedicated hardware op om pakketjes door te sturen. ASICs, FPGAs of zelfs echte processoren speciaal ontwikkeld om snel pakketjes door te sturen.

BGP gebruikt meer dan de helft van de CPU en het memory.

Ook goed om je te realiseren: CPUs worden niet meer sneller. Ze krijgen alleen nog meer cores. Maar de instructies/seconde wordt niet beter. Dat betekent dat je je routing software parallel moet schrijven. Niet makkelijk, want omdat je met een grote tabel werkt (600k+ routes in het Internet) is er geen natuurlijk vanzelfsprekende manier om je software op te delen in verschillende tasks. (Niet zonder een hoop locking).

Anyway. Mijn punt is: met sneller CPUs wordt er niet veel opgelost.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:14]

[TrailBlazer]

Het verwerken van die routetabel is echt niet het probleem. Het probleem zit het in de ASICS die moeten op wirespeed zien te achterhalen wat de uitgaande interface is voor elk elk pakketje. Dat is de moeilijkheid en daar zit de beperking in. Dat BGP procesje is echt peanuts.

[Verwijderd]

Dat BGP procesje is echt peanuts.

Tuurlijk. Daarom hebben core-router vendors als cisco, Juniper en Nokia (met de SR-routers van voorheen Alcatel-Lucent) ook teams van 5-10 programmeurs full-time werken alleen op BGP. En cisco bv heeft drie van die teams (voor IOS-XR, IOS-XE en Nexus OS).

Zoals ik al zei, op de control-plane van een core-router is BGP de grootste gebruiker van CPU tijd en memory. De forwarding-plane (waar jij het over hebt) is weer iets heel anders.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:14]

[slijkie]

Thanks voor de uitleg. Hoe zit dat dan met bijvoorbeeld Quantum-computing? Nu heb je bijvoorbeeld de D-Wave die enkele bedrijven testen, w.o. Google. Dit is natuurlijk nog in kinderschoenen. Maar zodra dit iets verder uitgewerkt is dan zouden die core-routers toch vervangen kunnen worden met zoiets? Of eraan toevoegen, kan ook natuurlijk. 600k routes dat met Qbits regelt word lijkt mij dat sneller zal gaan (in de toekomst uiteraard).

Hierbij gaat het dan voornamelijk om instructies, en dat doen ze juist goed, ipv de traditionele CPU's.

[Verwijderd]

Het bouwen van provider-netwerken is een hele conservatieve business. Vroeger had je nog "cowboy bedrijven" die heel ondernemend de eerste ISP-netwerken bouwden. En alle nieuwe technologie nodig hadden om te groeien. Maar die zijn allemaal overgenomen door de oude PTTs en Telcos. (Eind jaren negentig en vlak daarna). Niet alleen in Nederland, maar overal in de wereld.

En het is maar goed ook dat je ISP een beetje behoudend is. Je wilt tenslotte gewoon dat je ISP je pakketjes van thuis aanneemt en aflevert bij de bestemming. En niet veel meer. Betrouwbaarheid van je verbinding is het allerbelangrijkst. Eigenlijk nog belangrijker dan snelheid.

Dus ISPs (de oude Telcos en PTTs) zullen de laatste zijn die iets nieuws als quantum-computing gaan gebruiken.

Bovendien, zoals ik al zei, het probleem is niet alleen de grote van de routing-table. Het is ook het feit dat een BGP-implementatie niet zo gemakkelijk parallel te programmeren valt. Gaat wel gebeuren, maar het kost tijd, kost geld, en gaat gepaard met nieuwe bugs. De groei van routes op het Internet is een probleem, maar geen onoplosbaar probleem.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:14]

[Verwijderd]

Is het in dit geval (qua parallel computing) niet handiger om de BGP over te dragen op GPU's en de rest aan de CPU over te laten?

[Verwijderd]

Ik zeg net: het probleem is om parallele software te schrijven. Dat is nooit triviaal. (Tenzij het om problemen gaat die heel makkelijk parallel zijn op de lossen. En de meeste problemen zijn dat niet). Heeft allemaal niks met hardware te maken.

Bovendien stop je geen consumer-grade hardware in grote routers. Die hebben allerlei speciale requirements om de hardware heel robust te maken. Of hoe ze met stroom-gebruik en koeling omgaan. Voorbeeld: een beetje core-router trekt een paar duizend watt aan stroom. Constant.

[Blokker_1999]

IPv4 op het publieke internet zal ooit aan belang verliezen, maar ik zie dat de eerste 10 jaar nog niet gebeuren en verwacht dat ook binnen 20 jaar de meeste services nog bereikbaar zullen zijn via dual stack.

De reden is niet zozeer routetabellen. Dual stack opstellingen zoals we ze vandaag zien (met IPv4 en IPv6 tesamen) voegen een complexiteit toe aan het netwerk die niet noodzakelijk zou moeten zijn. Door terug naar single stack te gaan haal je die complexiteit opnieuw weg.

In 1991 werd trouwens voorspeld dat tegen 2008 het aantal IPv4 blokken dat kon toegewezen worden op 0 zou staan. Dankzij o.a. NAT hebben we dat kunnen rekken tot 2011.

[blorf]

Wat het niet zo dat lokale IPv4 subnetten in een keer overbrugd kunnen worden zonder NAT of VPN toestanden? Lijkt mij dat dat op het grote geheel aardig wat bandbreedte scheelt. Stand-alone computers met eigen lijn gaan die langere adressen merken maar als de route een node korter wordt heb je dat in bandbreedte en tijdsduur volgens mij alweer gecompenseerd.

[Reactie gewijzigd door blorf op 22 juli 2024 14:14]

[musiman]

Ik snap niet precies wat je bedoelt. Zou je de vraag kunnen verduidelijken?

[blorf]

Als je een lokaal subnet hebt met bwvs allemaal computers met ip4 192.168.1.x moet in het geval dat een van die computers een online server is die van buiten direct bereikbaar moet zijn je router een service draaien die een request op het buiten-ip bekijkt, het correcte lokale ip er bij zoekt en de communicatie verder afhandelt.
Met ipv6 kan je een computer die eerder op het lokale netwerk geidentificeerd moest worden nu direct van buiten aanspreken. Dat is mogelijk omdat met een ipv6 nummer meer combinaties mogelijk zijn en dus meer verschillende computers direct adresseerbaar gemaakt kunnen worden.

[Reactie gewijzigd door blorf op 22 juli 2024 14:14]

[musiman]

Oh, jij bedoelt dat je in jouw router aangeeft dat wanneer iemand binnenkomt op het publieke ip adres van de router, maar dan op poort 80 (bijvoorbeeld), dat de router dan het destination ip adres verandert naar het interne ip adres van de computer binnen je netwerk.
Dit levert geen vergroting of verkleining van de header op. Het enige dat gebeurt, is dat het ipadres van de destination gewijzigd wordt. Dat is NAT.

IPv4 is in de jaren 70 bedacht. Pas in 1994 is Network Address Translator bedacht (linkje). De reden dat NAT is bedacht, komt omdat er een naderend tekort aan ip adressen was. Pas in 1996 (linkje) werden de private ranges (10.x.x.x, 172.16.x.x - 172.31.x.x en 192.168.x.x) gereserveerd die wij tegenwoordig gebruiken i.c.m. NAT.

Bij IPv6 heb je ook NAT. Echter, dat hoef je niet te gebruiken. Met IPv6 hebben wij zo enorm veel adressen, dat de noodzaak van NAT voor het grootste deel weg is. Dus ja, je zou nu, net zoals het vroeger ook gewoon was bij IPv4, alle interne devices kunnen voorzien van een globaal uniek adres en ze zonder NAT met het internet kunnen verbinden.
Dit levert mijns inziens echter 0,0% snelheidswinst op.

[Reactie gewijzigd door musiman op 22 juli 2024 14:14]

[hackerhater]

Echter de situatie van intern naar een server die in hetzelfde subnet staat gaat wel sneller :
IPv4 : pc met local address => gateway => [check => rewrite naar intern] => server
IPv6 : pc => server (beide direct benaderbaar)

[musiman]

Dat verschil is dermate klein, dat merk jij echt niet.

[hackerhater]

Nee, maar het ontlast wel de gateway
en in een flink bedrijf merk je dat wel

[Lennie]

Andere oplossing:

Split-horizon DNS

[GMJansen]

Zelfde subnet? Je geeft je eigen antwoord al: het verkeer gaat NIET via de gateway, dus even snel.

[hackerhater]

De gateway, doorsnee de centrale router, zal in het geval van NAT eerst een adres-vertaling moeten doen.

[GMJansen]

Volgens mij ben ik de draad ergens kwijt geraakt:-)
Je wilt vanaf een interne pc naar een interne server, in hetzelfde subnet, of...?

[hackerhater]

Ja terwijl je alleen het externe IP weet
op domeinnaam of zo.
maar goed erg offtopic

[Blokker_1999]

Daar komt IPv6 niet tussen, dat kan je wel realiseren met behulp van MPLS.

[CAPSLOCK2000]

Met IPv6 krijg je in principe geen snelheidswinst, maar eerder het tegenovergestelde. Hoe dat komt? Heel simpel: een netwerkpakketje (ethernet frame) heeft standaard een maximale grootte van 1514 bytes. Zo'n pakketje bestaat grofweg gezegd uit twee delen: header en data. De header bevat de addressering en informatie over wat voor type pakket dit is (denk bijvoorbeeld aan TCP of UDP, HTTP, FTP, DNS of DHCP etc.)
Wanneer de header groter wordt, blijft er logischerwijs minder ruimte over voor de data. Hierdoor heb je meer pakketjes nodig om dezelfde hoeveelheid data te versturen.

Met IPv6 wordt de standaard header grootte 2x zo groot: van 20 bytes naar 40 bytes. Dit komt, omdat de source en destination ipadressen nou eenmaal 4x zo lang zijn geworden. Eigenlijk had de header nog groter kunnen zijn, maar om het niet té groot te laten worden, zijn er meer opties die standaard in de IPv4 header zaten, weggelaten en zijn daarmee optioneel geworden.

Daar wil ik één aantekening bij plaatsen namelijk dat de meeste pakketjes niet de volle 1514 bytes gebruiken maar slechts een fractie daar van. Als er genoeg ruimte overblijft dan maakt een langere header niet uit, het blijft één pakketje. Voor de meeste pakketjes maakt het dus effectief geen verschil.

[Lennie]

Ik denk dat de meeste pakketjes op Internet video zijn ?

Lijkt mij sterk dat streaming video veel pakketjes heeft die niet volledig gevuld zijn.

[vt220]

Ik weet er ook niet het fijne van maar haal je nu niet ethernet headers en tcpip headers door elkaar? Voor zover ik weet bevat de headers van een ethernet frame onder andere de mac adressen van de kaarten (source en destination). De header van tcpip[46] staat dan in het data gedeelte van het ethernetframe. Maar zoals gezegd ik heb de klepel wel horen luiden maar ik heb geen idee waar de klok hangt.

[musiman]

Als IT trainer houd ik het liever even simpel. Natuurlijk kan ik het hele OSI model uit gaan leggen, maar daar heeft de beste kerel niks aan.

[TD-er]

[...] Met IPv6 krijg je in principe geen snelheidswinst, maar eerder het tegenovergestelde. [...]

Maar met IPv4 heb je wel dat data vaak meerdere 'hops' moet maken.
In je router moet het ge-NAT worden. Maar ook aan de andere kant zie je wel dat er 1 frontend is, met daarachter meerdere servers die op die manier ontsloten worden.
Hoeveel dat scheelt durf ik niet te zeggen, maar ik kan mij zo voorstellen dat dat weer in het voordeel van IPv6 gaat qua snelheid.

[Lennie]

Klein voordeel van IPv6 is dat pakketjes niet geparsed moeten worden:

http://ipv6.com/articles/...eater-than-IPv4-Part4.htm

IPv4 daarom is ietsje trager als je het niet in hardware doet.

[goats]

Mijn ervaring met IPv6 is, is dat sommige netwerken vele malen beter bereikbaar zijn via IPv6 dan via IPv4. Daarnaast is het zo dat aangezien IPv6 preference heeft, de dns resolving al vele malen sneller gaat, en dat gaat je dus ook heel veel tijd schelen.
Routerings technisch zie ik minder problemen met IPv6 dan met IPv4. Iets wat over IPv6 bereikbaar is, is vaker onbereikbaar is via IPv4 dan via IPv6. De keerzijde is wel dat sommige ISP's IPv6 niet serieus genoeg nemen, en dat het soms een week kan duren voordat je colocatie gewoon weer bereikbaar is.
De grootte van IPv4 en IPv6 zijn nagenoeg hetzelfde. Voordelen van IPv6 is dat alles bedacht is met (hardware) acceleratie. Dus bit bounderies zijn 64 bits. Optie headers zijn vaste grootte. En extra headers en data zijn goed te vinden.
Het grootste gezeur is je lokale netwerk, dat bij IPv6 geen rol speelt: of je hebt intern een publiek netwerk, of je gebruikt intern link-local. Er is geen dhcp nodig voor link-local.
Persoonlijk gebruik ik altijd link-local voor tijdelijke devices.

[musiman]

DNS resolving geeft bij IPv6 0,0% snelheidswinst. Wat er in een dual stack omgeving gebeurt, is dat jouw pc twee DNS queries stuurt naar de DNS server: eentje die vraagt naar het A-record (dit is IPv4) en eentje die vraagt naar het AAAA-record (dit is IPv6).

Wanneer jouw pc van beide queries het antwoord terug krijgt, dan zal de computer over het algemeen de voorkeur geven aan IPv6. Echter, de verschillende browsers hebben het Happy Eyeballs principe op verschillende manieren doorgevoerd, waarbij Apple zich het minst houdt aan "voorkeur voor IPv6". Safari gaat namelijk eerst kijken welke route de snelste ping geeft en neemt dan de snelste. Dit kan de ene keer IPv4 zijn en de andere keer IPv6.
Browsers, zoals Chrome en Firefox doen het anders. Bij Chrome zal IPv6 de te prefereren route zijn, maar wanneer de website na 200 msec niet reageert, probeert Chrome al om de site via IPv4 te benaderen.
Bij Internet Explorer is het nog weer anders. Die wacht gewoon 8 seconden of de IPv6 verbinding werkt en gaat daarna pas IPv4 proberen.

[goats]

De DNS queries gebeuren over het algemeen niet tegelijk.
Er wordt eerst een AAAA query gedaan, waarbij het zoekpad wordt afgelopen.
Daarna de A query.
Mischien dat er nu systemen zijn die het tegelijk doen, maar over het algemeen dus eerst AAAA, niks gevonden, dan A proberen. Als ze dan ook nog eens hun TTL op < 60s zetten dan wordt het al helemaal traag.
Mijn chromebook weigerde vroeger ipv6 te doen omdat ze ipv6 gingen testen voordat ipv6 volledig en wel geconfigureerd was.
Nu dat gefixt is werkt dat inderdaad heel goed, en zijn het juist de ipv4 sites waar hij wat meer problemen mee heeft. Geen idee waarom eigenlijk.

[musiman]

Heb je ooit gesnift? Dan praten we nog wel een keer. Windows computers sturen beide queries direct achterelkaar.

[Nindustries]

Waarom zou het? IPv6 is ook maar een adressering, dus zou geen merkbaar verschil mogen maken.

[slijkie]

Dat wou ik dus weten, is ook niet nodig, puur uit interesse of dit bekend was of niet.

[hackerhater]

De adressen zijn wel groter cq minder ruimte voor de data => meer packets nodig

[MetalfanBlackness]

Persoonlijk verwacht ik geen grote veranderingen in performance, maar het gaat wel belangrijk worden om ipv6 te ondersteunen. Op den duur zullen sommige providers en/of nieuwe providers geen ipv4 adres kunnen uitgeven en dan komen er dus nieuwe clients die alleen een ipv6 krijgen. Dan is de vraag hoe makkelijk gaat het worden om je content te benaderen.

ps. ik weet dat er nog ipv4 adressen zijn, maar je kunt niet zomaar een huisnummer uit een andere straat gebruiken.

[Kevjoe]

Waarom is het in godsnaam nodig dat hier een performancewinst achter zit? De reden waarom heeft hier niets mee te maken, maar vooral dat het aantal IPv4's gewoon zo goed als op zijn.
Geen IPv4's meer => geen mogelijkheid meer om nieuwe servers toe te voegen aan het IPv4 internet.
Vandaar de omschakeling naar IPv6 - anders stopt de mogelijke groei van het internet. En met de gigantische scale van Amazon kan ik mij gerust voorstellen dat ze langzaam zonder IPv4's komen te zitten. Op dit moment is de enige manier om nieuwe IPv4's te krijgen ze van anderen te kopen.

En geloof me maar, hoe langer hoe duurder dit zal worden. Dus de noodzaak is niet performance, maar omdat het gewoon moet.

Daarnaast, IPv4 en IPv6 hun headers zijn anders, waarbij de IPv6 een veel grotere header heeft. Dat vermindert performance iets of wat, maar qua performance in het echte leven is het verschil te verwaarlozen.

[Reactie gewijzigd door Kevjoe op 22 juli 2024 14:14]

[slijkie]

Dat snap ik helemaal, echter was de vraag, is het bekend of er 'eventueel' performance winst of verlies optreed tussen ipv4 en ipv6. Is er dus echt 0,0% verschil, prima, dat was dus de vraag.

[hackerhater]

Het verlies is verwaarloosbaar. Daaraantegen wordt routing veel gemakkelijker en daar zit dan weer snelheids-winst op.
Maar de grootste winst is dat NAT eindelijk bij het vuilnis kan. NAT is een lelijke hack die ook nog slecht is voor de performance.

[Verwijderd]

Geen IPv4's meer => geen mogelijkheid meer om nieuwe servers toe te voegen aan het IPv4 internet.

Dat blijkt dus mee te vallen.

En geloof me maar, hoe langer hoe duurder dit zal worden. Dus de noodzaak is niet performance, maar omdat het gewoon moet.

Niks moet.
Het grote probleem is dat IPv6 helemaal niks nul nada voordeel biedt aan degene die overstappen van IPv4 naar IPv6. Het kost alleen geld. (Er is menskracht nodig om de overstap te doen. Niet alleen om het netwerk, maar ook alle applicaties aan te passen. En mensen kosten veel geld). In de echte wereld gebeurd nog steeds bijna alles vanwege geld.

Als IPv6 een of meerdere voordelen had gehad over IPv4, dan waren mensen misschien wel sneller overgestapt. Helaas is IPv6 25 jaar geleden ontworpen door kneuzen die geen kaas van networking hadden gegeten. En dus is IPv6 precies (maar dan ook precies) hetzelfde als IP4, alleen met grotere addressen. Een gemiste kans.
En als resultaat zitten we nu met de situatie dat de migratie al 15 jaar duurt en nog wel zo'n 10-20 jaar gaat duren.

[borft]

Dit is gewoon niet waar. Er zijn veel meer verschillen, zie bijvoorbeeld https://en.wikipedia.org/wiki/IPv6#Comparison_with_IPv4

Ik zou met kunenn voorstellen dat het gebrek aan NAT, en slimmere routering bijvoorbeeld wel performance voordelen hebben.

[Reactie gewijzigd door borft op 22 juli 2024 14:14]

[Verwijderd]

Jij kunt je dingen voorstellen. Mooi. Maar computer science is geen kwestie van fantasie en voorstellings-vermogen.

IPv6 is layer 3. De routing layer. Als je kijkt naar de architectuur van IPv6, naar het idee er achter, naar de algorithmen, dan zul je zien dat die precies hetzelfde zijn. Er zijn wel verschillen in details (zoals SLAAC), maar die doen er niet echt toe. De problemen met IPv4 op routing gebied (site address assignment, site mulit-homing, host multi-homing, seamless renumbering, true mobility, persistent tcp connection when renumbering or moving, locator-identifier separation, etc) zijn er nog steeds bij IPv6.

Er is niets veranderd (dat er toe doet). SLAAC bv geeft meer problemen dan dat het oplost.
Lees dit maar eens:
http://blog.ipspace.net/2010/02/ipv6-myths.html

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:14]

[kwikstaart]

Helaas is IPv6 25 jaar geleden ontworpen door kneuzen die geen kaas van networking hadden gegeten. En dus is IPv6 precies (maar dan ook precies) hetzelfde als IP4, alleen met grotere addressen. Een gemiste kans.

Kun je dit ook uitleggen? Wat zijn de gemiste kansen? Die "kneuzen" van 25 jaar geleden hebben wel iets bedacht waar we mee verder kunnen. Dat het 25 jaar geduurd heeft ligt niet aan hen. Zij konden 25 jaar geleden niet weten hoe internet er vandaag uit zou zien, of wat we nu nodig zouden hebben.

En als resultaat zitten we nu met de situatie dat de migratie al 15 jaar duurt en nog wel zo'n 10-20 jaar gaat duren.

Als het zolang duurt, dan zal IPv7 er voorlopig ook wel niet zijn, dus we zijn nog gezegend met IPv6, want IPv4 is over twintig jaar echt niet meer houdbaar.

[Verwijderd]

Kun je dit ook uitleggen? Wat zijn de gemiste kansen?

De gemiste kans was dat als je toch van protocol moet veranderen, wat een hoop bloed zweet en tranen gaat kosten, dan kun je er net zo goed voor zorgen dat je nieuwe protocol alle problemen oplost waar je op dat moment bewust van bent.

In 1990-2000 groeide het Internet als kool. Als je toen voor het juiste bedrijf werkte, verdiende je geld als water. Vooral router vendors en ISPs. Maar er waren ook een hoop bedrijven die de boot hadden gemist. DEC (Digitial Equipment Corporation) was in de jaren tachtig het twede grote computer bedrijf (na IBM). DEC deed een hoop networking. Maar DEC ging deed het slecht, en ging uiteindelijk failliet. De networking lui van DEC hadden dus geen klanten, en dus niet veel te doen. Die hebben zich op IPv6 gestort. Engineers van Sun (ook al verdwenen). Allemaal application-level lui die zich met networking gingen bemoeien. Die begrepen niet eens wat identifier-locator separation is, en waarom het belangrijk is. Die keken alleen vanuit het oogpunt van applicaties. Standaard-discussies zijn nooit leuk. Dus na een tijdje zeiden alle mensen die voor cisco en ISPs werkten: "bekijk het maar met je IPv6, ik ga IPv4-producent maken, en het IPv4-Internet een succes maken". En die mensen (de "makers" van het IPv4_Internet) zijn nu allemaal op vroege leeftijd retired. De "kneuzen" waar ik het over heb, die allemaal voor minder succesvolle bedrijven werkten, moeten nu allemaal nog steeds werken om hun brood te verdienen.

Die "kneuzen" van 25 jaar geleden hebben wel iets bedacht waar we mee verder kunnen.

Nogmaals, IPv6 is in grote lijnen net als IPv4. IPv4 werkt, met zijn beperkingen. Dus IPv6 werkt ook.

Dat het 25 jaar geduurd heeft ligt niet aan hen.

Welles.
Als IPv6 echt nieuwe voordelen had gehad, dan was iedereen er opgesprongen. Dan had niemand hoeven vechten voor de introductie van IPv6. Heb je ooit reclame gezien voor het IPv4-Internet ? Was er een PR-offensief voor nodig ? Nope. IPv4 heeft zichzelf verkocht. Net als http. Alleen IPv6 moet de mensen door de strot worden geduwd.

Zij konden 25 jaar geleden niet weten hoe internet er vandaag uit zou zien, of wat we nu nodig zouden hebben.

Tuurlijk wel. Het is allemaal niet zo heel complex. Maar je moet wel weten waar je het over hebt. En 25 geleden werden de mensen die wel wisten waar ze het over hadden, overschreeuwd door de anderen.

Als het zolang duurt, dan zal IPv7 er voorlopig ook wel niet zijn, dus we zijn nog gezegend met IPv6, want IPv4 is over twintig jaar echt niet meer houdbaar.

Er is een initiatief geweest uit de IETF om te proberen IPv6 om te vormen tot iets wat meer bruikbaar is. Helaas is iedereen zo afgeschrikt door het IPv6-debakel dat er weinig animo voor was. Voorlopig blijven (in het westen vooral) lekker doorgaan met IPv4.

[CAPSLOCK2000]

Wat ik mij dan afvraag, brengt dit performance-winst met zich mee? of juist het tegendeel?

Laat ik vooropstellen dat performance niet het doel is van deze verandering.
Het is heel moeilijk om er in het algemeen iets over te zeggen, maar er spelen meerdere factoren een rol.

- ipv6-adressen zijn inderdaad langer, je moet meer bytes versturen en dat maakt het langzamer.
- netwerkverkeer wordt in pakketjes van min of meer vaste lengte verwerkt, de meeste pakketjes zijn vrij kort en hebben ruimte over waardoor die langere adressen er niet toe doen.
- dit is storage, dat verplaatst veel data en gebruikt goed gevulde pakketjes.
- ipv6-pakketjes zijn handig opgebouwd waardoor het makkelijker is om ze uit te lezen en snel te verwerken
- ipv4 bestaat al veel langer en is extreem geoptimaliseerd, zowel in hardware als in software
- het onderzoek van RIPE gaat over verkeer over heel internet, dat is heel anders dan het verkeer op een min of meer afgesloten netwerk. Vergelijk het met rijden op de openbare weg versus rijden op het circuit.

[Verwijderd]

Het artikel van RIPE waarnaar je verwijst is uit 2001. Recenter is https://labs.ripe.net/Members/gih/examining-ipv6-performance waarin wordt gesteld dat de performance min of meer gelijk is. En in http://www.internetsociet...d-20-40-faster-over-ipv6/ waar IPv6 beter performed.

Waar je kunt aanvoeren dat de packets groter zijn, kun je ook stellen dat IPv4 NAT vertraging heeft door beperkte capaciteit van thuis aparatuur en bottlenecks bij ISP's zoals wan accelerators en dergelijke.

Onderaan de streep maakt het elkaar niet veel uit, echter kijkend naar de toekomst waarbij IPv4 schaarste meer NAT oplevert zal IPv4 performance afnemen en IPv6 performance blijven zoals het is.

[flippy]

waarom zo terughoudend met ipv6? ik heb al jaren een vast ip4 en native ipv6 van xs4all. zo moeilijk kan het toch niet zijn om een router op te hangen met fatsoenlijke ipv6 ondersteuning?

[CAPSLOCK2000]

waarom zo terughoudend met ipv6? ik heb al jaren een vast ip4 en native ipv6 van xs4all. zo moeilijk kan het toch niet zijn om een router op te hangen met fatsoenlijke ipv6 ondersteuning?

Ik denk wel eens dat het een kwestie is van het tegenhouden van nieuwe concurrenten.
Er is nu een handvol grote ISPs die alle IPv4-adressen bezitten. Je kan geen nieuwe ISP oprichten zonder IPv4-adressen. Nouja, technisch gezien kan het wel met CGNAT, maar in NL krijg je dat gewoon niet verkocht. In andere landen waar het tekort groter is en al langer bestaat misschien wel, maar in NL nog niet.

De bestaande ISPs vinden het natuurlijk helemaal niet erg dat het onmogelijk is om een nieuwe concurrent te beginnen. Er is dus een belang om zo lang mogelijk afhankelijk te zijn van IPv4. Als de grote ISPs vlotjes IPv6 zouden invoeren en de markt gaat mee zetten ze daarmee de deur open voor nieuwe concurrenten.

Daarbij zijn grote bedrijven sowieso huiverig voor verandering. Iedere verandering brengt problemen met zich mee en klanten die de servicedesk bellen zijn al snel niet meer rendabel. Overal afblijven en niks veranderen is dan al snel het devies.

[The Zep Man]

waarom zo terughoudend met ipv6? ik heb al jaren een vast ip4 en native ipv6 van xs4all.

Jij wel, een groot deel van de bevolking niet.

zo moeilijk kan het toch niet zijn om een router op te hangen met fatsoenlijke ipv6 ondersteuning?

IPv6 is niet moeilijk. IPv6 met veel (embedded) spul en veel bedrijfsnetwerken wel. Er is vanuit een end-point perspectief weinig vraag, dus weinig aanbod. En doordat er weinig (exclusief) aanbod is, is er weer weinig vraag.

Dat wordt nu langzaam doorbroken. Zo heeft bijvoorbeeld T.net nu ook IPv6 ondersteuning.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 14:14]

[flippy]

maar waarom dan geen native support en zet het standaard aan op zijn minst. op deze manier duurt het nog 20 jaar voordat het fatsoenlijk ingevoerd is.

[Snow_King]

Het is veelal onwil en angst. IPv6 staat ook al even aan bij Google en Facebook, gaat prima!

Nee, Amazon is gewoon heel erg laat.

[Verwijderd]

waarom zo terughoudend met ipv6?

Kost geld.

ik heb al jaren een vast ip4 en native ipv6 van xs4all. zo moeilijk kan het toch niet zijn om een router op te hangen met fatsoenlijke ipv6 ondersteuning?

De wereld is meer dan alleen een stel enthousiastelingen die thuis een router vervangen.

Er draaien meer applicaties op het net dan alleen web-browsers. Die moeten allemaal aangepast worden (lees: de code moet veranderd worden, hercompileerd en gedistribueerd naar alle gebruikers. En echte applicaties gebruik we appstore niet).

Om een groot netwerk aan te passen moet er een hoop gebeuren. En dat moet getest worden. En gepland. En dan uitgevoerd, met alle risicos van dien. Waarom al die moeite, als je zelf nul nada niks geen voordeel haalt bij een overgang ?

[Armin]

| waarom zo terughoudend met ipv6?

Kost geld.

En geeft storingen. Immers onderschat niet de hoeveelheid software die bijvoorbeeld blind aanneemt dat een IP nummer w.x.y.z formaat is, en helemaal over zijn nek gaat met een IPv6 adres

Vaak is software gelaagd en ergens diep in de middelste lagen zit er ene routine die een paar bytes te weinig alloceert. En als je pech hebt doet het dat alleen onder omstandigheden A of B.

Als het dan ook nog eens jouw eigen software niet is, en je support contract al jaren verlopen is, heb je een probleem.

[s_schimmel]

Eindelijk gaat Amazon aan de slag met ipv6, het wordt ook wel tijd voor ze. Nu maar hopen dat ec2 binnenkort ook ipv6 krijgt.

Ipv4 ranges zijn op en het wordt al problematisch voor developers van apps. Apple verplicht sinds kort voor apps dat zij volledig ipv6 moeten kunnen werken. Je backend daarvoor hosten bij AWS is dus niet mogelijk of je moet via tunnels gaan werken.

[WienerBlut]

Ik hoop ook dat ze dat snel eens gaan doen! Maar wanneer je bedenkt wat de omvang van de impact van dual-stack EC2 (incl. VPC etc.) zal zijn op ontwikkeling, testing en support (want relatief weinig mensen snappen IPv6 in vergelijking met IPv4), dan begrijp ik dat ze wat "laat zijn". Niet dat het een vrijbrief is om niets te doen natuurlijk.

We wachten af

edit: zin afgemaakt

[Reactie gewijzigd door WienerBlut op 22 juli 2024 14:14]

[chomp]

Hun Load Balancers ondersteunen natuurlijk wel gewoon ipv6, dus voor de meeste toepassingen is ipv6 gewoon mogelijk.

[s_schimmel]

Helaas niet. Althans, de VPC load balancers niet. De classics wel maar standaard werk je in een VPC.

Load balancers in a VPC support IPv4 addresses only

source

[PageFault]

Niet standaard over HTTPS? Of volgt meteen een soort redirect?

[ToolkiT]

hoe bedoel je? IPv4 vs IPv6 heeft niks met HTTP vs HTTPS dat zit namelijk in een andere laag in de is-osi stack: https://en.wikipedia.org/wiki/OSI_model
laag 3. Network vs laag 5. Session

zie ook https://support.microsoft.com/en-us/kb/103884

[PageFault]

Klopt, maar ik zie in de genoemde URLs HTTP staan, terwijl ik bij cloud diensten standaard HTTPS verwacht. Dat dit niks met IPv6 te maken heeft an sich, daar heb je gelijk in.

Maar wellicht weet iemand hoe dat bij de S3 service zit.

[ToolkiT]

ah op die fiets.. volgens mij is dat een keuze die je zelf in kan stellen op je bucket..
Ze hadden idd wel beter een https voorbeeld kunnen gebruiken..

[PageFault]

Okay, dank voor je antwoord. Tzt maar een keer induiken.

Ja security zou default by design moeten zijn tegenwoordig...

[ToolkiT]

mee eens.. bij AWS heb je alle opties zelf in de hand..
Op zich staat S3 log van http(s) want het gebruikt een ander protocol.. maar de endpoints gebruiken het wel..

[CyBeR]

Dat is aan de klant van amazon om te beslissen -- amazon zelf ondersteunt beide maar maakt geen keuze voor je.

[Verwijderd]

Daar zijn ze wel laat mee.