Forwarded with permission. ---------- On 10/24/2013 02:35 PM, grarpamp wrote:

On Thu, Oct 24, 2013 at 6:53 AM, Eugen Leitl <eugen@leitl.org> wrote:

...

----- Forwarded message from Caleb James DeLisle <cjd@hyperboria.ca> -----

...

I'm not really worried about what the IETF has to say

Nor am I really, even to the point of stealing an unused external IPv6/3 since it is unlikely all of them will ever be allocated. My thoughts are more about what I outlined in the last two paragraphs... that things like the userbase draw of existing applications, inclusive multihosting and participation in more than one net easily at the same time (whether general purpose IP transport, or specfic like file storage [1])... can and do matter. The simplest way I've seen yet that covers those areas is an internal IPv6 layer presented on the host's tunnel interfaces. So what are some means we can make to fit a world's population worth of users, out of much larger crypto keyspaces, into about 115 bits?

[1] Imagine a link in a web page, file://<IPv6>/<internal_file_key>, where <IPv6> is just a point-to-point tunnel bound to a particular filestore like GNUnet, ed2k, tahoe, etc.

...

at some point I'll probably add an option to use IPv4 for cjdns too. Applications won't even have to support IPv6 to support cjdns.

Keeping in mind that people need to be clear when/what they are referring to: - external addressing, used by the host/net on the public internet (IPv6, IPv4) - internal addressing, the user facing overlay addresses (IPv6, onion, i2p, etc) - maplayer addressing, map between crypto widths to narrower internal addressing

Why would anyone want to use IPv4 internally? It's only 32 bits, easy to generate/spoof a crypto based address collision. And only a handful of its tiny /8's (ie: 10/8, 16M users/nodes) could be used on a host's tunnel interface that would not conflict with external addressing. Further, every OS, and most applications users want to use, are already IPv6 enabled, such that using them with internal IPv6 addressing via the host's tunnel interface to that is not a problem.

...

When you do a DNS lookup for a site it will allocate an address for that machine out of whatever block you choose.

Please rephrase. What allocation method, from what address space (v6, v4), and for residence on the external or internal network? Via what interface? DNS lookup to external or internal DNS server? And for an internal or external site?

IPv4 in cjdns is actually really easy, you just need a mapping table inside of the node. Say you put in your configuration that 11.0.0.0/8 is for mapping. Cjdns will assign 11.0.0.1/8 to your TUN device then whenever you do a DNS lookup, it grabs the next number in the sequence and maps that to the key which is returned by the lookup. It could also map addresses to incoming connections from previously unseen keys allowing you to be a server too. It just breaks p2p stuff which shares IP addresses. This same idea could be used to map any number of different networks into a common IPv6 (or IPv4) address space.

I do see FC00::/8 addresses returned from queries to external nameservers. Leaking that activity externally can be unwise, so if a DNS for internal addresses is needed it should be run internally.

It's on the todo list. Not because we're trying to keep secrets or prevent web crawlers from firing syn packets off into ISP null routes but because the public domain system is expensive and an SPOF.

...

As far as address generation speed, the address is a double-sha-512 of your public key so it's extremely fast.

Ok, so a few seconds to generate 8 matching bits (into FC00::/8)?

On small hardware yes, on my laptop it feels instantanious.

...

Anything less than 128 bits (you're forced to collide the last 8 bits) would be dangerous. I'm sure we could have decided to limit valid keys to a fixed 16 bits or maybe even 24 but 48 bits would be quite unreasonable to expect of small devices.

I think this is in reply to one of the possible means to fit within a compatible IPv6 bit width. I think Eugens' forwarding style may have lost me some context there :) Not sure where to place this or how to read it.

We're used to disliking anything less than 128 bits for symmetric (streams, message encryption, etc). But for network ID's there's probably a reasonable case to be made for using somewhat less than that... you should use TLS, message encryption, fingerprints and other means over any network anyways, just in case something breaks.

The IPv6 address is effectively the key fingerprint because x509 is a mistake the world should never make again and colliding an IPv6 gives you spoofing ability as well as MiTM.

For reference, the five nets I referred to are: cjdns, i2p (garlicat), tor (onioncat), anonet, phantom Maybe there's a GNUnet interface in the works but I've not seen it yet.

I'm going to sound like an asshole here, probably because I am.. but every one of those systems with the exception of cjdns is heavily geared toward anonymity, privacy, freedom and individualism. Cjdns is designed to facilitate community and I've found the most divisive, manipulative and egomaniacal people ever to grace the Hyperboria community subscribed to just those values. At this point when I hear TOR user, I think "oh shit another one" so while it's not really my right to intentionally break valid use cases, I'm not feeling like putting a lot of effort into making interop work. Thanks, Caleb BTW: it looks like the IPv4 mapping idea I proposed might come sooner than I thought because Apple seems to have broken IPv6 support in Mavericks update. ----------