Migration to GitLab
[6bed4] / PREFIXES.MD
1 6BED4 PREFIXES AND PROMISES
2 ===========================
3
4 > *6bed4 works over a globally registered prefix TBD1 and a standard
5 > UDP port TBD2.  But there can be alternatives that route through the
6 > same 6bed4 infrastructure.*
7
8
9 Facilitation by 6bed4
10 ---------------------
11
12 The 6bed4 facilities are as follows:
13
14   * The prefix of the address may or may not be globally routable.  This is
15     impartial to 6bed4, but not necessarily for its users.  Locally routable
16     addresses can serve internal purposes (which is a vague term) including
17     (potentially large) peer-to-peer networks.  Global routability means that
18     anyone can route to the IPv6 endpoing addresses of 6bed4 peers, possibly
19     going through the 6bed4router.
20
21   * The prefix may also help to learn about the capability of an address for
22     opportunistic peering.  This capability must apply to both the sender and
23     recipient for a frame, because any NAT traversal must be kept open, thus
24     requiring a bidirectional UDP stream.  Note that no assumptions may be
25     made in general about remote nodes, other than the recognition of globally
26     defined prefix capabilities.
27
28   * The top-half of the address contains a fallback server, which can be used
29     when direct contact between peers is not possible.  Without this, it is
30     still possible to communicate with a configured fallback server, but peers
31     will only keep NAT open towards their own fallback server.  As a result,
32     the fallback server is a necessary hop between peers, and not finding a
33     peer's fallback server in their IPv6 address top half could lead to failure
34     to connect.  Because of this, communication can only be done locally.
35
36   * The lower half of the address contains a peer's public IPv4 address and
37     UDP port.  This information can be used for opportunistic peering, with
38     the option of the fallback server to deal with unroutable situations
39     between direct peers.  Port numbers 0 in the lower half can never be
40     used meaningfully in a 6bed4 address, so their handling is undefined.
41
42 So, when the top-half has no room for the fallback server's IP address, then
43 it can only be used on one 6bed4router (or on a cluster, but certainly not
44 globally).
45
46
47 Candidate Prefixes
48 ------------------
49
50 The following prefixes spring to mind for use with 6bed4:
51
52   * `TBD1::/32` and its extension `TBD1:<ipv4>::/64` are the perfect prefixes
53     for 6bed4.  They support the top-half and bottom-half structures, and are
54     globally defined to do so.
55
56   * `fc64:<netid>:<ipv4>::/64` may be used for 6bed4 as well.  The `<netid>` could
57     be varied to indicate different applications, so the prefix is as for 6bed4,
58     the `fc64:<netid>::/32` prefix.  The `fc00::/8` prefix indicates locally unique
59     addresses.  Since this also limits the scope, any connection between such
60     nets may be read as an indication that they are on the same local net and
61     the interpretation may therefore be assumed.  This is true for all `fc00::/8`
62     addresses, but we suggest leaving room for other uses by setting `fc64::/8`
63     specifically for the 6bed4 interpretation of the remainder of the address.
64     Note that `fd00::/8` also covers unique local addresses, but it is followed
65     by random bits, so no policy can be applied without breaking standards
66     (and software).  Note that `fc00::/8` is a local scoped name space, but it
67     is possible to connect 6bed4peers behind different fallback servers.  It
68     is simply a matter of distribution of addresses whether two peers will be
69     able to communicate.  We believe this scheme is perfect for peer-to-peer
70     operations, especially with the use of IPsec.
71
72   * Native IPv6 /48 or /64 prefixes may be used, but they will not facilitate
73     the top-half.  Sometimes the native use of native addresses may compete
74     with use in a 6bed4router; this is especially true when only one /64 is
75     available.  In this case, the undefined behaviour of port 0 in the lower
76     half may be used to bypass native traffic to a natively connected service.
77     Other than this, any 6bed4peer collecting these addresses can do anything;
78     native addresses can be reached, opportunistic connections to peers are
79     possible and even the native services using port 0 would work.  The one
80     thing that is impossible, as with `fc64::/16`, is that independent
81     6bed4router processes can serve the same prefix and have their 6bedpeer
82     clients reach each other; this is due to the lacking fallback server in
83     the top half.
84
85   * `fdXX:XXXX:XXXX::/48` prefixes are based on randomly assigned bits.  We
86     shall expand this to a /64, and it should be clear that these IPv6
87     addresses cannot be interpreted to hold an IPv4 address in their top half.
88     Local convention however, may dictate the interpretation of the lower half
89     for purposes of 6bed4 direct peering, provided that the other peer's
90     top half is the same.  This is a local convention, not in any way
91     different from one for a native IPv6 /48 or /64 prefix, but without
92     global routing.
93
94   * `2002:<ipv4>::/48` is based on the 6to4 prefix `2002::/16`, but instead of
95     using the peer's address and relying on the ability to pass IPv6 directly
96     over IPv4, the 6bed4router can be used as an intermediate.  The place of
97     the `<ipv4>` address is different than after the /32 of normal 6bed4
98     addresses, but this is quickly inferred from the prefix.  So, given a
99     prefix `2002:<ipv4>:<netid>::/64` it is theoretically possible to interpret
100     `<ipv4>` as the fallback server, even for foreign networks.  The problem
101     with this is concluding that the lower half of the address contains the
102     information typical for a 6bed4 peer.  This would lead to routing errors,
103     and this assumption should only be made for prefixes announced over
104     6bed4 in Router Advertisements.  In other words, the
105     `2002:<ipv4>:<netid>::/64` prefix is no different to the 6bed4 peer than
106     a native IPv6 prefix; direct peering is only done under the same /64.
107     Still, this leaves users with an option to have IPv6 addresses routed
108     over a NAT-piercing protocol from a server that should have no trouble
109     receiving proto-41 traffic.  Do note however, that 6to4 popularity is
110     in demise.
111
112
113 Implementation
114 --------------
115
116 The 6bed4router accepts multiple prefixes, simply by issuing more than one
117 `-L` prefix.  Each of these will be provided to the 6bed4peers in Router
118 Advertisements, after having completed them to a /114 prefix length.
119 When a 6bed4peer receives such prefixes, it should configure them all,
120 after setting its preference(s) of <lanip> in the last 14 bits.
121
122 The sizes of the various prefixes vary.  The following things are added
123 when possible:
124
125   * the fallback server IPv4 address, when at least 32 bits are available;
126   * network identities, to fill up any remaining 16 bits
127
128 This format works for prefixes of sizes 16, 32, 48 and 64:
129
130   * `xxxx::/16` becomes top half `xxxx:<ipv4>:<netid>::/64` or `xxxx:<netid>:<ipv4>::/64`
131   * `xxxx:yyyy::/32` becomes top half `xxxx:yyyy:<ipv4>::/64`
132   * `xxxx:yyyy:zzzz::/48` becomes top half `xxxx:yyyy:zzzz:<netid>::/64`
133   * `xxxx:yyyy:zzzz:wwww::/64` is unaltered
134
135 Specifically for the indicated candidate prefixes:
136
137   * `TBD1::/32` becomes top half `TBD1:<ipv4>::/64`
138   * `fc64:<netid>::/32` becomes top half `fc64:<netid>:<ipv4>::/64`
139   * `fc64::/16` becomes top half `fc64:<netid>:<ipv4>::/64`
140   * `fdXX:XXXX:XXXX::/48` becomes top half `fdXX:XXXX:XXXX:<netid>::/64`
141   * `fdXX:XXXX:XXXX:XXXX::/64` is unaltered
142   * `2002::/16` becomes top half `2002:<ipv4>:<netid>::/64`
143   * `2002:<ipv4>::/48` becomes top half `2002:<ipv4>:<netid>::/64`
144   * `xxxx:yyyy:zzzz::/48` becomes top half `xxxx:yyyy:zzzz:<netid>::/64`
145   * `xxxx:yyyy:zzzz:wwww::/64` is unaltered
146
147 These do all support routing based on the bottom half.  Furthermore:
148
149   * The fallback server appearing as <ipv4> in the top half enables unrelated 6bed4router connectivity
150   * The rules for global routing determine whether the addresses can communicate with native IPv6 addresses
151
152
153 Routing Local Addresses
154 -----------------------
155
156 As explained, some prefixes can be routed globally:
157
158   * `TBD1::/32`
159   * `TBD1:<ipv4>::/64`
160
161 Other prefixes are defined by local addressing policy and can only be
162 directly peered to peers that match the prefix:
163
164   * Native IPv6 /48 prefixes
165   * Native IPv6 /64 prefixes
166   * `fc64:<netid>:<ipv4>::/64`
167   * `fdXX:XXXX:XXXX::/48`
168   * `fdXX:XXXX:XXXX:XXXX::/64`
169   * `2002:<ipv4>::/48`
170   * `2002:<ipv4>:<netid>::/64`
171
172 Having to relay all traffic the fallback router is not necessarily the end
173 of the (networking) world, however.  There are still options for routing.
174
175 Even the local addressing schemes for `fc64::/16` and `fd00::/8` are local
176 in the sense of convention, but the addresses are thought and hoped to be
177 globally unique, thus allowing them to spread out without a risk of clashes.
178
179 What this means is that the router may be *explicitly configured* to connect
180 to other server nodes with the same interpretation policy.  It is even possible
181 to mix `fc64:<netid>` with different `<netid>` values and treat them as one
182 network; the only concern is the interpretation of the address format should
183 match.  Now, wasn't Linux visionary when it defined the wonderful notion of
184 [network namespaces](https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/)?
185
186 It is in fact strongly advised to do any routing for non-global prefixes in
187 a namespace that is separate from any native routing.  This helps to avoid
188 leaking local traffic over a default route, which is always a bad idea.
189 Likewise, local traffic should not be inserted so easily and accidentally
190 by an upstream router.  We recommend that you partition your network
191 to separate out the local namespaces `fc64::/16` and `fd00::/8`.
192
193 If you do not partition into netwok namespaces, you can instead ensure that
194 any prefix cannot get out or in across the scope of interpretation, which
195 usually means the primary network interface of a machine:
196
197 ```
198 shell$ ip6tables -A OUTPUT -s fc00::/7 -j DROP
199 shell$ ip6tables -A OUTPUT -d fc00::/7 -j DROP
200 shell$ ip6tables -A  INPUT -s fc00::/7 -j DROP
201 shell$ ip6tables -A  INPUT -d fc00::/7 -j DROP
202 ```
203
204 Having made sure that no *default traffic* for local addresses are exchanged
205 with an outside that interprets those addresses differently, we can now add
206 *explicit routes* between servers that have the same interpretation of the
207 addresses.  This can be done through tunnels, of any kind you like.  Since
208 the fallback router is supposed to control its routing and firewalling more
209 professionally than home/office nodes, the UDP layer is no longer required.
210
211 Among the many options that now arise are:
212
213   * IPIP tunnels, packing IPv6 in IPv4 or IPv6 in IPv6.  These lead to a
214     different `ip link` for each tunnel.
215   * L2TP tunnels, which allow for more management, and may be constructed
216     dynamically or statically.  L2TP is often used with IPsec protection,
217     though that might not add much if the 6bed4 usage patterns did not.
218     L2TP is also used as a backend protocol for such things as PPPoE,
219     and it may be statically configured using `ip link` or dynamically
220     using [extensive management tools](http://openl2tp.org).  L2TPv2
221     handles 2 level of 16-bit identities, L2TPv3 uses 32-bit identities.
222   * GRE, which can send traffic with 32-bit keys.  GRE over IPv6 in Linux
223     may not scale well, but over IPv4 it does.  This is a simple technical
224     matter of adding hash tables to the IPv6 implementation as it has been
225     done for the IPv4 counterpart.
226
227 The reason for emphasising the 32-bit identities in the above is that this
228 might be used to automate tunneling to a given IPv4 address.  Note that the
229 remarks about scope of interpretation applies when this is done.  This is
230 not a good idea for `fd00::/8` adresses, which really ought to be filled
231 with random data, without any opportunity of interpretation.  Interesting
232 about `fd00::/8` however is that it defines a /48 prefix and the remainder
233 may be interpreted locally, for instance as a 16-bit identity for an L2TP
234 protocol.  All these are just options to simplify automation.
235
236
237 Peer-to-Peer Networking
238 -----------------------
239
240 We emphasised the value of global routing, but this is not always desired.
241 Specifically for peer-to-peer networks, this requirement is not useful at
242 all.  In fact, such networks may even use the ORCHID address range, which
243 introduces 96 bits from a hash over a public key as a hint to a host's
244 identifying key.  Note that ORCHID leaves no room for us to interpret the
245 lower half of the address for 6bed4, so it cannot be used for our purposes.
246
247 A peer-to-peer network can however be based on 6bed4 addresses such as
248 `fc64::/16` ranges, or even a network-specific `fdXX:XXXX:XXXX::/48` or
249 `fdXX:XXXX:XXXX:XXXX::/64` prefix and the 6bed4 interpretation for the
250 lower half of the address.
251
252 It may sound like a contradiction to combine hosting with peer-to-peer
253 networking.  The trick however, is that connected hosts allow the peer
254 to choose a hosting party that suits his goals in terms of control,
255 jurisdiction and privacy.  This may in fact be a hosting provider that
256 intentionally protects their customer's privacy, possibly in return
257 for payment (which is a way of being sure that the contract needs to be
258 consistently lived by, a property that "free" services do not offer).
259
260 Also note that many setups with 6bed4 allow peers to connect directly.
261 This is even true with shared prefixes from a local-address range.
262 As a result, the user still has full control, and may only need to
263 fallback to the server to detect their address, and/or as a fallback
264 route.  When setup completely (usually with port forwarding in one's
265 NAT router) the fallback server can be completely abolished; this
266 however, would be the "extra-value" option for die-hards, but not a
267 strict necessity for those who are just getting started on the network.
268
269 There are also benefits in a technical sense.  Where peer-to-peer networks
270 employ clever techniques to make routing less dependent on infrastructure,
271 there still is a need for a lot of communication in service of others on
272 the network; this results from multi-hop routing in the overlay network.
273 If an average of 10 hops are needed, then count on an average of 9 frames
274 to route for a single frame that you send.  It can be attractive to bundle
275 such responsibilities in a hosted server, whose traffic is usually cheaper,
276 whose connectivity is more stable and whose routing may benefit multiple
277 tenants of the peer-to-peer network.  Many who have tried peer-to-peer
278 systems on their mobile phone would agree that the unpredictably elevated
279 cost of traffic is unattractive.
280
281 All this constitutes choices to be made by designers of a peer-to-peer
282 network.  They are however saved a lot of trouble passing through NAT
283 when they adopt the 6bed4 mechanism, so it is probably worthwhile to
284 consider.  Among the choices is the address prefix that will be used;
285 `fc64:<netid>:<ipv4>::/64` is helpful because of the embedded IPv4
286 address that can be interpreted as a hosting endpoint; on the other hand,
287 `fdXX:XXXX:XXXX:XXXX::/64` introduces a kind of *network identity*
288 in the random bits, and strictly relies on the interpretation of the
289 lower half where all the opportunistic peering takes place, and it will
290 never step out to someone else's router, which can happen when `fc64::/16`
291 is used.  Abundant choices, but they are all good (in their own way).
292
293 As an example: fallback serers may each use their own `fd00::/8` prefix
294 with a random continuation that differs between fallback servers.
295 Some mechanism of the network informs such servers about their joint
296 action as a peer-to-peer network.  The fallback servers use the random
297 bits to route using a mechanism like Kademlia, possibly after some initial
298 randomisation as proposed by GNUnet.  This means that the fallback servers
299 form a peer-to-peer network.  As far as the 6bed4 clients know, they can
300 link to other `fd00::/8` local addresses, and route them up to their
301 fallback server if the complete /64 differs from another that they might
302 like to contact.
303
304
305 Overview of Prefix Options
306 --------------------------
307
308 Not all prefixes are equally suited for routing; the interpretation of `6bed4` may go farther than the rest of the `world`, and varies between the `.top` and `.bot` halves of the address.
309
310 ```
311  Prefix in -L    | world.top | world.bot | 6bed4.top | 6bed4.bot
312 -----------------+-----------+-----------+-----------+-----------
313  TBD1::/32       |    yes    |    yes    |    yes    |    yes
314  fc64:X::/16,32  |   maybe   |   maybe   |    yes    |    yes
315  fdX:X:X:X::/64  |   maybe   |   maybe   |     no    |    yes
316  native/48,/64   |     no    |     no    |     no    |   maybe
317  2002::/16       |   vague   |     no    |   vague   |   maybe
318 ```
319
320 In the table above, `yes` indicates that the IPv4 address and UDP port can be found from the `.top` or `.bot` half of the address; `no` indicates that this is not possible; `maybe` indicates that such a thing may be configured specifically as a local address policy; `vague` indicates that confusion and inconsistencies are likely even under a local policy is defined, and these forms are therefore best avoided.
321
322 For `-R` prefixes, the situation is more relaxed.  As long as the hosts on these networks know how to route back to a `6bed4router` at its `-L` prefix, there should be no problem contacting such networks.  Note how the `-R` ranges can open up with `world` routable forms in the `-L` prefix.