View
220
Download
0
Category
Preview:
Citation preview
Operációs rendszerek és hálózatok GEIAL501M
A gyakorlatban elterjedt hálózati architektúrák - IPv4, IPv6
2013/2014. tanév, I . félév
Dr. Kovács Szilveszter © E. III. / 1.
2013/2014. tanév, I . félév
Dr. Kovács Szilveszter
E-mail: szkovacs@iit.uni-miskolc.hu
Informatikai Intézet 106. sz. szoba
Tel: (46) 565-111 / 21-06
A hálózati architektúra
• Rétegek és protokollok halmaza
• Elegendő információ az implementációhoz
• Nem része sem a részletes implementáció, sem az interfészek specifikációja (ezek a konkrét implementáció során tervezői döntések).
Dr. Kovács Szilveszter © E. III. / 2.
(ezek a konkrét implementáció során tervezői döntések).
Mai főbb témák
• Protcol stack-ek, más névenprotokoll hierarchiák, illetve protokollszövetek. Pl:– TCP/IP: Internet – világháló! (Ez és csak ez!)– IPX/SPX: Novell NetWare.– NetBEUI/NetBIOS: Microsoft
Dr. Kovács Szilveszter © E. III. / 3.
– NetBEUI/NetBIOS: Microsoft(NetBEUI: NetBIOS Extended User Interface – nem routeolható (nincs hálócím) – csak kis LAN-ok (MS))
– BanyanVines, DecNet stb.
• Bővebben:– Internet (TCP/IP) - IPv4, IPv6
LAN
Novell Netware: IPX/SPX protocol stack
• Eredetileg csak erőforrás megosztás, mint– File-rendszer és– nyomtató.
• A hálózat – szerver(ek)ből és
Dr. Kovács Szilveszter © E. III. / 4.
• dedikált vagy nem dedikált (az ő erőforrásait osztják meg)
– munkaállomásokból áll.
• De! Kommunikációs szempontból egyenrangúak (egyformák)
• A „Network Operation System”, vagy„hálózati operációs rendszer” – Novell elnevezés
Novell Netware: IPX/SPX protocol stack• Az IPX/SPX az XNS-en alapszik (Xerox Network System)
NetBIOS
Network Loadable Modules (NLM)
DOSFelhasználói programokNetware Core
Protocol (NCP)
Virtuális áramkörDatagram⇐
Dr. Kovács Szilveszter © E. III. / 5.
Koax, Twisted pair, Fibre, stb.
Ethernet, Token Ring, ArcNet stb.
Internet Packet Exchange (IPX)
Sequenced Packet Exchange (SPX)
Fizikai réteg
Adatkapcsolati réteg
Hálózati réteg
Szállítási réteg
⇐Eddig a szintig mind amunkaállomás, mind aszerver egyforma -Mind datagram, -Mind virtuális ák. szolgáltatást tud nyújtani
IPX keretformátum• IPX enkapszuláció (encapsulation)az adatkapcsolati rétegben• Ethernet keretformátum (Ethernet_II ) esetén:
Cél MAC cím Forrás MAC cím Típus: 8137h Ethernet adat CRC
Byte: 6 6 2 4
IPX keret• 802.3 keretformátum (802.2 LLC + SNAP) esetén:
Cél MAC cím Forrás MAC cím Length Data CRC
Byte: 6 6 2 4
Dr. Kovács Szilveszter © E. III. / 6.
DSAP= AA
SSAP= AA
Control= 03
Organization= 00 00 00
Type= 8137h
IPXKeret
802.2 LLC Header(ugyanaz mint az IP-nél)
802.2 LLC SNAP Header(Subnetwork Acces Protocol)
Ez teszi lehetővé az Ethernet tipus(8137) jelölését a 802.3 keretben!
IPXheader
IPXdata
• SNAP nélkül:DSAP= E0
SSAP= E0
Control= 03
IPXKeret
802.2 LLC Header Nincs SNAP ⇒ E0 E0 jelzi az IPX kerettípust
IPX keretformátum
• IPX enkapszuláció (encapsulation)az adatkapcsolati rétegben• 802.3 keretformátum (802.2 LLC nélkül) esetén:
Cél MAC cím Forrás MAC cím Length IPX keret CRC
Byte: 6 6 2 4
IPX header IPX data
Dr. Kovács Szilveszter © E. III. / 7.
IPX header IPX data
• Hátrány: Nincs jelölve a tipusa!⇒ Csak akkor lehet így, ha csak IPX van a hálózaton.
IPX keretformátumIPX keret:
Checksum0 15
Length
Destination Network
Destination Host
Destination Socket
TransportControl
PacketType
IPXheader30 byte
IPX címformátum Pl:&00000025 %080002001216 !5
Network Number Host Number Socket Number
Network Number: 32 bit (4byte)- Egyedi hálózat azonosító (route-olható).- Nem támogatja a hierarchikus címzést
(tipikusan LAN)Host Number: 48bit (6byte)– MAC cím
Ha 0:helyben
Dr. Kovács Szilveszter © E. III. / 8.
Destination Socket
Source Network
Source Host
Source Socket
IPX Data0-546 byte
PotentialPAD
Host Number: 48bit (6byte)– MAC címSocket Number:16 bit –szolgálat elérési pontPl: 1: Routing Information, 2: Echo, 3: Router Error
0451:Netware File Server, 0452:Netware SAP0453:Netware RIP (Routing Information Protocol), stb.
Transport Control: 0000xxxx – 4bit hop counterPacket Type:az adatok tipusát határozza megPl: 0: Unknown, 1: Routing Information packet 2: Echo packet,
3: Error packet, 4: Packet Exchange, 5: Sequence Packet Protocol
Párosra egészíti ki a byte számot (de nincs benne a hosszban).
Ha 0:ismeretlen
IPX routing
• A router-eket itt „bridge”-nek hívják
• Valamennyi táblázat, amely tartalmazza valamennyi hálózat elérési irányát.
• Beállításuk vagy kézzel (statikus routing), vagy (és) elosztott dinamikus módon:
Dr. Kovács Szilveszter © E. III. / 9.
(és) elosztott dinamikus módon:IPX RIP: IPX Routing Information Protocol(A szomszédok táblát cserélnek.)
IPX routing%080002001231Port1
Port2%080002001232
IPX Router A
%080002001233Port1
Port2%080002001234
IPX Router B
%080002001235Port1
Port2%080002001236
IPX Router C
&00000011 &00000022 &00000033 &00000044Network
Host A Host B%080002001111 %080002002222
IPX Frame:(A→B)
Dr. Kovács Szilveszter © E. III. / 10.
Dest MAC%080002001231
Source MAC%080002001111
Type:8137h
Ethernet Data: IPX Frame
CRC
DNet&44
DHost%080002002222
DSock!451
SNet&11
SHost%080002001111
SSock!B9
IPXDATA
(A→B)
Datalink Frame (Ethernet): Router A-nak küldi Host A
Dest MAC%080002001233
Source MAC%080002001232
Type:8137h
Ethernet Data: IPX Frame
CRC
Datalink Frame (Ethernet): Router B-nek küldi Router A
Nem (alig, csak a hop counter, checksum) változik! Majdnem ugyanazt az IPX keretet adják tovább.
Internet: TCP/IP protocol stack
• Hierarchikus címzés is lehetséges
• Világméretű hálózat alakítható ki belőle
• Újabb elnevezések:– Internet: „küls ő” hálózat (WAN)– Intranet: „bels ő” hálózat (LAN)
Dr. Kovács Szilveszter © E. III. / 11.
– Intranet: „bels ő” hálózat (LAN)
• Általános hálózati kommunikációs szolgálatok készletét biztosítja
• A szolgálatok szabványosítottak, és ma már szinte valamennyi OS-re implementálták
• Internet testületeket, szabványosítás:
Internet Technical Bodies (technikai testületek)
• ISOC - Internet Society. Professzionális közösség az Internet kutatási és oktatási felhasználásának támogatására.
• IAB - Internet Architecture Board. Az ISOC alá tartozó technikai koordinációs testület.
• IETF - Internet Engineering Task Force.
Dr. Kovács Szilveszter © E. III. / 12.
• IETF - Internet Engineering Task Force. Meglévő protokollok és specifikációk standardizálása. Évente háromszor, munkacsoportokban (working groups) ülésezik.
• IRTF - Internet Research Task Force. Kutatás orientált csoport.
Internet adminisztráció• USA:
– DDN (Defense Data Network) – az Internetért felelős kormányszervezet – NOC (Network Operations Center) – kommunikációs linkekért felel– DDN NIC (Network Information Center)
• TCP/IP protokollal összefüggő anyagok gyűjtése és terjesztése
IANA Internet Assigned Numbers Authority– Az egész világon egyedihálózati címek,
Dr. Kovács Szilveszter © E. III. / 13.
– Az egész világon egyedihálózati címek, Domain nevek és szolgálat azonosítók kiosztása
• Regionális szervezetei(Regional Inrenet Registries):• RIPE NCC (www.ripe.net) Réseaux IP Européens Network
Coordination Centre – Európa, Közel-Kelet, Észak-Afrika
• ARIN (www.arin.net) American Registry for Internet Numbers
• APNIC (www.apnic.net) Asian Pacific Network Information Centre
IAB szabványosítási folyamat
RFC
Internet Draft
Request For Comments: véleményezésre közreadott technikai dokumentumok
Revision RFC
Technikailag stabil, hibáktól,
Dr. Kovács Szilveszter © E. III. / 14.
Proposed Standard
Draft Standard
Official Standard
Technikailag stabil, hibáktól, hiányosságoktól mentes protokoll specifikációk.
Legalább két független egymással interoperábilis implementáció a specifikált funkciók tesztelésére
Jelentős felhasználási terület és egyértelmű felhasználói érdeklődés
Protocol Status Levels
• Valamennyi TCP/IP protokoll az alábbi öt állapot valamelyikében van:– Required – szükséges– Recommended – ajánlott– Elective – választható– Limited use – részlegesen használható
Dr. Kovács Szilveszter © E. III. / 15.
– Limited use – részlegesen használható– Not recommended – nem ajánlott
Internet dokumentumok
• RFC– RFC XXXX – több mint 2500 létezik belőle– A frissített RFC-k új RFC számmal jelennek meg– Nem mindegyik RFC ír le protokollokat és nem
mindegyiket használják– ftp://ds.internic.net
Dr. Kovács Szilveszter © E. III. / 16.
– ftp://ds.internic.net
• STD (STandDard)– hivatalos Internet standard
• FYI (For Your Information)– RFC-k, amik nem protokoll leírást tartalmaznak
RFC dokumentum fejléc minták • RFC
– 2030 I D. Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", 10/30/1996. (Pages=18) (Format=.txt) (Obsoletes RFC1769)
– 1879 I B. Manning, "Class A Subnet Experiment Results and Recommendations", 01/15/1996. (Pages=6) (Format=.txt)
Dr. Kovács Szilveszter © E. III. / 17.
(Pages=6) (Format=.txt)
• FYI– 0023 Guide to Network Resource Tool. EARN Staff.
March 1994. (Format:TXT=235112 bytes) (Also RFC1580)
– 0028 Netiquette Guidelines. S. Hambridge. October 1995. (Format: TXT=46185 bytes) (Also RFC1855)
Az Internet hivatkozási modell (DoD)
ApplicationApplicationNetwork
Applications
End-to-end
Dr. Kovács Szilveszter © E. III. / 18.
TransportTransport
InternetInternet
NetworkNetwork
PhysicalPhysical
End-to-endServices
Routing
Transmission
Network Interface
Az ISO/OSI és a DoD modellekDoD (Department of Defense)
ApplicationApplication
TCP/IPApplicationApplication
PresentationPresentation
SessionSession
OSI
Dr. Kovács Szilveszter © E. III. / 19.
PhysicalPhysical
TransportTransport
InternetInternet
NetworkNetwork
TransportTransport
NetworkNetwork
Data LinkData Link
PhysicalPhysical
A TCP/IP protokol stackApplicationApplication
TransportTransport
InternetInternet(Network)(Network)
Network AccessNetwork Access
User ProcessUser Process
IPIP IGMPIGMPICMPICMP
UDPUDPTCPTCP
User ProcessUser ProcessUser ProcessUser ProcessUser ProcessUser Process
DoDDoD
Dr. Kovács Szilveszter © E. III. / 20.
PhysicalPhysical
Network AccessNetwork Access(Data Link)(Data Link) Hardware InterfaceHardware InterfaceARPARP RARPRARP
Physical layerPhysical layer
Szállítási réteg:TCP: Transmission Control Protocol (Telnet, Rlogin, FTP, SMTP)
→ megbízható adattovábbítás (összeköttetés alapú szolgálat)UDP: User Datagram Protocol (TFTP, SNMP, DNS (TCP is))
→ összeköttetés-mentes datagram szolgálat
A TCP/IP protokol stackApplicationApplication
TransportTransport
InternetInternet(Network)(Network)
Network AccessNetwork Access(Data Link)(Data Link)
User ProcessUser Process
IPIP
Hardware InterfaceHardware Interface
IGMPIGMPICMPICMP
ARPARP RARPRARP
UDPUDPTCPTCP
User ProcessUser ProcessUser ProcessUser ProcessUser ProcessUser Process
DoDDoD
Dr. Kovács Szilveszter © E. III. / 21.
PhysicalPhysical Physical layerPhysical layerHálózati réteg:IP: Internet Protocol → összeköttetés-mentes datagram szolgálat változó méretű csomagokra → Best effort delivery (a telhető legjobb): változó késleltetés, hiba, adatvesztés
→ kapcsolódhat hozzá alkalmazói program közvetlenül, de ritkaICMP: Internet Control Message Protocol → a hálózati réteggel kapcsolatos üzenetek
(pl. Router csomageldobás esetén visszaüzen)→ lehet közvetlen alkalmazói program kapcsolat (pl. ping –echo request/reply)
IGMP: Internet Group Management protocol → multicasting (többes címzés)-el kapcsolatos üzenetek
A TCP/IP protokol stackApplicationApplication
TransportTransport
InternetInternet(Network)(Network)
Network AccessNetwork Access(Data Link)(Data Link)
User ProcessUser Process
IPIP
Hardware InterfaceHardware Interface
IGMPIGMPICMPICMP
ARPARP RARPRARP
UDPUDPTCPTCP
User ProcessUser ProcessUser ProcessUser ProcessUser ProcessUser Process
DoDDoD
Dr. Kovács Szilveszter © E. III. / 22.
PhysicalPhysical
(Data Link)(Data Link)
Physical layerPhysical layer
Adatkapcsolati réteg:Hardware interface: megbízható csatorna kialakítása
→ keretképzés, hibavédelem, adatfolyam vezérlés, kapcsolat menedzsmentARP: Address Resolution ProtocolRARP: Reverse Address Resolution Protocol
→ Ethernet Broadcast → MAC címek ↔ IP címek közötti kétirányú megfeleltetés
Applications
Transport
IP
1 2 3 4( ) ( ) ( ) ( )
A TCP és UDP SAP azonosítás
• A szolgáltatott alkalmazásokat 16 bites portszámokkal azonosítják(SAP Service Access Point)– 0 --not used– 1-255 --Reserved ports for well-known
services (IANA)– 256-1023 --Other reserved ports
Dr. Kovács Szilveszter © E. III. / 23.
– 256-1023 --Other reserved ports– 1024-65535 --user-defined server ports
• Unix stores general used port in /etc/servicesPl:– telnet TCP: 23; ftp TCP: 20(data), 21(control); tftp
UDP: 69; – http: 80; smtp: 23; stb.
Internet címek
• 32 bit, 4 byte
• Pontok közötti decimális alak (Dotted decimal notation - egészen jól olvasható)164.107.134.510100100.01101011.10000110.00000101 (bin)A4:6B:86:05 (hexa)
Dr. Kovács Szilveszter © E. III. / 24.
A4:6B:86:05 (hexa)
• Max címszám: 232 = 4 milliárd csomópont
• Class A Networks = 15 millió csomópont
• Class B Networks = 64K csomópont
• Class C Networks = 250 csomópont.
IPv4
IP címosztályok• Hierarchia: hálózat cím + hoszt cím (netid+hostid)
• Class A0.0.0.0 - 127.255.255.255
• Class B128.0.0.0 - 191.255.255.255
• Class C
0 netid hostid
1 7 24 bits
10 netid hostid
2 14 16 bits
110 netid hostid
Dr. Kovács Szilveszter © E. III. / 25.
192.0.0.0 - 223.255.255.255
• Class D(többes címzés)
224.0.0.0 - 239.255.255.255
• Class E240.0.0.0 - 247.255.255.255
multicast: többes címzés ⇒
az üzenet a multicast csoport minden tagjának szól (broadast → mindenkinek szól)
IPv4
110 netid hostid
3 21 8 bits
1110 Group id. (Multicast)
4 28 bits
11110 Lefoglalva (későbbi felh.)
5 27 bits
IP címtér
Osztály Oszt.+hálózati bitek száma
Hálózatok száma
Gép bitek száma
Gépek száma
Címmező foglalás
A 1 + 7 27 - 2 = 126 24 224 - 2 = 16777214
49,21%
B 2 + 14 214 = 16384
16 216 - 2 = 65534
24,99%
Dr. Kovács Szilveszter © E. III. / 26.
B 2 + 1416384
1665534
24,99%
C 3 + 21 221 = 2097152
8 28 - 2 = 254 12,40%
D Multicast 4 + 28 228 = 268435456
- - 6,25%
E Fenntartva 4 - 32 - 4 228 - 1 = 268435455
6,25%
IPv4
Speciális címek és jelentésük• Nem minden cím osztható ki állomáscímnek
Hálózat bitek
Gép bitek Jelentés
..0.. ..0..Ideiglenes forrás cím, amíg nem tanulja meg a gép a címét. Nem szabad célcímként használni. Default route: 0.0.0.0
..1.. ..1..Broadcast, mindenki ezen a helyi fizikai hálózaton. MAC broadcast keretben kell küldeni.
Dr. Kovács Szilveszter © E. III. / 27.
x ..0.. Ez a logikai hálózat. Korábban logikai broadcast.
x ..1..Directed broadcast, mindenki ezen a távoli hálózaton. Távolról MAC unicast keretben kell
127.0.0 xLoopback, a helyi TCP/IP stack pszeudó címe a hoszton belül. A hálózaton nem fordulhat elő.
224.0.0.2 - Multicast, az összes router ezen a hálózaton van.
IPv4
Klasszikus címzés összefoglaló
• A cím egyértelműen két részre bontható– az első bitek megmondják, hol a határ– ugyanakkor merev bit-határok– broadcast cím egyértelműen számítható
(a host id. csupa 1-es)
• Igény a címzési hierarchia bővítésére
Dr. Kovács Szilveszter © E. III. / 28.
• Igény a címzési hierarchia bővítésére– Intézményi hálózatok fejlődése– a pazarló A és B osztályok elfogytak– pont-pont kapcsolatokra teljes C osztály
IPv4
Alhálózat (subnet) bevezetése
• Az eredeti felosztás
• A subnet maszkkal az
hhhhhhhhggggggggggggggggggg
32 bits
netid hostid
32 bitsA subnet maszk:
Dr. Kovács Szilveszter © E. III. / 29.
• A subnet maszkkal az – értékes biteket kijelöljük
hhhhhhhh ggggggg
netid hostid
sssssssssssssss
subnetid
A subnet maszk: n db 1-es bit és 32-n db 0-s bit
Kiterjesztett hálózatiazonosító
IPv4
Alhálózat címzések
• A (sub)net maszk (RFC 950)
• A kiterjesztett hálózati azonosító hosszabb lehet, mint a címosztály hálózati azonosítója!
• C osztályú címnél a default maszk: 255.255.255.0
• A prefix jelölés:
Dr. Kovács Szilveszter © E. III. / 30.
• A prefix jelölés:– 193.6.5.0/24
• 193.6.5.0• 255.255.255.0
Osztály Prefix NetmaskA /8 255.0.0.0B /16 255.255.0.0C /24 255.255.255.0
IPv4
A subnetting eredménye
• A címező jobb kihasználása– pont-pont kapcsolatok 2 biten elférnek– több LAN befér egy IP hálózatba
• A cím nem tartalmazza a hálózat-azonosítót– A maszkot is jól kell konfigurálni
• a broadcast cím nem található ki az IP címből
Dr. Kovács Szilveszter © E. III. / 31.
• a broadcast cím nem található ki az IP címből
– A maszkot is kell továbbítani (plussz 4 byte az útvonal-választási információkban)
– De az útvonalválasztás egyszerűsödhet(pl. hálózatok összefogása „szupernetting”)
IPv4
A címfeldolgozás• Pl 193.6.5.1 IP címből a
– /24 (255.255.255.0) maszk és az and logikai műveletleválasztja a hálózati címet
– a /24 maszk negáltjának és az and logikai művelet leválasztja a gép címet
• Ha a szubnet maszk hosszabb111… ..11 0000
32 bits
1111
Dr. Kovács Szilveszter © E. III. / 32.
– Pl. /28: 255.255.255.240, akkor • 28 bits: net• 4 bits: host
• Ha rövidebb, mint a címosztályé: „supernetting”– több hagyományos osztály összefogása– Pl. 16 C összefogása: /20: 255.255.240.0
IPv4
111… ..11 0000
24 b: netid 4b: hostid
1111
4b: snettid
28 b: netid
Alhálózat címkiosztási példa
• Adott 193.6.5.0/24; és bontsuk öt egyforma méretű alhálózatra!– 22 < 5 < 23 → 3 subnet bit kell → /27 a prefixes (255.255.255.224)
jelölés → valójában 8 alhálózatra osztunk
Bitminta Címtartomány Megjegyzés11000001|00000110|00000101|000xxxxx 193.6.5.0/27 Subnet 0/All zeros *
Dr. Kovács Szilveszter © E. III. / 33.
11000001|00000110|00000101|000xxxxx 193.6.5.0/27 Subnet 0/All zeros *11000001|00000110|00000101|001xxxxx 193.6.5.32/27 Subnet 111000001|00000110|00000101|010xxxxx 193.6.5.64/27 Subnet 211000001|00000110|00000101|011xxxxx 193.6.5.96/27 Subnet 311000001|00000110|00000101|100xxxxx 193.6.5.128/27 Subnet 411000001|00000110|00000101|101xxxxx 193.6.5.160/27 Subnet 511000001|00000110|00000101|110xxxxx 193.6.5.192/27 Subnet 611000001|00000110|00000101|111xxxxx 193.6.5.224/27 Subnet 7/All ones *
* Ezeket régen nem volt szab használni!IPv4
Alhálózat címkiosztási példa /2
• A Subnet 4-et osszuk ki …– Csak 30 gépet tudunk azonosítani, mert– egyet elvisz a subnet azonosító,– egyet pedig a subnet broadcast cím ...
Bitminta IP cím Megjegyzés11000001|00000110|00000101|10000000 193.6.5.128 Subnet azonosító
Dr. Kovács Szilveszter © E. III. / 34.
11000001|00000110|00000101|10000000 193.6.5.128 Subnet azonosító11000001|00000110|00000101|10000001 193.6.5.129 Gép 111000001|00000110|00000101|10000010 193.6.5.130 Gép 211000001|00000110|00000101|10000011 193.6.5.131 Gép 3… … …11000001|00000110|00000101|100111101 193.6.5.157 Gép 2911000001|00000110|00000101|100111110 193.6.5.158 Gép 3011000001|00000110|00000101|100111111 193.6.5.159 Subnet broadcast
IPv4
Változó alhálózat méretek• Variable Length Subnet Mask
(VLSM) (RFC 1009)– Különböző alhálózatok létrehozása
• hatékonyabb címfelhasználás– A routing-nak támogatnia kell (RIP-1 nem jó!)
• a kiterjesztett prefixet (subnet maszkot) is át kell adni (terjeszteni kell)
• Minden router a leghosszabb prefix egyezése elvén
Dr. Kovács Szilveszter © E. III. / 35.
• Minden router a leghosszabb prefix egyezése elvén továbbítsa a csomagokat
• Az aggregációhoz a címkiosztásnak követnie kell a topológiai feltételeket
– A többszintű hierarchia előnye• alhálózatokat tovább tudunk bontani• az aggregáció miatt ez kívülről nem látszik
IPv4
Maszk (bin) Maszk (dec)10000000 .12811000000 .19211100000 .22411110000 .24011111000 .24811111100 .25211111110 .254
Longest prefix match• Tegyük fel, a 2.28.137.130 címre kell a csomagot
továbbítani, az alábbi router tábla esetén: Forgatókönyv:– Kigyűjteni az összes bejegyzést, ahol cél IP és maszk a prefixet adja– Ezekből kiválasztani azt, amelyiknek a leghosszabb a maszkja.
Legrosszabb esetben 0.0.0.0, azaz a default route a választás
Route prefix Interface Next-hop Target IP mask
Dr. Kovács Szilveszter © E. III. / 36.
Route prefix Interface Next-hop Target IP mask0.0.0.0./0 Serial 0 1.1.1.1 0.0.0.02.28.0.0/16 Serial 1 2.2.1.1 2.28.0.0.2.28.137.0/24 Serial 2 2.3.1.1 2.28.137.02.28.137.128/25 Ethernet 0 2.3.1.4 2.28.137.1283.10.0.0/16 Serial 1 2.2.1.1 2.28.0.0.3.10.11.0/24 Serial 2 2.3.1.1 2.28.137.0
IPv4
Az osztály nélküli címzés
• Classless Inter-Domain Routing (CIDR) (RFC 1517-1520)– A maszk rövidebb is lehet, mint a hálózat-azonosító
(superneting) pl:193.6.0.0-193.6.15.0 16db C osztály → 255.255.240.0 (/20) → 193.6.0.0 /20
– Több hagyományos A,B,C osztály összefogása
Dr. Kovács Szilveszter © E. III. / 37.
– Több hagyományos A,B,C osztály összefogása– laza bithatárok: /4 … /30– szükségtelenné válik az osztályok használata– a routing nem az első bitek szerint dönt– a címtér sokkal jobban kihasználható
• A CIDR együtt élhet a klasszikus routinggal, de– a régebbi eszközök nem mindig kezelik
IPv4
A VLSM és a CIDR
• Mindkett ő támogatja egy A, B, C hálózaton– flexibilis alhálózat-rendszer kialakítását– belsejének elrejtését (aggregáció)
• A CIDR azonban lehetővé teszi– több bitszomszédos hálózatok összefogását (supernetting)
• és ezen belül tetszőleges hierarchia kialakítását
Dr. Kovács Szilveszter © E. III. / 38.
• és ezen belül tetszőleges hierarchia kialakítását
– több szomszédos A, B, C hálózat összevont útvonal-választási bejegyzését
IPv4
Címfoglalási szabályok
• A globális Interneten minden IP cím egyedi– a globális IP címeket engedélyeztetni kell
(IANA, EU: RIPE)
• Internett ől elszigetelt magánhálózaton– tetszőleges kiosztást készíthetünk, de így a– későbbi esetleges csatlakozás gondot okozhat.
Dr. Kovács Szilveszter © E. III. / 39.
– későbbi esetleges csatlakozás gondot okozhat. – Lokális címtartományok (IANA) (RFC 1918)
• 10.0.0.0./8• 172.16.0.0./12• 192.168.0.0./16
IPv4
Magánhálózat csatlakoztatása az Internetre
• Ha bejegyzett címtartományokat használtunk,– nincs gond.
• A lokális címtartományú magánhálózatot tűzfallal leválasztjuk (se ki, se be)– nincs gond, de nem használható az Internet közvetlenül
Dr. Kovács Szilveszter © E. III. / 40.
– nincs gond, de nem használható az Internet közvetlenül
• Lokális címtartományú magánhálózatról bejegyzett címtartományra kívánunk áttérni– átszámozás (elég költséges),– címfordítás NAT (Network Address Translation)
(RFC 1631) lehetséges.
IPv4
Címfordítás, NAT (IP masquerade)• A belső és a külső IP címek összerendelése
– Címfordítási táblázat (ötlet ua. Protokoll – több port):
Külső cím Belső címD=152.66.8.5
Külső IP cím(ek)Protokoll (TCP, UDP)
Külső Port
Belső IP cím(ek)Protokoll (TCP, UDP)Belső Port
Dr. Kovács Szilveszter © E. III. / 41.
193.6.5.4/32 10.1.2.0/24
10.1.2.4
D=152.66.8.5TCP(UDP)/dS=10.1.2.4TCP(UDP)/sb
NAT
D=152.66.8.5TCP(UDP)/dS=193.6.5.4TCP(UDP)/sk
Belső világKülső világ
D= 193.6.5.4TCP(UDP)/skS= 152.66.8.5TCP(UDP)/d
D= 10.1.2.4TCP(UDP)/sbS= 152.66.8.5TCP(UDP)/d
IPv4
Címfordítás, NATEgyetlen külső cím esetén:• Kicseréli a belső forrás címet a külső címre• Megnézi, hogy az eredeti forrás port szabad-e a külső
oldalon.• Ha szabad, akkor azt választja.• Ha foglalt, akkor a szabad (választható) portok közül
választ egyet.
Dr. Kovács Szilveszter © E. III. / 42.
választ egyet.• Ha nincs szabad port, akkor eldobja a csomagot.• Bejegyzi egy táblázatba a fordítást a visszafelé jövő,
illetve a további csomagok érdekében.Több külső cím esetén:• Ha nincs szabad port, akkor veszi a következő külső
címet és azon keres szabad portot. (Ugyanúgy mint egy cím esetén.)
IPv4
Címfordítás, NAT• A NAT transzparens mindazon protokollokra melyek
– nem használnak IP címeket a csomag belsejében,– nem használnak előre megbeszélt, vagy magasabb
szinten egyeztetett címet.• A NAT amennyiben felismeri (és ismeri) a magasabb
szintű protokollokat, úgy a csomag belsejében is elvégezheti a címváltoztatást.
Dr. Kovács Szilveszter © E. III. / 43.
elvégezheti a címváltoztatást.Pl:– FTP (a behívó kliens mondja meg a szervernek, hogy hova hívjon
vissza a szerver – aktív FTP, (passzívnál a behívó hív újra)).– embedded IP Addresses in DNS "A and PTR" records.
NAT will translate the address(es) which appear in DNS responses to name lookups (A queries) and inverse lookups (PTR queries).
IPv4
NAT - elnevezésekBasic NAT• This involves IP address translation only, not port
mapping. PAT (Port Address Translation)• Also called simply "NAT" or "Network Address Port
Translation, NAPT". This involves the translation of both IP addresses and port numbers.
Source NAT or SNAT • translation of the source IP address and/or source port
Dr. Kovács Szilveszter © EII. IV. / 44.
• translation of the source IP address and/or source portDestination NAT or DNAT• NAT which involves translation of the destination IP
address and/or destination port number. To publish a service located in a private networkon a publicly accessible IP address
Masqueraded network• Az átcímzett (eltakart) hálózat neve
IPv4
NAT - gond
• IP fregmentáció és UDP, TCP ellenőrzőösszeg
• IP has a checksum in each packet header, which provides error detection only for the header.
• IP datagrams may become fragmented and it is necessary for a NAT to reassemble these fragments to allow correct recalculation of higher
Dr. Kovács Szilveszter © EII. IV. / 45.
fragments to allow correct recalculation of higher level checksums (TCP, UDP) and correct tracking of which packets belong to which connection.
IPv4
Destination network address translation (DNAT)
• DNAT is a technique for transparently changing the destination IP address of an en-route packet and performing the inverse function for any replies. Any router situated between two endpoints can perform this transformation of the
Dr. Kovács Szilveszter © EII. IV. / 46.
endpoints can perform this transformation of the packet.
• DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address.
IPv4
NAT – elnevezések: SNAT• The usage of the term SNAT varies by vendor. • A common definition is Source NAT, the counterpart of
Destination NAT (DNAT).• Microsoft uses the term for Secure NAT, in regards to the
ISA Server extension discussed below. • For Cisco Systems, SNAT means Stateful NAT.
Dr. Kovács Szilveszter © EII. IV. / 47.
• For Cisco Systems, SNAT means Stateful NAT.• The Internet Engineering Task Force(IETF) defines
SNAT as Softwires Network Address Translation. This type of NAT is named after the Softwires working group that is charged with the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks.
IPv4
NAT – elnevezések: Dynamic network address translation
Static NAT
• One-to-one internal to public static IP address mapping
Dynamic NAT
Dr. Kovács Szilveszter © EII. IV. / 48.
• Uses a group of available public IP addresses.
IPv4
Full cone NAT - one-to-one NAT
• Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent
Dr. Kovács Szilveszter © EII. IV. / 49.
iAddr:iPort will be sent through eAddr:ePort.
• Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.
IPv4
(Address) Restricted cone NAT
• Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort.
• An external host
Dr. Kovács Szilveszter © EII. IV. / 50.
• An external host (hAddr:any) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort had previously sent a packet to hAddr:any."any" means the port number doesn't matter.
IPv4
Port-Restricted cone NAT
• Like an (Address) Restricted cone NAT, but the restriction includes port numbers.
• Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent
Dr. Kovács Szilveszter © EII. IV. / 51.
from iAddr:iPort will be sent through eAddr:ePort.
• An external host (hAddr:hPort) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort had previously sent a packet to hAddr:hPort.
IPv4
Symmetric NAT • Each request from the same
internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port.
• If the same internal host sends a packet even with the same source address and port but to a different
Dr. Kovács Szilveszter © EII. IV. / 52.
port but to a different destination, a different mapping is used.
• Only an external host that receives a packet from an internal host can send a packet back.
IPv4
Session Traversal Utilities for NAT (STUN)
• In the original specification in RFC 3489, STUN was an acronym for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs),but this title has been changed in a specification of an updated set of methods published as RFC 5389with the title Session Traversal Utilities for NAT, retaining the
Dr. Kovács Szilveszter © EII. IV. / 53.
Session Traversal Utilities for NAT, retaining the same acronym.
IPv4
Session Traversal Utilities for NAT (STUN)
• The STUN protocol allows applications operating through a network address translator(NAT) to discover the presence of a network address translator and to obtain the mapped (public) IPaddress (NAT address) and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) connections to remote
Dr. Kovács Szilveszter © EII. IV. / 54.
Datagram Protocol (UDP) connections to remote hosts.
• The protocol requires assistance from a 3rd-party network server (STUN server)located on the opposing (public) side of the NAT, usually the public Internet .
IPv4
Session Traversal Utilities for NAT (STUN)
STUN does work with primarily three types: • full cone NAT, • restricted cone NAT, and • port restricted cone NAT. • In the cases of restricted cone or port restricted cone
NATs, the client must send out a packet to the endpoint
Dr. Kovács Szilveszter © EII. IV. / 55.
NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client.
STUN does not work with symmetric NAT.• In symmetric NAT case, the NAT mapping will be
different for the STUN server than for an endpoint. TURN (Traversal Using Relay NAT) offers better results with symmetric NAT.
IPv4
Session Traversal Utilities for NAT (STUN)
• The client, operating inside the NAT-masqueraded network, initiates a short sequence of requests to a STUN protocol server listening at two IP addresses in the network on the public side of the NAT, traversing the NAT.
• The server responds with the results, which are the
Dr. Kovács Szilveszter © EII. IV. / 56.
• The server responds with the results, which are the mapped IP address and port on the 'outside' of the NAT for each request to its two listeners.
• From the results of several different types of requests, the client application can learn the operating method of the network address translator, including the lifetime of the NAT's port bindings.
IPv4
Session Traversal Utilities for NAT (STUN)
• When a client has discovered its external address, it can communicate with communication peers by advertising its external NAT address to its peers, rather than the masqueraded (internal) address that is not reachable for its peers on the public network.
• In some cases of NATs (e.g., full-cone type) then either
Dr. Kovács Szilveszter © EII. IV. / 57.
• In some cases of NATs (e.g., full-cone type) then either side can initiate communication.
• With other types (restricted cone or restricted port cone types) both sides must commence transmitting at about the same time to establish the port bindings in the network address translator.
IPv4
Session Traversal Utilities for NAT (STUN)
• The original STUN specification (RFC 3489) used the following algorithm to characterize NAT gateways and firewalls according to the address mapping behavior. It should be noted that this algorithm
Dr. Kovács Szilveszter © EII. IV. / 58.
be noted that this algorithm is not a reliably successful procedure and only applicable to a subset of NAT devices deployed today. The method has therefore been officially removed from the latest version of the standard (RFC 5389).
IPv4
Session Traversal Utilities for NAT (STUN)
• Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port.
• If the same internal host sends a packet even with the same source address and
Dr. Kovács Szilveszter © EII. IV. / 59.
same source address and port but to a different destination, a different mapping is used.
• Only an external host that receives a packet from an internal host can send a packet back.
• Megy, ha sárga, vagy zöld
IPv4
Session Traversal Utilities for NAT (STUN)
Dr. Kovács Szilveszter © EII. IV. / 60.IPv4
IPv4 címzés fejlődése
• Klasszikus címosztályok: 1981– a címzési rendszer alapelvei
• Alhálózatok: 1985– kétszintű hierarchia
• Változó méretű alhálózatok: 1987
Dr. Kovács Szilveszter © E. III. / 61.
• Változó méretű alhálózatok: 1987– többszintű hierarchia, aggregáció
• Osztálymentes címzés: 1993– tetszőleges hálózatméret, hálózatok közti aggregáció
• Címfordítás: 1994– a címtér többszörös lefedése
IPv4
Az IP csomag
verzió IHL TOS (8) Total length (16)
Identification (16) flags Fragment offset (13)
TtL (8) Protocol (8) Header checksum (16)
Source IP Address (32)
Destination IP Address (32)
Hea
der
20 b
ytes
4 4
Dr. Kovács Szilveszter © E. III. / 62.
Destination IP Address (32)
Options (if any * 32)
Data (x * 32)
IPv4
verzió IHL TOS (8) Total length (16)4 4
Az IP csomag
• Verzió: 4 (IPv4)• IHL: Header length (a header hossza az opciókkal együtt)
32 bites szavakban 4 bit ⇒ a header max 60 byte hosszú lehet
• TOS: Type of Services, csak 3+4 bitet használ:– 3 bit a prioritásra (7 a magas, 0 az alacsony) + 4 bit:
Dr. Kovács Szilveszter © E. III. / 63.
– 3 bit a prioritásra (7 a magas, 0 az alacsony) + 4 bit:– D bit: Minimize delay (Pl. telnet)– T: Maximize throughput (Pl. Ftp data)– R: Maximize reability (pl SNMP)– Minimize monetary cost(Nem minden implementáció használja (pl. OSPF dönthet ez alapján))
• Total length: az IP datagram teljes mérete bájtokban16 bit ⇒ IP datagram max. 65535 byte
IPv4
egyszerre csakegy bit lehet 1
Az IP csomag
• Identification: a datagram egyedi azonosítója, amit a küldő hoszt állít be (pl fregmentáció esetén azonosítja az egyes darabokat)
• Flags (3 bit): – 1 bit nem használt– 1 bit (DF): "don't fragment" bit: ha 1, a csomag nem
Identification (16) Flags Fragment offset (13)
Dr. Kovács Szilveszter © E. III. / 64.
– 1 bit (DF): "don't fragment" bit: ha 1, a csomag nem fregmentálható.
• Ha mégis kellene: ICMP error "fragmantation needed but don't fragment bit is set"
– 1 bit (MF): fregmentálás esetén 1, ha van még további darab; 0, ha ez az utolsó
• Fragment offset (13 bit): fregmentáció esetén a data melyik része (milyen az eltolás 8 byte-okban számolva). Az első darab esetén = 0. Az összes darab hossza csak 8 egész többszöröse byte lehet (kivéve az utolsó darabot).
Az IP csomag
• Time to Live (TTL, 8 bit): – Minden ugrás esetén a router annyival csökkenti, ahány sec-ot állt
nála (de legalább 1-gyel). – Régebben 32 v. 64, manapság 128 kezdeti értékkel– Ha eléri a 0-át,
• a router eldobja és
TTL (8) Protocol (8) Header checksum (16)
Dr. Kovács Szilveszter © E. III. / 65.
• a router eldobja és• ICMP "time exceeded" error a feladónak.
• Protocol: az IP csomagot előállító protokollt (pl TCP, UDP, ICMP, IGMP) azonosítja
• Header cheksum: az IP fejrészre vonatkozó 1 komplemens 16 bites összeg. Mivel a TTL változik, mindig újraszámítandó (Hop). Hiba esetén eldobják a csomagot.(A vevő az egészre számol 1 komplemens összeget → ha jó, csupa 1)
IPv4
Az IP csomagverzió IHL TOS (8) Total length (16)
Identification (16) flags Fragment offset (13)
TtL (8) Protocol (8) Header checksum (16)
Source IP Address (32)
Destination IP Address (32)
Options (if any * 32)
Hea
der
20 b
ytes
4 4
Dr. Kovács Szilveszter © E. III. / 66.
• SA, DA (IP címek)• Opciók és adatok
IPv4
Options (if any * 32)
Data (x * 32)
Az enkapszuláció
Network Applications
TCP UDP
IP
ARP Packet
Segment D.gram
User Data
User DataApp-H
Appl DataTCP-H
Appl DataTCP-HIP-H
IP datagram
TCP szegmens
Application layer
Dr. Kovács Szilveszter © E. III. / 67.
ARP
Ethernet Frame
Packet
Appl DataTCP-HIP-H E-TE-H
14 20 20 4Ethernet frame (46-1500 byte)
IP datagram
A visszaállítás (demultiplexálás)User Data
TCP-H
IP-H
IP datagram
Network Applications
TCP UDP
IP
ARP RARP Az Ethernet kerettípus alapján
Az IP Header Protocol értéke alapján demultiplexál
A cél port (SAP) címszerint demultiplexál
User DataApp-H
Dr. Kovács Szilveszter © E. III. / 68.
E-TE-H
Incoming frame
IP datagramARP
Ethernet Frame
RARP Az Ethernet kerettípus alapján
A TCP SAP, UDP SAP azonosítás: 16 bites port szám alapján (port number)
Link Layer: Ethernet enkapszuláció
Data+ PadTypeSA CRCDA
IP datagram0800 CRC
(RFC 894)
Ethernet frame
46-1500 byte6 6 2 4
28 18
Dr. Kovács Szilveszter © E. III. / 69.
0806 CRC
8035 CRC
Ethernet kerettípus
PadARP req/rep
PadRARP req/rep
28 18
28 18
Link Layer: 802.3 enkapszuláció(RFC 1042)
802.3 frame
SADA Len D S C Data+ PadType CRCO
802.3 MAC Header
802.2 LLC 802.2 SNA
26 6 11 1 3 2 4
(mint az előző oldalon)
46-1500 byte
Dr. Kovács Szilveszter © E. III. / 70.
Header802.2 SNA
Header
D: Destination SAP (AA)S: Source SAP (AA)C: Control (vezérlés) (03)O: Organisation Code (00)Type: Lásd Ethernet
SNA: Sub Network Access Protocol Headre
LLC: Logical Link Control Header
Link Layer: PPP enkapszuláció
F: Flag szinkron:7E (bitbeszúrás: 01111110)aszinkron: 7E, de karakter orientált
transzparens: adatok között
PPP frame
F A C IP datagram / control data
Prot CRC
11 1 2 2
F
10-1500
IP soros vonalon (nem csak IP) Point to Point Protocol• aszinkron, 8 bites adatok, • szinkron, bit orientált. A protokoll lehet:LCP (Link Control P)(RFC 1548):Data link kapcsolat létrehozása, tesztje, konfigurációja
Dr. Kovács Szilveszter © E. III. / 71.
transzparens: adatok között 7E: 0x7D=escape: 0x7E→7D,5E;adatok közt 0x7D→7D,5D;20h-nál kisebb →7D,20H+d
A: Address (FF)C: Control (03)Prot: 0021: IP datagram Nincs ARP ← ez pont-pont kapcsolat !
C021: Link Control Data8021: Network Control Data
tesztje, konfigurációjaNCP (Network Cont. Prot.)(RFC 1332):különböző hálózati protokollok(pl. IPX) átvitele PPP-n
Az ARP (RFC 826)
• Feladat: host vagy router IP címének leképzése MAC címmé
• Fogalmak, alapok:– IP cím: hálózat + host cím, a subnet maszk segít a
szétválasztásban– Default router: egy hálózathoz tartozó router és
Dr. Kovács Szilveszter © E. III. / 72.
– Default router: egy hálózathoz tartozó router és annak IP címe
– Helyi kommunikáció: egy hálózaton belüli• Ua a hálózati cím (ua a subnet-mask)
– Távoli kommunikáció: hálózaton kívüli• más a hálózati cím
Az ARP (RFC 826)
• Fogalmak:– Címzési szabályok:
• minden hosztnak (legalább egy) egyedi IP címe van
• az egy hálózaton lévőknek közös a hálózati címe (netid) és a szubnet maszkja
– A hálózat itt azonos a „Broadcast Domain”-nel!
Dr. Kovács Szilveszter © E. III. / 73.
– A hálózat itt azonos a „Broadcast Domain”-nel!• A hálózat azon része, melyről „Local Broadcast
Packet” használatával információt nyerhetek– ismétlők, hidak továbbítják a Local Broadcast
Packet-et,– routerek nem!
– A szegmensen belül helyi kommunikáció,„Direct Delivery” (közvetlen kézbesítés) van.
Az ARP (RFC 826)• Az L2 MAC címek kereshetők:
– Local Broadcast ARP_REQUESTküldése után a válaszokból ARP_REPLY (amiket azonnal cache-elni lehet)
– Majd a későbbiekben az ARP cache-ből (IP - MAC párok)
• ARP_REQUEST (Local Broadcast) tartalmazza a forrás IP címén kívül az L2 (MAC) címet is, így a válaszolónak nem kell keresnie a kérdező L2 címét.
• ARP_REQUEST (Local Broadcast) –okat mindenki cache-
Dr. Kovács Szilveszter © E. III. / 74.
• ARP_REQUEST (Local Broadcast) –okat mindenki cache-eli, így a kérdezők L2 címét a passzívak is begyűjtik
• Induló állomás saját IP címére ARP_REQUEST(Local Broadcast), ha valaki válaszol rá, más is használja a címet (ha nem, akkor is bekerül legalább az ARP cache-ekbe)
• Az ARP cache bejegyzések öregednek• Proxy ARP (helyettesítő ARP)• A továbbiakhoz tegyük fel, hogy megvan a cél IP címe (Pl.
DNS-ből)
10.0.0.1/24 10.0.0.2/24 10.0.0.3/24
10.0.0.0/24
Az RARP
• Saját IP cím lekérdezése (pl. boot) a saját MAC cím alapján– RARP_REQUEST Broadcast-al– A szerver táblázat alapján válaszol RARP_REPLY
További protokollok
Dr. Kovács Szilveszter © E. III. / 75.
• Boot Protocol (RFC 1542)– MAC és IP cím statikus összerendelése– Kliens-szerver-relay_agent konfiguráció– UDP csomagokban request-reply
További protokollok
Dynamic Host Configuration Protocol DHCP (RFC 1541)
• MAC és IP cím dinamikus összerendelése,
• címtartományok kijelölhetők,• címhasználat időben korlátozódhat,• kérheti a korábbi címét,• hasznos erőforrások (pl. netmask,
Dr. Kovács Szilveszter © E. III. / 76.
• hasznos erőforrások (pl. netmask, DNS, default GW) jelezhető,
• BOOTP-vel felülről kompatibilis.
Az IP csomagok továbbítása
• Megvizsgálja a cél IP címet, az „helyi”, vagy „távoli” – A saját subnet maszkkal leválasztja a hálózati
címrészt, és összeveti a sajátjával: ha egyezik: helyi, ha nem: távoli.
Dr. Kovács Szilveszter © E. III. / 77.
• Ha helyi, akkor (Direct Delivery)– Nézi a cache-ében, van-e hozzá MAC cím.
Igen: a MAC szinten elküldi a címzettnek.– Nincs: Local Broadcast kezdeményezéssel választ
kér, és így megkapja a cél MAC címet. Mindjárt cache-eli, és MAC szinten elküldi a címzettnek.
Az IP csomagok továbbításaHa a cél cím „távoli”, akkor (Indirect Delivery)• Nézi saját forgalomirányító tábláját (route table),
van-e speciális út a célhoz, ha van,– keresi a cache-ében, ismeri-e az úthoz rendelt
router MAC cím. Igen: MAC elküldi annak.– Nincs: Local Broadcast kezdeményezéssel választ
kér, és így megkapja a router MAC címet. Mindjárt cache-eli, és MAC szinten elküldi neki
Dr. Kovács Szilveszter © E. III. / 78.
cache-eli, és MAC szinten elküldi neki• Ha nincs speciális út (esetleg nincs is forgalomirányító
tábla) – a default router-nek küldi: – Nézi a cache-ében, van-e a default router-hez MAC
cím. Igen: MAC elküldi annak.– Nincs: Local Broadcast kezdeményezéssel választ
kér, és így megkapja a default router MAC címet. Mindjárt cache-eli, és MAC szinten elküldi neki
Az IP csomagok továbbítása
• Két host közös hálózaton (netid), közös adatkapcsolati réteg
HostA
IPA: netA +hostA
HostB
IPB: netA +hostB
DataIP
HeaderLink
Header
HostA→ HostB
Dr. Kovács Szilveszter © E. III. / 79.
Dest: MACB Dest: IPB
Az IP csomagok továbbítása
• Két host különböző hálózaton
HostAIPA: netA +hostA
IPRA: netA +routerA
DataIP
HeaderLink
Header
HostA→ RouterA
Dest: MACRA Dest: IPB
1:
Dr. Kovács Szilveszter © E. III. / 80.
Router
IPRA: netA +routerA
HostB
IPRB: netB +routerB
IPB: netB +hostBData
IPHeader
Link Header
RouterB → HostB
Dest: MACB Dest: IPB
2:
Az IP csomag nem (alig (TTL+checksum)) változik, csak a Link Layer Header más.
Az IP routing
• Az útvonalválasztó az eredeti datagram-on a következőket változtatja meg:– Dekrementálja a Time-to-Live mezőt (amiből
eldönthető, hány sec-ig, vagy ugrásig maradhat meg a datagram).
– Újraszámítja a checksum-ot.
Dr. Kovács Szilveszter © E. III. / 81.
– Újraszámítja a checksum-ot.
IP routing tábla
• Egy router a routing tábláját nézi végig, hogy melyik portjára (melyik interfészére) küldje a datagramot. – A keresési kulcs a cél IP hálózati címe.– A kereséshez kell a szubnet maszk is.
• A csomagtovábbítás
Dr. Kovács Szilveszter © E. III. / 82.
• A csomagtovábbítás– a leghosszabb illeszkedő prefix
(longest prefix match),– hop-by-hop (azaz minden router maga dönt),– nem megfelelő router választása esetén (a router
ugyanazon interfészén visszaküldi a csomagot) ICMP Redirect a küldőnek.
Routerek konfigurációja
HostARouter1
Cím: 193.6.10.1Maszk: 255.255.255.0Broadcast: 193.6.10.255Def.Router: 193.6.10.254
193.6.10.254255.255.255.0
Router2
193.6.4.254
193.6.3.254255.255.255.0
193.6.3.253255.255.255.0
Router3193.225.4.5255.255.255.252
193.6.12.253
193.6.12.254
Router1 net id mask gatewayIP Route 193.6.12.0 255.255.255.0 193.6.3.253
InternetISP
193.225.4.6 (ISP)
Dr. Kovács Szilveszter © E. III. / 83.
IP Route 193.6.12.0 255.255.255.0 193.6.3.253193.6.4.0 255.255.255.0 193.6.3.253
Default 0.0.0.0 0.0.0.0 193.6.3.253
Router2 net id mask gatewayIP Route 193.6.10.0 255.255.255.0 193.6.3.254Default 0.0.0.0 0.0.0.0 193.6.12.254
Router3 net id mask gatewayIP Route 193.6.3.0 255.255.255.0 193.6.12.253
193.6.4.0 255.255.255.0 193.6.12.253193.6.10.0 255.255.255.0 193.6.12.253
Default 0.0.0.0 0.0.0.0 193.225.4.6
A gateway (router) címemindig olyan, amit a sajáthálóján közvetlenül elér.
Ez a statikus kitöltési módjaa routing tábláknak(static routing)
Az ICMP
• Internet Control Message Protocol– Az alapvetően a hálózati réteggel kapcsolatos
üzenetek továbbítására
• Az ICMP enkapszuláció
• ICMP message
IP header ICMP message
Type (8) Code (8) Checksum (16)
20
IP datagramm
Dr. Kovács Szilveszter © E. III. / 84.
• Típusok: – hibaüzenetek,– információk,– diagnosztikai üzenetek.
Type (8) Code (8) Checksum (16)
Content (type és code függő tartalom)
ICMP
Checksum: a teljes ICMP üzenet ellenőrzése
ICMP példákType Code Üzenet (RFC792)
0 0 echo reply (ping)3 Destination unreachable
0 Network unreachable1 Host unreachable3 Port unreachable4 Fregmentation is needed but don't fragment bit set
4 0 Source quench: fojtócsomag (flow control)
Dr. Kovács Szilveszter © E. III. / 85.
4 0 Source quench: fojtócsomag (flow control)5 Redirect
0 Redirect for network1 Redirect for host
8 0 echo request (ping)11 Time exceed
0 Time to live = 0 during transmit (traceroute)1 Time to live = 0 during reassembly
stb.
ICMP
ICMP
• Az ICMP hibaüzenetek mindig tartalmazzák annak az IP datagram-nak a fejrészét (20 byte) és első 8 bájtját, ami a hibát okozta.
• Így a fogadó ICMP modul meghatározhatja a protokollt és a user processzt, amihez a hiba tartozik.
Dr. Kovács Szilveszter © E. III. / 86.
tartozik.
ICMP
IP hálózatok vizsgálata• A vizsgálatok szükségessége
– Hálózat beüzemelése, tesztelése• a végpontok látják-e egymást? (connectivity)• a csomagszűrés jól van-e beállítva?
– Üzemelő hálózat teljesítményének fokozása• hatékony a működés (perfomance)
Dr. Kovács Szilveszter © E. III. / 87.
• hatékony a működés (perfomance)• torlódások vannak-e?• Erőforrások kihasználtsága?
• Van néhány egyszerű alkalmazás– ping: az elérhetőség ellenőrzésére– traceroute: állomás elérési útvonalának
vizsgálata
A ping• Állomás elérhetőségének ellenőrzésére
– ping kliens: aki kezdeményez egy ICMP echo request-tel;
– ping szerver: aki válaszol egy ICMP echo reply-vel.– A csomagok sorszámot és időbélyeget kapnak
• csomagvesztés detektálható,• duplikáció detektálható,• sorrendcsere detektálható,
Dr. Kovács Szilveszter © E. III. / 88.
• sorrendcsere detektálható,• késletetési viszonyok változása (torlódás) detektálható.
Type: 0 v. 8 Code: 0 Checksum (16)
Optional data (a szerver echózza)
ICMP echorequest/reply
identifier
0 7 8 15 16 31
sequence numberA küldő processz id-je
0-tól számozzasorba
- Elérhető-e- Mennyi idő alatt
ér vissza a válasz
A traceroute• Állomás elérési útvonalának vizsgálata
Ötlet: – Ha router TTL = 1 vagy 0 IP datagramot kap, azt nem
továbbítja, hanem ICMP time exceed üzenetet küld.– Ha a router IP datagramot továbbít, a TTL értéket annyival
csökkenti, ahány sec-ig nála volt a csomag, de legalább 1-el→ gyak. a router 1 sec.-nél rövidebb ideig tart egy csomagot, így a TLL olyan mint egy ugrásszámláló
– Küldjünk csomagokat rendre TTL=1,2,3 … értékekkel olyan
Dr. Kovács Szilveszter © E. III. / 89.
– Küldjünk csomagokat rendre TTL=1,2,3 … értékekkel olyan UDP portra, amihez nem tartozik szerver alkalmazás (pl. 30000 feletti portszám)
• A soron következő első, második stb. router eldobja és ICMP üzenetet küld a saját címével mint feladóval→ megtudható a köztes routere-ek címe;
• Amikor eljut a célállomásra→ ICMP port unreachable üzenet jön vissza (a célállomás címével), ebből tudható, hogy elérte a célállomást.
A traceroute• ICMP time exceeded:
Type: 11 Code: 0v.1 Checksum (16)
IP header + első 8 byte
0 7 8 15 16 31
Unused = 0
Dr. Kovács Szilveszter © E. III. / 90.
Type: 3 Code: 3 Checksum (16)
IP header (20byte) + UDP header első 8 byte
0 7 8 15 16 31
Unused = 0
• ICMP UDP port unreachable:
Routing Algoritmusok és Protokollok
• A routing protokollok határozzák meg az utak számításának módját, és a router-ek közötti üzenetcserét (routing update).
• Vector Distance Algorithm (shortest path using hops):Eleinte mindegyik router csak a kapcsolódó hálózatokat ismeri, majd más routerekkel táblát
Dr. Kovács Szilveszter © E. III. / 91.
hálózatokat ismeri, majd más routerekkel táblát cserélve és frissítve saját tábláját megismeri a többi hálózatot.
• Shortest Path First Algorithm:Mindegyik routernél ott a teljes hálózat térképe az egyes utak árával. Az „ár” függhet a hop számtól, sebességtől stb.
Vector Distance Algorithm (Bellman-Ford)• A routing tábla távolság oszlopot is tartalmaz.• Distance = number of hops = number of gateways to
traverse• Mindegyik router megküldi a tábláit azokra a
hálózatokra, melyek kapcsolódnak hozzá.Azok a routerek, melyek megkapják ezen táblákat, módosítják azok metrikáit és felhasználják értékeit, ha:
Dr. Kovács Szilveszter ©
módosítják azok metrikáit és felhasználják értékeit, ha:– még nem ismernek olyan utat – Vagy az így kapott út jobb, mint amit eddig ismertek.
• A routerek periodikusan, vagy a változások esetén küldik el tábláikat.
• A lassabb hálózatok magasabb hop számmal jelölhetőek.
Vector Distance Algorithm (Bellman-Ford 1957, 1962)
B
D
C
A1
4
2
4
A-t vizsgáljuk, aki B-től és C-től kap táblákat:
B táblájaA A:1C A:3D D:4
C táblájaA A:2B A:3D D:4
A "módosítja" a kapott táblákat a küldő távolságával: +1 +2
Dr. Kovács Szilveszter © E. III. / 93.
MódosítottB B:1C B:4D B:5
MódosítottC C:2B C:5D C:6A kiválasztja a legjobbakat:
A a legjobbakból új táblát készít: A táblájaB B:1C C:2D B:5
Bellman-Ford algoritmus: count-to-infinityA végtelenig számolás problémája(count-to-infinity):• A jó hír ( A megjavult) gyorsan,• a rossz hír (A elromlott) lassan terjed
(a terjedés sebessége a ∞ ábrázolásától függ pl. 16)– A probléma oka, hogy egy csomópont nem tudja eldönteni, hogy
rajta van-e egy másik csomópont által javasolt úton.
A B C D E A B C D EA megjavult A elromlott
Dr. Kovács Szilveszter © E. III. / 94.
A B C D E
0 ∞ ∞ ∞ ∞ Kezdet
0 1 ∞ ∞ ∞ 1 csere
0 1 2 ∞ ∞ 2 csere
0 1 2 3 ∞ 3 csere
0 1 2 3 4 4 csere
x 1 2 3 4 Kezdet
x 3 2 3 4 1 csere
x 3 4 3 4 2 csere
x 5 4 5 4 3 csere
x 5 6 5 6 4 csere
x 7 6 7 6 5 csere
∞ ∞ ∞ ∞
A megjavult A elromlott
Shortest Path First (Link Status)
• Mindegyik router-nél ott a teljes hálózat térképe az egyes utak árával.
• Mindegyik routert periodikusan üzenetet küld a linkjeinek tesztelésére (link status).Ha érkezik rá válasz – a link él (up)Ha nem, akkor bejelöli a táblájába, hogy a link
Dr. Kovács Szilveszter ©
Ha nem, akkor bejelöli a táblájába, hogy a link nem elérhető (down).
• Minden változás esetén gráfelméleti módszerekkel újraszámolja az utakat (link).
• Gyakori a legrövidebb út algoritmus (shortest path, forward search) alkalmazása.
Shortest Path First (Dijkstra 1959)
• Legrövidebb út algoritmus:– Állandóvá tesszük a kiindulási állomást → (1)– (1) Ideiglenesen felcímkézzük a szomszédos
állomásokat – az úthosszal és az állandó állomás címével
– A legrövidebb úthossz címkéjűt állandóvá tesszük → (1)
Dr. Kovács Szilveszter © E. III. / 96.
→ (1)
Forgalomirányítás, infó
Pl: A→D legrövidebb út
1
4
1
3
1
A
B
C
D
Hossz, vagy súly
⇒
1
4
1
3
1
A
B(1,A)
C(4,A)
D
állandó
⇒
legkisebb súly- állandó
1
4
1
3
1
A
B(1,A)
C(4,A)(2,B)
D(4,B)
kisebb
⇒
1
4
1
3
1
A
B(1,A)
C(2,B)
D(4,B)(3,C)
új állandókisebb
A cél állandó lett → kész
Routerek „hierarchiája”
• Core Gateway routerek: az INOC (Internet Network Operation Center) által kontrollált routerek:– az egész Internetre vonatkozó ismereteik
vannak (nincs default router fogalmuk),
Dr. Kovács Szilveszter © E. III. / 97.
vannak (nincs default router fogalmuk), – backbone hálózatokat formálnak.
Autonom rendszerek (AS)
• Autonom System (AS) csoportosítási egység:– olyan hálózatok és routerek csoportja, amit egy szervezet
üzemeltet, vagy– olyan hálózatok és routerek csoportja, amik azonos routing
politikát folytatnak.
• Az AS-ek INOC (Internet Network Operation Center) által kiadott AS számmal rendelkeznek.
• Az AS-eket Exterior Gateway (EG) –ek kötik össze
Dr. Kovács Szilveszter © E. III. / 98.
• Az AS-eket Exterior Gateway (EG) –ek kötik össze• Az AS-ek hirdetik saját hálózataik elérhetőségét más
AS-eknek• Az AS-en belül nem kell feltétlen az egész Internet
címtartományt ismerni (default router/út)• AS-en belüli lokális forgalom, topológiai változás nem
látszik kifelé
Exterior Gateway Protocol (EGP)
• EGP az a protokoll, amivel az Exterior Gateway-ek hirdetik elérhetőségi információikat szomszédaiknak és a Core Gateway-eknek
• Mindegyik gateway a saját hálózatából gyűjt információt és EGP-vel hirdeti szomszédainak.
Dr. Kovács Szilveszter ©
• Az EGP-nek 3 fő funkciója van:– Támogatja az új szomszédok fogadását.– Teszteli az EGP szomszádait (Hello Protocol).– Rendszeresen hálózat elérhetőségi információkat
cserélnek EGP szomszédaikkal (routing update).
Interior Gateway Protocols (IGP)
• Az IGP az AS-en belül használt routing protokoll (eltérhet az EGP-től).
• Routing Information Protocol (RIP),(Vector Distance Algorithm)az egyik legelterjedtebb IGP.
Dr. Kovács Szilveszter ©
• Open Shortest Path First Protocol (OSPF): Open standard uses the SPF algorithm.
Internet felépítés: IGP-EGP• AS-en belüli Intra-Domain
(Interior Gateway Protocol, IGP)– Lehet RIP/OSFP a méretektől, elvárásoktól függően
• AS-ek közötti Inter-Domain Exterior Gateway Protocol (EGP), vagyBorder Gatway Protocol (BGP)– Alap: egy default út ki az AS-ből egy nagy ISP-hez,
Dr. Kovács Szilveszter © E. III. / 101.
– Alap: egy default út ki az AS-ből egy nagy ISP-hez, (Gateway router fogalom)
– Újabb a BGP (Border Gatway Protocol)• Hálózat elérhetőségi információkat cserél
→ melyik AS milyen teljes útvonalon érhető el• Célja az AS-en átmenő forgalom minimalizálása• Képes kezelni
– multi homed AS-t (több helyre szétosztott AS),– üzleti/politikai szabályrendszereket.
Exterior Gateway Protocol
• EGP, RFC 904– AS-ek között útvonalválasztás, elérhetőségi
információk alapján– Régi, kifejlesztésekor még hierarchikus volt az
Internet.– Alapvetően vector-distanceprotokoll
Dr. Kovács Szilveszter © E. III. / 102.
– Alapvetően vector-distanceprotokoll– Nem véd a hurokképződés ellen, nincsenek védelmi
mechanizmusai
Border Gateway Protocol• Egy AS szempontjából a forgalom lehet
– helyi (local traffic), az illető AS-ből indul, vagy abba érkezik
– átmenő (transit traffic)
• BGP célja ⇒ az átmenő forgalom minimalizálása– Lehetővé teszi a szabályalapú (policy based) routolást⇒ az AS adminisztrátorok meghatározzák, hogy több lehetséges út esetén melyiket válassza
Dr. Kovács Szilveszter © E. III. / 103.
lehetséges út esetén melyiket válassza– A BGP (mint a RIP) távolságokat továbbít a
szomszédainak, de a teljes utat(AS-ek sorozata) is megadjaaz egyes cél AS-ekhez
AS1 AS2
AS3 IGPEGP/BGP
IGPIGP
Border Gateway Protocol
• BGP, RFC 1771• Az EGP hiányosságait küszöböli ki• CIDR (Classless Inter-Domain Routing) támogatás
(hatékony cím aggregáció)• Konfigurálni kell a BGP szomszédokat, nincs
„szomszéd felfedezés”
Dr. Kovács Szilveszter © E. III. / 104.
„szomszéd felfedezés”• TCP fölött fut (179-es port), megbízható
kapcsolatorientált transzportot feltételez• Nincs periodikus újraküldés, minden hallott útvonalat
megjegyeznek a routerek.• A hurokmentesség ellen path vektor módszert használ
(célig vezető AS-ek listája)
EBGP - IBGP
• Exterior BGP– AS-ek között
• Interior BGP– AS-en belüli kapcsolatokra (pl. ha nem túl nagy,
nem érdemes az OSPF-et használni, de nem felel meg a RIP)
Dr. Kovács Szilveszter © E. III. / 105.
meg a RIP)
Interior Gateway Protocols (IGP)ICMP redirect (ICMP átirányítás):
• Valójában nem IGP, de itt érdemes megemlíteni
• Ha a router a kapott csomagot ugyanazon a hálón küldi tovább, mint amin kapta egy másik routernek
Dr. Kovács Szilveszter © E. III. / 106.
routernek⇒ ICMP redirect üzenet közvetlenül a feladónak azzal a címmel, akinek küldenie kellett volna helyette
• Támadási lehetőséget biztosíthat: Hamis redirect: „Man in the middle” hack
A RIP és RIP2• Routing Information Protocol
– az UDP-re épül, az 520-as porton.
• A szomszédok táblákat cserélnek– Konfigurálni kell, hogy ki kinek küldjön,
kit ől fogadjon
• A hálócímek (netid) mellet metrika (metric) a táblában (a netid hány ugrással érhető el)
Dr. Kovács Szilveszter © E. III. / 107.
(a netid hány ugrással érhető el)– A csatlakozó interfészeken állítani lehet az értékét (a többi ezt
küldi szét, illetve ennyivel növeli az azon irányból kapottakat)
• Metrika korlát (max. 16):– metric = 16 → nem elérhető
• A RIP a subneteket (maszkokat) nem hirdeti• a RIP2 (RIP Version 2) a subneteket is hirdeti.
Open Shortest Path First (Link Status)
• OSPF (közvetlenül az IP-re épül)• Nem távolságokat gyűjt, hanem a szomszédai elérhetőségét
vizsgálja (Link State Protocol)• Képes több utat kezelni (pl. Az IP Type of Service alapján)
• Az utakhoz súlyokat lehet rendelni (pl. ToS)
• Az azonos súlyúak között képes terhelésmegosztásra
Dr. Kovács Szilveszter © E. III. / 108.
• Az azonos súlyúak között képes terhelésmegosztásra• Hirdeti a subnet maszkot is• Minden (gateway) router periodikusan küld egy üzenetet,
tesztelve a link státust– az üzenet routing információkat nem tartalmaz.– Ha van válasz: a link él, a térképben ez jelezhető.– Ha nincs válasz: a link nem él.
OSPF komponensek
• Szomszédok felfedezése (Hello)• Default router (DR), tartalék (BDR) választás • Szomszédsági viszony (adjacencies) kialakítása• Adatbázis szinkronizáció (DS)• Él állapot terjesztés (LSA flooding)
Dr. Kovács Szilveszter © E. III. / 109.
• Él állapot terjesztés (LSA flooding)• Routing tábla számítás
• OSPF csomagok (fejrészében típus)– Hello – Database Description– Link-State Request/Reply/Ack
OSFP
OSPF AB szinkronizáció (DS)
• Kérés-válasz alapon– Link-State (LS) fejléceket cserélnek, és – ami hiányzik, lekérik LS Request-tel
• Link-State-Advertisment (terjesztés is, flooding-al)– minden szomszédnak továbbadom, kivéve ahonnan
Dr. Kovács Szilveszter © E. III. / 110.
– minden szomszédnak továbbadom, kivéve ahonnan jött, és Ack-ra várok
– Ha megkapta, nyugtázza, vagy újabb saját LS-t küld (ez is egyfajta „nyugta”)
– Ez „fa mentén terjedő, egyszer átlapolódó körbe-küldős elv”
• Minden LSA „öregszik”
OSFP
OSPF Hello
• A linkek állapotának folyamatos figyelésére
• Broadcast linken Default Router választás
Szomszédsági viszony• A szomszédaival, hangolja össze az adatbázisát,
Dr. Kovács Szilveszter © E. III. / 111.
• A szomszédaival, hangolja össze az adatbázisát, annak küldi az LSA-kat– A pont-pont link másik vége a szomszéd.– A broadcast linken a DR (default router) a szomszéd.
OSFP
Dinamikus
• Észreveszi, ha egy link megszakad– az adatkapcsolati réteg jelzi a router alkalmazásnak
(néhány sec), vagy– a Hello csomagok elmaradnak (40 sec).
• És egyből terjeszti a router az új topológiai állapotot.
Dr. Kovács Szilveszter © E. III. / 112.
állapotot.
OSFP
IP Version 4 - IP Version 6
• Az IPv4 címtartomány kimerülőfélben van (még a subnet maszkokkal + NATis)
• The current IPv4 Internet routing infrastructure is acombination of both flat and hierarchical routing ⇒ there are routinelyover 85,000 routes in the routing tables of Internet backbone
Dr. Kovács Szilveszter © E. III. / 113.
in the routing tables of Internet backbone routers .
IPv4
IP Version 4IPv4 address allocation history:• 1981 - IPv4 protocol published• 1985 ~ 1/16 total space• 1990 ~ 1/8 total space• 1995 ~ 1/4 total space• 2000 ~ 1/2 total space• 2005 ~ 1 ??
Dr. Kovács Szilveszter © E. III. / 114.
• 2005 ~ 1 ??
Despite increasingly intense conservation efforts since 1994• CIDR (classless inter-domain routing)• NAT (network address translation)Theoretical limit of 32-bit space: ~4 billion devices;• practical limit of 32-bit space: ~250 million devices
IPv4
IP Version 6• Az IPv6 címek 128 bitesek (16 byte),
2128 = 3.4 * 1038 cím– 665 * 1021 cím per négyzetméter a földön!– Ha 106/µs sebességgel osztanánk ki a címeket, 20 év alatt
tölthenénk be a címteret.– Könnyű subnet-eket kialakítani– Nem kell NAT
• Az IPv6 címek nem hoszt/node címek (mint IPv4), hanem
Dr. Kovács Szilveszter © E. III. / 115.
• Az IPv6 címek nem hoszt/node címek (mint IPv4), hanem „interfész” címek
• Egy hosztnak lehet több interfésze (címe)• IPv6 includes support for addresses of different “scope”
(többes címzések – link local, site local)• Unicast, multicast, anycast is lehet• Ugyanakkor nincs„broadcast”
IPv6
További IPv6 előnyök• New header format
• Large address space
• Efficient and hierarchical addressing and routing infrastructure
• Stateless and stateful address configuration
Dr. Kovács Szilveszter © E. III. / 116.
• Built-in security
• Better support for QoS
• New protocol for neighboring node interaction
• Extensibility
IPv6 előnyök - New header format• Keeping header overhead to a minimum. • By moving both non-essential fields and optional fields to
extension headers.• IPv4 headers and IPv6 headers are not interoperable.
IPv6 is not a superset of functionality that is backward compatible with IPv4.
Dr. Kovács Szilveszter © E. III. / 117.
• A host or router must use an implementation of both IPv4 and IPv6 in order to recognize and process both header formats.
• The new IPv6 header is only twice as large as the IPv4 header, even though IPv6 addresses are four times as large as IPv4 addresses.
IPv6 előnyök –Hierarchical Addressing and Routing
• Efficient, hierarchical, and summarizable routing infrastructure.
• Smaller routing tables.• “Aggregatable Global Unicast Addresses.”
Dr. Kovács Szilveszter © E. III. / 118.
• “Aggregatable Global Unicast Addresses.”
IPv6 előnyök –Stateless and Stateful Address Configuration
• Supports both stateful address configuration• Stateful: e.g. DHCP server• Stateless: hosts on a link automatically configure
themselves with IPv6 addresses for the link (called link-local addresses) and with addresses
Dr. Kovács Szilveszter © E. III. / 119.
(called link-local addresses) and with addresses derived from prefixes advertised by local routers.
• Even in the absence of a router, hosts on the same link can automatically configure themselves with link-local addresses and communicate without manual configuration.
IPv6 előnyök – Built-in Security
• Support for IPsec is an IPv6 protocol suite requirement.
• This requirement provides a standards-based solution for network security needs
Dr. Kovács Szilveszter © E. III. / 120.
based solution for network security needs and promotes interoperability between different IPv6 implementations.
IPv6 előnyök – Better Support for QoS• New fields in the IPv6 header define how traffic is
handled and identified. • Traffic identification using a Flow Label field in
the IPv6 header allows routers to identify and provide special handling for packets belonging to a flow, a series of packets between a source and
Dr. Kovács Szilveszter © E. III. / 121.
a flow, a series of packets between a source and destination.
• Because the traffic is identified in the IPv6 header, support for QoS can be achieved even when the packet payload is encrypted through IPsec.
IPv6 előnyök –New Protocol for Neighboring Node Interaction
• The Neighbor Discovery protocolfor IPv6 is a series of Internet Control Message Protocol for IPv6 (ICMPv6) messages that manage the interaction of neighboring nodes (nodes on the same link).
Dr. Kovács Szilveszter © E. III. / 122.
nodes (nodes on the same link). • Neighbor Discovery replaces the broadcast-
based Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and ICMPv4 Redirect messages with efficient multicast and unicast Neighbor Discovery messages.
IPv6 előnyök – Extensibility
• IPv6 can easily be extended for new features by adding extension headers after the IPv6 header.
• Unlike options in the IPv4 header, which
Dr. Kovács Szilveszter © E. III. / 123.
• Unlike options in the IPv4 header, which can only support 40 bytes of options, the size of IPv6 extension headers is only constrained by the size of the IPv6 packet.
IPv4 - IPv6 összevetés
Source and destination addresses are 32 bits (4 bytes) in length.
Source and destination addresses are 128 bits (16 bytes) in length.
IPsec support is optional. IPsec support is required.
No identification of packet flow for Packet flow identification for QoS
IPv4 IPv6
Dr. Kovács Szilveszter © E. III. / 124.
No identification of packet flow for QoS handling by routers is present within the IPv4 header.
Packet flow identification for QoS handling by routers is included in the IPv6 header using the Flow Label field.
Fragmentation is done by both routers and the sending host.
Fragmentation is not done by routers, only by the sending host.
Header includes a checksum. Header does not include a checksum.
IPv4 - IPv6 összevetés
Header includes options. All optional data is moved to IPv6 extension headers.
Address Resolution Protocol (ARP) uses broadcast ARP Request frames to resolve an IPv4 address to a link layer address.
ARP Request frames are replaced with multicast Neighbor Solicitation messages. “Neighbor Discovery.”
IPv4 IPv6
Dr. Kovács Szilveszter © E. III. / 125.
layer address.
Internet Group Management Protocol (IGMP) is used to manage local subnet group membership.
IGMP is replaced with Multicast Listener Discovery (MLD) messages. “Multicast Listener Discovery.”
ICMP Router Discovery is used to determine the IPv4 address of the best default gateway and is optional.
ICMP Router Discovery is replaced with ICMPv6 Router Solicitation and Router Advertisement messages and is required. “Neighbor Discovery.”
IPv4 - IPv6 összevetésIPv4 IPv6
Broadcast addresses are used to send traffic to all nodes on a subnet.
There are no IPv6 broadcast addresses. Instead, a link-local scope all-nodes multicast address is used.
Must be configured either manually or through DHCP.
Does not require manual configuration or DHCP. “Address Autoconfiguration.”
Uses host address (A) resource records in the Domain Name System to map
Uses host address (AAAA) resource records in the Domain Name System
Dr. Kovács Szilveszter © E. III. / 126.
in the Domain Name System to map host names to IPv4 addresses.
records in the Domain Name System to map host names to IPv6 addresses.
Uses pointer (PTR) resource records in the IN-ADDR.ARPA DNS domain to map IPv4 addresses to host names.
Uses pointer (PTR) resource records in the IP6.INT DNS domain to map IPv6 addresses to host names.
Must support a 576-byte packet size (possibly fragmented).
Must support a 1280-byte packet size (without fragmentation). “IPv6 MTU.”
IPv6 – Link Layer Enkapszuláció
Dr. Kovács Szilveszter © E. III. / 127.
IPv6 – Ethernet II Enkapszuláció
Dr. Kovács Szilveszter © E. III. / 128.
• EtherType field: 0x86DD(IPv4 esetén 0x800). • Minimális IPv6 csomagméret: 46 byte• Maximális IPv6 csomagméret: 1,500 byte
IPv6 – IEEE 802.3 Enkapszuláció
Dr. Kovács Szilveszter © E. III. / 129.
• Sub-Network Access Protocol (SNAP) header• EtherType field: 0x86DD• Minimális IPv6 csomagméret: 38 byte• Maximális IPv6 csomagméret: 1,492 byte
IPv6 – Címzés: Format Prefix (FP)
Dr. Kovács Szilveszter © E. III. / 130.
IPv6 – Címzés: Jelölés
• Preferred form (16 byte): – FEDC:BA98:7654:3210:FEDC:BA98:7654:3210– 1080:0:0:0:0:8:800:200C:417A
• Compressed form:– 1080::8:800:200C:417A
Dr. Kovács Szilveszter © E. III. / 131.
– 1080::8:800:200C:417A– 0:0:0:0:0:0:0:1 ==> ::1 (Unicast Loopback address)– FF01:0:0:0:0:0:0:42 ==> FF01::42 (Multicast address)– 0:0:0:0:0:0:0:0 ==> :: (The unspecified address)
IPv6 – Címzés: Kompatibilis címek• IPv4-kompatibilis cím
– 0:0:0:0:0:0:193.6.5.73 ==> ::193.6.5.73– 0:0:0:0:0:0:w.x.y.z ==> ::w.x.y.z – Csak akkor, ha IPv4/IPv6 dual stack.– Ha IPv4-kompatibilis címet adnak meg úgy, mint
egy IPv6 cél címet, akkor az IPv6 forgalom automatikusan IPv4 fejrészt kap és az IPv4
Dr. Kovács Szilveszter © E. III. / 132.
automatikusan IPv4 fejrészt kap és az IPv4 hálózaton küldik a cél felé.
• IPv4-mapped address– 0:0:0:0:0:FFFF:193.6.5.73 ==> ::FFFF:193.6.5.73– Csak belső reprezentáció, senki sem küld ilyet.– Az IPv6 node jelöli így a csak IPv4 node-ot
IPv6 – Címzés: Kompatibilis címek• 6to4 cím
– 2002::/16 cím 32 bites publikus IPv4 node címmel, egy 48-bites prefixet alkot.
– Pl: 193.6.5.73 esetén (Hexában: C1.6.5.49)2002:C106:0549::/48
– Két IPv4 és IPv6 dual stack node között használják, ha azok IPv4 routing infrastruktúra felett kommunikálnak .
Dr. Kovács Szilveszter © E. III. / 133.
azok IPv4 routing infrastruktúra felett kommunikálnak . – A 6to4 egy RFC 3056 szerinti tunnel technika.
• Az IPv6 nem használ maszkot, csak prefixet.
IPv6 – Címzés: Cím típusok
Dr. Kovács Szilveszter © E. III. / 134.
IPv6 – Címzés: Unicast címek
• Aggregatable global unicast addresses• Link -local addresses• Site-local addresses• Special addresses
Dr. Kovács Szilveszter © E. III. / 135.
(loopback, unspecified compatible)
IPv6 – Aggregatable global unicast addresses
• TLA ID – Top-Level Aggregation Identifier– Highest level in the routing hierarchy (called default-free routers) – Administered by IANA for long haul Internet service providers
Dr. Kovács Szilveszter © E. III. / 136.
– Administered by IANA for long haul Internet service providers assigned to the routing region
• Res – Bits that are reserved for future use• NLA ID – Next-Level Aggregation Identifier.
– Az intézmény azonosítására szolgál.
• SLA ID – Site-Level Aggregation Identifier.– Az SLA ID az intézményen belüli alhálózatok azonosítására szolgál.
• Interface ID – Egy alhálózaton belül az interface-t azonosítja.
IPv6 – Miskolci Egyetem Hbone 6Net• 2001:0738:6001::/48
inet6num: 2001:0738:6001::/48netname: UNI-MISKOLCdescr: University of Miskolcdescr: Miskolci Egyetemdescr: H-3515 Miskolc Egyetemvaroscountry: HUadmin-c: LB18-RIPE
• person: Laszlo Ballaaddress: University of Miskolcaddress: Miskolci Egyetemaddress: Miskolc Egyetemvarosaddress: H-3515 MISKOLC-Egytemvarosaddress: Hungaryphone: +36 46 565111 ext. 1012fax-no: +36 46 363450e-mail: szkballa@uni-miskolc.hunic-hdl: LB18-RIPEchanged: hostmaster@iif.hu 19920705changed: hostmaster@iif.hu 20020103source: RIPE
person: Szilveszter Kovacsaddress: University of Miskolcaddress: Miskolci Egyetemaddress: H-3515 Miskolc-Egyetemvarosaddress: Hungaryphone: +36 46 565111 ext. 2108
Dr. Kovács Szilveszter © E. III. / 137.
admin-c: LB18-RIPEtech-c: SK38-RIPEtech-c: NB12-RIPEstatus: ASSIGNEDremarks: ourid=445mnt-by: NIIF6-MNTsource: RIPEchanged: hostmaster6@iif.hu 20030103
phone: +36 46 565111 ext. 2108fax-no: +36 46 563450e-mail: szkszilv@uni-miskolc.hunic-hdl: SK38-RIPEnotify: hostmaster@iif.huchanged: szkszilv@uni-miskolc.hu 19960502changed: hostmaster@iif.hu 20020103source: RIPE
person: Norbert Burmeisteraddress: University of Miskolcaddress: Miskolci Egyetemaddress: H-3515 Miskolc-Egyetemvarosaddress: Hungaryphone: +36 46 565111 ext. 1070fax-no: +36 46 563450e-mail: szkburma@uni-miskolc.hunic-hdl: NB12-RIPEnotify: hostmaster@iif.huchanged: hostmaster@iif.hu 19920705changed: hostmaster@iif.hu 20020103source: RIPE
IPv6 – Link-Local unicast addresses
• A link-local címek a Neighbor Discovery eljáráshoz kellenek és mindig automatikusan konfigurálódnak,
Dr. Kovács Szilveszter © E. III. / 138.
még akkor is, ha semmilyen más unicast cím sem létezik.
• A link-local címek prefix-e mindig FE80::/64
IPv6 – Site-Local unicast addresses
• A link-local címekkel ellentétben, asite-local címek nem automatikusan konfigurálódnak, hanem vagy
Dr. Kovács Szilveszter © E. III. / 139.
állapotmentes (stateless), vagy állapot alapú (stateful) cím konfigurációval kell megadni azokat.
• A site-local címek esetén az első 48-bit mindig ugyanazzal a FEC0::/48 címmel kezdődik.
• A fix 48 bitet követi a 16-bites subnet identifier (Subnet ID field).
IPv6 – Multicast címek
• Flags– RFC 2373, jelenleg csak: Transient (T) flag. (legalsó bit)– 0: multicast address is a permanently assigned (well-known) multicast
address allocated by the Internet Assigned Numbers Authority (IANA).
FF
Dr. Kovács Szilveszter © E. III. / 140.
address allocated by the Internet Assigned Numbers Authority (IANA).FF01:: - FF0F:: reserved, well-known addresses
– 1: transient (non-permanently-assigned) multicast address.
• Scope: – 0: Reserved, 1: Node-local scope, 2: Link-local scope, 5: Site-local scope, – 8: Organization-local scope, E: Global scope, F: Reserved– Pl. FF02::2 link-local scope. (Az IPv6 router-ek nem továbbítját)
• Group ID : A multicast csoport egyedi azonosítója
IPv6 – Multicast címek• Speciális node multicastcímek:
– FF01::1 (node-local scope all-nodesmulticast address)– FF02::1 (link-local scope all-nodesmulticast address)
• Speciális router multicast címek:– FF01::2 (node-local scope all-routersmulticast address)– FF02::2 (link -local scope all-routers multicast address)
Dr. Kovács Szilveszter © E. III. / 141.
– FF02::2 (link -local scope all-routers multicast address)– FF05::2 (site-local scope all-routersmulticast address)
IPv6 – Multicast címek (módosítás)
• However, because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast MAC
FF
Dr. Kovács Szilveszter © E. III. / 142.
addresses, RFC 2373 recommends assigning the Group ID from the low order 32 bits of the IPv6 multicast address and setting the remaining original group ID bits to 0.
• By using only the low-order 32 bits, each group ID maps to a unique Ethernet multicast MAC address.
IPv6 – Solicited-Node Multicast Address• A cím felfejtés (address resolution) során elősegíti a hatékony
hálózati címhez tartozó adatkapcsolati cím lekérdezést. • Az IPv6 Neighbor Solicitation üzenetethasznál a cím felfejtéshez
(address resolution).• Local-link scope all-nodes multicast címzés helyett
solicited-node multicast címzést használ.• A solicited-node multicast címet azFF02::1:FF00:0/104 prefixből
és a felfejtendő IPv6 cím utolsó 24-bit jébők képzi. Pl:
Dr. Kovács Szilveszter © E. III. / 143.
és a felfejtendő IPv6 cím utolsó 24-bit jébők képzi. Pl:– Node A link-local címe FE80::2AA:FF:FE28:9C5A
valamint hallgat az ehhez tartozó solicited-node multicastcímre:FF02::1:FF28:9C5A
– Ha Node B keresi a Node A link-local címéhez FE80::2AA:FF:FE28:9C5A tartozó link-layer címet, akkor Neighbor Solicitation üzenetet külda FF02::1:FF28:9C5A solicited node multicast címre.
– Mivel Node A hallgat erre a címre, megválaszolja azt B-nek az unicastNeighbor Advertisementüzenettel
IPv6 – Anycast Address
• Az anycast címeket több interfészhez is hozzá lehet rendelni. • Packets addressed to an anycast address are forwarded by the
routing infrastructure to the nearest interfaceto which the anycast address is assigned.
Dr. Kovács Szilveszter © E. III. / 144.
anycast address is assigned.• Anycast addresses are assigned out of the unicast address space
and the scope of an anycast address is the scope of the type of unicast addressfrom which the anycast address is assigned.
• All router interfaces attached to a subnet are assigned the Subnet-Router anycast addressfor that subnet.
• The Subnet-Router anycast address is used for communication with one of multiple routers attached to a remote subnet
IPv6 – Addresses for a Host• Egy IPv6 host-hozaz alábbiunicast címek vannak
hozzárendelve:– A link-local address for each interface– Unicast addresses for each interface(which could be a site-
local address and one or multiple aggregatable global unicast addresses)
– The loopback address(::1) for the loopback interface
Dr. Kovács Szilveszter © E. III. / 145.
– The loopback address(::1) for the loopback interface
• Valamennyi host hallgat az alábbimulticast címekre:– The node-local scope all-nodesmulticast address (FF01::1)– The link-local scope all-nodesmulticast address (FF02::1)– The solicited-node address for each unicast addresson each
interface– The multicast addresses of joined groupson each interface.
IPv6 – Addresses for a Router• Egy IPv6 router az alábbiunicast címek vannak hozzárendelve:
– A link-local address for each interface– Unicast addressesfor each interface (which could be a site-local address
and one or multiple aggregatable global unicast addresses)– A Subnet-Router anycastaddress– Additional anycast addresses (optional)– The loopback address(::1) for the loopback interface
• Valamennyi router hallgat az alábbimulticast címekre:
Dr. Kovács Szilveszter © E. III. / 146.
• Valamennyi router hallgat az alábbimulticast címekre:– The node-local scope all-nodesmulticast address (FF01::1)– The node-local scope all-routersmulticast address (FF01::2)– The link-local scope all-nodesmulticast address (FF02::1)– The link-local scope all-routersmulticast address (FF02::2)– The site-local scope all-routersmulticast address (FF05::2)– The solicited-node address for each unicast addresson each interface– The multicast addresses of joined groupson each interface
IPv6 – Interface ID• A 64 bit prefix alatti egyedi 64 bites IF cím• RFC 2373: valamennyi 001-111 prefixű unicast címnek EUI-64
(IEEE) kompatibilis IF ID címének kell lennie.
EUI-48:(MAC)
Dr. Kovács Szilveszter © E. III. / 147.
EUI-64:
• U/L bit – 0: Universal, 1: Locally administred address• I/G bit – 0: Individual (unicast), 1: Group (multicast) address
IPv6 – Interface ID• Az Interface ID képzése az EUI-64 alapján:
EUI-64:
U/L bitet invertálni kell → így:
Dr. Kovács Szilveszter © E. III. / 148.
IPv6Interface ID
U/L bitet invertálni kell → így:1: Universal, 0: Locally administred address
Lokálisan adminisztrált Interface ID -k esetén tehát a 7. bitnek 0-nak kell lennie ⇒
Mapping IPv6 Multicast Addresses to Ethernet Addresses
Dr. Kovács Szilveszter © E. III. / 149.
Pl:• Link-local scope all-nodes multicast address of
FF02::1 ⇒ 33-33-00-00-00-01• Solicited-node address of
FF02::1:FF3F:2A1C⇒ 33-33-FF-3F-2A-1C– Remember that the solicited-node address is the prefix
FF02::1:FF00:0/104and the last 24-bits of the unicast IPv6 address
IPv6 – Header tervezési megfontolások• Felismerhető, egyszerűsített fejrész formátum.
• Csökkentse a gyakori esetek csomag-feldolgozási költségeit.
• A címmező méretének növekedése ellenére a fejrész overhead maradjon alacsony.
Dr. Kovács Szilveszter © E. III. / 150.
• Támogassa a rugalmasan bővíthető fejrész opciók használatát.
• A 64-bites feldolgozási architektúrára legyen optimalizálva (Headers are 64-bit aligned)
IPv6 – Header – forma• Fix méretű IPv6 Header
– Az IPv4-el ellentétben – az opciók nincsenek 40 byte-ra korlátozva
• Az alap fejrészben kevesebb mező van– Faster processing of basic packets
• 64-bitre illesztett fejrész/opciók
Dr. Kovács Szilveszter © E. III. / 151.
• 64-bitre illesztett fejrész/opciók
• Hatékony opció feldolgozás– Az opció mezőket csak akkor kell feldolgozni, ha léteznek.– Processing of most options limited performed only at
destination
IPv6 – Header – feldolgozási sebesség• A Network Layer-ből eltűnik az ellenőrző összeg
– Az adatkapcsolati réteg megbízhatóbbá vált– A felsőbb rétegekben kötelező a hibaellenőrzés
Pl: TCP, UDP, ICMPv6
• A hálózatban nincs további csomag fregmentáció– Csökkenti a routerek terhelését
Dr. Kovács Szilveszter © E. III. / 152.
– Csökkenti a routerek terhelését– Egyszerűbb hardver implementáció– Könnyű Layer 3 switching of IP
• Minimum link MTU is 1280 bytes– Az IPv4-ben ez 68 byte volt.
IPv6 – Basic Header(RFC 2460 )IPv4
IPv6 20 bytes ⇒ 40 bytes
• Version: 0110, azaz 6• Traffic Class: IPv6 Class of Priority
(mint IPv4 TOS), még nincs definiálva
Dr. Kovács Szilveszter © E. III. / 153.
(mint IPv4 TOS), még nincs definiálva• Flow label: adatfolyam azonosító
For non-default quality of service connections. Default: Flow Label = 0.
• Payload Length: a csomag hasznos mérete, max. 65535 byte– ha hosszabb: Payload Length = 0 ésJumbo Payload option in the Hop-by-Hop Options Extension Header.
• Next Header: a következő extension header típusa
• Hop limit: ugrásszámláló (csökken, 0 eldob)
Next Header– 0:Hop-by-Hop Options Header,6:TCP, 17:UDP, 43:Routing Header, 44:Fragment Header, 58:ICMPv6, 59:No next header, 60:Destination Options Header
IPv6 – Extension Headers (RFC 2460 )
Dr. Kovács Szilveszter © E. III. / 154.
• Delivery and forwarding options are moved to extension headers. • The only extension header that must be processed at each
intermediate router is the Hop-by-Hop Options extension header
IPv6 – Extension Headers (RFC 2460 )
More Fragments
Dr. Kovács Szilveszter © E. III. / 155.
• Minden Extension Header-ben van egy Next Header, ami a következő típusa.
More FragmentsFlag
IPv6 – Extension Headers (pl. Routing Header)
Node D
Dr. Kovács Szilveszter © E. III. / 156.
• A Routing extension header használható a loose source route meghatározására (az útvonal listája a célig).
I2
Node D
IPv6 – Extension Headers (RFC 2460 )
• Hop-by-hop options header (type:0)– jumbo payload (csomagméret > 65535)
→ az eredeti Payload Lenght:0 – helyette a kiegészítő fejlécben 32 bit hossz (max 4 terabyte) hasznos csomagméret
– router alert: routernek szóló információ
• Routing header– loose source routing (mezők a kívánt út IP címeinek)
Dr. Kovács Szilveszter © E. III. / 157.
– loose source routing (mezők a kívánt út IP címeinek)
• Fragment header– Az IPv6-ban, csak a forrás darabolhatja a küldendő
adatokat (payload). If the payload submitted by the upper layer protocol is larger than the link or path MTU, then IPv6 fragments the payload at the source and uses the Fragment extension header to provide reassembly information.
IPv6 – ICMPv6
• IPv6 does not provide facilities for reporting errors. • Instead, IPv6 uses Internet Control Message Protocol
version 6 (ICMPv6).• Error Messages:
– Destination Unreachable– Packet Too Big – Time Exceeded
Dr. Kovács Szilveszter © E. III. / 158.
– Time Exceeded– Parameter Problem
• Informational Messages:– Echo Request/Reply– De nincs forrásfolytás (Source Quench)
• Multicast Listener Discovery (MLD)• Neighbor Discovery (ND)
ICMPv6 - Path MTU Discovery• The sending node assumes that the path MTU is the link
MTU of the interface on which the traffic is being forwarded.
• The sending node sends IPv6 packets at the path MTU size.• If a router on the path is unable to forward the packet over
a link with a link MTU that is smaller than the size of the packet, it discards the IPv6 packet and sends an ICMPV6
Dr. Kovács Szilveszter © E. III. / 159.
packet, it discards the IPv6 packet and sends an ICMPV6 Packet Too Bigmessage back to the sending node. The ICMPV6 Packet Too Big message contains the link MTUof the link on which the forwarding failed.
• The sending node sets the path MTUfor packets being sent to the destination to the value of the MTU field in the ICMPv6 Packet Too Bigmessage.
ICMPv6 - Multicast Listener Discovery• MLD is a set of messages exchanged by routers and nodes,
enabling routers to discoverthe set of multicast addresses for which there are listening nodesfor each attached interface.
Multicast Listener Query:• Used by a router to query a link for multicast listeners.
– The General Queryis used to query for multicast listeners of all multicast addresses.
– Multicast-Address-Specific Queryis used to query for multicast listeners of a specific multicast address.
Dr. Kovács Szilveszter © E. III. / 160.
listeners of a specific multicast address.
Multicast Listener Report:• Used by a multicast listener to either report interest in
receiving multicast traffic for a specific multicast address or to respond to a Multicast Listener Query.
Multicast Listener Done:• Used by a multicast listener to report that it is no longer
interestedin receiving multicast traffic for a specific multicast address.
ICMPv6 - Neighbor Discovery (ND)ND is used by hoststo:• Discover neighboring routers.• Discover addresses, address prefixes, and other configuration
parameters.ND is used by routers to:• Advertise their presence, host configuration parameters, and
on-link prefixes.
Dr. Kovács Szilveszter © E. III. / 161.
• Inform hosts of a better next-hopaddress to forward packets for a specific destination.
ND is used by nodesto:• Resolve the link-layer addressof a neighboring node to which
an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed.
• Determine whether a neighbor is still reachable.
ICMPv6 - Address Resolution Example• Host A has an Ethernet MAC addressof
00-AA-00-11-11-11and a corresponding link-local addressof FE80::2AA:FF:FE 11:1111.
• Host B has an Ethernet MAC addressof 00-AA-00-22-22-22and a corresponding link -local addressof
Dr. Kovács Szilveszter © E. III. / 162.
and a corresponding link -local addressofFE80::2AA:FF:FE 22:2222.
• To send a packet to Host B, Host A must use address resolution to resolve Host B’s link-layer address.
• Based on Host B’s IP address, Host A sends a solicited-node multicast Neighbor Solicitationto the address of FF02::1:FF22:2222
ICMPv6 - Address Resolution Example
Based on Host B’s IP address, Host A sends a solicited-node multicast Neighbor Solicitation to the address of
FF02::1:FF22:2222
Dr. Kovács Szilveszter © E. III. / 163.
ICMPv6 - Address Resolution Example
Host B responds with a unicast Neighbor Advertisementmessage
Dr. Kovács Szilveszter © E. III. / 164.
ICMPv6 - Duplicate Address Detection• IPv6 nodes use the Neighbor Solicitation message to detect
duplicate address use on the local link.• In the duplicate address detection Neighbor Solicitation
message, the Source Address field in the IPv6 header is set to the unspecified address (::).– The address being queried for duplication cannot be used until it is
determined that there are no duplicates.
• In the Neighbor Advertisement reply to a duplicate address detection Neighbor Solicitation message, the Destination
Dr. Kovács Szilveszter © E. III. / 165.
detection Neighbor Solicitation message, the Destination Address in the IP header is set to thelink-local scope all-nodes multicast address (FF02::1). – The Solicited flagin the Neighbor Advertisement message is set to 0. – Because the senderof the duplicate address detection Neighbor
Solicitation message is not using the desired IP address, it cannot receive unicast Neighbor Advertisements.
– Therefore, the Neighbor Advertisement is multicast.
• Duplikáció esetén a Node nem használja a duplikált címet
ICMPv6 - Duplicate Address DetectionPl:
Dr. Kovács Szilveszter © E. III. / 166.
ICMPv6 - Duplicate Address DetectionPl:
Dr. Kovács Szilveszter © E. III. / 167.
ICMPv6 - Router Discovery• Router discovery is the process through which nodes attempt to discover
the set of routers on the local link.• IPv6 routers periodically send a Router Advertisementmessage on the
local link advertising their existence as routers. – They also provide configuration parameters such as default hop limit, MTU,
and prefixes.
• Active IPv6 hosts on the local link receive the Router Advertisementmessages and use the contents to maintain the default router list, the prefix list, and other configuration parameters.
Dr. Kovács Szilveszter © E. III. / 168.
prefix list, and other configuration parameters.• A host that is starting up sends a Router Solicitation message to the link-
local scope all-routers multicast address(FF02::2).• Upon receipt of a Router Solicitation message, all routers on the local link
send a unicast Router Advertisement messageto the node that sent the Router Solicitation.
• The node receives the Router Advertisement messages and uses their contents to build the default router and prefix lists and set other configuration parameters.
ICMPv6 - Router DiscoveryPl:
link-local scope all-routers multicast address
Dr. Kovács Szilveszter © E. III. / 169.
ICMPv6 - Router DiscoveryPl:
Dr. Kovács Szilveszter © E. III. / 170.
ICMPv6 – Redirect Function
• Routers use the redirect function to inform originating hosts of a better first-hop neighborto which traffic should be forwarded for a specific destination.
• Redirect messages are only sent by the first routerin the path between the originating host and the
Dr. Kovács Szilveszter © E. III. / 171.
the path between the originating host and the destination and like ICMPv6 error messages are rate limited.
• Hosts never send Redirect messagesand routers never update routing tables based on the receipt of a Redirect message
ICMPv6 – Redirect Function• The originating host forwards a unicast packet to its default router.
• The router processes the packet and notes that the address of the originating host is a neighbor. Additionally, it notes that the addresses of both the originating host and the next-hop are on the same link.
• The router forwards the packet to the appropriate next-hop address.
• The router sends the originating host a Redirect message. In the Target Address field of the Redirect messageis the next-hop address of the node to which the originating host should send packetsaddressed to the destination.
• For packets redirected to a router, the Target Address field is set to the link-
Dr. Kovács Szilveszter © E. III. / 172.
• For packets redirected to a router, the Target Address field is set to the link-local address of the router. For packets redirected to a host, the Target Address field is set to the destination address of the packet originally sent.
• The Redirect message includes the Redirected Header option. It might also include the Target Link-Layer Address option.
• Upon receipt of the Redirect message, the originating host updates the destination address entry in the destination cache with the address in the Target Address field. If the Target Link-Layer Address option is included in the Redirect message, its contents are used to create or update the corresponding neighbor cache entry.
ICMPv6 – Redirect Function Pl:
site-local
link-local
Dr. Kovács Szilveszter © E. III. / 173.
ICMPv6 – Redirect Function Pl:
Dr. Kovács Szilveszter © E. III. / 174.
ICMPv6 – Redirect Function Pl:
link-local address of the router
Dr. Kovács Szilveszter © E. III. / 175.
Irodalom
• RFC 1058 Routing Information Protocol• RFC 1723 RIP Version 2• RFC 2328 OSPF Version 2• RFC 1771 BGP-4• J. T. Moy: OSPF: Anatomy of an Internet Routing
Protocol Addison-Wesley, 1998
Dr. Kovács Szilveszter © E. III. / 176.
Protocol Addison-Wesley, 1998• EIGRP: www.cisco.com/warp/public/457/7.html• IBM Redbooks:
www.redbook.ibm.com/abstracts/gg243376.html
Recommended