In your previous mail you wrote:
> I believe you can make your set of rules simpler if you introduce
> a new lifetime (or condition if one needs something smarter than
> a delay). I'll call it "regen lifetime" and when the regen lifetime
> of an anonymous address expires then a new
> I believe you can make your set of rules simpler if you introduce
> a new lifetime (or condition if one needs something smarter than
> a delay). I'll call it "regen lifetime" and when the regen lifetime
> of an anonymous address expires then a new address is created, checked
> by DAD then is use
I believe you can make your set of rules simpler if you introduce
a new lifetime (or condition if one needs something smarter than
a delay). I'll call it "regen lifetime" and when the regen lifetime
of an anonymous address expires then a new address is created, checked
by DAD then is used as the a
> Keeping the bottom 24 bits fixed at an initial random value, or
> changing them less frequently than the upper 40, would cut down the
> number of multicast groups joined.
.. but make it easier to correlate multiple connections from the same
host. Unless there are a *lot* of nodes on a link, mo
> think both behaviors should be allowed. Joining too many multicast groups
> might be a significant performance hit in some environments.
Keeping the bottom 24 bits fixed at an initial random value, or
changing them less frequently than the upper 40, would cut down the
number of multicast groups
> This is to limit the number of multicast groups that the
> interface must join?
> While this does not affect long time correlation of the nodes
> communication, it
> allows for easier short time correlation (that is, two
> communicating outside
> observers will be able to notice, that in (pre
> Without addressing most of your points, I think you're (plural if
> necessary) overlooking a mode in which many would wish to operate:
> generating a new anonymous address for almost every active TCP open
> (I say almost because the data connection for an FTP transfer is an
> obvious exception)
Ignatios asked me to forward his comments to the list.
I'll reply separately.
-Original Message-
From: Ignatios Souvatzis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 07, 2000 3:26 AM
To: Richard Draves
Subject: Re: problems with privacy draft
On Tue, Jun 06, 2000 at 05:20
Without addressing most of your points, I think you're (plural if
necessary) overlooking a mode in which many would wish to operate:
generating a new anonymous address for almost every active TCP open
(I say almost because the data connection for an FTP transfer is an
obvious exception) and some c
While implementing draft-ietf-ipngwg-addrconf-privacy-01.txt, some issues
have come up that I'd like to discuss.
The good news is that with the changes I propose below, it does work great.
First some review... RFC 2462 section 5.5.3 discusses processing of a Prefix
Information option for address
10 matches
Mail list logo
