[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 18:48:07 -03 2020

Ok, pero el hecho es que los CPE no siempre siguen esas recomendaciones...
entonces bien podrían los clientes tomar la iniciativa, no?

Ese es justamente el problema, que los CPE no necesariamente siguen las
mejores prácticas o todos los estándares. :)

Nico

El El mar, dic. 15, 2020 a la(s) 18:41, Roque Gagliano <rgaglian en gmail.com>
escribió:

> Nico,
>
> 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.
>
> Roque
>
>
>
>
> On Tue, Dec 15, 2020 at 9:54 PM Nicolas Antoniello <nantoniello en gmail.com>
> wrote:
>
>> 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
>> _______________________________________________
>> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20201215/562f55bf/attachment.htm>