There are several problems with around refid
s in the current RFC.
refid
s are being used as IPs for tracing.refid
s 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.