> This would only cause trouble, I guess, if the customer's > system attributes some special security status to packets > that appear to come _from_ a site-local address, which would > be quite inadvisable.
Hmm, perhaps there is some misunderstanding of how site-locals would be used for security, because the idea is in fact to give special security status to packets that come from a site-local address. Here's the model that I have in mind. First, the definition of a site has nothing to do with geography. It has to do with administrative & routing boundaries. The typical site is at least partially connected to the internet, so it has a global prefix. (Actually one or more global prefixes.) Plus it has the site-local prefix. The site uses a common subnet numbering plan across its prefixes, global and site-local. Applications use site-local addresses to ensure that communication is within the site. For example, one has a file server that is intended only for use within the site: the file server is restricted to only processing requests from site-local addresses. But the file server node also has a global address for other uses. In a more extreme example, one may have a private node that should only be accessible within the site, so the node has a site-local address but no global addresses. OK, so how does one implement this functionality without site-locals? The most obvious alternative is to do filtering or firewalling of the global prefix at nodes within the site. (Note - NOT filtering at the site boundary!) So the file server node is configured with a filter rule to block packets to the file service port with source addresses that don't match the site's global prefix. The private site-internal node is configured with a filter rule to block all packets with source addresses that don't match the site's global prefix. Etc. Now in previous email I pointed out the inherent "defense in depth" of the site-local prefix, because there will likely be multiple site-boundary routers between an attacker and the site, all of which would have to malfunction or be misconfigured to let the attacker's site-local packets into the site. In contrast, the alternative approach has no defense in depth. Any mistake in configuring the filter rules on a file server or private node lets the attacker through. And many more nodes have to be configured properly, because all the internal applications and private nodes have to be individually protected with filter rules, vs just configuring the site-boundary routers. If the site renumbers, all those filter rules have to updated properly. Now in recent email, if I understand correctly, Keith is proposing that non-routable global addresses replace site-locals in the above scenario. So the site would have its normal routable global prefix and also a non-routable global prefix. The non-routable global prefix would be standardized so that distributed applications could recognize it. This sounds exactly like site-locals with the 38 bits of zero replaced with a unique site identifier so that derived addresses are globally unique yet not globally routable (sites could make private peering arrangements to route them). (This is of course an idea that has been raised & rejected by the WG several times previously, but never mind that for now.) Keith, do I understand this right?? Thanks, Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
