I-D Action: draft-rafiee-6man-ra-privacy-05.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Router Advertisement based privacy extension in IPv6 autoconfiguration
	Author(s)       : Hosnieh Rafiee
                          Christoph Meinel
	Filename        : draft-rafiee-6man-ra-privacy-05.txt
	Pages           : 10
	Date            : 2013-08-08

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.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rafiee-6man-ra-privacy

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-rafiee-6man-ra-privacy-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux