based Reticulum address decentralized IP address, Abolish ipv4 and ipv6 #403
Replies: 7 comments 8 replies
-
|
Does IANA control how we use link-local addresses? |
Beta Was this translation helpful? Give feedback.
-
|
Only for the sake of compliance. If I'm airgapped, I can use anything I want. If I want to interface with the Internet with collisions, I have 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12 as my playthings. Just if you're using someone else's hardware, you play by their rules. And the Internet is someone else's hardware. |
Beta Was this translation helpful? Give feedback.
-
Yes, IANA does control how we can use link-local addresses, as all other addresses, because the base premise of the entire IP system, that they are administrating, is that every address outside of their hierarchical control are non-interoperable. You can build as many local networks or "own-nets" as you want, but they will never interlink with each other in any meaningful way.
Yes. This exactly. |
Beta Was this translation helpful? Give feedback.
-
|
The only problem I see is how Reticulum generates hashes that are used as addresses. I don't know if it guarantees that they are unique. You're free to use any IPv4 or IPv6 addres in a system that isn't connected to the internet, but with such large and complex network, you need someone who will make sure that address is really unique. IANA delegated the blocks to lower organistaions and they delegate to ISPs, large companies... Every member of the chain only needs to check thet addresses inside their block(s) are uniquely assigned and it's divide-et-impera. When it comes to link-local addresses, private IPv4 address and some other special blocks, IANA prescribed guidelines for usage of that blocks and we should adhere to them if we want our network to be 100% compatible with internet. If we don't adehere, that doesn't mean our network won't work or we'll get fined. |
Beta Was this translation helpful? Give feedback.
-
|
Now you solved my mistery from day 1. It just relies on randomness of a cryptographic function. 128 od 256 or whatever number, it doesn't matter as long as there is no checking. We won't run out of 128 bit address space if we use them as IPv6 and put some limits how certain numbers (addresses are number after all) will be used. If we use them randomly, we might face the problem sooner. |
Beta Was this translation helpful? Give feedback.
-
|
Your requirement is impossible to fulfil under any circumstance. By placing the key in a certain range, you increase the chance of collision. A central authority can's promise nothing is provisioned in its absence. Solutions like blockchain simply move the goalposts to having "authority" being whoever can corner the market or you end up with the Red Queen's Race, with more and more computing power doing less and less. Querying the network would require an instant response from every device on the network and nearly infinite computing power. Could you imagine if when you powered on your computer you can to query every single network attached device on the Internet? If your application requires such certainty, it will not work. Period. No amount of mental gymnastics or combination of words will make it possible. If you believe that to be incorrect, try to implement it yourself. No matter the solution, it will fail. Catastrophically. It will also undermine the entire point of a random identity. Look into the differing modes of UUID to see exactly the kind of security risks when you begin to embed metadata and restrictions into a hash function. In fact, why don't you just use UUID-7? You'll run out of space much faster, but you can have reasonable certainty until your network produces multiple identities per second, then you'll have immediate collisions. Other variants will have even better resistance than UUID-7, but will tell people your MAC address or similar personally identifying information. All of this has a much higher chance of collision than the current methods used, along with substantially more risk of unintended and catastrophic consequences. Due to the exceedingly low probabilities and the local routing systems built into Reticulum, this isn't an issue. If you want to implement something novel, please do so. It's always helpful to see something new, but if you're interested in replacing so much of Reticulum, perhaps you should ask yourself if you want to use it at all. |
Beta Was this translation helpful? Give feedback.
-
|
I do like reticulum, but this isn't changing everything. |
Beta Was this translation helpful? Give feedback.
-
|
A primary aim of the Reticulum project is to explore what an Internet would look like if the foundational protocols made no accommodation for hierarchy. Reticulum assumes every peer on the network is potentially hostile, and every link is potentially compromised--even peers and links that you control. It trades a very slight chance of a hash collision for the gain of being not just completely decentralized, but uncentralizable. The whole point is it cannot be centralized. There can be no central server that maybe the operator of chooses to start charging money to use, gives up on maintaining, intentionally shuts down to deny service, or discovers a way to use their central function to conduct surveillance. When control is delegated, it becomes power that can be abused. This is a fundamental design characteristic of Reticulum. |
Beta Was this translation helpful? Give feedback.
-
|
Acehoss said it better than I could. Let me simply enumerate the mechanical issues. You need a centralized authority over a network (bad) and one that has authority to give authority (worse) and we're back to TCP/IP. Identities and addresses are no longer portable over all networks, you're locked under one control authority. Since hashes are, by design, difficult to predict, you'd have to generate multiple, perhaps thousands, of new addresses to see if they fit in the proper namespace. If you simply truncated the hash and added a preamble, you break the ability to know every address of an identity simply by knowing the identity, Remember I can have the same identity running lxmf.delivery in Utah and user_app.messaging in Moscow and the network will handle it, but they certainly wouldn't be on the same authoritative network. If an authoritative node goes down, it orphans its clients. The decision of what happens to them, if there's a backup, or if other nodes still pass their traffic is non-trivial and dead nodes will clutter the namespace for no benefit. Such authoritative names will have the same issues as IP addresses, being linked to network topographies or even local regions, and as such opens up the user to identification or address bands being rejected for purposes of censorship or simple pettiness. As Acehoss said, this decentralization and failure tolerant mesh networking is as central a part of Reticulum as the encryption is. Believe me, I've wracked my brain about how to make it as easy to find a server as using DNS, but it's nearly impossible without a central authority. There's the (currently offline due to unhandled threat vectors) Amber Pages, but even that required someone to find the Between the Borders node and trust it (in a meat trust way, not a Reticulum trust way) for it to be useful. If you need something to be unique, just check to see if it's already in your database with a different public key, and discard it if it is. It almost certainly won't happen in your lifetime, but that's the only certainty there is. |
Beta Was this translation helpful? Give feedback.
-
That's the great thing, you actually don't. You just need a large enough address space, and system that maps secrets (X.25519 private keys) to public endpoint addresses (Reticulum destination hashes). That system is defined here and here. Most people have a really hard time grasping exponential math, and for good reason. It's not intuitive for humans - until you sit down and actually try it out on a piece of paper, a calculator, or whatever you prefer. On a very small piece of paper, you can write a number that can index every possible thing in the entire observable universe. It's easy, here you go: There's enough room in that number to uniquely index every elementary particle in the observable universe. And that's even in decimal! How inefficient! A binary representation will only take up 283 bits. For even incredibly complex, planetary-scale networks, the 128-bit address space of Reticulum is completely sufficient to provide statistically collision-free operation with billions of new addresses created every day. For bizarrely large networks that are way out into the realms of the future and sci-fi, we can literally just flip a switch and go to a 256-bit address space, which can accommodate every possible thing in our entire galaxy. Reticulum provides much better assurance of a collision-free address space than a centrally controlled one like IP, where it actually can (and regularly does) happen, simply be the merit of people in control of the space deciding to hijack addresses on behalf of government subsidiaries, or by other (just as nefarious) mechanisms, such as BGP hijacking. No centralised control is needed. I cannot reiterate that enough. Apparently, entropy is much better at managing things than bureaucracy. Now that's a thought to ponder, huh? |
Beta Was this translation helpful? Give feedback.
-
There is what you call "checking", just not in the way you assume it has to occur. First, and most importantly: Play around with, and understand probability dynamics withing very large sets. Then, I'll recommend you read this. When you understand what is going on there, and why, I promise you will see the light, and hear some choral music ;)
No. |
Beta Was this translation helpful? Give feedback.
-
|
And just for anyone reading in the future, even in the nearly impossible event that an address space collision does occur, Reticulum does have provisions in the code to deal with it, and only announces from the destination that came first will be accepted by the network. So if you really want to make sure that a collision didn't happen when creating new destinations, you can just query the network and check if the returned Identity for a destination matches the one you just generated. If not, you managed to find a collision, and I will most definitely buy you a round of beers. I'm pretty sure we should even have some sort of commemorative party for that occasion :) |
Beta Was this translation helpful? Give feedback.
-
|
And points to @Pantyhose-X for sparking this discussion without even really receiving any replies to your original question ;)
Yes, this is a fundamentally important issue, and was one of the main problems I specifically wanted Reticulum to solve.
Yes! And this is actually what we have, right now. Reticulum destinations are those addresses, and you can start replacing other systems with them today, but it will take some effort to write new programs and applications that work within the context and possibilities of Reticulum, instead of IP. There's no reason to simply "jank out" IP alltogether, and replace it entirely - not yet. At least not in all situations. To be fair though, I like the idea of Reticulum-only systems a lot myself, and have a few of those just for experimentation. But a lot of people will still need and want to use IP-based programs for a long, long time. That's why Reticulum can coexist, on the same hardware as IP-based programs without any issues. It's your choice. Run a mixed system, or something that is Reticulum only. I put a lot of thought into designing Reticulum in a way that would allow for a gradual transition to Reticulum-based networks, even globally, if that time comes at some point. All the hardware running the backbones of the current Internet can potentially run a Reticulum stack as well (or exclusively), and in such a case the global Ret can form organically and at any pace, slowly or rapidly. And any person on the planet can interconnect with it, either by accessing native Reticulum channels from somewhere, or by just tunneling a Reticulum connection over the IP-based internet to somewhere that has connectivity. All of this is possible now. Sure, there is still a lot of work to do in terms of performance, ease of use, variety of implementations, and very importantly, actual applications using Reticulum. Things will take time, but we're getting there :) |
Beta Was this translation helpful? Give feedback.
-
|
Implementing Reticulum with hash addressing for decentralized IP addresses and abolishing IPv4 and IPv6 would introduce several key features to the internet infrastructure:
Overall, adopting Reticulum with hash addressing for decentralized IP addresses presents an opportunity to create a more secure, private, and censorship-resistant internet infrastructure. |
Beta Was this translation helpful? Give feedback.
-
|
It would also be useful to have a built-in overlay network to connect reticulum addresses over the existing Internet, without having to run an i2p daemon. I bet this would be valuable for many situations and threat models even if it did not offer i2p's anonymity features. (This is how I initially read the OP, though they might have been saying something different.) |
Beta Was this translation helpful? Give feedback.
-
THE IDEAL PATH
What if we replace the controlled and surveilled IP addresses with new internet addresses that are based on Reticulum address? These addresses will inherit all Reticulum address features, i.e., they will be purely decentralized, secure, future-proof, robust, anonymous, unhackable, controlled by no single authority and many more.
Is it just a dream? For now. If this could be true we would be changing the internet as we know it.
win10 network adapters : Enter the Reticulum address
Wi-Fi DHCP Static : Enter the Reticulum address
IPv4 and IPv6 are centralized. They are controlled by national companies, etc.
Try to Google “Who controls IP addresses?” You’ll promptly get “IANA: the Internet Assigned Numbers Authority.” IANA is the top authority behind IP address allocation and assignment. There are five different regional internet registries (RIR) with jurisdiction under the IANA.
As a matter of fact, as an individual or a normal internet user you cannot request IP addresses directly from IANA or one of the five RIRs, but only from internet service providers, such as the services offered by mobile or telecom operators.
Beta Was this translation helpful? Give feedback.
All reactions