The "Request for Comments: 2030" mentions that UDP source port and
destination port are 123.


"The UDP port number assigned to NTP is 123, which should be used in
   both the Source Port and Destination Port fields in the UDP header."

Why?  A client program will need special privileges to assign source port
123 . Furthermore, this does not seem to be the case, for I can send and
receive data to a  Time Server using, on the client, any source port above
1024, as long as the destination port is 123. So, the  de facto standard
seems to be "The port number assigned to NTP is 123 only as the destination
Port; any ephemeral port can be used for the source".  Again, I cannot find
any exceptions, in practice, on stratum 2 servers.

Is this current practice mentioned in any standard that I may have
overlooked?  If not should I be prepared to change my applications so that
they use source and destination port 123?

Regards,

Mike Chirico

Mike,

All previous and current NTP specifications require port 123 as both 
source and destination in order to support symmetric peer modes. This 
has been the case for the last twenty years, so should not be a surprise.

Dave

Mike Chirico wrote:
> The "Request for Comments: 2030" mentions that UDP source port and
> destination port are 123.
> 
> 
> "The UDP port number assigned to NTP is 123, which should be used in
>    both the Source Port and Destination Port fields in the UDP header."
> 
> Why?  A client program will need special privileges to assign source port
> 123 . Furthermore, this does not seem to be the case, for I can send and
> receive data to a  Time Server using, on the client, any source port above
> 1024, as long as the destination port is 123. So, the  de facto standard
> seems to be "The port number assigned to NTP is 123 only as the destination
> Port; any ephemeral port can be used for the source".  Again, I cannot find
> any exceptions, in practice, on stratum 2 servers.
> 
> Is this current practice mentioned in any standard that I may have
> overlooked?  If not should I be prepared to change my applications so that
> they use source and destination port 123?
> 
> Regards,
> 
> Mike Chirico
> 
> 

"Mike Chirico" <mchirico@comcast.net> wrote:

> The "Request for Comments: 2030" mentions that UDP source port and
> destination port are 123.
> 
> 
> "The UDP port number assigned to NTP is 123, which should be used in
>    both the Source Port and Destination Port fields in the UDP header."
> 
> Why?  A client program will need special privileges to assign source port
> 123 .

Presumably it'll need special privileges to adjust the system time ...

-- 
                      Ronan Flood <R.Flood@noc.ulcc.ac.uk>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't like)

David:

But take a look at the documentation on ntpdate. With the -u option the
program uses unprivileged ports, plus  the -d option, debug, always uses
unprivileged ports.  Agreed, even though  ntpdate is going away it has been
in use for a number of years.

Almost without exception, Time Servers support queries on  a source ports
other than 123. This is good and should continue.  This is not the same as
asking symmetric peer modes to use something other than port 123 -- 
absolutely not, symmetric peers  should stick to  port 123.

My point is this standard has only been followed for  symmetric peer
servers. Not client programs such as ntpdate. The standard is not inline
with actual practice.

Regards,

Mike Chirico


"David L. Mills" <mills@udel.edu> wrote in message
news:ch4gk8$gkf$1@dewey.udel.edu...
> Mike,
>
> All previous and current NTP specifications require port 123 as both
> source and destination in order to support symmetric peer modes. This
> has been the case for the last twenty years, so should not be a surprise.
>
> Dave
>
> Mike Chirico wrote:
> > The "Request for Comments: 2030" mentions that UDP source port and
> > destination port are 123.
> >
> >
> > "The UDP port number assigned to NTP is 123, which should be used in
> >    both the Source Port and Destination Port fields in the UDP header."
> >
> > Why?  A client program will need special privileges to assign source
port
> > 123 . Furthermore, this does not seem to be the case, for I can send and
> > receive data to a  Time Server using, on the client, any source port
above
> > 1024, as long as the destination port is 123. So, the  de facto standard
> > seems to be "The port number assigned to NTP is 123 only as the
destination
> > Port; any ephemeral port can be used for the source".  Again, I cannot
find
> > any exceptions, in practice, on stratum 2 servers.
> >
> > Is this current practice mentioned in any standard that I may have
> > overlooked?  If not should I be prepared to change my applications so
that
> > they use source and destination port 123?
> >
> > Regards,
> >
> > Mike Chirico
> >
> >
>

"Ronan Flood" <ronan@noc.ulcc.ac.uk> wrote in message
news:ch4lk8$lq3$1@canard.ulcc.ac.uk...
> "Mike Chirico" <mchirico@comcast.net> wrote:
>
> > The "Request for Comments: 2030" mentions that UDP source port and
> > destination port are 123.
> >
> >
> > "The UDP port number assigned to NTP is 123, which should be used in
> >    both the Source Port and Destination Port fields in the UDP header."
> >
> > Why?  A client program will need special privileges to assign source
port
> > 123 .
>
> Presumably it'll need special privileges to adjust the system time ...

No. And I think this is an important point. Why should an application be
restricted to any time discrepancies of the server it is running on, and why
should it worry about setting the time on that server.  With everything
networked, applications can check and determine very accurate time without
relying on the local server -- they go directly to a chosen time server,
calculate the precise time, just as ntpd does with the delay, then use it at
that moment. Or, note the time offset of the local server and add the
difference to get the correct current time.

Regards,

Mike Chirico

In article <B_6dnSZNL7-Yc6jcRVn-uw@comcast.com>,
Mike Chirico <mchirico@comcast.net> wrote:

> relying on the local server -- they go directly to a chosen time server,
> calculate the precise time, just as ntpd does with the delay, then use it at

That's outside the scope of the NTP RFC as it is SNTP, not NTP.  NTP requires
the use of phase locked loops and the operation of algorithms to select
servers and filter results.  Out of band selection of servers and
use of a single exchange are SNTP only.

> that moment. Or, note the time offset of the local server and add the
> difference to get the correct current time.

Possible, but not common, and unlikely to be done on systems that enforce
the privileged port concept.

ntpdate is not a symmetric association.

ntpdate has other problems and has been retired in favor of ntpd -g.

H

"Mike Chirico" <mchirico@comcast.net> wrote in message 
news:B_6dnSZNL7-Yc6jcRVn-uw@comcast.com...

> No. And I think this is an important point. Why should an application be
> restricted to any time discrepancies of the server it is running on, and 
> why
> should it worry about setting the time on that server.  With everything
> networked, applications can check and determine very accurate time without
> relying on the local server -- they go directly to a chosen time server,
> calculate the precise time, just as ntpd does with the delay, then use it 
> at
> that moment. Or, note the time offset of the local server and add the
> difference to get the correct current time.

    None of these techniques will provide the type of accuracy that NTP is 
designed to provide. If you're looking for that level of accuracy, use SNTP 
or something else. NTP is fundamentally designed to synchronize system time 
to a reference time that is ultimately traceable to UTC.

    DS

"David Woolley" <david@djwhome.demon.co.uk> wrote in message
news:T1094071508@djwhome.demon.co.uk...
> In article <B_6dnSZNL7-Yc6jcRVn-uw@comcast.com>,
> Mike Chirico <mchirico@comcast.net> wrote:
>
> > relying on the local server -- they go directly to a chosen time server,
> > calculate the precise time, just as ntpd does with the delay, then use
it at
>
> That's outside the scope of the NTP RFC as it is SNTP, not NTP.  NTP
requires
> the use of phase locked loops and the operation of algorithms to select
> servers and filter results.  Out of band selection of servers and
> use of a single exchange are SNTP only.
>
> > that moment. Or, note the time offset of the local server and add the
> > difference to get the correct current time.
>
> Possible, but not common, and unlikely to be done on systems that enforce
> the privileged port concept.

I do not understand. Correct RFC 2030 describes SNTP; but, there
is no distinction made in this documentation when dealing with the
source port.

This was taken from RFC 2030:

  "To a NTP or SNTP server, NTP and SNTP
   clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
   servers are undistinguishable. Like NTP servers operating in non-
   symmetric modes, ..."



Regards,

Mike Chirico

"David Schwartz" <davids@webmaster.com> wrote in message
news:ch5fh2$506$1@nntp.webmaster.com...
>
> "Mike Chirico" <mchirico@comcast.net> wrote in message
> news:B_6dnSZNL7-Yc6jcRVn-uw@comcast.com...
>
> > No. And I think this is an important point. Why should an application be
> > restricted to any time discrepancies of the server it is running on, and
> > why
> > should it worry about setting the time on that server.  With everything
> > networked, applications can check and determine very accurate time
without
> > relying on the local server -- they go directly to a chosen time server,
> > calculate the precise time, just as ntpd does with the delay, then use
it
> > at
> > that moment. Or, note the time offset of the local server and add the
> > difference to get the correct current time.
>
>     None of these techniques will provide the type of accuracy that NTP is
> designed to provide. If you're looking for that level of accuracy, use
SNTP
> or something else. NTP is fundamentally designed to synchronize system
time
> to a reference time that is ultimately traceable to UTC.
>
Correct, this is not intended to be a replacement for NTP.

How would you know from an applications perspective, that NTP is working
on the local server? I think the answer is to perform some of the functions
of ntpd daemon in the application: leverage the 4 timestamp values T1, T2,
T3 and T4
to calculate the roundtrip delay, and local clock offset by sending several
packets
to different timeservers.

The problem is this application will be distributed to 1000s of servers,
some servers
that may not have ntp running correctly. That's ok this application will fix
this itself, or
determine that the time cannot be verified.

Security is an issue --  this application should not have any special
privileges.

The only problem is the wording in the SNTP standard, which is currently not
being
followed, that the source port 123 and destination port 123 be used when
getting this timestamp information via SNTP. I'm trying to force the issue
of why
this is in the standard.

Regards,

Mike Chirico

"Mike Chirico" <mchirico@comcast.net> wrote in message
news:YZ6dnRsmb6ZmyqvcRVn-jQ@comcast.com...
[...]
> How would you know from an applications perspective, that NTP is
> working on the local server? I think the answer is to perform some
> of the functions of ntpd daemon in the application: leverage the 4
> timestamp values T1, T2, T3 and T4 to calculate the roundtrip delay,
> and local clock offset by sending several packets to different
> timeservers.

Wrong. The spec for an application doesn't say "NTP must run alongside".
It says "correct functioning requires correct system time".

So yu ask your sysop, and he says "we run NTP", and you tick off the
"have correct time" item on your list.

Groetjes,
Maarten Wiltink

This is a multi-part message in MIME format.
--------------010408000709050509020002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Maarten Wiltink wrote:

>"Mike Chirico" <mchirico@comcast.net> wrote in message
>news:YZ6dnRsmb6ZmyqvcRVn-jQ@comcast.com...
>[...]
>  
>
>>How would you know from an applications perspective, that NTP is
>>working on the local server? I think the answer is to perform some
>>of the functions of ntpd daemon in the application: leverage the 4
>>timestamp values T1, T2, T3 and T4 to calculate the roundtrip delay,
>>and local clock offset by sending several packets to different
>>timeservers.
>>    
>>
>
>Wrong. The spec for an application doesn't say "NTP must run alongside".
>It says "correct functioning requires correct system time".
>
>So yu ask your sysop, and he says "we run NTP", and you tick off the
>"have correct time" item on your list.
>
>Groetjes,
>Maarten Wiltink
>
>  
>
I don't think that's quite right either!

How about "the application requires that system time be within X 
(milliseconds | microseconds) of UTC for correct functioning."  Just 
having NTP running does not mean that you have the correct time!




--------------010408000709050509020002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Maarten Wiltink wrote:<br>
<blockquote type="cite"
 cite="mid4136e1cc$0$78279$e4fe514c@news.xs4all.nl">
  <pre wrap="">"Mike Chirico" <a class="moz-txt-link-rfc2396E" href="mailto:mchirico@comcast.net">&lt;mchirico@comcast.net&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:YZ6dnRsmb6ZmyqvcRVn-jQ@comcast.com">news:YZ6dnRsmb6ZmyqvcRVn-jQ@comcast.com</a>...
[...]
  </pre>
  <blockquote type="cite">
    <pre wrap="">How would you know from an applications perspective, that NTP is
working on the local server? I think the answer is to perform some
of the functions of ntpd daemon in the application: leverage the 4
timestamp values T1, T2, T3 and T4 to calculate the roundtrip delay,
and local clock offset by sending several packets to different
timeservers.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Wrong. The spec for an application doesn't say "NTP must run alongside".
It says "correct functioning requires correct system time".

So yu ask your sysop, and he says "we run NTP", and you tick off the
"have correct time" item on your list.

Groetjes,
Maarten Wiltink

  </pre>
</blockquote>
I don't think that's quite right either!<br>
<br>
How about "the application requires that system time be within X
(milliseconds | microseconds) of UTC for correct functioning."&nbsp; Just
having NTP running does not mean that you have the correct time!<br>
<br>
<br>
<br>
</body>
</html>

--------------010408000709050509020002--

"Mike Chirico" <mchirico@comcast.net> quoted Ronan Flood:

> > Presumably it'll need special privileges to adjust the system time ...
>
> No. And I think this is an important point. Why should an application be
> restricted to any time discrepancies of the server it is running on, and
> why should it worry about setting the time on that server.

I don't think you have any concept of just how complex the process is that
ntpd goes through to determine the correct time and to keep that.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

"Mike Chirico" <mchirico@comcast.net> wrote:

> But take a look at the documentation on ntpdate. With the -u option the
> program uses unprivileged ports, plus  the -d option, debug, always uses
> unprivileged ports.  Agreed, even though  ntpdate is going away it has
> been in use for a number of years.

My understanding is that these are aspects of ntpdate which have been
regretted since the day they were added.

> Almost without exception, Time Servers support queries on  a source ports
> other than 123. This is good and should continue.  This is not the same
> as asking symmetric peer modes to use something other than port 123 --
> absolutely not, symmetric peers  should stick to  port 123.
>
> My point is this standard has only been followed for  symmetric peer
> servers. Not client programs such as ntpdate. The standard is not inline
> with actual practice.

Note that ntpd is inherently both client and server.  If no other clients
are configured to query that server, then it doesn't serve any clients.
But it's still a server.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

"Mike Chirico" <mchirico@comcast.net> wrote:

> How would you know from an applications perspective, that NTP is working
> on the local server?

Because that's how NTP is designed to work?

> The problem is this application will be distributed to 1000s of servers,
> some servers that may not have ntp running correctly.

Then those servers are broken, but the entire whole of the rest of the
world should not be shackled to a solution that is geared to trying to
solve just this one problem.

>                                               That's ok this
> application will fix this itself, or determine that the time cannot be
> verified.

If you want them to have the correct time set, then run ntpd on them, and
configure it correctly.  That's not particularly difficult to do.

> The only problem is the wording in the SNTP standard, which is currently
> not being
> followed, that the source port 123 and destination port 123 be used when
> getting this timestamp information via SNTP. I'm trying to force the
> issue of why
> this is in the standard.

Well, that's the standard.  So long as that's the standard, you have to do
it if you want to be compliant with the standard.  If you want to change
the standard, I suggest you go through the IETF RFC process.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> How about "the application requires that system time be within X
> (milliseconds | microseconds) of UTC for correct functioning."  Just
> having NTP running does not mean that you have the correct time!

Then it's up to your system administrator to make sure that this is
possible on your hardware, and if not, to change the hardware to suit.
Once your sysadmin has determined that this is possible, getting the level
of accuracy you require is a matter of configuration.

All of this is solvable with the NTP protocol and ntpd, assuming that the
hardware is physically capable of the accuracy required.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

"Mike Chirico" <mchirico@comcast.net> wrote in message 
news:B_6dnSZNL7-Yc6jcRVn-uw@comcast.com...

> No. And I think this is an important point. Why should an application be
> restricted to any time discrepancies of the server it is running on, and 
> why
> should it worry about setting the time on that server.

    If an application has special time requirements and it's intended for 
mass distribution. it should definitely have internal code to sanitize the 
system time. I've worked on programs that have certain timing requirements 
that are essential for correct operation.

    For example, consider timing out a DNS query. If system time jumps 
forwards, the query may not time out for minutes, which could cause internal 
problems. This requires an application to sanitize the system time. Using 
the raw system time for things like timeouts is, IMO, not acceptable in a 
commercial program.

    However, an application cannot reliably get sub-second accuracy without 
help from the system. If the application requires more accuracy than that, 
it must specify that the system time must be accurate, and at best it can 
detect an inaccuracy if it's serious.

> With everything
> networked, applications can check and determine very accurate time without
> relying on the local server -- they go directly to a chosen time server,
> calculate the precise time, just as ntpd does with the delay, then use it 
> at
> that moment.

    At what moment? At the moment they sent the query? They don't have the 
results back yet. At the time they get the reply? That's not the time the 
packet was sent. If the delay is asymmetric or that particular query gets 
queued due to congestion, this technique won't work. It also won't help if 
the time is needed immediately.

> Or, note the time offset of the local server and add the
> difference to get the correct current time.

    Note the time offset when? And what if the system time is running too 
quickly? Applying correction can result in backwards jumps. I think you 
grossly underestimate what's involved in keeping accurate time.

    DS

This is a multi-part message in MIME format.
--------------080306060906010203070500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

brad@shub-internet.org wrote:

>"Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>
>  
>
>>How about "the application requires that system time be within X
>>(milliseconds | microseconds) of UTC for correct functioning."  Just
>>having NTP running does not mean that you have the correct time!
>>    
>>
>
>Then it's up to your system administrator to make sure that this is
>possible on your hardware, and if not, to change the hardware to suit.
>Once your sysadmin has determined that this is possible, getting the level
>of accuracy you require is a matter of configuration.
>
>All of this is solvable with the NTP protocol and ntpd, assuming that the
>hardware is physically capable of the accuracy required.
>  
>

I think you are missing the point!   If you have an application that 
requires the "correct" time you need to specify exactly what you mean by 
that.  In the US, only NIST has the "correct" time, by definition.  
Anybody else has an approximation that is more or less good.   You may 
be within nanoseconds of UTC and still not have the exact and correct time.

Rather than specify that ntp must be running, you need to specify the 
allowable amount of error before your application breaks.  It is then up 
to the sysadmin to take the necessary measures to ensure that system 
time meets that specification.

--------------080306060906010203070500
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<a class="moz-txt-link-abbreviated" href="mailto:brad@shub-internet.org">brad@shub-internet.org</a> wrote:<br>
<blockquote type="cite" cite="mid20040902162439.222$bR@newsreader.com">
  <pre wrap="">"Richard B. Gilbert" <a class="moz-txt-link-rfc2396E" href="mailto:rgilbert88@comcast.net">&lt;rgilbert88@comcast.net&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">How about "the application requires that system time be within X
(milliseconds | microseconds) of UTC for correct functioning."  Just
having NTP running does not mean that you have the correct time!
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Then it's up to your system administrator to make sure that this is
possible on your hardware, and if not, to change the hardware to suit.
Once your sysadmin has determined that this is possible, getting the level
of accuracy you require is a matter of configuration.

All of this is solvable with the NTP protocol and ntpd, assuming that the
hardware is physically capable of the accuracy required.
  </pre>
</blockquote>
<br>
I think you are missing the point!&nbsp;&nbsp; If you have an application that
requires the "correct" time you need to specify exactly what you mean
by that.&nbsp; In the US, only NIST has the "correct" time, by definition.&nbsp;
Anybody else has an approximation that is more or less good.&nbsp;&nbsp; You may
be within nanoseconds of UTC and still not have the exact and correct
time.<br>
<br>
Rather than specify that ntp must be running, you need to specify the
allowable amount of error before your application breaks.&nbsp; It is then
up to the sysadmin to take the necessary measures to ensure that system
time meets that specification.<br>
</body>
</html>

--------------080306060906010203070500--

David,

Case in point is the ntpd daemon itself. Nowhere is the raw time used 
for anything, only differences between timestamps. See the white papers 
at the NTP project page www.eecis.udel.edu/~mills/ntp.html. In other 
words, the logical time is never set directly, only adjusted by offsets 
computed by the daemon.

However, the daemon never uses timestamps for internal timeouts, as the 
timestamps can change radically. These depend only on the Unix interval 
timer facility. So, even if the time is wrangled in ugly ways, the 
daemon operations are not affected. I would expect other applications to 
use a similar approach.

Dave

David Schwartz wrote:
> "Mike Chirico" <mchirico@comcast.net> wrote in message 
> news:B_6dnSZNL7-Yc6jcRVn-uw@comcast.com...
> 
> 
>>No. And I think this is an important point. Why should an application be
>>restricted to any time discrepancies of the server it is running on, and 
>>why
>>should it worry about setting the time on that server.
> 
> 
>     If an application has special time requirements and it's intended for 
> mass distribution. it should definitely have internal code to sanitize the 
> system time. I've worked on programs that have certain timing requirements 
> that are essential for correct operation.
> 
>     For example, consider timing out a DNS query. If system time jumps 
> forwards, the query may not time out for minutes, which could cause internal 
> problems. This requires an application to sanitize the system time. Using 
> the raw system time for things like timeouts is, IMO, not acceptable in a 
> commercial program.
> 
>     However, an application cannot reliably get sub-second accuracy without 
> help from the system. If the application requires more accuracy than that, 
> it must specify that the system time must be accurate, and at best it can 
> detect an inaccuracy if it's serious.
> 
> 
>>With everything
>>networked, applications can check and determine very accurate time without
>>relying on the local server -- they go directly to a chosen time server,
>>calculate the precise time, just as ntpd does with the delay, then use it 
>>at
>>that moment.
> 
> 
>     At what moment? At the moment they sent the query? They don't have the 
> results back yet. At the time they get the reply? That's not the time the 
> packet was sent. If the delay is asymmetric or that particular query gets 
> queued due to congestion, this technique won't work. It also won't help if 
> the time is needed immediately.
> 
> 
>>Or, note the time offset of the local server and add the
>>difference to get the correct current time.
> 
> 
>     Note the time offset when? And what if the system time is running too 
> quickly? Applying correction can result in backwards jumps. I think you 
> grossly underestimate what's involved in keeping accurate time.
> 
>     DS
> 
> 

"David L. Mills" <mills@udel.edu> wrote in message news:<ch4gk8$gkf$1@dewey.udel.edu>...
> Mike,
> 
> All previous and current NTP specifications require port 123 as both 
> source and destination in order to support symmetric peer modes. This 
> has been the case for the last twenty years, so should not be a surprise.
> 

The ntp implementation shows that this is true for servers that must
send and receive on port 123. However, a client can use any port it
wants. This is true of ntpq and ntpdc which cannot use UDP port 123
since they are in use by the server on which you may want to run them.
In fact there is nothing in the code that prevents a server receiving
or dropping packets coming from any other port. So there is no such
restriction enforced in the official sources. The RFC may need to be
modified to reflect this.

Danny

> Dave
> 
> Mike Chirico wrote:
> > The "Request for Comments: 2030" mentions that UDP source port and
> > destination port are 123.
> > 
> > 
> > "The UDP port number assigned to NTP is 123, which should be used in
> >    both the Source Port and Destination Port fields in the UDP header."
> >

"Danny Mayer" <mayer@gis.net> wrote in message
news:3a2a0492.0409061857.4e42367d@posting.google.com...
> "David L. Mills" <mills@udel.edu> wrote in message
news:<ch4gk8$gkf$1@dewey.udel.edu>...
> > Mike,
> >
> > All previous and current NTP specifications require port 123 as both
> > source and destination in order to support symmetric peer modes. This
> > has been the case for the last twenty years, so should not be a
surprise.
> >
>
> The ntp implementation shows that this is true for servers that must
> send and receive on port 123. However, a client can use any port it
> wants. This is true of ntpq and ntpdc which cannot use UDP port 123
> since they are in use by the server on which you may want to run them.
> In fact there is nothing in the code that prevents a server receiving
> or dropping packets coming from any other port. So there is no such
> restriction enforced in the official sources. The RFC may need to be
> modified to reflect this.
>
> Danny

Thank you. I would strongly agree  the RFC may need to be modified to
reflect
this point, just as you described.

Who would I write to?

Regards,

Mike Chirico

"Danny Mayer" <mayer@gis.net> wrote in message
news:3a2a0492.0409061857.4e42367d@posting.google.com...
> "David L. Mills" <mills@udel.edu> wrote in message
news:<ch4gk8$gkf$1@dewey.udel.edu>...
> > Mike,
> >
> > All previous and current NTP specifications require port 123 as both
> > source and destination in order to support symmetric peer modes. This
> > has been the case for the last twenty years, so should not be a
surprise.
> >
>
> The ntp implementation shows that this is true for servers that must
> send and receive on port 123. However, a client can use any port it
> wants. This is true of ntpq and ntpdc which cannot use UDP port 123
> since they are in use by the server on which you may want to run them.
> In fact there is nothing in the code that prevents a server receiving
> or dropping packets coming from any other port. So there is no such
> restriction enforced in the official sources. The RFC may need to be
> modified to reflect this.
>
> Danny

Danny,

Perhaps you missed the fact that Dr. David L. Mills (who posts on this list)
wrote the RFC's for NTP and 2030, not to mention
the ntpd at www.ntp.org, from which most/many implementations of NTP are
based.


-- 
-- 
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jamesh@cybermesa.com
noc@cybermesa.com
(505) 795-7101

"Mike Chirico" <mchirico@comcast.net> wrote in message news:<9JGdnQs0c4RHtqDcRVn-oA@comcast.com>...
> > The ntp implementation shows that this is true for servers that must
> > send and receive on port 123. However, a client can use any port it
> > wants. This is true of ntpq and ntpdc which cannot use UDP port 123
> > since they are in use by the server on which you may want to run them.
> > In fact there is nothing in the code that prevents a server receiving
> > or dropping packets coming from any other port. So there is no such
> > restriction enforced in the official sources. The RFC may need to be
> > modified to reflect this.
> >
> > Danny
> 
> Thank you. I would strongly agree  the RFC may need to be modified to
> reflect
> this point, just as you described.
> 
> Who would I write to?
> 

David Mills. email: mills@udel.edu. From what Dave says, IETF is not
reviewing or doing anything with this RFC so there is noone at IETF
to turn to.

Danny

> Regards,
> 
> Mike Chirico

"james edwards" <jamesh@cybermesa.com> wrote:

> Perhaps you missed the fact that Dr. David L. Mills (who posts on this
> list) wrote the RFC's for NTP and 2030, not to mention
> the ntpd at www.ntp.org, from which most/many implementations of NTP are
> based.

Perhaps you missed the point that Danny is one of the contributors to
ntp.org, and that he is the guy responsible for writing and maintaining all
the network code within the Reference Implementation.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

Yes, I referenced to wrong person. Sorry Danny, I intended no slight to you.

-- 
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jamesh@cybermesa.com  noc@cybermesa.com
http://www.cybermesa.com/ContactCM
(505) 795-7101


<brad@shub-internet.org> wrote in message
news:20040912131606.871$8x@newsreader.com...
> "james edwards" <jamesh@cybermesa.com> wrote:
>
> > Perhaps you missed the fact that Dr. David L. Mills (who posts on this
> > list) wrote the RFC's for NTP and 2030, not to mention
> > the ntpd at www.ntp.org, from which most/many implementations of NTP are
> > based.
>
> Perhaps you missed the point that Danny is one of the contributors to
> ntp.org, and that he is the guy responsible for writing and maintaining
all
> the network code within the Reference Implementation.
>
> -- 
> Brad Knowles, <brad@stop.mail-abuse.org>
>
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>     -Benjamin Franklin, Historical Review of Pennsylvania.
>
>   SAGE member since 1995.  See <http://www.sage.org/> for more info.