vanrein/android6bed4

Android 6bed4 tunnel to IPv6

android6bed4's Issues

Linking across 6bed4 server ranges

When two nodes reside under a different 6bed4 router, their /64 prefixes will differ. When connecting a peer under another /64, for instance using a connect() method, exchange pleasantries with the remote party's router or with the remote party's endpoint address. This leads to a same-valued top /64 for the two endpoints of a connection, thus avoiding trapezium-shaped routing. This is only possible under TBD1::/32, AFAIK.

This means that no initial contact with the upstream 6bed4router is made to determine an address, until a bind() or listen() or read() is done; if instead, connect() is used, even on a UDP socket, the remote peer is contacted for their address.

Always send to public_server when remote_port==0

The lookup_neighbor() function will happily try to contact remotes at UDP port 0. We have recently decided that such addresses must always be forwarded to the public_router or more accurately the upstream router, so that these may be used to host services.

Addresses with their last 14 bits set to 0 always belong with the public_router, too, as this signifies the router itself. With the support of masquerading, this too will be a potential for services on the hosting end.

Support for alternative prefixes & promises

We recently decided to support alternative prefixes and promises. Briefly put, the lower half of anything transported over 6bed4's UDP/IPv4 connections are interpreted as holding an IPv4 address and UDP port in their extension from /64 to /114, so anything dealing with direct peering stays functional.

What may differ however, is whether an IPv4 address can be derived for direct routes. We informally took the fc64:<netid>::/32 prefix (for any <netid>, so this is actually just a /16 prefix) to mean a locally routed subset followed by an IPv4 address, just like the "real" 6bed4 prefix TBD1::/32. For both, an upstream server may be contacted directly, and Android6bed4 may request a lower-half fill-up from /64 to /114 by sending a Router Solicitation to the public server for the prefix. This special handling has not been covered in Android6bed4 yet.

The fdXX:XXXX:XXXX::/48 and 2002:XXXX:XXXX::/48 prefixes may also be of some use, but do not permit derivation of an IPv4 address for a public server, so unless routed explicitly between public servers, there is no chance of setting up a connection; traffic will often pass through a trapezium held up by two routers instead of zero or one, as is customary for 6bed4. This situation is no different from a supplied native /64 prefix, in fact: traffic always needs to be sent to the configured public_server.

There are many other prefixes, not of interest to us. For instance, the ORCHID addresses occupy the entire /128, but are not meant for routing — which happens to be our most pressing concern.