[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