> I apologise for the length - for the 8 line summary, skip to the bottom. > > Keith Moore wrote: > > > people made similar incorrect generalizations about NATs. > > see http://www.cs.utk.edu/~moore/what-nats-break.html for a > > list of the kinds of practices/assumptions broken by NATs. > > many of these would also be broken by SLs. > > Within a site, no. Externally, of course.
of course, for an isolated site they cause no problems at all. but if the site has any external connections there will be apps that are expected to take advantage of those external connections. > A large number of your objections seem to boil down to "SLs break if people > try to use them for global connectivity". close. SLs break if people expect apps that use them to communicate with nodes that are off-site. global connectivity is not a necessary condition. > This seems an education problem - > site locals are site local, which means exactly what it says. well, in an sense, education is what IETF does. we need to educate people so that they don't misuse SLs. > A few of the notes on your list are are multi-homing issues. These exist > independent of site-locals. multi-homing issues won't go away entirely, but their effects can be minimized. over-use of SLs will contribute to the problem. > > the address selection rules won't save us for lots of reasons - > > one of which is that they favor SLs over globals even for apps > > that will fail if they try to use SLs. > > Can you give me an example of an application that will fail if two (or more) > nodes in the same site attempt to communicate using site locals instead of > globals? when they learn of each other's addresses through an intermediary which might not be in the same site. the intermediary has no idea whether those nodes are in the same site or not. > Of course, the instant you try to connect external to the site, things > /will/ (or SHOULD) fail if site locals are involved. no, it won't fail the *instant* you connect - it will fail in mysterious and unpredictable (to users) ways at some later time. > DNS is part of a solution. Maintain two namespaces, one local (eg > private.arpa), one global. If you want your application to play globally, > make sure they use the global names. I've seen this used as an attempt to try to cope with multihoming in IPv4 where not all interfaces were globally accessible. my experience is that people have trouble remembering to use different sets of names for different purposes. > The app that comes to mind as a potential problem case is a broker for a > peer-peer mesh (eg game or teleconferencing client). If A is the server, > and B (a machine in the same site) and C (an external machine) both try to > connect to it, it needs to be smart enough to obtain B's global address > (and/or name) so B and C can meaningfully communicate. easliy done, *if* B has a global address. I don't think everyone is assuming that it necessarily has or needs one. > On the other hand, it's entirely possible that A, B and D (another local > machine) want to communicate locally, and the global address is "transient", > thus the local address is to be preferred. User intervention is the only > way to solve this problem, as far as I can see. actually, not using limited-scope addresses helps a lot. B and D might still have to try multiple addresses, and if B tries the transient address first it will have to time out. but at least when B tries D's other address it doesn't reach a different host. > > > IMO, we want to push site local addressing as a (2nd line) mechanism > > > for internal addressing independent of the global address space. At > > > the point a network connects to the global internet, a set of global > > > prefixes should be distributed also. The address selection rules are > > > in place precisely to deal with this multi-addressed situation. > > > > except that they don't deal with this. they assume that the only > > parties concerned with use of an IP address are the immediate source > > and destination. they assume that all applications have the same needs > > from addresses. they assume that all networks have the same preference > > as to which addresses should be used. etc. > > Agreed. Which is why applications should be able to acquire a list of > addresses and meaningfully obtain information about their scope. no. there's no way in general that an app can 'meaningfully obtain obtain information about their scope' if the absence of a global set of scope names. and if you do that you might as well embed the scope name in the address - which gets you back to non-routable globals. > Not all > applications will approve of the default recommendation. > > Note that this is not specifically a site-local issue, it is a multi-homing > and scoped addressing issue. true. personally I like to think of it as an issue resulting from an over-dependence on address selection. but it's really hard to talk about all of these issues at once - you have to pick one angle or another for the sake of a particular conversation. > > > don't confuse addres scope with connectivity. > > For 99% of applications, connectivity is the issue. I don't do an app any > favours if I say: > > "Here are four candidate destination addresses, and you have three source > addresses. I can't provide any hints about which combinations might work." so don't provide so many addresses unless it's absolutely necessary. don't expect the app or the host to make such choices. don't promote the idea that you can assign as many addresses to a host as you want and expect apps to work. finding a path through the network from point A to point B is the network's job, not the job of applications. and the network can do a better job if we at least try to have distinguished names for points, even if not all points are reachable from all other points. > > At least a site local says: > > "To another site local, this as likely to work as any. To anywhere else, I > can almost promise you it will fail." the problem is, an app has no way of knowing whether it's local to that site, or "anywhere else". so it has nothing to inform that choice. at least with NR globals the app has a chance of getting immediate feedback (either from lack of a route or an ICMP message) if it tries to send to an address that isn't reachable. > In both cases the app should probably try all combinations, but at least we > can help it pick right the first time. site locals make this harder, not easier. > The assumption of course is that the site local destination address is 'in > scope'. Hence the stress on not leaking addresses. Within scope, a site > local provides as much information as any other address. Outside scope, the > address is meaningless and any packet found with one should be discarded as > soon as possible. nodes have no idea what scope they are in. > > it's much harder to try to cleanly detect errors that result from trying > > to use ambiguous addresses. but if globals are't available to > > non-globally-connected networks they'll use SLs and expect apps to > > route between them, and that's a mess. > > I find this argument specious. It's about as much sense as saying "walk > into your local bookshop and buy me the third book in the fiction section", > and then complaining because you give me a different book than what I > expected from my bookshop. I don't follow your analogy. Let me try one of my own. Expecting apps to use SLs is like expecting that someone who is married to a person named "mary" will be equally satisfied with the person named "mary" in whatever town he happens to be in (if there is one), or that he'll be satisfied if he cannot telephone his wife (or reaches a different person) if he isn't in his hometown. > From my original summary: > > > Routers and hosts are only expected to support one site local scope. > > Further subdivision of a site local address space should be done using > > the site local aggregate portion of the SLA address. > > Or: "If you want to connect multiple networks, either configure them as a > single site, or use a bigger scoped address" better yet, use a scopeless address. scopes are too much trouble to deal with. > My short summary: > > (a) Within a "site", a site local address works at least as well as a global > address. true, but apps don't know when they're crossing site boundaries. > (b) Outside a site, a site local address DOES NOT WORK. I'd say "MUST NOT > WORK", but that is a little hard to enforce. true. > (c) Given (b), the issues with site locals are about address selection where > there are both global and local addresses available. However, these issues > exist with any multi-homed host, and site locals at least offer applications > some strong cues about when the addresses will fail. the last part is false - the app gets more cues if the addresses can at least potentially be routed. as for "these issues exist with any multi-homed host" pretending that it's a different (or somebody else's) problem won't help minimize it. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
