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