4 ms·

> DHCPv6 was never even supposed to be a thing; Why?

Arnt 6y ago
There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
- growse 6y ago
  > There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. > DHCPv6 does exist, but I don't really understand what it offers over RA+ND. How does RA/ND solve the problem of client auto-configuration of services? Rightly or wrongly, DHCP has been traditionally used for service discovery ("Hey! Here's some NTP servers, a TFTP server and a SIP server") as well as config discovery (useful for autoprovisioning of many devices) and I didn't think you could achieve that just with RA/ND. Has anyone managed to get netboot or PXE working on IPv6 without DHCP? Edit just saw a sibling thread about DNS adverts in RA. I guess RA could do all these things, but if it doesn't support it today, DHCP is going to fill the gap.
  - Arnt 6y ago
    Or the gap goes unfilled. We live in an age where small diskless devices are uncommon and another type of small device now called "phone" is common. A small device nowadays doesn't boot from PXE+TFTP, it has its own SSD and doesn't even trust the network.
    - aftbit 6y ago
      Maybe on your home LAN, but IP desk phones are increasingly common in offices (if we ever go back to those).
      - Arnt 6y ago
        I had one for a while. It had SSD storage.
wahern 6y ago
AFAIU, SLAAC and RA were supposed to be the answers for the problems solved by DHCP. But people don't really get SLAAC and RA. I think, based on my own personal experience and ignorance, this is partly because SLAAC and RA emphasize the adoption of sophisticated prefixing and routing strategies that people (who aren't BGP router administrators) aren't accustomed to caring about, let alone rigorously thinking about and accommodating, especially on their LANs. Also, neither directly solve the problem of advertising DNS hosts and other options, like NTP hosts, that piggyback on DHCP. I'm not particularly well versed with all things IPv6, but AFAIU the alternatives arrived belatedly--e.g. RFC 6106 (currently RFC 8106) which extends RA to propagate DNS configuration. I'm not sure if NTP and other DHCP extensions even have non-DHCPv6 alternatives, yet. I don't know if DHCPv6 will win the day, or the vision of a leaner, more distributed addressing and routing infrastructure will prevail. And I don't have any opinions on which is better. I just know it's all rather confusing and still in flux.
- whereistimbo 6y ago
  To this time of writing The Android AOSP Team still refuses to adopt DHCPv6. Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
  - wahern 6y ago
    > Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits. Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together. I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply. If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.

Arnt 6y ago

There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. DHCPv6 does exist, but I don't really understand what it offers over RA+ND.

growse 6y ago
> There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. > DHCPv6 does exist, but I don't really understand what it offers over RA+ND. How does RA/ND solve the problem of client auto-configuration of services? Rightly or wrongly, DHCP has been traditionally used for service discovery ("Hey! Here's some NTP servers, a TFTP server and a SIP server") as well as config discovery (useful for autoprovisioning of many devices) and I didn't think you could achieve that just with RA/ND. Has anyone managed to get netboot or PXE working on IPv6 without DHCP? Edit just saw a sibling thread about DNS adverts in RA. I guess RA could do all these things, but if it doesn't support it today, DHCP is going to fill the gap.
- Arnt 6y ago
  Or the gap goes unfilled. We live in an age where small diskless devices are uncommon and another type of small device now called "phone" is common. A small device nowadays doesn't boot from PXE+TFTP, it has its own SSD and doesn't even trust the network.
  - aftbit 6y ago
    Maybe on your home LAN, but IP desk phones are increasingly common in offices (if we ever go back to those).
    - Arnt 6y ago
      I had one for a while. It had SSD storage.

wahern 6y ago

AFAIU, SLAAC and RA were supposed to be the answers for the problems solved by DHCP. But people don't really get SLAAC and RA. I think, based on my own personal experience and ignorance, this is partly because SLAAC and RA emphasize the adoption of sophisticated prefixing and routing strategies that people (who aren't BGP router administrators) aren't accustomed to caring about, let alone rigorously thinking about and accommodating, especially on their LANs. Also, neither directly solve the problem of advertising DNS hosts and other options, like NTP hosts, that piggyback on DHCP. I'm not particularly well versed with all things IPv6, but AFAIU the alternatives arrived belatedly--e.g. RFC 6106 (currently RFC 8106) which extends RA to propagate DNS configuration. I'm not sure if NTP and other DHCP extensions even have non-DHCPv6 alternatives, yet. I don't know if DHCPv6 will win the day, or the vision of a leaner, more distributed addressing and routing infrastructure will prevail. And I don't have any opinions on which is better. I just know it's all rather confusing and still in flux.

whereistimbo 6y ago
To this time of writing The Android AOSP Team still refuses to adopt DHCPv6. Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
- wahern 6y ago
  > Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits. Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together. I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply. If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.