I-D: Router Advertisement Based Privacy - draft-rafiee-6man-ra-privacy

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

I have improved the document and also clearly explained the problems that this document addresses in the Introduction section. I also improved the algorithm for IID lifetime, which is now a conditional application based lifetime.

 <http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04> http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04 

 

 

Abstract:

   Privacy is an important issue which concerns many governments and

   users, with its importance becoming more evident every day. Nodes

   change their IP addresses frequently in order to avoid being tracked

   by attackers. The act of frequently changing IP addresses also helps

   to prevent the leakage of information by nodes. In IPv6 networks

   there is currently one solution for maintaining the privacy of nodes

   when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is

   used. Unfortunately there are some problems associated with this

   solution which entails the use of the Privacy Extension (RFC 4941).

   One of the issues with this RFC concerns the wording that is used

   which allows the implementation to make the choice as to what

   approach to use and in so doing, in some cases, the choice made is

   not the most prudent or best approach and this is not ideal and can

   cause some problems. Some of these problems are concerned with not

   generating a new Interface ID (IID) after changing the router prefix.

   Another concern would be the fact that nodes may use an IID that was

   generated based on a MAC address as a public address, and then use

   this in their response. The act of cutting the current connections to

   other nodes, if the max lifetime of the old IID has elapsed, is also

   not clearly explained nor is whether or not the already used IID

   should be kept in stable storage, There is also a concern about the

   need to have stable storage available for the generation of a

   randomized IID. The RFC gives no explanation as to how to make use of

   CGA in its randomizing solution when stable storage is not available

   or how to use the same approach for random value generation in all

   implementations where there is a lack of stable storage. The purpose

   of this document is to address these issues, to update the current

   RFC and to introduce a new algorithm for the lifetime of IID.

 

Please take a look and share your comments.

Thanks,

Regards,

Hosnieh