RE: about Wedgelayer 3.5 / Fat IP approaches

[Erik Nordmark <Erik.Nordmark@sun.com>]

> If the locators are the AIDs, then there is indeed a problem because
> two hosts have the same locator.  Administratively, this might be 
> preventable in most cases by forcing a host to pick a new key if 
> truncate(hash(key)) matches with another host within that prefix.
> However, not in the mobility case, where a host might roam into
> a prefix where there is an AID collision.
> 
> Anyway, if my m6 layer can differentiate between the two hosts, and
> my applications have provided me with more than the AIDs, I don't
> see why my transport couldn't work also (perhaps not by the AIDs 
> alone, but by some context information passed in the implementation).    

Yes, with enough thrust pigs can fly :-)

It might not be a good idea to assume that all transports and all middleware
layers of software will be modified to carry some additional context where
they today only carry a FQDN or an IP address.

But since such collisions are supposed to be infrequent,
it might actually make a lot more sense to guard against them.
What harm would be caused in the context of a CGA-like scheme
if a host couldn't at the same time communicate with
two (or more) hosts which have the same 64 bit hash
even though the public keys are different?
As long as the nodes with the same 64-bit hash do not communicate
with the same peer at the same time this would have no ill effect at all.

> If there is no exchange of larger IDs prior to conversation, then
> yes, I agree that one can construct ambiguity scenarios where an
> application intends to talk to one host but instead talks to 
> another.  The CB64 draft seems to argue that applications can provide
> the additional verification if desired (Sec. 4.1 point 7).

Section 4.1 point 7 talks about something different; doing the PK crypto check
before any locator change. As specified cb64 relies on the RR check for
the initial setup, and not until there is a locator change does it
end up using public-key crypto. 

   Erik