Kacheong Poon wrote:
> We know that it is a problem to have more than one IPv4
> interface having LLA. But we should not prohibit an
> admin from assigning LLA to more than one interfaces.
> Treating both cases the same means that we should allow
> the system to automatically assign an LLA to more than
> one interfaces. I think we should avoid this kind of
> confusion.
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?
Or what use case are you concerned about?
> There are two sides to this question. One is which app
> will not benefit from this. The other is which app may
> have new failures. For those which may not benefit from
> it, there is no loss. If there is only the LLA, it means
> that if LLA is not supported, there will be no address to
> use at all. So that app will not work anyway.
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!)
> The other question is if the app knows about it and
> somehow uses it to communicate, it will work some time.
> And it is not easy to figure out what is going on.
>
> BTW, should sendmail know about LLA? My guess is that
> it should not.
Depends whether or not you think email loops are a good thing.
Suppose a host has been configured with the LLA 169.254.17.17.
Using the email address syntax with a literal IP address I can now send
mail to root at 169.254.17.17 (perhaps there is some quoting brackets in
the syntax - I didn't double check.)
That will connect to sendmail on the system. Sendmail will check whether
the email is for local delivery, which among other things rely on
knowing all the hostnames and all the IP addresses of the system. Since
you've hidden 169.254.17.17 from sendmail, it will conclude it should
relay this email. Thus it will open a smtp connection to that IP
address. As a result the email will loop.
While sendmail might by default not relay things, the larger point is
that the interaction between what gethostbyname/getaddrinfo returns and
what shows up in SIOCGLIFCONF has some interesting aspects, and the
*architecture* for IPv4 link-local addresses better take that into
account unless we want to end up with a brittle or broken system.
>> Has any customers expressed this need?
>
>
> I have no data. But I guess you can ask some internal
> folks requesting this case about this.
Huh? You said there was a need to implement this, but there is no
customer interest. Is that right?
Frankly, link-local addresses doesn't seem worth the effort. Even if you
do address my concerns above, you'd still end up with a system that is
more complex than without it, and some of that complexity will bleed
through to make the administrator/user have to understand them.
Already today it is the case that any network I've connected the laptop
to has had a DHCP server, and the penetration of DHCP will have further
increased by the time some LLA support shows up in Solaris.
Keep it simple, please!
Erik
