> > being able to distinguish an ambiguous address from a global > > address doesn't solve the problem of requiring hosts or apps > > to be aware of topology in order to make address selection. > > Ambiguity has nothing to do with the address selection problem here. False. It makes the address selection problem intractable. > > > Making all labels global only works if the routing is in > > > fact globally flat. > > > > It's worked in IPv4 for 20+ years. What has been repeatedly > > shown to not work well is to try to route on non-global > > labels. (anyone remember uucp mail or easynet?) > > It has never worked for multi-homed systems when some of the > participants in an app have a different view of the topology. False, or at least an exaggeration. Basically multi interface hosts have worked just fine as long as the host had a distinguished address which was reachable from each of its interfaces (whether via ARP or routing or whatever), and that it consistently used as a source address -- or more generally, as long as all of the addresses it used as source addresses were routable from any of the nets to which it connected (modulo access control), regardless of whether different routing paths were available to different hosts. What hasn't ever worked is requiring apps to know about routing topology in order to successfully route packets to the destination, where "successfully" might mean a variety of things ranging from "being able to get the packets there at all" to "having those packets utilize the high speed (and/or secure) link". Note again that ambiguous addresses make this problem even harder to solve, by changing the problem from "need more information to know how to get there" to "can't even tell where 'there' is". > > If we can agree on how to make the first 48 bits globally > > unique, does it really matter what values are assigned to the > > first 10 bits? That choice could be made strictly on the > > basis of compatibility issues with existing hosts, apps, and > > routers, once the other technical aspects of GUPIs had been > > worked out. > > Which is one of my points. There have been several proposals offered > to create probabilistically unique 38 bit values, probabilistically unique doesn't cut it, because it's making unreasonable assumptions about the size of the collision domain. remember, hosts don't have to communicate directly in order to cause a collision between their identifiers within an application. > that are compatible > with shipping code that use that specific /10. In other words we have > the technical means to take the ambiguity issue off the table. Getting > rid of the shipping /10 doesn't accomplish the goal of removing > ambiguity, it only delays getting there. the thing we should be doing is figuring out how to provide GUPIs, not figuring out an excuse to keep using the SL prefix. > Your other issue about address selection doesn't go away. IPv6 nodes > will have multiple addresses, therefore a list to select from. agreed, but we can minimize the degree to which the selection is critical. > With a distinguishing flag (upper 10 bits), it becomes possible for > the processes that resolve names to topology locators in order to sort > it out. wrong, because processes that resolve names have no idea about whether such locators are valid in the scopes in which they will be used, much less whether they are suitable for use by the applications. > Without that flag there is no consistent way for that process > to know. wrong. the mere existence of this "flag" is what makes it impossible for the app to know whether the address is valid. > If that process is the end app (because it doesn't trust any > other process to be fast or reliable enough), then the app needs to > know the topology it explicitly intends to describe. Now you're essentially arguing (without any supporting evidence) that the network shouldn't have to know how to route packets beyond the local link. Keith