Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
|  Message 4149  |
|  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 >> ]