Network Working Group J-F. Boudreault
Internet-Draft Marc Blanchet
Expires: May 13, 2002 Viagenie inc.
November 13, 2001
Reference ID for NTPv6
draft-boudreault-ipv6-ntp-refid-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document proposes a solution to solve the reference ID
issue for IPv6 NTP secondary server.
Table of Contents
1. Definition of Reference ID in NTP Protocol
2. Problem Statement
3. Protocol Change
3.1 Description
3.2 Impacts
3.3 Implementation
4. Using Timestamps
4.1 Description
4.2 Impacts
4.3 Implementation
5. Ipv6 Address Compression
5.1 Description
5.2 Impacts
5.3 Implementation
6. Discussion on solutions
7. Acknowledgements
1. Definition of reference ID in NTP protocol
According to RFC 1305 (Network Time Protocol Version 3),
Reference Clock Identifier "is a 32-bit code identifying the
particular reference clock. In the case of stratum 0 (unspecified)
of stratum 1 (primary reference), this is a four-octet,
left-justified, zero-padded ASCII string. [...] In the case of
stratum 2 and greater (secondary reference) this is the four-octet
Internet address of the primary reference host." Reference ID is
included as a 32-bits field in every NTP packet.
This reference ID is essential to avoid 'loopback' during the
selection of synchronization source for NTP server. A 'loopback' happens
when a NTP server choose a reference source that is a secondary NTP server
who use itself as a source. This result in false synchronization.
Reference ID being the IPv4 address of the reference source, one can avoid
'loopback' by comparing this field (from NTP server reply packet) with our
IPv4 address, and reject the potential source if they are equal.
2. Problem Statement
The Reference ID is a 32 bits field in the NTP packet definition.
It is enough for IPv4 32 bits addresses but not enough for IPv6 128 bits
addresses. There is a problem if a secondary server is using a IPv6-only
NTP server as reference source. We need a way to avoid 'loopback' for
synchronization of secondary NTP server with a IPv6-only NTP server.
In this document we present our understanding of three
possible solutions. The first solution is to change the size of
reference ID field in NTP packet definition from 32 bits to 128 bits.
The second solution is to use timestamps informations to avoid 'loopback'.
The third solution is to apply an algorithm the IPv6 address to compress
it to 32 bits and use these IPv6-compressed address in reference ID.
3. Protocol Change
3.1 Description
A solution is to change the reference ID field from 32 bits to
128 bits. This way one could put IPv6 source as reference ID
and IPv6 embedded IPv4 for IPv4 source. We need to change NTP
packet definition to modify reference ID field from 32 bits to
128 bits.
3.2 Impacts
By using a new protocol definition for ntp packet, this breaks
the support for old version of ntp. To support them, one needs
to implement both versions of ntp packet, one with 32 bits
reference id and one with 128 bits reference id. When a server
receives a packet, it first puts it in a buffer structure to
look at the version field, and decide which structure to use
according to ntp version. When server will reply to request,
it will need to make sure it respond with the same version
and use the correct packet definition that the client support.
If a secondary server using IPv6 reference source receive a
request from an old version client, it will need to ignore it
because it will not be able to put his reference id in the old ntp
packet definition. This will need an important redefinition
of ntp specifications.
3.3 Implementation
To change the size of reference ID, one needs to modify
the definition of NTP packet structure. This will have
big impact on compatiblity with older versions of NTP.
To maintain this compatiblity, one will need to support
old packet format. It means that it needs to implement
both NTP packet structure definitions, one with a
32 bits reference ID field and one with a 128 bits
reference ID field.
In reception procedure, the server will need to first put the
packet in a NTP structure buffer, analyze the version
of the packet and put it in the correct NTP packet
structure.
In transmission procedure, the server will need to first know
the NTP version of the destination, and put
informations in correct packet format. In every
procedure that use reference ID, one will need to support
both versions and test every time to know which version
is used.
4. Using Timestamps
4.1 Description
This was first proposed by David L. Mills in RFC 2030 (Simple Network
Time Protocol Version 4) to resolve reference id problem for IPv6
source. By using other informations from ntp packet, one could avoid
loopback by comparing timestamps of the last transmitted packet from
reference source and originate timestamp of the reply from ntp server.
When a reference source is selected, each time ntp server receive a
packet from this source, it will update his reference id to the low
32 bits of transmit timestamp field from this ntp packet.
When a ntp server is looking for synchronization source, it will
compare the low 32 bits from originate timestamp field of ntp reply
packet (this will correspond to his transmit timestamp from request)
with reference id field. If they are equal, that is because this server
updated his reference id after received the request packet, and
that means that it is using this server as synchronization source.
In this case it needs to be discarded.
4.2 Impacts
It could append that a ntp request packet is send to a
ntp server at the same time than the reference source of
this server send it a packet. By this way, the ntp
server will adjust his reference id to transmit time from
his ntp source. If this value is the same than the
transmit timestamp of ntp request packet, the requester
will reject this server even if it is not using itself
as a source. This way could reject a good potential
source of synchronization.
4.3 Implementation
In clock update procedure, when the stratum of system
is more than 1 (secondary server), the server will put the low
32 bits from transmit timestamp of the last received
NTP packet from reference source.
In clock selection procedure, the server needs to modifiy
loopback detection test to compare reference ID
field with originate timestamp field.
In reception procedure, every time the server receive a packet
from our reference source, it will need to update reference
ID with the low 32 bits of the transmit timestamp field.
Depending on the exact implementation of NTP, one need
to be sure we can obtain the informations we need to
use this solution. That could be a problem in some
implementations.
5. IPv6 Address Compression
5.1 Description
By applying a compression algorithm, one could compress
IPv6 addresses to 32 bits and put the compressed address
as the Reference Id. The proposed way is to ignore
some bits because of some assumptions in the use of these
bits in the IPv6 address.
In order to avoid to overlap the IPv4 address space in the
reference ID field, the leftmost 3 bits of the Reference ID
field is '111'b when an IPv6 address is compressed in the
reference ID. '111' in the first 3 bits correspond to the
Class D and E IPv4 addresses. Since this address space is
not used for Reference ID field, this gives no overlap between
the two spaces.
The IPv6 address architecture [RFC2373] defines specific
boundaries in the address as shown below.
| 3 | 13 | 32 | 16 | 64 bits |
+---+-----+---------------------+--------+-----------------+
|001| TLA | NLA ID | SLA ID | Interface ID |
+---+-----+---------------------+--------+-----------------+
The last 64 bits is the interface ID. If the NTP server uses
autoconfig with a unique layer2 identifier, then this is identified
by a "uniqueness" bit in the EUI-64 format used in the Interface ID.
This identifier is used for the Reference ID. If the identifier is
more than 32 bits (for example: Ethernet 48 bits), then the
last rightmost 28 bits (32 - 3 - 1 bits) are used for the Reference ID.
and one bit is 1 for identifying a unique address.
If the NTP server is not having a unique interface identifier
in its address, then the following assumptions are made:
- we expect that most NTP server sites that are interconnected
will only have one or a few NTP servers. This means that the
differentiator is mostly based on the identification of the site
instead of the host. The algorithm will try to use most of the
site identification (the first 48 bits) instead of the subnet id
(the next 16 bits) or interface id (the last 64 bits).
- because of the compression of 0 in writing IPv6 addresses makes
easier to put most zeros in a manually assigned address, then
most of the leftmost bits in the rightmost 64 bits of the
address will be all zeros. So this compression algorithm will
only use the rightmost 4 bits of the rightmost 64 bits of the
address.
- for the same reason of zero compression for writing, the
SLA ID will usually have many zeros at the left. This algorithm
only uses the rightmost 4 bits of this field.
- since the current addressing architecture is only defined for
the 001 as the first three bits, these bits are redundant and
not used.
- this leaves us with 45 bits of TLA/NLA bits and only 32-3-4-4=21
bits left. For no real reasons except the basis of the current
allocation policies, this algorithm uses the
rightmost 4 bits of the TLA field and the rightmost 17 bits of the
NLA field.
The chosen bits are identified with the number of bits below
the following figure.
| 3 | 13 | 32 | 16 | 64 bits |
+---+-----+---------------------+--------+-----------------+
|001| TLA | NLA ID | SLA ID | Interface ID |
+---+-----+---------------------+--------+-----------------+
|4| | 16 | |4| |4|
5.2 Algorithm
5.2.1 Unique Interface ID of the IPv6 address based on EUI-64
If the IPv6 address has the "uniqueness" bit on, then
the reference ID is composed of the following fields:
| 4 | 4 | 24 |
+----+----+-------------------------+
|1111| A | B |
+----+----+-------------------------+
| 32 |
The compression algorithm is the following:
- the first leftmost 4 bits are '1111'b.
- the next 4 bits, identified as A in the previous figure,
are the 16-19 bits of the Interface ID
of the IPv6 address, counting with 0 as the leftmost bit
of the Interface ID field (of 64 bits).
- the next 24 bits, identified as B in the previous figure,
are the rightmost 24 bits of the IPv6 address.
TBD: discussion on 64 bits EUI-64 identifiers
5.2.2 Non unique Interface ID
The reference ID is then composed of the following fields:
| 4 | 4 | 16 | 4 | 4 |
+----+----+-----------------+----+----+
|1110| A | B | C | D |
+----+----+-----------------+----+----+
| 32 |
The compression algorithm is the following:
- the rightmost 3 bits are '111'b
- the next field, identified as A, is of 4 bits and the bits
are the 12-15th bits of the IPv6 address, starting with zero as the
leftmost bit.
- the next field, identified as B, is of 16 bits and the bits
are the 42-47th bits of the IPv6 address, starting with zero as the
leftmost bit.
- the next field, identified as C, is of 4 bits and the bits
are the 60-63th bits of the IPv6 address, starting with zero as
the leftmost bit.
- the last field, identified as D, is of 4 bits and the bits
are the rightmost 4 bits of the IPv6 address.
5.2 Impacts
This compression algorithm is obviously going to produce some
false hits. Our current understanding of the previous proposal
based on Timestamps tells us that that proposal also exhibits
some false hits. Which one is more probable than the other
is difficult to guess. We consider for now essentially equal
unless the contrary is demonstrated.
By compressing IPv6 address, it could append that two
IPv6 addresses give the same 32-bits compressed address.
If this append, a ntp server could reject a source that
use a reference server with the same IPv6-compressed
address. So we could reject a good potential source of
synchronization due to IPv6-compressed addresses conflict.
TBD: discussion on other addresses: link-local, site-local,
ipv4-compatible, 6to4, ...
5.3 Implementation
Each time one uses IPv6 address to create or compare reference id, we
just need to apply the algorithm to obtain 32 bits IPv6-compressed
address that will fit the field. By this way we will be able to
avoid 'loopback' by comparing reference source IPv6-compressed
address with our IPv6-compressed address. They will be the same if
we are the reference source and we apply the same algorithm to
compress IPv6 address.
Every time we set reference ID from IP address or
compare IP address with reference ID, we will apply
a algorithm to the IP address. This algorithm will
return a 32 bits address corresponding to the complete
IPv4 address or compressed IPv6 address.
The key advantage of this proposal is the fact that it is very
easy to compute the reference ID. In fact, it has been implemented
with a small C macro on the current IPv6 branch of the ntpd code.
It also brings backward compatibility with IPv4 servers already
in place.
6. Discussion on Solutions
There is no 'perfect' solution for this problem. Every
solutions has some consequences. In both case of using
timestamps or IPv6 compressed address, we could have
conflicts and reject good potential source of reference.
And changing of the protocol definition without braking
compatibility with older version has important implications
for deployment and version negociation.
We believe that using IPv6-compressed address is the
better solution. Being easy to implement, we could
minimise the possiblity of conflict with a good
compression algorithm.
7. Acknowledgements
TBD
8. References
TBD
9. Authors' Addresses
Jean-Francois Boudreault
Viagenie inc.
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Jean-Francois.Boudreault@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Marc Blanchet
Viagenie inc.
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 656 9254
EMail: Marc.Blanchet@viagenie.qc.ca
URI: http://www.viagenie.qc.ca/
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.