home bbs files messages ]

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