Geeft het presenteren van je IP adres in IPv6 notatie bij internetten meer security als de (meest gebruikte) IPv4 notatie? Of is het juist andersom?
Ik denk dat de meningen hierover verschillen.
Veel mensen zijn bang voor een lek, omdat het nog te nieuw is.(anno 1995)
Nord VPN:
Naast het feit dat er met IPv6 meer adressen beschikbaar zijn en je afscheid kunt nemen van allerlei andere onnodige servers en tussenoplossingen, is IPv6 ook een stuk veiliger dan IPv4. Je maakt hier gebruik van het IPsec-protocol. Dit protocol functioneert op het niveau van de network layer en verzorgt de authenticiteit van IP-pakketten. Authenticiteit is een van de belangrijkste onderdelen van veiligheid, naast autorisatie en accounting. Met IPv6 blijft je data vertrouwelijk. Daarnaast ben je ook verzekerd van data-integriteit. Dat is zeker welkom in een tijd waarin de privacy-schandalen elkaar opvolgen.
Persoonlijk denk ik, dat het onveilig kan zijn, omdat we het vermijden.
Hoe meer je het gebruikt, hoe veiliger het wordt.
1 like
Ik denk dat qua security IPv4 en IPv6 elkaar niet veel meer ontlopen. Voor velen is IPv6 misschien nog de ânew kid on the blockâ, maar zowel de protocollen als de implementaties zijn al decennia oud.
IPSec is inderdaad onderdeel van IPv6, en NordVPN gebruikt dat misschien, maar dat betekend weer niet dat met IPv6 alles ineens IPSec is. Ook in dat opzicht is er geen verschil met IPv4.
Wat qua privacy wel een verschil is is dat veel IPv6 implementaties de netwerk prefix aanvullen met een (afgeleidde van) je MAC adres. Daarmee maak je jouw machine wel erg eenduidig identificeerbaar. Uiteraard zijn daar oplossingen voor zoals de privacy extensions, maar die moet je vaak zelf expliciet aanzetten.
Ja, daar zat ik ook aan te denken. Ben nog niet genoeg ingelezen mbt IPv6.
Kan me voorstellen dat als iemand in een logfile mijn IPv6 adres ziet staan ipv mijn IPv4, dat dat cryptischer overkomt. Aan de andere kant geef wel meer informatie (MAC) dan bij het presenteren van de laatstgenoemde.
Waar zet ik dat aan ?!? (en hoe) Router ?!?
In mijn beleving hebben de meeste besturingssystemen tegenwoordig de privacy extensions standaard aan staan.
Als je IPv6 adres geen âff:feâ in het adres heeft, is je MAC-adres niet uit het adres af te leiden. Voor informatie hierover zie Stateless address autoconfiguration (SLAAC) [en]
Dit schakel je in je client (i.e. je PC). Bij mijn MAC staat dit standaard aan. Seattleware zul je aan een windows gebruiker moeten vragen, weet ik niet.
Overigens wordt dit privacy ding veel groter gemaakt als dat het is.
Stel je voor dat jouw laptop MAC adress heeft: 00:11:22:33:44:55.
Een IPv6 netwerk wat gebruik maakt van SLAAC (stateless IP assignment levert dan als IPv6 adres op (bij Freedom): 2a01:3781:xxxx:yyyy:0011:22ff:fe33:4444
waarbij xxxx verschillend is iedere klant, en yyyy een âsubnetâ nummer is wat de klant zelf in kan stellen.
Ga je nu met je laptop naar locatie A, dan krijg je bijvoorbeeld 2a01:3781:1000:0000:0011:22ff:fe33:4455.
Ga je met diezelfde laptop naar locatie B, dan krijg je bijvoorbeeld
2a01:3781:2000:0000:0011:22ff:fe33:4455.
De vet gedrukte nummers zijn afhankelijk van je MAC adres en blijven dus hetzelfde.
Zie je een IPv6 adres waar deze bytes hetzelfde zijn, dan zou het âjouw laptopâ kunnen zijn.
Maar de meeste IPv6 netwerken gebruiken DHCPv6 en dan is er geen relatie meer tussen MAC adres en IPv6 adres bij verschillende locaties. Het is dus een enorme storm in een vingerhoed water; het geldt alleen bij gebruik van SLAAC
In vergelijking: kijk voor de grap eens welke cookies er in je browser zijn achtergebleven. Had je opnieuw in moeten loggen toen je naar dit forum kwam? Heb je al eens google âuitgelogdâ en gekeken wat er dan allemaal niet meer werkt? Ik hou mijn browser enigszins schoon, maar toen ik recent de cookies wiste van een laptop van iemand anders was de wereld te klein want âniets werkte meerâ. En dat heeft niks te maken met IPv6.
Oh, en realiseer je dat Android (nog steeds) geen DHCPv6 ondersteunt, alleen SLAAC. Maar je, als je een Android-toestel koopt dan weet je dat maar de helft van het toestel betaalt, de rest betaal je met je privacy (ontbreken van). En ook dat heeft weer niks met IPv6 te maken.
RFC4941 [1] staat sinds jaar en dag standaard aan op elk modern OS. Dat is echt een oude discussie. Tegenwoordig is het overigens onderdeel van RFC8981 [2].
[1] RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
[2] RFC 8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
2 likes
Laat ik van de gelegenheid gebruik maken om een 5-minuten IPv6 cursus te geven voor die mensen âdie zich niet genoeg inlezenâ.
- IPv6 is â96 more bits, no differenceâ. Een IPv4 adres heeft 32 bits, een IPv6 adres heeft 128 bits
- Subnet mask is altijd hetzelfde: een /64 ofwel 64 bits netwerk adres, 64 bits host adres.
- Je kunt een compleet IPv4 adres in het host gedeelte van een IPv6 adres stoppen. Dat is gemakkelijk, want het scheelt een aparte administratie voor IPv6. Je IPv4 adres 192.168.2.1 zou je om kunnen zetten naar 2a10:3781:1000:0000:192:168:2:1. Dat âwerkt gewoonâ, kun je vanavond nog aan de gang
- IPv4 NAT wordt misbruikt als âsecurity argumentâ, is gewoon niet waar. De IPv6 gateways die ik ken, blokkeren inkomende IPv6 verbindingen (het is handig om dat een keer te controleren!). En dan heb je met IPv6 thuis dezelfde security als IPv4 thuis. Basta.
- De 5 minuten zijn voorbij. Welkom met je nieuwe, werkende IPv6 verbinding! Van IPv6 zie je vaak helemaal niks. Om te testen kun je eens kijken naar https://www.test-ipv6.com
Spannender is het allemaal niet. Heus!
3 likes
Dank voor deze heldere les.
Maar -naast deze uitleg- geldt ook: IPv4 wordt schaars ( gemaakt? )
Dus mijn vraag :
De IPv4-adressen worden duur voor Freedom; dus stel dat ik alléén nog IPv6 wil gaan gebruiken, moet ik dan niet
-
EN in de PC aangeven (zie scherm-1)
-
EN in de router (FritzBox; zie scherm-2)
Zijn er nog meer plekken waar ik iets moet doen ?
IPv4 wordt NIET schaars gemaakt. âŠ
Er zijn 2^32 theoretische adressen door architectuurkeuzen is pakweg 3/4 van deze adressen werkelijk beschikbaarâŠ
In begin jaren 70 toen netwerken in een embrionaal stadium waren, achte IBM de wereldwijde markt voor computers iets van maximaal een 1000 tal. Rond 1974 was het idee voor IP netwerken min of meer rond. Het aantal computers was mogelijk iets hoger ingeschat, 10000-100000.
Dus 32 bits voor adres ruimte was EXORBITANT, er zijn toen ook hele /8 blokken aan bedrijven gegeven die meewerkten aan de ontwikkeling.
Begin jaren 90 werd ingezien dat de vlucht van IP (v4) zo groot werd dat er niet voldoende adressen waren.
Anyway: Als IPv4 uitgeschakeld wordt, zou het systeem (inmiddels) geen A DNS lookups meer mogen doen, en geen ARP verkeer meer doen.
Daarmee wordt het IPv4 netwerk effectief niet meer gebruikt.
Er zal nog de nodige software rondhangen die IPv6 niet begrijpt⊠dat adres vertalen is vooral iets dan applicaties doen waarbij het OS slechts een handje helpt.
Door gebrek aan ARP zal voor IPv4 geen buursysteem gevonden kunnen worden.
Op de PC zal vink bij IPv4 instellingen dat IPv4 vereist is verwijderd moeten worden.
Maar die kan Freedom niet allemaal gebruiken, omdat er clubjes zijn die vrijkomende IPv4-adressen harder sparen dan postzegels ( voor de jongeren onder ons: stickers om op papieren mail te doen, vaak met mooie afbeeldingen )
en âdusâ worden ze schaars.
Als 240/4 ooit uitgegeven zou worden duurt dat nog jaren om goed geregeld te krijgen in allerlei firmware. De zgn. Class E reeks. âreservedâ / experimenteel⊠zijn dus zonder wijziging op vrijwel alle apparatuur (modems, TVâs, etc. ) niet bruikbaar.
Verder zijn er GEEN adressen meer vrij tenzij iemand ze wil verkopen⊠en iedereen die op momenteel âongebruikteâ adres reeksen zit wil die alleen maar verhuren(leasen)⊠dat levert meer op, en kost dan ook meer.
US Defensie heeft een aantal adres reeksen, maar de kans is HEEL groot dat die niet vrij komen, en mogelijk al intern gebruikt worden zonder koppeling aan publiek netwerk (op dit moment).
Overigens zijn adressen een druppel op de gloeiende plaat. Er komen een paar (ok miljoen) adressen bij, IPv6 geeft miljarden maal miljarden adressen. Nat levert in dat kader meer op omdat er pakweg een 5 tal bitjes / IPv4 adres worden toegevoegd. ie IPv4 * 32.
maar ja IPv6 is 32 extra bits, en dan mag daarachter ook nog eens per Globaal adres 2^64 nodes aangesloten wordenâŠ
Wereld oppervlak is ~ 2^48 vierkant meter. ~2 bits voor adres classieficatie.
Er zijn dus 2^(62-48) = 2^14 = ongeveer 16K prefixen / m2 over de gehele aardbol (dus ook op zee).
Daar helpen een paar IPv4 adres met heel veel kunstgrepen niet heel erg mee.
(Btw. op elk van die 16 K prefixen / m2 kunnen ieder 2^64 systemen neergezet worden).
Dit is wat Drs_W bedoelt met het hard sparen. Wolken en bedrijven als TikTok gooien goud geld naar IPv4 adressen. Die situatie maakt het voor een partij als Freedom lastiger/duurder om klanten een IPv4 adres te bieden.
Zelf IPv4 uitzetten als Freedom abonnee zal niet concreet bijdragen, want Freedom heeft sowieso een IPv4 adres voor jouw aansluiting gereserveerd. Ik weet ook niet of de PPPoE-verbinding zoals die nu ingericht is, ermee om kan gaan. Als het al werkt, zal je merken dat verschillende sites niet meer bereikbaar zijn.
Als het vanuit Freedom interessant zou zijn, zou er wellicht nagedacht kunnen worden over het op ISP niveau aanbieden van faciliteiten om de afhankelijkheid van een IPv4-adres per klant te verminderen.
Opties zijn:
- CGNAT voor IPv4, dan heb je aan de klant kant nog altijd een IPv4 netwerk nodig
- Vertaalslag op netwerkniveau, hier zijn een aantal standaarden voor onder andere IVI zie ik, dan zou een klant netwerk geen IPv4-faciliteiten meer nodig hebben
- HTTP(S) proxy, hiermee kunnen systemen en applicaties die helemaal geen IPv6 ondersteunen aan de klant kant, verbinding maken met IPv6 sites, maar het werkt alleen voor software die met een HTTP(S) proxy kan functioneren
- Vast nog meer varianten
De bovenstaande varianten sluiten elkaar niet uit, dus er zal in de toekomst wel een combinatie ontstaan. Het hoeft ook niet per se op ISP niveau. Je kunt zelf experimenteren. Op een gegeven moment is de tijd wellicht rijp om dit samen met Freedom te testen om toe te werken naar een situatie waarbij een IPv4-adres per klant optioneel is. In Nederland is de situatie nu relatief lux. Een gemiddelde ISP in het buitenland biedt enkel IPv4 met CGNAT 
Je kunt bijbetalen voor een publiek IPv4-adresâŠ
Ik verwacht dat Freedom vooralsnog investeert in IPv4-adresruimte, maar ik zou zelf ook graag bijdragen als er actief gekeken werd om de afhankelijkheid van IPv4 te verminderen.
mbt. Het sparen, KPN heeft groot ingekocht begin jaren 2000, daarna heeft KPN een heleboel kleine ISPâs (mogelijk ook een aantal opgerichtâŠen daarna) opgekocht die ook een voorraadje hadden.
Dit heb ik van een oud-medewerker van KPN-research ergens rond 2006-2008.
IVI (aka stateless NAT64)âŠ
Voor zover ik weet is dit begraven, UDP, ICMP omzetting was nog mogelijk.
(zie aanvulling)
TCP omzetting was te complex om dat stateless te kunnen doen.
TCPv4 en TCPv6 zijn onderling zeer verschillend.
Dus is ook Statefull omzetting nodig:
Verwijzingen naar meer:
RFC Stateful:
https://www.rfc-editor.org/rfc/rfc6146
Aanvulling: Er wordt gerefereerd aan patches voor de Linux Kernel, maar er zijn opties voor configuratie hiervan in de Linux Kernel. Ik heb er een referentie kunnen vinden:
/usr/src/linux/include/uapi/linux/bpf.h- * long bpf_skb_change_proto(struct sk_buff *skb, __be16 proto, u64 flags)
/usr/src/linux/include/uapi/linux/bpf.h- * Description
/usr/src/linux/include/uapi/linux/bpf.h- * Change the protocol of the *skb* to *proto*. Currently
/usr/src/linux/include/uapi/linux/bpf.h- * supported are transition from IPv4 to IPv6, and from IPv6 to
/usr/src/linux/include/uapi/linux/bpf.h- * IPv4. The helper takes care of the groundwork for the
/usr/src/linux/include/uapi/linux/bpf.h- * transition, including resizing the socket buffer. The eBPF
/usr/src/linux/include/uapi/linux/bpf.h- * program is expected to fill the new headers, if any, via
/usr/src/linux/include/uapi/linux/bpf.h- * **skb_store_bytes**\ () and to recompute the checksums with
/usr/src/linux/include/uapi/linux/bpf.h- * **bpf_l3_csum_replace**\ () and **bpf_l4_csum_replace**\
/usr/src/linux/include/uapi/linux/bpf.h: * (). The main case for this helper is to perform NAT64
/usr/src/linux/include/uapi/linux/bpf.h- * operations out of an eBPF program.
/usr/src/linux/include/uapi/linux/bpf.h- *
/usr/src/linux/include/uapi/linux/bpf.h- * Internally, the GSO type is marked as dodgy so that headers are
/usr/src/linux/include/uapi/linux/bpf.h- * checked and segments are recalculated by the GSO/GRO engine.
/usr/src/linux/include/uapi/linux/bpf.h- * The size for GSO target is adapted as well.
/usr/src/linux/include/uapi/linux/bpf.h- *
/usr/src/linux/include/uapi/linux/bpf.h- * All values for *flags* are reserved for future usage, and must
/usr/src/linux/include/uapi/linux/bpf.h- * be left at zero.
/usr/src/linux/include/uapi/linux/bpf.h- *
/usr/src/linux/include/uapi/linux/bpf.h- * A call to this helper is susceptible to change the underlying
/usr/src/linux/include/uapi/linux/bpf.h- * packet buffer. Therefore, at load time, all checks on pointers
/usr/src/linux/include/uapi/linux/bpf.h- * previously done by the verifier are invalidated and must be
/usr/src/linux/include/uapi/linux/bpf.h- * performed again, if the helper is used in combination with
/usr/src/linux/include/uapi/linux/bpf.h- * direct packet access.
Andere bronnen melden dat in kernel support er niet meer is. Er wordt verwezen naar TAYGA (IVI) en Jool (SIIT):
https://wiki.archlinux.org/title/IPv6#NAT64
http://www.litech.org/tayga/
Dan de vereiste DNS64 ⊠het kan werkenâŠ, alleen DNSSEC gooit wat roet in 't eten.
AANVULLING:
na bijlezen van RFCâs⊠idd TCP is gelijk. Veel eerder was er sprake van dat TCP voor IPv6 andere opties en defaults zou hebben die (mogelijk) niet compatible waren. ⊠Voor zover ik nu kan beoordelen is dat allemaal beperkt tot de IPv6 headers.
Wel zal omzetting tot performance problemen leiden (fragmentatie) etc.
1 like
Sorry als ik misschien wat te direct ben, maar dit klopt niet, TCP is op IPv4 en IPv6 hetzelfde. De RFC waar je naar verwijst omschrijft oa. een translatie van IPv4 naar IPv6 en de TCP connection tracking die daarvoor nodig is. Om onderscheid te maken tussen packets vanuit de IPv4 kant en de IPv6 kant van de verbinding wordt er aan TCP termen in combinatie met v4 en v6, maar de structuur van een TCP packet veranderd niet door deze translatie.
1 like
Nou is het zo dat
Maar als ik een werkwijze zou vinden, waarbij dat reserveren niet meer hoeft,
dan help ik daar * Freedom, * IPv6, en wellicht ook * mezelf mee.
Als de websites, die ik dan niet kan bereiken, niet essentieel zijn, ⊠âŠ
dat is dan maar zo. (vergelijk het met weigeren van cookies)
Ik zit te puzzelen over een (eigen) IPv6-ONLY-testperiode. Zodra ik daaraan begin, maak ik hier een apart item over met alle ervaringen ( en tips ? )
Sowieso kunnen alle activiteiten op dit vlak bijdragen! Een eerste stap is wellicht een IPv6-only netwerk achter een tweede router of een IPv6-only virtuele machine.
Er zijn browser add-ons die kunnen tonen of een site via IPv6 of IPv4 wordt geladen. Daarmee kan je al een indruk krijgen.
Veel succes! Ik ben erg benieuwd. Als het heel technisch wordt, is het misschien een idee om ook de OpenWRT of misschien de Freetz-NG forums te gebruiken. Afhankelijk van of je OpenWRT of een Fritzbox met AVM firmware inzet.
ik wil eerst beginnen met een FritzBox, die de gewone AVM-FritzOS draait,
zodat ieder (die dat wil) het na kan bootsen.
DaarnĂĄ een OpenWRT-test, lijkt me leuk; maar daar heb ik nu nog geen ervaring mee.
(en ik haal graag maar Ă©Ă©n probleem tegelijk op mân nek)
VRAAG-1:
meestal âluistertâ de FritzBox naar zowel http://Fritz.Box of http://192.168.178.1
Wat is het (standaard) IPv6 - adres van een FritzBox ?!?
VRAAG-2:
een tweede Fritz in het eigen netwerk krijgt vaak âvanzelfâ 192.168.188.1 uitgedeeld; hoe zit dĂ t met IPv6 bij de tweede FritZBox ?
Kan ik zogauw niet vinden, maar misschien zoek ik niet goed genoeg.
Helaas is de wereld nog niet geschikt voor âIPv6 onlyâ. Het RIPE NCC heeft, als diverse andere netwerk organisaties, bij diverse meetings âv6-onlyâ netwerken gedraaid om ervaring op te doen en je kunt de resultaten eens nalezen. Grote dingen werken wel, maar er zijn helaas ook spelers die, al dan niet bewust, de boot missen en bij diverse apparaten gaan er dingen kapot op een IPv6 netwerk.
We moeten wel toe naar een wereld waarin je met een âIPv6 onlyâ netwerk wel alles kan, en daarvoor zullen die spelers om moeten. Ik denk aan leveranciers van gegevens en content (websites enzo) maar ook aan het aansluiten van gebruikers.
Diverse spelers (o.a. google, Microsoft, Netflix) zijn âomâ en als ik thuiswerk (mijn werkgever gebruikt de nodige Microsoft âcloudâ spullen) dan zie ik dat er behoorlijk wat verkeer over IPv6 gaat. En daar merk je helemaal niks van en zo hoort het ook.
Helaas zijn er ook spelers die niet meedoen, bijvoorbeeld marktplaats. Voor overheidsinstanties geldt tegenwoordig âpas toe of leg uitâ en wellicht dat ieder eens zijn gemeente kan testen en bij een gebrek, vragen.
En bij de aansluitingen wisselt het ook. Voor thuisaansluitingen doet Freedom netjes IPv6. Bij andere providers wisselt het nog wel eens. En bij de drie mobiele operators (KPN, Vodafone, T-mobile) heeft alleen KPN zân zaakjes op orde (ik zou het niet erg vinden om hierop gecorrigeerd te worden).
Met OpenWRT is het maken van een extra âIPv6-onlyâ netwerk eenvoudig.
Er is nog een hoop te doen!