O roteador ADSL aceita com alegria pacotes IPv6 de 2K de tamanho

4

Pelo que entendi a fragmentação do IPv6, os roteadores não realizam fragmentação, apenas os nós de ponta a ponta. E quando qualquer roteador ao longo do caminho receber um pacote maior que o MTU do link para seu próximo salto, ele irá descartá-lo e responder ao IP de origem com um "pacote muito grande" do ICMPv6.

A seguir, o que eu observo na minha configuração:

Inicialmente, depois que meu link ethernet local está ativo, visito uma página HTTP com uma solicitação que faz com que um pacote grande (1965 bytes) seja enviado. Meu roteador responde com ICMPv6 dizendo que o pacote é muito grande e meu MTU é 1492 (o do link ADSL ATM). Minha máquina, em seguida, divide o pacote TCP em dois cada menores (1492 e 545 bytes) e tenta novamente (em vez de adicionar cabeçalhos de extensão ao IPv6 para fragmentação, que é o que eu esperava que acontecesse).

Até aí tudo bem. O que me intriga é que a partir de então, o roteador não envia mais respostas "Packet too big" apesar de alguns pacotes de saída serem maiores que 2K (ex. 2399 bytes) em tamanho e tudo parece estar bem (ou seja, sem retransmissão usando pacotes menores) .

Alguma ideia do que está acontecendo aqui?

Estou no Linux 3.14.23 e no Tomato do meu roteador. Eu não tenho monitoramento de pacotes no meu roteador no momento.

    
por Mansour 04.01.2015 / 16:07

2 respostas

4

A camada entre o IPv6 e a camada física faz com que a fragmentação hop-by-hop seja permitida pelo padrão. E, de fato, se a MTU da camada física for menor que 1280 bytes, essa fragmentação hop-by-hop é mesmo obrigatória. O funcionamento exato de tal fragmentação abaixo da camada IPv6 está fora do escopo do padrão IPv6. A formulação exata na RFC 2460 é esta:

On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

A fragmentação que você tem em mente é a fragmentação de ponta a ponta no IPv6. E esse tipo de fragmentação só pode ser executado pelo nó que originou o pacote em primeiro lugar. Nenhum roteador intermediário tem permissão para realizar esse tipo de fragmentação em um pacote que eles estão encaminhando.

Tanto quanto eu posso dizer da sua pergunta, nenhum tipo de fragmentação está acontecendo no seu caso.

Se você fosse capaz de enviar um pacote de 2KB do cliente HTTP para o roteador, isso implicaria que sua LAN foi configurada para usar jumboframes. Outra possibilidade é que o cliente HTTP esteja executando em um host com suporte para descarregamento de segmentação TCP. Se esse foi o caso, o primeiro pacote pode parecer ser de 2 KB quando observado com o tcpdump no host de envio, mas na verdade ele pode ser um pacote com os primeiros 1500 bytes e outro com o restante.

Os 1500 bytes ainda seriam muito grandes para o MTU no link ADSL. O tamanho real do pacote que aciona a mensagem de erro muito grande pode ser visto na máquina do cliente, inspecionando a mensagem de erro com uma ferramenta apropriada, como por exemplo o Wireshark.

O que acontece quando a pilha TCP do cliente recebe um erro muito grande depende de qual pilha TCP está sendo usada. Alguns retransmitirão o mesmo segmento TCP usando a fragmentação IPv6, outros dividirão o segmento TCP em dois segmentos TCP menores. O padrão IPv6 diz isso:

In order to send a packet larger than a path's MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets).

Eu li isso como recomendando que o segmento TCP seja retransmitido como dois segmentos menores em vez de usar a fragmentação IPv6. Existem várias razões para a segmentação TCP ser preferida à fragmentação.

O roteador pode classificar as mensagens de erro muito grandes. Portanto, se você enviar vários segmentos TCP, cada um com mais de 2 KB, poderá receber apenas uma mensagem de erro para o primeiro. A pilha TCP deve ser capaz de lidar com isso usando a MTU menor, uma vez que ela retransmite os pacotes que excederam a MTU na primeira vez.

O que você está vendo pode ser simplesmente um limite de taxa inferior ao esperado. Você pode tentar medir qual limite de taxa está realmente sendo usado e, em seguida, tomar medidas adicionais apenas se achar que é excessivamente baixo.

    
por 04.01.2015 / 16:47
0

Assim que o tamanho inicial da fragmentação for identificado. Deve ficar com o link. O pacote inicial falhará inicialmente. Outros pacotes serão fragmentados na pilha do IPv6 antes de serem enviados. Despeje o tráfego no cliente e verifique os tamanhos dos pacotes. Você deve ver os pacotes maiores (respostas) sendo fragmentados antes da transmissão.

Você indica que tudo funciona após a primeira fragmentação. Isso indica que os pacotes estão sendo fragmentados adequadamente, caso contrário, eles provavelmente falharão com a fragmentação mais abaixo na rota.

    
por 04.01.2015 / 17:23