this summary is a good start, IMHO. one comment:
> Scope and Address selection: > > Address selection for hosts is a difficult issue. > > Destinations with only a global address (and hence probably outside the > site) should be addressed using that address, and the source address should > also be global. Traffic destined for outside the site should fail if a > site-local source address is used. > > Destinations with both global and site local addresses (internal hosts) can > be accessed using either. Assuming that a site local exists because the > global address is not persistent, internal only applications should favour > site local addresses. Applications that may include external hosts need to > use global addresses. 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? > 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. 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. (non-routable really means non-routable in the public internet - it doesn't preclude routing via private connections) > Filtering globally > unique routeable addresses is worse, since the reduced scope is hidden from > the application. My assumption is that the prefixes for non-routable global addresses would be well known, so they are as easily filtered as site locals. 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. 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] --------------------------------------------------------------------
