Opened 4 years ago

Last modified 15 months ago

#12138 new enhancement

No IPv6 support when suggesting a bindaddr to a PT

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-pt, tor-bridge ipv6
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This recent post in tor-talk:
http://www.marshut.com/iwuqqh/setting-up-an-ipv6-%20supporting-obfs3-bridge.html
revealed that Tor does not support IPv6 when supporting a bind address to a pluggable transport. It seems that we missed that during #7011.

The problem is that the first time someone fires up a ServerTransportPlugin, Tor will suggest to it to bind in 0.0.0.0:0. This can be seen in get_stored_bindaddr_for_server_transport:
https://gitweb.torproject.org/tor.git/blob/2ee56e4c2c841a45418cfb826e1ce6689278382d:/src/or/statefile.c#l517

 no_bindaddr_found:
  /** If we didn't find references for this pluggable transport in the
      state file, we should instruct the pluggable transport proxy to
      listen on INADDR_ANY on a random ephemeral port. */
  tor_asprintf(&default_addrport, "%s:%s", fmt_addr32(INADDR_ANY), "0");
  return default_addrport;

Instead of using fmt_addr32(INADDR_ANY), we should use fmt_addrport and suggest [::] if we need to use IPv6. We should probably suggest an IPv6 address, if our ORPort is IPv6 (what if we have both kinds of ORPorts?).

Implementation of this should not be hard. I can do it one of these days.

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-final

comment:2 in reply to:  description Changed 4 years ago by yawning

Replying to asn:

Instead of using fmt_addr32(INADDR_ANY), we should use fmt_addrport and suggest [::] if we need to use IPv6. We should probably suggest an IPv6 address, if our ORPort is IPv6 (what if we have both kinds of ORPorts?).

If the ORPort is *just* IPv6, then suggesting [::] should be fine, ditto the opposite, but I don't think that's all that useful.

Implementation of this should not be hard. I can do it one of these days.

Before deciding on what to do (unless it's just special casing a bridge that only provides IPv6 service), we really should figure out how to make pluggable transports play nice in dual stack configs before fixing this (See: #11211).

In the short term, if people *really* want to setup an IPv6 bridge, they can specify ServerTransportListenAddr and get a bridge that only works over IPv6 for the specified transport.

But at least as of right now, I think it's safe to assume that when people say "IPv6" they mean "IPv6 in addition to IPv4", so the hack won't be sufficient in the majority of the deployment scenarios.

comment:3 Changed 4 years ago by nickm

Keywords: 026-triaged-1 026-deferrable added

comment:4 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:5 Changed 21 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:6 Changed 20 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:7 Changed 15 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 15 months ago by nickm

Keywords: 026-triaged-1 removed

comment:9 Changed 15 months ago by nickm

Keywords: 026-deferrable removed

comment:10 Changed 15 months ago by nickm

Keywords: ipv6 added
Severity: Normal
Type: defectenhancement
Note: See TracTickets for help on using tickets.