Skip to content

Latest commit

 

History

History
322 lines (263 loc) · 17.2 KB

PREFIXES.MD

File metadata and controls

322 lines (263 loc) · 17.2 KB

6BED4 PREFIXES AND PROMISES

6bed4 works over a globally registered prefix TBD1 and a standard UDP port TBD2. But there can be alternatives that route through the same 6bed4 infrastructure.

Facilitation by 6bed4

The 6bed4 facilities are as follows:

  • The prefix of the address may or may not be globally routable. This is impartial to 6bed4, but not necessarily for its users. Locally routable addresses can serve internal purposes (which is a vague term) including (potentially large) peer-to-peer networks. Global routability means that anyone can route to the IPv6 endpoing addresses of 6bed4 peers, possibly going through the 6bed4router.

  • The prefix may also help to learn about the capability of an address for opportunistic peering. This capability must apply to both the sender and recipient for a frame, because any NAT traversal must be kept open, thus requiring a bidirectional UDP stream. Note that no assumptions may be made in general about remote nodes, other than the recognition of globally defined prefix capabilities.

  • The top-half of the address contains a fallback server, which can be used when direct contact between peers is not possible. Without this, it is still possible to communicate with a configured fallback server, but peers will only keep NAT open towards their own fallback server. As a result, the fallback server is a necessary hop between peers, and not finding a peer's fallback server in their IPv6 address top half could lead to failure to connect. Because of this, communication can only be done locally.

  • The lower half of the address contains a peer's public IPv4 address and UDP port. This information can be used for opportunistic peering, with the option of the fallback server to deal with unroutable situations between direct peers. Port numbers 0 in the lower half can never be used meaningfully in a 6bed4 address, so their handling is undefined.

So, when the top-half has no room for the fallback server's IP address, then it can only be used on one 6bed4router (or on a cluster, but certainly not globally).

Candidate Prefixes

The following prefixes spring to mind for use with 6bed4:

  • TBD1::/32 and its extension TBD1:<ipv4>::/64 are the perfect prefixes for 6bed4. They support the top-half and bottom-half structures, and are globally defined to do so.

  • fc64:<netid>:<ipv4>::/64 may be used for 6bed4 as well. The <netid> could be varied to indicate different applications, so the prefix is as for 6bed4, the fc64:<netid>::/32 prefix. The fc00::/8 prefix indicates locally unique addresses. Since this also limits the scope, any connection between such nets may be read as an indication that they are on the same local net and the interpretation may therefore be assumed. This is true for all fc00::/8 addresses, but we suggest leaving room for other uses by setting fc64::/8 specifically for the 6bed4 interpretation of the remainder of the address. Note that fd00::/8 also covers unique local addresses, but it is followed by random bits, so no policy can be applied without breaking standards (and software). Note that fc00::/8 is a local scoped name space, but it is possible to connect 6bed4peers behind different fallback servers. It is simply a matter of distribution of addresses whether two peers will be able to communicate. We believe this scheme is perfect for peer-to-peer operations, especially with the use of IPsec.

  • Native IPv6 /48 or /64 prefixes may be used, but they will not facilitate the top-half. Sometimes the native use of native addresses may compete with use in a 6bed4router; this is especially true when only one /64 is available. In this case, the undefined behaviour of port 0 in the lower half may be used to bypass native traffic to a natively connected service. Other than this, any 6bed4peer collecting these addresses can do anything; native addresses can be reached, opportunistic connections to peers are possible and even the native services using port 0 would work. The one thing that is impossible, as with fc64::/16, is that independent 6bed4router processes can serve the same prefix and have their 6bedpeer 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 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 6bed4router accepts multiple prefixes, simply by issuing more than one -L prefix. Each of these will be provided to the 6bed4peers in Router Advertisements, after having completed them to a /114 prefix length. When a 6bed4peer receives such prefixes, it should configure them all, after setting its preference(s) of in the last 14 bits.

The sizes of the various prefixes vary. The following things are added when possible:

  • the fallback server IPv4 address, when at least 32 bits are available;
  • network identities, to fill up any remaining 16 bits

This format works for prefixes of sizes 16, 32, 48 and 64:

  • xxxx::/16 becomes top half xxxx:<ipv4>:<netid>::/64 or xxxx:<netid>:<ipv4>::/64
  • xxxx:yyyy::/32 becomes top half xxxx:yyyy:<ipv4>::/64
  • xxxx:yyyy:zzzz::/48 becomes top half xxxx:yyyy:zzzz:<netid>::/64
  • xxxx:yyyy:zzzz:wwww::/64 is unaltered

Specifically for the indicated candidate prefixes:

  • TBD1::/32 becomes top half TBD1:<ipv4>::/64
  • fc64:<netid>::/32 becomes top half fc64:<netid>:<ipv4>::/64
  • fc64::/16 becomes top half fc64:<netid>:<ipv4>::/64
  • fdXX:XXXX:XXXX::/48 becomes top half fdXX:XXXX:XXXX:<netid>::/64
  • fdXX:XXXX:XXXX:XXXX::/64 is unaltered
  • 2002::/16 becomes top half 2002:<ipv4>:<netid>::/64
  • 2002:<ipv4>::/48 becomes top half 2002:<ipv4>:<netid>::/64
  • xxxx:yyyy:zzzz::/48 becomes top half xxxx:yyyy:zzzz:<netid>::/64
  • xxxx:yyyy:zzzz:wwww::/64 is unaltered

These do all support routing based on the bottom half. Furthermore:

  • The fallback server appearing as 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?

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:

shell$ ip6tables -A OUTPUT -s fc00::/7 -j DROP
shell$ ip6tables -A OUTPUT -d fc00::/7 -j DROP
shell$ ip6tables -A  INPUT -s fc00::/7 -j DROP
shell$ ip6tables -A  INPUT -d 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. 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. This is a simple technical matter of adding hash tables to the IPv6 implementation as it has been done for the IPv4 counterpart.

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).

As an example: fallback serers may each use their own fd00::/8 prefix with a random continuation that differs between fallback servers. Some mechanism of the network informs such servers about their joint action as a peer-to-peer network. The fallback servers use the random bits to route using a mechanism like Kademlia, possibly after some initial randomisation as proposed by GNUnet. This means that the fallback servers form a peer-to-peer network. As far as the 6bed4 clients know, they can link to other fd00::/8 local addresses, and route them up to their fallback server if the complete /64 differs from another that they might like to contact.

Overview of Prefix Options

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.

 Prefix in -L    | world.top | world.bot | 6bed4.top | 6bed4.bot
-----------------+-----------+-----------+-----------+-----------
 TBD1::/32       |    yes    |    yes    |    yes    |    yes
 fc64:X::/16,32  |   maybe   |   maybe   |    yes    |    yes
 fdX:X:X:X::/64  |   maybe   |   maybe   |     no    |    yes
 native/48,/64   |     no    |     no    |     no    |   maybe
 2002::/16       |   vague   |     no    |   vague   |   maybe

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.

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.