Undernet IPv6 Interop [was: Enigmabox/cjdns]

[grarpamp]

On Thu, Oct 24, 2013 at 6:53 AM, Eugen Leitl <eugen at leitl.org> wrote:
> ----- Forwarded message from Caleb James DeLisle <cjd at 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