IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Usuari:Rafelmelich / NIVELL XARXA I NIVELL DE TRANSPORT < Usuari:Rafelmelich

NIVELL XARAXA I NIVELL DE TRANSPORT

CONCEPTES

  • El nivell de xarxa és l'encarregat de realitzar les tasques bàsiques per transportar les dades des d'un origen fins a una destinació a traves d'una xarxa
  • Model de referència OSI
    • Nivell 3. Nivell de xarxa
  • Pila de protocols TCP/IP
    • Nivell 2.Nivell d'Internet

Rafelmelichxarxaosiwan.png

Xarxes WAN

  • Wide Area Network
    • El nivell de xarxa treballa amb tot tipus de xarxes però adquireix la seva raó de ser quan treballem amb múltiples xarxes.
    • A la xarxa formada per aquest subconjunt de xarxes o subxarxes de l'anomena WAN (Wide Area Network)

Rafelmelichxarxaosiwan1.png

  • Xarxa "WAN" del centre

Rafelmelichxarxaosiwan2.png

Nivell d'Internet (Nivell 2 TCP/IP) - Nivell de xarxa (Nivell 3 OSI)

Control de la xarxa/subxarxa

  • Treballa amb blocs de dades de xarxa (3-PDU) anomenats paquets.

Funcions

  • Encaminament: Determinar la ruta (nodes de xarxa pels quals circular) més adequada per als paquets
  • Identificació: Els nodes han de tenir una identificació única que els permeti distingir dels altres nodes i localitzar-los a la xarxa. ADREÇES IP
  • Control de la congestió: determina quins són els camins menys congestionats (similar al trànsit rodat) ICMP
  • Interconnexió de Xarxes
  • Protocol: IP (Internet Protocol)
    • No te control de flux (velocitat), perquè de ja se'n encarrega un altre.
    • Tampoc té control de errors (ECRC)-(el control de errors el fa el TCP, protocol de capa superior)
    • l'IP ho fa lo millor que pot.


Encaminament

Encaminament

  • És el mecanisme pel qual en una xarxa els paquets es fan arribar d'un origen a una destinació seguint un camí o ruta concreta.
  • Cada node de la xarxa, quan rep un paquet a de prendre una decisió de que fer amb aquest paquet:
    • Quedar-se el paquet quan ell és el destinatari
    • Enviar al paquet cap a un altre node veí
    • O potser eliminar el paquet per què és incorrecta.

Routers/Encaminadors

  • Els routers o encaminadors són els dispositius/nodes de xarxa que s'encarreguen de l'encaminament a nivell de xarxa.

Tipologies

  • Típic de les xarxes WAN
    • A diferència de les xarxes LAN, el medi no és compartit.

Rafelmelichxarxaosiwan3.png

  • UDP= Nivell de port (port que entrarà/sortirà del SO)
  • IP= SO (Sistema Operatiu).
  • Frame header= a nivell de targeta de xarxa.

si la teva velocitat es de una mega mai podrem arribar a aquesta ja que fan falta els headers a las paquets que enviem ho sigui que serà

  • Enllaços punt a punt (PPP)
    • Cada node de la xarxa és un router (encaminador).

Rafelmelichxarxaosiwan4.png

  • Encaminador= router els paquest només passen per nell, per enviar-ho a una direcció a d'obrir el paquet veure mac per veure la url
    • en el cas del switch= hauria d'obrir-lo per veure la mac on ho ha d'enviar
    • En el cas del HUB=simplement conmmuta no obre el paquet ja que treballa a nivell de MAC


Control de congestió

  • Posar captura de control de la congestió
  • Control de la congestió: determina quins són els camins menys congestionats (similar al trànsit rodat)


Protocol IP

Internet Protocol

  • IP és el protocol més utilitzat a nivell de xarxa
  • La versió actual del protocol és la versió 4 (Ipv4) i data del 1980
  • IP és un protocol Best Effort (El millor esforç possible)
    • Intenta transmetre els paquets el millor possible per la xarxa però no pot assegurar:
    • Que els paquets arribin
    • Que els paquets arribin correctament (sense errors)
    • Que els paquets arribin en ordre
    • El nivell superior (transport) és qui fa el control d'errors
  • La Internet Engineering Task Force (IETF) és qui s'encarrega de definir el protocol IP.

Història

  • TCP/IP va ser creat pel DoD (Departament of Defense) dels Estats Units amb l'objectiu de crear una xarxa que sobrevisques a qualsevol circumstància (per exemple un atac Nuclear).
  • La idea és que les comunicacions funcionin encara que un moment concret un o més nodes de xarxa no funcionin
  • IP a anat creixent a mesura que Internet anava creixent
    • Les primeres xarxes tenien molts pocs nodes
    • La primera versió d'IP era per a xarxes de com a màxim 25 màquines (32 màquines)
    • La següent versió era per a 24(16) xarxes i 28 (256) màquines per xarxa.
    • La versió actual suporta 232(4.294.967.296 màquines)
    • Actualment uns 4 billions d'adreces no són suficients adreces. S'està implantant poc a poc el protocol IPv6 amb 2128 (3,4x1038 màquines)
  • Creixement d'Internet i de les adreces IP
Posar captura


Repàs del format binari

  • ipcalc: calcula en binari la IP.
sudo apt-get install ipcalc
  • Per utilitzar el ipcalc
[email protected]:~$ ipcalc 192.168.204.118
Address:   192.168.204.118      11000000.10101000.11001100. 01110110
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.204.0/24     11000000.10101000.11001100. 00000000
HostMin:   192.168.204.1        11000000.10101000.11001100. 00000001
HostMax:   192.168.204.254      11000000.10101000.11001100. 11111110
Broadcast: 192.168.204.255      11000000.10101000.11001100. 11111111
Hosts/Net: 254                   Class C, Private Internet
  • Potències de base 2
    • Són els “nombres màgics” en informàtica
  • Exercici
    • Creu un full de càlcul com el de la dreta utilitzant OpenOffice
  • Formats
    • binari: 1011101
    • octal: 135
    • decimal: 93
    • hexadecimal: 5D
Posar captura de la taula


Conversió de binari a decimal

  • Cada bit té un pes diferent
    • El primer bit per l'esquerre val 1
    • Els següents bits dupliquen (multipliquen x2) el seu valor:
1024 512 256 128 64 32 16 8 4 2 1
0 0 0 0 1011101
64+16+8+4+1=93

Fragmentació

  • Per atacar els problemes de xarxa

ipmtu.png

ipfragmentationreassembly.png

RafelmelichIP1.png

EXEMPLE DE FRAGMENTACIÓ DE PAQUET'

RafelmelichIP2.png

MTU
  • En xarxes dividim en nivells.
  • Quan estem IP internet protocol.xarxa tipus nivell 3.Encarrega d'enviar paquets.
  • Per sobre nivell de transport.
  • Pert sota nivell d'enllaç (Ethernet).
  • Ethernet és la limitació.
  • Protocol IP dissenyat per treballar amb tot lo que hi hagi per sota.
  • A més gran el paquet, més carrega de dades pot portar, ara aixó té un problema si aquest està malament s'hauria de tornar a enviar. Valor de compromís ,Encara que tinguessim un ample de banda molt gran tindriem un problema de latència
  • Router Link MTU= 1200
  • Ethernet MTU=1500 bytes.

PRÀCTICA MTU Canviarem el tamany del paquet del ping amb la comanda ping -s a 3200 i el farem a la pàgina web de google. Podem veure la mida màxima de paquet 1472 menys del capçaleres 

Fem un ifconfig per veure el MTU establert màxim per Ethernet segons la nostra targeta de ret:
[email protected]:~$ ifconfig
eth2      Link encap:Ethernet  HWaddr 00:30:05:eb:3b:44  
          inet addr:192.168.204.118  Bcast:192.168.204.255  Mask:255.255.255.0
          inet6 addr: fe80::230:5ff:feeb:3b44/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41857 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25125 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:25276599 (25.2 MB)  TX bytes:5922485 (5.9 MB)
          Interrupt:23 Base address:0x4000 

[email protected]:~$ ping -s 1500 192.168.204.1

Si fem una captura amb el wireshark es pot observar: Rafelmelichwirepingmenoss.png


PRÀCTICA MTU

Canviarem el tamany del paquet del ping amb la comanda ping -s a 3200 i el farem a la pàgina web de google. Podem veure la mida màxima de paquet 1472 menys del capçaleres 

Fem un ifconfig per veure el MTU establert màxim per Ethernet segons la nostra targeta de ret:
[email protected]:~$ ifconfig
eth2      Link encap:Ethernet  HWaddr 00:30:05:eb:3b:44  
          inet addr:192.168.204.118  Bcast:192.168.204.255  Mask:255.255.255.0
          inet6 addr: fe80::230:5ff:feeb:3b44/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41857 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25125 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:25276599 (25.2 MB)  TX bytes:5922485 (5.9 MB)
          Interrupt:23 Base address:0x4000 

[email protected]:~$ ping -s 1500 192.168.204.1

Si fem una captura amb el wireshark es pot observar:

Rafelmelichwirepingmenoss.png

Si canviem el MTU de la targeta de ret i li assignem un valor superior (per exemple: 3000), podem provar de fer un ping amb un MTU superior. Però com és veurà a continuació aquest està "capat" pel switch. 

[email protected]:~$ ping -s 2000 -M do 192.168.204.1 
.
..
...
....
From 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)
CFrom 192.168.204.18 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 192.168.204.1 ping statistics ---
0 packets transmitted, 0 received, +3808 errors

Per tal de poder realitzar aquestes proves farem una connexió punt a punt (amb Joel), assignarem cadascun 

[email protected]:~$ iperf -s 192.168.204.118
iperf: ignoring extra argument -- 192.168.204.118
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.204.118 port 5001 connected with 192.168.204.169 port 34820
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   653 MBytes   547 Mbits/sec
^[email protected]:~$ iperf -s 192.168.204.118
iperf: ignoring extra argument -- 192.168.204.118
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.204.118 port 5001 connected with 192.168.204.169 port 34821
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   654 MBytes   548 Mbits/sec
^[email protected]:~iperf -s 192.168.204.118
iperf: ignoring extra argument -- 192.168.204.118
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.204.118 port 5001 connected with 192.168.204.169 port 34822
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   780 MBytes   654 Mbits/sec
^[email protected]:~$ iperf -s 192.168.204.118
iperf: ignoring extra argument -- 192.168.204.118
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
^[email protected]:~$ iperf -s 192.168.204.118
iperf: ignoring extra argument -- 192.168.204.118
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
^[[A^[email protected]:~$ iperf -s 192.168.204.178
iperf: ignoring extra argument -- 192.168.204.178
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.204.178 port 5001 connected with 192.168.204.169 port 49841
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   779 MBytes   653 Mbits/sec
^[email protected]:~$ iperf -s 192.168.204.178
iperf: ignoring extra argument -- 192.168.204.178
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
^[email protected]:~$ iperf -s 192.168.204.178
iperf: ignoring extra argument -- 192.168.204.178
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
^[email protected]:~$ iperf -s 192.168.204.178
iperf: ignoring extra argument -- 192.168.204.178
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.204.178 port 5001 connected with 192.168.204.169 port 49842
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   839 MBytes   703 Mbits/sec
Encapsulassió

Rafelmeñlichencapsulació.png

  • PDU: a més baixem més gran.
  • A d'alt de tot tenim un la payload (la persona que escriu o el programa)
  • Després aplicació.
  • Desprès protocol.
  • PDU de capa 2 frame || en IP datagrama || al nivell TCP/UDP segments

MTU

RafelmelichIP2.png

  • MTU=Maximun Transmission Unit.
  • No va en paquets va en Trames-Frames.
  • Fragmentació dela paquets
  • Al passar de
  • Ethernet Link MTU= 2200

Adreces IP

Paquest IP

Configuració IP de nodes de xarxa

  • Paràmetres necessaris per configurar un paràmetre de xarxa

Paràmetres imprescindibles

  • Adreça IP -> Representa un identificador (identificador únic,universal: URI:universal resource identificator || URL: URI + Locator)
    • Totes les URL són úniques.
    • IP: Idetifica i indica la localització: permet arribar al recurs.
  • Màscara de xarxa -> Permet identificar l'equip en la xarxa "local". (quina magnitud té la xarxa on estic)

Paràmetres “opcionals”

  • Porta d'enllaç: a nivell de xarxa local que necessita accés a internet
  • Servidors de DNS: a nivell d'usuaris

http://acacha.org/mediawiki/index.php/Nivell_d%27internet_TCP/IP http://acacha.org/mediawiki/index.php/Nivell_de_transport_TCP/IP

Altres paràmetres

  • Adreça de difusió, adreça de xarxa, adreça MAC

Màscara de xarxa

  • La màscara determina quins bits estan reservats a la xarxa i quins bits a les màquines.
[email protected]:~$ ipcalc 192.168.204.118
Address:   192.168.204.118      11000000.10101000.11001100. 01110110
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000 -> Només podem utilitzar els últims 8 bits (dreta).els altres són els paràmetres
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>La ma
Network:   192.168.204.0/24     11000000.10101000.11001100. 00000000
HostMin:   192.168.204.1        11000000.10101000.11001100. 00000001
HostMax:   192.168.204.254      11000000.10101000.11001100. 11111110
Broadcast: 192.168.204.255      11000000.10101000.11001100. 11111111
Hosts/Net: 254                   Class C, Private Internet

La 1º IP i la última de la màquina estan reservades. Ojo no vol dir que la 1º sigui la 0 ni la última 255

[email protected]:~$ ipcalc 192.168.204.118/25
Address:   192.168.204.118      11000000.10101000.11001100.0 1110110
Netmask:   255.255.255.128 = 25 11111111.11111111.11111111.1 0000000
Wildcard:  0.0.0.127            00000000.00000000.00000000.0 1111111
=>
Network:   192.168.204.0/25     11000000.10101000.11001100.0 0000000
HostMin:   192.168.204.1        11000000.10101000.11001100.0 0000001
HostMax:   192.168.204.126      11000000.10101000.11001100.0 1111110
Broadcast: 192.168.204.127      11000000.10101000.11001100.0 1111111
Hosts/Net: 126                   Class C, Private Internet
 
Quan més gran és la mascara més petita és la xarxa.

[email protected]:~$ ipcalc 192.168.204.118/30
Address:   192.168.204.118      11000000.10101000.11001100.011101 10
Netmask:   255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard:  0.0.0.3              00000000.00000000.00000000.000000 11
=>
Network:   192.168.204.116/30   11000000.10101000.11001100.011101 00
HostMin:   192.168.204.117      11000000.10101000.11001100.011101 01
HostMax:   192.168.204.118      11000000.10101000.11001100.011101 10
Broadcast: 192.168.204.119      11000000.10101000.11001100.011101 11
Hosts/Net: 2                     Class C, Private Internet
EXTREMS

Res:32/31/ ->30 sería la 1ª que té utilitat peruque 32 és inservible,31 com reservem 2 tampoc, la primera mascara útil és 30. 

[email protected]:~$ ipcalc 192.168.204.118/32
Address:   192.168.204.118      11000000.10101000.11001100.01110110 
Netmask:   255.255.255.255 = 32 11111111.11111111.11111111.11111111 
Wildcard:  0.0.0.0              00000000.00000000.00000000.00000000 
=>
Hostroute: 192.168.204.118      11000000.10101000.11001100.01110110 
Hosts/Net: 1                     Class C, Private Internet

[email protected]:~$ ipcalc 192.168.204.118/31
Address:   192.168.204.118      11000000.10101000.11001100.0111011 0
Netmask:   255.255.255.254 = 31 11111111.11111111.11111111.1111111 0
Wildcard:  0.0.0.1              00000000.00000000.00000000.0000000 1
=>
Network:   192.168.204.118/31   11000000.10101000.11001100.0111011 0
HostMin:   192.168.204.118      11000000.10101000.11001100.0111011 0
HostMax:   192.168.204.119      11000000.10101000.11001100.0111011 1
Hosts/Net: 2                     Class C, Private Internet, PtP Link RFC 3021

[email protected]:~$ ipcalc 192.168.204.118/30
Address:   192.168.204.118      11000000.10101000.11001100.011101 10
Netmask:   255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard:  0.0.0.3              00000000.00000000.00000000.000000 11
=>
Network:   192.168.204.116/30   11000000.10101000.11001100.011101 00
HostMin:   192.168.204.117      11000000.10101000.11001100.011101 01
HostMax:   192.168.204.118      11000000.10101000.11001100.011101 10
Broadcast: 192.168.204.119      11000000.10101000.11001100.011101 11
Hosts/Net: 2                     Class C, Private Internet
MÀXIM:
  • Passa el mateix però a la inversa
[email protected]:~$ ipcalc 192.168.204.118/0
INVALID MASK1:   0
 
Address:   192.168.204.118      11000000.10101000.11001100. 01110110
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.204.0/24     11000000.10101000.11001100. 00000000
HostMin:   192.168.204.1        11000000.10101000.11001100. 00000001
HostMax:   192.168.204.254      11000000.10101000.11001100. 11111110
Broadcast: 192.168.204.255      11000000.10101000.11001100. 11111111
Hosts/Net: 254                   Class C, Private Internet

[email protected]:~$ ipcalc 192.168.204.118/1
Address:   192.168.204.118      1 1000000.10101000.11001100.01110110
Netmask:   128.0.0.0 = 1        1 0000000.00000000.00000000.00000000
Wildcard:  127.255.255.255      0 1111111.11111111.11111111.11111111
=>
Network:   128.0.0.0/1          1 0000000.00000000.00000000.00000000
HostMin:   128.0.0.1            1 0000000.00000000.00000000.00000001
HostMax:   255.255.255.254      1 1111111.11111111.11111111.11111110
Broadcast: 255.255.255.255      1 1111111.11111111.11111111.11111111
Hosts/Net: 2147483646            Class B, In Part Private Internet
 
[email protected]:~$ ipcalc 192.168.204.118/2
Address:   192.168.204.118      11 000000.10101000.11001100.01110110
Netmask:   192.0.0.0 = 2        11 000000.00000000.00000000.00000000
Wildcard:  63.255.255.255       00 111111.11111111.11111111.11111111
=>
Network:   192.0.0.0/2          11 000000.00000000.00000000.00000000
HostMin:   192.0.0.1            11 000000.00000000.00000000.00000001
HostMax:   255.255.255.254      11 111111.11111111.11111111.11111110
Broadcast: 255.255.255.255      11 111111.11111111.11111111.11111111
Hosts/Net: 1073741822            Class C, In Part Multicast
 
[email protected]:~$ ipcalc 192.168.204.118/8
Address:   192.168.204.118      11000000. 10101000.11001100.01110110
Netmask:   255.0.0.0 = 8        11111111. 00000000.00000000.00000000
Wildcard:  0.255.255.255        00000000. 11111111.11111111.11111111
=>
Network:   192.0.0.0/8          11000000. 00000000.00000000.00000000
HostMin:   192.0.0.1            11000000. 00000000.00000000.00000001
HostMax:   192.255.255.254      11000000. 11111111.11111111.11111110
Broadcast: 192.255.255.255      11000000. 11111111.11111111.11111111
Hosts/Net: 16777214              Class C, In Part Private Internet
  • Finalitzar amb les dades de la transparència.


Subxarxes

  • La xarxa (Internet) està formada per subxarxes.
    • L'adreça de xarxa conjuntament amb la màscara de xarxa configuren les subxarxes.
  • Les subxarxes permeten aprofitar millor les IPS
    • Recurs limitat.
    • Millor organització jeràrquica.
  • Els routers connecten subxarxes.

Fitxer:Rafelmelichtrocals.png

  • PSTN (Public Switched Telephone Network)
    • La xarxa telefònica commutada (xarxa telefònica) també utilitza subxarxes.
    • No Telèfon: +34 93 894 05 50
    • +34: Codi de país (Espanya).
    • 93: Codi de província (Barcelona)
    • 894: Codi de ciutat/zona (Sitges)
    • 05 50: Número de l'abonat

Fitxer:RafelmelichPTSN.png

Sistema per Classes

(introduir la imatge de la piràmide de xarxes).

  • CLASSE A:
    • Comences per 0
    • Les més grans
    • La mitat de les IP són classe a (0.0.0.0 - 127.255.255.255)
  • CLASSE B:
    • Comences per 128-191
  • CLASSE C:
    • Comences per 192-223
  • CLASSE D:
    • Comences per 224-239
    • Especial: Multicast.
  • CLASSE E:
    • Comences per 240-255
    • Especial: Multicast.

Adreces IP Reservades

ICMP

  • Protocol de missages que serveix per controlar el protocol IP.
  • Protocol Core.
  • El Internet Control Message Protocol (ICMP) és un dels protocols core d'Internet (aka Internet Protocol Suite). És utilitzat pels sistemes operatius dels nodes d'una xarxa per enviar missatges d'error de comunicació entre nodes com per exemple que un node no esta accessible o un servei no està disponible.
  • El Ping és un dels més coneguts (host is alive)(apart ens dona latència,etc..)
  • No transporta dades, sinó missatges entre nodes.
  • Perque funcione necessita IP (o sigui que un switch no treballa amb ICMP ja que treballen en capa 2)

El sistema operatiu pot ser un SO d'estacions de treball com Windows o Linux, o altres sistemes més específics de nodes de xarxa com routers - routerOS, Cisco IOS, etc...)

Parts

Capçalera

ICMP és un protocol que corre sobre el protocol IP i no utilitza ni TCP ni UDP. Tots els paquets ICMP tenen una capçalera de mida de 8 bytes (64 bits) i una mida de les dades (payload) variable·

Els 4 primers Bytes de la capçalera (header) han de ser consistents:

The ICMP header starts after the IPv4 header. All ICMP packets will have an 8-byte header and variable-sized data section. The first 4 bytes of the header will be consistent. The first byte is for the ICMP type. The second byte is for the ICMP code. The third and fourth bytes are a checksum of the entire ICMP message. The contents of the remaining 4 bytes of the header will vary based on the ICMP type and code.<ref name="Forouzan" />

ICMP error messages contain a data section that includes the entire IP header plus the first 8 bytes of data from the IP datagram that caused the error message. The ICMP datagram is then encapsulated in a new IP datagram.<ref name="Forouzan" />

Bits 0–7 8–15 16–23 24–31
0 Type Code Checksum
32 Rest of Header

Rafelmelichmoooooa.png


  • Type – ICMP type as specified below.
  • Code – Subtype to the given type.
  • Checksum – Error checking data. Calculated from the ICMP header+data, with value 0 for this field. The checksum algorithm is specified in RFC 1071.
  • Rest of Header – Four byte field. Will vary based on the ICMP type and code.

ICMP error messages contain a data section that includes the entire IP header plus the first 8 bytes of data from the IP datagram that caused the error message. The ICMP datagram is then encapsulated in a new IP datagram.

Bits 0–7 8–15 16–23 24–31
0 Type Code Checksum
32 Rest of Header
  • Type – ICMP type as specified below.
  • Code – Subtype to the given type.
  • Checksum – Error checking data. Calculated from the ICMP header+data, with value 0 for this field. The checksum algorithm is specified in RFC 1071.
  • Rest of Header – Four byte field. Will vary based on the ICMP type and code.

Exercici Wireshark

  • Fem un ping i utilitzant el wireshrak fem una captura de paquets al eth2 (la meva targeta)
  • Posteriorment filtrem nomes els paquets ICMP i en seleccionem un per veure de les parts de que es componen
  • COLOCAR LES CAPTURES AMB EL WIRESHARK DE TYPE, CODE Y CHECKSUM

Tipus de missatges

PING
  • Es tracta d'una utilitat incorporada a molts sistemes operatius
  • Ping-Pong
  • Basada en sistemes de sonar
Linux
  • No satura, al contrari de Windows
  • Per aturar-lo ping -c
  • Sinó ctrl+c -> Close tanca ordenadament (kill a secas mata l'aplicació)
  • Sinó li diem res per defecte ocupa 64-capçalera 8bytes = 56 bytes de dades.
  • El ping l'enviem tot en un paquet el maxim d'espai que podem ocupar en un paquet 65335 bytes -20 bytes de la capçalera = 65515 bytes - 8 de la capçalera del ping = 65507 de payload.
Exercici
  • Fem un ping amb 
[email protected]:~$ ping 192.168.204.118 -s65508
Error: packet size 65508 is too large. Maximum is 65507
[email protected]:~$ ping 192.168.204.118 -s65507
PING 192.168.204.118 (192.168.204.118) 65507(65535) bytes of data.
65515 bytes from 192.168.204.118: icmp_req=1 ttl=64 time=0.152 ms
65515 bytes from 192.168.204.118: icmp_req=2 ttl=64 time=0.137 ms
65515 bytes from 192.168.204.118: icmp_req=3 ttl=64 time=0.142 ms
65515 bytes from 192.168.204.118: icmp_req=4 ttl=64 time=0.148 ms

Desactiva la proteccio per inundació del broadcast 

[email protected]:~$ sudo -i
[email protected]:~# echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
[email protected]:~#

Per comprovar que ara si podem veure els pings a totes del maquines del broadcast 

[email protected]:~# ping -b 192.168.204.255 
WARNING: pinging broadcast address
PING 192.168.204.255 (192.168.204.255) 56(84) bytes of data.
64 bytes from 192.168.204.118: icmp_req=1 ttl=64 time=0.053 ms
64 bytes from 192.168.204.115: icmp_req=1 ttl=64 time=0.178 ms (DUP!)
64 bytes from 192.168.204.102: icmp_req=1 ttl=64 time=0.190 ms (DUP!)
64 bytes from 192.168.204.107: icmp_req=1 ttl=64 time=0.195 ms (DUP!)
64 bytes from 192.168.204.112: icmp_req=1 ttl=64 time=0.199 ms (DUP!)
64 bytes from 192.168.204.208: icmp_req=1 ttl=64 time=3.27 ms (DUP!)
64 bytes from 192.168.204.204: icmp_req=1 ttl=64 time=8.08 ms (DUP!)
64 bytes from 192.168.204.118: icmp_req=2 ttl=64 time=0.059 ms
64 bytes from 192.168.204.112: icmp_req=2 ttl=64 time=0.173 ms (DUP!)
64 bytes from 192.168.204.102: icmp_req=2 ttl=64 time=0.185 ms (DUP!)
PING RATE LIMIT
[email protected]:~$ sudo ping -s 65505 -i 0 -b 192.168.204.255  
WARNING: pinging broadcast address
PING 192.168.204.255 (192.168.204.255) 65505(65533) bytes of data.
ping: sendmsg: Message too long
65513 bytes from 192.168.204.118: icmp_req=1 ttl=64 time=0.189 ms
ping: sendmsg: Message too long
65513 bytes from 192.168.204.118: icmp_req=2 ttl=64 time=0.071 ms



[email protected]:~$ sudo ping -f -b 192.168.204.255  
WARNING: pinging broadcast address
PING 192.168.204.255 (192.168.204.255) 56(84) bytes of data.
--- 192.168.204.255 ping statistics ---
710350 packets transmitted, 710350 received, +2280131 duplicates, 0% packet loss, time 111333ms
rtt min/avg/max/mdev = 0.005/10.187/3467.346/58.107 ms, pipe 22016, ipg/ewma 0.156/0.051 ms



[email protected]:~$ sudo -i
[email protected]:~# echo 10000 > /proc/sys/net/ipv4/icmp_ratelimit
[email protected]:~#

PRÀCTICA TCPDUMP

Amb una terminal realitzem un ping al gateway 

[email protected]:~$ ping 192.168.204.1

I amb un altre terminal fem un tcpdump per capturar els paquets i analitzar l'estructura dels mateixos. 

[email protected]:~$ sudo tcpdump -n -i eth2 icmp
[sudo] password for rafel: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 20:21:26.273705 IP 192.168.204.118 > 192.168.204.1: ICMP echo request, id   
8091, seq 22, length 64
24 packets captured
24 packets received by filter
0 packets dropped by kernel

Només ens deixa veure un resum dels paquets capturats (ping,pong) durant la captura.

Fer un TRACEROUTE és el mateix que fer un ping -nR xtec.cat 

[email protected]:~$ sudo traceroute xtec.cat
[sudo] password for rafel: 
traceroute to xtec.cat (213.176.163.147), 30 hops max, 60 byte packets
 1  192.168.204.1 (192.168.204.1)  0.305 ms  0.401 ms  0.397 ms
 2  routortosa01real.tortosa.guifi.net (109.69.15.2)  8.516 ms  8.532 ms  8.497 ms
 3  10.253.4.22 (10.253.4.22)  14.911 ms  14.819 ms  14.927 ms
 4  anella01.01.catnix.net (193.242.98.38)  19.247 ms  19.175 ms  19.292 ms    
 5  xtec-anella.cesca.cat (84.88.18.46)  16.926 ms  16.974 ms  16.986 ms

Es el mateix que fer aque 

[email protected]:~$ ping -nR www.xtec.cat
PING www.xtec.cat (213.176.163.147) 56(124) bytes of data.

Pràctica PING i TCPDUMP amb un ttl (time to life) assignat de 1 (-t1).El ttl es el temps de vida assignat que li donem al icmp_request del ping. Podem observar al següent exemple que per defecte ens dona un ttl de 46. Si canviem els paràmetre del ttl a 1 (paràmetre força petit), al fer el ping ens informa que el temps de sol·licitud (de resposta) s'ha excedit. Si mentre fem un ping -t1 capturem els paquets amb el tcpdump aquest també ens informa que s'ha excedit el temps del ping (ICMP time exceeded in-transit) 

[email protected]:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=46 time=54.2 ms  -->ttl=time to life 
64 bytes from 8.8.8.8: icmp_req=2 ttl=46 time=51.0 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=46 time=47.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 47.847/51.072/54.287/2.635 ms

[email protected]:~$ ping -t1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.204.1 icmp_seq=1 Time to live exceeded
From 192.168.204.1 icmp_seq=2 Time to live exceeded
From 192.168.204.1 icmp_seq=3 Time to live exceeded
From 192.168.204.1 icmp_seq=4 Time to live exceeded
From 192.168.204.1 icmp_seq=5 Time to live exceeded

[email protected]:~$ sudo traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.204.1 (192.168.204.1)  0.271 ms  0.307 ms  0.306 ms
 2  routortosa01real.tortosa.guifi.net (109.69.15.2)  6.292 ms  6.330 ms  6.231 ms
 3  10.253.4.22 (10.253.4.22)  7.915 ms  7.851 ms  7.927 ms
 4  gi4-2.mag01.bcn01.atlas.cogentco.com (149.6.130.113)  12.531 ms  12.178 ms  12.480 ms
 5  te3-4.ccr01.bcn01.atlas.cogentco.com (154.54.59.133)  12.476 ms  12.472 ms te4-2.ccr01.bcn01.atlas.cogentco.com (154.54.59.129)  12.170 ms
 6  te0-0-0-6.ccr22.mrs01.atlas.cogentco.com (130.117.2.210)  17.552 ms  19.649 ms  18.996 ms  
 7  te0-1-0-3.ccr22.muc01.atlas.cogentco.com (154.54.74.102)  37.317 ms te0-2-0-7.ccr22.muc01.atlas.cogentco.com (154.54.74.86)  37.539 ms  
       te0-4-0-1.ccr22.muc01.atlas.cogentco.com (154.54.74.98)  37.195 ms
 8  te0-5-0-4.mpd22.fra03.atlas.cogentco.com (154.54.74.218)  44.418 ms te0-2-0-2.mpd22.fra03.atlas.cogentco.com (130.117.50.241)  48.293 ms t   
       e0-3-0-2.mpd22.fra03.atlas.cogentco.com (130.117.50.237)  48.110 ms
 9  aurora-tel-ltd.demarc.cogentco.com (149.6.140.58)  149.599 ms  149.641 ms  149.581 ms
10  209.85.240.64 (209.85.240.64)  78.437 ms  48.146 ms  48.094 ms
11  72.14.239.60 (72.14.239.60)  48.362 ms 72.14.236.20 (72.14.236.20)  48.258 ms 72.14.239.60 (72.14.239.60)  48.403 ms
12  209.85.254.116 (209.85.254.116)  46.631 ms 209.85.254.118 (209.85.254.118)  53.072 ms 209.85.254.114 (209.85.254.114)  53.094 ms
13  * * *
14  google-public-dns-a.google.com (8.8.8.8)  50.385 ms  50.181 ms  50.384 ms

[email protected]:~$ ping -t1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.204.1 icmp_seq=1 Time to live exceeded
From 192.168.204.1 icmp_seq=2 Time to live exceeded
From 192.168.204.1 icmp_seq=3 Time to live exceeded
From 192.168.204.1 icmp_seq=4 Time to live exceeded
From 192.168.204.1 icmp_seq=5 Time to live exceeded

[email protected]:~$ sudo tcpdump -n -i eth2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
20:48:35.233982 IP 192.168.204.118 > 8.8.8.8: ICMP echo request, id 8274, seq 6, length 64
20:48:35.234179 IP 192.168.204.1 > 192.168.204.118: ICMP time exceeded in-transit, length 92
20:48:35.975029 IP 192.168.204.118 > 173.194.70.94: ICMP echo request, id 8252, seq 442, length 64
20:48:36.233699 IP 192.168.204.118 > 8.8.8.8: ICMP echo request, id 8274, seq 7, length 64
20:48:36.233836 IP 192.168.204.1 > 192.168.204.118: ICMP time exceeded in-transit, length 92
20:48:36.975680 IP 192.168.204.118 > 173.194.70.94: ICMP echo request, id 8252, seq 443, length 64
20:48:37.233689 IP 192.168.204.118 > 8.8.8.8: ICMP echo request, id 8274, seq 8, length 64
20:48:37.233834 IP 192.168.204.1 > 192.168.204.118: ICMP time exceeded in-transit, length 92
20:48:37.975682 IP 192.168.204.118 > 173.194.70.94: ICMP echo request, id 8252, seq 444, length 64
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel

ICMP 3 DESTINATION UNRICHABLE

Hi ha vegades que quan fem un ping no es pot arribar a destinació, sigui per que aquesta no existeix,una falla a la ret,etc..En aquests casos específics ens avisarà que la destinació és inabastable (Destination Host Unreachable). Cosa diferent és quan envia el ping i no torna contestació el host de destinació, llavors potser que si que li arribi el ping, però que per alguna raó no torni la contestació.

En el següent cas podem veure que en el cas de fer un ping a una màquina de l'aula del costat (203), aquesta si existeix ens torna el ping correctament. 

[email protected]:~$ ping 192.168.203.102
PING 192.168.203.102 (192.168.203.102) 56(84) bytes of data.
64 bytes from 192.168.203.102: icmp_req=1 ttl=63 time=0.462 ms
64 bytes from 192.168.203.102: icmp_req=2 ttl=63 time=0.241 ms
64 bytes from 192.168.203.102: icmp_req=3 ttl=63 time=0.243 ms

[email protected]:~$ sudo traceroute 192.168.203.102  ->Amb el traceroute podem observar que només fem 2 salts fins a la màquina de l'aula 203
[sudo] password for rafel: 
traceroute to 192.168.203.102 (192.168.203.102), 30 hops max, 60 byte packets
 1  192.168.204.1 (192.168.204.1)  0.256 ms  0.319 ms  0.327 ms
 2  a203PC02.aula203.iesebre.com (192.168.203.102)  0.647 ms  0.627 ms  0.654 ms

Ara bé, en el cas que fem un ping a una màquina apagada,inexistent o fora de línia per alguna raó, llavors ens tornarà un missatge que ens posarà sobre avís de que la IP(ICMP) de destinació no s'ha pogut assolir.(Com és el cas de la IP 192.168.203.189) 

[email protected]:~$ ping 192.168.203.189
PING 192.168.203.189 (192.168.203.189) 56(84) bytes of data.
From 192.168.204.1 icmp_seq=1 Destination Host Unreachable
From 192.168.204.1 icmp_seq=3 Destination Host Unreachable
From 192.168.204.1 icmp_seq=4 Destination Host Unreachable
From 192.168.204.1 icmp_seq=5 Destination Host Unreachable
^C
--- 192.168.203.189 ping statistics ---
6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4998ms 
pipe 3

Un altre exemple fent un ping a una IP assolible: 

[email protected]:~$ ping 10.140.128.11
PING 10.140.128.11 (10.140.128.11) 56(84) bytes of data.
64 bytes from 10.140.128.11: icmp_req=1 ttl=61 time=3.94 ms
64 bytes from 10.140.128.11: icmp_req=2 ttl=61 time=11.9 ms
64 bytes from 10.140.128.11: icmp_req=3 ttl=61 time=4.99 ms
64 bytes from 10.140.128.11: icmp_req=4 ttl=61 time=4.08 ms
64 bytes from 10.140.128.11: icmp_req=5 ttl=61 time=1.83 ms
64 bytes from 10.140.128.11: icmp_req=6 ttl=61 time=1.82 ms
64 bytes from 10.140.128.11: icmp_req=7 ttl=61 time=12.9 ms
64 bytes from 10.140.128.11: icmp_req=8 ttl=61 time=1.72 ms
64 bytes from 10.140.128.11: icmp_req=9 ttl=61 time=8.08 ms
64 bytes from 10.140.128.11: icmp_req=10 ttl=61 time=2.67 ms
64 bytes from 10.140.128.11: icmp_req=11 ttl=61 time=2.81 ms
^C
--- 10.140.128.11 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10015ms
rtt min/avg/max/mdev = 1.722/5.170/12.922/3.857 ms 

[email protected]:~$ sudo traceroute 10.140.128.11
traceroute to 10.140.128.11 (10.140.128.11), 30 hops max, 60 byte packets
 1  192.168.204.1 (192.168.204.1)  0.306 ms  0.314 ms  0.266 ms
 2  192.168.50.6 (192.168.50.6)  0.636 ms  0.645 ms  0.636 ms
 3  172.16.150.1 (172.16.150.1)  8.783 ms  9.239 ms  9.529 ms
 4  10.140.128.11 (10.140.128.11)  8.947 ms  9.550 ms  9.049 ms

I un altre exemple a una IP inassolible: 

[email protected]:~$ ping 10.140.128.17
PING 10.140.128.17 (10.140.128.17) 56(84) bytes of data.
From 10.36.253.97 icmp_seq=2 Destination Host Unreachable
From 10.36.253.97 icmp_seq=5 Destination Host Unreachable
From 10.36.253.97 icmp_seq=8 Destination Host Unreachable

[email protected]:~$ sudo tcpdump -n -i eth2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
21:03:25.179744 IP 192.168.204.118 > 10.140.128.17: ICMP echo request, id 8314, seq 8, length 64
21:03:25.315839 IP 192.168.204.118 > 173.194.70.94: ICMP echo request, id 8252, seq 1331, length 64
21:03:26.081044 IP 10.36.253.97 > 192.168.204.118: ICMP host 10.140.128.17 unreachable, length 92
21:03:26.179330 IP 192.168.204.118 > 10.140.128.17: ICMP echo request, id 8314, seq 9, length 64
21:03:26.315380 IP 192.168.204.118 > 173.194.70.94: ICMP echo request, id 8252, seq 1332, length 64
21:03:27.187758 IP 192.168.204.118 > 10.140.128.17: ICMP echo request, id 8314, seq 10, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

[email protected]:~$ sudo traceroute 10.140.128.17
traceroute to 10.140.128.17 (10.140.128.17), 30 hops max, 60 byte packets
 1  192.168.204.1 (192.168.204.1)  0.322 ms  0.300 ms  0.294 ms
 2  192.168.50.6 (192.168.50.6)  0.609 ms  0.603 ms  0.594 ms
 3  172.16.150.1 (172.16.150.1)  11.430 ms  11.715 ms  11.709 ms   --> Observem que no pot passar del tercer salt.
 4  * * *
 5  * * *
 6  * 10.36.253.97 (10.36.253.97)  1067.407 ms !H *

BLOQUEJAR PINGS (ICMP)

És poden bloquejar els pings mitjançant l'eina iptables com és pot veure al següent exemple. En aquest cas la IP 8.8.8.8 (Primer els fa caure DROP , i el REJECT els rebutja. Un els REp però els llança i l'altre ja no els deixa entrar, els rebutja directament) 

[email protected]:~$ sudo iptables  -A OUTPUT  -d 8.8.8.8 -j DROP  
[email protected]:~$ sudo iptables  -A OUTPUT  -d 8.8.8.8 -j REJECT  --reject-with icmp-host-prohibited
[email protected]:~$ sudo iptables --line-numbers -nvxL
Chain INPUT (policy ACCEPT 37 packets, 6165 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1         970    83244 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
2           0        0 REJECT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
3           0        0 REJECT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
4           0        0 REJECT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
5           0        0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
6           0        0 DROP       icmp --  *      *       127.0.0.1            0.0.0.0/0            icmptype 8

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 36 packets, 4676 bytes)
num      pkts      bytes target     prot opt in     out     source               destination         
1           0        0 REJECT     all  --  *      *       0.0.0.0/0            8.8.8.8              reject-with icmp-host-prohibited

Si provem de realitzar un ping a la IP estipulada veurem que no ens està permesa l'operació 
[email protected]:~$ sudo ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Operation not 
permitted                                                                                                                                              
ping: sendmsg: Operation not  
permitted                                                                                                                                              
ping: sendmsg: Operation not  
permitted                                                                                                                                              
ping: sendmsg: Operation not  
permitted                                                                                                                                              
ping: sendmsg: Operation not  
permitted                                                                                                                                              
ping: sendmsg: Operation not  
permitted                                                                                                                                              
ping: sendmsg: Operation not 
permitted                                                                                                                                             ^C                                                                                                                                                                                   
--- 8.8.8.8 ping statistics---                                                                                                                                                     
7 packets transmitted, 0 received, 100% packet loss, time 6047ms

Control messages

Notable control messages<ref>Plantilla:Cite web</ref><ref>Computer Networking – A Top-Down Approach by Kurose and Ross</ref>
Type Code Description
0 – Echo Reply<ref name=rfc792/>Plantilla:Rp 0 Echo reply (used to ping)
1 and 2 Reserved
3 – Destination Unreachable<ref name=rfc792/>Plantilla:Rp 0 Destination network unreachable
1 Destination host unreachable
2 Destination protocol unreachable
3 Destination port unreachable
4 Fragmentation required, and DF flag set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated
9 Network administratively prohibited
10 Host administratively prohibited
11 Network unreachable for TOS
12 Host unreachable for TOS
13 Communication administratively prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
4 – Source Quench 0 Source quench (congestion control)
5 – Redirect Message 0 Redirect Datagram for the Network
1 Redirect Datagram for the Host
2 Redirect Datagram for the TOS & network
3 Redirect Datagram for the TOS & host
6 Alternate Host Address
7 Reserved
8 – Echo Request 0 Echo request (used to ping)
9 – Router Advertisement 0 Router Advertisement
10 – Router Solicitation 0 Router discovery/selection/solicitation
11 – Time Exceeded<ref name=rfc792/>Plantilla:Rp 0 TTL expired in transit
1 Fragment reassembly time exceeded
12 – Parameter Problem: Bad IP header 0 Pointer indicates the error
1 Missing a required option
2 Bad length
13 – Timestamp 0 Timestamp
14 – Timestamp Reply 0 Timestamp reply
15 – Information Request 0 Information Request
16 – Information Reply 0 Information Reply
17 – Address Mask Request 0 Address Mask Request
18 – Address Mask Reply 0 Address Mask Reply
19 Reserved for security
20 through 29 Reserved for robustness experiment
30 – Traceroute 0 Information Request
31 Datagram Conversion Error
32 Mobile Host Redirect
33 Where-Are-You (originally meant for IPv6)
34 Here-I-Am (originally meant for IPv6)
35 Mobile Registration Request
36 Mobile Registration Reply
37 Domain Name Request
38 Domain Name Reply
39 SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol
40 Photuris, Security failures
41 ICMP for experimental mobility protocols such as Seamoby [RFC4065]
42 through 255 Reserved

Source quench

Source Quench requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request, or may occur if the router or host buffer is approaching its limit.

Data is sent at a very high speed from a host or from several hosts at the same time to a particular router on a network. Although a router has buffering capabilities, the buffering is limited to within a specified range. The router cannot queue any more data than the capacity of the limited buffering space. Thus if the queue gets filled up, incoming data is discarded until the queue is no longer full. But as no acknowledgement mechanism is present in the network layer, the client does not know whether the data has reached the destination successfully. Hence some remedial measures should be taken by the network layer to avoid these kind of situations. These measures are referred to as source quench. In a source quench mechanism, the router sees that the incoming data rate is much faster than the outgoing data rate, and sends an ICMP message to the clients, informing them that they should slow down their data transfer speeds or wait for a certain amount of time before attempting to send more data. When a client receives this message, it will automatically slow down the outgoing data rate or wait for a sufficient amount of time, which enables the router to empty the queue. Thus the source quench ICMP message acts as flow control in the network layer.

Source quench message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 4 Code = 0 Header checksum
unused
IP header and first 8 bytes of original datagram's data

Where:

Type must be set to 4
Code must be set to 0
IP header and additional data is used by the sender to match the reply with the associated request

Redirect

Redirect requests data packets be sent on an alternative route. ICMP Redirect is a mechanism for routers to convey routing information to hosts. The message informs a host to update its routing information (to send packets on an alternate route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a direct path from the host to R2 is available (that is, the host and R2 are on the same Ethernet segment), then R1 will send a redirect message to inform the host that the best route for the destination is via R2. The host should then send packets for the destination directly to R2. The router will still send the original datagram to the intended destination. However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.

Redirect message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 5 Code Header checksum
IP address
IP header and first 8 bytes of original datagram's data

Where:

Type must be set to 5.
Code specifies the reason for the redirection, may be one of the following:
Code Description
0 Redirect for Network
1 Redirect for Host
2 Redirect for Type of Service and Network
3 Redirect for Type of Service and Host
IP address is the 32-bit address of the gateway to which the redirection should be sent.
IP header and additional data is included to allow the host to match the reply with the request that caused the redirection reply.

Time exceeded

Time Exceeded is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit.

Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.

Time exceeded message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 11 Code Header checksum
unused
IP header and first 8 bytes of original datagram's data

Where:

Type must be set to 11
Code specifies the reason for the time exceeded message, include the following:
Code Description
0 Time-to-live exceeded in transit.
1 Fragment reassembly time exceeded.
IP header and first 64 bits of the original payload are used by the source host to match the time exceeded message to the discarded datagram. For higher level protocols such as UDP and TCP the 64 bit payload will include the source and destination ports of the discarded packet.

Timestamp

Timestamp is used for time synchronization. It consists of the originating timestamp.

Timestamp message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 13 Code = 0 Header checksum
Identifier Sequence number
Originate timestamp

Where:

Type must be set to 13
Code must be set to 0
Identifier and Sequence Number can be used by the client to match the timestamp reply with the timestamp request.
Originate timestamp is the number of milliseconds since midnight Universal Time (UT). If a UT reference is not available the most-significant bit can be set to indicate a non-standard time value.

Timestamp reply

Timestamp Reply replies to a Timestamp message. It consists of the originating timestamp sent by the sender of the Timestamp as well as a receive timestamp and a transmit timestamp.

Timestamp reply message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 14 Code = 0 Header checksum
Identifier Sequence number
Originate timestamp
Receive timestamp
Transmit timestamp

Where:

Type must be set to 14
Code must be set to 0
Identifier and Sequence number can be used by the client to match the reply with the request that caused the reply.
Originate timestamp is the time the sender last touched the message before sending it.
Receive timestamp is the time the echoer first touched it on receipt.
Transmit timestamp is the time the echoer last touched the message on sending it.
All timestamps are in units of milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.

Address mask request

Address mask request is normally sent by a host to a router in order to obtain an appropriate subnet mask.

Recipients should reply to this message with an Address mask reply message.

Address mask request
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 17 Code = 0 Header checksum
Identifier Sequence number
Address mask

Where:

Type must be set to 17
Code must be set to 0
Address mask can be set to 0

ICMP Address Mask Request may be used as a part of reconnaissance attack to gather information on the target network, therefore ICMP Address Mask Reply is disabled by default on Cisco IOS.<ref>Plantilla:Cite web</ref>

Address mask reply

Address mask reply is used to reply to an address mask request message with an appropriate subnet mask.

Address mask reply
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 18 Code = 0 Header checksum
Identifier Sequence number
Address mask

Where:

Type must be set to 18
Code must be set to 0
Address mask should be set to the subnet mask

Destination unreachable

Destination unreachable is generated by the host or its inbound gateway]<ref name=rfc792/> to inform the client that the destination is unreachable for some reason. A Destination Unreachable message may be generated as a result of a TCP, UDP or another ICMP transmission. Unreachable TCP ports notably respond with TCP RST rather than a Destination Unreachable type 3 as might be expected.

The error will not be generated if the original datagram has a multicast destination address. Reasons for this message may include: the physical connection to the host does not exist (distance is infinite); the indicated protocol or port is not active; the data must be fragmented but the 'don't fragment' flag is on.

Destination unreachable message<ref name=rfc792/>Plantilla:Rp
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type = 3 Code Header checksum
unused Next-hop MTU
IP header and first 8 bytes of original datagram's data

Where:

Type field (bits 0-7) must be set to 3
Code field (bits 8-15) is used to specify the type of error, and can be any of the following:
Code Description
0 Network unreachable error.
1 Host unreachable error.
2 Protocol unreachable error (the designated transport protocol is not supported).
3 Port unreachable error (the designated protocol is unable to inform the host of the incoming message).
4 The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on.
5 Source route failed error.
6 Destination network unknown error.
7 Destination host unknown error.
8 Source host isolated error.
9 The destination network is administratively prohibited.
10 The destination host is administratively prohibited.
11 The network is unreachable for Type Of Service.
12 The host is unreachable for Type Of Service.
13 Communication administratively prohibited (administrative filtering prevents packet from being forwarded).
14 Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port).
15 Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators).
Next-hop MTU field (bits 48-63) contains the MTU of the next-hop network if a code 4 error occurs.
IP header and additional data is included to allow the client to match the reply with the request that caused the destination unreachable reply.


http://acacha.org/mediawiki/index.php/Nivell_d%27internet_TCP/IP http://acacha.org/mediawiki/index.php/Nivell_de_transport_TCP/IP

Obtingut de «https://acacha.org/w/index.php?title=Usuari:Rafelmelich_/_NIVELL_XARXA_I_NIVELL_DE_TRANSPORT&oldid=151300»

Sobre nosaltres

logo

Acacha Wiki és un lloc web col·laboratiu d' informàtica i telecomunicacions creat per experts en administració de sistemes, xarxes, desenvolupament multiplataforma, disseny web i altres àrees de coneixement.

Quant a Política de privadesa Avís general

Blog

TODO
Entrada blog 1
October 9, 2014
pendent
Entrada blog 2
October 9, 2014

Pàgines populars

Segueix-nos




Pàgines Germanes

Ebre-escool

S'ha visitat aquesta pàgina 4420 vegades.
Darrera modificació de la pàgina: 21 gen 2013 a les 21:52.
© 2021 by Sergi Tur Badenas i altres contribuïdors • Powered by MediaWiki & Bootstrap