On Feb 16, 8:56 am, "Maarten Wiltink" <maar...@kittensandcats.net> wrote: > "Dave Hart" <daveh...@gmail.com> wrote in message > > > RFC1918 addresses are of course not globally unique, so are > > particularly ill-suited to a reference ID used for loop detection. > [...] > > Why play roulette if you have a globally unique IPv4 address to use > > as a refid? ... > > You do? Lucky you. RFC1918 addresses are all I have[0], except for > the one address on the outside of my modem, which of them all is the > _least_ suitable because it's the one place in my network where I > don't have, nor currently want, NTP service[1].
I said if. My original comment was if you're going to use a single refid for the NTP host instead of using its interface address as refid (meaning same server has different refid depending on which of its interfaces you approach it via), prefer apparent unicast global IPv4 addresses over RFC1918 when selecting from several IPv4 addresses which to use as refid. Which got Danny going again on his ntptrace breaking spree saying refids are not IPv4 addresses and picking a random number at startup is the wise way forward. > RFC1918 addresses may not be globally unique, but they are also not > routeable, so within any given network they _will_ be unique. It is good to have a bit of lighthearted humor in these technical discussions. > While > multi-homed hosts may seem to be a counter-example, living as they > do on several networks at the same time, I think they still need > unambiguous network addresses around them. Sounds like a fine goal. Multi-homed hosts are more than a counter- example, they were the very reason I suggested preferring non-RFC1918 when choosing a machine-wide ntpd refid, assuming as I was that one of several IPv4 addresses would be used. Many servers, for example, have a management network separate from their service access network. No problem today running ntpd, but if you change ntpd to use the same refid across all interfaces, choosing a likely-to-collide RFC1918 address isn't helping anyone. On the nonroutability of RFC1918 addresses, have you ever seen someone try to VPN back to their home network from a hotel network and fail miserably because the hotel network and the home network have conflicting ideas of how to route RFC1918 addresses? Personally, I'm nearly irrational in my hatred for things that break end-to-end communication, determined to avoid, disable, tame, or tunnel around any packet manglers I'm saddled with. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
