Hi Pascal, On Wed, Jul 3, 2019 at 6:18 PM Pascal Thubert (pthubert) <[email protected]> wrote: > The routers that Michael is talking about are real routers, deployed in large > volumes in the field, e.g., in Smartgrid networks. > They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then > operate RPL routing within the ML subnet. > It would be great to have a section that describes that new ND operation and > shows how it changes the deal. I'd be happy to help you on that if you need. > There are some hints in > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.
Oh, that's an interesting plot twist ;) Migrating from 4861/4862 to 6775/8505? Sounds like smth we might want to explore as a strategy (while the tactical fixes my draft mostly talks about might be still needed too). I'll re-read RFCs 6775/8505 and will be back to you with some questions later..Thanks for the suggestion! > > -----Original Message----- > > From: 6lo <[email protected]> On Behalf Of Jen Linkova > > Sent: mercredi 3 juillet 2019 08:52 > > To: Michael Richardson <[email protected]> > > Cc: [email protected]; 6man <[email protected]>; V6 Ops List <[email protected]>; > > [email protected] > > Subject: Re: [6lo] ND cache entries creation on first-hop routers > > > > On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson > > <[email protected]> wrote: > > > 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. > > > > Disclaimer: I have very limited knowledge in that area. > > > > > 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 next version of the draft will have much more details on discussing the > > security considerations indeed. > > > > > The behaviour 2.2.1. Host Sending Unsolicited NA, should probably > > > never flush an old entry out of the ND. > > > > I'd say that the router behaviour for creating a STALE entry upon receiving > > an > > unsolicited NA should be the same as for creating an entry for any other > > reason (e.g. for receiving an RS with SLLAO). > > The same safety rules shall apply. > > > > > 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. > > > > I guess your routers do purge old stale entries? > > > > > {typo: > > > -It's recommended that thsi functionality is configurable and > > > +It's recommended that this functionality is configurable and } > > > > Thanks, will fix in -01. > > > > > 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 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.. > > > > > > > > Jen Linkova <[email protected]> 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 > > > > [email protected] > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > > -------------------------------------------------------------------- > > > > > > > > > -- > > > Michael Richardson <[email protected]>, Sandelman Software Works > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > 6lo mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lo -- SY, Jen Linkova aka Furry _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
