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 94744E6F731 for ; Sat, 21 Mar 2026 21:21:52 +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 A84D9F210; Sat, 21 Mar 2026 16:21:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orleans.occnc.com; s=curtis-orleans-20250605-224653; t=1774124509; bh=6NZGs1uyjN9RKGYAkuhlEq1/10nAlMKJpdOpORk7vIY=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=ZDadnLfqRG9f0FFvsQWyNMb+NeiSKTYEMgB9TRrwwpyngfwhNPvuAztqziD8HyiNo OFQTLT3xJdOLSzAzKccG3EQFqKETYYpdpiGvVnyO3hzLFmEon7XMiaZ4NWnWKh52Ou u51LMBYiisiemDO5/zucr4v49zdabdYB/JBafenodU42vygs0tGwsy8s0HMhvbDVp/ O8lz6BUtifaRfoxgRGKAiQlC8f5mrVEX1aXciUTeQOEg3YRdc7qs0FtvPPi5PGuGeL lcrcm62y3WpqYrLu/3u4uULgrtTA/T7/Ok1LSYTQu3QGTTylEn9YQXrygnNxA+Co/U AZcxRfsiJbW5w== To: Juliusz Chroboczek cc: Curtis Villamizar , galene@lists.galene.org From: Curtis Villamizar In-reply-to: Your message of "Sat, 21 Mar 2026 12:44:38 +0100." <87ikapo195.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91976.1774124092.1@harbor6.andover.occnc.com> Date: Sat, 21 Mar 2026 16:14:52 -0400 Message-ID: <177412451486.1734.13704910639279989816@gauss> Message-ID-Hash: P2C6CE67OXNLYBLFLRAWHKZLXOV6BAXL X-Message-ID-Hash: P2C6CE67OXNLYBLFLRAWHKZLXOV6BAXL 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 <87ikapo195.wl-jch@irif.fr> Juliusz Chroboczek writes: > I'm separating this into its own thread, so we can focus on Galene > improvements in the main thread. Good idea. > >> 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 that > IPv6 is being widely deployed. I'm also fully committed to having Galene > 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 IPv6 > 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 doing > 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 petrodictatorships). So we can agree that some people need to support IPv6 and NAT on their server. Therefore galene needs to support ICE. > >> 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! It is true in my case since I am not serving the masses but rather a small group of people. > There's the issue of the client-side firewall. If it's a simple stateful > 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 server. > 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 reliably > restart a flow after a UDP outage: it detects the case when UDP suddenly > gets filtered but the TCP WebSocket remains functional. So you seem to be saying that galene needs ICE. That is different from I need ICE (for any reason other than getting galene to work). > -- Juliusz If that is true that galene can't function without ICE then I can stop chasing down failures to display video. I'd prefer my galene neat rather than on ice. :) Thanks, Curtis