Publish transports that bind on IPv6 addresses

Currently, pt_get_extra_info_descriptor_string() uses router_pick_published_address() to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.

The bad news are that router_pick_published_address() only returns IPv4 addresses, and we will probably have to refactor it, or do something like this: ~~ https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 ~~ (wrong commit reference) for IPv6 addresses.

Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.

changed milestone to %Tor: unspecified

added anticensorship component::core tor/tor ipv6 milestone::Tor: unspecified needs-spec points::3 priority::medium pt refactor severity::normal status::needs-information tor-bridge type::defect labels

Trac:
Keywords: tor-bridge pt deleted, tor-bridge pt ipv6 added

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Keywords: tor-bridge pt ipv6 deleted, pt, tor-03-unspecified-201612, tor-bridge, ipv6 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Sponsor: N/A to N/A
Points: N/A to 3
Reviewer: N/A to N/A
Keywords: ipv6 deleted, ipv6 anticensorship needs-spec refactor easy added
Severity: N/A to Normal

I would like to work on this. Do I need to create a wrapper around router_pick_published_address() which will take family as an argument and return the address as IPv4 or IPv6 accordingly, if it exists and return -1 otherwise?

Trac:
Username: fristonio

This is not an easy patch.

Since you've posted implementation questions on two different tickets, I'm going to leave you to answer some of the detailed pluggable transport questions on this ticket.

There are four cases in pt_get_extra_info_descriptor_string():

1. the pluggable transport has told us it is listening on a specific IPv4 address

• this case is already handled correctly

2. the pluggable transport has told us it is listening on a specific IPv6 address

• this case is handled correctly for transports that are IPv6-only
• one address is used for transports that are dual-stack, but which one?
• do any current pluggable transports (PTs) supply their specific IPv6 address?
• what do transports with an IPv4 and an IPv6 address do?
• how does Tor handle what they do?
  • transport_t only has one address/port field, so dual stack transports are not supported

3. the pluggable transport has told us it is listening on all IPv4 addresses

• this case is already handled correctly

4. the pluggable transport has told us it is listening on all IPv6 addresses

• do any current pluggable transports (PTs) say they are listening on all IPv6 addresses?
• how do we distinguish between IPv4 only, IPv4/IPv6 and IPv6 only transports?
  • what do transports with an IPv4 and an IPv6 address do?
    • do they give the address as 0.0.0.0, ::, or [::]?
  • how does Tor handle what they do?
    • transport_t only has one address/port field, so dual-stack transports may be ambiguous or not supported
  • what do transports with an IPv6 address do?
    • do they give the address as 0.0.0.0, ::, or [::]?
  • how does Tor handle what they do?
    • Tor assumes that all null addresses are IPv4

You can focus on PTs supported by Tor Browser and BridgeDB (obfs3 and obfs4, both implemented by https://gitweb.torproject.org/pluggable-transports/obfs4.git/ ).

Replying to fristonio:

I would like to work on this. Do I need to create a wrapper around router_pick_published_address() which will take family as an argument and return the address as IPv4 or IPv6 accordingly, if it exists and return -1 otherwise?

Once you've answered the questions for case 4, you'll know if you need to do this or not.

Trac:
Keywords: ipv6 anticensorship needs-spec refactor easy deleted, ipv6 anticensorship needs-spec refactor added
Description: Currently, pt_get_extra_info_descriptor_string() uses router_pick_published_address() to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.

The bad news are that router_pick_published_address() only returns IPv4 addresses, and we will probably have to refactor it, or do something like this: https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 for IPv6 addresses.

Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.

to

Currently, pt_get_extra_info_descriptor_string() uses router_pick_published_address() to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.

The bad news are that router_pick_published_address() only returns IPv4 addresses, and we will probably have to refactor it, or do something like this: ~~ https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 ~~ (wrong commit reference) for IPv6 addresses.

Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.
Status: new to needs_information

I think that I need to be more familiar with the codebase first in order to move to difficult issues. Thank you for your response teor, I really appreciate it :) I will take on some easy issues related to Pluggable Transports to get familiar, and will try to resolve difficult ones after that.

Trac:
Username: fristonio

changed time estimate to 24h

mentioned in issue #9874 (moved)

mentioned in issue #11211 (moved)

mentioned in issue #12434 (moved)

mentioned in issue #21136 (closed)

mentioned in issue #29128 (moved)

mentioned in issue #31009 (moved)

moved to tpo/core/tor#7961 (closed)

mentioned in issue tpo/core/tor#11211