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
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.
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.
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.
@MartijnZ:
YMMV⊠Mijn telecom provider doet nog geen IPv6⊠(geen verrrassingâŠ, ver verwondering waarom ze onder een steen blijven liggenâŠ
maar ja Tweak zei 5 jaar geleden dat onderstening voor IPv6 nergens voor nodig was, en dat er genoeg adressen waren en dat ze geen enkel plan hadden om IPv6 te gaan doen).
De telecom provider doet CGNAT⊠dus voor een verbinding tussen mijn telefoon en mijn thuisnetwerk voor bediening etc. moet ik voorlopig een NIET CGNAT IPv4 hebben⊠En door gebreken elders heb ik ook nog een paar andere IPv4 adressen nodig.
Wat mij betreft gaat de wereld ZSM om naar IPv6.
Met Exit voor alle NAT.
$ dig +noall +answer hotmail-com.olc.protection.outlook.com a
hotmail-com.olc.protection.outlook.com. 25 IN A 104.47.30.97
hotmail-com.olc.protection.outlook.com. 25 IN A 104.47.51.225
Wat ik te zot voor woorden vind. Maar goed er werkt wel meer niet zoals het hoort bij henâŠ
Ik vergelijk de security van een PC met de security van een huis. De security van een huis hangt af van de sloten op je deur, dievenklauwen in ramen en deuren. Je adres heeft daar m.i. geen invloed op. Security is dus niet afhankelijk van ipv4 of ipv6.
Zoals eerder gezegd, veel sites blijven ook bewust op ipv4
Je moet het filteren ook opnieuw doen.
En niet iedere provider geeft een /48 uit.
Dan is het al snel, ipv4 werkt toch ookâŠWe doen niet mee met ipv6
Bij sommige lijkt het er op dat de anti-(d)dos provider (Cloudfront, Imperva) IPv4 only is. Ik dacht van een eental toch zeker te weten dat ze over IPv6 bereikbaar warenâŠ
Het effect is hetzelfde uiteraard: geen IPv6.
Klopt voor IPv6 only is het gebruikelijk om een /56 te krijgen⊠Evengoed nog bruikbaar voor 256 VLAN subnet segmenten.
Prefixen <=/64 (64âŠ128) zijn ISPâs die het niet begrepen hebben hoe het werkt
Prefixen tussen /56 en /63 zijn nog zuiniger dan Zeeuwen. Zelfs Scroodge voor kerst is dan kwistig.
Prefix /48 is een oude afspraak waar jaren later de aanpassing op gemaakt is naar /56 omdat 64K subnet segmenten meestal niet zinnig is.
Dat is een kwestie van een Vinkje zetten, nadat ze onder hun steen uit kruipenâŠ
Onderstaand artikel is uit 2019:
Ik ben op dit moment verbonden via een ISP die enkel een IPv6 verbinding oplevert. IPv4 verkeer wordt niet ondersteund op de directe uplink. Het is interessant om te zien hoe dit in de praktijk werkt. Ik was zelf in het begin ook in de war en las online ook wat verwarring over de verwachtingen bij deze ISP.
De uplink is een 3G/4G (UMTS/LTE) verbinding waarbij de router de instellingen krijgt aangeleverd. Ik weet niet precies hoe dat opgezet wordt. De wan interface op de router heeft twee IPv6 adressen, een publiek adres en een link-local adres.
IPv6 verkeer wordt gerouteerd als gebruikelijk. Bij hosts die via DNS normaal enkel een A record hebben en geen AAAA record, wordt er een extra AAAA record bijgevoegd wat begint met 64:ff9b:: en eindigt met dezelfde bytes als het IPv4 adres uit het A record. Als er dus een A record zou bestaan dat wijst naar 198.51.100.123en er is geen AAAA record, dan wordt er vanuit de DNS server een AAAA record toegevoegd dat wijst naar 64:ff9b::c633:647b. Voor zover ik kan zien, gebeurt dit vanuit de DNS server van de ISP.
Als ik iets probeer met een extern IPv4 adres wat ik ergens hard heb ingevuld, dan werkt het gewoon helemaal niet. Er is geen simpelweg geen route waarmee dit verkeer afgehandeld kan worden. Voor een IPv4 host zonder hostname, zal je met de hand een 64:ff9b::....:.... adres moeten bouwen en dat gebruiken. Ergens bij de ISP vindt de omzetting plaats waardoor IPv4 hosts wel bereikbaar zijn. Naast gehardcode IPv4 adressen is ook de DNS cache relevant. Als je merkt dat sommige hosts niet bereikbaar zijn, is het goed te controleren of de lokale cache niet een oude entry heeft met enkel een A record.
De router die ik nu gebruik is vrij simpel en niet aan te bevelen. Het gaat om een Tecno TR118. Die wordt niet in West-Europa verkocht, maar is wel populair in andere delen van de wereld. Er zit een handig lek in de webinterface waarmee je shelltoegang kan krijgen. Het is eigenlijk een ZTE apparaat. Er zit geen firewall in, dus al het verkeer wordt beide kanten op gewoon doorgelaten. De router webinterface is wel afgeschermd van buiten. De betere routers zullen dit ongetwijfeld nooit zo doen, maar deze router en vergelijkbare ZTE MIFI routers zijn erg populair, dus wel handig om te weten dat alles wat op je systeem draait in principe wel vanuit de hele wereld benaderbaar is.
Ik ben nu aan het kijken naar een Teltonika router. Teltonika gebruikt (net als Turris) OpenWRT en biedt veel verschillende mobiele routers aan. (Als iemand nog een tip heeft hoor ik het graag.)
Misschien geeft deze post wat ideeën om ook met een Freedom verbinding te experimenteren. De eerste stap zou zijn om te zorgen dat 64:ff9b::....:.... adressen worden afgehandeld. Daarna zou een tweede stap zijn om die extra AAAA records in te voegen vanuit een lokale DNS server. Vanaf dat moment heb je een netwerk waarin een IPv6-only systeem enigszins volwaardig zou kunnen functioneren.
DNS64 samen met NAT64 is al een aantal keren overwogen hier.
Het vergt hoe dan ook CG-NAT-apparatuur en dat is een forse investering. Per klant heeft een gehuurd IPv4-adres voor ons kosten- en cashflow voordelen. Bovendien geven âechteâ IPv4-adressen altijd een betere klantervaring.
We hebben momenteel ook niet de capaciteit om op kleine schaal te experimenteren. Maar velen hebben er al mee te maken, want vooral mobiele providers (oa KPN) passen dit op grote schaal al toe.
De echte kostenbesparing krijg je dus alleen als je IPv4 helemaal laat vallen en enkel IPv6 connectiviteit aanbiedt.
Nou zou de vervolgvraag zijn wat de verhoudingen zijn en hoeveel een budget IPv6-only internet abonnement nu goedkoper zou zijn dan een abonnement met beiden
Zou Tor niet een mogelijkheid kunnen zijn om alsnog aan een IPv4-mogelijkheden te komen? Of een zoân VPN-proxy dienst? (Als je normaal toch altijd alles via een of andere Blabla VPN laat lopen, zou een IPv6-only verbinding vanuit Freedom helemaal zo gek niet zijn. Zolang die Blabla VPN maar via IPv6 benaderbaar is.)
Tegelijk denk ik dat het wel goed is om te experimenteren met een IPv6-only LAN (eventueel met lokaal NAT64). En wat precies de gevolgen zijn als je een IPv6-only WAN verbinding probeert op te zetten, zonder enige IPv4-mogelijkheden. Zou Freedom daar wel capaciteit voor hebben?
Per gebruiker zal IPv6-only niet heel veel in kosten schelen. Mogelijk zelfs minder dan de extra kosten van support en administratie.
Het punt is meer dat we hele blokken IPv4-adressen moeten huren. Immers een prefix langer dan een /24 (dus 256 adressen of minder) is niet te routeren. We huren meestal een /22 (1024) adressen tegelijk. Het totaal telt flink op. Dat is het punt,
En het steekt dat we moeten betalen voor nummers die ooit (bijna) gratis waren. Maar tegenwoordig is er een markt voor en daarmee hebben we gewoon te maken.
Alle opties waarbij IPv4-adressen worden gedeeld, vergen hoe dan ook een âmiddle boxâ die per âconversatieâ state moet bijhouden. Op schaal is dat hoe dan ook moeilijk en dus duur. Er is een break-even point waarna CG-NAT (of de een of andere proxyserver) goedkoper wordt dan de benodigde hoeveelheid adressen.
In theorie is het - denk ik - mogelijk om met een IPv6-only TOR-entry-node te werken en daarbij wel IPv4-eindbestemmingen te bereiken. Maar daarvoor moet de TOR-client wel een TOR-circuit opbouwen die dat mogelijk maakt. Waarbij de selectie van de middelste- en exit-nodes een cruciale rol speelt in het overbruggen van de verschillende IP-families. Ik weet niet hoe dat in de praktijk gaat werken.
Ik heb nu een IPv6-only verbinding opgezet met behulp van een extra OpenWRT router om mee te testen. Ik heb (nog) niets ingericht voor IPv4 vertaling. De WAN poort van de testrouter hangt aan mijn gebruikelijke LAN.
De hoofdrouter die verbinding heeft met Freedom draait TurrisOS 6.5.2 (OpenWRT gebaseerd) en de IPv6-only testrouter draait OpenWRT 23.05.2.
Standaard richt OpenWRT zowel een wan als een wan6 interface in. Om te beginnen heb ik die wan interface verwijderd. Met alleen de wan6 interface ingesteld als DHCPv6 client worden er direct IPv6 adressen/prefixen gereserveerd op de WAN interface, maar die werden niet direct op de lan interface overgenomen. Ik moest bij lan interface naar de âAdvanced Settingsâ tab en daar âIPv6 assignment lengthâ aanpassen. Die stond op âDisabledâ en heb ik op â64â gezet. Toen kreeg mijn lan interface ook een IPv6 adres en begon de router IPv6 adressen uit te delen aan clients erachter.
Ik heb op de lan interface ook een IPv4-adres ingevuld. Via DHCP worden ook IPv4 adressen uitgedeeld en een IPv4 default route, maar omdat er geen upstream IPv4 is, geeft dat nu time-outs. Ik wil eerst kijken wat er precies gebeurt als ik mijd dat de DHCP server een default route uitgeeft voor IPv4.
Daarna wil ik kijken hoever ik kom als ik bijvoorbeeld Tor probeer te gebruiken of een VPN tunnel met een IPv4-uplink
Inmiddels heb ik enige ervaring opgedaan. Als je echt enkel IPv6 hebt, werken eigenlijk veel dingen gewoon goed. Bij sociale media (Mastodon, Facebook, LinkedIn), merk je praktisch niets. Daar is dat allemaal prima in orde.
Nieuws sites gaat ook prima, de NOS, Volkskrant, Trouw kan je gewoon bezoeken. Een site als de NRC die dan niet werkt, lijkt een uitzondering.
Zoeken is wel lastiger. DuckDuckGo en Startpage doen het allebei niet. Google en Brave wel.
Een patroon wat ik wel vaker zag, soms werkt example.com wel, maar niet www.example.com of omgekeerd. Het is altijd goed om zowel met als zonder www. te proberen.
Tor werkte niet toen ik het probeerde. Waarschijnlijk zijn er te weinig IPv6 nodes.
Ik heb een aantal dagen via nat64.net zitten surfen en dat ging prima. Als je de informatie op die site verder leest, krijg je de indruk dat een IPv6-only ISP eigenlijk best haalbaar is.
