idnits 2.17.1 draft-ietf-dnsind-serial-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1996) is 10266 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) == Unused Reference: 'RFC1034' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 308, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEN-74' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Robert Elz 2 Internet Draft University of Melbourne 3 Expiration Date: September 1996 4 Randy Bush 5 RGnet, Inc. 7 March 1996 9 Serial Number Arithmetic 11 draft-ietf-dnsind-serial-02.txt 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-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 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 2. Abstract 33 This draft defines serial number arithmetic, as used in the Domain 34 Name System. The DNS has long relied upon serial number arithmetic, 35 a concept which has never really been defined, certainly not in an 36 IETF document, though which has been widely understood. This draft 37 supplies the missing definition. It is intended to update RFC1034 38 and RFC1035. 40 3. Introduction 42 The serial number field of the SOA resource record is defined in 43 RFC1035 as 45 SERIAL The unsigned 32 bit version number of the original copy of 46 the zone. Zone transfers preserve this value. This value 47 wraps and should be compared using sequence space 48 arithmetic. 50 RFC1034 uses the same terminology when defining secondary server zone 51 consistency procedures. 53 Unfortunately the term "sequence space arithmetic" is not defined in 54 either RFC1034 or RFC1035, nor do any of their references provide 55 further information. 57 This phrase seems to have been intending to specify arithmetic as 58 used in TCP sequence numbers [RFC793], and defined in [IEN-74]. 60 Unfortunately, the arithmetic defined in [IEN-74] is not adequate for 61 the purposes of the DNS, as no general comparison operator is 62 defined. 64 To avoid further problems with this simple field, this document 65 defines the field and the operations available upon it. This 66 definition is intended merely to clarify the intent of RFC1034 and 67 RFC1035, and is believed to generally agree with current 68 implementations. However, older, superseded, implementations are 69 known to have treated the serial number as a simple unsigned integer, 70 with no attempt to implement any kind of "sequence space arithmetic", 71 however that may have been interpreted, and further, ignoring the 72 requirement that the value wraps. Nothing can be done with these 73 implementations, beyond extermination. 75 4. Serial Number Arithmetic 77 Serial numbers are formed from non-negative integers from a finite 78 subset of the range of all integer values. The lowest integer in 79 every subset used for this purpose is zero, the maximum is always one 80 less than a power of two. 82 When considered as serial numbers however no value has any particular 83 significance, there is no minimum or maximum serial number, every 84 value has a successor and predecessor. 86 To define a serial number to be used in this way, the size of the 87 serial number space must be given. This value, called "SERIAL_BITS", 88 gives the power of two which results in one larger than the largest 89 integer corresponding to a serial number value. This also specifies 90 the number of bits required to hold every possible value of a serial 91 number of the defined type. The operations permitted upon serial 92 numbers are defined in the following section. 94 5. Operations upon the serial number 96 Only two operations are defined upon serial numbers, addition of a 97 positive integer of limited range, and comparison with another serial 98 number. 100 5.1. Addition 102 Serial numbers may be incremented by the addition of a positive 103 integer n, where n is taken from the range of integers 104 [0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the 105 result of such an addition, s', is defined as 107 s' = (s + n) modulo (2 ^ SERIAL_BITS) 109 where the addition and modulus operations here act upon values that 110 are non-negative values of unbounded size in the usual ways of 111 integer arithmetic. 113 Addition of a value outside the range 114 [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined. 116 5.2. Comparison 118 Any two serial numbers, s1 and s2, may be compared. The definition 119 of the result of this comparison is as follows. 121 For the purposes of this definition, consider two integers, i1 and 122 i2, from the unbounded set of non-negative integers, such that i1 and 123 s1 have the same numeric value, as do i2 and s2. Arithmetic and 124 comparisons applied to i1 and i2 use ordinary unbounded integer 125 arithmetic. 127 Then, s1 is said to be equal to s2 if and only if i1 is equal to i2, 128 in all other cases, s1 is not equal to s2. 130 s1 is said to be less than s2 if, and only if, s1 is not equal to s2, 131 and 133 (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or 134 (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1)) 136 s1 is said to be greater than s2 if, and only if, s1 is not equal to 137 s2, and 139 (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or 140 (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1)) 142 Note that there are some pairs of values s1 and s2 for which s1 is 143 not equal to s2, but for which s1 is neither greater than, nor less 144 than, s2. An attempt to use these ordering operators on such pairs 145 of values produces an undefined result. 147 The reason for this is that those pairs of values are such that any 148 simple definition that were to define s1 to be less than s2 where 149 (s1, s2) is such a pair, would also usually cause s2 to be less than 150 s1, when the pair is (s2, s1). This would mean that the particular 151 order selected for a test could cause the result to differ, leading 152 to unpredictable implementations. 154 While it would be possible to define the test in such a way that the 155 inequality would not have this surprising property, while being 156 defined for all pairs of values, such a definition would be 157 unnecessarily burdensome to implement, and difficult to understand, 158 and would still allow cases where 160 s1 < s2 and (s1 + 1) > (s2 + 1) 162 which is just as non-intuitive. 164 Thus the problem case is left undefined, implementations are free to 165 return either result, or to flag an error, and users must take care 166 not to depend on any particular outcome. Usually this will mean 167 avoiding allowing those particular pairs of numbers to co-exist. 169 The relationships greater than or equal to, and less than or equal 170 to, follow in the natural way from the above definitions. 172 6. Corollaries 174 These definitions give rise to some results of note 176 6.1. Corollary 1 178 For any sequence number s and any integer n such that addition of n 179 to s is well defined, (s + n) >= s. Further (s + n) == s only when 180 n == 0, in all other defined cases, (s + n) > s. 182 6.2. Corollary 2 184 If s' is the result of adding the integer n to the sequence number s, 185 and m is another integer from the range defined as able to be added 186 to a sequence number, and s" is the result of adding m to s', then it 187 is undefined whether s" is greater than, or less than s, though it is 188 known that s" is not equal to s. 190 6.3. Corollary 3 192 If s" from the previous corollary is further incremented, then there 193 is no longer any known relationship between the result and s. 195 6.4. Corollary 4 197 If in corollary 2 the value (n + m) is such that addition of the sum 198 to sequence number s would produce a defined result, then corollary 1 199 applies, and s" is known to be greater than s. 201 7. Examples 203 7.1. A trivial example 205 The simplest meaningful serial number space has SERIAL_BITS == 2. In 206 this space, the integers that make up the serial number space are 0, 207 1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1. 209 In this space, the largest integer that it is meaningful to add to a 210 sequence number is 2^(SERIAL_BITS - 1) - 1, or 1. 212 Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0. 213 Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether 214 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1. 216 7.2. A slightly larger example 218 Consider the case where SERIAL_BITS == 8. In this space the integers 219 that make up the serial number space are 0, 1, 2, ... 254, 255. 220 255 == 2^SERIAL_BITS - 1. 222 In this space, the largest integer that it is meaningful to add to a 223 sequence number is 2^(SERIAL_BITS - 1) - 1, or 127. 225 Addition is as expected in this space, for example: 255+1 == 0, 226 100+100 == 200, and 200+100 == 44. 228 Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44, 229 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200. 231 Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing 232 a serial number can cause it to become "smaller". Of course, 233 incrementing by a smaller number will allow many more increments to 234 be made before this occurs. However this is always something to be 235 aware of, it can cause surprising errors, or be useful as it is the 236 only defined way to actually cause a serial number to decrease. 238 The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and 239 255 are not equal, but in each pair, neither number is defined as 240 being greater than, or less than, the other. 242 It could be defined (arbitrarily) that 128 > 0, 129 > 1, 243 130 > 2, ..., 255 > 127, by changing the comparison operator 244 definitions, as mentioned above. However note that that would cause 245 255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a 246 definition, apart from being arbitrary, would also be more costly to 247 implement. 249 8. Citation 251 As this defined arithmetic may be useful for purposes other than for 252 the DNS serial number, it may be referenced as Serial Number 253 Arithmetic from RFCXXXX. Any such reference shall be taken as 254 implying that the rules of sections 4 to 7 of this document apply to 255 the stated values. 257 9. The DNS SOA serial number 259 The serial number in the DNS SOA Resource Record is a Serial Number 260 as defined above, with SERIAL_BITS being 32. That is, the serial 261 number is a non negative integer with values taken from the range 262 [0 .. 4294967295]. That is, a 32 bit unsigned integer. 264 The maximum defined increment is 2147483647 (2^31 - 1). 266 Care should be taken that the serial number not be incremented, in 267 one or more steps, by more than this maximum within the period given 268 by the value of SOA.expire. Doing so may leave some secondary 269 servers with out of date copies of the zone, but with a serial number 270 "greater" than that of the primary server. Of course, special 271 circumstances may require this rule be set aside, for example, when 272 the serial number needs to be set lower for some reason. If this 273 must be done, then take special care to verify that ALL servers have 274 correctly succeeded in following the primary server's serial number 275 changes, at each step. 277 Note that each, and every, increment to the serial number must be 278 treated as the start of a new sequence of increments for this 279 purpose, as well as being the continuation of all previous sequences 280 started within the period specified by SOA.expire. 282 Caution should also be exercised before causing the serial number to 283 be set to the value zero. While this value is not in any way special 284 in serial number arithmetic, or to the DNS SOA serial number, many 285 DNS implementations have incorrectly treated zero as a special case, 286 with special properties, and unusual behaviour may be expected if 287 zero is used as a DNS SOA serial number. 289 10. Document Updates 291 RFC1034 and RFC1035 are to be treated as if the references to 292 "sequence space arithmetic" therein are replaced by references to 293 serial number arithmetic, as defined in this document. 295 11. Security Considerations 297 This document does not consider security. 299 It is not believed that anything in this document adds to any 300 security issues that may exist with the DNS, nor does it do anything 301 to lessen them. 303 12. References 305 [RFC1034] Domain Names - Concepts and Facilities, 306 P. Mockapetris, ISI, November 1987. 308 [RFC1035] Domain Names - Implementation and Specification 309 P. Mockapetris, ISI, November 1987 311 [RFC793] Transmission Control protocol 312 Information Sciences Institute, USC, September 1981 314 [IEN-74] Sequence Number Arithmetic 315 William W. Plummer, BB&N Inc, September 1978 317 13. Acknowledgements 319 Thanks to Rob Austein for suggesting clarification of the undefined 320 comparison operators, and to Michael Patton for attempting to locate 321 another reference for this procedure. Thanks also to members of the 322 IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris. 324 14. Author's Address 326 Robert Elz 327 Computer Science 328 University of Melbourne 329 Parkville, Vic, 330 Australia.