Hoy, sale un artículo con un toque de humor! Veremos qué son las RFC, por qué son tan importantes, y analizaremos algunos ejemplos de RFC’s relevantes, relacionadas con un protocolo de transporte basado en palomas mensajeras 😛

Hace ya años leí estas RFC’s, y desde entonces tengo una entrada en mi kanboard que dice «Escribir artículo sobre IPoAC (IP over Avian Carriers – IP sobre palomas mensajeras)», así que ahí voy.

Saben que me apasionan los protocolos de red, el encapsulamiento, tunneling, análisis de tráfico, etc. Por esto, cuando leí un documento oficial de la IETF, una RFC (Request for Comments), sobre cómo encapsular paquetes IP sobre un transporte de palomas mensajeras, me llamó mucho la atención, como se imaginarán.

RFC – Request for Comment

Las RFC son documentos técnicos de estandarización (no todos llegan a estándar igualmente), mayormente publicados por la IETF. Su origen se remota a 1969, momento en el que Steve Crocker, pionero en comunicaciones entre computadoras y la seguridad de dichas comunicaciones, ideó el concepto.

Crocker había creado en esos tiempos un grupo de trabajo de Redes de la IETF llamado NWG (Network Working Group), y necesitaba un mecanismo que mejorara la comunicación tanto entre los integrantes del grupo como con el resto de los grupos de trabajo que experimentaban con ARPANET. Las RFC fueron la solución.

Las RFC son documentos técnicos escritos en texto plano, sin formatos. Cuentan con una cabecera, índice (en general), y están divididos en secciones. Las gráficas que incorporan también son texto plano, arte ASCII, lo que les da un aire old-school característico de los inicios de Internet.

Cada RFC está numerada y puede tener referencias a otras RFC’s. Nunca se eliminan, y sus números no pueden reutilizarse, aunque el documento quede obsoleto. Se van generando nuevas RFCs que actualizan las anteriores, y toda la evolución de las mismas queda documentada.

Así, cada RFC tiene un ciclo de vida en el que va pasando entre diferentes estados, gestionado por la Junta de Arquitectura de Internet (IAB – Internet Architecture Board), una sección de la IETF.

Los estados y sus cambios de estado pueden verse en la siguiente imagen, y se describen a continuación.

• Estándar: ya es norma definida por la IAB.
• Estándar borrador: Se está considerando la propuesta para su estandarización por parte de la IAB.
• Estándar propuesto: Protocolo no estandarizado que se propone a la IAB para su estudio.
• Experimental: En proceso de desarrollo de, no debería implementarse.
• Informativo: Protocolos desarrollados por terceros externos a la IAB, pero que se publican como RFC por conveniencia de la comunidad de Internet.
• Histórico: el protocolo quedó obsoleto y la definición de su RFC fue reemplazada por otra/s.

Hay RFC’s para muchas cosas, por ejemplo, la RFC 2821 corresponde con el protocolo SMTP (correo electrónico), la RFC 2784 corresponde con el protocolo de encapsulamiento GRE, o la RFC 4949, un glosario muy interesante sobre seguridad en Internet.

El sitio de RFC Editor permite listar todas las RFCs redactadas hasta el momento, y posee un buscador por número o palabra clave, muy recomendable de ver.

Las RFC van definiendo estándares y normativas sobre protocolos (y otras cosas) en Internet. De hecho, existe una RFC que define el proceso de estandarización de Internet, incluido el uso de las propias RFCs: la 2026 (sí, hay bastante de recursividad ahí :P).

En la práctica, esto se traduce en:

¿Querés desarrollar un servidor web? Entonces tendrías que programar una aplicación que implemente los mensajes detallados en la RFC 2616 (protocolo HTTP), que además ha sido actualizado por las RFC’s 7230-7235. Y si querés agregarle seguridad (TLS), deberías mirar la RFC 8446 de TLS v1.3.

Lo mismo si querés desarrollar un cliente HTTP, o para cualquier protocolo de red de cualquier capa del modelo TCP/IP. Es más, el propio stack TCP/IP está documentado en la RFC informativa 1180!

RFC 1149 – IP over Avian Carriers (IPoAC)

Ahora que sabemos lo que es una RFC, analicemos una particular para entender su estructura, actualizaciones y formatos.

Elegí la RFC 1149 porque me causó mucha gracia la primera vez que la leí: Un estándar para transmisión de paquetes IP sobre Palomas mensajeras… sí, como suena.

Se trata de un método experimental de encapsulamiento de paquetes IP sobre palomas mensajeras. En su intro describe que es útil en redes de área metropolitana, obviamente 😛

En esta captura de la intro vemos varias entradas interesantes. Arriba a la izquierda muestra qué otras RFCs la actualizaron (2549 y 6214 en este caso), a qué grupo de trabajo de la IETF pertenece (NWG), y el número de RFC que se trata: 1149.

A la derecha se ve su estado: EXPERIMENTAL, cuyo significado se comentó anteriormente. Se ve el autor de la RFC y el año de la publicación.

Además se aprecia que la RFC tiene erratas, y dichas erratas pueden verse dando clic en link homónimo situado en la parte superior. Particularmente me dio curiosidad en esta RFC, así que entré, y me encontré que fue rechazada en el 2011 con una nota muy peculiar:

No debería usarse un espejado de puertos con palomas mensajeras, ya que una única colisión con el espejo resultará en un 100% de pérdida del transportador.

NOTA DE VERIFICADOR:

Al igual que una única colisión con las ventanas.

Lo cual tiene bastante lógica tratándose de palomas 😀

La sección Overview comenta que las palomas mensajeras tienen gran retraso, bajo rendimiento y bajo servicio de altitud. Además agrega detalles de la topología centralizada de red.

La sección Frame Format describe el formato del datagrama IP: debe ser impreso en un pequeño rollo de papel, en hexadecimal, con cada octeto por separado. Este rollo se envuelve alrededor de la pata de la paloma transportadora, y el datagrama se asegura con cinta adhesiva. Añade que el ancho de banda está limitado por la longitud de la pata de la paloma, y que el MTU aumenta según la edad de la misma, siendo el MTU estándar de 256 miligramos (me sigo riendo XD).

Actualizaciones

Esta RFC fue actualizada por la 2549, que añade detalles de QoS al protocolo (Calidad de Servicio), e incorpora algunos gráficos ASCII muy sugerentes 😛

Finalmente, la RFC 6214 adapta la original a IPv6, muy interesante también XD

Para que tengan una idea, hablan de algoritmos de enrutamiento de palomas, consideraciones de tunneling, gestión de gusanos en al red, o ataques de denegación de servicio (DoS), o de problemas con virus como el H5N1.

Incluso las erratas de cada una de estas RFC son dignas de unos minutos… yo todavía me sigo riendo.

No me voy a extender mucho con esto, pero les recomiendo pasar a leerlas, no tienen desperdicio!

Como se comentó, la RFC no se elimina, se agregan nuevas RFC que la actualizan y corrigen detalles.

Referencias y otros detalles

En general si una RFC actualiza a otra, se verá una entrada «Updates: xxxx» en su cabecera. Aquí, por ejemplo, la RFC 2549 muestra lo siguiente (también marqué la categoría a la que pertenece):

En esta captura también puede verse, entre los enlaces de la barra superior, diferentes formatos de visualización. Entre ellos, uno muy interesante es el que dice bibtex. Ese es el formato de referencia bibliográfica para quien quiera añadir esta RFC a su biblioteca Zotero, o a su documento Latex directamente.

Por otro lado, las RFC’s pueden incluir referencias a otras RFC’s externas sobre las que se basan los conceptos tratados. Esto figura en un formato de dos columnas, la primera, el número de RFC entre corchetes, y la segunda, el/los autor/es, título y fecha de la RFC correspondiente. Aquí un ejemplo de referencias en la RFC 6214:

Implementación práctica

Sí, aunque parezca mentira, hay hasta implementaciones prácticas de este protocolo, con palomas y todo.

El 28 de abril de 2001 el mundo vio la primer implementación práctica del protocolo, en Noruega. Se usaron palomas mensajeras para enviar paquetes Ping (ICMP echo-request) y esperar sus respuestas (ICMP echo-reply). Imprimieron los paquetes, los enviaron con palomas, esperaron las respuestas, escanearon lo recibido, y decodificaron los mensajes.

El log del ping resultante es el siguiente:

Script started on Sat Apr 28 11:24:09 2001
vegard@gyversalen:~$ /sbin/ifconfig tun0
tun0      Link encap:Point-to-Point Protocol  
          inet addr:10.0.3.2  P-t-P:10.0.3.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:150  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 
          RX bytes:88 (88.0 b)  TX bytes:168 (168.0 b)

vegard@gyversalen:~$ ping -i 900 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

--- 10.0.3.1 ping statistics ---
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms
vegard@gyversalen:~$ exit

Script done on Sat Apr 28 14:14:28 2001

Sí, enviaron 9 mensajes, se recibieron 4, un 55% de mensajes perdidos, con un promedio de round-trip time de 5222806.6 milisegundos (sí, casi hora y media).

Si quieren divertirse un rato, vean el log completo del experimento, el código fuente del software utilizado, y fotos incluidas, en este link, sin desperdicio.

Conclusiones

Hemos aprendido qué son las RFC’s, esos documentos técnicos de texto plano que tiene siempre la información más fiable sobre detalles de protocolos de Internet.

Analizamos sus principales características por medio de las RFCs que describen el encapsulamiento de datagramas IP sobre palomas mensajeras, y nos divertimos un rato 🙂

¡Espero que les haya gustado! Y por supuesto, que les haya servido como introducción a las RFC, si es que no estaban interiorizados de estos documentos.

¡Será hasta la próxima!