I don't have a particularly rigid stance one way or the other on the
issue, I was mainly attempting to privately recap the points of
view I had seen expressed by people who matter more than me.
Anyway, hopefully that's enough of a disclaimer for everybody...
Ted Lemon wrote:
> But you have to test against
> INADDR_BROADCAST and the local subnet broadcast address in these cases
> anyway, so what's the big deal adding one more test?
Well, Linux won't let you set the IP address to INADDR_BROADCAST either.
It does let you set the IP address to the subnet broadcast address...
I personally suspect that's a bug.
> Sure, if you
> engage in bad programming practice and dangerously overload
> INADDR_ANY, you can run into trouble. Don't do that! The meaning of
> 0.0.0.0 as an IP source address doesn't overlap with any other
> meaningful use of INADDR_ANY,
It already does though - the binding of specific ethernet addresses.
Let me give a hypothetical example showing why this is enough to get
you into trouble. Suppose I was writing a simple proxy server designed
mainly for allowing a few hosts on a LAN to share a ppp dialin connection.
Now obviously a major security concern is misconfigurations that would
create an open proxy. Thus, by default I'll only bind my listening
socket to ethernet ports (just by using a SIOCGIFCONF and looking for
interfaces named "eth*", which is generally good enough for Linux).
All seems fine.
Now suddenly someone installs this on a machine getting its ethernet
address via dhcp. Oops, I just bound INADDR_ANY silently defeating
the security.
Now one can just say "the programmer should have checked for it" and
would be right. But having an API that can confuse a program silently
in an edge case should make people scared.
So I agree with your first two sentences in the above quoted segment
entirely. We _shouldn't_ overload INADDR_ANY because yes it is
dangerous.
> In order to have a complete TCP/IP implementation, according to the
> Host Requirements Document (RFC1122), you _must_ be able to send
> packets with a source address of 0.0.0.0 in order to configure your IP
> stack.
Please cite chapter and verse. As far as I can tell, the only requirement
regarding 0.0.0.0 (3.2.1.3.(a)) is that IF you send such a packet it must
be from a "part of an initialization procedure by which the host learns
its own IP address". It doesn't specify how the OS interfaces with
userland to facilitate sending such packets, nor does it even state that
you "_must_ be able to send" them.
Ted, I have no problem with your dissenting opinion on this issue. In
fact, I regard your opinion quite highly in this matter. However,
claiming that Linux is in violation of RFC1122 (which you did 3 times in
your message) is a rather grave charge... I hope you can back it up.
> implementors, given that there's already a de facto API that works on
> all Unix systems, including Linux prior to 2.1, but not on Linux 2.1
> or later.
If that is really the case (and I assume it is, because you of all
people should know) then MAYBE we should support it for no other
reason than UNIX-standardiztion. I thought I remembered some people
lamenting that there was now "another OS" that had to use the lpf
hack, so I thought there were other unicies doing the same. I
guess I was wrong on this count, sorry.
> Such applications already deal with this, and have had to deal with
[...]
> Trust me, the
> Internet Software Consortium does not mind if you allow a 0.0.0.0
> source address, and we're maintaining bind.
Perhaps I should clarify my point. I wasn't trying to claim that any
of the packages listed have a problem with such interface addresses -
they clearly don't. I was just trying to say that there is the possibility
for confusion about such interface addresses in userland programs (as
I talked about above). I was merely listing things like named and
gated as examples of userland programs that are sensitive to the
interface list. They are examples of programs that could be confused
by a 0.0.0.0 interface address, not examples of programs that are.
> How many people are going to have to create kludges like the
> one you suggested to Mike?
I don't know. Is there any deep reason that lpf could not be made
to work under 2.0? (or does it?) In that case it's not an end-user
issue - it's merely another program that needs to be updated prior to
running a 2.2 kernel. If it can't be (i.e. there is no way to have
a single dhcp-client executable that supports both 2.0 and 2.2; that
seemed to be the nature of the thread that Mike forwarded) then that
is quite unfortunate since admins are going to have to be forced
into using a little script hack.
> How many man-days of effort do you think it would be for me to propose
> and implement yet another API?
Well perhaps one of the local networking gurus has some ideas (anyone?)
The problem as I see it is that when an OS wants to support dhcp they
have the choice between two APIs
1. Allowing an interface address of 0.0.0.0. I think we can both
agree this is non-optimal since it conflicts with the use of
INADDR_ANY in bind(). Obviously we disagree on the severity
of this problem.
2. lpf. This is non-optimal because it requires the application
to know the link-layer encapsulation in use (which it doesn't)
It seems to me that the linux folks who opinions matter (which doesn't
include me, BTW, so don't put this all on my shoulders just because I
answered Mike's question) aren't too keen supporting the
less-than-perfect 0.0.0.0 system. I think the only solution that can
possibly make everybody happy is that if we had a way to get an packet
socket that allowed sending arbitrary L3 frames allowing the kernel to
do the L2 encaps as usual.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/