Keith Moore wrote: > ... > but if the normal way > you get a site local is to buy a router, why would anybody need > more site local prefixes than routers?
Because routers have interfaces in multiple sites. > ... > > If you are arguing that a multiparty app with > > multiple participants on both sides of the site boundary > should be able > > to pass around both SL & Global as explicit addresses, explain why. > > no I'm arguing that every network, private or public, should have > globally unique addresses available to it, and every host on such > a network should be capable of using those addresses, so that apps > don't have to deal with limited-scope or ambiguous addresses at all. > ... > > > ... > > > of course it's a global address. but that doesn't mean > it's globally > > > routable. > > > > You have just argued yourself into a corner. > > no I haven't. the addresses are for private interconnection > agreements, > not for global routing. These arguments are contradictory. If an address isn't globally routed, the app needs to deal with some addresses having a limited scope. Right now we have told the app unambiguously that a specific set of addresses has a limited scope. What you are asking for is that we remove the explicit scope, and leave it up to dynamic routing policy as to where the scope boundary is. How does the app learn where the scope boundary is? At least with the concept of a two-faced DNS, the app has a chance of knowing that if a SL comes back in the query that the node is somewhere in the same private net. I agree no address should ever be ambiguous, but that doesn't require global uniqueness. The thing that is required is that the address be unique within the scope of routability. If you expect an app to figure out that scope, it needs to be through the one piece of information that the app has about topology, and that is the name-to-address-mapping process. The resolution of a restricted-scope address requires an exact match between the administrative boundary of the resolution tool and the routing boundary. If those don't match there is no hope the app will work reliably. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
