Hi, ik vraag me af of het niet nuttig zou zijn een basis FAQ te starten voor gebruikers die wel gewend zijn IPv4 te gebruiken, maar nog niet echt in aanraking zijn gekomen met IPv6. Waarschijnlijk zijn er best wat nieuwe gebruikers die overgestapt zijn van een andere provider, en nu bij Freedom ook gebruik kunnen gaan maken van IPv6. Er wordt al heel lang over gesproken dat dit gestimuleerd wordt, maar een soort van eenvoudige ‘hoe gebruik je IPv6 bij Freedom’ handleiding, met b.v. uitleg over de IPv6 instellingen van de Fritzbox en hoe je een Windows/Mac/Linux machine het best kunt instellen, mis ik…
Ik denk dat er aardig wat technisch geïnteresseerden, maar niet volledig in de protocollen bedreven gebruikers dankbaar gebruik van zouden maken.
Laat ik dan maar hier starten met wat ik tegenkwam.
Ik maak gebruik van een Fritzbox 7590 (eigendom)
Als DNS heb ik het volgende ingevuld: Bij IPV4
1.1.1.1 en 9.9.9.9 Bij IPV6
2606:4700:4700::1111 en 2620:fe::fe
Alle vinkjes bij DNS over TLS zijn aangevinkt.
Bij resolutienamen van de DNS-servers heb ik staan:
Ik heb thuis een proxmox server draaien met daarop wat FreeBSD-servers.
Deze servers heb ik een IPV4 adres gegeven in de 10.10.10.0/24 range. Bijv. 10.10.10.10.
Als IP6 adres heb ik mijn prefix gegegeven gevolgd door het ip4-adres (in hex),
dus: 2a10:XXXX:YYYY:ZZZZ:a:a:a:a/64.
De gateway is dan 2a10:XXXX:YYYY:ZZZZ:: (Dit laatste leerde ik van een xs4all beheerder)
In grote trekken is IPv6 hetzelfde als IPv4 alleen de adres reeksen in fors uitgebreid. Naast aanpassing van de IP header op adres lengte zijn de opties meer flexibel toegevoegd. Maar dat is niet relevant voor het concept/
IP v6 adressen zijn ook anders georganiseerd. Waarbij allerlei functies die nodig zijn nu vooraf ingebouwd zijn in plaats van als vergeetmenietjes achteraf zijn gemaakt (Multicast bv.). en NAT kan eindelijk op de plek waar het hoort in het vuilnisvat.
IPv6 lost het adres probleem een stuk serieuzer op met 128 adres bitjes beschikbaar, terwijl met NAT zijn er hoogstens een 6-8 tal toevoegt. Door de verdeling over minimaal 64 bitjes voor een aansluiting en 64 achter de aansluiting geen NAT meer.
Kortom weer naar internet zoals het bedoeld was.
De gateway is afhankelijk van hoe je de adressen verderop gebruikt. Maar kan je prefix zijn. (Die is bij Freedo overigens 48 bits. dus in je voorbeeld 2a10:XXXX:YYYY:: (De ZZZZ kun je geheel zelf kiezen).
IPv4 heeft een aantal Private-Adres-bereiken,
dat wil zeggen dat je (los van de verdere configuratie) nóóit het verdere internet op komt.
Dit is bijvoorbeeld voor testen handig.
RFC1918 regelt, dat de volgende adresreeksen privé zijn:
* 10.0.0.0/8 (alle apparaten met 10.aaa.bbb.ccc zijn voor jou zichtbaar te maken)
* 172.16.0.0/12 (dus alleen apparaten met hetzelfde 172.zzz.yyy.xxx zijn voor jou te zien)
* 192.168.0.0/16 (dus alleen apparaten met hetzelfde 192.168.yyy.xxx zijn voor jou te zien)
Maar hierover lees ik in IPv6-handleidingen niets meer …
Bestaan er op IPv6 geen Private-adressen / Private-adresreeksen meer ?!?
Wie kan mij (en aan anderen) dat handig uitleggen ?!?
Site local adressen zijn inderdaad de prive adres bereiken… daar heb je er dus 2^118 van beschikbaar als je bang bent om er te kort te komen.
Overigens de “prive” adres bereiken zijn in het leven geroepen om NAT mogelijk te maken. Het hele concept van NAT is ziek. En in principe niet op IPv6 van toepassing.
Voor IPv6 is het helemaal niet noodzakelijk, relevant etc.
IPv6 heeft ook het voorbeeld adres bereik waarmee je ook niet het internet op kan. (is bedoeld voor documentatie …, net als 192.0.2.0/24 in IPv4 overigens).
Overigens bestaat er wel NPT in IPv6 waarbij de prefix evt. vertaald wordt zodat je de achterste 96 bits uit een localreeks van een valide public range kan voorzien in een firewall, op die manier kun je evt. meerdere publieke endpoints bij meerdere ISP’s op een je eigen netwerk van de juiste prefix voorzien voor routering via de juiste poort. Let wel er veranderd niets in een portnummer of de achterste (128 - prefix lengte) bits van een adres.
Overigens regelt RFC 1918 niet dat die Prive zijn, maar dat die niet op het Internet gerouteerd mogen worden… Je zult er dus nooit antwoord op ontvangen, maar je ziet ze soms als afzender adres in de meeste gevallen vermoedelijk als configuratie fout (geen correcte NAT ingesteld). mar het kan een DOS poging zijn.
Site-local is ‘deprecated’. De redenen daarvoor staan opgesomd in RFC3879 [1]. Let op dat FEC0::/10 in moderne IPv6 implementaties geen speciale betekenis meer heeft. Het komt er op neer dat het in principe gewoon Global Unicast kan zijn [2].
De vervanging voor site-local heet:… ik verzint het niet… Unique Local IPv6 Unicast Addresses of te wel ULA. Dat is: FC00::/7. En dat staat allemaal weer in RFC4193 [3].
Het opheffen van site-local ging overigens zekers niet zonder slag-of-stoot. Voor degene die geïnteresseerd zijn in een kleurijk stukje internet-geschiedenis; lees de reactie van 't IESG op het beroep van Tony Hain en de reacties daar weer op [4].
Wat betreft 172.16.0.0/12 wil ik even een aanvullende opmerking maken mbt het tweede octet (zzz).
172.16.0.0/12 loopt van: 172.16.0.0 tot en met: 172.31.255.255. Daar buiten zijn het gewoon routeerbare unicast adressen. Niet in de laatste plaats: www.google.com (172.217.168.196).
We hebben namelijk wel eens een ontevreden klant die niet bij www.google.com kan; omdat die 172.0.0.0/8 naar zichzelf routeert.
ik meen te herinneren dat in de jaren '90 een Windows-versie de private IPv4-adressen ook gewoon doorstuurde naar het internet; wat hele vreemde situaties op leverde. Een patch (jawel) herstelde dit weer.
Helaas , ook apart definieren van poorten werkt niet , alleen ipv4 adres is van buiten bereikbaar via ssh , ipv6 niet. In mijn herinnering werkte dit bij xs4all toch probleemloos. Exposed host aanvinken en ik kon van buiten met ipv6 bij mijn machine. Lijkt wel ergens geblokkeerd te wordenbij freedominter.net. Ipv6 naar buiten geen probleem, ipv4 naar binnen en buiten geen probleem, ipv6 naar binnen blocked, en dat is niet mijn firewall.
Ik ga er van uit dat je een FritzBox hebt. Wat je moet doen is:
Installeer de allerlaatste FritzOS.
Zet het modem terug naar de fabrieksinstellingen. Ik snap dat je dan alles weer opnieuw moet doen, maar het werkt echt! (tip van helpdesk xs4all en freedom)
Ja, zal ik doen, het lijkt er toch echt op dat mijn 7581 kaduk is in de firewall regionen.
Reset naar f.i. heeft niet geholpen. Raar ding is ook dat ik bij portsharing krijg dat mijn internet ipv6 adres
a:b:c:d:e:f:1 is, terwijl een remote check zegt dat het a:b:c:d:e:f:2 is, welk laatste adres ook overeenkomt met feitelijike
interface adres wat ik zie. Maar mijn feitelijke adres is “Administratively prohibited” wanneer ik ping6 uitprobeer vanaf een remote adres en het ipv6 adres wat ik volgens de fritzbox (bij port sharing wordt het vermeld) heb voor remote servers is “Unreachable”.
Er is iets echt niet lekker met die fritzboxes.
Ik heb de firewall op de machine zelf uitgezet, dus dat kan het niet zijn, blijft over het modem. Traceroute stopt bij het
freedom ipv6 adres van het modem, dus ik vermoed dat het modem toch echt niet ok is, rare is dat ik dus wel het ipv6 adres van het modem kan pingen. Rotte firmware. Ipv6 is trouwens uberhaupt slecht geregeld bij dsl want het werkt alleen bij tunneling via ipv4, dus je hebt niet eens een echte native ipv6 verbinding, lekker voor je mtu ook , Waar blijft die glasvezel aansluiting.
Blijkbaar probleem ogelost. Fritzbox zag mijn link local adres als ipv6 adres en gebruikte als mijn internetadres de laatse 4 hexblokken van mijn link-local adres, wat de fritzbox voorinvult bij ipv6-interface-id item in het permit_access menu, en de eerste 3 hex blokken van mijn link-global ipv6 adres met als 4 hexblok een 1 , als het adres om te openen in de firewall. Ik heb dat ipv6-interface-id in dat menu vervolgens veranderd in de laatste 4 hex blokken van mijn link-global toegewezen adres en na een keer herstarten van het modem kreeg ik toegang van buiten naar binnen op ipv6. Dat menu item ipv6-interface-id is trouwens raar want het ziet er zo uit :
::a.b.c.d , waarbij a,b,c en d aan te passen zijn , echter die :: is fout , dat is in het echt :1:
Dus als je ipv6 rang 9.8.7::/48 is, dan is het adres dat door de fritzbox geopend wordt voor toegang , niet 9.8.7::a.b.c.d, zoals
in de ipv6-interface-id in het menu staat , maar 9.8.7:1:a.b.c.d (alle . is : ). Waarom het fritzbox modem telkens de laatste 4 link-local hex-blokken gebruikte i.p.v. het link-global toegewezen ipv6 adres is onduidelijk, maar dat kan ermee te maken hebben dat ik in NetworkManager
de ipv6 privacy extensions had enabled , maar hoe dat dan zou moeten werken is mij niet echt duidelijk. Feit is dat na het uitzetten van de ipv6 privacy extensions op mijn machine en het aanpassen van het ipv6-interface-id in de fritzbox, het nu werkt. Aparte port definieties ook niet nodig, exposed host aanvinken werkt voor zowel ipv4 als ipv6 correct. Die krakkemikkige ipv6 autodetect in de fritzbox werkt niet goed en die privacy extensions hadden er ook niks mee te maken, het is puur het fritzbox modem dat verkeerde gegevens vooraf invult bij een onduidelijk menu item.
