There are several problems with around refids in the current RFC.
refids are being used as IPs for tracing.refids are colliding with valid IPv4 addressesIt doesn't help that the stock ntpq -p output shows the refid as an IPv4 address and does not display the association ID. That will be changing soon:
The proposal is comprised of two parts. One is a change to the refid value for IPv6 addresses, and the other goes to a recommended way of selecting a refid that will identify the current host.
To select an IP to be used as the basis for a host's refid:
Call the IPs we have found "list A".
If a mechanism exists to identify when there is a change to an interface, upon such a change repeat the above steps, saving the results in "list B".
For each IP in "list A", see if that IP is in "list B". If it is not, remove the IP from "list A".
For each IP in "list B", see if that IP is in "list A". If it is not, add the IP to the end of "list A".
Assign the first entry in "list A" to candidate_IP.
For each of the remaining IPs in "list A", see if the new IP is "more routable" than the candidate_IP. If it is, remember it as the new candidate_IP.
The following list shows how "routable" an IP is.
For IPv4 addresses, the following list goes from least to most routable:
For IPv6 addresses, the following list goes from least to most routable:
If the candidate_IP is an IPv4 address, use that value for the refid.
If the candidate_IP is an IPv6 address:
md5 hash of the addressrefid to (0xF0000000. 0xF0000000, or 0xFF000000)refid.The choices in the IPv6 case go to "how many bits do we want to use" and "how do we want the refid value to look".
The content of this page was last updated on 2015-06-09. It was migrated from the old Trac wiki on 2022-12-19.