ipv6: the OSPFv3 and EIGRP configurators assign an interface address without Duplicate Address Detection

[adamgeorge309]

Summary

#1171 fixes the two places where Ipv6NetworkConfigurator and Ipv6NeighbourDiscovery
assign a global unicast address without Duplicate Address Detection (DAD). Two further call
sites do the same thing for a statically configured interface address and are outside that
fix. Each passes false as the tentative argument of
Ipv6InterfaceData::assignAddress() (src/inet/networklayer/ipv6/Ipv6InterfaceData.cc:293),
so the address is permanent on assignment and Ipv6NeighbourDiscovery::initiateDad() is
never reached for it:

• src/inet/routing/ospfv3/process/Ospfv3Process.cc:242 — an interface address taken from
  the Open Shortest Path First version 3 (OSPFv3) XML configuration:

  intfData6->assignAddress(address6, false, SIMTIME_ZERO, SIMTIME_ZERO);

• src/inet/routing/eigrp/EigrpDeviceConfigurator.cc:640 — an interface address taken from
  the Enhanced Interior Gateway Routing Protocol (EIGRP) XML configuration:

  int6data->assignAddress(ipv6, false, SIMTIME_ZERO, SIMTIME_ZERO);

What the standard says

RFC 4862 Section 5.4:

Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:

• An interface whose DupAddrDetectTransmits variable is set to zero
  does not perform Duplicate Address Detection.

The requirement is explicitly independent of how the address was obtained, which covers both
sites, and its own exception — DupAddrDetectTransmits set to zero — is already implemented
in INET per node and per interface, so no new parameter is needed to let a simulation skip
the check.

Three other call sites pass false correctly and should not be changed:
Ipv6RoutingTable.cc:259 (the loopback address ::1), EigrpIpv6Pdm.cc:1493 (a multicast
group address, and Duplicate Address Detection applies to unicast addresses only), and
Ipv6RoutingTable.cc:381 (which takes tentative from an XML attribute).

Why it matters

In a shipped example, examples/eigrp/two_node6, no address on any interface is ever
probed. Measured on origin/master 7aef79d5c0, 20 s of simulated time, detailed logging:

"DAD completed"                            : 0 occurrences
"Starting DAD for tentative global address" : 0 occurrences

Every address the Enhanced Interior Gateway Routing Protocol (EIGRP) configurator installs
from config.xml — including the link-local address fe80::1, which the rest of INET does
probe — is permanent from the moment it is assigned. A duplicate involving any of these
addresses cannot be detected, and the startDad and dadCompleted statistics under-count
by the number of such addresses.

Reproduction:

cd examples/eigrp/two_node6
opp_run -m -u Cmdenv -f omnetpp.ini -r 0 --sim-time-limit=20s \
  --cmdenv-express-mode=false --cmdenv-log-level=detail | grep -c "DAD completed"

Two sites deliberately excluded

Both look like instances of this defect and are not, so they are named here to save the next
reader the check:

• src/inet/networklayer/ipv6/Mipv6InterfaceData.cc:44 assigns a mobile node's home address
  with false. RFC 6275 Section 11.5.5 requires exactly that for the returning-home case:

  the mobile node MUST NOT perform Duplicate Address Detection on its own
  home address, in order to avoid confusion or conflict with its home
  agent's use of the same address.

  Whether INET reaches this site in cases the exemption does not cover is a separate
  question, and not one this issue claims to answer.

• src/inet/networklayer/ipv6/Ipv6InterfaceData.cc:811, inside deduceAdvPrefix(), has the
  same false, but deduceAdvPrefix() has no caller anywhere in the repository — it is
  unreachable.

Relationship to #1171 and #1140

All three are the same defect class — a unicast address assigned without Duplicate Address
Detection (DAD) — at different call sites. #1171 covers the configurator and the router's own
advertised-prefix address, #1140 covers a care-of address formed at a handover, and this one
covers the two routing-protocol configurators. None is load-bearing for the others: each site
is reached independently, and fixing any one leaves the rest unprobed.