Resumen

  • RFC 2784 separa cabecera de entrega, cabecera GRE y carga útil. Su base de cuatro octetos identifica el protocolo interior, pero no decide para qué existe el túnel, quién puede usarlo ni si lo transportado es seguro.
  • Tony Li coescribió el registro GRE de 1994 y la especificación Standards Track de 2000. Los RFC posteriores muestran la deuda operativa: Key es una etiqueta de contexto, no un secreto; Sequence Number introduce estado y riesgo de denegación; transportar IPv6 exige verificar MTU e integridad en los extremos.

Dos destinos no forman una sola ruta

En el ingress, el paquete original pasa a ser la carga. Delante se coloca una cabecera GRE y, por fuera, una cabecera de entrega. El underlay lee el destino exterior y lleva el conjunto al egress. Allí se retiran las capas exteriores y el destino interior recupera su función.

La operación produce tres registros diferentes. La entrega identifica los extremos del túnel. GRE declara qué clase de carga sigue y qué opciones están presentes. El paquete interior conserva origen, destino, tiempo de vida y significado de capa superior. Que la ruta exterior llegue no demuestra que exista la interior, que la carga esté autorizada o que el control de seguridad pueda verla después de desencapsular.

RFC 2784, publicado en marzo de 2000 como Standards Track, nombra a Dino Farinacci, Tony Li, Stan Hanks, David Meyer y Paul Traina. Sustituyó al Informational RFC 1701, firmado por Hanks, Li, Farinacci y Traina. El perfil público de Tony Li en IETF Datatracker aporta identidad, índice de RFC y funciones en la captura congelada. La prueba sostiene una contribución colectiva, no invención individual, empleador actual ni control personal de túneles desplegados.

La lectura centrada en la persona es más precisa: Li figura tanto en el diseño general inicial como en la especificación que redujo su núcleo común. La decisión duradera no fue gobernar todos los usos, sino fijar solo lo necesario para que implementaciones independientes pudieran encontrarse.

Un sobre común desarma la matriz de combinaciones

Si cada protocolo de carga necesita un método distinto sobre cada protocolo de entrega, el número de emparejamientos crece como una matriz. RFC 2784 denomina el problema O(n²) y propone una relación más manejable: carga, GRE común y entrega.

La generalidad tiene límites explícitos. Para servir a muchas combinaciones, el diseño ignora matices específicos; un mecanismo dedicado X sobre Y puede resultar mejor. Además, el documento se niega deliberadamente a resolver cuándo debe encapsularse un paquete. Define la gramática, no la justificación.

Una empresa puede unir redes privadas, un operador trasladar un servicio o un laboratorio ensayar un protocolo que el underlay desconoce. Ninguna finalidad queda legitimada por producir bytes conformes. Aún hay que identificar dueño, extremos, cargas admitidas, capacidad, seguridad y condición de retirada.

La reducción de coste no transfiere el riesgo. El mecanismo común ahorra implementación y coordinación, pero no paga por una fuga, un black hole, una inspección incompleta o una dependencia olvidada. Quien reutiliza GRE conserva las consecuencias operativas.

Cuatro octetos no esconden una autoridad

Sin checksum opcional, la cabecera base de RFC 2784 tiene dos palabras de 16 bits. La primera contiene el indicador de checksum, bits reservados y versión; la segunda es Protocol Type, el EtherType de la carga. La versión base es cero.

No aparecen propietario, identificador mundial de túnel, política, ruta, cifrado o promesa de servicio. Solo se explica cómo leer los bytes siguientes. Un Protocol Type desconocido debería descartarse. Los bits reservados se transmiten a cero y ciertas posiciones no nulas se rechazan cuando el receptor no implementa el comportamiento anterior.

El checksum opcional agrega cuatro octetos y cubre cabecera GRE más carga con la suma ordinaria de Internet. Detecta parte de la corrupción accidental; no autentica al emisor, no oculta contenido y no concede permiso. Un checksum válido jamás equivale por sí solo a un túnel confiable.

Una especificación mínima no deja todo ambiguo. Endurece las pocas afirmaciones que deben compartir ambos extremos y hace visibles las que continúan fuera de su autoridad.

Al abrir el sobre, la carga vuelve a gobernar su destino

Cuando el interior es IPv4, RFC 2784 exige reenviar según su dirección de destino y reducir su TTL. El destino exterior ya cumplió su tarea; no reemplaza la semántica del paquete transportado.

También existe una condición concreta de bucle. Si el destino interior es el encapsulador del otro extremo, el paquete puede volver a entrar en la misma relación y debe descartarse. Un túnel oculta topología, pero no anula el resultado de un loop.

El diagnóstico debe respetar esa separación. Un traceroute exterior puede alcanzar el egress sin ruta interior. La interfaz puede estar up mientras la carga cae tras la desencapsulación. Y un fallo atribuido a GRE puede pertenecer al underlay, al retorno, al filtro o al MTU. Los tres registros se observan por separado y se unen con evidencia del mismo tráfico.

El estándar nuevo redujo el núcleo

RFC 1701 permitía Routing, Key, Sequence, Strict Source Route y control de recursión. RFC 2784 tomó la intersección desplegada por varios fabricantes y retiró esas funciones del perfil base. Si un receptor no implementa expresamente la conducta antigua, descarta los bits correspondientes cuando aparecen activos.

La evolución no consistió en acumular opciones. El significado común se hizo menor para que implementaciones independientes acordaran menos cosas con mayor certeza. Una necesidad opcional podía volver mediante una extensión definida, no mediante conjeturas sobre espacio reservado.

La compatibilidad es entonces un límite de rechazo explicable. Aceptar un layout desconocido no resuelve que los extremos esperen capacidades distintas. Hay que probar la pareja, activar solo el perfil acordado y conservar un rollback al contrato anterior de parsing.

El campo Key no es una llave de seguridad

RFC 2890, cuyo autor es Govindan Dommety y no Li, definió después las extensiones Key y Sequence Number. El Key de cuatro octetos identifica un flujo o contexto lógico entre extremos; cómo se asigna queda fuera del documento.

El nombre es peligrosamente sugestivo. El RFC aclara que ese campo no interviene en seguridad. Puede distinguir cliente, servicio o flujo por acuerdo local, pero alguien capaz de construir GRE puede copiar o inventar el valor si otra capa no protege el paquete. Tratarlo como contraseña convierte una etiqueta en frontera de confianza ficticia.

Sequence Number aporta entrega no fiable pero ordenada. El receptor conserva la última cifra desencapsulada, rechaza anteriores y puede amortiguar desorden limitado. Algunas cargas se benefician, a costa de estado por flujo. Una inyección con valor alto puede hacer que tráfico legítimo parezca viejo.

RFC 2890 requiere IPsec AH o ESP frente a esa amenaza. También desaconseja duplicar orden cuando una capa superior ya lo ofrece o tolera reordenación. Activar la opción compromete memoria, buffer, contadores, logs y superficie de ataque en ambos extremos.

El filtrado debe situarse donde vuelve a verse el significado

RFC 2784 señala que el filtrado de rutas se parece al de IPv4 nativo, pero el filtrado de paquetes debe mirar dentro de GRE o realizarse en los extremos. El underlay puede permitir correctamente protocolo 47 entre dos direcciones sin saber protocolo, dirección o puerto interior.

Ahí surge un vacío frecuente. Transporte dice que la ruta exterior está restringida. Seguridad dice que el firewall acepta GRE solo entre los extremos. Servicio asume que su carga heredó las dos autorizaciones. En realidad, ninguno de los hechos exteriores define lo permitido después de abrir el túnel.

Un diseño auditable registra prefijos y protocolos interiores, lugar de desencapsulación, punto de inspección antes o después y uso efectivo de IPsec. GRE up no es un estado de seguridad. La prueba es la política aplicada en ambas capas al paquete real.

IPv6 convirtió omisiones en puertas de activación

RFC 7676, escrito por Carlos Pignataro, Ron Bonica y Suresh Krishnan, definió más tarde IPv6 como carga o entrega GRE. No es una obra de Li. Sirve para ver cómo las obligaciones locales emergen cuando el contrato delgado encuentra otra capa de red.

Un túnel que lleve carga IPv6 debe transportar un paquete de 1280 octetos desde ingress hasta egress sin fragmentar la carga. El ingress verifica esa capacidad antes de activar y periódicamente después, y activa o desactiva según el resultado. El GMTU es el MTU del camino entre extremos menos la entrega y el overhead GRE. Para una carga demasiado grande, en las condiciones descritas, se descarta y se devuelve ICMPv6 Packet Too Big con el valor utilizable.

La cabecera pequeña no elimina el tamaño. Hace calculable el overhead y coloca en el extremo la obligación de probar y retroalimentar. Si se pierde PTB, funcionan probes pequeños, se bloquean flujos grandes y el control puede seguir verde.

La integridad tiene otra frontera. Omitir checksum GRE evita cómputo redundante, pero la cabecera de entrega IPv6 no tiene checksum propio y el de GRE tampoco la cubriría. RFC 7676 analiza un caso raro: la corrupción del destino exterior entrega el paquete a otro PE; con direcciones privadas superpuestas y estado adecuado, la carga podría caer en el VPN equivocado. GRE sobre IPv6 no debe desplegarse donde el operador no acepte el riesgo; la autenticación extremo a extremo de la carga puede mitigarlo.

El RFC no demuestra que un despliegue concreto sufra el fallo. Establece una pregunta que el operador debe contestar antes de operar. Transporte genérico nunca significa seguridad genérica.

Coordinación delgada, evidencia gruesa en el borde

El texto posterior de Lu Heng Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption ofrece a Sofia Ren un marco para GRE. Lo común puede limitarse a layout, versión, tipo, extensiones y rechazo. Cada red conserva la libertad y la obligación de decidir propósito, extremos, admisión, seguridad y retiro.

Running-Code Primacy eleva la prueba. Un objeto de configuración expresa intención. La realidad une ruta exterior, flags emitidos, Protocol Type, overhead efectivo, contexto Key, asociación de seguridad, ruta interior, decisión de filtro, respuesta MTU, contadores y resultado de aplicación.

Los textos de Heng son un marco editorial posterior, no evidencia de intención privada de Li ni de consenso IETF fuera de los RFC citados. Ayudan a asignar responsabilidad: el estándar posee el sobre común; la implementación, parsing y estado; el operador, todas las razones para permitir su existencia.

GRE duró porque no gobierna la carga. Esa moderación lo hizo portable. También significa que dentro de cuatro octetos no existe institución alguna que rescate un despliegue descuidado. El sobre puede transportar casi cualquier cosa; solo sus extremos pueden probar qué debería transportar.

Fuentes