Return to Answer

Progams should use Netlink

IE: rtnl as most Linux networking tools do, then after adding the rtnl_addr object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

• having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
• IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
• absence of both flags means DAD finished and no collisions were found.

The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers (which may vary depending on whether the kernel has optimistic_dad or enhanced_dad enabled). The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

If the program uses the ip CLI

... then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

    ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'

The iproute2 `ip` CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

Note: If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

Linux ≤ 2.4

If the program is run on the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

(This specifically includes the net-tools `ifconfig`, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)

• If the program uses Netlink (rtnl) as most Linux networking tools do, then after adding the rtnl_addr object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

  • having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
  • IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
  • absence of both flags means DAD finished and no collisions were found.

  The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers (which may vary depending on whether the kernel has optimistic_dad or enhanced_dad enabled). The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

  Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

• If the program uses the ip CLI, then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

  ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'
  

  The iproute2 ip CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

• If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

• And if the program uses the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

  (This specifically includes the net-tools ifconfig, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)

• If the program uses Netlink (rtnl) as most Linux networking tools do, then after adding the rtnl_addr object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

  • having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
  • IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
  • absence of both flags means DAD finished and no collisions were found.

  The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers (which may vary depending on whether the kernel has optimistic_dad or enhanced_dad enabled). The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

  Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

• If the program uses the ip CLI, then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

  ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'
  

  The iproute2 ip CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

• If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

• And if the program uses the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

  (This specifically includes the net-tools ifconfig, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)

Progams should use Netlink

IE: rtnl as most Linux networking tools do, then after adding the rtnl_addr object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

• having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
• IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
• absence of both flags means DAD finished and no collisions were found.

The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers (which may vary depending on whether the kernel has optimistic_dad or enhanced_dad enabled). The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

If the program uses the ip CLI

... then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

    ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'

The iproute2 `ip` CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

Note: If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

Linux ≤ 2.4

If the program is run on the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

(This specifically includes the net-tools `ifconfig`, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)

The kernel automatically performs Duplicate Address Detection any time an IPv6 address is added to an interface. There is nothing special that the program needs to do in order to activate DAD.

If I have some software that wants to add an IP to the host, how could that software discover that the IP is taken. Eg using the ip CLI?

The same way it adds the IP address:

• If the program uses Netlink (rtnl) as most Linux networking tools do, then after adding the rtnl_address object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

  • having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
  • IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
  • absence of both flags means DAD finished and no collisions were found.

  The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers. The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

  But Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

• If the program uses the ip CLI, then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

  ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'
  

  The iproute2 ip CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

• If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

• And if the program uses the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

  (This specifically includes the net-tools ifconfig, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)

The kernel automatically performs Duplicate Address Detection any time an IPv6 address is added to an interface. There is nothing special that the program needs to do in order to activate DAD.

If I have some software that wants to add an IP to the host, how could that software discover that the IP is taken. Eg using the ip CLI?

The same way it adds the IP address:

• If the program uses Netlink (rtnl) as most Linux networking tools do, then after adding the rtnl_addr object it can get (RTM_GETADDR) the same object and check its IFA_FLAGS:

  • having IFA_F_TENTATIVE means it is still undergoing Duplicate Address Detection (and in fact the kernel won't allow you to use it, unless Optimistic DAD is enabled),
  • IFA_F_DADFAILED means DAD finished and found a collision (the tentative flag may remain set as well),
  • absence of both flags means DAD finished and no collisions were found.

  The program doesn't need to wait for a specific time. The kernel's DAD code already has the necessary timers (which may vary depending on whether the kernel has optimistic_dad or enhanced_dad enabled). The program only needs to keep checking (e.g. every second) until either the 'tentative' flag disappears or 'dadfailed' appears, whichever happens first.

  Netlink also provides change notifications (like in ip monitor addr) so the program will automatically keep receiving the address object every time its flags change, without needing any poll interval.

• If the program uses the ip CLI, then to begin with, it should stop using the ip CLI and start using interfaces meant for machine use, namely Netlink. But if that's not possible then the program should use ip -json to query the addresses, parsing the output as JSON and using the same logic as for Netlink (i.e. wait until .tentative has disappeared and/or .dadfailed has appeared).

  ip -j -6 addr ls mlx0 | jq '.[].addr_info[] | {local, tentative, dadfailed}'
  

  The iproute2 ip CLI itself uses Netlink, so it is not problematic in itself – it has access to all of the same information, and you can run it manually to check the same flags. But it is an interface for human consumption first and foremost.

• If the program uses the ip CLI on a platform where there's no -json option (either because it's an ancient iproute2 version or because it's the Busybox imitation), then sorry but that's already in the "works on my computer" territory.

• And if the program uses the old Linux 2.4 era IPv6-specific ioctl and /proc/net interfaces, then AFAIK it has no way to obtain this information, and it should be ported to Netlink – although even ip -json would already be an upgrade.

  (This specifically includes the net-tools ifconfig, as nobody has ported it to the modern Linux 2.6 ways yet. Avoid net-tools.)