[ntp:questions] NTP over redundant peer links, undetected loops

Richard B. Gilbert rgilbert88 at comcast.net
Mon Feb 16 20:57:16 UTC 2009

Dave Hart wrote:
> On Feb 16, 8:56 am, "Maarten Wiltink" <maar... at kittensandcats.net>
> wrote:
>> "Dave Hart" <daveh... at 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?  

RFC-1918 address are non-routeable by definition!  They are intended for 
PRIVATE networks where the nodes need not be accessible from outside. 
Generally, any link with the outside must be initiated from inside. 
(Don't call us, we'll call you!)

You can reach your home system from your hotel by addressing the 
external address of your router and selecting a port that the router 
will map to something you can talk to and can talk to you.  This 
requires some setup on your router before you leave home!

It's necessarily a security hole; if you can get in that way, anyone 
else can.  Passwords and whatnot make it more difficult but not impossible.

> 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.

Cling to rationality!  It will save you unnecessary trips to the 
laughing academy!

More information about the questions mailing list