5 ms·

That's like saying IP addresses are stupid technology of the past century.

iod 10y ago
If by that you mean IPv4, then yes.
runeks 10y ago
They are. Nodes on the internet should be identified by public key hashes, not IPs. Whoever can respond to a packet with a message, whose signature verifies against the public key that it's destined to, is by definition the recipient. Servers would have relatively static keys, while client keys could be as ephemeral as wanted. So rather than specify an IP address (location) as destination, you specify the recipient, by encrypting a request with eg. Google's SSL public key, signing it with your public key, and delivering it to something that will route this packet to Google (at whatever IP address that may be), so they can decrypt it, and produce a packet encrypted with your public key.
- jrockway 10y ago
  IP addresses have nothing to do with identification. As the name implies, they're for addressing.
  - runeks 10y ago
    My point is that, with cryptography, they are redundant. If all traffic on the internet is encrypted, why do I need to both encrypt a packet such that only a single recipient can read it and specify an address? Any node on the path to the recipient could do a lookup and find Google's IP address, the client doesn't really need to.
    - wfunction 10y ago
      Huh? Then you have to send "google.com" as a string instead of its IP address, which doesn't have any benefits, and can even change meaning during the time the packet is traveling... not to mention that it'd flood the DNS servers for no good reason.
    - jrockway 10y ago
      I don't understand how your system would work with any sort of reasonable performance. How do upstream routers know which network to forward your packet to? The reason BGP works is because address spaces are delegated to "autonomous systems". The authority over the address space delegated to an autonomous system doesn't change very often, therefore only systems close to a packet's destination need to be updated with respect to routing changes on a regular basis. Systems farther away have a basic and infrequently-changing idea of how to interact with that ASN, i.e. your ISP doesn't really care what Google's network is doing, it knows how to get your packet closer to Google, and that's all. As the packet gets closer to the destination, those systems know more about Google and less about your ISP. Thus, we have an actual distributed system' the information each network needs to store and maintain is limited, but there is still much flexibility allowing the network to self-repair damage. Certainly, networks can work without any delegation in this form; tor's hidden services show that this can work in practice. Pretty slow though. Reasonable performance (and accuracy) depends on not having every node on every network know the correct route to every other node, or having nodes have to reach a consensus (slow) on where to forward your packet at each hop. What's your plan for that?
- deadbunny 10y ago
  I guess you've not thought about routing...

iod 10y ago

If by that you mean IPv4, then yes.

They are. Nodes on the internet should be identified by public key hashes, not IPs. Whoever can respond to a packet with a message, whose signature verifies against the public key that it's destined to, is by definition the recipient. Servers would have relatively static keys, while client keys could be as ephemeral as wanted. So rather than specify an IP address (location) as destination, you specify the recipient, by encrypting a request with eg. Google's SSL public key, signing it with your public key, and delivering it to something that will route this packet to Google (at whatever IP address that may be), so they can decrypt it, and produce a packet encrypted with your public key.

jrockway 10y ago
IP addresses have nothing to do with identification. As the name implies, they're for addressing.
- runeks 10y ago
  My point is that, with cryptography, they are redundant. If all traffic on the internet is encrypted, why do I need to both encrypt a packet such that only a single recipient can read it and specify an address? Any node on the path to the recipient could do a lookup and find Google's IP address, the client doesn't really need to.
  - wfunction 10y ago
    Huh? Then you have to send "google.com" as a string instead of its IP address, which doesn't have any benefits, and can even change meaning during the time the packet is traveling... not to mention that it'd flood the DNS servers for no good reason.
  - jrockway 10y ago
    I don't understand how your system would work with any sort of reasonable performance. How do upstream routers know which network to forward your packet to? The reason BGP works is because address spaces are delegated to "autonomous systems". The authority over the address space delegated to an autonomous system doesn't change very often, therefore only systems close to a packet's destination need to be updated with respect to routing changes on a regular basis. Systems farther away have a basic and infrequently-changing idea of how to interact with that ASN, i.e. your ISP doesn't really care what Google's network is doing, it knows how to get your packet closer to Google, and that's all. As the packet gets closer to the destination, those systems know more about Google and less about your ISP. Thus, we have an actual distributed system' the information each network needs to store and maintain is limited, but there is still much flexibility allowing the network to self-repair damage. Certainly, networks can work without any delegation in this form; tor's hidden services show that this can work in practice. Pretty slow though. Reasonable performance (and accuracy) depends on not having every node on every network know the correct route to every other node, or having nodes have to reach a consensus (slow) on where to forward your packet at each hop. What's your plan for that?
deadbunny 10y ago
I guess you've not thought about routing...