Re: addition of TLV to locator ID or locator ID set

[Paul Jakma <paul@clubi.ie>]

On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:

> i am not sure what you mean here, nut just for stating things 
> precisely, HBA do have globally assigned prefixes

Uh, ah. I didn't realise that. Who assigns them? And surely the point 
of HBA is that they can be locally assigned? (Or do you mean HBA's 
stand a very good chance of being globally /unique/?).

> > I had, in my mind, been considering that there would be a mechanism to 
> > allow the prefix set -> ULID mapping to change
>
> there is, the CGA part of the HBA/CGA hybrid addresses.

> That is why there are three flavors of addresses:
> - HBA that support a static set of addresses that cannot be changed during 
> the lifetime of an established communication (with the cost of a hash per 
> address)
> - CGA/HBA that support a stable prefix set and additional addresses that can 
> be added during the lifetime of the communications (the cost of the stable 
> addresses is a hash operation while the cost of a new address (out of the 
> initial set) is a public key operation)
> - CGA addresses, any addresses can be used with the cost of a public key 
> operation

I'd have to ask: Why use CGA?

AFAICT, CGA was created specifically because relying on IPSec for 
address assignment has bootstrap issues. Hence CGA and SeND.

For modes relying on anonymously introduced public-key cryptography, 
we won't have bootstrap issues here, so why not use standard IPSec? 
Is it just to avoid the size of an AH header on each packet?

How will you communicate the CGA parameters? Is shim to reinvent 
portions of IKE in order to communicate public keys? Why not just use 
IKE? IPSec is well-understood, widely implemented and deployed. Why 
give ourselves the task of reinventing aspects of it?

I can see some of the attractions of HBA, but using CGA beyond the 
local-link is stretching it..

(That's not to say a host that was configured with a key for CGA 
couldn't use the same public key for IPSec..)

> However, you should note that the public key used is included in 
> the hash that results in the interface identifier of the addresses

Ok.

> > fairly big cost in functionality. (Eg, what exactly would shim6 
> > using invariant HBAs offer over application layer remapping 
> > support?
>
> i am not sure i understand what you mean here... could you expand?

For me, the prime benefit of multihoming is not so much having 
multiple links but having number portability and the ability to 
easily transfer between providers[1]. Eg, shim'ing but having only 
one provider would be something I'd be interested in if it gave me 
portability. It's been a big reason for multihoming for two 
organisations I've worked with.

Without portability, you're left only with solving failure events 
amongst multihomed links. And I don't think you need a shim layer for 
this, personally.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
travel, n.:
	Something that makes you feel like you're getting somewhere.