[Bug 325111]

[tlhackque]

(In reply to comment #7)
> Good idea, and the "problem" is the refid is a 32-bit structure.
> 
> Its purpose is for loop detection - to make sure machine A doesn't
> believe time from machine B if machine B is getting its time from A.
> 
> I've had some chats with Prof. Mills about this and we're gently
> discussing changing the refid value for non-refclock sources to a simple
> nonce.

That's a separate issue from displaying the full server address.I
actually have some where a subnet has the several servers, and I can't
tell them apart; the initial part of the IP address matches several
machines, and some machines have both A and  records...so the names
aren't unique either.  it isn't pretty.

As far as the reference address - I thought that for IPv6, the refid was
a hash of the IPv6 address - which means it's already a nonce.  There's
some small probability of a collision (2 + n in 4 billion - 1 for IPv4
and 1 for IPv6 + the possibility that an IP address or hash turns out to
be one of the refclock tags  - e.g. .GPS., .PPS., .INIT etc -  in
binary).

Now that bits are cheaper, perhaps NTPv5 can allocate 136 bits -- 8 for
an entity id (IPv4 address, IPv6 address, and Refclock to start with)  +
a full IPv6 address at the end of the packet.  Oooh - NTPv5?  Well,
maybe not.   Just think of all the firewalls and other chaos ;-)

In any case, displaying the full server IP address would be a big help.

I don't have a strong opinion on whether the expanded format should
require a command-line switch - such as -w.  IPv6 will require any
scripts that parse the text to change anyway - and humans won't care.
But it would be a way to guarantee backward compatibility.

Anyhow, after 4 years, it would be nice to see this addressed...IPv6 IS
gathering steam.

Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/325111

Title:
  ntpq output truncates IPv6 addresses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ntp/+bug/325111/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 325111]

[tlhackque]

Oh, here's a sample:

router#show ntp assoc

  address ref clock   st   when   poll reach  delay  offset   disp
-~2600:3C03::F03C:91FF:FEDF:9B84
  128.4.40.12  3265512   377 43.274  10.649  0.032
 ~149.20.68.17.INIT.  16  -   1024 0  0.000   0.000 15937.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/325111

Title:
  ntpq output truncates IPv6 addresses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ntp/+bug/325111/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 325111]

[tlhackque]

A thought:

Cisco IOS (routers) solved this by putting IPv6 addresses on their own line, 
then indenting the following line so that the columns line up.

This is pretty easy for scripts that parse the output to accomodate, and
visually it works, at least for me.

And since they have deployed a solution, it would be nice to be
consistent

(I'm not affiliated with cisco, but I am a user.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/325111

Title:
  ntpq output truncates IPv6 addresses

To manage notifications about this bug go to:
https://bugs.launchpad.net/ntp/+bug/325111/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs