Számítógép hálózatok tervezése és üzemeltetése Címek, címkiosztás, routing (IPv4, IPv6)

Számítógép hálózatok tervezése és üzemeltetése Címek, címkiosztás, routing (IPv4, IPv6) 2013/2014. tanév, II. félév Dr. Kovács Szilveszter E-mail: [email protected] Informatikai Intézet 106. sz. szoba Tel: (46) 565-111 / 21-06 Dr. Kovács Szilveszter ©

EII. IV. / 1.

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.5 10100100.01101011.10000110.00000101 (bin) 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

Dr. Kovács Szilveszter ©

EII. IV. / 2.

IP címosztályok • Hierarchia: hálózat cím + hoszt cím (netid+hostid) 0 netid hostid • Class A 1

0.0.0.0 - 127.255.255.255

• Class B

7

10

128.0.0.0 - 191.255.255.255

• Class C 192.0.0.0 - 223.255.255.255

• Class D (többes címzés) 224.0.0.0 - 239.255.255.255

• Class E 240.0.0.0 - 247.255.255.255

2

24 netid

bits hostid

14

16

bits

110

netid

hostid

3

21

8

1110

Group id. (Multicast)

4 11110

bits

28

bits

Lefoglalva (későbbi felh.)

5

27

bits

multicast: többes címzés ⇒ az üzenet a multicast csoport minden tagjának szól (broadast → mindenkinek szól) IPv4


EII. IV. / 3.

IP címtér Oszt.+hálózati Hálózatok bitek száma száma

Osztály A B C D Multicast

7

Gép bitek száma

Gépek száma

Címmező foglalás

24

224 - 2 = 16777214

49,21% 24,99%

1 + 7

2 - 2 = 126

2 + 14

214 = 16384

16

216 - 2 = 65534

3 + 21

221 = 2097152

8

28 - 2 = 254

12,40%

4 + 28

228 = 268435456

-

-

6,25%

32 - 4

228 - 1 = 268435455

6,25%

E Fenntartva IPv4

4

-


EII. IV. / 4.

Speciális címek és jelentésük • Nem minden cím osztható ki állomáscímnek Hálózat bitek

Gép bitek

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

x

..0..

Ez a logikai hálózat. Korábban logikai broadcast.

x

..1..

127.0.0

x

224.0.0.2

-

IPv4

Jelentés

Directed broadcast, mindenki ezen a távoli hálózaton. Távolról MAC unicast keretben kell Loopback, a helyi TCP/IP stack pszeudó címe a hoszton belül. A hálózaton nem fordulhat elő. Multicast, az összes router ezen a hálózaton van.


EII. IV. / 5.

IPv4 Multicast Címek Reserved for addressing multicast groups – 224.0.0.0 to 239.255.255.255. Link local – 224.0.0.0 to 224.0.0.255 (Example: routing information exchanged by routing protocols) Globally scoped addresses – 224.0.1.0 to 238.255.255.255 (Example: 224.0.1.1 has been reserved for Network Time Protocol)

Lokális (Privát) IPv4 Címek Private address blocks are: • Hosts that do not require access to the Internet can use private addresses

10.0.0.0 to 10.255.255.255 (10.0.0.0/8) 172.16.0.0 to 172.31.255.255 (172.16.0.0/12) 192.168.0.0 to 192.168.255.255 (192.168.0.0/16) Shared address space addresses: • Not globally routable • Intended only for use in service provider networks • Address block is 100.64.0.0/10

Speciális IPv4 Címek • Network and Broadcast addresses – within each network the first and last addresses cannot be assigned to hosts • Loopback address – 127.0.0.1 a special address that hosts use to direct traffic to themselves (addresses 127.0.0.0 to 127.255.255.255 are reserved) • Link-Local address – 169.254.0.0 to 169.254.255.255 (169.254.0.0/16) addresses can be automatically assigned to the local host • TEST-NET addresses – 192.0.2.0 to 192.0.2.255 (192.0.2.0/24) set aside for teaching and learning purposes, used in documentation and network examples • Experimental addresses – 240.0.0.0 to 255.255.255.254 are listed as reserved

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


EII. IV. / 9.

Alhálózat (subnet) bevezetése 32 bits

• Az eredeti felosztás

hhhhhhhh ggggggggggggggggggg netid

hostid

32 bits

• A subnet maszkkal az – értékes biteket kijelöljük

A subnet maszk: n db 1-es bit és 32-n db 0-s bit hhhhhhhh sssssssssssssss ggggggg netid

subnetid

hostid

Kiterjesztett hálózati azonosító IPv4


EII. IV. / 10.

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: – 193.6.5.0/24 • 193.6.5.0 • 255.255.255.0

IPv4

Osztály A B C


Prefix /8 /16 /24

Netmask 255.0.0.0 255.255.0.0 255.255.255.0

EII. IV. / 11.

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

– A maszkot is kell továbbítani (plussz 4 byte az útvonalválasztási információkban) – De az útvonalválasztás egyszerűsödhet (pl. hálózatok összefogása „szupernetting”)

IPv4


EII. IV. / 12.

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űvelet levá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 hosszabb – Pl. /28: 255.255.255.240, akkor • 28 bits: net • 4 bits: host

32 bits 111…

..11

24 b: netid

1111

0000

4b: snettid 4b: hostid

28 b: netid

• 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


EII. IV. / 13.

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 11000001|00000110|00000101|000xxxxx 11000001|00000110|00000101|001xxxxx 11000001|00000110|00000101|010xxxxx 11000001|00000110|00000101|011xxxxx 11000001|00000110|00000101|100xxxxx 11000001|00000110|00000101|101xxxxx 11000001|00000110|00000101|110xxxxx 11000001|00000110|00000101|111xxxxx

IPv4

Címtartomány 193.6.5.0/27 193.6.5.32/27 193.6.5.64/27 193.6.5.96/27 193.6.5.128/27 193.6.5.160/27 193.6.5.192/27 193.6.5.224/27

Megjegyzés Subnet 0/All zeros * Subnet 1 Subnet 2 Subnet 3 Subnet 4 Subnet 5 Subnet 6 Subnet 7/All ones *

* Ezeket régen nem volt szab használni! Dr. Kovács Szilveszter ©

EII. IV. / 14.

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 11000001|00000110|00000101|10000000 11000001|00000110|00000101|10000001 11000001|00000110|00000101|10000010 11000001|00000110|00000101|10000011 … 11000001|00000110|00000101|100111101 11000001|00000110|00000101|100111110 11000001|00000110|00000101|100111111

IPv4

IP cím 193.6.5.128 193.6.5.129 193.6.5.130 193.6.5.131 … 193.6.5.157 193.6.5.158 193.6.5.159


Megjegyzés Subnet azonosító Gép 1 Gép 2 Gép 3 … Gép 29 Gép 30 Subnet broadcast

EII. IV. / 15.

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 továbbítsa a csomagokat Maszk (bin) Maszk (dec) • Az aggregációhoz a címkiosztásnak követnie kell a topológiai feltételeket .128 10000000

– 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

11000000 11100000 11110000 11111000 11111100 11111110

IPv4


.192 .224 .240 .248 .252 .254 EII. IV. / 16.

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 0.0.0.0./0 2.28.0.0/16 2.28.137.0/24 2.28.137.128/25 3.10.0.0/16 3.10.11.0/24

IPv4

Interface Serial 0 Serial 1 Serial 2 Ethernet 0 Serial 1 Serial 2

Next-hop 1.1.1.1 2.2.1.1 2.3.1.1 2.3.1.4 2.2.1.1 2.3.1.1

Target IP mask 0.0.0.0 2.28.0.0. 2.28.137.0 2.28.137.128 2.28.0.0. 2.28.137.0


EII. IV. / 17.

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ózatazonosí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 – 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


EII. IV. / 18.

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

– több szomszédos A, B, C hálózat összevont útvonalválasztási bejegyzését

IPv4


EII. IV. / 19.

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. – Lokális címtartományok (IANA) (RFC 1918)

• 10.0.0.0 /8 • 172.16.0.0 /12 • 192.168.0.0 /16 IPv4


EII. IV. / 20.

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

• 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


EII. IV. / 21.

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ő IP cím(ek) Protokoll (TCP, UDP) Külső Port D=152.66.8.5 TCP(UDP)/d S=193.6.5.4 TCP(UDP)/sk

Belső IP cím(ek) Protokoll (TCP, UDP) Belső Port

Külső cím 193.6.5.4/32

Belső cím 10.1.2.0/24

D=152.66.8.5 TCP(UDP)/d S=10.1.2.4 TCP(UDP)/sb

NAT D= 10.1.2.4 TCP(UDP)/sb S= 152.66.8.5 TCP(UDP)/d

D= 193.6.5.4 TCP(UDP)/sk S= 152.66.8.5 TCP(UDP)/d Külső világ

IPv4

10.1.2.4

Belső világ


EII. IV. / 22.

Címfordítás, NAT Egyetlen 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. • 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


EII. IV. / 23.

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


EII. IV. / 24.

NAT - elnevezések

Basic 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 Destination 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 network on a publicly accessible IP address Masqueraded network • Az átcímzett (eltakart) hálózat neve IPv4


EII. IV. / 25.

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 level checksums (TCP, UDP) and correct tracking of which packets belong to which connection.

IPv4


EII. IV. / 26.

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 packet. • DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address.

IPv4


EII. IV. / 27.

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


EII. IV. / 28.

NAT – elnevezések: Dynamic network address translation Static NAT • One-to-one internal to public static IP address mapping Dynamic NAT • Uses a group of available public IP addresses.

IPv4


EII. IV. / 29.

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 through eAddr:ePort. Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.

IPv4


EII. IV. / 30.

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


EII. IV. / 31.

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


EII. IV. / 32.

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 destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back.

IPv4


EII. IV. / 33.

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 5389 with the title Session Traversal Utilities for NAT, retaining the same acronym.

IPv4


EII. IV. / 34.

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) IP address (NAT address) and port number that the NAT has allocated for the application's User 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


EII. IV. / 35.

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


EII. IV. / 36.

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


EII. IV. / 37.


• •

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


EII. IV. / 38.


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


EII. IV. / 39.


•

•

•

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


EII. IV. / 40.

Session Traversal Utilities for NAT (STUN)

IPv4


EII. IV. / 41.

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


EII. IV. / 42.

Az IP csomag 4

verzió

IHL

TOS (8)

Total length (16) flags

Header

Identification (16) TtL (8)

Protocol (8)

Fragment offset (13)

Header checksum (16)

Source IP Address (32) Destination IP Address (32) Options (if any * 32)

Data (x * 32)

IPv4


EII. IV. / 43.

20 bytes

4

4

verzió

4

IHL

Az IP csomag TOS (8)

Total length (16)

• 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: – D bit: Minimize delay (Pl. telnet) – T: Maximize throughput (Pl. Ftp data) egyszerre csak – R: Maximize reability (pl SNMP) egy bit lehet 1 – 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ájtokban 16 bit ⇒ IP datagram max. 65535 byte IPv4


EII. IV. / 44.

Az IP csomag Identification (16)

Flags


• 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 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). Dr. Kovács Szilveszter ©

EII. IV. / 45.

Az IP csomag TTL (8)

Protocol (8)


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


EII. IV. / 46.

4

verzió

IHL

TOS (8)

Total length (16) flags

Header

Identification (16) TtL (8)

Protocol (8)



Source IP Address (32) Destination IP Address (32) Options (if any * 32) Data (x * 32) • SA, DA (IP címek) • Opciók és adatok IPv4


EII. IV. / 47.

20 bytes

4

Az IP csomag

Az enkapszuláció

User Data

Application layer

App-H User Data

Network Applications TCP

TCP-H

UDP

Segment

D.gram

TCP szegmens

IP ARP

IP-H TCP-H

Appl Data

IP datagram

Packet

Ethernet Frame

Appl Data

E-H IP-H TCP-H 14

20

Appl Data

E-T

20

4

Ethernet frame (46-1500 byte)


EII. IV. / 48.

A viszaállítás (demultiplexálás) Network Applications TCP

ARP

App-H User Data

A cél port (SAP) cím szerint demultiplexál

TCP-H

UDP IP

User Data

Az IP Header Protocol értéke alapján IP-H demultiplexál

RARP Ethernet Frame

Az Ethernet kerettípus alapján

IP datagram

E-H

E-T Incoming frame

A TCP SAP, UDP SAP azonosítás: 16 bites port szám alapján (port number)


EII. IV. / 49.

Link Layer: Ethernet enkapszuláció (RFC 894) Ethernet frame 6

DA

6

SA

46-1500 byte

4

Type

Data+ Pad

CRC

0800

IP datagram

CRC

2

28

0806

ARP req/rep Pad CRC 28

8035

18 18

RARP req/rep Pad CRC

Ethernet kerettípus


EII. IV. / 50.

Link Layer: 802.3 enkapszuláció (RFC 1042) 802.3 frame 6

6

DA

SA

2

1

1

1

Len D S C

3

2

O Type

802.3 MAC Header

46-1500 byte

4

Data+ Pad

CRC

(mint az előző oldalon) 802.2 LLC 802.2 SNA Header Header

D: Destination SAP (AA) S: Source SAP (AA) C: Control (vezérlés) (03) O: Organisation Code (00) Type: Lásd Ethernet

LLC: Logical Link Control Header SNA: Sub Network Access Protocol Headre


EII. IV. / 51.

Link Layer: PPP enkapszuláció PPP frame

IP soros vonalon (nem csak IP) Point to Point Protocol 1 1 1 2 0-1500 2 1 • aszinkron, 8 bites adatok, IP datagram / F A C Prot CRC F • szinkron, bit orientált. control data A protokoll lehet: LCP (Link Control P) F: Flag (RFC 1548): szinkron:7E (bitbeszúrás: 01111110) Data link kapcsolat létrehozása, aszinkron: 7E, de karakter orientált tesztje, konfigurációja transzparens: adatok között NCP (Network Cont. Prot.) 7E: 0x7D=escape: 0x7E→7D,5E; (RFC 1332): adatok közt 0x7D→7D,5D; különböző hálózati protokollok 20h-nál kisebb →7D,20H+d (pl. IPX) átvitele PPP-n A: Address (FF)

C: Control (03) Prot: 0021: IP datagram

Nincs ARP ← ez pont-pont kapcsolat !

C021: Link Control Data 8021: Network Control Data Dr. Kovács Szilveszter ©

EII. IV. / 52.

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


EII. IV. / 53.

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! • 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. Dr. Kovács Szilveszter ©

EII. IV. / 54.

Az ARP (RFC 826) • A MAC címek nyerhetők: – Local Broadcast ARP_REQUEST küldése után a válaszokból ARP_REPLY (amiket azonnal cache-elni lehet) – Majd a későbbiekben a cache-ből (IP - MAC párok)

• A továbbiakhoz tegyük fel, hogy megvan a cél IP címe (Pl. DNS-ből)

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 Dr. Kovács Szilveszter ©

EII. IV. / 55.

További protokollok • Boot Protocol (RFC 1542) – MAC és IP cím statikus összerendelése – Kliens-szerver-relay_agent konfiguráció – UDP csomagokban request-reply

• Dynamic Host Configuration Protocol (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. DNS) jelezhető, BOOTP-vel felülről kompatibilis. Dr. Kovács Szilveszter ©

EII. IV. / 56.

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.

• 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. Dr. Kovács Szilveszter ©

EII. IV. / 57.

Az IP csomagok továbbítása Ha 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 • 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 Dr. Kovács Szilveszter ©

EII. IV. / 58.

Az IP csomagok továbbítása • Két host közös hálózaton (netid), közös adatkapcsolati réteg IPA: netA +hostA HostA

HostA→ HostB

IPB: netA +hostB HostB

Link Header

IP Header

Data

Dest: MACB Dest: IPB


EII. IV. / 59.

Az IP csomagok továbbítása • Két host különböző hálózaton 1: HostA IPA: netA +hostA

HostA→ RouterA Link Header

IP Header

Data

Dest: MACRA Dest: IPB

IPRA: netA +routerA Router IPRB: netB +routerB

2:

RouterB → HostB Link Header

IPB: netB +hostB HostB

IP Header

Data

Dest: MACB Dest: IPB Az IP csomag nem (alig (TTL+checksum)) változik, csak a Link Layer Header más. Dr. Kovács Szilveszter ©

EII. IV. / 60.

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.


EII. IV. / 61.

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 – 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. Dr. Kovács Szilveszter ©

EII. IV. / 62.

Routerek konfigurációja HostA

Router1

193.6.4.254

Router2 193.6.10.254 255.255.255.0

Cím: 193.6.10.1 Maszk: 255.255.255.0 Broadcast: 193.6.10.255 Def.Router: 193.6.10.254

Internet ISP 193.6.12.254

193.6.12.253 193.6.3.253 193.6.3.254 255.255.255.0 255.255.255.0

A gateway (router) címe mindig olyan, amit a saját hálóján közvetlenül elér. Ez a statikus kitöltési módja a routing tábláknak (static routing)

Router1 IP Route

193.225.4.6 (ISP)

Router3

193.225.4.5 255.255.255.252

Default

net id 193.6.12.0 193.6.4.0 0.0.0.0

mask 255.255.255.0 255.255.255.0 0.0.0.0

gateway 193.6.3.253 193.6.3.253 193.6.3.253

Router2 IP Route Default

net id 193.6.10.0 0.0.0.0

mask 255.255.255.0 0.0.0.0

gateway 193.6.3.254 193.6.12.254

Router3 IP Route

net id 193.6.3.0 193.6.4.0 193.6.10.0 0.0.0.0

mask 255.255.255.0 255.255.255.0 255.255.255.0 0.0.0.0

gateway 193.6.12.253 193.6.12.253 193.6.12.253 193.225.4.6

Default


EII. IV. / 63.

Az ICMP • Internet Control Message Protocol – Az alapvetően a hálózati réteggel kapcsolatos 20 üzenetek továbbítására

• Az ICMP enkapszuláció • ICMP message

IP header

ICMP message

IP datagramm

Type (8) Code (8)

Checksum (16)

Content (type és code függő tartalom)

• Típusok:

Checksum: a teljes ICMP üzenet ellenőrzése

– hibaüzenetek, – információk, – diagnosztikai üzenetek. ICMP


EII. IV. / 64.

ICMP példák Type 0 3

4 5

8 11

Code 0 0 1 3 4 0 0 1 0 0 1

Üzenet (RFC792) echo reply (ping) Destination unreachable Network unreachable Host unreachable Port unreachable Fregmentation is needed but don't fragment bit set Source quench: fojtócsomag (flow control) Redirect Redirect for network Redirect for host echo request (ping) Time exceed Time to live = 0 during transmit (traceroute) Time to live = 0 during reassembly

stb. ICMP


EII. IV. / 65.

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.

ICMP


EII. IV. / 66.

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) • 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 Dr. Kovács Szilveszter ©

EII. IV. / 67.

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 • • • • ICMP echo request/reply A küldő processz id-je

csomagvesztés detektálható, duplikáció detektálható, sorrendcsere detektálható, késletetési viszonyok változása (torlódás) detektálható. 0

78 Type: 0 v. 8

15 16

Code: 0

identifier

31 Checksum (16)

sequence number

Optional data (a szerver echózza) Dr. Kovács Szilveszter ©

0-tól számozza sorba - Elérhető-e - Mennyi idő alatt ér vissza a válasz EII. IV. / 68.

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 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. Dr. Kovács Szilveszter ©

EII. IV. / 69.

A traceroute • ICMP time exceeded: 0

78 Type: 11

15 16

Code: 0v.1

31 Checksum (16)

Unused = 0 IP header + első 8 byte

• ICMP UDP port unreachable: 0

78 Type: 3

15 16

Code: 3

31 Checksum (16)

Unused = 0 IP header (20byte) + UDP header első 8 byte


EII. IV. / 70.

IP Version 4 - IP Version 6 • Az IPv4 címtartomány kimerülőfélben van (még a subnet maszkokkal + NAT is) • The current IPv4 Internet routing infrastructure is a combination of both flat and hierarchical routing ⇒ there are routinely over 85,000 routes in the routing tables of Internet backbone routers .

IPv4


EII. IV. / 71.

IP Version 4 IPv4 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 ?? 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


EII. IV. / 72.

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


EII. IV. / 73.

További IPv6 előnyök • New header format • Large address space • Efficient and hierarchical addressing and routing infrastructure • Stateless and stateful address configuration • Built-in security • Better support for QoS • New protocol for neighboring node interaction • Extensibility


EII. IV. / 74.

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. • 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. Dr. Kovács Szilveszter ©

EII. IV. / 75.

IPv6 előnyök – Hierarchical Addressing and Routing • Efficient, hierarchical, and summarizable routing infrastructure. • Smaller routing tables. • “Aggregatable Global Unicast Addresses.”


EII. IV. / 76.

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 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. Dr. Kovács Szilveszter ©

EII. IV. / 77.

IPv6 előnyök – Built-in Security • Support for IPsec is an IPv6 protocol suite requirement. • This requirement provides a standardsbased solution for network security needs and promotes interoperability between different IPv6 implementations.


EII. IV. / 78.

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


EII. IV. / 79.

IPv6 előnyök – New Protocol for Neighboring Node Interaction • The Neighbor Discovery protocol for 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). • Neighbor Discovery replaces the broadcastbased Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and ICMPv4 Redirect messages with efficient multicast and unicast Neighbor Discovery messages. Dr. Kovács Szilveszter ©

EII. IV. / 80.

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 can only support 40 bytes of options, the size of IPv6 extension headers is only constrained by the size of the IPv6 packet.


EII. IV. / 81.

IPv4 - IPv6 összevetés IPv4

IPv6

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


EII. IV. / 82.


IPv6

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. Internet Group Management Protocol (IGMP) is used to manage local subnet group membership.

ARP Request frames are replaced with multicast Neighbor Solicitation messages. “Neighbor 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.”

IGMP is replaced with Multicast Listener Discovery (MLD) messages. “Multicast Listener Discovery.”


EII. IV. / 83.

IPv4


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. Uses host address (A) resource records in the Domain Name System to map host names to IPv4 addresses.

Does not require manual configuration or DHCP. “Address Autoconfiguration.” Uses host address (AAAA) resource 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.” Dr. Kovács Szilveszter ©

EII. IV. / 84.

IPv6 – Link Layer Enkapszuláció


EII. IV. / 85.

IPv6 – Ethernet II Enkapszuláció

• EtherType field: 0x86DD (IPv4 esetén 0x800). • Minimális IPv6 csomagméret: 46 byte • Maximális IPv6 csomagméret: 1,500 byte Dr. Kovács Szilveszter ©

EII. IV. / 86.

IPv6 – IEEE 802.3 Enkapszuláció

• • • •

Sub-Network Access Protocol (SNAP) header EtherType field: 0x86DD Minimális IPv6 csomagméret: 38 byte Maximális IPv6 csomagméret: 1,492 byte Dr. Kovács Szilveszter ©

EII. IV. / 87.

IPv6 – Címzés: Format Prefix (FP)


EII. IV. / 88.

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


EII. IV. / 89.

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 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 Dr. Kovács Szilveszter ©

EII. IV. / 90.

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. – A 6to4 egy RFC 3056 szerinti tunnel technika.

• Az IPv6 nem használ maszkot, csak prefixet.


EII. IV. / 91.

IPv6 – Címzés: Cím típusok


EII. IV. / 92.

IPv6 – Címzés: Unicast címek • • • • •

Aggregatable global unicast addresses Link-local addresses Site-local addresses Unique Local addresses Special addresses: – Loopback: ::1/128 vagy ::1 – Unspecified: ::/128 vagy :: – Compatible: ::w.x.y.z/128 Dr. Kovács Szilveszter ©

EII. IV. / 93.

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 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. Dr. Kovács Szilveszter ©

EII. IV. / 94.

IPv6 – Miskolci Egyetem Hbone 6Net •

• 2001:0738:6001::/48 inet6num: 2001:0738:6001::/48 netname: UNI-MISKOLC descr: University of Miskolc descr: Miskolci Egyetem descr: H-3515 Miskolc Egyetemvaros country: HU admin-c: LB18-RIPE tech-c: SK38-RIPE tech-c: NB12-RIPE status: ASSIGNED remarks: ourid=445 mnt-by: NIIF6-MNT source: RIPE changed: [email protected] 20030103

person: address: address: address: address: address: phone: fax-no: e-mail: nic-hdl: changed: changed: source:

Laszlo Balla University of Miskolc Miskolci Egyetem Miskolc Egyetemvaros H-3515 MISKOLC-Egytemvaros Hungary +36 46 565111 ext. 1012 +36 46 363450 [email protected] LB18-RIPE [email protected] 19920705 [email protected] 20020103 RIPE

person: address: address: address: address: phone: fax-no: e-mail: nic-hdl: notify: changed: changed: source:

Szilveszter Kovacs University of Miskolc Miskolci Egyetem H-3515 Miskolc-Egyetemvaros Hungary +36 46 565111 ext. 2108 +36 46 563450 [email protected] SK38-RIPE [email protected] [email protected] 19960502 [email protected] 20020103 RIPE

person: address: address: address: address: phone: fax-no: e-mail: nic-hdl: notify: changed: changed: source:

Norbert Burmeister University of Miskolc Miskolci Egyetem H-3515 Miskolc-Egyetemvaros Hungary +36 46 565111 ext. 1070 +36 46 563450 [email protected] NB12-RIPE [email protected] [email protected] 19920705 [email protected] 20020103 RIPE


EII. IV. / 95.

IPv6 – Link-Local unicast addresses

• A link-local címek a Neighbor Discovery eljáráshoz kellenek és mindig automatikusan konfigurálódnak, még akkor is, ha semmilyen más unicast cím sem létezik. • A link-local címek prefix-e mindig FE80::/64 • Unique-local addresses (RFC 4193) - routed within private network: FC00::/7 • FC00::/8 not decided, FD00::/8 defined for /48 prefixes, setting the 40 least-significant bits to a random bits Dr. Kovács Szilveszter ©

EII. IV. / 96.

IPv6 – Site-Local unicast addresses

• A link-local címekkel ellentétben, a site-local címek nem automatikusan konfigurálódnak, hanem vagy á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). • Site-Local használata nem ajánlott RFC 3879. Dr. Kovács Szilveszter ©

EII. IV. / 97.

IPv6 – Unique Local unicast addresses (ULA) – Similar to private addresses for IPv4. – Used for local addressing within a site or between a limited number of sites. – In the range of FC00::/7 to FDFF::/7.


EII. IV. / 98.

IPv6 – Multicast címek FF

• 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). 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 Dr. Kovács Szilveszter ©

EII. IV. / 99.

IPv6 – Multicast címek • Speciális node multicast címek: – FF01::1 (node-local scope all-nodes multicast address) – FF02::1 (link-local scope all-nodes multicast address)

• Speciális router multicast címek: – FF01::2 (node-local scope all-routers multicast address) – FF02::2 (link-local scope all-routers multicast address) – FF05::2 (site-local scope all-routers multicast address)


EII. IV. / 100.

IPv6 – Multicast címek (módosítás) FF

• However, because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast MAC 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. Dr. Kovács Szilveszter ©

EII. IV. / 101.

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 üzenetet haszná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 az FF02::1:FF00:0/104 prefixből és a felfejtendő IPv6 cím utolsó 24-bitjébők képzi. Pl: – Node A link-local címe FE80::2AA:FF:FE28:9C5A valamint hallgat az ehhez tartozó solicited-node multicast cí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üld a FF02::1:FF28:9C5A solicited node multicast címre. – Mivel Node A hallgat erre a címre, megválaszolja azt B-nek az unicast Neighbor Advertisement üzenettel Dr. Kovács Szilveszter ©

EII. IV. / 102.

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 interface to which the 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 address from which the anycast address is assigned. • All router interfaces attached to a subnet are assigned the Subnet-Router anycast address for that subnet. • The Subnet-Router anycast address is used for communication with one of multiple routers attached to a remote subnet Dr. Kovács Szilveszter ©

EII. IV. / 103.

IPv6 – Addresses for a Host • Egy IPv6 host-hoz az alábbi unicast címek vannak hozzárendelve: – A link-local address for each interface – Unicast addresses for each interface (which could be a sitelocal address and one or multiple aggregatable global unicast addresses) – The loopback address (::1) for the loopback interface

• Valamennyi host hallgat az alábbi multicast címekre: – The node-local scope all-nodes multicast address (FF01::1) – The link-local scope all-nodes multicast address (FF02::1) – The solicited-node address for each unicast address on each interface – The multicast addresses of joined groups on each interface. Dr. Kovács Szilveszter ©

EII. IV. / 104.

IPv6 – Addresses for a Router • Egy IPv6 router az alábbi unicast 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) – A Subnet-Router anycast address – Additional anycast addresses (optional) – The loopback address (::1) for the loopback interface

• Valamennyi router hallgat az alábbi multicast címekre: – – – – – – –

The node-local scope all-nodes multicast address (FF01::1) The node-local scope all-routers multicast address (FF01::2) The link-local scope all-nodes multicast address (FF02::1) The link-local scope all-routers multicast address (FF02::2) The site-local scope all-routers multicast address (FF05::2) The solicited-node address for each unicast address on each interface The multicast addresses of joined groups on each interface Dr. Kovács Szilveszter ©

EII. IV. / 105.

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)

EUI-64:

• U/L bit – 0: Universal, 1: Locally administred address • I/G bit – 0: Individual (unicast), 1: Group (multicast) address Dr. Kovács Szilveszter ©

EII. IV. / 106.

IPv6 – Interface ID • Az Interface ID képzése az EUI-64 alapján: EUI-64:

IPv6 Interface 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 ⇒ Dr. Kovács Szilveszter ©

EII. IV. / 107.

Mapping IPv6 Multicast Addresses to Ethernet Addresses

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/104 and the last 24-bits of the unicast IPv6 address Dr. Kovács Szilveszter ©

EII. IV. / 108.

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. • 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)


EII. IV. / 109.

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


EII. IV. / 110.

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


EII. IV. / 111.

IPv6 – Basic Header (RFC 2460 ) IPv4 IPv6

• • •

•

• •

Version: 0110, azaz 6 Traffic Class: IPv6 Class of Priority (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 és Jumbo 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)

20 bytes ⇒ 40 bytes

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 Dr. Kovács Szilveszter © EII. IV. / 112.

IPv6 – Extension Headers (RFC 2460 )

• 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 Dr. Kovács Szilveszter ©

EII. IV. / 113.

IPv6 – Extension Headers (RFC 2460 )

More Fragments Flag

• Minden Extension Header-ben van egy Next Header, ami a következő típusa. Dr. Kovács Szilveszter ©

EII. IV. / 114.

IPv6 – Extension Headers (pl. Routing Header)

Node D

I2

• A Routing extension header használható a loose source route meghatározására (az útvonal listája a célig). Dr. Kovács Szilveszter ©

EII. IV. / 115.

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)

• 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. Dr. Kovács Szilveszter ©

EII. IV. / 116.

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 Parameter Problem

• Informational Messages: – Echo Request/Reply – De nincs forrásfolytás (Source Quench)

• Multicast Listener Discovery (MLD) • Neighbor Discovery (ND) Dr. Kovács Szilveszter ©

EII. IV. / 117.

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 Packet Too Big message back to the sending node. The ICMPV6 Packet Too Big message contains the link MTU of the link on which the forwarding failed. • The sending node sets the path MTU for packets being sent to the destination to the value of the MTU field in the ICMPv6 Packet Too Big message. Dr. Kovács Szilveszter ©

EII. IV. / 118.

ICMPv6 - Multicast Listener Discovery • MLD is a set of messages exchanged by routers and nodes, enabling routers to discover the set of multicast addresses for which there are listening nodes for each attached interface. Multicast Listener Query: • Used by a router to query a link for multicast listeners. – The General Query is used to query for multicast listeners of all multicast addresses. – Multicast-Address-Specific Query is used to query for multicast 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 interested in receiving multicast traffic for a specific multicast address. Dr. Kovács Szilveszter ©

EII. IV. / 119.

ICMPv6 - Neighbor Discovery (ND) ND is used by hosts to: • 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. • Inform hosts of a better next-hop address to forward packets for a specific destination. ND is used by nodes to: • Resolve the link-layer address of 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. Dr. Kovács Szilveszter ©

EII. IV. / 120.

ICMPv6 - Address Resolution Example • Host A has an Ethernet MAC address of 00-AA-00-11-11-11 and a corresponding link-local address of FE80::2AA:FF:FE11:1111. • Host B has an Ethernet MAC address of 00-AA-00-22-22-22 and a corresponding link-local address of FE80::2AA:FF:FE22: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 Solicitation to the address of FF02::1:FF22:2222 Dr. Kovács Szilveszter ©

EII. IV. / 121.

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


EII. IV. / 122.

ICMPv6 - Address Resolution Example Host B responds with a unicast Neighbor Advertisement message


EII. IV. / 123.

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 Address in the IP header is set to the link-local scope allnodes multicast address (FF02::1). – The Solicited flag in the Neighbor Advertisement message is set to 0. – Because the sender of 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 Dr. Kovács Szilveszter ©

EII. IV. / 124.

ICMPv6 - Duplicate Address Detection Pl:


EII. IV. / 125.

ICMPv6 - Duplicate Address Detection Pl:


EII. IV. / 126.

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 Advertisement message 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 Advertisement messages and use the contents to maintain the default router list, the prefix list, and other configuration parameters. • A host that is starting up sends a Router Solicitation message to the linklocal 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 message to 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. Dr. Kovács Szilveszter ©

EII. IV. / 127.

ICMPv6 - Router Discovery Pl: link-local scope all-routers multicast address


EII. IV. / 128.

ICMPv6 - Router Discovery Pl:


EII. IV. / 129.

ICMPv6 – Redirect Function • Routers use the redirect function to inform originating hosts of a better first-hop neighbor to which traffic should be forwarded for a specific destination. • Redirect messages are only sent by the first router in the path between the originating host and the destination and like ICMPv6 error messages are rate limited. • Hosts never send Redirect messages and routers never update routing tables based on the receipt of a Redirect message Dr. Kovács Szilveszter ©

EII. IV. / 130.

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 message is the next-hop address of the node to which the originating host should send packets addressed to the destination. For packets redirected to a router, the Target Address field is set to the linklocal 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. Dr. Kovács Szilveszter ©

EII. IV. / 131.

ICMPv6 – Redirect Function Pl:

site-local link-local


EII. IV. / 132.



EII. IV. / 133.


link-local address of the router


EII. IV. / 134.

Számítógép hálózatok tervezése és üzemeltetése Címek, címkiosztás, routing (IPv4, IPv6)

Recommend Documents