Subj : FidoNews 42:01 [02/08]: General Articles To : All From : FidoNews Robot Date : Mon Jan 06 2025 00:07:16 ================================================================= GENERAL ARTICLES ================================================================= IPv6 only experiment By Michiel van der Vlist, 2:280/5555 In my last week's (or last year's if you want) article *1) I mentioned Alex Haydock's IPv6 only project. *2) This inspired me to have a look at how Fidonet systems would behave in such an environment. My conclu- sion was that the "problem" of literal IPv4 addresses in the nodelist can be worked around by using binkp.net. At the end of that part I wrote: "Did I test this? Yes of course! See next week's article..." So here it is: a report of what I tested and how. I choose to not build an entire IPv6 only environment like Alex Haydock did but to use the minumum required for the test I had in mind. Just a single system with IPv6 only access: The laptop running my point system. That laptop (a Dell Latitude D620, running WIN7) has WiFi on board and an RJ45 connector for UTP cable. It has a manual switch to enable/disble the WiFi. So the first step was to switch off the WiFi and connect the laptop to the LAN with a cable. This allowed me to easely switch between the original setup and the IPv6 only setup. Just plug/unplug the cable and unset/set the WiFi switch. The second step was to disable IPv4 in the LAN cable interface. After doing that I found out I no longer had access to the Internet. It turned out the DNS servers of my provider (Caiway Fiber) do not work well in an IPv6 only environment. Malus point for Caiway! The DNS servers of my other provider (Ziggo) do not have that problem. No big deal because for the test I had in mind, I have to use other DNS servers anyway. I need DNS64 and NAT64 to be able to access IPv4 only systems. Contrary to Alex Haydock I do not have a provider that offers these services so I have to look elsewhere. Instead of building a NAT64 gateway myself just for this experiment, I decided to make use of a third party. The free service of Kasper Dupont was not hard to find. *3) All I had to do was to configure the wired LAN interface to use he following DNS servers: 2a00:1098:2c::1 2a01:4f8:c2c:123f::1 2a01:4f9:c010:3f02::1 These are DNS64 servers. For accessing IPv4 only systems they refer to his NAT64 gateway. That is all that is needed to create an IPv6 only environment with DNS64/NAT64 support. For details on the working of DNS64/NAT64: Google is your friend! *4) After configuring the above DNS servers binkd could connect to IPv6 nodes and most IPv4 nodes in the nodelist. IPv6 nodes are connected as usual and IPv4 only nodes are connected via the NAT64 gateway. So to the other side they will appear to come from the IPv4 WAN address of the gateway. 95.216.219.126 in this case. It will back resolve to nat64.dyndns.dk. So if you have an IPv4 only binkp node and you see that in your logs with an incoming connection from 2:280/5555.1 that was me testing. For nodes listed with a literal IPv4 address a work around is still needed. DSN64/NAT64 does not work with literal IPv4 addresses. The work around - as mentioned in my previous article *1) - is to use binkp.net. After manually configuring * for the literal adresses in binkd.cfg these nodes were connected without further problems. So running a Fidonet node in an IPv6 only environment is no problem. There are a few snags though. For one, it is not possible to connect to nodes that advertise IPv6 connectivity but do not actually support it. I could not connect to 240/8010. Binkd times out and that's it. There is no fall back to IPv4 in this configuration. Of course there isn't! This is IPv6 only remember!? So if we want to prepaire for an IPv6 only Internet, we'd better get used to that. But for those who are not quite ready for that there is a work around, but it is a bit more complicated. Configure [2a00:1098:2c::5:93.236.155.101] as the literal IPv6 address for binkd to connect. Here we bypass the DNS64 and directly connect to the NAT64 gateway. 2a00:1098:2c::5: is the prefix used by the NAT64 gateway and 93.236.155.10 is the IPv4 address of the node in question. Writing the last 32 bits of an IPv6 address as an IPv4 quad is a legitimate way of writing an IPv6 address though not all applications may understand it. Apparently the WIn32 version of binkd does. Your milage may vary. This method could also be used to connect to IPv4 only nodes with a literal IPv4 address though it may not be practial. Authors of scripts that generate a configuration file for binkd from the nodelist may consider to add either method as an option. It goes without saying that incoming IPv6 is no problem in this confi- guration. It works as before. Incoming IPv4... Well, there isn't. Not in this IPv6 only configura- tion. In my, now 7+ year old DS-Lite emulation experiments *4-8), I demonstrated that running an IPv6 node without incoming IPv4 is do- able. And for those who can not or do not want to renounce incoming IPv4 yet, there is Feste-ip.net. *7) But maybe we should just forego incoming IPv4 for a while to entice the IPv4 only sysops of Fidonet to adopt IPv6. :-) As a side note: I wonder how long Kasper Dupont will continue this service. It is free and open to all without any registration or other authorisation. I feel a bit uncomfortable about that, it looks like a recipe for abuse. But he has been running it for over five years now, so it may not be a serious problem. So it feels OK for a short and simple test. Another problem with public NAT64 gateways is similar to the problem with the 6to4 tunnels that some of us are still using: services using geolocation to grant access may get confused because all traffic seems to come from the gateway, not from the originator. Not a problem for Fidonet I'd say, but for other use it may be. For those and some other reasons I would prefer a NAT64 gateway run by my provider if I ever start to use this permanently. I have two providers at the moment and neither of them provides such a service. I may make that a goal for the coming year. Or next year... References: 1) FN 41:53 Dec 2024 IPv6 in 2024 2) https://blog.infected.systems/posts/2024-12-01-no-nat-november/ 3) https://nat64.net/ 4) https://en.wikipedia.org/wiki/IPv6_transition_mechanism 5) FN 34:31 Jul 2017 DS-Lite emulation experiment v2.0 6) FN 34:37 Sep 2017 DS-Lite emulation experiment 2.0, the results 7) FN 34:33 Aug 2017 DS-Lite: a solution 8) FN 34:38 Sep 2017 DS-Lite Emulation experiment v2.1 ----------------------------------------------------------------- --- Azure/NewsPrep 3.0 * Origin: Home of the Fidonews (2:2/2.0) .