Re: [6lo] ND cache entries creation on first-hop routers

[Michael Richardson <[e-mail]>]

Jen Linkova <[e-mail]> wrote:
    >> I didn't really understand 2.2.2: is it exploiting some corner case in the
    >> spec, or maybe just some part I am not well clued in about.  So maybe an
    >> extra paragraph to explain things.

    > It's just using the standard ND process: when the node B receives an
    > NS from node A and that NS contains the node B  address as a target
    > address and SLLAO contains node A LLA,
    > the node B would respond with NA and would create a STALE entry for
    > the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3

I read through https://tools.ietf.org/html/rfc4861#section-7.3.3
and it says:

   The first time a node sends a packet to a neighbor whose entry is
   STALE, the sender changes the state to DELAY and sets a timer to
   expire in DELAY_FIRST_PROBE_TIME seconds.  If the entry is still in
   the DELAY state when the timer expires, the entry's state changes to
   PROBE.  If reachability confirmation is received, the entry's state
   changes to REACHABLE.

   Upon entering the PROBE state, a node sends a unicast Neighbor
   Solicitation message to the neighbor using the cached link-layer
   address.  While in the PROBE state, a node retransmits Neighbor
   Solicitation messages every RetransTimer milliseconds until
   reachability confirmation is obtained.  Probes are retransmitted even
   if no additional packets are sent to the neighbor.  If no response is
   received after waiting RetransTimer milliseconds after sending the
   MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the
   entry SHOULD be deleted.  Subsequent traffic to that neighbor will
   recreate the entry and perform address resolution again.

Is PROBE and DELAY different states? It almost feels like a typo here.

    >> I kinda like the ping all routers trick.

    > I think it's a hack ;( we do have a mechanism for communicating
    > neighbours addresses/reachability called ND. It would be nice to
    > utilise its machinery.
    > Pinging creates additional overhead on routers and could get filtered.
    > But I'd not be surprised if it's the only way we have realistically to
    > mitigate the issue..

Yes, it's a hack.  It leverages existing behaviour, can be deployed
unilaterally by mobile phone makers, and does not require any new state in
the end device, as they don't even have to listen for the ECHO REPLY.

Let me suggest a different hack: use stateful DHCPv6.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-