Point-to-Point Protocol- Point-to-Point Protocol

Internettprotokollpakke
Påføringslag
Transportlag
Internett -lag
Linklag

I datanettverk er Point-to-Point Protocol ( PPP ) en datalinklag (lag 2) kommunikasjonsprotokoll mellom to rutere direkte uten noen vert eller annet nettverk i mellom. Det kan gi forbindelse autentisering , transmisjon kryptering , og datakomprimering .

PPP brukes over mange typer fysiske nettverk, inkludert seriell kabel , telefonlinje , stamledning , mobiltelefon , spesialiserte radiokoblinger, ISDN og fiberoptiske koblinger som SONET . Siden IP-pakker ikke kan overføres over en modemlinje alene uten noen datalink-protokoll som kan identifisere hvor den overførte rammen starter og hvor den slutter, har Internett-leverandører (ISPer) brukt PPP for oppringt tilgang til Internett fra kunder .

To derivater av PPP, Point-to-Point Protocol over Ethernet (PPPoE) og Point-to-Point Protocol over ATM (PPPoA), brukes oftest av Internett-leverandører for å etablere en digital abonnentlinje (DSL) Internett-tjenesteforbindelse med kunder.

Beskrivelse

PPP brukes ofte som en datalinklagsprotokoll for tilkobling over synkrone og asynkrone kretser , der den i stor grad har erstattet de eldre Serial Line Internet Protocol (SLIP) og telefonselskapets mandatstandarder (for eksempel Link Access Protocol, Balanced (LAPB) i X.25 -protokolsuite). Det eneste kravet for PPP er at kretsen som tilbys er tosidig . PPP ble designet for å fungere med mange nettverkslagsprotokoller , inkludert Internet Protocol (IP), TRILL , Novells Internetwork Packet Exchange (IPX), NBF , DECnet og AppleTalk . Som SLIP er dette en full Internett -tilkobling over telefonlinjer via modem. Det er mer pålitelig enn SLIP fordi det dobbeltsjekker for å sikre at internettpakker kommer intakt. Den sender eventuelle skadede pakker på nytt.

PPP ble designet noe etter de originale HDLC -spesifikasjonene. Designerne av PPP inkluderte mange tilleggsfunksjoner som bare hadde blitt sett i proprietære datalink-protokoller fram til den tiden. PPP er spesifisert i RFC 1661.

RFC 2516 beskriver Point-to-Point Protocol over Ethernet (PPPoE) som en metode for overføring av PPP over Ethernet som noen ganger brukes med DSL . RFC 2364 beskriver Point-to-Point Protocol over ATM (PPPoA) som en metode for overføring av PPP over ATM Adaptation Layer 5 ( AAL5 ), som også er et vanlig alternativ til PPPoE som brukes med DSL.

PPP, PPPoE og PPPoA er mye brukt i WAN -linjer.

PPP er en lagdelt protokoll som har tre komponenter:

  1. En innkapslingskomponent som brukes til å overføre datagrammer over det spesifiserte fysiske laget .
  2. En Link Control Protocol (LCP) for å etablere, konfigurere og teste lenken samt forhandle om innstillinger, alternativer og bruk av funksjoner.
  3. En eller flere Network Control Protocols (NCP) brukes til å forhandle om valgfrie konfigurasjonsparametere og fasiliteter for nettverkslaget. Det er én NCP for hver protokoll med høyere lag som støttes av PPP.

Automatisk selvkonfigurasjon

LCP starter og avslutter tilkoblinger grasiøst, slik at verter kan forhandle om tilkoblingsalternativer. Det er en integrert del av OPS, og er definert i samme standardspesifikasjon. LCP gir automatisk konfigurasjon av grensesnittene i hver ende (for eksempel innstilling av datagramstørrelse , rømte tegn og magiske tall) og for valg av valgfri autentisering. LCP -protokollen kjøres på toppen av PPP (med PPP -protokollnummer 0xC021), og derfor må en grunnleggende PPP -tilkobling opprettes før LCP kan konfigurere den.

RFC 1994 beskriver Challenge-Handshake Authentication Protocol (CHAP), som er foretrukket for å etablere oppringte forbindelser med Internett-leverandører. Selv om den er utdatert, brukes passordautentiseringsprotokoll (PAP) fremdeles noen ganger.

Et annet alternativ for autentisering over PPP er Extensible Authentication Protocol (EAP) beskrevet i RFC 2284.

Etter at koblingen er opprettet, kan det hende at ytterligere nettverkskonfigurasjon ( lag 3 ) finner sted. Vanligvis brukes Internet Protocol Control Protocol (IPCP), selv om Internetwork Packet Exchange Control Protocol (IPXCP) og AppleTalk Control Protocol (ATCP) en gang var populære. Internet Protocol Version 6 Control Protocol (IPv6CP) vil se utvidet bruk i fremtiden, når IPv6 erstatter IPv4 som den dominerende lag-3-protokollen.

Flere protokoller for nettverkslag

PPP -arkitektur
IP
LCP CHAP PAP EAP IPCP
PPP -innkapsling
HDLC -lignende innramming PPPoE PPPoA
RS-232 POS Ethernet Minibank
SONET/SDH

PPP tillater flere nettverkslagsprotokoller å operere på den samme kommunikasjonslenken. For hver nettverkslagsprotokoll som brukes, tilbys en egen Network Control Protocol (NCP) for å innkapsle og forhandle alternativer for flere nettverkslagsprotokoller. Den forhandler informasjon om nettverkslag, f.eks. Nettverksadresse eller komprimeringsalternativer, etter at forbindelsen er opprettet.

For eksempel bruker IP IPCP, og Internetwork Packet Exchange (IPX) bruker Novell IPX Control Protocol ( IPX/SPX ). NCPer inkluderer felt som inneholder standardiserte koder for å indikere nettverkslagsprotokolltypen som PPP -tilkoblingen innkapsler.

Følgende NCP kan brukes med PPP:

Sløyfed koblingsdeteksjon

PPP oppdager koblede koblinger ved hjelp av en funksjon som involverer magiske tall . Når noden sender PPP LCP -meldinger, kan disse meldingene inneholde et magisk nummer. Hvis en linje sløyfes, mottar noden en LCP -melding med sitt eget magiske nummer, i stedet for å få en melding med kollegaens magiske nummer.

Konfigurasjonsalternativer

Den forrige delen introduserte bruken av LCP -alternativer for å oppfylle spesifikke WAN -tilkoblingskrav. PPP kan inneholde følgende LCP -alternativer:

  • Godkjenning - Peer -rutere utveksler autentiseringsmeldinger. To godkjenningsvalg er Password Authentication Protocol (PAP) og Challenge Handshake Authentication Protocol (CHAP). Autentisering forklares i neste avsnitt.
  • Komprimering - Øker den effektive gjennomstrømningen på PPP -tilkoblinger ved å redusere mengden data i rammen som må reise over lenken. Protokollen dekomprimerer rammen på destinasjonen. Se RFC 1962 for mer informasjon.
  • Feildeteksjon - Identifiserer feiltilstander. Kvalitets- og magiske tallalternativer bidrar til å sikre en pålitelig, sløyfefri datalink. Magisk nummer-feltet hjelper deg med å oppdage koblinger som er i en tilbakeført tilstand. Inntil konfigurasjonsalternativet for Magic-Number er vellykket, må Magic-Number overføres som null. Magiske tall genereres tilfeldig i hver ende av forbindelsen.
  • Multilink - Gir lastbalansering av flere grensesnitt som brukes av PPP til Multilink PPP (se nedenfor).

PPP -ramme

Struktur

PPP -rammer er varianter av HDLC -rammer :

Navn Antall byte Beskrivelse
Flagg 1 0x7E, begynnelsen på en PPP -ramme
Adresse 1 0xFF, standard kringkastingsadresse
Kontroll 1 0x03, unummererte data
Protokoll 2 PPP -ID for innebygde data
Informasjon variabel (0 eller mer) datagram
Polstring variabel (0 eller mer) valgfri polstring
Ramme sjekk sekvens 2 rammesjekk
Flagg 1 0x7E, utelatt for påfølgende PPP -pakker

Hvis begge jevnaldrende godtar Adressefelt og Kontrollfeltkomprimering under LCP, blir disse feltene utelatt. På samme måte hvis begge jevnaldrende godtar protokollfeltkomprimering, kan 0x00 byte utelates.

Protokoll feltet indikerer typen av nyttelast-pakke: 0xC021 for LCP , 0x80xy for forskjellige NCP , 0x0021 for IP, 0x0029 Talk, 0x002B for IPX , 0x003D for Multi, 0x003F for NetBIOS , 0x00FD for MPPC og MPPE , etc. PPP er begrenset, og kan ikke inneholde generelle lag 3 -data, i motsetning til EtherType .

Informasjonsfeltet inneholder PPP nyttelast; den har en variabel lengde med et forhandlet maksimum som kalles maksimal overføringsenhet . Som standard er maksimum 1500 oktetter . Det kan være polstret på overføringen; Hvis informasjonen for en bestemt protokoll kan polstres, må denne protokollen tillate at informasjon skilles fra polstring.

Innkapsling

PPP-rammer er innkapslet i en protokoll med lavere lag som gir innramming og kan gi andre funksjoner, for eksempel en kontrollsum for å oppdage overføringsfeil. PPP på serielle lenker er vanligvis innkapslet i en ramme som ligner på HDLC , beskrevet av IETF RFC 1662.

Navn Antall byte Beskrivelse
Flagg 1 indikerer at rammen begynner eller slutter
Adresse 1 kringkastingsadresse
Kontroll 1 kontrollbyte
Protokoll 1 eller 2 eller 3 l i informasjonsfeltet
Informasjon variabel (0 eller mer) datagram
Polstring variabel (0 eller mer) valgfri polstring
FCS 2 (eller 4) feilsøking

Flaggfeltet er tilstede når PPP med HDLC-lignende innramming brukes.

Adresse- og kontrollfeltene har alltid verdien hex FF (for "alle stasjoner") og hex 03 (for "unummerert informasjon"), og kan utelates når PPP LCP Address-and-Control-Field-Compression (ACFC) forhandles .

Den ramme-kontrollsekvens (FCS) feltet brukes for å bestemme hvorvidt et individ ramme har en feil. Den inneholder en kontrollsum beregnet over rammen for å gi grunnleggende beskyttelse mot feil i overføringen. Dette er en CRC -kode som ligner den som ble brukt for andre lag to protokollfeilbeskyttelsesordninger, for eksempel den som ble brukt i Ethernet. I følge RFC 1662 kan den enten være 16 bits (2 byte) eller 32 bits (4 byte) i størrelse (standard er 16 bits - Polynom x 16 + x 12 + x 5 + 1).

FCS beregnes over feltene Adresse, Kontroll, Protokoll, Informasjon og Polstring etter at meldingen er innkapslet.

Linjeaktivering og faser

Link Dead
Denne fasen skjer når lenken mislykkes, eller den ene siden har blitt fortalt å koble fra (f.eks. Har en bruker fullført oppringingsforbindelsen.)
Link Etablering Fase
Denne fasen er hvor Link Control Protocol -forhandling forsøkes. Hvis det lykkes, går kontrollen enten til autentiseringsfasen eller Network-Layer Protocol-fasen, avhengig av om autentisering er ønsket.
Autentiseringsfase
Denne fasen er valgfri. Det lar sidene autentisere hverandre før en forbindelse opprettes. Hvis det lykkes, går kontrollen til protokollfasen for nettverkslaget.
Nettverkslagsprotokollfase
Denne fasen er der hver protokolls nettverkskontrollprotokoller påkalles. For eksempel brukes IPCP for å etablere IP -tjenester over linjen. Datatransport for alle protokoller som er vellykket startet med nettverkskontrollprotokollene skjer også i denne fasen. Nedleggelse av nettverksprotokoller skjer også i denne fasen.
Link Termination Phase
Denne fasen stenger denne forbindelsen. Dette kan skje hvis det er en autentiseringsfeil, hvis det er så mange kontrollsumfeil at de to partene bestemmer seg for å rive koblingen automatisk, hvis koblingen plutselig mislykkes, eller hvis brukeren bestemmer seg for å legge på en tilkobling.

Over flere lenker

Multilink PPP

Multilink PPP (også referert til som MLPPP , MP , MPPP , MLP eller Multilink) gir en metode for å spre trafikk over flere forskjellige PPP -tilkoblinger. Den er definert i RFC 1990. Den kan for eksempel brukes til å koble en hjemmedatamaskin til en Internett -leverandør ved hjelp av to tradisjonelle 56k -modemer, eller for å koble et selskap gjennom to leide linjer.

På en enkelt PPP -linje kan rammer ikke komme ut av drift, men dette er mulig når rammene er delt mellom flere PPP -tilkoblinger. Derfor må Multilink PPP nummerere fragmentene slik at de kan settes i riktig rekkefølge igjen når de kommer.

Multilink PPP er et eksempel på en koblingaggregasjonsteknologi . Cisco IOS versjon 11.1 og nyere støtter Multilink PPP.

PPP i flere klasser

Med PPP kan man ikke opprette flere samtidige distinkte PPP -tilkoblinger over en enkelt lenke.

Det er heller ikke mulig med Multilink PPP. Multilink PPP bruker sammenhengende tall for alle fragmentene i en pakke, og som en konsekvens er det ikke mulig å suspendere sending av en sekvens av fragmenter av en pakke for å sende en annen pakke. Dette forhindrer å kjøre Multilink PPP flere ganger på de samme koblingene.

Multiklasse PPP er en slags Multilink PPP der hver "klasse" av trafikk bruker et eget sekvensnummerrom og en samlingsbuffer. Multiklasse PPP er definert i RFC 2686

Tunneler

Forenklet OSI -protokollstabel for et eksempel SSH +PPP -tunnel
applikasjon FTP SMTP HTTP … DNS …
Transportere TCP UDP
Nettverk IP
Data lenke OPS
applikasjon SSH
Transportere TCP
Nettverk IP
Data lenke Ethernet Minibank
Fysisk Kabler, hubber og så videre

Avledede protokoller

PPTP (Point-to-Point Tunneling Protocol) er en form for PPP mellom to verter via GRE ved bruk av kryptering ( MPPE ) og komprimering ( MPPC ).

Som en lag 2 -protokoll mellom begge ender av en tunnel

Mange protokoller kan brukes til å tunnelere data over IP -nettverk. Noen av dem, som SSL , SSH eller L2TP, lager virtuelle nettverksgrensesnitt og gir inntrykk av direkte fysiske forbindelser mellom tunnelens endepunkter. For eksempel på en Linux -vert vil disse grensesnittene bli kalt tun0 eller ppp0 .

Siden det bare er to endepunkter på en tunnel, er tunnelen en punkt-til-punkt-forbindelse og PPP er et naturlig valg som en datalinklagsprotokoll mellom de virtuelle nettverksgrensesnittene. PPP kan tildele IP -adresser til disse virtuelle grensesnittene, og disse IP -adressene kan for eksempel brukes til å rute mellom nettverkene på begge sider av tunnelen.

IPsec i tunnelmodus lager ikke virtuelle fysiske grensesnitt i enden av tunnelen, siden tunnelen håndteres direkte av TCP/IP -stakken. L2TP kan brukes til å gi disse grensesnittene, denne teknikken kalles L2TP/IPsec. Også i dette tilfellet gir PPP IP -adresser til ytterpunktene i tunnelen.

IETF -standarder

PPP er definert i RFC 1661 (The Point-to-Point Protocol, juli 1994). RFC 1547 (Krav til en Internet Standard Point-to-Point Protocol, desember 1993) gir historisk informasjon om behovet for OPS og dens utvikling. En rekke relaterte RFC-er er skrevet for å definere hvordan en rekke nettverkskontrollprotokoller-inkludert TCP/IP , DECnet , AppleTalk , IPX og andre-fungerer med PPP.

  • RFC  1332 , PPP Internet Protocol Control Protocol (IPCP)
  • RFC  1661 , Standard 51, Point-to-Point Protocol (PPP)
  • RFC  1662 , Standard 51, PPP i HDLC-lignende innramming
  • RFC  1962 , PPP Compression Control Protocol (CCP)
  • RFC  1963 , PPP Serial Data transport Protocol
  • RFC  1877 , PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
  • RFC  1990 , PPP Multilink Protocol (MP)
  • RFC  1994 , PPP Challenge Handshake Authentication Protocol (CHAP)
  • RFC  2153 , Informasjonelle, PPP -leverandørutvidelser
  • RFC  2284 , PPP Extensible Authentication Protocol (EAP)
  • RFC  2364 , PPP over minibank
  • RFC  2516 , PPP over Ethernet
  • RFC  2615 , PPP over SONET/SDH
  • RFC  2686 , Multi-Class Extension to Multi-Link PPP
  • RFC  2687 , foreslått standard, PPP i sanntidsorientert HDLC-lignende innramming
  • RFC  5072 , IP versjon 6 over PPP
  • RFC  5172 , Forhandling for IPv6 Datagram -komprimering ved hjelp av IPv6 -kontrollprotokoll
  • RFC  6361 , PPP Transparent sammenkobling av mange koblinger ( TRILL ) Protocol Control Protocol

Ytterligere utkast:

Se også

Referanser