Erik,
I don't understand the last point. A KHI couldn't be used in
referrals unless we have a ubiquitous and scalable KHI->locator
lookup system, and I don't think we know how to build such a thing
(yet).
I think we know, at least for some value of "know". We can use
DHTs. What we don
Tony and Erik,
As I wrote, I can't see how we could convince the world from going
from where we are now to a world that requires people to change
their network stack, add a new piece of infrastructure, and to
change applications at the same time. That won't happen, any
more. Even a "kil
Dear Geoff and Brian,
Its a simple draft, but it still makes absolutely no sense to me to
me in terms of relating to to an address allocation. If these token
values are in fact "non routable identifiers" , which is what I
read above, then you have no semantic intersection with the
convent
Dear Geoff,
My apologies, but this is getting a little spaced out in terms of
being able to understand where you are heading here.
[...]
Where exactly are you looking?
Sorry for trying to interpret Christian's intentions, thereby
confusing the things. I merely tried to understand what C
Christian,
=> the draft is supposed to address both issues. For the first one
we can add more cautionary words if one believes there are not yet
enough. For the second one we already merged two very different
experiments into one request.
Well, if that is what we want, then we can write a much
David,
IMHO, every identifier ends up being routed, at least in some
context.
If they are routed, they are not identifiers. They are locators.
An identifier simply names the object. It might enable
connectivity on a non-routed infrastructure, e.g., a local LAN, and
if you want to call
Christian,
IMHO, every identifier ends up being routed, at least in some context.
I think I fully agree with you, but IMHO we need to be very careful
about the terminology here. For example, I can easily imagine an
overlay network, running on the top of the current IP network, using
DHT
Geoff,
I fully agree with you that a new identifier name space should not be
mixed with any existing locator space. In other words, from an ideal
architectural point of view, the goals of having non-routable
identifiers that have different semantics from IPv6 addresses
definitely do not
Geoff,
My understanding is that these are not routable addresses.
you are right: not only they are not routable but they should be
easy to be recognized as not routable.
To clarify: if we decide to define this prefix, it will mean that the
particular prefix will be generally unavailable for
e the prefix at the API level.
Consequently, if you want to talk to those hosts, you cannot use the
prefix in the network.
Hence, even though the prefix is not assumed to appear in the wire,
defining this does effect on what bits can(not) be used in the wire.
--Pekka Nik
so the previous discussion at the IPv6 WG, starting at
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html
--Pekka Nikander
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.i
/4 as suggested, then
I think most router configurations would already now do the right
thing. But I may also be way off here; I'm mostly out of touch with
current IPv6 operational matters.
--Pekka Nikander
IETF IPv6 wor
put := CID | hash function id | Input
Hash1 := Hash(Hash1 input)
SHA1 Input := CID | Hash1
and so on. Basically, you encode another hash function into the
input, and use it first to generate the input for the method defined
in the draft.
--Pekka Nikander
---
ng:
Consequently, the suggested method to react to the hash result
becoming too short due to increased computational power or the used
hash function becoming insecure due to advances in cryptology is to
allocate a new prefix and cease to use the present one.
Mayb
thing for this to rfc2462bis, the protocol will become
complicated, degrading one of the motivations of this clarification.
From the SEND point of view, looks good.
--Pekka Nikander
IETF IPv6 working group mailing list
[
SEND node could well *defend* the address
fe80::A for DAD/DIID purposes, but it would never actually use it.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org
Daniel,
Below is a DNA WG agenda at 59th IETF and DAD Optimization will be
discussed as indicated in this agenda.
The intention is mostly to inform people that the work is
continuing, but that it will be transferred to the IPv6 WG.
For this work, a draft was proposed
in the DNA BoF (before) as be
requires non-member postings
to be explicitly approved by the list admins.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
er requirements) for identification but pure
mobility and multi-homing.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
available at:
http://honor.trusecure.com/mailman/listinfo/hipsec
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
ve up the idea of the
Cartesian theatre already a few years ago. You really
must start reading Dennet and Dawkings. :-)
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
vacy threats
associated with all of the above mentioned needs for identifiers.
However, that is a subject of another mail.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
most probably apply also to SCTP ADD-IP and, of course,
also other multi-address multi-homing solutions.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org
stly, we still don't have secure DNS. Secondly, having to
rely on an authority seems like a bad approach to me. At least
when compared to one where you don't need to rely on authority.
(Just can't resist: Could we compare this to the difference
bet
Michel,
Pekka Nikander wrote:
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.)
M
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?
[I think I answered this separately already elsewhere. Anyway.]
No, just making a clear distinction does not necessarily mean
that we have to go into
streams running.
I know, the MIPv6 RO security background draft is long.
But I don't have time to try to distill a shorter version
of it right now.
--Pekka Nikander
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Ad
27 matches
Mail list logo
