IPv4 - IPv4
Protokoll verem | |
Célja | internetmunka protokoll |
---|---|
Fejlesztő (k) | DARPA |
Bemutatott | 1981 |
OSI réteg | Hálózati réteg |
RFC (k) | RFC 791 |
Internet protokoll csomag |
---|
Alkalmazási réteg |
Szállítási réteg |
Internet réteg |
Linkréteg |
Az Internet Protocol 4 -es verziója ( IPv4 ) az Internet Protocol (IP) negyedik változata . Ez az egyik alapvető protokollja a szabványos internetes munkamódszereknek az interneten és más csomagkapcsolt hálózatokon. IPv4 volt az első változat telepített termelés SatNet 1982-ben és az ARPANET a 1983. január Még ma is használják az utat a legtöbb internetes forgalom ma, annak ellenére, hogy a folyamatban lévő telepítését utódjának protokoll, az IPv6 .
Az IPv4 32 bites címteret használ, amely 4 294 967 296 (2 32 ) egyedi címet biztosít, de a nagy blokkok speciális hálózati módszerek számára vannak fenntartva.
Történelem
Az IP -réteget eredetileg a TCP v3 -as verziójában választották el a tervezés javítása érdekében, és a 4. verzióban stabilizálták. Az IPv4 -et az IETF RFC 791 (1981. szeptember) publikációja írja le, amely felvált egy korábbi definíciót (RFC 760, 1980. január). 1982 márciusában az Egyesült Államok Védelmi Minisztériuma a katonai számítógépes hálózatok szabványának nyilvánította a TCP/IP szabványt.
Célja
Az Internet Protocol protokoll, amely meghatározza és lehetővé teszi internetworking az internet réteg az Internet Protocol Suite . Lényegében ez képezi az internetet. Logikus címzési rendszert használ, és útválasztást végez , azaz csomagok továbbítását a forráshosztról a következő útválasztóra, amely egy ugrással közelebb van a másik hálózat tervezett célállomásához.
Az IPv4 kapcsolat nélküli protokoll, és a legjobb erőfeszítéseket teljesítő szállítási modellel működik, mivel nem garantálja a kézbesítést, és nem biztosítja a megfelelő sorrendet vagy az ismétlődő kézbesítés elkerülését. Ezekkel a szempontokkal, beleértve az adatok integritását, egy felső rétegű szállítási protokoll foglalkozik, például a Transmission Control Protocol (TCP).
Címzés
IPv4 használ 32-bites címeket, amely korlátozza a címtartomány a 4 294 967 296 (2 32 ) címeket.
Az IPv4 speciális címblokkokat tart fenn magánhálózatok (~ 18 millió cím) és multicast címek (~ 270 millió cím) számára.
Címábrázolások
Az IPv4-címek bármely, 32 bites egész értéket kifejező jelölésben megjeleníthetők. A leggyakrabban írt dot-tízes számrendszerben , amely négy oktett a címet kifejezett egyenként tizedes számok és elválasztott időszakokban .
Például a négypontos 192.0.2.235 IP-cím a 32 bites 3221226219 decimális számot jelöli, amely hexadecimális formátumban 0xC00002EB. Ezt ki is fejezhetjük pontozott hexadecimális formátumban 0xC0.0x00.0x02.0xEB formátumban, vagy oktális bájtértékekkel, mint 0300.0000.0002.0353.
A CIDR jelölés kompakt formátumban egyesíti a címet az útválasztási előtagjával, amelyben a címet egy perjel karakter (/) követi, és az egymást követő első bitek száma az útválasztási előtagban (alhálózati maszk).
A klasszikus hálózatépítés során más címmegjelenítések is általános használatban voltak . Például a 127.0.0.1 hurokcímet általában 127.1-nek írják , tekintettel arra, hogy egy A osztályú hálózathoz tartozik, amely nyolc bitet tartalmaz a hálózati maszkhoz és 24 bitet a gazdagép számához. Ha négynél kevesebb szám van megadva a címben pontozott jelöléssel, akkor az utolsó értéket annyi bájt egész számként kell kezelni, amennyi a cím négy oktettes kitöltéséhez szükséges. Így a 127.65530 cím egyenértékű a 127.0.255.250 címmel .
Kiosztás
Az IPv4 eredeti kialakításában az IP -címet két részre osztották: a hálózati azonosító volt a cím legjelentősebb oktettje, a gazdaazonosító pedig a cím többi része. Ez utóbbit is nevezik a többi területen . Ez a struktúra legfeljebb 256 hálózati azonosítót engedélyezett, ami hamar kiderült, hogy nem megfelelő.
Ennek a határnak a leküzdése érdekében a legjelentősebb cím oktettet 1981-ben újradefiniálták, hogy hálózati osztályokat hozzanak létre , egy olyan rendszerben, amelyet később klasszikus hálózatépítésnek neveztek el . A felülvizsgált rendszer öt osztályt határozott meg. Az A, B és C osztályok eltérő bithosszúsággal rendelkeztek a hálózat azonosításához. A cím többi részét a korábban használt módon azonosították a hálózaton belüli gazdagépek azonosítására. A különböző osztályok különböző méretű mezői miatt minden hálózati osztály eltérő kapacitással rendelkezett a gazdagépek címzéséhez. A három címzési osztályon kívül a D osztályt határozták meg a multicast címzéshez, és az E osztályt a jövőbeli alkalmazások számára fenntartották.
A meglévő klasszikus hálózatok alhálózatokra való felosztása 1985 -ben kezdődött az RFC 950 megjelenésével . Ez a felosztás rugalmasabbá vált a változó hosszúságú alhálózati maszkok (VLSM) bevezetésével az RFC 1109- ben 1987-ben. 1993-ban, e munka alapján, az RFC 1517 bevezette az osztály nélküli tartományközi útválasztást (CIDR), amely kifejezte a bitek számát (a legjelentősebb ), mint például, / 24, és az osztály-alapú rendszert nevezték osztály alapú , ezzel szemben. A CIDR -t úgy tervezték, hogy lehetővé tegye minden címtér felosztását, hogy kisebb vagy nagyobb címblokkokat lehessen hozzárendelni a felhasználókhoz. A CIDR által létrehozott hierarchikus struktúrát az Internet Assigned Numbers Authority (IANA) és a regionális internetes nyilvántartások (RIR) kezeli . Minden RIR nyilvánosan kereshető WHOIS adatbázist tart fenn , amely információkat tartalmaz az IP -címek hozzárendeléséről.
Különleges felhasználású címek
Az Internet Engineering Task Force (IETF) és az IANA korlátozta az általános használatot a különféle fenntartott IP -címekre speciális célokra. Nevezetesen ezek a címek a multicast forgalomhoz használatosak, és címzési helyet biztosítanak a privát hálózatok korlátlan használatához.
Speciális címblokkok Cím blokk Címtartomány Címek száma Hatály Leírás 0.0.0.0/8 0.0.0.0–0.255.255.255 16 777 216 Szoftver Jelenlegi hálózat (csak forráscímként érvényes). 10.0.0.0/8 10.0.0.0–10.255.255.255 16 777 216 Privát hálózat Privát hálózaton belüli helyi kommunikációra szolgál . 100,64,0,0/10 100.64.0.0–100.127.255.255 4 194 304 Privát hálózat Megosztott címtér a szolgáltató és előfizetői közötti kommunikációhoz, ha szolgáltatói szintű NAT-ot használ . 127.0.0.0/8 127.0.0.0–127.255.255.255 16 777 216 Házigazda Használt visszacsatolási címeket a helyi gépre. 169.254.0.0/16 169.254.0.0–169.254.255.255 65 536 Alhálózat Használt link-local címek két gép között egyetlen kapcsolatot, amikor nincs IP-cím hiányában, így volna normális kivették DHCP szerver. 172.16.0.0/12 172.16.0.0–172.31.255.255 1 048 576 Privát hálózat Privát hálózaton belüli helyi kommunikációra szolgál. 192,0.0.0/24 192.0.0.0–192.0.0.255 256 Privát hálózat IETF protokoll hozzárendelések. 192,0.2.0/24 192,0.2.0–192.0.2.255 256 Dokumentáció TEST-NET-1, dokumentáció és példák. 192,88.99.0/24 192,88.99.0–192.88.99.255 256 Internet Fenntartott. Korábban használt IPv6 az IPv4- relé (tartozék IPv6 címtartomány 2002 :: / 16 ). 192.168.0.0/16 192.168.0.0–192.168.255.255 65 536 Privát hálózat Privát hálózaton belüli helyi kommunikációra szolgál. 198.18.0.0/15 198.18.0.0–198.19.255.255 131 072 Privát hálózat Két külön alhálózat közötti hálózatok közötti kommunikáció benchmark tesztelésére szolgál. 198.51.100.0/24 198.51.100.0–198.51.100.255 256 Dokumentáció TEST-NET-2, dokumentáció és példák. 203.0.113.0/24 203.0.113.0–203.0.113.255 256 Dokumentáció TEST-NET-3, dokumentáció és példák. 224.0.0.0/4 224.0.0.0–239.255.255.255 268 435 456 Internet IP multicast esetén használatos . (Korábbi D osztályú hálózat). 233.252.0.0/24 233.252.0.0-233.252.0.255 256 Dokumentáció MCAST-TEST-NET, dokumentáció és példák. 240.0.0.0/4 240.0.0.0–255.255.255.254 268 435 455 Internet Fenntartva a későbbi használatra. (Korábbi E osztályú hálózat). 255.255.255.255/32 255.255.255.255 1 Alhálózat A "korlátozott sugárzású " célcímre van fenntartva.
Privát hálózatok
Az IPv4 -ben meghatározott mintegy négymilliárd cím közül három tartományban körülbelül 18 millió cím van fenntartva magánhálózatokban való használatra . Az ezekben a tartományokban lévő csomagcímek nem irányíthatók a nyilvános interneten; minden nyilvános útválasztó figyelmen kívül hagyja őket. Ezért a magángépek nem tudnak közvetlenül kommunikálni a nyilvános hálózatokkal, de e célból megkövetelik a hálózati cím fordítását egy útválasztó átjárón.
Foglalt magán IPv4 hálózati tartományok Név CIDR blokk Címtartomány Címek száma Klassz leírás 24 bites blokk 10.0.0.0/8 10.0.0.0 - 10.255.255.255 16 777 216 Egyetlen A osztály. 20 bites blokk 172.16.0.0/12 172.16.0.0 - 172.31.255.255 1 048 576 16 B osztályú blokk szomszédos tartománya. 16 bites blokk 192.168.0.0/16 192.168.0.0 - 192.168.255.255 65 536 256 C osztályú blokk szomszédos tartománya.
Mivel két magánhálózatok, például két fiókirodák, nem lehet közvetlenül együttműködni a nyilvános Internet útján, a két hálózat át kell hidalni az interneten keresztül virtuális magánhálózat (VPN) vagy egy IP-alagút , amely magában foglalja a csomagokat, beleértve a fejlécet tartalmazó privát címek, protokollrétegben a nyilvános hálózaton keresztüli átvitel során. Ezenkívül a beágyazott csomagok titkosíthatók a nyilvános hálózatokon keresztüli továbbításhoz az adatok védelme érdekében.
Link-local címzés
Az RFC 3927 határozza meg a speciális 169.254.0.0/16 címblokkot a link-local címzéshez. Ezek a címek csak a hivatkozásra érvényesek (például helyi hálózati szegmens vagy pont-pont kapcsolat), amely közvetlenül kapcsolódik az őket használó gazdagéphez. Ezek a címek nem irányíthatók. A privát címekhez hasonlóan ezek a címek sem lehetnek az interneten áthaladó csomagok forrása vagy célállomása. Ezeket a címeket elsősorban a címek automatikus konfigurálásához ( Zeroconf ) használják, amikor a gazdagép nem tud IP -címet szerezni egy DHCP -kiszolgálótól vagy más belső konfigurációs módszerektől.
A címblokk lefoglalásakor nem léteztek szabványok a cím automatikus konfigurálására. A Microsoft létrehozta az APIPA ( Automatic Private IP Addressing ) nevű megvalósítást , amelyet több millió gépen telepítettek, és de facto szabvány lett . Sok évvel később, 2005 májusában az IETF hivatalos szabványt határozott meg az RFC 3927-ben, az IPv4 link-helyi címek dinamikus konfigurálása címmel .
Loopback
Az A osztályú 127.0.0.0 hálózat (127.0.0.0/8 osztály nélküli hálózat) a loopback számára van fenntartva . Azok az IP -csomagok, amelyek forráscímei ehhez a hálózathoz tartoznak, soha ne jelenjenek meg a gazdagépen kívül. Azokat a csomagokat, amelyek visszacsatolási forráson vagy célcímen keresztül érkeznek, vissza kell utasítani.
Első és utolsó alhálózati címek
Az alhálózat első címe magát az alhálózatot azonosítja. Ezen a címen minden gazdabit 0 . A kétértelműség elkerülése érdekében ez a cím fenntartva. Az utolsó címben az összes gazdabit 1 -re van állítva . Helyi sugárzási címként használható üzenetek küldésére az alhálózat összes eszközére egyidejűleg. A 24 -es vagy nagyobb méretű hálózatoknál a sugárzási cím mindig 255 -tel végződik.
Például a 192.168.5.0/24 alhálózatban (255.255.255.0 alhálózati maszk) a 192.168.5.0 azonosító a teljes alhálózatra vonatkozik. A hálózat sugárzási címe 192.168.5.255.
Bináris forma | Pont-tizedes jelölés | |
---|---|---|
Hálózati tér |
11000000.10101000.00000101.00000000
|
192.168.5.0 |
Műsorszórási cím |
11000000.10101000.00000101.11111111
|
192.168.5.255 |
Pirossal jelzi az IP -cím gazda részét; a másik része a hálózati előtag. A gazda megfordul (logikai NEM), de a hálózati előtag érintetlen marad. |
Ez azonban nem jelenti azt, hogy minden 0 -ra vagy 255 -re végződő cím nem használható gazdaként. Például a 192.168.0.0/255.255.0.0 /16 alhálózatban, amely egyenértékű a 192.168.0.0–192.168.255.255 címtartománnyal, a sugárzási cím 192.168.255.255. A következő címek használhatók a gazdagépek számára, annak ellenére, hogy 255 -re végződnek: 192.168.1.255, 192.168.2.255, stb. Továbbá a 192.168.0.0 a hálózati azonosító, és nem rendelhető hozzá interfészhez. A 192.168.1.0, 192.168.2.0 stb. Címek hozzárendelhetők, annak ellenére, hogy 0 -val végződnek.
A múltban konfliktusok merültek fel a hálózati címek és a műsorszórási címek között, mert egyes szoftverek nem szabványos sugárzási címeket használtak nullák helyett.
A /24 -nél kisebb hálózatokban a műsorszórási címek nem feltétlenül végződnek 255 -tel. Például a 203.0.113.16/28 CIDR alhálózat 203.0.113.31 sugárzási címmel rendelkezik.
Bináris forma | Pont-tizedes jelölés | |
---|---|---|
Hálózati tér |
11001011.00000000.01110001.00010000
|
203.0.113.16 |
Műsorszórási cím |
11001011.00000000.01110001.00011111
|
203.0.113.31 |
Pirossal jelzi az IP -cím gazda részét; a másik része a hálózati előtag. A gazda megfordul (logikai NEM), de a hálózati előtag érintetlen marad. |
Különleges esetként az a /31 hálózat csak két gazda számára képes. Ezeket a hálózatokat általában pont-pont kapcsolatokhoz használják. Ezekhez a hálózatokhoz nincs hálózati azonosító vagy sugárzási cím.
Címfelbontás
Az internetes házigazdákat általában neveken ismerik, pl. Www.example.com, nem elsősorban IP -címük alapján, amelyet útválasztásra és hálózati interfész azonosítására használnak. A tartománynevek használata megköveteli azok lefordítását, az úgynevezett feloldást címekre és fordítva. Ez analóg azzal, hogy a címzett nevét felhasználva megkeres egy telefonszámot a telefonkönyvben.
A címek és tartománynevek közötti fordítást a Domain Name System (DNS) végzi , amely egy hierarchikus, elosztott elnevezési rendszer, amely lehetővé teszi a névterek átruházását más DNS -kiszolgálókra.
Cím a tér kimerülése
A nyolcvanas évek óta nyilvánvaló volt, hogy a rendelkezésre álló IPv4 -címek olyan mértékben fogynak, amilyenre a hálózat eredeti kialakításában nem számítottunk. A címkimerülést felgyorsító fő piaci erők közé tartozott a rohamosan növekvő számú internet -felhasználó, akik egyre inkább mobil számítástechnikai eszközöket, például laptopokat , személyi digitális asszisztenseket (PDA) és IP -adatszolgáltatással rendelkező okostelefonokat használtak . Ezenkívül a nagy sebességű internet-hozzáférés mindig bekapcsolt eszközökön alapult. A kimerültség fenyegetése számos javítótechnológia bevezetését motiválta, például az 1990-es évek közepére bevezetett osztálymentes tartományközi útválasztási (CIDR) módszereket, a hálózati címfordítás (NAT) kiterjedt használatát a hálózati hozzáférési szolgáltató rendszerekben és a szigorú használatot. alapú kiosztási politikák a regionális és helyi internetes nyilvántartásokban.
Az Internet elsődleges címkészlete, amelyet az IANA fenntartott, 2011. február 3 -án kimerült, amikor az utolsó öt blokkot az öt RIR -hez rendelték hozzá . Az APNIC volt az első RIR, amely 2011. április 15 -én kimerítette regionális készletét, kivéve az IPv6 -ra való áttérési technológiák számára fenntartott kis mennyiségű címteret, amelyet korlátozott házirend alapján kell kiosztani.
A hosszú távú megoldás a kimerültség kezelésére az Internet Protocol új verziójának, az IPv6- nak az 1998-as specifikációja volt . Jelentősen megnövelt címtárat biztosít, de lehetővé teszi az útvonal összesítését az interneten keresztül, és nagy alhálózat -kiosztást kínál legalább 2 64 gazdacímről a végfelhasználóknak. Az IPv4 azonban nem képes közvetlenül együttműködni az IPv6-tal, így a csak IPv4-alapú állomások nem tudnak közvetlenül kommunikálni a csak IPv6-alapú gazdagépekkel. A 6bone kísérleti hálózat 2004-ben kezdődő kivezetésével 2006-ban megkezdődött az IPv6 végleges, hivatalos bevezetése. Az IPv6 telepítésének befejezése várhatóan jelentős időt vesz igénybe, így a köztes átmeneti technológiák szükségesek ahhoz, hogy a házigazdák részt vehessenek az interneten a protokoll mindkét verziója.
Csomagszerkezet
Az IP csomag fejlécrészből és adatrészből áll. Az IP csomagnak nincs adatellenőrző összege vagy más lábléce az adatrész után. Jellemzően a kapcsolati réteg magában IP csomagokat keretek CRC Lábjegyzet amely érzékeli a legtöbb hiba, sok transzport réteg protokollok által hordozott IP is saját hibajavítás.
Fejléc
Az IPv4 csomagfejléc 14 mezőből áll, amelyek közül 13 kötelező. A 14. mező opcionális és találóan elnevezett: options. A fejléc mezőiben a legjelentősebb bájt van ( nagy endián ), és a diagram és a megbeszélés során a legjelentősebb biteket tekintjük elsőnek ( MSB 0 bites számozás ). A legjelentősebb bit 0 -val van számozva, így a verziómező például az első bájt négy legjelentősebb bitjében található.
Eltolások | Oktett | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Oktett | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
0 | 0 | Változat | IHL | DSCP | ECN | Teljes hossz | |||||||||||||||||||||||||||
4 | 32 | Azonosítás | Zászlók | Töredékeltolás | |||||||||||||||||||||||||||||
8 | 64 | Itt az ideje élni | Jegyzőkönyv | Fejléc ellenőrzőösszege | |||||||||||||||||||||||||||||
12 | 96 | Forrás IP -cím | |||||||||||||||||||||||||||||||
16 | 128 | Cél IP -cím | |||||||||||||||||||||||||||||||
20 | 160 | Opciók (ha IHL> 5) | |||||||||||||||||||||||||||||||
⋮ | ⋮ | ||||||||||||||||||||||||||||||||
60 | 480 |
- Változat
- Az IP- csomag első fejlécmezője a négybites verziómező. IPv4 esetén ez mindig 4 -gyel egyenlő.
- Internet fejléc hossza (IHL)
- Az IPv4 fejléc változó méretű az opcionális 14. mező (opciók) miatt. Az IHL mező tartalmazza az IPv4 fejléc méretét, 4 bitből áll, amelyek meghatározzák a fejlécben lévő 32 bites szavak számát. Ennek a mezőnek a minimális értéke 5, ami 5 × 32 bit = 160 bit = 20 bájt hosszúságot jelez. 4 bites mezőként a maximális érték 15, ez azt jelenti, hogy az IPv4 fejléc maximális mérete 15 × 32 bit = 480 bit = 60 bájt.
- Differenciált szolgáltatások kódpontja (DSCP )
- Eredetileg a szolgáltatás típusaként (ToS) határozták meg, ez a mező az RFC 2474 szerinti differenciált szolgáltatásokat (DiffServ) határozza meg. A valós idejű adatfolyam a DSCP mezőt használja. Példa erre a Voice over IP (VoIP), amelyet interaktív hangszolgáltatásokhoz használnak.
- Értesítés a torlódásokról (ECN )
- Ez a mező az RFC 3168-ban van definiálva, és lehetővé teszi a végpontok közötti értesítést a hálózati torlódásokról csomagok ejtése nélkül . Az ECN opcionális szolgáltatás, amely akkor érhető el, ha mindkét végpont támogatja, és akkor hatékony, ha az alaphálózat is támogatja.
- Teljes hossz
- Ez a 16 bites mező határozza meg a teljes csomagméretet bájtban, beleértve a fejlécet és az adatokat. A minimális méret 20 bájt (fejléc adatok nélkül), a maximális pedig 65 535 bájt. Minden gazdagépnek képesnek kell lennie 576 bájtos adatgramok újratelepítésére, de a legtöbb modern gazdagép sokkal nagyobb csomagokat kezel. A hivatkozások további korlátozásokat írhatnak elő a csomag méretére vonatkozóan, ebben az esetben a datagramokat töredezettségbe kell hozni . Az IPv4 töredezettségét vagy a küldő gazda, vagy az útválasztók végzik. Az összeszerelést a fogadó állomáson végzik.
- Azonosítás
- Ez a mező azonosító mező, és elsősorban egyetlen IP -datagram töredékeinek csoportjának egyedi azonosítására szolgál. Néhány kísérleti munka azt javasolta, hogy az azonosító mezőt használják más célokra, például csomagkövetési információk hozzáadásához, hogy segítsenek nyomon követni a datagramokat hamis forráscímekkel, de az RFC 6864 mostantól tiltja az ilyen felhasználást.
- Zászlók
- Három bites mező következik, és a töredékek vezérlésére vagy azonosítására szolgál. Ezek (sorrendben, a legjelentősebbtől a legkevésbé jelentősig):
- bit 0: Fenntartva; nullának kell lennie.
- bit 1: Ne töredezzen (DF)
- 2. bit: További töredékek (MF)
- Ha a DF jelző be van állítva, és töredezettség szükséges a csomag útvonalához, akkor a csomag elmarad. Ez akkor használható, ha csomagokat küld egy gazdagépnek, amely nem rendelkezik erőforrásokkal a töredékek újratelepítéséhez. Használható MTU útvonal felfedezéséhez is , akár automatikusan a gazda IP szoftver, akár manuálisan, diagnosztikai eszközök, például ping vagy traceroute segítségével .
- A töredezetlen csomagok esetén az MF jelző törlődik. A töredezett csomagok esetében az utolsó kivételével minden töredék rendelkezik MF jelzővel. Az utolsó töredék nem nulla töredékeltolási mezővel rendelkezik, ami megkülönbözteti a töredezetlen csomagtól.
- Töredékeltolás
- Ez a mező egy adott töredék eltolását határozza meg az eredeti töredezetlen IP-datagram kezdetéhez képest nyolcbájtos blokkokban. Az első töredék eltolása nulla. A 13 bites mező maximum (2 13 - 1) × 8 = 65 528 bájt eltolást tesz lehetővé , amely a fejléc hosszával együtt (65 528 + 20 = 65 548 bájt) támogatja a maximális 65 535 bájtos IP -t meghaladó csomagok töredezettségét.
- Ideje élni (TTL)
- Az élő mező nyolc bites ideje korlátozza a datagram élettartamát, hogy megakadályozza a hálózati meghibásodást útválasztási ciklus esetén . Ez másodpercben van megadva, de az 1 másodpercnél rövidebb időintervallumokat felfelé kerekítik. A gyakorlatban a mező ugrásszámként szolgál - amikor a datagram megérkezik egy útválasztóhoz , az útválasztó eggyel csökkenti a TTL mezőt. Amikor a TTL mező eléri a nullát, az útválasztó eldobja a csomagot, és általában ICMP idő túllépése üzenetet küld a feladónak.
- A program traceroute módosított TTL értékű üzeneteket küld, és ezeket az ICMP idő túllépett üzeneteit használja a csomagok által a forrásból a célállomásra áthaladó útválasztók azonosítására.
- Jegyzőkönyv
- Ez a mező határozza meg az IP datagram adatrészében használt protokollt. Az IANA az RFC 790 utasításainak megfelelően listát vezet az IP protokoll számokról .
- Fejléc ellenőrző összege
- A 16 bites IPv4 fejléc ellenőrző összeg mező a fejléc hibajavítására szolgál. Amikor egy csomag megérkezik egy útválasztóhoz, az útválasztó kiszámítja a fejléc ellenőrző összegét, és összehasonlítja azt az ellenőrző összeg mezővel. Ha az értékek nem egyeznek, a router eldobja a csomagot. Az adatmező hibáit a beágyazott protokollnak kell kezelnie. Mind az UDP, mind a TCP külön ellenőrző összegekkel rendelkezik, amelyek az adataikra vonatkoznak.
- Amikor egy csomag megérkezik egy útválasztóhoz, az útválasztó csökkenti a fejléc TTL mezőjét. Következésképpen az útválasztónak új fejléc -ellenőrző összeget kell kiszámítania.
- Forráscím
- Ez a mező a csomag feladójának IPv4 -címe. Vegye figyelembe, hogy ezt a címet a hálózati címfordító eszköz átvitel közben megváltoztathatja .
- Célcím
- Ez a mező a csomag vevőjének IPv4 -címe. A forráscímhez hasonlóan ezt is megváltoztathatja az átvitel során egy hálózati címfordító eszköz.
- Lehetőségek
- A beállítások mezőt nem gyakran használják. Az egyes opciókat tartalmazó csomagokat egyes útválasztók veszélyesnek tekinthetik, és blokkolhatják. Ne feledje, hogy az IHL mezőben szereplő értéknek elegendő 32 bites extra szót kell tartalmaznia ahhoz, hogy az összes opciót megtartsa, valamint minden kitöltést, amely szükséges ahhoz, hogy a fejléc egész számú 32 bites szót tartalmazzon. Ha az IHL nagyobb, mint 5 (azaz 6 és 15 között van), az azt jelenti, hogy az opciók mező jelen van, és ezt figyelembe kell venni. Az opciók listája az EOOL (opciós lista vége, 0x00) opcióval fejezhető be; erre csak akkor van szükség, ha az opciók vége különben nem esik egybe a fejléc végével. A fejlécben a következő lehetőségek adhatók meg:
Terület Méret (bit) Leírás Másolva 1 Állítsa 1 -re, ha a beállításokat egy töredezett csomag minden töredékébe kell másolni. Opciós osztály 2 Általános opciók kategória. A 0 a vezérlési opciókat, a 2 pedig a hibakeresést és a mérést jelenti . Az 1. és a 3. fenntartva. Opció száma 5 Megad egy opciót. Opció hossza 8 A teljes opció méretét jelzi (beleértve ezt a mezőt is). Ez a mező nem létezik az egyszerű lehetőségeknél. Opció adatok Változó Opcióspecifikus adatok. Ez a mező nem létezik az egyszerű lehetőségeknél.
- Az alábbi táblázat az IPv4 meghatározott beállításait mutatja. Az Opciótípus oszlop a Másolt, Opcióosztály és Opciószám bitekből származik, a fentiek szerint.
Opció típusa (tizedes / hexadecimális) Opció neve Leírás 0 / 0x00 EOOL Az opciós lista vége 1 / 0x01 NOP Nincs művelet 2 / 0x02 SEC Biztonság (megszűnt) 7 / 0x07 RR Útvonal rögzítése 10 / 0x0A ZSU Kísérleti mérés 11 / 0x0B MTUP MTU szonda 12 / 0x0C MTUR MTU válasz 15 / 0x0F KÓDOL KÓDOL 25 / 0x19 QS Gyors indítás 30 / 0x1E EXP RFC3692 stílusú kísérlet 68 / 0x44 TS Időbélyeg 82 / 0x52 TR Traceroute 94 / 0x5E EXP RFC3692 stílusú kísérlet 130 / 0x82 SEC Biztonság (RIPSO) 131 / 0x83 LSR Laza forrás útvonal 133 / 0x85 E-SEC Kiterjesztett biztonság (RIPSO) 134 / 0x86 CIPSO Kereskedelmi IP biztonsági opció 136 / 0x88 SID Adatfolyam azonosítója 137 / 0x89 SSR Szigorú forrásútvonal 142 / 0x8E VÍZUM Kísérleti hozzáférés -szabályozás 144 / 0x90 IMITD IMI Forgalomleíró 145 / 0x91 EIP Kiterjesztett Internet Protokoll 147 / 0x93 ADDEXT Címbővítés 148 / 0x94 RTRALT Router Alert 149 / 0x95 SDB Szelektív irányított sugárzás 151 / 0x97 DPS Dinamikus csomagállapot 152 / 0x98 UMP Felfelé irányuló multicast Pkt. 158 / 0x9E EXP RFC3692 stílusú kísérlet 205 / 0xCD FINN Kísérleti áramlásszabályozás 222 / 0xDE EXP RFC3692 stílusú kísérlet
Adat
A csomag hasznos terhelését nem tartalmazza az ellenőrző összeg. Tartalmait a Protokoll fejléc mező értéke alapján értelmezi.
Az IP protokoll számok listája tartalmazza a hasznos terhelés protokoll típusok teljes listáját. Néhány gyakori hasznos terhelési protokoll:
Protokoll száma | Protokoll neve | Rövidítés |
---|---|---|
1 | Internet Control Message Protocol | ICMP |
2 | Internet csoportkezelési protokoll | IGMP |
6 | Átviteli vezérlő protokoll | TCP |
17 | User Datagram Protocol | UDP |
41 | IPv6 tokozás | ENCAP |
89 | Először nyissa meg a legrövidebb útvonalat | OSPF |
132 | Stream Control Transmission Protocol | SCTP |
Töredezés és összeszerelés
Az Internet Protokoll lehetővé teszi a hálózatok közötti forgalmat. A kialakítás különböző fizikai jellegű hálózatokat foglal magában; független a kapcsolati rétegben használt átviteli technológiától. A különböző hardverekkel rendelkező hálózatok általában nemcsak az átviteli sebességben, hanem a maximális átviteli egységben (MTU) is eltérnek . Ha az egyik hálózat datagramokat szeretne továbbítani egy kisebb MTU -val rendelkező hálózatra, akkor töredezettsé teheti a datagramjait. Az IPv4 -ben ezt a funkciót az Internet Layer -ben helyezték el , és IPv4 -útválasztókban hajtják végre, így az IP -csomagok útválasztásához nincs szükség magasabb rétegek megvalósítására.
Ezzel szemben az IPv6 , az Internet Protocol következő generációja, nem teszi lehetővé az útválasztóknak a töredezettséget; a gazdagépeknek meg kell határozniuk az MTU útvonalat, mielőtt datagramokat küldenek.
Töredezettség
Amikor egy útválasztó csomagot fogad, megvizsgálja a célcímet, és meghatározza a használandó kimenő interfészt és az interfész MTU -ját. Ha a csomag mérete nagyobb, mint az MTU, és a csomag töredezettsége (DF) bit a csomag fejlécében 0 -ra van állítva, akkor az útválasztó feldarabolhatja a csomagot.
A router töredékekre osztja a csomagot. Az egyes töredékek maximális mérete az MTU mínusz az IP fejléc mérete (legalább 20 bájt, maximum 60 bájt). Az útválasztó minden töredéket a saját csomagjába helyez, és minden töredékcsomag a következő módosításokkal rendelkezik:
- A teljes hosszúságú mező a töredék mérete.
- A több töredék (MF) jelző minden töredékhez be van állítva, kivéve az utolsót, amely 0 -ra van állítva.
- A töredékeltolási mező be van állítva az eredeti adat hasznos terhelésben lévő töredék eltolása alapján. Ezt 8 bájtos blokkok egységében mérik.
- A fejléc ellenőrzőösszeg mezője újraszámításra kerül.
Például 1500 bájtos MTU és 20 bájtos fejléc esetén a töredékeltolások többszörösei lehetnek . Ezek a szorzók 0, 185, 370, 555, 740 stb
Lehetséges, hogy egy csomag töredezett az egyik útválasztónál, és a töredékek tovább töredezettek egy másik útválasztónál. Például egy 4520 bájtos csomag, beleértve az IP fejléc 20 bájtját (opciók nélkül), két csomagra van töredezve egy 2500 bájtos MTU linken:
Töredék | Méret (bájt) |
Fejléc mérete (bájt) |
Adatméret (bájt) |
Zászló További töredékek |
Töredékeltolás (8 bájtos blokkok) |
---|---|---|---|---|---|
1 | 2500 | 20 | 2480 | 1 | 0 |
2 | 2040 | 20 | 2020 | 0 | 310 |
A teljes adatméret megmarad: 2480 bájt + 2 020 bájt = 4500 bájt. Az eltolások és .
Egy 1500 bájtos MTU -val rendelkező linken minden töredék két töredéket eredményez:
Töredék | Méret (bájt) |
Fejléc mérete (bájt) |
Adatméret (bájt) |
Zászló További töredékek |
Töredékeltolás (8 bájtos blokkok) |
---|---|---|---|---|---|
1 | 1500 | 20 | 1480 | 1 | 0 |
2 | 1020 | 20 | 1000 | 1 | 185 |
3 | 1500 | 20 | 1480 | 1 | 310 |
4 | 560 | 20 | 540 | 0 | 495 |
Ismét megmarad az adatméret: 1 480 + 1 000 = 2 480 és 1 480 + 540 = 2 020.
Ebben az esetben is a Több töredék bit marad 1 az összes töredékhez , amelyek 1 -vel érkeztek, és az utolsó töredékhez, amelyik megérkezik, a szokásos módon működik, vagyis az MF bit 0 -ra van állítva csak az utolsóban. És természetesen az Azonosítás mezőnek továbbra is ugyanaz az értéke minden újra töredezett töredékben. Így, még akkor is, ha a töredékek újra töredezettek, a vevő tudja, hogy kezdetben mind ugyanabból a csomagból indultak ki.
Az utolsó eltolás és az utolsó adat mérete kiszámításához használt összes adat mérete: .
Összeszerelés
A vevő tudja, hogy a csomag töredék, ha az alábbi feltételek közül legalább az egyik teljesül:
- A "több töredék" jelző be van állítva, ami minden töredékre igaz, kivéve az utolsót.
- A "fragment offset" mező nem nulla, ami az első kivételével minden töredékre igaz.
A vevő azonosítja a megfelelő töredékeket az idegen és a helyi cím, a protokoll azonosítója és az azonosító mező segítségével. A vevő újra összeállítja az azonos azonosítójú töredékek adatait a töredékeltolódás és a több töredék jelző használatával. Amikor a vevő megkapja az utolsó töredéket, amelynek "több töredék" jelzője 0 -ra van állítva, kiszámíthatja az eredeti adat hasznos terhelésének méretét úgy, hogy megszorozza az utolsó töredék eltolását nyolccal, és hozzáadja az utolsó töredék adatméretét. A megadott példában ez a számítás 495*8 + 540 = 4500 bájt volt.
Ha a vevő minden töredékkel rendelkezik, akkor azokat az eltolásnak megfelelő sorrendben újra össze lehet állítani, hogy létrehozza az eredeti datagramot.
Segítő protokollok
Az IP -címek nincsenek állandó módon kötve a hardverazonosításokhoz, sőt, a hálózati interfésznek több IP -címe is lehet a modern operációs rendszerekben. A házigazdáknak és útválasztóknak további mechanizmusokra van szükségük az eszközinterfészek és az IP -címek közötti kapcsolat azonosításához annak érdekében, hogy egy IP -csomag megfelelően eljusson a célállomáshoz egy linken. A címfeloldási protokoll (ARP) elvégzi ezt az IP-cím-hardver-cím fordítást az IPv4 számára. (A hardvercímet MAC -címnek is nevezik .) Ezenkívül gyakran fordított korrelációra is szükség van. Például, amikor egy IP -gazdagép elindul vagy csatlakozik a hálózathoz, meg kell határoznia annak IP -címét, kivéve, ha a címet egy rendszergazda előre konfigurálta. Az ilyen fordított korrelációk protokolljai léteznek az Internet Protocol Suite -ben . A jelenleg használt módszerek a Dynamic Host Configuration Protocol (DHCP), a Bootstrap Protocol (BOOTP) és ritkán a fordított ARP .
Lásd még
Megjegyzések
Hivatkozások
Külső linkek
- Internet hozzárendelt számok hatóság (IANA)
- IP, Internet Protocol - IP fejléc lebontása, beleértve a speciális beállításokat
- RFC 3344 - IPv4 mobilitás
- IPv6 vs. szolgáltatói szintű NAT/többet kihozva az IPv4-ből
- RIPE jelentés a címfelhasználásról 2003. októberében
- Az IPv4 /8 kiosztások hivatalos jelenlegi állapota, az IANA fenntartása szerint
- Dinamikusan generált grafikonok az IPv4 -címfogyasztásról a kimerülési dátumok előrejelzéseivel - Geoff Huston
- Az IP -címzés Kínában és a címhiány mítosza
- A fennmaradó elérhető IPv4 címek visszaszámlálása (becsült)