Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime

["Hosnieh Rafiee" <[e-mail]>]

Hi Fred,

Actually the content of this draft
(http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime )  was presented
in IETF 87 as a part of ra-privacy. Some people during that meeting thought
that it is better to make this draft more generate and separate it from
ra-privacy;  http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy  (this
draft also does nothing with security and it address the problems with RFC
4941 and also deprecating EUI-64 in RFC 4941.  The draft "deprecated IID"
that is new and contain most of the section that is already explained in
ra-privacy could improve this existing draft)

So, iid lifetime draft, as you already know, does nothing with security but
it is a way of maintaining privacy and try to avoid sacrificing user's
connectivity in IPv6 networks. This draft, first, compares the current
mechanisms available for the lifetime of an IID and then offer a new
mechanism for the mentioned purpose (privacy and connectivity)

> 
> 1) Please provide a succinct problem statement for your draft. What
> problem/issue is this draft discussing? What operational problems does the
> proposal address in real life networks?

We tried to have a short problem statement at the end of Introduction. But
we are open to suggestions if you or anybody else think that there is  a
need for expanding this section.

> 
> 2) Where does this draft or presentation fits into v6ops' current charter
> (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a
section(s)
> of the charter is preferable.

It might fit to number 4 and the rest of the explanation. Why we think it
can fit? It is because IPv6 addresses are public and at least at the moment
our computer connect to internet using its own unique IP address. I guess
this will open new issues for privacy and security. The reason is the
initial attack on node's security and privacy is to recon the node. So, when
your node has a fix IID, then the attacker has better possibility to attack
this node. 
Now the purpose of this draft is only to give information to the
implementers that they can improve the privacy and security of their
mechanisms. It also provide a way for privacy-aware-applications to use a
same framework which can also control the total number of IID and not
generate the IID themselves. 
This means they do not need to have any information about IP layer while at
the same time they can ensure their users that their application is
privacy-aware

> 3) Who is this draft's audience?

Privacy-aware implementers

> 4) Have any operators expressed interest in this draft or its problem
space,
> either via review or other discussion?

I guess I have already answered this 

> 5) Is this draft pursuing discussion in any other WGs? If so, please list
them
> here, along with rationale for the interaction with multiple WGs in
parallel.

Please check the recordings of ra-privacy (lifetime section) and the mailing
list discussion about ra-privacy after IETF 87


> 6) Is any protocol work being recommended in the draft?

It is actually in informational track that gives the choice for
implementers. I am also in the process of implementing it for Linux. 

Thank you again,
-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey