Edge Rewrite
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a25ffdc868a7b071

Jump to content

Talk:DHCPv6

Page contents not supported in other languages.
Add topic
From Wikipedia, the free encyclopedia
Latest comment: 9 years ago by Citrin.ru in topic Address pool assignment randomizing?

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