mipv6: the home agent does not perform Duplicate Address Detection for the home address, a hardcoded 1 s delay stands in

[adamgeorge309]

Summary

A home agent must run Duplicate Address Detection for a mobile node's home address on the home
link before it acknowledges a first home registration, and must reject the registration with
status 134 if the address turns out to be in use. INET does neither. The check is replaced by a
hardcoded one-second delay on the Binding Acknowledgement, and the rejection path is an empty
// TODO.

src/inet/networklayer/mipv6/Mipv6.cc:856-861, directly under the quoted RFC passage:

simtime_t sendTime;
if (rt6->isHomeAgent())
    // HA has to do DAD in case this is a new binding for this HoA
    sendTime = existingBinding ? 0 : 1;
else
    sendTime = 0;

applied at Mipv6.cc:645-648, which carries its own admission:

// TODO solve the HA DAD problem in a different way
// (delay currently specified via the sendTime parameter)
if (sendTime > 0)
    sendDelayed(msg, sendTime, "toIPv6");

and the rejection path, Mipv6.cc:867-872:

/*If this Duplicate Address Detection fails for the given
   home address or an associated link local address, then the home agent
   MUST reject the complete Binding Update and MUST return a Binding
   Acknowledgement to the mobile node, in which the Status field is set
   to 134 (Duplicate Address Detection failed).*/
// TODO

The delay is not the deviation. A compliant home agent does wait roughly one Duplicate
Address Detection interval before acknowledging. The deviation is that the check never happens,
so the delay is a constant where the model should produce a distribution, and status 134 can
never be sent.

What the standard says

RFC 6275 Section 10.3.1, "Primary Care-of Address Registration":

Unless this home agent already has a binding for the given home address, the home agent MUST
perform Duplicate Address Detection [19] on the mobile node's home link before returning the
Binding Acknowledgement. This ensures that no other node on the home link was using the
mobile node's home address when the Binding Update arrived. If this Duplicate Address
Detection fails for the given home address or an associated link local address, then the home
agent MUST reject the complete Binding Update and MUST return a Binding Acknowledgement to the
mobile node, in which the Status field is set to 134 (Duplicate Address Detection failed).

How to reproduce

On origin/master 021485b99c:

cd examples/ipv6/mipv6
inet -u Cmdenv -c Handover -r 0 --seed-set=1 --sim-time-limit=25s \
  --cmdenv-express-mode=false --cmdenv-log-level=off \
  '--*.Home_Agent.ipv6.neighbourDiscovery.cmdenv-log-level=trace' \
  '--*.Home_Agent.ipv6.mipv6.cmdenv-log-level=info'

The home agent logs INITIATING DUPLICATE ADDRESS DISCOVERY exactly twice, both at
t=0.043611 s, for its own two interfaces at boot. It logs nothing at t=21.712822 s, when the
Binding Update arrives and is validated. No Neighbor Solicitation for the home address is ever
sent.

Measuring the acknowledgement delay across seed sets:

seed set	Binding Update at home agent	Binding Acknowledgement at mobile node	delay
1	21.712822	22.714349	1.001526 s
2	24.521633	25.523360	1.001726 s
3	21.514159	22.515745	1.001587 s

Identical to three decimal places: one second of sendDelayed plus about 1.5 ms of link
latency. A re-registration, which takes the existingBinding branch, is acknowledged in
0.0017 s -- pure propagation.

Why it matters

1. A fixed number where the model should produce a distribution. Real Duplicate Address
   Detection in INET costs retransTimer plus a uniform 0-1 s term standing for the
   solicited-node multicast group join of RFC 4862 Section 5.4.2. A handover-latency study built
   on this model sees no spread from a term that genuinely has some.

2. Status 134 is unreachable. A duplicate home address cannot be modelled at all, so no
   scenario can exercise a home agent rejecting a registration.

3. A first registration costs two Binding Updates and draws two Binding Acknowledgements.
   The one-second delay lands just after the mobile node's own one-second retransmission timer
   fires. The retransmitted Binding Update arrives when the Binding Cache entry already exists,
   is therefore read as a re-registration, and is acknowledged immediately -- on top of the
   delayed acknowledgement owed to the original. Both arrive within a millisecond of each other
   (22.714349 and 22.715321 on seed set 1). The retransmission itself is mipv6: InitialBindackTimeoutFirstReg is dead code, first home registration always uses INITIAL_BINDACK_TIMEOUT #1132/mipv6: MIPv6_INITIAL_BINDACK_TIMEOUT_FIRST is 1 s, RFC 6275 specifies 1.5 s #1133; the double
   acknowledgement is this defect.

4. A defect it hides on the mobile node's side. Because status 134 can never be sent, the
   mobile node's handling of it has never run. It logs Binding was rejected. and then, in its
   own words, retransmission is performed anyway as timers are not deleted -- so it retries
   with the ordinary Binding Update backoff and never stops, against RFC 6275 Section 11.7.3.
   That is a separate defect, but it is unreachable until this one is fixed.

Related

• ipv6: a care-of address formed at a handover is registered without Duplicate Address Detection #1140 / ipv6: verify a care-of address before registering it with the home agent #1141 -- a care-of address registered without Duplicate Address Detection: the
  mirror-image defect on the mobile node's side of the same handover.
• mipv6: InitialBindackTimeoutFirstReg is dead code, first home registration always uses INITIAL_BINDACK_TIMEOUT #1132 / mipv6: MIPv6_INITIAL_BINDACK_TIMEOUT_FIRST is 1 s, RFC 6275 specifies 1.5 s #1133 / mipv6: complete a first home registration in a single Binding Update #1134 -- the mobile node's first-registration retransmission timeout, which
  this delay collides with.
• ipv6: the Duplicate Address Detection delay is added to the timeout instead of delaying the first probe #1179 / ipv6: delay the first Duplicate Address Detection probe #1183 -- the same RFC 4862 Section 5.4.2 random term applied to the timeout instead of
  the first probe, in initiateDad().
• Proxy Neighbor Discovery at the home agent (RFC 6275 Section 10.4.1) is a separate defect
  with a separate trigger: Section 10.3.1 governs what must happen before the acknowledgement
  goes out, Section 10.4.1 what must happen on the home link while the binding lives.