La reunión IETF98 tuvo lugar en Chicago del 25 al 31 de marzo. El sábado 25 y domingo 26 se realizaron varias actividades paralelas, como el Hackathon, Code Sprint, reunión de IEPG, tutorial de nuevos participantes y un tutorial de QUIC, entre otras. Los grupos de trabajo se reunieron de lunes a viernes y a continuación se resumen algunos de los temas tratados.

IPv6

Los dos principales grupos relacionados con IPv6, v6ops y 6man, tuvieron su reunión en Chicago.

En v6ops el foco estuvo puesto en la operación de redes IPv6-only, incluso proponiendo una modificación al chárter del grupo para ajustarlo a esa visión. Algunos de los drafts presentados están relacionados a esto: un draft sobre actualizaciones para que los CPE soporten mecanismos de transición más actuales; uno sobre requerimientos de routers en general; también el documento draft-gont-v6ops-host-configuration, que discute sobre las incompatibilidades en la asignación de DNS y la necesidad de resolverlas a fin de poder operar redes sólo IPv6. Cabe mencionar que actualmente, en muchos casos, la única solución posible termina siendo asignar DNS a los equipos mediante DHCP en IPv4.

En 6man continuó la discusión sobre estandarización del protocolo IPv6, particularmente con las RFCs 2460bis y 4291bis. En la primera, el texto definitivo sobre la prohibición de inserción de EH en nodos intermedios es cuestionado por algunos fabricantes. En la segunda, la discusión es sobre los límites del espacio de direccionamiento IPv6: si los 64 bits para interfaces deben ser fijos o no. Estos dos documentos han generado una gran cantidad de discusión en el WG, incluso después del llamado a last-call.

Un draft de importancia es el de una actualización a los requerimientos de nodos IPv6, que actualiza la RFC 6434 agregando varias funcionalidades como el soporte de direcciones de privacidad, el uso de RFC 7217 para SLAAC, obligatoriedad de aceptar información de DNS en los RA, soporte obligatorio de MLDv2 para multicast, soporte para el modelo Netconf/YANG y otros cambios que apuntan a mejorar la experiencia de despliegue de IPv6.

Otros dos drafts se presentaron: uno de ellos realiza una actualización de las características de las direcciones temporarias y clarifica sobre la necesidad, o no, de utilizar direcciones estables; el otro draft es sobre recomendaciones de uso de direcciones, fundamentalmente para servicios a publicarse en la red.

Como se puede ver, IPv6 continúa en un proceso de cambios, fundamentalmente ligados a la operación y la necesidad de garantizar la interoperabilidad entre las distintas implementaciones.

Ruteo

En grow se realizaron un par de presentaciones acerca de OpenBMP y extensiones al protocolo. También sobre una técnica para mejorar los tiempos de re-enrutamiento de tráfico en caso de mantenimiento de enlaces en topologías como un IXP, para evitar esperar a que los hold-timers de BGP expiren.

En idr se continúa trabajando sobre el problema de clasificación y soluciones para los route-leaks (ver clasificación en RFC 7908). Dos drafts, que introducen nuevos elementos para ayudar a la mitigación de los leaks, fueron presentados: uno definiendo “roles” en las relaciones BGP: peer, customer, provider, internal; el otro definiendo un nuevo atributo: RLP, route-leak protection. La fundamentación de estos trabajos está en que, normalmente, los anuncios de rutas que recibimos de nuestros proveedores no deberíamos propagarlos a través de enlaces de peering o hacia otros proveedores de tránsito, así como tampoco las rutas aprendidas de nuestros peers deberían propagarse a otros peers o enlaces de tránsito. Esta clasificación de las relaciones entre los sistemas autónomos está dando lugar a distintos drafts que ahondan sobre el tema.

Otras dos presentaciones estuvieron relacionadas a la implementación de mecanismos de descubrimiento y configuración automática de vecinos en BGP. Este tipo de cambios drásticos al protocolo están ligados a los llamados MSDC: Massively Scalable Datacenters, en los que se prefiere utilizar BGP como único protocolo de ruteo (ver RFC 7938).

A medida que se agrega información en BGP, los mensajes de UPDATE crecen de tamaño, por lo cual también se están proponiendo técnicas de compresión para ellos, como las que describe draft-przygienda-idr-compressed-updates, así como una longitud extendida mas allá de los 4Kbyes: draft-ietf-idr-bgp-extended-messages.

Cabe preguntarse si todos estos cambios no ameritan definir un nuevo protocolo para estos usos específicos en vez de continuar extendiendo BGP.

En IETF98 se llevó a cabo la primera reunión del grupo sidrops. Este grupo es una suerte de continuación de sidr, sólo que enfocado en temas de operación, una vez que los protocolos ya han sido definidos. Respecto de sidr, la lista continuará funcionando y hay algunos trabajos que aún continúan en sus etapas finales, si bien el grupo ya no se reunirá como tal. En lo que concierne a sidrops, se presentaron los mismos trabajos sobre route-leaks que en idr, un par de trabajos sobre BGPsec y un draft que desaconseja el uso de maxlength en los ROAs por la posibilidad de facilitar ataques que introduciría su uso.

IoT

En Chicago se reunieron los grupos relacionados con IoT como ace, lwig, core, roll, asi como los que implementan IPv6 sobre arquitecturas restringidas como 6lo, 6tisch, y el recientemente creado lpwan. También se reunió el grupo del IRTF t2trg que se ocupa del modelo de IoT a más largo plazo. En esta ocasión la dinámica de la reunión consistió en plantear algunos problemas y dividirse en cuatro grupos para discutirlos. Algunos de los problemas tuvieron que ver con interoperabilidad, formas de distribuir la información de seguridad en un contexto público, manejo de certificados en dispositivos que se espera que duren 10 años sin administración, transferencia de autoridad de un propietario a otro, etc. Por ejemplo, se planteó como caso concreto: ¿qué deberíamos hacer al vender una casa a un nuevo propietario? ¿Cómo hacer para que pueda acceder a la cantidad de dispositivos IoT que existirán? ¿Cuál sería la operación equivalente a darle las llaves al nuevo propietario? ¿Cuál es el equivalente a cambiar la cerradura de la puerta? Todas estas cuestiones fueron abordadas y discutidas brevemente en el grupo y presentan desafíos que aún no están resueltos.

Otros temas

BOF sobre CASM

Se realizó un BOF llamado CASM sobre Coordinated Address Space Management. La idea de éste es generar una forma centralizada de manejar el espacio de direcciones de una organización, de forma integrada con otros equipos que necesitan pools de direcciones. Por ejemplo, poder interactuar con los equipos DHCP, los BNGs, NATs & CGNs, equipos SDN, etc. La idea es que desde el servicio IPAM se pueda coordinar y manejar el pool de direcciones de una organización y asignar/configurar/transferir bloques entre equipos, que en la actualidad se hace en forma manual. Un comentario de parte de los RIRs (George Michaelson, APNIC) fue integrar a esta problemática la interfaz con los registros regionales de IP y no sólo pensarlo hacia “abajo” de la organización.

IEPG

El IEPG es el Internet Engineering Planning Group, un grupo que se reúne habitualmente los domingos antes de que empiece la IETF y que trata temas de operación. En esta ocasión hubo presentaciones sobre el uso de “Let’s encrypt” y su contribución a democratizar el encriptado en Internet; un estudio de las violaciones al protocolo DNS por parte de diferentes implementaciones; un análisis sobre las longitudes de los prefijos IPv6; y un análisis de Geoff Huston sobre las tablas de BGP en 2016. Algunas de las observaciones de este último estudio son, por ejemplo, que a pesar del agotamiento de IPv4, la tabla de BGP sigue creciendo linealmente, al mismo ritmo, si bien el tamaño medio de prefijo está disminuyendo. Otra observación interesante es que la cantidad de UPDATES crece sustantivamente y sin embargo la convergencia de BGP continúa estable: una de las razones que contribuye a esta estabilidad es la corta longitud en promedio de los AS-PATH, que está en el orden de 4 ASs. En estos análisis se ve que la mayoría de los datos son obtenidos de colectores en Europa y EEUU. Sería importante poder contar con más colectores de RIS en América Latina y el Caribe.

Plenario técnico

El tema del plenario en esta ocasión fue la relación entre protocolos y derechos humanos. Este es un tema que ya se venía discutiendo en la IRTF, en un grupo específico, y ahora se planteó en el plenario. En general hubo acuerdo en que la tecnología no es neutral al respecto y, así como el tema de seguridad se ha incorporado en las RFCs, se sugirió incluir consideraciones respecto de los derechos humanos. Una parte de la discusión giró en torno a la falta de soluciones sencillas para permitir el encriptado de las comunicaciones y se reconoció de forma autocrítica una falla de parte de la IETF en ese aspecto.

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/98/agenda.html