jamal wrote: > I am assuming you have some form of configuration, no? You should only > configure an IP address to be link local if you really mean it to be > so.
Typically, there is no user-configuration. The 169.254.0.0./16 and FE80::0/8 IP ranges are used for so-called zero configuration networking, where the idea is that no configuration is necessary, but devices automatically pick a self-assigned address. Beside PC's, you should think about devices without an interface to make configuration changes at all (e.g. printers of HP, Lexmark and Epson, the Roku soundbridge, etc.). Jamal also wrote: > Should we hard-code checks for RFC 1918 IPV4 addresses in the kernel? > After all, they are well defined by the IETF. The answer is no. You make a valid argument here: that hard-coding IP address is bad (make it less flexible). To avoid possible confusion, we are not talking about RFC 1918 IPv4 addresses though (private use, a.k.a. "Unique Local Unicast"), but about RFC 3927 IPv4 (self-assigned, a.k.a. "Link-Local Unicast"). Your argument still holds for either range of course. Scope can be used, and applications can be changed to require to set the scope when configuring the IP link-local address. One may argue if this is a big deal or not -- in lines of code it is not, but it would be Linux-specific, and I personally like to see it done more or less the same on all OSes. This is a matter of taste. More importantly, the "scope" parameter does not seem appropriate for the purpose of deciding to broadcast or unicast ARP replies. The "scope" parameter, as I understand, gives the scope of an IP addresses: interface-local, link-local, or global. (IPv6 also define site-local and interface-local, but they are not used, and site-local is deprecated now). On the other hand, what it important with regard to RFC 3927 is not if the IP address is link-local or not, but if it is self-assigned or not. Or actually, if there is a change of an address conflict or not, since that is the reason for the ARP broadcasting. It seems to me that the scope does not convey that information, but something which is slightly different: the uniqueness of the address (globally unique, or only unique on a specific link). > If one was to set the scope to be link local, would it work just fine? Fair question. I think it would work fine for 169.254.0.0 provided that the applications are altered. However, it will also broadcast other ARP replies, which is unnecessary. If that breaks anything -- I do not know. I do not think it will break. However, it clearly deviates from the behaviour defined in existing standards, and I would strongly recommend only to deviate from existing RFC standards if there is a very good reason to do so. The only argument in favour of deviating from the standard seems to make the kernel more configurable. To me as a networking person that is not a convincing argument. By the way, David posed an interesting question -- what *is* the "scope" used for now? I could not find a clear answer with Google. Perhaps someone on the list like to elaborate. Regards, Freek - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
