<!DOCTYPE html>
<html><head>
    <meta charset="UTF-8">
</head><body><p>Estimados, this email is just to let you all know that PowerDNS is now part of Open-Xchange. We are planning on several improvements and different services in the near future. </p><p>Let us know what your thoughts are about PowerDNS and whether there is anything we can do to help if you are a current customer / User.</p><p>Thanks.</p><blockquote type="cite"><p>On February 16, 2016 at 7:19 AM Fernando Gont <fgont@si6networks.com> wrote:<br><br><br>("Tema" corregido)<br><br>On 02/16/2016 06:53 AM, Fernando Gont wrote:</p><blockquote type="cite"><p>Estimados,<br><br>FYI: <https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-02><br><br>---- cut here ----<br><br>4.3. Allocation strategies<br><br> A DHCPv6 server running in typical, stateful mode is given a task of<br> managing one or more pools of IPv6 resources (currently non-temporary<br> addresses, temporary addresses and/or prefixes, but more resource<br> types may be defined in the future). When a client requests a<br> resource, server must pick a resource out of configured pool.<br> Depending on the server's implementation, various allocation<br> strategies are possible. Choices in this regard may have privacy<br> implications.<br><br> Iterative allocation - a server may choose to allocate addresses one<br> by one. That strategy has the benefit of being very fast, thus can<br> be favored in deployments that prefer performance. However, it makes<br> the resources very predictable. Also, since the resources allocated<br> tend to be clustered at the beginning of available pool, it makes<br> scanning attacks much easier.<br><br> Identifier-based allocation - some server implementations use a fixed<br> identifier for a specific client, seemingly taken from the client's<br> MAC address when available or some lower bits of client's source IPv6<br> address. This has a property of being convenient for converting IP<br> address to/from other identifiers, especially if the identifier is or<br> contains MAC address. It is also convenient, as returning client is<br> very likely to get the same address, even if the server does not<br> retain previous client's address. Those properties are convenient<br> for system administrators, so DHCPv6 server implementors are<br><br><br><br>Krishnan, et al. Expires June 29, 2016 [Page 9]<br><br><br>Internet-Draft DHCPv6 Privacy considerations December 2015<br><br><br> sometimes requested to implement it. There is at least one<br> implementation that supports it. The downside of such allocation is<br> that the client now discloses its identifier in its IPv6 address to<br> all services it connects to. That means that correlation of<br> activities over time, location tracking, address scanning and OS/<br> vendor discovery apply.<br><br>---- cut here ----<br><br>P.S.: En fin:<br><https://tools.ietf.org/html/draft-gont-predictable-protocol-ids-00>...</p></blockquote><p><br>-- <br>Fernando Gont<br>SI6 Networks<br>e-mail: fgont@si6networks.com<br>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br><br><br><br><br>_______________________________________________<br>Seguridad mailing list<br>Seguridad@lacnic.net<br>https://mail.lacnic.net/mailman/listinfo/seguridad</p></blockquote><p><br></p><div class="io-ox-signature"><p>Ronaldo Venci<br>VP of Sales – The Americas<br>Open-Xchange Inc.<br>Mobile: +1 (678) 237-5528<br>Office: +1 (408) 500-0768 x8821<br>Email: ronaldo.venci@open-xchange.com</p></div></body></html>