> Once we start handing out addresses whose practical scope is less than > global, we either need proxies (eg NAT) or multi-homing.
I disagree. One reason I disagree is that when we make global addresses unreachable, this is usually done because policy dictates that those hosts not be reachable from some portions of the net. Allowing those hosts to be reachable by NAT or via other addresses would circumvent such policies. Another reason I disagree is that from an architectural standpoint it is better to have fewer addresses for a host and expect the network to filter out traffic that is not permitted by policy, than it is to have more addresses for a host and expect applications to choose the correct addresses. The former strategy is both simpler to implement consistently in the network, and easier to support in applications. > Few to none of the > limited scope or multi-homing problems are specific to site locals. In > fact, site locals have a slight advantage in a multi-homing situation in > that they promise that they do not have global scope, and thus may be > singled out by address selection algorithms. This doesn't help, because the application rarely cares about whether an address has global scope - what it cares about is whether the address is reachable by itself or its peers. Since the application is generally unaware of the scopes to which its peers have access, there is no way that it can know whether a global address or a scoped address is better for its peers. What does work is to have a single address for each of its peers, and to expect the network to route traffic there if policy and conditions permit. This separation of function is fundamental to the Internet architecture - the network, not the application, is responsible for routing. > But despite the title, site-local addresses are only one example of a > broader category of addresses that these problems apply to. Well, there are multiple categories that SLs fit into, ranging from "scoped addresses" to "potentially unreachable addresses" to "IP addresses" and beyond. And there are problems associated with all of these. But if you are trying to say that all of the problems with SLs also exist with these other categories, you are simply wrong. Even creating an additional category of scoped addresses (beyond link local) introduces more problems than we would have with just link local addresses. > Site locals as > currently specified do add additional issues for architecture (DNS and SBRs) > if not correctly managed. One question is whether the burden of "correctly" managing SLs is worth the gain. Or perhaps the "correct" way to manage SLs is to not use them at all in connected networks. > However, at the client and application level, > most site-local alternatives suggested here (everything except fully > provider independent routed addresses, without address-based filtering) fall > foul of the same problems as site local addresses themselves. That's true only if you ignore the additional problems that scoped addresses create for applications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
