David Schwartz wrote:
> "Danny Mayer" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> 
> 
>>David Schwartz wrote:
> 
> 
>>>    That's nice but has nothing to do with how you tell whether two 
>>>packets
>>>with different source UDP addresses came from the same server or not.
> 
> 
>>>    Consider a simple case. We have a simple server that is not using
>>>authentication. It's on a LAN where a lot of machines have both public 
>>>and
>>>private IP addresses. We recognize our local and internal LANs by their 
>>>IP
>>>range and don't need to authenticate because spoof protection is done at 
>>>the
>>>boundaries. We are talking to both 192.168.32.23 and 216.105.54.22, the
>>>question is, are they the same machine or not?
> 
> 
>>You cannot tell from the outside, nor should you usually care.
> 
> 
>     You should care. If you think they're two different servers, you may 
> give the time data double the weight it really should get.
> 

If you give more weight to one address over the other then you should
care that it gets sent from the right address and that's what we make
sure we do. So I don't understand your objections.

> 
>     I have seen NTP sync to the same server twice on two different IP 
> addresses. So if there is a unique identifier that NTP could use to ignore 
> duplicates, it doesn't use it as far as I've seen.
> 

That's because of a defect in the implementation of Refids in the
current code. Refids should be the same for all packets sent by the same
server no matter what IP address it uses. I intend to fix that in the
near future where the server will use one and only one refid and it
won't necessarily be based on an IPv4 address. That's a problem with the
specific implementation and not the protocol. One example of this is
that an IPv4 address and an IPv6 address on the same interface will give
you different refids.

Danny
>     DS
> 
> 
> _______________________________________________
> questions mailing list
> [email protected]
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 


_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to