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? 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.

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)?

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. 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. Other possibly useful references for the topic... An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) https://tools.ietf.org/html/rfc4843 https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/ Cryptographically Generated Addresses (CGA) https://tools.ietf.org/html/rfc3972 Host Identity Protocol (hip) https://datatracker.ietf.org/wg/hip/charter/ Zooko https://plus.google.com/108313527900507320366/posts/jGCh1xZJq88 https://plus.google.com/s/cjdns