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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Filename: xxx-ipv6-roadmap.txt
Title: Roadmap for implementing IPv6 in Tor
Authors: Nick Mathewson
Created: 29 December 2011
Status: Draft
0. Overview
IPv6 support is important, but too large to do in a single step.
Therefore, we need a plan for how to build IPv6, starting with high
benefit-per-effort items, and eventually getting full IPv6 support in
Tor's protocols and implementation.
The phases in brief:
1. Remove internal barriers and limitations in Tor's implementation
that would affect IPv6 hosts and multi-stack hosts.
2. Make client->private bridge connections support IPv6.
3. Make client->public bridge connections support IPv6.
4. Make client->relay connections support IPv6.
5. Support exiting to IPv6 addresses over Tor.
6. Allow relays to connect to one another over IPv6.
0.1. Motivation
4 billion addresses wasn't enough.
Also, the IPv6 world is currently not quite so censored as the IPv4
world, so we should take advantage of that.
1. The roadmap in detail
We list the steps below in rough implementation order. There may be
issues with what we can do without hurting anonymity which has to do
with how many relays we have on IPv6. So maybe it's not wise to derive
the deployment order from the implementation order. The following tasks
also differ hugely in size.
1.1. Phase 1: Infrastructure, part 1
Throughout Tor, there are pieces of code that make certain assumptions
which we will need to change in order to support the features below.
Most of these pieces are already implemented, including:
* We have switched nearly all of our code that assumed an IPv4
address to assume an IPv4 or an IPv6 address.
* We have relaxed the assumption that a Tor relay or bridge may have
one address.
1.2. Phase 2: Client->Private Bridge connections
The first piece of IPv6 functionality to deploy is allowing clients
to talk to bridges over IPv6. (This is simplest because it requires
relatively little design, and has minimal impact on the rest of the
network and codebase.)
The Tor side of this more or less complete. Bridges can advertise
themselves as having IPv4 and IPv6 address, and clients can use a
bridge over IPv6 if configured to know about its IPv6 address.
Design issues to solve:
* If the user configures both the IPv4 and the IPv6 address of a
given bridge, which one does the client use? (Defaulting to IPv6
if possible seems like a reasonable policy for starters).
* Should we (can we?) detect whether the client is configured to use
its ethernet MAC to build the last part of its address, and
treat it as a privacy issue inasmuch as it allows a bridge to
link connections from a single ethernet device as it moves around
the net? If possible, we should at least detect this, tell
the user how to work around it, and prefer IPv4 so long as our
IPv6 address identifies our device.
There is a UI component here as well. We must extend the Tor
controllers to allow IPv6 bridges. Vidalia, arm, Torflow, TAILS, and
TorCtl will all need to be tested.
1.3. Phase 3: Client->Public Bridge connections
The next stage is to support IPv6 addresses in public bridges.
This is mainly a matter of extending support tools. We need to
implement the part of proposal 186 that specifies how IPv6 addresses
are tested and added to network statuses, so that the bridge authority
can test IPv6 bridges and tell BridgeDB about them.
We'll also need to enhance bridgedb itself.
We'll need an IPv6 GeoIP database for bridges to use to tell where
they're being censored.
BridgeDB needs to be extended to parse IPv6 addresses in bridge
descriptors, and give them out to clients who can support them.
Identifying these clients will need some work. One option is for
clients to opt in; another is to detect clients who have connected to
BridgeDB over an IPv6 address, and send them IPv6 bridges.
We need to update the metrics-db parts that sanitize bridge
descriptors. We need to come up with an algorithm for sanitizing IPv6
addresses similar to the one for sanitizing IPv4 addresses.
We'll need to migrate the bridge authority to IPv6 soon if we
anticipate clients and/or bridges without IPv4 addresses. The
administrator says the server can be on IPv6 as soon as we need it to.
1.4. Phase 4: Client->Relay connections
The next step will be to make clients talk to non-bridge relays via
IPv6. Most of the code here is written: there are only a few more
tweaks to make in order to expand client->bridge support into
client->relay support.
Most notably, we'll need a way for clients to decide which address to
use when connecting to a server. As in phase 1, we should take
MAC-address privacy and other IPv6 privacy issues into account.
Design considerations:
* We might want to delay deploying the client-side facility until a
threshold of relays are advertising IPv6 addresses.
Directory authorities will need a way to test IPv6 addresses; relays
will need to self-test them as well as their IPv4 addresses. The hard
part there will be to expand the current notion of self-testing and
node testing so that a test result is now associated with a
node-address pair, rather than just a node.
Related tools will need to know about IPv6 relays, including the
metrics subsystem.
If we plan to have IPv6-only clients, we should make sure that some
directory authorities run on IPv6. Maatuska has an IPv6 address as of
November 22. We should not turn on relays on IPv6 until we have some
other relays on IPv6 too, so as not to load the directory authorities
too badly.
1.5. Phase 5: IPv6 exit support
This part will be particularly fiddly, but as more and more target
addresses support IPv6, it will be increasingly useful.
Once IPv6 exits become extant, relays will want to prove they were
running a relay at a given IPv6 address, so ExoneraTor will need to
handle IPv6 in relay descriptors.
Our DNS system has long needed serious work. For IPv6 support, we'll
need to get our resolver to support IPv6 addresses, and our clients do
decide which to report to the client and which to use. Solving this
could be part of a broader DNS revamp. Long ago, we wrote a design
document (proposal 117) to try to solve some of these issues, but it
will need more attention based on experience we've gained over the
past few years.
The second part of making IPv6 exits work is to transport IPv6 traffic
and exit to IPv6 servers. The issues to solve here are exit policies;
formulating an approach similar to the notion of topologically close
in IPv4 (same /16) to IPv6, unless it doesn't make sense; and
implementing the specified enhancements to RELAY_BEGIN cells from
tor-spec.
Necessary tool enhancements will include:
- We need to extend TorDNSEL/TorBEL and the part of ExoneraTor that
processes the TorDNSEL/TorBEL output.
- We also need to update VisiTor to handle IPv6 addresses in web server
logs and compare them to exit lists.
1.6. Phase 6: Relay->Relay connections on IPv6
This part is least essential, and should fall out as a consequence of
the other parts.
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.
|
