[Lista ArNOG] [lacnog] Madurez de IPv6

J. Ignacio Alvarez-Hamelin ihameli en cnet.fi.uba.ar
Jue Jul 20 19:01:32 ART 2017


Perdón Fernando, pero creo que el tema es que se "terminó" una versión
allá por el 2000, y se empezó a usar en serio cuando se terminaron las
direcciones IPv4 en ARIN (febrero 2011). Es verdad que los japoneses
comenzaron a usarlo antes. Pero el problema es que se hizo y quedó
archivado hasta que se comenzó a usar por fuerza mayor.

Es como BGP, podemos hacer miles de protocolos mejores, pero hasta que no
haya una necesidad realmente imperiosa, lo vamos a seguir usando.
Y... hasta que no se usa no surgen los problemas. En fin. tal vez lo que
no te gusta es la definición de STD, y es posible que tengas razón.
El tema es que otros métodos, como por ejemplo la estandarización de USB o
bluetooth ha llevado a mucho tiempo de incompatibilidades.

Tal vez es hora de formalizar las pruebas que debe pasar un protocolo de
comunicaciones para que pueda utilizarse. (Me refiero a una prueba 
mediante herramientas foramles de teoría de lenguajes.)

Esta es mi versión libre de lo que pasa con IPv6 y otras yerbas en
Internet.


Saludos!

 	J. Ignacio

_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: ihameli en cnet.fi.uba.ar
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________


On Thu, 20 Jul 2017, Fernando Gont wrote:

> Hola, Roque,
> Ciertamente esa es la conclusión final.
> 
> 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".
> 
> 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).
> 
> Creer q es maduro no o estable solo ayuda a frenar posibles mejoras -- lo cual, obviamente, no es una "ayuda", sino todo lo contrario.
> 
> Fernando
> 
> 
> 
> 
> 
> El 20 jul. 2017 5:53 p. m., "Roque Gagliano" <rgaglian en gmail.com> escribió:
>       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
> 
> 
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> 
> 
>


Más información sobre la lista de distribución Lista