Sharon Goldberg writes: >>> 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.
My proposal for SUGGEST-REFID is simply a mechanism for an NTP instance to tell others "If you use me as your system peer, please use <FOO> as your refid." If a server chooses to suggest a single nonce for all of its interfaces as its suggested refid, great. If it chooses to use that same nonce for all of its associations, that's great too. For me, we're now in the realm of "policy", and there are tradeoffs there. My goal was to provide a robust mechanism to allow for these policy choices. > 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? Danny's (policy) proposal would most likely be implemented using the suggest-refid EF proposal I made, so: Yes, an EF Nobody is doing this yet, unless somebody has implemented my proposal and not told me. As for backward compatibility, that's not really an issue. An old server will not understand the EF so it will use the current rules for choosing its refid when selecting its system peer. This is what I talked about in my first "set", covering the I-Do and Last-EF proposals. If I send you packets with I-Do and get back a plain response, I know you can't or aren't willing to do these newer choices. Either way, I need to be prepared to check the legacy and suggested refid choices in responses I get from you. If I send you an I-Do and get *no* response, then I don't know if you never got my packet or you got it and dropped it because it had an unrecognized EF in it. Eventually I would just send plain packets. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
