Opened 6 years ago

Closed 4 years ago

#9098 closed defect (wontfix)

Hidden service protocol has IPv4 baked into it

Reported by: andrea Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.14-alpha
Severity: Keywords: tor-hs needs-proposal
Cc: andrea Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The current hidden service protocol assumes a single-protocol IPv4 environment. Specifically:

The v2 HS descriptor has exactly one ip-address field per intro point, which is parsed by tor_addr_parse(). This will accept an IPv6 address, although I haven't checked what the client will do with it if it gets one. In a mixed IPv4/v6 environment it's obviously undesirable for there to be only one ip-address field per intro point, although possibly a service could get around that by listing the IPv4 and IPv6 addresses of a node in separate intro points.

The v2/v3 INTRODUCE cell format have the 4-byte IPv4 address of a rendezvous point hard-coded. This will have to change to something like this:

  • 1 byte address family
  • 1 byte address length
  • variable-length address

...possibly together with a way for the service to indicate in its descriptors what address families it will support in rendezvous points.

Yeah, I know there's a long list of desired hidden service improvements and a Tor network where any nodes don't support IPv4 is far off in the future, but I haven't seen this one mentioned before so I thought I'd file a bug while I remembered it.

Child Tickets

Change History (2)

comment:1 Changed 6 years ago by nickm

Keywords: tor-hs needs-proposal added

comment:2 Changed 4 years ago by nickm

Resolution: wontfix
Status: newclosed

Proposal 224 will solve this. Won't fix in current hs protocol.

Note: See TracTickets for help on using tickets.