Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Hal Murray <hmurray@megapathdsl.net> Tue, 03 September 2019 12:05 UTC

Return-Path: <hmurray@megapathdsl.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4D6120108 for <ntp@ietfa.amsl.com>; Tue, 3 Sep 2019 05:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.035
X-Spam-Level: *
X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7EUXEkcAxa1 for <ntp@ietfa.amsl.com>; Tue, 3 Sep 2019 05:05:46 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id CCC7012006F for <ntp@ietf.org>; Tue, 3 Sep 2019 05:05:44 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 394CC40605C; Tue, 3 Sep 2019 05:05:44 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Miroslav Lichvar <mlichvar@redhat.com>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Miroslav Lichvar <mlichvar@redhat.com> of "Mon, 02 Sep 2019 11:58:54 +0200." <20190902095854.GC15024@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Sep 2019 05:05:44 -0700
Message-Id: <20190903120544.394CC40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/RrLWN2gh154l8aZpJJqYLCPj5dA>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 12:05:51 -0000

mlichvar@redhat.com said:
> If the system has multiple addresses, its clients may not know all of them
> and may fail to detect loops. Addresses are no good.

> We need each server (or rather the clock) to have an ID and extend the
> protocol to exchange this ID so clients (that operate also as servers) can
> reliably detect 1-degree loops. The suggested-refid EF basically does that. 

Sorry for not being clear.

I agree with what you said.  I was trying to explore a source for an ID.  I'm 
assuming it is important to avoid collisions.  Harlan's proposal has other 
ideas tangled up in there.  I wasn't considering of them them.

I think there are two approaches.

One is to use random data.  The probability of a collision can be made 
arbitrarily small by making the number of bits in the ID big enough.  That 
needs good randomness.

The other approach is to piggyback on some other scheme that has already 
solved the problem.

Can we assume that every server will have a globally routeable IPv6 address?  
This seems slightly iffy to me, but I expect an IPv6 wizard could tell us 
about all the corner cases and it might work if we made a list of address 
ranges to not use.  IPv4 only systems add to the complications.  So does NAT.

I can't rule out that approach, but it seems like it will be complicated.

Can we assume that every server will have an Ethernet host address?  I don't 
know of any corner cases for those.  There may be some networking technologies 
where the hardware level address is assigned randomly - try again if somebody 
is using it.  We would have to avoid those.


In both cases, for multi homed servers, just pick one.  After that choice, 
it's an ID, no longer an address.


-- 
These are my opinions.  I hate spam.