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.