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.
As part of implementing that RFC we should make the behavior of such
addresses conform with the RFC. It doesn't make sense to allow the user
to get the old (undefined) behavior as an option - nobody would want that.
>> I suspect the issues is more complex than that, since it also matters
>> whether or not the LLA is visible by remote systems (and the local
>> system) in the naming services. I'm assuming you want to make the LLA
>> visible with Bonjour (even if the system has non-LLA addresses?) thus
>> applications will end up using it unknowingly since
>> gethostbyname/getaddrinfo returns it. (If you don't make it visible in
>> Bonjour then nothing of signficanse will use the LLAs, means makes it
>> even less interesting to configure them!)
>
>
> But I expect Bonjour will know what to do when there is a
> routable address. After all, it's supposed to work in
> exactly this situation. I have not looked at Bonjour's
> code to verify this though.
My parenthetical remark about Bonjour was not the concern. The text
before the parenthesis is my concern.
The architectural invariant I'm concerned about is the relationship
between what gethostbyname/getaddrinfo returns for "foo" on a remote
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.
So you are stuck between the proverbial rock and a hard place.
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.
Erik
