[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Will ntp.org consider accepting a rewrite of
From:       Danny Mayer <mayer () ntp ! org>
Date:       2011-09-26 3:21:16
Message-ID: 4E7FEFAC.6090508 () ntp ! org
[Download RAW message or body]

On 9/25/2011 7:52 PM, Dave Hart wrote:
> On Sun, Sep 25, 2011 at 22:28, Hal Murray <hmurray@megapathdsl.net> wrote:
>>
>> mayer@ntp.org said:
>>>> Another issue to address would be IPv6 peers.
>>> In what way?
>>
>> Mode 3/4 packets have a 32 bit slot for the upstream.   For IPv4, that
>> contains the IP Address.   For IPv6, it's only a hash.
> 
> To expand on Hal's comment slightly, since one can't send NTP queries
> to a 32-bit hash of an IPv6 address, ntptrace _must_ use mode 6 (ntpq)
> or mode 7 (ntpdc) queries to retrieve the sys.peer IP address for it
> to trace through IPv6.  Mode 7 would be a bad choice as I'm hoping to
> default servicing mode 7 queries to off before long.
> 

I've said repeatedly that the REFID is NOT an IP address, it is just
formatted like one. Originally apparently it was an IPv4 address if it
was not a refclock but with the introduction of IPv6 it no longer can
be. ntptrace does not use the REFID to trace the chain of servers. I
initially thought so too but a closer look at the perl code shows
otherwise. It is indeed sys.peer that you need to get to use in the next
query. The perl script needs some attention too. I notice some of the
code could use some updates like replacing gethostbyaddr() with
getaddrinfo().

It took me a while to dig out the old C version of ntptrace. I had to go
back to ntp 4.1.1 to find it. It DID use client mode packets but then it
used the refid to find the next one in the chain which is obviously
wrong. So I was wrong about using mode 3 and 4 packets but that was what
I remembered from the program.

There are a number of problems with the refid in any case since it uses
the IP address of the interface for forming the refid. However with
multiple IP addresses both IPv4 and IPv6 being common it means that you
get a different REFID depending on which interface your packet arrives
on. In reality a server should have one and only one REFID so it
shouldn't matter if you arrive on a different interface or on an IPv6
address you should get the same REFID. We need to decide which one to use.

Danny


_______________________________________________
hackers mailing list
hackers@lists.ntp.org
http://lists.ntp.org/listinfo/hackers

[prev in list] [next in list] [prev in thread] [next in thread]