[lacnog] Madurez de IPv6

Jue Jul 20 12:52:46 BRT 2017

Fernando,

Resumo tu análisis: "es lo que hay."

Justo?
Roque

On Jul 20, 2017 8:54 AM, "Fernando Gont" <fgont en si6networks.com> wrote:

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