[LAC-TF] [lacnog] Madurez de IPv6

Thu Jul 20 14:45:44 BRT 2017

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 at gmail.com> escribió:

> Fernando,
>
> Resumo tu análisis: "es lo que hay."
>
> Justo?
> Roque
>
> On Jul 20, 2017 8:54 AM, "Fernando Gont" <fgont at 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 at si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20170720/f7b458f5/attachment.html>