1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Filename: xxx-ipv6-plan.txt
Title: How to implement IPv6 in Tor
Author: Nick Mathewson
Created: 1 March 2011
Status: Draft
Overview:
This document outlines what we'll have to do to make Tor fully
support IPv6. It refers to other proposals, current and as-yet
unwritten. It suggests a few incremental steps, each of which on
its own should make Tor more useful in the brave new IPv6 future of
tomorrow.
Motivation:
Turns out, 4 billion addresses wasn't enough.
What needs to change:
Tor uses the Internet in many ways. There are three main ways that
will need to change for IPv6 support, from most urgent to least
urgent.
1. Tor must allow connections from IPv6-only clients. (Currently,
routers and bridges do not listen on IPv6 addresses, and can't
advertise that they support IPv6 addresses, so clients can't
learn that they do.)
2. Tor must transport IPv6 traffic and IPv6-related DNS traffic.
(Currently, Tor only allows BEGIN cells to ask for connections
to IPv4 targets or to hostnames, and only allows RESOLVE cells
to request A and PTR records.)
3. Tor must allow nodes to connect to one another over IPv6.
Allowing IPv6-only clients is the most important, since unless we
do, these clients will be unable to connect to Tor at all. Next
most important is to support IPv6 DNS related dependencies and
exiting to IPv6 services. Finally, allowing Tor nodes to support a
dual stack of both IPv4 and IPv6 for interconnection seems like a
reasonable step towards a fully hybrid v4/v6 Tor network.
One implementation hurdle that will need to get resolved alongside
these changes is to convert uint32_t to tor_addr_t in many more places
in the Tor code, so we can handle addresses being either IPv4 or IPv6.
There are a few cases, e.g. the local router list, where we'll want
to think harder about the resource requirements of keeping tens of
thousands of larger addresses in memory.
More issues may of course also be discovered as we develop solutions
for these issues, some of which may need to take priority.
Designs that we will need to do:
For IPv6-only clients, we'll need to specify that routers can have
multiple addresses and ORPorts.
There is an old proposal (118) to try to allow multiple
ORPorts per router. It's been accepted; it needs to be checked for
correctness, updated to track other changes in more recent Tor
versions, and updated to work with the new microdescriptor designs.
Additionally, we'll need to audit the designs for all our codebase
for places that might assume that IPs are a scarce resource. For
example, clients assume that any two routers occupying an IPv4 /16
network are "too close" topologically to be used in the same
circuit, and the bridgedb HTTPS distributor assumes that hopping
from one /24 to another takes a little effort for most clients.
The directory authorities assume that blacklisting an IP is an okay
response to a bad router at that address. These and other places
will instead need more appropriate notions of "closeness" and
"similarity".
We'll want to consider geographic and political boundaries rather than
purely mathematical notions such as the size of network blocks.
We'll need a way to advertise IPv6 bridges, and to use them.
For transporting IPv6-only traffic, we have another accepted design
proposal (117). It has some open questions concerning proper
behavior with respect to DNS lookups, and also needs to be checked
and updated to track current Tor designs.
We do not have a current accepted design proposal for allowing
nodes to connect to each other via IPv6. Allowing opportunistic
IPv6 traffic between nodes that can communicate with both IPv4 and
IPv6 will be relatively simple, as will be bridges that have only
an IPv6 address: both of these fall out relatively simply from
designing a process for advertising and connecting to IPv6
addresses. The harder problem is in supporting IPv6-only
Tor routers. For these, we'll need to consider network topology
issues: having nodes that can't connect to all the other nodes
will weaken one of our basic assumptions for path generation, so
we'll need to make sure to do the analysis enough to tell whether this
is safe.
Ready, fire, aim: An alternative methodology
At least one volunteer is currently working on IPv6 issues in Tor.
If his efforts go well, it might be that our first design drafts
for some of these open topics arrive concurrently with (or even in
the form of!) alpha code to implement them. If so, we need to
follow a variant of the design process, extracting design from code
to evaluate it (rather than designing then coding). Probably,
based on design review, some changes to code would be necessary.
|
