David Schwartz wrote:
"Brian Utterback" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
David Schwartz wrote:
I am saying the default presumption is that it must be that way but that
particular protocols can override it. That's effectively what SHOULD means
in a general description -- done that way unless the specifics of some
particular case justify doing otherwise.
Oh? Do you know of any OS that does this? Given a multi-homed system,
the OS will respond with the same IP address in the source address that
was used as the destination address in the request, without application
support when using UDP, no matter which of the possibly many destination
addresses were used? I know Solaris doesn't, and truthfully, I don't
see how it could possibly be done.
The application can do it, if it can determine the destination address.
As I pointed out, only Bootps, SNMP and NTP are doing this, at least on
Solaris. Linux, Solaris and other OS's now have a way to get the
destination address via the socket, but that is a very new feature, and
not generally used. Of course, now that it is available, more might use
it, and it would have been unreasonable had the UDP standard demanded
it, but it did not, and as such UDP protocols have traditionally
included methods to work around it.
Further, description of the API for use with UDP in RFC 768
lists the ability to determine the source address of a packet, but does
not list any such ability for the destination, which would be necessary
to accomplish this. The fact that this ability was not listed
and indeed not included in any UDP API until relatively recently should
tell you something about the requirement.
The description of what API where? RFC 768 contains no API description.
Sure it does, on page 2, the section labeled "User Interface".
As I have said before, most UDP protocols are designed to handle this
problem. Only UDP protocols that deal with network control and topology
generally have cared about the destination address. The system I am
using has 356 listening UDP ports open right now, and exactly
3 of those have bound all the interfaces: bootps, snmp, and NTP. Every
one of the others either does not care or has another mechanism for
handling it, like XIDs. The bootps/DHCP and SNMP need to know the
destination address in order for them to respond with the proper answers,
which is to say the answer is different depending on the destination
address of the request. What is NTP's excuse?
What is NTP's excuse for what?
For binding all the interfaces.
I would further point out that none of these are bound to all addresses
in order to prevent port hijacking.
I don't see the relevance.
This was just an aside to Danny Mayer. Pay no notice.
DS
--
blu
"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
