On 4/5/2016 4:54 PM, Sharon Goldberg wrote: > >   The problem that I was alluding to in the jabber room is this. > I'll keep > >   the problem simple and to one example. > > > >   A takes its time from B over an IPv4 address. A then gets a time > query > >   from C over IPv6. How does it know if B and C are the same > system or > >   different system? A has no information about that. > > > >   Is this clearer? > > > > Yes, it's clear. How does the current ntpd implementation deal with this > > problem? Â > > > > Currently it doesn't. One of my proposals is for each system to generate > a RefID and use that for all interfaces. I'm not sure if that works for > all cases or causes other issues. > > > OK. To clarify: you are proposing an extension to NTP where a server > that has multiple IP addresses can choose a special value as its refID, > and communicate that to its clients. Then, if the clients choose to > take time from that server, they put that special value in as their > refID, instead of an IP address. > > AFAIK this functionality is not part of NTP today, right? It would > probably require an extension field? Also its not backwards compatible, > since a server that chooses to do this would need to make sure that its > clients understand what it is doing. And currently clients don't know > how to do this, right? > > Please clarify if I have misunderstood.
You did misunderstand. I said the Refid itself and not an extension field so it would be interoperable. I'm of the opinion that a server should only have one refid for all interfaces no matter which one is being used to send the packet. I recall that there is an issue that Harlan had to explain to me in excruciating detail as to why the existing refid is the way it is today but I don't recall now the details. We already have a problem where the hash of the IPv6 address can conflict with a real IPv4 address. Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
