Darren.Reed at Sun.COM wrote:
> How about you call them "LLAs" and "non-LLAs"?
>
> Just because an address is not an LLA does not
> mean it is routable.
Do we have another range of IPv4 unicast addresses
which are not routable by definition? While one
can construct a network which no address is routed
at all, it is a design choice to make sure that
nothing works, not by definition.
> 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.
I guess this is exactly why many people view these
proxies as problems in the IPv4 architecture. They
break a lot of things. But using the above scenario,
will it help if SIOGCLIFCONF shows the LLA by default?
No app will be able to use it to talk to anyone anyway
in the above scenario.
> 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.
It is not that I know better than the app writer. Otherwise,
this case will not have a flag to allow app writers to
also find out about LLA. If an app writer knows exactly
what is needed, then sets the flag and moves on. The key
here is about legacy apps which probably will never be
changed.
> 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.
No, this is not true. You are restricting the apps to
a special environment. In fact, even in a restricted
environment with firewall and "internal addresses," those
apps still work fine talking to other internal hosts using
non-LLAs. But using LLA, those apps will fail, except
talking to another host on link.
> Not every
> address on a NIC is "routable", regardless of its subnet
> allocation. Applications that make assumptions like that
> are simply broken.
I'd say it differently. It is the network topology
designer who is trying to break things by making some
IPv4 addresses not routable. It is a design choice on
the network. But IPv4 apps should not be written to assume
that a non-LLA is not routable.
>> 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.
If an app does not understand LLA so it does not filter
out LLA, it may break in some cases but not in other if
it uses the results from SIOCGLIFCONF. I guess what you
propose is that we don't need to worry about those apps.
It is certainly a design choice. But I don't think you
can say that no apps will be broken, or those apps will
be broken anyway.
> 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.
Because it is true by definition. Only when a network
designer chooses not to do that, this assumption is
broken. But it is not by design of the IPv4 architecture.
> 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?
Yes, it is different. If a machine is actually set up
like the above, I expect the routing table to be set up
properly so that things will work correctly. Note that
LLA is supposed to be set up in an ad hoc fashion auto-
matically. There is no manual set up required. So it
is better to be careful. BTW, unless an app explicitly
bind() to the LLA, the system will not pick the LLA as
the source to talk to any non-LLA. So in this respect,
LLA is safe.
> 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.
Yes, doing the above is bad. And yes, because of NATs, a
lot of things break unfortunately... But it does not
mean that we should not be careful in making sure that
legacy apps work properly.
>>> 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.
Exactly, there is no regression with this case's proposal.
> 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.
What this case tries to do with the ioctl is that
1. If an app knows about LLA and how to/not to use it, it
is fine. It can be changed to also get the LLA.
2. If an app does not know about LLA, as the ioctl will
not return the LLA, it will behave as before, meaning
not working.
The other choice is that we don't worry about any app at all.
So just let them break using LLA in an unknown fashion. I
don't think it is feasible to check what apps will break in
what fashion, even if we restrict ourselves to only those
apps in ON. If most people think that we don't need to worry
about breaking apps in some interesting and not easy to
figure out ways, I can remove this restriction in both
SIOCGLIFCONF and SIOCGIFCONF. This case will not and cannot
make any promise on what apps may break. And there will be
no attempt trying to figure this out.
--
K. Poon.
kacheong.poon at sun.com
