Keith Moore wrote: > ... > > 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. In other words, I was incomplete earlier. We are required to have a single flat global routing domain, with the additional policy constraint that only a single organization is allowed to inject a given value. Otherwise every address is probabilistically unique. How do you know that someone is not injecting 8/8 into routing today, and confusing some poor soul (or just hijacking the space) in a remote corner of the net? Given the current technology, we probably need the additional policy constraint that any given value is only allowed to appear at a single location, else we can't be sure it is really the authorized originator. > > > 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. No excuses, the existence and use in shipping code of a particular /10 is not preventing progress on uniqueness. > > > 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. You have argued yourself in a full circle. You agree that the address selection issues don't go away, then turn around and say that the existence of a tool for distinguishing which on the list are least likely to work for global purposes makes it impossible for apps to choose, and end up back at the point of an app can't pass around data that it intends for the receiver to use as topology data unless it understands the topology. In fact the local router may not know how to get some packets off the local link if a network manager has limited the routing information available to that router. This is not broken, it is the reality that global routing is not a single flat space. Tony