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

[Hal Murray <[e-mail]>]

[e-mail] 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.