Protocolo punto a punto

En redes informáticas, Protocolo punto a punto (PPP) es un protocolo de comunicación de capa de enlace de datos (capa 2) entre dos enrutadores directamente sin ningún host o otras redes en el medio. Puede proporcionar autenticación de conexión de bucle, cifrado de transmisión y compresión de datos.

El PPP se utiliza en muchos tipos de redes físicas, incluido el cable serial, la línea telefónica, la línea troncal, el teléfono celular, los enlaces de radio especializados, ISDN y los enlaces de fibra óptica como SONET. Dado que los paquetes IP no se pueden transmitir a través de una línea de módem por sí solos sin algún protocolo de enlace de datos que pueda identificar dónde comienza y dónde termina la trama transmitida, los proveedores de servicios de Internet (ISP) han utilizado PPP para el acceso telefónico de los clientes a Internet.

Dos derivados de PPP, el protocolo punto a punto sobre Ethernet (PPPoE) y el protocolo punto a punto sobre ATM (PPPoA), son los más utilizados por los ISP para establecer un servicio de Internet de línea de suscriptor digital (DSL) LP conexión con los clientes.

Descripción

PPP se usa comúnmente como un protocolo de capa de enlace de datos para la conexión a través de circuitos síncronos y asíncronos, donde ha reemplazado en gran medida al antiguo Protocolo de Internet de línea en serie (SLIP) y los estándares obligatorios de la compañía telefónica (como el Protocolo de acceso a enlace, balanceado (LAPB) en el conjunto de protocolos X.25). El único requisito para PPP es que el circuito proporcionado sea dúplex. PPP fue diseñado para funcionar con numerosos protocolos de capa de red, incluido el Protocolo de Internet (IP), TRILL, Internetwork Packet Exchange (IPX) de Novell, NBF, DECnet y AppleTalk. Al igual que SLIP, esta es una conexión completa a Internet a través de líneas telefónicas a través de un módem. Es más confiable que SLIP porque verifica dos veces para asegurarse de que los paquetes de Internet lleguen intactos. Reenvía cualquier paquete dañado.

PPP se diseñó un poco después de las especificaciones HDLC originales. Los diseñadores de PPP incluyeron muchas características adicionales que hasta ese momento solo se habían visto en protocolos de enlace de datos propietarios. PPP se especifica en RFC 1661.

RFC 2516 describe el protocolo punto a punto sobre Ethernet (PPPoE) como un método para transmitir PPP sobre Ethernet que a veces se usa con DSL. RFC 2364 describe el protocolo punto a punto sobre ATM (PPPoA) como un método para transmitir PPP sobre la capa de adaptación ATM 5 (AAL5), que también es una alternativa común a PPPoE que se usa con DSL.

PPP, PPPoE y PPPoA se utilizan ampliamente en las líneas WAN.

PPP es un protocolo en capas que tiene tres componentes:

1. Un componente de encapsulación que se utiliza para transmitir datagramas sobre la capa física especificada.
2. A Link Control Protocol (LCP) para establecer, configurar y probar el enlace, así como negociar ajustes, opciones y el uso de funciones.
3. Uno o más Protocolos de Control de Redes (NCP) utilizados para negociar parámetros e instalaciones opcionales de configuración para la capa de red. Hay un NCP para cada protocolo de capas superiores apoyado por PPP.

Autoconfiguración automática

LCP inicia y finaliza las conexiones correctamente, lo que permite que los hosts negocien las opciones de conexión. Es una parte integral de PPP y se define en la misma especificación estándar. LCP proporciona la configuración automática de las interfaces en cada extremo (como la configuración del tamaño del datagrama, los caracteres de escape y los números mágicos) y para seleccionar la autenticación opcional. El protocolo LCP se ejecuta sobre PPP (con el número de protocolo PPP 0xC021) y, por lo tanto, se debe establecer una conexión PPP básica antes de que LCP pueda configurarlo.

RFC 1994 describe el Protocolo de autenticación por desafío mutuo (CHAP), que es el preferido para establecer conexiones de acceso telefónico con ISP. Aunque está en desuso, el Protocolo de autenticación de contraseña (PAP) todavía se usa a veces.

Otra opción para la autenticación mediante PPP es el Protocolo de autenticación extensible (EAP) descrito en RFC 2284.

Después de que se haya establecido el enlace, es posible que se realice una configuración de red adicional (capa 3). Por lo general, se usa el Protocolo de control de protocolo de Internet (IPCP), aunque el Protocolo de control de intercambio de paquetes entre redes (IPXCP) y el Protocolo de control de AppleTalk (ATCP) alguna vez fueron populares. El protocolo de control de la versión 6 del protocolo de Internet (IPv6CP) verá un uso extendido en el futuro, cuando IPv6 reemplace a IPv4 como el protocolo de capa 3 dominante.

Múltiples protocolos de capa de red

PPP permite que múltiples protocolos de capa de red operen en el mismo enlace de comunicación. Para cada protocolo de capa de red utilizado, se proporciona un Protocolo de control de red (NCP) separado para encapsular y negociar opciones para los múltiples protocolos de capa de red. Negocia información de capa de red, p. dirección de red u opciones de compresión, después de que se haya establecido la conexión.

Por ejemplo, IP utiliza IPCP e Internetwork Packet Exchange (IPX) utiliza el Protocolo de control IPX de Novell (IPX/SPX). Los NCP incluyen campos que contienen códigos estandarizados para indicar el tipo de protocolo de la capa de red que encapsula la conexión PPP.

Los siguientes NCP se pueden usar con PPP:

• IPCP para IP, número de código de protocolo 0x8021, RFC 1332
• el Protocolo de Control de capas de red OSI (OSINLCP) para los diversos protocolos de capa de red OSI, número de código de protocolo 0x8023, RFC 1377
• el Protocolo de Control de AppleTalk (ATCP) para AppleTalk, número de código de protocolo 0x8029, RFC 1378
• el protocolo de control de intercambio de paquetes de Internet (IPXCP) para el intercambio de paquetes de Internet, número de código de protocolo 0x802B, RFC 1552
• el Protocolo de Control de Fase IV (DNCP) de DECnet Fase IV Protocolo de rotación (DECnet Phase IV), número de código de protocolo 0x8027, RFC 1762
• el Protocolo de Control de Marcos de NetBIOS (NBFCP) para el protocolo NetBIOS Frames (o NetBEUI como se llamó antes), número de código de protocolo 0x803F, RFC 2097
• el Protocolo de Control IPv6 (IPV6CP) para IPv6, número de código de protocolo 0x8057, RFC 5072

Detección de enlace en bucle

PPP detecta enlaces en bucle utilizando una característica que involucra números mágicos. Cuando el nodo envía mensajes PPP LCP, estos mensajes pueden incluir un número mágico. Si una línea está en bucle, el nodo recibe un mensaje LCP con su propio número mágico, en lugar de recibir un mensaje con el número mágico del par.

Opciones de configuración

La sección anterior introdujo el uso de opciones LCP para cumplir con los requisitos específicos de conexión WAN. PPP puede incluir las siguientes opciones de LCP:

• Autenticación - Los routers Peer intercambian mensajes de autenticación. Dos opciones de autenticación son el Protocolo de autenticación de contraseñas (PAP) y el Protocolo de autenticación de palanca de desafío (CHAP). La autenticación se explica en la siguiente sección.
• Compresión - Aumenta el rendimiento efectivo en las conexiones PPP reduciendo la cantidad de datos en el marco que debe viajar a través del enlace. El protocolo descomprime el marco en su destino. Vea RFC 1962 para más detalles.
• Detección de errores - Identifica las condiciones de culpa. Las opciones de Quality and Magic Number ayudan a asegurar un enlace de datos fiable y libre de bucles. El campo Magic Number ayuda a detectar enlaces que están en una condición de retroceso. Hasta que se haya negociado con éxito la opción de configuración de Magic-Number, debe transmitirse como cero. Los números mágicos se generan aleatoriamente en cada extremo de la conexión.
• Multilink - Proporciona equilibrio de carga varias interfaces utilizadas por PPP a través de PPP multilink (ver abajo).

Marco PPP

Estructura

Los marcos PPP son variantes de los marcos HDLC:

Si ambos pares aceptan la compresión del campo de dirección y del campo de control durante LCP, esos campos se omiten. Del mismo modo, si ambos pares están de acuerdo con la compresión del campo de protocolo, se puede omitir el byte 0x00.

El campo Protocolo indica el tipo de paquete de carga útil: 0xC021 para LCP, 0x80xy para varios NCP, 0x0021 para IP, 0x0029 AppleTalk, 0x002B para IPX, 0x003D para Multilink, 0x003F para NetBIOS, 0x00FD para MPPC y MPPE, etc. PPP es limitado y no puede contener datos generales de capa 3, a diferencia de EtherType.

El campo Información contiene la carga útil de PPP; tiene una longitud variable con un máximo negociado denominado Unidad Máxima de Transmisión. Por defecto, el máximo es 1500 octetos. Puede estar acolchado en la transmisión; si la información de un protocolo en particular se puede rellenar, ese protocolo debe permitir que la información se distinga del relleno.

Encapsulación

Las tramas PPP se encapsulan en un protocolo de capa inferior que proporciona tramas y puede proporcionar otras funciones, como una suma de verificación para detectar errores de transmisión. PPP en enlaces seriales generalmente se encapsula en un marco similar a HDLC, descrito por IETF RFC 1662.

El campo Bandera está presente cuando se utiliza PPP con tramas similares a HDLC.

Los campos Dirección y Control siempre tienen el valor hexadecimal FF (para "todas las estaciones") y hex 03 (para "información no numerada"), y se pueden omitir siempre que PPP Dirección LCP -and-Control-Field-Compression (ACFC) se negocia.

El campo de secuencia de verificación de tramas (FCS) se usa para determinar si una trama individual tiene un error. Contiene una suma de comprobación calculada sobre la trama para proporcionar protección básica contra errores en la transmisión. Este es un código CRC similar al que se usa para otros esquemas de protección contra errores de protocolo de capa dos, como el que se usa en Ethernet. Según RFC 1662, puede tener un tamaño de 16 bits (2 bytes) o 32 bits (4 bytes) (el valor predeterminado es 16 bits: polinomio x¹⁶ + x¹² + x⁵ + 1).

El FCS se calcula sobre los campos Dirección, Control, Protocolo, Información y Relleno después de encapsular el mensaje.

Activación de línea y fases

Enlace muerto

Esta fase ocurre cuando el enlace falla, o se le ha dicho a un lado que se desconecte (por ejemplo, un usuario ha terminado su conexión de marcado).

Link Establishment Fase

Esta fase es donde se intenta negociar el Protocolo de Control de Enlace. Si tiene éxito, el control va bien a la fase de autenticación o a la fase de Protocolo de capa de red, dependiendo de si se desea autenticación.

Fase de autenticación

Esta fase es opcional. Permite a los lados autenticarse antes de establecer una conexión. Si tiene éxito, el control va a la fase de protocolo de cadena de red.

Network-Layer Protocol Fase

Esta fase es donde cada protocolo deseado Se invocan protocolos de control de redes. Por ejemplo, IPCP se utiliza para establecer el servicio IP en la línea. El transporte de datos para todos los protocolos que se inician con éxito con sus protocolos de control de red también ocurre en esta fase. El cierre de protocolos de red también ocurre en esta fase.

Terminación de enlace Fase

Esta fase cierra esta conexión. Esto puede suceder si hay un fallo de autenticación, si hay tantos errores de checksum que las dos partes deciden derribar el enlace automáticamente, si el enlace de repente falla, o si el usuario decide colgar una conexión.

A través de varios enlaces

PPP multienlace

PPP multienlace (también conocido como MLPPP, MP, MPPP, MLP, o Multilink) proporciona un método para distribuir el tráfico a través de múltiples conexiones PPP distintas. Se define en RFC 1990. Se puede usar, por ejemplo, para conectar una computadora doméstica a un proveedor de servicios de Internet usando dos módems tradicionales de 56k, o para conectar una empresa a través de dos líneas alquiladas.

En una sola línea PPP, los marcos no pueden llegar desordenados, pero esto es posible cuando los marcos se dividen entre varias conexiones PPP. Por lo tanto, Multilink PPP debe numerar los fragmentos para que puedan volver a colocarse en el orden correcto cuando lleguen.

Multilink PPP es un ejemplo de una tecnología de agregación de enlaces. Cisco IOS versión 11.1 y posteriores admiten Multilink PPP.

PPP multiclase

Con PPP, no se pueden establecer varias conexiones PPP distintas simultáneas a través de un solo enlace.

Eso tampoco es posible con Multilink PPP. Multilink PPP utiliza números contiguos para todos los fragmentos de un paquete, por lo que no es posible suspender el envío de una secuencia de fragmentos de un paquete para enviar otro paquete. Esto evita ejecutar Multilink PPP varias veces en los mismos enlaces.

PPP multiclase es una especie de PPP multienlace donde cada "clase" del tráfico utiliza un espacio de número de secuencia separado y un búfer de reensamblado. PPP multiclase se define en RFC 2686

Túneles

Protocolos derivados

PPTP (protocolo de tunelización punto a punto) es una forma de PPP entre dos hosts a través de GRE mediante encriptación (MPPE) y compresión (MPPC).

Como un protocolo de capa 2 entre ambos extremos de un túnel

Se pueden utilizar muchos protocolos para canalizar datos a través de redes IP. Algunos de ellos, como SSL, SSH o L2TP, crean interfaces de red virtual y dan la impresión de conexiones físicas directas entre los extremos del túnel. En un host Linux, por ejemplo, estas interfaces se llamarían tun0 o ppp0.

Como solo hay dos extremos en un túnel, el túnel es una conexión punto a punto y PPP es una opción natural como protocolo de capa de enlace de datos entre las interfaces de red virtual. PPP puede asignar direcciones IP a estas interfaces virtuales y estas direcciones IP se pueden usar, por ejemplo, para enrutar entre las redes en ambos lados del túnel.

IPsec en modo de tunelización no crea interfaces físicas virtuales al final del túnel, ya que el túnel es manejado directamente por la pila TCP/IP. L2TP se puede utilizar para proporcionar estas interfaces, esta técnica se denomina L2TP/IPsec. También en este caso, PPP proporciona direcciones IP a los extremos del túnel.

Estándares IETF

PPP se define en RFC 1661 (Protocolo punto a punto, julio de 1994). RFC 1547 (Requisitos para un protocolo punto a punto estándar de Internet, diciembre de 1993) proporciona información histórica sobre la necesidad de PPP y su desarrollo. Se ha escrito una serie de RFC relacionados para definir cómo una variedad de protocolos de control de red, incluidos TCP/IP, DECnet, AppleTalk, IPX y otros, funcionan con PPP.

• RFC 1332, The PPP Internet Protocol Control Protocol (IPCP)
• RFC 1661, Standard 51, The Point-to-Point Protocol (PPP)
• RFC 1662, Standard 51, PPP en formato HDLC
• RFC 1962, PPP Protocolo de Control de Compresión (CCP)
• RFC 1963, PPP Protocolo de transporte de datos serie
• RFC 1877, PPP Internet Protocol Control Protocol Extensiones para direcciones de servidor de nombres
• RFC 1990, The PPP Multilink Protocol (MP)
• RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)
• RFC 2153, Informational, PPP Vendor Extensiones
• RFC 2284, PPP Protocolo de autenticación extensible
• RFC 2364, PPP sobre ATM
• RFC 2516, PPP sobre Ethernet
• RFC 2615, PPP sobre SONET/SDH
• RFC 2686, La extensión multi-clase a PPP multi-Link
• RFC 2687, estándar propuesto, PPP en un marco de HDLC orientado en tiempo real
• RFC 5072, IP Version 6 sobre PPP
• RFC 5172, Negociación para la compresión de datagramas IPv6 usando el protocolo de control IPv6
• RFC 6361, PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol

Borradores adicionales:

• PPP Internet Protocol Control Protocol Extensions for IP Subnet (draft)
• PPP IPV6 Protocolo de Control Extensiones para direcciones de servidor DNS (proyecto)
• PPP Internet Protocol Control Protocol Extensions for Route Table Entries (draft)
• PPP Consistent Overhead Byte Stuffing (draft) (cf. Consistent Overhead Byte Stuffing)