3 ms·

> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw

> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it? From Bernstein: > In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing? All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6. The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6). * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752

aboardRat4 2y ago
>how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? By using nat46 on ISP's routers.
- throw0101c 2y ago
  >> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? > By using nat46 on ISP's routers. I do not understand. In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses. Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses. Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)): * https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp... The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created. Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols: * https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre... But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through? Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?
  - aboardRat4 2y ago
    Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server. If software has hardcoded ipv6 addresses, this is much harder to solve, but I don't think this is really an issue, because hardcoded ipv6 addresses appear very seldom.
    - Dylan16807 2y ago
      Assuming you mean nat46, your description is a bit off. The NAT box doesn't have a single ipv4, it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. But that means it has to intercept all DNS requests and doesn't work with anything it didn't intercept, which seems far from ideal.
      - aboardRat4 2y ago
        >it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. But those don't have to be globally routable. >it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. This wasn't really a problem until doh/dot became a thing. But even nowadays doh and dot are provided by whom? By google and cloudflare who are tls-mitm'ing half of the internet anyway. Moreover most ISPs intercept dns to display those "please enter your phone number to verify your identity" screens anyway. >far from ideal. No more imperfect than NAT. Idealism is what is killing ipv6.
        Dylan16807 2y ago
        If I'm going to run single stack locally I'm going to use IPv6 and a stateless converter for IPv4.
        aboardRat4 2y ago
        Which means that servers have zero incentive to convert to ipv6. All this cgnat46 setup is not in the name of end users, because they will always adapt somehow, as reels have a huge force of attraction. It is to make sure that service providers can deploy ipv6-only _servers_ and not bother that 60 percent of their target audience will be unavailable. The issue with the ipv6 internet is not the end users, they are paying, so the ISPs will always adapt to their needs, or the users themselves will buy new equipment in the worst case, it's the service providers who stop being profitable by going ipv6-only.
linsomniac 2y ago
>how do you get 32-bit-only system to understand more-32-bits of addressing Maybe you don't. I imagine it would work like this (where XXXX::<IPv4> is the transition block mapping the current Internet v4 into IPv6): - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part. - Hosts with v6 addresses outside of XXXX::<IPv4> could not talk to IPv4 addresses without having a 6to4 proxy. We also have this now. - Hosts with v4 addresses could switch to IPv6, KEEPING their current v4 address by setting their IPv6 addres to XXXX::<IPv4>. They can now talk to all the hosts they used to be able to, AND they can start talking to IPv6 hosts, without having to have two IP, dual stack config, etc. So we end up with a significant benefit of allowing people with IPv4 addresses and IPv6 connectivity to do an IPv6-only setup. In my case, I simply don't see us transitioning to IPv6. Our main service has an IPv4-only address and we receive 0 complaints about it. We've literally never had anyone say they couldn't connect to our services because of it. Our users are geographically located in the central US, and everybody has IPv4s. Maybe they have an IPv6 as well, but if we went v6-only I can basically guarantee that we'd have users screaming at us. We'd probably have lawsuits over it. But going v4-only, not a peep.
- throw0101c 2y ago
  > - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part. Oh, you mean like IPv4-mapped Address (::ffff:0:0/96) as defined in RFC 4291 § 2.2.5, or NAT64 (64:ff9b::/96) as per RFC 6050. See also 6to4 in RFC 3056 dating back to 2001. Your idea is not new.
  - linsomniac 2y ago
    Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing. In particular when I first started thinking about it I kept getting stuck on "Ok, so how do non-v4 mapped IPs talk to v4 addresses?"

aboardRat4 2y ago

>how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? By using nat46 on ISP's routers.

throw0101c 2y ago
>> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? > By using nat46 on ISP's routers. I do not understand. In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses. Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses. Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)): * https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp... The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created. Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols: * https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre... But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through? Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?
- aboardRat4 2y ago
  Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server. If software has hardcoded ipv6 addresses, this is much harder to solve, but I don't think this is really an issue, because hardcoded ipv6 addresses appear very seldom.
  - Dylan16807 2y ago
    Assuming you mean nat46, your description is a bit off. The NAT box doesn't have a single ipv4, it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. But that means it has to intercept all DNS requests and doesn't work with anything it didn't intercept, which seems far from ideal.
    - aboardRat4 2y ago
      >it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. But those don't have to be globally routable. >it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through. This wasn't really a problem until doh/dot became a thing. But even nowadays doh and dot are provided by whom? By google and cloudflare who are tls-mitm'ing half of the internet anyway. Moreover most ISPs intercept dns to display those "please enter your phone number to verify your identity" screens anyway. >far from ideal. No more imperfect than NAT. Idealism is what is killing ipv6.
      - Dylan16807 2y ago
        If I'm going to run single stack locally I'm going to use IPv6 and a stateless converter for IPv4.
        aboardRat4 2y ago
        Which means that servers have zero incentive to convert to ipv6. All this cgnat46 setup is not in the name of end users, because they will always adapt somehow, as reels have a huge force of attraction. It is to make sure that service providers can deploy ipv6-only _servers_ and not bother that 60 percent of their target audience will be unavailable. The issue with the ipv6 internet is not the end users, they are paying, so the ISPs will always adapt to their needs, or the users themselves will buy new equipment in the worst case, it's the service providers who stop being profitable by going ipv6-only.

linsomniac 2y ago

>how do you get 32-bit-only system to understand more-32-bits of addressing Maybe you don't. I imagine it would work like this (where XXXX::<IPv4> is the transition block mapping the current Internet v4 into IPv6): - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part. - Hosts with v6 addresses outside of XXXX::<IPv4> could not talk to IPv4 addresses without having a 6to4 proxy. We also have this now. - Hosts with v4 addresses could switch to IPv6, KEEPING their current v4 address by setting their IPv6 addres to XXXX::<IPv4>. They can now talk to all the hosts they used to be able to, AND they can start talking to IPv6 hosts, without having to have two IP, dual stack config, etc. So we end up with a significant benefit of allowing people with IPv4 addresses and IPv6 connectivity to do an IPv6-only setup. In my case, I simply don't see us transitioning to IPv6. Our main service has an IPv4-only address and we receive 0 complaints about it. We've literally never had anyone say they couldn't connect to our services because of it. Our users are geographically located in the central US, and everybody has IPv4s. Maybe they have an IPv6 as well, but if we went v6-only I can basically guarantee that we'd have users screaming at us. We'd probably have lawsuits over it. But going v4-only, not a peep.

throw0101c 2y ago
> - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part. Oh, you mean like IPv4-mapped Address (::ffff:0:0/96) as defined in RFC 4291 § 2.2.5, or NAT64 (64:ff9b::/96) as per RFC 6050. See also 6to4 in RFC 3056 dating back to 2001. Your idea is not new.
- linsomniac 2y ago
  Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing. In particular when I first started thinking about it I kept getting stuck on "Ok, so how do non-v4 mapped IPs talk to v4 addresses?"