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.

Az előadások a következő témára: "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."— Előadás másolata:

1 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

2 Á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

3 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. 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

4 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

5 Példa HOSTS fájlra mik:/home/goodzi# cat /etc/hosts
localhost mail oxserver samba.mik.bme.hu MIK 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

6 DNS információ lekérése - dig
mik:/home/goodzi# dig ; <<>> DiG P3 <<>> ;; 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: ; IN A ;; ANSWER SECTION: IN A ;; AUTHORITY SECTION: hu IN NS NS2.NIC.FR. hu IN NS NS1.NIC.hu. hu IN NS NS-COM.NIC.hu. hu IN NS NS3.NIC.hu. hu IN NS NS-SE.NIC.hu. hu IN NS NS2.NIC.hu. hu IN NS NS.NIC.hu. ;; ADDITIONAL SECTION: NS2.NIC.FR IN A NS1.NIC.hu IN A NS-COM.NIC.hu IN A NS3.NIC.hu IN A NS-SE.NIC.hu IN A NS2.NIC.hu IN A NS.NIC.hu IN A NS2.NIC.FR IN AAAA :660:3005:1::1:2 ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Wed Mar 17 14:40: ;; MSG SIZE rcvd: 326 DNS, DHCP és 3G UMTS

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

8 Inverz lekérés – dig -x DNS, DHCP és 3G UMTS
mail:/home/goodzi# dig -x ; <<>> DiG P3 <<>> -x ;; 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: ; in-addr.arpa. IN PTR ;; ANSWER SECTION: in-addr.arpa IN PTR sportgeza.hu. ;; AUTHORITY SECTION: in-addr.arpa IN NS ns.index.hu. in-addr.arpa IN NS ns.inventra.hu. ;; ADDITIONAL SECTION: ns.index.hu IN A ns.inventra.hu IN A ;; Query time: 72 msec ;; SERVER: #53( ) ;; WHEN: Wed Mar 17 14:42: ;; MSG SIZE rcvd: 177 DNS, DHCP és 3G UMTS

9 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

10 DNS beállítások a kliens gépen
mik:/home/goodzi# cat /etc/resolv.conf domain bme.hu search hit.bme.hu nameserver nameserver nameserver 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

11 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

12 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

13 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

14 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

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

16 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

17 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 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

18 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. ( H 3H 7D 600 ) NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. MX mail MX www2 kamu NS backup.mik.bme.hu. exchange NS exchangeserver.mik.bme.hu. @ A ns A mail A gallery A qoe A opensbc A calendar A location A samba A wlan A www A home A home AAAA :738:2001:20a0:216:35ff:fe04:f76c test A ibm A ibm A gep A gep A wlan A wlan A DNS, DHCP és 3G UMTS

19 Példa IPv4-es névkeresési zónafájlra
mik:/home/goodzi# cat /etc/bind/master/ in-addr.arpa $TTL in-addr.arpa. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( ;Serial number ;Refresh ;Retry ;Expire 86400) ;Minimum TTL NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. IN PTR ns0.mik.bme.hu. IN PTR miksolaris.mik.bme.hu. IN PTR ibm1.mik.bme.hu. IN PTR ibm2.mik.bme.hu. IN PTR gep4.mik.bme.hu. IN PTR gep5.mik.bme.hu. IN PTR wlan1.mik.bme.hu. IN PTR wlan2.mik.bme.hu. IN PTR wlan3.mik.bme.hu. IN PTR wlan4.mik.bme.hu. IN PTR wlan5.mik.bme.hu. IN PTR switch1.mik.bme.hu. IN PTR switch2.mik.bme.hu. IN PTR switch3.mik.bme.hu. IN PTR switch4.mik.bme.hu. IN PTR switch5.mik.bme.hu. IN PTR gep16.mik.bme.hu. DNS, DHCP és 3G UMTS

20 Példa IPv6-os névkeresési zónafájlra
mik:/home/goodzi# cat /etc/bind/master/ IP6.ARPA $TTL IP6.ARPA. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( ;Serial number ;Refresh ;Retry ;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 IN PTR ns.mik.bme.hu. 1.c e.f.f.f.d.5.b IN PTR mnn1-eth.anemone.mik.bme.hu. IN PTR gw.anemone.mik.bme.hu. a.2.e.f.f.f.f IN PTR sun-gw.anemone.mik.bme.hu. IN PTR sun-ha.anemone.mik.bme.hu. IN PTR mr1-hoa.anemone.mik.bme.hu. IN PTR pc1.anemone.mik.bme.hu. DNS, DHCP és 3G UMTS

21 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

22 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 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

23 DHCPv4 használata a kliens gépen
mik:/home/goodzi#dhclient eth2 Internet Systems Consortium DHCP Client V3.0.4 Copyright Internet Systems Consortium. All rights reserved. For info, please visit 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 port 67 interval 4 DHCPOFFER from DHCPREQUEST on eth2 to port 67 DHCPACK from bound to renewal in seconds. mik:/home/goodzi#tshark -i eth2 > DHCP DHCP Request - Transaction ID 0xf > DHCP DHCP ACK Transaction ID 0xf DNS, DHCP és 3G UMTS

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

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

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

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

28 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

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

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

31 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

32 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

33 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

34 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

35 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

36 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 ( ) 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

37 AT parancsok kiadása: wvdial
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 = Stupid mode = 1 DNS, DHCP és 3G UMTS

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

39 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, V firmware GGSN (APN=test, IPv4) Cisco 7206, IOS 12.4 c7200-adventerprisek9_mw-mz 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, as kernelen Fejlesztése jelenleg is folyik a MIK berkein belül DNS, DHCP és 3G UMTS

40 A wvdial futtatása (natív IPv6 3G)
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 } }*} } g}%~ --> Carrier detected. Starting PPP immediately. --> Starting pppd at Mon Nov 3 11:58: --> Pid of pppd: 6045 --> Using interface ppp0 --> Authentication (PAP) started --> Authentication (PAP) successful DNS, DHCP és 3G UMTS

41 A hoston létrejött ppp interfész
ifconfig ppp 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

42 pppd logok: a 3G kapcsolat kiépítése
tail -f 40 /var/log/syslog | grep pppd Nov 3 11:56:34 anemone-mnn2 pppd[6019]: pppd 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

43 Forgalom a felépült GTP alagútban
> GTP Create PDP context request > GTP Create PDP context response fe80::1234:1234:1234:1234 -> ff02:: GTP <ICMPv6> Router solicitation fe80::3412:3412:1234:1234 -> ff02:: GTP <ICMPv6> Router advertisement :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [SYN] Seq=0 Len=0 MSS=1340 TSV= TSER=0 WS=0 :6b0:1:ea:202:a5ff:fecd:13a6 -> :738:2001:20a9:1234:1234:1234:1234 GTP <TCP> www > [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET / HTTP/1.1 :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [ACK] Seq=370 Ack=2657 Win=47808 Len=0 TSV= TSER= :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 TCP [TCP segment of a reassembled PDU] :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [SYN] Seq=0 Len=0 MSS=1340 TSV= TSER=0 WS=0 :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> www > [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [ACK] Seq=370 Ack=4703 Win=48418 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP <TCP> > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /ipv6.org.css HTTP/1.1 :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP <TCP> [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 HTTP HTTP/ OK (text/css) :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

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