[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] ipv6 behaviour consensus



Hello,

Charly Ghislain wrote:
> selfreplying as I hadn't read the whole ticket thread at the time of
> writing (still haven't, tbh).
> 
> I think there are real reason to use natted traffic in this period of
> transition toward ip6 and that must be supported.
> My setup (ha proxy litening on both interfaces, tor relay listening on
> ip4 only) was used because tor is running in a containerized
> environment, heavily relying on natted ipv4 networks to route the
> traffic to the correct container, which might run on another host.
> Corporates still use internal ip4 vpn/firewalls, with load balancers
> accepting ip6 traffic.
> 
> For many other reasons, the ip/interface/port you are listening to might
> be very different than the one you publicly advertise. Lets keep it that
> way.
> 

I totally agree. But why would you want to advertise an IPv6 ORPort if
your Tor daemon only truly has IPv4 socket? This is what I don't
understand. Why would one want that? Just to look neat in the consensus?
It's like having a Diesel car, but buying gasoline and exchanging that
at the corner for Diesel with another person (in the context where both
products have equal cost, and there is no additional gain by doing this
effort).

IPv6 is optional for the time being when running a Tor relay. Two basic
purposes IPv6 was designed for are:
- eliminate the need for NAT - nobody is happy about it. It was just a
necessary evil at the time, to ensure keep things on going on IPv4;
- ensure better end-to-end connectivity;

There are so many ways to properly do it. Like encapsulate traffic,
6-in-4 tunnels, etc. etc. , many ways that would allow the Tor host to
actually have an IPv6 socket.

Having an application advertising it is reachable on an address class,
but not having an open socket (not listening anywhere) on that other
class is confusing, wrong and breaks logic. It hasn't anything to do
with the fact that migration solutions are needed for quite some time in
the future. On this I agree, but there are plenty of solutions that will
allow Tor to behave logically and ask one open socket from the family it
is advertising to authorities, like use a tunnel or transparent
encapsulation method.

If a Tor daemon doesn't actually have (listen) on IPv6, and some middle
box does the translation and forwards to the same v4 socket already
advertised in the consensus as IPv4, what is the use for it? It's
useless, it adds data to the consensus. I know it works without
problems, but I can't see the real use of it.

One use I can think for this is in a world where an IPv6 only client
gets to use such a relay as Guard, by connecting it to its advertised
IPv6 address (regardless that will be actually converted to IPv4 before
it hits the relay, this will be transparent to the client and will
actually work).

Is it worth it? I don't know, but I am looking forward to hear more
opinions from people that know much more about this.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays