Hi!
As I understand, RouterOS right now only supports DHCPv6 PD and not the stateful client DHCPv6?
It would be nice to support it as well, so that the individual client bindings can be inspected through the console/API.
MikroTik did say at one point that they planned to eventually support stateful DHCPv6 server on RouterOS, which would mean the ability to create not only pools of prefixes but pools of addresses. However, that was before Google clarified that they would *never* support stateful DHCPv6 on any Android platform b/c SLAAC is better. If you need to run any Android based devices on the network, you will need to also run SLAAC, and if you do both stateful DHCPv6 and SLAAC there is really no major advantage vs. just running SLAAC.As I understand, RouterOS right now only supports DHCPv6 PD and not the stateful client DHCPv6?
It would be nice to support it as well, so that the individual client bindings can be inspected through the console/API.
When you have SLAAC with no privacy extensions, which is the case for most such devices, the SLAAC addresses are essentially static - they won't change. The UPS management card you have is probably building a global address from EUI-64. There's no need for privacy extensions on such devices, and so you can create a DNS record that resolves to that address without having to worry about the address changing.I've several devices that can't really use SLAAC because you need to know their address to connect to them. Some of them are UPS management cards.
It actually doesn't do SLAAC at all, apparently (except obviously for router and DHCPv6 discovery). I can configure a static IPv6, but I need to support dynamic prefixes (for failover reasons) so this is not acceptable.When you have SLAAC with no privacy extensions, which is the case for most such devices, the SLAAC addresses are essentially static - they won't change. The UPS management card you have is probably building a global address from EUI-64. There's no need for privacy extensions on such devices, and so you can create a DNS record that resolves to that address without having to worry about the address changing.
That is really strange. I've never encountered a device that only supported DHCPv6 client and not SLAAC, and we use many devices. I have seen a few devices where (confusingly) you have to put it in DHCPv6 client mode to get a SLAAC address. If you put the device in question into DHCPv6 client mode, does it get an address via SLAAC?It actually doesn't do SLAAC at all, apparently (except obviously for router and DHCPv6 discovery).
I've tried all permutations of IPv6 configuration options (there are just two: "automatic", and "static IPv6"). I can ping the device over the link-local address, but for some reason it doesn't accept SLAAC. It works over stateful DHCPv6 on OpenWRT.That is really strange. I've never encountered a device that only supported DHCPv6 client and not SLAAC, and we use many devices. I have seen a few devices where (confusingly) you have to put it in DHCPv6 client mode to get a SLAAC address. If you put the device in question into DHCPv6 client mode, does it get an address via SLAAC?
Honestly, the device not supporting SLAAC is really an issue with the device. Most likely the manufacturer just assumed IPv6 is the same as IPv4 and didn't know SLAAC existed or didn't know that it was the normal way of assigning addresses with IPv6. I've only had one device that didn't support SLAAC (only supported DHCPv6) but the DHCPv6 option actually worked with SLAAC but gave a confusing error message in the log that it couldn't receive an address via DHCPv6. I asked the vendor about it and the response was that they barely knew how IPv6 worked and just assumed that the only options for address allocation were static or DHCP, like in IPv4. They added SLAAC in a later firmware update after I asked them to fix it.I've tried all permutations of IPv6 configuration options (there are just two: "automatic", and "static IPv6"). I can ping the device over the link-local address, but for some reason it doesn't accept SLAAC. It works over stateful DHCPv6 on OpenWRT.
I'll try to upgrade its firmware and see if it helps.
I also still do like to be able to manage devices over the DHCPv6. I would even add this functionality if Mikrotik allowed custom NPKs.
i agree. android doesn't even has DHCPv6 support built in.The Google engineer makes his case for the best way to track IPv6 address usage by host in RFC 7934 section 9.1:
https://tools.ietf.org/html/rfc7934#page-9
Well, the story ended happily. We just disabled IPv6 in our network entirely. It's not like anybody needs it right now.The Google engineer makes his case for the best way to track IPv6 address usage by host in RFC 7934 section 9.1:
https://tools.ietf.org/html/rfc7934#page-9
That's not the case - we have hundreds of linux servers, APs, UPS's, PDU's, switches, etc all on SLAAC. We have to manually create a single DNS record for each, but the address does not change. For the servers we turn off the privacy extensions, whereas devices like APs, UPS's, PDU's, and switches will not have privacy extensions support to begin with.About ND-based host tracking, I don't think it can be hooked up to DNS management or even to monitoring with user-friendly names.
To be fair, desktop macOS and Windows both support DHCPv6 so this allows to provide visibility into them.ND-based host tracking is really only an issue where you are dealing with subnets and ranges that end users will connect to, especially in BYOD situations. In those cases they can get multiple addresses using SLAAC and tracking requires some specialized service.
Yeah, that is a little strange. A UPS shouldn't need privacy addresses under any scenario - they should just have that disabled so it only has the one EUI64-based address.So the vendor sent me a replacement card. It works fine with SLAAC. But I guess they overdid it, it gets a MAC-based address and a bunch of privacy addresses.