6 ms·

Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take U

• jiggawatts 3y ago
  The USB protocols over the wire are generally not compatible between versions, especially at the lowest levels (signalling). That's the definition of how more bandwidth can be squeezed into the same wires. The signalling layer changed between versions. The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4. Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change. You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
• growse 3y ago
  How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
  • rini17 3y ago
    Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
    • growse 3y ago
      You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
      • rini17 3y ago
        No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
        • growse 3y ago
          A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme. You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6. > You could instead move this "port" directly into IP header in backward-compatible way If you're changing the meaning of the headers, it is by definition not backwards compatible.
        • simiones 3y ago
          No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it would have been done a long time ago.
          • rini17 3y ago
            Not true. There is Options field to extend IPv4 header. And only server and the router closest to user would need to support such extension, keeping layering violations to minimum.
• candiodari 3y ago
  IPv6 is backwards compatible. In multiple ways: Option 1: "6to4" https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64 + DNS64 Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike) Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling https://en.wikipedia.org/wiki/Teredo_tunneling Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications) Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite) https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual... And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism https://en.wikipedia.org/wiki/IPv6_transition_mechanism The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.
  • ta1243 3y ago
    The fact there are so many options shows the fundamental design problem.
    • deleted 3y ago
      [deleted]
    • supertrope 3y ago
      It's iterating over time to fix real problems. No protocol is perfect in the initial RFC.
      • p1mrx 3y ago
• bauruine 3y ago
  What's your problem with the IPv6 end-user experience? Hundreds of millions of end-users are using it without even knowing what an IP is.
• danhor 3y ago
  USB 3 the protocol isn't backwards compatible with USB 2, USB 3 ports just include both USB 2 and USB 3 pins (what one might call dual stack). You can easily connect two differnt devices one to the USB 2 pins and one to the USB 3 pins. If you only want to connect USB 3 devices, there is no need for USB 2 Pins, as done on the PS4. There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.