Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    WINPOINT    |    Support for the WinPoint software    |    1,004 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 689 of 1,004    |
|    Michiel van der Vlist to Tim Schattkowsky    |
|    WinPoint Version 404 IPV5    |
|    12 Mar 22 15:16:05    |
      TID: FMail-W32 2.1.3.7-B20170919       RFC-X-No-Archive: Yes       TZUTC: 0100       CHRS: CP850 2       MSGID: 2:280/5555 622cb026       REPLY: 2:240/1120.29 473fbe83       Hello Tim,              On Saturday March 12 2022 02:11, you wrote to Wilfred van Velzen:               TS>>> I have changed WP to use the first address returned by the OS.        TS>>> We have to test if that works as expected.               WvV>> And if the first fails or times out, it should move on to the        WvV>> next (that's what binkd does)...               TS> Yes, that is the idea. But this is a little more work and thus not        TS> something I do right now. Again, this currently makes preferring IPv4        TS> over IPv6 probably the better choice, as it addresses exactly the        TS> scenario where the fallback would be needed.              A fallback is in order when there is more than one IP adress to choose from       and the attempt to connect with the first choice fails for one reason or       another. This is not related to IPv6 vs IPv4 per s‚. It could be that the host       presents several IPv4 addresses but no IPv6 address. Or the other way around,       it presents more than one IPv6 address but no IPv4 address. Or it could       produce a mix of IPv4 and IPv6 addresses. But let us focus on the case that       the choice is between IPv6 and IPv4.              Your conjecture that IPv4 is the better choice instead of the choice presented       by the OS in case there is no fallback mechanism is based on the assumption       that in general IPv4 has a better chance of resulting in a connection than       IPv6. As we discussed before, that may have been a valid assumption ten years       ago, but it certainly does not hold today. Yes, one may still run into a       situation where an IPv6 connection fails and an IPv4 connection can be       established. But one may just as well run into the reverse situation. I have       no personal experience with the latter situation. My system always tries the       OS choice first, which (nearly) always is IPv6. So I do not know if it ever       happens that an IPv4 connect fails and a subsequent IPv6 succeeds. My binkd       does not try to outsmart the OS in choosing between IPv4 and IPv6. But I have       no reason to think that the one will happen more often than the other. In this       case I do not think it is a good idea to try to outsmart Windows...               TS> I still keep thinking (and nothing brought forward so far has been a        TS> valid argument against it) that in practice there are usually only        TS> benefits and no drawbacks of preferring IPv4 over IPv6 when both are        TS> available.              I already mentioned the situation that the Winpoint user is on a DS-Lite       connection and the BOSS node is Dual Stack. I also mentioned the situation       that the BOSS node is on a DS-LIite connection but presents an (invalid) IPv4       address nevertheless.               TS> On the other side, there usually exists absolutely no benefit for the        TS> user in choosing IPv6 in that scenario.              Maybe not from the POV of the user, but for the internet as a whole choosing       IPv4 where IPv6 is possible is detrimental regarding the transition from IPv4       to IPv6. That transition is unavoidable and the faster it is completed, the       better.                     Cheers, Michiel              --- GoldED+/W32-MSVC 1.1.5-b20170303        * Origin: http://www.vlist.eu (2:280/5555)       SEEN-BY: 15/0 106/201 124/5016 129/331 153/757 7715 203/0 218/700       SEEN-BY: 221/0 229/110 317 426 428 664 700 266/512 280/464 5003 5555       SEEN-BY: 282/1038 292/854 8125 301/1 310/31 317/3 320/219 341/234       SEEN-BY: 396/45 460/58 712/848 770/1 2452/250       PATH: 280/5555 464 712/848 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca