Subject: Re: Please advance draft-ietf-dnsind-tsig-09.txt

From: Paul A Vixie <[email-masked]>
Date: Tue, 27 Jul 1999 14:32:20 -0700

> I'm still confused about what "network byte order" means
> on a 48 bit value.  48 bit values lack the symmetry of
> an even power of two.  Maybe I am worrying needlessly
> over a perception of byte vs. word vs. longword ordering.

i think you are, yes.  this isn't about byte swapping or even
halfword swapping or longword swapping.  a portable implementation
of a 48 bit network integer grabber looks like this:

	result = 0;
	for (i = 0; i < 6; i++) {
		result |= src[i];
		result <<= 8;
	}

...so the bits are presumed to come off the wire highest-order-first,
and so are the bytes.  the above snippet assumes that "result" can
hold a 48-bit unsigned value, but does not assume that
	write(fd, &result, sizeof result);
would produce a wire format 48-bit value.

making this work on a 32-bit machine is of course harder.  but as one
who has programmed on vms, i'm not bothered by time values bigger than
my registers.

> Perhaps I'm obsessing on symmetry, and should step back
> to another angle.

yes.

> It occurs to me that the "fudge" will most often be a
> small, non-zero value, to insure against some minimal
> expected/acceptable amount of clock drift.
> 
> Would it be possible to simply state that the clock
> had lower resolution by two or three bits?  That is,
> that the clock had a built in fudge by being (e.g.)
> an "8 second clock" instead of a one-second clock?

i think this should be a protocol element so that the tolerance can
be an implementation and/or operational consideration.

> This would bypass the Y2038 issue for an additional
> (~)910 years if a 32 bit value was used for the time
> with an implied 3 bits of fudge always set.  Since TSIG
> is acknowledged to be a stopgap measure, this should
> be an acceptable tradeoff which avoids the lack of
> 48/64 bit byteorder functions altogether.
> 
> What do you think?

i think a 48-bit time-since-1970 moves this problem ~9 million years
into our future, and as such, has no Y2038 problem.

% calc
> 2**31
        2147483648
> ./(84600*365.25)
        ~69.49751531950492149714
> 1970+.
        ~2039.49751531950492149714
> 2**48
        281474976710656
> ./(84600*365.25)
        ~9109178.32795814907047376792
> 1970+.
        ~9111148.32795814907047376792

anyone who is using binary computers 9 million years from now will be part
of a different epoch and will be a new generation of culture following at
least one nuclear winter.  as such, they will have their own Y2038 problem
and will not have inherited ours.

---

From: [email-masked]
Date: Wed, 28 Jul 1999 11:19:30 +1000

> Jerry Scharf wrote:
> > 
> > Who says that wire format and internal format need to be
> > the same? There is a clear step of converting wire format
> > to internal format when receiving data and converting it
> > back out on sending data. You may have to do this for
> > everything to handle endian issues as well. You have one
> > routine that receives these messages and puts them in a
> > convinient storage and usage method for you.
> 

	Take the top 8 bits, then the next 8 bits ...

> 
> I grant you the distinction between internal and wire
> format, but the specification is for wire format, right?

	Yes.
> 
> I have htonl/htons/ntohl/ntohs, but no htonu_int_48 (or
> the reverse) in the standard 4.2BSD bag of tricks.  I
> think the lack of a standard processing function for
> such values makes implementation error-prone, in a
> largely Intel world.

	So?  There isn't ones for 64 bit values either.
	That does not stop us declaring 64 bit fields.
> 
> I know I likewise have a similar problem with not having
> a htonu_int_64 function (or the reverse), but at least
> symmetry makes misimplementation much more unlikely.
> 

	Always non zero.  Using zero would require that the
	message was transmitted between a clock ticks.
> > BTW, last time I looked, there were a bunch of
> > processors that didn't support 64 bit integer math,
> > and you have to do funny games with dual 32 bit
> > values. Optimizing for instruction sets is a lose,
> > IMO.
> 
> Heartily agreed.  I got rat-holed by the idea that I
> wanted to avoid "de-optimization" for 64 bit machines;
> I wasn't looking at it as optimization for a particular
> machine, but cast in that light, it is a bit silly.  For
> all I know, we're talking about something like a Transputer
> with a built-in barrel shifter.  8-).
> 
> 
> -- Terry Lambert
> -- Whistle Communications, Inc.
> -- [email-masked]
> -------------------------------------------------------------------
> This is formal notice under California Assembly Bill 1629, enacted
> 9/26/98 that any UCE sent to my email address will be billed $50
> per incident to the legally allowed maximum of $25,000.
> 
> 
	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]