Mobil Internet 1 2. előadás Adminisztratív információk és IPv4 alapok Jeney Gábor jeneyg@hit.bme.hu BME Híradástechnikai Tanszék 2007/2008 II. félév
Kivonat Motivációk Adminisztratív tudnivalók Félév felépítése (előadások és laborgyakorlatok) Félév elismerésének (aláírás) feltételei Év végi osztályzat komponensei Internet Protokoll alapok Címzés ésútvonalválasztás Verziók és az IPv4 részletesen 2007.12.20 Mobil Internet előadás 2
Bemutatkozás Dr. Jeney Gábor (tárgyfelelős) Személyesen csütörtök pénteken biztosan I.E.450. Tel: 2418 Egyébként e-mail jeneyg@hit.bme.hu Az órák többségén jelen leszek (pénteken biztos) 2007.12.20 Mobil Internet előadás 3
Motivációk Ezt a MÉRNÖKI tárgyat ezért hoztuk létre: 2007.12.20 Szeretnénk ismereteinket továbbadni Gyakorlatias, használható ismereteket tartalmaz Miről szól ez a tárgy Technológiai szempontból hogyan kezelhető a mobilitás, ha Internetre kapcsolódunk Miről nem szól ez a tárgy Filozofikus gondolatok a mobil Internetről M-commerce, mobil alkalmazások Számlázás, azonosítás, jogosultságok kezelése Mobil Internet előadás 4
Hol hasznosíthatóak az itt tanultak? Felhasználói oldal Folytonos (szakadásmentes) Internet kapcsolat biztosítása mobil környezetben Egyáltalán Internetkapcsolat mobil módon Szolgáltatói (ISP) / Vállalkozói oldal A mobilitás támogatáshoz szükséges infrastruktúra megismerése, feltérképezése Lehetőségek és korlátok tisztázása 2007.12.20 Mobil Internet előadás 5
Adminisztratív tudnivalók 3+1-es tárgy: heti 3 előadás (elmélet) és 1 laborgyakorlat (a tanultak tesztelése élőben) minden előadás 90 perces vagy kimarad kéthetente egy alkalom, vagy hamarabb végzünk a félév során => melyik legyen? Az előadások látogatása nem kötelező (ld. TVSZ) minden labor 160 perces 4 alkalom => mikor legyen? A laborgyakorlatok látogatása kötelező => olyan alkalom kell, amikor mindenki el tud jönni 2007.12.20 Mobil Internet előadás 6
Előadás tudnivalók Szerda, péntek 12:15 13:45 (szünet nélkül) Új tárgyról van szó (2. alkalom) 2007.12.20 mindent megteszünk, hogy ne érezzétek kiforratlannak minden kritikát/visszajelzést szívesen veszünk ha attól félsz, hogy befolyásolja az osztályzatodat (pedig nem), mondd/küldd el a vizsga után Több előadó is lesz doktorandusz hallgatók fiatal tanszéki oktatók Mobil Internet előadás 7
Mérés tudnivalók A méréseken beugrót iratunk legalább elégséges szükséges aki nem teljesíthette, nem végezheti el a mérést a mérés során jegyzőkönyv készül, amelyre osztályzatot adunk Aláírást az kap, aki minden mérést legalább elégségesre elvégzett Vizsgázni csak aláírás birtokában lehet 2007.12.20 Mobil Internet előadás 8
A félév végi osztályzat szóbeli vizsga a vizsgaidőszakban, legalább elégséges szükségeltetik a mérésekre kapott osztályzatok átlaga 1/2-es súlyozással befolyásolja a félév végi jegyet félév végi jegy = = kerekít(½ mérési + ½ szóbeli) A kerekítési szabályok matematikailag korrektek (3,5-re 4-est adunk) 2007.12.20 Mobil Internet előadás 9
Segédanyagok a tárgyhoz Minden előadáshoz fólia készül, amelyet az óra előtt le lehet tölteni, ki lehet nyomtatni az órai jegyzet készítése könnyen megy 2007.12.20 http://kutfo.hit.bme.hu Minden előadáson URL-eket, vagy más hivatkozásokat adunk további információért ide fordulhattok Egyéb nyomtatott, vagy elektronikus anyag nincs Mobil Internet előadás 10
A félév tematikája Alapok ismétlése: IPv4 és IPv6 Problémafelvetés: amikor a hálózathoz kapcsolódó hoszt elindul amikor a hosztok hálózata indul el Terminológia Horizontális és vertikális hálózatváltás Mikro- és makromobilitás Paging 2007.12.20 Mobil Internet előadás 11
A félév tematikája 2 Az alapmegoldás: hoszt szintű mobilitás támogatás az IP-ben (MIPv6 Mobile IPv6) Hálózati szintű mobilitás támogatás: NEMO (NEtwork MObility) A MIPv6 és NEMO megoldások korlátai és hátrányai. Lehetséges javítási javaslatok micro-mobilitás kezelés (HMIPv6 Hierarchical MIPv6, CIPv6 Cellular IPv6) hálózatváltások optimalizálása (FMIPv6 2007.12.20 Mobile IPv6 Fast Handovers) Mobil Internet előadás 12
A félév tematikája 3 Útvonal optimalizálás (routing optimisation) NEMO-ban (ONEMO Optimized NEMO) A mobilitás támogatás következményei 2007.12.20 többszörös cím (MCoA) terhelés- és forgalom megosztás a linkek között Multihoming Mobilitás támogatás az IP réteg felett mobilitást támogató réteg (MSL) hoszt azonosító protokollal (HIP) Mobil Internet előadás 13
A félév tematikája 4 Mobilitás támogatás az IP réteg felett 2007.12.20 transzport protokollok (TCP, UDP, DCCP, SCTP) Viszony rétegbeli protokollal (SLM) Az alkalmazási rétegben SIP Session Initiation Protocol A SIP-ről részletesebben. SIP-URI szerepe és használata. A harmadik generációs mobil rendszerek SIP támogatása: IMS (IP Multimedia Subsystem) Mobil Internet előadás 14
A félév tematikája 5 Esetek, amikor nem probléma a mobilitás Megoldások a meglévő mobil rendszerekben UMTS/GSM maghálózati infrastruktúra 2007.12.20 Azonos alhálózatra kapcsolt WiFi/WiMAX AP-k UMTS-WLAN együttműködés Az együttműködés szintjei Lehetséges együttműködési forgatókönyvek (loose coupling, tight coupling) Kiterjesztett mobilitás-támogatás a mobil szolgáltató szemszögéből: 3GPP UMA Mobil Internet előadás 15
Kezdjük hát... Amit az Internet Protokollról (IP) tudni érdemes IP 4-es verzió (IPv4) 2007.12.20 Mobil Internet előadás 16
Mi is az Internet Nincs jó definíció kisebb nagyobb hálózatok összekapcsolása 2007.12.20 IP-lal működő hálózatok Hagyjuk meg a filozófusoknak Ami fontos: az Internet használatához IP kell Internet Protokoll Két verziója van: IPv4 és IPv6 Bár ma az előbbi az egyeduralkodó, a félév során az utóbbira fókuszálunk ma IPv4, de rövidesen IPv6 Mobil Internet előadás 17
2007.12.20 Az Internet Protokoll Úgy képzelhető el, mint a postaszolgálat Az IP (pont úgy, mint a Magyar Posta) csomag alapú (csomagkapcsolt) protokoll datagram jellegű, megbízhatatlan cím alapján továbbítja a csomagokat Illetéktelenek is elolvashatják IP homokóra effektus Ma már szinte minden IP felett megy, a nem Internethez kapcsolódó szolgáltatások is pl. Távközlési szolgáltatók beszéd- és faxforgalma Mobil Internet előadás 18
Az OSI ARPA referencia modell 2007.12.20 Mobil Internet előadás 19
2007.12.20 IPv4 A csomagok haladási útvonaláról azok feladásakor semmit sem tudhatunk Best effort típusú szolgálat Minden csomag tartalmazza a küldő és a vevő címét A protokoll nem garantálja sem a csomag továbbítását, sem azt, hogy jó helyre érkezik, sem azt, hogy hibátlanul (A hibakezelés és -korrekció felsőbb rétegek feladata) Mobil Internet előadás 20
Az IPv4 csomag felépítése és adattovábbítás Fejléc Hasznos tartalom (payload) 2. hálózat 2. úv. 1. hálózat 1. úv. 4. hálózat 3. hálózat 2007.12.20 Mobil Internet előadás 21
IPv4 címzés Az IP feladata a csomagok célba juttatása 32 bites címek bájtonként, ponttal (.) elválasztva, tízes számrendszerben írjuk (pl. 152.66.248.201) Minden cím egy hálózati és egy állomás címből áll Hálózat száma azonosítja a célpont hálózatát az állomásszám pedig magát az állomást pl. 152.66.248.201
IPv4 címzés A címosztály Kezdetben a hálózat száma 7 bites, az állomás száma pedig 24 bites volt kevés, de népes hálózatokra számítottak '0'+7bit+24bit (pl. 68.23.44.198) Ezt A osztályú címeknek nevezték el Később a felhasználói igények megmutatták, hogy sok, kisebb méretű hálózatra van inkább szükség
IPv4 címzés B és C címosztályok Még két címosztályt vezettek be: B és C Nagyobb hely a hálózat részére (14 és 21 bit) és kisebb az állomás számára (16 és 8 bit) több, de kisebb hálózati címtér Igények: a B osztály túl sok, a C osztály túl kevés állomás bekapcsolását teszi lehetővé emiatt a C és B osztály elfogyott '10'+14bit+16bit, illetve '110'+21bit+8bit pl. 131.33.59.253, és 193.224.53.106
IPv4 címzés D és E címosztályok A D osztály = Internet Multicast '1110'+28 hasznos bit struktúrálatlan egy cím = egy multicast csoport az IGMP (Internet Group Management Protocol) mellett vezették be (RFC 1112) Az E osztályú címek későbbi felhasználásra voltak fenntartva '1111'+28bit Ma B és C osztályként osztják ki
IPv4 címzés speciális címek 127.0.0.1 => loopback interfész (az IP-s stack tesztelhetősége + egyéb funkciók) Speciális állomáscímek csupa 0 = a hálózat azonosítója (például 152.66.0.0) csupa 1 = a hálózaton minden állomás broadcast jelleggel (például 152.66.255.255) Fenntartott címek (pl. NAT-oláshoz) 10.0.0.0/8, 172.224.0.0/12 és 192.168.0.0/16 Léteznek egyéb konvenciók (pl..12 a DNS)
IPv4 címzés subnet mask Botorság lenne 24/16/8 bites állomáscímeket egyetlen fizikai hálózaton használni pl. 152.66.0.0 => az egész egyetem egyetlen fizikai hálózatként? A cég/szervezet számára fenntartott IPv4 címteret gyakran még tovább osztják az első rész a subnet (alhálózat) azonosítására a második pedig azon belül magát az állomást ez a címzési architektúra részét képezi [RFC950] felosztás az ún. subnet maszk megadásával
IPv4 címzés subnet mask A maszk megadása kétféleképpen történhet Egyetlen számmal perjel után írva: a cím elejétől hány bit a hálózat azonosítója (a címosztály bitjeit is beleszámítva) IP cím alakban: a 32 bites maszkban minden bit 1, ami a hálózat vagy a subnet számához tartozik és 0, ami magát az állomást azonosítja. Tehát, ha egy B osztályú hálózatban az első 8 bitet tartják fenn a subnet jelölésére, akkor a subnet maszk 255.255.255.0, vagy /24 lesz
IPv4 címzés subnetek Pl. az egyetem 152.66.0.0/16-os tartománya 152.66.x.0/24-es subnetekre van bontva Létezhetnek változó hosszúságú subnet-ek is egy tartományban lehet olyan subnet, melynek azonosítására az állomásszám felső 8 bitjét használjuk, és lehet olyan, ahol a felső 12 bitet A subneteket prefix mentessé kell tenni A subnet számokat úgy kell kiosztani, hogy az első 8 bitből el lehessen dönteni, a subnet típusát (8 vagy 12 bites subnet szám), lásd osztályok
IPv4 változó hosszúságú subnetek A változó hosszúságú subnetek alkalmazása akkor lehet hasznos, ha sok eltérő méretű subnet-ünk van és fix beosztás esetén nem elegendő a címtér A módszer viszont egy fokkal bonyolultabb routing protokollt és adminisztrációt igényel
IPv4 címzés subnet routolás Egy subneten lévő állomásokra feltétel szomszédosak legyenek (ugyanazon linken) router nélkül tudnak kommunikálni Egy linken több subnet is lehetséges Egy subnet nem tartalmazhat több linket linkek között az átjárás csak routeren át lehet Ha egy linken több subnet van, akkor a különböző sub-neten lévő állomások, bár közvetlenül is kommunikálhatnának, mégis routeren keresztül teszik
IPv4 fejléc formátum 20 octet + opciók : 13 mező, 3 flag bit Changed Removed 0 bits 4 8 16 24 31 Ver IHL Service Type Total Length Identifier Flags Fragment Offset Time to Live Protocol Header Checksum 32 bit Source Address 32 bit Destination Address Options and Padding
IPv4 fejléc formátum Version: IP verzió (most még 4, IPv4) Header Length: a fejléc hossza Type of Service (ToS) a szolgáltatás típusát határozza meg lehetővé teszi a datagramokkal való bánásmód megkülönböztetését, de korlátozottan Minthogy a specifikáció nem követelte meg, a jelenlegi Interneten sok helyen nem számít Total Length: a csomag teljes hossza
IPv4 fejléc formátum Identifier: a csomaghoz rendelt egyedi azonosító (töredezésnél van jelentősége) Flags and Fragment Offset: az Identifier mezővel együtt segítenek abban, hogy a több részben küldött datagramok a fogadó gépen ismét az eredeti adattá állhassanak össze Header Checksum: ellenőrző összeg Source Address: a küldő IP címe Destination Address: a célállomás IP címe
IPv4 fejléc formátum Time To Live (TTL) Egy datagram elküldésénél maximális A csomag élettartamát jelöli Minden hálózati berendezés köteles eggyel csökkenteni Ha eléri a nullát, a csomagot el kell dobni Ezzel érjük el, hogy hurok esetén egy csomag ne keringjen az örökkévalóságig a hálózatban Protocol: a felsőbb szintű protokoll kódját tartalmazza (pl. TCP, UDP)
Töredezés (Fragmentation) Akkor következik be, ha haladási útvonalon a következő linken az MTU (Max. Transm. Unit) kisebb, mint a csomagméret A router (vagy maga a feladó) több darabra tördeli a csomagot mindegyik darabba beleírja, hogy ez az eredeti csomag hányadik byte-jától kezdődő információt tartalmazza ad a csomagnak egy egyedi azonosítót. Az azonosító belekerül a fragmentbe és jelzi a vevőnek, hogy mely darabok alkotják az eredeti csomagot
Töredezés (Fragmentation) A router a kapott darabokat egyesével feladja, és a hálózatra bízza őket A nagyobb fragmentek esetleg később még tovább darabolódhatnak A vevő feladata a csomag összerakása A feladó egy bit (DF=Do not Fragment) beállításával kérheti, hogy ne darabolják ha az MTU túl kicsi a csomag továbbításához, a csomagot eldobják és erről ICMP üzenetben tájékoztatják a feladót
Töredezés (Fragmentation) Az IP csupán azt követeli meg, hogy Az alatta lévő hálózat képes legyen minimum 68 byte-os IP csomagok továbbítására ez tehát a minimálisan szükséges MTU pl. az Ethernet/WLAN esetében MTU=1500 byte Minden állomásnak képesnek kell lennie minimum 576 byte-os csomagok fogadására (egészben vagy fragmentálva) Javaslat, hogy ekkora (576 byte) csomagokon keresztül kommunikáljanak az állomások elavult: próbálják a maximális MTU-t használni
Opciók Az opciók szolgálnak ritka, IP szintű funkciók megvalósítására Nincs értelme minden csomagban használni Az opciókat minden állomás köteles megérteni és feldolgozni Nem az implementáció, csupán jelenlétük választható Copy bit: kell-e a töredezett csomagok mindegyikébe másolat Class: az opció típusát határozza meg debugging/mérés, vezérlés
Opciók Source routing: A feladó által megadott útvonalon, állomások megadott listáján halad végig a csomag. Két vállfaja van szigorú (strict): csak a listán felsorolt állomásokon haladhat végig a csomag. Ha két szomszédosnak felsorolt állomás nem szomszédos, akkor a csomag elvész és egy Source routing failed ICMP csomag érkezik a feladóhoz. laza (loose): ha a listán két szomszédosnak feltüntetett állomás a valóságban nem szomszédos, akkor is továbbítódik a csomag a lista következő eleméhez, de a router-ek által kijelölt útvonalon.
Opciók Security: a csomag hitelesítéséhez szükséges információ Extended security: további biztonsági funkciók Traceroute (útvonalrögzítés): A csomag által érintett állomások válaszolnak az IP címükkel Időbélyeg: A csomag által érintett állomások időbélyegei tárolódnak a csomagban Stream ID, MTU probe, MTU reply: obsolete Router alert: az útvonalválasztók figyelmeztetése komplexebb feladatok kapcsán
Internet Control Message Protocol Az ICMP = az IP felügyeleti protokollja mintha magasabb szintű protokoll lenne valójában az IP integráns része Az IPv4 és IPv6 ICMP protokollja is gyökeresen eltérő (ICMPv4 és ICMPv6) egy ICMP csomag valójában egy IP csomag, melyben a protokoll azonosítója 1
Internet Control Message Protocol ICMP üzenet a következő esetekben A címzett elérhetetlen. A router küldi a feladónak, ha a cél nem létezik/ki van kapcsolva a cél hálózata végtelen távolságban van beállított DF bit mellett fragmentációra lenne szükség. A címzett is küldheti, ha például nincsen a jelölt protokollt támogató stackje Lejárt a csomag élettartama. A router küldheti, ha a TTL nullára csökkent, vagy a címzett, ha a fragmentek összevárására kijelölt idő letelt és még nem érkezett meg az összes darab
ICMP Source quench: majdnem megtelt a buffer Túl gyorsan küldjük a csomagokat. Ezt az üzenetet router vagy a címzett küldheti, tipikusan még mielőtt kimeríti erőforrásait, így az a csomag, amire válaszként jön, még célbaérhet Átirányítás (Redirect): másfelé rövidebb a címzetthez küldendő csomagok, rövidebb úton is célba érhetnek. A router küldheti a küldő állomásnak a hálózat működésének javítása érdekében Paraméter probléma: hibás az IP csomag
ICMP Echo request és reply: a címzett elérhetőségének tesztelése. Egy Echo request üzenetre minden állomás köteles Echo replyjal válaszolni. (Ezt használja a ping parancs) Időbélyeg kérés és válasz: Az állomások óráinak ellenőrzésére használatos Information/Address mask request és reply: Saját hálózat számának felderítése. A válaszoló egy teljesen kitöltött címmel válaszol Traceroute: válasz a traceroute opcióra
ICMP Az eredeti ICMP funkciók mellé az RFC 1256 megjelenésével az ICMP router discovery mechanizmusa társult. A routerek periodikusan hirdetményeket tesznek közzé a linken (Router Advertisement), melyekben számos paraméterüket közlik. Az állomások így megismerik a routereket a linken Az állomásoknak nem kell megvárniuk a hirdetmények periodikus közzétételét, hanem felszólításokkal (Router Solicitation) soron kívül is kiválthatják azokat
Hajajjajjj Gondok az IPv4-gyel
Híres kijelentések I think there is a world market for maybe five computers. Thomas Watson, chairman of IBM, 1943 640K ought to be enough for anybody. Bill Gates, 1981 32 bits should be enough address space for Internet. Vint Cerf, 1977 (Honorary Chairman of IPv6 Forum 2000)
Címzés problémák Az IPv4 nem jelzi a földrajzi távolságokat, pedig hasznos lenne az útvonalválasztásnál A nagyméretű site-ok több C osztályú blokkot igényelnek, ami miatt a routing táblák gyorsabban nőnek A felosztott címtér kezelése összetett feladat (routerenként kell karban tartani) Elfogynak a címek (2 év, ketyeg az óra) http://penrose.uk6x.com/
Ideiglenes megoldások a címprobléma kezelésére CIDR Classless Inter-Domain Routing NAT - Network Address Translator A használaton kívüli címek visszakérése Használaton kívüli A osztályú címek kiosztása A cím-birtoklás jelenlegi struktúrájának módosítása
Classless Inter-Domain Routing A CIDR lényege, hogy szakít a címosztályok koncepciójával Helyette a hálózati prefix, hálózati maszk koncepcióját általánosítja. Az Internet routerek nem az IP cím első három bitje alapján állapítják meg a határt a hálózati cím és az állomáscím között, hanem hálózati maszk alapján (amit cserébe tárolni kell) A CIDR-t ismerő routing protokollok nem törődnek a címosztállyal, csak a maszkot figyelik
CIDR Elemzők szerint, ha 1994/95-ben nem vezetik be a CIDR technológián alapuló címkiosztást, a routing táblák akkorára nőttek volna, hogy az Internet mára működésképtelen lenne A legtöbb router ma már ismeri ezt a technikát, és jelenleg az IANA is CIDR alapján osztja ki a címeket.
NAT Network Address Translator A NAT technika manapság az egyik legelterjedtebb módja az Internetre kapcsolódásnak Alapötlete az RFC 1918 az Internetre nem kapcsolódó IP alapú hálózatok címkiosztására tesz ajánlást Ezeknek a hálózatoknak nem kell globálisan egyedi címeket lefoglalni, elég, ha a lokálisan egyediek A NAT megoldást nyújt a címtérhiány ellen
NAT Network Address Translator Az IANA 3 különböző méretű címtartományt különített el erre a célra: 10.0.0.0/8 (10.0.0.0 10.255.255.255) 172.16.0.0/12 (172.16.0.0 172.31.255.255) 192.168.0.0/16 (192.168.0.0 192.168.255.255) Egy szervezet, mely nem kívánja hálózatát az Internetre kapcsolni, tetszőlegesen választhat ezen címekből Így tehát nem kell az IANA-hoz fordulni IP-címekért IANA vállalja, hogy ezen címek nem lesznek kiosztva
A NAT működése A NAT-olni akaró szervezet kér tipikusan egy IP címet az Internet szolgáltatójától (ez lesz a NAT külső oldalán) A hálózaton levő állomásokat felcímkézi a fenti három címtartomány valamelyikéből vett címekkel (ez lesz a NAT belső oldalán) A NAT-oló modul Dinamikusan helyettesíti a belső címeket a külsőkkel a kimenő csomagokban A válaszcsomagokban visszaalakítja
NAT előnyök és hátrányok Előnyei csökkenti az Interneten szükséges címek számát növeli a biztonságot (a belső hálózati struktúra láthatatlan a külvilág felé) a hálózati címstruktúrát a szervezet akkor is megtarthatja, ha Internet szolgáltatót vált Hátrányai kommunikációt csak belső végpont indíthat NAT-olt szerverek üzemeltetése trükközést igényel két NAT-os tartomány egyesítése nehéz lehet
A használaton kívüli címek visszakérése Az IANA javaslatokat tesz [RFC 1917] azok a hálózatok, melyek biztonsági okokból sohasem kapcsolódnának az Internetre, szolgáltassák vissza a már lefoglalt IP címeiket azok az ISP-k (Internet Service Provider) amelyek túl sok használaton kívüli hálózati előtagot birtokolnak, szolgáltassák vissza ezeket én pedig javaslom, hogy mindenki fizesse be nekem az összes pénzét megkérdőjelezhető a sikeressége
Használaton kívüli A és E osztályú címek kiosztása Az A címosztály egy részét egyéb célokra tartogatták A 64.0.0.0/2 címtartományt nem osztották ki Született egy ajánlás arra nézve, hogy ezt a címtartományt is ki lehessen osztani, hiszen a teljes IP címtartománynak jelentős részét teszi ki Az E osztályú címeknél???
A cím-birtoklás jelenlegi struktúrájának módosítása A címtér allokálás jelenleg a szervezet kér egy címtartományt az IANA-tól ha azt megkapja, addig birtokolhatja amíg az neki jól esik (vagy ameddig fizetni tud érte) IETF készített egy ajánlást, melynek lényege a szervezet csak kölcsön kapja a címeket egy idő után le kell mondania róla, és másikat kell igényelnie. Ezáltal bizonyos dinamizmussal ruháznánk fel a címek allokálását, a módszernek azonban több nagy hátránya is van.
Cím-birtoklás: jelenlegi struktúra módosítása hátrányok A CIDR technológia alapfeltétele: a címkiosztás tükrözze a hálózati topológiát A folyamatos újra címzésekkel kaotikussá válik egyre újabb és újabb elkerülő útvonalak beszúrása szükséges a routing táblákban a dinamizmus árát a csomagok routolási hatékonyságának csökkenése jelentené A módszer az Internetes közösségek ellenérzését váltaná ki IETF Procedures for Internet/Enterprise Renumbering (PIER) munkacsoport
Mobilitás Egyik hálózatból másikba mozogva változik az IPv4 cím A létező kapcsolatok megszakadnak handover esetén Roaming esetén az új protokollra van szükség, hogy a HLR-ben az új IP címet és az egyéni azonosítót összerendelje A WAP és GPRS felhasználók drasztikusan növelik a mobil Internet használatot A korlátozott IPv4 címtér hamarosan kifogy
Egyebek Otthoni hálózat (Home Networking) Nagyon sok egyedi IP címet igényelnek eszköz szinten. Szolgáltatások támogatása Az új szolgáltatások nem tudják hasznosítani az IP fejléc fix mezőit. Nincs beépített IPv4 biztonsági algoritmus. A QoS-n sokat segítenének az IP szintű forgalmi folyam jelzők.
Hivatkozások RFC 768: User Datagram Protocol RFC 791: Internet Protocol DARPA specification RFC 792: Internet Control Message Protocol DARPA specification RFC 793: Transmission Control Protocol DARPA specification RFC 826: Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC 919: Broadcasting internet datagrams RFC 922: Broadcasting internet datagrams in the presence of subnets RFC 1027: Using ARP to Implement Transparent Subnet Gateways RFC 1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks RFC 1166: INTERNET NUMBERS RFC 1256: ICMP Router Discovery Messages RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC 1812: Requirements for IP Version 4 Routers RFC 1878: Variable Length Subnet Table For IPv4