idnits 2.17.1 draft-boudreault-ipv6-ntp-refid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 444 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 207 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 13, 2001) is 8172 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2373' on line 216 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J-F. Boudreault 3 Internet-Draft Marc Blanchet 4 Expires: May 13, 2002 Viagenie inc. 5 November 13, 2001 7 Reference ID for NTPv6 8 draft-boudreault-ipv6-ntp-refid-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 13, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document proposes a solution to solve the reference ID 40 issue for IPv6 NTP secondary server. 42 Table of Contents 44 1. Definition of Reference ID in NTP Protocol 45 2. Problem Statement 46 3. Protocol Change 47 3.1 Description 48 3.2 Impacts 49 3.3 Implementation 50 4. Using Timestamps 51 4.1 Description 52 4.2 Impacts 53 4.3 Implementation 54 5. Ipv6 Address Compression 55 5.1 Description 56 5.2 Impacts 57 5.3 Implementation 58 6. Discussion on solutions 59 7. Acknowledgements 61 1. Definition of reference ID in NTP protocol 63 According to RFC 1305 (Network Time Protocol Version 3), 64 Reference Clock Identifier "is a 32-bit code identifying the 65 particular reference clock. In the case of stratum 0 (unspecified) 66 of stratum 1 (primary reference), this is a four-octet, 67 left-justified, zero-padded ASCII string. [...] In the case of 68 stratum 2 and greater (secondary reference) this is the four-octet 69 Internet address of the primary reference host." Reference ID is 70 included as a 32-bits field in every NTP packet. 72 This reference ID is essential to avoid 'loopback' during the 73 selection of synchronization source for NTP server. A 'loopback' happens 74 when a NTP server choose a reference source that is a secondary NTP server 75 who use itself as a source. This result in false synchronization. 76 Reference ID being the IPv4 address of the reference source, one can avoid 77 'loopback' by comparing this field (from NTP server reply packet) with our 78 IPv4 address, and reject the potential source if they are equal. 80 2. Problem Statement 82 The Reference ID is a 32 bits field in the NTP packet definition. 83 It is enough for IPv4 32 bits addresses but not enough for IPv6 128 bits 84 addresses. There is a problem if a secondary server is using a IPv6-only 85 NTP server as reference source. We need a way to avoid 'loopback' for 86 synchronization of secondary NTP server with a IPv6-only NTP server. 88 In this document we present our understanding of three 89 possible solutions. The first solution is to change the size of 90 reference ID field in NTP packet definition from 32 bits to 128 bits. 91 The second solution is to use timestamps informations to avoid 'loopback'. 92 The third solution is to apply an algorithm the IPv6 address to compress 93 it to 32 bits and use these IPv6-compressed address in reference ID. 95 3. Protocol Change 97 3.1 Description 99 A solution is to change the reference ID field from 32 bits to 100 128 bits. This way one could put IPv6 source as reference ID 101 and IPv6 embedded IPv4 for IPv4 source. We need to change NTP 102 packet definition to modify reference ID field from 32 bits to 103 128 bits. 105 3.2 Impacts 107 By using a new protocol definition for ntp packet, this breaks 108 the support for old version of ntp. To support them, one needs 109 to implement both versions of ntp packet, one with 32 bits 110 reference id and one with 128 bits reference id. When a server 111 receives a packet, it first puts it in a buffer structure to 112 look at the version field, and decide which structure to use 113 according to ntp version. When server will reply to request, 114 it will need to make sure it respond with the same version 115 and use the correct packet definition that the client support. 116 If a secondary server using IPv6 reference source receive a 117 request from an old version client, it will need to ignore it 118 because it will not be able to put his reference id in the old ntp 119 packet definition. This will need an important redefinition 120 of ntp specifications. 122 3.3 Implementation 124 To change the size of reference ID, one needs to modify 125 the definition of NTP packet structure. This will have 126 big impact on compatiblity with older versions of NTP. 127 To maintain this compatiblity, one will need to support 128 old packet format. It means that it needs to implement 129 both NTP packet structure definitions, one with a 130 32 bits reference ID field and one with a 128 bits 131 reference ID field. 133 In reception procedure, the server will need to first put the 134 packet in a NTP structure buffer, analyze the version 135 of the packet and put it in the correct NTP packet 136 structure. 138 In transmission procedure, the server will need to first know 139 the NTP version of the destination, and put 140 informations in correct packet format. In every 141 procedure that use reference ID, one will need to support 142 both versions and test every time to know which version 143 is used. 145 4. Using Timestamps 147 4.1 Description 149 This was first proposed by David L. Mills in RFC 2030 (Simple Network 150 Time Protocol Version 4) to resolve reference id problem for IPv6 151 source. By using other informations from ntp packet, one could avoid 152 loopback by comparing timestamps of the last transmitted packet from 153 reference source and originate timestamp of the reply from ntp server. 154 When a reference source is selected, each time ntp server receive a 155 packet from this source, it will update his reference id to the low 156 32 bits of transmit timestamp field from this ntp packet. 158 When a ntp server is looking for synchronization source, it will 159 compare the low 32 bits from originate timestamp field of ntp reply 160 packet (this will correspond to his transmit timestamp from request) 161 with reference id field. If they are equal, that is because this server 162 updated his reference id after received the request packet, and 163 that means that it is using this server as synchronization source. 164 In this case it needs to be discarded. 166 4.2 Impacts 168 It could append that a ntp request packet is send to a 169 ntp server at the same time than the reference source of 170 this server send it a packet. By this way, the ntp 171 server will adjust his reference id to transmit time from 172 his ntp source. If this value is the same than the 173 transmit timestamp of ntp request packet, the requester 174 will reject this server even if it is not using itself 175 as a source. This way could reject a good potential 176 source of synchronization. 178 4.3 Implementation 180 In clock update procedure, when the stratum of system 181 is more than 1 (secondary server), the server will put the low 182 32 bits from transmit timestamp of the last received 183 NTP packet from reference source. 185 In clock selection procedure, the server needs to modifiy 186 loopback detection test to compare reference ID 187 field with originate timestamp field. 189 In reception procedure, every time the server receive a packet 190 from our reference source, it will need to update reference 191 ID with the low 32 bits of the transmit timestamp field. 193 Depending on the exact implementation of NTP, one need 194 to be sure we can obtain the informations we need to 195 use this solution. That could be a problem in some 196 implementations. 198 5. IPv6 Address Compression 200 5.1 Description 202 By applying a compression algorithm, one could compress 203 IPv6 addresses to 32 bits and put the compressed address 204 as the Reference Id. The proposed way is to ignore 205 some bits because of some assumptions in the use of these 206 bits in the IPv6 address. 208 In order to avoid to overlap the IPv4 address space in the 209 reference ID field, the leftmost 3 bits of the Reference ID 210 field is '111'b when an IPv6 address is compressed in the 211 reference ID. '111' in the first 3 bits correspond to the 212 Class D and E IPv4 addresses. Since this address space is 213 not used for Reference ID field, this gives no overlap between 214 the two spaces. 216 The IPv6 address architecture [RFC2373] defines specific 217 boundaries in the address as shown below. 219 | 3 | 13 | 32 | 16 | 64 bits | 220 +---+-----+---------------------+--------+-----------------+ 221 |001| TLA | NLA ID | SLA ID | Interface ID | 222 +---+-----+---------------------+--------+-----------------+ 224 The last 64 bits is the interface ID. If the NTP server uses 225 autoconfig with a unique layer2 identifier, then this is identified 226 by a "uniqueness" bit in the EUI-64 format used in the Interface ID. 227 This identifier is used for the Reference ID. If the identifier is 228 more than 32 bits (for example: Ethernet 48 bits), then the 229 last rightmost 28 bits (32 - 3 - 1 bits) are used for the Reference ID. 230 and one bit is 1 for identifying a unique address. 232 If the NTP server is not having a unique interface identifier 233 in its address, then the following assumptions are made: 234 - we expect that most NTP server sites that are interconnected 235 will only have one or a few NTP servers. This means that the 236 differentiator is mostly based on the identification of the site 237 instead of the host. The algorithm will try to use most of the 238 site identification (the first 48 bits) instead of the subnet id 239 (the next 16 bits) or interface id (the last 64 bits). 240 - because of the compression of 0 in writing IPv6 addresses makes 241 easier to put most zeros in a manually assigned address, then 242 most of the leftmost bits in the rightmost 64 bits of the 243 address will be all zeros. So this compression algorithm will 244 only use the rightmost 4 bits of the rightmost 64 bits of the 245 address. 246 - for the same reason of zero compression for writing, the 247 SLA ID will usually have many zeros at the left. This algorithm 248 only uses the rightmost 4 bits of this field. 249 - since the current addressing architecture is only defined for 250 the 001 as the first three bits, these bits are redundant and 251 not used. 252 - this leaves us with 45 bits of TLA/NLA bits and only 32-3-4-4=21 253 bits left. For no real reasons except the basis of the current 254 allocation policies, this algorithm uses the 255 rightmost 4 bits of the TLA field and the rightmost 17 bits of the 256 NLA field. 258 The chosen bits are identified with the number of bits below 259 the following figure. 261 | 3 | 13 | 32 | 16 | 64 bits | 262 +---+-----+---------------------+--------+-----------------+ 263 |001| TLA | NLA ID | SLA ID | Interface ID | 264 +---+-----+---------------------+--------+-----------------+ 265 |4| | 16 | |4| |4| 267 5.2 Algorithm 269 5.2.1 Unique Interface ID of the IPv6 address based on EUI-64 271 If the IPv6 address has the "uniqueness" bit on, then 272 the reference ID is composed of the following fields: 273 | 4 | 4 | 24 | 274 +----+----+-------------------------+ 275 |1111| A | B | 276 +----+----+-------------------------+ 277 | 32 | 279 The compression algorithm is the following: 280 - the first leftmost 4 bits are '1111'b. 281 - the next 4 bits, identified as A in the previous figure, 282 are the 16-19 bits of the Interface ID 283 of the IPv6 address, counting with 0 as the leftmost bit 284 of the Interface ID field (of 64 bits). 285 - the next 24 bits, identified as B in the previous figure, 286 are the rightmost 24 bits of the IPv6 address. 288 TBD: discussion on 64 bits EUI-64 identifiers 290 5.2.2 Non unique Interface ID 292 The reference ID is then composed of the following fields: 293 | 4 | 4 | 16 | 4 | 4 | 294 +----+----+-----------------+----+----+ 295 |1110| A | B | C | D | 296 +----+----+-----------------+----+----+ 297 | 32 | 299 The compression algorithm is the following: 300 - the rightmost 3 bits are '111'b 301 - the next field, identified as A, is of 4 bits and the bits 302 are the 12-15th bits of the IPv6 address, starting with zero as the 303 leftmost bit. 304 - the next field, identified as B, is of 16 bits and the bits 305 are the 42-47th bits of the IPv6 address, starting with zero as the 306 leftmost bit. 307 - the next field, identified as C, is of 4 bits and the bits 308 are the 60-63th bits of the IPv6 address, starting with zero as 309 the leftmost bit. 310 - the last field, identified as D, is of 4 bits and the bits 311 are the rightmost 4 bits of the IPv6 address. 313 5.2 Impacts 315 This compression algorithm is obviously going to produce some 316 false hits. Our current understanding of the previous proposal 317 based on Timestamps tells us that that proposal also exhibits 318 some false hits. Which one is more probable than the other 319 is difficult to guess. We consider for now essentially equal 320 unless the contrary is demonstrated. 322 By compressing IPv6 address, it could append that two 323 IPv6 addresses give the same 32-bits compressed address. 324 If this append, a ntp server could reject a source that 325 use a reference server with the same IPv6-compressed 326 address. So we could reject a good potential source of 327 synchronization due to IPv6-compressed addresses conflict. 329 TBD: discussion on other addresses: link-local, site-local, 330 ipv4-compatible, 6to4, ... 332 5.3 Implementation 334 Each time one uses IPv6 address to create or compare reference id, we 335 just need to apply the algorithm to obtain 32 bits IPv6-compressed 336 address that will fit the field. By this way we will be able to 337 avoid 'loopback' by comparing reference source IPv6-compressed 338 address with our IPv6-compressed address. They will be the same if 339 we are the reference source and we apply the same algorithm to 340 compress IPv6 address. 342 Every time we set reference ID from IP address or 343 compare IP address with reference ID, we will apply 344 a algorithm to the IP address. This algorithm will 345 return a 32 bits address corresponding to the complete 346 IPv4 address or compressed IPv6 address. 348 The key advantage of this proposal is the fact that it is very 349 easy to compute the reference ID. In fact, it has been implemented 350 with a small C macro on the current IPv6 branch of the ntpd code. 352 It also brings backward compatibility with IPv4 servers already 353 in place. 355 6. Discussion on Solutions 357 There is no 'perfect' solution for this problem. Every 358 solutions has some consequences. In both case of using 359 timestamps or IPv6 compressed address, we could have 360 conflicts and reject good potential source of reference. 361 And changing of the protocol definition without braking 362 compatibility with older version has important implications 363 for deployment and version negociation. 365 We believe that using IPv6-compressed address is the 366 better solution. Being easy to implement, we could 367 minimise the possiblity of conflict with a good 368 compression algorithm. 370 7. Acknowledgements 371 TBD 373 8. References 374 TBD 376 9. Authors' Addresses 378 Jean-Francois Boudreault 379 Viagenie inc. 380 2875 boul. Laurier, bureau 300 381 Sainte-Foy, QC G1V 2M2 382 Canada 384 Phone: +1 418 656 9254 385 EMail: Jean-Francois.Boudreault@viagenie.qc.ca 386 URI: http://www.viagenie.qc.ca/ 388 Marc Blanchet 389 Viagenie inc. 390 2875 boul. Laurier, bureau 300 391 Sainte-Foy, QC G1V 2M2 392 Canada 394 Phone: +1 418 656 9254 395 EMail: Marc.Blanchet@viagenie.qc.ca 396 URI: http://www.viagenie.qc.ca/ 398 Full Copyright Statement 400 Copyright (C) The Internet Society (2001). All Rights Reserved. 402 This document and translations of it may be copied and furnished to 403 others, and derivative works that comment on or otherwise explain it 404 or assist in its implementation may be prepared, copied, published 405 and distributed, in whole or in part, without restriction of any 406 kind, provided that the above copyright notice and this paragraph are 407 included on all such copies and derivative works. However, this 408 document itself may not be modified in any way, such as by removing 409 the copyright notice or references to the Internet Society or other 410 Internet organizations, except as needed for the purpose of 411 developing Internet standards in which case the procedures for 412 copyrights defined in the Internet Standards process must be 413 followed, or as required to translate it into languages other than 414 English. 416 The limited permissions granted above are perpetual and will not be 417 revoked by the Internet Society or its successors or assigns. 419 This document and the information contained herein is provided on an 420 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 421 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 422 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 423 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 424 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Acknowledgement 428 Funding for the RFC Editor function is currently provided by the 429 Internet Society.