Skip to main content
  1. Concetti/

MTU - Maximum Transmission Unit

·6 mins
Alessio Barnini
Author
Alessio Barnini
Table of Contents

Cosa fa
#

Definisce la dimensione massima in byte che il payload di un frame puo' avere su un determinato link fisico. Non e' una proprieta' del router, del cavo, o di TCP — e' una proprieta' del protocollo di Layer 2 usato su quel link. Se un pacchetto IP supera l'MTU del link successivo, deve essere frammentato (IPv4) o il mittente deve rimandarlo piu' piccolo (IPv6).

TL;DR
#

MTU = quanto spazio hai nel "camion" per caricare i dati

Link Ethernet standard → MTU 1500 byte
  significa: il payload del frame non puo' superare 1500 byte
  dentro ci sta: header IP + header TCP + dati applicativi

Se il pacchetto e' piu' grande del MTU del link → problema
  IPv4: il router frammenta il pacchetto
  IPv6: il router manda "Packet Too Big" al mittente

Dove opera MTU — il modello OSI
#

Layer 7  APPLICATION   HTTP, HTTPS, FTP...
         "voglio mandare questi dati"
Layer 4  TRANSPORT     TCP, UDP
         "li spezzetto in segmenti"
Layer 3  NETWORK       IP
         "creo pacchetti, rispetto l'MTU del link"
Layer 2  DATA LINK     Ethernet, WiFi, PPPoE  ← MTU vive qui
         "il frame non puo' superare X byte"
Layer 1  PHYSICAL      cavi, segnali
         "trasmetto i bit"

MTU e' una proprieta' del Layer 2 che il Layer 3 deve rispettare. Il cavo fisico (Layer 1) non ha MTU — trasmette bit senza limiti di dimensione.


Cos'e' un frame — cosa contiene
#

Un frame Ethernet e' l'unita' di dati del Layer 2. Contiene tutto: header Ethernet + payload + FCS.

FCS: Frame Check Sequence — il checksum del frame Ethernet. Se il frame arriva corrotto (cavo rovinato, interferenze): FCS calcolato dal ricevitore ≠ FCS nel frame → frame scartato silenziosamente → TCP al layer 4 non riceve l'ACK → ritrasmette

FRAME ETHERNET COMPLETO (max 1514 byte):
┌─────────────────┬───────────────────────────────────────┬──────┐
│  ETH header     │            payload (max 1500 byte)    │ FCS  │
14 byte       │                                       │ 4b   │
│ MAC src + dst   │ IP header + TCP header + dati HTTP    │      │
│ + tipo (2b)     │                                       │      │
└─────────────────┴───────────────────────────────────────┴──────┘
                       questo e' l'MTU
                    (solo il payload, non gli header Ethernet)

Cosa c'e' dentro il payload (esempio HTTP):

PAYLOAD (max 1500 byte su Ethernet):
┌──────────────┬───────────────┬─────────────────────────────────┐
│  IP header   │  TCP header   │         dati HTTP               │
20 byte    │   20 byte     │  "GET /index.html HTTP/1.1..."│              │               │         ~1460 byte              │
└──────────────┴───────────────┴─────────────────────────────────┘

Spazio effettivo per i dati = 1500 - 20 (IP) - 20 (TCP) = 1460 byte
Questo si chiama MSS — Maximum Segment Size

MTU varia per tipo di link#

L'MTU non e' universale — dipende dal protocollo di Layer 2 del link:

Tipo di link         MTU tipico    Nota
──────────────────────────────────────────────────────────────
Ethernet standard    1500 byte     il default ovunque
Jumbo frames         9000 byte     datacenter, reti ad alte perf.
WiFi 802.11          2304 byte     teorico, in pratica ~1500
PPPoE (ADSL/fibra)   1492 byte     -8 byte per header PPPoE
VPN (IPSec/OpenVPN)  variabile     ridotto — il tunnel aggiunge overhead
Loopback (lo)        65536 byte    solo locale, nessun limite reale

Perche' VPN riduce l'MTU
#

Un tunnel VPN aggiunge il suo header sopra il pacchetto IP originale:

SENZA VPN:
┌──────┬──────┬──────┬───────────────────────────────────┐
│ ETH  │  IP  │ TCP  │           dati                    │
│ 14b  │ 20b  │ 20b  │          1460b                    │  = 1514 byte totali
└──────┴──────┴──────┴───────────────────────────────────┘

CON VPN (IPSec esempio):
┌──────┬──────────┬──────┬──────┬──────┬────────────────┐
│ ETH  │ IP outer │ IPSec│  IP  │ TCP  │    dati        │
│ 14b  │   20b    │ ~50b │ 20b  │ 20b  │   ~1356b       │
└──────┴──────────┴──────┴──────┴──────┴────────────────┘
              overhead del tunnel
              "mangia" spazio dal payload

MTU effettivo con VPN ≈ 1500 - 50 (IPSec overhead) = ~1450 byte

Path MTU Discovery — come funziona
#

Ogni hop lungo il percorso ha il suo MTU. Il percorso ha un MTU minimo:

Client        Router A       Router B       Server
MTU 1500      MTU 1500       MTU 1400       MTU 1500

Path MTU = minimo tra tutti gli hop = 1400

In IPv4 — il router frammenta
#

Client manda pacchetto da 1500 byte
Router A (MTU 1500) → passa
Router B (MTU 1400) → troppo grande!
       ├── Frammento 1: 1400 byte → Server
       └── Frammento 2: 100 byte  → Server

Server riassembla i frammenti

Il router frammenta in silenzio — il mittente non sa nulla.

In IPv6 — solo il mittente frammenta
#

Client manda pacchetto da 1500 byte
Router A (MTU 1500) → passa
Router B (MTU 1400) → troppo grande!
       └── ICMPv6 Type 2 "Packet Too Big, MTU=1400" → Client

Client riceve il messaggio
       ├── Abbassa MTU a 1400
       └── Rimanda il pacchetto piu' piccolo
           Server — arriva correttamente

Il router IPv6 non frammenta mai — notifica il mittente.

Perche' IPv6 ha scelto questo approccio? Frammentare nei router intermedi e' costoso computazionalmente. Spostare la responsabilita' al mittente rende i router piu' veloci.


Come appare in Wireshark — IPv6 con Fragment Header
#

Next header: Fragment Header for IPv6 (44)   ← segnale di frammentazione
Fragment Header:
  Offset: 0        ← primo frammento
  More Fragments: Yes  ← ne arrivano altri
  Identification: 0xcde00817  ← ID per riassemblare

Il campo Next Header = 44 indica che c'e' un Extension Header di frammentazione — la prova che il mittente ha dovuto spezzare il pacchetto.


Scenario Reale Blue Team
#

Un server web smette improvvisamente di rispondere ad alcuni client ma funziona per altri. Il problema potrebbe essere MTU.

# Testa la connettivita' con pacchetti di dimensione crescente
ping -M do -s 1472 8.8.8.8   # -M do = Don't Fragment, -s = size payload
# Se fallisce con 1472 ma funziona con 1400 → MTU problem nel percorso

# Scopri il Path MTU verso un host
tracepath 8.8.8.8
# mostra l'MTU di ogni hop

Un altro scenario: client dietro VPN non riescono a caricare pagine grandi ma le pagine piccole funzionano. Causa quasi sempre: MTU del tunnel VPN non configurato correttamente — il client manda pacchetti troppo grandi per il tunnel.

Tip

Il valore 1472 in ping corrisponde a 1500 (MTU Ethernet) - 20 (IP header)

  • 8 (ICMP header) = 1472 byte di payload. Se questo ping funziona, l'MTU lungo il percorso e' almeno 1500.
Warning

Alcuni firewall bloccano i pacchetti ICMPv6 "Packet Too Big". Questo rompe il Path MTU Discovery per IPv6 e causa problemi di connettivita' inspiegabili — i pacchetti grandi non arrivano mai. E' una misconfiguration comune e difficile da diagnosticare.


Collegato a
#

  • network — categoria
  • osi-model — MTU opera a Layer 2, rispettato da Layer 3
  • ip-header — frammentazione IPv4 nei campi Flags e Fragment Offset
  • ipv6 — Path MTU Discovery in IPv6, Packet Too Big
  • tcp-udp — MSS (Maximum Segment Size) e' il MTU meno gli header IP e TCP

Related