Hogar › Teléfono › El protocolo ppp del nodo fue interrumpido. Protocolo APP. Opciones de configuración de APP

El protocolo ppp del nodo fue interrumpido. Protocolo APP. Opciones de configuración de APP

PPP (protocolo de red)

APP(Inglés) Protocolo punto a punto) - protocolo punto a punto de la capa de enlace de datos (Enlace de datos) del modelo de red OSI. Normalmente se utiliza para establecer una comunicación directa entre dos nodos de red y puede proporcionar autenticación de conexión, cifrado (mediante ECP, RFC 1968) y compresión de datos. Utilizado en muchos tipos. redes fisicas: cable de módem nulo, línea telefónica, comunicación celular etc.

A menudo existen subtipos del protocolo PPP, como el protocolo punto a punto. a través de Ethernet(PPPoE), utilizado para conexiones Ethernet y, a veces, DSL; y el protocolo punto a punto sobre ATM (PPPoA), que se utiliza para conexiones sobre ATM Adaptation Layer 5 (AAL5), que es la principal alternativa a PPPoE para DSL.

PPP es una familia completa de protocolos: Protocolo de control de enlace (LCP), Protocolo de control de red (NCP), Protocolos de autenticación (PAP, CHAP), PPP multienlace (MLPPP).

Características principales

El protocolo PPP se desarrolló sobre la base de HDLC y agregó algunas características que anteriormente solo se encontraban en protocolos propietarios.

Configuración automática

Una vez establecida la conexión, se puede configurar a través de red adicional. Normalmente, se utiliza el Protocolo de control de protocolo de Internet (IPCP), aunque alguna vez fueron populares el Protocolo de control de intercambio de paquetes entre redes (IPXCP) y el Protocolo de control AppleTalk (ATCP). El protocolo de control del protocolo de Internet versión 6 (IPv6CP) se generalizará en el futuro cuando IPv6 reemplace a IPv4 como protocolo de capa de red principal.

Soporte multiprotocolo

PPP permite que múltiples protocolos de capa de red operen en un único canal de comunicación. En otras palabras, dentro de una conexión PPP, se pueden transmitir flujos de datos de varios protocolos de red (Novel IPX, etc.), así como datos de protocolos de capa de enlace de red local. Para cada protocolo de red, se utiliza el Protocolo de control de red (NCP), que lo configura (negocia algunos parámetros del protocolo).

Detección de enlaces de bucle

PPP detecta loopbacks usando una característica que incluye números mágicos. Cuando un nodo envía mensajes PPP LCP, pueden incluir un número mágico. Si la línea está en bucle, el nodo recibe un mensaje LCP con su propio numero magico en lugar de recibir un mensaje con el número mágico del cliente.

Características más importantes

El protocolo de control de enlace establece y finaliza conexiones, lo que permite a los nodos definir la configuración de conexión. También admite codificaciones orientadas a bytes y bits.
El protocolo de control de red se utiliza para definir la configuración de la capa de red, como dirección de red o ajustes de compresión después de que se haya establecido la conexión.

Opciones de configuración de APP

Dado que PPP incluye el protocolo LCP, puede controlar los siguientes parámetros LCP:

Autenticación. RFC 1994 describe el Protocolo de autenticación por desafío mutuo (CHAP), que es el protocolo de autenticación preferido para PPP, aunque a veces todavía se utiliza el Protocolo de autenticación de contraseña (PAP). Otra opción de autenticación es el Protocolo de autenticación extensible (EAP).
Compresión. Aumenta efectivamente el rendimiento de una conexión PPP al comprimir datos en el marco. Los algoritmos de compresión de cuadros PPP más conocidos son Stacker y Predictor.
Detección de errores. Incluye protocolo de calidad y ayuda a identificar bucles. comentario vía Números Mágicos RFC 1661.
Multicanal. Multilink PPP (MLPPP, MPPP, MLP) proporciona métodos para distribuir el tráfico entre múltiples canales fisicos, teniendo una conexión lógica. Esta opción permite un mayor rendimiento y proporciona equilibrio de carga.

marco de APP

Cada trama PPP siempre comienza y termina con el indicador 0x7E. A esto le sigue un byte de dirección y un byte de control, que también son siempre iguales a 0xFF y 0x03, respectivamente. Debido a la probabilidad de que los bytes coincidan dentro de un bloque de datos con banderas reservadas, existe un sistema para corregir automáticamente los datos "problemáticos" con su posterior recuperación.

Los campos Bandera, Dirección y Control (encabezado de trama HDLC) se pueden omitir y no transmitir, pero esto es si PPP negocia esto durante la configuración (usando LCP). Si PPP está encapsulado en paquetes L2TP, entonces el campo Bandera no se transmite.

Tipo de marco de datos PPP

Campo "Datos" marco de APP, a su vez, se dividen en dos campos más: la bandera del protocolo (que determina el tipo de datos hasta el final del cuadro) y los datos en sí.

Los indicadores de protocolo 0x0XXX a 0x3XXX identifican los protocolos de capa de red. Por ejemplo, el protocolo popular corresponde al indicador 0x0021 y Novell IPX - 002B.
Los indicadores de protocolo 0x4XXX a 0x7XXX identifican protocolos de bajo tráfico.
Los indicadores de protocolo 0x8XXX a 0xBXXX identifican el Protocolo de control de red (NCP).
Los indicadores de protocolo 0xCXXX a 0xEXXX identifican los protocolos de control. Por ejemplo, 0xC021 indica que la trama contiene datos del protocolo de control de enlace LCP.

Activaciones y fases del canal PPP.

Las fases del PPP según RFC 1661 se enumeran a continuación:

Enlace muerto. Esta fase ocurre cuando la conexión se interrumpe, o una de las partes ha indicado no conectarse (por ejemplo, el usuario ha terminado la conexión del módem).
Fase de establecimiento de enlace. En esta fase se configura Link Control. Si la configuración fue exitosa, el control pasa a la fase de autenticación o a la fase de Protocolo de capa de red, dependiendo de si se requiere autenticación.
Fase de autenticación. Esta fase es opcional. Permite a las partes verificarse entre sí antes de establecer una conexión. Si la verificación tiene éxito, el control ingresa a la fase de Protocolo de capa de red.
Fase de protocolo de capa de red. En esta fase se llama al NCP para el protocolo deseado. Por ejemplo, IPCP se utiliza para establecer servicios IP. En esta fase también se realiza la transferencia de datos a través de todos los protocolos instalados correctamente. En esta fase también se incluye el cierre de protocolos de red.
Fase de terminación del enlace. Esta fase cierra la conexión. Se llama en caso de errores de autenticación, si hubo tantos errores. sumas de control que ambas partes decidan cerrar la conexión si ésta finaliza inesperadamente o si el usuario se desconecta. Esta fase intenta cerrar todo de la forma más ordenada posible según las circunstancias.

Documentos RFC

El protocolo PPP está definido en RFC 1661 (Protocolo punto a punto, julio de 1994). Se han escrito varios RFC relacionados para definir cómo funcionan varios protocolos de red, incluidos TCP/IP, DECnet, AppleTalk, IPX y otros, con PPP.

RFC 1661, Estándar 51, Protocolo punto a punto (PPP)
RFC 1662, Estándar 51, Uso de HDLC en el desarrollo de APP
RFC 5072, IPv6 y PPP

Notas

Ver también

P.L.I.P. (Inglés) ruso

Protocolos TCP/IP básicos por niveles del modelo OSI (Lista de puertos TCP y UDP)
Físico
Conducto
Red
Transporte
Sesión
Envíos
Aplicado
Otros aplicados

UART

Capas físicas

Punto a punto	bucle de corriente Módem RS-232 IrDA HART
Red	RS-422 RS-423 RS-485 LIN
Especial	es: Kansas City Standard (casete compacto, disco de gramófono).

Protocolos

Punto a punto	APP DESLIZAMIENTO IrDA HART ISO 7816
Red	Modbus LIN DMX-512 P-NET Profibus

Áreas de uso

A continuación se ofrece una breve descripción de los errores que se producen al intentar conectarse a través de VPN, así como los métodos para solucionarlos. Encontré este artículo en Internet, pero también lo agregué yo mismo, porque... algunas soluciones estaban francamente desactualizadas o eran incorrectas.

Error 678- Computadora remota no responde

Este error ocurre cuando no hay conexión entre su computadora y el servidor de acceso. Lo más probable es que la causa de este error sea: mal funcionamiento del equipo activo, la tarjeta de red del cliente está deshabilitada, la conexión está bloqueada por un programa antivirus o firewall.

Error 691: acceso denegado porque el nombre de usuario o la contraseña no son válidos en este dominio

La mayoría de las veces, este error les ocurre a los usuarios si realmente escriben el nombre de usuario y la contraseña incorrectamente, o si ya se han conectado a la red con su inicio de sesión.
Si todo lo anterior no es para usted, intente ejecutar el siguiente conjunto de comandos:

1. Seleccione Inicio - Ejecutar en el menú, ingrese y ejecute el comando
cmd
2. Ejecute el comando: netsh interface ip reset
3. Ejecute el comando: netsh winsock reiniciar
4. Reinicie su computadora.

Error 721: la computadora remota no responde

Al conectarse a una VPN, la conexión llega al elemento "Comprobando nombre y contraseña", se congela por un momento y muestra el error 721: "La computadora remota no responde".

1. Primero, debes verificar si el servidor VPN correcto está registrado en la conexión VPN.

Para hacer esto, vaya a Inicio - Panel de control - Conexiones de red. Haga clic derecho en el acceso directo a su conexión VPN y seleccione Propiedades. Pestaña General: en la línea Nombre de la computadora o dirección IP de destino, se debe especificar la dirección del servidor VPN.

2. En la mayoría de los casos, el error 721 se produce debido a que hay un firewall instalado en su computadora.

Si se configura incorrectamente, este programa puede bloquear el tráfico de la red. Para estar 100% seguro, desactiva todo cortafuegos(Outpost Firewall, Zone Alarm, Kaspersky Internet Security...) incluido Firewall de Windows (Inicio - Panel de control - Firewall de Windows). Intenta conectarte. Si el error desaparece, intente configurar su firewall correctamente.

3. Si el error 721 continúa apareciendo, pruebe con el túnel L2TP.

Para hacer esto, vaya a Inicio - Panel de control - Conexiones de red. Haga clic derecho en el acceso directo a su conexión VPN y seleccione Propiedades. Pestaña Red, cambie el tipo de VPN; en lugar de VPN automática o PTPP, configure VPN IPSEC L2TP. Haga clic en Aceptar e intente conectarse.

4. A menudo sucede que al instalar una nueva versión de Windows, el Firewall integrado se instala incorrectamente, por lo que es imposible acceder a su configuración y solucionar el problema.

Para reinstalar el firewall debe llamar función API"Configuración de API InstallHinfSection". Para hacer esto, siga estos pasos:

Seleccione Inicio - Ejecutar, ingrese y ejecute el comando
cmd
Ingrese el siguiente comando en línea de comando y presione Entrar:
Rundll32 setupapi, InstallHinfSection Ndi-Steelhead 132 %windir%\inf\netrass.inf
Reinicie Windows.
Seleccione Ejecutar en el menú Inicio, ingrese y ejecute el comando
cmd
En el símbolo del sistema, escriba el siguiente comando y presione Entrar:
restablecimiento del firewall netsh
En el menú Inicio, seleccione Ejecutar, ingrese y ejecute el comando
firewall.cpl
Vaya a Inicio - Panel de control - Firewall de Windows y apáguelo.
Si después de todas estas operaciones sigue apareciendo el error 721, solo queda reinstalar Windows, de lo contrario es imposible solucionar este problema.

Error 734: se interrumpió el protocolo de control de enlace PPP

Este error puede ocurrir si los protocolos de seguridad del servidor al que se está conectando son incompatibles con su configuración de seguridad local. Solución: en la carpeta Conexiones de red, haga clic derecho en la conexión que está utilizando. Seleccione el comando Propiedades y abra la pestaña Seguridad. En la lista Utilizado al escanear, seleccione Contraseña no segura.

Error 769: el destino especificado es inalcanzable

El motivo de este error es que la tarjeta de red de su computadora está deshabilitada.

Error 800: Error de conexión

El motivo puede ser que esté utilizando un enrutador con firmware desactualizado. Por ejemplo, puede encontrar este problema si está utilizando un enrutador Cisco con firmware creado antes de 2001.
Para verificar que esta sea la causa, mire el seguimiento de la red. El equipo de Cisco anuncia un tamaño de ventana de cero en el protocolo de enlace TCP en el puerto 1723.

El problema también puede ser una conexión de red configurada incorrectamente. Por ejemplo, su servidor VPN o la configuración de seguridad están configurados incorrectamente.

En algunos casos, puede ocurrir un error debido a la falta de respuesta del servidor de autorización.

Los fallos en la conexión VPN, que implican el uso de módems de varios operadores de telecomunicaciones como enrutador, pueden ocurrir con bastante frecuencia. Uno de los más comunes es el error 734. Muchos usuarios, al intentar solucionar el problema que ha surgido, en ocasiones ni siquiera saben cómo abordar la solución de la situación. Pero, en general, se puede eliminar de forma bastante sencilla, para lo cual se pueden utilizar varios métodos propuestos en el material siguiente.

¿Qué significa el error 734 de VPN?

Antes de tomar cualquier medida para corregir la situación, veamos brevemente las razones por las que se produce tal fallo. El mensaje de error de conexión 734 indica claramente que por algún motivo se interrumpió el protocolo de control de comunicación (en nuestro caso estamos hablando de PPPoE). ¿Por qué sucedió esto? Se cree que esto se debe únicamente al hecho de que el proveedor que proporciona una conexión a su servidor VPN en Internet no utiliza el cifrado de los datos transmitidos y recibidos, mientras que dichas configuraciones están instaladas en la computadora del usuario. Por eso surgen conflictos a la hora de conectar.

La aparición del error 734 no se limita únicamente a este motivo. Muy a menudo se puede encontrar cuando se utiliza un software especial de Cisco. Cliente VPN. Sólo en este caso se informa que se ha producido un fallo y se cerrará la aplicación. Para restaurar la configuración de conexión, puede utilizar varios consejos simples, que se ofrecen para su consideración.

¿Cómo solucionar el error PPPoE 734 de la forma más sencilla?

Entonces, si apareció una falla, por así decirlo, de la nada (todo funcionaba antes de que apareciera), es muy posible que la causa sean fallas a corto plazo, no particularmente críticas, del propio sistema operativo.

En este caso, simplemente puede intentar restaurar el sistema seleccionando el punto antes de que ocurriera el error durante la reversión. Si esto no ayuda y vuelve a aparecer el error 734, es muy posible que algún tipo de virus haya entrado en el sistema y esté bloqueando la conexión.

lo mas salida sencilla será un análisis completo de su computadora en busca de amenazas utilizando algún tipo de escáner portátil o programas de disco como Rescue Disk, desde los cuales puede iniciar incluso antes de que se inicie el sistema operativo.

Pero a veces todo puede ir bien con los errores del sistema y tampoco hay virus en la computadora. ¿Qué hacer en tal situación?

Aquí tendrás que pasar por el “Panel de control” hasta la sección de administración de redes y recursos compartidos, luego usar la opción para cambiar opciones adaptador de red, luego vaya a través del elemento de propiedades a la pestaña de parámetros y haga clic en el botón "Configuración de PPP...". Después de que aparezca la ventana de configuración con tres elementos, verifique el primero (habilitar extensiones de LCD), guarde la configuración e intente conectarse nuevamente.

Pasos adicionales de configuración de seguridad

Sin embargo, también sucede que la opción propuesta anteriormente para corregir el error 734 no produce resultados. En este caso, puede ofrecer una opción de configuración adicional más.

Estando en la misma ventana principal que se muestra arriba, vaya a la pestaña de seguridad y luego en la lista desplegable de cifrado de datos, seleccione la opción “Opcional” (con una conexión incluso sin cifrado). Nuevamente, guarde la configuración y conéctese nuevamente al servidor VPN.

Opciones de corrección de errores del cliente VPN de Cisco

Ahora unas palabras sobre los problemas asociados con el cliente de software VPN de Cisco. Para solucionar estos problemas, primero puede utilizar la recuperación del sistema y el análisis de virus. Sin embargo, si esto no da ningún resultado, muchos expertos recomiendan comprobar o restaurar el registro, para lo cual puedes utilizar utilidades como WinTruster. También sería buena idea limpiar tu ordenador de “basura” (todo tipo de archivos temporales), utilizando cualquier optimizador o limpiador como CCleaner o ASC. Finalmente, si el problema persiste, desinstala completamente el cliente de tu computadora y luego vuelve a instalarlo. Para desinstalar, utilice programas de desinstalación (por ejemplo, iObit Uninstaller) en lugar de herramientas del sistema. Si, después de todos los pasos anteriores, aparecen nuevamente errores relacionados con el cliente, actualice controladores de red, utilizando programas automatizados (Driver Booster), que son los más adecuados para este tipo de operaciones.

¿Qué hacer si nada ayuda?

Por último, no olvide que la aparición de fallos asociados a una conexión VPN no siempre puede depender únicamente de la configuración de los terminales o portátiles de los usuarios. Por parte del proveedor tampoco se puede descartar su aparición. Póngase en contacto con el servicio de soporte de su proveedor u operador de telecomunicaciones. Es muy posible que los especialistas resuelvan su problema (en casos extremos, tal vez al menos le digan qué se puede hacer para eliminar las fallas). Si la falla es de corta duración y está relacionada únicamente con trabajos técnicos, no necesitará hacer nada en absoluto y, una vez finalizado el servicio, la conexión volverá a funcionar.

Autenticación. Los enrutadores conectados intercambian mensajes de autenticación. Hay dos opciones de autenticación disponibles: basada en PAP y basada en CHAP.

Compresión. Esta característica aumenta el rendimiento efectivo de las conexiones PPP al reducir la cantidad de datos por trama transmitida a través del enlace. El protocolo descomprime la trama en el destino. Hay dos protocolos de compresión disponibles en los enrutadores Cisco: Stacker y Predictor.

Detección de errores. Esta función detecta condiciones de falla. Los parámetros Calidad y Número mágico ayudan a garantizar un canal de transmisión de datos confiable y sin bucles. El campo Número mágico se utiliza para detectar canales que tienen un bucle. Hasta que la negociación del parámetro de configuración del Número Mágico se complete con éxito, el valor nulo este parámetro. Los valores de Magic-Number se generan aleatoriamente en cada extremo de la conexión.

Devolución de llamada PPP. La devolución de llamada PPP se utiliza para mejorar la seguridad. Al utilizar esta opción LCP, el enrutador Cisco puede actuar como un cliente de devolución de llamada o un servidor de devolución de llamada. El cliente realiza la llamada inicial, solicita una devolución de llamada al servidor y completa la llamada inicial. El enrutador de devolución de llamada responde a la llamada inicial y realiza una devolución de llamada al cliente según los comandos de configuración. El comando utilizado es devolución de llamada ppp [ aceptar | pedido ] .

Después de configurar los parámetros, el valor del campo correspondiente se inserta en el campo de parámetro del protocolo LCP.

Comandos básicos de configuración de PPP

Iniciar PPP en una interfaz

Para configurar PPP como método de encapsulación utilizado por la interfaz serie, utilice el comando de configuración de interfaz ppp de encapsulación .

El siguiente ejemplo habilita la encapsulación de PPP en la interfaz serie 0/0/0.

R3# configurar terminal

R3(configuración)# interfaz serie 0/0/0

R3(config-si)# ppp de encapsulación

el equipo ppp de encapsulación sin argumentos. Recuerda que si enrutador cisco La encapsulación PPP no está configurada, entonces la encapsulación HDLC se utilizará de forma predeterminada para las interfaces serie.

La figura muestra los enrutadores R1 y R2 configurados para usar una dirección IPv4 y una dirección IPv6 en sus interfaces serie. PPP es una encapsulación de Capa 2 que admite varios protocolos de Capa 3, incluidos IPv4 e IPv6.

Comandos de compresión PPP

Configurar en un protocolo punto a punto compresión de software en interfaces serie es posible después de activar la encapsulación PPP. Debido a que este modo invoca el proceso de compresión mediante programación, puede afectar el rendimiento del sistema. Si el tráfico ya consta de archivos comprimidos como .zip, .tar o .mpeg, no se debe utilizar esta función. La figura muestra la sintaxis del comando. comprimir .

Para configurar la compresión de transmisión PPP, ingrese los siguientes comandos.

R3(configuración)# interfaz serie 0/0/0

R3(config-si)# ppp de encapsulación

R3(config-si)# comprimir [ vaticinador | estanca ]

Equipo de Monitoreo de Calidad del Enlace PPP

Recuerde que LCP proporciona un paso adicional para determinar la calidad del enlace. En este punto, el LCP examina el enlace para determinar si la calidad del enlace es suficiente para admitir protocolos de Capa 3.

Equipo calidad ppp porcentaje garantiza el cumplimiento del canal requisito establecido a la calidad; de lo contrario, el canal está cerrado.

El porcentaje se calcula tanto para la dirección entrante como para la saliente. La calidad del enlace ascendente se calcula comparando el número total de paquetes y bytes enviados con el número total de paquetes y bytes recibidos por el nodo de destino. La calidad del enlace entrante se calcula comparando el número total de paquetes y bytes recibidos con el número total de paquetes y bytes enviados por el nodo de destino.

Si el porcentaje de calidad del canal no es compatible, entonces la calidad del canal se considera baja y el canal se desactiva. El Monitor de Calidad (LQM) implementa un mecanismo de retardo de tiempo para garantizar que el canal no sufra activación y desactivación secuencial.

El siguiente ejemplo de configuración monitorea los datos enviados al canal y evita bucles de generación de tramas (ver figura).

R3(configuración)# interfaz serie 0/0/0

R3(config-si)# ppp de encapsulación

R3(config-si)# calidad ppp 80

Para deshabilitar la herramienta LQM, use el comando sin calidad ppp .

Comandos PPP multienlace

Multilink PPP (también conocido como MP, MPPP, MLP o Multilink) proporciona un método para distribuir el tráfico a través de múltiples enlaces WAN físicos. Multilink PPP también proporciona fragmentación y reensamblaje de paquetes, secuenciación adecuada, capacidad entre proveedores y equilibrio de carga del tráfico entrante y saliente.

MPPP permite fragmentar paquetes y enviar esos fragmentos simultáneamente a través de múltiples enlaces punto a punto sobre el mismo a una dirección remota. En respuesta a un umbral de carga definido por el usuario, se abren múltiples canales físicos. MPPP puede medir la carga sólo en el tráfico entrante o sólo en el tráfico saliente, pero no la carga total en ambos tráficos.

Configurar MPPP es un proceso de dos pasos (ver figura).

Paso 1. Creando un grupo multicanal.

La interfaz multicanal es creada por el equipo. interfaz multienlace número .

En el modo de configuración de interfaz, a la interfaz multienlace se le asigna una dirección IP. En este ejemplo, se configuran una dirección IPv4 y una dirección IPv6 en los enrutadores R3 y R4.

Se inicia Multilink PPP en la interfaz.

A la interfaz se le asigna un número de grupo multicanal.

Paso 2. Asignación de interfaces a un grupo multicanal.

Las siguientes configuraciones se realizan en cada interfaz que forma parte de un grupo multicanal.

La encapsulación PPP está habilitada.

El PPP multienlace está activado.

Se le asigna a un grupo especificando el número de grupo configurado en el paso 1.

Para deshabilitar PPP multienlace, use el comando sin enlace múltiple ppp .

Comprobar la configuración de PPP

Para verificar que la encapsulación HDLC o PPP esté configurada correctamente, use el comando mostrar interfaces seriales . La salida del comando muestra la configuración de PPP (ver figura).

Después de configurar HDLC en la salida del comando mostrar interfaces seriales Debería aparecer la línea encapsulación HDL C. Si se configura PPP, también se debe mostrar el estado de LCP y NCP. Tenga en cuenta que los protocolos de control de red IPCP e IPV6CP están abiertos a IPv4 e IPv6 porque los enrutadores R1 y R2 tienen direcciones IPv4 e IPv6 instaladas.

En la figura. muestra una lista de comandos para verificar PPP.

Equipo mostrar ppp multienlace comprueba si el enlace múltiple PPP está habilitado en R3 (consulte la Figura 3).

El resultado muestra la interfaz Multilink 1, los nombres de host de los puntos finales locales y remotos, y interfaces seriales, incluido en un grupo multicanal.

autenticación de APP

PPP define un protocolo LCP extensible que permite negociar un protocolo de autenticación para verificar la identidad del interlocutor antes de permitir que los protocolos de capa de red transporten datos a través del enlace. RFC 1334 define dos protocolos de autenticación, PAP y CHAP (ver figura).

PAP (Protocolo de autenticación de contraseña) es un proceso muy simple de dos pasos. No utiliza cifrado. El nombre de usuario y la contraseña se envían sin cifrar. Una vez recibido, se permite establecer la conexión. CHAP (Protocolo de autenticación por desafío mutuo) tiene un nivel de seguridad más alto que PAP. Utiliza un intercambio de clave secreta compartida de tres pasos.

El paso de autenticación de la sesión PPP es opcional. Si se utiliza, el par se autentica después de que el LCP establece un canal y selecciona un protocolo de autenticación. Si se utiliza, la autenticación se realiza antes de que comience la fase de configuración del protocolo de capa de red.

Las opciones de autenticación requieren que la persona que llama ingrese información de autenticación. Esto garantiza que el usuario tenga permiso de administrador de red para realizar la llamada. Los enrutadores conectados intercambian mensajes de autenticación.

Protocolo de autenticación de contraseña (PAP)

Una de las muchas funciones de PPP es realizar autenticación de Capa 2 además de autenticación, cifrado, control de acceso y procedimientos generales de seguridad en otras capas.

Inicialización PAP

El protocolo PAP proporciona un método sencillo para verificar a un par mediante un apretón de manos de dos pasos. PAP es un protocolo no interactivo. Si se utiliza el comando pap de autenticación ppp , el nombre de usuario y la contraseña se pueden enviar como un único paquete de datos LCP en lugar de que el servidor solicite un nombre de inicio de sesión y espere una respuesta, como se muestra en la Fig. 1. Después de que PPP completa la fase de establecimiento de la conexión, el nodo remoto reenvía el par de nombre de usuario/contraseña a través del canal hasta que el nodo receptor lo reconoce o completa la conexión.

Finalización del PAP

En el nodo receptor, el servidor de autenticación verifica el nombre de usuario y la contraseña, lo que permite o niega la conexión. Se devuelve un mensaje de aceptación o rechazo al solicitante, como se muestra en la Figura. 2.

PAP no es un protocolo de autenticación sólido. Con PAP, las contraseñas se envían sin cifrar, por lo que no hay protección contra ataques de repetición o ataques repetidos de prueba y error. El nodo remoto controla la frecuencia y el tiempo de los intentos de ingresar a la red.

Sin embargo, existen situaciones en las que está justificado el uso de PAP. Por ejemplo, a pesar de sus desventajas, la PAP se puede utilizar en las siguientes condiciones.

Gran parque instalado aplicaciones cliente que no soportan el protocolo CHAP

Incompatibilidad entre implementaciones CHAP de diferentes proveedores

Proceso de encapsulación y autenticación PPP

Esquema en la Fig. explica el proceso de autenticación de PPP al realizar la configuración de PPP. El diagrama muestra un ejemplo visual de la lógica de decisión del protocolo PPP.

Por ejemplo, si una solicitud PPP entrante no requiere autenticación, PPP pasa al siguiente nivel. Si una solicitud PPP entrante requiere autenticación, la solicitud se puede autenticar utilizando una base de datos local o un servidor de seguridad. Como se muestra en el diagrama, después de una autenticación exitosa, el proceso pasa a nuevo nivel y si la autenticación falla, la conexión finaliza y se ignora la solicitud PPP entrante.

Siga los pasos de la figura para ver cómo el R1 establece una conexión PPP autenticada por CHAP con el R2.

Paso 1. R1 primero negocia una conexión de enlace con R2 mediante LCP y los dos sistemas acuerdan utilizar la autenticación CHAP durante la negociación de PPP LCP.

Paso 2. R2 genera una identificación y un número aleatorio, luego envía estos datos y su nombre de usuario a R1 como un paquete de control CHAP.

Paso 3. El enrutador R1 utiliza el nombre de usuario del retador (R2) y hace referencias cruzadas a este nombre para buscar la contraseña correspondiente en su base de datos local. Luego, R1 genera un hash MD5 utilizando el nombre de usuario, ID, número aleatorio y nombre compartido del enrutador de R2. contraseña secreta. En este ejemplo, la contraseña secreta compartida es Boardwalk.

Paso 4. Luego, el enrutador R1 envía al enrutador R2 el ID del paquete de control, el valor hash y su nombre de usuario (R1).

Paso 5. R2 genera su valor propio código hash que utiliza el ID, la contraseña secreta compartida y el número aleatorio enviado originalmente al R1.

Paso 6. R2 compara su valor hash con el valor enviado por R1. Si los valores coinciden, entonces R2 envía una respuesta de establecimiento de enlace al enrutador R1.

Si la solicitud falla en la autenticación, se genera un paquete CHAP con información de error, que consta de los siguientes componentes:

04 = tipo de mensaje de error CHAP

id = copiado del paquete de respuesta

"Fallo de autenticación" o similar mensaje de texto, comprensible para el usuario.

La contraseña secreta compartida debe ser idéntica en ambos enrutadores R1 y R2.

Configurar la autenticación PPP

Para especificar el orden en el que se solicitan los protocolos CHAP y PAP en una interfaz, utilice el comando de configuración de interfaz autenticación ppp, como se muestra en la imagen. Para deshabilitar la autenticación, use una versión negada de este comando ( No ).

Después de habilitar la autenticación CHAP, PAP o ambas, el enrutador local solicita al dispositivo remoto una prueba de su autenticidad antes de permitir el flujo de datos. Para hacer esto, realice los siguientes pasos.

La autenticación PAP solicita al dispositivo remoto un nombre de usuario y una contraseña para compararlos con la entrada correspondiente en la base de datos de nombres de usuarios local o en la base de datos remota TACACS/TACACS+.

La autenticación CHAP envía una solicitud de control al dispositivo remoto. El dispositivo remoto debe cifrar el valor de control utilizando una clave secreta compartida y devolver el valor cifrado y su nombre al enrutador local en un mensaje de respuesta. Enrutador local utiliza el nombre del dispositivo remoto para buscar la clave secreta correspondiente en la base de datos de nombres de usuario local o en la base de datos TACACS/TACACS+ remota. Utiliza la clave secreta encontrada para cifrar el valor de verificación original y verifica la identidad de los valores cifrados.

Nota. TACACS es un servidor dedicado de autenticación, autorización y contabilidad (AAA) que se utiliza para autenticar usuarios. Los clientes TACACS envían una solicitud al servidor de autenticación TACACS. El servidor autentica al usuario, autoriza las acciones del usuario y realiza un seguimiento de las acciones del usuario.

Puede habilitar PAP, CHAP o ambos protocolos. Si ambos métodos están habilitados, se solicita el método especificado primero durante la negociación de la comunicación. Si el nodo remoto sugiere usar el segundo método o simplemente se niega a usar el primer método, se intenta el segundo método. Algunos dispositivos remotos solo admiten CHAP y otros solo admiten PAP. El orden en el que se especifican los métodos se basa en consideraciones relativas a la capacidad del dispositivo remoto para negociar correctamente el método apropiado, así como en consideraciones de seguridad del enlace de datos. Los nombres de usuario y contraseñas de PAP se envían como cadenas claras y pueden interceptarse y reutilizarse. El protocolo CHAP ha abordado la mayoría de los agujeros de seguridad conocidos.

Configurar PPP con autenticación

La tabla describe el procedimiento para configurar la encapsulación y los protocolos PPP. autenticación PAP/CAP. Es importante configurar esto correctamente porque PAP y CHAP utilizan estos parámetros para la autenticación.

Configurar la autenticación PAP

En la figura. Se proporciona un ejemplo de configuración de la autenticación PAP bidireccional. Cada enrutador realiza y pasa la autenticación, por lo que los comandos de autenticación PAP correspondientes se reflejan entre sí. El nombre de usuario y la contraseña de PAP enviados por cada enrutador deben coincidir con el especificado en el comando nombre de usuario nombre contraseña contraseña otro enrutador.

El protocolo PAP proporciona un método sencillo para verificar a un par mediante un apretón de manos de dos pasos. Esto solo se hace después de que se crea inicialmente el canal. El nombre de host en un enrutador debe coincidir con el nombre de usuario configurado para PPP en el otro enrutador. Las contraseñas también deben coincidir. Especifique los parámetros pasando el nombre de usuario y la contraseña en el comando ppp pap nombre-usuario enviado nombre contraseña contraseña .

Configurar la autenticación CHAP

CHAP verifica periódicamente la identidad del host remoto mediante un protocolo de enlace de tres vías. El nombre de host en un enrutador debe coincidir con el nombre de usuario configurado en el otro enrutador. Las contraseñas también deben coincidir. El procedimiento se realiza después de la creación inicial del canal y puede repetirse en cualquier momento después de que se establezca la conexión. En la figura. Se proporciona un ejemplo de configuración de CHAP.

15/10/06 6.1K

2.1 Introducción

PPP es un estándar de Internet para transmitir paquetes IP a través de líneas serie. PPP admite líneas síncronas y asíncronas. Para conocer algunos puntos de la discusión sobre PPP, así como sobre PPP versus SLIP, le aconsejo que consulte el documento en ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (papel) y sug91- cheapIP.shar.Z (diapositivas para retroproyector)

2.2 Características de PPP que pueden estar presentes o no

En ambos lados de la compatibilidad con el marco PPP básico, es necesario saber que muchos programas añaden sus propios características adicionales. Es aconsejable recordar que no todos los programas de distribución gratuita, así como los comerciales, tienen un conjunto completo de todas las capacidades.
Marcación a petición (marcación bajo petición) Conexión de una interfaz PPP y marcación de números de teléfono. números a la llegada del paquete. Deshabilitar la interfaz PPP después de un período de inactividad.
Rellamada Conexión de una interfaz PPP, que no se desconectará posteriormente y mantendrá siempre a su disposición el canal conectado.
Campling (ver Rellamada)
Instalación de scripting a través de una serie de mensajes o conexiones intermedias para establecer una conexión PPP, más parecidas a las secuencias utilizadas para establecer una conexión a través de UUCP.
Paralelo Configurar varias líneas PPP para una misma conexión al host, para distribuir uniformemente el tráfico entre ellas. (En proceso de estandarización)
Filtrado Selección de qué paquetes tiene sentido empezar a llamar a la línea y cuáles no. Basado en el tipo de paquete IP o TCP o TOS (Tipo de Servicio) a la hora de tomar una decisión. Por ejemplo, ignore todos los paquetes ICMP.
Compresión de encabezado Compresión de encabezado TCP de acuerdo con RFC1144 No es necesario cuando se usa en líneas de alta velocidad, pero es muy útil en líneas de baja velocidad.
El servidor acepta conexiones PPP entrantes, que también pueden requerir enrutamiento adicional.
Tunneling Construcción de redes virtuales sobre una conexión PPP, mediante flujo TCP, a través de una red IP existente. (Construir un red virtual a través de un enlace PPP a través de un flujo TCP a través de una red IP existente).
Los caracteres de escape adicionales orientados a bytes que no están incluidos en el conjunto de caracteres estándar utilizado al establecer una conexión se pueden configurar por separado, pero tampoco se superponen con los utilizados al establecer una conexión. (Caracteres de relleno de bytes fuera del mapa asíncrono negociado, configurables de antemano pero no negociables).

2.3 Glosario APP

Cada tecnología adquiere siglas con el tiempo... PPP no es una excepción. Dado que casi todos los términos se utilizan en su transcripción inglés/estadounidense, me parece que la traducción de estas abreviaturas no tiene sentido.
ack Acuse de recibo
AO Active Open (recientemente pasó a formar parte de FSM en RFC1331)
C Cerrar
Protocolo de autenticación por desafío mutuo CHAP (RFC1334)
D Capa inferior hacia abajo
Protocolo de entrada de datos DES
Arquitectura de red digital de ADN
Grupo de trabajo de ingeniería de Internet del IETF.
Protocolo de Internet IP
Protocolo de control IP IPCP.
Intercambio de paquetes de red IPX (pila de redes de Novell)
Secuencia de verificación de trama FCS
Automatización de estados finitos de la FSA
Máquina de estados finitos FSM
Protocolo de control de enlace LCP.
Informe de calidad del enlace LQR.
Algoritmo de firma digital MD4 MD4
Algoritmo de firma digital MD5 MD5
Unidad de recepción máxima MRU
Unidad de transmisión máxima MTU
nak Reconocimiento Negativo
Protocolo de control de red NCP.
Codificación de bits NRZ sin retorno a cero. (SYNC ppp predeterminado debido a disponibilidad)
NRZI Codificación de bits invertidos sin retorno a cero. (SYNC ppp es la alternativa preferida a NRZ)
Interconexión de sistemas abiertos OSI
Protocolo de autenticación de contraseña PAP (RFC1334)
Unidad de datos de protocolo PDU (igual que el paquete)
PO Pasivo abierto
Protocolo PPP punto a punto (RFC1548 /RFC1549,1332,1333,1334,1551,1376,1377,1378)
Configuración de recepción RCA-Ack
Código de recepción RCJ-Rechazo
RCN Recibir Configurar-Nak o -Rechazar
RCR+ recibe una buena solicitud de configuración
RER Recibir solicitud de eco
Solicitud de comentarios RFC (estándar de Internet)
RTA Recibir Terminar-Ack
RTR Recibir solicitud de terminación
RUC Recibe código desconocido
sca Enviar Configurar-Aceptar
scj Enviar código-Rechazar
scn Enviar Configurar-Nak o -Rechazar
scr Enviar solicitud de configuración
ser Enviar respuesta de eco
sta Enviar Terminar-Ack
str Enviar solicitud de terminación
Protocolo de flujo ST-II
TO+ Tiempo de espera con contador > 0
TO- Tiempo de espera con contador vencido
VJ Van Jacobson (algoritmo de compresión de encabezado RFC1144)
Servicios de red XNS Xerox
información general

El protocolo punto a punto (PPP) está diseñado para resolver problemas asociados con cantidad insuficiente medios estándar para encapsular protocolos del tipo “IP punto a punto”. Además, PPP también fue diseñado para simplificar la emisión y administración de direcciones IP, encapsulación síncrona asíncrona y orientada a bits, multiplexación de protocolos de red, configuración y prueba de calidad de comunicación, detección de errores y opciones para establecer características de capa de red como direcciones de configuración y configurar la compresión de datos. Para respaldar las cualidades anteriores, PPP debe proporcionar control sobre el protocolo de control de enlace (LCP) extendido y la familia de protocolos de protocolos de control de red (NCP) que se utilizan para establecer parámetros de comunicación. Hoy en día, PPP soporta no sólo IP, sino también otros protocolos, incluidos IPX y DECNet.

Componentes de las APP

PPP proporciona la capacidad de transmitir datagramas a través de líneas seriales punto a punto. Tiene 3 componentes:

* Un método para proporcionar encapsulación de datagramas a través de líneas PPP en serie utilizando el protocolo HDLC (Control de enlace de datos de alto nivel) para empaquetar datagramas a través de comunicaciones PPP.
* LCP (Protocolo de control de enlace) mejorado para instalación, configuración y pruebas conexión física(pruebe la conexión de enlace de datos)
* Una familia de protocolos (NCP) para establecer y administrar otros protocolos de red; en otras palabras: PPP está diseñado para admitir múltiples protocolos de red simultáneamente.

Operación General

Cuando se establece una conexión PPP, el controlador PPP primero envía paquetes LCP para configurar y (posiblemente) probar el enlace de comunicación. Después de que se hayan establecido las comunicaciones y capacidades adicionales según sea necesario a través de LCP, el controlador PPP envía tramas NCP para cambiar y/o configurar uno o más protocolos de red. Cuando este proceso termine, entonces paquetes de red tener la oportunidad de ser transmitido a través conexión establecida. Permanecerá configurado y activo hasta que ciertos paquetes LCP o NCP cierren la conexión, o hasta que ocurra algún evento externo que provoque la pérdida de la conexión (por ejemplo: un temporizador de inactividad o intervención del usuario)
Requisitos de la capa física

PPP está adaptado para funcionar con cualquier interfaz DTE/DCE, incluidas EIA/TIA-232-C (RS-232), EIA/TIA-422-C(RS-422), EIA/TIA-423-C(RS-423 ) , UIT-T (CCITT) V.35. El único requisito de hardware impuesto por PPP es la presencia de hardware dúplex, ya sea dedicado o conmutado, que pueda operar en paquetes transparentes PPP asíncronos o síncronos orientados a bits.
Capa de enlace PPP
—————

PPP utiliza los principios, la terminología y la estructura de paquetes descritos en los documentos ISO relacionados con HDLC (ISO 3309-1979) y su versión ampliada:

* ISO 3309:1984/PDAD1 “Anexo 1: Iniciar/detener transmisión”.
* ISO 3309-1979: describe la estructura de los paquetes HDLC para su uso en sistemas síncronos.
* ISO 3309:1984/PDAD1: describe propuestas de cambios a ISO 3309-1979 que permitirían el uso de sistemas asíncronos.

Los procedimientos de control de APP utilizan definiciones y campos de control estandarizados en los documentos: ISO 4335-1979 e ISO 4335-1979/Anexo 1-1979.

Formato de paquete PPP:
1 1 1 2 Variable 2 o 4
Bandera Protocolo de control de direcciones DATOS FCS

Bandera: un byte que indica el comienzo o el final de un paquete. El campo de bandera contiene la secuencia binaria: 01111110.
Dirección: un byte que contiene la secuencia binaria: 11111111, dirección de transmisión estándar. PPP no soporta la unidifusión de estaciones.
Control: Un byte que contiene la secuencia binaria: 00000011, que se envía para transmitir datos del usuario en paquetes no divididos. (para la transmisión de datos de usuario en una trama no secuenciada.
Protocolo: 2 bytes codifican el protocolo empaquetado en el tiempo del protocolo PPP. Los valores del protocolo se pueden encontrar en el documento Solicitud de comentarios (RFC) de números asignados.
Datos: 0 o más bytes que componen el datagrama del protocolo especificado en el campo “Protocolo”. El final del campo de información se determina buscando la secuencia final y la secuencia de 2 bytes en el campo FCS. Por defecto, la longitud máxima del campo de información es 1500 bytes. Sin embargo, de común acuerdo, teniendo en cuenta el uso de PPP, se pueden utilizar otras longitudes de campo.
Secuencia de verificación de trama (FCS): normalmente 16 bits (2 bytes). Sin embargo, de mutuo acuerdo, se puede utilizar el control de integridad de paquetes de 32 bits (4 bytes).

Protocolo de control de enlace PPP

PPP LCP proporciona métodos para establecer, configurar, mantener y probar conexiones punto a punto. LCP se divide en 4 fases:

* Configuración y comunicación: antes de transmitir cualquier datagrama (por ejemplo, IP), el LCP primero debe abrir una conexión y realizar un intercambio inicial de parámetros de configuración. Esta etapa finaliza cuando se ha enviado y recibido un paquete que confirma la configuración.
* Determinación de la calidad de la comunicación: LCP permite (pero no exige) agregar una fase de prueba del canal de comunicación; esta fase seguirá inmediatamente después de la primera. Durante esta fase se determina si la conexión es capaz de transportar cualquier protocolo de red con la calidad suficiente. Esta fase es opcional. El LCP debe retrasar la transferencia de cualquier protocolo de red hasta que se complete esta fase.
* Establecimiento de la configuración del protocolo de red: una vez que el LCP ha terminado de definir los parámetros de comunicación, los protocolos de red deben ser configurados de forma independiente por los NCP correspondientes, que pueden iniciarse o dejar de usarse en cualquier momento.
* Fin de la conexión: LCP puede finalizar la conexión establecida en cualquier momento. Esto puede ocurrir debido a la demanda del usuario o debido a algún evento físico, como la pérdida del operador o la expiración de un período permitido de tiempo de canal no utilizado.

Hay tres tipos de paquetes LCP:

* Paquetes de establecimiento: se utilizan para establecer y configurar comunicaciones.
* Interrumpir paquetes: se utiliza para interrumpir una conexión establecida.
* Paquetes de ahorro de comunicaciones: se utilizan para la gestión y el diagnóstico de las comunicaciones.

2.4 RFC relevantes para APP

Esta es una lista de RFC relacionados con PPP. Algunos de estos documentos (obsoletos) están desactualizados...

* 1717 - Sklower, K.; Lloyd, B.; McGregor, G.; Carr, D El protocolo multienlace (MP) PPP. noviembre de 1994; 21 h. (Formato: TXT=46264 bytes)
* 1663 - Rand, Transmisión confiable DPPP. julio de 1994; 8 p.m. (Formato: TXT=17281 bytes)
* 1662 — Simpson, W., edPPP in HDLC-like Framing. julio de 1994; 25p. (Formato: TXT=48058 bytes) (Obsoleto RFC 1549)
* 1661 — Simpson, W., ed. El protocolo punto a punto (PPP). julio de 1994; 52p. (Formato: TXT=103026 bytes) (Obsoletos RFC 1548)
* 1638 - Panadero, F.; Bowen, R., edsProtocolo de control de puentes (BCP) del PPP. Junio de 1994; 28 p.m. (Formato:TXT=58477 bytes)
* 1619 - Simpson, WPPP sobre SONET/SDH. mayo de 1994; 4 p.m. Formato: TXT=8893 bytes)
* 1618 - Simpson, WPPP sobre RDSI. mayo de 1994; 6 p.m. (Formato: TXT=14896 bytes)
* 1598 - Simpson, WPPP en X.25. marzo de 1994; 7 p.m. (Formato: TXT=13835 bytes)
* 1570 — Simpson, W., ed. Extensiones PPP LCP. enero de 1994; 18 h. (Formato: TXT=35719 bytes) (Actualiza RFC 1548)
* 1553 - Mathur, S.; Lewis, M. Compresión de encabezados IPX a través de medios WAN (CIPX). 1993 diciembre; 23 h. (Formato: TXT=47450 bytes)
* 1552 - Simpson, W. El protocolo de control de intercambio de paquetes entre redes PPP (IPXCP). 1993 diciembre; 14 p.m. Formato: TXT=29174 bytes)
* 1551 - Allen, M. Novell IPX sobre varios medios WAN IPXWAN). 1993 diciembre; 22 p.m. (Formato: TXT=54210 bytes) (Obsoleto RFC 1362)
* 1549 — Simpson, W., ed. PPP en marcos HDLC. 1993 diciembre; 18 h. (Formato: TXT=36353 bytes) Obsoleto por RFC 1662)
* 1548 — Simpson, W. El protocolo punto a punto (PPP). 1993 diciembre; 53 p. (Formato: TXT=111638 bytes) (Obsoleto RFC 1331; Obsoleto por RFC 1661; Actualizado por RFC 1570)
* 1547 - Perkins, D. Requisitos para un protocolo punto a punto estándar de Internet. 1993 diciembre; 21 h. Formato: TXT=49811 bytes)
* 1378 - Protocolo de control PPP AppleTalk (ATCP). Parker, B. noviembre de 1992; 16 p.m. (Formato: TXT=28496 bytes)
* 1377 - Protocolo de control de capa de red PPP OSI (OSINLCP). Katz, D. noviembre de 1992; 10 p.m. (Formato: TXT=22109 bytes)
* 1376 - Protocolo de control PPP DECnet Fase IV (DNCP). Senum, S.J. noviembre de 1992; 6 p.m. (Formato: TXT=12448 bytes)
* 1362 - Allen, M. Novell IPX sobre varios medios WAN IPXWAN). Septiembre de 1992; 18 h. (Formato: TXT=30220 bytes)
* 1334 - Protocolos de autenticación PPP. Lloyd, B.; Simpson, W.A. Octubre de 1992; 16 p.m. (Formato: TXT=33248 bytes)
* 1333 - Monitoreo de calidad del enlace PPP. Simpson, W.A. mayo de 1992; 15 h. (Formato: TXT=29965 bytes)
* 1332 - Protocolo de control de protocolo de Internet PPP (IPCP). McGregor, G. mayo de 1992; 12 p.m. (Formato: TXT=17613 bytes) (Obsoleto RFC1172)
* 1331 - Protocolo punto a punto (PPP) para la transmisión de datagramas multiprotocolo a través de enlaces punto a punto. Simpson, W.A. mayo de 1992; 66p. (Formato: TXT=129892 bytes) (Obsoletos RFC1171, RFC1172; obsoletos por RFC 1548)
* 1220 - Extensiones de protocolo punto a punto para puentes. Panadero, F., ed. abril de 1991; 18 h. (Formato: TXT=38165 bytes)
* 1172 - Opciones de configuración inicial del Protocolo punto a punto (PPP). Perkins, D.; Hobby, R. julio de 1990; 38p. (Formato: TXT=76132 bytes) (Obsoleto por RFC1331, RFC1332)
* 1171 - Protocolo punto a punto para la transmisión de datagramas multiprotocolo sobre enlaces punto a punto. Perkins, D. julio de 1990; 48p. (Formato: TXT=92321 bytes) (Obsoleto RFC1134; Obsoleto por RFC1331)
* 1134 - Protocolo Punto a Punto: Una propuesta para la transmisión multiprotocolo de datagramas a través de enlaces Punto a Punto. Perkins, D. noviembre de 1989; 38p. (Formato: TXT=87352 bytes) (Obsoleto por RFC1171)
* 1144 - Compresión de encabezados TCP/IP para enlaces seriales de baja velocidad. Jacobson, V. febrero de 1990; 43p. Formato: TXT=120959 PS=534729 bytes)