Hi Alper, Greg. I'm not flaming, and not try to generate any heat :-)
Greg Daley wrote:
That's right. This gives the option to use LCoA with a CN if MN
wants to. So, location privacy is an optional feature for MN to
use, unlike with the NATs.
Actually, I think that MN can decide about its use
Shannon -jj Behrens wrote:
This is fine as long as Nokia never goes out of business (I'm not
being snide, I'm being practical).
:-)
In that eventuality there's one at http://gusl.nal.motlabs.com visible
both in v4 and v6.
Not that I support gusl proposal, I must first understand it, but it
seems
Alper, I tried to draw a logic conclusion from this:
-I assumed LCoA and RCoA have same last 64 bits
-I was countered that that is not absolutely necessary, and that rfc
3041 could be used.
-I replied: yes, could, but it is not.
-I was pointed that site-locals might be used too.
-so I concluded.
Alper Yegin wrote:
I don't quite understand this... All CN knows is the RCoA of the
MN. Only LCoA can reveal the location of the MN within the network.
And CN cannot figure out LCoA by looking at RCoA.
What's the difference between a RCoA and a LCoA of a same MN? In my
understanding only the
Hi Greg,
Greg Daley wrote:
There is no problem with the RCoA and LCoA differing only in prefix
if the LCoA and RCoA are based on RFC3041 addresses.
A-ha, that sounds like a tangible goal. I mean there is a big
if in your phrasing. I still need to understand how this would work
in practice
Brian E Carpenter wrote:
If IPv6 has a better anonymity solution, can someone point me
to it? Or do I have to start working on NATv6? (See, this is
why I don't always want to identify myself! :-)
See RFC 3041 - It does exactly what you want without the
drawbacks of NAT.
Actually not, if you
Alexandru Petrescu wrote:
Brian E Carpenter wrote:
If IPv6 has a better anonymity solution, can someone point me
to it? Or do I have to start working on NATv6? (See, this is
why I don't always want to identify myself! :-)
See RFC 3041 - It does exactly what you want without the
drawbacks
Francis Dupont [EMAIL PROTECTED] writes:
So I suppose there's draft, a pointer would help. Far from me any
intention that you imply, sorry.
= draft-ietf-ipngwg-temp-addresses-v2-00.txt
Thanks!
I think there's also MSRN but know nothing about it more than it's
used for
[EMAIL PROTECTED] writes:
I would be a bit careful to use IMEI as Interface Identifier.
Hi Jonne, please let me assure you that I'm trying to be very careful
in all this. If I speak out so frequently is just because I need to
better understand how IPv6 and 3GPP/UMTS can be made to work
Charles E. Perkins [EMAIL PROTECTED] writes:
That's exactly right, and I am suggesting that the draft
be renamed to be IPv6-support-for-what-exists-today.
Hi, appologies for a more than week old follow-up and this has
probably been mentioned.
Being confronted recently with the idea of using
Ignatios Souvatzis [EMAIL PROTECTED] writes:
The idea is to use the same 64bit Interface Identifier (especially
if a globally unique, e.g., derived from the EUI-64 of the node, if
available, or the EUI-64 of one of the Ethernet devices) also for an
interface on a different link that has no
Hi James,
After your reply, my expectations confirm more and more that this is
very much of AAA and PANA issue, and much less of securing the ND.
Simple intuition tells me that if AAA and PANA can help authenticate
the access, then ND is subsequently secured.
If I were to work on securing ND, I
Jari Arkko [EMAIL PROTECTED] writes:
Well... while I'm an AAA guy myself, I really don't wish we need to
get AAA everywhere just to secure our LAN control signaling. I'd
like to concetrate also on infrastructureless methods.
Using Radius to escape 802.11b weaknesses is deployable for small
Claude Castelluccia [EMAIL PROTECTED] writes:
A message digest of the (IMEI, Nonce) will theoretically make use of
all parts of space and will provide unlinkability between IPv6
global addresses and certain devices, what imho is highly
recommendable.
I think that what you propose
Hi Erik, I'll pick the gauntlet, with great care :-)
Erik Nordmark [EMAIL PROTECTED] writes:
When other than Ethernet link layers are involved, probably the
functionality of the u/g bits can be derived from the 8bit prefix?
Maybe it's the 8bit prefix that should be tweaked to obtain the
Michel Py [EMAIL PROTECTED] writes:
IPv6 over ethernet: stick to exactly /64. Probably for TR and FDDI
too.
IPv6 over foo: it might be desirable to get a lower value (make it
fit on a nibble or byte boundary) _if_ accompanied by RFC2373
modifications or new text that define a fixed
James Kempf [EMAIL PROTECTED] writes:
I've submitted a draft on securing neighbor discovery,
draft-kempf-secure-nd-00.txt.
Hi James. Thanks for providing the tandem threat-solution for ND. As
before, I'll make a case against using crypto as a total solution for
a fine-grained problem.
Erik Nordmark [EMAIL PROTECTED] writes:
First, I find CGA (Computationally Generated Addresses) mechanisms to
have valuable IP security properties and are probably exploitable in
some contexts.
CGA = Cryptographically Generated Addresses
Right.
EGA = Expensively Generated Addresses :-)
Hi Francis, thanks for following up on this.
Francis Dupont [EMAIL PROTECTED] writes:
-to this probability one should add administrative probability where
same prefixes are accidentally assigned to two entities.
= this is like link-layer address collision (for instance two Ethernet
Francis Dupont [EMAIL PROTECTED] writes:
= I believe you've mixed in a confusing way the uniqueness of an
address/IID on a link (guaranteed by DAD) and the uniqueness of
a CGA from the security point of view. They are very different
questions.
Ok, I didn't want to generate any confusion. If
[Please excuse cross-posting and multiple copies]
Hi,
This is to announce that the monet list has been moved to
[EMAIL PROTECTED] Archives of discussions starting now as well as
archives of discussions Dec 2001-Jan 2002 are available at:
http://www.nal.motlabs.com/mailman/listinfo/monet
Hi, there's currently a stream of proposals that put random bits on
the Interface ID of an IPv6 address. A background assumption is that
the length of the Interface ID is 64 bits. Another assumption is that
since those ID's are generated from random sources, then their
uniqueness is guaranteed
Tony Hain [EMAIL PROTECTED] writes:
In a quick scan of 3041 I didn't see a reference to that, but it was a
fundemental assumption. If 3041 is updated it would probably help to
have a clear pointer back to 2462.
Sure, thanks for pointing this. I wasn't referring to rfc3041
though.
My remark
Tony Hain [EMAIL PROTECTED] writes:
As for using an address without performing DAD, this is a *bad idea* in
general and fast-handoff is no excuse to avoid verifying that someone
else is not already using an address on the link (assigned or random).
If mip is that far off in the weeds we may
Tony Hain [EMAIL PROTECTED] writes:
I understand the role of cross WG sanity checking, but usually that is
only done when the origin WG believes in the work but want verification,
or that the work really belongs in the other group.
Hi, the remark was born out mainly from my personal oppinions
) in the body. You need to
subscribe to the list in order to send to the list. You can post to the list by
sending mail to [EMAIL PROTECTED] Unsubscribe by sending mail to
[EMAIL PROTECTED] with the two
words unsubscribe monet (again without the quotes) in the body.
Cheers,
Hong-Yon Lach
Alexandru
Soininen Jonne (NET/MtView) [EMAIL PROTECTED] writes:
as Mattias states it is important that GGSN does not have to do DAD.
Hi Jonne. At first I thought I misunderstood what Mattias wrote; but
now that you re-state it, I really don't understand: is GGSN involved
when mobile does DAD? Or I
Soininen Jonne (NET/MtView) [EMAIL PROTECTED] writes:
Anyways, I guess the issues of GPRS L1/L2 should be left for 3GPP to
decide. I do not think we can fix any issues on design decisions of GPRS
link-characteristics here.
That's correct, this is not to be discussed here. Thanks for all your
Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1
without any criticism.
The funniest thing of the 3GPP stateless autoconf is that GGSN
provides the unique interface identifier (an equivalent of an EUI-64)
to the mobile as if the mobile would not know its own unique ID.
Mattias Pettersson [EMAIL PROTECTED] writes:
Alexandru Petrescu wrote:
Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1
without any criticism.
The funniest thing of the 3GPP stateless autoconf is that GGSN
provides the unique interface identifier
Hi,
I'm looking for minutes of the discussions that took place during the
May 30th joint meeting. I have the agenda and a bunch of slides but I
wish I had minutes specifically on answers to previously circulated
questions from the IPv6 Directorate (by voice of T. Narten).
Thanks in advance,
SungJin Lee [EMAIL PROTECTED] writes:
What is the difference between two advertisement below ?
- Renumbered home link router advertisement
- Router advertisement in a foreign link
I'm sharing your surprise there's no written differentiation. It is
so striking that I imagine the
32 matches
Mail list logo
