Pekka,

>> Iljitsch van Beijnum wrote:
>> Are you saying that we should make a clear distinction
>> between identifiers and locators, and not have any values
>> that are valid in both realms?

> Pekka Nikander wrote:
> Yes, in the long run.

Would that include going to identifiers that are longer than 128 bits?


> In the short run, we probably have to continue living in a
> world where there is no clear distinction between the two.

Sorry if I ask a stupid question, but the main issue deployment issue
HIP has is basically that every host would need an HIP stack. Since
there is not much you can't do about this, why haven't you pushed the
reasoning further and opted for an extended HIT that would not have some
of the current limitations (background: we did discuss the issue in
Atlanta and one of the things I recalled is that we both wished we had
more bits).


> I do understand your point about the benefits of an
> identifier also being a locator, but I also believe
> that the benefits of clean separation will more than
> pay the drawbacks in the long run. (I don't have any
> analysis or data to support this belief, though.)

I'd be interested in some vague rationale about this.


> Nodes with well-known addresses, such as servers and those
> using stateful configuration, are most vulnerable. Nodes
> that are a part of the network infrastructure, such as DNS
> servers, are particularly interesting targets for attackers,

To put this in context, the paragraph above assumes that the server is
being accessed using the identifier, and that the hackers targets the
id/loc mapping mechanism in order to map the id to _his_ locs, not the
legit ones. 

Did I get this right? And if I did, what difference does it make if the
locators and the identifiers are segregated?

Michel.


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to