I think that the discussion here is particularly relevant to constrained devices/routers on route-over MESH(RPL,etc.) networks.
I also think that for L=0 networks, which RPL creates with RPL DIO messages
rather than (just) RAs, and 6LRs that need to support join operations
(like draft-ietf-6tisch-minimal-security) this may matter.
In particular, in the minimal-security case, we need to partition the ND
cache such that untrusted (unverified) malicious pledge nodes can not
attack the ND cache.
The behaviour 2.2.1. Host Sending Unsolicited NA, should probably
never flush an old entry out of the ND. I think that under attack
(whether from untrusted pledges, or from p0woned devices already on the
network), it is better to prefer communication from existing nodes rather
than new ones. 2.2.1.2 mentions this.
{typo:
-It's recommended that thsi functionality is configurable and
+It's recommended that this functionality is configurable and
}
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.
I kinda like the ping all routers trick.
Jen Linkova <furr...@gmail.com> wrote:
> I wrote a short draft to discuss and document an operational issue
> related to the ND state machine and packet loss caused by how routers
> create ND cache entries for new host addressed:
> https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
> (taking into account some vendors have implemented one of the proposed
> solution already, I guess it's a well-known problem but it might still
> worth documenting)
> Comments are appreciated!
> --
> SY, Jen Linkova aka Furry
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
