[LACNIC/Seguridad] Fwd: Protocol Action: 'Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6' to Proposed Standard (draft-ietf-6man-rfc4941bis-12.txt)

[Nicolas Antoniello]

Hola Guillermo,

Supongo que eso no sucede pues el ISP es quien asigna la parte
“determinada” del prefijo y eso no cambiaría.
Al igual que en IPv4, el ISP aún puede saber quien es el cliente (pero, al
igual que en IPv4) no puede saber de cual de todos los dispositivos del
cliente se trata. Bueno, eso es lo que interpreto de la letra del estándar.

Saludos,
Nico




El El mar, dic. 22, 2020 a la(s) 11:32, Guillermo Pagliero <
paglierog en hotmail.com> escribió:

> buenos días, ante todo disculpen mi ignorancia, pero no me queda claro
> algo con respecto a este tema, como operador ISP, la escasez de IPv4 nos
> obliga a hacer NAT y con ello a perder cierta información, por ejemplo,
> cuando nos pidén judicialmente quien tuvo en un determinado momento una
> dirección IP en particular, con esta nueva configuración de direcciones
> IPv6 no nos estaría pasando lo mismo??
>
> saludos
> ------------------------------
> *De:* Seguridad <seguridad-bounces en lacnic.net> en nombre de Fernando Gont
> <fgont en si6networks.com>
> *Enviado:* lunes, 14 de diciembre de 2020 15:43
> *Para:* Lista para discusión de seguridad en redes y sistemas
> informaticos de la región <seguridad en lacnic.net>; lactf en lac.ipv6tf.org <
> lactf en lac.ipv6tf.org>
> *Asunto:* [LACNIC/Seguridad] Fwd: Protocol Action: 'Temporary Address
> Extensions for Stateless Address Autoconfiguration in IPv6' to Proposed
> Standard (draft-ietf-6man-rfc4941bis-12.txt)
>
> FYI.
>
> La IESG finalmente aprobó nuestro IETF Internet-Draft
> draft-ietf-6man-rfc4941bis
> (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) -- una revisión
> de la especificación de "Direcciones IPv6 Temporales" (RFC4941).
>
> Fueron cuatro años de trabajo en este documento....
>
> También hice la implementación de Linux de este documento hace algunos
> meses:
>
> https://patchwork.ozlabs.org/project/netdev/patch/20200501035147.GA1587@archlinux-current.localdomain/
>
> Y una para FreeBSD que por algun motivo todavía no se comiteó.
>
> Slds,
>
> Cheers,
> Fernando
>
>
> -------- Forwarded Message --------
> Subject: Protocol Action: 'Temporary Address Extensions for Stateless
> Address Autoconfiguration in IPv6' to Proposed Standard
> (draft-ietf-6man-rfc4941bis-12.txt)
> Resent-Date: Mon, 14 Dec 2020 07:39:13 -0800 (PST)
> Resent-From: alias-bounces en ietf.org
> Resent-To: fgont en si6networks.com, suresh en kaloom.com, narten en cs.duke.edu,
> richdr en microsoft.com
> Date: Mon, 14 Dec 2020 07:39:13 -0800
> From: The IESG <iesg-secretary en ietf.org>
> To: IETF-Announce <ietf-announce en ietf.org>
> CC: ek.ietf en gmail.com, rfc-editor en rfc-editor.org, otroan en employees.org,
> draft-ietf-6man-rfc4941bis en ietf.org, The IESG <iesg en ietf.org>,
> ipv6 en ietf.org, 6man-chairs en ietf.org
>
> The IESG has approved the following document:
> - 'Temporary Address Extensions for Stateless Address Autoconfiguration
>     in IPv6'
>    (draft-ietf-6man-rfc4941bis-12.txt) as Proposed Standard
>
> This document is the product of the IPv6 Maintenance Working Group.
>
> The IESG contact persons are Erik Kline and Éric Vyncke.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/
>
>
>
>
>
> Technical Summary
>
>     This document describes an extension that causes nodes to generate
>     global scope addresses with randomized interface identifiers that
>     change over time.  Changing global scope addresses over time limits
>     the window of time during which eavesdroppers and other information
>     collectors may trivially perform address-based network activity
>     correlation when the same address is employed for multiple
>     transactions by the same node.  Additionally, it reduces the window
>     of exposure of a node via an addresses that becomes revealed as a
>     result of active communication.  This document obsoletes RFC4941.
>
> Working Group Summary
>
>     This document is an update of RFC4941. The document
>     shepherd has reviewed every change to the document as it
>     has processed as well as a thorough read through of the
>     whole final document.
>
> Document Quality
>
>     There are multiple implementations of the mechanism described.
>
> Personnel
>
>     Ole Trøan is the document shepherd.
>     Erik Kline is the responsible AD.
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20201222/f9b74462/attachment-0001.htm>