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? > > What if routing isn't actually > > allowed between those networks? > > That's what firewalls are used for. Yes ... and that prevents you from using a single address. > > 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. When responding to a unicast query, a multi-homed server has to be careful with the selected source address. Thus the requirements in the RFC I've been citing (1122) and the use of IP_PKTINFO and many similar (and ancient) source address selection control methods in a huge number of applications. This issue isn't by any means new. > NTP servers typically run as a muilticast client that listens for the > announcements, a different mode of operation to that where it has > a server address configured (or at least that's my understanding.) NTPv4 includes a new "manycast" mode of operation that combines multicast and unicast methods. -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
