Jen Linkova <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
