[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 15:30:51 -03 2020

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20201215/ae1df95c/attachment.htm>