Lencse Gbor, Rps Sndor, Arat Andrs

IPv6
S BEVEZETST TMOGAT
TECHNOLGIK
1. kiads

HunNet-Mdia Kft.
Budapest, 2015

IPv6 s bevezetst tmogat technolgik

Szerzk:

Dr. Lencse Gbor

egyetemi docens, PhD
Rps Sndor
okleveles villamosmrnk,
Certified Cisco Systems Instructor (CCSI#34630),
Microsoft Certified Trainer (MCT),
MikroTik Certified Inter-networking Engineer (MTCINE)
Arat Andrs
okleveles mrnk-informatikus,
Cisco Certified Internetwork Expert (CCIE#3297)

Lektorlta: Dr. Almsi Bla

egyetemi docens, PhD

Dr. Lencse Gbor, Rps Sndor, Arat Andrs, 2015.

A knyv a Creative Commons Attribution-ShareAlike (CC-BY-SA) 3.0 licenc alatt hasznlhat, terjeszthet. https://creativecommons.org/licenses/by-sa/3.0/
A knyv megrsa sorn a szerzk igyekeztek a lehet legpontosabb informcit nyjtani,
de a knyvben szerepl hibkrt, tvedsekrt, valamint az azokbl ered esetleges krokrt
semmilyen felelssget nem vllalnak.
A knyv jabb verzijnak kiadsrl tjkoztatst adunk, valamint a knyvvel kapcsolatos
szrevteleket, hibabejelentseket ksznettel fogadunk: http://ipv6ready.hu/konyv/.
ISBN: 978-963-12-3272-1
DOI: 10.18660/ipv6-b1.2015.9.1
Kiadja a HunNet-Mdia Kft. 1132 Budapest, Victor Hug utca 18-22. Felels kiad a
Kft. mindenkori gyvezetje.

Tartalomjegyzk
1.

Bevezets ..................................................................................................... 6

2.

IPv6 alapok .................................................................................................. 7

2.1. IPv6 cmek ................................................................................................................... 7
2.1.1. IPv6 cmek rsa .......................................................................................................... 7
2.1.2. Az IPv6 cmzsi architektrja.................................................................................. 8
2.2. Az IPv6 datagram felptse .................................................................................... 14
2.2.1. Az IPv6 fejrsz kiterjesztse .................................................................................... 15
2.3. Internet Control Message Protocol version 6 (ICMPv6) ................................... 17
2.4. A Neighbor Discovery Protocol (NDP) ............................................................... 18
2.4.1. llapotmentes automatikus cmkonfigurci ....................................................... 18
2.4.2. IPv6-cm egyedisgnek ellenrzse ...................................................................... 19
2.4.3. Cmfelolds................................................................................................................. 20
2.5. Multicast Listener Discovery (MLD) ..................................................................... 20
2.6. Path MTU discovery (PMTUD) ............................................................................. 22
2.7. Domain Name System ............................................................................................. 23
2.7.1. IPv6 nvfelolds ........................................................................................................ 23
2.7.2. IPv6 reverz nvfelolds ............................................................................................ 23
2.8. IPv6 cmkioszts........................................................................................................ 24
2.8.1. RIPE adminisztrci................................................................................................. 24
2.8.2. RIPE NCC adatbzis ................................................................................................ 26
2.8.3. Ajnlsok .................................................................................................................... 28

3.

tvlaszts..................................................................................................30
3.1. OSPFv3 ...................................................................................................................... 30
3.1.1. OSPFv2 s OSPFv3 sszehasonltsa ................................................................... 30
3.1.2. OSPFv3 mkdse ................................................................................................... 31
3.2. BGP-MP ..................................................................................................................... 35
3.2.1. BGP alapok ................................................................................................................ 35
3.2.2. BGP kapcsolat kialaktsa ........................................................................................ 36
3.2.3. BGP kommunikci ................................................................................................. 37
3.3. PIM-SM ...................................................................................................................... 42
3.3.1. Bevezet ..................................................................................................................... 42
3.3.2. A PIM-SM mkdse ............................................................................................... 43
3.3.3. A PIM-SM hibatrse............................................................................................... 45
3.4. Linux rendszerek konfigurlsa .............................................................................. 46
3.4.1. Alapbelltsok ........................................................................................................... 46
3.4.2. ip6tables ...................................................................................................................... 50
3.4.3. Automatikus IPv6 cmkioszts ............................................................................... 50
3.4.4. BIND .......................................................................................................................... 55
3.5. Cisco IOS alap eszkzk konfigurlsa ..............................................................56
3.5.1. IPv6 Konfigurci .................................................................................................... 58

3.5.2. Biztonsgi belltsok ............................................................................................... 61

3.5.3. OSPFv3 ...................................................................................................................... 62
3.5.4. OSPFv3 biztonsgi belltsok................................................................................ 67
3.5.5. IPv6 MP-BGP ........................................................................................................... 69
3.6. MikroTik tvlasztk konfigurlsa ....................................................................... 79
3.6.1. Alapbelltsok ........................................................................................................... 79
3.6.2. Az ipv6 firewall.......................................................................................................... 80
3.6.3. Automatikus IPv6 cmkioszts ............................................................................... 81
3.6.4. OSPFv3 ...................................................................................................................... 82
3.6.5. IPv6 BGP ................................................................................................................... 83
3.6.6. IPv6 PPPOE szerver belltsa ............................................................................... 85
3.6.7. IPv6 PPP kliens belltsa ........................................................................................ 85
4.

IPv6 ttrsi technolgik sszehasonlt elemzse..................................87

4.1. ltalnos ttekints ................................................................................................... 87
4.1.1. Az IPv4-rl IPv6-ra val ttrs idbeli lezajlsa ................................................ 87
4.1.2. Az IPv4 s IPv6 alap rendszerek egyttmkdsnek fontosabb esetei ....... 87
4.2. Emlkeztet az IP-cmek megosztsrl............................................................... 88
4.2.1. A cmfordtst hasznl megolds.......................................................................... 88
4.2.2. Az Address plus Port (A+P) megolds .................................................................91
4.3. A DNS64 + NAT64 megolds ............................................................................... 91
4.3.1. A megolds elvi mkdse ...................................................................................... 91
4.3.2. Az IPv4-cmeket begyaz IPv6-cmekrl ............................................................ 93
4.3.3. A megolds lettartama ............................................................................................ 94
4.4. A MAP megolds s vltozatai ............................................................................... 94
4.5. A DNS46+NAT46 megolds ................................................................................. 95
4.6. A 6to4 megolds........................................................................................................ 95
4.6.1. A 6to4 cmzse .......................................................................................................... 95
4.6.2. A 6to4 megolds mkdse .................................................................................... 96
4.6.3. A 6to4 megolds lettartama ................................................................................... 98
4.6.4. A 6to4 megolds problmi..................................................................................... 98
4.6.5. A 6to4 tovbbfejlesztsei ..................................................................................... 99
4.7. A 6in4 megolds ......................................................................................................100
4.8. Az MPT tunnel ........................................................................................................100
4.9. Tovbbi ajnlott forrsok ......................................................................................101

5.

IPv6 ttrsi technolgik vizsglata ....................................................... 102

5.1. ltalnos ttekints .................................................................................................102
5.1.1. Vizsglati szempontok............................................................................................102
5.1.2. Kivlasztsi szempontok ........................................................................................102
5.1.3. Vizsglati szempontok technolginknt ............................................................103
5.2. A NAT64 technolgia kompatibilitsa ................................................................104
5.2.1. Ms kutatk eredmnyei ........................................................................................104
5.2.2. A vizsglatainkhoz hasznlt NAT64 implementcik ......................................105
5.2.3. A megvizsglt alkalmazsok ..................................................................................105

5.2.4. Vizsglatok s eredmnyek ....................................................................................105

5.3. A NAT64 technolgia portszm fogyasztsa .....................................................110
5.3.1. Ms kutatk eredmnyei: ami van, s ami kellene .............................................110
5.3.2. Web bngszs portszm fogyasztsnak vizsglata .........................................111
5.3.3. FTP s tovbbi alkalmazsok portszm fogyasztsnak vizsglata .................116
5.3.4. Tovbbi alkalmazsok portszm fogyasztsa .....................................................118
5.3.5. A globlis web forgalom portszm fogyasztsnak becslse ...........................118
5.4. NAT64 implementcik stabilitsa s teljestmnye .........................................123
5.4.1. Korbbi tudomnyos eredmnyek .......................................................................123
5.4.2. NAT64 tjrk teljestmnynek s stabilitsnak vizsglata ...........................124
5.5. DNS64 implementcik stabilitsa s teljestmnye..........................................128
5.5.1. A megvizsglt DNS64 implementcik...............................................................128
5.5.2. A tesztkrnyezet ......................................................................................................129
5.5.3. A DNS64 teljestmnymrs mdszere ...............................................................130
5.5.4. A DNS64 mrsek eredmnyei .............................................................................131
5.6. A TOTD DNS64 implementci stabilitsi s biztonsgi krdsei ................133
5.6.1. A programozsi hiba s kijavtsa.........................................................................133
5.6.2. A biztonsgi rs s annak kijavtsa......................................................................134
5.7. 6to4 implementcik stabilitsa s teljestmnye ...............................................136
5.7.1. Ms kutatk eredmnyei ........................................................................................136
5.7.2. A teszt krnyezet .....................................................................................................137
5.7.3. A 6to4 mrsi mdszer ..........................................................................................138
5.7.4. A 6to4 mrsek eredmnyei ..................................................................................140
5.8. Az MPT knyvtr teljestkpessge ...................................................................141
6.

Irodalomjegyzk ....................................................................................... 143

1. Bevezets
Br az internet protokoll 6-os verzijt (IPv6) mr 1998-ban definiltk (RFC 2460), ltalnos
elterjedse az egsz vilgon, gy haznkban is sokig ksett, s csak a publikus IPv4 cmtartomny
kimerlsvel vlt halaszthatatlann. Az IP j verzijra val zkkenmentes s mielbbi ttrs
megkveteli, hogy a hlzatokkal foglalkoz szakemberek birtokban legyenek a szksges ismereteknek. Ez nem pusztn az IPv6 protokoll ismerett jelenti, hanem a kt protokoll egyttmkdshez szksges klnfle n. IPv6 ttrsi technolgik (IPv6 transition technologies) s azok
klnfle implementciinak alapos ismerett is. Nem tudunk olyan magyar nyelv szakknyvrl,
ami ezt a tmt kell mlysgben trgyaln; clunk ennek a hinynak a betltse. Munknkkal gyakorlati szakemberek, egyetemi hallgatk, oktatk s kutatk szmra egyarnt segtsget szeretnnk
nyjtani. Az olvasrl felttelezzk, hogy birtokban van az alapvet szmtgp-hlzati ismereteknek, belertve mind a TCP/IP protokollcsald (TCP/IP protocol stack), mind a hordozhlzatknt hasznlt klnfle fizikai/adatkapcsolati szint hlzati megvalstsok ismerett1.
Az IPv6 tmakrben az alapoktl indulunk, bemutatjuk az IPv6 cmzst, az IPv6 datagram szerkezett s az IPv6 protokoll mkdst, fokozott figyelmet szentelve az IPv4-tl eltr megoldsoknak (pl. ARP helyett NDP). Az elmlet mellett gyakorlati pldkkal illusztrljuk az egyes megoldsok belltst, hasznlatt, tesztelst. Kln fejezetben foglalkozunk az tvlaszts krdseivel.
Az ttrsi technolgik kzl azokat trgyaljuk rszletesen, amelyeket jelenleg fontosnak, elremutatnak tartunk. Nhny ttrsi technolgia ltalunk kivlasztott implementciival kapcsolatban bemutatjuk sajt kutatsi eredmnyeinket is. Remljk, hogy ezek hasznosak lesznek mind a
gyakorlati szakemberek szmra (segtenek a megfelel technolgia s implementci kivlasztsban), mind az akadmiai szfra rsztvevinek (tovbbi kutatsokra motivlnak). Br a knyv terjedelmnek jelents rszt a kutatsi eredmnyeink bemutatsa teszi ki, hangslyozzuk, hogy ez
messze nem teljes; szmos problma vizsglatra van mg szksg, melyre ezton is keresnk
egyttmkd partnereket.
Ksznetnket fejezzk ki a knyv hivatalos lektornak, Almsi Blnak a kzirat tolvassban,
javtsban vgzett alapos munkjrt, valamint mindenkinek, aki a brlati pldnyt tolvasta, s
hibkat jelzett, klnsen Varga Gyrgynek, akitl szmos hibajavtst, javaslatot kaptunk.
Munknknak ez az els kiadsa, amit szeretnnk a tovbbiakban folytatni, bvteni. A knyv jabb
kiadsrl tjkoztatst adunk, valamint a knyvvel kapcsolatos szrevteleket, hibabejelentseket
ksznettel fogadunk: http://ipv6ready.hu/konyv/.
Remljk, hogy munknk hozzjrul az IPv6 mielbbi magyarorszgi elterjedshez.
Lencse Gbor, Rps Sndor, Arat Andrs

1 Ha valaki ezen a tren szeretn a tudst kiegszteni, akkor az id- s kltsghatkony egyetemi jegyezettl [1] a vaskos
angol nyelv knyvek magyar fordtsig [2] s [3] szles palettrl vlogathat.

2. IPv6 alapok
2.1. IPv6 cmek
Az IPv6 protokoll egyik legszembetnbb eltrse az IPv4-hez kpest a cmek mrete. Az IPv6
128 bites cmeket hasznl, gy mg a cmtartomny nem hatkony felhasznlsa esetn is hossz
idre elegend cmet biztost a vrhat s az elre nem lthat feladatokra.

2.1.1. IPv6 cmek rsa

Rugalmas formtum
Az IPv6 cmek szveges lersban az RFC 4291 meglehetsen rugalmas, a felhasznlnak szmos
lehetsget nyjt az egyszerstsre, de ezeket nem teszi ktelezv. Az IPv6 cm 128 bitjt 16 bites
csoportonknt ngy hexadecimlis jeggyel rjuk, a csoportokat kettsponttal vlasztjuk el egymstl.
A csoportok elejn a nullk mindig elhagyhatk. gy amennyiben egy 16 bites csoportban ngy nulla
ll egyms utn, azt mindig helyettesthetjk egy nullval. Ha egyms utni 16 bites csoportok csak
nullkat tartalmaznak, az sszes ilyen csoportot helyettesthetjk dupla kettsponttal (::), de ez
csak egyszer alkalmazhat, hogy a dekdols egyrtelm legyen. Lssunk egy pldt:
2001:0DB8:0000:00AE:0000:0000:0000:ABCD

2001:DB8:0:AE:0:0:0:ABCD

2001:DB8:0:AE::ABCD
Amennyiben egy IPv6 cmet IPv4 cmbl kpeztnk, s az IPv6 cm az IPv4 cmet az utols 32
bitjn tartalmazza, akkor az IPv4 cmet tartalmaz rszt rhatjuk az IPv4 kanonikus formtumban
is, pldul a 64:FF9B::C000:20A cm rhat gy is, hogy: 64:FF9B::192.0.2.10.
A hexadecimlis szmjegyekben szerepl betkkel kapcsolatban sincs megkts, hogy kis- vagy
nagybetk legyenek, a pldkban RFC 4291 nagybetket hasznl.
Gyakran van szksg egy IPv6 cm els n bitjnek a megadsra, amit n mret eltagnak (prefix)
neveznk s az eltag utn /n megadsval jellnk. Fontos, hogy prefix rsakor az utols olyan
16 bites csoportot, ami nem csupa 0-t tartalmaz, mindig vgig ki kell rni.
Plda: 2001:DB8:AB00::/40 a helyes rsmd, mert ha 2001:DB8:AB::/40-et rnnk, az azt jelenten, hogy: 2001:0DB8:00AB::/40, ami pedig valjban: 2001:0DB8::/40.
A dupla kettspont hasznlatval prefixeknl klnsen krltekinten kell bnni, pldul a
2001:DB8:0:A::/64 nem rvidthet tovbb gy, hogy 2001:DB8::A/64, mert az teljesen mst jelent, konkrtan azt, hogy: 2001:DB8:0:0:0:0:0:A/64.
Az RFC 3986 definilja az IPv6 cmek hasznlatt URL-ekben. Pldk:
http://[2001:DB8:FFFF:FFFF::192.224.128.1]:8080/index.html
ftp://[2001:DB8:2C01:8000::15]

Kanonikus formtum
Az RFC 4291 rugalmassga nagyon knyelmes, gy egy IPv6 cmnek sokfle rsmdja lehetsges
attl fggen, hogy a felhasznl mely lehetsgekkel kvn lni, s melyekkel nem. Azonban az
RFC 5952 lerja, hogy ez a szabadsg szmos esetben problmkat okozhat a gyakorlatban. Pldul
gondoljuk arra, hogy egy naplfjlban a 2001:db8::a:0:0:1 cmet szeretnnk megkeresni, mikzben
az olyan formban szerepel benne, hogy: 2001:0DB8:0:0:A::1. A problma megoldsra bevezetik
az IPv6 cmek szveges rsnak kanonikus formjt azzal, hogy egy program bemenetknt minden
7

olyan cmet kteles (MUST) elfogadni, amit RFC 4291 megenged, de kimenetn ersen ajnlott
(SHOULD) a kanonikus forma hasznlata. Tovbb azt tancsoljk, hogy az IPv6 cmek lersakor
mi emberek is hasznljuk a kanonikus formt. Ennek szablyai a kvetkezk:
Az egyes 16 bites csoportokban a vezet nullkat el kell (MUST) hagyni.
A dupla kettspontot a maximlis kapacitsig ki kell (MUST) hasznlni.
A duplakettspontot tilos (MOST NOT) egyetlen 16 bites csoport rvidtsre hasznlni.
Amennyiben tbb csupa nulls csoport van, akkor a leghosszabbat, ha pedig a csoportok
hossza egyenl, akkor balrl jobbra haladva az elst kell (MUST) dupla kettsponttal
helyettesteni.
Hexadecimlis szmokban kisbetket kell (MUST) hasznlni.
Ebben a knyvben a tovbbiakban treksznk a fentiek betartsra, de cmekben (vagy defincis
cmkkben) szndkosan csupa nagybett hasznlunk, s mshonnan tvett anyagokat (pl. brk,
RFC rszletek) sem mdostunk.

2.1.2. Az IPv6 cmzsi architektrja

Az IPv6 cmtartomny klnfle clokra val felosztst prefixek segtsgvel lehet megadni. A
kvetkez fbb kategrikat definiltk (RFC 4291):
Cm tpusa
---------Unspecified
Loopback
Multicast
Link-Local unicast
Global Unicast

Binris prefix
------------00...0 (128 bit)
00...1 (128 bit)
11111111
1111111010
(minden ms, ami nem

IPv6 jellssel
------------::/128
::1/128
FF00::/8
FE80::/10
specilis)

A kvetkezkben az egyes kategrikat rszletesen megvizsgljuk.

Specilis IPv6 cmek/prefixek

Az albbi kt cmet minden host hasznlja:
::/128 Unspecified Address
Meghatrozatlan cm, akkor hasznljuk, amikor egy host inicializlja magt.
::1/128 Loopback Address
A 127.0.0.1 IPv4 loopback cmhez hasonlan hasznlt loopback cm.
FF00::/8 Multicast Address
Az IPv4-ben broadcastnak s multicastnak nevezett funkcik megvalstsra egyarnt hasznlt
cmtartomny. Rszletesen foglalkozunk vele.
FE80::/10 Link-Local IPv6 Unicast Addresses
Olyan cmek, amik csak egy adott fizikai linken rvnyesek, pldul egy Ethernet szegmensen. Az
ilyen forrscmmel rendelkez IPv6 csomagokat az tvlasztk (routerek) nem tovbbtjk. Olyan
esetekben hasznljuk, amikor pldul egy IPv6 hlzatban nincs router, vagy Neighbour Discovery
(lsd ksbb) esetn. Minden hlzati interfszhez ktelezen tartozik ilyen cm. Amikor ilyen cmet hasznlunk egy programban forrscmknt, akkor ktelezen meg kell adni, hogy melyik interfszen menjen ki a csomag (hiszen a link-loklis cmbl nem derl ki).
8

FEC0::/10 Site-Local IPv6 Unicast Addresses RVNYTELEN!

Ez a tartomny ma mr nem hasznlt, rvnytelentett. Eredetileg az egy adott site krzetn belli
cmzsre definiltk (mint IPv4-nl az RFC 1918 szerinti loklis cmeket), de a site fogalmnak
nehz meghatrozhatsga miatt mr nem hasznlatos, lsd: RFC 3879.2
FC00::/7 Unique Local IPv6 Unicast Adresses
Az RFC 4193 definilja. Az egyedi loklis cmek (a tovbbiakban ULA) hasznlatval olyan helyeken
is lehet IPv6-ot hasznlni, ahol nincs hivatalosan kiosztott IPv6 prefix, azaz felhasznlsuk clja
teljesen hasonl az RFC 1918-ban meghatrozott privt IPv4 cmekhez. Nagy klnbsg azonban,
hogy az ilyen cmeknl a hlzatcm (Network ID) meghatrozshoz egy lvletlen (pseudo-random)
szmot hasznlunk, amit az RFC-ben megadott mdon lehet ellltani. Tbb szervezeti egysg is
generlhat gy magnak cmet, s a pseudo-random algoritmusnak ksznheten nagyon kicsi valsznsggel fognak ezek a cmek tkzni. (Segtsgkkel teht sikerlt kikszblni az rvnytelentett site-local unicast cmek hibit.)
Felptsk az albbi:
| 7 bits |1| 40 bits
| 16 bits |
64 bits
|
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID |
Interface ID
|
+--------+-+------------+-----------+----------------------------+

Ahol:

Prefix: fc00::/7
L: ktelezen 1 rtk
Global ID: vletlenszeren vlasztott, igen j esllyel globlisan egyedi3
Subnet ID: a hlzatcm hasznlja osztja ki a hlzatainak
Interface ID: a hlzati interfsz 64 bites azonostja, lsd ksbb

Az IPv4-rl IPv6-ra val tlls (IPv6 transition) tmogatsra szntk az albbi IPv6 cmtpusokat
azzal a cllal, hogy IPv6 hlzatokban IPv4 cmeket reprezentljanak:
::/96 IPv4-Compatible IPv6 Addresses RVNYTELEN!
IPv6 hlzatokban az x.y.z.w IPv4 cmet reprezentlta volna a kvetkez alakban: ::x.y.z.w (az
elejn 96 db 0 rtk bit volt). Eredetileg az IPv4 IPv6 tmenethez val felhasznlsra szntk,
de mr ms megoldst (lsd kvetkez) talltak ki, ezrt rvnytelentettk.
::FFFF:0:0/96 IPv4-Mapped IPv6 Addresses (ez hasznlhat!)
IPv6 hlzatokban az x.y.z.w IPv4 cmet reprezentlja a kvetkez alakban: ::ffff:x.y.z.w (az elejn
80 db 0 rtk bit van). A korbbi ::x.y.z.w helyett azrt kellett msik, mert vltozott a mdszer,
amit az IPv4 IPv6 tmenethez szeretnnek alkalmazni.

2 Az RFC azt is lerja, hogy a msik problma, ami IPv4-nl is eljtt, az az, hogy a loklis(nak sznt) IP-cmekkel rendelkez datagramok esetenknt mgis kiszivrognak, ilyenkor aztn mindenfle gondot okoznak, radsul mg azt sem lehet
megtallni, hogy honnan jttek.
3 Megjegyzs: ltezik olyan szolglats (https://www.sixxs.net/tools/grh/ula/), ahol generlnak szmunkra ULA IPv6
cmet, s be is lehet azt jegyeztetni, de mivel hasznlata nem ktelez, ezrt semmilyen garancit sem nyjt a cm egyedisgre.

Megjegyzs: a fenti prefix vgn szksges volt kirni a kt darab 16 bites (csupa 0 rtk) csoportot jell :0:0 rszt, mert a ::ffff/96 jellsnl a 16 darab 1 rtk bit a 128 bites IPv6 cm
legals 16 bitjnek a helyre kerl. (Lsd az RFC 6890 hibajegyzkben a 2. bejegyzst.)
Hlzati alkalmazsok ksztse esetn ennek a cmtpusnak a hasznlatval lehetsges az, hogy
egyetlen socketet hasznljunk mind IPv6, mint IPv4 kommunikcira. Ilyenkor elegend a socket
kezel fggvnyeknek csak az IPv6-os verzijt hasznlni. Ha IPv4-mapped IPv6 cmeket adunk
meg, akkor a (Linux) kernel IPv4-es csomagokat kld ki, illetve ha az alkalmazs ltal figyelt portra
IPv4 csomag rkezik, akkor ilyen IPv6 cmekkel kapja meg az alkalmazs a csomagot. Ezzel a megoldssal igen jelents mennyisg programozsi munkt takarthatunk meg.
2001:DB8::/32 IPv6 szabvnyos dokumentcis prefix
Annak rdekben, hogy a dokumentcikban szerepl pldk ne okozzanak zavart (a fejekben)
vagy mkd rendszerekkel val tkzst, lefoglaltak egy globlis unicast prefixet kifejezetten dokumentcis clra. Ez a 2001:db8::/32 (RFC 3849). Ezt a prefixet soha senkinek sem fogjk kiosztani s nem is routoljk. De termszetesen ettl mg nem szmt loklis unicast prefixnek!
(gy ha egy pldban ezt a prefixet hasznljk, s valaki a pldt sz szerint begpeli, az nem fog
krt okozni, mert a prefixet a vals letben soha semmire nem hasznljuk. A prefixet helyi hlzatokban is kiszrhetik; ezrt senki ne szmtson r, hogy mkdni fog, ha hasznlni prbln!)
Megjegyzs: IPv4-nl is vannak ilyenek, az RFC 5737 szerint: 192.0.2.0/24, 198.51.100.0/24,
203.0.113.0/24.
A specilis cl IPv4 s IPv6 cmekrl sszefoglal tallhat: RFC 6890

Az IPv6 multicast cmzse

Fontos, hogy IPv6-ban az IPv4-gyel ellenttben broadcast cm nincs. Multicast cmzsre az
ff00::/8 tartomny hasznlhat. A multicast cmek felptse az albbi:
bitek szma

mez neve

prefix

112

flags scope

group ID

Az egyes mezk jelentse:

prefix: a cm csoportcm voltt jelz eltag, rtke: ff
flags: ebben a mezben jelzbiteket definiltak: 0, R, P, T
scope: a cm rvnyessgnek a hatkrt fejezi ki (0-f)
group ID: az egyes multicast csoportok azonostsra hasznlhat bitek
A flags mezben tallhat jelzbitek rtelmezse:
0: fenntartott (reserved)
R: A csoporthoz tartoz randev pont (Rendezvous point) cme a csoportcmbe begyazott-e (RFC 3956), 1: igen, 0: nem.
P: A csoportcmet az azt ltrehoz szervezet hlzatnak eltagja (Prefix) alapjn generltk-e (RFC 3306), 1: igen, 0: nem.
T: A csoportcm dinamikus-e (Transient), 1: igen, 0: nem, azaz az IANA ltal kiosztott
well-known multicast address. Lsd: http://www.iana.org/assignments/ipv6-multicastaddresses/ipv6-multicast-addresses.xml
A csoportcmek rvnyessgi krt kifejez 4 bites scope mez lehetsges rtkei:
0: Reserved fenntartott
1: Interface-local multicast loopback tvitelre hasznlhat
10

 2: Link-Local hatkre a fizikai hlzat broadcast domainje

4: Admin-Local hatkre a lehet legkisebb rtelmes adminisztratv tartomny
5: Site-Local hatkre egy fizikai telephely
6-7: Unassigned a hlzati adminisztrtorok definilhatjk
8: Organization-Local egy szervezet sszes telephelyre kiterjed
9-D: Unassigned a hlzati adminisztrtorok definilhatjk
E: Global globlis
F: Reserved fenntartott
Az IANA ltal kiosztott nhny ltalnos cl csoportazonost (group ID):
FF02::1 link local all nodes az sszes eszkz az adott fizikai hlzaton (broadcast
domainben)
FF02::2 link local all routers minden tvlaszt a fenti krben
FF02::5 link local all OSPF routers minden OSPF tvlaszt a fenti krben
FF02::D link local all PIM routers minden PIM tvlaszt a fenti krben
FF02::16 link local all MLDv2 routers minden MLDv2 tvlaszt a fenti krben
FF05::2 site local all routers a telephely sszes tvlasztja
Vegyk szre, hogy az FF02::1 jelentse nem ms, mint IPv4 esetn az aktulis hlzatra vonatkoz broadcast cm! Megjegyzs: IPv4-ben is van ilyen csoportcm: 224.0.0.1
Vannak minden scope esetn rvnyes csoportazonostk is, pldul:
FF0x::C SSDP Az SSDP (Simple Service Discovery Protocol) ltal hasznlt IPv6
csoportcm. (IPv4 alatt a 239.255.255.250 csoportcmre szemetel az SSDP.)
Meg kell ismernnk mg egy fontos csoportcmet, amelyre ksbb fontos szerep hrul majd. Ez
a krdses eszkz (node) IPv6 cmnek felhasznlsval kpzett link-loklis hatkr solicited-node
multicast address. Ellltshoz az ff02:0:0:0:0:1:ff00::/104 prefixhez kell hozzrni a krdses node
IPv6 cmnek legkisebb helyirtk 24 bitjt. Pldul a 2001:db8::800:abba:edda IPv6 cmhez tartoz ilyen multicast cm: ff02:0:0:0:0:1:ffba:edda. Mivel egy eszkznek csatlakozni kell az sszes
IPv6 cmhez tartoz solicited-node multicast csoporthoz, a csoportcmnek az IPv6 cm utols 24
bitjbl val kpzse elnys lehet, ha az interfsz tbbfle prefix hasznlatval kpzett IPv6 cmmel is rendelkezik4, ugyanis ekkor csak egyetlen csoportrl van sz (amennyiben az IPv6 cmeinek
utols 64 bitjt a hlzati interfsz azonostjbl kpeztk). Azt pedig a ksbbiekben fogjuk ltni,
hogy egy adott multicast csoportban nem fognak tlsgosan sokan tartzkodni, st gyakran csak
egy hlzati interfsz tartozik bele (az sszes IPv6 cmvel).
Itt emltjk mg meg, hogy az IPv6 multicast Ethernet szinten a csoportcmben a 33:33 prefixet
hasznlja, utna pedig az IPv6 csoportcm utols 32 bitje kvetkezik. (Teht fentiek alapjn a
solicited node multicast address esetn az Ethernet csoportcm prefixe 33:33:ff lesz.)

Az IPv6 Anycast cmzse

Az IPv6 cmzsi arcitektrja hromfle cmtpust sorol fel: unicast, multicast s anycast. Az
anycast cmek szintaktikailag unicast cmek, csak a hasznlatuk mdja eltr. Mg unicast esetn
minden hlzati interfsz cme klnbz, addig anycast esetn ugyanazt a cmet tbb klnbz
szmtgp hlzati interfszhez is hozzrendelik. Egy anycast cmre kldtt csomagot az adott
anycast cmmel rendelkez interfszek kzl (a hlzatban hasznlt routing protokoll metrikja
szerint) a forrshoz legkzelebb tallhat interfsznek kzbestik. (Az anycast cmzst IPv4-nl is
alkalmazzk.)
4 Ami meglehetsen tipikus, hiszen egy interfsznek mindenkppen van egy link-loklis IPv6 cme, valamint clszeren
egy globlis (vagy legalbb egy ULA) IPv6 cme is. St egy interfsznek tbb globlis IPv6 cme is lehet.

11

Ismereteink rendszerezsre tekintsk most t a cmzsi mdszereket!

Unicast: A csomag pontosan egy ltalunk kivlasztott llomsnak szl.
Broadcast: A csomag (az adott hlzaton vagy tartomnyban) az sszes llomsnak szl.
Multicast: A csomag egy csoport sszes tagjnak szl.
Anycast: A csomag egy csoport tagjai kzl egynek szl, de nem a felad, hanem a hlzat dnti el, hogy melyik legyen az. Tipikus vlaszts, hogy legyen a kldhz legkzelebb es csoporttag.
Az egyes mdszerek mkdst illusztrlja az 1. bra.
Az anycast cmzs megvalstsa:
Ugyanazt az IP-cmtartomnyt (kznsges unicast cmek!) tbb helyen is alkalmazzk
s hirdetik az Interneten (BGP-vel). (Termszetesen akr egy szolgltat hlzatn bell
is alkalmazhat az Anycast cmzs.)
Az IP datagramok a legkzelebbi clhoz fognak megrkezni.
Az Anycast cmzs hasznlata a gyakorlatban:
DNS kiszolglk esetn: ugyanolyan nev (IP-cm) legfels szint nvkiszolgl a vilg
tbb pontjn is ltezik. A kliensek a legkzelebbit rik el.
Az IPv4-rl IPv6-ra val tlls (IPv6 transition) sorn hasznlt 6to4 megolds is ezt hasznlja a legkzelebbi 6to4 tjr elrsre.
Tartalomszolgltat hlzatok (CDN: Content Delivery Network) is alkalmazzk abbl a
clbl, hogy a kliens a legkzelebbi szerverrl tudja letlteni a mdiatartalmat.
Unicast:

Broadcast:

Multicast:

Anycast:

1. bra: Cmzsi mdszerek illusztrcija

12

Globlis Unicast cmek

Trtneti rdekessg: Mivel az IPv6 cmek 128 bitesek, kellen sok van bellk. Tervezskor nem
lttk elre, hogy milyen szempontok fognak felmerlni a cmek struktrjnak kialaktsval kapcsolatban. Kt szempont kellen logikusnak tnt:
tmogassuk a kettnl tbb szint struktrt
hagyjunk szabadsgot arra, hogy mi legyen a strukturlsi szempont
Termszetesen a tervezknek valamerre el kellett indulniuk, gy eredetileg definiltak pldul
olyan cmcsoportot, ahol fldrajzi alapon s olyat is, ahol szolgltatk szerint osztjk ki a hlzatokat. Akkor gy tnt, hogy ez jl szolglja az aggreglhatsgot, de aztn fellbrltk s megszntettk. Jelenleg inkbb a Regional Internet Registryknek (RIR) osztanak ki nagyobb tartomnyokat
s azok osztjk szt sajt hatskrben a krelmezknek.
Br jelenleg az IANA mg csak a 2000::/3 tartomnybl deleglt a RIR-eknek, ez elvileg semmiben sem klnbzik a tbbi globlis unicast IPv6 cmtartomnytl.
A jelenleg rvnyes szabvny az RFC 3587: IPv6 Global Unicast Address Format.
ltalnos felptsk:
|
n bits
|
m bits |
128-n-m bits
|
+-----------------------+-----------+----------------------------+
| global routing prefix | subnet ID |
interface ID
|
+-----------------------+-----------+----------------------------+

Ahol az egyes mezk:

global routing prefix: hierarchikus felpts, az aggregcirl a RIR-ek, LIR-ek s az
ISP-k gondoskodnak, a site-ok az ISP-ktl kapjk
subnet ID: hierarchikus felpts, az aggregcirl a site-ok adminisztrtorai gondoskodnak
Interface ID: a hlzati interfszt azonostja
Az IPv6 cmzsi architektrjt definil RFC 4291 szerint a 0000/3 tartomny kivtelvel az
Interface ID mrete 64 bit. gy felptsk az albbi:
|
n bits
| 64-n bits |
64 bits
|
+-----------------------+-----------+----------------------------+
| global routing prefix | subnet ID |
interface ID
|
+-----------------------+-----------+----------------------------+

Ha a jelenleg hasznlt 2000::/3 tartomnyban az egyes szervezetek a mr elavult (obsolete) RFC

3177 ltal ajnlott /48-as tartomnyokat kaptak, akkor a cmeik felptse a kvetkez:
| 3 |
45 bits
| 16 bits |
64 bits
|
+---+-------------------+-----------+----------------------------+
|001|global routing pre.| subnet ID |
interface ID
|
+---+-------------------+-----------+----------------------------+

Pldul a BME tartomnya is ilyen mret, a prefixe: 2001:738:2001::/48

A cmek szerkezett korbban az RFC 2374 rta le An IPv6 Aggregatable Global Unicast Address
Format cmmel. Errl fontos tudni, hogy elavult (obsolete), ezrt nem hasznljuk.

13

A cmallokci megfontolsai
Az elavult (obsolete) RFC 3177 szerint a site-ok szmra az alaprtelmezett allokcis egysg mrete a /48 volt. Az j irnyelvet az RFC 6177 IPv6 Address Assignment to End Sites fogalmazza
meg. Ezt rviden az albbiakban foglaljuk ssze:
Kis felhasznlknl nem szksges a pazarl /48 mret.
A /64 viszont nem elg, mert idvel tbb fizikai hlzatra lehet szksg.
Szempont a takarkossg is, de az is, hogy ksbb se legyen szksg NAT-ra (a site kapjon elegend cmet).
A reverse DNS felolds szempontjbl megfontoland a 4 bites hatrra val illeszkeds.
Megemlti az egyes RIR-ek gyakorlatt (/56-os mret), de alapelv, hogy nincs j alaprtelmezett mret.
Br a /128 bizonyos esetekben elfogadott, site esetn semmikppen sem javasolt.

2.2. Az IPv6 datagram felptse

Az IP 6-os verzijban a cmek mretnek nvekedse mellett a msik jelents vltozs a 4-es
verzihoz kpest az, hogy j nhny mez hinyzik. gy pldul a ktelez, fix fejrszbl teljesen
hinyoznak a trdelst szolgl mezk, a trdels lehetsgt a hlzati tvitel kzben teljesen meg
is szntettk (csak a forrs trdelhet, lsd a fejrsz kiterjesztseknl). Ugyancsak hinyzik az ellenrz sszeg, erre a mai tviteli megoldsok mellett nincs igazn szksg, s gy nem lasstja feleslegesen a routereket. A ktelez fejrsz hossza fix, gy annak hosszt sem kell megadni. Opcik ettl
mg lehetsgesek, ezt gyes trkkel oldottk meg (lsd: next header). Ennyi bevezet utn nzzk
meg egy, csak a ktelez fejrszt tartalmaz IPv6 datagram felptst (2. bra).
Az IPv6 datagram mezinek jelentse:
Version (4 bit) verziszm rtke termszetesen: 6, br rdemben nem hasznljuk,
lsd ksbb.
Traffic Class (8 bit) forgalmi osztly Az IPv4 Type of Service mez utdja. Az RFC
2474 szerinti Differentiated Services megoldst hasznljuk.
Flow Label (20 bit) folyamcmke Adott forrstl adott cl IP-cm (utbbi multicast
vagy anycast is lehet) fel irnyul forgalmon bell folyamok (flow) elklntst s kezelst hivatott tmogatni. Jelenleg rvnyes specifikcija: RFC 6437.
Payload Length (16 bit) adatmez hossza Mivel 16 bit hossz, gy rtke legfeljebb
65535 lehet. Az IPv4-gyel ellenttben itt a fejrsz 40 oktettje nem szmt bele, ezt fejezi
ki a neve is: hasznos teher hossza.
Next Header (8 bit) kvetkez fejrsz Megmutatja, hogy mit hordoz az IP cmek
utni rsz. Ez a mez egyrszt tartalmazhatja az IPv6 fltti protokoll tpusnak megadst (ilyen rtelemben az IPv4 Protocol mezjnek utdja), msrszt ezzel ki lehet terjeszteni a fejrszt, ahova tovbbi mezk kerlhetnek (ilyen rtelemben az IPv4 Options
mezjt is helyettesti). Ez utbbi esetben a f fejrsz (a cmekkel befejezd 40 oktett)
utn jn egy kvetkez fejrsz.
Hop Limit (8 bit) tugrs korlt Funkcija megfelel az IPv4 Time To Live mezjnek,
de az elnevezse jobban kifejezi a funkcijt, s a mrtkegysge sem msodperc (hanem
darab).
Source Address (128 bit) forrs IPv6-os cme Az IPv6 cmekkel mr rszletesen
foglalkoztunk.
Destination Address (128 bit) cl IPv6-os cme

14

2. bra: IPv6 datagram felptse

Megjegyzsek:
1. Elvileg a verziszmbl derlne ki, hogy az utna kvetkez mezket nem IPv4, hanem
IPv6 mezknek kell tekinteni. Gyakorlatilag nem gy trtnik, mert mr a hordozhlzatban (link layer) az IPv4-tl (0x0800) eltr EtherType protokoll azonostt hasznlnak
az IPv6-ra (0x86DD).
2. Egy folyam klasszikus defincija pldul a kvetkez t szmmal adhat meg: forrs s
cl IP-cmek, az IP fltti protokoll szma (TCP vagy UDP), valamint a forrs s cl
portszmok. A folyamcmke lehetsget ad arra, hogy a folyamot sokkal egyszerbben,
tisztn az IPv6 protokoll mezi alapjn azonostsuk. (Esetnkben a kt IP-cm s a folyamcmke egyrtelmen azonostjk a folyamot.)
3. Az adatmez hosszt alapesetben a 16 bites rtk ersen korltozza, de lehetsgnk van
gynevezett jumbogram kialaktsra is a Jumbo Payload option segtsgvel (RFC 2675).
Ez 64kB-nl jval nagyobb csomag is lehet, gy a routereknek nem kell 64kB adatonknt
a fejrszt feldolgozniuk, ezltal jelentsen gyorsulhat az adattvitel. Ugyanakkor a nagy
mret csomag sokig foglalja a linket, ami szolgltatsminsgi (QoS) problmkat vethet fel.

2.2.1. Az IPv6 fejrsz kiterjesztse

A fejrsz kiterjesztse nagyon szellemes megolds5: mivel a next header mez mrete 8 bit, s az
IP fltti protokollok szma messze elmarad a 8 biten kifejezhet 256-tl, ezrt j nhny rtket
5 Ugyanakkor szmos kockzattal is jr. Nveli az tvlasztk terhelst, problmt okozhat a tzfalaknl, klnfle
tmadsokra ad lehetsget, pldul az RFC 7113 2.1. pontjban is tallhat ilyen.

15

ms clra hasznlhatunk: ezekkel klnfle fejrsz kiterjesztseket adhatunk meg. Kzlk nhnyat mr az RFC 2460-ban definiltak:
Hop-by-Hop Options (0) Ha van ilyen, akkor ennek kell a legelsnek lennie. Amint
a nevbl is kiderl, ezt minden egyes routernek (hop) meg kell vizsglnia (mg az egyebeket ltalban csak a clnl).
Routing (43) Eredetileg a 0-s tpus vltozatt definiltk (Type mez rtke 0, rviden
RH0-nak is nevezik), ami az IPv4 Loose Source and Record Route opcijnak a megfelelje
volt, segtsgvel olyan csompontok IP-cmeit lehetett megadni, amin a csomagnak keresztl kell haladnia. Mivel ez kivl lehetsget nyjtott hlzati torldst elidz, tulajdonkppen szolgltatsmegtagads (Denial of Service, DoS) tpus tmadsra, ezrt rvnytelentettk (RFC 5095). Mobil IPv6-hoz a 2-es tpusa hasznlhat.
Fragment (44) Csomagok trdelsre lehet hasznlni, de erre IPv6-ban kizrlag a
forrsnl van lehetsg. A trdels megvalstsra hasznlt mezk teljesen hasonlak,
mint IPv4 esetn, mlyebben nem foglalkozunk vele.
Destination Options (60) Az ltala szlltott informcit csak a cl csompontban
kell megvizsglni. (Multicast esetn tbb cl is lehet.)
A fentieken tl mg kt fontos fejrszkiterjesztst emltnk meg:
Authentication (51) Az adatok eredett (origin) s vltozatlansgt (integrity) igazolja s
visszajtszs (replay) ellen is vd (RFC 4302).
Encapsulating Security Payload (50) Az adatok titkossgnak (confidentality), vltozatlansgnak (integrity) s (tttelesen) eredetnek (origin) vdelmre hasznlhat (RFC
4303).
Megjegyezzk, hogy az utols kettt hasznl IPsec (RFC 4301) eredetileg minden teljes IPv6
implementci ktelez (MUST) rsze volt, de az RFC 6434 ersen ajnlott (SHOULD) minstette
t azzal az indoklssal, hogy vannak ms megoldsok is (pldul TLS, SSH), s az IPsec nem minden
esetben az idelis megolds.
Az egyes opcik szerkezett, mkdst mlyebben nem vizsgljuk, annyit jegyznk meg rluk,
hogy sorrendjk (kzeltleg) kttt, mretk oktettben kifejezve mindig 8-cal oszthat, s az els
oktettjk mindig a kvetkez kiterjeszts vagy az IP fltti protokoll azonostja. (Vegyk szre,
hogy IPv4 esetn 32-bites, IPv6 esetn pedig 64-bites egysgekben gondolkozunk.)
Ksbb jabb kiterjesztseket is definiltak, st a fejrsz kiterjeszts ltalnos formtumt is definiltk az RFC 6564-ben az albbiak szerint (de ez csak az ksbbiekre ktelez):
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|
|
.
.
.
Header Specific Data
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A fejrsz kiterjeszts mezinek jelentse:

Next header (8 bit) kvetkez fejrsz A kzvetlenl utna kvetkez fejrszt azonostja. Ez lehet tovbbi fejrsz kiterjeszts vagy valamely az IP fltti protokoll azonostja.
16

Hdr Ext Len (8 bit) fejrsz kiterjeszts hossza Ez a 8 bites eljel nlkli egsz szm
az adott fejrsz kiterjeszts mrett adja meg, 8 oktettes egysgekben mrve gy, hogy az
els 8 oktettet nem szmtjuk bele.
Header Specific Data (vltoz hosszban) kiterjeszts specifikus adatok Kiterjesztstl fggen ms-ms adatok.

2.3. Internet Control Message Protocol version 6

(ICMPv6)
Az ICMP IPv6-os implementcija. zenetei az IPv6 felett utaznak (next header=0x3A, decimlisan 58), de minden IPv6 implementci ktelez rsze! Aktulis dokumentci: RFC 4443.
zenetei kt tpusba sorolhatk: hibazenetek s informcis zenetek.
Az ICMPv6 zenetek formtuma egyedi. Ami kzs bennk, az az ICMPv6 fejrsz els 32 bitjn
tallhat hrom adatmez:
Type (8 bit) tpus 0-127: hibazenetek, 128-255: informcis zenetek
Code (8 bit) altpus a tpuson bell tovbbi fajtt jellhet, ha egyltaln van ilyen
Checksum (16 bit) ellenrz sszeg
A tovbbi rsz kiosztsa fgg az zenet tpustl.
Az albbiakban felsoroljuk a fontosabb ICMPv6 zeneteket, az els szm a tpus mez rtke.
1 Destination Unreachable cl nem elrhet Mint az azonos nev ICMP zenet.
2 Packet Too Big a csomag mrete tl nagy Az IPv6 tkzben nem trdel. Ha
egy csomag nem fr bele az MTU-ba, akkor a router eldobja, s visszajelzst kld.
3 Time Exceeded idtllps Mint az azonos nev ICMP zenet.
4 Parameter Problem paramter rtelmezsi hiba A hiba okt a Code mezben
jelzi:
o 0: Hibs IPv6 fejrsz mez,
o 1: Ismeretlen Next Header tpus,
o 2: Ismeretlen IPv6 opci.
128 Echo Request visszhang krs Mint az azonos nev ICMP zenet.
129 Echo Reply visszhang vlasz Mint az azonos nev ICMP zenet.
130 Multicast Listener Query csoporttagok lekrdezse Multicast cm megadsa
nlkl: mely multicast csoportoknak vannak tagjai az adott hlzaton? Multicast cm megadsval: a megadott cm multicast csoportnak vannak-e tagjai az adott hlzaton?
MLDv2 esetn pedig mg forrs specifikus lekrdezsre is lehetsget nyjt.
131 Multicast Listener Report (MLDv1) csoporttagsg jelzse A csoporttagok
ezzel az zenettel jelzik ignyket a multicast forgalomra. (MLDv2-ben a 143-as tpus
Multicast Listener Report vette t a funckijt!)
132 Multicast Listener Done (MLDv1) multicast csoportbl kilps A csoporttagok ezzel az zenettel jelzik, hogy mr nem tartanak ignyt az adott multicast csoport
forgalmra. (MLDv2-ben a 143-as kd Multicast Listener Report vette t a funckijt,
ami gy ktfle funcit is megvalst.)
133 Router Solicitation router informci krse Az NDP rsze, rszletesen trgyaljuk majd.
134 Router Advertisement router informci hirdetse Az NDP rsze, lehet krsre vlasz, de a routerek krs nlkl is hirdetik. A kretlen hirdets szndkosan nem
pontosan periodikus.
17

135 Neighbor Solicitation MAC-cm krse Az NDP rsze, az ARP megfelelje

(pl. ARP Request s Probe funkcik).
136 Neighbor Advertisement MAC-cm hirdetse Lehet krsre vlasz, ekkor
Solicited Neighbor Advertisement. Krs nlkl is kldhet (pl. IP-cm vltozsakor), ez
az Unsolicited Neighbor Advertisement.
137 Redirect jobb tvonal kzlse Mint az azonos nev ICMP zenet.
143 Multicast Listener Report (MLDv2) csoporttagsg jelzse Az MLDv2 protokoll esetn az MLDv1 131-es s 132-es tpus zenetnek funkcijt is elltja.

2.4. A Neighbor Discovery Protocol (NDP)

Az NDP (Neighbor Discovery Protocol, RFC 4861) a TCP/IP referenciamodell internet rtegben mkdik. Mkdshez ICMPv6 protokoll zeneteket hasznl, azaz az IPv6 fejrszben a kvetkez fejrsz (next header) mez rtke 58, s aztn az ICMPv6 fejrsz tpus (type) mezje azonostja
a konkrt zentet (pldul: Neigbor Solicitation, Neighbor Advertisement).
Egy host a mkdshez szksges azonostkhoz, paramterekhez klnfle mdon juthat
hozz: bellthatk statikusan, megszerezhetk az llapotmentes automatikus cmkonfigurci
(SLAAC, lsd lent), valamint a DHCPv6 segtsgvel.
Az NDP tbbek kztt kpes:
llapotmentes automatikus cmkonfigurcira
Cmfeloldsra (IPv6 cmbl MAC cm)
Routerek cmnek megllaptsra
DNS szerverek cmnek megllaptsra
Cmduplikci ellenrzsre, azaz annak vizsglatra, hogy egy IPv6 cmet mr hasznlnak-e (DAD: Duplicate Address Detection)
Az adott linken rvnyes prefixek s MTU kidertsre
Kzlk nhnyat a tovbbiakban rszletesen bemutatunk.

2.4.1. llapotmentes automatikus cmkonfigurci

Az llapotmentes automatikus cmkonfigurci (SLAAC: Stateless Address Autoconfiguration,
RFC 4862) lehetv teszi, hogy a szmtgpek (host) emberi beavatkozs nlkl kapjanak IPv6
cmet llapot alap kiszolgl (DHCPv6) nlkl is. A folyamat tbb lpsbl ll, a host elszr linkloklis IPv6 cmet hoz ltre, majd annak segtsgvel szerez egy routertl prefixet a globlisan egyedi
IPv6 cmhez. Mind a link-loklis, mind a globlis IPv6 cm esetn az IPv6 cm utols 64 bitjben
tallhat Interface ID-t a hlzati interfsz MAC-cmbl lltja el a mdostott EUI-64 cmet elllt algoritmussal (lsd lent). Hasznlat eltt mindkt IPv6 cm egyedisgt ellenrzi a DAD
(Duplicate Address Detection) algoritmussal (kln trgyaljuk).
Az SLAAC lpsei:
Link-loklis IPv6 cm generlsa (fe80::/64 + mdostott EUI-64 azonost)
Link-loklis IPv6 cm egyedisgnek ellenrzse (DAD)
Hlzati prefix krse (ICMPv6 Router Solicitation)
o Az zenet kldshez forrscmknt mr hasznlhat a link-loklis IPv6-cm
o A clcm pedig a link-loklis hatkr (link-local scope) all routers IPv6
multicast cm (ff02::2)

18

Hlzati prefix informci vtele (ICMPv6 Router Advertisement)

o A router ezt a sajt link-loklis IPv6 cmrl ltalban a link-local scope all nodes
IPv6 multicast cmre (ff02::1) kldi. (De az RFC 4861 6.2.6. pontja szerint kldheti a host unicast cmre is, ha az nem az unspecified (::) IPv6 cm.)
Globlisan egyedi IPv6 cm (global unicast IPv6 address) ellltsa (a kapott prefix +
mdostott EUI-64 azonost). (Ehhez /64 hosszsg kapott prefix szksges!)
Globlisan egyedi IPv6 cm egyedisgnek ellenrzse (DAD)
Figyeljk meg, hogy a link-loklis s a globlis unicast cmek utols 64 bitje azonos lesz, hiszen
mindegyikben a mdostott EUI-64 azonost szerepel.
Az SLAAC biztonsgi kockzattal jr: hamis Router Advertisement zenettel a kliens megtveszthet, lsd:
SLAAC Attack http://resources.infosecinstitute.com/slaac-attack/
RFC 6104: Rogue IPv6 Router Advertisement Problem Statement

A mdostott EUI-64 cmet elllt algoritmus

Clja a hlzati interfsz 48 bites MAC cmbl 64 bites EUI (Extended Unique Identifier) azonost ltrehozsa. Az algoritmus lpsei:
A 48 bites cmet kzpen kettvgva a kt fl kz beszrjuk az FFFE 16 bites rtket.
A MAC cm els bjtjnak msodik legkisebb (azaz 2-es) helyirtk bitjt 1-re lltjuk.
(Ez a MAC cm OUI rsznek U/L bitje, teht azt jelezzk vele, hogy nem univerzlisan egyedi, hanem loklisan adminisztrlt cmrl van sz.6)
Az algoritmus mkdst egy pldval illusztrljuk:
Az eredeti MAC cm:
00:C1:C0:0B:0C:0D
Az els lps eredmnye:
00:C1:C0:FF:FE:0B:0C:0D
A msodik lps eredmnye:
02:C1:C0:FF:FE:0B:0C:0D (ksz)
Az IPv6-nl hasznlt alakban:
2C1:C0FF:FE0B:C0D
A kapott EUI-64 azostt az IPv6-nl hasznlt alakban egy 64 bites prefix utn rva megkapjuk az
IPv6 cmet.

2.4.2. IPv6-cm egyedisgnek ellenrzse

Az IPv6 cm egyedisgnek ellenrzse (DAD: Duplicate Address Detection) elvi szinten hasonlan
trtnik, mint IPv4-nl az ARP Probe zenettel. IPv6 esetn az ICMPv6 Neighbor Solicitation
(NS) zenetet hasznljk, s ha nem rkezik r vlasz, akkor a cmet mg senki sem hasznlja.
A megvalsts viszont bonyolultabb. Ugyanis mg az NS zenetben a forrscm (az ARP-hez
hasonlan) rvnytelen (::/128), addig a clcm a vizsglt IPv6 cmhez (tentative address) tartoz
solicited-node multicast address. Ennek haszna nyilvnval: mg IPv4 esetn az ARP zenetszrst
(broadcast) hasznl, s gy az adott zenetszrsi tartomny (broadcast domain) sszes gpt terheli,
addig az ND multicast hasznlatval megkmli a gpek dnt tbbsgt. Az adott multicast csoportban elvileg tbben is tartzkodhatnak, de SLAAC esetn ezek szma vrhatan alacsony. (Mivel a mdostott EUI-64 azonost utols 24 bitje alapjn kpezik a csoportcmet, ezrt nem zrhat ki, hogy egy adott hlzaton klnbz gyrtktl szrmaz hlzati interfszek esetn ez a
24 bit azonos legyen, de vrhatan nem lesz bellk tlsgosan sok.)
Megjegyzs: Azt mr lttuk, hogy az Ethernet szinten a solicited node multicasthoz hasznlt csoportcm prefixe: 33:33:ff. Amennyiben az IPv6 cmet SLAAC hasznlatval hoztuk ltre, akkor

Fontos, hogy ez a kittel csak a MAC cmre vonatkozik, ettl mg a generlt IPv6 cm lehet link loklis s globlis is.

19

az utols 24 bitje pedig a mdostott EUI-64 azonost utols 24 bitje, ami viszont nem ms, mint
a hlzati interfsz MAC cmnek az utols 24 bitje.
A DAD sorn a vizsglt cmet hasznlni kvn interfsznek mg a fenti NS zenet kikldse
eltt csatlakoznia kell kt multicast csoporthoz, ezek az all-nodes multicast (azrt, hogy ha valaki
mr hasznlja a vizsglt cmet, akkor megkapja a Neighbor Advertisement zenetet) s a vizsglt
cmhez tartoz solicited-node multicast (azrt, hogy ha valaki ms is szeretn haszlni a vizsglt
cmet, akkor halljk egymst). Az RFC mg szmos egyb felttelt s rszletet ler (pldul a klnbz vletlenszeren megvlaszott ksleltetsekkel kapcsolatban), de ilyen szint rszletekbe most
nem megynk bele (a rszletek megtallhatk az RFC 4862 5.4. rszben).
Vgl, ha vlaszknt Neighbor Advertisement zenet rkezik, akkor a vizsglt cm nem egyedi,
teht tilos (MUST NOT) az interfszhez rendelni (hasznlni) s ersen ajnlott (SHOULD) az
esemnyt naplzni.

2.4.3. Cmfelolds
Br a szmtgpek IP-cmmel azonostjk egymst, egy csomag tnyleges (fizikai) elkldshez
szksg van annak az interfsznek az adatkapcsolati szint (link layer) cmre (MAC-cmnek is
szoktuk nevezni) amely szmra kzvetlenl (link szinten) kldeni szeretnnk a csomagot szllt
adatkapcsolati szint adategysget, pl. Ethernet keretet. Az IP 4-es verzija erre a clra a jl ismert
ARP-t alkalmazza. IPv6 esetn pedig a Neighbor Solicitation (NS) s Neighbor Advertisement
(NA) ICMPv6 zenteteket hasznljuk. (Az IPv6 cmfelolds rszletes lersa az RFC 4861 7.2. rszben tallhat.)
Amikor egy (multicast kpes) hlzati interfszt engedlyeznek, az kteles (MUST) csatlakozni az
all-nodes multicast csoporthoz, valamint az sszes IPv6 cmhez tartoz solicited-nodes multicast
address ltal meghatrozott csoporthoz is. Ha az IPv6 cme megvltozik, akkor kteles (MUST)
tagja lenni az j IPv6 cmhez tartoz solicited-nodes multicast address cm ltal meghatrozott
csoportnak, illetve elhagyni az olyan csoportot, amiben mr nem illetkes. Megjegyzs: amint mr
korbban emltettk, lehetsges, hogy tbb klnbz IPv6 cmhez ugyanaz a csoportcm tartozik.
(Pldul tipikusan ez a helyezet, ha egy fizikai interfszen tbbfle prefix alapjn kpzett interfsze
is van, s ezek utols 64 bitjt a hlzati interfsz azonostjbl kpeztk.) gy nem minden esetben trtnik tnylegesen csoportba val belps illetve onnan val kilps. Amennyiben ilyen trtnik akkor erre az MLD (Multicast Listener Discovery) protokoll 1-es vagy 2-es verzijt hasznljk.
Az RFC szmos lehetsget ler, hogy NS/NA zenetvltskor milyen cmeket hasznlhatnak, itt
most egy tipikus pldt mutatunk be. A krdez gp az NS zenetet a sajt link-loklis IPv6 cmrl
a krdses IPv6 cmhez tartoz solicited-node multicast cmre kldi, s az zenet Target Address
mezjben benne van a krdses IPv6 cm, valamint a krdez a Source link-layer address opcival
megadja a sajt MAC cmt is. Az IPv6 cm gazdja egy NA zenettel vlaszol, amit a sajt linkloklis IPv6 cmrl a krdez link-loklis IPv6 cmre kld, benne van a Target Address mezben a
krdses IPv6 cm, s a hozz tartoz MAC cm pedig a Target link-layer address opciban tallhat.

2.5. Multicast Listener Discovery (MLD)

Amint a cmzsnl mr lttuk, az IPv6 kifinomultan tmogatja a tbbesklds (multicast) megvalstst, s amint az ND-nl lttuk, az IPv6 alaposan ki is hasznlja a multicast lehetsgeit, kivltva
vele a broadcastot.
IPv6-ban az egyes llomsok az MLD (Multicast Listener Discovery, MLDv1: RFC 2710,
MLDv2: RFC 3810) protokoll segtsgvel tudjk kifejezni ignyket valamely multicast csoport

20

forgalmra. (Az MLDv1 az IGMPv2-nek, az MLDv2 pedig az IGMPv3-nak az IPv6-os megfelelje. Az jabb verzi clja mindkt esetben az volt, hogy a vevk kifejezhessk azon ignyket,
hogy az adott multicast csoport forgalmbl csak egy adott forrs adsra tartanak / nem tartanak
ignyt.)
Az MLD ICMPv6 zeneteket hasznl, azaz az IPv6 fejrszben a kvetkez fejrsz (next header)
mez rtke 58, s aztn az ICMPv6 fejrsz tpus (type) mezje azonostja a konkrt zentet. Ezek
a v2-ben a v1-hez kpest vltoztak, az 1. tblzatban rviden sszefoglaljuk, hogy melyik verzi
milyen clra milyen zeneteket hasznl. Az egyes zenetek utn megadjuk az ICMPv6 tpus mez
decimlis rtkt is, amire a klnbz verziszm, ezrt eltr Multicast Listener Report zenetek azonostshoz van szksg.
verzi
csoporttagsg lekrdezse
csoportagsg jelzse
csoportbl kilps

MLDv1
Multicast Listener Query (130)
Multicast Listener Report (131)
Multicast Listener Done (132)

MLDv2
Multicast Listener Query (130)
Multicast Listener Report (143)
Multicast Listener Report (143)

1. tblzat: Az MLDv1 s az MLDv2 ltal hasznlt ICMPv6 zentek tpusa

Teht a 2. verziban a csoporttagsg jelentsre s a csoportbl val kilps (krds nlkli) bejelentsre ugyanazt az zenetet hasznljk, amely azonban eltr az 1. verziban a csoporttagsg
jelzsre hasznlt zenettl. A tblzatbl nem ltszik, de a 2. verziban a lekrdezsre hasznlt
zenet formtuma is vltozott (bvlt).
Az MLDv1-ben mindhrom zenet formtuma azonos:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Maximum Response Delay
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Multicast Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ahol az egyes mezk jelentse:

Type (8 bit) tpus Lehetsges rtkei: 130, 131, 132. Az zenet tpust hatrozza meg.
Code (8 bit) nem hasznljk Csak az ICMPv6 fejrsz szerkezete miatt szerepel. A
kld az rtkt 0-ra lltja, a vev pedig nem veszi figyelembe.
Checksum (16 bit) ellenrz sszeg A szabvnyos ICMPv6 ellenrz sszeg.
Maximum Response Delay (16 bit) maximlis megengedett ksleltets Csak a krdsben (query) hasznljk, rtke ms-ban adja meg, hogy mennyi idn bell kell a vlaszt
kldeni. A tbbi zenetben az rtkt 0-ra lltja a kld s a vev nem veszi figyelembe.
Reserved (16 bit) tovbbi fejlesztsre fenntartva rtkt a kld 0-ra lltja s a vev
nem veszi figyelembe.
21

Multicast Address (128 bit) multicast cm Lekrdezs (query) esetn kt lehetsg

van. Ha az rtke 0, akkor ltalnos lekrdezsrl (General Query) van sz, a krdez arra
kvncsi, hogy mely csoportoknak vannak tagjai. Ha rtke 0-tl klnbz, akkor csoportcm specifikus lekrdezsrl (Multicast-Address-Specific Query) van sz, a krdez azt
szeretn megtudni, hogy az adott cm IPv6 multicast csoportnak van-e tagja. Vlasz
(Report) vagy kilps (Done) esetn pedig azt a csoportot adja meg, amelyik forgalmra
a vlasz kldje az ignyt bejelenti (Report) vagy ppen amelyiket el kvnja hagyni
(Done).
A 2. verzi az 1. verzival kpes egyttmkdni (interoperable), a bvts clja a forrsspecifikus
multicast (SSM: Source-Specific Multicast, RFC 3569) tmogatsa. A lekrdezs (Query) zenet tpusa (type) nem vltozik, de szmos tovbbi mezvel bvl, valamint a benne tallhat Maximum
Response Delay mez neve Maximum Respons Codera vltozik, mikzben rtelmezse 0-32767 rtkek esetn vltozatlan, fltte viszont lebegpontos szmknt kell rtelemezni (lsd: RFC 3810
5.1.3 rsz). A vlaszzenet tpuskdja s formtuma is teljesen megvltozik. Ezeket a tovbbiakban
nem rszletezzk. (A gyakorlatban tallkozhatunk velk, a Wireshark kpes dekdolni.)

2.6. Path MTU discovery (PMTUD)

A hlzati tvitel hatkonysga szempontjbl kvnatos, hogy a lehet legnagyobb csomagmretet hasznljuk. Egy adott tvonal legnagyobb megengedett csomagmretnek kidertse (PMTUD: Path MTU
Discovery) mind IPv4 (RFC 1191), mind IPv6 (RFC 1981) esetn felmerl krds. Mg IPv4 esetn egy adott tvonalon a kzbls routerek trdehetnek, ha a DF (Dont Fragment) bit nincs
belltva, gy IPv4-nl tl nagy csomagmret esetn csak a hatkonysg cskken (esetleg a csomagok sszeraksnl lehet problma, ha pl. egy tzfal eldobja a tredkeket), addig IPv6 esetn
kizrlag a forrs trdelhet, teht a csomagmret megvlasztsa itt mg fontosabb krds. Amenynyiben IPv6 esetn egy csomag mrete tl nagy, s ezrt egy kzbls router eldobja, akkor az adott
router ezt a problmt a Packet Too Big (PTB) ICMPv6 zenettel kteles (MUST) jelezni a forrs
szmra (lsd RFC 1885, 3.2). A PMTUD (els krben) ezen zenetek hasznlatn alapul.
Mivel az tvonalak idkzben megvltozhatnak, a PMTUD-t idrl idre jra el kell vgezni.
Amennyiben egy host PTB zetetet kap, akkor kteles (MUST) az adott tvonalra kldtt zenetek
mrett cskkenteni, s a kzeljvben (10 perc a szoksos id, 5 percnl semmikppen sem lehet
kisebb) nem is kldhet ilyen mret csomagot. (Az RFC a cskkents konkrt mrtkt nem hatrozza meg.) Egy adott tvonal MTU rtknek cskkensre teht azonnal kell reaglni, az esetleges
nvekedst pedig 10 percenknt ajnlott megvizsglni.
Azonban elfordulhat, hogy valamely tvonalon egy tzfal nem engedi t a PTB zeneteket. Ez
a gyakolatban pldul azt jelentheti, hogy egy TCP kapcsolat felpl ugyan, de aztn a forgalom
nem halad t rajta. ICMPv6 zenetek hinyban trtn PMTUD-re ad megoldst az RFC 4821. A
benne lert PLPMTUD (Packet Layer PMDUD) alaptlete (TCP-ben gondolkozva) az, hogy a TCP
szegmens mretet kis rtkrl kezdve nveli, s az els izollt csomagvesztst nem torldsnak
tekinti (nem cskkenti a congestion window rtkt), hanem azt felttelezi, hogy a szegmens mrete
tl nagy volt, ezrt eldobsra kerlt, de a PTB zenet elveszett. A megoldssal bvebben nem tudunk foglalkozni, csak jeleztk a problma s a megolds ltt.
Mivel az 1280-as MTU-t minden IPv6 node-nak ktelezen tmogatnia kell, s Ethernet esetn
1500 bjt az ltalnos MTU, ezrt a mindennapi letben az esetek tbbsgben az 1280-1500 az
MTU lehetsges intervalluma. Specilis esetben lehet komoly jelentsge a nagyobb MTU hasznlatnak.

22

2.7. Domain Name System

Az IPv6 protokoll alkalmazsa magval hozta a DNS rendszer kiterjesztst is. Megjelent egy j
erforrs rekord tpus (Resource Record, RR), valamint az IPv6 reverz delegcihoz egy j domain.
A DNS mkdst ler RFC 1034 s RFC 1035 kerlt kiegsztsre az RFC 3596-tal.

2.7.1. IPv6 nvfelolds

Az IPv6 nvfeloldshoz bevezetsre kerlt az AAAA rekordtpus. Knny megjegyezni, hiszen
az IPv6 cm hossza ppen ngyszerese az IPv4 cm hossznak, gy az IPv4-nl alkalmazott A
rekord helyett itt a ngy A (quad A) rekord kerlt bevezetsre. Az AAAA rekord alkalmazsa
teljesen megegyezik az IPv4-es prjval, annyi klnbsggel, hogy IPv6 cm kveti. Pldul egy
WWW rekord megadsa egy IPv6 cmhez egy tetszleges znban gy nzhet ki:
www

IN AAAA

2001:DB8::10

www

IN A
IN AAAA

192.0.2.10
2001:DB8::10

Ha egy hoszt rendelkezik IPv4 s IPv6 cmmel is, akkor mindkt tpus rekordot ltre kell hozni
a znban. Egy ilyen esetre plda az albbi znafjl rszlet:

A DNS szerver nem veszi figyelembe, hogy a krs IPv4, vagy IPv6 protokollal rkezik-e hozz,
hanem a krdezett rekordtpushoz tartoz vlaszt adja vissza.

2.7.2. IPv6 reverz nvfelolds

Az IPv6-os cmek fordtott irny (reverz) feloldsa IP-cmbl szimbolikus nv (DNS domain
name) megllaptsra szolgl, ami tovbbi dntsek alapjt is kpezheti (pldul hozzfrs engedlyezse a domain alapjn). Megvalstsa is az IPv4-es prjhoz hasonl annyi eltrssel, hogy
mg az IPv4 esetben az in-addr.arpa domaint kell hasznlni, itt az ip6.arpa alkalmazsa szksges.
A ltrehozott znban ugyangy a PTR tpus rekordokat kell hasznlni. A domain ltrehozsnl
fontos, hogy minden ngy bites csoportot jellni kell, nem hagyhatak el a nullk sem. A szmjegyek sorrendjt pedig az IPv4-hez hasonlan meg kell fordtani. Nzzk meg kt pldn keresztl,
hogy hogyan llthatjuk el a szksges domaint s bejegyzst:
Az IPv6 cm:
A rvidts nlkl:
Domain nv:

2001:db8::10
2001:0db8:0000:0000:0000:0000:0000:0010
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Az IPv6 cm:
A rvidts nlkl:
Domain nv:

2001:abcd:e001:1::2
2001:abcd:e001:0001:0000:0000:0000:0002
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.e.d.c.b.a.1.0.0.2.ip6.arpa.

Az els pldhoz ltrehozhat a

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa.

nev zna, a

0.1.0.0.0.0.0.0

IN

PTR

www.isp.hu.

PTR rekorddal, mg a msodikhoz a

0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.e.d.c.b.a.1.0.0.2.ip6.arpa.

nev zna, a
2.0.0.0.0.0.0.0

PTR rekorddal.

IN

PTR

www.isp2.hu.

23

2.8. IPv6 cmkioszts

2.8.1. RIPE adminisztrci
Az interneten hasznlt egyedi azonostkat (IP cmek, protokoll azonostk, portok, domain nevek, stb.) az Internet Assigned Numbers Authority (IANA, http://www.iana.org/) adminisztrlja,
mely az Internet Corporation for Assigned Names and Numbers (ICANN,
https://www.icann.org/) nonprofit szervezet rszlege. Az IANA az IPv4 s IPv6 cmek (s AS
szmok) adminisztrlst fldrajzi terletek alapjn a 2. tblzatban felsorolt t regionlis szervezethez deleglta (Regional Internet Registry, RIR).
rvidts
AFRINIC
APNIC
ARIN
LACNIC
RIPE
NCC

nv
African Network
Information Center
Asia Pacific Network
Information Centre
American Registry for Internet Numbers
Latin America and
Caribbean Network
Information Centre
The Rseaux IP Europens
Network Coordination
Centre

terlet
Afrikai rgi

weboldal
http://www.afrinic.net/

zsiai s csendesceni rgi

szak-amerikai rgi
Latin-Amerika s
Karib-szigetek

https://www.apnic.net/

Eurpa, Kzp-Kelet, Kzp-zsia

https://www.ripe.net/

https://www.arin.net/
http://www.lacnic.net/

2. tblzat: Az t RIR adatai

Az IANA viszonylag nagy nllsgot biztostott az 5 RIR rszre, gy az IP cmhez juts felttelei
s mdszerei terletenknt eltrek. A kvetkezkben a RIPE szablyaival foglalkozunk.
A RIPE Network Coordination Centre (RIPE NCC) az IPv6 cmhez (s mg ms azonosthoz)
jutst tagsghoz kttte (mely termszetesen tagdjfizetssel jr). Az IPv6 cmekre vonatkoz szablyokat jelenleg a RIPE-641 (https://www.ripe.net/publications/docs/ripe-641) dokumentum
szablyozza. Az IPv6 cmeket a felhasznlk nem kzvetlenl a RIPE NCC-tl kell, ignyeljk,
hanem az internetszolgltatjuktl (ISP). A nagyobb ISP-k ltalban helyi internet regisztrtorok
(Local Internet Registries, LIR) is egyben. RIPE NCC tagsggal rendelkeznek, s k vgzik az IPv6
cmek adminisztrlst gyfeleik szmra. A cmek adminisztrlsnak hierarchikus felptse lthat a 3. brn.
Az adminisztrci megrtshez fontos kt fogalom pontos defincija:
Allokls (Allocation): A cmtartomny kiosztsa IR-ek rszre, hogy azok tovbb oszthassk azokat.
Kijells (Assignment): A cmtartomny hozzrendelse ISP-hez, vagy elfizethz kizrlag a meghatrozott s dokumentlt felhasznls cljbl. A kijellt cmtartomnybl, annak felosztsval nem vgezhetek jabb kijellsek msok rszre.
Teht a csak alloklt cmtartomnyban lv IPv6 cmeket mg nem hasznlhatja senki, mg a mr
kijellt cmek (kizrlag a kijells cljra) mr hasznlhatk.

24

IANA

RIR

ISP/LIR

EU (ISP)

EU (ISP)

RIR

Regional Internet Registries

(ARIN, APNIC, RIPE NCC, plus
possible future RIRs)

NIR

National Internet Registries

(APNIC region)

ISP/LIR

Local Internet Registries

(ISPs)

EU

End Users

3. bra: IPv6 cmkioszts hierarchikus felptse (https://www.ripe.net/publications/docs/ripe-641)

Az IPv6 cmtartomny kezelsnek tbb, nhol egymsnak ellentmond clja van:
Gondossg (Prudent manner): Az IPv6 cmtartomny egy kzs erforrs, melynek gondos kezelse szksges.
Egyedisg (Uniqueness): Minden allokcinak s kijellsnek biztostania kell az IPv6
cmek teljes vilgra kiterjed egyedisgt, hiszen ez szksges az IPv6 internet problmamentes mkdshez, az egyedi hosztok azonostshoz.
Regisztrci (Registration): Az IPv6 cmeket minden esetben rgzteni kell egy adatbzisban, biztostand az egyedisget, s a visszakereshetsget.
Aggregls (Aggregation): Mindenhol, ahol lehetsges, a hlzat felptshez igazodva,
hierarchikusan kell kiosztani az IPv6 cmeket, ezltal biztostva az aggregls lehetsgt.
Az aggregls alkalmazsa cskkenti az tvlasztkra jut terhelst, azltal, hogy kevesebb routing bejegyzs kerlhet a routing tblzatokba. (Az IPv6 protokoll esetben ez a
szempont kerl eltrbe.)
Megrzs (Conservation): Annak ellenre, hogy az IPv6 cmtr hatalmas, kerlni kell a
pazarlst.
Mltnyossg (Fairness): Biztostani kell az igazsgos s egyenl IPv6 cmtr hasznlatot
az alkalmazott szablyok s gyakorlatok segtsgvel az internet jelenlegi s lehetsges
felhasznli szmra, helytl, nemzetisgtl, mrettl, s minden egyb tulajdonsguktl
fggetlenl.
Minimlis kltsg (Minimised overhead): Minimalizlni kell az IPv6 cmhez juts terheit.

25

Fontos, hogy az egyedi IPv6 unicast cmek nem kerlnek a felhasznlk tulajdonba, azokat k
csak hasznlatba kapjk.
A legkisebb IPv6 allokci prefixe /32. Ez azt jelenti, hogy ha egy LIR IPv6 cmtartomny allokcit kr, legalbb ekkora cmteret kap. Az allokcinl figyelembe lehet venni a hasznlt IPv4
cmtartomnyokat, melyek indokolhatjk a rvidebb IPv6 prefix (nagyobb cmtartomny) allokcijt is. Az IPv6 cmek allokcijakor alkalmazott megolds (nem kzvetlen egyms utn kerltek
alloklsra a cmtartomnyok) lehetv teszi, hogy szksg esetn a /32-es tartomny (sszefgg)
/29-esre bvthet legyen. Ezt a bvtst jelenleg indokls nlkl krheti brmely LIR, ezltal megnyolcszorozva a rendelkezsre ll cmtartomny mrett.
A felhasznlk rszre biztostott prefix mrete az internetszolgltat dntsn mlik, azonban
egy vgpontra a /64 (teht az egy alhlzat) a legkisebb mret cmtartomny. A /64 s /48 hosszak
kztti prefixek esetben nincs szksg a felhasznltl dokumentci beszerzsre, azonban a
/48-as prefixnl nagyobb cmtartomny kijellse esetben mr a felhasznlnak bizonytania kell,
hogy valban szksge van ilyen mret tartomnyra. Ilyen esetekben a RIPE NCC hagyja jv az
allokcit.
Az IPv6 cmek kijellst regisztrlni kell a RIPE NCC adatbzisban. A LIR ezt kt fle mdon
csinlhatja. Ha az egyes felhasznlk rszre /48-nl nagyobb tartomnyt biztost, gy ezt a tartomnyt a felhasznl rszre kell regisztlnia az adatbzisban. Ha /48 s /64 kztti tartomnyokat
jell ki, azt nagyobb tartomnyokknt is regisztrlhatja, azonban, ilyenkor meg kell adnia az
AGGREGATED-BY-LIR attribtumot is az objektumhoz.

2.8.2. RIPE NCC adatbzis

Legegyszerbben a RIPE weboldaln (https://www.ripe.net/) keresztl krdezhetjk le az adatbzis tartalmt. Egy kijells (assigment) lthat a 4. brn.

4. bra: IPv6 assignment a RIPE adatbzisban

A sajt objemtumok mdostst s trlst is elvgezhetjk a webupdate segtsgvel, ami az
objektum melletti Update gombra kattintva tltdik be. (A webupdate mellett, e-mail-ben is mdosthatk az objektumok.) Termszetesen a mdostshoz hitelestsre is szksgnk van.

26

A reverze delegcit a /32-es prefixekhez a domain objektum segtsgvel rgzthetjk az adatbzisban. Erre mutat pldt az 5. bra.

5. bra: IPv6 reverz delegci

A RIPE NCC szervern (ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt) mindig elrhet
az egyes LIR-ek rszre alloklt IPv4 s IPv6 cmtartomnyok listja. A knyv rsakor (2015.5.30.)
112 darab hu.-tal kezdd LIR volt megtallhat. Ez a lista nem pontosan egyezik meg a haznkban internetszolgltatssal foglalkoz cgekkel, azonban j kzeltst ad a magyarorszgi helyzetrl.
A hu. alatti adatok vizsglatnak eredmnyeit a 3. tblzatban foglaljuk ssze.
hu. alatti LIR-ek szma
ebbl IPv6 allokcival rendelkezk
csak IPv6 allokcival rendelkezk szma
kt IPv6 allokcival rendelkezik

112 db
86 db (76,79%)
1 db (0,89%)
1 db (0,89%)

3. tblzat: A RIPE hu. alatti ISP-k IPv6 allokcii

Alloklt prefixek mrete

/28, 1 db, 1%
/29, 21 db, 24%

/31, 1 db, 1%

/32, 64 db, 74%

6. bra: A RIPE hu. alatti ISP-k IPv6 allokciinak mrete

27

db
18
16
14
12
10
8
6
4
2
0
2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 v

7. bra: RIPE hu. alatti ISP-k IPv6 allokcik ves eloszlsa

Az IPv6 allokcik prefixhossznak eloszlst a 6. brn lthatjuk. Mg az IPv6 allokcik ves
eloszlsa a 7. brn lthat.
Ezek az adatok bizakodsra adhatnak okot, hiszen a 112 LIR 77%-a mr rendelkezik IPv6 cmallokcival. Azonban, ha megvizsgljuk, hogy a 87 darab IPv6 prefixbl hny tallhat meg a globlis routing tblban, az eredmny sokkal rosszabb, mivel kiderl, hogy az alloklt IPv6
prefixeknek csak kevesebb, mint felt hasznljk.. A knyv rsakor a globlis routing tblban kzlk csak 33 darab prefix szerepelt. Az pedig az sszes hu. LIR-nek csak 29,46%-a, mg a 87
darab alloklt prefixnek csak 37,93%-a.

2.8.3. Ajnlsok
A korbban ismertetettek alapjn, az elfizeti telephelyek rszre kijellt cmtartomny ajnlott
mrete a minimlis /64 s a maximlis /48 kz esik. Az tlthatsgot nveli (s a reverz DNS
belltst egyszersti), ha a mretezsnl figyelembe vesszk a byte, vagy a flbyte (4 bit) hatrokat.
Ezek alapjn vizsgljuk meg, hogy egy /32 prefixmret kezdeti allokcit felhasznlva egy LIR
hny felhasznl rszre tud IPv6 cmet kijellni.
kijellt prefix mret
/64
/60
/56
/52
/48

gyfelek szma
232=~4,3 millird
228=~286,4 milli
224=~16,8 milli
220=~1 milli
216=65536

gyfelek lehetsges alhlzatainak szma

20=1
24=16
28=256
212=4096
216=65536

4. tblzat: Az gyfelek s hlzataik lehetsges szma a kisztottt prefix mretnek fggvnyben, ha a

LIR prefixnek mrete /32
A 4. tblzat sszelltsnl nem vettk figyelembe, hogy az internetszolgltatk sajt infrastruktrja is ignyel IP cmeket, valamint minden gyfl rszre ugyanakkora tartomny kerlt kijellsre. A RIPE NCC jelenlegi szablyozsa szerint a /32 mret kezdeti allokci egyszeren /29re nvelhet, ami a tblzatban lv adatokat 23-nal szorozva, 8-szorosra nveli a rendelkezsre
ll cmtartomnyt. Ezek alapjn, ha egy magyarorszgi LIR gy dnt, hogy az egyszersg kedvrt
28

a byte hatrokat betartva, mindenkinek /56-os cmtartomnyt jell ki, akkor sem relis, hogy kifogyjon a rszre alloklt IPv6 cmtartomnybl. Ezzel a mdszerrel minden gyfele szmra biztostja azt is, hogy az gyfelek legalbb 256 alhlzatot alakthassanak ki sajt hlzatukon bell.
Termszetesen egy hlzat tervezsnl sok szempontot figyelembevtele szksges, hiszen nagyon fontos az aggregls lehetsge, a szolgltat, valamint az gyfl hlzatnak fldrajzi elhelyezkedse, az gyfl hlzatnak mrete, stb. Ugyanakkor jl lthat, hogy az IPv6 protokoll alkalmazsa esetn nem a takarkossg kell, hogy a vezrlelv legyen. (A technikai szempontok mellett,
a marketing szempontok figyelembevtele is szksges.)

29

3. tvlaszts
3.1. OSPFv3
Az Open Shortest Path First (OSPF) 2-es verzijt sok helyen alkalmazzk. Elnye, hogy nylt
szabvny, mely hlzati eszkzk szles skljn implementlt, gy heterogn, tbb gyrttl szrmaz eszkzkbl kialaktott hlzat kialaktsa sem okoz problmt. Az OSFPv2 azonban nem
tmogatja az IPv6-os protokollt, gy szksgess vlt tovbbfejlesztse, melynek sorn elszr az
OSPF for IPv6, majd az IP protokoll mindkt verzijt tmogat OSPFv3 kerlt szabvnyostsra.
Elterjedt megoldsknt az OSPFv2-t az IPv4 protokoll, mg az OSPFv3-at az IPv6 protokoll tvlasztsra hasznljk, annak ellenre, hogy az jabb eszkzk mr tmogatjk az OSPFv3-as ktprotokollos mkdst is (AF: Address Families). Az OSPFv2-t jelenleg az RFC 2328, mg az
OSPF for IPv6-ot az RFC 5340, vgl az OSPFv3 s AF-et az RFC 5838 definilja. Az OSPFv3
AF nem minden rendszerben implementlt. Pldul a Cisco IOS Release 15.1(3)S s 15.2(1)T eltt
is mkdtt az OSPFv3 IPv6, de OSPFv3 IPv4 alkalmazsra csak ezektl a felsorolt verziktl
van lehetsg.

3.1.1. OSPFv2 s OSPFv3 sszehasonltsa

Mivel az OSPFv3 az OSPFv2 kibvtse az IPv6 tmogats rdekben, gy nagyon sok egyezs
tallhat a kt protokoll mkdsben, ugyanakkor az IPv6 tmogatsa rdekben elvgzett vltoztatsok mrtke miatt nem kompatibilis a kt verzi, ezrt kerlt sor a verziszm nvelsre.
Hasonlsgok:
Mindkett kt szint hierarchit alkalmaz, s a ktelez gerinchlzat terletre (Backbone
area) (0 vagy 0.0.0.0) csatlakozik a tbbi area.
Mindkettben vannak terlethatr tvlasztk (Area Border Router, ABR) s AS-hatr
tvlasztk (Autonomous System Boundary Router, ASBR).
Mindkett a Shortest Path First (SPF) mdszert alkalmazza az optimlis tvonal kivlasztsra, melyet Edsger Dijkstra SPF algoritmusnak alkalmazsval szmt ki.
Metrikja mindkettnek az tvonalak kltsge (cost).
Mindkett 5 csomagtpussal rendelkezik:
o Hello
o Database description (DBD)
o Link-state request (LSR)
o Link-state update (LSU)
o Link-state acknowledgment (LSAck)
Azonos interfsz tpusokat hasznlnak:
o Broadcast
o P2P (point-to-point)
o P2MP (point-to-multipoint)
o NBMA (non-broadcast multiple access)
o Virtual-Links
Mindkett azonos idztseket hasznl.
Klnbsgek:
Az OSPFv2 csak IPv4, mg az OSPFv3 csak IPv6, vagy mindkt IP protokoll.
OSPFv3 esetben j LSA tpusok.
Eltr csomagformtumok.
30

OSPFv3 eltr flooding scope biteket hasznl.

OSPFv3 szomszdsgok link-loklis IPv6 cmekkel.
OSPFv3 linkenknt, nem pedig alhlzatonknt mkdik. (Megjegyzs: ltalnos IPv6
jellemz, hogy nem alhlzat, hanem link terminolgit hasznl.)
Tbb OSPFv3 pldny tmogatott egy linken.
OSPFv3 multicast cmek: FF02::5 az adott linken minden OSPF router (link-local all
OSPF routers), FF02::6 az adott linken minden a routing informcik cserjre kijellt OSPF
router (link-local all OSPF Designated Routers, DRs).
OSPFv3 protokoll fejlcbl eltvoltsra kerltek az AuType s Authentication mezk.
gy az OSPFv3 alapesetben nem tmogatja a szomszdok hitelestst. Erre a clra csak
az IPSec AH s ESP volt hasznlhat, majd megjelent az RFC 7166-ban rgztett
Authentication Trailer.
OSPFv3 alatt a Router ID ugyangy 4 byte hossz, s a megfelel mkds rdekben
hlzaton belli egyedi, 0.0.0.0-tl eltr rtkkel kell rendelkezzen.

3.1.2. OSPFv3 mkdse

Az OSPF kapcsolatllapot (link-state) alap, autonm rendszeren belli tvlasztsi protokoll (interior
gateway protocol, IGP). Npszersgnek oka a gyors konvergencia, a j sklzhatsg s a szleskr tmogats, melynek kvetkeztben a tbbgyrts, heterogn hlzatok kialaktsa sem okoz
gondot. A kvetkezkben az OSPFv3 mkdst ismertetjk.

Kapcsolatllapot (link-state) alap tvlaszt protokollok

A link-state routing protokollok szmos elnnyel rendelkeznek a tvolsgvektor (distance-vektor)
alap protokollokkal szemben:
Hierarchikus felptskbl kifolylag jobban sklzhatak, gy segtsgkkel lnyegesen nagyobb hlzatok alakthatk ki.
Minden router ismeri a teljes hlzat felptst (tbb area alkalmazsa esetn, csak a
sajt area felptst), belertve a tbbi routert, az azok kzti sszekttetseket, valamint azok metrikit is. Ezeket az informcikat felhasznlva, a routerek kpesek kivlasztani a szmukra legmegfelelbb tvonalat.
A hlzati topolgia vltozsakor (LSA segtsgvel) rtestik egymst a routerek, ami
gyors konvergencit eredmnyez, valamint tviteli kapacitst takart meg.
A szomszdos routerek egymssal szomszdsgi kapcsolatokat alaktanak ki. Ha kt
szomszd kzt a kommunikci megszakad, a tbbi routert az ennek kvetkeztben
bell topolgiavltozsrl (LSA segtsgvel) rtesti a problmt rzkel eszkz.

OSPF ttekintse
A routerek Link-State Advertisement (LSA) csomagokat kldenek ki minden llapotvltozs esetn. A tbbi router irnybl fogadott LSA csomagokbl kinyert informcikat pedig a Link-State
Database (LSDB)-ben troljk le. (Ezt az adatbzist hvhatjk mg topolgia adatbzisnak is, hiszen
a hlzat felptst kpezi le a router szmra rtelmezhet formban.)
Az LSDB alapjn az SPF eljrs segtsgvel, az OSPF esetben alkalmazott kltsg (cost) metrikk
figyelembevtelvel kivlasztjk a legolcsbb teljes kltsg (cumulated cost) tvonalat. Utols lpsben pedig a routing tblba bejegyzik a legolcsbb tvonalakhoz tartoz kvetkez routereket (nexthop).

31

Szomszdsgi kapcsolat kialaktsa

Ahogy mr korbban is emltettk, az OSPF routerek egymssal szomszdsgi kapcsolatokat alaktanak ki. Erre a clra Hello csomagokat hasznlnak, melyeket a FF02::5 multicast IPv6 cmre kldenek ki. Az erre a multicast cmre rkez csomagokat az sszes OSPF router figyeli s feldolgozza.
Az OSPF IPv6 Hello packet felptse az RFC 5340 alapjn:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Verison: 3 |
1
|
Packet Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Area ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
| Instance ID
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Interface ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority |
Options
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Hello Interval
|
Router Dead Interval
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Designated Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Backup Designated Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Neighbor ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|

Az OSPFv2 Hello csomaghoz kpest a legfontosabb eltrsek a kvetkezk:

A verzi mez rtke 3.
Hinyzik az authentikcis mez, hiszen OSPFv3 esetn erre a clra az IPSec (RFC
4302 , RFC 4303) az RFC 4552-ben megadott mdon, vagy az Authentication Trailer
(RFC 7166) hasznlhat.
Hinyzik a Network mask, ellenben megjelent az Interface ID.
Megjelent az Instance ID, melyre elsdlegesen a tbb AF egyidej tmogatsa miatt
van szksg (lehetsges rtkei: RFC 6969).
A fontosabb mezk:
Area ID: Azt adja meg, hogy az adott interfsz melyik area rsze. rtke ugyangy 32
bit hossz, mint az OSPFv2 esetben.
Router ID: rtke az OSPFv2-vel megegyezen itt is 32 bit hossz. Kikts, hogy
rtke 0.0.0.0-tl eltr, s a hlzatban egyedi legyen.
Hello Interval: A msodpercben megadott idkznknt kldik ki (s vrjk egymstl) a routerek a Hello csomagokat.
Router Dead Interval: Amennyiben ennyi ideig nem kap Hello csomagot egy router
a szomszdjtl, akkor gy rtkeli, hogy a szomszd mr nem elrhet (az sszekttets megszakadt). rtke ltalban a ngyszerese a Hello Interval rtknek.

32

Neighbor ID: Ebbl a mezbl annyi tallhat, ahny routerrel a Hello csomagot
kld router a hlzaton, mr sikeresen kialaktotta a kapcsolatot. A mezk rtkei,
pedig a szomszdos routerek Router ID-ivel egyeznek meg. Ebbl a mezbl tudja egy
szomszdos router, hogy a Hello csomagot kld routerhez elzleg eljutott a sajt
Hello csomagja..
Rtr Priority: rtke a routing informcik cserjre kijellt tvlaszt (Designater Router,
DR) s a tartalk DR (Backup Designated Router, BDR) kivlasztsnl jut szerephez.
0 esetn a router biztosan nem lesz DR, vagy BDR.
A szomszdsgi kapcsolat kialaktshoz fontos, hogy a kvetkez mezk rtkei megegyezzenek:
Area ID, Hello Interval, Router Dead Interval. Az alaprtelmezett Hello s Router Dead Interval
msodperc rtkeket az 5. tblzatban adjuk meg.

OSPF Hlzat tpus

Broadcast
Non-broadast
Point-to-Point
Point-to-Multipoint
Point-to-Multipoint Non-broadcast

Hello
10
30
10
30
30

Router Dead Interval

40
120
40
120
120

5. tblzat: Az OSPF alaprtelmezett Hello s Router Dead Interval rtkei msodpercben

SPF algoritmus
OSPF routing prtokoll esetben a Shortest Path Sirst (SPF) algoritmus felel a legjobb tvonal
kivlasztsrt. A routing protokollok klnbz metrikkat alkalmaznak a legjobbnak vlt tvonal
kivlasztshoz. OSPF esetben ez a metrika az tvonalon lv sszes interfsz sszestett kltsge.
Nzzk meg a mkdst a 8. brn lthat pldn keresztl.
Cumulative cost=25
Cost=10

Router A

Router B

Cost=15

Cost=15

Cumulative cost=35
Cost=20

Router C

Router D

8. bra: OSPF tvonalvlasztsa

Ltszik, hogy a Router A s a Router D kztt kt lehetsges tvonal van. Ha Router A-bl
Router B fel indulunk, majd onnan tovbb a Router D fel, gy az tvonal teljes kltsge 25
(zlddel jellt tvonal), mg ha a Router C fel indulunk, majd tovbb a Router D-hez, gy a kltsg
35 (pirossal jellt tvonal). Mivel kltsgrl beszlnk, s az letben is alacsonyabb kltsgre treksznk, gy a router is az alacsonyabb kltsggel jr tvonalat fogja kivlasztani. A kltsgek
33

kialaktsa az alkalmazott router tpustl fgghet. Lehet bellthat manulisan, de akr az adott
interfsz sebessgnek s egy referenciasebessgnek a felhasznlsval is automatikusan elllthatja
a router.
Az SPF algoritmus Edsger W. Dijkstra, dn tuds ltal 1956-ban megalkotott, s rla elnevezett
Dijkstra algoritmus segtsgvel az LSDB adatait felhasznlva felpt egy olyan grfot, melynek kiindulsi pontjban a router van, s minden egyes alhlzat fel a legalacsonyabb kltsg tvonalon
lehet eljutni. Teht egy area esetben minden router LSDB-je megegyezik, azonban a grfok eltrnek, hiszen a grfok kiindulsi pontjban minden esetben ms router tallhat. Az SPF algoritmus
viszonylag nagy erforrsignye miatt rgebben sok kismret area kialaktsa volt clszer, mra
azonban a Routerek fejldsvel mr lnyegesen nagyobb area is gond nlkl kialakthat. (Fontos
ugyanakkor, hogy a nagyobb Area, nagyobb hlzati forgalmat is generl.)

OSPF Area
Az OSPF segtsgvel nagymret, sok alhlzatbl ll hlzatok is kialakthatak. Nagy hlzatok esetben azonban rdemes a hlzatot tbb rszre, gynevezett arera osztani. Fontos, hogy
Backbone Area (0.0.0.0, vagy 0-val jellt) kialaktsa minden esetben szksges, s minden area
kapcsolattal kell, hogy rendelkezzen a Backbone Area irnyban. Teht a Backbone Area biztostja
a tranzitforgalom tovbbtst a tbbi Area kztt. Ezrt sokszor nevezik tranzit arenak is.

Msik AS

Backbone
Router

Internal
Router

ABR

ASBR
AREA 0

OSPF AS
ABR

AREA 1

Internal
Router

AREA 2

9. bra: OSPF AS felptse

A 9. brn egy hrom area segtsgvel felptett OSPF autonm rendszer (Autonomous System,
AS) lthat. (AS-nek nevezzk az egy adminisztratv s/vagy mszaki fennhatsg al tartoz, kzs routing politikt alkalmaz hlzatot. ltalban egy cg hlzata.) Az brn szerepl routerek:
Backbone Router: Olyan router, melynek minden interfsze az Area 0 rsze.
Internal Router: Olyan router, melynek minden interfsze azonos Area rsze, de az
nem a Backbone.
Area Border Router (ABR): Interfszei klnbz Arek rszei. Mivel minden Area
kapcsoldik a Backbonehoz, gy ezen routerek egyik interfsze a Backbone Area rsze.
Autonomous System Border Router (ASBR): Ms AS-ekhez biztostja a kapcsolatot. (Az OSPF AS rtelmezse eltr a BGP routing protokoll esetn alkalmazottl. Az
OSPF protokollt ltalban nem alkalmazzuk EGP mdon, vals AS-ek kzti forgalom
34

kicserlsre, inkbb egy AS-en bell kerlhetnek kialaktsra OSPF, vagy ms IGP
szigetek.)

Designated s Backup Designated Router

Tbbszrs hozzfrs hlzatokban (multiple access networks) fontos az adott linken kialakul
szomszdsgi viszonyok darabszmnak alakulsa. (Pldul egy switchre tbb router csatlakozik.)
A kidolgozott megolds clja, hogy a ltrejv szomszdsgi viszonyok darabszmt ngyzetesrl
linerisra cskkentse. Az OSPF ezrt alkalmazza a routing informcik cserjre kijellt (tartalk) tvlasztkat ((Backup) Designated Router, DR s BDR). Ezeken a hlzatokon a nem DR s nem
BDR routerek csak a DR s BDR routerekkel cserlnek LSA csomagokat, gy nagymrtkben cskkentik a hlzati forgalmat, valamint tehermentestik a tbbi routert is. A lertakbl is egyrtelm,
hogy pont-pont OSPF interfsz esetn nincs DR s BDR szerepkr, hiszen csak kt router csatlakozik egy sszekttetsre, gy alkalmazsa nem cskkenten a szomszdsgi viszonyok szmt. A
DR s BDR kivlasztst a Hello csomag Rtr Priority mez rtkvel tudjuk befolysolni. ltalban
a nagyobb teljestmny, nagyobb memrival rendelkez routereknek rdemes nagyobb prioritst
adni, vagy a 0 priorits segtsgvel a nagyon kis kapacits routereken letiltani a DR/BDR szerepkrt. Azonos priorits rtkek esetn a nagyobb ID-vel rendelkez router veszi fel a (B)DR szerepkrt.

3.2. BGP-MP
A Border Gateway Protocol (BGP) egy AS-ek kzti routing protokoll (interdomain routing
protocol, IDRP, ms kifejezssel: interautonomous system, inter-AS). Jelenleg a 4-es verzija van
hasznlatban (Border Gateway Protocol 4, BGP-4), melyet az RFC 4271 definil. A BGP-4 IPv6os kiterjszetsvel (Multiprotocol Extensions for BGP-4 ) az RFC 4760 foglalkozik. Fontos megjegyezni, hogy a kt emltetten kvl mg szmtalan RFC kapcsoldik a BGP-4 protokollhoz. A
BGP egy nagyon megbzhat, sokoldalan konfigurlhat, rendkvl jl sklzhat, az internetszolgltatk, valamint a nagy hlzatokat zemeltet szervezetek krben szleskrben alkalmazottt
routing protokoll. Mind AS-ek kzt (exterior gateway protocol, EGP7), mind pedig AS-en bell
(interior gateway protocol, IGP) alkalmazhat (s alkalmazott), ugyanakkor AS-en belli alkalmazsa nehzkes, ezrt ltalban ms IGP protokollal (pl. OSPF) kzsen hasznljk. Knyvnkben
csak a BGP IPv6-os alkalmazshoz s annak megrtshz felttlenl szksges alapokat mutatjuk
be, bvebb informcikrt rdemes a kapcsold RFC-ket tanulmnyozni.
Mivel a BGP elsdlegesen EGP, s a msik AS-bl rkez informcik nem felttlenl megbzhatak, de akr tvedsbl is elfordulhatnak hibs informcik, a BGP nagyon sok szrsi lehetsget tmogat. A BGP sokrt szrse teszi lehetv az AS tulajdonosa szmra a rszre megfelel routing politika (policy) technikai megvalstst. A szrsek mellett kpes a BGP peer hitelestsre is. Erre a clra ltalban TCP MD5-t (RFC 2385) alkalmaznak, de akr IPsec segtsgvel
is biztosthat a BGP routerek kzti kommunikci biztonsga.

3.2.1. BGP alapok

A BGP fejlesztse sorn nagy hangslyt fektettek a sklzhatsgra, megbzhatsgra, s a biztonsgra. A knyv rsakor krlbell 585.000 prefix volt megtallhat a teljes IPv4 routing tblban, melyek informciit az internetszolgtatk egymssal BGP protokoll segtsgvel cserlik ki.
Ez a mennyisg ugyanakkor a BGP-nek nem okoz gondot, a legnagyobb problmt a routerek
7 Az AS-ek kzti forgalom kicserlsre az 1980-as vek elejtl az Exterior Gateway Protocol 3-as verzijt (EGP3)
hasznltk (RFC 827 s RFC 904). Innen is ered a manapsg hasznlt BGPv4 meghatrozsa EGP protokollknt. Fontos
azonban, hogy ne keverjk ssze a rgi, elavult protokollt s az AS-ek kzti mkdsre utal elnevezst.

35

memriamrete szokott okozni, mert az ilyen mennyisg adat trolsa csak kellen nagy memrival rendelkez routerekben lehetsges.
A BGP egy kibvtett tvlosgvektor (enhanced distance-vector) alap routing protokoll [4], amely
csak triggered update-eket alkalmaz s nagyon sokfle metrika (ezek a metrikk a BGP attribtumok, melyekrl ksbb lesz sz) alkalmazst tmogatja. A triggered update-eket nem azonnal tovbbtja, hanem ktegekbe sszefogva. AS-en kvli szomszdok8 fel (alaprtelmezetten) 30 msodpercenknt, mg AS-en belli irnyban (alaprtelmezetten) 5 msodpercenknt. (A ktegelt tovbbts nagyobb sklzhatsgot, ugyanakkor lassabb konvergencit is eredmnyez.) A kommunikcihoz a megbzhat adatvitelt biztost TCP-t alkalmazza, valamint (alaprtelmezetten 60
msodpercenknt) keep-alive csomagok segtsgvel gyzdik meg egy msik BGP peer elrhetsgrl. (Hiszen egy BGP szomszdsgi viszony nem felttlenl jelent link szomszdsgot is.)

BGP attribtumok
Az OSPF ismertetse sorn mr megismerkedtnk a metrika fogalmval, s azt is tudjuk, hogy az
egyes routing protokollok a metrikk alapjn dntik el azt, hogy egy-egy csomagot milyen irnyban tovbbtanak. A BGP esetben a metrikk a BGP tvonal attribtumok (BGP path attributes).
Ezek az attribtumok lehetnek ktelezen (well-known) s opcionlisan (optional) tmogatottak.
A well-known attribtumok a kvetkezk:
Mandatory (ktelezen tovbbtandk)
o Origin: a hlzat irnyba mutat route forrsa (IGP, EGP, Incomplete)
o AS-path: a hlzat mely AS-eken keresztl, s milyen sorrendben rhet el, hasznlhat pldul optimlis tvonal kivlasztsra, s segti a hurkok elkerlst is
o Next-hop: a kvetkez router IP cme a hlzat irnyba
Discretionary (ktelezen tmogatandak, de nem ktelez tovbbtani):
o Local preference: csak azonos AS-be tartoz peerek rszre (teht IBGP esetben) kerl tovbbtsra, alaprtke 100, a routerek a nagyobb rtkekkel rendelkez tvonalakat (route) preferljk azonos hlzatok irnyba
o Atomic aggregate: az tvonal (route) aggreglssal (tbb kisebb hlzat sszevonsval) kerlt ellltsra
Az opcionlis attribtumok kt csoportra oszthatk:
Tranzitv: tovbbtsa megtrtnik, valamint a felismers megjellsre kerl
Nemtranzitv (Non-transitive): csak felismers esetn kerl tovbbtsra
A legfontosabb opcionlis attribtum a community, mely tranzitvan viselkedik. A community egy
olyan numerikus rtk, mely a route-hoz kapcsolhat, annak tovbbtsakor. Segtsgvel megjellhetek az egyes route-ok, s a jellsek ksbb felhasznlhatk a hasznlni kvnt route-ok
kivlasztsra.

3.2.2. BGP kapcsolat kialaktsa

A BGP esetben minden egyes szomszd (neighbor) manulis belltsa szksges. Mg az OSPF
esetben a szomszdok kpesek egymst automatikusan felderteni, egy EGP esetben ennek a
mdszernek az alkalmazsa nem clszer (pl. biztonsgi okokbl), gy a routereken az egyes peerek paramtereinek manulis belltsa szksges. Ilyen paramterek lehetnek pldul:
a neighbor IPv4 vagy IPv6 cme (ktelez)
a neighbor AS-e (ktelez)
authentikci esetn az alkalmazott jelsz (MD5 shared secret)
8

Ahol az OSPF-tl eltren nem felttlenl kzvetlen szomszdsgrl van sz.

36

 a kommunikci sorn felhasznlt forrs IP-cm

a szomszdtl maximlisan elfogadott prefixek-szma
kimen s bejv szrsek
Egy BGP router a szomszdaival a 179-es TCP porton kommunikl. rdekes hlzati konfigurcik is kialakthatak, ha figyelembe vesszk azt is, hogy kt szomszd BGP routernek nem kell
felttlenl ugyanazon alhlzatban lennie. Erre mutat pldt a 10. bra. (Megjegyezzk, hogy az
RFC 5398 rgzt dokumentcis clokra AS azonostkat, a jobb ttekinthetsg rdekben mgsem azokat, hanem az RFC 6996 szerinti privt AS szmokat hasznlunk a pldkban.)
Ezen topolgia alkalmazsakor figyeljnk arra, hogy a statilkus routeren a megfelel routing tbla
bejegyzseket ltrehozzuk!

AS 65000

AS 65001
BGP router

Statikus router

BGP router

10. bra: Multihop BGP kialaktsa

3.2.3. BGP kommunikci

BGP fejlc formtum
A BGP kommunikci sorn az zenetek a kvetkez (RFC 4271 ltal meghatrozott), fix 19
byte hosszsg fejlc alkalmazsval kerlnek tovbbtsra:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
+
|
Marker
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Length
|
Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Az egyes mezk jelentse a kvetkez:

Marker: kompatibilitsi okokbl kerlt alkalmazsra, rtke csupa 1-es.
Length: az zenet teljes hosszt adja meg, beleszmolva a headert is.
Type: rtke az 5 fle zenettpust azonostja:
o 1 - OPEN
o 2 - UPDATE
o 3 - NOTIFICATION
o 4 - KEEPALIVE
o 5 - ROUTE-REFRESH

37

BGP open zenet

A BGP kapcsolat kialaktsa sorn elsknt a BGP open zenet kerl tovbbtsra. Az open zenet RFC 4271 alapjn a kvetkez mdon pl fel:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|
Version
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
My Autonomous System
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Hold Time
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
BGP Identifier
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
Optional Parameters (variable)
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Az egyes mezk tartalma s felhasznlsa a kvetkez:

Version: Megadja a router ltal hasznlt BGP verziszmt. rtke 4.
My Autonomous System: Megmutatja, hogy a router mely AS-ben talhat. Fontos
megjegyezni, hogy az RFC 4893 (mr elavult), majd az RFC 6793 (rvnyes) kibvtette
a BGP alkalmazsa esetn hasznlhat AS-ek szmt 4 byte hosszra (ami a kompatibilits megtartsa miatt nem volt trivilis feladat).
Hold Time: A kld router ltal javasolt megrzsi idtartam, mely azt mondja meg,
hogy a cmzett router mennyi ideig kezelje rvnyesknt a kld routert. 0 rtke esetn
nem kerlnek kikldsre a keepalive zenetek.
BGP azonost: Eredetileg a router egyik IPv4-es cme, majd az RFC 6286 megjelenstl, brmely nem nulla rtk, ngy byte hossz, eljel nlkli egsz szm, mely az
adott AS-ben elfordul BGP routerek kzt egyedi.
Optional Parameters Length: Az opcionlis paramterek teljes hossza.
Optional Parameters: Az opcionlis paramterek a kvetkez (RFC 4271 szerinti) formtumban:
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Parm. Type
| Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Szmunkra az opcionlis paramter mezk a klnsen rdekesek, hiszen itt helyezhet el annak
az informcinak a hirdetse is, hogy a router kpes az IPv6 tmogatsra. A BGP capability hirdetsnek mdjt az RFC 5492 rja le. Amennyiben az Optional parameter type mez rtke 2,
akkor az Capabilities Optional Parameter-t azonost a kvetkez (RFC 5492 szerinti) formban
(ismtlds esetn mindhrom mez ismtldik):

38

+------------------------------+
| Capability Code (1 octet)
|
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
~
~
+------------------------------+

A BGP Multiprotocol extension hirdetse esetn a Capability Code mez rtke 1, mg a

Capability Length mez rtke 4. A Capability value felptse (RFC 4760 alapjn) a kvetkez:
0
7
15
23
31
+-------+-------+-------+-------+
|
AFI
| Res. | SAFI |
+-------+-------+-------+-------+

Az egyes mezk a kvetkez jelentssel brnak:

AFI - Address Family Identifier: 1-es rtke IPv4-et, mg 2-es rtke IPv6 protokollt
jelez
(http://www.iana.org/assignments/address-family-numbers/address-familynumbers.xhtml).
Res. Reserved: rtkt a kldnek 0-ra kell lltania, a fogadnak pedig figyelmen
kvl kell hagyina a mezt.
SAFI - Subsequent Address Family Identifier: a hasznlt rtkek megtallhatk az
IANA
oldaln
(http://www.iana.org/assignments/safi-namespace/safinamespace.xhtml).

BGP keepalive zenet

A BGP open zenet kikldse utn a kld router vlaszknt szintn egy open zenetet vr. Ha
ez az zenet megrkezik, s a benne lv paramterek megfelelek, ltrejhet a BGP kapcsolat a
kt szomszd router kzt. Ahhoz, hogy a kapcsolat tnylegesen ltrejjjn a routereknek mg
keepalive zenetekkel is nyugtzniuk kell azt. Annak rdekben, hogy a kapcsolat ellenrzse folyamatosan megtrtnjen rendszeres idkznknt BGP keepalive zenetek kerlnek tovbbtsra.
Abban az esetben, ha egy BGP szomszddal a hold-time idtartamn bell nem sikerl keepalive
zenetet cserlni, akkor a router a kapcsolatot megszntknt kezeli s megteszi a szksges tovbbi
lpseket. (Pl: Routing tbla mdostsa, tbbi neighbor rtestse, stb.)
A keepalive zeneteket hold-time/3 idtartamonknt ajnlott kikldeni. A keepalive zenet csak
a 19 byte hossz BGP headerbl ll.

BGP update zenet

Feladata az tvlasztsi informcik tovbbtsa az egyes BGP routerek kzt. Egy update zenet
tovbbthat olyan lehetsges tvonalakat, melyek ugyanolyan tvonal attribtumokon osztoznak,
vagy visszavonhat megsznt tvonalakat. Egy update zenet minden esetben tartalmazza a BGP
fejlcet, valamint a kvetkez zenetfajtk egy rszt (RFC 4271):

39

+-----------------------------------------------------+
|
Withdrawn Routes Length (2 octets)
|
+-----------------------------------------------------+
|
Withdrawn Routes (variable)
|
+-----------------------------------------------------+
|
Total Path Attribute Length (2 octets)
|
+-----------------------------------------------------+
|
Path Attributes (variable)
|
+-----------------------------------------------------+
|
Network Layer Reachability Information (variable) |
+-----------------------------------------------------+

Az egyes mezk jelentse a kvetkez:

Withdrawn Routes Length: az tvonal visszavonsi informcik hosszt adja meg byteban. 0 esetn nincs visszavons;
Withdrawn Routes: maguk a visszavont tvonalak a kvetkez formtumban:
+---------------------------+
|
Length (1 octet)
|
+---------------------------+
|
Prefix (variable)
|
+---------------------------+

Length: az IPv4 cm prefix bitjeinek szmt adja meg,

Prefix: az IPv4 cm prefixe, mely a hlzatot azonostja (byte hatrra kiegsztve),
Total Path Attribute Length: az tvonal attribtumok hosszt adja meg;
Path Attributes: maguk az tvonal attribtumok a kvetkez formtumban (visszavons esetn nem rsze az zenetnek, nem trgyaljuk rszletesen):
o
o

0...................1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Network Layer Reachability Information (NLRI): az IPv4 cm prefixek listja a

Withdrawn Routes meznl megadott formtumban.
A fenti informcik alapjn az RFC 4271-ben definlt BGP-v4 nem kpes IPv6 routing informcik tovbbtsra, ezrt az RFC 4760 kiegsztette azt az IPv6 tmogatshoz szksges kt tovbbi
opcionlis s nem tranzitv attribtummal (gy ha egy MP-BGP-t nem tmogat router kap ilyen
attribtumot, akkor azzal nem foglalkozik, s nem is tovbbtja):
Multiprotocol
Reachable
Network
Layer
Reachability
Information
(MP_REACH_NLRI): az elrhet hlzatok, s a next-hop informcikat tovbbtja
a kvetkez formtumban:

40

+---------------------------------------------------------+
| Address Family Identifier (2 octets)
|
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)
|
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet)
|
+---------------------------------------------------------+
| Network Address of Next Hop (variable)
|
+---------------------------------------------------------+
| Reserved (1 octet)
|
+---------------------------------------------------------+
| Network Layer Reachability Information (variable)
|
+---------------------------------------------------------+

Address Family Identifier s Subsequent Address Family Identifier: korbban

mr ismertettk,
o Length of Next Hop Network Address: a next hop cmnek hossza byte-ban,
o Network Address of Next Hop: a next hop cme,
o Reserved: a kld ktelezen 0 rtkre lltja, mg a cmzett figyelmen kvl
hagyja,
o Network Layer Reachability Information (NLRI): a lehetsges tvonalak listja;
Multiprotocol
Unreachable
Network
Layer
Reachability
Information
MP_UNREACH_NLRI: az elrhetetlenn vlt hlzatok listjt tovbbtja a kvetkez formtumban:
o

+---------------------------------------------------------+
| Address Family Identifier (2 octets)
|
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet)
|
+---------------------------------------------------------+
| Withdrawn Routes (variable)
|
+---------------------------------------------------------+

Address Family Identifier s Subsequent Address Family Identifier: korbban

mr ismertettk,
o Withdrawn Routes: a visszavont tvonalinformcik listja a Network Layer
Reachability Information (NLRI) mezvel megegyez formtumban.
A Network Layer Reachability Information (NLRI) listban egy, vagy tbb prefix kerl tovbbtsra a kvetkez formtumban (RFC 4760):
o

+---------------------------+
|
Length (1 octet)
|
+---------------------------+
|
Prefix (variable)
|
+---------------------------+

A kt mez jelentse a kvetkez:

Length: a cm prefix bitjeinek szmt adja meg;
Prefix: a cm prefixe, mely a hlzatot azonostja (byte hatrra kiegsztve).

41

BGP notification zenet

Hiba szlelse esetn a router BGP notification zenetet kikldsvel rtesti a szksges
router(eke)t, majd lezrja a kapcsolatot. RFC 4271 szerinti formtuma a kvetkez:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code
| Error subcode |
Data (variable)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Az egyes mezk jelentse a kvetkez:

Error code: az rtests tpust hatrozza meg
Error subcode: rszletesebb informcikat nyjt a hiba termszetrl (bvebben: RFC
4271)
Data: informcik a hiba oknak feltrshoz. Pontos tartalma az Error code s Error
subcode mez rtktl fgg. Bvebben: RFC 4271

3.3. PIM-SM
3.3.1. Bevezet
Szmos IP multicast routing protokoll ltezik. Ilyenek pldul az OSPF multicast prja az
MOSPF (Multicast Open Shortest Path First, RFC 1581), a DVMRP (Distance Vector Multicast
Routing Protocol, RFC 1075), s a Core-Based Trees (RFC 2189) is. A PIM (Protocol Independent
Multicast) pedig egy protokollcsald. A PIM multicast routing protokoll valamely unicast routing
protokolltl (pl. OSPF) szerzett routing informci alapjn pt multicast fkat, ezrt is hvjk protokoll fggetlennek (protocol independent). Ngy vltozata van:
1. PIM-DM (PIM Dense Mode, RFC 3973) gy pt multicast fkat, hogy az egsz
hlzatot elrasztja multicast forgalommal, s azutn levgja azokat az gakat, ahol
nincsenek multicast vevk. Amint a neve is mutatja, hasznlata akkor elnys, ha a
hlzatban srn helyezkednek el a multicast forgalomra ignyt tart llomsok.
2. PIM-SM (PIM Sparse Mode, RFC 4601) Nem ttelez fel mindenhol csoporttagokat,
csak arra kld multicast forgalmat, ahonnan arra ignyt jelentettek be. A forgalom tovbbtsra az n. randev pontban (Rendezvous Point) gykerez, tbb forrs forgalma
ltal megosztottan hasznlt fkat (shared trees) pt. Opcinlisan hasznlhat forrsonknt
legrvidebb utat megvalst fkat is. Mkdst rszletesen bemutatjuk.
3. PIM-SSM (PIM Source-Specific Multicast, RFC 4607) Egyetlen forrsban gykerez
multicast fkat pt fel, gy nincs szksge RP-re. A PIM-SM-nl elvileg szkebb krben,
tipikusan valamilyen tartalom broadcast jelleg tovbbtsra hasznhat. IPTV szolgltatsra viszont ez is elg, ezrt a jvben vrhatan terjedni fog a hasznlata.
4. BIDIR-PIM (Bidirectional PIM, RFC 5015) A PIM-SM olyan vltozata, amely a forrsokat s a vevket sszekt ktirny megosztott fkat pt. A PIM-SM-mel ellenttben
sohasem pt forrsonknt legrvidebb utat megvalst fkat.
Ezek kzl a PIM-SM protokollt IPTV rendszerekben elterjedten hasznljk, ezrt azt fogjuk
rszletesen bemutatni.

42

3.3.2. A PIM-SM mkdse

A protokoll mkdst [5] cikknk alapjn mutatjuk be. Amint emltettk, a PIM-SM nem rendelkezik sajt topolgiafeldert algoritmussal, hanem az adott autonm rendszerben hasznlt
unicast routing protokoll routing adatbzist (RIB: Routing Information Base) hasznlva pti fel a
sajt multicast routing adatbzist (MRIB: Multicast Routing Information Base). Mg a unicast
routing adatbzisok egy adott hlzat fel a kvetkez tvlasztt (next hop router) adjk meg, addig
a multicast routing adatbzisban az adattovbbtssal ellenttes irny (reverse-path) informcit
troljk (ksbb ltni fogjuk, hogy mirt: erre haladnak a PIM Join/Prune zenenetek).
A PIM-SM protokoll mkdsnek hrom fzisa van, a tovbbiakban rviden ismertetjk, hogy
mi trtnik ezekben a fzisokban, de elbb mg megismernk egy fontos fogalmat.

A randev pont
Mivel a PIM-SM a brmely forrs multicast (ASM: Any-Source Multicast) routing protokollok kz
tartozik, a vevknek valahogy meg kell tallniuk a multicast forrst vagy forrsokat. Ezt a clt szolglja a tallkozsi pont vagy randev pont (RP: Rendezvous Point). Az RP-t statikusan bellthatja az
adott AS adminisztrtora vagy egy megfelel algoritmussal megvlaszhatjk az adminiszrtor ltal
RP jelltnek (Candidate RP) belltott routerek kzl. Egy AS-ben vagy multicast tartomnyban
multicast csoportonknt logikailag csak egy RP lehet. Ennek nem mond ellent, hogy ltezik az n.
Anycast RP (RFC 4610) megolds, amikor tbb RP pldny van egy multicast tartomnyban, s ezek
ugyanazt az IP-cmet hasznljk (anycast cmzssel).

1. fzis: RP-tree
Az els fzisban a randev pontban gykerez fa (Rendezvous Point Tree) pl fel a kvetkez mdon. A vevk az MLD (Multicast Listener Discovery, RFC 3810) protokoll hasznlatval Multicast
Listener Report zenetekkel jelzik az ignyket valamely multicast csoport forgalmra. A vev kijellt
routere (DR: Designated Router, ezt korbban mr megvlasztottk a helyi routerek kzl) ennek
az zenetnek a hatsra PIM Join zenetet kld az ignyelt multicast csoport RP-jnek. Ez a PIM
Join zenet thalad a hlzatban az RP fel vezet t routerein, amelyek elksztik a megfelel
MRIB bejegyzseket, s gy felpl az RP-fa. Egy PIM Join zenet jellse (S, G), ahol az els elem
a forrs IP-cme, a msodik elem pedig a csoport IP cme (ennek a prefixe termszesen FF00::/8).
A (*, G) jells pedig azt jelenti, hogy a vev a G multicast csoport minden forrsra ignyt tart.
Fontos, hogy a forrs IP-cme ismeretnek hinyban a DR elszr mindig (*, G) Join zenetet
kld! (Majd a 3. fzisban lesz lehetsge a forrs alapjn val finomtsra.) A PIM Join zeneteknek
nem mindig kell az RP-ig eljutniuk, hanem elg, ha elrnek egy olyan pontot, ahol az RP-fa mr
kiplt. Az RP-ft azrt hvjk megosztott fnak (shared tree), mivel minden forrs multicast forgalma
ugyanazt a ft hasznlja. A PIM Join zeneteket a DR periodikusan kldi, amg ltezik az adott
csoportnak legalbb egy tagja (van olyan vev, aki az adott multicast csoport forgalmra ignyt tart).
Amikor az RP-fnak egy levl (leaf) azaz a fban csak egyetlen kapcsolattal rendelkez hlzatban az utols tag is elhagyja a G csoportot, akkor a DR egy (*, G) jells PIM Prune zentet kld
az RP fel, s a ft vissszametszik addig a pontig, ahol mg vannak aktv vevk.
Amikor egy S forrs adni kezd egy G multicast csoport szmra, akkor a forrs DR-e a multicast
adatcsomagokat regisztrcis zeneteknek (Register messages) nevezett unicast csomagokba gyazza
be, amelyeket az RP-nek cmez. (Az RP router ezekbl az zenetekbl szerez tudomst arrl, hogy
az S forrs szeretne multicast forgalmat kldeni.) Az RP kibontja a regisztrcis zeneteket, s az
RP-fa mentn tovbbtja a megfelel multicast csoport szmra (ha ltezik legalbb egy tagja). A
folyamat mkdst a 11. bra mutatja be. A multicast tovbbts ekkor mr funkcionlisan mkdik, a tovbbi kt fzis csak a hatkonysgot szolglja.

43

11. bra: A PIM-SM mkdse 1. fzis [5]

2. fzis: register-stop
Az RP egy (S, G) Join zenetet kld az S forrsnak. Amint ez az zenet a S forrs fel halad, a
routerek bejegyzik az (S, G) prt a multicast routing adatbzisukba (MRIB), ha eddig mg nem
szerepelt benne. Amikor a Join zenet a forrs hlzatba vagy egy olyan routerhez r, amelynl az
MRIB-ben mr szerepelt az (S, G) bejegyzs, akkor a multicast tartalom az S forrstl RP fl
multicast mdon is ramlani fog. (gy az RP-hez az ads dupln rkezik meg.) Ezzel mr felplt
egy forrs specifikus muticast fa az S forrstl az RP-ig. Ezutn az RP egy regisztrci vge (Register-Stop)
zenetet kld, jelezve a forrs DR-nek, hogy mr nem kell kldenie a regisztrcis zeneteket

12. bra: A PIM-SM mkdse 2. fzis [5]

44

(amelyek a multicast forgalmat unicast csomagokba gyazzk be). A 2. fzis mkdst a 12. bra
mutatja be.

3. fzis: shortest-path tree

Lehetsges, hogy a multicast csomagok tja a forrstl az RP-n t a vevkig nem optimlis. Ennek
a kikszblse rdekben a vev DR-e kezdemnyeheti (MAY, fontos, hogy ez opcionlis) egy
forrs specifikus legrvidebb utat megad fa (source specific shortest-path tree) felptst a forrs fel
(amely esetleg nem tartalmazza az RP-t). A vev DR-e ezt gy oldja meg, hogy egy (S, G) Join
zentet kld az S-nek. Amikor ez az zenet megrkezik az S hlzatba vagy egy olyan routerhez,
amelynl az MRIB-ben mr szerepel az (S, G) bejegyzs, akkor a multicast forgalom az S forrstl
a vev fel az j forrs specifikus SPT-n t is ramlani fog. Ekkor a vev DR-e minden adatcsomagot ktszer kap meg, ezrt az RP-fn keresztl rkez, az S forrstl a G csoportnak szl multicast
csomagokat eldobja. Ennek az llapotnak a kikszblsre a vev DR-e egy (S, G) Prune zenetet
kld az RP-nek. (Ezt az zenetet gy is hvjk, hogy (S, G, rpt) Prune.) Ez a Prune zenet lemetszi
a szksgtelen fagakat s a multicast ads tbb nem fog az RP-fn keresztl rkezni a vevhz.
Megjegyzs: mindezt (belertve a csomageldobst s a Prune kldst) a vev DR-e helyett egy tle
a forrs fel lev (upstream) router is elvgezheti, ha a dupln rkezs jelensgt szleli. A 3. fzis
mkdst a13. bra mutatja be.

13. bra: A PIM-SM mkdse 3. fzis [5]

3.3.3. A PIM-SM hibatrse

A PIM-SM hibatrsnek fontos eleme, hogy az RP-t nem szksges kzzel belltani, hanem az
RP automatikusan megvlaszhat az RP-jelltknt (C-RP: Candidate RP) belltott routerek kzl.
A vlaszts az RFC 5059-ben lert bootstrap mechanizmust hasznlja. Ehhez mg egy elzetes
lpsre van szksg, melynek sorn elszr egy gynevezett BSR routert vlasztanak meg azok kzl
a PIM-SM routerek kzl, amelyeket BSR jelltnek (C-BSR: Candidate BSR) lltottak be. A BSR
megvlasztshoz a C-BSR routerek elrasztjk a multicast tartomnyt (multicast domain) a bootstrap
zeneteikkel (BSM: Bootstrap message), melyben megadjk a sajt prioritsukat. Amelyik a C-BSR
router a sajtjnl nagyobb priorits C-BSR router zenett hallja, az egy ideig nem kld tovbbi
sajt BSM-et. gy vgl a legnagyobb priorits nyer. A BSR megvlasztsa kzben az sszes router
45

(belertve a C-RP routereket is) megtanulja a BSR IP-cmt. Eztun a C-RP routerek periodikusan
kldik az RP jellt hirdets (C-RP-Adv: Candidate-RP-Advertisement) zeneteiket a BSR-nek. (A CRP-Adv zenetek kldsnek peridusidejt C_RP_Adv_Period nvvel illetik, melynek alaprtelmezett rtke 60 msodperc.) A BSR begyjti a C-RP-Adv zeneteket, s az RP jelltekrl listt kszt
(RP list), majd a listt egy bootstrap zenetbe (BSM, ugyanolyan tpus zenet, mint amit a BSR
megvlasztshoz is hasznltak) gyazva periodikusan elkldi az sszes PIM-SM routernek (peridusid: BS_Period, alaprtelmezett rtk: 60 msodperc). Minden PIM-SM router (belertve a BSRt s a C-RP-ket is) sajt maga kpes C-RP-k prioritsa alapjn a gyztes RP meghatrozsra. (Ezt
mindegyik PIM-SM router maga vgzi el, s a vgs eredmny meghatrozsakor a BSM-ben kapott
informcin tl figyelembe veszi a benne statikusan belltott informcit is.)
Megjegyzs: multicast csoportonknt klnbz RP-k lehetnek, az RP-ket csoportcmmel egytt
hirdetik. St egy RP tbb csoporthoz is tartozhat, ennek a hatkony megadsra a csoportcmen
tl csoportmaszkot (group mask) is tovbbtanak.
Ha az aktulis RP nem kld C-RP-Adv zenetet a BSR-nek RP Holdtime (a C-RP-Adv zenetben
megadott rtk: a hirdets ennyi ideig rvnyes) idn bell, akkor a BSR gy dnt, hogy az adott
RP nem mkdik s j RP listt kezd el hirdetni a nem mkdnek tlt RP kihagysval.
A C-RP routerek lellsukat a BSR szmra 0 rtk RP Holdtime megadsval tudjk jelezni.
Ilyenkor az BSR azonnal j RP listt hirdet az adott C-RP kihagysval. A C-RP routereknek a CRP-Adv zenetben legalbb 2,5*max(BS_Period, C_RP_Adv_Period) nagysg RP Holdtime rtket kell (SHOULD) megadniuk, gy a rendszer kpes tolerlni nhny BSM s/vagy C-RP-Adv
zenet elveszst.
A C-BSR routerek arra is gyelnek, hogy a megvlasztott BSR router mkdik-e, ellenkez esetben j BSR-t vlasztanak. Ha egy C-BSR router BS_Timeout ideig (alaprtelmezett rtk 130 msodperc) nem kap BSM zenetet, akkor egy BSM zenet kibocstsval elindt egy BSR vlasztst.

3.4. Linux rendszerek konfigurlsa

Knyvnkben a Debian alap Linux disztribcik belltst ismertetjk, aminek f oka a Debian
s az Ubuntu disztribcik szleskr elterjedse. Ebben a fejezetben csak a natv IPv6 konfigurlst ismertetjk rszletesen. A klnbz ttrsi technikk (tunnel, NAT) ismertetsvel s vizsglatval kln fejezetek foglalkoznak. A lertak alkalmazsakor figyelembe kell venni, hogy a Linux
kernel IPv6 tmogatsa gyorsan s folyamatosan vltozik, fejldik; egyre jabb funkcik jelennek
meg, az alaprtelmezett rtkek, belltsok vltoznak, gy a lertaktl eltr mkds is elfordulhat.

3.4.1. Alapbelltsok
Az egyes hlzati vezrlkhz rendelt IPv6 cmeket az IPv4 esetben is megszokott ifconfig
parancs alkalmazsval krdezhetjk le:
root@Debian:~# ifconfig
eth0
Link encap:Ethernet HWaddr 00:15:5d:20:42:33
inet addr:10.0.0.10 Bcast:10.0.0.127 Mask:255.255.255.192
inet6 addr: 2001:db8::215:5dff:fe20:4233/64 Scope:Global
inet6 addr: fe80::215:5dff:fe20:4233/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:22015 errors:0 dropped:3138 overruns:0 frame:0
TX packets:8063 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1746432 (1.6 MiB) TX bytes:920169 (898.6 KiB)

46

Jl lthat az IPv6 mkdshez szksges link local, valamint a mdostott EUI-64 alkalmazsval automatikusan hasznlatba vett IPv6-os cm is. Ebben az esetben az tvlasztn, mellyel a
szmtgp kapcsolatban van, engedlyezett a Router advertisement, gy a korbban mr ismertetett
SLAAC segtsgvel automatikusan jutott IPv6 cmhez a szmtgp. Ha nem alkalmazunk
SLAAC-t s DHCP-t, vagy egy knnyebben megjegyezhet cmet szeretnnk fixen a szmtgphez rendelni, gy a /etc/network/interfaces llomnyban tehetjk ezt meg az inet6 stanza
alkalmazsval (feltve, hogy nem hasznlunk pldul Network Managert). A hlzati maszk hoszszt a bitek darabszmval adhatjuk meg:
iface eth0 inet6 static
address 2001:DB8::10
netmask 64
gateway 2001:DB8::1

Ha rendelkeznk IPv6 DHCP szerverrel s stateful auto address konfigurcit alkalmazunk, akkor az IPv4 protokollhoz hasonlan a static szcska helyre a dhcp-t kell rni. Ha kifejezetten az
SLAAC alkalmazst szeretnnk, akkor pedig az auto a megfelel sz.
A Linux verzitl fggen elfordulhat, hogy nem csak a statikusan belltott cmet hasznlja szmtgpnk, hanem az SLAAC segtsgvel hasznlatba vettet is:
root@Debian:~# ifconfig
eth0
Link encap:Ethernet HWaddr 00:15:5d:20:42:33
inet addr:10.0.0.10 Bcast:10.0.0.127 Mask:255.255.255.192
inet6 addr: 2001:db8::215:5dff:fe20:4233/64 Scope:Global
inet6 addr: fe80::215:5dff:fe20:4233/64 Scope:Link
inet6 addr: 2001:db8::10/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112 errors:0 dropped:7 overruns:0 frame:0
TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16145 (15.7 KiB) TX bytes:10324 (10.0 KiB)

Ezt rdemes megszntetni, mert nem kvnt mkdst is elidzhet. Tbb megoldst is alkalmazhatunk, melyek kzl taln a legegyszerbb a hlzati vezrlk konfigurcijt tartalmaz llomny
mdostsval a SLAAC alkalmazsnak letiltsa:
iface eth0 inet6 static
address 2001:DB8::10
netmask 64
gateway 2001:DB8::1
post-up echo 0 > /proc/sys/net/ipv6/conf/default/accept_ra
post-up echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra
post-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
post-up echo 0 > /proc/sys/net/ipv6/conf/default/autoconf
post-up echo 0 > /proc/sys/net/ipv6/conf/all/autoconf
post-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf

Az IPv6 nvszerverek belltst az IPv4-hez hasonlan a /etc/resolv.conf llomnyban vgezhetjk el. Hasznlhatunk csak IPv4-es, vagy csak IPv6-os, vagy mindkt tpus nvszervereket
47

egyarnt. A DNS mkdsbl addan mindegy, hogy milyen verzij IP cmen rhet el a nvszerver, az nem befolysolja a mkdst.
A routing tbla manipulcijt az ip parancs alkalmazsval rdemes elvgezni. Amennyiben a
parancs alkalmazsakor megadjuk a -6 paramtert, gy a kiadott parancsok az IPv6 protokollra
rvnyesek. Ezek alapjn a routing tbla kiratsa:
root@Debian:~# ip -6 route
2001:db8::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
ff00::/8 dev eth0 metric 256
default via 2001:db8::1 dev eth0 metric 1

j bejegyzs hozzadsa a tblhoz, teht egy statikus tvonal (route) ltrehozsa az add paramterrel lehetsges. Pldul egy olyan statikus route, mely szerint a 2001:db8:1::/64 hlzat a
2001:db8::2 IPv6 cm tjrn rhet el, a kvetkez paranccsal hozhat ltre:
root@Debian:~# ip -6 route add 2001:db8:1::/64 via 2001:db8::2

A parancs eredmnye pedig:

root@Debian:~# ip -6 route ls
2001:db8:1::/64 via 2001:db8::2 dev eth0 metric 1024
2001:db8::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
ff00::/8 dev eth0 metric 256
default via 2001:db8::1 dev eth0 metric 1

Route bejegyzs trlse a del paramterrel lehetsges, melyre plda:

root@Debian:~# ip -6 route del 2001:db8:1::/64 via 2001:db8::2

Ha a szmtgp egyik hlzati vezrlkrtyjhoz tbb IPv6-os cmet is szeretnnk hozzrendelni, gy a helyes mkds rdekben azt az ip -f inet6 addr add paranccsal vgezzk, ne az
IPv4-nl mr megszokott eth0:0 aliast alkalmazzuk. Pldul:
root@Debian:~# ip -f inet6 addr add 2001:db8::3456/64 dev eth0

Eredmnye pedig a kvetkez:

ifcroot@Debian:~# ifconfig
eth0
Link encap:Ethernet HWaddr 00:15:5d:20:42:33
inet addr:10.0.0.10 Bcast:10.0.0.127 Mask:255.255.255.192
inet6 addr: fe80::215:5dff:fe20:4233/64 Scope:Link
inet6 addr: 2001:db8::3456/64 Scope:Global
inet6 addr: 2001:db8::10/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112 errors:0 dropped:7 overruns:0 frame:0
TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16145 (15.7 KiB) TX bytes:10324 (10.0 KiB)

48

A mr feleslegess vlt msodlagos IPv6 cm eltvoltsra plda:

root@Debian:~# ip -f inet6 addr del 2001:db8::3456/64 dev eth0

Mint mr az olvas is tisztban van vele, az IPv6 protokoll az IPv4-tl eltren nem az ARP
protokollt alkalmazza az egyes hlzati (L3) cmekhez tartoz fizikai (L2) cmek feloldsra, hanem
az NDP-t. Az Linux NDP tblzatnak manipullshoz az ip -6 neigh parancs hasznlhat. A
tblzat kiratsra plda:
root@Debian:~# ip -6 neigh show
fe80::20c:42ff:fe9a:4b7a dev eth0 lladdr 00:0c:42:9a:4b:7a router REACHABLE
2001:db8::1 dev eth0 lladdr 00:0c:42:9a:4b:7a router REACHABLE

A knyv szerzinek tapasztalata szerint sajnos sokszor elfordul, hogy szmtgpnk nem tall
egy szomszdos szmtgpet. Ilyenkor sok esetben segt, ha a tblzatbl a nem elrhet eszkzt
manulisan trljk, mely utn ltalban megjavul a hlzati kapcsolat a kt szmtgp kzt. Erre
plda:
root@Debian:~# ip -6 neigh del 2001:db8::1 dev eth0

Az IPv6 csomagok tovbbtst a /proc file rendszeren keresztl engedlyezhetjk legegyszerbben:

root@Debian:~# sysctl net.ipv6.conf.all.forwarding=1

Ha szeretnnk, hogy belltsunk jraindts utn is megmaradjon, akkor clszeren a

/etc/sysctl.conf llomnyban vgezzk el ugyanezt a belltst. Tiltani pedig a 0 rtk bellt-

sval lehet.

A hlzati kapcsolatok ellenrzse a ping6 s a traceroute6 parancsok segtsgvel lehetsges,

mg a tbbi parancs megegyezik a kt protokoll esetben:
root@Debian:~# ping6 cisco.com -c 4
PING cisco.com(www1.cisco.com) 56 data bytes
64 bytes from www1.cisco.com: icmp_seq=1 ttl=232
64 bytes from www1.cisco.com: icmp_seq=2 ttl=232
64 bytes from www1.cisco.com: icmp_seq=3 ttl=232
64 bytes from www1.cisco.com: icmp_seq=4 ttl=232

time=145
time=145
time=145
time=145

ms
ms
ms
ms

--- cisco.com ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 145.316/145.400/145.434/0.469 ms

Ha egy parancs paramtereknt IPv6 cmet kell megadnunk, de nem egyrtelm, hogy hol vannak
a cm hatrai, gy a cmet [ ] jelek kz rhatjuk. Pldul:
root@Debian:~# scp * [::1]:/home

49

3.4.2. ip6tables
Az IPv4 esetben alkalmazott iptables parancsnak az IPv6 protokoll esetn alkalmazott megfelelje az ip6tables. Hasonlsguk miatt csak az ip6tables legfontosabb parancsait ismertetjk
pldk segtsgvel. Az A parancs segtsgvel egy meglv lnc vghez fzhetnk jabb sort, mg
az I parancs segtsgvel a lnc elejre szrhatunk be. Trlni a D paranccsal lehet, mg az L-lel
listzhatjuk ki a lncot.
Egy sor beszrsa a lnc vgre, mely minden csomagot eldob, ami a 2001:db8::100 cmrl rkezik:
root@Debian:~# ip6tables -A INPUT -s 2001:db8::100 -j DROP

Ha ezt a sort a lnc elejre szeretnnk beszrni:

root@Debian:~# ip6tables -I INPUT -s 2001:db8::100 -j DROP

Kirja a lncok tartalmt a megfelelt csomagok s byteok szmval egytt:

root@Debian:~# ip6tables -L -v

Trli az els lpsben ltrehozott sort:

root@Debian:~# ip6tables -D INPUT -s 2001:db8::100 -j DROP

3.4.3. Automatikus IPv6 cmkioszts

Az IPv6 cmek automatikus kiosztsa eltr az IPv4 esetben megszokottl. Trtnhet stateless
mdon a radvd segtsgvel, valamint stateful mdon DHCP szerver s a radvd kombinlt alkalmazsval. A radvd alkalmazsa kismret hlzatok esetn clszer, ahol nincs szksg egy teljes
rtk DHCP szerver ltal nyjtott funkcionaltsra, elg csupn az IP cm, tjr, DNS szerver
automatikus hozzrendelse. Nagyobb mret hlzatokban, vagy specilis ignyek esetn javasolt
DHCP szervert is hasznlni.

Router Advertisement Daemon (radvd)

Ha SLAAC segtsgvel kvnjuk a szmtgpek IPv6 cmt belltani, akkor erre Linux rendszerek esetn a Router Advertisement Daemon (radvd) alkalmazsa javasolt. A radvd segtsgvel,
tbb ms paramter mellett automatikusan megoldhat a prefix, valamint annak lettartama, s a
DNS szerver(ek) IP cmnek belltsa is. Mivel sok helyen hasznlnak Linux alapokon mkd
routert gy fontosnak tartottuk bemutatni mkdst.
A radvd daemon belltsa a /etc/radvd.conf konfigurcis llomny segtsgvel lehetsges.
A pontos szintaxist, valamint a hasznlhat defincikat a man radvd.conf parancs segtsgvel
rathatjuk ki. Mi csak a fontosabbakat mutatjuk be:
Interfsz defincija:
interface name
{
interfsz specifikus opcik
prefix defincik
azon kliensek (listja), akik rszre hirdets trtnjen
tvonal defincik

50

rekuzv DNS szerver (RDNSS) defincik

};

Prefix definci:

prefix prefix/length
{
list of prefix specific options
};

rekuzv DNS szerver definci:

RDNSS ip [ip] [ip]

{
rdnss specifikus informcik
};

A 14. brn lthat plda alapjn vgezzk el a belltst.

eth1:
2001:db8::1/64

Kliens

Linux router
radvd-vel
s DNS szerverrel

14. bra: Linux radvd s DNS szerver

A SLAAC belltsnak els lpseknt teleptsk a radvd programot az apt-get install
radvd parancs segtsgvel, majd (a mr megismert mdon) engedlyezzk az IPv6 csomagok to-

vbbtst, ha az mg nem lenne engedlyezve!

Hozzuk ltre a /etc/radvd.conf llomnyt a kvetkez tartalommal:
interface eth1
{
AdvSendAdvert on;
prefix 2001:db8::/64 {};
RDNSS 2001:db8::1 {};
};

Az AdvSendAdvert on segtsgvel a peridikus Router Advertisement (RA) zenetek kikldst, valamint a vlaszadst a router solicitation zenetekre engedlyezzk. A prefix paramter mutatja meg a SLAAC kilens szmtgpnek, hogy az ltala generlt IPv6 cm mely hlzatba tartozzon. Az RDNSS segtsgvel pedig a DNS szerver IPv6 cmt tovbbthatjuk a kliensnek (RFC 6106
alapjn). Fontos informci, hogy nem minden kliens hasznlja fel az gy kapott DNS informcikat. Az ltalunk hasznlt Debian Linux rendszert futtat kliensen a mkds rdekben elbb telepteni kell a rdnssd csomagot (apt-get install rdnssd). (Megolds lehet mg az is, ha a radvd
mellett teleptnk egy DHCP szervert is, amely azonban csak a DNS szerver cmt segt belltani
a klienseknek. Ilyenkor a cmkioszts szintn stateless mdon trtnik.)

51

Utols lpsknt indtsuk el a radvd daemont a /etc/init.d/radvd start parancs kiadsval,

majd vizsgljuk meg a kliens hlzati interfsznek belltsait!
A mr ismert informcik szerint, a SLAAC metdus sorn a kliens sajt IPv6 cmnek utols 64
bitjt a mdostott EUI-64 algoritmus segtsgvel nllan lltja el, ahogy esetnkben is jl lthat:
eth1

Link encap:Ethernet HWaddr 00:15:5d:28:65:35

inet6 addr: 2001:db8::215:5dff:fe28:6535/64 Scope:Global
inet6 addr: fe80::215:5dff:fe28:6535/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30 errors:0 dropped:0 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3769 (3.6 KiB) TX bytes:3054 (2.9 KiB)

Ez a mdszer azonban biztonsgi problmkat idzhet el, hiszen az IPv6 cm vge viszonylag
jl klienshez kthet. Ennek a kezelsre dolgoztk ki az RFC 4941-ben rgztett privacy
extensions-t, melyet az ltalunk is hasznlt Debian Linux kliensen a /proc file rendszeren keresztl
engedlyezhetjk a kvnt interfszen, pldul a kvetkez mdon, a /etc/network/interfaces
llomnyban:
iface eth1 inet6 auto
pre-up sysctl -w net.ipv6.conf.eth1.use_tempaddr=2

A megadott 2-es rtk azt eredmnyezi, hogy rendszernk a kommunikci sorn az ideiglenes
IPv6 globlis cmet preferlja a mdostott EUI-64 algoritmus segtsgvel generlttal szemben,
mg 1-es rtk esetn a helyzet fordtott. 0 rtk (alaprtelmezs szerinti) esetn nem kerl ltrehozsra ideiglenes IPv6 cm. A megadott konfigurci esetn az interfsz belltsa a kvetkez:
eth1

Link encap:Ethernet HWaddr 00:15:5d:28:65:35

inet6 addr: 2001:db8::bd92:1aea:d646:9f30/64 Scope:Global
inet6 addr: 2001:db8::215:5dff:fe28:6535/64 Scope:Global
inet6 addr: fe80::215:5dff:fe28:6535/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2087 (2.0 KiB) TX bytes:2310 (2.2 KiB)

rdemes r figyelni, hogy a privacy extension alkalmazsa ugyan nveli a biztonsgot, ugyanakkor
okozhat problmkat a mkds sorn.
Ha valamilyen okbl a kliens nem lltja be automatikusan a kvnt paramtereket, akkor Debian
Linuxot futtat kliens esetben jl hasznlhat hibakeres eszkz az rdisc6 parancs, mely az
nidsc6 a csomag rsze:
root@Debian:~# rdisc6 eth1
Soliciting ff02::2 (ff02::2) on eth1...
Hop limit
Stateful address conf.

:
:

64 (
No

52

0x40)

Stateful other conf.

:
No
Router preference
:
medium
Router lifetime
:
1800 (0x00000708)
Reachable time
: unspecified (0x00000000)
Retransmit time
: unspecified (0x00000000)
Prefix
: 2001:db8::/64
Valid time
:
86400 (0x00015180)
Pref. time
:
14400 (0x00003840)
Recursive DNS server
: 2001:db8::1
DNS server lifetime
:
600 (0x00000258)
Source link-layer address: 00:15:5D:28:65:34
from fe80::215:5dff:fe28:6534

seconds

seconds
seconds
seconds

ISC DHCPD s radvd egyttes alkalmazsa

A szles krben alkalmazott, Internet Systems Consortium (ISC) ltal fejlesztett, szabad szoftverknt elrhet ISC DHCPD a 4.x verzijtl kezdden az IPv4 mellett mr az IPv6 protokollt is
tmogatja. Fontos azonban, hogy egy idben csak az egyik protokollal hajland mkdni, teht ha
egyidben IPv4 s IPv6 dhcp szerverre is szksgnk van, akkor kt pldnyban kell futtatni a
daemont. A kvetkezkben csak az IPv6 nll alkalmazshoz szksges alapbelltsokat mutatjuk be. Pldaknt a SLAAC bemutatsakor is hasznlt topolgit hasznljuk azzal a klnbsggel,
hogy a radvd mellett DHCP szerver is fut a Linux routeren.
Az IPv4 protokoll alkalmazsakor a DHCP szerver segtsgvel kerlnek kiosztsra az alaptjrval kapcsolatos informcik is, azonban az IPv6 esetben nem ez a mdszer kerlt kivlasztsra,
gy szksg van a radvd futtatsra is. Ehhez azonban a mr megismerttl eltr konfigurcis
llomnyt kell alkalmazni. Hozzuk ltre a /etc/radvd.conf konfigurcis llomnyt a kvetkez
tartalommal:
interface eth1
{
AdvSendAdvert on;
AdvManagedFlag on;
AdvOtherConfigFlag on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 60;
};

Az AdvManagedFlag on segtsgvel engedlyezzk a stateful mkdst, azaz az IPv6 cm krst a DHCP szervertl. Az AdvOtherConfigFlag on pedig engedlyezi a kliens szmra, hogy a
DHCP szervertl egyb belltsokat is elfogadjon. A kt intervallumot (MinRtrAdvInterval s
MaxRtrAdvInterval) azrt kell belltani, mert az alaprtelmezs szerinti rtkek olyan magasak
(200 s 600 msodperc), hogy a kliens sokszor csak indulsa utn percekkel rteslne az alaprtelmezett tjr cmrl, ugyanis ezek a paramterek lltjk be a radvd-nek a router advertisement
hirdetsek kzti idintervallumot. Indtsuk jra a radvd-t a /etc/init.d/radvd restart parancs
kiadsval!
A DHCP szerver teleptst az apt-get install isc-dhcp-server paranccsal vgezhetjk
el. Ezutn a /etc/default/isc-dhcp-server llomnyban be kell lltani az IPv6 protokoll
hasznlatt a OPTIONS="-6" sor segtsgvel. A szerver teleptse sorn automatikusan ltrejn a
/etc/dhcp/dhcpd.conf llomny, melyben a DHCP szerver belltsait elvgezhetjk. Az llomnybl nem trlve, ahhoz adjuk hozz a kvetkez sorokat:
53

subnet6 2001:db8::/64
{
range6 2001:db8::100 2001:db8::200;
option dhcp6.name-servers 2001:db8::1;
option dhcp6.domain-search "mylan.hu";
}

A subnet6 mondja meg, hogy a DHCP szerver mely interfszen fog mkdni, a range6, pedig
a kioszthat IPv6 cmek tartomnyt hatrozza meg. A kt option a nvkiszolgl cmt s a keressi zna nevt adja meg. (Ha szeretnnk prefix delegcit is hasznlni, gy a prefix6 kulcsszval adhatjuk me az e clra felhasznlhat tartomnyt.)
Hozzuk ltre a kiosztott IPv6 cmekkel kapcsolatos informcikat trol llomnyt a touch
/var/lib/dhcp/dhcpd6.leases parancs segtsgvel, majd indtsuk el a dhcpd daemont a
/etc/init.d/isc-dhcp-server start parancs kiadsval.
Ezek utn a kliens megkapja a hlzat elrshez szksges adatokat. Ha Debian Linuxot futtat
klienst hasznlunk, lehetsges, hogy a kliens nem lltja be az alaptjr cmt. Ennek oka, hogy ez
a kliens DHCP alkalmazsa sorn letiltja a RA csomagok figyelst. A problma egyszer mdon
kikszblhet a /etc/network/interfaces llomnyban, a megfelel interfsznl:
iface eth1 inet6 auto
post-up sysctl -w net.ipv6.conf.eth1.accept_ra=1

A kliens interfsznek belltsainl lthatjuk, hogy a cm a megadott tartomnybl kerlt kiosztsra:

root@Debian:~# ifconfig
eth1
Link encap:Ethernet HWaddr 00:15:5d:28:65:35
inet6 addr: 2001:db8::1af/64 Scope:Global
inet6 addr: fe80::215:5dff:fe28:6535/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:93 errors:0 dropped:0 overruns:0 frame:0
TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9339 (9.1 KiB) TX bytes:5007 (4.8 KiB)

Mg a routing tblt kiratva az tjr is lthat:

root@Debian:~# ip -6 route
2001:db8::/64 dev eth1 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
default via fe80::215:5dff:fe28:6534 dev eth1 proto kernel
expires 177sec

metric 1024

Vgl pedig, a nvszerver bellts is a DHCP szerveren megadott rtket vette fel:
root@Debian:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
# resolvconf(8)
nameserver 2001:db8::1
search mylan.hu

54

3.4.4. BIND
Szintn az ISC ltal fejlesztett, szabad szoftverknt elrhet ISC BIND segtsgvel mutatjuk be
a nvszerver konfigurcit. Pldnkban a DNS-rl szl rszben mr ismertetett znkt hozzuk
ltre.
Els lpsknt teleptsk a BIND csomagot az apt-get install bind9 parancs segtsgvel.
Azrt, hogy szervernket ne hasznljk fel DDoS tmadsokhoz, korltozzuk le rekurzv hasznlatt sajt hlzatunkra. Ehhez elszr egy ACL-t kell ltrehoznunk az /etc/bind/named.conf.local
llomnyban a kvetkezk szerint:
acl mynetwork { 127.0.0.0/8; ::1; 192.0.2.0/24; 2001:db8::/32; };

(Az ACL-ek ltrehozsa sorn az IPv4-es s IPv6-os cmeket nyugodtan keverhetjk, nincs szksg kln ACL-ek ltrehozsra.)
Engedlyezzk a korltozst a /etc/bind/named.conf.options llomnyban a kvetkez sor
elhelyezsvel:
allow-recursion { mynetwork; };

Hozzuk ltre a forward nvfeloldshoz szksges /etc/bind/db.isp.hu llomnyt a kvetkez

tartalommal:
isp.hu. 3600

SOA

dns
www

Hozzuk

dns.isp.hu. root.isp.hu. (
2015022301
; serial YYYYMMDDnn
86400
; refresh ( 24 hours)
7200
; retry
(
2 hours)
3600000
; expire (1000 hours)
172800 )
; minimum (
2 days)
NS
dns.isp.hu.
AAAA
2001:db8::1
A
192.0.2.10
AAAA
2001:db8::10

ltre

reverz

nvfeloldshoz

szksges
llo-

/etc/bind/db.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

mnyt a kvetkez tartalommal:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 SOA

dns.isp.hu. root.isp.hu. (
2015022301
; serial YYYYMMDDnn
86400
; refresh ( 24 hours)
7200
; retry
(
2 hours)
3600000
; expire (1000 hours)
172800 )
; minimum (
2 days)
NS
dns.isp.hu.
0.1.0.0.0.0.0.0 IN
PTR
www.isp.hu.
Vgl tltsk be a znkat a /etc/bind/named.conf.local llomnyban elhelyezett albbi

sorokkal:

zone "isp.hu" {
type master;

55

file "/etc/bind/db.isp.hu";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
type master;
file
"/etc/bind/db.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa";
};

Majd indtsuk jra a nvszervert a /etc/init.d/bind9 restart parancs kiadsval! Munknkat ellenrizzk le a host parancs segtsgvel:
root@Debian:~# host www.isp.hu ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:
www.isp.hu has address 192.0.2.10
www.isp.hu has IPv6 address 2001:db8::10
root@Debian:~# host 2001:db8::10 ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
domain name pointer www.isp.hu.

Mint lttuk, egy IPv6-os rekordokat (is) tartalmaz zna llomny ltrehozsa semmiben sem tr
el IPv4-es megfeleljtl, fontos azonban, hogy tbb IPv6-os opci jelent meg, melyeket IPv4-es
megfeleljktl a -v6 vgzds klnbztet meg. Pldul:
transfer-source-v6
notify-source-v6
listen-on-v6

3.5. Cisco IOS alap eszkzk konfigurlsa

A Cisco tvlaszt eszkzk alkalmazsa szleskrben elterjedt az Interneten s a privt hlzatokon egyarnt, gy belltsuk s alkalmazsuk ismerete rendkvl fontos a gyakorlati letben. A
knyv ksztse sorn a kvetkez npszer hardver, s a knyv rsakor legfrissebb szoftver verzik kerltek alkalmazsra (6. tblzat).
Annak ellenre, hogy a fent felsorolt eszkzk hardver konfigurcija s teljestmnye is klnbz, a knyvben emltett konfigurciok a kzs Cisco IOS rendszer miatt megegyeznek.
Pldnkban a 15. bra szerinti topologit fogjuk alkamazni. A topolgia kialaktsa sorn egy
gyakran alkalmazott nagyvllalati megoldst hasznltunk, ahol minden bels hlzati pont (telephely) kt kzponti adatkzponthoz (datacenter) kapcsoldik s mindkett adatkzpont kln internet szolgltatval ltest kapcsolatot. Egy vals hlzat esetben termszetesn tbb telephely
(R3) lenne, s termszetesen ezek a routerek is redundnsan csatlakoznnak a kt adatkzponthoz.
A 15. bra pldjt mint llatorvosi lovat fogjuk hasznlni nhny elterjedt konfigurci szemlltetshez.
56

nv
Router1
Router2
Router3
Router4
Router5

hardver
ASR1001-X
ASR1001-X
WS-C4500X
CISCO2911
CISCO2911

IOS (XE) szoftver

03.15.00.S - 15.5(2)S
03.15.00.S - 15.5(2)S
03.07.01.E - 15.2-3.E1
15.5(2)T
15.5(2)T

6. tblzat: A hasznlt Cisco eszkzk paramterei

15. bra: BGP s OSPF pldahlzat CISCO eszkzkkel

Bels hlzati routing protokollknt (IGP) OSPFv3-at, mg a nyilvnos Internet oldalon (EGP)
BGPv4-et (MP-BGP) fogunk hasznlni. Az OSPFv3 s a BGPv4 protokoll tmogatja az IPv4 s
IPv6 prhuzamos alkalmazst is, gy jelenleg ez az egyik legnpszerbb megolds, mind a topolgia
mind pedig a routing protokollok kivlasztshoz.
Router1 (R1) s Router2 (R2) routerek kt redundns adatkzpontot jelkpeznek. Ez a kt router
OSPFv3 routing protokollt futtat a bels hlzati forgalom, mg BGPv4 routing protokollt hasznl
a nyilvnos Internet tvonalvlasztsi informcik cserjhez.
Az R3 mint remote site (amibl tbb is lehet) csak OSPFv3 routing protokollt futtat.
Az R4 s R5 routerek az internet szolgltatkat jelkpezik, BGPv4 routing protokollt hasznlnak
a nyilvnos Internet tvonalvlasztsi informcik cserjhez.
redemes megjegyezni, hogy a gyakorlatban kln routereket, tzfalat s egyb biztonsgi-szrsi
belltsokat hasznlnak az Internet kapcsolat biztonsgnak nvelse rdekben. A BGP-OSPF
protokollok kztti hlzati cmek cserjt (redistribution) a bels hlzat biztonsgi szempontjai
alapjn rdemes szrni vagy engedlyezni. Az egyes telephelyek felosztsa a 16. brn lthat.
57

Site4: ISP1

Site5: ISP2

2001:db8:4:1/64

2001:db8:5:1/64
Gi0/0

Gi0/0
2001:db8:0:45/64

Gi0/2

Gi0/2

2001:db8:4:1::10

2001:db8:5:1::10
R4

R5
Gi0/1

Gi0/1

2001:db8:0:25/64

2001:db8:0:14/64

Site1: Datacenter

Site2: Datacenter

Gi0/0/1

Gi0/0/1

2001:db8:1:1::10

2001:db8:0:12/64

Gi0/0/2
Gi0/0/3
R1

20
01
:d
b8
:0
:1
3/
64

Gi0/0/0
2001:db8:1:1/64

2001:db8:2:1::10

Gi0/0/2
Gi0/0/3
R2

64
3/
:2
:0
b8
d
:
01
20

Gi0/0/0
2001:db8:2:1/64

Ten2/1/3

Ten1/1/3

2001:db8:3:1::10
2001:db8::1/128
R3
Ten1/1/1

2001:db8:3:1/64

Site3: Remote

16. bra: Eszkzk elhelyezkedse az egyes telephelyeken

A pldk bemutatshoz terminal/text (Command line interface, CLI) alap konfigurct hasznlunk, a parancsokat konfigurcs mdban lehet soronkt begpelni a rendszerbe. A show parancsok hasznlatakor csak a fontosabb sorokat fogjuk bemutatni.

3.5.1. IPv6 Konfigurci

A Cisco IOS alap eszkzkn az IPv6 routing alaprtelmezetten nincs engedlyezve, ezrt a
konfigurcit mindig az engedlyezssel kell kezdeni. Ugyancsak fontos meggyzdni arrl, hogy
az eszkzn fut szoftver alkalmas-e az IPv6, illetve a szksges routing protokoll(ok) futtatsra.

IPv6 engedlyezse
A kvetkez sorok bemutatjk a konfigurcis zemmd s egy konfigurcis paramter (IPv6
routing engedlyezs) vltoztatst. A ksbbiekben csak a konfigurcis parancsok kerlnek bemutatsra.
R R1>enable
Password:
R1#
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ipv6 unicast-routing ezzel engedlyezzk az unicast routingot

Cmkonfigurci s llapot lekrdezse

Az IPv6 cm(ek) bellitsa s kiratsa a kvetkezkppen trtnik:
58

R1(config)#interface GigabitEthernet0/0/0 interfsz konfigurcis md

R1(config-if)# ipv6 address 2001:DB8:1:1::1/64 IPv6 global unicast cm bellts
R1#show ipv6 interface brief cm kiratsa
<...rvidtve...>
GigabitEthernet0/0/0
[up/up]
FE80::86B8:2FF:FE1E:CA02
2001:DB8:1:1::1

Jl lthat, hogy a router a global unicast cm mellett a link-local cmet is automatikusan engedlyezte az interfszen. A global s link-local cm manulis belltst a kvetkezkppen tehetjk
meg:
R1(config)#interface gigabitEthernet 0/0/0
R1(config-if)#ipv6 address 2001:DB8:1:1::1/64
R1(config-if)#ipv6 address FE80::1 link-local link-local cm bellts
R1#show ipv6 interface brief
<...rvidtve...>
GigabitEthernet0/0/0
[up/up]
FE80::1
2001:DB8:1:1::1

A tovbbiak tekintsk gy, hogy a globlis IPv6 cmek a fenti hlzati topolgin lthat mdn
vannak belltva. A helyi hlzati szegmensek esetben a router interfszek a prefixhez tartoz legkisebb hasznlhat IPv6 cmet kaptk. Az egyes routereket sszekt hlzatokban pedig az adott
router IPv6 cmnek utols szmjegye megegyezik a router sorszmval (1-5).

Kapcsolat ellenrzse
Egy kapcsolat ellenrzshez hasznlhatjuk az egyszer ping, ssh vagy pedig a show ipv6
neighbors parancsot, ami az IPv6 neighbor discovery (ND) tblt mutatja meg. Az albbi pld-

kon bemutatjuk a kapcsolat ellenrzst, valamint az IPv6 cmek hasznlatt mindhrom mdszer
alkalmazsval.
R1#ping 2001:DB8:0:12::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:12::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R1#ssh -l admin 2001:DB8:0:12::2
Password:
R2#sh ipv6 neighbors IPv6 szomszdok listzsa
<...rvidtve...>
IPv6 Address
Age Link-layer Addr State
Interface
2001:DB8:0:25::2
0 a80c.0d83.4229 REACH Gi0/0/1
FE80::AA0C:DFF:FE83:4229
89 a80c.0d83.4229 DELAY Gi0/0/1
2001:DB8:0:12::1
0 84b8.021e.ca04 REACH Gi0/0/2
FE80::86B8:2FF:FE1E:CA04
27 84b8.021e.ca04 STALE Gi0/0/2
2001:DB8:0:23::2
0 0008.e3ff.fc04 REACH Gi0/0/3
FE80::208:E3FF:FEFF:FC04
0 0008.e3ff.fc04 REACH Gi0/0/3

59

Amennyiben a helyi hlzaton ms IPv6 eszkzk is talallhatak, gy az ICMPv6 protokoll segtsgvel ellltott ND tbla segtsgvel, az IPv4 ARP tbljhoz hasonlan lehet az aktv eszkzk L3 s L2 cmeit felderteni.

Automatikus cmek kezelse

A Cisco routerek konfigurlsakor elfordulhat, hogy a cmet automatikusan szeretnnk megkapni egy msik routertl. Ilyenkor vagy a stateless automatikus konfigurcit (SLAAC), vagy a
stateful DHCP mdot hasznlhatjuk.
A legegyszerbb a SLAAC mdszer alkalmazsa, melyet a 17. brn lthat pldn keresztl bemutatunk be, ahol R1 biztost cmet R2 rszre.
Gi0/0/1
2001:db8:1:1::10

Gi0/0/1
Gi0/0/2

2001:db8:0:12/64

Gi0/0/3
Router1

2001:db8:2:1::10

Gi0/0/2
Gi0/0/3
Router2

Prefix
Gi0/0/0

2001:db8:0:12::1

2001:DB8:0:12:86B8:2FF:FE8C:BD04

Gi0/0/0

17. bra: SLAAC alkalmazsa

R2(config)#interface gigabitEthernet 0/0/2
R2(config-if)#no ipv6 address 2001:DB8:0:12::2/64 lland cm trlse
R2(config-if)#ipv6 address autoconfig automatikus IPv6 cmbellts
R2#sh ipv6 interface gigabitEthernet 0/0/2
GigabitEthernet0/0/2 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::86B8:2FF:FE8C:BD04
<...rvidtve...>
Global unicast address(es):
2001:DB8:0:12:86B8:2FF:FE8C:BD04, subnet is 2001:DB8:0:12::/64 [EUI/CAL/PRE]
<...rvidtve...>

Routerek automatikus cmkonfigurlshoz hasznlhat a DHCPv6 protokoll is. Ezt a mdszert

az internetszolgltatk ltalnosan elterjedt mdon hasznljk, akr a bels interfsz cmnek belltsra is (nem csak a direkt interfsz konfigurlshoz). A lenti pldban egy tipikus felhasznls
kerl bemutatsra, ahol a szolgltat (R1) kett DHCP cmtartomnyt biztost a felhasznl rszre
(R2). Az R2 router az els cmet a kzvetlenl csatlakoz interfszre, a msodik cmet a bels
hlzati interfszre lltja be. Az R2 router akr jelezhet is (prefix delegation segtsgvel) a szolgltat fel a kvnt cmtartomny mretvel kapcsolatban. gy a bels hlzaton akr tbb interfszen is konfigurlhat IPv6 cm. A 18. bra pldjban az R2 router /60 cmet kr, ami akr 16
darab /64 prefix bels hlzati interfsz konfigurlshoz is elegend lehet.

18. bra: Prefix delegci mkdse

60

R2 konfigurc:
ipv6 dhcp pool ISP-pool IPv6 cmtartomny ltrehozsa
prefix-delegation pool ISP-ipv6 lifetime 1800 60 szolgltattl kapott cm
dns-server 2001:558:FEED::1
dns-server 2001:558:FEED::2
interface gigabitEthernet 0/0/2
ipv6 address dhcp szolgltattl kapunk cmet
ipv6 enable
ipv6 nd autoconfig default-route
ipv6 dhcp client pd hint ::/60 szolgltattl krnk /60 cmtartomnyt
ipv6 dhcp client pd ISP-ipv6 ezzel a nvvel azonostjuk a /60 cmtartomnyt
interface gigabitEthernet 0/0/0
ipv6 address ISP-ipv6 ::0:0:0:0:1/64 szolgltattl kapott els/64 subnet
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server ISP-pool ltalunk definilt DHCP pool, a cm a szolgltattl jn
interface gigabitEthernet 0/0/10
ipv6 address ISP-ipv6 ::1:0:0:0:1/64 szolgltattl kapott msodik/64 subnet
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server ISP-pool

3.5.2. Biztonsgi belltsok

Az IPv6 cmek szrsnek s kezelsnek belltsnl nincs nagy klnbsg az IPv4 protokollhoz
kpest. Az albbi plda bemutatja a firewall feature, valamint egy egyszer Access Control List
(ACL) belltst is.
ipv6 inspect name TRAFFIC-V6 udp IPv6 firewall bekapcsolsa a protokolcsaldra
ipv6 inspect name TRAFFIC-V6 tcp
ipv6 inspect name TRAFFIC-V6 icmp
ipv6 access-list INBOUNDV6 IPv6 plda access-list, amit az interfszen hasznlunk majd
permit icmp any any
permit udp any any eq 546
permit tcp any any established
interface gigabitEthernet 0/0/2
ipv6 inspect TRAFFIC-V6 out firewall bekapcsolsa a definilt protokolcsaldra
ipv6 traffic-filter INBOUNDV6 in az interfszre rkez csomagokra az ACL enged-

lyezse

61

3.5.3. OSPFv3
Az OSPF protokoll belltsnak bemutatshoz 19. brn lthat topologit fogjuk hasznlni.
A backbone area (area 0) a kzponti routerek kapcsolatt biztostja. Nagyobb hlzatok teleptsnl a diagramon lthat area 1, 2 s 3 ltalban tovbbi routereket is magban foglal, nem csak az
R1, R2 s R3 area border routereket.

19. bra: OSPFv3 kialaktsa

Konfigurci
A Cisco OSPFv3 implementcija az IOS Release 15.1(3)S s 15.2(1)T verziktl kezdden tmogatja az IPv6 s IPv4 protokoll egyttes alkalmazst (AF), de hasznlathoz az IPv6 protokoll
engedlyezse ktelez. Az OSPFv3 alapszint konfigurcija a kvetkez lpsekbl ll:
1. OSPFv3 routing processz definilsa:
a. A Router azonost megadsa, ami az IPv4-hez hasonlan 32 bit hossz, de nem
kell egyeznie egyik interfsz IP cmvel sem, csak a hlzaton bell egyedi kell,
hogy legyen.
b. Cm osztly definilsa. Itt az IPv6 ktelez, az IPv4 opcionlis.
2. A protokoll engedlyezse azon az interfszen, ahol az OSPF protokollt hasznlni szeretnnk.
Az albbi plda bemutatja az OSPFv3 protokoll konfigurcijt az R1-es routeren. Minden
routeren ltrehozsra kerlt egy loopback interfsz is, melynek oka, hogy ennek llapota mindig
up, gy a kapcsold processzek llapota nem fgg egy kivlasztott vals interfsz up vagy
down sttusztl.
A kivlasztott interfszeken a passzv zemmd segtsgvel megakadlyozzuk, hogy OSPF zeneteket kldjn, vagy fogadjon a router. Ennek a megoldsnak az alkalmazsa javasolt az olyan
hlzati szegmenseken, ahol nincs ms OSPF router, ugyanis segtsgvel megakadjozhatjuk, hogy
hamis OSPF zeneteket kldjenek routernk rszre.
Az albbi konfigurc bemutatja az R1, R2 s R3 OSPFv3 konfigurcijt. Az egyszer kvethetsg rdekben a local s global cmek statikusan lettek belltva. Mind a hrom routernek van
loopback interfsze, melyek passzv mdra vannak lltva:
R1 konfigurci:
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:1::1/128

62

ipv6 ospf 1 area 1 OSPF area belltsa az interfszen

!
interface GigabitEthernet0/0/0
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:1:1::1/64
ospfv3 1 ipv6 area 1
!
interface GigabitEthernet0/0/1
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:0:14::1/64
ospfv3 1 ipv6 area 0
!
interface GigabitEthernet0/0/2
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:0:12::1/64
ospfv3 1 ipv6 area 0
!
interface GigabitEthernet0/0/3
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:0:13::1/64
ospfv3 1 ipv6 area 0
cdp enable
router ospfv3 1
router-id 1.1.1.1 OSPF procesz azonost
!
address-family ipv6 unicast
passive-interface GigabitEthernet0/0/1 OSPF processz legyen inaktv az interf-

szen

passive-interface Loopback0
exit-address-family

R2 konfigurci:
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:2::2/128
ipv6 ospf 1 area 2
!
interface GigabitEthernet0/0/0
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:2:1::2/64
ospfv3 1 ipv6 area 2
!
interface GigabitEthernet0/0/1
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:0:25::2/64
ospfv3 1 ipv6 area 0
!
interface GigabitEthernet0/0/2
ipv6 address FE80::2 link-local

63

ipv6 address 2001:DB8:0:12::2/64

ospfv3 1 ipv6 area 0
!
interface GigabitEthernet0/0/3
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:0:23::2/64
ospfv3 1 ipv6 area 0
!
router ospfv3 1
router-id 2.2.2.2
!
address-family ipv6 unicast
passive-interface GigabitEthernet0/0/1
passive-interface Loopback0
exit-address-family

R3 konfigurci:
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:3::3/128
ipv6 ospf 1 area 3
!
interface TenGigabitEthernet1/1/1
no switchport
no ip address
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:3:1::1/64
ospfv3 1 ipv6 area 3
!
interface TenGigabitEthernet1/1/3
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:0:13::3/64
ospfv3 1 ipv6 area 0
!
interface TenGigabitEthernet2/1/3
ipv6 address FE80::3 link-local
ipv6 address 2001:DB8:0:23::3/64
ospfv3 1 ipv6 area 0
!
router ospfv3 1
router-id 3.3.3.3
!
address-family ipv6 unicast
passive-interface Loopback0
exit-address-family

Konfigurci ellenrzse
Az OSPF konfigurci ellenrzshez a show ospfv3 parancs alkalmazsra van szksg. Az
albbi pldk bemutatjk a fontosabb parancsokat s hasznlatukat az R1 routeren:
64

OSPF szomszdok ellenrzsre az albbi parancsot hasznljuk. Lthat, hogy R1 router a

Designated Router(DR) mindkt kapcsolatra, mig R2 s R3 router Backup Designated Routerek
(BDR):
R1#show ospfv3 neighbor
OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)
Neighbor ID
3.3.3.3
2.2.2.2

Pri
1
1

State
FULL/BDR
FULL/BDR

Dead Time
00:00:32
00:00:36

Interface ID
58
12

Interface
GigabitEthernet0/0/3
GigabitEthernet0/0/2

OSPF interfsz ellenrzse:

R1#show ospfv3 interface interfsz OSPF paramtereinek listzsa
GigabitEthernet0/0/3 is up, line protocol is up
Link Local Address FE80::1, Interface ID 13
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, local address FE80::1
Backup Designated router (ID) 3.3.3.3, local address FE80::3
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:00
Graceful restart helper support enabled
Index 1/4/4, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 6
Last flood scan time is 0 msec, maximum is 1 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 3.3.3.3 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
GigabitEthernet0/0/2 is up, line protocol is up
Link Local Address FE80::1, Interface ID 12
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, local address FE80::1
Backup Designated router (ID) 2.2.2.2, local address FE80::2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:07
Graceful restart helper support enabled
Index 1/3/3, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 4
Last flood scan time is 0 msec, maximum is 1 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Loopback0 is up, line protocol is up
Link Local Address FE80::86B8:2FF:FE1E:CA00, Interface ID 22
Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1

65

Network Type LOOPBACK, Cost: 1

Loopback interface is treated as a stub Host
GigabitEthernet0/0/0 is up, line protocol is up
Link Local Address FE80::1, Interface ID 10
Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, local address FE80::1
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Graceful restart helper support enabled
Index 1/1/1, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)

OSPF routing tbla ellenrzsre az albbi parancsot hasznljuk. Minden hlzati prefix esetn
lthat:
next-hop local-link cme
next-hop interfsz neve
administrative distance s OSPF cost.
R1#show ipv6 route ospf
IPv6 Routing Table - default - 21 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
O
2001:DB8:0:23::/64 [110/2]
via FE80::3, GigabitEthernet0/0/3
O
2001:DB8:0:25::/64 [110/3]
via FE80::3, GigabitEthernet0/0/3
OI 2001:DB8:2::2/128 [110/2]
via FE80::3, GigabitEthernet0/0/3
OI 2001:DB8:2:1::/64 [110/3]
via FE80::3, GigabitEthernet0/0/3
OI 2001:DB8:3::3/128 [110/1]
via FE80::3, GigabitEthernet0/0/3
OI 2001:DB8:3:1::/64 [110/2]
via FE80::3, GigabitEthernet0/0/3
<...rvidtve...>

rdemes megjegyezni, hogy a routing tblba csak azok az OSPF bejegyezsek kerlnek, amelyek
nem tallhatk meg kisebb administrative distance segtsgvel, azaz olyan routing protokollal,
amelyik az zemeltet ltal jobban preferlt. Pldul azok a hlzatok, amelyek kzvetlenl vannak
csatlakoztatva a kvetkez mdon rathatak ki:
66

R1#show ipv6 route connected

IPv6 Routing Table - default - 21 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
C
2001:DB8:0:12::/64 [0/0]
via GigabitEthernet0/0/2, directly connected
C
2001:DB8:0:13::/64 [0/0]
via GigabitEthernet0/0/3, directly connected
C
2001:DB8:0:14::/64 [0/0]
via GigabitEthernet0/0/1, directly connected
LC 2001:DB8:1::1/128 [0/0]
via Loopback0, receive
C
2001:DB8:1:1::/64 [0/0]
via GigabitEthernet0/0/0, directly connected

3.5.4. OSPFv3 biztonsgi belltsok

Annak rdekben, hogy az OSPFv3 csomagokat biztonsgosan clba juttathassuk, anlkl, hogy
valaki azokat mdostan, vagy hamis adatokat kldene a hlzat fel, ajnlott bekapcsolni az OSPF
authenticationt. Az OSPFv2-tl eltren ez nem egy egyszer jelszval lett megoldva, hanem a
szabvnyostott IPsec protokoll segtsgvel. (Pldnkban nem a korbban mr emltett
Authentication trailert alkalmazzuk, hanem az IPSec-et.)
A biztongi belltst megtehetjk az egsz OSPFv3 arera, de a nagyobb biztonsg rdekben,
kln bellthat minden egyes interfszre is. A router a Security Policy Indexet (SPI) s a hozz
tartoz kulcsot hasznlja a hash kulcsok belltsra s ellenrzsre.
Az OSPF interfsz biztonsgnak belltsa az albbi parancs segtsgvel vgezhet el:
ipv6 ospf encryption

{ipsec

spi spi esp

{encryption-algorithm [[key-encryption-type]
| null}

null} authentication-algorithm [key-encryption-type] key

key]

A 20. bra s a konfigurci bemutatja az OSPFv3 authentication bekapcsolst a pldahlzatunkon, az R1 s R2 router kztt, a backbone areban.
OSPFv3 IPSEC
SPI=1000, Key256bit=12345...1234

Gi0/0/1
2001:db8:1:1::10

2001:db8:0:12/64

Gi0/0/2
Gi0/0/3

Gi0/0/1
2001:db8:2:1::10

Gi0/0/2
Gi0/0/3

R1

R2
Gi0/0/0

Gi0/0/0

Ten2/1/3

Ten1/1/3

2001:db8:3:1::10
2001:db8::1/128
R3
Ten1/1/1

20. bra: OSPFv3 IPsec

67

A konfigurci belltsa utn az interfsz belltsa az R1 s R2 routereken a kvetkez:

Security Policy Index: 1000
AES-CBC encryption 256 bites kulccsal, ami 64 hexadecimlis szmjegy hossz.
SHA-1 authentication, amihez egy 40 hexadecimlis szmjegy hossz kulcs tartozik.
Termszetesen ms opcikat is lehet hasznlni, mint pldul 3DES s MD5. A kulcsok a kvethetsg rdekben lettek ilyen egyszerre rtkekre belltva.
R1 konfigurc:
interface GigabitEthernet0/0/2
no ip address
negotiation auto
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:0:12::1/64
ipv6 ospf encryption ipsec spi 1000 esp aes-cbc 256
1234567890123456789012345678901234567890123456789012345678901234 sha1
1234567890123456789012345678901234567890
ospfv3 1 ipv6 area 0

R2 konfigurc:
interface GigabitEthernet0/0/2
no ip address
negotiation auto
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:0:12::2/64
ipv6 ospf encryption ipsec spi 1000 esp aes-cbc 256
1234567890123456789012345678901234567890123456789012345678901234 sha1
1234567890123456789012345678901234567890
ospfv3 1 ipv6 area 0
end

Az ellenrzshez ltalban elg csak meggyzdni arrl, hogy az OSPF szomszdunk llapota
FULL, de lehetsg van arra is, hogy magt az IPsec kapcsolatot az SPI index segtsgvel beazonostsuk.
R1#show ipv6 ospf neighbor
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Neighbor ID
3.3.3.3
2.2.2.2

Pri
1
1

State
FULL/BDR
FULL/DR

Dead Time
00:00:33
00:00:33

Interface ID
58
12

Interface
GigabitEthernet0/0/3
GigabitEthernet0/0/2

R1#show crypto ipsec sa

interface: GigabitEthernet0/0/2
Crypto map tag: GigabitEthernet0/0/2-OSPF-MAP, local addr FE80::1
IPsecv6 policy name: OSPFv3-1000
protected vrf: (none)
local ident (addr/mask/prot/port): (FE80::/10/89/0)
remote ident (addr/mask/prot/port): (::/0/89/0)
current_peer FF02::5 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 101, #pkts encrypt: 101, #pkts digest: 101
#pkts decaps: 69, #pkts decrypt: 69, #pkts verify: 69

68

#pkts
#pkts
#pkts
#send

compressed: 0, #pkts decompressed: 0

not compressed: 0, #pkts compr. failed: 0
not decompressed: 0, #pkts decompress failed: 0
errors 0, #recv errors 0

local crypto endpt.: FE80::1,

remote crypto endpt.: FF02::5 ebbl ltszik, hogy l a kapcsolat
plaintext mtu 1462, path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb GigabitEthernet0/0/2
current outbound spi: 0x3E8(1000)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x3E8(1000)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2001, flow_id: HW:1, sibling_flags FFFFFFFF80000009, crypto map:
GigabitEthernet0/0/2-OSPF-MAP
sa timing: remaining key lifetime (sec): 0
Kilobyte Volume Rekey has been disabled
IV size: 16 bytes
replay detection support: N
Status: ACTIVE(ACTIVE) ebbl ltszik, hogy l a kapcsolat
outbound esp sas:
spi: 0x3E8(1000)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2002, flow_id: HW:2, sibling_flags FFFFFFFF80000009, crypto map:
GigabitEthernet0/0/2-OSPF-MAP
sa timing: remaining key lifetime (sec): 0
Kilobyte Volume Rekey has been disabled
IV size: 16 bytes
replay detection support: N
Status: ACTIVE(ACTIVE) ebbl ltszik, hogy l a kapcsolat

3.5.5. IPv6 MP-BGP

Az MP-BGP (BGPv4) protokoll konfigurlshoz az idig hasznlt topologihoz csatlakoztatjuk
az R4 s R5 routereket, melyek az internetszolgltatkat szimbolizljk. Az R1, R2 s R3 routerek
az Autonomous System (AS) 65000 rszei, mg az internet szolgltatk: R4 AS65004 s R5 AS65005
(21. bra).

Konfigurci
Az MP-BGP implementcija egyarnt tmogatja az IPv6 s IPv4 protokollt. Az MP-BGP alapszint konfigurcija a kvetkez lpsekbl ll:
1. MP-BGP Autonomous System (AS) szm hozzrendelse a BGP processzhez.
2. A Router azonost megadsa. Ez Cisco eszkzkn egy 32 bit hossz IPv4 cm s ktelez, hogy elrehet (up sttus) legyen. Ezrt ezt a cmet, ltalban az egyik loopback interfszhez szoktk rendelni.
3. MP-BGP szomszd(ok) definilsa.
4. IPv6 cmcsald definilsa s opcionlisan a sajt hlzatok hirdetse s szrse.
Az albbi plda bemutatja az MP-BGP protokoll konfigurcijt az R1, R2, R4 s az R5-es
routereken a fenti diagram alapjn. Segtsgknt a fenti diagramot hasznljuk a pldhoz.

69

2001:db8:0:25/64

2001:db8:0:14/64
20

01

:d

b8
:

0:

13

/6
4

20

01

:d

:
b8

2
0:

64
3/

21. bra: MP-BGP kialaktsa CISCO eszkzkkel

R1 konfigurc:
router bgp 65000 BGP Autonomous System azonostja
bgp router-id 1.1.1.1 BGP router azonostja
neighbor 2001:DB8:0:12::2 remote-as 65000 BGP szomszdok definilsa
neighbor 2001:DB8:0:14::4 remote-as 65004
!
address-family ipv6
network 2001:DB8:1::1/128 hirdetend hlzat definilsa
network 2001:DB8:1:1::/64
network 2001:DB8:2::2/128
network 2001:DB8:2:1::/64
network 2001:DB8:3::3/128
network 2001:DB8:3:1::/64
neighbor 2001:DB8:0:12::2 activate BGP szomszd engedlyezse
neighbor 2001:DB8:0:14::4 activate

R2 konfigurc:
router bgp 65000
bgp router-id 2.2.2.2
neighbor 2001:DB8:0:12::1 remote-as 65000

70

neighbor 2001:DB8:0:25::5 remote-as 65005

!
address-family ipv6
network 2001:DB8:1::1/128
network 2001:DB8:1:1::/64
network 2001:DB8:2::2/128
network 2001:DB8:2:1::/64
network 2001:DB8:3::3/128
network 2001:DB8:3:1::/64
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:25::5 activate

R4 konfigurc:
router bgp 65004
bgp router-id 4.4.4.4
neighbor 2001:DB8:0:14::1 remote-as 65000
neighbor 2001:DB8:0:45::5 remote-as 65005
!
address-family ipv6
network 2001:DB8:0:14::/64
network 2001:DB8:0:45::/64
network 2001:DB8:4::4/128
network 2001:DB8:4:1::/64
neighbor 2001:DB8:0:14::1 activate
neighbor 2001:DB8:0:45::5 activate

R5 konfigurc:
router bgp 65005
bgp
router-id 5.5.5.5
neighbor 2001:DB8:0:25::2 remote-as 65000
neighbor 2001:DB8:0:45::4 remote-as 65004
!
address-family ipv6
network 2001:DB8:0:25::/64
network 2001:DB8:5::5/128
network 2001:DB8:5:1::/64
neighbor 2001:DB8:0:25::2 activate
neighbor 2001:DB8:0:45::4 activate

A hirdetend hlzatokat s a BGP szomszdokat egyesvel kell megadni, br lehetsg van a

hlzatok sszestsre (aggreglsra) is rvidebb maszk megadsval.

Konfigurci ellenrzse
Az MP-BGP konfigurci a show bgp ipv6 parancs segtsgvel ellenrizhet. Az albbi pldk
bemutatjk a fontosabb parancsokat s hasznlatukat az R1 routerrl:
BGP szomszdok ellenrzse a show bgp ipv6 unicast neighbors parancs segtsgvel:
R1#show bgp ipv6 unicast summary

71

BGP router identifier 1.1.1.1, local AS number 65000

BGP table version is 89, main routing table version 89
13 network entries using 3536 bytes of memory
25 path entries using 3600 bytes of memory
12/7 BGP path/bestpath attribute entries using 2976 bytes of memory
4 BGP AS-PATH entries using 128 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 10240 total bytes of memory
BGP activity 13/0 prefixes, 29/4 paths, scan interval 60 secs
Neighbor
V
State/PfxRcd
2001:DB8:0:12::2
4
2001:DB8:0:14::4
4
<...rvidtve...>

AS MsgRcvd MsgSent

TblVer

InQ OutQ Up/Down

65000

371

374

89

0 04:58:50

12

65004

41

44

89

0 00:24:08

A BGP hlzati tbla ellenrzse a show bgp ipv6 unicast parancs segtsgvel lehetsges.
Fontos, hogy a tbla nem minden eleme kerl t a routing tblba, ami alapjn a csomagokat a
router majd tovbbtja.
R1#show bgp ipv6 unicast
BGP table version is 113, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

r>

Network
Next Hop
2001:DB8:0:14::/64
2001:DB8:0:14::4

Metric LocPrf Weight Path

0 65004 i

*>i 2001:DB8:0:25::/64
2001:DB8:0:25::5
0
*

100

0 65005 i

2001:DB8:0:14::4
0 65004 65005 i

* i 2001:DB8:0:45::/64
2001:DB8:0:25::5
0
*>

100

0 65005 65004 i

2001:DB8:0:14::4
0

0 65004 i

* i 2001:DB8:1::1/128
2001:DB8:0:12::2
*>
::
* i 2001:DB8:1:1::/64
2001:DB8:0:12::2

*>
*>

::
2001:DB8:2::2/128
FE80::3
* i
2001:DB8:0:12::2

100

0 i
32768 i

100

0 i
32768 i

2
0

72

32768 i
100

0 i

*>
* i

2001:DB8:2:1::/64
FE80::3
2001:DB8:0:12::2

32768 i

100

0 i

100

0 i
32768 i

100

0 i
32768 i

100

* i 2001:DB8:3::3/128
2001:DB8:0:12::2
*>
FE80::3
* i 2001:DB8:3:1::/64
2001:DB8:0:12::2

*>
FE80::3
* i 2001:DB8:4::4/128
2001:DB8:0:25::5

*>

0 65005 65004 i

2001:DB8:0:14::4
0

0 65004 i

* i 2001:DB8:4:1::/64
2001:DB8:0:25::5
0
*>

100

0 65005 65004 i

2001:DB8:0:14::4
0

0 65004 i

* i 2001:DB8:5::5/128
2001:DB8:0:25::5
0
*>

100

0 65005 i

2001:DB8:0:14::4
0 65004 65005 i

* i 2001:DB8:5:1::/64
2001:DB8:0:25::5
0
*>

100

0 65005 i

2001:DB8:0:14::4
0 65004 65005 i

A routing tbla ellenrzse a show ipv6 route parancs kiadsval lehetsges. Pldaknt nzzk
meg, hogy mit ltunk az R1, R4 s az R5 routereken:
Az R1 routeren lthat az sszes BGP router, amit R4 s R5 hirdet valamint az sszes OSPF
bels route amit R2 s R3 hirdet.
R1#sh ipv6 route
IPv6 Routing Table - default - 21 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
a - Application
C
2001:DB8:0:12::/64 [0/0]
via GigabitEthernet0/0/2, directly connected
L
2001:DB8:0:12::1/128 [0/0]
via GigabitEthernet0/0/2, receive
C
2001:DB8:0:13::/64 [0/0]
via GigabitEthernet0/0/3, directly connected
L
2001:DB8:0:13::1/128 [0/0]
via GigabitEthernet0/0/3, receive
C
2001:DB8:0:14::/64 [0/0]

73

L
O
B
B
LC
C
L
OI
OI
OI
OI
B
B
B
B
L

via GigabitEthernet0/0/1, directly connected

2001:DB8:0:14::1/128 [0/0]
via GigabitEthernet0/0/1, receive
2001:DB8:0:23::/64 [110/2]
via FE80::3, GigabitEthernet0/0/3
2001:DB8:0:25::/64 [200/0]
via 2001:DB8:0:25::5
2001:DB8:0:45::/64 [20/0]
via FE80::4, GigabitEthernet0/0/1
2001:DB8:1::1/128 [0/0]
via Loopback0, receive
2001:DB8:1:1::/64 [0/0]
via GigabitEthernet0/0/0, directly connected
2001:DB8:1:1::1/128 [0/0]
via GigabitEthernet0/0/0, receive
2001:DB8:2::2/128 [110/2]
via FE80::3, GigabitEthernet0/0/3
2001:DB8:2:1::/64 [110/3]
via FE80::3, GigabitEthernet0/0/3
2001:DB8:3::3/128 [110/1]
via FE80::3, GigabitEthernet0/0/3
2001:DB8:3:1::/64 [110/2]
via FE80::3, GigabitEthernet0/0/3
2001:DB8:4::4/128 [20/0]
via FE80::4, GigabitEthernet0/0/1
2001:DB8:4:1::/64 [20/0]
via FE80::4, GigabitEthernet0/0/1
2001:DB8:5::5/128 [20/0]
via FE80::4, GigabitEthernet0/0/1
2001:DB8:5:1::/64 [20/0]
via FE80::4, GigabitEthernet0/0/1
FF00::/8 [0/0]
via Null0, receive

Az R4 routeren lthat az sszes BGP route, amit az R4 s R5 hirdet, valamint az sszes bels
route, amit a network parancsal hirdetnk az R1 s R2 routereken keresztl. Az OSPF R1, R2 s
R3 routerek kzti sszekttetsekhez tartoz 2001:DB8:0 route-ok azrt nem lthatk itt, mert
ezeket a hlzatokat nem hirdetjk az R1 vagy R2 routereken BGP protokoll segtsgvel.
R4#show ipv6 route
IPv6 Routing Table - default - 17 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
a - Application
C
2001:DB8:0:14::/64 [0/0]
via GigabitEthernet0/1, directly connected
L
2001:DB8:0:14::4/128 [0/0]
via GigabitEthernet0/1, receive
B
2001:DB8:0:25::/64 [20/0]
via FE80::5, GigabitEthernet0/2
C
2001:DB8:0:45::/64 [0/0]
via GigabitEthernet0/2, directly connected
L
2001:DB8:0:45::4/128 [0/0]

74

B
B
B
B
B
B
LC
C
L
B
B
L

via GigabitEthernet0/2, receive

2001:DB8:1::1/128 [20/0]
via FE80::1, GigabitEthernet0/1
2001:DB8:1:1::/64 [20/0]
via FE80::1, GigabitEthernet0/1
2001:DB8:2::2/128 [20/2]
via FE80::1, GigabitEthernet0/1
2001:DB8:2:1::/64 [20/3]
via FE80::1, GigabitEthernet0/1
2001:DB8:3::3/128 [20/1]
via FE80::1, GigabitEthernet0/1
2001:DB8:3:1::/64 [20/2]
via FE80::1, GigabitEthernet0/1
2001:DB8:4::4/128 [0/0]
via Loopback0, receive
2001:DB8:4:1::/64 [0/0]
via GigabitEthernet0/0, directly connected
2001:DB8:4:1::4/128 [0/0]
via GigabitEthernet0/0, receive
2001:DB8:5::5/128 [20/0]
via FE80::5, GigabitEthernet0/2
2001:DB8:5:1::/64 [20/0]
via FE80::5, GigabitEthernet0/2
FF00::/8 [0/0]
via Null0, receive

Mivel az R3 routeren csak az OSPF protokollt futtatjuk, ezrt csak az R1 s R2 routerek OSPF
tblja kerl szinkronizlsra. Az R4 s R5 routerek ltal hirdetett hlzatok elrsre csak a default
route segtsgvel lehetsges a jelenlegi konfigurci mellett.
R3#sh ipv6 route
IPv6 Routing Table - default - 14 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter
OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1
ON2 - OSPF NSSA ext 2, a - Application
O
2001:DB8:0:12::/64 [110/2]
via FE80::1, TenGigabitEthernet1/1/3
via FE80::2, TenGigabitEthernet2/1/3
C
2001:DB8:0:13::/64 [0/0]
via TenGigabitEthernet1/1/3, directly connected
L
2001:DB8:0:13::2/128 [0/0]
via TenGigabitEthernet1/1/3, receive
L
2001:DB8:0:13::3/128 [0/0]
via TenGigabitEthernet1/1/3, receive
C
2001:DB8:0:23::/64 [0/0]
via TenGigabitEthernet2/1/3, directly connected
L
2001:DB8:0:23::3/128 [0/0]
via TenGigabitEthernet2/1/3, receive
OI 2001:DB8:1::1/128 [110/1]
via FE80::1, TenGigabitEthernet1/1/3
OI 2001:DB8:1:1::/64 [110/2]
via FE80::1, TenGigabitEthernet1/1/3
OI 2001:DB8:2::2/128 [110/1]

75

OI
LC
C
L
L

via FE80::2, TenGigabitEthernet2/1/3

2001:DB8:2:1::/64 [110/2]
via FE80::2, TenGigabitEthernet2/1/3
2001:DB8:3::3/128 [0/0]
via Loopback0, receive
2001:DB8:3:1::/64 [0/0]
via TenGigabitEthernet1/1/1, directly connected
2001:DB8:3:1::1/128 [0/0]
via TenGigabitEthernet1/1/1, receive
FF00::/8 [0/0]
via Null0, receive

MP-BGP s OSPFv3 hlzati hirdetsek cserje

Elfordulhat, hogy bizonyos partner hlzatok vagy hlzat specifikus tvlaszts miatt nmely
BGP hlzatot szeretnnk a bels OSPF routing tblba hirdetni. A redistribute funkcival nhny, vagy akr az sszes BGP hlzatot t tudjuk vinni az OSPF tblba, kls hlzatknt. Ezeknek az internet cmeknek tvitele OSPF protokollba a kvetkez clokat is szolglhatjk:
Bizonyos partner hlzatot norml krlmnyek kztt egy szolgltat fel szeretnk
elrni politikai, ksleltets, svszlessg vagy egybb okok miatt.
Egy bels (IGP) router az tvlasztsi dntst egy bizonyos hlzat elrhetsgtl teszi
fggv.

20 BG
20 01 P01 :db >O
:d 8: SP
b8 4: F
:5 1 /
:1 6 4
/6
4

PF 64
OS 1/ 4
-> 8:4: :1/6
P
BG :db b8:5
0 1 :d
20 001
2

22. bra: Redisztribci BGP s OSPF kztt

76

Termszetesen a teljes BGP hlzati tbla tadsa OSPF-be szinte soha nem praktikus, vagy lehetsges a BGP tbla hatalmas mrete (s az ebbl kvetkez memriaignye) miatt. A BGP hlzati cmek tadsa csak kontrolllt mdon, szrve ajnlott (lsd az albbi pldt). A kls hlzatok
tbbsgt ltalban a default route hasznlatval fogjuk elrni.
Nzznk meg egy pldt arra az esetre, ha az R4 s R5 BGP ltal hirdetett hlzatt az R1 valamint
az R2 routeren keresztl az OSPF tblba visszk t (22. bra).
R1 konfigurci:
router ospfv3 1
router-id 1.1.1.1
!
address-family ipv6 unicast
passive-interface GigabitEthernet0/0/1
passive-interface Loopback0
redistribute bgp 65000 metric 1000 metric-type 1 route-map BGP-OSPF

BGP hlzat redisztribucija a BGP-OSPF route map segitsgvel

exit-address-family
!
router bgp 65000
bgp router-id 1.1.1.1
neighbor 2001:DB8:0:12::2 remote-as 65000
neighbor 2001:DB8:0:14::4 remote-as 65004
!
address-family ipv6
network 2001:DB8:1::1/128
network 2001:DB8:1:1::/64
network 2001:DB8:2::2/128
network 2001:DB8:2:1::/64
network 2001:DB8:3::3/128
network 2001:DB8:3:1::/64
neighbor 2001:DB8:0:12::2 activate
neighbor 2001:DB8:0:14::4 activate
!
ipv6 prefix-list R4-R5-NET seq 5 permit 2001:DB8:4:1::/64 prefix-list a kls

hlzat engedlyezsre

ipv6 prefix-list R4-R5-NET seq 10 permit 2001:DB8:5:1::/64

route-map BGP-OSPF permit 10 route-map, amit a redisztribucira hasznlunk
match ipv6 address prefix-list R4-R5-NET

R2 konfigurci:
router ospfv3 1
router-id 2.2.2.2
!
address-family ipv6 unicast
passive-interface GigabitEthernet0/0/1
passive-interface Loopback0
redistribute bgp 65000 metric 1000 metric-type 1 route-map BGP-OSPF
exit-address-family
!

77

router bgp 65000

bgp router-id 2.2.2.2
neighbor 2001:DB8:0:12::1 remote-as 65000
neighbor 2001:DB8:0:25::5 remote-as 65005
!
address-family ipv6
network 2001:DB8:1::1/128
network 2001:DB8:1:1::/64
network 2001:DB8:2::2/128
network 2001:DB8:2:1::/64
network 2001:DB8:3::3/128
network 2001:DB8:3:1::/64
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:25::5 activate
!
ipv6 prefix-list R4-R5-NET seq 5 permit 2001:DB8:4:1::/64
ipv6 prefix-list R4-R5-NET seq 10 permit 2001:DB8:5:1::/64
route-map BGP-OSPF permit 10
match ipv6 address prefix-list R4-R5-NET

Ha megvizsgljuk az R3 router tbljt, mr lthat, hogy R4 s R5 loklis hlzata megjelent,

mint external OSPF route.
R3# show ipv6 route
IPv6 Routing Table - default - 18 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter
OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1
ON2 - OSPF NSSA ext 2, a - Application
O
2001:DB8:0:12::/64 [110/2]
via FE80::2, TenGigabitEthernet2/1/3
via FE80::1, TenGigabitEthernet1/1/3
C
2001:DB8:0:13::/64 [0/0]
via TenGigabitEthernet1/1/3, directly connected
L
2001:DB8:0:13::2/128 [0/0]
via TenGigabitEthernet1/1/3, receive
L
2001:DB8:0:13::3/128 [0/0]
via TenGigabitEthernet1/1/3, receive
O
2001:DB8:0:14::/64 [110/2]
via FE80::1, TenGigabitEthernet1/1/3
C
2001:DB8:0:23::/64 [0/0]
via TenGigabitEthernet2/1/3, directly connected
L
2001:DB8:0:23::3/128 [0/0]
via TenGigabitEthernet2/1/3, receive
O
2001:DB8:0:25::/64 [110/2]
via FE80::2, TenGigabitEthernet2/1/3
OI 2001:DB8:1::1/128 [110/1]
via FE80::1, TenGigabitEthernet1/1/3
OI 2001:DB8:1:1::/64 [110/2]
via FE80::1, TenGigabitEthernet1/1/3
OI 2001:DB8:2::2/128 [110/1]
via FE80::2, TenGigabitEthernet2/1/3

78

OI

2001:DB8:2:1::/64 [110/2]
via FE80::2, TenGigabitEthernet2/1/3
LC 2001:DB8:3::3/128 [0/0]
via Loopback0, receive
C
2001:DB8:3:1::/64 [0/0]
via TenGigabitEthernet1/1/1, directly connected
L
2001:DB8:3:1::1/128 [0/0]
via TenGigabitEthernet1/1/1, receive
OE1 2001:DB8:4:1::/64 [110/1001]
via FE80::1, TenGigabitEthernet1/1/3
OE1 2001:DB8:5:1::/64 [110/1001]
via FE80::2, TenGigabitEthernet2/1/3
L
FF00::/8 [0/0]
via Null0, receive

3.6. MikroTik tvlasztk konfigurlsa

A MikroTik hlzati eszkzk alkalmazsa egyre npszerbb haznkban, gy knyvnkbl sem
maradhatott ki az IPv6 konfigurlsnak ismertetse RouterOS rendszerek esetben. A knyv ksztsekor a rendszer 6.27-es verzijt vettk alapul, s a parancssori (CLI) mkdst ismertetjk.

3.6.1. Alapbelltsok
Az IPv6 protokoll hasznlathoz telepteni (s engedlyezni) kell a szoftver verzinak megfelel
ipv6 csomagot. A csomag megltt a system package print parancs segtsgvel ellenrizhetjk.
Az IPv6-os cmek, melyek az egyes hlzati interfszekhez vannak rendelve, az ipv6 address
print parancs segtsgvel krdezhetek le:
[admin@MikroTik] > ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
#
ADDRESS
FROM-POOL INTERFACE
ADVERTISE
0 DL fe80::20c:42ff:fe3f:2e74/64
ether2
no
1 DL fe80::20c:42ff:fe3f:2e73/64
ether1
no
2 DL fe80::20c:42ff:fe3f:2e75/64
ether3
no

Minden olyan interface, mely aktv, teht van hozz csatlakoztatva hlzat, s nincs letiltva, rendelkezik link local cmmel. IPv6-os cm hozzadsa az ipv6 address add paranccsal oldhat
meg:
[admin@MikroTik] > ipv6 address add interface=ether1 address=2001:DB8::1/64

Melynek eredmnye:
[admin@MikroTik] > ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
#
ADDRESS
FROM-POOL INTERFACE
ADVERTISE
0 DL fe80::20c:42ff:fe3f:2e74/64
ether2
no
1 DL fe80::20c:42ff:fe3f:2e73/64
ether1
no
2 DL fe80::20c:42ff:fe3f:2e75/64
ether3
no
3 G 2001:db8::1/64
ether1
yes

79

Bellthatjuk mdostott EUI-64 alkalmazsval ltrehozott IPv6 cm hasznlatt is az eui64=yes paramter megadsval, ez azonban tvlasztk esetben nem clszer.
Statikus route bejegyzs ltrehozsa az ipv6 route add paranccsal lehetsges. Pldaknt egy

alaprtelmezett tjr hozzadsa:

[admin@MikroTik] > ipv6 route add dst-address=::/0 gateway=2001:db8::2

Mg a routing tblzat kiratsa:

[admin@MikroTik] > ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
#
DST-ADDRESS
GATEWAY
DISTANCE
0 A S ::/0
2001:db8::2
1
1 ADC 2001:db8::/64
ether1
0

A RouterOS rendszerekben az IPv4 protokoll esetn alkalmazottal megegyezen, IPv6 protokoll

esetn is a ping s a tool traceroute parancs hasznlhat a hlzati kapcsolatok ellenrzsre.
Fontos ugyanakkor, hogy nem hivatkozhatunk kzvetlenl IPv6-os nvre, csak IP-cmekre. Pldul:
[admin@MikroTik] > ping ipv6.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
failure: dns name exists, but no appropriate record

De:
[admin@MikroTik] > ping 2a00:1450:4016:803::1000 count=4
SEQ HOST
SIZE TTL TIME STATUS
0 2a00:1450:4016:803::1000
56 49 26ms echo reply
1 2a00:1450:4016:803::1000
56 49 26ms echo reply
2 2a00:1450:4016:803::1000
56 49 26ms echo reply
3 2a00:1450:4016:803::1000
56 49 26ms echo reply
sent=4 received=4 packet-loss=0% min-rtt=26ms avg-rtt=26ms max-rtt=26ms

A gyrt ltal javasolt megolds a kvetkez:

[admin@MikroTik] > ping [:resolve ipv6.google.com] count=4
SEQ HOST
SIZE TTL TIME STATUS
0 2a00:1450:4016:803::1000
56 49 27ms echo reply
1 2a00:1450:4016:803::1000
56 49 26ms echo reply
2 2a00:1450:4016:803::1000
56 49 26ms echo reply
3 2a00:1450:4016:803::1000
56 49 26ms echo reply
sent=4 received=4 packet-loss=0% min-rtt=26ms avg-rtt=26ms max-rtt=27ms

3.6.2. Az ipv6 firewall

Az ipv6 firewall hasznlata nagyon hasonl az ip firewall alkalmazshoz, gy pldk
segtsgvel csak az alapvet parancsokat ismertetjk.
80

Az add parancs segtsgvel egy meglv lnc vghez fzhetnk jabb sort. Trlni a remove
paranccsal lehet, mg a print parancs segtsgvel listzhatjuk ki a lncot.
Egy sor beszrsa a lnc vgre, mely minden csomagot eldob, ami a 2001:db8::100 cmrl rkezik:
[admin@MikroTik] > ipv6 firewall filter add chain=input \
src-address=2001:db8::100 action=drop

Kirja a lncok tartalmt:

[admin@MikroTik] > ipv6 firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0
chain=input action=drop src-address=2001:db8::100/128 log=no \
log-prefix=""

Trli a megjelentett sort:

[admin@MikroTik] > ipv6 firewall filter remove numbers=0

3.6.3. Automatikus IPv6 cmkioszts

Router Advertisement (RA)
A MikroTik eszkzkn a /ipv6 nd alatt llthatjuk be a RA kzponti belltsait. Els lpsknt
irassuk ki a belltsokat:
[admin@MikroTik] > ipv6 nd print
Flags: X - disabled, I - invalid, * - default
0 * interface=all ra-interval=3m20s-10m ra-delay=3s mtu=unspecified
reachable-time=unspecified retransmit-interval=unspecified \
ra-lifetime=30m
hop-limit=unspecified advertise-mac-address=yes advertise-dns=yes
managed-address-configuration=no other-configuration=no

Az interfszenknt belltst az IPv6 cm hozzadsakor tehetjk meg. Pldul:

[admin@MikroTik] > ipv6 address add interface=ether1 \
address=2001:db8::1/64 advertise=yes

j cm hozzadsakor a hirdets alaprtelmezetten engedlyezett (advertise=yes), gy ezt nem

szksges megadni. Az RA-val hirdetett prefixek kz automatikusan felkerlnak a hozzadott globlis cmek prefixei, de manulisan is vihetnk fel hirdetend prefixeket. A prefixek kratsa a kvetkez mdon lehetsges:
[admin@MikroTik] > ipv6 nd prefix print
Flags: X - disabled, I - invalid, D - dynamic
0 D prefix=2001:db8::/64 interface=ether1 on-link=yes autonomous=yes
valid-lifetime=4w2d preferred-lifetime=1w

DHCPD
Els lpsben az IPv6 poolt kell ltrehozni, melybl a prefixek deleglsra kerlnek:
81

/ipv6 pool add name=IPv6PDPool prefix=2001:db8::/56 prefix-length=60

A megadott konfigurcival a 2001:db8::/56 cmtartomnybl kerlnek deleglsra /60 mret

prefixek. Hozzuk ltre a DHCP szervert:
/ipv6 dhcp-server add name=dhcpserver1 interface=ether10 \
address-pool=IPv6PDPool disabled=no

rdekes megolds, hogy egy interfsznek automatikusan biztosthatunk egy megadott poolbl
IPv6 cmet a kvetkez parancs segtsgvel:
/ipv6 address add interface=ether1 add address=::1/64 from-pool=IPv6PDPool

Ez lehet egy ltalunk belltott pool, de akr egy prefix delegcival kapott pool is, gy a kapott
prefixekbl automatikusan rendelhetnk IPv6 cmet a router megfelel interfszhez, majd onnan
RA segtsgvel biztosthatjuk a megfelel prefixxel rendelkez cmeket a kliensek rszre.

3.6.4. OSPFv3
RouterOS rendszerekben az OSPFv3 belltsa a routing ospf-v3 instance parancs segtsgvel trtnhet. Els lpsknt rassuk ki az alapbelltsokat:
[admin@MikroTik] > routing ospf-v3 instance print
Flags: X - disabled, * - default
0 * name="default" router-id=0.0.0.0 distribute-default=never
redistribute-connected=no redistribute-static=no redistribute-rip=no
redistribute-bgp=no
redistribute-other-ospf=no metric-default=1 metric-connected=20
metric-static=20 metric-rip=20 metric-bgp=auto metric-other-ospf=auto

Jl ltszik, hogy egy IPv6 OSPF pldny tallhat az tvlasztn, default nven, mely nem hirdeti
tovbb a tbbi routing protokollal kapott, valamint a statikus s kzvetlenl csatlakoz hlzatokat.
A kvetkezkben lltsuk be az OSPFv3-at a 23. brn lthat hlzathoz, majd ellenrizzk mkdst. Az egyszersg kedvrt csak backbone area van a hlzatban.
eth1:
2001:db8::1/64

eth1:
2001:db8::2/64
eth2: 2001:db8:2::1/64

eth2: 2001:db8:1::1/64
MikroTik

MikroTik2

23. bra: OSPF pldahlzat MikroTik eszkzkkel

Ahogy mr korbban emltettk, az IPv4-nl alkalmazott OSPFv2 esetben network megadsa
szksges az OSPF engedlyezshez, az OSPFv3 esetben az interfszeket kell konfigurlni. Az
OSPFv3 mkdshez minden a hlzatban lv tvlasztnak egyedi azonostval kell rendelkeznie. (Ugyangy, mint az OSPFv2 esetben.) Ez OSPFv3 esetben is egy ngy byte hossz azonost
maradt, amit rdemes manulisan belltani. Els lpsben engedlyezzk a csatlakoz s a statikus
hlzatok redisztribcijt, lltsuk be a router-id-t, majd engedlyezzk a msik tvlaszthoz csatlakoz interfszen az OSPFv3-at:
82

[admin@MikroTik] > routing ospf-v3 instance set 0 \

redistribute-static=as-type-1 redistribute-connected=as-type-1
[admin@MikroTik] > routing ospf-v3 interface add instance-id=0 \
interface=ether1 area=backbone
[admin@MikroTik2] > routing ospf-v3 instance set 0 \
redistribute-static=as-type-1 redistribute-connected=as-type-1
[admin@MikroTik2] > routing ospf-v3 interface add instance-id=0 \
interface=ether1 area=backbone

Ellenrizzk le a mkdst:
[admin@MikroTik] > routing ospf-v3 neighbor print
0 instance=default router-id=2.2.2.2 address=fe80::20c:42ff:fe42:d0c9
interface=ether1 priority=1 dr=2.2.2.2 backup-dr=1.1.1.1 state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=3m39s
[admin@MikroTik] > ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
#
DST-ADDRESS
GATEWAY
DISTANCE
0 ADC 2001:db8::/64
ether1
0
1 ADC 2001:db8:1::/64
ether2
0
2 ADo 2001:db8:2::/64
fe80::20c:42ff:fe42:d...
110
[admin@MikroTik2] > routing ospf-v3 neighbor print
0 instance=default router-id=1.1.1.1 address=fe80::20c:42ff:fe3f:2e73
interface=ether1 priority=1 dr=2.2.2.2 backup-dr=1.1.1.1 state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=2m16s
[admin@MikroTik2] > ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
#
DST-ADDRESS
GATEWAY
DISTANCE
0 ADC 2001:db8::/64
ether1
0
1 ADo 2001:db8:1::/64
fe80::20c:42ff:fe3f:2...
110
2 ADC 2001:db8:2::/64
ether2
0

3.6.5. IPv6 BGP

AS65000
2001:db8:100::/48

AS65001
2001:db8:200::/48

2001:db8::/64
MikroTik

MikroTik2

24. bra: MP-BGP pldahlzat MikroTik eszkzkkel

83

Els lpsknt rassuk ki a BGP alapbelltsait:

[admin@MikroTik] > routing bgp instance print
Flags: * - default, X - disabled
0 * name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no
redistribute-static=no redistribute-rip=no
redistribute-ospf=no redistribute-other-bgp=no out-filter="" clientto-client-reflection=yes ignore-as-path-len=no
routing-table=""

lltsuk be az tvlaszt sajt AS szmt:

[admin@MikroTik] > routing bgp instance set 0 as=65000
[admin@MikroTik2] > routing bgp instance set 0 as=65001

lltsuk be a BGP-vel hirdetni kvnt hlzatot:

[admin@MikroTik] > routing bgp network add network=2001:db8:100::/48
[admin@MikroTik2] > routing bgp network add network=2001:db8:200::/48

Majd adjuk hozz a BGP peer-t:

[admin@MikroTik] > routing bgp peer add name=MikroTik2-AS65001 \
remote-address=2001:db8::2 remote-as=65001 update-source=ether1
[admin@MikroTik2] > routing bgp peer add name=MikroTik-AS65000 \
remote-address=2001:db8::1 remote-as=65000 update-source=ether1

Ellenrizzk a mkdst:
[admin@MikroTik] > routing bgp peer print detail
Flags: X - disabled, E - established
0 E name="MikroTik2-AS65001" instance=default remote-address=2001:db8::2
remote-as=65001 tcp-md5-key="" nexthop-choice=default multihop=no
route-reflect=no hold-time=3m ttl=255 in-filter="" out-filter=""
address-families=ip,ipv6 update-source=ether1 default-originate=never
remove-private-as=no as-override=no passive=no use-bfd=no

Az E bet jelzi, hogy ltrejtt a kapcsolat a msik tvlasztval. Tbbek kzt leolvashat a tvoli
tvlaszt IP cme, a tvoli AS szma, az authentikci sorn hasznlt osztott kulcs s az is ltszik,
hogy nem hasznlunk szrlistt. Ksztsnk egy szrlistt, mely megakadlyozza, hogy default
route hirdetst fogadjunk el a szomszdtl, valamint az elfogadott prefixek esetben belltja a
weight rtkt 200-ra:
[admin@MikroTik] > routing filter add action=discard \
chain=bgpv6-AS65001-IN prefix=::/0 prefix-length=0 protocol=bgp
[admin@MikroTik] > routing filter add action=accept \
chain=bgpv6-AS65001-IN protocol=bgp set-bgp-weight=200

Rendeljk hozz a peer-hez a szrlistt:

84

[admin@MikroTik] > routing bgp peer set 0 in-filter=bgpv6-AS65001-IN

Ellenrizzk a szrlista tartalmt:

[admin@MikroTik] > routing filter print
Flags: X - disabled
0
chain=bgpv6-AS65001-IN prefix=::/0 prefix-length=0 protocol=bgp
invert-match=no action=discard set-bgp-prepend-path=""
1
chain=bgpv6-AS65001-IN protocol=bgp invert-match=no action=accept setbgp-weight=200 set-bgp-prepend-path=""

Szrlistt eltvoltani a routing filter remove parancs segtsgvel tudunk. A mvelet eltt
ne felejtsk el a lista hasznlatt megszntetni az adott peer esetben sem!

3.6.6. IPv6 PPPOE szerver belltsa

A kvetkezkben a PPPOE szerver belltst ismertetjk annak ellenre, hogy hosszas prblkozs ellenre sem sikerlt megbzhat mkdsre brni a MikroTik implementcijt IPv6 protokollal. Tbb szoftververzi kiprblsa utn, valsznsthet, hogy valamilyen programhiba
okozza a problmt. Mivel az internetszolgltatk elszeretettel hasznljk hitelestsre a PPPOE
protokollt, gy a problma megoldsa rdekben jeleztk a hibt a gyrtnak.
Elsknt hozzuk ltre a PPPOE kliensek szmra deleglsra kerl cmtartomny(oka)t tartalmaz IPv6 poolt a kvetkez parancs segtsgvel:
/ipv6 pool add name=IPv6PDPool prefix=2001:db8::/56 prefix-length=60

A megadott konfigurcival a 2001:db8::/56 cmtartomnybl kerlnek deleglsra /60 mret

prefixek, ami azt jelenti, hogy egy-egy kliens 16 darab /64-es mret alhlzatot hasznlhat, s
sszesen 16 klienst tud kiszolglni a router. lltsuk be az ltalunk hasznlt PPP profilban a ltrehozott pool nevt:
/ppp profile set 0 remote-ipv6-prefix-pool=IPv6PDPool

Hozzuk ltre a pppoe szervert:

/interface pppoe-server server add disabled=no interface=ether1 disabled=no

Vgl pedig hozzuk ltre a PPPOE belpshez hasznlhat felhasznlt:

/ppp secret add name=User1 password=P@ssw0rd1

3.6.7. IPv6 PPP kliens belltsa

A PPPOE kliens belltsa lnyegesen egyszerbb, s problmamentesen mkdtt. Els lpsknt hozzuk ltre a PPPOE klienst:
/interface pppoe-client add add-default-route=yes interface=ether1
password=P@ssw0rd1 user=User1 disabled=no

85

Ezutn csak a DHCP kliens hozzadsa szksges:

/ipv6 dhcp-client add interface=pppoe-out1 pool-name=ppp-test \
pool-prefix-length=64

Ha szeretnnk tudatni a PPPOE szerverrel, hogy /62 mret prefix deleglst krjk, akkor a
sor vgre mg rjuk oda, hogy: prefix-hint=::/62
A kiadott parancs eredmnyeknt, ha a PPPOE szerver DHCP szervere delegl a kliens rszre
prefixet, akkor az megjelenik az IPv6 poolok kztt:
[admin@MikroTik] > ipv6 pool print
Flags: D - dynamic
#
NAME
PREFIX
0 D ppp-test
2001:db8::10:0:0:0:0/60

PREFIX-LENGTH EXPIRES-AFTER
64 2d23h59m56s

Lthat, hogy a szerver /60-as mret prefixet delegl (ahogy a szerveren belltottuk), melyet a
kliensen fut DHCP szerver tovbb deleglhat /64-es darabokban.

86

4. IPv6 ttrsi technolgik sszehasonlt

elemzse
4.1. ltalnos ttekints
4.1.1. Az IPv4-rl IPv6-ra val ttrs idbeli lezajlsa
Az Internet trtnelmben egyszer sikerlt a pillanatszer protokollvlts: az ARPANET-en
1983. 01. 01-n volt az ttrs NCP-rl (Network Control Program) TCP/IP-re (RFC 801). Ma ez
lehetetlen feladat. Tbb millird csompont van, lehetetlen ket egyszerre tkapcsolni. St jelenleg rengeteg hardver s szoftver eleve alkalmatlan IPv6-ra.
Br az tmenet rgen megkezddtt, elszr nagyon lassan haladt, s csak az IPv4 cmek kifogysa adott neki lendletet. A kt protokoll tartsan egyms mellett fog lni a fentieken tl azrt is,
mert egyrszt bizonyos hardver s szoftver szlltk nem fogjk megoldani az IPv6 kompatibilitst,
msrszt a felhasznlk ragaszkodnak a rgi eszkzeikhez. Teht meg kell oldani az IPv4 s az IPv6
alap rendszerek egyttmkdst!

4.1.2. Az IPv4 s IPv6 alap rendszerek egyttmkdsnek

fontosabb esetei
A legtbb alkalmazsunk kliens-szerver konfigurciban mkdik. Egyik szempont, hogy mely
protokollokra kpes a kliens s a szerver. A msik szempont, hogy a hlzat mely protokollokra
kpes a klienstl a szerverig terjed ton. Ezen szempontok szerint vizsglva a kvetkez eseteket
s megoldsokat tartjuk emltsre rdemesnek:
Az egyszer eset: dual stack hasznlata
Ha a kliens s a szerver kzl brmelyik is kpes mindkt protokoll hasznlatra (dual stack), akkor
a kzs nyelv hasznlatval a kommunikci megoldott feltve, hogy a kztk lev hlzat is
tmogatja azt. A problma az, hogy mr nincs elg IPv4 cm! (Knyszermegolds: Dual-Stack Lite.)
IPv6 kpes kliens IPv4-only krnyezetben s IPv6 szerver
A kliens kpes IPv6-ra, de az internetszolgltat (ISP) csak IPv4-cmet ad a kliensnek, a szerver
pedig kizrlag IPv6-ra kpes. Egy rgi s viszonylag j megolds: 6to4 hasznlata. Ezt a megoldst
mlyebben is bemutatjuk. A 6to4-hez hasonl megolds mg a teredo s a 6rd, rviden ezekkel is
foglalkozunk.
IPv6 kliens s IPv4 szerver
Csak IPv6-ra kpes a kliens (mr csak IPv6 cm jutott neki) s csak IPv4-re kpes a szerver (rgi,
az IPv6-ot nem tmogatja). Egy j megolds: DNS64 szolgltats + NAT64 tjr hasznlata.
Mindkt rszvel mlyebben foglalkozunk.
IPv4 kliens s IPv6 szerver
Csak IPv4-re kpes a kliens (rgi hardver s/vagy szoftver) s csak IPv6-ra kpes a szerver (ilyenek
is vannak, s szmuk vrhatan nni fog). Egy megolds lehetne (vagy inkbb lehetett volna):
NAT46+DNS46, de vek ta nem lett belle szabvny, br lteznek r implementcik. Rviden
ismertetjk a megoldsok alaptlett.
IPv6 kliens s IPv6 szerver DE tkzben egy szakaszon csak IPv4 van
Tipikus eset, az j IPv6 szigeteket ssze kell ktni. A megolds az IPv6 datagramok szlltsa
IPv4 fltti alagtban (6in4 tunnel). Bemutatunk egy olyan megoldst is (MPT [6]), amely brmelyik IP verzi (4 vagy 6) felett brmelyik verzit kpes tvinni.

87

IPv4 kliens s IPv4 szerver DE tkzben egy szakaszon csak IPv6 van
Ma mg nlunk nem igazn jellemz, de majd lehet. A megolds az IPv4 datagramok szlltsa
IPv6 fltti alagtban (4in6 tunnel). s a fent emltett MPT is hasznlhat.
IPv4 kliensek privt IPv4 cmmel s IPv4 szerver DE az ISP hlzatban csak IPv6 van
A klienseknek mr nem jutott publikus IPv4 cm, de ahelyett, hogy IPv6-ot hasznlnnak, 4-es
verzij privt IP-cmeket adnak nekik. Megolds lehet a MAP protokoll, rviden trgyaljuk.

4.2. Emlkeztet az IP-cmek megosztsrl

Ennek a tmakrnek (legalbb rszleges) ismerett ugyan felttelezzk az Olvasrl, de a tovbbiak megrtshez szksges nhny fontos rszlet bemutatsa s az egysges terminolgia hasznlata rdekben egy rvid sszefoglalt adunk rla.

4.2.1. A cmfordtst hasznl megolds

A hlzati cmfordts (NAT/NAPT) mkdsi elve
A TCP/IP protokollcsaldot eredetileg vgponttl vgpontig val kommunikcira terveztk. Az
alkalmazsok arra szmtanak, hogy a cmek s portszmok a hlzati tvitel sorn vltozatlanok.
Az IPv4-cmek szkssge miatt terjedt el az a megolds, hogy egy hlzatban, ahol privt IPcmeket hasznlnak, de szksg van kls kommunikcira is, a problmt cmfordtssal oldjk
meg.
Legyen a feladat elszr az, hogy a privt IP-cmmel rendelkez (kliens) gpek elrhessenek kls, publikus
IP-cmmel rendelkez (szerver) gpeket. Ehhez rendelkezsnkre ll egy router, aminek van publikus IPcme.
A megolds alaptlete a kvetkez:
A privt IP-cmmel rendelkez gprl a clcm alapjn kldjk el a csomagot az Internet
fel. (Ekkor a csomag elvileg ugyan odarne, de a vlasz nem tallna vissza. Egybknt
pedig tiltott a privt IP-cmeknek a publikus krnyezetben trtn hasznlata.)
A kimen router cserlje ki a forrs privt IP-cmt a sajt publikus IP-cmre. gy mr a
vlasz visszar a cmcsert vgrehajt routerhez.
A router tovbbtsa a vlaszt a megfelel privt IP-cm gpnek. De hogyan?
Ahhoz, hogy a router a vlaszt az eredeti feladnak vissza tudja kldeni, nyilvn kell tartania, s
egy vlaszcsomag rkezsekor tudnia kell, hogy ki volt a kldje annak a csomagnak, amire a vlasz
rkezett. Ennek rdekben a nyilvntartshoz az IP-cmen tl mst is felhasznl. TCP s UDP
esetn ezek a forrs portszmok. De a routernek nem elegend ezeket megjegyeznie, hiszen a forrs
portszmok csak gpenknt egyediek, a forrs IP-cmet viszont a sajtjra cserli. Teht a megolds (az
n. traditional NAT esetn, de lsd majd ksbb: extended NAT) a kvetkez:
A router a kimen csomagokban a forrs IP-cm cserjekor a forrs portszmokat is kicserli a routeren egyedi portszmokra: az IP-cmek s a clportszm mellett ezekkel mr egyrtelmen azonostani tudja a kapcsolatokat. Kapcsolatonknt nyilvntartja, hogy mit mire
cserlt ki.
A bejv csomagoknl az IP-cmen kvl a portszmot is vissza kell cserlnie. (Itt most az
irny vltozsa miatt a cl IP-cm s a clport az, amit tr.)
Megjegyzs: terminolgia nem egysges, de eredetileg a NAT csak az IP-cmek cserjt jelentette,
ezt hvjk ma basic NAT-nak, vagy one-to-one NAT-nak. A fenti megolds precz neve a NAPT (Network Address and Port Translation). Nevezik many-to-one NAT-nak is.
A NAT clja s mkdse szempontjbl a fent ismertetett megoldst Source NAT-nak (SNAT)
hvjuk akkor, ha a router publikus IP-cme fix, s Masquerade-nek, ha DHCP-vel kapta az interfsze
88

az IP-cmet (ilyenkor nem egy fixen megadhat IP-cmre, hanem az interfsz aktulis IP-cmre kell
a forrs IP-cmet kicserlni).
A msik irny feladat az, hogy privt IP-cmmel rendelkez gpeket elrhetv tegynk az Internet fell.
Erre a megolds a Destination NAT (DNAT) vagy ms nven port forwarding, ahol a router az adott
portjra rkez csomagokat egy meghatrozott privt IP-cm gpnek tovbbtja gy, hogy a clcmet kicserli a csomagban. Pldul a 80-as portra rkez csomagokat a 10.1.1.2 webszerver, a 25sre rkezket pedig a 10.1.1.3 SMTP szerver fel tovbbtja.
ICMP esetn nincs portszm, de segthet az, hogy egy hibazenetben benne van az azt kivlt
TCP vagy UDP adategysg els 64 bitje a portszmokkal. Amennyiben nem hibazenetrl van sz,
akkor is van megolds: az ICMP zenet valamilyen azonost jelleg mezjt hasznljk fel.
A NAT-rl bvebben az RFC 3022-ben olvashatunk, az IP, TCP, UDP, ICMP fejrszek mezinek mdostsval a 4.1. rsz, az ellenrz sszeg hatkony jraszmtsval a 4.2. rsz foglalkozik.
Lnyegben arrl van sz, hogy a rgi portszmot "kivonjuk", az jat pedig "hozzadjuk" s nem
kell a szmtst a teljes adategysgre elvgezni.

A NAPT kritikja
A megolds slyos problmja, hogy srti az IP-cmek s porszmok vgponttl vgpontig trtn vltozatlansgnak elvt, ami szmos kvetkezmnnyel jr. Vizsgljunk meg kzlk nhnyat:
Koncepcionlisan az sszes olyan alkalmazsi rtegbeli protokollal problma lehet, ahol az
alkalmazsi rtegbeli PDU-ban megjelenik valamilyen kommunikciazonost (pl. IP-cm,
portszm). Pldul egy FTP kliens aktv mdban a vezrl kapcsolaton keresztl megadja
a szervernek, hogy mely portjn vrja, hogy a szerver felptse az adatkapcsolatot. Privt
IP cmmel vrhatja hacsak nem segt valaki: protocol helper. (Az adott esetben persze tkletes megolds az FTP passzv mdjnak alkalmazsa, amikor a vezrl kapcsolaton keresztl a szerver kldi el a kliensnek az IP-cm + portszm prost, ahova a kliens gond
nlkl fel tudja pteni az adatkapcsolatot. Ez a megolds a kliens oldali tzfal problmjt
is megoldja, ami kifele engedni fogja a kapcsolat felptst, mg befele nem engedn.) Hasonlkppen egy IP telefon rendszernl is gond lesz az IP-cmek tkldsvel (arra is van
megolds, ltezik pldul SIP NAT helper is).
A port forwarding ugyan alkalmas arra, hogy egyetlen publikus IP-cm hasznlatval tbb
szervert tegynk elrhetv, de ettl mg a privt IP-cmmel rendelkez gpek hasznlhatsga nem teljes rtk, hiszen elrhetsgk nem automatikus, a NAPT eszkzn belltsra van szksg, st egy adott portot csak egy eszkz fele lehet tovbbtani. (Teht ha
kt privt IP-cmmel rendelkez, azonos publikus IP-cm mg helyezett elfizet szeretne
azonos porton szolgltatni pldul mindkett web szervert szeretne zemeltetni , az
mr problmt okoz.)
A kzs publikus IP-cmen val osztozs tovbbi problmja, hogy a kommunikciban
rszt vev felek nem tudjk egymst klcsnsen azonostani. Pldul egy web szerver
nem a NAPT mgtti kliensek IP-cmt ltja (privt IP cmk egybknt teljesen haszontalan is lenne), hanem az NAPT eszkz kls interfsznek publikus IP-cmt. Visszalsek megllaptsa (lsd kvetkez pont) vagy pldul szavazsok (egy IP-cmrl naponta
egy szavazat) esetn ez komoly gondot okoz.
Internetszolgltatk esetn fontos jogszablyi elrs, hogy kpeseknek kell lennik utlag
adatot szolgltatni arrl, hogy adott idpontban egy adott IP-cmet mely elfizetjk hasznlt. Tbbletkltsg rn mszakilag termszetesen megoldhat, hogy az IP-cmeket a
portszmokkal egytt naplzzk, de mg ekkor is problmt okozhat, ha olyan megkeresst
kapnak, hogy csak idpont s IP-cm alapjn kell azonostaniuk az elfizett (mert a tmadst vagy visszalst bejelent fl nem naplzta a kliens portszmt, csak IP-cmt).
89

A fenti problmk majd NAT64-nl is eljnnek, ott az alkalmazsok kompatibilitsra rszletesen ki fogunk trni.

NAPT mlyebben: hagyomnyos s kiterjesztett tpusok

A fent bemutatott NAPT megolds elnye az egyszersg, aminek ra a portszmok pazarl hasznlata. Mr 2007-ben javasoltak olyan megoldst, ami a portszmokkal sokkal takarkosabban bnik
[7]. Nzznk bele most egy kicsit mlyebben mindkt megolds mkdsbe!
Kt szmtgp kztt egyszerre tbb kommunikci is folyamatban lehet, akr TCP akr UDP
hasznlatval. Br az UDP kapcsolatmentes protokoll, nevezzk most ezeket mgis kapcsolatnak
(connection vagy session) mindkt esetben. Egy kapcsolatot a kvetkez 5 szm azonost egyrtelmen: forrs IP-cm, forrs portszm, cl IP-cm, cl portszm, protokoll (TCP vagy UDP).
Egy hagyomnyos (traditional) tpus NAPT implementci a kapcsolatok kvetsre (connection
tracking) csak a 7. tblzat szerinti azonostkat hasznlja, teht kihagyja a (privt IP cmmel rendelkez kliens szempontjbl) cl IP-cmet s cl portszmot. Minden forrs IP-cm + forrs port
pros esetn egyedire cserli a kimen csomagban a forrs portszmot. Mivel a portszmok 16
bitesek, s erre a clra csak az 1024-tl 65535-ig terjed tartomnyt hasznlja, ezrt sszesen 63k
darab TCP s ugyanennyi UDP kapcsolatot kpes kezelni a kimen interfszre felhzott minden
egyes publikus IP-cm mellett. Ez jelents korltozs, ezrt erre a problmra mr 2007-ben javasoltk a kvetkez, ma elterjedten alkalmazott megoldst.
Egy kiterjesztett (extended) tpus NAPT implementci a kapcsolatok kvetsre a 8. tblzat
szerinti azonostkat hasznlja, teht a cl IP-cmet s cl portszmot is. Csak akkor cserli ki a
csomagban a forrs portszmot, ha az felttlenl szksges, azaz a csere nlkl nem lenne a kapcsolat egyrtelmen azonosthat a visszarkez csomagban szerepl rtkek alapjn. A 8. tblzatban tbb olyan esetet is bemutatunk, amikor a forrs portszmot nem kell cserlni, a csere csak az
utols sorban volt szksges. Ezzel a megoldssal lnyegesen sikerlt kibvteni a kimen interfszre felhzott publikus IP-cmenknt kezelhet kapcsolatok szmt.
Source IP
Address
10.1.2.2
10.1.2.3
10.1.3.5

Source Port External IP

Number
Address
5001
192.0.2.1
5001
192.0.2.1
5002
192.0.2.1.

Temp. Port Transport

Number
Protocol
10001
TCP
10002
TCP
10003
TCP

7. tblzat: Hagyomnyos NAPT kapcsolat kvetsi tblzat (translation table) [8]

Source IP
Address
10.1.2.2
10.1.2.3
10.1.3.5
10.1.3.6

Source Port External IP

Number
Address
5001
192.0.2.1
5001
192.0.2.1
5001
192.0.2.1.
5001
192.0.2.1.

Temp. Port Destination

Number
IP Address
5001
198.51.100.2
5001
203.0.113.3
5001
198.51.100.2
10001
198.51.100.2

Dest. Port Transport

Number Protocol
80
TCP
80
TCP
443
TCP
80
TCP

8. tblzat: Kiterjesztett NAPT kapcsolat kvetsi tblzat (translation table) [8]

Megjegyezzk azonban, hogy a kezelhet kapcsolatok szma gy sem vgtelen, ezzel ksbb rszletesen foglalkozunk.
A cl IP-cm s cl portszm bevonsnak termszetesen ra van, a kapcsolattblban lnyegesen
nagyobb mret kulcs alapjn kell keresni! (A gyakorlatban hash fggvny segtsgvel oldjk meg
a gyors keresst.)
90

Az extended megoldst hasznlja pldul a Linux Netfilter keretrendszere [9] is, amit a felhasznli
interfsznek neve utn iptablesnek is szoktak nevezni.

4.2.2. Az Address plus Port (A+P) megolds

Az A+P mkdsi elve
Ez a megolds is az IPv4 cmek szkssgnek problmjt hivatott enyhteni. Alaptlete, hogy
az tvlasztsba vonjuk be az IP-cmeken tl a portokat is. Egy szolgltat ugyanazt az IP-cmet
tbb elfizetnek is kiosztja, s ezzel egytt az azonos IP-cmmel rendelkez elfizetknek
diszjunkt s megfelel mret portszm tartomnyokat is kioszt. Ezenkvl mindegyik elfizetnl
olyan eszkzt helyez el, ami az adott elfizet forrs portszm hasznlatt a neki kiosztott portszm
tartomnyra korltozza. A szolgltat ezutn sajt hlzatban az tvlasztsi algoritmust gy mdostja, hogy az A+P megoldsba bevont cmek esetn az adott cmre rkez datagramok a cl
portszm alapjn a megfelel elfizethz rkezzenek meg. Nzzk, meg, hogyan mkdik ez a
megolds!
Az elfizet kliense termszetesen nem foglalkozik azzal, hogy A+P mgtt van, teht tetszleges
forrs portot vlaszt. A szolgltat ltal kihelyezett eszkz egy NAT44 segtsgvel trja a forrs
portot az elfizet szmra kiosztott tartomnybl valamelyik szabad portra. A datagram gond
nlkl eljut a cmzetthez, majd a vlasz visszar szolgltathoz. A szolgltat specilis tvlasztsa
a cl portszm alapjn az azonos IP-cm elfizetk kzl a megfelelhz tovbbtja a datagramot,
majd a kihelyezett NAT44 eszkz trja a portszmot s gy a datagram eljut az illetkes alkalmazshoz.
A megoldsrl bvebben a (ksrletinek nevezett, 2011-ben kiadott) RFC 6346-ban olvashatunk.

Az A+P kritikja
A megvltoztatott tvlasztst tmogat eszkz mg kltsghatkonyan elhelyezhet a szolgltatnl, de a minden elfizethz kihelyezend eszkz mr rdemben drgtja a szolgltatst. Az
elfizetknek kiosztand diszjunkt portszm tartomnyok kvetelmnye mg slyosabb problma,
ugyanis ha tl kicsire vlasztjk, akkor az korltozza az elfizett9, gy cskkenti a szolgltats rtkt, ha pedig tl nagyra vlasztjk, az viszont tnkreteszi a megolds hatkonysgt. Pldul elfizetnknt 1024 portot szmtva 64 elfizet10 osztozhat egy publikus IP-cmen. Ezrt a megolds
jval kevsb hatkony, mint a NAPT, ahol nem kell maximumra mretezve fixen kiosztani az
egyes elfizetknek a portszm tartomnyokat, hanem a traditional esetben is statisztikai
multiplexels van, az extended hatkonysga pedig mg annl is sokkal jobb. Az A+P elnye viszont a specilis tvlasztst vgz eszkz llapotmentessge: vele szemben egy extended NAPT
eszkznek igen nagyszm kapcsolat kezelsre kell kpesnek lennie!
A NAPT-nl emltett emltett tovbbi problmk termszetesen itt is fennllnak.

4.3. A DNS64 + NAT64 megolds

4.3.1. A megolds elvi mkdse
Az IPv4 cmek kifogysa miatt az IP 4-es s 6-os verzijnak egyttmkdsben vrhatan az
lesz az els tipikus megoldand problma, hogy az internetszolgltatk csak IPv6 cmet tudnak

9 Lsd ksbb az egyes alkalmazsok portszm fogyasztst. Illetve egy elfizet (s csaldtagjai) egyidejleg tbb eszkz
hasznlatra is ignyt tarthatnak.
10 Vagy 63, ha a 0-1023 tartomnyt nem osztjuk ki.

91

adni az j gyfeleiknek, s a csak IPv6 cmmel rendelkez (IPv6-only) klienseknek el kell rnik a csak
IPv4 cmmel rendelkez (IPv4-only) szervereket is.
A DNS64+NAT64 megolds hasznlhatsgnak egyik szksges felttele, hogy a csatlakozni
kvn fl (kliens) a DNS rendszert hasznlja az elrni kvnt fl (szerver) IP-cmnek kidertsre,
s a kliensben nvkiszolglknt egy DNS64 szerver legyen belltva.
A DNS64 szerver (RFC 6147) egy caching-only nvkiszolglhoz hasonlan recursive querykre vlaszol. Ennek sorn, egy adott szimbolikus nvhez (domain name):
ha van IPv6 cm, akkor tovbbtja a vlaszban a kliensnek
ha nincs IPv6 cm, de IPv4 cm van, akkor az IPv4 cm alapjn generl egy specilis IPv6
cmet, s azt adja vissza a kliensnek.
A specilis IPv6 cm egy IPv4 cmet begyaz IPv6 cm (IPv4-Embedded IPv6 Address) ami a legegyszerbb esetben, az n. NAT64 Well-Known Prefix hasznlata esetn, a 64:ff9b::/96 prefix + az
utols 32 biten a szimbolikus nvhez tartoz IPv4 cm.
A megolds mkdshez tovbb szksges, hogy az tvlasztsi tblzatok szerint a NAT64
Well-Known Prefix (mint hlzat) fel az t egy NAT64 tjrn (RFC 6146) keresztl vezessen
(anycast cmzs hasznlhat).

25. bra: DNS64+NAT64 megolds elvi mkdse [10]

Az elvi megolds mkdst a 25. bra pldjn mutatjuk be. Kvessk vgig a pldt. Az IPv6only kliens csatlakozni szeretne az IPv4-only h2.example.com nev webszerverhez, ennek rdekben:
1. A kliens lekri a szerver IPv6 cmt a szimbolikus neve alapjn.
2. A DNS64 szerver a DNS rendszertl megkrdezi a h2.example.com nvhez tartoz
IP-cmet.11
3. Vlaszknt csak egy IPv4-cmet (192.0.2.1) kap (A record).
4. A DNS64 szerver a benne belltott NAT64 Well-Known prefix (64:ff9b::/96) hasznlatval ellltja a szksges IPv4 cmet begyaz IPv6 cmet (64:ff9b::c000:201) s ezt elkldi a kliensnek (AAAA record).

11 A valsgban a DNS64 szerver kt kln krst kld: elszr egy AAAA rekord krst, s amennyiben erre res
vlaszt kap, akkor egy A rekord krst [11]. Az RFC 6417 5.1.8. pontja azt is megengedi, hogy a kt krdst prhuzamosan kldje el (a msodik kldse eltt nem vrja meg az els vlaszt).

92

5. A kliens TCP SYN szegmenst tartalmaz IPv6 csomagot kld a kapott IPv4 cmet begyaz IPv6 cmre (64:ff9b::c000:201), amely a routing belltsa miatt a NAT64 tjrhoz rkezik meg.
6. A NAT64 tjr az IPv6 csomag alapjn egy IPv4 csomagot kszt; benne a clcm a specilis IPv6 clcm utols 32 bitje (192.0.2.1), a forrscm pedig a NAT64 tjr IPv4 cme
lesz. Kzben a NAT64 tjr eltrolja a kapcsolattbljba a szksges informcikat, s
ha korszer az implementci, akkor a forrs portszmot csak szksg esetn cserli. Az
tjr az elkszlt IPv4 csomagot elkldi a cmzettnek, ami az IPv4-only szerver.
7. Az IPv4-only szerver megkapja a TCP SYN szegmenst tartalmaz IPv4 csomagot s a
megszokott mdon vlaszol (SYN+ACK). Mivel a kapott IPv4 csomagban a forrscm a
NAT64 tjr IPv4 cme volt, a vlasz cmzettje is a NAT64 tjr IPv4 interfsze lesz, a
forrscm pedig a sajt IPv4 cme. A vlasz megrkezik az NAT64 tjrhoz.
8. A vlasz alapjn a NAT64 tjr elkszti a neki megfelel IPv6 csomagot, melybe forrscmknt ugyanaz a specilis IPv6 cm kerl, amit a DNS64 szerver generlt, clcmknt az
IPv6-only kliens IPv6 cme kerl; mindez a kapcsolattbla alapjn trtnik. Az IPv6 csomagot a NAT64 tjr elkldi az IPv6-only kliensnek.
Amikor az IPv6-only kliens megkapja a csomagot, gy folytatja a kommunikcit, hogy kzben
mit sem sejt arrl, hogy a szervernek IPv4 cme van. A klienshez hasonlan a szerver sem szlel
semmi klnset, hiszen ltszlag a NAT64 tjr IPv4 interfszvel kommunikl. Ennek persze
az a kvetkezmnye, hogy a szerver az IPv6-only kliens valdi IPv6 cme helyett a NAT64 tjr
IPv4 cmt fogja naplzni. Ez egyben a megolds egyik gyengesge is, de termszetesen nem csupn
a NAT64-, hanem a privt IP-cmek hasznlatakor alkalmazott NAT- is, mint azt mr emltettk.
(Szmos esetben okoz slyos problmt, pldul naplzsnl, IP-cm alapjn vgzett szavazsnl,
vagy kitiltsnl, stb.)
Megjegyzs: A NAT64-tl val megklnbztetsl a NAT-ot NAT44-nek is hvjk, amikor
mind a lecserlt, mind az j IP-cm verziszma 4-es.
A fentiekben bemutatott megolds az RFC 6052 szerinti 64:ff9b::/96 elre lefoglalt, n. NAT64
Well-Known Prefixet hasznlja. A prefix hasznlatnak szmos korltja van, lsd RFC 6052 3. rsz.
A NAT64 tjr megvalstsakor a gyakorlatban sok esetben az egyes IPv6 hlzatokbl szoktak
erre a clra lefoglalni egy rszt, ezt hlzat-specifikus prefixnek (Network-Specific Prefix) nevezik.

4.3.2. Az IPv4-cmeket begyaz IPv6-cmekrl

Az IPv4-cmeket begyaz IPv6-cmeket (IPv4-Embedded IPv6 Address) mg kt tovbbi nvvel illetik a felhasznlsuk cljtl fggen, br szerkezetk s ellltsuk azonos.
Azokat az IPv6 cmeket, amiket arra hasznlunk, hogy IPv4 llomsokat kpviseljenek
IPv6 hlzatokban, gy nevezzk, hogy IPv4-bl konverlt IPv6 cmek (IPv4-Converted IPv6
Address). A fenti pldban pontosan errl volt sz.
Az IPv4-re lefordthat IPv6 cm (IPv4-Translatable IPv6 Address) megnevezst pedig akkor
hasznljuk, ha a cm egy IPv6 llomshoz tartozik, s a fordts clja, hogy a csak IPv4-re
kpes eszkzk is el tudjk rni az IPv6 llomst. (Ezzel az esettel most nem foglalkozunk.)
Az RFC 6052 definilja, hogy hogyan kell az IPv4-cmeket begyaz IPv6-cmeket kpezni. Hlzat-specifikus prefixnl a hlzat adminisztrtora dnti el, hogy a rendelkezsre ll cmtartomnybl mekkora tartomnyt szeretne erre a clra sznni. Ennek megvlasztsa sorn tekintettel
kell lennie az albbi szablyokra is:
A prefix mrete szigoran csak 32, 40, 48, 56, 64 vagy 96 lehet.
Az IPv6 cmben a 64-71. sorszm biteknek 0 rtkeknek kell lennik.
Az IPv4 cm 32 bitjt a vlasztott mret prefix utn rjuk, de a fenti kvetelmny kielgtse rdekben a szigoran 0 rtk bitek helyt tugorjuk.
93

 A cm vgt szksg esetn ugyancsak 0 rtk bitekkel tltjk ki.

A cmek lehetsges formtuma:
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32|
prefix
|v4(32)
| u | suffix
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40|
prefix
|v4(24)
| u |(8)| suffix
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48|
prefix
|v4(16) | u | (16) | suffix
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56|
prefix
|(8)| u | v4(24)
| suffix
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64|
prefix
| u |
v4(32)
| suffix
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96|
prefix
|
v4(32)
|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Ha pldul egy /48-as cmtartomnyunk van, akkor a hlzat-specifikus prefix mrete /56, /64
vagy /96 lehet. A vlaszts szempontjairl az RFC 6052 3.3. s 3.4. rszben olvashatunk.

4.3.3. A megolds lettartama

IPv6 ttrsi megoldsrl lvn sz, az nyilvnval, hogy akkor mr nem lesz szksg r, amikor
minden eszkz kpes lesz az IPv6-ra. Azonban ehhez vrhatan mg akr egy vagy tbb vtizedre
is szksg lehet. A megvalstshoz hasznlt eszkzk forgalma kezdetben vrhatan nvekedni
fog a csak IPv6-ra kpes kliensek szmnak nvekedsvel, aztn vrhatan cskkensnek indul,
amint egyre nagyobb arnyban kpesek lesznek a szerverek IPv6-ra. s a forgalom hossz id alatt
vlik elenyszv. Olyan technolginak tljk meg, amit rdemes mind megismerni, mind kutatni,
mert legalbb egy vtizedig szksg lesz r.

4.4. A MAP megolds s vltozatai

A kiindulsi problma hasonl, mint a DNS64+NAT64 megoldsnl: IPv4 cmek kifogysa miatt
az internetszolgltatk mr nem tudnak 4-es verzij publikus IP-cmet adni a klienseknek, a szolgltat hlzatban csak IPv6 mkdik, de a klienseknek el kell rnik a csak IPv4 cmmel rendelkez szervereket. A megkzelts viszont ms: a kliensek nem IPv6 cmet kapnak, hanem privt
IPv4 cmet. A MAP vltozattl fggen a szolgltat IPv6 hlzatban vagy begyazssal
(encapsulation, MAP-E) vagy llapotmentes cmfordtssal (translation, MAP-T) kerl tvitelre a
datagram. A szolgltat IPv6 hlzata egy Border Relay eszkzzel kapcsoldik a publikus IPv4
hlzathoz.
Br ez is egy lehetsges megolds a publikus IPv4 cmek kifogysnak a problmjra, de ez a
megkzelts inkbb konzervlja a helyzetet: a klienseket az IPv4 vilgban tartja. Ezzel szemben a
NAT64+DNS64 megolds elremutat, a kliensek alapveten az IPv6 vilgba kerlnek, de lehetsgk nylik a csak IPv4 cmmel rendelkez szerverek elrsre is.
A rszletek trgyalsa nlkl megjegyezzk, hogy a megolds rokonsgban van az A+P mdszerrel, de gyes trkkel a portszmot az IPv6 cmben trolja, gy az IPv6 hlzatban szablyos, IPv6
cm alap tvlasztst vgezhet. Az A+P-vel val rokonsgot tkrzi a kt vltozatnak teljes neve

94

is: Mapping of Address and Port with Encapsulation (MAP-E, RFC 7597), illetve Mapping of Address and
Port using Translation (MAP-T, RFC 7599).
Mivel a megoldst nem tartjuk elremutatnak, bvebben nem foglalkozunk vele.

4.5. A DNS46+NAT46 megolds

A megoldand problma ppen a fordtottja, mint a DNS64+NAT64 esetn: itt a csak IPv4 cmmel rendelkez kliensek szmra szeretnnk biztostani a csak IPv6 cmmel rendelkez szerverek
elrst. Sajnos esetnkben a fordtott problma megoldsa nem hasznlhat egy az egyben. Mg a
teljes IPv4 cmtartomny knnyen lekpezhet az IPv6 cmtartomny egy kis rszre (egy IPv6
cmben bsgesen elfr egy teljes IPv4 cm), a fordtottja nem igaz. Ezrt dinamikus sszerendelst
(mapping) hoznak ltre a kt cmtartomny egyes elemei kztt. Mivel a kliens kizrlag IPv4 cmeket kpes kezelni, a DNS46 megolds az elrni kvnt szerver szimbolikus neve alapjn kidertett
IPv6 cmhez egy IPv4 cmet rendel, s azt adja vissza a kliensnek. A kliens az gy kapott IPv4 cmet
clcmknt felhasznlva kapcsoldik a szerverhez. gy van belltva a routing, hogy a DNS46 szerver ltal visszaadott IPv6 cmeket reprezentl IPv4 cmek tartomnya fel az tjr egy NAT46 eszkz,
ami ismeri a DNS64 szerver aktulis sszerendelseit (mapping), s elvgzi a cmek cserjt, valamint a protokoll konverzit. Ezt a megoldst ler RFC sajnos nem kerlt elfogadsra, az utols
draft mr 2010-ben lejrt [12]. Br a megoldst nem szabvnyostottk, mgis tbb implementcija
ltezik. Szabad szoftverknt pldul ltezik modul az OpenWRT-hez [13], s egyes nagy hlzati
eszkzgyrtk termkei is tmogatjk, pldul a Cisco ASA 5510 tzfal [14] vagy a Brocade
ServerIron ADX [15].
Mivel a megolds nem szabvnyos, mlyebben nem foglalkozunk vele, viszont kvncsian vrjuk,
hogy az IETF milyen szabvnyos megoldst knl a problmra.

4.6. A 6to4 megolds

Ezt a megoldst akkor hasznljuk, ha egy IPv6 kpes eszkz IPv4-only krnyezetben van, s IPv6
protokollal egy msik IPv6-os eszkzt szeretne elrni (akr az is lehet IPv4-only krnyezetben).
A 6to4 megolds (RFC 3056) egy automatikus tunnel, ami az IPv6 datagramokat IPv4
datagramokba csomagolja be (s termszetesen ki is). A 6in4-hez hasonlan a 41-es protokollazonostt hasznlja (lsd ksbb).

4.6.1. A 6to4 cmzse

Ahhoz, hogy egy eszkz IPv6 protokollt tudjon hasznlni, szksge van IPv6 cmre. Mivel a 6to4
megoldst natv IPv6 Internet elrs hinyban hasznljuk, az IPv6 cmet az IPv4 cmbl lltjuk
el, s a natv IPv6 cmektl val megklnbztets rdekben 6to4 IPv6 cmnek hvjuk.
A 6to4 cmzshez a 2002::/16 prefixet foglaltk le. A 6to4 IPv6 cmek kpzse az albbi mdon
trtnik.
Hlzatcm: 2002::/16 prefix + publikus IPv4 cm 32 bitje + 16 bit subnet ID
o Egyetlen host (lsd ksbb) esetn a subnet ID egy generlt vletlenszm.
o Ha a 6to4 mechanizmust router hasznlja, akkor akr tbb IPv6 hlzat is lehet
mgtte, ekkor hasznos a subnet ID.
Gpcm: A szabvnyos mdostott EUI-64 azonost
Ilyen mdon a 6to4 megolds minden publikus IPv4 cmhez egy 2002::/16 kezdet, /48 mret
IPv6 cmtartomnyt rendel. Mindegyik IPv4 cm mgtt elrhet lehet egy ilyen mret IPv6
hlzat.

95

4.6.2. A 6to4 megolds mkdse

A kommunikci sorn a 6to4 IPv6 cmmel rendelkez llomsok datagramjainak IPv4
datagramokba val be- s kicsomagolst vgz 6to4 psedo-interfsz (6to4 pseudo-interface) elhelyezse szempontjbl ktfle konfigurci lehetsges:
lehet egyetlen host, amin az IPv6 kliens fut, s a becsomagolst is a host vgzi a 6to4
pseudo-interface a hoston van (6to4 host)
lehet tbb IPv6-os gp egy IPv6 hlzaton, aminek a routere vgzi a becsomagolst a
6to4 (border) router rendelkezik 6to4 pseudo-interface-szel.
A mkds sorn ez a kt eset nem klnbzik lnyegesen, az viszont igen (s ezrt kln trgyalst ignyel), hogy az IPv4 krnyezetben lev IPv6 eszkz nevezzk a tovbbiakban 6to4 IPv6
llomsnak egy az IPv6 Internetre kapcsold natv IPv6 llomssal vagy egy msik 6to4 IPv6 llomssal kommunikl-e.
Tekintsk elszr egy 6to4 IPv6 lloms s egy natv IPv6 lloms kommunikcijt. Ebben az
esetben az IPv4 hlzat s a natv IPv6 Internet kztt egy tovbbi eszkzre van szksg: ez a 6to4
relay. A 6to4 relay feladata a 6to4 IPv6 llomstl rkez, IPv4 datagramba gyazott IPv6 datagram
kicsomagolsa s tovbbtsa az IPv6 Interneten t a natv IPv6 lloms fel. A msik irny kommunikci sorn szintn a 6to4 relay feladata a natv IPv6 llomstl szrmaz datagram IPv4
datagramba val becsomagolsa s az IPv4 hlzaton keresztl val tovbbtsa. Ilyen eszkzbl
tbb is lehet, az IPv4 irnybl a legkzelebbi a 192.88.99.1 anycast cmen rhet el.
A 6to4 megolds mkdst a 4. brn lthat hlzat pldjn mutatjuk be, ahol egy 6to4 IPv6
cmmel rendelkez kliens kommunikl egy natv IPv6 szerverrel. A kommunikci lpsei:
A kliens a szerver fel IPv6 csomagot kld (forrscm: 2002:c000:208::2, clcm:
2001:db8::2).
A becsomagols elvgzje (itt most a 2002:c000:208::1 cmen elrt 6to4 router, de lehetne
maga a host is) az IPv6 csomagot IPv4 csomagba gyazza, s az IPv4 segtsgvel elkldi
egy 6to4 relaynek (forrscm: 192.0.2.8, clcm: 192.88.99.1).
A begyazst elvgz 6to4 routerhez az IPv4 hlzat metrikja szerint legkzelebbi
(192.88.991 anycast cmre hallgat) 6to4 relay kapja meg a csomagot.
A 6to4 relay kicsomagolja az IPv4-be gyazott IPv6 csomagot, majd tovbbtja a natv IPv6
hlzatba (forrscm: 2002:c000:208::2, clcm: 2001:db8::2).
A natv IPv6 hlzatban a csomag megrkezik a cmzetthez.
A cmzett vlaszol (forrscm: 2001:db8::2, clcm: 2002:c000:208::2).
A vlasz a natv IPv6 llomshoz az IPv6 Internet metrikja szerint legkzelebbi, az IPv6
hlzatba 2002::/16 prefixet hirdet 6to4 relayhez rkezik meg. Ez lehet az elbbivel azonos vagy attl eltr 6to4 relay (jelen pldnkban eltr). Erre a kommunikl feleknek
nincs befolysa!
Visszafele a 6to4 relay az IPv6 csomagot IPv4-be csomagolva kldi a kliensnek, pontosabban a korbban a kliens IPv6 csomagjt IPv4-be csomagol eszkznek, ami pldnkban a
192.0.2.8 IPv4 cmre hallgat 6to4 router (forrscm: 192.88.99.1, clcm: 192.0.2.8).
Megjegyzs: A 192.0.2.8 clcmet a 6to4 relay a 2002:c000:208::2 IPv6 clcmbl tudta megllaptani.
A vlasz megrkezik a 192.0.2.8 IP-cm 6to4 routerhez.
A 6to4 router kicsomagolja az IPv4 csomagbl az IPv6 csomagot s elkldi a kliensnek
(forrscm: 2001:db8::2, clcm: 2002:c000:208::2).
Vgl a kliens megkapja a szerver vlaszt.
A fenti pldban a 6to4 lloms volt a kliens a natv IPv6 lloms pedig a szerver, de a fordtott
esetnek sincs akadlya, a kommunikci a natv IPv6 irnybl is kezdemnyezhet.
96

A megolds mkdshez szksges felttel, hogy a becsomagolst vgz eszkznek (6to4 router
vagy 6to4 host) legyen publikus IPv4-cme, klnben nem tudna rvnyes 6to4 IPv6 cmet nyjtani
a mgtte tallhat eszkzknek. Ha a becsomagolst vgz eszkznek nincs publikus IPv4 cme,
akkor a 6to4 helyett Teredot lehet hasznlni (RFC 4380).
A msik eset, amikor kt 6to4 lloms kommunikl egymssal (kt IPv6 szigetet ktnk ssze a
6to4 segtsgvel az IPv4 Internet felhasznlsval). Ebben az esetben a becsomagolst vgz eszkz a datagram cl IPv6-cmbl (2002::/16 prefix) tudja meg, hogy nem egy 6to4 relaynek, hanem
a megfelel IPv4 cm pseudo-interfsszel rendelkez eszkznek (6to4 host vagy 6to4 router) kell
IPv4 szinten cmeznie s kldenie a csomagot. A 26. bra pldja segtsgvel egy ilyen esetet is
nyomon kvethetnk. Kommunikljon most az elbbi pldban szerepl kliens az bra jobb fels
sarkban tallhat 6to4 llomssal:

26. bra: A 6to4 megolds lehetsgei [16] (mdostva)

A kliens a 6to4 lloms fel IPv6 csomagot kld (forrscm: 2002:c000:208::2, clcm:
2002:c633:640c::2).
A becsomagols elvgzje (a 2002:c000:208::1 cm 6to4 router) az IPv6 csomagot IPv4
csomagba gyazza. Ennek sorn az IPv6 csomagban szerepl clcm 2002::/16 prefixe
alapjn tudja, hogy a datagramot nem egy 6to4 relaynek kell cmeznie, hanem a cl IPv4
cm a cl IPv6 cmbl az els 16 bitet kvet 32 bit, azaz 198.51.100.12 lesz (forrscm:
192.0.2.8, clcm: 198.51.100.12).
A csomag megrkezik a 198.51.100.12 IP-cm 6to4 hosthoz.
A 6to4 host pseudo interfsze elvgzi a kicsomagolst s tovbbtja az IPv6 datagramot az
IPv6 interfsznek (forrscm: 2002:c000:208::2, clcm: 2002:c633:640c::2).
97

Az IPv6 cmen elrhet alkalmazs vlaszol (forrscm: 2002:c633:640c::2, clcm:

2002:c000:208::2).
A vlaszt a 6to4 host pseudo interfsze IPv4 csomagba gyazza. A cl IPv4 cmet szintn
a cl IPv6 cmbl llaptja meg (forrscm: 198.51.100.12, clcm: 192.0.2.8).
A vlasz megrkezik a 192.0.2.8 IP-cm 6to4 routerhez.
A 6to4 router kicsomagolja az IPv4 csomagbl az IPv6 csomagot s elkldi a kliensnek
(forrscm: 2002:c633:640c::2, clcm: 2002:c000:208::2).
Vgl a kliens megkapja a 6to4 host vlaszt.
Figyeljk meg, hogy ebben az esetben a kommunikciban mindkt irnyban ugyanazok a 6to4
interfszek vettek rszt. (Ez nem vletlen, hiszen a kommunikl eszkzk 6to4 IPv6 cmben az
IPv4 cmek egyrtelmen rgztettek voltak.)

4.6.3. A 6to4 megolds lettartama

A megolds mr rgta zemel. A tovbbiakban mr csak viszonylag rvid ideig van/lesz r szksg; addig, amg lesz olyan terlet, ahol az internetszolgltatk nem nyjtanak IPv6 elrst. Br az
Amerikai Egyeslt llamokban nmelyek mr (2011 ta) temetni szeretnk a megoldst12, Magyarorszgon Budapest kivtelvel mg nagyon is valsgos problma, hogy valaki nem tud IPv6 internet elfizetst vsrolni.

4.6.4. A 6to4 megolds problmi

Szolgltatsminsg
A 6to4 megolds ltal nyjtott szolgltats minsgre slyos kvetkezmnyekkel jr az, hogy
amennyiben egy 6to4 IPv6-ot hasznl lloms egy a natv IPv6-ot hasznl llomssal kommunikl, akkor amint lttuk a kt irnyban nem felttelnl azonos tvonalon (s 6to4 relayen) halad
a kommunikci, s ezen radsul a 6to4 lloms internetszolgltatja sem tud segteni. Mirt?
Vizsgljuk meg ezt a krdst! Amennyiben a 6to4 lloms internetszolglatja egyltaln nem foglalkozik azzal, hogy gyfeleli rszre IPv6 elrst biztostson, akkor a forgalom mindkt irnyban
valamilyen ms szervezet ltal zemeltetett 6to4 relayen halad keresztl. (A 6to4 router pedig az
gyflnl tallhat.) Ha az internetszolgltat rendelkezik natv IPv6 Internet elrssel, akkor zemeltethet egy sajt 6to4 relayt, amit az gyfeleinek a 192.88.99.1 anycast cmen meghirdetve elrheti,
hogy azok kimen 6to4 IPv6 forgalma rajta, mint szmukra legkzelebbi 6to4 relayen keresztl
menjen t az IPv6 Internetre. Arra azonban nincs befolysa, hogy a vissszafele irnyul forgalom
melyik 6to4 relayen menjen keresztl; egy adott gyfl esetn pontosan azon a relayen fog tmenni,
amely az IPv6 Interneten a legkzebb van ahhoz a natv IPv6 llomshoz, amellyel az gyfl szmtgpe ppen kommunikl. Ha az adott relay tlterhelt, akkor az negatvan befolysolja a felhasznl tal tapasztalt szolgltatsminsget. A problma orvosolhat a 6to4 megolds egy tovbbfejlesztett vltozata a 6rd (RFC 5969) hasznlatval. (Ami azonban NEM helyettesti a 6to4
megoldst!)

12 Az erre irnyul draft RFC nyomon kvethet: https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic. A 6-os

verziban mg a teljes 6to4 megoldsrl (RFC 3056) sz volt, 8-as verzitl mr egyre inkbb csak az RFC 3068 szerinti
192.88.99.0/24 anycast prefixrl. Ezt vgl 2015. mjusban elfogadtk, mint RFC 7526.

98

Biztonsg
A 6to4 megolds biztonsgi krdseivel kln RFC foglalkozik (RFC 3964). A 6to4 megolds
termszetbl addan rzkeny a szolgltatsmegtagads (DoS: Denial of Service) s a cmhamists (address spoofing) tpus tmadsokra. A legtbb biztonsgi problmt a 6to4 kvetkez kt
jellemzje okozza:
1. Egy 6to4 routernek el kell fogadnia s ki kell bontania brmely ms 6to4 routertl (6to4
hostot is belertve) vagy relaytl szrmaz forgalmat.
2. Egy 6to4 relaynek el kell fogadnia brmely natv IPv6 node forgalmt.
Az RFC-ben meghatroztak olyan szablyokat, hogy egy 6to4 routernek, illetve relaynek milyen
ellenrzseket kellene vgrehajtania. Pldul egy 6to4 router (a 6to4 hostot is belertve) ne engedjen
meg olyan forgalmat, aminek pldul:
1. IPv4 cme privt, broadcast vagy valamilyen lefoglalt tartomnyba tartozik
2. IPv4 forrscme nem egyezik meg azzal, ami a 6to4 prefixben van
3. IPv6 cme nem globlis IPv6 cm (hanem pldul link-loklis, stb.)
4. 6to4 prefixe nem egyezik meg a sajtjval.
Hasonlan 6to4 relayre is vannak ilyenek. Pldul a fentiek kzl az els hrom arra is vonatkozik.
Kifejezetten 6to4 relayre vonatkoz tilts, hogy ne fogadjon el 6to4 routertl olyan forgalmat, aminek az IPv6 clcmben 6to4 prefix szerepel (s nem natv IPv6 cm).
Sajnos ezeknek a szablyoknak a betartst a 6to4 implementcik nem mindig ellenrzik (knyszertik ki).
Az RFC szmos tmadsi lehetsget ler, amelyeket nem rszleteznk, csak megjegyezzk, hogy
a 6to4 sajnos sok lehetsget ad a tmadsra, ezrt aki hasznlni szeretn, annak mrlegelnie kell a
kockzatokat. Az OpenBSD opercis rendszerben pldul biztonsgi megfontolsbl nem implementltk a 6to4 megoldst: http://www.securityfocus.com/columnists/459.

4.6.5. A 6to4 tovbbfejlesztsei

Teredo
A 6to4 megolds hasznlatt korltozza, hogy hasznlathoz a 6to4 pseudo-interface szmra
publikus IPv4 cm szksges, de ma rengeteg felhasznl privt IP-cm gpet s valamilyen NAT
megoldst hasznl. A Teredot (RFC 4380) kifejezetten NAT-on keresztli mkdsre terveztk. Ezt
gy ri el, hogy a Teredo kliensek a jl ismert (kliensbe beptett) cmeken (3544-es UDP port)
elrhet Teredo szerverektl megszerzett informci alapjn IPv4 fltt UDP hasznlatval ptenek ki alagutat a megfelel Teredo relay fel, amelynek natv IPv6 kapcsolata van. A Teredo a
2001::/32 prefix IP cmeket hasznlja, ahol a kvetkez 32 biten a Teredo szerver IPv4 cme
tallhat, majd a kommunikci egyb paramterei, gy a NAT tpusa, s specilis kdolssal a NAT
eszkz publikus IPv4 cme, valamint az azon hasznlt UDP portszm is.
Mlyebben nem foglalkozunk vele, mivel egyrszt csak vgs megoldsnak (last resort) sznjk arra
az esetre, ha sem natv IPv6, sem 6to4 nem hasznlhat, msrszt pedig mostanban tervezik lekapcsolni a Teredo relayeket13.

6rd
Szintn a 6to4 negatv tulajdonsgainak kikszblsre szletett a 6rd (RFC 5969) megolds. A
6rd f elnynek szntk, hogy csak az adott szolgltat hlzatn bell s kontrollja alatt mkdik,
s itt szlltja IPv4 fltt az elfizetk IPv6 forgalmt. Ennek megfelelen nem a 2002::/16 prefixet,

13

A javaslat a kvetkez dokumentum 8. oldaln: http://www.ietf.org/proceedings/88/slides/slides-88-v6ops-0.pdf

99

hanem a szolgltat sajt IPv6 prefixt hasznlja. Ez azrt elnys, mert mg a 6to4 esetn kiszmthatatlan, hogy melyik 6to4 relayen keresztl megy t egy csomag a natv IPv6 hlzatbl az IPv4
hlzatba, itt a szolgltat prefixe ezt egyrtelmen meghatrozza. Mindez garantlt elrhetsget
s szolgltats minsget biztost az elfizetknek. Amennyiben teht egy szolgltat szeretne a
segtsgvel majdnem igazi IPv6 internet elfizetst nyjtani, akkor arra a clra kivlan alkalmazhat. Viszont a 6rd-t csak a szolgltat tudja a hlzatban bevezetni, a szolgltat nlkl a
megolds hasznlhatatlan, teht a 6rd NEM kpes a 6to4 megoldst helyettesteni.

4.7. A 6in4 megolds

Ezt a megoldst akkor hasznljuk, ha IPv6 szigetek csak IPv4 hlzaton keresztl tudnak egymssal kommuniklni (IPv6-over-IPv4, lsd: RFC 4213).
Ekkor az IPv6 csomagokat IPv4 csomagokba gyazva visszk t az IPv4 hlzaton. Az IPv4-ben
a 41-es protokollazonostt hasznljuk az IPv6 csomagok azonostsra. (Amint az IP fltt a
Protocol mezben a TCP protokollt a 6, az UDP-t a 17, az ICMP-t pedig az 1 rtk azonostja.) A
be- s kicsomagolst az IPv6 szigetek hatrn lev tjrk vgzik.
A megolds nagyon hasonlt a 6to4 technikra, azzal a klnbsggel, hogy az alkalmazott tunnelek
kizrlag manulis mdon hozhatak ltre. Ennek a mdszernek legnagyobb elnye a biztonsg,
hiszen csak elre belltott tunneleket alkalmaz, amelyek konfigurlst mindkt vgponton el kell
vgezni. Ez ugyanakkor htrnya is, hiszen egyttmkdst s munkt ignyel mindkt fltl. Problmt okoz mg, ha nincs mindkt oldalnak lland publikus IPv4 cme, hiszen ekkor minden cmvltozskor mdostani kell a tunnel msik vgpontjn lv eszkz belltsait. A mdszer ennek
ellenre elterjedt; a tunnel brkerek is ezt a megoldst alkalmazzk, s ltalban valamilyen kiegszt szoftver segtsgvel oldjk meg a belltsok (tunnel vgpont cmek) automatikus mdostst.

4.8. Az MPT tunnel

Az MPT [6] hlzati szint tbbutas kommunikcis knyvtrat (network layer multipath communication library) a Debreceni Egyetemen fejlesztettk ki Dr. Almsi Bla vezetsvel. Segtsgvel brmely verzij IP (4 vagy 6) fltt brmely verzij IP alagt (tunnel) ltrehozhat. Kpessgei ennl
lnyegesen bvebbek, segtsgvel lehetsg van tbb t tviteli kapacitsnak sszegzsre [17][18] vagy vezetk nlkli hlzatokban roaming megoldsra [19], akr eltr hlzati technolgik
estn is [20]. Mi most, mint az eltr IP verziszm problmjnak megoldsra hasznlhat alagtkpz megoldssal foglalkozunk vele.
Az MPT hlzati szint tbbutas kommunikcis knyvtr alapvet jdonsgt a sokkal kzismertebb Multipath TCP-vel (RFC 6824) val sszehasonlts segtsgvel mutatjuk be.
Az MPTCP tbb TCP kapcsolatot (TCP subflow) hasznl potencilisan eltr utak felett (27.
bra), ami egy j megolds az eltr tviteli utak kapacitsnak sszegzsre. A TCP ltal nyjtott
megbzhat bjtfolyam tpus tvitel tkletes megolds a hlzati alkalmazsok szles osztlya
szmra, mint pldul web bngszs, elektronikus levelek kldse vagy letltse, fjlok tvitele.
Viszont kifejezetten nem kvnatos egy msik osztly szmra, mint pldul az IP-telefnia, a videokonferencia vagy ms olyan vals idej alkalmazsok, amelyek jobban tolerljk a (kismrtk)
csomagvesztst, mint a nagy kseltetseket vagy ksleltets-ingadozsokat, amelyeket a TCP jrakldsi mechanizmusa okoz.
Az MPT hlzati szint tbbutas kommunikcis knyvtr UDP/IP-t hasznl minden link szint
kapcsolat felett, s ezek felett IP alagutat hoz ltre. A kt szint IP verzija egymstl fggetlenl
megvlaszthat. Az IP alagt fltt akr TCP, akr UDP hasznlhat (28. bra). Ezrt az jraklds
kihagyhat, ha nincs r szksg. Ez az architektra az MPT-t az MPTCP-nl ltalnosabb teszi,
100

ms felhasznlsi lehetsgekkel. Ezenkvl az MPT-t kivlan alkalmass teszi az IPv6-ra val

ttrs sorn (tbbfle) alagtkpz megoldsknt val hasznlatra az a tny, hogy a kt szinten
egymstl fggetlenl megvlaszthat az IP verzija.
Application
MPTCP
TCP subflow

TCP subflow

IP

IP

27. bra: Az MPTCP protokollverem (protocol stack) architektrja (RFC 6824)

Application
TCP/UDP (tunnel)
IP (tunnel)

MPT

UDP

UDP

IP

IP

Net Access

Net Access

28. bra: Az MPT knyvtr ltal megvalstott architektra [17]

Az MPT legjabb verzijban protokollvlts trtnt. A szerzk kvetik a GRE-in-UDP RFC
draft [21] specifikcijban lertakat. A koncepcionlis mkds ugyanaz maradt, de egy GRE fejrsz kerlt az IP tunnel s UDP fejrsz kz, ahogy azt a GRE-in-UDP megkveteli [22].

4.9. Tovbbi ajnlott forrsok

Az IPv6 ttrssel szmos publikci foglalkozik. Ajnlunk kzlk nhnyat. Az IPv4/IPv6
egyttlsrl, tjrsrl, migrcirl s trendekrl szl knyvfejezet: [23]. Hasonl tma, de a 3G
UMTS hlzatokra, kifejezetten mobil krnyezetre fkuszlva: [24]. Az IPv6 anycast ttekintst
tartalmazza, s egy specilis hasznlati lehetsgrl r a mobilits-kezels terletn: [25]. Az IPv6
ttrssel kapcsolatos trendek, statisztikk vizsglatval foglalkozik: [26].
Az IPv4 cmek megosztsra hasznlhat algoritmusokat osztlyozza [27], melynek sorn rtinti
azt fontos szempont is, hogy az egyes megoldsok elsegtik-e az IPv6 mielbbi bevezetst.

101

5. IPv6 ttrsi technolgik vizsglata

5.1. ltalnos ttekints
5.1.1. Vizsglati szempontok
Az alkalmazand IPv6 ttrsi technolgikat ltalban az egyes szervezetek (pl. internetszolgltatk) hlzati rendszergazdi vlasztjk ki a megoldand feladatokhoz. Nmely problma megoldsra tbb technolgia is ltezik, ilyenkor dnteni kell az adott clra legmegfelelbb technolgirl. Ezen tl a bemutatott ttrsi technolgik tbbsghez szmos implementci ltezik, melyek
kzl szintn vlasztani kell. Ezekben a dntsekben szeretnnk gyakorlati segtsget nyjtani a
tmban vgzett kutatsi eredmnyeink bemutatsval.
Ha egy technolginak vagy annak egy implementcijnak az les szolgati krnyezetben val
zemszer alkalmazhatsgt vizsgljuk, akkor a vizsglatnak legalbb a kvetkez ngy szempontra kell kiterjednie:
A megolds kompatibilis-e az alkalmazsokkal, befolysolja-e azok mkdst, hasznlhatsgt?
A megolds stabilan viselkedik-e, nem fog-e sszeomlani?
A megolds gazdasgos-e? Milyen a teljestmnye / erforrs fogyasztsa ms megoldsokhoz kpest?
A megolds biztonsgos-e? Milyen sebezhetsgei vannak, milyen kockzatokat hordoz
az alkalmazsa?
Ezek a krdsek mind az egyes technolgik, mind azok implementciinak szintjn felmerlnek.
Messze nem tudunk rjuk a teljessg ignyvel vlaszt adni. Kutatsaink sorn igyekeztnk elssorban azokat a technolgikat megvizsglni, amelyekre vrhatan hamarosan szksg lesz. Ezek kztt is ersen vlogatnunk kellett az erforrsaink (anyagi, humn, id) korltos volta miatt.
Kutatsainkat jelenleg is folytatjuk, eredmnyeinket folyamatosan publikljuk. Cikkeink ltalban
mr a brlati fzisban elrhetk itt: http://www.hit.bme.hu/~lencse/publications/.

5.1.2. Kivlasztsi szempontok

Csak szabad szoftver (free software) [28] (ms szhasznlatban nylt forrs (open source) [29]) implementcikkal foglalkoztunk. Erre tbb okunk is volt [16]:
Bizonyos cgek licencei (pldul: Cisco [30] s Juniper [31]) nem engedlyezik teljestkpessg-vizsglatok (benchmarking) eredmnyeinek publiklst.
Szabad szoftvereket brki, brmilyen clra hasznlhat, gy eredmnyeink a lehet legszlesebb kr szmra hasznosak.
A szabad szoftverek egyben ingyenesek is, ami szmunka is fontos szempont volt.
A tovbbiakban problmakrnknt bemutatjuk azokat a szempontokat, amelyek a vizsgland
technolgik s implementcik kivlasztsban vezettek bennnket.

IPv6 kliens esete az IPv4 szerverrel

A publikus IPv4 cmtartomny kimerlse miatt az els megoldand gyakorlati problma az, hogy
a klienseknek mr nem jut IPv4 cm, ezrt knytelenek az IPv6 protokollt hasznlni, de a szerverek
nagy rsze mg mindig csak az IPv4 protokoll segtsgvel rhet el. Erre a problmra szmos
megoldst talltak ki, melyek kzl a legfontosabbnak az albbiakat talltuk [32]:

102

A NAT-PT/NAPT-PT (RFC 2766) megoldst 2000-ben mg szabvnynak javasoltk

(proposed standard sttusz volt az RFC), de szmos ok miatt 2007-ben vgkpp elvetettk (RFC 4966).
Alkalmazsszint tjr (ALG: Application Level Gateway, lsd: RFC 2663) vagy ms nven
proxy hasznlata mkdkpes alternatva lehet, de nagyon kltsges, mert minden alkalmazshoz kln ki kell fejleszteni, s zemeltetni kell az IPv6 s IPv4 hlzatok hatrn.
A legltalnosabb s flexibilisebb megoldsnak az DNS64 szerver s NAT64 tjr alkalmazst tartjuk.
Ezrt a DNS64 s NAT64 megoldsok vizsglatval rszletesen foglalkoztunk.

IPv6-ra kpes kliens IPv4 krnyezetben

Magyarorszgon ma mg gyakran elfordul problma, hogy szeretne valaki IPv6-ot hasznlni,
de az internetszolgltatja mg nem kpes azt neki nyjtani. Erre a problmra a 6to4 s a Teredo
megoldsok lteznek. Kzlk a 6to4 vizsglatval foglalkoztunk.

Adott IP verzij szigetek sszektse a msik verzi felett

Elbb az IPv6 szigetek IPv4 fltti sszektse, majd az IPv4 szigetek IPv6 fltti sszektse
lesz vrhatan a gyakoribb feladat. Ezek mindegyikre alkalmas az MPT knyvtr. Ennek a teljestkpessgt is megvizsgltuk.

5.1.3. Vizsglati szempontok technolginknt

NAT64
A NAT64 technolginl az eddig elvgzett vizsglataink az albbiakra terjedtek ki:
A technolgia mely alkalmazsokkal kompatibilis s melyekkel nem?
A technolginak milyen a portszm fogyasztsa az egyes alkalmazsoknl?
Az egyes implementciknak milyen a stabilitsa s teljestmnye?
sszesen kt implementcit vizsgltunk, mert amikor a mrseket vgeztk, akkor azt a kt szabad szoftver implementcit talltuk vizsglatra rdemesnek. Ms (rszben ksbb megjelent) implementcik vizsglatt is tervezzk a jvben.

DNS64
Az egyes DNS64 implementcikat elssorban stabilits s teljestkpessg szempontjbl vizsgltuk hromfle opercis render (Linux, OpenBSD s FreeBSD) alatt. Az egyik implementci
hibja miatt rintettnk biztonsgi krdseket is.

6to4
Az egyes 6to4 implementciknl is teljestkpessget s stabilitst vizsgltunk. Itt szintn vizsgltuk az opercis rendszerek hatst is, br itt az opercis rendszer gyakran ersen behatrolta
a hasznlhat implementcikat.

MPT knyvtr
Az MPT knyvtr teljestmnyt abbl a szempontbl vizsgltuk, hogy milyen hatkonyan kpes
tbb tviteli t kapacitst sszegezni. Mind a hordoz, mind a tunnel protokoll szerepben mindkt IP verzi mkdst teszteltk (sszesen 4 forgatknyv).

103

5.2. A NAT64 technolgia kompatibilitsa

A tmval kapcsolatos kutatsi eredmnyeinket [33]-ben kzltk, most ezeket foglaljuk ssze.
Elszr ttekintjk az alkalmazsok kompatibilitsval kapcsolatos publikcik eredmnyeit, majd
bemutatjuk az ltalunk kivlasztott NAT64 implementcikat, a tesztelend alkalmazsokat, a tesztelsi mdszert, vgl kzljk s rtelmezzk az eredmnyeket.

5.2.1. Ms kutatk eredmnyei

koberne s Ciglari [34] 18 hlzati alkalmazs NAT64 kompatibilitst tesztelte elmletben s
gyakorlatban virtualizlt krnyezetben az Ecdysis [35] NAT64 implementci segtsgvel. Az eredmnyt hrom kategriba soroltk: j, feltteles s rossz (well translated, conditionally translated,
poorly translated). Megllaptottk, hogy az tlagos internet-felhasznlk ltal naponta hasznlt alkalmazsok tbbsgnl (konkrtan: HTTP, HTTPS, IMAP, NTP, POP3, RDP, CIFS, SMTP,
SSH, TELNET) az eredmny a j kategriba esik. Az FTP s BitTorrent protokollokat a feltteles,
a Skype, MSNP, SIP, OpenVPN, IPsec, PPTP protokollokat pedig a rossz kategriba soroltk.
Arra a kvetkezetsre jutottak, hogy az otthoni felhasznlk szempontjbl a VoIP s az zenetkld (Instant Messaging) alkalmazsok inkompatibilitsa rontja a felhasznli lmnyt. Vllalati
krnyezetben viszont a legtbb zleti alkalmazs megfelelen fog mkdni.
Bajpai s szerztrsai [36] egyes hlzati alkalmazsok klnfle implementciit teszteltk a
Dual-Stack Lite s a NAT64 megoldsokkal val kompatibilits szempontjbl. A tesztelt web bngszk: Safari 5, Google Chrome 10, Firefox 4, Opera 11, amelyekkel a kvetkez vizsglatokat
vgeztk el: WebMail (Gmail TLSv1 hasznlatval), mdia letlts (YouTube Flash s HTML5
hasznlatval), Google Maps, HTTP letlts, Web Chat (Gmail, Yahoo, Freenode IRC). Levelezsre az Apple Mail 4-es verzijt hasznltk s a kvetkez protokollokat teszteltk: IMAP (Gmail
s Microsoft Exchange), POP3 (Gmail) s SMTP (Gmail s Microsoft Exchange). zenetklds
(Instant Messaging) s IP fltti telefonls vizsglatra a kvetkezket teszteltk: iChat, Skype,
SIP. Tovbbi tesztelt protokollok: SSH, FTP, IRC, Git, Mercurial, OpenVPN, BitTorrent. Azt talltk, hogy kzlk a Skype, az OpenVPN, a BitTorrent s a SIP volt a NAT64-gyel inkompatibilis
(a Dual Stack Lite esetn pedig egyltaln nem szleltek problmt). Az inkompatibilits okt is
megvizsgltk. A Skype kliens egyltaln nem tmogatja az IPv6 protokollt. A Transmission nev
BitTorrent kliens sikeresen letlttte a torrent fjlt a trackerrl, de nem tudott csatlakozni olyan
peerhez, ami csak IPv6 cmmel rendelkez gpen futott. A cikk az OpenVPN-rl csak annyit llapt
meg, hogy nem tudott IPv6 fltt VPN csomagokat tvinni, konkrt rszleteket nem kzl.
Rszletesen lerjk viszont a Linphone nev SIP klienssel vgzett vizsglatot, ami IPv6 tmogatssal
rendelkezik. Ebbl annyit tartunk fontosnak megemlteni, hogy a SIP jelzstvitel mg sikeresen
lezajlott, de az RTP a mdiafolyam nem indult el. Ennek okaknt azt adtk meg, hogy az SDP
rekordokban a vgpontokat IPv4 cmek azonostjk. Az FTP-vel kapcsolatban nem jeleztek problmt, de sajnos azt nem kzltk, hogy aktv vagy passzv mdot hasznltak-e a vizsglat sorn.
Megjegyezzk, hogy az OpenVPN esetn mindkt cikk inkompatibilitst llaptott meg.
Egy msik cikkben [37] a Skype 5.0 verzijt NAT64 kompatibilisnek talltk, amit mi a korbbi
cikkek s sajt tapasztalataink alapjn egyarnt megkrdjeleznk, ezrt tovbbi eredmnyeiket nem
kzljk. Az emltett konferenciacikk kiadja (IARIA) szerepel az n. parazita (predator) kiadk s
folyiratok nemzetkzi listjn [38].
Vgezetl megemltjk, hogy az RFC 6586 pedig olyan gyakorlati tapasztalatokrl szmol be, amikor nhny felhasznl egy tisztn IPv6 hlzatot hasznlt, s az IPv4 Internetet NAT64-en keresztl rtk el. Szmos rdekes eredmnyt kzl, pldul 12 zenetkld alkalmazs kzl 6 mkdtt 6 pedig nem, 12 internetes jtk kzl pedig csak egyetlen egy mkdtt, ami web alap
volt. F kvetkeztetse, hogy a tisztn IPv6 alap hlzat hasznlhat, de vannak problmk.
104

5.2.2. A vizsglatainkhoz hasznlt NAT64 implementcik

A NAT64 technolginak klnfle alkalmazsokkal val kompatibilitsnak vizsglathoz kt
NAT64 implementcit hasznltunk: ezek a TAYGA+iptables s az OpenBSD PF.

TAYGA
A TAYGA [39] egy llapotmentes szabad szoftver NAT64 implementci, amit GPLv2 licensz
alatt adtak ki. A kszti zemszeren hasznlhat NAT64 implementcinak szntk olyan esetekre, amikor egy hardveres NAT64 eszkz hasznlata tlzs lenne [39]. Mivel llapotmentes, ezrt
csak 1-1 hozzrendelsre (one-to-one NAT) kpes IPv6 s IPv4 cmek kztt. Ezrt egy llapottart NAT44 megoldssal egytt hasznljk, ami Linux alatt az iptables. A TAYGA a forrs IPv6
cmeket egy megfelelen vlasztott privt IPv4 tartomny klnbz cmeire kpezi le (s termszetesen vgrehatja a protokoll konverzit IPv6-rl IPv4-re), majd a privt IPv4 cmeket az iptables
SNAT-olja a kimen interfsz publikus IPv4 cmre. A msik irnyban az iptables vgrehajtja a
(most mr) cl IP cmben a publikus IPv4 cmrl a megfelel privt IP-cmre val csert, a TAYGA
pedig az ltala ismert 1-1 hozzrendels segtsgvel trja az IPv4 csomagot IPv6 csomagra. A
megolds mkdshez a TAYGA konfigurlsakor a kliensek szmnak (s lehetsges egyidej
aktivitsnak) megfelel mret privt IPv4 tartomnyt kell belltani.

Packet Filter
A PF (Packet Filter) [40] az OpenBSD opercis rendszer beptett tzfala s csomagmanipulcis eszkze, s amiknt az OpenBSD, a PF is BSD licensz alatti szabad szoftver. A PF tmogatja
a NAT-ot, a terhels kiegyenslyozst (load balancing), a naplzst, valamint egyidejleg llapottart s llapotmentes csomagszrknt is hasznlhat.
A NAT64-et az 5.1 verzi ta tmogatja, s cmcsald fordtsnak (address familiy translation) nevezi. NAT64 implementcija az Ecdysis projektbl szrmazik [41]. llapottart mdban tbb
IPv6 cmet kpes egyetlen IPv4 cmre fordtani (many-to-one NAT), amihez llapottblt hasznl.
A TAYGA-val szemben ez nagy elny, mert gy nem kell minden egyes csomagot kt programnak
feldolgoznia.

5.2.3. A megvizsglt alkalmazsok

Vlemnynk szerint a leggyakrabban hasznlt (kihagyhatatlan) hlzati alkalmazsok a kvetkezk: HTTP, HTTPS, SMTP, POP3, IMAP4. Rajtuk kvl gyakran hasznlatosak mg: Telnet, SSH,
FTP, OpenVPN, RDP, Syslog, klnfle P2P s SIP. A megvizsglt protokollokat s legfontosabb
jellemziket a 9. tblzatban foglaltuk ssze.

5.2.4. Vizsglatok s eredmnyek

Mivel az egyes alkalmazsok mkdse eltr, rszben eltr struktrj hlzatokat kellett hasznlnunk a vizsglatukhoz. A tovbbiakban kitrnk majd a klnbsgekre, most a teszthlzat ltalnos felptst ismertetjk. A vizsglatokat a Szchenyi Istvn Egyetem Tvkzlsi Tanszknek
Tvkzls-informatika oktat s kutat kaboratriumban vgeztk. A vizsglatokhoz elklntett teszthlzatot ksztettnk, de ezt esetenknt sszekapcsoltuk a laboratrium hlzatval.
Hlzati eszkzknt egy 3Com Baseline 2948-SFP switchet hasznltunk VLAN-okkal. (A kvetkez
brkon a kt-kt switch szimblum ugyanazon switch eltr VLAN-jait jelenti.) IPv6 cmtartomnyknt az fd5c:6bc1:7bc7:ffff::/64 Unique Local IPv6 Unicast Address (ULA) tartomnyt vlasztottuk. sszesen legfeljebb 5 szmtgpet hasznltunk klnfle clokra. Az egyes alkalmazsok vizsglathoz hasznlt mrsi sszelltsokat az albbiakban mutatjuk be. A vizsglatok sorn
hasznlt rszletes belltsok, az egyes szoftverek verziszmai, valamint az egyes mrsek pontos
105

kivitelezse megtallhatk az eredeti cikknkben [33]. A teszteket mindkt NAT64 implementcival elvgeztk, s azonos eredmnyeket kaptunk. A teszteket mindig legalbb kt klienssel vgeztk annak rdekben, hogy elkerljk a hamis pozitv eredmnyt olyan esetben, amikor az els
kliens sikeresen csatlakozik/mkdik, de a tovbbiak mr nem.
alkalmazs protokoll
HTTP
HTTPS
SMTP
POP3
IMAP4
Telnet
SSH
FTP
OpenVPN
RDP
Syslog
P2P (BitTorrent)
SIP
RTP/RTCP SIP-hez

szlltsi protokoll
port
TCP
80
TCP
443
TCP
25
TCP
110
TCP
143
TCP
23
TCP
22
TCP
20,21
UDP/TCP
1194
TCP
3389
UDP
514
TCP/UDP 6881-6999
TCP/UDP
5060
UDP 1024-65535

9. tblzat: A megvizsglt protokollok s jellemzik [33]

IPv4 server
192.168.100.211/24

3com Baseline 2948-SFP Plus

192.168.100.221/24

NAT64
gateway
DNS64
server
fd5c:6bc1:7bc7:ffff::1/64

3com Baseline 2948-SFP Plus

fd5c:6bc1:7bc7:ffff::20/64

fd5c:6bc1:7bc7:ffff::21/64

IPv6 clients

29. bra: HTTP, HTTPS, Telnet, SSH, FTP, Syslog vizsglathoz hasznlt teszthlzat [33]
106

HTTP, HTTPS, Telnet, SSH, FTP, Syslog

A NAT64 technolginak a HTTP, HTTPS, Telnet, SSH, FTP, Syslog protokollokkal val kompatibilitsnak tesztelshez ugyanazt a hlzatot hasznltuk, a hlzat topolgija a 29. brn lthat.
Az FTP kivtelvel mindegyik protokoll gond nlkl egyttmkdtt a NAT64-gyel.
Az FTP mkdse sorn kt TCP kapcsolatot hasznl. A vezrl kapcsolat (control connection) a
kliensnek a szerverre trtn bejelentkezsekor pl fel, s mindvgig fennll. Kln adat kapcsolat
(data connection) pl fel minden egyes fjl, illetve knyvtr lista tvitele esetn. Az FTP-t aktv
mdban (active mode) s passzv mdban (passive mode) is lehet hasznlni. Amikor aktv mdban
adatkapcsolatra van szksg, akkor a kliens a vezrl kapcsolaton keresztl (a PORT paranccsal)
elkldi az IP-cmt s azt a portszmot, amelyen vrja a szerver kapcsoldst. A megadott IP-cm
s portszm felhasznlsval a szerver kezdemnyezi az adat kapcsolat felptst a kliens fel. Paszszv mdban viszont a kliens kri a szervertl az IP-cm + portszm prost (a PASV parancs segtsgvel), melyre vlaszul a szerver elkldi az IP-cmt s azt a portszmot, ahol vrja a kliens csatlakozst. Az adat kapcsolat felptst a kliens kezdemnyezi a szerver fel.
Ha a kliens NAT mgtt van, akkor csak a passzv md hasznlhat, aktv mdban ugyanis a
szerver kptelen lesz a kliens ltal kldtt (tipikusan privt) IP-cm gphez kapcsoldni. A problma megoldsra ltezik n. FTP protokoll segt (protocol helper), ami figyeli a vezrl kapcsolat
forgalmt s szksg esetn vgrehajtja az IP-cm s portszm fordtst. Mivel ilyet nem hasznltunk, aktv mdban sikertelen volt a fjlok s knyvtr listk tvitele, passzv mdban viszont kivlan mkdtt, ami megfelelt az elzetes vrakozsainknak.
f1.tilb.sze.hu
192.168.100.21/24

f2.tilb.sze.hu
192.168.100.22/24
VPN interface
172.16.0.6/24

VPN interface
172.16.0.1/24

IPv4 client

OpenVPN server
Lab

network

TCP / UDP
channel

192.168.100.221/24

NAT64 + DNS64
fd5c:6bc1:7bc7:ffff::1/64

VPN interface
172.16.0.10/24

VPN interface
172.16.0.14/24

IPv6 clients
fd5c:6bc1:7bc7:ffff::20/64

fd5c:6bc1:7bc7:ffff::21/64

30. bra: OpenVPN vizsglathoz hasznlt teszthlzat [33]

107

OpenVPN
Az OpenVPN vizsglathoz egy msik teszthlzatot ptettnk, amely a laboratrium hlzathoz is kapcsoldott. A vizsglatainkhoz kt darab IPv6-os klienst s egy darab IPv4-es OpenVPN
klienst, valamit egy IPv4-es OpenVPN szervert hasznltunk a 30. bra szerinti sszelltsban.
Miutn a szerver s az sszes kliens gpen elindtottuk az OpenVPN-t, ICMP-vel (ping) vizsglva
brmely kt kliens kztt sikeres volt a kommunikci. Ennek magyarzatt, s az irodalomban
publiklt eredmnyektl val eltrs okt abban ltjuk, hogy a hasznlt Linux Debian Wheezy opercis rendszerben tallhat OpenVPN nem hivatalos fejleszti foltot (unofficial developer patch) tartalmaz az IPv6 tmogatsra a 2.3.0 verzitl.

E-mail: SMTP, POP3, IMAP4

A levelez protokollok vizsglathoz is a labor hlzathoz kapcsold teszthlzatot ptettnk
(31. bra). Az letszersg rdekben kt IPv4-es szervert s kt IPv6-os klienst hasznltunk. A
nvfeloldst a laboratrium DNS szervere vgezte.
f2.tilb.sze.hu
192.168.100.22/24

f1.tilb.sze.hu
192.168.100.21/24

IPv4 mail servers

Lab network

192.168.100.221/24

NAT64 + DNS64
fd5c:6bc1:7bc7:ffff::1/64

fd5c:6bc1:7bc7:ffff::20/64

fd5c:6bc1:7bc7:ffff::21/64

IPv6 clients

31. bra: SMTP, POP3, IMAP4 s RDP vizsglathoz hasznlt teszthlzat [33]
Mind a levelek SMTP-vel val elkldse, mind azok POP3 illetve IMAP4 protokollal val letltse sikeres volt.

RDP
Az RDP vizsglatt is a 30. brn lthat hlzatot segtsgvel vgeztk, de csak az egyik szervert
hasznltuk. Itt is mindkt kliens sikeresen csatlakozott a szerverhez.
108

BitTorrent s Skype
A P2P alkalmazsok csaldjbl vett ezen kt reprezentns vizsglathoz a NAT64 tjr kls
interfsznek IPv4 Internet kapcsolatt a laboratriumi hlzaton keresztl biztostottuk. Mindkt
teszt sikertelen volt. BitTorrent esetn nem indult el a fjlok letltse, a Skype-nl pedig mr az
authentikci is sikertelen volt.

SIP
A SIP vizsglatt a 32. brn lthat hlzat segtsgvel vgeztk. Csak IPv4 cmen SIP proxyknt a Trixbox CE 2.8.0.4 verzijt hasznltuk. Az egyik IPv6-os s az IPv4-es gpre Debian
Linux alatt Linphone 3.5.2, a msik IPv6-os gpre Windows al Linphone 3.6.1 SIP kpes IP telefon
szoftvert (softphone) teleptettnk. Azt tapasztaltuk, hogy a hvsok mind IPv4-tl IPv6 fel, mind
az IPv6 fell IPv4 fel sikeresen felpltek, de beszlgetni nem lehetett, mert az RTP csatorna nem
plt fel. Br ellenrz ksrleteinkben NAT44 esetn a NAT mgtt opci biztostotta a megfelel mkdst, NAT64 esetn azonban ez sem oldotta meg a problmt [42].
f2.tilb.sze.hu
192.168.100.22/24

f1.tilb.sze.hu
192.168.100.21/24

sipc3
1000

IPv4 client

Lab network

SIP proxy

192.168.100.221/24

NAT64 + DNS64

fd5c:6bc1:7bc7:ffff::1/64

fd5c:6bc1:7bc7:ffff::20/64
sipc1
2000

fd5c:6bc1:7bc7:ffff::21/64

IPv6 clients

sipc2
2100

32. bra: SIP vizsglathoz hasznlt teszthlzat [33]

Eredmnyek sszefoglalsa s sszehasonltsa
Eredmnyeinket a 10. tblzatban foglaltuk ssze. Az ltalunk megvizsglt NAT64 implementci minden protokoll esetn azonosan viselkedett. A szakirodalomban kzlt eredmnyekhez kpest az OpenVPN esetn tapasztaltunk lnyeges eltrst, mely nlunk kifogstalanul mkdtt.
109

Alkalmazs protokoll

PF Tayga

HTTP
HTTPS
SMTP
POP3
IMAP4
Telnet
SSH
FTP passzv md
FTP aktv md
OpenVPN
RDP
Syslog
Skype
BitTorrent
SIP

I
I
I
I
I
I
I
I
N
I
I
I
N
N
N

I
I
I
I
I
I
I
I
N
I
I
I
N
N
N

Ecdsys
[34]
I
I
I
I
I
I
I
?
?
N
I

N
feltteles
N

[36]
I
I
I
I
I

I
?
?
N

N
N
N

10. tblzat: NAT64 implementcik alkalmazsokkal val kompatibilitsa [33]

Az irodalombl szrmaz rtkeknl megjegyezzk, hogy egyik cikkben sem emltettk az FTP
mkdsi mdjt, ezrt az sszefoglal tblzatba nem tudtunk rdemi eredmnyt rni, br mindkettben vizsgltk: [34] szerint feltteles, [36] szerint pedig mkdkpes az FTP. Hangslyozzuk,
hogy a mrseket mi 2013-ban vgeztk a [33] cikknkben megadott verziszm szoftverekkel
(tovbbi rszletek Hajas Tams szakdolgozatban [42]), az aktulis llapot vltozhat, ha tovbbi
protokollsegdek vlnak elrhetv.

5.3. A NAT64 technolgia portszm fogyasztsa

5.3.1. Ms kutatk eredmnyei: ami van, s ami kellene
A tma fontossga ellenre kifejezetten a NAT64 portszm fogyasztsval foglalkoz megbzhat
tudomnyos publikcit nem talltunk. Nhny olyannal tallkoztunk, amelyek hlzati alkalmazsok portszm fogyasztst vizsgljk.
Egyarnt hlzati alkalmazsok portszm fogyasztsnak fels korltjt vizsglja [43] s [44], mert
az Address plus Port (A+P) megolds (RFC 6346) esetn arra van szksg. Ez a megolds llapotmentes cm plusz port megfeleltetst (Stateless A+P Mapping, SMAP) hasznl, s ennek a tmogatsra a
64k mret portszm tartomnyt kisebb, fix mret tartomnyokra osztja fel. Ezek mretnek meghatrozshoz az alkalmazsok portszm fogyasztsnak egy j fels korltjra van szksg. Mindkt cikk azt javasolja, hogy ez a korlt nhnyszor 100 port krl legyen. Ezenkvl [43] kivlan
illusztrlja is a Google Map segtsgvel, hogy mi trtnik, ha nem ll rendelkezsre elegend szm
port: a portok szmt 15-re korltozva a trkp kb. feln fehr tglalapok maradtak, mert a szoftver
prhuzamosan tbb TCP kapcsolatot hasznl a minl gyorsabb letlts rdekben, s amikor a
portszmok elfogytak, sikertelen volt az jabb TCP kapcsolatok felptse.
A Dual Stack Light szempontjbl vizsgldnak, s a web bngszs portszm fogyasztsnak a
fels korltjt keresik [45] szerzi is. Azt szimulljk, hogy a TCP protocol stack hogyan reagl a
portszmok elfogysra: arra a megllaptsra jutnak, hogy ennek kvetkezmnye egy 3 msodperces fennakads (az id telik, de nincs vlasz). Vgl aktv kliensenknt 500 portot javasolnak.

110

Mindezekkel ellenttben a hagyomnyos (traditional) tpus NAT vagy NAT64 esetn nincs szksg
a portszmtartomny elzetes felosztsra, mert ezek (pl. az A+P-vel ellenttben) egy kzs tartomnybl dinamikusan alloklnak portot az egyes alkalmazsok szksgletei szerint. Ezrt ezek mretezshez valamifle tlagos portszm fogyaszts jelleg informcira van szksg. Ez nem felttlenl
jellemezhet egyetlen szmmal, szksg lehet valamilyen idfggvnyre.
Ami a kiterjesztett (extended) tpus NAT vagy NAT64 eszkzket illeti, azok a portszmokat jra
fel tudjk hasznlni a klnbz IP-cm szerverek fel, ezrt ebben az esetben elegend a legnpszerbb s legnagyobb portszm igny cl IP-cmekkel (szerverekkel) foglalkozni (rszleteket ld. ksbb).
Talltunk tovbb egy olyan cikket is, melyben az id fggvnyben vizsgltk klnfle hlzati
alkalmazsok portszm fogyasztst, de ez sajnos ugyanaz a cikk, aminek eredmnyeit korbban
nem ismertettk, mert nem tartottuk megbzhatnak [37]. A benne hasznlt vizsglati mdszer (s
a brlat) alapossgt tovbb az is megkrdjelezi, hogy sszesen kt website tesztelse utn bizonytottnak tekintik, hogy a Firefox portszm fogyasztsa magasabb, mint az Internet Explorer.
Ezrt eredmnyeik ismertetst most sem vllaljuk fel.
Ugyan nem tudomnyos cikk, hanem draft RFC, de fontos eredmnyt kzl: [46]. A 2.1. pontban
foglalkozik a NAT64 portszm fogyasztsval: a China Mobile szolgltat azt figyelte meg, hogy a
NAT64 szolgltats felhasznlnknt tlagosan kb. fele annyit portot ignyel, mint a NAT44, mivel
a legnpszerbb web szerverek jelents rsze elrhet IPv6-on keresztl, s ebben az esetben nincs
szksg NAT64-re. s ez az arny tovbb fog javulni az IPv6 elterjedsvel. De sajnos az arnyon
kvl konkrt szmrtkeket nem kzlnek.

5.3.2. Web bngszs portszm fogyasztsnak vizsglata

Ebben a rszben azon kutatsaink [47] eredmnyt mutatjuk be, amelyek clja az volt, hogy megvizsgljuk, hogy web bngszskor milyen lehet egy (hagyomnyos tpus) NAT64 eszkzn a
portszm fogyaszts nagysgrendje, azaz a bngszk hny prhuzamos TCP kapcsolatot hoznak ltre,
s ez milyen paramterektl fgghet.

A mrsi mdszer
A mrsekhez a korbban emltett TAYGA+iptables s OpenBSD PF NAT64 implementcikat
hasznltuk. Minden tesztet elvgeztnk mindkt sszelltssal, de az eredmnyekben nem talltunk
rdemi eltrst.
A mrshez olyan weboldalakat vlasztottunk, amelyek csak IPv4 cmmel rendelkeztek, teht elrskhz szksg volt NAT64-re. A vlasztott weboldalakat a 11. tblzatban soroltuk fel.
Weboldal
www.amazon.com
www.ask.com
www.baidu.com
www.ebay.com
www.linkedin.com
www.live.com
www.sohu.com
www.taobao.com
www.twitter.com
www.yandex.ru

11. tblzat: A vizsglatokhoz hasznlt weboldalak

111

A mrshez klnbz opercis rendszer s web bngsz kombincikat vlasztottuk annak

rdekben, hogy meg tudjuk vizsglni, milyen paramterektl fgg a portszm fogyaszts. A vizsgltatokhoz hasznlt kombincik az albbiak voltak:
Windows 7 Enterprise:
o Mozilla Firefox 21.0
o Internet Explorer 10.0.9200.16576
o Google Chrome 27.0.1453.110m
o Opera 12.15
Debian Wheezy 7.1 Linux + KDE 4.8.4:
o Iceweasel 17.0.6
o Konqueror 4.8.4
o Google Chrome 28.0.1500.45
Ubuntu 12.04 LTS Linux:
o Mozilla Firefox 21.0
A mrsi sszellts a 33. brn lthat. A klnfle bngszket mindig az IPv6 kliens szmtgpen futtattuk, s a portszm fogyasztst a NAT64 tjrn mrtk.
A mrseket scriptek segtsgvel automatizltuk, belertve a tvoli scriptek megfelel idztssel
val elindtst s lelltst is. Az idztseket a 34. brn mutatjuk be. Egy ksrlet 65 msodpercig
Lab network
(internet)

192.168.100.221/24

NAT64 + DNS64

fd5c:6bc1:7bc7:ffff::1/64

fd5c:6bc1:7bc7:ffff::20/64

IPv6 client computer

33. bra: A HTTP protokoll portszm fogyasztsnak mrse NAT64 tjrn [47]

3s

Web browser is running

60 s
t (s)

1s

Metering port consumption

65 s

34. bra: A mrsek idztse [47]

112

tartott. Az els mrst 1 msodperc ksleltetssel indttuk, s a hasznlt portok szmt msodpercenknt naplztuk. A bngszt a portszm mrsnl mg kt msodperccel ksbb indtottuk, 60
msodpercig futtattuk s mg a bngsz lelltsn tl kt msodpercig ment a portszm mrs.
Ezeket a vd intervallumokat azrt hasznlatuk, hogy a tvoli script indtsbl s lelltsbl
add szinkronizcis problmkat elkerljk, hiszen az egyes folyamatok indtsa s lelltsa nem
nulla id alatt trtnt meg. A mrshez hasznlt scripteket most mellzzk, azok megtallhatk
[47] cikknkben. Minden mrst 11-szer vgeztk el.

Eredmnyek

ask.com

baidu.com

ebay.com

linkedin.com

live.com

sohu.com

taobao.com

twitter.com

yandex.ru

Windows/Firefox
Windows/Opera
Windows/Explorer
Windows/Chrome
Debian/Chrome
Debian/Iceweasel
Debian/Konqueror
Ubuntu/Firefox

amazon.com

Az eredmnyek els ttekintst a 12. tblzat segtsgvel tehetjk meg. A benne szerepl szmrtkek az adott URL megnyitsnak kezdettl a vizsglati id vgig mrt portszm fogyaszts
maximumt adjk meg. Az els megfigyelseink a kvetkezk:
Igen nagy az eltrs (az ltalban) legkevesebb portot fogyaszt twitter.com (9-16 port, a
bngsztl fggen) s a legtbbet fogyaszt sohu.com (122-198) web oldal portszm
fogyasztsa kztt.
Mg egyes oldalak portszm fogyasztsa ersen fgg a bngszktl (pldul a baidu.com
esetn csak 8 Windows/Explorerrel s 27 Ubuntu/Forefox-szal, ami tbb mint hromszoros eltrs) addig ms oldalaknl ez az eltrs sokkal kisebb (pldul az ask.com estn
mindig 24 s 33 kztt van).
Egyes URL-eknl ugyanannak a bngsznek a portszm fogyasztsa szmotteven eltrhet klnbz opercis rendszerek alatt (pldul az ebay.com esetn a Chrome Windows
alatt csak 30, Debian alatt 48 portot hasznlt).

74
58
67
48
52
55
35
52

28
24
24
25
32
31
26
33

25
16
8
10
13
25
11
27

42
32
37
30
48
43
39
40

18
14
15
14
23
19
12
20

26
37
21
23
39
25
21
25

198
140
123
122
122
186
122
166

135
73
77
67
72
131
135
117

11
13
14
11
16
12
9
11

26
20
19
18
23
20
17
21

12. tblzat: Egyes kliens s URL kombincik maximlis portszm fogyasztsa

A fenti megfigyelseken tl le kell szgeznnk, hogy ezek a szmok maximlis rtkek, s ha
ezeket hasznlnnk a mrt portszm fogyaszts tnyleges eloszlsa helyett, akkor az esetleg tlsgosan konzervatv becslshez vezetne (az eloszls jellegtl fggen). Ezrt egyrszt mlyebbre kell
snunk, msrszt viszont igencsak kvnatos volna az egyes eloszlsokat egyetlen szmmal helyettesteni, ugyanis olyan sok figyelembe veend paramternk van, hogy a teljes eloszls figyelembe
vtele megneheztheti lnyeg megragadst.
Vajon helyettesthetjk-e az eloszlst az tlaggal? (Az tlag jl tkrzi-e az eloszlst?) Szndkosan kt
ersen eltr esetet vlasztottunk, ahol grafikusan brzoljuk az egyes ksrletekben mrt eredmnyek adott idpillanatban vett minimumt, maximumt s tlagt, st hibasvok (error bars) formjban feltntetjk az [tlag szrs, tlag + szrs] intervallumokat is. A 35. bra alapjn gy tnik,
113

hogy a szrs (tipikus rtke 8 krl van) viszonylag kicsi az tlaghoz kpest (tipikus rtke 140
krl van), gy az tlag jl tkrzi az eloszlst. Az 36. brn viszont egy ellenpldt lthatunk: itt az
ltag sszemrhet a szrssal (klnsen 40 s 60 msodperc kztt). Mindezek ismeretben,
mgis csak az tlagos portszm fogyaszts rtket tntetjk fel az id fggvnyben, amikor a 8
megvizsglt opercis rendszer + bngsz kombinci viselkedst sszehasonltjuk, ugyanis 8
vonal tbb, mint elg egy brn (a tovbbi vonalak teljesen emszthetetlenn tennk azt).
sohu.com - Ubuntu/Firefox
180
160
Number of ports

140
120
100
Max.
Avg.
Min.

80
60
40
20
0
0

10

15

20

25

30

35

40

45

50

55

Time (s)

35. bra: A sohu.com portszm fogyasztsa Ubuntu/Firefox bngszvel [47]

twitter.com - Debian/Iceweasel
Max.
Avg.
Min.

14
Number of ports

12
10
8
6
4
2
0
0

10

15

20

25

30

35

40

45

50

55

Time (s)

36. bra: A twitter.com portszm fogyasztsa Debian/Iceweasel bngszvel [47]

Az sszes mrsi eredmny megtallhat Hajas Tams szakdolgozatnak [42] CD mellkletn.
Ezek vizsglata alapjn elmondhat, hogy a kt brn bemutatott helyzet reprezentatvan tkrzi a
mrs stabilitst. Ugyanis a 35. brn nagy mrtk (100-as nagysgrend) portszm fogyaszts
mellett a relatv szrs alacsony. A 36. brn pedig ugyan nagy a relatv szrs, de a portszm fogyaszts rtke alacsony (nagysgrendileg 10 krli), teht egy NAT64 tjr mretezse szempontjbl a mrsi bizonytalansg nem szmottev.
Hogyan befolysolja az opercis rendszer + bngsz vlaszts az egyes oldalak porszm fogyasztst? A 37. brn a tesztelt opercis rendszer + bngsz kombincik portszm fogyasztst mutatjuk be a
sohu.com oldal esetn. Az egyes kombincik portszm fogyasztsa kztti lnyeges klnbsg
igen jl lthat: pldul az tlagrtk maximumt (188,18) a Widows/Firefox kombinci adja 18
msodpercnl, amikor is a Debian/Crome tlagos rtke csak 110 krl van, ami lnyeges eltrs.
A 38. brn pedig a linkedin.com esetn vizsgljuk meg ugyanezt a krdst. Ennek az oldalnak a
portszm fogyasztsa lnyegesen kisebb, de az eltrs itt is lnyeges: itt a Debian/Iceweasel adja a
maximumot (18,36) 20 msodpercnl, amikor a Debian/Konqueror rtke csak 10,8. Mindenesetre
a legnagyobb portszm fogyaszts egyik esetben sem haladta meg a legkisebb rtk ktszerest
114

sohu.com
200

Number of ports

150
100
50
0
0

10

15

20

25
30
Time (s)

35

40

45

50

55

Windows/Firefox

Windows/Opera

Windows/Explorer

Windows/Chrome

Debian/Chrome

Debian/Iceweasel

Debian/Konqueror

Ubuntu/Firefox

37. bra: A sohu.com tlagos portszm fogyasztsa klnbz bngszkkel [47]

linkedin.com
20

Number of ports

15
10
5
0
0

10

15

20

Windows/Firefox

25
30
35
Time (s)
Windows/Opera

Windows/Chrome

Debian/Chrome

Debian/Konqueror

Ubuntu/Firefox

40

45

50

55

Windows/Explorer
Debian/Iceweasel

38. bra: A linkedin.com tlagos portszm fogyasztsa klnbz bngszkkel [47]

amazon.com
60
Number of ports

50
40
30
20
10
0
0

10

15

20

25
30
Time (s)

Windows/Firefox

35

40

45

50

55

Ubuntu/Firefox

39. bra: Az amazon.com tlagos portszm fogyasztsa azonos bngszvel klnbz opercis rendszereken [47]

115

live.com
35

Number of ports

30
25
20
15
10
5
0
0

10

15

20

25
30
Time (s)

Windows/Chrome

35

40

45

50

55

Debian/Chrome

40. bra: A live.com tlagos portszm fogyasztsa azonos bngszvel klnbz opercis rendszereken
[47]
Adott bngsz mellett hogyan befolysolja az opercis rendszer a portszm fogyasztst? Kt olyan bngsznk volt (Firefox s Chrome) amelyet kt platformon is teszteltnk. Br a tesztelt oldalak tbbsgnl az eredmnyek igen hasonlak voltak, nhny esetben jelents eltrst tapasztaltunk. Pldul a 39. brn a Firefox eredmnyeit lthatjuk az amazon.com oldal esetn. Mg Windows esetn
az tlagos portszm fogyaszts elri az 55-t, addig Ubuntunl ez alig haladja meg a 40-et. A 40. brn pedig a Chrome eredmnyeit lthatjuk. Itt Windows esetn elri a 30-at, mg Debian esetn 22
alatt marad. (A legnagyobb rtk itt sem rte el a legkisebb rtk msflszerest.)
Mindezek alapjn megllaptjuk, hogy a web bngszs portszm fogyasztsa nhnyszor 10-tl
nhny 100-ig terjedhet, rtke ersen fgg a megltogatott weboldaltl, de fgg a bngsztl is
(ktszeresnl kisebb eltrst tapasztaltunk), st mg adott bngsz esetn az opercis rendszertl
is fgghet (a tapasztalt eltrs msflszeres alatti volt).
Megjegyezzk tovbb, hogy a fenti vizsglatok eredmnyt jelentsen befolysolja az a krlmny, hogy PC-s krnyezetben trtntek. Okostelefonok esetn a szksges portszmok mennyisge ettl eltr (akr alacsonyabb is) lehet. Garai Gbor szakdolgozatban [48] arra a kvetkeztetsre jutott, hogy egy kis kpernys eszkz (Symbian alap okostelefon) portszm fogyasztsa jelentsen alacsonyabb egy nagy kpernys eszkz (Linuxot vagy Windowst futtat PC) portszm
fogyasztsnl.
Mindezek alapjn arra a kvetkeztetsre jutottunk, hogy a NAT64 tjrk mretezshez tovbbi
vizsglatokra van szksg.

5.3.3. FTP s tovbbi alkalmazsok portszm fogyasztsnak

vizsglata
Ezzel a krdssel is a [47] cikknkben foglalkoztunk, most az ott elrt eredmnyeket foglaljuk
ssze.

FTP portszm fogyasztsnak mrse

A mrshez hasznlt hlzat topolgijt a 41. brn mutatjuk be. Az bra tetejn lthat, csak
IPv4 cmmel rendelkez gp volt az FTP szerver, a klnbz FTP klienseket pedig az bra aljn
lthat csak IPv6 cmmel rendelkez gpen futtattuk.
A HTTP vizsglathoz hasonlan itt is klnbz opercis rendszer s FTP kliens kombincikat hasznltunk. Ezek a kvetkezk voltak:
Windows 7 Enterprise:
116

o FileZilla 3.7.3 (belltva: 1 majd 10 prhuzamosan letlthet fjl)

o Total Commander 8.01
Debian Wheezy 7.1 Linux:
o parancssori ftp kliens 0.17-27
o Midnight Commander 4.8.3-10

A kvetkez szm s mret fjlt tltttk le:

1x 100 MB
30x 1 MB
100x 1 MB
1x 500 MB
A portszm hasznlat mrshez a HTTP vizsglatokhoz hasznlt mr scriptek mdostott vltozatait hasznltuk.

FTP eredmnyek
Eredmnyeinket a 13. tblzat tartalmazza. Ezekkel kapcsolatban megllaptottuk, hogy:
A felhasznlt portok szma kzel arnyos az tvitt fjlok szmval, de mindig valamennyivel nagyobb annl.
IPv4 only server

f2.tilb.sze.hu
192.168.100.22/24

Lab network

192.168.100.221/24

NAT64 + DNS64
fd5c:6bc1:7bc7:ffff::1/64

fd5c:6bc1:7bc7:ffff::20/64

IPv6 only client

41. bra: Az FTP portszm fogyasztsnak mrshez hasznlt hlzat [47]

117

A Midnight Commander klnfle knyvtr listkat tlt le, ez a magyarzata annak, hogy
mr egyetlen fjl esetn is jelents szm portot hasznl, s tbb fjl esetn is van egy kb.
konstans tbblete a tbbi alkalmazshoz kpest.
A Filezilla a 10 prhuzamosan letlthet fjl bellts esetn 9-cel tbb portot hasznlt,
mint amikor 1-et lltottunk be.
File mret (MB)
Debian/FTP
Debian/MC
Windows/TC
Windows/Filezilla 1 prhuzamos
Windows/Filezilla 10 prhuzamos

100 30 x 1
2
32
10
39
3
32
4
33
42

100 x 1 500
102
2
109 10
102
3
103
4
112
-

13. tblzat: A klnfle FTP kliensek portszm hasznlata [47]

5.3.4. Tovbbi alkalmazsok portszm fogyasztsa

Teszteltk mg a korbban NAT64-gyel kompatibilisnek tallt kvetkez protokollokat is: SSH,
SCP, OpenVPN, SMTP, POP3, IMAP4, RDP, SYSLOG. (Az SCP-t ugyanazokkal a fjlokkal vizsgltuk, mint az FTP-t). Ezek mindegyike csak 1-1 portot hasznlt [47].

5.3.5. A globlis web forgalom portszm fogyasztsnak becslse

A mdszer clja, alaptlete s korltai
Web bngszs tlagos portszm fogyasztsnak kzelt, nagysgrendi jelleg becslsre dolgoztunk ki
mdszert [8] cikknkben. A mdszer mind hagyomnyos, mind kiterjesztett NAT, illetve NAT64
eszkzk mretezshez hasznos lehet, ezekhez hasonl mdon, de kt kln mennyisget hatroz
meg.
A mdszer alaptlete, hogy letltssel megvizsgljuk a legnpszerbb weboldalak portszm fogyasztst, s ezekbl kpeznk slyozott tlagot vagy slyozott maximumot a npszersgknek
megfelel slyokkal (lsd ksbb).
A mdszernek szmos korltja van, pldul az, hogy a weboldalak kezdoldalnak s tovbbi
oldalainak (ahova esetleg csak felhasznli nv s jelsz megadsa utn lehet eljutni) a portszm
fogyasztsa jelentsen eltrhet. Tovbb elhanyagolsokat (a portszm fogyasztsnak a bngsztl
s az opercis rendszertl val fggse) s kzeltst (ltogatsok szmt a ltogatk szmval)
alkalmaztunk, ezenkvl a statisztikai adatok is hinyosak voltak. Mindezek ellenre megadtunk egy
mdszert, ami nagysgrendi becslst kpes nyjtani, s konkrt idfggvnyeket is meghatroztunk
a hagyomnyos, illetve a kiterjesztett NAT/NAT64 eszkzkhz. Ezek nmagukban mg nem
elegendk ilyen eszkzk mretezsre, mert szksg van mg a felhasznli viselkeds figyelembe
vtelre is. Pldul mennyi ideig idznek a felhasznlk egy-egy oldalon, milyen gyakorisggal
kattintanak (click), milyen valsznsggel maradnak az adott oldalon, illetve hagyjk el azt. A felhasznli viselkedsnek jl kidolgozott irodalma van, jabb s rgi cikkek egyarnt tallhatk benne,
pldul: [49]-[51], ezzel mi nem foglalkoztunk.

Mit mrjnk?
Ha egy szolgltat NAT44 vagy NAT64 eszkzt szeretne mretezni, akkor tudnia kell, hogy a
felhasznlinak a forgalma vajon milyen mennyisg portszmot fog ignyelni. Egy felhasznl
portszm ignye szolgltatnknt tbb okbl is eltr lehet, hiszen orszgonknt msok lehetnek
a felhasznli szoksok (ms jelleg oldalakat ltogatnak) s jelents klnbsg lehet a mobil s a
118

vezetkes felhasznlk portszm fogyasztsa kztt (akr az eltr tartalom, akr az eltr kpernymret miatt). Korbban feltrtuk tovbb, hogy egy adott oldal letltse sorn eltrs van a
klnbz bngszk portszm fogyasztsa kzt, st mg azonos tpus bngszk kztt is, ha
azok eltr opercis rendszerek alatt futnak. Egy ltalnos cl vizsglatnl azonban vigyzni kell
arra, nehogy a tl sok paramter figyelembe vtele miatt a mdszer tlsgosan bonyolultt, idignyess, s gy a gyakorlatban hasznlhatatlann vljon. Ezrt kvetkez dntseket hoztuk.
A portszm fogyasztsnak a bngsztl s az opercis rendszertl val fggst teljesen
elhanyagoljuk. Ugyanis egyik oldalrl a korbbi mrseink szerint a megvizsglt URL-ek
esetben a legkisebb s a legnagyobb portszm fogyaszts kztt legfeljebb egy 2-es szorz
volt a klnbsg, ami nagysgrendi becslsnl (1 vagy 500 port per kliens) mg megengedhet. A msik oldalrl viszont a szba jhet bngszk s opercis rendszerek mindegyikn elvgezni a mrseket, majd azutn az eredmnyeket azok piaci rszvel (ami nem
pontosan ismert, radsul idben vltoz) slyozva tlagolni az eredmnyeket; tlsgosan
nagy munkt ignyelne.
A terleti, illetve a mobil/vezetkes jellegbl fakad eltrseket gy kezeljk, hogy egy ltalnos mdszert definilunk, s a mrseket valamilyen konkrt adatokkal vgezzk el.
Szksg esetn a mrseket specifikus input adatokkal elvgezve az eredmnyek adott
esetre nzve pontosthatk.

Input adatok kivlasztsa

Lehetsges bemeneti adatknt megvizsgltunk klnbz statisztikkat. A legismertebb az Alexa
ltal ksztett globlis 500-as lista [52], de van ennl bvebb, illetve orszgonknti vagy tartalom kategrinknti statisztikjuk is. Ezek a listk azonban sajnos csak rangsorok (rank list), nem adjk meg
az egyes site-oknak a teljes web forgalombl val rszesedst (amire szksg lenne az oldalakon
mrt porszm fogyasztsi adatok slyozott sszegzshez). Egy msik oldalon [53] vannak ugyan
slyok, de ott egyrszt csak 35 web site-ot sorolnak fel, msrszt az adatok tl rgiek (2012. viek),
ezrt hasznlhatatlanok. Egy harmadik oldalon [54] tallhat Nielsen top 100 lista kivl lenne, mert
az egyedi ltogatk szmn (unique audience) kvl az sszes letltsek szmt (total visits) is megadja, de
sajnos a kora miatt (2010. vi) szintn hasznlhatatlan. Vgl a Quantcast [55] 100-as listjt vlasztottuk. Ez sem teljesen j, ugyanis egyrszt a 12 rejtett profil (hidden profile) miatt csak 88 elemt
tudtuk hasznlni, msrszt csak a havi ltogatk (monthly people) szmt kzli, amivel csak kzelteni
tudtuk a havi letltsek szmt (amire a web forgalomban val slyknt szksgnk van). De legalbb
aktulis. (A lista orszgonknt kszlt, az USA-t vlasztottuk.)

A mrsi mdszer
Korbban 60 msodperces idintervallumban mrtnk [47], s azt tapasztaltuk, hogy br az oldalak ennyi id alatt letltdtek, mgsem cskkent nullra a portszm fogyaszts a NAT64 tjrn.
Ennek kt oka is lehetett: vagy tnyleg ltek mg a TCP kapcsolatok, vagy pedig azok ugyan mr
lezrultak, de a NAT64 eszkzben mg nem telt le a time-out, s ezrt voltak mg jelen az llapottblban. Mivel klnbz NAT/NAT64 eszkzkben eltr lehet a (default) time-out rtk, gy
dntttnk, hogy azt az intervallumot mrjk, amg a TCP kapcsolat tnylegesen fennll, s szksg
esetn az egyes eszkzk konkrt time-out rtke ksbb figyelembe vehet. Az az id, amg a TCP
kapcsolat fennll, csak a klienstl s a szervertl fgg, az esetleges NAT/NAT64 eszkztl nem,
ezrt a mrsekhez nem volt szksg ilyen eszkzre.
A szmtsokhoz hasznlt mrsek eltt vgeztnk egy mrs sorozatot a szksges mrsi idintervallum meghatrozsra, hogy az egyrszt kellen hossz legyen, msrszt ne vesztegessnk el
feleslegesen sok idt.

119

A mrs paramterei
A mrshez egy tlagos otthoni szmtgpet hasznltunk a kvetkez paramterekkel: AMD
Athlon 64 X2 Dual Core 4200+ 2200 MHz CPU, 2 GB DDR2 667 MHz RAM, 320 GB HDD,
Internet hozzfrs egy Linksys E3000 routerrel kbelneten keresztl 60 Mbps letltsi s 6 Mbps
feltltsi sebessg mellett. A szmtgpen Debian Linux 7.6 opercis rendszer s KDE volt.
Iceweasel (Firefox kln) 24.6.0 bngszt hasznltunk, amit gy lltottunk be, hogy res kezdlappal induljon (teht ne prbljon valamilyen oldalt betlteni vagy a legutbb megltogatott oldalt
helyrelltani). A cache ki volt kapcsolva (0 MB belltsval), de ennek ellenre azt tapasztaltuk,
hogy ntt a ~/.cache/mozilla/firefox knyvtr helyfoglalsa, ezrt minden egyes mrskor
letrltk annak tartalmt kzvetlenl az oldal megnyitsa eltt. (Ksbb megvizsgltuk a cacheels hatst a portszm fogyasztsra, s azt tapasztaltuk, hogy nem cskkenti jelentsen a portszm
fogyasztst [8].)
A Debian nem szabad szoftver troljbl (non-free repository) flash playert teleptettk, hogy a bngsz be tudja tlteni az oldal esetleges flash tartalmt is. A felugr ablakokat (pop-up windows)
blokkolva hagytuk, mert az volt a bngsz alap belltsa. Minden mr belltst is vltozatlanul
hagytunk. A portszmmal kapcsolatos belltsokat ellenriztk az about:config URL megnyitsval:
network.http.max-connections 256
network.http.max-persistent-connections-per-proxy 32
network.http.max-persistent-connections-per-server 6

Kzlk az els a legfontosabb szmunkra, mert ez korltozhatja az egyszerre megnyitott TCP

kapcsolatok szmt, gy a portszm fogyaszts rtkt is.
A netstat Linux parancsot hasznltuk a nyitott TCP kapcsolatok monitorozsra.
Amint mr emltettk, az l TCP kapcsolatok szma rdekelt bennnket, ezrt sajt Linux kernelt fordtottunk (kernel verzi: 3.12.6, gcc verzi: 4.7.2-5), hogy a TCP protocol stack time-out
rtkt cskkenteni tudjuk. Az include/net/tcp.h fjban definilt TCP_TIMEWAIT_LEN paramter rtkt 60 msodpercrl 1 msodpercre lltottuk.
A mrsi intervallum meghatrozshoz hasznlt ksrlethez az 1 milli elem Alexa [52] top site
listt tltttk le, a fjl dtuma 2014. jlius 18. volt. (Az egyes web site-ok slytnyezinek becslsvel kapcsolatos tovbbi paramtereket ksbb adunk meg.) A mrshez hasznlt scriptek s mkdsk lersa megtallhat [8] cikknkben.

A mrsi idintervallum meghatrozsa

A mrsi idintervallum meghatrozshoz az Alexa [52] listban tallhat els 10 URL-t hasznltuk fel. Nhny elzetes ksrlet utn 600 msodpercre lltottuk be ezeknek a mrseknek az
idtartamt. Minden oldalt 11-szer tltttnk le, hogy kellen megbzhat eredmnyeket kapjuk. A
11 mrs eredmnyt az albbiak szerint tlagoltuk:
(1)

Ports(URL, t ) =

1 11
Ports(URL, t, M )
11 M =1

Az eredmnyeket a 42. bra mutatja. Jl lthat, hogy egy perc tlsgosan rvid lenne mrsi
idintervallumnak, de kt perc krnykn a portszm fogyaszts ersen lecskken, s 3 perc utn
(egy kivtellel) elenyszv vlik. Ezrt mrsi idintervallum hosszt 200 msodpercere vlasztottuk.

120

live.com
35

Number of ports

30
25
20
15
10
5
0
0

10

15

20

25
Time (s)

30

Windows/Chrome

35

40

45

50

55

Debian/Chrome

42. bra: Az Alexa lista els 10 elemnek portszm fogyasztsa az id fggvnyben [8]
A slytnyezk meghatrozsa
Mivel a forgalmi arnyt is tartalmaz forrsok kzl egyedl a Quantcast lista [55] aktulis, ezrt
azt vlasztottuk. Jobb becsls hjn az egyes web oldalak ltogatsi szmnak arnyt a ltogatk
szmnak arnyval kzeltettk. A 88 nyilvnos profil oldal adatait hasznltuk. A listt 2014. jlius
22-n tltttk le. A slytnyezk alakulst a 43. brn mutatjuk be. Az oszlopok burkolgrbje
az exponencilis eloszlsra emlkeztet. A slytnyezket az albbiak szerint hatroztuk meg:
Weight(i ) =

(2)

Visitors(i )
88

Visitors( j )
j =1

Ahol a weboldalakat 1-tl 88-ig indexeljk (kihagyva a rejtett profil oldalakat).

A portszm fogyaszts jellemzsre hasznlt mennyisgek

Ami a hagyomnyos NAT eszkzket illeti, azok a web bngszs tlagos portszm fogyasztsra
rzkenyek, ezrt szmukra a 88 nyilvnos profil weboldal portszm fogyasztsnak slyozott szszegt kell megadnunk (ami lnyegben tlagot jelent, mivel a slytnyezk sszege 1):

live.com
35

Number of ports

30
25
20
15
10
5
0
0

10

15

20

25
Time (s)

Windows/Chrome

30

35

40

45

50

55

Debian/Chrome

43. bra: Az USA 100 legnpszerbb weboldalnak ltogatszma a [55] forrsbl 2014. 07. 22n letlttt adatok alapjn [8]
121

88

Ports(t ) = Weight(i ) Ports(i , t )

(3)

i =1

Ahol Ports(i,t) az i-edik weboldal ltalunk mrt portszm fogyasztst jelli az id fggvnyben,
Ports(t) pedig a becslt portszm fogyasztsi profilt (lsd majd lent), amivel egy tetszleges web
bngszs portszm fogyasztsnak tlagos alakulst s idbeli lefutst kzeltjk.
Ami az extended tpus NAT eszkzket illeti, azokra a portok jra felhasznlsa miatt csak a
kiugran magas npszersg S portszm igny szerverek (pontosabban cl IP-cmek) jelenthetnek veszlyt. gy azok szempontjbl a web bngszs portszm felhasznlsa az albbi mennyisggel jellemezhet:
88

(4)

Ports(t ) = MAX(Weight(i )Ports(i, t ))

i=1

Mrsi eredmnyek s diszkusszijuk

A Quantcast lista [55] 88 nyilvnos profil weboldalt 11-szer letltttk, s 200 msodpercen
keresztl mrtk azok portszm fogyasztst. Az egyes weboldalak adott idpontokban mrt porszm fogyasztst (1) szerint tlagoltuk, hogy kellen megbzhat eredmnyeket kapjunk.
A (3) szerint kiszmtott slyozott sszeget a 44. brn mutatjuk be. Amint az vrhat volt, a
grbe kezdetben meredeken emelkedik, s a 2 perc krli esse is hatrozott. Kt kisebb ess figyelhet meg 1 s 3 percnl. Az bra alapjn gy tnik, hogy a NAT szmra tlagosan 50 port
bven elg ami jelentsen kisebb, mint az irodalomban kzlt 500-as maximum rtk , de azt
gondoljuk, hogy tovbbi mrsekre van szksg, mieltt ilyen klszablyt megfogalmaznnk.
A (4) szerint kiszmtott slyozott maximumot pedig a 45. brn mutatjuk be. Az ekvivalens
portszm fogyaszts rtke mindig kisebb, mint 3. Ennek oka, hogy kicsik a slytnyezk (a
(google.com-mal 0.066873-nl kezddnek, s a Quantcast listban a legutols helyen talhat
mozilla.org rtke mr csak 0.004063). Mivel itt slyozott maximumrl van sz, elvileg ezt mg
befolysolhatn egy ksbbi igen kiugr rtk, de ennek valsznsge a slyok cskkense miatt
csekly. A [8] cikkben megfontolst kzlnk mg az esetlegesen azonos IP-cmet hasznl virtulis
web szerverekre (name based virtual hosting) nzve is.

44. bra: Becslt portszm fogyasztsi profil a hagyomnyos tpus NAT eszkzkhz [8]
Hangslyozzuk, hogy az eredmnyeink nagysgrendi becslsek, s szeretnnk ms kutatkat arra btortani, hogy ismteljk meg a mrseinket ms bngszkkel s eltr, lehetleg jobb npszersgi
listkkal. A [8] cikknkben tovbbi megfontolsokat is kzlnk a cache-els, a tesztelsre hasznlt
szerver fizikai elhelyezse s egyb tnyezk befolysol hatsra nzve.

122

45. bra: Becslt portszm fogyasztsi profil a kiterjesztett tpus NAPT eszkzkhz [8]

5.4. NAT64 implementcik stabilitsa s

teljestmnye
A tmval kapcsolatos kutatsi eredmnyeinket kt cikkben kzltk. Az elsben [56] (egy
DNS64 implementci mellett) csak a Linux alatti TAYGA [39] NAT64 implementcival foglalkoztunk. A msodikban [57] a TAYGA mellett az OpenBSD PF [40] ltal megvalstott NAT64
implementcit is megvizsgltuk. Ez utbbi cikknk alapjn mutatjuk be a kt NAT64 implementci stabilitst s teljestmnyt. Vizsglataink elvgzse utn talltunk r a Linux alatti Jool [58]
llapottartart (stateful) NAT64 implementcira, amelynek a teljestkpessgt s stabilitst a ksbbiekben szintn tervezzk megvizsglni.
Elszr rviden ttekintjk a korbbi kutatsok eredmnyeit, majd bemutatjuk az ltalunk kidolgozott tesztelsi mdszert, utna kzljk s rtelmezzk a mrsi eredmnyeinket.

5.4.1. Korbbi tudomnyos eredmnyek

A TAYGA NAT64 implementci teljestmnyt (s implicit mdon a TOTD DNS64 implementcit) hasonltja ssze a NAT44 teljestmnyvel [59]. Az Ecdysis [35] NAT64 implementci
teljestmnyt (amelynek sajt DNS64 implementcija van) hasonltja ssze a szerzk sajt HTTP
ALG (alkalmazsszint tjr) implementcijnak teljestmnyvel [60]. Ugyancsak az Ecdysis
NAT64 implementci teljestmnyt hasonltja ssze a NAT-PT s egy HTTP ALG teljestmnyvel [61]. Ezeknek a cikkeknek kzs jellemzje, hogy egy adott NAT64 implementci s egy
adott DNS64 implementci egyttes teljestmnyvel foglalkoznak. Egyrszt ez termszetes, hiszen mind NAT64 tjrra, mind DNS64 szolgltatsra szksg van ahhoz, hogy a csak IPv6 cmmel rendelkez kliensek kommuniklni tudjanak a csak IPv4 cmmel rendelkez szerverekkel, msrszt viszont ez bizonyos rtelemben egy olyan rukapcsols, amely eltakarhatja egy adott NAT64
vagy DNS64 implementci nll teljestmnyt. Ugyanis br a mkdshez mindkettre szksg
van, egy nagy hlzatban ez ltalban kt fggetlen szolgltats, amelyet kt kln szerver nyjt: a
NAT64-et egy router, a DNS64-et pedig egy DNS szerver. gy a kt szolgltatsra a legjobb implementcikat egymstl fggetlenl lehet, st gy clszer kivlasztani.
A TAYGA NAT64 implementci s a BIND DNS64 implementci teljestmnyt s stabilitst kln-kln teszteltk [56] cikknkben. Br ezek mindegyikt stabilnak s megfelelen gyorsnak

123

talltuk, mivel akkor mindkt clra csak 1-1 implementcit vizsgltunk meg, tovbbi NAT64 s
DNS implementcik teljestkpessgnek s stabilitsnak vizsglatra volt szksg.
A DNS64 s NAT64 tmban val kutatsokrl j sszefoglal tallhat az [62] konferenciacikkben, ahol azt is demonstrltk, hogy a DNS64+NAT64 a gyakorlatban is hasznlhat megolds egy
ISP szmra. Azonban a klnbz DNS64 s NAT64 implementcik nagy terhels alatti stabilitsnak vizsglatval s teljestkpessgk sszehasonltsval nem foglalkoztak.

5.4.2. NAT64 tjrk teljestmnynek s stabilitsnak vizsglata

A mrsi eljrs
A NAT64 tjrk teljestkpessgnek s stabilitsnak vizsglatra hasznlt mdszert lnyegben mr [56] cikknkben kidolgoztuk, s a tovbbiakban is azt hasznltuk. A mdszer alaptlete a
kvetkez:
A mrsekben NAT64 tjrknt viszonylag kis teljestmny szmtgpet hasznlunk,
amelyben egyedl a hlzati krtyk teljestmnye nagy. Ennek az sszelltsnak az a clja,
hogy mr kisszm kliens gp segtsgvel jelents tlterhelst tudjunk elrni.
Minden egyes kliens gp nagyszm kliens viselkedst szimullja gy, hogy klnfle clok fel indt krseket.
A terhels mrtkt a kliens gpek szmval szablyozzuk.
Az sszes kliens krsre egyetlen egy nagy teljestmny szerver vlaszol.
Mivel a konkrt mrsi sszelltsok eltrek voltak, a vizsglat rszleteit [57] alapjn mutatjuk
be. A NAT64 tjrk teljestkpessgnek vizsglatra alkalmazott teszthlzat a 46. brn lthat.
Ennek kzponti eleme a NAT64 tjr (egy Intel Pentium III szmtgp az bra kzps rszn).
Az bra als rszn tallhat, csak IPv6 cmmel rendelkez 8db Dell Precision 490 munkalloms
jtssza a nagyszm kliens szerept gy, hogy az i-edik (i=1..8) kliens gp a 10.i.0.0/16 IPv4 cmtartomnybeli szerverek elrst imitlja. Az IPv4 cmeket begyaz IPv6 cmeket DNS64 szerver
nlkl, manulisan lltotta el a tesztelshez hasznlt bash script gy, hogy a
2001:738:2c01:8001:ffff:ffff::/96 hlzat specifikus prefixhez hozzrta a megfelel IPv4-cm 32
bitjt. A NAT64 tjrban a 10.0.0.0/8 hlzat fel a next hop router cmt 193.225.151.70-re lltottuk, s ezt a cmet az bra fels rszn lthat Dell Precision 490 munkallomsra hztuk fel,
amely minden a 10.0.0.0/8 tartomnybeli IP-cm szerver helyett vlaszolt (ehhez iptables segtsgvel a bejv csomagokat a gp a sajt IP-cmre irnytotta t).
Ami a gpek konfigurcijt illeti, a NAT64 tjr egy 800MHz-es Intel Pentium III processzoros
szmtgp volt 256MB memrival s kt darab 3Com 3c940 Gigabit Ethernet hlzati krtyval.
A Dell Precision 490 munkallomsokban pedig 2 db ktmagos Intel Xeon 5130 2GHz CPU zemelt. (A gpek pontos konfigurcija megtallhat: [57].) Ami az opercis rendszert illeti, minden
gpre Debian Squeeze 6.0.3 GNU/Linux opercis rendszer teleptettk, belertve a NAT64 tjrt is, amikor Linux alatt hasznltuk. Amikor pedig OpenBSD alatt, akkor annak verzija 5.1 volt.
Az egyes gpeken az IP-cmeket a 46. brnak megfelelen lltottuk be, tovbbi rszletek megtallhatk a [57] cikknkben.
A mrseket az albbi script segtsgvel vgeztk, amelyet a kliensek hajtottak vgre:
#!/bin/bash
i=`cat /etc/hostname | grep -o .$`
for b in {0..255}
do
rm -r $b
mkdir $b
for c in {0..63..4}
do

124

ping6 -c11 -i0 -q 2001:738:2c01:8001:ffff:ffff:10.$i.$b.$c \

>> $b/nat64p-10-$i-$b-$c &
ping6 -c11 -i0 -q 2001:738:2c01:8001:ffff:ffff:10.$i.$b.$((c+1)) \
>> $b/nat64p-10-$i-$b-$((c+1)) &
ping6 -c11 -i0 -q 2001:738:2c01:8001:ffff:ffff:10.$i.$b.$((c+2)) \
>> $b/nat64p-10-$i-$b-$((c+2)) &
ping6 -c11 -i0 -q 2001:738:2c01:8001:ffff:ffff:10.$i.$b.$((c+3)) \
>> $b/nat64p-10-$i-$b-$((c+3))
done
done

A script az i sorszmot a gp nevnek utols karakterbl hatrozza meg, majd a 10.i.0.0/16

tartomny mind a 216 darab IP cmvel generl IPv4 cmet begyaz IPv6 cmet s azok mindegyike
fel 11 db ICMP echo request krst kld a ping6 parancs segtsgvel. A parancsok eredmnyt fjlokba naplzza, amelyeket ksbb dolgozunk fel. A minl nagyobb terhels elrse rdekben a 4
CPU magot kihasznlva 4 db ping6 parancsot konkurens mdon adunk ki (kzlk ez els hrom
vgn & jel van).
Az egyes mrseknl a kliensek szmnak megvlasztsval (1, 2, 4 s 8) tudtuk a terhels mrtkt
megfelelen belltani. A hasznlni kvnt kliens gpeken a scriptek egyidej indtst egy KDE
grafikus fellettel rendelkez gprl a Konsole nev grafikus terminl program bemenetek sztosztsa
(Send Input to All Sessions) funkcijval valstottuk meg.

next hop towards

10.0.0.0/8
+
responder in the
NAT64 tests

193.225.151.70/28

Dell Precision 490

193.225.151.75/28
2001:738:2c01:8000::69/64

NAT64
gateway
2001:738:2c01:8001::1/64

Intel PIII 800MHz

3com Baseline Switch

2948-SFP Plus

2001:738:2c01:8001::111/64

...

2001:738:2c01:8001::118/64

client computers
for all the tests
client1

8x Dell Precision 490

client8

46. bra: A NAT64 tjrk teljestkpessgnek vizsglathoz hasznlt teszthlzat [57]

125

Mrtk a ping6 parancsok vlaszidejt, valamint a NAT64 implementcit futtat teszt gpen a
processzor terhelst s a memria fogyasztst. Linux alatt ezeket a kvetkez paranccsal naplztuk:
dstat -t -c -m -l -p --unix --output load.csv

OpenBSD alatt pedig az albbi parancssort hasznltuk:

vmstat -w 1 >load.txt

Eredmnyek
A 14. tblzatban a TAYGA eredmnyeit mutatjuk be. Az els sorban az adott mrsben rsztvev kliensek szma tallhat. A msodik sor a csomagveszts rtkt mutatja. A harmadik a negyedik s az tdik sorban rendre a ping6 parancs vlaszidejnek tlagt, szrst s maximumt
adtuk meg. A hatodik s a hetedik sor a teszt gpen a processzor kihasznltsgnak tlagt s szrst tartalmazza. A nyolcadik sor a msodpercenknt tovbbtott csomagok szmt mutatja. Az
utols sor pedig a teszt gp memriafogyasztst adja meg.
1
2
3
4
5
6
7
8
9

kliensek szma
csomagveszts [%]
tlag
a ping6 parancs
szrs
vlaszideje [ms]
maximum
CPU kihasztlag
szrs
nltsg [%]
forgalom mrtke [csomag/s]
memriafogyaszts [MB]

1
0,01
0,447
0,103
5,202
69,8
3,3
5 721
10,8

2
0,01
0,957
0,158
5,438
84,3
1,7
6 614
11,4

4
8
0,03
0,03
1,986 4,406
0,321 0,474
8,057 13,965
97,8 100,0
2,2
0,1
7 085 6 890
11,9
12,9

14. tblzat: A TAYGA NAT64 implementci teljestmnye [57]

1
2
3
4
5
6
7
8
9

kliensek szma
csomagveszts [%]
tlag
a ping6 parancs
szrs
vlaszideje [ms]
maximum
CPU kihasztlag
nltsg [%]
szrs
forgalom mrtke [csomag/s]
memriafogyaszts [MB]

1
2
4
8
0,02
0,02
0,02
0,02
0,405 0,486 0,606 1,194
0,050 0,073 0,127 0,250
1,770 1,433 3,904 7,055
31,7
50,1
80,1
90,3
5,4
5,0
5,1
4,7
5 909 11 091 18 367 22 886
2,4
3,5
5,5
7,9

15. tblzat: A PF NAT64 implementci teljestmnye [57]

Az eredmnyek elemzse:
Br csomagveszts mr egyetlen kliens esetn is elfordult, ennek mrtke mindig nagyon
alacsony volt (a maximlis rtk 0,03%, ami 10 000-bl 3 elveszett csomagot jelent).
A vlaszid kzel linerisan ntt a terhels fggvnyben: a terhels megduplzsnak
hatsra a vlaszid is kzel duplzdott.
A msodpercenknt kiszolglt csomagok szma addig tudott nni, amg volt szabad CPU
kapacits. Ngy kliensnl a CPU kihasznltsga mr 97,8% volt, s nyolc kliensnl mr
nem tudott a TAYGA tbb csomagot kiszolglni, st az tvitt csomagok szma kis mrtkben mg cskkent is 7 085-tl 6 890-re, ami kisebb, mint 3%-os cskkens.

126

A memriafogyaszts mindig alacsony volt (13MB alatt maradt), s csak nagyon gyengn
ntt a terhels fggvnyben.
A fentieket sszefoglalva megllapthatjuk, hogy a TAYGA jl teljestett, a memriafogyasztsa
alacsony volt, s nagy terhels esetn a vlaszideje a terhels fggvnyben kzelten lienrisan
ntt, azaz, a TAYGA megfelel a graceful degradation [63] alapelvnek (azaz jelents tlterhels esetn
sem omlik ssze, s a teljestmnye nem cskken hirtelen, a terhelshez kpes arnytalan mrtkben).
A 15. tblzatban a PF eredmnyeit mutatjuk be. (A tblzat felptse az elz tblzatval azonos, ezrt nem rszletezzk.)
Az eredmnyek elemzse:
A csomagvesztsi arny nagyon alacsony volt, tehelstl fggetlenl 0,02%.
Amg volt jelents mennyisg szabad CPU kapacits, a vlaszid a tehels fggvnyben
linerisnl kisebb mrtkben ntt. Azutn 4 helyett 8 kliens hasznlata esetn a vlaszid
mr kzel megduplzdott.
A msodpercenknt kiszolglt csomagok szma lnyegesen nni tudott a kliensek szmnak nvelsvel: 1 helyett 2 kliens esetn kzel megduplzdott (5 909 helyett 11 091),
majd az arny cskkent: 4 kliens esetn 18 367 lett, vgl 8 kliensnl 22 886, ami mr a
teltds jeleit mutatja, de mg mindig maradt kzel 10% szabad CPU kapacits.
A memriafogyaszts nagyon alacsony volt, s a kliensek szmnak fggvnyben a
lienrisnl alacsonyabb mrtkben emelkedett.
sszefoglalsknt megllapthatjuk, hogy a PF kivl teljestmnyt nyjtott, s amg tesztelni tudtuk, viselkedse megfelelt a graceful degradation elvnek, de mg 8 kliensnl is maradt szabad CPU
kapacitsa. Memriafogyasztsa is nagyon alacsony volt.

Packets sent
(p/s)
25,000

22,886
18,367

20,000
15,000
10,000
5,000

PF

11,091

TAYGA
5,909
6,614

7,085

6,890

5,721

0
1

8
Number of clients

47. bra: A tovbbtott csomagok msodpercenknti szma a kliensek szmnak fggvnyben [57]
A TAYGA s a PF teljestmnyt a 47. s 48. brn hasonltjuk ssze. Megllaptjuk, hogy mrskelt terhels (1 kliens gp) mellett a vlaszidik s az tvitt csomagok szma nagyon hasonl volt.
Viszont ers tlterhels (8 kliens gp) esetn a PF 22 886 csomagot tudott kezelni msodpercenknt
1,2 ms tlagos vlaszid mellett, mg a TAYGA csak msodpercenknt 6 890 csomag tvitelre volt
kpes 4,4 ms vlaszidvel. Ez igen jelents (3,3-szoros) teljestmnyklnbsg. Ennek okt a kvetkez kt tnyezben ltjuk:
A TAYGA llapotmentes NAT64 megolds, ezrt egy llapottart NAT44 megoldssal
(iptables) egytt kellett hasznlnunk: gy minden csomagot kt kln programnak kellett
kezelnie.

127

Mivel a TAYGA felhasznli cmtrben (user space) mkdik, minden csomagot t kell
msolni elszr a kernel cmterbl ide, aztn pedig vissza.
Vgezetl megllaptjuk, hogy mindkt megolds (a TAYGA s a PF) stabilnak bizonyult s alkalmasnak tartjuk ket NAT64 funkci elltsra. Amennyiben egy rendszerben az IPv6 kliensek
s az IPv4 szerverek kztt nagy forgalom vrhat, akkor a PF hasznlatt javasoljuk.

Response
time (ms)
5
4.5
4
3.5
3

PF

2.5

TAYGA

2
1.5
1
0.5
0
1

8
Number of clients

48. bra: Vlaszid a kliensek szmnak fggvnyben [57]

5.5. DNS64 implementcik stabilitsa s

teljestmnye
A tmval kapcsolatos kutatsi eredmnyeinket kt cikkben kzltk. Az elsben [56] (egy
NAT64 implementci mellett) csak a BIND [64] ltal megvalstott DNS64 implementcival
foglalkoztunk. A msodikban [32] a BIND a mellett a TOTD [65] DNS64 implementci teljestmnyt s stabilitst megvizsgltuk. Azta tovbbi kt implementcival (Unbound s
PowerDNS) is foglalkoztunk, s mind a ngy implementci esetn 1, 2 s 4 magos processzorral
rendelkez tesztgpeken is elvgeztk a vizsglatokat. Ezek eredmnyt nemzetkzi tudomnyos
folyiratcikkben tervezzk publiklni [66]. A fentieken tl tervezzk mg egy j, ksrleti stdiumban lev DNS64 implementci, az MTD64 (Multi-Threaded DNS64) [11] vizsglatt is.
Ami ms kutatk eredmnyeit illeti, lnyegben ugyanazokat sorolhatnnk fel, amit a NAT64 esetben (egy adott NAT64 implementci s egy adott DNS64 implementci egyttes teljestmnynek a vizsglata), de nem szeretnnk nmagunkat ismtelni, ezrt ezzel a krdssel most tbbet
nem foglalkozunk. A tovbbiakban [32] alapjn fogunk haladni.

5.5.1. A megvizsglt DNS64 implementcik

A BIND ami DNS szerverek kzt de facto szabvnynak szmt a 9.8 verzitl tartalmaz
DNS64 tmogatst, ezrt ez kihagyhatatlan volt. Mivel a BIND egy nagy s komplex szoftver sokfle DNS funkcionalitssal (pl. authoritative, recursive, DNSSEC tmogats), a msik vlasztsunk
egy pehelysly DNS64 proxyra, nevezetesen a TOTD-re esett. Mindkt implementcit a kvetkez hrom opercis rendszer alatt teszteltk: Linux, OpenBSD s FreeBSD.

128

5.5.2. A tesztkrnyezet
Az volt a clunk, hogy megvizsgljuk s sszehasonltsuk a kivlaszott implementcik teljestmnyt. Arra is nagy hangslyt fektettnk, hogy jelents tlterhels mellett vizsgljuk a stabilitsukat. (A szoftverek tesztelshez valamilyen hardvert kellett hasznlnunk, de nem hardverek teljestmnynek vizslata volt a clunk.)
A tesztelsre hasznlt hlzat topolgijt a 49. brn mutatjuk be. A teszthlzat kzponti eleme
a DNS64 szerver.

49. bra: A DNS64 teszthlzat [32]

A mrsekhez olyan nvtrre volt szksgnk, amely:
szisztematikusan lerhat
a nevekhez csak IPv4 cmek tartoznak
a nvfelolds helyben azonnal elvgezhet
Erre a clra a 10-{0..10}-{0..255}-{0..255}.zonat.tilb.sze.hu nvteret hasznltuk,
amit a 10.0.0.0 10.10.255.255 IPv4 cmekre kpeztnk le az bra tetejn lthat teacherb nvkiszolglval, ami a 192.168.100.105 IPv4 cmen volt elrhet.
A DNS64 szerver ezekhez az IPv4 cmekhez IPv4 cmet begyaz IPv6 cmeket rendelt a
2001:738:2c01:8001:ffff:ffff:0a00:0000 2001:738:2c01:8001:ffff:ffff:0a0a:ffff tartomnybl.

129

Az bra als rszn lthat, csak IPv6 cmmel rendelkez DELL munkllomsok jtszottk
DNS64 teljestmnymrsekben a nagyszm kliens szerept. A mrsekhez lnyegben ugyanazokat a gpeket hasznltuk, mint a korbban lert, ICMP-vel vgzet NAT64 teljestmnymrsekhez,
azzal a klnbsggel, hogy a DNS64 vizsglatnl csak 128MB RAM volt a Pentim III teszgpben.
Az eszkzk pontos konfigurcija megtallhat [32] cikknkben. Debian Squeeze 6.0.3 opercis
rendszert teleptettnk minden gpre (a Pentium III tesztgpre is, amikor Linux alatt hasznltuk).
Az OpenBSD verzija 5.1, a FreeBSD- pedig 9.0 volt.
Az egyes eszkzk IP cmeit a 49. brnak megfelelen lltottuk be. A rszletes belltsok
(BIND, TOTD konfigurcis llomnya, valamint a BIND znafjlt elllt script is) megtallhatk a [32] cikknkben.

5.5.3. A DNS64 teljestmnymrs mdszere

A cache-els hatsnak kikszblsre az egyes kliensek egymssal t nem lapold nvteret
hasznltak. Az i. kliens a 10.i.0.0/16 hlzatra lekpzett nvtrre vonatkoz krseket kldtt. gy
minden kliens 216 db nvfeloldst vgzett el. A vgrehajtsi id megfelel mrse rdekben minden
kliens 256 ksrletet vgzett, s egy-egy ksrletbe 256 nvfelolds tartozott, amihez a Linux szabvnyos host parancst hasznltuk. A ksrletek vgrehajtsi idejt a GNU time paranccsal mrtk
(ami nem egyezik meg a bash shell time parancsval). A kliensek a kvetkez script segtsgvel
hajtottk vgre a 256 ksrletet:
#!/bin/bash
i=$(cat /etc/hostname|grep -o .$) # ordinal number of the client computer
rm dns64-$i.txt
for b in {0..255}
do
/usr/bin/time -f "%E" -o dns64-$i.txt a ./dns-st-c.sh $i $b
done
A mrsben rszt vev kliens gpeken a scriptek szinkronizlt indtsra a KDE Konsole nev

terminl programjnak a bemenetek sztosztsa (Send Input to All Sessions) funkcijt hasznltuk. A fenti scriptben meghvott dns-st-c.sh nev script (amely kt paramtert vett t) volt a
felels egy 256 nvfeloldsbl ll ksrlet vgrehajtsrt. Ennek tartalma a kvetkez volt:
#!/bin/bash
for c in {0..252..4} # that is 64 iterations
do
host 10-$1-$2-$c.zonat.tilb.sze.hu &
host 10-$1-$2-$((c+1)).zonat.tilb.sze.hu &
host 10-$1-$2-$((c+2)).zonat.tilb.sze.hu &
host 10-$1-$2-$((c+3)).zonat.tilb.sze.hu
done
A for ciklus magjban ngy host parancsot indtott el konkurrens mdon, melybl az els hrom

aszinkron mdon (httrben) futott (gy tudtuk kihasznlni a kt darab ktmagos processzor szmtsi teljestmnyt a minl nagyobb terhels ltrehozsra), s a ciklus magja 64-szer kerlt vgrehajtsra.
A mrssorozatban a mrsben rszt vev kliensek szmt 1-tl 8-ig duplzssal nveltk. A ksrletek vgrehajtsi idejn kvl mrtk a DNS64 szerver programot futtat gpen a memria- s
processzorhasznlatot is. Erre Linux alatt a kvetkez parancsot hasznltuk:
dstat -t -c -m -l -p --unix --output load.csv

BSD rendszerek alatt pedig ezt:

vmstat -w 1 >load.txt

130

5.5.4. A DNS64 mrsek eredmnyei

Mind a kt szoftvert (BIND, TOTD) mind a hrom opercis rendszer (Linux, OpenBSD,
FreeBSD) alatt megvizsgltuk. Radsul a BIND-ot, recursorknt is (amikor a nvfelolds lpseit
iterative queryk segtsgvel maga vgzi el) s forwarderknt is (amikor egy msik szervert kr meg a
nvfelolds lpseinek elvgzsre egy recursive queryvel). gy eredmnyl kilenc tblzatot kaptunk,
amelyekbl itt csak kettt mutatunk be (a tbbi is megtallhat [32] cikknkben): ezek a Linux alatti
mrsi eredmnyek (ahol a legjobb volt az implementcik teljestmnye), ezen bell az sszehasonlthatsg rtekben a BIND-nak a forwarder mdban mrt teljestmnye, mivel a TOTD csak
forwarderknt kpes mkdni.
1
2
3
4
5
6
7
8

kliensek szma
egy ksrlet
tlag
szrs
vgrehajtsi
maximum
ideje [s]
CPU kihasztlag
nltsg [%]
szrs
memriafogyaszts [MB]
krsek szma [krs/s]

1
1,127
0,049
1,650
61,77
4,1
40
227

2
4
1,542 3,183
0,037 0,081
1,680 3,310
95,56 100,00
2,3
0,0
58
57
332
322

8
6,318
0,104
6,470
100,00
0,0
57
324

16. tblzat: A BIND DNS64 implementci teljestmnye, Linux, forwarder [32]

A BIND-nak Linux alatt forwarderknt mrt eredmnyeit a 16. tblzat tartalmazza, melynek
rtelmezse a kvetkez. Az els sorban lthat az adott ksrletben rszt vev kliensek szma. (A
DNS64 szerver terhelse a kliensek szmval ntt.) A msodik, harmadik s negyedik sorok rendre
az egy ksrlet (256 db host parancs) vgrehajtsi idejnek tlagt, szrst s maximumt adjk
meg. Az tdik s hatodik sorban tallhat a processzor kihasznltsgnak tlaga s szrsa. A
hetedik sorban a becslt memriafogysztst adtuk meg. (Ennek az rtknek viszonylag nagy a bizonytalansga, mert nem a DNS64 szerver processz memriahasznlatnak vltozst mrtk, hanem a Linux rendszer szabad memria rtknek a cskkenst, amit ms processzek is befolysolhattak. Azrt tartjuk helyesnek ezt a megoldst, mert ha pusztn a processz memriafogyasztst
vizsgltuk volna, akkor esetleg nem mrtnk volna bele olyan memriafogyasztst, ami nem a
DNS64 szerver processznl jelentkezik, de mgis annak a cljait szolglja, pl. kernel pufferek.) A
nyolcadik sorban egy szmtott rtk tallhat, nevezetesen a msodpercenknt kiszolglt krsek
NR szma:
(5)

NR =

256 * nk
TE

ahol nk a mrsben rszt vev kliensek szma, TE pedig az egy ksrlet (256 db host parancs)
tlagos vgrehajtsi ideje.
A mrsi eredmnyek alapjn megllapthatjuk, hogy:
A terhels nvelse nem okoz jelents teljestmnycskkenst, s a rendszer egyltaln
nem omlik ssze a tlterhels hatsra. Mg amikor a processzor kihasznltsg 100%-os,
a vlaszid akkor is csak kzeltleg linerisan n a terhelsnek (azaz a kliensek szmnak) fggvnyben.
Br nem tudunk pontos becslst adni a DNS64 szerver memriafogyasztsra, de lthat,
hogy az mg nagyon ers tlterhels esetn is mrskelt.

131

A tblzat utols sorban lthat, hogy a msodpercenknti krsek szmnak a maximumt a rendszer kt kliens esetn rte el. A kliensek szmnak tovbbi nvelse csak a
vlaszidt nvelte, de a msodpercenknti krsek szmt nem. Ennek oka, hogy a teszt
program nem tudott addig j krst kldeni, amg a konkurrens mdon indtott ngy
host parancs kzl az utolsra meg nem jtt a vlasz.
A fenti eredmnyek azrt nagyon fontosak, mert azt mutatjk, hogy a BIND DNS64 szerver
viselkedse megfelel a graceful degradation [63] elvnek; azaz amennyiben nincs elegend erforrs a
krsek kiszolglsra, akkor a rendszer vlaszideje csak linerisan n a terhels fggvnyben.
Egy msik fontos megfigyels, hogy a legnagyobb terhels (8 kliens) esetn a vgrehajtsi id
szrsa (0,104s) kisebb, mint 2%-a az tlagnak (6,318s) s maximuma (6,470) is csak 2,5%-kal tbb,
mint az tlag. Ez azt mutatja, hogy a rendszer mg komoly tlterhels esetn is nagyon stabil.
Ezen kt megfigyels alapjn a Linux alatt futtatott, forwarderknt hasznlt BIND egy kivl jellt
zemszeren hasznlhat DNS64 szervernek les kereskedelmi rendszerekben is.

1
2
3
4
5
6
7
8

kliensek szma
egy ksrlet
tlag
vgrehajtsi
szrs
ideje [s]
maximum
CPU kihasztlag
nltsg [%]
szrs
memriafogyaszts [MB]
krsek szma [krs/s]

1
2
4
8
0,791 1,310 2,158 4,348
0,038 3,863 3,754 5,301
1,370 64,950 63,730 68,540
38,00 58,05 80,16 84,79
2,4
27,1
27,5
29,2
1,0
1,1
1,6
0,8
324
391
474
471

17. tblzat: A TOTD DNS64 implementci teljestmnye, Linux, forwarder [32]

A TOTD-nek Linux alatt (forwarderknt, hiszen csak erre kpes) mrt eredmnyeit a 17. tblzat
tartalmazza, melynek rtelmezse a megegyezik a 16. tblzat rtelmezsvel.
A TOTD megmriaignye feltnen alacsony, amit a cache-els hinya okoz. Mivel a tesztelsi
mdszernk szndkosan kikszblte a cache-els hatst, ezrt mrsnkben ez nem okozott
htrnyt a BIND-dal szemben, de egy vals rendszerben a TOTD teljestmnyt a cache-els hinya
lnyegesen ronthatja. (Kicsi, beptett rendszerekben viszont komoly elny lehet az alacsony memriaigny!)
Ami a TOTD teljestmnyt illeti, alacsony terhels (1 kliens) mellett a teljestmnye kivl: msodpercenknt 324 krst szolglt ki 38 % CPU terhels mellett, szemben a BIND-dal, ami msodpercenknt csak 227 krs kiszolglsra volt kpes, radsul 61,77 % CPU terhels mellett. Br az
egy ksrlet vgrehajtsi idejnek maximuma 1,370s, ami lnyegesen nagyobb, mint az tlag (0,791s),
de mg elfogadhat, hiszen ez 64 iterci ideje.
Azonban nagyobb terhels (2-8 kliens) mellett a TOTD eredmnyei elfogadhatatlanok az egy ksrlet maximlis vgrehajtsi idejre kapott 60-80s krli rtkek miatt. Megvizsgltuk a jelensget,
s azt tapasztaltuk, hogy a TOTD idnknt (ritkn, s ltszlag szablytalanul) 1 perc krli ideig
nem vlaszolt, aztn folytatta a mkdst. (A TOTD egybknt mindhrom opercis rendszer
alatt hasonlan viselkedett.) Kzben az authoritatv DNS szerver a teacherb gpen kifogstalanul
mkdtt.
A fentiek miatt a TOTD (jelents terhels mellett biztosan) nem alkalmas zemszer hasznlatra.
Viszont gy tltk meg, hogy a BIND-hoz kpest lnyegesen kisebb szmtsi teljestmny ignye
miatt rdemes a TOTD hibjt megkeresni s kijavtani. (Ezt meg is tettk; a kvetkezkben beszmolunk az eredmnyeinkrl.)

132

Mg annyit emltnk meg, hogy a BIND BSD rendszereken gyengbb tlagos teljestmnyt nyjtott, mint Linux alatt, viszont FreeBSD alatt ezt nagyon stabilan tette, teht ha adott esetben biztonsgi megfontolsok miatt FreeBSD platformra van szksg (pl. jailben val futtats cljbl), s
a teljestmnyldozat elfogadhat, akkor a BIND DNS64 szerver hasznlata FreeBSD alatt j megolds lehet. (Tovbbi rszletek a [32] cikknkben.)

5.6. A TOTD DNS64 implementci stabilitsi s

biztonsgi krdsei
Amint emltettk, a BIND-nl lnyegesen jobb tlagos teljestmnye (alacsonyabb szmtsignye)
alapjn a TOTD szoftvert rdemesnek tartottuk arra, hogy megkeressk s kijavtsuk a hibjt.
Errl a munknkrl [67] cikknken adtunk szmot, ahol vzlatosan lertuk a tesztels lpseit is.
Most csak a hibt s kijavtst mutajuk be.

5.6.1. A programozsi hiba s kijavtsa

A DNS krs s vlasz zenetek egyarnt tartalmaznak egy 16 bites trazakciazonost (Transaction
ID) mezt, amelynek az rtkt a kliens lltja be, s a szerver vltozatlanul beleteszi a vlaszba. A
kliens ennek alapjn tudja azonostani a szerver vlaszt. (A DNS zenetek felptst rszletesen
bemutattuk [11] cikknkben.) Mivel a TOTD proxyknt mkdik, egy krs vtele utn kliensknt
kell viselkednie: egy DNS krst kell kldenie egy olyan DNS szervernek, amely recursive queryket
fogad (a TOTD ezt a szervert forwardernek nevezi). A TOTD-nek ilyenkor tranzakciazonostt
kell generlnia az ltala kldend DNS krshez. Ellenriztk a ne_mesg.c fjlban tallhat
mesg_id() nev fggvnyt, amyely egy id nev statikus vltozt tartalmaz:
uint16_t mesg_id(void) {
static uint16_t id = 0;
if (!id) {
srandom (time (NULL));
id = random ();
}
id++;
if (T.debug > 4)
syslog (LOG_DEBUG,"mesg_id() = %d",id);
return id;
}

A programoz szndka nyilvnvalnak tnik: vlasszuk meg a statikus vltoz kezdrtkt

vletlenszeren, s nveljk az rtkt 1-gyel minden vgrehajtskor. De a fenti C program tnyleges viselkedse egy kicsit ms. Amikor az id nev statikus vltoz rtke 0xffff, s az rtkt
1-gyel megnveljk, akkor az rtke 0 lesz, s a fggvny azt minden tovbbi nlkl visszaadja. De
a fggvny kvetkez vgrehajtsakor nem 1-gyel fogja azt nvelni, hanem ismt vletlenszer rtket vlaszt, ami kicsi (de pozitv) valsznsggel 0xffff-hez kzel lehet (akr 0xffff is lehet). Ez
azt jelenti, hogy egy j DNS krs tranzakciazonostja megegyezhet egy nemrg elkldtt, s mg
vlaszra vr DNS krs tranzakciazonostjval. Ez problmt okozhat, amikor a vlasz alapjn
a TOTD elkeresi a neki megfelel krst. Ksztettnk egy gyors hibajavtst, amelyben ellenrizzk, hogy a nvels utn vajon nem lett-e 0 az id nev statikus vltoz rtke, s ha igen, akkor
azonnal megnveltk azt 1-re. Ezzel elkerltk a kockzatos (ismtelt) vletlenszm-generlst. A
kijavtott kd:
133

uint16_t mesg_id(void) {
static uint16_t id = 0;
if (!id) {
srandom (time (NULL));
id = random ();
}
if ( !++id ) ++id; /* correction for id==0 */
if (T.debug > 4)
syslog (LOG_DEBUG,"mesg_id() = %d",id);
return id;
}

A fenti mdosts utn a TOTD tbb nem produklta a korbbi hibt.

Megjegyzs: TOTD gy mkdik, hogyha nem kap vlaszt a forwarder-knt belltott nvkiszolgltl, akkor a kvetkezvel prblkozik (ha van). A programozsi hibt tartalmaz verzi a
forwarder-knt belltott nvkiszolgl hibjt felttelezve a mkdst ezrt megfelel time-out
letelte utn folytatta (az egyetlen belltott nvkiszolgl hasznlatval).

5.6.2. A biztonsgi rs s annak kijavtsa

A sebezhetsg
Mivel a TOTD szekvencilis tranzakciazonostkat hasznl, amelynek elrejelzse trivilis, ezrt
a TOTD sebezhet a tranzakciazonost elrejelzsen alapul DNS cache mrgezs tmadsra (DNS
cache poisoning with transaction ID prediction attack) nzve. Ez a tmads gy mkdik, hogy a
tmad rveszi az ldozat DNS kiszolglt, hogy egy adott szimbolikus nvre vonatkoz nvfeloldsi krst kldjn ki, melyre a tmad mg az authoritatv nvkiszolgl vlasznak megrkezse
eltt vlaszol (hamis adatokkal). Ha a tranzakciazonost elrejelzse sikeres, akkor az ldozat
DNS kiszolgl elfogadja a tmad hamis vlaszt. (A tmadsrl bvebb lers tallhat az RFC
5452 4. rszben.) A legelterjedtebben hasznlt BIND nvkiszolgl 8.2 eltti verziiban is megvolt
ez a sebezhetsg. A 8.2 verziban vezettk be az lvletlen tranzakci ID-ket, s tovbbi fejlesztsek voltak a 9-es verziban, de elvileg mg az is tmadhat [68] szerint.

Az elvi megolds
gy dntttnk, hogy mi is lvletlen tranzakciazonostkat fogunk hasznlni. Azonban az egyedileg generlt lvletlen tranzakciazonostk hasznlata megkvetelte volna, hogy nyilvntartsuk,
hogy mely tranzakciazonostk vannak mg hasznlatban. Ehhez viszont tbb helyen kellett volna
mdostanunk a TOTD forrst (pldul nyilvntartsba venni a tranzakciazonostt, amikor a
TOTD egy j krst kld, s trlni a nyilvntartsbl a tranzakciazonostt, amikor megjtt a
krsre a vlasz, vagy letelt a time-out). Ezrt inkbb az elre generlt lvletlen permutcik hasznlatt vlasztottuk, hogy a vltozsokat egyetlen forrsfjlon bell tudjuk tartani. Kt tovbbi megfontolst tettnk mg:
Ha az lvletlen permutcik mind a 65536 elemt felhasznlnnk, akkor a tartomny
kimerlshez kzeledve egyre nagyobb valsznsggel elrejelezhetk lennnek a
tranzakciazonostk.
Egy adott permutci nhny utols eleme mg hasznlatban lehet, amikor egy j permutci elemeit kezdjk hasznlni (gy ismt tkzs fordulhatna el).

134

Ezrt a megoldsunkba kt diszjunk tartomnyt (0-0x7fff s 0x8000-0xffff) felvltva hasznlunk,

s a generlt lvletlen permutciknak mindig csak a felt hasznljuk fel. Ez a megolds az eredetihez kpest lnyegesen javja a biztonsgi helyzetet, s csak kis mennyisg programozi munkt
ignyel (konkrtan kt fggvnyt egyetlen forrsfjlon bell). A megolds ra tovbb arnylag kis
mennyisg szmtsi teljestmny elpazarlsa, hiszen az ellltott vletlen permutcik elemeinek felt nem hasznljuk fel.

Az implementci
A vletlen permutcik generlsra a Durstenfeld ltal publiklt algoritmus [69] kifordtott (inside
out) vltozatt hasznltuk. Mg az eredeti vltozat egy tmb elemeibl helyben kszt vletlen permutcit, s gy a tmb elzetes inicializlst ignyli, a kifordtott vltozat mindkt feladatot elvgzi
egyetlen ciklusban. Mindkt vltozat komplexitsa O(N), de a kifordtott vltozat megtakartja az
inicializlst s az elemek felcserlst.
A mdostott mesg_id() fggvny s az ltala hasznlt make_random_permutation() fggvny megjegyzsekkel elltott C forrskdja megtallhat [67] cikknkben (a folyirat open access).

Teljestmnyvizsglat
Az implementci hatkonysgnak ellenrzsre sszehasoltottuk az eredeti TOTD, a programozsi hiba kijavtst tartalmaz TOTD, a biztonsgi rst kikszblst tartalmaz TOTD s a
(forwarderknt hasznlt) BIND DNS64 implementcik teljestmnyt. A mrseket a korbb cikknkben [32] megadotthoz hasonl mdon, de azzal az eltrssel vgeztk, hogy most a host parancs -t AAAA opcijnak hasznlatval csak az AAAA rekordokat krtk le (enlkl az opci
nlkl a host parancs az MX rekordot is lekri), illetve a kliensek szmt 1-tl 10-ig egyesvel
nveltk (azrt, hogy jl brzolhat grafikont kapjunk). Itt most csak az egy ksrlet (256 db host
-t AAAA parancs) vgrehajtsnk tlagos idejt hasonltjuk ssze az 50. brn, de az sszes mrt
Avg. Resp.
Time (ms)

Average Response Time

7
6
5
4
3
2
1
0
1

Original TOTD

Bugfixed TOTD

Improved TOTD

BIND

10

Number of
Clients

50. bra: Egy ksrlet tlagos vgrehajtsi ideje (a kisebb rtk a jobb) [67]
rtk tblzatosan is megtallhat [67] cikknkben. Az brn az eredeti TOTD grafikonjnak hullmzsa teljesen esetleges, hiszen a TOTD vletlenszeren elfordul hibja okozza. (Egy msik
mrsben msknt nzne ki a grafikon.) A programozsi hiba kijavtst tartalmaz TOTD
(bugfixed TOTD) grafikonjt majdnem teljesen eltakarja a biztonsgi rs kikszblst tartalmaz
TOTD (improved TOTD) grafikonja, ami azt jelenti, hogy ezek tlagos teljestmnye kzt nincs

135

lnyegi klnbsg. A BIND teljestmnye lnyegesen elmarad ezeknek a teljestmnytl (10 kliensnl a BIND-dal egy ksrlet tlagos vgrehatsi ideje tbb, mint ktszerese a TOTD javtott verziival mrt tlagos vgrehajtsi idnek).
sszefoglalva megllaptjuk, hogy a biztonsgi rs kijavtst tartalmaz TOTD egy jl hasznlhat, s a tesztelt krlmnek kztt a BIND-nl lnyegesen hatkonyabb megoldsknt olyan
kivl DNS64 implementci, amelynek hasznlatt les krnyezetben is javasoljuk. A TOTD-nek
az ltalunk ksztett javtst is tartalmaz 1.5.3. verzija forrskdban elrhet [70].

5.7. 6to4 implementcik stabilitsa s teljestmnye

Felmerl a krds, hogy egyltaln mirt foglalkozunk 6to4 implementcik teljestmnynek
vizsglatval, amikor a 6to4 technolgia alkalmazsa esetn biztonsgi problmk vannak? Egyrszt
azrt, mert knyelmi s rszben kltsg szempontok miatt (nem kell explicit tunnelt belltani, hasznlni, esetleg venni) mgis hasznljk ket, msrszt pedig azrt, mert a manulisan konfigurlt
tunnel megoldsoknl is nagyon hasonl feladatot kell megvalstani, gy eredmnyeink valsznleg ott is hasznosak lesznek.
A tmval kapcsolatos kutatsi eredmnyeinkrl megjelent els cikknkben [16] megmutattuk,
hogy a 6to4 megoldst illeten a relayek teljestmnye lehet kritikus, hiszen azokon nagyszm felhasznl forgalma haladhat keresztl (radsul ez a szm elre nem tervezhet), mg egy 6to4
routernek csak a mgtte lev IPv6 eszkzk forgalmt kell kiszolglnia. Ebben a cikknkben a
Linux sit, a FreeBSD stf s a NetBSD stf interfszek, mint 6to4 relay implementcik teljestkpessgt s stabilitst vizsgltuk meg. Msodik (jelenleg megjelens alatt ll) cikknkben [71] pedig a Linux sit, OpenWrt sit s FreeBSD stf interfszeket teszteltnk. Mr kszl egy harmadik
cikknk is, amelyben a msodik cikknkben szerepl implementcikkal azonos krlmnyek kztt teszelt (gy velk sszehasonlthat) Linux v4tunnel s NetBSD stf interfszek eredmnyei is
szerepelnek [72]. Mivel ezt mg nem publikltuk, ezrt a msodik cikknk alapjn mutatjuk be a
6to4 implementcik vizsglatval kapcsolatos eredmnyeinket.

5.7.1. Ms kutatk eredmnyei

A 6to4 megolds teljestmnyvel tbb cikk is foglalkozik. Az egyikben [73] egy teszthlzaton
(kt IPv6 sziget IPv4 hlzat fltt sszektve) a 6to4 megolds teljestmny jellemzit (round trip
time s througput) hasonltottk ssze azzal, amikor az adott hlzaton 6to4 nlkl, natv IPv4
illetve IPv6 protokoll hasznlata mellett mrtk meg ugyanazokat a jellemzket. A vizsglatokat a
vgpontok kztt TCP s UDP hasznlatval is elvgeztk. A teszthlzatban Cisco routereket
hasznltak. Egy msik cikkben [74] az elre konfigurlt tunnel s a 6to4 teljestmnyt hasonltottk
ssze egy egyszer teszthlzaton (kt kliens gp kztt kt 6to4 router szmtgppel megvalstva), s mindegyiket ktfle Linux (Fedora 9.10 s Ubuntu 11.0) s ktfle Windows (Server 2003
s 2008) esetn is megvizsgltk mind TCP-vel, mind UDP-vel elvgezve a mrseket. Azonban a
Linux esetn hasznlt interfszek tpust sajnos nem kzltk. Egy harmadik cikkben [75] az elzhz hasonl vizsglatokat vgeztek, de csak Windows alatt (Server 2008 s 2012).
A fenti cikkek kzs jellemzje, hogy szimmetrikus hlzaton, kt darab 6to4 router hasznlatval
mrtek. Sajnos olyan cikket nem talltunk, ahol klnfle, nv szerint megjellt szabad szoftver
6to4 relay implementcik teljestmnyt hasonltottk volna ssze egymssal.

136

5.7.2. A teszt krnyezet

Mrsi sszellts
Az egyes 6to4 implementcik stabilitsnak s teljestmnynek a vizsglathoz hasznlt hlzatot a 51. brn mutatjuk be. Mivel izollt krnyezetben mrtnk, ezrt tetszleges IPv4 s IPv6
cmeket hasznlhattunk. Az sszellts kzponti eleme az bra bal oldaln tallhat 6to4 relay
router (egy Pentium III szmtgp) volt. A terhelst az bra aljn tallhat 10db Dell Precision
490 munkalloms szolgltatta. Ezek a gpek 6to4 hostknt mkdtek: az IPv6 kliensek forgalmt
IPv4 csomagokba gyaztk be. Az ltaluk kldtt csomagokat a 3Com switch a 6to4 relaynek tovbbtotta, ami kibontotta a begyazott IPv6 csomagot s tovbbtotta az bra tetejn tallhat gp
fel. Az sszes cmzett helyett ez a gp vlaszolt; ehhez NAT66 segtsgvel magra irnytotta a
csomagokat. A vlaszokat a 6to4 relay ismt begyazta, majd tovbbtotta a megfelel 6to4 hostnak.
A laptop a mrsek vezrlst ltta el. Az egyes gpeken az IP-cmeket az 51. brnak megfelelen
lltottuk be.

51. bra: A 6to4 relay implementcik vizsglathoz hasznlt teszthlzat [71]

Hardver s szoftver konfigurci
A 6to4 relay router egy 800MHz-es Intel Pentium III szmtgp volt 128MB memrival s kt
darab TP-LINK TG-3269 Gigabit Ethernet hlzati krtyval. A Dell Precision 490 munkallomsokban pedig 2 db ktmagos Intel Xeon 5130 2 GHz CPU zemelt. (A gpek pontos konfigurcija
megtallhat: [71] cikknkben, tovbbi rszletek pedig Horvth Viktor szakdolgozatban [76].) Ami
az opercis rendszert illeti, minden kliens gpen Debian Squeeze 6.0.7 GNU/Linux volt, a vlaszol gpre pedig OpenBSD 5.3 opercis rendszert teleptettk. (Az utbbira a NAT66-hoz volt
137

szksg.) Az egyes 6to4 relay implementcik tesztelshez hasznlt gpre mindig az adott implementcinak megfelel opercis rendszer kerlt.

A tesztelt 6to4 implementcik

A kvetkez 6to4 implementcikat teszteltk, a megadott opercis rendszerek alatt:
Debian 7.1.0_x86 sit
OpenWRT 12.09_x86 sit
FreeBSD 9.1_x86 stf.
A kliens gpeken pedig mindig a Linux sit interfszt hasznltuk a 6to4 host funkci megvalstshoz.

5.7.3. A 6to4 mrsi mdszer

A mrsekhez a terhelst a kilenseken az albbi scripttel lltottuk el:
#!/bin/bash
i=`cat /etc/hostname | grep -o '[0-9]'`
for b in {0..255}
do
rm -rf $b
mkdir $b
for c in {0..252..4}
do
ping6 2001:738:2c01:8000::193.$i.$b.$c -c8 -i0 \
>> $b/6to4-193-$i-$b-$c &
ping6 2001:738:2c01:8000::193.$i.$b.$c -c8 -i0 \
>> $b/6to4-193-$i-$b-$c &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+1)) -c8
>> $b/6to4-193-$i-$b-$((c+1)) &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+1)) -c8
>> $b/6to4-193-$i-$b-$((c+1)) &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+2)) -c8
>> $b/6to4-193-$i-$b-$((c+2)) &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+2)) -c8
>> $b/6to4-193-$i-$b-$((c+2)) &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+3)) -c8
>> $b/6to4-193-$i-$b-$((c+3)) &
ping6 2001:738:2c01:8000::193.$i.$b.$((c+3)) -c8
>> $b/6to4-193-$i-$b-$((c+3))
done
done

-i0 \
-i0 \
-i0 \
-i0 \
-i0 \
-i0 \

Az elzetes mrsek tapasztalatai alapjn a scriptet gy hangoltuk be, hogy mg a leghatkonyabb

6to4 implementci esetn is kzel 100% legyen a 6to4 relay terhelse 10 kliens mellett. A programban az i vltoz tartalmazza az aktulis kliens sorszmt. A kls for ciklus 256-szor fut le (0tl 255-ig), a bels pedig 64-szer (0-tl 252-ig 4-es lpskzzel). A ciklus magja 4 pr, azaz 8 darab
ping6 utastst tarlamaz (br a gpekben csak 4 db CPU mag volt, ez a megolds nagyobb terhelst
biztostott, mintha csak 4 darab ping6 utastst hasznltunk volna). Mindegyik ping6 utasts 8-8
darab ICMPv6 echo request zenetet kldtt, kztk kzel 0 idintervallummal. A ping6 utastsok az els hetet aszinkron mdon indtottuk el, gy a nyolc utasts konkurrens mdon futott, de
a bels ciklus jabb itercija csak a nyolcadik ping6 utasts lefutsa utn indulhatott el. gy minden kliens 256*64*8*8= 1048576 ICMP echo request zenetet kldtt ki, sszesen 256*64*4=
138

65536 klnbz cl IP-cm irnyba. Egy mrssorozatban a mrsben rszt vev kliensek szmt
egyesvel nveltk 1-tl 10-ig. A 6to4 relayen a CPU s memria hasznlatt a vmstat paranccsal
mrtk. Annak rdekben, hogy a vmstat nagy terhels mellett is megfelelen mkdjn, -10-es
nice rtket hasznltunk.

Linux - sit performance

No. of
forwarded
packets/sec

CPU util. (%)

100000

100

90000

90

80000

80

70000

70

60000

60

50000

50

40000

40

30000

30

20000

20

10000

10

0
1

No. of forwarded packets/sec

0
10
No. of clients

CPU util. (%)

52. bra: Linux sit: msodpercenknt tovbbtott csomagok szma s processzorhasznlat [71]

OpenWrt - sit performance

No. of
forwarded
packets/sec

CPU util. (%)

100000

100

90000

90

80000

80

70000

70

60000

60

50000

50

40000

40

30000

30

20000

20

10000

10

0
1

No. of forwarded packets/sec

0
10
No. of clients

CPU util. (%)

53. bra: OpenWrt sit: msodpercenknt tovbbtott csomagok szma s processzorhasznlat [71]
139

FreeBSD - stf performance

No. of
forwarded
packets/sec

CPU util. (%)

100000

100

90000

90

80000

80

70000

70

60000

60

50000

50

40000

40

30000

30

20000

20

10000

10

0
1

No. of forwarded packets/sec

0
10
No. of clients

CPU util. (%)

54. bra: FreeBSD stf: msodpercenknt tovbbtott csomagok szma s processzorhasznlat [71]

5.7.4. A 6to4 mrsek eredmnyei

A mrsi eredmnyek tblzatos formban megtallhatk [71] cikknkben. A tblzatokban
ugyanazok a mrt jellemzk szerepelnek, mint amiket a NAT64 implementcik teljestmnynek
ICMP-vel val vizsglatakor lttunk, viszont itt implementcinknt 10 mrssorozatot vgeztnk,
ezrt a tblzatok nem frnnek el jelen knyv lapszlessgben. gy az egyes implementcik teljestmnyt brk segtsgvel mutatjuk be. Minden implementci kln brn szerepel, s a msodpercenknt tovbbtott csomagszm mellett feltntetjk a processzorigny rtkt is.
A Linux sit interfsz teljestmnyt az 52. brn lthatjuk. A msodpercenknt tvitt csomagok
szma kezdetben mg majdnem duplzdik (1 kliensnl 18051 csomag/s, 2 kliensnl 33953 csomag/s), de aztn a grbe egyre inkbb teltdst mutat, a vgn kis mrtkben cskken is (9 kliensnl 73129 csomag/s, 10 kliensnl 73050 csomag/s). A processzorigny kezdetben nagyon alacsony,
de aztn a linrisnl lnyegesen ersebben nvekszik (1-5 kliensig rendre: 1,8%, 4,8%, 12,9%,
31,2% s 53%). t kliensnl a grbnek inflexis pontja van, s feltehetleg a CPU kapacits
korltozott volta miatt a grbe meredeksge cskken.
Az OpenWrt sit interfsz teljestmnyt az 53. brn lthatjuk. Egy kliens mellett ennek a teljestmny nagyon kzel van a Linux sit teljestmnyhez (17595 csomag/s), de aztn fokozatosan lemarad tle, s a 60000 csomag/s rtket sohasem ri el (a maximum rtke 59332 csomag/s 9 kliens
mellett). A processzorigny lnyegesen magasabb rtkrl indul (1 kliens: 10,1%), a kliensszmmal
arnyosnl lnyegesen ersebben n (2 kliens: 45%), aztn hamarosan teltdik, s aszimptotikus
jelleggel kzelti a 100%-ot.
A FreeBSD stf interfsz teljestmnyt a 54. brn lthatjuk. Egy kliens mellett ennek a teljestmnye gyakorlatilag megegyezik az OpenWrt teljestmnyvel (17594 csomag/s), de aztn fokozatosan lemarad tle s a 44000 csomag/s rtket sohasem ri el (a maximum rtke 43970 csomag/s

140

9 kliens mellett, de a 6-10 kliens tartomnyban lnyegben fluktul). A processzorigny mg magasabb rtkrl indul (1 kliens: 51,5%), s kezdettl fogva a teltdsi tartomnyban van (2-4 kliensnl
rendre: 77,1%, 89%, 96,4%).
sszefoglalsknt megllaptjuk, hogy mindhrom implementci stabilan viselkedett, de a teljestmnykben lnyeges klnbsg mutatkozott. Alacsony tehels (1 kliens) esetn a msodpercenknt tvitt csomagok szmban nem volt lnyeges klnbsg, de a processzorignyben mr nagyon
jelents volt az eltrs (Linux sit: 1,8%, OpenWrt sit: 10,1%, FreeBSD stf 51,5%). Nagyobb terhelsnl mr megmutatkozott a klnbsg az egyes implementcik teljestkpessge kztt, cscsteljestmnyk 9 kliens mellet: Linux sit: 73129 csomag/s, OpenWrt sit: 59332 csomag/s, FreeBSD
stf 43970 csomag/s. Br az eltrs jelents, a teljestmnyek arnya messze nem tkrzi azt az
arnyt, amit az 1 kliensnl tapasztalt processzorignyek arnya alapjn vrtunk volna. A jelensg
oknak vizsglata rdekes feladat, de meghaladja mrseink cljt. A kpet mg tovbb rnyalja az
egyes implementcik csomagveszsi arnya. Ebben jellemzben ugyanis a FreeBSD stf volt legjobb, csomagvesztse mindvgig 0,02% alatt maradt, mg 10 kliensnl az OpenWrt sit csomagvesztse 0,089%, a Linux sit csomagvesztse pedig a 0,061% volt.
A hrom vizsglt 6to4 implementci kzl a legjobb tviteli teljestmnyt a Linux sit rte el, de
szksg esetn brmelyik implementci hasznlhat, mert mindegyik stabilan viselkedett.

5.8. Az MPT knyvtr teljestkpessge

Az MPT hlzati szint tbbutas kommunikcis knyvtr teljestkpessgt az t aggregci
hatkonysga szempontjbl vizsgltuk [77]. Mivel az IPv6 ttrsi technolgik kztt az MPT
elssorban, mint rugalamas alagtkpzsi protokoll rdekes (brmelyik IP verzi fltt brmelyik
IP verzi tvihet vele), ezrt ezeket az eredmnyeinket csak rintlegesen mutatjuk be.
A mrsek sorn mind a ngy lehetsges esetet megvizsgltuk: IPv4 alagt IPv4 fltt, IPv6 alagt
IPv4 fltt, IPv4 alagt IPv6 fltt s IPv6 alagt IPv6 fltt. A mrsi sszelltst az 55. brn
mutatjuk be, amely az els esetet brzolja (IPv4 alagt IPv4 fltt). Rszletek a [77] cikknkben.

55. bra: Az MPT teszhlzat (IPv4 alagt IPv4 fltt) [77]

Szmos esetet megvizsgltunk, a mrseket UDP s TCP protokoll fltt egyarnt elvgeztk, az
MPT knyvtrnak a 32-bites s a 64-bites verzijt is teszteltk. Most csak a 32-bites verzi UDP
fltti vizsglatnak eredmnyeit mutatjuk be. Ezekhez a mrsekhez az iperf hlzati tesztprogramot hasznltuk. Eredmnyeink az 56. brn lthatk. Rgtn feltnik, hogy a fels (alagtknt
hasznlt) protokoll verzijtl fggetlenl, az als protokoll verzijnak van dnt hatssal a csa-

141

tornakapacits sszegzsnek a hatkonysgra. Amikor az als protokoll IPv4 volt, a csatornakapacits lnyegben linerisan ntt. Amikor pedig IPv6 volt, akkor 7 hlzati interfsz volt a lineris
nvekeds hatra, utna az tviteli kapacits nem ntt tovbb. Azt is megmutattuk, hogy ez a hatr
nem az MPT valamilyen bels tulajdonsga, hanem a szmtgpek erforrsbl kvetkezik (a
processzorok cserjvel a hatrt sikerlt megemelni).

56. bra: Az MPT csatornakapacits sszegzsnek hatkonysga (32-bit, iperf) [77]

Terveink kztt szerepel, hogy orszgos mret hlzaton (Gyr-Budapest-Debrecen viszonylatban) sszehasonltjuk az MPT-vel ltrehozott klnfle alagutak teljestmnyt egymssal s a
natv IPv4 illetve natv IPv6 hlzatok teljestmnyvel.

142

6. Irodalomjegyzk
[1] Lencse Gbor: Szmtgp-hlzatok, 2. kiads, Universitas-Gyr Nonprofit Kft., Gyr,
2008. ISBN: 978-963-9819-15-3
[2] J. F. Kurose, K. W. Ross: Szmtgp-hlzatok mkdse - Alkalmazsorientlt megkzelts, Panem Kiad, Budapest, 2008. ISBN: 978-9-635454-98-3
[3] A. S. Tanenbaum, D. J. Wetherall: Szmtgp-hlzatok, 3. kiads, Panem Kiad, Budapest,
2012. ISBN: 978-963-545-529-4
[4] Cisco Systems, Configuring BGP on Cisco Routers, Student Guide, vol. 1, version 3.2, 2005.
[5] G. Lencse and I. Derka, Investigation of the fault tolerance of the PIM-SM IP multicast
routing protocol for IPTV purposes, Infocommunications Journal, vol. 5, no. 1. (March, 2013)
pp. 21-28.
[6] B. Almsi, A. Harman, An overview of the multipath communication technologies, in Proc.
Conference on Advances in Wireless Sensor Networks 2013 (AWSN 2013), Debrecen University
Press, Debrecen, Hungary, 2013. ISBN: 978-963-318-356-4, pages 7-11.
[7] S. Ferdous, F. Chowdhury and J. C. Acharjee, An extended algorithm to enhance the performance of the current NAPT, in Proc. International Conference on Information and Communication
Technology 2007 (ICICT07), Dhaka, Bangladesh, March 7-9, 2007, pp. 315-318, DOI:
10.1109/ICICT.2007.37540
[8] G. Lencse, Estimation of the port number consumption of web browsing, IEICE Transactions on Communications, vol. E98-B, no. 8. (August, 2015) pp. 1580-1588. DOI:
10.1587/transcom.E98.B.1580
[9] M. Boye, Netfilter connection tracking and NAT implementation, in Proceedings of Seminar on
Network Protocols in Operating Systems, Department of Communications and Networking, Aalto
University, 2013, pp. 34-39. http://urn.fi/URN:ISBN:978-952-60-4997-7
[10] S. Rps, P. Farnadi and G. Lencse, Performance and stability analysis of free NAT64 implementations with different protocols, Acta Technica Jaurinensis, vol. 7, no 4, (October,
2014), pp. 404-427. DOI: 10.14513/actatechjaur.v7.n4.340
[11] G. Lencse and A. G. Sos, Design of a tiny multi-threaded DNS64 server, in Proc. 8th International Conference on Telecommunications and Signal Processing (TSP 2015), Prague, Czech Republic,
July 9-11, 2015, Brno University of Technology, pp. 27-32.
[12] D. Liu, H. Deng, NAT46 considerations draft-liu-behave-nat46-02, [Online]. Available:
https://tools.ietf.org/html/draft-liu-behave-nat46-02
[13] A. Yourchenko, OpenWRT feed with stateless NAT46 kernel module, [Online]. Available:
https://github.com/ayourtch/nat46
[14] Bob Weeink, Cisco ASA NAT46 (IPv4-to-IPv6), [Online]. Available: https://supportforums.cisco.com/discussion/11809096/cisco-asa-nat46-ipv4-ipv6
[15] Brocade, Brocade ServerIron ADX NAT64 Configuration Guide: Supporting Brocade ServerIron ADX
version 12.5.02, Part Number: 53-1003448-01 [Online]. Available: http://www.brocade.com/downloads/documents/html_product_manuals/SI_12502_NAT64/
[16] G. Lencse and S. Rps, Performance analysis and comparison of 6to4 relay implementations, International Journal of Advanced Computer Science and Applications, vol. 4, no. 9. (September, 2013), pp. 13-21. DOI: 10.14569/IJACSA.2013.040903
[17] B. Almsi, Sz. Szilgyi, "Throughput performance analysis of the multipath communication
library MPT", in Proc. 36th International Conference on Telecommunications and Signal Processing (TSP
2013), Rome, Italy, July 2-4, 2013, pp. 86-90. DOI: 10.1109/TSP.2013.6613897

143

[18] B. Almsi, Sz. Szilgyi, Multipath FTP and stream transmission analysis using the MPT software environment, International Journal of Advanced Research in Computer and Communication Engineering, Vol. 2, No. 11, (November 2013) pp. 4267-4272.
[19] B. Almsi, A simple solution for wireless network layer roaming problems, Carpathian Journal of Electronic and Computer Engineering, vol. 5, no. 1, (2012) pp. 5-8.
[20] B. Almsi, A solution for changing the communication interfaces between WiFi and 3G
without packet loss, In Proc. 37th International Conference on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, July 1-3, 2014, pp. 73-77.
[21] E. Crabbe, L. Yong, X. Xu, T. Herbert, GRE-in-UDP encapsulation, IETF Draft, [Online]. Available: https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap
[22] B. Almsi, G. Lencse, Investigating the multipath extension of the GRE in UDP
technology, unpublished
[23] L. Bokor, G. Jeney, IPv4 / IPv6 coexistence and transition: concepts, mechanisms and
trends In: Katalin Tarnay, Gusztv Adamis, Tibor Dulai (Ed.), Advanced Communication Protocol Technologies: Solutions, Methods, and Applications, Hershey: IGI Global, Information Science
Reference, 2011. pp. 156-177.
[24] L. Bokor, Z. Kanizsai, G. Jeney, IMS-centric evaluation of IPv4/IPv6 transition methods in
3G UMTS systems, International Journal on Advances in Networks and Services, vol. 3 no 3 & 4,
(2010) pp. 402-416.
[25] L. Bokor, V. Simon, I. Duds, S. Imre, Anycast subnet optimization for efficient IPv6 mobility management, In: Proc. First International Global Information Infrastructure Symposium (IEEE
GIIS 2007), (Marrakech, Morocco, July 2-6, 2007), IEEE Press, New York, pp. 187-190
DOI: 10.1109/GIIS.2007.4404188
[26] M. Nikkhah, R. Guerin, Migrating the internet to IPv6: An exploration of the when and
why, to appear in IEEE/ACM Transaction on Networking, [Online]. Available:
http://www.seas.upenn.edu/~mnikkhah/Migrating-the-Internet-02252015.pdf
[27] N. Skoberne, O. Maennel, I. Phillips, R. Bush, J. Zorz, M. Ciglaric, IPv4 address sharing
mechanism classification and tradeoff analysis, IEEE/ACM Transactions on Networking, vol.
22, no. 2, pp. 391-404. DOI: 10.1109/TNET.2013.2256147
[28] Free Software Foundation, The free software definition, [Online]. Available:
http://www.gnu.org/philosophy/free-sw.en.html
[29] Open Source Initiative, The open source definition, [Online]. Available: http://opensource.org/docs/osd
[30] Cisco, End user license agreement, [Online]. Available:
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html
[31] Juniper Networks, End user license agreement, [Online]. Available: http://www.juniper.net/support/eula.html
[32] G. Lencse and S. Rps, Performance analysis and comparison of different DNS64 implementations for Linux, OpenBSD and FreeBSD, in Proc. IEEE 27th International Conference on
Advanced Information Networking and Applications (AINA 2013), Barcelona, Spain, March 25-28,
2013, pp. 877-884. DOI: 10.1109/AINA.2013.80
[33] S. Rps, T. Hajas and G. Lencse, Application compatibility of the NAT64 IPv6 transition
technology, in Proc. 37th International Conference on Telecommunications and Signal Processing (TSP
2014), Berlin, Germany, July 1-3, 2014, Brno University of Technology, pp. 49-55.
[34] N. koberne and M. Ciglari, Practical evaluation of stateful NAT64/DNS64 translation
Advances in Electrical and Computer Engineering, vol. 11, no. 3, (August 2011), pp. 49-54. DOI:
10.4316/AECE.2011.03008
[35] S. Perreault, J.-P. Dionne, and M. Blanchet, Ecdysis: open-source DNS64 and NAT64,
AsiaBSDCon, 2010, http://viagenie.ca/publications/2010-03-13-asiabsdcon-nat64.pdf
144

[36] V. Bajpai, N. Melnikov, A. Sehgal and J. Schnwlder, Flow-based identification of failures

caused by IPv6 transition mechanisms in Dependable Network Services: Proc. 6th IFIP WG 6.6
International Conference on Autonomous Infrastructure, Management, and Security (AIMS 2012), Luxembourg, Luxembourg, June 4-8, 2012, Springer LNCS, vol. 7279. pp. 139-150. DOI:
10.1007/978-3-642-30633-4_19
[37] X. Deng, L. Wang, T. Zheng, D. Gu, E. Burgey, Analysis on IPv6 transition solutions and
service tests, in Proc. ICNS 2011: The Seventh International Conference on Networking and Services,
Venice/Mestre, Italy, May 22-27, 2011, IARIA, pp. 85-91.
[38] J. Beall, Scholarly open access: Critical analysis of scholarly open-access publishing,
[Online]. Available: http://scholarlyoa.com/publishers
[39] TAYGA: Simple, no-fuss NAT64 for Linux [Online]. Available:
http://www.litech.org/tayga/
[40] P. N. M. Hansteen, The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall, 2nd ed., San
Francisco: No Starch Press, 2010. ISBN: 978-1593272746
[41] Simon Perreault, [Ecdysis-discuss] NAT64 in OpenBSD, [Online]. Available:
http://www.viagenie.ca/pipermail/ecdysis-discuss/2011-October/000173.html
[42] Hajas Tams, NAT64 implementcik alkalmazsokkal val kompatibilitsnak vizsglata, szakdolgozat, Szchenyi Istvn Egyetem, MTK, Tvkzlsi Tanszk, 2013.
[43] S. Miyakawa, IPv4 to IPv6 transformation schemes, IEICE Trans. Commun., Vol. E93-B,
No. 5, May 2010, pp. 1078-1084. DOI: 10.1587/transcom.E93.B.1078
[44] F. Fourcot, B. Grelot, Migrating to IPv6 with Address+Port translation, SLR Project Report, Telecom Bretagne, March 2010, [Online]. Available: https://svn.fperrin.net/v6fication/documentation/rapport-Fourcot-Grelot.pdf
[45] I. Kraemer, F. Perrin, Impact of the lack of ports in a DS-Lite architecture, Project Report,
Telecom Bretagne, March 18, 2011, [Online]. Available: https://svn.fperrin.net/v6fication/article/simulation.pdf
[46] G. Chen, W. Li, T. Tsou, J. Huang, T. Taylor, Analysis of NAT64 port allocation methods
for shared IPv4 addresses: draft-chen-sunset4-cgn-port-allocation-05, [Online]. Available:
https://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-05
[47] S. Rps, T. Hajas and G. Lencse, Port number consumption of the NAT64 IPv6 transition
technology, in Proc. 37th International Conference on Telecommunications and Signal Processing (TSP
2014), Berlin, Germany, July 1-3, 2014, Brno University of Technology, pp. 66-72.
[48] Garai Gbor, IPv6 bevezetsnek tmogatsa a Telenor hlzatban, szakdolgozat, Szchenyi Istvn
Egyetem, MTK, Tvkzlsi Tanszk, 2013.
[49] P. E. Romn, J. D. Velsquez, V. Palade, L. C. Jain, New trends in web user behaviour analysis in Advanced Techniques in Web Intelligence-2: Web User Browsing Behaviour and Preference Analysis, Springer Berlin Heidelberg, 2013, pp. 1-10. DOI:10.1007/978-3-642-33326-2_1
[50] C. Liu, R. W. White, S. Dumais, Understanding web browsing behaviors through Weibull
analysis of dwell time, in Proc. 33rd international ACM SIGIR conference on Research and development in information retrieval, Geneva, Switzerland, July 19-23, 2010, ACM New York, NY, USA,
2010, pp. 379-386, DOI: 10.1145/1835449.1835513
[51] L. D. Catledgea, J. E. Pitkowb, Characterizing browsing strategies in the world-wide web,
Computer Networks and ISDN Systems, vol. 27, no. 6, (April, 1995) pp. 1065-1073, DOI:
10.1016/0169-7552(95)00043-7
[52] Alexa, The top 500 sites on the web, [Online]. Available: http://www.alexa.com/topsites
[53] Statistic Brain, Top websites by traffic, 2014, [Online]. Available: http://www.statisticbrain.com/top-us-websites-by-traffic/
[54] BBC News, SuperPower: visualising the Internet, [Online]. Available:
http://news.bbc.co.uk/2/hi/technology/8562801.stm
145

[55] Quantcast, Top sites, Quantcast Corporation, [Online]. Available:

https://www.quantcast.com/top-sites
[56] G. Lencse and G. Takcs, Performance analysis of DNS64 and NAT64 solutions, Infocommunications Journal, vol. 4, no 2, (June, 2012), pp. 29-36.
[57] G. Lencse and S. Rps, Performance analysis and comparison of the TAYGA and of the
PF NAT64 implementations, in Proc. 36th International Conference on Telecommunications and Signal Processing (TSP 2013), Rome, Italy, July 2-4, 2013, Brno University of Technology, pp. 7176. DOI: 10.1109/TSP.2013.6613894
[58] NIC Mexico, Jool NAT64 implementation, [Online]. Available: https://www.jool.mx/
[59] K. J. O. Llanto and W. E. S. Yu, Performance of NAT64 versus NAT44 in the context of
IPv6 migration, in Proc. International MultiConference of Engineers and Compuer Scientists 2012
(IMECS 2012), Hong Kong, March 14-16, 2012, vol. I, pp. 638-645.
[60] C. P. Monte et al, Implementation and evaluation of protocols translating methods for IPv4
to IPv6 transition, Journal of Computer Science & Technology, ISSN: 1666-6038, vol. 12, no. 2,
(August, 2012). pp. 64-70.
[61] S. Yu, B. E. Carpenter, Measuring IPv4 IPv6 translation techniques, Technical Report
2012-001, Department of Computer Science, The University of Auckland, January 2012.
[62] E. Hodzic, S. Mrdovic, IPv4/IPv6 transition using DNS64/NAT64: Deployment issues, in
Proc. 2012 IX International Symposium on Telecommunications (BIHTEL), Sarajevo, Bosnia and
Herzegovina, Oct. 25-27, 2012, DOI: 10.1109/BIHTEL.2012.6412066
[63] NTIA ITS, Definition of graceful degradation [Online]. Available:
http://www.its.bldrdoc.gov/fs-1037/dir-017/_2479.htm
[64] Internet Systems Consortium, Berkeley Internet Name Daemon (BIND), [Online]. Available: https://www.isc.org/software/bind
[65] Martin Dunmore (Ed.), An IPv6 Deployment Guide, The 6NET Consortium, September, 2005.
[Online]. Available: http://www.6net.org/book/deployment-guide.pdf
[66] G. Lencse, S. Rps, Performance analysis and comparison of four DNS64 implementations
under different free operating systems, unpublished
[67] G. Lencse and S. Rps, Improving the performance and security of the TOTD DNS64
implementation, Journal of Computer Science & Technology, ISSN: 1666-6038, vol. 14, no. 1,
(April, 2014) pp. 9-15.
[68] A. Klein, BIND8 DNS cache poisoning And a theoretic DNS cache poisoning attack
against the latest BIND 9, Trusteer, July-August 2007, [Online]. Available:
http://packetstorm.wowhacker.com/papers/attack/BIND_8_DNS_Cache_Poisoning.pdf
[69] R. Durstenfeld, Algorithm 235: Random permutation, Communications of the ACM, vol. 7,
no. 7, (July, 1964) p. 420. DOI: 10.1145/364520.364540
[70] TOTD source code at GitHub, [Online]. Available: https://github.com/fwdillema/totd.git
[71] S. Rps, V. Horvth and G. Lencse, Stability analysis and performance comparison of three
6to4 relay implementations, in Proc. 38th International Conference on Telecommunications and Signal
Processing (TSP 2015), Prague, Czech Republic, July 9-11, 2015, Brno University of
Technology, pp. 82-87.
[72] S. Rps, V. Horvth and G. Lencse, Stability analysis and performance comparison of five
6to4 relay implementations, unpublished
[73] N. Bahaman, E. Hamid, A. S. Prabuwono, Network performance evaluation of 6to4
tunneling in Proc. 2012 International Conference on Innovation Management and Technology Research
(ICIMTR), Malacca, Malaysia, May 21-22, 2012, pp. 263-268. DOI:
10.1109/ICIMTR.2012.6236400
[74] S. Narayan, S. Tauch, IPv4-v6 transition mechanisms network performance evaluation on
operating systems, in Proc. 3rd IEEE International Conference on Computer Science and Information
146

Technology (ICCSIT 2010), Chengdu, China, Jul 9-11, 2010, pp. 664-668, DOI:
10.1109/ICCSIT.2010.5564141
[75] D. Hadiya, R. Save, G. Geetu, Network performance evaluation of 6to4 and configured tunnel transition mechanisms: An empirical test-bed analysis, in Proc. 6th International Conference
on Emerging Trends in Engineering and Technology (ICETET 2013), Nagpur, India, December 1618, 2013, IEEE Computer Society, pp. 56-60. DOI: 10.1109/ICETET.2013.14
[76] Horvth Viktor, 6to4 relay implementcik teljestkpessgnek s stabilitsnak vizsglata, szakdolgozat, Szchenyi Istvn Egyetem, MTK, Tvkzlsi Tanszk, 2013.
[77] G. Lencse and . Kovcs, Advanced measurements of the aggregation capability of the
MPT multipath communication library, International Journal of Advances in Telecommunications,
Electrotechnics, Signals and Systems, vol. 4, no. 2. (2015), pp 41-48. DOI: 10.11601/ijates.v4i2.112

147