¿Por qué el campo de protocolo es parte de un encabezado IP?

Tenga en cuenta que esto no es un duplicado de ¿Por qué la capa IP es consciente de las capas superiores de la pila de red?

La necesidad de un identificador de protocolo (por ejemplo, el campo Protocolo del encabezado IP) en la comunicación basada en paquetes es clara: es este o algún tipo de algoritmo de inferencia computacionalmente intensivo. La pregunta es: ¿por qué debe existir como parte del encabezado IP en lugar de en los encabezados de los protocolos encapsulados?

Me parece que este es uno de esos casos donde la claridad teórica se encuentra con consideraciones prácticas (también conocido como "Haskell cumple Go" ...): Por un lado, colocar un campo de "protocolo" en el encabezado de IP rompe la separación conceptual de intereses que, por ejemplo . el modelo OSI destinado a por otro lado, forzar protocolos más altos en la pila para indicar su tipo de manera consistente es mucho más difícil y eventualmente conduciría a una situación similar de todos modos (por ejemplo, si cada protocolo más arriba en la pila usara su primer byte de encabezado para indicar su tipo , parecería que IP utilizó su último byte de encabezado para hacer lo mismo).

Entonces mi pregunta es: ¿cuál fue el razonamiento detrás de colocar el campo "protocolo" dentro del encabezado del paquete de la IP en lugar de en cualquier otro lugar?

Editar : Al escribir esta pregunta, reflexioné sobre si agregar la palabra " original " antes de "razonar", es decir, el razonamiento del equipo que ideó la propiedad intelectual , pero consideró que era redundante ya que la pregunta estaba redactada en tiempo pasado ("¿cuál era el razonamiento..."). Sin embargo, esto parece necesario, ya que ninguna de las respuestas responde a esa pregunta. Algunas ideas notables:

• @immibis sugiere que cualquier otra forma rompería los modelos de otros protocolos (por ejemplo, los protocolos de comunicación encriptados tendrían que tener un campo de identificación de texto sin formato)
• @Eddie esencialmente afirma que la razón es la convención (aceptación del diseño de la cadena de protocolo , aunque por qué esa es la convención sigue siendo un misterio)
• @Ricky enfatiza la practicidad como una consideración general
• @Claudio sugiere que si el campo de protocolo formara parte del encabezado encapsulado, se necesitaría un paso de identificación de encabezado adicional , en el modelo actual que tiene lugar durante el análisis del encabezado IP

Así que reformulo: ¿Qué tiene de malo un modelo en el que, en lugar de que cada encabezado identifique el tipo del siguiente encabezado, cada encabezado identifique su propio tipo en una ubicación predeterminada (por ejemplo, en el primer byte del encabezado)? ¿Por qué un modelo así es menos deseable que el actual?

Edición n. ° 2 : Parece que la respuesta es una combinación de varias de las respuestas dadas (principalmente las mencionadas anteriormente junto con el segundo apéndice de @ Eddie):

1. Simplicidad: romper el principio del agnosticismo de capa en este caso particular significa que la pila (o el modelo) en su conjunto puede ser más simple:

   • No hay fase de "identificación de protocolo", ni implícita ni explícita
   • Se mejora la independencia de la capa (por ejemplo, un controlador de comunicaciones encriptado no tiene que compartir una capa con ningún protocolo auxiliar)

   La regulación también se simplifica enormemente, ya que no tiene que imponer ningún requisito sobre los protocolos del cliente.

2. Rendimiento: establecer el protocolo de un paquete encapsulado antes del paquete en sí mismo permite que varios tipos de protocolos de enrutamiento rápido (filtrado de paquetes, QOS, conmutación de corte) se integren en la capa de red (Internet); estos pueden tomar decisiones tan rápido como se puede acceder a una tabla hash, lo cual es aún más importante teniendo en cuenta el hardware limitado para el que se diseñó este protocolo.

Este modelo tiene sus desventajas, pero parece que para los casos de uso comunes es más adecuado que las alternativas.

Recuerde, los bits llegan a una NIC como una serie de 1 y 0. Tiene que existir algo para dictar cómo deben interpretarse las siguientes series de 1 y 0.

Ethernet2 es el estándar de facto para L2, como tal se supone que interpreta los primeros 56 bits como un preámbulo, y los siguientes 8 bits como el preámbulo, y los siguientes 48 bits como el MAC de destino, y los siguientes 48 bits como la fuente MAC, y así sucesivamente .

La única variación podría ser el encabezado 802.3 L2 algo anticuado , que es anterior al estándar Ethernet2 actual, pero también incluía un encabezado SNAP que tenía el mismo propósito. Pero yo divago.

El encabezado estándar Ethernet2 L2 tiene un campo Tipo, que le dice al nodo receptor cómo interpretar los 1 y los 0 que siguen:

Sin esto, ¿cómo sabría la entidad receptora si el encabezado L3 es IP o IPv6? (o AppleTalk, o IPX, o IPv8, etc.)

El encabezado L3 (en el mismo marco que el anterior) tiene el campo Protocolo, que le dice al nodo receptor cómo interpretar el siguiente conjunto de 1 y 0 que sigue al encabezado IP:

Nuevamente, sin esto, ¿cómo sabría la entidad receptora interpretar esos bits como un paquete ICMP? También podría ser TCP, o UDP, o GRE, u otro encabezado IP, o una gran cantidad de otros.

Esto crea una especie de cadena de protocolo para indicar a la entidad receptora cómo interpretar el siguiente conjunto de bits. Sin esto, el extremo receptor tendría que usar heurística (u otra estrategia similar) para identificar primero el tipo de encabezado y luego interpretar y procesar los bits. Lo que agregaría una sobrecarga significativa en cada capa y un notable retraso en el procesamiento de paquetes.

En este punto, es tentador mirar el encabezado TCP o el encabezado UDP y señalar que esos encabezados no tienen un campo Tipo o Protocolo ... pero recuerde, una vez que TCP / UDP ha interpretado los bits, pasa su carga útil a la aplicación. Lo que sin duda probablemente tenga algún tipo de marcador para al menos identificar la versión del protocolo L5 +. Por ejemplo, HTTP tiene un número de versión integrado en las solicitudes HTTP: (1.0 frente a 1.1).

Edite para hablar con la edición del póster original:

¿Qué tiene de malo un modelo en el que, en lugar de que cada encabezado identifique el siguiente tipo de encabezado, cada encabezado identifique su propio tipo en una ubicación predeterminada (por ejemplo, en el primer byte del encabezado)? ¿Por qué un modelo así es menos deseable que el actual?

Antes de entrar en mi intento de respuesta, creo que vale la pena señalar que probablemente no haya una respuesta definitiva de un millón de dólares sobre por qué una forma es mejor o la otra. En ambos casos, el protocolo que se identifica frente al protocolo que identifica lo que encapsula, la entidad receptora podría interpretar los bits correctamente.

Dicho esto, creo que hay algunas razones por las que el protocolo que identifica el próximo encabezado tiene más sentido:

# 1

Si el estándar fuera el primer byte de cada encabezado para identificarse, esto sería establecer un estándar en todos los protocolos en cada capa. Lo que significa que si solo se dedica un byte, solo podríamos tener 256 protocolos. Incluso si dedicó dos bytes, eso lo limita a 65536. De cualquier manera, pone un límite arbitrario en la cantidad de protocolos que podrían desarrollarse.

Mientras que si un protocolo solo era responsable de interpretar el siguiente, e incluso si solo un byte estaba dedicado a cada campo de identificación de protocolo, al menos 'escala' ese máximo de 256 a cada capa.

# 2

Los protocolos que ordenan sus campos de tal manera que permiten a las entidades receptoras la opción de inspeccionar solo el mínimo para tomar una decisión solo existe si el siguiente campo de protocolo existe en el encabezado anterior.

Ethernet2 y conmutación " Cut-Through " vienen a la mente. Esto sería imposible si los primeros (pocos) bytes fueran forzados a ser un bloque de identificación de protocolo.

# 3

Por último, no quiero tomar el crédito, pero creo que la respuesta de @reirab en el comentario en los comentarios de la pregunta original es extremadamente viable:

Porque entonces es efectivamente el último byte del encabezado IPv4 (o cualquier protocolo de nivel inferior) en todo menos en el nombre. Es un problema de "pollo o huevo". No puede analizar un encabezado si no sabe qué protocolo es.

_{Citado con el permiso de Reirab}

También puede preguntar por qué un encabezado de Ethernet tiene un campo Tipo de Ether. La pila de red necesita saber qué protocolo en la siguiente capa superior obtiene la carga útil de la capa actual.

Editar 1:

La razón por la que cada datagrama tiene el protocolo de la siguiente capa superior es para crear la independencia de la capa. A cada capa no le importa lo que hay en la carga útil, y no debería tener que mirar en la carga útil para determinar dónde entregar la carga útil. Piense en el número de protocolo en el encabezado como una dirección donde se entregará la carga útil. Al igual que los números de puerto TCP son direcciones TCP, le dicen a TCP dónde entregar su carga útil.

La dirección MAC de destino le dice al conmutador de red qué interfaz de conmutador debe entregar la trama. El campo Tipo de Ether le dice a la capa 2 dónde entregar su carga útil, el campo Protocolo en el encabezado IP le dice a la capa 3 dónde entregar su carga útil, y los números de puerto en TCP y UDP le dicen a la capa 4 dónde entregar su carga útil.

Piense en un camionero de 18 ruedas que se conecta a un remolque para entregarlo en algún lugar. No necesita preocuparse por lo que hay en el tráiler o por lo que se usará; solo mira su papeleo y lo entrega al lugar en el papeleo.

Debe recordar que cada uno de los protocolos se desarrolló de forma independiente sin saber qué protocolos de capa superior emergentes se utilizarían. Durante mucho tiempo, el protocolo primario de capa 3 utilizado en Ethernet fue IPX. Si se hubiera creado Ethernet específicamente para IPX, ¿sería tan omnipresente hoy? Ethernet se creó para transportar cualquier protocolo de capa 3 al tener el campo Tipo de Ether que la pila de red puede usar para decidir a dónde va la carga útil de Ethernet. IP hace lo mismo, al igual que TCP y UDP. Es un método fácil y lógico, por lo que cada capa desarrollada independientemente en la pila de red tiene un equivalente. Usted y cualquier otra persona interesada son libres de desarrollar sus propios protocolos para cualquiera de las capas que pueden conectarse fácilmente a la pila de red debido a esto.

Edición 2:

Permite que diferentes protocolos de capa 3 se registren con la capa 2. Puede ejecutar simultáneamente protocolos IPX (0x8137), IPv4, (0x0800), ARP (0x0806), IPv6 (0x86DD), etc., y la capa 2 sabrá qué protocolos se han registrado con ella y pasará la carga útil a la capa adecuada. 3 protocolo sin saber nada acerca de la carga útil (o descartar cualquier paquete que no tenga un protocolo registrado). No es necesario que tenga que instalar un protocolo de capa 2 diferente para cada combinación de protocolos de capa 3 que tenga, y eso sería necesario si el protocolo de capa 2 debe saber más sobre los protocolos de capa 3 ) para poder leer los encabezados de los paquetes. Incluso los encabezados de paquetes IPv4 e IPv6 son bastante diferentes.

Aquí hay una lista incompleta de valores para diferentes protocolos de capa 3 que pueden registrarse con la capa 2.

Los protocolos de capa 4 también se registran con varios protocolos de capa 3, y las aplicaciones se registran con protocolos de capa 4.

Su pregunta original postulaba que las capas deberían ser independientes entre sí, y este tipo de cosas en realidad promueve la independencia de las capas, en lugar de romperlas como sugiere. Layer-2 no sabe que la carga útil es IPv4, solo sabe que el ethertype es 0x0800, y debe pasar la carga útil al protocolo de capa 3 que ha registrado ese ethertype.

No es una respuesta directa a su pregunta, pero:

Por un lado, colocar un campo de "protocolo" en el encabezado IP rompe la separación conceptual de intereses a la que apuntaba el OSI.

TCP / IP se desarrolló sin referencia al modelo OSI. Si bien comparten algunos puntos en común, fue un esfuerzo de desarrollo por separado.

La razón más simple es ayudar a analizar cuando se recibe un paquete.

Si sabe qué protocolo seguir, puede desarrollar una restricción más estricta. El único aspecto dinámico en el paquete IP es el tamaño (la presencia de opciones IP aumenta este tamaño en múltiplos de cuatro bytes).

En la fase de análisis, puede verificar la longitud del encabezado ip, el protocolo. Luego, en la validación de paquetes de bajo nivel, los datos del paquete se leen a través de una estructura de datos (generalmente, encabezados icmp, tcp, udp) y con un paquete fácil se valida.

Solo lee el título:

Cuando el paquete IP contiene datos TCP, el campo del número de protocolo tendrá el valor 6, por lo que la carga se enviará a la pila TCP, TCP luego usará los números de puerto para enviar los datos a la aplicación correcta. Lo mismo es para UDP con el protocolo número 17.

Otra forma de ver el campo de número de protocolo IP es que, si no tuviéramos este campo en el encabezado del paquete IP, IP solo sería capaz de transportar un tipo de datos, mientras que agregar este campo permitió que la IP transportara múltiples tipos de datos diferenciados por el número de protocolo, lo mismo ocurre con TCP / UDP usando puertos TCP / UDP para servir múltiples aplicaciones y Ethernet usando el Ethertype, y así sucesivamente.