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

"Hosnieh Rafiee" <> Fri, 25 October 2013 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6659F21F9FF9 for <>; Fri, 25 Oct 2013 15:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A-HwRae5v3QA for <>; Fri, 25 Oct 2013 15:55:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8F7B521F8411 for <>; Fri, 25 Oct 2013 15:55:32 -0700 (PDT)
Received: from kopoli ( []) by (node=mrus1) with ESMTP (Nemesis) id 0M6BzW-1VssCn3Dys-00yThG; Fri, 25 Oct 2013 18:55:14 -0400
From: "Hosnieh Rafiee" <>
To: <>
References: <>
In-Reply-To: <>
Date: Sat, 26 Oct 2013 00:55:04 +0200
Message-ID: <008901ced1d5$434e5790$c9eb06b0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGR/c6oFX+mvk/6gDLEuSjOLB4jLpp/ouWQ
Content-Language: en-us
X-Provags-ID: V02:K0:QRjc/Rjev/SiGgIV02hL0PJoE8b9UjFD9GGt3sOeXZ+ 9PMxc8jNBp6PNUD0Z6dHyIheCoLMFjwGy0QU2ZGfSNCH/8f8xO sUaTm1vXYrc1+Pl/CT6JnlVS+0kFslgbnb44d3UUHSKVbCWKkh L9q2aP0BXtXGwjczmIXTnJ66/CG3Q1LBCYQgd2X1DjENjPyG9l QPom5zn0Gx3UVrjqNSnVuEvPgfIa6ul7qrsO0pwcTvbuK9M9p0 vo0x6K5LSpyaUHPCYvxpzylHSvnE+r66ySjOhwHrIhDXuikLA1 9nnkSyX+YhRckSiDVifwZCGJT8KJVTCicMYfxdZhl/xo0d4zXn p/mxXQqCK73HNOq3SKcU=
Cc:,, Erik Nordmark <>
Subject: Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Oct 2013 22:55:45 -0000

Hi Fred,

Actually the content of this draft
( )  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;  (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
> ( Citing specific a
> 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

> 3) Who is this draft's audience?

Privacy-aware implementers

> 4) Have any operators expressed interest in this draft or its problem
> 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
> here, along with rationale for the interaction with multiple WGs in

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,
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey