Source address in response always the same as target address inrequest? - NTP

This is a discussion on Source address in response always the same as target address inrequest? - NTP ; Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 35

Thread: Source address in response always the same as target address inrequest?

  1. Source address in response always the same as target address inrequest?

    Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    source address in
    all responses the same as the UDP target address in the original
    requests?
    I doubt it would be a UDP requirement because this is domain of upper
    protocols.

  2. Re: Source address in response always the same as target addressin request?

    guuwwe@hotmail.com wrote:
    > Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    > source address in
    > all responses the same as the UDP target address in the original
    > requests?
    > I doubt it would be a UDP requirement because this is domain of upper
    > protocols.



    Yes and no. The basic protocol does not require it. The reference
    implementation does require it. The Autokey crypto authentication
    scheme currently requires it, but there has been some discussion
    recently about the nature of that requirement and whether it could
    be relaxed, but I don't see that discussion going anywhere in this
    regard.

    Brian Utterback

  3. Re: Source address in response always the same as target addressin request?

    Guys,

    In both the NTPv4 specification and reference implementation the
    destination address used by the client when mobilizeing the association
    and sending the request must match the source address when receiving the
    response. This is a property of all RPC protocols known to me that use
    addresses to match requests with responses. This is so obvious a
    requirement that maybe the specification doesn't make it clear enough.

    Dave

    Brian Utterback wrote:
    > guuwwe@hotmail.com wrote:
    >
    >> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >> source address in
    >> all responses the same as the UDP target address in the original
    >> requests?
    >> I doubt it would be a UDP requirement because this is domain of upper
    >> protocols.

    >
    >
    >
    > Yes and no. The basic protocol does not require it. The reference
    > implementation does require it. The Autokey crypto authentication
    > scheme currently requires it, but there has been some discussion
    > recently about the nature of that requirement and whether it could
    > be relaxed, but I don't see that discussion going anywhere in this
    > regard.
    >
    > Brian Utterback


  4. Re: Source address in response always the same astarget address in request?

    guuwwe@hotmail.com wrote:
    > Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    > source address in
    > all responses the same as the UDP target address in the original
    > requests?
    > I doubt it would be a UDP requirement because this is domain of upper
    > protocols.


    If you want to use Autokey, it's a requirement. However, firewalls can
    also fail if you don't reply from the same address as it cannot match
    the source of the reply packet to the address of the outgoing packet.

    Danny

  5. Re: Source address in response always the same as target addressin request?

    I beg to differ. Most UDP based protocols do not have this requirement.
    If they did, it would not be the case that in the (mumble mumble) years
    since the invention of the UDP protocol and the sockets interface,
    that the interface even provided the ability for the application to
    to do this within the interface within the last few years.

    The UDP protocol itself has no such requirement. Although the
    Hosts requirements RFC says that a host SHOULD provide a mechanism
    to do it, until IPv6 came along, few systems actually did. The
    only way to guarantee it was using the awful "bind every interface"
    trick that the reference implementation uses.

    The "RPC protocol" itself (RFC 1050) does not have this requirement.

    I do not know why the original designers of UDP did not include this
    requirement. I suspect they did not foresee the security requirements
    we have today. Or perhaps they had a good reason. But in any case the
    NTPv3 spec does not have the requirement in it. If I recall correctly,
    the NTPv4 spec does have the requirement, but I also recall commenting
    on this ages ago, comments that were ignored.

    I don't disagree that UDP should have the requirement, but it does not,
    and as such I do object to gratuitously adding the requirement to NTP,
    which has complicated the code base to no end.

    Of course, as I said above, it is now possible to implement this cleanly
    on many OS's, which would allow us to simplify the code immensely. But
    until such support is universal, that won't happen.

    Brian


    David L. Mills wrote:
    > Guys,
    >
    > In both the NTPv4 specification and reference implementation the
    > destination address used by the client when mobilizeing the association
    > and sending the request must match the source address when receiving the
    > response. This is a property of all RPC protocols known to me that use
    > addresses to match requests with responses. This is so obvious a
    > requirement that maybe the specification doesn't make it clear enough.
    >
    > Dave
    >
    > Brian Utterback wrote:
    >> guuwwe@hotmail.com wrote:
    >>
    >>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>> source address in
    >>> all responses the same as the UDP target address in the original
    >>> requests?
    >>> I doubt it would be a UDP requirement because this is domain of upper
    >>> protocols.

    >>
    >>
    >>
    >> Yes and no. The basic protocol does not require it. The reference
    >> implementation does require it. The Autokey crypto authentication
    >> scheme currently requires it, but there has been some discussion
    >> recently about the nature of that requirement and whether it could
    >> be relaxed, but I don't see that discussion going anywhere in this
    >> regard.
    >>
    >> Brian Utterback


  6. Re: Source address in response always the same astarget address in request?

    Brian,

    UDP is stateless. There is absolutely no way that the UDP protocol
    developers could require that that a reply go back to the same address
    from which the packet was sent or that it be sent from the same IP
    address. No reply is ever required of a datagram. It would be a protocol
    layering violation to do so. The NTP protocol requirement is proper in
    this context.

    Danny

    Brian Utterback wrote:
    > I beg to differ. Most UDP based protocols do not have this requirement.
    > If they did, it would not be the case that in the (mumble mumble) years
    > since the invention of the UDP protocol and the sockets interface,
    > that the interface even provided the ability for the application to
    > to do this within the interface within the last few years.
    >
    > The UDP protocol itself has no such requirement. Although the
    > Hosts requirements RFC says that a host SHOULD provide a mechanism
    > to do it, until IPv6 came along, few systems actually did. The
    > only way to guarantee it was using the awful "bind every interface"
    > trick that the reference implementation uses.
    >
    > The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >
    > I do not know why the original designers of UDP did not include this
    > requirement. I suspect they did not foresee the security requirements
    > we have today. Or perhaps they had a good reason. But in any case the
    > NTPv3 spec does not have the requirement in it. If I recall correctly,
    > the NTPv4 spec does have the requirement, but I also recall commenting
    > on this ages ago, comments that were ignored.
    >
    > I don't disagree that UDP should have the requirement, but it does not,
    > and as such I do object to gratuitously adding the requirement to NTP,
    > which has complicated the code base to no end.
    >
    > Of course, as I said above, it is now possible to implement this cleanly
    > on many OS's, which would allow us to simplify the code immensely. But
    > until such support is universal, that won't happen.
    >
    > Brian
    >
    >
    > David L. Mills wrote:
    >> Guys,
    >>
    >> In both the NTPv4 specification and reference implementation the
    >> destination address used by the client when mobilizeing the association
    >> and sending the request must match the source address when receiving the
    >> response. This is a property of all RPC protocols known to me that use
    >> addresses to match requests with responses. This is so obvious a
    >> requirement that maybe the specification doesn't make it clear enough.
    >>
    >> Dave
    >>
    >> Brian Utterback wrote:
    >>> guuwwe@hotmail.com wrote:
    >>>
    >>>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>> source address in
    >>>> all responses the same as the UDP target address in the original
    >>>> requests?
    >>>> I doubt it would be a UDP requirement because this is domain of upper
    >>>> protocols.
    >>>
    >>>
    >>> Yes and no. The basic protocol does not require it. The reference
    >>> implementation does require it. The Autokey crypto authentication
    >>> scheme currently requires it, but there has been some discussion
    >>> recently about the nature of that requirement and whether it could
    >>> be relaxed, but I don't see that discussion going anywhere in this
    >>> regard.
    >>>
    >>> Brian Utterback

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  7. Re: Source address in response always the same astarget address in request?

    Perhaps proper, but ill-advised. Look at the trouble we have
    had trying to satisfy that requirement. I am sitting at a
    system that currently has over 300 UDP ports in use. Exactly
    one of those UDP ports is bound on each interface, namely 123.
    Interestingly, it is also bound twice on the wildcard address
    as well.

    Until recently, it wasn't possible in a portable manner, for
    a process to listen on a UDP port, receive a request and
    then issue a reply with the reply's source address guaranteed
    to be the same as the request's destination address. And
    virtually all UDP protocols had a way to deal with it, except
    NTP.


    Danny Mayer wrote:
    > Brian,
    >
    > UDP is stateless. There is absolutely no way that the UDP protocol
    > developers could require that that a reply go back to the same address
    > from which the packet was sent or that it be sent from the same IP
    > address. No reply is ever required of a datagram. It would be a protocol
    > layering violation to do so. The NTP protocol requirement is proper in
    > this context.
    >
    > Danny
    >
    > Brian Utterback wrote:
    >> I beg to differ. Most UDP based protocols do not have this requirement.
    >> If they did, it would not be the case that in the (mumble mumble) years
    >> since the invention of the UDP protocol and the sockets interface,
    >> that the interface even provided the ability for the application to
    >> to do this within the interface within the last few years.
    >>
    >> The UDP protocol itself has no such requirement. Although the
    >> Hosts requirements RFC says that a host SHOULD provide a mechanism
    >> to do it, until IPv6 came along, few systems actually did. The
    >> only way to guarantee it was using the awful "bind every interface"
    >> trick that the reference implementation uses.
    >>
    >> The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >>
    >> I do not know why the original designers of UDP did not include this
    >> requirement. I suspect they did not foresee the security requirements
    >> we have today. Or perhaps they had a good reason. But in any case the
    >> NTPv3 spec does not have the requirement in it. If I recall correctly,
    >> the NTPv4 spec does have the requirement, but I also recall commenting
    >> on this ages ago, comments that were ignored.
    >>
    >> I don't disagree that UDP should have the requirement, but it does not,
    >> and as such I do object to gratuitously adding the requirement to NTP,
    >> which has complicated the code base to no end.
    >>
    >> Of course, as I said above, it is now possible to implement this cleanly
    >> on many OS's, which would allow us to simplify the code immensely. But
    >> until such support is universal, that won't happen.
    >>
    >> Brian
    >>
    >>
    >> David L. Mills wrote:
    >>> Guys,
    >>>
    >>> In both the NTPv4 specification and reference implementation the
    >>> destination address used by the client when mobilizeing the association
    >>> and sending the request must match the source address when receiving the
    >>> response. This is a property of all RPC protocols known to me that use
    >>> addresses to match requests with responses. This is so obvious a
    >>> requirement that maybe the specification doesn't make it clear enough.
    >>>
    >>> Dave
    >>>
    >>> Brian Utterback wrote:
    >>>> guuwwe@hotmail.com wrote:
    >>>>
    >>>>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>>> source address in
    >>>>> all responses the same as the UDP target address in the original
    >>>>> requests?
    >>>>> I doubt it would be a UDP requirement because this is domain of upper
    >>>>> protocols.
    >>>>
    >>>> Yes and no. The basic protocol does not require it. The reference
    >>>> implementation does require it. The Autokey crypto authentication
    >>>> scheme currently requires it, but there has been some discussion
    >>>> recently about the nature of that requirement and whether it could
    >>>> be relaxed, but I don't see that discussion going anywhere in this
    >>>> regard.
    >>>>
    >>>> Brian Utterback

    >> _______________________________________________
    >> questions mailing list
    >> questions@lists.ntp.org
    >> https://lists.ntp.org/mailman/listinfo/questions
    >>

    >


    --
    blu

    "You've added a new disk. Do you want to replace your current
    drive, protect your data from a drive failure or expand your
    storage capacity?" - Disk management as it should be.
    ----------------------------------------------------------------------
    Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  8. Re: Source address in response always the same astarget address in request?



    Danny Mayer wrote:
    > Brian,
    >
    > UDP is stateless. There is absolutely no way that the UDP protocol
    > developers could require that that a reply go back to the same address
    > from which the packet was sent or that it be sent from the same IP
    > address. No reply is ever required of a datagram. It would be a protocol
    > layering violation to do so.


    And yet the host requirements RFC does so require it, at least to
    the "SHOULD" level:

    When the local host is multihomed, a UDP-based request/response
    application SHOULD send the response with an IP source address
    that is the same as the specific destination address of the UDP
    request datagram.

    My contention is that although it is a SHOULD, the sockets API did
    not provide a way to actually accomplish it, so very few UDP
    protocols do not deal with the failure to do so. Except NTP.
    --
    blu

    "You've added a new disk. Do you want to replace your current
    drive, protect your data from a drive failure or expand your
    storage capacity?" - Disk management as it should be.
    ----------------------------------------------------------------------
    Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  9. Re: Source address in response always the same as target addressin request?

    Brian,

    I beg to differ with your beg to differ. RFC 768 requires that the UDP
    checksom includes the pseudo header, which itself contains the IP source
    and destination addresses. Technically speaking the addresses don't have
    to mean anything, but it would be pretty silly for a RPC server not to
    know how to return the goods to its client. Maybe you are talking about
    the socket interface, rather than the protocol data unit. I wasn't.

    Dave

    Brian Utterback wrote:

    > I beg to differ. Most UDP based protocols do not have this requirement.
    > If they did, it would not be the case that in the (mumble mumble) years
    > since the invention of the UDP protocol and the sockets interface,
    > that the interface even provided the ability for the application to
    > to do this within the interface within the last few years.
    >
    > The UDP protocol itself has no such requirement. Although the
    > Hosts requirements RFC says that a host SHOULD provide a mechanism
    > to do it, until IPv6 came along, few systems actually did. The
    > only way to guarantee it was using the awful "bind every interface"
    > trick that the reference implementation uses.
    >
    > The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >
    > I do not know why the original designers of UDP did not include this
    > requirement. I suspect they did not foresee the security requirements
    > we have today. Or perhaps they had a good reason. But in any case the
    > NTPv3 spec does not have the requirement in it. If I recall correctly,
    > the NTPv4 spec does have the requirement, but I also recall commenting
    > on this ages ago, comments that were ignored.
    >
    > I don't disagree that UDP should have the requirement, but it does not,
    > and as such I do object to gratuitously adding the requirement to NTP,
    > which has complicated the code base to no end.
    >
    > Of course, as I said above, it is now possible to implement this cleanly
    > on many OS's, which would allow us to simplify the code immensely. But
    > until such support is universal, that won't happen.
    >
    > Brian
    >
    >
    > David L. Mills wrote:
    >
    >> Guys,
    >>
    >> In both the NTPv4 specification and reference implementation the
    >> destination address used by the client when mobilizeing the
    >> association and sending the request must match the source address
    >> when receiving the response. This is a property of all RPC protocols
    >> known to me that use addresses to match requests with responses. This
    >> is so obvious a requirement that maybe the specification doesn't make
    >> it clear enough.
    >>
    >> Dave
    >>
    >> Brian Utterback wrote:
    >>
    >>> guuwwe@hotmail.com wrote:
    >>>
    >>>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>> source address in
    >>>> all responses the same as the UDP target address in the original
    >>>> requests?
    >>>> I doubt it would be a UDP requirement because this is domain of upper
    >>>> protocols.
    >>>
    >>>
    >>>
    >>>
    >>> Yes and no. The basic protocol does not require it. The reference
    >>> implementation does require it. The Autokey crypto authentication
    >>> scheme currently requires it, but there has been some discussion
    >>> recently about the nature of that requirement and whether it could
    >>> be relaxed, but I don't see that discussion going anywhere in this
    >>> regard.
    >>>
    >>> Brian Utterback

    >>

    >



  10. Re: Source address in response always the same astarget address in request?

    Brian Utterback wrote:
    > Perhaps proper, but ill-advised. Look at the trouble we have
    > had trying to satisfy that requirement. I am sitting at a
    > system that currently has over 300 UDP ports in use. Exactly
    > one of those UDP ports is bound on each interface, namely 123.
    > Interestingly, it is also bound twice on the wildcard address
    > as well.
    >
    > Until recently, it wasn't possible in a portable manner, for
    > a process to listen on a UDP port, receive a request and
    > then issue a reply with the reply's source address guaranteed
    > to be the same as the request's destination address. And
    > virtually all UDP protocols had a way to deal with it, except
    > NTP.
    >


    Not true. NTP had a number of bugs in it that needed to get fixed.
    Getting through all of the use cases took a long time to get right.
    That's a bug not an architectural flaw.

    Danny

  11. Re: Source address in response always the same astarget address in request?

    Danny Mayer wrote:
    > Brian Utterback wrote:
    >
    >> Perhaps proper, but ill-advised. Look at the trouble we have
    >> had trying to satisfy that requirement. I am sitting at a
    >> system that currently has over 300 UDP ports in use. Exactly
    >> one of those UDP ports is bound on each interface, namely 123.
    >> Interestingly, it is also bound twice on the wildcard address
    >> as well.
    >>
    >> Until recently, it wasn't possible in a portable manner, for
    >> a process to listen on a UDP port, receive a request and
    >> then issue a reply with the reply's source address guaranteed
    >> to be the same as the request's destination address. And
    >> virtually all UDP protocols had a way to deal with it, except
    >> NTP.
    >>
    >>

    >
    > Not true. NTP had a number of bugs in it that needed to get fixed.
    > Getting through all of the use cases took a long time to get right.
    > That's a bug not an architectural flaw.
    >

    What's not true? Are you saying that NTP doesn't need to bind all the
    interfaces anymore?
    If that is the case, then great, but the argument still stands. If that
    is not the case,
    then nothing has changed and the argument still stands.

    Brian Utterback

  12. Re: Source address in response always the same as target addressin request?

    I went back to your original message and re-read it. I think the
    problem here is in the phrase "property of all RPC protocols
    [...] that use addresses to match requests with responses."

    What is not clear and what the original poster is in fact asking,
    is whether or not NTP is such a protocol that uses "addresses to
    match requests with responses". My point is that while NTP may
    be designed to be such a protocol, I think it was a mistake to
    to make it so. Or if there was a good reason to make it so, I
    would like it explained to me why.



    "David L. Mills wrote:
    > Brian,
    >
    > I beg to differ with your beg to differ. RFC 768 requires that the UDP
    > checksom includes the pseudo header, which itself contains the IP source
    > and destination addresses. Technically speaking the addresses don't have
    > to mean anything, but it would be pretty silly for a RPC server not to
    > know how to return the goods to its client. Maybe you are talking about
    > the socket interface, rather than the protocol data unit. I wasn't.
    >
    > Dave
    >
    > Brian Utterback wrote:
    >
    >> I beg to differ. Most UDP based protocols do not have this requirement.
    >> If they did, it would not be the case that in the (mumble mumble) years
    >> since the invention of the UDP protocol and the sockets interface,
    >> that the interface even provided the ability for the application to
    >> to do this within the interface within the last few years.
    >>
    >> The UDP protocol itself has no such requirement. Although the
    >> Hosts requirements RFC says that a host SHOULD provide a mechanism
    >> to do it, until IPv6 came along, few systems actually did. The
    >> only way to guarantee it was using the awful "bind every interface"
    >> trick that the reference implementation uses.
    >>
    >> The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >>
    >> I do not know why the original designers of UDP did not include this
    >> requirement. I suspect they did not foresee the security requirements
    >> we have today. Or perhaps they had a good reason. But in any case the
    >> NTPv3 spec does not have the requirement in it. If I recall correctly,
    >> the NTPv4 spec does have the requirement, but I also recall commenting
    >> on this ages ago, comments that were ignored.
    >>
    >> I don't disagree that UDP should have the requirement, but it does not,
    >> and as such I do object to gratuitously adding the requirement to NTP,
    >> which has complicated the code base to no end.
    >>
    >> Of course, as I said above, it is now possible to implement this cleanly
    >> on many OS's, which would allow us to simplify the code immensely. But
    >> until such support is universal, that won't happen.
    >>
    >> Brian
    >>
    >>
    >> David L. Mills wrote:
    >>
    >>> Guys,
    >>>
    >>> In both the NTPv4 specification and reference implementation the
    >>> destination address used by the client when mobilizeing the
    >>> association and sending the request must match the source address
    >>> when receiving the response. This is a property of all RPC protocols
    >>> known to me that use addresses to match requests with responses. This
    >>> is so obvious a requirement that maybe the specification doesn't make
    >>> it clear enough.
    >>>
    >>> Dave
    >>>
    >>> Brian Utterback wrote:
    >>>
    >>>> guuwwe@hotmail.com wrote:
    >>>>
    >>>>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>>> source address in
    >>>>> all responses the same as the UDP target address in the original
    >>>>> requests?
    >>>>> I doubt it would be a UDP requirement because this is domain of upper
    >>>>> protocols.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> Yes and no. The basic protocol does not require it. The reference
    >>>> implementation does require it. The Autokey crypto authentication
    >>>> scheme currently requires it, but there has been some discussion
    >>>> recently about the nature of that requirement and whether it could
    >>>> be relaxed, but I don't see that discussion going anywhere in this
    >>>> regard.
    >>>>
    >>>> Brian Utterback
    >>>

    >>

    >


  13. Re: Source address in response always the same astarget address in request?

    Brian Utterback wrote:
    > Danny Mayer wrote:
    >> Brian Utterback wrote:
    >>
    >>> Perhaps proper, but ill-advised. Look at the trouble we have
    >>> had trying to satisfy that requirement. I am sitting at a
    >>> system that currently has over 300 UDP ports in use. Exactly
    >>> one of those UDP ports is bound on each interface, namely 123.
    >>> Interestingly, it is also bound twice on the wildcard address
    >>> as well.
    >>>
    >>> Until recently, it wasn't possible in a portable manner, for
    >>> a process to listen on a UDP port, receive a request and
    >>> then issue a reply with the reply's source address guaranteed
    >>> to be the same as the request's destination address. And
    >>> virtually all UDP protocols had a way to deal with it, except
    >>> NTP.
    >>>
    >>>

    >>
    >> Not true. NTP had a number of bugs in it that needed to get fixed.
    >> Getting through all of the use cases took a long time to get right.
    >> That's a bug not an architectural flaw.
    >>

    > What's not true? Are you saying that NTP doesn't need to bind all the
    > interfaces anymore?


    No, it does to thast.

    > If that is the case, then great, but the argument still stands. If that
    > is not the case,
    > then nothing has changed and the argument still stands.
    >


    If you want to send a reply back to a client how would you specify the
    outgoing local interface address? Even using sendmsg() you cannot do
    that if you want to use, for example, the wildcard socket. Don't forget
    this is UDP so it's connectionless and is a separate datagram each time.
    There are very few choices here. With TCP there is an established
    connection and you can reply on that connection. This is not the case here.

    Danny

  14. Re: Dimensioning NTP Server

    Hi
    Iam planning to have NTP Server for something around 50,000 Clients in
    the Network

    Can Anyone guide me in dimensioning the NTP Server. What are the
    guidelines that I should take care for dimensioning the NTP Server

    Also can I two NTP Servers running in active-stand by or in Load
    balancing scenario in the same network

    Regards
    Vivek Aggarwal

  15. Re: Source address in response always the same astarget address in request?



    Danny Mayer wrote:

    > If you want to send a reply back to a client how would you specify the
    > outgoing local interface address? Even using sendmsg() you cannot do
    > that if you want to use, for example, the wildcard socket. Don't forget
    > this is UDP so it's connectionless and is a separate datagram each time.
    > There are very few choices here. With TCP there is an established
    > connection and you can reply on that connection. This is not the case here.
    >


    That's my point. The socket interface does not provide a way to
    do something that is required to use the NTP protocol. The fact that
    the sockets API has existed for so long without that ability is
    my evidence that the requirement should not have been so lightly
    made. If the requirement was really so universal (as Dave suggested)
    as to not even need to be mentioned in the spec and just assumed,
    then I contend that the sockets API would have a way to easily
    meet that requirement. Which as you pointed out, it does not.

    --
    blu

    "You've added a new disk. Do you want to replace your current
    drive, protect your data from a drive failure or expand your
    storage capacity?" - Disk management as it should be.
    ----------------------------------------------------------------------
    Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  16. Re: Dimensioning NTP Server

    "Aggarwal Vivek-Q4997C" wrote in message
    news:750BBC72E178114F9DC4872EBFF29A5B05217A23@ZMY1 6EXM66.ds.mot.com...

    > Iam planning to have NTP Server for something around 50,000 Clients in
    > the Network
    >
    > Can Anyone guide me in dimensioning the NTP Server. What are the
    > guidelines that I should take care for dimensioning the NTP Server


    "Do not start up all clients at once."

    Under normal conditions, clients will quickly back off to one packet
    per 1024 seconds. I could scrounge up an old 386SX-16 motherboard
    for you, but even that isn't going to be fazed by 50 packets per
    second, I'm afraid.


    > Also can I two NTP Servers running in active-stand by or in Load
    > balancing scenario in the same network


    Load balancing... yes, I think so. I can't think of anything that
    would go wrong. But the usual way to provide high NTP availability
    is to simply have all clients query all of four servers all the time.
    Because it's not only a question of the number of servers likely to
    be up. The real question is 'what time is it?' when there are four
    answers, or three, or two, all just a little different.

    Groetjes,
    Maarten Wiltink



  17. Re: Dimensioning NTP Server

    >>> In article <750BBC72E178114F9DC4872EBFF29A5B05217A23@ZMY16EXM6 6.ds.mot.com>, Q4997C@motorola.com (Aggarwal Vivek-Q4997C) writes:

    Aggarwal> Hi Iam planning to have NTP Server for something around 50,000
    Aggarwal> Clients in the Network

    Is this a LAN or a WAN?

    Have you seen http://support.ntp.org/Support/DesigningYourNTPNetwork ?

    While I think 1 or 2 machines could handle the load (if the clients all
    started at the same time it would be fun for a little while), you will do
    better overall having at least several machines offering NTP service, both
    in terms of reliability and load. The machines you would need for this
    service should all be pretty inexpensive.

    And if you could write up your experience (or email it to me) I would
    appreciate it.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  18. Re: Source address in response always the same as target addressin request?

    Brian,

    Are we having a disconnect here or are we talking right past each other?
    NTP has evolved from very many protocols of the late 1970s and early
    1980s, including ICMP, GGP, EGP, UDP/TIME, UTP/DAYTIME, UDP/QOD, SNMP
    and countless others. These protocols multiplex among possibly many
    servers and clients using the IP addresses and ports (UDP). A client
    sending a request to a server must know the source address of the reply
    in ordet to match the request to the reply data structures.

    This was the intent of the original design and as evolved in the Gateway
    Architecture and Data Structures (GADS) task force and its successor the
    Internet Architecture (INARC) task force, both of which I happened to chair.

    This engineering design might today be considered archaic and maybe even
    a collossal mistakce. However, you need to make the case. Furthermore,
    this has absolutely nothing to do with sockets or Unix programming
    style. I made this abundantly clear to Mike Karels of UCB at the time in
    a meeting with DARPA principals concerned that UCB was a loose cannon
    and uncooperative with Internet design principles.

    Hyde Park in London on Sunday Morning...

    Dave

    Brian Utterback wrote:
    > I beg to differ. Most UDP based protocols do not have this requirement.
    > If they did, it would not be the case that in the (mumble mumble) years
    > since the invention of the UDP protocol and the sockets interface,
    > that the interface even provided the ability for the application to
    > to do this within the interface within the last few years.
    >
    > The UDP protocol itself has no such requirement. Although the
    > Hosts requirements RFC says that a host SHOULD provide a mechanism
    > to do it, until IPv6 came along, few systems actually did. The
    > only way to guarantee it was using the awful "bind every interface"
    > trick that the reference implementation uses.
    >
    > The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >
    > I do not know why the original designers of UDP did not include this
    > requirement. I suspect they did not foresee the security requirements
    > we have today. Or perhaps they had a good reason. But in any case the
    > NTPv3 spec does not have the requirement in it. If I recall correctly,
    > the NTPv4 spec does have the requirement, but I also recall commenting
    > on this ages ago, comments that were ignored.
    >
    > I don't disagree that UDP should have the requirement, but it does not,
    > and as such I do object to gratuitously adding the requirement to NTP,
    > which has complicated the code base to no end.
    >
    > Of course, as I said above, it is now possible to implement this cleanly
    > on many OS's, which would allow us to simplify the code immensely. But
    > until such support is universal, that won't happen.
    >
    > Brian
    >
    >
    > David L. Mills wrote:
    >
    >> Guys,
    >>
    >> In both the NTPv4 specification and reference implementation the
    >> destination address used by the client when mobilizeing the
    >> association and sending the request must match the source address when
    >> receiving the response. This is a property of all RPC protocols known
    >> to me that use addresses to match requests with responses. This is so
    >> obvious a requirement that maybe the specification doesn't make it
    >> clear enough.
    >>
    >> Dave
    >>
    >> Brian Utterback wrote:
    >>
    >>> guuwwe@hotmail.com wrote:
    >>>
    >>>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>> source address in
    >>>> all responses the same as the UDP target address in the original
    >>>> requests?
    >>>> I doubt it would be a UDP requirement because this is domain of upper
    >>>> protocols.
    >>>
    >>>
    >>>
    >>>
    >>> Yes and no. The basic protocol does not require it. The reference
    >>> implementation does require it. The Autokey crypto authentication
    >>> scheme currently requires it, but there has been some discussion
    >>> recently about the nature of that requirement and whether it could
    >>> be relaxed, but I don't see that discussion going anywhere in this
    >>> regard.
    >>>
    >>> Brian Utterback


  19. Re: Source address in response always the same as target addressin request?

    Brian,

    You say "until recently"; NTP has been intimate with Unix since the
    early 1980s. Is this recent?

    Second and more importantly, if the address is not used to bind a
    request to a reply, what else can replace it?

    Why do you have 300 sockets bound to an interface with a stateless
    protocol? This appears to be a fundamental violation of the stateless
    paradigm.

    Dave

    Brian Utterback wrote:

    > Perhaps proper, but ill-advised. Look at the trouble we have
    > had trying to satisfy that requirement. I am sitting at a
    > system that currently has over 300 UDP ports in use. Exactly
    > one of those UDP ports is bound on each interface, namely 123.
    > Interestingly, it is also bound twice on the wildcard address
    > as well.
    >
    > Until recently, it wasn't possible in a portable manner, for
    > a process to listen on a UDP port, receive a request and
    > then issue a reply with the reply's source address guaranteed
    > to be the same as the request's destination address. And
    > virtually all UDP protocols had a way to deal with it, except
    > NTP.
    >
    >
    > Danny Mayer wrote:
    >
    >>Brian,
    >>
    >>UDP is stateless. There is absolutely no way that the UDP protocol
    >>developers could require that that a reply go back to the same address
    >>from which the packet was sent or that it be sent from the same IP
    >>address. No reply is ever required of a datagram. It would be a protocol
    >>layering violation to do so. The NTP protocol requirement is proper in
    >>this context.
    >>
    >>Danny
    >>
    >>Brian Utterback wrote:
    >>
    >>>I beg to differ. Most UDP based protocols do not have this requirement.
    >>>If they did, it would not be the case that in the (mumble mumble) years
    >>>since the invention of the UDP protocol and the sockets interface,
    >>>that the interface even provided the ability for the application to
    >>>to do this within the interface within the last few years.
    >>>
    >>>The UDP protocol itself has no such requirement. Although the
    >>>Hosts requirements RFC says that a host SHOULD provide a mechanism
    >>>to do it, until IPv6 came along, few systems actually did. The
    >>>only way to guarantee it was using the awful "bind every interface"
    >>>trick that the reference implementation uses.
    >>>
    >>>The "RPC protocol" itself (RFC 1050) does not have this requirement.
    >>>
    >>>I do not know why the original designers of UDP did not include this
    >>>requirement. I suspect they did not foresee the security requirements
    >>>we have today. Or perhaps they had a good reason. But in any case the
    >>>NTPv3 spec does not have the requirement in it. If I recall correctly,
    >>>the NTPv4 spec does have the requirement, but I also recall commenting
    >>>on this ages ago, comments that were ignored.
    >>>
    >>>I don't disagree that UDP should have the requirement, but it does not,
    >>>and as such I do object to gratuitously adding the requirement to NTP,
    >>>which has complicated the code base to no end.
    >>>
    >>>Of course, as I said above, it is now possible to implement this cleanly
    >>>on many OS's, which would allow us to simplify the code immensely. But
    >>>until such support is universal, that won't happen.
    >>>
    >>>Brian
    >>>
    >>>
    >>>David L. Mills wrote:
    >>>
    >>>>Guys,
    >>>>
    >>>>In both the NTPv4 specification and reference implementation the
    >>>>destination address used by the client when mobilizeing the association
    >>>>and sending the request must match the source address when receiving the
    >>>>response. This is a property of all RPC protocols known to me that use
    >>>>addresses to match requests with responses. This is so obvious a
    >>>>requirement that maybe the specification doesn't make it clear enough.
    >>>>
    >>>>Dave
    >>>>
    >>>>Brian Utterback wrote:
    >>>>
    >>>>>guuwwe@hotmail.com wrote:
    >>>>>
    >>>>>
    >>>>>>Are there any clear requirements in NTP/SNTP RFC docs about the UDP
    >>>>>>source address in
    >>>>>>all responses the same as the UDP target address in the original
    >>>>>>requests?
    >>>>>>I doubt it would be a UDP requirement because this is domain of upper
    >>>>>>protocols.
    >>>>>
    >>>>>Yes and no. The basic protocol does not require it. The reference
    >>>>>implementation does require it. The Autokey crypto authentication
    >>>>>scheme currently requires it, but there has been some discussion
    >>>>>recently about the nature of that requirement and whether it could
    >>>>>be relaxed, but I don't see that discussion going anywhere in this
    >>>>>regard.
    >>>>>
    >>>>>Brian Utterback
    >>>
    >>>_______________________________________________
    >>>questions mailing list
    >>>questions@lists.ntp.org
    >>>https://lists.ntp.org/mailman/listinfo/questions
    >>>

    >>

    >


  20. Re: Source address in response always the same as target addressin request?

    Brian,

    I recall the SHOULD was inserted to support the anycast model where any
    of a number of servers could respond to a specific request. NTP along
    with many others in the late 1970s did not anticipate such a model and,
    even if they did, as later in NTP manycast, the addresses are still
    necessary for operation sugbsequent to discovery.

    Dave

    Brian Utterback wrote:

    >
    > Danny Mayer wrote:
    >
    >>Brian,
    >>
    >>UDP is stateless. There is absolutely no way that the UDP protocol
    >>developers could require that that a reply go back to the same address
    >>from which the packet was sent or that it be sent from the same IP
    >>address. No reply is ever required of a datagram. It would be a protocol
    >>layering violation to do so.

    >
    >
    > And yet the host requirements RFC does so require it, at least to
    > the "SHOULD" level:
    >
    > When the local host is multihomed, a UDP-based request/response
    > application SHOULD send the response with an IP source address
    > that is the same as the specific destination address of the UDP
    > request datagram.
    >
    > My contention is that although it is a SHOULD, the sockets API did
    > not provide a way to actually accomplish it, so very few UDP
    > protocols do not deal with the failure to do so. Except NTP.


+ Reply to Thread
Page 1 of 2 1 2 LastLast