Tunneling IP or Ethernet on top of fc00::/8 can easily be accomplished using existing tunneling protocols on top of IPv6. Why re-invent the wheel?
Instead, we could draft a general-purpose tunnel broker protocol designed to run on top of cjdns as an independent service.
The protocol should allow requesting various tunnel types (IP-over-IP, IP-over-GRE, Ethernet-over-L2TPv3-over-IP, ...) to various defined target networks (ARPA-INET, ARPA-INET6, DN42, ...).
A tunnel broker may allow being queried for available tunneling methods and target networks by clients. Maybe having enumerated flags to indicate more exactly what type of connectivity you'll get (e.g. 'behind-nat', 'dhcp', 'ra', 'dhcpv6', 'upnp', 'homenet', 'mdns', ...) and maybe also WHERE in the target network you'll most likely end up (AS#, geo location, ...).
Tunneling IP or Ethernet on top of fc00::/8 can easily be accomplished using existing tunneling protocols on top of IPv6. Why re-invent the wheel?
Instead, we could draft a general-purpose tunnel broker protocol designed to run on top of cjdns as an independent service.
The protocol should allow requesting various tunnel types (IP-over-IP, IP-over-GRE, Ethernet-over-L2TPv3-over-IP, ...) to various defined target networks (ARPA-INET, ARPA-INET6, DN42, ...). A tunnel broker may allow being queried for available tunneling methods and target networks by clients. Maybe having enumerated flags to indicate more exactly what type of connectivity you'll get (e.g. 'behind-nat', 'dhcp', 'ra', 'dhcpv6', 'upnp', 'homenet', 'mdns', ...) and maybe also WHERE in the target network you'll most likely end up (AS#, geo location, ...).
ps: I started using Ethernet-over-L2TP-over-IP and it works quite nicely :) See https://gist.github.com/dangowrt/e65dfde190fb1fcaf05f