Next: EBlob format, Previous: MultiCast Discovery, Up: NNCP
NNCP is able to act itself as a client to Yggdrasil overlay network. Current IPv6 adoption for home users is relatively bad in many countries. That is why Yggdrasil overlay network uses dynamic spanning tree mesh network for packets routing, making it useful for gaining hosts high availability reachability without complex manual manipulations. By default it creates 200::/7 IPv6 network, where each host’s address is derived from the corresponding public key.
NNCP’s Yggdrasil support is fully based on and resembles the idea taken from yggmail software, that does not use Yggdrasil’s full-featured IP tunnelling capabilities, but rather uses it only as a generic packet transmission network, greatly simplifying the whole setup, without necessity to setup separate networking interface and operating system’s routing tables with firewall. μTP transport protocol is used over Yggdrasil’s packet interface – it is relatively simple and efficient enough.
No separate explicit Yggdrasil daemon installation is necessary, however you should be able to interoperate with it too, using for example as an entry point to the global Yggdrasil network. You can reuse already existing Yggdrasil network, without colliding with its IP tunnelling features.
Only minor modifications were done to current NNCP’s tools:
yggdrasil:
addresses, pointing to the desired Yggdrasil’s public
key (that also acts as the destination host’s address). Yggdrasil
background goroutine is automatically started, connecting to the
specified Yggdrasil entrypoints and making μTP connection with the hosts
and initiating NNCP’s native online protocol handshake on
top of that.
yggdrasil-aliases
map.
How to start using NNCP through that overlay network?
$ nncp-cfgnew -yggdrasil Public: 4fd64130e23cf7abdbc0fabdf2ae12bbc2ab7179861efa296d2beb0181ae07ea Private: 571fb05c81e62a572096566fd48e87ad47e706b1f600dd625ebbf86d310332624fd64130e23cf7abdbc0fabdf2ae12bbc2ab7179861efa296d2beb0181ae07ea
You should share your public key with other NNCP peers.
PRV;BIND[,...];[PUB,...];[PEER,...]
, where PEER
is in
Yggdrasil’s URL format, like tcp://HOST:PORT
or
tcp://HOST:PORT?key=PUBKEY
.
$ nncp-daemon -yggdrasil "571f...07ea;[::]:1234,[::1]:2345;;tcp://some.peer?key=ITSPUBKEY"
Here we did not specify any allowable public key – anyone can connect
to us and route packets through. As you can see, private key is in
command line arguments, that could be treated as a security issue. That
is why it is preferred to specify them in
configuration’s yggdrasil-aliases
section, where you can alias all of entities and reference them in
-yggdrasil or yggdrasil:
-addresses:
yggdrasil-aliases: { myprv: 571f...07ea bindPublic: [::]:1234 bindLocalhost: [::1]:2345 peerBE: tcp://some.peer.be?key=BEPUBKEY peerRU: tcp://some.peer.ru?key=RUPUBKEY defPeers: peerBE,peerRU remoteAlicePub: 52be...3c14 }
And now you can more conveniently and safely specify:
$ nncp-daemon -yggdrasil "myprv;bindPublic,bindLocalhost;;defPeers"
yggdrasil:
-address, that takes remote host’s public key, our
host’s private key and list of Yggdrasil peers entrypoints. Similarly to
-yggdrasil option, it is ";"-separated list too:
$ nncp-call alice "yggdrasil:remoteAlicePub;myprv;bindLocalhost,tcp://some.other.entrypoint"
Next: EBlob format, Previous: MultiCast Discovery, Up: NNCP