Conjunto de protocolos de internet

El conjunto de protocolos de Internet, comúnmente conocido como TCP/IP, es un marco para organizar el conjunto de protocolos de comunicación utilizados en Internet y redes informáticas similares de acuerdo con funciones criterios. Los protocolos fundamentales de la suite son el Protocolo de control de transmisión (TCP), el Protocolo de datagramas de usuario (UDP) y el Protocolo de Internet (IP). En el desarrollo de este modelo de red, las primeras versiones del mismo se conocían como el modelo del Departamento de Defensa (DoD) porque la investigación y el desarrollo eran financiado por el Departamento de Defensa de los Estados Unidos a través de DARPA.

El conjunto de protocolos de Internet proporciona comunicación de datos de extremo a extremo que especifica cómo se deben empaquetar, direccionar, transmitir, enrutar y recibir los datos. Esta funcionalidad está organizada en cuatro capas de abstracción, que clasifican todos los protocolos relacionados según el alcance de la red de cada protocolo. Una implementación de las capas para una aplicación particular forma una pila de protocolos. De menor a mayor, las capas son la capa de enlace, que contiene métodos de comunicación para los datos que permanecen dentro de un solo segmento de red (enlace); la capa de Internet, que proporciona interconexión de redes entre redes independientes; la capa de transporte, que maneja la comunicación de host a host; y la capa de aplicación, que proporciona intercambio de datos de proceso a proceso para las aplicaciones.

Los estándares técnicos subyacentes al conjunto de protocolos de Internet y sus protocolos constituyentes son mantenidos por el Grupo de Trabajo de Ingeniería de Internet (IETF). El conjunto de protocolos de Internet es anterior al modelo OSI, un marco de referencia más completo para los sistemas de redes generales.

Historia

Investigaciones iniciales

Diagrama de la primera conexión por Internet

Un SRI International Packet Radio Van, utilizado para la primera transmisión por Internet de tres vías.

Inicialmente denominado Modelo de arquitectura de Internet DOD, el conjunto de protocolos de Internet tiene sus raíces en la investigación y el desarrollo patrocinado por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) a fines de la década de 1960. Después de que DARPA iniciara el ARPANET pionero en 1969, Steve Crocker estableció un "Grupo de Trabajo de Redes" que desarrolló un protocolo host-host, el Programa de control de red (NCP). A principios de la década de 1970, DARPA comenzó a trabajar en varias otras tecnologías de transmisión de datos, incluida la radio móvil por paquetes, el servicio satelital por paquetes, las redes de área local y otras redes de datos en los dominios público y privado. En 1972, Bob Kahn se unió a la Oficina de Tecnología de Procesamiento de la Información de DARPA, donde trabajó tanto en redes de paquetes satelitales como en redes de paquetes de radio terrestres, y reconoció el valor de poder comunicarse a través de ambos. En la primavera de 1973, Vinton Cerf se unió a Kahn para trabajar en modelos de interconexión de arquitectura abierta con el objetivo de diseñar la próxima generación de protocolos para ARPANET. Se basaron en la experiencia de la comunidad de investigación de ARPANET y el Grupo de Trabajo de Redes Internacionales, que presidió Cerf.

Para el verano de 1973, Kahn y Cerf habían elaborado una reformulación fundamental, en la que las diferencias entre los protocolos de red local se ocultaban mediante el uso de un protocolo de red común y, en lugar de que la red fuera responsable de la confiabilidad, como en el protocolos ARPANET existentes, esta función fue delegada a los hosts. Cerf acredita a Hubert Zimmermann y Louis Pouzin, diseñador de la red CYCLADES, con importantes influencias en este diseño. El nuevo protocolo se implementó como el Programa de Control de Transmisión en 1974.

Inicialmente, el Programa de Control de Transmisión (el Protocolo de Internet no existía entonces como un protocolo separado) solo proporcionaba un servicio de flujo de bytes confiable a sus usuarios, no un datagrama. A medida que creció la experiencia con el protocolo, los colaboradores recomendaron la división de la funcionalidad en capas de distintos protocolos, lo que permite a los usuarios acceder directamente al servicio de datagramas. Los defensores incluyeron a Danny Cohen, quien lo necesitaba para su trabajo de paquetes de voz; Jonathan Postel del Instituto de Ciencias de la Información de la Universidad del Sur de California, quien editó la Solicitud de comentarios (RFC), la serie de documentos técnicos y estratégicos que ha documentado y catalizado el desarrollo de Internet; y el grupo de investigación de Robert Metcalfe en Xerox PARC. Postel declaró: "Estamos metiendo la pata en nuestro diseño de protocolos de Internet al violar el principio de estratificación". La encapsulación de diferentes mecanismos tenía como objetivo crear un entorno en el que las capas superiores pudieran acceder solo a lo que se necesitaba de las capas inferiores. Un diseño monolítico sería inflexible y daría lugar a problemas de escalabilidad. En la versión 3 de TCP, escrita en 1978, Cerf, Cohen y Postel dividieron el Programa de control de transmisión en dos protocolos distintos, el Protocolo de Internet como capa sin conexión y el Protocolo de control de transmisión como un servicio confiable orientado a la conexión.

El diseño de la red incluía el reconocimiento de que solo debería proporcionar las funciones de transmisión y enrutamiento eficientes del tráfico entre los nodos finales y que toda la demás inteligencia debería ubicarse en el borde de la red, en los nodos finales. Este diseño se conoce como el principio de extremo a extremo. Usando este diseño, fue posible conectar otras redes a ARPANET que usaban el mismo principio, independientemente de otras características locales, resolviendo así el problema inicial de interconexión de redes de Kahn. Una expresión popular es que TCP/IP, el producto final del trabajo de Cerf y Kahn, puede funcionar con "dos latas y una cuerda". Años más tarde, como una broma, se creó y probó con éxito la especificación del protocolo formal IP over Avian Carriers.

DARPA contrató a BBN Technologies, la Universidad de Stanford y el University College London para desarrollar versiones operativas del protocolo en varias plataformas de hardware. Durante el desarrollo del protocolo, el número de versión de la capa de enrutamiento de paquetes pasó de la versión 1 a la versión 4, la última de las cuales se instaló en ARPANET en 1983. Se conoció como Protocolo de Internet versión 4 (IPv4) como el protocolo que todavía está en uso en Internet, junto con su sucesor actual, el Protocolo de Internet versión 6 (IPv6).

Implementación temprana

En 1975, Stanford y University College London realizaron una prueba de comunicaciones IP de dos redes. En noviembre de 1977, se realizó una prueba de IP de tres redes entre sitios en los EE. UU., el Reino Unido y Noruega. Varios otros prototipos de IP se desarrollaron en múltiples centros de investigación entre 1978 y 1983.

Se proporciona una computadora llamada enrutador con una interfaz para cada red. Reenvía paquetes de red de un lado a otro entre ellos. Originalmente, un enrutador se llamaba puerta de enlace, pero el término se cambió para evitar confusiones con otros tipos de puertas de enlace.

Adopción

En marzo de 1982, el Departamento de Defensa de EE. UU. declaró que TCP/IP era el estándar para todas las redes informáticas militares. En el mismo año, NORSAR y el grupo de investigación de Peter Kirstein en el University College London adoptaron el protocolo. La migración de ARPANET de NCP a TCP/IP se completó oficialmente el día de la bandera el 1 de enero de 1983, cuando los nuevos protocolos se activaron de forma permanente.

En 1985, la Junta Asesora de Internet (más tarde la Junta de Arquitectura de Internet) realizó un taller de TCP/IP de tres días para la industria informática, al que asistieron 250 representantes de proveedores, promoviendo el protocolo y conduciendo a su creciente uso comercial. En 1985, la primera conferencia Interop se centró en la interoperabilidad de la red mediante una adopción más amplia de TCP/IP. La conferencia fue fundada por Dan Lynch, uno de los primeros activistas de Internet. Desde el principio asistieron a la reunión grandes corporaciones, como IBM y DEC.

IBM, AT&T y DEC fueron las primeras corporaciones importantes en adoptar TCP/IP, a pesar de tener protocolos propietarios en competencia. En IBM, desde 1984, el grupo de Barry Appelman realizó el desarrollo de TCP/IP. Navegaron por la política corporativa para obtener un flujo de productos TCP/IP para varios sistemas de IBM, incluidos MVS, VM y OS/2. Al mismo tiempo, varias empresas más pequeñas, como FTP Software y Wollongong Group, comenzaron a ofrecer paquetes TCP/IP para DOS y Microsoft Windows. La primera pila TCP/IP de VM/CMS provino de la Universidad de Wisconsin.

Algunas de las primeras pilas de TCP/IP fueron escritas sin ayuda de unos pocos programadores. Jay Elinsky y Oleg Vishnepolsky [ru] de IBM Research escribieron pilas TCP/IP para VM/CMS y OS/2, respectivamente. En 1984, Donald Gillies en el MIT escribió un TCP de conexión múltiple ntcp que se ejecuta sobre la capa IP/PacketDriver mantenida por John Romkey en el MIT en 1983–4. Romkey aprovechó este TCP en 1986 cuando se fundó FTP Software. A partir de 1985, Phil Karn creó una aplicación TCP de conexión múltiple para sistemas de radioaficionados (KA9Q TCP).

La difusión de TCP/IP se impulsó aún más en junio de 1989, cuando la Universidad de California, Berkeley, acordó colocar el código TCP/IP desarrollado para BSD UNIX en el dominio público. Varios proveedores corporativos, incluido IBM, incluyeron este código en versiones comerciales de software TCP/IP. Microsoft lanzó una pila TCP/IP nativa en Windows 95. Este evento ayudó a consolidar el dominio de TCP/IP sobre otros protocolos en las redes basadas en Microsoft, que incluían la Arquitectura de red de sistemas (SNA) de IBM y en otros plataformas como DECnet de Digital Equipment Corporation, Open Systems Interconnection (OSI) y Xerox Network Systems (XNS).

Sin embargo, durante un período a fines de la década de 1980 y principios de la de 1990, los ingenieros, las organizaciones y las naciones estaban polarizados sobre la cuestión de qué estándar, el modelo OSI o el conjunto de protocolos de Internet, daría como resultado las mejores y más sólidas redes informáticas.

Especificación formal y estándares

Los estándares técnicos subyacentes al conjunto de protocolos de Internet y sus protocolos constituyentes se han delegado al Grupo de Trabajo de Ingeniería de Internet (IETF).

La arquitectura característica de Internet Protocol Suite es su amplia división en ámbitos operativos para los protocolos que constituyen su funcionalidad central. La especificación que define la suite es RFC 1122, que describe en términos generales cuatro capas de abstracción. Estos han resistido la prueba del tiempo, ya que el IETF nunca ha modificado esta estructura. Como tal modelo de redes, Internet Protocol Suite es anterior al modelo OSI, un marco de referencia más completo para los sistemas de redes generales.

Principios arquitectónicos clave

Flujo de datos conceptuales en una topología de red simple de dos anfitriones (A y B) conectado por un enlace entre sus respectivos routers. La aplicación en cada host ejecuta operaciones de lectura y escritura como si los procesos estuvieran directamente conectados entre sí por algún tipo de tubo de datos. Después del establecimiento de esta tubería, la mayoría de los detalles de la comunicación se ocultan de cada proceso, ya que los principios subyacentes de la comunicación se aplican en las capas de protocolo inferiores. En analogía, en la capa de transporte la comunicación aparece como host-to-host, sin conocimiento de las estructuras de datos de la aplicación y de los routers de conexión, mientras que en la capa de internetworking, los límites de red individuales se atraviesan en cada router.

Encapsulación de datos de aplicación descendiendo a través de las capas descritas en RFC 1122

El principio de extremo a extremo ha evolucionado con el tiempo. Su expresión original puso el mantenimiento del estado y la inteligencia general en los bordes, y asumió que Internet que conectaba los bordes no conservaba el estado y se concentraba en la velocidad y la simplicidad. Las necesidades del mundo real de firewalls, traductores de direcciones de red, cachés de contenido web y similares han forzado cambios en este principio.

El principio de solidez establece: "En general, una implementación debe ser conservadora en su comportamiento de envío y liberal en su comportamiento de recepción. Es decir, debe tener cuidado de enviar datagramas bien formados, pero debe aceptar cualquier datagrama que pueda interpretar (p. ej., no objetar los errores técnicos donde el significado aún es claro)." "La segunda parte del principio es casi igual de importante: el software en otros hosts puede contener deficiencias que hacen que no sea prudente explotar funciones de protocolo legales pero oscuras."

La encapsulación se utiliza para proporcionar abstracción de protocolos y servicios. La encapsulación generalmente se alinea con la división del conjunto de protocolos en capas de funcionalidad general. En general, una aplicación (el nivel más alto del modelo) utiliza un conjunto de protocolos para enviar sus datos a las capas. Los datos se encapsulan aún más en cada nivel.

Un documento arquitectónico temprano, RFC 1122, enfatiza los principios arquitectónicos sobre las capas. RFC 1122, titulado Requisitos del host, está estructurado en párrafos que se refieren a las capas, pero el documento hace referencia a muchos otros principios arquitectónicos y no enfatiza las capas. Define vagamente un modelo de cuatro capas, con las capas que tienen nombres, no números, de la siguiente manera:

• La capa de aplicación es el alcance dentro del cual las aplicaciones, o procesos, crean datos de usuario y comunican estos datos a otras aplicaciones en otro o el mismo host. Las aplicaciones utilizan los servicios proporcionados por las capas inferiores subyacentes, especialmente la capa de transporte que proporciona fiabilidad o fiabilidad tuberías a otros procesos. Los socios de comunicaciones se caracterizan por la arquitectura de la aplicación, como el modelo cliente-servidor y las redes entre pares. Esta es la capa en la que operan todos los protocolos de aplicación, como SMTP, FTP, SSH, HTTP. Los procesos se abordan a través de puertos que representan esencialmente servicios.
• La capa de transporte realiza comunicaciones host-to-host en la red local o redes remotas separadas por los routers. Proporciona un canal para las necesidades de comunicación de las aplicaciones. UDP es el protocolo básico de capa de transporte, proporcionando un servicio de datagramas sin conexión no confiable. El Protocolo de Control de Transmisiones proporciona control de flujo, establecimiento de conexiones y transmisión fiable de datos.
• La capa de Internet intercambia datagramas a través de los límites de red. Proporciona una interfaz de red uniforme que oculta la topología real (capa) de las conexiones de red subyacentes. Por lo tanto, es también la capa que establece el internetworking. De hecho, define y establece Internet. Esta capa define las estructuras de dirección y enrutamiento utilizadas para la suite protocolo TCP/IP. El protocolo primario en este ámbito es el Protocolo de Internet, que define direcciones IP. Su función en la ruta es transportar datagramas al próximo host, funcionando como router IP, que tiene la conectividad a una red más cercana al destino final de datos.
• La capa de enlace define los métodos de networking dentro del alcance del enlace de red local en el que los anfitriones se comunican sin intervenir en los routers. Esta capa incluye los protocolos utilizados para describir la topología de la red local y las interfaces necesarias para afectar la transmisión de los datagramas de la capa de Internet a los anfitriones de próximo vecindario.

Capa de enlace

Los protocolos de la capa de enlace operan dentro del alcance de la conexión de red local a la que está conectado un host. Este régimen se denomina enlace en el lenguaje TCP/IP y es la capa de componentes más baja de la suite. El enlace incluye todos los hosts accesibles sin atravesar un enrutador. Por lo tanto, el tamaño del enlace está determinado por el diseño del hardware de red. En principio, TCP/IP está diseñado para ser independiente del hardware y puede implementarse sobre prácticamente cualquier tecnología de capa de enlace. Esto incluye no solo implementaciones de hardware, sino también capas de enlace virtual, como redes privadas virtuales y túneles de red.

La capa de enlace se utiliza para mover paquetes entre las interfaces de la capa de Internet de dos hosts diferentes en el mismo enlace. Los procesos de transmisión y recepción de paquetes en el enlace se pueden controlar en el controlador del dispositivo para la tarjeta de red, así como en el firmware o mediante conjuntos de chips especializados. Estos realizan funciones, como tramas, para preparar los paquetes de la capa de Internet para la transmisión y, finalmente, transmiten las tramas a la capa física ya través de un medio de transmisión. El modelo TCP/IP incluye especificaciones para traducir los métodos de direccionamiento de red utilizados en el Protocolo de Internet a direcciones de capa de enlace, como direcciones de control de acceso a medios (MAC). Sin embargo, se asume implícitamente que todos los demás aspectos por debajo de ese nivel existen y no están definidos explícitamente en el modelo TCP/IP.

La capa de enlace en el modelo TCP/IP tiene funciones correspondientes en la Capa 2 del modelo OSI.

Capa de Internet

Internetworking requiere el envío de datos desde la red de origen a la red de destino. Este proceso se denomina enrutamiento y está respaldado por el direccionamiento y la identificación del host mediante el sistema de direccionamiento IP jerárquico. La capa de Internet proporciona una instalación de transmisión de datagramas poco confiable entre hosts ubicados en redes IP potencialmente diferentes al reenviar datagramas a un enrutador de siguiente salto apropiado para su posterior retransmisión a su destino. La capa de Internet tiene la responsabilidad de enviar paquetes a través de redes potencialmente múltiples. Con esta funcionalidad, la capa de Internet hace posible el trabajo en red, el interfuncionamiento de diferentes redes IP, y esencialmente establece Internet.

La capa de Internet no distingue entre los distintos protocolos de la capa de transporte. IP transporta datos para una variedad de diferentes protocolos de capa superior. Cada uno de estos protocolos se identifica con un número de protocolo único: por ejemplo, el Protocolo de mensajes de control de Internet (ICMP) y el Protocolo de administración de grupos de Internet (IGMP) son los protocolos 1 y 2, respectivamente.

El Protocolo de Internet es el componente principal de la capa de Internet y define dos sistemas de direccionamiento para identificar hosts de red y ubicarlos en la red. El sistema de direcciones original de ARPANET y su sucesor, Internet, es el Protocolo de Internet versión 4 (IPv4). Utiliza una dirección IP de 32 bits y, por lo tanto, es capaz de identificar aproximadamente cuatro mil millones de hosts. Esta limitación se eliminó en 1998 con la estandarización del Protocolo de Internet versión 6 (IPv6), que utiliza direcciones de 128 bits. Las implementaciones de producción de IPv6 surgieron aproximadamente en 2006.

Capa de transporte

La capa de transporte establece canales de datos básicos que las aplicaciones utilizan para el intercambio de datos específicos de tareas. La capa establece conectividad de host a host en forma de servicios de transferencia de mensajes de extremo a extremo que son independientes de la red subyacente y de la estructura de los datos del usuario y la logística del intercambio de información. La conectividad en la capa de transporte se puede categorizar como orientada a la conexión, implementada en TCP, o sin conexión, implementada en UDP. Los protocolos de esta capa pueden proporcionar control de errores, segmentación, control de flujo, control de congestión y direccionamiento de aplicaciones (números de puerto).

Con el fin de proporcionar canales de transmisión específicos de procesos para aplicaciones, la capa establece el concepto de puerto de red. Esta es una construcción lógica numerada asignada específicamente para cada uno de los canales de comunicación que necesita una aplicación. Para muchos tipos de servicios, estos números de puerto se han estandarizado para que las computadoras cliente puedan abordar servicios específicos de una computadora servidor sin la participación de servicios de directorio o descubrimiento de servicios.

Debido a que IP proporciona solo una entrega de mejor esfuerzo, algunos protocolos de la capa de transporte ofrecen confiabilidad.

TCP es un protocolo orientado a la conexión que aborda numerosos problemas de confiabilidad al proporcionar un flujo de bytes confiable:

• data arrives in-order
• los datos tienen un error mínimo (es decir, corrección)
• los datos duplicados se descartan
• paquetes perdidos o descartados son resentidos
• incluye control de la congestión de tráfico

El nuevo Protocolo de transmisión de control de flujo (SCTP) también es un mecanismo de transporte confiable y orientado a la conexión. Está orientado al flujo de mensajes, no al flujo de bytes como TCP, y proporciona múltiples flujos multiplexados en una sola conexión. También proporciona compatibilidad con multihoming, en el que el final de una conexión puede representarse mediante varias direcciones IP (que representan varias interfaces físicas), de modo que si una falla, la conexión no se interrumpe. Fue desarrollado inicialmente para aplicaciones de telefonía (para transportar SS7 sobre IP).

La confiabilidad también se puede lograr mediante la ejecución de IP sobre un protocolo de enlace de datos confiable, como el control de enlace de datos de alto nivel (HDLC).

El Protocolo de datagramas de usuario (UDP) es un protocolo de datagramas sin conexión. Al igual que IP, es un protocolo de mejor esfuerzo y poco confiable. La confiabilidad se aborda a través de la detección de errores utilizando un algoritmo de suma de verificación. UDP se usa normalmente para aplicaciones como transmisión de medios (audio, video, voz sobre IP, etc.) donde la llegada a tiempo es más importante que la confiabilidad, o para aplicaciones simples de consulta/respuesta como búsquedas de DNS, donde la sobrecarga de configurar un conexión confiable es desproporcionadamente grande. El protocolo de transporte en tiempo real (RTP) es un protocolo de datagramas que se usa sobre UDP y está diseñado para datos en tiempo real, como la transmisión de medios.

Las aplicaciones en cualquier dirección de red determinada se distinguen por su puerto TCP o UDP. Por convención, ciertos puertos bien conocidos están asociados con aplicaciones específicas.

La capa de transporte o de host a host del modelo TCP/IP corresponde aproximadamente a la cuarta capa del modelo OSI, también denominada capa de transporte.

QUIC está emergiendo rápidamente como un protocolo de transporte alternativo. Si bien técnicamente se transporta a través de paquetes UDP, busca ofrecer una conectividad de transporte mejorada en relación con TCP. HTTP/3 funciona exclusivamente a través de QUIC.

Capa de aplicación

La capa de aplicación incluye los protocolos utilizados por la mayoría de las aplicaciones para proporcionar servicios de usuario o intercambiar datos de aplicaciones a través de las conexiones de red establecidas por los protocolos de nivel inferior. Esto puede incluir algunos servicios básicos de soporte de red, como protocolos de enrutamiento y configuración de host. Los ejemplos de protocolos de capa de aplicación incluyen el Protocolo de transferencia de hipertexto (HTTP), el Protocolo de transferencia de archivos (FTP), el Protocolo simple de transferencia de correo (SMTP) y el Protocolo de configuración dinámica de host (DHCP). Los datos codificados de acuerdo con los protocolos de la capa de aplicación se encapsulan en unidades de protocolo de la capa de transporte (como flujos TCP o datagramas UDP), que a su vez utilizan protocolos de capa inferior para efectuar la transferencia de datos real.

El modelo TCP/IP no tiene en cuenta los aspectos específicos del formato y la presentación de datos y no define capas adicionales entre las capas de aplicación y transporte como en el modelo OSI (capas de presentación y sesión). De acuerdo con el modelo TCP/IP, tales funciones son el ámbito de las bibliotecas y las interfaces de programación de aplicaciones. La capa de aplicación en el modelo TCP/IP a menudo se compara con una combinación de las capas quinta (sesión), sexta (presentación) y séptima (aplicación) del modelo OSI.

Los protocolos de capa de aplicación a menudo se asocian con aplicaciones cliente-servidor particulares, y los servicios comunes tienen números de puerto bien conocidos reservados por la Autoridad de Números Asignados de Internet (IANA). Por ejemplo, el Protocolo de transferencia de hipertexto usa el puerto de servidor 80 y Telnet usa el puerto de servidor 23. Los clientes que se conectan a un servicio generalmente usan puertos efímeros, es decir, números de puerto asignados solo durante la transacción al azar o de un rango específico configurado en el solicitud.

En la capa de aplicación, el modelo TCP/IP distingue entre protocolos de usuario y protocolos de soporte. Los protocolos de soporte brindan servicios a un sistema de infraestructura de red. Los protocolos de usuario se utilizan para aplicaciones de usuario reales. Por ejemplo, FTP es un protocolo de usuario y DNS es un protocolo de soporte.

Aunque las aplicaciones suelen conocer las cualidades clave de la conexión de la capa de transporte, como las direcciones IP y los números de puerto del extremo, los protocolos de la capa de aplicación generalmente tratan los protocolos de la capa de transporte (y los inferiores) como cajas negras que brindan una conexión de red estable a través de que comunicar. La capa de transporte y las capas de nivel inferior no se preocupan por los detalles de los protocolos de la capa de aplicación. Los enrutadores y conmutadores normalmente no examinan el tráfico encapsulado, sino que simplemente proporcionan un conducto para ello. Sin embargo, algunas aplicaciones de limitación de ancho de banda y cortafuegos utilizan una inspección profunda de paquetes para interpretar los datos de la aplicación. Un ejemplo es el Protocolo de reserva de recursos (RSVP). A veces, también es necesario que las aplicaciones afectadas por NAT consideren la carga útil de la aplicación.

Evolución de capas y representaciones en la literatura

El conjunto de protocolos de Internet evolucionó a través de la investigación y el desarrollo financiados durante un período de tiempo. En este proceso, cambiaron los detalles de los componentes del protocolo y sus capas. Además, los intereses comerciales y de investigación paralelos de las asociaciones industriales competían con las características del diseño. En particular, los esfuerzos en la Organización Internacional de Normalización condujeron a un objetivo similar, pero con un alcance más amplio de creación de redes en general. Los esfuerzos por consolidar las dos escuelas principales de estratificación, que eran superficialmente similares, pero que diferían mucho en los detalles, llevaron a los autores independientes de libros de texto a formular herramientas didácticas abreviadas.

La siguiente tabla muestra varios de estos modelos de red. El número de capas varía entre tres y siete.

Algunos de los modelos de red provienen de libros de texto, que son fuentes secundarias que pueden entrar en conflicto con la intención de RFC 1122 y otras fuentes primarias de IETF.

Comparación de capas TCP/IP y OSI

Las tres capas superiores del modelo OSI, es decir, la capa de aplicación, la capa de presentación y la capa de sesión, no se distinguen por separado en el modelo TCP/IP, que solo tiene una capa de aplicación por encima de la capa de transporte. Si bien algunas aplicaciones de protocolo OSI puras, como X.400, también las combinaron, no existe ningún requisito de que una pila de protocolos TCP/IP deba imponer una arquitectura monolítica sobre la capa de transporte. Por ejemplo, el protocolo de aplicación NFS se ejecuta sobre el protocolo de presentación de Representación de datos externos (XDR), que, a su vez, se ejecuta sobre un protocolo denominado Llamada a procedimiento remoto (RPC). RPC proporciona una transmisión de registros fiable, por lo que puede utilizar de forma segura el transporte UDP de mejor esfuerzo.

Diferentes autores han interpretado el modelo TCP/IP de manera diferente y no están de acuerdo si la capa de enlace, o cualquier aspecto del modelo TCP/IP, cubre los problemas de la capa 1 de OSI (capa física), o si TCP/IP asume una capa de hardware. existe debajo de la capa de enlace.

Varios autores han intentado incorporar las capas 1 y 2 del modelo OSI en el modelo TCP/IP, ya que estos son comúnmente mencionados en los estándares modernos (por ejemplo, por IEEE e ITU). Esto a menudo da como resultado un modelo con cinco capas, donde la capa de enlace o la capa de acceso a la red se divide en las capas 1 y 2 del modelo OSI.

El esfuerzo de desarrollo del protocolo IETF no se preocupa por la estratificación estricta. Es posible que algunos de sus protocolos no encajen perfectamente en el modelo OSI, aunque los RFC a veces se refieren a él y, a menudo, usan los antiguos números de capa OSI. El IETF ha declarado repetidamente que el protocolo de Internet y el desarrollo de la arquitectura no pretenden ser compatibles con OSI. RFC 3439, que hace referencia a la arquitectura de Internet, contiene una sección titulada: "La estratificación se considera dañina".

Por ejemplo, las capas de sesión y presentación de la suite OSI se consideran incluidas en la capa de aplicación de la suite TCP/IP. La funcionalidad de la capa de sesión se puede encontrar en protocolos como HTTP y SMTP y es más evidente en protocolos como Telnet y el Protocolo de inicio de sesión (SIP). La funcionalidad de la capa de sesión también se realiza con la numeración de puertos de los protocolos TCP y UDP, que se incluyen en la capa de transporte de la suite TCP/IP. Las funciones de la capa de presentación se realizan en las aplicaciones TCP/IP con el estándar MIME en el intercambio de datos.

Otra diferencia está en el tratamiento de los protocolos de enrutamiento. El protocolo de enrutamiento OSI IS-IS pertenece a la capa de red y no depende de CLNS para entregar paquetes de un enrutador a otro, sino que define su propia encapsulación de capa 3. Por el contrario, OSPF, RIP, BGP y otros protocolos de enrutamiento definidos por IETF se transportan a través de IP y, con el fin de enviar y recibir paquetes de protocolo de enrutamiento, los enrutadores actúan como hosts. Como consecuencia, RFC 1812 incluye protocolos de enrutamiento en la capa de aplicación. Algunos autores, como Tanenbaum en Computer Networks, describen los protocolos de enrutamiento en la misma capa que IP, razonando que los protocolos de enrutamiento informan las decisiones tomadas por el proceso de reenvío de los enrutadores.

Los protocolos IETF se pueden encapsular de forma recursiva, como lo demuestran los protocolos de tunelización como Generic Routing Encapsulation (GRE). GRE usa el mismo mecanismo que usa OSI para hacer túneles en la capa de red.

Implementaciones

El conjunto de protocolos de Internet no presupone ningún entorno de hardware o software específico. Solo requiere que exista una capa de hardware y software que sea capaz de enviar y recibir paquetes en una red informática. Como resultado, la suite se ha implementado en prácticamente todas las plataformas informáticas. Una implementación mínima de TCP/IP incluye lo siguiente: Protocolo de Internet (IP), Protocolo de resolución de direcciones (ARP), Protocolo de mensajes de control de Internet (ICMP), Protocolo de control de transmisión (TCP), Protocolo de datagramas de usuario (UDP) y Administración de grupos de Internet. Protocolo (IGMP). Además de IP, ICMP, TCP, UDP, el Protocolo de Internet versión 6 requiere el Protocolo de descubrimiento de vecinos (NDP), ICMPv6 y el Descubrimiento de oyentes de multidifusión (MLD) y, a menudo, va acompañado de una capa de seguridad IPSec integrada.