Rob wrote:
Martin Burnicki <[email protected]> wrote:
Rob wrote:
Harlan Stenn <[email protected]> wrote:
Martin Burnicki writes:
Harlan Stenn schrieb:
Sander Smeenk writes:
Quoting Miroslav Lichvar ([email protected]):
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
that is 0xac023551, or 172.2.53.81 in the quad-dotted notation.
Miroslav, you're right. This is it. Thanks.
I consider this a bug.
As do we all. And we can fix it as soon as a decent solution appears.
Maybe just print the refid as hex bytes instead of dotted quads unless
it's interpreted as string?
Printing 32 bits of information in dotted-quad format takes 15
characters.
Printing 128 bits of information in base64 takes 22 characters.
I didn't mean to break the protocol by extending a 32 bit field to 128 bit.
I just meant to print the 32 bit refid field from the NTP packets in hex
instead of dotted quads, unless they are interpreted as ASCII
characters, e.g. "AC100E19" instead of "172.16.14.25".
I do understand that is what you meant, but then Harlan started about
printing 128 bits of information in base64. There are no 128 bits
available, so finding out how to print them is not currently required.
(although in general there is an issue with printing IPv6 addresses in
tabular output, which also affects ntpq and ntpdc)
Oops, the previous part of my reply should have been a reply to Harlan's
posting. Sorry for the confusion.
This would prevent many people from interpreting this as an IPv4
address. ;-)
Of course a better solution would be to be able to distinguish it the 32
bit number is a full IPv4 address, or only a 4 byte hash of an IPv6
address, and display an IPv4 address as dotted quad, and a hash as hex
number. I don't know if a tool like ntpq can determine what the refid
actually represents.
Not from the value alone. There apparently is a hack (described in the
standard) that whenever the server is stratum-0 the refid is printed
in ASCII and when it is not, it is printed as a dotted quad.
But it has no way of knowing if the dotted quad is an IPv4 address or
the hash of an IPv6 address.
Yes, that's also how I thought it's actually working.
The problem is not the printing!
Before 128 bits of information can be printed at all, the protocol
has to be modified to transfer the bits in the datagrams.
The use of a 32-bit field for the refid is as hardwired in the protocol
as 32-bit addresses are in IPv4.
It is not realistic to change this. What could be changed is the use
of the 32 bits when IPv6 is in use (as I proposed), and the printing
of the 32 bits in that case.
Sorry, I don't remember your proposal. Do you have a pointer to it?
I made it elsewhere in this thread.
When the NTP server puts an IPv6 hash in the refid field, it could set
the upper 4 bits to 1. (so the hex value starts with F)
A valid IPv4 address never has that, so ntpq could print it in hex in
this case, and as a dotted quad in other cases.
This also guarantees a hashed IPv6 can never collide with a valid IPv4
refid. But at the same time, it shrinks the space of IPv6 hashes,
increasing the chance of a hash collision between two IPv6 addresses.
In my opinion this sounds reasonable. The danger of collision might be
slightly higher (less with IPv4, a little bit more with another IPv6
hash), but for users it would avoid confusing IPv4 addresses with IPv6
hashes.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
