分享
 
 
 

RFC1982 - Serial Number Arithmetic

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group R. Elz

Request for Comments: 1982 University of Melbourne

Updates: 1034, 1035 R. Bush

Category: Standards Track RGnet, Inc.

August 1996

Serial Number Arithmetic

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

This memo defines serial number arithmetic, as used in the Domain

Name System. The DNS has long relied upon serial number arithmetic,

a concept which has never really been defined, certainly not in an

IETF document, though which has been widely understood. This memo

supplies the missing definition. It is intended to update RFC1034

and RFC1035.

1. IntrodUCtion

The serial number field of the SOA resource record is defined in

RFC1035 as

SERIAL The unsigned 32 bit version number of the original copy of

the zone. Zone transfers preserve this value. This value

wraps and should be compared using sequence space

arithmetic.

RFC1034 uses the same terminology when defining secondary server zone

consistency procedures.

Unfortunately the term "sequence space arithmetic" is not defined in

either RFC1034 or RFC1035, nor do any of their references provide

further information.

This phrase seems to have been intending to specify arithmetic as

used in TCP sequence numbers [RFC793], and defined in [IEN-74].

Unfortunately, the arithmetic defined in [IEN-74] is not adequate for

the purposes of the DNS, as no general comparison operator is

defined.

To avoid further problems with this simple field, this document

defines the field and the operations available upon it. This

definition is intended merely to clarify the intent of RFC1034 and

RFC1035, and is believed to generally agree with current

implementations. However, older, superseded, implementations are

known to have treated the serial number as a simple unsigned integer,

with no attempt to implement any kind of "sequence space arithmetic",

however that may have been interpreted, and further, ignoring the

requirement that the value wraps. Nothing can be done with these

implementations, beyond extermination.

2. Serial Number Arithmetic

Serial numbers are formed from non-negative integers from a finite

subset of the range of all integer values. The lowest integer in

every subset used for this purpose is zero, the maximum is always one

less than a power of two.

When considered as serial numbers however no value has any particular

significance, there is no minimum or maximum serial number, every

value has a successor and predecessor.

To define a serial number to be used in this way, the size of the

serial number space must be given. This value, called "SERIAL_BITS",

gives the power of two which results in one larger than the largest

integer corresponding to a serial number value. This also specifies

the number of bits required to hold every possible value of a serial

number of the defined type. The operations permitted upon serial

numbers are defined in the following section.

3. Operations upon the serial number

Only two operations are defined upon serial numbers, addition of a

positive integer of limited range, and comparison with another serial

number.

3.1. Addition

Serial numbers may be incremented by the addition of a positive

integer n, where n is taken from the range of integers

[0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the

result of such an addition, s', is defined as

s' = (s + n) modulo (2 ^ SERIAL_BITS)

where the addition and modulus operations here act upon values that

are non-negative values of unbounded size in the usual ways of

integer arithmetic.

Addition of a value outside the range

[0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.

3.2. Comparison

Any two serial numbers, s1 and s2, may be compared. The definition

of the result of this comparison is as follows.

For the purposes of this definition, consider two integers, i1 and

i2, from the unbounded set of non-negative integers, such that i1 and

s1 have the same numeric value, as do i2 and s2. Arithmetic and

comparisons applied to i1 and i2 use ordinary unbounded integer

arithmetic.

Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,

in all other cases, s1 is not equal to s2.

s1 is said to be less than s2 if, and only if, s1 is not equal to s2,

and

(i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or

(i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))

s1 is said to be greater than s2 if, and only if, s1 is not equal to

s2, and

(i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or

(i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))

Note that there are some pairs of values s1 and s2 for which s1 is

not equal to s2, but for which s1 is neither greater than, nor less

than, s2. An attempt to use these ordering operators on such pairs

of values produces an undefined result.

The reason for this is that those pairs of values are such that any

simple definition that were to define s1 to be less than s2 where

(s1, s2) is such a pair, would also usually cause s2 to be less than

s1, when the pair is (s2, s1). This would mean that the particular

order selected for a test could cause the result to differ, leading

to unpredictable implementations.

While it would be possible to define the test in such a way that the

inequality would not have this surprising property, while being

defined for all pairs of values, such a definition would be

unnecessarily burdensome to implement, and difficult to understand,

and would still allow cases where

s1 < s2 and (s1 + 1) > (s2 + 1)

which is just as non-intuitive.

Thus the problem case is left undefined, implementations are free to

return either result, or to flag an error, and users must take care

not to depend on any particular outcome. Usually this will mean

avoiding allowing those particular pairs of numbers to co-exist.

The relationships greater than or equal to, and less than or equal

to, follow in the natural way from the above definitions.

4. Corollaries

These definitions give rise to some results of note.

4.1. Corollary 1

For any sequence number s and any integer n such that addition of n

to s is well defined, (s + n) >= s. Further (s + n) == s only when

n == 0, in all other defined cases, (s + n) > s.

4.2. Corollary 2

If s' is the result of adding the non-zero integer n to the sequence

number s, and m is another integer from the range defined as able to

be added to a sequence number, and s" is the result of adding m to

s', then it is undefined whether s" is greater than, or less than s,

though it is known that s" is not equal to s.

4.3. Corollary 3

If s" from the previous corollary is further incremented, then there

is no longer any known relationship between the result and s.

4.4. Corollary 4

If in corollary 2 the value (n + m) is such that addition of the sum

to sequence number s would produce a defined result, then corollary 1

applies, and s" is known to be greater than s.

5. Examples

5.1. A trivial example

The simplest meaningful serial number space has SERIAL_BITS == 2. In

this space, the integers that make up the serial number space are 0,

1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1.

In this space, the largest integer that it is meaningful to add to a

sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.

Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.

Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether

2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.

5.2. A slightly larger example

Consider the case where SERIAL_BITS == 8. In this space the integers

that make up the serial number space are 0, 1, 2, ... 254, 255.

255 == 2^SERIAL_BITS - 1.

In this space, the largest integer that it is meaningful to add to a

sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.

Addition is as eXPected in this space, for example: 255+1 == 0,

100+100 == 200, and 200+100 == 44.

Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,

200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.

Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing

a serial number can cause it to become "smaller". Of course,

incrementing by a smaller number will allow many more increments to

be made before this occurs. However this is always something to be

aware of, it can cause surprising errors, or be useful as it is the

only defined way to actually cause a serial number to decrease.

The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and

255 are not equal, but in each pair, neither number is defined as

being greater than, or less than, the other.

It could be defined (arbitrarily) that 128 > 0, 129 > 1,

130 > 2, ..., 255 > 127, by changing the comparison operator

definitions, as mentioned above. However note that that would cause

255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a

definition, apart from being arbitrary, would also be more costly to

implement.

6. Citation

As this defined arithmetic may be useful for purposes other than for

the DNS serial number, it may be referenced as Serial Number

Arithmetic from RFC1982. Any such reference shall be taken as

implying that the rules of sections 2 to 5 of this document apply to

the stated values.

7. The DNS SOA serial number

The serial number in the DNS SOA Resource Record is a Serial Number

as defined above, with SERIAL_BITS being 32. That is, the serial

number is a non negative integer with values taken from the range

[0 .. 4294967295]. That is, a 32 bit unsigned integer.

The maximum defined increment is 2147483647 (2^31 - 1).

Care should be taken that the serial number not be incremented, in

one or more steps, by more than this maximum within the period given

by the value of SOA.expire. Doing so may leave some secondary

servers with out of date copies of the zone, but with a serial number

"greater" than that of the primary server. Of course, special

circumstances may require this rule be set aside, for example, when

the serial number needs to be set lower for some reason. If this

must be done, then take special care to verify that ALL servers have

correctly succeeded in following the primary server's serial number

changes, at each step.

Note that each, and every, increment to the serial number must be

treated as the start of a new sequence of increments for this

purpose, as well as being the continuation of all previous sequences

started within the period specified by SOA.expire.

Caution should also be exercised before causing the serial number to

be set to the value zero. While this value is not in any way special

in serial number arithmetic, or to the DNS SOA serial number, many

DNS implementations have incorrectly treated zero as a special case,

with special properties, and unusual behaviour may be expected if

zero is used as a DNS SOA serial number.

8. Document Updates

RFC1034 and RFC1035 are to be treated as if the references to

"sequence space arithmetic" therein are replaced by references to

serial number arithmetic, as defined in this document.

9. Security Considerations

This document does not consider security.

It is not believed that anything in this document adds to any

security issues that may exist with the DNS, nor does it do anything

to lessen them.

References

[RFC1034] Domain Names - Concepts and Facilities,

P. Mockapetris, STD 13, ISI, November 1987.

[RFC1035] Domain Names - Implementation and Specification

P. Mockapetris, STD 13, ISI, November 1987

[RFC793] Transmission Control protocol

Information Sciences Institute, STD 7, USC, September 1981

[IEN-74] Sequence Number Arithmetic

William W. Plummer, BB&N Inc, September 1978

Acknowledgements

Thanks to Rob Austein for suggesting clarification of the undefined

comparison operators, and to Michael Patton for attempting to locate

another reference for this procedure. Thanks also to members of the

IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.

Authors' Addresses

Robert Elz Randy Bush

Computer Science RGnet, Inc.

University of Melbourne 10361 NE Sasquatch Lane

Parkville, Vic, 3052 Bainbridge Island, Washington, 98110

Australia. United States.

EMail: kre@munnari.OZ.AU EMail: randy@psg.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有