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. A large number of your objections seem to boil down to "SLs break if people try to use them for global connectivity". This seems an education problem - site locals are site local, which means exactly what it says. NAT is a nasty kludge to give private addresses non-private connectivity. A few of the notes on your list are are multi-homing issues. These exist independent of site-locals. > > - There is also a global connection, at which point the address > > selection rules should use this for external connection. > > the presence of a site local isn't as significant as the absence of > a global address. but the presence of a global address doesn't imply > a global connection. > > 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? Of course, the instant you try to connect external to the site, things /will/ (or SHOULD) fail if site locals are involved. 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. 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. 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. > > 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. 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. > 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." 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." In both cases the app should probably try all combinations, but at least we can help it pick right the first time. 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. > 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. >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" My short summary: (a) Within a "site", a site local address works at least as well as a global address. (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. (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. -- Andrew White [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
