One of the point in the discussion of the "globally unique" site local addresses has been the discussion of their usage. In particular, if the new addresses are globally unique, how do we prevent them from being globally routed and creating a mess in the global routing tables; and, on a related note, how do we make sure that they are actually local? The issue is clearly complex. There are legitimate scenarios in which two sites might want to create some kind of backdoor connection independent of any ISP connection, in a way similar to the various "extranet" scenarios that are common today; it could also be used in a merger situation. There are also illegitimate scenarios in which a powerful customer would pressure an ISP to simply advertize their globally unique /48. I believe that Bob Hinden provided the beginning of the answer when he proposed that all routers would have a default black-hole for the site local prefix. The implementation would be the following: 1) In a local site, advertise the subnet routes in the IGP, possibly a default route for the site, and a black-hole for the site local prefix. This guarantees internal connectivity to the valid subnets, and unreachability for all other sites. 2) In an extranet scenario, import in the IGP an explicit route for the "friendly" sites, and point it to the specific backdoor connecctions to these sites. This will override the blackhole. 3) At a border router, discard all BGP route that point to the site local prefix or subsets of it. 4) At a site border router or firewall, perform ingress filtering and discard all externally sourced packets in which the source address pretends to belong to the internal site. The combination of 1 and 3 presents a powerful disencentive against the "leakage of routes" risk: a powerful customer might pressure a local ISP, but that would be to no avail since the packets would be dropped by the next hop. I believe that the combination of the four rules will provide the desired locality benefits without having to resort to ambiguity as an enforcement mechanism. -- Christian Huitema
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
