DNS, DHCP és 3G UMTS Mobil és vezetéknélküli hálózatkezelés Linux és * BSD operációs rendszerek alatt Bokor László BME-HT goodzi@mcl.hu

Áttekintés DNS Alapok Szolgáltatások Hierarchia Névfeloldás DHCP Működés 3G UMTS Mobil telekommunikáció generációinak fejlődése PPP alapok 3GPP UMTS architektúra Fontosabb fogalmak BME-MIK 3G UMTS tesztrendszer DNS, DHCP és 3G UMTS

DNS – Alapok I. Egy forrás és cél host közti IP alapú kommunikációhoz mindkét állomásnak érvényes IP címmel kell rendelkeznie Probléma: az IP-címek az emberek számára nehezen memorizálhatók Megoldás: könnyen olvasható tartomány- és állomásnevek (pl. www.index.hu), melyek az emberek számára sokkal kényelmesebb azonosítók A könnyen megjegyezhető tartomány/állomásnevek és a hálózati réteg működésében nélkülözhetetlen (de nehezen memorizálható) IP címek fordítását a hálózati névfeloldó-rendszerek végzik. DNS, DHCP és 3G UMTS

DNS – Alapok II. Az Internet hajnalán az IP-címek és állomásnevek egyetlen adminisztrációs szerveren, a központilag tárolt HOSTS nevet viselő állományban voltak egymáshoz rendelve. Ez az állomány tartalmazta az internetre kötött összes állomás nevét és IP-címét. Az állomásnév megadása után a küldő fél a HOSTS állomány letöltött példányából kereste ki a cél IP-címét. Ez a HOSTS állomány eleinte ki tudta elégíteni az internetre csatlakoztatott számítógépek igényeit, ám az IP terjedésével az állomásnév-cím feloldást igénylő hostok száma nagyon megnőtt, így a HOSTS alapú működés fenntarthatatlanná vált, új megoldás kellett. A megoldás neve a Domain Name Service (DNS): a DNS szerverek elosztott alapú működéssel oldják meg névfeloldást. Egy darabka múlt: napjainkban is minden állomás TCP/IP stack-je kezel egy HOSTS állományt. A feloldási folyamat elején, annak részét képezve a DNS szolgáltatás igénylése előtt az állomás a helyi HOSTS állományban keres először. Szerpe: Hibakeresés DNS ideiglenes helyettesítése DNS folyamat – korlátozott képességű – gyorsítása DNS, DHCP és 3G UMTS

Példa HOSTS fájlra mik:/home/goodzi# cat /etc/hosts 127.0.0.1 localhost mail oxserver 152.66.87.200 samba.mik.bme.hu MIK 10.0.2.2 ocmpvideo # The following lines are desirable for IPv6 capable hosts #::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts DNS, DHCP és 3G UMTS

DNS információ lekérése - dig mik:/home/goodzi# dig www.index.hu ; <<>> DiG 9.5.1-P3 <<>> www.index.hu ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62793 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 8 ;; QUESTION SECTION: ;www.index.hu. IN A ;; ANSWER SECTION: www.index.hu. 214 IN A 217.20.130.97 ;; AUTHORITY SECTION: hu. 86597 IN NS NS2.NIC.FR. hu. 86597 IN NS NS1.NIC.hu. hu. 86597 IN NS NS-COM.NIC.hu. hu. 86597 IN NS NS3.NIC.hu. hu. 86597 IN NS NS-SE.NIC.hu. hu. 86597 IN NS NS2.NIC.hu. hu. 86597 IN NS NS.NIC.hu. ;; ADDITIONAL SECTION: NS2.NIC.FR. 86256 IN A 192.93.0.4 NS1.NIC.hu. 863 IN A 193.239.149.3 NS-COM.NIC.hu. 863 IN A 194.0.1.12 NS3.NIC.hu. 863 IN A 195.70.35.250 NS-SE.NIC.hu. 863 IN A 77.72.229.251 NS2.NIC.hu. 863 IN A 193.6.16.1 NS.NIC.hu. 41206 IN A 193.239.148.62 NS2.NIC.FR. 86256 IN AAAA 2001:660:3005:1::1:2 ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 17 14:40:47 2010 ;; MSG SIZE rcvd: 326 DNS, DHCP és 3G UMTS

DNS információ lekérése - nslookup mik:/home/goodzi# nslookup www.index.hu Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: www.index.hu Address: 217.20.130.97 DNS, DHCP és 3G UMTS

Inverz lekérés – dig -x DNS, DHCP és 3G UMTS mail:/home/goodzi# dig -x 217.20.130.97 ; <<>> DiG 9.5.1-P3 <<>> -x 217.20.130.97 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4487 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;97.130.20.217.in-addr.arpa. IN PTR ;; ANSWER SECTION: 97.130.20.217.in-addr.arpa. 3600 IN PTR sportgeza.hu. ;; AUTHORITY SECTION: 130.20.217.in-addr.arpa. 3600 IN NS ns.index.hu. 130.20.217.in-addr.arpa. 3600 IN NS ns.inventra.hu. ;; ADDITIONAL SECTION: ns.index.hu. 5673 IN A 195.56.65.172 ns.inventra.hu. 5673 IN A 217.20.130.10 ;; Query time: 72 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 17 14:42:33 2010 ;; MSG SIZE rcvd: 177 DNS, DHCP és 3G UMTS

DNS – Alapok III. Erőforrás bejegyzés és domainnév-tartomány Az erőforrás bejegyzés (resource record) egy bejegyzés az adott DNS zóna adatbázis állományában. A bejegyzés azonosítja az állomás típusát, IP-címét vagy a DNS adatbázis vonatkozó paraméterét. A domainnév-tartomány több al-tartományból vagy csoportból, és azokon belüli újabb erőforrás bejegyzésekből jön létre. Célja, hogy biztosítsa az erőforrások hierarchikus felépítését. DNS szerver A DNS szerverek tartják karban az erőforrás bejegyzéseknek és a domainnév-tartomány információinak adatbázisát. A DNS szerverek a beérkezett kéréseket először megpróbálják a saját zónájuk adatbázisában tárolt bejegyzések alapján feloldani. Ha az adott DNS szerver nem rendelkezik a kért információval, akkor további, előre meghatározott DNS szerverek bevonásával válaszolja meg a kérést. Névfeloldó A névfeloldó (resolver) olyan alkalmazás (esetleg rendszerfunkció), mely az ügyfeleken és a szervereken egyaránt fut. Az ügyfeleken egy tartománynév használatba vételekor betöltődik, és indít egy DNS kérést a szerver felé. A szervereken – ha az nem rendelkezik a kért információval egy beérkező kérés megválaszolásához – továbbítja a kérést egy másik DNS szerverhez. DNS, DHCP és 3G UMTS

DNS beállítások a kliens gépen mik:/home/goodzi# cat /etc/resolv.conf domain bme.hu search hit.bme.hu nameserver 127.0.0.1 nameserver 152.66.248.12 nameserver 152.66.249.12 nameserver 2001:738:2001:21a0:217:34ff:fe05:f75c mik:/home/goodzi# cat /etc/host.conf order hosts,bind multi on DNS, DHCP és 3G UMTS

DNS – Hierarchia I. A DNS rendszer felépítése hierarchikus és az egész Internetre elosztott. A hierarchiához DNS tartománynevek segítségével biztosítható használ amely kisebb, könnyen kezelhető zónákra osztható. A DNS szerverek jól körülhatárolt fennhatóságú adatbázist kezelnek és csak a DNS rendszer kis részéért felelősek. Ha egy DNS szerver olyan névre kap kérést, mely név nem a saját zónájához tartozik, akkor egy másik, a megfelelő zónát kezelő szerverhez továbbítja beérkező feloldási igényt. Ennek köszönhetően a DNS egy jól bővíthető rendszer! DNS, DHCP és 3G UMTS

DNS – Hierarchia II. A DNS hierarchia egy olyan, fordított fához hasonlít, melynek a felül van a gyökere és alul az ágai. A DNS hierarchia tetején a gyökér (root) szerverek tartják karban a legmagasabb szintű (top-level) tartományok elérhetőségéről tárolt információkat, melyek aztán legtöbbször visszamutatnak a második szintű (second level) tartományok szervereire. A top-level tartományok a hozzájuk tartozó szervezetek típusát vagy országát jelentik. Pl.: .com –üzleti vállalat .hu – Magyarország .au – Ausztrália .org – nonprofit szervezet A top-level tartományok alatt a második (majd még alacsonyabb) szintű tartományok találhatók: .bme.hu – BME .mik.bme.hu – BME-MIK mail.mik.bme.hu – levelezőszerver a BME-MIK szervezetén belül DNS, DHCP és 3G UMTS

DNS – Hierarchia III. A DNS hierarchia gyökerében lévő (root) DNS szerver nem feltétlenül tudja, hogy pontosan hol vannak az ágak (pl. a mail.mik.bme.hu) de vannak rekordjai a top-level tartományról (pl. a .hu top-level tartományról). A .hu tartományba tartozó szerverek szintén nem biztos, hogy ismerik a mail.mik.bme.hu címét, de van bejegyzésük a bme.hu tartományról. Hasonlóan, a bme.hu tartománynak van bejegyzése a mik.bme.hu-ról, a mik.bme.hu névszervere pedig már fel fogja tudni oldani a mail.mik.bme.hu IP-címét. Látható, hogy a DNS szolgáltatás erősen decentralizált kiszolgáló hierarchián alapul. Az erőforrás bejegyzések tartalmazzák azokat a tartományneveket, melyeket a DNS szerverek feloldanak és ezeket az információkat más szerverek szintén lekérdezhetik tőlük. A mail.mik.bme.hu egy ún. teljesen minősített tartománynév (FQDN – Fully Qualified Domain Name): megadja az adott állomás pontos helyét a hierarchikus DNS névtartományban. DNS, DHCP és 3G UMTS

DNS – Névfeloldás I. Ha egy állomás DNS névfeloldást indít, akkor a resolver segítségével fog kapcsolatba lépni a tartományán belüli DNS szerverrel (a resolver ismeri a DNS szerver IP-címét, ez az adat része az állomás alapvető konfigurációs paramétereinek). Amikor a DNS szerver kérést kap egy ügyfél resolver-től, akkor a kérést először a helyi DNS bejegyzések gyorstárjában (cache) lévő adatok alapján próbálja megválaszolni. Ha a cache-ben nincs válasz, akkor a szerver resolver funkciója a kérést egy másik DNS szerver felé közvetíti. A folyamat egészen addig folytatódik, amíg a kérés válasza elő nem áll, majd a válasz (vagyis a névfeloldási információ) visszakerül az eredeti szerverhez, ami válaszol az ügyfélnek. A DNS névfeloldás folyamatai alatt valamennyi DNS szerver eltárolja a kérésekre érkezett válaszokat a cache-ben. A gyorstárban tárolt adatokat használva a DNS szerver gyorsíthat az válaszadás folyamatán, mert a szerver először mindig a cache-ben lévő adatok alapján kísérli meg a válaszadást. A DNS szerverek csak egy adott ideig tárolják az információt gyorstárjaikban, hiszen az állomásnév bejegyzések időről-időre változhatnak, tehát a cache adatai elévülhetnek. DNS, DHCP és 3G UMTS

A DNS névfeloldás csomagszekvenciája mik:/home/goodzi# nslookup www.origo.hu mik:/home/goodzi# tshark -i eth1 -R dns 41.423935 192.168.101.243 -> 152.66.87.200 DNS Standard query A origo.hu 41.424100 152.66.87.200 -> 192.168.101.243 DNS Standard query response A 195.228.240.145 mik:/home/goodzi# nslookup ipv6.google.com 199.465871 152.66.87.211 -> 152.66.87.200 DNS Standard query AAAA ipv6.google.com 199.466071 152.66.87.200 -> 152.66.87.211 DNS Standard query response AAAA 2a00:1450:8001::68 DNS, DHCP és 3G UMTS

DNS – Dinamikus frissítés A DNS korai implementációiban az erőforrás bejegyzések felvitele és módosítása csak kézzel történhetett. A DNS zónák kezelésének és karbantartásának megkönnyítésére a DNS protokollt úgy módosították, hogy az egyes állomások saját bejegyzéseiket dinamikusan frissíthessék. A dinamikus frissítéssel a DNS ügyfelek adataikban bekövetkezett változásai esetén azonnal frissíthetik saját DNS bejegyzéseiket. Ezt a speciális funkciót a DNS szervernek, a DNS kliensnek és a DHCP szervernek egyaránt támogatnia kell. A legtöbb, napjainkban elterjedt operációs rendszer támogatja a dinamikus frissítés funkcióit. DNS, DHCP és 3G UMTS

DNS - Zónák A DNS szerverek a teljes DNS hierarchia csak egyetlen, meghatározott szeletének zóna adatbázisát kezelik (az adott szelet erőforrás bejegyzései a DNS zónában kerülnek tárolásra). A DNS zónák címkeresési (forward lookup) vagy névkeresési (reverse lookup) zónák lehetnek, és ezeken belül megkülönböztetünk elsődleges vagy másodlagos címkeresési, ill. névkeresési zónákat. Címkeresési zóna Hagyományos DNS zóna, mely egy FQDN-t old fel IP-címre. Egy weboldal URL-jének (például www.mik.bme.hu) böngészőbe való bevitele egy rekurzív kérést indít helyi DNS kiszolgálóhoz a név feloldására. Névkeresési zóna A névkeresési zóna IP címeket old fel FQDN tartománynevekre. Bizonyos alkalmazások – biztonsági célokból – névkeresést használnak a velük kommunikáló állomások azonosítására. Elsődleges zóna Az elsődleges DNS zóna módosítható: ha új erőforrás bejegyzést kell felvenni vagy egy létezőt kell módosítani vagy törölni kell akkor az elsődleges zónát szerkesztik. Minden DNS tartományban egyetlen elsődleges zóna lehet (illetve egyetlen elsődleges címkeresési és egyetlen elsődleges névkeresési zóna). Másodlagos zóna A másodlagos zóna biztonsági célokat szolgál: ez egy csak olvasható tartalék zóna, melyet az elsődleges zónától fizikailag is elkülönítve (külön szerveren) tárolni. A másodlagos zóna tulajdonképpen az elsődleges zóna másolata és az elsődleges zónából frissül. Másodlagos zónából is létezhet címkeresési és névkeresési zóna is. DNS, DHCP és 3G UMTS

Példa címkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/mik.bme.hu $TTL 600 @ SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. (2010031002 12H 3H 7D 600 ) NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. MX 10 mail MX 20 www2 kamu NS backup.mik.bme.hu. exchange NS exchangeserver.mik.bme.hu. @ A 152.66.87.211 ns A 152.66.87.200 mail A 152.66.87.200 gallery A 152.66.87.200 qoe A 152.66.87.200 opensbc A 152.66.87.200 calendar A 152.66.87.200 location A 152.66.87.221 samba A 152.66.87.200 wlan A 152.66.87.200 www A 152.66.87.211 home A 152.66.87.200 home AAAA 2001:738:2001:20a0:216:35ff:fe04:f76c test A 152.66.87.2 ibm1 A 152.66.87.4 ibm2 A 152.66.87.5 gep4 A 152.66.87.6 gep5 A 152.66.87.7 wlan1 A 152.66.87.8 wlan2 A 152.66.87.9 DNS, DHCP és 3G UMTS

Példa IPv4-es névkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/87.66.152.in-addr.arpa $TTL 86400 87.66.152.in-addr.arpa. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( 2010031001 ;Serial number 10800 ;Refresh 3600 ;Retry 604800 ;Expire 86400) ;Minimum TTL NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. 2 IN PTR ns0.mik.bme.hu. 3 IN PTR miksolaris.mik.bme.hu. 4 IN PTR ibm1.mik.bme.hu. 5 IN PTR ibm2.mik.bme.hu. 6 IN PTR gep4.mik.bme.hu. 7 IN PTR gep5.mik.bme.hu. 8 IN PTR wlan1.mik.bme.hu. 9 IN PTR wlan2.mik.bme.hu. 10 IN PTR wlan3.mik.bme.hu. 11 IN PTR wlan4.mik.bme.hu. 12 IN PTR wlan5.mik.bme.hu. 13 IN PTR switch1.mik.bme.hu. 14 IN PTR switch2.mik.bme.hu. 15 IN PTR switch3.mik.bme.hu. 16 IN PTR switch4.mik.bme.hu. 17 IN PTR switch5.mik.bme.hu. 18 IN PTR gep16.mik.bme.hu. DNS, DHCP és 3G UMTS

Példa IPv6-os névkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/8.0.2.1.0.0.2.8.3.7.0.1.0.0.2.IP6.ARPA $TTL 600 8.0.2.1.0.0.2.8.3.7.0.1.0.0.2.IP6.ARPA. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( 2008071501 ;Serial number 10800 ;Refresh 3600 ;Retry 604800 ;Expire 600) ;Minimum TTL NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. d.6.7.f.4.0.e.f.f.f.5.3.6.1.2.0.0 IN PTR ns.mik.bme.hu. 1.c.0.8.1.7.e.f.f.f.d.5.b.0.2.0.9 IN PTR mnn1-eth.anemone.mik.bme.hu. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR gw.anemone.mik.bme.hu. 8.8.3.0.a.2.e.f.f.f.f.4.4.1.2.0.2 IN PTR sun-gw.anemone.mik.bme.hu. 0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.8 IN PTR sun-ha.anemone.mik.bme.hu. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8 IN PTR mr1-hoa.anemone.mik.bme.hu. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 IN PTR pc1.anemone.mik.bme.hu. DNS, DHCP és 3G UMTS

DHCP - Alapok A DHCP (Dynamic Host Configuration Protocol) a TCP/IP hálózatra csatlakozó kliens végpontok hálózati beállításainak automatikus konfigurációjára való. Segítségével a kliens megtudhatja az alábbiakat: IP-cím hálózati maszk alapértelmezett átjáró DNS szerver címe A DHCP kliens-szerver alapú, működése a kliensek által küldött kérésekből, és a DHCP szerver által küldött válaszokból áll. A DHCP segítségével dinamikusan oszthatók ki IP-címek, ami a rendelkezésre álló tartomány gazdaságos felhasználását teszi lehetővé (a hálózatról lecsatlakozó végpontok IP-címeit megkaphatják a hálózatra újonnan felcsatlakozók). Három féle IP-cím kiosztás: automatikus (DHCP-vel osztható IP-tartomány megadásával) kézi (MAC cím alapján) dinamikus (olyan IP-tartomány megadásával, ahol az IP címek „újrahasznosíthatók”) DNS, DHCP és 3G UMTS

DHCP - Működés Mikor egy végpontot először állítunk be a hálózatba, az még nem rendelkezik IP címmel, alhálózati maszkkal, alapértelmzett átjáróval vagy DNS szerver címmel. Ezeket, a hálózati működéshez szükséges a beállítási paramétereket a végpont DHCP kliensként, a DHCP szervertől szerzi be. A DHCP szervert úgy állítják be, hogy bírjon az IP címeknek egy olyan tartományával, melyből oszthat az ügyfeleknek. A működés: A beállításokat igénylő kliens egy DHCP felderítés (DHCP Discover) üzenetet küld 255.255.255.255 cél IP, és FF-FF-FF-FF-FF-FF cél MAC címmel. A hálózat valamennyi állomása fogadja ezt a szórásos DHCP keretet, de csak a DHCP szerver fog válaszolni rá: egy felajánlást (DHCP Offer) küld a kliensnek, melyben ajánl egy IP címet. A kliens állomás ezután egy igénylést (DHCP Request) küld a szervernek, kérve, hogy használhassa a felajánlott címet. A szerver egy jóváhagyással (DHCP Acknowledgement) fejezi be a négy üzenetből álló mechanizmust. DNS, DHCP és 3G UMTS

DHCPv4 használata a kliens gépen mik:/home/goodzi#dhclient eth2 Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth2/00:14:4f:2a:03:8a Sending on LPF/eth2/00:14:4f:2a:03:8a Sending on Socket/fallback DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 152.66.87.200 DHCPREQUEST on eth2 to 255.255.255.255 port 67 DHCPACK from 152.66.87.200 bound to 152.66.87.196 -- renewal in 13100 seconds. mik:/home/goodzi#tshark -i eth2 40.478696 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0xf8600839 40.479098 152.66.87.200 -> 152.66.87.196 DHCP DHCP ACK - Transaction ID 0xf8600839 DNS, DHCP és 3G UMTS

A mobil távközlés generációi DNS, DHCP és 3G UMTS

Kitekintés: 3G és B3G DNS, DHCP és 3G UMTS

A 3GPP UMTS architektúra (Release 6) DNS, DHCP és 3G UMTS

3G User Plane protokoll stack DNS, DHCP és 3G UMTS

Fontosabb fogalmak PDP (Packet Data Protocol) kontextus A mobil PDP kontextusának aktiválásakor az SGSN és a GGSN létrehozza az adott kommunikációs folyamat (session) kezeléséhez szükséges információkat (IP cím, QoS) tartalmazó adatstruktúrát (kontextust) APN (Access Point Name) GGSN-hez tartozó logikai név, mely egy külső hálózatot is azonosít (Az SGSN DNS lekéréssel találja meg a mobil által igényelt APN-hez tartozó kiszolgáló GGSN-t) GTP (GPRS Tunneling Protocol) UDP/IP alapú alagutazó protokoll mely a külső csomagkapcsolt hálózat és a GPRS hálózaton belüli mobil egység közti kapcsolatért felel DNS, DHCP és 3G UMTS

Állapottartó IPv4/IPv6 auto- konfiguráció UMTS hálózatokban DNS, DHCP és 3G UMTS

Állapotmentes IPv6 auto-konfiguráció UMTS hálózatokban DNS, DHCP és 3G UMTS

PPP alapok I. A Point-to-Point Protocol (PPP) egy alapvetően soros összeköttetések számára tervezett adatkapcsolati protokoll Az adatkapcsolati rétegben működik, de itt újabb alrétegeket (alprotokollokat) definiál, melyek segítségével képes multi-protokoll adatcsomagok beágyazására és átvitelére is a létrehozott pont-pont kapcsolatokon keresztül A PPP protokoll rögzített és nyílt szabványokon (RFC 1661, 2153, stb.) alapul, ezért lehetővé teszi a különböző gyártóktól származó készülékek közötti kommunikációt is DNS, DHCP és 3G UMTS

PPP alapok II. A PPP két alprotokollt definiál: Kapcsolatvezérlő protokoll (Link Control Protocol, LCP): a pont-pont kapcsolatok felépítését, fenntartását és lebontását menedzseli. Hálózatvezérlő protokoll (Network Control Protocol, NCP): a különböző hálózati protokollokkal való együttműködést biztosítja. DNS, DHCP és 3G UMTS

PPP - Kapcsolatvezérlő protokoll (LCP) Az LCP a pont-pont összeköttetések létrehozására, fenntartására, tesztelésére és terminálására használatos. Az LCP legfontosabb feladatai: tömörítés hibafelismerés hitelesítés (authentication) több kapcsolat (multilink) konfigurációs hibákat észlelése különböző méretű csomagok kezelése kapcsolatdiagnosztika DNS, DHCP és 3G UMTS

PPP - Hálózatvezérlő protokoll (NCP) Az NCP a különböző hálózat rétegbeli protokollok beágyazására használatos (így eltérő hálózati protokollok, mint pl. IPv4 és IPv6, is képesek ugyanazon kommunikációs kapcsolatot használni). A PPP kapcsolatokon használt valamennyi hálózati protokollnak saját hálózatvezérlő alrétegre (protokollra) van szüksége a PPP-n belül. Az IP az IP vezérlőprotokollt (IPCP, IP6CP), az IPX pedig az IPX vezérlőprotokollt (IPXCP) használja. DNS, DHCP és 3G UMTS

PPP - Működés A PPP-kapcsolatok létrehozásának folyamata három fázisra bontható Az összeköttetés létrehozása (kapcsolatfelépítés) A PPP LCP keretekkel teszteli és konfigurálja az adatkapcsolatot. Az LCP-keretek konfigurációs mezőjét használva van mód például a maximális átviteli egység (MTU) méretének, a tömörítés típusának és a használt hitelesítési típusnak az egyeztetésére. A kapcsolat hitelesítési típusának egyeztetése és az átviteli minőség tesztelése opcionálisak. A kapcsolatfelépítés fázisa akkor tekinthető befejezettnek, ha a végponti berendezések megkapták az aktuálisan használandó konfigurációt nyugtázó LCP keretet. Hitelesítés (opcionális) Ez a fázis jelszavas védelmet biztosít a kapcsolódó végpontok azonosításához (pl. PAP, CHAP). A hitelesítésre a végpontok kapcsolatparamétereinek elfogadása után, de még az NCP egyeztetési fázis kezdete előtt kell sort keríteni. NCP egyeztetés A PPP NCP csomagok segítségével választ ki és konfigurál egy vagy több hálózati rétegbeli protokollt (pl. IPv4-et, IPv6-ot). Ha az LCP bontja a kapcsolatot, akkor értesíteni kell a hálózati rétegbeli protokollokat is, hogy azok végrehajthassák a megfelelő műveleteket. Egy létrejött PPP kapcsolat mindaddig aktív marad, amíg az LCP vagy az NCP nem bontja a kapcsolatot (vagy le nem jár a kapcsolat élettartama). Természetesen a felhasználók is inicializálhatják a PPP kapcsolatok befejezését. DNS, DHCP és 3G UMTS

Modem vezérlése: AT parancsok PIN Command: AT+CPIN? Response: +CPIN: <code> Command: AT+CPIN=<pin>[,<newpin>] Response: OK | +CME ERROR: <error> PDP (Packet Data Protocol) context Command: AT+CGDCONT=<cid> [,<pdptype> [,<apn>[,<pdpaddr> [,<dcomp>[,<hcomp]]]]] Response: OK | ERROR Command: AT+CGDCONT? Response: +CGDCONT: <cid1>,<pdptype1>,<apn1>,<pdpaddr1><dcomp1>,<hcomp1>, …, <cidN>,<pdptypeN>,<apnN>,<pdpaddrN><dcompN> <cid> PDP context ID, minimum value is 1, maximum value depends on device and can be found with the =? command. <pdptype> String parameter identifying the protocol type IP – Internet Protocol IPV6 – Internet Protocol, version 6 PPP – Point to Point Protocol <apn> String that identifies the Access Point Name in the packet data network. <pdpaddr> Requested address, if null (0.0.0.0) an address is requested dynamically. <dcomp> PDP data compression control, off by default. <hcomp> PDP header compression control, off by default. Get/Set current network operator, list available operators Command: AT+COPS?, Response: +COPS: (<mode>,[<format>,<oper>[,<AcT>]]),…, (<modeN>,[<formatN>,<operN>[,<AcTN>]]) Command: AT+COPS=<mode>,[<format>,<oper>[,<AcT>]] Response: OK | +CME ERROR DNS, DHCP és 3G UMTS

AT parancsok kiadása: wvdial anemone@anemone-mnn2:~$ cat /etc/wvdial.conf [Dialer nokia6] #Init1 = AT+CPIN=1234 Modem = /dev/ttyACM0 Carrier Check = no Auto DNS = 0 Init2 = AT+CGDCONT=1,"IPV6","test6",,0,0 Phone = *99# New PPPD = yes Username = a Password = a Baud = 921600 Stupid mode = 1 DNS, DHCP és 3G UMTS

BME-MIK 3G UMTS architektúra DNS, DHCP és 3G UMTS

A demonstráció során használt fontosabb rendszerelemek User Equipment Nokia N93i Symbian OS v9.1, S60 3rd edition felhasználói interfész, V30.0.013 firmware GGSN (APN=test, IPv4) Cisco 7206, IOS 12.4 c7200-adventerprisek9_mw-mz.124-15.T3.bin Cisco GGSN Release 6.0 GGSN (APN=test6, IPv6) OpenGGSN 0.84 továbbfejlesztése OpenGGSN 0.84_v6_03 SunFire X4200 hardveren fut, Ubuntu Server 7.04 operációs rendszeren, 2.6.23-as kernelen Fejlesztése jelenleg is folyik a MIK berkein belül DNS, DHCP és 3G UMTS

A wvdial futtatása (natív IPv6 3G) root@anemone-mnn2:/home/anemone# wvdial nokia6 --> WvDial: Internet dialer version 1.56 --> Cannot get information for serial port. --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: AT+CGDCONT=1,"IPV6","test6",,0,0 AT+CGDCONT=1,"IPV6","test6",,0,0 --> Modem initialized. --> Sending: ATDT*99# --> Waiting for carrier. ATDT*99# CONNECT ~[7f]}#@!}!} } }2}#}$@#}!}$}%\}"}&} }*} } g}%~ --> Carrier detected. Starting PPP immediately. --> Starting pppd at Mon Nov 3 11:58:30 2008 --> Pid of pppd: 6045 --> Using interface ppp0 --> Authentication (PAP) started --> Authentication (PAP) successful DNS, DHCP és 3G UMTS

A hoston létrejött ppp interfész root@anemone-mnn2:/home/anemone# ifconfig ppp0 Link encap:Point-to-Point Protocol inet6 addr: 2001:738:2001:20a9:1234:1234:1234:1234/64 Scope:Global inet6 addr: fe80::1234:1234:1234:1234/10 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:17 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:1304 (1.2 KiB) TX bytes:56 (56.0 b) DNS, DHCP és 3G UMTS

pppd logok: a 3G kapcsolat kiépítése anemone@anemone-mnn2:~$ tail -f 40 /var/log/syslog | grep pppd Nov 3 11:56:34 anemone-mnn2 pppd[6019]: pppd 2.4.4 started by anemone, uid 1000 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: using channel 2 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: Using interface ppp0 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: Connect: ppp0 <--> /dev/ttyACM0 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc637ee9c> <accomp>] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: rcvd [LCP ConfRej id=0x1 <magic 0xc637ee9c> <accomp>] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: sent [LCP ConfReq id=0x2 <asyncmap 0x0>] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [PAP AuthReq id=0x1 user="a" password=<hidden>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [PAP AuthAck id=0x1 ""] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: PAP authentication succeeded Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfReq id=0x1 <addr fe80::912c:e42a:efd0:fa10>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfReq id=0x0 <addr fe80::0000:0000:0000:0000>] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfNak id=0x0 <addr fe80::154c:bcf1:77d4:80e5>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfNak id=0x1 <addr fe80::1234:1234:1234:1234>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfReq id=0x2 <addr fe80::1234:1234:1234:1234>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::154c:bcf1:77d4:80e5>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfAck id=0x1 <addr fe80::154c:bcf1:77d4:80e5>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfAck id=0x2 <addr fe80::1234:1234:1234:1234>] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: local LL address fe80::1234:1234:1234:1234 Nov 3 11:56:36 anemone-mnn2 pppd[6019]: remote LL address fe80::154c:bcf1:77d4:80e5 Nov 3 11:56:36 anemone-mnn2 pppd[6019]: Script /etc/ppp/ipv6-up started (pid 6021) Nov 3 11:56:36 anemone-mnn2 pppd[6019]: Script /etc/ppp/ipv6-up finished (pid 6021), status = 0x0 DNS, DHCP és 3G UMTS

Forgalom a felépült GTP alagútban 68.707483 192.168.11.1 -> 192.168.100.5 GTP Create PDP context request 68.707542 192.168.100.5 -> 192.168.11.1 GTP Create PDP context response 70.312330 fe80::1234:1234:1234:1234 -> ff02::2 GTP <ICMPv6> Router solicitation 70.312816 fe80::3412:3412:1234:1234 -> ff02::1 GTP <ICMPv6> Router advertisement 70.566687 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 54017 > www [SYN] Seq=0 Len=0 MSS=1340 TSV=3983484125 TSER=0 WS=0 70.607518 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> www > 54017 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV=103039371 TSER=3983484125 70.770572 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 54017 > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV=3983676125 TSER=103039371 70.830538 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET / HTTP/1.1 70.923134 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] 70.923224 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] 71.432700 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 54017 > www [ACK] Seq=370 Ack=2657 Win=47808 Len=0 TSV=3984334625 TSER=103039403 71.474050 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] 71.474097 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 TCP [TCP segment of a reassembled PDU] 71.627840 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 46699 > www [SYN] Seq=0 Len=0 MSS=1340 TSV=3984539125 TSER=0 WS=0 71.668688 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> www > 46699 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV=103039478 TSER=3984539125 71.890942 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 54017 > www [ACK] Seq=370 Ack=4703 Win=48418 Len=0 TSV=3984794125 TSER=103039458 71.907932 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> 46699 > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV=3984812875 TSER=103039478 72.010624 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /ipv6.org.css HTTP/1.1 72.052547 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] 72.052681 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 HTTP HTTP/1.1 200 OK (text/css) 72.070341 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /IPv6-logo.png HTTP/1.1 DNS, DHCP és 3G UMTS

Bokor László BME-HT goodzi@mcl.hu Köszönöm a figyelmet! Bokor László BME-HT goodzi@mcl.hu