7 ms·
With NAT, this has essentially already happened. You could say IPv4 is actually 48-bit addressing, at least on the client side. For all useful purposes, NAT e
by apenwarr 9y ago
With NAT, this has essentially already happened. You could say IPv4 is actually 48-bit addressing, at least on the client side. For all useful purposes, NAT expanded every /24 or even /32 subnet by an extra 16 bits, which is the real reason we still haven't run out of IPv4 addresses.
That could be extended to the server side if we used something like SRV records instead of defaulting to port 80/443.
- jsjohnst 9y agoMaybe it's early and I've not drank enough coffee yet, but what benefit would this provide? You'll be in effect doubling the DNS lookups needed to connect to a website adding latency to time to first byte, with seemingly zero benefit.
- JdeBP 9y agoAs I pointed out at https://news.ycombinator.com/item?id=14721416 https://news.ycombinator.com/item?id=14721416 , the claim of "doubling the DNS lookups" simply does not hold water if actually analysed.
- apenwarr 9y agoThe main benefit would be the ability to offer public Internet-facing services through a NAT, even a carrier-grade NAT that lumps multiple ISP customers behind a single IP address. (You would need some kind of cooperation from the NAT to be able to allow incoming connections on a port range.) JdeBP's post provides a good answer about the SRV records. The short version is a single DNS packet can contain both A/AAAA and SRV responses.
- efreak 9y agoOn another note, I have long wished for something like specifying protocol port numbers in a DNS record. Ever since I ran my first ircd on a shared hosting server, and continuing to today with multiple httpds (nginx, znc, etc) and ircds (ZNC, bitlbee) and such on a single IP. Not for any technical reasons, though--I'm just lazy, and specifying port numbers is annoying.