*** John Goerzen [2022-01-17 14:23]:
>It would be great if these two modes of operation were compatible.  That
>is, if you run a node with the embedded code, you could connect to it
>with the traditional (TCP to an IPv6 address) code.

Ah, I see! I misunderstood you previously indeed.

Well, today I replaced μTP transport with full IP+TCP networking stack
implemented by gvisor.dev/gvisor. It works slightly faster than μTP, but
anyway much slower than direct ordinary TCP.

I think that is because of the Yggdrasil's code itself: it is very
simple and compact (that is good), but I noticed much memory allocations
and copying, that probably is the source of the problem. Anyway it means
that I just can not saturate gigabit link now.

That gave ability to use ordinary IPv6+TCP over Yggdrasil's PacketConn
interface. But it does not give ability to connect to the derived IPv6
address. Diving in the Yggdrasil's source code (that is really pretty
simple and small!) showed me that I also had to process special
out-of-band packets asking for my Yggdrasil node's full 256-bit public
key, that is related to given 200/7 IPv6-address. Without that, I was
only able to listen on ordinary TCP socket on 200/7 address and connect
to it with nncp-call "yggdrasil:" with explicitly provided full public
key. Yggdrasil's PacketConn interface really works only with full
ed25519 public keys as addresses. IPv6↔ed25519 resolution is completely
separate work pipeline.

Except for increased code size (well, now we are dealing with the full
IP+TCP network stack in Go!), the only danger is that Yggdrasil's
out-of-band packet types are not exported constants in its module
(typeKeyDummy, typeKeyLookup, typeKeyResponse in
yggdrasil-go/src/ipv6rwc/ipv6rwc.go), so I had to copy them, that won't
give guarantees that if next Yggdrasil's version won't change them.

>Client with embedded Ygg -> server with embedded Ygg
>Client with embedded Ygg -> server with standalone Ygg
>Client with standlone Ygg -> server with embedded Ygg
>Client with standlone Ygg -> server with standalone Ygg

Yes, all that cases should work now with my currently uncommited code.

>There may be
>reasons a person would want to run Yggdrasil standalone.  For instance:
>[...]

All of that valid points! Seems they are good to be included in
documentation.

>Ideally, one should be able to move a keypair from yggdrasil.conf to
>nncp.hjson (or the reverse) and keep operating as before with zero
>changes to clients.

That should work fine.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF