[lacnog] Fwd: [IPv6]I-D Action: draft-ietf-6man-slaac-renum-14.txt

[Henri Alves de Godoy]

Boa tarde Fernando Gont e demais.  Consegui agora dar uma lida.

Entendi que a proposta esta relacionada aos hosts clientes,  e nao aos
roteadores/radvd, pois essa opção já existe.

Nos hosts Windows por exemplo o tempo mínimo é de 2 horas.

Então a proposta é baixar esse tempo para menos de 2 horas.

Entendi que nao tem relação alguma em resolver problemas de múltiplos links.

Por curiosidade, busquei nos registros de logs nos hosts windows dos
laboratórios de informatica rede cabeada ( 320 hosts), qual a frequência de
alteração dos endereços temporários.  O ritmo médio padrão da maioria das
máquinas IPv6 temporário foi de 2 vezes por dia (entre 1,6 e 2,7
renovações/dia).   Para esse tipo de ambiente que tenho me parece razoável
e facilita a auditoria, por exemplo.

Creio que tempos menores de 2 horas, haverá um desafio maior de manter os
registros de endereços ipv6 temporário que temos que guardar (apesar de
serem sem estado) mas temos que guardar e correlacionar com IPv4, o que
confesso que esta sendo bem complicado e difícil de gerenciar.

Minha dificuldade atual:  incidentes de segurança chegam com IPv4 público,
mas o host é de pilha dupla.  O Active Directory Windows Server só registra
o conexão inicial padrão que é IPv6,  e não IPv4.   A correlação entre
endereços de hosts em pilha dupla é um desafio bem complicado.

Abraços !
Henri







Em dom., 5 de jul. de 2026 às 11:19, Fernando Gont <fernando en gont.com.ar>
escreveu:

> FYI: https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum-14
>
>
>
> -------- Forwarded Message --------
> Subject: [IPv6]I-D Action: draft-ietf-6man-slaac-renum-14.txt
> Date: Sun, 05 Jul 2026 06:08:14 -0700
> From: internet-drafts en ietf.org
> Reply-To: ipv6 en ietf.org
> To: i-d-announce en ietf.org
> CC: ipv6 en ietf.org
>
> Internet-Draft draft-ietf-6man-slaac-renum-14.txt is now available. It is a
> work item of the IPv6 Maintenance (6MAN) WG of the IETF.
>
>     Title:   Improving the Robustness of Stateless Address
> Autoconfiguration (SLAAC) to Flash Renumbering Events
>     Authors: Fernando Gont
>              Jan Zorz
>              Richard Patterson
>     Name:    draft-ietf-6man-slaac-renum-14.txt
>     Pages:   28
>     Dates:   2026-07-05
>
> Abstract:
>
>     In scenarios where network configuration information becomes invalid
>     without explicit notification to the local network, local hosts may
>     end up employing stale information for an unacceptably long period of
>     time, thus resulting in interoperability problems.  This document
>     improves the reaction of IPv6 Stateless Address Autoconfiguration to
>     such configuration changes.  It formally updates RFC 4191, RFC 4861,
>     RFC 4862, RFC 8106, RFC 8781, RFC 9096, and RFC 9463.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum-14
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-slaac-renum-14
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 en ietf.org
> List Info: https://mailman3.ietf.org/mailman3/lists/ipv6@ietf.org/
> --------------------------------------------------------------------
>
> --
> Fernando Gont
> e-mail: fernando en gont.com.ar
> PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
> _______________________________________________
> 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/20260729/bd7c8c3a/attachment.htm>