From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=orleans.occnc.com; dkim=pass header.d=orleans.occnc.com; arc=none (Message is not ARC signed); dmarc=none Received: from mta6-tap0.andover.occnc.com (mta6-tap0.andover.occnc.com [IPv6:2600:2c00:b000:2500::153]) by mail.toke.dk (Postfix) with ESMTPS id DD1BFE6F96C for ; Sat, 21 Mar 2026 21:47:06 +0100 (CET) Received: from harbor6.andover.occnc.com (harbor6.andover.occnc.com [IPv6:2600:2c00:b000:2500::610b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519MLKEM768 server-signature ECDSA (secp384r1) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: curtis@occnc.com) by mta6-tap0.andover.occnc.com (Postfix) with ESMTPSA id D6035F214; Sat, 21 Mar 2026 16:47:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orleans.occnc.com; s=curtis-orleans-20250605-224653; t=1774126025; bh=PGK5hWyngP49XhgzBVe3HW2fuZYmlIqoRU4sM3VZBcY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=KwWwXyTfhX/Dx+X3kvko2f1Y19B+jRFsvRj3+Dh98kBbyLm3JgrgG+REbISnL1RkN ModwXBefBWoWxLE0P5UYbf6UiwCX4UrBZoPzmvAXQg8j9ebvqQjFB0WIJxJWTRajNK buNXcQNSSU7EfVsa5RjZDDl5NMpVbXekUJjdnhw6KxERJfNtYsND5bwXAYbUtC8Xh+ VaJtXvid8fa+Pt6PPI4K50M/1j+UcBK1KTCnUU5apv6g2ZWUJr41PKVl8zDSb65DGc U1ToW0o6SN7bqUD2IcP5tixwE+X8DLHlsigZM3dMFZIZJmP4ahHtaOjWp9/OjMbok+ eEFJWdsDSjN3Q== To: Craig Miller cc: galene@lists.galene.org From: Curtis Villamizar In-reply-to: Your message of "Sat, 21 Mar 2026 08:09:26 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92071.1774125608.1@harbor6.andover.occnc.com> Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Mar 2026 16:40:08 -0400 Message-ID: <177412602788.1734.10712605539474417758@gauss> Message-ID-Hash: 7O6XIIV4JJDZZV3JDJBYNV7VZMBHR6CH X-Message-ID-Hash: 7O6XIIV4JJDZZV3JDJBYNV7VZMBHR6CH X-MailFrom: curtis@orleans.occnc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Reply-To: Curtis Villamizar Subject: [Galene] Re: IPv6 and ICE [was: galene on IPv6 only] List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: In message Craig Miller writes: = > I think the goal needs to be better described. I'm not sure there was a goal here. This was a discussion of why supporting NAT even when running IPv6 is needed. For the case of the galene software Juliusz makes a convincing case that it is needed. > In an IPv6-only environment, there is NO NAT. Yes there is a stateful = > firewall, but ports are opened to destinations in a DMZ network for = > services offered from the DMZ. In my case there are no NATs in the way. I'm testing at home so I made sure that there would be no NAT by tunneling IPv6 past my ISP (in IPv4) directly to a host at the datacenter. Since this case isn't working it may be that gelene doesn't just support ICE, it needs ICE to function. Just speculative, waiting for Juliusz to confirm. Late breaking (or unbroken) news. I just tried with the built in TURN serve enabled and it works. So yes, it appears galene needs ICE. That would be a bug IMHO but I'm not sure my opinion matters enough to make it worth addressing unless it bugs me enough for me to (attempt to) "fix" the code. Seems harmless so maybe doesn't need fixing. > For Galene, if a pool of UDP ports were be defined, then that pool could= = > be opened in the stateful firewall allowing incoming UDP to the Galene = > server. There would be no need for ICE or STUN, since those address/port= = > destinations would be available to the internet. Good workaround for that case. Thanks. > Craig... Curtis > On 3/21/26 04:44, Juliusz Chroboczek wrote: > > I'm separating this into its own thread, so we can focus on Galene > > improvements in the main thread. > > > >>> I, too, used to be optimistic about IPv6 ;-) > >> That is another discussion. So I'll try to be brief. > > No need to be brief, people who are not interested will hit delete. > > > >> Even here in the laggard US more consumer ISPs are offering IPv6 > >> either enabled by default or enabled on request. > > Oh, fully agreed, sorry for the misunderstanding. I have no doubts th= at > > IPv6 is being widely deployed. I'm also fully committed to having Gal= ene > > work well in v6-only networks. (In fact, Nexedi, one of the former > > sponsors of Galene, are running a v6-only network internally, using > > reverse proxies for all v4 access.) > > > > What I'm no longer optimistic about is IPv6 traffic being end-to-end, = with > > no middleboxes. People are putting stateful firewalls around their IP= v6 > > networks, so we still need things like STUN and TURN in order to cross > > these firewalls. And I have it on good authority that people are doin= g > > NAT in IPv6. Granted, it's 1-to-1 NAT, not NAPT, but it's still NAT. > > > > And then there's the issue of corporate firewalls (that whitelist web > > traffic and Zoom, because the web and Zoom are supposedly not threats,= but > > block anything else). And don't get me started on state-sponsored > > firewalls (China, of course, but also Russia and other petrodictatorsh= ips). > > > >>> ICE is still required, since both address selection and blackhole > >>> detection are done by ICE. > >> This is not a problem in my case. IPv6 in the clear, no NAT. > > How I wish that were true! > > > > There's the issue of the client-side firewall. If it's a simple state= ful > > firewall, as in most residential networks, then you need ICE in order > > to ensure that the first packet in a UDP flow goes from client to serv= er. > > If it's a fascist corporate firewall that blocks all non-web traffic, = then > > you need a TURN server on port 443 (and preferably more than one, on > > different IP ranges). > > > > Even when there's no firewall, ICE is the mechanism that allows Galene= to > > detect that a UDP flow is no longer functioning, and therefore to reli= ably > > restart a flow after a UDP outage: it detects the case when UDP sudden= ly > > gets filtered but the TCP WebSocket remains functional. > > > > -- Juliusz [... trim ...]