IETF Logo Mail Archive

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

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Wed, 04 September 2019 10:23 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 C4E10120059 for <ntp@ietfa.amsl.com>; Wed, 4 Sep 2019 03:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 iwmiF8SS_BHi for <ntp@ietfa.amsl.com>; Wed, 4 Sep 2019 03:23:13 -0700 (PDT)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C9A1200CE for <ntp@ietf.org>; Wed, 4 Sep 2019 03:23:13 -0700 (PDT)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D24F46000057 for <ntp@ietf.org>; Wed, 4 Sep 2019 12:23:10 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id BC2816000056 for <ntp@ietf.org>; Wed, 4 Sep 2019 12:23:10 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 04 Sep 2019 12:23:10 +0200
Message-Id: <5D6F908C020000A10003374A@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Wed, 04 Sep 2019 12:23:08 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>, mlichvar@redhat.com
References: <mlichvar@redhat.com> <20190902095854.GC15024@localhost> <20190903120544.394CC40605C@ip-64-139-1-69.sjc.megapath.net> <20190904095111.GJ15024@localhost> <EC0267640200002C6A6A8CFC@gwsmtp.uni-regensburg.de> <A7C4D27502000083822C0D04@gwsmtp.uni-regensburg.de> <D5F28766020000316A6A8CFC@gwsmtp.uni-regensburg.de> <2E18D20E0200009A822C0D04@gwsmtp.uni-regensburg.de> <4B834D170200006586EDC2A6@gwsmtp.uni-regensburg.de> <831B91BE020000B87ED719BE@gwsmtp.uni-regensburg.de> <5D6CB84E020000A100033405@gwsmtp.uni-regensburg.de> <6A31A7C90200006043047E14@gwsmtp.uni-regensburg.de> <87F2C84C0200007A6A6A8CFC@gwsmtp.uni-regensburg.de> <0A3D67B1020000F643047E14@gwsmtp.uni-regensburg.de> <6FF2BC4A020000476A6A8CFC@gwsmtp.uni-regensburg.de>
In-Reply-To: <6FF2BC4A020000476A6A8CFC@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pV78lsuO97pkGIyEw9HxXnxrpoA>
Subject: [Ntp] Antw: Re: 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: Wed, 04 Sep 2019 10:23:16 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 04.09.2019 um 11:51 in
Nachricht <20190904095111.GJ15024@localhost>:
> On Tue, Sep 03, 2019 at 05:05:44AM ‑0700, Hal Murray wrote:
>> 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.
> 
> The former makes more sense to me. We don't need the ID to be static.
> Generating a random number on each start should be fine.
> 
>> Can we assume that every server will have a globally routeable IPv6
address? 
>  
> 
> No. IPv6 is not universally available. Address translation is
> common, so we cannot assume an IPv4 or IPv6 address is unique.
> 
>> Can we assume that every server will have an Ethernet host address?
> 
> The vast majority will, but I'm not sure we can rely on them being random.

Hi!

Also if you specify it to be random, there won't be interpretation even if it
is not ;-)
(meaning: those who like to use a global IPv6 address could do so)
The other way round you woudn't be allowed to make it random.
Likewise as said before (for the paranoid): Don't require it to be constant
over a long time. So implementations would be allowed to change it periodically
(like once per day), each boot, each daemon restart, etc.
BTW: A new ID after a daemon restart might have the positive effect that
clients could detect that it's a "new server" (as the NTP variables are quite
different after a restart, that would even be a valid assumption)...


> 
>> In both cases, for multi homed servers, just pick one.  After that choice,

>> it's an ID, no longer an address.
> 
> Yes. And it's important that all clients get the same ID.

At least short- and mid-term. See above.


Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email