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