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

["Fred Baker (fred)" <[e-mail]>]

Thanks.

Question for you. What is the interaction with draft-gont-6man-deprecate-eui64-based-addresses? In conversation with him there, you asked if he would be folding your draft into his and therefore making yours redundant. Does he plan to? If he does, it may be appropriate for you to become a co-author on that paper.

My sense, which could be completely incorrect, is that the exact value of the IID isn't all that interesting to most operators, as once it is in use nobody really cares how it was chosen. Duplicate IIDs in use would be a problem, so DAD is important. The means by which it is assigned is interesting (some operators require SLAAC, some use DHCPv6 but permit SLAAC, some require DHCPv6, and some assign IIDs to their servers or to routers for BGP purposes). Duplicate IIDs in use would be a problem, so DAD is important operationally if SLAAC is in use, and in DSL and Cable networks the behavior of DAD in their transmission systems is "interesting". The number of addresses that are in actual use at a given time (and therefore neighbor slots that are in use) is operationally interesting in that it affects and is affected by table capacity, and can therefore be an attack vector. The bits in the IID and the mechanism by which they are generated is, however, very important to 6man, which defines SLAAC. From that perspective, the paper may be of interest in 6man.

I'm looking, as always, for operational feedback on the list. But that's my initial thought.

On Oct 26, 2013, at 12:55 AM, Hosnieh Rafiee <[e-mail]>
 wrote:

> 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
> 
>