Not Working IPv4
By Michiel van der Vlist (2:280/5555)

As some of you may have noticed a new category of nodes was added to
the list of IPv6 nodes as published weekly here in the Snooze. The new
category is NWI4. It stands for "Not Working IPv4".

Until about a month ago I did not even know they existed but thanks to
Dmitry Protasoff I became aware that there are nodes that advertise
dual stack capability but that are only reachable via IPv6. *1) They
are not reachable via IPv4 despite the fact that the hostname in the
nodelist resolves to both an IPv4 and an IPv6 address.

What is remarkable is not really the fact that these nodes exist, an
error can easily occur, but that they apparently can exist for quite
some time before the sysops concerned become aware of it and take
steps to correct it by fixing the problem with IPv4 or by removing the
A record from the DNS and adding the INO4 flag to the nodelist. But
nothing like that has happened yet. 3:770/1 for example has been
unreachable via IPv4 for almost two months now. That is not just an
obscure end node, it is a busy hub with many links in Fidonet and some othernets. Nevertheless nobody noticed or so it seems.

What does that tell us other than that many systems seem to run on (semi)autopilot? Well, I say that it also shows that the era of IPv4
dominance is coming to an end. IPv6 is the future but IPv4 is still indispensable and will be with us for decades to come has been the
word since the turn of the millennium. But if dual stack systems can
continue to run for months with broken IPv4 and nobody noticing, by
now IPv4 would seem to not be all that indispensable anymore I'd say.
Earlier this week Google's statistics on global IPv6 adoption peaked
above 50% for the first time in IPv6 history. *2) So maybe we are
finally getting somewhere and the era of IPv6 dominance and the phase
out of IPv4 has begun.

This article was written without the use of AI.

References:

1) https://nodelist.fidonet.cc/analytics/ipv6-only
2) https://www.google.com/intl/en/ipv6/statistics.htm


-----------------------------------------------------------------

-+- Azure/NewsPrep 3.0
+ Origin: Home of the Fidonews (2:2/2.0)


--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: he.net certified sage (2:280/5555)

Hello Michiel!

04 May 26 02:46, you wrote to all:

nothing like that has happened yet. 3:770/1 for example has been unreachable via IPv4 for almost two months now. That is not just an

That's a bit unfair. Paul has been in the process of moving, and that is not something that happens over night.
Even the best laid plans sometimes fail.


Stephen


--- GoldED+/LNX 1.1.5-b20260304
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- Prt: 6800 (3:633/280)

Hello Michiel!

04 May 26 02:46, you wrote to all:

nothing like that has happened yet. 3:770/1 for example has been unreachable via IPv4 for almost two months now.

A follow up from my previous message... Works from here..

+ 12:27 [24336] outgoing session with agency.bbs.nz:24554 [103.193.138.76]
- 12:27 [24336] OPT CRAM-MD5-78d6f64437e5de71b208505a486bbcee
+ 12:27 [24336] Remote requests MD mode
- 12:27 [24336] SYS Agency + Risa HUB
- 12:27 [24336] ZYZ Paul Hayton
- 12:27 [24336] LOC Dunedin, New Zealand
- 12:27 [24336] NDL 115200,TCP,CM,MO,IBN,BINKP,PING,IPv6
- 12:27 [24336] TIME Mon, 4 May 2026 14:27:36 +1200
- 12:27 [24336] VER binkd/1.1a-115/Linux binkp/1.1
+ 12:27 [24336] addr: 3:57/0@fidonet
+ 12:27 [24336] addr: 3:770/1@fidonet
+ 12:27 [24336] addr: 3:770/0@fidonet
+ 12:27 [24336] addr: 3:772/1@fidonet
+ 12:27 [24336] addr: 3:772/0@fidonet
+ 12:27 [24336] addr: 21:0/0@fsxnet
+ 12:27 [24336] addr: 21:1/0@fsxnet
+ 12:27 [24336] addr: 21:1/1@fsxnet
+ 12:27 [24336] addr: 21:1/2@fsxnet
+ 12:27 [24336] addr: 21:1/3@fsxnet
+ 12:27 [24336] addr: 21:21/0@fsxnet
+ 12:27 [24336] addr: 21:1/100@fsxnet
+ 12:27 [24336] addr: 39:970/0@amiganet
+ 12:27 [24336] addr: 46:3/103@agoranet
- 12:27 [24336] TRF 0 0
+ 12:27 [24336] Remote has 0b of mail and 0b of files for us
- 12:27 [24336] OPT EXTCMD CRYPT GZ BZ2
+ 12:27 [24336] Remote supports EXTCMD mode
+ 12:27 [24336] Remote requests CRYPT mode
+ 12:27 [24336] Remote supports GZ mode
+ 12:27 [24336] Remote supports BZ2 mode
+ 12:27 [24336] pwd protected session (MD5)
- 12:27 [24336] session in CRYPT mode
+ 12:27 [24336] done (to 3:770/1@fidonet, OK, S/R: 0/0 (0/0 bytes))



Stephen


--- GoldED+/LNX 1.1.5-b20260304
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- Prt: 6800 (3:633/280)

Re: Not working IPv4. Article as published in Fidonews
By: Michiel van der Vlist to All on Mon May 04 2026 02:46 am

Howdy,

3:770/1 for example has been
unreachable via IPv4 for almost two months now. That is not just an
obscure end node, it is a busy hub with many links in Fidonet and some othernets. Nevertheless nobody noticed or so it seems.

FWIW, I connect to 3:770/1 multiple times per day over IPv4, and have done for the last two months.

Perhaps there is some issue, why you have come to the conclussion that it is unreachable...


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Hello Stephen,

On Monday May 04 2026 11:31, you wrote to me:

3:770/1 for example has been unreachable via IPv4 for almost two
months now.

That's a bit unfair. Paul has been in the process of moving, and that
is not something that happens over night. Even the best laid plans sometimes fail.

Of course, shit happens all the time. But this wasn't meant as an attack on Paul or any other sysop. 3:770/1 was just an example and the core of my article was not the fact that connection failures with IPv4 happen, but the fact that they seem to go unnoticed for some time and everything just keeps working anyway. Via IPv6.

I get my information from the site of Dmitry Protasoff:

https://nodelist.fidonet.cc/analytics/ipv6-only

Scroll down to the node in question and click on "history" on the right.

I can not explain why you manage to make an IPv4 connect and Dmitry's system does not.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: he.net certified sage (2:280/5555)

Michiel van der Vlist wrote to Stephen Walsh <=-

3:770/1 for example has been unreachable via IPv4 for almost two
months now.

That's a bit unfair. Paul has been in the process of moving, and that
is not something that happens over night. Even the best laid plans sometimes fail.

Of course, shit happens all the time. But this wasn't meant as an
attack on Paul or any other sysop. 3:770/1 was just an example and the core of my article was not the fact that connection failures with IPv4 happen, but the fact that they seem to go unnoticed for some time and everything just keeps working anyway. Via IPv6.

I get my information from the site of Dmitry Protasoff:

https://nodelist.fidonet.cc/analytics/ipv6-only

Scroll down to the node in question and click on "history" on the
right.

I can not explain why you manage to make an IPv4 connect and Dmitry's system does not.

It seems that *MANY* (perhaps even ALL) people other than Dmitry can
make an IPv4 connect... Hmmmm, where could the problem be?



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.37-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

On 04 May 2026, Michiel van der Vlist said the following...

What is remarkable is not really the fact that these nodes exist, an
error can easily occur, but that they apparently can exist for quite
some time before the sysops concerned become aware of it and take
steps to correct it

3:770/1 for example has been unreachable via IPv4 for almost two months

I can reach 3:770/1 via IPv4 from here on both ports 24553 & 24554:

+ 06:40 [65633] call to 3:770/1@fidonet
06:40 [65633] trying agency.bbs.nz [103.193.138.76]...
06:40 [65633] connected
+ 06:40 [65633] outgoing session with agency.bbs.nz:24554 [103.193.138.76]
- 06:40 [65633] OPT CRAM-MD5-d580837935bce4524a7bec73a28173ee
+ 06:40 [65633] Remote requests MD mode
- 06:40 [65633] SYS Agency + Risa HUB
- 06:40 [65633] ZYZ Paul Hayton
- 06:40 [65633] LOC Dunedin, New Zealand
- 06:40 [65633] NDL 115200,TCP,CM,MO,IBN,BINKP,PING,IPv6
- 06:40 [65633] TIME Mon, 4 May 2026 22:40:46 +1200
- 06:40 [65633] VER binkd/1.1a-115/Linux binkp/1.1
[snip]

+ 06:38 [65564] call to 3:770/1@fidonet
+ 06:38 [65564] External command 'openssl s_client -4 -quiet -alpn binkp -connect agency.bbs.nz:24553' started, pid 65565
06:38 [65564] connected
+ 06:38 [65564] outgoing session with agency.bbs.nz:24553
depth=0 CN = localhost
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = localhost
verify error:num=10:certificate has expired
notAfter=Jan 28 21:04:56 2025 GMT
verify return:1
depth=0 CN = localhost
notAfter=Jan 28 21:04:56 2025 GMT
verify return:1
- 06:38 [65564] OPT CRAM-MD5-9ae528fa78fcdef41890560d5be7d8ee
+ 06:38 [65564] Remote requests MD mode
- 06:38 [65564] SYS Agency + Risa HUB
- 06:38 [65564] ZYZ Paul Hayton
- 06:38 [65564] LOC Dunedin, New Zealand
- 06:38 [65564] NDL 115200,TCP,CM,MO,IBN,BINKP,PING,IPv6
- 06:38 [65564] TIME Mon, 4 May 2026 22:38:48 +1200
- 06:38 [65564] VER binkd/1.1a-115/Linux binkp/1.1
[snip]


Jay

... A man does not look behind the door unless he has stood there himself

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: Northern Realms (1:229/664)

Hello Michiel!

04 May 26 14:03, you wrote to me:

That's a bit unfair. Paul has been in the process of moving, and
that is not something that happens over night. Even the best laid
plans sometimes fail.

Of course, shit happens all the time. But this wasn't meant as an
attack on Paul or any other sysop. 3:770/1 was just an example and the

core of my article was not the fact that connection failures with IPv4 happen, but the fact that they seem to go unnoticed for some time and everything just keeps working anyway. Via IPv6.

That is the issue with dual stack. Until such a time as there is only IPv6, these type of things will happen. I've even seen it in commercial setups.

I can not explain why you manage to make an IPv4 connect and Dmitry's system does not.

Location, Location! We are in the general same region, so less internet blips to cause issues.



Stephen


--- GoldED+/LNX 1.1.5-b20260304
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- Prt: 6800 (3:633/280)