5 ms·

Not exactly. 6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them. What I propose

by geocar 11y ago

Not exactly. 6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them. What I propose (effectively) gives IPv6 (though I should call it something else) hosts IPv4 addresses: the exact opposite. You don't have to upgrade anything except the user's web browser (which clearly took less than 20 years).

lmm 11y ago
> 6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them. No-one's turning off their IPv4 stacks though. Under your proposal if one or other edge was IPv4-only then they'd use ordinary IPv4, you'd only see any benefit if both edges were IPv4+, right? Which is the same as when using 6to4. (If you really need to avoid dual-stack even on the local network you can use 6to4 and NAT64). (6to4 is largely a failure but the kind of approach you propose would have the same issues as far as I can see)
- geocar 11y ago
  A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4. An IPv4+ address reserves 32 bits for the network address, and has (say) a 64 bit host address after it. This means that IPv4+ hosts can be allocated by anyone with an IPv4 address.
  - lmm 11y ago
    > A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4. Not so - if you have a single public IPv4 address you can turn that into an IPv6 /48 and put up to 16 bits worth of hosts behind it. Given that these are only for edges and not meant to have routing within them that should be plenty (having two different sets of routing logic applying to the same packets would be a recipe for difficult-to-debug disconnections and even-more-difficult-to-debug transient slowness).
- solotronics 11y ago
  Eventually we will start turning off IPv4 stacks, just like the ATM/frame layer 2 technologies have given way to carrier ethernet.
  - lmm 11y ago
    Sure. My point was it's not that important for IPv6 to be able to talk to IPv4 - as long as you need to talk to IPv4 hosts, you can just keep running an IPv4 stack.
zAy0LfpBZLC8mAC 11y ago
I think I still don't get what your suggestion is ... what could a web browser do to alleviate the address shortage in IPv4?
- 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
fulafel 11y ago
6in4 != 6to4. In 6to4, only the router needs an IPv4 address, yielding a /48 to play with.
- geocar 11y ago
  Oh I see, sorry about that. It's what I get for being on my phone. 6to4 would probably have been more successful had it not allowed tunnelling arbitrary IPv6 addresses, not used a different protocol type, or broken the IPv4 addresses (by adding the 2.0.0.2.ip6.arpa DNS zone), but I agree it's basically the same thing.

by geocar 11y ago

lmm 11y ago

> 6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them. No-one's turning off their IPv4 stacks though. Under your proposal if one or other edge was IPv4-only then they'd use ordinary IPv4, you'd only see any benefit if both edges were IPv4+, right? Which is the same as when using 6to4. (If you really need to avoid dual-stack even on the local network you can use 6to4 and NAT64). (6to4 is largely a failure but the kind of approach you propose would have the same issues as far as I can see)

geocar 11y ago
A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4. An IPv4+ address reserves 32 bits for the network address, and has (say) a 64 bit host address after it. This means that IPv4+ hosts can be allocated by anyone with an IPv4 address.
- lmm 11y ago
  > A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4. Not so - if you have a single public IPv4 address you can turn that into an IPv6 /48 and put up to 16 bits worth of hosts behind it. Given that these are only for edges and not meant to have routing within them that should be plenty (having two different sets of routing logic applying to the same packets would be a recipe for difficult-to-debug disconnections and even-more-difficult-to-debug transient slowness).
solotronics 11y ago
Eventually we will start turning off IPv4 stacks, just like the ATM/frame layer 2 technologies have given way to carrier ethernet.
- lmm 11y ago
  Sure. My point was it's not that important for IPv6 to be able to talk to IPv4 - as long as you need to talk to IPv4 hosts, you can just keep running an IPv4 stack.

zAy0LfpBZLC8mAC 11y ago

I think I still don't get what your suggestion is ... what could a web browser do to alleviate the address shortage in IPv4?

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

fulafel 11y ago

6in4 != 6to4. In 6to4, only the router needs an IPv4 address, yielding a /48 to play with.

geocar 11y ago
Oh I see, sorry about that. It's what I get for being on my phone. 6to4 would probably have been more successful had it not allowed tunnelling arbitrary IPv6 addresses, not used a different protocol type, or broken the IPv4 addresses (by adding the 2.0.0.2.ip6.arpa DNS zone), but I agree it's basically the same thing.