On 05/14/2013 10:37 PM, Hosnieh Rafiee wrote:
> 2- Nodes may use an IID that was generated based on a MAC address and use
> this in their response
> A MAC based IID may still be valid and this RFC does not force the node to
> stop using it.
> Solution: The node MUST not generate its IID based on a
Hi,
> >In my opinion, it is better to update the current RFCs or obsolete
> >them instead of adding more specifications which will result on
> >confusing vendors. Of course, it is my point of view and some people
> >are disagree with that. They would like to have several optional
> >standards
>Failed to catch what you exactly mean.
>IMHO, a method for CGA to be privacy address could be :
>keep public key unchanged, and choose different modifier each time so as to
obtain different IP, and
>only when address ownership is required, send CGA parameter including
modiefer, public key,etc.
> Here's what is read: "IPv6 is a well-defined set of completed standards."
>
> Here's what is seen: "Lots of RFCs, both 'standard track' and
informational, and
> IETF drafts floating around." [1][2]
>
> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg79157.html
> 2. http://ripe58.ripe.ne
>BTW,how to add some salt to make CGA randomized as provacy address? Since
public key has
>to be kown to receiver.
CGA provides local link security. So the public key is only exposed within
the same network and it is not published on the internet. The privacy is not
important if you are in the s
>
> There is a part of me that wishes that we just deploy what we have. There
is
> another part that notices that between IEEE802, privacy addresses, CGA,
stable
> privacy addresses and probably a few more, we have built a nice mess and
> maybe we should clean it up. For example, we could decree t
Hi Sujing,
At 22:07 06-05-2013, Sujing Zhou wrote:
Considering the current level of IPv6 deployment, we have got so many specs...
Yes.
Here's what is read: "IPv6 is a well-defined set of completed standards."
Here's what is seen: "Lots of RFCs, both 'standard track' and
informational, and IE
Christian Huitema 写于 2013-05-07 13:28:19:
> > Considering the current level of IPv6 deployment, we have got so
> many specs...
> > BTW,how to add some salt to make CGA randomized as privacy
> address? Since public key has
> > to be kown to receiver.
>
> The CGA identifiers result from the h
> Considering the current level of IPv6 deployment, we have got so many
> specs...
> BTW,how to add some salt to make CGA randomized as privacy address? Since
> public key has
> to be kown to receiver.
The CGA identifiers result from the hash of a modifier, a subnet prefix, a
collision count
Considering the current level of IPv6 deployment, we have got so many
specs...
BTW,how to add some salt to make CGA randomized as provacy address? Since
public key has
to be kown to receiver.
> There is a part of me that wishes that we just deploy what we have.
> There is another part that not
There is a part of me that wishes that we just deploy what we have. There is
another part that notices that between IEEE802, privacy addresses, CGA, stable
privacy addresses and probably a few more, we have built a nice mess and maybe
we should clean it up. For example, we could decree that comp
Hi Bob,
> >
> > As far as I can see, if I set the RFC 4941 timer to a reasonable
> > value, my IID will change much more often than my subnet prefix.
> >
>
> I would like to see the answer to Brian's comment, I didn't see a response
to it
> in the thread.
>
That is true. But the problem that I a
Hi,
On May 4, 2013, at 12:54 PM, Brian E Carpenter
wrote:
. . . .
>
> As far as I can see, if I set the RFC 4941 timer to a reasonable
> value, my IID will change much more often than my subnet prefix.
>
I would like to see the answer to Brian's comment, I didn't see a response to
it in th
Follow up:
>To my understanding, rfc4941 meant to use CGA exactky as defined in rfc
3972.
To clarify what my purpose is, I want to address the situation where the
node is not using stable storage but still needs to generate a random IID.
This document is only an update to that section to provid
>To my understanding, rfc4941 meant to use CGA exactky as defined in rfc
3972.
>The modified CGA algorithm in draft-rafiee-6man-ra-privacy has nothing to
do with CGA.
>How are u going to do with the CGA parameter?
There is no CGA option to add to the ICMP messages. Using a part of CGA
alg
To my understanding, rfc4941 meant to use CGA exactky as defined in rfc
3972.
The modified CGA algorithm in draft-rafiee-6man-ra-privacy has nothing to
do with CGA.
How are u going to do with the CGA parameter?
There is no meaning in send modifier in CGA parameter then.
If modifier is meant to b
As I wrote in the draft, the time frame for the lifetime of the IP address
should be left up to the use choose based on network policy, but with the
caveat that it should not be so long as to let it be tracked by an attacker.
I explained that as long as the session is valid (layer 5), the node ca
> => I tried to not participate to this... Nethertheless this is *not* an
European
> law, only a EC directive project. BTW even if (when?)
Yes, first as I explained to Brian, that was a reference for the meaning of
privacy and a possible way for protecting privacy. Second, it is better to
be prepa
In your previous mail you wrote:
> The aim of this draft is to adapt the current RFC to the latest European law
> http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en
=> I tried to not participate to this... Nethertheless this is *not*
an European law, only a EC directive project. BT
Hi,
I've had a very brief look, because there was one specific thing I was looking
for, and it doesn't seem to be there.
Addresses/IIDs have to last at least as long as the transport layer/application
connections are using them, unless the transport layer/application connection
takes ownership
>
> > The aim of this draft is to adapt the current RFC to the latest
> > European law
> > http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en
>
> Can you please identify the exact clause in the proposed EU regulation that
> would require pseudo-random IIDs that change when the subnet
> The aim of this draft is to adapt the current RFC to the latest European law
> http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en
Can you please identify the exact clause in the proposed EU regulation
that would require pseudo-random IIDs that change when the subnet
prefix changes?
22 matches
Mail list logo
