3 ms·

If you want to have larger addresses you need to make changes to anything that assumes addresses are 4 bytes. Whether you make them 6 bytes or 8 bytes is irrele

by geocar 11y ago

If you want to have larger addresses you need to make changes to anything that assumes addresses are 4 bytes. Whether you make them 6 bytes or 8 bytes is irrelevant. Most of the internet knows how to route 4 bytes, but if I want to add new nodes, and there are only 8 billion people on the planet, surely between me and my neighbour we can share an IPv4 address -- and in fact we are with NAT, but you can't address a single device that I control -- you can only address the NAT machine, make sense? That's actually okay though, because the only reason the NAT box can't forward the packet to my home server is because it doesn't know that's what you meant: It only knows about 4 bytes. If we teach it about 16 bytes, then it will have no problems. The trick is, we overlap the upper 4 bytes with IPv4: This means most of the routing infrastructure (that doesn't need to know the difference between my home server and my router) can remain unchanged. This is (in fact) most of the Internet. However an application that wants to access my server still needs to be updated. Web browsers went through a similar problem, but they didn't use nat, they relied on the fact that the hostname could be used to identify the service. In this way, the DNS hostname which map to an IP address can be reused to address a specific web site. This information is stored in HTTP in the Host: header and in HTTPS in the SAN (subject alternative name field). The "router" (in this case usually called a web server or a proxy server) can route to the appropriate resource using this information. This didn't happen immediately though: For a long time, many web browsers didn't use the Host: header, so before people could rely on the Host header to distinguish services, web browsers needed to be updated. Not all of them, but enough web servers configured to remind users to upgrade their web browser eventually did the trick, and it didn't take twenty years either. What I proposed is a general mechanism for doing this: to simply extend the address space at the application level. We could have done it in the operating system -- say with a socket option, and I think it would still be faster than IPv6. Does that make sense?

zAy0LfpBZLC8mAC 11y ago
Well, yeah, I think I understand what you propose ... but I don't really see the point of it. I mean, where is even any significant difference to IPv6? Yeah, you could use the IPv4 routing infrastructure for transport of this new protocol. That's also known as tunneling. You can do that with IPv6. Even with automatic assignment of addresses based on IPv4 addresses you already have, that's called 6to4. And while that was a nice idea for a transition mechanism (and in the form of 6rd still usefully employed by some ISPs), it's not really that useful in the long term, as backbone routers have been IPv6 capable for a long time, simply due to upgrades for higher bandwidths. To take a random example: Peak bandwidth at AMS-IX in 2002 was 12 Gbit/s. Now, it's 4.2 Tbit/s. And they didn't do that by multiplying the number of routers by 350. Your analogy to HTTP and TLS also doesn't really hold up: Both are protocols that are only implemented at the edge of the network and pretty much only in software that is easy to update, while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by. Also, it's not actually true that the v4 routing infrastructure wouldn't need to know the difference between your server and your router. What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. How would your translation gateway know which inside address to forward it to? Or how about a fragmentation needed message? Should we break PMTUD for good?
- geocar 11y ago
  > I don't really see the point of it. I mean, where is even any significant difference to IPv6? IPv4+ solves the same problems that IPv6 does, is much simpler than IPv6, is cheaper than IPv6, and could have been deployed in less time than IPv6. If we're going to learn from IPv6, then that means studying things like IPv4+. Note I'm not suggesting we stop IPv6 efforts: I used to say that, but that's only because I think we'll have a 50% solution in another ten years, and IPv4+ could take up to ten years if we had consensus. > while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by. If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it. This is very similar to the challenges that upgrading HTTP and HTTPS do had. Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT. > addresses based on IPv4 addresses you already have, that's called 6to4 6to4 is a lot more complicated than IPv4+. It was harder to deploy, and building on IPv6 instead of IPv4 was probably a mistake. If we don't consider the complexity of the implementation, 6to4 still took much longer to be suggested than IPv4+ (or similar) was. > What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.
  - zAy0LfpBZLC8mAC 11y ago
    > If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it. What does "your users need to support IPv4+" mean? What does it take to make a "user" support IPv4+? > Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT. Yeah, the same as with IPv6/v4 dual stack. > NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT. No, it doesn't, no, it's not. ICMP error messages contain the first 8 bytes of the packet that couldn't be delivered, which in the case of TCP and UDP contains the port numbers, which a TCP/UDP NAT uses to NAT the ICMP messages. And broadasting is not an acceptable solution because delivery of ICMP messages happens to sockets, not to machines. If you deliver ICMP UDP port unreachable messages to all sockets in the respective IPv4+ address range where the port happens to match, that's going to cause chaos.

by geocar 11y ago

zAy0LfpBZLC8mAC 11y ago

Well, yeah, I think I understand what you propose ... but I don't really see the point of it. I mean, where is even any significant difference to IPv6? Yeah, you could use the IPv4 routing infrastructure for transport of this new protocol. That's also known as tunneling. You can do that with IPv6. Even with automatic assignment of addresses based on IPv4 addresses you already have, that's called 6to4. And while that was a nice idea for a transition mechanism (and in the form of 6rd still usefully employed by some ISPs), it's not really that useful in the long term, as backbone routers have been IPv6 capable for a long time, simply due to upgrades for higher bandwidths. To take a random example: Peak bandwidth at AMS-IX in 2002 was 12 Gbit/s. Now, it's 4.2 Tbit/s. And they didn't do that by multiplying the number of routers by 350. Your analogy to HTTP and TLS also doesn't really hold up: Both are protocols that are only implemented at the edge of the network and pretty much only in software that is easy to update, while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by. Also, it's not actually true that the v4 routing infrastructure wouldn't need to know the difference between your server and your router. What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. How would your translation gateway know which inside address to forward it to? Or how about a fragmentation needed message? Should we break PMTUD for good?

geocar 11y ago
> I don't really see the point of it. I mean, where is even any significant difference to IPv6? IPv4+ solves the same problems that IPv6 does, is much simpler than IPv6, is cheaper than IPv6, and could have been deployed in less time than IPv6. If we're going to learn from IPv6, then that means studying things like IPv4+. Note I'm not suggesting we stop IPv6 efforts: I used to say that, but that's only because I think we'll have a 50% solution in another ten years, and IPv4+ could take up to ten years if we had consensus. > while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by. If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it. This is very similar to the challenges that upgrading HTTP and HTTPS do had. Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT. > addresses based on IPv4 addresses you already have, that's called 6to4 6to4 is a lot more complicated than IPv4+. It was harder to deploy, and building on IPv6 instead of IPv4 was probably a mistake. If we don't consider the complexity of the implementation, 6to4 still took much longer to be suggested than IPv4+ (or similar) was. > What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.
- zAy0LfpBZLC8mAC 11y ago
  > If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it. What does "your users need to support IPv4+" mean? What does it take to make a "user" support IPv4+? > Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT. Yeah, the same as with IPv6/v4 dual stack. > NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT. No, it doesn't, no, it's not. ICMP error messages contain the first 8 bytes of the packet that couldn't be delivered, which in the case of TCP and UDP contains the port numbers, which a TCP/UDP NAT uses to NAT the ICMP messages. And broadasting is not an acceptable solution because delivery of ICMP messages happens to sockets, not to machines. If you deliver ICMP UDP port unreachable messages to all sockets in the respective IPv4+ address range where the port happens to match, that's going to cause chaos.