© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
(In reply to comment #7)
> Good idea, and the "problem" is the refid is a 32-bit structure.
>
> Its purpose is for loop detection - to make sure machine A doesn't
> believe time from machine B if machine B is getting its time from A.
>
> I've had some chats with Prof. Mills about this and we're gently
> discussing changing the refid value for non-refclock sources to a simple
> nonce.
That's a separate issue from displaying the full server address. I actually have some where a subnet has the several servers, and I can't tell them apart; the initial part of the IP address matches several machines, and some machines have both A and AAAA records...so the names aren't unique either. it isn't pretty.
As far as the reference address - I thought that for IPv6, the refid was a hash of the IPv6 address - which means it's already a nonce. There's some small probability of a collision (2 + n in 4 billion - 1 for IPv4 and 1 for IPv6 + the possibility that an IP address or hash turns out to be one of the refclock tags - e.g. .GPS., .PPS., .INIT etc - in binary).
Now that bits are cheaper, perhaps NTPv5 can allocate 136 bits -- 8 for an entity id (IPv4 address, IPv6 address, and Refclock to start with) + a full IPv6 address at the end of the packet. Oooh - NTPv5? Well, maybe not. Just think of all the firewalls and other chaos ;-)
In any case, displaying the full server IP address would be a big help.
I don't have a strong opinion on whether the expanded format should require a command-line switch - such as -w. IPv6 will require any scripts that parse the text to change anyway - and humans won't care. But it would be a way to guarantee backward compatibility.
Anyhow, after 4 years, it would be nice to see this addressed...IPv6 IS gathering steam.
Thanks.