[lacnog] Renumeración en IPv6 (Fwd: Document Action: 'Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events' to Informational RFC (draft-ietf-v6ops-slaac-renum-05.txt))

Mar Dic 15 17:54:10 -03 2020

Hola Roque,

No exactamente... pues ese documento por lo que veo también trata el
lado del CPE... Yo me refiero del lado de los clientes (los
dispositivos y no el router doméstico).
Es decir, que simplemente los clientes al recibir un nuevo prefijo
IPv6, descarten los anteriores.

Saludos,
Nico

El mar, 15 de dic. de 2020 a la(s) 15:31, Roque Gagliano
(rgaglian en gmail.com) escribió:
>
> Hola Nico,
>
> Me parece que lo que tu comentas está especificado en este otro documento de Fernando dando recomendaciones a los fabricantes de CPEs/Operadores y donde los autores pasan tiempo explicando la relación de timers entre el WAN-side y el LAN-side:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-06
>
> Roque
>
>
>
> On Tue, Dec 15, 2020 at 5:04 PM Nicolas Antoniello <nantoniello en gmail.com> wrote:
>>
>> Hola Fernando,
>>
>> Tengo algunas consultas para vos al respecto... a ver si puedes
>> arrojar un poco más de luz sobre este tema pues justamente en mi caso,
>> el hecho de que mi proveedor de acceso a Internet mantiene la política
>> de rotar los prefijos IPv4 e IPv6 asignados cada 12 horas, hace que
>> los dispositivos de mi red doméstica mantengan una lista bastante
>> larga y nociva de direcciones IPv6... que terminó por obligarme a
>> deshabilitar IPv6 (sip, así de dura es la realidad, jejeje).
>>
>> Incluso supongamos un escenario un poco más simple que es que el
>> router doméstico palme (término utilizado en Uruguay para indicar que
>> deja de funcionar repentinamente)... cuando reinicia, es muy probable
>> que sea imposible que conozca cuáles eran los prefijos anteriores para
>> transmitirlos con un TTL 0 o algo similar... por lo que los
>> dispositivos (en especial todos esos pequeños dispositivos IoT) siguen
>> aumentando su lista de prefijos IPv6 válidos y que no rutean a ningún
>> lado.
>> Entonces, no sería bueno modificar el comportamiento estándar por
>> defecto del cliente para que cuando reciba un prefijo IPv6 nuevo,
>> automáticamente elimine todos los anteriores? esto podría ser
>> modificado por configuración del usuario... pero yo hablo de que por
>> defecto asi sea.
>>
>> Abrazo,
>> Nico
>>
>>
>> El lun, 14 de dic. de 2020 a la(s) 19:31, Fernando Gont
>> (fgont en si6networks.com) escribió:
>> >
>> > Estimades,
>> >
>> > La IESG aprobó nuestro IETF I-D draft-ietf-v6ops-slaac-renum
>> > (https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum) sobre los
>> > problemas operacionales que existen en casos en los que se renumeran
>> > redes IPv6 -- como por ejemplo el que sucede muchas veces con los
>> > usuarios hogareños.
>> >
>> > Para quienes estén desplegando IPv6, o vayan a hacerlo, es un tema
>> > importante a tener en cuenta.
>> >
>> > Slds,
>> > Fernando Gont
>> > SI6 Networks
>> >
>> >
>> >
>> >
>> > -------- Forwarded Message --------
>> > Subject: Document Action: 'Reaction of Stateless Address
>> > Autoconfiguration (SLAAC) to Flash- Renumbering Events' to Informational
>> > RFC (draft-ietf-v6ops-slaac-renum-05.txt)
>> > Resent-Date: Tue,  8 Dec 2020 12:51:15 -0800 (PST)
>> > Resent-From: alias-bounces en ietf.org
>> > Resent-To: fgont en si6networks.com, jan en connect.com, richard.patterson en sky.uk
>> > Date: Tue, 08 Dec 2020 12:51:14 -0800
>> > From: The IESG <iesg-secretary en ietf.org>
>> > To: IETF-Announce <ietf-announce en ietf.org>
>> > CC: The IESG <iesg en ietf.org>, draft-ietf-v6ops-slaac-renum en ietf.org,
>> > v6ops-chairs en ietf.org, owen en delong.com, warren en kumari.net,
>> > rfc-editor en rfc-editor.org, Owen DeLong <owen en delong.com>, v6ops en ietf.org
>> >
>> > The IESG has approved the following document:
>> > - 'Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-
>> >     Renumbering Events'
>> >    (draft-ietf-v6ops-slaac-renum-05.txt) as Informational RFC
>> >
>> > This document is the product of the IPv6 Operations Working Group.
>> >
>> > The IESG contact persons are Warren Kumari and Robert Wilton.
>> >
>> > A URL of this Internet Draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/
>> >
>> >
>> >
>> >
>> >
>> > Technical Summary
>> >
>> > This is a companion document to
>> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/.
>> > This document provides advice for the operator side of the process
>> > whereas the other document
>> > provides advice for the client or CPE side of the process. Together,
>> > both documents attempt to
>> > improve the user experience when unplanned SLAAC renumbering events occur.
>> >
>> >
>> > Working Group Summary
>> >
>> > The document does not specify new protocol, but rather provides guidance
>> > regarding how
>> > to override the default values of some parameters in the existing protocols.
>> > The document (along side its companion document
>> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/
>> > has received substantial comments from the working group.
>> >
>> > Document Quality
>> >
>> >     The document(s) are clear, easy to read, and explain the issues and
>> > procedures.
>> > Personnel
>> >
>> >     Owen DeLong is the Document Shepherd
>> >    Fred Baker and Ron Bonica are the WG chairs
>> >     Warren Kumari is RAD!
>> >
>> >
>> > _______________________________________________
>> > LACNOG mailing list
>> > LACNOG en lacnic.net
>> > https://mail.lacnic.net/mailman/listinfo/lacnog
>> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> --
>
>
> At least I did something
> Don Draper - Mad Men
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog