4 ms·

This is insane... IPv6 as a completely separate network from IPv4? JUST ADD 12 BYTES TO THE FRONT OF THE ADDRESS YOU ASSTWATS, then the 0::0/96 is all the curre

by anon4 11y ago

This is insane... IPv6 as a completely separate network from IPv4? JUST ADD 12 BYTES TO THE FRONT OF THE ADDRESS YOU ASSTWATS, then the 0::0/96 is all the current IPv4 space and the rest is up for grabs. Yes, there are still interoperability problems with this scheme, but the alternative right now is to give every device two public addresses, be effectively on two completely distinct global networks and hope everything works. It doesn't seem to.

growse 11y ago
You mean, you want to be able to embed an address on the old scheme into a routable address in the new scheme? Just like IPv6 does? https://tools.ietf.org/html/rfc6052#section-2.2 https://tools.ietf.org/html/rfc6052#section-2.2
blfr 11y ago
All my devices at home* are dual-stack and so are some of the servers I run. Never had any issues. Browsers, ssh/sftp, nginx, whatever's behind nginx, Exim... no complications beyond adding another listen line to the configuration where appropriate. * Except Kindles.
lmm 11y ago
If you don't completely separate the networks what are legacy IPv4-only routers going to route on? The lower 32 bits of the address? Great, now you get unreliable silent failures where your packets sometimes get stuck in routing loops depending on which path they take. That would be an absolute nightmare to debug.
- cornholio 11y ago
  If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. 32 bits was perfectly adequate for routing for decades and would still be if not for the route explosion caused by exhaustion itself. A similiar problem could still happen inside your mixed IPv4-"IPv4.1" system, but in that case it's your problem to fix and not the fault of the protocol or of some distant sysadmin.
  - darkr 11y ago
    IPv4.1 is a thing, and has been supported in the Linux kernel for some years. It basically adds on a extra octet to IPv4, giving you 40 bits of address space rather than 32. AFAIK this hasn't and will probably never make it out of experimental status.
  - lmm 11y ago
    > If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. So endpoints would not have publicly routable addresses, and your packets would be sent across the Internet encapsulated as IPv4. Isn't that just NAT? It would work, to the extent that NAT works today, but it wouldn't get us any closer to having a publicly routable network with more addresses (you'd still get undebuggable problems whenever you tried to switch on public routing), and it wouldn't address the real problem which is not just IP address exhaustion but also class A, B and C exhaustion. What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? That's your "route explosion caused by exhaustion itself" right there.
    - cornholio 11y ago
      > Isn't that just NAT? No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. This further means that: 1. IPv6 deployment is no longer a tragedy of the commons: if I deploy IPv6 I get it's benefits immediately along with my remote peers, no longer dependent of providers, AWS or some remote sysadmin over which I have no control. 2. There are no longer any dual stacks to maintain, timeouts, and switches that plague us today; IPv6 just works on the existing IPv4 infrastructure until it becomes dominant. 3. IPv4-only services are incetivized to upgrade because they can provide better service to IPv6 customers who share a common IPv4 that will presumably revert to a form of NAT when connecting to an IPv4 only server. In short, a rational and much less risky upgrade path. >What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.
zAy0LfpBZLC8mAC 11y ago
You might want to learn about how IP works before you tell people what it can do. IP has on each packet both the source and the destination address, because the destination uses the source address to send back the response. Nothing works if you can't send responses. If your device has an address from the "extended address space", you cannot talk to any device that doesn't know about that "extended address space" because they won't know how to read your source address and how to send a response back to it. Just as with IPv6: You cannot talk to an IPv4-only device if all you have is IPv6. Essentially, IPv6 does exactly what you are suggesting. Things just don't work as you imagine them to, but rather one unavoidably ends up with "a completely separate network" if one does things as you suggest.

by anon4 11y ago

growse 11y ago

You mean, you want to be able to embed an address on the old scheme into a routable address in the new scheme? Just like IPv6 does? https://tools.ietf.org/html/rfc6052#section-2.2 https://tools.ietf.org/html/rfc6052#section-2.2

blfr 11y ago

All my devices at home* are dual-stack and so are some of the servers I run. Never had any issues. Browsers, ssh/sftp, nginx, whatever's behind nginx, Exim... no complications beyond adding another listen line to the configuration where appropriate. * Except Kindles.

lmm 11y ago

If you don't completely separate the networks what are legacy IPv4-only routers going to route on? The lower 32 bits of the address? Great, now you get unreliable silent failures where your packets sometimes get stuck in routing loops depending on which path they take. That would be an absolute nightmare to debug.

cornholio 11y ago
If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. 32 bits was perfectly adequate for routing for decades and would still be if not for the route explosion caused by exhaustion itself. A similiar problem could still happen inside your mixed IPv4-"IPv4.1" system, but in that case it's your problem to fix and not the fault of the protocol or of some distant sysadmin.
- darkr 11y ago
  IPv4.1 is a thing, and has been supported in the Linux kernel for some years. It basically adds on a extra octet to IPv4, giving you 40 bits of address space rather than 32. AFAIK this hasn't and will probably never make it out of experimental status.
- lmm 11y ago
  > If a backwards compatible, "IPv4.1" version would have been deployed, designed to route transparently through the legacy IPv4 infrastructure, then public routes could have been restricted to the legacy field for a number of years by IANA. So endpoints would not have publicly routable addresses, and your packets would be sent across the Internet encapsulated as IPv4. Isn't that just NAT? It would work, to the extent that NAT works today, but it wouldn't get us any closer to having a publicly routable network with more addresses (you'd still get undebuggable problems whenever you tried to switch on public routing), and it wouldn't address the real problem which is not just IP address exhaustion but also class A, B and C exhaustion. What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? That's your "route explosion caused by exhaustion itself" right there.
  - cornholio 11y ago
    > Isn't that just NAT? No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them. This further means that: 1. IPv6 deployment is no longer a tragedy of the commons: if I deploy IPv6 I get it's benefits immediately along with my remote peers, no longer dependent of providers, AWS or some remote sysadmin over which I have no control. 2. There are no longer any dual stacks to maintain, timeouts, and switches that plague us today; IPv6 just works on the existing IPv4 infrastructure until it becomes dominant. 3. IPv4-only services are incetivized to upgrade because they can provide better service to IPv6 customers who share a common IPv4 that will presumably revert to a form of NAT when connecting to an IPv4 only server. In short, a rational and much less risky upgrade path. >What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.

zAy0LfpBZLC8mAC 11y ago

You might want to learn about how IP works before you tell people what it can do. IP has on each packet both the source and the destination address, because the destination uses the source address to send back the response. Nothing works if you can't send responses. If your device has an address from the "extended address space", you cannot talk to any device that doesn't know about that "extended address space" because they won't know how to read your source address and how to send a response back to it. Just as with IPv6: You cannot talk to an IPv4-only device if all you have is IPv6. Essentially, IPv6 does exactly what you are suggesting. Things just don't work as you imagine them to, but rather one unavoidably ends up with "a completely separate network" if one does things as you suggest.