clients reach each other; this is due to the lacking fallback server in
the top half.
+ * fdXX:XXXX:XXXX::/48 prefixes are based on randomly assigned bits. We
+ shall expand this to a /64, and it should be clear that these IPv6
+ addresses cannot be interpreted to hold an IPv4 address in their top half.
+ Local convention however, may dictate the interpretation of the lower half
+ for purposes of 6bed4 direct peering, provided that the other peer's
+ top half is the same. This is a local convention, not in any way
+ different from one for a native IPv6 / 48 or /64 prefix, but without
+ global routing.
+
* 2002:<ipv4>::/48 is based on the 6to4 prefix 2002::/16, but instead of
using the peer's address and relying on the ability to pass IPv6 directly
over IPv4, the 6bed4router can be used as an intermediate. The place of
the <ipv4> address is different than after the /32 of normal 6bed4
- addresses, but this is easily inferred from the prefix. So, it is quite
- possible to interpret <ipv4> as the fallback server. What is not safe
- to assume though, is that the underlying portion is a 6bed4 address. To
- allow for that, we define a "special SLA value" be64, as a hint that the
- lower half may be interpreted for opportunistic peering.
- TODO: This breaks with traditions... NOT FIT FOR A FORMAL SPEC
-
+ addresses, but this is quickly inferred from the prefix. So, given a
+ prefix 2002:<ipv4>:<netid>::/64 it is theoretically possible to interpret
+ <ipv4> as the fallback server, even for foreign networks. The problem
+ with this is concluding that the lower half of the address contains the
+ information typical for a 6bed4 peer. This would lead to routing errors,
+ and this assumption should only be made for prefixes announced over
+ 6bed4 in Router Advertisements. In other words, the
+ 2002:<ipv4>:<netid>::/64 prefix is no different to the 6bed4 peer than
+ a native IPv6 prefix; direct peering is only done under the same /64.
+ Still, this leaves users with an option to have IPv6 addresses routed
+ over a NAT-piercing protocol from a server that should have no trouble
+ receiving proto-41 traffic. Do note however, that 6to4 popularity is
+ in demise.
Implementation
* The fallback server appearing as <ipv4> in the top half enables unrelated 6bed4router connectivity
* The rules for global routing determine whether the addresses can communicate with native IPv6 addresses
+
+Routing Local Addresses
+-----------------------
+
+As explained, some prefixes can be routed globally:
+
+ * TBD1::/32
+ * TBD1:<ipv4>::/64
+
+Other prefixes are defined by local addressing policy and can only be
+directly peered to peers that match the prefix:
+
+ * Native IPv6 /48 prefixes
+ * Native IPv6 /64 prefixes
+ * fc64:<netid>:<ipv4>::/64
+ * fdXX:XXXX:XXXX::/48
+ * fdXX:XXXX:XXXX:XXXX::/64
+ * 2002:<ipv4>::/48
+ * 2002:<ipv4>:<netid>::/64
+
+Having to relay all traffic the fallback router is not necessarily the end
+of the (networking) world, however. There are still options for routing.
+
+Even the local addressing schemes for `fc64::/16` and `fd00::/8` are local
+in the sense of convention, but the addresses are thought and hoped to be
+globally unique, thus allowing them to spread out without a risk of clashes.
+
+What this means is that the router may be *explicitly configured* to connect
+to other server nodes with the same interpretation policy. It is even possible
+to mix `fc64:<netid>` with different `<netid>` values and treat them as one
+network; the only concern is the interpretation of the address format should
+match. Now, wasn't Linux visionary when it defined the wonderful notion of
+[network namespaces](https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/)?
+
+It is in fact strongly advised to do any routing for non-global prefixes in
+a namespace that is separate from any native routing. This helps to avoid
+leaking local traffic over a default route, which is always a bad idea.
+Likewise, local traffic should not be inserted so easily and accidentally
+by an upstream router. We recommend that you partition your network
+to separate out the local namespaces `fc64::/16` and `fd00::/8`.
+
+If you do not partition into netwok namespaces, you can instead ensure that
+any prefix cannot get out or in across the scope of interpretation, which
+usually means the primary network interface of a machine:
+
+```
+ip6tables -A OUTPUT -d fc00::/7 -j DROP
+ip6tables -A INPUT -s fc00::/7 -j DROP
+```
+
+Having made sure that no *default traffic* for local addresses are exchanged
+with an outside that interprets those addresses differently, we can now add
+*explicit routes* between servers that have the same interpretation of the
+addresses. This can be done through tunnels, of any kind you like. Since
+the fallback router is supposed to control its routing and firewalling more
+professionally than home/office nodes, the UDP layer is no longer required.
+
+Among the many options that now arise are:
+
+ * IPIP tunnels, packing IPv6 in IPv4 or IPv6 in IPv6. These lead to a
+ different `ip link` for each tunnel.
+ * L2TP tunnels, which allow for more management, and may be constructed
+ dynamically or statically. L2TP is often used with IPsec protection,
+ though that might not add much if the 6bed4 usage patterns did not.
+ L2TP is also used as a backend protocol for such things as PPPoE,
+ and it may be statically configured using `ip link` or dynamically
+ using [extensive management tools](http://openl2tp.org). L2TPv2
+ handles 2 level of 16-bit identities, L2TPv3 uses 32-bit identities.
+ * GRE, which can send traffic with 32-bit keys. GRE over IPv6 in Linux
+ may not scale well, but over IPv4 it does.
+
+The reason for emphasising the 32-bit identities in the above is that this
+might be used to automate tunneling to a given IPv4 address. Note that the
+remarks about scope of interpretation applies when this is done. This is
+not a good idea for `fd00::/8` adresses, which really ought to be filled
+with random data, without any opportunity of interpretation. Interesting
+about `fd00::/8` however is that it defines a /48 prefix and the remainder
+may be interpreted locally, for instance as a 16-bit identity for an L2TP
+protocol. All these are just options to simplify automation.
+
+
+Peer-to-Peer Networking
+-----------------------
+
+We emphasised the value of global routing, but this is not always desired.
+Specifically for peer-to-peer networks, this requirement is not useful at
+all. In fact, such networks may even use the ORCHID address range, which
+introduces 96 bits from a hash over a public key as a hint to a host's
+identifying key. Note that ORCHID leaves no room for us to interpret the
+lower half of the address for 6bed4, so it cannot be used for our purposes.
+
+A peer-to-peer network can however be based on 6bed4 addresses such as
+`fc64::/16` ranges, or even a network-specific `fdXX:XXXX:XXXX::/48` or
+`fdXX:XXXX:XXXX:XXXX::/64` prefix and the 6bed4 interpretation for the
+lower half of the address.
+
+It may sound like a contradiction to combine hosting with peer-to-peer
+networking. The trick however, is that connected hosts allow the peer
+to choose a hosting party that suits his goals in terms of control,
+jurisdiction and privacy. This may in fact be a hosting provider that
+intentionally protects their customer's privacy, possibly in return
+for payment (which is a way of being sure that the contract needs to be
+consistently lived by, a property that "free" services do not offer).
+
+Also note that many setups with 6bed4 allow peers to connect directly.
+This is even true with shared prefixes from a local-address range.
+As a result, the user still has full control, and may only need to
+fallback to the server to detect their address, and/or as a fallback
+route. When setup completely (usually with port forwarding in one's
+NAT router) the fallback server can be completely abolished; this
+however, would be the "extra-value" option for die-hards, but not a
+strict necessity for those who are just getting started on the network.
+
+There are also benefits in a technical sense. Where peer-to-peer networks
+employ clever techniques to make routing less dependent on infrastructure,
+there still is a need for a lot of communication in service of others on
+the network; this results from multi-hop routing in the overlay network.
+If an average of 10 hops are needed, then count on an average of 9 frames
+to route for a single frame that you send. It can be attractive to bundle
+such responsibilities in a hosted server, whose traffic is usually cheaper,
+whose connectivity is more stable and whose routing may benefit multiple
+tenants of the peer-to-peer network. Many who have tried peer-to-peer
+systems on their mobile phone would agree that the unpredictably elevated
+cost of traffic is unattractive.
+
+All this constitutes choices to be made by designers of a peer-to-peer
+network. They are however saved a lot of trouble passing through NAT
+when they adopt the 6bed4 mechanism, so it is probably worthwhile to
+consider. Among the choices is the address prefix that will be used;
+`fc64:<netid>:<ipv4>::/64` is helpful because of the embedded IPv4
+address that can be interpreted as a hosting endpoint; on the other hand,
+`fdXX:XXXX:XXXX:XXXX::/64` introduces a kind of *network identity* in
+the random bits, and strictly relies on the interpretation of the
+lower half where all the opportunistic peering takes place, and it will
+never step out to someone else's router, which can happen when `fc64::/16`
+is used. Abundant choices, but they are all good (in their own way).
+
+
projects / 6bed4 / commitdiff