making better use of ipv4 space
As of 2023, many ISPs still do not offer ipv6.
Geektards' naming of ipv4 addresses as "legacy" is aspirational, not factual.
No ISP in Guernsey offers ipv6.
Static ip addresses with an ordinary internet connection only cost around 5 GBP(2023) extra, except for the Guernsey vodafone, which quoted me many times that. For those reading from the future, this is around the price of a nice coffee.
Twenty years ago, you could get a /24 from techie ISPs like aaisp or zen, for next to peanuts. The addresses are scarce, but could better use be made of them?
Assumed here is that one wants the internet to be end-to-end, as originally designed, and thus be able to run services from, connect in to, the site with the internet connection.
Let's take as a reference point the fact that one can't really run more than one HTTPS web site from a single static ip at the moment. There are some ways, like a proxy with all the keys, and possibly some horrific pre-starttls item, and by having explicit port numbers in URLs, and not using https because it's pretend and silly, but these are not really "ways".
Let's note that ISP-supplied routers tend to do port-forwarding, of both TCP and UDP, configurable via whatever web interface comes with the router.
The simplest idea is to have a new set of application-level protocols which are defined as using SRV records instead of A records. An A record has an address, and the port number is implicit. An SRV record has an address and port (and a bit more). So each of the 65k ports on the ip address could be used for a different service, without having port numbers in the services' URLs. Pragmatically, for small setups, each service could be configured with a TCP port forward set up on the router.
Some protocols already have this (example: IMAP). Others don't. Examples: HTTP, HTTPS. HTTP(S) is not going to be changed. I suspect a decent transition could be designed, but it's not happening. This doesn't matter, because HTTP(S) has no value, and may have negative value. As a tangent, the objections tend to be things like: well both would have to still work, and we can't add any delay to web clients. Well, both could be queried in parallel, and an A record could be defined as equivalent to an SRV record with port 443, at a set priority and weight, for this protocol. Clients would have to support SRV records before SRV-only web sites would work, and this is strictly bad because it imposes a new requirement on user-agents. But in the case of the web, where real clients are limited to massive proprietary and quasi-proprietary hairballs implementing the very latest JS and other fashions, I don't see why anyone would care. Ending the tangent, it's probably better to just replace the web.
The second idea is to have something with more addresses / networks that runs easily over the current internet. Probably something like this has been tried. The port number in UDP/ipv4 could be commandeered as an extra 16 bits of address, with the invention of some related protocols. Since the customer-connection routers already support UDP port forwarding, if it's done in the right way, it could run over existing connections and equipment. Equipment explicitly supporting the new protocol(s) might be able to do more granular routing, instead of just 65k further networks effectively routed internally via a form of udp encapsulation. The exact number of extra bits after the old port number to also commandeer for extra address space is a tradeoff, because of eating into packet sizes and MTUs, which matters. Hopefully the high-level design is reasonably obvious, even if I haven't spelled things out.
The third idea is connection-broker hack like that described in Could a TCP "connection broker" set up a direct connection between two NATed endpoints? [0]. The idea is that a station "fully on the internet" might be able to fake tcp handshakes so that two stations not fully on the internet can then talk directly to each other. Or perhaps so that a client can "connect in" to something behind NAT, without port forwarding, again utilising the connection-tracking of near-edge router(s) doing the NAT. This might be equivalent. Might also be possible for particular UDP protocols. Hacky, and don't know if such things are possible, but it would be fun to try.
Comments
Post a Comment