vanrein/6bed4

IPv6 everywhere (and usually peer-to-peer)

6bed4's Issues

Rewrite MAN pages (especially ADDRESS FORMAT)

It's well out of date.

Consider a configuration file

Look at Tayga, and how it reads information from a file instead of the commandline. May be useful or not.

Check if server-local but non-default-route use is possible

Nice when used side-by-side with NAT64

Consider a UDP port on IPv6

Silly, unless you position the 6bed4 server behind NAT64. A longer dependency chain though, so the mild effort of an iptables rule to divert the UDP port for 6bed4 to its interface is probably justified (more than the sequence and subsequent confusion on the IPv6 end).

Consider TAP mode, not just TUN for 6bed4router

In TAP mode, a 6bed4 interface could plug into a bridge, alongside a public IPv4 address.

• This would make the -l argument unnecessary
• Multiple 6bed4router processes might be created to accommodate multiple IPv4 addresses
• One or more IPv6 address on the interface might be used as -L and/or -R arguments

Look at what Tayga does; it has an interface that continues to exist (and be configured) in spite of the daemon going up and down. This provides better resilience. Plugging into a bridge can further enhance that.

Support / Describe local network prefixing

The random prefix fdXX:XXXX:XXXX:XXXX::/64 and local subnet fc64:<netid>:<ipv4>::/64 can be used for unrouted subnets. They may be used as defaults.

Since fd00::/8 requires a random identity which would be different between boots if not stored, it requires a file in /var/lib/6bed4router to support stateless restarts of the 6bed4router. This not being the simplest solution, it might not be used by default.

This leaves fc64:<netid>:<ipv4>::/64 as a suitable default. Its <netid> can be set from an option -n <netid> or --netid <netid> which might default to bed.

We can even specify (or just implement) that at least fc64:bed::/32 is routed between 6bed4 servers, so it will create an open interconnect between 6bed4peer instances, though not with a connection to the outside World; at least global peer-to-peer connectivity is hereby arranged and, if also taken up into the 6bed4peer, would not even require the use of a 6bed4router for anything but address assignment.

Direct connections between 6bed4peers

The p2p functionality is currently only for one prefix, but we can extend that now, after the prefix orientation and implementation.

The routes are not available in such a crossover mode, but that is not an issue; we are talking of connections to remote peers that use an address that we recognise as being specific to 6bed4, and that we can route directly.

Although fc64::/16 is a locally defined prefix, it should only arrive in our bubble when it is meaningful to us, and so, if it is a 6bed4 prefix. Note that this assumes that no other local nodes will use the prefix. In a realm where 6bed4 is used, IPv6 can probably be assumed to be not too extravagent indeed.

Integrate with DHCPv6 [6bed4node]

This is part of the extension of 6bed4peer to acting like a 6bed4node that offers multiple local hosts an IPv6 address under the /114 prefix that it retrieved. There may not be much more to it than this, really.

A specifically useful one would be dnsmasq, where an extension may be added to the configuration files and the daemon reloaded.

Doing this well probably involves tracking the 6bed4node and removing its configuration file upon termination. There could be multiple 6bed4node instances on the same DHCPv6 server.

A good first stab at a 6bed4node would be to launch a desired number of 6bed4peer instances, relaying their acquired prefixes to the DHCPv6 server and, upon exit of either 6bed4peer child, remove those prefixes from the DHCPv6 server. There should be only one 6bed4node server at any time, so killing others and removing files stored in the DHCPv6 server setup should work well.

Support / Describe routable prefix

Support [and describe] a mode where a routable prefix is announced in the Router Advertisement; the prefix may differ from the one set with -L and might use -R as an option. It not offer the prefix to the client for StateLess Address AutoConfiguration.

This allows a "uplink" mode of use, where clients to a server network (with its own /64) can route to the server network from a prefix that is not part of the server network. This may be useful with random prefixes such as fdXX:XXXX:XXXX:XXXX::/64 or network prefixes such as fc64:<netid>:<ipv4>::/64 for unconnected local subnets.

Can't make it work

Hi,

I tried to build refimpl-01-alpha2 as well as the master branch of this repo, but didn't manage how to make it work. My environment is Ubuntu/Linux 16.04.3 LTS behind NAT. Once I execute 6bed4peer -def (or 6bed4peer -ref in case of master branch) I get the following output:

6bed4peer[20413]: Bound to UDP port 64070
6bed4peer[20413]: No LAN bypass: Failed to setup multicast: Invalid argument
6bed4peer[20413]: Looking up v6addr fe80::c225:6ff:feb0:7ea6
6bed4peer[20413]: Message of 3776 bytes from neighbor cache, total is now 3776
6bed4peer[20413]: Message of 352 bytes from neighbor cache, total is now 352
6bed4peer[20413]: Message of 20 bytes from neighbor cache, total is now 20
6bed4peer[20413]: Failed to find LL
6bed4peer[20413]: Sent Router Advertisement to Public 6bed4 Service, next attempt in 1 seconds
6bed4peer[20413]: Sent Router Advertisement to Public 6bed4 Service, next attempt in 3 seconds
6bed4peer[20413]: Sent Router Advertisement to Public 6bed4 Service, next attempt in 7 seconds
6bed4peer[20413]: Sent Router Advertisement to Public 6bed4 Service, next attempt in 15 seconds
6bed4peer[20413]: Sent Router Advertisement to Public 6bed4 Service, next attempt in 30 seconds

What can I do to troubleshoot the issue?

Consider the Flow Info to indicate direct peering

According to Section 6 of RFC 2460 and more specifically Appendix A, the experimental facilitation of a Flow Label is meant to keep flows on the same path. For 6bed4, such a choice is possible.

When set to 0, the Flow Label is considered absent and no flow consistency is expected. To manage the flow as a consistent stream, the Flow Label is to be pseudo-random but non-zero. This may be used by a 6bed4peer to choose direct delivery for the data involved. Standards are not up to par with this, so it would be a "software extension" on top of the official specification.

The socket API shares the Flow Label in the sin6_flowinfo field of struct sockaddr_in6 so it can be set when binding or connecting a socket, and when inspecting the local or remote socket address.

Since the transmitted field is 20 bits, and programmers be what they are, there may be no stopping to "initial" code setup with the hexadecimale value 6bed4 in this field :-)

Improve configuration of server address:port

Currently, fixed setting at configuration time, visible in several ways

1. At least use CMake computations from a single entry for address, and for port
2. Possibly make it more dynamic (without sacrificing efficiency!)

Construct the tunnel as a separate phase

Look at what Tayga does, it has an explicit --mktun command to do nothing but creating the tunnel. This is useful to run as root, especially because tools to do this are getting less common in user space.