Mostrando entradas con la etiqueta rfc. Mostrar todas las entradas
Mostrando entradas con la etiqueta rfc. Mostrar todas las entradas

jueves, 22 de agosto de 2024

Ampliando el Espacio de Documentación en IPv6

Introducción y un poco de historia

Primero hablemos un poco sobre los prefijos IP de documentación, el objetivo de estos prefijos es que sean exclusivamente utilizados en libros, textos, ejemplos, tutoriales, etc y que no sean enrutados en Internet.  Su éxito ha traído consigo también mayores necesidades, esto me recuerda a un dicho muy sabio que reza: los problemas de hoy fueron las soluciones de ayer.


Segundo, por otro lado, algo muy interesante está ocurriendo en el marco de IETF y específicamente dentro del working group v6ops.  Lo que   está ocurriendo es que hace exactamente 10 años un grupo de profesionales (incluido este humilde servidor) intentamos expandir el espacio de documentación en el mundo de IPv6 [1]. Lastimosamente este intento no procedió y quedó en el tintero.


Finalmente, hoy en día existe un ID (Internet Draft) que pensamos lo va a lograr (convertirse en RFC), el mismo tiene como nombre: “Expanding the IPv6 Documentation Space”. Es un documento que apoyamos y creemos que es necesario e importante para la comunidad; claro, a su vez pensamos que era mejor retomar el draft de hace 10 años y rescatarlo, mecanismo perfectamente válido dentro del IETF.


¿Se necesitan prefijos de documentación?  Las direcciones privadas ¿no sirven para lo mismo?

Son conceptos diferentes y cada uno ataca problemas distintos. Ciertamente a veces se tienden a confundir, pero la concepción de cada uno busca diferentes soluciones.


Las direcciones privadas en IPv4 y aprovechamos y hablamos de las ULA -Unique Local Address- en IPv6 sus objetivos es que sean utilizadas en redes internas, es decir, son direcciones IPs que si estarán en uso en la red y configuradas en nuestros equipos (léase desde computadoras, hasta servidores pasando por impresoras y teléfonos móviles).  De hecho, muy probablemente el equipo con el que navegas este artículo tenga una dirección privada en este momento.


Por otro lado, las direcciones o prefijos IP de documentación buscan precisamente que sean utilizadas en documentos, revistas, ejemplos en la web, laboratorios y mucho más. Estos prefijos son muy importantes para garantizar la claridad y coherencia en la documentación topológica, sin  afectar la operatividad de una red. Por ejemplo, en el mundo de IPv6 las probabilidades que leas un documento en la web, un video ejemplo o en alguna revista es muy posible que el direccionamiento utilizado pertenezca al prefijo 2001:db8::/32.


Por último, ninguno de los prefijos privados y/o documentación deben ser enrutados en Internet, ni deben ser aceptados por ejemplo en routers que hablen BGP hacia proveedores de Internet.


Para el resto de este artículo nos enfocaremos en las direcciones IP de documentación que precisamente es el cambio que se avecina en el mundo de IPv6.


Sobre el draft actual “Expanding the IPv6 Documentation Space”

Es un documento de la autoría de Geoff Huston y Nick Buraglio. La primera versión se introdujo en el 2021 y actualmente va por la versión 03 que expira el 30 de noviembre de este año. Sin embargo, ya se encuentra en Last Call y con amplio apoyo por la mayoría de la comunidad. Nuestro pronóstico es que se convertirá en RFC tipo Informational prontamente.


¿Cómo ha sido el progreso del documento dentro de IETF?




¿Qué busca el draft?

Este documento propone reservar un prefijo adicional de direcciones IPv6 para ser utilizado en documentación. Actualmente se tiene el bloque de direcciones 2001:db8::/32 reservado para este fin, pero se sugiere expandirlo con un prefijo más grande, específicamente un /20.


Motivos

Esta ampliación permitirá que los ejemplos documentados reflejen de manera más precisa una gama más amplia de escenarios de implementación realistas y se alineen mejor con los modelos de asignación contemporáneos para grandes redes. Sin ir muy lejos, para aquellos que hemos dado cursos de IPv6, muchas veces nos hemos visto limitados en poder crear topologías y planes de direccionamiento IPv6 que se ajuste a muchas empresas y necesidades.


Argumentos

Se argumenta que con la expansión de la implementación global de IPv6, los escenarios individuales de implementación de redes IPv6 han aumentado en tamaño y diversidad, lo que hace que el prefijo 2001:db8::/32 original sea insuficiente para describir muchas topologías actuales de implementación realistas. La asignación de un /20 solucionará todas las limitaciones anteriores e incluso brindará nuevas posibilidades que se escapan de nuestra imaginación.


Alguna información que sustente lo anterior

Según los datos publicados por los Registros Regionales de Internet en agosto de 2023, aproximadamente el 25.9% de todas las asignaciones IPv6 registradas son mayores que un /32 en tamaño. Se destaca que la mayoría de las asignaciones son /29. Se cree que reservar un /20 cubriría las necesidades de documentación en relación con la amplia gama de despliegues ajustados a la realidad.  Como dato referencial, en un /20 tenemos 4096 /32s. En nuestra región podemos crear entre otros un plan de direccionamiento IPv6 para una multinacional que desee tener /32 en cada país de LATAM (y del mundo) sin ningún inconveniente.


Otros puntos importantes

Se recuerda que los prefijos de documentación no deben usarse para tráfico real, no deben anunciarse globalmente y no deben utilizarse internamente para tráfico productivo o conectividad. Es importante filtrar los prefijos de documentación en las publicaciones de prefijos de enrutamiento según corresponda.


Conclusiones

Creemos que este documento procederá en los próximos meses dentro de IETF, posteriormente contaremos con  un prefijo de documentación /20 que cubrirá a la perfección casi la totalidad del laboratorio de redes pensables y con ello los beneficios para el ecosistema de Internet y la promoción del protocolo IPv6.


Referencias

https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/

https://datatracker.ietf.org/doc/html/draft-moreiras-v6ops-rfc3849bis-01

https://datatracker.ietf.org/doc/html/rfc3849

https://datatracker.ietf.org/doc/html/rfc5737

domingo, 21 de abril de 2024

Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS

En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su nombre indiscutiblemente me llamó la atención.


Historia

La necesidad de encapsular un protocolo en otro no es nada nuevo. De hecho, esta práctica lleva con nosotros aproximadamente 30 años.

Retrocedamos a la década de los 90. En estos años ocurrió de todo en cuanto a las ideas de encapsular un protocolo en otro. Por ejemplo, IP-IP (IP en IP) apareció cuando Internet estaba en sus primeras etapas de expansión comercial y se buscaban formas de conectar redes privadas sobre la infraestructura de red pública, lo que conocemos hoy en día como Internet.

En esa misma década sin ir muy lejos aparecieron otras tecnologías que aún son muy populares como -el querido- GRE, PPTP, L2TP, e incluso ya a finales de los 90’ y comenzando los 2000, hubo grandes avances con VPNs IPSEC.

Pero no avancemos tanto en el tiempo, vamos a quedarnos un rato más en los 90’. Ya no solo se quería encapsular IPv4 en IPv4, también dieron un paso adelante con IPv6 y apareció el protocolo 41 (IPv6 en IPv4) en 1998.

A partir de aquí el resto es historia. Ya se han realizado cualquier cantidad de “mezclas” de encapsulamientos de protocolos, como IPv4 sobre IPv6, IPv6 sobre UDP sobre IPv4, ethernet sobre IP y un largo etcétera.


Ok, volvamos al draft Ethernet sobre HTTPS

A finales del año 2023, específicamente el día 27 de diciembre dentro del Working Group INTAREA (Internet Area Working Group) llegó un draft con el título Ethernet sobre HTTPS,


¿De qué trata el draft?

El Draft busca definir un protocolo para encapsular tramas ethernet sobre HTTPS, permitiendo una comunicación segura entre clientes y servidores Web internos.


¿Cómo se pretende lograr lo anterior?

Dentro de la sección 1.2 del documento se realiza la siguiente explicación, que podemos resumir en lo siguiente:


El cliente, al especificar una URL interna, reconoce que se debe utilizar Ethernet sobre HTTPS para la comunicación. El navegador del cliente, preconfigurado con la dirección IP y el puerto del Servidor HTTP que actúa como puerta de enlace a la LAN, inicia el protocolo Ethernet sobre HTTPS y envía una solicitud de autenticación al servidor. Una vez autenticado, el cliente envía una solicitud de página web interna encapsulada dentro de una solicitud HTTPS. El servidor desencapsula la trama Ethernet, extrae la solicitud HTTP original y la enruta al servidor web interno. Luego, el servidor encapsula la respuesta del servidor web interno y la envía de vuelta al cliente.


Diagrama de operación





Respuesta al cliente

El draft explica que la respuesta a una solicitud de un cliente es en formato JSON. Un ejemplo sería:




Puntos positivos del draft

Trata de un tema interesante, puede ser novedoso y tener una gran cantidad de implementaciones.

Por el momento es un draft corto y correctamente hace hincapié en el área de seguridad y autenticación. 

Dudas que deja el mismo


El problema no queda bien definido, es difícil entender por qué se desea solucionar una situación a nivel HTTP desde Ethernet.

Pareciera que el servidor EoH es similar a un proxy

El área de seguridad a nivel de capa 2 es muy delicada, debería ser al menos mencionada en el draft

Expresan respuestas en json de mac_address y direcciones IP con un ejemplo de IPv4 ☹️

Indiscutiblemente, la explicación del funcionamiento deja muchas dudas

Es muy normal en el mundo de encapsulamiento tener preocupaciones en el área del exceso de payload. Transportar ethernet sobre HTTPS es literalmente cargar todo el modelo TCP/IP en HTTPS

Al punto anterior hay que sumar los posibles problemas de MTU que pueden conllevar este tipo de soluciones.

Ya existen varios trabajos en este sentido, el primero es el draft “Proxying ethernet in  HTTP” y un software que hace precisamente lo que promete el draft llamado Softether. Lo anterior sin mencionar  “Proxying IP in HTTP” el cual incluso ya es un RFC Standard Track (RFC 9484).


Pronóstico sobre el draft

Recordando el funcionamiento de IETF (ver diagrama abajo), donde individuos proponen drafts de manera personal, luego son adoptados por el WG, y más adelante luego de un consenso de la comunidad en varias etapas, el mismo es adoptado como RFC.




The IETF Publication Process


Con la versión actual del mismo, no pareciera que el draft avance mucho. Pienso que quedará lejos del consenso dentro IETF. Hoy en día no se aprecia mayor soporte por parte de la comunidad, sin embargo no quiero descartarlo 100% porque pueden ocurrir cosas que le den un giro al mismo como conseguir nuevos autores, conseguir un “running code”, presentarlo presencialmente y muchas otras cosas.


Conclusiones


Es un draft que propone una idea arriesgada, vamos a llamarla reflexiva, sin un problema claro que resolver. Esto es un claro ejemplo de que no todos los documentos que llegan a IETF son tan elaborados, a veces son solo ideas para medir la temperatura de la comunidad.


¿Qué opinas de este draft? ¿Te ánimas a introducir algún documento a IETF?

martes, 23 de marzo de 2021

RFC 7911- BGP Add-path en acción



En el video se realiza un demo de la capacidad de BGP llamada Add-Path definida en el RFC 7911 utilizando FRR sobre Ubuntu. Para la realización del video se utilizó únicamente prefijos IPv6 a pesar de que la capacidad es agnóstica al prefijo transportado

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...