On 1/11/2021 5:22 PM, Martin Duke wrote:
Perhaps I should make some edits for clarity!
On Mon, Jan 11, 2021, 16:52 Christian Huitema <[email protected]
<mailto:[email protected]>> wrote:
I am looking at the text of section 4.2, and I am not sure how I
would implement that. What should be the value of the config
rotation bits in CID created by the server?
Any config includes the corresponding CR bits, and when generating the
CID it would use those bits.
The confusing part is that, for this algorithm, a usable SID has to be
extracted from any CID, hence all the weird stuff about CIDs with
undefined configs.
Aside from that, it's like PCID: any server-generated CID uses the CR
bits in the config, optional length encoding, SID, server-use octets.
Should the 6 other bits in the first octet be set to a CID Len or
to a random value?
It depends on the rest of the config, as with the other algorithms.
Issss the timer set when the server ID is first added to the
table, or is the timer reset each time a packet is received with
that CID? In the latter case, is it reset when any packet is
received, or only when a "first initial" packet is received?
When any packet is received with that SID (not CID), the expiration is
refreshed.
OK. So we can have the following:
1) Server learns of Server-ID = X.
2) Server creates new CID with that server ID, uses it to complete
handshake.
3) Client maintains a long running connection with that CID.
4) Server keeps receiving messages with CID pointing to server-ID = X
5) server-ID=X never expires.
Is that by design?
-- Christian Huitema
