[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
El 03/10/2005, a las 15:58, Paul Jakma escribió:
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?
HBA are constructed using regular PA prefixes assigned by the ISPs
(LIRs) that are serving the multihomed site. Just regular PA prefixes.
The HBA essentially defines the iid
And surely the point of HBA is that they can be locally assigned?
Well, the iid is locally generated (as any IPv6 address) but the prefix
is asigned by the LIR as any PA prefix
(Or do you mean HBA's stand a very good chance of being globally
/unique/?).
no, HBA are administratively unique (as opposed to statistically 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?
i think that Jari and Erik have clearly explained this point
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.
i agree that this is a great benefit of current IPv4 PI address based
solution, but this is clearly not the goal of the shim6 wg
Without portability, you're left only with solving failure events
amongst multihomed links.
I would rephrase it a bit more general, like: the goal of the shim is
to preserve established communications through outages
but yes, portability in the sense of PI addresses are not part of the
scope of the shim work
And I don't think you need a shim layer for this, personally.
here we disagree (but we have already discuss this point)
regards, marcelo
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.