Direct connections between 6bed4peers

[vanrein]

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.

[vanrein]

This used to be about fd64::/16 only, but it seems that no direct peering is working in 6bed4peer yet. It has been built into Socket6bed4, I think, but was never finished here. There is support for a neighbor discovery queue though...

[vanrein]

Direct peering can be greatly simplified if we don't test that a reply message matches one we sent directly. ICMPv6 can do this, and tricks with TCP semantics improve it further. But...

What we are really after is knowing that the peer does receive our messages. The contents of such messages do not matter, just that it travels over direct UDP/IPv4.

...so it suffices if a peer simply sends a notification that it has received some message from us directly. This can crossover between kinds of messages, so sends and receives do not have to be paired. And we do not need to compare identities and thus avoid sending two ways.

The remaining information is just one bit, and can be an easy stowaway in one of the fixed headers: IPv4, UDP, or IPv6. Specifically, the IPv6 frame always begins with a nibble 6 and never with 4. Let us use4 to mark that we received direct traffic from the addressed peer. Let us make that change after any checksumming of the message, because that is normally done in the application.

WHOA.... This simplifies life and now it is fair to make direct messaging a MUST have in the spec. Also, compatibility improves greatly.

[vanrein]

Every 6bed4peer uses the information of a succeeded transfer for some time, say 25s. Positive information should not be older than 2s and the remaining 3s can be used for rebuilding contact.

We can operate in three modes:

• default would be to send initial messages directly and also via the server. Networks are known to duplicate traffic. We might even compensate for this duplication.
• tam is half-way of a tam-tam mode. It avoids the duplication on the first message sent, and only sends a direct message. In this mode, it is assumed that a failure will cause a resend in a brief time. Every now and then, a failed connection would try again to connect directly. This is a little bit agressive, but lenient in allowing the server to partake in the communication.
• tam-tam excludes the server for all peer-to-peer traffic. When direct communication fails, then so be it. This is a very strong choice, and may impair connectivity until the peer opens his router for actual direct traffic.

These modes can communicate are compatible, so the choice can be made locally. This is helpful to represent personal preferences, personal network setups and different code (networking over a generic interface or dedicated code that is part of an application).

[vanrein]

The practice of Neighbor Discovery between peers continues to be a useful idea. It supports the transmission of traffic for no other reason than to communicate between peers. The flag 6 that turns to 4 is still valid.

[vanrein]

Here is an interesting little protocol:

• Instead of duplicating traffic, the first few messages to new 6bed4peer are sent through the 6bed4router, with a keepalive message to the new peer. (The TTL must then be set to full.)
• After receiving a message over a direct link, a timer is (re)started. For the 2s after this, responses are marked with the 4 nibble. The timer may be restarted at any time when more direct traffic comes in.
• When receiving a message with a 4 nibble over a direct connection, a timer is (re)started. For the 25s after this, messages are sent over a direct link to this peer. The timer may be restarted at any time when more direct traffic with a 4 nibble comes in.
• After the passing of 25s, and no reset of the timer during this period, there are 3s left in the customary 30s delays for trying to receive more direct traffic. To this end, a few keepalive messages may be sent over a direct connection to the peer, perhaps 1s apart, allowing 3 attempts after 27s, 28s, 29s.
• After 30s without outgoing messages and without incoming 4 nibbles, a peer may be removed from the neighbor cache. When a message comes in with a 4 nibble set, a new entry may be made in the neighbor cache with the timer setup accordingly. This mirrors the operation in the reverse direction, which uses the other timer.
• Keepalive messages are empty UDP messages. They have no 4 nibble so they can restart the timer that indicates having seen traffic, but they will not relay the local timer status. As a result, connections are not automatically kept open when no messages pass through.