[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Identifier (structure) [Was: Agenda for Vienna]
> In another message you write:
> > to my understanding multiple of the above solutions are based on the
> > loc/id separation
> > That is:
> > - mobility
> > - HIP
> > - address agile transports
> > - loc/id
> > Are solutions based on the separation of loc/id roles. I mean all of
> > them use a fixed identifier for application layer and multiple locators
> > for routing (in this case in the end -hosts)
> Careful here: not everything that uses more than one address separates
> the locator and identifier functions.
Agree, but i would say that any multi-address solution that preserves
established communications does implements some sort of loc/id split.
> Address agile transports simply
> use multiple addresses that overload the loc+id functions the same way
> single addresses do in TCP and UDP.
I am not so sure about this. I guess that any proposal of address agile
transport layer must present only ONE single address to the application
layer, which plays the role of identifier, while all the others address
plus this one are the locators.
The difference here is that the distinction is made in the transport
layer and not in the IP layer, but from the application POV there is
still only one identifier and from the routing POV there are multiple
There is still the option of letting the application to manage multiple
addresses. In this case, you can say that the identifier is the set of
locators, but i digress...
> MIP uses the loc+id for the home
> address and just the loc for the care of address. But I'd prefer to not
> categorize MIP as a loc/id variant because it doesn't really address
> this issue (as far as I know, that draft is REALLY long).
I do not understand what you mean here...
HoA is an identifier and one of the possible locators and CoAs are
alternative locators, do you have an alternative interpretation?
> By the way, does anyone know if MIPv6 and routing optimization are
> supported widely yet? I seem to remember this was "mandatory"
I think route optimization support on CN is a SHOULD.
> but as
> far as I can tell the stuff I work with doesn't support this or at
> least doesn't say it supports it.
> HIP may in fact incorporate a locator/identifier separation but it does
> so much more and is by its nature not suitable as a general multihoming
> solution so I don't want to count it as loc/id either.
I have to disagree here... HIP splits Loc and id and it can be used to
solve the mh problem, so i see no reason to not consider it as such
I think that many folks agree that the problem is that the a loc and an
id are univocaly mapped since there is a single name (IP address) that
performs both functions. So, the solution would be to extend the mapping
to support the relation between one identifier and multiple locators.
Perhaps there is some agreement in this.
How to actually implement it? Well, all the above proposals do this in
very different ways, so we still have to discuss this.
But As Tony already proposed, we should first reach consensus on the
Loc/id split approach is the way to go. Well, at least the long term
> > A really good approach to this issue is JNC's Endpoint and endpoint
> > names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for
> > those few of you who has not read it yet :-)
> Yes, this is good stuff. The NSRG report was interesting too but a few
> too many open doors. Great the way they start the security
> considerations section on page 2, though. :-)
> One comment on the endpoint thing: this brings up the interesting
> question whether we care about the nature of the item being identified
> by an identifier. Does it matter whether an identifier points to a
> host, a process, a service or an interface? Those have different
> properties, but each may act as an endpoint at some point in time.
I think that the first decision is to decide where to implement the
loc/id split. IMHO it should be done between the IP layer and the
transport layer (or by the upper part of the IP layer, if you wish)
Then, i guess that multiple identifier can be supported so that you can
associate with any element residing above the IP layer that you consider
marcelo bagnulo <firstname.lastname@example.org>