Resumen

  • El Parameter Problem de IPv4 descartaba el datagrama inválido, pero su puntero de ocho bits podía identificar el octeto de la cabecera donde el procesamiento se detuvo.
  • ICMPv6 amplió el puntero a 32 bits y separó campo erróneo, Next Header desconocido y opción desconocida, con alcance sobre cadenas de extensiones.
  • El puntero puede quedar fuera de los bytes citados en la respuesta. Una coordenada exacta no autentica al emisor del error, no demuestra la causa última y nunca autoriza una lectura fuera del búfer.

Una coordenada en vez de una explicación genérica

RFC 792 describió en 1981 un caso preciso. Un host o una pasarela IPv4 encontraba un parámetro de cabecera que impedía terminar el procesamiento. El datagrama debía descartarse. Solo entonces podía enviar a la fuente ICMP tipo 12, Parameter Problem.

Con código 0, el campo Pointer de ocho bits identificaba el octeto de la cabecera original donde se había detectado el error. Un valor 1 podía apuntar al antiguo Type of Service; si había opciones, 20 podía señalar el tipo de la primera. La posición incluso podía caer en medio de una opción. El receptor no enviaba una teoría sobre la intención del origen: declaraba el punto al que había llegado su lector.

La respuesta incluía también la cabecera Internet y los primeros 64 bits de datos. Esos ocho octetos solían bastar para recuperar puertos de TCP o UDP y relacionar el error con un proceso. La cita daba identidad contextual al tráfico; el puntero daba ubicación al fallo.

Nada de ello garantizaba una respuesta. ICMP era retroalimentación sobre problemas, no una capa de fiabilidad. El propio error podía perderse, filtrarse o no generarse por las restricciones del protocolo. El silencio nunca equivalió a aceptación.

El diagnóstico entra en la responsabilidad del host

RFC 1122 convirtió el formato en comportamiento. Si el sistema podía identificar el proceso que originó el paquete, debía hacer llegar la información pertinente. En TCP, Parameter Problem debía comunicarse, no interpretarse sin contexto como una orden inevitable de destruir la conexión. La capa que conserva el estado decide qué significa para esa operación.

El documento de 1989 trató además el coste de registrar paquetes extraños. Guardar cabeceras favorece el diagnóstico en una red heterogénea, pero una corriente de anomalías no puede consumir recursos ilimitados. Esa tensión reaparece en el tamaño de las citas: suficiente evidencia para investigar, nunca una obligación de devolver el paquete entero.

RFC 1812 detalló la conducta de los routers IPv4. Un datagrama inválido se descarta y normalmente se registra. Si parte de la cabecera aún puede examinarse con seguridad, un router puede responder apuntando a Internet Header Length o Total Length. Sin embargo, un fallo allí puede proceder de truncamiento de enlace, corrupción, otra versión de IP o una construcción ilegal del origen. La coordenada no resuelve por sí sola esa causalidad.

La cita pudo crecer hasta todo lo que cupiera sin superar el búfer mínimo de reensamblado IPv4 de 576 bytes. El límite impedía que explicar un paquete defectuoso se convirtiera en amplificación ilimitada.

IPv6 desplaza el problema a una cadena

El máximo de 60 bytes de una cabecera IPv4 hacía suficiente un puntero de un octeto. IPv6 fijó una cabecera base de 40 bytes y trasladó la información opcional a cabeceras de extensión enlazadas por valores Next Header. El error podía estar mucho más lejos.

RFC 2463 definió en 1998 ICMPv6 Parameter Problem con tipo 4 y Pointer de 32 bits. El valor es el desplazamiento en octetos desde el comienzo del paquete invocador. Código 0 significa campo de cabecera erróneo; código 1, Next Header no reconocido; código 2, opción IPv6 no reconocida. RFC 4443 conservó la estructura en 2006.

El ejemplo de código 1 y puntero 40 muestra la semántica: el valor Next Header inmediatamente posterior a la cabecera base no se pudo interpretar. El 40 no mide saltos ni gravedad. Nombra una posición.

RFC 8200 vincula esa posición con el orden. Las extensiones se procesan como aparecen; no se puede saltar una transición desconocida y buscar más adelante algo familiar. Cuando un destino debe continuar y no conoce el Next Header actual, descarta y señala precisamente ese valor. Las acciones de las opciones desconocidas pueden usar el código 2, pero su contrato de bits es un tema distinto.

Así, el puntero conserva el primer límite de comprensión, no una certificación del resto. Los campos posteriores quizá ni siquiera fueron examinados.

El número llega más lejos que la cita

Un error ICMPv6 debe devolver tanto del paquete invocador como sea posible sin superar la MTU mínima de IPv6. Con extensiones largas, el campo que causó el rechazo puede quedar fuera de esa porción.

RFC 4443 mantiene el desplazamiento real aunque apunte más allá de los bytes adjuntos. La fuente recibe una afirmación precisa sobre la posición N, junto con una ausencia igualmente importante: la respuesta no contiene el octeto N.

Reducir el valor al final de la cita acusaría a otro campo. Aumentar la respuesta sin límite rompería el control de recursos. El diseño no elimina la incertidumbre; la sitúa. Por eso una implementación debe comparar Pointer con la longitud real antes de usarlo como índice de memoria.

La cita también puede terminar antes del protocolo superior. En tal caso, el host receptor quizá no pueda elegir el proceso al que notificar y termine descartando el error después del procesamiento IPv6. Localizar el límite de red no garantiza que la aplicación reciba el informe.

Una sintaxis válida también puede superar una capacidad local

RFC 8883 añadió en 2020 códigos 5 a 10. Cubren un Next Header desconocido en un nodo intermedio y límites sobre tamaño de una extensión, longitud total de la cadena, cantidad de cabeceras, cantidad de opciones o tamaño de una opción. El Pointer marca el valor desconocido, el primer octeto fuera del límite o el primer elemento que excede un recuento.

Aquí el paquete puede estar bien formado. Lo que falla es el presupuesto local de análisis. El código declara qué clase de límite alcanzó ese nodo; el desplazamiento muestra dónde. Otro dispositivo puede disponer de otra capacidad.

La diferencia evita presentar una limitación de implementación como invalidez universal. También evita exigir a todo router recursos infinitos para cualquier cadena legal. El rechazo se vuelve observable y atribuible, sin convertirlo en una verdad global.

RFC 8883 explicita la disciplina de memoria: antes de leer usando el puntero, el receptor debe confirmar que el valor está dentro de los datos citados. Una coordenada válida en el espacio del paquete no crea bytes dentro del búfer local.

Un mensaje exacto todavía puede ser falso

ICMP no queda autenticado por defecto. RFC 4443 analiza suplantación de origen, modificación de campos, denegación de servicio y manipulación de capas superiores. La reacción debe correlacionar direcciones, protocolo, puertos y tráfico efectivamente enviado. El informe es una pieza de evidencia, no una autoridad aislada.

Los errores ICMPv6 además deben limitarse por tasa. Una fuente que insiste con paquetes erróneos no puede obligar al receptor a responder sin fin. Las reglas de multidifusión, los filtros y la pérdida ordinaria añaden silencio. Recibir Parameter Problem demuestra que alguien formuló ese informe; no recibirlo no demuestra que todos procesaron el paquete.

La aportación duradera fue separar cuatro planos: descarte, clase de causa, ubicación y contexto citado. Cada uno tiene un responsable y un límite. El protocolo fue útil porque su exactitud no pretendió ser omnisciencia.

Fuentes