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. > So I suppose what I'm wondering is why does IKE need to use > any (or every!) address available and not one of a few that > are preconfigured on the server? Because we're talking about multi-homed *servers*. The issue doesn't come up if you're not multi-homed. For example, suppose we have a server that has addresses on sixteen separate subnets, 10.0.0.0/24 through 10.0.15.0/24. There are local systems on each of those subnets, and the server doesn't forward between them (it's only a host). 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? What if routing isn't actually allowed between those networks? What about applications that use link-local multicast (such as NTP and RIP)? Please see RFC 1122 section 3.3.4.2. The rules are pretty simple: when sending a response to some previous packet, you should use a source address on your response that's equal to the destination address on that previous packet. -- 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]
