> Keith Moore wrote: > > > > Scope and Address selection: > > > I think it's fairly arbitrary to distinguish "internal-only" applications > > from "applications that may include external hosts". How will the > > application know which category it is in? What if different components > > of the application have different ideas about this? > > Any application involving transactions between two hosts that doesn't want > to pass name or address information to a third party shouldn't have > problems. In this situation, it's probably safe to pick a site-local if > it's mutually available.
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. > The simplest solution I can see is to make it a user problem - if you want > global connectivity, connect using a global name and thus force a global > address. See notes on DNS. well, you might not want global connectivity but still want the app to span site boundaries. but yes, this works fine - provided, of course, that globals are available to such apps, and that people don't expect such apps to function with only site locals. > Alternatively, an application that tries to forward a scoped identifier to a > target outside scope could: > (1) Fail > (2) Attempt to re-establish the session with a more suitable scope. again, (2) presumes that an address pair with "a more suitable scope" is available and known to the app. a big part of the problem is that lots of people will think that they can just assign SLs on their net and expect apps to work. some apps will work, of course. > > > Note: This is IMO the real sticking point of site locals. Globally > > > unique non-routeable addresses have exactly the same problem. > > > > I disagree here for what may be subtle reasons. forgive me for trying > > to explain them again. > > > > My assumption is that if sites expect apps to use site-locals (and > > especially if we don't provide them with good alternatives) then > > customers will demand that many apps be able to operate across site > > boundaries using those addresses, adding considerable complexity to > > those apps and degrading their performance and reliability. > > Hmm. I think this assumption is not as robust as it should be. The > presence of a site local prefix could mean: > > - There is no global connection, at which point the very concept of > operating across site boundaries is meaningless. > > - 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. > 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. > In fact, once global connectivity exists, site local addresses should be > deprecated and eventually removed, unless the allocating authority (human or > automated) has reason to consider that the global prefix allocation is > "transient". again, connectivity isn't necessarily either global or nonexistent. and deprecating the site locals when globals are available would be fine with me, but lots of people claim that there are good reasons to keep them. > > OTOH if non-routable globals are available (except perhaps in isolated > > sites where it doesn' t matter) then it becomes much more reasonable for > > many apps to simply use global addresses whenever they are available. > > The app no longer needs to define its own addressing (at least not for > > the purpose of working around SLs). And it is no longer the app's > > responsibility to know about sites or to try to route between those > > sites. > > If the network designers had wanted to provide a connection between > > those networks they would have done so. > > For clarity, let's talk about restricted scope and global scope [unique] > addresses. (Site local are restricted scope non-unique addresses.) no, that's not clearer. non-routable globals still have global scope. don't confuse addres scope with connectivity. > I must be missing something. I read this several times, and it still seems > to be one of two situations: > > - If apps can tell the difference in scope, then there is functionally no > difference a restricted scope unique or non-unique address. false. non-routable globals are still useful as host/node identification even in the (possibly temporary) absence of connectivity to that host. > - If apps can't tell the difference, then your unique restricted scope > address is from the apps' perspective an unrestricted scope address, which > could lead to some "unexpected" failures due to filtering. no, those kinds of failures should not be unexpected - every app should be able to deal with them. (particiularly if the right ICMP messages result from trying to send traffic to those addresses). "you can't get there from here" is a perfectly valid error condition, since it's a reflection of the underlying network's routing policy. this is not a condition that the app should be trying to work around - it should simply report it. 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. > > However it would not really be valid for an app to assume that a > > non-routable address had a reduced scope in comparison to a > > global address, or that such an address was less likely to work. > > On a network with extensive private connections to other networks but > > lots of filtering on its connections to the public internet the app > > might do better with the non-routable address. > > So not a site, but a mesh of sites with arbitrary connectivity? right. there's a lot of that going around. > At this level of complexity, why not just use globally routeable prefixes > and configure the routers and filters to pass or block packets correctly? that requires each network to have a connection through an ISP. many networks don't want to do that. 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] --------------------------------------------------------------------
