the existence of scoped addresses in v6 forces a greater percentage of
programs to be address aware. some programs that could avoid being
address aware in ipv4 cannot do so in v6 and provide the same
functionality.
Keith,
For the benefit of us uninformed lurkers who learn best by example,
could you provide one?
Already done, see my previous message.
Also, I'm wondering how the SL/1918 address-scoping debate plays in
the context of firewalls. Don't firewalls provide an even more random
form of address scoping that apps must cope with? Or not?
It's a separation of function issue. Ideally, apps try to send messages to
their peers; the network makes a best effort to deliver them there, modulo
policy. That way, the apps can concentrate on their intended purposes, and
the network concentrates on its intended purpose - neither needs to absorb
the complexity required to second-guess the other. Each has a clear set of
expectations, there's an obvious separation between the two, and if something
fails the problem is clearly on one side or the other. Separation of function
minimizes complexity and improves robustness. also, there's less incentive for
an arms race between apps and the network, which also helps to keep complexity
down.
Specifically, in a world where all addresses used by apps are global, if a
firewall blocks traffic from host A to host B, there's nothing that an app on
host A can or should be expected to do about it. The app may not be able to
tell whether it's due to a network failure or a firewall, but it doesn't
matter too much - the most the app can do is retry at a later time. (I'd argue
that ICMP should allow the app to distinguish the two, for the sake of error
reporting, and to distinguish permanent failures due to policy based filtering
from temporary failures due to link outages. But it appears that we need
fixes to both firewalls and APIs to make this work well.)
Scoped addresses muddy this picture, because experience indicates that apps
will be expected to cope with a mixture of scoped and global addresses. Once
scoped addresses are introduced, the app has to perform functions
traditionally performed by the network. If host A cannot reach host B, it
might be due to policy or a network failure, or it might be that the address
that A has for B is not valid in the scope that A is using. There's no way
that A can know this. A might need to try sending to B from a different
interface. Or it might need to try to route the message through a peer that
does have access to B's scope. Or it might need to be able to try multiple
addresses for B. Or all of the above. But since A doesn't have access to the
network topology information anyway (unless it's explicitly configured to know
such things), this involves something between trial-and-error and network
probing. Basically the app is expected to absorb a lot of complexity just to
function in these cases, and even then, the app is not likely to function
reliably. For that matter, since apps now have more reason to try to route
traffic to their destination by any means available (including
application-level tunneling), it becomes much more difficult to make effecitve
firewalls. Even "legitimate" programs will be forced to employ such tactics.
So scoped addresses increase complexity of both apps and networks.