[lacnog] Madurez de IPv6

[Fernando Gont]

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