On Jan 22, 2015, at 7:47 AM, Steffen Nurpmeso <[email protected]> wrote:
> Rob Seaman <[email protected]> wrote: >> I think it’s clear that DNS won’t support all leap second use cases, but >> that it may provide a high reliability / low latency method for some >> specific purposes. Here is PHK’s specific example... > > Below a simple C version for the interested. It doesn't iterate over the > results but only uses the first; it also doesn't provide an encode mode. We should be careful not to settle on a specific encoding yet. PHK himself was discussing different options after providing his python example. Notes on the different parts of the encoding: 1) IPv4 class E - yes, we should do it this way with the expectation that an IPv6 implementation will ultimately replace it, likely with more features, longer checksums, etc. 2) Count of months - yes (as opposed to only supporting June/December, for instance). There is a value here in simplicity and this should simply be an integer count starting with January 1972. Making it more clever would increase the likelihood of bad implementations, plus January = 1 provides for easy modulo arithmetic. 3) Count of leap seconds. Again, keep this as simple as possible and just use an integer representing the explicit difference between TAI and UTC. Due to the huge leverage of the accumulated 35s we're starting with, this can be an unsigned count. (That is, by the time we saw a couple of dozen straight negative leap seconds eating into this total we would start to get the idea that refactoring was necessary.) 4) Flags. The current encoding fits a -1/0/1 triad in two bits. Suggest that this should rather be two separate flags: Is there a leap second? Is the leap second positive or negative? Alternately the fourth case could be used for some separate option, but I haven't been able to see what that would usefully be. 5) CRC. A CRC is a hash/checksum tuned to be sensitive to bit errors, e.g., errors in transport. While catching these is of interest to us, the bigger issue is to detect lies introduced by bogus public wifi, etc. Lies come in the form of different numerical values covering the full range of (non-class E) IP addresses. Many of these will correspond to more than the 8-bit errors mentioned in the python comments. Regarding the current crc8() function, the numbers look about right in that it picks up all 1, 2 and 3 bit errors and then the 4-8 bit errors each correspond to about 1/256 (0.003-0.004) of the corresponding patterns. Hash is a hash is a hash, and any 8-bit hash is going to only catch that fraction of bit patterns overall. Combined with the class E constraint this will give good protection, but we might want to evaluate other types of checksums (1's-complement, perhaps others) if some sorts of lying failure modes are systematically more likely. 6) Size of fields. There is an advantage to using more standard size ints than 11-bit unsigned months and 7-bit signed leap seconds most recently suggested. For instance, a 12-bit month tally would provide coverage for three centuries into the future. And an 8-bit unsigned count would permit more than 200 leap seconds during that time. So the first half of the pseudo-address would be the class E pedestal followed by the months, and the second half would be the leap tally, two flags plus a 6-bit checksum. A 6-bit checksum still would detect more than 98% of the very few errors/lies that manage to get past the class E check. An alternate that would preserve space for the 8-bit CRC would be to combine the "Is there a leap?" flag as a sign bit on a 12-bit signed month tally, and the positive/negative flag as a sign bit on an 8-bit signed TAI-UTC offset. This would provide for 90+ future leap seconds (assuming all positive) over a bit more than a century to come. One might expect we would have transitioned to IPv6 by then, retiring this format naturally. The parsing would be quite straightforward for a 4 + 12 + 8 + 8 layout, and the flags would be recoverable as simple +/- tests, with absolute values for the magnitudes. Plus the simplicity of modulo arithmetic for the month of the year. Presumably we would want 2's-complement ints. Rob _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
