James Carlson wrote:
Darren Reed writes:
James Carlson wrote:
Darren Reed writes:
James Carlson wrote:
This is a very, very common issue for UDP daemons. For example, it's
an issue that affects DNS servers and RIP.
Because with DNS we can tell clients to use address X, even if
the server can also recieve packets on Y and Z. DNS clients
Sure. But we can also tell clients to use Y and Z, and the server
must respond sanely. That's the whole point. Multi-homing requires
that you understand how to use the addresses you have. Forcing
yourself to use just one means that you aren't really multi-homed.
Why do I need to accept packets addressed to a service for
each particular interface and not just one?
Just so I can say it is "multi-homed"?
What about when that design doesn't scale?
Because doing otherwise forces administrators to deploy in only one
way; it's inflexible.
And because the RFC says otherwise.
Why can't we provide service to all sixteen subnets with that one
server? If what you're suggesting -- always using exactly one address
on a server -- is viable, doesn't that mean that we force N-1 of the
client networks to route packets?
Or even force all N of them to route packets and configure the server
to be on N+1. I don't see the "having to route packets" as a big issue.
Am I missing something?
Only that it's an inflexible solution. You're asserting that binding
to a single address is not just the "best" solution, but that it's the
only one we should make available, and that it's ok if the others just
don't work right.
I disagree. The system should work right even if the user decides to
allow a server to use more than one address. And ancient RFCs already
describe what it means to "work right."
Why argue this?
Ok, I'm not arguing what it means to "work right."
And it hasn't been my intention to.
What I'm questioning is the architecture of the application (or use of
the application) if it finds itself in a position where it needs hundreds
of open file descriptors to manage all of the addresses.
I suppose one solution is what Dan's proposing, but I'm not
alltogether sure I like that because it encourages the use of
INADDR_ANY as something to bind to for servicing a port.
There are security traps present when one chooses to bind to
only INADDR_ANY, potentially allowing someone else to come
along and bind to a specific address, stealing your packets.
What about applications that use
link-local multicast (such as NTP and RIP)?
To the best of my knowledge, both of these protocols use multicast
addresses to supply information, not to do query-request operations.
Not true for both. Both allow unicast query-response operations in
addition to the multicast operation.
Are you saying that NTP and RIP also do query-response for multicast
traffic?
I didn't know (and haven't seen) that... :-o
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
