Network Time Protocol IPv6 REFID Hash
draft-stenn-ntp-ipv6-refid-hash-00
| Document | Type |
Replaced Internet-Draft
(ntp WG)
Expired & archived
|
|
|---|---|---|---|
| Author | Harlan Stenn | ||
| Last updated | 2016-09-15 (Latest revision 2016-03-14) | ||
| Replaced by | draft-ietf-ntp-refid-updates | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-ntp-refid-updates | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines the value to be used as the REFID for network associations. For IPv4 associations the IPv4 address is used, and for IPv6 associations four octets of the MD5 hash of the IPv6 are used. Often, the REFID is simplistically and incorrectly used to identify upstream servers. While this works in an IPv4 network, it doesn't work for IPv6 associations and may have other problems in an environment with mixed use of IPv4 and IPv6. Specifically, the NTP Project has received a report where the generated IPv6 hash decoded to the IPv4 address of a different machine on the system peer's network. This proposal offers a way for a system to generate a REFID for a system peer that communicates over IPv6 that does not conflict with a valid IPv4-based REFID.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)