Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    IPV6    |    The convoluted hot-mess that is IPV6    |    4,612 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 4,149 of 4,612    |
|    Michiel van der Vlist to Victor Sudakov    |
|    Connection Tests    |
|    24 Apr 23 16:22:01    |
      TID: FMail-W32 2.2.0.0       RFC-X-No-Archive: Yes       TZUTC: 0200       CHRS: CP850 2       MSGID: 2:280/5555 64469543       REPLY: 2:5005/49 644576e2       Hello Victor,              On Monday April 24 2023 01:20, you wrote to me:               VS>>> Only when you know the IPv6 address and port beforehand.               MV>> When runing servers you normally do...               VS> P2P apps like Transmission are not really servers.               VS> Well they are in the strict sense of the word, but people just start        VS> them up and hope for them to work out of the box,              That's their problem...               VS> and they are often configured by default to randomize port numbers on        VS> each start.              Bad practise...               VS>>> Usually an IPv6 address on the home LAN is dynamic (SLAAC),               MV>> No. SLAAC addresses are not dynamic. They are derived from the        MV>> MAC address.               VS> Not any more. AFAIK the recent implementation of SLAAC uses the        VS> privacy extensions which do not use the MAC address but some random        VS> numbers to derive the IPv6 host address.              Privacy extensions use random numbers for the host part. AFAIK SLAAC still       uses the MAC address. What I do see is that DHCP6 is often preferred over       SLAAC and the host part of a DHCP6 address also looks random. But it       definitely is a fixed address. So no problem.               VS>>> and the port in peer-to-peer applications, VoIP applications etc        VS>>> is often dynamic too.               MV>> VOIP normally uses standard ports.               VS> SIP (the signalling protocol) does, but the RTP uses random ports. A        VS> firewall has no way to know the RTP dynamic port numbers unless it        VS> inspects the SIP protocol.              If those "random" ports are previously initaiated by the SIP protocol there       should be no problem.               VS>>> The situation is different of course when you are hosting an        VS>>> IPv6 web-server or something like that. It would have a fixed        VS>>> IPv6 address and port anyway, so there is no need for        VS>>> punch-holing the firewall.               MV>> Indeed.               VS> I don't really understand your point. If we decide that UPnP (think        VS> "automatic firewall configuration from the inside") is desirable for        VS> IPv4,              That "we" does not include me. I have never used UPnP, have always had it       disabled in my routers and never had any need for it.              I consider UPnP a security risk.              So maybe I am not the right person to discuss this "issue".               VS> then it's desirable for IPv6 too. If we decide that UPnP is not        VS> desirable, you can do without it in IPv4: just configure a static        VS> RFC1918 address and port on your internal "server" and create a static        VS> NAT/portmapping entry on the router.              Works for me...                     Cheers, Michiel              --- GoldED+/W32-MSVC 1.1.5-b20170303        * Origin: he.net certified sage (2:280/5555)       SEEN-BY: 1/123 15/0 19/10 90/1 103/705 104/117 105/81 106/201 123/131       SEEN-BY: 124/5016 153/757 7715 154/10 203/0 218/700 221/0 6 226/30       SEEN-BY: 227/114 229/110 112 113 206 307 317 400 426 428 452 470 550       SEEN-BY: 229/664 700 240/1120 5832 250/1 266/512 280/464 5003 5006       SEEN-BY: 280/5555 282/1038 292/854 8125 301/1 310/31 317/3 320/219       SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 633/267       SEEN-BY: 633/280 281 410 412 418 420 509 712/848 770/1 5019/40 5020/545       SEEN-BY: 5020/1042 5053/58       PATH: 280/5555 464 633/280 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca