On Wed, May 30, 2007 at 06:59:04AM -0700, Erik Nordmark wrote: > Kacheong Poon wrote: > >Erik Nordmark wrote: > > > >>I don't understand your concern hence I can't follow your logic. Are you > >>concerned with some admin that has chosen to use the link-local address > >>range (169.254/16) for some purpose which is different than link-local > >>addresses as defined by the RFC? > > > > > >Yes. If they do so manually, it is their choice and we should > >not prohibit this. But I'd try not to allow that to happen if > >they use the supported mechanism. > > Makes no sense. > The behavior of 169.254/16 is standardized in RFC 3927. > Given that Solaris hasn't yet implemented that RFC, whatever behavior > somebody sees when configuring the system with such an address is undefined.
Well, no, under the original IP specs the LLA address block and 10/8, and 192.168/16, etcetera should be normal, usable, publicly routable address blocks. These address blocks have been set aside for these uses knowing that noone "owned" them, so that anyone using them would be doing so at their own peril. But I'm nitpicking. If anyone's systems are broken by Solaris' adoption of LLA because they were using LLA addresses in non-LLA ways, well, too bleeping bad -- what were they doing using address that are neither for private use nor theirs? The argument that someone using LLA addresses in non-LLA ways might be upset is really not one we can seriously consider. The IETF was the forum to consider such arguments when LLA was being specified, and, though we're not forced to implement this, the fact is that the evolution of IP has been such that folks had better know by now what address blocks are safe to use in their networks, and which ones are not. Like it or not, the assumption that folks do not use addresses that do not belong to them or are not set aside for private addressing is a crucial aspect of the IPv4 story, and it has been for a long time. >[...] > The architectural invariant I'm concerned about is the relationship > between what gethostbyname/getaddrinfo returns for "foo" on a remote Traditional name services should NOT return an LLA address for "foo." Though they certainly CAN. But if they do, then the customer is outside supported behaviour -- it are using address blocks that do not belong to it and should not be surprised to get burned. > system, and on system "foo" what an application will see with > SIOCGLIFCONF. You are proposing to change that invariant with this case. > > >To be frank, I don't know how Bonjour handles the naming > >service using IPv4 LLA. So I cannot answer what the implication > >is. But I don't think it actually ties to the behavior > >SIOCGILIFCONF does not return the LLA by default. At the > >very least, the code can be changed to set the LLA flag to > >retrieve the LLA. > > You are proposing to change an architectural invariant for IP addresses > and names. > > Changing the default behavior of SIOCGLIFCONF to return LLAs, as you've > correctly pointed out, causes a different set of problems. Have these been described? (Sorry, I stopped following this thread after a while :( > So you are stuck between the proverbial rock and a hard place. Most likely. So pick the least surprising answer. IMO, not including LLA interfaces in SIOCGLIFCONF by default seems fine to me. > Which is why I asked 'do we really need to support RFC 3927?'. I'll > continue to pursue that question in a different forum as you privately > suggested. I've never needed IPv4 LLA. Does anyone? Does it really help? Prior to the advent of Really Cheap SOHO Routers and Ubiquitous Internet Access I might have been willing to believe that LLA could help. Now I'm not sure it really does. But perhaps I'm being way too U.S.-centric! Nico --
