On 1/24/19, Christian Huitema <huitema@huitema.net> wrote:

If you want real integration with IPv6 addressing, the crypto systems can really only use 64 bits. The top 64 bits are claimed by the routing system, and the network providers just won't let you put something arbitrary there. That's a big issue, because if your cryptographic proof of ownership relies on matching 64 bits, then it is not much of a proof.

Depends on if and to what extent one needs or wishes to speak to the clearnet hardware that currently exists... " Yes, one cannot rationally overload all 128 bits for that without colliding upon allocated IPv6 space that may appear in one's host stack. However the 1:1 key network can be larger than 64 or 80 bit. One could easily play with up to say 125 bits by squatting on entirely unallocated space. (Unlike the clear mistake CJDNS made by squatting on space already allocated for a specific and conflicting real world in stack purpose.) Obviously the common library widths of 96 and 112 could be keyed. And request could be made for a formal allocation if compatibility and compliance was felt needed by some mental gymnastics. https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia... https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unica... " Agreed, going from say 64 to 125 bits is not the huge or universally strong and ideal leap that could be sought for. And there is the question of secure levels and offloading (or onboarding as it may be)... at what level would many users perhaps choose to share their cat pictures... 64, 80, 120, 512? And their finances, affairs, work, email? Were a slider to exist, where would offloading bulk traffic, of any given content or purpose, end up being set, and start to occur? How would you run each as needed? Do you need a future 8192-bit IPvN in backbone routers and host stacks to achieve certain strengths and utility goals? Or can you do it some other way?

The CGA specification (RFC 3972) tried to mitigate that by introducing the "SEC" field. It tries to make the proof harder by specifying a number of matching zeroes. There is a tradeoff there. We wanted to encode the number of zeroes in the address itself: we feared that doing otherwise would make address spoofing too easy. But we were also worried about birthday paradox issues. Each bit allocated to the SEC field is one fewer bit available to differentiate the addresses of hosts on the same network. The compromise was to pick a 16 bit granularity. ...

For reference... https://tools.ietf.org/html/rfc3972

... Bottom line, back in 2005 we had high hopes that CGA would enable all kinds of security improvements, be it end-to-end IPSEC or secure IP Mobility. That did not happen, and hardly anybody uses CGA today. Lots of the work was done at Microsoft Research, but Microsoft never found a real reason to deploy CGA in Windows. The real reason is that 64 bits is too small for crypto.

ORCHIDv2 is also commonly noted... https://tools.ietf.org/html/rfc7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.