[LAC-TF] [Lista ArNOG] [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))

[Fernando Gont]

Hola, Nico,

Entre lineas....

On 15/12/20 13:04, Nicolas Antoniello 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).

No me sorprende. De hecho, los datos de una encuesta hecha sobre el tema 
indico que al menos un 30% de los proveedores utilizan prefijos 
dinamicos, así como vos lo comentás.




> 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.

Exacto. En principio hay solo dos formas en la cuales tu router hogareño 
podrñia saber eso:

1) Que guarde los prefijos delegados en almacenamiento estable (junto a 
un timestamp), y entonces al reiniciarse pueda "aprender" cual es el 
prefijo anteriormente utilizado.

2) QUe al renumerar, tu ISP le pase por DHCPv6-PD, dos prefijos: el 
prefijo nuevo con un lifetime != 0, y el prefijo viejo con un lifetime de 0.

Lamentablemente, ninguna de las dos cosas suceden en la practica, por lo 
cual los dispositivos no se enteran.


Y hay una cuestión más: así y todo el router anunciara el prefijo viejo 
con un lifetime de 0, la especificacion actual de Neighbor Discovery 
(RFC4861) impide que los host reduzcan el lifetime de los prefijos a 
menos de dos horas -- lo cual es una tontera, tambien. Esta es otra 
modificación que nuestro documento 
https://tools.ietf.org/html/draft-ietf-6man-slaac-renum hace/propone. 
Dicho documento se está trabajando en 6man, ya que contiene 
modificaciones al protocolo en si.


> 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.

Tenés completa razón, y de hecho es lo que nosotros propusimos en 6man 
en la sección 4.5 de este documento: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#page-11   (el 
mencionado mas arriba)


La cuestión ha sido demasiado trabajosa. Empezando porque uno de los 
co-chairs del grupo se negó durante meses a llamar a consenso para la 
adopción del documento ("porque a el no le gustaba el documento"). Luego 
de dicha adopción, la hostigación continuó pidiendonos a los autores 
que, al adoptar el documento, eliminemos todo el texto (dejando solo los 
titulos), y que fueramos agregando contenido a medida que continuara la 
discusión. (ver todos los "TBD" en 
https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-00 ).

Asi y todo, y pesé a la oposición y trabas, estamos intentando hacer 
progreso. Claro que sin la participación de la gente, todo se vuelve mas 
dificil.


En torno a esta cuestión, se me ocurre mencionar algunos temas 
miscelaneos, realacionados:

1) El hecho que hayas deshabilitado IPv6 es perfectamente entendible. La 
realidad es que uno usa Internet con el fin de realizar determinadas 
actividades (trabajo, ocio, o lo que fuera), y *no* con el objetivo de 
utilizar un protocolo en particular. Cuando se encuentran problemas sin 
soluciones obvias y directas, es logico que la solucion sea eliminar 
aquello que trae problemas y, al final del dia, no afecta la actividad 
que uno quiere realizar.

En ocasiones, algunos individuos y organizaciones que promocionan IPv6 
tienen algun tipo de prurito cuando uno habla o discute problemas en 
IPv6, como si eso fuera algo malo. Y mi argumento es justamente que 
quienes trabajamos en el area de Ingenieria de Internet, debemos tener 
el objetivo y responsabilidad de encontrar problemas, y hacer que las 
cosas funcionen mejor -- y *no* de dedicarnos al marketing queriendo 
inventar virtudes, y ocultando problemas.

Cuando uno se focaliza en el marketing, en vez de hacer ingeniería, 
tristemente suceden cosas como las que describís: eventualmente los 
problemas aparecen, quien utiliza el protocolo encuentra la manera mas 
pragmatica de solucionar sus problemas, con las opciones que tiene sobre 
la mesa (que usualmente es la de "deshabilitarlo").


2) La breve descripción del manejo de nuestro documento por parte de uno 
de los chairs de 6man -- y en definitiva, por los dos chairs, y por el 
propio director de area, tal vez sirva como datapoint de porqué siempre 
discuto con todos aquellos que venden una historia de fantasia sobre 
IETF, como si fuera la misma organizacion a la que 20 años atras 
concurrian hippies idealistas en sandalias.  Padecer manejos 
discrecionales y arbitrarios, y luego que en tu propia region te hablen 
maravillas sobre el propio sistema que en ocasiones padecés no es la 
cosa mas agradable.

3) Alguna de las cosas que proponemos en nuestro documento ya las he 
implementado en algunos sistemas operativos, como por ejemplo el kernel 
del Linux. No solo menciono esto como datapoint de que hay trabajo 
activo en este area, sino para resaltar que no solo es bueno que los 
estandares sean abiertos, sino que tambien es bueno y necesario que los 
sitemas operativos sean libres y de codigo abierto, ya que permite a la 
gente (en este caso, yo), trabajar en el codigo para solucionar 
problemas.  Esto lo menciono porque muchas veces se hace mucho lobby 
respecto de los estandares abiertos, pasando diapositivas con "Keynote" 
-- lo cual ignora que las especificaciones abiertas cobran sentido 
cuando alguien las implementa. Y los sistemas libres y de codigo abierto 
posibilitan que mucha gente pueda contribuir. Algo que complementa a los 
estandares abiertos, y tiene igual o mayor importancia.

4) Por si lo de arriba no fuera suficiente, te cuento que algunas 
personas (incluyendo el propio co-chair que nos ha hecho la vida 
imposible para solucionar este problema con modificaciones al protocolo) 
tambiñen se han opuesto a la publicación de el documento del Subject, 
argumentando que discute un problema inexistente.


Esto lo menciono porque a veces uno simplemente ve un documento, y 
esperaria que su publicacion hubiera sido sencilla (por discutir un 
problema real, concreto, etc.) -- pero muchisimas veces (como en este 
caso), la cuestión dista de ello.


Como una nota mas de lo de arriba: Mi ISP renumera "cada tanto" (todavia 
no pude identificar de qué depende la renumeracion). En mi caso, tengo 
el CPE del proveedor en modo puente, y utilizo un Mikrotik como router 
hogareño, lo cual me permite reducir artificialmente el lifetime 
anunciado para los prefijos. De no disponer de ello, yo también hubiera 
terminado deshabilitando IPv6.

Abrazo,
Fer




-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492