Messages in this thread | | | Subject | Re: Fw: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries?? | Date | Mon, 08 Feb 1999 15:46:48 -0500 | From | Ted Lemon <> |
| |
Sigh.
> 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/
| |