IPv4
Internet Protocol versjon 4 (på engelsk , Internet Protocol versjon 4 , IPv4 ) er den fjerde versjonen av Internet Protocol (IP), en protokoll for sammenkobling av nettverk basert på Internett , og det var den første versjonen implementert i 1983 for produksjon fra ARPANET . Definert i RFC 791 bruker IPv4 32 - biters adresser , begrenset til = 4.294.967.296 unike adresser, mange av dem LAN . [ 1 ] På grunn av den enorme veksten som elektronisk sikkerhet og automatisering har hatt, kombinert med at det er adressesvinn i mange tilfeller (se avsnittene som følger), ble det for flere år siden observert at IPv4-adresser var knappe .
Denne begrensningen bidro til å stimulere studien om gjennomførbarheten av å implementere en ny IPv6 -protokoll , som i 2016 allerede var i de første testfasene, og som ville ende opp med å erstatte IPv4-protokollen.
Adressene som er tilgjengelige i den globale IANA -poolen som tilhører IPv4-protokollen ble offisielt oppbrukt mandag 31. januar 2011. [ 2 ] De regionale internettregistrene måtte fra det øyeblikket administrere sine egne bassenger, som ble beregnet til å nå opp til år 2020 og ikke så mye lenger.
Adressering
IPv4 bruker 32-biters adresser som begrenser adresseplassen til 4 294 967 296 (2 32 ) mulige adresser.
IPv4 (Internet Protocol versjon 4) reserverer spesielle adresseblokker for private nettverk (totalt 16 777 216 adresser eller 2 24 ), så vel som multicast -adresser (268 435 456 adresser eller 2 28 ). .
Adresserepresentasjoner
IPv4-adresser kan representeres i en hvilken som helst notasjon som uttrykker en 32-bits heltallsverdi. Mesteparten av tiden er de skrevet i desimalnotasjonen , som består av fire oktetter av adressen uttrykt individuelt i desimaltall, og atskilt fra hverandre med punktum.
For eksempel representerer den fire-prikkede IP-adressen 192.0.2.235 det 32-biters desimaltallet 3221226219, som i heksadesimal er 0xC00002EB. Dette kan også uttrykkes i heksadesimalt punktformat som 0xC0.0x00.0x02.0xEB, eller med verdier i oktalt format som 0300.0000.0002.0353.
CIDR - notasjon kombinerer adressen med ruteprefikset i et kompakt format, der adressen etterfølges av en skråstrek (/) og antallet av 1 påfølgende biter i rutingprefikset (nettverksmaske).
Oppgave
I den opprinnelige utformingen av IPv4 ble en IP-adresse delt i to deler: nettverksidentifikatoren var den viktigste oktetten av adressen, og vertsidentifikatoren (vert eller gjest) var resten av adressen. Sistnevnte ble også kalt rastefeltet. Denne strukturen tillot maksimalt 256 nettverksidentifikatorer, noe som raskt ble funnet å være utilstrekkelig.
For å overvinne denne grensen ble den viktigste adresseoktetten omdefinert i 1981 for å lage nettverksklasser, i et system som senere ble kjent som klassenettverk. Det reviderte systemet definerte fem klasser. Klassene A, B og C hadde forskjellige bitlengder for nettverksidentifikasjon. Resten av adressen ble brukt som ovenfor for å identifisere en vert i et nettverk. På grunn av de forskjellige størrelsene på feltene i forskjellige klasser, hadde hver nettverksklasse en annen evne til å adressere vertene sine. I tillegg til de tre klassene for adressering av verter, ble klasse D definert for multicast-adressering, og klasse E ble reservert for fremtidige applikasjoner.
Oppdelingen av eksisterende klassenettverk i undernett begynte i 1985 med utgivelsen av RFC 950. Denne inndelingen ble gjort mer fleksibel med introduksjonen av Variable Length Subnet Masks (VLSM) i RFC 1109 i 1987. I 1993, basert på i dette arbeidet, RFC 1517 introduserte Classless Inter-Domain Routing (CIDR), [ 3 ] som uttrykker antall (mest signifikante) biter som /24, og det klassebaserte opplegget ble kalt classy, i kontrast. CIDR ble designet for å tillate partisjonering av ethvert adresserom slik at mindre eller større blokker med adresser kunne tildeles forskjellige brukere. Den hierarkiske strukturen opprettet av CIDR ble administrert av Internet Assigned Numbers Authority (IANA) og de regionale Internett-registrene (RIR). Hver RIR opprettholder en offentlig søkbar WHOIS-database, som gir informasjon om IP-adressetilordninger.
Adresser for spesiell bruk
Internet Engineering Task Force (IETF) og Internet Assigned Numbers Authority (IANA) har begrenset den generelle bruken av forskjellige IP-adresser reservert for spesielle formål. Spesielt brukes disse adressene til multicast-trafikk og for å gi adresserom for ubegrenset bruk i private nettverk.
| adresseblokk | Område | antall adresser | omfang | Beskrivelse |
|---|---|---|---|---|
| 0.0.0.0/8 | 0.0.0.0–0.255.255.255 | 16.777.216 | Programvare | Nåværende nettverk [ 4 ] (kun gyldig som kildeadresse). |
| 10.0.0.0/8 | 10.0.0.0–10.255.255.255 | 16.777.216 | Privat nettverk | Brukes for lokal kommunikasjon innenfor et privat nettverk . [ 5 ] |
| 100.64.0.0/10 | 100.64.0.0–100.127.255.255 | 4.194.304 | Privat nettverk | Delt adresserom [ 6 ] for kommunikasjon mellom en tjenesteleverandør og dens abonnenter ved bruk av NAT av operatørgrad. |
| 127.0.0.0/8 | 127.0.0.0–127.255.255.255 | 16.777.216 | Vert | Den brukes for tilbakekoblingsadresser . [ 4 ] |
| 169.254.0.0/16 | 169.254.0.0–169.254.255.255 | 65.536 | Subnett | Den brukes for lokale lenkeadresser [ 7 ] l mellom to verter på en enkelt lenke når en IP-adresse ikke er spesifisert ellers, da den normalt ville blitt hentet fra en DHCP- server . |
| 172.16.0.0/12 | 172.16.0.0–172.31.255.255 | 1 048 576 | Privat nettverk | Brukes for lokal kommunikasjon innenfor et privat nettverk. [ 5 ] |
| 192.0.0.0/24 | 192.0.0.0–192.0.0.255 | 256 | Privat nettverk | IETF Protocol Assignments. [ 4 ] |
| 192.0.2.0/24 | 192.0.2.0–192.0.2.255 | 256 | Dokumentasjon | Tildelt som TEST-NET-1, for dokumentasjon og eksempler. [ 8 ] |
| 192.88.99.0/24 | 192.88.99.0–192.88.99.255 | 256 | Internett | Reservert. [ 9 ] Tidligere brukt for IPv6 til IPv4 relé . [ 10 ] (inkludert IPv6 -adresseblokk 2002::/16 ). |
| 192.168.0.0/16 | 192.168.0.0–192.168.255.255 | 65.536 | Privat nettverk | Brukes for lokal kommunikasjon innenfor et privat nettverk. [ 5 ] |
| 198.18.0.0/15 | 198.18.0.0–198.19.255.255 | 131.072 | Privat nettverk | Den brukes til benchmarking av kommunikasjon mellom to separate undernett. [ 11 ] |
| 198.51.100.0/24 | 198.51.100.0–198.51.100.255 | 256 | Dokumentasjon | Tildelt som TEST-NET-2, for dokumentasjon og eksempler. [ 8 ] |
| 203.0.113.0/24 | 203.0.113.0–203.0.113.255 | 256 | Dokumentasjon | Tildelt som TEST-NET-3, for dokumentasjon og eksempler. [ 8 ] |
| 224.0.0.0/4 | 224.0.0.0–239.255.255.255 | 268.435.456 | Internett | Brukes for IP Multicast . [ 12 ] (tidligere et klasse D-nettverk). (Eksperimentell) |
| 240.0.0.0/4 | 240.0.0.0–255.255.255.254 | 268.435.456 | Internett | Reservert for fremtidig bruk. [ 13 ] (tidligere et klasse E-nettverk). (Eksperimentell) |
| 255.255.255.255/32 | 255.255.255.255 | 1 | Subnett | Reservert for multicast-destinasjoner. [ 4 ] [ 14 ] |
Av de rundt fire milliarder adressene som er definert i IPv4, er rundt 18 millioner adresser i tre områder reservert for bruk i private nettverk. Pakkeadresser i disse områdene kan ikke rutes på det offentlige Internett; de ignoreres av alle offentlige rutere. Derfor kan private verter ikke kommunisere direkte med offentlige nettverk og krever nettverksadresseoversettelse ved en rutegateway for dette formålet.
| Navn | CIDR -blokk | adresseområde | antall adresser | Klasse |
|---|---|---|---|---|
| 24-bits blokk | 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | 16 777 216 | En klasse. |
| 20-bits blokk | 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | 1 048 576 | Sammenhengende utvalg av 16 klasse B blokker. |
| 16-bits blokk | 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | 65.536 | Sammenhengende utvalg av 256 klasse C-blokker. |
Siden to private nettverk, for eksempel to avdelingskontorer, ikke kan fungere direkte sammen over det offentlige Internett, må de to nettverkene koble seg over Internett gjennom et virtuelt privat nettverk eller en IP-tunnel, som innkapsler pakker, inkludert deres overskrifter som inneholder de private adressene, på en protokolllag under overføring over det offentlige nettverket. I tillegg kan innkapslede pakker krypteres for overføring over offentlige nettverk for å sikre data.
Link-lokale adresser
RFC 3927 definerer den spesielle adresseblokken 169.254.0.0/16 for lenkelokal adressering. Disse adressene er bare gyldige på lenker (som et lokalt nettverkssegment eller punkt-til-punkt-tilkobling) koblet til en vert. Disse adressene kan ikke rutes. I likhet med private adresser, kan ikke disse adressene være kilden eller destinasjonen til pakker som krysser Internett. Disse adressene brukes først og fremst for adresseautokonfigurasjon ( Zeroconf ) når en vert ikke er i stand til å få tak i en IP-adresse fra en DHCP-server eller andre interne konfigurasjonsmetoder.
Da adresseblokken ble reservert, var det ingen standarder for automatisk adressekonfigurasjon. Microsoft opprettet en implementering kalt Automatic Private IP Addressing (APIPA), som ble implementert på millioner av maskiner og ble en de facto-standard. Mange år senere, i mai 2005, definerte IETF en formell standard i RFC 3927, med tittelen Dynamic Configuration of IPv4 Link-Local Addresses.
Loopback
Klasse A-nettverket 127.0.0.0 (klasseløst nettverk 127.0.0.0/8) er reservert for loopback . IP-pakker hvis kildeadresser tilhører dette nettverket, må aldri vises utenfor en vert. Arbeidsmåten til dette nettverket utvider seg til et loopback -grensesnitt :
- IP-pakker hvis kilde- og destinasjonsadresser tilhører nettverket (eller subnettet) til det samme loopback -grensesnittet , returneres til det grensesnittet;
- IP-pakker hvis kilde- og destinasjonsadresser tilhører nettverk (eller subnett) av forskjellige grensesnitt på samme vert, hvorav en er et loopback -grensesnitt , videresendes regelmessig.
Adresser som slutter på 0 eller 255
Nettverk med nettverksmasker på minst 24 biter, det vil si klasse C-nettverk på klassenettverk, og nettverk med CIDR-suffikser /24 til /30 (255.255.255.0–255.255.255.252) kan ikke ha en adresse som slutter på 0 eller 255 .
Klassefull adressering foreskrev bare tre mulige subnettmasker: Klasse A, 255.0.0.0 eller /8; Klasse B, 255.255.0.0 eller /16; og klasse C, 255.255.255.0 eller /24. For eksempel, i delnettet 192.168.5.0/255.255.255.0 (192.168.5.0/24), brukes ofte identifikatoren 192.168.5.0 for å referere til hele delnettet. For å unngå tvetydighet i representasjonen er adressen som slutter på oktett 0 reservert.
En multicast-adresse er en adresse som lar informasjon sendes til alle grensesnitt på et gitt subnett, i stedet for til en bestemt maskin. Generelt blir kringkastingsadressen funnet ved å ta komplementet av biter av subnettmasken og bitvis ELLER nettverksidentifikatoren. Med andre ord er kringkastingsadressen den siste adressen i subnettadresseområdet. For eksempel er kringkastingsadressen for 192.168.5.0-nettverket 192.168.5.255. For nettverk med størrelse /24 eller større, ender kringkastingsadressen alltid på 255.
| binær form | desimalnotasjon | |
|---|---|---|
| nettverksplass | 11000000.10101000.00000101.00000000 | 192.168.5.0 |
| kringkastingsadresser | 11000000.10101000.00000101.11111111 | 192.168.5.255 |
| I fet skrift vises vertsdelen av IP-en; Den andre delen er nettverksprefikset. Verten er reversert (IKKE logisk), men nettverksprefikset forblir intakt. | ||
Dette betyr imidlertid ikke at alle adresser som slutter på 0 eller 255 ikke kan brukes som vertsadresse. For eksempel, på /16-undernettet 192.168.0.0/255.255.0.0, som tilsvarer adresseområdet 192.168.0.0–192.168.255.255, er kringkastingsadressen 192.168.255.255. Følgende adresser kan brukes for verter, selv om de slutter med 255: 192.168.1.255, 192.168.2.255, etc. Dessuten er 192.168.0.0 nettverksidentifikatoren og bør ikke tilordnes et grensesnitt. [ 15 ] Adressene 192.168.1.0, 192.168.2.0 osv. kan tildeles, til tross for at de slutter med 0.
Tidligere oppsto det en konflikt mellom nettverksadresser og kringkastingsadresser fordi noen programmer brukte ikke-standard kringkastingsadresser med nuller i stedet for enere. [ 16 ]
På nettverk mindre enn /24 slutter ikke kringkastingsadresser nødvendigvis med 255. For eksempel har et CIDR-undernett 203.0.113.16/28 en kringkastingsadresse på 203.0.113.31.
| binær form | desimalnotasjon | |
|---|---|---|
| nettverksplass | 11001011.00000000.01110001.00010000 | 203.0.113.16 |
| kringkastingsadresser | 11001011.00000000.01110001.00011111 | 203.0.113.31 |
| I fet skrift vises vertsdelen av IP-en; Den andre delen er nettverksprefikset. Verten er reversert (IKKE logisk), men nettverksprefikset forblir intakt. | ||
Adresseoppløsning
Verter på Internett er generelt kjent under navnene sine, for eksempel www.example.com, ikke først og fremst av IP-adressen, som brukes til ruting og identifisering av nettverksgrensesnitt. Bruk av domenenavn krever oversettelse, kalt oppløsning, til adresser og omvendt. Dette er analogt med å slå opp et telefonnummer i en telefonbok med mottakerens navn.
Oversettelsen mellom adresser og domenenavn gjøres av Domain Name System (DNS), et distribuert, hierarkisk navnesystem som tillater subdelegering av navneområder til andre DNS-servere.
Fragmentering og remontering
Internet Protocol (IP) lar nettverk kommunisere med hverandre. Designet rommer nettverk av forskjellige fysiske naturer; den er uavhengig av teknologien som brukes i laget rett under, Link Layer. Nettverk med forskjellig maskinvare varierer vanligvis ikke bare i overføringshastighet, men også i deres maksimale overføringsenhet (MTU). Når et nettverk ønsker å overføre datagrammer til et nettverk med lavere MTU, må det fragmentere datagrammene. I IPv4 utføres denne funksjonen på Internett-laget, og den utføres av IPv4-rutere, som bare krever dette laget som det høyeste implementert i deres design.
I kontrast tillater ikke IPv6, den nye generasjonen av Internett-protokollen, rutere å utføre slik fragmentering; vertene er de som bestemmer MTU før de sender datagrammer.
Fragmentering
Når en ruter mottar en pakke, undersøker den destinasjonsadressen og bestemmer utgangsgrensesnittet som skal brukes og MTUen for den. Hvis pakkestørrelsen er større enn MTU og No Fragmentation (DF)-biten er 0 i pakkeoverskriften, må ruteren fragmentere pakken.
Ruteren deler pakken i fragmenter. Den maksimale størrelsen på hvert fragment er MTU minus størrelsen på IP-headeren (mellom 20 og 60 byte). Ruteren legger hvert fragment inn i pakken sin. Disse skårene får følgende endringer:
- Feltet for den totale størrelsen er delstørrelsen.
- Flagget for flere fragmenter (MF) er lik 1 i alle pakker bortsett fra den siste.
- Fragmentforskyvningsfeltet er aktivert, basert på forskyvningen av fragmentet i den opprinnelige datainnlastingen. Det måles i enheter på 8-byte blokker.
- Overskriftssjekksum - feltet beregnes på nytt.
For eksempel, for en MTU på 1500 byte og en topptekststørrelse på 20 byte, vil fragmentforskyvningene være multipler av (1500-20)/8 = 185 . Disse multiplene er 0,370,555,740...
Det er mulig for en pakke å bli fragmentert på en ruter og pakker å bli fragmentert på en annen ruter. Anta for eksempel at et transportlag har en størrelse på 4500 byte, ingen alternativer og en IP-hodestørrelse på 20 byte. Dermed vil pakkestørrelsen være 4520 byte.
Forutsatt at pakken går på en kobling med en MTU på 2500 byte, vil den se omtrent slik ut:
| Fragment | Størrelse i byte | header-bytes | databytes | Flagg
"Flere fragmenter" |
Fragmentforskyvning
(8-byte blokker) |
|---|---|---|---|---|---|
| 1 | 2500 | tjue | 2480 | 1 | 0 |
| to | 2040 | tjue | 2020 | 0 | 310 |
Merk at biter bevarer datastørrelsen: 2480 + 2020 = 4500 byte.
Legg også merke til hvordan du finner ut datastørrelsesforskyvningene:
- 0
- 0 + 2480/8 = 310.
Forutsatt at disse fragmentene treffer en kobling med en MTU på 1500 byte. Hver del ville bli to biter:
| Fragment | Størrelse i byte | header-bytes | databytes | Flagg
"Flere fragmenter" |
Fragmentforskyvning
(8-byte blokker) |
|---|---|---|---|---|---|
| 1 | 1500 | tjue | 1480 | 1 | 0 |
| to | 1020 | tjue | 1000 | 1 | 185 |
| 3 | 1500 | tjue | 1480 | 1 | 310 |
| 4 | 560 | tjue | 540 | 0 | 495 |
Merk at biter bevarer datastørrelsen:
- 1480 + 1000 = 2480 byte
- 1480+540 = 2020 byte
Legg også merke til at "Flere fragmenter"-biten forblir på 1 for alle fragmenter som fulgte med den 1-en, og at når den når det siste fragmentet, vil den biten bli satt til 0. Selvfølgelig fortsetter ID-feltet med samme verdi hele veien. alle fragmenter refragmentert. På denne måten, selv om fragmentene er re-fragmentert, vet mottakeren at de alle startet i den samme pakken.
Se hvordan vi får forskyvningene til datastørrelsene:
- 0.
- 0 + 1480/8 = 185.
- 185 + 1000/8 = 310.
- 310 + 1480/8 = 495.
Vi kan bruke siste forskyvning og siste datastørrelse for å beregne totalstørrelsen: 495*8 + 540 = 4500
3960 + 540 = 4500.Montering på nytt
En mottaker vet at en pakke er et fragment hvis minst en av følgende betingelser er oppfylt:
- "Flere fragmenter"-flagget er satt (= 1). (Dette gjelder for alle fragmenter bortsett fra det siste.)
- Fragmentforskyvningen er ikke 0. (Dette gjelder for alle fragmenter unntatt det første).
Mottakeren identifiserer samsvarende fragmenter ved hjelp av lokale og utenlandske adresser, protokoll-ID og identifikasjonsfeltet. Mottakeren vil sette sammen fragmentdataene med samme ID ved å bruke både fragmentforskyvningen og "Flere fragmenter"-flagget. Når mottakeren mottar det siste fragmentet (som har "Flere fragmenter"-flagget satt til 0), kan den beregne lengden på datanyttelasten, multiplisere forskyvningen av det siste fragmentet med 8 og legge til datastørrelsen også. I eksemplet ovenfor er denne beregningen 495 x 8 + 540 = 4500 byte.
Når mottakeren har alle fragmentene, kan den sette dem tilbake i riktig rekkefølge ved å bruke forskyvningene for å gjøre det.
Det er da du kan skyve dataene dine på stabelen for videre behandling.
Adresserepresentasjon
IPv4-adresser kan skrives som et 32-bits heltall, selv om de vanligvis skrives med stiplede desimaler. Disse 3-sifrede desimaltallene kalles "oktetter" fordi de i binært sett krever 8 sifre (8 bits) for å bli representert. Følgende tabell viser ulike måter å representere IPv4-adresser på:
| Notasjon | Verdi | Konvertering fra stiplet desimal |
|---|---|---|
| punktdelt desimal | 192.0.2.235 | - |
| punktseparert heksadesimal | 0xC0.0x00.0x02.0xEB | Hver oktett konverteres individuelt til heksadesimal form |
| punktseparert oktal | 0301.1680.0002.0353 | Hver oktett konverteres fra individuelt til oktal |
| heksadesimal | 0xC00002EB | Oktettsammenkobling av punktseparert heksadesimal form |
| Desimal | 3221226219 | Det heksadesimale tallet uttrykt i desimal |
| oktal | 030000001353 | Det heksadesimale tallet uttrykt i oktalt |
Sløsing med adresser
Sløsing med IPv4-adresser skyldes flere faktorer.
En av de viktigste er at man i utgangspunktet ikke tok hensyn til den enorme veksten som Internett skulle ha; store adresseblokker (på 16,271 millioner adresser) ble tildelt land, og til og med selskaper.
En annen årsak til sløsing er at i de fleste nettverk, bortsett fra de minste, er det praktisk å dele nettverket inn i undernett . Innenfor hvert subnett er den første og siste adressen ikke brukbare; men ikke alle gjenværende adresser brukes alltid. For eksempel, hvis du vil ha plass til 80 verter i et subnett , trenger du et subnett på 128 adresser (du må runde av til neste potens i base 2), i dette eksempelet brukes ikke lenger de resterende 48 IP-adressene.
Referanser
- ↑ http://tools.ietf.org/html/rfc1918
- ↑ http://www.enterprisenetworkingplanet.com/news/article.php/3923391/IPv4+Officially+Depleted,+Eyes+on+IPv6.htm
- ↑ "Forstå IP-adressering: Alt du noen gang har ønsket å vite" . 3Com. Arkivert fra originalen 16. juni 2001.
- ↑ a b c d Spesialformål IP-adresseregistre , doi : 10.17487/RFC6890 , BCP 153. RFC 6890 . Oppdatert av RFC 8190 .
- ↑ abcd Adressetildeling for private internett , doi : 10.17487 /RFC1918 , BCP 5. RFC 1918 . Oppdatert av RFC 6761 .
- ↑ IANA-reservert IPv4-prefiks for delt adresseområde , doi : 10.17487/RFC6598 , BCP 153. RFC 6598 .
- ↑ Dynamisk konfigurasjon av IPv4-koblingslokale adresser , doi : 10.17487/RFC3927 , RFC 3927 .
- ↑ a b c IPv4-adresseblokker reservert for dokumentasjon , doi : 10.17487/RFC5737 , RFC 5737 .
- ↑ Avskriving av Anycast-prefikset for 6to4 relérutere , doi : 10.17487/RFC7526 , BCP 196. RFC 7526 .
- ↑ Et Anycast-prefiks for 6to4- relérutere , doi : 10.17487/RFC3068 , RFC 3068 . Foreldet av RFC 7526 .
- ↑ Benchmarking Methodology for Network Interconnect Devices , doi : 10.17487/RFC2544 , RFC 2544 . Oppdatert av: RFC 6201 og RFC 6815 .
- ↑ IANA retningslinjer for IPv4 Multicast Address Assignments , doi : 10.17487/RFC5771 , BCP 51. RFC 5771 .
- ↑ Tildelte numre: RFC 1700 er erstattet av en onlinedatabase , doi : 10.17487/RFC3232 , RFC 3232 . Utdatert RFC 1700 .
- ↑ Kringkasting av Internett-datagrammer , doi : 10.17487/RFC0919 , RFC 919 .
- ↑ Robert Braden (oktober 1989). "Krav til internettverter – kommunikasjonslag" . IETF . s. 31. RFC 1122 .
- ↑ Robert Braden (oktober 1989). "Krav til internettverter – kommunikasjonslag" . IETF . s. 66. RFC 1122 .