M_FLOOD includes a TTL. "The message MUST contain a time-to-live (ttl) for the validity of the contents, given as a positive integer value in milliseconds. There is no default; zero indicates an indefinite lifetime."
In any case, floods must be ignored after their TTL expires, obviously. I see that RFC 8995 specifies the TTL as 180000 ms. So there's also: 5. Pick the one with the longest remaining TTL. That should be about the same as #1, but maybe not quite, if we ever decided to vary the TTL in future. Regards Brian On 04-Jan-23 15:08, Michael Richardson wrote:
I've opened ticket: https://github.com/anima-wg/constrained-voucher/issues/260 Assume that a Join Proxy is receiving GRASP M_FLOOD messages on it's uplink (ACP) side. What should it do when it receives announcements from multiple Registrars (distinct v6 locators). Where does it connect to? The choices are: 1. pick most recent announcement 2. pick the one to which a reply was most recently received (or TCP connected successfully) 3. pick one at random 4. pick one in a round-robin fashion If a packet is forwarded to a Registrar, and it does not reply within ?-seconds, does it then drop that registrar from the list (or put it at the back of the list) if it has others? Do any of these choices have implications for security, resilience or deterministic identification of errors? Remember that the pledge can't see any of this. Assume that all announcements are legitimate, but perhaps not all Registrars always function perfectly. It seems that 3. pick one at random either results in random failures, or it results in some probability that a good registrar will get picked on the next try, and the onboarding will occur (resiliency). 4. also guarantees that a new connection is chosen each time. 1 and 2 favour devices which are more active. Round-robin seems the easiest to implement, is deterministic (which is good for unit tests), and allows the load to be distributed easily. Are there any protocol or standard implications? I don't think so, but I wanted to check. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
