<div dir="ltr"><div>Nico,</div><div><br></div><div>El cliente responde a los atributos que el CPE envia via SLAAC, entonces la reacción del endpoint está implícita. Si el CPE sigue las recomendaciones del document, los dispositivos deberían reaccionar como tú lo buscas.</div><div><br></div><div>Roque</div><div><br></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 9:54 PM Nicolas Antoniello <<a href="mailto:nantoniello@gmail.com" target="_blank">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 Roque,<br>
<br>
No exactamente... pues ese documento por lo que veo también trata el<br>
lado del CPE... Yo me refiero del lado de los clientes (los<br>
dispositivos y no el router doméstico).<br>
Es decir, que simplemente los clientes al recibir un nuevo prefijo<br>
IPv6, descarten los anteriores.<br>
<br>
Saludos,<br>
Nico<br>
<br>
El mar, 15 de dic. de 2020 a la(s) 15:31, Roque Gagliano<br>
(<a href="mailto:rgaglian@gmail.com" target="_blank">rgaglian@gmail.com</a>) escribió:<br>
><br>
> Hola Nico,<br>
><br>
> 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:<br>
><br>
> <a href="https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-06" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-06</a><br>
><br>
> Roque<br>
><br>
><br>
><br>
> On Tue, Dec 15, 2020 at 5:04 PM Nicolas Antoniello <<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
><br>
> --<br>
><br>
><br>
> At least I did something<br>
> Don Draper - Mad Men<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"><br><br>At least I did something<br>Don Draper - Mad Men</div>