4 ms·

Keep the structure and services around IP protocol (DNS, DHCP, NAT), just with more bits for address. Do not try to reinvent the wheel and add unnecessary break

Keep the structure and services around IP protocol (DNS, DHCP, NAT), just with more bits for address. Do not try to reinvent the wheel and add unnecessary breaking bell and whistles which nobody asked for.

jcranmer 2y ago
All of these things already exist for IPv6, although I don't know how much DHCPv6 is deployed in practice.
- baq 2y ago
  It should be deployed everywhere where IPv6 is deployed and there's an IT department if only for logging/audit.
  - kccqzy 2y ago
    Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. And I in fact agree with them. And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
    - bigstrat2003 2y ago
      > Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.
  - jandrese 2y ago
    IPv6 DHCP isn't the same as IPv4 DHCP though. It doesn't work very well for logging and audits. It's more for assigning prefixs to routers.
- fanf2 2y ago
  Regrettably little, mainly because Lorenzo Colitti who is in charge of the Google Android network stack refuses to support it.
  - dmm 2y ago
    His justification for not supported stateful dhcpv6 is completely reasonable and I wish more platforms had come to the same conclusions.
justsomehnguy 2y ago
> just with more bits for address And by having a just more bits for the address - be incompatible with IPv4. DNS is IP^W address protocol agnostic, by the way. If you really need you can run it on IPX/SPX. DHCP is just a lack of the autoconfiguration in IPv4. No thanks. Nor APIPA, nor DHCP with the same 192.168.0.1/24 everywhere solve that properly like in v6. Sure there were some nuances in the begging (like the inability to provide the DNS servers addresses at the beginning) but they were solved 15 years ago.
- kemotep 2y ago
  Yeah any “solution” to backwards compatibility I have heard involves updating the address scheme. And to get that to work you need to update your networking equipment, software, and start redesigning your network to accommodate the new address scheme and guess what, that’s an IPV6 migration.
  - tsimionescu 2y ago
    If you only had to update the software for a new IP version and a longer address, and maybe even a bit of cleanup in the headers, adoption could have been much quicker. As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network). Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
    - justsomehnguy 2y ago
      > If you only had to update the software for a new IP version and a longer address By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already. If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that. More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic. You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware. > As it is, virtually everything about networking is different in the IPv6 world Sorry, but no. The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself. > That has significantly complicated adoption for everyone, arguably needlessly sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1] IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2] > And not everyone who says they support IPv6 even actually supports everything that the designers expect Now you argue what with 'IPv5' this wouldn't happen. > Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface. I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'. PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010). Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster. [0] if anything it's slower now [1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it. [2] Take this from someone who did and does both.

jcranmer 2y ago

All of these things already exist for IPv6, although I don't know how much DHCPv6 is deployed in practice.

baq 2y ago
It should be deployed everywhere where IPv6 is deployed and there's an IT department if only for logging/audit.
- kccqzy 2y ago
  Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. And I in fact agree with them. And DHCPv6 isn't needed for logging/audit: the router always has an association of MAC addresses and IPv6 addresses even if hosts assign their own addresses with SLAAC.
  - bigstrat2003 2y ago
    > Stateful DHCPv6 does not get deployed because IPv6 purists at Google refuse to implement them on Android. Which is absolutely ridiculous. Google should not be trying to dictate to their customers how to run infrastructure. If someone wants to use stateful DHCPv6 for their Android devices, that is their right and Google has no business standing in their way.
- jandrese 2y ago
  IPv6 DHCP isn't the same as IPv4 DHCP though. It doesn't work very well for logging and audits. It's more for assigning prefixs to routers.
fanf2 2y ago
Regrettably little, mainly because Lorenzo Colitti who is in charge of the Google Android network stack refuses to support it.
- dmm 2y ago
  His justification for not supported stateful dhcpv6 is completely reasonable and I wish more platforms had come to the same conclusions.

justsomehnguy 2y ago

> just with more bits for address And by having a just more bits for the address - be incompatible with IPv4. DNS is IP^W address protocol agnostic, by the way. If you really need you can run it on IPX/SPX. DHCP is just a lack of the autoconfiguration in IPv4. No thanks. Nor APIPA, nor DHCP with the same 192.168.0.1/24 everywhere solve that properly like in v6. Sure there were some nuances in the begging (like the inability to provide the DNS servers addresses at the beginning) but they were solved 15 years ago.

kemotep 2y ago
Yeah any “solution” to backwards compatibility I have heard involves updating the address scheme. And to get that to work you need to update your networking equipment, software, and start redesigning your network to accommodate the new address scheme and guess what, that’s an IPV6 migration.
- tsimionescu 2y ago
  If you only had to update the software for a new IP version and a longer address, and maybe even a bit of cleanup in the headers, adoption could have been much quicker. As it is, virtually everything about networking is different in the IPv6 world. That has significantly complicated adoption for everyone, arguably needlessly. And not everyone who says they support IPv6 even actually supports everything that the designers expect (e.g. lots of ISPs give you a /64 or even a /128 for your whole network). Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface.
  - justsomehnguy 2y ago
    > If you only had to update the software for a new IP version and a longer address By 2005 all the major 'software' (read: general purpose network operating systems) had the software for IPv6 already. If your application is hardcoded to use IPv4 addresses then you need to rewrite it anyway and no amount of IPv5 would change that. More so, if the software just didn't bother with hardcoding and just used the OS primitives for it's network activity (read: sockets and OS provided name resolution) then you don't even need to update it, it would just work. But the most important part here is what were (and I can bet my pumpkin latte - still are) incapable of anything of not IPv4 - because it's the hardware, which routed, NATed, checksummed all that traffic. You just couldn't slap your IPv5 there by exactly the same reason you couldn't slap IPv6 there - you needed to replace the hardware. > As it is, virtually everything about networking is different in the IPv6 world Sorry, but no. The basics, ie the networking, is exactly the same. Yes, there are some nuances, like using link-local addresses for the gateways, which absolutely, totally, makes sense after a 15 minute reading. But overall it's just another technology, not harder then everything else out there, including IPv4 itself. > That has significantly complicated adoption for everyone, arguably needlessly sigh At this point I need to conclude what the network guys are... just dumb. Like, come on, I needed to learn every year from the time I touched my first 286. Every year there is something new and you need to learn it[0]. Sometimes to abandon and forget it after a couple of years.[1] IPv6 is not a rocket-neuroscience, just another set of RFC's and guides. If anything, IPSec with it's idiosyncrasies is way, way more convoluted both to learn and implement.[2] > And not everyone who says they support IPv6 even actually supports everything that the designers expect Now you argue what with 'IPv5' this wouldn't happen. > Also, plenty of software that interacts with networking will sometimes be subtly broken if running on an IPv6 host, because of assumptions like one IP per interface. I wrote about it - it's the problem of the software. I had multiple IPv4 addresses on the same interface many, many times. If that software breaks with multiple IPv6 addresses on the one interface then it would break the same with mulltiple addresses of IPv4 and 'IPv5'. PS I have a small fleet of PowerConnect 5500 and 8000 switches. They are old, so old 5500 has SSH bolted onto a Telnet server. Yet they did already support IPv6 by 2010. It's already passed more years since the release of 8000 (2010 - 2024) than between IPv6 IETF proposal and release of 8000 (1998 - 2010). Slow adoption has nothing to do with IPv6 itself, and no IPv5 or whatever would made it faster. [0] if anything it's slower now [1] MS Exchange for example. Do you know X.400? I do not, anymore. But for some years I needed to know and I learned it. [2] Take this from someone who did and does both.