IPv4 of IPv6 tijdens gebruik internet

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!

4 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

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 :frowning: 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!

Mijn verwachting is dat de AVM software op dit moment geen rekening houdt met pioniers die enkel IPv6 willen gebruiken, dus daarmee maak je het jezelf niet makkelijker :slight_smile:

Door het per se op een standaard Fritzbox te willen doen, zal je juist meerdere problemen moeten aanvliegen. Zoals GeertJan ook aangeeft, is het makkelijker om het eerst met OpenWRT te proberen.

Nee, dit is niet echt hoe het werkt. Mijn advies is om je in te lezen in de theorie rondom de verschillende OSI-lagen en de verschillende protocollen die bij het internet een rol spelen. Zowel IPv4 als IPv6, maar ook TCP, UDP, DNS, etc. Op zich staat er op Wikipedia veel informatie, maar er zijn ook goede boeken over. We gebruikten destijds Kurose & Ross, Computer Networking: A Top-Down Approach op de universiteit.
Als je hier echt aan begint, is theoretisch begrip van hoe alles in elkaar hangt belangrijk om de problemen die je tegen gaat komen aan te kunnen vliegen.

1 like

Ik zou er geen probleem mee hebben om IPv4 middels CGNAT aangeboden te krijgen, inmiddels is IPv6 voor mijn toepassingen, waar een publiek uniek ip adres voor nodig is, voldoende ingeburgerd.

Eigenlijk alleen voor legacy website hosters heb ik nog wel eens IPv4 nodig, maar die verbindingen functioneren ook prima via CGNAT.

Als het te implementeren is zonder dat dat grote kosten met zich meebrengt, zou Freedom voor, naar ik denk, heel wat klanten die voldoende kennis bezitten een opt-in voor IPv4 via CGNAT kunnen aanbieden. Met een opt-in is het ook een zeer bewuste keuze voorde klant om dan af te zien van een uniek publiek IPv4 adres.

Het blijft een suggestie uiteraard, maar Freedom zou er mogelijk een voordeel aan kunnen hebben.

De Fritzbox luistert ook naar het FD00: adres.
IPv6 Adressen moet je wel tussen vierkante haakjes zetten in de browser […]

Als je IPv4 in de soep is gelopen, is dit ook een nood adres.
Helaas luisteren mijn nieuwe repeaters er niet meer naar in een netwerk.
Alleen de 1750E reageert er op.
Maar wel naar het unicast adres.

192.168.178.1 — is IP en is GEEN IPv6… dus niet mogelijk in IPv6-ONLY …
IPv6 werkt niet met “STANDAARD” adressen…, je hangt aan een extern netwerk, daar is een PREFIX aan je toegewezen.
(Static, DHCPv6-PD, of mogelijk ook DHCPv6…)
Je kan vervolgens een “subnet” adres van de prefix aan je interne interfaces hangen…

Of de fritzbox z’n LAN kant ook aan Fritx.Box naam in de DNS service hangt tja dat weet ik niet, ik heb er geen.

IPv6 genereert ZELF link local adressen gebaseerd op het MAC adres. (fe80:: )
Dat is min of meer het alternatief voor ARP … in IPv4, dit is vergelijkbaar met APIPA (169.254.0.0/16 adres reeksen).

Kies hoe dan ook een Firewall waar je de nodige controle over het OS hebt… OpenWRT is er een, OPNSense, een andere.
Dit zijn distro’s die er compleet voor ingericht zijn om van een standaard PC… een Firewall te maken.
Met ondersteuning op fora, newsgroups etc.