Michiel van der Vlist ��㡫������ ��������� ����⨪� �� ���
IPv6-㧫�� � �������, � ⠪�� ��᪮�쪮 ᢮�� ��᫥� �� �⮬� ������. �� �ࠢ����� � ���� ����� �᫮ ⠪�� ��� 㢥��稫���, ������� � ������⥫� ������諮�� ���� - �� ⥯��� 109.

=============================================================================
* Area : FIDONEWS
* From : FidoNews Robot, 2:2/2 (30 ������� 2024 00:15)
* Subj : FidoNews 41:53 [02/08]: General Articles ============================================================================= =================================================================
GENERAL ARTICLES =================================================================

IPv6 in 2024
By Michiel van der Vlist, 2:280/5555


Another year has passed. When we compare the statistics as published
by the end of 2022 and 2023 with those of today, we see that last
year's dip has been filled, but there isn't any overal growth any
more. The number of Fidonet IPv6 nodes keeps hoovering just over
100. At the moment of writing there are 109 nodes.


110 _| . .
_| .
100 _| .
_| .
90 _|
_| .
80 _| .
_|
70 _| .
_|
60 _|
_| .
50 _|
_|
40 _| .
_|
30 _|
_| .
20 _|
_|
10 _| .
_| .
0 _|______________________________________________________________
| | | | | | | | | | | | |
2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025


The number of nodes carrying the INO4 flag dropped from 5 to 3. So the
vast majority of Fidonet still supports full IPv4. Not really what I
expected, but that is what it is.

What also strikes me is that about a quarter of the Fidonet IPv6 nodes
still uses a tunnel. Most of them via he.net, but a few via another
tunnel broker. Apparently there are still many ISPs around that do not
support IPv6. Shame!


Outside of Fidonet IPv6 continues to grow. Slowly but steadily. Accor-
ding to Google worldwide IPv6 adoptation now hoovers around just under
50%. Almost half of those visiting Google do so via IPv6.

https://www.google.com/intl/nl/ipv6/statistics.html

Some even claim the tipping point has been reached where IPv6 is now
the norm but I would say this is premature.


Regarding my personal situation: I participated in a project building
a particulate matter sensor. The idea is to have many of these sensors
spread around to continuesly monitor and collect particulate matter
data over a long period of time: maps.sensor.community. Zoom in on
my location and click on sensor #87057 to see the partical density, temperature, air pessure and relative humidity here.

The thing is build around a an ESP8266 NodeMCU V2. It has limited
resources so the designers "forgot" about IPv6. I managed to raise the
interest of one of the developers and some changes to implement IPv6
were made. The experimental firmware version that I run now does http
via IPv6 and so data are exchanged in IPv6 with the servers of the
sensor community. The user interface is also available via IPv6. But..
the ESP8266 does not have a hardware clock and so the only source of
time are the NNTP servers on the internet. And its NNTP is IPv4 only
for now. Same for DNS: IPv4 only. So this gadget is far from being
able to function in an IPv6 only environment. Pity because it is
equipmemt like this that prolongs the need to support IPv4. What I
should do of of course instead of complaining is to delve into it and
add full IPv6 support myself. But Frankly, at my age I mis the drive
and the energy. Plus that it will only solve this particular problem
and not the problem of the hundreds or thousands of similar gadgets
where the developers choose the easy way of ignoring IPv6...

Then again: my two globalping probes (runnig on a NanoPI Neo 512m) are
doing fine with full IPv6 support: dash.globalping.io.

All the same, we are stil a long way from IPv6 only.

For some more on doing away with IPv4, here is an interesting article
by Alex Haydock about running an (almost) IPv6 only environment. The
title of the article is: No NAT November:

https://blog.infected.systems/posts/2024-12-01-no-nat-november/

For those who read the article it should be clear that the greatest
botlleneck for operating in an IPv6 only environment are applications
that use literal IPv4 addresses. Reaching IPv4 only servers adressable
by a symbolic host name from an IPv6 only environment is possible
using NAT64 en DNS64. Those can be installed on the perimeter of the
IPv6 only system or beyond. Doable without very much effort. But
literal IPv4 adresses are another kettle of fish. For that you need
CLAT and that must be installed on the system running the application.

And that brings us back to Fidonet. Is Fidonet using literal IPv4
addresses and is it possible to use CLAT on Fidonet systems? Short
answers: yes and no. Yes, Fidonet uses literal IPv4 adresses and no,
for the vast majority of Fidonet systems it is not possible to install
CLAT. For an explanation on the latter, read the above article.

So where do we find these liteal IPv4 adresses? In the nodelist! Per
FTS-5000 and FTS-5001 literal IP addresses can be used instead of
symbolic host names in the nodelist. For IPv6 this option is very
rarely used but in the IC's daily nodelist (#357 at the moment of
counting) there are 68 literal IPv4 addresses. I may have missed some
or my filter may have had some false positives but is clear that it is
more than just a few and too many too ignore.

So do we need to do something about it and if yes, what? It is obvi-
ously not a matter of great urgency. AFAIK there are no Fidonet
systems running in an IPv6 only environment. And that may not change
for a while. IPv4 will be with us for a some time, maybe quit a long
time and the pioneer spirit that once was the driving force of Fidonet
is almost gone. So we may not see Fidonet systems running in an IPv6
only environment any time soon. Maybe never. Despite that it is always
good to be prepaired. So how should we deal with the literal IPv4
addresses in the nodelist?

Option 1: Convince the sysops in question to go install IPv6. This is
no guarantee that the literal IPv6 adresses wil disappear, but
presently all dual stack systems use symbolic host names. Convincing
all sysops concerned may be difficult. If it was easy for them to
install IPv6 they would probably have done it already. Plus that to
convince them, they have to be reached first. That may be a problem in itself...

Option 2: Convince the sysops in question to use a symbolic host name
for adressing their systems. This may not be easy either. It has no
direct advantage for them and "it works" doesn't it?

Option 3: Handle it at the NC level. For NCs it would be relatively
easy to create host names for the less than handfull literal IPv4
addresses in their segments and enter them manually. Presuamably those
literal IPv4 adresses are static so it is not a great burden on the
NCs. Then again, we may run into the same problem as when trying to
convince individual sysops.

Option 4: Deal with it on the RC, ZC or IC level. For the RC and ZC
level we have the same probem as with te NCs. Some may not be all that enthousiastic. But for the IC level it may be doable. The IC runs a
program called ErrFlags and maybe Erflags could be adapted to replace
literal IPv4 addresses with symbolic host names.

Option 5: Something else on a global scale. But... hey wait... we
already have that! It is called binkp.net. So for those who want to
run Fidonet in an IPv6 only environment using NAT64 and DNS64 to
reach IPv4 only systems, just configure your binkd to use binkp.net
and the literal IPv4 adresses will be taken care of. OK, that only
works for binkd but there is just one system using a literal IPv4
address that has no binkp capability so for that one you just have to
configure a manual override. If you want to make a direct connect
using vmodem that is...

Did I test this? Yes of course! See next week's article...


In order not to have to tell the same story over and over again, I
sometimes refer people to Fidonews articles I wrote in the past.
Since there seems to be no easely available searcheable archive, I
made a list of these articles. I hope I did not miss any.

My previous Fidonews articles about IPv6:


FN 26:31 Jul 2009 FidoNet and IPv6
FN 28:04 Jan 2011 FidoNet and IPv4 depletion
FN 28:07 Feb 2011 Fido and IPv6 Day
FN 28:16 Apr 2011 APNIC runs out
FN 28:20 May 2011 The IPv6 echo
FN 28:31 Aug 2011 A SECOND LIFE FOR THE LINKSYS Part 1
FN 28:32 Aug 2011 A SECOND LIFE FOR THE LINKSYS PArt 2
FN 28:45 Nov 2011 A "first"
FN 29:04 Jan 2012 World IPv6 Launch Day, 6 June 2012
FN 29:09 Feb 2012 A SECOND LIFE FOR THE LINKSYS Part 3
FN 29:38 Sep 2012 RIPE is out of IPv4 addresses.
FN 32:17 Apr 2015 IPv6 penetration in the nodelist
FN 32:26 Jun 2015 ARIN is out of IPv4 addresses.
FN 32:52 Dec 2015 IPv6 in Fidonet by the end of 2015
FN 33:02 Jan 2016 IPv6 in two thousand SIX teen
FN 33:06 Feb 2016 Another barrier broken.
FN 34:01 Jan 2017 IPv6 in 2016
FN 34:13 Mar 2017 SixXs Sunset 06-06-2017
FN 34:30 Jul 2017 TV without IPv6
FN 34:31 Jul 2017 DS-Lite emulation experiment v2.0
FN 34:37 Sep 2017 DS-Lite emulation experiment 2.0, the results
FN 34:33 Aug 2017 DS-Lite: a solution
FN 34:38 Sep 2017 DS-Lite Emulation experiment v2.1
FN 35:01 Jan 2018 IPv6 in 2017
FN 35:53 Dec 2018 IPv6 in 2018
FN 36:52 Dec 2019 IPv6 in 2019
FN 38:01 Jan 2021 IPv6 in 2020
FN 38:20 May 2021 100 IPv6 nodes
FN 39:01 Jan 2022 IPv6 in 2021
FN 40:01 Jan 2023 IPv6 in 2022
FN 41:01 Jan 2024 IPv6 in 2023

Happy IPv6 in 2025. =============================================================================

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