IPv4

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 23. december 2021; checks kræver 7 redigeringer .
IPv4
Navn Internet protokol version 4
Niveau (ifølge OSI-modellen ) netværk
Familie TCP/IP
Oprettet i 1981
Formål med protokollen Adressering
Specifikation RFC 791
Vigtigste implementeringer (klienter) TCP/IP stakimplementeringer på Windows , Linux og BSD , Mac OS
Kerneimplementeringer ( servere ) implementeringer af TCP/IP-stakken i Windows , Linux og BSD
 Mediefiler på Wikimedia Commons

IPv4 ( engelsk  Internet Protocol version 4 ) er den fjerde version af Internet Protocol ( IP ). Første udbredte version. Protokollen er beskrevet i RFC 791 (september 1981), som afløser RFC 760 (januar 1980).

Adresserepræsentation

IPv4 bruger 32 - bit ( fire byte ) adresser, hvilket begrænser adresserummet til 4294967296 (232 ) mulige unikke adresser.

Den traditionelle form for en IPv4-adresse er fire decimaltal (0 til 255) adskilt af prikker. Brøken angiver længden af ​​undernetmasken .

Tilmeldingsformular Eksempel Konverter fra punkteret decimalnotation
Stiplet decimal 192.0.2.235 —
Punkteret hexadecimal 0xC0.0x00.0x02.0xEB Hver oktet konverteres til hexadecimal
Punkteret oktal 0300.0000.0002.0353 Hver oktet konverteres til oktal
Hexadecimal 0xC00002EB Sammenkædning af oktetter fra punkteret hexadecimal notation
Decimal 3221226219 32-bit tal i decimalform
oktal 030000001353 32-bit tal i oktal form

Adressering: værter og undernet

En tidlig version af IP-standarden, ifølge RFC 760  ( januar 1980), beskrev en stiv opdeling af adresserummet i undernet og værter. Den første oktet var netværksadressen, efterfulgt af den lokale værtsadresse i de resterende tre oktetter. Således tillod standarden eksistensen af ​​2^8=256 netværk med 2^24=16.777.216 værter hver.

Subnetstørrelsen er fast.

Klassisk adressering

Det stod dog hurtigt klart, at netværkene var for få, for store, og at adressering manglede fleksibilitet. Derfor blev RFC 791  (engelsk) allerede i september 1981 udgivet , som introducerede den såkaldte classful adressering. Ideen er denne: For fleksibilitet i tildelingen af ​​netværksadresser og muligheden for at bruge et stort antal små og mellemstore netværk blev adresserummet opdelt i flere logiske grupper, og hver gruppe havde et forskelligt forhold mellem værter og undernet. Disse grupper er opkaldt efter netværksklasser og er nummereret med latinske bogstaver: A, B, C, D og E. Inddelingen er baseret på de væsentligste bits af adressen. Adressering er beskrevet detaljeret i RFC 790  .

Klasse A : 0.XXX.XXX.XXX - 127.XXX.XXX.XXX

Den første bit af adressen er nul, så klasse A optager halvdelen af ​​hele adresserummet. Netværksadressen er 7 bit, værtsadressen er 24 bit, så klasse A indeholder 128 undernet med hver 16.777.216 adresser.

For eksempel subnet 10.0.0.0 (klasse A, indeholder mere end 16,7 millioner adresser fra 10.0.0.0 til 10.255.255.255). Reserveret som standard, ikke routbar på internettet og bruges til at bygge lokale og virksomhedsnetværk.

ss B : 128.0.XXX.XXX - 191.255.XXX.XXX

Vores adresse starter også med bit 1,0, så klasse B fylder en fjerdedel af hele adressepladsen. Netværksadressen er 14 bit, værtsadressen er 16 bit, så klasse B indeholder 16.384 undernet med hver 65.536 adresser.

For eksempel klasse B netværk 169.254.XX med 65536 adresser. Reserveret til "kanal"-adresser.

Klasse C : 192.0.0.XXX - 223.255.255.XXX

Adressen starter med bit 1,1,0, så klasse C optager 1/8 af adressepladsen. En netværksadresse er 21 bit, en værtsadresse er 8 bit, så klasse C indeholder 2.097.152 netværk med hver 256 adresser.

For eksempel har netværket 192.0.2.X adresserne 192.0.2.0 til 192.0.2.255, reserveret til dokumentationseksempler.

I 1990 beskrev RFC 1166  yderligere to klasser.

Klasse D : 224.XXX.XXX.XXX - 239.XXX.XXX.XXX

Adressen starter med bit 1,1,1,0. Klasse D optager 1/16 af adressepladsen. Bruges til multicasting.

Klasse E : 240.XXX.XXX.XXX - 255.XXX.XXX.XXX.

Adressen starter med bit 1,1,1,1. Sådanne adresser er forbudte. Reserveret til fremtidig brug.

Til sammenligning ser størrelserne af undernetklasser sådan ud:

klasser: EN B C D E

Med klassificeret adressering beregnes undernetstørrelsen ud fra ip-adressen.

Klasseløs adressering

Med internettets vækst viste dette system sig at være ineffektivt og blev suppleret med klasseløs adressering (CIDR). En yderligere metrik blev introduceret - undernetmasken, som bestemmer, hvor mange bits af adressen, der er tildelt til netværksadressen, og hvor mange - til værtsadressen.

Subnet-tildelinger

Nogle IPv4-adresser er reserveret til specielle formål og er ikke beregnet til global routing [1] . Listen over undernet til særlige formål er defineret af RFC 6890 . Tabellen nedenfor viser de vigtigste (listen er ikke komplet).

Undernet Formål Routing
0.0.0.0/8[2 ] Adresser på pakkekilder til "dette" ("egne") netværk [1] [3] . forbudt
0.0.0.0/32 På stik med "lytte"-tilstand betyder det enhver kilde-IP eller et hvilket som helst destinationsnetværk på den aktuelle vært. Kan kun sendes til netværket som kildeadresse, hvis værten endnu ikke er blevet tildelt en IP-adresse (normalt via DHCP ). Kan ikke bruges som netværksdestination.

På Cisco-routere, hvis du forsøger at sende en pakke til adresse 0.0.0.0, vil den blive sendt til broadcast-adressen på det mindste tilsluttede undernet (forbundet i routing-tabellen).

forbudt
10.0.0.0/8[4 ] Til brug i private netværk . RFC 1918 . De fleste af IPv4-adresserne i Gwangmyeong-netværket (DPRK) [5] . Global routing er deaktiveret.
100.64.0.0/10 Delt adresseområde. RFC 6598 . Til brug på tjenesteudbydernetværk. De fleste af IPv4-adresserne bruges til NAT - abonnenter af ER-Telecom , Beeline osv. Global routing er forbudt.
127.0.0.0/8[2 ] Undernettet til kommunikation inden for værten (se localhost ). Netværksundersystemet bruges, men sådanne pakker passerer faktisk ikke gennem netværkskortet. Hvis en pakke med samme destinationsadresse blev modtaget fra netværket, SKAL den kasseres. forbudt
169.254.0.0/16 [6] kanal adresser . Undernettet bruges til automatisk IP-tildeling af operativsystemet, hvis DHCP er konfigureret, men ingen server svarer. kun på private netværk
172.16.0.0/12 [4] Til brug i private netværk . RFC 1918 . del af IPv4-adresserne i Gwangmyeon-netværket (DPRK) [5] . Global routing er deaktiveret.
192.0.0.0/24[7 ] IETF Protocol Assignments
192.0.0.0/29 Dual-Stack Lite (DS-Lite). RFC 6333 . IPv6
192.0.0.170/32 NAT64
192.0.0.171/32 DNS64
192.0.2.0/24[8 ] For eksempler i dokumentationen. forbudt
192.88.99.0/24 [1] Bruges til at sende til den nærmeste node . RFC 3068 globalt tilladt
192.88.99.1/32 Anvendes som relæ til IPv6 til IPv4 indkapsling ( 6to4 ) [9] . Med andre ord er denne IP ikke unik. Mange virksomheder annoncerer det. En pakke til denne adresse vil gå til den nærmeste vært med denne IP, som vil pakke pakken ud og sende den videre langs IPv6-rutingen. globalt tilladt
192.168.0.0/16 [4] Til brug i private netværk. RFC 1918 . del af IPv4-adresserne i Gwangmyeon-netværket (DPRK) [5] . Global routing er deaktiveret.
198.51.100.0/24 [8] For eksempler i dokumentationen. forbudt
198.18.0.0/15 [10] Til præstationsprøvebænke. kun til prøver
203.0.113.0/24 [8] For eksempler i dokumentationen. forbudt
224.0.0.0/4 [11] Bruges til multicasting . For en komplet opdateret liste over reserverede blokke, se IANA -webstedet [1] . RFC 5771 reserverede multicast-undernet klarlagt . globalt kun tilladt for undernet 233.0.0.0/8 og 234.0.0.0/8.
240.0.0.0/4[2 ] Reserveret til fremtidig brug. Der er en opfattelse af, at dette subnet aldrig vil blive brugt igen, da der er meget udstyr, der ikke er i stand til at sende pakker til dette netværk. forbudt
255.255.255.255/32 [12] Begrænset udsendelsesadresse . Mest almindeligt brugt som destinationsadresse, når du slår DHCP-servere op. forbudt
Andet Distribueret af regionale internetregistratorer . Kan være udbyderuafhængig . globalt tilladt

Pakkehovedstruktur

IP-pakkehovedet indeholder 14 felter, hvoraf 13 er obligatoriske. Det fjortende felt er til valgfrie muligheder. Felterne bruger byte-rækkefølge fra høj til lav, med de mest signifikante bit først. Den første bit har tallet 0. Således er versionsfeltet for eksempel i de fire mest signifikante bits af den første byte. Når der sendes flere oktetværdier, sendes den mest signifikante oktet først.

IPv4-headerformat
Indryk Oktet 0 en 2 3
Oktet Bit 0 en 2 3 fire 5 6 7 0 en 2 3 fire 5 6 7 0 en 2 3 fire 5 6 7 0 en 2 3 fire 5 6 7
0 0 Version Header Størrelse Differentieret servicekodepunkt Eksplicit meddelelse om overbelastning Pakkestørrelse (fuld)
fire 32 Identifikator Flag Fragment offset
otte 64 Livstid Protokol Overskrift kontrolsum
12 96 Kilde IP-adresse
16 128 Destinations-IP-adresse
tyve 160 Valgmuligheder (hvis overskriftstørrelse > 5)
20 eller 24+ 160 eller 192+ Data
Version Det første felt i pakkehovedet er protokolversionen, som er fire bit lang. For IPv4 er det 4. Header Størrelse (Internet Header Længde) De næste fire bit indeholder størrelsen af ​​pakkehovedet i 32-bit ord . Da antallet af muligheder ikke er konstant, er det vigtigt at angive størrelsen for at adskille overskriften fra dataene. Minimumsværdien er 5 (5×32=160 bits, 20 bytes), maksimumværdien er 15 (60 bytes). Differentiated Services Code Point (DSCP) Oprindeligt kaldet "Type of Service" ( ToS), nu defineret af RFC 2474 som "Differentiated Services". Bruges til at opdele trafik i serviceklasser, for eksempel for at give forsinkelsesfølsom trafik som VoIP en højere prioritet. Congestion Pointer (Eksplicit Congestion Notification, ECN) Advarsel om overbelastning af netværk uden pakketab. Dette er en valgfri funktion og bruges kun, hvis begge værter understøtter det. Pakke størrelse Den 16-bit samlede pakkestørrelse i bytes, inklusive header og data. Minimumsstørrelsen er 20 bytes (header uden data), maksimum er 65535 bytes. Værter skal understøtte transmission af pakker op til 576 bytes, men moderne implementeringer understøtter typisk meget større størrelser. Pakker, der er større end kommunikationskanalen understøtter, er fragmenteret. Identifikator Bruges primært til at identificere fragmenter af en pakke, hvis den er blevet fragmenteret. Der er eksperimenter med at bruge det til andre formål, såsom tilføjelse af pakkesporingsinformation for at gøre det nemmere at spore stien til en pakke med en forfalsket kildeadresse [13] . Flag Et tre-bit felt, der indeholder fragmenteringskontrolflag. Bits, fra høj til lav, betyder:
  • 0: Reserveret, skal være 0 [14] .
  • 1: Lad være med at fragmentere
  • 2: Pakken har stadig fragmenter
Hvis flaget "fragmenter ikke" er indstillet, så vil en sådan pakke blive ødelagt, hvis fragmentering er nødvendig. Kan bruges til at sende data til værter, der ikke har tilstrækkelige ressourcer til at håndtere fragmenterede pakker. Flaget "har fragmenter" skal indstilles til 1 for alle fragmenter af pakken undtagen det sidste. Sæt til 0 for ikke-fragmenterede pakker - sådan en pakke betragtes som sit eget sidste fragment. Fragment offset 13-bit-feltet angiver forskydningen af ​​datafeltet for det aktuelle fragment i forhold til begyndelsen af ​​datafeltet for den første fragmenterede pakke i blokke på 8 bytes. Giver dig mulighed for at indstille til (2 13 −1)×8=65528 offset bytes. Når man overvejer header-størrelsen, kan den resulterende offset overstige den maksimale pakkestørrelse (65528 + 20 = 65548 bytes). Det første fragment i sekvensen har en offset på nul. "Time to Live" ( Time to Live , TTL)-pakke Angiver det maksimale antal routere langs pakkens sti. Tilstedeværelsen af ​​denne parameter tillader ikke pakken at krydse netværket uendeligt. Hver router skal nedsætte TTL-værdien med én, når en pakke behandles. Pakker, hvis levetid er blevet nul, kasseres, og en ICMP Time Exceeded-meddelelse sendes til afsenderen . Sporingen af ​​deres rejsesti ( traceroute ) er baseret på at sende pakker med forskellige levetider . Den maksimale værdi TTL=255. Normal startværdi TTL=64 (OS-afhængig). Protokol Angiver, hvilke IP-protokoloplysninger pakken indeholder (f.eks. TCP eller ICMP). Tildelte protokolnumre kan findes på IANA -webstedet [15] . Overskrift kontrolsum 16-bit checksum bruges til at kontrollere headerintegritet. Hver vært eller router sammenligner headerens kontrolsum med værdien af ​​dette felt og kasserer pakken, hvis de ikke matcher. IP kontrollerer ikke dataintegritet - den kontrolleres af højere lags protokoller (såsom TCP eller UDP ), der også bruger kontrolsummer. Da TTL dekrementeres ved hvert pakkehop, skal summen også beregnes ved hvert hop. Kontrolsumgenberegningsmetoden er defineret i RFC 1071 [16] . Kildeadresse 32-bit adressen på afsenderen af ​​pakken. Passer muligvis ikke til den faktiske afsenderadresse på grund af adresseoversættelse . Destinationsadresse 32-bit adressen på modtageren af ​​pakken. Det kan også ændre sig under adresseoversættelse. Muligheder Destinationsadressen kan efterfølges af et ekstra valgfelt, men dette bruges sjældent. Størrelsen af ​​overskriften skal i dette tilfælde være stor nok til at rumme alle mulighederne (med forbehold for udfyldning til et helt tal på 32-bit ord). Tildelte optionnumre er offentliggjort på IANA's hjemmeside. [17] Hvis listen over muligheder ikke er slutningen af ​​en overskrift, skal den slutte med mulighed 0x00. Indstillinger har følgende format:
Mark Bit størrelse Beskrivelse
Kopi en Indstil til 1, hvis indstillinger skal kopieres til overskrifterne på alle fragmenter.
Tilvalgsklasse 2 0 for "kontrol"-indstillinger og 2 for "mål og debug"-muligheder. 1 og 3 er forbeholdt.
Option nummer 5 Angiver en mulighed.
Mulighed Størrelse otte Angiver størrelsen af ​​indstillingen (inklusive dette felt). Kan udelades for muligheder uden argumenter.
Optionsargumenter Variabel Yderligere data, der bruges af muligheden.
  • Bemærk: Overskriftslængde på mere end 5 ord angiver tilstedeværelsen af ​​muligheder og behovet for at behandle dem.
  • Bemærk: Felterne "kopi", "option klasse" og "option nummer" omtales nogle gange som et enkelt otte-bit "option type" felt.
Kopi klasse nummer værdi Navn reference
0 0 0 0 EOOL - Slut på valgliste RFC791 [18]
0 0 en en NOP—Ingen betjening RFC791 [18]
en 0 2 130 SEC - Sikkerhed [RFC1108]
en 0 3 131 LSR - Løskilderute RFC791 [18]
0 2 fire 68 TS-tidsstempel RFC791 [18]
en 0 5 133 E-SEC - Udvidet sikkerhed [RFC1108]
en 0 6 134 CIPSO-kommerciel sikkerhed [draft-ietf-cipso-ipsecurity-01]
0 0 7 7 RR—Optag rute RFC791 [18]
en 0 otte 136 SID - Stream ID RFC791 [18] [RFC6814][1]
en 0 9 137 SSR - Strict Source Route RFC791 [18]
0 0 ti ti ZSU—Eksperimentel måling [ZSu]
0 0 elleve elleve MTUP - MTU Probe [RFC1063][RFC1191][1]
0 0 12 12 MTUR-MTU svar [RFC1063][RFC1191][1]
en 2 13 205 FINN - Eksperimentel Flow Control [Greg_Finn]
en 0 fjorten 142 VISA - Eksperimentel adgangskontrol [Deborah_Estrin][RFC6814][1]
0 0 femten femten KODER - ??? [VerSteeg][RFC6814][1]
en 0 16 144 IMITD - IMI Traffic Descriptor [Lee]
en 0 17 145 EIP - Extended Internet Protocol [RFC1385][RFC6814][1]
0 2 atten 82 TR - Traceroute [RFC1393][RFC6814][1]
en 0 19 147 ADDEXT-adresseudvidelse [Ullmann IPv7][RFC6814][1]
en 0 tyve 148 RTRALT-Router Alert [RFC2113]
en 0 21 149 SDB - Selektiv rettet udsendelse [Charles_Bud_Graff][RFC6814][1]
en 0 22 150 В В В В В В В В — Ikke tildelt (udgivet 18. oktober 2005)
en 0 23 151 DPS - Dynamic Packet State [Andy_Malis][RFC6814][1]
en 0 24 152 UMP - Upstream Multicast Pkt. [Dino_Farinacci][RFC6814][1]
0 0 25 25 QS-Hurtig start [RFC4782]
0 0 tredive tredive EXP - RFC3692-eksperiment [2] [RFC4727]
0 2 tredive 94 EXP - RFC3692-eksperiment [2] [RFC4727]
en 0 tredive 158 EXP - RFC3692-eksperiment [2] [RFC4727]
en 2 tredive 222 EXP - RFC3692-eksperiment [2] [RFC4727]

Udmattelse af adresseplads

Allerede i 1980'erne blev det tydeligt, at distributionen af ​​adresserum foregik med en meget hurtigere hastighed, end der var indbygget i IPv4-arkitekturen. Dette førte først til klasseløs adressering , senere til klasseløs adressering og til sidst til udviklingen af ​​den nye IPv6 -protokol .

I februar 2011 tildelte IANA de sidste 5 adresseblokke til RIR'er . Blokke af gratis IP-adresser begyndte at løbe tør hos regionale registratorer siden 2011 [19] .

Den 25. november 2019 blev de sidste gratis IPv4-adresser distribueret i Europa, landene i det tidligere USSR og Mellemøsten [20] . Nu vil det kun være muligt at få en IPv4-adresse, hvis den nuværende ejer frigiver den - for eksempel lukker en virksomhed eller et netværk frigiver en adresseressource, som den ikke har brug for.

Se også

Noter

  1. ↑ 1 2 3 RFC3330: IPv4-adresser til særlig brug Arkiveret 14. december 2011 på Wayback Machine  ; afløst af RFC5735 : IPv4-adresser til særlig brug Arkiveret 15. maj 2013 på Wayback Machine 
  2. ↑ 1 2 3 RFC1700: Tildelte numre arkiveret 1. januar 2012 på Wayback Machine 
  3. ↑ RFC1122: Krav til internetværter - kommunikationslag [afsnit-3.2.1.3] Arkiveret 15. september 2008 på Wayback Machine 
  4. ↑ 1 2 3 RFC1918: Adressetildeling for private internets Arkiveret 2. december 2011 på Wayback Machine 
  5. ↑ 1 2 3 Et kig ind i Nordkoreas intranet . Hentet 20. oktober 2021. Arkiveret fra originalen 20. oktober 2021.
  6. ↑ RFC3927: Dynamisk konfiguration af IPv4 link-lokale adresser Arkiveret 19. januar 2012 på Wayback Machine 
  7. ↑ RFC 6890: IANA IPv4 Special Purpose Address Registry Arkiveret 17. oktober 2012 på Wayback Machine 
  8. ↑ 1 2 3 RFC5737: IPv4-adresseblokke reserveret til dokumentation Arkiveret 9. november 2011 på Wayback Machine 
  9. ↑ RFC3068: Et anycast-præfiks til 6to4-relæroutere Arkiveret 21. januar 2012 på Wayback Machine 
  10. ↑ RFC2544: Benchmarking-metodologi for netværksforbindelsesenheder Arkiveret 9. november 2011 på Wayback Machine 
  11. ↑ RFC3171: IANA-retningslinjer for IPv4 multicast-adressetildelinger Arkiveret 15. maj 2012 på Wayback Machine 
  12. ↑ RFC919: Udsendelse af internetdatagrammer Arkiveret 26. november 2011 på Wayback Machine 
  13. ↑ Stefan Savage. Praktisk netværksunderstøttelse for IP-sporing . Hentet: 6. september 2010.
  14. ↑ Som en aprilsnar er det foreslået at betyde pakkens ondsindede hensigt (ond smule)
  15. ↑ Tildelte internetprotokolnumre arkiveret 13. juni 2018 på Wayback Machine 
  16. ↑ Beregning af internettjeksum Arkiveret 9. juni 2011 på Wayback Machine 
  17. ↑ IP-MULIGHEDSNUMRE . IANA. Hentet 17. juni 2018. Arkiveret fra originalen 25. oktober 2018.
  18. ↑ 1 2 3 4 5 6 7 RFC791: Internet Protocol Arkiveret 30. juli 2019 på Wayback Machine 
  19. ↑ IPv4-adresserapport . Hentet 16. februar 2011. Arkiveret fra originalen 1. april 2009.
  20. ↑ Udgivelsesdato: 25. november 2019 - nyheder, ipv4, Ipv4 Depletion, ipv6, pressemeddelelse. RIPE NCC er løbet tør for IPv4-adresser . RIPE Netværkskoordinationscenter. Hentet 27. november 2019. Arkiveret fra originalen 25. november 2019.