Network Time Protocol REFID Updates

The information below is for an old version of the document
Document Type Expired Internet-Draft (ntp WG)
Authors Harlan Stenn  , Sharon Goldberg 
Last updated 2017-05-17 (latest revision 2016-11-13)
Replaces draft-stenn-ntp-ipv6-refid-hash, draft-stenn-ntp-leap-smear-refid, draft-stenn-ntp-not-you-refid
Stream Internet Engineering Task Force (IETF)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines the value of the REFID, the system peer for the responding host. In the past, for IPv4 associations the IPv4 address is used, and for IPv6 associations the first four octets of the MD5 hash of the IPv6 are used. There are at least three shortcomings to this approach, and this proposal will address the three so noted. One is that knowledge of the system peer is "abusable" information and should not be generally available. The second is that the four octet hash of the IPv6 address looks very much like an IPv4 address, and this is confusing. The third is that a growing number of low-stratum servers want to offer leap-smeared time to their clients, and there is no obvious way to know if a server is offering accurate time or leap- smeared time.


Harlan Stenn (
Sharon Goldberg (

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)