IPv6: use correct timeout value after first NS message

[djs55]

Previously the following could happen:

• client sends an IPv6 packet while the stack is initialising: perfectly legitimate;
• the packet would be queued: as requested by the RFC;
• a "Neighbor Solicitation" message would be sent and lost: still good;
• an entry in the IpMap would be created mapping to INCOMPLETE with an erroneously high initial timeout of ~30s

The logic inside tick_one would correctly set the timeout to now + retrans_timer for second and subsequent retransmits, but the initial timeout is erroneously set to the now reachable_time which is typically very long (~30s).

From RFC2461 section 4.2:

 Reachable Time 32-bit unsigned integer.  The time, in
       milliseconds, that a node assumes a neighbor is
       reachable after having received a reachability
       confirmation.  Used by the Neighbor Unreachability
       Detection algorithm (see Section 7.3).  A value of
       zero means unspecified (by this router).

 Retrans Timer  32-bit unsigned integer.  The time, in
       milliseconds, between retransmitted Neighbor
       Solicitation messages.  Used by address resolution
       and the Neighbor Unreachability Detection algorithm
       (see Sections 7.2 and 7.3).  A value of zero means
       unspecified (by this router).

This PR:

• removes the sleep from the IPv6 UDP unit test to expose the bug
• sets the initial NS timeout to the "Retrans timer" rather than the "Reachable Time" since we've not yet received a reachability confirmation.

Fixes #330

[djs55]

OK I think the relevant part of RFC2461 is 7.2.2:

While awaiting a response, the sender SHOULD retransmit Neighbor
Solicitation messages approximately every RetransTimer milliseconds,
even in the absence of additional traffic to the neighbor.
Retransmissions MUST be rate-limited to at most one solicitation per
neighbor every RetransTimer milliseconds.

If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
solicitations, address resolution has failed. The sender MUST return
ICMP destination unreachable indications with code 3 (Address
Unreachable) for each packet queued awaiting address resolution.

It looks like this is supposed to happen via the tick function. I'll investigate to see why this isn't working.

[djs55]

OK, I now believe I've fixed this properly. The problem seems to be that the initial timeout when a NeighborCache entry is set to INCOMPLETE is erroneously based on the "Reachable Time" which is the time to assume a confirmed table entry is valid instead of the "Retrans timer" which is the expected interval between initial transmitted probes.

The second and subsequent probes would have their timeouts set correctly to now + retrans_timer but the initial probe has a bad timeout of now + reachable_time. Since reachable_time is of the order of 20-30s it causes excessive packet loss and breaks the test. Using the expected 1s retrans_timer fixes the test.

[yomimono]

I won't have time today to page enough ipv6 stuff into my head to review this properly, but I'll try to get to it soon.

[djs55]

No worries -- I don't think it's particularly urgent. I mainly investigated to learn a little about IPv6, to prepare myself for the day when my broadband provider finally rolls it out (any year now!)

[hannesm]

what is the status of this PR? does it improve the current IPv6 implementation? if yes, I'd be in favour of merging (esp. since I've some API changes and need to adapt ipv6.ml as well and am scared of merge conflicts). :)

[djs55]

I'm fairly confident it fixes a real bug in the IPv6 implementation but I'm much less familiar with it than I am with the IPv4 implementation. However I think we should probably merge this (and figure out how to use and test IPv6 more in future)

[avsm]

Reading RFC2461, this also looks correct to me. Merging!