Kacheong Poon wrote: >Darren.Reed at Sun.COM wrote: > >... > >>Wrong. An LLA interface can be used just as well >>as any other interface. The only way I could see >>something untoward happening is if I'm using a >>multihomed box with one interface that has an LLA >>and one that has a "normal" address and an >>application "discovers" the LLA address via some >>means before it discovers the "normal" address >>and then tries to explicitly use the LLA address >>when it should use the other. >> > > >Actually, the above is exactly the scenario, even >with only one link as we can have two IPv4 interfaces >plumbed over it, one with a routable address and >the other with a LLA. >
How about you call them "LLAs" and "non-LLAs"? Just because an address is not an LLA does not mean it is routable. >>This problem can >>arise in other ways too, if other network interfaces >>aren't able to reach the destination that I want >>to reach. >> > > >While the above is certainly true, it is usually >assumed that if one has a routable IPv4 address, it >can be used as the source to communicate with any >other routable IPv4 address. If it fails, it is >a routing problem. But with LLA, it is explicitly >prohibited from doing this. > That is a very very wrong statement to make. In the presence of a proxying firewall, you would not expect to be able to talk to "any address" if you bind to the local socket using the "inside" address. And so forth. So what this all boils down to is you're triyng to make some assumptions about what a program expects to receive in terms of addresses because you believe that you know better than the application writers about what is a good vs bad address to use. Enumerating through all of the entries return is just good programming style, as is trying all of the addresses returned by gethostbyname(), etc. Any program that you believe would be broken because of the LLA will be broken today on multi homed boxes, without LLA. Not every address on a NIC is "routable", regardless of its subnet allocation. Applications that make assumptions like that are simply broken. >>In this case, it is incumbant upon >>the application in question to allow the user to >>specify which interface they way to use, one way >>or another. >> > > >Yes, if the app knows about LLA, it certainly should >filter it out. But the question here is about legacy >support. > Applications don't need to know about LLA support in order to offer this option. >>What it looks like to me that you're trying to >>do is provide a mechanism to work around a >>shortcoming in the general IP APIs offered >>whereby they don't support you asking if a >>destination is reachable via an address you >>want to bind to locally before you try and >>use the local address. >> > > >See above. There is only routable IPv4 unicast address >before the introduction of IPv4 LLA. In this respect, >the existing mechanism works as advertised. All the >addresses returned are usable as the source address to >communicate with any other IPv4 addresss. It is a >short coming of the LLA design. This case only tries to >handle it in a safe way. > I don't know why you believe that all IPv4 addresses in the non-LLA network are routable. They're not. It may be true, in a holisitic fashion, for IPv6, but not IPv4. >>What you seem to be implying is that somehow a box with >>an LLA address is actually going to be receiving things or >>trying to do things that will make it try and reach other >>machines when it in fact can't (or at least shouldn't be.) >> > > >The above is the scenario I wrote in a previous mail. The >host first gets a LLA and talks happily to a printer. Then >it gets a routable address and starts talking to the outside. > How is this different from a host having both an internal IP address (say network 10) and an external IP address (say network 129.146) and using the wrong one in data today? Embedding the IP address in the protocol, anywhere, is just plain harmful and people who do things like that should expect their protocol to break when used over NATs. >>I think you're introducing the potential for them to fail in >>a completely new way: they'll believe that the only network >>available is loopback and either not function or not work >>in any meaningful manner. >> > > >But if there is no LLA at all, will they function then? > No and that's fine because if there is no address (at all) assigned then there cannot be any expectation for any of them to work. Implementing filtering of what ioctl calls return in the sense of what has been proposed appears to me to be a solution looking for a problem - I cannot see any case where the presence of this flag alone benefits anyone when implemented as described. Darren
