RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

["Tony Li" <Tony.Li@procket.com>]

We also run into the issue of doing an identifier to locator
mapping.  If the identifier is a random value, then this
would be 'challenging'.  However, if this is a 64 bit
administratively assigned number, then we have both global
uniqueness and hierarchical search capability.

Tony


|    -----Original Message-----
|    From: Brian E Carpenter [mailto:brian@hursley.ibm.com] 
|    Sent: Monday, May 05, 2003 12:06 AM
|    To: Peter Tattam
|    Cc: multi6@ops.ietf.org
|    Subject: GSE IDs [Re: IETF multihoming powder: just add 
|    IPv6 and stir]
|    
|    
|    Peter Tattam wrote:
|    ...
|    > >
|    > > 3) We know from previous discussion that 64 bits is 
|    too short for a
|    > > randomly assigned global space;
|    > 
|    > I thought we were talking about a M + S + 64 bits 
|    address space where the M
|    > bits can be guaranteed globally unique and the S bits 
|    are managed by the site.
|    > For the purposes of global routing, this is unique 
|    enough to guarantee no
|    > collisions.  The uniqueness of the 64 bits within the 
|    local segment are managed
|    > by existing mechanisms of address autoconfig.
|    
|    That isn't the only requirement. If the M is mutable and 
|    the S has no 
|    particular reason to be unique, then if you have a set of peers 
|    intercommunicating, you've only got the 64 bit IDs 
|    available to act as 
|    unique IDs for transport end-point and security end-point 
|    identification.
|    
|    So there is a strong requirement that the 64 bit IDs be 
|    unique within
|    any set of intercommunicating peers. (In the case of TCP, 
|    the set has
|    two members; in the case of FTP it's any number, by use of the PORT
|    command.) 
|    
|       Brian
|    
|