On 4/30/16, str4d str4d@i2pmail.org wrote:
On 27/04/16 22:31, grarpamp wrote:
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
Thanks str4d, I think I remember that one.
There''s certainly a difference between underlying cryptographic addressing, and human "DNS style" naming. Onion addresses, even at 16 char or 80 bit, were always beyond most human scope. I'm not too concerned about human addressing since that can always be a layer in userland (though not as strong as something tracing back to the underlying crypto), of course if it comes along with any side layer deemed necessary for getting the crypto addressing working between nodes under IPv6, that's a good bonus.
But the tor-onions mailing list is to discuss the technical details running onion services.
Fyi, I'm still waiting to hear back on the status of the onioncat list.
onioncat. It's a way to get non-TCP between TorHS onions, thus in the thread "Hidden datagram service".
I think there are a nontrivial number of users interested in, and using, non-strictly-TCP transport over an IPv6 tunnel interface. For example, look at users of CJDNS...
For which we should try to continue a way, in v2, to do that over anonymous overlay network Tor / I2P.
There is already some work on doing this in I2P:
https://github.com/majestrate/i2p-tools/tree/master/i2tun https://github.com/majestrate/i2p-tools/tree/master/pyi2tun
I2P also natively supports non-TCP protocols if that helps (only datagrams implemented thus far).
You mean just UDP? How would you move ICMP, GRE, raw IP/packets? Do you have to implement each one? That seems more work than implementing a generic data conduit, or an IPv6 conduit (as a more specific, host stack oriented, interoperable form). Though yes UDP would be the most useful for people after TCP.