[Galene] Re: IPv6 and ICE [was: galene on IPv6 only]

[Curtis Villamizar <curtis@orleans.occnc.com>]

In message <e864dc2c-2164-4d6c-8863-ffc1a658c193@gmail.com>
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 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).
> >
> >>> 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 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.
> >
> > -- Juliusz

[... trim ...]