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