* Zdenek Radouch <3sp35g$7rsc1@xxxxxxxxxxxxxxxxxxxxxxx> 2005-03-07 22:15 > The major thing the RFC misses is the fact that internal > to one of these "public" or "private" hosts, you may have > another, "even more private" network, for example one > that connects the cards within the chassis. Such network > must be (for obvious reasons) completely hidden > from the outside, and thus cannot come from the > "outside" address space. This "outside" space is a union > of the "public" and "private" IP addresses. > Guess what's left? How 'bout 127.0.0.0. RFC 1918 is in no way related to 127/8, it simply suggest various address spaces considered private and the fact that its status is only best practice makes it obvious that it has open issues such as merging conflicts so I'm not quite sure if I understand what you mean. I think we all agree that having 127/8 fully routeable in the local table would be a good thing although I haven't seen any use for it. There are two major problems involved though: The kernel must know about its own local address for ARP, routing and various other reasons. This isn't a problem because it could simply look up the route but sometimes there is not enough information to do a full route lookup. This issue can be resolved with some effort though. It would get easier if policy routing is ignored for this purpose. Userspace must be told about the address and prefix of the loopback which is done via the LOOPBACK() macro. Extracting parts of the address field is not a problem if userspace is recompiled but making it dynamically is. It would mean to change all userspace applications relying on LOOPBACK() to either use netlink or ioctl. Given this issue has been resolved there it is still likely that certain userspace applications do not use LOOPBACK() and simply rely on the fact that 127/8 has a host scope and is _always_ looped back. Problem #2 can probably be ignored in some cases and left to the operator to resolve. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
