Darren Reed writes:
> Dan McDonald wrote:
> > Their "better approach" is employed by our IKEv1 daemon, but it has problems
> > with file-descriptor limits (when many local addresses exist), and needing
> > to
> > monitor routing-socket behavior for local-address additions and deletions.
> >
> ...
>
> The question I've got to ask is, why is the IKE daemon receiving packets for
> so many different IP addresses?
> Is it a required part of some protocol spec?
> Or is it an application design thing?
> Or...?
It's the usual UDP application problem: if you're a UDP-based server,
then you're supposed to use the same IP address and port as the source
values in your reply as the client originally used in his destination.
If you're single-homed, no problem. If you're multi-homed, and you
have only one socket, then the stack itself will pick a source address
for you on sending, and that source address may well be one that you
didn't intend to use.
There are two known work-arounds for this. One is to have a zillion
sockets open, each one bound to one of your local addresses and ports,
so you can reply from the right local address when desired. The other
is to use something like IP_PKTINFO to set the source address on
output, so it always matches correctly.
As RFC 1122 section 3.3.4.2 says:
(1) If the datagram is sent in response to a received
datagram, the source address for the response SHOULD be
the specific-destination address of the request. See
Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
section of [INTRO:1] for more specific requirements on
higher layers.
(For IPsec, that's more likely a "must.")
--
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]
