Talk:DHCPv6

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing: Networking

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by Networking task force.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

Neighbor Discovery Protocol[edit]

A bit of what appears to be conflict between editors in the final paragraph of the lead. How do we iron this out? Should other undiscoverable properties be mentioned? Are there limitations to Neighbor Discovery Protocol that need to be mentioned? --Kvng (talk) 16:19, 13 September 2010 (UTC)[reply]

There is no conflict. Just two ways to accomplish the same goal. Kbrose (talk) 19:46, 13 September 2010 (UTC)[reply]

DUID Length[edit]

This article states that a DUID has a minimum length of 12 bytes (96 bits) and a maximum length of 20 bytes (160 bits) However the relevant RFC 3315 at http://tools.ietf.org/html/rfc3315#section-9.1 states

  A DUID consists of a two-octet type code represented in network byte
  order, followed by a variable number of octets that make up the
  actual identifier.  A DUID can be no more than 128 octets long (not
  including the type code).

Any comments before I change it? --B timmins (talk) 09:30, 15 October 2014 (UTC)[reply]

Address pool assignment randomizing?[edit]

Due to the fact that IPv6 allows every device to be assigned a single address that follows it forever, IPv6 has the potential to also be an excellent tool for life-long surveillance and monitoring by marketing, analytics, and Three Letter Agencies.

NAT for the most part has basically prevented this sort of remote tracking up until now, due to mushing all internal address connections into a few single external addresses which constantly recycle the same port ranges for outgoing connections, making external tracking of devices behind NAT virtually impossible.

(Personally I believe NAT should continue to be implemented in IPv6, even if only for its internal address obfuscation, and automatic firewall-less protection of internal devices from externally directed attack connections. NAT is an excellent tool for protecting free speech and permitting device usage privacy.)

So then, is anyone exploring the use of IPv6 DHCP address pool randomizing, with short lease times, to make remote device tracking and passive profiling much more difficult?

-- DMahalko (talk) 15:03, 13 May 2015 (UTC)[reply]

There is RFC 4941 to address this issue for SLAAC. For DHCPv6 address rotation can be implemented by server, as I can see protocol doesn't prevent this. Citrin.ru (talk) 02:28, 11 January 2017 (UTC)[reply]