> The ARP thing is only the tip of the iceberg. What about other things
> like ICMP? What about incoming packets in general - you don't want
> generic traffic going there. Plus the 0.0.0.0 address has special meaning
> to the API (i.e. bind all interfaces)... allowing that to be an actual
> interface address is just gross.
Mitchell, your repeated assertions that something required by the RFCs
is gross and shouldn't be implemented elicit sympathy, but not
agreement. Yes, it's hard to get a network stack right. Sure, you
can point out several places where it's necessary to test against
INADDR_ANY in order to be correct. 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? 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, so I don't see how this could be a
problem, given the level of care that's required to get an IP stack to
work reliably in the first place.
In any case, it's an error to ARP for 0.0.0.0. It's an error to send
any kind of IP datagram with a destination address of 0.0.0.0. So
erroneous ICMP responses and ARP responses are extremely unlikely, and
if generated, should only affect the machine making the erroneous
request. Even if some other machine is sniffing ARPs and salting its
cache with them, who cares if it has a bogus entry for 0.0.0.0? If it
tries to send a packet there, its stack is broken!
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. While coming up with a whole new API to support that does meet
the letter of the requirement, it's a real pain for software
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.
I don't think lpf satisfies the host requirements document, because I
can't send an IP datagram with a source address of 0.0.0.0 without
going through some *major* contortions - the latest DHCP client
supports lpf, but still won't work except on ethernet and maybe FDDI,
because lpf is a link layer API, not an IP layer API, so I have to
have link layer encapsulation code in my userland software. Ick.
Satisfying the host requirements document is something you should do,
and not try to push off on innocent software developers.
> And what about application programs that scan the interface list
> (gated, bind, ...) how can be be sure that none of them get
> confused? You can add special case code for all of these, but it'll
> become clear after awhile that you're putting forth alot of effort
> to support this hack.
Such applications already deal with this, and have had to deal with
this, since their inception, since the API supporting 0.0.0.0 as an
interface address has been present since 4.2BSD, and is still present
in all IP stacks of which I am aware other than that of Linux 2.1 and
later. Don't put this off on software developers. Trust me, the
Internet Software Consortium does not mind if you allow a 0.0.0.0
source address, and we're maintaining bind. I'm sure that I can get
somebody authoritative at Merit (the maintainers of gated) to tell you
the same thing, if this is really a concern of yours.
> An interface should not have an IP address that doesn't belong to it (i.e.
> unique to the network and capable of general packet reception).
See RFC1122. It does make a general assertion that agrees with this,
but then makes a specific exception for programs that configure the
network, such as DHCP clients (I think it refers to BOOTP). Both the
DHCP protocol specification and the BOOTP protocol specification make
specific assertions that support for generating a source address of
0.0.0.0 is required.
If you're worried about people mistakenly configuring this IP address,
then by all means require a special flag to be set in order to use it
(but please make sure ifconfig has support for setting that flag,
since the dhcp client uses ifconfig to configure the interface).
> This was the decision by the networking gurus. I suspect that this
> decision is not going to change. It seems to mirror what most other
> OSes are doing.
Um. Can you name one such operating system? Windows, maybe? It's
the only popular one on which I haven't tested the 0.0.0.0 source
address. I too suspect the decision is not going to change, but that
is not going to stop me from pointing out why it should when people
ask me.
Requiring me to rewrite my code, particularly to an API that isn't
documented, and requiring Mike to run two different binaries or set up
some kind of shell script kludge to work around the problem is
backwards thinking. I can't imagine it would require more than a
man-day of effort for somebody knowledgable about the Linux stack to
exhaustively audit it for problems relating to the use of 0.0.0.0 as a
source address.
Incompatibly changing the API has _already_ cost me several man-days
because I don't have a test machine, and so I have to iterate back and
forth with various Linux 2.2 people to fix the problems you've
created. How many people are going to have to create kludges like the
one you suggested to Mike? How much user time is going to be wasted
now trying to figure out why they get "protocol not configured" when
they run the DHCP client? How many man-days does that add up to?
> I think if [you] came up with a good API proposal for this and
> submitted it to the networking mailing list
> (linux-net@vger.rutgers.edu last I checked) [you] might get somewhere
> in the 2.3 kernel. Simply saying "put it back to how it was" over
> and over isn't going to get anything accomplished though. The
> people who took it out did not do so out of ignorance. As for
> [Mike's] oroginal question about avoiding different binaries, just
> put both binaries on each machine and throw together a little shell
> script that looks at uname -r and runs the right one.
How many man-days of effort do you think it would be for me to propose
and implement yet another API? I'm not a Linux geek, man - I'm a
NetBSD geek and an ISC geek. I don't have time to come up with some
API that'll make you happy. I don't think it's reasonable of you to
ask! You were in compliance with RFC1122 as of Linux 2.0. You're out
of compliance now. You're creating extra work for software
developers, and you're creating extra work for Linux users. This is a
problem for you to fix, not a problem for me to fix.
_MelloN_
-
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/