Tamanho da MTU da Starlink: MTU do caminho medida em 1500 bytes

Pacotes de 1500 bytes chegaram aos três hosts de teste, em IPv4 e IPv6

A unidade máxima de transmissão (MTU) de um enlace é o maior pacote que ele leva inteiro, e a MTU de um caminho é a menor MTU de enlace ao longo dele. A RFC 8201 define assim: “the minimum link MTU of all the links in a path between a source node and a destination node” (em tradução nossa, a menor MTU de enlace entre todos os enlaces de um caminho entre um nó de origem e um nó de destino; seção 2, verificada em outubro de 2026).

O teste rodou em outubro de 2026 a partir de um computador ligado por cabo à rede de casa, numa conexão Starlink doméstica, em duas leituras com poucos minutos de intervalo. Todas as rotas até os hosts de teste saíam pela interface cabeada, então nenhuma VPN, exit node ou túnel levou o tráfego. Em cada leitura, para cada host, em IPv4 e em IPv6, o tracepath rodou até o fim. Depois, três pings dimensionados para formar pacotes de 1500 bytes saíram com o bit don't fragment ligado e um tempo limite de resposta de 2 segundos. Outros três, dimensionados para formar pacotes de 1501 bytes, foram recusados pelo computador antes de serem enviados.

Os três hosts são máquinas públicas que os operadores oferecem para testes de rede (cada página verificada em outubro de 2026):

• scanme.nmap.org, que o projeto Nmap montou para que as pessoas possam “test and make sure that their Nmap installation (or Internet connection) is working properly” (testar e garantir que a instalação do Nmap, ou a conexão com a internet, está funcionando direito);
• speedtest.newark.linode.com, cuja página inicial tem o título “Linode, now Akamai, Speedtest”;
• proof.ovh.net, um host de teste de velocidade de rede da OVHcloud.

A descoberta da MTU do caminho parte da MTU do primeiro enlace de quem envia. Em IPv4, o remetente liga o bit Don't Fragment (DF), e um roteador que não consegue encaminhar esse pacote inteiro o descarta e devolve uma mensagem ICMP que significa “fragmentation needed and DF set” (fragmentação necessária e DF ligado; RFC 1191, seção 2, verificada em outubro de 2026). Em IPv6, um roteador que não consegue encaminhar um pacote por ele ser maior que a MTU do próximo enlace deve devolver uma mensagem Packet Too Big (RFC 4443, seção 3.2, verificada em outubro de 2026). Nos dois casos, o remetente reduz a sua estimativa (RFC 8201, seção 3). O tracepath rastreia um caminho “discovering MTU along this path” (descobrindo a MTU ao longo deste caminho) e mostra a MTU do caminho onde ela muda (iputils 20250605, verificado em outubro de 2026). Em todos os rastreamentos daqui ela ficou em 1500 do início ao fim, e nenhum ping provocou uma mensagem de pacote grande demais, então nenhum salto informou uma MTU menor.

Os pings verificam a mesma coisa de ponta a ponta. Cada ping de 1500 bytes chegou ao respectivo host, e a resposta voltou. Isso cobre os saltos que não respondem ao tracepath, que só os pings testam. O caminho também começa no roteador de casa, então as próprias configurações do roteador fazem parte do resultado: nada nesses caminhos, incluindo o roteador de casa e a rede da Starlink, cortava pacotes abaixo de 1500 bytes naquele momento.

Em IPv4, os rastreamentos começaram com os mesmos tipos de saltos do rastreamento do guia sobre hospedar um servidor sem IPv4 público, que esta página não repete.

Um ping de 1472 bytes é um pacote IPv4 de 1500 bytes

A opção -s do ping define o número de bytes de dados, e o ICMP soma a eles um cabeçalho de 8 bytes (ping(8), iputils 20250605, verificado em outubro de 2026). Uma mensagem de eco ICMPv6 também tem 8 bytes antes dos dados: tipo, código, checksum, identificador e número de sequência (RFC 4443, seção 4.1, verificada em outubro de 2026). Um cabeçalho IPv4 mínimo tem 20 bytes, e um cabeçalho IPv6 tem 20 bytes a mais, 40 (RFC 8200, seção 8.3, verificada em outubro de 2026).

Um ping com don't fragment ligado que recebe respostas com 1472 bytes de dados em IPv4 significa que um pacote de 1500 bytes atravessou o caminho. O 1472 é a carga útil do ping, e a MTU é o pacote inteiro.

Em IPv6, os roteadores nunca dividem um pacote: “fragmentation in IPv6 is performed only by source nodes” (a fragmentação em IPv6 é feita apenas pelos nós de origem), diz a RFC 8200 (seção 4.5). Então um ping IPv6 de 1500 bytes ou atravessa inteiro ou encontra um roteador que tem de responder com uma mensagem Packet Too Big (RFC 4443, seção 3.2).

Para repetir o teste no Linux com o iputils, rode estes comandos, mostrados aqui com um dos três hosts:

tracepath -4 -n scanme.nmap.org
ping -4 -M do -n -c 3 -W 2 -s 1472 scanme.nmap.org
tracepath -6 -n scanme.nmap.org
ping -6 -M do -n -c 3 -W 2 -s 1452 scanme.nmap.org

-M do liga o don't fragment, -c 3 envia três pings e -W 2 define um tempo limite de resposta de 2 segundos (ping(8)). A página do Nmap pede que os visitantes não exagerem com o host: “A few scans in a day is fine” (algumas varreduras por dia, tudo bem). Os comandos ping de outros sistemas usam outras opções, e esta página não trata deles.

Pacotes de 1501 bytes nunca saíram do computador

Num computador cuja própria MTU de enlace é de 1500 bytes, um ping com -M do e 1473 bytes de dados (IPv4) ou 1453 (IPv6) que falha na hora, com um erro local dizendo que a mensagem é longa demais para uma MTU de 1500, foi recusado por esse computador. A falha não diz nada sobre o seu provedor.

Se o erro citar uma MTU menor que 1500, essa interpretação não vale. O computador está comparando o pacote com um limite mais baixo que o do seu enlace, e esse limite pode vir do caminho: um remetente reduz a sua estimativa depois de uma mensagem de pacote grande demais vinda de um roteador (RFC 1191, seção 2; RFC 8201, seção 3).

As ferramentas de túnel contam 80 bytes de cabeçalhos do WireGuard

No kernel Linux, uma interface nova do WireGuard recebe dev->mtu = ETH_DATA_LEN - overhead (device.c, Linux 6.18). ETH_DATA_LEN é 1500, a carga útil máxima da Ethernet (if_ether.h). O overhead é a menor mensagem de dados do WireGuard, mais um cabeçalho UDP de 8 bytes (RFC 768) e o maior dos cabeçalhos IPv6 e IPv4, os 40 do IPv6 (RFC 8200). Essa mensagem tem 32 bytes: um tipo de 4 bytes, um índice de chave de 4 bytes, um contador de 8 bytes e uma tag de autenticação de 16 bytes (messages.h, com o tamanho da tag em chacha20poly1305.h). Então o overhead é de 80 bytes, e a interface começa em 1420. Tudo verificado em outubro de 2026.

A tag vem depois dos dados cifrados: no AEAD (criptografia autenticada com dados associados) da RFC 8439, a saída é o texto cifrado e depois a tag (seção 2.8, verificada em outubro de 2026).

O wg-quick no Linux usa a linha MTU da config da interface quando ela existe. Sem ela, o script lê a MTU das rotas até os endpoints dos peers, recorre à da rota padrão e depois a 1500, e define a interface 80 bytes abaixo (linux.bash, wireguard-tools v1.0.20250521, verificado em outubro de 2026). Numa rota de 1500 bytes, isso dá 1420.

O Tailscale conta os mesmos 80 bytes para o pior caso, um cabeçalho externo IPv6. A lista dele é um “20-byte IPv4 header or 40-byte IPv6 header” (cabeçalho IPv4 de 20 bytes ou cabeçalho IPv6 de 40 bytes), um cabeçalho UDP de 8 bytes, um tipo de 4 bytes, um índice de chave de 4 bytes, um nonce de 8 bytes e uma tag de autenticação de 16 bytes (mtu.go, Tailscale v1.90.0, verificado em outubro de 2026). Nesse arquivo, o tamanho não depende do enlace: DefaultTUNMTU(), que o arquivo usa para definir a MTU da interface, retorna 1280, a MTU padrão “safe” (segura) dele, a menos que a configuração de depuração TS_DEBUG_MTU defina outro tamanho. Ele retorna 1280 mesmo com TS_DEBUG_ENABLE_PMTUD, a configuração de depuração para sondar a MTU do caminho, ligada. Somados os 80 bytes, 1280 vira 1360 bytes no fio. O valor 1280 também é a menor MTU que o IPv6 permite em qualquer enlace (RFC 8200, seção 5).

Os caminhos deste teste levaram pacotes de 1500 bytes. Nenhum túnel rodou sobre eles, então esta página não mostra o que os pacotes de um túnel fizeram.

Quando um pacote é grande demais para um enlace e a mensagem de pacote grande demais nunca chega ao remetente, a RFC 8201 descreve conexões que “complete the TCP three-way handshake correctly but then hang when data is transferred” (completam corretamente o handshake de três vias do TCP, mas depois travam quando os dados são transferidos; seção 1). Este teste não procurou isso.

Não testado aqui

• A MTU de um túnel nesta conexão, para WireGuard, Tailscale ou uma VPN de trabalho. Se mudar uma MTU resolve um problema de VPN também não foi testado.
• Um máximo ou um padrão. Nada acima de 1500 bytes pôde sair do computador de teste, então esta página não mostra um máximo. As páginas da própria Starlink sobre MTU não foram lidas para esta página, então ela também não mostra um padrão.
• Wi-Fi. As duas leituras usaram um enlace cabeado.
• Outras conexões e outros momentos. As duas leituras tiveram poucos minutos de intervalo, e a MTU de um caminho “may change over time, due to changes in the routing topology” (pode mudar com o tempo, por causa de mudanças na topologia de roteamento; RFC 8201, seção 3).

Veja como isso se encaixa nos outros testes de casa, para um homelab.