Protocolo punto-a-punto

En las redes informáticas, el Protocolo de punto-a-punto o PPP (por sus siglas en inglés Point-to-Point Protocol) es un protocolo de comunicación de capa de enlace de datos (capa 2) entre dos enrutadores directamente sin ningún host ni ninguna otra red en el medio. Puede proporcionar autenticación de conexión, cifrado de transmisión y compresión de datos.

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 una conexión de servicio de Internet de línea de suscriptor digital (DSL) 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 de 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 fue diseñado algo 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. Un protocolo de control de enlace (LCP) para establecer, configurar y probar el enlace, así como negociar configuraciones, opciones y el uso de funciones.
3. Uno o más protocolos de control de red (NCP) utilizados para negociar parámetros de configuración opcionales y facilidades para la capa de red. Hay un NCP para cada protocolo de capa superior compatible con PPP.

Autoconfiguración automática

LCP inicia y termina 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.

Una vez que se ha establecido el enlace, puede tener lugar 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 la información de la capa de red, por ejemplo, la dirección de red o las opciones de compresión, una vez que se ha 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 capa 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 entre redes (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 de DECnet (DNCP) para el protocolo de enrutamiento de fase IV de ADN (DECnet fase IV), número de código de protocolo 0x8027, RFC 1762
• el protocolo de control de tramas NetBIOS (NBFCP) para el protocolo de tramas NetBIOS (o NetBEUI, como se llamaba antes), número de código de protocolo 0x803F, RFC 2097
• el Protocolo de control de 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 usando 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 presentó el uso de las opciones de LCP para cumplir con los requisitos de conexión WAN específicos. PPP puede incluir las siguientes opciones de LCP:

• Autenticación: los enrutadores del mismo nivel intercambian mensajes de autenticación. Dos opciones de autenticación son el Protocolo de autenticación de contraseña (PAP) y el Protocolo de autenticación por desafío mutuo (CHAP). La autenticación se explica en la siguiente sección.
• Compresión: aumenta el rendimiento efectivo en las conexiones PPP al reducir la cantidad de datos en el marco que debe viajar a través del enlace. El protocolo descomprime la trama en su destino. Ver RFC 1962 para más detalles.
• Detección de errores: identifica las condiciones de falla. Las opciones Quality y Magic Number ayudan a garantizar un enlace de datos confiable y sin bucles. El campo Número mágico ayuda a detectar enlaces que están en una condición de bucle invertido. Hasta que la Opción de Configuración del Número Mágico se haya negociado con éxito, el Número Mágico debe transmitirse como cero. Los números mágicos se generan aleatoriamente en cada extremo de la conexión.
• Multilink: proporciona equilibrio de carga en varias interfaces utilizadas por PPP a través de Multilink PPP (consulte a continuación).

Marco PPP

Estructura

Los marcos PPP son variantes de los marcos HDLC:

Nombre	Número de bytes	Descripción
Bandera	1	0x7E, el comienzo de un marco PPP
Dirección	1	0xFF, dirección de transmisión estándar
Control	1	0x03, datos sin numerar
Protocolo	2	PPP ID de datos incrustados
Información	variable (0 o más)	datagrama
Relleno	variable (0 o más)	relleno opcional
Secuencia de comprobación de fotogramas	2	suma de comprobación del marco
Bandera	1	0x7E, omitido para paquetes PPP sucesivos

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.

Nombre	Número de bytes	Descripción
Bandera	1	indica el comienzo o el final del marco
Dirección	1	dirección de Difusión
Control	1	byte de control
Protocolo	1 o 2 o 3	l en el campo de información
Información	variable (0 o más)	datagrama
Relleno	variable (0 o más)	relleno opcional
SFC	2 (o 4)	comprobación de errores

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 hexadecimal 03 (para "información no numerada"), y se pueden omitir siempre que se negocie la compresión de campo de dirección y control (ACFC) de PPP LCP..

El campo de secuencia de verificación de trama (FCS) se utiliza 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 de 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 muertoEsta fase ocurre cuando el enlace falla, o se le dice a un lado que se desconecte (por ejemplo, un usuario ha terminado su conexión de acceso telefónico).Fase de establecimiento del enlaceEsta fase es donde se intenta la negociación del Protocolo de control de enlace. Si tiene éxito, el control pasa a la fase de autenticación o a la fase de protocolo de capa de red, dependiendo de si se desea la autenticación.Fase de autenticaciónEsta fase es opcional. Permite que los lados se autentiquen entre sí antes de que se establezca una conexión. Si tiene éxito, el control pasa a la fase de protocolo de la capa de red.Fase de protocolo de capa de redEsta fase es donde se invocan los Protocolos de control de red de cada protocolo deseado. Por ejemplo, IPCP se utiliza para establecer el servicio IP a través de 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 se produce en esta fase. El cierre de los protocolos de red también se produce en esta fase.Fase de terminación del enlaceEsta fase cierra esta conexión. Esto puede suceder si hay una falla de autenticación, si hay tantos errores de suma de verificación que las dos partes deciden eliminar el enlace automáticamente, si el enlace falla repentinamente o si el usuario decide cortar la conexión.

A través de varios enlaces

PPP multienlace

Multilink PPP (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, las tramas no pueden llegar desordenadas, pero esto es posible cuando las tramas se dividen entre múltiples 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 sobre 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.

El PPP multiclase es un tipo de PPP multienlace en el que cada "clase" de tráfico utiliza un espacio de números de secuencia y un búfer de reensamblaje separados. PPP multiclase se define en RFC 2686

Túneles

Solicitud	FTP	SMTP	HTTP	…	DNS	…
Transporte	TCP	UDP
La red	IP
Enlace de datos	PPA
Solicitud	SSH
Transporte	TCP
La red	IP
Enlace de datos	ethernet	Cajero automático
Físico	Cables, concentradores, etc.

Protocolos derivados

PPTP (protocolo de tunelización punto a punto) es una forma de PPP entre dos hosts a través de GRE mediante cifrado (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 puntos finales 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 el modo de tunelización no crea interfaces físicas virtuales al final del túnel, ya que el túnel lo maneja directamente 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, el protocolo de control de protocolo de Internet PPP (IPCP)
• RFC 1661, Estándar 51, Protocolo punto a punto (PPP)
• RFC 1662, estándar 51, PPP en estructura similar a HDLC
• RFC 1962, Protocolo de control de compresión PPP (CCP)
• RFC 1963, Protocolo de transporte de datos en serie PPP
• RFC 1877, extensiones de protocolo de control de protocolo de Internet PPP para direcciones de servidores de nombres
• RFC 1990, el protocolo multienlace PPP (MP)
• RFC 1994, Protocolo de autenticación por desafío mutuo (CHAP) de PPP
• RFC 2153, Informativo, Extensiones de proveedores de PPP
• RFC 2284, PPP Protocolo de autenticación extensible (EAP)
• RFC 2364, PPP sobre cajero automático
• RFC 2516, PPP sobre Ethernet
• RFC 2615, PPP sobre SONET/SDH
• RFC 2686, la extensión multiclase para PPP multienlace
• RFC 2687, estándar propuesto, PPP en un marco similar a HDLC orientado en tiempo real
• RFC 5072, IP Versión 6 sobre PPP
• RFC 5172, Negociación para la compresión de datagramas IPv6 mediante el protocolo de control IPv6
• RFC 6361, PPP Protocolo de control de protocolo de interconexión transparente de muchos enlaces (TRILL)

Borradores adicionales:

• Extensiones de protocolo de control de protocolo de Internet PPP para subred IP (borrador)
• Extensiones del protocolo de control PPP IPV6 para direcciones de servidor DNS (borrador)
• Extensiones de protocolo de control de protocolo de Internet PPP para entradas de tabla de rutas (borrador)
• PPP Relleno de bytes de sobrecarga coherente (borrador) (cf. Relleno de bytes de sobrecarga coherente)