Michiel van der Vlist (2:280/5555) �஢� ����ਬ��� � ����, ����饩
⮫쪮 IPv6 ����.

� ���� � ��諮� FidoNews �� 㯮��� �஥�� ����� ������� "IPv6 only"
� ����ᠫ, �� ���஢�� ��, � �㦭� ����� ���� �� ᫥���饩 ������". ������� ��襫 ����� � ���஢����.

Michiel �訫 �� ��ந�� 楫�� ��� IPv6 only, � �ᯮ�짮���� ��������� ����ன��. ��� �⮣� �� ��� �����, �� ���஬ �⪫�稫 IPv4 �
����ன��� �⥢��� ������. ��᫥ �⮣� �� �����㦨�, �� DNS-�ࢥ��
��� �஢����� �� ࠡ���� �� v6. ��� ���஢���� �裡 � IPv4 Michiel �ᯮ�짮��� �㡫��� �ࢨ� NAT64 �� Kasper Dupont. ��᫥ ����ன�� DNS-�ࢥ஢ Michiel ᬮ� ����������� � ����� IPv6 � ����設��� 㧫��
IPv4 � �������. �� �⮬ 㧫� IPv6 ����������� ��� ���筮, � 㧫�
⮫쪮 IPv4 ����� ����������� �१ �� NAT64. Michiel ᤥ��� �뢮�,
�� ����� 㧫� Fidonet � �।� ⮫쪮 � IPv6 �� �।�⠢��� �஡����.

����� Michiel �।����� �襭�� ��� ��, �� ��� ����� DNS64 �
������� ����������� � ��� NAT64.

���ᨡ� �� ��ॢ�� ������ ��㣫�����.

=============================================================================
* Area : FIDONEWS
* From : FidoNews Robot, 2:2/2 (06 ������ 2025 00:07)
* Subj : FidoNews 42:01 [02/08]: General Articles ============================================================================= =================================================================
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) =============================================================================


--- GoldED+/W64-MSVC 1.1.5-b20240209
* Origin: Esquire Station (2:6035/3.1)