MSGID: 2:2/2.0 1048873c   
   REPLY: 2:2/2.0 1048873a   
   CHRS: CP850 2   
   =================================================================   
                           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)   
   SEEN-BY: 2/2 10/0 1 103/705 105/81 124/5016 128/187 154/30 203/0 2   
   SEEN-BY: 203/124 412 218/0 1 700 221/0 226/30 227/114 229/110 114   
   SEEN-BY: 229/426 428 470 700 705 230/0 240/1120 5832 280/464 5003   
   SEEN-BY: 280/5555 291/111 292/8125 301/1 320/219 341/66 234 423/81   
   SEEN-BY: 423/120 467/888 712/848 902/26 5020/400   
   PATH: 2/2 203/0 280/464 103/705 218/700 229/426