Eljött az ideje, hogy bemutassuk az internetet részletesen. Mielőtt belemerülnénk a részletekbe, érdemes egy pillantást vetnünk azokra az elvekre, melyek annak idején az internet tervezőit vezették, és amelyeknek mai sikerét is köszönheti. Manapság amúgy is túl gyakran tűnik úgy, hogy az emberek megfeledkeztek ezekről. Az elveket az RFC 1958 sorolja fel és tárgyalja meg. Ez ugyancsak hasznos olvasmány (sőt a protokolltervezők számára kötelezővé kellene tenni, és még vizsgázniuk is kellene belőle). Az RFC erősen támaszkodik Clark [1988], valamint Saltzer és mások [1984] ötleteire. Most pedig összefoglaljuk, hogy mi mit tartunk a legfontosabb 10 vezérelvnek (a fontosabbaktól a kevésbé fontosabbak felé haladva).
A lényeg, hogy működjön. Ne véglegesítsd a tervet vagy a szabványt, amíg több prototípus nem kommunikált sikeresen egymással. Túlságosan is gyakran fordul elő, hogy a tervezők elkészítenek egy 1000 oldalas szabványt, elfogadtatják, aztán rájönnek, hogy alapjaiban rossz és nem is működik. Ezután megírják a szabvány 1.1-es verzióját. Ezt az utat nem szabad követni.
Maradj az egyszerűnél. Ha kétségek gyötörnek, használd a legegyszerűbb megoldást. William of Occam fogalmazta meg ezt az elvet (Occam borotvája) a 14. században. Hogy mai szóhasználattal éljünk: küzdj a funkciók ellen. Ha egy funkció nem feltétlenül szükséges, hagyd ki, különösen, ha ugyanaz a hatás elérhető más funkciók kombinációjával.
Válassz egyértelműen. Ha ugyanazt a dolgot többféleképpen is meg lehet oldani, válassz ki egy megoldást. Ha két vagy több módon is megvalósíthatjuk ugyanazt, az csak bajt okoz. A szabványokban gyakran csak azért vannak különböző lehetőségek, paraméterek vagy üzemmódok, mert számos, nagy befolyású kidolgozó fél ragaszkodik ahhoz, hogy a saját elgondolása a legjobb. A tervezőknek keményen ellen kell állniuk ennek a tendenciának. Egyszerűen nemet kell mondani.
Használd ki a modularitást. Ez az elv közvetlenül a protokollvermek alkalmazásának ötletéhez vezet, melyekben minden réteg független a többitől. Ily módon, ha a körülmények egy modul vagy réteg megváltoztatását követelik meg, a többit ez nem érinti.
Számíts heterogén környezetre. Minden nagy hálózatban előfordulnak különböző hardverek, átviteli berendezések és alkalmazások. Ahhoz, hogy ezeket mind kezelni tudd, a hálózat tervezése legyen egyszerű, általános és rugalmas.
Kerüld a statikus opciókat és paramétereket. Ha a paraméterek használata végképp elkerülhetetlen (például a maximális csomagméret), akkor jobb, ha az adó és a vevő megegyeznek egy értékben, mint ha rögzített opciókat határoznánk meg.
Amit tervezel, az legyen jó – nem kell tökéletesnek lennie. A tervezőknek gyakran van egy olyan tervük, ami jó ugyan, de nem képes valamilyen furcsa speciális esetet kezelni. Ahelyett, hogy erre összekuszálnák a tervet, tanácsosabb a jó terv mellett kitartaniuk, a mesterkedések terhét pedig azokra hagyni, akiknek különleges igényeik vannak.
Légy szigorú a küldésnél és elnéző a vételnél. Más szavakkal, csak olyan csomagokat küldj, amelyek szigorúan megfelelnek a szabványoknak, de számíts rá, hogy a bejövő csomagok nem lesznek teljesen szabványosak, és próbáld meg kezelni ezeket.
Gondolj a skálázhatóságra. Ha a rendszernek több millió hosztot és több milliárd felhasználót kell hatékonyan kezelnie, semmilyen központosított adatbázis nem jöhet szóba, a terhelést pedig olyan egyenletesen kell megosztani a rendelkezésekre álló erőforrások között, amennyire csak lehet.
Mérlegeld a teljesítőképességet és a költségeket. Ha egy hálózat gyatra teljesítőképességet nyújt, vagy irreális költségeket produkál, senki sem fogja majd használni.
Tegyük most félre az általános elveket, és kezdjük el az internet hálózati rétegének tanulmányozását. A hálózati réteg szintjén az internet hálózatok gyűjteményének vagy autonóm rendszerek (Autonomous Systems, AS) összekapcsolt együttesének tekinthető. Nincs igazi szerkezete, de létezik számos főbb gerinchálózata, amelyek nagy sávszélességű vonalakból és gyors útválasztókból állnak. Ezek közül a gerinchálózatok közül a legnagyobbat, amelyekhez mindenki más csatlakozik az internet többi részének eléréséhez, 1. rétegű hálózatoknak (Tier 1 networks) nevezzük. A gerinchálózatokhoz ISP-k csatlakoznak, amelyek internet-hozzáférést biztosítanak lakások, vállalatok, adatközpontok és kolokációs létesítmények számára, amelyek tele vannak szervergépekkel és regionális (középszintű) hálózatokkal. Az adatközpontok szolgáltatják az interneten keresztül küldött tartalom nagy részét. A regionális hálózatokhoz további ISP-k, illetve az egyetemeken, vállalatoknál és ISP-knél levő LAN-ok csatlakoznak. Az 5.45. ábrán ennek a kvázihierarchikus szerveződésnek egy vázlata látható.
Az a ragasztó, amely az internetet egybetartja, az IP (Internet Protocol – internetprotokoll). Sok régebbi hálózati rétegbeli protokolltól eltérően, ezt már a kezdetektől a hálózatok összekapcsolását szem előtt tartva tervezték. A hálózati rétegről jó elképzelés lehet a következő: az a feladata, hogy best-effort (vagyis nem garantált) szállítást biztosítson csomagoknak a forrásgéptől a célgépig történő eljuttatásához, függetlenül attól, hogy ezek a gépek ugyanazon a hálózaton vannak-e vagy sem, és vannak-e köztük más hálózatok vagy nincsenek.
Az interneten a kommunikáció a következőképpen működik. A szállítási réteg veszi az adatfolyamokat, és feltördeli úgy, hogy azok IP-csomagként elküldhetők legyenek. Elméletben a csomagok egyenként 64 KB hosszúak lehetnek, de a gyakorlatban rendszerint nem hosszabbak 1500 bájtnál (így beleférnek egy Ethernet-keretbe). Az IP-útválasztók minden csomagot továbbítanak az interneten keresztül, az útvonal mentén az egyik útválasztóról a következőre, a végső cél eléréséig. A célnál a hálózati réteg átadja az adatokat a szállítási rétegnek, amely azután átadja azt a vételi folyamatnak.azt a vételi folyamatnak.
Az 5.45. ábrán látható példában az otthoni hálózaton lévő hoszttól induló csomagnak négy hálózatot és számos IP-útválasztót kell megjárnia, hogy eljusson az vállalati hálózatra, amelyen a címzett hoszt található. Ez nem ritka a gyakorlatban, sőt számos ennél hosszabb útvonal is van. Az interneten redundáns kapcsolatok is vannak, gerinchálózatokkal és ISP-kel, amelyek sok helyen csatlakoznak egymáshoz. Ez azt jelenti, hogy két hoszt között számos lehetséges útvonal van. Az IP útválasztó protokoll feladata annak eldöntése, hogy melyek a használandó útvonalak.
Az internet hálózati rétegének tanulmányozásához jó kiindulási pont maguknak az IP-datagramoknak a formátuma. Egy IPv4-datagram egy fejrészből és egy törzsrészből vagy hasznos részből áll. A fejrésznek van egy 20 bájtos rögzített része és egy változó hosszúságú opcionális része. A fejrész formátuma az 5.46. ábrán látható. A bitek balról jobbra, fentről lefele kerülnek továbbításra, a Verzió mező legmagasabb helyi értékű bitje megy elsőnek. [Ez a „felsővég” (big endian) hálózati bájtsorrend. Az alsóvég gépeken (little endian), mint például az Intel x86 számítógépeken, adáskor és vételkor is szoftveres átalakítás szükséges.] Visszatekintve, az alsóvég jobb választás lett volna, de az IP tervezésekor senki nem tudta, hogy domináns számítástechnikai megoldás lesz belőle.
A Verzió mező azt tartja nyilván, hogy a datagram a protokoll melyik verziójához tartozik. Jelenleg a 4-es változat uralkodó az interneten, és ezzel kezdjük a leírást. Azáltal, hogy a verziót minden datagram elején megadják, a verziók közti átmenet évekig is eltarthat. Valójában az IP következő változata, az IPv6, több mint tíz évvel ezelőtt jelent meg, de a bevezetése még mindig csak az elején tart. Erre később térünk ki. Az IPv6 használatát akkor fogják kényszeríteni, ha Kína majd 231 lakosa rendelkezni fog asztali géppel, hordozható számítógéppel vagy IP-telefonnal. Ha már a számozásnál tartunk, megemlítjük, hogy az IPv5 egy kísérleti, valós idejű folyamtovábbító protokoll volt, amit soha nem használtak széles körben.
Mivel a fejrész hossza nem állandó, a fejrész egyik mezője, az IHL szolgál arra, hogy 32 bites szavakban megadja a fejrész hosszát. A legkisebb érték 5, ebben az esetben semmilyen opció nem szerepel. Ennek a 4 bites mezőnek a maximális értéke 15, amely a fejrészt 60 bájtra, ennélfogva az Opciók mezőt 40 bájtra korlátozza. Néhány opcióhoz, mint például ahhoz, amelyik a csomag által megtett utat jegyzi fel, a 40 bájt túl kicsi, ezáltal az opció értelmét veszti.
A Differenciált szolgáltatások mező az egyik azok közül a mezők közül, amelyek jelentése (kissé) megváltozott az évek során. Eredeti neve Szolgáltatás típusa volt. Akárcsak régen, ma is az a célja, hogy különbséget tegyen az eltérő szolgáltatási osztályok között. A megbízhatóságnak és a sebességnek számos kombinációja képzelhető el. A digitalizált hangnál a gyors kézbesítés fontosabb, mint a pontosság. A Szolgáltatás típusa mező 3 bitet biztosított a prioritás jelzéséhez, és 3 bitet annak jelzéséhez, hogy a hoszt megmondja, mi számára a legfontosabb: a késleltetés, az átbocsátóképesség vagy a megbízhatóság. Azt azonban igazából senki nem tudta, hogy mit lehet kezdeni ezekkel a bitekkel az útválasztón, ezért ezeket évekig nem használták. A differenciált szolgáltatások kialakításakor az IETF aztán végül bedobta a törölközőt, és újra felhasználta a mezőt. Jelenleg 6 bitet használnak a csomag szolgáltatási osztályának jelzésére: a fejezet korábbi részében már leírtuk a gyorsított és biztosított szolgáltatásokat. Az alsó 2 bit explicit torlódásértesítési információt hordoz, például hogy a csomag tapasztalt-e torlódást. Az explicit torlódásértesítést a fejezet korábbi részében írtuk le, a torlódáskezelés részeként.
A Teljes hosszba (Total lenght) a datagram minden része beleértendő, a fejrész is és az adatrész is. A maximális hossz 65 535 bájt. Jelenleg ez a felső korlát még elegendő, de a jövőbeni gigabites hálózatoknál nagyobb datagramokra lehet majd szükség.
Az Azonosítás (Identification) mező a daraboláskor szükséges ahhoz, hogy a címzett hoszt eldönthesse, melyik datagramhoz tartozik az újonnan érkezett darab. Egy datagram minden darabja ugyanazt az Azonosítás értéket tartalmazza.
A következő egy kihasználatlan bit, amely meglepő, mivel a rendelkezésre álló hely az IP-fejrészben meglehetősen kevés. Áprilisi tréfaként Bellovin [2003] felvetette, hogy ezt a bitet használják a rosszindulatú forgalom detektálására. Ez nagyban leegyszerűsítené a biztonságot, mivel az „evil” bittel rendelkező csomagokról lehetne tudni, hogy azokat támadók küldték, és így eldobhatók. Sajnos azonban a hálózati biztonság nem ilyen egyszerű.
Majd két 1 bites mező következik, amely a darabolással kapcsolatos. A DF jelentése: Ne darabold (Don’t Fragment). Ez az útválasztóknak szóló parancs, hogy ne darabolják fel a csomagot. Eredetileg az volt a célja, hogy támogassa azokat a hosztokat, amelyek nem tudják újra összerakni a darabokat. Jelenleg ezt az útvonal MTU-jának felderítésére szolgáló folyamat részeként alkalmazzák. Az MTU a legnagyobb csomag, amely az útvonal mentén darabolás nélkül átküldhető. Ha a datagram DF bittel van megjelölve, akkor az adó tudja, hogy egy darabban fog megérkezni, ellenkező esetben az adó hibaüzenetet kap vissza.
Az MF jelentése: több darab (More Fragments). Ezt a bitet minden darabban be kell állítani, kivéve az utolsóban. Ez azért szükséges, hogy tudjuk, vajon egy datagram minden darabja megérkezett-e.
A Darabeltolás mező megmondja, hova tartozik a mostani darab a datagramban. Egy datagram minden darabjának – kivéve az utolsót – 8 bájt többszörösének kell lennie, mert ez az elemi darabméret. Mivel 13 bit áll rendelkezésre, ez legfeljebb 8192 darabot jelent datagramonként, amely 65 536 bájtos maximális datagramhosszt eredményez, eggyel nagyobbat, mint amit a Teljes hossz mező lehetővé tesz. Az Azonosítás, MF és Darabeltolás mező együtt valósítja meg a darabolást az 5.5.5. szakaszban leírt módon.
Az Élettartam mező egy számláló, amelyet a csomag élettartamának korlátozására használnak. Ez elvileg az időt mérné másodpercekben, ezáltal maximálisan 255 másodperc hosszú életet tenne lehetővé. Minden ugrásnál csökkenteni kell, és ha egy csomag hosszú ideig állt sorban egy útválasztóban, akkor elvileg többször is csökkenteni kellene. Gyakorlatilag csak az ugrásokat számolja. Amikor eléri a nullát, a csomagot el kell dobni, és egy figyelmeztető csomagot kell visszaküldeni a forráshoszthoz. Ez a tulajdonság megelőzi, hogy a datagramok a végtelenségig kóboroljanak, ami egyébként megtörténhetne, ha az útválasztó táblázatokba valamikor hiba csúszna.
Amikor a vételi oldalon a hálózati réteg összeállított egy teljes datagramot, tudnia kell, mit tegyen vele. A Protokoll mező mondja meg, melyik szállítási folyamatnak adja át. Lehetséges a TCP, de az UDP és pár másik protokoll is. A protokollok számozása az interneten egységes. A protokollok számozását és a többi számkiosztást az RFC 1700 tartalmazta, de ma már egy online adatbázisban találhatók a www.iana.org weboldalon.
Mivel a fejrész lényeges információt hordoz, mint például a címek, a védelem érdekében kiszámítja a saját ellenőrző összegét, a Fejrész-ellenőrző összeget (Header Checksum). Az algoritmus az, hogy egyes komplemens aritmetikával az érkezés sorrendjében összeadjuk a 16 bites félszavakat, és vesszük az eredmény egyes komplemensét. Az algoritmus alapján a Fejrész-ellenőrző összeget a csomag érkezésekor nullának várjuk. Az ilyen ellenőrző összeg a csomag hálózaton való átküldése során fellépő hibák észleléséhez hasznos. Ne feledjük el, hogy ezt minden ugrásnál újra kell számítani, mivel legalább egy mező (az Élettartam mező) mindig változik, de alkalmazhatók trükkök a számítás felgyorsítására.
A Forráscím és Célcím mutatja a forrás és a cél hálózati interfészének az IP-címét. Az internetcímeket a következő részben tárgyaljuk.
Az Opciók mező egy menekülési útvonal, amelyet arra terveztek, hogy a protokoll következő verzióinak lehetőségük legyen olyan információt belevenni a protokollba, amelyek az eredeti tervben nem szerepeltek, hogy kísérletezhessenek új ötletek kipróbálásával, és hogy ne kelljen olyan információ számára is fejrészbiteket lefoglalni, amelyekre csak ritkán van szükség. Az opciók változó hosszúságúak. Mindegyik az opciót azonosító egybájtos kóddal kezdődik. Néhány opciónál ezt egy egybájtos hosszmező követi, majd egy vagy több adatbájt. Az Opciók mezőt négy bájt többszörösére töltik ki. Eredetileg öt opció létezett, ahogy az az 5.47. ábrán látszik.
A Biztonság opció azt mondja meg, milyen titkos az információ. Elméletben egy katonai útválasztó használhatná ezt a mezőt arra, hogy ne irányítson bizonyos, a katonaság szempontjából „rosszfiúnak” minősülő országokon keresztül. A gyakorlatban minden útválasztó figyelmen kívül hagyja, így az egyetlen gyakorlati funkciója az, hogy a kémek könnyebben megtalálhassák a jó dolgokat.
A Szigorú forrás általi útválasztás opció IP-címek sorozataként megadja a teljes utat a forrástól a célig. A datagramnak pontosan ezt az utat kell követnie. Ez nagyon hasznos rendszermenedzserek számára, hogy vészcsomagokat küldjenek az útválasztó táblák meghibásodása esetén, vagy időzítési méréseket végezzenek.
A Laza forrás általi útválasztás opció megköveteli a csomagtól, hogy a megadott útválasztókon, a megadott sorrendben áthaladjon, de útközben áthaladhat más útválasztókon is. Rendesen ez az opció csak egy pár útválasztót bocsát rendelkezésre, hogy egy bizonyos utat kényszerítsen ki. Például, hogy egy Londonból Sydneybe tartó csomagot kelet helyett nyugat felé kényszerítsünk, ez az opció például megadhat New York-i, Los Angeles-i és honolului útválasztókat. Ez az opció nagyon hasznos, ha politikai vagy gazdasági megfontolásokból keresztül kell haladni bizonyos országokon, vagy el kell kerülni azokat.
Az Útvonal feljegyzése opció arra utasítja az útba ejtett útválasztókat, hogy az IP-címüket fűzzék hozzá az Opciók mezőhöz. Ez lehetővé teszi a rendszermenedzsereknek, hogy kinyomozzák a hibákat az útválasztó algoritmusokban. („Miért keresik fel a Houstonból Dallasba menő csomagok először mind Tokiót?”) Amikor az ARPANET először létrejött, egyik csomag sem érintett kilenc útválasztónál többet, így az opció 40 bájtja bőségesen elegendő volt. Ahogy fentebb említettük, most már túl kicsi.
Végül az Időbélyeg opció olyan, mint az Útvonal feljegyzése opció, kivéve, hogy minden útválasztó a 32 bites IP-címe mellé egy 32 bites időbélyeget is feljegyez. Ez az opció is főleg az útválasztó algoritmusok hibakereséséhez való.
Az IP-opciókat ma már nem részesítik előnyben. Számos útválasztó figyelmen kívül hagyja, vagy nem dolgozza fel azokat hatékonyan, félretolva őket, mint szokatlan esetet. Ezért ezeket csak részben támogatják és csak ritkán használják.
Az IPv4 meghatározó jellemzője a 32-bites cím. Az interneten minden hosztnak és útválasztónak van egy IP-címe, amely az IP-csomagok Forráscím és Célcím mezői hordozzák. Fontos megjegyezni, hogy az IP-cím valójában nem egy hoszthoz tartozik. Igazából egy hálózati interfészre utal, tehát ha egy hoszt két hálózathoz is csatlakozik, akkor két IP-címének is kell lennie. Mindazonáltal a gyakorlatban a legtöbb hoszt egy hálózathoz csatlakozik, így csak egy IP-címe van. Ezzel szemben az útválasztók több interfésszel rendelkeznek, ezért több IP-címük is van.
Az IP-címek, az Ethernet-címekkel ellentétben, hierarchikusak. Minden 32 bites cím változó hosszúságú hálózati részből (felső bitek) és hosztrészből áll (alsó bitek). A hálózati rész értéke az egy hálózaton – például Ethernet LAN-on – lévő összes hoszt esetén megegyezik. Ez azt jelenti, hogy a hálózat az IP-címtér folyamatos blokkjának felel meg. Ezt a blokkot előtagnak (prefix) hívjuk.
Az IP-címeket rendszerint pontokkal elválasztott decimális jelölésrendszerben (dotted decimal notation) írják. Ebben a formátumban minden 4 bájtot tízes számrendszerben írnak ki, 0-tól 255-ig, például a 80D00297 32 bites hexadecimális cím decimális formája a következő: 128.208.2.151. Az előtagok megadják a legkisebb IP-címet a blokkban, illetve a blokk méretét. A méretet a hálózati részben lévő bitek száma határozza meg. A bitek a hosztrészben változhatnak. Ez azt jelenti, hogy a méretnek kettő hatványnak kell lennie. Megegyezés szerint az előtag IP-címe egy perjellel van kiegészítve, és ezt követi a hálózati rész bitjeinek száma. Ha az előtag a példánkban 28 címet tartalmaz és 24 bit marad a hálózati részre, akkor a következőképpen fest: 128.208.0.0/24.
Mivel az előtag hossza nem következtethető ki magából az IP-címből, az útválasztó protokolloknak át kell adniuk az előtagokat az útválasztóknak. Bizonyos esetekben az előtagokat egyszerűen a hosszuk írja le, mint a „/16” esetében (amelyet „per 16”-nak mondanak). Az előtag hossza megfelel az 1-esek bináris maszkjának a hálózati részben. Az ilyen írásmódot alhálózati maszknak (subnet mask) hívják. Ha ezt ÉS kapcsolatba hozzuk az IP-címmel, megkapjuk a hálózati részt. A példánkban az alhálózati maszk a 255.255.252.0. Az 5.48. ábra egy előtagot és alhálózati maszkot mutat be.
A hierarchikus címeknek számos előnye és hátránya van. Az előtagok fő előnye az, hogy az útválasztók a csomagokat továbbítani tudják a cím hálózati része alapján, amíg minden hálózat egyedi címblokkal rendelkezik. A hosztrész az útválasztók számára érdektelen, mivel az egy hálózaton lévő összes hoszt csomagját ugyanabba az irányba kell küldeni. Csak akkor kell a megfelelő hoszthoz továbbítani a csomagokat, amikor azok elérik a célhálózatot. Ezáltal kisebbek lesznek az útválasztó táblák, mint egyébként lennének. Képzeljük el, hogy a hosztok száma az interneten eléri az egymilliárdot. Így nagyon nagy táblázatot kellene minden útválasztónak fenntartania. A hierarchia alkalmazásával azonban az útválasztóknak csak körülbelül 300 000 előtagot kell fenntartaniuk a táblázatban.
A hierarchia használatával lehetővé válik az internet útválasztásának skálázása, amelynek két hátránya is van. Az első, hogy a hoszt IP-címe a hálózaton belüli helyétől függ. Az Ethernet-cím bárhol a világon használható, de minden IP-cím adott hálózathoz tartozik, és az útválasztók csak az erre a címre küldött csomagokat tudják kézbesíteni a hálózatra. Ezért szükség van olyan kialakításra – mint például a mozgó IP –, amely támogatja azokat a hosztokat, amelyek mozognak a hálózatok között, de meg akarják tartani IP-címüket.
A második hátrány, hogy a hierarchia címpazarlás, hacsak nem kezelik körültekintően. Ha a címeket (túl) nagy blokkokban rendelik a hálózatokhoz, akkor számos kihasználatlan cím kerül lefoglalásra. Ez nem számítana, ha bőségesen állnának rendelkezésre címek. Már több mint 20 évvel ezelőtt rájöttek arra, hogy az internet nagymértékű növekedése gyorsan kimeríti a szabad címteret. Az IPv6 megoldást jelent erre, de ennek széles körű bevezetéséig nagy a nyomás, hogy az IP-címeket minél hatékonyabban használják ki.
A hálózatszámokat az ICANN (Internet Corporation for Assigned Names and Numbers – Internettársaság Kiosztott Nevek és Számok Kezelésére) nevű nonprofit intézmény kezeli a konfliktusok elkerülése végett. Az ICANN különböző regionális hatóságokra bízta a címtér egy részét, hogy azok osszák ki az IP-címeket az ISP-nek és más vállalatoknak. Ez az a folyamat, amellyel egy vállalat IP-cím blokkot foglalhat le.
Ez a folyamat azonban csak a történet eleje, mivel az IP-cím hozzárendelés folyamatos, ahogy a vállalat növekszik. Azt mondtuk, hogy az előtagalapú útválasztáshoz a hálózatban minden hosztnak ugyanazzal a hálózatszámmal kell rendelkeznie. Ez a tulajdonság a hálózatok növekedésével gondokat okozhat. Tekintsünk például egy egyetemet, ahol kezdetben /16 előtag állt rendelkezésre a Számítástudományi Tanszék Ethernet-hálózatán lévő gépek számára. Egy évvel később a Villamosmérnöki Tanszék is ki akart kerülni az internetre. A Bölcsészettudományi Tanszék is követi példájukat. Milyen IP-címet kell használnia ezeknek a tanszékeknek? A beszerezhető további blokkok kívül vannak az egyetem hálózatán, ezenkívül drágák is lehetnek, és alkalmasságuk is megkérdőjelezhető. Továbbá a /16 előtag több mint 60 000 hoszt számára elengedő címet már lefoglalt. A nagy növekedés lehetővé tétele lehet a cél, de amíg ez be nem következik, addig nagy pazarlás lefoglalni további IP-cím blokkokat az egyetem számára. Másfajta szervezés szükséges tehát.
A megoldás az, hogy tegyük lehetővé a címblokk szétvágását több részre, hogy egy hálózat a belső felhasználás szempontjából több részre legyen felosztva, miközben a külvilág számára továbbra is egyetlen hálózatnak látszik. Ez az alhálózatra osztás (subnetting), és a nagyobb hálózat feldarabolásából keletkezett hálózatokat (mint amilyenek például az Ethernet LAN-ok) alhálózatoknak (subnets) nevezik. Amint azt az 1. fejezetben említettük, ez a szóhasználat ütközik az „alhálózat” szó azon jelentésével, ahol az egy hálózatban levő útválasztók és kommunikációs vonalak összességét értjük alatta.
Az 5.49. ábra bemutatja, hogy az alhálózatok hogyan segíthetnek a példánkban felmerült probléma megoldásában. Az egyetlen /16-ot osztottuk részekre. Ennek a felosztásnak nem kell egyenletesnek lennie, de minden darabnak sorbarendezettnek kell lennie, hogy minden bit használható legyen az alacsonyabb hosztrészben. Ebben az esetben a blokk felét (/17) a Számítástudományi Tanszék (SZT) számára, egynegyedét a Villamosmérnöki Tanszék (VT) számára (/18), illetve egynyolcadát (/19) a Bölcsészettudományi Tanszék (BT) számára foglalták le. A maradék nyolcad kiosztatlan marad. Egy másik mód a címblokk felosztásának bemutatására, hogy megnézzük az eredményül kapott előtagokat, amelyeket binárisan jelölünk:
|
Számítástudományi Tanszék: |
10000000 |
11010000 |
1|xxxxxxx |
xxxxxxxx |
|
Villamosmérnöki Tanszék: |
10000000 |
11010000 |
00|xxxxxx |
xxxxxxxx |
|
Bölcsészettudományi Tanszék: |
10000000 |
11010000 |
011|xxxxx |
xxxxxxxx |
A függőleges vonal (|) az alhálózat száma és a hosztrész közötti határt ábrázolja.
Amikor egy csomag beérkezik, honnan fogja tudni a központi útválasztó, hogy melyik alhálózatnak kell átadnia? Itt jön képbe az előtag részletezése. Lehetne, mondjuk egy 65 536 bejegyzésből álló táblázat minden útválasztóban, ami az egyetem minden hosztjához megmondja, hogy melyik útválasztót kell használni. Ez azonban meghiúsítaná a hierarchiából származó fő méretezési előnyöket. Ehelyett az útválasztónak csak a hálózatok alhálózati maszkjait kell ismernie az egyetemen belül.
Amikor egy IP-csomag megérkezik, az útválasztó megkeresi a célcímét a csomagban, és ellenőrzi, hogy melyik alhálózathoz tartozik. Ehhez az útválasztó a célcímet és minden egyes alhálózati maszkot ÉS kapcsolatba hoz, és ellenőrzi, hogy az eredmény a megfelelő előtag-e. Tekintsük például a 128.208.2.151 IP-címre küldött csomagot. Ahhoz, hogy kiderítsük, hogy a Számítástudományi Tanszéknek küldték-e a csomagot, ÉS kapcsolatba hozzuk a 255.255.128.0 maszkkal az első 17 bit kinyerése érdekében (ami a 128.208.0.0), és megnézzük, hogy ez megfelel-e az előtagcímnek, ami a 128.208.128.0. Ezek nem egyeznek. Ha az első 18 bitet nézzük a Villamosmérnöki Tanszéknél, akkor a 128.208.0.0 címet kapjuk az alhálózati maszkkal való ÉS művelet elvégzése után. Ez megfelel az előtag címének, így a csomag továbbításra kerül a Villamosmérnöki Tanszék hálózatához tartozó interfészre.
Az alhálózati felosztások később szükség esetén módosíthatók az egyetemen lévő összes útválasztó alhálózati maszkjának frissítésével. A hálózaton kívülről az alhálózati felosztás nem látható, így új alhálózat kiosztásához nem kell felvenni a kapcsolatot az ICANN-nel, illetve nem kell külső adatbázisokat módosítani.
Annak ellenére, hogy IP-címblokkok kerülnek lefoglalásra, így a címek felhasználása hatékony, egy probléma továbbra is fennáll: az útválasztó tábla nagymértékű növekedése.
Egy hálózat szélén lévő intézmény (mint például az egyetem) útválasztójának útválasztó táblázatában minden alhálózathoz tartoznia kell egy bejegyzésnek, ami megmondja az útválasztónak, hogy melyik vonalat használja az adott alhálózat eléréséhez. Az intézményen kívüli célokhoz az útválasztók használhatják az egyszerű alapértelmezett szabályt, amely szerint a csomagokat a vonalon az ISP felé kell küldeni, amelyik azután az intézményt összeköti az internet többi részével. Az összes többi célcímnek valahol kívül kell lennie.
Az internet „közepén” lévő ISP-k és gerinchálózatok útválasztói számára nem biztosított ez a luxus. Ezeknek az útválasztóknak tudnia kell, hogy melyik úton érjék el az egyes hálózatokat, az egyszerű alapértelmezés nem fog működni. Ezek a központi útválasztók az internet alapértelmezés nélküli zónájában (default-free zone) vannak. Valójában senki nem tudja, hogy hány hálózat kapcsolódik az internethez, de ez a szám meglehetősen nagy, valószínűleg legalább egymillió. Ez nagyon nagy táblázatot eredményezhet. Ez a számítógép-szabványok szerint nem tűnik nagynak, de az útválasztóknak minden csomagtovábbításnál bele kell nézniük a táblázatba, és a nagy ISP-k útválasztói másodpercenként akár több millió csomagot is továbbíthatnak. A csomagok ilyen sebességű feldolgozásához speciális hardver és gyors memória szükséges, nem egy általános célú számítógép.
Ezenfelül az útválasztó algoritmusok azt igénylik, hogy minden útválasztó átadja a többinek az általa elért címekkel kapcsolatos információt. Minél nagyobbak a táblázatok, annál több információt kell átadni és feldolgozni. A feldolgozás legalább lineárisan növekszik a táblázat méretével. Minél több a kommunikáció, annál nagyobb a valószínűsége annak, hogy az információ egy része elvész, legalábbis ideiglenesen, amely instabil útválasztáshoz vezethet.
Az útválasztó táblázatok problémája megoldható lett volna mélyebb hierarchia használatával. Működhetne például egy olyan IP-cím, ami ország, állam/tartomány, város, hálózat és hoszt mezőket tartalmazna. Ekkor minden útválasztónak csak azt kéne tudnia, hogyan juthat egy adott országba, a saját országán belüli államokba/tartományokba, a saját államában vagy tartományában lévő városokba, és a városán belüli hálózatokba. Sajnos ez a megoldás lényegesen több mint 32 bitet igényelne az IP-címek számára, és nem használná ki hatékonyan a címeket (Liechtensteinnek ugyanannyi bitje lenne, mint az Egyesült Államoknak).
Szerencsére, azért tehetünk valamit az útválasztó táblázat méretének csökkentése érdekében. Alkalmazhatjuk ugyanazt a megoldást, mint az alhálózatokra bontás esetében: a különböző helyeken lévő útválasztók tudhatják egy adott IP-címről, hogy különböző méretű előtagokhoz tartozik. Ahelyett azonban, hogy a címblokkot alhálózatokra osztatnánk, több kis előtagot egyesítünk egyetlen nagyobb előtagba. Ezt a folyamatot útvonal-csoportosításnak (route aggregation) hívják. Az eredményül kapott nagyobb előtagot szuperhálózatnak (supernet) is nevezik, az alhálózatokkal ellentétben, amelyeket a címblokkok felosztása eredményez.
A csoportosítással az IP-címeket különböző méretű előtagok fogják tartalmazni. Ugyanazt az IP-címet, amelyet az egyik útválasztó a /22 (ez a blokk 210 címet tartalmaz) részeként kezeli, elképzelhető, hogy másik útválasztó a nagyobb /20 (amely 212 címet tartalmaz) részeként kezeli. Minden útválasztó saját feladata, hogy birtokában legyen a megfelelő előtag-információnak. Ez a kialakítás alhálózatokra bontást használ és CIDR-nek (Classless InterDomain Routing, osztály nélküli körzetek közti útválasztás) hívják. Ennek legújabb változatát az RFC 4632 írja le [Fuller és Li, 2006]. A név kiemeli a különbséget azon címekkel szemben, amelyek a hierarchiát osztályokkal kódolják. Ezt röviden ismertetjük.
A CIDR-t egyszerűbben megérthetjük a következő példán keresztül. Van egy 8192 IP-címből álló blokk, ahol a címek 194.24.0.0-tól kezdve állnak rendelkezésre. Tegyük fel, hogy a Cambridge-i Egyetemnek 2048 címre van szüksége, és megkapja a 194.24.0.0-tól 194.24.7.255-ig terjedő címtartományt, a 255.255.248.0 maszkkal. Ez megfelel a /21 előtagnak. Következőként az Oxfordi Egyetem kér 4096 címet. Mivel a 4096 címből álló blokknak 4096-os bájthatárra kell kerülnie, nem kaphatja meg a 194.24.8.0-tól kezdődő címeket, helyette a 194.24.16.0-tól a 194.24.31.255-ig terjedő címeket kapja, a 255.255.240.0 alhálózati maszkkal. Végül az Edinburghi Egyetem kér 1024 címet, és megkapja a 194.24.8.0-tól 194.24.11.255-ig terjedő címtartományt a 255.255.252.0 maszkkal. Ezeket a kiosztásokat foglalja össze az 5.50. ábra.
Az alapértelmezés nélküli zóna összes útválasztója megkapja a három hálózatban lévő IP-címeket. Az egyetemekhez közeli útválasztóknak szüksége lehet arra, hogy minden előtaghoz más-más kimenő vonalon küldjenek csomagokat, így minden előtaghoz kell egy bejegyzés az útválasztó táblázatban. Erre példa az 5.51. ábrán látható Londonban lévő útválasztó.
Most nézzük meg ezt a három egyetemet a New Yorkban lévő távoli útválasztó szemszögéből. A három előtagban lévő összes IP-címet New Yorkból (illetve az USA-ból általában) Londonba kell küldeni. A londoni útválasztási folyamat észleli ezt, és a három előtagot összefogja a 194.24.0.0/19 csoportos bejegyzésbe, és ezt átadja a New York-i útválasztónak. Az előtag 8K címet tartalmaz és lefedi a három egyetemet, valamint a nem kiosztott 1024 címet. Csoportosítással a három előtagból egy lesz, ezzel csökken az előtagok száma, amelyről a New Yorkban lévő útválasztót, illetve a hozzá tartozó útválasztó táblázat bejegyzéseit frissíteni kell.
Csoportosítás alkalmazásával ez automatikus folyamat; az egyes előtagok interneten elfoglalt helyétől függ, nem pedig attól, hogy az adminisztrátor hogyan rendeli hozzá a címeket a hálózatokhoz. A csoportosítást sűrűn használják az interneten, és ez az útválasztó táblázatok méretét körülbelül 200 000 előtagra csökkentheti.
További csavar, hogy az előtagok átfedhetik egymást. Az a szabály, hogy a csomagokat a legjobban meghatározott útvonal irányába kell küldeni, vagy a leghosszabb egyező előtag (longest matching prefix) irányába, amely a legkevesebb IP-címet tartalmazza. A leghosszabb egyező előtagalapú útválasztás eléggé rugalmas, ahogy az a New York-i útválasztó viselkedésén látható (lásd 5.52. ábra). Ez az útválasztó egyetlen csoportos előtagot használ három angol egyetem számára London irányába küldéséhez. A korábban ebben az előtagban elérhető címblokk azonban egy San Franciscó-i hálózatnak lett kiosztva. Egyik lehetőség, hogy a New York-i útválasztó négy előtagot tart fenn. Ezek közül hármat a Londonba küldendő csomagokhoz, és egyet a San Franciscóba küldendő csomagokhoz. Ehelyett a leghosszabb egyező előtagalapú útválasztás ezt a továbbítást a két előtaggal tudja kezelni, ahogy azt láthatjuk. Egy teljes (az összes előtagot tartalmazó) előtagot arra használnak, hogy a teljes címblokk forgalmát Londonba irányítsák. Egy specifikusabb előtagot arra használnak, hogy a nagyobb előtag egy részéhez tartozó forgalmat San Franciscóba irányítsák. A leghosszabb egyező előtag szabályának segítségével a San Francisco-i hálózaton lévő IP-címek a kimenő vonalon San Francisco felé, a nagyobb előtagban lévő összes többi IP-cím pedig London felé kerül továbbküldésre.
Elméletben a CIDR működése a következő. Amikor egy csomag érkezik, az útválasztó megnézi az útválasztó táblázatot annak eldöntéséhez, hogy a cél az előtagon belül található-e. Elképzelhető, hogy több különböző előtaghosszal rendelkező bejegyzés felel meg ennek. Ebben az esetben a leghosszabb előtaggal rendelkező bejegyzést használja fel. Így ha a /20 és /24 maszkkal egyaránt van egyezés, akkor a /24 bejegyzést használja a csomaghoz tartozó kimenő vonal meghatározásához. Ez a folyamat azonban fárasztó lenne, ha a táblázatot tényleg bejegyzésről bejegyzésre végignézné. Ehelyett összetett algoritmusokat alakítottak ki a címegyeztetési folyamat felgyorsítása érdekében [Ruiz-Sanchez és mások, 2001]. A kereskedelmi forgalomban lévő útválasztók egyéni VLSI-chipeket használnak, amelyekben ezt az algoritmust hardverbe ágyazzák.
Annak jobb megértése érdekében, hogy miért hasznos a CIDR, röviden bemutatjuk azt a kialakítást, amely a CIDR-t megelőzte. 1993 előtt az IP-címeket öt kategóriába sorolták, amelyet az 5.53. ábra mutat. Ezt a kiosztást osztályalapú címzésnek (classful addressing) nevezték.
Az A, B és C osztályú formátumok sorrendben a következő címtartományokat teszik lehetővé: legfeljebb 128 hálózat, mindegyiken 16 millió hoszttal, 16 384 hálózat 65 536 hoszttal, illetve 2 millió hálózat (például LAN) 256 hoszttal (ezek közül néhány speciális). A többesküldés is támogatott (a D formátumú osztály), amelyben a datagram több hoszt felé kerül továbbításra. Az 1111-gyel kezdődő címeket jövőbeli használatra tartják fenn. Ezeket érdemes lenne használni az IPv4-címtér kimerülése miatt. Sajnálatos módon számos hoszt nem fogadja el ezeket a címeket érvényesként, mivel azok sokáig kívül estek a korlátokon, ezért nehéz megtanítani a régi hosztokat új trükkökre.
Ez egy hierarchikus kialakítás, de a CIDR-rel ellentétben a címblokkok mérete rögzített. Több mint kétmilliárd cím létezik ugyan, de a címtartomány osztályok szerinti szervezésének gyakorlata ebből több milliót elveszteget. Az igazi bajkeverők konkrétan a B osztályú hálózatok. A legtöbb intézménynek egy 16 millió címet tartalmazó, A osztályú hálózat túl nagy, míg a 256 címet tartalmazó C osztályú hálózat túl kicsi. Egy 65 536 címet tartalamzó B osztályú hálózat viszont éppen megfelelő. Az internet folklórjában ez a helyzet a három medve problémája (three bears problem) néven ismert [Southey, 1848].
A valóságban egy B osztályú cím a legtöbb intézmény számára túl nagy. Tanulmányok is kimutatták, hogy a B osztályú hálózatok több mint a fele 50-nél kevesebb hoszttal rendelkezik. Ilyen esetekben egy C osztályú hálózat is elegendő lett volna, de nyilván minden B osztályú címet kérő intézmény úgy gondolta, hogy egy napon kinövi a 8 bites hosztmezőt. Visszatekintve, esetleg jobb lett volna, ha a C osztályú hálózatok 8 helyett 10 bitet használtak volna a hosztszámhoz, amely így hálózatonként 1022 hosztot tenne lehetővé. Ebben az esetben a legtöbb intézmény valószínűleg megelégedett volna egy C osztályú címmel, és ezekből félmillió darab lehetne (szemben a mindössze 16 384 B osztályú hálózattal).
Nehéz az internet tervezőit hibáztatni azért, mert nem hagytak több (és kisebb) B osztályú címet. Azokban az időkben, amikor meghozták a döntést a három osztály létrehozásáról, az internet egy kutatási hálózat volt, ami a főbb amerikai kutatóegyetemeket kötötte össze (és ezeken kívül még nagyon kevés céget és katonai támaszpontot, amelyek hálózati kutatással foglalkoztak). Senki sem látta az internetben a jövő tömeges kommunikációs rendszerét, ami még a telefonhálózattal is felveszi majd a versenyt. Azokban az időkben az emberek minden bizonnyal azt mondták: „Az USA-nak körülbelül 2000 főiskolája és egyeteme van. Még ha az összes rákapcsolódik is az internetre, és más országokból is sok egyetem csatlakozik, akkor sem érjük el a 16 000-et, hiszen nincs is annyi egyetem az egész világon. Továbbá, ha a hosztszám egész számú bájtból áll, az gyorsítja a csomagok feldolgozását” (amelyet ezután teljes egészében a szoftver végzett). Elképzelhető, hogy egy napon az emberek visszanéznek, és a telefonszám-sémát kialakító szakembereket hibáztatják, a következő felkiáltással: „Micsoda idióták. Miért nem rakták bele a bolygó számát a telefonszámba?” De jelenleg ez nem tűnik szükségesnek.
A probléma megoldása érdekében alhálózatokat vezettek be a címblokkok rugalmas hozzárendeléséhez az intézményen belül. Később kialakították a CIDR-t a globális útválasztó táblázat méretének csökkentésére. Manapság az IP-cím azon bitjei, amelyek jelzik, hogy a cím A, B vagy C osztályú hálózathoz tartozik, már nincsenek használatban, azonban az irodalomban még gyakran hivatkoznak ezekre az osztályokra.
Ahhoz, hogy lássuk, hogy az osztályok elhagyása hogyan teszi még bonyolultabbá a továbbítást, nézzük meg, hogy milyen egyszerű volt ez a régi osztályalapú rendszerben. Amikor egy csomag megérkezett egy útválasztóhoz, az IP-címének másolatát 28 bittel jobbra léptették, hogy megkapják a 4 bites osztályszámot. Ezután 16-felé szétválogatták a csomagokat A, B, C (valamint D és E) osztályra, ahol nyolc eset tartozott az A osztályhoz, négy a B-hez, illetve kettő a C-hez. Az egyes osztályok kódja ezután kimaszkolta a 8, 16 vagy 24 bites hálózatszámot, és jobbra igazította egy 32 bites szóban. A hálózatszámot azután kikeresték az A, B vagy C táblázatból, általában az A és a B hálózat szerint indexelve és a C szerint hash-elve. Amint meglett a bejegyzés, ki lehetett keresni a kimeneti vonalat és a csomag továbbítható volt. Ez sokkal egyszerűbb, mint a leghosszabb egyező előtagművelet, amely a továbbiakban nem tud egy egyszerű táblázatban keresni, mivel az IP-címnek tetszőleges hosszúságú előtagja lehet.
A D osztályú címeket továbbra is használják az interneten a többesküldéshez. Valójában pontosabb, ha azt mondjuk, hogy többesküldésre kezdik használni, mivel az interneten történő többesküldés a múltban nem terjedt el széles körben.
Számos más címnek speciális jelentése van, ahogy azt az 5.54. ábra mutatja. A legkisebb IP-címet, a 0.0.0.0-át, a hosztok az elinduláskor használják. Ez „ezt a hálózatot” vagy „ezt a hosztot” jelenti. Azok az IP-címek, amelyeknek a hálózatszáma 0, az aktuális hálózatra vonatkoznak. Ezek a címek lehetővé teszik a gépeknek, hogy a saját hálózatukra hivatkozzanak anélkül, hogy tudnák annak a számát (de a hálózati maszkot ismerniük kell, hogy tudják, hány 0-t tegyenek az elejére). A csupa 1-ből álló cím, azaz a legnagyobb, 255.255.255.255 cím a jelzett hálózat összes hosztját jelenti. Ez lehetővé teszi az adatszórást a helyi hálózaton, jellemzően egy LAN-on. Azok a címek, amelyeknek helyes a hálózatcíme, hosztmezője pedig csupa 1-est tartalmaz, lehetővé teszik adatszóró csomagok küldését az interneten bárhol elhelyezkedő távoli LAN-okra. Azonban számos hálózati adminisztrátor letiltja ezt a szolgáltatást, mivel általában veszélyt jelent a biztonságra. Végül a 127.xx.yy.zz formájú címek visszacsatolásos tesztelésre vannak fenntartva. Az erre a címre küldött csomagok nem kerülnek ki a vezetékre; ezeket a rendszer helyileg dolgozza fel, és bejövő csomagként kezeli. Ez lehetővé teszi csomagok küldését a hosztnak anélkül, hogy az adó ismerné annak számát. Ez a tesztelésnél hasznos.
Az IP-címek szűkös erőforrások. Ha egy internetszolgáltatónak mondjuk /16 címe van, akkor ezzel 65 534 darab hosztszámhoz jut. Ha ennél több ügyfele van, bajban van.
Az IP-címek hiánya olyan technikák kialakulásához vezetett, amelyek az IP-címeket takarékosan használják. Egyik megoldás, ha a hálózatra bejelentkező számítógép dinamikusan kap IP-címet, amit a kapcsolat lezárásakor vissza is vesznek. A cím ezután hozzárendelhető másik számítógéphez, amely aktívvá válik. Ily módon egyetlen /16-os címmel akár 65 534 aktív felhasználó is kiszolgálható.
Ez a stratégia jól működik néhány esetben, például betárcsázó hálózatok, valamint mobil és egyéb olyan számítógépek esetén, amelyek ideiglenesen ki vannak kapcsolva vagy nem csatlakoznak a hálózatra. Üzleti felhasználók esetén azonban nem megfelelő. Itt a PC-ktől elvárják, hogy folyamatosan be legyenek kapcsolva. Néhány alkalmazott gépéről éjszaka készítenek biztonsági mentést, más gépek pedig kiszolgálók lehetnek, amelyeknek távoli kéréseket kell kiszolgálniuk késlekedés nélkül. Ezek a vállalatok olyan összeköttetéssel rendelkeznek, amely állandó kapcsolatot biztosít az internet felé.
A dolgot tovább nehezíti, hogy egyre több otthoni felhasználó fizet elő az internetre ADSL-en vagy kábeltévé-hálózaton keresztül, mivel nincs csatlakozási költség (csak havi alapdíj). Számos felhasználónak van legalább két számítógépe otthon, gyakran minden családtagnak egy, és mindannyian egész nap el szeretnék érni az internetet. Erre a megoldás, hogy az otthoni PC-ket egy LAN-nal kötik össze, amelyre egy (vezeték nélküli) útválasztót is tesznek. Az útválasztó csatlakozik az internetszolgáltatóhoz. A szolgáltató szemszögéből a család ezután ugyanolyan, mint egy néhány számítógépet tartalmazó kisvállalat. Üdvözöljük a Kovács Rt.-nél! Az eddig bemutatott technikákkal minden számítógépnek saját IP-címmel kell rendelkeznie egész nap. Több ezer ügyféllel – különösen üzleti ügyfelekkel és kis vállalatként működő családi ügyfelekkel – kapcsolatban levő ISP esetén az IP-címek iránti igény gyorsan meghaladhatja a rendelkezésre álló blokkot.
Az IP-címek hiánya nem elvi probléma, ami talán valamikor a távoli jövőben bekövetkezik. Ez itt és most történik. A hosszú távú megoldás az, hogy az egész internet átáll az IPv6-ra, amely 128 bites címeket használ. Az átállás lassan meg is történik, de még évek telnek el, mire befejeződik. Ezért gondolták néhányan azt, hogy rövid távon gyors javításra van szükség. Ez a gyors javítás a NAT (Network Address Translation – hálózati címfordítás) képében jött el. A NAT-ot az RFC 3022 írja le, amelyet az alábbiakban foglaljuk össze. További információkért lásd Dutcher [2001] munkáját.
A NAT alapötlete az, hogy az internetszolgáltató minden otthon vagy cég számára egyetlen egy (vagy legalábbis kevés számú) IP-címet oszt ki. Egy vállalati hálózaton belül minden számítógép egyedi IP-címet kap, amit a házon belüli forgalom irányításához használnak. Amikor viszont egy csomag elhagyja a vállalati hálózatot, és kimegy az ISP felé, akkor címfordításra kerül sor: az egyedi belső IP-cím helyét egy osztott nyilvános IP-cím veszi át. Ez a fordítás három IP-címtartományt használ, amelyet privát használatra jelöltek ki. A hálózatok ezeket belsőleg tetszőlegesen használhatják. Az egyetlen kikötés az, hogy magán az interneten nem jelenhet meg olyan csomag, ami ezeket a címeket tartalmazza. A három fenntartott címtartomány a következő:
|
10.0.0.0 |
– 10.255.255.255/8 |
(16 777 216 hoszt) |
|
172.16.0.0 |
– 172.31.255.255/12 |
(1 048 576 hoszt) |
|
192.168.0.0 |
– 192.168.255.255/16 |
(65 536 hoszt) |
Az első tartomány 16 777 216 hoszt számára nyújt elegendő címet (leszámítva az összes 0-t és összes 1-et, mint mindig), a legtöbb vállalat ezt is választja, még akkor is, ha nincs is szükségük ennyi címre.
A NAT működését az 5.55. ábra mutatja be. A vállalat határain belül minden gépnek egyedi címe van, 10.x.y.z alakban. Ha azonban egy csomag elhagyja a vállalat területét, akkor áthalad egy NAT-dobozon (NAT box), ami átalakítja a belső IP-forráscsomópont, vagyis az ábrán a 10.0.0.1 címet a vállalat tényleges IP-címére, ami példánkban 198.60.42.12. A NAT-dobozt gyakran a tűzfallal együtt, egy eszközben valósítják meg, mert a tűzfal a biztonság érdekében amúgy is gondosan megvizsgálja, hogy mi jön be a vállalathoz, és mi lép ki onnan. A tűzfalakat a 8. fejezetben fogjuk tanulmányozni. A NAT-dobozt ezenkívül akár az útválasztóval vagy az ADSL-modemmel is egybeépíthetik.
Eddig még mindig átsiklottunk egy apró részlet fölött: amikor a válasz visszaérkezik (például egy webszervertől), természetesen a 198.60.42.12 címre küldik. Honnan tudja ekkor a NAT-doboz, hogy melyik címre cserélje ki ezt? Ebben rejlik a NAT problémája. Ha lenne még egy maradék mező az IP-fejrészben, azt felhasználhatnánk arra, hogy nyomon kövessük, ki volt az eredeti feladó; azonban már csak egy 1 bit maradt kihasználatlanul. Elvileg készíthetnénk egy új opciót, ami az eredeti forráscímet tartalmazná, de ehhez az egész internet összes gépének szoftverét meg kellene változtatni, hogy kezeljék ezt az új opciót. Ez nem túl ígéretes alternatíva egy gyors javítás számára.
Valójában a következő történt. A NAT tervezői megfigyelték, hogy a legtöbb IP-csomag TCP- vagy UDP-tartalmat hordoz. Amikor a 6. fejezetben tanulmányozni fogjuk a TCP-t és az UDP-t, látni fogjuk, hogy mindkettejük fejrésze tartalmaz egy forrásport- és egy célportmezőt. Az alábbiakban csak a TCP-portokat tárgyaljuk, de ugyanaz érvényes az UDP-portokra is. A portok 16 bites egészek, amelyek azonosítják, hogy hol kezdődik és végződik egy TCP-kapcsolat. Ezek a portok lesznek tehát azok a mezők, amelyekre a NAT működéséhez szükségünk van.
Amikor egy folyamat egy TCP-kapcsolatot szeretne kiépíteni egy másik, távoli folyamattal, hozzácsatolja magát egy addig a saját gépén nem használt TCP-porthoz. Ezt nevezzük forrásportnak (source port), és ez mondja meg a TCP-szoftvernek, hogy hová küldje az adott kapcsolathoz tartozó bejövő csomagokat. A folyamat megad egy célportot (destination port) is, hogy megmondja, kinek kell a csomagokat adni a távoli oldalon. A 0–1023-ig terjedő portokat a jól ismert szolgáltatások számára tartották fenn. A webszerverek például a 80-as portot használják, így a távoli kliensek könnyen megtalálják őket. Minden kimenő TCP-üzenet tartalmaz egy forrás- és egy célportot is. Ez a két port együtt azonosítja a kapcsolatot használó folyamatokat mindkét végponton.
A következő hasonlat talán világosabbá teszi a portok használatát. Képzeljünk el egy vállalatot egy darab központi telefonszámmal. Amikor az emberek felhívják a központi számot, akkor egy központossal beszélhetnek, aki megkérdi, melyik melléket kérik, majd kapcsolja azt. A központi szám hasonló a vállalat IP-címéhez, a kapcsolat két végén a mellékek pedig hasonlók a portokhoz. A portok tulajdonképpen további 16 bitet adnak a címzéshez, hogy azonosítsák, melyik folyamat melyik bejövő csomagot kapja meg.
A Forrásport mező használatával megoldhatjuk a leképezési problémánkat. Amikor egy kilépő csomag eléri a NAT-dobozt, a 10.x.y.z forráscímet lecseréljük a vállalat igazi IP-címére. Ezenkívül, a TCP Forrásport mezőt lecseréljük egy mutatóra, amely a NAT-doboz 65 536 bejegyzésből álló fordítási táblázatába mutat. A mutatott bejegyzés tartalmazza az eredeti IP-címet és az eredeti forrásportot. Végül az IP- és a TCP-fejrészek ellenőrző összegeit is újraszámolják, és az eredményt beleírják a csomagba. Azért kell kicserélni a Forrásport mezőt, mert a 10.0.0.1 és a 10.0.0.2 gépekből induló összeköttetések is használhatják például véletlenül az 5000-es portot, vagyis a Forrásport önmagában nem elég a feladó folyamat azonosítására.
Amikor egy csomag megérkezik a NAT-dobozhoz az ISP-től, a TCP-fejrészben található Forrásport mezőt kiveszik, és indexként használják a NAT-doboz leképezési táblázatában. Az így talált bejegyzésből kiveszik a belső IP-címet és az eredeti TCP Forrásportot, és belerakják azokat a csomagba. Ezután újraszámolják mind az IP-, mind a TCP-ellenőrző összegeket, és azokat is beleírják a csomagba. A csomagot végül átadják hagyományos továbbításra a vállalati útválasztónak a 10.x.y.z cím használatával.
Jóllehet ez a séma voltaképp megoldja a problémát, az IP-közösségben mégis sokan visszataszítónak tartják. Íme, az ellenérvek rövid összegzése. Először is, a NAT megsérti az IP architekturális modelljét, mely szerint minden IP-cím globálisan egyedien egyetlen gépet azonosít. Az internet teljes szoftverstruktúrája erre a tényre épül. A NAT révén azonban több ezer gép használhatja (és használja is) a 10.0.0.1 címet.
Másodszor, a NAT felbontja az internet végponttól végpontig tartó (end-to-end) összeköttetés modelljét, mely szerint bármely hoszt küldhet bármely másik hosztnak tetszőleges időpontban csomagot. Mivel a leképezést a NAT-dobozban a kimenő csomagok állítják be, a bejövő csomagok addig nem fogadhatók el, amíg a kimenők ki nem mennek. A gyakorlatban ez azt jelenti, hogy a NAT-ot használó otthoni felhasználó TCP/IP-kapcsolatot létesíthet a távoli webszerverrel, de a távoli felhasználó nem létesíthet kapcsolatot az otthoni hálózaton lévő játék szerverrel. Ennek a helyzetnek a támogatásához speciális konfiguráció vagy NAT áthidalási technikák szükségesek.
Harmadszor, a NAT az összeköttetés nélküli internetből egyfajta összeköttetés-alapú hálózatot csinál. A gondot itt az okozza, hogy a NAT-doboznak minden rajta keresztülmenő kapcsolatról információt (egy leképezést) kell tárolnia. A kapcsolat állapotának ilyen jellegű számontartása az összeköttetés-alapú hálózatok sajátossága, és nem az összeköttetés nélkülieké. Ha a NAT-doboz összeomlik és a leképezési táblázat elvész, akkor a doboz összes TCP-összeköttetése megsemmisül. Ha nincs NAT, akkor az útválasztók összeomlása és újraindulása nincs hosszú távú hatással a TCP-összeköttetésekre. Ilyenkor mindössze az történik, hogy a feladó folyamat időzítője néhány másodperc alatt lejár, mire az minden nyugtázatlan csomagot újraad. A NAT használatával az internet olyan sebezhető lesz, mint egy vonalkapcsolt hálózat.
Negyedszer, a NAT megsérti a protokollrétegezés legfontosabb alapelvét: a k. réteg nem tehet semmilyen feltételezést arról, hogy a 
. réteg mit tett az adatmezőjébe. Az alapelv az, hogy a rétegeknek függetleneknek kell lenniük. Ha a TCP-t egyszer továbbfejlesztik TCP-2-re, és megváltozik a fejrész formátuma (például 32 bitesek lesznek a portszámok), akkor a NAT megbukik. A rétegezett protokollok lényege éppen az, hogy biztosítják, hogy az egyik rétegben bekövetkezett változások nem követelik meg a többi réteg megváltoztatását. A NAT felborítja ezt a függetlenséget.
Ötödször, a folyamatok az interneten nem feltétlenül használnak TCP-t vagy UDP-t. Ha az A gépen egy felhasználó úgy dönt, hogy egy új szállítási protokoll segítségével fog beszélgetni a B gép felhasználójával (például egy multimédiás alkalmazás útján), akkor a NAT-doboz bevezetésével az alkalmazás már nem fog működni, mert a NAT-doboz nem fog megfelelő TCP Forrásportot találni.
A hatodik probléma, hogy néhány alkalmazás több TCP/IP-kapcsolatot vagy UDP-portot használ előre leírt módon. A szabványos FTP (File Transfer Protocol – fájlátviteli protokoll) például a csomag törzsébe illeszti az IP-címeket, hogy a vevő azután innen kivehesse és használja. Mivel a NAT semmit nem tud ezekről a címekről, így nem tudja kicserélni azokat, illetve másképp sem tud róluk számot adni. Ezen ismeret hiánya azt jelenti, hogy az FTP és más alkalmazások, mint például a H.323 internettelefon protokoll (amit a 7. fejezetben fogunk tanulmányozni), NAT jelenlétében csődöt mondhat, hacsak nem teszünk különleges óvintézkedéseket. A NAT-ot esetleg meg lehet javítani, hogy működjön így is, de az nem túl jó ötlet, hogy a NAT-doboz szoftverét egy új alkalmazás megjelenésekor minden egyes alkalommal újra ki kelljen javítani.
És végül, mivel a TCP Forrásport 16 bites, legfeljebb 65 536 gépet lehet egy IP-címhez rendelni. A tényleges érték ennél kicsit kevesebb, mert az első 4096 portot speciális célokra tartják fenn. Ha azonban nem egy, hanem több IP-cím áll rendelkezésünkre, akkor mindegyikkel lekezelhetünk legfeljebb 61 440 gépet.
A NAT több más problémája mellett ezeket is tárgyalja az RFC 2993. A problémák ellenére a NAT-ot a gyakorlatban sok helyen használják, különösen otthoni és kis vállalati hálózatokhoz, mivel ez az egyetlen kisegítő eszköz az IP-címek hiányának kiküszöbölésére. Ez a tűzfalakkal is együttműködik, és a titkosságnak is megfelel, mivel alapértelmezésben blokkolja a kéretlen bejövő csomagokat. Ezért valószínűleg az IPv6 széles körű alkalmazása esetén sem fog megszűnni.
Az IP-t már évtizedek óta intenzíven használják. Eddig rendkívül jól működött, ahogy azt az internet exponenciális növekedése is mutatja. Sajnos az IP gyors tempóban lesz saját népszerűségének áldozata: kezd kifogyni a címekből. Bár a CIDR és a NAT takarékosan használja a címeket, az ICANN várhatóan kiosztja az utolsó IPv4-címeket 2012 vége előtt.[26] Ez a fenyegető végzet sok tárgyalást és vitát szült az internet közösségén belül arról, hogy mit is lehetne ez ellen tenni.
Ebben a szakaszban megtárgyaljuk a problémát, és a megoldási javaslatokat is. Az egyetlen hosszú távú megoldás a hosszabb címekre való áttérés. Az IPv6 (az IP 6-os változata) helyettesítő kialakítás, amely éppen ezt teszi: 128 bites címet használ. Nem túl valószínű, hogy ezek a címek az előre látható jövőben elfogyjanak. Az IPv6 bevezetése azonban nagyon bonyolult. Ez a hálózati rétegnek egy másik protokollja, amely a sok hasonlóság ellenére nem működik igazán együtt az IPv4-gyel. A vállalatok és felhasználók egyáltalán nem biztosak abban, hogy miért kell valaha is alkalmazniuk az IPv6-ot. Ennek következtében az IPv6-ot csak az internet nagyon kis részében (körülbelül 1%-ában) használják annak ellenére, hogy 1998 óta internetszabvány. A következő néhány év érdekes időszak lesz, ahogy az utolsó néhány meglévő IPv4-cím kiosztása megtörtént. Az emberek elkezdik majd árulni az IPv4-címüket az eBayen? Fel fog virágozni a címek feketepiaci kereskedelme? Ki tudja.
Az említett címproblémákon kívül egy másik kérdés is bujkál a háttérben. Az internetet korai éveiben nagyrészt az egyetemek, a csúcstechnológiai ipar és az Egyesült Államok kormányzata (különösen a Honvédelmi Minisztérium) használta. Az internet iránti érdeklődés az 1990-es években robbanásszerűen megnőtt. Sokan kezdték el használni, mégpedig jellemzően eltérő igényű emberek. Ma egyfelől rengeteg, okostelefonnal rendelkező ember használja az otthoni bázissal való kapcsolattartásra. Másfelől a számítástechnika, a távközlés és a szórakoztatóipar közelgő konvergenciája miatt lehetséges, hogy nemsokára a világon minden telefon- és televíziókészülék egy internetcsomópont lesz, ami milliárdnyi hálózati zenehallgatásra és videózásra használt gépet eredményez. Ilyen körülmények között nyilvánvalóvá vált, hogy az IP-nek fejlődnie kell, és rugalmasabbá kell válnia.
Az IETF – látván, hogy ezek a problémák feltűnnek a horizonton – 1990-ben elkezdte a munkát az IP új verzióján, egy olyan verzión, amely soha nem fogy ki a címekből, mindenféle egyéb problémákat is megold, és ezek mellett rugalmasabb és hatékonyabb is. A fő célok a következők voltak:
Támogatni a több milliárd hosztot, még nem hatékony címtartomány-hozzárendelés árán is.
Csökkenteni az útválasztó táblázatok méretét.
Egyszerűsíteni a protokollt, lehetővé téve ezzel az útválasztóknak a csomagok gyorsabb feldolgozását.
A jelenlegi IP-nél jobb biztonságot (hitelesítés és titkosság) biztosítani.
Nagyobb figyelmet szentelni a szolgáltatás típusának, különösen a valós idejű adatoknál.
Segíteni a többesküldést azáltal, hogy megadják a hatósugarakat.
Lehetőséget adni arra, hogy egy hoszt a címének megváltoztatása nélkül barangoljon.
Lehetővé tenni a protokoll fejlődését.
Meg kell engedni, hogy az új és a régi protokoll még évekig egymás mellett létezhessen.
Az IPv6 kialakítása lehetőséget adott az IPv4 összes jellemzőjének javítására, ami messze alatta marad a mai igényeknek. Az IETF egy mindezen igényt kielégítő protokoll kifejlesztése érdekében javaslatokra és vitára szóló felhívást tett közzé az RFC 1550-ben. Huszonegy válasz érkezett, közülük nem mind volt teljes javaslat. 1992 decemberére hét komoly javaslat feküdt az asztalon. Ezek az IP kisebb módosításaitól kezdve addig terjedtek, hogy az egészet ki kellene dobni, és egy teljesen másmilyen protokollal helyettesíteni.
Az egyik javaslat az volt, hogy a TCP-t a CLNP felett kell futtatni. A CLNP az OSI által tervezett hálózati protokoll, amely 160 bites címeivel mindörökre elegendő címtartományt biztosított volna, minthogy az óceánokban lévő vízmennyiség minden molekulájához elegendő címet (durván 25 számú címet) tudna adni egy kis hálózat telepítéséhez. Ezzel a választással egyesíthető lenne két fő hálózati protokoll. Sokan úgy érezték azonban, ez annak lett volna az elismerése, hogy az OSI világban tulajdonképpen valamit jól csináltak, ez az állítás pedig politikailag helytelennek minősül internetkörökben. A CLNP-t közvetlenül az IP-ről mintázták, így a kettő valójában nem különbözik annyira egymástól. Tulajdonképpen, a végül is kiválasztott protokoll sokkal jobban különbözik az IP-től, mint a CLNP. Újabb csapást az mért a CLNP-re, hogy gyatrán támogatja azokat a szolgáltatástípusokat, amelyek a multimédia hatékony átviteléhez szükségesek.
A jobb javaslatok közül hármat közölt az IEEE Network [Deering, 1993; Francis, 1993; Katz és Ford, 1993]. Sok vita, módosítás és pozícióharc után kiválasztották a Deering- és a Francis-féle javaslatok egy módosított kombinációját, amelyet ekkor már SIPP-nek (Simple Internet Protocol Plus) hívtak, és az IPv6 jelölést adták neki.
Az IPv6 egészen jól megfelel az IETF céljainak. Megtartja az IP jó tulajdonságait, elveti vagy kevésbé hangsúlyossá teszi a rosszakat, és új tulajdonságokkal egészíti ki, ahol szükség van rá. Általánosságban, az IPv6 nem kompatibilis az IPv4-gyel, de az összes többi internetprotokollal igen, beleértve a TCP-, UDP-, ICMP-, IGMP-, OSPF-, BGP- és DNS-protokollokat, néhol úgy, hogy kisebb módosításokra van szükség (főleg a hosszabb címek kezelése miatt). Alább tárgyaljuk az IPv6 főbb tulajdonságait. További információ található az RFC 2460–2466-ban.
Először, ami a legfontosabb, az IPv6-nak hosszabb címei vannak, mint az IPv4-nek. 128 bit hosszúak, amely megoldja azt a problémát, amelyet az IPv6-nak meg kell oldania: egy gyakorlatilag végtelen internetcím-ellátmányt biztosít. Nemsokára több mondanivalónk is lesz a címekről.
Az IPv6 második fő fejlesztése a fejrész egyszerűsítése. Csak 7 mezőt tartalmaz (szemben az IPv4 13 mezőjével). Ez a változás lehetővé teszi az útválasztóknak, hogy gyorsabban dolgozzák fel a csomagokat, és ezáltal javítsák az átbocsátást. A fejrészt is rövidesen megtárgyaljuk.
A harmadik fő előrelépés az opciók jobb támogatása. Ez a változás szükségszerűen együtt jár az új fejrésszel, mert a korábban megkövetelt mezők most opcionálisak lettek (mivel ezeket nem túl gyakran használják). Ezenkívül az opciók megjelenésének a módja is más, így az útválasztóknak egyszerű átlépni a nem nekik szánt opciókon. Ez a tulajdonság a csomagfeldolgozási időt gyorsítja fel.
A negyedik terület, ahol az IPv6 jelentős előrelépést tett, a biztonság. Az IETF-nek elege volt azokból az újságtörténetekből, ahol koraérett 12 évesek a személyi számítógépeikkel bankokba és katonai bázisokba törnek be az interneten. Erősen érezhető volt, hogy valamit tenni kell a biztonság javítása érdekében. A hitelesítés és a titkosság az új IP kulcstulajdonsága. Ezeket aztán visszamenőleg az IPv4-be is beépítették, így a biztonság területén a különbségek ma már nem olyan jelentősek.
Végül, több figyelmet szenteltek a szolgáltatásminőségnek is. Erre már a múltban is tettek több, lagymatag kísérletet, de most, ahogy a multimédia jobban teret hódít az interneten, a dolog egyre sürgetőbbé válik.
Az IPv6-fejrész az 5.56. ábrán látható. A Verzió mező IPv6-nál mindig 6 (és az IPv4-nél mindig 4). Az alatt az idő alatt, amíg átállnak az IPv4-ről, ami több mint egy évtizedig is eltarthat, az útválasztók megvizsgálhatják ezt a mezőt, hogy eldöntsék, milyen fajta csomagjuk van. Viszont ez az ellenőrzés mellékhatásként elveszteget pár utasítást a kritikus úton, mivel az adatkapcsolati fejrész rendszerint jelzi a demultiplexeléshez szükséges hálózati protokollt, így néhány útválasztó esetleg átlépi ezt az ellenőrzést. Az Ethernet Type mezője például különféle értékekkel rendelkezik egy IPv4 vagy IPv6 adatmező jelzésére. A „Csináljuk helyesen!” és a „Legyen gyors!” táborok közt kétségkívül hosszú és parázs viták lesznek.
A Differenciált szolgáltatások (eredetileg Forgalmi osztály) mező szolgál arra, hogy különbséget tegyenek a csomagok között, amelyeknél különbözőek a követelmények a valós idejű szállítással kapcsolatban. Ezt a differenciált szolgáltatás architektúránál használják a szolgáltatásminőséghez ugyanúgy, mint ahogy az azonos nevű mezőt használták az IPv4-csomagban. Az első két bit az explicit torlódás jelzésére szolgál ugyanúgy, mint az IPv4 esetén.
A Folyamcímke mező lehetővé teszi, hogy a forrás és a cél megjelölje azon csomagok csoportját, amelyek azonos követelményeket támasztanak, és amelyeket a hálózatnak azonos módon kell kezelnie, ezáltal egy álösszeköttetést létesítve. Például egy bizonyos forráshoszt egy folyamatától egy meghatározott címzett hoszt egy folyamatáig tartó csomagfolyamnak szigorú késleltetési igényei lehetnek, és ezért fenntartott sávszélességre van szüksége. A folyamot előre fel lehet állítani, és egy azonosítót adni neki. Amikor egy nem nulla Folyamcímke mezőjű csomag tűnik fel, minden útválasztó kikeresheti a belső táblázataiból, hogy milyen különleges elbánást igényel. Tulajdonképpen a folyamok bevezetése kísérlet arra, hogy egyszerre lehessen kihasználni a datagramalapú hálózat rugalmasságát és a virtuálisáramkör-alapú hálózat garanciáit.
A szolgáltatásminőség biztosításához minden folyamot forráscím, célcím és folyamszám alapján azonosítanak. Ez azt jelenti, hogy 
folyam lehet egy időben aktív két adott IP-cím közt. Ilyen módon, ha más hosztoktól jövő, de ugyanolyan folyamszámú folyamok ugyanazon az útválasztón haladnak keresztül, az útválasztó meg tudja azokat különböztetni a forrás- és célcím segítségével. Várhatóan a folyamszámokat véletlenszerűen fogják választani ahelyett, hogy 1-től kezdve folyamatosan osztanák ki azokat, hogy az útválasztók könnyen tudják azokat hash-elni.
Az Adatmező hossza mező megmondja, mennyi bájt következik az 5.56. ábra 40 bájtos fejrésze után. A név megváltozott az IPv4 Teljes hossz mezőjéhez képest, mivel a jelentés is módosult: a 40 fejrészbájtot már nem számolják bele a hosszba, mint régebben. Ez a módosítás azt jelenti, hogy az adatmező 65 535 bájtot tartalmazhat 65 515 bájt helyett.
A Következő fejrész mező kiengedi a zsákbamacskát. A fejrészt azért lehetett egyszerűsíteni, mert lehetnek további (opcionális) kiegészítő fejrészek. Ez a mező mondja meg, melyik kiegészítő fejrész következik a (jelenleg) hat közül, ha egyáltalán van ilyen. Ha a fejrész az utolsó IP-fejrész, a Következő fejrész mező azt mondja meg, melyik szállítási protokoll kezelőjének (TCP, UDP) kell a csomagot továbbítani.
Az Ugráskorlát mező gátolja meg a csomagokat abban, hogy azok örökké élhessenek. Ez gyakorlatilag ugyanaz, mint az Élettartam mező az IPv4-ben, vagyis egy olyan mező, amelyet minden ugrásnál csökkentenek. Elméletben az IPv4-ben ez másodpercekben mért idő volt, de egy útválasztó sem használta így, ezért megváltoztatták a nevét, hogy az a tényleges működésre utaljon.
Következnek a Forráscím és Célcím mezők. Deering eredeti javaslata, az SIP, 8 bájtos címeket használt, de a felülvizsgálási folyamat során sok ember érezte úgy, hogy 8 bájtos címekkel az IPv6 néhány évtizeden belül ki fog fogyni a címekből, míg a 16 bájtos címek soha nem fogynak el. Más emberek érvelése szerint a 16 bájt túlzás, megint mások pedig 20 bájtos címeket részesítettek volna előnyben, hogy az IPv6 kompatibilis legyen az OSI-datagramprotokollal. Egy másik frakció változó hosszúságú címeket akart. Sok vita és nyomdafestéket nem tűrő szavak után úgy határoztak, hogy a legjobb kompromisszum a rögzített hosszúságú 16 bájtos címek alkalmazása.
A 16 bájtos címek leírására új jelölésrendszert is javasoltak. Nyolc, négy-négy hexadecimális számjegyből álló csoportként írjuk le a címet, a csoportok között kettősponttal, valahogy így:
8000:0000:0000:0000:0123:4567:89AB:CDEF
Mivel a sok cím sok nullát fog tartalmazni, három ésszerűsítést engedélyeztek. Először is, egy csoporton belül a bevezető nullák elhagyhatók, így a 0123 helyett 123 írható. Másodszor, egy vagy több, 16 nullából álló csoport két kettősponttal helyettesíthető. Így a fenti címből a következő lesz:
8000::123:4567:89AB:CDEF
Végül, az IPv4-címek két kettőspont és a régi, pontokkal elválasztott decimális szám formájában írhatók fel, például:
::192.31.20.46
Talán szükségtelen ennyire hangsúlyozni, de rengeteg 16 bájtos cím létezik. Egész pontosan 
, azaz körülbelül 3 × 1038 darab van belőlük. Ha az egész Föld, szárazföldön és vízen egyaránt, számítógépekkel lenne befedve, az IPv6 7 × 1023 IP-címet tenne lehetővé négyzetméterenként. A vegyészhallgatók észre fogják venni, hogy ez a szám nagyobb az Avogadro-számnál. Bár nem az volt a szándék, hogy a Föld felszínén minden molekulának saját IP-címet adjunk, azért nem is járunk annyira messze ettől.
A gyakorlatban a címtartományt nem lehet hatékonyan kihasználni, mint ahogy a telefonszámok címtartományát sem. (A manhattani körzetszám, a 212, majdnem tele van, de a wyomingi (307) majdnem üres.) Az RFC 3194-ben Durand és Huitema kiszámolták, hogy a telefonszámok kiosztását irányadónak véve még a legpesszimistább forgatókönyv szerint is bőven több mint 1000 IP-cím jut a Föld felszínének (szárazföld és víz egyaránt) minden négyzetméterére. Röviden, nem tűnik valószínűnek, hogy a belátható jövőben kifogynánk belőlük.
Tanulságos összehasonlítani az IPv4-fejrészt (5.46. ábra) az IPv6-fejrésszel (5.56. ábra), hogy lássuk, mi maradt ki az IPv6-ból. Az IHL mező eltűnt, mert az IPv6-fejrész rögzített hosszúságú. A Protokoll mezőt is kivették, mert a Következő fejrész mező megmondja, mi jön az utolsó IP-fejléc után (például egy UDP- vagy TCP-szegmens).
A darabolással kapcsolatos összes mezőt eltávolították, mert az IPv6 másképpen közelíti meg a darabolást. Először is minden, az IPv6-hoz igazodó hoszttól elvárjuk, hogy dinamikusan határozza meg a használt datagram méretét. Ez az MTU-felderítési protokoll segítségével lehetséges, amelynek leírását az 5.5.5. szakasz tartalmazza. Röviden: amikor egy hoszt túl nagy IPv6-csomagot küld, az az útválasztó, amely képtelen azt továbbítani, darabolás helyett egy hibaüzenetet küld vissza. Ez az üzenet arra utasítja a hosztot, hogy a jövőben minden, ehhez a címzetthez tartó csomagot tördeljen fel. Az, hogy a hoszt eleve jó méretű csomagokat küld, végül is sokkal hatékonyabb, mint ha az útválasztók darabolják azokat menet közben. Ezenkívül a minimális csomagméret, amelyet az útválasztónak tovább kell tudnia küldeni, megnövekedett 576-ról 1280 bájtra, hogy az 1024 bájtos adatmezőt és számos fejrészt tegyen lehetővé.
Végül az Ellenőrző összeg mező is eltűnt, mert kiszámítása nagyban csökkenti a hatékonyságot. A ma használt hálózatok megbízhatósága és azon tény mellett, hogy az adatkapcsolati és a szállítási rétegeknek rendszerint megvan a maguk ellenőrző összege, egy újabb ellenőrző összeg hozadéka kisebb, mint amekkora romlást okoz ateljesítőképességben. Mindezen funkciók eltávolítása egy egyszerű és nagyszerű hálózati protokollt eredményezett. Az IPv6 ezzel a tervezéssel elérte célját: gyors, mégis rugalmas protokoll lett, bőséges címtartománnyal.
A hiányzó mezők közül némelyikre azért továbbra is szükség mutatkozott, így az IPv6 bevezette az (opcionális) kiegészítő fejrész (extension header) fogalmát. Ezek a fejrészek használhatók hatékony módon kódolt külön információ biztosítására. Jelenleg a kiegészítő fejrészeknek hat típusa definiált, ezeket az 5.57. ábra sorolja fel. Mindegyik opcionális, de ha több mint egy van jelen, akkor közvetlenül a rögzített fejléc után kell szerepelniük, és célszerűen a megadott sorrendben.
Némelyik fejrésznek kötött a formátuma; mások változó számú és hosszúságú mezőt tartalmaznak. Ez utóbbiaknál minden tétel egy (Típus, Hossz, Érték) hármasként van kódolva. A Típus egy 1 bájtos mező, amely azt mondja meg, hogy melyik opcióról van szó. A Típus értékeket úgy választották meg, hogy az első 2 bit megmondja az útválasztónak, mit tegyen, ha nem tudja feldolgozni az opciót. A lehetőségek: átugorni az opciót; eldobni a csomagot; eldobni a csomagot és visszaküldeni egy ICMP-csomagot; valamint eldobni a csomagot és nem küldeni vissza az ICMP-csomagot a többesküldéses címre (hogy egy rossz csomag ne generáljon több millió ICMP-jelentést).
A Hossz is egy 1 bájtos mező. Azt mondja meg, milyen hosszú az érték (0 és 255 bájt közt). Az Érték 255 bájt erejéig bármilyen kívánt információ lehet.
Az Ugrás opciók fejrészt olyan információhoz használják, amelyeket minden, útba eső útválasztónak meg kell vizsgálnia. Eddig egyetlen ilyen opciót definiáltak a 64 KB-nál hosszabb datagramok támogatására. Ennek a fejrésznek a formátumát az 5.58. ábra mutatja. Amikor ezt az opciót használják, akkor a rögzített fejrészben az Adatmező hossza mező értékét 0-ra állítják be.
Mint minden kiegészítő fejrész, ez is egy olyan bájttal kezdődik, amelyik megmondja, hogy milyen lesz a következő fejrész. Ezt a bájtot egy másik követi, amelyik azt tudatja, hogy hány bájt hosszú az ugrás opció fejrésze, leszámítva az első 8, kötelező bájtot. Minden kiegészítő fejrész így kezdődik.
A következő két bájt jelzi, hogy ez az opció a datagram méretét határozza meg (194-es kód), egy 4 bájtos szám formájában. Az utolsó négy bájt adja meg a datagram méretét. A 65 536 bájtnál kisebb méretek nem megengedettek. Ha ilyen mégis előfordulna, az első útválasztó eldobja a csomagot, és visszaküld egy ICMP-hibaüzenetet. Az ilyen fejrész-kiegészítést használó datagramokat óriás datagramoknak vagy jumbogramoknak nevezik. A jumbogramok használata a szuperszámítógépes alkalmazások számára fontos, melyeknek gigabájt nagyságrendű adatokat kell hatékonyan átvinni az interneten.
A Címzetti opciók fejrészt olyan mezőknek szánták, melyeket csak a címzett csomópontban kell értelmezni. Az IPv6 kezdeti verziójában ide nem definiáltak mást, csak üres opciókat, hogy kitöltsék ezt a fejrészt 8 bájt többszörösére, ezt a fejrészt tehát eleinte nem fogják használni. Azért került bele mégis a protokollba, hogy az új útválasztó- és hosztszoftverek használhassák, ha egy napon valakinek egy címzetti opcióra lenne szüksége.
Az Útválasztás opció fejrész egy vagy több útválasztót sorol fel, melyeket a célhoz vezető úton fel kell keresni. Ez nagyon hasonlít az IPv4 laza forrás általi útválasztásához annyiban, hogy minden felsorolt címet sorban végig kell járni, de közben más, nem felsorolt útválasztókat is útba lehet ejteni. Az útválasztás opció fejrészformátumát az 5.59. ábra mutatja.
Az útválasztás opció kiegészítő fejrészének első 4 bájtja négy 1 bájtos egész számot tartalmaz. A Következő fejrész és a Kiegészítő fejrész hossza mezőket már leírtuk. Az Útválasztás típusa mező megadja a fejrész hátralévő részének formátumát. A 0 típus azt jelenti, hogy egy fenntartott 32 bites szó követi az első szót, majd bizonyos számú IPv6-cím következik. A jövőben más típusokat is kitalálhatnak, ha szükség lesz rá. Végül a Hátralevő szegmensek száma mező tartja számon, hogy a listában szereplő címek közül még hányat nem látogattunk meg. Ezt minden útválasztó érintése után eggyel csökkentik. Amikor a számláló eléri a 0-t, akkor a csomag már csak magára hagyatkozhat, és nem kap több útmutatást arra nézve, hogy melyik utat kövesse. Ezen a ponton általában olyan közel van a céljához, hogy a legjobb útvonal már egyértelmű.
A Darabolási opció fejrésze az IPv4-hez hasonlóan kezeli a darabolást. A fejrészben szerepel a datagramazonosító, a darabszám és egy bit, amelyik arról értesít, hogy jönnek-e még további darabok. Az IPv4-től eltérően az IPv6-ban már csak a forráshoszt darabolhat fel egy csomagot, az útba eső útválasztók nem. Ez ugyan nagy gondolkodásmódbeli törés az eredeti IP-hez képest, de tartja magát az IPv4 gyakorlatához. Ezenfelül egyszerűbbé teszi az útválasztók munkáját, és meggyorsítja az útválasztást. Ahogy fentebb említettük, ha az útválasztó egy túl nagy csomaggal találja magát szemben, akkor eldobja azt, és visszaküld egy ICMP-csomagot a forráshosztnak. Ez az információ teszi lehetővé a forráshoszt számára, hogy ezt a fejrészt használva kisebb részekre darabolja a csomagot, és újra próbálkozzon.
A Hitelesítés opció fejrésze egy olyan eljárást biztosít, mellyel a csomag vevője meggyőződhet róla, hogy tényleg a feladó küldte-e a csomagot. A Titkosított biztonsági adatmező lehetővé teszi, hogy egy csomag tartalmát úgy titkosítsuk, hogy csak a szándékaink szerinti vevő tudja elolvasni. Ezek a fejrészek titkosító módszereket használnak küldetésük teljesítéséhez. Ezeket a módszereket a 8. fejezetben mutatjuk be.
Tudván a nyílt tervezési folyamatról és arról, hogy sok érintett ember makacsul ragaszkodott az álláspontjához, nem okozhat meglepetést, hogy számos, az IPv6 esetében hozott döntés erősen vitatott volt. Ezek közül néhányat összefoglalunk az alábbiakban. A részleteket lásd az RFC-kben.
Már megemlítettük a vitát a címek hosszáról. Az eredmény egy kompromisszum: 16 bájtos rögzített hosszúságú címek.
Szintén csata bontakozott ki az Ugráskorlát mező hossza körül. Az egyik tábor nagyon úgy érezte, hogy a maximális ugrásszám (a 8 bites mezőből adódó) 255-re való korlátozása öreg hiba. Végül is, a 32 ugrásból álló utak ma már elterjedtek, és 10 év múlva sokkal hosszabb utak is elterjedhetnek. Ezek az emberek azzal érveltek, hogy egy hatalmas méretű cím használata előrelátó volt, de egy kicsi ugrásszámláló használata rövidlátásra utal. Álláspontjuk szerint a legnagyobb bűn, amit egy számítástechnikus elkövethet, hogy valahol túl kevés bitet hagy meg.
A válasz az volt, hogy minden mező megnövelésére akad érv, de ez felduzzadt fejrészhez vezetne. Egyébként is, az Ugráskorlát mező feladata, hogy a csomagok ne kószálhassanak hosszú ideig szerteszét, és 65 535 ugrás túlságosan hosszú. Végül, ahogy az internet növekszik, egyre több és több nagy távolságú összeköttetés fog kiépülni, lehetővé téve, hogy bármely országból bármely más országba legfeljebb fél tucat ugrással eljussunk. Ha 125 ugrásnál több szükséges eljutni a forrástól a megfelelő nemzetközi átjáróikhoz, akkor valami nincs rendben a nemzeti gerinchálózatokkal. A 8 bitet támogatók nyerték meg ezt a csatát.
A másik hevesen vitatott téma a csomagméret volt. A szuperszámítógépes társadalom 64 KB-nál nagyobb csomagokat akart. Amikor egy szuperszámítógép átvitelbe kezd, akkor tényleg dolga van, és nem akarja, hogy 64 KB-onként megszakítsák. A nagy csomagok ellen az az érv merült fel, hogy ha egy 1 MB-os csomag elér egy 1,5 Mb/s-os T1 vonalat, akkor ez a csomag 5 másodpercre lefoglalja a vonalat, és jól észlelhető késleltetést okoz a szintén ezt a vonalat használó interaktív felhasználóknál. Itt kompromisszum született: a rendes csomagokat 64 KB-ra korlátozták, de az Ugrás kiegészítő fejrész használható jumbogramok engedélyezésére.
A harmadik forró téma az IPv4 ellenőrző összegének eltávolítása volt. Néhány ember ezt ahhoz hasonlította, mintha egy autóból kiszednénk a fékeket. Ha így teszünk, az autó könnyebb lesz, és gyorsabban haladhat, de ha valami váratlan esemény történik, akkor gond van.
Az ellenőrző összegek elleni érv az volt, hogy bármely alkalmazásnak, amely valóban törődik az adatintegritással, amúgy is kell lennie egy ellenőrző összegének a szállítási rétegben, így túlzás az IP-be is berakni egyet (az adatkapcsolati réteg ellenőrző összegén felül).
A mozgó hosztok is vita tárgyát képezték. Ha egy hordozható számítógép félig körberepüli a világot, működhet-e tovább a célban ugyanazzal az IPv6-címmel, vagy egy hazai és idegen ügynökös sémát kelljen használnia? Néhányan a mozgó hosztok számára kifejezett támogatást akartak beépíteni az IPv6-ba. Ez az erőfeszítés meghiúsult, amikor egyik javaslatban sem tudtak megegyezni.
A legnagyobb csata valószínűleg a biztonság körül dúlt. Mindenki egyetértett abban, hogy szükség van rá. A harc azzal kapcsolatban folyt, hogy hol és hogyan legyen. Először nézzük a hol kérdését. A hálózati rétegbe helyezése mellett az az érv szólt, hogy ekkor ez szabványos szolgáltatássá válik, amelyet minden alkalmazás minden előzetes tervezés nélkül használhat. Az ellene szóló érv az, hogy a valóban titkos alkalmazások a végpontok közötti titkosításnál nem érik be kevesebbel, ahol is a forrásalkalmazás végzi a titkosítást, és a célalkalmazás fejti vissza. Bármivel, ami ennél kevésbé biztonságos, a felhasználó ki van szolgáltatva a hálózati réteg esetlegesen hibás megvalósításának, amelyek fölött nem bír ellenőrzéssel. Erre az érvre az a válasz, hogy ezek az alkalmazások tartózkodhatnak az IP titkosítási tulajdonságainak kihasználásától, és maguk végezhetik el a munkát. Erre pedig az a viszontválasz, hogy azok, akik nem bíznak meg abban, hogy a hálózat jól végezné el ezt, nem akarják megfizetni az ilyen képességű lassú és terjedelmes IP-megvalósítások árát, még ha az ki is van kapcsolva.
A biztonság elhelyezésének másik vetülete ahhoz kapcsolódik, hogy sok (de nem minden) országnak szigorú kiviteli törvényei vannak a titkosításra nézve. Néhány ország, főképpen Franciaország és Irak, belföldön is nagyban korlátozza a használatát, hogy az embereknek ne lehessenek titkaik a rendőrség előtt. Ennek eredményeként semmilyen olyan IP-megvalósítást, amely elég erős titkosító rendszert használ ahhoz, hogy valóban hasznos legyen, nem lehet kivinni az Egyesült Államokból (és sok más országból) a vásárlókhoz világszerte. A legtöbb számítógépes cég erőteljesen ellenzi azt, hogy két szoftverkészletet kelljen karbantartania, egyet belföldi használatra és egyet kivitelre.
Egy ponton nem volt vita, és ez az, hogy senki sem számít arra, hogy egy vasárnap reggel kikapcsolják az IPv4-internetet, és az hétfő reggel IPv6-internetként indul újra. Ehelyett elkülönült IPv6-„szigetek” fognak először átállni, kezdetben alagutakon keresztül kommunikálva, ahogy azt az 5.5.3. fejezetben láthattuk. Ahogy az IPv6-szigetek nőnek, úgy olvadnak össze egyre nagyobb szigetekké. Végül minden sziget össze fog olvadni, és az internet teljesen át fog állni.
Legalábbis ez volt a terv. A bevezetés megmutatta az IPv6 Achilles-sarkát. Továbbra is alig használják, annak ellenére, hogy minden nagy operációs rendszer teljes mértékig támogatja. A legtöbb bevezetés új szituáció, amelyben a hálózati operátor – például egy mobiltelefonos operátor – nagyszámú IP-címet igényel. Számos stratégia került kialakításra az egyszerű átállás biztosítása érdekében. Ezek között van olyan, amely automatikusan beállítja az alagutat, amely átviszi az IPv6-csomagot az IPv4-interneten, illetve olyan, amely lehetővé teszi, hogy a hosztok automatikusan megtalálják az alagút végpontjait. A két protokollkészlettel rendelkező (dual-stack) hosztoknak egyaránt van IPv4 és IPv6 implementációja, így a csomag célcíme alapján kiválaszthatják, hogy melyik protokollt kell használni. Ezek a stratégiák fájdalommentessé teszik az IPv6 alapvető bevezetését, amely elkerülhetetlen lesz, amikor az IPv4-címek elfogynak. További információ az IPv6-tal kapcsolatban Davies [2008] munkájában található.
Az adattovábbításra használt IP-n kívül az internetnek számos, a hálózati rétegben használt vezérlőprotokollja van, mint például az ICMP, ARP és a DHCP. Ebben a szakaszban sorban mindegyiknek áttekintjük az IPv4-nek megfelelő változatát, mivel ezek az általánosan használt protokollok. Az ICMP és DHCP hasonló változattal rendelkezik az IPv6-hoz is. Az ARP IPv6-megfelelőjét NDP-nek (Neighbour Discovery Protocol – szomszédfelderítési protokoll) nevezik.
Az internet működését az útválasztók szorosan figyelemmel kísérik. Amikor valami váratlan esemény történik a csomag feldolgozása során egy útválasztóban, ezt az eseményt az ICMP (Internet Control Message Protocol – internetes vezérlőüzenet protokoll) segítségével jelenti. Az ICMP-t az internet tesztelésére is használják. Körülbelül egy tucat ICMP-üzenetet definiáltak. A legfontosabbakat az 5.60. ábra sorolja fel.
A cél elérhetetlen üzenetet akkor használják, ha az útválasztó nem tudja megtalálni a célt, vagy egy DF bittel rendelkező csomagot nem lehet kézbesíteni, mert egy „kiscsomagos” hálózat az útjába állt.
Az időtúllépés üzenetet akkor küldik, ha egy csomagot azért dobnak el, mert a számlálója elérte a nullát. Ez az esemény annak a tünete, hogy a csomagok hurokba kerültek, hogy hatalmas torlódás van, vagy az időzítő értékét túl alacsonyra állították be.
Ennek a hibaüzenetnek az egyik értelmes használata a traceroute (útkövetés) segédprogram, amelyet Van Jacobson fejlesztett ki 1987-ben. A traceroute megtalálja a hoszt és a címzett IP-címe közötti útvonal mentén lévő útválasztókat. Ezt az információt mindenfajta privilegizált hálózati támogatás nélkül találja meg. A módszer egyszerű: csomagok sorozatának elküldése a cél felé, az Élettartam mezőbe írt először 1-es, majd 2-es, 3-as stb. értékkel. A csomagokban lévő átlépésszámlálók elérik a nullát, ahogy végighaladnak az útvonal mentén lévő egymás utáni útválasztókon. Ezek az útválasztók egyenként időtúllépés üzenetet küldenek vissza a hosztnak. Ezekből az üzenetekből a hoszt meg tudja határozni az útvonal mentén lévő útválasztók IP-címét, illetve statisztikát és időzítéseket tarthat fenn az útvonal egyes részeiről. Ez nem az, amire az időtúllépés üzenetet eredetileg szánták, de talán a valaha alkalmazott leghasznosabb hálózati hibakereső eszköz.
A paraméterprobléma üzenet azt jelzi, hogy egy fejrészmezőbe érvénytelen érték került. Ez hibát jelez az adóhoszt IP-szoftverében, vagy esetleg egy, az út során érintett útválasztó szoftverében.
A forráslefojtás üzenetet régebben a túl sok csomagot küldő hosztok visszafogására használták. Amikor egy hoszt ilyen üzenetet kapott, le kellett lassítania. Manapság már ritkán használják, mert amikor torlódás következik be, ezek a csomagok csak olajat öntenek a tűzre. Az interneten a torlódáskezelés most nagyrészt a szállítási rétegben történik, és a 6. fejezetben fogjuk tanulmányozni.
Az átirányítás üzenetet akkor használják, ha egy útválasztó észreveszi, hogy egy csomag rosszul irányítottnak tűnik. Az útválasztó használja, hogy a küldő hosztot értesítse a valószínű hibáról.
A visszhang kérés és visszhang válasz üzeneteket arra használják, hogy meggyőződjenek arról, hogy egy adott hoszt elérhető-e és pillanatnyilag életben van-e. A visszhang kérés üzenetet megkapva, a címzettnek vissza kell küldenie egy visszhang válasz üzenetet. Ezeket az üzeneteket a ping segédprogram használja, amely ellenőrzi, vajon a hoszt működik-e és elérhető-e az interneten.
Az időbélyeg kérés és időbélyeg válasz üzenetek hasonlók, kivéve, hogy az üzenet érkezési ideje és a válasz indulási ideje is szerepelnek a válaszban. Ezt a tulajdonságot a hálózati teljesítőképesség mérésére használják.
Az útválasztó hirdetés és útválasztó kérelmezés üzenetek segítségével a hosztok meg tudják keresni a közeli útválasztókat. A hosztnak meg kell tanulnia legalább egy útválasztó IP-címét ahhoz, hogy csomagokat küldhessen a helyi hálózatnak.
A fentieken kívül más üzeneteket is definiáltak. Az üzenetek online listáját a www.iana.org/assignments/icmp-parameters webcímen találhatjuk.
Bár az interneten levő összes gépnek van egy (vagy több) IP-címe, ezeket voltaképpen nem használhatjuk csomagok küldésére, mivel az adatkapcsolati réteg hálózati csatolókártyája (NIC), mint amilyen az Ethernet-kártya is, nem érti az internetcímeket. Az Ethernet esetében minden eddig gyártott csatolókártya egy 48 bites Ethernet-címmel ellátva érkezik. Az Ethernet-kártyák gyártói egy címtartományt igényelnek az IEEE-től, hogy biztosan ne legyen két kártyának ugyanaz a címe (hogy elkerüljék az ütközéseket, ha a két kártya valaha is ugyanazon a LAN-on tűnne fel). A kártyák a 48 bites Ethernet-címekre alapozva küldenek és fogadnak kereteket. Semmit sem tudnak a 32 bites IP-címekről.
Felmerül a következő kérdés: hogyan képezik le az IP-címeket az olyan adatkapcsolati rétegbeli címekre, mint amilyen az Ethernet-cím is. Ennek a működését az 5.61. ábra példáján keresztül magyarázzuk el, ahol egy kisebb egyetem két /24-es hálózata látható. Két kapcsolt Ethernet-hálózat: egy a Számítástudományi Tanszéken (SZT), 192.32.65.0/24 előtaggal, és egy a Villamosmérnöki Tanszéken (VT), 192.32.63.0/24 előtaggal. A két LAN-t IP-útválasztó köti össze, amelynek egyedi Ethernet-címe van, E1-től E6-ig jelölve, és egyedi IP-címe az SZT vagy a VT hálózatán.
Kezdésként nézzük meg, hogyan küld az 1. hoszt egyik felhasználója egy csomagot az SZT hálózaton lévő 2. hoszt egy felhasználójának. Tegyük fel, hogy a küldő ismeri a szándéka szerinti vevő címét, valami ilyesmit: eagle.cs.uni.edu . Az első lépés a 2., eagle.cs.uni.edu -ként ismert hoszt IP-címének megkeresése. Ezt a felkutatást a DNS (Domain Name System – körzetnévkezelő rendszer) végzi, amelyet a 7. fejezetben tanulmányozunk majd. Most csak feltételezzük, hogy a DNS visszaadja a 2. hoszt IP-címét (192.32.65.5).
Az 1. hoszt felsőbb rétegbeli szoftvere most felépít egy csomagot 192.32.65.5-tel a Célcím mezőben, és átadja az IP-szoftvernek átvitelre. Az IP-szoftver megnézi a címet, és látja, hogy a cél az SZT (azaz a saját hálózatán) van, de valami módon meg kell találnia a cél Ethernet-címét. Egy megoldás az, hogy legyen egy konfigurációs állomány valahol a rendszerben, amely leképezi az IP-címeket Ethernet-címekre. Ez a megoldás természetesen lehetséges, de a több ezer gépet üzemeltető intézmények számára ezeknek az állományoknak a naprakészen tartása hibára hajlamos, időrabló munka.
Jobb megoldás az, hogy az 1. hoszt kiad egy adatszóró csomagot az Ethernetre, kérdezvén: „Kié a 192.32.65.5-ös IP-cím?” Az adatszórás az SZT Ethernet-hálózatának minden gépéhez megérkezik, és mindegyik ellenőrzi az IP-címét. Csak a 2. hoszt fog válaszolni a saját Ethernet-címével (E2-vel). Ily módon az 1. hoszt megtudja, hogy a 192.32.65.5-ös IP-cím az E2-es Ethernet-című hoszton van. Ennek a kérdésnek a feltevésére és a válasz megkapására szolgáló protokoll az ARP (Address Resolution Protocol – címfeloldási protokoll). Az interneten majdnem minden gép futtatja, és az RFC 826 definiálja.
Az ARP előnye a konfigurációs állományokkal szemben az egyszerűség. A rendszermenedzsernek nincs sok dolga, csak minden géphez egy IP-címet kell hozzárendelnie és dönteni az alhálózati maszkok felől. Az ARP elvégzi a többit.
Ezen a ponton az 1. hoszt IP-szoftvere felépít egy Ethernet-keretet E2-nek címezve, belehelyezi a (192.32.65.5-nek címzett) IP-csomagot az adatmezőbe, és ráadja az Ethernetre. A csomag IP- és Ethernet-címét az 5.61. ábra mutatja. A 2. hoszt Ethernet-kártyája észleli a keretet, begyűjti, és egy megszakítást kezdeményez. Az Ethernet-meghajtó kicsomagolja az IP-csomagot az adatmezőből és átadja az IP-szoftvernek, amely látja, hogy helyes a címzés, és feldolgozza.
Változatos optimalizálások lehetségesek az ARP hatékonyabbá tételére. Először is, ha egyszer egy gép futtatta az ARP-t, eltárolja az eredményt arra az esetre, ha rövid idő múlva ugyanazzal a géppel kell kapcsolatba lépnie. A következő alkalommal megtalálja a hozzárendelést a saját gyorstárában, ezáltal szükségtelenné válik a második adatszórás. Sok esetben a 2. hosztnak vissza kell küldenie egy választ, ezáltal arra kényszerül, hogy az adó Ethernet-címének megállapításához futtassa az ARP-t. Ezt az ARP-adatszórást el lehet kerülni, ha az 1. hoszt beleteszi az IP–Ethernet hozzárendelését az ARP-csomagba. Amikor az ARP-csomag megérkezik a 2. hoszthoz, a (192.32.65.7, E1) pár bekerül a 2. hoszt gyorstárába majdani felhasználásra. Tulajdonképpen az Etherneten levő összes gép bejegyezheti ezt a leképezést a saját ARP gyorstárába.
Hogy lehetőséget adjunk a leképezések megváltoztatására, amikor egy hoszt új IP-cím használatára van beállítva (de megtartja a régi Ethernet-címet), akkor az ARP gyorstárában lévő bejegyzéseknek pár perc után le kell járniuk. A gyorstárban lévő adatok aktuálisan tartásának és a teljesítőképesség optimalizálásának intelligens módja, ha minden gép adatszórással közli a leképezést beállításkor. Az adatszórás általában a saját IP-címre vonatkozó ARP-kikeresés formájában történik. Erre nem szükséges válasz, de az adatszórás mellékhatása, hogy mindenki ARP-gyorstárában bejegyzés keletkezik vagy frissül a meglévő bejegyzés. Ezt önkényes ARP-nek (gratuitous ARP) hívják. Ha a válasz (váratlanul) megérkezik, akkor a két géphez ugyanaz az IP-cím tartozik. A hibát a hálózatkezelőnek meg kell oldani ahhoz, hogy mindkét gép használni tudja a hálózatot.
Most nézzük újra az 5.61. ábrát, csak most az 1. hoszt a 4. (192.32.63.8) hosztnak akar egy csomagot küldeni a VT hálózaton. Az 1. hoszt látja, hogy a címzett IP-címe nem az SZT hálózaton van. Tudja, hogy az összes hálózaton kívüli forgalmat az útválasztóhoz kell küldeni, amelyet alapértelmezett átjárónak (default gateway) hívnak. Megegyezés szerint az alapértelmezett átjáró a hálózat legkisebb címe (198.32.65.1). Egy keret útválasztóhoz küldéséhez az 1. hosztnak ismernie kell az útválasztó interfész Ethernet-címét az SZT hálózaton. Ennek felderítéséhez egy ARP-adatszórócsomag kerül kiküldésre a 198.31.65.1 címre, amelyből megismeri az E3-at. Ezután elküldi a keretet. Ugyanezt a kikereső módszert használják, ha egy csomagot egy internetútvonalon lévő egyik útválasztótól egy másik útválasztóra küldenek.
Amikor az útválasztó Ethernet NIC-kártyája megkapja a keretet, átadja a csomagot az IP-szoftvernek. A hálózati maszkokból tudja, hogy a csomagot a VT hálózatra kell küldenie, ahol eléri a 4. hosztot. Ha az útválasztó nem tudja a 4. hoszt Ethernet-címét, akkor újra az ARP-t használja. Az 5.61. ábra táblázata megjeleníti a forrás és cél Ethernet- és IP-címet, amelyek megtalálhatók a keretekben, ahogy az SZT és VT hálózaton ezt megvizsgálták. Figyeljük meg, hogy az Ethernet-címek változnak az egyes hálózatokon lévő keretekkel, miközben az IP-címek azonosak maradnak (mivel azok az összekapcsolt hálózatok végpontjait jelzik).
Az is lehet, hogy az 1. hoszt a 4. hosztra küldjön csomagot anélkül, hogy tudná, hogy a 4. hoszt másik hálózaton található. Erre az a megoldás, hogy az útválasztó ARP-ket küld az SZT hálózaton a 4. hosztra és válaszként megadja az E3 Ethernet-címet. A 4. hoszt erre nem tud közvetlenül válaszolni, mivel nem látja az ARP-kérést (mert az útválasztók nem továbbítják az Ethernet-szintű adatszórás-üzeneteket). Az útválasztó ezután megkapja a 192.32.63.8 címre küldött kereteket, majd továbbítja azokat a VT hálózatra. Ezt a megoldást helyettesítő ARP-nek (proxy ARP) nevezik. Ezt olyan speciális helyzetekben használják, ahol a hoszt meg kíván jelenni a hálózaton úgy is, hogy valójában másik hálózaton található. Általános helyzet például egy mobil számítógép, amely azt szeretné, hogy egy másik csomópont vegye fel a neki küldött csomagokat, amikor nem az otthoni hálózaton tartózkodik,
Az ARP (ahogy más internetprotokollok is) feltételezi, hogy a hosztokat ellátták alapvető információval, mint amilyen például a saját IP-címük. Hogyan kapják meg a hosztok ezt az információt? Be lehet állítani ezt minden számítógépen kézzel is, de ez hosszadalmas és nagy a hibázás lehetősége. Van erre egy jobb módszer. Ezt DHCP-nek (Dynamic Host Configuration Protocol – dinamikus hosztkonfigurációs protokoll) hívják.
DHCP alkalmazása esetén minden hálózaton kell lennie egy DHCP-kiszolgálónak, amely a konfigurációért felelős. A számítógépek elindításkor beépített Ethernet- vagy egyéb, a hálózati kártyába ágyazott adatkapcsolati rétegbeli címmel rendelkeznek, de IP-címmel nem. Az ARP-hez hasonlóan a számítógép adatszórással IP-címet kér a hálózaton. Ezt dhcp felfedezés csomag küldésével teszi. A csomagnak el kell érnie a DHCP-kiszolgálót. Ha ez a kiszolgáló nem közvetlenül csatlakozik a hálózathoz, akkor az útválasztót úgy állítják be, hogy fogadja a DHCP adatszóró üzeneteket és továbbítja azokat a DHCP-kiszolgáló felé, bárhol is található az.
Amikor a kiszolgáló megkapja a kérést, kioszt egy szabad IP-címet és elküldi azt a hosztnak a dhcp ajánlat csomagban (amely újra továbbításra kerülhet az útválasztón keresztül). Ahhoz, hogy a hosztok ezt IP-cím nélkül is meg tudják tenni, a kiszolgáló a hosztot az Ethernet-címével azonosítja (amelyet a dhcp felfedezés csomag tartalmaz).
Az IP-címeknek egy külön készletből (pool) történő automatikus kiosztása felveti azt a kérdést, hogy vajon mennyi időre osszanak ki egy IP-címet. Ha egy hoszt elhagyja a hálózatot, és nem adja vissza az IP-címét a DHCP-kiszolgálónak, akkor ez a cím tartósan elveszik. Egy idő után sok cím tűnhet el így. Ennek megelőzésére kioszthatjuk az IP-címeket rögzített időtartamra is. Ezt a módszert lízingelésnek (leasing) nevezik. A hosztnak röviddel a lízing lejárta előtt újítást kell kérnie a DHCP-kiszolgálótól. Ha nem sikerül ilyen kérelmet küldenie vagy a kiszolgáló elutasítja a kérelmet, akkor a hoszt nem használhatja tovább a korábban kapott IP-címet.
A DHCP leírását az RFC 2131 és a 2132 tartalmazza. Ezt az interneten széles körben használják mindenféle paraméter beállítására az IP-címkiosztáson felül. A vállalati és otthoni hálózatokon egyaránt használják az ISP-k az eszközök paramétereinek internetkapcsolaton keresztüli beállításához, így az ügyfeleknek nem kell telefonon beszerezniük ezt az információt az ISP-től. A beállított adatokra általános példa a hálózati maszk, az alapértelmezett átjáró IP-címe, valamint a DNS és pontos-idő-szerver IP-címe. A DHCP jórészt teljesen felváltotta a korábbi, korlátozottabb funkcionalitású protokollokat (RARP és BOOTP).
Eddig az internet hálózati rétegében való navigáció során a csomagokat kizárólag az IP-útválasztók által továbbított datagramokként kezeltük. Másik módszer is létezik, amely kezd széles körben elterjedni, különösen az internetszolgáltatók körében, az internetes forgalom hálózaton történő továbbítása érdekében. Ezt a technológiát többprotokollos címkekapcsolásnak (MultiProtocol Label Switching, MPLS) nevezik, és nagyon hasonlít a vonalkapcsoláshoz. Annak ellenére, hogy az internetes közösségben sokan erős ellenérzéseket táplálnak az összeköttetés-alapú hálózatokkal szemben, az ötlet mégis újra meg újra felbukkan. Ahogy Yogi Berra mondta, ez olyan, mint a deja vu újra és újra. Ugyanakkor az internet és az összeköttetés-alapú hálózatok alapvetően különböző módon építik fel az útvonalaikat, tehát ez a módszer semmiképp sem azonos a hagyományos vonalkapcsolással.
Az MPLS egy címkét rak be minden csomag elé, és a csomag a címke alapján kerül továbbításra, nem a célcím alapján. Mivel a címke egy belső táblázat indexe, a megfelelő kimenő vonal a táblázatból meghatározható. Ennek a módszernek az alkalmazásával a továbbítás nagyon gyors lehet. Főképp ez motiválta az MPLS kialakítását, amely számos különböző (szabadalmaztatott) név alatt fut, mint például a címkekapcsolás (tag switching). Az IETF végül szabványosította az elgondolást. Ezt a protokollt többek között az RFC 3031 írja le. A fő előny, hogy az útválasztás rugalmas, és a továbbítás megfelel a szolgáltatásminőségnek, valamint gyors.
Az első kérdés, hogy hová tegyük a címkét? Mivel az IP-csomagokat nem virtuális áramkörökhöz tervezték, az IP-fejrész nem tartalmaz mezőt a virtuálisáramkör-azonosítók számára. Ezért új MPLS-fejrészt kell tenni az IP-fejrész elé. Az 5.62. ábra két útválasztó közötti vonalon használatos PPP adatkapcsolati protokoll keretszerkezetét mutatja, beleértve a PPP-, MPLS-, IP- és TCP-fejrészeket is.
Az általános MPLS-fejrész 4 bájt hosszú és 4 mezőből áll. Ezek közül a legfontosabb a Címke (Label) mező, amely az indexet tartalmazza. A QoS mező a szolgáltatásminőségi osztályt jelzi. Az S mező több, egymásra halmozott címkére utal (lásd lejjebb). A TtL mező azt mutatja, hogy a csomag még hányszor továbbítható. Ennek értékét minden útválasztó csökkenti, és ha ez eléri a 0-t, akkor a csomagot eldobják. Ez akadályozza meg, hogy egy csomag útválasztási zavar esetén a végtelenségig keringjen.
Az MPLS az IP hálózati protokoll és a PPP adatkapcsolati protokoll közé esik. Nem tartozik igazán a 3. réteghez, mivel a címkeútvonalak kialakítása IP- vagy más hálózatiréteg-címtől függ. Nem is tartozik igazán a 2. réteghez sem, mivel több ugráson át továbbít csomagokat, nem egyetlen adatkapcsolaton. Ezért az MPLS-t 2,5 rétegbeli protokollnak is hívják. Ez szemlélteti, hogy a valós protokollok nem mindig illeszkednek tökéletesen az idealizált rétegezett protokollmodellbe.
Mivel az MPLS-fejrész sem a hálózati réteg csomagnak, sem az adatkapcsolati réteg keretnek nem része, az MPLS nagyban független mindkét rétegtől. Ez többek közt azt is jelenti, hogy olyan MPLS-kapcsolók is készíthetők, melyek IP- és nem-IP-csomagokat egyaránt képesek továbbítani, attól függően, hogy éppen mi érkezik. Innen ered a „többprotokollos” szó az elnevezésben. Az MPLS képes IP-csomagokat nem-IP-hálózatokon is átvinni.
Amikor egy MPLS-címkével kiegészített csomag megérkezik egy LSR-hez (Label Switched Router – címkekapcsolt útválasztó), a címkét táblázatindexként használják a használandó kimeneti vonal és új címke meghatározásához. Az effajta címkecserélgetést a virtuálisáramkör-alapú hálózatokban is használják, mert a címkéknek csak helyi jelentésük van, és két különböző útválasztó ugyanazon a kimeneti vonalon össze nem tartozó csomagokat is továbbíthat ugyanazon címke használatával. Ahhoz, hogy a címkék a másik oldalon megkülönböztethetők legyenek, minden ugrásnál újra le kell képezni azokat. Ezt a mechanizmust láthattuk már működés közben az 5.3. ábrán. Az MPLS ugyanezt a módszert használja.
Kis kitérőként megjegyezzük, hogy egyesek különbséget tesznek a továbbítás és a kapcsolás között. A továbbítás során a célcímet keressük ki egy táblázatból, hogy megtudjuk, hová kell küldeni a csomagot. Erre példa az IP-továbbításhoz használt leghosszabb egyező előtag algoritmus. A kapcsolás ellenben a csomagban található címkét használja indexként a továbbítási táblázathoz. Ez gyorsabb és egyszerűbb. Ezek a definíciók persze még messze nem univerzálisak.
Mivel a legtöbb hoszt és útválasztó nem érti az MPLS-t, meg kell kérdeznünk, hogy mikor és hogyan kerülnek a címkék a csomaghoz. Ez akkor történik, amikor egy IP-csomag eléri az MPLS-hálózat szélét. Az LER (Label Edge Router – hálózatszéli útválasztó) megvizsgálja a címzett IP-címét és a többi mezőt, és ez alapján meghatározza, hogy a csomagot melyik MPLS-útvonalon kell továbbítani, és a megfelelő címkét a csomag elejére helyezi. Az MPLS-hálózat ezt a címkét használja a csomag továbbítására. Az MPLS-hálózat másik szélén a címke beteljesíti hivatását, és eltávolításra kerül, újra kinyitva az IP-csomagot a következő hálózat számára. Ezt a folyamatot az 5.63. ábra mutatja. Az MPLS és a hagyományos virtuális áramkörök között az egyik legnagyobb különbség a csoportosítás (aggregation) szintje. Az egyes folyamok minden további nélkül rendelkezhetnek saját címkekészlettel az MPLS-hálózatban. Sokkal gyakoribb azonban, hogy az útválasztók több, egy adott útválasztónál vagy LAN-nál végződő folyamot összefognak, és egy közös címkét használnak hozzájuk. Az egy címkéhez csoportosított folyamokat egyazon továbbítási ekvivalenciaosztályhoz (Forwarding Equivalence Class, FEC) tartozónak nevezzük. Ez az osztály nemcsak a csomagok címzettjét, hanem szolgáltatási osztályát is lefedi (a differenciált szolgáltatások értelmében), mert a továbbítás szempontjából az osztály minden csomagját egyformán kezeli.
A hagyományos virtuális áramkörös útválasztásnál nem lehet több, különböző címzetthez tartó útvonalat egyazon virtuálisáramkör-azonosítóval ellátni, mert ekkor a végső célállomásnál nem lehetne őket egymástól megkülönböztetni. MPLS használata esetén a csomagok továbbra is tartalmazzák a célcímet a címkén kívül, így a címkézett útvonal végén a címkefejrészt el lehet távolítani, és a továbbítás a megszokott módon folytatódhat a hálózati rétegbeli célcím felhasználásával.
Valójában az MPLS ennél továbbmegy. Az MPLS egyszerre több szinten is működhet azáltal, hogy több címke kerül a csomag elé. Tételezzük fel például, hogy számos csomag van, különböző címkékkel (mivel a csomagokat eltérően kívánjuk kezelni a hálózatban), amelyeknek ugyanazt az útvonalat kell követniük néhány célhoz. Ahelyett, hogy számos címkekapcsolási útvonalat kellene beállítani (minden címkéhez egyet), beállítható egyetlen útvonal. Amikor a már felcímkézett csomagok elérik az útvonal elejét, másik címke adódik hozzá. Ezt címkék vermének (stack of labels) hívjuk. A legkülső címke irányítja a csomagokat az útvonal mentén, majd az útvonal végén eltávolításra kerül, és előkerülnek az esetleges további címkék, amelyek a csomag további továbbításához használhatók. Az 5.62. ábrán bemutatott S bit lehetővé teszi, hogy az útválasztó eltávolítson egy címkét annak kiderítése érdekében, hogy maradtak-e még további címkék. Az S bitet 1-re állítják a legalsó címkében, és 0-ra minden egyéb címkében.
A végső kérdés, hogy a címketovábbítási táblázatok hogyan épülnek fel, hogy a csomagok követhessék őket. Az MPLS és a hagyományos virtuális áramkörök között ez az egyik legnagyobb különbség. Ha a felhasználó egy összeköttetést szeretne kiépíteni egy hagyományos virtuálisáramkör-alapú hálózatban, akkor egy kapcsolatfelépítő csomagot indít útjára a hálózatban, hogy létrehozza az útvonalat és a megfelelő bejegyzéseket a továbbítási táblázatokban. Az MPLS nem vonja be a felhasználókat a beállítási fázisba. Ha a felhasználótól a datagram küldésén kívül bármi mást is elvárnánk, az túl sok meglévő internetszoftvert érintene.
Ehelyett a továbbítási információt az útválasztó és összeköttetés-beállítási protokollokat magában foglaló protokollok adják meg. Ezek a vezérlőprotokollok tisztán elkülönülnek a címketovábbítástól, amely több különböző vezérlőprotokoll használatát teszi lehetővé. Az egyik változat a következőképpen működik. Amikor egy útválasztó elindul, akkor megnézi, hogy mely útvonalak számára lesz ő a végállomás (azaz, hogy mely előtagok tartoznak az interfészeihez). Ezeknek aztán létrehoz egy vagy több FEC-t, mindegyikhez hozzárendel egy címkét, majd átadja a címkéket a szomszédjainak. Ezek aztán beírják a címkéket a továbbítási táblázataikba, és új címkéket küldenek a szomszédjaiknak, míg végül minden útválasztó megtanulja az útvonalat. A megfelelő szolgáltatásminőség érdekében erőforrások is lefoglalhatók az út kiépítése során. Más változatok különböző útvonalakat alakíthatnak ki, mint amilyenek például a forgalomtervezési útvonalak, amelyek a nem használt kapacitást veszik figyelembe, és igény szerint hoznak létre útvonalakat a különféle szolgáltatások támogatásához, mint amilyen például a szolgáltatásminőség.
Bár az MPLS mögött rejlő alapötlet eléggé kézenfekvő, a részletek már rendkívül bonyolultak, számtalan változattal és használati esettel, amelyek aktívan megvalósításra kerülnek. További információért lásd Davie és Farrel [2008], valamint Davie és Rekhter [2000] munkáit.
Az imént befejeztük az internet csomagtovábbítási módjainak tárgyalását. Ideje továbblépnünk következő témánkra: az interneten belüli útválasztásra. Ahogy már korábban is említettük, az internet nagyszámú autonóm rendszerből (AS) tevődik össze. Minden AS-t más intézmény működtet, általában egy vállalat, egyetem vagy internetszolgáltató (ISP). A saját hálózatukon belül az intézmények saját algoritmust használhatnak a belső útválasztásra, vagy ismertebb nevén a körzeten belüli útválasztásra (intradomain routing). Azonban csak néhány szabványos protokoll vált népszerűvé. Ebben a részben a körzeten belüli útválasztás problémáját fogjuk tanulmányozni, és megtekintjük a gyakorlatban széles körben használt OSPF-protokollt. A körzeten belüli útválasztó protokollt belső átjáró protokollnak (interior gateway protocol) is nevezik. A következő részben a függetlenül működő hálózatok közötti útválasztás problémáját, azaz a körzetek közötti útválasztást (interdomain routing) fogjuk tanulmányozni. Ehhez az összes hálózatnak ugyanazt a körzetek közötti útválasztást, avagy külső átjáró protokollt (exterior gateway protocol) kell használnia. Az interneten használt protokoll a BGP (Border Gateway Protocol – határátjáró protokoll).
A korai belső átjáró protokoll a Bellman–Ford-algoritmusra épülő távolságvektor-alapú protokoll volt, amelyet az ARPANET-ből vettek át. Ennek a manapság használt fő példája a RIP (Routing Information Protocol – útválasztási információ protokoll). Ez kis rendszerekben jól működött, de ahogy a hálózatok nagyobbak lettek, egyre kevésbé volt elfogadható. Szenvedett a végtelenig számolás problémájától és általában a lassú konvergenciától is. E problémák miatt az ARPANET 1979 májusában áttért egy kapcsolatállapot-alapú protokollra, és 1988-ban az IETF elkezdett kidolgozni egy ilyen protokollt a körzeten belüli útválasztáshoz. A protokoll neve OSPF (Open Shortest Path First – nyílt hozzáférésű, a legrövidebb utat előrevevő protokoll), amely 1990-ben szabvány lett. Ez az ISO-szabvány IS-IS (Intermediate-System to Intermediate-System) protokollra épül. A közös örökség miatt a két protokoll nagyon hasonlít egymásra. A teljes történet az RFC 2328-ban olvasható. Ezek a domináns körzeten belüli útválasztó protokollok, és a legtöbb útválasztógyártó mindkettőt támogatja. Az OSPF-et főként a vállalati hálózatok, az IS-IS protokollt pedig az ISP-hálózatok használják szélesebb körben. Mi az OSPF működését vázoljuk.
Mivel már sok tapasztalat gyűlt össze más útválasztó protokollokról, az OSPF protokollt tervező csoportnak hosszú listája volt a teljesítendő követelményekről. Először is, az algoritmust a mindenki által hozzáférhető irodalomban kellett publikálni, innen az „O” (Open) az OSPF-ben. Nem felelt volna meg egy olyan egyedi megoldás, amelyet egyetlen vállalat birtokol. Másodszor, az új protokollnak mindenféle távolságmetrikát támogatnia kellett, beleértve a fizikai távolságot, a késleltetést és így tovább. Harmadszor, dinamikus algoritmusnak kellett lennie, méghozzá olyannak, amely a topológia változásaihoz automatikusan és gyorsan alkalmazkodik.
Negyedszerre, és ez új az OSPF-ben, támogatnia kellett a szolgáltatás típusára alapozott útválasztást. Az új protokollnak képesnek kellett arra lennie, hogy a valós idejű forgalmat egy adott útvonalra, a másfajta forgalmat pedig másfelé irányítsa. Az IP-protokollnak van egy Szolgáltatás típusa mezője, de semmilyen létező útválasztó protokoll nem használta. Ez a mező az OSPF-ben is szerepelt, de még így sem használta senki, ezért végül eltávolították. Ez a követelmény talán megelőzte korát, ahogy az IETF munkája is megelőzte a differenciált szolgáltatásokat, amely megújította a szolgáltatási osztályokat.
Ötödszörre, és a fentiekkel összefüggésben, az új protokolltól elvárták, hogy több vonalra szétosztva egyenlítse ki a terhelést is. A legtöbb, ezt megelőző protokoll minden csomagot a legjobb útvonalon küldött el, még abban az esetben is, ha létezett két egyformán jó útvonal. A második legjobb útvonalat egyáltalán nem használták. Sok esetben a terhelés több vonalra való szétosztása jobb teljesítőképességet ad.
Hatodszor, a hierarchikus rendszerek támogatására is szükség volt. 1988-ra az internet már olyan nagyra nőtt, hogy egyik útválasztótól sem lehetett elvárni, hogy ismerje az egész topológiát. Az új protokollt úgy kellett megtervezni, hogy erre egyik útválasztónak se legyen szüksége.
Hetedszerre, valami kevés biztonságra is szükség volt, hogy a mókás kedvű hallgatókat meggátolják abban, hogy az útválasztókat hamis útválasztási információ küldésével félrevezessék. Végül valamilyen rendelkezésre is szükség volt az olyan útválasztók kezeléséhez, amelyek alagút típusú átvitelen keresztül kapcsolódtak az internethez. Az előző protokollok ezt nem kezelték jól.
Az OSPF támogatja a kétpontos adatkapcsolatokat (például SONET), valamint az adatszóró hálózatokat (például a legtöbb LAN). Ezenkívül még abban az esetben is támogatja az olyan, több útválasztóval megvalósított hálózatokat, amelyek közül mindegyik közvetlenül kommunikál a többivel (többszörös hozzáférésű hálózatok – multiaccess networks), ha azok nem rendelkeznek adatszóró képességgel. A korábbi protokollok nem kezelték jól ezt az esetet.
Az 5.64.(a) ábra egy AS-hálózatra mutat példát. A hosztok kimaradtak, mivel általában nem játszanak szerepet az OSPF-ben, csak az útválasztók és a hálózatok (amelyek tartalmazhatnak hosztokat). Az 5.64.(a) ábrán az útválasztók nagy része kétpontos adatkapcsolattal kapcsolódik egymáshoz, illetve a hálózathoz, a hálózaton lévő hosztok elérése érdekében. Az R3, R4 és R5 útválasztót azonban egy adatszóró LAN kapcsolja össze, mint amilyen például a kapcsolt Ethernet.
Az OSPF úgy működik, hogy a valódi hálózatok, útválasztók és vonalak összességét egy irányított gráfba képezi le, ahol minden élhez tartozik egy súly (távolság, késleltetés stb.). Két útválasztó közti kétpontos adatkapcsolatot egy élpár jelképez, mindkét irányban egy-egy éllel. Ezek súlyai különbözhetnek. Az adatszóró hálózatot egy csomópont jelképezi, és minden útválasztónak megfelel egy további csomópont. A hálózatnak megfelelő csomópontból az útválasztók felé vezető élek súlya 0. Ezek azonban fontosak, mivel nélkülük nincs a hálózaton átmenő útvonal. Más, csak hosztokat tartalmazó hálózatok csak odamenő éllel rendelkeznek, visszamenővel nem. A struktúra a hosztokhoz vezető utat adja meg, a rajtuk keresztülvezetőt nem.
Az 5.64.(b) ábra mutatja az 5.64.(a) ábra gráf-reprezentációját. Alapjában véve az OSPF azt csinálja, hogy a valódi hálózatot egy ilyen gráfba képezi le, majd a kapcsolatállapot-alapú módszer segítségével kiszámítja a legrövidebb utat minden útválasztótól a többi csomópontig. Elképzelhető több, egyformán rövid útvonal. Ebben az esetben az OSPF megjegyzi a legrövidebb útvonalakat, és a csomagtovábbítás során a forgalmat megosztja ezek között az útvonalak között. Ez segít a terhelés kiegyenlítésében. Ezt ECMP-nek (Equal Cost Multipath – több azonos költségű útvonal) hívják.
Az interneten sok AS önmagában is nagy, és nem magától értetődő a kezelésük. Az OSPF lehetővé teszi, hogy ezeket megszámozott területekre (area) osszuk fel, ahol egy terület egy hálózat vagy hálózatok összefüggő halmaza. A területek nem fedhetik át egymást, de nem kell kimerítőnek lenniük, vagyis elképzelhető, hogy néhány útválasztó egyik területhez sem tartozik. A teljes egészében egy adott területen belül elhelyezkedő útválasztót belső útválasztónak (internal router) nevezik. A terület az egyedülálló hálózat általánosítása. Egy területen kívülről a címzettek láthatók, de a topológia nem. Ez a jellemző segít az útválasztás skálázásában.
Minden AS-nek van egy gerinchálózati (backbone) területe, amit 0. területnek hívnak. A területen lévő útválasztókat gerinchálózati útválasztóknak (backbone router) hívják. Minden terület a gerinchálózathoz csatlakozik, esetleg alagutakon keresztül, így az AS bármely területéről bármelyik másik területére el lehet jutni a gerinchálózaton keresztül. Az alagutat a gráfban egy él és egy költség jelképezi. Mint az más területekre is igaz, a gerinchálózat topológiája sem látszik a gerinchálózaton kívülről.
A kettő vagy több területhez kapcsolódó útválasztót területhatár-útválasztónak (area border router) hívják. Ennek szintén a gerinchálózathoz kell tartoznia. A területhatár-útválasztó feladata az egy területen lévő címzettek összefogása és az összefogás továbbítása a többi terület felé. Ez tartalmazza a költséginformációt, de nem tartalmazza a terület topológiájának minden részletét. A költségadatok továbbításával a többi területen lévő hosztok meg tudják keresni az adott területre történő belépéshez használható legjobb területhatár-útválasztót. Azáltal, hogy topológiai adatok nem kerülnek átadásra, kisebb lesz a forgalom, és a többi terület útválasztói egyszerűbben ki tudják számítani a legrövidebb útvonalat. Ha azonban csak egyetlen területhatár-útválasztó van a területen kívül, akkor még az összefoglalást sem kell átadni. A területen kívüli címzettek útvonalai mindig ezzel kezdődnek „Menj a területhatár-útválasztóhoz”. Ezt a területtípust csonka területnek (stub area) hívják.
Az utolsó útválasztótípus az AS-határútválasztó (AS boundary router). Ez a más AS-en lévő külső címzettek útvonalát küldi a területre. A külső útvonalak ezután címzettként jelennek meg, amelyek az AS-határútválasztón keresztül érhetők el, valamilyen költséggel. Egy külső útvonal egy vagy több AS-határútválasztón keresztül léphet be. Az AS-ek, a területek és a különböző típusú útválasztók közötti kapcsolatot az 5.65. ábra mutatja. Egy útválasztó több szerepet is betölthet, például egy határútválasztó lehet gerinchálózati útválasztó is.
Rendes működés közben az egy területen lévő útválasztók azonos kapcsolatállapot-alapú adatbázissal rendelkeznek, és ugyanazt a legrövidebb útvonal algoritmust futtatják. Fő feladatuk a legrövidebb útvonal kiszámítása saját maga és a teljes AS-ben lévő többi útválasztó és hálózat között. A területhatár-útválasztónak az összes hozzá csatlakozó terület adatbázisára szüksége van, és mindegyik területre függetlenül kell lefuttatnia a legrövidebb útvonal algoritmust.
Ha a forrás és cél ugyanazon a területen található, a legjobb területen belüli útvonal (amely teljes egészében a területen belül vezet) kerül kiválasztásra. Különböző területen lévő forrás és cél esetén három részre bontható az útvonal: a forrástól a gerinchálózatig, a gerinchálózaton keresztül a célterületig, majd a célterületen belül a célig. Ez az algoritmus csillag alakú elrendezést kényszerít az OSPF-re, ahol a gerinchálózat a csillag közepe és a többi terület pedig a csillag ága. Mivel az algoritmus a legkisebb költségű útvonalat választja, a hálózatok különböző részeiben lévő útválasztók különböző területhatár útválasztókat használhatnak a gerinchálózatra, illetve a célterületre való belépéshez. A csomagokat úgy irányítjuk a forrástól a célig, „ahogy vannak”. Nem ágyazzuk be azokat, és nem visszük keresztül alagutakon, hacsak nem egy olyan területre mennek, amelyet a gerinchálózattal csak egy alagút köt össze. A külső célhoz vezető útvonalak szükség esetén tartalmazhatják a külső útvonalon lévő AS-határútválasztó külső költségét, vagy csak az AS belső költségét.
Amikor egy útválasztó elindul, HELLO üzeneteket küld minden kétpontos vonalán, és ezeket többesküldéssel elküldi a LAN-okon az összes többi útválasztóból álló csoportnak is. A válaszokból minden útválasztó megtudja, hogy kik a szomszédjai. Az ugyanazon a LAN-on lévő útválasztók mind szomszédok.
Az OSPF azáltal működik, hogy információt cserél a határos vagy összefüggő útválasztók között, amelyek nem ugyanazok, mint a szomszédos útválasztók. Nem hatékony ugyanis, hogy egy LAN-on minden útválasztó minden másikhoz beszéljen. Hogy ezt a szituációt elkerüljék, az egyik útválasztót megválasztják kijelölt útválasztónak (designated router). Ezt nevezik az összes többi útválasztóval határos útválasztónak (adjacent router) vagy összefüggőnek, és ez cserél velük információt. Ez az útválasztó lényegében egy olyan csomópont, amely a LAN-t képviseli. Az olyan szomszédos útválasztók, amelyek egymással nem függenek össze, egymás közt nem cserélnek információt. Mindig naprakészen tartanak egy tartalék kijelölt útválasztót is, hogy az átállást megkönnyítsék, amennyiben az elsődleges kijelölt útválasztó összeomolna, és azonnali cserére szorulna.
Rendes működés közben minden útválasztó periodikusan eláraszt KAPCSOLATÁLLAPOT FRISSÍTÉSE üzenetekkel minden vele összefüggő útválasztót. Ez az üzenet megadja annak állapotát, és biztosítja a topológiai adatbázisban használt költségeket. Az elárasztási üzeneteket nyugtázzák, hogy megbízhatók legyenek. Minden üzenetnek van egy sorszáma, így az útválasztók láthatják, hogy egy bejövő KAPCSOLATÁLLAPOT FRISSÍTÉSE régebbi vagy újabb annál, mint amelyik náluk van. Az útválasztók akkor is elküldik ezeket az üzeneteket, amikor egy vonal tönkremegy vagy megjavul, vagy megváltozik a költsége.
Az ADATBÁZIS LEÍRÁSA üzenetek megadják minden, a küldő által jelenleg birtokolt kapcsolatállapot-bejegyzés sorszámát. A vevő a saját értékeit az adóéval összehasonlítva eldöntheti, kinek van a legújabb értéke. Ezeket az üzeneteket egy vonal megjavításakor használják.
Bármely partner kérhet kapcsolatállapot-információt a másiktól a KAPCSOLATÁLLAPOT KÉRÉSE üzeneteket használva. Ennek az algoritmusnak a tovaterjedő hatása az, hogy minden összefüggő útválasztó pár ellenőrzi, hogy kinek vannak a legújabb adatai, és ily módon az új információ elterjed a területen belül. Mindezeket az üzeneteket nyers IP-csomagokként küldik el. Az öt üzenettípus összefoglalása látható az 5.66. ábrán.
Végre összerakhatjuk a darabokat. Az elárasztást használva minden útválasztó informálja a területén belüli összes többi útválasztót a hozzájuk menő saját adatkapcsolatairól és hálózatairól, valamint ezeknek az adatkapcsolatoknak a költségéről. Ez az információ lehetővé teszi mindegyik útválasztó számára, hogy összeállítsa a területe vagy területei gráfját, és kiszámítsa a legrövidebb utat. Ezt a gerinchálózati terület is elvégzi. Ezenkívül a gerinchálózati útválasztók a területhatár-útválasztóktól is elfogadnak információt, hogy kiszámolják a legjobb útvonalat minden gerinchálózati útválasztótól minden más útválasztóig. Ezt az információt visszafelé is elterjesztik a területhatár-útválasztókhoz, amelyek kihirdetik ezt a körzeteikben. Ezt az információt használva egy útválasztó, amely egy területek közti csomagot készül küldeni, kiválaszthatja a legjobb kijáratot a gerinchálózat felé.
Az egyetlen AS-en belül általánosan használt protokoll az OSPF és az IS-IS. Az AS-ek között egy másik protokollt, a BGP-t (Border Gateway Protocol – határátjáró protokoll) használják. Azért van másfajta protokollra szükség, mert a körzeten belüli protokoll és a körzetek közötti protokoll célja nem ugyanaz. A körzeten belüli protokollnak csak annyi a dolga, hogy a csomagokat a lehető leghatékonyabban mozgassa a forrás és a cél közt. Nem kell törődnie a politikával.
A körzetek közötti protokolloknak viszont sokat főhet a fejük a politika miatt [Metz, 2001]. Például egy vállalati AS-nek szüksége lehet arra a képességre, hogy csomagokat tudjon küldeni az internet tetszőleges helyére, illetve csomagokat tudjon fogadni az internet tetszőleges helyéről. Viszont nem biztos, hogy hajlandó egy idegen AS-ben keletkezett és egy másik idegen AS-be tartó csomagot szállítani, még ha a saját AS a legrövidebb úton is lenne a két idegen AS közt. („Ez az ő problémájuk, nem a mienk.”) Másfelől viszont hajlandó lehet átmenő forgalmat továbbítani a szomszédainak vagy esetleg más olyan AS-eknek is, amelyek fizettek ezért a szolgáltatásért. A telefontársaságok például boldogan működnének szolgáltatóként az ügyfeleik számára, de mások számára nem. Általában a külső átjáró protokollokat, így a BGP-t is úgy tervezték, hogy lehetővé tegyenek sokfajta útválasztó politikát, amelyeket az AS-ek közötti forgalom kényszerít ki.
A tipikus politikák világpolitikai, biztonsági vagy gazdasági megfontolásokat foglalhatnak magukban. Egy pár példa az útválasztás lehetséges korlátozására az USA-ban:
Ne menjen át kereskedelmi forgalom az oktatási hálózaton.
Sose küldjük a Pentagontól jövő forgalmat Irakon keresztül menő útvonalon.
Használjuk a TeliaSonert a Verizon helyett, mert az olcsóbb.
Ne használjuk az AT&T-t Ausztráliában, mivel rossz a teljesítőképessége.
Az Apple-nél kezdődő vagy végződő forgalom ne menjen át a Google-on.
Ahogy a listából látható, az útválasztási politikák meglehetősen egyediek lehetnek. Ezek gyakran védettek, mivel érzékeny üzleti adatokat tartalmaznak. Lehet azonban olyan mintákat találni, amelyek a fenti vállalat érvelését tükrözik, és amelyeket gyakran használnak kiindulási pontként.
Az útválasztási politika megvalósítása úgy történik, hogy a rendszer eldönti, hogy melyik forgalom melyik AS-ek közötti vonalon menjen át. Egy általános politika, hogy az ügyfél ISP-je fizet a másik ISP-nek, hogy eljuttassa a csomagokat tetszőleges más célhoz az interneten keresztül, illetve hogy a más cél által küldött csomagokat fogadja. Az ügyfél ISP átmenő szolgáltatást (transit service) vásárol a szolgáltató ISP-től. Ez éppen olyan, mint amikor az otthoni ügyfél internet-hozzáférést vásárol egy internetszolgáltatótól. Ahhoz, hogy ez működjön, a szolgáltató ISP-nek hirdetnie kell az interneten lévő célok útvonalát az ügyfél felé az őket összekapcsoló útvonalakon. Ily módon az ügyfél tetszőleges célhely csomagküldési útvonalának birtokában lesz. Viszont az ügyfélnek csak a saját hálózatán lévő célok útvonalait kell a szolgáltató ISP felé hirdetnie. Ezáltal a szolgáltató ISP csak az e címekre irányuló forgalmat küldi el az ügyfélnek. Az ügyfél nem akarja kezelni a többi célhoz küldött forgalmat.
Az átmenő szolgáltatásra az 5.67. ábra mutat példát. Itt négy AS van összekötve. Az összeköttetés gyakran IXP-n (Internet eXchange Point – internetkapcsolódási pont) lévő adatkapcsolaton történik. Ez olyan eszköz, amelyhez számos ISP rendelkezik adatkapcsolattal más ISP-hez való kapcsolódás céljából. Az AS2, AS3 és AS4 az AS1 ügyfelei, és átmenő szolgáltatást vásárolnak az AS1-től. Amikor az A forrás a C felé küld, akkor a csomagok az AS2-től az AS1-re, majd végül az AS4-re mennek. Az útválasztási hirdetések a csomagokkal ellenkező irányba haladnak. Az AS4 a C-t célként hirdeti az átmenő szolgáltatójához, az AS1 felé, hogy a források a C-t elérhessék az AS1-en keresztül. Ezután az AS1 hirdeti a C-hez vezető útvonalat a többi ügyfelének, az AS2-t is beleértve, hogy tudják, hogy a C-nek menő forgalmat az AS1-en keresztül küldhetik.
Az 5.67. ábrán az összes többi AS átmenő szolgáltatást vesz az AS1-től. Ez kapcsolódást biztosít számukra, így az internet tetszőleges hosztjával kapcsolatba léphetnek. Ezért a privilégiumért azonban fizetniük kell. Tételezzük fel, hogy az AS2 és AS3 nagy forgalmat bonyolít le egymással. Feltéve, hogy a két hálózat már csatlakoztatva van, más politikát is használhatnak, ha akarnak – ingyen küldhetik a forgalmat egymásnak. Ez csökkenti annak a forgalomnak a mennyiségét, amelyet az AS1-nek kell helyettük kézbesítenie, ezáltal remélhetőleg a számla összege is csökken. Ezt a politikát hívjuk fizetség nélküli szolgáltatásnak (peering).
A fizetség nélküli szolgáltatás megvalósításához a két AS útválasztási hirdetést küld egymásnak a hálózatukon lévő címekről. Ezáltal az AS2 az AS3-nak csomagokat tud küldeni A-ból B-be, és fordítva. A fizetség nélküli szolgáltatás azonban nem tranzitív. Az 5.67. ábrán az AS3 és AS4 szintén egymás partnere a fizetség nélküli szolgáltatásban. Ez a fizetség nélküli szolgáltatás lehetővé teszi, hogy a C-ből B-be irányuló csomagokat közvetlenül az AS4-nek lehessen küldeni. Mi történik, ha C küld csomagot az A-nak? Az AS3 csak egy B-hez menő útvonalat hirdet AS4 felé, A felé menő útvonalát nem hirdeti. Ennek következtében nem kerül át az AS4-től az AS3-hoz menő forgalom az AS2-höz, annak ellenére, hogy fizikai útvonal létezik közöttük. Ez a korlátozás pontosan az, amit az AS3 akar. Partnerei az AS4-nek a forgalom cseréjében, de az AS4-től jövő forgalmat az internet többi részére nem kívánja átvinni, mivel az nem fizet ezért. Ehelyett az AS4 átmenő szolgáltatást kap az AS1-től, és az AS1 fogja elszállítani a csomagokat a C-ből az A-ba.
Most, az átmenő szolgáltatás és a fizetség nélküli szolgáltatás ismeretében, azt is láthatjuk, hogy az A, B és C rendelkezik átmenő szolgáltatási megegyezéssel. Például az A-nak internet-hozzáférést kell vennie az AS2-től. Az A lehet egyetlen otthoni számítógép, vagy több LAN-ból álló vállalati hálózat. Nincs azonban szüksége BGP-re, mivel ez egy csonka hálózat (stub network), amely az internet többi részéhez egyetlen adatkapcsolattal csatlakozik. Így a hálózaton kívülre címzett csomagokat csak az AS2 adatkapcsolatán küldheti. Másfelé nem tud küldeni. Ez az útvonal egyszerűen kialakítható egy alapértelmezett útvonal beállításával. Emiatt nem látjuk az A-t, B-t és C-t a körzetek közötti útválasztásban résztvevő AS-ként.
Más részről néhány vállalati hálózat több internetszolgáltatóhoz is kapcsolódik. Ez a technika javítja a megbízhatóságot, mivel ha az egyik ISP-n keresztülmenő útvonal megszakad, akkor a vállalat használhatja a másik ISP-n át vezető útvonalat. Ezt a technikát többplatformúságnak (multihoming) nevezik. Ebben az esetben a vállalati hálózat valószínűleg körzetek közötti útválasztó protokollt futtat (például a BGP-t), hogy megmondja a többi AS-nek, hogy melyik címet melyik ISP adatkapcsolatán keresztül kell elérni.
Ennek az átmenő fizetség nélküli szolgáltatási politikáknak számos változata lehetséges, de ezek már szemléltették, hogy az üzleti kapcsolatok és az útvonalhirdetések helyének szabályozása hogyan valósíthat meg különböző politikákat. Ezután részletesebben megnézzük, hogy a BGP-t futtató útválasztók hogyan hirdetik útvonalaikat egymásnak, és hogyan választják ki az útvonalat a csomagok továbbításához.
A BGP alapvetően távolságvektor-alapú protokoll, de meglehetősen eltér a legtöbb körzeten belüli távolságvektor-alapú protokolltól, mint amilyen például az RIP. Már láthattuk, hogy ezt a politikát a minimális távolság meghatározása helyett arra használják, hogy a használt útvonalakat feljegyezze. Másik nagy különbség az, hogy az egyes célokhoz menő útvonalak költségének karbantartása helyett minden BGP-útválasztó pontosan nyomon követi a használt útvonalat. Ez az útvonalvektor protokoll (path vector protocol). Az útvonal a következőket tartalmazza: a következő ugrás útválasztója (ami lehet az ISP másik oldalán, nem a szomszédos oldalon), és az AS-ek sorozata vagy AS-útvonal, amelyet az út követ (fordított sorrendben megadva). És végül, a BGP-útválasztók páronként TCP-összeköttetést létrehozva kommunikálnak egymással. Az ilyen működés megbízható kommunikációt biztosít és annak a hálózatnak az összes részletét is elrejti, amelyiken áthalad.
Az 5.68. ábra bemutatja a BGP-útvonalak hirdetésének módját. Három AS van, a középső átmenő forgalmat biztosít a bal és jobb oldali ISP számára. A C előtag felé menő útvonalhirdetés az AS3-mal kezdődik. Amikor ezt az ábra tetején lévő R2c adatkapcsolaton keresztül terjesztik, akkor az AS útvonala egyszerűen az AS3 és a következő ugrásútválasztó, az R3a. Az alsó részen ugyanaz az AS-útvonal, de a következő ugrás különbözik, mivel másik adatkapcsolaton halad keresztül. A hirdetés terjesztése folytatódik és átmegy az AS1 határán. Az R1a útválasztónál, az ábra felső részén, az AS-útvonal az AS2, AS3, és a következő ugrás az R2a.
Ha az út tartalmazza a teljes útvonalat, a fogadó útválasztó egyszerűen észlelni tudja, és fel tudja törni a hurkokat. A szabály az, hogy minden útválasztó, amely az AS-en kívülre küld, az útvonal elé fűzi a saját AS-számát. (Ezért van a lista fordított sorrendben). Amikor az útválasztó megkap egy útvonalat, megnézi, hogy a saját AS-száma szerepel-e már az AS-útvonalon. Ha igen, akkor hurkot észlelt és a hirdetést eldobja. Csak az 1990-es évek végén vették észre azonban, hogy mindezen elővigyázatosság ellenére a BGP a végtelenig számolás problémájától szenved [Labovitz és mások, 2001]. Nincsenek sokáig fennálló hurkok, de az útvonalakon lehetnek átmeneti hurkok, illetve lassú lehet a konvergencia.
Elég kezdetleges módszer az útvonal megadása az AS-ek listájával. Egy AS lehet egy kisvállalat vagy egy nemzetközi gerinchálózat. Ez az útból nem derül ki. A BGP meg sem próbálja kideríteni, mivel a különböző AS-ek különböző körzeten belüli protokollt használhatnak, amelyek költsége nem hasonlítható össze. Még ha össze is tudná ezeket hasonlítani, elképzelhető, hogy néhány AS nem akarja elárulni a belső mértékeit. Ez az egyik különbség a körzetek közötti és a körzeten belüli protokollok között.
Eddig láthattuk, hogy az útvonalhirdetés hogyan megy keresztül két ISP közötti adatkapcsolaton. A BGP-útvonalakat azonban valahogy terjeszteni kell az ISP két oldala között, hogy elküldhetők legyenek a következő ISP-nek. Ezt a feladatot kezelheti a körzeten belüli protokoll, de mivel a BGP nagyon jól méretezhető nagy hálózatokhoz, gyakran használják a BGP egy változatát erre a funkcióra. Ennek a neve iBGP (internal BGP – belső BGP), hogy meg lehessen különböztetni a normál BGP-től, az eBGP-től (external BGP – külső BGP).
Az útvonalak ISP-n belüli terjesztésének szabálya szerint az ISP határán lévő minden útválasztó megtanulja az összes többi határútválasztó által látott útvonalat a konzisztencia érdekében. Ha az ISP egyik határútválasztója megtanulja a 128.208.0.0/16 előtagot, akkor az összes többi útválasztó is megtanulja azt. Az előtag ezután az ISP összes részéről elérhető, függetlenül attól, hogy a csomagok hogyan lépnek be az ISP-be más AS-ekből.
Ezt a terjesztést nem mutattuk be az 5.68. ábrán a zűrzavar elkerülése érdekében, de például az R2b útválasztó tudni fogja, hogy a C-t felül az R2c útválasztón keresztül, alul pedig az R2d útválasztón keresztül tudja elérni. A következő ugrás frissítésre kerül, amint az útválasztó keresztülmegy az ISP-n, így az ISP távoli oldalán lévő útválasztók tudni fogják, hogy melyik útválasztót kell használni az ISP-ből való kilépéshez a másik oldalon. Ez a legbaloldalibb útvonalakon látható, amelyben a következő ugrás ugyanazon az ISP-n belüli útválasztóra mutat, és nem a következő ISP-ben lévő útválasztóra.
Ezután leírhatjuk a hiányzó kulcsrészletet, amely azt mutatja meg, hogy az BGP-útválasztók hogyan választják ki az egyes célokhoz használandó útvonalat. Minden BGP-útválasztó megtanulhatja egy adott cél útvonalát attól az útválasztótól, amelyhez a következő ISP-nél csatlakozik, illetve az összes többi határ útválasztótól (amelyek különböző útvonalat hallottak az útválasztóktól, amelyekhez a többi ISP-nél csatlakoznak). Minden útválasztónak el kell döntenie, hogy az útvonalhalmaz melyik útvonalát érdemes használnia. A végső válasz az, hogy az ISP dolga a preferált útvonal kiválasztásához valamilyen politika kidolgozása. Ez a magyarázat azonban nagyon általános és egyáltalán nem kielégítő, így azért legalább néhány stratégiát leírunk.
Az első stratégia, hogy a fizetség nélküli szolgáltatást (peering) nyújtó hálózatokon keresztülhaladó útvonalaknak precedenciája van az átmenő szolgáltatást nyújtó (transit) hálózatokon keresztülmenő útvonalakkal szemben. Az előbbi útvonalak ingyenesek, az utóbbiakért pedig fizetni kell. Hasonló stratégia, hogy az ügyfélútvonalak kapják a legnagyobb preferenciát. Ez az egyetlen jó megoldás arra, hogy a forgalmat közvetlenül a fizető ügyfeleknek továbbítsák.
Egy másik stratégia esetén az alapértelmezett szabály az, hogy a rövidebb AS jobb. Ez azonban vitatható, mivel az AS tetszőleges méretű hálózat lehet, így elképzelhető, hogy három kis AS-en keresztülmenő útvonal rövidebb, mint az egy nagy AS-en keresztülmenő útvonal. Normális esetben azonban a rövidebb a jobb, és általánosan ez a szabály a döntő érvényű.
Az utolsó stratégia az ISP-n belüli legkisebb költségű útvonal kiválasztása. Ez az 5.68. ábrán ábrázolt stratégia. Az A-ból a C-be küldött csomagok az AS1-ből a felső, R1a útválasztón keresztül lépnek ki. A B-ből küldött csomagok az alsó R1b útválasztón keresztül lépnek ki. Ennek oka, hogy az A és B egyaránt a legkisebb költségű útvonalat, vagy az AS1-ből kivezető leggyorsabb útvonalat választja. Mivel ezek az ISP különböző részein találhatók, a két csomópont leggyorsabb kilépési pontja különbözik. Ugyanez történik az AS2-n keresztülhaladó csomagok esetén. Utolsó lépésként az AS3-nak a B-ből jövő csomagokat a saját hálózatán kell keresztülvinnie.
Ezt a stratégiát korai kilépésnek (early exit) vagy forró krumpli útválasztásnak (hot-potato routing) hívják. Ennek különös mellékhatása, hogy az útvonalakat aszimmetrikussá teszi. Vegyük például azt az útvonalat, amelyet a C-ből B-be visszaküldött csomag megtesz. A csomag gyorsan kilép az AS3-ból a felső útválasztón, az erőforrások pazarlásának elkerülése érdekében. Ehhez hasonlóan a felső részen marad, amikor a lehető leggyorsabban átmegy az AS2-n az AS1 felé, majd a csomag hosszabb utat tesz meg az AS1-ben. Ez a B-ből C-be küldött csomag útvonalának tükörképe.
A fenti leírásból ki kell tűnnie, hogy minden BGP-útválasztó az ismert lehetőségek közül választja ki a saját legjobb útvonalát. Nem az a helyzet, mint amit naivan feltételeznénk, hogy a BGP a követendő útvonalat AS-szinten választja, az OSPF pedig az egyes AS-eken belül választ. A BGP és a belső átjáró protokoll mélyebben integrált. Ez azt jelenti, hogy például a BGP meg tudja találni a legjobb kilépési pontot az egyik ISP-től a következőig, és ez a pont az ISP-ken át változik, mint ahogy a forró krumpli politika esetén is. Ez azt is jelenti, hogy egy AS különböző részein lévő BGP-útválasztók különböző AS-útvonalakat választhatnak ugyanazon cél eléréséhez. Az ISP-nek körültekintően kell eljárnia a BGP-útválasztók beállításánál, hogy kompatibilis útvonalakat válasszanak ezen szabadság megtartása mellett, de ez megoldható a gyakorlatban.
Ezzel azonban még csak a BGP felszínét érintettük. További információt a BGP 4-es verziójával kapcsolatban az RFC 4271 és a kapcsolódó RFC-k tartalmaznak. Az összetettség azonban nagyban a politikából adódik, amit a BGP-protokoll specifikációja nem tartalmaz.
A rendes IP-kommunikáció egy adó és egy vevő közt zajlik. Néhány alkalmazás esetében azonban hasznos, ha egy folyamat képes nagyszámú vevőnek egyszerre küldeni. Ilyen például az élő sportesemény közvetítése sok nézőnek, programfrissítések küldése tükrözött (replicated) kiszolgálókra, illetve digitális konferenciahívások (vagyis többrésztvevős hívások) kezelése.
Az IP támogatja az egy-több típusú kommunikációt, illetve a többesküldést, D osztályú címek használatával. Minden D osztályú cím egy hosztcsoportot azonosít. Huszonnyolc bit használható a csoportok azonosítására, így egy időben több mint 250 millió csoport lehet jelen. Amikor egy folyamat egy D osztályú címre küld egy csomagot, best-effort típusú kísérlet történik arra, hogy a megcímzett csoport minden tagjának kézbesítsék a csomagot, de erre semmi garancia nincs. Előfordulhat, hogy egyes tagok esetleg nem kapják meg a csomagot.
A 224.0.0.0/24 IP-címtartomány többesküldésre van fenntartva a helyi hálózaton. Ebben az esetben nincs szükség útválasztó protokollra. A csomagok többesküldése a LAN-on egyszerű adatszórással megoldható többesküldéses cím használatával. A LAN-on lévő összes hoszt megkapja az adatszórás üzenetet, és a csoporthoz tartozó hosztok feldolgozzák a csomagot. Az útválasztók nem továbbítják a csomagot a LAN-on kívülre. Néhány példa a helyi többesküldéses címre:
|
224.0.0.1 |
Az egy LAN-on levő összes rendszer. |
|
224.0.0.2 |
Az egy LAN-on levő összes útválasztó. |
|
224.0.0.5 |
Az egy LAN-on levő összes OSPF-útválasztó. |
|
224.0.0.251 |
Az egy LAN-on levő összes DNS-kiszolgáló. |
A többi többesküldéses címhez tartozhatnak más hálózatokon lévő tagok. Ebben az esetben útválasztó protokollra van szükség. Először is a többesküldéses útválasztónak tudnia kell, hogy mely hosztok a csoport tagjai. A folyamat megkérheti a hosztját, hogy csatlakozzon egy bizonyos csoporthoz. Arra is megkérheti a hosztját, hogy lépjen ki a csoportból. Minden hoszt nyilvántartja, hogy a folyamatai jelenleg melyik csoportokhoz tartoznak. Amikor egy hoszt utolsó folyamata is elhagyja a csoportot, akkor a továbbiakban nem lesz a csoport tagja. Körülbelül percenként egyszer minden többesküldéses útválasztó lekérdező csomagot küld a LAN-on lévő hosztokhoz (a 224.0.0.1 helyi többesküldéses cím használatával), megkérve azokat, hogy jelentsék, milyen csoportokhoz tartoznak jelenleg. A többesküldéses útválasztók lehetnek egy helyen a normál útválasztókkal, illetve lehetnek különböző helyen is. Minden hoszt az összes olyan D osztályú címre válaszol, amelyben érdekelt. Ezek a lekérdező és válaszcsomagok az IGMP (Internet Group Management Protocol – internetes csoportkezelő protokoll) nevű protokollt használják. Ezt a protokollt az RFC 3376 írja le.
Számos többesküldéses útválasztó protokoll többesküldési feszítőfát állít elő, amely megadja a küldő és a csoporttagok közötti útvonalat. A használt algoritmusokat az 5.2.8. szakaszban tárgyaljuk. Egy AS-en belül az elsődlegesen használt protokoll a PIM (Protocol Independent Multicast – protokollfüggetlen többesküldés). A PIM-et számos formában használják. Sűrű módú PIM (Dense Mode PIM) esetén csonkolt visszairányú továbbítási fa jön létre. Ez olyan helyzetekben megfelelő, ahol a tagok a hálózatban elszórtan találhatók, mint például fájlok kézbesítése egy adatközponti hálózatban lévő kiszolgálók felé. Ritka módú PIM (Sparse Mode PIM) esetén a létrehozott feszítőfák hasonlóak a magalapú fákhoz. Ez olyan szituációkban alkalmas, amelyben például a tartalomszolgáltató tv-adást küld szét az IP-hálózat előfizetői számára. Ennek egyik változata a forrásspecifikus többesküldéses PIM, amelyet arra az esetre optimalizáltak, amelyben csak egy küldő küld a csoport felé. Végül a BGP többesküldéses kiterjesztései vagy alagutak használhatók többesküldéses útvonal létrehozásához, amikor a csoporttagok különböző AS-ekben találhatók.
Az internet sok felhasználójának van hordozható számítógépe, és akkor is internetkapcsolatra van szükségük, amikor távol vannak az otthonuktól, illetve még az utazás közben is. Sajnos az IP címzési rendszere miatt az otthontól távoli munkavégzést könnyebb mondani, mint megteremteni annak lehetőségét, ahogy ezt hamarosan látni fogjuk. Amikor tömeges igény mutatkozott eziránt, az IETF felállított egy munkacsoportot, hogy kidolgozza a megoldást. A munkacsoport gyorsan kialakított számos olyan alapelvet, amelyet minden megoldástól elvártak. Ezek a következők voltak:
Minden mozgó hoszt legyen képes bárhol az otthoni IP-címét használni.
A rögzített hosztokban ne kelljen szoftverváltoztatásokat végrehajtani.
Az útválasztószoftverben és táblázatokban ne kelljen változtatásokat végrehajtani.
A mozgó hosztokhoz menő csomagok döntő többségének ne kelljen kitérőket tenni.
Ne okozzon többletmunkát az, amikor a mozgó hoszt otthon tartózkodik.
A választott megoldás az, amit az 5.2.10. szakaszban leírtunk. Hogy röviden összefoglaljuk, minden helynek, amelyik lehetővé kívánja tenni a felhasználói számára a barangolást, egy otthoni ügynököt (home agent) kell létrehoznia. Amikor egy mozgó hoszt megjelenik egy idegen helyen, új IP-címet kér (ezt c/o címnek vagy továbbítási címnek (care-of address) nevezzük). A mozgó hoszt a továbbítási cím használatával megmondja az otthoni ügynöknek, hogy hol van. Amikor a mozgó hoszt csomagja megérkezik az otthoni helyre, és a mozgó hoszt máshol található, akkor az otthoni ügynök megfogja a csomagot, és alagúton keresztül elküldi azt az aktuális továbbítási címen lévő mobil hoszthoz. A mozgó hoszt a csomagokat közvetlenül vissza tudja küldeni a kommunikációs partnernek, de továbbra is az otthoni címet használja forráscímként. Ez a megoldás megfelel az összes fenti követelménynek, azzal a kivétellel, hogy a mozgó hoszt felé küldött csomagok kerülő úton mennek.
Most, hogy lefedtük az internet hálózati rétegét, belemélyedhetünk további részletekbe. A mobilitás támogatása iránti igény elsősorban magából az IP-címzési sémából fakad. Minden IP-cím tartalmaz egy hálózatszámot és egy hosztszámot. Vegyük például a 160.80.40.20/16 címen található gépet. A 160.80 a hálózatszámot, a 40.20 pedig a hosztszámot adja meg. A világ bármely helyén lévő útválasztó rendelkezik útválasztó táblázattal, amely megmondja, hogy melyik vonalon keresztül lehet eljutni a 160.80 hálózathoz. Amikor beérkezik egy csomag, amelyben a címzett IP-címe 160.80.xxx.yyy formátumú, akkor az ezen a vonalon megy ki. Ha hirtelen az adott című gép egy távoli helyre kerül, a csomagjai továbbra is az otthoni LAN-ra (vagy útválasztóra) kerülnek továbbításra.
Ezen a ponton két lehetőség áll rendelkezésre – de egyik sem túl vonzó. Az első, hogy létre tudunk hozni egy útvonalat specifikusabb előtaggal. Ha a távoli hely hirdeti a 160.80.40.20/32 felé menő útvonalat, akkor a cél felé küldött csomagok újból a megfelelő helyre kezdenek érkezni. Ez a lehetőség az útválasztókon használt leghosszabb egyező előtag algoritmustól függ. Hozzáadtunk azonban egy útvonalat az IP-előtaghoz, amely egyetlen IP-címet tartalmaz. Az összes ISP meg fogja tanulni ezt az előtagot. Ha a számítógép áthelyezésekor mindenki ily módon változtatja a globális IP-útvonalakat, akkor minden útválasztó több millió táblázatbejegyzést fog tartalmazni, amely horribilis összegbe kerül. Ez tehát nem működőképes.
A második lehetőség a mobil hoszt IP-címének módosítása. Igaz, hogy az otthoni IP-címre küldött csomagok nem kézbesíthetők addig, amíg az összes érintett ember, program és adatbázis nem értesül a változásról. De a mozgó hoszt az új helyen továbbra is használni tudja az internetet webböngészéshez és más alkalmazások futtatásához. Ez a megoldás magasabb szinten kezeli a mobilitást. Általában ez történik, amikor egy felhasználó beviszi a hordozható számítógépét egy kávézóba és az internetet a helyi vezeték nélküli hálózaton keresztül használja. Ennek hátránya, hogy néhány alkalmazás megszakítja a működését, és nem tartja fenn a kapcsolatot a mozgó hoszt helyváltoztatása közben.
A mobilitás azonban alacsonyabb rétegben, az adatkapcsolati rétegben is kezelhető. Ez történik, amikor a hordozható számítógépet 802.11 vezeték nélküli hálózaton használják. A mozgó hoszt IP-címe nem változik, és a hálózati útvonal is változatlan marad. A vezeték nélküli kapcsolat biztosítja a mobilitást. A mobilitás mértéke azonban korlátozott. Ha a számítógépet túl messzire viszik, akkor másik hálózaton keresztül kell csatlakozni az internetre, másik IP-címmel.
Az IPv4 mobil IP-megoldását az RFC 3344 rögzíti. Ez a meglévő internetes útválasztást használja, és lehetővé teszi, hogy helyváltoztatás közben is megmaradjon a hoszt kapcsolata a saját IP-címével. Ahhoz, hogy ez működjön, a mozgó hosztot fel kell tudni térképezni mozgás közben. Ez ICMP-útválasztó hirdetéssel és kérelmező üzenettel történik. A mozgó hosztok figyelik a rendszeres időközönként küldött útválasztó hirdetéseket, vagy kérelmet küldenek a legközelebbi útválasztó feltérképezése érdekében. Ha ez az útválasztó nem a mobil hoszt otthoni tartózkodáskor használt szokásos útválasztója, akkor ennek a hosztnak idegen hálózaton kell lennie. Ha ez az útválasztó változott az utolsó alkalom óta, akkor a mozgó hoszt másik idegen hálózatba lépett. Ugyanez a mechanizmus teszi lehetővé a mozgó hosztok számára a saját otthoni ügynökük megkeresését.
Ahhoz, hogy a mozgó hoszt az idegen hálózaton hozzájusson a továbbítási (c/o) IP-címhez, egyszerűen használhatja a DHCP-t, vagyis a dinamikus hosztkonfigurációs protokollt. Vagy ha kevés az IPv4-cím, akkor a mozgó hoszt tud csomagokat küldeni és fogadni egy idegen ügynökön keresztül, amely már rendelkezik IP-címmel a hálózaton. A mozgó hoszt az idegen ügynököt ugyanazon ICMP-mechanizmussal keresi meg, mint az otthoni ügynököt. Miután egy mozgó hoszt IP-címet kap, vagy idegen ügynököt talál, használni tudja a hálózatot az otthoni ügynöknek szóló üzenet küldésére, informálva az otthoni ügynököt az aktuális helyéről.
Az otthoni ügynöknek csak akkor kell tudnia fogadni a mozgó hosztnak küldött csomagokat, amikor a mozgó hoszt nincs otthon. Az ARP megfelelő módszert biztosít erre. Ha egy csomagot Etherneten keresztül kíván küldeni az IP-hoszt felé, akkor az útválasztónak tudnia kell a hoszt Ethernet-címét. Az útválasztó által alkalmazott szokványos mechanizmus, hogy ARP-lekérdezést küld például annak kiderítéséhez, hogy mi a 160.80.40.20 Ethernet-címe. Ha a mozgó hoszt otthon van, akkor az IP-címére vonatkozó ARP-lekérdezésre a saját Ethernet-címével válaszol. Ha a mozgó hoszt nincs otthon, akkor az otthoni ügynök válaszol a lekérdezésre az Ethernet-cím megadásával. Az útválasztó ezután a csomagjait a 160.80.40.20 címen az otthoni ügynökhöz küldi. Ezt proxy ARP-nek nevezzük.
Az ARP-leképezések gyors frissítéséhez, amikor a mozgó hoszt elmegy otthonról, illetve hazatér, egy másik ARP-technika használható, amelyet önkényes ARP-nek (gratuitous ARP) neveznek. Ennek lényege az, hogy a mobil hoszt vagy az otthoni ügynök maga küld ARP-lekérdezést a mobil IP-címre vonatkozóan, amelyre a megfelelő válasz jön, úgy hogy az útválasztó ezt észleli, és a leképezését frissíti.
Ha alagúttechnikával küldünk csomagot az otthoni ügynök és a c/o továbbítási címen lévő mozgó hoszt között, akkor a csomag beágyazódik a c/o címre küldött másik IP-fejrésszel. Ha a beágyazott csomag megérkezik a c/o címre, akkor a külső IP-fejrész eltávolításra kerül és a csomag kibontható.
Ahogy számos internetprotokoll esetén, itt is a részletekben rejlik a buktató, leggyakrabban a többi bevezetett protokollokkal való kompatibilitás részleteiben. Két bonyodalom is van. Először is a NAT-dobozok megkeresik az IP-fejrészben a TCP- vagy UDP-fejrészt. A mobil IP-re alkalmazott alagút típusú átvitel eredeti formája nem használja ezeket a fejrészeket, így ez nem működik a NAT-dobozokkal. A megoldás az, hogy megváltoztatjuk a beágyazást, hogy tartalmazzon egy UDP-fejrészt.
A második bonyodalom, hogy néhány ISP megvizsgálja a csomagok forrás IP-címét, hogy ellenőrizze, vajon a forráshoszt helye egyezik-e azzal a hellyel, mint ahol annak az útválasztó protokoll szerint lenni kellene. Ezt a technikát beléptető szűrésnek (ingress filtering) nevezik. Ez egy biztonsági intézkedés annak érdekében, hogy kiszűrjék és eldobják a látszólag helytelen című csomagokat, amelyek esetleg ártalmasak lehetnek. Az idegen hálózaton lévő mozgó hoszt által egy másik, interneten lévő hosztnak küldött csomagoknak a forrás IP-címe azonban az útválasztó szerint helytelen lesz, ezért ezeket a csomagokat az útválasztó el fogja dobni.
További kérdés, amit még nem vitattunk meg, a biztonság kérdése. Amikor egy otthoni ügynök üzenetet kap, hogy továbbítsa Roberta csomagját a megadott IP-címre, akkor jobb, ha ezt nem teszi meg, hacsak Roberta meg nem győzi arról, hogy ő a kérés forrása, és nem próbálja meg valaki kéretlenül helyette. Erre a célra kriptográfiai hitelesítési protokollokat használnak. Ezeket a protokollokat a 8. fejezetben tanulmányozzuk.
Az IPv6 mobilitási protokolljai az IPv4-alapra épülnek. A fenti séma a háromszögeléses útválasztás problémájától szenved, amelyben a mozgó hosztnak küldött csomagok kerülő utat tesznek a távoli otthoni ügynökön keresztül. Az IPv6-ban az útvonal-optimalizálás közvetlen útvonalat követ a mobil és a többi IP-cím között, miután a kezdeti csomagok a hosszú útvonalat követték. A mobil IPv6 definícióját az RFC 3775 tartalmazza.
Létezik másfajta mobilitás is, amelyet az internethez definiáltak. Néhány repülőgép beépített vezeték nélküli hálózattal rendelkezik, amelyet az utasok is használhatnak számítógépeik internetre csatlakoztatásához. A repülőnek van egy útválasztója, amely az internet többi részéhez vezeték nélküli összeköttetésen keresztül csatlakozik. (Vezetékes vonalat várt?) Így van egy repülő útválasztónk, amely azt jelenti, hogy a teljes hálózat mozog. A hálózat mobilitási kialakításai ezt a helyzetet anélkül támogatják, hogy a laptopok észlelnék, hogy a repülőgép mozog. Csupán azt látják, hogy ez egy másik hálózat. Természetesen néhány laptop mobil IP-t használ az otthoni cím megtartásához, miközben a repülőn van, így az alkalmazott mobilitás kétszintű. Az IPv6 hálózati mobilitását az RFC 3963 adja meg.