<div dir="auto">Hola, Roque,<div dir="auto"><br></div><div dir="auto">Ciertamente esa es la conclusión final.</div><div dir="auto"><br></div><div dir="auto">Pero la otra parte es q a ipv6 se le han hecho numerosos updates, muchos de los cuales se los puede considerar "de último momento".</div><div dir="auto"><br></div><div dir="auto">La realidad es q tanto en materia de seguridad como en materia operacional, el protocolo empezó a recibir atención "en serio" básicamente en los últimos diez años (o incluso menos).</div><div dir="auto"><br></div><div dir="auto">Creer q es maduro no o estable solo ayuda a frenar posibles mejoras -- lo cual, obviamente, no es una "ayuda", sino todo lo contrario.</div><div dir="auto"><br></div><div dir="auto">Fernando</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">El 20 jul. 2017 5:53 p. m., "Roque Gagliano" <<a href="mailto:rgaglian@gmail.com">rgaglian@gmail.com</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Fernando, <div dir="auto"><br></div><div dir="auto">Resumo tu análisis: "es lo que hay."</div><div dir="auto"><br></div><div dir="auto">Justo?</div><div dir="auto">Roque</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jul 20, 2017 8:54 AM, "Fernando Gont" <<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Estimados,<br>
<br>
En conversaciones recientes, se ha hablado sobre la "madurez" de IPv6, y<br>
se ha aseverado que la publicación de RFC8200 es basicamente una<br>
cuestión administrativa con el fin de enviar un mensaje a la comunidad.<br>
<br>
En tal sentido, permitaseme proveer un análisis alternativo (o "un<br>
analisis", a secas :-) ).<br>
<br>
<br>
* Por qué mover IPv6 a "Internet Standard" (STD)?<br>
<br>
La decisión fue, a mi criterio, meramente politica, con el fin de enviar<br>
una señal a la comunidad (no sé epecificamente cual :-) ) de que IPv6<br>
está completo, es estable, y maduro. Esta decisión condicionó el trabajo<br>
del grupo ya que, entre otras cosas, para poder move RFC2460 a estandar,<br>
uno debia limitarse en el tipo de cambios que eran posibles realizar<br>
(mas alla que ls cambios han sido numerosos, en casi la totalidad de los<br>
aspectos del protocolo en cuestión).<br>
<br>
Parte de esto ha llevado a que el documento final (RFC8200) no utilice<br>
(siquiera) terminos del RFC2119 ("MUST", "SHOULD", etc.), por lo cual no<br>
es trivial identificar que parte de la especificacion es un<br>
requerimiento formal, y que parte es "simple prosa" (sin ser un<br>
requerimiento).<br>
<br>
Por otro lado, para poder promover RFC2460 a STD, no se pudo incorporar<br>
neuvo requerimientos. Motivo por el cual, por ejemplo, RFC8200 no tiene<br>
requerimiento alguno respecto de las caracteristicas de los Fragment<br>
Identifiers (pese a la publicación de RFC7739, y a lo discutido en<br>
<<a href="https://tools.ietf.org/html/draft-gont-predictable-numeric-ids" rel="noreferrer" target="_blank">https://tools.ietf.org/html/d<wbr>raft-gont-predictable-numeric-<wbr>ids</a>>). Lo<br>
cual deja la puerta abierta a que implementaciones IPv6 continuen con la<br>
historia de elegir identificadores inapropiados.<br>
<br>
Yo soy de la idea que uno debe intentar hacer un buen trabajo técnico, y<br>
que dicho trabajo sea el que "envíe señales a la comunidad", mas que<br>
focalizarse en la señal que se quiere enviar, condicionando el trabajo<br>
técnico.<br>
<br>
<br>
<br>
* Que cambios se han realizado a IPv6 recientemente?<br>
<br>
 + Eliminar el Routing Header Type 0<br>
<br>
 Esto fue hecho por el RFC5095, en respuesta a una presentacion hecha en<br>
 CanSecWest en el año 2006.<br>
<br>
 + Numerosos cambios en materia de fragmentacion<br>
<br>
  El mecanismo de fragmentación estaba sub-expecificado. Por tal motivo<br>
  RFC5722 fue un parche para prohibir el uso de fragmentos solapados,<br>
  mientras que RFC7112 prohibió el uso de fragmentación en los cuales<br>
  el primer fragmento no contiene todos os encabezados ("hasta el del<br>
  protocolo e transporte incluido", por así decirlo).<br>
<br>
  Por otro lado, RFC2460 soportaba el uso de "IPv6 atomic fragments",<br>
  que generaba tanto problemas de interoperabilidad como de seguridad.<br>
  RFC6946 parcheo el procesamiento de fragmentos atomicos. Sin embargo,<br>
  la *generacion* de los mismos fue "silenciosamente" eiminada de<br>
  RFC8200, producto de la publicación de RFC8021 (que debería haber<br>
  actualizado formalmente al RFC2460, pero por motivo de las "señales"<br>
  que el grupo quería enviar, decidio publicarse como "Informational").<br>
<br>
 + Especificacion del Flow Label<br>
<br>
  Durante muchisimo tiempo no se supo que hacer con el campo "Flow<br>
  Label", hasta que, finalmente, mediante RFC6437 y RFC6438 se termino<br>
  especificando como utilizarlo para hacer ECMP.<br>
<br>
  Lamentablemente, por el tiempo que se tardó, hoy en dia esto todavía<br>
  no es posible.<br>
<br>
 + Procesamiento de encabezados de extensión<br>
<br>
   RFC7045 sinceró, un poco, el procesamiento de los Encabezados de<br>
   Extension. En parte apoyado en RFC7045, RFC8200 relaja el<br>
   procesamiento del encabezado "Hop by Hop Options". Sin embargo,<br>
   los problemas operacionales de los encabezados de extension siguen<br>
   siendo ignorados por RFC8200. Ver, por ejemplo, RFC7872, y<br>
<<a href="https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops" rel="noreferrer" target="_blank">https://tools.ietf.org/html/d<wbr>raft-gont-v6ops-ipv6-ehs-packe<wbr>t-drops</a>>.<br>
   Es de notar que si bien no lo incluimos en RFC7872 (por falta de<br>
   tiempo), el "descarte" de paquetes aplica también a los encabezados<br>
   de extensión correspondientes a IPsec. Lo cual hace que, en la<br>
   practica, para poder utilizar IPsec con IPv6 a traves de la Internet,<br>
   uno deba morir en encapsular el trafico en otra cosa 8por ejemplo,<br>
   UDP).<br>
<br>
<br>
<br>
Hay que tener en cuenta también que hay aspectos fundamentales de IPv6,<br>
como su Arquitectura de Direccionamiento, SLAAC, Neighbor Discovery, y<br>
demás, que no se encuentran estandarizados en el propio RFC2460/RFC8200.<br>
En tal sentido, en dichas areas también han ocurrido cambios notables,<br>
como ser la publicación de RFC7217 y RFC8064 (esté ultimo actualizando<br>
formalmente a 14 estandares vinculados a IPv6).<br>
<br>
<br>
En lo que a Neighbor Discovery respecta, se han relizado actualizaciones<br>
como ser la prohibicion de fragmentación con Neighbor Discovery<br>
(RFC6980), así como otras vinculadas a falencias en el protocolo (por<br>
ejemplo, RFC7048).<br>
<br>
<br>
* Que hay de la madurez de las implementaciones de IPv6?<br>
<br>
La madurez de las implementaciones de IPv6 es similar a aquella de las<br>
implementaciones de IPv4 en los años '90. Sin ir mas lejos, Microsoft<br>
incluso ha reimpleentado una "version IPv6" del tradicional ping o'<br>
death. (ver<br>
<<a href="https://technet.microsoft.com/library/security/ms13-065#section22" rel="noreferrer" target="_blank">https://technet.microsoft.com<wbr>/library/security/ms13-065#sec<wbr>tion22</a>> y/o<br>
<<a href="https://gcn.com/Blogs/CyberEye/2013/08/Microsoft-patch-ping-of-death-IPv6.aspx" rel="noreferrer" target="_blank">https://gcn.com/Blogs/CyberEy<wbr>e/2013/08/Microsoft-patch-<wbr>ping-of-death-IPv6.aspx</a>>)<br>
<br>
<br>
* Lo de arriba significa que no debo desplegar IPv6?<br>
<br>
El despliegue de IPv6, al menos para los casos generales, es inevitable.<br>
<br>
Pero esto no es porque IPv6 o sus implementaciones sean maduras, sino<br>
mas bien porque nos hacen falta mas direcciones IP, y lo unico que<br>
tenemos sobre la mesa es IPv6 -- y usar NATs simplemente no escala.<br>
*Este* es el motivador, y *no* la madurez de IPv6 o sus implementaciones<br>
<br>
(Haciendo una analogia: no hay problema alguno en comer hamburguesas de<br>
McDonald's cuando uno tiene hambre... lo incorrecto es pensar que una<br>
hamburguesa de Mcdonald's es un bife de chorizo, o que uno las come<br>
porque se trata de alimentos con buenas caracteristicas nutritivas... :-) ).<br>
<br>
De manera similar, se suelen hacer aseveraciones tales como que "IPv6 es<br>
necesario para IoT, y otras tantas -- sin demasiado sustento, o en<br>
ocasiones, hasta con arguemntos cuestionables.. como inferir que<br>
necesariamente es deseable que dichos dispositivos esten directamente<br>
conectados a Internet via IP.<br>
<br>
<br>
 "When you are studying any matter, or considering any philosophy,<br>
  ask yourself only what are the facts and what is the truth that<br>
  the facts bear out. Never let yourself be diverted either by<br>
  what you wish to believe, or by what you think would have<br>
  beneficent social effects if it were believed. But look only,<br>
  and solely, at what are the facts. "<br>
   -- Bertrand Russell (<<a href="https://www.youtube.com/watch?v=JtJmnDC0yMo" rel="noreferrer" target="_blank">https://www.youtube.com/watc<wbr>h?v=JtJmnDC0yMo</a>>)<br>
<br>
Saludos cordiales,<br>
--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a><br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailma<wbr>n/options/lacnog</a><br>
</blockquote></div></div>
<br>______________________________<wbr>_________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/<wbr>mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/<wbr>mailman/options/lacnog</a><br>
<br></blockquote></div></div>