It's important for a JP not to switch to a new preferred Registrar in the middle of a Pledge "session" (i.e. an active TLS or DTLS connection with Registrar).
For a stateful JP, it would be easy to keep state of the selected Registrar: e.g. any Pledge packet coming from same link-local IPv6 address and port can be identified to belong to the particular "session" and be sent to the same Registrar every time. (This also allows a Pledge to change its LL address in-between sessions/attempts, for privacy reasons. Then a next attempt might use a different Registrar as determined by JP.) For a stateless JP, it cannot keep such state per Pledge. What could work there is: 1. Select one Registrar and stick to it. Only allow changing to another Registrar during a period of inactivity, e.g. no Pledge messages were received for some timeout period (> 1 minute?). 2. Select one Registrar out of the N available by a fixed (hash) function that maps a LL IPv6 address to an integer 1 ... N . This allows consistent selection of a Registrar without keeping any state per Pledge. We could add a requirement for the JP that it "picks" a single Registrar per "session", regardless of how that is implemented. If we don't require this, things may start to fail in the multiple-Registrars cases. Or alternatively, require that only 1 Registrar be deployed. The exact selection of a Registrar could be up to JP implementation I think. E.g. prefer the one with longest TTL, or one that worked before (for a JP implementation that can monitor which "sessions" went well or which not.) Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Michael Richardson Sent: Wednesday, January 4, 2023 20:36 To: Brian E Carpenter <[email protected]>; [email protected] Subject: Re: [Anima] how should join proxy react to multiple registrars Brian E Carpenter <[email protected]> wrote: > 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." Sure, so after that time, throw away the announcement. So the list empties itself without a problem. > 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. Yes, okay, I'll take variation. We can throw out announcements that don't work, I think. Let's say one gets a Port Unreachable or No Route to Host. > 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
