1 6BED4 PREFIXES AND PROMISES
2 ===========================
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.*
12 The 6bed4 facilities are as follows:
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.
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.
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.
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.
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
50 The following prefixes spring to mind for use with 6bed4:
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.
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.
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
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
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
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.
122 The sizes of the various prefixes vary. The following things are added
125 * the fallback server IPv4 address, when at least 32 bits are available;
126 * the literal value be64, to fill up any remaining 16 bits
128 This format works for prefixes of sizes 16, 32, 48 and 64:
130 * `xxxx::/16` becomes top half `xxxx:<ipv4>:be64::/64`
131 * `xxxx:yyyy::/32` becomes top half `xxxx:yyyy:<ipv4>::/64`
132 * `xxxx:yyyy:zzzz::/48` becomes top half `xxxx:yyyy:zzzz:be64::/64`
133 * `xxxx:yyyy:zzzz:wwww::/64` is unaltered
135 Specifically for the indicated candidate prefixes:
137 * `TBD1::/32` becomes top half `TBD1:<ipv4>::/64`
138 * `fc64:<netid>::/32` becomes top half `fc64:<netid>:<ipv4>::/64`
139 * `xxxx:yyyy:zzzz::/48` becomes top half `xxxx:yyyy:zzzz:be64::/64`
140 * `xxxx:yyyy:zzzz:wwww::/64` is unaltered
141 * `2002::/16` becomes top half `2002:<ipv4>:<netid>::/64`
143 These do all support routing based on the bottom half. Furthermore:
145 * The fallback server appearing as <ipv4> in the top half enables unrelated 6bed4router connectivity
146 * The rules for global routing determine whether the addresses can communicate with native IPv6 addresses
149 Routing Local Addresses
150 -----------------------
152 As explained, some prefixes can be routed globally:
157 Other prefixes are defined by local addressing policy and can only be
158 directly peered to peers that match the prefix:
160 * Native IPv6 /48 prefixes
161 * Native IPv6 /64 prefixes
162 * `fc64:<netid>:<ipv4>::/64`
163 * `fdXX:XXXX:XXXX::/48`
164 * `fdXX:XXXX:XXXX:XXXX::/64`
166 * `2002:<ipv4>:<netid>::/64`
168 Having to relay all traffic the fallback router is not necessarily the end
169 of the (networking) world, however. There are still options for routing.
171 Even the local addressing schemes for `fc64::/16` and `fd00::/8` are local
172 in the sense of convention, but the addresses are thought and hoped to be
173 globally unique, thus allowing them to spread out without a risk of clashes.
175 What this means is that the router may be *explicitly configured* to connect
176 to other server nodes with the same interpretation policy. It is even possible
177 to mix `fc64:<netid>` with different `<netid>` values and treat them as one
178 network; the only concern is the interpretation of the address format should
179 match. Now, wasn't Linux visionary when it defined the wonderful notion of
180 [network namespaces](https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/)?
182 It is in fact strongly advised to do any routing for non-global prefixes in
183 a namespace that is separate from any native routing. This helps to avoid
184 leaking local traffic over a default route, which is always a bad idea.
185 Likewise, local traffic should not be inserted so easily and accidentally
186 by an upstream router. We recommend that you partition your network
187 to separate out the local namespaces `fc64::/16` and `fd00::/8`.
189 If you do not partition into netwok namespaces, you can instead ensure that
190 any prefix cannot get out or in across the scope of interpretation, which
191 usually means the primary network interface of a machine:
194 shell$ ip6tables -A OUTPUT -d fc00::/7 -j DROP
195 shell$ ip6tables -A INPUT -s fc00::/7 -j DROP
198 Having made sure that no *default traffic* for local addresses are exchanged
199 with an outside that interprets those addresses differently, we can now add
200 *explicit routes* between servers that have the same interpretation of the
201 addresses. This can be done through tunnels, of any kind you like. Since
202 the fallback router is supposed to control its routing and firewalling more
203 professionally than home/office nodes, the UDP layer is no longer required.
205 Among the many options that now arise are:
207 * IPIP tunnels, packing IPv6 in IPv4 or IPv6 in IPv6. These lead to a
208 different `ip link` for each tunnel.
209 * L2TP tunnels, which allow for more management, and may be constructed
210 dynamically or statically. L2TP is often used with IPsec protection,
211 though that might not add much if the 6bed4 usage patterns did not.
212 L2TP is also used as a backend protocol for such things as PPPoE,
213 and it may be statically configured using `ip link` or dynamically
214 using [extensive management tools](http://openl2tp.org). L2TPv2
215 handles 2 level of 16-bit identities, L2TPv3 uses 32-bit identities.
216 * GRE, which can send traffic with 32-bit keys. GRE over IPv6 in Linux
217 may not scale well, but over IPv4 it does.
219 The reason for emphasising the 32-bit identities in the above is that this
220 might be used to automate tunneling to a given IPv4 address. Note that the
221 remarks about scope of interpretation applies when this is done. This is
222 not a good idea for `fd00::/8` adresses, which really ought to be filled
223 with random data, without any opportunity of interpretation. Interesting
224 about `fd00::/8` however is that it defines a /48 prefix and the remainder
225 may be interpreted locally, for instance as a 16-bit identity for an L2TP
226 protocol. All these are just options to simplify automation.
229 Peer-to-Peer Networking
230 -----------------------
232 We emphasised the value of global routing, but this is not always desired.
233 Specifically for peer-to-peer networks, this requirement is not useful at
234 all. In fact, such networks may even use the ORCHID address range, which
235 introduces 96 bits from a hash over a public key as a hint to a host's
236 identifying key. Note that ORCHID leaves no room for us to interpret the
237 lower half of the address for 6bed4, so it cannot be used for our purposes.
239 A peer-to-peer network can however be based on 6bed4 addresses such as
240 `fc64::/16` ranges, or even a network-specific `fdXX:XXXX:XXXX::/48` or
241 `fdXX:XXXX:XXXX:XXXX::/64` prefix and the 6bed4 interpretation for the
242 lower half of the address.
244 It may sound like a contradiction to combine hosting with peer-to-peer
245 networking. The trick however, is that connected hosts allow the peer
246 to choose a hosting party that suits his goals in terms of control,
247 jurisdiction and privacy. This may in fact be a hosting provider that
248 intentionally protects their customer's privacy, possibly in return
249 for payment (which is a way of being sure that the contract needs to be
250 consistently lived by, a property that "free" services do not offer).
252 Also note that many setups with 6bed4 allow peers to connect directly.
253 This is even true with shared prefixes from a local-address range.
254 As a result, the user still has full control, and may only need to
255 fallback to the server to detect their address, and/or as a fallback
256 route. When setup completely (usually with port forwarding in one's
257 NAT router) the fallback server can be completely abolished; this
258 however, would be the "extra-value" option for die-hards, but not a
259 strict necessity for those who are just getting started on the network.
261 There are also benefits in a technical sense. Where peer-to-peer networks
262 employ clever techniques to make routing less dependent on infrastructure,
263 there still is a need for a lot of communication in service of others on
264 the network; this results from multi-hop routing in the overlay network.
265 If an average of 10 hops are needed, then count on an average of 9 frames
266 to route for a single frame that you send. It can be attractive to bundle
267 such responsibilities in a hosted server, whose traffic is usually cheaper,
268 whose connectivity is more stable and whose routing may benefit multiple
269 tenants of the peer-to-peer network. Many who have tried peer-to-peer
270 systems on their mobile phone would agree that the unpredictably elevated
271 cost of traffic is unattractive.
273 All this constitutes choices to be made by designers of a peer-to-peer
274 network. They are however saved a lot of trouble passing through NAT
275 when they adopt the 6bed4 mechanism, so it is probably worthwhile to
276 consider. Among the choices is the address prefix that will be used;
277 `fc64:<netid>:<ipv4>::/64` is helpful because of the embedded IPv4
278 address that can be interpreted as a hosting endpoint; on the other hand,
279 `fdXX:XXXX:XXXX:XXXX::/64` introduces a kind of *network identity* in
280 the random bits, and strictly relies on the interpretation of the
281 lower half where all the opportunistic peering takes place, and it will
282 never step out to someone else's router, which can happen when `fc64::/16`
283 is used. Abundant choices, but they are all good (in their own way).