Apple eist ipv6-ondersteuning bij apps op iOS 9

Apple verplicht ontwikkelaars ipv6-ondersteuning in hun apps in te bouwen, als ze willen dat hun apps goedgekeurd worden voor de App Store. De verplichting gaat in bij de release van iOS 9, later dit jaar. Veel ontwikkelaars hoeven hier waarschijnlijk niets voor te doen.

Apple wil dat alle ontwikkelaars voor iOS apps bouwen die werken op ipv6-netwerken, maakte Sebastien Marineau, Apples vice-president Core OS tijdens de Platform State Of The Union op WWDC 2015 bekend. Het concern maakt daarom ipv6-ondersteuning verplicht bij het indienen van apps voor de App Store.

Marineau wijst erop dat de ipv4-adressen op aan het raken zijn en providers ertoe over gaan ipv6-only uit te rollen. "Als je apps niet goed overweg kunnen met ipv6, werken ze simpelweg niet goed op die netwerken, voor die carriers en voor die klanten", zei hij. Apple zegt dat ontwikkelaars drie stappen moeten ondernemen: de netwerkframeworks als NSURLSession gebruiken, api's vermijden die specifiek met ipv4 werken en geen hardcoded adressen hanteren.

Omdat veel ontwikkelaars deze best practices al gebruiken, verandert er voor hen waarschijnlijk niets, schrijft InternetSociety. Wie er desondanks zeker van wil zijn dat zijn app overweg kan met ipv6, kan bij de komende OS X-versie, El Capitan, een hotspot opzetten met de 'ipv6-only'-optie geactiveerd. Slaagt de verbinding van de app dan ondersteunt deze ipv6.

OS X ondersteunt ipv6 sinds versie 10.1 en iOS sinds versie 4.0.

Reacties (86)

[Verwijderd]

Dit is waarschijnlijk de enige manier om het voor elkaar te krijgen. De meeste developers besteden hun tijd liever aan nieuwe features dan aan dit soort basiszaken (zou ik ook doen als ik moet investeren; niet veel mensen zullen een app kopen omdat het IPv6 ondersteunt).

[Yzord]

Het verbaasd me überhaupt dat het allemaal zo traag gaat met de invoering van ipv6. Toch heb ik me laten vertellen dat ipv6 minder veilig zou zijn dan ipv4, maar waarom is mij nooit echt duidelijk uitgelegd.

[CAPSLOCK2000]

Er zijn nogal wat mensen die denken dat NAT een afdoende beveiliging is en dat je die moet missen omdat je onder IPv6 geen NAT nodig hebt. Ze vergeten echter dat die veiligheid niet komt van NAT (adressen vertalen) maar omdat NAT noodzakelijkerwijs geen inkomende verbindingen toe staat.
Inkomende verbindingen verbieden kan echter prima met IPv6, daar heb je een firewall voor. Iedere router die IPv6 kan doorgeven kan het ook firewallen.

Een IPv6 firewall is zelfs veiliger dan NAT. Een hoop mensen willen namelijk stiekem toch wel inkomende verbindingen accepteren, bv voor spelletjes, voip, een bewakingscamera, om de verwarming de verlichting via internet aan te zetten of om een slimme meter uit te lezen. Voor een deel kan dat met NAT door poorten te forwarden en voor een deel kan het eigenlijk niet. Er zijn dus allerlei hacks bedacht om het toch voor elkaar te krijgen, bv upnp of Hole Punching. Dat soort hacks kunnen echter ook misbruikt worden. De extra complexiteit maakt het systeem ook nog eens moeilijker te begrijpen en daardoor is de kans op beveilingsfouten ook weer groter.

Wel is het zo dat IPv6 een extra mogelijkheid biedt om met jouw computer te verbinden. Als je het niet gebruikt dan heb je dus een extra risico waar je geen voordeel aan hebt. Net zoals een gasfornuis op zich niet heel gevaarlijk is maar je laat het niet branden als je niet aan het koken bent.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 04:03]

[Kees]

Alleen ga je nu hetzelfde krijgen. Mensen willen stiekum ook inkomende verbindingen accepteren maar willen niet zelf de portforward opzetten poort open zetten in de firewall. Dus zul je daar ook weer hacks voor gaan krijgen zodat apps zelf hun poorten open kunnen zetten in de firewall.

Want iemand die allang blij is dat de router out of the box werkt en zelfs het standaard wachtwoord van de router niet aanpast zal zeker niet blij worden als iets niet werkt wat voorheen gewoon werkte.

Verder zorgt ipv6 ook voor een hoop extra complexiteit, helemaal als clients gaan ipv6 hoppen omdat ze random een adres kiezen. Dan zou je elke keer handmatig de firewall moeten aanpassen (en niet vergeten oude rules weg te gooien). Dus dat nadeel van nat geldt net zo hard voor ipv6

[CAPSLOCK2000]

Alleen ga je nu hetzelfde krijgen. Mensen willen stiekum ook inkomende verbindingen accepteren maar willen niet zelf de portforward opzetten poort open zetten in de firewall. Dus zul je daar ook weer hacks voor gaan krijgen zodat apps zelf hun poorten open kunnen zetten in de firewall.

Het verschil is dat een IPv6-firewall makkelijker is om goed te configureren. In een NAT-omgeving kun je iedere poort maar één keer gebruiken. Als je twee apparaten hebt die allebei een webserver op poort 80 draaien dan zul je bij NAT één van die twee een andere poort moeten geven.

Ten tweede voorkom je het probleem dat veel routers hebben dat NAT-PT alleen op de externe interface werkt en dat je daarom vanaf je interne netwerk niet kan verbinden met dat ip en die poort.

Ten derde heb je geen probleem meer met protocollen die het IP-adres van de client gebruiken zoals FTP. Daarbij stuurt de client z'n eigen IP-adres mee maar de andere kant kan er niks mee omdat het een RFC1918 adres is dat niet bereikbaar is vanaf internet. Daar zijn wel weer oplossingen voor bedacht maar een IPv6 router/firewall heeft die niet nodig.

Er zullen nog steeds upnp-achtige protocollen worden gebruikt maar die kunnen eenvoudiger zijn wat de kans op fouten verkleint.

Verder zorgt ipv6 ook voor een hoop extra complexiteit, helemaal als clients gaan ipv6 hoppen omdat ze random een adres kiezen. Dan zou je elke keer handmatig de firewall moeten aanpassen (en niet vergeten oude rules weg te gooien). Dus dat nadeel van nat geldt net zo hard voor ipv6

Voor een goed geprogrammeerde client zou dat geen probleem moeten zijn want die privacy-adressen zijn alleen voor situaties waarin je geen inkomende verbindingen hebt. Daarnaast heb je altijd ook nog een gewoon vast adres waarop je wel verbindingen kan accepteren. Al zal ik direct toegeven dat niet iedereen goed programmeerd.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 04:03]

[Brahiewahiewa]

Euh, dat hoppen gebeurt toch alleen voor uitgaande verbinden?

[freaky]

[muggenziftmodus]
Met IPv6 maak je geen port forwards aan. Alleen een allow rule voor bepaald verkeer (mits er een stateful firewall voor staat uiteraard - wat wel aan te raden is ).

Port forwarding is een typisch NAT dingetje. In principe maak je een object/forward aan vanaf IP x poort x, naar IP y poort y en een rule die dat toe staat. Met IPv6 maak je alleen een rule aan die verkeer naar x:x toestaat.

Nu kun je IPv6 ook wel NAT'en uiteraard, maar daar is simpelweg geen noodzaak voor.
[/muggenziftmodus]

[dmantione]

Er is inmidels, ondanks heel veel weerstand, ook NAT in ipv6, omdat NAT te veel in de hoofden van mensen zit ingebakken en het als argument werd ingezet om niet naar ipv6 te migreren. Dus degene dit dat wil kan "gewoon" NAT voor zijn veiligheid blijven gebruiken met alle nadelen van dien.

[Verwijderd]

Ik nat thuis op ipv6 omdat het niet anders kan.
De router van mijn provider heeft een /64 subnet om alle clients ipv6 te geven.
Als ik achter die router een 2e router hang ben ik verplicht om te gaan natten, er is geen enkele manier waarmee die 2e router zich als router bekend kan maken en een /80 subnet kan vragen om dan verder uit te delen.

[dmantione]

Je kunt een /64 wel opsplitsen. Toegeven, daarmee moet je autoconfiguratie opgeven, wat net als NAT niet de bedoeling achter ipv6 is, maar het kan wel en is een stuk sjieker dan NAT gebruiken in zo'n situatie.

[Verwijderd]

dat weet ik en zou ik ook doen maar helaas is de router van de provider dichtgetimmerd (is geen probleem van ipv6).
het zou echter erg mooi zijn als een router via autoconfig gewoon een range kon aanvragen.
dat gaan ze toch nog moeten uitvinden want anders gaat elke normale consument die een 2e router koopt problemen hebben.

[Verwijderd]

De provider levert dus geen /48 én staat het niet toe om de router in bridge mode te zetten? Dat zou voor mij genoeg reden zijn om naar een concurrent te stappen. Met IPv6 zal ik pertinent weigeren om nog NAT toe te passen. Dan wil ik alleen nog puur publieke IP-adressen gebruiken met alle voordelen die daar bijhoren.

[Blokker_1999]

Er zitten wel degelijk enkele nuttige zaken in NAT waardoor NAT op IPv6 gevraagd werd. Ondanks het feit dat NAT niet welkom was in de standaard netfilter van de linux kernel werd de functionaliteit er door velen toch ingepatchet waarna besloten werd om het toch maar op te nemen.

Dat betekend niet dat men voor de huis-, tuin- en keukencomputer NAT zal gaan toepassen met IPv6.

[dmantione]

Een gebied waar ik het nog wel toegepast zie worden is als je bewust je apparaten wilt verbergen voor het netwerk, bijvoorbeeld stel je hebt in een hotel betaald internet afgenomen voor een bedrag per 24 uur. Stel je wilt zowel je laptop als telefoon met het WLAN-netwerk van het hotel verbinden. Een tweede apparaat aanmelden betekent dat je ook voor dat apparaat zult moeten betalen. In dat geval kan het nuttig zijn het tweede apparaat achter het eerste te verbergen via NAT.

[Floor]

Omdat het minder anoniem is. Dat is wat ik ervanaf weet maar verder, geen flauw benul.

[mdavids]

Hoi Floor,

IPv6 had (aanvankelijk) geen DHCP. IP-adressen werden verkregen m..b.v. SLAAC, wat er in het kort op neerkomt dat van het subnet dat aan jou is toegewezen (de prefix) en het MAC-adres van je PC een uniek IPv6 adres wordt samengesteld.

Theoretisch nadeel daarvan is, dat als je met die PC naar je werk gaat en daar ook een IPv6 adres via SLAAC krijgt, een tracker aan dat MAC-deel zou kunnen afleiden dat jij het bent (de prefix is uiteraard anders op je werk). En idem als je naar een congres gaat, of op vakantie bent. Kortom, je zou te tracken zijn op basis van dat achterste deel van je IPv6-adres, dat is gebaseerd op je MAC-adres.

Maar dit probleem is simpel ondervangen met RFC4941. Komt er in het kort op neer dat je PC niet het echte MAC-adres van je ethernet-interface gebruikt, voor het genereren van het IPv6 adres, maar een random-waarde (die ook nog geregeld kan wijzigen). Zo is het leven weer goed en ben je niet meer te tracken. Meeste OS-en ondersteunen dit, vaak al per default.

Er is zelfs een standaard, nog niet wijd in gebruik (RFC7217), die zorgt dat je in een bepaald netwerk steeds hetzelfde IPv6-adres krijgt (kan handig zijn), maar over de verschillende netwerken waartussen je pendelt, toch steeds een andere 'suffix' gebruikt.

En inmiddels is er ook gewoon DHCPv6 trouwens, waarmee je het probleem ook kunt ondervangen.

Kortom, zoals Blokker_1999 al aangaf, je hoeft met IPv6 zeker niet minder anoniem te zijn. Eerder het tegenovergestelde.

[Reactie gewijzigd door mdavids op 23 juli 2024 04:03]

[Floor]

Kijk, weer een hoop bij geleerd. Bedankt!

[Blokker_1999]

Imho even anoniem als IPv4 kan zijn.

[Verwijderd]

Huidige thuisverbindingen met meerdere systemen achter 1 router werken vaak met NAT. Dat zorgt er ten eerste voor dat de verbindingen voor buitenstaanders vanaf 1 IPv4 adres komen, en ten tweede dat binnenkomende verbindingen niet zomaar werken omdat er niet expliciet een mapping is van externe poortnummers naar interne IP adressen en poortnummers. Min of meer krijgen gebruikers dus een laag cadeau die sommigen zien als beveiligingslaag. Dat is het in zekere zin wel, maar zo is het niet bedoeld.

Met IPv6 is het de bedoeling dat een router de hele achterliggende netwerkrange kan routeren, dus stel een thuisgebruiker krijgt een 2001:abcd:1234:5678::1/64 adres op de publieke interface van zijn router, dan zou de router bijvoorbeeld alle verkeer naar dat subnet doorsturen, en er wordt dus niet gefilterd omdat de router gewoon het verkeer doorstuurt.

Gevolg is dus dat ofwel de router ook expliciet een taak van firewall moet krijgen, of dat er een firewall voor de router wordt gezet. Een firewall is namelijk WEL specifiek ingezet als beveiligingslaag. NAT op IPv6 is wel mogelijk maar het is een vorm van schijnveiligheid.

[Blokker_1999]

Ik ben nog geen enkele setup tegengekomen waar de modem/router bij IPv6 standaard inkomend verkeer naar de private adress range toestaat. Toegegeven, mijn ervaring is beperkt tot enkele vlaamse ISPs, maar die zetten het inkomende verkeer standaard dicht en ik verwacht dat de meeste ISPs dat zullen doen bij gewone consumenten net opdat de apparatuur in huis niet benaderbaar is zonder toestemming van de gebruiker.

[Verwijderd]

Welke "de private address range" bedoel je? Als je een publiek subnet krijgt is het niet nodig private ranges te gebruiken, als je dat wel doet, is het simpelweg NAT oude stijl.

En ja, de ISP's zouden dat moeten doen door hun modem/router standaard een degelijke firewallconfiguratie mee te geven. Dat is min of meer wat ik bedoelde te zeggen.

[Blokker_1999]

Het subnet dat je krijgt bedoel ik daarmee. Het is inderdaad niet helemaal correct om ze privaat te noemen daar ze publiek aanspreekbaar zijn.

[manniss]

Dat sommige zeggen dat ipv4 veilig is dan ipv6 zal waarschijnlijk te maken hebben met het feit dat ipv6 nu nog vaak door ipv4 tunnels wordt gestuurd naar zijn eindbestemming. Dit omdat ipv6 nog niet overal is geïmplementeerd.
Omdat de pakketten dan geëncapsuleerd zijn binnen de tunnel kunnen deze niet geïnspecteerd worden door firewalls en dergelijke.
Deze onveiligheid zal zichzelf echter oplossen bij de verdere uitrol van ipv6.

Bij het opbouwen van ipv6 zou trouwens meer rekening gehouden zijn met veiligheid.
Zo was origineel IPSec verplicht, dit is later echter afgezwakt naar 'sterk aangeraden'.

[t1mmy]

Developers hoeven aan de app kant niets te doen om IPv6 te ondersteunen, Apple's libraries ondersteunen het al. Ze moeten er alleen voor zorgen dat hun server IPv6 ondersteunt

[Tjidde]

Dat is minder als je een server ergens huurt die het niet ondersteund moet je of overstappen of je app word niet meer toegelaten.

[t1mmy]

Als je poster geen IPv6 ondersteunt is het wellicht sowieso een goed idee om over te stappen... Ik kan mij zo 123 geen hoster bedenken die het nog niet ondersteunt

[Yggdrasil]

Nou, Amazon Web Services, de grootste hoster ter wereld levert nog geen IPv6 op VPC, hun standaard virtual server dienst.

Bij EC2-Classic, de voorloper van VPC, kon je daar nog omheen werken door een Elastic Load Balancer (ELB) af te nemen, waarop wél IPv6 beschikbaar was, maar zo'n ELB is bij VPC alleen maar via IPv4 bereikbaar.

Omdat Amazon naast virtual servers een hele reeks cloud-infrastructuur levert is het voor veel klanten niet zo eenvoudig om over te stappen. Ze zijn niet voor niks marktleider. Het zal voor Amazon dan ook zeer complex zijn om IPv6 overal in te voeren, maar het wachten duurt me nu wel lang!

[borft]

VPC en EC2 zijn twee compleet verschillende dingen EC2 is een gevirtualiseerde server omgeving, waar VPC een gevirtualiseerd netwerk is.

[Yggdrasil]

Ja, maar ik wilde het niet complexer maken dan het al is. De termen zijn in de afgelopen jaren een aantal keer van betekenis verandert.

Amazon heeft EC2 hernoemt naar EC2-Classic. Nieuwe accounts krijgen hier niet eens meer toegang toe! De term EC2 (nieuwe stijl dus) verwijst nu naar de virtuele servers binnen een VPC. Feit blijft dat voor alle diensten binnen een VPC géén IPv6 wordt aangeboden, waar dat voor EC2-Classic wél mogelijk was (echter alleen als je wilde betalen voor een ELB load-balancer). Amazon houdt, zoals altijd, de lippen stijf op elkaar over wanneer nieuwe features beschikbaar komen.

De enige mogelijkheid om momenteel IPv6 beschikbaar te krijgen binnen een VPC is door zelf een tunnel te maken naar bijv. SixXS.

[CAPSLOCK2000]

Dat is dan weer een goede reden voor de hosters om ook IPv6 aan te bieden. Er zijn overigens al best veel hosters die het hebben. Die hosters voelen het probleem namelijk al branden. Hosters zijn grootgebruikers van IP-adressen. Het liefst zouden ze iedere website z'n eigen IP-adres geven maar dat is al 20 jaar niet meer haalbaar.
Daar zijn dan wel oplossingen voor gevonden (zoals virtual hosts) maar tegenwoordig huurt jan en alleman een VPS. Die VPS'jes moeten ook allemaal een IP-adres krijgen en daar is nog geen goede oplossing voor. Er zijn al een aantal hosters die VPS'en leveren met alleen een IPv6-adres. Als je ook een IPv4-adres wil moet je bijbetalen.

[Maurits van Baerle]

Er zijn al een aantal hosters die VPS'en leveren met alleen een IPv6-adres. Als je ook een IPv4-adres wil moet je bijbetalen.

Klopt, ik kwam laatst bijvoorbeeld Mythic Beasts tegen die een IPv6-only VPS aanbieden. Ideaal om te testen of bijvoorbeeld als het een backend server is die toch alleen maar met andere servers praat, over IPv6.

[Yggdrasil]

Gandi.net doet dat ook. IPv6-only servers zijn bij hen goedkoper dan dual-stack.

https://www.gandi.net/new...7/1166-ipv6-only_servers/

[CAPSLOCK2000]

De meeste apps zullen inderdaad niks hoeven te doen maar er zijn er ook die niet de standaard libraries gebruiken maar het zelf willen doen. Daarnaast zijn er apps die op de een of andere manier IP-adressen verwerken. Die zullen zich moeten aanpassen.

[CAPSLOCK2000]

Ik denk dat er een flink aantal apps zijn die wel IPv6 zouden willen gebruiken omdat het hun leven makkelijker zou maken maar die het niet doen vanwege het kip-ei probleem. Zolang IPv6 op de meeste netwerken niet beschikbaar is vinden developers het niet de moeite waard om er in te investeren. Juist in de wereld van mobiel internet is het tekort aan adressen het grootst. Daarbij weten we dat we nog lang niet klaar zijn. Het grootste deel van de wereld heeft nog geen smartphone maar zal die in de komende jaren wel gaan aanschaffen. Om het nog maar niet te hebben over dat steeds meer mensen meerdere mobiele devices hebben.

Door het gebruik van IPv6 op deze manier te kickstarten maakt Apple het een stuk aantrekkelijker voor mobiele providers om IPv6 te gaan gebruiken. Ik verwacht dat de volgende stap is dat ze van hun partners gaan verlangen dat ze IPv6 beschikbaar maken.

[Titan_Fox]

Tegen de tijd dat er enkel nog IPv6 is kunnen die developers hun app natuurlijk gewoon nog een keer verkopen. Zo vang je 2x geld voor dezelfde app. Tot het zo ver is blijf je je IPv4 geschikte app gratis updaten.

[Yggdrasil]

Huh? Lijkt me sterk dat klanten zullen accepteren dat een ontwikkelaar nogmaals geld vraagt voor dezelfde app met een ander IP protocol (waarvan de klant niks merkt).

[Trommelrem]

Werd tijd. Goede zet van Apple om IPv6 support te forceren. Wellicht kunnen we IPv4 over 20 jaar eindelijk eens uitschakelen

[Maurits van Baerle]

Het hangt er vanaf wie je bedoelt met 'we'

De wereld hoeft IPv4 niet uit te schakelen. Er zijn nog zoveel antieke protocollen die sporadisch worden gebruikt, IPv4 hoort daar ook bij.

Het enige wat je zult zien is dat je binnen tien jaar als thuisgebruiker IPv4 uit kunt zetten zonder dat je er last van hebt en de kans dat jouw ISP je nog een publiek IPv4 adres geeft zal steeds kleiner worden. Steeds meer ISP's zullen hun klanten een publiek IPv6 adres geven en een IPv4 achter Carier Grade NAT.

[Trommelrem]

Zouden er dan ook weer vele IPv4 adressen vrij komen?

[Maurits van Baerle]

Ik denk dat IPv4 adressen steeds meer bij consumenten weggehaald zullen worden om te worden gebruikt voor servers.

Voor gewone gebruikers zijn IPv4 adressen niet zo belangrijk, die kunnen gewoon IPv6 gebruiken. Voor servers wil je juist heel lang Dual Stack (IPv4+IPv6) kunnen gebruiken. Servers zullen nog lang die paar mensen moeten ondersteunen die nog steeds apparatuur hebben die niet IPv6 compatible is.

Je ziet het ook aan de waarde van adressen. IPv6 adressen zijn gratis terwijl IPv4 adressen steeds duurder worden. Bedrijven kopen IPv4 adressen uit failliete boedels etc. om te voorkomen dat ze zonder komen te zitten. Die prijsstijging zal doorzetten totdat de prijs ineens instort omdat IPv4 niet meer nodig/waardevol is.

Binnen een paar jaar zullen grote consumenten ISP's hun IPv4 blokken gaan verkopen aan hosters etc. en hun klanten achter IPv4 CGNAT gaan zetten. Als klant hou je dan een publiek IPv6 maar krijg je bijvoorbeeld voor een IPv4 adres uit de 192.168.x.x reeks.

[Verwijderd]

Zeker. Maar IPv4-adressen zullen dan even nuttig en waardevol zijn als nu een oude 486-laptop op je zolder.

[pennywiser]

IPv$ gaat nooit uitgezet worden. Over tig jaar gebruiken we het nog steeds.

[Erycius]

Ze forceren niet IPv6, maar wel de support ervoor. IPv6 forceren, zoals jij zegt, zou bijvoorbeeld zijn te verbieden om nog via IPv4 verbinding te maken.

Lichtjes offtopic: wat is er gebeurd met IPv5?

[Aertsvijand]

Enig zoekwerk brengt aan het licht dat "IPv5" wel degelijk bestaat, maar dat dit een experimentele aanvulling was op IPv4 en nooit geïmplementeerd is geweest. Daarom heet het ook niet IPv5, maar gewoon RFC 1819. Zeer beknopte uitleg kan je ook vinden op Wikipedia.

[DB LucF]

Off-topic antwoord
IPv5 is nooit officieel geworden. Wat leesvoer:
https://en.m.wikipedia.org/wiki/Internet_Stream_Protocol

[mkools24]

Ipv4 bestaat uit 4 octetten x.x.x.x ipv6 uit 6 x:x:x:x:x:x. Logisch dus om het v6 te noemen want 1,2 en 3 bestaan ook niet.

[Verwijderd]

een IPv6 adress bestaat uit 8 chunks (van 16 bits) die op zijn ouderwets ook 'octets' worden genoemd
hexatet lijkt me een beter passende benaming..

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:03]

[CyBeR]

Euh, nee. Een IPv6-adres bestaat uit 16 octets. Een octet is hetzelfde als een byte. D'r is niemand ter wereld die een 16-bit short een 'octet' noemt.

[Blokker_1999]

128 bits verdeeld over 8 segmenten komt toch echt uit op 16 bits per segment. Een IPv6 adres heeft nog altijd een notatie van ####:####:####:####:####:####:####:#### . Je mag wel zeggen dat je een IPv6 adres kunt noteren in 16 octets, maar dat is niet de manier waarop het gebeurd.

[CyBeR]

128 bits verdeeld over 8 segmenten komt toch echt uit op 16 bits per segment. Een IPv6 adres heeft nog altijd een notatie van ####:####:####:####:####:####:####:#### . Je mag wel zeggen dat je een IPv6 adres kunt noteren in 16 octets, maar dat is niet de manier waarop het gebeurd.

Dat zeg ik. Dat zijn geen octets.

[Verwijderd]

een IPv6 adres bestaat niet uit 16 octets, die bestaat uit 8 'chunks' die bij oude gewoonte octets worden genoemd

en een octet bestaat uit 8 bytes, vandaar dat die 'octet' heet

[Dopehead]

Wikipedia :

An octet is a unit of digital information in computing and telecommunications that consists of eight bits. The term is often used when the term byte might be ambiguous, as historically there was no standard definition for the size of the byte.

[CyBeR]

een IPv6 adres bestaat niet uit 16 octets, die bestaat uit 8 'chunks' die bij oude gewoonte octets worden genoemd

Nee. Echt niet. Ik gebruik al 12 jaar IPv6 en jij bent de eerste.

en een octet bestaat uit 8 bytes, vandaar dat die 'octet' heet

dafuq?

[Yggdrasil]

Iets met klok en klepel. Ik vermoed dat comrade met 'oude gewoonte' refereert naar IPv4, waar een adres bestond uit 4 octets, en het 'octet' zo genoemd werd omdat het bestond uit 8 bits (niet bytes!) echter weergegeven al decimale waarde.

Ook ik heb de term octet wel eens gebruikt horen worden voor de 8 groepen in IPv6 adressen, maar zeker niet vaak en het is ook zeker niet correct.

[Dorank]

Het hele geneuzel over octeten is natuurlijk onzin, ipv4 is een 32bit getal, ipv6 is een 128bit getal. De meest voorkomende presenaties zijn (omdat dat enigszins human readable/memorable is)
ipv4: per byte in decimaal gescheiden met .
ipv6: per 2 bytes in hex gescheiden met :

Maar in de ipv4 stack je kan zonder probleem ipv bv 127.0.0.1 ook gebruiken:
- 2130706433 (decimal)
- 0x7f000001 (hex)
- 017700000001 (octal)

Rare is dat de ipv6 tools schijnbaar alleen de ":hex:" vorm snappen/parsen.

[Aaargh!]

Dat is incorrect. Een IPv6 address is 128 bits dus 16 octets.

[et36s]

Kan Apple zelf geen api ontwikkelen die ipv6 toevoegt? Maar goed dat er eindelijk een bedrijf is die het voortouw neemt. Alleenheersers zijn not always evil

[ieperlingetje]

de netwerkframeworks als NSURLSession gebruiken

. Als je gebruikt maakt van de standaard libraries zou het normaal al in orde zijn, enkel als je eigen specifieke libraries hebt geschreven kan het zijn dat je aanpassingen moet uitvoeren.

[maevian]

een goede dictatuur is beter als een slechte democratie

[Verwijderd]

Volgens mij is Europa een goed voorbeeld

[markjans83]

Zou je in iOS 9 dan ook je IPv6 adres kunnen zien bij je wifi-settings? Op zowel iOS 8 als op de Apple TV kun je die nu niet zien. Zou wel handig zijn.

[Snow_King]

Dat hoop ik wel ja! Nu moet je nog een 3rd party app daar voor installeren.

[CAPSLOCK2000]

Wauw, dat is groot nieuws. Opeens hebben miljoenen developers een dringende reden om zich in IPv6 te gaan verdiepen en hun code aan te passen. Niet alleen de apps zullen nu IPv6 gaan ondersteunen maar ook de frameworks waar ze mee gebouwd worden. Een aantal van die frameworks richt zich niet alleen op iOS maar wordt ook breder gebruikt. Het zal dus een flink olievlek effect hebben.

Ik ben wel benieuwd wat Apple precies verwacht en hoe ze dat gaan testen. Ik heb al heel wat applicaties gezien die technisch gezien wel IPv6 ondersteunen maar dat op zo'n onbeholpen manier doen dat het in praktijk heel onhandig is. Zo ken ik een web-applicatie waar je een IP-adres uit een range moest kiezen door er op te klikken. Toen die applicatie IPv6 kreeg heeft de ontwikkelaar niet beseft dat IPv6-netwerken best wel groot zijn en had je opeens een lijst van honderduizenden pagina's.

[Maurits van Baerle]

Ja, ik verwacht ook dat het een olievlek werking zal hebben. Grote app developers zullen altijd proberen zoveel mogelijk code te hergebruiken voor meerdere platforms. Als je dan toch je frontend en/of backend IPv6-compatible moet maken voor iOS kun je dat net zo goed ook doen voor Android/WP etc.

[databeestje]

Moet Microsoft toch eindelijk aan de bak om Skype geschikt te maken. Voor al deze jaren is de App niet in staat om iets met IPv6 te doen. Sterker nog, het verbind met letterlijke IPv4 adressen, dat gaat dus niet werken met providers die IPv6 only aanbieden. De combinatie van DNS64 en NAT64 werkt namelijk alleen met hostnamen, maar niet met letterlijke IPv4 adressen.

Een ander heikel punt is de WiFi hotspot ondersteuning, daar zijn zowel de fabrikanten als carriers nog niet uit hoe ze dat gaan doen. Mijn voorkeur gaat uit naar het behandelen van de Wifi hotspot als een router (deze doet nu ook NAT44) en via de carrier een DHCP-PD delegatie te doen zodat je daar willekeurige apparaten op kan aansluiten compleet met IPv6 routering, net als de Ziggo thuis doet.

Zo loopt er nu op de Google android bug tracker een vurig draadje over de DHCP6 ondersteuning in Android (die mist). https://code.google.com/p/android/issues/detail?id=32621

[Maurits van Baerle]

Wat zou dan een andere methode zijn dan er een router met PD van te maken? En waarom zou dat een optie zijn, wat is het voordeel boven een router met PD?

[DexterDee]

Doet me denken aan het standpunt van Apple omtrent Adobe Flash support in iOS. En dat is redelijk succesvol gebleken. Ik vind het een goede zet!

[DenBeke]

Toch raar dat de site van Apple nog altijd niet met IPv6 bereikbaar is als ze het zo hard willen promoten...

[BikkelZ]

Volgens mij zijn er héél weinig apps die nog ergens een zelfgerolde netwerkstack gebruiken die alleen v4 ondersteunt. Vrijwel alle frameworks zoals AFNetworking gebruiken in de basis altijd alsnog de Apple bouwstenen.

Ik kan me alleen voorstellen dat Remote Desktop achtige applicaties nog een C++ stack gebruiken omdat de desktop applicatie die ook had.

[Verwijderd]

in Asie zijn IPv4 blocks zo goed als op en Apple wil simpelweg de markt niet verliezen.

[Blokker_1999]

In India zijn ze gewoon volledig op en word op IPv4 vandaag al carrier grade NAT uitgevoerd. Ook hier bij ons zie je NAT bij mobiele operatoren.

[Trommelrem]

Hoe doen ze dat in Noord Korea eigenlijk? Daar hebben ze slechts 1024 IPv4 adressen. Hebben die al een IPv6 blok?

[Reactie gewijzigd door Trommelrem op 23 juli 2024 04:03]

[CAPSLOCK2000]

Ik neem aan dat ze daar ook heel veel NAT doen, misschien wel drie lagen. Daarbij komt dat een groot deel van de bevolking nog geen internet heeft.

[DenBeke]

Noord-Korea heeft toch een eigen internet (Kwangmyong), dus ik vermoed dat voor hen dat probleem zich niet echt stelt...