Re: 64-bit identifiers

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

> The existence of the Privacy Address Configuration specification
> for IPv6 means that the low-order 64-bits CAN NOT uniquely identify
> a host.  Prior to then, using the low-order 64-bits (as proposed
> by original 8+8/GSE) might have worked.  That approach cannot work
> given the current state of specs.  Note well that the "privacy
> extension" spec (sic) is being widely implemented and deployed in
> end-systems (e.g. Windows XP).

... and others are contemplating using the low-order 64 bits 
to solve authorization issues for "redirect" (as in mobile ip binding
updates) as in the SUCV draft.
However, this doesn't make things any worse than with the "privacy extensions"
RFC. But it is more of a technical argument than a perception argument
for using the low-order 64 bits.

> Now one could postulate a different identifer that could be used
> in things like Protocol Control Blocks to bind session state
> and identity (in lieu of using IP addresses as at present).

The transport multihoming, SCTP, and GxSE seem to all be based on
the identifier being a *set of* IP addresses, where the set is
determined when the communcation is initiated. 
I think this is a very interesting space to continue to explore
to understand the differences between the ideas/proposals.
Such approaches would need a separate mechanism for handling renumbering
of long-lived connections since that would require securely changing the set.
(But my gut feel is that whatever secure solution we are confortable
for Mobile IPv6 binding updates effectively "redirecting" traffic, can
be applied to changes in the set of addresses identifying the connection.)

Has the NSRG explored using sets of IP addresses as the indentifiers?
Or are they focused on the issues of inventing a new name space?

  Erik