I was refering to 'xid'. So it sounds like it is expected for the same client to use the same xid across different negotiations, which would explain what I am seeing.
On Tue, Dec 12, 2017 at 8:23 AM, Tomek Mrugalski <tom...@isc.org> wrote: > W dniu 11.12.2017 o 22:38, Munroe Sollog pisze: > > Can someone help me understand how the tsid field is generated? What is > > used to generate that hash? I’m tracking DHCP performance based on the > > tsid and I’m seeing a very small percentage of long transaction time > > that may be explained by colliding tsids. > Are you asking about transaction-id, a 32 (in DHCPv4) or 24 (in DHCPv6) > bit field in the DHCP message or tsig, a signature used to protect DNS > updates? You mentioned a hash, which suggests the latter. Anyway, here > are brief answers to both. > > xid, or transaction-id, is not a hash. It is supposed to be set by a > client to a random value, but some clients set it a special value. Kea > doesn't pay much attention to it, except it being echoed back in its > responses. This value is used by clients to match responses to their > outstanding transmissions. For details, see RFC2131, Section 2, page 10. > > tsig, or transaction signature is used to sign DNS updates. Kea supports > a number of algorithms (hmac-md5, hmac-sha1 and others, see Section > 11.3.2 for details: > http://kea.isc.org/docs/kea-guide.html#d2-tsig-key-list-config). This > mechanism is defined in RFC2845. I haven't looked at the details, but I > presume it protects the whole content of the DNS message, so everything > in the DNS update message, a timestamp and a secret key are used to > generate that digest. > > Hope that helps. > Tomek > _______________________________________________ > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users > -- Munroe Sollog Senior Network Engineer mun...@lehigh.edu
_______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users