La reunión IETF99 tuvo lugar en Praga, República Checa, del 15 al 21 de Julio. A continuación, se resumen algunos de los temas tratados.

IPv6

Por el lado de 6man, la principal novedad es haber logrado alcanzar la categoría de Standard para el protocolo IPv6, mediante la publicación de la RFC 8200. Este proceso, como ya se ha comentado, provocó muchas discusiones, fundamentalmente en torno a los encabezados de extensión y la prohibición de modificarlos o insertarlos en el camino (equipos intermedios). Al respecto, el texto final fue redactado de esta manera:

“Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet’s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header”.

Un buen resumen de los cambios que ha tenido IPv6 se puede ver en los siguientes emails de Fernando Gont:

https://mail.lacnic.net/pipermail/lactf/2017-July/006879.html

https://mail.lacnic.net/pipermail/lactf/2017-July/006881.html

Por otro lado, continuó la discusión sobre la actualización de la RFC 4291 y aquí, lo que no logra alcanzar consenso es la longitud del identificador de interfaz: si debe ser fija de 64 bits o no. El texto actual del draft la deja fija pero con varias excepciones: “Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents”.

Se hace referencia a la RFC 7421 que hace un análisis de la longitud fija de 64 bits en los identificadores de interfaz.

En cuanto a v6ops, el nuevo chárter está enfocado en la operación de redes sólo IPv6 y buena parte de las presentaciones tuvieron que ver con esto. Uno de los temas en debate fue acerca de la red de los eventos de IETF y si existe la posibilidad de utilizar una red IPv6-only o no. Este fue un tema conflictivo, ya que al día de hoy hay muchas aplicaciones que no funcionan sobre IPv6, aun utilizando NAT64.

Hubo en ese sentido presentaciones demostrando que muchos de los sitios principales de la lista de Alexa que soportan dual-stack, fallan sin embargo en redes sólo IPv6.

También se realizó una presentación de un draft que actualiza el mecanismo happy eyeballs, con una serie de mejoras para incrementar su eficacia: ver draft-ietf-v6ops-rfc6555bis-02.

Un documento de interés para los operadores es el draft sobre requerimientos para routers CPE presentado por Jordi Palet. Una de las razones importantes para actualizar la RFC 7084 es la necesidad de incluir mecanismos de transición más actuales que los que allí se mencionan (6rd y DS-Lite) e incluir fundamentalmente 464XLAT y MAP. El documento original que actualizaba la RFC 7084 fue dividido en 4 documentos separados: “Basic Requirements for IPv6 Customer Edge Routers”, “Transition Requirements for IPv6 Customer Edge Routers”, “Minimum Requirements for IPv6-only Customer Edge Routers” y “Requirements for IPv6 Customer Edge Routers with HNCP”.

Un draft que conviene revisar es “Considerations For Using Unique Local Addresses”, que analiza casos de uso para las direcciones ULA. Allí se recomienda por ejemplo no utilizar las direcciones ULA con NPTv6 (NAT 1-1 en IPv6). Este mismo criterio fue ratificado en la discusión en el WG: “Document needs to say ULA + NPTv6 is ‘not recommended’ or ‘NOT RECOMMENDED’”. Sin embargo, este es un caso de uso que podría ser de interés para muchas organizaciones que tienen direcciones PA (dependientes del proveedor). Esto se debe a que las soluciones “multihoming” en IPv6 aún no están maduras (excepto usar direcciones PI).

Ruteo

En grow, el grupo que trata cuestiones de operación de BGP, dos drafts presentados tratan sobre técnicas para evitar pérdidas de paquetes en casos en que una sesión BGP es apagada, tratando de dar tiempo a reencaminar el tráfico (bgp session culling y bgp graceful shutdown). El otro draft presentado actualiza el protocolo BMP agregando posibilidades de examinar la tabla local de BGP. Cabe destacar que el protocolo BMP, definido en la RFC 7854, BGP Monitoring Protocol, define un protocolo para obtener una visión de las rutas en BGP y permitir su monitoreo.

En idr la actividad comenzó con una larga discusión de procedimientos acerca de los tiempos de los drafts e implementaciones y la asignación de codepoints por parte de IANA. Se puede ver aquí: https://www.youtube.com/watch?v=Dg13UDADozs&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h

Un draft que continua en discusión es “Route Leak Prevention using Roles in Update and Open messages”, el cual propone una asignación de roles a los peers BGP, de manera de clasificarlos en peers, providers, customers e internals. De esta forma, los prefijos aprendidos de neighbors clasificados como peers no son anunciados a otros peers, los prefijos aprendidos en un rol de “customer” no deberían ser anunciados a peers, etc. Esto permitiría evitar route-leaks, si bien introduce un cambio bastante profundo respecto del modelo actual de BGP.

Una gran cantidad de drafts se presentan en este grupo, agregando capacidades a BGP y modificando incluso algunas de sus características, como por ejemplo el que propone usar LLDP para auto-descubrimiento de vecinos. Habrá que ver cuáles de todas estas extensiones llegan a ganar aceptación entre los operadores de red.

En cuanto a sidrops, se presentaron algunas estadísticas que muestran que aproximadamente el 10% de los ROAs no cubren correctamente las publicaciones en Internet, por lo que se discutieron herramientas que puedan ayudar a mejorar esto. Entre ellas, una herramienta llamada “learning validator” que permite ignorar ROAs o configurar ROAs virtuales cuando se sospecha que la falta de un ROA podría conducir a descartar tráfico. Esto generó bastante discusión, ya que no está claro en qué casos eso podría servir o ser contraproducente, ya que no existe un criterio para determinar si un ROA cubre el conjunto de prefijos esperado o no (en otras palabras: si el tráfico que posiblemente se descartaría es tráfico válido o no).

Una de las presentaciones más importantes fue el documento “Update on Tree-validation”,
draft-ietf-sidrops-rpki-tree-validation-00.txt, que documenta el validador RPKI de RIPE NCC, uno de los más utilizados para validación de origen.

DNS

Hay muchos cambios que están ocurriendo en el DNS. Además de las cuestiones sobre privacidad de las que se ocupa el grupo dprive (qname minimization, DNS sobre TLS, DNS sobre QUIC, etc), en el grupo dnsop se están proponiendo muchas extensiones y modificaciones a la operación del sistema de nombres de dominio.

Una de las propuestas es un nuevo tipo de RR llamado ANAME, que es similar al CNAME, solo que puede coexistir con otro tipo de RR para el mismo nombre (recordemos que en cambio el CNAME es el único tipo de RR que se puede definir para un nombre). Este es un cambio que es de utilidad para las CDNs ya que permite utilizar el registro ANAME en el nombre de la zona (“ápex”) y poder redirigir a distintas IPs según corresponda.

A medida que progresan las propuestas de utilizar DNS sobre protocolos de transporte (TCP, TLS, HTTPS, QUIC), las sesiones tienen más duración, por lo que se vuelve necesaria alguna forma de control. El draft “DNS Session Signaling” propone utilizar TLVs para este tipo de señalización, efectuando un cambio notable a la operación del DNS que existe hoy en día.

Otro draft de interés es “A DNS Packet Capture Format”, que propone un formato estándar para captura de una gran cantidad de paquetes del tráfico de DNS, como puede ser necesario, por ejemplo, en servidores autoritativos para monitoreo y análisis.

Para más información, un buen artículo de Geoff Huston sobre la evolución y cambios que se están proponiendo en el DNS se puede ver aquí: https://blog.apnic.net/2017/07/25/ietf-99-prague-theres-lot-going-dns/

IoT

En el grupo de la IRTF t2trg se continúa analizando las características que debería tener una verdadera Internet de las cosas: una Internet donde los dispositivos de bajos recursos o restringidos puedan comunicarse entre sí y con la Internet en gran escala. Para esto, se trabaja en las cuestiones de interoperabilidad a nivel semántico, estructural y sintáctico.

El foco de la IETF está puesto en las capas de IP hacia arriba, terminando en la capa de aplicación, definiendo APIs para comunicación y funciones de administración incluyendo seguridad.

Uno de los temas que se mencionaron es el de la coexistencia entre muchas redes de IoT que compartirán el espectro (2.4GHz, pero también sub-GHz) y redes IP. Se hizo la analogía que hasta ahora se ha estado tratando de hacer andar un auto en la autopista vacía, pero hay que pensar en qué va a pasar cuando esa autopista esté más congestionada. ¿Cómo evitar que una red desplace a otra?

También se analizó la relación entre edge computing y la IoT, considerando aspectos de modelos de programación, networking y operación.

Otros temas

IEPG

Tal como es habitual, el domingo por la mañana se reunió el IEPG (Internet Engineering Planning Group), grupo que trata temas de operación de Internet.

Comenzó con una exposición de George Michaelson de APNIC sobre la posibilidad de detectar casos en los que no es posible pasar de una conexión HTTP insegura a una TLS. Gran parte de este trabajo sin embargo estuvo relacionada a la necesidad de trabajar con mayor seriedad estadística con los datos que obtenemos, sobre todo cuando estos datos pueden ser utilizados para definir políticas públicas. En su presentación se puede ver que hay muchos casos en los que establecer una conexión HTTPS es mucho más difícil y que en ello tiene una gran importancia tanto el navegador como el ASN, más que el sistema operativo.

Tres presentaciones trataron sobre temas de DNS: una sobre automatización de la transferencia de los registros DS de zonas hijas a padres (RFC 7344); otra sobre un análisis del uso de los servidores anycast de Netnod y las razones por las cuales no recibían el mayor número de consultas a pesar de ser mayor cantidad; por último un trabajo llamado “Root Canary” que pretende monitorear el rollover de la KSK y avisar en caso de problemas en base a la medición de DNSSEC desde distintos ángulos.

La presentación de Geoff Huston sobre “BGP more specifics” trató sobre las razones para desagregar tráfico en BGP y la comparación entre IPv4 e IPv6. Mientras que en IPv4 el porcentaje de anuncios más específicos se mantiene en el tiempo en el orden de 50% sobre el total, en IPv6 está en crecimiento, llegando actualmente a un 38%. Una característica también de los anuncios de prefijos IPv6 en BGP es que su inestabilidad es mucho mayor.

Quantum criptography

Un tema que se trató en esta reunión es la necesidad de preparar los algoritmos para el momento en que se logren operar computadoras cuánticas de gran escala. Es sabido que cuando este tipo de computadoras se puedan construir tendrán un efecto catastrófico sobre los algoritmos criptográficos y de encriptado que usamos actualmente.

En la actualidad ya existen computadoras cuánticas de escala pequeña, por lo que no está claro cuándo estarán disponibles computadoras que puedan quebrar los algoritmos actuales. Por lo tanto, es importante por un lado poder predecir en qué momento dichas computadoras estarán disponibles y, por otro lado, comenzar a trabajar en desarrollar y utilizar los algoritmos alternativos que son clasificados como “post-quantum criptography”.

Este es un tema de gran importancia, que conlleva un cambio en todos los algoritmos criptográficos que se utilizan en la actualidad.

Routing in the datacenter

En el marco del rtgwg se mencionó que en la próxima reunión de IETF habrá un BOF dedicado al tema de enrutamiento en el datacenter. Este es un tema que se ha venido discutiendo en reuniones anteriores y por tal razón será el motivo de una reunión específica que discuta la problemática, requisitos y posibles soluciones sobre el tema.

Este es apenas un breve resumen de algunos de los temas que se trataron en la reunión. Se puede ver más información en cada uno de los grupos de trabajo. Ver: https://datatracker.ietf.org/meeting/99/agenda.html